NASA Project Management System Engineering and Project Control Processes and Requierments

JPR 7120.3 March 2004

Project Management: Systems Engineering & Project Control Processes and Requirements

JPR 7120.3 JSC Procedures and Guidelines for Project Management: Systems Engineering and Project Control Processes an d Requirements

Development Team This document was developed as a joint effort between the JSC Systems Engineering Working Group (J-SEWG) and the Project Management Working Group (PMWG).

J-SEWG: AG/James Ortiz (Chair) AG/Jeff Phillips, Dwight Auzenne, Ralph Anderson EA/Linda Bromley, Joyce Carpenter, Cliff Farmer DA/Larry Bishop, Patricia Carreon

PMWG: AG/Lee Graham (Chair) AG/Samuel Padgett EA/Linda Bromley DA/Jerome Yencharis

IA/Jon Symes, John Jurgensen JA/Jay Hoover A/Daniel Freund RA/Jason Noble SA/Karen Morrison XA/Cuong Nguyen OA/Jonette Stecklein

IA/Jon Symes JA/Gary Wessels AH/Brad Mudgett, Erica Vandersand A/Jeevan Perera RA/Jason Noble SA/Douglas Whitehead LA/Richard Whitlock

Consultation supported proved by the following personnel: Booz-Allen & Hamilton, Inc./Jack Gavalas Raytheon Technical Services Company, LCC/Larry Patrick Raytheon Technical Services Company, LCC/Brian Vining Raytheon Technical Services Company, LCC/Harold Smith

Editorial and graphics design suppor t provided by the following personnel: DynCorp/Betty Conaway InDyne/Sharon Hecht InDyne/Sid Jones

Change Record Revision

Date

Organization/Phone

Basic

March 2004

AG/Lee Graham/281-244-5192

Change 1

April 2006

AG/Bobby Watkins/281-483-0243

Description

Change in applicability to basic and applied research.

This JSC Procedures Guideline (JPG) is being changed to a JSC Procedures Requirement (JPR) document with no context changes. All referenced JPGs in this document will be evaluated during the annual review of this document and will be updated t o reflect additional changes to any JPGs that are currently referenced.

Table o f Content s Chapter 1 Introduction------------------------------------------------------------------------------1.1 Purpose------------------------------------------------------------------1.2 Applicability and Scope --------------------------------------------1.3 Authority ---------------------------------------------------------------1.4 References--------------------------------------------------------------1.4.1 External Documents -------------------------------------------------1.4.2 NASA Documents ---------------------------------------------------1.4.3 JSC Documents -------------------------------------------------------1.5 Cancellation-------------------------------------------------------------

Chapter 2

Overview of Project Management at JSC----------------------------------------2.1 Scope --------------------------------------------------------------------2.2 Systems Engineering ------------------------------------------------2.3 Project Control--------------------------------------------------------2.4 Project Types, Approaches, and Life Cycle Phases ---------2.4.1 Project Types ----------------------------------------------------------STS104-723-014 (21 July 2001) 2.4.1.1 Space flight system development projects ---------------------Backdropped over a wide scene of 2.4.1.2 Advanced techno logy development projects ------------------topography in the Middle East, the 2.4.1.3 Science research, applied research, and International Space Station (ISS) passes over the Persian Gulf. This photograph advanced studies------------------------------------------------------was taken with a 70mm han dheld camera 2.4.1.4 Institutional ------------------------------------------------------------during a fly -around insp ection by the 2.4.1.5 Operations--------------------------------------------------------------Spac e Shuttl e Atlantiscrew not long after 2.4.2 Project Approaches --------------------------------------------------the two spacecraft separated. Prominent Staffing------------------------------------------------------------------on the starboard side of the outpost is2.4.2.1 the newly-installed Quest airlock. 2.4.2.2 Type of contract ------------------------------------------------------2.4.2.3 Magnitude--------------------------------------------------------------2.4.2.4 Implementation approach ------------------------------------------2.4.3 Project Life Cycle Phases ------------------------------------------2.5 2.5.1 2.5.2 2.5.3 2.5.3.1 2.5.3.2 2.5.3.3 2.6 2.7 2.7.1 STS104-315-005 (12-24 July 2001) 2.7.2 With Earth’s horizon in the background,2.7.2.1 astronaut Michael L. Gernhardt, STS -104 2.7.2.2 mission specialist, participates in one of 2.7.2.3 three spacewalks aimed toward wrapping up the completion of work on the second 2.7.2.4 phase of the ISS. Gernhardt was joined 2.7.2.5 on this spacew alk by astronaut 2.7.2.6 James F. Reilly. 2.7.2.7 2.7.2.8 2.7.2.9 2.7.2.10 2.7.3 2.7.3.1

1-1 1-1 1-1 1-2 1-3 1-3 1-4 1-7 1-7

2-1 2-1 2-1 2-1 2-2 2-2 2-2 2-2 2-2 2-3 2-3 2-4 2-4 2-4 2-5 2-5 2-6

Project Management Forums --------------------------------------Project-level Forums ------------------------------------------------Directorate-level Forums -------------------------------------------Center-level Forums -------------------------------------------------JSC Engineering Review Board (ERB) ------------------------JSC Facility Review Board (FRB)-------------------------------JSC Project Management Council -------------------------------Documentation Tree -------------------------------------------------Project Team-----------------------------------------------------------Organization -----------------------------------------------------------Membership------------------------------------------------------------Project manager role -------------------------------------------------Deputy project manager (DPM) role ----------------------------Lead systems engineer (LSE) role -------------------------------Project control officer role -----------------------------------------Subsystem and discipline lead engineers role ----------------Verification lead role ------------------------------------------------Validation lead role --------------------------------------------------Project scientis t role --------------------------------------------------

2-7 2-7 2-7 2-7 2-7 2-7 2-8 2-11 2-12 2-12 2-12 2-12 2-13 2-13 2-13 2-14 2-14 2-15 2-15

User representative role ---------------------------------------------Administrative officer role -----------------------------------------Support Team ---------------------------------------------------------Line management support-------------------------------------------

2-15 2-15 2-15 2-15

v

Table o f Content s 2.7.3.2 2.7.3.3 2.7.3.4 2.7.3.5 2.7.3.6 2.7.3.7 2.7.3.8 2.7.3.9 2.7.3.10 2.7.3.11 2.7.3.12 2.7.3.13 2.7.3.14

ISS01-323-010 (8 November 2000)

2.7.3.15 2.7.3.16 2.7.3.17 2.7.3.18 2.7.3.19

Early fil m docu mentation ofthe Ex pedition 2.8 2.8.1 1 crewmembers on boardSS theshows I cosmonauts Sergei K. Krikalev (left) and 2.8.2 Yuri P. Gidzenko at work in the Zvezda 2.8.3 Service Module. This is one of the first film images that was released from the 2.8.4 Expedition 1 crew.

Safety and mission assurance (S&MA) support -------------Mission operations support ----------------------------------------Test operations lead support---------------------------------------Facilities support -----------------------------------------------------Environmental support ----------------------------------------------Counterintelligence support ---------------------------------------Export control support ----------------------------------------------Logistics, transportation, and shipping support --------------Procurement support ------------------------------------------------Office of the Chief Financial Officer (CFO) support ------------------------------------------------------------------Office of the Chief Engineer support ---------------------------Legal support----------------------------------------------------------Communication and information technology support ------------------------------------------------------------------Documentation and graphics support ---------------------------Photographic -video support ---------------------------------------Public Affairs Office support -------------------------------------Human factors support ----------------------------------------------Technology transfer and intellectual property management support ------------------------------------------------Project Management and Planning ------------------------------Project Management-------------------------------------------------Project Management Plan and Project Baseline --------------Program Operating Plan (Project Baseline Updates) ----------------------------------------------------------------Customer-Project Agreement --------------------------------------

2-16 2-16 2-16 2-17 2-17 2-17 2-17 2-18 2-18 2-18 2-18 2-18 2-19 2-19 2-19 2-19 2-19 2-19 2-21 2-21 2-21 2-22 2-22

Chapter 3 Project Life Cycle Requirements---------------------------------------------------3.1 Pre-Phas e A – Advanced Studies --------------------------------3.1.1 Overview ---------------------------------------------------------------3.1.2 Expected Results/Outcomes---------------------------------------3.1.3 Products-----------------------------------------------------------------3.1.4 Process ------------------------------------------------------------------3.1.5 Reviews – Conce pt Revie w ---------------------------------------3.1.6 Management Decision ----------------------------------------------3.1.7 References--------------------------------------------------------------3.2 Phas e A – Preliminary Analysis ----------------------------------ISS01-E-5129 (December 2000) 3.2.1 Overview ---------------------------------------------------------------Astronaut William M. (Bill) Shepherd, 3.2.2 Expected Results/Outcomes---------------------------------------Expedition One commander, works on the Products-----------------------------------------------------------------Ward R oom table in het Zvezda Service 3.2.3 Module abo ard theISS. 3.2.4 Process ------------------------------------------------------------------3.2.5 Reviews -----------------------------------------------------------------3.2.5.1 The Requirements Review -----------------------------------------3.2.5.2 The Definition Review----------------------------------------------3.2.6 Management Decision ----------------------------------------------3.2.7 References--------------------------------------------------------------3.3 Phase B – Definition ------------------------------------------------3.3.1 Overview ---------------------------------------------------------------3.3.2 3.3.3 3.3.4 3.3.5 3.3.5.1

Expected Results/Outcomes---------------------------------------Products-----------------------------------------------------------------Process ------------------------------------------------------------------Reviews -----------------------------------------------------------------The System Requirements Review -------------------------------

vi

3-1 3-2 3-2 3-2 3-2 3-2 3-2 3-2 3-3 3-4 3-4 3-4 3-4 3-4 3-4 3-4 3-4 3-6 3-6 3-7 3-7 3-7 3-7 3-7 3-7 3-7

Table o f Content s 3.3.5.2 3.3.5.3 3.3.6 3.3.7 3.4 3.4.1 3.4.2 3.4.3 3.4.4 3.4.5 3.4.6 3.4.7

The System Definition Review-----------------------------------The Preliminary Design Review ---------------------------------Management Decision ----------------------------------------------References--------------------------------------------------------------Phase C – Design -----------------------------------------------------Overview ---------------------------------------------------------------Expected Results/Outcomes---------------------------------------Products-----------------------------------------------------------------Process ------------------------------------------------------------------Reviews – The Critical Design Review ------------------------Management Decision ----------------------------------------------References---------------------------------------------------------------

3-8 3-9 3-10 3-10 3-11 3-11 3-11 3-11 3-11 3-11 3-12 3-12

3.5 3.5.1 3.5.2 3.5.3 3.5.4 3.5.5 3.5.5.1 3.5.5.2 STS105-725-006 (16 August 3.5.5.3 2001) 3.5.5.4 Astronaut Daniel T. Barry, STS-105 mission specialist, traverses along the 3.5.5.5 Space Shu ttleDiscovery’s payload bay, 3.5.6 backdropped inst aga the blue andwhite 3.5.7 Earth, during one of two days of space3.6 walks. Barry was joined by astronaut Patrick G. Forrester, mission specialist,3.6.1 on both of the spacewalks scheduled for 3.6.2 the STS-105 mission. 3.6.3 3.6.4 3.6.5 3.6.5.1 3.6.5.2 3.6.5.3 3.6.5.4 3.6.6 3.6.7 3.7 3.7.1 3.7.2 3.7.2.1 STS105-E-5168 (13 August 2001) 3.7.2.2 Astronaut Yury V. Usachev works out on 3.7.3 the treadmill device in the Zvezda Service Module aboard the ISS. The Expedition 2 3.7.4 mission commander is only days away3.7.5 from returning to Earth following five 3.7.5.1 months aboard the orbital outpost. 3.7.5.2 3.7.6 3.7.7

Phase D – ---------------------------------------------------------------Development --------------------------------------------Overview Expected Results/Outcomes---------------------------------------Products-----------------------------------------------------------------Process ------------------------------------------------------------------Reviews -----------------------------------------------------------------The Production Readiness Review ------------------------------The Test Readiness Review ---------------------------------------The System Acceptance Review ---------------------------------The Deployment Readiness Review ----------------------------The Operational Readiness Review -----------------------------Management Decision ----------------------------------------------References--------------------------------------------------------------Phase E – Operations------------------------------------------------Overview ---------------------------------------------------------------Expected Results/Outcomes---------------------------------------Products-----------------------------------------------------------------Process ------------------------------------------------------------------Reviews -----------------------------------------------------------------The Delta Operational Readiness Review ---------------------The System Upgrade Review -------------------------------------The Safety Review ---------------------------------------------------The Decommissioning Review -----------------------------------Management Decision ----------------------------------------------References--------------------------------------------------------------Project Termination--------------------------------------------------Overview ---------------------------------------------------------------Activities ---------------------------------------------------------------Nominal termination ------------------------------------------------Off-nominal termination -------------------------------------------Products-----------------------------------------------------------------Process ------------------------------------------------------------------Reviews -----------------------------------------------------------------The Termination Review -------------------------------------------The Decommissioning Review -----------------------------------Management Decision ----------------------------------------------References---------------------------------------------------------------

3-13 3-13 3-13 3-13 3-13 3-16 3-16 3-17 3-17 3-17 3-18 3-18 3-18 3-19 3-19 3-19 3-19 3-19 3-19 3-19 3-19 3-19 3-20 3-20 3-20 3-21 3-21 3-21 3-21 3-21 3-22 3-22 3-22 3-22 3-22 3-24 3-24

vii

Table o f Content s Chapter 4 Project Management Processes and Requirements ----------------------------4.0.1 References--------------------------------------------------------------4.1 Systems Engineering Processes ----------------------------------4.1.1 Requirements Development ---------------------------------------4.1.1.1 Function-----------------------------------------------------------------4.1.1.2 Objective ---------------------------------------------------------------4.1.1.3 Responsibilities -------------------------------------------------------4.1.1.4 Life cycle ---------------------------------------------------------------4.1.1.5 Inputs --------------------------------------------------------------------4.1.1.6 Steps ---------------------------------------------------------------------4.1.1.7 Outputs -------------------------------------------------------------------

4-1 4-3 4-4 4-4 4-4 4-4 4-4 4-4 4-4 4-4 4-6

4.1.1.8 4.1.1.9 4.1.1.10 4.1.1.11 4.1.1.12 4.1.2 4.1.2.1 4.1.2.2 STS100-347-025 (28 April 2001) 4.1.2.3 The Canadian-built Space Station robotic arm transfers its launch cradle over to 4.1.2.4 Endeavour’s Canadian -builtrobotic arm. 4.1.2.5 A Canadian mission specialist, astronaut 4.1.2.6 Chris A. Hadfield, was instrumental in the activity as he was at the controls of the4.1.2.7 srcinal robot arm from his post on the 4.1.2.8 aft flight deck of the Shuttle. 4.1.2.9 4.1.2.10 4.1.2.11 4.1.2.12 4.1.3

Exit criteria-------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques --------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Requirements Management----------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques --------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Operational Concept Development -------------------------------

4-6 4-7 4-7 4-7 4-7 4-9 4-9 4-9 4-9 4-9 4-9 4-9 4-10 4-10 4-11 4-11 4-11 4-11 4-12

4.1.3.1 4.1.3.2 4.1.3.3 4.1.3.4 4.1.3.5 4.1.3.6 4.1.3.7 4.1.3.8 STS100-395-017 (19 April - 1 4.1.3.9 May 2001) 4.1.3.10 A close look at the window in this picture of the Destiny laboratory reveals the faces 4.1.3.11 of astronauts Susan J. Helms and James 4.1.3.12 S. Voss, flight engineers for the Expedition 4.1.4 2 mission. One of he t two STS -100 space walkers, astronauts Scott E. Parazynski4.1.4.1 and Chris A. Hadfield, exposed the image 4.1.4.2 with a 35mm camera on one of two days 4.1.4.3 of performing spacewalks. 4.1.4.4 4.1.4.5 4.1.4.6 4.1.4.7 4.1.4.8 4.1.4.9 4.1.4.10 4.1.4.11

Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques --------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Decomposition --------------------------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques --------------------------------------------Software tools ----------------------------------------------------------

4-12 4-12 4-12 4-12 4-12 4-12 4-13 4-14 4-14 4-14 4-14 4-14 4-15 4-15 4-15 4-15 4-15 4-15 4-15 4-17 4-17 4-17 4-17 4-18

viii

Table o f Content s 4.1.4.12 4.1.5 4.1.5.1 4.1.5.2 4.1.5.3 4.1.5.4 4.1.5.5 4.1.5.6 4.1.5.7 4.1.5.8 4.1.5.9 4.1.5.10

References--------------------------------------------------------------Feasibility Study------------------------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques ---------------------------------------------

4-18 4-19 4-19 4-19 4-19 4-19 4-19 4-19 4-20 4-21 4-21 4-21

4.1.5.11 4.1.5.12 4.1.6 4.1.6.1 4.1.6.2 4.1.6.3 4.1.6.4 4.1.6.5 4.1.6.6 STS108-725-010 (5-17 December 2001) 4.1.6.7 Backdropped by the blackness of space, 4.1.6.8 the S I S was photographed by a crew 4.1.6.9 member aboard the Space Shuttle 4.1.6.10 Endeavour. 4.1.6.11 4.1.6.12 4.1.7 4.1.7.1 4.1.7.2 4.1.7.3 4.1.7.4 4.1.7.5 4.1.7.6 4.1.7.7 4.1.7.8 4.1.7.9 4.1.7.10 STS108-350-009 (10 December 4.1.7.11 2001) 4.1.7.12 Astronaut Linda M. Godwin, STS-108 mission specialist, works during a four-4.1.8 hour,12-m inute spac ewalk The ain m 4.1.8.1 objective of the spacewalk was to install 4.1.8.2 thermal blankets on mechanisms that 4.1.8.3 rotate the ISS’s main solar arrays. 4.1.8.4 4.1.8.5 4.1.8.6 4.1.8.7 4.1.8.8 4.1.8.9 4.1.8.10

Software tools ---------------------------------------------------------References-------------------------------------------------------------Technology Planning------------------------------------------------Function-----------------------------------------------------------------Objectives --------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques--------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Design -------------------------------------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques --------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Attainment -------------------------------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques ---------------------------------------------

4-21 4-22 4-23 4-23 4-23 4-23 4-23 4-23 4-23 4-25 4-25 4-25 4-25 4-25 4-25 4-26 4-26 4-26 4-26 4-27 4-27 4-27 4-28 4-29 4-29 4-29 4-29 4-30 4-31 4-31 4-31 4-31 4-31 4-31 4-31 4-32 4-33 4-33 4-33

4.1.8.11 4.1.8.12 4.1.9 4.1.9.1 4.1.9.2

Software tools ---------------------------------------------------------References--------------------------------------------------------------Integration--------------------------------------------------------------Function-----------------------------------------------------------------Objective ----------------------------------------------------------------

4-33 4-34 4-35 4-35 4-35

ix

Table o f Content s 4.1.9.3 4.1.9.4 4.1.9.5 4.1.9.6 4.1.9.7 4.1.9.8 4.1.9.9 4.1.9.10 4.1.9.11 4.1.9.12 4.1.10 4.1.10.1 4.1.10.2 4.1.10.3 4.1.10.4 4.1.10.5 4.1.10.6 4.1.10.7 4.1.10.8 4.1.10.9 ISS003-E-5415 (10 September 4.1.10.10 2001) 4.1.10.11 Expedition 3 mission commander Frank L. Culbertson, Jr., conducts inflight 4.1.10.12 maintenance with a ratchet under a panel in 4.1.11 the Unity Node 1 on the ISS. This image was taken with a digital still camera. 4.1.11.1 4.1.11.2 4.1.11.3 4.1.11.4 4.1.11.5 4.1.11.6 4.1.11.7 4.1.11.8 4.1.11.9 4.1.11.10 4.1.11.11 4.1.11.12 4.1.12 4.1.12.1 ISS003-E-5634 (17 September 2001) 4.1.12.2 Cosmonaut Mikhail Tyurin, Expedition 34.1.12.3 flight engineer, packs the docking probe in 4.1.12.4 a stowage bag in Unity. The docking probe successfully guided the arrival of the 4.1.12.5 Russian-built Pirs docking compartment 4.1.12.6 to the ISS. 4.1.12.7 4.1.12.8 4.1.12.9 4.1.12.10 4.1.12.11 4.1.12.12 4.1.13 4.1.13.1 4.1.13.2 4.1.13.3 4.1.13.4 4.1.13.5 4.1.13.6

Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques --------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Technical Work and Resource Management------------------Function------------------------------------------------------------------

4-35 4-35 4-35 4-35 4-40 4-40 4-40 4-41 4-41 4-41 4-42 4-42

Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques --------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Safety and Mission Success ---------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques --------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Control ------------------------------------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques --------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------System Analysis ------------------------------------------------------Function------------------------------------------------------------------

4-42 4-42 4-42 4-42 4-43 4-45 4-45 4-45 4-46 4-46 4-46 4-47 4-47 4-47 4-47 4-48 4-48 4-48 4-51 4-51 4-51 4-51 4-51 4-51 4-53 4-53 4-53 4-53 4-53 4-53 4-53 4-55 4-55 4-55 4-56 4-56 4-56 4-57 4-57

Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ----------------------------------------------------------------------

4-57 4-57 4-57 4-57 4-58

x

Table o f Content s 4.1.13.7 4.1.13.8 4.1.13.9 4.1.13.10 4.1.13.11 4.1.13.12 4.1.14 4.1.14.1 4.1.14.2 4.1.14.3 4.1.14.4 4.1.14.5

Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques --------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Verification ------------------------------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs ---------------------------------------------------------------------

4-59 4-59 4-59 4-60 4-60 4-60 4-61 4-61 4-61 4-61 4-61 4-61

4.1.14.6 4.1.14.7 4.1.14.8 4.1.14.9 4.1.14.10 4.1.14.11 4.1.14.12 4.1.15 JSC2001-E-24454 (8 August 4.1.15.1 2001) 4.1.15.2 Astronaut John M. Grunsfeld, STS-109 4.1.15.3 payload commander, uses virtual reality hardware at the Johnson Space Center4.1.15.4 (JSC) to rehearse some of his duti es on 4.1.15.5 the upcoming ST -109 m ission, ASA N ’s 4.1.15.6 fourth servicing visit to the Hubble Space 4.1.15.7 Telescope. 4.1.15.8 4.1.15.9 4.1.15.10 4.1.15.11 4.1.15.12 4.1.16 4.1.16.1 4.1.16.2 4.1.16.3 4.1.16.4 4.1.16.5 4.1.16.6 4.1.16.7 STS109-E-5048 (3 March 2002) The top portion of the Hubble Space 4.1.16.8 4.1.16.9 Telescope is phot ographed some 350 miles above the Pacific Ocean southwest 4.1.16.10 of Mexico, as theSpaceShuttl eColumbia 4.1.16.11 is about to use its 50-foot-long robotic arm 4.1.16.12 to lower the telescope into its cargo bay. 4.2 The image was one of a series recorded with a digital still camera. 4.2.1 4.2.1.1 4.2.1.2 4.2.1.3 4.2.1.4

Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques --------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Validation --------------------------------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques --------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Reviews -----------------------------------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques --------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Project Control Processes ------------------------------------------Resource Management----------------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ----------------------------------------------------------------

4-62 4-63 4-63 4-63 4-63 4-64 4-64 4-65 4-65 4-65 4-65 4-65 4-65 4-65 4-66 4-67 4-67 4-67 4-67 4-68 4-69 4-69 4-69 4-69 4-69 4-69 4-69 4-71 4-71 4-71 4-71 4-72 4-72 4-73 4-73 4-73 4-74 4-74 4-74

Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement -----------------------------------------------------------

4-74 4-74 4-74 4-74 4-74

4.2.1.5 4.2.1.6 4.2.1.7 4.2.1.8 4.2.1.9

xi

Table o f Content s 4.2.1.10 4.2.1.11 4.2.1.12 4.2.2 4.2.2.1 4.2.2.2 4.2.2.3 4.2.2.4 4.2.2.5 4.2.2.6 4.2.2.7 4.2.2.8

Methods and techniques --------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Planning-----------------------------------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria --------------------------------------------------------------

4-74 4-75 4-75 4-76 4-76 4-76 4-76 4-76 4-76 4-76 4-76 4-77

4.2.2.9 4.2.2.10 4.2.2.11 4.2.2.12 4.2.3 4.2.3.1 4.2.3.2 4.2.3.3 STS108-E-5594 (15 December 4.2.3.4 2001) 4.2.3.5 As seen in a medium view from a digital 4.2.3.6 still camera aimed through a window on Endeavour’s aft flight deck, the ISS, now4.2.3.7 staffed with its fourth three-person crew, i 4.2.3.8 contrasted against aatch p of the blued an 4.2.3.9 white Earth during a farewell look from the 4.2.3.10 Shuttle following undocking. The Destiny 4.2.3.11 laboratory is partially covered with shadows in the foreground. 4.2.3.12 4.2.4 4.2.4.1 4.2.4.2 4.2.4.3 4.2.4.4 4.2.4.5 4.2.4.6 4.2.4.7 4.2.4.8 4.2.4.9 4.2.4.10 4.2.4.11 ISS004-E-10071 (17 April 2002) 4.2.4.12 Moments prior to the undocking of the 4.2.5 Space Shu ttle Atlantisfrom the ISS, an 4.2.5.1 Expedition 4 crewmember took this digital still photograph from a window in the 4.2.5.2 Pirs Docking Compartment. The -110 STS cr e 4.2.5.3 spent about a week aboardSS theand I successfully installed the S0 (S-zero) 4.2.5.4 truss. Also visible in this image are the4.2.5.5 Soyuz Space craft, Space Stati on Rem ote 4.2.5.6 Manipulator System/Canadarm2 and 4.2.5.7 Pressurized Mating Adapter 3. 4.2.5.8

Measurement ----------------------------------------------------------Methods and techniques --------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Documentation and Data Management -------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques --------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Cost Estimating -------------------------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria-------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques --------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Performance Measurement ----------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria --------------------------------------------------------------

4-77 4-78 4-78 4-78 4-79 4-79 4-79 4-79 4-79 4-79 4-79 4-80 4-80 4-80 4-80 4-80 4-81 4-82 4-82 4-82 4-82 4-82 4-82 4-82 4-83 4-83 4-83 4-84 4-84 4-84 4-85 4-85 4-86 4-86 4-86 4-86 4-87 4-89 4-89

4.2.5.9 4.2.5.10 4.2.5.11 4.2.5.12 4.2.6

Measurement ----------------------------------------------------------Methods and techniques --------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Schedule Management -----------------------------------------------

4-89 4-89 4-89 4-90 4-91

xii

Table o f Content s 4.2.6.1 4.2.6.2 4.2.6.3 4.2.6.4 4.2.6.5 4.2.6.6 4.2.6.7 4.2.6.8 4.2.6.9 4.2.6.10 4.2.6.11 4.2.6.12

Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and technique s--------------------------------------------Software tools ---------------------------------------------------------References---------------------------------------------------------------

4-91 4-91 4-91 4-91 4-91 4-91 4-92 4-92 4-93 4-93 4-93 4-93

4.2.7 4.2.7.1 4.2.7.2 4.2.7.3 4.2.7.4 4.2.7.5 4.2.7.6 4.2.7.7 STS110-718-013 (13 April 2002) 4.2.7.8 Astronaut Lee M. E. Morin, STS-110 4.2.7.9 mission specialist, anchored on the mobile 4.2.7.10 foot restraint on the ISS nadarm C 2, moves toward the Station’s newly installed 4.2.7.11 S0 (S-zero) truss during this second 4.2.7.12 scheduled spacew alk Astronaut Jerry L. 4.3 Ross, mission specialist, worked in tandem with Morin on the spacewalk. 4.3.1 4.3.1.1 4.3.1.2 4.3.1.3 4.3.1.4 4.3.1.5 4.3.1.6 4.3.1.7 4.3.1.8 4.3.1.9 4.3.1.10 4.3.1.11 4.3.1.12 STS110-366-002 (11 April 2002) 4.3.2 Astronaut Steven L. Smith, STS-110 4.3.2.1 mission specialist, works inside the S0 4.3.2.2 truss, newly installed on the ISS. Astronaut Rex J. Walheim(out of frame), 4.3.2.3 mission specialist, worked in tandem with 4.3.2.4 Smith during the spacewalk. 4.3.2.5 4.3.2.6 4.3.2.7 4.3.2.8 4.3.2.9 4.3.2.10 4.3.2.11

Project Analysis ------------------------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques --------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Crosscutting Processes----------------------------------------------Acquisition Management-------------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques --------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Risk Management ----------------------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques --------------------------------------------Software tools ----------------------------------------------------------

4-94 4-94 4-94 4-94 4-94 4-94 4-94 4-96 4-96 4-96 4-96 4-96 4-96 4-97 4-97 4-97 4-97 4-97 4-97 4-97 4-98 4-99 4-99 4-99 4-100 4-100 4-100 4-101 4-101 4-101 4-101 4-101 4-101 4-101 4-102 4-103 4-103 4-103 4-104

4.3.2.12 4.3.3 4.3.3.1 4.3.3.2 4.3.3.3

References--------------------------------------------------------------Configuration Management ---------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities --------------------------------------------------------

4-104 4-105 4-105 4-105 4-105

xiii

Table o f Content s

ISS005-E-19968 (6 November 2002)

4.3.3.4 4.3.3.5 4.3.3.6 4.3.3.7 4.3.3.8 4.3.3.9 4.3.3.10 4.3.3.11 4.3.3.12 4.3.4 4.3.4.1 4.3.4.2

Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques --------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Quality Management ------------------------------------------------Function-----------------------------------------------------------------Objective ----------------------------------------------------------------

4-105 4-105 4-106 4-107 4-108 4-108 4-108 4-108 4-109 4-110 4-110 4-110

4.3.4.3 4.3.4.4 4.3.4.5 4.3.4.6 4.3.4.7 4.3.4.8 4.3.4.9 4.3.4.10 4.3.4.11 4.3.4.12

Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques --------------------------------------------Software tools ---------------------------------------------------------References---------------------------------------------------------------

4-110 4-110 4-110 4-111 4-112 4-113 4-113 4-113 4-113 4-113

Astronaut Peggy A. Whitson, Expedition 5 flight engineer, exercises in the Destiny laboratory on the ISS.

Appendices Appendix A – Project Management Content Requirements ----------------A.1 Title Page ---------------------------------------------------------------A.2 Introduction------------------------------------------------------------A.3 Objectives --------------------------------------------------------------A.4 Customer Definition and Advocacy-----------------------------A.5 Project Authority -----------------------------------------------------A.6 A.7 A.8 A.9 A.10 ISS005-E-20309 (8 November A.11 2002) Soyuz 5 Comm ander Serge i Zalyotin A.12 looks at a plant growth experiment in A.13 the Zvezda Service Modu le onthe S I S. A.14 A.15 A.16 A.17 A.18 A.19 A.20 A.21 A.22 A.23 A.24 A.25 A.26

Management -----------------------------------------------------------Project Requirements-----------------------------------------------Technical Summary -------------------------------------------------Logistics ----------------------------------------------------------------Schedules ---------------------------------------------------------------Resources---------------------------------------------------------------Controls -----------------------------------------------------------------Implementation Approach -----------------------------------------Acquisition Summary -----------------------------------------------Program/Project Dependencies -----------------------------------Agreements ------------------------------------------------------------Safety and Mission Success ---------------------------------------Risk Management ----------------------------------------------------Environmental Impact ----------------------------------------------Test and Verification ------------------------------------------------Technology Assessment --------------------------------------------Commercialization ---------------------------------------------------Reviews -----------------------------------------------------------------Termination Review Criteria --------------------------------------Tailoring ----------------------------------------------------------------Change Log -------------------------------------------------------------

xi v

A-1 A-1 A-1 A-1 A-1 A-1 A-1 A-1 A-1 A-1 A-1 A-1 A-2 A-2 A-2 A-2 A-2 A-2 A-2 A-2 A-2 A-2 A-2 A-3 A-3 A-3 A-3

Table o f Content s Appendix B – Systems Engineering Management Plan Outline -----------B.1 Description of the System of Interest ---------------------------B.2 Description of the Technical Processes -------------------------B.3 Software Development----------------------------------------------B.4 Project Technical Management Processes ---------------------B.5 Organization (Team) Structure -----------------------------------B.6 Other Systems Engineering Concerns ---------------------------

B-1 B-1 B-1 B-1 B-1 B-2 B-2

Appendix C – Trace of Project Management Processes to Life Cycle ----

C-1

Appendix D – Project Tailoring Guidelines --------------------------------------

D-1

Appendix E – Terms and Defin itions ----------------------------------------------

E-1

Appendix F – Acronyms -------------------------------------------------------------Appendix G – Photograph Capti ons-----------------------------------------------Appendix H – “Spiral” Development Process ----------------------------------STS111-383-009 (5-19 June 2002)

F-1 G-1 H-1

Figures

Astronauts Kenneth D. Cockrell (left) and Paul S. Lockhar t, STS -111 mission com- Chapter 2 mander and pilot, participate in one of the 2.1-1 Project management scope-----------------------------------------STS-111 detailed test objectives (DTOs). 2.4-1 Typical development processes for projects ------------------The purpose of DTO 694 is ot produce ultra-pure water from the Shuttle’s fuel 2.4-2 cell Project life cycle phases --------------------------------------------water. This water an c replace manifested 2.5-1 Pre-proposal/proposal/implementation ultra-pure water supplies, and significantly approval process ------------------------------------------------------decrease the mass and volume required 2.6-1 Documentation tree --------------------------------------------------to support biotechnology payloads.

2-1 2-3 2-6 2-9 2-11

Chapter 3 3-1 3-2 3.3-1 3.3-2 3-4 3-5.1

Pre-Phase A advancedanalysis studiesdiagram--------------------------diagram-------------------------Phase A preliminary Phase B system definition diagram------------------------------Phase B preliminary design diagram----------------------------Phase C design diagram --------------------------------------------Phase D development – fabrication and integration stage diagram ------------------------------------------Phase D development – preparation for deployment stage d iagram -----------------------------------------Phase D development – deployment and operational verification stage diagram--------------------------Phase E opera tions diagram ---------------------------------------Off-nominal project termination diagram----------------------Nominal project termination diagram----------------------------

3-16 3-20 3-23 3-23

Chapter 4 4-1 Example of three levels of system of interest-----------------4-2 Example of enabling systems -------------------------------------4-3 Decompo sition of the systems of inter est----------------------4-4 Relationship among needs, goals, and objectives------------4.1-1 Requirements development process diagram -----------------4.1-2 Requirements manage ment process diagr am -----------------4.1-3 Operational concept development process diagram ---------4.1-4 Decomposition process diagram ----------------------------------

4-2 4-2 4-3 4-3 4-5 4-10 4-13 4-16

3-5.2 3-5.3 STS111-318-030 (5-19 June 2002)

3-6 Astronaut Philippe Perrin, STS-111 3-7.1 mission specialist representing CNE S, the 3-7.2 French Space Agency, looks out an aft

3-3 3-5 3-8 3-9 3-12 3-14 3-15

flight deck window Endeavour of .

xv

Table o f Content s 4.1-5 4.1-6 4.1-7 4.1-8 4.1-9 4.1-10 4.1-11 4.1-12 4.1-13 4.1-14 4.1-15 4.1-16 4.2-1 4.2-2 4.2-3 JSC2003-E-02172 (15 January 2003)

4.2-4 4.2-5 An overall view of the Station flight 4.2-6 control room (BF CR) in Houston’s Mission Control Center MC(C). A large screen at 4.2-7 the front of the room shows astronauts4.3-1 Kennet h D. Bowersox and Donald R. 4.3-2 Pettit, Expedition 6 mission commander 4.3-3 and NASA ISS science officer, during the mission’s only scheduled spacewalk. 4.3-4

Feasibility study process diagram--------------------------------Technology planning process diagram -------------------------Design process diagram --------------------------------------------Attainment process diagram ---------------------------------------Integration process diagram ---------------------------------------“Vee” chart -------------------------------------------------------------Technical work and resource management process diagram-------------------------------------------------------Safety and mission success process diagram------------------Control process diagram--------------------------------------------System analysis process diagram --------------------------------Verification process diagram---------------------------------------

4-20 4-24 4-28 4-32 4-36 4-37

Validation process diagram---------------------------------------Reviews process diagram ------------------------------------------Resource manage ment process diagr am -----------------------The planning process dia gram ------------------------------------Documentation and data management process diagram -----------------------------------------------------------------Cost estimating process diagram ---------------------------------Performance measurement process diagram ------------------Schedule management process diagram------------------------Project analysis process diagram ---------------------------------Acquisition management process diagram --------------------Risk management process diagram ------------------------------Configuration management process diagram -----------------Quality management process diagram ---------------------------

4-66 4-70 4-75 4-77

xvi

4-43 4-48 4-54 4-58 4-62

4-80 4-83 4-87 4-92 4-95 4-98 4-102 4-106 4-111


In t ro d u ct io n

Introduction

Chapter 1 Introduct ion

•

This document provides a description of the basic processes and general practice for the development and operation of all projects managed at the Lyndon B. Johnson Space Center (JSC). In addition to the processes and requirements documented here, all projects shall comply with applicable JSC directives and requirements established by applicable law, regulations, Executive Orders, and NASA directives. In the event of a conflict, the NASA directive, Executive Order, regulation, or law (in ascending order) shall have precedence.

•

•

•

Implementing JPC 7120.2,JSC Project Management Council Implementing this document, JPG 7120.3, Project Management: Systems Engineering and Project Control Processes and Requirements Implementing JPD 7120.1,JSC Project Management Policy Aligning the SE processes to be used at JSC with interim Agency guidance and industry standards, practices, and maturity models – such as the Electronic Industries Alliance (EIA)-632,Processes for Engineering a System, the INCOSE Systems

Engineering Handbook, and the Capability Maturity Model Integration (CMMI) for Systems Engineering, Software Engineering, Integrated Product and Process Development , and Supplier Sourcing – and documenting them in this publication. This document therefore combines, in coordination with the JSC Management System and the JSC organizational structure, project management, project control and SE principles and practices. It does this in a fashion compatible with the previously mentioned Agency project management and SE guidelines and directives. In this document, a requirement is identified by a “shall,” a good practice by a “should,” permission by a “may” or a “can,” expectation by a “will,” and descriptive material by an “is.”

Over the changes, last ten years, JSC and NASA have undergone many examples of which include the creation of the Center-level Systems Management Offices and the Headquarters-level Chief Financial Officer’s Cost Analysis Division, an increased emphasis on risk management and the use of probabilistic risk analysis (PRA) and cost assessment requirements description (CARD) documentation. One of the more visible and significant changes is that the Agency has evolved a strategic planning process that is based on a family of Enterprises. JSC has also created new offices and processes to implement Agency, Congress, and White House input and direction. Similarly, NASA program and project development and management have evolved as documented in NASA Procedures and Requirements (NPR) 7120.5B, NASA Program and Project Management Processes and Requirements. The Agency has also developed interim guidance related to systems engineering (SE) as documented in draft NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Processes and Requirements. These changes have been put in place to ensure that programs and projects are not only in concert with the Enterprise efforts, but are also efficiently and consistently planned, budgeted, and executed. Additional guidelines – e.g., risk management, software-independent verification and validation (IV&V), logistics management, and export control – have also been put in place for similar purposes. Another significant change has been that both the Agency and JSC have implemented the International Organization of Standardization (ISO) 9000 Quality Management System. This system is the day-to-day process by which JSC implements the requirement to continually improve Center processes, products, and services, and to use measurable objectives to establish the quality of its work. JSC has documented this in JSC Procedures and Guidelines (JPG) 5335.3, JSC Quality Management System Quality Manual. As part of this continual improvement effort, JSC has made a number of additional critical decisions on project processes and product control. These include: Implementing JSC Policy Directive (JPD) 8090.1, Systems Engineering Policy

1.1 Purpose The purpose of this document is to define Centerwide processes, practices, and product requirements to support the planning, operations, and management of projects at JSC. This document provides overall direction and processes to be followed by all projects and project team members at JSC. 1.2 Appli cability and Scope This document has been developed to ensure a common understanding and documentation of the processes, practices, and procedures that shall be required for development and integration of all hardware and software projects at JSC. These projects include activities in the areas of space flight system development, advanced technology development, advanced studies, institutional support operations, and any combination thereof. It also serves as an informationonly source for activities such as: Basic and applied research investigations that are part of a portfolio (per NPR 7120.5C) Small Business Innovation Research (SBIR) Center Director Discretionary Fund (CDDF) funded projects •

• •

•

1-1

Project Management: SE & Project Control Processes & Requirements

sible and documented in the project management plan (PMP) for approval, as a minimum, and the program commitment agreement (PCA) and program plan, as appropriate.

Space Act Agreements that do not exceed $100,000 (including civil service labor, facilities, and materials cost) • Research and Technology Objectives and Plans The JSC Center Director is accountable for JSC support to projects managed by Agency programs. As such, JSC activities and JSC projects managed by Agency programs shall follow the processes stipulated in this document. Any disagreements that may arise between the requirements of this document and direction provided by the program(s) shall be brought forward to the JSC Engineering Review Board (ERB) •

1.3 1.3.1

1.3.2

for clarification on the potential and levelthe of appropriate risk being assumed. The ERB chairperson program manager will discuss the issue and resolve it. Final resolutions shall be appropriately documented in the project management plan and project-customer agreements (e.g., ITAs, MOUs, and Class 1 deliverables). While basic common processes and general practices are discussed in this document, project managers, working with their project team members, should tailor implementation to the specific needs of th e project consistent with the project scope, visibility, cost, complexity, crit icality, and risk. For purpose s of this document, tailoring should be considered to be a method to encourage innovation and achieve products in an efficient manner while still meeting the expectations of the customer. Tailoring approaches shall be coordinated with all affected parties as early as pos-

1.3.3

1.3.4

1-2

Authority Per NPR 7120.5B, paragraph P2.4, “Each Center is responsible for developing and implementing the Center-level policies, processes, procedures, and requirements necessary to ensure successful program/project execution.” Per NPR 71xx.x (document number not yet assigned), 2.4, “Each Center is responsibleparagraph for developing and implementing Center-level policies, processes, procedures and requirements necessary to ensure successful execution of the processes and requirements according to this document.” Per JPD 8090.1, “The JSC Office of the Chief Engineering is responsible for: 1) Establishing policy, requir ements, and guidelines for systems engineering processes and products for the development and operation ofJSC systems.” Per JPD 7120.1, “The JSC Chief Engineer is responsible for : 1) Serving as the process steward for JSC project management, including development and maintenance of JSC project management procedures and guidelines that are compliant with Agency policies and the JSC quality management system.”

Introduction

1.4

References

1.4.1 External Documents Number Title AD-A319533KKG, Continuous Risk Management Guidebook DTIC#: AD-A319 533\6\XAB ANSI/AIAA G-043Guide for Preparation of Operational Concept 1992 Documents CMMICapability Maturity Model Integration (CMMI) for SE/SW/IPPD/SS Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing

EIA-632

CMMI Project Planning Process Proce sses for Engineering a System

EIA-731.1

Systems Engineering Capability Model

EIA-748A EIA-748-98

Earned Value Management Systems Industry Guidelines for Earned Value Management Systems Institute of Electrical and Electronic Engineers (IEEE) Standard for Application and Management of Systems Engineering Processes Quality Management Systems – Requirements Test Requirements for Launch, Upper Stage and Space Vehicles

IEEE 1220-1998

ISO 9001:2000 MIL-HDBK-340A, Vols. 1 and 2 SP 800-12 SWELT:RM0.2

An Introduction to Computer Security: the NIST Handbook (Web page) Requirements Management Guidebook Analys is of Automated Requirements Management Capabilities

1-3

Paragraph 4.3.2.12

4.1.3.12 1, 4.1.1.6, 4.1.1.7, 4.1.1.10, 4.1.1.11, 4.1.1.12, 4.1.2, 4.1.2.2, 4.1.2.4, 4.1.2.6, 4.1.2.7, 4.1.2.8, 4.1.2.11, 4.1.2.12, 4.1.3.1, 4.1.3.6, 4.1.3.7, 4.1.3.12, 4.1.4.5, 4.1.4.6, 4.1.4.7, 4.1.4.10, 4.1.4.12, 4.1.7.12, 4.1.8, 4.1.8.12, 4.1.9, 4.1.9.2, 4.1.9.5, 4.1.9.6, 4.1.9.12, 4.1.10.6, 4.1.10.7, 4.1.10.12, 4.1.11.12, 4.1.12.6, 4.1.12.12, 4.1.13, 4.1.13.6, 4.1.13.12, 4.1.14.12, 4.1.15.6, 4.1.15.12, 4.3.1.1, 4.3.1.4, 4.3.1.5, 4.3.1.6, 4.3.1.8, 4.3.1.10, 4.3.1.12, 4.3.2, 4.3.2.12, 4.3.3.6, 4.3.3.7, 4.3.3.12, 4.3.4, 4.3.4.6, 4.3.4.7, 4.3.4.12, App. E App. E 1, 4.1.1, 4.1.1.2, 4.1.1.5, 4.1.1.11, 4.1.1.12, 4.1.2.4, 4.1.2.7, 4.1.2.11, 4.1.2.12, 4.1.3.6, 4.1.3.7, 4.1.3.8, 4.1.3.12, 4.1.4.6, 4.1.4.7, 4.1.4.8, 4.1.4.12, 4.1.7, 4.1.7.11, 4.1.7.12, 4.1.8, 4.1.8.7, 4.1.8.12, 4.1.9.2, 4.1.9.5, 4.1.9.6, 4.1.9.12, 4.1.11.12, 4.1.12.6, 4.1.12.12, 4.1.13, 4.1.13.10, 4.1.13.11, 4.1.13.12, 4.1.14.1, 4.1.14.12, 4.1.15, 4.1.15.1, 4.1.15.12, 4.2.5, 4.2.5.1, 4.2.5.12, 4.3.1.6, 4.3.1.7, 4.3.1.9, 4.3.1.12, 4.3.3.12 4.1.10, 4.1. 10.12, 4.1.13.4, 4.1.13.12, 4.3.4, 4.3.4.2, 4.3.4.7, 4.3.4.8, 4.3.4.10, 4.3.4.11, 4.3.4.12 4.2.5, 4.2.5.1, 4.2.5.12 4.2.7, 4.2.7.12 App. E

4.3.4, 4.3.4.12 2.4.2.4 4.3.2.12 4.1.2.4, 4.1.2.7, 4.1.2.11, 4.1.2.12 4.1.14.12, 4.1.15.12


Number

Title Customer-Centered Products

Expert Choice, Inc. (Web page) Fundamentals of Project Management INCOSE Systems Engineering Handbook

Project Management Toolbox Risk Management Guide for DoD Acquisition System Engineering Fundamentals Visualizing Project Management W. Lilly Project Control Study for the National Academy of Public Adminis tration (NAPA)

1.4.2

Paragraph 4.0.1, 4.1.2.4, 4.1.2.7, 4.1.2.11, 4.1.2.12 4.1.5.12 4.2.2, 4.2.2.12 1, 4.1.1.5, 4.1.1.7, 4.1.1.8, 4.1.1.10, 4.1.1.11, 4.1.1.12, 4.1.2.2, 4.1.2.4, 4.1.2.5, 4.1.2.7, 4.1.2.11, 4.1.2.12, 4.1.3.2, 4.1.3.5, 4.1.3.6, 4.1.3.7, 4.1.3.8, 4.1.3.9, 4.1.3.10, 4.1.3.12, 4.1.4.2, 4.1.4.6, 4.1.4.7, 4.1.4.8, 4.1.4.9, 4.1.4.10, 4.1.4.11, 4.1.4.12, 4.1.6.6, 4.1.6.12, 4.1.7, 4.1.7.3, 4.1.7.5, 4.1.7.10, 4.1.7.12, 4.1.8.3, 4.1.8.10, 4.1.8.12, 4.1.9.5, 4.1.9.10, 4.1.9.11, 4.1.9.12, 4.1.11.12, 4.1.12.10, 4.1.12.11, 4.1.12.12, 4.1.13.9, 4.1.13.11, 4.1.13.12, 4.3.1.7, 4.3.1.12, 4.3.3.12, 4.3.4.6, 4.3.4.12 4.2.2, 4.2.2.12, 4.2.4, 4.2.4.12, 4.2.5, 4.2.5.12, 4.2.6, 4.2.6.12 4.3.2.12 4.1.3.10, 4.1.3.12, 4.1.4.2, 4.1.4.5, 4.1.4.10, 4.1.4.12, 4.1.13.12 4.2.2, 4.2.2.12, 4.2.6, 4.2.6.12 2.1

NASA Documents

Number KHB 1700.7 NASA-GB-1740.1396 NASA-STD-2100-91 NASA-STD-2201-93 NASA-STD8719.13A NASA-STD-8739.8 NASA-STD-8739 series

NMI 7234.1 NPD 1280.1 NPD 1440.6G NPD 1441.1D NPD 2190 NPD 2820.1 NPD 7330.1F

Title Full Co st Initiative Agencywide Implementation Guide (Web page) KSC Payload Ground Safety Handbook NASA Gui debook for Safet y Critical Software – Analysis and Development NASA Software Documentation Standard Software Assurance Standard Software Safety NASA Technical Standard

Paragraph 4.2.1, 4.2.1.12, 4.2.2.7

Software Assurance

4.1.11.6 4.1.11.12

Next-Generation Space Tele scope (NGST) (Web pag e) Facilities Utilization Program NASA Ma nagement System Po licy NASA Record s Management NASA Record Re tention Schedule NASA Ex port Control Progr am NASA Softwar e Policies Approval Authorities for Facilities Projects

4.1.6.6, 4.1.6.12

1-4

4.1.11.6, 4.1.11.12 4.1.11.6, 4.1.11.12 4.1.11.6, 4.1.11.12 4.1.11.1, 4.1.11.6, 4.1.11.12 4.1.11.6, 4.1.11.12

2.5.3.2 4.3.4, 4.3.4.2, 4.3.4.12 4.2.6, 4.2.6.12 4.2.3, 4.2.3.12 2.7.3.8 2.6, 4.1.11.6 2.4.1.4, 2.6

Introduction

Number NPD 7500.1 NPD 8010.2 NPD 8010.3 NPD 8730.4 NPD 8800.14B NPD 8810.2 NPD 8820.2A NPD 8820.3 NPD 8831.1D NPD 9501.3A NPR 1440.6G NPR 2190.1 NPR 71xx.x

Title Program/Project Logistics Metrics System Notification of Intent to Terminate Operating Space Systems NASA Software Independent Verification and Validation (IV&V) Policy Policy for Real Property Management Master Planning for Real Property Design and Construction of Facilities Facility Sustainable Design Management of Institutional and Program Facilities

and Related Equipment Earned Value Performance Management Recor ds Mana gement Export Control NASA Systems Engineerin g Processes and Requirements (document number not yet assigned)

NPR 7120.5B

NASA Program and Project Management Processes and Requirements

NPR 7120.5C

NASA Program and Project Management Processes

NPR 8000.4

and Requirements (Draft) Risk Management Procedures and Guidelines

NPR 8705.2

Human-Rating Requirements and Guidelines for Space Flight Systems

1-5

Paragraph 2.6 2.6 2.6, 3.7, 3.7.5.2, 3.7.7 2.6, A.20 2.4.1.4 2.4.1.4 2.4.1.4, 2.6 2.4.1.4, 2.6 2.4.1.4, 2.6 4.2.5, 4.2.5.1, 4.2.5.12 2.6 2.6 1, 1.3, 4.0.1, 4.1.1, 4.1.1.1, 4.1.1.11, 4.1.1.12, 4.1.2, 4.1.2.1, 4.1.2.4, 4.1.2.7, 4.1.2.11, 4.1.2.12, 4.1.3, 4.1.3.1, 4.1.3.7, 4.1.3.12, 4.1.4, 4.1.4.1, 4.1.4.7, 4.1.4.12, 4.1.5, 4.1.5.1, 4.1.5.12, 4.1.6, 4.1.6.1, 4.1.6.6, 4.1.6.12, 4.1.7, 4.1.7.1, 4.1.7.2, 4.1.7.5, 4.1.7.8, 4.1.7.12, 4.1.8, 4.1.8.1, 4.1.8.2, 4.1.8.4, 4.1.8.5, 4.1.8.12, 4.1.9, 4.1.9.1, 4.1.9.12, 4.1.10, 4.1.10.1, 4.1.10.2, 4.1.10.12, 4.1.11, 4.1.11.1, 4. 1.11.12, 4.1.12, 4.1.12.1, 4.1.12.12, 4.1.13, 4.1.13.1, 4.1.13.12, 4.1.14, 4.1.14.1, 4.1.14.12, 4.1.15, 4.1.15.1, 4.1.15.12, 4.1.16, 4.1.16.1, 4.1.16.12, 4.3.1, 4.3.1.1, 4.3.1.2, 4.3.1.6, 4.3.1.12, 4.3.2.1, 4.3.2.12, 4.3.3, 4.3.3.1, 4.3.3.12, 4.3.4, 4.3.4.1, 4.3.4.12, App. E 1, 1.3, 2.4.2.4, 2.6, 3.2, 3.2.7, 3.3, 3.3.7, 3.4, 3.4.7, 3.5, 3.5.7, 3.6, 3.6.7, 4.1.6, 4.1.6.1, 4.1.6.3, 4.1.6.12, 4.1.9.6, 4.1.9.12, 4.1.10.12, 4.1.11.1 , 4.1 .11.2, 4.1.11.12, 4.1.12.10, 4.1.12.12, 4.1.13, 4.1.13.12, 4.1.14, 4.1.14.12, 4.1.15.12, 4.2.1, 4.2.1.12, 4.2.4, 4.2.4.12, 4.3.1, 4.3.1.1, 4.3.1.2, 4.3.1.3, 4.3.1.6, 4.3.1.12, 4.3.2.5, 4.3.2.12, 4.3.3.12, 4.3.4, 4.3.4.12, App. A, A.18, B.4, App. E App. E 2.6, 4.3.2, 4.3.2.6, 4.3.2.10, 4.3.2.12, A.18 4.1.7.6


Number NPR 8820.2E NPR 8831.2D NPR 9501.3 NSTS 13830 NSTS 1700.7 NSTS 1700.7 Addendum NSTS 5300.4(1D -2)

Title Facility Project Implementation Guide Facilities Maintenance Management Earned Value Management Implementation on NASA Contr act Payloa ds Safety Review and Data Submittal Requirements Safety Policy and Requirements for Payloads Using the STS Safety Policy Requirements for Payloads Using the International Space Station Safety, Reliability, Maintainability, and Quality

RP 1358

Provisions for the Space Shuttle Program Systems Engineering “Toolbox” for Design-Oriented Engineers

SP 6103 SP 6105

NASA Readings in Project Control NASA Systems Engineering Handbook

SSP 41173 SSP 50038 SSP 51079

WSP 09-0014

Space Station Program Quality Assurance Requirements Computer-Based Control System Safety Requirements International Space Station Program Risk Management Plan NASA Cost Estimating Hand book 2002 (Web page) Probabilistic Risk Assessment Procedures Guidebook for NASA Managers and Practitioners Technology Readiness Levels: A White Paper Project Management

1-6

Paragraph 2.4.1.4, 2.6 2.4.1.4, 2.6 4.2.7, 4.2.7.12 4.1.11.6, 4.1.11.12 4.1.11.6, 4.1.11.12 4.1.11.6, 4.1.11.12 4.1.11.6 2.6, 4.1.1.11, 4.1.1.12, 4.1.2.4, 4.1.2.7, 4.1.2.11, 4.1.2.12, 4.1.5.10, 4.1.5.12, 4.1.6.10, 4.1.6.12, 4.3.2.10, 4.3.2.12 2.3, 4.2.1, 4.2.1.12, 4.2.4, 4.2.4.12 2.4.2.4, 2.6, 3, 3.1, 3.1.7, 3.2, 3.2.7, 3.3, 3.3.7, 3.4, 3.4.7, 3.5, 3.5.7, 3.6, 3.6.7, 4.1.1.11, 4.1.1.12, 4.1.2.4, 4.1.2.7, 4.1.2.11, 4.1.2.12, 4.1.4.2, 4.1.4.3, 4.1.4.7, 4.1.4.10, 4.1.4.12, 4.1.5.1, 4.1.5.12, 4.1.6.4, 4.1.6.12, 4.1.7, 4.1.7.3, 4.1.7.6, 4.1.7.8, 4.1.7.12, 4.1.8.5, 4.1.8.6, 4.1.8.7, 4.1.8.12, 4.1.9.3, 4.1.9.6, 4.1.9.7, 4.1.9.12, 4.1.10.3, 4.1.10.5, 4.1.10.10, 4.1.10.12, 4.1.11, 4.1.11.1, 4.1.11.6, 4.1.11.12, 4.1.12.2, 4.1.12.12, 4.1.13, 4.1.13.2, 4.1.13.3, 4.1.13.6, 4.1.13.7, 4.1.13.10, 4.1.13.12, 4.1.16.1, 4.1.16.2, 4.1.16.4, 4.1.16.5, 4.1.16.6, 4.1.16.7, 4.1.16.8, 4.1.16.12, 4.2.4, 4.2.4.12, 4.2.6, 4.2.6.12, 4.3.1.5, 4.3.1.7, 4.3.1.10, 4.3.1.12, 4.3.3, 4.3.3.3, 4.3.3.12, 4.3.4.3, 4.3.4.12, App. E 4.1.11.6 4.1.11.6, 4.1.11.12 4.3.2.12 4.2.4, 4.2.4.12, 4.2.7, 4.2.7.12 4.3.2.12 4.1.6.12

Introduction

1.4.3 JSC Documents Number Title AG-CWI-001 JSC Lessons Learned Process JSC Exp ort Compliance CWI J29W-01 JMI 2314.2L Identifying and Processing JSC Scientific, Technical and Administrative Documents JMI 5150.5F Processing of JSC Procurements Through Del ivery, Acceptance and Payment Stages JMI 5151.5B Management of Support Contracts JSC Pro ject Management Cou ncil JPC 7120.2 JPD 1382.1H Relea se of Information to News Media Freedom of Information Act (FOIA) JPD 1382.4K JPD 2200.1A JPD 5335.1 JPD 7120.1 JPD 8090.1 JPG 1440.3 JPG 1700.1 JPG 5335.2 JPG 5335.3 JPG 8080.5 JSC Announcement 02-035 JSC-24937 LA-CWI-01 SLP 4.6 SLP 4.20

1.5 None.

Relea se of JSC Scientific and Technical Information to External Audiences JSC Quality Policy JSC Project Management Policy JSC Systems Engineering Policy JSC Fi les and Reco rd Management Procedures JSC Safety and Total Health Handbook Space Act Agreements JSC Quality Management System Quality Manual JSC Design and Procedural Standard Manual Charter of the Engineering Review Board JSC Earned Value Management Handbook Limited Life Time Cycle Items Program Requirements Document Budget Planning Process Procurement Process Measurement and Improvement JSC Cost Estimating (Web page)

Cancellation

1-7

Paragraph 4.3.4.6, 4.3.4.12 2.7.3.8 4.2.3, 4.2.3.12 4.3.1.12 4.3.1.12 1, 2.5.3.3 2.7.3.17 2.7.3.17 4.2.3, 4.2.3.12 4.3.4, 4.3.4.12 1, 1.3, 2.6 1, 1.3, 2.6 2.7.2.10, 4.2.3, 4.2.3.12, 4.2.6, 4.2.6.12 4.1.11.6, 4.1.11.12 4.3.1.1, 4.3.1.3, 4.3.1.12 1, 4.1.11.6, 4.3.4, 4.3.4.3, 4.3.4.12 4.1.11.6 2.5.3.1 2.6 4.1.11.6, 4.1.11.12 4.2.1.6 4.3.1.1, 4.3.1.3, 4.3.1.12 4, 4.2.1.10, 4.3.3.10, 4.3.3.12 4.1.12.11, 4.1.13.12


O v e r v ie w o f P ro je c t M a n a g e m e n t a t JS C

Overview of Project Management at JSC

Chapter 2 Overview of Project Management at JSC

(product or service). The emphasis is on achieving stakeholder functional, physical, and operational performance requirements in the intended use environments over the planned life of the system and within cost and schedule constraints. SE includes the engineering and technical management processes that consider the interface relationships across all elements of the system or other systems, or as part of a larger system. The SE function systematically considers all technical aspects of a project in making design choices and is a continuous, iterative process that is used throughout the life cycle of the

2.1 Scope Project Management is the function of planning, overseeing, and directing the numerous activities required to achieve the requirements, goals, and objectives of the cust omer within specified cost, quality, and schedule constraints. The scope of project management includes two major areas of emphasis, both of equal weight and importance. These areas are systems engineering (SE) and project control. It is critical for the success of the proje ct that the project management team understands that both major areas must be successfully implemented and contin ually used throughout the project life cycle. Definitions for SE and project control, as well as the main content areas under each, are depicted in Figure 2.1-1.

project. These iterative efforts result in theand best system architecture, design, manufacturing, operations possible for the given cost and schedule constraints. The success of every Johnson Space Center (JSC) proj ect is highly dependent on the SE process being properly exercised at all levels of design and across all phases of the project life cycle.

Project Management Systems Engineering A disciplined approach for the definition, implementation, integration, and operation of a system (product or service). The emphasis is on achieving stakeholder functional, phy ical, and op eration al performance requirements in the intended use environment over its planned life. SE includes the engineering processes and technical management processes that • Configuration management consider the interface relationships across • Risk all elements of the system, other systems, management 1 or as part of a larger system. • Acquisition • Systems requirement development management and management • Quality • Operations concept development •

• •

1NASA 2From

Systems architecture development management (decomposition, feasibility studies, design, attainment, technology planning, systems analysis) Integration, verification, validation, safety, and mission success SE management (technical work and resource management, control, reviews

Project Control Total management process of establishing and maintaining project baselines for project content, 2 scope, configuration, schedule, and cost. • Resource management • Planning • Project analysis • Docum entation and dat a managem ent • Schedule management • Performance measurement • Cost estimating

Systems Engineering Working Group Definition, Draft SE NPR 12/2002. W. Lilly Project Control Study for the National Academy of Publication Administration (NAPA), 1989.

Figure 2.1 -1. Project management scope.

2.2 Systems Engineering SE is a disciplined approach for the definition, implementation, integration, and operation of a system

2.3 Project Control Project control is the total management process o f establishing and maintaining project baselines and

2-1


effectively supporting the project manager in meeting the overall objectives of the project. It functions in both a proactive and a reactive context. The proactive aspects of p roject control include baseline control of project processes and control of the project management plan and i ts changes ov er the life cycle. An example of such a proactive aspect might be identification of process trends that may eventually lead to problems in meeting cost or schedule. Reactive as pects of project control include performance measurement and control, and management of variances to the project cost and schedule. This includes taking corrective

• •

Institutional project Operations project

2.4.1.1

Space flight system development projects Space flight system development projects are generally those hardware (H/W) and/or software (S/W) proje cts that result in an end product for flight into space. These items may include products for flight experiments, flight crew equipment, or detailed test objectives (DTOs). A common characteristic of a space flight system

actions for these The success ofvariances. projects depends on disciplined attention to numerous planning, resource, and scheduling variables, and the integration and optimization of interrelated activities. Project control ensures that project objectives are met by monitoring and measuring progress regularly to identify variances from plan. Corrective action can then be taken when necessary. For example, systematic attention to the implications of variances between planned baselines and actual performance on projects is critical to taking early remedial action, thereby reducing costly delays and increasing the probability of achieving success. Additional detailed background discussions on project control experiences can be found in Special Publication (SP) 6103,NASA Readings in Project Control .

development is often a “waterfall” ment process,project as shown in Figure 2.4-1. develop-

2.4

2.4.1.3

2.4.1.2

Advanced technology development projects Advanced technology development projects are those H/W and/or S/W projects characterized by an end product for use in test or demonstration of a design concept(s). These intended final products may or may not result in a product to be operated in spa ce or on an aircraft. The development of these products can be characterized by a “spiral” development process, as shown in Figure 2.4-1. A larger view of the “spiral” detail is provided in Appendix H. Examples of this type of project at JSC include Robonaut and the variable specific impulse magnetoplasma rocket (VASIMR).

Project Types, Approaches, and Life Cycle Phases This section addresses two related but distinct subjects. First, in Section 2.4.1, the various types of project implementations at the center are presented along with their defining characteristics. This is followed by a discussion, in Section 2.4.2, of the important subject of identifying and selecting the appropriate project approach to improve the likelihood of achieving project success. The project life cycle is presented in Section 2.4.3.

Science research, applied research, and advanced studies Science research and applied research projects are efforts that are intended to answer, or at least to address, fundamental research or development questions. Basic research can thus be understood to have no direct or for eseen applications. Applied re search is most commonly an effort to develop advanced prototype H/W and/or S/W. Advanced studies examine the feasibility of approaches to a design problem or an operational alternative. Examples of advanced studies include studies performed to support strategic planning formulation. Since these final products are commonly developed based on a “pay as you go” level of effort (LOE) process tied to funding availability, the development effort may vary from year to year. Because of the diverse scope and unique selection and review process for fundamental, applied research and advanced studies projects, a modified management approach is warranted. The end goals of research projects often do not fit the life cycle definitio ns shown here. However, sub-projects within a research project may fit within these requirements. Examples include the development of research facilities, test rigs, mockups, and other research equipment.

2.4.1 Project Types A discussion of the types of project s at JSC needs to be prefaced with an understanding that most, if not all projects, involve one or more of the listed project types at some point during the project life cycle. The determination of what type of project designation is most appropriate is based on the intended final product and the project approach used to complete it. The list of project “types” includes: • Space flight system development project • •

Advanced technology development project Science research, applied research, or advanced studies project

2-2


TYPICAL DEVELOPMENT PROCESS

PROJECT TYPE

Space Flight System Development

“Waterfall” development

Advanced Technology Development

“Spiral” development based on technology readiness level (TRL)

Science and Applied Research

“Pay as you go” level of effort (LOE) typically sub-TRL 3 activities

Institutional

Either 1) Waterfall 2) Spiral 3) LOE

Operations

Either 1) Waterfall 2) Spiral 3) LOE

Figure 2.4 -1. Typical development processes for projects. 2.4.1.4 Institutional Institutional projects are the buildings, site infrastructure, and H/W and/or S/W development efforts that culminate in an end pro duct that supports a mission-critical infrastructure or Center-operational function. Examples of this project type include typical construction of facilities (CofF), Center- funded construction, infrastructure modification (e.g., telephone system), or education efforts (e.g., KC -135 Student Program, etc.). It also includes technical support sy stem development such as the design and data management system (DDMS), Mission Control Center (MCC) local area network (LAN) upgrade, or aircraft H/W and S/W development efforts. The CofF and associated support projects have a unique feature among institutional project types since they already have an existing set of project management processes, practices, and requirements. These include: • NASA Policies and Directives (NPD) 7330.1F, Approval Authorities for Facilities Projects • NPD 8800.14B, Policy for Real Pr operty Mana gement • NPD 8810.2, Master Planning for Real Property • NPD 8820.2A, Design a nd Construction of Facilities

NASA Procedures and Requirements (NPR) 8820.2E, Facility Project Implementation Guide • NPD 8831.1D, Management of Institutional and Program Facilities and Related Equipment • NPR 8831.2D, Faciliti es Maintenance Mana geme nt • NPD 8820.3, Facility Sustainable Design In addition, the current versions of NPR 8820.3 and NPR 8820.2E require an engineering-pr ocurement-construction (EPC) approach to facility delivery, commonly referred to as a “design-bid-build” process using performanc e-based, fixed-price contract s. Facilities and associated support projects shall be exempt from the requirements documented herein, with the exception of the various project management forums discussed in Section 2.5, because o f the EPC approach, the existing laws and regulations concerning design and construction s tandards, and the existing body of knowledge and practice in this area. •

2.4.1.5 Operations Operations projects are those building, site infrastructure, and H/W and/or S/W development efforts that provide a foundation for future development and research to use or build on. This project type is typic ally characterized by the following major points:

2-3


• •

•

• •

The vast majority of the life of the project is spent in the operations phase. The project product functions as a “facility” to allow additional H/W and/or S/W to be added, where this new S/W could accomplish an asyet-unspecified new mission. The project management team makes decisions on a life cycle basis, as opposed to a near-te rm problem-reso lution focus. Activities such as a preplanned product improvement (P3 I) effort may be part of the core project. The project management process has a clear un-

• • • •

•

An agreed -to-, documented minimum project documentation/deliverables list An agreed-to, documented minimum content for each project documentation/deliverable An absolute minimum set of requirements for the project (both stated and implied) An extremely aggressive effort to minimize requirement changes/additions over the life of the project A documented, agreed-to minimum amount of reporting and statusing to customer, Center, Agency, or external forums

•

derstanding of not precluding future as-yet-unspecified H/W and/ or S/W modifications. It should be understood that while the operations project H/W and/or S/W may have been developed under a space flight system waterfall process, an advanced technology spiral process, or even an LOE process, the project type is considered “operations” due to the role of a support facility for additional future capabilities. Examples of this project type in clude the Space Station Training Facility, the Hubble Space Telescope, and, at a program level, the Space Shuttle Program and the International Space Station Program.

Each technical area should include technically experienced team members who are capable of successfully working with others • A rapid but well-documented, streamlined change order review, approval, and implementation process • A rapid but well-documented H/W and/or S/W modification process • Collocation of the entire team to the greatest extent possible • Maximum use of information technology (IT) resources to increase the productivity of each team member The project approach is developed by carefully considering, discussing, and selecting from several sets of supportive options. Elements of project approach to consider include: • Staffing • Type of contract

2.4.2 Project Approaches Given the project need and real-world constraints, the project team, stakeholders, and customer must identify the project approach that will most likely achieve success. It is critical that di scussions of proj-

• •

ect include all stakeholders and customers, andapproach that consensus results are formally documented in the project management plan (PMP) prior to authorization to proceed (ATP). * (See Section 2.5.3.3 for a discussion of the ATP process.) Development and implementation of the approach of the project is the responsibility of the project manager and the project management team. For JSC projects, some characteristics for success should be implemented t o the maximum extent pos sible. These include: • The maximum use of contractor documentation and processes, once these have been determined to meet or exceed government-equivalent items, for contractor-supported/NASA-managedprojects • A very close contractor/NASA working relationship for all team members, especially including the NASA contracting officer, for contractorsupported/NA SA-managed projects

Magnitude Implementation approach • Degree of implementation of th e characteristics for success previously mentioned • Customer desires The potential bre adth of answers to these discussions clearly shows the wide variation possible in many aspects of the project (e.g., deliverables), and the re sulting impact to project schedules and resources.

*

2.4.2.2 Type of contract If the project requires contractor support, the next question that needs to be address ed is the type of contract to be used.

2.4.2.1 Staffing One of the first project approach discussions shall be the level of civil service involvement. This would include whether the project will be a governmentfurnished equipment (GFE)/data project (i.e., acc omplished solely by civil service technical development), a con tractor-devel oped/NASA-managed project, or a project that is a combination of both.

ATP is a formal approval provided by the JSC Project Management Council (PMC) to implement a JSC project. This approval marks a commitment by the Center to execute the project within the plans and resource envelopes authorized at the time approval is given.

2-4


2.4.2.3 Magnitude Still another supportive option to consider in developing the project approach is the overall life cycle cost estimate for the project. A p roject estimated to cost less than $1M could, and probabl y should, have a simpler project management approach than a project costing greater than $10M. The selected project approach should be tailored to effectively manage and achieve the individual project. This could include reduced project team size, increased use of Web-based SE and project control applications, increased use of IT resources to support project decision making, re-

PMP, acceptance test plan, system documentation, etc.). It b egins at Pre-Phase A or Phase A and continues on until termination of the project. A tailored baseline approach is generally the default approach for institutional and operational projects based on NPRs and NPDs for facilities. b) X-project approach – An X-project approach is an option when t he project management an d the customer are willing to accept an increased level of risk, above that of the baseline approach, in meeting cost, schedule, and performance require-

duced number oflist project deliverables, reduced of the agreed-to of project deliverabl es, etc.content Dis cussion of the budge t-driven project tailoring should be a significant factor in the development of the PMP, schedules, and deliverables. For example, for a small project under $1M it may be technically acceptable to combine the Preliminary Design Review (PDR) and Critical Design Review (CDR). In contrast, a large project greater than $10M may require not only a PDR and a CDR, but also H/W PDRs and CDRs separate from S/W PDRs and CDRs. In that case, integrated system PDRs and CDRs would be required as well. As the reader call tell, the budget-driven project tailoring approach is a key discussion when planning and defining a project.

ments for is theappropriate project. Normally, fast-i paced approach when the this project ncre mentally builds on past development efforts and pushes the technological boundaries in only one or two well-defined areas. Typically, X-project types exhibit all of the characteristics for project success discussed earlier. c) Protoflight approach – A protoflight approach is an option to consider when the project/program is also willing to accept an increased level of risk above the baseline approach, and when there are other factors that would make non-baseline approaches desirable . An example of this might be the need to develop a “quick reaction capability” to solve an urgent problem within an operational system. A protoflight approach requires a test program that combines the objectives of the qualification and acceptance test programs with the und erstanding that all protoflight components and assemblies are intended for subsequent flight use. The protoflight approach uses agreed-to and documented reduced test levels, cycles, and/or durations from the standard qualification test requirements. This is intended to allow the protoflight-tested H/W to be used later for flight. This approach is not intended, nor it is acceptable, to be used as a standard lower-cost, faster alternative to the baseline qualification and acceptance test programs. A protoflight approach has a higher level of technical risk approach as compared to a full qualification test program due to there being no demonstrated flight duration capability (i.e., number of cycles, or time or operation or exposure to the service environment) and, in some cases, lower demonstrated margins over the service environment extremes. A key characteristic of a protoflight approach is that there is a signifi-

2.4.2.4 Implementation approach For space flight systems and advanced technology development projects, the project management team shall consider whether the project approach is a “ba seline” approach, an “X-project” approach, a “protoflight” approach, or a “protoqual” approach. Each of these approaches is discussed further in this document. This document focuses primarily on the bas eline approach. It shall be considered the default standard approach to be used by JSC projects. Although the other approaches are acceptable alternatives, the rationale for any alternate tailored approach must be documented in the PMP. It is of special importance, however, that the project team understands that use of other than a baseline approach needs to be discussed and concurred with by the customer, directorate, and Center management as early as possible in the project formulation efforts and prior to AT P. a) Baseline approach – A baseline approach can be considered to be a project following a “standard” life cycle and providing a complete project deliverables set such as is discussed in SP 6105, NASA Systems Engineering Handbook , and the latest versio n of NPR 7120.5B , NAS A Program and Proj ect Manag ement Processes and Requirements . This includes planning and documentation development (e.g., trade studies,

cant amount of discussion with the customer prior to accepting this higher-risk approach a s documented in the PMP. d) Protoqual approach – A protoqual approach is another i ncreased-risk alternative approac h

2-5


from the baseline flight qualification and acceptance testing approach. A protoqual approach is very similar to a protoflight approach, except that a modified qualification test program is conducted only on a single item, and that test item is considered available for flight. The normal full acceptance test program is then conducted on all other items intended for flight. Additional information regarding both the prot oflight and the protoqual approaches can be obtained in MIL-HDBK-340A, Vols. 1 and 2, Test Requirements for Launch, Upper Stage

the Phase A goals and objectives may be the Announcement of Opportunity (AO) the researcher is responding to, while for a spac e flight system development project goals and objectives may be provided as part of the Enterprise strategic plans. A nothe r example is the risk management plan. The researcher will follow the same risk management process called out in Section 4.3.2; however, it may be documented as an integral part of the research plan developed in support of the effort. Detailed discussions of the various life cycle phases are provided in Chapter 3, Project Life Cycle

and Space Vehicles .

Requirements.

2.4.3 Project Life Cycle Phases All JSC project activities shall use the same project life cycle phase template to manage their efforts. This template shall consist of an interval-based approach, defined by the completion of various activities and products, as well as successful completion of the respective “control gate” at the end of the stage or phase. This control gate will be a defined management and/ or technical milestone in the development of the project and will be document ed in the PMP (see FIG. 2.4-2). Documentation of these life cycle phases, their respective activities and products, and their control gate serves as a common template for project management efforts throughout the life of the project. Because of the wide diversity of project types at JSC, it is important to understand the intent behind each activity, phase, and stage to identify the applicable processes and control gates. While the terminology may not be identical across all project types, the intent is the same. For example, for research projects,

Control Gates Life Cycle Phase

Pr e-Phase A (Advance d Studies)

Stage

ProjectFeasibility

Objective

– Understand the customer – Identify feasible alternatives

Phase A (Preliminary Analysis)

Phase B (Definition)

System SystemDefinition Definition

Phase C (Design)

Phase D (Development)

Phase E (Operations)

Preliminary Fabrication & Preparation Deployment Design Final DesignIntegration for & OperationalOperations Disposal Deployment Verification

Analyze project – Analyze – Perform – Perform Manufacture Prepare requirements system preliminary final design & assembly system for – Establish optirequirements design – Integration & deployment mum architecture – Establish test optimal system – Verification & design acceptance

Figure 2.4 -2. Project life cycle phases.

2-6

– Conduct Conduct – Decommission deploym ent & operation or dispose of operational system verification


2.5 Project Management Forums JSC projects may have several different forums that provide management and technical oversight. The initial baseline proj ect management oversight forum shall be the JSC PMC until formally delegated to a lower-level board. However, to the greates t degree possible, the Center management team will attempt to delegate oversight to the lowest possible board, thus putting the management and technical oversight as close as possible to the project a nd its efforts. Project managers and project teams must under-

2.5 .3 Cent er-level Forums 2.5.3.1 JSC Engineering Review Board (ERB) The JSC ERB charter and membership are documented in JSC Announcement 02-035, Charter of the Engineering Review Board . The JSC ERB ensures consistent application of policies, guidelines, processes, s tandards, and requirements as related to SE across JSC. The Board also evaluates new program and institutional initia tives, ensuring consistency with the Center’s strategic objectives. Further, the Board provides the Center Director a means to ensure that viable project trade- offs and decisions are made. The

stand that: • Projects may be required to report to centerlevel forums • Projects may be required to report to programlevel forums. • Projects may be required to report to directoratelevel forums. • Projects may establish their own forums − At and across the project level. − At and across the system level. − At the subsystem level. There are many different forms a forum can take. For example, • Management councils • Management boards • Review boards • Control boards • Technical working groups The forums used and defined by the project shall

ERB functionsreview in concert with the JSC PMC, ing a technical capability; however, ERBprovidendorsement is not a prerequisite to a JSC PMC presentation or decision. Types of ERB presentat ions include: project status/ overview presentations, technical issueresolution presentations, Center process improvement initiative presentations, project pre -proposal authorization presentations, and project implementation approval presentations. Center project management-related process improvement initiatives are presented to the ERB for approval and status since the Board is responsible for ensuring consistent application of Center processes. ERB project pre-proposal authorization presentations may be required, by direction of the Center PMC. This would occur prior to Center PMC pre-proposal authorization. For projects requiring Center PMC ATP, project implementation approval presentations must be approved by the ERB. This approval reflects an ERB decision as to whether the system and its operation are well enough understood to warrant design and acquisition of the end items. Direction within the purview of the ERB may result during any presentation, and may require further coordination with the customer and stake holders . Any changes affecting the PMP or projectcustomer agreements shall be documented.

be defined in the PMP. 2.5.1 Project-level Forums The designation of th e project-specific boards is defined at the discretion of the project manager and project management team as they see fit to ensure that project needs, goals, and objectives are satis fied. The project team may also establish technical forums down and across the project organization to communicate, resolve, and concur on technical aspects of the system. In both cases, some form of these boards should exist over the entire life cycle of the project.

2.5.3.2 JSC Facility Review Board (FRB) The FRB provides senior management review and assessment of proposed facility and facility-associated support projects and functions as a Facilities Utilization Review Board in accordance with NASA Management Instruction (NMI) 7234.1. The responsible office is Center Operations with membership from across the JSC directorates. The FRB charter http://serveris at: mpo.arc.nasa.gov/Services/CDMSDocs/Centers/JSC/Dirs/JP G/JPG1107.1AC4.html . The Board functions as a management review forum for facilities and associated support project types, as dis-

2.5.2 Directorate-level Forums Each directorate may have a unique number of technical and management boards, board structures, and placements within the organization deemed appropriate to manage their projects. One option for delegation of management oversight from the JSC PMC is to a directorate-level management board.

cussed in Section 2.4.1. It shall review all proposed facility and facility-associated support projects, and recommend to the PMC a primary project oversight forum for these project types. If delegated by the PMC, the FRB functions as the primary oversight forum for this project type.

2-7


2.5.3.3 JSC Project Management Council In relation to JSC projects, the JSC PMC is the highest Cente r-level decision -making bo dy, and it exists to ensure JSC project success. A detailed dis cussion of the JSC PMC applicability, functions, and membership is defined in JPC 7120.2. Because of the number of JSC projects, not all will be reviewed on a regular basis by the JSC PMC. Some shall be formally delegated, in writing, to a directorate-level project management board. However, any JSC project, whether delegated to a directorate board or not, shall be re quired to provide a status to the JSC PMC if

support service projects; (2) approve impl e mentation of a project; and (3) for proje cts that have given the ATP, concur with continued development and implementation of the project, auth orize or enable the corrective action ne ces sary to mitigate unfavorable impacts during project development, or terminate the project (FIG. 2.5-1). 2) Pre-proposal Approval Process – The purpose of the pre-proposal appro val process is to characterize for the JSC PMC any perceived business opportunities in which JSC may want to partici -

requested by therule, JSCJSC PMC chairperson. As a general projects meet with the PMC to receive formal ATP as defined in the PMC preproposal, proposal, and implementation process out lined in Section 2.5.5.1. Once established, projects meet with the PMC to present status on an agreed-to basis. Other project topics may be covered at the discretion of the JSC PMC chairperson. Where the project manager for a JSC project is resident in a program office, the JSC PMC shall be limited to reviewing only the JSC support to th at projec t. In this case, the presenter need not be the project manager. For thos e projects where the project manager is resident in a directorate, the JSC PMC will review the full project scope, including cost, technical, and schedule aspects. In this case, the presenter should be the project manager. 2.5 .3. 3.1 JSC Project Managemen processes

pate. This revi of ewthe occurs as soonrequest as sufficient understanding customer’s and resources required is available. It occurs before the concept review mile stone in Pre- Phase A. The discussion at the JSC PMC will be focused around four major points. These points are: • Whether the project being proposed is within the JSC mission and goals • Whether there is the appropriate level of JSC support available to provide a reasonable probability of success for the pre -proposal and proposal development effort • What the estimated costs for the pre-proposal and proposal efforts are, and what funding sources are available • Whether this pre-proposal and proposal development effort was requested by a NASA program A favorable outcome of this JSC PMC review results in approval to begin a pre -proposal effort. No set criterion is established to define, in advance, whether delegation to a lower-level directorate board should be done. However, at the sa me time as the JSC PMC provides pre proposal approval, the project may formally request delegation to a lower-level board. The information requested is minimal in order that JSC PMC decisions may be timely; however, the information must provide assurance t hat there has been a complete and thorough as sessment of all resources necessary to successfully complete the p re-proposal an d proposal development effort. For facility and facilityassociated support projects, the JC PMC shall review the recommendations of the FRB and decide on the appropriate project review board. If the pre-proposal and/or proposal efforts were specifically requested in writing by a NASA program, the pre-proposal team shall immediately proceed without waiting for JSC PMC approval and shall report their initiation of efforts at the earliest possible JSC PMC . Similarly, if the pre proposal effort was not requested by the program but can be funded by int ernal directo rate funds

t Counci l

1) General Process Overview – The JSC PMC chairperson convenes the PMC quarterly as a minimum. The JSC PMC secretary coordinates requests for special JSC PMCs with the JSC PMC membership. The results of the JSC PMC discussions and assessments are documented in the form of minutes, findings, and actions. Outside-of-board (OSB) decision making by the JSC PMC chairperson is not the preferred process and is used on an exception basis only. All OSB decisions are documented in writing and provided to the JSC PMC membership by the JSC PMC secretary at the earliest opportunity. Unless otherwise documented herein, OSB activity is limited mainly to only time-critical decisions. The following paragraphs de fine the standard JSC PMC milestones on which the JSC PMC bases its deliberations and d ecisions regar ding the initiation or continuance of projects. The JSC PMC makes three major decisions in the life cycle of a project. These are to: (1) pursue new business by initiating or concurring on preproposal/proposal activity for development or

2-8


Is it a facility or facilityassociated project?

Project pre-proposal discussion at directorate(s)

No

Directora te(s)identify pre-proposal/proposal manager for project

Yes Facility Review Board review

Has pre-proposal funding been obtained?

FRB recommends PMC review oversight of Yes project?

Yes

Pre-Phase work begins

Inform JSC PMC of pre-proposal

No

developm ent effo rt

No Follow facility NPDs and NPRs for project development

FRB provides project oversight Modify PMC pre-proposal form

Develop PMC pre-proposal approv a l form

Yes

Terminate activity

No

Actions assigned ?

Present to JSC PMC. Pre-proposal approval given?

No

Yes

PMC delegated No oversight to directorate

Facility project ? Yes

Yes Directorate boards provide project oversight

Key: ATP – authorization to proceed ERB – Engineering Review Boa rd FRB – Facil ity Review Bo ard JSC – Johnson Space Center NPD – NASAPolicy Directi ve NPR – NASA Procedu res and Requirements OSB– outside ofboard PMC– Project Management Council

No

Directorate(s) name pre-proposal/proposal manager Pre-Phase A work

Follow facility NPDs and NPRs for projectdevelopme nt

Phase work Directorate or designated board reviews Phase B work begins

Customer approva l review

Yes

Present to JSC PMC for concurrence (may be processed OSB)

Phase C work begins

Ye Yess

Programdirected project?

ERB review Completed assigned actions

No

Yes Present to JSC PMC w/ proposal results. ATPgiven?

No

Terminate activity per Section 3.7

Project presents status to JSC PMC on agreedto project-specif ic schedule

Figure 2.5 -1. Pre-proposal/proposal/implementation approval process.

2-9

Actions assigned ? No

System Definition Review (SDR) completed


(e.g., Center general and administration (G&A) allocation) or external Center funding, the team may immediately proceed without waiting for JSC PMC approval. In such case, the pre-proposal team shall report their initiation of efforts at the earliest poss ible JSC PMC. At that time, the JSC PMC must determine whether project oversight will be kept at the PMC or delegated to a directorate-level project management board. The JSC PMC approval for this effort may be given OSB. If the pre-proposal efforts are for a project in

time to the JSC PMC. JSC PMC approval for this effort may be given OSB. Detailed PMC procedures in support of this process are documente d in the JSC Office of the Chief Engineer’s Web site. 4) Implementation Review Proce ss – The purpose of the JSC PMC implementation review is to look at the current status of the project or project support effort. The discussion at the JSC PMC will be focused around two major points; i.e., to: • Demonstrate to the JSC PMC that the project is meeting its intended goals and requirements

support a non-NASA program and funded by be internal of Center funds, JSC PMC approval shall required prior to initiation of these activities. Detailed PMC procedures in support of this process are doc umented in the JSC Office of the Chief Engineer’s Web site. 3) Implementation Approval Process – The purpose of the implementation approval process is to re view the project proposal developed and to determine whether it should be implemented. This review occurs at the same time as System Definition Review (SDR) in Phase B of the project life cycle. The discussion at the JSC PMC will be focused around fo ur major points: • That the project is appropriate for the JSC mission and goals • That there is the appropriate completeness and accuracy of the p roposal development effort expended to date • Whether the appropriate level of JSC support is available to provide a reasonable probability of success for the resulting project • The appropriateness of delegating management oversight to a directorate-level board (and which directorate-level board to delegate to) A favorable outcome results in an ATP for implementation of the project. An unfavorable outcome may result in additional work being required or termination of the effort ( FIG. 2.5-1). For all projects given ATP, the JSC PMC shall document in its minutes the frequency of future status reviews. The JSC PMC project approval information requested is minimal in order that JSC PMC decisions may be timely; however, the information must also provide ass urance that a complete and thorough proposal development effort has been made. If the proposal efforts were specifically requested in writing by a NASA program, the proposal team can immediately proceed with out waiting for JSC PMC approval and shall report their initiation of efforts at the earliest possible

within the approved schedule and resource envelopes. Apprise the JSC PMC of any corrective action needed above the project level. A favorable outcome results in an authorization to continue des ign, development, or operations activities on the project. An unfavorable outcome may result in additional work being required or termination of the project. The JSC PMC project status review information requested is minimal in order that JSC PMC decisions may be timely; however, the information must also provide assurance that there is complete and thorough project management of the design, development, or operations effort. All approved projects will be reviewed on an agreed frequency, and thi s frequency shall be formally documented in the JSC PMC minutes. Detailed PMC procedures in support of this process are documente d in the JSC Office of the Chief Engineer’s Web site. •

2-10


2.6 Documentation Tree The following figure ( FIG. 2.6-1) is provided to graphically show the various levels and relationships of many project management or project managementrelated documents as they affect JSC projects. The listings shown are not a complete representation of all documents since there are many more documents (including NASA external documentation) that are applicable. The listing is instead intended to show the JSC Center-level and directorate-level implementation of these documents and their requirements. Headquarters Level

NPR 7120.5B

Facilities NPDs and NPRs

NPR 1440.6G

Program/Project Management

“What”

NPD 8820.2 A NPD 8820.3 NPR 8820.2 E NPR 8831.2D NPD 8831.1D

Records Management

NPD 7500.1 NPD 8010.2

NP R NPR Systems

Program/Project Logistics

NPD 8730.4

Metrics System

NPD 7330.1F

Systems Engineering Engineering

Designand Construction of Facilities Facility Sustainable Design Facility ProjectImplementation Guide Facilities Maintenance Managem ent Manag ementof Institutionaland Program Facilities and Equipment ApprovalAuthoriti es for Facilities Projects

S/W IV&

NPD 8010.3

NPD 2820.1

NPR 8000.4

NPD 9501

Terminate Space Systems Risk Management

Center Level

EVM

NASA RP 1358

of What”

Systems Engineering Toolbox

JP G

JPG Project Management

JPD 7120.1

WP 09-0014

WSTF

JPD 8090.1

Project

Systems

Handbook

Management

Engineering

Project Control (includes EVM)

of H ow”

EA-WI-023

Engineering

TBD

TBD

TBD

TBD

Various WIs

MOD

SLSD

IRD

FCOD

JA

Key: Completed

JP D

Systems Engineering

Directorate Level“Deta il

Software Policies

Software Guide and Requirements

SP 6105

ProjectManagemen t

Export Control

JSC EVM Handbook

“Detail

“How”

NPR 2190.1

In development

Handbook

Figure 2.6 -1. Documentation tree.

2-11


2.7 Project Team JSC uses, and shall continue to use, a collaborative engineering and development approach for all Center projects. As such, the project and support teams include representation of all organizations necessary to successfully complete the project. The following project and support team member discussions are intended to document a minimum set of roles and responsibilities needed to effectively and successfully manage a project. The team member listings also highlight the need for a conscious project discussion as to individual team member roles and responsibilities.

re-staffing. Not all project position described in the following sections are necessary for every project.

project must make a strong effort to identify theThe correct minimum number of individuals early in the project planning effort. In this identification process, however, there must be a clear understanding of the expected workload for each project and support team member. Especially importan t is an understanding of the workload for those individuals who take on multiple project roles (e.g., project manager and project control officer). The detailed discussion of what is required for each role is, therefore, provided to lay a common framework across all projects and direc torates at JSC. The project manager can also use the project team membership discussion for additional purposes. For example, they can use it for: • A quantitative planning tool for estimating the minimum number of project personnel. • An introduction to the tailored management processes and pro cedures to be used. Finally, these agreed-to project management positions shall be documented in the project management plan.

beginning with identification of the project skill requirements and ending, ultimatel y, in enteam suring that project requirements are met within budget and schedule. The project manager is responsible, in accordance with Federal regulations and NASA and JSC management directive s (many of which are referenced here in), for the successful planning and implementation of project resources, schedule, and performance objectives. This includes being responsible for the overall project safety and risk management. The project manager receives authority via a clear chain of delegation beginning with the pr ogram commitment agreement (PCA) and flowing through the program plan to the project management plan (for program-delegated projects) or by the approved project management plan (for JSC projects not tied to a specific program). The project manager monitors all aspects of project planning, definition, development, and implementation to develop a clear grasp of progress and problems. The project manager will then determine the necessary corrective action and implement it. The project manager is therefore responsible for determining when changes to the project schedule, design requirements, and available resources are necessary or when interim test results, failure investigations, or other unpredictable constraints also require changes in the project, such as parallel and/or repetition of design activities. Additional key aspects of the project manager’s responsibilities include: a. Functioning as the project representative to upper management. As such, it is the project manager’s responsibility to remain cognizant of external issues and concerns and address them in a timely manner. b. Identifying to line management the skills required to successfully achieve the project objectives and working with line management to identify team members who meet these

2.7.2 Membership The following paragraphs describe functions and roles of various positions in the project management team. 2.7.2.1 Project manager role The project manager shall have the authority and responsibility to execute the project. The project manager is responsible for all aspects of the p roject

2.7.1 Organization The project organization is the establishment of clear, non-conflicting authority relationships between positions that have been assigned specific tasks required to achieve project requirements. A full understanding of the project performance requirements, costs, and schedules is necessary to identify the specific sets of responsibilities involved. Delegation of authority to undertake these responsibilities is key to organization, and is one of the most important managerial abilities. Unless authority is effectively delegated, duties requiring coordination of group activities cannot be effectively assigned to a subordinate supervisor, who must, in turn, must have adequate authority to accomplish those tasks or assign them to others. A project’s organizational structure and staffing are dependent on the character of the project and will change as the project matures and areas of importance and priorities shift. The project manager is responsible for identifying these necessary project changes and directing the associated replanning, reorganizing, and

requirements. c. Ensuring that the SE functions are accomplished in accordance with this guideline. d. Ensuring that the project control functions are accomplished in accordance with this guideline,

2-12


e. f. g.

h. i.

including incorporation of appropriate earned value management (EVM). Ensuring form ulation and maintenance of the project acquisition strategy. Ensuring adequate train ing for the project team members. Knowledge of the information genera ted within the project and taking appropriate action to protect it, depen ding on its sen sitivity. Ensuring project compliance with export control requirements. Ensuring appropriate implementation of safety

role in determining tailoring, if any, for the SE practices of the project. Although the project manager will look to the subsystem managers as the authorities on subsystem performance, it is the responsibility of the LSE to: • Ensure the analytical and physical integration of the subsystems. • Monitor the performance of all subsystems. • Ensure the technical performance of the overall integrated system. • Identify, plan, schedule, appropriately resource load, and execute all system-level test activities

for personnel and protection of national security classified/sensitive /valuable unclassified information, material, facilities, and other property. j. For a contracto r-supported/NASA -managed project, developing and maintaining an understanding of the contractor’s processes, procedures, and activities.

to support the overall project schedule. As part of their effort in ensuring that system implementation fulfills system needs, the LSE is responsible for managing and directing all of the project’s SE activities performed using the SE processes outlined in Chapter 4. These activities include requirements development and flowdown, formulation of systems architectures and concepts, systems design, interface definition and control, draft development and monitoring of technical performance measure ments (TPMs), system-level risk management, systemlevel trade studies, fabrication planning, test plan development, system integration and testing, and verification. Another role of the LSE is to make recommendations on project design trade-offs where performance, cost, and schedule must be balanced. Through responsibility for the technical adequacy of all system-related activities of the project, the LSE must strive to ensure that system engineering is exercised in all project deci sions. Finally, the skills and knowledge necessary for an LSE are normally accrued from multiple past subsystem or system assignments, training classes, and other professional developmental experiences.

2.7.2.2 Deputy project manager (DPM) role Depending on the project, it may be neces sary to have a DPM in addition to the project manager. The DPM will normally be formally delegated all of the responsibilities held by the project manager when the project manager is absent. In addition, the DPM may be delegated primary responsibilities for selected project management tasks by the project manager. Any project-unique responsibilities need to be documented in the PMP. Some examples of reasons why a DPM may be required include: • A very large or complex project • A geographically distributed project • A project management developmental opportunity for an individual 2.7.2.3 Lead systems engineer (LSE) role The LSE is a key member of the project team. The LSE is functionally responsible to the project manager for assuring that system implementation fulfills system needs and that proper system enginee ring practices are being followed. The LSE oversees the project system engineering activities, including in-house and any contractor responsibilities, to assure they are adequate and in compliance with the project constraints of performance requirements, cost, and schedule. As part of the effect to ensure that proper system engineering practices are being followed, the LSE must direct, monitor, or coordinate applicable SE tasks both within the Center and, to the appropriate level and as req uired, outside the Center. The LSE must also constantly review and evaluate the technical aspects of the project to ensure that the system/ subsystems engineering processes are functioning appropriately. In addition, the LSE plays the major

2.7.2.4 Project control officer role The project control officer shall be responsible to the project manager for all project documentat ion, for assessing project progress against baseline schedule(s), for providing integrated (i.e., technical, cost, and schedule) project-level non-technical recommendations, and for assisting the project manager in control of project resources and activities, including budg et, schedules, customer agreement, and overall project management. The project control officer shall also be responsible for providing support to the total management process of establishing and maintaining project baselines and effectively supporting the project manager in meeting the overall objectives of the project. The project control officer is responsible for: • Resource management • Project planning

2-13


ment of performance analyses for the system or subsystem. Examples of engineering disciplines that may be important to the project include: aerodynamics analysis; aerothermal analysis; guidance, navigation, and control; static and dynamic structural analyses; materials analysis; software/avionics development, and reliability, maintainability, availability, and human factors. SLEs and DLEs shall support the subsystem or analysis detailed status to the project LSE for technical review and integration, and to the project control officer for rev iew and integration of cost and

Documentation and data management Project assessment − Cost estimating − Performance measurement − Project analysis • Schedule management • Acquisition management • Risk management • Configuration management (CM) • Quality management The project control officer shall: a. Provide detailed recommendations early in the project planning phases of what minimum data set (including the deliverables list) is required throughout the project life cycle. b. Ensure project progress and activities are consistent with approved project customer agreements, budgets, schedules, and acquisition strategies. c. Ensure all aspects of the project cost and schedule status are integrated and documented (especially including subsystem status). d. Manage the day -to-day project-support functions such as management information systems (including IT securi ty plans), organizing the lo gistics of programmatic reviews, compiling and reporting project metrics, and reporting contract or NASA-internal performance measurement surveillance efforts (including any EVM efforts). e. Ensure project document compliance with any NASA requirements and, if applicable, ensure • •

f. g. h. i. j.

schedule status. The SLE or DLE shall: a. Be responsible for ensuring the subsystem or analysis requirements are appropriately and correctly flowed down from system requirements. b. Be responsible for ensuring the subsystem or analysis requirements are achieved within project budget and schedule. c. Be responsible for the subsystem functions and, therefore, for the technical performance of their subsystem. [SLEs] d. Be responsible for the technical accuracy and completeness of th eir discipline areas. [DLEs] e. Make appropriate use of the management tools provided by the project control officer (e.g., EVM, critical path analysis, 5 × 5 risk management matrix, technical performance measurements, etc.). f. Be responsible for developing subsystem or analysis design documentation to support scheduled reviews. g. Be responsible for the planning and conduct of subsystem fabrication and testing. [SLEs] h. Ensure that, to the maximum extent possible, the system will be tested appropriately and can fulfill its requ irements and perform as intended. i. All subsystem-level test activities and support are identified, planned, scheduled, appropriately resource loaded, and executed to support the overall project schedule.

contractor document compliance with any contractual requirements. Fulfill the library and records retention function for storage and retrieval of project documents. Develop the project data management procedures for the project. Develop and implement planning for contract acquisition. Provide detailed recom mendations for the project acquisition strategy. Provide the project input for the annual Center/ program operating plan (POP) cycle.

2.7.2.6 Verification lead role The verification lead is accountable to the project manager and is responsible for all verification aspects of the project. The verification lead shall: a. Ensure requirements are verifiable. b. Develop the verification plan. c. Identify the most effective verification meth ods. d. Identify verifi cation criteri a and coordinate

2.7.2.5

Subsystem and discipline lead engineers role The subsystem lead engineer (SLE) and the discipline lead engineer (DLE) prove a significant factor in the successful technical and cost management of a project. The SLE is the project manager’s primary Depending contact on on management a partic ular s ubsystem. the project of product complexity and staffing constraints, an SLE may be responsible for more than one subsystem. The DLE performs a similar function, but is responsible for the manage-

activities with verification facilities, participants, and other team members. e. Execute the verification plan. f. Develop or coordinate verification procedures.

2-14


g. Collect and document verification results. h. Evaluate results for com pliance or need for reverification.

a flight crew representative, their role is to provide the operator’s viewpoint and experience throughout all phases of the project, and to obtain consensus of the Astronaut Office on issues involving safety and mission success. The flight crew representative shall act as a consultant to the project team, and provide input into, and concurrence on, project requirements and products. The flight crew representative will also coordinate participation from the Astronaut Office in testing and checkout, proc edures development an d verification, and other activities as appropriate. Involvement of the Astronaut Office ensures that

2.7.2.7 Validation lead role The validation lead is accountable to the project manager and is responsible for all validation aspects of the project. The validation lead shall: a. Develop the validation plan. b. Identify the most effective validation method. c. Coordinate activities with validation facilities, participants, and other team members. d. validation the plan. e. Execute Develop the or coordinate validation procedures . f. Collect and document the validation results .

the n-orbit experience and activities lessons learned are carriedoforward in engineering dealing with human space flight. In addition, the Astronaut Office benefits by gaining in -depth know ledge of the sys tems they will operate on orbit.

2.7.2.8 Project scientist role Not ever y JSC proje ct needs to have a projec t scientist. However, it may be necessary to have a project scientist on a project if there is significant scientific instrumentation/utilization in the project. For a sciencebased project, the project scientist shall be deemed necessary when no principal investigator (PI) exists, when multiple PIs exist, when the PI is external to the Center, or when the JSC PI cannot serve in the project scientist function for the project. The project scientist’s role, duties, and responsibilities shall include: a. Overseeing the scientific integrity of the project’s mission within project constraints. b. Ensuring that science requirements are adequately documented and verified in the project. c. Ensuring that the project planning, definition, implementation, and operations are appropriate for the science requirements. d. Serving as the scientific advisor to the project manager, advising on pr oposed changes to science objectives or requirements, when necessary. e. Participating in appropriate project reviews to ensure the project science requirements are appropriately addressed. f. Acting as the science interface for data analysis and plans. It should be noted that when a PI serves in the role of project scientist, the PI may also serve as the project manager.

2.7.2.10 Administrative officer role The administrative officer is responsible for assisting the project manager in a variety of administrative activities in support of the project. Responsibilities may vary depending on the size and complexity of the project and the project manager’s delegation of responsibilities and assignments. Responsibilities may include the tracking of project-related correspondence, handling of personnel actions, oversight and maintenance of internal task agreements (ITAs), and recording and tracking of action items (both internal to the project and as signed to the project externally). The administrative officer may also serve as the offi cial training and records officer for the project, thereby ensuring compliance with JSC Procedures and Guidelines (JPG) 1440.3, JSC Files and Record Management Procedures. 2.7.3 Support Team The following paragraphs describe various functions and roles in support of the project management team. 2.7.3.1 Line management support JSC projects normally operate on a matrix organizational approach. As such, the primary functions of line management in the life cycle of a project include: a. Participating in the project approval pr oces s. b. Providing the resources, facilities, and tools re quired for the project. c. Selecting competent and knowledge project managers. d. Implementing Agency, Center, directorate, and

2.7.2.9 User representative role A key input into the project day-to-day management often comes from the end user of the product. While not every project at JSC needs to have a user representative on its team, it is critical that the project team continually consider the user as its develops the end products. Some examples of user representatives include flight crew, flight controllers, surgeons, or the JSC IT community. For those projects that have

division policies, procedures, and standards. e. Enforcing safety, cost, schedule, technical, and management processes to ensure product and services are consistent and of high quality.

2-15


f. Providing support and oversight over technical management decisions. g. Ensuring projects and project decisions that impact other projects, processes, or priorities established by the customers, the Agency, Center, directorate, and/or division are coordinated/communicated. h. Ensuring comm unication and integration across projects and other divisional/organizational lines. i. Mentoring the entire project team. j. Providing technical and management guidance to the project manager based on project complex-

ance Directorate, assuring proper coordination, review, or approval of all safety, reliability, maintainability, and quality assurance (QA) responsibilities and practices. d. Ensure that S&MA processes are established within the project. 2.7.3.3 Mission operations support Mission operations project support is provided through an assigned representative or representatives. typically these representatives come from the Mission Operations Directorate. The representative shall be

ity and the experience level of the project manager. While line management reserves the right to provide technical direction to project managers under their supervision, any resulting changes in baselined cost, schedule, or performance requirements shall be approved by the customer in accordance with the established CM process. Technical issues that cannot be resolved between the line management chain and the project manager shall be presented to the JSC ERB for final disposition prior to coordination with the customer. In cases where the project or line management feels a decision jeopardizes crew safety or mission success, appeals should be taken directly through the appropriate management chain or indirectly (anonymously) through the independent assessment (IA) organizations, the JSC Ombuds, the NASA Safety and Reporting System (NSRS), the Government Auditing Office, and/or the NASA Inspector General. Given line management responsibilities for the selection and performance of the project manager, line management can replace any or all of the project management team under their supervision when significant technical competency or management issues with the project management team are identified. In all cases, this removal should be coordinated with the project customer and the directorate.

the project’s interface with theand mission and opera tions discipline organizations personnel. The project team normally requires a person to lead efforts associated wi th ensuring that the project mis sion operations are properly defined, planned, and executed. Mission operations encompass the flight and ground operations suppo rt personnel, S/ W, procedures, H/W, and facilities required to execute the flight mission. The responsibilities of the mission operations support team member are also to lead the efforts associated with defining the operations team and ensure that the op erations team is trained and ready to support operations. Ground operations are included as the ground segment of mission operations. 2.7.3.4 Test operations lead support The test operations lead is accountab le to the project manager and is the system test team individual responsible for ensuring that, to the maximum extent possible, the system will be tested appropriately and can fulfill its requirements and perform as intended. The test operations lead shall ensure that: a. All system-level test requirements provided by the project team have been identified and documented prior to testing. b. All system-level test procedures provided by the project team have been developed and verified prior to testing. c. All subsystems supporting the system-level tests are ready to support and are appropriately documented. d. The Test Readiness Review(TRR) appropriately addresses all system test performance and safety requirements and incorporates all applicable les sons learned from the JSC lessons learned database (http://iss-www.jsc.nasa.gov/ss/issapt/lldb/) as well as the NASA lessons learned database (http://llis.gsfc.nasa.gov/ ); and that the required test and/or integration facilities have been veri-

2.7.3.2

Safety and mission assurance (S&MA) support S&MA project support is provided through a Safety and Miss ion Assurance Directorate-assigne d representative, usually collocated with the project team. In this capacity, the S&MA representative shall: a. Assist the project manager in assuring that all system S&MA requirements (including personnel and facility safety) are appropriately defined and implemented. b. Provide for an independent S&MA oversi ght and assessment function for all aspects of the project. c. Serve as the single point-of-contact between the project team and the Safety and Missi on Assur-

fied to provide the necessary conditions and have been scheduled and are available. e. The required test and/or integration fa cilities have been verified to provide the necessary

2-16


conditions and have been scheduled and are available. f. The required ground support equipment (GSE) has been verified to provide the necessary support resources and has been sche duled and is available.

vides the capability to perform analyses and make assessments of the potential environmental impact. Some of the areas the environmental team support s include storm water and wastewater management, industrial and hazardous waste management, oil storage, asbestos and lead control, and spills and releases management.

2.7.3.5 Facilities support In some cases, it may be necessary for the project to have support for the modification or co nstruction of Center facilities. Coordination of these activities may be accomplished through a Center Operations

2.7.3.7 Counterintelligence support In almost all cases, it will be necess ary for the project to have support for the counterintelligence function. Coordination of these activities may be ac-

representative on theproject projectteam team,coordination or it may bediaccomplished through rectly with appropriate Center Oper ations perso nnel. For new facilities, it is critical that all requirements be identified in any budget submission, and the impact on other funding sources (e.g., institutional) also be defined. New facility requirements should be split between nonrecurring (outfitting) and recurring (operations and maintenance). Considerable and timely foresight must be given to facility requirements. Most requirements ideally can be accommodated with minimal changes to existing facilities. Where changes are required, however, cost and schedule cons iderations will determine the procedure for affecting change. Facility projects may be funded by project or CofF funds. Project funding can be used only through use of an “Unforeseen Programmatic Document” that explains the urgency of the requirement and gives reasons why the requirement has not been included in the CofF budget cycle. The CofF budget cycle requires a minimum of three years from initial submission of the requirement to completion of construction. Initially, the project requirements are specified for inclusion in the CofF budget cycle. A preliminary engineering report further defines the requirements during the first year, design is accomplished during the second year, and construction is started during the third year. In most instances, construction can be completed in one year. A number of Center offices participate in the preliminary engineering report and d esign phases, ensurin g the completed project will satisfy all requirements and meet Center objecti ves .

complished through a Center representative on the project team, or it Operations may be accomplished through project team coordination directly with the appropriate Center Operations personnel. The Center counterintelligence function provides an assessment and support capability for the project, the Center, an d the Agency. This function works to actively identify potential technologies and other products that could be used by fore ign governmen ts (businesses or individuals) for their economic/strategic advantage. This function is distinctly separate fro m the export control function in that it also works to actively assess technology development areas and analyzes them against specific threat areas. A key characteristic of these counterintelligence representatives is their ability to work proactiv ely with the project management team to ensure both the appropriate awareness and responsibilities to manage the protection of these technologies, and how to identify attempts to access them improperly. 2.7.3.8 Export control support In some cases, it may be necessary for the project to have support for export control activi ties. Coordination of these activities may be accomplished through a Center Operations representative on the project team,, or it may be accomplished through project team coordination directly with the appropriate Center Operations personnel. The purpose of the export control function is to ensure complianc e with the JSC export control re quirements documented in the JSC Common Work Instruction (CWI) J29W-01, JSC Export Complian ce , the NASA export control directive, NPD 2190, NASA Export Control Program, and the export control requirements of the Departments of State and Commerce as well as other agencies. This important function covers all JSC projects and encompasses export control to all product technologies and technical information

2.7.3.6 Environmental support In some cases, it may be necessary for the project to have support for environmental concerns or impacts . Coordination of these activities may be accomplished through a Center Operations representative on the project team, or it may be accomplished through pro ject team coordination directly with appropriate Center Operations personnel. When planned project activities have the potential for environmental impact, the support function pro-

that have the potential for export outside of the U.S. In addition, the Export Control Office provides consultation and guidance for all project activities at JSC.

2-17


2.7.3.9 Logistics, trans portation, and shipping support In some cases, it may be necessary for the project to have support for logistics, transportation, and ship ping. Coordination of these activities may be accomplished through a Center Operations representative on the project team, or it may be accomplished through project team coordination directly with appropri ate Center Operations personnel. For logistics, transportation, and shipping support, it is critical that all requirements be identified as early as possible in the life cycle. Early identificati on and

2.7.3.11

Office of the Chief Financial Officer (CFO) support The Office of the Chief Financial officer is the focal point for financial planning and budget execution for the Center. The Office designs and implements the financial and resources systems required for pro per data collection and reporting and ensures that Agency and Center-level financial and resource decisions are implemented. It reviews, approves, and implements financial and resource s policies and systems and integrates the planning, implementation, manageme nt, and control of all resources for which the Center is

communication of any ofof these requirements minimize the probability project disruptionwould from these support areas.

responsible. The CFO provides guidance in administrative responsibilities of the technical community in regard to the initiation and approval of purchase requests. The guidance is included in the IFM On -line Quick Reference, http://olqr-cf.ifmp.nasa.gov. Guidance regarding planning and execution of civil serv ice travel will be provided at a later date.

2.7.3.10 Procurement support For contracted projects, the project manager’s procurement interface is a Procurement Office repre sentative to the project team. This representative may or may not be collocated. For a JSC internal project (e.g., GFE), the project Procurement Office representative may only function to assist in purchasing of materials, services, or components for the final proje ct product. The Procurement Office representative shall be responsible for: a. Development of the Master Buy Plan submis sion to the JSC Procurement Office. b. Coordinating the acquisition strategy including scheduling and assisting in the development of the presentation to the Acquisition Strategy Meeting with JSC management and, if required, NASA Headquarters. c. Assisting in the development of the statement of work (SOW) for the contract. d. The request for proposal (RFP). e. Formation and operation of a Source Evaluation Board leading to source selection. The Procurement Office representative is also responsible for contract negotiation for a contracted project. The Procurement Office representative also supports the development of a change order control system to implement contract changes. Timely development of change requirements and technical evaluation of change proposals by the Project Office will permit early change order negotiations and ensure a firm contract baseline. Formal authority to enter into and modify contracts rests solely with the contracting officer in the cognizant Procurement Office; however, there must be a close

2.7.3.12

Office of the Chief Engineer support The Office of the Chief Engineer provides support to the projects primarily through the Systems Management Office (SMO) . The SMO provides leadership, consultation services , and technical expertise on SE and project management. The SMO also reviews and determines Centerwide usage and consistency for common SE and project management processes, procedures, and practices. This includes the use and implementation of appropriate performance measurement systems requirements such as EVM. As a project consultant, the SMO can assist the project in planning and accomplishing Pre -Phase A, Phase A, and even some Phase B efforts. Experience has shown that a significant percentage of projects that have failed to meet performance, cost, or schedule requirements has had an inadequate effort in these critical project phases. Therefore, the SMO can be called on to assist the project in executing these phases appropriately. As a project reviewer, the SMO c an act a s an independent reviewer, either at the request of the project itself, the program manager, the director, or the Center Director. In this capacity, the SMO can examine the project from a technical, cost, and/or schedule viewpoint and provide deta iled recommendations for corrective actions. 2.7.3.13

working relationship between the contracting office and the project contracting officer technical representative (COTR) to ensure appropriate management and direction of any contractor’s support efforts.

Legal support

The project manager must maintain a close working relationship with the legal representative on all issues or concerns developing with legal implications or involving legal policy. Matters that should give rise

2-18


to claims or litigation should be communicated and coordinated as early as possible. Any correspondence or contacts by external NASA legal counsel should be referred to or reported immediately to the Chief Counsel or the Chief Counsel’s designated repres entative. Any court or administrative legal papers affecting NASA (e.g., lawsuits, claims, subpoenas, or summons) shall also be referred to the Chief Counsel for advice and guidance. 2.7.3.14

services for development and mission support. Coordination and discussion of these needs may be accomplished through an IRD representative on the project team, or it may be accomplished through project team coordination directly with the appro priate IRD personnel. For space flight mission support, this includes acquisition, distribution, recording, search/retrieval and playback, editing, duplication, and archiving. Operational services are also provided to satisfy project-level test, training, and administration video support requirements. This support team also oper-

Communication and information technology support

JSC has significant IT or andproject communications capabilities to supportexisting individual needs. Because of the diverse nature of projects at JSC, however, unique communication or IT requirements may develop. Coordination and discussion of these requirements may be accomplished through an Information Resources Directorate (IRD) representative on the project team, or it may be accomplished t hrough project team coordination directly with appropriate IRD personnel. For information on existing directorate-specif ic IT tools, the project team should review the listings at http://cio.jsc.nasa.gov/Center/itp/standards/standards.htm . These unique communications and IT requirements should be identified early in the project planning efforts to provide for effective long-range implementation and budget planning as part of t he Agency and JSC forecast. With this information, early communications feasibility engineering for lease or contracting workloads for project execution can be accomplished. Timely scheduling to include communications in project planning will permit the required communications and IT support to be availab le to support the project for management, scientific, technical, and operational requirements. 2.7.3.15

Documentation and graphics support JSC has significant existing documentation and graphics capabilities to support individual or project needs. Coordination and discussion of these needs may be accomplished through an IRD representative on the project team, or it may be accomplished through project team coordination directly with the appropriate IRD personnel. Some of the documentation and graphics services and products provided throughout the project life cycle include printing and reproduction, editing and technical writing, graphics, mail delivery/pickup services, and documentation repository.

ates audio/video cablethe TV system. distribution network and the JSC 2.7.3.17 Public Affairs Office support The Public Affairs Office provides support to the projects and the project team by serving as a liaison for project information going to the public and the media. Coordination of these activities may be accomplished through a Public Affairs Office representative on the project team (if there is enough demand); or it is more likely that it may be accomplished through project team coordination directly with the appropriate Public Affairs Office personnel. Additional guidance can be obtained through reference to JPD 1382.1H and JPD 1382.4K. 2.7.3.18 Human factors support For cases in which the H/W or S/W bei ng developed requires a human interface, it may be necessary for the project to have support for human factors and habitability concerns or impacts. Coordination of these activities may be accomplished through project team coordination direct ly with the appropriate repre sentatives or by having an assigned representative in the team. Typically these representatives come from the Space and Life Sciences Directorate. When planned project activities have the p otential for human factors or habitability impact, the support function provides the capability to perform analyses and make assessments of potential impact. Involvement of human factors also ensures t hat on-orbit operational habitability experie nce reports and l essons learned are carried forward in project activities. Some of the areas human factors and habitability personnel support include physical and visual accessibility, human strength capabilities and limitations, workstation design, internal environme nt design, labeling and coding, and user/computer interaction. 2.7.3.19

Technology transfer and intellectual property management support The Office of Technology Transfer & Commercialization provides support to projects in two areas, technology transfer and intellectual property management.

2.7.3.16 Photographic -video support The project may require photographic or video support over its life cycle. The IRD is responsible for providing the photographic and operational video

2-19


The technology transfer representative shall: a. Assist the project manager in technology planning by • Identifying and negotiating with potential partners for joint technology development ventures. • Identifying technologies at other governmen t organizations and universities that would be prime candidates for technology infusion into the project. b. Assist the project manager in identification and documentation of new innovations that result from technology development performed by the project. c. Provide guidance on all technology transfer functions and initial guidance on intellectual property matte rs. The Patent Counsel and the Patent Counsel’s staff shall assist the project manager on all matters pertaining to intellectual property, which includes but is not limited to invention disclosures, patent prosecution, copyrights, S/W usage agreements, new technology and patent rights clauses in contracts, and procurement counseling on related issues.

2-20


2.8 Project Management and Planning Project managem ent and planning activities pro vide the framework to ensure that a project meets the established budget, schedule, safety, and technica l re quirements to satisfy both project and the customer’s objectives. The project management and planning activities shall operate over the entire life cycle of the projec t and must be developed and implemented such that a rapid assessment and response capa bility is in herent. The amount of project management and planning performed should be commensurate with project approach, type, size, risks, and complexity.

characteristics and, more importantly, requires a different management guidance style for each (also called situational leadership). Many descriptions of this transformation process exist. As an example, one description is called the Four-Stage Model. Simply stated, the team passes through four s tages on its way to a unified, effective work team. The stages and the associated management style are lis ted below: 1. Forming F (Telling; e.g., provides specific directions and closely supervises performance) 2. Storming F (Selling; e.g., explains decisions and provides opportunity for clarification)

Projectin management planning are This included a PMP (seeand Appendix A activities for template). not only establishes project controls that include a project baseline to allow for performance to be monitored and corrective action taken, if necessary; it also allows for a clear communication to project team members of the processes, methods, and activities that will be used in managing the project. Included in this shall be any tailoring approaches to be used during the lifetime of the project. In addition to the PMP, project management and planning activities create other products and documentation that supplement the PMP and support the annual program operating plan (POP) proc ess. Project activities will likely change the project ba seline as the project progresses. Reviews may be conducted internally or externally by the project , pro gram (if applicable), or center or through an independent assessment organization. If significant performance variances or risks are identified that jeopardize project objectives, changes to the PMP and project baseline may be required.

3. Norming e.g., shares ideas and facilities(Participating; in decision making) 4. Performing F (Delegating; e.g., turns over re sponsibility for decisions and implementations) Since a considerable number of knowledge sources exist on this topic, further discussion on the generic transformation process and the appropriate management guidance style for each is left for the reader to obtain external to this document. Available resources include the Human Resources Development Branch and the Academy of Program and Project Leadership (APPL) (http://appl.nasa.gov/home/ ).

F

2.8.2

Project Management Plan and Project Baseline As the project develops, one of the key documents that captures and establishes the baseline for the project implementation activities is the PMP. A PMP documents project products and describes the overall plan for project implementation. The PMP shall serve as the basic agreement for the project among the project manager, the Center managing the project, and the program management (if the project is directly supporting a program). PMPs are unique to each project; and the level of detail may vary with the size, complexity, sensit ivity, and other particular characteristics of the project. The PMP also contains additional information, a nd shall be prepared in accordance with Appendix A of this document. The PMP shall create an integrated project baseline by linking scope, requirements, sche dule, and cost to risk. To accomplish this, projects shall start the planning process in the Pre-Phase A efforts, a proc ess that will mature with the continuation of the system definition and preliminary design process. The draft PMP shall be completed at the end of Phase A. The final PMP shall be completed during Phase B, and it shall be maintained and updated t hroughout the remaining project life cycles.

2.8.1 Project Management One of the key aspects of project management is the formation and operation of a project team. That is the art of transforming a group into a team that operates efficiently and effectively. While each project is unique, there are key underlying characteristics that should be understood and followed by each project manager at JSC. They are: • Honesty • Integrity • Leadership • Motivation • Negotiation • Communication • Delegation • Decision making As the project begins Pre-Phase A activities and plans and progresses through Phase E, the proj ect team will transform itself. This fact must be well understood by the project manager since each phase has specific

The planning process should be conducted in parallel with the definition of requirements. During Phase A, a pro duct-oriented work breakdown structure (WBS) shall be developed and refined as requirements are more defined. In addition to a WBS, projects

2-21


should have a high-level schedule, a life cycle cost estimate, and an organization concept developed. During Phase B, an integrated resource-loaded schedule shall be developed with refinement of the WBS and schedule and development of a bottom-up budget estimate. A risk assessment should also be completed to determine the amount of budget and schedule management reserve needed. As the project progresses through the remaining life cycle phases, periodic reviews should be made to determine whether other changes within the project are necessar y. (See Section 4.2.2 for an overview of the planning

to an attached specification). The project shall ensure that there is a written document of the customer-project agreement, agreed-to and signed by bot h parties. Parties should be aware that the degree of clarity and definition of the customer-project agreement directly influences the success of the project. Several forms of customer-project agreements may exist. For technical agreements, the minimum requirements listed below may be implemented in the form of a contract, a letter of agreement, or documented according to a customerspecific template. The customer-project agreement shoul d address, at

process.) 2.8.3 Program Operating Plan (Project Baseline Updates) Project management and planning efforts may be used to assess Center or directorate-level support e fforts and take corrective action, if necessary. Every year each project is required t o submit a budget estimate, updating life cycle and phased funding, and schedule and workforce requirements to the program/ Enterprise. The program/Enterprise consolidates the various project budget estimates into a POP. The POP covers all aspects of the project and is the lates t estimate of funding needs required to achieve baseline scope and schedule. The development process for the POP begins with the issuance of POP guidelines. The project manager then conducts a review of the entire project. Included in this review is an assessment of any requirements changes, an assessment of the previous year’s plan vs. the project’s actual performance, major project risks and their associated cost and/or schedule potential impacts, and any readjustments from the srcinal project life cycle based on unforeseen funding changes . However, any changes to requirements, schedule, and resulting budget, as well as the risk profile and reserve posture, should be managed through an internal project change process and be reflected as change s to funding needs. The resulting funding needs are what is presented annuall y as part of the POP proc ess. Center management reviews the POP submittal for consistency and compliance with Center commitments and responsibilities. The POP is then submitted to the programs and Headquarters for review, comment, and eventual approval. Through this review process and subsequent POP marks, current operating plans and future year funding, and workforce and schedule re quirements are established for each project.

a minimum: • Project needs, goals, objectives, assumptions, •

•

•

•

and constraints (the context for the project). Product or service requirements, includi ng performance, interfaces, quality, environmental and other constraints, and verification and validation requirements. Requirements on the conduct/implementation of the project. Includes the content, level, and fre quency of reporting; data, H/W and S/W deliverables; schedule information to support monitoring and incorporation into higher-level (e.g., program) schedules; process standards; and customer and project roles relative to the major technical reviews. Resources provided by the customer or other organizations to the project such as funding, personnel, equipment, facilities, and materials. Resources devoted by the supplier organization

(the project)equipment, the accomplish the project suchand as personnel, facilities, materials, subcontracts. The project agreement with the customer will flow down into the project PMP, either directly or as the implementing elements necessary to meet the agreement. While the elements of t he customer-project agreement will be included in the PMP, the project benefits from havi ng a separate agreement with the customer. In that way, the customer’s approval is not required to change elements of the PMP that do not directly impact the customer.

2.8.4 Customer-Project Agreement The customer-project agreement documen ts the requirements on the project related to how it will do business relative to the custome r and t he expectations on the product or service supplied (usually by reference

2-22


P ro je ct L if e C y cl e e R q u rie m e n ts

Project Life Cycle Requirements

Chapter 3 Project Life Cycle Requirements

•

This chapter outlines requirements for Johnson Space Center (JSC) projects as they relate to the products, reviews, and management decisions that are expected for each phase of the project deve lopment life cycle.* A discussion of each life cycle phase includes: • Overview – Provi des a to p-level summar y narrative of major project activities accomplished during the life cycle phase. • Expected Results/Outcomes – Lists the major

•

•

results and outcomes that the project is expected to accomplish during the life cycle phase. Products – Lists the major products that the project is required or expected to produce during the life cycle phase.

•

*

Refer to Section 2.4 for a discussion of the project life cycle for facilities and associated support projects .

3-1

Process – Provides a flow diagram that depicts the sequence of major ac tivities tha t occurs during this phase, and shows how the project management processes support these activities. NOTE: For an in-depth discussion of the process steps, refer to Special Publication (SP) 6105, NASA Systems Engineering Handbook . Reviews – Lists thep roject-level life cycle reviews that are performed during this life cycle phase. This discussion includes the purpose of the review; the objectives the project team should accomplish as part of the review; checklists to aid in determining succ essful completion of the review; and decisions that are made at the project level based on information from the review (Section 4.1.16, Reviews). Management Decisions – Outlines any management decisions made outside of the project team during the life cycle phase.


3.1 Pre-Phase A – Advanced Studies 1 3.1.1 Overview Pre-Phase A, Advanced Studies, is perfor med to develop an understanding of project needs and expectations, and to identify feasible project alternatives to fulfill these needs and expectations. This phase init iates the project development life cycle. Involvement from the project customer is essential at this stage to scope the project. The project customer provides a statement of project needs, goals, and objectives, and discloses project constraints and assump tions. This phase results in a feasibility assessment of whether project needs

the associated reviews is also illustrated along with the project management (PM) processes that should be referenced in executing each activity. 3.1.5 Reviews – Concept Review A CR, the purpose of which is to validate project needs and objectives and to examine concepts for meeting those objectives, shall be performed to exit Pre-Phase A. At the r eview, the project team shoul d be prep ared to : • Demonstrate that project objectives are complete and understandable. •

can be accomplished wthe ithin the constraints and as sumptions provided by customer.

Confirm concepts demonstrate technicalthat and proposed programmatic feasibility for meeting stakeholder needs and objectives. • Confirm that customer project needs are clear and achievable. • Ensure that prioritized evaluation criteria (also known as figures of merit or measures of effectiveness) are provided for subsequent analysis. • Identify skills needed for the next phase. The following checklist is provided to aid in determining successful completion of the review: • Has the project need been clearly identified? • Are the project objectives clearly defined and stated? Are they unambiguous and consistent? • Are project assumptions and constraints clearly defined? • Will satisfaction of the preliminary set of requirements provide a system that will meet stakeholder needs and objectives?

3.1.2 Expected Results/Outcomes During Pre-Phase A, the project team should: • Confirm customer project need s. • Assess the technica l and programmatic feas ibility of the project. • Define objectives and top-level functional and performance requirements. • Produce a feasibility assessment report. • Conduct a concept review. 3.1.3 Products The feasibility assessment report shall be the pri mary product of this phase. It documents the st udies completed during Pre-Phase A to assess project feasibility. The contents of this report are reviewed during the Concept Review (C R). The following are repre -

•

sentative contents this report: • Project needs,ofgoals, and objectives and relevance to the Center Implementation Plan • Project assumptions, guidelines, and constraints • Top-level functional and performance requirements • Documentation of all system and functional concepts and architectures considered, and rationale for selection or rejection • Operations concepts • Evaluation criteria (also known as figures of merit or measures of effectiveness) • Performance measures (cost, schedule, and technical) • Life cycle schedule and c ost estimates • Technology development requirements • Trades and analysis results • A review and report on applicable lessons learned

Have the concept evaluation criteria that are to be used in the candidate system’s evaluation been identified and prioritized? • Is the project feasible? Has at least one solution been identified that is technically feasible, and that meets stated assumptions and constraints? Is the rough cost estimate within the acceptable cost range? • Are schedule and cost estimates credible? • Was a technology search don e to identify existing assets that could satisfy the project or part of the project? • Were all applicable lessons learned identified, evaluated, and incorporated to the maximum extent possible? Project Decision – The project manager decides whether the project is ready to recom mend authoriza tion to proceed to the preliminary analysis phase.

3.1.4 Process The diagram ( FIG. 3-1) at the top of the following page indicat es the steps in th is phase of the project life cycle that should be accomplished when evolving the system of interest. Interaction o f these steps and

3.1.6 Management Decision The decision to proceed from Pre-Phase A, Advanced Studies, to Phase A, Preliminary Analysis, shall be provided by a directorate-level board or its delegate. For projects that involve multiple directorates, approval

3-2


Project Customer Provides Project Needs, Goals, Objectives, Assu mptions, and Cons traint s

Management Decision/Control Gate Conce pt Review Iterate Requirements and Concepts to Establish Feasibility Reviews

Start 1.1 Refine User Needs & Objectives Start

Understand Customer

Identify Fea sible Alternatives

1.3 Develop Management Top-Level Decision/Control Requirements Gate Requirements

Requirements Development & Management

PMC Approval*

Development & Management

1.2 Refine Constraints & Assumptions Requirements Development & Management

1.6 Flowdown Top-Level Systems Requirements

1.2a Assess Project Feasibility (“bid/no bid” decision) Feasibility Study

X.X Phase Step Supporting PM Process

*Refer to Section 2.5.3. (JSC P roject Management Council )

1.8 Allocate Requirements

Feasibility Study

Requirements Development & Management Feasibility Study

1.4 Develop Top-Level Functional Concept Operations Concept Development

Feasibility Study

Requirements Development & Management

1.5 Develop Evaluation Criteria 1.2b Prepare PMC Proposal Approval Form*

1.10 Synthesize & Down Select

1.9 Analyz & Evaluate Feasibility Study, Technology Planning

1.7 Develop Feasible Systems Concept(s) Decomposition, Feasibility Study

Mana gement and Planni ng Technology Planning, Acquisition Management, Risk Management, Quality Management, Control, Technical Work and Sources Management, Configuration Management, Safety and Mission Success, Resource Management, Planning, Documentation and Data Management, Cost Estimating, Performance Measurement, Schedule Management, Project Analysis

Figure 3 -1. Pre-Phase A advanced studie s diagram. to proceed shall be obtained from all directorate-level boa rds . For management decisions concerning entry into this phase, please refer to the PMC discussion in Section 2.5.3.3. 3.1.7 References The following document, which was used to prepare this section, offers additional insights into Pre-Phase A, Advanced Studies: 1

SP 6105, NASA Systems Engineering Handbook , 1995.

3-3


3.2 Phase A – Preliminar y Analysis 1,2 3.2.1 Overview Phase A, Preliminary Analysis, is performed to examine further the feasibility and desirable of a suggested new system and its compatibility with NASA strategic plans. During this phase, requirements and concepts are iterat ed to establish optimal system requirements and top -level system archite cture.

• • • • • •

3.2.2 Expected Results/Outcomes During Phase A, the project team should: • Refine bo th top-level functional and perfo rm-

•

• • • • • • • • • • •

3.2.4 Process The diagram at the top of t he following page ( FIG.

ance requirements criteria and metrics.and corresponding evaluation Develop and refine both system-lev el requirements and corresponding evaluation criteria and metrics. Develop interface requirements to external systems, if applicable. Identify alternative operations and logistics concepts. Demonstrate that credible, feasible system architecture designs exist. Examine alternative system architectural design concepts. Establish an optimized system architecture. Identify technical and technology risks, and outline mitigation plans. Initiate environmental impact studies, if applicable. Refine resource need estimates for the project.

3-2) indicates the steps in this phase of the project life cycle that should be accomplished in the course of evolving the system of interest. Interaction of these steps and the associated reviews is also illustrated along with the PM processes that should be refer enced in executing each activity.

Produce a needs statement. Produce a top-level operations concept. Produce a preliminary set of project plans, including preliminary versions of the project management plan (PMP), systems engineering (SE) management plan, risk management plan, technology development plan, and logistic plan.

are consistent with requirements and the operations and logistics concepts. Confirm that requirements and evaluation criteria are consistent with customer needs. • Demonstrate that operations and architecture concepts support missio n needs, goals, and objectives; assumptions, guidelines, and constraints; and project requirements. • Demonstrate that the process for managing change in requirements is established, documented in the project information repository, and communicated to stakeholders. Project Decisio n – Based on the results of the RR, the project manager shall decide whether to proceed with steps toward the establishment of optimum system architecture.

3.2.5 Reviews 3.2.5.1 The Requirements Review A Requirements Review (RR) shall be conducted, usually early in Phase A, to determine whether the requirements development and the requirements management functions are sufficiently established to proceed with determining the optimum system architecture. At the RR, the project team should be prepared to: • Demonstrate that project requirements are complete and understandable. • Demonstrate that prioritized evaluation criteria

•

3.2.3 Products The project definition package shall be the primary product of Phase A. This package documents the activities conducted during this phase to define project re quirements, systems architecture, and preliminary plans. The following are representative contents of this package: • A needs statement for the project • Project constraints and system boundaries • Top-level project and system requirements with corresponding evaluation criteria and metrics

• •

Feasibility studies Recommended system architecture Advanced technology requirements Risk studies, including mitigation plans Cost and schedule estimates A preliminary set of project plans, including preliminary versions of the PMP, SE management plan, risk management plan, technology development plan, and logistics plan.

3.2.5.2 The Definitio n Revie w A successful Definition Review (DR) shall be con-

(also known as figures of merit or measures of effectiveness) A list of credible, feasible systems architecture designs considered Alternative operations and logistics concepts

ducted to exiting PhasetoA. The purpose of the DR is toprior determine whether proceed with developing the proposed system architecture design and any technology needed to accomplish project goals. Review

3-4


Management Decision/Control Gate

•

Iterate Requirements and Concepts to Establish Opt imal System Requirements and Top-Level Architecture

Concep t Review

Analyze Requirements

Reviews

Establish Optimum Architecture

Requirements Review

Management Decision/Control Gate Definition Review Reviews

Reviews

Start

2.4 Define & Refine System Requirements

2.1 Refi ne To p-Level ProjectRequ irements

RequirementsDevelopme nt & Management

Requirements Developm ent & Management

2.6 Allocate Requirements To Elements

2.3 Develop & Refine Evaluation Criteria

Decomposition

Feasibility Study

2.5 Develop Alternative System Architecture & Concept s

2.2 Refine Mission Operations Concept(s)

Operations Concep t Development Feasibility Study; Technology Planning; Design

Operations Concept Development

2.8 Synthesize Down Select Feasibility Study

2.7 Analyz & Evaluate Architectures & Concept s Feasibility Study; Technology Planning


Manage ment and Pl anning Technology Planning, Acquisition Management, Risk Management, Quality Management, Work and Resource Management, Control, Configuration Management, Safety and Mission Success, Resource Management, Planning, Documentation and Data Management, Cost Estimating, Performance Measurement, Schedule Management, Project Analysis

DevelopToolsand Meth ods Verification, Validation, System Analysis,ibili Feas ty Study

Figure 3 -2. Phase A preliminary analysis diagram. •

results should reinforce project merit and provide a basis fo r the system acquisition strategy. At the DR, the project team should be prepared to: • Establish the proposed systems architecture design and the allocation of functional system requirements are optimized to satisfy project objectives with respect to the requirements trades and evaluation criteria established at the CR. • Demonstrate that system requirements meet project objectives. • Identify both technical and technology risks, and the plans to mitigate those risks. • Present refined cost, schedule, and personnel resource estimates. The following checklist should be used to aid in determining successful completion of the DR: • Will the selected system architecture desig n

•

• • • • • • •

•

meet system requirements and satisfy project objectives and stated needs? Are cost and schedule estimates in the preliminary plans realistic in view of sy stem require ments and the selected architecture?

•

3-5

Are system-level requirements complete, consistent, and verifiable? Have preliminary allocations been made to lower levels? Have the requirements trades converged on an optimized set of system requirements? Do the trades address project cost and schedule constraints as well as technical needs? Do the trades cover a broad spectrum of options? Have the remaining trades been identified to select a proposed system architecture design? Are plans in place for the design and development phases? Are the upper levels of the system product breakdown structure completely defined? Are decisions made as a result of the trades consistent with evaluation criteria established at the CR? Have major design issues been identified for the elements? Have technical and technology ris ks been identified, and have mitigation plans been developed?


3.2.7 References The following documents, which were used to prepare this section, offer additional insights into Phase A, Preliminary Analysis:

Project Decision – The project manager decides whether the project is ready to procee d to Phase B, Definition, for developing the system architecture/ design and any technology needed to accomplish the goals of the project. If the project is deemed ready, authorization is requested to proceed to Phase B, Definition.

1

SP 6105, NASA Systems Engineering Handbook , 1995. 2 NPR 7120.5B, NASA Progra m and Projec t Management Processes and Requirements , 2002.

3.2.6 Management Decision Directorate-level board(s) or its delegates shall authorize the project to proceed to Phase B, Definition, to develop the system architecture/design and any technology need to accomplish project goals.

3-6


3.3 Phase B – Definition 1,2 3.3.1 Overview Phase B, Definition, of the project life cycle is performed to establish an initial project “des ign-to” baseline. The baseline includes a formal flowdown of project-level performance requirements to a complete set of design specifications for the system of interest down to the lower levels of its architecture. During this phase, technical requirements are sufficiently detailed to establish fi rm schedule and cost estimates for the project. Early in Phase B, the effort focuses on system

A number of products should be prepared in support of the solution, including: • New or revised plans, such as the PMP, SE management plan, risk management plan, and other supporting plans such as specialt y engineering plans, safety plans, S/W management plans, test plans, and verification and validation pla ns. • System of interest functional requirements defined to the lowest level as appropriate, including internal and external interfaces (interface control documents (ICDs)) • •

requirements analysis andtosystem definition and selection, allocating functions particular items of hardware (H/W), software (S/W), personnel, etc. System functional and performance requirements along with architectures and designs are solidified as system of interest trade studies and subsystem trade studies iterate in an effort to seek ou t more cost-effective desi gns. Later in Phase B, the effort shifts to establishing a functionally complete, preliminary design solution that meets project goals and objectives. Trade studies continue. Interfaces among major end items are defined. Engineering test item s may be developed and us ed to derive data for further design work; and project risks are reduced by successful risk mitigation efforts, including technology developments and demonstrations. Phase B culminates in a series of Preliminary Design Reviews (PDRs), continuing the system of interest PDR and PDRs for lower-level end items, as appropriate.

• • • •

• •

Trade studies and feasibility analyses Verification requirements matrix Baseline co ncept of operati on Work breakdown structure (WBS) and dictionary Statement(s) of work (SOW(s)) System of interest c ost-effectiveness model, technical resource estimates, and life cycle cost estimates Technology development test results Acquisition strategies and requirements

3.3.4 Process Figures 3-3.1 and 3-3.2, which appea r at the top of the following pages, indicate the steps in Phase B that should be accomplished when evolving the system of interest. The interaction of these steps and their associated reviews are also illustrated in the figures along with the PM processes that should be referenced in executing each activity.

3.3.2 Expected Results/Outcomes During Phase B, the project team should: • Demonstrate that the system of interest architecture and design are acceptable, complete, and optimized relative to measures of effectiveness (e.g., figure of merit, performance goals, etc.), and that all requirement allocations to functional elements are complete. • Show that the system of interest design is correct and can be built to meet project ne eds, goals, and objectives. • Show that all major project risks have mitigation plans in place. • Show that all requirements are complete and consistent. • Show that the design meets cost and schedule constraints.

3.3.5 Reviews 3.3.5.1 The System Requirements Review The System Requirements Review (SRR) shall be conducted early in Phase B. The objective of this review is to confirm that system- level requirements and specifications are sufficient to meet project objectives . At the SRR, the project team should be prepared to demonstrate that systems -level requirements and specifications mee t project objective s. The following checklist is provided to aid in determining successful completion of the SRR: • Are allocations contained in the system of interest specifications sufficient to meet project objectives? • Are evaluation criteria established and realistic? • Are measures of effectiveness established and realistic? • Are cost estimates established and realistic?

3.3.3 Products A functionally complete solution that meets project goals and objectives shall be produced as the primary product of Phas e B. This solution shall be expressed and control as a “design-to” specification at all levels of the system architecture.

• •

3-7

Has a system verification concept been identified? Are appropriate plans being initiated to support project system development milestones?



Integrate Integration, Systems Analysis

Definition Review Reviews

System Definition Review(s)

System Requirements Review

Element C

Reviews

Element B

Reviews

Element A

Establish Optimum System Design

Analyze System Requirements

Start

3.1 Mission Requirements Analysis

3.3 Flowdown & Refine Requirements Requiremen ts Developme nt & Management, Decomposition

Requiremen ts Developme nt & Management

3.2 Develop System Evaluation Criteria Design

3.5 Allocate Requirements to End ems It

3.4 Develop & Refine Prime/Critical Item Requirements Managem ent, Concepts

3.6 Evaluate & Analyze System End Item Concepts Systems Analysis

Decomposition

3.7 Synthesize/Selec Optimal Option

Decomposition, Design

Design, Attainment Iterate Requirements and Concepts to Establish Optimal “De

sign-To” Baseline

Develop Technology Technology Planning

3.11 Develop & Refine Tools & Methods


Technology Planning

Mana gement and Planni ng Technology Planning, Acquisition Management, Risk Management, Quality Management, Control, Work and Resource Management, Configuration Management, Safety and Mission Success, Resource Management, Planning, Documentation and Data Management, Cost Estimating, Performance Management, Schedule Management, Project Analysis

Figure 3 -3.1. Phase B system definition diagram. 3.3.5.2 The System Definition Review A System Definition Review (SDR) shall be conducted to exit design s election and enter preliminary design. An SDR examines the proposed system architecture/design and the flowdown to all functional elements of the system to determine whether to proceed with developing the selected design and any technology needed to accomplish project goals. At the SDR, the project team should be prepared to: • Demonstrate that the architecture/design is acceptable, requirements allocation is complete, and a system that fulfills project objectives can be buil t within constr aints. • Ensure that the verification concept and preliminary verification program are defined. • Have established end item acceptance criteria. • Ensure that adequate detailed information exists to support initiation of further development or acquisition efforts.

Have technology development issues been identified along with approaches to their solution? • Have specialty engineering considerations been incorporated into the systems -level requirements and specifications? Project Decision – At the SRR, a decision is reached regarding whether the design team has demonstrated sufficient understanding of the mission for the system of interest, programmatic issues, and potential system of interest implementations to enable a commitment to the fe asibility of the desired capability. Successful completion of the SRR freezes project requirements and leads to a formal decision to proceed with preparations for project implementation. Complicated systems of interest with multiple elements may require multiple SRRs. The decision to proceed may result in the preparation of a request for a formal project start decision. •

3-8




Integration Systems/Elements/Lower Architectural Elements Integration



Reviews

Reviews

Lower Architectural Elements Preliminary Design

Start

4.1 Analyze & Refine Requirements Requiremen ts Developme nt & Management

4.2 Perform Design Analysis

4.6 Evaluate, Verify, & Validate Design

Design

SystemsValidation Analysis, Verification,

4.3 Perfor Engineering Developm ent Test s

4.5 Perform Preliminary Design

Verification

Design

4.7 Complete Plans Documentation for Qualification Items

4.4 Define Interfaces Decomposition, Design

Verification

Manag ement and Pl anning

X.X Phase Step

Technology Planning, Acquisition Management, Risk Management, Quality Management, Control, Work &Supporting Resource PM Process Manag ement, Configurati on Managem ent, Safety and Missi on Success, Resource Mana gement, Planning, Documentation and Data Management, Cost Estimating, Performance Measurement, Schedule Management, Project Analysis

Figure 3 -3.2. Phase B preliminary design diagram. The following checklist is provided to aid in determining successful completion of the SDR:

completion of the SDR releases both approved specifications for the system of interest and its elements and preliminary specifications for the design of appropriate functional elements. Authorization to proceed with preliminary design activities is requested.

•

Will the top-level system design selected meet system requirements, satisfy project objectives, and address operational needs? • Can the selected top-level system design be built within cost constraints and in a timely manner? • Have all s ystem-level requirements been allocated to one or more lower levels? • Have major design issues for the elements and subsystems been identified? Have majorrisk areas been identified and addressed with mitigation plans? • Have plans been completed to control the development design process? • Is a development verification/test plan in place to provide data for making informed design decisions? Is the minimum end item product performance documented in the acceptance criteria? • Is there sufficient information to support contract proposal efforts? Is there a complete, validated set of requirements with sufficient system defi nition to support cost and schedule estimates (if required)? Project Decisio n – At the SDR, a decision is made that indicates whether the system of interest and its operation are well enough understood to warrant design and acquisition of the end items. Successful

3.3.5.3 The Preliminary Design Review A PDR shall be conducted for the system of interest and for each of its major subsystems and/or c onfiguration items (CIs). The PDR is not a single review but is a number of reviews that includes the system of interest PDR and PDRs conducted o n sub-elements of the system. The PDR demonstrates that the preliminary design meets all system requirements with acceptable risk; shows that the correct design opti on has been selected, interfaces have been identified, and verification methods have been satisfactorily described; and establishes the basis for proceeding with detailed design. At the PDR, the project team should: •

3-9

Ensure that all system requirements have been allocated, the requirements are complete, and flowdown is adequate to verify system performance.


projects, the directorate-level decision may be to proceed with a commitment of in -house resources to proceed with Phase B project implementation. The first control gate decisions follows the SDR. For projects requi ring Center PMC autho rity to proceed, an Engineering Review Board (ERB) decision is reached regarding whether the system and its operation are well enough understood to warrant design and acquisition of the end items. Specifications are approved for the s ystem as well as preliminary specifications for the design of appropriate elements. Plans to control and integrate the expanded technical

Show that the proposed design is expected to meet the functional and performa nce require ments at the CI level. • Show sufficient maturity in the proposed design approach to proceed to final design • Show that the design is verifiable and the risks have been identified, characterized, and mitigated, where appropriate. The following checklist is provided to aid in determining successful completion of the PDR: • Can the proposed preliminary design meet all requirements within plann ed cost and sche dule? •

• • • • • •

•

• •

Have all external interfaces been identified? Have all system and segment requirements been allocated down to the CI level? Are all CI “design-to” specifications complete and ready for formal approval and release? Has an acceptable operations concept been developed? Does the proposed design satisfy requirements critical to human safety and project success? Do the human factors considerations of the proposed design support the intended end users’ ability to perfo rm and operate the system effectively? Have production, verification, operations, and other specialty engineering organizatio ns re viewed the design? Is the proposed design producible? How long lead items have been considered? Do specialty engineering project plans and

process are place. PMC approval a may project approved byinthe ERBJSC at this SDR controlfor gate be obt aine d outside of board (OSB). At the conclusion of the PDR is another control gate management decision point. This one approves the “design-to” baseline and authorizes the project to proceed to the design phase. The “design-to” baseline may include preliminary engineering design drawings, end-item specifications, prelim inary ICDs, and pre liminary S/W specifications. Identical to the SDR control gate, a decision to proceed into Phase C, Design, should be obtained from the directorate-level board or its delegate. The decisio n may also be prese nted to the ERB on re quest . 3.3.7 References The following documents, which were used to prepare this section, offer additional insights into Phase B, Definition: 1

SP 6105, NASA Systems Engineering Handbook ¸ 1995.

de sign specifications provide sufficie nt guidance, constraints, and systems requirements for design engineers to execute the design? • Is the reliability analysis based on sound methodology; and does it allow for realistic logistics planning and life cycle cost ana lysis? • Are sufficient project reserves and schedule slack available to proceed further? • Are the integrated logistics support analyses mature enough, and are they realistic? • Has the Safety and Mission Assurance Review Team approved of the Phase Isafety data package? Project Decisio n – After the PDR is successfull y completed, the “design-to” baseline and the Phase I safety data package are approved. Authorization is requested for the project to proceed to design phase.

2 NPR 7120.5B, NASA P rogram and Projec t Management Processes and Requirements , 2002.

3.3.6 Management Decision There are three d ecision points in Phase B. Th e SRR is sometimes referred to as an interim review rather than a “control gate” review. For large proj ects, the decision that is reached following the SRR is to begin/stop preparing for release of a request for propo sal (RFP) for Phase B studies. For smaller

3-10


3.4 Phase C – Design 1,2 3.4.1 Overview The Phase C, Design, phase of a project est ablishes a complete desig n “build-to” baseline that is ready to fabricate (or code), integrate, and verify. Trade studies continue. Engineering test units, which more closely resemble actual H/W, are built and tested to establish confidence that the design will function in the expected environments. Engineering specialty analysis results are integrated into the design, and the manufacturing process and controls are defined and validated. At each step in the successive refinement of the final

during this phase o f the project life cycle. The interaction of these steps and the associated reviews are also illustrated along with the PM processes that should be referenced to execute each activity.

design, corresponding and verification activities are planned inintegration greater detail. Phase C culminates in a series of Critical Design Reviews (CDRs) that contain the system of int erestlevel CDR and CDRs corresponding to different levels of the system hierarchy. At this point, a detailed design of the system of interest and its associated subsystems , including its operations systems, is complete and ready to be released.

system ofproblems interest des in fullanomalies detail; ascertains technical andign design have beenthat resolved; and ensures that the design ma turing justifies the decision to initiate fabrication/ manufacturing (or coding), integrati on, and verification of project H/W and S/W. At the CDR, the project team should be prepared to: • Ensure that the “build-to” baseline contains detailed H/W and S/W specifications that can meet functional and performance requirements. • Ensure that the design has been satisfactorily audited by s pecialty engineering organizations. • Ensure that production processes and controls are sufficient to proceed to fabrication (or coding). • Provide evidence that planned quality assurance (QA) activities will establish perceptive verification and screenin g processes to produce a quality product. • Verify that the final design fulfills specifications

3.4.5

Reviews – The Critical Design Review A CDR shall be conducted f or the system of interest and each of its major subsystems and/or CIs. The CDR is not a single review but is a number of reviews that includes the system of interest CDR and CDRs conducted on specific CIs. The CDR discloses the complete

3.4.2 Expected Results/Outcomes During Phase C, the project team should: • Establish a “build-to” baseline of the system of interest. • Verify that the detailed design meets system of interest requirements. • Ensure that verification and a cceptance testing requirements are satisfied. • Ensure that system of interest performance and operations requirements are satisfied.

at the PDR. Theestablished following checklist is provided to aid in determining successful completion of the CDR: • Can the proposed final design be expected to meet all requirements within planned cost and schedule? • Is the design complete? Are drawings ready to begin production? Is the S/W product definition sufficiently mature to start coding? • Is the “build-to” baseline sufficiently traceable to assure there are no orphan requirements? • Has all qualification testing been completed? • Are all internal interfaces completely defined and compatible? Are external interfaces current? • Are integrated safety analyses complete? Do these analyses show that identified hazards have been controlled, or has the appropriate authority waived the remaining risks that cannot be controlled?

3.4.3 Products During Phase C, a completed, detailed design of the system of interest and all its components – including subsystems, testing system, and operations systems – shall be expressed and controlled as the “build -to” baseline. This baseline should include: • Build-to specification(s) at all levels of the system architecture • A baseline of all requirements and designs, including traceability to all levels • Baseline updates to system architecture, verification requirements matrix, WBS, project plans, etc., reflecting project maturity • Baselined system integration, operations, and manufacturing plans • Completed and archived trade studies • A refined integrated logistics support plan •

•

Refined verification and validation plans

•

3.4.4 Process The diagram ( FIG. 3-4) at the top of the following page ind icates the steps that should be ac compli shed

3-11

Are production plans in place and reasonable? Are there adequate quality checks in the production process?



Integration Systems/Elements/Lower Architectural Elements Integration

Preliminary Design Review(s)

Critical Design Reviews(s)

Reviews

Reviews

Lower Architectural Elements

Star


Final Design

5.1 Define & Control Detailed Design Interfaces Decom position Design

5.5 Evaluate, Verify, & Validate Design

5.2 Perform Detailed Design

Design, Attainment Systems Analysis, Verification, Validation

Design

5.6 Complete Detailed Design & Production Plans

5.3 Perform Engineering Test Design, Verification

Design

5.4 Fabricates/Tests Qualification Items Verification

X.X Phase Step

Manag ement and Planni ng

Technology Planning, Acquisition Management, Risk Management, Quality Management, Control, Work &Supporting Resource PM Process Managemen t, Configuration Manag ement, Safety and Missi on Success, Resource Managem ent, Planning, Documentation and Data Management, Cost Estimating, Performance Measurement, Schedule Management, Project Analysis

Figure 3 -4. Phase C design diagram. 3.4.6 Management Decision The affected directorate-level board(s) provide authorization to initiate fabrication/manufa cturing (or coding), integration, and verification of project H/W and S/W.

Are the logistics support analyses adequate to identify integrated logistics support resource requirements? • Are comprehensive system integration and verification plans complete? • Has the Safety and Mission Assurance Review Team approved the Phase II safety data package? Project Decisio n – As a result of suc cessful CDR completion, the “build-to” baseline, produc tion plans, and verification plans are approved. Approved draw ings are released and authorized for fabrication. The decision is made to authorize coding of deliverable S/W and system qualification testing and integration. All open issues are resolved with closure actions an d schedules. The Phase II safety data packag e has been approved. Authorization to proceed to Phase D is requested. •

3.4.7 References The following documents, w hich were u sed to prepare this section, offer additional insights into Phase C, Design: 1

SP 6105, NASA Systems Engineering Handbook , 1995. 2 NASA Pr ogram a nd Proj ect Man NPR 7120.5B, agement Processes and Requirements , 2002.

3-12


3.5 Phase D – Development 1,2 3.5.1 Overview The purpose of the Phase D, Development, phase is to build and verify the system of interest designed in the previous phase, deploy it, and prepare it for operations. Activities include fabrication (e.g., H/W, S/W facilities construction), integration, ver ification, and d eployment of the system of interest. Additional activities include initial training of operating personnel and implementation of the logistics support plans. The major product is the system of interest that has bee n shown to be capable of accomplishing the purpose

terest from design to operational use. The interaction of these steps and the associated reviews are also il lustrated along with the PM processes tha t should be referenced in executing each activity. During this phase of the life cycle, the system of interest is transformed through three distinct stages, each of which is bounded by control gates. These three stages include fabrication and integration, preparation for deployment, and deployment and operational verification.

for which it was created. 3.5.2 Expected Results/Outcomes During Phase D, the project team should: • Build—i.e., fabricate (or code)— the end items (i.e., the lowest-level items in the system of interest architecture). • Integrate end items according to the integration plan and perform verifications, thereby yielding verified components and subsystems. Repeat this process of successive integration until a verified system is achieved. • Verify and validate the system; i.e., develop verification and validation procedures at all levels, and perform system of interest qualification verification(s) and acceptance verification(s) and validation(s). • Prepare for operations; i.e., prepare the operators’ manuals and maintenance manuals. Train initial system operators and maintainers, perform operational verification(s), audit “as-built” configurations, and finalize and implement an integrated logistics support plan. 3.5.3 Products The primary product of Phase D shall consist of the completed, verified, validated, and accepted system of interest and associated documentation necessary for normal operations. Example products include: • Verified and validated H/W and S/W products • “As -built” and “as-deployed” documenta tion • Updated logistics support plans • Operations plans and procedures, including operations, maintenance, and disposal procedures • Training materials • Documentation of lessons learned • Verification, validation, and acceptance data • Problem/failure reports 3.5.4 Process The following diagrams ( FIGS. 3-5.1, 3-5.2, and 3-5.3) indicate the steps in Phase D that should be accomplished in the course of evolving the system of in -

3-13



Manufacture & Assembly


Integration & Test

Integrate Systems, Control & Verify Interfaces

Critical Design Review(s)

System Acceptanc Review

Integration, Control

Reviews

Reviews Subsystems

Production Lower Architectural Elements Readiness Reviews(s)

Star

Test Readiness Reviews(s)

Reviews

6.1 Ready Production Facilities

Reviews

6.2 Fabricate/Assemble End Item Attainment

Attainmen

6.5 Test/Verify End Item Attainment, Systems Analysis, Verification, Validation

6.6 Assemble Physically Integrate System

Attainment, Verification

Integration, Verification, Validation

6.4 Complete Plans/ Documentation for End Item

6.8 Complete Plans & Documentation for System

Attainment

Verification, Validation

Integration

6.7 Complete Test Plans & Documentation for System

6.3 Complete End Item Verification Test

6.9 Test/Verify System

6.10 Perform Acceptance Testing Validation


Integration

Train Manag ement and Planni ng Technology Planning, Acquisition Management, Risk Management, Quality Management, Control, Work and Resource Management, Configuration Management, Safety and Mission Success, Resource Management, Planning, Documentation and Data Management, Cost Estimating, Performance Measurement, Schedule Management, Project Analysis

Figure 3 -5.1 Phase D development – fabrication and integration stage diagram.

3-14


Management Decision/Control Gate System Acceptanc Reviews

Deployment Readiness Review

Reviews

Review

Start

7.2 Configure Hardware CM, Control

7.3 Configure Software CM, Control

7.1 Deliver/Install System

7.4 Configure Support System CM, Control

7.7 Complete Integrated Pre-Deployment Checkout Verification

7.5 Prepare Personnel

7.6 Update Ops Plans & Procedures


Work & Resource Management,C

Manage ment and Pl anning Technology Planning, Acquisi tion Management, Risk Managem ent, Quali ty Manageme nt, Control, Work and Re source Manage ment, Configuration Management, Safety and Mission Success, Resource Management, Planning, Documentation and Data Management, Cost Estimating, Performance Measurement, Schedule Management, Project Analysis

Figure 3 -5.2. Phase D development – preparation for deployment stage diagram.

3-15


•


Deployment Readiness Review

Operational Readiness Review

Review

Reviews

8.1 Deploy Start

8.2 Configure for Checkout and Operations Validation

8.3 Demonstrate Operational Capability X.X Phase Step

Validation

Supporting PM process

Manag ement and Planni ng Technology Planning, Acquisition Management, Risk Management, Quality Management, Control, Work and Resource Management, Configuration Management, Safety and Mission Success, Resource Management, Planning, Documentation and Data Management, Cost Estimating, Performance Measurement, Schedule Measurement, Project Analysis

Figure 3 -5.3. Phase D development – deployment and operational verification stage diagram. 3.5.5

Reviews •

3.5.5.1 The Production Readiness Review A Production Readiness Review (ProRR) shall be conducted to ensure that production plans, facilities, and personnel are in place an d ready to begin production. The ProRR is conducted after the CDR and prior to the start of production. At the ProRR, the project team should be prepared to: • Demonstrate that all significant production engineering problems encountered during development, including S/W problems, have been resolved. • Ensure that the design documentation is adequate to support manufacturing, fabrication, or coding. • Ensure that production plans and preparations are adequate to begin manufacturing, fabrication, or coding. • Establish that adequate resources have been allocated to support en d item production. The following checklist should be used to aid in

Has the bill of m aterials been reviewed , and have critical parts been identified? • Have delivery schedules been verified? • Have alternative sources been identified? • Have adequate spares been planned and budgeted? • Are the facilities and tools sufficient for end item production? Are special tools and test equipment specified in proper quantities? • Are personnel qualified? • Are drawings baselined? • Is production engineering and planning mature for cost-effective production? • Are production processes and methods consistent with quality requirements, and are they compliant with occupation safety, environmental, and energy conservation regulations? Project Decisio n – A successfu l ProRR results in certification of production readiness by the project manager and involved specialty engineering organ-

determining successful completion of the ProRR: • Is the design baselined? Have incomplete design elements been identified? • Have risks been identified and characterized and mitigation efforts defined?

izations. The project manager recommends whether to proceed to production.

3-16


3.5.5.2 The Test Readiness Review A Test Readiness Review (TRR) shall be conducted to ensure that all t est article H/W and S/W, the test facility, ground support personnel, and test procedures are ready for integrated testing, data acquisition, reduction, and control. The TRR is conducted after system fabrication and integration, but prior to the start of a formal test cycle. At the TRR, the project team should be prepared to: • Confirm that in-place test plans meet verification requirements and specifications. • Confirm that sufficient resources are allocated

•

to the testdetailed effort. test procedures for completeExamine ness and safety. • Determine that critical test personnel are tes tand safety-certified. • Confirm that test support S/W is adequate, pertinent, and verified. The following checklist should be used to aid in determining successful completion of the TRR: • Have the test cases been reviewed and analyzed for expected results? • Are the results consistent with the test plans and objectives? • Have the test procedure been “dry run?” If so, do they indicate satisfactory operation? • Have test personnel received training and certification, if required, in test operations and s afety procedures? • Are resources available to adequately support

•

• •

•

Establish that the system is ready to be delivered and accepted under DD -250. Ensure that the system meets acceptance criteria established at the SDR. Establish th at the system meets requirements and will function properly in the expected operational environments as reflected in test data, demonstrations, and analyses. Establish an understanding of the capabilities and operational constraints of the “as -built” system, and ensure that the documentation delivered with the system is complete and current.

For flight systems, ensure that the sy stem (H/W and S/W) has been certified for flight. This certification includes successful H/W qualification testing of the qualification unit and H/W and/or S/W acceptance testing of the flight unit. Certification documentation includes the following: identification (part number, part name), baseline requirements and associated verifications, safety data package, baseline test and analysis, documentation (qualification and acceptance plans, procedures, reports), limited-life item list, approved waivers, or deviations and material usage agreements (MUAs), etc. The following checklist should be used to aid in determining successful compl etion o f the SAR: • Are tests and analyses complete? • Do the tests and analyses indicate th at the system will function properly in the expected operational environment(s)?

•

•

planned tests as well as contingencies, including failed H/W replacement? • Has the test support S/W been demonstrated to handle test configuration assignments, data acquisition, reduction, control, and archiving? Project Decision – A successful TRR results in certification of formal system test readiness by the project manager and involved specialty engineering organizations. The project manager decides whether to proceed with planned system verification and acceptance testing.

Does the system meet the criteria described in the acceptance plans? Does the system meet the nee ds of the stakeholders? • Is the system ready to be delivered (e.g., flight items to the launch site a nd non-flight items to the intended operational facility for installation)? • Is the system documentation complete and accurate? • Is it clear what is be ing bought? • Has all open work been identified and dispositioned? • Has the Safety and Mission Assurance Review Team approved the Phase III safety data package? Project Decisio n – A successful SAR results in the approval of the “as -built” baseline by the project manager, involved specialty engineering organizations, and the customer. The project manager recommends whether to proceed to prepare the system fo r deployment. •

3.5.5.3 The System Acceptance Review A System Acceptance Review (SAR) shall be conducted to examine the system, its end items and documentation, and the test data and analyses that support its verification. The SAR also ensures that the system has sufficient technical maturity to authorize its shipment to and installation at the launch site or intended operational facility. SAR is and conducted near co mpletion of the systemThe fabrication integration stage, and prior to preparations for deployment. At the SAR, the project team should be prepared to:

3.5.5.4 The Deployment Readiness Review A Deployment Readiness Review shall be conducted to demonstrate that the system is ready for deployment. This review includes examining tests,

3-17


demonstrations, analyses, and audits. It also ensures that all H/W, S/W, personnel, and procedures are operationally ready. In a flight environment, this review equates to a Flight Readiness Review (FRR) where system readiness for a safe and successful launch and for subsequent flight operations is determined. The De ployment Readiness Review i s conducted on completion of delivery, installation and configura tion of the system but prior to system deployment and the operational capability demonstration. At the Deployment Readiness Review, the project team should be prepared to:

support (i.e., normal, contingency, and unplanned.) • Establish that operational documentation is complete and that this documentation represents the system of interest configuration and its planned modes of operation. • Establish that the training function is in place and has demonstrated a capability to support all aspects of system of interest maintenance, preparation, operation, and recovery. The following checklist should be used to aid in determining successful completion of the ORR:

•

•

Certify that system operations can safely proceed with acceptable risk. Confirm that system and support elements are properly configured and ready. • Establish that all interfaces are compatible and function as expected. • Establish that the system state supports a “go” decision based on go/no-go criteria. The following checklist should be used to aid in determining successful completion of the Deployment Readiness Review: • Are the system elements ready to support operations? • Is the system safe and capable of achieving mission success? • Are the system interfaces checked out and found to be functional? • Are all environmental factors within constraints ? • Have all open items a nd waivers been examin ed

Are system of interest H/W, S/W, personnel, and procedures in place to support operation? Have all detected anomalies been resolved, documented, and incorporated into existing operational support data? • Are the changes that are necessary to transition the system of interest to an operational configuration ready to be made? • Are all waivers closed? • Are the resources in place or financially planned and approved to support the system of interest during its operational lifetime? Project Decision – Based on the results of the ORR, the project manager, with concurrence from the customer, recommends whether to assume normal operational use of the system of interest.

and found to be acceptable? Project Decision – Based on the result s of the Deployment Readiness Review, the project manager recommends whether to proceed with steps toward deployment and operational verification of the system.

decisions are necessary: • Upon completion of system verification and acceptance testing, authorize the project to proceed in preparation for delivery and installation of the system for operational use. • Upon completion of system deployment and demonstration of operational capabilities, authorize the project to commence normal operations for the system.

•

•

3.5.6 Management Decision During Phase D, Development, two management

3.5.5.5 The Operational Readiness Review An Operational Readiness Review (ORR) shall be conducted to examine the actual system characteristics and procedures used in the system of interest’s opera tion, and to ensure that all H/W, S/W, personnel, procedures, and user documentation accurately reflect the deployed state of the sy stem of interest. The ORR is conducted when the system of interest and its operational and support equip ment and personnel are read y to become operational. At the ORR, the project team should be prepared to: • Establish that the system of interest is ready to transition into an operational mode through ex-

•

3.5.7 References The following documents, which were used to prepare this section, offer additional insights into Phase D, Development: 1

SP 6105, NASA Systems Engineering Handbook , 1995. 2 NPR 7120.5B, NASA Pr ogram a nd Proj ect Man agement Processes and Requirements , 2002.

amination ofdemonstrations. available test results, analyses, and operational Confirm that the system of interest is operationally and logistically supported in a satisfactory manner considering all modes of operation and

3-18


3.5 Phase E – Operati ons1,2 3.6.1 Overview The purpose of Phase E, Operations, is to use t he system of interest to meet its initially identified need. The Operations phase encom passes the use of the sys tem of interest; the maintenance an d upgrade of the sys tem of interest; and the training of personnel w ho operate, maintain, and upgrade the system of interest. Evolution of the system of interest is included in this phase, as long as the changes do not involve major changes to the architecture. (Changes of that scope constitute new requirements, and the project life c y-

3.6.5 3.6.5.1

cle starts over.) This phaseand alsodisposal deals with preparation for the safe decommission of the system of interest at the end of its operational life, though the costs and risks associated with decommission and dis posal should be considered during earlier phases of the project life cycle.

present system upgrades to the project staff. This typeplanned of review is primarily informational, however approval is required when any change to critical systems is needed or extra resources are required. At the System Upgrade Reviews, the project team should be prepared to: • Show before and after physical architecture diagrams. • Show before and after functional architecture diagrams. • Show before and after data diagrams. • Describe any H/W and/or S/W changes. • Describe the impact to operational procedures or training. • Provide an upgrade schedule. The following checklist should be used to aid in determining successful completion of the System Upgrade Review: • Has the rationale for the upgrade been sufficient-

Reviews The Delta Operational Readiness Review Delta ORRs shall be conducted in Phase E whenever significant system changes occur. These reviews are typically held a few weeks or even a few months before operational use of the system changes. Delta ORRs essentially have the same content as the ORR described in Section 3.5.5.5. 3.6.5.2 The System Upgrade Review System Upgrade Reviews are held, as necessary, to

3.6.2 Expected Results/Outcomes During Phase E, the project team shall: • Operationally use the system of interest. • Maintain an upgrade the system of interest. • Train operations and maintenance personnel. • Prepare to conduct the decommissioning review. • Document lessons learned. • Conduct delta ORRs. • Conduct safety reviews. • Conduct upgrade reviews. 3.6.3

Products

Phase E products are the results of the operational use of the system of interest. Examples of these include: • System-intended products or services delivered • Engineering data on system, subsystem, and materials performance • Operations and maintenance logs • Problem/failure reports • Decommissioning studies • Lessons learned documents • System upgrade proposals

ly described? Are changes to the system fully described in diagrams and text? • Do operations and training personnel completely understand the impacts to their procedures? • Are all costs associated with the upgrades provided? • Does the schedule allow enough time for necessary changes by the affected parties? • Where is the appropriate life cycle phase to re enter to implement upgrades? • Is a delta ORR required as a result of the changes ? Project Decision – The project manager decides whether to recommendproceeding with systemupgrades. •

3.6.4 Process The diagram ( FIG. 3-6) at the top of the following page indicates the steps in this phase of the project life cycle that should be accomplished in the course of evolving the system of interest. Interaction of these steps and the associated reviews are also illustrated along with the PM processes that should be referenced in executing each activity.

3.6.5.3 The Safety Review Periodic Safety Reviews are held to examine the established safety procedures and identified hazards. At the Safety Review, the project team should be prepared to: • • •

3-19

Examine current safety documentation. Review all safety incidents, their resolution, or plans for their resolution. Review all identified safety hazards and their mitigation procedures.




System Upgrade Review

Critical Design Review(s)

Management Decision/Control Gate (Delta) Operational Readiness Review Reviews

Start

Reenter Appropriate Life Cycle Phase

Reviews

Reviews

9.6 Distribute System Products

9.8 Update Documentation

9.10 Sequential Production

Attainment Control

Work & Resource Mgmt. Configuration Mgmt.

Work & Resource Mgmt. Control

9.1Operations Configure for

9.9 Improvement Block Changes

Configuration Mgmt. Control

Rqmts. Development Requirements Mgmt. Feasibility Study Technology Planning Design Systems Analysis

9.2 Ope rate he t System Work & Resource Mgmt. Configuration Mgmt. Safety Control

9.3 Train Personnel Work & Resource Mgmt. Control

9.7 Assess Trends

9.4 Maintain System

Work & Resource Mgmt. Control

Work & Resource Mgmt. Configuration Mgmt. Acquisition Mgt. Control

Safety Review Reviews

10.1 Preparation for Decommission/ Disposal Work & Resource Mgmt. Control

X.X Phase Stop Supporting PM Process

9.5 Support System Work & Resource Mgmt. Quality

Manag ement and Planni ng Technology Planning, Acquisition Management, Risk Management, Quality Management, Control, Work and Resource Management, Configuration Management, Safety and Mission Success, Resource Management, Documentation and Data Management, Cost Estimating, Performance Measurement, Schedule Management, Project Analysis

Figure 3 -6. Phase E operations diagram. decommissioning studies and begin preparations for the Decommissioning Review.

Identify new safety hazards and plans to resolve or mitigate them. The following checklist should be used to aid in determining successful completion of the Safety Review: • Is current safety documentation up to date and accessible to all personnel? • Have all safety incidents been properly addressed? • Are current safety procedures still relevant and effective? Project Decision – The project must decide whether current safety procedures and identified hazards and resolutions are acceptable. •

3.6.6 Management Decision Directorate-level boards may/may not authorize the project to proceed with system operations. Customer management boards (whether Center- or program-level) may authorize recommended system upgrades. 3.6.7 References The following documents, which were used to prepare this section, offer additional insights into Phase E, Operations: 1 SP 6105,NASA Systems Engineering Handbook, 1995.

3.6.5.4 The Decommissioning Review Details of the Decommission Review are addressed in Section 3.7. In this phase, the project shall initiate

2 NPR 7120.5B, NASA Pr ogram a nd Proj ect Man agement Processes and Requirements , 2002.

3-20


3.7 Project Termination 1 3.7.1 Overview During Project Termination, the project team methodically plans and performs actions that bring the project to a timely, orderly conclusion, and efficiently and safely remove the system from the field of operational or active NASA interest. Project termination generally occurs for one of the following reasons: • The project has successfully completed Phase E, Operations, and the system of interest is nominally approaching the end of its planned useful

−

decommissioning and disposal, and project/system personnel transition. • Maintain the capability to continue system operations in the event that decommissioning is postponed at the Decommissioning Review. Participate in a Decommissioning Review. The Decommissioning Review will either approve termination and disposal as planned or with modifications, or decide on new schedule/performance/safety/cost- based trigger(s) for postponed termination and disposal.

service life. has exceeded safety, cost, and/or The project schedule limits to an unacceptable degree during its design, development, or operations. • The project is anticipated to be unable to meet the commitments contained in project controlling agreements and plans. • The project need is no longer valid. Project termination activities are pl anned and conducted so that appropriate degrees of oversight and control are provided both to the concluding stages of the project, whether nominal or off -nominal, and to the justification of, preparation for, and execution and documentation of decommissioning and/or disposal of the system of interest.

•

3.7.2 Activities The sets of activities differ for nominal and offnominal termination.

•

•

•

3.7.2.1 Nominal termination For nominal project Termination during operations, the project shall: • Monitor the schedule to stay informed of the approach of the nominal end of schedule system service life. − At an appropriate time, in advance of the end of service life, begin and complete preparations to make removal of the system of interest from service as efficiently, safely, and otherwise acceptable to the system operating environment as constraints permit. • Remind all stakeholders of the approach of the end of schedule system service life. • Gather and prepare to present information, as avai lable, that both supports and oppos es o n-time termination of the project and disposal of the system. • Coordinate and document detailed plans for nominal project termination, system

If decommissioning is approved: − Terminate project activity and support disposal of the system of interest and transition of personnel as planned or as redirected from plans by the Decommissioning Review. − Document project closeout, support system decommissioning/disposal documentation insofar as project personnel are involved, and turn over control of the project information repo sitory to the next -higher tier of management. If decommissioning is approved with modifications, plan modifications shall be made and presented to the Decommis sioning Review Board for concurrence. If decommissioning is postponed, continue system operations and either: − Prepare as before to meet the Decom-

−

missioning Review’s new schedulebased termination target; or Monitor and assess trends using Decommissioning Review-designated performance/safety/cost triggers to recommend the next appropriate termination target .

3.7.2.2 Off-nominal termination Entry into the off-nominal termination phase occurs as a result of a Termination Review decision by the JSC Project Management Council (PMC) or the PMP designated authority. The Termination Review is held due to violation of established thresholds, anticipated inability to meet established commitments, or the project need no longer being valid. The project shall: • Support the JSC PMC or the authority designated by the PMP project Termination Review. −

3-21

The project Termination Review shall either direct termination or establish new schedule/ performance/safety/cost-based trigger(s) or agreements to permit continued design, development, or operations.


•

3.7.5 Reviews 3.7.5.1 The Termination Review A Termination Review is held in the off-nominal case to review violations of established project thresholds and/or anticipated inability to meet established commitments. At the review, the project should be prepared to detail: • Current project status, concentrating on the contributors to the violation of established proj ect threshold and/or anticipated inability to meet the established commitments that necessitated the review.

Upon direction to terminate, prepare to remove the system of interest from service in a manner that is efficient, safe, and acceptable to the system. − Inform all stakeholders of the decision to terminate the project early, and dispose of the system of interest or its unintegrated elements before the scheduled end of service life. − Gather and prepare to present information, as available, that both supports and opposes the proposed early termination of the project and disposal of the system.

•

−

•

Coordinate and document detailed plans for early project termination, system disposal, and personnel transition. Participate in a Decommissioning Review, which will approve decommissioning plans either as presented or with modifications. − If decommissioning is approved with modifications, the plan modifications shall be made and presented to t he Decommissioning Review Board for concurrence. − If decommissioning is approved: • Terminate project activity, and support disposal of the system of interest and transition of project/system personnel as planned or as redirected from plans by the Decommissioning Review. • Document project closeout, support system decommissioning/disposal documentation insofar as project personnel

The justification and authority of the established threshold or agreement. The result of this review will be a decision, by the governing authority (JSC PMC- or PMP-design ated authority) to terminate the project or to establish new thresholds to continue design development or operations. 3.7.5.2 The Decommissioning Review In the nominal case, a Decommissioning Review is conducted to determine whether and how to terminate the project and dispose of the system. If the off -nominal case, the review is conducted to determine only how to terminate the project and dispose of the system. In either case, as with most reviews, the project team contributes significant technical content. At the review, the project team should be prepared to: • Cite the authority under which they initiated preparations for termination of the project, dis posal of the system of interest, and transition of project/system personnel. • Discuss the pro ject schedule. • Demonstrate that plans for project termination, system decommissioning and disposal, and project/system personnel transition at the pro posed time are: − Feasible. − Consistent with requirements. 1 − Acceptable to stakeholders. − Efficient, safe, and acceptable to the system operating environment as constraints permit. For the nominal case, • Present information as available, both supporting and opposing the proposed termination of the project and disposal of the system. For the off-nominal case, • Cite the authoritative direction to terminate and dispose.

are involved, and turn over control of the project information repository to the next-higher tier of management. 3.7.3 Products During Project Termination planning, the following are documented: • Evidence supporting and/or opposing Project Termination and system disposal at the planned time • System decommissioning/disposal requirements and plans • Project closeout requirements and plans • Project/system personnel transition requirements and plans • Lessons learned 3.7.4 Process The diagrams ( FIGS. 3 -7.1 and 3-7.2) on t he follow-

•

ing page indicate the steps involved in off-nominal and nominal Project Termination and decommissioning. The interaction of these steps and the associated re views is also illustrated along with the processes that should be referenced in executing each activity.

3-22

Review any top-level implementing guidance that the project received during planning for termination and disposal.


Life Cycle Phases B – E

Termination

(Definition, Design, Development, Operations)

Continuous Performance Assessment Risk Management, Safety, Quality, Systems Analysis, Project Control

10.1 Prepare for Disposal •

Need Valid

No

PMP threshold violation/ Yes anticipated inability to meet commitment

•

Manag ement Decisi on/ Control Gate

Terminate

Alert Stakeholders Write and Coordinate Detailed Plans

Yes

ermination Review (JSC PMC- or PMDesignated Authority)

Reviews

With Mods Make Modifications As Necessary

No No


Decommissioning Review

As Planned

10.2 Decomm ission/Dispose Implementation Plan • Terminate Project • Dispose of System • Transition Personnel • Document Actions and Decisions • Give Repository to NextHigher Tier

Reestablish Thresholds/ Legitimize Need

Key:

Step Name/Descriptio n

•

Decision

Supporting PM Process •

Verify Proper Plan Implementation Provide Assurance to Decomm issioning Review Authority

Figure 3 -7.1. Off-nominal project termination diagram.

Life Cycle Phase E

Termination

(Operations)

Monitor Schedule

10.1 Prepare for Disposal

Schedule Management

No

Nominal End of Life Approaching

Inform Stakeholders • Gather Information For and Against • Write and Coordinate Detailed Plans • Maintain Capability to Continue Operations •

Yes

Management

Decommissioning Review

Decision/Control Gate

Reviews

With Mods

Postponed

As Planned

Make Modifications as necessary 10.2 Decom mission/Dispose Implementation Plan Terminate Project Dispose of System Transition Personnel • Document Actions and Decisions • Give Repository to NextHigher Tier • • •

Key:

Step Name/Descriptio n

•

Decision

•

Supporting PM Process

Figure 3 -7.2. Nominal project termination diagram.

3-23

Verify Proper Plan Implementation Provide Assurance to Decomm issio ning Review Authority


A successful Decommissioning Review assures that the decommissioning and disposal of system items and processes is appropriate and effective. This review determines whether the following conditions are met prior to decommissioning: • Reasons for decommissioning/disposal are documented • Disposal plan is complete and in compliance with local, state, and Federal environmental regulations • Disposal plan addresses disposition of H/W, S/W, facilities, processes, and any contractual/ • • • •

Subsequent to implem entation of the decommis sioning and disposal plans, assurance that these two plans were impl emente d as agreed is provided to the authority approving the plans. 3.7.6 Management Decision Management will direct whether to proceed with project termination, system disposal, and personnel transition in accordance with specific plans described at the Termination Review and Decommissioning Review, and, if not, what modifications to prescribe. 3.7.7 References The following document, which was used to prepare this section, offers additional insights into Project Termination:

procurement actions necessary Disposal risks have bee n assessed Data archival plans have been defined Sufficient resources are assigned to complete the disposal plan A personnel transition plan is in place

1

NPD 8010.3, Notification of Intent to Termi nate Operating Space Systems , 1999.

3-24


P ro j e c t M a n a g e m e n t P r o c e s se s a n d R e q u ire m e n ts

Project Management Processes and Requirements

Chapter 4 Project Management Processes and Requirements

Methods and techniques – Provides a list of available methodologies and techniques that could be used to execute the process steps. • Software tools – Provides a brief discussion of the functions provided by typical software (S/W) tools available to support the process. • References – Lists sources used to prepare the content of the process section or that can offer further insight into the process. The following paragraphs introduce several concepts and nomenclatures that are key for understanding the content of the PM processes covered in this chapter. •

This chapter outlines the processes and requirements in support of Johnson Space Center (JSC) projects. It is divided into three sections. Section 4.1 addresses the systems engineer ing (SE) pro cesses; Section 4.2 addresses the project control processes; and Section 4.3 presents those processes that cut across SE and project control. The following information is presented for each process: • Process overview – Provides a top-level summary narrative of the overall objective of the process, major process steps, products, and relationships with other project management (PM) processes. • Function – Provides the requirements for tasks and expected outcomes resulting from the process. • Objective – Defines the purpose of the process. • Responsibilities – Outlines the roles of key project team members in planning and executing the proc ess steps. • Life cycle – Identifies the project life cycle phases supp orted by the process. • Inputs – Identifies the main inputs that support execution of the process. • Steps – Outlines the required main steps and preferred sequence of steps invol ved in executing the process. Steps are annotated with support of information that provides additional detail and clarification. • Outputs – Identifies the primary outputs from the process. • Exit criteria – Provides conditions for determining process completion. • Measurement – Identifies example base and derived measures that may be used in conjunction with executing the process. Base measures are simple measures relating to the primary activity that is being performed. Derived measures apply some algorithm to the base measure to provide trending data for corrective action analysis and future planning and estimating. While example measures are provided, it is the project team’s responsibility to identify those measures that provide appropriate insight into the health of this project process. The procedure, which is defined in SLP 4.20, Process Measurement and Improvement, should be followed to properly identify, collect, analyze, and report project measures.

In this chapter,“system extensive is made to the terms “system,” of reference interest,” and “enabling system.” These c oncepts are briefly explained below. • A “system” is the combination of elements that functions together to produce the capability required to meet a need. Elements include all of the hardware (H/W), S/W, equipment, facilities, personnel, a nd processes and procedures needed for this purpose. • The “system of interest” is the entity for which the project engineering team is responsible for designing, developing, integrating, and testing. The system of interest may be at any level in the hierarchy of a complex syst em. In considering a spacecraft, for example, the system of interest may be at the space craft level, the communications system level, or the avionics box level. The system of interest may include human-level interactions. ( FIG. 4-1). •

“Enabling systems” are those systems that complement the system of interest by providing essential services (e.g., launch, tracking and data relay, and navigation services) that comple ment the systems of interest but do not contribute directly to their functioning ( FIG. 4-2). In this documen t, the nomencl ature used to denote the decomposition of the system of interest is shown on page 4-3, Figure 4-3. Another important concept introduced here is that of project scope. Project scope constitutes the vision for the project and consists of the following el ements: • Need to develop or procure a system • Goals and objectives of the customer and stakeholders • Information about the customers and users of the system • How the system will be developed or purchased, tested, deployed, and used. Project scope also the boundaries constraints of both theincludes project and the system.and

4-1


Figure 4 -1. Example of three levels of system of intere st.

Figure 4 -2. Example of enabling systems.

4-2


Parent System

Systems of Interest

Enabling System(s)

····· SystemElementN (or Subsystem)

SystemElement1 (or Subsystem)



EndItems

EndItems

Figure 4 -3. Decomposition of the systems of interest. 4.0.1 References The following documents, which were used to prepare this section, offer additional insights into the PM processes:

Key elements of the p roject scope are needs, goals, and objectives. The relationship among these is depicted in Figure 4-4. Project scope is defined up front, such that the vision and constraints of the project are clearly understood by the project team before requirements are written. This is an essential component that ensur es the success of the project. The concept of project scope is reflected in the PM processes addressed in this chapter.

1

NPR 71xx.x (document number not yet assigned), Systems Engineering Processes and Requirements . 2

Hooks I, Farry K. Customer-Centered Products , American Management Association (AMACO M), 2001.

Needs ? Reason for the Project ? Derived from the Problem Statement ? Should Not Change Much Over Time Example: “The Nation has a Need for Assured Human-Rated Space TransGoals portation." ? Define What Actions Must Be Accomplished to Meet the Needs ? Derived from the Needs Example: “To Fly Safely”

Objectives ? Defin e Howthe Needs and Goals Are Accomplished (how do we know when w e get here) t Example: “One Vehicle Loss in 500 Flights”

Figure 4 -4. Relationship among needs, goals, and objectives.

4-3


4.1.1.5 Inputs 2,3 There are three types of inputs to the Requirements Development process: (1) statement of need or project request made by the customer from the agreement, other documents, enabling systems, and stakeholders that have a stake in the outcome of the system of in terest; (2) requirements in the form of outcomes from other processes, such as technical plans and decisions from technical reviews; and (3) requested or approved changes to requirements of the first type. Typical inputs to the Requirements Development process should include, but are not limited to:

4.1 Systems Engineering Processes 4.1.1 Requirements Development 1,2 The Requirements Development process is performed to gather needs and constraints and to transform them into agreed-to requirements for the system of interest. These requirements, which are stated in acceptable technical terms, represent a complete description of the system of interest. The same Requirements Development process will be used to evaluate changes to requirements in an agreement or when other stakeholder requirements are identified that affect the system of interest.

•

4.1.1.1 Function1 In the Requirements Development process: • Customer and stakeholder needs shall be defined. • System of interest requirements shall be verified and validated. • Requirements shall be evaluated and maintained due to changes in the needs or const raints of the system of interest. • Requirements traceability/flow down shall be established. • All technical requirements shall be documented.

• • • • • • • • •

4.1.1.2 Objective 1,2 The primary objective is to produce and analyze re quirements that will serve as the foundation for establishing the functions that a system of interest has to perform, how well the system of interest must perform, and with what systems it must interact. Requirements – which, depending on design maturity, take the form of specifications, drawings, models, or other design documents – are used to (1) build, code, assemble, and integrate end products; (2) verify end products against; (3) obtain off-the-shelf products; or (4) assign a supplier for development of subsystem products.

Goals objectivesneeds Projectand or customer Stakeholder needs Assumptions, guidelines, and constraints (e.g., from specialty and design engineering) Technology availability, maturity, costs, and risks Outputs from preceding projects Records of meetings and conversations with the customer Policies and procedures Laws and regulations Operations concepts

4.1.1.6 Steps 4 SE performs all of the steps in the Requirements Development process. The diagram at the top of the following page ( FIG. 4.1-1) illustrates the major steps and products of the Requirements Development process. The three major steps are to (1) develop customer requirements, (2) develop system of interest requir e ments, and (3) analyze and validate requirements. These steps are progressively and iteratively executed until a validated set of requirements is achieved. The internal steps are shown in this illustration as well. The following adds detail to the steps illustrated: • Develop Customer Requirements – Stakeholder needs, expectations, constraints, and interfaces shall be collected and translated into customer requirements. − Elicit and Collect Stakeholder Needs • Elicit, identify, and collect stakeholder needs, expectations, constraints, and interfaces for all phases of the system of interest life cycle. • Engage relevant stakeholders using methods for eliciting needs, expectations, constraints, and external interfaces. − Develop Customer Requirements • Transform stakeholder needs, expecta-

4.1.1.3 Responsibilities The Lead Systems E ngineering function ensures that the Requirements Development process is fully implemented and the output of requirements meets intended criteria. The project or program manager is ultimately responsible for the content of the require ments, but the Lead Systems Engineering function assists the project or program manager in providing technical overview of the process. 4.1.1.4 Life cycle Requirements development begins during the advanced studies phase of the development life cycle, carries through preliminary analysis, and is baselined in the definition phase. Requirements development may also take place in the desk and development phases, if changes occur in agreements or enabling systems.

•

4-4

tions, constraints, and interfaces into customer requirements. Translate stakeholder needs, expectations, constraints, and interfaces into documented customer requirements.


Develop Customer Requirements

Develop System of Interest Requirements

Elicit and Collect Stakeholder Needs

Develop Customer Requirements

A

Establish System of Interest and Subsystem Requirements

B

Establish and Maintain Operational Concepts and Associated Scenarios

Allocate Subsystem Requirements

Analyze and Validate Requirements C

KEY

Step/Activity

Customer Requirements

A

Identify Interface Requirements

Establish and Maintain a Definition of Required Function ality Analyze Requirements to Achieve Balance

Analyze Requirements

B

C

Validate System of Interest Requirements

Validate Requirements

Information/Output Flows

Produc

System of Interes Requirements

B

Connector

Figure 4.1 -1. Requirements development process diagram. Define constraints for verification and validation. Develop System of Interest Requirements – Customer requirements shall be refined and elaborated to develop system of interest and subsystem requirements. − Establish system of interest and subsystem requirements. − Establish and maintain system of interest and subsystem requirements that are based on customer requirements. • Develop requirements in the technical terms necessary for system of interest and subsystem design. • Derive requirements that result from design decisions. • Establish and maintain a relationship among requirements for consideration during change manage ment and require ments allocation. − Allocate Subsystem Requirements • Allocate requirements for each system of interest component. • Allocate requirements to functions. • Allocate requirements to system of interest components. • Allocate design constraints to system of interest components. •

•

•

•

• −

Develop requirements for identified interfaces. Analyze and Validate Requirements – R e quirements shall be analyzed and validated, and a definition of required functionality shall be developed with documented rationale provided. − Establish and Maintain Operational Concepts and Associated Scenarios • Develop operational concepts and scenarios, including functionality, performance, maintenance, support, and disposal, as appropriate. • Define environment in which the system of interest will operate, including boundaries and constraints. • Review operational concepts and scena rios to refine and discover requirements. • As system of interest components are selected, develop a detailed operational concept that defines the interaction of the system of interest, the e nd user, and the environment, and tha t satisfies oper ational, maintenance, support, and disposal needs. − Establish and Maintain Definition of Required Functionality • Analyze and quantify functionality required by end users. •

Document relationships among allocated requirements. Identify Interface Requirements • Identify interfaces that are both external and internal to the system of interest.

•

4-5

Analyze requirements or functional partitions.to identify logical Using established criteria, partition requirements into groups to facilitate and focus requirements analysis.


Consider the sequencing of time -critical functions both initial and subsequently during system of interest d evelopment. • Allocate customer requirements to functional partitions, objects, people, or support elements to support the synthesis of solutions. • Allocate functional andperformance requirements to functions and sub-functions. Analyze Requirements • Analyze requirements to ensure th ey are necessary and sufficient. •

−

•

•

•

•

•

•

−

−

•

•

•

Analyze stakeholder needs, expectations, constraints, and external interfaces to remove conflicts and to organize into related subjects. Analyze requirements to determine whether they satisfy the obje ctives of higher-level requirements. Analyze requirements to ensure they are specific, measurable, achievable, resource constrained, and time constrained (SMART). Identify key requirements that have a strong influence on cost, schedule, functionality, ris k, or performance. Identify technical performance measures that will be tracked during the development effort. Analyze operational concepts and scenar ios to refine customer needs, constraints,

will perform appropriately in its intendeduse environment. Explore the adequacy and completeness of requirements by developing system of interest representations and obtaining feedback about them from relevant stakeholders . Assess the design as it matures in the cont ext of the requirements validation environment to identify validation issues and expose unstated needs and customer requirements. Obtain customer concurrence with the requirements.

4.1.1.7 Outputs 3,4 The primary output from the Requirements Development process is a system of interest requirements document that becomes the desi gn baseline in passing the System Requirements Review (SRR) milestone. This requirements document may include: • Concept of operation • Mission requirements • Functional requirements • Customer restraints on the conduct of verification/validation • Derived requirements • Product requirements • Product-component requirements • Interface, environmental, and nonfunctional requirements • Performance requirements, including key performance parame ters • •

and interfaces and to discover new requirements. Analyze Requirements to Achieve Balance • Analyze requirements to balance stakeholder needs and constraints. • Use proven models (e.g., simulations) and prototyping to analyze the balance of stakeholder needs and constraints. • Perform risk assessment on the requirements and functional architecture. • Examine system of interest life cycle concepts for requirements impacts on risks. • Prioritize requirements. Requirement priority information is key information to support any required project de-scope. Validate Requirements • Validate requirements to ensure the resulting system of interest will perform appropriately and as intended in the customer environment using multiple techniques, as appropriate. • Analyze requirements to determine the risk that the resulting system of interest

• • • • • • • • •

Design constraints Relationship among requirements (e.g., parent, child, peer requirements) Physical and functional interface requirements Product installation, operational, maintenance, and support concepts Use cases (primarily for S/W development) Timeline scenarios System architecture Functional architecture Activity diagrams Results of requirements validation Technical baseline

4.1.1.8 Exit criteria 3 An approved, validated system of interest requirements document that is derived from each individual requirement statement shall be: • Clear, unique, consistent, stand-alone, and verifiable. • Traceable to an identified source requirement. • Not redundant to, nor in conflict with, any other known requirement.

4-6


Not biased by any particular implementation. Identified with a verification method assigned to each requirement. • Traceable to a higher-level requirement. • Documented with results of cu stomer concurrence discussions. While producing the system of interest requirements document, consider whether: • The impact of enterprise and external constraints on system design is understood. • The design team concurs with the list of requirements. •

•

•

•

• • • •

• • • • • •

Functional concept analysis Functional definition and decomposition Quality functional deployment (QFD) Extraction from sources such as documents, standards, or specifications Observation of existing products, environments, and workflow patterns Use cases (primarily for S/W development) Business case analysis Reverse engineering (for legacy products)

4.1.1.11 Softwar e tools1–6 Some means of capturing requirements should be required. This usually is a repository, the nature of which is dependent on the size and complexity of the system of interest. At a minimum, requirement statements must be captured and controlled, relationships among primary and derived requirements must be identified and managed, and a means for tracking changes over time must be provided. There are a number of commercial off-the-shelf (COTS) S/W applications (e.g., DOORS, SLATE) that provide extensive capabilities supporting requirements development and management. For a list of potential tools, see the table

Cost goals are established for the system. Stakeholder concurrence discussion results are documented. Requirements are verifiable via test, demonstra tion, examination, etc. All requirements are allocated.

4.1.1.9 Measurement The following table provides example base and derived measures that can be used in conjunction with executing the Requirements Developmen t pro cess. See discussion of Measurement on page 4-1. Base Measures

Derived Measures

Total # of Shall Statements

Total # of Requirements @ SRR – Planned vs. Actuals

Requirements Definition Effort (full-time equivalents (FTEs))

Requirements Definition Productivity (allocated resources vs. actual resources used) Requirements Definition Effort – Planned vs. Actuals Requirements Definition Rate Charts Requirements Definition Effort as % of Total Engineering Effort

Defects in Requirements (by phase)

Requirements Defects – Projected @ SRR vs. Actuals

# of Incomplete Requirements

# of Blanks, To Be Determined (TBD), To Be Supplied (TBS), Incomplete Requirements vs. Planned @ SRR

4.1.1.10 Methods and techniques3,4 Some of the methods and techniques that may be used in the developing requirements are: • Questionnaires, interviews, and brainstorming • Working groups • Project reviews • Mission analysis • Requirements analysis • • • • •

provided by INCOSE at: http://www.incose.org/tools/eia632tax/eia632top.html. 4.1.1.12 References The following documents, which were used to prepare this section, offer additional insights into the Requirements Development process: 1

NPR 71xx.x (document number not yet assigned),

Systems Engineering Processes and Requirements . 2 EIA-632, Processes for Engineering a System, ANSI/EIA-632-1998, 1999.

Performance analysis Trade studies Prototypes and models Constraint evaluation Cost/benefit analysis

4-7


3

INCOSE Systems Engineering Handbook , Version 2.0, 2000. 4

CMMI-SE/SW/IPPD/SS V1.1,Capability Maturity Model Integration (CMMI) for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing , 2002. 5

SP 6105, NASA Systems Engineering Handbook , 1995. 6 RP 1358, Systems Engineering “Toolbox” for Design-Oriented Engineers, 1994.

4-8


4.1.2 Requirements Management1,2 The Requirements Management process is performed to manage the requirements of the system of interest and its subsystem components, and to i dentify inconsistencies among those requirements and the plans and work products of the project. This process manages all requirements received or generated by the project, including both technical and nontechnical requirements. The Requirements Development process is the primary source of these requirements.

4.1.2.5 Inputs 3 Specific inputs should include those produced by the Requirements Development process, namely: • Concept of operations • Mission requirements • Functional requirements • Customer restraints on the conduct of verification/validation • Derived requirements • Product requirements • Product-component requirements • Interface environmental, and nonfunctional

4.1.2.1 Function1 In the Requirements Management process: • Baselined requirements developed in the Requirements Development process sh all be established. • Proposed changes shall be reviewed by affected organizations to assess impact on project cost, schedule, and performance on the system of interest. • Proposed changes shall be reviewed by interfacing organizations and stakeholders to assess impact on the system of interest. • Requirements shall be maintained under configuration control. • Changes to the baselined requirements shall be managed and assessed.

• • • • • • • • • • • • •

4.1.2.2 Objective 2,3 The objective of requirements management is to establish a repository of baseline system of interest requirements to serve as a foundation for requirements refinement and revision by subsequent functions in the product development life cycle, for a nonambiguous and traceable flow of requirements to system of interest sub-components, and for support of corrective actions based on inconsistent requirements.

•

requirements Performance requirements, including key performance parameters Design constraints Relationship among requirements Physical and functional interface requirements Product installation, operational, maintenance, and support concepts Use cases (primarily for S/W development) Timeline scenarios System architecture Functional architecture Activity diagrams Requirements defects reports Technical performance measurements (TPMs) Results of requirements validation Technical baseline 2

4.1.2.6 Steps SE performs all five steps in the Requirements Management process. These steps and their overall relationships are illustrated in F igure 4.1-2 at the t op of the following page. In performing the Requirements Management process, users shall: • Develop with the requirements providers an understanding of the meaning of the requirements. − Establish criteria for distinguishing appropriate requirements providers. − Establish objective criteria for the acceptance of requirements. − Analyze requirements to ensure that established criteria are met. − Reach an understanding of the requirements with the requirements provider so the project participants can commit to the requirements. • Obtain commitment to the requirements from

4.1.2.3 Responsibilities The Lead Systems E ngineering function is to ensure that the Requirements Management process is fu lly implemented and the output of requirements meets intended criteria. The project or program manager is ultimately responsible for the content of the requirements, but the Lead Systems Engineering function assists the project or program manager in providing technical overview of the process . The Lead Systems Engineering function should ensure that impacts from ch anges to requi rements are examined thoroughly and fully tracked to completion in the Requirements Management process. 4.1.2.4 Life cycle 1–8 Requirements management begins with project initiation and carries through all phases of the project.

project participants. − Assess the impact of requirements on existing commitments. − Negotiate and record commitments.

4-9


Manage Requirements Changes

System of Interest Requirements

Develop Understanding of Requirements

Obtain Commitment to Requirements

A

KEY

Requirements Repository

Identify Inconsistencies Among Project Plans, Work Products, and Requirements

Requirements Inconsistencies

Maintainbi-directional Traceability of Requirements

Step/Activity

A


Produc

B

Connector

Figure 4.1 -2. Requirements management process diagram. •

Manage changes to the requirements as they evolve during the project. − Capture all requirements and requirements changes given to or generated by the project. − Maintain the requirements change history with a rationale for the changes. − Evaluate the impact of requirement changes from the standpoint of relevant stakeholders. − Make the requirements and change data available to the project.

•

Maintain bi-directional traceability among therequirements and the project plans and work products . − Maintain requirements traceability to ensure that the source o f lower-level (i.e., derived) requirements is documented. − Maintain requirements traceability from a requirement to its derived requirements as well as to its allocation of functions, objects, people, processes, and work products. − Maintain horizontal traceability from function to function and across interfaces. − Generate requirements traceability matrix. Identify inconsistencies between the project plans and work products and the requirements. − Review project plans, activities, and work products for consistency with the re quirements and changes made to the requirements. − Identify both the source of the inconsistency and the rationale. − Identify changes that need to be made to the plans and work products resulting from changes to the requirements baseline . − Initiate corrective action.

•

4.1.2.7 Outputs 1–8 The output of the Requirements Management process is a system of interest requirements repository that contains the validated set of requirements and pro vides control over requirement additions, changes, and deletions. In addition to requirements, other information is stored in the repository, including: • Requirement rationale and assumptions • Requirement assignments • Requirement bi-directional traceability •

•

Any other informat ion contained in the requirements document that needs to be controlled and made available to the various stakeholders Requirements defects reports

4.1.2.8 Exit criteria 2 A configuration-controlled requirements repository shall have a documented requirements tracking method. The repository contains requirements that shall be: • Clear, unique, consistent, stand-alone, and verifiable. • Traceable to an identified source requirement. • Not redundant to, nor in conflict with, any other known requirement. • Not bia sed by any p articular implementation. • Identified with a verification method assigned to each requirement. • Traceable to a higher-level requirement. • Documented with results of cu stomer concurrence discussions.

4-10


3

4.1.2.9 Measurement The following table provides example base and derived measures that can be used in conjunction with executing the Requirements Management process. See discussion of Measurement on page 4-1.


EIA-632, Processes for Engineering a System, ANSI/EIA -632-1998, 1999.

Base Measures

Derived Measures

Total # of Requirements (e.g., name of shall statements)

Requirements Managed – Planned @ SRR vs. Actuals

# of Requirements Added, Changed, or Deleted

Requirements Volatility = % Added, Changed, or Deleted (since SRR)

Requirements Management Effort (FTEs)

Requirements Management Productivity Requirements Managem ent Effort – Planned @ SRR vs. Actuals Requirements Management Effort as % Total Engineering Effort 5

4.1.2.10 Methods and techniques Some of the methods and techniques that may be used in the Requirem ents Management process a re: • Requirements analysis • Traceability analysis

SP 6105,NASA Systems Engineering Handbook, 1995.

6

RP 1358, Systems Engineering “Toolbox” for Design-Oriented Engineers , 1994. 7

SWELT:RM0.2, Requirements Management Guidebook , 1996. 8

Hooks I, Farry K, Customer-Centered Products , American Management Association (AMACOM), 2001.

4.1.2.11 Software tools1–8 Some means of capturing requirements should be required. This usually is a repository of some kind, the nature of which is dependent on the size and com plexity of the system of interest. At a minimum, requirement statements must be captured and controlled, relationships among primary and derived requirements must be identified and managed, and a means for tracking changes over time must be provided. A number of COTS S/W applications (e.g., DOORS, SLATE) provide extensive capabilities supporting require ments development and management. For a list of potential tools, see the table provided by INCOSE at: http://www.incose.org/tools/eia632tax/eia632top.html. 4.1.2.12 References The following documents, which were used to prepare this section, offer additional insights into the Requirements Development process: 1

NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Proces ses and Requirements. 2

CMMI-SE/Sw/IPPD/SS V1.1, Capability

Maturity Model Integration (CMMI) Integrated for Systems Engineering, Software Engineering, Product and Process Development, and Supplier Sourcing , 2002.

4-11


4.1.3 Operational Concept Development 1 The Operational Concept Development process is performed to better understand the capabilities and performance of the system of interest within its pro posed mission, use, or function. This process helps to focus the Requirements Development process so sys tems operations, deployment, delivery, support (including maintenance and sustaining), training, and disposal as well as all modes and states are considered during system of interest definition—regardless of engineering discipline. The operations concept describes the “who, what, when, where, and how” of the sys tem.

concept of operations. All parties should concur on the defined concept of operations. The Lead Systems Engineer is also responsible for the performance of the process steps outlined below. The Design En gineering Discipline (e.g., mechanical, electrical, S/W) ar e responsible for using the defined concept of operations as the basis for functional decomposition and requirements allocation. The Project Manager is responsible for reviewing and agreeing on the defined concept of operations.

Operational conceptprocess. and scenario development evolves as an iterative Operational concepts are refined as solution decisions are made, system of interest components ar e defined, and lower-level detailed requirements are developed.

Operations concept begins during the advanced studies phasedevelopment of the development life cycle, and these concepts are further refined and alternatives defined during preliminar y analysis. As system of in terest requirement changes are encountered during the definition, design, and development phases, operations concepts shall also be updated to ensure concurrency. Operations concepts and associated scenarios provide input into the development of operational products (e.g., operational plans and procedures ) performed during the development phase.

4.1.3.4 Life cycle

4.1.3.1 Function1,2 In this process, a high -level definition of the operational concept and scenarios for the system of interest shall be established and maintained to cover the operational stages and to define timeline, functions, and interfaces.

4.1.3.5 Inputs 3,4 Typical inputs to this process include, but are not limited to: • Goals and objectives • Mission needs • Stakeholder needs • Assumptions, guidelines, and constraints

4.1.3.2 Objective 3 The primary objective of the Operational Concept Development process is to document what the operational system will do and why, and to communicate with the end user so that operational needs are clearly understood. The secondary objective is to define any critical, top-level performance requirements (stated either qualitatively or quantitatively) and system rationale. Other objectives are to: • Provide traceability between operational needs and written source requirements captured in the Requirements Development pr oce ss. • Establish a basis of requirements—e.g., personnel requirements, support requirements, etc.— to support the system of interest over its life. • Establish a basis for integration test planning, interface and system-level requirements, and any requirements for environmental stimulators. • Provide the basis for computation of system capacity, behavior underload/overload, and mission-effectiveness calculations. • Validate requirements at all levels to discover implicit requirements overlooked in source documents.

• • • • • • • • • • •

System environment(s) System of of interest interest operating concept and system hierarchy Technical operational requirements Statement of operational objectives System requirements document Data flow diagrams State/mode diagrams Behavior diagrams Customer standard operating procedures Existing operational infrastructure Records of meetings and conversations with customer

4.1.3.6 Steps 2– 5 The diagram on the following page ( FIG. 4.1-3) illustrates the major steps and products of this process. These are progressively and iteratively executed until a validated concept of operations is achieved. In performing the Operational Concept Develop-

4.1.3.3 Responsibilities The Lead Systems Engineer is responsible for leading discussions with operations personnel (e.g., end users, system operators, facilities, flight crew, Mission Operations) and the Design Engineering Team to develop the

ment process, users shall take the following steps: • Top-Level Operational Concepts and Associated Scenarios – Top-level operational concepts and associated scenarios shall be developed.

4-12


? Develop Top-Level Operational Concepts and Scenarios Define Top-Level Operational Environments

Top-Level Con Ops and Scenarios

Evolve Operational Concepts and Scenarios

Integrated Set of Detailed Con Ops and Scenarios

Review Operational Concepts and Scenarios

Derived System of Interest Requirements

Evolve Operational Environments

These steps are progressively and iteratively executed until a validated concept of operations is achieved.

KEY

Step/Activity

Information/Output Flows Product

B

Connector

Figure 4.1 -3. Operational concept development process diagram. −

•

Develop top-level operational concepts and scenarios. • Include functionality, performance, maintenance, support, and disposal as appropriate. • Identify and develop scenarios consistent with the level of detail in the stakeholder needs, expectations, and constraints in

Review operational concepts and scenarios. • Integrate operational concepts and scenarios produced for each physical level of system of interest decomposition. • Refine requirements and discove r overlooked implicit requirements. The following questions should be answered in the development of an operational concept: −

•

−

which the proposed system of interest is expected to operate. − Define top-level operational environments. • Define the environments in which the system of interest will operate. • Include boundaries and constraints. Detailed Operational Concepts and Scenarios − Establish and maintain detailed operational concepts and scenarios. − Evolve operational concepts and scenarios. • As system of interest components are selected, further evolve operational concepts and scenarios to describe the conditions, operating modes, and operating states specific to each system of interest component. − Evolve operational environments. • Evolve the operational environments for each system of interest component defined. • Take into consideration that theenvironment for any given system of interest will be influenced by other system of interest components and by the external environment.

− −

− −

− −

Operational Distribution or Deployment: Where will the system be used? Mission Profile or Scenario: How will the system accomplish its mission objective? Performance and Related Parameters: What are the critical system parameters to acc omplish the mission? Utilization Environments: How are the various system components to be used? Effectiveness Requirements: How effective or efficient must the system be in performing its mission? Operational Life Cycle: How long will the system be operated by the user? Environment: What environments will the system be expected to operate in effectively?

4.1.3.1 Outputs 1–5 The primary output from this process is a system of interest concept of operations doc ument that is baselined at the SRR milestone. Outputs of this process include: • Concept of operations document

4-13


• • • • •

• • • • • • •

Top-level and detailed operational concept definitions Operational, installation, support, maintenance, training, disposal, and support concepts Integrated set of component-level operatio nal concepts and scenarios Operational behavior models for each operational mode traceable from source requirements Operational scenarios (step-by-step descriptions of how the proposed system of interest should operate and interact with its users and external interfaces)

The following diagramming techniques may be employed to capture operational concepts: • Context diagrams • Mission event sequence illustrations • Functional flow diagrams • Timeline charts • N2 charts

Use cases Timeline scenarios Timeline analyses of component interaction s Trade analyses for the operations concept System test plan test threads and key test features Environmental simulation plan Derived requirements

the associated scenarios have been developed, they should be placed under configuration management (CM) control to maintain and support their evolution. The use of basic spreadsheet and graphics tools is also applicable in the development of N2 charts as are context, event sequence, timeline, and functional flow diagrams.

4.1.3.5 Software tools A standard word processor is sufficient for developing the concept of o perations document and associated scenarios. Once the document and

4.1.3.12 References The following documents, which were used to prepare this section, offer additional insights into the Operational Concept Development process:

4.1.3.2 Exit criteria 3,5 Exit criteria include: • Release and approval of the system of interest concept of operations document at the SRR. • Assurance that all operational concept changes affecting the system of interest have been properly communicated to the interfacing and component suppliers. 4.1.3.3

1

NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Processes and Requirements. 2

CMMI-SE/SW/IPPD/SS V1.1, Capability Maturity Model Integration (CMMI) for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing , 2002. CMMI is a service mark of Carnegie Mellon University.

Measurement 3

The following table provides example base and derived measures that can be used in conjunction with executing the Operational Concept Development process. See discussion of Measurement on page 4- 1.

3 INCOSE

Systems Engineering Handbook , Version

2.0, 2000. 4

Section 4.3.1 of this document.

Base Measures

Derived Measures

# of Functional Flow Diagrams

Functional Flow Diagrams – Required vs. Completed

# of System External Interfaces

System External Interfaces – Required vs. Completed

# of Unresolved Source Requirement (i.e., TBD, TBS, etc.)

Unresolved Source Requirement Statements – % Completed

4.1.3.4 Methods and techniques 3,6 In addition to a scan of the listed input documents, additional operational insight can be achieved through: • Interviews with operators of current/similar • • •

5

EIA-632, Processes for Engineering a System, ANSI/EIA -632-1998, 1999. 6 Defense Systems Management College, System Engineering Fundamentals , 2001.

systems. Interviews with potential users. Interface working group (IFWG) meetings. Observation of existing products, environments, and workflow patterns.

7 ANSI/AIAA G-043-1992, Guide for Preparation of Operational Concept Documents .

4-14


4.1.4 Decomposition 1 The Decomposition process is performed to develop an architectural breakdown of the system of interest into lower-level elements to allocate the functions and requirements to the respective elements of the system of interest and to identify all physical and functional interfaces for the v arious levels. Decomposition is an iterative process that is performed until the system of interest is decomposed to the level needed to fully define it. Typically, the Decomposition process runs concurrent with development of the system concept

•

•

Develop and maintain interfac e control or defi nition documentation that defines all physical and functional interfaces for the various levels of the system of interest. Identify and characterize interfaces between decomposed elements and functions.

4.1.4.3 Responsibilities 3 The Lead Systems Engineer is responsible for the performance of the process steps outlined below. Process execution may include working and coordinating with multiple engineering disciplines (e.g.,

SECTION

of operations ( the concept of operations is used as the4.1.3) basis because for functional decomposition and requirements allocation.

H/W, S/W, to ensure themechanical, proper and electrical, appropriateenvironmental) level of system decomposition is achieved. The Design Engine ering Team is the primary customer of th e products resulting fro m the Decomposition process. Decomposition process products are used by the Design Engineering Team as the basis for design.

4.1.4.1 Function1 In the Decomposition process: • Physical and functional architectures shall be developed th at identify the next lower-level physical or functional elements of the system of interest. • The system architecture for the system of interest shall include an allocation of functions and requirements to the respective elements of the system of interest. • Identification of interfaces shall also be developed and documented, thereby definin g all phys ical and functional interfaces for the various levels of the system of interest. • All physical and functional interfaces shall be identified, devel oped, and documented for the system of interest.

4.1.4.4 Life cycle System decomposition begins during the advanced studies phase of the project life cycle with the development of a high-level system archite cture and breakdown structure. The system of interest architecture and interfaces are further refined, and architectures associated with alternative solutions are defined during preliminary analysis. As the system of interest continues through the definition and design phases (i.e., system definition, preliminary design, and final design stages) of the life cycle, the architecture and interfaces of the selected solution are furth er de composed to whatev er level of decomposition is n eeded to fully define the system.

2,3,4

4.1.4.2 Objective The primary objectives are to (1) document the allocat ion of higher-level systems, requirements, or customer needs into lower-level components within the context of the system of interest; and (2) document the interfaces down to the l ower-level components. This allows for a better understanding of what the system of interest has to do and in what ways it can perform, both lo gically and in terms of the performance required. Other objectives are to: • Allocated higher- level functional and performance requirements to lower-level functions (i.e., requirements traceability). • Document how requirements are parsed/ detailed into requirements for functional or physi cal components. • Identify priorities and conflicts associated with lower-level functions. • Provide information essential to optimizing and evaluating solutions. • Form the basis for design definition.

4.1.4.5 Inputs 4,5 Typical inputs to this process include, but are not limited to: • System goals and objectives • System requirements, including functional, physical, enviro nmental, and performance pro ducts and interface requirements • System hierarchy concepts • High-level architectures (functional and physical) • Operational concepts and scenarios, including: − Use cases (for S/W projects) − Data flow diagrams − State/mode diagrams − Behavior diagrams − Timeline scenarios 4.1.4.6 Steps 2,5,6 SE is responsible for all of the steps in the Decomposition process. The following diagram (FIG. 4.1-4) illustrates the major steps and products of this process.

4-15


Higher-Level System Requirements

Allocate System Requirements to Lower-Level Architectures

Functionally Decompose System of Interest

Identify Functional and Physical Interfaces

Lower-Level Functional Architectures

Physical Decompose System of Interest

Lower-Level Physical Architectures

High-Level Operational Concepts & Architectures

Interface Control Documentation

Iterate process. Lower-level architectures become higher-level ones in next process pass.

KEY

Step/Activity

Product


B

Connector

Figure 4.1-4. Decomposition process diagram. −

Higher-level architectures, operational concepts, and system requirements are from the previous concurrent execution of the decomposition, operations concept development, and requirements development processes, respectively. This repetitive decomposition occurs until the architecture detail and allocation of requirements are sufficient for the desig n process to start as follows: • Functionally Decompose System of Interest – Functional decomposition shall be performed on the system of interest. − Decompose the system functions into subfunctions. − Iterate until the system is decomposed into its basic sub-functions and each sub-function at the lowest level is completely and uniquely defined by its requirements. The resulting prod uct is the functional architecture. • Physically Decompose System of Interest – Physical decomposition shall be performed on the system of interest. − Functional decomposition of the system occurs concurrently with phy sical decomposition of the system. The result ing p roduc t •

−

Distribute the fu nctional system requirements to each of the functional system elements. Distribute the physical system requirements to each of the physical system elements.

−

•

is the Requirements physical architecture. Allocate to the Architectures – System of interest requirements shall be allocated to the lower-level functional and physical architecture. To achieve this:

Perform and establish traceability of performance requirements (requirements allocation sheets (RASs)). Identify Interfaces – Functional and physical interfaces shall be identified and maintained. − Identify and document functional and physical interfaces between products internal to the system of interest. − Identify and document functional and physical interfaces associated with external items and enabling systems. − Identify and document interfaces between products and the product -related life cycle processes. For example, such interfaces may include those between a product that is to be fabricated and the jigs and fixtures that are used to enable fabrication during the manufacturing process. − Ensure that the documented interface solutions account for all of therequirements interface requirements developed in the development processes.

4-16


Some specific activities that can occur during the Decomposition process include: • Task sequences and relationships (functional flow block diagram (FFBD)) • Process and data f lows (i.e., integration d efinition for function modeling (IDEF0) diagrams) • The time sequence of time-critical functions (timeline analysis sheets (TLSs)

•

1,2,3,5,6

4.1.4.7 Outputs Primary outputs from this process are: • Functional architecture • • •

•

Physical architecture Product breakdown structure Interface control documents (ICDs)

•

4.1.4.8 Exit criteria 2,6 Exit criteria include: • Completion of FFBD documentation to level of detail required for project life cycle phase. • Completion of interface definition descriptions for all interfaces (N2 charts may be sufficient). • Completion of RASs (or tables) for all functional requirements.

• •

4.1.4.9 Measurement 2 The table at the bottom of the page provides example base and derived measures that can be used in conjunction with the Decomposition process. See discussion of Measurement on page 4-1.

•

•

detail to defining durations of various functions. It defines concurrency, overlapping, and sequential relationships of functions and tasks. It identifies time-critical functions that directly affect system availability, operatin g time, and main tenance downtime. Finally, it is used to identify specific time-related design requirements. N2 Diagramming – A matrix displaying functional interactions, or data flows, at a particular hierarchical level. RASs – Used to identify allocated performance and to establish traceability of performance requirements. IDEF0 – A common modeling techniques for the analysis, developm ent, re -engineering, and integration of information systems, business processes, or SE analysis. Where the FFBD is used to show the functional flow of a product, IDEF0 is used to show data flow, system control, and the functional flow of life cycle processes. Trade Studies – Used to evaluate different decomposition (architecture) alternatives. Functional Thread Analysis – A thread consists of the system input and output. Analysis of threads identifies stimulus-condition-response threads to control S/W development. Modeling an d Simulation – Used to verify the interpretation, definition, and viability of key functions. Real-Time Structural Analysis – An alternative to functional allocation that is usually applied to

2–5

4.1.4.10 Methods and techniques Several methods and techniques are available to adequately define and represent the functional and physical architecture of the system of interest. These include: • Functional Flow Block Diagramming – Diagrams that show the logical sequence (network) of actions that leads to fulfillment of a function. • Timeline Analysis – Used to define the time sequence of time -critical functions. The T LS adds

•

the design of S/W-intensive systems. Typical steps are to constru ct data flow diagram s and data dictionaries. Object-Oriented System Modeling – Use d to construct an object that combines data structure and behavior in a single entity to repr esent the components of a system. This form of modeling allows conceptual issues to be clearly understood before the system is built.

Base Measures

Derived Measures

# of Functional Flow Diagrams

Function Flow Diagrams – Required vs. Completed

# of System External Interfaces

ICDs – Required vs. Completed

# of Issues/Risks Identified

Unresolved Issues/Risks – % Completed/Mitigated Depth of Functional Hierarchy – % vs. Target Depth % of Requirements Allocated at the Lowest Level of Hierarchy

4-17


4.1.4.12 References The following documents, which were used to prepare this section, offer additional insights into the Decomposition process:

Architectures may also include standards and design rules governing the development of system components and their interfaces, as well as guidance to aid product developers.

1

NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Process and Requirements.

4.1.4.11 Software Tools2 A standard word processor is sufficient for documenting the architectures and ICDs. Once developed, they should be placed under CM control to maintain and support their evolution. The use of basic spreadsheet and graphics tools is also applicable in the development of N2 charts, RASs, and TLSs, as

2


SP 6105,NASA Systems Engineering Handbook , 1995.

4

Defense Systems Management College, System

Engineering 5

Fundamentals , 2001. CMMI-SE/SW/IPPD/SS V1.1, Capability Maturity Model Integration (CMMI) for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing , 2002. CMMI is a service mark of Carnegie Mellon University.

well as functional and be IDEF0 Other S/W toolsflow that can use ddiagrams. in the Decomposition process include: • Analysis tools • Modeling tools • Prototyping tools • Simulation tools • Requirements traceability tools

6

EIA-632, Processes for Engineering a System, ANSI/EIA -632-1998, 1999.

4-18


4.1.5 Feasibilit y Study 1 The Feasibility Study process is performed to evaluate and iterate the needs and potential approaches for technical and programmatic feasibility. This process establishes technical and resource feasibility and identifies the associated risks of meeting requirements within the given constraints.

the feasibility assessment by completed during Phase A, Preliminary analysis, where requirements and concepts are refined to establish optimal system require ments and a sin gle, optimum top-level architecture. However, circumstances may indicate the need for continuing assessments at lower levels in the architecture to complete optimization of the total system of interest.

4.1.5.1 Function1,2 The Feasibility Study process is performed to evaluate the technical and programmatic possibility of success of an approach(es) to realizing the system of interest. Credibility of a candidate concept and its subsequent design is also at issue in this r equirement. In the Feasibility Study process: • Evaluation criteria for assessing feasibility of approaches shall be established and ranked. • One or more technically and programmatically implementable approaches for the system of interest under consideration shall be established in the feasibility study. • Cost estimates shall be determined for each possible system of interest approach.

4.1.5.5 Inputs As shown in Section 4.1.5.6, the F easibility Study process begins with an understanding of the system of interest stakeholders theirsub-elements. needs, the operational environment, and theand system These are examined in the Requirements Development (Section 4.1.1), Requirements Management (Section 4.1.2), Operational Concep t Development (Section 4.1.1), and Decomposition (4.1.4) processes. Therefore, the outputs of these processes, listed below, should be used as inputs to the Feasibility Study process. • Requirements document • Contents of the system of interest requirements repository, including requirement: − Additions, changes, and deletions − Rationale and assumptions − Assignments − Bi-directional traceability • Concept of operations document • Functional architecture • Physical architecture • Product breakdown structure

4.1.5.2 Objective The Feasibility Study process is performed to ascertain whether the system of interest can be designed, implemented as designed, and then accomplish system goals – all within the constraints imposed by the fiscal and thermal environments of the project. 4.1.5.3

Responsibilities

•

Depending on the size and complexity of the project, the Feasibility Study process is led by the Project Manager or by another individual who is acting in the role of Lead Systems Engineer and can take a broad view of the total system of interest. Consult ation with experienced person nel who have performed similar projects may be useful. Other personnel/roles may participate in proportion to the scale and complexity of the project. Broad participation in the feasibility study by the Project Team and outside experts usually contributes to the fidelity of the study effort. For example, Design Engineering Disciplines may develop the system concept and architecture options for evaluation. Specialty Engineering Disciplines may contribute to the evaluate process or identify “show-stoppers” to proposed concept options. Cost Personnel may contribute to estimating the cost of the possible system approaches.

Preliminary interface definition

4.1.5.6 Steps In Pre -Phase A, requirements and concepts are iterated to establish feasibility; and in Phase A, re quirements and concepts are iterated to establish optimal system requirements a nd top-level architecture. Major steps and products of the Feasibility Study process are illustrated in Figure 4.1-5. The specific steps in the process follow. In taking these steps, study participants: • Should Review Requirements – To understand the expected performance, conceptua l configuration, and operating environment of the system of interest. Study participants should also examine the decomposition of stakeholder needs, assumptions, presumed scenarios, environmental constraints, and structure documented in the: − Requirements document. − −

4.1.5.4 Life cycle During Pre-Phase A, Advanced Studies, the pro cess iterates between requirements and alternative concepts, with the goal of establishing feasibility by admitting one or more concepts. It is intended that

−

4-19

Contents of the requirements repository. Concept of operations. Functional and physical architectures.


Requirements Document

– START – Review Requirements

Identify

Select Options for Evaluation

Constraints

Determine Option Costs, Benefits, Sched ules,Risks

A

Preliminary Interface Document

Functional/Physical Architectures

Concept of Operations

Requirements Repository

Product Breakdown Structure

B

A

Preliminary Options Costs, Sched ules,Risks

Preliminary Option Ops Concepts

Preliminary Option Tech Plans Preliminary Option Interface Definition

Deve lop Evaluati on Criteria

B

KEY

Prioritized Evaluation Criteria

Step/Activity

Feasibility Assessment Document

Select Feasible Options


Product

B

Connector

Figure 4.1 -5. Feasibility study process diagram. −

Preliminary interface definition.

− •

•

•

•

Product breakdown structure. Should Identify Constraints − Analyze information gained from the review to identify environmental, operational, functional, or architectural constraints. − Identify critical physical or functional interfaces or project constraints. Shall Select Options for Evaluation − Develop alternative solutions or conceptual designs for the system of interest. Shall Determine Cost Estimates for Each Option − Identify alternative operations and logistics concepts. − Develop cost and schedule estimates for each alternate solution. − Identify technical, cost,schedule, programmatic, and safety risks for each alternate solution. Shall Develop and Prioritize the Evaluation Criteria −

•

implementation plans. Examples can include, but are not limited to, the factors s hown in the table at the top of the following page. Shall Select Feasible Options − Use prioritized evaluation criteria to identify technically and programmatically feasible solutions for further study or development. produce a feasibility assessment document that includes, but is not limited to, the following: • Description of and rationale for evaluation criteria • Descriptions of alternatives considered, which can include preliminary option: − Costs, schedules, risks − Operations concepts − Interface definition − Technical plans • Ranked feasible alternative solutions list

4.1.5.7

Establish prioritized evaluation criteria for assessing the feasibility of the alternative solutions. Select criteria appropriate to the system of interest. Assess t he fit of the solution with JSC or organization strategic or

Outputs

For the Feasibility Study phase: For Pre- Phase A, the output of this process is a top-level or partial feasibility assessment. • For Phase A, the output of this process is a completed feasibili ty assess ment. •

4-20


Performance

Technology Safety Readiness

LifeCycleCost, Budg et, and Schedule

Physical Envelopes During All Applicable Project Phases

Resources

(Asrequired) (Asrequired) (Asrequired) – Design,deve lopme nt,– Length – Power test, and evaluation – Width – Information (DDTE) – Height technology – Deployment – Mass – Facilities – Skills, training – Electromagnetic – Thermal rejection – Disposal compatibility/ – On-orbit crew time – Foreseeable required electromagnetic– Crew training time improvement/ interference – Upmass augmentation/ complementary or (EMC/EMI) follow -on system

4.1.5.8 Exit criteria For the Feasibility Study phase: • For Pre- Phase A, a t op-level or partial feasibility assessment shall be documented and accepted at the concept review. • For Phase A, completed feasibility assessment sha ll be documented and accepted at the definition review. 4.1.5.9

– volume – Up On-o rbit stowage space – Downmass – Down volume – Launch infrastructure – Operations & communications infrastructure – Ground processing infrastructure • • • • • •

Specialty Engineering

– Reliability – Maintainability – Transportability – Sustainability – Producibility – Supportability – Human Factors – Safety

Risk

– Technical & performance – Safety – Cost – Schedule

– Assurance – Quality S/W Assurance – Environmental – Fabrication – Test & Verification – Training – Operations – Information Systems – Logistics & Maintenance

Trade studies Cost-benefit studies Risk assessment matrix Success tree analysis Benchmarking Concurrent engineering

4.1.5.11 Software tools Standard office automation tools that support

Measurement

The following table provides example base and derived measures that can be used in conjunction with executing the Feasibility Study process. See discussion of Measurement on page 4-1.

identification andstudy directteam communicatio n of the cess inputs to the should generally bepro used; e.g., word processor, spreadsheet, and presentation slide S/W for personal computers

Base Measures

Derived Measures

Total # of Alternative Solutions Studied

Total # of Alternative Solutions Studied – Planned vs. Actual

Feasibility Study Effort (FTEs)

Feasibility Study Productivity

Alternative Solution Study Rate Charts

Feasibility Study Effort – Planned vs. Actuals Feasibility Study Effort as % Total Engineering Effort 4.1.5.10 Methods and techniques 3 The key techniques here are sound managerial

(PCs). Some tools are available that provide for documentation of the options, input of the evaluation criteria, and display of the ranked list of options. One such tools is Expert Choice. 4

and engineering Thebe following and managementjudgment. devices may useful intechnical performing the assessments:

4-21


4.1.5.12 References The following documents and Web site, which were used to prepare this section, offer additional insights into the environment of the Feasibility Study proces s: 1 NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Pro cesses and Requirements. 2 SP 6105, NASA Systems Engineering Handbook , 1995. 3 RP 1358, System Engineering “Toolbox” for Design-Oriented Engineers , 1994. 4 Expert Choice, Inc., www.exp ertchoice.co m

4-22


4.1.6 Technology Planning 1,2 The Technology Planning process is performed to ensure that technologies critical to the success of the project are identified and the effort to advance the technologies is understood and feasible.

The Stakeholder Representative interfaces with the Project Manager and the Lead Systems Engineer for soliciting information in support of the technology planning function. The Stakeholder Representative also provides advice on assessing technology maturation and insertion.

4.1.6.1 Function1,2 For a system to be realized, the technologies that enable achievement of system goals must be available within the resources and schedule of the project. A technology assessment is therefore performed and documented to identify and characterize requirements

4.1.6.4 Life cycle 7 Technology planning begins in the Pre-Phase A, Advanced Studies, where conceptual technology development requirements are documented to help to answer the general question of mission feasibility.

and development plans forthe thesystem key enabling andwill enhancing technologies that of interest require, and how these technologies will be acquired and incorporated into the system. In the Technology Planning process: • An initial tech nology assessment shall be performed and documented that identifies any key enabling and enhancing technologies that will need to be infused into the system of interest and also identifies the existing technology readiness level (TRL) for each. (References explain determining TRLs.) • Identified technologies shall be further assessed and documented to determine what is required to advance them to the level necessary for successful inclusion into the overall system of interest. • Technology maturation and insertion planning shall be developed and documented for each identified technology that describes quantifiable milestones, decision gates, and fallback positions for incorporating the identified technologies into the system of interest.

Subsequently, during Phase A, Preliminary Analysis, technology development requirements and plans are documented that reflect increased understanding gained from that phase’s iterations between requirements and concepts to develop optimal system re quirements and top-level architecture. Finally, during Phase B, Definition, technology development plans are updated to accommodate any changes indicated by the iterations between requirements and concepts to establish the optimal design-to baseline. 4.1.6.5 Inputs Typical inputs should include, but not be limited to: • Needs, goals, objectives • Requirements • Programmatic guidelines and constraints] • System specifications • System concept and architecture • Cost/effectiveness analyses • Environmental assessment • Feasibility assessment • Specialty engineering studies • Life cycle cost estimates • Trade and analysis results • Analysis model descriptions • SE tool descriptions • Program and project management plans (PMPs) • Engineering master plan and master schedule • Operations concepts • Evaluation criteria • Reference missions • Technical performance measures

4.1.6.2 Objectives The Technology Planning process is performed to document the selection of system-required technologies and to schedule their maturation and incorporation into the system of interest. Technology planning includes identification of partnering opportunities with other agencies, centers, industry, and academ ia. 4.1.6.3 Responsibilities 2 The Lead Systems Engineer provides primary technical assessment on needs and requirements for products, materials, and services. The Lead Systems Engineer is responsible for performing the planning steps b elow, which outline how technical assessment for the technology planning mechanisms is performed. The Project Manager is responsible for formulating technology planning strategy(ies) for the project. The Project Manager also makes the final decisions concerning project technology planning and approves any corrective actions related to the performance of the technology insertion into the system of interest.

4.1.6.6 Steps 1,3,6 Three main steps to this process are to review and understand requirements and concepts, to establish the key technologies needed by the system of interest, and to plan for their maturation and insertion. These major steps and are products ofed thefurther Technology process, which discuss below,Planning are illustrated in Figure 4.1-6. • Requirements and concepts should be reviewed. − Examine current life cycle phase inputs.

4-23


−

Requirements & Concepts Developing in Current Life Cycle Phase

Inputs for Current Life Cycle Phase

– START – Review Requirements and Concepts

Key Technology Definitions, TRLs, and Gaps

Is New Technology Re uired?

Yes

A

Established Required Key Technologies TRLAdvancementans Pl Plan for Technology Maturation & Insertion

A

Maturation & Insertion Schedule

Techn ology Alternati ve Employment Criteria

Step/Activity

Document That No New Technologies AreNeeded

STOP

Technology Development Requirements

KEY

No

Low-TRL Technology Insertion Criteria

Technology Development Plan

Information/Product


A

Connector

Figure 4.1 -6. Technology planning process diagram. − •

•

Keep abreast of concurrently developing

TRLs to levels required for incorporation

requirements. Required key technologies shall be established. − Identify and document key technologies required by the system of interest using tools and resources such as the NASA Technology Portal to identify potential technologies; e.g., http://nasatechnology.nasa.gov/index.cfm . − Identify key partnerships. − Identify and document the TRL of each required key technology. − Identify where tec hnology gaps exist, in cluding gaps significant enough to question the viability for a concept to be realized. − Evaluate those technologies that can incrementally improve project capabilities, decrease risk, improve safety, or reduce cost. − Identify technologies that have distribution restrictions on the S/W, H/W, or data. − If no new technology are required, docu-

−

−

ment this and advise termination of process. Technology maturation and insertion shall be planned for required low-TRL technologies. − Determine and document activities for advancing required technologies from lower

4-24

into the system of interest. • Generate technology development plans to remove identified technology gaps. • Explore innovative avenues to expand participation and infuse the la test tec hnological and commercial capabilities into the project. • Ensure that plans for technological or commercial cooperation include a full description of the opportunities for partnering, the potential partners, the need to protect intellectual property, the likelihood of the partnership achieving fruition, the expected contribution, and the confidence that the partnership will remain in force. Determine and document the criteria for assessing when required low-TRL techn ologies that must be matured can be inserted into the system of interest. Schedule and document anticipated technol ogy maturation and insertion foreach identified required low-TRL technology, and protect against technol ogy non-maturation.


Describe calendar -based milestones for the insertion of each required technology. • Document alternatives to incorporating the identified low- TRL technologies i nto the system of interest, and establish decision gates and decision criteria for proceeding with the alternatives. As indicated by the life cycle phase, document technology development requirements and/or the technology development plan. Identify potential technologies to disclose. •

−

−

• • • • • • •

Concurrent engineering Brainstorming Delphi technique Nominal group techniqu e Cause and effect diagram (fishbone) Flowchart analysis TRL classification

4.1.6.11 Software tools The Technology Planning process should include a review of technology databases and portals, and interviews with experienced technology developers whose

4.1.6.7 Outputs For the Technology Planning phase: • Pre-Phas e A, Advanced Studies, is a set of c onceptual technology development requirements. • Phase A, Preliminary Analysis, is a set of tech nology development requirements and plans. • Phase B, Definition, is any updates to the technology development plans.

expert judgment can shed light on potential technology challenges for the system of interest. Thus, standard office automat ion tools that support identification and direct, condensed communication of process inputs to the study team should generally be used; e.g., word processor, spreadsheet, technology databases/portals, data mining tools such as an “expert locator system,” and presentation slide software for PCs.

4.1.6.8 Exit criteria For the Technology Planning phase: • Pre-Phase A, Advanced Studies, conceptual technology development requirements shall be documented and accepted by the concept review. • Phase A, Preliminary Analysis, documented technology requirements and plans shall be accepted by the definition review. • Phase B, Definit ion, any updates to the te chnology development plans shall be documented

4.1.6.12 References The following documents and Web site, which were used to prepare this section, offer additional insights into the environment of the Technology Planning process: 1

NPR 71xx.x (document num ber not yet assigned), NASA Systems Engineering Pro cesses and Requirements. 2

NPR 7120.5B, NASA Pr ogram a nd Proj ect Man agement Processes and Requirements , 2002. 3

and accepted by the definition review.

INCOSE Systems Engineering Handbook , Version

2.0, 2000. 4 RP 1358, System Engineering “Toolbox” for Design-Oriented Engineers , 1994.

4.1.6.9 Measurement The table a t the bottom of the page provides example base and derived measures that can be used in conjunction with executing the Technology Planning pro cess. See discussion of Measurement on page 4-1.

5 Mankins JC. Technology Readiness Levels: A White Paper . Advanced Concepts Office, Office of Space Access and Technology, NASA, 1995. 6

Next- Generation Space Telescope (NGST) Web site explanation of TRLs, http://www.ngst.nasa.gov/public/unconfigured/doc _0852/rev_01/NGST_TRLs.html .

4

4.1.6.10 Methods and techniques The following technical and management methods – the key tools of which have been and will remain sound managerial and engineering judgment and decisiveness – may be useful in technology planning:

7


Base Measures

Derived Measures

Total # of Technologies Assessed

Total # of Technologies Assessed – Planned vs. Actuals Technology Assessment Rate Charts

Technology Planning Effort (FTEs)

Technology Planning Productivity Technology Planning Effort – Planned vs. Actuals Technology Planning Effort as % Total Engineering Effort

4-25


4.1.7 Design1–4 The Design process is performed to provide a methodical and iterative effort that transforms system of interest requirements into qualitative and quantitative solutions. this process involves taking identified products from previous phases and establishing a system definition sufficient for moving into attainment. Requirements are iterated and decomposed into progressively lower levels using trade studies to optimize the selected system of interest. The selected solution is validated to meet needs, goals, objectives, costs, and schedules. This solution is evaluated for manufactur-

Establishes a “design-to” solution that fully meets project needs, goals, and objectives. • Completes test and verification p lans. • Establishes design-dependent requirements and interfaces. • Completes implementation level of design. Detail design: • Establishes complete, validated “build-to” detailed design. • Completes all design specialty audits. • Establishes manufacturing processes and controls. • Finalizes and integrates interfaces. •

ability, operations, safety, requirements reliability, maintainability parts/materials adequacy, compliance, , and operations concept consistency. All interfaces are identified and documented. Approaches to verify and validate all requirements and specifications are documented. The process completes the design of the system of interest by defining the set of identified configuration items and defining their interfaces, integrated as a system. The Design process is applied to all levels of t he system of interest to: • Establish specified requirements anddetailed drawings or documents for system of interest products. • Define initial and final specifications, including interface specifications, for subsystems of each system of interest product that requires further development. • Identify enabling product requirements to facilitate meeting functional requirements during attainment, production, test, deployment, operations, training, support, and disposal. Designs provide the appropriate content not only for attainment but also for other phase s of the product life cycle, such as modification, re-procurement, maintenance, sustainment, and installation. Design documentation provides a reference to support mutual understanding of the design by relevant stakeholders and supports future changes to the design both during attainment and subsequent phases of the life cycle. A complete design description is documented in a technical data package that consists of a full range of features and parameters including form, fit, functio n, interface, manufacturing process characteristics, and other parameters. Established organizational or project design standards (e.g., checklists, templates, object frameworks) form the basis by which to a chieve a high degree of definition and completeness in design documentation. Design begins in the earliest phases of the project with development or preliminary system concepts and specifications and continues throughout system definition and design. Predominate activities, how ever, occur in the preliminary design and detailed design phases of the project life cycle. Specifically, preliminary design:

4.1.7.1 Function1 In the Design process: • Requirements for the system of interest shall be further decomposed and allocated to elements of the system(s) of interest. • Proposed solutions t hat address the system of interest requirements shall be identified. • Trade studies of the proposed solutions shall be performed to provide an objective foundation for selection of the solution(s). • The selected solution shall be documented. 4.1.7.2 Objective 1 The primary objective of the Design process is to document that identified needs, goals, and objectives of the customer and other stakeholders can be achieved by a baselined system of interest solution, and the system of interest can be attained, operated, and de-commissioned within the technical, budget, and schedule scope of the program/project plans. 4.1.7.3 Responsibilities 3,4 In the Design process, the Lead Systems Engineer is responsible for ensuring the relationships of the system of interest are being designed to its environment and subsystems rather than with the internal details of how the system of interest will accomplish its objectives. The Lead Systems Engineer’s viewpoint is broad rather than deep, encompassing system functionality from end to end and temporally fro m conception to disposition. The Design Engineering Disciplines (e.g., mechanical, electrical, S/W) have the primary responsibility for actual system of interest design. Specialty Engineering Disciplines and Support Functions (e.g., quality engineering, quality assurance (QA), S/W assurance, CM, data management) contribute to the design when and as required. For example, engineering specialty analysis results are integrated into the design, and the manufacturing process and controls are defined and validated.

4-26


4.1.7.4 Life cycle Some early design activities take place in Phase A in support of synthesizing and down selecting proposed system concept(s) and drafting preliminary system specifications. Some design activities also take place early in Phase B in support of definition reviews such as development of the systems evaluation criteria, development and refinement of the prime items concepts, and performing trades for selecting the optimal solution. The preliminary Design process begins following successful System Definition Reviews (SDRs) during Phase B andends in a series of Preliminary Design Reviews (PDRs) con-

• • • • • • • • • • •

taining the system of interest-level PDR as well as PDRs for lower-level components, as appropriate. Detailed design execution is conducted duringPhase C, culminating in a series of Critical Design Reviews (CDRs) for the system of interest and all of its components. 4.1.7.5 Inputs 1,3 Available and necessary inputs required for the Design process range from analyses, assessments, and studies to plans and requirements. These inputs will occur during various stages of development. Some will be conceptual or preliminary documents and only partially complete, while others will be fully complete and approved. Some of these inputs are further refined or completed during the Design process and are listed as outputs. The following provides a listing of typical inputs that should be considered during design: • Results from evaluations, analyses, and studies of cost/effectiveness, risks, life cycle cost, logis tics, support, producibility, reliability, human factors, maintainability, safety/hazards, specialty engineering, environmental, feasibility, trades, and failures modes and effects • Concepts, including system, functional, operations, integrated logistics support, and integration and assembly • All requirements, including top-level projec t, science, system/segment, allocated, disposal, flow down, refined, interface, lower level, performance, technology, development, verification, and validation • Plans in various stages of development, including PMPs, SE management plans, CM plans, integration and assembly plans, integrated logistics support plans, QA plans, risk management plans, system safety plans, verification and validation plans, etc. Other inputs include: • Needs, goals, and objectives • • • •

System specifications Applicable standards Verification requirements matrix ICDs Design-to specifications Design selection with rationale Development test results Engineering items Hardware/software list Integrated schematics Material and processes data

4.1.7.6 Steps 4 Figure 4.1-7 illustrate s the major steps and products of the Design process. This process begins wi th outputs from decomposition and end s with a fully characterized design solution. More detailed activities associated with these steps are pro vided below. NOTE: Reference NPR 8705.2 for space flight systems that carry humans or whose function or malfunction may pose a hazard to NASA space systems that carry humans. • Detailed Alternative Solutions and Selection Criteria Shall Be Developed – Various alternative design solutions and association evaluation criteria should be established from which an optimal design solution can be sele cted. These alternative solutions are refined and evaluated until a preferred design solution is selected. − Develop Evaluation Criteria – Evaluation criteria should be established that address design issues for the life of the product. Synthesize and Down Select Optimal Solution – Establish project and system specifications from which potential solutions can be selected. − Select Optimal Solution – Select an d document product/components of the system of interest that best satisfies evaluation criteria. Preliminary Design Shall Be Established – Establish system of interest capabilities and arch itecture, including partitions, component identifications, system states and modes, major intercomponent interfaces, and external interfaces. − Analyze and Refine Requirements – Detai l and update specifications, flow down requirements to the component level, and establish disposal and interface requirements. Use the Requirements Development process (Section 4.1.1) as required. − Perform Design Analyses – Capture design analyses and trade study results in reports as required. The Systems Analysis process (Section 4.1.13) is applied here as necessary. −

•

Assumptions, guidelines, and constraints Performance measures, including budgets and margins Design disclosure Product breakdown structure

4-27


Needs, Goals, and Objectives

System Definition

Develop Evaluation Criteria

Synthesize and Down Select

Selec Optimal Solution

Preliminary Design To Spec

Perform Design Analyses

A

Analyz Preliminary and Refine Design Requirements

Evaluate, Verify, and Validate Preliminary Design

Perfor Preliminary Design

Perform Engineering Developme nt Tests

Design to Spec

Define Interfaces Complete Plans and Documentation for Qualification Items

Detailed Design B

KEY

Perform Detailed Design

Define and Control Detailed Interfaces

Fabricate/Test Qualification Items

Evaluate, Verify, and Validate Detailed Design

Perfor Engineering Tests

Complete Detail Design and Production Plans

Build to Spec

Information/Output Flows Step/Activity

Product

B

Connector

Figure 4.1 -7. Design process diagram. −

•

A

Perform Engineering Development Tests – Identify engineering items and capture development test results. Engineering tests are conducted on test units created to resemble

− −

actual components to establish confidence that the design will functi on in the ex pected environment. − Define Interfaces – Update the ICD and create integration schematics. − Perform Preliminary Design – Prepare the design disclosure, create an engineering parts list, and generate a hardware/software list. Complete the “design-to” baseline . − Complete Plans and Documentation for Qualification Items. − Evaluate, Verify, and Validate Preliminary Design – Check preliminary design for cost effectiveness and life cycle cost, and other specialty engineering considerations. Use the Verification and Valida tion processes (Sections 4.1.14 and 4.1.15) as necessary. Detailed Design of the System of Interest Shall Be Developed – The system of interest structure

−

−

−

data, and develop integration and assembly plans. Complete “build-to” baseline. Design and Control Detailed Interfaces – Update interface control documentation. Perform Engineering Tests – Capture/update development test results and finalize engineering items. Test units that closely resemble actual components are evaluated to ensure the design will operate as expected in the target environment. Fabricate/Test Qualification Items – Produce qualification items and capture qualification test results. Evaluate, Verify, and Validate Detailed Design – Check final design to assure that it meets cost-effectiveness goals, life cycle cost, and other specialty engineering considerations. Use the Verification and Validation processes (Sections 4.1.14 and 4.1.15) as necessary. Complete Detailed Design and Production Plans – Create “build-to” specificati ons and verification requirements and specifications.

4.1.7.7 Outputs In general, the output of the Design process is a technical data package that evolves over the pro ject life cycle to ultimately include all remaining lowerlevel requirements and designs and “build-to” spe ci-

and capabilities are defined in sufficient detail for conducting attainment, integration, verification, and validation. − Perform Detaile d Design – Update des ign disclosure, produce material and processes

4-28

B


fications at all levels. Depending on the stage of the design, this technical data package includes: • Results from analysis and refinement of requirements • Evaluate of cost/effectiveness, environmental, failure modes and effect analysis (FMEA), logistics support, reliability, maintainabilit y, safety and hazards, and life cycle costs • Revisions to plans such as the program management plans, SE management plans, integrated logistics support plans, S/W QA plans, verification and validation plans, risk management plans, etc. • • • • • • • • • • • • • • • • • • • • • •

• •

Successful completion of subsystem design reviews – i.e., PDR, CDR – shall be docu mented. Successful completion of system of interest design reviews – i.e., PDR, CDR – shall be documented.

4.1.7.9 Measurement The table at the top of the following page provides example base and derived measures that can be used in conjunction with executing the Design process. See discussion of Measurement on page 4-1. 4.1.7.10

System specification Evaluation criteria Operations concept System concept and architecture Design disclosures Product breakdown structure Technology development requirements ICDs Integration and assembly concept and design Integrated logistics suppo rt concept Documented selection, including rationale Design analysis reports Trade analysis and results Electronic parts list Hardware/software list Integrated schematics Instrumentation program and command list Material and process data

Methods and techniques 3

Methods and techniques in theof Design process depend, to some degree, on used the nature the system of interest. However, typic al methods and techniques include: • Brainstorming • Literature searches • Trade studies • Analysis of risks, hazards, failure modes and effects, reliabilit y, cause-consequence, etc. • Dimensioning and tolerancing • Surveys • Vendor inquiries • N2 charts • System schematics • Interface diagrams • Tables and drawings of detailed interface data • QFD • Layout sketches • Decision trees • Functional flow diagrams

Integration andtest assembly Development results design Engineering items Verification requirements and specifications

4.1.7.11 Software tools Designing a system of interest involves the po tential use of numerous tools of various sizes. These range from tools intended to help to express t he physical characteristics of the system of interest to tools that are used to analyze associated design parameters. There are concept development tools, system safety and reliability analysis tools, design-related analytical tools, graphical data development and interpretation tools, statistical tools, QA tools, and trend analysis tools. Other tools include computer -aided des ign tools; drafting tools for preparation of drawings and schematics; and tools that provide archival, CM, and review of design documentation (e.g., design and data management system (DDMS)). For a current and extensive listing of commercially available design tools, see the table provided by INCOSE at:

4.1.7.8 Exit criteria 1,4 Although design may occur throughout the remainder of the system of interest life cycle, most design activities are considered complete when CDR requirements are satisfied. Therefore, to transition these design components from the Design process to the Attainment process (Section 4.1.8), the following criteria must be satisfied: • A design solution (i.e., a build-to specification) shall be ba selined and documented that satisfies system of interest requirements and meets stakeholder needs. • Documented readiness to attain, verify, and validate the system of interest shall be established. • Customer signature approval of updatedin ternal task agreements (ITAs) or statements of work (SOWs) with firm cost to complete shall be acquired. • Safety and Mission Assurance Review Team (SMART) approval of the safety data package shall be provided.

http://www.incose.org/tools/eia632tax/eia632top.html. This t able lists tools that support the solution definition requirements of EIA-63 2.

4-29


Base Measures

Derived Measures

# of Design Elements (e.g., # of subsystems, # of H/W configuration items (CIs), # of S/W CIs)

Planned vs. Actual Design Elements

umber of Requirements Not Met By Design Solution

Planned vs. Actual Requirements Met by Design Solution

# of Allocated Requirements (to subsystems, H/W, S/W)

% Allocated Requirements – to Subsystems, H/W CIs, S/W CIs % Requirements Not Allocated

# of Requirements Verified by Analyses # of “TBDs” in Design Solution

Planned vs. Actual Requirements Verified Planned vs. Actual TBDs

# of Unresolved Interface Issues

Planned vs. Actual Unresolved Interface Issues

Elements in Design Solution Defined

Planned vs. Actual Elements Defined

Design Milestone Dates

Milestone – Planned vs. Actuals

Design Effort (FTEs)

Design Productivity

Design % Complete – Planned vs. Actuals

Design Effort – Planne d vs. Actuals Design Rate Charts Design Effort as % Total Engineering Effort 4.1.7.12 References The following documents, which were used to prepa re this secti on, offer additional insights into the Design process: 1 NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Processes and Requirements . 2

EIA-632, Processes for Engineering a System, ANSI/EIA -632-1998, 1999. 3


SP 6105, NASA Systems Engineering Handbook , 1995. 5 CMMI-SE/SW/IPPD/SS V1.1, Capability Maturing Model Integration (CMMI) for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing , 2002.

4-30


4.1.8 Attainment 1,2,3 The Attainment process is performed to transform each system of interest solution into an actual product. Attainment is accomplished through buying, building, supplying, or coding the product as determined by the trade studies. This process is executed to procure, acquire, and/or manufacture end items associated with each level of the system of interest. Resulting system of interest end items may then be assembled, integrated into other systems of interest, verified, and validated. See the Integration, Verificati on, and Validation pro cesses (Sections 4.1.9, 4.1.14, and 4.1.15) for further

ing changes to relevant stakeholders. The Lead Systems Engineer is also responsible for monitoring activities during the Attainment process to identify the potential effects of any issues that may surface in other parts of the system of interest or its external interfaces. Final ly, the Lead Systems Engineer updates technical plans and schedules, as necessary, to reflect the technical resolution of these issues. Actual solution attainment is the responsibility of the Subsystem Lead Engineers . By working closely with the Lead Systems Engineer, the Subsystem Lead Engineers ensure subsystem solutions are transformed

details regarding the disposition of attained items. The result of successfully completing this end process is a fully integratable system of interest that satisfies its specified requirements. System of interest integr a tion preparation during attainment ensures that both internal and external interfaces function according to requirements; that designed states, modes, dynamic allocations, or other operational switching functions perform as required; and that any desi gned overload conditions, reduced operational levels, or designed-in degraded mode of operations are included. Example characteristics of the Attainment process are: S/W is coded, data are documented, services are performed and documented, electrical and mechanical parts are fabricated, product-unique manufacturing processes are put into operation, processes are documented, and facilities are constructed.

into appropriate of interest solutions (i.e., fabricated items,systems S/W code, acquired components) that are ready for further integration and test. 4.1.8.4 Life cycle 1 Attainment begins at the point where the documented solution (i.e., the “build-to” specification) for the system of interest is considered fixed and ends with the successful completion of the system of interest acceptance. This corresponds to the end of Phase C, Design, and the initial stages of Phase D, Development. 4.1.8.5 Inputs 1,5 The primary inputs to attainment are: • Baselined “build-to” specifications that satis fy requirements and meet stakeholder needs. • Documented readiness to produce, verify, and validate the system of interest. Inputs into the Attainment process will take place during various stages of completion. Some will be

4.1.8.1 Function1 In the Attainment process: • The documented solution shall be made available and communicated among individuals involved with transforming the solution into a produc t. • Procedures and work instructions and supporting enabling systems shall be in place for transforming the soluti on into a product. • The solution shall be transformed into a product.

conceptual or preliminary documents and only partially complete, while others will be fully complete and approved. Following is a listing of typi cal inputs : • System specification • Technology development requirements • Documented selection with rationale • Factors such as cost/effectiveness, environmental, FMEA, logistics support, producibility, R&M, safety/hazard analysis, andlife cycle costs. • Acceptance criteria • Material and process data • Electronics parts list • Hardware/software list • Users’ manual • Plans such as the PMP, QA plan, acceptance plan, development plan, safety plan, reliability plan, integration and assembly plans, verification and validation plans, qualification item plan, etc.

4.1.8.2 Objective 1 The objective of the Attainment process is to build subsystems of interest and prepare these subsystems for progressive integration by creating the overarching system of interest while developing confidence that the results will meet system of interest requirements. 4.1.8.3 Responsibilities 4 In the Attainment process, the Lead Systems Engineer is primarily responsible for requirements baseline maint enance and requirements feedback to design. The Lead Systems Engineer ensures and manages the technical integrity of the requirements baseline, continually updating it as various changes are imposed on it d uring the Attainment process and communicat-

4.1.8.6 Steps 5 The following diagram ( FIG. 4.1-8) illustrates the major steps and products of the Attainment process. This process begins with outputs from the Design process (Section 4.1.7) and ends with a fully t est ed

4-31


system of interest. More detailed activities associated with these steps are provided below. Receive Product(s) “Build-to” Spec(s)

Reuse Product(s)

Communicate Solution

Assemble Product(s)

KEY

Verify and Validate Product(s) Against Requirements

Build Product(s)

Attain Products

Support Product Attainment

Product(s)

Develop Procedures

Provide Enabling Systems

Step/Activity

Assembled Product(s)

Verify Assemblies

Validate Assemblies

Prepare User’s Manual

Prepare Maintenance Manuals

Train System Operators and Maintainers

Complete Product(s)

Document Lessons Learned

Finaliz Text Procedures


Product

Figure 4.1 -8. Attainment process diagram. The basic steps in the Attainment process are: • Products Shall Be Acquired, Fabricated, or Coded − Communication Solution – The d ocumented solution is made available and communicated among those individuals involved in transforming the solution into a product. − Receive, build, or reuse the end item(s); i.e.,

•

•

Other activities occur during the Attainment process that facilitate either end item acquisition or fabrication activities. These activities include: • Develop Procedures – Procedures are required to fabricate end items. These procedures provide the specific instructions necessary at each stage of fabrication to create the item. •

the st-level items in the sy stem of i nterestlowe architecture. − Fabrication is conducted in accordance with the “build-to” design and manufacturing/production plans. Product(s) Shall Be Verified and Validated Against Requirements (Verification and Validation processes, Sections 4.1.14 and 4 .1.15) − Ensure the product(s) satisfy requirements. − Ensure the item(s) satisfy the intent of the “build-to” solution. If more than one end item is required to create the system of interest: − Product(s) shall be assembled. • Assemble in accordance with the “buildto” design and assembly plans. – Assemblies shall be verified (Verification process, Section 4.1.14). • Verify any assemblies in accordance

•

•

•

•

•

•

with the verification plan. – Assemblies shall be validated (Validation process, Section 4.1.15). Validate an y assemblies in accordan ce with the validation plan.

Provide Systems – Define, establishEnabling any enabling systems needeplan, d to and support fabrication o f the end items. Examples of enabling systems include qualification unit and ground support equipment. Prepare User’s Manual – As the end item is acquired or fabricated, initiate preparation of the user’s manual. Prepare Maintenance Manuals – Begin maintenance manual development during the Attainment process. Train System Operators and Maintainers – Initiate training for system operators and maintainers. Document Lessons Learned – Lessons learned provide information for Attainment process refinement. Finalize Test Procedures – Finalize test procedures for acceptance testing.

4.1.8.7 Outputs 2,5 Primary outputs from the Attainment process, which are completed, validated, and verified products, are:

4-32


Acquired H/W, S/W, firmware end products or composites of system of interest products built or coded to their specified requirements, drawings, or descriptive documents; or other needed physical entities (e.g., trained personnel, certified facilities, special techniques, manuals). • Lessons learned. The following provides a listing of typical outputs: • Evaluation, verification, and validation of design factors such as cost/effectiveness, environmental, producibility, FMEA, logistics support, reliability, maintainability, safety/hazard analysis, and life •

• • • • • • • • • • • • • • • •

• •

A system of interest is developed or acquired. Verification and validation of the system of interest is accomplished and documented.

4.1.8.9 Measurement The table at the bottom of the page provides example base and derived measures that can be used in conjunction with the Attainment process. See discussion of Measurement on page 4-1. 4.1.8.10 Methods and techniques 4 Methods and techniq ues include: • •

cycle costs. End items Support items Spares QA results As -built documen tation Technical manuals and data User’s manual Integrated system Support equipment Operations procedures Delivered/installed system Final documentation Trained personnel Waivers Phase III safety data package Final test procedures

CM of requirements baseline Functional analysis tool − N2 charts − Functional flow diagrams

4.1.8.11 Software tools Many S/W tools are required to attain system of interest end items. The nature of these tools depends on whether the end item is a fabricated item, a S/W item, or an acquired item. Most of the tools are als o outside the dom ain of SE – i.e., they are unique tools associated with fabrication, S/W development, or acquisition – and, as such, are not referenced in this document. The SE tools used in this process are tools used for requirements management and, if necessary, functional analysis. For a list of potential tools, see the table provided by INCOSE at: http://www.incose.org/tools/eia632tax/eia632top.html.

4.1.8.8 Exit criteria The following shall be accomplished to satisfy exit from this process: Base Measures

Derived Measures

Defects in Design (by phase)

Design Defects – Projected vs. Actuals

Milestones Dates (reviews, change control boards, baseline document publication)

Milestones – Planned vs. Actuals

Code Effort (FTEs)

Code Productivity Code Effort – Planned vs. Actual Code Rate Charts Code Effort as % Total Engineering Effort

Code Size (# lines of code)

Code Size – Planned vs. Actual

Defects in S/W Code (by phase)

Code Defects – Projected vs. Actuals

Code % Complete – Planned vs. Actuals

4-33


4.1.8.12 References The following documents, which were used to prepare this section, offer additional insights into the Attainment process: 1 NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Processes and Requirements . 2

EIA-632, Processes for Engineering a System, ANSI/EIA -632-1998, 1999. 3 CMMI-SE/SW/IPPD/SS V1.1, Capability Maturity Model Integration (CMMI) for Systems Engineering, Software Engineering, Integrated Product and Process Development , and S upplier Sourcing , 2002. 4



4-34


4.1.9 Integration 1,2 The Integration process is performed to interconnect distinct and separable elements to form a complete final system for verification. An integral part of ensuring physical system integration success is comprehensive integration planning; i.e., continually checking that all of the pieces remain compatible and t hat they will support the intended product. In this activity, each system element is analyzed to ensure compatibility with other elements within the system of interest. Compatibility with other (external) enabling systems is

4.1.9.2 Objective 2,3 The primary objective of this process i s to manage activities to achieve complete system integration through the progressive assembly of elements according to a defined integration sequence and procedures . The Integration process integrates end products, enabling systems, and external interfacing systems as appropriate to the level of the system of interest and as required for verification.

also verified. This ensures that each system element canassessment be adequately accommodated with respect to the basic constraints imposed by the system of interest and the final integrated system. Another key aspect of the integration process is management of internal and external interfaces of the system of interest. Physical integration is more than just a one-time assembly of elements at the conclusion of design and attainment. Integration is conducted incrementally, using an iterative process of assembling elements, evaluating these elements, and assembli ng more ele ments. This process steadily progresses throug h increasingly more realistic incremental functionality until the final system is achieved. There is a higher probability that a system of interest that has been in tegrated in this manner will pass verification and validation. For some systems, the last integration phase will occur when the system is deployed at its intended operational site. Execution of the physical interconnection system integration activities follows the SE Design and Attainment processes (Sections 4.1.7 and 4.1.8 ) and re sults in a fully integrated system that will be verified by the SE Verification process (Section 4.1.14).

all of the Integration process, including themanagement integration sequence. In this role, the Lead Systems Engineer ensures integration planning activ ities are performed, Test Readiness Reviews (TRRs) are conducted, and only verified CIs are integrated into the next-higher assembly for further verification. The Verification Lead supports the Lead Systems Engineer to ensure that development and documentation of system-level integration and test plans are accomplished and that the required integration facilities have been verified to provi de the necessary conditions, have been scheduled, and are available.

4.1.9.3 Responsibilities 4 The Lead Systems Engineer is responsible for ove r-

4.1.9.4 Life cycle Integration is an activity that exists at all points in the project life cycle. The “Vee” chart, which appears as a foldout as page 35, represents systems definition and development in three dimensions. The horizontal axis of the chart is notional time. The vertical axis represents levels of system/element decomposition. The further down on the chart, the more detailed the system information and, hence, the system depth. Implicit in the chart is an axis perpendicular to the paper that represents the increasing number of subsystems identified and being decomposed in parallel (system breadth). On the upward Integration and Verification leg (i.e., the right side of the “Vee”), integration activities consist of executing the integration and verification plans developed on the accompanying downward leg level. The hard work for integration takes place on the downward leg. Integration in the downward leg is applied at each baseline level to ensure compatibility is maintained during system definition and design. While descending down this leg, the process remains the same except for the level of detail analyzed. The horizontal lines going across the “Vee” chart indicate the baseline levels and reflect the connection between the integration

4.1.9.1 Function1 In the Integration process: • Planning for the needs (i.e., H/W, S/W, human factors, facility, personnel, etc.) to integrate individual elements into the system of interest shall be performed. • Procedures and work instructions and supporting enabling systems shall be put into place for integrating the products. • The configuration of products being integrated, as well as the integrated products as being representative of the configuration in which the system of interest will be used, shall be validated. • Testing of the interface(s) shall be performed. • Integration planning shall be performed to ensure success in the physical and operational integration of the system of interest.

plan and the assembly of e lements into subsystems on the upward leg of the “Vee.” Simultaneously, analysis is taking pace to assure integra tion on the perpendicular axis. The 3-way analysis approach produces detailed element-to-element integration and

4-35


4.1.9.6 Steps 2,3,4,6 The diagram at the bottom of the page ( FIG. 4.1-9) illustrates the major steps and products of the Integration process. The Lead Systems Engineer is responsible for ensuring all major steps in the Integration process are performed. Adherence to the major steps of this process directs the project toward meeting its integration requirements. For each major process step, additional guidance is provided as to the expected typical subprocess activities and products. • Integration Planning Steps

optimizes the system with respect to overall effectiveness (rather than sub-optimizing the system by optimizing each element for its maximum performance). Integration in the downward leg consists of identifying all interfaces (physical, electrical, data/information, and operational) and documenting the corresponding interface requirements in ICDs. As for any requirement, interface requirements in the ICDs must have verification plans written as part of the baseline. The context for the verificati on plans for the interface re quirements in the ICDs is that baseline level’s operations scenarios/concepts/plans/procedures. Finally,

−

integration plans how mustthe be elements developedwill at that baseline level to describe be assembled or integrated to be ready for test and verification. Commensurate ICDs, verification plans, operational concepts, and integration plans, which are all written at the same baseline level on the downward leg of the “Vee,” control the execution of integration and verification at the same baseline level on the upward leg of the “Vee.” 4.1.9.5 Inputs 2,3,5 Typical inputs to this process include, but are not limited to: • Operations concept • ICDs • Development schedule and status • System requirements • Design documentation • Validated products to be integrated • • •

An integration plan and process shall be established. Develop the overall project plan and process to achieve system integratio n and include this as part of the Systems Engineering Management Plan (SEMP). • Define the project integration responsibilities, especially as they relate to the project acquisition strategy (Section 4.3.1). • Provide the project manager with cost and schedule inputs related to integration engineering life cycle activities in support of the project planning effo rt. • Ensure a conceptual version of the integration plan is available at the SDR, a preliminary version is available at the PDR, and a final/approved version is available at both the CDR and the Production Readiness Review (ProRR). •

Product breakdown structure System hierarchy System architecture (functional, physical)

Integration Planning

Interface Compatibility

Establish an Integration Plan and Process

Determine Integration Sequence

Continue Integration Plan

System Integration

Confirm Product Readiness for Integration

KEY

Step/Activity

Establish Integration Environment

Establish Integration Procedures and Criteria

Review and Manage Interface Descriptions

Assemble Products

Product

Figure 4.1 -9. Integration process diagram.

4-36

Evaluate Assembled Products

Fully Integrated System



4-37


4-38


−

−

−

An integration se quence shall be determined. • Identify the products to be integrated. • Identify the product integration verifications to be performed using the definition of the interfaces between products. • Identify alternative product integration sequences. • Select the best integration sequence. • Periodically review the product integration sequence and revise, as needed, to ensure that variations in production and delivery schedules have not adversely

Monitor and address lower-level hierarchy effects and issues to the system level. Interface Compatibility Steps − Review and management of interface descriptions shall be performed. • Review interface data for completeness and ensure complete coverage of all interfaces. • Ensure that products and interfaces are marked to ensure easy and correct connection to the joining product. • Periodically review adequacy of interface descriptions. •

•

impacted the sequence or compromised the factors on which earlier decisi ons were based. • Record the rationale for decisions made and deferred. An integration environment shall be established. • Identify requirements for product integration environment. • Identify verification criteria and procedures for product integration environment. • Decide whether to make or buy needed product integration environment. • Develop integration environment if a suitable environment cannot be acquired. • Maintain product integration environment throughout the project. • Dispose of those portions of the environment that are no longer useful. Integration procedures and criteria shall be

•

Ensure compatibility of the interfaces throughout the life of the product. Resolve conflict, noncompliance, and change issues. • Maintain repository for interface data that are accessible to project participants. System Integration Steps − Product readiness for integration shall be confirmed. • Perform hardware/software integration (HSI) prior to the PDR to e stablish confidence that the H/W and S/W design concepts are adequate to meet functional interfaces. • Perform HSI prior to CDR on engineering units to establish confidence that the H/W and S/W detailed designs meet requirements. • Track status of all products as soon as they become available for integration. •

•

•

established. Establish and maintain integration procedures for the products. • Establish and maintain criteria for product integration and evaluation. • Establish and maintain criteria for validation and delivery of integrated product. Continually Perform Integration Planning − Horizontal integration shall be performed to: • Monitor and integrate system definition activities and results at the lower levels of the hierarchy to ensure compatibility . • Monitor and integrate the preliminary design activities and results at lower levels of the hierarchy to ensure overall system integrity. This monitoring and integration includes tracking interfaces, TPMs, allocations, etc. • Track parameters, budgets, and inte rfaces as final design progresses to ensure that the design will fit together and work, and to facilitate later physical integration of the system. •

•

−

4-39

Ensure products are delivered to the product integration environment in accordance with the product integration sequence and available procedures. • Confirm receipt of each properly identified product. • Ensure each received product meets its description. • Check configuration status against the expected configuration. • Perform pre-check (e.g., by performing a visual inspection and using basic measures) of all physical interfaces before connecting products. Assemble Products – Integration of syste m elements shall proceed in accordance with the integration plan. • Ensure readiness of the product integration plan. • Ensure assembly sequence is properly performed. • Revise product integration sequence and available procedures as appropriate.


Recommend verification and validation plans/pr ocedures updates based on integration outcomes. Assembled product components shall be evaluated. • Conduct a TRR of assembled products. • Record the TRR results. •

−

• • •

4.1.9.8 Exit criteria Exit criteria in clude: • Attainment of a fully integrated system of interest. • Successful TRR in preparation for verification and acceptance of the system.

4.1.9.7 Outputs 4 Primary outputs from this process are: • Integration plans • System integration process (to include in SEMP) • • • •

TRR results Verification and validation plan/procedure updates Fully integrated system

4.1.9.9

Integration procedures and criteria Integration sequence Integration environment Integration environment requirements

Measurement

The following table provides example base and derived measures that can be used in conjunction with executing the Integration process. See discus sion of Measurement on pag e 4-1.

Base Measures

Derived Measures

Requirements Management Measures Total # of Integration Environment Requirements (e.g., # of shalls)

# of Integration Environment Requirements Added, Changed, Deleted

Integration Requirements Managed – Planned vs. Actuals Integration Requirements Volatility = % Added, Changed, Deleted

Requirements Development Measures Total # of Shalls for Integration Environment

Total # of Integration Requirements – Planned vs. Actuals Integration Requirements Definition Productivity

Integration Environment Requirements Effort (FTEs)

Integration Requirements Definition Effort – Planned vs. Actuals Integration Requirements Definition Rate Charts Integration Requirements Definition Effort as % Total Engineering Effort Technical Solution (TS) Measures # of Products to Integrate

Integration Size – Planned vs. Actual % Integration Completed – Planned vs. Actuals Integration Productivity Integration Effort – Planned vs. Actuals

Integration Effort (FTEs)

Integration Rate Charts Number of Integration Anomalies

Integration Effort as % Total Engineering Effort Integration Anomalies – Projected vs. Actuals

Number of Interface Defects

Interface Defects – Projected vs. Actuals

Planning Measures

Integration Planning Milestone Dates (e.g., due dates on planning checklist) Integration Planning Effort (FTEs)

Integration Planning % Complete – Planned vs. Actuals % Integration Planning Milestones Met – Planned vs. Actuals Integration Planning Productivity Integration Planning Effort – Planned vs. Actuals

Int egration Plan Status Monitoring and Control Measures Tracking Integration Milestones Dates

Integration Issues/Actions Status Overall Integration Management Effort

Integration Planning Effort as % Total Engineering Effort % Integration Plan Reviewed; % Approved by Identified Stakeholders % Tracking Integration Milestones Met – Planned vs. Actuals % Integration Issues Closed Integration Management Effort – Planned vs. Actuals Integration Management Effort as % Total Engineering Effort

CM Measures

CI Status

CI Status Summary

4-40


4.1.9.10 Methods and techniques5 Several methods and techniques are available. These include: • Integration Maps/Trees – An integration map or tree shows how elements are integrated t o form the system of interest. Each node represents an element of the system of interest. • N2 Diagramming – A matrix displaying functional interactions, or data flows, at a particular hierarchical level. • Simulations – For example, the use of threads, rapid prototypes, virtual prototypes, and physical

plans, processes, procedures, requirements, analy ses, and criteria developed and documented under this process. Once developed, thes e documents should be placed under CM control to maintain, control, and support their evolution. Also, to ensure that proper configuration of the elements requ ired for integra tion is obtained, a standard CM tool should be employed to document a concurrent baseline that is consistent with the output of the project. The use of a basic office automation spreadsheet and graphical tools is applicable in the development of N2 charts and integration sequences (maps, trees), respectively. Mathematical S/W tools should be considered to support the development and execution of mathematical models during analytical integration activities.

prototypes. of virtual vs. physical prototyping The useddegree to support element integration depends on the functionality of the design tools, the complexity of the element, and the risk associated with that element. • IFWGs – Can be established to review interface statements/drawings, and are a good means of ensuring direct interaction of all parties to the system of interface. Horizontal integration methods and techniques include: • Mathematical models (e.g., to ensure the power consumption needs of the overall system can be met by the power supplied by or to the sy stem; or to integrate experiments, payloads, or payload complements at the rack, pallet, lab, or partner levels for purposes of transportation, accommodation, or operations) • Data collection and analysis • • •

4.1.9.12 References The following documents, which were used to prepare this section, offer additional insights into the SE Integration process: 1 NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Processes and Requirements . 2 CMMI-SE/SW/IPPD/SS V1.1, Capability Maturity Model Integration (CMMI) for Systems Engineering, Softw are Engineering, Int egrated Product and Process De velopm ent, and Supplier Sourcing , 2002. 3

EIA-632, Processes for Engineering a System, 1999. 6105, NASA S ystems Engineering Handbook , 1995.

Compatibility analysis Impact assessments Planning and scheduling analyses

4 SP 5

INCOSE Systems Engineering Handbook , Version 2.0, 2000.

4.1.9.11 Software tools5 A standard office automation word processor is sufficient for documenting the integration-related

6

NPR 7120.5B, NASA P rogram and P roject Management Processes and Requirements , 2002.

4-41


4.1.10.2 Objective 1 The objective of the Technical Work and Resource Management process is to document and status the SE effort required t o accomplish the goals and objectives of the system of interest. This includes describing how the efforts are carried out, who accomplishes them, how they are controlled, and how technology is transitioned from the technology base to system of interest products. Basically, the objective of this process is to establish the SE management approach – whether it is documented in an SEMP or some other document – and record and report status against it.

4.1.10

Technical Work and Resource Management 1,2 The Technical Work and Resource Management process is performed to plan how technical aspects of the work will be accomplished and to identify the re sources that are necessary to accomplish this work. Execution of this process by the SE effort provides technical inputs to the overall project work and resource planning effort. There are two basic aspects to this process: the plan and organize aspect, and the monitor and control aspect. The plan and organize aspect identifies technical needs and constraints in support of the overall project planning effort. Technical requirements, which define the structure required to bring the system of interest into being, include identification, integration, and scheduling of all engineering functions and tasks; work breakdown structure (WBS) development; organiza tional structure definition (as related to the project); and descriptions of or references to key policies, standards, and processes. The results are documented in an SE management approach, often called SEMP, which relates technical requirements to project requirements, providing the structure to guide and control the integration of engineering activities needed to achieve SE objectives that are consistent with a top-level PMP. The monitor and control aspect provides visibility into technical progress and risks, and detection of variances needing corrective action. Monitoring requires tailoring the level of control of the complexity and risk of the project, tracking data for the level of control, and initiating a corrective action when measures do not meet expected results. Controlling requires setting thresholds of control limits and activating corrective actions based on risk analysis. A review process com pares the results against the technical effort documented estimates, commitments, and plans. Adequate visibility enables timely corrective action to be taken before performance deviates significantly from plans.

4.1.10.3 Responsibilities 3 The Lead Systems Engineer is responsible for managing the SE effort throughout the technical aspects of the project life cycle. This includes managing the system of interest decomposition and definition processes as well as the Integration, Verification, and Validation processes (Sections 4.1.9, 4.1.14, and 4.1.15). Attendant with this is the requirement to control the completeness and integrity of project technical baselines, ensuring an efficient and logical progression through these baselines while maintaining cost and schedule consistent with business baseline. SE audits the design and coding process and the design engineering solutions for compliance to all hig her-level baselines. SE also ensures that concurrent engineering is properly applied throughout the project life cycle by involving the required specialty engineering disciplines. The SEMP is the guiding document for all these activities. The Project Manager approves the SEMP, ensures that SEMP requirements and plans are properly integrated into the PMP, and allocates project resources to execute the SEMP. ( NO TE : At the discretion of the Project Manager, the SEMP and the PMP may be combined into a single document.) 4.1.10.4 Life cycle The Technical Work and Resource Management process begi ns at the ea rliest stages of the project life cycle and continues throughout the project. Planning for and development of the SEMP is one of the first planning activities of any project. The SEMP then becomes the baseline against which SE tasks, budgets, and schedules are measured throughout the remainder of the project. The SEMP is not a static document, however. It must be revi ewed and revised as co nditions change on the project.

4.1.10.1 Function1 In the Technical Work and Resource Management pro ces s: • Technical content and technical products (e.g., documents, drawings) of the work to be accomplished shall be defined. • Detailed technical schedule estimates necessary to accomplish the work shall be defined. • Technical skills and capabilities necessary to perform the work shall be identified. • Resource estim ates (e.g., cost, labor) to perform the work shall be provided. • Status relative to the cost, schedule, and technical progress of the work shall be provided.

4.1.10.5 Inputs 3 Typical inputs required by the Technical Work and Resource Management process to create an SEMP include: • Needs, goals, and activities

4-42


organizing, staffing, directing, coordinating, reporting, and budgeting. − Estimate the Scope of the Project – Establish a system of interest structure to estimate the scope of the project. Identify and describe tasks in sufficient detail to specify estimates of project tasks, responsibilities, and schedule. Identify system of interest products and any enabling product s to be produced, acquired, or reused. − Establish Estimates of Technical Attributes – Establish and maintain estimates of technical

Project plans and schedules, including the PMP and other plans and schedules • Assumptions, guidelines, and constraints • Concepts and architectures, including system, functional, and operations • Product breakdown structure • System specification • Requirements, including top-level project, science, and system/segment Once the SEMP is established and commitment to it are secured, inputs to this process are typically to progress status with regard to tasks, budgets, and schedules. •

attributes of work productsand andstructure tasks. Size, connectivity, complexity, of deliverable and non-deliverable work p roducts, documents, and operational and support S/W are typical inputs to estimate. These parameters are used to support technical planning estimates of efforts, cost, and schedule. See the Control process (Section 4.1.12) for identification and allocation of technical attributes.

4.1.10.6 Steps 4 The following diagram ( FIG. 4.1-10) illustrates the major steps and products of the Technical Work and Resource Management process. More detailed activities associated with these steps are provided below. • Establish Estimates – SE planning parameters shall be established and maintained. Parameters include all of the information needed by th e project to perform necessary SE planning

Plan and Organize Establish Project Scope

Establish Estimates

A

Establish Estimates of Technical Attributes

Project Attributes

Identify

Plan for Data

and Schedule

Project Risks

Management

Resources

Identify Processes

Plan Stakeholder Involvement

Establish the SEMP

Plan for Needed Knowledge and Skills

Obtain SEMP Commitment

Determine Estimates of Effort and Cost

Establish Budget

Develop the SEMP B

Define Project Life Cycle

Review Plans that Affect the Project

C

Reconcile Work and Resource Levels

Plan for Project

Obtain SEMP Commitments

A

B

SEMP

SEMP Commitments

C

D

Monitor and Control C

Planning Commit- Project Data Stakeholder Parametersments Risks Management Involvement

D

Manage Corrective Action

KEY

Conduct Progress Reviews

Monitor

Monitor Technical Efforts

E

Analyze Issues

Step/Activity

Take Corrective Action

Manage Corrective Action

Figure 4.1 -10. Technical work and resource management process diagram.

4-43

Conduct Milestone Reviews

Correction Action Results


Product

Results

B

Connector

E


Define Project Life Cycle – Define t he project life cycle phases on which to scope the major system of interest phase for the current state of the product, expected future phases, and the relationships and effects among the phas es. Adjust planning parameters to account for relationships and effects among phases. − Determine Estimates of Effort and Cost – Estimate the project effort and cost for the work products and the task based o n estimation rationale. Develop the SEMP – An SEM P shall be est ab−

•

−

−

•

lished maintained as the basis managing the SEand aspects of the project. This for SEMP details the work activities and work products of the integrated technical effort across the project. − Establish Budget and Schedule – Establish and maintain the project budget and schedule. − Identify Project Risks – Identify and analyze project risks (Risk Management process, Section 4.3.2). − Plan for Data Management – Plan for the management of project data. − Plan for Project Resources – Plan for necessary resources to perform the SE aspects of the project. − Plan for Needed Knowledge and Skills – Plan for knowledge and skills needed to perform the project. − Identify Processes – Identify technica l and engineering management proces ses to be

•

Reconcile Work and Resource Levels – Reconcile the SEMP to reflect available and estimated resources. When integrated teams are involved, special attention must be paid to resource commitments in circumstances of distributed integrated teams and when individuals are on multiple integrated teams in one or more projects. Obtain SEMP Commitments – Obtain commitment from the project manager and relevant stakeholders responsible for performing and support SEMP execution.

Monitor Technical against Effort –the Technical shall be monitored SEMP. effort − Monitor SEMP Planning Parameters – Monitor the actual val ues of the project planning parameters against the SEMP. See the Control process (Section 4.1.12) for actual tracking and reporting of significant technical attributes. − Monitor Commitments – Monitor commitments against those identified in the SEMP. − Monitor Project Risks – Monitor risk against those risks identified in the SEMP (see the Risk Management process, Section 4.3.2, for further details of this activity). − Monitor Data Management – Monitor the management of project data against data management requirements in the SEMP. − Monitor Stakeholder Involvement – Monitor stakeholder involvement against the SEMP. −

used in executing the project (see the Quality Management process, Section 4.3.4, for additional details regarding identifying and tailoring the project processes.) − Plan Stakeholder Involvement – Plan the involvement of identified stakeholders. − Establish the SEMP – Establish and maintain the SEMP and its contents. Obtain Commitment to the SEMP – Commitments to the SEMP shall be established and maintained. − Review Plans Affecting the Project – Review all plans that affect the project to understand project commitments; e.g., technology development plans, systems integration plans, verification and validation plans, and PMPs. Plans developed within other process areas typically contain information similar to that called for in the SEMP. These

•

plansand mayshould provide ance be additional compatibledetailed with andguidsupport the SEMP to indicate who has authority, responsibility, accountability , and control.

Conduct Progress Reviews – Periodically review the progress, performance, and issues of the project against the SEMP. − Conduct Milestone Reviews – Review the accomplishments and results of the project at selected project milestones (see the Reviews process, Section 4.1.16, for further details of this activity). Manage Conservative Action to Closure – Significant deviations from plan shall be analyzed and corrective actions shall be managed to clo sure. See the Quality Management process (Section 4.3.4) and the Safety and Mission Success process (Section 4.1.11) for related details associated with management corrective actions. − Analyze Issues – Collect and analyze the issues and determine the corrective actions necessary to address these issues. − Take Corrective Action – Take corrective −

4-44

action(s) on identified issues. Manage Corrective Action – Manage corrective actions to closure.


4.1.10.7 Outputs 4 The output associated with planning and orga nizing technical work and resource management shall be an SEMP. The SEMP, whether it is a standalone document or is embedded in the PMP, is the single integrated technical planning document. It incorporates not only what the project needs to do to accomplish the SE effort, but also how the efforts are to be carried out, who will accomplish them, how they are to be controlled, and how the technology is to be transitioned from the technology base to the system of interest products. Actual structure and content of the SEMP will vary according to project needs, but generally the SEMP should be organized to describe the: • System of interest and its structure. • Technical processes. • Project technical management processes. • Organizational structure. • Constraints and concerns. An outline for development an SEMP is found in Appendix D of this document. Specific content of the SEMP would typically include: • SE task descriptions, including size and complexity of tasks and work products • WBS, including work packages and task dictionary • Technical approach and processes, including project life cycle phases • Technical management approach and processes, including estimating m odels, effort and cost es timates with rationale, schedule and schedule dependencies, budget, and identified and •

References to or actual plans for engineering functions; e.g., reliability, maintainability, human engineering, safety, producibility, integrated logistics support, data management, CM, etc. • Staffing requirements, including inventory of skills needed, and staffing and new hire plans • Critical facilities and equipment lists • Records indicating reviews and commitments to the SEMP For the monitor and control aspect of this process, major outputs should include: • Records of project performance and significant •

• •

deviations Documented project progress and milestone review results List of issues needing corrective action and corrective actions results

4.1.10.8 Exit criteria The exit criteria for the Technical Work and Re source Management process shall be: • Establishment of and commitment to an SEMP. • Regular, documented reviews of technical effort against the SEMP. 4.1.10.9 Measurement The following table provides example base and derived measures that can be used in conjunction with executing the Technical Work and Resource Management process. See dis cussion of Measurement on page 4-1.

prioritized risks Acquisition strategy and plans in support of SE activities Base Measures

Derived Measures

Planning Milestone Dates

Planning % Complete – Planned vs. Actuals % Planning Milestones Met – Planned vs. Actual s Project Planning Productivity Project Planning Effort – Planned vs. Actuals Project Planning Effort as % Total Engineering Effort % Tracking Milestones Met – Planned vs. Actuals

Planning Effort (FTEs)

Tracking Milestone Dates (e.g., monthly progress reviews, milestone reviews) Issues/Actions Status Overall Technical Project Management Effort Tailoring Report Completion # of Processes Tailored (i.e., modified or

% Issues Closed Project Management Effort – Planned vs. Actuals Technical Management Effort as % Total Engineering Effort Planned vs. Actual Tailoring Dates % Process Compliance

tailored out) # of Plans and Associated Status

% Processes Modified or Tailored Out % Plans Reviewed; % Approved by Identified Stakeholders

4-45


4.1.10.10 Methods and techniques 3 The following methods and techniques are representative of those typically used in technical work and resource management: • WBS analysis • Networking scheduling • Workflow diagram • Program evaluation review technique (PERT) charting • Activity-on-arrows diagram • Precedence diagrams • Gantt charts • •

Resource leveling Decision tree

4.1.10.11 Software tools Depending on the size and complexity of the system of interest, the tools used to support the Technical Work and Resource Management process could vary from typical office products (e.g., spreadsheets, word processors, and graphical representation tools) to very sophisticated commercial products built on top of Microsoft Project or other standard project management applications. Generally, the basic re quirements are to use tools that support capturing, analyzing, and publishing schedules, costs, budgets, and resources. Other tools may be required to sup port the capture and analysis of skill, knowledge, education, and training information. These could be commercial tools, when management and tracking of many people over a period of years is required, or a project built using spreadsheets or commonly available databases. 4.1.10.12 References The following documents, which were used to prepare this section, offer additional insights into the Technical Work and Resource Management process: 1 NPR 71xx.x (document number no t yet assi gned), NASA Systems Engineering Processes and Requirements. 2 EIA-731.1, Systems Engineering Capability Model , 2002. 3

SP 6105, NASA Sys tems Engineering Handbook , 1995. 4 CMMI-SE/SW/IPPD/SS V1.1, Capability Maturity Model Integration (CMMI) for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing , 2002. 5

NPR 7120.5B, NASA P rogram and P roject Management Processes and Requirements , 2002.

4-46


4.1.11 Safety and Mission Success 1,2 The Safety and Mission Success process is performed to provide for early identificati on, analysis, reduction, elimination, and control of hazards to ensure the safety, reliability, maintainability, and quality of the system of interest. The requirements on the part of SE are to monitor, coordinate, and integrate the overall project safety and mission success establi shed by project management. Project management and SE must rely on contributions from both the specialty engineering disciplines and the traditional design disciplines for functional expertise and specialized analytic methods related to safety and mission success. Specialty engineering areas include reliability, maintainability, QA, quality engineering, and safety engineering. Specialty engineers contribute throughout the SE process. As part of the technical effort, they apply specialized analytical techniques; define system requirements in their areas of expertise; perform analyses; and evaluate data packages, engineering change requests, test results, and documentation for major project reviews. A part of the systems engineer’s function is to verify that these specialty engineering activities are coherently integrated into the project.

• • •

4.1.11.2

Objective 3

The primary objective of this process is to integrate specialized quality engineering and safety, reliability, maintainability, and quality assurance techniques/processes throughout all phases of the project life cycle. Other objectives are to ensure that: • Safety and mission success processes will be used throughout the project life cycle to prevent potential system failures. • Project decisions made will be consistent with JSC S&MA principles. • The safety of the public, NASA flight crews, employees, and critical assets will not be jeopardized. 4.1.11.3 Responsibilities The Project Manager ensures that safe ty and mis sion success processes are performed by the project. The Lead Systems Engineer is respons ible for integrating safety and mission success functions into the project and for coordinating the performance

4.1.11.1 Function1,2,3 Safety engineering is performed to provide for the early identification, analysis, reduction, elimination, and/or control of hazards associated with the system of interest. Reliability engineering implements specific design features to ensure that the system of interest can perform in physical environments for the required amount of time. Maintainability engineering implements specific design features to optimize maintenance characteristics of the system in the physical environments. Quality engineering and QA verifies that the system of interest is produced and delivered in accordance with its safety, performance, and design requirements, and that approved processes are followed during the project life cycle. S/W QA ensures that the S/W processes and products conform to requirements, standards, and procedures through a planned and sys tematic set of activities as stated 18 in NASA-STD-2201-93. Safety and mission success personnel at JSC will comply with the documents maintained in the safety and mission assurance (S&MA) documentation tree (http://www.hq.nasa.gov/office/codeq/doctree/gdoc.htm ). The Safety and Mission Success process will: • Scope the amount of S&MA support needed. •

Hazard mitigation efforts shall be ensured to be implemented as designed and to perform the intended function. − Systems safety s hall be an integral part of the overall risk management process using probabilities estimates and severity classes for understanding and managing safety risks. Ensure the system of interest is reliable. Ensure the system of interest is maintainable. Ensure the system of interest is of high quality. −

of these functions by the project team.atThis working with the S&MA Directorate JSCincludes to scop e the best approach to meet the specific needs of the project as related to safety and mission success. S&MA project support is provided through S&MAassigned representatives. In this capacity, the S&MA Representatives will (1) assist the project manager in ensuring that all S&MA requirements are appropriately defined and implemented; (2) guide the project during life cycle development through the safety, assurance, procurement, certification, shipping, etc., processes; and (3) serve as a point of contact between the project team and the S&MA D irectorate, assur ing proper coordination, review, or approval of all safety and mission success responsibilities and practices. Support from numerous personnel is provided, as required, to meet the needs of the project. The safety engineer, reliability engineer, maintainability engineer, quality engineer, QA specialist, procurement quality assurance (PQA) specialist, and S/W QA engineer are all part of the S&MA Directorate. The difference in the roles of a quality engineer, QA specialist, PQA specialist, and S/W QA engineer are clarified below.

Ensure the system of interest is safe; i.e., − Potential hazards shall be identified. − A method to monitor and control, eliminate, or reduce identified hazards shall be established.

4-47


• • •

•

The quality engineer ensures that products provided meet or exceed S&MA requiremen ts. The QA specialist ensures that processes are implemented and followed. The PQA specialist ensures that S&MA requirements are imposed on contracts and delegates QA functions to other agencies (e.g., Defense Contract Management Agency (DCMA)). The S/W QA engineer is responsible for QA, quality engineering, and safety on S/W products.

4.1.11.4

• • • • • • • • • •

Life cycle

•

The Safety and Mission process Successthrough process all establishes and maintains an effective p hases of the project life cycle. S&MA requirements, reviews, and plans are integrated into the project life cycle.

Procurement documents (SOW, data requirements descriptions) Version description document ITA Development plans Engineering drawings Design documents Verification and validation plan/document ICDs Certification data package Acceptance data package (ADP) Problem reports

4.1.11.6 Steps The project team, in accordance wit h the respon sibilities outlined in Section 4.1.11.3 above, performs the process steps illustrated in Figure 4.1 -11. • Determine S&MA Support Level – S&MA support shall be scoped to determine the amount of support needed. − Prepare and approve a n ITA. • Ensure System Safety – System safety shall be integrated into the life cycle development of the system of interest. − Develop and execute a system safety plan. − Provide regular reporting of system safetyrelated issues and status to project managem ent. − Formulate the System Safety Design Criteria – The common goal of system safety design

4.1.11.5 Inputs Typical inputs to this process include, but are not limited to: • System goals and objectives • System requirements • Operational concepts and scenarios • Trade studies • Project plans • Feasibility assessment • Schedules/timelines • System constraints • Quality and test procedures

Ensure System Maintainability

Ensure System Safety

Safety Plans, Procedures, Analysis, Reports, Issues, & Status

KEY

Step/Activity

Maintainability Plans, Procedures, Analysis, Reports, Issues, & Status

Ensure System Quality

Ensure System Reliability

Quality Plans, Procedures, analysis, Reports, Issues, Status

Reliability Plans, Procedures, Analysis, Reports, Issues, & Status


Product

Figure 4.1 -11. Safety and mission success process diagram.

4-48


− − −

−

−

−

− −

criteria is to achieve acceptable and minimized levels of design-associated hazards. Many hazards can be eliminated by selecting appropriate specifications, standards, materials, design features, and previously qualified components as expressed in design criteria. Review and approve verification/validation plan. Review and approve requirements documents and verification criteria. Prepare hazard analysis to identify potential hazards and drive design solutions. A safety data package is prepared and submitted to

− − −

−

the Safety at Review Panel (SRP). I is submitted the PDR, Phase II atPhase the CDR, and Phase III after qualification testing. (NOT E: For government- furnis hed equipment (GFE), the safety review is performed by the SMART; and for GFE payloads, the safety review is performed by the Payload Safety Review Panel (PSRP).5,6 Perform Software Safety Analysis – S/W safety is defined in SSP 50038, NASA-STD 8719.13, and NASA- GP-1740.13-96. 7,8,9 Perform Safety Testing – Safety tests are planned to demonstrate that safety provisions, alarms, and procedures called out in the hazard analysis are adequate and to verify hazard controls are implemented, effective, and satisfy requirements. Perform Ground Safety Analysis – The ground safety analysis report is an analysis

•

required to alert vehicle integrators to of any specific safety-related design features the project. Normally this involves integrating the project through the Kennedy Space Center (KSC) as shown in KSC 1700.710 and further defined in NSTS 13830. 11 The paragraphs identified in KSC 1700.7 and NSTS 13830 provide information on the intent and content of this analysis report. These documents are specific to KSC operations but cover most typical project safety-related delivery scenarios. If an organization other than KSC is integrating flight H/W onto a vehicle/flight article, a review of these paragraphs should ensure an understanding of the necessary material to support negotiations with the organization’s safety group. Ground systems with S/W controls must meet the safety requirements in NASA- STD-8719.13. 8 Support TRRs. Ensure that the system and all gro und operations and activities associated with the system comply with applicable Occupational Safety and Health Administration (OSHA) standards

determine margin or robustness. Ensure System Reliability – System reliability shall be integrated into the life cycle development of the system of interest. 2 − Develop and execute a re liability plan. − Provide regular reporting of system reliabilityrelated issues and status to project management. − Perform criticality assessment of the system as part of the feasibility assessment. − Develop and refine reliability prediction models. − Establish and allocate reliabili ty goals, fault tolerance requirements, and environmental design requirements. − Review and approve verification/validation plan. − Review and approve requirements documents and verification criteria. − Develop environment test requir ements a nd −

−

−

− − −

−

−

4-49

and JPG 1700.1 12 so as to prevent personnel injury, damage to the system, and damage to other property/systems. Review and approve certification documentation. Review and as sess problem reports and nonconformances for safety impacts. Ensure that system operational issues are identified and documented on a problem report and that corrective actions are implemented. Support project tests or analyze products – not only at the expected operational condi tions, but also at off-nominal conditions – to

specifications for H/W qualification. Prepare an FMEA/critical items list (CIL) to support design decisions. FMEA /CIL is re viewed and approved by the appropriate R&M panel. Perform design trade studies covering issues such as the degree of redundancy, system availability, and reliability vs. maintainability. Support risk management by identifying design attributes that are likely to result in reliability problems and recommend appropriate risk mitigations. Identify and track limi ted life and cycle life items (e.g., JSC-24937 13 ). Identify redundancy requirements. Perform analyses on qualification test data to verify reliability predictions and validate the system reliability prediction models, and to understand and resolve anomalies. Review a nd ap prove electrical/electronic equipment (EEE) parts specifications, if applicable. Conduct and/or approve EEE parts application analysis, if applicable.


Perform testing for qualification and acceptance of EEE parts, if applicable. − Review and approve certification documentation. − Prepare fault-tree analysis to ide ntify failures. Ensure System Maintainability – System maintainability shall be integrated into the life cycle development of the system of interest. 2 − Develop and execute a maintainability plan. − Provide regular reporting of system maintainability-related issues and status to project management. −

•

−

− − −

−

−

•

Establish and allocate maintainability and availability requirements. The requirements should be consistent with the maintenance concept and trac eable to system-level ava ilability objectives. − Perform an engineering design analysis to identify maintainability design deficiencies and predictions. − Develop maintainabili ty predictions to sup port logistics (spares), operations (e.g., crew time for repairs), and manifest. − Perform analyses to quantify the system maintenance resource requirements, and document them in the maintenance plan. Ensure System Quality – System quality shall be integrated into the life cycle development of 2 the system of interest. − Develop and execute a QA plan (S/W and H/W). − Provide regular reporting of system quality-re−

−

− − −

lated issues and status of project management. Identify issues of design, materials, workmanship, fabrication and verification processes, and other characters that could degrade product system quality in support of major system design reviews (e.g., SRR, PDR, and CDR). Ensure engineering designs meet project requirements and comply with Center and program quality requirements. The requirements are detailed in the following documents: ? JPG 5335.3, Quality Manual ? NSTS 5300.4(1D-2), Safety, Reliability, Maintainability, and Quality Provisions for the Space S huttle Program ? SSP 41173, Space Station Program Quality Assurance Requirements ? JPG 8080.5, JSC Desig n and Procedural Standard Manual Conduct process, product, and quality

ed by the following documents: • NPD 2820.1, NASA Software Po licies

− −

− − −

−

−

−

− − − − − −

4-50

NASA-STD-2100-91, NASA Software Docume ntatio n Standard • NASA-STD-2201-93, Software Assurance Standard • NASA-STD-8719.13A, Software Safety NASA Technical Standard • NASA-STD-8739.8, Software Assurance Perform QA contract surveillance. Ensure verification requirements are properly specified, especially with respect to test environments , test configurations, and pass/fa il criteria. Evaluate manufacturing/fabrication plans and processes. Assign mandatory inspection points. Inspect items and facilities during manufacturing/fabrication as well as items delivered to the NASA field centers. •

−

management system audits. Ensure the completeness of CM plan, procedures, and documentation. Review and approve test procedures.

Review and approve PMPs and program/ project requirements documents. (NOT E: This is a joint review by all of S&MA.) Review and approve procurement documents. Participate in the evaluation and selection of procurement sources. Ensure NASA workmanship standards are used in the design and manufacture of EEE for high-reliability (flight H/W, critical ground support equipment, etc.) applications. 14 Ensure S/W is designed and developed in accordance with NASA standards establish-

Inspect facilities assure equipment, certification, andto calibration. Ensure the adequacy of personnel training and technical documentation to be used during manufacturing/ fabrication. Monitor qualification and acceptance t ests to ensure compliance with verification requirements and test procedures, and to ensure that test data are correct and complete. Approve the resolution of nonconformances and problem/failure reports (P/FRs), and verify the implementation and effectiveness of corrective action(s). Perform assessment of as-designed vs. asbuilt configurations. Verify each ADP is complete and correct. Verify each version description document as complete and correct. Verify completion of certification documentation. Assess S/W development folders. Ensure flight equipment that is being shipped for flight is ready for shi pment and follow on flight processing/integration.


−

Investigate mishaps and process escapes.

• •

4.1.11.7 Outputs Primary outputs from this process are: • Safety and mis sion success program plans • Safety and mission success requirements • Hazard analysis • Reliability prediction models • FMEA/CIL • Fault-tree analysis • Safety and mission success status • Review item dispositions (RIDs) • •

• • • • • • • • • • •

QA surveillance data Flight H/W- and S/W-specific output, including: − ADP − Certification data package − Pre-Shipment Readiness Review (JSC Form 1027) − Government certification approval request (GCAR)

• • • • •

Trade studies Risk assessment matrix Hazard analysis FMEA and criticality analysis Reliability block diagram Fault-tree analysis Event-tree analysis Combinatorial failure probability analysis Failure mode information propagation modeling Probabilistic design analysis Probabilistic risk assessment Tolerance stack-up analysis Design of experiments Brainstorming Checklists Reliability trend analysis Human reliability analysis Failure trend analysis

4.1.11.8 Exit criteria The Safety and Mission Success process is ongoing throughout the life cycle of the project and does not end until the mission is complete and project deliverables are decommissioned.

4.1.11.11 Software tools Standard of fice automation tools, which support documentation reviews and the development of various analyses, should generally be used; e.g., word processor, spreadsheet, and presentation S/W for PCs. Tools that help in the analysis of systems should also be used. One such t ool is PSpice.

4.1.11.9 Measurement The table at the bottom of the page provides both base and derived measures that can be used in conjunction with the Safety and Mission Success process. See

4.1.11.12 References The following documents, which were used to prepare this section, offer additional insights into the Safety and Mission Success process:

discussion of Measurement on page 4-1.

1 NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Processes and Requirements .

4.1.11.10 Methods and techniques Methods and techniques used in the Safety and Mission Success process depend, to some degree, on the nature of the system of interest. However, typical methods and technique s include:

2

SP 6105,NASA Systems Engineering Handbook, 1995.

3

NPR 7120.5B, NASA Pr ogram a nd Proj ect Management Processes and Requirements , 2002.

Base Measures

Derived Measures

S&MA Planning Milestone Dates (e.g., due dates on planning checklist)

S&MA Planning % Complete – Planned vs. Actuals

S&MA Planning Effort (FTEs)

S&MA Planning Productivity S&MA Planning Effort – Planned vs. Actuals

Mishap Rate

Mishaps/Year for Last 5 Years Cumulative Rate Projection

Open Work

Cause Category % H/W and S/W Shipped with Open Certification

Timeliness

QA Turnaround Time for Discrepancy Report Processing

4-51


4 NASA-STD-2100 -91, NASA Sof tware Document ation Standard . 5 NSTS 1700.7, Safety Policy and Requirements for Payloads Using the STS . 6

NSTS 1700.7 Addendum, Safety Policy Requirements for Payloads Using the International Space Station . 7 SSP 50038, Computer-Based Control System Safety Requirements . 8

NASA-STD-8719.13A, Software Safety NASA Technical Standard . 9 NASA-GB-1740.13-96, NASA Guidebook fo r Safety Critical Software – Analysis and Development . 10 KHB 1700.7, KSC Pay load Ground Safety Handbook . 11

NSTS 13830, Payloads Sa fety Review and Data Submittal Requirements . 12 JPG 1700.1, JSC Safety and Tota l Health Handbook . 13 JSC-24937, Limited Life Time Cycle Ite ms Program Requirements Document , 2002. 14

NASA-STD-8739 series.

15

INCOSE Systems Engineering Handbook , Version 2.0, 2000. 16 CMMI-SE/SW/IPPD/SS V1.1, Capability Maturity Model Integration (CMMI) for Systems Enginee ring, Software Engineering, Integrated Product and Process Development, and Supplier

Sourcing , 2002. 17 EIA-632, Processes for Engineer ing a Sys tem. 18

NASA-STD-2201-93, Software Assurance Standard .

4-52


4.1.12 Control 1 The SE Control process is performed to identify, allocate, track, and control significant attributes of the system of interest (e.g., technical performance, technical resources, cost, schedule, and interfaces). These significant system attributes are defined and controlled by this process and are reported to the Technical Work and Resource Management process (Section 4.1.10). The Technical Work and Resource Management process, in turn, is responsible for communicating technical performance status and resolving discontinuities reported by the Control process.

4.1.12.4 Life cycle The Control process is a crosscutting process that spans the enti re project life cycle. Establishing methods for tracking, controlling, and reporting technical measures and attributes occurs during definition of the project. Identification of technical attributes and performance measures in support of SEMP development also occurs early in the project life cycle. Execution of process tracking, controlling, and reporting functions continues until the end of the project.

Establishingand TPMs is useful for tracking technical performance progress as well as for evaluating trades when trying to derive the best technical solution since TPMs are typ ically based on key t echnical system attributes (e.g., weight, power, size, speed, performance, cost, and schedule).

Typical limited to: inputs to this process include, but are not • System architecture • WBS • SEMP • System requirements • Technical performance measurement baseline (PMB) • ICD • Interface requirements specification

4.1.12.5 Inputs

4.1.12.1 Function1 In the SE Control process: • Budgets and margins for significant system of interest attributes (e.g., power, weight) shall be defined and allocated. • TPMs shall be established and tracked. • Methods for tracking and reporting measures for technical resources, cost, and schedule shall be established. • Interface controls shall be established, documented, and maintained.

4.1.12.6 Steps 3,4 Adhering to the major steps of this process directs the project toward meeting its SE control requirements. For each major process step, additional guidance is provi ded as to the typical su b-process steps and products that are expected. These steps are shown in Figure 4.1-12 (at the top of the next page ) and are discussed further below.

4.1.12.2 Objective 2 The objective of this process is to establish, monitor, control, and report the technical performance, cost, and schedule attributes, methods, and measures of the system of interest.

•

4.1.12.3 Responsibilities The Project Manager makes the final decision concerning salient features and significant attributes of the control system. The Lead Systems Engineer is responsible for ensuring the completeness and integrity of the SE control system, identifying and allocating budgeted resources of system attributes, establishing and tracking technical measures, and establishing interface controls. The Project Control Officer is responsible for integrating the SE control systems into the overall project control function. Specialty Engineering Disciplines are responsible for supporting the Lead Systems Engineer with discipline-specific technical pe rformance, cost, and schedule data and measures.

Manage Technical Attributes − Identify and Allocate Technical Attributes – Budgets and margins for significant system of interest attributes shall be defined and allocated. • Define technical budgets and margins for significant system of interest attributes (e.g., size, power, weight, cost, and schedule). • Allocate technical budgets and margins for significant attributes across and down the system of interest hierarchy. − Maintain and Control Technical Attributes – Budgets and margins for significant system of interest attributes shall be maintained, tracked, and controlled. • Periodically assess the adequacy of technical resources, including margins, to meet project requirements. •

4-53

Develop and implement a recovery plan when margins of technical attributes for the system of interest become inadequate.


Manage Technical Attributes

Technical Attributes

System of Interest Technical Attributes

Establish Technical Performance Measures

Track Technical Performance Measures

Identify & Allocate

? Maintain & Control Technical Attributes

Over-Budgeted Resources Recovery Plan

Analyze Technical Performance Measures

Manage Performance Measures Technical Performance Measures

Manage Interfaces

KEY

Establis Interface Controls

Step/Activity

Report Technical Performance Measures

Interfac Mgmt. Plans & Processes

Maintain& Control Interfaces

Technical Performance Results

ICDs and Interfac Request Specifications


Produc

Figure 4.1 -12. Control process diagram. •

Manage Performance Measures Establish Technical Performance Measures – Identification of technical performance measures and of collection, analysis, and reporting requirements shall be established. Note that the Control process measurement steps are very similar to those defined in the Quality

tracking depth, used to derive the defined TPMs. This may be achieved by developing a technical parameter hierarchy that identifies all measurable key technical elements and establishes their relative relationships and importance.

−

•

Management process (Section 4.3.4); however, the focus of each differs. The Control measurement steps are specific to performance measures, whereas the Quality Management measures are applicable only to proce ss and pr oduct m easur es. • Establish measurement objectives that are derived from technical needs and objectives. • Specify TPMs that address resource, cost, and schedule measurement objectives, including attributes (e.g., owner, frequency of collection, roll-up of lower-level measures). Most useful TPMs are those that provide visibility into the technical performance of key elements of the WBS, especially those that are cost drivers on the program, lie on the critical path, or represent high-risk items . TPMs are key

•

Specify data collection methods,measurement tools, and storage procedures. Specify measurement data analysis methods, procedures, and tools. • Specify measurement result report types and communication mechanisms. • Manage and store measurement specifications in accordance with defined storage procedu res. Track Technical Performance Measures – Collection of technical performance measurement data shall be performed. • Collect specified technical performance measurement data in accordance with the defined collection methods and tools. • Track critical technical parameters rela tive to time, with dates established as to when progress will be checked and when full compliance will be met. •

−

•

to progressively assessing technical progress and, once defined, should be documented in the SEMP (Section 4.1.10). Specify the critical technical parameters, including update frequencies and level of

−

4-54

Manage and store measurement data in ac cordance with defined storage procedures. Analyze Technical Performance Measures – Analysis of technical performance measurement data shall be performed.


Analyze specified technical performance measurement data in accordance with defined analysis methods, procedu res, and tools. • Apply statistical methods to understand performance measurement variation, where applicable. • Analyze and interpret performance measurement data. • Manage and store analysis results in accordance with defined storage procedures. Report TPMs – Reporting of technical performance results to relevant stakehold ers •

−

•

•

•

shall be performed. • Report technical performance measurement and analysis results to the project manager and other relevant stakeholders (e.g., design and SE, customer). • Periodically review project performance against the SEMP (see Section 4.1.10 for conducting progress reviews). • Establish a correction plan for performance measurement discontinuities (see Section 4.3.4 for managing corrective actions). Manage Interfaces − Establish Interface Controls – The project technical plan for maintaining and controlling system interfaces shall be established. Development and documentation of the system of interest internal and external interfaces is performed as part of the SE Decomposition process (Section 4.1.4).

•

•

•

•

Establish, document, and maintain the project interface controls (e.g., r esponsibilities, processes) in an interface management plan. Maintain and Control Interfaces – Management of system interfaces shall be performed by providing oversight of interface definition, control, compatibi lity, approval, a nd coordination in accordance with the interface management plan. • Monitor system development and manage technical staff, budget, and schedules to ensure project interface management plans are bein g followed and supporting proce sses are being used. • Ensure supervision and resources are pro vided to enable the interface management plans to be executed and commitments met. • Make data pertinent to interface manage-

•

quirements, and interfaces required for the system tothe perform as intended. Establish an interface control working group to maintain interface requirements, and to coordinate and resolve any discrepancies in system interfaces (requiremen ts and implementations). Ensure interface changes affecting the element and affected by the element are controlled to prevent adverse consequences. Update and maintain ICDs and interface requirements, as required.

4.1.12.7 Outputs Primary outputs from this process are: • System technical attributes • TPMs • TPM analysis results • Earned value status, if available

•

−

element are identified, defined, assigned, documented, and managed. Ensure element design definitions are compatible in terms of form, fit, and function. Conduct frequent technical interchange meetings (TIMs) among systems engineers of each organization involved to promote understanding of the mission functional requirements of the fully integrated system, the contribution each product is expected to make in fulfilling those re-

• •

Plans (resource recovery plans, interface management plans) ICDs (updated) Interface requirements specification (updated)

4.1.12.8 Exit criteria The process is exited upon project termination. 4.1.12.9 Measurement The table at the top of the following page provides example base and derived measures that can be used in conjunction with executing the Control process. See discussion of Measurement on page 4 -1.

ment readily accessible to project teams throughout the system of interest life cycle. Ensure all internal and external functional and physical interfaces for each

4-55


Base Measures

Derived Measures

Tracking Milestone Dates (e.g., mo nthly tracking book reviews, gate reviews)

% Tracking Milestones Met – Planned vs. Actuals

Issues/Actions Status

% Issues Closed

Overall Technical Management Effort

Technical Management Effort – Planned vs. Actuals Management Effort as % Total Engineering Effort

4.1.12.10 Methods and techniques 5,6 Performance management methods include:

• •

•

• •

Earned Management (EVM and ) – Enables effectiveValue execution, management, control as well as integrated evaluation of cost, schedule, and technical performance against the baseline. • Performance Assessments – Confirms satisfactory project performance and ensures timely identification of all problems throughout the life cycle. • Schedule Management – Ensu res the establishment, management, and control of baseline master schedule and derivative schedules that provide the framework for time phasing and coordinating all project efforts into a master plan to ensure that objectives are accomplished within project or program commitments. Project performance against the baseline schedule represents a key element in managing risk. • WBS – Serves as the structure for projec t technical planning, scheduling, cost estimating and budgeting, contract scope definition, documentation, product development, and status reporting and assessment (including integrated cost/schedule performance measurement). • TPM – Is the ongoing process of predicting the value of performance parameters, which are critical to successful performance of the system, at completion of the system development; comparing the current actual values of those performance parameters to a planned profile of each parameter over development time; and identifying any design defic iency that could jeopardize system performance. The extent to which TPM is to be employed should be defined in the SEMP. TPM may also be used to: evaluate compliance with requirements; assess compliance to levels of technical risk; trigger development of recovery plans for identified deficiencies; and examine marginal cost benefits of performance in excess of requirements. Measurement and analysis methods include: • Statistical analysis • Cause and effect – fishbone diagr ams • Control charts • Flow diagrams

• •

Affinity diagrams Interrelationship diagraphs Pareto charts Run charts Block diagrams Gantt charts

4.1.12.11 Software tools 5 Many S/W tools a re available to support the SE Control process. These S/W tools include typical spreadsheet, scheduling, database, and drawing tools for data visualization, planning, monitoring, controlling, and analysis with commercial products available from many vendors . Als o available are specialized tools for measuring managemen t systems and statis tical modeling analysis. For cost estimating and analysis, see the JSC Cost Estimating Web page at www.jsc.nasa.gov/bu2/. For a n extensive listing of commercially available systems analysis tools, see the table provided by INCOSE at the following: www.incose.org/tools/ei a632tax/eia632top .html. This 5 the Control process table lists toolsof that support requirements EIA-632.

4.1.12.12 References The following documents, which were used to prepare this section, offer additional insights into the Control process: 1 NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Processes and Requirements. 2

SP 6105, NASA Systems Engineering Handbook , 1995. 3

CMMI-SE/SW/IPPD/SS V1.1, Capability Maturing Model Integration (CMMI) for Systems Engineering, Software Engineering, Integrated Product and Pr ocess Development , and Supplie r Sourcing , 2002. 4

EIA-632, Processes for Engineering a System, 1999. 5

INCOSE 2.0, 2000. Systems Engineering Handbook , Version 6 NPR 7120.5B, NASA Pr ogram a nd Proj ect Man agement Processes and Requirements , 2002.

4-56


4.1.13 System Analysis1–5 The Sys tem Analys is process (e.g., stress, thermal, cost, performance, safety, etc.) is performed to provide a specific, quantitative, engineering assessment that is used in making systematic, technical, and economic decisions and establishing design alternatives, recom mendations, allocations, and budgets. Thi s process is used to (1) provide a rigorous basis for technical decision making, resolution of requirements conflicts, and assessment of alternative physical solutions; (2) determine progress in satisfying system of interest requir e ments; (3) support risk management; and (4) ensure

4.1.13.3 Responsibilities 3 The Lead Systems Engineer is responsible for all aspects of the System Analysis process, including construction of quantitative models, application of those models to identified alternatives, and analysis of resulting data. Alternative selection and documentation are also the responsibilities of the Lead Systems Engineer. Other participants in this process include the: • Design Engineering Disciplines such as S/W, mechanical, electrical, etc., who are responsible for providing discipline and functional expertise

that decisions are made and onlyrisk after evaluating cost, schedule, performance, effects on thethe system of interest. The System Analysis process is a structured approach to evaluating alternative solutions against established criteria to determine a recommended sol ution addressing an issue. A formal System Analysis process involves establishing criteria for evaluating alternatives, identifying alternative solutions, selecting methods for evaluating alternatives, evaluating solutions using established criteria and methods, and selecting recommended solutions from the alternatives based on the evaluation criteria. A formal System Analysis process reduces the subject nature o f the decision and increases the probability of selecting a solution that meets the multiple demands of the relevant stakeholders. In particular, trade studies are used to evaluate solutions to optimize the cost, schedule, performance, and risk of select ed alternativ es.

•

•

in supportEngineering of these analyses. Specialty Disciplines , including reliability, maintaina bility, logistics, test, pro duction, transportation, human factors, QA, safety, and risk management, who are responsible for providing specific, specialty expertise in support of these analyses. Chief Financial Officer Representative , who is responsible for supporting, providing, and certifying financial information in these analyses.

4.1.13.4 Life cycle 6 Technical issues requiring the System Analysis process must be ide ntified during any phase of a program. The objective is to identify impending technical issues as early as possible in the life cycle to maximize the time available to deal with each issue. The greatest application of the System Analysis process is, therefore, during the early stages of the life cycle beginning with Pre- Phase A, Advanced Stud ies, and continuing through Phase A, Preliminary Analysis, and Phase B, Definition, and ending in Phase C, Design. However, the process is applicable to the remaining stages of the life cycle and should be applied any time a technical issues requires analysis. The System Analysis process may be involved from any of the other SE processes.

4.1.13.1 Function1 In the System Analysis process: • Evaluation criteria (e.g., environment, dimensions, life cycle, weight, cost, etc.) shall be established and applied during the an alysis. • Analytical or physical modeling of the alternatives based on the established evaluation criteria shall be performed to obtain a qu antitative prediction. • A recommendation for the solution based on the quantitative outcome of the analytical or physical modeling shall be made.

4.1.13.5 Inputs Inputs to the System Analysis process vary depending on the stage in the life cycle and the foc us of the analysis. Typical inputs will consist of: • Functional concepts • Physical concepts • Operations concepts • Requirements • Design • Measures of effectiveness (e valuation crite ria)

4.1.13.2 Objective 3 The objective of system analysis is to help decision makers choose appropriate course of action. This is achieved by systematically examining the relevant objectives – and alternative policies and strategies for achieving them – and comparing quantitat ively the economic costs, effectiveness, and ri sks of the alternatives.

•

4-57

Plausible alternatives


4.1.13.6 Steps 3,4 The following diagram ( FIG. 4.1-13) illustrates the major steps of the System Analysis process. Details of these steps are provided below.

Prepare for System Analysis

Establish System Analysis Guidelines

START

A Conduct System Analysis

−

Define/Identify Goals, Objectives, and Constraints

Define

Define

Figures Merit of

Measurement Methods

Compute Cost for Each Alternative

Compute Uncertainty Ranges

fulfill its goals and objectives (see Section 4.1.4, Decomposition). Define Plausible Alternatives – Create alternatives that can potentially achieve the

Perform Functional Analysis

Collect Data on Each Alternative

Perform Sensitivity Analyses

B

KEY

Make a Tentative Selection

Step/Activity

Is Tentative Selection Acceptable?

Product

Yes

Document Systems AnalysisResults


B

Define Selection Criteria

A

Com pute Syste m Effectiveness, Performance or Technical Attributes

Perform Risk Analysis

Consider New Alternatives

No Select Solutions

Define Plausible Alternatives

Analysis Report

Connector

B

Return to Start

EN

Decision

Figure 4.1 -13. System analysis p rocess diagram. •

Preparation for Systems Analysis Shall Be Performed – Preparation for the analytical portion of systems analysis shall be performed, including functional analysis of the system of interest to help identify plausible alternative solutions. − Establish Guidelines for System Analysis – Establish and maintain guidelines to determine which issues are subject to a formal system analysis process. Guidelines should be reviewed with and accepted by the design team. − Define/Identify Goals, Objectives, and Constraints – State the goals, objectives, and constraints in general operational terms during early stages of the project life cycle and as the architecture and design matures. State them more in terms of perfor mance requirements thatan as-

−

•

pect of the system of interest must meet (see Section 4.1.1, Requirements Development). Perform Functional Analysis – Systematically identify, describe, and relate the functions that the system of interest must perform to

4-58

goals and objectives of the system. Solicit alternatives from relevant stakeholders. Use brainstorming sessions, literature searches, interviews, and working groups to uncover alternatives. The number of alternatives considered can drive the cost of the analysis, so consider only clearly viable choices. − Define Selection Criteria – Define how t he figures of merit for each trade st udy or decision will be used to make a tentative selection of the preferred alternative. Define the range and scale (or weighting factors) for ranking the criteria, rank the criteria, assess the criteria and their relative importance, and document rationale for the selection and rejection of criteria. Systems Analysis of Alternatives Shall Be Performed – Each plausible alternative shall be analyzed in sufficient detail to support selection of a course of action. − Define Figures of Merit (also called “ measures of effectiveness”) – Define quantitatively


−

−

−

−

−

•

accomplishment of the system goals and objectives. Figures of merit are often expressed as polynomials (e.g., cost per ton launched, mean time to repair, data return time). Define Measurement Methods – Define which measurement methods are to be used to explicitly identify and model those variables associated with system effectiveness, system performance, technical attributes, and system cost, and that are important in meeting system of interest goals and objectives. Collect Data on Each Alternative – Collect

−

−

data on eachmeasurement alternative to methods. support evaluation by selected Compute System Effectiveness, Performance, or Technical Attributes – Compute an estimate of system effe ctiveness, performance, or technical attributes for each selected alternative. Compute Uncertainty Ranges – Compute, for non-point solution outcomes, unce rtaint y ranges for each alternative. Perform Sensitivity Analyses – Estimate, for uncertain key inputs, a range of output values to gauge the sensitivity of the alternative with regard to inputs. Especially in the early stages of design, weighting factors and some “quantified” data can be subjective, so the sensitivity analysis is crucial. If the solution can be changed by making relatively minor changes in data input, the study is probably

analysis. Archive this report to ensure traceability of decisions made throughout the SE process. Ideally, system analysis and trade study reports should be indexed to requirements and records of design decisions for the project. 4.1.13.7 Outputs 3 The output of the System Analysis process is a report that describes: • The system issue under analysis. • The system goals and objectives (or requirements, as appropriate to the level of resolution) and constraints. • The figures of merit used in analysis. • The measurement methods (models) used. • All data sources used. • The alternatives chosen for analysis. • The computational results, including uncertainty

invalid. Similarly, data input produce ifnosignificant change inchanges ou tput in value, the methodology should be reviewed and revised. − Perform Risk Analysis – Analyze the technical, schedule, and cost risks associated with each alternative. A Solution Shall Be Selected – Given the results of alternative analysis, a tentative solution shall be selected and a decisio n reached as to whether the solution meets the acceptance criteria . − Make a Tentative Selection – Combine the selection rule with results of the analysis, align alternatives from most preferred to least, and make a tentative selection. In making this selection, the following questions should be considered: • Have the goals, objectives, and constraints been met? •

Is more analytical refinement needed to distinguish among alternatives? • Have subjective aspects of the problem been ad dressed? Consider New Alternative Solutions – Consider new alternative solutions, criteria, or methods if the proposed alternatives do not test well; repeat the evaluations until alternatives test well. Document System Analysis Results – Establish and maintain a system analysis or trade study report documenting all aspects of the •

• • •

ranges and sensitivity analyses performed. The selection rule (or decision method) used. Recommended alternative and associated risks. Revisions to baselines for functional, phy sical, and operational concepts as a result of analysis.

4.1.13.8 Exit criteria Completely document the recommended solution with the associated analysis. 4.1.13.9 Measurement 7 The table at the top of the following page provides example base and derived measures that can be used in conjunction with executing the System Analysis process. See discussion of Measurement on page 4-1. Each of the system analyses may have cost and schedule measures associated with plannin g and performing the analyses as well as progress m easu res

Is the tentative selection robust? Isset it of heavily dependent on a particular input values to the measurement methods? Does it hold up under a range of reas onable input values? What are the risks?

with respect to completion of the analyses. Each type of analysis will also have specific technical measures related to the topic under analysis.

4-59


Base Measures

Derived Measures

Planned Analysis Cost

Planned Analysis Cost vs. Actual Cost

Planned Analysis Schedule

Planned Analysis Schedule vs. Actual Schedule

Planned # of Alternatives

Planned # of Alternatives vs. Actual #

4.1.13.10 Methods and techniques 2,3,7 The following are the methods and techniques used by the System Analy sis proce ss: • Methods

4.1.13.11 Software tools 7 Many S/W tools are available to support the System Analysis process. These include typical spreadsheet, database, and drawing tools for visualization, imag-

−

Tradeoff analysis Effectiveness analysis • Cost effectiveness • Total ownership cost • Environmental impacts • System effectiveness − Risk analysis (technical, schedule, and cost) − Functional analysis − Decision analysis methods (e.g., analytic hierarchy process, etc.) Techniques − Physical Modeling – Wind tunnel model, mockup, engineering model, breadboard model, thermal model, acoustic model − Virtual Modeling − Graphical Modeling – Functional flowcharts, behavior diagrams, timeline charts, N2 dia grams, PERT charts, logic trees, document trees, waterfall charts, floor plans, schemat-

ing, analysis withAlso commercial available fromand many vendors. availableproducts are specialized tools for graphical modeling, mathematical modeling, and statistical modeling. For cost estimating and analysis, see the JSC Cost Estimating Web page at www.jsc.nasa.gov/bu2/ . For an extensive listing of commercially available systems analysis tools, see the table that has been provided by INCOSE at www.incose.org/tools/eia632tax/eia632top. html. This table lists tools that support the System Analysis process require ments of EIA -632. 2

−

•

−

−

4.1.13.12 References The following documents and Web site, which were used to prepare this section, offer additional insights into the System Analysis process: 1

NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Processes and Requirements. 2

ics, representative drawings, topographical representations, drawings of systems or components, QFD Mathematical Modeling – Dynamic motion models, structural analysis, thermal analysis, vibration analysis, electrical analysis, finite elements, linear programming, cost modeling, network or nodal analysis, decision analysis, flow field studies, hydro -dynamics studies, control systems modeling, workflow analysis, reliability and availability models, human reliability analysis, maintainability analysis, process models, entity relationship models Statistical Modeling – Monte Carlo, logistical support, process modeling, manufacturin g layout modeling, sequence estimation modeling, discrete, cont inuous

EIA-632, Processes for Engineering a System,

ANSI/EIA -632-1998, 1999. 3 SP 6105, NASA Systems Engineering Handbook , 1995. 4 CMMI-SE/SW/IPPD/SS V1.1, Capability Maturity Model Integration (CMMI) for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing , 2002. 5 NPR 7120.5B, NASA Progra m and Projec t Management Processes and Requirements , 2002. 6

EIA-731.1, Systems Engineering Capability Model , 2002. 7


System Engineering Fundamentals , Defense Systems Management College, 2001. 9

JSC Cost Estimating Web page: www.jsc.nasa.gov/bu2/ .

4-60


4.1.14 Verification 1,2 Verification is the methodical development of evidence of system of interest compliance with requirements (“shalls”). It is accomplished at each level of the system architectural hierarchy.

The Verification Lead ensures that requirements are verifiable, develops a verification plan, identifies most effective verification methods and verification criteria, and coordinates activities with verification facilities, participants, and other team members. The Verification Lead also executes the verification plan, develops or coordinates procedures, collects and documents results, and evaluates results for compliance or need for re -verification. The Test Operations Lead assures that the required test facilities have been verified to provide neces sary conditions and have been scheduled and are available.

4.1.14.1 Function1,3 The system Verification process is use d to ascertain that end items at each level of the system architecture, from the bottom up, meet specified requirements. In the Verification process: •

•

•

•

•

The Project assesses thefor verification plan, reviews results,Manager determines the need redesign, negotiates access to external facilities or resources, and reviews results with the customer. Also, the Project Manager assigns responsibility for resolution of unsuccessful verification activities and manages closure of discrepancy reports.

Verification methods (i.e., test, shall analysis, inspection, and/or demonstration) be developed and documented to identify how each requirement is met. Verification planning information shall be documented to described the detailed processes that will ensure the system of interest complies with its requirements. Verification success c riteria shall be defined and documented that will indicate successful completion of each verification process. The method for submitting, reviewing, and tracking the results of the verification processes shall be defined and documented. Verification shall be performed and documented on each part of the system of interest at each level of the architecture hierarchy from the bottom to the top.

4.1.14.4 Life cycle Verification-related activity of some kind is usually in progress during all phas es through the System Acceptance Review (SAR), with conceptual planning documentation required as early as the Concept Review (CR). Execution usually concludes by the SAR. However, for some systems verification continues by exception later in Phase D, Development, prior to launch, and even during Phase E, Operations (i.e., orbital testing). 4.1.14.5 Inputs The Verification process is principally tracked by means of a verification matrix. This matrix is the project record of the identity, performance, and outcome of the verification activity for each of the system “shall” requirements from all project requirement documents. It is used first to capture t he plan for the verification, and it is then used to summarize results for the record. The table below illustrates the headings and one entry of such a matrix.

4.1.14.2 Objective The Verification process is performed to determine that the system of interest complies with requirements. 4.1.14.3 Responsibilities The Lead Systems Engineer reviews verification plans, ensures end -to-end verification is performed, reviews results as to adequacy and compliance, and recommends needs for retest or redesign.

Reqmt. DocumentParagraph Shall VerificationVerification Facility No. of Origin Statement Success Method or Lab Quotation Criteria ID

P-1

1. System locks to forward link System at min./ max. 3.2.1.1 shall pro- data rate Capability:vide a tolerance. JSC-nnnn support maximum 2. System Test Uplinked ground-to- locks forData station ward link at uplink the min. and max. operating frequency tolerances.

Phase

AcceptancePreflight Performing Results Requirement? Acceptance? Org.

[Is this Report nnn [Is this requirement (indicates 5 [Code for requirementalso verified documents Electronic “formal sysalso verifiedduring any that contain Systems tem-level during initialpreflight or JSC/EV objective Test Lab functional acceptance recurring evidence (ESTL) phase”] testing of acceptance that the reeach unit?] testing of quirement each unit?] was satisfied)

4-61


The following should be inputs to the process of creating the verification matrix, both from the perspective of aggregating the “shall” requirements and from the perspective of understanding the environment surrounding t hose requirements. • Concept of operations documentation • Mission needs and goals • Requirements and specifications • ICDs • Testing standards and policies • Agency standards and policies

−

− − −

4.1.14.6 Steps The following diagram ( FIG. 4.1-14) illustrates the major steps and products of the Verification p rocess. The three major steps are (1) prepare for verification, (2) perform verification, and (3) analyze and document results. These steps are progres sively and iteratively executed until the complete system is verified for all requirements.

Prepare for Verification

Select Product for Verification

inspection based on their ability to prove that the system meets its requirements. Develop the operational scenario, environment, or constraints for the verification activity and base these on a set of requirements to be verified. Verification criteria are established and documented. Verification criteria are approved by customers and S&MA. Procedures are developed for the verification activity and are approved by quality

•

engineering. Project Shall Perform Verification Activity − The verification activity is configured as appropriate to reflect the selected environment. H/W is configured, S/W is loaded, models are set up, tools are tested, and simulations are established as appropriate.

Define Document Verification Method(s), Verification Environment

Develop & Document Verification Success Criteria

Establish & Document Verification Procedures & Plans

Verification Procedures & Plans

Perform Verification

Configure or Model System

Perfor Verification Procedure

Address Design Issues Analyze and Document Results

KEY

Evaluate Results Against Criteria

Step /Activity

Record results (data or observations)

Verification Procedure Results

No OK to proceed?

Yes

Document results, analysis, and decisions

Information Flows/Output Flows

Infor mation/Product

Report of verification results, analysis, and decisions

Decision

Figure 4.1 -14. Verification process diagram. •

Project Shall Prepare for Verification −

−

Select system or subsystem components that are to be verified and the verification methods that will be used f or each. The method i s selected from test, analysis, demonstration, or

−

4-62

The verification activity is performed and witnessed by QA. Quantitative results from the test, analysis, inspection, or demonstration activity are recorded as appropriate.


Discrepancies should be documented via discrepancy reports. Project Shall Analyze and Docu ment Results − Data resulting from the verification activity are analyzed against defined verification criteria. − Results of this analysis are used to determine whether the product at this point in the life cycle meets the requirements or fails to meet the requirements, resulting in a need for either a waiver or a decision on whether a modification to the design is warranted. − All verification results, analyses, and −

•

•

4.1.14.9 Measurement The table at the bottom of the pages provides example base and derived measures that can be used in conjunction with executing the Verification process. See discu ssion of Measurement on page 4-1. 4.1.14.10 Methods and techniques Verification may be accomplished by a number of

conclusions concerning product adequacy are documented.

techniques and inspections, methods that and/or can be demonstrations. categorized as tests, analyses, The following definitions are offered not to constrain verification planning with narrow a priori identities, but to sti mulate ideas for planning, documenting, and employing the specific approaches that will be used in any given project to prove the fidelity of project unique designs and products to srcinal requirements. • Test – A method of verification wherein for mal project requirements are verified by measurement or functional test during or after the controlled application of functional and/or environmental stimuli. These measurements may require the use of laboratory equipment, recorded data, procedures, test support items, or specialized S/W. • Analysis – A verification method using techniques and tools such as math m odels, prior te st data, simulations, analytical assessments, etc. Verification by similarity is acceptable if the subject article is similar or identical in design, manufacturer, manufacturing process, and quality control to another article that has been

4.1.14.7 Outputs The ultimate need is for documentation of objective evidence that all “shall” requirements have been verified. The following outputs support fulfillment of that need: • Verification plans • Completed verification requirements matrix • Verification results and analysis • Verification procedure s • Test, demonstration, inspection, and analysis reports • Waivers • Discrepancy reports and descriptions of their closures 4.1.14.8

Exit criteria

Process exit criteria include: • Objective evidence of compliance or waiver of each system of interest “shall” requirements shall be documented. Base Measures

The verification p rocess shall not be cons idered or designated as complete until all discrepancy reports are closed.

Derived Measures

Total # of “Shall” Requirements Total # of “Shall” Requirements Verified To Date

Total # of “Shall” Requirements Verified To Date vs. Total # of “Shall” Requirements, %

Total # of “Shall” Requirements Complied With

Total # of “Shall” Requirements Complied With vs. Total # of “Shall” Requirements, %

Total # of “Shall” Requirements Waivered

Total # of “Shall” Requirements Waivered vs. Total # of “Shall” Requirements, %

Total # of “Shall” Requirements Re-verified

Re-verifications vs. Total “Shall” Requirements Verified, %

Total Verification Effort (FTEs)

Verification Rates Verification Productivity

# of Major Verifications (above specific dollar or hour level)

# of Major Verifications vs. Total # of “Shall” Requirements Verified To Date

4-63


•

•

previously verified to equivalent or more strin gent criteria. Inspection – A method of verification of physical characteristics that determines compliance using only vision and visible-spectrum optics (microscopes, fiberscopes, etc.) Demonstration – A method of verif ication that evaluates the integrated properties of the subject end item by staging a loosely controlled operational scenario based on the operations concept. Demonstration participant s are user-oriented; i.e., they interface with the subject and item pri-

93-C-0123). Prepared for Rome Laboratory, Air Force Materiel Command C3CB 525 Brooks Rd. Griffiss AFB, NY 13441, by Software Productivity Solutions, Inc., 122 4th Ave., Indalantic, FL 32903. 5

CMMI-SE/SW/IPPD/SS V1.1, Capability Maturity Model Integration (CMMI) for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing , 2002.

marily to employ as fully as possible to meet user needs in that it situation, with little emphasis on accommodating limitations of the item other than safety considerations. Demonstration can be conducted with or without special test equipment or instrumentation to verify required operational characteristics such as endurance, ruggedness, human engineering features, service and access features, transportability, and displayed data. 4.1.14.11 Software tools A S/W tool intended to support verification management should possess the ability to track the identity, srcin, verification, method, facility, success criteria, and current degree of fulfillment of each requirement. For large or complex projects, COTS requirements management tools (e.g., DOORS and SLATE) usually include features that can convert requirements loaded in them into verification matrices with required elements of information. INCOSE offers an excerpt from an S/W productivity solutions review of such tools at: http://wwww.incose.org/tools/reqsmgmt.html . For small or simple projects, word processor or spreadsheet S/W is often adequate for manual tracking or building an elementary custom tool. 4.1.14.12 References The following documents, which were u sed to prepare this section, offer additional insights into the Verification process: 1 NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Processes and Requirements. 2 NPR 7120.5B, NASA Pr ogram a nd Proj ect Man agement Processes and Requirements , 2002. 3

EIA-632, Processes for Engineering a System, ANSI/EIA -632-1998, 1999. 4 Analysis of Automated Requirements Management Capabilities . Developed in support of Advanced System Engineering Automation (ASEA) CSC-2.7 Requirements/Design Manager (Contract no. F30602-

4-64


4.1.15 Validation 1,2 While verification proves “whether the system was done right,” validation pr oves “whether the right system was done.” That is, verification provides objective evidence that every “shall” was met, whereas validation is performed for the benefit of the customers and users to ensure that the system functions in the expected manner when placed in the intended environment. This is achieved by examining the products of the system at every architectural level. 4.1.15.1

The Validation Lead develops the validation plan, identifies the most effective validation method, and coordinates activities with validation facilities, participants, and other team members. The Validation Lead also executes the validation plan, develops procedures, and collects and documents results. The Project Manager assesses the validation plan, negotiates access to external facilities or resources, assigns responsibility for resolution of unsuccessful validation activities, and manages closure of is sues and actions.

Function1,2 4.1.15.4 Life cycle Validation-related activity is usually in progress during all phases through the SAR, with conceptual planning documentation required as early as the PDR. Although execution usually concludes by the SAR, for some systems validation continues by exception later in Phase D, Development, prior to launch, and even during Phase E, Operations (i.e., orbital testing).

Validation is performed on systemprocess of interest and subsystem products. The Validation is conducted to ensure that system and subsystem products are ready for the uses, functions, and missions implied or suggested by both the requirements and any other relevant project or program information. In the Validation process: • Validation method(s) (i.e., test, analysis, inspection, and/or demonstration) shall be defined and documented. • Validation planning information shall be developed and documented to describe the processes that will ensure the system of interest will meet customer needs. • Validation succe ss criteria shall be defined and documented that will indicate successful completion of each Validation process. • The methods for submitting, reviewing, and tracking the results of the Validation process shall be defined and documented. • Validation shall be conducted and documented on each part of the system of interest at each level of the architecture hierarchy, from the bott om to the top.

4.1.15.5 Inputs The Validation process is principally tracked by means of a validation matrix. This matrix – which is the project record of the identity, performance, and outcome of each validation activity – is used first to capture the plan for validation and then to summarize plan results for the record. The table at the bottom of the page illustrates the headings and one entry of such a matrix. The following should be inputs to the process of creating the validation matrix, both from the perspective of aggregating implied or suggested customer expectations beyond the “shall” requirements, and from the perspective of understanding the environment surrounding those needs: • Concept of operations documentation • Mission needs and goals • Requirements and specifications • ICDs • Testing standards and policies • Agency standards and policies

4.1.15.2 Objective Validation is performed to determine whether customer needs can be met in the context of the expected operational scenarios of the system of interest. 4.1.15.3 Responsibilities The Lead Systems Engineer works with customers and users to identify desired validation activities, reviews the validation plan, ensures end-to-end val idation is performed, and reviews results to determine adequacy. Validation Product # 1

Activity

Objective

4.1.15.6 Steps 3 Figure 4.1-15 illustrates th e major steps and produc ts of the Validation process. The majo r steps are to (1) prepare for validation, (2) perform validation, and (3) analyze and document results. These

Metho d

Facility or Lab ID

The customer/ 1. Ensure legibility sponsor will is acceptance. evaluate the 2. Ensure overallDemonstration candidate displays appearance is acceptable.

4-65

Phase

Performing Org.

1 [this number is code for “During ESTL product selection process”]

JSC/EV

Results Customer asserts that displays are both legible and acceptable overall.


Prepare for Validation

Select Product for Validation

Define Document Validation Method(s), Validation Environment

Develop & Document Validation Success Criteria

Establ ish & Docum ent Validation Procedures & Plans

Validation Procedures & Plans

Perform Validation

Perfor Validation Procedures

Configure or Model System

Address Design Issues

Analyze and Documentesult Rs

KEY

Validation Procedure Report

No

Evaluate Results Against Criteria

Step/Activity

Reco rd Resu lts (Data or Observation)

OK to Procee ?

Yes

Document Results, Analysis, and Decisions


Product

Report of Validation Results, Analysis, and Decisions

Decision

Figure 4.1 -15. Validation process diagram. steps are progressively and iteratively executed until the complete system is validated for all expected environments. • Project Shall Prepare for Validation − Select system or subsystem components to be vali dated and the validation methods that will be used for each. The method is selected from test, analysis, demonstration, or inspection and is based on the ability of the system or subsystem components to prove that the user and customer needs are satisfied. − Develop the operational scenario, environment, or constraints for the validation activity, and base these on customer and user needs and expectations. − Ensure validation criteria are established and agreed to by users and customers. − Develop and document procedures for the validation activity. − Ensure that quality engineering approves procedures for the validation activity. • Project Shall Perform the Validation Activity − The validation activity is configured as appropriate to reflect the selected environment. H/W is configured, S/W is loaded, models are s et up, tools are te sted, and simulations are established as appropriate.

The validation activity is performed and witnessed by QA, preferably with observation or participation by customer and users. − Results of the validation activity are recorded as appropriate. User and customer subjective reactions to the activity are noted as are quantitative results from the test, analysis, inspection, or demonstration. − Issues and actions arising from validation activity shoul d be documented and tracked. Project Shall Analyze and Document Results − Data resulting from the validation activity are analyzed against the defined validation criteria. − Results of the analysis are used to determine whether the product at this point in the life cycle meets customer and user needs and expectations, or whether a modification to the design is warranted. − All validation results, analysis, and conc lusions as to product adequacy are documented. −

•

4.1.15.7 Outputs The ultimate need is for documentation of objective evidence that shows all implied or suggested customer expectations have been validated. The following outputs support fulfillment of that need:

4-66


• •

Validation plans and procedures Validation evaluation results, including issues and actions found and descriptions of their resolution •

4.1.15.8 Exit criteria Exit criteria for this process include: • Objective evidence of performance and results of each system of interest validation activity shall be documented. • The validation process shall not be considered or designated as complete until all issues and actions are resolved.

•

concept. participants ar e useroriented;Demonstration i.e., they interface with the subject end item primarily to use it as fully as po ssible to meet user needs in that situation, with litt le emphasis on accommodating limitations of the item other than safety considerations.

4.1.15.9 Measurement The following table provides example base and derived measures that can be used in conjunction with executing the Validation process. See discussion of Measurement on page 4-1: Base Measures

ufacturer, manufacturing process, and quality control to another article that has been previously verified or validated to equivalent or more stringent criteria. Inspection – A method of confirmation of physical characteristics that determines compliance using only vision and visible spectrum optics (microscopes, fiberscopes, etc.). Demonstration – A qualitative method of validation that evaluates the integrated properties of the subject end item by staging a loosely controlled operational scenario based on operations

Derived Measures

Total # of Validation Products Total # of Project Changes Caused by Validation

Total # of Project Changes Caused by Validation vs. Total # of Project Changes, %

Total Validation Effort (FTEs)

Validation Rates Validation Productivity

# of Major Validation Products (above specific dollar or hour level) 4.1.15.10 Methods and techniques Validation may be accomplished by a number of techniques and methods that can be categorized as tests, analyses, inspections, and/or demonstrations. The following definitions are offered not to constrain validation planning with narrow a priori identities, but to sti mulate ideas for planning, documenting, and employing specific approaches that will be used in any given project to examine whether system of interest products will satisfy the customer: • Test – A method of validation whe rein requirements (performance, environment, etc.) are proven by measurement or functional test during or after the controlled application of functional and/or environmental stimuli. These measurements may require the use of laboratory equipment, recorded data, procedures, test support items, or specialized S/W. • Analysis – A validation method using techniques and tools such as math models, prior test data, simulations, analytical assessme nts, etc. Valid ation by similarity is acceptab le if the subject article is similar to or identical in design, man-

Demonstrations can be conducted with or without special test equipment or instrumentation to validate implied customer expectations beyo nd “shall” requirements. 4.1.15.11 Software tools An S/W tool intended to support validation man agement should possess the ability to track the identity, objective, validation, method, facility, phase, performing organization, and results of each activity. For large or complex projects, COTS requirements management tools (e.g., DOORS and SLA TE) usually in clude features that can convert the requirements loaded into them into verification matrices with the required elements of information. This feature can also be u sed in the same manner to produce validation matrices. INCOSE offers an excerpt from an S/W productivity solutions review of such tools at: http://www.incose.org/tools/reqsmgmt.html . For small or simple projects, word processor or spreadsheet S/W is often adequate for manual tracking or building an elementary custom tool.

4-67


4

4.1.15.12 References The following documents, which were used to prepare this section, offer additional insights into the Validation process:

NPR 7120.5B, NASA Progra m and Projec t Management Processes and Requirements , 2002.

1

EIA-632, Processes for Engineering a System, ANSI/EIA -632-1998, 1999. 2

NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Processes and Requirements . 3 CMMI-SE/SW/IPPD/SS V1.1, Capability Maturity Model Integration (CMMI) for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing , 2002.

4-68

5 Analysis of Automated Requirements Management Capabilities . Developed in support of ASEA CSC2.7 Requirements/Design Manager (Contract No. F30602-93-C-0123). Prepared for Rome Laboratory, Air Force Materiel Command C3CB 525 Brooks Rd. Griffiss AFB, NY 13441, by Software Pro ductivity Solutions, Inc., 122 4 th Ave. Indalantic, FL 32903.


4.1.16 Reviews 1 Several types of reviews are used in the project management environment, each with its own purpose. Reviews generally fall into three major categories: programmatic reviews, external reviews, and technical reviews. Programmatic reviews, such as the Engineering Review Board and the Project Management Council reviews, are used to maintain broad governance over project processes. External reviews, such as non-advocate reviews and independent assessments, provide insight on the health of specific technical and managerial areas of projects from non-

review-dependent. Typically, in the case of an in stitutional support project, the Convenin g Authority resides within the project program or line management. The Project Manager is responsible for working with the convening authority to ensure technical re views occur at the proper project level of maturity. In addition, the Project Manager ensures findings of the review panel/board are properly addressed to enable management decisions allowing project life cycle progression. The Lead Systems Engineer is responsible for facil-

affiliated expert authorities. This section deals with project technical reviews. The technical Reviews process is executed to establish an assessment of the system of interest status. This status is then used to determine readiness to proceed through a progressive maturation of processes to develop the final system of interest. Technical reviews required in support of the project life cycle are detailed in Chapter 3.

itating Reviews process andtoensuring communication of the project technical status review participants. 4.1.16.4 Life cycle 2 Typical reviews are found in or at the end of all project life cycle phase s. 4.1.16.5 Inputs 2 Reviews process input consists of a project with associated products possessing maturity that are consistent with the established review entry criteria.

4.1.16.1 Function1,2 Reviews are conducted to communicate an approach, demonstrate an ability to meet requirements, or establish status. Reviews help to develop a better understanding among project participants, open and maintain commu nication channels, alert partici pants and management to problems, and open avenues for solutions. In the Reviews process: • The purpose, scope, and entry/exit criteria for conducting the review shall be established. • The technical products to be assessed, as part of the specified review, shall be identified. • A technical assessment of the review products shall be conducted, and issues shall be documented and tracked to closure. • Customer and stakeholders participation and role(s) in the review shall be established. • Objective evidence that the review objectives are met shall be documented.

4.1.16.6 Steps 2 As with inputs and outputs, the specific steps of each revie w are unique. However, the general way of doing business for reviews is fairly consisted, as shown in Figure 4.1-16 at the top of the next page. • Establish the Review – The review convening authority, in coordination with the project manager, shall establish and document initial guidance

•

•

4.1.16.2 Objective 2 The purpose of a review is to furni sh the forum and process through which to provide NASA management and their contractors assurance that the most satisfactory approaches, plans, or designs have been selected, that configuration items have been produced to meet specified requirements, or that configuration items are ready.

as follows: − Purpose − Scope − Entry and exit criteria Verify Entry Criteria Are Met – The conveni ng authority, in coordination with the project manager, shall determine whether requisite life cycle steps have be en taken and docu ments, H/W, S/W, and other items that are to be examined possess maturity consistent with review entry criteria. Appoint Review Board/Panel members and Chair and Establish Participant Roles − The convening authority shall appoint the members. • Avoid appointing persons involved with the project as chair or as majority makeup of members. − Highly Recommend ed – In additi on to board appointments, invite a review audience that includes both NASA and contractor personnel who are not directly associated with the project. T his: • Uses cross-discipline expertis e.

4.1.16.3 Responsibilities The Convening Authority is responsible for initiating major milestone project technical reviews. The PMP identifies the convening authority, which may be

4-69


−

Establish the Review – Purpose − – Scope – Entry/Exit Criteria −

Agency/Center Guidelines & Requirements

−

Verify That Entry Criteria Are− M et − • •

−

Appoint Review Board/Panel Members& Chair Establish Review Participant−Roles − − Project Team − Customer − − Other Stakeholders − −

•

Establish Review Ground Rules − − Publish Review Meeting Agenda − − Identify Technical Products to Assess − Describe CR & Action Item − Disposition Process(es) − •

− Conduct Technical Assessment − Review Technical Products − − Hold Review Meeting − − Verify Whether Exit Criteria Are Met − −

Docum ent Evidence That Review Ob jectives Are Not Met − Are or

Review Report

− −

KEY

Step/Activity

Information/ Product

− Information/Output Flows −

Figure 4.1 -16. Reviews process diagram. should be provided to the review board an d

Helps to identify design shortfalls and recommend design improvements. • Should include non-project specialists in the area under review, production/fabrication, testing, QA, reliability, and safety. If indicated, both contractor and NASA contracting officers should be included. − The convening authority shall delineate roles and responsibilities for all participants, including: • Project team • Customer • Other stakeholders Establish Review Ground Rules – The chair shall publish and assure the availability of the: − Agenda of the review meeting. − Technical products to be assessed by the review, including all applicable documents necessary to support the re view. •

•

−

−

− •

Process forchange dispositioning action and requests.requests for Conduct Technical Assessment − Review Technical Products – Copies o f prepared materials (e.g., presentation charts)

meeting attendees in advance of the review meeting. • For major reviews, this could be as far in advance as 30 calendar days. • Specifications, drawings, analysis reports, and any other documents/technical products capturing the approaches, plans, and designs to be reviewed should be included. Board members and attendees may submit requests for action or change requests (CRs) in advance of the meeting that document a concern, deficiency, or recommended im provement in the presented approaches, plans, o r designs. Hold the Review Meeting ? Conduct Oral Presentations with Cognizant Subsystem Engineers to: − Explain applicable projectrequirements. − Describe approaches, plans, or designs −

4-70

devised to date to satisfy requirements. Propose dispositions of CRs and action items submitted prior to the meeting to the chair.


Describe documentation/technical product maturity. − Request Baselining of completed documentation/technical products that require CM. Continue Change/Action Traffic – Board members and attendees may continue to submit requests for action or CRs at the meeting. Formulate and Record Decisions – After developing consensus among members, the chair declares and records: * −

•

•

−

•

4.1.16.7 Outputs

Dispositions of CRs and action items submitted both prior to and during the meeting. Either that the appropriate approaches, plans, or designs briefed at the meeting or submitted o ut-of-board are accepted and that the next steps of the project are authorized; or that there are issues with these items, and enunciates those issues and assigns appropriate action items for the record. Either that completed documents/technical products capturing the accepted approaches, plans, or designs are baselined and are to be taken under CM to support subsequent project action; or that there ar e issues with these items, and enunciates those issues and assigns appropriate action items for

The output of the Reviews process consists of documented evidence produced by the review chair. This evidence addresses the results of the review, including the recommendation as to whether the project has or has not met the established review exit criteria. Characteristic output for individual technical reviews are listed in SP 6105. 2

the record. Verify Whether Exit Criteria Are Met – The board chair: • Finalizes consensus on the findings of the board shortly following the review meeting, including: − Recommendation for or against proceeding with subsequent project life cycle steps − Products baselined − Changes accepted, rejected, modified, and withdrawn

4.1.16.10 and useful techniques MethodsMethods and techniques and necessary to be used during the Reviews process include: • Effective Communication – Effective communication will be necessary to ensure that current project status is effectively conveyed to review board members and that all review participant inputs and concerns are effectively transmitted to the project team and, ultimately, to the convening authority.

−

−

−

Actions assigned and the persons re sponsible for them − All open issues and plans for closing them − Risks from problem areas • Decides, based on established review exit criteria, whether exit criteria have been met. Document Evidence That Review Objectives Are/Are Not Met – The chair shall submit a written report to the convening authority capturing all of the above findings. −

4.1.16.8 Exit criteria 2 The Reviews process exit criteria shall consist of documentation that states that the review criteria have been met. 4.1.16.9 Measurement The table at the bottom of the page provides example base and derived measures that can be used in conjunction with executing the Reviews process. See discussion of Measurement on page 4 -1.

Base Measures

Derived Measures

Duration of the Review

Duration of the Review, Planned vs. Actuals

Review Effort (FTEs)

Review Effort, Planned vs. Actuals

*

For most reviews , the chair is supported by CM and other administrative resources in taking notes, generating minutes, tracking action items and CRs, and tracking products under configuration control.

4-71


•

•

•

views process; including accessibility of review products to rev iew parti cipants, and generation and tracking of review comments and discrepancies to closure.

Configuration Management – This will be used to manage review of products and to ensure all concerns are captured and addressed. Review Checklists – These are use d to summarize items such as desired composition of the review team, lists of support technical documentation, standard entry/exit criteria, etc. Templates – These are used to document the review plans, comments, reports, etc.

4.1.16.12 References The following documents, which were used to prepare this section, offer additional insights into the Reviews process:

4.1.16.11 Software tools Tools available to support the Reviews process

1 NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Processes and Require-

include variety to enhance communications maintaina configuration control throughout the and Re-

ments . 2


4-72

Project Management Processes

4.2 Project Control Processes The objective of the project control processes section of this document is to clearl y re -define the scope of project control. Only after the proper scope of the project control function is clearly defined and agreed to can the issues of organization responsibility and assignment be addressed. It should be emphasized that project control is not a collection of independent, stand-alone functions. It is instead a process that requires the integration of all of its functions to derive benefits for effective project management. This section of the document presents a “projec t

Process measures are used to ensure processes meet customer expectations and are properly implemented. Proactive use of these measurement types enables managers to identify and monitor trends; determine potential cost, schedule, and performance impacts; analyze and prioritize risks and opportunities; and propose corrective action to minimize or eliminate risks through integrated schedules and/or project plan revisions.

control model”that for are the essential various functions, practices, and processes in supporting the successful management of NASA JSC projects. Sound project control practices over the years have contributed to the remarkable accomplishments attained by our Agency and our Center. JSC Project control activities have four significant and key characteristics. These are to: 1. Continually focus project management attention on areas critical to successful project execution. (Focus on what is important.) 2. Establish anddocumenta project baseline,including: • A project requirements list. • A project schedule consisting of significant project-level milest ones. • An interconn ected, sequential networ k of tasks required to complete the project (through retirem ent). • A time-phased life cycle cost (LCC) estimate achieved by “resource loading” (e.g., costs for facility, workforce, materials, other direct costs (ODCs), and indirect costs) of the project network. 3. Emphasize timely responses. 4. Provide a “closed-l oop” system for measurement and analysis of the project that: • Provides a common method fordefining, collecting, analyzing, and reporting measurements. • Provides guidance and requirements for identifying and managing measurement data. • Is a useful tool for assessing progress, product, and process performance. Measurement and analysis is an integral part of project planning, project estimating, project management, and continuous improvement and spans the entire life cycle of a project. It supports the identification, collection, analysis, and reporting of three measurement types: Progress, Product, and Process. • Progress measures are used to help work groups that build products assess the groups’ perform ance against project goals. • Product measures are used to ensure that defects are found early in the development life cycle, resulting in reduced risk and cost.

Resourceprocess Management plans the andpreparation, develops anreintegrated that involves view, and maintenance of project resource needs. It is responsible for reviewing, analyzing, and interpreting data in a timely manner to effectively support project implementation in support of the NASA Strategic Plan and associated Center roles and missions. A major responsibility of Resource Management is to define and lead the bus iness process to ensure project success through the budget formulation andexecution process. It also assesses the political environment, performs requirement analysis, performs metric analysis, and develops resource strategies to facilitate the project and Center budget process and schedules. The Resource Management process will be able to rapidly respond to both internal and external inquiries during the entire budget formulation cy cle of the project. The Resources Management function shall: • Ensure that all project needs are adequately covered and properly time phased in the budget submission and significant resource issues are identified during the POP process. • Monitor cost performance on an ongoing basis by conducting plan vs. actual cost asse ssments and related analyses. • Ensure that the flow of funds is being planned, expedited, tracked, and analyzed to guarantee timely use of project resources. • Make sure that the data and informationprovided to the project management team is timely and accurate. • Recognize and quantify risks and uncertainties by allowing f or adeq uate re serves and allowances. The recognition of uncertainties and quantification of risks are vital to the success of any project; and having contingency funds with a judicious process for allocating them is an es sential element for managing projects, especially in the research and development (R&D) environment. • Resolve and defend unforeseen funding requirements • Be available to advise project managers in all aspects of this critical project control function.

•

4.2.1 4.2.1.1

4-73

Resource Management 1,2,3 Function


A key product of the Resources Management fun ction comprises formulating, monitoring, and maintaining a funding needs profile, including such driver s as facilities and labor requirements. Because labor drives a significant portion of development costs, keeping abreast of the status and trends in this area is critical. The project budget profile, established late in the Phase A effort to be consistent with the cost, schedule, and technical baseline of the project, will be main tained reflecting only the impact of changed project scope or sche dule. In contrast, the project funding requirements will be continually updated to reflect the latest assessment of

• • •

Facility costs (actual) Material costs (planned) Material costs (actual)

4.2.1.6 Steps Resources Management activities are initiated by the program operating plan (POP) process, as discussed in Section 2.8.3 and as described fully in LA-CWI-01, Budget Planning Process . The project manager shall prepare a POP in conformance wit h instructions and guidance provided by the Center Chief Financial Officer (CFO). The CFO is responsible for

resou rce needs andof incorporated in the POP process. A primary value the cost collection effort in the resource management function is to predict future performance indications and to contribute to project management’s decision-making process. The Resource Management process relies heavily on project performance measurement efforts, which integrate the development and maintenance of the cost, schedule, and technical baseline of the project.

the POP process. Guidance for developing thesignature POP is provided in the Center POP Call issued under of the CFO. In addition, common wor k in struction LA-CWI-01 document s the POP proces s at JSC. It is critical that the POP submission realistically project the cost required to procee d according to the project management plan (PMP). The project POP should also identify any over-guidelines require ments and associated impact statements assessing the risk to the technical performance of project schedules due to lack of required funds. The project manager should structure the POP submittal to minimize the risk associated with normal fluctuations in available funding as a result of the authorization, appropriation, and apportionment process or any delays. The project manager should also include a projection of the total LCC of the project. These steps are illustrated in Figure 4.2 -1 at the top of the following page.

4.2.1.2 Objective The objective of resource management is to establish and ensure consistency between resource availability and project resource needs. 4.2.1.3 Responsibilities The Project Control Officer is responsible for all aspects of the Resource Management process, including notifying the Project Team of when and what data are required, coordinating with any project-external organizations, ensuring timely project-internal review of the final product, and delivering the final product. Other participants in this process include the: • Project Manag er , who is responsible for ensuring the Project Control Officer has the facilities and workforce needed to accomplish this task. The Project Manager also acts as a customer to the Project Control Officer for this process. • Entire Project Team , which also participates in this process by providing data, supporting rationale, and recommendations for improvement.

4.2.1.7 Outputs Outputs to the Resource Management process include: • Annual project budget submissions (funding requirements) • Completed POP (time-phased estimation to complete (ETC) by phase and to completion) • Workforce forecasts (by phase and to completion) • Cost forecasts (by phase and to completion) 4.2.1.8 Exit criteria The exit criterion for the Resource Management process is a complet ed work breakdown structure (WBS).

4.2.1.4 Life cycle Resource management begins in Phase A and is conducted throughout the life cycle of the project.

4.2.1.9 Measurement The following table provides example measures that can be u sed in conjunction with executing the Resource Management process. See discu ssion of Measurement on page 4-1.

4.2.1.5 Inputs Inputs to the Resource Management process include: • Civil service labor cos ts (planned) • Civil service labor costs (actual) • Contractor labor costs (planned) • Contractor labor costs (actual) • Facility costs (planned)

4.2.1.10 Methods and techniques The methods and techniques that may be used in developing requirements are:

4-74


Define and document resource management plan including strategy, processes (including POP schedules), and procedures including reserves management approach and process metrics

Complete project resource needs by WBS

Modify resource Yes management plan accordingly

Identify Check to enpotential sure resource reserves projections are level(s) realistic, accurate, and cover entire Potential project scope reserves level(s) and life cycles approved by project manager

Implement?

Project review of new performance/ process metric indicators

Review project resource needs and phasing, and identifypotential issues (e.g., proper resource phasing for contracts, workforce, and facility support schedules, etc.), and mitigation plans

Identify potential metric indicators to identify this problem in future

Document project resource budget, obligation, and cost plan (including phasing) i.e., POP

Project manager approves

Submit to Center/program POP call

POP

Project operating plan New budget required per annual POP schedule

(budg et) approved)

Analyze issue including root cause and potential additional resource impact in future

Yes

Reanalyze POP and process metrics on a monthly basis;

Issue identified?

No

No

Develop monthly status reporting including potential issues

identify process/ progress issues Form 533 inputs, if applicable

Figure 4.2 -1. Resource management process diagram. Base Measures

Derived Measures

Total # of internal task agreement s (ITAs) developed

Time to complete each ITA, from draft to final signature Average time for all ITAs to be completed, with final signature

Total $ value of all ITAs (in full cost)

ITA $ costed to date (in full cost) Monthly ITA $ costed to date (planned vs. actual)

Support contractor total $ value of contract

Support contractor $ costed to date

Total # of civil servants on project Total # of contractors on project

Monthly contractor $ costed (planned vs. actual) Monthly level of civil servants (planned vs. actual) Monthly level of contractor personnel (planned vs. actual)

% of WBS development complete Total material costs (planned vs. actual), if not already captured in ITA

Monthly material costs (planned vs. actual)

Management reserve remaining ($)

Monthly level of management reserve ($) available

Purchase request (PR) tracking log • • • • •

team members and stakeholders. The following S/W tools satisfy these considerations: • Excel • Microsoft PowerPoint

Resource (workforce, cost, etc.) histogram Individual or group expert judgment Statistical analysis of historical data JSC SLP 4.20, Proce ss Mea surem ent and Improvement Contractor financial reporting systems for contrac tor-supported/NASA-managed projects

4.2.1.11

4.2.1.12 References The following documents, which were used to prepare this section, offer additional insights into the Resource Management process:

Software tools

6103,NASA Readings in Project Control, 1994. NPR 7120.5B, NASA Pr ogram a nd Proj ect Man agement Processes and Requirements , 2002. 3 Full Cost Initiative Agencywide Implementation Guide: http://ifmp.nasa.gov/codeb/library/f cimplementation.pdf .

The two principal considerations for a tool that would support the Resource Management process are (1) the consistent, concise, and thorough docum entation of the project funding status; and (2) common and convenient accessibility and visibility to all project

1 SP 2

4-75


4.2.2 Planning 1,2,3 4.2.2.1 Function Project planning is determining what needs to be done, by who m, when, and with what resources to accomplish the project. Without appropriate planning there can be no project control, because planning provides the baseline that makes control possible. The Planning process is an iterative process that requires the active participation of all knowledgeable project and support team members, and that defines req uirements, schedules, cost, and the resulting PMP. This process shall be achieved by establishing requirements ,

• •

Project product list Project schedule

4.2.2.6 Steps Project and management planning is an iterative process that entails layout out a unified strategy for projec t accomplishment and adjusting to changing conditions, updating the plan, and integrating requirements acros s all project disciplines. The basic elements of planning, which a business discipline will engage in, occur from the formulation phase throughout the implementation phase. These

an overall project budget, a project WBS,management a detailed networked schedule baseline, and a risk process. This would then allow the project to eval uate progress and determine and implement any “mid course” corrections.

elements include: • Developing objectives and requirements • Developing WBS • Developing project requirements, including the master schedule • Assuring cost and schedule are commensurate with technical scope • Assisting in cost/schedule trades as they relate to system and design changes • Conducting “what-if” analyse s • Assessing workforce needs and skill mix • Developing the PMP • Developing acquisition strategies Although a significant initial effort is required during the formulation phase, the Planning process is a continual and iterative process of laying ou t and ensuring a unified effort in implementation, adjusting t o changing conditions, maintaining the plan, and integrating technical, cost, and schedule requirements.

4.2.2.2 Objective The objective or project and management planning revolves around establishing the project roadmap from inception to completion of stated goals. A key element in the Planning process is the ability of the program to effectively plan and organize activities to meet overall objectives. Strategic planning is determining what needs to be done, by whom, when, and at what expense of resources throughout the life cycle of the project. It carefully considers customer needs and how project resources can be best managed. 4.2.2.3 Responsibilities The Project Control Officer is responsible for all aspects of the Planning process, including notifying the Project Team as to when and what data are required, coordinating with any project-exter nal organiza tions, ensuring timely project-internal review of the final product, and delivering the final product. Other participants in this process include: • Project Manag er , who is responsible for ensuring the Project Control Officer has the facilities and workforce needed to accomplish this task. The Project Manager also acts as a customer to the Project Control Officer for this process. • Entire Proje ct Team , which also partic ipates in this process by providing data, supporting rationale, and recommendations for improvement.

Figure 4.2-2, which appears at the top of the next page, il lustrates the steps in the Planning process. 4.2.2.7 Outputs Typical outputs to the Planning proc ess are: • Project WBS • Master schedule • Responsibility organization matrix • Project organization and structure • Resource loaded, integrated schedule Specific time-phased estimates should be devel oped for direct civil service labor and travel and for d irect contractor labor and total cost. All other elements of project cost (service pools and general and adminis trative (G&A)) are planned and recorded as factors applied to labor or other direct costs and are not within the control of project management personnel. Planners should be familiar with the latest version of the Full

4.2.2.4 Life cycle Planning is conducted throughout the life cycle of the project. 4.2.2.5 Inputs Typical inputs to the Planning process are: • Project requirements

Cost Initiative Agencywide Implementation Guide, which is available from the CFO.

4-76


Figure 4.2 -2. The planning process diagram.

4.2.2.8 Exit criteria An integrated project baseline has been developed and accepted by the POP process as the exit cri terion. 4.2.2.9 Measurement The following table provides example base and derived measures that can be used in conjunction with executing the Planni ng process. See disc ussion of Measurement on page 4-1.

4-77


Base Measures

Derived Measures

# of project support plans identified (e.g., PMP, Systems Engineering Management Plan (SEMP), risk management plan, documentation and data management plan, acquisition management plan, etc.)

# of project support plans completed to draft level (actual vs. planned) # of project support plans completed to final level (actual vs. planned)

% complete of responsibility organization matrix

% complete of responsibility organization matrix (actual vs. planned)

% complete of WBS development (% vs. schedule)

% complete of WBS development (% vs. schedule) (actual vs. planned)

# of detailed and high-level project schedules to be developed

# of detailed and high-level project schedules developed (actual vs. planned)

Organization structure

Draft version available Final version available

LCC estimate completion schedule

LCC estimate completion schedule (actual vs. planned)

4.2.2.10 Methods and techniques The methods and techniques that may be used in developing requirements are derived from individual or group expert judgment. 4.2.2.11 Software tools The following S/W tools satisfy the Planning proces s: • Microsoft Project • Microsoft Project Server • Excel • Microsoft PowerPoint • SuperProject Expert 4.2.2.12 References The following documents, which were used to prepare this section, offer additional insights into the Planning proces s: 1

Milosevic DZ, Proje ct Management Tool box , John Wiley & Sons, Inc., 2003. 2 Forsberg K, Mooz H, Cotterman H, Visualizing Project Manag ement , 2nd edition, John Wiley & Sons, Inc., 2000. 3

Lewis JP, Fundamentals of Project Management , AMACOM, 2002.

4-78


4.2.3

Documentatio n and Data Management 1–4 4.2.3.1 Function Documentation and data management establishes the data policies, responsibilities, and procedures for identifying, selecting, archiving, and providing access to project data not directly associated with product configuration. Examples of these types of information include the PMP, meet ing minutes, design review pre sentations, the acquisition management plan, etc. It must be clearly understood that documentation and data management is separate and distinct from config-

tion required to support a project. It assures that the appropriate project management data are captured and that proper control is established for data and documents created during and after the life of the project.

uration management (CM), which focuses the actual project product configuration. Further on information on CM can be found in Section 4.3.3. The project shall make every effort to retain only the minimum items required by regulations and those items needed to permit cost-effective support of research, development, production, cataloging, provisioning, training, operation, maintenance, and related logistics functions over the project life cycle. The project team must have timely, authorized a ccess to ac curate dat a and documentation, regardless of where the data are stored, how they are formatted, or how they are access ed. Data and documentation must be available when needed to reduce cycle time, increase data accuracy , and ultimately improve decision-making. There should be frequent, informal interaction with the project team (and with the parent program, if applicable) to determine information requirements and preferences. Additionally, the documentation and data management system should ensure adequate control of the data and documents once they are provided. An additional aspect of documentation and data management includes the display of information. Time invested in designing effective formats for communication of project data and document early in the project advanced studies and definition phases will lead to significant returns, especially in the area of labor hours. Communication techniques should include the judicious use of candor b y members of t he project team, data visualization techniques (to depict and focus major points) and documentation, and data scope and depth to help establish credibility and reliability for the communicated products. For contractor-supported projects, the project team will establish similar documentation and data management requirements and formally document them as a deliverable that is subject to immediate access or that must be made available to the project team within a specified period of time.

project-internal of the final product, and delivery of the finalreview product. Other participants in the process include the: • Project Manager , who is responsible for ensuring the Project Control Officer has the facilities and workforce needed to accomplish the task. The Project Manager also acts as a customer to the Project Control Officer for this process. • Entire Proje ct Team , which also participates in this process by providing data, supporting rationale, and recommendations for improvement.

4.2.3.3 Responsibilities The Project Control Officer is responsible for all aspects of the Documentation and Data Management process, including notifying the Project Team as to when and what data are required, coordination with any project-external organizations, ensuring timely

4.2.3.4 Life cycle Documentation and data management is conducted throughout the project life cycle. 4.2.3.5 Inputs Typical inputs to the Documentation and Data Management process include a detailed understanding of Federal, JSC, and, if appropriate, program-specific data and documentation regulations and requirements. 4.2.3.6 Steps The Documentation and Data Management process for the project begins with a clear understanding of the documentation and data management requirements levied on the project by Federal, NASA, and JSC requirements. The project will then proceed to identify the documentation and data management strategy, approach, processes, procedures, methods, and metrics to be used. After these steps have been successfully identified and documented, the project will identify a preliminary set of documentation and data to be re tained and, potentially, archived throughout the complete project life cycle. As the project exe cutes the data and documentation plan over the project life cycle, it shall be necessary to perform a periodic audit of the processes. These audits will include performing a review of the process metrics, output products, and, as required, retained and archived documentation and data. If an issue is identified during the audits, the project team (and any other necessary external organization) shall analyze the issue to determine the root cause of

4.2.3.2 Objective The objective of documentation and data management is to establish a formal and disciplined system for the scientific, technical, and management informa-

4-79


the issue and the preventive or corrective action required. After successful implementation of a preventive or corrective action, the project team may re -audit this area during the following normally scheduled audit or, if necessary, perform a special audit that focuses solely on the specific top in question. Figure 4.2-3 illustrates t he steps in the process.

Document documentation and data management strategy, approach, processes, procedures, methods, and metrics in a plan

Baseline plan in PMP

Identify preliminary documentation and data elements to be retained/archived

•

Successful audit of the implementation of all data and documentation management tools and techniques

4.2.3.9 Measurement The table at the top of the following page provides example base and derived measures that can be used

Periodically audit documentation and data management process metrics, output products, and retained/archived documentation and data

Execute Plan Over Project Life Cycle

No

Analyze issue to determine Issue identified

Yes

root cause and preventive, corrective action required

No

Continuous improvement option identified

Yes Implemen t continuous improvem ent action Implement preventative/ corrective plan

Figure 4.2 -3. Documentation and data management process diagram.

4.2.3.7 Outputs Typical outputs to the Documentation and Data Management process are: • Documented project strategy and process for data and documentation management • List of identifi ed project data and documentation to be controlled, reported, and archived • List of data and documentation management tools and techniques to be used by the pr oject • Project change log • Change request form

in conjunction with the Documentation and Data Management process. See discussion of Measurement on page 4-1. 4.2.3.10 Methods and techniques The methods and techniques used in developing documentation and data management requirements are: • Audit process • Individual and group expert judgment 4.2.3.11 Software tools The following S/W tools satisfy the requirements of documentation and data management: • Change tracking tool (e.g., Excel) • Document and data storage tool (e.g., Windchill) • Process modeling tool (e.g., Process Model)

4.2.3.8 Exit criteria Exit criteria for the Documentation and Data Management process are: • Project strategy and process for data and documentation management documented in the PMP • Successful audit of the documentation and data process to ensure it adequately addresses all Federal, JSC, and, if applicable, programsp ecific regulations and requiremen ts

4-80


Base Measures

Derived Measures

Documented audit results

Documented preventative and corrective actions (including closure date) resulting from the audits Total # of completed preventative and corrective actions (planned vs. actual) # of completed preventative and corrective actions per month (planned vs. actual)

4.2.3.12 References The following documents, which were used to prepare this section, offer additional insights into the Documentation and Data Management process: 1

JMI 2314.2L, Identifyin g and Processing JSC Scientific, Technical and Administrative Documents , 1993. 2 JPD 2200.1A, Relea se of JSC Scient ific and Technical Information to External Audiences , 2000. 3 JPG 1440.3, JSC Files and Record Managem ent Procedures , 2001. 4

NPD 1441.1D, NASA Record Retention Schedule , 2003.

4-81


4.2.4 Cost Estimating 1– 5 4.2.4.1 Function Cost estimating and the development of accurate and defensible LCC estimates for JSC projects are critical for good project planning and execution. LCCs are the total of the direct, indirect, recurring, nonrecurring, and other related expenses incurred or estimated to be incurred in the design, development, verification, production, operation, maintenance, support, and retirement of a system over its planned lifetime. A project manager can use the LCC estimates as no t only a project planning tool for workforce and deliverables,

review team wil l question project assump tions and identify and quantify technical and programmatic risks, risk mitigation strategies, and reserve strategies. Depending on the team’s findings, the ICE from one of these reviews may result in a recommendation to change the project funding profile.

but alsospace as anfor additional input or constraint into the design the project. Cost estimating may be done at the project level or at some lower level. Project-level cost estimates will be discussed in the following paragra phs. Cost estimates may also be done at lower levels; e.g., in individual change requests or as a comparison tool in trade studies. It is critical that the project team performing the cost estimate uses the proper tools and techniques for the project life cycle phase in which the estimate is being done. NPG 7120.5B3 provides the requirements and guidelines for the frequency and types of projectlevel cost estimates to be performed. Both types of estimates (i.e., project l evel and below) can be developed at the request of the project manager to the JSC Chief Financial Officer, Cost Estimating and Assessment Office. Basically, two types of project-level cost estimates are required during the life cycle of the project. Thes e are the advocacy cost estimate (ACE) and the independent cost estimate (ICE). An ACE shall be required of all JSC projects and shall be documented in the PMP prior to approval. Although the project office can develop the LCC estimate for budgetary planning purposes based on its understanding of the technical requirements and schedules, it is strongly encouraged that the project coordinate this activity with the CFO Cost Estimating and Assessment Office. The ACE typically become the project bas eline estimate and is performed during the Pre-Phase A and Phase A definition phases of a project. There may be several iterations of the ACE during these phases as trade studies are conducted and the project becomes more mature and better defined. An ICE shall be accomplished as required by th e JSC Center Director or NPG 7120.5B. 3 This independent cost review may also be accomplished as part of other independent reviews, such as a non -advocate re-

be generated reflect realistic cost projects for achieving the that documented technical requirements of a project.

4.2.4.2 Objective The objective of effective cost estimating is to assess project performance and aid in project decision-making. Beginning early in the life cycle process and continuing throughout the project life, cost estimates must

4.2.4.3 Responsibilities The Project Control Officer is responsible for all aspects of the cost-estimating process, including notifying the Project Team of when and what data are required, coordination with any project-external organizations, ensuring timely proj ect-internal review of the final produc t, and delivery of the final product. Other participants in this process include the: • Project Manager , who is responsible fo r ens uring the Project Control Officer has the facilities and workforce needed to accomplish this task. The Project Manager also acts as a customer to the Project Control Officer for this process. • Entire Proje ct Team , which also participates in this process by providing data, supporting rationale, and recommendations for improvement. 4.2.4.4 Life cycle Cost estimating is conducted throughout the life cycle of the project. 4.2.4.5 Inputs Inputs to the Cost Estimating process are dependent on the cost estim ation method and technique to be used. For example, potential inputs could include a wide range of parameters such as weight, year of technology, quantities, technical complexity, schedule, estimated number of lines of S/W code, etc. Inputs are also provided to the process by the cost analysis requirements description (CARD). 4.2.4.6 Steps The project team member: • Should determine what the cost estimate scope and content should include. Care should be taken to ensure the cost estimate reflects all cost-generating areas within the scope of the estimate by establishing a comprehensive WBS. • Should review the various models and techniques readily available for cost estimating during that

view (NAR) or an independent assessment (IA). In each of these cases, members of the independent review team, as opposed to the project team, will develop the ICE. In addition to reviewing the project selection of cost methodologies and model inputs, the independent

4-82


life cycle phase. If a cost-estimating commercial off-the-shelf (COTS) or NASA-developed parametric model is used, the project team member should ascertain whether individual training on the use and nuances of the model(s) is necessary. • Develops and documents the input parameters to be used for the model chosen. Documentation includes the rationale behind selection of individual parameters and values so as to capture the thought process used to develop them. • Finally runs the model. The resulting cost estimate is reviewed for “reason-

Figure 4.2-4 (below) illustrates th e steps taken in this process. 4.2.4.7 Outputs Typical outputs to the Cost Estimating process are: • Cost estimate • Project data to develop the CARD 4.2.4.8 Exit criteria Exit criteria for the Cost Estimating process are: • Completion and documentation of cost estimate • Method of cost estimate, including all input

ableness” using engineering judgment. mustthan be taken not to discard a cost estimate thatCare is higher the project team member’s experience. Therefore as a result, model changes that may be required should be incorporated and the model run again until a reasonable result occ urs. A sensitivity analysis should be done to determine both the primary “cost drivers” and the potential range of the cost estimate given project-realistic changes in the input parameters.

Cost Estimate Determined to be Needed

parameters and their rationales 4.2.4.9 Measurement The table, which appears at the top of the following page, provides example base and derived measures that ca n be used in conjunction with executing the Cost Estimating process. See discussion of Measurement on page 4-1.

Yes Develop Cost Estimate

Determine Most AppropriateModel and Technique to be Used

Cost Estimate Scope and Content Decided

Develop and Document Input Parameters

Project Team Member Familiar with Model/Technique

No Obtain Training

Review Output for “Reasonableness” No

Reasonable?

No

Correct Model and Technique Used?

Yes

Correc Input Parameters Used?

Yes Conduct Sensitivity Analysis

No

Document Cost Estimate Results

Figure 4.2 -4. Cost estimating process diagram.

4-83

Yes

Solicit Expert Consultation from JSC CFO


Base Measures

Derived Measures

# of cost estimates done

Time to accomplish cost estimate (in days)

4.2.4.10 Methods and techniques The methods and techniques that may be used in developing requirements are: • Parametric • Grass roots • Analogy • • •

4.2.4.12 References The following documents and Web site, which were used to prepare this section, offer additional insights into the Cost Estimating process: 1

Milosevic DZ, Project Man agem ent To olbo x , John Wiley & Sons, Inc., 2003. 2 NASA

Cost Estimating Handbook 2002 at http://www.jsc.nasa.gov/bu2/NCEH/index.htm .

Individual or group expert judgment Historical costs of analogous H/W and S/W systems Inflation indices; e.g., the NASA (Code B) R&D New Start Index

3

NPR 7120.5B, NASA Pr ogram a nd Proj ect Man agement Processes and Requirements , 2002. 4 5

SP 6103, NASA Readings in Pr oject Control .


4.2.4.11 Software tools The following S/W tools will support the Cost Estimating process: • Parametric cost models; e.g., NAFCOM, PRICE, SEER, and COCOMO • Ris k analysis tools; e.g., @RISK • Cost-phasing algorithms; e.g., the Beta Curve

4-84


4.2.5 Performance Measurement 1–4 Performance measurement is a management tool that shows the current system or process status and identifies problem trends or problem areas as t hey develop. The three major types of performance measurement are technical performance measurement (TPM), process performance measurement, and earned value management (EVM) performance measure. Although there are other taxonomies for performance measurement, they will not be addressed here. The first of these performance measurements,

resources, when issues are resolved it may be wise to delete the measures addressing them unless there is concern that these issues may recur. The third and final type of performance measurement is EVM. EVM is a “leading process” whereby project tasks are arranged in resource-load schedules (a budget baseline) and checked off when accomplished. A detailed discussion of EVM is provided below.

TPM, addresses the system interest. enBy measuring orattributes estimatingofTPMs, the of subsystem gineer, lead systems engineer, and project manager gain visibility into whether the delivered system will actually meet performance requirements. The goal of TPM is to provide early warning that specific quan tifiable threshold values for performance (e.g., accuracy, thrust, reliability, etc.) or limits of resources (e.g., weight , power demand, thermal output, memory availability, central processing unit (CPU) usage, etc.) are in jeopardy. These thresholds and limits are key attributes of the system of interest. They are not applicable to all elements of a project, and they may or may not be additive. A detailed discussion of TPMs is found in Section 4.1.12. The second type of performance measurement, process performance measurement, addresses the processes used in engineering the s ystem of interest. SE metrics are included in this category, as are project control metrics involving production control, operations, and maintenance. Examples of SE and project control metrics are shown throughout Chapter 4. The focus of process p erformance measurement is on the progress of the project and the quality and productiv ity of the processes rather than on the performance of the system of interest. Such metrics will facilitate the detection of systemic problems (e.g., skills imbalances ) or project difficulties (e.g., requirements instability). Process metrics will also guide process improvement initiatives. Further detailed discussion of process performance measureme nts is found in Section 4.3.4. Both TPM and process performance measurement should be directed at issues in either the projects or the organizations in which the projects are performed. These measures are not universal and should no t be applied to all of the elements of a project or an organization. Some issues requiring closer scrutiny and measurement will be identified in the early phases from project objectives (budgets, schedules, quality,

quantify accomplishments. Earned value measure of progress in completing the project; i.e., is itsthe degree of completion. The goal of EVM is to provide early visibility into technical problems that, if unrecognized, may impact project cost or schedule goals. The earlier such problems are recognized, the more likely the corrective action will be fruitful and the less likely the problems will result in large project overruns or schedule slips. Before project management starts, a project must be defined. An effort becomes a project when the scope (with completion criteria), schedule (completion date and major milestones), and budget (the most likely level of resources that will be consumed) are clearly defined and conclusively agreed by the customer and the supplier or project manager. The EVM process starts when the project scope (statement of work (SOW)) is clearly divided into lower-level, re latively short-duration tasks that can be sequenced, scheduled, budgeted, and assigned by the project manager to responsible front-line managers for completion. A WBS is the most desired method of accomplishing this. The EVM process continues into project implementation with monthly or weekly project schedule assessments in which the responsible front-line managers quantify progress (earned value) against the budgeted, short-duration tasks defined in the planning phase. In this assessment a task is either complete, in which case the budget value is “earned,” or is not complete, in which case there is no “earned value.” Significant differences between the volume of work completed and the volume planned (schedule variance) must be thoroughly analyzed to identify the nature of the problem and the reason for this variance. Once the cause of variance is understood, its likely impact on the same or future tasks can be accurately assessed and corrective actions can be planne d and set in motion to eliminate or mitigate the effect on downstream work. During these frequent assessments, front-line man-

performance, system capability), risk assessments, project constraints and assumptions, product acceptance requirements, or project external requirements. Finally, these issues may be identified from experience. Because the measurement process consumes

agers need to determine the actual cost of the completed work. The actual cost data must come from the accounting system. Significant differences between the volume of work completed and the actual cost inc urred (cost

4.2.5.1 Function EVM is an approach to project management (planning and control) that requires the project manager to

4-85


variance) should be analyzed in a manner similar to that used to analyze the schedule variance. Once the front-line managers clearly understand the nature of the problems and make reasonable plans for corrective actions, they can ma ke informed fore casts of when the tasks can be completed and what level of resources they are likely to consume. These estimates are consolidated to produce an ETC for t he project. This cycle of quantifying progress against schedule and actual cost is repeated each period until project completion. If these assessments are to accura tely re -

NASA policy for application of EVM can be found in NPD 9501.3A. 3 This document applies only to contracts . It requires the contractor to apply EVM to R&D or production contracts larger than $25M and of a duration longer than one year. If the contracts are larger than $70M for R&D or $300M for production, the contractor is required to implement a system that observes the 32 principles from EIA-748A. 1 It further requires “validation,” meaning that the EVMS actually used by the contractor has been de monstrated and verified in writing as complying with the 32 principles or criteria. Earned value is not required if the

flect status and forecasts of future conditions,the theproject plan (baseline) must be maintained. The goal of maintenance is that the baseline always reflects the agreement between the customer and the project manager. When the project changes (i.e., work is added, deleted, or moved in time), the ba seline must change to reflect this new reality. The budgets for project tasks will change in total dollars or in phasing whenever significant work is added, deleted, or moved in time. The budgets will not change, however, unless the work changes. 1 EVM is described in significant detail in EIA-748A. This standard has many parallels with EIA-632. 2 The EIA-748A guidelines for EVM are as follows: • Plan work scope for the project to completion. • Break down the project work scope into finite pieces that can be assigned to a responsible person or organization for control of technical, schedule, and cost objectives. • Integrate project work scope, schedule, and cost objectives into a performance measurement baseline plan against which accomplishments may be measured. Control changes to the baseline. • Use actual costs incurred and recorded in accomplishing the work pe rformed. • Objectively assess accomplishments at the work performance level. • Analyze significant variances from the plan, forecast impacts, and prepare an estimate at completion based on performance to date and work to be performed. • Use earned value management system (EVMS) information in the center management process. EIA-748A 1 also includes 32 principles that further promote ob jective and accurate assessment of the status and outlook of projects. These principles are appropriate for large, long-term projects in which accuracy, objectivity, and baseline traceability are particularly importance. The principles are essentially the same as the Cost/Schedule Control Systems Criteria (C/SCSC) levied by the Department of Defense (DoD ) on larg e weapons programs since the 1960s.

contract predominan tly level-of-effort (no 3product A draftispolicy (to replace NPD 9501.3A but re-s ). numbered to be part of program formulation policy, NPD 7XXX) is in development at the Agency level. This document will broaden the application from contracts to projects. In the interim , JSC shall imple ment an EVMS for all projects that is tailored to the specific project and approved by the Center EVM Council representative. Only the Center PMC or Center Director may approve waivers of NPD 9501.3A. 3 4.2.5.2 Objective The objective of EVM is to prove early visibility into project technical problems so that corrective actions might prevent unfavorable schedule or cost outcomes. 4.2.5.3 Responsibilities The Project Control Officer is responsible for all aspects of the performance measurement process. This includes notifying the Project Team of when and what data are required, coordination with any project-external organizations, ensuring timely project-intern al re view of the final product, and delivery of the final product. Other participants in the process include the: • Project Manager , who is responsible for ensuring the Project Control Officer has the facilities and workforce needed to accomplish this task. The Project Manager also acts as a customer to the Project Control Officer for this process. • Entire Project Team, which also participates in this process by providing data, supporting rationale, and recommendations for improvement. 4.2.5.4 Life cycle EVM is applicable to any project life cycle phase that has conclusive completion criteria. 4.2.5.5 Inputs Typical inputs to the EVM Performanc e Measurement process are:

4-86


•

•

•

A product hierarchy (usually a WBS) with definitions for each element that clearly distinguish that element from all other elements and that provide conclusive guidance regarding completion criteria. Work authorization (scope, schedule, budget in terms of resource types, and signatures indicating a meeting of the minds): − At the project level, between the customer and the performing organization. − At the task level (scope entirely within a WBS element to be performed by a single

•

An EVM tool that will capture resource-loaded schedules.

4.2.5.6 Steps Figure 4.2-5 illustrates t he steps that are taken in performing the EVM Performance Measurement process. These steps can be broken down into two phases : planning and control. • Planning Phase − A solicitation is receive d from the customer. The formality is less important than the specificity of the solicitation. It should clearly

functional organizatio n), between the pro ject manager and the task manager. Schedules that clearly define the period of performance, major enforced milestones dates, and delivery dates of customer- supplied prod ucts.

−

convey the major functionality of milestones the product as well as the schedule pertinent t o the product. The directorate prepares a proposal describing the implementation, the budget in terms

Customer:

Solicitation

Urgent Change

Proposed Change Review

Review

Directorate: Proposal

Agreement?

Yes

Projec Agreement (e.g., ITA) Review

No

Project Manager: Initial Planning

Review

Project Log

Review

Project Management Plan

Work Authorization Documents

Task Manager: Review

No

Agreement? Yes Detail Planning Record Baseline Actual Cost

Figure 4.2 -5. Performance measurement process diagram.

4-87

Schedule Status

Another Month’ s Work

Analyz Variances

Estimate Cos to Complete

Report

Replan


−

−

−

−

of time-phased resources (i n-hous e labor by organization, contractor labor, material, facilities, travel, service pool, general and administrative (G&A) by fiscal year), and any other pertinent schedule events. Review and negotiation continues until both parties reach a mutual agreement regarding scope, schedule, and time-phased reso urces (budget). This agreement is recorded in an ITA or another document that clearly defines the scope, schedule, and budget. It is t hen signed by the director and the customer.

−

•

The project manager sufficient internal planning to do aperforms preliminary allocation of project tasks and resource levels to performing organization units. These plans will also include targ et dates for commencing and completing the tasks. Negotiation between the project manager and the task manager will continue until they reach a mutual agreement regardi ng all sali ent provisions of the task. The project manager, task manager, and functional manager, who supervises the task manager, will sign the work authorization document (WAD). Once the WAD is signed, the task manager will perform the detailed planning that breaks the task into near- term work packa ges (subtasks) and farther-term planning packages, indicating specific periods of performance but with less “granularity.” Each work package and planning package will be composed of only a single resource type. Predecessor/ successor relationships among the work/planning packages will be defined. A work package represents units of work at levels where work is performed. A s such, it is clearly dis tinguished from all other work packages. Among the factors that distinguish are: • It is assigned to a single organizational element. • It has scheduled start and comp letion dates and, as applicabl e, interim mile stones that are representative of physic al accomplishment. • It has a bud get or an ass igned value expressed in terms of dollars, labor-hours, or other measurable units. • Its duration is limited to a relatively short time span, or it is subdivided by disc rete value milestones to facilitate the objective measurement of work performed, or it is level of effort. • It is integrated with detailed engineering, manufacturing, or other schedules.

Control Phase − Each month, the task manager will status the task-level schedule. Milestones and work packages will be reported as complete, not yet started, or in process. − The schedule status information , when co mpared with the project baseline data, will in dicate schedule variance. When compared with actual cost data, cost variances will be revealed. Both schedule and cost variances will be analyzed as to cause (i.e., the nature of the technical problem underly ing the variance), impact on the current task and on successor tasks, and corrective action. − A time-phased ETC will be prepared that reflects actual cost to date and knowledge of future conditions. − The task manager will repeat this cycle each month, updating schedule status, analyzing

−

−

4-88

Record this baseline information in the EVM tool. Baseline information includes schedule and budget data. Budget data will be broken into the performance measurement baseline representing work authorized formally to task managers, undistributed budget that represents work not yet authorized to task manage rs, and management reserve representing a contingency held by the project manager to authorize work that has always been part of the scope that has not been assigned to any task manager.

variances, and building untilofthe task is complete. Each monthETCs a r eport this in formation will be provided to the project manager, directorate management, and customer. Occasions will arise when a work package or a milestone should be replanned. Replanning can take the form of a change in time (schedule) or implementation details (differ ent work group, buy rather than make, etc.) within the overall schedule and budget constraints for the task as outlined in the work authorization. When such a need arises, a request will be prospectively prepared and forwarded to the project manager. When approved, the detail project baseline will be modified accordingly. On infrequent occasions, changes in overall project scope or schedule will be necessary. These changes will follow the steps taken when establis hing the srcinal project agreement. Sometimes elements of the changes are urgent and must be pursued immediately, even if the changes have not yet been


4.2.5.11 Software tools The following S/W tools satisfy the principal considerations of the EVM Performance Measuring process: • MS Project • MS Project Server • EV tools perform several essential tasks, including: − Schedule planning (duration, sequence, resource types, resource levels) − Schedule baseline (recordin g and maintain ing baseline approved by project manager) − Schedule status by work package or mile -

negotiated between the customer and the directorate. In such cas e, the near-term eff ort will be scheduled and budgeted. At the same time, a change request will be prepared, negotiated, and recorded to reflect appropriate, equitable changes to the baseline values. 4.2.5.7 Outputs The outputs of the process are: • Variance analyses characterizing the cause and impact of only significant variances as well as corrective action plans intended to mitigate or •

•

minimize effects of technical These problems. Estimates the of cost at completion. estimates are based on performance to date, commitment values for material, and estimates of future conditions. Estimated project completion date, including forecasts for significant milestones.

− − −

4.2.5.8 Exit criteria There are no exit criteria since this process is continuous.

−

4.2.5.9 Measurement The following tables provides example base and derived measures that can be used in conjunction with executing the Performance Measurement process. See discussion of Measurement on p age 4-1.

Base Measures

Project • Plan (budgeted cost of work scheduled (BCWS) • Earned value (budged cost of work performed (BCWP)) • Actual cost (actual cost of work performed (ACWP)) • BAC • EA C

−

stone (completed, not started, or in work/ percent complete) Schedule forecast (estimated dates for baselined tasks) Record direct costs in a manner consist with budgets without allocation Report variances (schedule and cos t) at task level Report to facilitate variance analysis (automatically decompose labor-cost variances into rate and efficiency vari ances and ma terial-cost variances i nto price and usag e variances) Accommodate revisions to baseline for • Internal task replanni ng • Adding or deleting work from task • Changes to indirect cost rates or factors

Derived Measures Schedule variance (SV) – ($, %, co mparative fit index (CFI), 6-month, etc.) Cost variance (CV) – ($, %, CFI, 6-month, etc.) Variance at completion (VAC) – (budget at completion (BAC)-estimate at completion (EAC)) Schedule performance index (SPI) (earned value (EV)/Plan) Cost performance index (CPI) (EV/ACWP) To complete performance index (TCPI) (BAC-EV)/ (EAC-actual cost (AC))

Fraction of work performed each period

Defined as measured as opposed to level of effort (LOE)

Age of unnegotiated changes

Age of unnegotiated changes (actual vs. project-defined “yellow” and “red” age levels)

4.2.5.10 Methods and techniques The methods and techniques that may be used in developing requirements are defined by EIA -748-A1 principles.1

−

4-89

Consolidation for reporting purposes from task level to project level through hierarchies for organization (functional) and product (WBS).


4.2.5.12 References The following documents, which were used to prepare this section, offer additional insights into the EVM Performance Measuring process: 1

EIA-748A, Earne d Value Management S ystem s, 2002. 2

EIA-632, Processes for Engineering a System, ANSI/EIAS-632-1998, 1999. 3 NPD 9501.3A, Earned Valu e Performan ce Management , 2002. 4

Milosevic DZ, Proje ct Management Tool box ,

John Wiley & Sons, Inc., 2003.

4-90


4.2.6 Schedule Management 1–5 4.2.6.1 Function Schedule management provides for the overall development and maintenance of a master schedule, coupled with the detail from the interrelated, lowerlevel schedules covering the overall project from start to finish. Additional benefits of this scheduling strategy include automated summarizations of project cost and schedule data, resource leveling to effectively stay within existing workforce constraints, efficient and timely reporting of project status, and more accurate impact assessments on external project interfaces .

project within cost, schedule, and performance constraints. The schedule content, format, detail, and symbology shall be established. The key discipline in this area is taking time and effort early in the schedule development process to d evelop a detailed, logi cal, network-driven schedule. This scheduling technique is mandatory for successful control of bo th in -house and contractor efforts, and it proves invaluable in keeping management focused on the right tasks and knowing the right prio rities for workforce assignments . 4.2.6.3 Responsibilities The Project Control Officer is responsible for all aspects of the schedule management process, including notifying the Project Team of when and what data are required, coordination with any project-externa l org anizations, ensuring timely project-internal review of the final product, and delivery of the final product. Other participants in this process include the: • Project Manager , who is responsible for ensuring the Project Control Officer has the facilities and workforce needed to accomplish this task. The Project Manager also acts as a customer to the Project Control Officer for this process. • Entire Project Team, which also participates in this process by providing data, supporting rationale, and recommendations for improvement.

Time and money are directly linked, andLogic combining them in analysi s proves very beneficial. networkdriven schedules should be resource-loaded in a simple and practical manner. These resource-loaded networked schedules provide a useful tool in understanding interdependencies. Schedule analysis techniques shall involve review and assessment of critical paths, logic relationships between activities, slack and reserve usage management, milestones and tasks progress against plans, and other schedule analysis criteria. This can then provide the capabilities for determining reliable cost and workforce estimates, EVM, trending for better EACs, what-if analysis for POP exercises and project workarounds, and generally better overall cost control. For contractor-supported projects, the contractor should be held to “rolli n g wave” accountability on near-term schedules. The term “rolling wave” means that there are very detailed schedules for near-term activities, specifically for the upcoming 6-month period. These schedules should be measured in inchstones, not milestones. The performer reports the budgeted valu e of the inch-stones met in a given month vs. the budge d value of those planned. Wit h this type of small, incremental planning and tracking, it is readily apparent how well the project is being executed. When the contractor reporting structure closely links schedule and cost-reporting milestones, care should be taken that the approach is not based on equal value milestone performance since this could lead to erroneous assessments. Slippages in a project schedule can be extreme ly expensive. A permanent record of all schedule changes should be documented to support trend analysis and the project assessment function.

4.2.6.4 Life cycle Schedule management is begun during Phase A and is conducted throughout the life cycle of the project. 4.2.6.5 Inputs Typical inputs to the Schedule Management process are: • WBS • WBS dictionary • Project master schedule

4.2.6.2 Objective The objective of schedule management is to provide the key in implementing an effective in tegrated man-

4.2.6.6 Steps The project effort shall be broken into tasks and milestones at a level of detail to allow for discrete progress measurement and for management visibility into the overall definition, development, fabrication, integration, test, delivery, and operational phases of a project. The project should require the responsible lead engineer, along with other key project team members, to set aside time in the early stage s of the project to review the WBS and determine associated task durations, resources required, and interdependencies. Each task should also be assessed for risk to determine the ap-

agement process for NASA projects. It is the foundation for establishing a project baseline and effective performance measurement process. The goal of sched uling is to provide a framework to time- phas e an d coordinate tasks into a master plan to complete the

propriate duration ra nge to be used in the scheduling process. All of these efforts enable better organization of the work, improved estima tes of task duration, bet ter procurement planning , and reduced risk of accidental scope omission.

4-91


A logic-driven schedule is then developed within the framework of the approved project WBS. This schedule must, by definition, contain the entire scope of the work. Each task and milestone should be horizontally integrated with the appropriate predecessor/ successor sequence relationships; they should also be vertically integrated to significant project milestones. This provid es an end-to-end logic network of resource-loaded project tasks. As the project progresses, the scheduled effort will shift to schedule stat us reporting and analys is on a regular basis so as to reflect the most current status

4.2.6.7 Outputs Typical outputs to th e Schedule Managem ent process are: • Identified tasks for each appropriate WBS item • Duration (range) for each task • Resources required for each task • Logic progression sequence of tasks (e.g., network) • Integrated, resource-loaded project schedule • Critical path analyses

of the integrated project analysis activities must also take schedule. pl ace on aSchedule re gular basi s to determine whether significant project schedule changes have occurred, such as a change in critical path. Figure 4.2-6 illustrates t he steps in the process.

Exit criteria for the Schedule Management process are: • Completed top-level project schedule throughout the life cycle

Exit criteria

Determine What Schedules Are Needed

Determine How Schedules Will Be Used (e.g., Task Planning and Oversight, Task Progress Tracking, Reporting to Upper Management, etc.)

Combine Tasks to Form Project Network

Develop Pred ecessor/Succes sor for Each Task, Through Project Completion

Define and Evaluate Risks for Each Task

Develop Risk Mitigation Actions and Add to Network

Review Critical Path to Determine if It Is Possible to Shorten

Yes

4.2.6.8

Shorten?

Determine Critical Path

No

Plan Periodic Project-Level Schedule Status Reviews

Figure 4.2 -6. Schedule management process diagram.

4-92

Determine Appropriate Schedule Management Tool

Develop Tasks (from WBS)

Determine Range of Duration for Each Task

Assign Duration Range to Each Task

Determine Current Tasks Schedule Status

Perfor Variance Analysis


• • •

4.2.6.12 References The following documents, which were used to prepare this section, offer additional insights into the Schedule Management Process:

Completed detail -level project schedu le throughout the life cycle Defined and documented schedule definition and analysis process Successful schedule trace from start milestone through completion with no breaks

1

NPD 1440.6G, NASA Records Management , 2002.

2

JPG 1440.3, JSC Files and Re cords Management Procedures , 2001.

4.2.6.9 Measurement The following table provides example base and derived measures that can be used in conjunction with executing the Schedule Management process. See discussion of Measurement on page 4 -1.

3


Base Measures

Derived Measures

# of schedules to be developed

# completed (actual vs. planned)

Priority of schedules to be developed % complete for identification and documentation of each task duration (range) for each schedule

% complete for identification and documentation of each task duration (range) for each schedule (actual vs. planned)

% complete for identification and documentation of predecessor/successor for each task for each schedule

% complete for identification and documentation of predecessor/s uccessor for each task for each schedule (actual vs. planned)

% complete for identification and documentation for required resources for each task for each schedule

% complete for identification and documentation for required resources for each task for each schedule (actual vs. planned)

Critical path analysis completion Slack/float (free and total) 4

4.2.6.10 Methods and techniques The methods and techniques that may be used in development requirements are: • Cards-on-the-w all method • Work flow diagram • Individual and group expert judgment • Start at completion and work backward • Critical path analysis techniques (program evaluation review technique (PERT), graphical evaluation review technique (GERT), critical path method (CPM), etc.) • Time-scaled arrow di agram • Critical chain schedule • Milestone charts • Hierarchical schedule • Line of balance • B-C-F [baseline-current-future] analysis • Backward pass method 4.2.6.11

Forsberg K, Mooz H, Cotterman H, Visualizing Project Management , John Wiley & Sons, Inc., 2002. 5

Dragan ZM, Project Man agement Toolbox , John Wiley & Sons, Inc., 2003.

Software tools

The following S/W tools support the Schedule Manageme nt process: • Microsoft Project Server • Microsoft Project • Microsoft PowerPoint (Gantt charts)

4-93


4.2.7 Project Analysis1,2,3 4.2.7.1 Function This section addresses the need for project leaders to perform an effective and timely analysis of project data for existing projects, proposed changes, and future projects. This analysis shall be performed to determine that the current performance analysis plan is understood and that future plans are in place to assure project success. The analysis shall also be u sed to assess proposed changes and new project pla ns. 4.2.7.2

•

•

•

Objective

• • •

objective of project analysisand is tocommunicating provide a disThe ciplined process for analyzing existing project performance measurement data to determine project progress and issues, and to assess future plans. This analysis should result in an understanding of the accuracy of the data and progress on the pro ject, project issues, and future plans to provide a basis for management action. Project analysis also provides a process for analyzing proposed changes and proposed project plans to determine whether the plans are sound and for m the basis for accepting or rejecting the proposals. Project analysis shall be done at a level in the WBS that is appropriate to the complexity or risk of the task and at the overall project level. Project analysis shall be done throughout the life cycle of the project to provide increasingly reliable data concerning the viability of future proje cts or the perfor mance on existing projects.

• • • •

•

BCWS, which is the sum of the time-phase d budgets for all efforts scheduled to be accomplished within a time period; associated with this budget is a baseline schedule that has resources assigned to it BCWP, which is the sum of the time-phase d budgets for all efforts c ompleted dur ing a specified time period ACWP, which is the cost actually incurred and recorded in accomplishing the BCWP within a given time period CV, which is BCWP-ACWP SV, which is BCWP-BCWS CPI, which is cumulative BCWP divided by cumulative ACWP SPI, which is cumulative BCWP divided by cumulative BCWS TCPI, which is BAC-cumulative BCWP divided by EAC-ACWP Actual costs for similar projects, vendor quotes, or best estimates from subject matter experts Basis of estimat e (BOE), which is th e basis for estimating new projects and changes to existing projects TPMs appropriate to the project life cycle

4.2.7.6 Steps To analyze a proposed proj ect in Pre-Phase A or Phase A, the project control officer and the team members acquire backup cost, schedule, and risk information from other similar projects or market sur-

4.2.7.3 Responsibilities The Project Control Officer is responsible for all aspects of the project analysis process, including notifying the Projec t Team of when and what data a re required, coordination with any project-external organizations, ensuring timely project-internal review of the final product, and delivery of the final product. Other participants in this process include the: • Project Manag er , who is responsible for ensuring the Project Control Officer has the facilities and workforce needed to accomplish this task. The Project Manager also acts as a customer to the Project Control Officer for this progress. • Entire Project Team, which also participates in this process by providing data, supporting rationale, and recommendations for improvement.

veys to form the basis of estimate and risk assessment. Where information is not available, subject matter experts (SMEs) can be used to provide a best engineering estimate using cost-estimating techniques appropriate for the product. SMEs can also be used to surv ey the market to assess the risk of available technolo gies to support the project. Team members and the project manager use this information to validate the proposed project cost, schedule, and risks. When assessing a vendor’s proposal, similar comparison data are acquired for purposes of reviewing both the srcinal proposal for a project and subsequent changes to that project. When a project is sufficiently defined, the work is allocated to team members or vendor managers for implementation into an integrated project baseline. The project control officer, project manager, and other appropriate SMEs review and approve the baseline. If the project is a government-furnished item, the project control officer and team members implement the base-

4.2.7.4 Life cycle Project analysis applies during the entire life cycle of a project.

line. If the project is assigned to a vendor, the vendor’s project control function and managers implement the baseline with oversight by the NASA project team. The project control officer and vendor’s project control function strictly control project baseline changes

4.2.7.5 Inputs Typical inputs to the Project Analysis process are:

4-94


to assure that no unk nown changes invalidate the baseline and subsequent data for analysis. The team members or vendor managers provide monthly status for both TPMs and EV reporting. The project control officer or vendor’s project control function takes these inputs and provides team members or vendor managers and the project manager with reports on project performance measurements for project analysis. The team m embers or vendor manager s use these reports to assess variances in cost or schedule (usually greater than ±10%) and provide corrective action plans. The project manager analyzes project-

(ACWP). SPI represents how quickly the work is accomplished (BCWP) vs. what is baselined (BCWS). TCPI represents the cost efficiency re quired to achieve the project with the budget or EAC planned. In a perfect project, all three measures are a 1.0. Seeing usual variations in these indices indicates a need to look further. For example, if the project CPI is 0.56 yet the TCPI is 1.40, the indication is that a large increase in efficiency will be needed to successfully complete the plan. TPMs are analyzed to determine whether there are technical issues or risks in trends observed. For example, a high change rate could

level indices and variance information trends. For variance analysis, CPI, SPI,for andproject TCPI provide a quick rule -o f-thumb measure for project health. CPI represents how efficiently the work is performed (BC WP) vs. th e money being spent

indicate thatphase. the project is insufficiently defined for the current Similarly, a high defect rate could indicate a process problem within the project. Figure 4.2.7 illustrates the Project Analysis process.

Analyze Proposed

Collect Data from Similar Project

Assess Proposal

Proposal Assessment

Yes

Go?

A

Project No Stop Project

Analyze Project Change

Review Technical Proposal

Determine Should Cost

Assess Cost Proposal BOEs vs. Sh ould Cost

Conduct Fact-Finding

B

B

A

Develop Integrated

Define Cost Centers (CC) (WBS +Org.)

Baseline

Allocate Requirements to CC

Negotiate Baseline Change

Authorize Change and Update Baseline/POP

Prepare Budget, Schedule, Metrics, and Risks for CC

Integrated Baseline and POP

C C

Analyze Performance Data

KEY

Collect Performance Data

Step/Activity

Produc

Analyz Variances, Issues, and Risks

Prepare Corrective Action Plans


Figure 4.2 -7. Project analysis process diagram.

4-95

Decision

ETC Update Variance Report Issues and Risks

B

Connector


4.2.7.7 Outputs Typical outputs to the Project Analysis process are: • An integrated project status and POP • ETC, which provides an updated time -phased estimate for the remaining work on the project • Variance analysis report (VAR), which provides an analysis of the problem, program impact, and corrective action plan • Risk assessment and technical performance issues • Corrective action plans

4.2.7.11 Software tools S/W tools that will support the Project Analysis process are: • Excel • Word processor • Cos t-estimating models (e.g., SEER, NAFCOM, PRICE, etc.)

4.2.7.8

4.2.7.12 References

• •

Exit criteria

Exit criteria for the Project Analysis process are: • A revised estimate that more accurately reflects project costs for the project’s entire scope • The corrective action plan in the variance analysis addresses the root cause of the technical, cost, or schedule issue • A risk assessment and abatement plan for the potential future project problems

Individual or group expert judgment EVMS

The following documents and Web site, which were used to prepare this section, offer additional insights into the Project Analysis process: 1 NPR 9501.3, Earned Valu e Management Implementation on NASA Contract , 2002. 2

EIA-748-98, Industry Guidelines for E arned Value Management Systems , 1998. 3

NASA Cost Estimating Handbook 2002 at http://www.jsc.nasa.gov/bu2/NCEH/index.htm .

4.2.7.9 Measurement The following table provides example base and derived measures that can be used in conjunction with executing the Project Analysis process. See discussion of Measurement on page 4-1. 4.2.7.10 Methods and techniques The methods and techniques that may be used in developing requirements are: • Statistical analysis of defect closure rate and • •

change rate Analysis of EV performance measurements Cost-estimating methods

Base Measures

Derived Measures

# Requirements Added, Changed, or Deleted

Requirements Volatility = % Added, Changed, or Deleted

Defects in Requirements (by Phase)

Requirements Defects – Projected vs. Actuals

Defects in Design (by Phase)

Design Defects – Projected vs. Actuals

Defects in S/W Code (by Phase)

Code Defects – Projected vs. Actuals

Issues/Actions Status

% Issues Closed

Risk Status (e.g., Open, In Work, Closed)

Projected vs. Actual Risk Status

CV

BCWP-ACWP

SV

BCWP-BCWS

CPI

Cumulative BCWP divided by Cumulative ACWP

SPI

Cumulative BCWP divided by Cumulative BCWS

TCPI

BAC-Cumulative BCWP divided by EAC-ACWP

4-96


4.3 Crosscutting Processes 4.3.1 Acquisition Management 1,2 The Acquisition Management process is performed to acquire all products, materials, or services in support of the project. Project acquisitions are performed via acquis ition instruments such as contracts, grants, cooperative agreements, or a combination of these. Component activities of the Acquisition Management process include: • Defining requirements • Formulating acquisition strategies for the project, including determining acquisition

The Project Manager is supported by the Project Acquisition Team, whose principal participants include the Project Control Officer, the Lead Systems Engineer, the Procurement Representative, the Chief Financial Officer Representative, and, as necessary, the Office of the Chief Counsel Representative. The Project Control Officer is responsible for performing the process steps outlined below. The Project Control Officer also provides the primary management inputs on needs and requirements for the prod ucts, materials, and services to be acquired in support of the project.

instruments and appropriate contract types Executing the acquisition instruments Monitoring and evaluating performance of the acquisitions The end customer for the Acquisition Management process is the project manager. Acquisition manage ment, which is a continuous process throughout the life cycle of the project, is exercised in accordance with project acquisition strategies.

LeadonSystems Engineer Theinput provides nical n eeds and requirements forprimary pro jecttechacquisitions. The Lead Systems Engineer also supports execution of the acquisition instruments by participating in the development and review of solicitations and the evaluation process for selection of suppliers. Finally, the Lead Systems Engineer supports technical monitoring and evaluation of the acquisition instruments. The Procurement Representative interfaces with the Project Control Officer and the Lead System s En gineer to solicit information in suppor t of proje ct acquisitions and provides advice both on conducting acquisitions and on acquisition regulations. The Chief Financial Officer Representative provides resource management, budget support, accounting, and financial transaction su pport for project acquis itions. Other responsibilities are outlined in JSC SLP 4.6 4 5 and JPG 5335.2.

• •

4.3.1.1 Function1,2,3 In the Acquisition Management process: • Technical requirements (e.g., detail specifications, interfaces, cost, schedule/long lead, etc.) and management requirements of the products, materials, or services being acquired shall be identified. • Acquisition strategies to acquire required products, materials, and services shall be developed. •

4.3.1.4 Life cycle 3 The Acquisition Management process is applicable to all phases of the project life cycle whenever acquisitions are required. Acquisi tion strategies are formu lated based on project needs for products, materials, or services in support of the work performed at any given life cycle phase. Acquisition strategies may range from project-level strategies – such as whether the contractor or outside organization should perform any (or all) of the project – through focu sed acqui sitions to procure products or materials to implement in-house designs. Once decisions are made to acquir e from a contractor or outside organization, support of the contract execution and performance monitoring continues until acquisition is completed.

Acquisition instruments in accordance with project acquisition strategies shall be executed. Execution of the acquisition instruments, including monitoring and performance evaluation, shall be managed. All project acquisitions are performed in accordance with the following established JSC procedures: JSC SLP 4.6, Procurement ;4 and JPG 5335.2, Space Act Agreements .5 •

4.3.1.2 Objective 1,2 The primary objective of the Acquisition Management process is to acquire all required prod ucts, ma terials, and services to enable a firm commitment t o accomplish project goals and objectives on schedule and within budget.

4.3.1.5 Inputs 3,8 Typical inputs to the process include, but are not limited to:

4.3.1.3 Responsibilities 1 The Project Manager is responsible for formulating acquisition strategies for the project. The Project Manager also makes the final decisions conce rning project acquisitions and approves any corrective actions relating to the performance of the acquisition mechanisms.

• • • •

4-97

Concepts (mission, system, operations) Goals and objectives (mission, system) Needs (mission, system) Assumptions, guidelines, and constraints, including:


Federal Acquisition Regulations (FARs) and other applicable NASA and JSC guidelines/ regulations Requirements (mission, system, interface), including: − Specifications, interfaces, design data, cost, schedule, quantities, and standards related to the item being acquired Historical data (previous NASA projects and contracts) Market/industry data Plans (project plan – project acquisition strategy) −

•

• • • •

Consider using a draft request for proposal (DRFP) to obtain industry comments on the set of acquisition requirements. − Communicate in advance with procurement support personnel to coordinate potential project procurement needs and potential procurement inst rume nts. Project acquisition strategies shall be developed and maintained. − Gather technical and management inputs and recommendations to th e project acquisi tion strategies based on judgments related to −

•

Procurement data, including: − List of appropriate acquisition types − Implementation timeline for each acquisition type

4.3.1.6 Steps 1,2,3,7 The major steps and products that are implemented by this process are illustrated in Figure 4.3.-1.

−

technology maturity, knowledge and skill base of th e civil service workforce, cost effectiveness, work complexity, existence of facilities or other infrastructure to perform the work, or other relevant considerations. Evaluate whether project components should be developed, purchased, or reused based on es-

Acquisition Requirements Definition

Manage Acquisition Executions

Acquisition Requirements

Contract Performance Evaluation and Monitoring Data

Develop and MaintainAcquisition Strategies Project Acquisition Strategies

Execute Acquisition Instruments

Contracts, Grants, or Agreements

Information in support of the next acquisition

KEY

Step/Activity


Product

Figure 4.3 -1. Acquisition management process diagram. •

Project acquisition requirements shall be defined. − Identify and document technical and management needs and requirements for the products, materials, and services that that need to be acquired to support the project. Includes, as applicable, SOWs, detailed specifications, deliverables, cost, schedule, and any other applicable documents.

−

4-98

tablished criteria and the needs of the project (i.e., Make/Buy Analysis). Identification of work products, whether externa lly or intern ally acquired, helps to establish a top -level WBS to estimate the scope of the project. Determine the acquisition type for each product to be acqui red (e.g. , contract type such as sole source, full and open competi tion or “piggyback” on existing contract, grant, cooperative agreement, or interagency


•

funds transfer) (see discussion, Section 2.8 , Project Management and Planning). − Periodically review and maintain the project acquisition strategies to account for changing project needs and updated Federal regulations. The project shall execute the acquisition instrument in accordan ce with project strat egies. − Develop solicitation and evaluation instruments to support solicitation, negotiations, and selection of the supplier (e.g., agreement, SOWs, RFPs, requests for quotes (RFQs), announcements of opportunities, evaluation

Analyze performance data vs. established criteria to assess the level of performance. − Communicate the status to the project manager. Include recommendations for corrective actions as required (see Section 4.2). NOTE: These process steps are also applicable for t he case where acquisitions are performed by adding d eliveries to an existing contract. In this case, requirements would still need to be defined; the acquisition strategy will use the existing contractual vehicle; the supplier proposal would still need to be evaluated; and performance monitoring of the task would still

criteria). Provide technical and management inputs to supplier selection based on an evaluation of the supplier’s ability to meet specified requirements and established criteria. − Support activities leading to the award of the contract or approval of agreements per established JSC procedures. The project shall manage execution of the acquisition instruments, including monitoring and performing evaluation. − Designate members of the project team to act as task monitors or contracting officer’s technical representatives (COTRs) to oversee the work performed. − Develop a surveillance strategy. Note that, for contracts, the COTR and contracting officer are responsible for determining and implementing the level and type of performance

need to be performed.

−

−

•

−

4.3.1.7 Outputs 6,7,8 Primary outputs from this process are: • Acquisition Requirements, including, as applicable, SOWs, detailed specifications, deliverables, cost, schedule, and any other applicable documents. • Acquisition strategies. • Surveillance plans. • Acquisition instruments. • Supplier performance evaluation and monitoring data. 4.3.1.8 Exit criteria 3 Closeout activities are completed for each acquisition within the project. 4.3.1.9 Measurement 7 The following table provides example base and

monitoring required after considering risk factors associated with the work to be performed. Provide the necessary performance evaluation criteria and data to monitor and evaluate the supplier’s performance.

derived measures that can be used in conjunction with the Acquisition Management process. See discussion of Management on page 4-1.

Base Measures

Derived Measures

Acquisition Requirements Definition (FTEs)

Acquisition Requirements Definition Productivity Acquisition Requirements Definition Effort – Planned vs. Actuals Acquisition Requirements Definition Rate Charts Acquisition Requirements D efinition Effort as % of Tota l Engineering Effort Planned vs. Actual Acquisition Products Acquisition Strategy Milestone Schedule – Planned vs. Actuals Contract Deliverables – Planned vs. Actual Dates

# of Products to be Acquired

Contract Deliverables Milestone Dates

Contract Deliverables Status (e.g., DRLI in development, review, approval, delivered)

Data Requirements List Items (DRLI) Delivery Status Summary – # On Time vs. # Late; % On Time Deliveries Contract Deliverables Status Summary

4-99


4.3.1.10 Methods and techniques 3,8 Several methods and techniques are available to support the Acquisition Management process. These are: • Market research. • Make/buy/reuse analysis. • Technology assessment. • Trade study. • Risk-based acquisition management.

1

NPR 7120.5B, NASA Progra m and Projec t Management Processes and Requirements , 2002. 2 NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Processes and Requirements . 3

CMMI-SE/SW/IPPD/SS V1.1, Capability Maturity Model Integration (CMMI) for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing , 2002.

4.3.1.11 Software tools Some means of capturing evaluation criteria, computations, comparison, recommendations, and

4

JSC SLP 4.6, Procurement .

5

5335.2, Space Act Agreements . INCOSE Systems Engineering Handbook , Version 2.0, 2000.

results associated with SE analyses is required. Typ ically a spreadsheet application is sufficient to capture, control, manipulate, present, and share this information. Access to historical data repositories should also be considered. Depending on the size, complexity, and amount of applicable data captured from previous projects, anywhere from standard office automation tools to large databases may be required.

6 JPG

7

EIA-632, Processes for Engi neering a System, ANSI/EIA -632-1998, 1999. 8


JMI 5150.5F, Processing of JSC Procurements Through Delivery, Acceptance and Payment Stages .

4.3.1.12 References The following documents, which were used to prepare this section, offer additional insights into the Acquisition Management process:

10

4-100

JMI 5151.5B, Management of Support Contracts .


4.3.2 Risk Managem ent 1,2 The Risk Management process is performed to identify potential problems before they occur, so that risk-handling activities may be planne d and invoked, as needed, across the life of the project in an efficient and effective manner and to mitigate adverse impacts. In the Risk Management process, the project team i s responsible for identifying, analyzing, planning, tracking, controlling, and communicating effectively the risks (and the steps being taken to handle them) both within the team and with management and stakeh olders. Risk management is a continuous, iterative process

• • • • • • • •

Fault-tree analysis (FTA) results Failure modes and effects analysis (FMEA) results Test data Expert opinion Hazard analysis Lessons learned Technical analysis Resources

4.3.2.6 Steps 1 The project team shall document the Risk Man-

with thebeultimate goal of and enabling mission success. It should a key element an integral part of project management and engineering processes.

agement process within a risk management plan, and the project manager shall approve that process. Content requirements of the risk management plan are listed in NPR 8000.4, Section 2.7.4.2. Figure 4.3-2, which appears at the top of the following page, illustrates this process. The project Risk Management process shall in clude at a minimum: (a) risk identification, (b) risk analysis , (c) risk planning, (d) risk tracking, (e) risk control, and (f) identification of process responsibilities. These are outlined as shown below. • Identify Risks − Identify all project risks, including safety, performance, schedule, and cost risks. − State the risks in terms of conditions an d consequence(s). − Capture the context of the risks; e.g., what, when, where, how, and why. − Methods such as FMEA and fault-tree a nal-

4.3.2.1 Function3 In the Risk Management process: • Continuous and iterative risk analysis that des cribes and quantifies the safety, performance, schedule, and cost risk (i.e., likelihood vs. consequences) shall be conducted. • Controls and approach, including mitigation options for identified risks, shall be documented. • Risks shall be tracked. • Risks that impact mission success, performance, cost, and schedule shall be controlled. 4.3.2.2 Objective The Risk Management process is performed to reduce the probability of adverse impacts and, as a result, maximize the probability of achieving system goals.

ysis can help to identify risks. Key areas to as sess include safet y, performance, schedule, budget, requirements, technology, management supportability, logistics and maintenance operations, and programmatic. Analyze Risks − Evaluate risks, in cluding: • Probability • Impact/severity • Timeframe (when action needs to be taken) − Classify/group similar/related risks. − Prioritize. − Methods such as probabilistic risk assessment (PRA) can help to analyze risks. Plan for Action − Assign responsibility for each risk. − Determine approach for each risk (research, −

4.3.2.3 Responsibilities The Project Control Officer has primary responsibilities in the tracking, control, and communication aspects of the Risk Management process. The Project Manager is the primary customer in that the Risk Management process supports project resource allocation decisions. All other Project Team Members are responsible for risk identification, analysis, and planning.

•

4.3.2.4 Life cycle Risk management is conducted throughout the project life cycle. A preliminary risk management plan is required at the end of Phase A, Preliminary Analysis, and an update to this plan is required by the end of Phase B, Definition.

•

4.3.2.5 Inputs 4 Inputs include the following: • Program data • Project data • Constraints

accept, mitigate, monitor).are Typical risk attributes for eachorapproach as follows: • Research – High-cost mitigation, long time to effect, uncertainty in analysis of likelihood and consequence

4-101


Project Data Risk Management Plan Lessons Learned PRA Results FTA FMEA Results Expert Opinion Constraints Test Data Other Technical Analysis Hazard Analysis

Resources Project Goals and Constraints

START Identify Risks

Statements of Risks

Analyze Risks

Risk Evaluation, Classification, and Prioritization

Plan for Action

Project Data Resources

Communication and documentation occurs throughout all of the activities

KEY

Step/A ctivity

Risk Status Reports

Track

NOTE:

Risk Mitigation Plans Risk Acceptan ce Criteri a Risk Tracking Plan

Control


nformation/Products I

Figure 4.3 -2. Risk management process diagram. Accept – Low consequence, fairly low likelihood, any timeframe, any cost • Mitigate – High-medium consequence, high and medium likelihood, near to mid term, high-medium and low cost to mitigate • Monitor – Lo w-medium likelihood, lowmedium consequence, mid and far term, high-medium and low cost to mitigate − For each risk that will be mitigated, define mitigation level (e.g., action item list or more detailed task plan) and goal, and include budget estimates. Track − Acquire/update, compile, analyze, and organize risk data. − Report results/status. − Verify and validate mitigation actions. Control − Analyze results of mitigation actions. − Decide how to proceed (re-plan, close the risk, invoke contingency plans, continue •

•

•

− −

•

Communicate and Document − Communicate essential risks status to the entire team on a regular basis. − The project manager shall report project risk status, especially a status concerning primary risks (i.e., those with both high probability and high impact/severity) to the program manager, directorate -level organization (DLO) management, and appropriate project governing management forums (e.g., directorate project management board, JSC Engineering Review Board (ERB), or JSC Project Management Council (PMC)). − Implement a system for documenting and tracking risk decisions.

4.3.2.7 Outputs The Risk Management process is perfor med over the entire life cycle of the system of interest. A preliminary risk management plan is required during Phase A, with an update required during Phase B. In addition, outputs include risk: • Statements • Evaluations • Mitigation plans • Acceptance criteria

tracking).the control decisions. Execute The project manager shall personally review the formal acceptance and closure of all project risks.

4-102


• •

4.3.2.10 Methods and techniques 1,5 Methods and techniques applicable to the Risk Management process include: • Individual or group expert judgment. • Statistical analysis of historical data. • Uncertainty analysis of cost, performance, and schedule projects (consists of building and running a probabilistic model of the system under investigation, including the chance variation inherent in real-life cost, performance, and schedule).

Tracking plans Status reports

4.3.2.8 Exit criteria Since risk management is conducted throughout the project life cycle, the overall exit criterion is the safe and orderly achievement of system of interest disposal. 4.3.2.9 Measurement The following provides exam ple b ase and de rived measures that can be used in conjunction with executing the Risk Management Measurement on page 4-1. process. See discussion of Base Measures

Derived Measures

Identify

Total # of Risks Identified Analyze

Total # of Risks of High Probability and/or High Impact (primary risks) Identified

# of Primary Risks Encountered vs. Total # of Risks Identified – % Risks Identified Rate Charts

Plan

# of Risks with Chosen Approach Research

Total # of Risks Identified vs. Total # of Risks with Chosen Approach Research – %

# of Risks with Chosen Approach Accept

Total # of Risks Identified vs. Total # of Risks with Chosen Approach Accept – %

# of Risks with Chosen Approach Monitor

Total # of Risks Identified vs. Total # of Risks with

# of Risks with Chosen Approach Mitigate

Chosen Approach Monitor – % Total # of Risks Identified vs. Total # of Risks with Total # of Mitigate – %

Total # of Mitigation Plans Developed

Mitigation Plan Development Rate Charts Total # of Mitigation Plans Developed vs. Total # of Risks Identified – % # of Mitigation Plans for Primary Risks Developed vs. Total # of Mitigation Plans Developed

Track

Total # of Risks Eliminated

Total # of Risks Eliminated vs. Total # of Risks Identified – % # of Primary Risks Eliminated vs. Total # of Risks Eliminated # of Primary Risks Eliminated vs. Total # of Primary Risks Identified Risk Elimination Rate Charts

Overall Process Risk Management Effort (FTEs)

Risk Management Productivity Risk Management Effort – Planned vs. Actuals Risk Managemen t Effort as % of Total Engineering Effort

4-103


•

• • • •

College, Second Edition, 1999. This document can be downloaded from: http://www.dsmc.dsm.mil/pubs/pubsgen.htm

PRA (also known as probabilistic safety assessment (PSA) and quantitative risk assessment (QRA)). FTA and FMEA. Ordinal risk scales. Comparison to analogous systems. Risk assessment matrix.

9 SSP 51079, Inter national Space Station Program Risk Management Plan , Revision A, 2002. Information on: • Risks associated with computer systems can be found in the National Institute of Standards and Technology (NIST) publication: SP 800-12, An Introduction to Computer Security: the NIST Handbook , available at http://csrc.nist.gov/publications/nistpubs/800-12/ .

4.3.2.11 Software tools Principal considerations for a S/W tool that would support the Risk Management process are the co nsistent, concise, and thorough documentation both of the

•

risk characterization (proba bility and impact) and of the mitigation progress of each risk. Common and convenient accessibility and visibility to all project team members and stakeholders is also a primary consideration. The Integrated Risk Management Application (IRMA) is a custom-built databa se tool that is used by the International Space Station Program. JSC projects should consider use of this already existing tool as their risk management application. A plan is being considered for adopting IRMA NASA-wide to support unifying the risk management effort across the Agency.

•

4.3.2.12 References The following documents and Web sites, which were used to prepare this section, offer additional insights into the Risk Management process: 1 NPR 8000.4, Risk Manag ement Proce dures and Guidelines , 2002. 2 CMMI-SE/SW/IPPD/SS V1.1, Capability Maturity Model Integration (CMMI) for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing , 2002. 3 NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Processes and Requirements. 4 NPR 7120.5B, NASA Progra m and Projec t Management Pro cesses and Requirements , 2002. 5 RP 1358, Systems Engineering “Toolbox” for Design-Oriented Engineers , 1994. 6 Probabilistic Risk Assessment Procedures Guide for NASA Managers and Practitioners, Version 1.1, http://www.hq.nasa.gov/office/doeq/doctree/pragui de.pdf 7

NTIS AD-319533KKG, DTIC#:AD-A319 533\6\XAB, Continuous Risk Management Guidebook , Software Engineering Institute at Carnegie Mellon University, 1996. 8 The Department of Defense, Risk Manag ement Guide for DoD Acquisition . Defense Acquisition University and Defense Systems Management

4-104

Implementation of risk-based acquisition management (R-BAM) can be found at http://www.grc.nasa.gov/WWW/spaceiso/rbam/ . The Continuous Risk Management process may be found at http:///www.srqa.jsc.nasa.gov/r iskmgmt/.


4.3.3 Configuration Management 1,2 Configuration management (CM) is performed on projects to establish and maintain the integrity of a system of interest’s products and controlling project baselines using configuration planning, configuration identification, configuration control, configuration status accounting, and configuration verification. The requirements on the part of the SE and project control efforts are to provide technical support to the overall project CM established by the project manager per NPG 7120.5B.3

nical baseline and for ensuring that it is consist ent with the costs and schedules in t he business baseline. The Project Manager is responsible for establishing a Configuration Management process for the project, including a Configuration Control Board (CCB) or equivalent. The Project Control Officer conceives, implements, and manages t he CM system, and documents it in a CM plan; acts as secretary of the project CCB (controls the change review process); controls baseline changes and releases; and initiates and acts on the results of configuration verification activities, including audits.

1

4.3.3.1 Function Management process: In the Configuration • The project’s overall plan and process for achieving CM shall be developed. • The work products that are to be placed unde r configuration control shall be identified. • The configuration of selected work products that compose the baselines at given points in time shall be identified. • The control and communication of changes to configuration items (C Is) shall be cond ucted. • Status accounting and current configuration data for configuration-controlled items shall be provided. • Configuration verification shall be supported. 4.3.3.2 Objective The primary objective of the SE and project control Configuration Management process is to assure that the physical configuration of a product is adequately identified, documented, and controlled to a product level of detail sufficient to repeatedly produce that and meet anticipated needs for operation, quality management, maintenance, repair, and replacement.

Assurance Engineer The Quality supports the configuration audits to evaluate the evolution of a product to ensure compliance to specifications, policies, and agreements. The Engineering Disciplines support configuration identification for their specific areas, are extensive users of the CM system, and rely on configuration status accounting to manage their CIs and request the proper baselines. The Engineering Disciplines also support the Configuration Manager and the Quality Assurance Engineer with applicable configuration audits. 4.3.3.4 Life cycle The Configuration Management process is concerned with all system of interest products and everything that describes those products from their name to their requirements and documentation. Therefore, CM begins d uring the preliminary analysis phase and continues throughout the life cycle of the system of interest. A CM plan is developed during the preliminary analysis phase. 4.3.3.5 Inputs Typical inputs to the Configuration Management process consist primarily of pro duct baselines an d CRs to baselines. Examples of these inputs and their associated life cycle phase are as follows:

4.3.3.3 Responsibilities 2 The Lead Systems Engineer is responsible for ensuring the completeness and technical integrity of the techLife Cycle Phase

CM Process Input

Preliminary Analysis Definition

Operations Concept System/Subsystem Requirements Interface Requirements Specification Architectural Design Interface Design Test Plan and Procedures Operational and Support Manuals Training Materials

Design

Operations Termination

Product Delivery Technical Performance Data Lessons Learned Disposal Plan

4-105


4.3.3.6 Steps 4 The following diagram ( FIG. 4.3-3) illustrates the major steps and products of the SE Configuration Management process. Adhering to the major st eps of this process directs the project toward meeting its CM re quirements. For each major process step, additional guidance is provided as to the typical sub-process steps and products that are expected.

Perform CM Planning

•

Identification Steps − Identify CIs and Baselines – CIs that will be plac ed und er CM shall be identified. Typical items placed under CM control include plans, processes, designs, drawings, requirements, products, tools, technical baselines, change control forms, and program documentation.

Perform Configuration Audits

Identify CIs

Establish CM Records

and Baselines Audit Results

CM P lans and Processes

Configuration Reports

Project CI and Baseline Definitions

Establish CM Systems

Manage CRs

CM Systems

Change Control Forms

Control CIs

Release Baselines

CI Baselines


KEY

Step/Activity

Produc

Figure 4.3 -3. Configuration management process diagram. •

Planning Steps − Perform CM Planning – A plan for performing CM on the project shall be defined. • Develop the project’s overall plan for achieving CM and include as part of the SEMP and PMP, as applicable. • Define the project’s CM roles and responsibilities. • Develop the appropriate CM policies, processes, procedures, and guidelines required to meet the project’s CM plan. • Provide the project manager with cost and schedule inputs related to CM life cycle activities in support of the project planning effort. •

•

• •

•

Ensure that at leas t a top -level/partial version of the CM plan is available at Mission Definition Review (MDR), and a final/approved version is available at System Design Review (SDR).

• •

4-106

Select the CIs and the work products that compose the CIs based on documented criteria. Assign unique identifiers to CIs using a predetermined method. Specify important characteristics of each CI (e.g., author, document or file type, publication date or version identifier, and programming language for S/W code files). Specify when each CI is placed under CM. Example criteria for determining when to place work products under CM include the stage of the project life cycle, when the work product is ready for test, degree of control desired on the work product, cost and schedule limitations , and customer requirements. Identify the owner responsible for each CI. Identify CI baselines that may be used for internal use and for delivery to the customer.


−

Establish a CM System – A CM system, including a change management process for controlling work products, shall be established and maintained. • Establish a mechanism to manage multiple control levels of CM; e.g., mechanisms for managing the differences in the levels of control needed at different times in the project life cycle, differences in the levels of control needed for different types of systems, and differences in the levels of control needed to satisfy privacy

−

and security requirements forCM the CIs. Create CM reports from the system. Preserve the contents of the CM system (i.e., backup, archiving, and recovery functions). Control Steps − Manage CRs – CRs to CIs shall be tracked. • Initiate and record CRs in the CR repository. − Problem/change report − Specification change notice − Engineering change proposal − Request for deviation/waiver • Analyze the impact of changes and fixes proposed in the CRs. • Review CRs that will be addressed in t he next baseline with those organizations that will be affected by the changes and get their ag reement. •

•

• −

•

Track the status of CRs to closure. Control CIs – Changes to CIs, throu ghout the life of the product, shall be controlled. Configuration control maintains the integrity of the CIs identified by facilitating approved changes and prevents the incorporation of unapproved changes into the baseline. • Verify appropriate authorization was obtained before changed CIs are entered into the CM system. Authorization may be in the form of approval from a projectestablished CCB. • Check in and check out CIs from the CM system for incorporation of changes in a manner that maintains the correctness and ingenuity of the CIs. • Perform reviews to ensure that changes have not caused unintended effects on the baselines (e.g., ensure tha t changes have

•

in the CM system. Document the set of CIs that is contained in a baseline. • Make the current set of baselines readily available. Status Steps − Establish CM Records – Records des cribing CIs shall be established and maintained. • Record CM actions in sufficient detail so hat t the content and status of each CI is known and previous versions can be recovered. • Ensure that relevant stakeholders have access to and knowledge of the configuration status of the CIs. • Specify the latest version of the baselines . • Identify the version of the CIs that constitute a particular baseline. • Describe the differences between successive baselines. •

•

•

Release Baselines – Baselines for internal use and for delivery to the customer shal l be released. Release of a baseline involves approving a set of configuration data for the agreed-on set of CIs from the CM systems and releasing the baseline for further development. Multiple baselines may be used to define an evolving product during its development cycle. • Obtain authorization from the CCB before creating or releasing baselines of CIs. • Create or release baselines only from CIs

•

Revise the status and history (i.e., changes and other actions) of each CI, as necessary. Audit Steps − Perform Configuration Verification – Configuration audits to maintain integrity of the configuration baselines and ensure process integrity shall be supported. • Assess the integrity of the baselines. • Confirm that the configuration records correctly identify the configuration of the CIs. • Review the structure and integrity of the items in the CM system. • Confirm the completeness and correctness of the items in the CM system. • Confirm compliance with applicable CM standards and procedures. • Track action items from audit to closure.

4.3.3.7 Outputs 4 Primary outputs from this process are: • CM plans/processes/CM procedure(s) • CM system

not compromised the safety a nd/or security of the system). Record changes to CIs and the reasons for the changes, as appropriate.

4-107


• • • • •

lead to changes in formal baselines and internally controlled items. The following examples provide an organized approach to change tracking: • Problem/Change Report – To document p roblems and re commend enhancements to CIs or complementary documentation. Can be used to identify problems during design, development, integration, test, and operations. • Specification Change Notice – To propose, transmit, and record changes to baselined specifications. • Engineering Change P roposal – To pr opose changes to the customer. This proposal describes

Project CIs CI baselines Change control forms configuration reports Configuration audit results

4.3.3.8 Exit criteria Since CM is an ongoing function throughout the system of interest life cycle until retirement, there are no specific exit criteria. However, there are some items that are required to move from one life cycle phase to the next. Some examples of the se are: • • • • •

Released and approved CM plan or updated version Established list of project CIs Implemented CM system containing the identified CIs Established and controlled CI baselines Published configuration audit results

•

4.3.3.9 Measurement The following table provides example base and derived measures that can be used in conjunction with the Configuration Management process. See discussion of Measurement on page 4-1.

the advantages andasdisadvantages of the proposed change as well available alternatives and the schedule and funding needed to proceed. Request for Deviation/Waiver – To request and docu ment temporary deviations from config uration identification requirements when permanent changes to provide conformity to an established baseline are not acceptable.

4.3.3.11 Software tools Suggested tools are: • A database management system to capture and control CIs; to identify, control, and release baselines; and to provide status accounting reports.

Base Measures

Derived Measures

# of CIs and Associated Size (or complexity)

CI Content – Planned vs. Actuals

CI Status

CI Status Summary (monthly as a minimum)

CR Status (classifications include change, problem, deviation, waiver)

CR Status Summary – # Open, Approved, Rejected, InProcess, Closed, Common Reason for Change

Effort for CM (FTEs)

CM Effort – Planned vs. Actuals CM Effort as % Total Engineering Effort

CM Activity Status

CM Activities Status Summary

CM Records Status

CM Records Status Summary CM Effort – Planned vs. Actuals; per CR Type; per Life Cycle Phase CM Rate Charts – Change Rate, Change Process, Cycle Time CM Effort as % Total Engineering Effort •

4.3.3.10 Methods and techniques Several methods and techniques , such as general auditing techniques, are available. Additional process

•

tools and techniques are (ISO) listed SLP in JSC International Process Standards Organization 4.20, Measurement and Improvement .5 Also, change control forms provide a standard method of reporting problems and enhancements that

4-108

Standard office automation products to create standardized change control forms and audit reports. A workflow system to handle CR tracking and approval.


4.3.3.12 References The following documents, which were used to prepare this section, offer additional insights into the Configuration Management process: 1 NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Processes and Requirements . 2


NPR 7120.5B, NASA Progra m and Projec t Management Pro cesses and Requirements , 2002. 4

Capability CMMI-SE/SW/IPPD/SS V1.1, Maturity Model Integration (CMMI) for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing , 2002. 5

SLP 4.20,Process Measurement and Improvement .

6


EIA-632, Processes for Engineering a System, 1999.

4-109


4.3.4 Quality Management 1–6 The Quality Management process is performed to assure the use and integration of high standards of quality within the PM effort to reduce technical risk. This process addresses the quality of the processes that are being used to create the system of interest. High-quality products can only be produ ced, on a continuous basis, if a process exists to continuously measure and improve the quality of processe s used to produce the system of interest products. This process emphasizes establishment of goals and subsequent measurements, analysis, and implementation of cor-

•

Continuous improvement and lessons learned within the procedures and processes shall be incorporated.

4.3.4.2 Objective 2,7 The objective of this process is to identify and establish processes and procedures to manage and design the system, to measure process performance, and to perform continuous improvement of the processes based on objective data. Not only is qual ity expected of the sys tem of interest as it matures but the processes used to build in quality are under continu-

rective to attain thoseorgoals. The are intent of quality actions is to ensure products services offered that meet defined needs, satisfy stakeholders’ expectations, and comply with appli cable standards and proc edur es. The Quality Management process involves (1) objectively evaluating performed processes, work products, and services against applicable process descriptions, standards, and procedures; (2) identifying and documenting noncomp liance issues; (3) ensuring that noncompliance issues are addressed; (4) capturing, reporting, and reviewin g lessons learned; and (5) pro viding feedback to project staff and managers on the results of quality activities. This process supports the delivery of high-quality products by providing project staff and managers at all l evels with appropriate visi bility into, and feedback on, processes and associated work products throughout the life of the project. NASA and JSC policies, procedures, and guidelines 7 8 4 (ref. NPD 1280.1, JPD 5335.1, and JPG 5335.3 ) establish organizational and project expectations to objectively evaluate processes and products. These e xpectations encompass assurances that (1) customer requirements are determined, maintained, and s atisfied; (2) products and services are planned, developed under controlled conditions, measured, reviewed, and improved; and (3) processes and their interactions used to provide products and services are planned, measured, reviewe d, and improved. This Quality Management process provides a mechanism for implementing many of these policies, procedures, and guidelines. See Section 4.1.11 for details on quality assurance (QA) activities.

ous for effectiveness, value to stakeholders, and review improvement opportunities. 4.3.4.3 Responsibilities 9 It is the responsibility of the Project Manager to ensure that project planning documents include welldefined, quality-related processes and strategies that will be followed by the project team and that are in accordance with the JSC Quality Management System.4 The Project Manager and the Lead Systems Engineer need to have confidence t hat the system of in terest produced and delivered is in accordance with its functional, performance, and design requirements. The Project Control Officer is responsible for implementing the Quality Management process for the project with technical support from the Lead Systems Engineer. 4.3.4.4 Life cycle The Quality Management process is pervasive throughout the project life cycle. Quality Management process expectations begin at proj ect conception and are applied increasingly as the system of interest matures through design, development, integration, test, deployment, operation, and disposal. During the early stages of the life cycle, the focus is on ensuring that the quality management system policy is being properly applied; i.e., appropriate processes and procedures are established based on the needs of the project. As the project matures, the emphasis shifts to assessments of process applications; i.e., are the processes being executed as described, and are the work products being produced in accordance with requirements and specifications.

4.3.4.1 Function1 In the Quality Management process: • Reliable and repetitive procedures and processes shall be identified and established. • Established procedures and processes shall be used to manage the project and design of the system. • The quality process shall ensure that system of interest products meet the design (i.e., “as-built” meets the “as designed”) and the records of compliance are maintained.

4.3.4.5 Inputs The following are typical inputs to the Quality Manageme nt process: • Project plans • Center processes, standards, and work instructions • Process tailoring guidelines

4-110


4.3.4.6 Steps 3,10,11 The following diagram ( FIG. 4.3-4) illustrates the major steps of the Quality Management process. Details of these steps are provided below. Apply Processes and Practices

Review Lessons Learned

Evaluate Process Performances

A

Projec Processes

Evaluate Work Products

A

Work Products

Ensure Resolution of Noncompliance Issues

Establish Records

KEY

Identify Applicable Processes

Select Processes for Evaluation

Select Work Products for Evaluation

to process owners any particular strengths or weaknesses of the selected processes.

Tailor Processes

Project Processes

Establish and Maintain Process Evaluation Criteria

Select Process Measures

Monitor Processes

Evaluate Selected Processes

Establish and Maintain Work Product Evaluation Criteria

Select Product Measures

Monitor Work Products

Evaluate Selected Work Products

B

Resolve Noncompliance Issues

Document Escalate Unresolved Unresolved Issues Issues

C

Capture Lessons Learned

Lessons Learned

Step/Activity

Identify Lessons Learned

A

Product

Analyze Trends

Infor Relevant Stakeholders

Record Activities


C


C

B

C

B


Review Open Issues

Revise Status

B

Track Noncompliance Issues

Quality Process Status Report

Connector

Figure 4.3 -4. Quality management process diagram. •

•

Apply Processes and Practices – All projectrelated processes and practices shall be properly established and tailored as required, and addressed in the project plan and associated project documentation. Review Lessons Learned – Review lesso ns learned to establish an awareness of issues and problems previously identified. − Identify Applicable Processes – Determ ine which JSC processes are applicable to the project. − Tailor Processes for the Project – Tailor identified processes to meet specific needs of the project. − Identify Lessons Learned – Identify and capture lessons learned and best practices that could improve future projects and their processes. In particular, identify and report

•

4-111

Evaluate Process Performance – Performed processes shall be objectively evaluated again st applicable process descriptions, standards, and procedu res. − Select Processes for Evaluation – Identify the processes that will be evaluated based on criticality of the process to meet project needs. − Establish and Maintain Process Evaluation Criteria – Establish and maintain clearly stated criteria for process evaluations to determine appropriate levels of process performance based on proje ct needs. − Select Process Measures – Select a set of measurements that supports the evaluation criteria (see Section 4.2.5, Performance Measurement). − Monitor Process Performance and Collect Process Measures


Evaluate Selected Processes – Use the stated criteria to evaluate performed processes. − Identify Lessons Learned – Identify and capture lessons learned and best practices that could improve future projects and their processes. Evaluate Work prod ucts – Work products and services shall be objectively evaluated against the applicable product descriptions, standards, and procedures. − Select Work Products for Evaluation – Identify work products to be evaluated based −

•

−

−

−

−

−

−

−

on documented sampling criteria, if sampling is used. Establish and Maintain Work Product Evaluation Criteria – Clearly state criteria by which to evaluate work products. The intent is to provide criteri a based on project needs such as: • What will be assessed during the evaluation of a work product? • When or how often will a work product be evaluate d? • How will the evaluation be conducted? • Who must be involved in the evaluation? Select Product Measures – Select a set of measurements that supports the evaluation criteria (see Section 4.2.5, Performance Measurement). Monitor the Development of Work Products and Collect Product Measures

−

−

−

•

Evaluate Work Products – Evaluate work prod ucts b y: • Using the standard criteria during evaluations of work products. • Evaluating work products before they are delivered to the customer. • Evaluating work products at selected milestones in their development. • Performing in-progress or incremental evaluations of work products and services against pro cess descriptions, standards, and procedures. • Identifying each case of noncompliance found during the evaluations. − Identify Lessons Learned – Identify and capture lessons learned and best practices that could improve future projects and their work products . Ensure Resolution of Noncompliance Issues – Quality issues and resolution of noncompliance issues shall be communicated with project staff and management, regardless of whether issues are process or work product related.

•

Resolve Noncompliance Issues – Resolve each noncompliance issue with the appro priate members of the project where possible. Document Unresolved Issues – Document noncompliance issues when they cannot be resolved within the project. Escalate Unresolved Issues – Escalate noncompliance issues that cannot be resolve d within the project to the appropriate level of management. Analyze Trends – Analyze nonconformance issues to see if there are any quality trends that can be identified and addressed. Identify whether nonconformance issues are caused by nonco mpliance with established processes or by process deficiencies. Inform Relevant Stakeholders – Ens ure that relevant stakeholders are aware of the results of the evaluations and the quality trends. Communicate process deficiencies or improvement opportunities to the process owner so that they are addressed as part of continuous process improvement. The process owner can be at the project, directorate, or Center level. Examples of Center-level process own ers include the JSC Systems Engineering Working Group (J-SEWG), the Software Engineering Process Group (SEPG), and the Project Management Working Group (PMWG). Review Open Noncompliance Issues – Periodically review open noncompliance

issues and trends withand the act manager who is designated to receive on noncompliance issues. − Track Noncompliance Issues – Track noncompliance issues to resolution. Establish Records – Quality records shall be established and maintained. − Capture Lessons Learned – Record lessons learned that were identified in previous steps in this process. Ensure lessons learned are available for review. Report lessons learned, as required. − Record Activities – Record process and product quality management activities in sufficient detail such that status and results are known. − Revise Status – Revise status and history of the quality management activities, as necessary.

4.3.4.7

Outputs 2,3

Outputs of the Quality Management process are: Project-specific processes and work instructions. • Process and work product evaluation criteria. • Process and work product evaluation reports. •

4-112


• • • •

Lessons learned, best practices, and improvement opportunities. Trouble/noncompliance reports. Corrective action reports. Quality trends.

• • • • •

2

4.3.4.8 Exit criteria Quality management is an ongoing process that is never actually completed until project termination. However, throughout the project life cycle the following criteria shall be evident: • Corrective action identification and mitigation • •

4.3.4.12 References The following documents, which were used to prepare this section, offer additional insights into the Quality Management process: 1

NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Processes and Require-

ments . 2 EIA-731.1, Systems Engineering Capability Model , 2002.

plan s Lessons learned identification, capture, and dissemination Improvement opportunity identification, capture, and dissemination

3

CMMI-SE/SW/IPPD/SS V1.1, Capability Matu rity Model Integration (CMMI) for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing , 2002.

4.3.4.9 Measurement The following table provides example base and derived measures that can be used in conjunction with executing the Quality Management process. See discussion of Measurement on page 4-1. Base Measures

Cause analysis tools Analysis tools Mathematical modeling tools Process illustration and simulation tools Process checklists

4 JPG 5335.3, JSC Quality Management System Quality Manual , 2003.

Derived Measures

Tailoring Report Completion

Planned vs. Actual Tailoring Dates

# of Processes Tailored (i.e., modified or tailored out)

% Process Compliance

# of Process Assessments

Planned vs. Actual Process Assessments

# of Corrective Actions (e.g., discrepancy reports)

# of Corrective Action Items vs. # of Corrective Actions Resolved

% Processes Modified or Tailored Out

# of Days Past Due for Corrective Action 5

4.3.4.10 Methods and techniques 2 The following are typical methods and techniques used in quality management: • Cause and effects diagram • Trend analysis • Pareto analysis • Fishbone (Ishikawa) diagrams • Process maps and models • Process simulations • Surveys, assessments, and audits 4.3.4.11

NPR 7120.5B, NASA P rogr am and Project Management Processes and Requirements , 2002. 6 ISO 9001:2000, Quality Management Systems – Requir ements , 2000. 7

NPD 1280.1, NASA Management System Policy , 2003. (NOTE : This NPD cancelled NPD 8730.3, NASA Quality Management System Policy .) 8

JPD 5335.1, JSC Quality Policy , 2003.

9


Software tools2

Typical S/W tools used in the Quality Management process are analysis, simulation, and modeling tools as well as standard office products such as spreadsheets, work processors, and databases. Many of these tools fall into the following categories:

INCOSE Systems Engineering Handbook ,

Version 11

2.0, 2000. AG-CWI-001, JSC Lessons Learned Process .

4-113

JSC Project Management: System Engineering & Project Control Processes & Requirements

A p p e n d ic e s

Appendix A

Appendix A – Project Management Plan Content Requirements 1 A.1 Title Page Includes, at a minimum, signatures of: • Center Director or chair, directorate-level board if delegated • Program manager (if project is in support of a program) • Project manager • S&MA organization A.2

management tools to support management in planning and controlling the project. Describe any use of special boards and committees. Address any requirement for a NASA Resident Office, including duties and authority. A.7 Project Requirements Document the project requirements, including performance requirements and success criteria, as a flowdown from the program requirements. This includes allocation of these requirements and success criteria among the systems to be developed, bo th hardware (H/W) and software (S/W).

Introduction

The project is identified by an officially approved title, a NASA program, a program commitment agreement (PCA), and/or unique project number. A brief general history and summary are given, including the project’s purpose, goals, overall approach, and time frame. For multiple NASA center projects, describe the NASA center’s project in relationship to the other participating NASA centers.

A.8 Technical Summary Present a technical description of the project. This includes the systems to be developed (H/W and S/W), use of the international system of units (SI) measurement system, facilities, flight plans, operations and logistics concepts, and planned mission results analysis and reporting. The technical summa ry inclu des the following: • System(s) • System operations concept • System constraints • Ground systems and support • Facilities • Mission results analysis and reporting • End of life cycle

A.3 Objectives State the specific project objectives, the performance goals, and t heir relationship to the program objectives and goals. Performance goals should be expressed in an objective, quantifiable, and measurable form. A.4 Customer Definition and Advocacy State the main customers of the project (e.g., principal investigator (PI), science community, technology community, public, education community, program and Enterprise sponsor) and the process to be used to ensure customer advocacy.

A.9 Logistics Describe the project logistics requirements; e.g., spares, shipping and simulators, handling equipment, transportation, user manuals, training and training materials, and supporting personnel.

A.5 Project Authorit y Identify the center where the project manager resides and ot her center responsibilities, and the Governing Project Management Council (GPMC) responsible for oversight of the project. Provide a chain of accountability an d decision path that outlines the roles and responsibilities of the project manager, program manger, Center Director, and other authorities as required.

A.10 Schedules Document the project master schedule for all major events, independent reviews, and other activities throughout the life cycle of the project. Include approval dates for principal project documentation, life cycle transitions, major reviews, program -controlled milestones, and significant contractor milestones. Identify lower-level schedules to be developed and maintained. A.11 Resources The following resources are to be addressed: a. Funding Requirem ents – Present a funding requirements chart that includes the same elements as for the acquisition summary. Indicate the new obligation authority (NOA) in r eal-year dollars for the prior, curren t, and remaining fis cal years. The displayed detail should cover major elements of cost (typically reflecting at least at the second level of the work breakdown structure (WBS) or its equivalent).

A.6 Management Describe the project management structure, including organization and responsibilities, its integration into the program management structure, and NASA center participat ion. Identify all significant interfaces with other contributing organizations. Identify specific 1 NPR 7120.5B, NASA Program and Project Management Processes and Requirements, 2002.

A-1


b. Institutional Requirements – Present institutional requirements (use of or development of facilities, workforce) for the entire project throughout its life cycle. Include civil service workforc e require ments on the providing organizations for the prior (e.g., actuals), current, and remaining years. A.12 Controls All technical performance, cost, or schedule parameters specified as requiring approval by the Administrator, the Enterprise Associate Administrator (EAA), Center Director, program manager, or appropriate controlling authority should be identified. Examples include funding by year, success criteria, program requirements, project objectives, management structure, and major program/project documentation. Identify the thresholds associated with each parameter that could cause a change request. Describe the process by which project requirements are validated for compliance with program requirements. Describe the pro cess for controlling changes to these r equirements. A.13 Implementation Approach The implementation approach of the project is provided (e.g., in -house, NASA cen ter, contractor prime) as well as a project WBS as follows: • Implementation approach • Project summary WBS (tied to the higher-leve l project or program) • WBS dictionary A.14 Acquisition Summary Provide summary information on procurement items, such as element (engineering design study, H/W and S/W development, mission and data o perations support); type of procurement (competitive, Announcement of Opportunity (AO) for instruments ); type of contract (cost-reimbursable, fixed-price); source (institutional, contractor, other government organizations); procuring activity; and surveillance. A.15 Program/Project Dependencies Other NASA, U.S . agency, and international activ ities, studies, a nd agreements are summarized with emphasis on their effect on the program as follows: • Related activities and studies; e.g., space communications, launch services, crosscuttingtechnology • Related non-NASA activities and studies A.16 Agreements List all agreements necessary for project success and the projected dates of approval. Include all agreements concluded with the authority of the project manager and reference agreements concluded with the authority of the program manager and above as listed below:

• •

NASA agree ments; e .g., space communications, launch services Non-NASA agreements − Domestic − International

A.17 Safety and Mission Success Safety and mission success planning is developed either as a section of this project plan or as a separat e document. Address the activities and steps to be taken to ensure the safety of the public, the NASA astronauts and pilots, the NASA workforce, and NASA’s highvalue equipment and property. bothall H/W and S/W aspects of the project, Address and identify act ivities; e.g., safety, reliability, maintainabilit y, quality assurance, and environmental- related desig n and test, including orbital debris mitigation, project surveillance, and failure reporting/resolution that are used to ensure the success and safe ty of the mission. A.18 Risk Managem ent Summarize the risk management approach to be used for the project, including appropriate project de-scope plans. Also identify primary risks consistent with NPR 7120.5B, paragraph 4.3.2d. A risk management plan is also developed and includes the content shown in NPR 8000.4, Risk Management Procedures and Guidelines. A.19 Environmental Impact Identify the documentation and schedule of events associated with environmental compliance conside rations (NEPA and otherrequirements). This may include environmental assessment (EA) or an environmental impact statement (see NPR 7120.5B, paragraph 4.6.5). A.20 Test and Verification Describe the project approach to test and verification for assurance of project success. This should address requirem ents for H/W and S/W verificatio n and validation, as well as S/W independent verification and validation per NPD 8730.4, NASA Software In dependent Verification and Validation (IV&V) Policy . A.21 Technology Assessment Identify the NASA crosscutting or oth er technology thrusts to be used by the project. Identify the technologies the project expects to mature during the life of the program. Briefly describe how these technologies will be developed and infused. Describe how and when the project will evaluate the feasibility, readiness, cost, risk, and benefits of the new technologies. A.22 Commercialization Identify near-term opportunities for commercializa tion. Describe the methods to be used to identify additional opportunities throughout the project life cycle.

A-2

Appendix A

A.23 Reviews Provide the names, purposes, content, and timing of all reviews. Explain the reporting requirements for program and proje ct reviews. A.24 Termination Review Criteria Provide the technical, scientific, schedule, cost, and other threshold criteria that will be used to initiate a termination review. A.25 Tailoring Identify those requirements for which the approach to compliance has tailored consistentvisibility, with project characteristics suchbeen as scope, complexity, cost, safety, and acceptable risk. Provide the rationale for such tailoring. A.26 Change Log Changes to the project plan should be documented in a change log.

A-3

Appendix B

Appendix B – Systems Engineering Management Plan Outline The Systems Engineering Management Plan (SEMP) is the top-level, integrated planning document for managing the technical effort. The SEMP defines how the project will be organized, structured, and conducted, and how the total engineering process will be controlled to provide a product that sa tisfies customer requirements. The SEMP should incorporate what t he project nee ds to do to ac complish the technical efforts, describing how the efforts will be carried out, who will accomplish them, how

•

they will be controlled, and how technology will be transitioned from the technology base to systemofinterest products. This appendix provides a preferred outline for an SEMP. This outline is presented as an aid to the user of this Johnson Space Center (JSC) Procedures and Guidelines (JPG). The user may tailor the actual content of the SEMP.

•

•

• •

•

•

B.1

Description of the System of Interest Describe the: a. System of interest structure to include the produ cts (subsystems or system elements) that will make up the system of interest and also the enabling systems that will be related to the system of interest over its life. b. Describe the key technical objectives and expected deliverables applicable to the systems engineering (SE) effort based on the entry and exit criteria of the applicable system life cycle stage.

• •

What work will be done in executing the process . Who has overall responsibility for the success of the process, and who provides support in the execution of the process. Who will do the work, when will the work be done, and where will the work be done. The specific inputs required to conduct the process, including dependencies among work efforts such as what information will be needed to perform the work, where the work will come from, and when the work will be needed. The actual steps to be followed and their sequence of occurrence. Indicate any deviations from the recommended approach. The expected products and outcomes to be produced in the execution of the process, including tracking with respect to who will use and/or require the results. Any measurements to be used in tracking and managing the execution of the process. How exit criteria will be satisfied. Any specific methods, techniques, and tools to be use d to conduct the process.

B.3

Software Development (can refer to a standalone plan if one is applicable) Software development entails describing: a. The processes and tasks to be completed for developing software (S/W) products. b. Methods and tools that are used to accomplish S/W development processes and/or tasks. c. Any special organizational approaches to ensure that efficient use of embedded or standalone computer and S/W products will be accomplished in the SE efforts related to the system-of-interest structure.

B.2

Description of the Technical Processes For each system of interest, describe implementation of the following technical process from Section 4 of this JPG: • Requirements development • Requirements management • Operations concept development • Decomposition • Feasibility study • Technology planning • Design • Attainment • Integration • Systems analysis

B.4

Project Technical Management Processes The project technical management process involves the following: a. Describe how each of the following technical management processes from Section 4 of this JPG is used to support the technical work defined in Section B.2 above: • Acquisition management • Technical work and resource management • Risk management

•

• •

Verification Validation For each process describe: •

•

B-1

Configuration management (CM) Safety and mission success Control


b. Describe any gaps in skills and/or knowledge of the existing workforce, and identify and describe training that will be accomplished to provide needed skills and/or knowledge. c. Explain how personnel will be assigned to teams to ensure that integrated, multi-disciplinary teamwork will be accomplished to define, design, and realize required products.

Quality management Reviews b. Describe the hooks/relationships to NASA NPR 7120.5 and other such management policy guidance documents. c. Provide reference, as appropriate, to each standalone pla n that provides more com plete descriptions of processes such as cost and schedule control, risk management, logistics support, CM, interface management, quality assurance (QA), requirements management, change management, and information management. • •

B.6

Other Systems Engineering Concerns Other SE concerns include: •

B.5 Organization (Team) Structure For the organization structure: a. Describe the special skills and expertise required to provide members to teams involved with engineering the system of interest.

• • • •

B-2

Budget Schedule Planned technology transitions Long lead items Other considerations for support required from the project or customer

Appendix C – Trace of Project Management Processes to Life Cycle

C-1

Appendix D

Appendix D – Project Tailoring Guidelines The basic requirements expected from a Johnson Space Center (JSC) project are detailed in this document. However, because of the wide variety and size of projects, it may be necessary to allow some form of tailoring. This is acceptable as an effort to optimize the project processes and requirements and to encourage development of innovative practices. The project should assess a wide variety of factors to determine both the appropriate and the necess ary level of tailoring required. These factors include: • Type of project • • • • •

Criticality of the project (if any) Experience level of the project team members and support team members • Lessons learned from other tailoring efforts by other projects • Acquisition approach Every project is strongly encouraged to h old tailoring discussions, which include the customer, to identify areas that might be possible candidates. These discussions and any final decision shoul d be documented as part of the project documentation. As a final step, any project tailoring that is to be imple• •

Approach of project Project funding (including funding profile) Project timeline Level of risk acceptable to the customer Level of insight/control acceptable to the customer

mented on the project is recorded in the project management plan prior to formal directorate and JSC Project Management Council approval (see Section 1.2).

D-1

Appendix E – Terms and Definitions

Term(s)

Definition

Acquisition Recommendations

Recommendations to the project acquisition strategies that include: • Inputs based on technical judgments items such as: technology maturity, civil service workforce knowledge and skill base, cost effectiveness, work complexity, and existence of facilities or other infrastructure to perform the work • Lists of products to be acquired and the applicable acquisition type based on a Make/Buy Analysis • Evaluation of suppliers based on their ability to meet specified requirements and established criteria

Acquisition Requirements

The acquisition team generates a requirement set for each acquisition, including, as applicable, statements of work (SOWs), solicitations (request for proposal (RFP), request for quotes (RFQ)), detailed specifications, documentation deliverables, cost, schedule/ long lead, and any other applicable documents. Technical inputs related to the acquisition requirements are provided by the systems engineering (SE) function.

Attainment

The transformation of a solution into a product.

Agreement

Typically used to document requirements (deliverables and quantities, budget plans, and schedules) and responsibilities; examples include an internal task agreement (ITA), a memorandum of agreement (MOA), and an interdivisional agreement (IA).

Authorization to Proceed (ATP)

A formal approval provided by the Johnson Space Center (JSC) Project Management Council (PMC) to implement a JSC project. This approval marks a commitment by the Center to execute the project within the plans and resource envelopes authorized at the time this approval is given.

Baseline

•

•

Reference (if applicable)

The technical performance and content, technology application, schedule milestones, and budget (including contingency and APA) that are documented in approved program and project plans. Official version of a configuration-controlled item that can only be changed through a formal review, evaluation, or approval procedure (Configuration Management (CM) Process section)

NPR 7120.5B

Certification

Flight system certification documents the results of successful hardware (H/W) qualification testing of the qualification unit and H/W and/or software (S/W) acceptance testing of the flight unit. Certification documentation includes the following: identification (part number, part name), baseline requirements and associated verifications, safety data package, baseline test and analysis, documentation (qualification and acceptance plans, procedures, reports), limited-life item list, approved waivers, or deviations and material usage agreements (MUAs), etc.

Control Gate

A management decision process, by the designated review authority, that marks progress in project maturity and risk reduction. A control gate is a process rather than a single formal meeting. It is a tool to achieve consensus about the status of the project. It is a gate in the sense that the effort must successfully complete the associated prerequisite review(s) to move to the next step or life cycle phase in the project.

Configuration Item

An aggregation of work products that is designated for CM and treated as a single entity in the CM process.

Configuration Management

A management discipline applied over the product life cycle to provide visibility, and to control performance and functional and physical characteristics.

Convening Authority

The individual designated by the project management plan (PMP) as being responsible for initiating a milestone review. The convening authority establishes review purpose, scope, and entry and exit criteria as well as assigns a review board chairperson.

E-1

NPR 7120.5B


Term(s)

Definition


Customer

CMMI v1.1 A “customer” is the party (individual, project, or organization) responsible for accepting the product or for authorizing payment. The customer is external to the project, but not necessarily external to the organization. The customer may be a higher-level project. Customers are a subset ofstakeholders. Any individual, organization, or other entity to which a project or project provides a product(s) and/or service(s).

NPR 7120.5B

Decomposition

The division and allocation of high-level systems, requirements, or customer needs into lower-level components or parts.

Enabling System

NPR 71xx.x A system that complements the system of interest but does not contribute directly to its functionality. Each system of interest has a (document number set of enabling systems that allows the system of interest to perform not yet assigned) its life cycle functions.

Entrance Criteria

A collection of documents, decisions, and previously scheduled events that must be accomplished or available at the start of stage processes.

Exit Criteria

A collection of documents, decisions, and previously scheduled events that must be accomplished at the end of the stage before proceeding to a subsequent stage.

Life Cycle Cost (LCC)

NPR 7120.5B The total of direct, indirect, recurring, nonrecurring, and other related NPR expenses incurred or estimated to be incurred in the design, development, verification, production, operation, maintenance, support, and retirement of a system over its planned lifespan.

Logistics Support Plans

SP 6105 Plans that describe what logistics activities are planned and how they will be conducted and integrated into the SE process. Logistics activities include maintenance, personnel and training, supply support, test and support equipment, transportation and handling, facilities, and disposal.

Metric

A measurement taken over a period of time that communicates vital information about a process or an activity. A metric should derive appropriate action.

NPR 7120.5B

Mission

A major activity required to accomplish an Agency goal or to effectively pursue a scientific, a technological, or an engineering opportunity directly related to an Agency goal. Mission needs are independent of any particular system or technological solution.

NPR 7120.5B

Operational Concepts

Operational scenarios are a step-by-step description of how the proposed system should operate and interact with its users and its external interfaces (e.g., other systems).

Participant

An active member of the project or program.

Program

NPR 7120.5B A major activity within an Enterprise that has defined goals, objectives, requirements, and funding levels, and consists of one or more projects.

Project

An organized activity with a finite time span that has defined goals, Draft NPR 7120.5C objectives, requirements, and LEE, and that consumes resources and yields either: a. a new or revisedproduct or service that meets theAgency’s strategic needs. b. A new capability applicable to current or future products or processes that will support future Agency needs.

Requirement

A statement that identifies a product or process operational, functional, or design characteristic or constraint that is unambiguous, testable or measurable, and necessary for product or process acceptability (by consumers or internal quality assurance (QA) guidelines.

IEEE 1220-1998

Risk

The combination of the likelihood of various outcomes and their distinct consequences.

SP 6105

E-2

Appendix E – Terms and Definitions

Term(s)

Definition


Risk Management

An organized, systematic decision-making process that efficiently identifies, analyzes, plans, tracks, controls, communicates, and documents risk to increase the likelihood of achieving program/ project goals.

NPR 7120.5B

Specialty Engineering

The application of specific knowledge and analytic methods in support of SE processes. Specialty engineering disciplines typically include safety, reliability, maintainability, quality assurance, S/W assurance, environment, fabrication, test and verification, human factors, training, operations, information systems, logistics, and maintenance.

Stakeholder

A “stakeholder” is a group of an individual that is affected by or in CMMI v1.1 some way accountable for the outcome of an undertaking. Stakeholders may include project members, suppliers, customers, end users, and others. An individual or organization having no interest (or stake) in the outcome or deliverable of a program or project.

NPR 7120.5B

System

The combination of elements that functions together to produce the NPR 7120.5B capability required to meet a need. Elements include all H/W, S/W, equipment, facilities, personnel, and processes and procedures needed for this purpose.

System of Interest

The entity that the engineering team is responsible for designing, developing, integrating, and testing.

Systems Engineering

NPR 71xx.x SE is defined as a disciplined approach for the definition, implementation, integration, and operation of a system (product or serv- (document number ice). The emphasis is on achieving stakeholder functional, physical, not yet assigned) and operational performance requirements in the intended use environments over the system’s planned life and within cost and schedule constraints. SE includes the engineering processes and technical management processes that consider the interface relationships across all elements of the system, other systems, or as a part of a larger system.

Systems Engineering Management Plan (SEMP)

A documented plan that addresses all relevant technical and engineering management planning items necessary to achieve the

CMMI Project Planning Process

mutual understanding, commitment, and performance of individuals, groups, and organizations that must execute or support the technical effort. The SEMP defines all aspectsof the technical effort, tying together in a logical manner: project life cycle considerations; technical and management tasks; budgets and schedules; milestones; data management, risk identification, resource and skill requirements; and stakeholder identification and interaction. Infrastructure descriptions include responsibility and authority relationships for the technical staff, management, and support organizations. Depending on the nature of the project, SEMP content may be contained in a standalone document or embedded in the PMP. Technical Performance Measure (TPM)

Key indicators of key performance that, if not met, put the project atIEEE 1220-1998 cost, schedule, and performance risk. The most useful TPMs are those that provide visibility into the technical performance of key elements of the work breakdown structure (WBS), especially those that are cost drivers on the program, lie on the critical path, or represent high-risk items. TPMs are key to progressively assessing technical progress.

Validation

Proof that the product accomplishes the intended purpose. May be determined by a combination of test, analysis, and demonstration.

NPR 7120.5B

Verification

Proof of compliance with specs. May be determined by a combination of test, analysis, demonstration, and inspection.

NPR 7120.5B

E-3

Appendix F – Acronyms

AC ACE ACWP ADP AIAA

DLE DLO DO DoD DPM DR DRFP DRLI DTO

discipline lead engineer directorate-level organization delivery order Department of Defense deputy project manager Definition Review draft request for proposal data requirements list items detailed test objective

AO APA

actual cost advocacy cost estimate actual cost of work performed acceptance data package American Institute of Aeronautics and Astronautics American Management Association American National Standards Institute Announcement of Opportunity allowance for program

EA EAA

environmental assessment Enterprise Associate

ATP

adjustment to proceed authorization

B-C-F BAC BCWP BCWS BOE

baseline-current-future budget at completion budgeted cost of work performed budgeted cost of work scheduled basis of estimate

EAC EEE EIA EMC/EMI

C/SCSC

Cost/Schedule Control Systems Criteria cost analysis requirements description configuration control board Center Director Center Director Discretionary Fund Critical Design Review comparative fit index Chief Financial Officer configuration item critical items list configuration management Capability Maturity Model Integration construction of facilities contracting officer technical representative commercial off-the-shelf cost performance index critical path method central processing unit change request Concept Review cost variance Common Work Instruction

Administrator estimate at completion electrical/ele ctronic equipment Electronics Industries Alliance electromagneti c compatibility/ electromagnetic interference engineering-procurementconstruction Engineering Review Board electronic systems test laboratory estimation to complete earned value earned value management earned value management system

AMACON ANSI

CARD CCB CD CDDF CDR CFI CFO CI CIL CM CMMI CofF COTR COTS CPI CPM CPU CR CV CWI DCMA

Defense Contract Management Agency

DDMS

design and data management system design, development, test, and evaluation

DDTE

EPC ERB ESTL ETC EV EVM EVMS

FAR FFBD FMEA FRB FRR FTA FTE

Federal Acquisition Regulation functional flow block diagram failure mode and effects analysis Facility Review board Flight Readiness Review fault-tree analysis full-time equivalent

G&A GCAR

GSE

general and administrative government certification approval request graphical evaluation review technique government-furnished equipment Governing Project Management Council group support equipment

H/W HSI

hardware hardware/softw are integration

IA

independent assessment interdivisional agreement interface control document independent cost estimate

GERT GFE GPMC

ICD ICE

F-1


IDEF0

integration definition for function modeling interface working group International Council on Systems Engineering Information Resources Directorate Integrated Risk Management Application International Organization for Standardization information technology

PC PCA PDR PERT

ITA IV&V

internal task agreement independent verification and validation

J-SEW G JPD JPG JSC

JSC Systems Engineering Working Group JSC Policy Directive JSC Procedures and Guidelines Johnson Space Center

POP PQA PR PRA ProRR PSA PSRP

program operating procurement qualityplan assurance Purchase Request probabilistic risk assessment Production Readiness Review probabilistic safety assessment Payload Safety Review Panel

KSC

Kennedy Space Center

QA QFD QRA

quality assurance quality functional deployment quantitative risk assessment

LAN LCC LOE LSE

local area network life cycle cost level of effort lead systems engineer

R-BAM

MCC MDR MOA MUA

Mission Control Center Mission Definition Review memorandum of agreement material usage agreement

NAR NGST

non -advocate review Next- Generation Space Telescope National Institute of Standards and Testing NASA Managemen t Instruction new obligation authority NASA Policies and Directives NASA Procedures a nd Requirements NASA Safety and Reporting System

risk-based acquisition management research and development reliability and maintainability requirements allocation sheet request for proposal request for quotes review item disposition reference publication Requirements Review Research and Technology Objectives and Plans

IFW G INCOSE IRD IRMA ISO IT

NIST NMI NOA NPD NPR NSRS

PI PMB PMC PMP PMW G

R&D R&M RAS RFP RFQ RID RP RR RTOP

S&MA S/W SAR SBIR SDR SE SEMP SEPG

ODC ORR OSB OSHA

P/FR P3 I

other direct cost Operational Readiness Review outside of board Occupational Safety and Health

SI SLE SLP

Administration

SMART

problem/failure report preplanned product improvement

F-2

personal computer program commitment agreement Preliminary Design Review program evaluation review technique principal investigator performance measurement baseline Project Management Council project management plan Project Management Working Group

safety and mission assurance software System Acceptance Review Small Business Innovation Research System Definition Review systems engineering Systems Engineering Management Plan Software Engineering Process Group international system of units subsystem lead engineer system-level procedure Safety and Mission Assurance Review Team specific, measurable, achievable, resource constrained, and time constrained

Appendix F – Acronyms

SME SMO SOW SPI SRP SRR SV

subject matter expert Systems Management Office statement of work schedule performance index Safety Review Panel System Requirements Review schedule variance

TBD TBS TCPI TDRSS

to be determined to be supplied to complete performance index tracking and data relay satellite

TIM TLS TPM TRL TRR TS

system interchange meeting technical timeline analysis sheet technical performance measure technology readiness level Test Readiness Review technical solution

VAC VAR VASIMR

variance at completion variance analysis report variable specific impulse magnetoplasma rocket

WAD WBS

work authorization document work breakdown structure

F-3

Appendix G – Photograph Captions

P 2-20 left

Chapter 1:

ISS004-E-11792 (26 April 2002 ) Astronaut Carl E. Walz, Expedition 4 flight engineer, works on the Elektron Oxygen Generator in the Zvezda Service Module on the ISS.P 2-22

P 1-2

STS110-730-079 (17 April 2002) This full view of the International Space Station (ISS) was recorded by the STS-110 crewmembers on board the Space Shuttle Atlantis following the undocking of the two spacecraft some 247 statute miles above the North Atlantic.

p2-22 ISS004-E-11958 (16 May 2002) This image features fire scars and smoke plumes resulting from biomass burning in the savannahs of the southern Democratic Republic Congo. Expedition 4 crewmembers observed the seasonal increase in savannah burning.

P 1-7

JSC2001-E-18949 (December 2001) The Space Shuttle Atlantis launched this railcar, called the Mobile Transporter (MT), and an initial 43-foot section of track as it delivered the first segment of the ISS exterior truss. Designated “S0 (S-zero),” this first section of truss was carried aloft during the mission of STS-110.

Chapter 3: P 3-1

ISS007-E-17880 (20 October 2003)

Chapter 2:

European Space Agency (ESA) astronaut Pedro Duque of Spain prepares to set up the Cervantes program of tests by starting with the Microgravity Science Glovebox (MSB) in the Destiny laboratory on the ISS. Duque is working on an experiment that will investigate the growth processes of proteins during weightless conditions.

P 2-6

STS110-S-039 (19 April 2002) The Space Shuttle Atlantis heads for touchdown on the runway at the KSC landing facility to complete a nearly 11day journey.

P 3-3 P 2-10

ISS008-E-05181 (31 October 2003)

STS105-E-5226 (16 August 2001)

Astronaut C. Michael Foale, Expedition Eight mission commander and NASA ISS science officer, works with the Russian biomedical “Pilot” experiment in the Zvezda Service Module on the ISS. The experiment looks at psychological and physiological changes in crew performance during long-duration space flight.

Now a member of the STS-105 crew, departing Expedit ion 2 Flight Engineer Susan J. Helms works out on the er gometer device on the mid deck of the Space ShuttleDiscovery. P 2-11 top

ISS005-E-16521 (9 aOctober Backdropped against blue and2002) white Earth, this view

P 3-6

of the Space Shuttle Atlantis was photographed by an Expedition 5 crewmember on board the ISS during rendezvous and docking operations.

ISS008-E-12281 (9 January 2004) Cosmonaut Alexander Y. Kaleri, Expedition 8 flight engineer, works at the Vozdukh CO2 scrubber in the Zvezda Service Module on the ISS.

P 2-11 bottom

ISS005-E-10926 (23 August 2002)

P 3-10

This image shows some of the devastating late summer 2002 European flooding. The image, captured on board the ISS during Expedition 5, shows flooding around the Danube Bend area just north of Budapest near the city of Vác, Hungary

The Space Shuttle Columbia passes through some predawn clouds as it soars into the sky to begin its 27th flight, STS-109.

STS109-S-020 (1 March 2002)

P 3-13 P 2-20 top right

STS112-326-015 (12 October 2002)

ISS004-E-8652 (14 March 20 02) Astronaut Daniel W. Bursch, Expedition 4 flight engineer, works the controls of the Canadarm2, or Space Station Remote Manipulator System (SSRMS) in the Destiny laboratory on the ISS.

Astronaut Piers J. Sellers, STS-112 mission specialist, uses a handrail on the Destiny Laboratory and a foot restraint on the SSRMS or Canadarm2 to remain stationary while performing work at the end of the STS-112 mission's second spacewalk.

P 2-20 bottom right

P 3-14 left

ISS004-E-10288 (21 April 2002 )

STS112-E-05901 (16 October 2002)

This view featuring the San Francisco Bay Area was photographed by an Expedition 4 crewmember on board the ISS.

Astronaut Sandra H. Magnus, STS-112 mission specialist, works out on a bicycle ergometer on the middeck of the Space Shuttle Atlantis.

G-1


P 3-14 right

STS112-304-005 (12 October 2002) This scene, showing a portion of the forward section of the Space Shuttle Atlantis, was photographed by a space walking astronaut. Astronauts Jeffrey S. Ashby, STS-112 mission commander; Pamela A. Melroy, pilot; and cosmonaut Fyodor N. Yurchikhin, mission specialist, can be seen through an overheard aft flight deck window. P 3-15

STS112-702-002 (7–18 October 2002) Egypt’s triangular Sinai Peninsula lies in the center of this view, photographed from the Space ShuttleAtlantis, with the dark greens of the Nile delta lower right. P 3-24

STS113-E-05201 (28 November 2002) Astronaut Michael E. Lopez-Alegria, STS-113 mission specialist, works on the newly installed Port One (P1) truss on the ISS during the mis sion’s second scheduled spacewalk The spacewalk lasted 6 hours, 10 minutes.

Chapter 4: P 4-8 top

ISS008-E-13212 (26 January 2004) This image of the El Paso-Juarez area on the U.S.-Mexico border, photographed by an Expedition 8 crewmember, is the 100,000th photograph of Earth that astronauts have taken from the ISS. P 4-8 bottom

STS112-709-073K (10 October Astronaut David A. Wolf, STS-1122002) mission specialist, anchored to a foot restraint on the SSRMS or Canadarm2, carries the Starboard One (S1) outboard nadir external camera. The camera was installed on the end of the S1 Truss on the ISS during the mission’s first scheduled spacewalk.

(EMU) spacesuit, is pictured in the Quest Airlock on the Lopez-Alegria was about to begin the first of three scheduled spacewalks to perform work on the Station. P 4-22 bottom

STS113-370-012 (2 December 2002) The horizon of a blue and white Earth and the blackness of space form the backdrop as two miniature satellites are released from the Space Shuttle Endeavour as part of an experiment referred to as MEPSI. Funded by the Defense Advance Research Projects Agency (DARPA), the two small satellites, which are tethered together, were released from Endeavour’s payload bay (visible in foreground) to fly free for three days as a technology demonstration of the launcher and use of micro- and nano-technologies in space systems. P 4-30

STS107-400-004 (16 January – 1 February 2003) This Earth view featuring the Sinai Peninsula, Red Sea, Egypt, Nile River, and Mediterranean was photographed by a n STS-107 crewmember on board the Space Shuttle Columbia. P 4-32 fragment,

top ri ght STS113-332-035 (14 December 2002) The STS-113 crewmembers used a 35mm still camera to record this image of Mt. Etna Volcano erupting on the island of Sicily. The oblique, south-looking view shows Mt. Etna’s dark ash plume. P 4-34 top right

STS113-305-007 (26 November 2002) Astronaut John B. Herrington, STS-113 mission specialist, participates in the mission’s first spacewalk. The opened hatch of the Quest Airlock is reflected in Herrington’s helmet visor. P 4-34 bottom

STS113-336-015 (2 December 2002) P 4-11

STS111-307-017 (11 June 2002) Astronaut Philippe Perrin, STS-111 mission specialist representing CNES, the French Space Agency, participates in the second scheduled spacewalk for the mission. During the spacewalk, Perrin and Chang-Diaz attached power, data and video cables from the ISS to the Mobile Base System (MBS) and used a power wrench to complete attachment of the MBS onto the MT. P 4-18

STS113-S-007 (23 November 2003) Against a black night sky, Space ShuttleEndeavour heads toward Earth orbit and a scheduled link-up with the ISS. P 4-22 top right

STS113-360-030 (26 November 2002) Astronaut Michael E. Lopez-A legria, STS-113 mission specialist, attired in his Extravehicular Mobility Unit ISS.

Backdropped by a blue and white Earth, this full view of the ISS was photographed by a crewmember on board the Space Shuttle Endeavour following the undocking of the two spacecraft. P 4-41 left

STS111-321-024 (5–19 June 2002) This sunset over the Sahara Desert was photographed by the STS-111 crewmembers aboard the Space Shuttle Endeavour. When this photograph was taken, the Shuttle was in a position over the Sudan near the Red Sea coast. P 4-41 right

STS111-367-014 (5–19 Jun e 2002) This view featuring Canadian forest fires was taken by STS-111 crewmembers aboard Space Shuttle Endeavour. It represents an oblique view northward of one of the numerous fires observed and reported burning in the dry boreal forests of Saskatchewan and Manitoba during the month of June.

G-2

Appendix G – Photograph Captions

of the Space Shuttle Endeavour remote manipulator system (RMS) robotic arm during the four-hour, 12-minute session spacewalk.

P 4-46 top

ISS007-E-09860 (21 July 2 003) This view of Earth’s horizon as the sunsets over the Pacific Ocean was taken by an Expedition 7 crewmember on board the ISS. Anvil tops of thunderclouds are also visible.

P 4-78

STS108-350-009 (10 December 2001) Astronaut Linda M. Godwin, STS-108 mission specialist, works during a four-hour, 12-minute spacewalk. The main objective of the spacewalk was to install thermal blankets on mechanisms that rotate the ISS main solar arrays

P 4-46 bottom

ISS007-E-10807 (8 July 2003) Astronaut Edward T. Lu, Expedition 7 NASA ISS science officer and flight engineer, wearing squat harness pads, performs knee-bends using the Interim Resistive Exercise Device (IRED) equipment in the Unity node on the ISS.

P 4-81 left

STS107-E-05359 (22 January 2003) P 4-52 top

SPACEHAB Double Module as seen from Columbia’s aftResearch flight deck during STS-107.

JSC2003-E-31962 (24 April 2 003) The Soyuz rocket is erected at the launch pad at the Baikonur Cosmodrome, Kazakhstan. Expedition 7 is scheduled to launch on board the Soyuz on Saturday April 26, 2003.

P 4-81 right

STS107-E-05537 (25 January 2003) One of the STS-107 crewmembers used a digital still camera to capture this image of clouds, shadows and sunglint during a moment away from Flight Day 10 science research aboard the Space Shuttle Columbia.

P 4-52 bottom

ISS008-E-12109 (6 January 2004) Five-year-old icebergs near South Georgia Island are featured in this image photographed by an Expedition 8 crewmember on board the ISS. This oblique image shows two pieces of a massive iceberg that broke off from the Antarctica Ronne Ice Shelf in October 1998.

P 4-84

STS104-315-013 (12–24 July 2001) Holding onto the end effector of the Canadarm on the Space Shuttle Atlantis, astronaut Michael L. Gernhardt, STS-104 mission specialist, participates in one of three STS-104 spacewalks. The spacewalk was designed to help wrap up work on the second phase of the ISS.

P 4-55

STS110-353-023 (8–19 April 2002) Docked to the ISS, a Soyuz vehicle (foreground) and the Space Shuttle Atlantis were photographed by an STS-110 crewmember in the Pirs docking compartment on the orbital outpost.

P 4-90 top

ISS006-E-05070 (4 December 2002) The new crewmembers aboard the ISS were able to document a rare occurrence early into their tour on the outpost. The dark area near Earth’s horizon at center frame is actually a shadow cast by the Moon during the total solar eclipse of Dec. 4, 2002.

P 4-64

STS113-S-005 (23 November 2002) Against a black night sky, the Space Shuttle Endeavour heads toward Earth orbit and a scheduled link-up with the ISS.

P 4-90 bottom

ISS006-E-07133 (9 December 2002) Astronaut Donald R. Pettit, Expedition 6 NASA ISS science officer, works to set up Pulmonary Function in Flight (PuFF) hardware in preparation for a Human Research Facility (HRF) experiment in the Destiny laboratory on the ISS.

P 4-68

STS111-373-001 (15 June 2002) Backdropped by the blackness of space and a blue and white Earth, the ISS is now separated from the Space Shuttle Endeavour following the undocking of the two spacecraft over western Kazakhstan.

P 4-93

STS112-705-011 (7–18 October 2002)

P 4-72

The light-blue region in the middle of this view, photographed from the Space Shuttle Atlantis, is the shallow flat platform known as the Great Bahama Bank.

JSC2003-E-59333 (20 October 2003) This overall view of the Station flight control room (BFCR) in JSC’s Mission Control Center (MCC) was photographed during rendezvous and docking operations between the Soy uz TMA-3 spacecraft and the ISS.

P 4-96

STS111-373-018 (15 June 2002)

P 4-77

Silhouetted over Earth, this full view of the ISS was photographed by a crewmember on board the Space Shuttle Endeavour following the undocking of the two spacecraft over western Kazakhstan.

STS108-311-010 (10 December 2001) Astronauts Linda M. Godwin (red stripes) and Daniel M. Tani, STS-108 mission specialists, are pictured near the end

G-3


P 4-100

P B-2

STS110-716-026 (13 April 2002)

STS109-713-014 (8 March 2002)

Some 240 miles above the blue and white Earth, astronaut Lee M.E. Morin totes on e of the S0 (S-zero) keel pins that was removed from its functional position on the truss and attached on the truss exterior for long-term stowage.

Astronauts John M. Grunsfeld (right) and Richard M. Linnehan, STS-109 payload commander a nd mission specialist, respectively, are photographed near the giant Hubble Sp ace Telescope temporarily hosted in the Space Shuttle Columbia’s cargo bay at the close of the fifth and final session of spacewalks.

P 4-104

ISS007-E-09855 (8 July 2003) Astronaut Edward T. Lu, Expedition 7 NASA ISS science officer and flight engineer, exercises on the Cycle Ergometer with Vibration Isolation System (CEVIS) in the Destiny laboratory on the ISS.

P D-1

STS108-E-5349 (10 December 2001) Astronaut Linda M. Godwin, STS-108 mission specialist, is pictured near the end of the Space Shuttle Endeavour RMS arm during a four-hour spacewalk.

P 4-109 top

STS109-326-008 (5 March 2002)

P F-3 top

Astronaut Michael J. Massimino, mission specialist, works at the stowage area for the Hubble Space Telescope port side solar array. Astronauts Massimino and James H. Newman removed the old port solar array and stowed it in Columbia’s payload bay for a return to Earth. They then went on to install a third-generation solar array and its associated electrical components.

ISS005-E-19267 (1 November 2002)

P 4-109 bottom

A Soyuz spacecraft approaches the Pirs docking compartment on the ISS carrying the Soyuz 5 taxi crew, Commander Sergei Zalyotin, Belgian Flight Engineer Frank DeWinne, and Flight Engineer Yuri V. Lonchakov for an eight-day stay on the Station. The new Soyuz TMA1 vehicle was designed to accommodate larger or smaller crewmembers, and is equipped with upgraded computers, a new cockpit control panel and improved avionics.

STS109-329-021 (1–12 March 2002) The horizon of a blue and white Earth and the blackness of space form the backdrop for this view of the cargo bay of the Space Shuttle Columbia, as seen through windows on the aft flight deck during the STS-109 mission. Pictured in the cargo bay is the Rigid Array Carrier (RAC) holding the new Hubble Solar Arrays. In its stowed position at right center of the frame is the Canadian-built RMS arm.

P F-3 bottom

ISS005-E-19024 (30 October 2002) The three-member crew of the Expedition 5 mission on board the ISS was able to observe Mt. Etna’s spectacular eruption, and photograph the details of the eruption plume and smoke from fires triggered by lava as it flowed down the 11,000 ft mountain. This image provides a three-dimensional profile of the eruption plume. This eruption was one of Etna’s most vigorous in years.

Appendices: P A-3 top

ISS007-E-10246 (15 July 2 003) The crew of the ISS had a great seat from which to observe tropical storm Claudette as she turned into a hurricane and came ashore with high winds and heavy rains that drenched their Houston home base and other Texas areas.

Below ISS008-E-08453 (10 December 2003) This view of a full Moon was photographed by one of the Expedition 8 crewmembers on board the ISS.

P A-3 bottom

right ISS007-E-14440 (4 September 2003) Astronaut Edward T. Lu, Expedition 7 NASA ISS science officer and flight engineer, wearing a Russian Sokol suit, floats in the Destiny laboratory on the ISS. P A-3 bottom

left ISS007-E-11507 (31 July 2 003) Cosmonaut Yuri I. Malenchenko, Expedition 7 mission commander, is pictured with the Plasma Crystal Experiment the Zvezda Service Module transfer compartment on theinISS.

G-4

Appendix H – “Spiral” Development Process

n

Key:

+1

Planning

TRL

Develop

(n )

Prototype Build

n

Evaluate, Determine Alt ernati ves

H-1

National Aeronautics and Space Administration Lyndon B. Johnson Space Center Houston, Texas

NASA Project Management System Engineering and Project Control Processes and Requierments

Recommend Documents