The Rational Uniﬁed Process Department of Computer Science Mlardalen University Emil Eric Majid Gorbani Andreas Selenwall June 10, 2004

(1)

The Rational Unified Process

Department of Computer Science Mlardalen University

Emil Eric Majid Gorbani Andreas Selenwall

June 10, 2004

(2)

Abstract

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

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

(3)

1 Introduction

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

RUP is a software engineering process developed and marketed by Rational Software. It is a disciplined approach to assigning and managing tasks and responsibilities in a development organization. The goal with this process is to produce, within a predictable schedule and budget, high-quality software that meets the needs of its end users. RUP is a process ”framework” for software development, which covers the life cycle of a project and guides the development team 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 itself an object-oriented approach. Its structure transcends the traditional model of the development in cascade to offer a powerful software development framework based on a controlled and optimized iterative cycle. The RUP proposes a framework making it possible for an organization of software development of all sizes to work, extend and improve its process according to its objectives. The RUP is a rich base of knowledge of the best practices harvested by Rational over the years. RUP captures many of the best practices in modern software development and presents them in a tailorable form that is suitable for a wide range of projects and organizations. RUP delivers these best practices to the project team online in a detailed, practical form.

1.1 Problem area

The problem of systems engineering is to design and implement a system that meets a broad set of requirements [1]. Depending on circumstances, there might be other system requirements such as logistics support, security, and remote training 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 specified concurrently. The system problem then differs from the software-only problem in that system engineering addresses a broader set of requirements than are normally addressed in software efforts. A way to handle these problems is to use the Rational Unified Process (RUP), like a process model, that addresses the problem of system specification, analysis, design, and development.

1.2 Purpose

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

(6)

2 Process description

2.1 Static structure

A model process describes who does what, how, and when. The Rational Unified Process is represented with the use of four primary modeling elements, which are workers, activities, artifacts, and workflows. A worker defines the behavior and responsibilities of an individual or a group of individuals working as a team.

Workers represent a role played by individuals on a project, and define how they carry out their work. Workers have activities, which define the work they perform. An activity is something a worker does that provides a meaningful result 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 perform activities, and produce artifacts in the execution of activities. Artifacts are pieces of information that are produced, modified, or used by a process.

Core workflows, in the Rational Unified Process, represent a partitioning of workers 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

(7)

2.1.1 Workers

The worker is the core element in the whole process, as a result the workers defined the behaviour and responsibilities of an individual or a group of individuals working together as a team. It is helpful to think of a worker as a hat that an individual can put on during the project. One person may have on many hats. This is important because it is common to think of a worker as the individual or the group, but in the RUP the term worker refers to the roles that classify 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 coordinates requirements elicitation and use-case modelling by outlining the systems and delimiting the system.

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

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

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

2.1.2 Activities

Each worker has activities, which characterize the work they perform. An activity 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. The purpose of the activity is to create or update artifacts such as a model, class or a plan. Every activity may be frequently doing some operation on the same artifact, particularly from one iteration to another as the system is refined and expanded. 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: Performance Tester

2.1.3 Artifact

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

(8)

• 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 represent a process. We need a way to describe meaningful sequences of activities that produce some important result and to show interactions between workers. A workflow 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, a collaboration diagram, or an activity diagram.

The Rational Unified Process is organized to reach the goal using the following:

• 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 the sequential or waterfall process. This is surprising because at first, this method seems 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 down to 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.

(9)

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 engineers can draw on hundreds of years of experimentation in design and construction.

But in contrast, software engineers have had only a few decades to explore their field. During the seventies and eighties the software developers worked very hard to accumulate experimental results in software design and during the 1980 the sequential problem solving was the only method used.

In the sequential processing the developers have only one shot on each step of 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 those with a small amount of novelty or risk, RUP breaks down the lifecycle of a large project into a succession of small waterfall projects. In this way you take a smaller step each time on every sequence and you have time to address some requirements and some risks, design a little, implement a little, validate it, and then 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 iterations. Each sequence looks like a mini waterfall and involves the activities of requirements, design, implementation, and assessment.

