Key Management Issues for Software Reviews Requirements Communication How have prototyping results been used? What is still unknown? Are these requirements testable? Software Allocation Sum of parts equals whole? Reasonableness? Function and Performance Covered? Software Architecture Clearly Defined? JTA Compliant? Degree of Openness? Domain-specific tie-ins? Performance and scalability considered? Traceability To Which Baselines? Are Derived Requirements Understood? Evidence of a stable, well-defined Process? How is Configuration Control being done? Do Metrics match the developer’s rhetoric? Design Progress—Reasoned Choices? Tie-in to Hardware Development Visible? Cost & Schedule Feasibility Demonstrated? Test & Support Viability being Considered? Do Supporting Analyses for next level Exist? What is the level of risk in the program now? “How do you know?” “What does that mean?” “Can you show me?” Management Issue: Within existing commercial standards, there is a smorgasbord of available reviews. Review content, phasing, and timing should be program dependent, integrated, and risk driven. Imposing an inflexible schedule-driven review structure on a software developer is asking for trouble! Rev 1.3

Software Development: A Lifecycle Review Focus OCD SSS SSDD IRS DBDD SDD IDD CODE “As Built” Info Interfaces CSCI ID’d CSCIs Design System Software Interface Perspective Operational Requirements Database SRS Test Plans Planning Test Views User USER NEEDS What’s ‘Supposed’ To Happen? Software Development: A Lifecycle Review Focus SRR SDR ASR SFR SSR PDR Initial Stage Design & Review Activities Intermediate Stage Design & Review Activities CDR TRR PRR SVR PCA Functional Baseline Final Stage Design & Review Activities Allocated Baseline(s) KEY SOFTWARE FACTORS Are requirements traceable to operational mission profiles? Is top-level requirements allocation reasonable? Are software and hardware allocations realistic? Has a software architecture been established? Is it reasonable? Have realistic computer resource utilization limits been established? Have communication and interface requirements been established? Have critical requirements (safety, security, privacy) been specified? KEY FACTORS--SOFTWARE Have software requirements been established? Are they prioritized? Are derived requirements understood? Have conditions for software acceptance been established? What modifications are needed as a result of prototype testing? What are reuse & COTS levels? Are personnel, training and support impacts understood? What exception conditions/capacity limits have been taken into account? Have CSCIs been elaborated into Units? Is the breakout reasonable? Product Baseline(s) KEY FACTORS--SOFTWARE Do results of Detailed Design support subsequent coding and implementation activities? Are interfaces specified in sufficient detail to support coding and implementation? What systems are in-place for software configuration management during Post Deployment Software Support? How will changes be incorporated into the fielded software? Do results of software tests to date verify performance, reliability, safety, security and other critical requirements? PM Note: A variety of “Joint Management Reviews” to manage software development is suggested by commercial software development standards. Unlike the ineffective massive reviews historically used on DoD programs, these reviews are envisioned as more frequent, incremental and smaller in scope. Rev 3.0