Archive of Supporting Materials « LaRC Software Engineering (SWE) Process Improvement Initiative (SPII)

This page contains examples, guidance, and tools for earlier revisions of NPR 7150.2 and LPR 7150.2. These items may still provide some value to helping projects adhere to the Agency and Center software engineering requirements. However, they are now incomplete with respect to recent revisions of governing documents and they reference obsolete governing documents (including cancelled center procedures for software engineering).

Examples, Guidance, and Tools (Listed Alphabetically)

Class D Example 1 – Completed Documents from a Real Project: Contains actual products produced by a real Class D project following LMS-CP-7150.5. It includes a complete Software Management Plan, Software Configuration Management Plan, Software Requirements Specification, and Compliance Matrix for Class D. It also includes a partially complete Software Test Plan and Software Version Description. All of the above were completed in 4 ½ hours. This is a streamlined implementation of LMS-CP-7150.5 for a Class D software activity involving only one civil servant developer, working part time. The black and gray text is a straight cut and paste from LMS-CP-7150.5. The green text is what the project entered under each requirement to fulfill it. All project names have been changed for anonymity. Examples of the required Software Assurance Classification Report and the associated Software Inventory information are also provided. (THANK YOU Research Directorate for this valuable contribution and others below!)
Class D Example 2 – Software Management Plan (SMP) template for Class D: Contains a template for developing a Class D SMP. It is packed full of guidance, instructions, and examples to use in developing your own Class D SMP by customizing it to your particular project and trimming out what is not needed. (For example, the Diagram of the Organizational Structure has almost every imaginable stakeholder; so you simply delete the stakeholders you don’t need and rename the remaining ones to your specific stakeholders.) As is, the SMP complies with all the requirements in LMS-CP-7150.5 Class D Software. Take care in deleting text statements that end with [SWE-###] since they fulfill specific LMS-CP-7150.5 requirements. They must be replaced with something equivalent or obtain approval for tailoring or waiver.
Class D Example 3 – Release of Class D Heritage Software: These documents provide examples of some of the items needed for release of completed heritage software. The Compliance Matrix and Software Management Plan, CM Plan, Software Version Description provide examples of fulfilling LPR 7150.2 Langley Software Engineering Requirements, LMS-CP-7150.5 Class D Software and answers to some of the questions on Form 7: Software Release Request Authorization (Mar 2013) all of which are required to release software. Examples of the required Software Assurance Classification Report and the associated Software Inventory information are also provided.
Class D Example – (Additional examples to be completed. We are looking for real examples, please volunteer by sending email to larc-dl-support-sepg-help@mail.nasa.gov)
Class E Example 1 –Branch Level Class E SMP: Contains an actual Branch Level Class E Software Management Plan (SMP). This one plan is use as the SMP for all Class E projects or tasks in the Branch. The Branch Head simply replaces the green highlighted text of the plan with the specific Branch information requested, has all the Software Leads/Software Managers in the Branch sign the plan showing their agreement to executing the plan content, and has one line of information added to “Attachment 1, Branch Software Project/Task List” for each existing and new Class E software Project/Task. This is a very low effort, efficient way of fulfilling the LMS-CP-7150.6, Class E Software SMP requirements. An example Software Inventory information is also provided.
Class E Example 2 – Release of Class E Heritage Software: These documents provide examples of some of the items needed for release of completed heritage software. The Compliance Matrix and Software Management Plan provide examples of fulfilling LPR 7150.2 Langley Software Engineering Requirements, LMS-CP-7150.6 Class E Software and answers to some of the questions on Form 7: Software Release Request Authorization (Mar 2013) all of which are required to release software. Examples of the required Software Assurance Classification Report and the associated Software Inventory information are also provided.
Class E Example 3 – SMP For Group Of Codes From Real Task: Contains an real project Software Management Plan (SMP) that covers a group of Class E codes. This one plan is use as the SMP for all Class E codes that the Task Lead/Researcher has. The Task Lead simply replaces the green highlighted text of the plan with the specific task information requested. Then the Task Lead signs the plan and the Branch Head signs the plan showing their agreement to executing the plan content, and the SMP has one line of information added to “Attachment 1, Task List” for the existing group of codes and for each new Class E code or group of codes. This is a very low effort, efficient way of fulfilling the LMS-CP-7150.6, Class E Software SMP requirements. The associated Software Assurance Classification Report and Software Inventory are also provided.
Class E Example – (Additional examples to be completed. We are looking for real examples, please volunteer by sending email to larc-dl-support-sepg-help@mail.nasa.gov)
Guidance on Selecting Life Cycle and Development Approach R1V4
Manager’s Handbook for Software Development (Revision 1) : Methods and aids for the management of software development projects are presented. The recommendations are based on analyses and experiences of the Software Engineering Laboratory (SEL) Goddard Space Flight Center with flight dynamics software development. The management aspects of the following subjects are described: organizing the project, producing a development plan, estimating costs, scheduling, staffing, preparing deliverable documents, using management tools, monitoring the project, conducting reviews, auditing, testing, and certifying.
Matrix of NASA and IEEE Software Standards and Guides : provides recomendations and discriptions of NASA andIEEE Software Standards and Guides.
Programmer’s Guide : This document is a collection of style and implementation rules for developing code in a specific organization. The rules are based upon the experience of the Configuration Control Board and on rules and recommendations published in the cited reference documents.
Project Measures Table R1V0 : Based on the project’s information needs and goals, select and identify specific measures to achieve project objectives. This Table lists some sample measures.
ProjectStatusIssuesRiskWorkbookTemplate :Workbook/spreadsheet tool that has tabs for Project Progress Review, plus risk and issue tracking, and a tab that defines the ‘Consequence’ and ‘Likelihood’ rating levels. It was developed at NASA LaRC, Simulation Development & Analysis Branch. Additionally the workbook helps fulfill CMMI requirements in both Project Planning and Project Monitoring and Control for Capability Level 3. See SDABRiskManagementWorkInstructions.doc for the policy and procedure for risk management while using the above Workbook Template. Also see SDABProjectRiskandIssuesWorkbookWorkInstructions.doc for the procedure for implementing the other parts of the above workbook.
Recommended Approach to Software Development (Revision 3) : This document presents guidelines for an organized, disciplined approach to software development that is based on studies conducted by the Software Engineering Laboratory (SEL) Goddard Space Flight Center since 1976. It describes methods and practices for each phase of a software development life cycle that starts with requirements definition and ends with acceptance testing. For each defined life cycle phase, this document presents guidelines for the development process and its management, and for the products produced and their reviews.
Risk List exampleR1 V0 : Provides a Risk List Table with associated risk management instructions that would be tailored to reflect the project circumstances.
Risk – See above link ProjectStatusIssuesRiskWorkbookTemplateV1.5.xlsx
Stakeholders Roles and Responsibilities Table for Class D : Provides an example table of tasks and the associated customer and project roles and responsibilities.
Top 10 Worst Practices :Describes, in descending order, the 10 worst practices that contribute most to software failures.
Table of V&V Output Products by Phase v9 : NPR 7120.5D Lifecycle Phase with example software verification and validation output products to reflect NPR 7150.2A Class A requirements.
Wide-Ban Delphi Estimation ProcessV3 : Process used for estimating software size or other measure estimates such as cost.

Peer Review / Inspection Aids

Peer_Review_Toolkit_v13.xlsx
Sample_Peer_Review_Overview_Meeting_Slides_v12.ppt : Training slides for Peer_Review_Toolkit
PeerReview-InspectionProceduresR3V0Quick Reference GuideR1V0.doc: Peer Review/Inspection – Quick Reference Guide
PeerReviewInspectionChecklistsR2V1.doc: Provides various PeerReview/Inspection checklists that have been used at different NASA Centers
Peer_Review_Inspection_Forms_R2V0.doc: Provides an example layout for the PeerReview/Inspeciton forms
Peer Review Inspection Procedure R1V0.doc – This is based on the NASA training class on PeerReview/Inspecitons
Instructional Handbook for Formal Inspections.pdf : Used for those that have not had PeerReview/Inspeciton training or that have just completed training.

SWE Documents Showing Best Practices (Pre-LMS 7150 requirements)

Presentations and Reports

LaRC Software Process Improvement Effort – Sponsor Briefing July1997
CornerStone Findings Briefing Nov 1997
The first “Software Process Improvement Initiative Implementation Plan” (9/3/1998)
Briefing on Agency Software Challenges to SMC and NASA Administrator by CIO_Code Q_Chief Engineer
Software Process Improvement Initiative (SPII) CornerStone Report CS_RPT12
Watts Humphrey’s talk on Disciplined Software Engineering
Watts Humphrey’s talk on Productive Engineering teams– and the Personal Software Process (PSP) and Team Software Process (TSP)