(10)

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 appropriate focus for each iteration, a development cycle is divided into a sequence of four phases that partition with help of milestones the sequence of iterations. These milestones provide points at which we can decide to proceed, abort, or change course. Finally, we must partition and organize the sequence of iterations according to specific short-term objective.

Figure 4: RUP four phases

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

(11)

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

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

• Inception Phase – During the inception phase the core idea is developed into a product vision. In this phase, we review and confirm our understanding of the core business drivers. We want to understand the business case for which the project should be attempted. The inception phase establishes the product feasibility and delimits the project scope.

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

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

• Transition Phase – In the transition phase the goal is to ensure that the requirements have been met to the satisfaction of the stakeholders. This phase is often initiated with a beta release of the application. Other activities include site preparation, manual completion, and defect identification and correction. The transition phase ends with a postmortem devoted to learning 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 iterative approach accommodates changes in requirements and in implementation strat- egy. It confronts and mitigates risks as early as possible. It allows the development organization to grow, to learn, and to improve. It focuses on real, tangible objectives.

3 Process workflow

3.1 Project Management Workflow

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

(12)

to monitoring and measurements of the product so far. A project plan is divided into two parts, the phase plan and the iteration plan. The phase plan is a coarse-grained plan with overall information about each of the four phases, and should contain date of major milestones, staffing estimates for each phase an estimation of the numbers of iterations included in each phase. Iteration plan is 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 establish start and end dates for each task. Gannt charts are often used to show tasks start 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 next iteration, deciding when to change iteration and whether the project still is 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 work schedule.

The Software Development Plan consists of

• Measurement plan

• Risk management plan

• Product acceptance plan

• Problem resolution plan

(13)

• 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 be divided 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 of environment 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 Business Modelling we document business processes using business use cases. This assures a common understanding between all stakeholders (a stakeholder is any person or representative of an organization who has a stake - vested interest - in the outcome of a project, [7] ) what business process needs to be supported in the model.

The Business Case developed provides the business information necessary to determine if the project is worth investing in, Return On Investment (ROI). Its main 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

(14)

milestones in the project there must be a check if the project is accurate to the ROI 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 of communication between the business engineering team and the software engineering team, thus the output from business engineering is not used properly in the software development. The Rational Unified Process address this problem by providing a common language to communicate between teams and thus preventing this problem from occuring. The output from this workflow is doc- umented in a Business Object-model. Business Modelling is one of the first things you do in the project since the result of Business Cases and Return On Investment is the information stakeholders will use to decide if the project is worth 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 should not do and what requirements to prioritize. This is done through meetings with the customer, refining the requirements after each meeting until the requirement team has the same picture of the system as the customer. In the process we will find and document actors and use-cases.

The three active workers in the Requirements workflow are, the System Analysts, 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 team understand what the customer wants

– Develop the requirements management plan – Finding actors and Use-Cases

– Develop a Vision – capture the importance of the requirements workflow, analyzing the problem, understand stakeholders needs, defining the system and managing the requirements as they change

– Elicit stakeholders requests - see that the requirements are understood

• Software Architect – Prioritize Use-Cases - find which Use-Cases are more important 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 subsequently refined into classes, subsystems and packages. Analysis and design result in a

(15)

design model, which can be abstracted using three architectural views. The logical view presents the decomposition of the system into a set of logical elements, e.g. classes, subsystems, packages and collaborations. The process view maps those elements to the processes and threads in the systems. The deployment view 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 requirements into a specification that describes how to implement the system. Early in the project, it is important to establish a robust architecture so it will be possible to design a system that is easy to understand, build and evolve [3]. The purpose of analysis is to transform the requirements of the system into a form that maps well to the software designers area of concern - that is, to a set of classes and subsystems. This transformation is driven by the use cases and is shaped further by the systems non-functional requirements. Analysis focuses on ensuring that the systems functional requirements are handled. As a result, analysis expresses a 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-functional requirements, the implementation environment, performance requirements, and so forth. Design is a refinement of analysis. It focuses on optimizing the systems design 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 separate analysis model has proved very useful. The analysis model omits most of the details of how the system works and provides an overview of the systems functionality.

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 the system 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 architectural analtysis, use case analysis, class analysis, package analysis and how they are related to each other.

