space systems engineering - university of...

Space Systems EngineeringENAE 483/788D - Principles of Space Systems Design

U N I V E R S I T Y O FMARYLAND

Space Systems Engineering

1

• Lecture #02 – September 5, 2013• Background of Systems Engineering• NASA program planning phases• Scheduled milestones• Requirements document• Work breakdown structure• Technology readiness levels• Project management tools• Design reference missions and CONOPS• Earned value management• Risk tracking © 2013 David L. Akin - All rights reserved

http://spacecraft.ssl.umd.edu



Announcements

• No lectures next week– Lectures will be podcast on web– Use class time to meet with your group and work on

Systems project assignment

• When posting in Piazza, don’t use anonymous mode unless it is appropriate!

• Check the course web site(s) regularly (at least daily) for news and announcements

2



Overview of Systems Engineering

• Developed to handle large, complex systems– Geographically disparate– Cutting-edge technologies– Significant time/cost constraints– Failure-critical

• First wide-spread applications in aerospace programs of the 1950’s (e.g., ICBMs)

• Rigorous, systematic approach to organization and record-keeping

3



NASA Lifecycle Overview

4



NASA Formulation Stage Overview

5



Space Systems Development Process

Pre-Phase A Conceptual Design PhaseDevelopment of performance goals and requirementsEstablishment of Science Working Group (science missions)Trade studies of mission conceptsFeasibility and preliminary cost analysesRequest for Phase A proposals

6




Pre-Phase A

Phase A

Preliminary Analysis PhaseProof of concept analysesMission operations concepts“Build vs. buy” decisionsPayload definitionSelection of experimentersDetailed trajectory analysisTarget program scheduleRFP for Phase B studies

7




Pre-Phase A

Phase B

Phase A

Definition PhaseDefine baseline technical solutionsCreate requirements documentSignificant reviews:

Systems Requirements ReviewSystems Design ReviewNon-Advocate Review

Request for Phase C/D proposalsEnds with Preliminary Design Review (PDR)

8



Historical Implications of Study Phases

9

from J. A. Moody, ed., Metrics and Case Studies for Evaluating Engineering Designs Prentice-Hall, 1997



Implementation Stage Overview

10




Pre-Phase A

Phase C/D

Phase B

Phase A

Development PhaseDetailed design process“Cutting metal”Test and analysisSignificant reviews:

Critical Design Review (CDR)Test Acceptance ReviewFlight Readiness Review

Ends at launch of vehicle

11




Pre-Phase A

Phase E/F

Phase C/D

Phase B

Phase A

Operations and End-of-LifeLaunchOn-orbit Check-outMission OperationsMaintenance and TroubleshootingFailure monitoringEnd-of-life disposal

12



NASA Project Life Cycle - Milestones

13

from NASA SP-2007-6105 rev. 1, “NASA Systems Engineering Handbook”



NASA Project Life Cycle - Acronyms

14

from NASA SP-2007-6105 rev. 1, “NASA Systems Engineering Handbook”



Requirements Document

• The “bible” of the design and development process

• Lists (clearly, unambiguously, numerically) what is required to successfully complete the program

• Requirements “flow-down” results in successively finer levels of detail

• May be subject to change as state of knowledge grows

• Critical tool for maintaining program budgets

15



Design is based on requirements. There's no justification for designing something one bit "better" than the requirements dictate.

Akin’s Laws of Spacecraft Design - #13

16

DYMAFLEX

Stowed Configura7on

Deployed Configura7on

Mission Overview

• Mission Statement Investigate the coupled dynamics and associated control mitigation

strategies for a free-flying vehicle with a high-performance manipulator performing tasks analogous to satellite servicing

• Mission Objectives– Develop a microsatellite in the university environment through a program which

maximizes opportunities for students to be involved in all aspects of the development process.

– Leverage three decades of advanced space robotics research in the development and flight demonstration of a space manipulator system

– Investigate the coupled dynamics and associated control mitigation strategies for a free-flying vehicle with a high-performance manipulator performing tasks analogous to satellite servicing

