Difference between revisions of "What Makes Up a Lifecycle?"

Revision as of 20:11, 5 January 2016

1 Overview

When thinking about what EIT does on a day-to-day basis, you have to consider two different perspectives. In part 1 we discussed the ongoing critical functions that enable enterprise IT to carry out its mission of supplying high-quality, reliable information and communication services.

This section, Part 2, discusses the service life cycle, from service concept — defined in a set of requirements — to service transition, to deployment, and then to retirement.

2 Projects and Project Management

Projects are defined as scope (features and constraints), schedule, and resources. 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.

Because there are usually too many unknowns to predict exactly what will produce the required scope, 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 waterfall development. This can also be used for projects that involve 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 reason 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. By surveying all change requests, it is easier to prioritize them using portfolio management, and bundle high-priority ones into projects, so that resources are applied where most appreciated.

3 EIT System Development Life Cycles

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.

In the EITBOK, we have adopted a fairly traditional product life 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 happening simultaneously. How the phases are executed depends on the solution type, size, and complexity, as well as the specific development methodologies that the EIT organization has adopted.

“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 an enterprise, needed to ensure customer acceptance at prescribed milestones. The easiest way they saw to do this was to have major milestone reviews to approve progress to date. 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, tams from 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. Because they also used continuous integration, it was obvious early on when features didn’t play together well.

3.1 Requirements Analysis and Design <h3>

The requirements 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.

<h3>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 performance of the supplier or vendor in providing support and fulfilling other contractual obligations.

3.2 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.3 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 installing a new software application, migrating an existing hardware infrastructure into a new location, refreshing key business applications with new software, or decommissioning a datacenter, hardware, or network devices.

3.4 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 call 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.