obsidian/Main
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

vault backup: 2025-01-08 10:40:29

Browse Source
This commit is contained in:
Claudio Fritsche
2025-01-08 10:40:29 +01:00
parent 1b8e503f63
commit e9c4fb055b
4 changed files with 67 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

45
5 Media/0 Books/Software Project Survival Guide by Steve McConnell.md
View File

@@ -166,7 +166,52 @@ Erring on the side of too much process is marginally more expensive, versus erri
Software projects are inherently complex and therefore need to be planned, controlled and made sure that the progress is visible, people are supported to do the project's work.
The risks should be tracked and constantly redeveloped.
#### Planning
- Think about processes in the upstream period of fixing mistakes at 1/200th of the price.
- Rule of thumb: each day spent in processes (e.g. technical review) saves 3-10 days later in the project
- Software Development Plan
- Project Estimates
- Revised Estimates
- Quality Assurance Plan
- Staged Delivery Plan
- Requirements Development
- Architecture
- Detailed Design
> [!Important]+ Planning Checkpoint Review
> Very early in the project (at about 10%) success or failure is determined. This means it can be used as a checkpoint to do a *go/no go* decision about the project. At this point the team should have produced:
> - user interface prototype (and shown it to users)
> - detailed requirements
> - detailed project plan including cost and schedule estimates.
>
> **Mandatory Documents needed for the checkpoint**:
> - Name of project's key decision maker
> - Vision statement
> - Business case for the software
> - preliminary effort and schedule goals
> - 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
>
> **Agenda for the Checkpoint Review**
> - Is the original product concept still viable?
> - Will it be possible to develop a product that matches the project's vision statement?
> - Is the business case for the software still justified when updated, more accurate cost and schedule estimates are considered?
> - Can the major risks to the project be surmounted?
> - Have users and developers been able to agree on a detailed User Interface Prototype?
> - Is the User Manual / Requirements Specification complete and stable enough to support further development work?
> - Is the Software Development Plan complete and adequate to support further development work?
> - What is the estimated cost of completing the project
> - What is the estimated schedule for completing the project?
Benefits of splitting development into these two funding phases:
1. Cancelling one bad project at the stage of 10-20% can fund many other projects
2. More reliable funding for the bulk of the project, because it can be better estimated
3. Forces project manager to do upstream work in the first 10-20% --> setting the project up for success.
#### Risk Management
#### Project Control