Process Framework based on RUP Phases, RUP Iterations and EPIC Principles
This section presents the EPIC [ALB0702,ALB1102] principles in the context of RUP phases and RUP iterations. The
EPIC principles are the following:
Iteratively Converging Decisions
In order to maintain balance between the four spheres, EPIC creates an environment that supports the iterative
definition of the four spheres over time while systematically reducing the trade space within each. This allows a
decision in one sphere to influence, and be influenced by, decisions in the other spheres. Initially, as shown at the
left of the figure below, the trade space may be large. There is flexibility for making tradeoffs between the
stakeholder needs and user business processes, the architecture and design, the offerings of the marketplace and other
sources, and programmatics and risk. As EPIC is used to drive toward a refined understanding of the solution, the trade
space shrinks. The spheres increasingly overlap as fewer decisions remain in any single sphere that can be made without
significant impact on the others.
An iterative development process is necessary to keep the requirements and architecture fluid as the four spheres of
influence are considered and adjusted in order to optimize the use of available COTS packages. Each iteration contains
tasks that gather information from each of the four spheres. Each iteration refines the newly gathered information
through analysis and negotiation with affected stakeholders, to form the harmonized knowledge needed to assemble an
executing system implementing the solution and supporting the needed user business processes. The iterations are
managed by the four RUP phases and associated milestones.
Accumulating Knowledge
Concurrent with diminishing the trade space, knowledge about the solution must grow at a controlled pace. This
knowledge is reflected in the set of artifacts necessary to evaluate, recommend, acquire, install, configure, field and
evolve the solution. Most of the artifacts are started in outline form and are expanded as more information is gathered
and refined. This knowledge includes an increasingly detailed understanding of the following:
-
Capabilities and limitations of candidate COTS packages, the vendors that produce them and the marketplace
drivers that control them.
-
Negotiated and prioritized stakeholder needs and user business processes.
-
Architectural alternatives and mechanisms to integrate the COTS packages into the acquiring environment.
-
Implications of the COTS packages on the stakeholder needs and user business.
-
Planning necessary to implement and field the solution (including any needed user business changes) and
associated cost, schedule and risk.
It is particularly important to keep knowledge current about the COTS packages critical to the solution and the
marketplace or other sources that supply COTS packages. This allows the organization to track trends that may affect
the solution over time. This also allows them to keep the volatility of the marketplace in balance with the need for
stability in building, fielding and supporting the solution in operations. Monitoring and evaluation begin at project
initiation and continue until the solution is retired.
Increasing Stakeholder Buy-in
While decisions are converging and knowledge is accumulating, the stakeholders must increase commitment to the evolving
definition of the solution. Since these stakeholders are a broad and possibly disparate group, this will be difficult
for many projects as this commitment is significant, even unprecedented. Active participation from the stakeholders,
however, is essential to the success of the solution. Creating an environment that includes the stakeholders (or
empowered representatives) directly affected by any change in user business processes allows quick resolution to
discovered mismatches between the available COTS packages, the desired user business processes, and the stated
stakeholder needs, while simultaneously demonstrating that the solution can be built within cost and schedule
constraints with acceptable risk.
End-user needs mature and change with increased understanding of available COTS packages. The day-to-day involvement of
users is essential because the tasks that identify, evaluate and select COTS packages will shape the user business
processes and define the functionality that will be delivered. At the same time, architectural stakeholders ensure that
the COTS packages considered can be effectively integrated within the broader organization's existing systems to meet
required performance parameters. Business analysts must ensure that viable vendors support the COTS packages. Vendor
involvement can provide enhanced visibility into the COTS package's capabilities and potential insight for the vendor
into the organization's needs. The continuous negotiation and reconciliation among affected stakeholders leads to a
more effective use of COTS packages in satisfying the mission.
The stakeholders confirm and increase their buy-in and commitment to the evolving definition of the solution based on
an iteratively evolving executing system implementing the solution. An executing system is essential to reduce the
risks due to misunderstandings or unforeseen technical and operational factors.
Process Framework based on RUP Evolution Cycles
Across the life of a large or complex project or program, many generations of the solution, often overlapping, evolve
in response to new technology, new COTS packages and new operational needs. The four RUP phases are repeated for each
new generation (called RUP Evolution Cycle), until the solution is retired.
For instance, acquiring and implementing a COTS package could be done in a progressive fashion, where the final COTS
package solution is realized through a series of operational increments that advance the solution capabilities (see
Wideman's five white papers on Progressive Acquisition [WID1202, WID0103, WID0203, WID0303, WID0403]). Following the first development
cycle (first path through inception, elaboration, construction and transition) that produces the first operational
increment, each subsequent evolution cycle can be initiated with a new contract that focuses on the latest known
requirements, without having to invoke the full evaluation procedure that takes place in inception and elaboration
during the first development cycle. Instead, a simplified and more efficient version of the process is invoked.
|