The Rational Unified Process

Department of Computer ScienceMlardalen University

Emil EricMajid Gorbani

Andreas Selenwall

June 10, 2004

1

Abstract

It is claimed that only 26% of major IT projects are successful. Thereare many reasons for this, but one way to make a project more likely tosucceed is to use a formal process for software development. The RationalUnified Process (RUP) is such a process. RUP was developed by unifyingseveral object oriented development processes. The RUP has also formedthe basis for many variants including the Unified Process, an open initia-tive and many commercial derivations. This report describes the processmodel from analyzing, designing, implementing, testing and maintenanceto the final delivery of the product.

Keywords: RUP, UP, OPEN, software development, process phases,workflow

2

Contents

1 Introduction 51.1 Problem area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Process description 62.1 Static structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1 Workers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.2 Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.3 Artifact . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.4 Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Dynamic Structure: Iterative Development . . . . . . . . . . . . 82.2.1 The sequential process . . . . . . . . . . . . . . . . . . . . 82.2.2 Four process phases . . . . . . . . . . . . . . . . . . . . . 10

3 Process workflow 113.1 Project Management Workflow . . . . . . . . . . . . . . . . . . . 11

3.1.1 Project Risk . . . . . . . . . . . . . . . . . . . . . . . . . 123.2 Business and Requirements Modelling . . . . . . . . . . . . . . . 13

3.2.1 Business Modelling . . . . . . . . . . . . . . . . . . . . . . 133.2.2 Requirements Modelling . . . . . . . . . . . . . . . . . . . 14

3.3 The analysis and Design workflow . . . . . . . . . . . . . . . . . 143.3.1 Analysis versus design . . . . . . . . . . . . . . . . . . . . 153.3.2 The analysis model . . . . . . . . . . . . . . . . . . . . . . 153.3.3 The design model . . . . . . . . . . . . . . . . . . . . . . . 15

3.4 The implementation workflow . . . . . . . . . . . . . . . . . . . . 163.4.1 Builds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.4.2 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . 173.4.3 Prototypes . . . . . . . . . . . . . . . . . . . . . . . . . . 183.4.4 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.5 Test workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.5.1 Testing in the iterative lifecycle . . . . . . . . . . . . . . . 193.5.2 Type of test . . . . . . . . . . . . . . . . . . . . . . . . . . 193.5.3 The test model . . . . . . . . . . . . . . . . . . . . . . . . 203.5.4 Workers and artifacts . . . . . . . . . . . . . . . . . . . . 213.5.5 The test workflow . . . . . . . . . . . . . . . . . . . . . . 21

4 Project Planning with the Rational Unified Process 224.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.2 Project Start Activities . . . . . . . . . . . . . . . . . . . . . . . 22

4.2.1 Developing a Business Case . . . . . . . . . . . . . . . . . 224.2.2 Identify and Assessing risks . . . . . . . . . . . . . . . . . 234.2.3 The Vision . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.3 Initiating the project . . . . . . . . . . . . . . . . . . . . . . . . . 244.3.1 The Software Development Plan . . . . . . . . . . . . . . 24

3

4.3.2 The iteration plan . . . . . . . . . . . . . . . . . . . . . . 254.3.3 The architecture . . . . . . . . . . . . . . . . . . . . . . . 274.3.4 Building and testing products . . . . . . . . . . . . . . . . 27

5 Related process models 275.1 OPEN: an overview . . . . . . . . . . . . . . . . . . . . . . . . . 275.2 RUP and OPEN: a qualitative comparison . . . . . . . . . . . . . 28

5.2.1 Flexibility . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.2.2 Project management elements . . . . . . . . . . . . . . . . 29

6 Discussion and Conclusion 30

4

1 Introduction

This chapter considers the purpose and limitations of the project and how theRational Unified Process(RUP) works in generall.

RUP is a software engineering process developed and marketed by RationalSoftware. It is a disciplined approach to assigning and managing tasks and re-sponsibilities in a development organization. The goal with this process is toproduce, within a predictable schedule and budget, high-quality software thatmeets the needs of its end users. RUP is a process ”framework” for softwaredevelopment, which covers the life cycle of a project and guides the developmentteam in the activities of project management as well as the technical activities.The RUP has a solid structure; its description is coherent and uses in itselfan object-oriented approach. Its structure transcends the traditional model ofthe development in cascade to offer a powerful software development frame-work based on a controlled and optimized iterative cycle. The RUP proposes aframework making it possible for an organization of software development of allsizes to work, extend and improve its process according to its objectives. TheRUP is a rich base of knowledge of the best practices harvested by Rationalover the years. RUP captures many of the best practices in modern softwaredevelopment and presents them in a tailorable form that is suitable for a widerange of projects and organizations. RUP delivers these best practices to theproject team online in a detailed, practical form.

1.1 Problem area

The problem of systems engineering is to design and implement a system thatmeets a broad set of requirements [1]. Depending on circumstances, there mightbe other system requirements such as logistics support, security, and remotetraining needs. Some of these requirements are familiar to software development.Some cannot be addressed without hardware, software, and worker considera-tions. Systems design requires that all three types of components be specifiedconcurrently. The system problem then differs from the software-only problemin that system engineering addresses a broader set of requirements than arenormally addressed in software efforts. A way to handle these problems is touse the Rational Unified Process (RUP), like a process model, that addressesthe problem of system specification, analysis, design, and development.

1.2 Purpose

The purpose with this project is to make research to see how the RationalUnified Process (RUP) works.

5

2 Process description

2.1 Static structure

