IN THIS CHAPTER, YOU WILL LEARN:

To be an effective systems analyst, we need more than just modeling tools; we need methods. In the systems development profession, the terms method, methodology, project life cycle, and systems development life cycle are used almost interchangeably. In Part III, we will look at the detailed methods for doing systems analysis, within the broader context of a method — known as a structured project life cycle — for carrying out the overall development of a new system.

Before introducing the structured project life cycle, it is important to examine the classical project life cycle discussed in many textbooks and used in many systems development organizations today, primarily to identify its limitations and weaknesses. This examination will be followed by a brief discussion of the semistructured life project life cycle: a project life cycle that includes some, but not all, of the elements of modern systems development. Next, we introduce the structured project life cycle, presenting an overview to show the major activities and how they fit together. Finally, we will examine briefly the iterative, or prototyping, life cycle introduced in the mid-1980s by Bernard Boar and James Martin, and now popularized by software engineers such as James Highsmith and Kent Beck (see (Highsmith, 2000) and (Beck, 2000)).

We will also explore the concept of iterative or top-down development. In particular, we will introduce the notion of radical top-down development and conservative top-down development. Depending on the nature of a systems development project, there may be valid reasons for adopting one approach rather than the other; indeed, some projects may call for a combination of the two.

5.1 THE CONCEPT OF A PROJECT LIFE CYCLE

As you might expect, small IT organizations tend to be relatively informal: systems development projects are begun as the result of a verbal discussion between the user and the project manager (who may also be the systems analyst, programmer, computer operator, and janitor!), and the project proceeds from systems analysis through design and implementation without much fuss.

In the larger organizations, however, things are done on a much more formal basis. The various communications between users, management, and the project team tend to be documented in writing, and everyone understands that the project will go through several phases before it is complete. Even so, it is surprising to see the major differences between the way two project managers in the same organization will conduct their respective projects. Indeed, it is often left to the discretion of the individual project manager to determine what phases and activities her or his project will consist of and how these phases will be conducted. [1]

Recently, though, the approach taken to systems development has begun to change. More and more large and small organizations are adopting a single, uniform project life cycle — sometimes known as a project plan or systems development methodology or, simply, “the way we do things around here.” Usually contained in a notebook as ponderous as the standards manual that sits (unread) on every analyst’s and programmer’s desk, the documented project life cycle provides a common way for everyone in the systems development organization to go about the business of developing a computer system.

The approach may be home-grown or, alternatively, the systems development organization may decide to purchase a project management package and then tailor it to company needs. [2] It seems apparent that, aside from providing employment for the people who create project life cycle manuals (and for those who write textbooks about them!), the project methodology is desirable. What then is the purpose of having a project life cycle? There are three primary objectives:

The first objective is particularly important in a large organization in which new people are constantly entering the ranks of project management. The fledgling project manager may overlook or underestimate the significance of important project phases if he or she follows only intuition. Indeed, it can happen that junior programmers and systems analysts may not understand where and how their efforts fit into the overall project unless they are given a proper description of all the phases of the project.

The second objective is also important in a large organization. For higher levels of management, it can be extremely disconcerting to oversee a hundred different projects, each of which is being carried out in a different way. For example, if project A defines the systems analysis activity differently than does project B, and project B doesn’t include a design phase, how is the second- or third-level manager to know which project is in trouble and which is proceeding on schedule? [3]

The third objective of a standard project life cycle is associated with management’s need to control a project. On trivial projects, the sole checkpoint is likely to be the end of the project: Was it finished on time and within the specified budget? (Or even more simply: was it finished at all?) And did it accomplish the user's requirements? But for larger projects, management should have a number of intermediate checkpoints during the project, which provide it with opportunities to determine whether the project is behind schedule, and whether additional resources need to be procured. In addition, an intelligent user will also want checkpoints at several stages in the project so that he can determine whether he wants to continue funding it! [4]

Having said all this, let me emphasize that the project life cycle definitely is not in charge of the project. It will not relieve the project manager of the difficult responsibility of making decisions, weighing alternatives, fighting political battles, negotiating with recalcitrant users, boosting the morale of dejected programmers, or any of the other project-related trials and tribulations. The project manager still has to manage, in every sense of the word. The only help that the project life cycle can provide is that it can organize the manager’s activities, making it more likely that the right problems will be addressed at the right time.

