What Kind of RUP Configuration Meets Your Process Needs?

All of the above creates some important questions for determining what kind of RUP configuration is needed: Where should a project be on the process map? How much should it favor an iterative approach? How much ceremony is needed? To answer these questions, let us look at four different projects.

Project Deimos: Team of One

graphics/d_icon.gif

Project Deimos is a one-person project, developing a fairly simple application under the harsh time constraints of one week. Project Deimos is further described in Chapter 4.

Placement on the process map: The extremely small size, short duration, and relatively low complexity all indicate that the project should use an extremely iterative, flexible process (see Figure 3.6).

Figure 3.6. Example Projects on the Process Map. Different projects require different process configurations, as shown with these four RUP projects. Project Deimos, a one-person, one-week project; Project Ganymede, a small project under harsh time constraints; Project Mars, an average- sized project with no experience in iterative development; and Project Jupiter, a very large project challenged by complex stakeholder relations and complex technology.

graphics/03fig06.gif

Project Ganymede: Small Project with Tight Timeline

graphics/g_icon.gif

Project Ganymede is a four-person project developing a database-centric, hosted business application. The team is working under tough time constraints and must deliver a first version of the application in three months. To make things worse , the team expects the requirements to change somewhat during the project due to the rapidly changing business environment. Luckily, several team members have built similar systems before.

Placement on the process map: The small size, harsh time constraints, changing requirements, hosted environment allowing rapid deployment of fixes, and experienced team all indicate that the project should use a highly iterative, flexible process (see Figure 3.6).

Project Mars: Average-Size Project without Iterative Development Experience

graphics/m_icon.gif

Project Mars is a 15-person project developing a Web-centric application. This is the third Web-based application the project team has developed on a J2EE platform. None of the team members has done iterative development, and there is no funding for iterative development training or mentoring. The team is using a very simple tool environment, including a low-end Configuration and Change Management system. The team knows that the system will be around for a number of years , so it needs to develop a robust system. To make things worse, the team has to develop the system under great time constraints, creating a difficult balance between making a system that is easy to maintain and doing it quickly.

Placement on the process map: The medium-sized project, as well as the balance between speed and system maintenance, indicate that the project should be somewhere in the middle of the Low Ceremony/High Ceremony axis. Considering the severe time constraints and the need to get the architecture right, the team would benefit from using a highly iterative approach, but the lack of experience, training, and mentors, as well as the inadequate tool environment, all suggest the team would not be able to manage too many iterations in their first iterative project. They should be just below the center on the Waterfall/Iterative axis (see Figure 3.6).

Project Jupiter: Large Distributed Project

graphics/j_icon.gif

Project Jupiter is a large, 150-member project, distributed over three sites on two continents ”a time zone difference of 11 hours complicates communication. The project has complex stakeholder relations, and some stakeholders require good visibility in the project. This project will develop versions of a technically very complex system. The system will need to be maintained for many years. Additionally, quality is a major concern. Luckily, there are some very experienced team members, including top- notch project management and architecture teams .

Placement on the process map: Size, technical complexity, complex stakeholder relationships, long-lived system, quality concerns, and an experienced team all indicate that the project should use a highly iterative, high-ceremony process (see Figure 3.6).



The Rational Unified Process Made Easy(c) A Practitioner's Guide to Rational Unified Process
Programming Microsoft Visual C++
ISBN: N/A
EAN: 2147483647
Year: 2005
Pages: 173

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net