Main/5 Media/0 Books/Software Project Survival Guide by Steve McConnell.md

title, created_date, updated_date, aliases, tags, type, book_name, author, status

title	created_date	updated_date	aliases	tags	type	book_name	author	status
Software Project Survival Guide by Steve McConnell	2025-01-07	2025-01-07		book	book	Software Project Survival Guide	Steve McConnell	not_started

Software Project Survival Guide by Steve McConnell

• 🏷️Tags : #01-2025 #book

---

Summary

[!summary] Summary 3 Sentences only!

• What are the main ideas?
• If I implemented one idea from this book right now, which one would it be?
• How would I describe the book to someone else?

---

Ideas and Thoughts

[!info]+ Inspiring Questions

• Did you think about other concepts from other books?
• Do the concepts fit to your past, to your memories?
• Can you relive them and reflect them from a different angle?

• We should define exact goals that are measurable: What does the software need to do? What's its accuracy?

---

Clippings

Intro

• Software projects fail because of
  • lack of knowledge of software project conduct
  • lack of resolve --> indecisiveness, procrastination, low confidence, inconsistency
• References
  • Key Practices of the Capability Maturity Model, Version 1.1 by Software Engineering Institute (SEI)
  • Recommended Approach to Software Development, Revision 3 by NASA Software Engineering Laboratory (SEL)

The Survival Mindset

• The only outcome considered a failure is total collapse
• Success: meet cost, schedule and quality goals within engineering tolerances (+- 10% of goal)
• Survival Needs
  • Needs that need to be satisfied before anything else can work (humans: food, shelter, water, air)
    • project not canceled, team not fired, adequate physical working conditions
    • meeting personal promises for schedule and functionality
  • Project team must be satisfied that the project can be completed at all before it can worry about the schedule or budget
  • !
  • Individual developers might not prioritise the same needs as the software projects survival needs

Stakeholders

Each group involved in the project must respect the rights of the other parties. And each group's survival needs must be thoroughly satisfied such that they can focus on higher level needs. Usually this is the Customer and the Project Team:

Customer's Bill of Rights

1. To set objectives for the project and have them followed
2. To know how long the software project will take and how much it will cost
3. To decide which features are in and which are out of the software
4. To make reasonable changes to requirements throughout the course of the project and to know the costs of making those changes
5. To know the project's status clearly and confidently
6. To be apprised regularly of risks that could affect cost, schedule, or quality, and to be provided with options for addressing potential problems
7. To have ready access to project deliverables throughout the project

Project Team's Bill of Rights

1. To know the project objectives and to clarify priorities.
2. To know in detail what product I'm supposed to build and to clarify the product definition if it is unclear.
3. To have ready access to the customer, manager, marketer, or other person responsible for making decisions about the software's functionality.
4. 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.
5. To approve effort and schedule estimates for any work that Team 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; to take the time needed to create meaningful estimates; and to revise estimates whenever the project's requirements change.
6. To have my project's status reported accurately to customers and upper management.
7. To work in a productive environment free from frequent interruptions and distractions, especially during critical parts of the project.

Survival Check

This tool is a quick check to verify that the essential characteristics for the survival are met. In the book a 👍🏼 or a 💣 is used. We will use a box just like below for every chapter.

[!question] Survival Check - Survival Training

• 👍🏼 Project team's survival needs are being met
• 👍🏼 The customer and the project team agree to respect each other's software project rights - 💣 The agreement in principle is not followed in practice

Software Project Survival Test

The idea of the survival test is to check the chances of survival of a project in different stages and to act upon the neglected areas if needed. There is a list of questions that will be answered with 0-3 points, 3 being fully qualified. The questions are separated into the following categories

• Requirements
• Planning
• Project Control
  • Can progress be tracked and viewed by team members?
  • defect tracking, source control, project management software
• Risk Management
  • up to date list of risks to the project