5.2 THE CLASSICAL PROJECT LIFE CYCLE

The kind of project life cycle used in many organizations today differs from the one to which we’ll be devoting most of our attention in Part III. The classical, or conventional, project life cycle is shown in Figure 5.1. Every project goes through some kind of systems analysis, design, and implementation, even if it’s not done in exactly the way shown in the diagram. The project life cycle used in your organization, for example, might differ from the one shown in Figure 5.1 in one or all of the following ways:

Thus, an individual organization’s project life cycle may have five phases, or seven phases, or twelve phases, but it is still likely to be of the classical variety.

What is it that really characterizes a project life cycle as being classical? Two features stand out: a strong tendency toward bottom-up implementation of the system, and an insistence on linear, sequential progression from one phase to the next.

 

Figure 5.1(a): The classical project life cycle

5.2.1 Bottom-up Implementation

The use of bottom-up implementation is one of the major weaknesses in the classical project life cycle. As you can see from Figure 5.1(a), the programmers are expected to carry out all their module testing (sometimes known as “component testing”) first, then subsystem testing, and finally system testing. This approach is also known in the computer industry as the “waterfall life cycle,” based on a diagram introduced in (Royce, 1970), and subsequently popularized by Barry Boehm in (Boehm, 1981). It is shown in Figure 5.1(b).

It’s not clear where this approach originally came from, but it may have been borrowed from assembly-line manufacturing industries. The bottom-up implementation approach is a good one for assembling automobiles on an assembly line, but only after the prototype model has been thoroughly debugged! [5] Unfortunately, many system development organizations are still producing one-of-a-kind systems, for which the bottom-up approach has a number of serious difficulties:

 

Figure 5.1(b): The waterfall model of systems development

 

5.2.2 Sequential Progression

The second major weakness with the classical project life cycle is its insistence that the phases proceed sequentially from one to the next. There is a natural, human tendency to want this to be so: We want to be able to say that we have finished the systems analysis phase and that we’ll never have to worry about that phase again. Indeed, many organizations formalize this notion with a ritual known as freezing the specification or freezing the design document.

The only problem with this desire for orderly progression is that it’s completely unrealistic! In particular, the sequential approach doesn’t allow for real-world phenomena having to do with personnel, company politics, or economics. For example, the person doing the work, such as the systems analyst or designer, may have made a mistake, and may have produced a flawed product. Indeed, as human beings, we rarely do a complex job right the first time, but we are very good at making repeated improvements to an imperfect job. Or the person reviewing the work, in particular, the user who reviews the work of the systems analyst, may have made a mistake. Or perhaps the person carrying out the work associated with each phase may not have enough time to finish, but may be unwilling to admit that fact. This is a polite way of saying that, on most complex projects, systems analysis and design (and system testing, too) finish when someone decides that you have run out of time, not when you want those activities to finish!

Other problems are commonly associated with the sequential, classical project life cycle: During the several months (or years) that it takes to develop the system, the user may change his or her mind about what the system should do. During the period that it takes to develop the system, certain aspects of the user’s environment may change (e.g., the economy, the competition, or the government regulations that affect the user’s activities).

An additional characteristic of the classical project life cycle is that it relies on outdated techniques. That is, it tends to make no use of structured design, structured programming, walkthroughs, or any of the other modern development techniques. [7] But because the classical project life ignores the existence of these techniques, there is nothing to prevent the project manager from using them. Unfortunately, many programmers, systems analysts, and first-level project leaders feel that the project life cycle is a statement of policy by top-level management; and if management doesn’t say anything about the use of structured programming, then they, as mere project members and leaders, are not obliged to use nonclassical approaches.

5.3 THE SEMISTRUCTURED LIFE CYCLE

The comments in the previous section make it seem as if most IT organizations are still living in the Dark Ages. Indeed, such a characterization is unfair: Not every organization uses the classical project life. Beginning in the early 1980s, there IT industry began recognizing that formal, disciplined techniques like structured design, structured programming, and top-down implementation had some significant benefits. This recognition has led to the semistructured project life cycle shown in Figure 5.2; it shows two obvious features not present in the classical approach:

