Understanding the Unified Process (UP)

Sinan Si Alhir

Introduction

The systems engineering discipline focuses on an elegant universe we call reality wherein the two dimensions of time and space establish the landscape for the intertwining dance between the two natural forces of change and complexity. It is within this arena that the key ingredients of teams and people, methodologies and processes, and tools and enabling technologies converge to bridge the chasm between vision and reality. At the core of every mature discipline, from the arts to the sciences and engineering, is a common language and common approaches enabling practitioners to collaborate and the discipline to evolve; and at the heart of this evolution is capturing or acquiring, communicating or sharing, and leveraging or utilizing knowledge. Language establishes the boundaries of thought and behavior, it defines concepts; methodology and process establish behavior within that boundary, they apply concepts; and tools establish the automation of behavior within that boundary, they automate the application of concepts. Quite simply, if we can't think it, we can't do it nor communicate it, and if we can't do it, we can't automate it! Within the information systems and technology industry, the Unified Process (UP), Rational Unified Process (RUP), Unified ModelingLanguage (UML), and Software Process Engineering Metamodel (SPEM) are at the heart of this evolution.

The Unified Process (UP) and Rational Unified Process (RUP)

The Unified Process (UP) is a use-case-driven, architecture-centric, iterative and incremental development process framework that leverages the Object Management Group's (OMG) UML and is compliant with the OMG's SPEM. The UP is broadly applicable to different types of software systems, including small-scale and large-scale projects having various degrees of managerial and technical complexity, across different application domains and organizational cultures.

The UP emerged as the unification of Rational Software Corporation's Rational Approach and Objectory AB's Objectory process in 1995 when Rational Software Corporation acquired Objectory AB. Rational Software Corporation developed the Rational Approach as a result of various customer experiences, and Ivar Jacobson created the Objectory process primarily as a result of his experience with Ericsson in Sweden.

The UP is an "idea," a process framework that provides an infrastructure for executing projects but not all of the details required for executing projects; essentially, it is a software development process framework, a lifecycle model involving context, collaborations, and interactions. The UP is documented in the book entitled "The Unified Software Development Process" by the Three Amigos (Grady Booch, James Rumbaugh, and Ivar Jacobson) (Addison-Wesley, 1999). The Rational Unified Process (RUP) is a process product developed and marketed by Rational Software Corporation that provides the details required for executing projects using the UP, including guidelines, templates, and tool assistance; essentially, it is a commercial process product providing the details or content for the UP framework. When applying the UP or RUP on a project, a Development Case, an instance of the process framework, specifies what elements of the UP or RUP are utilized throughout the project. A "RUP-based" Development Case is an instance of the RUP (and the UP), a configured or tailored subset of the RUP content (which may possibly be further augmented) that addresses the breadth and depth of the UP framework. A "UP-based" Development Case is an instance of the UP that addresses the breadth and depth of the UP framework.

The Unified Modeling Language (UML) and Software Process Engineering Metamodel (SPEM)

The Unified Modeling Language (UML) is an evolutionary general-purpose, broadly applicable, tool-supported, and industry-standardized modeling language or collection of modeling techniques for specifying, visualizing, constructing, and documenting the artifacts of a system-intensive process. The UML is broadly applicable to different types of systems (software and non-software), domains (business versus software), and methods and processes. The UML enables and promotes (but does not require nor mandate) a use-case-driven, architecture-centric, iterative and incremental process.

The UML emerged from the unification that occurred in the 1990s within the information systems and technology industry. Unification was led by Rational Software Corporation and the Three Amigos. The UML gained significant industry support from various organizations via the UML Partners Consortium and was submitted to and adopted by the OMG as a standard (November 1997).

As the UML is an industry-standardized modeling language for communicating about systems, the Software Process Engineering Metamodel (SPEM) is an industry-standardized modeling language for communicating about processes and process frameworks (families of related processes) but it does not describe process enactment (the planning and execution of a process on a project). The SPEM began to emerge after the UML standardization effort, gained significant industry support from various organizations, and was adopted by the OMG as a standard (November 2001).

System Development, Systems, Models, and Views