• Personnel
  • Do we have all technical expertise?
  • Are there enough team members and are they committed?

Most projects have a score <50.

Score Range	Rating	Description
90+	Outstanding	A project with this score is virtually guaranteed to succeed in all respects, meeting its schedule, budget, quality, and other targets. In terms of Chapter 1's project needs hierarchy, such a project is fully "self-actualized."
80-89	Excellent	A project at this level is performing much better than average. Such a project has a high probability of delivering its software close to its schedule, budget, and quality targets.
60-79	Good	A score in this range represents a better-than-average level of software development effectiveness. Such a project stands a fighting chance of meeting either its schedule or its budget target, but it probably won't meet both.
40-59	Fair	This score is typical. A project with this score will likely experience high stress and shaky team dynamics, and the software will ultimately be delivered with less functionality than desired at greater cost and with a longer schedule. This kind of project stands to experience the greatest benefit from applying the plan described in this book.
< 40	At Risk	A project with this score has significant weaknesses in the major areas of requirements, planning, project control, risk management, and personnel. The primary concern of a project in this category should be whether it will finish at all.

[!question] Survival Check - Survival Test

• 👍🏼 Project scores at least 60 on the Survival Test
• 👍🏼 The project scores less than 60, but corrective actions are planned to improve its score. - 💣 The project team doesn't follow through on the planned corrective actions.

Survival Concepts

[!Quote] An investment made in process at the beginning of the project produces large returns later in the project

Processes are important because they make the development more productive and resistant in the long term. Example processes are:

• formally write down requirements
• use a procedure to control additions and changes to the requirements
• Do reviews of all requirements, designs and source code
• Develop a written Quality Assurance Plan, including a test plan, review plan and a defect tracking plan.
• Create an implementation plan that defines in which order the components are developed.
• Automated source code control (e.g. git)
• Revise Cost and schedule after each milestone

If teams do not invest in process at the beginning of the project, the amount of time spent for process and thrashing (i.e. unproductive time) will increase (see Figure 3-3). !

On the contrary, teams which establish processes in the beginning (overhead) will spend less and less time on thrashing and processes as the project moves on. !

[!Quote] Overhead of a cancelled Project If you think that attention to process is needless overhead, consider that the overhead of a canceled project is 100 percent.

[!warning] Opposite Views

• Processes limit developer's creativity
  • --> Set up an environment where creativity is still possible.
  • Developers feel best in environments where they are the most productive.
  • Research shows that in regulated environments people feel more productive.

Upstream and Downstream

Upstream contains all early work of a project, such as requirements definition and architecture design. Downstream refers to later parts such as construction and system testing. Defects cost more (50-200 times more), the earlier in the project they are inserted as illustrated in the figure below. ! Please note that the cost grows exponentially, which multiplies the effect.

[!Quote] Successful project teams create their own opportunities to correct upstream problems by conducting thorough, careful reviews of requirements and architecture.

Remember that just because no code is being written in the beginning that doesn't mean it is delaying the real work, but rather it is laying the groundwork for the project's success. Erring on the side of too much process is marginally more expensive, versus erring on too little process can be way more expensive (50-200x) in the long run. This is because of the cone of uncertainty, which illustrates that upstream decisions affect downstream decisions, but not vice-versa. !

[!Quote] Early in the project you can have firm cost and schedule targets or afirmfeature set, but not both.

[!question] Survival Check - Survival Test

• 👍🏼 Project leadership understands the critical role of well-defined processes and supports them.
• 👍🏼 The project's processes are generally oriented toward detecting as many problems upstream as possible.
• 👍🏼 Project leadership recognises that estimates made during the first half of the project are inherently imprecise and will need to be refined as the project progresses.

Survival Skills

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

You can hope for the best but should prepare for the worst --> risk management. Typical risks:

• failure to plan
• failure to follow the plan that has been created
• failure to revise the plan when project circumstances change

