Home > Articles > Software Development & Management > Management: Lifecycle, Project, Team

The Software Life Cycle

  • Print
  • + Share This
If your software's lifecycle starts with coding and ends with a successful compile, its lifespan is probably going to be pretty short. For a business that develops software, many more careful steps are required to build software that works well, satisfies its users, and lasts.
Placing special emphasis on a comprehensive approach combining organization, people, process, and technology, Harris Kern's Enterprise Computing Institute is recognized as one of the world's premier sources for CIOs and IT professionals concerned with managing information technology.
From the author of

Many people view the software development lifecycle as that time between when a programmer sits down to write the first line of code for a program, and the point when the completed program successfully compiles and executes. Successful software development organizations have much more complete definitions of a software lifecycle. These lifecycle definitions start with early requirements-gathering and analysis stages, and proceed through ongoing operation and maintenance. The maturity of a software development organization, in fact, is closely related to its understanding of the software lifecycle and the underlying processes and procedures required to successfully develop software.

The Software Engineering Institute (SEI) has captured this in a series of models, called capability maturity models (CMMs). These models judge the maturity of the software processes of an organization and identify the key practices required to increase the maturity of these processes. This article introduces the capability maturity model and then discusses how it applies during the software lifecycle, from initial requirements definition to production acceptance.

The Capability Maturity Model for Software

The United States government, as one of the largest developers and users of software in the world, has always been very concerned with improving software processes. As a result, the Software Engineering Institute (SEI) was created. The Institute is a federally funded research and development center, which has been run under contract by Carnegie Mellon University since 1984. Software professionals from government, industry, and academia staff the SEI. The SEI web site contains information about all the activities of the institute. One of the most important contributions to software development to come out of the SEI is its series of capability maturity models, which describe how to measure the maturity of software development organizations. The SEI has defined six capability maturity models:

  • SW-CMM: A capability maturity model for measuring software development organizations.

  • P-CMM: The people capability maturity model, for measuring an organization's maturity in managing its people.

  • SE-CMM: A capability maturity model for measuring system-engineering organizations.

  • SA-CMM: A capability maturity model for measuring how an organization acquires software.

  • IPD-CMM: A capability maturity model for measuring an organization's ability to perform integrated product development.

  • CMMI: The capability maturity model integration.

The CMMI is the most recent focus of the SEI's activities, and currently exists in draft form. This project's objective is to develop a capability maturity model integrated product suite that provides industry and government with a set of integrated products to support process and product improvement. This project will serve to preserve government and industry investment in process improvement and enhance the use of multiple models. The project's output will consist of integrated models, assessment methods, and training materials.

The first capability maturity model developed by the SEI was the capability maturity model for software, also known as the SW-CMM. Watts Humphrey and William Sweet first developed it in 1987. The SW-CMM defines five levels of maturity commonly found in software development organizations, and describes processes required to increase maturity at each level. While concepts such as network computing and the Internet were unknown then, the SW-CMM remains a benchmark by which software development organizations are judged. The Software Engineering Institute has updated the model since then, with the latest version being the SW-CMM version 2 draft C, released in October of 1997. The basics of the model have not changed, however. Now more than ever, as development organizations are forced to work to schedules on "Internet time," process maturity remains critical to software development organizations.

The capability maturity model for software categorizes software development organizations into one of five levels according to the maturity of their processes. A brief description of each of the five maturity levels is provided below, along with key process areas for each level. Within each process area, a few representative traits of organizations performing at this level are listed. The complete SW-CMM, of course, includes many more details than are possible to cover in this article.

Level 1: Initial

At this level, software development is ad hoc, and no well-defined processes are followed. As such, organization focus is typically placed on those key developers, or "heroes," who happen to fix the software bug of the day. Organizations at this level of maturity are not likely to be successful at delivering anything but the most simple software projects. An organization operating at this level might expect to take six to nine months to move to level 2, assuming that a proper management team is in place with a focused effort to improve the organization.

Level 2: Repeatable

