Transcript No Slide Title

®
IBM Software Group
PRJ270: Essentials of Rational Unified Process
Module 1: Best Practices of Software
Engineering
1
Module 1 Objectives
Understand Rational’s best practices for
software development by looking at:
 Symptoms and root causes
 The Rational Best Practices
 An introduction to Rational Unified Process
2
Discussion: Symptoms and Root Causes
 What are some symptoms of software
development problems?
 To what root causes can these symptoms
be traced?
3
Symptoms of Software Development Problems
User or business needs not met
Requirements churn
Modules don’t integrate
Hard to maintain
Late discovery of flaws
Poor quality or end-user experience
Poor performance under load
No coordinated team effort
Build-and-release issues
4
Trace Symptoms to Root Causes
Symptoms
Root Causes
Needs not met
Insufficient requirements
Requirements churn
Ambiguous communications
Modules don’t fit
Brittle architectures
Hard to maintain
Overwhelming complexity
Late discovery
Undetected inconsistencies
Poor quality
Poor testing
Poor performance
Subjective assessment
Colliding developers
Waterfall development
Build-and-release
Uncontrolled change
Insufficient automation
5
Best Practices
Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually
Visually (UML)
(UML)
Model
Continuously Verify
Verify Quality
Quality
Continuously
Manage Change
Practice 1: Develop Iteratively
Best Practices
Process Made Practical
Develop Iteratively
Manage Requirements
Use Component
Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change
6
Waterfall Development Characteristics
Waterfall Process
Requirements
Analysis
Design
Code and Unit Test
Subsystem
Integration
System Test
 Delays confirmation of critical risk resolution
 Measures progress by assessing work-products that
are poor predictors of time-to-completion
 Delays and aggregates integration and testing
 Precludes early deployment
 Frequently results in major unplanned iterations
7
Iterative Development Produces Executables
Requirements
Analysis & Design
Planning
Implementation
Management
Environment
Test
Evaluation
Deployment
Each iteration
results in an
executable release.
8
Risk Profiles
Risk
Waterfall Risk
Risk Reduction
Iterative Risk
Time
9
Practice 2: Manage Requirements
Best Practices
Process Made Practical
Develop Iteratively
Manage Requirements
Use Component
Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change
10
Requirements Management Means…
Making sure you
 solve the right problem
 build the right system
by taking a systematic approach to
 eliciting
 organizing
 documenting
 managing
the changing requirements of a software
application.
11
Aspects of Requirements Management
 Analyze the Problem
 Understand User Needs
 Define the System
 Manage Scope
 Refine the System Definition
 Manage Changing Requirements
12
Map of the Territory
Problem
Problem
Space
Needs
Solution
Space
Features
The
Product
to Be
Built
Software
Requirements
Test Scripts
Design
13
User
Docs
Practice 3: Use Component Architectures
Best Practices
Process Made Practical
Develop Iteratively
Manage Requirements
Use Component
Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change
14
Purpose of a Component-Based Architecture
 Basis for reuse
 Component reuse
 Architecture reuse
Component-based
architecture with
layers
 Basis for project
management
 Planning
 Staffing
 Delivery
Applicationspecific
Businessspecific
 Intellectual control
Middleware
 Manage complexity
 Maintain integrity
Systemsoftware
15
Resilient and Component-Based Architectures
 Resilient
 Meets current and future requirements
 Improves extensibility
 Enables reuse
 Encapsulates system dependencies
 Component-based
 Reuse or customize components
 Select from commercially available components
 Evolve existing software incrementally
16
Practice 4: Model Visually (UML)
Best Practices
Process Made Practical
Develop Iteratively
Manage Requirements
Use Component
Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change
17
Why Model Visually?
To:
 Capture structure and behavior
 Show how system elements fit together
 Keep design and implementation consistent
 Hide or expose details as appropriate
 Promote unambiguous communication
 UML provides one language for all practitioners
18
Visual Modeling with Unified Modeling Language
 Allows multiple views
 Provides precise syntax and
