April 01, 2000
Optimize or Adapt
Few achieve CMM level five, not only because they lack the resources for continuous process improvement, but because they have a false impression of what a software process is.
As a developer working in an organization that abides by a software process, I take exception to Jim Highsmith’s characterization of software processes in general and their relationship with creativity in particular. The Software Engineering Institute’s Capability Maturity Model (CMM) is not, as Jim Highsmith proclaims, "a collection of regulated, simplistic views" meant to strangle an organization’s creativity, but a powerful tool that enables an organization to produce better products while providing its employees with an improved working environment. In fact, Highsmith’s own solution to the chaos of software development–adaptive patterns–is diminished by his inaccurate portrayal of what constitutes a software process. Highsmith writes, for example, that "following the 14 recommended steps in a requirement definition process does not guarantee success." The CMM level two requirements management process, however, does not define 14 steps. There are two goals and 12 key practices (one commitment, four abilities, three activities, one measurement and three verifications). Nowhere in the CMM process is a particular methodology for requirements management imposed. There aren’t 14 steps in the CMM that must be used to do requirements management–or any other software development life-cycle activities, for that matter. The CMM and other prominent software development processes, such as the Rational Unified Process (RUP) and the Henderson-Sellers OPEN process, are not about "rigorous rules and tight control" as Highsmith writes. These process models emphasize that an organization should first observe the model and then adapt the process to its needs. In fact, a key SEI document, entitled "Process Tailoring and the Software Capability Maturity Model" (CMU/SEI-94-TR-024), provides a framework for altering the CMM. The CMM process is not applied as is on all projects of an organization; it must first be tailored for the organization and then tailored for each project. The Fifth Element Highsmith argues that while optimization solved yesterday’s software delivery problems, today’s accelerated market requires an organization to focus on adaptation. However, Highsmith overlooks the fact that optimization implies adaptation. While the SEI describes level five as the level at which "the entire organization is focused on continuous process improvement," process improvement is independent from CMM. Process improvement suggests that the organization takes into account changes in its environment, new tools and problems with the process identified in previous projects. Process optimization only means that the organization tries to improve, adapt and correct its software process–using past project information–before problems escalate out of control. Granted, very few organizations are at level five, because it takes tremendous commitment from upper management to allocate the time, people and money needed for continuous software process improvement. Additionally, there is a lack of commitment for software process improvement in most organizations because upper management does not appreciate the long-term benefits. Articles such as Highsmith’s "Beyond Optimizing" only add to the problem by creating a false impression of what is a software process and why it is used. Highsmith tells us that the CMM and other such processes "attempt to counteract uncertainty by admonishing people to be more certain," but no process can remove uncertainties. What is the main part of the CMM? It is the key process goals for each level. And what are these goals? The industry’s best practices and common sense. To reach a CMM level, an organization does not have to do everything described in the key process areas (KPA) for that level; however, the goals of the KPAs must be satisfied. There is no admonition there, as Highsmith argues, but there is a reduction of the uncertainties (and risks) because the organization must document and verify what is done during the software development cycle. If something goes wrong for a project, the information will be used on the next one to avoid making the same mistakes. New Product, Old Mistakes A colleague of mine worked in a system-engineering department that didn’t follow a process. When a project ended, the design documentation didn’t correspond to the equipment in production, and there wasn’t any time or money to document or correct any of the found problems. When a new project began, the new team used the old documentation as a design reference and, therefore, repeated many mistakes from the previous project. Without a formal process to verify and validate the design, to do configuration management, or to manage requirements, the same mistakes continued to be made on each and every project. These errors ultimately created delays and cost each project more money than it would have cost to simply update the design documentation. The systems created did increase in complexity from one project to the next, so upper management has finally decided to implement a process. This organization wants to move from chaos (which does not work) to structure because a process helps reduce (not eliminate) many problems by establishing verification and validation, configuration management and requirements management activities, and so on. Mental Health A software process, when well implemented, also reduces the stress placed on the software development team. I have been developing embedded-system software for 15 years and hadn’t worked in an organization with a software process until four years ago. The main activities of the first software process in which I worked were verification and validation of the design to ensure that the proper software was being built, and those two activities greatly reduced the amount of stress I experienced. During the previous 11 years, there was no formal verification (walkthrough or review) of my design whenever I developed a software component. Consequently, the verification was done only when my software component was integrated into the product, and errors (some small, some big) were common because I had misinterpreted some requirements and no one had checked my design. Today, I work in an organization using a software process where formal verification and validation begins with the system requirements down and extends to the detailed design and unit test planning. This means that, if I misinterpret a requirement, two or three of my colleagues are there to catch my error. This doesn’t mean that I do a sloppy job because somebody else will correct it; rather, I know that a huge mistake, that will require weeks of work to correct, won’t be found four months later during integration. In another organization that is currently at CMM level three and progressing toward level four, a colleague has also confirmed this benefit of a systematic software process: All the software development team members experience less stress. Not Paid to Think? Highsmith also writes that "processes imply you don’t have to think." I am happy to report that I do not think less now that I work within a software process. In fact, we have more time to think about software design with a process, and we may even be more creative, because we do not have to spend as much time and energy to organize our work. I see no link between a software process and limited creativity. Software processes and methodologies are often compared with the construction of a building. Is the architect’s creativity limited by mechanical engineering rules and building code regulations? Perhaps a little–he has to comply with a minimum ceiling height, provide emergency exits, consider the characteristics of the materials used, be concerned with aesthetics, and so on. However, the architect’s own creativity and skills are the principal limiting factors in the building’s design. Creativity, knowledge and skills are personal attributes. I agree with Highsmith that structure does not substitute for skills, but do people lose their skills because they are using a software process? I think not. A process doesn’t dictate how a person thinks. The CMM doesn’t try to prescribe the skills of a person to be "plunked into the next recruit," as Highsmith wrote, but it does try to establish a predictable result from the person’s skills and creativity–namely, the resulting system and software design. Once written, these results may be used by the "next recruit" to improve her skills and enhance her knowledge. Put It in Writing The CMM does not specify a methodology, although some other processes, such as the RUP, do suggest particular methods–object-oriented programming, for example. Returning to the requirements management issue, the CMM does not dictate what method to use to analyze the client needs, to find the system requirements or to allocate requirements to subsystems. The organization must define its own method. What the CMM implies is that the organization will define a method that is documented in writing. In fact, the organization should probably have more than one method to modify the process to each type of project. In fact, the CMM doesn’t even define a software development life cycle (SDLC); the organization must decide which SDLC to use. Software process models, such as the CMM, are much more helpful than Highsmith would have us believe. Some organizations may misuse them, but the goals of these models are hardly overly restrictive. Software processes are frameworks to organize our work. And because software development techniques evolve, the process must be improved to follow the organization environment changes. As Larry Constantine writes in his introduction to Mr. Highsmith’s article, "the best structures create a framework for creative process and products."
|
 |
|
||||||||||||||||||||||||||||
|
|
|
