The Software Process Strategy

1. The Software Process Strategy The Software Process Strategy

2. The Software Process Strategy • The software process (SP) is a self-improvement process designed to help you control, manage, and improve the way you work. • It’s a structured framework of forms, guidelines, and procedures for developing software. • Properly used, the SP provides the historical data you need to better make and meet commitments and it makes the routine elements of your job more predictable and more efficient.

3. The Software Process Strategy (Cont.) • As you become more familiar with SP principles, you will begin to understand how to define, measure, and analyze your own process. • This chapter describes some common software engineering problems and the logic for the SP. • The SP’s purpose: the SP is not a magic answer to all your software engineering problems. Although it can suggest where and how you can improve, you must make the improvements yourself.

4. 5.1 The Logic for a Software Engineering Discipline • Software has become a critical issue in modern society. Everyone seems to need more and better software faster and cheaper. • The intuitive software development methods generally used today are acceptable only because there are no alternatives. The current practice is nearer a craft than an engineering discipline. • Most finished software products usually can be made to work, but only after extensive testing and repair.

5. 5.1 The Logic for a Software Engineering Discipline (Cont.) • From a scientific viewpoint, the process is distressingly unacceptable. It is much like the Brownian motion of particles in a gas. • This analogy suggests that large-scale software development should be treated as a problem of crowd control: Don’t worry about what each individual does as long as the crowd behaves predictably. • Software engineers are left to figure out their own working methods and standards without the guidance and support that professionals find essential, for example, in shorts, the arts, or medicine.

6. 5.1 The Logic for a Software Engineering Discipline (Cont.) • This situation becomes critical when each individual’s contribution is uniquely important. A symphony orchestra best illustrates this idea. While the orchestra’s overall performance is a careful blend of many instruments, each musician is highly competent and disciplined contributor. Individual performers occasionally stand out, but the entire orchestra is far more than the sum of these parts, and a single sour note by any individual could damage the entire performance.

7. 5.1 The Logic for a Software Engineering Discipline (Cont.) • Like an orchestral performance, however, the performance of a software system can be damaged by almost any defective part.because computers today possess extraordinary computational power, one badly handled interrupt or pointer could sooner or later cause an entire system to crash. • The software industry has responded to this threat by resorting to increasingly rigorous and time-consuming tests. However, this testing strategy has not been totally effective, as demonstrated by the Thorac disaster that killed two patients or the telephone switching-system failure that shut down large segments of the United States.

8. 5.2 What Is a Software Process • Some organizations have addressed the problem of developing large-scale software systems by adopting the concept, taken from the manufacturing community, of a defined and managed process. • The software process is the sequence of steps required to develop or maintain software. A software process definition is a description of this process. A team that follows consistent process definitions can better coordinate the work of individual members and more precisely track their process.

9. 5.2 What Is a Software Process (Cont.) • The software process sets out the technical and management framework for applying methods, tools, and people to the software task, while the process definition identifies roles and specifies tasks. • The definition further establishes measures and provides exit and entry criteria for every major step. An effectively designed definition helps to ensure that every work item is properly assigned and its status is tracked. • Defined processes are what Deming calls operational definitions: something everyone can communicate about and work toward.

10. 5.2 What Is a Software Process (Cont.) • They provide he following benefits: • They enable effective communication about the process among users, developers, managers, customers, and researchers. • They enhance management’s understanding, provide a precise basis for process automation, and facilitate personal mobility. • They facilitate process reuse. Process development is time consuming and expensive. Few project teams can afford the time or resources to fully define the way they will work. They can save both by using the standard reusable elements a defined process provides. • They support process evolution by providing an effective means for process learning and a solid foundation for process improvement. • They aid process management. Effective management requires clear plans and a precise, quantified way to measure status against them. Defined processes provide such a framework.

11. 5.3 Process Maturity • The processes for large-scale software development can themselves be quite large and complex. Thus they often are hard to define, hard to comprehend, and even harder to introduce. • This is why the software process maturity framework was developed. This framework is an orderly way for organizations to determine the capabilities of their current processes and to establish priorities for improvement.