Software development is a high-risk activity, which is why it is essential to perform risk managment.

[!Quote] By Tom Gilb If you don't actively attack the risks on a software project, they will actively attack you.

Project Control

Without project control every project is out of control, which is definitely something we do not want. We do not want to control the people, but rather the project itself:

• Choose a software lifecycle model (e.g. staged delivery) to provide a framework
• requirements change management --> only update what is necessary
• Design and coding standards, to have consistency
• write detailed plan of project to align developer's work with goals and to minimize conflicts in between developers

Project Visibility

The visibility is the ability to determine a project's true status, which will give answers to questions like:

• Is the project on track to achieve goals?
• Are we within 10% of budget and schedule or only within 50%?

Good visibility does not come automatically, you have to plan for it!

Activities that help achieve visibility:

• Vision Statement
• Hold a planning checkpoint review after 10% of the project
• Regularly compare actual performance against planned performance to check if plan is working and adapt if necessary.
• Use binary milestones: they are either done or not done
• Drive the project to a releasable state periodically to show project's true condition
• revise estimates after each phase to improve planning with more information

Peopleware

The development team needs to be on board in order for the project to succeed. Guidelines to consider the human aspect in software development:

• Align Developers' Interest with Work Assignments:
  • Make work interesting
  • Make possible goals: developers usually are realistic and are demotivated by goals that are out of reach
• Show developers that you sincerely appreciate them
  • don't use cheerleading campaigns, impossible challenges or monetary rewards
• Provide Thinking-oriented office space
  • the process is one of continuous discovery and invention --> create atmosphere which is supportive.
  • Space where developers can concentrate
• Avoid open work bays
  • allows deep concentration
  • install soda machine or hang out zone for when they don't need to concentrate to foster communication and inspirational discussions.

User Involvement

Don't assume you know what the user wants! Marketers want too many features such that the essential features cannot be found anymore, Developers create technical features that user's don't care about.

• Ask users what they want, show them what they intend to build and ask how they like it. Then listen carefully until you fully understand the stated and unstated elements of the users' reponses
• Identifying who the user is might be difficult
• user needs to be open to mock-ups (very crude prototype)
• Adopt easy features and changes immediately and implement larger more complicated changes later on.

User involvement saves time because it eliminates a large source of requirement changes: features that no-one needs.

Product Minimalism

Focus on simplicity. Simple solutions are always better than complicated ones.

• Focus on taking away components of the software to make it simpler, rather than adding elements to make it more complex.

Focus on Shipping Software

A company makes money by shipping software not by developing it!

[!question] Survival Check - Survival Skills

• 👍🏼 Project Team creates a detailed written plan, designed to eliminate potentially costly problems early in the project.
• 👍🏼 Project emphasizes the importance of upstream work holding a Planning checkpoint review to make a go / nogo decision when the project is about 10 percent complete.
• 👍🏼 Project practices active risk management
• 👍🏼 project plan emphasizes visibility and control
• 👍🏼 project plan involves real users early and throughout the journey
• 👍🏼 project is conducted in a productive environment
• 👍🏼 project plan calls for a simple-to-complex approach rather than the reverse.

Successful Project at a Glance

• source code tends to grow in a S-shaped curve where most of the code is written in the middle third of the project.
• Staged delivery: ship important functionality fist
• keep tabs on clearly defined milestones and deliverables

Intellectual Phases

Different phases of a project have different characteristics. They need to overlap somehow, but we don't want them to overlap too much either. !

Project Flow

Staged delivery! We want to ship staged versions of the software continuously in order to deliver something that works and improve upon it (ideally with more user feedback). Each stage is released after detailed design, coding, debugging and thorough testing.

Benefits of Staged Delivery