A model process describes who does what, how, and when. The Rational UnifiedProcess is represented with the use of four primary modeling elements, which areworkers, activities, artifacts, and workflows. A worker defines the behavior andresponsibilities of an individual or a group of individuals working as a team.Workers represent a role played by individuals on a project, and define howthey carry out their work. Workers have activities, which define the work theyperform. An activity is something a worker does that provides a meaningfulresult in the context of the project. Activities have input and output artifacts.An artifact is a work product of the process; workers use artifacts to performactivities, and produce artifacts in the execution of activities. Artifacts arepieces of information that are produced, modified, or used by a process.

Core workflows, in the Rational Unified Process, represent a partitioning ofworkers and activities into logical groupings called areas of concern or disci-plines. The core process workflows are grouped into six engineering workflows:Business Modeling, Requirements, Analysis and Design, Implementation, Test,and Deployment; and three supporting workflows: Project Management, Con-figuration and Change Management, and Environment.

Three individuals elements are shown in figure 1.

Figure 1: Static structure

6

2.1.1 Workers

The worker is the core element in the whole process, as a result the workersdefined the behaviour and responsibilities of an individual or a group of indi-viduals working together as a team. It is helpful to think of a worker as a hatthat an individual can put on during the project. One person may have onmany hats. This is important because it is common to think of a worker as theindividual or the group, but in the RUP the term worker refers to the roles thatclassify how the individuals should do their work.

Some examples that a worker possibly will be take part in are:

• System analyst – a person acting as system analyst leads and coordinatesrequirements elicitation and use-case modelling by outlining the systemsand delimiting the system.

• Designer – a person acting as a designer defines the responsibilities, oper-ations, attributes and relationships of one or more classes.

• Test Designer – a person acting as a test designer is responsible for theplanning, design, implementation and evaluation of tests.

It is essential to know that workers are not individuals. They explain thatan individual should conduct itself in the business and the responsibilities ofeach individual.

2.1.2 Activities

Each worker has activities, which characterize the work they perform. An ac-tivity is a unit of work that an individual in that role may be asked to perform,and that produces a consequential result in the context of the project. Thepurpose of the activity is to create or update artifacts such as a model, classor a plan. Every activity may be frequently doing some operation on the sameartifact, particularly from one iteration to another as the system is refined andexpanded. Some instances of the activities:

• Plan an iteration: performed by the worker: Project Manager

• Find use cases and actors: performed by the Worker: System Analyst

• Review the design: performed by the Worker: Design Reviewer

• Execute a performance test: performed by the Worker: PerformanceTester

2.1.3 Artifact

Activities have input and output artifacts. An artifact is information that isproduced and modified or used by a process. Below is some examples of whatan artifact could looks like:

7

• A model, such as the use-case model or the design model

• A model element - an element within a model - such as a class , a use case,or a subsystem

• A document, such as a business case or software architecture document

• Source code

• Executables

2.1.4 Workflows

A simple record of all workers, activities and artifacts does not quite representa process. We need a way to describe meaningful sequences of activities thatproduce some important result and to show interactions between workers. Aworkflow is a sequence of activities that produces a result of observable val-ues. In UML terms, a workflow can be articulated as a sequence diagram, acollaboration diagram, or an activity diagram.

The Rational Unified Process is organized to reach the goal using the fol-lowing:

• Core workflows

• Workflow details

• Iteration plans

2.2 Dynamic Structure: Iterative Development

2.2.1 The sequential process

There has been a lot of problems and failures in software development on thesequential or waterfall process. This is surprising because at first, this methodseems like a reasonable approach to system development.

The typical step to solve a problem by sequential process can be as follow:

1. It is a requirement to completely understand the problem and write downto get all interested part figuring out what they (users) accomplish.

2. Design a solution that can satisfy all requirements and constraints.

3. Implement the solution.

4. Verify that the implementation satisfy the requirement.

5. Deliver.

8

Figure 2: The sequential process

The representation below shows the whole sequential process.This kind of planning is the common development method used by building

constructors because the problem field is relatively well known; the engineerscan draw on hundreds of years of experimentation in design and construction.But in contrast, software engineers have had only a few decades to explore theirfield. During the seventies and eighties the software developers worked veryhard to accumulate experimental results in software design and during the 1980the sequential problem solving was the only method used.

In the sequential processing the developers have only one shot on each stepof sequence of project, with very little opportunity to learn from their mistakes.The design must be almost perfect and also the rest of the sequence like coding,programming and testing whitout any errors or fault.

If the sequential, or waterfall processing works for the short projects or thosewith a small amount of novelty or risk, RUP breaks down the lifecycle of a largeproject into a succession of small waterfall projects. In this way you take asmaller step each time on every sequence and you have time to address somerequirements and some risks, design a little, implement a little, validate it, andthen take on more requirements, design some more, build some more, validate,and so on, until you are finished. This is the iterative approach.

Figure 3 shows the difference of sequence and iterative processing.The iterative process breaks a development cycle into a succession of iter-

ations. Each sequence looks like a mini waterfall and involves the activities ofrequirements, design, implementation, and assessment.

9

Figure 3: Difference between sequential and iterative approach

2.2.2 Four process phases

Phases and milestones To control the project and to give the appropriatefocus for each iteration, a development cycle is divided into a sequence of fourphases that partition with help of milestones the sequence of iterations. Thesemilestones provide points at which we can decide to proceed, abort, or changecourse. Finally, we must partition and organize the sequence of iterations ac-cording to specific short-term objective.

Figure 4: RUP four phases

The Rational Unified Process consists of cycles that may repeat over thelong-term life of a system. The software lifecycle is based on four phases, throughwhich the project evolves linearly in time. The phases are: Inception Phase,Elaboration Phase, Construction Phase, and Transition Phase. Each of thesephases is composed of one or more iterations and follows a waterfall patterncontaining requirement elicitation, analysis, design, implementation, test, and