semantics
Sequence
Diagrams
Collaboration
Diagrams
Dynamic
Diagrams
Statechart
Diagrams
Static
Diagrams
Class
Diagrams
Use-Case
Diagrams
Object
Diagrams
Component
Diagrams
Models
Activity
Diagrams
19
Deployment
Diagrams
Visual Modeling Using UML Diagrams
Use-Case
Diagram
Class Diagram
Statechart
Diagram
add file
DocumentList
Use Case 1
FileMgr
Actor A
Actor B
Document
add( )
delete( )
fetchDoc( )
sortByName( )
name : int
docid : int
numField : int
get( )
open( )
close( )
read( )
sortFileList( )
create( )
fillDocument( )
Use Case 2
FileList
fList
Writing
add file [ numberOffile==MAX ] /
flag OFF
read() fill the
code..
Openning
close file
add( )
delete( )
1
Use Case 3
close file
Reading
Closing
rep
Repository
(from Persistence)
File
read( )
GrpFile
name : char * = 0
readDoc( )
readFile( )
Collaboration
Diagram
9: sortByName ( )
Repository
mainWnd : MainWnd
1: Doc view request ( )
read( )
open( )
create( )
fillFile( )
DocumentList
Deployment
Diagram
Windows95
Window95
FileManager
Windows95
L
2: fetchDoc( )
Document
gFile : GrpFile
4: create ( )
¹®¼°ü¸®
Ŭ¶óÀ̾ðÆ®.EXE
¹®¼°ü¸® ¾ÖÇø´
Windows
NT
8: fillFile ( )
user : Clerk
Solaris
fileMgr : FileMgr
¹®¼°ü¸® ¿£Áø.EXE
GraphicFile
3: create ( )
Alpha
UNIX
ÀÀ¿ë¼¹ö.EXE
6: fillDocument ( )
File
FileList
Windows
NT
IBM
Mainframe
7: readFile ( )
5: readDoc ( )
document : Document
repository : Repository
µ¥ÀÌŸº£À̽º¼¹ö
mainWnd
user
ƯÁ¤¹®¼¿¡ ´ëÇÑ º¸±â¸¦
»ç¿ëÀÚ°¡ ¿äûÇÑ´Ù.
fileMgr :
FileMgr
document :
Document
1: Doc view request ( )
2: fetchDoc( )
gFile
repository
Component
Diagram
3: create ( )
4: create ( )
5: readDoc ( )
ÈÀÏ°ü¸®ÀÚ´Â Àоî¿Â
¹®¼ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼
°´Ã¼¿¡ ¼³Á¤À» ¿äûÇÑ´Ù.
6: fillDocument ( )
Forward and
Reverse
Engineering
7: readFile ( )
8: fillFile ( )
È¸é °´Ã¼´Â ÀоîµéÀÎ
°´Ã¼µé¿¡ ´ëÇØ À̸§º°·Î
Á¤·ÄÀ» ½ÃÄÑ È¸é¿¡
º¸¿©ÁØ´Ù.
9: sortByName ( )
Sequence
Diagram
20
Target
System
Practice 5: Continuously Verify Quality
Best Practices
Process Made Practical
Develop Iteratively
Manage Requirements
Use Component
Architectures
Model Visually (UML)
Continuously
Verify Quality
Manage Change
21
Continuously Verify Your Software’s Quality
Software problems are
100 to 1000 times more costly
to find and repair after deployment
 Cost to Repair Software
 Cost of Lost Opportunities
Cost
 Cost of Lost Customers
Development Phases
22
Testing Dimensions of Quality
Usability
Functionality
 Test application from the
perspective of
convenience to end-user.
 Test the accurate
workings of each
usage scenario
Reliability
 Test that the application
behaves consistently and
predictably.
Supportability
 Test the ability to maintain
and support application
under production use
Performance
 Test online response
under average and peak
loading
23
Test Each Iteration
Iteration 1
Iteration 2
Iteration 3
Iteration 4
Test Suite 1
Test Suite 2
Test Suite 3
Test Suite 4
UML Model
and
Implementation
Tests
24
Practice 6: Manage Change
Best Practices
Process Made Practical
Develop Iteratively
Manage Requirements
Use Component
Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change
25
What Do You Want to Control?
 Secure workspaces for each developer
 Automated integration/build management
 Parallel development