12. 5.3 Process Maturity (Cont.) • Defining five levels of progressively more-mature process capability: 1. Initial: The software process is characterized as ad hoc and occasionally even chaotic. Few processes are defined, and success depends on individual effort. 2. Repeatable:Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications. 3. Defined: The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization’s standard software process for developing and maintaining software.

13. 5.3 Process Maturity (Cont.) 4. Managed: Detailed measures of software process and product quality are collected. Both the software process and products are quantitatively understood and controlled. 5. Optimizing: Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies. • The Software Engineering Institute (SEI), working with the leading U.S. software organizations, has refined these level definitions and their practices into the Capability Maturity Model (CMM) for Software. At each level, key process areas (KPAs) provide goals and example practices (Fig 5.1). • The CMM is the best available description of the goals, methods, and practices needed for the industrial practice of software engineering.

14. Figure 5.1 The Capability Maturity Model (CMM) Key Process AREAS(KPAs)

15. 5.4 The Software Process Strategy • The SP has a maturity framework much like that of the CMM. Figure 5.2 shows the CMM again, with those KPAs that are at least partially addressed by the SP shown in italics and noted with an asterisk. • Some CMM are excluded for the following reasons: • Software subcontract management and Intergroup coordination: These cannot be practiced at the individual level. • Requirements management and Software configuration management: These can be usefully practiced by individuals but their implications are better demonstrated in a small-team environment.while both are critical, they should be addressed immediately after the initial SP steps. • Software quality assurance and Training program: These relate more directly to broader organizational issues. While the capabilities you learn with the SP are relevant to these areas, useful exercises to demonstrate them at an individual level are difficult or impossible to develop.

16. Figure 5.2 The CMM and the SP

17. Figure 5.3 The SP Evolution

18. PSP0: The Baseline Process • The first step in the SP is to establish a baseline that includes some basic measurements and a reporting format. This baseline provides a consistent basis for measuring progress and a defined foundation on which to improve. • PSP0 is enhanced to PSP0.1 by adding a coding standard, size measurement and the process improvement proposal (PIP). The PIP is a form that provides a structured way to record process problems, experiences and improvement suggestions.

19. PSP1: The Personal Planning Process • PSP1 adds planning steps to PSP0. The initial increment adds a test report and size and resource estimation. In PSP1.1, task and schedule planning are introduced. • You want to make explicit, documented plans for your work for the following reasons: • To help you understand the relation between the size of the programs you develop and the time you take to develop them • To help you to make commitments you can meet • To give you an orderly plan for doing the work • To give you a framework for determining the status of your work • These objectives are critical not only for large projects but also for individuals, even those individuals work alone.

20. PSP2: Personal Quality Management Process • To manage your defects, you must know how many you make. PSP2 adds review techniques to PSP1 to help you find defects early when they are least expensive to fix. You do this by gathering and analyzing the defects found in compile and test for your earlier programs. With these data, you can establish review checklists and make your own process quality assessment. • PSP2.1 establishes design completeness criteria and examines various design verification and consistency techniques.

21. PSP3: A Cyclic Personal Process • The PSP has concentrated on simple linear process for building small programs. A program of 10,000 lines of code (LOC) is too big to write and debug and code review using PSP2. • The strategy is to subdivide a large program into PSP2-size pieces. The first build is a base module or kernel that you enhance in iterative cycles. • In each iteration, you do a complete PSP2, including design, code, compile, and test. Each enhancement builds on the previously completed increments. PSP3 is suitable for programs of up to several thousand LOC (KLOC).

22. PSP3: A Cyclic Personal Process (Cont.) • The cyclic PSP3 process effectively scales up to large programs only as long as each successive increment is high quality. • But if a prior increment has poor quality, testing will be much more complex and the scale-up benefits will be largely lost. This is why design and code reviews are emphasized in the earlier PSP steps. • The test report also is important because with it you can return earlier tests to verify that the new increment did not cause problems with previously working functions. Such problems are called regressions. • Regression testing is a very important part of most large-system development processes.