1 / 39

Software Project Monitoring and Control Process Training

Learn the process and tools for monitoring and controlling the progress of your software development project. Includes agenda, software processes, and documentation templates.

amaliak
Download Presentation

Software Project Monitoring and Control Process Training

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SOFTWARE PROJECT MONITORING AND CONTROL PROCESS TRAINING Process and Tools for Monitoring and Controlling the Progress of your Software Development Project

  2. Agenda

  3. Software Processes • The SEPG has developed the following processes: • GRC-SW-7150.3 - Software Project Planning • GRC-SW-7150.4 - Software Project Monitoring and Control • GRC-SW-7150.5 - Requirements Development • GRC-SW-7150.6 - Requirements Management • GRC-SW-7150.8 - Software Measurement • GRC-SW-7150.9 - Software Configuration Management • GRC-SW-7150.10 - Transition SW to a Higher Class • GRC-SW-7150.12 - Formal Inspection and Peer Review • GRC-SW-7150.14 - Software Acquisition SOW Guideline (being updated) • GRC-SW-7150.15 - Software Acquisition Planning • GRC-SW-7150.16 - Software Estimating • GRC-SW-7150.17 - Software Safety Planning • These are available on Software@Glenn.

  4. Software Documentation Templates • The SEPG has developed the following document templates: • GRC-SW-TPLT-SMP - Software Management Plan Template • GRC-SW-TPLT-SRS - Software Requirements Specification Template • GRC-SW-TPLT-RTM - Requirements Traceability Matrix Template • GRC-SW-TPLT-SCMP - Software Configuration Management Plan Template • Software Change Request/Problem Report • GRC-SW-TPLT-MMS – Master Metrics Spreadsheet • GRC-SW-TPLT-SDD - Software Design Description Template • GRC-SW-TPLT-IDD - Interface Design Description Template • GRC-SW-TPLT-STP - Software Test Plan Template • GRC-SW-TPLT-STPr - Software Test Procedure Template • GRC-SW-TPLT-STR - Software Test Report Template • GRC-SW-TPLT-SVD - Software Version Description Template • GRC-SW-TPLT-SUM - Software Users Manual Template • GRC-SW-TPLT-SMntP - Software Maintenance Plan Template • GRC-SW-TPLT-SAP - Software Assurance Plan Template • GRC-SW-TPLT-SSP- Software Safety Plan Template • GRC-SW-TPLT-SSCA - Software Safety Criticality Assessment (new) • These are available on Software@Glenn. • They are Word documents except for the Master Metrics SS.

  5. Software Project Monitoring and Control Process • This process was developed to assist Software Leads in assessing the status of a software project and determining if adjustments are needed. The purpose of the process is to ensure the development of a quality product that meets customer needs by continuously comparing actual progress against planned progress, tracking risks, ensuring metrics collection, and initiating replanning as appropriate. • Use this process periodically throughout the project, after the initial baseline of the Software Management Plan. • Note that this process is generally performed by the Software Lead, unless designated to another individual on the team. • Implements NPR 7150.2B SWEs 015, 016, 017, 018, 021, 024, 148, 155 • Implements the following CMMI specific and generic practices: • PMC SP 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, and 2.1 • GP 2.7 • SAM SP 1.3, 2.1, 2.2, 2.3

  6. Software Project Monitoring and Control • 6.1Collect software metrics • 6.2Perform a risk assessment • 6.3Determine project progress • 6.4Track commitments • Start • 6.9Track stakeholder involvement • 6.8Manage project data • 6.7Track training progress • 6.6Track V&V • 6.5Track issues • 6.10 Track supplier progress (see next chart for additional steps) • 6.11Report project progress • 6.12 Conduct milestone reviews • 6.13 Determine project status • Restart Process Project on schedule, within budget, has acceptable risk Project behind schedule, over-budget, or unacceptable risk • 6.14 perform risk mitigations • 6.15 Replan project Project Complete • 6.16 Generate final metrics • 6.17 Evaluate software for reuse • 6.18 Archive project artifacts • 6.19 Release resources • 6.20 Document lessons learned • End

  7. Software Project Monitoring and Control • 6.10 Track supplier progress • 6.10.1 Participate in supplier reviews • 6.10.2 Track supplier processes • 6.10.3 Track product evaluations • Return to process step 6.11 • 6.10.5 Review supplier agreement • 6.10.4 Transition products from supplier

  8. Software Project Monitoring and Control Collect software metrics(6.1) • The Software Project Leadcollects the project’s software metrics data according to the project’s Software Management Plan (SMP) following GRC-SW-7150.8, Software Measurement. • This should be done on a pre-defined periodic basis based on Project Management needs

  9. Software Project Monitoring and Control Perform a risk assessment (6.2) • The Software Project Lead reviews, evaluates, and updates the project risks with the Software Team following NPR 8000.4, Risk Management Procedural Requirements and the Project’s Risk Management Plan.  The project’s Risk Facilitator participates in the risk assessment if the project has one.  

  10. Software Project Monitoring and Control Determine project progress (6.3) •  TheSoftware Project Lead compares the metrics against the previous values and against the project’s plans (i.e., the SMP, the schedule, etc.) to gauge the project’s actual progress against the software plans. The following activities should be considered for determining project progress: • Update the schedule with percentage of work done, work completed, new work, etc., and compare this with where the project should be on the schedule. • Track cost back to the estimate and planning parameters that went into the estimate •  Determine from these comparisons if the project is on schedule, within budget, and with acceptable risks.

  11. Software Project Monitoring and Control Track commitments (6.4) • The Software Project Lead reviews commitments with both internal and external organizations. These are any significant commitments made that impact software or that software made to others (i.e., commitment for certain resources, commitment of a facility, commitment to deliver hardware or software, etc.). Record the results of the review, noting any commitments that have not been satisfied or are at risk of not being satisfied. 

  12. Software Project Monitoring and Control Track issues (6.5) • The Software Project Lead reviews the software project issue list and closes out those that have been resolved, recording the action taken. Document new issues in the software project issue list. For any new issues, identify a person responsible for resolving each issue and a due date for resolution. For each existing overdue issue, identify the impediments to resolving the issue and a plan for overcoming the impediments. For the remaining issues, record current status.   

  13. Software Project Monitoring and Control Track V&V (6.6) The Software Project Lead • Records verification activities • Reviews verification results • Addresses issues found during verification • Use analysis to determine source of failure  • Resolve issue or request waiver if necessary  • Tracks all verifications to closure • Track work required to fix failed verifications • Plan and conduct follow up verification testing, including necessary regression tests • Ensure all requirements are met or waivers are granted • Captures and documents validation results • Resolves issues found during validation or requests a waiver if necessary.

  14. Software Project Monitoring and Control Track training progress (6.7) • The Software Project Lead maintains a record of who took which project-specific training courses during the reporting period. • For any project-specific software upcoming training • ensure that the funding is in place • the organization supplying the training is prepared to perform the training • a facility for the training is reserved and equipped • the personnel targeted for the training are aware of the training

  15. Software Project Monitoring and Control Manage project data (6.8) •  The Software Project Lead manages project data against the plan. Report the results of any reviews of project data,  incidents of compromised control of data, improper disclosure, or any incident that violates any of the security or privacy requirements.  

  16. Software Project Monitoring and Control Track stakeholder involvement (6.9) • TheSoftware Project Lead assesses the involvement of stakeholders over the reporting period. • Document any issues with stakeholder involvement.   

  17. Software Project Monitoring and Control Track supplier progress (6.10) • If the project has a supplier developing software, continue with step 6.10.1. Otherwise, go to Step 6.11.

  18. Software Project Monitoring and Control Participation in supplier reviews (6.10.1) • Software Project Lead develops reports on any milestone reviews, project reviews, and technical reviews held by the supplier or in conjunction with the supplier.   Reports may include progress reports, performance measures, closed action items, and products delivered. Software Project Lead adds any issues resulting from these reviews to the issues list.  

  19. Software Project Monitoring and Control Track supplier processes (6.10.2) • The Software Project Lead reviews the processes being monitored, as planned in GRC-SW-7150.15, Software Acquisition Planning. If supplier processes are being monitored, review the supplier’s processes and add any issues identified to the issues list.

  20. Software Project Monitoring and Control Track product evaluations (6.10.3) • The Software Project Lead evaluates delivered products against the identified acceptance criteria (see GRC-SW-7150.15, Software Acquisition Planning Process, which establishes the acceptance criteria).  Software Project Lead develops report on products delivered by the supplier and the evaluations of those products.  Software Project Lead adds any issues resulting from these reviews to the issues list.  

  21. Software Project Monitoring and Control Transition products from supplier (6.10.4) • Once the product(s) has/have been accepted by the Software Project Lead, the Software Project Lead transitions the product(s) to the project.   

  22. Software Project Monitoring and Control Review supplier agreement (6.10.5) • The Software Project Lead reviews agreement with the supplier to ensure it reflects the project’s relationship with the supplier. Determine what updates, if any, are needed.   

  23. Software Project Monitoring and Control Report project progress (6.11) •  TheSoftware Project Lead • Generates a report based on the collected metrics, risk data, budget, progress, commitments, issues list, and supplier agreement updates according to the format and timeframe described in the SMP. • Reports the progress to date to the Project Manager and Line Management, as planned. Report on the project’s status at a regular status meeting, major product review, or a specific project meeting 

  24. Software Project Monitoring and Control Conduct milestone reviews (6.12) • TheSoftware Project Lead works with the project to conduct milestone reviews in accordance with the project plan and/or the SMP. The Software Project Lead should consider if there is a need for separate software reviews, typically only needed on large, software-intensive projects. Milestone reviews are conducted in accordance with the appropriate GLPR (for example, GLPR 7120.5 for space flight projects, GLPR 7120.8 for aeronautics and research projects, etc.). Status may include progress, issues, metrics, risks, budget, schedule, commitments, supplier progress, etc. See the Software Engineering Handbook for guidance regarding appropriate information to be presented at reviews.  

  25. Software Project Monitoring and Control Determine project status (6.13) • Based on the progress report and discussions between the Software Project Lead and the Project Manager, Line Manager, and/or Technical Authority, decide if any replanning is necessary. If replanning is necessary, continue with the next step. If project is complete, continue with Step 6.16. Otherwise, end this iteration of the process.

  26. Software Project Monitoring and Control Perform risk mitigation (6.14) •  The Software Project Lead ensures the implementation of the risk mitigation strategies outlined in the SMP or the Risk Management Plan. Assess impacts to the software project schedule and any other affected planning documents.   Implement the software security risk mitigations addressed in the Project Protection Plan, if they exist.   

  27. Software Project Monitoring and Control Replan project (6.15) •  The Software Project Lead replans the project based on current information and any changes or corrective actions agreed to by project management. Start with the baselined project cost and schedule estimates for each WBS element and rework them  using GRC–SW–7150.3, Software Project Planning. If substantial changes in software plans, technical scope, software classification, or safety criticality are made, review the NPR 7150.2 requirements and planned compliance with the Technical Authority to assess if any changes are necessary.  Save the new planning documents and have project management and other relevant stakeholders review and approve them. These documents become the new baseline. End this iteration of the processand start over.

  28. Software Project Monitoring and Control Generate final metrics (6.16) •  The Software Project Lead generates a final metrics report as described in the Software Management Plan, and stores it as described in GRC-SW-7150.8, Software Measurement.

  29. Software Project Monitoring and Control Evaluate software for reuse (6.17) • At conclusion of the project, the Software Lead evaluates the software products for potential reuse by other projects across the Agency and contributes any reuse candidates to the Agency Software Catalog. 

  30. Software Project Monitoring and Control Archive project artifacts (6.18) •  TheSoftware Project Lead archives project data and software according to the project’s plans (Software Management Plan, Data Management Plan, etc.).

  31. Software Project Monitoring and Control Release resources (6.19) •  TheSoftware Project Lead releases software-related resources such as computers, equipment, and personnel.

  32. Software Project Monitoring and Control Document lessons learned (6.20) •  The Software Project Lead records and archives any lessons learned.

  33. Software Measurement ProcessResources, Tools, and Templates • Available from Software@Glenn: • http://software.grc.nasa.gov • GRC-SW-7150.4: Software Project Monitoring and Control • NPR 7150.2B: NASA Software Engineering Requirements • GRC-SW-TPLT-MMS: Master Metrics Spreadsheet Template • GRC-SW-TPLT-SMP: Software Management Plan Template • Available from the Agency • https://nen.nasa.gov/web/nen/home • Click on Communities->Software Engineering • Software Engineering Handbook, NASA-HDBK-2203 • Former NPR 7150.2 Handbook • https://swehb.nasa.gov/display/7150/Home • Software classification tool • https://swehb.nasa.gov/display/7150/Software+Classification+Tool • NASA Lessons Learned database • https://nen.nasa.gov/web/ll

  34. Feedback on the Software Metrics • Processes, checklists, templates and forms available at Software@Glenn: http://software.grc.nasa.gov • To ask questions • Lisa Lambert, x3994 • grc-sepg-lead@lists.nasa.gov • We value your feedback • The feedback form is on the Feedback page of Software@Glenn. • Send the feedback form to grc-sepg-lead@lists.nasa.gov. • Group feedback sessions available upon request. • Based on feedback, the process will be updated. • The updated process will be made available on Software@Glenn. • Share your products as examples for future projects!

  35. Questions?

  36. Backup

  37. CMMI v1.3 Project Monitoring and Control and Supplier Agreement Management • Project Monitoring and Control • SG 1 – Monitor the Project Against the Plan • SP 1.1 – Monitor Project Planning Parameters • SP 1.2 – Monitor Commitments • SP 1.3 – Monitor Project Risks • SP 1.4 – Monitor Data Management • SP 1.5 – Monitor Stakeholder Involvement • SP 1.6 – Conduct Progress Reviews • SP 1.7 – Conduct Milestone Reviews • SG 2 – Manage Corrective Action to Closure • SP 2.1 – Analyze Issues • SP 2.2 – Take Corrective Action • SP 2.3 – Manage Corrective Actions • Supplier Agreement Management • SG 1 – Establish Supplier Agreements • SP 1.1 – Determine Acquisition Type • SP 1.2 – Select Suppliers • SP 1.3 – Establish Supplier Agreements • SG 2 – Satisfy Supplier Agreements • SP 2.1 – Execute the Supplier Agreement • SP 2.2 – Accept the Acquired Product • SP 2.3 – Ensure Transition of Products

  38. CMMI v1.3 Generic Goal 2 • Generic Goal 2 and Practices • Goal 2 – Institutionalize a managed process • GP 2.1 – Establish an organizational policy • GP 2.2 – Plan the process • GP 2.3 – Provide resources • GP 2.4 – Assign responsibility • GP 2.5 – Train people • GP 2.6 – Control work products • GP 2.7 – Identify and involve relevant stakeholders • GP 2.8 – Monitor and control the process • GP 2.9 – Objectively evaluate adherence • GP 2.10 – Review status with higher level management • 38

  39. NPR 7150.2B RequirementsSWE-015, 016, 017, 018, 021, 024, 148, 155 • SWE-015 The project manager shall establish, document, and maintain two cost estimates and associated cost parameters for all software Class A and B projects that have an estimated project cost of $2 million or more or one software cost estimate and associated cost parameter(s) for other software projects. • SWE-016 The project manager shall document and maintain a software schedule that satisfies the following conditions: • a. Coordinates with the overall project schedule. • b. Documents the interactions of milestones and deliverables between software, hardware, operations, and the rest of the system. • c. Reflects the critical path for the software development activities. • d. Adhere to the guidance provided in NASA/SP-2010-3403, NASA Scheduling Management Handbook. • SWE-017 The project manager shall plan, track, and ensure project specific software training for project personnel. • SWE-018 The project manager shall regularly hold reviews of software activities, status, and results with the project stakeholders and track issues to resolution. • SWE-021 If a system or subsystem evolves to a higher or lower software classification as defined in Appendix D, or there is a change in the safety criticality of the software, then the project manager shall update their plan to fulfill the applicable requirements per the Requirements Mapping and Compliance Matrix in Appendix C and any approved tailoring. • SWE-024 The project manager shall track the actual results and performance of software activities against the software plans. • SWE-148 The project manager shall evaluate software for potential reuse by other projects across the Agency and contribute reuse candidates to the Agency Software Catalog. • SWE-155 The project manager shall implement the identified software security risk mitigations addressed in the Project Protection Plan.

More Related