Tools In the Flight Ops System (FOS) Steve Vaclavik Flight Operations Manager/STScI

What is a Tool? In general: A tool is anything that executes within the FOS environment or employs code to manipulate data, display data, interact with the system or collect information from the system AND is not delivered by Raytheon or the PRD Tools can range from simple Excel spreadsheets that perform calculations to more complex tools that perform specialized functions such as generation of Observatory Center of Mass, Management of Ground Reference Image, Tracking configuration of the FOS, etc. These tools could be written as Python Scripts, Perl Scripts, MatLab Scripts, C/C++ Code, Java, etc. Examples: Excel Spreadsheets Fortran code C/C++ code Matlab scripts Python, Perl, Ruby scripts Microsoft Office objects with embedded macros Etc.

Tool Process (1/5) Developer File a FlightOps DR in the STScI DR system including a description of the tool Must identify an appropriate FOS subsystem to ensure the tool is identified to be discussed in the FOS DRB Basic information (as follows) should be included in the DR to allow the MOM and other reviewers insight into the need and intentions for the tool. What will the tool do? What function does it serve? Who would be expected to use or benefit from the tool? Why is the tool needed within the FOS environment or valuable to users? What is the intended programming language/technology used to develop the tool? Will the tool be used forever or during a certain mission phase or period? How will the tool be utilized? Run continuously, on demand by user, scheduled, etc.? Is the tool reliant on or interacting with FOS applications or formatted outputs/inputs (CTS, BTS, TATS/EDR, RDH, etc.)? Will your tool break if there are changes in the FOS components or data formats for input or output? Other important information

Tool Process (2/5) MOM, FOM, and FOS DRB Review and approve development of the tool Developer/requestor must attend the FOS DRB meeting OR schedule a separate discussion with appropriate people as needed to justify and/or clarify the need for the tool. This may not be required for all tools (depending on complexity and/or risk). If the ITSD and Raytheon representation is not available during the first DRB meeting, it is advised that the developer should talk to them to help identify any concerns and issues as well as to help determine where the tool would be best installed/run within the FOS. Pre-coordination will assist in the smooth transition of the tool into the OPS environment.

Tool Process (3/5) Developer Create and test the tool Provides opportunities for peers to use the tools and provide feedback in a development area not in the FOS. When ready for implementation/deployment, the developer should demonstrate the tool Give a short presentation to MOM and FOM and anyone from the FOS DRB interested in the tool. Include any additional information regarding cost (if any), procurement issues (if any), and schedule needs for deployment that may have been learned or changed since the DR was filed and initial approval was granted. Include preliminary version of the pedigree information at this demonstration. If the tool has been identified as a concern to Raytheon, they may take a copy of the tool to the development lab in Aurora for testing at this time. It is expected that this testing would add no more than a week to the ultimate deployment of the tool. Document instructions and pedigree of the tool. Address CM control of the tool, deployment location, testing information, and general information indicating how a person knows the tool works. Screenshots may be desired and are acceptable where applicable.

Tool Process (4/5) FOS DRB After the developer successfully completes development, demonstration and documentation of the tool, then the FOS DRB will reassign the DR to the ITSD FOS Technical Lead. ITSD FOS Technical Lead Create a Request For Change (RFC). The RFC is an ITSD Footprints Ticket for their installation/modification of the FOS. Normal RFCs are approved via the FOS DRB. ITSD Install tool, with support from FOT if needed. The RFC is closed as implemented and the requestor is notified The RFC is reviewed with the implemented tickets at the next FOS DRB. Close the FlightOps/FOS DR that requested the tool creation.

Tool Process (5/5) Developer – Perform final checkout/validation of the tool deployment in the FOS environment. Make sure that proper directory access is available to all expected users Make sure that the configuration files are in an appropriate state to work in the new environment, etc. In general, this is to test functionality for the expected user set and not necessarily to verify/validate the code. Subsequent changes /enhancements are accomplished via the STScI DR system.

Tool Pedigree Form