Enterprise Unified Process: Core Practices

The Rational Unified Process (RUP) was originally 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. The Enterprise Unified Process^TM(EUP) reworks two of the best practices to capture their core essence and added a few more practices to round them out.The “core practices” of the EUP 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 the 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 real strategy 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. Although 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 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 (see Agile Testing and Quality Strategies). 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.
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 has done significant work in identifying and promoting collaborative development techniques. Primary techniques include pair programming, where two people work together to develop code; 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 stakeholders should provide information and make decisions in a timely manner and be involved with the development effort itself.
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.

Enterprise Unified Process: Core Practices

Recommended Reading