Aside from these obvious differences, there are some subtle points about this modified life cycle. Consider, for example, that top-down implementation means that some coding and testing are taking place in parallel. That certainly represents a major departure from the sequential phases that we saw in the classical life cycle! In particular, it can mean feedback between the activity of coding and that of testing and debugging. When the programmer tests the top-level skeleton version of the system, he or she may be heard to mutter, “Jeez, I had no idea that the double-precision FRAMMIS instruction worked that way!” Naturally, you can be sure that subsequent use of the double-precision FRAMMIS instruction will be quite different.

Perhaps more important, the use of top-down implementation tempts the implementors (and the systems analysts, if they haven’t abandoned the project by this time) to talk to the users after the specifications have been ceremoniously frozen. Thus, it is possible that the user will point out errors or misunderstandings in the specification; the user may even express a desire to change the specification, and if the conversation takes place directly between the user and the implementor, a change may actually be effected before the project manager knows what is happening. In short, top-down implementation often provides feedback between the implementation process and the analysis process — although this feedback exchange is not specifically shown on Figure 5.2, and although the user and the IT project manager might well deny that it is taking place!

There is one final point about the semistructured life cycle: A significant part of the work that takes place under the heading of “structured design” is actually a manual effort to fix up bad narrative specifications. You can see this by looking at Figure 5.3, which depicts the details of structured design. (Note that this figure consists of the details of process 3 in Figure 5.2.)

 

Figure 5.2: The semistructured project life cycle

In Figure 5.3, activity 3.1 (labeled CODIFY FUNCTIONAL SPECIFICATION) represents a task that designers have long had to do: translate a monolithic, ambiguous, redundant, narrative document into a useful, nonprocedural model to serve as the basis for deriving the hierarchy of modules that will implement the user’s requirements. In other words, people practicing structured design have traditionally assumed that they would be given a classical specification; consequently, their first job, as they see it, is to transform that specification into a package of dataflow diagrams, data dictionaries, entity-relationship diagrams, and process specifications.

 

Figure 5.3: Details of the design activity

This is a more difficult job than you might imagine: Historically, it has been a task carried out in a vacuum. Designers generally had little contact with the systems analyst who wrote the long narrative specification, and they certainly had no contact with the user!

Obviously, such a situation is ripe for change. Introducing structured analysis — the kind of modern systems analysis approach presented in this book — into the picture, as well as expanding on the idea of feedback between one part of the project and another, creates an entirely different kind of project life cycle. This is the structured project life cycle, which we will discuss next.

5.4 THE STRUCTURED PROJECT LIFE CYCLE

Now that we have seen the classical project life cycle and the semistructured project life cycle, we are ready to examine the structured life cycle; it is shown in Figure 5.4.

We will briefly examine the project life cycle’s nine activities and three terminators, as shown in Figure 5.4. The terminators consist of users, managers, and operations personnel; as you recall, we discussed their roles in Chapter 3. These are individuals or groups of individuals who provide input to the project team and who are the ultimate recipients of the system. They interact with the nine activities that we have shown in Figure 5.4. Each of the activities is summarized in the following sections.

5.4.1 ACTIVITY 1: The Survey

This activity is also known as the feasibility study or initial business study. Typically, it begins when a user requests that one or more portions of his or her business be automated. The major purposes of the survey activity are as follows:

 

Figure 5.4: The structured project life cycle

The survey typically occupies only 5% to 10% of the time and resources of the entire project, and for small, simple projects it may not even be a formal activity. However, even though it may not consume much of the time or resources of the project, it is a critical activity: at the end of the survey, management may decide to cancel the project if it does not appear attractive from a cost-benefit point of view.

As a systems analyst, you may or may not be involved in the survey; the user, together with appropriate levels of management, may have done it before you even hear about the project. However, for large, complex projects, the survey involves enough detailed work that the user will often ask the systems analyst to be involved as early as possible.

We will not discuss the survey in any further detail in this book. If you become involved in this activity, you may find Appendices E and C useful. For additional details, consult (Dickinson, 1981), (Gore and Stubbe, 1983), and (Yourdon, 1988).

5.4.2 ACTIVITY 2: Systems Analysis

