3. GuidanceThe purpose of the Planning Process is to produce and communicate effective and workable project software plans. This process determines the scope of the software management and technical activities, identifies process outputs, software tasks and deliverables, establishes schedules for software task conduct, including achievement criteria, and required resources to accomplish the software tasks. The software lead generally has the responsibility for periodically evaluating the cost, schedule, risk, technical performance, and content of the software work product development activity. The guidelines for different types of software plans are contained in topic 7.18 - Documentation Guidance. Whenever baselined software plans (e.g., Software Development/Management Plan, Software Test Plan, Software Independent Verification and Validation (IV&V) Plan) are changed, previous commitments and agreements are likely to be impacted. Affected parties, whether they are stakeholders or other interested parties,  need to be solicited for their concurrence with the new plan. With concurrence comes the commitment to support the revised work plan. Without commitment, the risk arises that not all elements of the work plan will be performed or completed in a timely manner. The risk may also occur that customers and stakeholders will not accept the final software work products because they no longer meet customer needs and expectations. The project is responsible for ensuring that commitments are met throughout the project life cycle. Tracking results and performance of software activities against software plans, including managing corrective actions and changes to those plans, is the primary method for carrying out that responsibility. Results and Performance Tracking The planning and requirements documentation developed during early phases of the project guides the development of software work products. The project management team and the software development lead work together to construct a work plan that is logical and achievable in the allotted time and budget. During early phases key performance factors, schedules and milestones are composed. As scheduled work is performed it is important for the results to be reviewed to assure conformance with these plans and to assess if the expected performance has been achieved. The Software Engineering Institute's (SEI) capability maturity model (CMMI®-DEV, Ver 1.3)  considers the evaluation of these work activities to be part of its Project Monitoring and Control process. "A project's documented plan is the basis for monitoring activities, communicating status, and taking corrective action. Progress is primarily determined by comparing actual work product and task attributes, effort, cost, and schedule to the plan prescribed milestones or control levels within the project schedule or work breakdown structure (WBS)." Per the Lesson Learned Acquisition and Oversight of Contracted Software Development (1999), Lesson No. 0921 , it is important to ensure that software plans that go across contract boundaries (as well as memorandums of understanding and other agreements) are adequately tracked by the project. The project teams can use a number of tools to develop the insight into the progress of the work. For tracking the progress of activities against plans the use of the following tools and techniques could be helpful: - Charts - comparisons of planned vs. achieved values.
- Documents - statusing the document tree.
- Schedules - baselined, updates, variances.
- Reports - monthly technical, schedule and cost narratives; performance measures.
- Project integration meetings and telephone conferences - cross discipline evaluations.
- Test observations - unit test and integration test activities.
- Team meetings - issue (current and forecasted) and problem reporting; resolution options and tracking completion status.
Results and analysis of these tracking activities can serve as the basis for reviews by stakeholders and advocates (see SWE-018). In addition to the software lead, software assurance personnel have a responsibility for this requirement. "Specifically, reviews, audits, and evaluations may be performed to ensure adherence to and effectiveness of approved plans and procedures. Assure that problem reports, discrepancies from reviews, and test anomalies are documented, addressed, analyzed, and tracked to resolution. Assure that software products (e.g., software requirements, preliminary design, detailed design, use cases, code, models, simulators, test data, inspection results, flow diagrams) are reviewed and software quality metrics (e.g., defect metrics) are collected, analyzed, trended, and documented."  The software development team uses approved engineering processes to achieve the specified results and performance. Reviews, audits and tracking of the actual use of the specified processes by the software development team is a function of software assurance (see SWE-022). Corrective Actions Often the evaluation of actual results versus expected performance reveals issues, discrepancies, or deviations that need to be corrected. Typically these findings require further evaluations, replanning, and additional time in the schedule to correct. The software development lead must track these issues to closure to ensure the intent of this requirement. Tools, such as Excel®-based checklists, planning and tracking tools (such as Omniplan® and Primavera®), and/or formal configuration management systems/change control tools, are used to identify, resolve, and track to closure discrepancies and other shortfalls to project performance. It is important to understand that the activities of "identification," "recording," and "tracking to closure" are techniques that the software development engineering team uses to address and satisfy NPR 7150.2, NASA Software Engineering Requirements, requirements related to many areas in the project, such as life cycle planning (SWE-018), verification and validation (V&V) activities (SWE-030 and SWE-031), requirements development and management (SWE-054), configuration management systems (SWE-080), and the preparation of documentation to measure and record these activities (SWE-091, topic 7.18 - Documentation Guidance). NPR 7150.2 uses these terms repetitively, but users of this Handbook are expected to use them and interpret them in the context of the SWE guidance being read. |
Occasionally these reviews surface a significant discrepancy between the actual and expected results of an activity. Some discrepancies are a normal part of project development activity and are resolved through the normal course of scheduled activity. These discrepancies are typically tracked informally until the developers establish a product baseline, after which discrepancies/problems are formally tracked (usually in the Problem Report and Corrective Action (PRACA) system) which requires evaluation, disposition and assurance oversight of the problem. The Software Development Plan or the Software Configuration Management Plan typically defines the level of the discrepancies that are required to be recorded and tracked in the formal tracking systems. Typically a Center has an approved process for PRACA activities. This requirement does not mandate a particular approach or tool as long the key elements of a corrective action activity that are described in the following paragraph are employed. During the course of the software development activity, once a discrepancy is found that meets the criteria for formal reporting, the software development team clearly states the issue, its area of applicability across the software development activity, and the spectrum of relevant stakeholders it involves. As this information is obtained, the issue is documented in the approved process tool or data repository and an analysis is conducted of the discrepancy. The results of a properly completed analysis provide a clear understanding of the discrepancy and a proposed course of action to further investigate and resolve the discrepancy as necessary. CR-PR - Software Change Request - Problem Report provides specific details for the information needed for documenting a problem report. Once a corrective action activity has been approved and initiated, its progress is reviewed on a regular basis for progress and its use of planned resources. This information is used to assess whether the action itself is on course or deviating from the expected result. An important element of the corrective action activity is the proper closeout of the action. After the activity has concluded, or when the discrepancy has been narrowed to within acceptable limits, the closeout is recorded and may include the following information: - Description of the issue/discrepancy.
- Proposed corrective action, with acceptable limits.
- Actual results/impacts from the effort.
- Listing of required changes to requirements, schedules, resources, if any, to accommodate the result.
- Signature(s)/concurrence by all relevant stakeholders.
Once the documentation has been completed, it can be entered into a suitable repository or configuration management system. Commitment Changes During the course of the software development life cycle, results can deviate from expectations, and funding or workforce levels may be altered. Baselined requirements (see 7.08 - Maturity of Life-Cycle Products at Milestone Reviews in this Handbook for phases of the Space Flight Project life cycle at which software plans typically become baselined) changes become necessary based on these and other factors. It may be necessary to update planning documentation and development schedules to account for corrective action activity (see SWE-080). Once it becomes clear that plans need to be changed, and/or schedules need to be altered, the software development lead and the relevant stakeholders recommit to these revised plans. The new commitments assure availability of resources and unified expectations regarding the revised project. Several avenues exist to obtain formal commitment to changes in plans. First, the change control process requires formal evaluation and agreement and signoff by relevant parties. The software development team must involve all the relevant stakeholders and other interested parties through the exercise of its configuration management change control system (see SWE-082). Less formal methods may be used, e.g., jointly written and signed memos of understanding between or among the various parties involved. The concurrence and signature to these documents is usually sufficient to provide binding commitments. Finally, organizational policies can also provide the required formality. Software development team organizational charters may require the team to automatically support any changes, subject to resource availability, because of Center, Agency, or national priorities. It is still important for the project and software development teams to strive for concurrence and commitment by the customers and stakeholders to mitigate risks engendered by unhappy and dysfunctional team members. |