Lifecycle Methodologies An application’s lifecycle covers its entire existence, starting with a vaguely formed idea and last- ing through design, development, deployment, and use by customers. The lifecycle may include any number of revisions and new releases, and ends when the last copy of the application is no longer used and the whole thing is relegated to history. An application’s lifecycle may last 30 years and span dozens of releases and enhancements, or it may be cut short during design when devel- opers decide the application is impractical or doesn’t adequately meet customer needs. Whether an application is intended to last a month, a year, or indefinitely, you need to manage its lifecycle. For a simple, one-use throwaway application, you may spend very little time in lifecycle management. For longer-lived applications, you may need to spend considerable effort to ensure that the application moves as smoothly as possible from the idea stage to a usable product, and that it remains usable as long as possible, or at least as long as it is needed. This chapter describes several different lifecycle methodologies that you can use to manage differ- ent kinds of applications. It discusses the strengths and weaknesses of each method, and explains which work best when developing in Visual Basic. Lifecycle Stages All lifecycle strategies use the same fundamental stages arranged in various ways. In one approach, some stages may be made longer or shorter. In another approach, some stages may be reduced practically to the point of non-existence, whereas others are repeated several times. Often, different stages blur together with one overlapping another. However, every approach uses the same basic stages to one extent or another. The following sections describe these basic stages. 06_053416 ch02.qxd 1/2/07 6:28 PM Page 15 Idea Formulation and Refinement Every application begins as an idea. Someone gets a notion about some program that might be useful. Sometimes the idea is only a vague notion, such as, “Wouldn’t it be great if we had a program that could generate reports for us?” Other times, the idea may be fully formed from the start with the idea maker knowing exactly what the program must do. Once the basic idea is discovered, it should be discussed with others who might have different insights into the desired result. As many people as possible should have a chance to provide input, making sug- gestions, additions, and improvements until you know pretty much what the application should do. Many different people might provide useful feedback in this stage of the lifecycle. People who will even- tually use the application (the customers) know what they need to accomplish. If the application will help with an existing process, the customers know how the process is currently performed. Though the application doesn’t need to follow the same approach that the customers use now, it’s worthwhile exam- ining the current methods to see if they contain any useful ideas. The supervisors and managers of the final users also often have useful insights. Even if these people won’t use the application daily, they sometimes have a higher-level view of the environment in which the application will run. They may be able to suggest ways to expand the scope of the application to handle other related tasks. They may also be able to restrict the scope of the idea to avoid duplicating other efforts that may not be obvious to the end users. It is frequently useful to ask people to daydream during this phase. Ask questions such as, “In an ideal world where anything is possible, what would you like the application to do?” The idea-makers may decide they want a telepathic interface that can guess what items are in inventory at any given moment. Ideas like this one may sound outlandish to the customers, but recent innovations in radio frequency identification (RFID) do basically that. Now is not the time to stifle creativity. Application architects, user interface designers, programmers, and developer types are often involved at the idea formulation and refinement phase, but their participation is not necessary, and it is sometimes even detrimental. These people know which application features are easy to build and which are not. In an effort to keep the ideas realistic, they may inhibit the other idea-refiners and close down useful avenues of exploration before their final payback is discovered. Though one feature may be unrealizable, discussing it may spawn other more useful ideas. It’s better to have lots of unrealistic ideas that are later discarded than to miss a golden opportunity. Happy accidents are not uncommon. Ice cream cones, chocolate chip cookies, the implantable pacemaker, penicillin, Post-it Notes, and Scotchgard were all invented by people trying to do something else (an ice cream seller ran out of bowls, Ruth Wakefield thought the chips would dissolve, Wilson Greatbatch was trying to make a device to record heartbeats, Alexander Fleming was studying nasal mucus but his samples were contaminated by mold, the glue used by Post-its was an attempt to make a better adhesive tape, and Scotchgard came from efforts to improve airplane fuels). Although you are unlikely to accidentally invent the next blockbuster three-dimensional action adven- ture game while trying to build a better billing system, you may stumble across a better way to identify at-risk customers. In a dispatch system I worked on, we added a mapping feature that let dispatchers see the routes that repair people were scheduled to follow. We thought this was a minor feature, but it turned out to be the easiest way for the dispatcher to see where everyone was at the same time, so the dispatchers used it all the time. A fortunate accident. 16 Part I: Design 06_053416 ch02.qxd 1/2/07 6:28 PM Page 16 Just as experienced developers can stifle creativity, too much executive participation can restrict the scope of the project. Eventually, the application’s lifecycle must consider real-world factors such as schedule and cost, but that can be left for later. It’s better to have too many good ideas and then pick out the best for implementation, rather than to stop at the first set of usable ideas you stumble across. In many projects, particularly those with a large existing group of users, some of the users will be gen- erally against the whole idea of the project. Sometimes this resistance is caused by inertia (“We’ve done fine without it so far”). Sometimes it’s caused by a general fear of a loss of power, respect, or control. Sometimes it’s caused by a general fear or dislike of change. If you ignore this person, he or she can become a real difficulty, spreading fear and dissent among the users. However, if you recruit this person into the development effort at the beginning, he or she can become a tremendous asset. This person is likely to see things from a different perspective than the man- agement and programming team members, and can provide valuable input. Often, this person will also become one of the project’s greatest proponents. Once the other users see that this person has been won over, they often follow. One person who should definitely be consulted during idea development is the idea’s originator. Even if the idea changes greatly during refinement, it’s worth keeping this person involved, if for no other rea- son than to make the idea seem appreciated. People with usable ideas are important, and if you yank the project away, you may never get another idea from this person again. Eventually, you may run across someone who is so committed to an original idea that he or she won’t allow the idea to change and grow. This person keeps pulling the idea back to its earliest form no matter how much others try to stretch and improve the idea. I’ve seen this on several projects. Often the perpe- trator has recently learned about a new concept or technique, and is determined to use it no matter what. In some cases, you can civilly explain to the person that the idea has outgrown the original concept and that it is time to move on. Occasionally, you may need to appeal to a higher level of management to make a decision stick. At the end of the idea formulation and refinement stage, you do not need a schedule, cost estimates, an architectural design, a user interface design, or anything else that is directly related to writing code. Those all come later. Another danger at this stage is the person who wants to rush headlong into development. Managers often want to move quickly to produce something they can hold up to show progress. Developers often want to hurry along to their favorite part of the lifecycle: development. Although you eventually need to actually build something, it’s a mistake to end the idea stage too early. If you dash off into development with the first workable idea, you may be missing out on all sorts of wonderful opportunities. At this point, you should have a pretty good idea of the application’s goals. The list of goals may be very short, as in, “Pull data from a specific database and enter it into an Excel workbook.” The list may be extremely large, containing hundreds of “must haves,” “nice to haves,” and “wild wishes.” The next stage, requirements gathering, refines these possibly vague ideas and makes them more concrete and measurable. Team Building This isn’t really a stage in an application’s lifecycle. Rather, it’s an ongoing activity that should start early and last throughout the project. Ideally, you should start building a solid team of supporters during idea formulation and refinement, and build on that core as the lifecycle progresses. 17 Chapter 2: Lifecycle Methodologies 06_053416 ch02.qxd 1/2/07 6:28 PM Page 17 This core team should include people who will be involved in all phases of the lifecycle. It can include customers, designers, developers, management, and customer support people, although you may need to rein in some of these people during different stages. For example, during the idea formulation and refinement phase, developers should not dwell on what is easy to program, and managers should not focus exclusively on time and expense. Two people who are particularly useful starting with the very earliest phases of the project lifecycle are a customer champion and a management patron. The customer champion represents the final users of the application. Often, this person is (or was) one of those users, or is their direct supervisor. This person understands the needs of the users inside and out, and can make informed decisions about which features will be most useful in the finished application. This person must have the respect of the other users, so any decisions he or she makes will be accepted. This person should be able to sign off on the project and say that it has officially achieved its goals. It is also extremely helpful to have a customer champion with an easygoing attitude of give and take. During later stages of the lifecycle, you may discover that some features are much harder to implement than you had originally planned. At that point, it’s tremendously valuable to have a customer champion who understands the realities of software development, and who knows that insisting on sticking to the original design may mean cost and schedule slips. The best attitude here is one of, “The details don’t matter, as long as the finished application lets the users do their jobs.” People who have played the role of customer champion before often understand this give-and-take approach. If your champion doesn’t have experience with development, you can start laying the ground- work for this type of interaction during the idea formulation and refinement phase. Use phrases such as, “We’ll see how hard that would be when we get into the design phase” and “If we start running out of time, perhaps we can defer that feature until release two.” Customers familiar with the traditional Waterfall lifecycle model described later in this chapter may have more trouble with this concept. In that model, requirements are laid out early and exactly in the cycle, and they must be followed strictly with little or no room for negotiation. A devoted Waterfall enthusiast can make development difficult. Fortunately, most people who are really dedicated to their jobs don’t care about the details too much as long as they can do their jobs well. Most customers don’t insist on sticking to a plan long after the plan has proven flawed (although I’ve met several managers with that attitude). The management patron is someone with enough influence in the company to ensure that the project moves forward. This person doesn’t necessarily need to be involved in the project’s day-to-day deci- sions, but should be aware of the project’s progress and any high-level issues that may need to be resolved (such as the need for staff, budget, and other resources). Practically anyone with decision-making power can play this role, depending on the scope of the appli- cation. For small projects that will be used by only one or two users, I’ve worked with patrons who were first-tier managers with only one or two direct reports. For applications that would affect hundreds of users and thousands of customers, I’ve worked with corporate vice presidents who oversaw tens of thousands of employees. On a particularly interesting football-training project, Hall of Famer Mike Ditka was one of our management patrons. 18 Part I: Design 06_053416 ch02.qxd 1/2/07 6:28 PM Page 18 Two types of people that you may want to avoid for the role of patron are the soon-to-be-ex-managers and people with lots of enemies. If management changes, the new management may not have the same commitment to your project as your previous patron. Sometimes, new management may cancel or weaken support for a project to dis- credit the previous management, to provide resources for new pet projects, or just to make a change. Unless you have a strong customer champion, keeping the project on track may be difficult. Of course, you probably won’t know if your company is about to be sold and a new management team installed, but if you know that a particular supervisor is up for retirement in six months, you might want to iden- tify possible replacements and decide whether the transition is likely to be smooth. If your management patron has lots of enemies, you may be in for an arduous project lifecycle. Political infighting can make it difficult to attract and keep good team members, obtain needed resources, or gain and keep customer confidence. I worked on one project with particularly nasty politics. Corporate vice presidents were slugging it out for control of this application and control of software development in general. At times, developers faced threats and blatant attempts to sabotage the code. Fortunately, we had a strong customer advocate and good customer buy-in, so the project was eventually a success, but it was a long, hard battle to keep the project on track. To avoid this sort of situation, you must take a look at the environment in which the potential patron works. If it’s a hostile environment full of political infighting, you may want to look for another manage- ment sponsor. Battling heroically against all odds to bring the customers the best possible application despite adversity brings a certain satisfaction after the fact, but it can make for a pretty grim couple of years during development. Requirements Gathering After the idea has had some time to ferment, you need to take a closer look at it and specify its features more precisely. You need to decide exactly what the features you have identified mean. You need to describe them with enough detail so that developers can understand what is necessary. You also need to define the application’s requirements with enough precision to determine whether the finished application has met its goals. The requirements must include specific measurable goals and mile- stones that you can use to unambiguously decide whether the application has achieved its objectives. For example, the following statement is a measurable goal: “When a user modifies a customer record, the program will make an ‘audit trail’ record storing the date and time, the user’s name, the customer ID, and the type of data changed. Supervisors (and only supervisors) will be able to view these records by date, user, and type of change.” This is a nice concrete statement that you can easily verify by trying it out in the program. Many projects bog down at the finish while developers and customers bicker over whether the applica- tion meets its goals. This is particularly a problem in projects that follow the Waterfall lifecycle model described later in this chapter because that model makes changing the goals difficult. During the project, if you discover that the goals are outdated, or that they do not solve a useful problem, it may be difficult 19 Chapter 2: Lifecycle Methodologies 06_053416 ch02.qxd 1/2/07 6:28 PM Page 19 to adapt and revise the application’s design. That can lead to fighting between the developers who did what they thought they were supposed to do (implement the original requirements) and customers whose needs are not satisfied by the original requirements. Other common requirements statements specify desired performance. For example, “When the user requests a customer order for processing, the program will display the next order within five seconds.” This statement is reasonable and measurable, but requires a bit more clarification. What may be possible with a few users on a fast network may be impossible if the network is congested and hundreds of users try to access the database at the same time. A more precise requirement should specify the system’s load and allow for some fluctuation. For exam- ple, “When the user requests a customer order for processing, the program will display the next order within five seconds 95 percent of the time with up to 100 users performing typical duties.” This may still be difficult to test, but at least it’s fairly clear. I worked on one project where performance testing was performed by a group of 20 users in the same room. The test leader had every user type in exactly the same data at the same time and press the Enter key simultaneously. They quickly learned that this was not a realistic test because it is very unlikely that every user would want to access the same customer record at exactly the same time. More realistic tests used fake jobs to simulate real work with users working jobs and requesting new ones at their own paces. One useful method for characterizing requirements is to build use cases. These are scripted scenarios that portray a user trying to work through a common task. For example, an emergency dispatch system might include a use case where the user takes a phone call from someone reporting a house fire, records necessary information, reviews and possibly overrides recommendations for the units to dispatch, and dispatches the units. You can find some example use cases at www.objectmentor.com/publications/usecases.pdf. At this stage, the requirements should not specify a solution to the use cases. In fact, a use case should specify as little about the solution as possible. It should not indicate how the user answers the phone, records necessary information, views recommended units, and approves the dispatching selection. It should just indicate the things that must happen, and leave the details open for later design. During the requirements gathering stage, you should also categorize ideas by their degree of impor- tance. At a minimum, you should make a list of “must haves,” “nice to haves,” and “wild wishes.” You may even have a category of “don’t need” for items that you’ve decided are really not such great ideas after all. Depending on the lifecycle model you follow, items may move between these categories during later stages of development. You may find an idea that you put in the “wild wishes” category is more impor- tant than you thought. Or, changes in the users’ rules and regulations might make a “nice to have” fea- ture mandatory. This phase is one point where various lifecycle approaches can differ. The best strategy is to avoid any actual design at this stage and focus on results. Rather than specifying exactly how the application should perform its actions, describe the results of those actions and what the actions will accomplish. Instead of designing a customer entry form, just say there will be a customer entry form where the user can enter customer data with links to order and payment information. Leave the details for the following design phases. 20 Part I: Design 06_053416 ch02.qxd 1/2/07 6:28 PM Page 20 This approach works particularly well with iterative approaches where everyone expects changes to the design. It doesn’t usually work as well with stricter Waterfall models where people expect every last detail of the application to be chiseled in stone before any of the work begins. With that approach, requirements gathering sometimes turns into a search for an exact specification. Avoid this as long as possible. That kind of specification makes explicit and implicit assumptions about the design, and you haven’t started the design yet. If your development environment requires that you begin a specification at this point, begin the design, too, either formally or informally. Try to do enough design work to support your decisions in the specifi- cation. If you don’t have time to design the features properly, you may be able to reuse ideas from exist- ing applications. If you’ve written an order-taking form before, reuse the ideas that worked well in that application. While you may not have time to perform a detailed design analysis, you can piggyback on the analysis you used for the previous application. Feasibility Analysis Feasibility analysis occurs at two levels. At a higher level, you must decide whether the project as a whole can succeed. At a lower level, you must decide which features should be implemented. High-Level Feasibility Analysis At a high level, it is the process of deciding whether the project as a whole is possible given your time, staffing, cost, and other constraints. At this scale, the goal is to determine whether the project will be possible and worthwhile as quickly as possible. If the project is not viable, you want to know that as soon as possible so you can bail out without spending more time and money on it than necessary. It’s much cheaper to cancel a project after a 1-month feasibility study involving 3 people than it is to can- cel a project that has been running with 20 staff members for 2 years. If people cost about $100,000 per year, then the difference is spending $25,000 on a feasibility study versus wasting $4 million. In this sense, feasibility analysis is a bit like poker. Many people think the goal in poker is to get the best hand possible. The true goal is to decide whether you have the winning hand as quickly as possible. If you are going to lose, you need to get out quickly before you bet a lot of money in the pot. If you think you are going to win, you want to drag the betting out as long as possible to get as much money in the pot as you can. Because the goal of high-level feasibility analysis is to determine the overall fitness of the project as soon as possible, you must start working on it as soon as you can. If the ideas you come up with during a month of idea formulation and refinement are not worth expending some effort, cancel the project, write off the $25,000 you invested studying the ideas, and use the $3.975 million you saved on another project. If the refined ideas you develop during a month of requirements gathering no longer seem useful, again abandon the project, forget the $50,000 you’ve spent so far, and invest the $3.95 million you saved on something else. (You can see from this example that the sooner you cancel the project the more time and money you save.) As time and the project move on, you should gain an increasingly accurate idea of whether the project as a whole is viable. After doing some preliminary design work, you should have an idea of how compli- cated the application is. It’s usually around this time that most organizations make a final decision about whether to commit to the project. Beyond this point, the amount of money invested in the application becomes large enough that people get in trouble and careers can be ruined if they admit they made a mistake and suggest that the project be canceled. 21 Chapter 2: Lifecycle Methodologies 06_053416 ch02.qxd 1/2/07 6:28 PM Page 21 After making a detailed high-level design, you should have at least some guesses about how many peo- ple you will need and how long the project will take. One project that I worked on should have been canceled long before it actually was. Part of its design turned out to be significantly more complicated than expected. After wasting a bit under a year working on the application, several quick changes in management lead to the project being mothballed. It was a small project and didn’t last too long, so it probably wasted less than $500,000. If we had realized that the project was unfeasible sooner, we might have been able to change the design and finish six months late and $250,000 over budget, or we could have canceled the project and saved six months and $250,000. For an even more dramatic example, a friend of mine once worked on a huge multi-billion dollar space- craft project involving hardware and software. At some point, most of the participating engineers realized that it was unfeasible. Unfortunately, the company had already invested a lot of money in it and was thoroughly committed at a high level. The project manager suggested that the project was impossible and was promptly fired. After a few months, the new project manager reached the same conclusion, made the same suggestion, and suffered the same fate. This loop repeated a couple more times before the project’s failings were too large even for upper management to ignore and it finally went under. Had the company listened to the first project manager, who knows how much time and money they could have saved. With better information about how hard the project is as time goes on, you can make a more informed decision about whether to continue. Until the point of full commitment, the result of your analysis should either be “cancel the project” or “continue until we have more information.” Try to delay full commitment until you are absolutely certain that the project can succeed. A project was a rewrite of an enormous application that had been written and modified over many years in several different versions of Visual Basic. The rewritten version was poorly designed, and the new features that were added provided only a small benefit. I don’t know how much money was spent on this rewrite, but I wouldn’t be surprised to learn it was $6 million or more. Furthermore, I predict another rewrite will be necessary, hopefully with a greatly improved design, within the next few years as the company transitions to a new development platform. Even a year into this project, the project team could have seen the clues that the new development plat- form was coming, canceled the first rewrite, and invested $3 million in savings on moving to the new platform a bit sooner. The users would have lost only relatively small enhancements and gotten the final, improved version of the system a year sooner. Low-Level Feasibility Analysis At a lower level, you must determine which features can and should be implemented given your time, cost, and other constraints. After the requirements-gathering phase, you should have a good idea of what the project’s features are and how much benefit they will provide. You should know which features fall into the “must have,” “nice to have,” and “wild wish” categories. Now is the time for quick negotiation with your customer champion to decide which features make it into the official requirements specification, which are deferred until a later release, and which are dropped completely. 22 Part I: Design 06_053416 ch02.qxd 1/2/07 6:28 PM Page 22 To help your customer champion understand the tradeoffs, you should phrase levels of difficulty in terms of costs and exchanges. For example, “We can give you this feature, but it will delay release by six months.” Or, “If we implement this feature and keep our original schedule, then we will have to defer this other feature.” Or, “We can separate the development of this piece from the rest of the project and hire four additional developers for six months (at a cost of $200,000).” Then it’s up to the customer champion to decide which options are acceptable to the users. Initially, you may have only a vague idea about how difficult the various features are to implement. As is the case with high-level feasibility analysis, you will have a better understanding of how difficult dif- ferent features are to build as time marches on. Also as is the case with the high-level analysis, it is best to keep your options open as long as possible, rather than committing to specific features, until you have a decent idea about how difficult they will be to build. If you discover that a feature is harder (or easier) to provide than you originally estimated, that’s the time when having a customer champion with an easygoing give-and-take nature is invaluable. It’s also when iterative lifecycle methodologies described later in this chapter are most useful, and the Waterfall model brings the most pain. High-Level Design During high-level design, architects lay out the application’s main systems and begin to outline how they interact with each other. They describe main groups of functions, such as order entry, billing, customer management, reporting, database processing, Web Services, inter-process communication, and so forth. The high-level design should not specify how the systems work, just what they do. To the extent that you understand them, you can also sketch out the interactions among the systems and some of the fea- tures that they will implement. For example, experience with previous applications may suggest a par- ticular set of tables that you will want to use in storing customer data in a database. Or, if you know that the application will need to pull files from FTP servers on the Internet, you may want to tentatively spec- ify the FTP routines that you used on a previous project. The high-level design generally should not specify particular classes. For example, it can say, “We’ll have a tax form where the user can fill in customer data describing their fuel tax payments and usage,” but it wouldn’t define a Customer class and dictate how that class should store fuel tax information. It also would not lay out the exact user interface for this form. Both of those tasks come later. At this stage, it is extremely important that you make the application’s different systems as decoupled as you can. There should be as little interaction among these major systems as possible, while still getting the job done. Every interface between two systems is a point where the teams building the systems must communicate, negotiate, and debug differences in code. If the systems have only a few well-defined interactions, the teams can work through them relatively quickly. If many of the systems interact in lots of different ways, the teams will spend a considerable amount of time trying to understand each other’s code, negotiating (sometimes arguing) over interfaces, and debugging those interfaces, leaving less time to actually write code. A good decoupled design lets a developer focus on the code within the system he or she is developing, while spending a minimum of time studying the details of the other systems. 23 Chapter 2: Lifecycle Methodologies 06_053416 ch02.qxd 1/2/07 6:28 PM Page 23 Lower-Level Design During successively lower levels of design, developers add additional detail to the higher-level designs. They start sketching out exactly what is needed to implement the high-level systems that make up the application. While building the lower-level designs, you should be able to flesh out the interfaces between the appli- cation’s systems. This is the real test of whether the higher-level designs defined cleanly separated major systems. If the systems must interact in many poorly defined ways, you may need to step back and reconsider the high-level design. If two systems require a large number of interactions, then perhaps they should be combined into a single system. At the same time, you should try to make each system small enough so that a team of four or five devel- opers can implement it. If a system will require more than five developers, you should consider breaking it into two or more subsystems that separate teams can implement independently. Some of the design patterns described in Chapter 7, “Design Patterns,” can help you separate closely coupled systems. For example, the mediator pattern helps separate two closely related systems so devel- opers can work on them separately. Instead of having code in the one system directly call code in the other, the code calls methods provided by a mediator class. The mediator class then forwards requests to the other system. Figure 2-1 shows the situation graphically. The top of the figure shows two systems that are tied closely together. On the bottom, a mediator sits between the systems to loosen the coupling between them. Figure 2-1: The mediator design pattern can help decouple two closely related systems. Note that the mediator in Figure 2-1 complicates the design somewhat. In this example, the mediator doubles the number of arrows required, so the amount of communication in the application has increased. The reason this design can help is that the mediator isolates the two systems from each other so that the code in one doesn’t need to know the details of the code in the other. This lets the two sys- tems evolve independently and lets developers work on them separately. System 1 System 2 System 1 System 2 Mediator Mediator 24 Part I: Design 06_053416 ch02.qxd 1/2/07 6:28 PM Page 24 [...]... Unit Routine Routine Routine Routine Routine Figure 2- 2 : Routine, unit, and system testing exercise paths of execution at different levels 28 06_053416 ch 02. qxd 1 /2/ 07 6 :28 PM Page 29 Chapter 2: Lifecycle Methodologies Even if you perform extensive lower-level testing, however, system-level testing is still necessary While most bugs have small scope and are contained within a single routine, some only... Figure 2- 9 shows this model graphically Each trip through the Design- Implementation-Testing cycle may or may not produce a new version of the application Idea Formulation Requirements Gathering Deployment and Support Pr ot ot yp e 1 Design Implementation Testing Prototype 2 e yp o ot o ot P Pr Deployment and Support 3 Deployment and Support Figure 2- 9 : In Staged Delivery, each trip through the Design- Implementation-Testing... time on routine and unit testing 36 06_053416 ch 02. qxd 1 /2/ 07 6 :28 PM Page 37 Chapter 2: Lifecycle Methodologies Idea Formulation Requirements Gathering Design Implementation Testing Deployment and Support Version 1 Deployment and Support Version 2 Deployment and Support Version 3 Idea Formulation Requirements Gathering Design Implementation Testing Idea Formulation Requirements Gathering Design Implementation... Implementation Testing Figure 2- 4 : You can use multiple serial Waterfalls to model multiple releases 37 06_053416 ch 02. qxd 1 /2/ 07 6 :28 PM Page 38 Part I: Design Overlapping Waterfall In practice, the different phases of development in the Waterfall model often overlap, as shown in Figure 2- 5 Idea Formulation Requirements Gathering Design Implementation Testing Deployment and Support Figure 2- 5 : The phases in a... ideas, and then moves on to requirements gathering The team then writes requirements documents that completely specify the system and moves on to the design phase only after the system is completely described Based on the specification, 34 06_053416 ch 02. qxd 1 /2/ 07 6 :28 PM Page 35 Chapter 2: Lifecycle Methodologies the project architects make the application’s high- and lower-level designs When the design. .. additional changes to the design You need to discard the design for the hash table and design a priority queue You’ll need to change both the high- and low-level designs You’ll also probably need to update the user interface design to let the user interact with the new queue The new design will also impact other subsystems that were supposed to add and remove items from the hash table The design for those subsystems... application 41 06_053416 ch 02. qxd 1 /2/ 07 6 :28 PM Page 42 Part I: Design Figure 2- 7 shows the process graphically Idea formulation and requirements gathering work as usual You then enter a loop, repeatedly designing, implementing, and testing better and better versions of the prototype until the final prototype is good enough for the users to install Idea Formulation Requirements Gathering Design Implementation... the ability to handle uncertain or changing requirements I’ve also seen the spiral drawn from the inside out Idea formulation and requirements gathering feed into the middle of the spiral, and successive development cycles move farther and farther out, implying that each prototype is bigger and more complete than the previous one 42 06_053416 ch 02. qxd 1 /2/ 07 6 :28 PM Page 43 Chapter 2: Lifecycle Methodologies...06_053416 ch 02. qxd 1 /2/ 07 6 :28 PM Page 25 Chapter 2: Lifecycle Methodologies System 1 can make calls to the mediator in more or less whatever way it wants, and those calls need not change, even if the code in System 2 that eventually handles the calls changes Similarly, System 1 can handle calls by the mediator in a consistent way, and hopefully remain unchanged even if the code in System 2 that starts... into account Handling fuzzy and changing requirements is usually extremely painful with the Waterfall model 44 06_053416 ch 02. qxd 1 /2/ 07 6 :28 PM Page 45 Chapter 2: Lifecycle Methodologies De D sig esig n n nemelpm noitat I Tes oitatnemelpm 2 n in t g Prototype I e Tes oitatn melpmI1 n ting Prototype Deployment and Support Deployment and Support Idea Formulation Requirements Gathering Figure 2- 1 0: You can . systems. 23 Chapter 2: Lifecycle Methodologies 06_053416 ch 02. qxd 1 /2/ 07 6 :28 PM Page 23 Lower-Level Design During successively lower levels of design, developers add additional detail to the higher-level. deferred until a later release, and which are dropped completely. 22 Part I: Design 06_053416 ch 02. qxd 1 /2/ 07 6 :28 PM Page 22 To help your customer champion understand the tradeoffs, you should. lifespan. 25 Chapter 2: Lifecycle Methodologies 06_053416 ch 02. qxd 1 /2/ 07 6 :28 PM Page 25 Implementation is an important part of application development, and for programmers, at least it’s usu- ally