1. SE470 - Rational Unified Process Overview
Excellence in Software Engineering
Repeatable Level
Defined Level
Managed Level
Initial Level
Optimized
Level
Larry Dribin, Ph.D. - DePaul University
Phone: (847) Fax: (847)
Copyright Ó Larry Dribin, Ph.D. - v

2. Symptoms and Root Causes
Some Symptoms:
Requirements in flux
Users needs not met
Poor quality
Schedule slips
Projects cancelled
Cost over runs
Difficulty in maintaining software
Software that work in pilot does not work in production
Business changes faster than systems can keep up
Staff turnover
Some Root Causes:
Insufficient and misunderstood requirement
Ambiguous communication
Lack of good software architectures
Undetected inconsistencies
Poor testing
Overwhelming complexity
Uncontrolled changes
Manual practices
Exponentially increasing cost of change

3. Sound Engineering principles consist of:
Our Goal is to fix the Root Causes through the use of Good Software Engineering Practices
Definition of Software Engineering:
“The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.”
Fritz Bauer -1969
Sound Engineering principles consist of:
Processes - Procedures and Life Cycles
Techniques - or Methods
Practices - Repeated performances of activities
Tools - to support Processes, Techniques and Practices

4. Generic Process Model performance measurement customer process
roles &
skills
customer IT
supplier

5. The Software Engineering Process
Software is developed in Teams:
Performance
Measures
Software
Engineering
Process
Requirements
Software Product
User Team
(Suppliers)
Expectations
Features
Cost
Benefit
Delivery Dates
Quality
Users Team
(Customer)
Perceptions
Features
Cost
Benefit
Delivery Dates
Quality
Software
Development Team
Processes, Techniques & Tools

6. Why have a Software Development Process?
Provides a guideline for software development
Reduces risk and increases predictability
Basis for improvement
Captures and institutionalizes best practices

7. Best Practices
“An organized and documented set of principles, methods and processes that increase quality and productivity of software development.”
Source: Rational - “Principles of Managing Iterative Development v2.0”

8. Rational’s View of Best Practices
Use Iterative Development
Manage Requirements
Use Component Architectures
Model Visually
Continuously Verify Quality
Control Change

9. Software Lifecycles Fundamental process - the Development Lifecycle
Waterfall
Iterative
Spiral
Evolutionary
Rational Unified Process (RUP) - Unified Development Process
Extreme Programming
Define the software development process in detail
Often described at as a Methodology

10. Waterfall model

11. Issues with the Waterfall Life Cycle
Real projects do not appear to follow the Waterfall life cycle - they appear to iterate.
Requirements must be defined up front which causes problems due to:
Users often do not know what they want.
Most Analysis and Design Techniques do not provide a good clear representation of the solution for the user.
The customer must wait a long time for the first deliverable.
The “Large Specifications” produced are hard to use and hard to validate.
The biggest drawback of the waterfall model is the difficulty of accommodating change after the process is underway

12. Waterfall Advantages/Disadvantages
Well defined
Can easily review & revise
Easy to see status
Logical
Understandable
Easy to estimate
Used as a component of iterative life cycles
Disadvantages
You can’t know everything initially and late discovery increase costs and risks
Rigid / Brittle for large projects
Difficult to handle changes in requirements
Lot of overhead
Must define complete problem at the start
Waterfall life cycle best used for well defined problems and as a component of iterative life cycles.

13. Spiral Life Cycle

14. Phases of the spiral model
Objective setting
Specific objectives for the project phase are identified
Risk assessment and reduction
Key risks are identified, analyzed and information is sought to reduce these risks
Development and validation
An appropriate model is chosen for the next phase of development.
Planning
The project is reviewed and plans drawn up for the next round of the spiral

15. Iterative - Evolutionary Life Cycle
Iterative life cycle best used for problems that are not well understood.

16. The Rational Unified Process
Iterations and
Releases

17. Iterations and Phases

18. Iterative Development

19. Iterative Advantages/Disadvantages
Resolves risks before making large investiments
Enables early user feedback
Makes testing and integration continuous
Focuses project on short-term objectives
Makes partial deployments possible
Disadvantages
Waterfall life cycle is more familiar since it is similar to hardware life cycle
Iterative Life Cycles difficult to estimate and manage.
Only recently used on real projects - therefore little track record
Iterative life cycle best used for problems that are not well understood.

20. Rational’s View of Best Practices
Use Iterative Development
Manage Requirements
Use Component Architectures
Model Visually
Continuously Verify Quality
Control Change

21. Manage Requirements A systematic approach to
eliciting
organizing
documenting
and managing
the changing requirements of the software application

