CS2 Software Engineering note 2

CS2Ah 01.10.22

CS2 Software Engineering note 2 Workows in the Rational Unied Process

As with the rst note in the Software Engineering series, this note draws heavily on the description of the RUP in Rationals own whitepaper on the RUP. The aim of these notes is to expose you to a typical commercial process. IN later notes we will consider the structure of development processes in more detail and will consider how alternative approaches to the heavyweight approach taken in the RUP. In Lecture Note 1 we considered the best practices incorporated in and the pahases of the RUP. In this note we consider the process and the main workows making up the RUP. This invloves a brief consideration of how we go about describing development processes and then describing the structure of the RUP.

Describing Development Processes

Worker: A worker denes the behavior and responsibilities of an individual, or a group of individuals working together as a team. You could regard a worker as a hat or role an individual can wear in the project. One individual may take many different roles. This is an important distinction because it is natural to think of a worker as the individual or team itself, but in the Unied Process the worker is the role dening how the individuals should carry out the work. The responsibilities we assign to a worker includes both to perform a certain set of activities as well as being owner of a set of artifacts. 1

CS2 Software Engineering note 2

CS2Ah 01.10.22

Activity: An activity of a specic worker is a unit of work that an individual in that role may be asked to perform. The activity has a clear purpose, usually expressed in terms of creating or updating some artifacts, such as a model, a class, a plan. Every activity is assigned to a specic worker. The granularity of an activity is generally a few hours to a few days, it usually involves one worker, and affects one or only a small number of artifacts. An activity should be usable as an element of planning and progress; if it is too small, it will be neglected, and if it is too large, progress would have to be expressed in terms of an activitys parts. Example of activities, and the worker assigned to them, are: Plan an iteration, carried out by the Worker: Project Manager Find use cases and actors, carried out by the Worker: System Analyst Review the design, carried out by the Worker: Design Reviewer Execute performance test, carried out by the Worker: Performance Tester Artifact: An artifact is a piece of information that is produced, modied, or used by a process. Artifacts are the tangible products of the project, the things the project produces or uses while working towards the nal product. Artifacts are used as input by workers to perform an activity, and are the result or output of such activities. In object-oriented design terms, as activities are operations on an active object (the worker), artifacts are the parameters of these activities. Artifacts are quite heterogeneous, they are often delivarables of the development process. For example: A model, such as the Use-Case Model or the Design Model A model element, i.e. an element within a model, such as a class, a use case or a subsystem A document, such as Business Case or Software Architecture Document Source code Executable code Workows: A mere enumeration of all workers, activities and artifacts does not quite constitute a process. We need a way to describe meaningful sequences of activities that produce some valuable result, and to show interactions between workers. A workow is a sequence of activities that produces a result of observable value. In UML terms, a workow can be expressed as a sequence diagram, a collaboration diagram, or an activity diagram. We use a form of activity diagrams in this white paper. Note that it is not always possible or practical to represent all of the dependencies between activities. Often two activities are more tightly interwoven than 2

CS2 Software Engineering note 2

CS2Ah 01.10.22

shown, especially when they involve the same worker or the same individual. People are not machines, and the workow cannot be interpreted literally as a program for people, to be followed exactly and mechanically. In next section we will discuss the most essential type of workows in the process, called Core Workows.

Core Workows
There are nine core process workows in the Rational Unied Process, which represent a partitioning of all workers and activities into logical groupings. The core process workows are divided into six core engineering workows: 1. Business modeling workow 2. Requirements workow 3. Analysis & Design workow 4. Implementation workow 5. Test workow 6. Deployment workow In addition there are three core supporting workows. The artifacts generated byt these workows are not part of the product being developed, but they are essentail to the smoot running of any project: 1. Project Management workow 2. Conguration and Change Management workow 3. Environment workow Although the names of the six core engineering workows evoke the sequential phases in a traditional waterfall process, we should keep in mind that the phases of an iterative process are different and that these workows are revisited again and again throughout the lifecycle. The actual complete workow of a project interleaves these nine core workows, and repeats them with various emphasis and intensity at each iteration. Business Modeling: One of the major problems with most business engineering efforts, is that the software engineering and the business engineering community do not communicate properly with each other. This leads to that the output from business engineering is not used properly as input to the software development effort, and vice-versa. The Rational Unied Process addresses this by providing a common language and process for both communities, as well as showing how to 3

CS2 Software Engineering note 2

CS2Ah 01.10.22

create and maintain direct traceability between business and software models. In Business Modeling we document business processes using so called business use cases. This assures a common understanding among all stakeholders of what business process needs to be supported in the organization. The business use cases are analyzed to understand how the business should support the business processes. This is documented in a business object-model. Projects may choose not to do business modeling if the product is not strongly embedded in some business process.

Requirements: The goal of the Requirements workow is to describe what the system should do and allows the developers and the customer to agree on that description. To achieve this, we elicit, organize, and document required functionality and constraints; track and document tradeoffs and decisions. A Vision document is created, and stakeholder needs are elicited. Actors are identied, representing the users, and any other system that may interact with the system being developed. Use cases are identied, representing the behavior of the system. Because use cases are developed according to the actors needs, the system is more likely to be relevant to the users. A use case describes a representative scenario in the use of the system. Use case analysis tries to discover all such uses 1 . Each use case is described in detail. The use-case description shows how the system interacts step by step with the actors and what the system does. Non-functional requirements are described in Supplementary Specications. The use cases function as a unifying thread throughout the systems development cycle. The same use-case model is used during requirements capture, analysis & design, and test.