10

deployment, and results in a release (either internal or external) of an executableproduct, which grows incrementally from iteration to iteration to become thefinal system. Each phase is concluded with a well-defined milestone - a point intime at which a certain critical decisions must be made, and therefore key goalsmust have been achieved.

Lets briefly review the four phases in a cycle: for example

• Inception Phase – During the inception phase the core idea is developedinto a product vision. In this phase, we review and confirm our under-standing of the core business drivers. We want to understand the businesscase for which the project should be attempted. The inception phaseestablishes the product feasibility and delimits the project scope.

• Elaboration Phase – During the elaboration phase the majority of the UseCases are specified in detail and the system architecture is designed. Thisphase focuses on the ”Do-Ability” of the project. We identify significantrisks and prepare a schedule, staff and cost profile for the entire project.

• Construction Phase – During the construction phase the product is movedfrom the architectural baseline to a system complete enough for transitionto the user community. The architectural baseline grows to become thecompleted system as the design is refined into code.

• Transition Phase – In the transition phase the goal is to ensure that therequirements have been met to the satisfaction of the stakeholders. Thisphase is often initiated with a beta release of the application. Other activ-ities include site preparation, manual completion, and defect identificationand correction. The transition phase ends with a postmortem devoted tolearning and recording lessons for future cycles.

The four phases (Inception, Elaboration, Construction, and Transition) con-stitute a development cycle and produce a software generation. The iterativeapproach accommodates changes in requirements and in implementation strat-egy. It confronts and mitigates risks as early as possible. It allows the develop-ment organization to grow, to learn, and to improve. It focuses on real, tangibleobjectives.

3 Process workflow

3.1 Project Management Workflow

The purpose of the Project Management Workflow is to provide a frameworkfor managing risks, by practical guidance on how to plan, execute and mon-itor projects. The project plan encapsulates the process the project shouldfollow, divide the problem into sub-tasks, assigning tasks to teams and settinga timescale for each task. The plan evolves during the project’s lifecycle due

11

to monitoring and measurements of the product so far. A project plan is di-vided into two parts, the phase plan and the iteration plan. The phase plan is acoarse-grained plan with overall information about each of the four phases, andshould contain date of major milestones, staffing estimates for each phase anestimation of the numbers of iterations included in each phase. Iteration planis the detailed plan for each iteration and should describe that exact iteration.Each iteration plan includes

• Requirements

• Analysis and Design

• Deployment

• Test and evaluation

In each iteration you should identify tasks, tasks and sub tasks, and establishstart and end dates for each task. Gannt charts are often used to show tasksstart and end date.

Each iteration also addresses three extra workflows items.

• Monitoring and Control Project – Checking that the project is on plan

• Plan for extra iteration – Develop the plan for the next iteration

• Manage iteration – Monitors progress of the project and plans for the nextiteration, deciding when to change iteration and whether the project stillis viable.

3.1.1 Project Risk

A risk comprises three elements

• An undesirable event

• An estimate of the severity of the consequnces of the event

• The probability that the event will occur

The risk of the project is a good basis for if the project is viable.The artifacts produced in the Project Management Workflow is the Software

Development Plan, the Business case, detailed plan for each iteration and workschedule.

The Software Development Plan consists of

• Measurement plan

• Risk management plan

• Product acceptance plan

• Problem resolution plan

12

• Project organization and staffing

• Monitoring and control processes

• Plan phases and iterations

3.2 Business and Requirements Modelling

There are nine core workflows in the Rational Unified Process which can bedivided into two groups, Core Process Workflow and Core Supporting Workflow.

Core Process Workflows

• Business modelling

• Requirements

• Analysis and Design

• Implementation

• Test

• Deployment

Core Supporting Workflows

• Configuration and Change Management

• Project Management

• Environment

The Core Supporting Workflows are the administrative parts of the projects,how to communicate within the project, the project plan and which type ofenvironment we are developing for and which we are developing in.

3.2.1 Business Modelling

In business modelling there are three active workers, the Business Process An-alyst, the Business Designer and the Business Model Reviewer. In BusinessModelling we document business processes using business use cases. This as-sures a common understanding between all stakeholders (a stakeholder is anyperson or representative of an organization who has a stake - vested interest -in the outcome of a project, [7] ) what business process needs to be supportedin the model.

The Business Case developed provides the business information necessary todetermine if the project is worth investing in, Return On Investment (ROI). Itsmain purpose is to develop an economic plan for realizing the Vison. The Busi-ness Case definition must contain the answer to ”Why is the product needed?”.It must be brief and easy for the team members to understand. At critical

13

milestones in the project there must be a check if the project is accurate to theROI stated in the Business Case and if the project should be continued.

One of the major problems that can occur in Business Modelling is lack ofcommunication between the business engineering team and the software engi-neering team, thus the output from business engineering is not used properlyin the software development. The Rational Unified Process address this prob-lem by providing a common language to communicate between teams and thuspreventing this problem from occuring. The output from this workflow is doc-umented in a Business Object-model. Business Modelling is one of the firstthings you do in the project since the result of Business Cases and Return OnInvestment is the information stakeholders will use to decide if the project isworth investing in. After the project is approved other activities can start.

3.2.2 Requirements Modelling

In the requirements workflow we identify what the system should and shouldnot do and what requirements to prioritize. This is done through meetings withthe customer, refining the requirements after each meeting until the requirementteam has the same picture of the system as the customer. In the process we willfind and document actors and use-cases.

The three active workers in the Requirements workflow are, the SystemAnalysts, the Software Architect and the Requirements Reviewer.