The primary purpose of the analysis activity is to transform its two major inputs, user policy and project charter, into a structured specification. This involves modeling the user’s environment with dataflow diagrams, entity-relationship diagrams, state-transition diagrams, and the other tools presented in Chapter 4; these tools are covered in detail in Part II.

The step-by-step process of systems analysis (i.e., the subactivities of the analysis activity in Figure 5.4) is discussed in Part III. As we will see, it involves the development of an environmental model (discussed in Chapter 18) and the development of a behavioral model (discussed in Chapters 19 and 20). These two models combine to form the essential model (discussed in Chapter 17), which represents a formal description of what the new system must do, independent of the nature of the technology that will be used to implement those requirements.

In addition to the system model describing user requirements, a more accurate, detailed set of budgets and cost-benefit calculations is generally prepared at the end of the analysis Activity. This is discussed in more detail in Appendix C.

Obviously, as a systems analyst, this is where you will be spending the major part of your time. There is nothing more we need to say about the analysis activity at this point, since it is the subject of the rest of this book.

5.4.3 ACTIVITY 3: Design

The activity of design is concerned with allocating portions of the specification (otherwise known as the essential model) to appropriate processors (CPUs and/or humans) and to appropriate tasks (or jobs, or partitions, etc.) within each processor. Within each task, the design activity is concerned with the development of an appropriate hierarchy of program modules and interfaces between those modules to implement the specification created in activity 2. In addition, the design activity is concerned with the transformation of entity-relationship data models into a database design; see (Inmon, 1988) for more details.

Part of this activity will be of interest to you as a systems analyst: the development of something called the user implementation model. This model describes those implementation issues that the user feels strongly enough about that he or she is not willing to leave them to the discretion of the systems designers and programmers. The primary issues that the user is typically concerned about is the specification of the human-machine boundary and the specification of the human interface. The human-machine boundary separates those parts of the essential model that are to be carried out by a person (as a manual activity) from the parts that are to be implemented on one or more computers. Similarly, the human interface is a description of the format and sequence of inputs provided by human users to the computer (e.g., screen designs and the on-line dialogue between the user and the computer), as well as the format and sequence of outputs provided by the computer to the user. The user implementation model is described in Chapter 21.

An introduction to the process of systems design may be found in Chapter 22. Additional material may be found in (Yourdon and Constantine, 1989), (Page-Jones, 1988), (Jackson, 1975), and others.

5.4.4 ACTIVITY 4: Implementation

This activity includes both coding and the integration of modules into a progressively more complete skeleton of the ultimate system. Thus, Activity 4 includes both structured programming and top-down implementation.

As you can imagine, this is typically an activity that the systems analyst is not involved with, though there are some projects (and some organizations) where systems analysis, design, and implementation are done by the same person. This topic is discussed in more detail in Chapter 23.

5.4.5 ACTIVITY 5: Acceptance Test Generation

The structured specification should contain all the information necessary to define an acceptable system from the user’s point of view. Thus, once the specification has been generated, work can commence on the activity of generating a set of acceptance test cases from the structured specification.

Since the development of acceptance tests can take place in parallel with the activities of design and implementation, it is possible that you may be assigned to this task after you finish developing the essential model in Activity 2. Testing is discussed in more detail in Chapter 23.

5.4.6 ACTIVITY 6: Quality Assurance

Quality assurance is also known as final testing or acceptance testing. This activity requires, as its input, acceptance test data generated in Activity 5 and an integrated system produced by Activity 4.

The systems analyst could conceivably be involved in the quality assurance activity, but typically is not. One or more members of the user organization may take responsibility, or it may be carried out by an independent testing group or Quality Assurance Department. Consequently, we will not discuss the quality assurance function in any further detail.

Note, by the way, that some people refer to this activity as quality control rather than quality assurance. Regardless of the terminology, we need an activity to verify that the system exhibits the appropriate level of quality; this is what we have called quality assurance in this book. Note also that it is important to carry out quality assurance activities throughout each of the earlier activities to ensure that they have been performed at an appropriate level of quality. Thus, one would expect a QA activity to be performed throughout the analysis, design, and programming activity to ensure that the analyst is developing high-quality specifications, the designer is producing a high-quality design, and the programmer is writing high-quality code. The quality assurance activity identified here is merely the final test of the system’s quality.

5.4.7 ACTIVITY 7: Procedure Description