22. The System is a Model of the Real World
Requirements Definition Goal:
Discover, define and document the goals of the system model so that we can quickly develop computer software which accurately models the real world system.
Real World
System
Inputs
Outputs
Computer
System Model of
However, real world systems are constantly changing and adapting to changes in other real world systems with which they interact.
Therefore, systems which model the real world must constantly change, to accurately represent the real world system in real time.

23. Requirements Management (Engineering) Activities
Requirements Analysis
Discover System Requirements
Outline Requirements
Requirements Definition
Describe the system from the user’s point of view
Requirements Specification
Develop a detailed and precise description of the system requirements from the software developer and users point of view
This document often acts as a basis for a contract between the the software developer and the client
Describe the Acceptance Testing requirements for the system

24. Requirements Management Engineering Activities
Develop As Is Model:
1. Study Current System & its Functions
2. Develop Model of Current System
3. Document Current System - As Is Model
Develop (Design) To Be Model:
4. Determine Problems to be Corrected and any
New Requirements
5. Develop Model of Future System =
Current System Function + Problems + New Features
6. Document Future System - To Be Model
7. Validate that “To Be” model solves problems identified
in “As Is” Analysis

25. Requirements Analysis Techniques
Variety of Techniques can be used to determine (capture) the requirements:
Individual Interviews
Group Interviews
Facilitated Workshops
Review Current System
DILO
Use Cases
Task and Work Flow Analysis
Observation
Storyboards
Brainstorming Sessions
JAD - Joint Applications Development (Formal Joint User / Developer Analysis & Design)
No Magic Solutions
No Magic Questions

26. Managing Changing Requirements
Establish a Baseline
Evaluate changes and determine their impact
Track and document tradeoffs and decisions

27. Rational’s View of Best Practices
Use Iterative Development
Manage Requirements
Use Component Architectures
Model Visually
Continuously Verify Quality
Control Change

28. Software Components
Definition:
A software component can be defined as a nontrivial piece of software, a module, a package, or a subsystem, that fulfills a clear function, has a clear boundary and can be integrated in a well-defined architecture. It is the physical realization of an abstraction in your design.

29. Components
COMPONENTS - Are objects that are combined into new objects without the use of inheritance
Airplane
Private Data
Object Operations
Engines
Wings
Fuselage
Tail

30. Features of Component Architectures
Resilient
Meets current and future requirements
Improves extensibility
Enables reuse
Encapsulates system dependencies
Component based
Reuse or customize components
Select form Commercially-available components
Evolve existing software incrementally

31. Benefits of Architecture
Intellectual control
Manage complexity
Maintain integrity
Basis for reuse
Component reuse
Architecture reuse (patterns)
Basis for project management
Focus on early iterations
Planning
Staffing

32. Rational’s View of Best Practices
Use Iterative Development
Manage Requirements
Use Component Architectures
Model Visually
Continuously Verify Quality
Control Change

33. Model Visually - Use the UML
Capture the structure and behavior of architectures and components
Show how the elements of the system fit together
Maintain consistency between a design and its implementation
Promote unambiguous communication

34. The Unified Modeling Language
Developed through the combined efforts of:
Grady Booch
Ivar Jacobson
James Rumbaugh
Is a language for:
Visualizing
Specifying
Constructing
Documenting
The artifacts of a software-intensive system.

35. History of the UML

36. UML Components Multiple Views Precise Syntax and semantics Include
Use-Case Diagrams
Class Diagrams
Object Diagrams
Component Diagrams
Deployment Diagrams
Activity Diagrams
State Chart Diagrams
Collaboration Diagrams
Sequence Diagrams

37. Rational’s View of Best Practices
Use Iterative Development
Manage Requirements
Use Component Architectures
Model Visually
Continuously Verify Quality
Control Change

38. Continuously Verify Quality
In the Rational Unified Process, quality is defined as:
"The characteristic identified by the following:
satisfies or exceeds an agreed upon set of requirements, and
assessed using agreed upon measures and criteria, and
produced using an agreed upon process."
Therefore, achieving quality is not simply "meeting requirements" or producing a product that meets user needs, or expectations, etc.
Quality also includes identifying the measures and criteria to demonstrate the achievement of quality, and the implementation of a process to ensure that the product created by the process, has achieved the desired degree of quality (and can be repeated and managed).

39. The Cost to Change Software
The Rational Process assumes that software problems are 100 to 1000 times more expensive to find and repair later in the life cycle.

40. Test Each Iteration Start testing early Continuously test
Test each Iteration for functionality and performance
Iterative development makes regression testing necessary
Use Automated Tests whenever possible