Each worker has its own role in capturing the requirements.

• The System Analysts has the role of

– Finding a common vocabulary - to assure that the requirements teamunderstand what the customer wants

– Develop the requirements management plan

– Finding actors and Use-Cases

– Develop a Vision – capture the importance of the requirements work-flow, analyzing the problem, understand stakeholders needs, definingthe system and managing the requirements as they change

– Elicit stakeholders requests - see that the requirements are under-stood

• Software Architect – Prioritize Use-Cases - find which Use-Cases are moreimportant and urgent than others.

• Requirement Reviewer – Review requirements.

3.3 The analysis and Design workflow

Analysis and design bridge the gap between requirements and implementation.This workflow uses use cases to identify a set of objects that is subsequentlyrefined into classes, subsystems and packages. Analysis and design result in a

14

design model, which can be abstracted using three architectural views. The log-ical view presents the decomposition of the system into a set of logical elements,e.g. classes, subsystems, packages and collaborations. The process view mapsthose elements to the processes and threads in the systems. The deploymentview maps the processes to a set of nodes on which they execute.

3.3.1 Analysis versus design

The purpose of the analysis and design workflow is to translate the requirementsinto a specification that describes how to implement the system. Early in theproject, it is important to establish a robust architecture so it will be possibleto design a system that is easy to understand, build and evolve [3]. The purposeof analysis is to transform the requirements of the system into a form that mapswell to the software designers area of concern - that is, to a set of classes andsubsystems. This transformation is driven by the use cases and is shaped furtherby the systems non-functional requirements. Analysis focuses on ensuring thatthe systems functional requirements are handled. As a result, analysis expressesa nearly ideal picture of the system. The purpose of design, on the other hand,is to adapt the results of analysis to the constraints imposed by non-functionalrequirements, the implementation environment, performance requirements, andso forth. Design is a refinement of analysis. It focuses on optimizing the systemsdesign while ensuring complete requirements coverage.

3.3.2 The analysis model

There is generally one design model of a system; the analyse procedure intro-duces a very abstract view of the system which will later be defined in design.The first phase of this model is the aspects of the system. In some companies,which systems lives very long or there are many variants of the system, a sep-arate analysis model has proved very useful. The analysis model omits most ofthe details of how the system works and provides an overview of the systemsfunctionality.

The extra work required to ensure that the analysis and design models re-mains consistent must be balanced against the benefit of having a view of thesystem that represents only the most important details of how the system works.In figure 6, RUPs four phases in the analysis workflow are shown, e.g. the ar-chitectural analtysis, use case analysis, class analysis, package analysis and howthey are related to each other.

3.3.3 The design model

The design model consists of a set of collaborations of model elements thatprovide the behavior of the system. This behavior is derived from the use-casemodel and nonfunctional requirements. The design model consists of collab-orations of classes which may be aggregated into packages and subsystems tohelp organize the model and to provide compositional blocks within the model.

15

Figure 5: RUPs four phases in the analysis workflow [6]

A class is further a description of a set of objects that share the same respon-sibilities, relationships, operations, attributes and semantics. A package is alogical grouping of classes, perhaps for organizational purposes that reduce thecomplexity of the system. A subsystem is a kind of package consisting of a setof classes that act as a single unit to provide specific behaviors [9].

The designer defines the responsibilities, operations, attributes and relation-ships of one or several classes and determines how they should be adjusted tothe implementation environment. In addition, the designer may have respon-sibility for one or more design packages or design subsystems, including anyclasses owned by the packages or subsystems.

Design can optionally include the following workers:

• Database designer – the database designer is needed when the systembeing designed includes a database.

• Capsule designer – the capsule designer is a kind of designer who focuses onensuring that the system is able to respond to events in a timely manner.

• Architecture reviewer and design reviewer – these specialists review thekey artifacts produced through this workflow.

3.4 The implementation workflow

The implementation workflow has four purposes:

16

1. To define the code in terms of implementation subsystems organized inlayers.

2. To implement classes and objects in terms of components.

3. To test the developed components as units.

4. To integrate into an executable system the results produced by individualimplementers or teams.

[10] To define the implementation process; builds, integration and prototypesmost be taken in consideration.

3.4.1 Builds

A build is a part of a system, e.g. a subsystem that demonstrates a subset ofcapabilities to be provided in the final product. During the developing processthere will be numerous builds, each helping to recognize integration problems assoon as they are introduced. Builds are an integral part of the iterative lifecycle.Each build is placed under configuration control in case there is a need to rollback to an earlier version when added functionality causes breakage. Projectsgenerally try to produce builds at regular intervals, up to one each day, but atleast one per week toward the end of an integration.

3.4.2 Integration

Integration refers to an activity in which separate software components are com-bined into a whole. Integration is done at several levels of the implementationfor the following purposes:

• To integrate the work of a team working with the same subsystem beforethe subsystem is released to system integrators.

• To integrate subsystems into a complete system.

The RUP approach to integration is that the software is integrated incremen-tally. Incremental developmant means that code is written and tested in smallpieces and then is combined into a working whole, piece by piece. Incrementaldevelopment offers the following benefits:

• Faults are easy to locate. When a new problem occurs during the integra-tion, the new component is the first place to look for the fault. Incrementalintegration also makes likely that defects will be discovered one at a time,something that makes it easier to identify faults.

• The components are tested more fully. Components are integrated andtested as they are developed. This means that the components are exer-cised more often than they are when integration is done in one step.

17

• Some parts of the system are running earlier. It is better for the moraleof developers to see early results of their work instead of waiting until theend to test everything.

[16]

3.4.3 Prototypes