Throughout this book, we concern ourselves with the development of an entire system — not just the automated portion, but also the portion to be carried out by people. Thus, one of the important activities to be performed is the generation of a formal description of those portions of the new system that will be manual, as well as a description of how the users actually will interact with the automated portion of the new system. The output of Activity 7 is a user’s manual.

As you can imagine, this is also an activity in which you may become involved as a systems analyst. Though we do not discuss it further in this book, you may wish to consult books on technical writing for additional information on the writing of user manuals.

5.4.8 ACTIVITY 8: Database Conversion

In some projects, database conversion involved more work (and more strategic planning) than did the development of computer programs for the new system; in other cases, there might not have been any existing database to convert. In the general case, this activity requires, as input, the user’s current database, as well as the design specification produced by Activity 3.

Depending on the nature of the project, you may or may not become involved in the database conversion activity as a systems analyst. However, we do not discuss this activity in any greater detail in this book.

5.4.9 ACTIVITY 9: Installation

The final activity, of course, is installation; its inputs are the user’s manual produced by Actvity 7, the converted database produced by Activity 8, and the accepted system produced by Activity 6. In some cases, however, installation may simply mean an overnight “cutover” to the new system, with no excitement or fanfare; in other cases, installation may be a gradual process, as one user group after another receives user’s manuals, hardware, and training in the use of the new system and actually begin using it.

5.4.10 Summary of the Structured Project Life Cycle

It’s important that you view Figure 5.4 for what it is: a dataflow diagram. It is not a flowchart; there is no implication that all of activity N must finish before activity N + 1 commences. On the contrary, the network of dataflows connecting activities strongly implies that several activities may be going on in parallel. It is because of this nonsequential aspect that we use the word activity in the structured project life cycle, rather than the more conventional word phase. The term phase has traditionally referred to a particular period of time in a project when one, and only one, activity was going on.

There is something else that must be emphasized about the use of a dataflow diagram to depict the project life cycle: A classical dataflow diagram, such as the one in Figure 5.4, does not explicitly show feedback, nor does it show control [11]. Virtually every one of the activities in Figure 5.4 can, and usually does, produce information that can provide suitable modifications to one or more of the preceding activities. Thus, the activity of design can produce information that may revise some of the cost-benefit decisions that take place in the analysis activity; indeed, knowledge gained in the design activity may even require revising earlier decisions about the basic feasibility of the project.

Indeed, in the extreme cases, certain events taking place in any activity could cause the entire project to terminate abruptly. The input of management is shown only for the analysis activity, because analysis is the only activity that requires data from management; it is assumed, however, that management exerts control over all of the activities.

In summary, then, Figure 5.4 only tells us the input(s) required by each activity and the output(s) produced. The sequence of activities can be implied only to the extent that the presence or absence of data makes it possible for an activity to commence.

5.5 RADICAL VERSUS CONSERVATIVE TOP-DOWN IMPLEMENTATION

In the previous section, I pointed out that the structured project life cycle allows more than one activity to take place at one time. Let me put it another way: In the most extreme situation, all the activities in the structured project life cycle could be taking place simultaneously. At the other extreme, the project manager could decide to adopt the sequential approach, finishing all of one activity before commencing on the next.

It is convenient to have some terminology to help talk about these extremes, as well as about compromises between the two extremes. A radical approach to the structured project life cycle is one in which activities 1 through 9 take place in parallel from the very beginning of the project; that is, coding begins on the first day of the project, and the survey and analysis continue until the last day of the project. By contrast, in a conservative approach to the structured project life cycle, all of activity N is completed before activity N + 1 begins.

Obviously, no project manager in his right mind would adopt either of these two extremes. The key to recognize is that the radical and conservative extremes defined above are the two endpoints in a range of choices; this is illustrated in Figure 5.5. There are an infinite number of choices between the radical and conservative extremes. A project manager might decide to finish 75% of the survey activity, followed by completion of 75% of systems analysis, and then 75% of design, in order to produce a reasonably complete skeleton version of a system whose details could then be refined by a second pass through the entire project life cycle. Or, the manager might decide to finish all the survey and analysis activities, followed by completion of 50% of design and 50% of implementation. The possibilities are truly endless!

 

Figure 5.5: Radical and conservative implementation choices

 