The system development lifecycle process involves a problem-solving process at a macro-level and the scientific method at a micro-level. Requirements may be characterized as problems. Systems that address requirements may be characterized as solutions. Problem solving involves understanding or conceptualizing the problem or requirements by representing and interpreting the problem, solving the problem by manipulating the representation of the problem to derive or specify a representation of the solution, and implementing or realizing and constructing the solution or system that addresses the requirements by mapping the representation of the solution onto the solution world. Within each problem-solving step, the scientific method involves planning or predicting a hypothesis, executing or empirically testing the hypothesis, evaluating the hypothesis against the results, and deriving a conclusion that is used to update the hypothesis. These macro-level and micro-level processes are very natural and often occur subtly and sometimes unconsciously in system development!

The UML facilitates and enables the problem-solving process. It facilitates specifying, visualizing, understanding, and documenting the problem or requirements; capturing, communicating, and leveraging strategic, tactical, and operational knowledge in solving the problem; and specifying, visualizing, constructing, and documenting the solution or system that satisfies the requirements. It enables capturing, communicating, and leveraging knowledge concerning systems using models, architectural views, and diagrams.

A system is a purposefully organized collection of elements or units. The architecture of a system entails two dimensions, the structural dimension and behavioral dimension, within its context. The structural or static dimension involves what elements constitute the system and their relationships. The behavioral or dynamic dimension involves how these elements collaborate and interact to satisfy the purpose of the system and provide its functionality or behavior.

A model is a complete abstraction of a system that captures knowledge (semantics) about a problem and solution. An architectural view is an abstraction of a model that organizes knowledge in accordance with guidelines expressing idioms of usage. A diagram is a graphical projection of sets of model elements that depicts knowledge (syntax) about problems and solutions for communication. Within the fundamental UML notation, concepts are depicted as symbols and relationships among concepts are depicted as paths (lines) connecting symbols.

Methodologies and Process Frameworks

A program is a collection or portfolio of projects. A project is a specific problem-solving effort that formalizes the "work hard and hope for the best" approach. A method specifies or suggests how to conduct a project. A method's descriptive aspect specifies or suggests what knowledge is captured and communicated regarding a problem and solution. A method's prescriptive aspect specifies or suggests how knowledge is leveraged to solve the problem. A process is the execution of a method on a project.

A methodology is a discipline or taxonomy, or well-organized collection, of related methods that addresses who does what activities on what work products, including when, how, why, and where such activities should be done. Workers (who), activities (how), work products (what), and the heuristics concerning them are commonly known as process elements. Methodologies group methods as a family, methods describe processes, and processes execute methods on projects.

To provide more flexibility and scalability to address increasingly more diverse problems, where applying a single method may be insufficient and applying a whole methodology may be impractical, a subset of a whole methodology may be applied where the methodology is called a process framework and the actual subset of all of its methods that are applied on a specific project is called a process instance.

A process framework specifies or suggests who does what activities on what work products, including when, how, why, and where such activities should be done for various types of projects. A process instance specifies or suggests who does what activities on what work products, including when, how, why, and where such activities should be done for a specific project. Process frameworks describe process instances as a more flexible and scaleable family of related processes, and process instances execute a subset of a process framework on projects. The UP is a process framework and Development Cases are process instances.

The Unified Process (UP)

To effectively and successfully apply the UP, we must understand collaborations, contexts, and interactions. As an effort or project leverages the UP, collaborations focus on the elements of the project, context focuses on the process framework for the project, and interactions focus on the execution of the project. Figure 1 shows the various elements of the UP.

Figure 1: Elements of the Unified Process (UP).

Collaborations

A collaboration involves an interaction within a context. A collaboration captures who does what activities (how) on what work products. Thus, it establishes the elements of a project.

A role is an individual or team who has responsibility for activities and artifacts. An activity is a unit of work, composed of steps, that is performed by a role. An artifact is an element of information that is the responsibility of a role and that is produced or consumed by activities. The UP defines numerous roles, artifacts, and activities.

Contexts

A context emphasizes the structural or static aspect of a collaboration, the elements that collaborate and their conglomeration or spatial relationships. A context captures when and where such activities should be done and work products produced and consumed. Thus, it establishes the context for a project. Figure 2 shows the context established by the UP.

Figure 2: Context established by the Unified Process (UP).