3.3.3 The design model

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

(16)

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 responsibilities, relationships, operations, attributes and semantics. A package is a logical grouping of classes, perhaps for organizational purposes that reduce the complexity of the system. A subsystem is a kind of package consisting of a set of classes that act as a single unit to provide specific behaviors [9].

The designer defines the responsibilities, operations, attributes and relationships of one or several classes and determines how they should be adjusted to the implementation environment. In addition, the designer may have responsibility for one or more design packages or design subsystems, including any classes owned by the packages or subsystems.

Design can optionally include the following workers:

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

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

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

3.4 The implementation workflow

The implementation workflow has four purposes:

(17)

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

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 individual implementers or teams.

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

3.4.1 Builds

A build is a part of a system, e.g. a subsystem that demonstrates a subset of capabilities to be provided in the final product. During the developing process there will be numerous builds, each helping to recognize integration problems as soon 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 roll back to an earlier version when added functionality causes breakage. Projects generally try to produce builds at regular intervals, up to one each day, but at least one per week toward the end of an integration.

3.4.2 Integration

Integration refers to an activity in which separate software components are combined into a whole. Integration is done at several levels of the implementation for the following purposes:

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

• To integrate subsystems into a complete system.

The RUP approach to integration is that the software is integrated incrementally. Incremental developmant means that code is written and tested in small pieces and then is combined into a working whole, piece by piece. Incremental development offers the following benefits:

• Faults are easy to locate. When a new problem occurs during the integration, the new component is the first place to look for the fault. Incremental integration 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 and tested as they are developed. This means that the components are exer- cised more often than they are when integration is done in one step.

(18)

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

[16]

3.4.3 Prototypes

Prototypes are used in a directed way to reduce risk. A prototype is a variant of a 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 they explore and by how they evolve [18]. In the context of the first view, there are two main kinds of prototypes:

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

• 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 you have 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 from design elements to implementation elements, for example classes to code. The persons playing the role as designers and implementers can either modify the design model and regenerate the corresponding code and then alter the design to match the modification. This closes a gap in the process and helps avoid errors in translating the design.

3.5 Test workflow

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

• Verifying the interactions of components

• Verifying the proper integration of components

• Verifying that all requirements have been implemented correctly

(19)

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

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

The test workflow provides the feedback mechanism for the project, enabling quality to be measured and defects to be identified. Testing activities begin early in the project, with test planning and some assessment occurring even in the inception 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 we assess quality. If developers are to obtain timely feedback on evolving product quality, testing must occur throughout the lifecycle. The tests depends on the projects 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 to make 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 components

3.5.2 Type of test

The testing have many kind of types, each one focusing on specific area, a test of software during the development has many variation of testing, a test could be 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 a known standard such as existing software or measurement

(20)

Figure 6: Testing during the software development lifecycle

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

• Installation test – verifying that the target-of-test installs properly and can be installed successfully on different configuration or under different conditions, such as insufficient disk space or on the different operation system 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 performance using various configurations while the operational conditions remain constant

• Stress test – verifying the acceptability of the target-of-tests performance when abnormal or extreme conditions are encountered, such as diminished resources 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 be tested. It is a view of the design and implementation models, depicting the

(21)

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

• Test cases – the set of test data, execution conditions, and expected test results developed for a specific test objective. Test cases can be derived from 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 test model, implementing the test procedures, and evaluating test coverage, results, and effectiveness.

