|
|
| Home - Industry Article - Nov 04 Issue |
Extending the Rational Unified Process: RUP to EUP
continued... page 2 |
Let's consider the two new phases added to the RUP by the EUP:
- The Production phase. This phase encompasses the period of the system lifecycle where you operate and support a system until it is either replaced with a new version or it is retired and removed completely from use. Change management of reported defects and new requirements is critical so as to ensure that changes are assigned to future development cycles. This phase applies to the lifetime of a single release of your software. To develop and deploy a new release of your software, you need to cycle through the four development phases again.
- The Retirement Phase. The focus of this phase is the removal of a system from production. Eventually systems become obsolete or are superseded by other systems and must be removed/sunsetted.
EUP phases are divided into one or more iterations, although the term "increment" might be more appropriate. Iterations build upon the work done by previous iterations and assemble the final system incrementally. Iterations are indicated along the bottom of Figure 4. When an iteration ends, in particular during the Construction phase, a small subset of the system has been completed that could conceivably be deployed to users as a release, even if only as an alpha or beta version.
3. The EUP Disciplines
The iterative nature of the RUP is reflected in how you approach its disciplines, which are logical groupings of activities that take place over the lifetime of a project. During a Construction iteration, for example, the portion of the requirements selected for that iteration are analyzed, designed, coded, tested, and integrated with the products from earlier iterations. As new or changed requirements are identified throughout a project, they are prioritized and either incorporated into the current effort, put off for later efforts, or rejected.
An important concept when working within an iteration is that work does not proceed serially, as it does in a waterfall approach. Yes, you still start with requirements, perform analysis, and then design and code, but you do not have to finalize one step before you can move to the next. With EUP, a typical approach is to address some subset of the requirements, do some analysis, go back and rework some of the requirements, move to design, rework some requirements and/or analysis, start coding, and then rework the design. In order for this to work, you need a team that works together on projects. Requirements people need to work with designers who work with coders who work with testers. Of course this works best if the same people can perform requirements analysis, design, coding, and testing, but it's not strictly necessary. The important point is that work proceeds in a serial nature in the broader sense but that artifacts are revised as needed by latter phases instead of being finished and handed off to other team members.
We have organized the EUP disciplines into three categories - development, support, and enterprise management - summarized respectively in Tables 1, 2, and 3. The development disciplines encapsulate the technical activities required to build a system, the support disciplines encapsulate activities that support project teams (as the name implies), and the enterprise management disciplines address cross-system activities. The first two categories are adopted from the original version of the RUP released in 1999 although they were subsequently dropped by Rational Corporation (it didn't make sense to have just two categories).
Table 1. The development disciplines.
| Discipline |
Goal |
| Business Modeling |
To understand the business of the organization, usually confined to the scope of the business that is relevant to the system being developed. |
| Requirements |
To elicit, document, and agree upon the scope of what is and what is not to be built. This information is used by analysts, designers, and programmers to build the system, by testers to verify the system, and by the project manager to plan and manage the project. |
| Analysis & Design |
To analyze the requirements for the system and to design a solution to be implemented, taking into consideration the requirements, constraints, and all applicable standards and guidelines. |
| Implementation | To transform the design into executable code and to perform a basic level of testing, in particular unit testing. |
| Test |
To perform an objective evaluation to ensure quality. This includes finding defects, validating that the system works as designed, and verifying that the requirements are met. |
| Deployment | To plan for the delivery of the system and to execute the plan to make the system available to end-users. |
Table 2. The support disciplines.
| Discipline |
Goal |
| Configuration and Change Management |
To manage access to the project artifacts. This includes not only tracking artifact versions over time, but also controlling and managing changes to them. |
| Project Management |
To direct the activities that takes place on the project. This includes managing risks, directing people (assigning tasks, tracking progress, etc.), and coordinating with people and systems outside the scope of the project to be sure that it is delivered on time and within budget. |
| Environment |
To support the rest of the effort by ensuring that the proper process, guidance (standards and guidelines), and tools (hardware, software, etc.) are available for the team as needed. |
| Operations & Support |
To operate and support your production systems. Operations activities include monitoring and tuning systems, upgrading hardware, and archiving data. Support activities include responding to user requests, escalating serious problems, recording suggested fixes and improvements to existing systems, and recovering from disasters. The EUP adopts much of the advice provided by the ITIL guidelines (ITIL 2003). |
Table 3. The enterprise management disciplines.
| Discipline |
Goal |
| Enterprise Business Modeling | To explore the business structure and processes of the enterprise. It provides a common understanding of the business activities, customers, and suppliers of the business. Enterprise business modeling helps to identify problems and areas that are candidates for automation. |
| Portfolio Management |
To enable you to track and plan your organization's entire software portfolio as well as individual programs within your overall portfolio. Doing so allows you to schedule and implement new requirements in a more strategic fashion. This also helps to avoid implementing the same functionality within different applications. |
| Enterprise Architecture |
To address the overall architecture issues associated with your organization. It consists of models that define it, prototypes and working models that demonstrate how it works, and frameworks that make it easier to use. This discipline helps to ensure consistency across systems and greatly facilitates application architecture efforts. The EUP extends the Zachman Framework (ZIFA 2004) to enhance the RUP's approach to architecture. |
| Strategic Reuse |
To promote development and reuse of assets across projects, the goal of which is to enable you to develop higher-quality applications more quickly by reusing assets instead of developing them anew each time. It also helps improve quality, as it allows you to use artifacts that have already been tested and proven to work. |
| People Management |
To manage your staff and mediate the interactions between them and other people. This discipline describes the process of organizing, monitoring, coaching, and motivating people in a manner to ensure they work together well and successfully contribute to projects within the organization. |
| Enterprise Administration |
To organize and administer data, network, hardware, software tools, and facilities that are key infrastructure components of your IT organization. |
| Software Process Improvement |
To manage, improve, and support the multiple processes in use across your organization. Remember, one process does not fit all. |
The new enterprise management disciplines come at a cost. Any attempts at implementing them should be applied judiciously and with minimal interruption to your current business functions. These new disciplines can provide significant savings in the long run by streamlining the way that your IT department operates, that is, if you choose to implement them in a non-bureaucratic manner.
It is important to understand that although some overlap exists between the enterprise management discipline activities and existing RUP activities, the scope is different. For example, the Enterprise Architecture discipline includes many of the same activities as the RUP Analysis and Design discipline. Your enterprise architecture is concerned with the architecture that spans across multiple systems, whereas the architecture that is done during the Analysis and Design discipline of a project is for a single system only. Similarly, Enterprise Business Modeling (EBM) and Business Modeling (BM) disciplines are alike as far as the activities are concerned. The difference is that EBM takes a broad and shallow look at the entire business, whereas BM typically looks at the business only as it relates to a single system. BM will most likely go into more detail in a specific area, as it may be required to do so in order for a particular system to be developed.
4. The EUP Best Practices
The RUP is based on six best practices - develop iteratively, manage requirements, use component architecture, model visually (UML), continuously verify quality, and manage change - gleaned from many years of experience on many projects. We have reworked two of the best practices to capture their core essence and added a few more practices to round them out. The best practices that we promote are:
- Develop iteratively. Developing in iterations allows projects to address risks on a priority basis. It allows for a constant measuring of progress, as iterations have a fixed time window and a specific goal to be met. At the end of each iteration, stakeholders are provided a view of how the project is proceeding and can set realistic expectations for the remainder of the project based on the actual progress of working code.
- Manage requirements. A key to delivering a system that meets the stakeholders" needs is identifying and then managing the requirements for the system. This includes gathering, documenting, and maintaining of requirements, incorporating changes in a systematic manner, and potentially even tracking and tracing the requirements to the design. Your requirements management process can be very well defined and prescriptive, often involving significant effort and expense but with the benefit of producing accurate and detailed documentation of your decisions; it also can be something as simple as the index-card based planning game from Extreme Programming (XP) (Beck 2005). It can be somewhere in between these two extremes. The RUP can and should be tailored to meet a project's exact needs.
- Proven architecture. The RUP uses the term "use component architecture," but the reality is that many architectures aren't component-based. For example, web services are another architectural option, as are procedural languages such as COBOL, and you can easily extend the RUP to work with these technologies. The true best practice is to identify and then prove through prototyping an architecture that is appropriate for the system that you are building.
- Modeling. Although the RUP uses the term "model visually," the reality is that some models such as use cases, business rule specifications, and Class Responsibility Collaborator (CRC) cards are non-visual in nature. Even as you might be tempted to think of writing a use case as simply writing documentation, what you're really doing is modeling how people will interact with your system. Modeling helps people envision and think through concepts and then share those ideas with others. Modeling can be done with high-powered, GUI-based software applications or can simply be sketches on whiteboards. A quick visit to the Agile Models Distilled home page ( www.agilemodeling.com/artifacts/) quickly reveals that a wide range of models is available to you.
- Continuously verify quality. Testing happens throughout each iteration of a RUP project instead of a single, large testing effort at the end. Ensuring quality goes beyond testing software to ensure it meets requirements - reviews of requirements, design, and mockups with stakeholders are also part of continuous quality verification. Testing for and catching defects early is much more efficient than a comprehensive approach to testing at the end. An effective way to ensure quality is an implementation technique called test-driven development (TDD), which is based on the idea that developers should write a test before they write new business code to ensure that they always have a 100% regression unit test suite for their system (Beck 2003; Astels 2003).
- Manage change. Change is a given in software development. Change must be expected and handled appropriately for a project to run smoothly and to take advantage of changes that may give them a competitive advantage. A wide range of artifacts - documents, models, plans, tests, code, and so on - will potentially be affected by any changes; as agilists point out, you want to travel as light as possible to minimize the impact.
- Collaborative development. Systems are built by teams of people, and if these people don't work together effectively, the overall project risks failure. The agile software development community ( www.agilealliance.org) has done significant work in identifying and promoting collaborative development techniques. Primary techniques include pair programming, where two people work together to develop code (Williams and Kessler 2002); modeling with others, which promotes the concept that several people are more effective modeling together than they are working separately; and active stakeholder participation, which promotes the concept that project stakeholders should provide information and make decisions in a timely manner and be involved with the development effort itself (Ambler 2002).
- Look beyond development. Not only do you need to build and deploy a system into production, but you also need to operate and support it after it's there. Good developers know this and understand that they need to work with operations and support professionals to ensure that their needs are met. Furthermore, good developers also realize that their system must fit into the overall organization, the implication being that they need to ensure that their system reflects common enterprise norms - their systems will take advantage of the existing architecture and infrastructure and will follow accepted enterprise guidance (standards and guidelines).
- Deliver working software on a regular basis. The primary measure of success for a software development project should be the delivery of working software that meets the needs of its users. Effective developers deliver working software on an incremental basis, delivering the highest priority functionality remaining at each iteration.
- Manage risk. Effective project teams strive to identify and then manage the risks that they face, either mitigating them completely or reducing their potential impact as appropriate.
Summary
The RUP lifecycle focuses on the development and deployment of one system release into production. Because your organization must contend with running multiple systems, you must extend the RUP to reflect this reality. The EUP includes two new phases and eight new disciplines to complete the view of the overall system and IT perspectives. The operations and support discipline - which encompasses most of the Production phase - has been added to help an organization operate and support their systems. Two new phases of the EUP include Production and Retirement. The Production phase addresses supporting a product after it has been released into production. The Retirement phase has been added to address the real-world needs of sunsetting (or retiring) a product from production. Finally, seven new enterprise management disciplines have been added to address multiple areas within your organization to support cross-project issues.
References and Recommended Reading:
- Ambler, S.W. (1999). Enhancing the Unified Process. Software Development, October 1999. www.sdmagazine.com/documents/s=753/sdm9910b/9910b.htm
- Ambler, S.W. (2002). Agile Modeling: Best Practices for the Unified Process and Extreme Programming. New York: John Wiley & Sons. www.ambysoft.com/agileModeling.html
- Ambler, S.W., Nalbone, J., and Vizdos, M. (2005). The Enterprise Unified Process: Extending the Rational Unified Process. Upper Saddle River, NJ: Prentice Hall PTR.
- Astels D. (2003). Test Driven Development: A Practical Guide. Upper Saddle River, NJ: Prentice Hall.
- Beck, K. (2003). Test Driven Development: By Example. Boston, MA: Addison-Wesley.
- Beck, K. (2005). Extreme Programming Explained 2nd Edition. Reading, MA: Addison-Wesley Longman, Inc.
- IBM (2004). Rational Unified Process Home Page. www.rational.com/products/rup/index.jsp.
- ITIL (2003) The ITIL and ITSM Directory. www.itil-itsm-world.com
- Jacobson, I., Booch, G., and Rumbaugh, J. (1999). The Unified Software Development Process. Reading, MA: Addison-Wesley Longman, Inc.
- Kruchten, P. (2004). The Rational Unified Process 3rd Edition: An Introduction. Reading, MA: Addison-Wesley Longman, Inc.
- Williams, L., and Kessler, R. (2002). Pair Programming Illuminated. Boston, MA: Addison-Wesley.
- ZIFA (2004). The Zachman Institute for Framework Advancement. www.zifa.com
Scott W. Ambler is a Senior Consultant with Ronin International, Inc. ( www.ronin-intl.com), a software services consulting firm that specializes in software process mentoring and improvement. He is founder and thought leader of the Agile Modeling (AM) ( www.agilemodeling.com), Agile Data (AD) ( www.agiledata.org), and Enterprise Unified Process (EUP) methodologies ( www.enterpriseunifiedprocess.com). Scott is the (co-)author of several books, including Agile Modeling (John Wiley & Sons), Agile Database Techniques (John Wiley & Sons), The Object Primer 3rd Edition (Cambridge University Press), The Practical Guide to Enterprise Architecture (Prentice Hall), and The Elements of UML Style (Cambridge University Press). Scott is a contributing editor with Software Development magazine (www.sdmagazine.com) and a columnist with Computing Canada. A full list of his books is presented atwww.ambysoft.com/booksAmbler.html. Scott can be reached for article feedback by visiting: www.ambysoft.com/scottAmbler.html
 
|
|
|