A project requires a management perspective to manage the effort and a technical perspective to execute and perform the technical work. The lifecycle of a project is composed of phases wherein iterations involve disciplines. A development cycle is composed of sequential phases resulting in a major system release called a system generation. For example, system generations may include versions 1.0, 2.0, 3.0, and so forth. A phase is a major milestone, a management decision point focused on managing business risk. Phases embody the macro-level problem-solving process. An iteration is a minor milestone, a technical decision point focused on managing technical risk, resulting in a minor system release called a system increment. For example, system increments may include versions 1.1, 1.2, 2.5, and so forth. Iterations embody micro-level applications of the scientific method. A discipline is an area of concern or theme wherein workflows describe the flow of work and wherein workflow details describe the collection of activities (with their associated roles and artifacts) often done together.

The UP defines the following four phases:

The Inception phase, concluding with the Objective milestone, focuses on establishing the project's scope and vision; that is, establishing the business feasibility of the effort and stabilizing the objectives of the project.
The Elaboration phase, concluding with the Architecture milestone, focuses on establishing the system's requirements and architecture; that is, establishing the technical feasibility of the effort and stabilizing the architecture of the system.
The Construction phase, concluding with the Initial Operational Capability milestone, focuses on completing construction or building of the system.
The Transition phase, concluding with the Product Release milestone, focuses on completing transitioning or deployment of the system to the user community.

The UP defines the following three supporting disciplines:

The Configuration & Change Management discipline focuses on managing the configuration of the system and change requests.
The Project Management discipline focuses on managing the project.
The Environment discipline focuses on the environment for the project, including the process and tools.
The UP defines the following six core disciplines:
The Business Modeling discipline focuses on understanding he business being automated by the system and capturing such knowledge in a Business model.
The Requirements discipline focuses on understanding the requirements of the system that automates the business and capturing such knowledge in a Use-case model.
The Analysis & Design discipline focuses on analyzing the requirements and designing the system and capturing such knowledge in an Analysis/Design model.
The Implementation discipline focuses on implementing the system based on the Implementation model.
The Test discipline focuses on testing (evaluating) the system against the requirements based on the Test model.
The Deployment discipline focuses on deploying the system based on the Deployment model.

The distribution of effort across phases, iterations, and disciplines focuses on addressing business and technical risks. During the Inception phase, most of the effort is distributed across the Business Modeling and Requirements disciplines. During the Elaboration phase, most of the effort is distributed across the Requirements, Analysis & Design, and Implementation disciplines. During the Construction phase, most of the effort is distributed across the Analysis & Design, Implementation, and Test disciplines. During the Transition phase, most of the effort is distributed across the Test and Deployment disciplines. The supporting disciplines are generally distributed throughout the four phases. The overall objective is to produce the resulting system; therefore, all of the core disciplines are engaged as soon as possible without introducing risk to the project; that is, practitioners are responsible for determining which disciplines to engage and when they should be engaged.

Interactions

An interaction emphasizes the behavioral or dynamic aspect of a collaboration, the elements that collaborate and their cooperation or temporal communication. An interaction captures when and why such activities should be done and work products produced and consumed. Thus, it establishes the execution of a project as it is governed by various forces.

As minor milestones occur within major milestones, technical decision points occur within management decision points such as to align technical tactics and operations with business strategy and objectives -- essentially, establishing a bridge between business and technical forces.

An iteration is a step or leg along a path or route to a destination. An iteration is planned and is not ad hoc, has evaluation criteria, and results in demonstrable progress. An iteration is iterative in that it is repetitive and involves work and rework, incremental in that it is additive and involves more than rework alone, and parallel in that work may be concurrent within the iteration.

A use-case is a functional requirement. For example, functionality to login or logout of a system, input data, process the data, generate reports, and so forth. As the UP is use-case driven, use cases drive or feed iterations. That is, iterations are planned and evaluated against "chunks" of functionality (or parts thereof) such as to manage agreement with users and trace project activities and artifacts back to requirements. Thus, accounting for business forces by planning and evaluating iterations against functional requirements. Non-functional requirements (usability, reliability, performance, and other such characteristics) are incrementally considered as use cases evolve through the disciplines.

A system has an architecture. For example, the architecture of a system includes a collection of elements and how they collaborate and interact, including various subsystems for handling security, input and output, data storage, external communications, reporting, and so forth. As the UP is architecture-centric, iterations focus on architecture and evolving the system. That is, iterations demonstrate progress by evolving a puzzle of "chunks" such as to manage the complexity and integrity of the system. Thus, accounting for technical forces by demonstrating progress via the production and evolution of the real system.

