16.842/16.355 class 3 notes

16.842/16.355Class 3 Notes

Factors That Influence Process

Waterfall Model

• Ideal or generic process that needs to be tailored for specific project• Often used as strawman, maligned, and mischaracterized (e.g., omit all feedback loops)

Features of the Waterfall Model

• A phased development process with clearly identified milestones

• Deliverables and baselines with each phase, results of each phase “frozen” (but can be changed later if necessary)

• Reviews at each phase

• Document-driven process (really deliverable driven, but deliverables in early phases are often documents)

• “Big Bang” testing vs. stubs vs. daily build and smoke test

• “A Rational Design Process and How to Fake It”– Strict sequencing between activities not usually obeyed

Feasibility Study (used to be called System Analysis)• Definition of problem• Alternate solutions and expected benefits• Required resources, costs, delivery dates for each proposed solution• Economic feasibility and technical feasibility (can hardware and software deliver performance required?)• Risk identification

Requirements:• What, not how• Contract with customer• Used to engineers to develop solutions

-- Careful analyses: goal is to prevent putting too much effort into constructing a system that does not satisfy user’s requirements

Requirements

• Need to consider project goals– Minimize development costs?– Minimize development time?– Maximize quality– Realism important: Faster, Better, Cheaper (choose two)– Separate essential from nice features

• Try to predict possible future requirements (product “families”)

• Identify environment and interactions with environment

• “Coding” a very small part of any development effort (7%)• Design (architecture) important but often rushed to get to coding• Test usually about 50% of development effort

“V” Model

Systems EngineeringOverview

Stakeholder Analysis

RequirementsDefinition

System ArchitectureConcept Generation

Tradespace ExplorationConcept Selection

Design DefinitionMultidisciplinary Optimization

System IntegrationInterface Management

Verification andValidation

CommissioningOperations

Lifecycle Management

Human Factors

SystemSafety

16.842 Fundamentals of Systems Engineering

“V-Model”

“V” Model/ Waterfall Model

• Phases are delineated by review processes

Air Force

NASA Program & Project Life Cycles

NASA Life Cycle Phases

ProjectLife Cycle Phases

Pre-Phase A:ConceptStudies

Phase A:Concept & Technology

Development

Phase B:Preliminary Design &

Technology Completion

Phase C:Final Design &

Fabrication

Approval for Implementation

FORMULATION IMPLEMENTATION

KDP CProject Life Cycle Gates & Major Events

Operations Pre-Systems Acquisition Systems Acquisition

Phase E:Operations

& Sustainment

KDP A

Launch

KDP D

Phase D:System Assembly, Int & Test, Launch

KDP B

Phase F:Closeout

Decommissioning

End of Mission

FOOTNOTES1. Flexibility is allowed in the timing, number, and content of reviews as long as the

equivalent information is provided at each KDP and the approach is fully documented in the Project Plan. These reviews are conducted by the project for the independent SRB. See Section 2.5 and Table 2-6.

2. PRR needed for multiple (≥4) system copies. Timing is notional.3. CERRs are established at the discretion of Program Offices.4. For robotic missions, the SRR and the MDR may be combined.5. The ASP and ASM are Agency reviews, not life-cycle reviews.6. Includes recertification, as required. 7. Project Plans are baselined at KDP C and are reviewed and updated as required, to

ensure project content, cost, and budget remain consistent.

Final Archival of Data

KDP F

SMSR, LRR (LV), FRR (LV)

KDP E

Peer Reviews, Subsystem PDRs, Subsystem CDRs, and System Reviews

DRPLARMDR4

Robotic Mission Project Reviews1

MCR SRR PDR CERR3SIR FRR

ACRONYMSASP—Acquisition Strategy Planning MeetingASM—Acquisition Strategy MeetingCDR—Critical Design ReviewCERR—Critical Events Readiness ReviewDR—Decommissioning ReviewFAD—Formulation Authorization DocumentFRR—Flight Readiness ReviewKDP—Key Decision PointLRR—Launch Readiness ReviewMCR—Mission Concept ReviewMDR—Mission Definition ReviewNAR—Non-Advocate Review

ORR—Operational Readiness ReviewPDR—Preliminary Design ReviewPFAR—Post-Flight Assessment ReviewPLAR—Post-Launch Assessment ReviewPNAR—Preliminary Non-Advocate ReviewPRR—Production Readiness ReviewSAR—System Acceptance ReviewSDR—System Definition ReviewSIR—System Integration ReviewSMSR—Safety and Mission Success Review SRR—System Requirements Review

FAD

Draft ProjectRequirements

Launch Readiness Reviews

SDR CDR / PRR2

PDRMCR FRRSRR SIR CERR3PLAR SAR

Human Space Flight Project Reviews1

Re-flights

DR(NAR)(PNAR)

Supporting Reviews

ORRInspections and Refurbishment

Re-enters appropriate life cycle phase if modifications are needed between flights6

End of Flight

PFAR

Preliminary Project Plan

Baseline Project Plan7

ASP5

ORR

ASM5

(NAR)(PNAR)CDR / PRR2