Prototypes are used in a directed way to reduce risk. A prototype is a variant ofa real product and is used to show something concrete and executable to users,customers and managers. You can view prototypes in two ways: by what theyexplore and by how they evolve [18]. In the context of the first view, there aretwo main kinds of prototypes:

• Behavioral prototype, which focuses on exploring specific behavior of thesystem.

• Structural prototype, which explores architectural or technological con-cerns.

In context of the second view, there are also two kinds of prototypes:

• Exploratory prototype, which is thrown away after it is finished and youhave learned whatever you wanted from it.

• Evolutionary prototype, evolves to become the final system.

3.4.4 Workflow

Implementation is tied closely to design, and there are clear tracing links fromdesign elements to implementation elements, for example classes to code. Thepersons playing the role as designers and implementers can either modify thedesign model and regenerate the corresponding code and then alter the designto match the modification. This closes a gap in the process and helps avoiderrors in translating the design.

3.5 Test workflow

The purpose of testing is to assess product quality. The test is not accrue in thefinal moment of the product development, but also begins early in the projectwith the assessment of the architecture and continues through the assessmentof the final product delivered to customers. The test workflow involves thefollowing:

• Verifying the interactions of components

• Verifying the proper integration of components

• Verifying that all requirements have been implemented correctly

18

• Identifying and ensuring that all discovered defects are addressed beforethe software is deployed.

When you talk about the quality in general it means principally the absenceof defects, but if the product does not reach the wished requirement, it is asuseless as the product with a defect.

The test workflow provides the feedback mechanism for the project, enablingquality to be measured and defects to be identified. Testing activities begin earlyin the project, with test planning and some assessment occurring even in theinception phase, and continue throughout the project.

3.5.1 Testing in the iterative lifecycle

Testing is not a single activity, nor is it a phase in the project during which weassess quality. If developers are to obtain timely feedback on evolving productquality, testing must occur throughout the lifecycle. The tests depends on theprojects current phase:

• In general, whenever there is an implementation result, there is a test

• Inception phase: initial test planning, prototype testing

• Elaboration phase: test architectural baseline

• Construction phase: significant testing at each build

• Transition phase: re-test fixes and regression tests

– Regression tests: in a new build, re-apply tests from old builds tomake sure nothing broke in new build

• Evolve test model

– Create new test cases for next build

– Refine prior test cases into regression tests

– Remove obsolete tests and corresponding test procedures and com-ponents

3.5.2 Type of test

The testing have many kind of types, each one focusing on specific area, a testof software during the development has many variation of testing, a test couldbe a single unit of code, integrated units, or a complete application or system.Here are some of the most common types of test:

• Benchmark test – comparing the performance of a target-of-test to aknown standard such as existing software or measurement

19

Figure 6: Testing during the software development lifecycle

• Configuration test – verifying that the target-of-test functions is an ac-ceptable manner on different configuration (hardware or software)

• Installation test – verifying that the target-of-test installs properly andcan be installed successfully on different configuration or under differentconditions, such as insufficient disk space or on the different operationsystem or platform

• Integrity test – verifying the target-of-test is reliable, robust, and resis-tance to failure during the execution

• Performance test – verifying the acceptability of the target-of-tests per-formance using various configurations while the operational conditionsremain constant

• Stress test – verifying the acceptability of the target-of-tests performancewhen abnormal or extreme conditions are encountered, such as diminishedresources or an extremely high number of users

The quality is everyones responsibility. Quality is not produced by a quality-personal or some testing organization.

3.5.3 The test model

The test model is an illustration of what will be tested and how it will betested. It is a view of the design and implementation models, depicting the

20

tests themselves, as well as aspects of the target-of-test that are relevant tothe testing effort. It includes the group of the test cases, test procedures, testscripts, and expected test results along with a description of their relationships.

• Test cases – the set of test data, execution conditions, and expected testresults developed for a specific test objective. Test cases can be derivedfrom use cases, design documents, or the software code.

• Test procedure – the set of detailed instructions for the setup, execution,and evaluation of test results for test case.

• Test components – the classes and components that realize the test de-signs, including drivers and stubs.

3.5.4 Workers and artifacts

Two main workers are concerned in the workflow:

• The test designer is responsible for the planning, design, implementation,and evaluation of testing. This involves generating the test plan and testmodel, implementing the test procedures, and evaluating test coverage,results, and effectiveness.

• The tester is responsible for executing the system tests. This effort in-cludes setting up and executing tests, evaluating test execution, recover-ing from executing tests, evaluating test execution, recovering from errors,assessing the results of testing, and logging change requests.

3.5.5 The test workflow

plan test The purpose is to identify and describe the testing that will beimplemented and executed. This is accomplished by generating a test plan thatcontains the requirements for test and test strategies. Test planning is done sothe test efforts can be measured and managed.

design test The purpose is to identify, describe, and generate the test modeland its reported artifact. The design is done to ensure that the test softwaremeets its requirements and is structured and organized well. In the designactivity, the test designer analyzes the target-of-test and develops the test modeland, in the case of performance test, the workload model.

implement test The purpose is to implement the test procedures that weredefined in the Design Test section. The creation of test procedures usually isdone in the contest of a test automation tool or programming environment. Theoutput artifact is a computer-readable version of the test procedure, referred toas a test script. If special test code (e.g., a test harness, drivers, or stubs) isneeded to support or perform testing, the designer and the implementer workwith the test designer to design and implements the test code.

21

4 Project Planning with the Rational UnifiedProcess

In this chapter we will take a closer look into the project planning and whatthe essentials are. To some of these essentials there are recommendations fromRUP on which are the key elements that should be in the documents [14].

