310 likes | 451 Views
Reference. Software Project Survival Guide Steve McConnell Microsoft Press, 1998. Customer's Bill of Rights. To set objectives for the project and have them followedTo 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
E N D
1. Managing the Project Lifecycle Jim Fawcett
CSE784 – Software Studio
Fall 2001
2. Reference Software Project Survival GuideSteve McConnellMicrosoft Press, 1998
3. 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
4. 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
5. 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.
6. 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
7. 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 accurately to customers and upper management.
To work in a productive environment free from frequent interruptions and distractions, especially during critical parts of the project.
8. 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?
9. 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
10. 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
11. 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.
12. 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.
13. Staged Delivery
14. 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
15. A Staged Delivery Process
16. 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.
17. 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.
18. 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.
19. 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.
20. 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.
21. Architecture Complete (cont) Install program created and baselined.
User manual/specification updated.
Stage 1 “feature-complete” product delivered.
Estimates, top 10 risks, log updated.
22. First Stage Code Complete – Then: Repeat preceding steps.
23. 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.
24. 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.
25. Some Additional Detail
26. 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.
27. 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.
28. Elements of a Quality Assurance Plan Defect tracking
Unit testing
Source code tracing
Technical reviews
Integration testing
System testing
29. Architecture Provide system overview.
Define subsystems and organization.
Identify areas most subject to change.
Make buy versus build versus reuse decisions.
30. 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
31. 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.
32. 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.