1. Requirements

3.2.3 The project manager shall submit software planning parameters, including size and effort estimates, milestones, and characteristics, to the Center measurement repository at the conclusion of major milestones. 

1.1 Notes

NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.

1.2 History

1.3 Applicability Across Classes

Key:    - Applicable | - Not Applicable

2. Rationale

NASA software measurement programs are designed to provide specific information necessary to manage software products, projects, and services.  For these programs to be current and accurate, certain center measurements (such as size and effort estimates, milestones, and characteristics) are provided to the Center repository at the end of the major project milestones. Defined software measurements are used to make effective management decisions by Center Management. Historical measurement data can also be used to improve aspects of future projects such as cost estimation.

3. Guidance

Refer to 5.08 - SDP-SMP - Software Development - Management Plan for more information on software planning parameters. At a minimum the following software planning data is defined and submitted at major milestones for the project:

• Software size: planned and the actual number of units, lines of code, or other size measurements over time.

• Effort: planned and actual workforce and hours.

• Milestones: planned and actual schedule dates (Start and Completion).

• Characteristic: uniquely identify the project and its work products and major features

• • Software characteristics are sometimes called software attributes. These basic characteristics are necessary for developing cost models, planning aids, and general management principles. Software characteristics are used to help uniquely identify the project and its work products, along with its major features.
    
    
• Examples of software cost parameters are: 
  • Required Software Reliability                
  • Database Size
  • Product Complexity
  • Developed for Reusability
  • Documentation Match to Life-Cycle Needs
  • Execution Time Constraint
  • Analyst Capability
  • Programmer Capability
  • Personnel Continuity
  • Applications Experience
  • Platform Experience
  • Language and Tool Experience
  • Multisite Development
  • Required Development Schedule
  • Development Flexibility
  • Architecture / Risk Resolution
  • Team Cohesion
  • Process Maturity
  • Main Storage Constraint
  • Platform Volatility
  • Use of Software Tools
  • Precedentedness

These software planning parameters are also be submitted to the repository at the end of each major milestone defined in the 5.08 - SDP-SMP - Software Development - Management Plan. Actual cost and effort estimates are also captured at the end of the project.

The software planning parameters can be documented in the 5.08 - SDP-SMP - Software Development - Management Plan. As stated in Topic 7.18 - Documentation Guidance, “The Software Development or Management Plan provides insight into, and a tool for monitoring, the processes to be followed for software development, the methods to be used, the approach to be followed for each activity, and project schedules, organization, and resources. This plan details the system software, project documentation, project schedules, resources requirements and constraints, and general and detailed software development activities.” It is important to keep the plan up to date throughout the project life cycle. Refer to Topic 7.08 - Maturity of Life-Cycle Products at Milestone Reviews for expected plan maturity and updates at various life-cycle milestones.

4. Small Projects

Small Projects should consider the value of capturing and tracking these elements (each center should define what is a small project). The value and benefit need to be determined for the project and organization.  If an organization only does small projects then the value of collecting data may be important to future business and process improvement.

5. Resources

5.1 References

5.2 Tools

6. Lessons Learned

6.1 NASA Lessons Learned

No Lessons Learned have currently been identified for this requirement.

6.2 Other Lessons Learned

No other Lessons Learned have currently been identified for this requirement.

7. Software Assurance

7.1 Tasking for Software Assurance

1. Confirm that all the software planning parameters, including size and effort estimates, milestones, and characteristics, are submitted to a Center repository.

2. Confirm that all software assurance and software safety software estimates and planning parameters are submitted to an organizational repository. 

7.2 Software Assurance Products

• Issues and risks discovered are brought to the attention of management.

  
  

  Objective Evidence

  • Evidence that the software planning parameters, including size and effort estimates, milestones, and characteristics, have been submitted to a Center repository.

  • Evidence that the software assurance and software safety software estimates and planning parameters have been submitted to an organizational repository. 

   Definition of objective evidence

  Objective evidence is an unbiased, documented fact showing that an activity was confirmed or performed by the software assurance/safety person(s). The evidence for confirmation of the activity can take any number of different forms, depending on the activity in the task. Examples are:

  • Observations, findings, issues, risks found by the SA/safety person and may be expressed in an audit or checklist record, email, memo or entry into a tracking system (e.g. Risk Log).
  • Meeting minutes with attendance lists or SA meeting notes or assessments of the activities and recorded in the project repository.
  • Status report, email or memo containing statements that confirmation has been performed with date (a checklist of confirmations could be used to record when each confirmation has been done!).
  • Signatures on SA reviewed or witnessed products or activities, or
  • Status report, email or memo containing a short summary of information gained by performing the activity. Some examples of using a “short summary” as objective evidence of a confirmation are:
    • To confirm that: “IV&V Program Execution exists”, the summary might be: IV&V Plan is in draft state. It is expected to be complete by (some date).
    • To confirm that: “Traceability between software requirements and hazards with SW contributions exists”, the summary might be x% of the hazards with software contributions are traced to the requirements.
  • The specific products listed in the Introduction of 8.16 are also objective evidence as well as the examples listed above.

7.3 Metrics

•  Comparison of initial SA cost estimates vs. final cost (capturing assumptions and differences)
• Trend the software assurance cost estimates through the project life cycle.
• Planned SA resource allocation versus actual SA resource allocation.
• # of detailed software requirements vs. # of estimated SLOC to be developed by the project

7.4 Guidance

Confirm that the project has submitted the software planning parameters, including size and effort estimates, milestones, and characteristics, to the Center measurement repository at the conclusion of each major milestone. The actual cost and effort should also be captured at the end of the project.

Examples of software cost parameters are:

• Required Software Reliability                
• Database Size
• Product Complexity
• Developed for Reusability
• Documentation Match to Life-Cycle Needs
• Execution Time Constraint
• Analyst Capability
• Programmer Capability
• Personnel Continuity
• Applications Experience
• Platform Experience
• Language and Tool Experience
• Multisite Development
• Required Development Schedule
• Development Flexibility
• Architecture / Risk Resolution
• Team Cohesion
• Process Maturity
• Main Storage Constraint
• Platform Volatility
• Use of Software Tools
• Precedentedness

Set up an SA organization repository. After each major milestone, review the repository contents to confirm that all SA software estimates and planning parameters exist. If any information is missing, update the repository content with the required information. At the end of the project, submit actual SA cost and effort estimates to the repository.  Annually or on some other periodic schedule, audit or assess the SA organization repository for the previously completed project to ensure all estimate and planning information exists in the repository.

Confirm the software planning documentation includes the metrics and measurements to be collected and assessed for the software project.  Including, but not limited to the project size and estimate of effort, software project milestone (s) planned and actual dates, specific software characteristics which may include requirement volatility, software risk management, software performance, or software usability.