Analysis & Design: The goal of the Analysis & Design workow is to show how the system will be realized in the implementation phase. You want to build a system that: Performs in a specic implementation environment the tasks and functions specied in the use-case descriptions. Fullls all its requirements. Is structured to be robust (easy to change if and when its functional requirements change). Analysis & Design results in a design model and optionally an analysis model. The design model serves as an abstraction of the source code; that is, the design model acts as a blueprint of how the source code is structured and written. The design model consists of design classes structured into design packages and
Usually it is impossible to identify all the use case associated with a system because for many systems the context of use is not xed but evolves with time and as the product is used in more contexts
1

CS2 Software Engineering note 2

CS2Ah 01.10.22

design subsystems with well-dened interfaces, representing what will become components in the implementation. It also contains descriptions of how objects of these design classes collaborate to perform use cases. Design activities are centered around the notion of architecture. The production and validation of this architecture is the main focus of early design iterations. Architecture is represented by a number of architectural views [1]. These views capture the major structural design decisions. In essence, architectural views are abstractions or simplications of the entire design, in which important characteristics are made more visible by leaving details aside. The architecture is an important vehicle not only for developing a good design model, but also for increasing the quality of any model built during system development. Implementation The purposes of implementation are:

To dene the organization of the code, in terms of implementation subsystems organized in layers. To implement classes and objects in terms of components (source les, binaries, executables, and others). To test the developed components as units. To integrate the results produced by individual implementers (or teams), into an executable system. The system is realized through implementation of components. The Rational Unied Process describes how you reuse existing components, or implement new components with well dened responsibility, making the system easier to maintain, and increasing the possibilities to reuse. Components are structured into Implementation Subsystems. Subsystems is substructure introduced to ease the managemnet effort involved in creating implementations. In Java, subsystems will correspond to packages. Test The purposes of testing are:

To verify the interaction between objects. To verify the proper integration of all components of the software. To verify that all requirements have been correctly implemented. To identify and ensure defects are addressed prior to the deployment of the software. The Rational Unied Process proposes an iterative approach, which means that you test throughout the project. This allows you to nd defects as early as possible, which radically reduces the cost of xing the defect. Test are carried out 5

CS2 Software Engineering note 2

CS2Ah 01.10.22

along three quality dimensions reliability, functionality, application performance and system performance. For each of these quality dimensions, the process describes how you go through the test lifecycle of planning, design, implementation, execution and evaluation. Strategies for when and how to automate test are described. Test automation is especially important using an iterative approach, to allow regression testing at then end of each iteration, as well as for each new version of the product. Deployment: The purpose of the deployment workow is to successfully produce product releases, and deliver the software to its end users. It covers a wide range of activities including: Producing external releases of the software. Packaging the software. Distributing the software. Installing the software. Providing help and assistance to users. In many cases, this also includes activities such as: Planning and conduct of beta tests. Migration of existing software or data. Formal acceptance. Although deployment activities are mostly centered around the transition phase, many of the activities need to be included in earlier phases to prepare for deployment at the end of the construction phase. The Deployment and Environment workows of the Rational Unied Process contain less detail than other workows. This completes the description of the workows oriented to generating artifacts that are directly associated with the product. The remaining workows contain the supporting tasks involving the management and control of the project. Project Management: Software Project Management is the art of balancing competing objectives, managing risk, and overcoming constraints to deliver, successfully, a product which meets the needs of both customers (the payers of bills) and the users. The fact that so few projects are unarguably successful is comment enough on the difculty of the task. This workow focuses mainly on the specic aspect of an iterative development process. The goal of this workow is to make the task easier by providing: 6

CS2 Software Engineering note 2

CS2Ah 01.10.22

A framework for managing software-intensive projects. Practical guidelines for planning, stafng, executing, and monitoring projects. A framework for managing risk. Thsi workow cannot provide a recipe for success, but it presents an approach to managing the project that markedly improves the odds of delivering successful software. [2] Conguration & Change Management In this workow we describe how to control the numerous artifacts produced by the many people who work on a common project. Control helps avoid costly confusion, and ensures that resultant artifacts are not in conict due to some of the following kinds of problems: Simultaneous Update When two or more workers work separately on the same artifact, the last one to make changes destroys the work of the former. Limited Notication When a problem is xed in artifacts shared by several developers, and some of them are not notied of the change. Multiple Versions Most large programs are developed in evolutionary releases. One release could be in customer use, while another is in test, and the third is still in development. If problems are found in any one of the versions, xes need to be propagated between them. Confusion can arise leading to costly xes and re-work unless changes are carefully controlled and monitored. This workow provides guidelines for managing multiple variants of evolving software systems, tracking which versions are used in given software builds, performing builds of individual programs or entire releases according to userdened version specications, and enforcing site-specic development policies. It describes how to manage parallel development, development done at multiple sites, and how to automate the build process. This is especially important in an iterative process where you may want to be able to do builds as often as daily, something that would become impossible without powerful automation. It also describes how to keep an audit trail on why, when and by whom any artifact was changed. This workow also covers change request management, i.e. how to report defects, manage them through their lifecycle, and how to use defect data to track progress and trends. Environment: The purpose of the environment workow is to provide the software development organization with the software development environment both processes and tools that are needed to support the development team. This workow focuses on the activities to congure the process in the context of a project. It also focusses on activities to develop the guidelines needed to support a project. 7

CS2 Software Engineering note 2

CS2Ah 01.10.22

This completes this brief overview of the RUP. As you can see the description of the process and the number of activities and the coordination required make the RUP a fairly heavyweight approach to development process. In later notes we will reect on this process and consider some alternative process in current use for OO development.

Bibliography
[1] Philippe Kruchten, The 4+1 View Model of Architecture, IEEE Software, 12 (6), November 1995, IEEE, pp.4250. [2] Walker Royce, Software Project Management A Unied Framework, AddisonWesley, 1998.