1. Critical functionality is available earlier: Because it is usually in the first deliverables.
2. Risks are reduced early: at each stage we have the integration of the different parts which means that different parts of the software are continuously brought onto the same page. You also create tangible signs of progress at frequent intervals.
3. Problems become evident early: You get frequent progress reports which show critical problems that can be addressed early. You will also see if the development team struggles, if they miss the deadline for the first deliverables.
4. Status-reporting overhead is reduced: Shipped and working software is a more accurate status report than a paper report.
5. Makes More Options Available: you have releasable software at all times, meaning if you want to release something is is much less work than if you don't
6. Reduces possibility of estimation error: each delivery is a syncronizing event because you can compare the estimates with what is delivered and improve your estimation skills.
7. Balances Flexibility and Efficiency: It avoids a situation like analysis paralysis, because you can ship a small stage efficiently.

Cost of Staged Delivery

• You need to retest software at every stage
• You need to execute merging and other version control tasks
• You need to manage different versions
• You need to plan the staged deliveries

Some of those costs are just exposed earlier in the process and would remain hidden (but still exist) otherwise.

Project Phases

The phases described above slightly overlap, which is inevitable and desirable. !

Distribution of Effort

!

!

Note that e.g. requirements development requires 12% of the time, but only 6% of the effort, because it is less tangible and requires deeper contemplation such that it is done at a slower pace. This also means that it doesn't produce a lot of code.

Milestones and Deliverables

Use lists from book pages 65ff.

[!question] Survival Check - Successful Project at a Glance

• 👍🏼 Project uses a staged delivery approach
• 👍🏼 Upper management, customer or both track progress by code growth curve
• 👍🏼 Upper management, customer or both track progress by keeping tabs on major milestones and deliverables

Hitting a moving target

Change Control

Floris is no fan of change control, and the book explains why: he could have any changes made at any time before, with change control there is a process which needs to be followed.

[!Quote] People who are used to getting their way can still get their way with systematic change control, but they'll have to do it through a process that emphasizes visible decision making and accountability.

Change control only works if all parties accept the decision of the change control board.

[!question] Survival Check - Change Control

• 👍🏼 The project has a change board.
  • 💣 The change board's decisions can be reversed by management, marketing, or the customer.
• 👍🏼 The project has a written, approved Change Control Plan.
  • 💣 Project team members aren't given enough time to carry out the plan.
  • 💣 Work products aren't actually put under change control.
• 👍🏼 Change Proposals are evaluated by all the project's concerned parties before they are resolved.
• 👍🏼 The change board notifies the project's concerned parties of how each Change Proposal is resolved.
• 👍🏼 The change board has the project team evaluate changes in batches so that the team is not distracted by a constant barrage of change requests.

Preliminary Planning

• Define project vision
• identify executive sponsor
• set targets
• manage risks
• map out strategies for using personnel

This all goes into a software development plan.

Project Vision

Effective teams have a common vision and thus a clear understanding of the objective. Having a common vision aligns team members to work effectively together and avoiding time-wasting side trips.

• Vision builds trust among team members because they know they work towards the same goal
• An effective vision can have a motivating effect --> therefore it needs to be elevating
• It needs to be achievable within the specified time frame

The vision should not promise too much (e.g. short schedule, low cost and rich functionality) since developers are realists and feel fooled with impossible goals.

Deciding What to leave out

Statements like creating the world's best of something include too much and therefore not provide much guidance to the development team. A good, exclusive vision statement helps the project team achieve the goal of software minimalism, which is essential for keeping project risk to a manageable level.

Committing to the vision

Formalize through a written vision statement and have it signed by every team member. Then put it under change control! It is the top most guidance element for the team and should be remembered often.

Executive Sponsorship

Make sure that the decision making comes from a single, clear authority (can be a board). Else decisions from different people do not align with each other and interfere and therefore slow down the entire project.

Project Scope Targets

This is the envisioned schedule, budget, staffing and feature set to get started with. When development starts and you realize that desired features are not in line with schedule and buget you adjust one or the other.

[!Quote] The best organizations plan to reestimate regularly throughout a project and periodically adjust their project plans based on the reestimation.