4.1 Introduction

If the project is viable after the project start activities we will define the projectorganizational structure based on the project characteristics and external con-straints. The recommendations from the Rational Unified Process is to definein terms of positions, teams, responsibilities and hierarchy. We will also definestaff requirements based on effort estimates, desired schedule, chosen organiza-tional structure and mapping of roles, the RUP recommends that you definestaff required for the project by type (skills and the domain of the project),experience and caliber, that you adjust the software development team from itsbaseline during the project lifecycle, that is while the project moves forwarddifferent staff members are required in different positions. For example:

• In the Inception Phase the focus will be on management functions. De-veloping the Vision, etc.

• In the Elaboration Phase the focus will be on the architecure. The staffwill consist of more designers.

• In the Construction Phase the focus will be on developments. The staffwill consist of more developers.

• In The Transition Phase the focus will be on Quality Assurance / SoftwareAssessment.

4.2 Project Start Activities

4.2.1 Developing a Business Case

The idea with the business plan is to see whether the project is worth investingin, or Return Of Investment (ROI). It is up to the manager to find if the project isworth investing in and the report is the artifact. The business case is essential forthe future of the project, the stakeholders must feel that this is worth investingin due to the artifact and the market needs.

The following steps are recommended by the RUP when developing the busi-ness case:

1. Describe the product and the need it fulfills

2. Define the product or project objectives at a high level

22

3. Develop a financial forecast including projected revenues and costs for theproject

4. Describe the project constraints that could potentially impact risk andcost

5. Describe the options that could impact the projects success

4.2.2 Identify and Assessing risks

This an important task and its best place is in the startup of the project. Thispart builds a basis for risk mitigation in the iterations. RUP is risk-driven,that is, it focuses on risks and mitigate risks. This is done by identifying andhandling risks early in the development. In this process a Risk List will becreated by identifying in decreasing order of priority events that could lead toproblem, with each risk associated with a plan to mitigate the risk. The risksshould be a focal point for the planning project activities and a basis for howiterations are organized.

Its important to have continuos checks on the activities, what it producesand their configurations to track issues and handle them when they occur. RUPuses regular status assessments and provides a mechanism for addressing, com-municating and resolving management issues. Each issue should be assigned toa person accountable for the resolution.

RUP has some steps they recommend you follow when working on risks:

1. Identify potential risks that would decrease the likelihood that the devel-opment team will be able to deliver the project with the right features,the specified level of quality, on time and within budget.

2. Analyze and prioritize the risks by estimating the impact of each and thelikelihood of its occurence to determine the risk exposure for each risk

3. Identify risk avoidance strategies to reorganize the project so that you canreduce or eliminate risks

4. Identify risk mitigation strategies

5. Identify risk contingency strategies

6. Revisit risks frequently within iterations and subsequent phases

4.2.3 The Vision

Having a clear and correct Vision assures us that the project is defined afterand moving towards the stakeholders needs. The Vison captures the essenceof the Requirements Workflow by analyzing the problem, understanding thestakeholders needs, defining that system and managing the requirements asthey change. Some other features of the Vison Document is that it

• Provides a high-level basis for more detailed technical requirements

23

• Captures very high-level requirements

• Captures design constraints

• Provides input to the project-approval process – this part is closely relatedto the Business Modelling

• Problem statement – What is to be done?

The Vision also identifies stakeholders, users and what their needs are.

4.3 Initiating the project

After the Business Case is approved we start working on the Initiate Projectactivity. This activity will assign the Executive Management and Project Plan-ning team and will also set up the criteria for project completion, when thiscriteria is reached the project has successfully been completed. In this activityyou also assign a project review team who will be responsible for the overallview of the project, a project planning team responsible for the planning of theproject (gantt chart where we allocate resources for different activities), main-taining the project plan and report project status. Also this is when we approvethe project acceptance criteria (a way for the stakeholders and customers to de-termine when a delivered product is acceptable).

4.3.1 The Software Development Plan

A word of wisdom: ”The product is only as good as the plan for the product”,Johnson Space Center Shuttle Software Group

A Project Plans function is to give the team information about:

• Roles – who is doing what in the project

• Budget

• What to deliver and when

• Resource allocation – when a certain resource must be available and forwhat purpose

• Provides a basis for measuring progress and expenditures

• Gives the planner a baseline to support replanning activities

• Helps the customer and management to see what went wrong when aproject failes

The Project Plan is target based, it identifies deliverables on the project.It contains a variation of views depending on the stakeholder (the customer,team members and management), it must be measurable from a time view anda deliverable view, to easier identify what has been delivered and where we are

24

in the project timeline. Its also very important that each team member knowswhat have been delivered and what will be delivered. The plan must be up todate.

The Project Plan, or the Software Development Plan as it is called in theRational Unified Process, contains all information to manage the project and ismaintained throughout the project to keep it updated as it changes. The Soft-ware Development Plan contains the schedule for the project, the resource needsfor the project and compare progress against the schedule to update memberswith the actual progress of the project. Here are a list of the content of theSoftware Development Plan:

• Schedule – Project Plan, Iteration Plan, Resources and Tools

• Requirements Management Plan

• Configuration Management Plan

• Problem Resolution Plan

• Quality Assurance Plan

• Test Plan

• Test Cases

• Evaluation Plan

• Product Acceptance Plan

In smaller projects each part can consist of just a couple of words briefly de-scribing each part of the content.

The Software Development Plan is a very critical part of the project. Themajor activities are defining the project structure and estimating the size of theproject. IBM Rational have made an estimation of the project time by earlierexperience in software development. By their estimations, about 10

4.3.2 The iteration plan

