The design process involves adding formality and detail as the design is developed with constant backtracking to correct earlier designs
3. Construction The construction phase is essentially concerned with system design, programming and testing. Parts of the system are developed in
~---Figure 4.12 Phases
in the Rational Unified Process
Most descriptions of the RUP attempt to combine the static and dynamic per-spectives in a single diagram (Krutchen, 2(00). I think that makes the process harder to understand, so I use separate descriptions of each of these perspectives.
The RUP is a phased model that identifies four discrete phases in the software process. However, unlike the waterfall model where phases are equated with pro-cess activities, the phases in the RUP are more closely related to business rather than technical concerns. Figure 4.12 shows the phases in the RUP. These are:
I. lru:eption The goal of the inception phase is to establish a business case for the system. You should identify all external entities (people and systems) that will interact with the system and define these interactions. You then use this infor-mation to assess the contribution that the system makes to the business.Ifthis contribution is minor, then the project may becancelled after this phase.
2. ElaboratIOn The goals of the elaboration phase are to develop an understand-ing of the problem domain, establish an architectural framework for the sys-tem, develop the project plan and identify key project risks. On completion of this phase. you should have a requirements model for the system (UML use cases are specified), an architectural description and a development plan for the software.
3. Construction The construction phase is essentially concerned with system design, programming and testing. Parts of the system are developed in paral-lel and integrated during this phase. On completion of this phase, you should have a working software system and associated documentation that is ready for delivery to users.
4. Transition The final phase of the RUP is concerned with moving the system from the development community to the user community and making it work in a real environment. This is something that is ignored in most software pro-cess models but is, in fact, an expensive and sometimes problematic activity.
On completion of this phase, you should have a documented software system that is working correctly in its operational environment.
Iteration within the RUP is supported in two ways, as shown in Figure 4.12. Each phase maybeenacted in an iterative way with the results developed incrementally.
Inaddition, the whole set of phases may also beenacted incrementally, as shown by the looping arrow from Transition to Inception in Figure 4.12.
84 Chapter 4 :8 Software processes
The business processes are modelled using business use cases.
Actors who interactwiththesystemare identified and use cases are developed to model the system requirements.
A design model is created and documented using architectural models, component models, object models and sequence models.
The components in the system are implemented and structured into
implementation sub-systems. Automatic code generation from design models helps accelerate this process.
Testing is an iterative process that is carried out in conjunctionwith
implementation. System testing follows the completion of the implementation.
A product release is created, distributed to users and installed in their workplace.
This supporting workflow manages changes to the system (see Chapter 29).
This supporting workflow manages the system development (see Chapter 5).
This workflow is concemedwith making appropriate software tools available to the software development team.
Figure 4.13 Static workflows in Rational Unified Process
The static view of the RUP focuses on the activities that take place during the devel-opment process. These are calledworkflows in the RUP description. There are six core process workflows identified in the process and three core supporting workflows.
The RUP has been designed in conjunction with the UML-an object-oriented elling language-so the workflow description is oriented around associated UML mod-els. The core engineering and support workflows are described in Figure 4.13.
The advantage in presenting dynamic and static views is that phases of the devel-opment process are not associated with specific workflows.Inprinciple at least,allof the RUP workflows may be activeatallstages of the process.Ofcourse, most effort will probably be spent on workflows such as business modelling and requirements at the early phases of the process and in testing and deployment in the later phases.
The practice perspective on the RUP describes good software engineering prac-tices that are recommended for use in systems development. Six fundamental best practices are recommended:
1. Develop software iteratively.Plan increments of the system based on customer priorities and develop and deliver the highest priority system features early in the development process.
2. Manage requirements.Explicitly document the customer s requirements and keep track of changes to these requirements. Analyse the impact of changes on the system before accepting them.
4.5 Computer-Aided Software Engineering 85
3. Uu component-based architectures. Structure the system architecture into components as discussed earlier in this chaptler.
4. Visually model software. Use gtaphical UML models to present static and dynamic views of the software.
5. Verify software quality. Ensun: that the software meets the organisational qual-ity standard.
6. Control changes to software. Manage changes to the software using a change management system and configuration management procedures and tools (see Chapter 29).
The RUP is not a suitable proce:;s for all types of development but it does repre-sent a new generation of generic processes. The most important innovations are the separatIon of phases and workflows, and the recognition that deploying software in a user s environment is part ofthl~ process. Phases are dynamic and have goals.
Workflows are static and are technical activities that are not associated with a single phase but may be used throughout the development to achieve the goals of each phase.
4.5 Computer-Aided Software Engineering
Computer-Aided Software Engineering (CASE) is the name given to software used to support software process activities such as requirements engineering, design, pro-gram development and testing. CASE tools therefore include design editors, data dictionaries, compilers, debuggers, system building tools and so on.
CASE technology provides software process support by automating some pro-cess activities and by providing information about the software that is being devel-oped. Examples of activities that can be automated using CASE include:
1. The development of graphical system models as part of the requirements spec-ification or the software design.
2. Understanding a design using a data dictionary that holds information about the entities and relations in a design.
3. The generation of user interfac.es from a graphical interface description that is created interactively by the user.
4. Program debugging through the provision of information about an executing program.
5. The automated translation of programs from an old version of a programming language such as COBOL to a more recent version.
86 Chapter 4 • Software processes