• The tester is responsible for executing the system tests. This effort includes setting up and executing tests, evaluating test execution, recovering 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 be implemented and executed. This is accomplished by generating a test plan that contains the requirements for test and test strategies. Test planning is done so the test efforts can be measured and managed.

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

implement test The purpose is to implement the test procedures that were defined in the Design Test section. The creation of test procedures usually is done in the contest of a test automation tool or programming environment. The output artifact is a computer-readable version of the test procedure, referred to as a test script. If special test code (e.g., a test harness, drivers, or stubs) is needed to support or perform testing, the designer and the implementer work with the test designer to design and implements the test code.

(22)

4 Project Planning with the Rational Unified Process

In this chapter we will take a closer look into the project planning and what the essentials are. To some of these essentials there are recommendations from RUP 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 project organizational structure based on the project characteristics and external constraints. The recommendations from the Rational Unified Process is to define in terms of positions, teams, responsibilities and hierarchy. We will also define staff requirements based on effort estimates, desired schedule, chosen organizational structure and mapping of roles, the RUP recommends that you define staff required for the project by type (skills and the domain of the project), experience and caliber, that you adjust the software development team from its baseline during the project lifecycle, that is while the project moves forward different 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 staff will consist of more designers.

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

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

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 investing in, or Return Of Investment (ROI). It is up to the manager to find if the project is worth investing in and the report is the artifact. The business case is essential for the future of the project, the stakeholders must feel that this is worth investing in due to the artifact and the market needs.

The following steps are recommended by the RUP when developing the business case:

1. Describe the product and the need it fulfills

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

(23)

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

4. Describe the project constraints that could potentially impact risk and cost

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. This part 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 and handling risks early in the development. In this process a Risk List will be created by identifying in decreasing order of priority events that could lead to problem, with each risk associated with a plan to mitigate the risk. The risks should be a focal point for the planning project activities and a basis for how iterations are organized.

Its important to have continuos checks on the activities, what it produces and their configurations to track issues and handle them when they occur. RUP uses regular status assessments and provides a mechanism for addressing, com- municating and resolving management issues. Each issue should be assigned to a 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 development 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 the likelihood of its occurence to determine the risk exposure for each risk 3. Identify risk avoidance strategies to reorganize the project so that you can

reduce 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 after and moving towards the stakeholders needs. The Vison captures the essence of the Requirements Workflow by analyzing the problem, understanding the stakeholders needs, defining that system and managing the requirements as they change. Some other features of the Vison Document is that it

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

(24)

• Captures very high-level requirements

• Captures design constraints

