Rational Unified Process ?

1
Rational Unified Process ?
2
Why do so many projects fail?

• Characteristics of failed projects
• Inaccurate understanding of end-user needs
• Inability to deal with changing environments
• Late discovery of serious project flaws
• Poor software quality
• Modules that do not fit together
• Unacceptable software performance
• These are just symptoms of deeper underlying
  problems

3
Root Causes for Project Failure

• Ad hoc requirements management
• Ambiguous and imprecise communication
• Overwhelming complexity
• Insufficient testing
• Subjective assessment of project status
• Uncontrolled change propagation
• Insufficient automation

4
Software Development Best Practices

1. Develop software iteratively
2. Manage requirements
3. Use component-based architectures
4. Visually model software
5. Continuously verify software quality
6. Control changes to software

5
1. Develop Software Iteratively
Planning
The classic waterfall lifecycle
Analysis
Logical Design
Physical Design
Implementation
6
1. Develop Software Iteratively
Planning
Analysis
Risk pushed forward in time
Logical Design
Risk
Physical Design
Implementation
Time
7
Iterative Approach
Initial Planning
Requirements
Planning
Analysis and Design
Management Environment
Evaluation

• continuous discovery and implementation
• -each iteration results in an executable

Implementation
Deployment
Test
8
Advantages of the iterative process

• Misunderstandings made evident early
• Encourages user feedback
• Continuous testing allows objective status
  assessment
• Inconsistencies between analysis, design, and
  implementation detected early
• Workload spread evenly (especially testing)

9
2. Manage Requirements

• Requirements are conditions or capabilities that
  a system must meet
• Requirements of a system are dynamic
• Identifying a systems requirements is a
  continuous process
• Impossible to exhaustively state a systems
  requirements before start of development
• Managing requirements involves
• Eliciting, organizing, documenting requirements
• Evaluating changes to requirements
• Tracking and documenting trade-offs and decisions

10
3. Use Component-based architecture

• Many people are involved in the development of a
  system
• End users, analysts, developers, testers,
  technical writers, project managers
• Each stakeholder views the system in a different
  way during the course of a project
• System architecture allows management of views
• Architecture covers structure and behavior of
  software elements, usage, functionality,
  performance, reuse, aesthetics, etc.

11
Component-based development (CBD)

• Allows reuse and customization of components from
  thousands of available sources
• Can use new, existing, or third-party components
  and strap them together to achieve desired
  functionality
• In an iterative approach, each cycle produces an
  executable architecture
• Can be measured, tested, evaluated against
  requirements
• Allows developers to attack risks continuously

12
Advantages of CBD architectures

• Components facilitate strong and flexible
  architectures
• Modularity enables separation of elements that
  are subject to change
• Components provide a natural basis for
  configuration management
• Visual modeling tools can be used for automation

13
4. Visually Model Software

• A model is a simplification of reality that
  describes system from specific perspective
• Models help teams visualize, specify, construct,
  and document system
• Improves ability to manage system complexity
• Communication is improved through the use of a
  common modeling language (such as UML)

14
Viewing a system from different perspectives
Class Diagrams
State Diagrams
Scenario Diagrams
Model
Component Diagrams
Deployment Diagrams
Use Case Diagrams
15
Advantages of Visual Modeling

• Use-cases and scenarios clearly specify system
  behavior
• Inflexible architectures quickly exposed
• Detail can be hidden when necessary
• Unambiguous designs show inconsistencies easily
• Visual Modeling tools support UML

16
5. Continuously verify software quality
- Software problems can be thousands of times
more expensive to find and repair after
deployment than if discovered earlier in the
project
Cost
Time
17
Testing and Quality

• Testing involves
• Creating tests for systems key scenarios
• Assessing functionality by asking which scenarios
  failed
• Testing at every iteration, continuously
  improving quality

18
6. Control Changes to Software

• Complex systems typically involve
• Multiple developers
• Multiple teams
• Multiple sites
• Multiple releases, platforms, and products
• Can quickly degenerate into chaos

19
To control changes

• Must establish repeatable workflow for managing
  changes
• A tested baseline is released at the end of every
  iteration
• By developing iteratively, the process of change
  control is continuous and traceable

20
Advantages of Formal Change Control

• Change requests facilitate unambiguous
  communication
• Change rate statistics are good metric for
  project status
• Change propagation is controlled
• All outputs are in a single location provides
  for consistency

21
So..
22
Any software development process must

• Guide the order of a teams activities
• Specify which artifacts (deliverables) must be
  produced and when they must be produced
• Direct activities of both individuals and teams
• Monitor and measure project activities

23
Example from Kinexis (see reading)

• Each iteration
• Lasts about 3 weeks
• Consists of build and documentation
• Sent to an evaluation team
• Design team one iteration ahead
• Quality team one iteration behind
• Synch iteration every 3 or 4 rounds

24
The Rational Unified Process?

• - software development process that attempts to
  ensure quality systems developed in a repeatable
  and predictable way

25
RUP
26
Next Class

• Details of Rational Unified Process