Section 12.2. Software Process Improvement


12.2. 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 diagnose and fix problems for individual projects. When you adopt a specific tool for your projectfor example, if you implement inspections on your project team and have them all follow the script in Chapter 5you 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 specific 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 process 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 serious 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 followed 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, software 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 improvement 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 dramatically increase the capability of your software organization.

There are specific process improvement tools to help you do this. There are models and certifications that help you assess the state of your organization's process, and that serve as a framework for improving that process. There are also processes and methodologies you can adopt that describe the complete set of activities, roles, and work products needed to build software. By applying these tools, you can give your organization the ability to fix problems before they get serious enough to cause your projects to slow down.

12.2.1. Models and Certifications

To many experts, software process improvement in practice means using a model or certification standard as a guideline for assessing and improving a software organization. Some of the most common models are the Capability Maturity Model, ISO 9000, and Six Sigma. These are not processes in and of themselves. Rather, they are systematic frameworks that were developed for evaluating any software organization (no matter what process is in use), identifying improvements that will increase the ability of the organization to build better software, and certifying that the organization has met an objective standard for capability.

12.2.1.1. The Capability Maturity Model

The Capability Maturity Model (CMM), is a process improvement method developed by the Software Engineering Institute at Carnegie Mellon University. It provides a set of best practices meant to address important aspects of software development: productivity, performance, costs, predictability, and stakeholder satisfaction. The purpose of the CMM is to define the characteristics of a mature, capable process in a way that can be measured and compared to processes at other organizations.

The CMM was developed in coordination with the U.S. Department of Defense (DoD) to help organizations privately improve their own processes. (It was also adopted by the DoD as a way to provide the U.S. military with a consistent method to identify the most capable software contractors. While this has been successful, it has also led to some abuses of the assessment systemsee below.) The result was a model (first published in August 1991) that contained five maturity levels, ranging from "Initial" (in which an organization does not apply tools, techniques, and practices consistently across all of its projects) to "Optimizing" (in which a software process was well defined, brought under statistical control using various metrics and measurements, and continually improved based on those metrics).

By the late 1990s, the government and the CMM user community had a great deal of feedback for the SEI team responsible for maintaining the CMM. In response, a project to create the Capability Maturity Model Integration (CMMI) was initiated in order to address these concerns. This new version was released in 2002.

Both the CMM and CMMI are divided into key process areas (KPAs) that define specific goals and practices. Each KPA addresses a specific area of software engineering. There are several dozen KPAs, including requirements management, project planning, project monitoring, configuration management, and training. (These areas of improvement should seem familiar by now!)

Each of the five maturity levels of the CMM is represented by its own set of KPAs; for an organization to achieve a specific maturity level, it must implement all of the practices in each of the KPAs for that level. The CMMI also contains five maturity levels; however, some of the focus of the CMMI has been drawn away from maturity levels in favor of implementing specific practices and goals. It does, however, still support a level-based assessment.

The most important part of each KPA is a set of one or more goals that define the "heart and soul" of each KPA. For example, the Project Planning KPA of CMMI v1.1 contains three goals:


Establish Estimates

Estimates of project planning parameters are established and maintained.


Develop a Project Plan

A project plan is established and maintained as the basis for managing the project.


Obtain Commitment to the Plan

Commitments to the project plan are established and maintained.

These are sensible goals that, if met, will lead to a well-planned project; if any of these goals is not met, then the project will have a clear planning problem. The remainder of the KPA lists specific practices that should be performed, in order to meet those goals. For example, the "Establish Estimates" goal is met with specific practices:


Estimate the Scope of the Project

Establish a top-level work breakdown structure (WBS) to estimate the scope of the project.


Establish Estimates of Work Product and Task Attributes

Establish and maintain estimates of the attributes of the work products and tasks.


Define Project Life Cycle

Define the project life cycle phases upon which to scope the planning effort.

Each practice is further defined with subpractices. For example, the "Estimate the Scope of the Project" practice requires that a WBS is developed, work packages are defined in sufficient detail to provide estimates, and work products are identified that will be acquired externally or reused. Again, these are all sensible activities that need to be performed in order to estimate the scope of a project.

Within each practice and subpractice is additional information providing advice and tips for implementation. There are usually lists of typical work productsfor example, the subpractice for estimating the scope of a project lists the task descriptions and WBS as work products. However, these are just suggestions. The most important part of the CMM and CMMI is meeting the goals, and the practices are simply an efficient way of meeting those goals.