For each iteration there is a related Iteration Plan, these are represented in theVision. The Iteration Plan is written after the project plan is completed. RUPis iterative and incremental, thus it is divided into phases and activities. Eachiteration in a phase is risk driven, the aim in each phase is to mitigate risk,this reduces the possibilities of future risks. Each iteration must have an iter-ation plan which contains a detailed description of that phase, which workersare needed and what they will do, activities and which artifacts will be deliv-ered. The Iteration Plan is more detailed than the project plan and has clearobjectives (and milestones) for each phase. To fully understand the projectscurrent status and it is progress is to identify which phase you are in, this mustbe realized by all project team members. Every phase delivers something. The

25

Figure 7: A graph showing time for each phase for a typical RUP project [11]

Inception Phase delivers for example the Vision document. Associated witheach deliverable is a workflow template which contains important aspects suchas activities, resources and other deliverables required to complete this deliver-able, and an artifact, the document produced by the project. RUP has providedus with some sample deliverables based on a normal RUP project.

• Business Cases - information about cost and benefits of the product

• Vision - What the product does, the market for the product and theproduct main features

• Use-Case Model - Defines the systems functional requirements

• Supplementary Requirements - non-functional requirements for the sys-tem, for example documentational requirements

As stated earlier there is a workflow associated with each deliverable. Theworkflow template idenitifies activities needed to create the deliverable. Anactivity includes roles which helps find what resources are needed and must befilled with actual workers, artifacts and guidance (help steps). Unfit activitiescan be omitted from an iteration (or project regarding the plan). Time for anactivity depends on the time allocated for the whole iteration.

To be able to see the progress of the project and if it is off-track and howto get the project back on track we use monitoring and control processes. Thisis usually done by checking the project so it follows the Software DevelopmentPlan (SDP) to see that the project is still in its scope. RUP has the followingrecommendations.

1. Define project indicators to alert the project manager to instigate correc-tive actions as required

2. Define sources for project indicators

26

3. Define and communicate a procedure and report frequency for projectteam members to report their status.

4. Define tresholds for the projects indicators.

5. Define a procedure for project status reporting

After each iteration assess success and failures, that is, compare results towhat was expected. For example functionality, performance, capacity and qual-ity. Also you should check if the requirements are still valid, if the goals are toohigh or too low and if the features of the product are still economically justified.After this control you might need to make some changes to the Vision documentand the risk list.

4.3.3 The architecture

The architecture should contain the structure of the systems significant com-ponents interacting through interfaces, ”What are the main pieces and how dothey fit together?”. The essence of the Analysis and Design Workflow are definea candidate architecture, refine the architecture, analyze behaviour and designcomponents of the system. The architecture design results in the SoftwareArchitecture Document which defines the architectural design which describesimportant aspects of the architecture, and multiple views with specific con-cerns, depending on the stakeholders (End User, Designers, Managers, SystemEngineers, Maintainers, etc).

4.3.4 Building and testing products

This is the essence of the Implement and Test workflow. The product is in-crementally coded, built and tested, each iteration (after the Inception Phase)delivers an executable. After the Elaboration Phase an architectural prototypewill be available for evaluation and a user-interface prototype might be included.Through each iteration in the Construction Phase components are integratedinto an executable.

5 Related process models

5.1 OPEN: an overview

Open is a tailorable process-focused framework for software development [19].It is described in terms of its metamodel or framework. The process itself iscreated as an instantiation of this framework. In figure 9, shown below, anoverview of the framework is described.

The framework is a combination of people in context of an organizationalculture; tools and available technology, together with Work Units (e.g. activ-ities and tags) and Work Products (e.g. code, planning and documents). It

27

Figure 8: An overview of the OPEN framework [12]

has a strong focus not only on software development but also on project man-agement [20]. OPEN combines the adaptability to construct a process to thespecific needs of an individual domain and continually adapt the process toparticular projects. This enhances the incorporation of component-based devel-opment architectural patterns that will be increasingly in demand.

5.2 RUP and OPEN: a qualitative comparison

5.2.1 Flexibility

A major difference between RUP and OPEN is that OPEN is a flexible meta-level framework, augmented by a repository of process component instances,from which industry creates their own organizationally tailored method. OPENcan be described as a component-based process construction facility. This givesa high degree of flexibility. RUP, on the other hand, is a pre-packaged, pre-configured instance of its own metamodel [21] and could be described as a tai-lorable methodology; that is, RUP is a pre-selected instantiation of a metamodelsuch as the OPEN framework [22].

According to official description of RUP, the tailoring is restricted to chang-ing relative durations; expanding, modifying and removing steps from specificactivities; adding new checkpoints to the review activities. A comparison of thecreation routes for RUP and OPEN is shown in figure 10.

28

Figure 9: Creation routes [15]

Figure 10: RUP phases and OPEN:s activities [17]

5.2.2 Project management elements

The key element in OPEN is that the linkages between activities and tasks and,secondly, between tasks and techniques are accomplished, as throughout OPEN,

29

by the use of possibility matrices which assist the method engineering in tailor-ing the most high quality software development in the most efficient manner.OPEN also suggests that you define your own project charter which containsan agreed statement on (1) Business Statement, (2) Problem Statement, (3)Description, (4) Context Model, (5) Methodology, (6) Project Resource Esti-mates and Schedules, (7) Quality Assurance, (8) Implementation Review and(9) Risk Analysis [23]. This charter is an encapsulated agreed statement on theconstraints and resources available. In contrast, in RUP all of the project man-agement elements are grouped together as a separate project management subsetsupporting workflow, which operates in parallel to the other subset workflowsand across each iteration workflow. In addition, the actual depth of support forproject management is limited. And use of non-standard project managementterminology complicates the RUP model further – for instance the use of theword activity to mean task, i.e. the smallest unit of work. There are many areasin RUP that show difficulties from a project management viewpoint. Ambler [24]identifies a number of weaknesses in RUP’s support for project management:

