Difference between revisions of "What Makes Up a Life Cycle?"

Revision as of 06:50, 21 January 2016

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

1 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, since the people are the major costs and the primary determiners of schedule.

Because there are usually too many unknowns to be able to predict exactly what it will take to 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 Project Management Body of Knowledge (PMBOK), jointly produced by IEEE and PMI, explains how these tools are used in both predictive and waterfall development. It 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 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. 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.

2 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 from one to another, in reality, for any given solution/system development, several phases can be going on simultaneously. How the phases are executed will depend 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 assure 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. In software product companies, on the other hand, 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. Since they also used continuous integration, it was obvious early on when features didn’t play together well.

2.1 Requirements Analysis & Design

This is the phase that 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 IT resources, and how to determine whether it is successful.

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

2.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 will bemoan the lack of explanation of the rationale for design.

2.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 data center, hardware, or network devices.

2.5 Maintenance<h3> Maintenance (or support) of an IT 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, since it adds many constraints set by the existing system’s architecture and other factors.