When an organization begins a process improvement effort based on the CMM or CMMI, a good first step is to set up a software engineering process group (SEPG). This is a team of software engineering professionals and/or managers within the organization who are dedicated either part- or full-time to improving the software process. They identify problems and inefficiencies, define the practices needed to address those problems, and implement them in the project teams.

Another important part of the CMM and CMMI is the assessment process. In an assessment, an assessor is brought into the organization. He spends time (typically one week) reviewing the process documentation, interviewing the people on the team, and verifying whether the process is actually carried out on real projects. The result of the assessment is a report that identifies which practices are in place, which practices are missing from key process areas, and the maturity level of the organization.

Assessments are a useful tool that SEPGs can use to identify areas for improvement. However, there is a downside to assessments. There are many organizations that must comply with the CMM or CMMI in order to qualify for certain government programs or to bid on contracts that require a minimum maturity level. Other organizations pursue a maturity level for publicity or public relations purposes. The assessment process assumes that the organization being assessed is honestly representing its practices. A software organization that is intent on getting assessed at a certain level can create reports and work products that will make it appear as if all of the practices have been implemented. This is just like a company that fools an accounting auditor by keeping two sets of booksit may pass the audit through no fault of the auditor.

When the CMM or CMMI is abused, it is no longer an effective way to improve an organization. The practices that are part of the KPAs then simply amount to pushing paper around. Documents that could be useful have simply become bureaucratic forms to be filled out. A project plan is created not to help the team understand and plan the work, but simply to satisfy an organizational policy. When this happens, the team members still face the same problems they have always faced: increasing delays, decreasing quality, overtime, dissatisfaction, and poor software development practices. But now they also get to fill out a bunch of paperwork.

Despite this potential abuse, when the CMM or CMMI is used well, it can be a powerful tool for actually improving the software process and capability of an organization. It contains a wealth of good practices, as well as advice for implementing those practices. When an organization really works toward understanding and fulfilling the goals and implementing the practices, they stand a good chance at truly building better software.


Note: The Capability Maturity Model and a great deal of supporting information can be obtained for free from the Software Engineering Institute web site at http://www.sei.cmu.edu/cmmi/cmmi.html.
12.2.1.2. ISO 9000

ISO 9000 is a family of quality management standards defined by the International Standards Organization and implemented by over half a million organizations around the world. Quality management refers to the practices performed by an organization in order to fulfill the customer's requirements (and any legal or regulatory requirements). The goal of quality management is to improve customer satisfaction, while at the same time continually improving the performance of the organization.

Every ISO 9000 standard defines a set of minimum "pass or fail" standards that are used to judge whether an organization is in compliance. ISO standards, like the CMM, have a certification process in which an organization's practices are assessed by a third-party assessor who audits the organization's compliance with the quality system, and whether that system is effective. The result of the audit is a set of recommendations for changes to be made, in order to bring the organization into compliance.

ISO 9000 is based on eight core principles:

  • Organizations must focus on their customers by understanding current and future customer needs.

  • Leaders within the organization must create and maintain an environment in which people can become involved and fulfill the organization's objectives.

  • People at all levels are important to the organization.

  • Activities and resources are best managed as a process.

  • Organizations have many interrelated processes, which must be understood and managed as a system.

  • The organization should continually improve its performance.

  • Decisions should be well informed and based on real data and information.

  • An organization and its suppliers are in a mutually beneficial relationship.

The ISO 9000-3 standard contains a set of guidelines that interprets ISO 9000 so that it can be applied to the development, supply, and maintenance of software. It is divided into sections that define standards for many areas of a software organization, including management practices, the quality system, contracts, document and data control, inspection, training, deployment, process control, and the design and development of the software.

Each of the sections contains standards for the day-to-day work that goes on in the organization. For example, within the software development and design section are standards for software development, software design, design and development planning, organizational and technical interfaces and design review, verification, validation, and change control.

Each of these standards defines specific practices that must be implemented in the organization. For example, the software development requirements require that a project plan be developed. This plan must define the project, list its objectives, contain a project schedule, define the inputs and outputs, identify related plans and projects, identify project risks, and identify assumptions. These requirements should seem familiar: they are all part of the project plan in Chapter 2.

Like the CMM, the ISO standards can be abused by an organization and reduced to bureaucracy and paper pushing. There is a great deal of pressure on many organizations to achieve an ISO 9000 certification at any cost, since they may be ineligible for certain contracts without it. However, when the standards are used properly, they can provide good guidelines to a project manager looking to improve how her organization builds software.


