Overview
In this activity, software project reviews are held. These reviews may be formal or informal, depending on the project size. Formal reviews are necessary for large projects or projects having one or more contractors. These progress reviews provide the project software manager with insight into the current state of the project.
Roles and Responsibilities
The project software manager is responsible for scheduling and leading the software project reviews.
The software project personnel are responsible for participating in the reviews.
The project manager, customers, users, and managers from other disciplines may be invited to attend and participate in the reviews.
Controls
Software project plans that document the software project status and approach.
The Software Configuration Management Plan (SCMP) (see Appendix E) which documents how changes in baselined software products will be handled.
The Project Plan (see Appendix E) which documents how project-level risks are identified and handled.
The project-level Configuration Management (CM) Plan (CMP) which documents how changes in project-level products are handled.
Inputs
Software work products for review.
Documented risks for discussion.
Software metric reports which help define the status of the software project.
Procedures
Software progress reviews may be periodically held, may be based around software project milestones, or may be held at the request of the project or software project personnel. The reviews facilitate communication between software project members, the project manager, customer(s), users, and managers from other disciplines, to identify risks and changes needed in software project plans; reaffirm or modify commitments; and evaluate progress status with supporting documentation (i.e., software metrics, software work products). For small projects in which the project software manager works closely with all other software project members, weekly group meetings may be sufficient. For larger projects or projects involving contractors, the project software manager should base progress reviews around milestones. These milestones should be clearly defined and related to the product status (e.g., completion of the software requirements).
For each progress review (formal or informal) the following steps should be followed:
1) The project software manager schedules the progress reviews and determines the agenda. In more formal reviews, all expected participants are notified of their expected contributions. Any required presentation format or other constraints should be communicated to the individuals (or organizations) expected to present material. All participants should be made aware of the meetings’ objectives. If software work products are to be discussed at the meeting, they should be obtained and distributed prior to the meeting to allow adequate time for review.
2) During the meeting, the current project status and commitments are reviewed based upon information from software project members and software metric reports. The project software manager compares these to the expected project status and commitments as defined in the software project plans and schedule. If applicable, impending project-level changes should be discussed with the project manager, customer(s), user(s), or other discipline managers to determine potential changes in commitments or scope.
3) In more formal reviews, materials for review may be presented as slides and demonstrations. Formal inspection results and/or test results may be discussed. Specific agendas for the Software Requirements Review (SRR), Preliminary (software) Design Review (PDR), and Critical (software) Design Review (CDR) are described in IEEE STD.1028. These formal reviews are highly recommended for larger projects in which the project software manager is not closely involved with the technical aspects of the project or when one or more contractors are involved.
4) All currently open risk items are discussed to identify any change in their status or risk mitigation strategies. Based upon the project status discussion, materials reviewed, and/or metric reports, new risks may be identified. For documenting and handling identified risks, see 1.2.1.1 Perform Risk Management.
5) Issues identified during the meeting which require changes in software project plans (e.g., required changes in the Software Test Plan (STP) (see Appendix E) due to changes in the project schedule) should be handled in accordance with the SCMP. The project software manager is responsible for identifying risks or required changes in project-level plans and documentation in accordance with the Project Plan and project-level CMP.
Outputs
Identified risks to be documented (see activity 1.2.1.1 Perform Risk Management).