At this level, there is a focus on project management to bring repeatability to the software development processes. The key process areas expected to be mastered by organizations at this level are listed below.

  • Requirements management. Software requirements are developed prior to application design or coding. At each step in the software design process, requirements are mapped to software functions to ensure that all requirements are being met. Software testing includes requirements traceability matrices.

  • Software project planning. Software projects are scheduled and budgeted accurately. Software engineers of the right skill mix and experience are assigned to each project.

  • Software project control. Software projects are tracked against their plan. Proper management oversight is used to identify project risks, instead of waiting until delivery dates are missed.

  • Software acquisition management. Any third-party software acquired for use on the project is properly evaluated for training, performance, usability, or other limitations it may impose on the project.

  • Software quality assurance. Each developer is held accountable for software quality. Quality metrics have been established and quality is tracked against these metrics.

  • Configuration management. All developers use a software revision control system for all project code. Software baselines are properly established and tracked.

Having these processes and their management in place will typically result in organizations that can deliver small to mid-sized projects in a repeatable fashion. Organizations at this level that don't move toward level 3 often fail when they undertake larger projects, or fail to meet cost, quality, and schedule constraints that become imposed on them. Level 2 software groups are fairly common to find among the IT organizations of large corporations, where software development management has been made a priority. However, moving to the next level requires a concentrated effort in software process development, and might take anywhere from 12–24 months for a typical level 3 organization.

Level 3: Defined

Organizations at level 3 have moved on from simple project management of software development to focus on the underlying engineering processes. The key process areas to be mastered by organizations at this level are listed below.

  • Organization process focus. A process focus is ingrained into the culture of the development organization.

  • Organization process definition. The organization translates its process focus into the clear definition of processes for all aspects of the software development process, from initial requirements definition to production acceptance.

  • Organization training program. The organization not only trains all software engineers on the software technologies being used, but also on all processes.

  • Integrated software management. Organizations have implemented the categorization, indexing, search, and retrieval of software components to foster reuse of software as much as possible.

  • Software product engineering. Individual software products are not simply developed in isolation, but are part of an overall software product engineering process that defines business-wide applications architecture.

  • Project interface coordination. Individual software projects are not defined in isolation.

  • Peer reviews. Peer reviews of software are accomplished at various places during the software lifecycle—after design is complete, during coding, and prior to start of unit testing.

Achieving level 3 of the capability maturity model is the goal of most large software development organizations. Levels 4 and 5 go on to define additional criteria that very few organizations are able to meet.

Level 4: Managed

At this level, the entire software development process is not only defined but is managed in a proactive fashion. The key process areas to be mastered by organizations at this level are listed below.

  • Organizations software asset commonality. In addition to enabling reuse through software management, reuse is built into the design process by following common design standards, interfaces, programming guidelines, and other standards.

  • Organization process performance. The organization has established metrics for evaluating the performance of its software processes.

  • Statistical process management. Statistical methods are used and managed in the development, implementation, and tracking of process use and effectiveness.

Organizations at level 4 thus not only manage the quality of their software products, but also can manage the quality of their software processes and understand the second-order effect of process quality on product quality.

Level 5: Optimized

This is the "Holy Grail" of software development. In fact, very few large organizations have ever achieved a level 5 score in SEI evaluations. To do so requires a demonstration of continuous process improvement in software development. The key process areas to be mastered by organizations at this level are listed below.

  • Defect prevention. The organization not only focuses on quality assurance—that is, finding and correcting defects—but on defect prevention.

  • Organization process and technology innovation. The organization continually innovates both in new processes that are developed and in new technology applied to the software development process.

  • Organization improvement deployment. Continuous process improvement in software development is not just a buzzword but is planned, executed, and tracked against the plan, with ongoing feedback loops.

Certainly, many organizations have achieved some of these criteria on some projects; however, achievement of level 5 requires universal adherence by all software development groups on every project.

The software processes of the SW-CMM can be applied across the entire software lifecycle, from requirements-gathering through final testing. The rest of this article provides a brief description of different stages of the software development process.

  • + Share This
  • 🔖 Save To Your Account