Page 290 -

Expanding the team is not the only place a formal process is useful. It can also help in an
organization where experts, users, or stakeholders are no longer readily available to the pro-
grammers. This is another area where the formal process can help. It means that require-
ments gathering activities are planned for from the beginning, and that there is a training
program in place to help the users and stakeholders learn to work with the requirements
analysts, ensuring that requirements are gathered at the beginning of the project.

Software Process Improvement

Software process improvement is the art and science of changing an organization’s software
process in order to build better software. In the first part of this book, you learned to diag-
nose and fix problems for individual projects. When you adopt a specific tool for your
project—for example, if you implement inspections on your project team and have them
all follow the script in Chapter 5—you are formalizing part of the software process for that
project by having the team follow a written description of that activity. Software process
improvement is very similar, except that instead of improving one project at a time, you
work on improving the entire organization.

The tools and techniques in the first part of this book make up many of the nuts and bolts
of software process improvement. But while this book so far has been about making spe-
cific improvements to the way software is built on the scale of an individual project, there
is another perspective: the high-level organizational perspective. It’s very important to
diagnose chronic problems your organization is having and address them with specific
practices to be adopted for all projects. By stepping back and looking at the software pro-
cess as a whole, you may be able to plan ahead and anticipate the inefficiencies in the way
your team develops software. In doing so, you can avoid problems before they have seri-
ous impact on your organization. That is where software process improvement can really
help your team excel.

Software process improvement always involves looking at the big picture. This generally
means writing down the entire software process as a whole and making sure that it is fol-
lowed on each project. It involves not just diagnosing specific problems and attacking them
individually, but also looking at entire projects and identifying areas that can be improved.

Software process improvement differs from the approach described in the first part of this
book. In Part I, you learned how to diagnose individual problems on your projects and use
specific tools, techniques, and practices to fix those problems. In much the same way, soft-
ware process improvement can be evolutionary, allowing you to use iterative cycles to fix
individual parts of your organization’s lifecycle. But software process improvement differs
from the diagnose-and-fix approach, because it requires that you change the culture of
your organization to one of continuous process improvement. Software process improve-
ment requires patient and consistent support (in both actions and resources) from your
senior managers, in order to be effective. It also requires a broad consensus among the
software engineers. If you can gather this kind of support behind a process improvement
effort, you can address issues that are beyond the scope of individual projects and dramat-
ically increase the capability of your software organization.

282 CHAPTER TWELVE