Put reestimation points in your plan (just as NASA does, see page 90):

Estimation Point	Upper Limit	Lower Limit
End of requirements definition and specification	x2.0	x0.50
End of requirements analysis	x1.75	x0.57
End of preliminary design	x1.4	x0.71
End of detailed design	x1.25	x0.80
End of implementation	x1.10	x0.91
End of system testing	x1.05	x0.95

Publicizing Plans and Progress

Involve the team in the planning phase, because the people who actually do the work often consider all details. If a plan cannot be followed because of wrong planning, it will not be followed and thus the team runs out-of-control.

• Get the plans reviewed and approved by the developers

The team needs effective coordination of activities from the project manager, such that efforts are not wasted. Therefore its smart to get the plan approved by the team before the bulk of the work gets started.

Progress Indicators

Once the project started we have the following indicators to show how well we follow the plan. This creates project visibility.

• List of tasks completed

• Defect statistics

• Top 10 Risks List

• Percent of schedule used

• percent of resources used

• project management's status reports to upper management

• Create a project intranet homepage (confluence page) with links to planning, tracking, technical work products and project deliverables. Essentially make a dashboard (see page 93)

Risk Management

The goal is to trade small amounts of increased overhead for large amounts of risk reduction. In order to commit to risk management:

• Describe a risk management approach in writing
• Budget funds for risk resolution and risk removal
• Use risk assessments to update project plans, else all is for nothing

Tools for risk management:

• Planning for risk management
• Assign a risk officer
  • play devil's advocate during planning meetings and planning reviews
  • needs to have a bit of the attitude: "It will never work"
  • senior developer or senior tester

• top 10 risk list

• risk-management plan for each risk
• create anonymous risk-reporting channel
  • Bad news are not shared easily --> make it anonymous to facilitate. It is crucial that all team members do communicate this

[!Idea] Use Jira / Github Issues for risk Tracking This makes risks visible. People can discuss risks. You can assign responsibility for risk mitigation

Risk Management Plans

Answer the following questions for every risk:

• Why? Why is a risk-management plan needed for this specific risk? Describe the risk's probability of occurrence, consequences, and severity.
• How? How will the risk be resolved in general? Describe the general approach to re- solving the risk. List or describe the options that were considered.
• What? What specific steps will be taken to resolve the risk? List the specific steps and deliverables that will be generated in addressing the risk. Include a description of the conditions under which the risk will be upgraded— for example, if the risk cannot be resolved by a specific date.
• Who? Who will be responsible for completing each step? List the specific person re- sponsible for completing each step.
• When? When will each step be completed? List the completion date for each step.
• How much? How much budget is allocated to the resolution of the risk? List the cost of each step that will be taken to resolve the risk.

Personnel Strategies

• evaluate managers based on how well they retain project personnell
• professional growth opportunities during the project
• after the project team members should feel better about the company, not worse

[!Quote] Available vs Good It's better to wait for a productive programmer to become available than it is to wait for the first available programmer to become productive.

Team dynamics and team bond play a more important role than individual developers' capabilities (slightly behind). This means we need to hire someone who fits into the team.

Key Staff-Buildup Questions

• Does the project manager have software experience with one or more projects of a similar size?
• Does project's senior technical staff have knowledge of the kind of software being built and experience on similar successful projects?
• Most teams are comprised of average personnel. Do expectations about the team's productivity match the team members' abilities?
• Will the individuals work well together?

Project Team Organization