• The neglect of several aspects of the larger scale management issues, es-pecially maintenance and support,

• The omission of any support for reuse and cross-project capability,

• The over-dependence on existing tools (of the vendor) leads to neglect ofareas that cannot be automated,

• Weakness in areas such as metrics management, reuse management, peoplemanagement and testing,

• The linking of prototypes linked to ends of iterations providing the abilityto make go/no go decisions,

• The serious investment in software tool support (RUP is after all a tool/productitself).

6 Discussion and Conclusion

”IKIWISI (Ill Know It When I See It), the users dont know what they want butthey know what they do not want when they see it” [25]

This quote reflects why the Rational Unified Process model divides the prob-lem into different parts with early prototype builds. Prototyping in an earlyphase prevents larger failures and eastablish the solution with the customer indifferent stages in the development process. ( by iterative refinement it is easyto evaluate the result )

If the sequential, or waterfall processing works for the short projects or thosewith a small amount of novelty or risk, why not break down the lifecycle of alarge project into a succession of small waterfall projects? In this way you takea smaller step each time on every sequence and you have time to address some

30

requirements and some risks, design a little, implement a little, validate it, andthen take on more requirements, design some more, build some more, validate,and so on, until you are finished. This is the iterative approach.

Another problem is that the technology is changing and also the market.New software and hardware techniques and products become known, and youwant to use and exploit them, and the competition might introduce betterproducts. The sequential, or waterfall, process works somewhat well on thesmall projects ranging from a few weeks to a few months. On a small projectit is always clear what would happen, and on projects in which all hard aspectswere well understood, but when you work on bigger problems the sequential orwaterfall method doesnt seem quite manageable as on small projects.

The content of the above mentioned is, a specific process model could neversuite for every software projects, e.g. software projects varies in both time andquantity. The RUP, as described in this report, is suited for greater softwareprojects because it contains more extensive work that would be a waste of timein smaller projects.

31

List of Figures

1 Static structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 The sequential process . . . . . . . . . . . . . . . . . . . . . . . . 93 Difference between sequential and iterative approach . . . . . . . 104 RUP four phases . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 RUPs four phases in the analysis workflow [6] . . . . . . . . . . 166 Testing during the software development lifecycle . . . . . . . . . 207 A graph showing time for each phase for a typical RUP project

[11] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 An overview of the OPEN framework [12] . . . . . . . . . . . . . 289 Creation routes [15] . . . . . . . . . . . . . . . . . . . . . . . . . 2910 RUP phases and OPEN:s activities [17] . . . . . . . . . . . . . . 29

32

References

[1] http://businessweek.itpapers.com/abstract.aspx?&scid=445&docid=52444

[2] Identifying Extensions Required by RUP (Rational Unified Process)http://mdh.lub.lu.se

[3] P. Kruchten, The Rational Unified Process An Introduction Second Edi-tion, USA, 2000, p. 171-172

[4] http://mdh.lub.lu.se/cgi-bin/ftxt/ebsco/00985589 2003 29 2 181-193/9108494

[5] P. Kruchten, The Rational Unified Process An Introduction Second Edi-tion, USA, 2000, p. 171-172

[6] P. Kruchten, The Rational Unified Process An Introduction Second Edi-tion, USA, 2000, p. 170-171

[7] http://www.softwaretesting.nildram.co.uk/cont542.htm

[8] http://www.awprofessional.com/article/printerfriendly.asp?p=30317

[9] P. Kruchten, The Rational Unified Process An Introduction Second Edi-tion, USA, 2000, p. 174-175

[10] A. Cockbum, Selecting a projects methodology, IEEE Software 17 (4)(2000) 84-85

[11] ”Planning Project with the Rational Unified Process”,http://www.rational.com

[12] A. Cockbum, Selecting a projects methodology, IEEE Software, 2000, p.68

[13] P. Kruchten, The Rational Unified Process An Introduction Second Edi-tion, USA, 2000, p. 184

[14] ”The Ten Essentials of RUP”, http://www.rational.com

[15] B. H-Sellers, D.G Firesmith, I. Graham, A.J.H Simons, Instantiating theprocess metamodel, 1999, p 53

[16] P. Kruchten, The Rational Unified Process An Introduction Second Edi-tion, USA, 2000, p. 185

[17] H-Sellers, D.G Firesmith, I. Graham, A.J.H Simons, Instantiating the pro-cess metamodel, 1999, p 56

[18] B. H-Sellers, D.G Firesmith, I. Graham, A.J.H Simons, Instantiating theprocess metamodel, 1999 p 102

33

[19] A. Cockbum, Selecting a projects methodology, IEEE Software, 2000, p64-71

[20] B. H-Sellers, A. Bulthuis, Object Oriented Metamethods, Springer, NewYork, 1998, p 158

[21] P. Hruby, Designing customizable methodologies, 2000, 22-31

[22] B. H-Sellers, D.G Firesmith, I. Graham, A.J.H Simons, Instantiating theprocess metamodel, 1999, p 51-57

[23] R.T. Du and B. H-Sellers, The changing paradigm for object project man-agement. Object Magazine 5,1995, p 54-60 also see page 78

[24] Ambler, S., Completing the Unified Process with process patterns,http://www.ambysoft.com/unifiedProcess.html, 1999

[25] P. Kruchten, The Rational Unified Process An Introduction Second Edi-tion, USA, 2000, p. 56

34