Summary of Development Phases

Team-Fly

---

 

	Requirements Analysis: From Business Views to Architecture By David C. Hay
	Table of Contents
	Chapter 2.  Managing Projects

---

Summary of Development Phases

So, what must we do to build a system? Many projects follow the system development life cycle portrayed in Figure 2.2. The project begins by programming something that looks interesting. Then it turns out that the program doesn't do something else that's important. So we modify the program, expanding it and introducing errors. We then discover that this isn't satisfactory and go around again. This continues until we run out of money or patience or both and the project is given up. ^[1]

^[1] or the program is accepted as the "beta" version.

Figure 2.2. The Usual System Development Life Cycle.

This approach has been common in our industry for most of its history. It has been given formal recognition more recently under the name the prototype approach .

In some circumstances, indeed, the prototype approach can be used successfully. When new technology is being used, and it is not exactly clear what the final product will or should look like, experimentation is very appropriate. But it is important to recognize that experimentation is what is going on. When presenting a prototype to users, be sure to communicate one very specific message:

This is not the final system. That could still take a very long time to build.

At the other end of the innovation scale, the planning time can also be minimized if a project being built is small and very similar to others that have been built by the same people, using familiar technology.

For projects of significant size , however, the prototype approach is not satisfactory. It tends to yield multiple, relatively small systems that don't communicate with each other very well. In other words, as Edwin Landale wrote in a 2001 letter to your author, "If you have only a few weeks to do the job, if the system doesn't have to talk to any other system, and if the system won't exist for long, then quick and dirty is the right approach."

The important point here is that this approach will not reflect any sort of underlying corporate architecture. A more methodical approach is to start at the beginning of a well-defined system development life cycle and conscientiously work from one step to the next .

A system development life cycle is a predefined approach to developing systems, beginning with strategic planning and carrying through analysis, design, construction, and implementation. The specific phases vary from methodology to methodology, but the overall concept is the same: Plan carefully before executing the plan.

Figure 2.3 shows a sample system development life cycle. There are many variations on this theme, but most have approximately these six phases:

• Strategic Planning

  Lay out the vision, mission, priorities, and constraints of the enterprise. From this, define a set of projects, carefully setting the boundaries among them so as to make the whole coherent . These boundaries then define the scope of each project. This phase is carried out from the perspective of the planner's view (Row One) of the Architecture Framework.

• Requirements Analysis

  For each project, determine the nature of the portion of the enterprise that it affects. From that derive a statement of what is required from a new system. This phase arises from the translation of the business owner's view (Row Two) to the architect's view (Row Three) of the specified part of the business. From analysis of the differences between these views come the requirements for what prospective systems might do. This phase, of course, is the primary subject of this book.

  Note that the first two phases have nothing to do with selecting or making decisions about computers or software.

• Design

  For each application area defined during the analysis phase, determine the technologies to address the requirements derived above, and define the specific configurations of those technologies. This is done from the designer's (Row Four) point of view. Design will be in terms of a set of system components , each of which will be addressed during construction.

• Construction

  Build each component of the new system. The builder's view (Row Five) is operative here.

• Transition

  Make the new system part of the enterprise's infrastructure, replacing one or more older systems in the process. This is the translation of the business owner's previous view (Row Two) to a new business owner's view.

• Production

  Maintain the system, ensuring that it continues to meet requirements. This involves fixing bugs and adding enhancements. ^[2] This is a view of the production system (Row Six).

  ^[2] Note, of course, that anything more than trivial corrections actually fires up the system development life cycle once again. Again it will be necessary to analyze requirements, design any corrections, and so forth.

Figure 2.3. System Development Life Cycle.

This approach is often called the "waterfall method", since you start at the top and progressively "fall down" the phases. ^[3] The underlying idea is that you should completely finish strategy before moving into analysis; you should completely finish analysis before starting design, and so forth.

^[3] Presumably one does not actually fall down during the process.

Of course, no one really approaches it this way. At each phase, there is often review of previous phases and discovery of things that were left out. After an iteration of Design, for example, it is often appropriate to revisit Analysis.

As Edwin Landale points out, this makes the process more like a river than like a waterfall. A river twists and turns, occasionally bumping into rocks that produce eddies swirling backward.

As previously stated, this book is concerned with the second phase of the system development life cyclerequirements analysis. Subsequent chapters describe the models required to address various facets of the problem, and this one addresses the specific processes that will be required to carry it out.

Much of this chapter is derived from Oracle Corporation's 1996 "Custom Development Method" and from work with Aera Energy, LLC of Bakersfield, California, but some of it comes from other sources as well.

---

Team-Fly

Top