Post on 18-Dec-2015
1
IBM Software Group
®
Best Practices of Software DevelopmentRational Unified Process (RUP)
2
Software Development Best Practices
Needs not met
Requirements churn
Modules don’t fit
Hard to maintain
Late discovery
Poor quality
Poor performance
Colliding developers
Build-and-release
Insufficient requirements
Ambiguous communications
Brittle architectures
Overwhelming complexity
Undetected inconsistencies
Poor testing
Subjective assessment
Waterfall development
Uncontrolled change
Insufficient automation
Symptoms Root Causes Best Practices
Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change
3
Best PracticesProcess Made Practical
Best PracticesProcess Made Practical
Develop IterativelyManage Requirements
Use Component Architectures
Model Visually (UML)Continuously Verify Quality
Manage Change
Develop IterativelyManage Requirements
Use Component Architectures
Model Visually (UML)Continuously Verify Quality
Manage Change
Practice 1: Develop Iteratively
4
Waterfall Development Characteristics
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
Waterfall Process
Requirements Analysis
DesignCode and Unit Test
Subsystem Integration
System Test
5
Iterative Development Produces Executables
Planning
Requirements
Analysis & Design
Implementation
Deployment
Test
Evaluation
ManagementEnvironment
Each iteration results in an executable release.
6
Practice 2: Manage Requirements
Best PracticesProcess Made Practical
Best PracticesProcess Made Practical
Develop IterativelyManage Requirements
Use Component Architectures
Model Visually (UML)Continuously Verify Quality
Manage Change
Develop IterativelyManage Requirements
Use Component Architectures
Model Visually (UML)Continuously Verify Quality
Manage Change
7
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.
8
Problem
Solution Space
Problem Space
Needs
Features
SoftwareRequirements
Test ScriptsDesign User
Docs
The Product
to Be Built
Traceability
Map of the Territory
9
Use Cases as a Basis for Iteration PlanningUse Cases as a Basis for Iteration Planning
Use-Case Model
SupplementarySpecifications
Iteration Plan
Fine-grained plan for a single iteration
Project Management
Constraints
During Elaboration, use cases are implemented to validate the architecture.
10
Use Cases as a Basis for System Modeling
verificationrealization
Use-Case Model(requirements)
Implementation Model(source code)
Test Scripts
influence
Design Model(classes and objects)
11
Use Cases as a Basis for Test Planning
The complete behavior of a use case is tested using Test Scripts and Test Suites.
Test Suite
Test Script
Test Script
Test Suite
12
Practice 3: Use Component Architectures
Best PracticesProcess Made Practical
Best PracticesProcess Made Practical
Develop IterativelyManage Requirements
Use Component ArchitecturesModel Visually (UML)
Continuously Verify QualityManage Change
Develop IterativelyManage Requirements
Use Component ArchitecturesModel Visually (UML)
Continuously Verify QualityManage Change
13
Purpose of a Component-Based Architecture
Basis for reuse Component reuse Architecture reuse
Basis for project management Planning Staffing Delivery
Intellectual control Manage complexity Maintain integrity
System-System-softwaresoftware
MiddlewareMiddleware
Business-Business-specificspecific
Application-Application-specificspecific
Component-based architecture with layers
14
Practice 4: Model Visually (UML)
Best PracticesProcess Made Practical
Best PracticesProcess Made Practical
Develop IterativelyManage Requirements
Use Component Architectures
Model Visually (UML)Continuously Verify Quality
Manage Change
Develop IterativelyManage Requirements
Use Component Architectures
Model Visually (UML)Continuously Verify Quality
Manage Change
15
One language – One tool – One team
Data Modeling
Tecnology Modeling
Application Modeling
Business Modeling
RequirementsModeling
One Language for All Practitioners
16
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.
17
Practice 5: Continuously Verify Quality
Best PracticesProcess Made Practical
Best PracticesProcess Made Practical
Develop IterativelyManage Requirements
Use Component Architectures
Model Visually (UML)ContinuouslyVerify Quality
Manage Change
Develop IterativelyManage Requirements
Use Component Architectures
Model Visually (UML)ContinuouslyVerify Quality
Manage Change
18
Continuously Verify Your Software’s Quality
CostCost
Development Phases
Software problems are100 to 1000 times more costly
to find and repair after deployment
Software problems are100 to 1000 times more costly
to find and repair after deployment
Cost to Repair Software
Cost of Lost Opportunities
Cost of Lost Customers
Cost to Repair Software
Cost of Lost Opportunities
Cost of Lost Customers
19
Testing Dimensions of Quality
ReliabilityReliability Test that the application
behaves consistently and predictably.
Test that the application behaves consistently and predictably.
PerformancePerformance Test online response
under average and peak loading
Test online response under average and peak loading
FunctionalityFunctionality Test the accurate
workings of each usage scenario
Test the accurate workings of each usage scenario
UsabilityUsability Test application from the
perspective of convenience to end-user.
Test application from the perspective of convenience to end-user.
SupportabilitySupportability Test the ability to maintain
and support application under production use
Test the ability to maintain and support application under production use
20
UML Model and
Implementation
Tests
Iteration 1Iteration 1
Test Suite 1Test Suite 1
Iteration 2Iteration 2
Test Suite 2Test Suite 2
Iteration 4Iteration 4
Test Suite 4Test Suite 4
Iteration 3Iteration 3
Test Suite 3Test Suite 3
Test Each Iteration
Need for automated testing increases
21
Practice 6: Manage Change
Best PracticesProcess Made Practical
Best PracticesProcess Made Practical
Develop IterativelyManage Requirements
Use Component Architectures
Model Visually (UML)Continuously Verify Quality
Manage Change
Develop IterativelyManage Requirements
Use Component Architectures
Model Visually (UML)Continuously Verify Quality
Manage Change
22
Muutostenhallinta - Change Request Management
Change requests come from many sources throughout each iteration of the product lifecycle
Maint
Test
Code
Design
Req
Customer andUser inputs
MarketingNew
Feature
NewRequirement
Bug
Help DeskUser inputs
ApprovedDecisionProcess(CCB)
Single Channel for Approval
Coders inputsTesters inputs
ChangeRequest (CR)
23
Unified Change Management
24
Best Practices Reinforce Each Other: An Example
Validates architectural decisions early on
Addresses complexity of design/implementation incrementally
Measures quality early and often
Evolves baselines incrementally
Ensures users involved as requirements evolve
Best PracticesBest Practices
Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change
Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change
25
RUP Implements Best Practices
Best PracticesProcess Made Practical Best Practices
Process Made Practical
Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change
Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change
26
Bringing It All Together: The Iterative Approachtime
content
Disciplines group related activities.
In an iteration, you walk through all disciplines.
27
Changing Focus of Phases Over Time
Planned (Technical) Visibility Points
Inception Elaboration Construction Transition
PreliminaryIteration
ArchitectureIteration
Architecture Iteration
Development Iteration
Development Iteration
Development Iteration
TransitionIteration
TransitionIteration
Acceptanceor end of life
Product sufficiently mature for customers to use
Architecture baselined
Scope and Business
Case agreement
Planned (Business) Decision Points
understand problem
understandsolution
have a solution
efficient use of solution
28
Typical Effort and Time Percentages by Phase
Inc Elab Const Trans
Effort 5% 20% 65% 10%
Time/Schedule 10% 30% 50% 10%
Time
People
ConstElab TransInc