1. 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

2. 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