• Technology Demonstrations– Lightweight, high-performance manipulator– Space manipulator adaptive control

Mission Requirements

M-1 DYMAFLEX shall include a robotic manipulator

M-2 DYMAFLEX shall be able to move the manipulator sufficiently fast as to cause larger dynamic coupling between manipulator and host vehicle than currently experienced on flown systems

M-3 DYMAFLEX shall be able to downlink telemetry of experiments to validate success of algorithms on the ground

M-4 DYMAFLEX shall operate in an environment where system dynamics dominates perturbations due to environmental effects

M-5 DYMAFLEX shall be able to introduce unknown values to control system by changing the mass configuration of its end effector

M-6 DYMAFLEX shall be able to return to a stable attitude after or during dynamic motions of the manipulator

M-7 DYMAFLEX shall simulate a variety of payload motions to cover desirable sets of future trajectories

M-8 DYMAFLEX shall maximize useful life on orbit by accepting new experiments from the ground

System Requirements

S-1 DYMAFLEX shall be able to perform a minimum set of trajectories: a single DOF, multi-axis linear and extended nonlinear

S-2 DYMAFLEX shall meet launch program's requirements (see UNP7 Users Guide)

S-3 DYMAFLEX shall be able to know its position, orientation, manipulator configuration, and lock state of tip masses

S-4 DYMAFLEX shall have sufficient communications capability to downlink a minimum of TBD Mb of experiment data within life of spacecraft

