1 / 14

Spiral Models and Paradigms

SAM Executive Seminar. Spiral Models and Paradigms. George Prosnik DAU CDSC E&T Center. System and Software Engineering Process Linkages. Systems Engineering, Hardware Design and Development Activities. System Requirements Analysis. Long Lead SW Items. Test Qualification

indra
Télécharger la présentation

Spiral Models and Paradigms

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SAM Executive Seminar Spiral Models and Paradigms George Prosnik DAU CDSC E&T Center

  2. System and Software Engineering Process Linkages Systems Engineering, Hardware Design and Development Activities System Requirements Analysis Long Lead SW Items Test Qualification Analysis Allocated Baseline Information SI Delivery Prototyping Needs Review Support Configuration Item Identification T & E Results Software Engineering and Development Activities Rev 3.4

  3. WaterfallParadigms IncrementalParadigms SpiralModels Grand Design P3I Acquisition Approach Evolutionary Software Development Paradigms System Acquisition Strategy Rev 5.0

  4. DT and OT&E Testing System SubsystemIntegrationandTesting System System Qualification Requirements Testing Analysis Sub Sys HIandSIIntegrationandTesting System Design Software SoftwareItemQualification SI SI HIs SI Requirements Testing Analysis Software Software SWUnitIntegration Units Software Units andTesting Software Units Design Software Software UnitTesting UnitCoding Systems & Software Development

  5. Systems Acquisition Life Cycle Note: the linkage between a Waterfall paradigm and the underlying system acquisition life cycle can vary widely from this notional diagram. E.g., starting and stopping points may depend on acquisition/contract strategy. Multiple Waterfalls may be required over the total acquisition life cycle, etc. System Require- ments Analysis System Design SW Require- ments Analysis Management Issues Excessive Documentation Acquisition Life cycle Linkage User Participation Late product visibility Software Design Implement & Unit Test Unit Integ & Testing SI Qual Testing SI/HI Testing System Testing “Waterfall” Software Development Paradigm • KEY CHARACTERISTICS • Do steps in a specified order • Define ALL requirements up front • Use comprehensive reviews as gates • Complete program design before coding • Emphasizes Functional & Allocated baselines • Elaborate SW design via extensive documentation • “Do the job twice if possible & involve the customer” Rev 4.4

  6. How do you eat the software elephant?? One Byte at a time! System Req’ts Analysis System Design Software Req’ts Analysis Software Design Testing and Integration Coding & Unit Testing Software Design Testing and Integration Coding & Unit Testing Software Design Testing and Integration Coding & Unit Testing SI/HI Testing System Qual Testing Management Issues: Baseline Control, Staff Loading, Phasing of Requirements, Definition of “Incremental” Incremental Development (one of many variations!) • KEY CHARACTERISTICS • Define requirements before building • Develop and code the system in a sequence of builds • Each build incorporates part of the planned capabilities • Development phases overlap • Software design may begin before software requirements analysis complete • Multiple configurations in development Rev 5.1

  7. Prototype #1 Prototype #2 Prototype #3 Management Issues: Control of Prototypes; Scaling Issues; “Phantom Data”; Subversion of Disciplined Life Cycle; User Involvement & Ownership; Baseline Control Prototyping and Insight Level of Understanding I N S I G H T • Prototype to: • Refine requirements • Assess affordability • Evaluate algorithms • Make cost/performance trades • Reduce risk on critical subsystems • Determine operational effectiveness • Assess User interfaces • Mitigate technology integration • Unconstrained development • Minimal/informal documentation • Tie prototypes to risk mitigation • “Think about” and document: • Prototype’s goals and purposes • Relationship of prototype to final product • Lessons to be learned or concepts proven • Completion or success criteria • Plans for monitoring the prototype effort Rev 4.3

  8. Management Issues: Floating Baselines, Process Visibility, Risk Management, Prototype Control, Funding, “Fielding” Decision, Many Look-Alike Variations of “Spiral Models” SPIRAL MODEL PARADIGMS • KEY CHARACTERISTICS • Concurrent determination of key artifacts done throughout lifecycle • Level-of effort and degree of detail are risk driven • Prototype feedback essential • “Anchor points” should be used as intermediate milestones • Emphasis should be on system-level lifecycle activities and artifacts • Objectives, risk, alternatives, reviews and commitment to proceed done for each cycle Risk Analysis ID & resolve RISKS Determine Objectives and Constraints Prototyping Activities START Plan next Phase Develop & Verify Next Level Product Vers 2.0

  9. DOD-STD-2167A MIL-STD-499A MIL-STD-973 Hardware Reqts Analysis Preliminary Design MIL-STD-1521B Detail Design Hardware Fabrication PDR DOD-STD-7935A HWCI Testing FCA PCA CDR System Integrate & Testing System Design System Reqts SRR SDR CDR PDR S Y S T E M E N G I N E E R I N G T&E TRR CSCI Testing FCA CDR PCA CSC Integ & Testing PDR Coding & CSU Test SSR Detailed Design Prelim Design Software Reqts Analysis Project Planning Software CM Software QA System Design Prepare for SW Transition SW Design Corrective Process Software Dev Environment Prepare SW for Use System Qual Test Joint Tech & Mgt Reviews Unit Integration and Testing Software & Hardware Integration & Test Software Product Evals SW Implementation and Unit Testing Software Item Qualification Testing SW Req’ts Analysis System Req’ts Analysis “Here are all the pieces. Tailor out what you don’t need” Old DoD MILSPEC approach to DoD System and Software Development “Here are all the pieces. Put them together in the best way that makes sense for your particular program!” ISO 12207 J-STD-016-1995 IEEE/EIA 12207 Systems and Software Development 1.1

  10. Others ... Systems & Software Standards* EIA/ANSI 632 Jan 1999 Systems Engineering Standards EIA 632 1994 EIA / IS 632 (Updates) EIA/IS 731 SE CMM (Full Standard) 1994 (Interim) Mil-Std-499B 1974 1994 Mil-Std-499A 1969 Jan 1999 IEEE 1220 ISO 15288 Mil-Std-499 (Not Released) IEEE 1220 (Trial Use) IEEE 1220 (Full Standard) Legend (Updates) Supersedes Source for Software Standards (Updates) 1995 ISO/IEC 12207 1988 ISO/IEC 12207 DoD-Std-2167A 1987 1998 DoD-Std-1703 IEEE/EIA 12207.x 1994 1996 Mil-Std-498 IEEE 1498 /EIA 640 1988 J-Std-016 1997 DoD-Std-7935A (Drafts) *Based on SMI INCOSE Nov 97 presentation Rev 1.1

  11. Some Key Tailoring Preconditions* • What organizational policies (languages, safety, security, reserve margins, etc.) apply? • What Acquisition Strategy is being used? • What software builds are envisioned? • What activities are required in each build? • What is the role of IV&V agents? • What is the software support concept? • What lifecycle model is relevant and applicable? • Which system lifecycle activities are applicable? • How are Software Items (SI) selected? • What types of software products (new, NDI, firmware, embedded, COTS, etc.) are envisioned? • What management controls (testing, reviews,etc.) are needed? • What deliverables are needed and why? Format? • Who will tailor deliverable content? Before any standard can be successfully use by a developer, these types of questions must have been considered by the acquirer! *Derived from Annex B J-STD-016 and Annex B.4 ISO 12207.0 Rev 1.1

  12. Elephant Bungee Wisdom • Universal Truth # 6: Shortcuts in software configuration management lead to chaos when the “rubber hits the road” • Management Emphasis • Use review boards to enforce CM • Allow no exceptions to CM rules • Anything that is shared by two or more people should come under configuration control Elephant Bungee Jumping # 6: Help…I’ve Fallen and I Can’t Get Up

  13. Elephant Bungee Wisdom • Universal Truth # 10: Cutting-edge software development tools lead to bleeding edge projects • Management Emphasis • Use only established technologies • Reduce requirements if necessary to avoid cutting-edge technologies • Add reserve margins to the project to account for these technologies • If cutting edge technologies must be used for software development, make them your no. 1 risk item Elephant Bungee Jumping # 10: Cutting Edges and Bloody Mistakes

  14. Elephant Bungee Wisdom • Universal Truth # 15: Avoid ping pong developments like the plague • Management Emphasis • Control deliverables via interfaces • Make deliverables testable in a stand-alone mode prior to integration • Keep the skill base to correct code on contract until until final transition • Don’t allow modules to be shuttled between different developers • Make subcontractor management a key contractual clause • Dispersed contractors increase risk Elephant Bungee Jumping # 15: Self-Eating Watermelons

More Related