Chapter 8. Process Improvement Planning
Make no little plans; they have no magic to stir men's blood and probably themselves will not be realized. Make big plans; aim high in hope and work, remembering that a noble, logical diagram once recorded will never die, but long after we are gone will be a living thing, asserting itself with ever-growing insistence. Remember that our sons and grandsons are going to do things that would stagger us. Let your watchword be order and your beacon beauty.
—Attributed to Daniel H. Burnham [(1846–1912), American architect and city planner.] While Burnham expressed these thoughts in a paper he read before the Town Planning
Conference,
8.1 Introduction
The purpose of this chapter is to give you guidance for writing an SEE implementation plan. Armed with this guidance, you can establish the framework for applying to your organization the things discussed in the preceding chapters. Our approach is to present and discuss key SEE implementation issues. The aim of this discussion is to provide you with insight into how to lay out an SEE implementation approach that makes sense for your organization. For example, we discuss the rate at which ADPE elements should be developed and implemented. We describe some of the key factors bearing upon this rate (e.g., the software and system engineering experience level of your organization's management and staff). These factors should help you plan an ADPE development and implementation rate appropriate for your organization.
Before we address process improvement planning issues, we set context. Figure 8-1 reminds us that, as we repeatedly stressed in the preceding chapters, consistent successful software systems development requires sustained effective communication between the software seller and the software customer. Reduced to the simplest terms, the concepts and principles examined in these chapters have their roots in this premise. We now recall some of these concepts and principles through an overview of the preceding chapters. To aid you in this recall, Figure 8-2 highlights the theme of each of these chapters.
Figure 8-1 At the most fundamental level, the avenue to consistent successful software systems development is sustained effective communication between the wizard (i.e., software seller) and the king (i.e., software customer). (The Wizard of Id, September 30, 1983. Reprinted by permission of Johnny Hart and Creators Syndicate, Inc.)
Figure 8-2 The preceding chapters capture the essence of things that you need to consider in planning for implementing a systems engineering environment (SEE) in your organization. SEE implementation is a structured way of institutionalizing consistent successful software systems development. This chapter integrates the ideas from the preceding chapters to guide your SEE implementation planning activity.
• Chapter 1 (Business Case) explored why it makes good business sense for an organization to take the time to alter its way of doing software development to achieve consistency. This chapter also introduced key concepts to establish a working vocabulary for the rest of the book (e.g., software, software process, product and process "goodness," culture). We emphasized that customer/seller faulty communication underlies a majority of software systems development problems. We stressed that software process improvement is first and foremost a cultural change exercise. We introduced the requisite software systems development disciplines— management, development, and product assurance. We introduced the change control board (CCB) as a mechanism for sustaining effective communication among these disciplines throughout a software systems development project. We introduced the notion of "prescriptive application" of an organization's documented software systems development process. We explained why prescriptive application is one of the keys to institutionalizing the process. The SEE also provides the means for effecting improvement to the software development process. Consistent successful software systems development and software process improvement are thus intertwined in the SEE concept.
• Chapter 2 (Project Planning Process) provided you with guidance for effectively planning software systems development work. We referred to the document containing planning information as the "project plan." We indicated that the project plan is a gauge used, in part, to think through what needs to be done, to estimate how much the effort may cost, and to determine whether software systems development work is unfolding as it was envisioned. We stressed that project planning is an ongoing negotiation between the customer (king) and the seller (wizard). We showed you how to plug the CCB apparatus into your project plan so that the wizard and king could effectively interact throughout the project. We showed you how the life cycle concept can be used to drive out specific tasks to be performed. We illustrated this fundamental point with three example life cycles—(1) six-stage classical development, (2) prototype development, and (3) (data-centered) information engineering. We showed you how to design a simple risk assessment approach for allocating resources to the three sets of requisite software systems development disciplines—management, development, and product assurance—thereby showing how you can explicitly incorporate risk reduction into your project budget. Most importantly, we showed you how to plan for change. We organized this project planning guidance into an easy-to-use package by showing you how to develop an ADPE element defining your organization's project planning process.
• Chapter 3 (Software Systems Development Process) established the focus for the remainder of the book. We defined principles for defining a software systems development process. We explained that a process constructed by applying these principles is likely to yield consistently "good" products—i.e., products you’re your customer wants and that are delivered on time and within budget. To help you apply these principles, we illustrated them by defining a top-level process that you can use as a starting point to formulate a process for your own organization. We again stressed the critical importance of maintaining the wizard and king dialogue by making the CCB a key element of the top-level process. We emphasized that, in general, the process cannot be reduced to a rigidly defined procedure with a definite order to the steps to be followed. Rather, we stressed that prescriptive application of the process was key to achieving consistent software systems development. That is, the process should specify what is to be done; individuals should be empowered to figure out how to do the what. We showed you how to plug a specific life cycle into the top-level process to explain how a project unfolds during process application. We showed you how to design a form to help you track a product as it wends its way through your software systems development process. We explained that the process does not stop once the product goes out the seller's door. Rather, we discussed the customer and seller responsibilities after the seller has delivered the product to the customer. We folded the chapter's process definition ideas into an easy-to-use package—namely, an annotated outline for an ADPE element defining your organization's software systems development process. We explained why this element is a good place to begin setting up your ADPE.
• Chapter 4 (Change Control Process) focused on the change control board (CCB) as a forum for sustaining effective communication between the wizard and king as well as among the wizard's staff. We provided you with guidance for setting up CCBs for your software systems development process. We also provided guidance for managing unplanned, as well as planned, change. We thereby closed the loop introduced in Chapter 2 where we emphasized that you need to account for the unknown in your project plan as well as accounting for the known. Chapter 4 also closed the loop introduced in Chapter 3, which stressed that, by integrating the customer/seller CCB into your software systems development process, you make product acceptance by the customer almost a foregone conclusion. We showed you how to do this integration by stepping through change control mechanics for both planned and unplanned changes. We explained the CCB role in traversing a project life cycle. We introduced the following three scenarios, each regulated by a CCB, that we asserted govern all of change control:
o Do we want something new or different?
o Is something wrong?
o Should we baseline the product?
We showed you what to record at CCB meetings and gave examples of CBB minutes. We offered you guidance for choosing a CCB chairperson and a CCB voting mechanism. We offered you guidance for determining when CCB hierarchies are appropriate and how to set them up. We gave you detailed guidance for constructing change control forms to support the preceding change control scenarios. We also gave example forms to help you get started in applying this guidance. We organized the CCB concepts and guidance into an easy-to-use package by showing you how to develop an ADPE element defining your organization's change control boards.
• Chapter 5 (Product and Process Reviews) focused on the product and process reviews needed to give visibility into what is happening on a software project. To establish context for the chapter, we asserted the following:
o Each software project should be approached with the candid realization that it is a voyage through iceberg-infested waters (or worse!).
o If this attitude is adopted, then common sense and the natural instinct for self preservation can lead to only one conclusion—that some way must be found to steer clear of the icebergs to the extent prudently possible.
o Product and process reviews are techniques for steering clear of the icebergs.
We defined a two-dimensional review taxonomy that consists of the following product and process reviews:
o Management Reviews
Product and Process Programmatic Tracking
Product and Process Technical Oversight
o Development Reviews
Product and Process Peer Reviews
Technical Editing of Software and Software-Related Documents
o Product Assurance Reviews
Product Quality Assurance, Verification and Validation, Test and Evaluation, and Self-Comparison
Process Quality Assurance at the Product Level and at the Project Level
The product reviews identified were, for the most part, those called out in Chapter 3 when we defined a top-level software systems development process. The process reviews identified were extensions to the product reviews. For example, for management, we called out two types of reviews—programmatic tracking and technical oversight—for both a specific product and the software systems development process.
We organized the chapter along the lines of the systems disciplines. Because we believe that application of the product assurance disciplines offers the greatest potential for reducing risk on a software project, the chapter devoted considerable attention to the product assurance product reviews. In particular, the chapter stepped through the mechanics of product assurance document reviews and acceptance testing. In this book, acceptance testing constitutes that activity in the software systems development process where the wizard formally demonstrates to the king that the software system and supporting databases do what they are supposed to do. Acceptance testing is therefore the bottom line of the software systems development process. For this reason, the chapter includes a detailed discussion of requirements testability with a worked out example.
For reviews not addressed (e.g., unit and integration testing), the chapter offered suggestions for extending the taxonomy to include such reviews. To help you apply the review guidance presented in the chapter, we showed you how to develop an ADPE element for product assurance reviews. We showed you how to integrate other product and process reviews into this element. Because peer reviews are generally recognized as adding significant value to the software systems development process, we showed you how to develop a peer review ADPE element.
• Chapter 6 (Measurement) provided you with guidance for measuring product and process "goodness." Borrowing from the mathematical discipline of vector analysis, we quantified "goodness" as the length of a vector in a space that we labeled "integrity." The dimensions in this space are the product or process attributes that we are interested in measuring. For example, for a product we might want to measure the extent to which customer requirements are satisfied and/or whether delivery was on time and/or delivery was within budget. For a process, we might want to measure, for example, whether peer reviews were conducted and/or whether product assurance reviews were performed and/or whether risk assessment was performed during project planning. We illustrated how to set up value scales for the attributes and gave you guidance for establishing value scales that make sense for your organization. We illustrated how to measure the integrity of a requirements specification, a user's manual, computer code, and a project plan. We illustrated how to measure the integrity of the process introduced in Chapter 3. To help you apply the chapter's integrity measurement approach, we reduce it to a small number of easy-to-follow steps. These steps also show you how to relate process integrity and product integrity measurements to one another to help you focus your process improvement efforts.
The product/process integrity measurement approach presented is actually a very general approach to quantifying almost any object. We thus call this approach "object measurement," or OM®. To hint at its general applicability, we applied OM to the Software Engineering Institute's Capability Maturity Model for Software (CMM® for Software) to show how the model's key process areas (KPAs) could be quantified. We also showed how
In addition to product integrity and process integrity measurements, we showed how to establish other process-related measurements tied to one or more components of the software systems development process. The approach was based on taking simple averages involving the number of times a particular activity or set of activities was performed on various projects within an organization. For example, we defined the following measurements that might be useful for an organization to collect for the purpose of assessing process effectiveness:
o Average number of peer reviews required to produce deliverables that are accepted by the customer (i.e., the customer returns the Acceptance of Deliverable form indicating "the product is accepted as delivered").
o Percentage of deliverables delivered on time to the customer during a specific period for certain projects, where "on time" is according to delivery dates specified in project plans or CCB minutes.
o Average number of drafts required to produce a project plan resulting in a project.
o Customer perception of the seller organization.
We organized the chapter's measurement guidance into an easy-to-use package by showing you how to develop an ADPE element defining your organization's product and process metrics and your organization's approach to applying them to improve your software(-related) products and software development process.
• Chapter 7 (Cultural Change) focused on the human, as opposed to engineering, issues bearing on successful software systems development. The chapter proceeds from the following premise, which is grounded in experience:
Getting a process on paper is a challenge, but getting the people in the organization to commit to the change is the challenge. People commit to change for their own reasons, not for someone else's reasons. Therefore, when people are asked to commit to change, their first concern may be their perceived losses.
We stressed that SEE implementation is first and foremost a cultural change exercise—an exercise in behavior modification. As we explain in the current chapter, this consideration bears heavily on developing a realistic SEE implementation plan. Successful software implementation is predominantly a people management exercise and not an engineering management exercise Most of us do what we do (whether it is developing software systems or brushing our teeth) because we feel most comfortable doing things our way. It should therefore not be a surprise that persuading people in the software systems development world to do things someone else's way (i.e., the organization's way) can be a daunting challenge—fraught with surprises.
We examined the role in bringing about cultural change of the organization responsible for writing the ADPE elements (i.e., the process engineering group [PEG]) and seeing to it that they are implemented and continually improved. We alerted you to considerations bearing upon PEG member qualifications (e.g., hands-on experience developing software systems).
We discussed how to deal with ADPE implementation challenges arising from the wizard's project-level individuals who will have to adapt to practices set forth in the ADPE elements that govern their work. On the customer side, we discussed how to deal with ADPE implementation challenges arising from those kings who give technical direction to wizard project managers. In this vein, we discussed how to get the customer to be part of ADPE implementation. We also discussed the pros and cons of getting the customer to be accountable for ADPE implementation, as well as the seller.
We examined the key role that seller senior management plays in effecting software systems development cultural change through ADPE implementation. On the other side, we examined the impact on customer senior management that ADPE implementation brings about.
We provided you with guidance for extracting key ideas from ADPE elements and packaging them for distribution to your organization as a means for effecting cultural change (e.g., the use of prominently displayed foam boards showing key process concepts such as requirements based acceptance testing).
We discussed the role of training in effecting cultural change. In particular, we stressed the key role that ADPE element briefings to wizard and king staff plays in getting the organization to assimilate desired engineering behavior. Allied with the role of training in bringing about cultural change, we examined the role of mentoring and coaching. We discussed how to sell ADPE implementation as a career growth opportunity.
We looked at organizational factors bearing upon how long it takes to bring about cultural change.
We examined why an ADPE element defining the ADPE element development and improvement process is intimately tied to organizational cultural change.
We concluded the chapter by giving you an annotated outline for an ADPE element defining the ADPE element development and improvement process. This element provides the framework for evolving the ADPE in a self-consistent manner.
Where do you go from here? How do you put together the concepts and guidance from the preceding chapters to lay out an approach for consistent successful software systems development or to improve what you already have? As Figure 8-3 indicates, this chapter is aimed at helping you plan an SEE implementation approach.
Figure 8-3 This chapter offers planning guidance to wizards and kings for setting up a software process improvement approach via SEE implementation. The chapter helps you select concepts from the preceding chapters to construct this approach. The concept of implementation plan as used in this chapter means "anything from notes scratched on the back of an envelope to a multivolume formal and highly detailed document—whatever makes sense for your organization." Reduced to simplest terms, plan in this chapter means "think and coordinate before doing."
We stress at the outset that this chapter is intended for both wizards and kings. If you are a wizard, this chapter will help you respond to a king's request for a wizard whose skill lies not in hand-waving but lies in setting up and following processes that consistently yield products with integrity (ideally, you should not have to wait for a king to ask you for a repeatable way of doing business). If you are a king, this chapter will help you (1) construct an SEE implementation approach to include in a request for proposal (RFP) that you want a wizard that you intend to hire to follow or (2) give guidance in an RFP to a wizard that you want to hire to construct an SEE implementation approach to include in the wizard's proposal or (3) give guidance to a wizard that you have already hired to construct an SEE implementation approach.
As Figure 8-3 indicates, "implementation plan" as used in this chapter spans a broad spectrum. It could be something as informal as notes scribbled on the back of an envelope highlighting the handful of things that need to be accomplished to set up and operate within an SEE. At the other end of the documentation spectrum, "implementation plan" could be a multivolume tome (for, say, a large systems development effort with major software content, or for a large organization handling fifty to several hundred or more concurrent software systems development efforts). Or "implementation plan" could be something in between these two documentation extremes. No matter where in the spectrum it lies, the purpose of the plan is to bring involved parties within an organization into the same frame of reference for setting up a consistent way of doing software systems development business.
This chapter serves as a guide to help you work your way back into previously introduced ideas to integrate them into an SEE implementation approach that makes sense for your organization. Since we do not know the details of your organization, this chapter bounds your thinking by giving you factors to consider when laying out an implementation approach. For example, we give you things to consider bearing upon how frequently ADPE elements should be updated so that you can include in your implementation plan an element update schedule.
8.2 SEE Implementation Planning Key Ideas
Figure 8-4 lists the key ideas that you can expect to extract from this chapter. To introduce you to this chapter, we briefly explain these key ideas. Their full intent will become apparent as you go through the chapter.
Figure 8-4 Here are some key process improvement planning concepts explained in this chapter. These key ideas are your guide to plan SEE implementation realistically. A realistic SEE implementation plan helps to focus your efforts toward consistent successful software systems development. To plan realistically in this chapter means "laying out an approach that motivates people to (1) overcome their resistance to change and (2) implement SEE business practices."
1. Plan your process improvement with business practices defined in ADPE elements. Your SEE implementation plan should propose an element phase-in strategy, with your first element defining your software systems development process.
As we showed in Chapter 3, this element establishes the context for most or all other ADPE elements. The software systems development process element is itself thus a plan for subsequent ADPE development. Any SEE should include at least this element.
2. The primary objective of SEE implementation is to establish organizationwide business practices that do not depend on particular individuals for their successful accomplishment.
This objective should not be misunderstood. Removing dependence on particular individuals for successful software systems development does not mean that SEE implementation is designed to put people out of work. Good people are certainly needed to achieve successful software systems development. The intent of establishing organization-wide business practices is to plug all these people into a consistent way of doing things, so that on any given day good work will be done no matter who is doing the work. These business practices leverage the goodness of people across the organization and help provide them with professional mobility. For example, Chapter 4 showed how to set up an ADPE element governing an organization's CCB meetings. Specifically, we explained how this element can be used to specify organizationwide practices for setting up, conducting, and documenting CCB meetings. These practices allow CCB meetings to be conducted and documented on any given day in the same way that they are conducted and documented on any other day—no matter who is conducting and documenting them. Good people are, of course, needed to make these meetings worthwhile—that is, to help carry through on software project work.
3. Package your engineering environment in a binder containing your ADPE elements and material pertinent to your technology environment. Give a binder copy to each member of your organization.
SEE implementation cannot begin to happen unless the SEE gets into the hands of your organization's people. One standard way to promulgate ADPE elements and the associated technology environment is to place this material in a binder (hard copy or electronic) and give each member of your organization a copy when that person joins your organization. The binder should also contain an explanation of the SEE concept and the relationship of this concept to your organization's business objectives. It should also contain instructions for adapting its contents to the specific project work to be accomplished by the binder recipient. For example, each binder should have space for project-specific material such as a copy of the customer's statement of work (SOW) and the project plan governing that recipient's work. Your organization should set up a process for sending SEE updates to binder recipients.
Of course, packaging the SEE in a binder and giving binder copies to each member of your organization does not make the business practices in the binder happen. Among other things, your organization should establish a policy delineating that each individual is responsible for (1) reading its contents, (2) following the practices documented therein, and (3) promoting these practices with your organization's customers. To make this policy happen, you will need to offer training and incentives. The training should be aimed at explaining such things as the engineering principles underlying ADPE elements and the value added of following the practices; the training should also stress that following the practices offers the individual career growth opportunities because the individual is not a captive of a particular project function (e.g., with a documented configuration management process, individuals currently handling configuration management functions can move on to other things because these documented functions can be performed by other individuals). But documenting your business practices (through ADPE elements or by other means) itself will generally not make SEE implementation happen. People will need to be offered incentives to adapt themselves to these business practices (e.g., salary raises tied to the degree to which an individual can demonstrate that he or she has followed the SEE way on project work).
4. Make the CCB your process focal point for customer/seller interaction.
At the outset of this chapter, we reiterated that the avenue to consistent successful software systems development is the sustained effective communication between the wizard (i.e., software seller) and the king (i.e., software customer). Chapter 4 detailed how the CCB is a mechanism for sustaining this communication. Chapter 3 explained how the CCB serves to focus project activity. A CCB mechanism should be put in place even before you document your organization's software systems development process. Customer/seller interaction should be formalized (via a CCB mechanism) at project outset—even without a CCB ADPE element. CCB rules can be stipulated in the project plan. Lessons learned from iterating on such rules during the early stages of setting up an SEE can be folded into such an element (to be promulgated after a software systems development process ADPE element has been promulgated).
5. In a small organization (say, up to ten people), plan for packaging the ADPE into a single element, with each section addressing what in a larger organization would be a separate element.
A consistent way of doing software systems development business is independent of organization size. Thus, documented business practices have a place in small as well as in large organizations. Because the number of communications paths among individuals is much less in small organizations than it is in large organizations, the amount of documentation needed to specify these practices is generally much less in small organizations than it is in large organizations. This principle should be applied when planning SEE implementation for a small organization. However, as with most software engineering principles, this principle is not inviolate. In some cases, it may be necessary to have voluminous ADPE elements even in a small organization. Such would be the case if, for example, a small organization were responsible for developing software systems whose failure might result in people getting killed, suffering injury, or sustaining large financial loss. Such would also be the case if a small organization were developing software systems under a fixed-price contractual vehicle. In this case, the seller might sustain large financial loss if the way of doing business were not clearly spelled out (particularly if the seller becomes involved in litigation). A small organization might also need voluminous ADPE elements if it were responsible for developing warranted software systems (for example, the seller would be responsible for repairing or replacing computer code, databases, and/or documentation for, say, up to one year after purchase—at no cost to the buyer).
6. Include in your plan a strategy for winning people over to the ADPE way (e.g.,mentoring, bonuses).
We detailed in Chapter 7 how ADPE implementation is a cultural change exercise. A realistic SEE implementation plan needs to include a strategy for winning people over to the ADPE way by (1) accounting for people's natural resistance to change, (2) building upon business practices that may already exist, and (3) encouraging people to contribute to the development of new business practices.
7. Make requirements management a training priority.
This key idea is a corollary to the message in the wizard-and-king comic strip. Requirements management is the number one challenge industrywide to successful software systems development. If it does nothing else, your requirements management training should provide guidance on how to institute effective oral and written communication between the wizard and king.
上一页 [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] ... 下一页 >>