A risk is an obstacle to success, including human, business, and technical concerns or issues. For example, human risks include having insufficient, untrained, or inexperienced human resources, and so forth; business risks include having insufficient funding, time, or commitment from the business community, and so forth; and technical risks include having an insufficient understanding of the requirements or technology, using unproven technology, using technology that will not sufficiently address the requirements, and so forth. As the UP is risk-confronting, iterations confront risk and leverage feedback from previous iterations to confirm progress and discover other unknown risks. That is, iterations confront risk that is derived from use cases and architecture such as to achieve project success,thus reconciling business and technical forces.

An iteration is a time-box with a fixed beginning and end wherein a collection of collaborations are planned, executed, and assessed in order to progressively demonstrate progress. The beginning and end are negotiated among stakeholders, management and technical members of the project community who impact and are impacted by the effort. Use cases that feed an iteration are selected based on the highest risks they confront. A use case may evolve across any number of iterations and may evolve through any number of core disciplines in an iteration. An iteration results in one or more intermediate builds or operational versions of the system. An iteration results in a single internal or external baselined and evaluated release of the system. The feedback and lessons-learned gained from an iteration feed into future iterations. Within an iterative approach, metrics and estimates are also iteratively derived, and trends across iterations form the basis for metrics and estimation for the overall effort. The duration of an iteration is inversely proportional to the level of risk associated with the effort. As iterations execute, they only minimally overlap. Development cycles and phases may also be time-boxed; as development cycles, phases, and iterations are planned, the further the plans are in the future, the less accurate the estimates.

Although iterations are composed of the same disciplines as a "pure waterfall" approach, there are key distinctions. A waterfall approach aims for one hundred percent completeness of activities and artifacts of a discipline before proceeding to the next discipline; however, an iterative approach involves iterative collaboration and aims for incremental refinement and evolving levels of detail of artifacts throughout the lifecycle. A waterfall approach does not offer explicit opportunities for partial deployment of a system or explicit opportunities for introducing change into the lifecycle, and is therefore quite reactive to change; however, an iterative approach does offer explicit opportunities for partial deployment of a system at the end of an iteration and explicit opportunities for introducing change into the lifecycle at the end of an iteration and before the next iteration, and is therefore quite proactive or responsive to change. A waterfall approach progresses serially through disciplines; however, an iterative approach may progress forward or backward across phases to change focus and involves various disciplines in order to address risk.

Iterations

To effectively and successfully apply the UP, we must understand iterations and how they are applied in linear, sequential, and iterative approaches.

An iteration is planned, executed, and evaluated. Use cases and risks are prioritized, and use cases are ranked against the risks they mitigate. When planning an iteration, those use cases that address the highest risks and can be accommodated given the iteration's limiting factors (funding, time, resources, and so forth) are selected for driving the iteration. When executing an iteration, use cases evolve through the core disciplines and the system and its architecture evolve.

However, use cases need not evolve through every core discipline in a single iteration. When evaluating an iteration, actual results are compared against the planned objectives of the iteration, and plans and risks are updated and adjusted. The overall objective is to produce the resulting system; therefore, all of the core disciplines are engaged as soon as possible without introducing risk to the project; that is, practitioners are responsible for determining which disciplines to engage and when they should be engaged.

Linear Approaches

When the first group of iterations focus primarily on business modeling, next group of iterations focus primarily on requirements; and so on through the core disciplines, the team steadily learns more about the problem before learning about the solution as the effort progresses across phases. The effort results in a complete system only at the end of the development cycle. This is commonly known as a linear approach. Figure 3 shows the overall pattern of how effort is distributed using a linear approach.

Figure 3: Linear Approach.

Linear iterations are too macro-focused towards phases where disciplines are more discretely distributed across phases; thus, the balance between business and technology is skewed by the management members of the community. The effort attempts to force all use cases through a few disciplines in an iteration often because the management members of the community perceive everything as a business risk that must be immediately controlled.

Linear iterations tend to delay architecture-related risk-confrontation and risk-resolution while perceiving everything as a business-related or use-case-related risk. However, this approach delays necessary validation of the system and its architecture, and precludes opportunistic deployment of the system throughout the lifecycle. Essentially, this is a "pure waterfall" approach where disciplines are distributed across iterations.

Sequential Approaches

When use cases evolve through every core discipline in a single iteration, the team steadily learns more about the solution for a limited portion of the problem as the effort progresses across phases. The effort results in a system that only addresses a subset of the requirements, which may or may not be deployable or usable throughout the development cycle, and results in a complete system only at the end of the development cycle. This is commonly known as a sequential approach.

