Notes on Steve McConnell's Software Project Survival Guide (1998)
Other Resources
Project Needs (lowest to highest - based on Maslow's human need hierarchy)
- survival needs (project not cancelled, team not fired, adequate physical working conditions, etc.)
- safety needs (meeting personal promises for schedule and functionality)
- belongingness and love (healthy team dynamics)
- self-esteem (feeling productive, belief in project's importance)
- self-actualization (ongoing professional development)
Project Up-front Planning
- project needs a clear achievable objective
- project needs executive sponsorship that has the final authority over decisions
- have entire project team approve project plan before starting on project
- make current updated project plan public for all project team to see (put on intranet site)
- approximately 5% of project's budget should be for risk management activities, i.e. risk officer (pessimist, devil's advocate), top 10 risks list (updated biweekly) and plan to deal with them, create anonymous risk-reporting channel
- flat staffing model works for small projects (< 7 developers), but for larger projects use only 2-5 people during requirements gathering and do staff buildup after Planning Checkpoint review (see below)
- make sure team dynamics are good - team cohesion has greater impact on productivity than team member's individual capabilities
- project team member's roles should be well defined (someone can do more than 1 role if small team) - can also create small "tiger teams" to do short-term tasks - make sure to rotate these assignments among staff
- make sure team gathers time-accounting data in specific categories from the start so as to create historical data to be used for future projects
Project Activities
| requirements gathering |
6% |
12% |
| architecture/design |
8% |
8% |
| detail design |
16% |
65% (can be broken into stages) |
| construction/coding |
40% |
| system testing |
20% |
| release |
10% |
15% |
Change Control
- create change proposal document (change description, cost impact, schedule impact, benefit, quality change, resource allocation change, etc.)
- change control board will review all change proposals at a scheduled time and will report back decisions
- use version control software
Typical Project Plan
also see here
- MILESTONE - beginning of project
- PHASE - project launch/feasibility study (vision statement/business case, preliminary schedule estimates/risks, etc.)
- PHASE - preliminary requirements development (storyboards, updated project schedule estimates/risks, technical architecture brief, etc.)
- PHASE - detailed requirements development (functional spec, user manual, QA plan, detailed tech plan, updated project schedule estimates/risks, etc.)
- MILESTONE - Planning Checkpoint review - go/no go
- PHASE - architecture (detailed tech spec - architecture/integration, staged delivery plan created, stage 1 test cases created, update user manual/requirements/project schedule estimates/risks)
- PHASE - 1st stage (create code, update user manual/requirements/project schedule estimates/risks, run test cases)
- MILESTONE - stage 1 release
- PHASE - 2nd stage (create code, update user manual/requirements/project schedule estimates/risks, run test cases)
- MILESTONE - stage 2 release
- PHASE - 3rd stage (create code, update user manual/requirements/project schedule estimates/risks, run test cases, do user training)
- MILESTONE - stage 3 release
- PHASE - release preparations (create release checklist and sign-off form, deliver product and install program, run final test cases, off site backup of code)
- MILESTONE - software release
Requirements Development
- identify end users to help define software
- interview end users to get preliminary set of requirements
- build simple user-interface prototype (just look and feel - nothing else) - may just be paper storyboards - revise based on comments
- develop a style guide
- create detailed user-interface prototype (never use it as the code base for the released software)
- the detailed user-interface prototype is the baseline specification - software should exactly match the prototype - any changes need to be changed controlled
- end-user documentation (and test plans) should be based off the detailed prototype (and any change documents) - helps flush out inconsistencies
- should also create separate non-user-interface requirements document, i.e. algorithms, performance/memory requirements, etc.
Quality Assurance
- quality affects development speed and cost
- activities include defect tracking (by developers - need to be reported), unit tracking (informal testing by developer of routines, classes, etc.), source-code tracing (line-by-line interactive debugger testing), technical reviews (code review/walkthrough by peers), integration testing (informal testing by developer of how it interacts with existing code), system testing (execution of program to find bugs)
- technical review plan - notification of review, reviewer preparation. review meeting, review report by reviewer, follow-up of report
- system testing info - done by independent QUA group, create test plan or requirements traceability matrix, need to specify what measurable release criteria is (the developers shouldn't decide), need good ration of testers to developers (Microsoft uses 1 to 1 ratio for commercial software - in-house system should use around 1 QA to 3/4 developers)
Planning Checkpoint review
- may take 10-20% of project time
- materials needed: project vision statement/business case, project schedule estimates
change control/order plan, top 10 risks list, functional specification, technical brief/development plan
- questions to ask: is project still viable, will it match original vision statement, can
risks be overcome, is functional specification/technical brief complete, based on updated schedule estimates what is updated project cost
Architecture Phase
- described in the Software Architecture Document (which needs to stay updated and put under change control)
- should start when requirements development is about 80% done
- should complete Planning Checkpoint review fist though
- design issues - system overview (should discuss major design alternatives that were considered and the reason this one was chosen), defines the major subsystems/functional areas (external interfaces, analysis, user input, tools, data organization, localization, networking, error handling, business rules, etc.) and preliminary list of modules/classes in them, describes interactions among subsystems, list most likely change scenarios and how they will be addressed (around 80% of possible ones), talk about commercial components vs. in-house developed ones vs. reused components, etc.
- larger projects should use UML for it's standard notation
- must support/discuss the Staged Delivery Plan
Final Preparations before Implementation
- project estimates (effort/cost/schedule) - look at past projects (see typical activities), use agreed upon estimation procedure (see sample) or use commercial software estimation tool (benefit of being impartial 3rd party), project plan should not assume the team works overtime (need reserve to draw on) and must be realistic, refine as project progresses, including milestones (should be revised after preliminary requirements development, detailed requirements development, and architectural design), put under change control
- staged delivery plan - doesn't reduce amount of time to deliver software, but user's feel like ti does since they see stuff sooner, need releasable software after each stage (but don't have to actually release it), don't show % complete (either task is done or in progress), release most important functionality 1st, good to develop themes for each stage (like database, admin, shopping process, utilities, etc.), isn't the same as alpha/beta/final releases
- ongoing planning activities - update top 10 risks list, personnel plan, and software development plan; revise project vision if necessary
Stage Planning
- create stage plan which is added to Software Development Plan
- stage plan describe milestones, schedules, and task assignments for updates to requirements, detailed design, construction, test case creation, updates to user documentation, technical reviews, defect correction, technical coordination, risk management, project tracking, integration and release, end-of-stage wrap-up (lessons learned)
- need to define detailed (miniature) milestones (no % done, either complete or not) for stage so can track project's status and keep team focused - should be at least every week and at most every day - let team define their own miniature milestones
- need to define detailed milestones twice - once to get through detailed design and again after detailed design is complete to get through software release
- milestones need to be complete - should include every task needed to release software
- perform technical reviews on all milestone work
- if developer misses milestones frequently don't have them work overtime over and over, but need to recalibrate their schedule, trim features, or reassign some of their tasks
Stage Detailed Design
- work in design areas including program organization (class module diagrams/routine text descriptions and pseudocode), reuse analysis, any resolution on unresolved stage requirements, requirements traceability (from requirements to architecture to detailed design to code to test cases - look for missing/unrequired functionality), comprehensive construction plan, correcting gaps/inconsistencies in architecture
- need detailed design document at least for every subsystem, if not for every component - should be placed under change control also
- design work can take place in parallel with construction for small projects (under 2 months with experienced developers)
- stage 1 considerations - for smaller projects with experienced developers architecture can be rolled into stage 1, need to explore viability/risks of architecture during stage 1, should address most difficult parts of system during stage 1 (don't have to complete, but need to at least work on)
- need technical reviews for design of each class, handful of routines, or 100 lines of psuedocode - 2 or 3 reviewers is most ideal - look for correctness, completeness, and understandability (since on average 10 generations of maintenance programmers will work on code after original developer) - this also helps achieve cross-training
Stage Construction
- based off of detailed design phase document
- tasks: create source code, unit test, debug, integrate with main site - use software integration procedure checklist and if have integration procedure then also do a daily build and smoke test
- need to have coding standards (25 pages at the most) that are enforced thoughout code reviews, i.e. layout of code within routines, variable/function names, versions of tools/libraries used, directory structures, etc.
- during Stage 1 a skeleton of the system should be built to support the entire functionality of the system (need menus, toolbars, etc. for user interface and supporting infrastructure like error handlers) - don't build the complete infrastructure though or will get bogged down
- need to make sure all miniature milestones are tracked (also should use a weekly time-accounting system) - project manager also needs to have weekly project status reviews (discuss milestones, defects, change requests, risk list, etc.) and the data coming out of them helps update the End-of-Stage Software Project Log and complete the End-of-Project Software Project History (should also let all project stakeholders know project status once a week)
- use the project change board as the means to control all change requests
Stage System Testing
- to verify end-to-end functionality of system (verifies all requirements were implemented and
at an acceptable quality level
- happens at the same time as construction
- should use User Interface prototype and User Manual/Requirements Specification to develop test cases - should be ready after software passes code review (if code doesn't pass daily smoke test than can't system test))
- system testing not as prominent using this methodology since already went through User Interface Prototype review, User Manual/Requirements Specification review, Architecture review, Detailed Design review, Code review, Unit testing, Integration testing, and the Daily smoke test
- make sure to do regression testing to make sure newly added stage requirements didn't break any of the older code
- should enforce developers to keep their unresolved defect count below 10 - shouldn't work on new features if over
- 80% of system's errors are usually found in 20% of its routines - look at defect tracking system to see which routines these are so can redesign/reimplement them
Stage Preparation for Release
- release either symbolically or literally - reduces subsequent test, debug, and correct efforts
- user documentation needs to be brought into alignment with the what was released
- can overlap release stage with detailed design of next stage to keep developers busy, but fixing defects is the #1 priority
- defect count should be low enough that could formally release (helps find quality problems early) - use more than one statistical technique to determine if most defects have been found and corrected
- look at if defects are being corrected faster than they are being found
- break defects into critical (sev 1), serious (sev 2), and cosmetic defects and calculate avg. # of hours it takes to fix each one
- look at % of defects detected in stage they were created in - want high percentage
- calculate defect density - # of defects per KLOC (thousand lines of code) and use it to compare to future releases to decide when most defects have been found
- can also estimate defects by using defect seeding - intentionally insert 1-line defects into code and see how many are detected - the use following formula to estimate total defects in code:
total-defects = (seeded-defects-planted / seeded-defects-found) * total-defects-found
- before release to users run the a release checklist and get sign-off from appropriate parties
Stage Wrap-Up
- staged delivery is flexible so that stages can be deterministic so that the most important functionality is delivered 1st, or they can be redefined at the end of each stage so that you can change course
- at the end of stage use opportunity to learn from experience gained during stage
- at end of stage do the following: feature change requests to be decided by the change board should be deferred until then (don't defer corrections though), project estimates/schedule should be revised (if project slipped in previous stage reestimate schedule by the magnitude of the slip, don't just add the extra time on to the schedule), evaluate performance against the project plan, archive project environment (code, database, tools/scripts, documentation, graphics) - still backup regularly though, update the software project log
Project History
- hold project review (postmortem), lessons learned after project is complete - need to get team members subjective impressions soon after (no more than 30 days) - need objective moderator for the meeting
- can also create questionnaire - can contain numerical ranking questions, targeted questions, and free-form comments - can also accept anonymous feedback
- Software Project History document contains objective, quantitative info as well as subjective, qualitative impressions - make sure to archive and send a copy to all team members
- create planning checklist for future projects from the Project History document (alos use top risks list for future projects)
