Supersnap Management Tools Requirements
A. Vick, D. Adler, M. Reinhart, T. Royle, I. Jordan, W. Workman
Overview:
The LRP used to run a query looking for visits that could be supersnaps, informed the PCs so that they could
prep the visits early, and provided the entire list to SPST regardless of whether the visits could schedule on any
given week. This process also required a "clean-up" each weekso that visits whose plan windows were opening
would be taken out of the supersnap pool, and put back in the general scheduling pool.
Requirements:
In the new procedure membership in the supersnap pool is determined by a flag that need not be changed when
plan windows open. The flag is set to no automatically (and only once) by software for visits that don’t meet the
criteria. The new system allows the PCs to query for their own possible supersnap candidates without involving
the LRPG. SPST uses the flag in conjunction with the constraint windows and USCs to find the subset of supersnaps that can schedule during the week of interest. Several new features, tools and procedures are required to
implement this new scheme:
Supersnap Criteria (implemented as a standalone function in some manner):
• not a member of a link set (orient or timing)
• not a SMOV or ENG proposal type (CAL is okay)
• not a SNAP or an ToO (the not_LRP_canidate state of the LRP state flag
• could be used for this.)
• not wholly internal
• not an earthflat
Database changes:
A new flag called supersnap state should be added to assist in thesu_track table. This flag should be set to U (for
undecided) whenthe visit record is initially made. When changes are made to the visit,the flag should not be
changed.
When flight ready is runs, it should check the visits against thesupersnap criteria. If the visit fails the supersnap
flag shouldbe set to N, if it passes the state should be left as is.
Supersnap Management Tools Requirements
May 10, 2001
1
Procedure changes:
SPST must query every week to find visits that:
• have constraint windows (intersected with all USCs)
• that intersect their week
• are flight ready
• have a new supersnap state flag set to Y
• not already on a calendar, or reserved for a calendar
The PCs will....
• use this tool throughout the year to check for visits that could be prepped early and added to the pool
• flag all visits that they or the PI feel should not be in thesupersnap pool with N. This state will not be changed
by any software.
• Use a new tool to flag visits that can be supersnaps with Y.
Tools:
• a report that would list all visits that pass the above criteria sorted by supersnap state and status (scheduling or
pi/implementation). Generally the PC is interested in the supersnap = "U" list, but the PC could (if they liked)
check the N and Y lists for visits that don’t belong.
• a feature in the Update Tool that allows PCs to toggle the supersnapflag to Y or N (or U?) as they choose.
• a change needed to flight ready: When flight ready is runs, it should check the visits against the supersnap criteria. If the visit fails the supersnap flag should be set to N, if it passes the state should be left as is.
• SPST will need a tool to do a pull of supersnap candidates based on the supersnap flag, and the constraint windows.
Outstanding issues:
• Should the flight ready popup provide a way to set the supersnap status? If so, what should it look like, how
should it function?
• Some visits with new linksets might end up in the pool when they shouldn’t. Is there a good way to check for
these? (ie. a new group within is added after the visits are set to scheduling, but only the visit with the link is
reprocessed.) Maybe the change checker should run some kind of check
• We realize that for changing link sets (and some other changes) vists may end up with the flag set to N.
Unless the PC notices and changes the flag, such visits will unnecessarily be left out of the pool. C’est la vie!
Supersnap Management Tools Requirements
May 10, 2001
2