Figure 4 shows the overall pattern of how effort is distributed using a sequential approach.

Figure 4: Sequential Approach.

Sequential iterations are too micro-focused towards iterations where disciplines are more discretely distributed within iterations; thus, the balance between business and technology is skewed by the technical members of the community. The effort attempts to force a few use cases through all disciplines in an iteration often because the technical members of the community perceive everything as a technical risk that must be immediately addressed.

Sequential iterations tend to delay use-case-related risk-confrontation and risk-resolution while perceiving everything as a technology-related or architecture-related risk. However, this approach results in a system that may be difficult to integrate and validate, and delays sufficient coverage when exercising the architecture. Essentially, a lack of architectural coverage increases the probability of encountering a use case that completely invalidates the architecture derived from preceding iterations.

Iterative Approaches

An iterative approach involves using a mixture of sequential and linear approaches where linear approaches focus on the problem and sequential approaches focus on the solution. Figure 5 shows the overall pattern of how effort is distributed using an iterative approach, resulting in a parallelogram shape where the corners of the parallelogram are adjusted based on the specific project. When all of the sides of the parallelogram "collapse" into a diagonal line, a "pure waterfall" approach results with disciplines are distributed across iterations.

Figure 5: Iterative Approach.

An iterative approach focuses on a stepwise refinement of knowledge throughout the lifecycle. During the Inception phase, linear approaches focus on scope and sequential approaches focus on an architectural proof-of-concept. During the Elaboration phase, linear approaches gain architectural coverage and sequential approaches focus on addressing architectural risk. During the Construction phase, sequential approaches promote deployment opportunities. During the Transition phase, linear and sequential approaches focus on system completion and project closure.

Generally, an effort ramps up at the start of a development cycle, reaches an optimum where all core disciplines are being performed in parallel and all supporting disciplines are operating as appropriate, and then ramps down at the end of the development cycle. As iterations execute, their content involves collaborations among roles, activities, and artifacts where activities are related via a producer-consumer relationship and may overlap in time such that a consumer activity may start as soon as its inputs from producer activities are sufficiently mature.

Effectively and Successfully Applying the Unified Process (UP)

To effectively and successfully apply the UP, we ought to be aware of various guidelines (lessons learned) for applying the process framework.

Given the collaboration among roles, activities, and artifacts, the principal dynamics occur between the roles of the Project Manager, Architect, and Process Engineer. The other roles are not particularly secondary to these roles, but collate around these roles. The Project Manager is responsible for the overall project. The Architect is responsible for the system and its architecture. The Process Engineer is responsible for applying the UP and Development Case. The quintessential factor for effectively and successfully applying the UP is the collaboration and interaction among these roles in the context of a specific project. Their collaboration involves the Architect defining the system, the Process Engineer suggesting the roles, activities, and artifacts required for delivering the system, and the Project Manager applying resources for executing the activities against the artifacts to deliver the system. Their interaction involves leveraging each other's knowledge to successfully execute the effort. These roles must focus on bridging the chasm between culture and vision while balancing various contextual forces in a stepwise approach; that is, they must focus, balance, and iterate to achieve success. Otherwise, linear iterations result if the Project Manager is overly rigid, sequential iterations result if the Architect is overly rigid, and general anarchy results if the Process Engineer is overly rigid. Such rigidity results in compromising and failing to realize the benefits of an iterative approach.

Traditionally, projects have combined the Project Manager and Process Engineer roles, which distorts these principal dynamics and causes a "conflict of interest" amongst these roles (as each role has a distinct focus, objectives, and so forth); thus, increasing the potentiality of project failure. Figure 6 shows the principal dynamics of the UP.

Figure 6: Principal Dynamics of the Unified Process (UP).

While guidelines (lessons learned) concerning specific roles, activities, and artifacts are beyond the scope of this paper, guidance regarding focus, balance, and iterations is provided.

Focus

When applying the UP, we ought to focus and be aware of the following guidelines:

