| One of the real advantages of using RUP is that it is flexible. As an example of getting started with it, say you're a project leader, and you're at the beginning of your project. You start with the most important concepts, and then add what you believe your organization needs to be successful. Gary approaches RUP by thinking about the artifacts (requirements, tests, code, and so on) that his project needs, then determining what activities to perform in order to create those artifacts. A key point to remember, though, is that the goal is to build software, not to create artifacts. Regardless of your project's size, you need to configure RUP for your particular context. Follow the Spirit of RUP , as elegantly described by Per Kroll, the director of the RUP product team at IBM Rational Software, [2] in his article in The Rational Edge . [3] By following the spirit of RUP, especially on a small project, you will ensure that you have just the right amount of process. [2] Rational Software was acquired by IBM Corp. in early 2003 and became a part of the IBM Software Group . We will usually say "Rational" even though some of the events described in the book occurred after the acquisition. [3] Go to www.therationaledge.com and click on Archives. Key Artifacts Here are the basic artifacts we believe every team needs: -
A Vision statement . This helps the project team understand what to build and later helps them know when they're done building it. -
A Risk List . What are the actual risks you face and how will you mitigate them? When you think about risk, consider these elements of your project: people, process, and tools. Worry about risks that are real, that have a reasonable probability of occurring. Prioritize risks based on their probability of occurring and the cost associated with them. Yes, it is possible that a member of your team will break a leg skiing and end up in the hospital for the duration of the project. If there is enough cross-knowledge on the project, the impact will be minimal, and the likelihood of such an accident is small ”so don't worry too much about mitigating this risk. If you are going to worry, at least worry about things that matter. If a risk starts to look more probable as the project progresses, you can always change your risk list. -
A Development Case . This describes how you will adapt RUP to your needs. One important part of a development case is that it explains the responsibilities of each different role on the project. With a small team, of course, each person typically plays more than one role, so it's important to define all the responsibilities carefully . -
Use cases . These define a series of interactions between the system and an actor (usually a user ) that yield observable results of value. When your team practices iterative development (see the sidebar on Iterative Development), use cases help ensure that you're delivering something of value with each iteration. Use cases serve as the foundation for your requirements. (You can also add nonfunctional requirements that are not based on use cases, such as requirements that focus on response time.) The use cases also serve as a basis for your test plan, your documentation plan, and so on. You need to decide whether to express your use cases in UML, in text, or in both. This is a cultural issue, and there's no right answer. Do what's right for your team. You might not need use cases if you were developing a compiler, for example, but we'd use them for most other projects we can imagine. -
A good set of Tests . If you're using RUP, then you can begin generating tests as soon as you complete your first use cases. In fact, if you write your tests first based on your requirements, and code to the tests, you can ensure that the software you produce meets your requirements. -
An Architecture . This may be extremely informal. Some groups release their first version without a formal architecture, then ( assuming success) when they're planning the second version, they start by documenting the architecture so far and how to extend it. Other projects develop an architecture from the beginning. Whether you explicitly set aside time on your project to attend to the architecture, or let the architecture evolve , you have an architecture! -
A Project Plan . This should outline the iterations and schedule. Design the iterations so that you address the major risk items during the Elaboration phase (one of the four phases of RUP). This helps you reduce the probability of technical surprises or unexpected rework late in the project. [4] [4] Magnus Lyck , who was one of the reviewers of the manuscript for this book, offers a variation. He suggests that you schedule an early Elaboration phase iteration with very simple goals to help the team become accustomed to working together and to working with the process and tools for the project, then schedule the second and subsequent iterations to address the high-risk items. This approach helps teams become familiar with RUP without the added burden of addressing highly complex technical issues. This is especially useful for teams who are new to using RUP. -
A Glossary . This should contain definitions to keep your team's language consistent, project-wide. If the team, including your customers and all stakeholders, are familiar with the domain and all of the terms you might use while working on the project, you might not need a written glossary. | Iterative Development Iterative development describes an approach to developing software that characterizes most modern software development lifecycles. Until the mid-1980s, the typical approach to software development was the waterfall lifecycle shown in Figure 2.1. This model works well when you have complete knowledge of the problem at hand and do not experience change during the development period. In the face of the continual change that we experience today when we develop systems, the waterfall model breaks down. Figure 2.1. The waterfall lifecycle [*]  [*] 2003 Rational Software Corporation. All rights reserved. Graphic used with permission of IBM Corporation. The waterfall lifecycle has also been shown to be ineffective at driving down risk early in the development period. This characteristic is primarily because testing does not begin until late in the project, when the cost of removing defects is much more expensive than early detection and removal. In 1986, Barry Boehm introduced his spiral model of software development. [  ] Since then, the spiral model has been adopted as the standard approach to developing software, often under different names such as evolutionary software development, or iterative development. Figure 2.2 shows the way RUP describes iterations. With iterative development, a project is broken up into i terations , each of them similar to a complete mini-waterfall cycle. While each iteration may appear to be sequential, like a true mini-waterfall, the actual sequence of activities may be nonlinear. For example, you might work on requirements, then work on analysis and design, then work on requirements again, then testing, then analysis and design, as work needs to be completed. Figure 2.2. RUP iteration diagram [  ]  [ ] 2003 Rational Software Corporation. All rights reserved. Graphic used with permission of IBM Corporation. Each iteration has a goal. In RUP the goal is to produce working software that provides value and can be deployed to a user. Iterations are time-boxed . This means that there is a specific time period in which the work is to be done. If the work is not complete on a specific feature it must be rescheduled for a future iteration or dropped from the product. You do not extend the time frame of an iteration. The time-box feature of iterative development and the continual adjusting of the project plan for each iteration helps you address changes more effectively than with a waterfall model. Typically, each iteration adds to the work done in previous iterations. For this reason, we say that a process like RUP is both iterative and incremental. We incrementally add to the software until we arrive at the desired product. One reason that the iterative development model has replaced the waterfall model is that it reduces risk early. This increases the probability that either the project will succeed or you will realize early that you cannot complete the project successfully within the allocated time and budget. Figure 2.3 shows the risk profile for iterative (RUP) versus the typical waterfall risk profile. Figure 2.3. Risk profile for iterative versus. waterfall lifecycles  Adopting an iterative approach to software development does not come for free. Making the transition from waterfall to iterative development can be difficult, especially for project managers. We recommend that you read the white paper "From Waterfall to Iterative Lifecycle ”A tough transition for project managers" (go to www.ibm.com/software/rational/library/whitepapers/wp-lifecycle.html and select the white paper ). |
[*] 2003 Rational Software Corporation. All rights reserved. Graphic used with permission of IBM Corporation. [ ] A Spiral Model of Software Development and Enhancement , Barry Boehm, ACM SIGSOFT Software Engineering Notes, August 1986. [ ] 2003 Rational Software Corporation. All rights reserved. Graphic used with permission of IBM Corporation. Level of Formality The artifacts can be as formal or informal as you want, depending on the needs of your business. You might write your vision on a Post-it note and the project plan on a whiteboard. You can keep your requirements on 3x5 cards. And you might have an oral agreement about your development case but not write it down. As the complexity of a project increases (in terms of the number of people, the amount of functionality, or by any other measurement), you may find that you need to work with these and other documents more formally . RUP provides templates for the artifacts and reports . The latest release of RUP provides two sets of most templates, formal and informal. When appropriate for your team, Rational tools (as well as other vendors ' tools) support the process by helping you create and manage the different artifacts. Also, you can always mix levels of formality. For example, if you're on a three-person team developing the security system for a Web site, communications within the project can be very informal. But when it comes to communicating with other small projects that have an interface with yours, then you may need to be more formal. As a project leader, you should create your own guidelines and adapt elements of the process to meet the needs of your project.  |