AgencyReviews

NASA

Evolutionary Model

• Prototyping – “Do it twice”– To assess feasibility

– To verify requirements

• May only be – A front end or executable specification (“very high level”

languages or front end for user interface)

– Or develop system with less functionality or quality attributes (speed, robustness, etc.)

Differences with Hardware Prototyping?

Evolutionary Model (2)• 3 approaches

1. Use prototyping as tool for requirements analysis.

2. Use to accommodate design uncertaintya. Prototype evolves into final product

b. Documentation may be sacrificed

c. May be less robust

d. Quality defects may cause problems later (during ops and maintenance -- Incorporating quality after system built is impossible or

extremely costly

3. Use to experiment with proposed solutions before large investments made

Evolutionary Model (3)

• Drawbacks– Can be expensive to build

– Can develop a life of its own, turns out to be product itself

– Hard to change basic decisions made early

– Can be an excuse for poor programming practices

Experimental Evaluation

• Boehm: prototyping vs. waterfall for software– Waterfall:

• Addressed product and process control risks better

• Resulted in more robust product, easier to maintain

• Fewer problems in debugging and integration due to more thought-out design

– Prototyping• Addressed user interfaces better

• Alavi: prototyping vs. waterfall for an information system– Prototyping: users more positive and more involved

– Waterfall: more robust and efficient data structures

24

Incremental Model

Communication PlanningModeling

ConstructionDeployment

Communication PlanningModeling

ConstructionDeployment

Communication PlanningModeling

ConstructionDeployment

Increment #1

Increment #2

Increment #3

Incremental Model

• Functionality produced and delivered in small increments

• Focus attention first on essential features and add functionality only if and when needed

• Systems tend to be leaner, fights overfunctionality syndrome

• May be hard to add features later– CLCS (tried to add fault tolerance later)

– Need to be careful about what put off. Requires very complex analysis and deep knowledge to do this right.

• Does this work for large, complex systems?

Incremental Model Variant

• Incremental implementation only– Follow waterfall down to implementation

– During requirements analysis and system design• Define useful subsets that can be delivered

• Define interfaces that allow adding later smoothly

– Different parts implemented, tested, and delivered according to different priorities and at different times

Spiral Model • Includes every other model• Risk-driven (vs. document driven or increment driven)• Radius of spiral represents cost accumulated so far

Considerations

• Do you need one uniform process over whole project? e.g., in requirements analysis, identify aspects that are uncertain Library system:

Checkout and Checkin (inventory control): Relatively certain

Card catalogue and user search: Relatively uncertain

Then have different processes for separate parts

Software Factory• Most software organizations strictly separated between

initial development and later maintenance– No incentive to produce a system that can be easily

maintained

– No incentive to produce reusable components

• Project management vs. product management

• Extend management responsibility to cover family of products rather than an individual product (product families)

What is CMMI?

CConsultantonsultant

MMoneyoney

MMakingaking

IInitiative nitiative

Critique of CMMI

““The projects most worth doing are the ones that will move The projects most worth doing are the ones that will move you DOWN one full level on your process scale” you DOWN one full level on your process scale” (Peopleware) [3](Peopleware) [3]

CMM (Capability Maturity Model)• Comes from Taylorism (“scientific management”,

statistical quality control)– Maximize efficiency by rational planning procedures

– Assembly lines, time and motion studies (Henry Ford)

– Behavior of individual controlled by normative rules and preplanned by system design

– Projects achieve control over their products and processes by narrowing the variation in the process performance to fall within acceptable quantitative boundaries

CMM (Capability Maturity Model) (2)• Despite rhetoric, does not follow TQM

– TQM emphasizes flexibility and learning

– Learning orientation seeks to increase variation in order to explore opportunities

• CMM focuses on narrowing variation

– Formal bureaucratic control undermines intrinsic motivation needed for creative and flexible responses to uncertainty

Senge: Humanistic values of caring and individual freedom are essential to building learning organizations

Carroll: “In too many TQM programs, it is the difficult-to-implement portions of the program that are being finessed or ignored and the rhetoric that is being retained.”

CMM Criticisms• Treats people as assembly line workers, i.e., replaceable,

unreliable

• Humans are subordinated to defined processes

• Why emphasis on “repeatable”?

• Why five levels? Why a rigid order?– Peer reviews at level 3? Defect prevention at level 5?

• Creates inflexible organizations and the illusion of control?

• Places focus on the wrong things

• Does this just ensure mediocrity? – Great software/hardware projects have done the opposite– Skunkworks, Apple (Mac), some Microsoft products

CMM Criticisms (2)Bollinger

• Process improvement more than simply adding good measurement and controls to a project

• Must address much deeper and uniquely difficult issue of how to distribute creative, intelligent problem-solving across a group of heterogeneous individuals.

• Make group IQ improvement a major issue– Group stupification when process metrics structured

around repetition– Use people for problem solving, don’t try to turn people

into machines

More

• Experimental validation?

• Industry experience?

CMMI vs. Agile, XP, etc.PEOPLE

TECHNOLOGYProcess

PEOPLE

Process Technology

Readings?