Note: Information on ISO 9000 can be found at the International Standards Organization web site. The URL at the time of this writing is http://www.iso.ch/iso/en/iso9000-14000/iso9000/iso9000index.html
12.2.1.3. Six Sigma

Six Sigma is an approach to improving quality in manufacturing and business processes. It was developed at Motorola in the early 1980s, and it has been used successfully at many software organizations. The goal of Six Sigma is to produce a product of consistent quality by statistically measuring the defect rate, improving the processes to eliminate those defects, and then monitoring the improvements. Six Sigma has been used to successfully improve organizations in many industries. While it has a reputation for success in large companies with thousands of employees, Six Sigma can be applied to small project teams as well.

The Greek letter sigma refers to standard deviationSix Sigma means "six standard deviations from the mean." To achieve this level of quality in a manufacturing process, 99.9997% of all products must be of acceptable quality (or 3.4 defects per million opportunities). It's not hard to get an intuitive grasp on what this means in the real world. According to Jeannine Siviy at the Software Engineering Institute, a Four Sigma level of qualitymeaning that we're 99.9% surewould yield:

  • 9 hours of unsafe drinking water a year

  • 107 incorrect medical procedures a day

  • 200,000 incorrect drug prescriptions a year

  • 18,322 pieces of mishandled mail an hour

  • 2,000,000 documents lost by the IRS a year

  • Two short or long landings at any major airport a day

Variance is an important part of Six Sigma. There is a saying at General Electric, an early adopter and innovator in the Six Sigma world: "Our Customers Feel the Variance, Not the Mean." All processes have some inherent variability. No process, especially not a software process, produces defects at an entirely regular rate. What GE found is that customers can get used to a "noise level" of defects; it's the large changes in quality that will really get their attention. This is where Six Sigma is especially useful. It is the statistical variances that will take a product from one standard deviation into another; the process problems that cause these variances are the ones most likely to be identified and fixed.

The goal of Six Sigma is to think of every aspect of the business as a process that can be improved in a way that can be measured statistically. The main tool for doing this is a five-phase approach called DMAIC (see Table 12-1).

Table 12-1. DMAIC: A five-phase approach to Six Sigma

Phase

Description

D efine opportunities

Determine customer and core processes . Determine the customer's requirements for the products and services being produced. Map the processes that are being improved. Gain the customer's commitment.

M easure performance

Develop a plan to collect and measure the defect data. Collect data from many sources in the organization and determine the defect rates and other metrics. Compile and display the data.

A nalyze opportunity

Analyze and verify the data collected. Determine the root causes for the defects and identify opportunities for improvement. Prioritize the improvement opportunities.

I mprove performance

Design creative solutions to improve the processes. Create a problem statement and a solution statement for each problem. Test specific improvements with an experimental approach. Deploy the improvements.

C ontrol performance

Monitor the improvement programs to control them. Develop an ongoing monitoring plan to keep the process on the new course and prevent it from reverting to its previous state. Assess the effectiveness of the improvement. Develop staffing and training incentives to make the improvements permanent.


Six Sigma professionals have a training and certification program called the Black Belt program. The Certified Six Sigma Black Belt is a professional trained to implement Six Sigma in an organization and train others in the Six Sigma principles, systems, and tools. They have a thorough understanding of the DMAIC model and fundamental knowledge of project management.