How does a project manager decide whether to adopt a radical or conservative approach? Basically, there is no right answer; the decision is usually based on the following factors:

As you can appreciate, not one of these questions has a straight black-or-white answer. For example, one can’t ask the user of the system, in casual conversation, “By the way, how fickle are you feeling today?” On the other hand, the project manager should be able to assess the situation, based on observation, especially if he or she is a veteran who has dealt with many users and many upper-level managers before.

If the project manager judges that he’s dealing with a fickle user — one whose personality is such that he delays final decisions until he sees how the system is going to work — then the manager would probably opt for a more radical approach. The same is true if the manager is dealing with an inexperienced user, who has had very few systems built for him. Why spend years developing an absolutely perfect set of specifications only to discover that the user didn’t understand the significance of the specifications?

If, however, the manager is dealing with a veteran user who is absolutely sure of what he wants, and if the user works in a business area that is stable and unlikely to change radically on a month-to-month basis, then the project can afford to take a more conservative approach. Of course, there are a lot of in-between situations: The user may be sure of some of the business functions to be performed, but may be somewhat unsure of the kinds of reports and management information he or she would like the system to provide. Or, if the user is familiar with batch computer systems, he or she may be unsure of the impact that an on-line system will have on the business.

Besides fickleness, there is a second factor to consider: the pressure to produce immediate, tangible results. If, due to politics or other external pressures, the project team simply must get a system up and running by a specific date, then a somewhat radical approach is warranted. The project manager still runs the risk that the system will be only 90% complete when the deadline arrives, but at least it will be a working 90% complete skeleton that can be demonstrated and perhaps even put into production. That’s generally better than having finished all the systems analysis, all the design, and all the coding, but none of the testing.

Of course, all projects are under some pressure for tangible results; it’s simply a question of degree. And it’s an issue that can be rather dynamic: A project that begins in a low-key fashion with a comfortable schedule can suddenly become high-priority, and the deadline may be advanced six months or a year. One of the advantages of doing the systems analysis, design, coding, and implementation top-down is that one can stop an activity at any point and leave the remaining details for subsequent consideration; meanwhile, the top-level systems analysis that has been completed can be used to begin the top-level design, and so forth.

Yet another factor in project management is the ever present requirement, in most large organizations, to produce schedules, estimates, budgets, and the like. In some organizations, this tends to be done in a fairly informal fashion, typically because the projects are relatively small, and because management feels that any errors in estimating will have an insignificant impact on the whole organization. In such cases, one can adopt a radical approach, even though any attempts at estimating will have to be “gut-level” guesses. By contrast, most large projects require relatively detailed estimates of personnel requirements, computer resources, and so on; and this can only be done after a fairly detailed survey, analysis, and design have been completed. In other words, the more detailed and accurate the estimates have to be, the more likely the project is to follow a conservative approach.

Finally, the project manager must consider the danger of making a major technical blunder. For example, suppose that all his past experience as a project manager has been with small, one-person Visual Basic projects, which are deployed on a single desktop PC. And now, all of a sudden, he finds himself in charge of developing an Internet-based, multiprocessing distributed database e-commerce system that will process 10 million transactions a day from 50,000 terminals scattered around the world. In such a situation, one of the dangers of a radical approach is discovering a major design flaw after a large portion of the top-level skeleton system has been implemented.

He may discover, for example, that in order for his whizbang system to work, a low-level module has to do its job in 19 microseconds — but his programmers suddenly tell him that there is no way on earth to code the module that efficiently — not in Java, not in C, not even in (ugh!) assembly language. So, he must be alert to the fact that following the radical approach requires his systems analysts and designers to pick a “top” to your system relatively early in the game, and there is always the danger of discovering, down toward the bottom, that they picked the wrong top!

However, consider another scenario: The project manager has decided to build an IT system with new hardware, a new operating system, a new database management system (produced by someone other than the hardware vendor), and a new telecommunications package (produced by yet another vendor). All the vendors have impressive, glossy manuals describing their products, but the vendors have never interfaced their respective hardware and software products together. Who knows if they will work together at all? Who knows if the throughput promised by one vendor will be destroyed by the system resources used by one of the other vendors? Certainly, in a case like this, the project manager might elect a radical approach, so that a skeleton version of the system could be used to explore possible interface and interaction problems between the vendors’ components.

