What Makes Up a Life Cycle?

From EITBOK
Jump to: navigation, search
Welcome to the initial version of the EITBOK wiki. Like all wikis, it is a work in progress and may contain errors. We welcome feedback, edits, and real-world examples. Click here for instructions about how to send us feedback.
Ieee logo 1.png
Acm logo 3.png

 

1 What is a Life Cycle?

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 life-cycle perspective, from concept — expanded into a set of requirements — to transition, then deployment, and finally retirement.

The term life cycle is used to refer to the stages something or someone progresses through, from beginning to end, or birth to death, changing form (maturing, usually) along the way. Appliances have “useful” lives, a term that describes the core part of the appliance’s life cycle, for example. Life cycles 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 life cycle include the marketing perspective of a life cycle (Figure 1), which focuses on sales.

Lifecycle 1.png

Figure 1. The Marketing Perspective of a Life Cycle

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).

Lifecycle 2.png

Figure 2. Innovation Adoption Life Cycle

1.1 Product Life Cycles

Another view is that of the producer, or the product manager, responsible for managing the life cycle of the product, from design through production and maintenance to retirement (including simply withdrawal of support). The whole product life cycle for an appliance looks like Figure 3. Note the milestones are shown in the bottom row and the inclusion of “end of life” is the last milestone).

Lifecycle 3.png

Figure 3. Product Life Cycle for an Appliance

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 life cycle 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 do 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 Life Cycles

The software world has often conflated the ideas of product life cycle with project life cycle. A project life cycle has a beginning, when the project is authorized, for example, and an end. However, many projects may 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. Once that is approved, there is a project to develop and deliver the first version of the product. (Often, with agile methodologies, we 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 4 is an example of the activities in a project life cycle in a software product company:

Lifecycle 4.png

Figure 4. Activities in a Project Life Cycle

Reducing the level of detail given above, we can arrive at the typical circular depiction of a project life cycle (Figure 5), although it is often mistakenly called a product life cycle.

Lifecycle 5.png

Figure 4. A Circular Depiction of one type of Project Life Cycle. Note that it is often the case that each feature follows its own life cycle, 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 schedule.

There are usually too many unknowns to be able 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 one is that bundling change requests together 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% 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 life cycle is the course of a product’s design, development, use, and retirement over the system’s lifetime, as discussed above.

Product-Life-cycle.jpg

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 from one to another, 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 life cycle 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 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 actually 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 agilest 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 life cycles" [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:

FDD Feature Driven Development 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> a(n) <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. JAD 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 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 Scrum is probably the best known form of agile, iterative, incremental development today. It calls each iteration a sprint--this 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 the 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.

TDD Test Driven Development stands part of the development cycle on its head: requirements are turned into automated tests (both positive and negative tests) before any coding is done. Then enough of the code is written to pass the initial test(s). 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