S-5 DYMAFLEX shall generate sufficient power (# watts TBD) to execute the minimum set of experiments and communicate results to ground

S-6 DYMAFLEX shall have multiple interchangeable tip masses for the manipulator

S-7 DYMAFLEX shall have sufficient computational power to perform realtime kinematic and manipulator control calculations

S-8 DYMAFLEX shall be able to put itself into a safe mode in the event of a critical anomaly

ROBO RequirementsS1-1 ROBO shall have a 4 DOF manipulator

S1-2 ROBO shall be able to change tip masses

S1-3 ROBO shall be capable of minimum end effector velocity of TBD m/s

S1-4 ROBO shall sense joint position, velocity, and torque

S1-5 ROBO shall sense motor controller temperature and current draw

S1-6 ROBO shall not extend below the Satellite interface plane (during or after deployment)

STRM RequirementsS2-1 The STRM shall have a natural frequency of at least 100 Hz with a goal of TBD Hz

S2-2 The STRM shall withstand g's in the x,y,z direction

S2-3 The STRM shall have a factor of safety of 2.0 for yield and 2.6 for ultimate for all structural elements

S2-4 STRM shall have a mass less than TBD grams with a goal of less than TBD grams

S2-5 STRM shall interface with lightband at satellite interface plane with 24 #1/4 bolts

S2-6 STRM shall not extend below Satellite interface plane (during or after deployments)

S2-7 STRM shall provide system with solar panels that will provide sufficient power for experiments

S2-8 STRM shall ensure CG for DYMAFLEX is within envelope (less than 0.5cm from lightband centerline, less than 40cm above satellite interface plane)

S2-9 STRM shall ensure final dimensions of DYMAFLEX meet requirements (50cm x 50cm x 60 cm tall)

S2-10 STRM materials shall meet all outgassing and stress corrosion cracking requirements

S2-11 STRM shall provide adequate venting such that the pressure difference is less then 0.5 psi with a factor of safety of 2



Requirements Verification Matrix

• Single spreadsheet tracking all requirements, sources, status, and documentation

• Broken down to successively finer levels of detail (frequently 4-6 levels)

• For a major program, the printed version can run to hundreds of pages

• Ensures that nothing gets overlooked and everything is done for a purpose

23



483/484 Level 1 Requirements

• The habitat system shall be capable of being positioned and used anywhere in cislunar space beyond the Van Allen radiation belts

• The system shall be compatible with Orion and provide crew support for up to 30 days

• The system shall provide an airlock or other means of supporting extravehicular activity without depressurization

• The system design shall incorporate launch, delivery, and stationkeeping

24



ENAE 483/484 Level 1 Requirements

• The system shall be designed to accommodate multiple missions and potential repositionings over the course of the habitat lifetime

• The system shall support an overall mission loss of crew probability no greater than 0.001

• The system shall maintain crew cumulative radiation dosage within current NASA limits

• Habitability of the habitat design and crew interfaces shall be assessed using physical mockups in 1g and neutral buoyancy

25



ENAE 483/484 Level 1 Requirements

• The system shall be capable of being launched on a single existing EELV or Falcon Heavy

• TBD

26



RASC-AL Judging Criteria• Synergistic application of innovative capabilities and/or new

technologies for evolutionary architecture development to enable future missions, reduce cost, or improve safety;

• Scientific evaluation and rationale of mission operations in support of an exciting and sustainable space exploration program;

• A mission concept of operations that includes what occurs at the facility before, during, and after crewed visits (over a period of years);

• Key technologies, including technology readiness levels (TRLs), as well as the systems engineering and architectural trades that guide the recommended approach;

• Reliability and human safety consideration in trading various architecture options;

• Realistic assessment of project plan and execution of that plan, including inclusion of a project schedule and test plan, as well as development and realistic annual operating costs (i.e., budget)

27

DYMAFLEX Requirements Verification Matrix



Interface Control Documents

• Used to clearly specify interfaces (mechanical, electrical, data, etc.) between mating systems

• Critical since systems may not be fit-checked until assembled on-orbit!

• Success of a program may be driven by careful choices of interfaces

• KISS principle holds here (“keep it simple, stupid”)

29



System Block Diagrams

• Shows interrelationships between systems• Can be used to derive communication bandwidth

requirements, wiring harnesses, delineation of responsibilities

• Created at multiple levels (project, spacecraft, individual systems and subsystems)

30



Exo-SPHERES S/C Block Diagram

31

RCS! COMM!

EPS!

SFT!C&DH!

ADCS!

VIS!

STRM!

Batteries!

Charger!

Kibo Airlock!

Regulator!CPU!

Disk Storage!

OS!

Scheduling!ADCS!RCS!

COMM!ROBO!

Reaction Wheel (TDB)!(x3)!

9 DOF IMU (TDB)! (x 3)!

Aft Camera!

Forward Camera (x2)!!

Wiring Harness!

Thrusters (x 16)! !

Tank! !

Tank! !

Valves! !

THRM!Sensors!(TDB)!

Active (TDB)!

Passive (TDB)!

High Bandwidth!

Low Bandwidth!XPNDR!

(TBD)!Antenna!(TBD) !

Antenna!(TBD) !

XPNDR!(TBD)!

Antenna!(TBD) !

Antenna!(TBD) !

Lights (TDB)!

AMP!Interfaces!

Restraints!

Access Hatches! Payload!Cushioning!



Exo-SPHERES RCS Block Diagram

32




(Shea's Law) The ability to improve a design occurs primarily at the interfaces. This is also the prime location for screwing it up.

33



Work Breakdown Structures

• Detailed “outline” of all tasks required to develop and operate the system

• Successively finer levels of detail– Program (e.g., Constellation Program)– Project (Lunar Exploration)– Mission (Lunar Sortie Exploration)– System (Pressurized Rover)– Subsystem (Life Support System)– Assembly (CO2 Scrubber System)– Subassembly, Component, Part, ...

34



NASA Standard WBS Levels 1 & 2

35


U N I V E R S I T Y O FMARYLAND 36

Standard WBS for JPL Mission

Foreign Travel/ITAR01.07

Facilities01.06

Review Support01.05

Project Plng Spt01.04

Risk Mgmnt01.03

Business Mgmnt01.02

Project Mgmnt01.01

Project Management01

Project V&V02.08

Launch Sys Eng02.07

Planetary Protection02.06

Config Mgmnt02.05

Information Systems02.04

Project SW Eng02.03

Mission & Nav Design02.02

Project Sys Eng02.01

Project Sys Eng02

SW IV&V03.09

Contamination Control03.08

SW Q&A03.07

HW Q&A03.06

EEE Parts Eng03.05

Reliability03.04

Environments03.03

System Safety03.02

MA Mgmnt03.01

Mission Assurance03

Education & Outreach04.06

Sci EnvironmentCharacterization

04.05

Sci Investigatio & Ops Spt

04.04

Sci Data Support04.03

Science Team04.02

Science Mgmnt04.01

Science04

P/L I&T05.06

Common P/L Systems05.05

Instrument N05.04

Instrument 105.03

P/L Sys Eng05.02

P/L Mgmnt05.01

Payload05

Spacecraft assemblytest & verification

06.12

Testbeds06.11

Spacecraft Flt SW06.10

GN&C Subsys06.09

Propulsion Subsys06.08

Thermal Subsys06.07

Mechanical Subsys06.06

Telecomm Subsys06.05

Command & Data S/s06.04

Power Subsys06.03

Flt Sys - Sys Eng06.02

Flt Sys Mgmnt06.01

Spacecraft Contract06.00

Flight System06

MOS V&V07.05

Operations07.04

Ground Data Sys07.03

MOS Sys Eng07.02

Mission Ops Mgmnt07.01

Mission Ops System07

Launch Services08.01

Launch System08

Project Name

WB

S Le

vels 1

2

3



Detail across JPL WBS Level II

1. Project Management2. Project Systems Engineering3. Mission Assurance4. Science5. Payload6. Flight System7. Mission Operations System8. Launch System

37


U N I V E R S I T Y O FMARYLAND 38

Standard WBS for JPL Mission

Foreign Travel/ITAR01.07

Facilities01.06

Review Support01.05

Project Plng Spt01.04

Risk Mgmnt01.03

Business Mgmnt01.02

Project Mgmnt01.01

Project Management01

Project V&V02.08

Launch Sys Eng02.07

Planetary Protection02.06

Config Mgmnt02.05

Information Systems02.04

Project SW Eng02.03

Mission & Nav Design02.02

Project Sys Eng02.01

Project Sys Eng02

SW IV&V03.09

Contamination Control03.08

SW Q&A03.07

HW Q&A03.06

EEE Parts Eng03.05

Reliability03.04

Environments03.03

System Safety03.02

MA Mgmnt03.01

Mission Assurance03

Education & Outreach04.06

Sci EnvironmentCharacterization

04.05

Sci Investigatio & Ops Spt

04.04

Sci Data Support04.03

Science Team04.02

Science Mgmnt04.01

Science04

P/L I&T05.06

Common P/L Systems05.05

Instrument N05.04

Instrument 105.03

P/L Sys Eng05.02

P/L Mgmnt05.01

Payload05

Spacecraft assemblytest & verification

06.12

Testbeds06.11

Spacecraft Flt SW06.10

GN&C Subsys06.09

Propulsion Subsys06.08

Thermal Subsys06.07

Mechanical Subsys06.06

Telecomm Subsys06.05

Command & Data S/s06.04

Power Subsys06.03

Flt Sys - Sys Eng06.02

Flt Sys Mgmnt06.01

Spacecraft Contract06.00

Flight System06

MOS V&V07.05

Operations07.04

Ground Data Sys07.03

MOS Sys Eng07.02

Mission Ops Mgmnt07.01

Mission Ops System07

Launch Services08.01

Launch System08

Project Name

WB

S Le

vels 1

2

3



Detail in JPL “Flight Systems” Column1. Spacecraft Contract2. Flight Systems Management3. Flight Systems - Systems Engineering4. Power Systems5. Command and Data Handling Systems6. Telecommunications Systems7. Mechanical Systems8. Thermal Systems9. Propulsion Systems10.Guidance, Navigation, and Control Systems11.Spacecraft Flight Software12.Testbeds13.Spacecraft Assembly, Test, and Verification

39




It's called a "Work Breakdown Structure" because the Work remaining will grow until you have a Breakdown, unless you enforce some Structure on it.

40



Technology Readiness Levels

TRL 9 Actual system “flight proven” through successful mission operations

TRL 8 Actual system completed and “flight qualified” through test and demonstration

TRL 7 System prototype demonstration in the real environment

TRL 6 System/subsystem model or prototype demonstration in a relevant environment

TRL 5 Component and/or breadboard validation in relevant environment

TRL 4 Component and/or breadboard validation in laboratory environment

TRL 3 Analytical and experimental critical function and/or characteristic proof-of-concept

TRL 2 Technology concept and/or application formulated

TRL 1 Basic principles observed and reported

41



PERT* Charts

Task Title

Slack Time

TaskDuration

Earliest Starting Date

Earliest Completion Date

*Program Evaluation and Review Technique

42



The Critical Path and Slack Time

43



The Critical Path and Slack Time

44



Cascading Slack Time

45



Gantt* Charts

I D Task Name Dura t i on S t a r t F i n i s h P r edeces so r s1 Design Robot 4 w Tue 9/3/02 Mon 9/30/022 Build Head 6 w Tue 10/1/02 Mon 11/11/02 13 Build Body 4 w Tue 10/1/02 Mon 10/28/02 14 Build Legs 3 w Tue 10/1/02 Mon 10/21/02 15 Assemble 2 w Tue 11/12/02 Mon 11/25/02 2,3,4

9/1 9/8 9/15 9/22 9/29 10/6 10/13 10/20 10/27 11/3 11/10 11/17 11/24 12/1 12/8September October November December

*developed by Charles Gantt in 1917

46



Some Pitfalls of Project Management

47




The schedule you develop will seem like a complete work of fiction up until the time your customer fires you for not meeting it.

48



Design Reference Missions

• Description of canonical mission(s) for use in design processes

• Could take the form of a narrative, storyboard, pictogram, timeline, or combination thereof

• Greater degree of detail where needed (e.g., surface operations)

• Created by eventual users of the system (“stakeholders”) very early in development cycle

49



Concept of Operations

• Description of how the proposed system will accomplish the design reference mission(s)

• Will appear to be similar to DRM, but is a product of the design, rather than a driving requirement

• Frequently referred to as “CONOPS”, showing DOD origins

50



Space Systems Architecture

• Description of physical hardware, processes, and operations to perform DRM

• Term is used widely (e.g., “software architecture”, “mission architecture”, “planning architecture”), but refers to basic configuration decisions

• Generally result of significant trade studies to compare options

51



ESAS Final Architecture/CONOPS

52



Earned Value Management

• Consider a simple program with four two-month tasks that are expected to cost various amounts

53

$4 M

$10 M

$6 M

$8 M

1 2 3 4 Months5

$2M $7M $8M $7M Planned monthly costs$4M



Program Cost Accounting

• Traditionally monitored by “burn rate” - cumulative expenditures with time

54

0

5

10

15

20

25

0 1 2 3 4 5

Months

Co

sts

($M

)

Cumulative



Earned Value Management - Month 1

• In the first month, you complete 60% of task 1 and 10% of task 2

• Actual costs for month 1 = $3 M EV=$3.4 M

55

$4 M

$10 M

$6 M

$8 M

1 2 3 4 Months5

EV(1)=0.6*4=$2.4 M

EV(2)=0.1*10=$1 M




• In the second month, you complete 100% of task 1 and 60% of task 2

• Actual costs for month 2 = $10 M EV=$10 M

56

$4 M

$10 M

$6 M

$8 M

1 2 3 4 Months5

EV(1)=1.0*4=$4 M

EV(2)=0.6*10=$6 M




• In the third month, you complete 100% of task 1, 80% of task 2, and 40% of task 3

• Actual costs for month 3 = $16 M EV=$14.4 M

57

$4 M

$10 M

$6 M

$8 M

1 2 3 4 Months5

EV(1)=1.0*4=$4 M

EV(2)=0.8*10=$8 M

EV(3)=0.4*6=$2.4 M



0

5

10

15

20

25

0 1 2 3 4 5

Months

Co

sts

($M

)

CumulativeActual

Program Cost Accounting - Tracking

• Plotting actual costs vs. time shows how money is spent, but doesn’t tell anything about how much work has been accomplished

58



• Earned value tracks accomplishments against their planned costs

• Variation shows schedule performance

0

5

10

15

20

25

0 1 2 3 4 5

Months

Co

sts

($M

)

CumulativeEarned Value


59



0

5

10

15

20

25

0 1 2 3 4 5

Months

Co

sts

($M

)

CumulativeEarned ValueActual

• Comparing earned value to actual costs shows “apples to apples” comparison of money spent and value achieved


60



Decision Analysis Tools• A number of different approaches exist, e.g.

– Pugh Matrices– Quality Function Deployment– Analytic Hierarchy Process

• Generally provide a way to make decisions where no single clear analytical metric exists - “quantifying opinions”

• Allows use of subjective rankings between criteria to create numerical weightings

• Not a substitute for rigorous analysis!

61



Analytical Hierarchy Process• Considering a range of options, e.g., ice cream

– Vanilla (V)– Peach (P)– Strawberry (S)– Chocolate (C)

• Could ask for a rank ordering, e.g. (1) vanilla, (2) strawberry, (3) peach, (4) chocolate - but that doesn’t give any information on how firm the rankings are

• Use pairwise comparisons to get numerical evaluation of the degree of preference

62



Pairwise Comparisons• Ideally, do exhaustive combinations

– Vanilla >> chocolate (strongly agree)– Vanilla >> peach (agree)– Vanilla >> strawberry (agree)– Peach >> chocolate (strongly agree)– Peach >> strawberry (disagree)– Strawberry >> chocolate (strongly agree)

• Number of required pairings out of N options is (N)(N-1)/2 - e.g., N=20 requires 190 pairings!

• Can use hierarchies of subgroupings to keep it manageable

63



Evaluation Metric

• Create a numerical scaling function, e.g.– “strongly agree” = 9– “agree” = 3– “neither agree nor disagree” = 1– “disagree” = 1/3– “strongly disagree” = 1/9

• Numerical rankings are arbitrary, but often follow geometric progressions– 9, 3, 1, 1/3, 1/9– 8, 4, 2, 1, 1/2, 1/4, 1/8

64



Evaluation Matrix

• Fill out matrix preferring rows over columns

65

C S P V

C

S 9

P 9 1/3

V 9 3 3



Evaluation Matrix

• Fill out matrix preferring rows over columns• Fill opposite diagonal with reciprocals

66

C S P V

C

S 9

P 9 1/3

V 9 3 3

C S P V

C 1/9 1/9 1/9

S 9 3 1/3

P 9 1/3 1/3

V 9 3 3



Normalization of Matrix Elements

• Normalize columns by column sums

67

C S P V

C 1/9 1/9 1/9

S 9 3 1/3

P 9 1/3 1/3

V 9 3 3

C S P V

C 0.032 0.018 0.143

S 0.333 0.491 0.429

P 0.333 0.097 0.429

V 0.333 0.871 0.491

27 3.44 6.11 0.78



Evaluation of Hierarchy Among Options

• Average across the populated row elements

68

C S P V

C 0.032 0.018 0.143

S 0.333 0.491 0.429

P 0.333 0.097 0.429

V 0.333 0.871 0.491

0.048

0.313

0.215

0.424 ⇐ Top ranking



Risk Tracking

• There are two elements of risk– How likely is it to happen? (“Likelihood”)– How bad is it if it happens? (“Consequences”)

• Each issue can be evaluated and tracked on these orthogonal scales

• This is not an alternative to probabilistic risk analysis (PRA) ⇒ discussed in a later lecture

69



Likelihood Rating Categories

1. Improbable (P<10-6)2. Unlikely to occur (10 -3>P>10 -6)3. May occur in time (10 -2>P>10 -3)4. Probably will occur in time (10 -1>P>10 -2)5. Likely to occur soon (P>10 -1)

70



Consequence Rating Categories

1. Minimal or no impact2. Additional effort required, no schedule impact,

<5% system budget impact 3. Substantial effort required, <1 month schedule

slip, >2% program budget impact4. Major effort required, critical path (>1 month slip),

>5% program budget impact5. No known mitigation approaches, breakthrough

required to resume schedule, >10% program budget impact

71



Risk Matrix

72



References (Available on Web Site)• NASA Systems Engineering Handbook - SP-6105 - June, 1995 [2.3 Mb, 164 pgs.]

(Obsolete, but nice description of NASA's systems engineering approach)

• NASA Systems Engineering Processes and Requirements - NPR 7123.1A - March 26, 2007 [3.6 Mb, 97 pgs.] (Current version - pages are almost impossible to read without a magnifying glass)

• NASA Space Flight Program and Project Management Requirements - NPR 7120.5D - March 6, 2007 [2.7 Mb, 50 pgs.] (Current version - pages are almost impossible to read without a magnifying glass)

• NASA Program and Project Management Processes and Requirements - NPR 7120.5C - March 22, 2005 [1.9 Mb, 174 pgs.] (Older, superceded version, but includes more figures and is readable by mere mortals)

• NASA Goddard Space Flight Center Procedures and Guidelines: Systems Engineering - GPG 7120.5B - 2002 [1.7 Mb, 31 pgs.]

• NASA Goddard Space Flight Center Mission Design Processes (The "Green Book") [860 Kb, 54 pgs.]

• NASA Systems Engineering “Toolbox” for Design-Oriented Engineers - NASA RP-1538, December 1994 [9.1 Mb, 306 pgs]

73




Capabilities drive requirements, regardless of what the systems engineering textbooks say.

74



System Project Teams

75

Team A1:Shallcross, MichaelKunnath, SarinSchaffer, MichaelMittra, Atin

Team A2:Zittle, Kyle Weber, KristyDownes, AlexanderKunnath, Sahin

Team A3:Ortiz, OliverAdamson, ColinPhillips, BrandynKumar, Rubbel

Team A4:Klein, DouglasSchneider, MarkKantzer, MichaelAdams, Matthew

Team A5:King, JenniferLevine, EdwardOuyang, WilliamGonter, Kurt

Team A6:Ferguson, KevinToothaker, CodyPatel, MihirRaghu, Nitin

Team A7:Feeney, MatthewCloutier, KyleGregorich, DonaldTodaro, Daniel

Team A8:Du Toit, CharlHorowitz, MatthewMuller, BrooksPashai, Pegah

Team A9:Kittur, ChandanChattopadhyay, Rajarshi Brassard, BriannaWallace, Mazi

Team A10:Moran, RyanGarcia, IrvingBhattarai, AshokGaray, SamuelMellman, Benjamin

Team A11(G):Borillo Llorca, IreneCarlsen, ChrisRodriguez, Jon



SDR Agenda (goals for Systems task)1. Identify Team Members2. Review Vision, Mission, Goal and Objectives of Project3. Review System Architecture (includes system definition, concept

and layout)4. Review Level 1 Requirements5. Review traceability of requirements “flow down” 6. Review Work Breakdown Structure (WBS)7. Review preferred system solution definition including major trades

and options. CAD model of physical components of system if available.

8. Review preliminary functional baseline9. Review draft concept of operations10. Review preliminary system software functional requirements11. Review risk assessment and mitigations approach12. Review analysis tools to be used13. Review cost and schedule data14. Review software test plan (approach)15. Review hardware test plan (approach)

76



Today’s ToolsYou should understand and be able to create and use

• Project scheduling (PERT and Gantt charts, critical path determination)

• Requirements definition and flow-down• Work breakdown structures• Risk definition charts• Design reference missions• Concept of operations• (Earned value management)• (Analytical hierarchy process)

77