If the project manager is in charge of a familiar kind of system, such as her 99th payroll system, then she probably has a very good idea of how realistic her goals are. She probably remembers, from the last project, what sort of modules she’s going to need at the detailed level, and she probably remembers very clearly what the top-level system structure looked like. In such a case, she may be willing to accept the risks of making a mistake because of the other benefits that the radical approach will give her.

In summary, the radical approach is most suitable for thinly disguised research and development efforts, where nobody is quite sure what the final system is supposed to do. And it is good in environments in which something must be working on a specific date and in situations where the user’s perception of what he wants the system to do is subject to change. The conservative approach, on the other hand, tends to be used on larger projects, in which massive amounts of money are being spent and for which careful analysis and design are required to prevent subsequent disasters. However, every project is different and requires its own special blend of radical and conservative top-down implementation. To deal with the individual nature of any project, the project manager must be prepared to modify his approach midstream, if necessary.

5.6 THE PROTOTYPING LIFE CYCLE

A variation on the top-down approach discussed above has become popular in quite a few IT organizations. It is generally known as the prototyping approach and was introduced in the mid-1980s by Bernard Boar, James Martin, and others. As Boar describes it in (Boar, 1984):

In many ways, this sounds exactly like the radical top-down approach discussed in the section above. The primary difference is that the structured approach discussed throughout this book presumes that sooner or later, a complete paper model of the system will be built (i.e., a complete set of dataflow diagrams, entity-relationship diagrams, state-transition diagrams, process specifications, etc.). The model will be completed sooner with a conservative approach and later with a radical approach; but by the end of the project, there will be a formal set of documents that should live forever with the system as it undergoes maintenance and revision.

The prototyping approach, on the other hand, almost always assumes that the model will be a working model, that is, a collection of computer programs that will simulate some or all of the functions that the user wants. But since those computer programs are intended just as a model, there is also an assumption that, when the modeling is finished, the programs will be thrown away and replaced with REAL programs. Prototypers typically use the following kinds of software tools:

The prototyping life cycle proposed by Boar is shown in Figure 5.6. It begins with a survey activity, similar to that proposed in this book; this is immediately followed by a determination of whether the project is a good candidate for a prototyping approach. Good candidates for a prototyping approach are projects that have the following characteristics:

 

Figure 5.6: The prototyping life cycle

 

It is significant to note that the prototyping life cycle shown in Figure 5.6 concludes by entering the design phase of a “traditional” structured life cycle of the sort described in this book. Specifically, this means that the prototype is not intended to be an operational system; it is intended solely as a means of modeling user requirements.

The prototyping approach certainly has merit in a number of situations. In some cases, the project manager may want to use the prototyping approach as an alternative to the structured analysis approach described in this book; in other cases, she or he may wish to use it in conjunction with the development of paper models such as dataflow diagrams. Keep in mind the following points:

5.7 SUMMARY

The major purpose of this chapter has been to provide an overview of project life cycles in general. If you examine the formal project life cycle in any systems development organization, you should be able to tell whether it falls into the category of classical, semistructured, structured, or prototyping.

If your projects only allow one activity at a time, the discussion of radical top-down implementation and conservative top-down implementation in Section 5.6 may have disturbed you. This was my intent, as the major purpose of that section was to make you think about the possibility of overlapping some of the major activities in a systems development project. Obviously, it’s more difficult to manage any project that has several activities taking place in parallel — but to some extent, that always happens in every project. Even if the project manager decides that his or her people will concentrate all their efforts on one major activity at a time, there will still be a number of subactivities taking place in parallel. Multiple systems analysts will be interviewing multiple users simultaneously; various pieces of the final product of systems analysis will be in various stages of progress throughout the analysis phase. One job of the project manager is to exercise sufficient control over those subactivities to ensure that they coordinate smoothly. And in virtually every IT project, this same kind of parallel activity operated at a higher level, too; that is, despite what the organization’s formal project life cycle may have recommended, the reality is that many of the major project activities do overlap to some extent. Nevertheless, if the project manager decides to insist on a strictly sequential progression of project activities, the project life cycle presented in this book will still work.

REFERENCES

QUESTIONS AND EXERCISES

FOOTNOTES