• Project manager: orchestrate detailed technical work (development, quality assurance, user documentation). Develops software development plan. Is the team's link to upper management.
• Product manager: Business level work: marketing, product packaging, end-user documentation, end-user support. In-house projects: work with groups that use the system to define the software, setup training and user support.
• Architect: Responsible for conceptual integrity at design and implementation level.
• User-interface designer: responsible for conceptual integrity of software visible to end-user.
• End-user liaison: interact with end-user throughout the project. Walk them through the prototype, demonstrate new releases, gather user feedback.
• Developer: detailed design and implementation of software. Responsible for making the software work.
• QA/Testers: responsible for Quality Assurance and test activities. Create detailed test plans and perform tests. Find all the ways to break the software.
• Tool smith: Responsible for developing build scripts, maintain versioning system, developing utilities needed by the project.
• Build coordinator: responsible for maintaining and running the daily build and notifying the developers when something breaks the build.
• Risk officer: watch for emerging risks and diversion from the development plan.
• End-user documentation specialists: generate help files, documentation, and instructional materials that end-users will use.

[!important] Mixing Roles is Okay except for ... ... Quality Assurance and Development

Time Accounting

Tracking where team members spend their time will help with future planning.

[!question] Survival Check - Preliminary Planning

• 👍🏼 The project has a clear vision.
  • 💣 The vision doesn't provide guidance in deciding what to leave out of the software.
• 👍🏼 The project team has identified an executive sponsor or committee with final authority over projectwide decisions.
• 👍🏼 The project plans and progress compared to the plans are readily available to all project team members and upper management.
• 👍🏼 The project has a risk officer.
  • 💣 The risk officer is the project manager.
• 👍🏼 The project has a Top 10 Risks List.
  • 💣 The Top 10 Risks List is not kept up to date.
• 👍🏼 The project team develops risk-management plans for each risk on the Top 10 Risks List.
• 👍🏼 The project leaders hire well-qualified people (waiting for qualified people, if necessary), rather than just hiring whoever is available first.
• 👍🏼 Time accounting is begun before requirements development begins.
• 👍🏼 All of the above considerations are formalized in a Software Development Plan.
  • 💣 The Software Development Plan isn't placed under change control.
  • 💣 The Software Development Plan isn't actually followed by the development team.

Requirements Development

[!question] Survival Check - Requirements Development

• 👍🏼 The project team identifies a set of key end users who can be trusted to shape the software.
• 👍🏼 The developers create several versions of a basic prototype until they find one that the users are excited about.
  • 💣 Prototyping stops while users are still only lukewarm about the prototype.
• 👍🏼 The developers extend the User Interface Prototype to elicit detailed requirements from users.
  • 💣 The prototype is not kept broad and shallow, and time is wasted providing deep functionality that will be rewritten for the final software.
• 👍🏼 The project team develops a User Manual/Requirements Specification to use as the detailed requirements specification.
• 👍🏼 The fully developed prototype is baselined and placed under change control.
  • 💣 The project team attempts to use the prototype code in the real software.
• 👍🏼 A separate, non-user-interface requirements document is created, reviewed, and placed under change control.

Quality Assurance

QA matters because it makes development easier and cheaper. If mistakes and defects are detected upstream they are 50-200 times cheaper, which is why a good quality assurance system pays out. Quality is important because the software usually acts as a foundation for business decisions, more software and usually lives longer than you might expect.

[!Quote] Quick and Dirty The problem with quick and dirty, as some people have said, is that dirty remains long after quick has been forgotten.

Quality Assurance Plan

This document writes down commitments to quality assurance onto paper:

• Software quality assurance activities must be planned
• The plan for quality assurance must be committed to writing
• Quality assurance must beginn in requirements phase or earlier
• Development and quality assurance of the same elements cannot be performed by the same person.
• Train team members in how to perform quality assurance activities.
• Provide adequate funding for quality assurance activities

Typical Quality assurance activities are:

• defect tracking: keep record of each defect found, its source, when it was found, when it was resolved, how it was resolved (fixed or not)
• unit testing: unit refers to subroutine, module, class or even larger programming entity. This is done by developers, or on the git cloud provider automatically
• source-code tracing: interactive debugging line by line. done by developer.
• technical reviews: reviews are performed by peers. check all technical work products. Done by developers, QA-team just ensures that they are being held.
• integration testing: test new code together with existing code / codebase. Done by developer
• system testing: Test the entire system for the purpose of finding defects. Performed by independent test organization / test engineer