As everything in the UP is essentially optional, make decisions based on various factors while considering their ramifications. Always ask the "original question" -- Why? Don't do everything specified or suggested by the UP and only do something when there is a reason. A Process Engineer must be able to address why a particular role, activity, or artifact is utilized. Always ask the "original question that may-be" -- What-if? That is, explore what ought to be done. A Process Engineer must be able to address the ramifications if a particular role, activity, or artifact is or is not utilized. Always ask the "original question to-be ('next original question')" -- What-next? Given what-if, what-next (and why)? A Process Engineer must be able to address what particular roles, activities, and artifacts ought to be utilized next. Failure or inability to address these questions indicates or is symptomatic of a lack of focus on the context of a specific project.
Focus on context, then essential content, and then bridge the chasm between context and content iteratively and incrementally. Without knowledge of the context of a specific project upon which the UP is applied or without knowledge of the essential elements of the UP, the potential of project failure using the UP is heightened. A Process Engineer must be able to bridge the chasm between the project and the UP; that is, apply the essential elements of the UP in the context of the specific project. If the Process Engineer does not have knowledge of the context or essential elements of the UP, they must be able to delegate to those who do have such knowledge and then leverage their input to bridge the chasm. The essential elements of the UP have been emphasized throughout this paper.
Focus on the "spirit of the UP" and not simply the "letter of the UP." The UP is not loose or chaotic and not rigid or stagnant, but flexible or dynamic. The UP only specifies or suggests, practitioners make decisions and execute. Failure or inability to balance indicates or is symptomatic of being overly focused on the "letter of the UP" rather than the "spirit of the UP." This is a common Achilles heal of many Process Engineers and those applying the UP; that is, they are unable to balance.
Empower the Project Manager, Architect, and Process Engineer to bridge the chasm between the community's culture and project's vision. When empowered, the localization of forces in-between these roles and the rest of the team significantly heightens the potential for project success because it establishes a context for achieving balance. The Project Manager must be a leader and not simply a project administrator or rigid dictator. The Architect must be a leader and not simply a theoretician or technologist, not overly pedantic or overly pragmatic. The Process Engineer must be a facilitator or enabler and not a process enforcer. The team must be able to stretch to address challenges and seize opportunities, but not break! Each discipline has a role who leads the overall effort within the discipline and who owns and maintains the model ("big picture") associated with the discipline, and each discipline has other roles who own and maintain the details ("small picture") within the model.

Even though many guidelines apply to the Process Engineer specifically, they may apply to other roles. Furthermore, other guidelines may be applied in addition to those above.

Balance

When applying the UP, we ought to be balanced and be aware of the following guidelines:

Always seek balance; it is not all or nothing without reason and justification! A Process Engineer must consider those roles, activities, and artifacts that necessarily, sufficiently, and consistently address risk and enable project success. Something is necessary if it is required; sufficient if it is enough to satisfy a given purpose; and consistent if it does not contradict or conflict with other things. Consistency may be managed via the use of guidelines. Failure or inability to facilitate necessity, sufficiency, and consistency indicates or is symptomatic of a lack of focus on the essential elements of the UP and understanding the value each process element contributes within the process framework. A Process Engineer who suggests utilizing everything in order to ensure maximum coverage for addressing risk and making sure nothing has been overlooked is impractical and demonstrates this failure and inability!
For roles, it is not typically the case that a project requires all or none of the roles. For roles, it is not typically the case that all or none of the team members are assigned to all or none of the roles. Always ask the "original question" regarding roles!
For activities, it is not typically the case that a team does all or none of the activities. For the activities that a team does, is not typically the case that the team does them in all their detail instantaneously, but only as sufficiently necessary. Always ask the "original question" regarding activities!
For artifacts, it is not typically the case that a team produces all or none of the artifacts. For the artifacts that a team produces, is not typically the case that the team produces them in all their detail instantaneously, but only as sufficiently necessary with evolving levels of detail. Always ask the "original question" regarding artifacts!
For iterations, it is not typically the case that there is constant or no rework or change. For rework or change, it is not typically the case that nothing or everything is reworked or changed. For rework or change, it is not typically the case that such things occur without a reason or for any and every reason. Always ask the "original question" regarding iterations.
Beware of a Process Engineer who can "justify" everything without qualification. To the "original question," such a person often replies with "Well ...!" Beware of a Process Engineer who can't "justify" anything. To the "original question," such a person often replies with "Trust me ...!"
Beware of purists and extremists, those who focus on the "letter of the UP" rather than the "spirit of the UP." Pragmatically, sooner or later, such purists and extremists will be forced to move toward a more balanced middle ground of compromise in order to facilitate project success. Failure or inability to move toward a more balanced middle ground indicates or is symptomatic of a very significant risk to the project. This is a common Achilles heal of many Process Engineers and those applying the UP; that is, they are unable to balance.