• Provides input to the project-approval process – this part is closely related to 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 Project activity. This activity will assign the Executive Management and Project Plan- ning team and will also set up the criteria for project completion, when this criteria is reached the project has successfully been completed. In this activity you also assign a project review team who will be responsible for the overall view of the project, a project planning team responsible for the planning of the project (gantt chart where we allocate resources for different activities), main- taining the project plan and report project status. Also this is when we approve the project acceptance criteria (a way for the stakeholders and customers to determine 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 for what 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 a project 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 and a deliverable view, to easier identify what has been delivered and where we are

(25)

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

The Project Plan, or the Software Development Plan as it is called in the Rational Unified Process, contains all information to manage the project and is maintained throughout the project to keep it updated as it changes. The Soft- ware Development Plan contains the schedule for the project, the resource needs for the project and compare progress against the schedule to update members with the actual progress of the project. Here are a list of the content of the Software 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. The major activities are defining the project structure and estimating the size of the project. IBM Rational have made an estimation of the project time by earlier experience 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 the Vision. The Iteration Plan is written after the project plan is completed. RUP is iterative and incremental, thus it is divided into phases and activities. Each iteration 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 iteration plan which contains a detailed description of that phase, which workers are needed and what they will do, activities and which artifacts will be delivered. The Iteration Plan is more detailed than the project plan and has clear objectives (and milestones) for each phase. To fully understand the projects current status and it is progress is to identify which phase you are in, this must be realized by all project team members. Every phase delivers something. The

(26)

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

Inception Phase delivers for example the Vision document. Associated with each deliverable is a workflow template which contains important aspects such as activities, resources and other deliverables required to complete this deliverable, and an artifact, the document produced by the project. RUP has provided us 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 the product main features

• Use-Case Model - Defines the systems functional requirements

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

As stated earlier there is a workflow associated with each deliverable. The workflow template idenitifies activities needed to create the deliverable. An activity includes roles which helps find what resources are needed and must be filled with actual workers, artifacts and guidance (help steps). Unfit activities can be omitted from an iteration (or project regarding the plan). Time for an activity 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 how to get the project back on track we use monitoring and control processes. This is usually done by checking the project so it follows the Software Development Plan (SDP) to see that the project is still in its scope. RUP has the following recommendations.

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

2. Define sources for project indicators

(27)

3. Define and communicate a procedure and report frequency for project team 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 to what was expected. For example functionality, performance, capacity and quality. Also you should check if the requirements are still valid, if the goals are too high 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 document and the risk list.

4.3.3 The architecture

The architecture should contain the structure of the systems significant components interacting through interfaces, ”What are the main pieces and how do they fit together?”. The essence of the Analysis and Design Workflow are define a candidate architecture, refine the architecture, analyze behaviour and design components of the system. The architecture design results in the Software Architecture Document which defines the architectural design which describes important aspects of the architecture, and multiple views with specific con- cerns, depending on the stakeholders (End User, Designers, Managers, System Engineers, Maintainers, etc).

4.3.4 Building and testing products

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

Through each iteration in the Construction Phase components are integrated into 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 is created as an instantiation of this framework. In figure 9, shown below, an overview of the framework is described.

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

(28)

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

has a strong focus not only on software development but also on project management [20]. OPEN combines the adaptability to construct a process to the specific needs of an individual domain and continually adapt the process to particular projects. This enhances the incorporation of component-based development 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. OPEN can be described as a component-based process construction facility. This gives a 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 tailorable methodology; that is, RUP is a pre-selected instantiation of a metamodel such as the OPEN framework [22].

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

(29)

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,

(30)

by the use of possibility matrices which assist the method engineering in tailoring the most high quality software development in the most efficient manner.

OPEN also suggests that you define your own project charter which contains an 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 the constraints and resources available. In contrast, in RUP all of the project management elements are grouped together as a separate project management subset supporting workflow, which operates in parallel to the other subset workflows and across each iteration workflow. In addition, the actual depth of support for project management is limited. And use of non-standard project management terminology complicates the RUP model further – for instance the use of the word activity to mean task, i.e. the smallest unit of work. There are many areas in 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 of areas that cannot be automated,

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

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

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

6 Discussion and Conclusion

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

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

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

(31)

requirements and some risks, design a little, implement a little, validate it, and then 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 you want to use and exploit them, and the competition might introduce better products. The sequential, or waterfall, process works somewhat well on the small projects ranging from a few weeks to a few months. On a small project it is always clear what would happen, and on projects in which all hard aspects were well understood, but when you work on bigger problems the sequential or waterfall method doesnt seem quite manageable as on small projects.

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

(32)

List of Figures

1 Static structure . . . 6

2 The sequential process . . . 9

3 Difference between sequential and iterative approach . . . 10

4 RUP four phases . . . 10

5 RUPs four phases in the analysis workflow [6] . . . 16

6 Testing during the software development lifecycle . . . 20

7 A graph showing time for each phase for a typical RUP project [11] . . . 26

8 An overview of the OPEN framework [12] . . . 28

9 Creation routes [15] . . . 29

10 RUP phases and OPEN:s activities [17] . . . 29

(33)

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

[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 the process metamodel, 1999, p 53

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

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

(34)

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

[20] B. H-Sellers, A. Bulthuis, Object Oriented Metamethods, Springer, New York, 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 the process metamodel, 1999, p 51-57

[23] R.T. Du and B. H-Sellers, The changing paradigm for object project management. 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