Spiral Model Implementation in RUP

The Rational Unified ProcessA Commercially Available Spiral Model Implementation

Walker Royce

Marketing Library Proposal, SPreston, Field Marketing, 1/27/99

OverviewHow does RUP relate to the spiral model?Commercial process frameworkHow have software processes evolved?Resource expenditure profiles across workflowsThe State of the RUPLessons learned


The RUP Iterative Life Cycle


Evolving Levels of DetailGet the architecture right first (the stuff that counts), then worry about completeness and precision.The ability to balance life-cycle accuracy and precision is a discriminating management skill.


Iterative Life-Cycle Activities


More balance; less waste during integration and testOne View of Software Process Evolution


RUP Workflow

Conventional

Process

(Waterfall)

Modern

Process

(Iterative)

Future

Process

Management

5%

10%

12%

Requirements

5%

10%

12%

Design

10%

15%

20%

Implementation

30%

25%

14%

Test &Assessment

40%

25%

18%

Deployment

5%

5%

12%

Environment

5%

10%

12%

100%

100%

100%

Resource Allocation Trends


The State of the RUP1000s of project users, 100s of projects/organizationsUsed across a broad range of spiral-oriented projectsRe-architecting or upgrading of legacy systemsNew system/product developmentsComponent based system developmentBusiness modeling-system engineeringCurrent situation:Strong process framework (still requires tailoring)Biggest strength: unifies the project team and stakeholdersHomogeneous process language and web-based online e-coachBiggest weakness: too easy to interpret as cookbookStill requires domain tailoring, common sense to be added


Current RUP Improvement Thrustse-business guidelines (Web oriented applications)Analysis and design patterns and frameworksImproved testing emphasis across the life cycleExpanded business modeling workflowImproved deployment workflowExplicit "build" as an artifactDesigning for usability guidanceUML based metrics and project dashboardThese thrusts reflect experience from field applications


Future RUP Improvement ThrustsSupport for process variantsConfigurability and navigation improvementsLocalizations (Japanese, Chinese, etc.)Rational Process WorkbenchProcess authoring and compilation supportUPM (Unified Process Meta-Model) and OMG submittalIntegration to a project portalWeb-based project artifact repository


The phases of the macroprocess correspond to the spiral model as illustrated in the graphic.-Inception. For the development of a new product, the main outcome of this phase is a go-no go decision to move into the next phase and an investment of time and money to analyze what it is that needs to be built and the feasibility of building it.-Elaboration. As part of this phase, an executable architecture baseline is evolved in one or several iterations depending on the scope, size, risk, and novelty of the project. This could include the development of one or more exploratory, throw-away prototypes to mitigate specific risks, refine the requirements, perform feasibility and human-interface studies, and demonstrate to investors.-Construction. This phase is broken down into several iterations, fleshing out the architecture baseline and evolving it toward the final product. At each iteration, the various artifacts prepared during the elaboration phase are expanded and revised, but they ultimately stabilize. -Transition. This is the phase where the product is put into the hands of its end-users. Efforts include marketing, packaging, installing, configuring, making corrections, and supporting the user community.Each state of development represents a certain amount of precision in the final system description. Early in the life cycle, precision is low and the representation is generally high. Eventually, the precision of representation is high and everything is specified in full detail. At any point in the life cycle, the different sets should be in balance; that is, they should be at compatible levels of detail and reasonably traceable to each other.As development proceeds, each of the parts evolves in more detail. When the system is complete, all four sets are fully elaborated and consistent with each other. Unlike the conventional practice, you do not specify the requirements, then do the design, and so forth. Instead, you evolve the entire system; decisions about the deployment may affect requirements, not just the other way around. The key emphasis here is to break the conventional mold, where the default interpretation is that one set precedes another. Instead, one state of the entire system evolves into a fuller state of the system, usually involving evolution in each of the parts. During the transition phase, traceability between the requirements set and the deployment set is extremely important. The evolving requirements set captures a mature and precise representation of the stakeholders acceptance criteria, and the deployment set represents the actual end-user product. Therefore, during the transition phase, completeness and consistency between these two sets are important. Traceability among the other sets is necessary only to the extent that it aids the engineering or management activities.

The macroprocess is composed of discrete phases and iterations but not discrete activities. There is a continuum of activities that go on in each phase and iteration. Management includes management activities, development of plans and business case, assessment of status, coordination of stakeholders and resource control for the project.Requirements capture includes development of the use case models, and specification of the project vision and evaluation criteria.Design includes implementation of the software architecture baseline, development of the design models, high-level design of all applications, and integration.Implementation includes low-level design activities, component coding, component testing, and maintenance. (Maintenance includes changes made to software components once they have been transitioned to a software baseline and are under change management control.)Assessment includes measurement and assessment activities necessary to demonstrate that the integrated software baselines meet the evolving evaluation criteria and are acceptable implementations of the project vision. Deployment activities are related to the transition of the product to the user community, including site/user preparation, user manual development, and training.Environment includes the administration and integration of the development environment and toolsmithing. It also includes administration of the change management database.

One view of the future is the trend in how software project teams spend their time and resource across the various project workflows. Here is my view on how planning and expenditure allocations will change in the years to come as modern project management methods, processes and software development technology matures. The trend toward more balance across the primary workflows is predominantly due to the elimination of more and more sources of error and more efficient processes.Two major trends will continue:1) More and more automation of implementation activities and reuse of commercial components will reduce implementation activities with added burden on design activities2) More mature iterative development methods and web based architectures will drive deployment activities into a larger role within the life cycle.If we extrapolate this trend out into the future, we should end up with a flat allocation of resources across these workflows. When we at Rational debated how many discrete workflows we would end up with and what they would contain as far as activities, this balanced resource allocation was one target goal. In other words, we tried to define workflows that would have a target state of equal resource allocation as we approached the point where software technology and software management processes reached a point that we could call it a mature engineering discipline.

Documents

Spiral Model Implementation in RUP