# Presentation: 329881

## GPM In-House Lessons Learned Workshop

- Tim Trenkle

- CONFIRMATION  RVW

## My In-House Role(s)

- FAST
- Test conductor
- SWAS
- Originally electrical systems engineer
- Became Mission Systems Engineer
- SMEX-Lite
- System engineer during design and system-level I&T
- Triana
- Mission systems engineer from design through Environmental test program

- CONFIRMATION  RVW

## What Worked Well

- Peer reviews
- Table-top design reviews, heavy on design, light on vu-graphs
- Chaired by Mission system engineer
- Action items tracked in an on-line database
- Attendance by project as well as in-house and out-of-house experts
- Guidelines for the design lead well-defined (i.e., we expected certain things in the package and if they weren’t there, we delayed the review)
- Review packages distributed to the review panel in advance of the review
- Observatory/GUS I&T
- Used SMEX/Spartan lessons learned
- Most folks had a lot of experience working in-house missions
- Partnership with Alenia
- Because of language barriers, found that face-to-face meeting and working was the only way to go
- Needed to be disciplined about documenting decisions, actions, etc from meetings
- Use of on-line collaboration tools

- CONFIRMATION  RVW

## What Worked Well

- Shuttle safety process
- Deputy program manager very familiar with the process from Spartan
- Had 4 shuttle safety experts assigned to the project
- Included project safety experts in all peer reviews and design meetings
- EEE Parts Management
- Full-time project parts engineer
- Maintained parts inventory
- Kept up with GIDEP and GSFC alerts
- Audited contractor P/Ls
- Defined additional tests (screening, burn-in etc)
- On-line collaborative engineering process
- Each subsystem and instrument team maintained an on-line repository of documentation
- Facilitated communication

- CONFIRMATION  RVW

## What Did Not Work Well

- Some aspects of environmental test
- Reasoned that instead of environmentally testing at the box level, we would environmentally test at s/c, instrument and observatory level
- Tough to get individual boxes to qual limits at the s/c level
- Worked against preventing burn-out of the test team because they were required to support two long-term system-level environmental test programs instead of the traditional single program
- Timely distribution of trend data to subsystems
- Plotting of data somewhat labor intensive resulting in irregular distribution
- Physical separation of C&DH/ACS FSW teams
- Lost out on a lot of synergy between the teams

- CONFIRMATION  RVW

## Process Risk Areas

- ISO-9000 application
- A lot of overhead without a lot of value added
- Was effective at enforcing discipline in configuration control of procedures, software, WOAs
- Project CM lead worked closely with the GSFC ISO-team to “police” us
- Science advocacy; developing and maintaining
- GSFC project scientist worked very closely with project PI
- Non-science project representation at all science team meetings
- Gave us insight into what the science team thought was important as well as their concerns
- Developed a sense of “team” between the project and the scientists

- CONFIRMATION  RVW

## Process Risk Areas

- Efficiently Running I&T
- Top-level view of I&T as part of Mission Systems Requirements Document
- Used flight operations engineers as I&T test conductors
- Used the same command/telemetry software for all instrument development, system I&T and flight operations
- During design phase, employed the use of COTS interfaces, operating systems, etc
- Assigned a test conductor to work with each intrumentor to develop instrument-level I&T procedures.  This eased the transition to system I&T once the instrument was integrated
- Before the integration of each subsystem, walked through the mechanical and electrical integration procedures
- Walk-thru about 1 week prior to planned integration
- Included subsystem lead, I&T manager, Mission System Engineer, mechanical and electrical techs and the test conductor lead

- CONFIRMATION  RVW

## GFSC-Specific Aspects

- Tracking in-house performance, schedule, cost and workforce
- Each subsystem developed a System Implementation Plan (SIP)
- Developed in conjunction with a requirements review between the subsystem lead and the Mission Systems Engineer.  Each subsystem requirements set served as the assumptions for the SIP
- The SIP included cost, schedule, man-power, anticipated purchases, etc
- The SIP served as a contract between each subsystem and the Project Office

- CONFIRMATION  RVW

## GFSC-Specific Aspects

- Controlling requirements creep
- Difficult because of the concurrent nature of the mission/subsystem design phases
- Real-time capture of “design decisions”
- “Design decisions” document evolved into Mission Systems Requirements Document
- Held a requirements review with each subsystem prior to detailed design
- Each subsystem generated a System Implementation Plan (SIP) which included the the requirements for that subsystem (including derived requirements)
- The SIP served as the “contract” between each subsystem and the project
- We could have done a better job of CM control on requirements!
- Requirements document should have been set up as a data-base to help in the development of the requirements verification matrix

- CONFIRMATION  RVW

## GFSC-Specific Aspects

- Timely anomaly resolution
- Used on-line anomaly tracking system developed for SMEX
- Data-base which allowed sorting by subsystem or status (open, closed, verified)
- Encouraged I&T team to write up anything that looked “funny” as an anomaly
- Resulted in a lot of anomalies
- Insured that nothing was missed
- Bi-weekly meetings (chaired by mission system engineer) between mission system engineer, project manager and project QA to go over anomalies generated in the past 2 weeks and determine which ones needed to be elevated to NCRs
- Bi-weekly meetings also used to status anomalies
- Number opened in the past 2 weeks
- Number closed in the past 2 weeks
- Total number open
- Total number closed

- CONFIRMATION  RVW

## Summary

- Top 5 in-house lessons learned
- Deep involvement by the systems team in all aspects of design, integration and test
- Extensive use of engineering peer reviews
- Use of on-line collaborative engineering tools to mitigate geographical separation between various team members
- Full-time parts engineer assigned to project
- Standardized command/telemetry software across instruments/observatory and mission operations

- CONFIRMATION  RVW