What You'll Learn in This Hour:
Why a development process is important
Why older development methodologies are inappropriate for today's systems
The GRAPPLE development process
How to incorporate the UML into the process
Now that you've learned about the UML's diagrams and structure, it's almost time for the rubber to meet the road. The UML is a wonderful tool, but you don't use it in isolation. It's intended to fuel software development. In this hour, you're going to learn about development processes and methodologies as a vehicle for understanding the use of the UML in a context.
Imagine this situation: Your organization needs a new computer-based system. New hardware and software will result in a competitive advantage, and you want that advantage. Development has to start, and soon.
You're the one who made the decision to build the new system. You've put a development team in place, complete with a project manager, modelers, analysts, programmers, and system engineers. They're champing at the bit, anxious to get started.
You are, in other words, a client. What work-products will you expect to see from the team? How do you want the project manager to report to you? At the end, of course, you'll want the system up and running. Before that, you'll want indications that the team understands the problem you're trying to solve and clearly comprehends your vision of how to solve it. You'll want a look at their solution-in-progress, and you'll want an idea of how far along the team is at any point.
These are common concerns for any client and for any system development project that involves an appreciable amount of time, money, and personpower.
You won't want the development team to rush off and start coding. After all, what will they code? The development team has to proceed in a structured, methodical way. The structure and nature of steps in a development effort are what I mean by a methodology.
Before they begin programming, the developers have to fully understand the problem. This requires that someone analyze your needs and requirements. After that analysis is done, can coding start? No. Someone has to turn the analysis into a design. Coders then work from the design to produce code, which, after testing and deployment, becomes a system.
This oversimplified look at a sequence of segments of effort might give you the idea that the segments should neatly occur in clearly defined chunks of time, one right after the other. In fact, early development methodologies were structured in that way. Figure 15.1 shows one way of thinking that was highly influential for a number of years. Dubbed the waterfall method, it specifies that analysis, design, coding, and deployment follow one another like activities in an activity diagram: Only when one is complete can the next one begin.
This way of doing things has some ominous overtones. For one thing, it encourages compartmentalization of effort. If an analyst hands off an analysis to a designer, who hands off a design to a developer, chances are that the three team-members will rarely work together and share important insights.
Another problem with this method is that it minimizes the impact of understanding gained over the course of a project. (Make no mistake: Understanding evolves during the life of a project—even after an analysis has turned into a design.) If the process can't go back and revisit earlier stages, it's possible that evolving ideas will not be utilized. Trying to shoehorn new insights into a project during development is difficult at best. Revisiting an analysis and a design—and then incorporating an evolved understanding—provides a much better chance of success.
In contrast to the waterfall method, contemporary software engineering stresses continuing interplay among the stages of development. Analysts and designers, for example, go back and forth to evolve a solid foundation for the programmers. Programmers, in turn, interact with analysts and designers to share their insights, modify designs, and strengthen their code.
The advantage is that as understanding grows, the team incorporates new ideas and builds a stronger system. The downside (if there is one) is that some people like closure and want to see intermediate stages come to a discrete end. Sometimes, project managers like to be able to say something to clients like, “Analysis is complete, and we're going into design. Two or three days of design, and we'll begin coding.”
That mentality is fraught with danger. Setting up artificial barriers between stages will ultimately result in a system that doesn't do exactly what a client wants.
The old way fosters another problem: It's usually the case that adherents of the waterfall method allot the lion's share of project time to coding. The net effect of this is to take valuable time away from analysis and design.
In the early years of computer programming, one person could analyze a problem, come up with a solution, and write a program. In the early years of building homes (back when the world was flat), one person could build a pretty serviceable home, too.
Today it's a different story. In order to develop the kinds of complex systems today's business world demands, a team approach is necessary. Why? Knowledge has become so specialized that one person can't know all the facets of a business, understand a problem, design a solution, translate that solution into a program, deploy the executable version onto hardware, and make sure the hardware components all work together correctly.
The team has to consist of analysts to communicate with the client and understand his or her problem, designers who construct a solution, programmers who code the solution, and system engineers who deploy the solution. A development process has to take all these roles into account, utilize them properly, and allot the proper amount of time to each stage of the effort. The process must also result in a number of work-products that indicate progress and form a trail of responsibility.
Finally, the process must ensure that the stages of the effort aren't discrete. Instead, feedback must take place among the stages to foster creativity and increase the ease of building new ideas into the effort. Bottom line: It's easier to make a change to the blueprint and then make the change to the house, rather than change the house while you build the physical structure.
In arriving at a process, the temptation is to construct a set of stages that result in massive amounts of paperwork. Some commercially available methodologies do this, leaving project managers to fill out endless forms. The paperwork becomes an end unto itself.
One reason for this is the erroneous idea that a one-size-fits-all methodology is possible. Every organization is unique. An organization has its own culture, standards, history, and people. The development methodology that's right for a multinational conglomerate will probably fail in a small business, and vice versa. In trying to shoehorn a methodology to fit an organization, the misconception is that massive paper trails will somehow help.
So here's the challenge. A development process must
Ensure that the development team has a firm understanding of the problem it's trying to solve
Allow for a team that consists of an array of roles
Foster communication among the team members who occupy those roles
Allow for feedback across stages of the development effort
Develop work-products that communicate progress to the client, but eliminate superfluous paperwork
Oh, by the way, it would be a good idea if the process produces a finished product within a short timeframe.
Process and Methodology
You'll notice that I use the words process and methodology interchangeably. Although it's possible to find some differences between the two, I'd rather not split hairs. It's been my experience that the word methodology has acquired a bad odor in some organizations. Mixing process into the discussion, I feel, somewhat alleviates the discomfort.
To meet the multifaceted challenge of creating a development process, I present the Guidelines for Rapid APPLication Engineering (GRAPPLE). The ideas within GRAPPLE aren't original. They're a distillation of the ideas of a number of others. The Three Amigos created the Rational Unified Process, and prior to that, each Amigo had his own process. The ideas in those processes are similar to GRAPPLE. Steve McConnell's book, Rapid Development (Microsoft Press, 1996), contains a number of best practices that pertain to . . . well . . . rapid development.
The first word in GRAPPLE's name, Guidelines, is important: This isn't a methodology written in stone. Instead, it's a set of adaptable, flexible ideas. Think of it as a simplified skeleton of a development process. I present it as a vehicle for showing the UML within a context. With a little tweaking here and there, GRAPPLE can work in a variety of organizations (but maybe not all). It leaves room for a creative project manager to add his or her own ideas about what will work in a particular organization and to subtract the built-in steps that won't.
A Little Context
Before I discuss GRAPPLE, here's a question you might be asking: “Why are you telling me about this in a book about the UML?”
Here's the answer: If I don't tell you about a development process and provide a context for using the UML, all I've done is show you how to draw diagrams. The important thing is to show why and when you'd use each one.
In Part II, “A Case Study,” you'll go through a test case that applies GRAPPLE and the UML.
GRAPPLE consists of five segments. I use segments rather than stages to get away from the idea that one “stage” has to be complete before the next one starts. (I resisted the temptation to call them pieces. “Five easy pieces” was just too cute.) Each segment, in turn, consists of a number of actions. Each action produces a work-product, and each action is the responsibility of a particular player.
In many cases, the project manager can combine the work-products into a report that he or she presents to the client. The work-products, in effect, serve the same purpose as a paper trail without bogging down the project in paperwork.
To adapt GRAPPLE, a project manager could add actions to each segment. Another possibility is to drill down a level deeper and subdivide each action into subactions. Still another possibility is to reorder the actions within each segment. The needs of an organization will dictate the course to follow.
GRAPPLE is intended for object-oriented systems. Thus the actions within each segment are geared toward producing work-products of an object-oriented nature.
The segments are
Requirements gathering
Analysis
Design
Development
Deployment
This acronymizes nicely to RADDD, or RAD3. After the third segment, the project manager combines the work-products into a design document to give to the client and the developers. When all the RAD3 segments are complete, all the work-products combine to form a document that defines the system.
Before all these segments start, you assume the client has made a business case for the new system. You also assume the members of the development team, particularly analysts, have read as much relevant documentation as possible.
Let's examine each segment more closely, with an eye toward showing the parts of the UML that fit into each one.
If you were to try and assign a relative importance to each segment, this one is a good candidate for numero uno. If you don't understand what the client wants, you'll never build the right system. All the use case analysis in the world won't help if you don't understand the essentials of the client's domain and the problem he or she wants you to solve.
It's a good idea to begin the development effort by gaining an understanding of the client's business processes, specifically the one(s) you're trying to enhance with the proposed system. To gain this understanding, an analyst typically interviews the client or a knowledgeable client-designated person and asks the interviewee to go through the relevant process(es) step-by-step.
An important outcome is that the analyst gains a working vocabulary in a subset of the client's terminology. The analyst uses this vocabulary when interviewing the client in the next action.
The work-product for this action is an activity diagram or a set of activity diagrams that captures the steps and decision points in the business process(es).
This action is like the example of the conversation with the basketball coach from Hour 3, “Working with Object-Orientation.” It can take place during the same session as the preceding action. The objective is to gain as solid an understanding as possible of the client's domain. Note that this action and the preceding one are about concepts; they're not about the system you're going to build. The analyst has to get comfortable in the client's world, as he or she will ultimately be the client's emissary to the development team.
The analyst interviews the client with the goal of understanding the major entities in the client's domain. During the conversation between the client and the analyst, another team member takes notes (optimally, on a laptop computer equipped with a word processing package), and an object modeler constructs a high-level class diagram. If you can have more than one team member take notes, by all means do so.
The object modeler listens for nouns and starts by making each noun a class. Ultimately, some nouns will become attributes. The object modeler also listens for verbs, which will become operations of the classes. At this point, a computer-based modeling tool becomes extremely valuable.
The work-product is a high-level class diagram and a set of meeting notes.
To Tape or Not to Tape?
Should you tape these interviews or should you just rely on your meeting notes? This is a question that crops up frequently. When you tape an interview, the temptation is to not listen as closely or not take notes as rigorously. (After all, you can always listen to the tape later.) If you do decide to tape, my advice is to forget the tape recorder, and take notes as though the recorder weren't there.
Tape recording can be a useful tool when you're training a new object modeler. An experienced modeler can compare the new modeler's diagrams with the taped discussion and check for completeness.
Seventeenth-century poet John Donne wrote, “No man is an island, entire of itself.” If he were writing today, it would have been “No person is a land-mass surrounded entirely by water, entire of him- or herself.” He might also have written “No system is an island . . . ,” and so on.
Donne would have been right on all counts. Today's business systems don't typically emerge in vacuums. They have to work with others. Early in the process, the development team finds out exactly which systems the new system will depend on and which systems will depend on it. A system engineer takes care of this action, and produces a deployment diagram as the work-product. The diagram shows the systems as nodes, with lines of internode communication, resident components, and intercomponent dependencies.
This one is extremely important. You might have guessed that because it has requirements in its name. In this action, the team goes through its first Joint Application Development (JAD) session. Several more occur throughout the course of GRAPPLE.
A JAD session brings together decision-makers from the client's organization, potential users, and the members of the development team. A facilitator moderates the session. The facilitator's job is to elicit from the decision-makers and the users what they want the system to do. At least two team members should be taking notes, and the object modeler should be refining the class diagram derived earlier.
The work-product is a package diagram. Each package represents a high-level area of system functionality (for example, “Assist with customer service”). Each package groups a set of use cases (for example, “Retrieve customer history” and “Interact with customer”).
The complexity of the system determines the length of the session. It's almost never less than half a working day, and it can last as long as a full workweek. The client's organization has to make a commitment to invest the necessary time.
Why use a JAD session to develop the system requirements? Why not interview each individual? As you'll recall, I said the last part of the challenge for a development process is to turn out a system in a short timeframe. Individual interviews can take weeks or even longer, if people's schedules conflict. Waiting for individual interview results eats up time and, with it, the potential competitive advantage of quickly completing the system. Individual interviews will probably contain conflicting views, and more time gets wasted as the team tries to resolve the conflicts. Grouping everyone together creates a whole that exceeds the sum of the parts, and the interplay among JAD participants results in a symbiosis that's beneficial for everybody.
When the team finishes all the Requirements actions, the project manager presents the results to the client. Some organizations might require the client's approval at this point in order for development to proceed. Other organizations might require a cost estimate based on the results. The work-product, then, will vary according to the organization.
In this segment, the team drills down into the results of the Requirements segment and increases its understanding of the problem. In fact, parts of this segment begin during the Requirements segment, as the object modeler begins refining the class diagram during the Requirements JAD session.
This action is a high-level use case analysis. In a JAD session with potential users, the development team works with the users to discover the actors who initiate each use case from the Requirements JAD session, and the actors who benefit from those use cases. (An actor, remember, can be a system as well as a person.) A facilitator moderates the session, and two team members take notes. After a few projects, the facilitator for this session will likely evolve into a use case analyst.
The team also tries to develop new use cases. The work-product is a set of use case diagrams that shows actors and any stereotyped dependencies («extends» and «includes») between use cases.
In this action, the development team continues its work with the users. The objective is to analyze the sequence of steps in each use case. This JAD session can be a continuation of the previous JAD session. Beware: This is usually the most difficult JAD session for the users. They're probably not accustomed to breaking down an operation into constituent steps and exhaustively enumerating all those steps. The work-product is a text description of the steps in each use case.
During the JAD sessions, the object modeler listens to all the discussions and continues to refine the class diagram. At this point, the object modeler should be filling in the names of associations, abstract classes, multiplicities, generalizations, and aggregations. The work-product is a refined class diagram.
The object modeler further refines the model by showing changes of state wherever necessary. The work-product is a state diagram.
Now that the team has a set of use case diagrams and a refined class diagram, it's time to define how the objects interact. The object modeler develops a set of sequence diagrams and collaboration diagrams to depict the interaction. State changes should be included. These diagrams form the work-product for this action.
Proceeding in parallel with all the preceding steps, the system engineer uncovers specific details of the integration with the cooperating systems. What type of communication is involved? What is the network architecture? If the system has to access databases, a database analyst determines the architecture (physical and logical) of those databases. The work-products are detailed deployment diagrams and (if necessary) data models.
In this segment, the team works with the results of the Analysis segment to design the solution. Design and Analysis should go back and forth until the design is complete. Some methodologies, in fact, combine Analysis and Design into one stage.
Programmers take the class diagram and generate any necessary object diagrams. They flesh out the object diagrams by examining each operation and developing a corresponding activity diagram. The activity diagrams will serve as the basis for much of the coding in the Development segment. The work-products are the object diagrams and the activity diagrams.
Programmers play a major role in this action. The task here is to visualize the components that will result from the next segment and show the dependencies among them. The component diagrams are the work-product.
When the component diagram is complete, the system engineer begins planning for deployment and for integration with cooperating systems. He or she creates a deployment diagram that shows where the components will reside. The work-product is a diagram that's part of the deployment diagram developed earlier.
This involves another JAD session with the users. Although this is part of Design, this session can be a continuation of the prior JAD sessions with users—an indication of the interplay between Analysis and Design.
The user interface should allow for completion of all use cases. In order to perform this action, a GUI analyst works with the users to develop paper prototypes of screens that correspond to groups of use cases. The users position post-it notes that represent screen components (pushbuttons, check boxes, drop-down lists, menus, and so on). When the users are satisfied with the positioning of the components, developers build screen prototypes for the users' approval. The work-products are screen shots of the screen prototypes.
Use cases enable the design of tests for the software. The objective is to assess whether or not the developed software performs as it's supposed to—that is, it does what the use cases specify. Preferably, a developer or test specialist from outside the development team uses the use case diagrams to develop test scripts for automated test tools. The test scripts constitute the work-product.
It's never too early to begin documenting the system for the end-users and for system administrators. Documentation specialists work with the designers to begin storyboarding the documentation and arriving at a high-level structure for each document. The document structure is the work-product.
Here's where the programmers take over. With enough analysis and design, this segment should go quickly and smoothly.
With the class diagrams, object diagrams, activity diagrams, and component diagrams in hand, the programmers construct the code for the system. The code is the work-product from this action.
Test specialists (not the developers) run the test scripts to assess whether or not the code is doing what it should. The test results are the work-products. This action feeds back into the preceding action and vice versa, until the code passes all levels of testing.
This action draws on the user-approved prototype user interfaces. The GUI specialist constructs them and connects them to the code. Further testing ensures that the interfaces work properly. The functioning system, complete with user interfaces, is the work-product.
When development is complete, the system is deployed on the appropriate hardware and integrated with the cooperating systems. The first action in this segment, however, can start long before the Development segment begins.
The system engineer creates a plan for steps to follow in case the system crashes. The plan, the work-product for this action, specifies what to do to back up the system and to recover from the crash.
The system engineer, with any necessary help from the programmers, deploys the finished system on the appropriate computer(s). The work-product is the fully deployed system.
Finally, the development team tests the installed system. Does it perform as it's supposed to? Does the backup and recovery plan work? Results of these tests determine whether further refinement is necessary, and the test results make up the work-product.
If you step back and look at the segments and actions in GRAPPLE, you'll see that the movement is from general to specific—from the unrefined to the refined. It begins with a conceptual understanding of the domain, moves to high-level functionality, drills down into use cases, refines models, and designs, develops, and deploys the system.
You'll also notice that more actions were in the Analysis and Design segments than in the Development segment. This is, pardon the pun, by design. The idea is to spend as much time as you can in up-front analysis and design so that coding proceeds smoothly. It might seem like heresy, but in the ideal world, coding is just one small part of system development. The more you analyze, the closer you come to the ideal.
GRAPPLE, as I said, is a simplified skeleton of a development process. I didn't touch on the details of important issues like levels of testing. I also left out some important nuts and bolts: Where and how does the team maintain the work-products-in-progress? How does the team handle the all-important issue of configuration management?
I didn't address these topics because they're tangential to our discussion of the UML. The short answer for these nuts-and-bolts issues is to embrace the technology. Work-products (finished or in-progress) can reside in a repository that lives on the organization's LAN. One option is to have a hierarchy of directories that the team members can access. A safer option is to install a centralized repository package that tracks checkout and check-in of work-products and permits only one person at a time to check out an editable copy of an item. This is the foundation of a solution for configuration management. Repository technology is advancing steadily, and several choices are available.
The next hour begins Part II, a case study that applies the UML and GRAPPLE.
A development methodology structures the segments and activities in a system development project. Without a methodology, chaos would reign, developers wouldn't understand the problem they were trying to solve, and systems wouldn't meet the needs of their users. Early methodologies forced a “waterfall” sequence of analyze, design, code, and deploy.
This kind of sequential methodology can compartmentalize development, so that a development team might not take advantage of the increased understanding that results during the life of a project. It also typically allots the major share of project time to coding and thus takes valuable time away from analysis and design.
This hour presented GRAPPLE (Guidelines for Rapid APPLication Engineering), a skeleton development process. GRAPPLE consists of five segments: Requirements gathering, Analysis, Design, Development, and Deployment. Each segment consists of a number of actions, and each action results in a work-product. UML diagrams are work-products for many of the actions.
Part II applies GRAPPLE and the UML to a case study.
Now that you know about methodologies, test your knowledge with these quiz questions. Appendix A, “Quiz Answers,” supplies the answers.