41. Rational’s View of Best Practices
Use Iterative Development
Manage Requirements
Use Component Architectures
Model Visually
Continuously Verify Quality
Control Change

42. Control Changes
You must control, track and monitor changes to enable iterative development
Control changes for all software artifacts:
Models
Documents
Source code
Project plans
Establish secure workspaces fore each developer
Automated integration and build management

43. Controlling Parallel Development
Multiple developers
Multiple teams
Multiple sites
Multiple iterations
Multiple releases
Multiple projects
Multiple platforms

44. Configuration Management
Configuration Management is the process which controls the changes made to a software system and manages the different versions and releases of the evolving software products
Librarian like function
Manages the version number for each software product
Changes made are controlled by a Change Control Process
Can be managed manually or through the use of a configuration management tool (Difficult to do manually, but it can be done.)
Check In
Check Out
Read only for others

45. Change Control Process
Create Initial
Sections
Create/Modify
Draft
Review
(V&V)
Create
Changes to
Incorporate
Changes Needed
In Document
Document
Approved
Revise
Time
...
Document Under Development and User Change Control
Document in Production and Under Formal Change Control

46. Rational’s View of Best Practices
The Best Practices Reinforce Each Other and tools are used to guide and support the best practices.

47. The Rational Unified Process
Developed through the combined efforts of:
Grady Booch
Ivar Jacobson
James Rumbaugh
Features
Based on the Unified Modeling Language
Iterative
Architecture-centric
Use-case driven
Risk driven

48. Rational Unified Process

49. The History of the Rational Unified Process
2000
1999
1998
1997
1996
1995
Rational Unified Process 5.5
UML v1.3
Rational Unified Process 5.0
UML v1.1
Rational Objectory Process 4.1
UML v1.0
Rational Objectory Process 4.1
Rational Approach
Objectory Process 3.8

50. RUP Model Notation A unit of work that a worker may perform.
A role played by an individual or a team.
A piece of information that is produced, modified or used by a process.

51. Workers A Worker is a role played by an individual or a team. Example:
Stakeholder
Systems Analyst
Designer
Test Designer
Project Manager

52. Artifacts (Work Products)
An artifact is a piece of information that is used, modified or produced by a process.
Artifacts are the intangible products of the project
Examples:
A use-case model
A document such as a business case
Source Code
Executable code

53. Artifacts
A piece of information that is produced, modified or used by a process.
Artifacts are the intangible products of the project
Examples:
A use-case model
A document such as a business case
Source Code
Executable code

54. Artifacts - Examples

55. Activities An Activity is a unit of work that a worker may perform.
Examples:
Plan an interaction performed by Project Manager
Find use cases and actors
Review the design
Execute a performance test
Activities are typically broken into steps of which there are three main Categories:
Thinking steps
Performing steps
Reviewing steps

56. Activities
Example decomposition for Activity: “Find use cases and actors”
Find actors
Find use cases
Describe how actors and use cases interact
Package use cases and actors
Present the use-case model in use-case diagram
Develop a survey of the use-case model
Evaluate your results

57. Additional Process Elements
Guidelines - are rules, recommendations, or heuristics that support activities and steps.
Templates - are models or prototypes of artifacts
Ex. Word template for Vision Document
Tool mentors - are a means of providing guidance by showing you how tuo use a specific software tool (Similary to wizards
Concepts - Separate material that describe some of the reasons and background on a specific topic

58. Rational’s Nomenclature of the Software Engineering Process
Software is developed in Teams:
Workers
Workers
Performance
Measures
(Activities)
Artifacts
Artifacts
Software
Engineering
Process
(Workflows)
Requirements
Software Product
User Team
(Suppliers)
Expectations
Features
Cost
Benefit
Delivery Dates
Quality
Users Team
(Customer)
Perceptions
Features
Cost
Benefit
Delivery Dates
Quality
Activities
Workers
Artifacts
Software
Development Team
Processes, Techniques & Tools

59. The Rational Unified Process
Basic phases
Inception
Elaboration
Construction
Transition
Core Workflows
Engineering Workflows
Business Modeling
Requirements Definition
Analysis and Design
Implementation
Test
Deployment
Supporting
Project Management
Configuration and change management
Environment
Iterations

60. Rational Unified Process Lifecycle Phases
Inception - defines the scope of the project
Elaboration - plans the project, develops a baseline architecture and specifies features
Construction - builds the project
Transition - transitions the project into the end user community

61. Workflows
A Workflow is a sequential description of the activities that produces a result of value
The Nine Core Workflows

62. Workflow Details for Requirements Overview

63. Rational Unified Process