Parallel
Development
Workspace
Management
Configuration
Management is
more than just
check-in and checkout.
Process
Integration
26
REPORT ALERT
Build
Management
Aspects of Managing Change
 Change Request Management (CRM)
 Configuration Status Reporting
 Configuration Management (CM)
 Change Tracking
 Version Selection
 Software Manufacture
27
Best Practices Reinforce Each Other: An Example
Best Practices
Develop Iteratively
Ensures users involved
as requirements evolve
Manage Requirements
Use Component Architectures
Validates architectural
decisions early on
Addresses complexity of
design/implementation incrementally
Model Visually (UML)
Continuously Verify Quality
Measures quality early and often
Manage Change
Evolves baselines incrementally
28
RUP Implements Best Practices
Best Practices
Process Made Practical
Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change
29
Achieving Best Practices Through a Process
 Iterative approach
 Guidance for
activities and
artifacts
 Process focus on
architecture
 Use cases which
drive design and
implementation
 Models which
abstract the system
30
Rational Unified Process (1)
 Captures and presents best practices
 Is a Web-enabled, tailorable knowledge base that enables efficient
development of quality software
 Is continuously improved with regular upgrades
 Contains templates, guidelines, and online Help
 Promotes common vision and culture
 Mentors successful use of tools
Your Process Online
31
Process Manuals
Rational Unified Process (2)
+
Process online
+ supporting tools
Training
Consulting and
Mentoring
32
History of RUP
•Tree browser
upgraded for
enhanced capabilities
of creating
customized My RUP
tree
Improved Process for
independent testing
•Rational Process
Workbench
•Major addition of
content
•Performance Testing
•Business Modeling
•Configuration &
Change Mgt
•Requirements
•Test Process
Rational Unified Process
2003
Rational Unified Process 2002
•Introduction of RUP
Platform providing a
configurable process
framework
•Major addition
of tool mentors
Rational Unified Process 2001
Rational Unified Process 2000
Rational Unified Process 5.5 1999
Rational Unified Process 5.0 1998
Rational Objectory Process 4.1 1997
•Project Management
•UML 1.3
•RealTime
•Objectory UI Design
•Data Engineering
•UML 1.1
Rational Objectory Process 4.0 1996
Rational Approach
Objectory Process 3.8
33
•OMT
•Booch
•UML 1.0
Role of UML in RUP
 Rational Unified Process was developed
hand-in-hand with the UML.
 Many artifacts in Rational Unified Process
have a UML representation.
 Rational Unified Process also includes
guidelines for UML concepts.
34
What’s New in RUP 2003.06.00?
Tree browser
upgraded with
enhanced
capabilities for
creating
customized
MyRUP trees.
New look and feel for entire RUP Web site.
Introduction of RUP Platform providing a
configurable process framework.
35
RUP Organization
RUP is organized:
 By time
 Phases and iterations
 By content
 Disciplines
36
RUP Organization By Time
Inception
Elaboration
Construction
Transition
time
Rational Unified Process has four phases:
 Inception: Define the scope of project
 Elaboration: Plan project, specify
features, baseline architecture
 Construction: Build the product
 Transition: Transition the product into
end-user community
37
RUP Organization By Content
RUP content is organized into disciplines.
A discipline is a collection of activities that are all
related to a major ‘area of concern’.
The disciplines are:
Business Modeling
Requirements
Analysis & Design
Implementation
Test
Deployment
Configuration &
Change Management
Project Management
Environment
38
Bringing It All Together: The Iterative Approach
time
In an
iteration,
you walk
through all
disciplines.
content
Disciplines group
related activities.
39
Review
 Rational’s Best Practices are:
• Develop Iteratively
• Manage Requirements
• Use Component Architectures
• Model Visually (UML)
• Continuously Verify Quality
• Manage Change
 Best Practices guide software engineering
by addressing root causes.
 Best Practices reinforce each other.
 Rational Unified Process is a means of
achieving Best Practices.
40