Note: More information on Six Sigma can be found at the iSixSigma web site (http://www.isixsigma.com) and the Motorola University web site (http://www.motorola.com/motorolauniversity).

12.2.2. Processes and Methodologies

There are also complete processes that can be adopted by an organization. Unlike models and certifications, these methodologies define the activities to be performed and the roles that people in the organization must fill in their daily work. In many cases, they incorporate many project management practices similar to the ones in this book. But unlike the diagnose-and-fix approach, a methodology provides a complete process that can be adopted all at once by an organization.

Adopting an "off-the-shelf" process or methodology is fundamentally different from using a model or framework for process improvement. Instead of improving the existing software lifecycle, you adopt an entire process that's "tried and true." Unlike the diagnose-and-fix approach, adopting a specific process requires revolutionary, rather than evolutionary or incremental, changes. It is usually much harder to convince people to adopt an entire new process rather than one specific tool or technique. It also requires determined management support to gain acceptance, because it requires a complete change to the entire lifecycle.

12.2.2.1. Extreme Programming

Extreme Programming (or XP) was developed in the 1990s by Kent Beck when he was working on a project at Chrysler (although its roots stretch back to SmallTalk projects that he and Ward Cunningham worked on at Tektronix in the mid-1980s). It represents one of the fastest growing movements in the software world today, and many of the techniques in this book will seem familiar to people who have worked in an XP environment.

XP consists of a set of rules and practices that govern all areas of software development: planning, designing, coding, and testing. These practices emphasize interaction and collaboration between the engineering team and the stakeholders and users, as well as the ability to respond quickly to changes in order to produce working software. The goal of XP is to lower the cost of change. Uncontrolled changes are the most common cause of software project failure (see Chapter 6); by putting basic XP principles and practices in place, a project team can control the changes.

The specific planning practices employed by XP are intended to be as lightweight and agile as possible, and have a high level of user involvement. XP projects are planned in short iterations using the Planning Game (see Chapter 3) in order to make frequent small releases. The requirements are documented as user stories, which are written by the users. Each user story is a brief, three-sentence description of a specific behavior that must be performed by the software. It is much less detailed than a use case or a requirement, and should only contain enough information to allow a developer to create a basic 1, 2, or 3-week estimate. Once 80 or so user stories are created, a release plan is built by the developers; they divide the project into 1- to 3-week iterations. An iteration plan is developed when each iteration begins. Project velocity is a metric that gauges how much work is getting done on the project by comparing the sum of the estimates for the user stories planned in the current iteration with the estimates for the tasks actually performed (similar to variance, in Chapter 4).

The main principle behind XP design is simplicity: a simple design is always more efficient to build than a complex one. Classes and methods should be named consistently; a metaphor should be used to help guide developers in creating consistent names. Functionality should never be added before it is scheduled. The developers should "refactor mercilessly"that is, they should refactor the design and code whenever possible (see Chapter 7).

XP coding employs some familiar practices: test-driven development (see Chapter 7) and pair programming (see Chapter 5). In addition, one important principle in XP coding is that the customer must always be available to the developers. This allows them to get constant feedback and clarifications. Users and stakeholders are an active part of the development team, and the developers have face-to-face communication with them throughout the course of the project. In addition to the user stories, they are responsible for negotiating which user stories are included in each release, giving feedback on the results of each iteration and, most importantly, filling in the details that are missing from the user stories.

Testing in XP consists of unit tests and acceptance tests. All code must have unit tests, and all unit tests must pass before the code can be released. When a bug is found in production, an additional unit test must be written to guard against it in the future. When software is delivered, the customer is responsible for running acceptance tests to verify that the user stories are all implemented properly. The customer is responsible for verifying that the acceptance tests are correctmeaning that the unit tests truly verify that the work has been doneand for reviewing the results of the acceptance tests to determine whether the software is ready for release.

Many programmers have turned their struggling development teams around using XP. One of its biggest advantages is that it does not require widespread organizational change, which means that it can be implemented by a small group of programmers without getting managers involved. For a team that does not have any project planning or requirements gathering, working in an XP environment will be an enormous relief. XP is an effective way to promote good social and organizational change by putting good development and project management practices in place. It's no wonder that there are a growing number of professionals who have come to depend on XP for all of their work.

One common misunderstanding is that XP is not a disciplined or well-defined process, and that XP and the CMM and ISO 9000 are all somehow mutually exclusive. In fact, XP projects follow a very specific set of rules and practices. It is possible for a good team that has fully implemented XP to pass a CMM or ISO 9000 assessment.

On reason XP is effective is that it addresses one of the most common problems in software development: the hands-off customer. Just as a hands-off client can cause serious problems in an outsourced project (see Chapter 11), serious project problems can happen when a stakeholder does not act as if he has a real stake in the software. It is very easy for a software project to go off track, and it needs constant direction to keep the scope of the project current with the organization's needs. XP provides an effective solution to this problem by making the stakeholders a part of the development team and requiring them to be involved in the day-to-day work of the project.

There are, however, some important drawbacks to XP. It is not clear that XP can be extended to large teams. Some experts feel that XP is difficult to implement with teams that are larger than about 12 people. (There is some research in this area, and a few researchers have reported success on large teams using a modified version of XP.) Another drawback is that it only works on software projects that can be delivered incrementally, or do not have human users. The original C3 project at Chrysler was a payroll system; it's not clear that XP would work for a different team at Chrysler developing a fuel injection system or anti-lock brake system.

But the most important drawback to XP is that the customer must always be available. There are many environments in which this is a very difficult requirement to meet. The users and stakeholders in most organizations have their own jobs to do, and it would be unreasonable to require that they devote all of their working time to a software project. Requirements elicitation (see Chapter 6) requires specialized skills and people, which often makes it difficult to implement in small organizations, but it is much less demanding of the time of people outside of the engineering team. And once the requirements are written, they can be reviewed for defects. While it's generally not possible to catch every defect before the programming begins, it is possible to find many of themand it is much faster to fix defects on paper than it is to fix them in software, especially when they are not caught until late in the project.

XP proponents often say that face-to-face communication is superior to written communication, and that XP's reliance on face-to-face meetings and very little documentation frees the process from the "bureaucracy" of requirements documentation. However, reliance on face-to-face communication for detailed requirements introduces its own problems. Defining the behavior of software is a particularly complex and error-prone process. It is very easy for people to reach misunderstandings when talking about software behavior. This is especially risky when a customer has been involved as a project team member since the beginning of the project. The customer's expectations will often evolve along with the project, as a side effect of the influence of the rest of the programming team. The result is that the customer is more likely to accept the software, even if it does not fully meet the needs of the people in the customer's organization who were not on the project team. This sort of tunnel vision is much easier to avoid when the customer keeps his eye on his task and his organization's needs rather than on the details of the project and the developers.

Drawbacks aside, for projects in which the circumstances and team are compatible with XP, it is a very powerful tool. Many project teams across the world have made a huge difference in their projects by adopting some or all of the XP practices.


Note: Additional information about Extreme Programming can be found in Extreme Programming Explained: Embrace Change(2nd Edition) by Kent Beck (Addison Wesley, 2004).
12.2.2.2. Rational Unified Process

There are many complete software processes that are available and ready to be adopted out of the box. Typically, such a process will include a complete set of activities to be performed over the course of the entire software project. These activities usually include scope definition, requirements engineering, architecture, design, programming, and testing activities. One of the most popular off-the-shelf processes is the Rational Unified Process (RUP).

The activities of RUP are based around the idea of highly iterative development. After an initial planning phase, the software project enters a cycle of iterations, each of which results in an executable release. Each of the iterations contains distinct activities for planning, requirements specification, analysis and design, implementation, testing, and stakeholder evaluation. The advantage of iteration is that it allows the project team to identify and correct misunderstandings early on in the project, keep the stakeholders up-to-date with deliverables to help them gauge the progress of the project, and distribute the project's workload more evenly over the course of the project.

RUP includes a disciplined approach to requirements management that is based on the idea of managing changes. The requirements in RUP are similar to those in Chapter 6. They include use cases as well as functional and nonfunctional requirements. RUP incorporates software design using the Unified Modeling Language (UML), a visual modeling system for graphically representing the use cases, class model, object interactions, and components of the software.

One core element of RUP is the continuous assessment of the quality of the system. The testing activities involve creating test cases based on the functionality introduced in each iteration. By incorporating testing activities in each iteration, RUP allows the team to identify defects early, and to continuously assess the health of the product. RUP also has a clear change control system to ensure that every change is evaluated; measurements of the rate of software changes are used to assess the status of the project.

One thing that makes RUP unique is that it is a product in addition to a process. RUP is available from Rational Software, a subsidiary of IBM. An organization licenses RUP from Rational Software, which keeps the software up to date and provides regular updates to the process and its documentation.

There are many software packages that go along with RUP. Requirements and use cases are stored, managed, traced, and edited using the RequisitePro software. Rational Rose, a UML editing tool, is used to capture and visually model the software architecture. Other products are used for configuration management (ClearCase), change request management (ClearQuest), test case management (TestManager), performance testing (PerformanceStudio), test automation (Rational Robot), and tools to support other areas of the software process. Each of these products is also available separately, and RUP can be implemented without these tools. Many organizations license RUP as a complete process engineering suite. RUP was also built to be adaptable to the needs of individual organizations; Rational Process Workbench is a tool for customizing and extending RUP to meet your organization's needs.

The support tools in RUP are a strong feature. However, they also present a significant pitfall. Some project managers feel that they can simply buy their way out of a software process problem by buying RUP and distributing it to the team. But while some problems can be solved by adopting a process like RUP out of the box, many project management problems cannot be solved by writing a check. This is why it is often easier to adopt small, piecemeal changes like adopting individual practices, tools, and techniques than it is to force an entire organization to adopt a complete software process immediately. However, if that problem can be overcome, then an out-of-the-box process such as RUP can be a powerful tool for building better software.


Note: More information on RUP can be found in The Rational Unified Process: An Introduction by Philippe Kruchten (Addison Wesley, 2000).


Applied Software Project Management
Applied Software Project Management
ISBN: 0596009488
EAN: 2147483647
Year: 2003
Pages: 122

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net