Page History
...
| id | tabs-1 |
|---|
1. Requirements
2.2.7 The project shall select and document a software development life cycle or model that includes phase transition criteria for each life cycle phase (e.g., formal review milestones, informal reviews, software requirements review (SRR), preliminary design review (PDR), critical design review (CDR), test readiness reviews, customer acceptance or approval reviews).
1.1 Notes
NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.
1.2 Applicability Across Classes
Class D and Not Safety Critical and Class G are labeled with "P (Center)." This means that an approved Center-defined process which meets a non-empty subset of the full requirement can be used to achieve this requirement.
Class F is labeled with "X (not OTS)". This means that this requirement does not apply to software that is considered to be "Off the Shelf"
...
| f | * |
|---|---|
| g | p |
| h | 0 |
| ansc | 1 |
| asc | 1 |
| bnsc | 1 |
| csc | 1 |
| bsc | 1 |
| esc | 1 |
| cnsc | 1 |
| dnsc | p |
| dsc | 1 |
| ensc | 0 |
...
| id | tabs-2 |
|---|
2. Rationale
...
The requirements statement gives examples of the phase transition criteria that can be used for the software development activities. The transition criteria for the software work development can be selected from these examples, or others that apply to the project. Still other examples may be suggested through an examination of the Entrance and Exit Criteria (see Topic 7.9) for each of the major program/project formal reviews. Once agreed to by the project team and the software development team, these criteria, when satisfied, provide a common basis of agreement that the software work products are viable and sufficiently developed to proceed. Materials presented at major reviews serve as evidence in determining if the transition criteria are satisfied.
...
| id | tabs-3 |
|---|
3. Guidance
...
NASA Program and Project Life Cycles
...
Figure 3.1a Phases in a NASA program life cycle
Figure 3.1b Phases in a NASA project life cycle
The terms "Key Decision Point (KDP)" and "Gate" are nominally equivalent. The term "transition criteria" may signify an event which, when satisfied, allows a KDP or gate to be "passed" through.
...
The Generic Software Life Cycle
A generic life cycle model for software development, which is aligned to the NASA project life cycle, is shown in Figure 3.2. Concepts and Requirements are part of the common Formulation phase, while Design, Code & Test, and Release & Maintenance are part of the Implementation phase.
Figure 3.2 Phases of a generic software development life cycle
...
Types of Software Life Cycles
...
• The Standard Waterfall Life Cycle
This strategy consists of performing the applicable processes sequentially during a development. Typically, they are:
- Requirements specification (requirements analysis).
- Software design.
- Coding (implementation).
- Integration (implementation).
- Testing (verification).
- Maintenance.
Figure 3.3a Schematic of Standard Waterfall Model
...
• The Standard Incremental Life Cycle
This life cycle model determines user needs, develops all the systems level requirements, and then performs the rest of the development process in a series of builds. Each successive build adds on to the capabilities encoded in the prior cycle, until the software work product is complete. Typically, high risk or major functions are developed in early builds.
Figure 3.3b Schematic of Standard Incremental Life Cycle Model
Each build has its own set of requirements, design, code, test, and integration activities. The Incremental life cycle requires that the full system design be completed early and that module interfaces be well-defined. This life cycle works best when most requirements are known early, but allows those requirements to evolve over time.
• The Evolutionary (iterative) Life Cycle
This life cycle model utilizes the concept of software partial release, capability evolution, new release, and so forth until the mature software work product is obtained. Each evolutionary cycle includes all or most of the life cycle phases in the waterfall model. This life cycle process is typically characterized by the idea that not all of the system requirements are known at the start of the development process. The evolutionary life cycle is typically used when requirements are not well known and are subject to change.
• The Standard Spiral Life Cycle
A key characteristic of a spiral model is the use of risk management at regular and repetitive stages in the development cycle. The spiral model is actually a series of maturing prototypes with each prototype building on the previous prototype. Each prototype is developed in four phases: planning (determine objectives for the current spiral), risk analysis, engineering (design, development, or test), and evaluation (review and replan the next spiral).
Figure 3.3c Schematic of Standard Spiral Model
The spiral model can be visualized as a process passing through some number of iterations, with a four quadrant diagram being used to represent the four phases. Software is produced in the engineering phase. Testing, when it begins, also occurs in the engineering phase of the life cycle model. In the visualization, the angular component of the spiral represents progress, while the radial component represents time and/or cost. The software development process using the spiral approach will pass iteratively through each of these phases until the work product is complete with all requirements and stakeholders being satisfied.
The spiral life cycle is typically used when requirements are not well understood or are extremely complex and prototype software can be used to help flush out firmer requirements.
...
Tailoring of Life Cycles
Individual projects developing software may benefit by tailoring the basic elements, the key decision points, the major review events, and/or the major work products that are to be developed in each phase of the chosen life cycle. The software development lead determines the appropriate life cycle, along with any modifications, that aligns its efforts with the needs of the overall project. The reviews and work products that arise from a tailored life cycle need to be integrated with the overall project life cycle to maintain schedule consistency. The decision to use a tailored software development life cycle does not affect the requirements specified for the software work products. Any needed modifications or inconsistencies caused by the decision to use a modified life cycle model must be managed by the corrective action and change control processes (see SWE-025 and SWE-053).
Additional guidance related to the software development life cycle may be found in the following related requirements in this Handbook:
...
...
Software Development/Management Plan
...
...
Software Maintenance Plan
| Div | ||
|---|---|---|
| ||
4. Small ProjectsSmaller projects may consider less formal approaches to the life cycle model concept. The agile approach, which relies on testing and feedback, may be more suitable to a smaller project. |
...
| id | tabs-5 |
|---|
5. Resources
...
| toolstable |
|---|
| Div | ||
|---|---|---|
| ||
6. Lessons LearnedNo Lessons Learned have currently been identified for this requirement. |
