Managing the Project Lifecycle Jim Fawcett CSE784 – Software Studio Fall 2001

Reference Software Project Survival Guide Steve McConnell Microsoft Press, 1998

Customer’s Bill of Rights To set objectives for the project and have them followed To know how long the project will take and how much it will cost To decide which features are in and which are out of the software To make reasonable changes to requirements throughout the course of the project and to know the costs of making those changes

Customer’s Bill of Rights (continued) To know the project’s status clearly and confidently To be apprised regularly of risks that could affect cost, schedule, or quality, and to be provided with options for addressing potential problems To have ready access to project deliverables throughout the project

Project Team’s Bill of Rights To know the project objectives and to clarify priorities. To know in detail what product I’m supposed to build and to clarify the project definition if it is not clear. To have ready access to the customer, manager, marketer, or other person responsible for making decisions about the software’s functionality.

Team’s Bill of Rights (continued) To work each phase of the project in a technically responsible way, especially to not be forced to start coding too early in the project. To approve effort and schedule estimates for any work that I will be asked to perform. This includes the right to provide only the kinds of cost and schedule estimates that are theoretically possible at each stage of the project

Team’s Bill of Rights (continued) To take the time needed to create meaningful estimates; and to revise estimates whenever the project's requirements change To have my project’s status reported accur-ately to customers and upper management. To work in a productive environment free from frequent interruptions and distractions, especially during critical parts of the project.

People-aware Management Accountability Managers should be held accountable for whether the organization’s human resources emerge from the project strengthened or diminished. Do developers quit the company at the end of the project? Does the whole team emerge with improved skills and excellent morale?

Life Cycle – Project Planning Software Development Plan Project cost and schedule estimates Quality Assurance Plan Technical reviews testing Staged Delivery Plan Requirements development Architecture Detailed Design

Planning Review Vision statement and business case Preliminary effort and schedule estimates Top 10 risks list User interface style guide Detailed user interface prototype User manual/Requirements Specification Software Quality Assurance Plan Detailed Software Development Plan

Early Project Control Explicitly choose a life-cycle model, e.g., staged delivery. Set up process to manage changes to requirements. Set design and coding standards. Create a detailed plan to focus each developer’s tasks on the project goals.

Benefits of Staged Delivery Critical functionality is available earlier. Risks are reduced early. Problems become evident early. Status-reporting overhead is reduced. working software is best status report More options are available with staged delivery. Reduces estimation errors.

Staged Delivery

Costs of Staged Delivery Increases project overhead Time to drive to software release many times Retest already tested features Versioning for each delivery Support multiple versions in the field Planning staged releases

A Staged Delivery Process

Top Level Milestones Key decision maker on board. Vision statement reviewed and published. Preliminary cost and schedule targets defined. First senior developers on board. Change control plan established. Top 10 risks defined. Software project log started.

Project Launch – Then: QA & Documentation leads on board. Key users identified and interviewed. UI Prototype created, reviewed by users. UI style guide baselined. First project estimates baselined. Preliminary Software Development Plan baselined. Top 10 risks and log updated.

Preliminary Requirements Development Complete – Then: Detailed UI prototype completed and baselined. User Manual/Requirements Specification baselined. Software Quality Assurance Plan baselined. Detailed Software Development Plan baselined. Project estimates, top 10 risks, project log updated.

Detailed Requirements Development Complete – Then: Most of development team and QA staff on-board. Software architecture document baselined. Software integration procedure defined. Staged delivery plan defined. Software test cases for stage 1 defined. All earlier baselined products updated.

Architecture Complete – Then: Beginning-of-stage planning completed. Detailed Design Document for stage 1 baselined. Detailed software construction plan for stage 1 including miniature milestones baselined. Software test cases for next stage baselined. Software build instructions (make files) for stage 1 baselined. Source code for stage 1 baselined.

Architecture Complete (cont) Install program created and baselined. User manual/specification updated. Stage 1 “feature-complete” product delivered. Estimates, top 10 risks, log updated.

First Stage Code Complete – Then: Repeat preceding steps.

Second Stage Code Complete: Detailed design document for last stage baselined. Software test cases for all stages updated. Source code for all stages updated. Build instructions for all stages updated. Install program updated. Integrated “feature-complete” product delivered. Estimates, top 10 risks, log updated.

Last Stage Complete Release checklist baselined. Release sign-off form signed by all parties and put under change control. Final product delivered. Final test cases delivered. Software media delivered. Project archives store off-site. Final updates to log. Project history document baselined.

Some Additional Detail

Change Control Procedure Initial development work is done without change control. When initial development is complete the product is submitted to a change control board. If the board accepts the product it becomes baselined. After baselining the product is put under source control, e.g., visual source safe, etc.

Change Control (continued) Further changes are treated systematically: Changes are proposed via Change Proposals with definition of change and impact. The change board distributes the proposal to all affected parties for review. Those affected provide assessments of cost and benefits from their own perspectives. The board summarizes results and decides to: Accept, defer to a later time, or reject.

Elements of a Quality Assurance Plan Defect tracking Unit testing Source code tracing Technical reviews Integration testing System testing

Architecture Provide system overview. Define subsystems and organization. Identify areas most subject to change. Make buy versus build versus reuse decisions.

Architecture (continued) Specific areas to address: External software interfaces User interface Database organization Data structures and storage Key algorithms Memory management Concurrency/threads Security Networking Error handling

Code Integration Procedure Code development Developer unit tests code with tracing. Developer integrates with a private version of main build. Developer submits for review. Informal turnover to testing. Developer fixes problems found. Fixes are reviewed. Developer integrates with main build. Code is declared complete.

System Test System test is a half step behind construction. Exercises system from end-to-end. Testers support developers by ensuring that system quality is high enough to support integration of new code. Developers support testers by fixing reported defects quickly.