Defect Tracking

• document each individual defect
• keep statistics: # open defects, average time requiered to correct a defect, percentage of defects resolved.
• track only defects that have been comitted. Beforehand you should just fix them (put them into your personal todos.)
• Put defect reports under change control and make it public: automatically in jira / gitlab issues
• create a defect report template

Technical Reviews

This is an activity that assures quality upstream in the process.

• can be: walkthroughs, inspections, code reading
• time to talk about code:
  • juniors can learn from seniors and seniors can fix problems in juniors code
  • challenge old ways of doing things

Review pattern:

1. Notification and distribution: developer informs reviewer that code is ready for review and shares material for review
2. Preparation: Review happens, aided by checklist of common errors
3. Review Meeting: talk about the review
4. Review Report: log statistics of review: amount of defects, time spent for review, meeting, etc, pass or fail
5. Follow-up: Fix the problems and review again until product passes the review.

Suggestions

• focus on defect detection, do not try to create solutions
• start reviews early in the project
• keep technical reviews technical and be honest about defects
• keep track of what material has been reviewed
• record the defects during reviews and list them in the report
• Verify that defects found during review are actually fixed (in the follow-up)
• make review results public to the project team
• schedule time for reviews and errorfixing of found defects

System Testing

This is an activity that assures quality downstream in the process, compared to technical reviews. Usually developers cannot wear both the developers' hat as well as the tester's hat: have different people do this.

• Start system testing as soon as you have the first executable software
• Use a requirements traceability matrix to ensure all requirements are covered.
  • test cases as rows
  • requirements as columns
  • every row and column need at least one mark, else they are useless
• Automate the testcases. The more critical the software is, the more testers per developers are needed.

[!Quote] Testing vs Quality Assurance Testing is a means of discovering the quality level of a software system, not a means of assuring software quality.

Beta Testing

Release of software to a selected group of testers.

Other

! !

Have measurable criteria for software releases.

[!question] Survival Check

• 👍🏼 Project has a written, approved Quality Assurance Plan.
  • 💣 Project isn't following the written plan.
• 👍🏼 Quality assurance is initiated in parallel with requirements work.
• 👍🏼 Defect tracking software is placed online at requirements development time, and defects are tracked from the beginning of the project.
• 👍🏼 Developers review all designs and code before the designs and code are considered "done."
  • 💣 No designs or code have failed their reviews, suggesting that reviews are superficial.
  • 💣 Developers don't source trace and unit test their own source code prior to submitting it for review, which gives rise to an unwieldy number of defects that have to be tracked from reviews onward.
• 👍🏼 The Quality Assurance Plan calls for an independent quality assurance group.
  • 💣 No funding is available for an independent quality assurance group.
• 👍🏼 The Quality Assurance Plan contains measurable criteria that are used to determine whether the software is ready to be released.

Architecture

Survival Preparations

---

Steps towards the Software release

1. Define preliminary risks list
2. Define requirements
3. Create initial project estimate (budget, schedule, staffing, desired feature set).

Document List

• Top 10 Risk List (keeps being updated) including a risk-management plan for each risk
• Software Development Plan
  • Risk management approach
  • Risk officer and other roles: personnell strategies
  • Decision making authority
  • project scope
  • publicizing of plans and progress
  • time accounting
  • once finished sign off by project manager, dev team and Q&A team, then place under change control
• Quality Assurance Plan
  • defect report template to be used to report defects (see page 130)
  • review checklists for different parts

Tool list

• Anonymous risk-reporting channel

Review List

• Review Top 10 Risks every 2 Weeks (see page 97)

---

Software Project Survival Guide Steve McConnell 
-file: "Software Project Survival Guide by Steve McConnell.md"