Software Process Improvement
Prerequisite Knowledge
This lecture builds on the following concepts from earlier lectures. If any feel unfamiliar, review the linked notes before proceeding.
Previously Covered in This Subject
- The triple constraint: good, fast, cheap — covered in Lecture 1 (Introduction to Software Engineering)
- Process improvement — covered in Lecture 2 (Software Processes)
- Software quality versus manufacturing quality, and process-based quality and its limits — covered in Lecture 10 (Software Quality Management)
- CMMI and continuous process improvement — covered in Lecture 11 (Software Quality Management)
- Software measurement and product and process measurements — covered in Lectures 11 and 12 (Software Quality Management; Software Measurement and Metrics)
Software Process Improvement
Software process improvement is one part of software quality management, and it asks a deceptively simple question: can you make the software better by making the way it is built better? The process-based view answers yes: if you fix the process that produces a product, you are likely to get a good-quality product. That link is direct for manufactured goods — calibrate the assembly line and the cars roll out consistent — but software is built by people, with creativity, design decisions and human factors, so process quality and product quality are not always directly related. Still, it is generally worthwhile to improve the process, because a better process tends to raise product quality, influence the productivity of the developers, and open the door to ideas like process capability and the CMMI model.
The rest of this lecture walks the full improvement path in order. First comes the relationship between process quality and product quality — why the manufacturing intuition works, and where it breaks for software. Then the classification of software processes, which tells you which kind of process you are dealing with. Next, measurement of processes: what to count, and the goal-question-metric way of choosing what to count. After measurement comes analysis and modeling — looking inside the process to find bottlenecks and exceptions. Finally, change: how to introduce improvements in a way that survives contact with the people who must use them, and the CMMI framework that gives the whole effort a maturity scale to climb.
13.1 What Software Process Improvement Means
13.1.1 Why Improve the Process at All
A close link exists between the quality of a development process and the quality of the products developed with that process. This is true of all manufactured products: improve the process and the product improves with it. Improving the software process is how an organization produces better software, and many software engineering companies have turned to process improvement as a way of enhancing software quality.
Hook — why fix the way you work, instead of just working harder?
If every project ran the same chaotic way and still shipped, nobody would touch the process. The reason organizations do touch it is the promise behind the triple constraints of software engineering — good, fast and cheap. You cannot have all three at once, and process improvement is the search for the best balance for a particular project.
Process improvement means understanding the existing processes and then changing them wherever required, with three possible goals: increase product quality, reduce cost, or reduce development time. These three goals map straight onto the triple constraints of software engineering — good, fast and cheap. You cannot be good, fast and cheap at the same time, and process improvement is the search for the best balance for a particular project.
Exam note: the good-fast-cheap triple constraint is the direct motivation for every improvement goal that follows. When asked why an organization improves its process at all, start from "good, fast, cheap" and expand each goal into its measure — fewer defects, lower cost, shorter schedule.
Most of the literature on process improvement focuses first on perfecting processes to improve product quality, and in particular to reduce the number of defects in delivered software. Only after defects are under control do the principal goals shift to cost or schedule reductions. Defect-reduction programs like Six Sigma help you remove defects first; only then should you turn your attention to cutting cost or time.
Worked example — the defect-first sequence.
A development organization ships a release with 40 defects found by customers in the first year. Its improvement program follows the defect-first order:
- Defect reduction first: introduce code inspections and statistical defect tracking; the goal is fewer customer-found defects in the next release.
- Defect count under control: after two releases, customer-found defects drop to 12 per year — the process is now repeatable enough that its output is predictable.
- Only then cost or time: with defects contained, the organization shifts its goal to reducing development cost by 10% and shortening delivery time by one month.
Sense-check: the second step does not succeed by accident — it succeeds because the defect-reduction program (measuring defects, fixing the process that caused them, re-measuring) ran first. Without that sequence, a fast and cheap process simply produces more bad software faster.
Real-world: Six Sigma-style statistical defect reduction is exactly the kind of process-improvement program the quality movement applies in industry. Six Sigma aims for a defect rate of about 3.4 defects per million opportunities, and its define-measure-analyze-improve-control (DMAIC) loop is the defect-first philosophy made operational: improve the process, then control it so the defects do not come back.
13.1.2 Process Attributes and Their Trade-offs
Software processes are inherently complex and involve a very large number of activities. Like any other product, a process has attributes or characteristics of its own. The eight process attributes are:
The eight process attributes — the dimensions along which any software process can be judged:
- Understandability — how easy the process is to grasp.
- Visibility — how much of the process can be observed and measured.
- Supportability — how well the process is supported by tools and infrastructure.
- Acceptability — how acceptable the process is to the people who use it.
- Reliability — how consistently the process delivers its results.
- Robustness — how well the process survives surprises and failures.
- Maintainability — how easy the process is to modify and evolve.
- Rapidity — swiftness, efficiency, speed of development.
Intuition — a process is a product too.
Think of a process as a machine whose output is software, and the eight attributes as the machine's spec sheet. Understandability is whether you can read the manual; visibility is whether you can see inside the machine while it runs; robustness is whether it keeps working when the power dips. The catch, which the spec sheet never advertises, is that you cannot tune every dial to maximum at once — improving one attribute usually worsens another.
You cannot make process improvements that optimize all of these attributes simultaneously, and no two can both be maximized in the same process. The classic trade-off is rapidity against visibility. Think of agile development: you develop at a very swift pace and you cannot afford to create elaborate documentation for each and every iteration or follow a heavy set of standards. Agile methods deliberately focus on product quality and compromise on visibility. But a manager needs visibility, because only through visibility can the progress of the project be measured — how far the project has gone, how much has been done. Making a process visible means producing documents at periodic intervals for every iteration, and that inevitably slows the process down. So if you include visibility, you reduce rapidity.
Pitfall — the all-optimized process does not exist.
Two mistakes beginners make here:
- Believing the eight attributes can all be maximized. They cannot: rapidity and visibility trade off directly, and many other pairs collide too (supportability can fight acceptability when heavy tooling alienates the team; robustness can fight rapidity when every failure path is engineered in advance).
- Believing the trade-off means one attribute must be sacrificed entirely. Improvement means choosing which attributes to sacrifice — the process is a portfolio of compromises, and the skill is picking the right compromise for the project.
The agile example is the classic illustration: agile optimizes rapidity and product quality, and deliberately sacrifices visibility (thin documentation, few prescribed standards). That is not a failure of agile — it is the cost of speed.
13.1.3 Improvement Is Project-Specific, Never Copied
Process improvement does not simply mean adopting particular methods or tools, or importing a process model that has been used elsewhere. Organizations that develop the same type of software do share a lot of process commonality, but every organization has local factors, procedures and standards that shape its process. If you simply try to change your process to the one used somewhere else, you will rarely be successful. You cannot replicate a process implemented elsewhere and expect it to work here.
Analogy — a recipe and a kitchen.
Two kitchens can both bake sourdough, but the recipe from one kitchen does not transfer wholesale to the other: the humidity, the oven, the flour, the staff's habits are all different. Software organizations are the same — two companies both build banking software, but their local standards, team culture, tooling history and customer constraints shape their processes differently. The recipe (the process model) is a starting point, never a finished transfer. Where the analogy breaks: baking is fully repeatable chemistry, while software development involves design decisions, so even a perfectly copied recipe cannot guarantee the same product.
Always treat process improvement as specific to a project, or to an organization, or to a part of a larger organization. And treat it as a cyclical, continuous activity that goes through several iterations — continuous quality improvement. The maturity levels in CMMI mirror this: the higher levels move from defined, to managed, to quantitatively managed, and finally to optimizing, which is continuous improvement.
13.1.4 The Process Improvement Cycle
The process improvement cycle has three important stages:
The three-stage improvement cycle — every round of improvement runs the same loop:
- Process measurement sits at the top of the cycle. The attributes of the current project or product are measured, and the aim is to improve the measures according to the goals of the organization involved — the project team, the product team, or the whole organization.
- Process analysis assesses the current process, studies its weaknesses, and identifies bottlenecks. Process models that describe the process are also developed during this stage, which is sometimes called process analysis and modeling. Flow charts and other process diagrams make the process visible so you can see where the bottlenecks are and what can be improved.
- Process change introduces the changes identified during analysis, but incrementally — changes are introduced gradually and their impact on the process and product quality is measured.
Worked example — one complete cycle.
A product team wants shorter development time (goal). The cycle runs:
- Measurement: record that the average time from requirements acceptance to completion of architectural design is 14 weeks, with 6 weeks spent on rework.
- Analysis: the flow chart of the process shows a bottleneck — design reviews happen at the end of the design phase, so errors are found late, after each designer has built on top of them. The process model makes this visible.
- Change: introduce weekly incremental design reviews instead of one end-of-phase review, and measure the impact.
After the change, the same measurement shows 10 weeks end-to-end and 3 weeks of rework. The cycle repeats: measurement, analysis, change, again.
Every cycle is measurement, analysis, change. Each stage may last several months or even years, so process improvement is a long-term business activity. It is also continuous: as new processes are introduced, the business environment changes, and the processes themselves must evolve to take those changes into account. The changes never remain constant.
Recap + bridge. Process improvement = understanding your process, then changing it deliberately, with the good-fast-cheap balance as the goal, the eight attributes as the dials you cannot all turn to maximum, and measurement-analysis-change as the repeating loop. The whole enterprise rests on one assumption, examined next: that a better process really does produce a better product.
13.2 Process Quality and Product Quality
13.2.1 The Core Assumption and Its Manufacturing Roots
Q: Do you agree that a good process leads to a good product?
A: Yes — process improvement rests on this assumption: the quality of the product development process is critical to product quality. It is tempting to think a good process always produces a good product, just as in manufacturing, where the link is direct and clear: improve the process, avoid defects, get better products. But for software the link is weaker, because the product is intangible and depends on creative, intellectual processes that cannot be automated. Software quality rests on a design process where individual human capability, creativity and effort matter a great deal. In some classes of product, though, the process is the most significant determinant of quality — especially large distributed systems developed by multiple teams across geographical locations. For innovative applications, in contrast, the people involved may matter more than the process, which is why agile teams focus on people and product quality.
That answer deserves a second look, because it contains both the root of process improvement and its first limit. The root: without a good process, even capable people produce inconsistent results. The limit: because software is designed rather than manufactured, the process is not the only — or always the dominant — influence on quality.
The notion of process improvement was originally proposed by Deming, the American quality engineer who worked with Japanese industry to improve quality. Japanese industry has been committed to continuous process improvement for many decades, and that commitment is acknowledged as the source of the high quality of Japanese manufactured goods. Deming and many others introduced the idea of statistical quality control.
How statistical quality control works — the loop that makes a process predictable:
- Measure the defects — count the number of product defects, and relate those defects to the process that produced them.
- Improve the process — change the process until it is repeatable and calibrated: the same steps give the same results, and the defect count falls.
- Standardize — fix the improved process as the new standard, making its output predictable.
- Repeat — a fresh cycle of measurement, analysis and change begins, driving the defect count lower still.
The goal is a process whose results are predictable: run it the same way, and you know roughly what quality you will get.
Real-world: this is how quality-driven manufacturing works in practice — measure defects, fix the process, standardize, repeat. The same loop reappears throughout this lecture: the improvement cycle of measurement, analysis and change is simply statistical quality control applied to software.
13.2.2 Why Software Is Not Manufacturing
Authors who write about process management have argued that the techniques of manufacturing — statistical process control and the rest — can be applied to software engineering as well. While there are similarities, it is not easy to agree that the results transfer directly.
In manufacturing the process–product quality relationship is very obvious: improving the process so defects are avoided leads to better products. That link is less obvious when the product is intangible and depends to a large extent on intellectual processes that cannot be automated. Software quality is not dependent on a manufacturing process but on a design process, where individual human capabilities, creativity and effort are significant.
Analogy — movies, books and poems.
Think of software the way you think of a novel. No publisher improves the quality of novels by calibrating the printing presses; the printing process only decides whether the ink is smudged. The quality of the story comes from the author's design — plot, characters, structure — and that cannot be automated or standardized into a repeatable production line. The same reasoning applies to any intellectual product: wherever quality depends on design, the people doing the design dominate.
The strength of the link depends on the class of product. In large distributed systems developed by multiple teams across geographical locations, the process is often the most significant determinant of product quality — the process carries a significant impact. In innovative applications in particular, the people involved may be more important than the process, which is why agile focuses on people and product quality.
Comparison — manufacturing versus software design:
| Dimension | Manufacturing | Software design |
|---|---|---|
| Product | Tangible, physical | Intangible |
| Process role | Direct: calibrate the line, quality follows | Indirect: creative, intellectual steps dominate |
| Key quality driver | The production process | Individual capability, creativity, effort |
| Where process still dominates | — | Large multi-team distributed systems |
| Standardization effect | Naturally beneficial | Can stifle creativity in innovative work |
When to pick which view: treat the process as the dominant factor for large, plan-driven, multi-team systems; treat the people as the dominant factor for small innovative projects.
13.2.3 The Four Factors That Affect Product Quality
Four main factors affect product quality: process quality, people quality, development technology, and cost, time and schedule. The four factors sit in a rectangle with product quality at the center and cost, time and schedule at the base — the base supports everything above it.
Visual intuition — the quality rectangle.
Picture a rectangle drawn on a whiteboard. Product quality is written in the middle. The three corners and the base hold the four factors: process quality and people quality at the two top corners, development technology at one of them (or on the sides), and cost, time and schedule running along the entire base. The base matters because it supports everything above it — a project with no budget, no time and an impossible schedule cannot hold up good quality no matter how strong the other factors are. The takeaway from the picture: the factors are not a ranking, they are a structure, and the base is non-negotiable.
With the rectangle in mind, the class discussion then went factor by factor, asking which one dominates — the answer always came back to the size and type of the project.
Q: Which of the four factors — process quality, people quality, development technology, cost, time and schedule — is most important for product quality?
A: It depends on the size and type of the project. For very large systems built as many separate subsystems by many teams working in different locations or even different companies, the main factor is the software process. The major problems in large projects are integration, project management and communications. The team usually mixes abilities and experience, development runs over a number of years, and the team keeps changing — it may even change completely over the lifetime of the project. So extraordinarily talented individuals do not usually dominate product quality over the whole project: you do not need a star developer or a star tester in a very large multi-team project.
Q: And for small projects?
A: For small projects — agile teams with only a few members — the quality of the people is much more important than the development process. If the team has high ability and experience, the product is likely to be of very high quality. If the team is inexperienced and unskilled, even a good process will not produce a high-quality product; a good process only limits the damage to some extent.
Q: Where does development technology matter most?
A: Development technology matters most in small, highly innovative projects. A small team cannot afford to spend much time on tedious administrative procedures or struggle with old technology — its members spend their time designing and programming, so good, efficient tools significantly boost their productivity. For large, long-lived, multi-location projects, the technology level is essential for information management, but a stable, basic level of technology is enough. Cutting-edge technology is less important there because most time goes into communication, coordination and project management rather than development: each person writes only a small portion of code, and the tools make little difference to team productivity.
Q: What about cost, time and schedule?
A: Cost, time and schedule are critical for every project, whatever its size. A project that is under-budgeted or planned with an unrealistic delivery schedule will see its quality affected. A good process needs resources to work effectively, and if the resources for testing, quality assurance and development are inadequate, even excellent people cannot save the project. If the deficit in cost, time and schedule is too great, no one can save it and product quality will be degraded.
The verdict from the four answers is compact enough to tabulate, and it is examinable in exactly this form.
Exam note: remember which factor dominates for which project type — process quality for large distributed plan-driven projects, people quality for small innovative agile teams, development technology for small projects, and cost, time and schedule for all projects.
The influence of each factor depends on the size and type of the project, summarized below.
| Project type | Dominant factor for product quality |
|---|---|
| Very large, multi-team, multi-location, plan-driven | Process quality |
| Small, innovative, agile teams | People quality |
| Small projects needing quick development | Development technology |
| Every project, regardless of size | Cost, time and schedule |
13.2.4 What Really Causes Software Quality Problems
The real cause of software quality problems is often not poor management, inadequate processes, or poor training. It is competitive pressure. Organizations must compete to survive: to gain a contract, a company may underestimate the effort required, or promise rapid delivery of the system to win the bid. To meet those unrealistic commitments, the company has to sacrifice software quality.
Pitfall — blaming the wrong culprits.
When a delivered system is full of defects, the instinct is to blame management, the process, or training. The history of real projects tells a different story: the quality failure often began the day the contract was won — the day effort was underestimated or an impossible delivery date was promised to beat a competitor. Once that unrealistic commitment exists, quality is the only variable left to sacrifice. If you diagnose quality problems, look for the competitive-pressure origin first.
Q: Have you come across a situation where budget or schedule constraints forced you to reduce the quality of testing?
A: A common view is that budget and schedule pressure leaves product quality unchanged. But if you do not have the money to test, or the time to test, you will not do elaborate testing — you ship the product with whatever it has, and quality suffers. When the deficit in cost, time and schedule is too great, no one can save the project.
The lesson is uncomfortable but important: quality is not only a technical property of the process, it is a business outcome of competitive decisions made before development even starts. A good process and good people are wasted if the organization's commitments are structurally impossible to meet.
13.3 Classification of Software Processes
13.3.1 Four Classes of Software Processes
Software processes can be observed in every organization, from one-person companies to large multinationals. They differ in the degree of formality of the process, the types of product being developed, the size of the organization, and so on. There are four general classes: informal processes, managed processes, methodical processes and supported processes.
The four process classes — a scale of increasing formality and tooling:
- Informal processes have no strictly defined process model. The development team chooses the process that is most appropriate for the project. An informal process may still use formal procedures — configuration management, for example — but the procedures and the relationships between them are defined as required by the development team. The process model defines the procedures, the scheduling and the relationships between the procedures.
- Managed processes have a defined process model, and that model is used to drive the development process.
- Methodical processes use defined development methods — systematic methods for object-oriented analysis and design, for instance — and benefit from computer-aided software engineering (CASE) tool support for design and analysis.
- Supported processes are processes whose activities are supported by automated CASE tools.
Intuition — a spectrum, not a ladder of quality.
The four classes are ordered by how much is predefined and automated, from "the team decides as it goes" (informal) to "tools carry out the activities" (supported). Do not read this as informal = bad, supported = good. A two-person start-up with an informal process can ship brilliant software; a regulated banking system almost certainly needs a managed or methodical process. The right class depends on the product, the team and the environment.
The key distinction to internalize: informal processes leave the process definition to the development team each time; managed processes bind the team to a defined model; methodical processes add systematic methods to that model; supported processes hand parts of the work to automated tools.
13.3.2 Overlapping Classes and Choosing a Process
These classifications overlap, and a process may fall into several classes at once. A process may be informal in that it is chosen by the development team, and the team may still choose a particular design method and support it with CASE tools — so the same process is informal, methodical and supported at the same time, and it may also be improving.
Professor's analogy — the short-lived transition program.
A program that supports transition from one type of computer system to another has a relatively short lifetime; its development does not need the standards and management procedures that are appropriate for software that will be used for many years. You would not impose a heavyweight, formally managed process on a piece of software that will be dead in six months — the process must fit the product's expected life, not the other way around.
The classification is useful as a basis for multidimensional process improvement. It helps organizations choose an appropriate process for their unique product development requirements, because the right process depends on the product.
Process classification recognizes that the process affects product quality, but it does not assume the process is always the dominant factor. Different types of process improvement apply to different process types: improvements to methodical processes might rest on better method training, better integration of requirements and design, and improved CASE tools.
Scope — where classification helps and where it stops.
Classification tells you which kind of process you have and which levers are available (better tools for a supported process, better training for a methodical one). It does not tell you the process is the dominant quality factor — the four-factor analysis from the previous section still applies, and for small innovative teams the people matter more than any process class.
13.3.3 Tool Support Across the Process Classes
Most software processes now have a lot of tool support. Analysis and design workbenches support methodical processes, but processes may have other kinds of tool support — prototyping tools and testing tools, for instance, whether or not a structured design method is used. The tool spectrum includes analysis and design workbenches, project management tools, modification management tools, and generic tools for the software process.
Tool effectiveness depends on the process classification. Generic tools — prototyping languages, compilers, debuggers, word processors — can be used in informal processes, but an informal process rarely uses more specialized tools in a consistent way. CASE tools can improve productivity when they match the process type.
| Tool type | Example | Fits which process class |
|---|---|---|
| Generic tools | Prototyping languages, compilers, debuggers, word processors | Informal processes (and any process) |
| Analysis and design workbenches | CASE tools for OO analysis/design | Methodical processes |
| Project management tools | Scheduling and tracking tools | Managed processes |
| Modification management tools | Configuration management | Any class that adopts formal procedures |
Recap + bridge. Real-world: choosing tooling for a project is a classification decision — heavy process, heavy tooling; light agile process, generic tooling. Classification tells you which process family you belong to; the next step is measurement, because you cannot improve a process you cannot quantify.
13.4 Process Measurement
13.4.1 What Process Measurement Is and Is Not
Process measurements are quantitative data about the software process. Measuring process and product attributes is essential for process improvement, and measurement also plays an important role in small-scale personal process improvement — a single developer improving their own practice.
Measurements are used to assess whether the efficiency of a process has improved. For example, the effort and time devoted to testing can be monitored; an effective improvement to the testing process should reduce the effort, the testing time, or both.
Intuition — the bathroom scale problem.
A scale tells you your weight has changed; it does not tell you the change is healthy. Process measurement works the same way. Time and effort measurements can show that the process is faster or cheaper, but they cannot, on their own, tell you that the product is better. That requires a second kind of data — product quality data — collected and connected to the process that produced it.
But process measurements on their own cannot determine whether product quality has improved. Product quality data must be collected and related to the process activities that produced the product. Measurements of the process and measurements of the product have to be connected before you can claim a quality improvement.
Pitfall — the disconnected measurement.
Beginners often collect one class of data and declare victory. Example: testing time fell by 20% after a process change, so "quality improved." Wrong — maybe the team simply skipped tests. Only when the process measure (testing time) is linked to the product measure (defects found in the release) can you support a quality claim. Never claim a quality improvement from process data alone.
13.4.2 Three Classes of Process Metrics
Three classes of process metrics can be collected.
The three metric classes — time, resources, and event occurrences:
- Time taken for a process to complete. This can be the total time devoted to the process, the calendar time, or the time spent on the process by the people involved.
- Resources required for the process. Resources include total effort in person-days, travel costs, and computer resources.
- Number of occurrences of a particular event. Examples of events that might be monitored include the number of defects discovered during code inspection, the number of requirements changes requested, and the average number of lines of code modified in response to a requirements change.
The first two classes — time and resources — show whether process changes improved the efficiency of the process. Software development has fixed points, such as the acceptance of requirements, the completion of architectural design, or the completion of test data generation, and you can measure the time and effort required to move from one fixed point to another. After changes are introduced, measurements of system attributes show whether the time or effort changed.
Event metrics have a more direct bearing on software quality. For example, if a changed program inspection process increases the number of defects discovered, product quality is probably improving — but this has to be confirmed by subsequent product measurements.
Worked example — the three classes on one process (testing).
| Metric class | Concrete metric | What a change would tell you |
|---|---|---|
| Time | Calendar days from completion of test data generation to release readiness | Was testing faster after the change? |
| Resources | Total testing effort in person-days | Did the change consume less labor? |
| Event occurrences | Number of defects found during code inspection | Did the new inspection process find more defects? |
Sense-check: the first two rows measure efficiency (faster, cheaper testing), the third measures effectiveness (more defects caught). Efficiency without effectiveness is exactly the pitfall from 13.4.1.
Exam note: the three classes of process metrics — time, resources, and event occurrences — are the core content of process measurement.
13.4.3 The Goal-Question-Metric Approach
The fundamental difficulty in process measurement is knowing what to measure. The goal question metric (GQM) paradigm helps decide what measurement should be taken and how it should be used.
Intuition — decide the question before collecting the data.
Collecting data without a purpose is like recording every reading from every instrument on a ship: you end up with terabytes of numbers and no idea whether you are sinking. GQM inverts the process — you start from the destination (the goal), work back to the questions whose answers would tell you whether the goal is being reached, and only then choose the metrics that answer those questions.
- Goals describe what the organization is trying to achieve. Examples: improved programmer productivity, shorter product development time, increased product reliability.
- Questions refine the goals into specific areas of uncertainty. A goal normally has several associated questions: how can the number of lines of code debugged be increased? How can the time required to finalize product requirements be reduced? How can more effective reliability assessments be made?
- Metrics are the measurements that must be collected to answer the questions and to confirm whether the process improvements achieved the goal. In the examples above: the productivity of individual programmers in lines of code and their level of experience; the number of formal communications between client and contractor for each requirements change; the number of tests required to cause product failure.
Worked example — GQM end to end.
Goal: improve programmer productivity. Question 1: how can the number of lines of code debugged be increased? Metric 1a: productivity of individual programmers in lines of code; Metric 1b: the programmers' level of experience. Question 2: how can the time to finalize product requirements be reduced? Metric 2: the number of formal communications between client and contractor for each requirements change.
Every metric is traceable: it answers a question, which serves a goal. If a proposed metric answers no question, it is dropped — that is the whole point of GQM's focus.
The advantage of GQM for process improvement is that it separates organizational concerns — the goals — from specific process concerns — the questions. It focuses data collection, and it suggests the collected data be analyzed in different ways depending on the question it is meant to answer. GQM has been used in several process improvement programs.
Recap + bridge. Real-world: GQM combined with the Software Engineering Institute's capability maturity model is what gave rise to software process improvement as a discipline. Measurement tells you what is happening; the next stage — process analysis and modeling — tells you why.
13.5 Process Analysis and Modeling
13.5.1 What Analysis and Modeling Achieve
Process analysis and modeling studies existing processes and develops an abstract model of them that captures their key characteristics. The models help you understand the process and communicate that understanding to others — the same way process model fragments are used to discuss specific activities like requirements engineering and software design.
Process analysis follows process measurement, but this is a simplification: in reality the activities are intertwined. You need some analysis to know what to measure, and while making measurements you inevitably develop a deeper understanding of the process being measured. Analysis is concerned with studying existing processes to understand the relationships between the parts. The initial stages are qualitative — the analyst discovers the key features of the model. Later stages may be quantitative and make use of the collected process measurements. After analysis is complete, you describe and document the process using a software process model: a flowchart or an activity diagram.
Intuition — a map of the territory.
A process model is a map. The map is not the territory: it leaves out hundreds of details, but it shows the roads (activities), the junctions (deliverables and handoffs) and the roundabouts (bottlenecks) well enough to plan a route. Analysis is the work of drawing that map accurately — discovering where the roads really run before deciding which ones to widen.
Pitfall — measuring without a map.
A common beginner error is jumping straight into collecting numbers without first drawing the abstract model. But you need some analysis to know what to measure — the map tells you where the interesting junctions are. If you measure first, you do not know which numbers matter; if you only analyze, you never learn whether the process improved. The two activities feed each other and are never cleanly separated in practice.
13.5.2 Starting from the Formal Process Model
The starting point for process analysis should be a formal process model, and many organizations have such a model — it may even be imposed on them by the customer. The standard defines the critical activities and lifecycle deliverables that must be produced as part of the process.
Why start from the formal model.
A formal process model is the organization's official description of its own process — what the customer contract or the company standard says happens. It is a good starting point for three reasons: it exists (someone already wrote it down), it is authoritative (it defines the critical activities and the lifecycle deliverables everyone must produce), and it gives you a vocabulary for discussing the process with the engineers.
Formal models are a useful starting point, but they rarely include enough detail to reflect the real activities of software development. They are fairly abstract and define only the principal process activities and deliverables. It is usually necessary to look inside the model to find the real process that is practiced. Also, the actual process often differs significantly from the formal model, although the specified deliverables will usually still be produced.
Worked example — the formal model versus the practiced process.
A company's formal model says: design → code → test → release, with an inspection after each step. Observation shows the practiced process is: design → code → (informal self-check) → test → release, and the inspections only happen when the customer is visiting. The deliverables — inspection reports — are still produced, often filled in after the fact to look compliant.
The gap is the starting point for improvement: the formal model is the reference, the observed process is the reality, and analysis must reconcile them before any change is made.
13.5.3 Analysis Techniques: Questionnaires, Interviews, and Observation
Several techniques exist for process analysis. You can use questionnaires and interviews, interacting with the engineers working on a project about what actually goes on. Answers to a formal questionnaire are refined during personal interviews with the people involved in the process, and the discussions can be structured around the process model, which is refined further as more information becomes available.
Observation can be combined with questionnaires and interviews: ethnographic studies reveal the nature of software development as a team activity, and they uncover subtleties and complexities that other techniques miss.
Comparison — three techniques side by side.
| Technique | What you get | Weakness |
|---|---|---|
| Questionnaire | Broad answers from many people, cheap to run | Shallow; people can give the answer they think you want |
| Interview | Depth on specific points, can probe | Slow; one person's view; same "please the interviewer" risk |
| Ethnographic observation | What people actually do, not what they say | Slowest and most costly; observer presence changes behavior |
When to pick which: start with a questionnaire to map the territory, use interviews to refine the points that matter, and use observation to check the answers against reality.
Each approach has advantages and disadvantages. The big weakness: the engineers being questioned may give the answers they think you want to hear rather than the truth about the process used. You may prefer an open-ended interview to a close-ended one for this reason — open-ended questions are harder to answer with the answer the interviewer wants.
Pitfall — the please-the-interviewer effect.
If you ask a close-ended question — "does the team always follow the defined process?" — the polite answer is "yes," because the engineer assumes that is what you want to hear. Open-ended questions — "walk me through how a change request actually gets handled last week" — force the engineer to describe reality rather than recite the official story. This is a structural weakness of questioning-based analysis; observation is the only fully reliable guard against it.
13.5.4 Process Models: From Abstract to Detailed
Process models are simplified views of the software process that show the activities and the outputs of the process. At the very abstract level, processes in many organizations look the same — but these generic models have different instantiations in different companies or projects, depending on the type of software being developed and the organizational environment.
Abstract or generic models are useful as a basis for discussing the process, but they may not include enough information for process analysis and improvement. Process improvement needs information about all the activities, the deliverables, the people, the communications, the schedules, and the organizational factors that affect the process. A typical detailed process model records elements like:
The five elements of a detailed process model.
- Pre-conditions — what must hold before the activity starts.
- Post-conditions — what must hold after the activity completes.
- Role — who performs the activity.
- Process — the activity itself.
- Inputs and outputs — what the activity consumes and produces.
Detailed process models are extremely complex. Even a single testing process has an elaborate set of roles, responsibilities, inputs, outputs, pre-conditions and post-conditions, and each element can decompose into further sub-processes. Rather than forcing all information into one simple model, you may have to make several models at different stages of abstraction, related and combined through common elements such as activities and deliverables. Some models deal with cross-activities, others with the control information that drives process execution.
Worked example — one activity modeled in full detail.
Take the activity "code inspection." Its detailed model element: pre-condition — the code module is unit-compiled and the author has produced the inspection checklist; post-condition — inspection report filed and agreed rework items logged; role — moderator, author, and two inspectors; process — walk through the module line by line against the checklist; inputs — source code, checklist, design documents; outputs — inspection report, rework list. Notice how the single activity already has an elaborate structure, and each input or role can itself decompose further — which is why several models at different abstraction levels are usually needed rather than one universal diagram.
13.5.5 Process Exceptions and Dynamic Adaptation
Software processes are very complex entities. A defined process model can only ever represent the ideal situation — the situation where the development team faces no unanticipated problems. In reality, unanticipated, surprising problems are a fact of everyday life for project managers.
Intuition — the model is the fair-weather route.
A process model describes the journey under ideal conditions. Real project managers drive the same route in storms: people fall ill, systems go down, the organization reshuffles, and new proposals demand attention. Nobody plans the storm route in advance — but a good manager knows the fair-weather map well enough to improvise detours when the storm hits.
Examples of the exceptions a project manager may face: several people falling ill at the same time just before a critical project release; a breach of security that puts all external communications out of action for several hours; an organizational reorganization that forces managers to spend much of their time on organizational matters instead of development and project management; an unanticipated request to write proposals for new projects, forcing effort to be transferred from the project to the proposals.
In general, the effect of an exception is that the resources, budgets or schedules of the project change. It is difficult to predict all exceptions well in advance and to incorporate them into a formal process model. So you often have to work out how to handle each exception as it arrives and dynamically change the standard process to cope.
Scope — why exceptions cannot be modeled away.
A formal process model is inevitably incomplete: it captures the ideal, not the exceptions. The manager's job includes dealing with exceptions and adapting the process as required — dynamically, in real time, case by case. Do not expect a better model to eliminate exceptions; expect better handling of them.
Recap + bridge. Analysis produces a model of the process — starting from the formal model, questioning, interviewing and observing to find the real process, then detailing activities with pre-conditions, roles, inputs and outputs, while remembering that exceptions will always force dynamic adaptation. The next step turns analysis findings into action: process change.
13.6 Process Change
13.6.1 What Process Change Involves
Process change is the third stage of the cyclical process of measurement, analysis and change. It means making modifications to the existing process, by introducing new practices, methods or tools, by changing the ordering of process activities, by introducing or removing deliverables from the process, or by introducing new roles or responsibilities.
What change can touch — the five modification levers.
- Practices — new procedures, e.g., a daily stand-up meeting.
- Methods — new development methods, e.g., switching to test-driven development.
- Tools — new tooling, e.g., an automated build system.
- Ordering — changing the sequence of activities, e.g., reviews before, not after, integration.
- Deliverables and roles — adding or removing work products, and creating or reassigning responsibilities.
You should set goals for the process improvement — for example, reducing the number of defects removed or discovered during an inspection or during integration testing by a certain percentage. These goals drive the process changes, and after the changes are implemented, the same goals are used to measure progress.
Intuition — the goal is the contract for the change.
A change without a numeric goal is unfalsifiable: you cannot tell whether it worked. Saying "we will reduce defects found in integration testing by 30%" turns the change into a testable hypothesis — if the percentage does not move, the change did not work and the cycle continues. The same goals used to drive the change are the yardsticks used to evaluate it afterwards.
13.6.2 The Five Stages of Process Change
The process change process has five stages.
The five stages of process change — identification → prioritization → introduction → training → tuning:
- Improvement identification. Use the results of the process analysis to identify quality, schedule or cost bottlenecks — places where process factors might adversely influence product quality. Improvement should focus on loosening these bottlenecks by proposing new procedures, methods and tools to address the problems.
- Prioritization of improvements. Assess the possible changes and prioritize them for implementation. When many changes have been identified, it is usually impossible to introduce them all at once. Decide which are most important, based on the need to improve specific process areas, the cost of introducing the change, the impact of the change on the organization, and other factors.
- Process change introduction. Put the new procedures, methods and tools into place and integrate them with the process activities. Allow enough time to introduce the changes and ensure they are compatible with other process activities and with organizational procedures and standards.
- Process change training. Without training, it is not possible to gain full benefit from the process changes. Process managers and software engineers may simply refuse to accept the new process. Changes imposed without adequate training degrade product quality rather than improve it.
- Change tuning. Proposed process changes are never completely effective as soon as they are introduced. A tuning phase discovers minor problems and proposes and introduces modifications. The tuning phase should last several months, until the development engineers are happy with the new process.
Worked example — all five stages on one change.
An analysis identifies a bottleneck: 40% of integration testing time is spent fixing defects that a code inspection would have caught. The five stages run:
- Identification — the bottleneck is "late defect discovery," and the proposed improvement is a mandatory code inspection before integration.
- Prioritization — the inspection change is ranked above two other candidate changes (a new debugger, a reporting template) because it targets the largest cost and requires the least new tooling.
- Introduction — inspection checklists are written, inspection slots are added to the schedule, and the change is announced with enough lead time.
- Training — all engineers attend a half-day inspection training session; without it, the inspections become rubber-stamps.
- Tuning — the first months show inspections are too long; the checklist is trimmed from 40 to 25 items, cutting inspection time by half while retaining defect detection.
Sense-check: the same goal — defect reduction during integration testing — was measured before and after, and the improvement was only achieved because the training stage was not skipped.
Once a change is introduced, the improvement process iterates: further analysis identifies new process problems, new improvements are proposed, and so on. It is impractical to introduce too many changes at the same time — apart from the training problems this causes, introducing many changes at once makes it impossible to assess the effect of each individual change on the process.
Pitfall — changing everything at once.
Two failures compound when changes are batched. First, training fails: the team cannot absorb ten new procedures at once and quietly ignores the ones it dislikes. Second, measurement fails: if three changes land in the same release and the defect count drops, you cannot say which change caused the improvement. Change one thing, measure, then change the next.
13.6.3 Training and the Human Side of Change
As a manager you have to be sensitive to the feelings of the people in your team while introducing any process change. Old-fashioned ideas like business process re-engineering, which involved making radical process changes, were largely unsuccessful because they failed to take the legitimate concerns of the people involved into account. People felt their expertise was being ignored and their jobs changed without consultation, so they actively resisted the changes and made sure the changes would not work.
Professor's analogy — the re-engineering cautionary tale.
Business process re-engineering promised dramatic gains by radically redesigning how organizations worked. It mostly failed — not because the redesigned processes were technically wrong, but because the people whose expertise the old process embodied were never consulted. Their jobs changed without discussion, their experience was treated as irrelevant, and they responded the only way they could: they made sure the new process would not work. The lesson carries over to software process change at any scale: a process change imposed on people is a change opposed by people.
There is no question that some people feel threatened by change and worry that they may lose their job or be unable to cope with new ways of working. The remedy: involve the team all the way through the change process, understand their doubts, and involve them in planning the new process — make them stakeholders in the process change. When people own the change, they are much more likely to want to make it work successfully.
Recap + bridge. Change is the payoff stage of the improvement cycle, run through five stages with training and tuning, and it succeeds or fails on the human side: people who own the change make it work, people who are handed it resist it. The final topic of the lecture scales this whole story up into a formal framework — CMMI.
13.7 The CMMI Process Improvement Framework
13.7.1 Origins and the Two Instantiations
The Software Engineering Institute (SEI) at Carnegie Mellon University was established to improve the capability of the USA software industry. The SEI developed the CMM — the capability maturity model — and later the integrated CMMI, which supersedes the earlier CMM models. CMMI is intended as a framework for process improvement with broad applicability across a range of companies.
CMMI has two instantiations: the staged version and the continuous version. The staged version is compatible with the original software CMM; it allows an organization's system development and management process to be assessed and assigned a maturity level from 1 to 5. The continuous version allows fine-grained classification and rates 24 process areas on a scale from 1 to 6. The full CMMI model is very complex — thousands of pages of description — so what follows covers only its main aspects.
Intuition — two ways to take the stairs.
The staged version is like climbing a fixed staircase: every organization starts at the same bottom step and is assessed against the same sequence of landings (maturity levels 1 to 5). The continuous version is like a ladder you can place where you like: each process area is rated individually on its own capability scale, and you decide which rungs to work on first. Both are the same CMMI model — same process areas, same goals, same practices — packaged in two different assessment philosophies.
13.7.2 Three Components: Process Areas, Goals, and Practices
The CMMI model has three important components.
The three CMMI components:
- Process areas. CMMI identifies 24 process areas relevant to software process capability and improvement, organized into four groups in the continuous model: process management, project management, engineering, and support.
- Goals. Goals are abstract descriptions of a desirable state the organization should attain. CMMI defines specific goals associated with each process area, which define the desirable state for that area, and generic goals associated with the institutionalization of good practice.
- Practices. Practices are descriptions of ways to achieve a goal. Up to seven specific and generic practices must be associated with each goal within each process area.
CMMI recognizes that the goal is more important than the way the goal is achieved. Organizations may use any appropriate practices — alternative practices — to achieve the CMMI goals; they do not have to follow the CMMI's recommended practices strictly.
Professor's key insight — the goal, not the recipe.
CMMI does not prescribe one correct way of working. If your organization achieves the goal of a process area through its own alternative practices, that is fully acceptable — the recommended practices are illustrations, not requirements. This is what makes the framework usable across very different companies: the destination is fixed, the route is not.
Generic goals and practices are not technical; they concern institutionalization — making good practice stick. What institutionalization means depends on the maturity of the organization. For a young organization at an early stage of maturity, institutionalization may mean following established plans and procedures. For a more mature organization with advanced processes, it may mean controlling the process using statistical and other quantitative techniques.
Worked example — specific versus generic goals in project planning.
The project planning process area has specific goals (e.g., "establish estimates," "develop a project plan," "obtain commitment to the plan"). It also carries generic goals, one per capability level — e.g., the generic goal "institutionalize a managed process." The specific goals ask what the process must achieve (a plan exists, estimates are made); the generic goals ask how firmly the process is embedded (there is an organizational policy, people are trained, the process is monitored and reviewed by higher management). An organization can satisfy all specific goals of project planning yet still fail the generic goal at level 2 because no policy and no monitoring exist — the process works once, but is not institutionalized.
13.7.3 Capability Levels: The Six-Point Scale
CMMI assessment examines the processes in an organization and rates each process area on a six-point capability scale:
The six-point capability scale — the continuous model's rating system:
- Not performed (0) — one or more of the specific goals associated with the process area is not performed or not satisfied.
- Performed (1) — the goals associated with the process area are satisfied, and the scope of work is explicitly set out and communicated to the team members.
- Managed (2) — the goals are met, and organizational policies are in place defining when each process should be used. Documented plans, resource management and process monitoring procedures must be in place across the institution.
- Defined (3) — the focus is on organization-wide standardization and deployment of the process. Each project has a managed process tailored from a defined set of organizational process assets, and process measurement data must be collected and used for future process improvements.
- Quantitatively managed (4) — the organization has a responsibility to use statistical and other quantitative methods to control subprocesses; collected process and product measurements must be used in process management and improvement.
- Optimizing (5) — the organization must use process and product measurements to drive process improvement: trends are analyzed and the process adapted to changing business needs.
The scale is described two ways in the source material: as "from 1 to 6" and as six levels numbered 0 to 5. The two wordings describe the same six-point scale. The official CMMI numbering labels the lowest level 0 (not performed) and the highest level 5 (optimizing), giving levels 0, 1, 2, 3, 4, 5 — exactly the six levels listed above. The phrase "a scale from 1 to 6" counts the same six levels starting at 1 instead of 0 (1 = not performed, 6 = optimizing), a common shorthand in informal summaries. Either way, there are six levels, and "0" in the official numbering corresponds to "1" in the counting version — the reference material lists the levels as "not performed (0)" through "optimizing (5)", which is the numbering to use in exams.
This description is simplified, but you can think of the levels as progressive: explicit process descriptions at the lowest levels, process standardization at the middle levels, and process change and improvement driven by measurement at the higher levels.
Pitfall — confusing the staged and continuous scales.
The staged model has five maturity levels (1 to 5, for the whole organization); the continuous model has six capability levels (0 to 5, for each process area). The similarity of the names — "managed," "defined," "optimizing" appear in both — causes endless confusion. Ask yourself: is this rating applied to the whole organization (maturity, staged) or to one process area (capability, continuous)? The six-point scale of this section is the continuous model's capability scale.
13.7.4 The Staged Model
The staged CMMI model is comparable with the original software CMM. It provides a means to assess an organization's process capability at one of five levels: initial, managed, defined, quantitatively managed, and optimizing. These are discrete stages — that is why it is called the staged model. It prescribes the goals that should be achieved at each level, and process improvement is achieved by implementing the practices at each level, moving from the lower to the higher levels.
Each maturity level has an associated set of process areas. The level-2 (managed) process areas are: requirements management, project planning, project monitoring and control, supplier agreement management, measurement and analysis, process and product quality assurance, and configuration management.
In addition to specific practices, organizations operating at level 2 should achieve the generic goal of institutionalizing each of these processes as a managed process. For example, the institutional practices associated with project planning include: establishing and maintaining an organizational policy for planning and performing the project planning process; providing adequate resources for performing the process, developing the work products and providing the services of the process; monitoring and controlling the project planning process, raising the plan and taking corrective action; and reviewing the activities, status and results of the project planning process with high-level management, resolving the issues that surface.
Worked example — why the level-2 generic goal matters.
An organization produces excellent project plans — the specific goals of project planning are all satisfied. But the level-2 generic goal demands that planning be managed: a policy exists, resources are provided, the planning process is monitored and corrected, and high-level management reviews its results. A company where planning is a heroics-driven activity — the plans are good because one brilliant planner makes them good — cannot claim the managed level, because the process stops working when that person leaves. Institutionalization is exactly what turns individual excellence into organizational capability.
The advantage of the staged model, apart from its compatibility with the original software CMM, is that it defines a clear improvement pathway for organizations moving from the initial level up through the levels. Its disadvantage: it is more appropriate to introduce goals and practices at higher levels before the lower-level practices are achieved, and when organizations do this, a maturity assessment gives a misleading picture of their capability — the assessment claims a level the organization has not actually earned.
Pitfall — the misleading maturity assessment.
Because the staged model is a staircase, some organizations climb it out of order: they adopt level-3 or level-4 goals and practices while their level-2 foundations are still missing. Their assessment then claims a maturity level they have not actually earned. This is the classic objection to the staged model — the level label looks authoritative, but it can be bought by cherry-picking higher-level practices rather than earned by building the lower-level ones. The continuous model exists partly as a response to this weakness.
13.7.5 The Continuous Model
Some organizations choose the continuous model instead of the staged one. It does not classify the organization into discrete levels. It is fine-grained: it considers individual practices or groups of practices and assesses the use of each practice. The maturity assessment is not a single value but a set of values showing the organization's maturity for each process or process group.
The continuous model rates each process area and assigns it a capability assessment from 1 to 6. Process areas include project monitoring and control, supplier agreement management, risk management, configuration management, requirements management, verification, validation, and others. In the example given, configuration management sits at level 4 while risk management sits at level 1. Organizations normally operate at different maturity levels for different process areas.
The result of a continuous assessment is a capability profile showing each process area and its associated capability assessment. Organizations may develop actual capability profiles and target profiles: the target profile reflects the capability level the organization would like to reach for each process area.
Worked example — building a target profile.
An organization draws up its target profile for three process areas: configuration management → level 3, risk management → level 2, requirements management → level 4. Its actual profile today is: configuration management → level 4, risk management → level 1, requirements management → level 2. The gap analysis is immediate: risk management needs one level of work, requirements management needs two. Note the contrast with the staged model: no level in the target is a prerequisite for another — the organization works on each gap independently, in its own order.
The main advantage of the continuous model is that organizations can pick and choose processes to improve according to their own needs and requirements. Different types of organizations have different requirements: a company developing software for the aerospace industry may focus on system specification, configuration management and validation, while a web development company may focus on customer-facing processes. The staged model requires companies to focus on different process areas at different stages in turn; the continuous model allows more discretion and flexibility while retaining the support and benefit of CMMI for process improvement.
Comparison — staged versus continuous model.
| Dimension | Staged model | Continuous model |
|---|---|---|
| Unit of assessment | Whole organization | Individual process areas |
| Scale | Five maturity levels (1-5) | Six capability levels (0-5) |
| Result | Single maturity level | Capability profile (and optional target profile) |
| Order of improvement | Fixed staircase, level by level | Free choice of process areas |
| Compatibility | With original software CMM | Fine-grained classification |
When to pick which: choose the staged model when you want a clear, externally recognized single rating (and you can genuinely earn levels in order); choose the continuous model when different parts of your organization mature at different speeds and you want to target your own priorities.
Real-world: aerospace versus web development is a real contrast — heavy, regulated, verification-driven processes on one side, customer-facing agility on the other. CMMI accommodates both through the continuous model's freedom to choose process areas.
Recap + bridge. CMMI is the industrial-scale packaging of everything before it: process areas and goals/practices (the classification and analysis ideas), a capability/maturity scale (the measurement idea), and staged versus continuous pathways (the change idea, organized). With CMMI, process improvement moves from an individual project's cycle to an organization-wide, assessed, benchmarked discipline.
13.8 Summary
13.8.1 The Improvement Journey in One Page
Process improvement involves process analysis, process standardization, process measurement and change, and training is essential if the improvement is to be effective. Processes can be classified as informal, managed, methodical and supported — and improving — and this classification helps identify the kind of tool support a process needs.
The process improvement cycle has three stages: process measurement, process analysis (including process modeling), and process change. Measurement should answer specific questions about the software processes used, and those questions should be based on organizational improvement goals. The process metrics used fall into three classes: time-related metrics, resource-usage metrics, and event metrics — the frequency of occurrence of an event in a given activity. Process models — flow charts showing the distribution of activities, subprocesses, roles, exceptions, communications and deliverables — can be used to analyze bottlenecks in the various processes.
The one-page journey — the full chain at a glance.
- Why improve? The good-fast-cheap triple constraint: increase quality, reduce cost, reduce time — defects first, cost and schedule only afterwards (Six Sigma style).
- What is the process worth? Process quality drives product quality — strongly in manufacturing, weakly in software, where people and design dominate for innovative products.
- What kind of process do you have? Informal, managed, methodical, supported — which guides the tooling you choose.
- What is happening? Measure: time, resources, event occurrences — chosen via goals → questions → metrics (GQM).
- Why is it happening? Analyze and model: questionnaires, interviews, ethnographic observation; detail activities with pre-conditions, roles, inputs, outputs; expect exceptions.
- How do you fix it? Change in five stages — identification, prioritization, introduction, training, tuning — with the people on board.
- How do you scale it? CMMI: process areas, goals, practices; six-point capability scale; staged or continuous pathway.
The CMMI framework supports both styles of improvement: the staged model, with discrete stages from initial, managed, defined, quantitatively managed and optimizing, and the continuous model, where you select process areas, keep a target rating for achievement, and measure yourself on each process area as you choose to improve — because you do not want to go stage by stage, but would rather select the process areas you want to improve. CMMI improvement rests on reaching goals related to good software engineering practices, describing the process model, standardizing it, and controlling the practices used to achieve organizational quality goals. The model includes recommended practices that may be used, but they are not obligatory.
13.8.2 Where This Fits in Quality Management
Process improvement is the process-focused half of the quality management story. Product quality is managed by improving the process that produces the product; process quality and product quality are measured and linked; and the improvement cycle — measure, analyze, change — runs continuously.
Domain placement — process quality inside quality management.
Quality management has two halves. The product half checks the artifact itself — testing, reviews, verification that the delivered software meets its specification. The process half, covered in this lecture, manages quality upstream: measure the process, analyze it, change it, and let product quality follow. The two halves depend on each other — process measures alone cannot prove quality (13.4.1), and product measures alone cannot tell you where to intervene. Organizations that run both halves continuously are the ones that can honestly claim statistical quality control, and the ones for which frameworks like CMMI and programs like Six Sigma actually pay off.
The full treatment of this material sits in the chapter on process improvement in the textbook.
Exam Guidance Summary
The stated reference for this material is the chapter on process improvement in the textbook. The important aspects highlighted across the topic are the ones to revise:
- The three-stage improvement cycle — process measurement, process analysis (with modeling), and process change — and why the cycle is continuous and long-term.
- The triple constraints (good, fast, cheap) as the goals of improvement: improve quality, reduce cost, reduce development time.
- The eight process attributes and the trade-off example (rapidity versus visibility in agile development).
- The four factors affecting product quality and which factor dominates for which project type.
- The four process classes (informal, managed, methodical, supported) and how classification guides process and tool choice.
- The three classes of process metrics — time, resources, event occurrences — and the goal question metric (GQM) approach.
- The process analysis techniques (questionnaires, interviews, ethnographic observation) and their weakness.
- The five stages of process change and why training and team involvement are essential.
- CMMI: the 24 process areas in four groups, specific versus generic goals, practices, the six-point capability scale, and the difference between the staged and continuous models, including the level-2 process areas.
Exam note — how to study each bullet.
For each item above, be ready to do three things: state the definition in one sentence, give the lecture's example (agile for the rapidity-visibility trade-off, person-days for resource metrics, the transition program for process choice), and name the pitfall the discussion flagged (quality sacrificed under competitive pressure; training skipped; staged levels claimed out of order). The questions in the course were asked exactly at this level — definitions, examples, and which-factor / which-stage lists.
Key Industry Applications
- Six Sigma and statistical quality control — defect-first improvement programs used in industry, rooted in Deming's work with Japanese manufacturing. The DMAIC loop (define, measure, analyze, improve, control) is the operational form of the measurement-analysis-change cycle, with the defect rate target of about 3.4 defects per million opportunities.
- Agile development — the real-world trade-off of rapidity against visibility: product-focused, documentation-light, people-driven. Every agile team lives this trade-off daily, and it is the standard example for the eight-attribute trade-off discussion.
- CMMI (Software Engineering Institute, Carnegie Mellon) — the widely used framework for assessing and improving organizational process capability, in both staged and continuous form. Government and defense contractors commonly require CMMI appraisal as a condition of bidding, which is why its level labels carry commercial weight.
- Goal question metric (GQM) — used in several real process improvement programs, often combined with the SEI capability maturity model. GQM was part of the origin of software process improvement as a discipline.
- CASE tools, analysis and design workbenches, prototyping and testing tools — tool support chosen to match the process classification: heavy process, heavy tooling; light agile process, generic tooling.
- Aerospace versus web development — contrasting process improvement priorities in different industries: verification-driven, regulated processes on one side; customer-facing speed and flexibility on the other.
- Business process re-engineering — the cautionary example of radical change that failed because people were not consulted. Its lesson — make the team stakeholders in the change — is the human-side rule for any process improvement effort.
SE Lecture 13 notes · Software Process Improvement
Sections Breakdown
The meaning and motivation of process improvement: the good-fast-cheap triple constraints as goals, the eight process attributes and their trade-offs, why improvement is project-specific, and the three-stage improvement cycle of measurement, analysis and change.
The core assumption that process quality drives product quality, Deming and statistical quality control, why software is not manufacturing, the four factors affecting product quality, and competitive pressure as the real cause of quality problems.
The four process classes (informal, managed, methodical and supported), their overlap, choosing a process to fit the product, and tool support across the classes.
What process measurement is and is not, the three classes of process metrics (time, resources, event occurrences), and the goal-question-metric approach to choosing what to measure.
What analysis and modeling achieve, starting from the formal process model, the techniques of questionnaires, interviews and ethnographic observation, detailed process models, and process exceptions with dynamic adaptation.
What process change involves, the five stages of change (identification, prioritization, introduction, training, tuning), and the human side of change.
CMMI origins and its two instantiations, the three components (process areas, goals, practices), the six-point capability scale, and the staged versus continuous models.
The improvement journey in one page — the full chain from the triple constraints to CMMI — and where process improvement fits in quality management.
The examinable lists: the improvement cycle, the triple constraints, the eight process attributes, the four quality factors, the four process classes, the three metric classes with GQM, the analysis techniques, the five change stages, and CMMI structure.
Real-world process improvement: Six Sigma and statistical quality control, agile development, CMMI, GQM, CASE tools, aerospace versus web development, and business process re-engineering.
Exam Revision Notes
Below is the distilled, exam-ready core. Every entry comes from the full explanation above. Use this section for rapid review; return to the main notes when a point needs more context.
What Software Process Improvement Means
Must-know: Improvement goals map to the triple constraints good, fast, cheap (increase quality, reduce cost, reduce time); the eight process attributes cannot all be maximized — rapidity trades off against visibility; improvement is project-specific and runs the three-stage cycle measurement, analysis, change.
⚠️ Top pitfall: Believing all eight process attributes can be optimized simultaneously, or that a process model can be copied from another organization.
Self-check: Why does adding visibility to an agile process reduce its rapidity?
Connects to: Process Quality and Product Quality, Process Measurement
Process Quality and Product Quality
Must-know: The process-quality to product-quality link is direct in manufacturing but weaker for software, where design, creativity and people dominate; which factor dominates depends on project size/type — process for large distributed plan-driven projects, people for small agile teams, technology for small projects, cost/time/schedule for all; competitive pressure is the real root of quality problems.
⚠️ Top pitfall: Assuming budget and schedule pressure leaves product quality unchanged — without money or time for testing you ship what you have and quality suffers.
Self-check: Why do star developers not dominate quality in very large multi-team projects?
Connects to: What Software Process Improvement Means, Classification of Software Processes
Classification of Software Processes
Must-know: The four process classes are informal (no strictly defined model, team chooses), managed (defined model drives development), methodical (defined methods + CASE support), and supported (activities automated by CASE tools); classes overlap and the choice is product-driven; generic tools fit informal processes, specialized CASE tools fit methodical ones.
⚠️ Top pitfall: Assuming classification ranks quality (informal = bad) or that a heavyweight managed process suits a short-lived transition program.
Self-check: Can one process be informal, methodical and supported at the same time?
Connects to: What Software Process Improvement Means, Process Quality and Product Quality
Process Measurement
Must-know: Three classes of process metrics: time taken, resources (person-days, travel, computer), and event occurrences (defects found, requirements changes, lines changed per change); the fundamental difficulty is knowing what to measure, solved by GQM: goals refine into questions, questions into metrics.
⚠️ Top pitfall: Claiming a quality improvement from process measures alone — product quality data must be collected and related to the process activities that produced the product.
Self-check: In GQM, what decides whether a proposed metric should be collected?
Connects to: What Software Process Improvement Means, Process Analysis and Modeling, The CMMI Process Improvement Framework
Process Analysis and Modeling
Must-know: Analysis starts from the formal process model (critical activities and lifecycle deliverables) but must look inside it for the real practiced process; techniques are questionnaires, interviews and ethnographic observation; open-ended interviews are preferred because engineers may give the answers they think you want; detailed models record pre-conditions, post-conditions, role, process, inputs and outputs; exceptions (illness, security breach, reorganization, proposal requests) force dynamic adaptation.
⚠️ Top pitfall: Trusting questionnaire answers over observation — engineers may give the answers they think the interviewer wants rather than the truth about the process.
Self-check: Why does the actual process often differ significantly from the formal process model?
Connects to: Process Measurement, Process Change
Process Change
Must-know: Change is the third stage of the cycle; its five stages are improvement identification (bottlenecks), prioritization (cost, impact, need), introduction (integration with existing activities), training (without it people refuse the new process and quality degrades), and tuning (several months of minor fixes); too many simultaneous changes make it impossible to assess each one's effect.
⚠️ Top pitfall: Skipping training or imposing many changes at once — untrained teams refuse the new process and batching changes makes their individual effects unmeasurable.
Self-check: Why did business process re-engineering largely fail, and what is the remedy?
Connects to: What Software Process Improvement Means, Process Measurement, Process Analysis and Modeling
The CMMI Process Improvement Framework
Must-know: CMMI has 24 process areas in four groups; goals are specific (per area) and generic (institutionalization); practices (up to seven per goal) are recommendations — the goal matters more than the way it is achieved; the six-point capability scale runs not performed (0) to optimizing (5); the staged model has five maturity levels whose level-2 process areas include requirements management and supplier agreement management; the continuous model rates each area and produces capability profiles with optional target profiles.
⚠️ Top pitfall: Confusing the staged and continuous scales (five maturity levels for the whole organization versus six capability levels per process area), or claiming a staged maturity level earned out of order.
Self-check: What is the difference between an actual capability profile and a target profile in the continuous model?
Connects to: What Software Process Improvement Means, Process Measurement, Summary
Summary
Must-know: The full improvement chain: triple constraints as goals; process quality driving product quality (weakly for software); four process classes guiding tool choice; three metric classes chosen via GQM; analysis via questionnaires/interviews/observation with exceptions forcing adaptation; five change stages with training essential; CMMI in staged and continuous forms with non-obligatory recommended practices.
⚠️ Top pitfall: Treating process improvement as a one-shot activity instead of a continuous, long-term cycle — measurement, analysis and change repeat as the business environment evolves.
Self-check: Why is process improvement the process-focused half of quality management?
Connects to: What Software Process Improvement Means, Process Quality and Product Quality, Process Measurement, The CMMI Process Improvement Framework
Exam Guidance Summary
Must-know: The examinable lists: cycle stages (measurement, analysis, change); goals (quality, cost, time); eight process attributes; four quality factors per project type; four process classes; three metric classes; GQM; five change stages; CMMI's 24 process areas, goals, practices, six-point scale, staged vs continuous models, level-2 process areas.
⚠️ Top pitfall: Revising facts without the examples — the agile trade-off, person-days metrics, the transition program, and the training stage are the recurring illustrations.
Self-check: Which three classes of process metrics are examinable, and which project types does each quality factor dominate?
Connects to: What Software Process Improvement Means, Process Quality and Product Quality, Process Measurement, The CMMI Process Improvement Framework
Key Industry Applications
Must-know: Industry anchors: Six Sigma (DMAIC, defect-first), agile (rapidity vs visibility), CMMI (staged/continuous), GQM (+SEI CMM), CASE tool matching, aerospace vs web priorities, BPR failure from ignoring people.
⚠️ Top pitfall: Listing frameworks without connecting them to the lecture concepts they instantiate.
Self-check: Which industry practice embodies the rapidity-versus-visibility trade-off?
Connects to: What Software Process Improvement Means, Process Quality and Product Quality, Process Measurement, Process Change, The CMMI Process Improvement Framework
Was this lecture useful?
BitsNotes AI Assistant
Subject Notes AssistantConfigure AI Chat
Choose how to access the chatbotSigned in as
Powered by BitsNotes — 20 messages per day. No API key needed. Want unlimited access? Use "Bring Your Own Key" mode.
Sign in to use AI Chat
Get 20 free AI messages per day to ask questions about your lecture notes. Sign in with Google or GitHub — it takes 5 seconds.
Sign In to BitsNotesSwitch to "Bring Your Own Key" tab above for unlimited access with any OpenAI-compatible provider.