Lecture 4

Introduction to Software
Engineering

Engr. Hafiza Sundus Waleed

Today’s Overview
• Rational Unified Process
• RUP Phases
• RUP Iteration
• Static Workflows in RUP
• RUP Work Products
• RUP Good Practices
• Personal Software Process
• Team Software Process
• Process and Product
Rational Unified Process
• A framework for object-oriented software engineering.
• Called Rational UP after Rational Corporation.
• Brings together aspects of the generic process models
discussed previously.
• Normally described from 3 perspectives
 A dynamic perspective that shows phases over time;
 A static perspective that shows process activities;
 A proactive perspective that suggests good practice.
RUP Phases
• RUP is a phased model
• Phases are more closely related to business rather than
technical concerns.
• RUP phases are similar in intent to the generic framework
activities studied before.
RUP Phases
RUP Phases: Iteration
 Establish the business case for the system.
 Collaboration with Stakeholder
 Business requirements for the software are identified
 Rough architecture for the system is proposed
 Planning identifies resources, assesses major risks, defines a
schedule for software increment
 Identify and define all external entities (people and
systems)
 Tentative outline of major subsystems.
RUP Phases: Elaboration
 Refines and expands the preliminary use cases
 Expands the architectural representation to include five
different views of the software—the use case model, the
requirements model, the design model, the
implementation model, and the deployment model.
 On completion of this phase you should have a
requirements model for the system.
 It does not provide all features and functions required to
use the system.
RUP Phases: Construction
 System design, programming and testing.
 Using architectural model as input, develops or acquire
s/w components to make each use-case operational for
the user
 To accomplish this, analysis and design models are completed to
reflect the final version of the software increment
 All necessary and required features and functions for the
software increment
 Unit tests are designed and executed for each
component.
 Integration testing is conducted.
 Use cases are used for acceptance tests.
RUP Phases: Transition
 Deploy the system in its operating environment.
 Software is given to end users for feedback.
 Software team creates the necessary support
information.
 Software increment becomes a usable software release.
RUP Phases: Production
 The ongoing use of the software is monitored
 Support for the operating environment (infrastructure)
is provided.
 Defect reports and requests for changes are submitted
and evaluated.
RUP Iterations
• In-phase iteration
 Each phase is iterative with results developed incrementally.

• Cross-phase iteration
 As shown by the loop in the RUP model, the whole set of phases
may be enacted incrementally.

• Concurrent nature
RUP Phases
UP Phases
Incept ion Elaborat ion Const ruct ion Transit ion Product ion

Workflows

Requirements

Analysis

Design

Implementation

Test

Support

Iterations #1 #2 #n-1 #n
Static workflows in the Rational
Unified Process
Workflow Description

Business modelling The business processes are modelled using business use
cases.

Requirements Actors who interact with the system are identified and use
cases are developed to model the system requirements.

Analysis and design A design model is created and documented using

architectural models, component models, object models and
sequence models.

Implementation The components in the system are implemented and

structured into implementation sub-systems. Automatic code
generation from design models helps accelerate this
process.
Static workflows in the Rational
Unified Process
Workflow Description

Testing Testing is an iterative process that is carried out in

conjunction with implementation. System testing follows
the completion of the implementation.
Deployment A product release is created, distributed to users and
installed in their workplace.

Configuration and This supporting workflow managed changes to the

change system
management
Project This supporting workflow manages the system
management development
Environment This workflow is concerned with making appropriate
software tools available to the software development
team.
 RUP Work Products
Incept ion phase

Elaborat ion phase

Vision document
Init ial use-case model
Init ial project glossary
Use-case model
Init ial business case Supplement ary requirement s
Init ial risk assessment . including non-f unct ional
Project plan, Analy sis model
phases and it erat ions. Sof t ware archit ect ure
Business model, Descript ion.
if necessary . Execut able archit ect ural
One or more prot ot y pes prot ot y pe.
I nc e pt i o
n Preliminary design model
Rev ised risk list
Project plan including
it erat ion plan
adapt ed workf lows
milest ones
t echnical work product s
Preliminary user manual
Const ruct ion phase
Transit ion phase
Design model
Sof t ware component s
Int egrat ed sof t ware Deliv ered sof t ware increment
increment Bet a t est report s
Test plan and procedure General user f eedback
Test cases
Support document at ion
user manuals
inst allat ion manuals
descript ion of current
increment
RUP Good Practices
• Develop software iteratively
 Plan increments based on customer priorities and deliver highest
priority increments first.

• Manage requirements
 Explicitly document customer requirements and keep track of
changes to these requirements.

• Use component-based architectures

 Organize the system architecture as a set of reusable components.

• Visually model software

 Use graphical UML models to present static and dynamic views of
the software.
RUP Good Practices
• Verify software quality
 Ensure that the software meet’s organizational quality standards.

• Control changes to software

 Manage software changes using a change management system and
configuration management tools.
Personal Software Process (PSP)
• The Personal Software Process (PSP) emphasizes
personal measurement of both the work product that is
produced and the resultant quality of the work product
• The PSP model defines five framework activities
• Planning
 This activity isolates requirements and develops both, size and
resource estimates.
 A defect estimate (the number of defects projected for the work) is
made.
 All metrics are recorded on worksheets or templates.
 Finally, development tasks are identified and a project schedule is
created.
Contd.
• High-level design
 External specifications for each component to be constructed are
developed and a component design is created.
 Prototypes are built when uncertainty exists. All issues are recorded
and tracked.
• High-level design review
 Formal verification methods are applied to uncover errors in the
design.
 Metrics are maintained for all important tasks and work results.
Contd.
• Development
 The component level design is refined and reviewed.
 Code is generated, reviewed, compiled, and tested.
 Metrics are maintained for all important tasks and work results.
• Postmortem
 Using the measures and metrics collected (this is a substantial
amount of data that should be analyzed statistically), the effectiveness
of the process is determined.
 Measures and metrics should provide guidance for modifying the
process to improve its effectiveness.
Team Software Process (TSP)
• The goal of TSP is to build a “self-directed” project team
that organizes itself to produce high-quality software
• Build self-directed teams
 that plan and track their work,
 establish goals, and own their processes and plans.
• Show managers how to coach and motivate their teams
and how to help them sustain peak performance.
• TSP defines the following framework activities:
 Project launch, high-level design, implementation, integration and
test, and postmortem
Product and Process
• If the process is weak, the end product will undoubtedly
suffer.
• As creative software professional, you should also derive
as much satisfaction from the process as the end product.
Thank you!