What Makes Up a Life Cycle?
|
Contents
1 What is a Lifecycle?
In Part 1, we discussed the on-going critical functions that enable Enterprise information technology (EIT) to carry out its mission of supplying high-quality, reliable information and communication series. Part 2 discusses the lifecycle perspective, from concept—expanded into a set of requirements—to transition, then deployment, and finally retirement.
The term lifecycle refers to the stages that something or someone progresses through, from beginning to end, or birth to death, changing form (maturing, usually) along the way. For example, appliances have "useful" lives, a term that describes the core part of the appliance's lifecycle. Lifecycles are not the same as methodologies (collections of methods) or strategies for developing a product. Many different options for methods and strategies can be used to carry out the activities needed to design and build a product.
Some views of a product lifecycle include the marketing perspective of a lifecycle (Figure 1), which focuses on sales.
Figure 1. The Marketing Perspective of a Lifecycle
There is also an innovation adoption lifecycle (Figure 2) that describes who adopts new technologies, originally described by Everett Rogers in his Diffusion of Innovations theory, and later popularized by Geoffrey Moore's book Crossing the Chasm (3rd edition, HarperCollins, 2014).
Figure 2. Innovation Adoption Lifecycle
1.1 Product Lifecycles
Another view is that of the producer, or the product manager, responsible for managing the lifecycle of the product, from design through production and maintenance to retirement (including simple withdrawal of support).
The sequence is the same for software, except that "production" includes building and testing the software, and then "manufacturing" the media in which it will be delivered (CD, tape, tar file, etc.).
Unfortunately, most diagrams of the software lifecycle are usually abbreviated, showing just the parts that developers focus on. Given that there are still legacy systems running Cobol, it's easy to see why retirement gets ignored! However, software product companies have to consider sunsetting (retiring) their products, so that they don't have to support them forever, as newer versions are sold.
1.2 Project Lifecycles
The software world has often conflated the ideas of product lifecycle with project lifecycle. A project lifecycle has a beginning, when the project is authorized, for example, and an end. However, many projects can be involved in creating and refining a software product. There might be a project to define the requirements for a project by developing a working prototype, or a demo version. When that is approved, there is a project to develop and deliver the first version of the product. (With agile methodologies, we often see that each iteration has its own project plan and follows the same sequence of activities in each iteration. Thus, each iteration is a sub-project that has its beginning and end, ergo, a life.)
Figure 3 is an example of the activities in a project lifecycle in a software product company.
Figure 3. Activities in a Project Lifecycle
Reducing the level of detail given above, we can arrive at the typical circular depiction of a project lifecycle (Figure 4), although it is often mistakenly called a product lifecycle.
Figure 4. Circular Depiction of One Type of Project Lifecycle
Note that as shown in the figure, it is often the case that each feature follows its own lifecycle, rather than all features having to move in lockstep.
2 Projects and Project Management
Projects are defined as scope (features and constraints), schedule, and resources. They have beginnings and endings. Project management is the balancing act of producing the desired scope of requirements, within the planned schedule and within the budgeted resources. Management of the key resources—the people—is the pivotal management skill, because the people are the major costs and the primary determiners of the schedule.
There are usually too many unknowns to predict exactly what it will take to produce the required scope, so project management depends on various approaches and mechanisms to estimate cost and duration, both with high-level estimates up front and with increasingly precise estimates as the project progresses.
The Software Extension to the Guide to the Project Management Body of Knowledge (PMBOK), jointly produced by IEEE and PMI, explains how these tools are used in both predictive and adaptive development. (It can also be used for projects that include hardware.) Another good resource for projects building large systems, or systems of systems, is the Guide to the Systems Engineering BOK (SEBOK), which is a wiki produced jointly by IEEE and INCOSE.
The project approach is used both for new development (greenfield) and for the production of subsequent system revisions. There are many reasons for using the project approach (projectizing) for system revisions rather than handling changes as a stream of independent user requests. One important reason is that bundling change requests makes it more likely that one change won't "break" the system in the production. Another is that it enables EIT to better contain its costs. For years, EIT has had to deal with complaints that 80 percent of its budget goes to "maintenance" while requests for new services pile up and take forever. However, it turns out that the bulk of what has been called "maintenance" is usually adding new functionality! By surveying many change requests at one time, it is easier to prioritize them using portfolio management, and bundle high-priority changes into projects, so that resources are applied where most appreciated.
3 EIT System Development Methodologies
An information system or service is a product that satisfies a want or need. The product lifecycle is the course of a product's design, development, use, and retirement over the system's lifetime, as discussed above.
Figure 5. Product Lifecycle
The development of a system is just one part of the system's life. Development has a beginning, and ends (traditionally) with the delivery of the finished system. However, the system's life goes on after that, often for decades.
In the EITBOK, we have adopted a fairly traditional system development cycle with six commonly accepted phases. Despite the fact that these phases (or stages) appear to occur in a clear sequence, in reality, for any given solution/system development, several phases can be going on simultaneously for different parts of the system in cases where they can be developed in parallel. How the phases are executed depends on the solution's type, size, and complexity, as well as the specific development "strategy" that the project team has adopted.
Development strategies are generally referred to as methodologies. Many different methodologies have evolved over the past 40 or so years.
"Agile" methodologies were a reaction to what has been termed waterfall development. Waterfall was seen in situations where a third-party developer, whether for the government or for a non-governmental enterprise, needed to ensure customer acceptance at prescribed milestones. The easiest way they saw to do this was to have major milestone reviews at which progress to date was approved. As major milestones, the end of the logical phases in the development lifecycle were selected: requirements, design, test, and integration into a larger system when necessary. Unfortunately, these had the unintended consequence of holding up pieces of the product while others were being worked on. On the other hand, in software product companies, product management, development, and testing teams worked closely throughout the development of the product, so approvals frequently occurred at the feature level for requirements and design. They also used continuous integration, so it was obvious early on when features didn't play together well.
3.1 Requirements Analysis and Design
The analysis and design phase involves gathering information about what the organization needs, what the solution must accomplish, what data is needed, and what business rules drive the process. Systems analysis attempts to answer the question, "What must the information system do to solve the problem?" From those requirements, the team creates a detailed conceptual design of what the solution must do, how it interacts with users and other EIT resources, and how to determine whether it is successful.
3.2 Acquisition
Acquisition is the process of obtaining a system, product, or service and ensuring its successful implementation, whether the supplies or services already exist or must be created, developed, demonstrated, and evaluated. Acquisition also includes ensuring that proper mechanisms are in place to monitor the supplier's/vendor's performance in providing support and fulfilling other contractual obligations.
3.3 Solution Construction
Construction is the system development phase that involves creating all of the various system components called for in the conceptual design so they work together as expected. It may include the need to revisit designs that proved unworkable, or even to re-examine requirements. For this reason, many agile developers prefer to say that the finished system is the final documentation of the requirements. However, those who work on subsequent revisions of the production system might bemoan the lack of explanation of the rationale for design.
3.4 Solution Transition
Transition consists of a set of processes and activities that release new solutions into an EIT environment, replace or update existing solutions, remove a solution or component from service, or move EIT components from one location to another. Examples of transition include the installation of a new software application, migration of an existing hardware infrastructure into a new location, a refresh of key business applications with new software, or decommissioning a datacenter, hardware, or network devices.
3.5 Maintenance
Maintenance (or support) of an EIT system involves the set of activities performed to ensure that the system remains operational. This includes actions necessary to prevent the deterioration and failure of a system due to defects, obsolescence, or environmental conditions.
Traditional definitions of maintenance include the evolution of a system via the application of enhancements. However, system evolution is actually a type of new development, sometimes called brownfield (to distinguish it from greenfield development). Brownfield development is often a lot harder than greenfield, because it adds many constraints set by the existing system's architecture and other factors.
4 Development Methodologies
Various development methodologies (frequently but erroneously called "system development lifecycles" [SDLC]) have come and gone since the 1980s. Some have been based on the type of system being developed (e.g., IBM's Client-Server Methodology in the early 1990s and subsequent methodologies developed by others). Others were based on a specific tool used to produce software (e.g., RAD, which came along with the advent of graphical interface and other code-generation development tools). Most, however, reflect a strategy of how the project team should work to produce the system. They often incorporate principles from kanban (https://en.wikipedia.org/wiki/Kanban) and lean manufacturing (https://en.wikipedia.org/wiki/Lean_manufacturing). Here are a few of the non-proprietary methodologies commonly used in the past couple of decades:
- Feature driven development (FDD) differs from other agile methodologies because it postulates just enough effort at the beginning of a project to understand the problem by building an object model of the problem domain. This is a structured, time-boxed activity that helps avoid surprises down the road. Instead of user stories, FDD talks about features. A feature is a small piece of function desired by stakeholders and expressed in the form: <action> the <result> <by|for|of|to> an <object>; for example calculate the total of a sale. For a good intro to FDD, consult Wikipedia, or http://www.methodsandtools.com/archive/archive.php?id=19p2.
- Joint application design (JAD) was developed by IBM engineers (Chuck Morris at IBM Raleigh and Tony Crawford at IBM Toronto) in the late 1970's as an interactive systems design concept. It was designed to bring system developers and users of varying backgrounds and opinions together to agree to system requirements, rather than interviewing people one at a time. Its use expanded and evolved over time to cover the whole development process. For details of the process, see http://www.umsl.edu/~sauterv/analysis/JAD.html#components.
- Scrum is probably the best known form of agile, iterative, incremental development today. It calls each iteration a sprint, which is the basic unit of development. Each sprint starts with a planning meeting, where the tasks for the sprint are identified and an estimated commitment for the sprint goal is made. A sprint ends with a review or retrospective meeting where progress is reviewed and lessons for the next sprint are identified. During each sprint, the team creates finished portions of a product. Several software development tools specify their support of scrum. You can find more information at https://www.scrum.org/Resources/What-is-Scrum.
- Test driven development (TDD) stands part of the development cycle on its head. Before any coding is done, requirements are turned into automated tests (both positive and negative). Then enough of the code is written to pass the initial tests. For details of the process and pros and cons of its use, see https://www.agilealliance.org/glossary/tdd/.
4.1 Other Options, Including Proprietary
- Crystal was designed by Alastair Cockburn as an agile approach that has different "weights" to determine how much rigor (formality) is required, by considering the size and complexity (and other factors) of the project. See http://alistair.cockburn.us/Crystal+methodologies.
- Dynamic systems development method (DSDM) is an agile project delivery framework, initially used as a software development method. See https://www.agilebusiness.org/.
- Scaled Agile Framework for the enterprise (SAFe is proprietary). See https://www.ivarjacobson.com/scaled-agile-framework. SAFe is also a major proponent of agile architecture which attempts to apply agile thinking and techniques to the design and development of application architectures.