Even though many guidelines apply to the Process Engineer specifically, they may apply to other roles. Furthermore, other guidelines may be applied in addition to those above.

Iterate

When applying the UP, we ought to iterate and be aware of the following guidelines:

Phases provide focus for iterations. Applying iterations outside the context of phases results in the appearance that iterations are loose and chaotic or rigid and stagnant rather than flexible and dynamic. Applying iterations that focus on nothing or everything hinders the ability to demonstrate progress. When planning, executing, and evaluating an iteration for a specific project, consider the phase of the iteration, the specific objectives of the phase, and how to satisfy the objectives within the context of the specific project.
Iterations are negotiated time-boxes. When an iteration's beginning, end, and content are not negotiated among stakeholders, stakeholders reject ownership of the iteration, thus impacting their contribution and participation within the iteration and project.
Focus and balance are critical and essential for a successful iteration and project. Without a purpose and objective, stakeholders don't have the ability to prioritize, dialog, negotiate, agree, and attain consensus. Notice that this order of abilities is fundamentally cumulative; that is, without a purpose and objective, one cannot constructively prioritize; without the ability to prioritize, one cannot have a constructive dialog with other stakeholders; without the ability to dialog, one cannot constructively negotiate; without the ability to negotiate, one cannot reach agreement; and without the ability to reach agreement, one cannot reach broad consensus. Beware of stakeholders who lack such abilities!
Don't "kill" ("castrate") an iteration, unnecessarily! That is, don't prematurely terminate an iteration because this will impact making the ramifications of the iteration and genuine status of the project visible to stakeholders. Only due to catastrophic changes where completing the iteration simply expends resources without providing demonstrable progress should an iteration be castrated. For example, killing the current iteration of a project may be justified if the project's requirements-related or technical assumptions have been significantly invalidated.
Don't "pollute" ("adulterate") an iteration, unnecessarily! That is, don't modify the scope of an iteration by adding use cases because this will impact making the ramifications of the iteration and genuine status of the project visible to stakeholders. Only due to unanticipated or unplanned requirements that may have catastrophic results if not introduced (in the current iteration) should an iteration be adulterated with these requirements. However, it is preferable that these requirements be fed into future iterations. For example, polluting the current iteration of a project may be justified if the project will lose funding if a specific unanticipated requirement is not introduced in the current iteration.
Don't "extend" ("mutate") an iteration, unnecessarily! That is, don't extend the end of an iteration in order to accommodate use cases because this will impact making the ramifications of the iteration and genuine status of the project visible to stakeholders. Only due to requirements that may have catastrophic results if not addressed (in the current iteration) should an iteration be mutated to accommodate these requirements. However, it is preferable that these requirements be fed into future iterations. For example, extending the current iteration of a project may be justified if the project will lose funding if a specific requirement is not addressed in the current iteration, thus requiring the current iteration's end to be extended.
Don't "fester" (or allow the team to "fester"), but progress! That is, use iterations to enable the team to gain a sense of accomplishment.
Strategize, execute, assess, and be agile (reactively adapt and proactively evolve the team and individual people, process, and tools) across iterations and throughout the lifecycle. Focus, then use, leverage, and exploit assets! That is, given a project's assets (the team and individual people, process, and tools), use them for operational and tactical purposes, use them to gain a strategic advantage, and use them to maximize this advantage. To succeed, localize forces that facilitate success in the context of forces that impede success; and then focus, balance, and iterate to bridge the chasm between culture and vision.

Furthermore, other guidelines may be applied in addition to those above.

Conclusion

Unequivocally, people are the "original ingredient" necessary for success. Don't standardize and enforce the UP, but empower people to leverage the UP! Don't focus on process then projects, but focus on teams because when teams succeed, their projects succeed using their process! Likewise, the UP is "scientifically" defined, but "artistically" applied!

As the Unified Process (UP) is a use-case-driven, architecture-centric, iterative and incremental development process framework that leverages the OMG's UML and SPEM, by understanding the UP, iterations, and being aware of various guidelines (lessons learned), we have a sound foundation for effectively and successfully applying the UP. Furthermore, it is experience, experimentation, and application of the UP and its various elements that will enable us to realize its benefits.

Related Methods & Tools articles

More Unified Modeling Language (UML) Knowledge

Click here to view the complete list of archived articles

This article was originally published in the Spring 2002 issue of Methods & Tools