Transcript Document

SE 470
Software Development Processes
James Nowotarski
14 April 2003
Course Map
Week
1
2
3
4
5
6
7
8
9
Content
. Rational Unified Process
. Extreme Programming
Implementation
. Tools, Training, Roles
. CMM, Metrics
. Selection & Evaluation
Briefings (Term Papers)
Assignments
Quizzes
Memorial Day
Overview
. Introduction
. History
10
11
Today’s Objectives
• Understand the basics of the Rational Unified
Process (RUP)
– Structure
– Content
– Best practices
• In particular, understand how RUP enables
iterative development
Today’s agenda
Topic
Duration
• Quiz #1
40 minutes
• RUP Overview
30 minutes
• *** Break
10 minutes
• RUP Overview (cont.)
45 minutes
• RUP and Iterative Development
60 minutes
Today’s agenda
Topic
Duration
• Quiz #1
40 minutes
• RUP Overview
30 minutes
• *** Break
10 minutes
• RUP Overview (cont.)
45 minutes
• RUP and Iterative Development
60 minutes
Today’s agenda
Topic
Duration
• Quiz #1
40 minutes
• RUP Overview
35 minutes
• *** Break
10 minutes
• RUP Overview (cont.)
30 minutes
• RUP and Iterative Development
75 minutes
Think to yourself how many of the
projects you have worked were:
On Time?
On Budget?
High Quality?
The Bottom Line: Our Customers are upset with us.
The Result is Often Referred to as the
Software Crisis
•
•
•
•
•
Schedule Overruns
Cost Estimate Overruns
Software Quality Problems
Software does not meet User Expectations
Productivity of Software Developers has not
been keeping up with demand
Why is This?
•
•
•
•
•
•
•
Software is dynamic versus static
Software is complex
Software is difficult to conceptualize
Software is difficult to represent
Software is difficult to communicate
Software is difficult to evaluate and measure
Software developers have trouble learning what
users want:
– Users do not know what they want
– Software developers misunderstand the problem
• There is a tremendous demand for software
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
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”
Rational’s View of Best Practices
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
Rational Unified Process
The History of the Rational Unified
Process
Rational Unified Process 2000
2000
Rational Unified Process 5.5
1999
UML v1.3
1998
Rational Unified Process 5.0
UML v1.1
UML v1.0
Rational Objectory Process 4.1
1997
Rational Objectory Process 4.1
1996
Rational Approach
1995
Objectory Process 3.8
RUP Model Notation
A role played by
an individual or a
team.
A piece of
information that
is produced,
modified or used
by a process.
A unit of work
that a worker may
perform.
Workers
• A Worker is a role
played by an
individual or a team.
• Example:
–
–
–
–
–
Stakeholder
Systems Analyst
Designer
Test Designer
Project Manager
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
Artifacts - Examples
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
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 to use a specific software tool
(Similar to wizards)
• Concepts - Separate material that describe some of
the reasons and background on a specific topic
Rational’s Nomenclature of the
Software Engineering Process
Software is developed in
Teams:
Workers
Artifacts
Requirements
Performance
Measures
(Activities)
Software
Engineering
Process
(Workflows)
User Team
(Suppliers)
Expectations
• Features
Workers
• Cost
• Benefit
• Delivery Dates
• Quality
Workers
Artifacts
Software Product
Activities
Artifacts
Software
Development Team
Processes,
Techniques & Tools
Users Team
(Customer)
Perceptions
• Features
• Cost
• Benefit
• Delivery Dates
• Quality
Rational’s View of Best Practices
•
•
•
•
•
•
Use Iterative Development
Manage Requirements
Use Component Architectures
Model Visually
Continuously Verify Quality
Control Change
Iterative Advantages/Disadvantages
Advantages
• Resolves risks before
making large investments
• Enables early user feedback
• Makes testing and
integration continuous
• Focuses project on shortterm 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.
Rational’s View of Best Practices
•
•
•
•
•
•
Use Iterative Development
Manage Requirements
Use Component Architectures
Model Visually
Continuously Verify Quality
Control Change
Manage Requirements
A systematic approach to
–
–
–
–
eliciting
organizing
documenting
and managing
the changing requirements of the software
application
What’s the Difference?
•
•
•
•
Requirements Analysis
Requirements Definition
Requirements Specification
Requirements Management
Managing Changing Requirements
• Establish a Baseline
• Evaluate changes and determine their impact
• Track and document tradeoffs and decisions
Rational’s View of Best Practices
•
•
•
•
•
•
Use Iterative Development
Manage Requirements
Use Component Architectures
Model Visually
Continuously Verify Quality
Control Change
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.
Components
COMPONENTS - Are objects that are combined
into new objects without the use of inheritance
Airplane
Private Data
Object Operations
Engines
Fuselage
Tail
Wings
Private Data
Private Data
Private Data
Private Data
Object Operations
Object Operations
Object Operations
Object Operations
Benefits of Component Architectures
• Resilient
– Meets current and future
requirements
– Improves extensibility
– Enables reuse
– Encapsulates system dependencies
• Reuse proven solution elements
– Reuse or customize components
– Select from Commercially-available
components
– Evolve existing software
incrementally
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
Rational’s View of Best Practices
•
•
•
•
•
•
Use Iterative Development
Manage Requirements
Use Component Architectures
Model Visually
Continuously Verify Quality
Control Change
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
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.
History of the UML
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
Rational’s View of Best Practices
•
•
•
•
•
•
Use Iterative Development
Manage Requirements
Use Component Architectures
Model Visually
Continuously Verify Quality
Control Change
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).
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
Rational’s View of Best Practices
•
•
•
•
•
•
Use Iterative Development
Manage Requirements
Use Component Architectures
Model Visually
Continuously Verify Quality
Control Change
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
Controlling Parallel Development
•
•
•
•
•
•
•
Multiple developers
Multiple teams
Multiple sites
Multiple iterations
Multiple releases
Multiple projects
Multiple platforms
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
Change Control Process
Create
Changes to
Incorporate
Create Initial
Sections
Create
Review
Changes Needed
In Document
Review
Draft
(V&V)
Create/Modify
Draft
Revise
Review
...
Document
Approved
Review
Approved
Time
Document Under Development and
User Change Control
Document in Production and
Under Formal Change Control
Today’s agenda
Topic
Duration
• Quiz #1
40 minutes
• RUP Overview
30 minutes
• *** Break
10 minutes
• RUP Overview (cont.)
45 minutes
• RUP and Iterative Development
60 minutes
Core Concepts
Iterative/Evolutionary/Spiral life cycle models
advocate multiple “threads” through the SDLC
phases
Version 1
A
D
I
Version 2
A
D
I
Version 3
A
D
I
Anatomy of Terminology
Product
Development Cycle
Phase
Iteration
Activity
Core Concepts
Iterative/Evolutionary/Spiral life cycle models
advocate multiple “threads” through the SDLC
phases
Product delivered to users
Initial
Version 1
Development Cycle
Evolution
Version 2
Development Cycle
Evolution
Version 3
Development Cycle
Core Concepts
Inception
Elaboration
Construction
Transition
Core Concepts
Iterationn
Iterationn+1
Core Concepts
Development Cycle
Phase
Iterationn
R
D
Iterationn+1
R
D
C
C
T
T
Core Concepts
Each iteration is a mini-waterfall
R
R
D
R
D
C
D
C
T
C
T
T
Importance of activities across one
development cycle
One development cycle
Core Concepts
Milestones
•
•
•
Exit criteria
Decide to proceed, abort, or change course
Measure progress, e.g.,
– use cases completed
– features completed
– performance requirements satisfied
– risks eliminated
– test cases passed
For each phase, one group fills out:
Key Question:
Deliverables/Outcomes
Activities
Exit Criteria
Guidelines
Key Question:
Look at the objectives and distill
into one key question that needs
to be answered by this phase
Activities
What are the essential activities?
Deliverables/Outcomes
What are the major artifacts
produced? Outcomes achieved?
Exit Criteria
Predefined standards that must be
met before exiting one development
phase and entering another. A team
handing work off to another part of
the project must fully satisfy their exit
criteria, while the receiving team
verifies that the work meets their
standard entry criteria.
Topics for April 21
• Kruchten, Chapters 3, 7, 17
• Quiz (end of class):
– Kruchten
– RUP
Extra Slides
Summary Timeline
1960
1970
1990
1980
2000
Mainframe
Decentralized
Tech era
Distributed
Internet
Stage wise
Life cycle
model
Meth
approach
Content
Updates
Waterfall
Iterative/Incremental
Structured Analysis/Design
Information Engineering
Object-Oriented A/D
Agile
• OLTP
• Data mgmt
• JAD
• Prototyping
• UI design
• Bus process reengineering
• Data/process distribution
• CASE tools
• Multimedia content mgmt
• Quality • Network design/mgmt
• Security
Protracted integration and
late breakage
Conventional application of the waterfall
model typically results in late integration and
performance showstoppers
Late design
breakage
100%
Development progress
(% coded)
Integration
begins
Original
target date
Source: Royce, W. Software Project Management: A Unified Framework. Addison-Wesley (1998).