rational unified process fundamentals module 1: best practices of software engineering rational...
DESCRIPTION
3 Unified Software Practices Copyright © Rational Software, all rights reserved Module 1 Content Outline Software development problems The Six Best Practices RUP within the context of the Six Best PracticesTRANSCRIPT
Rational Unified Process Fundamentals
Module 1: Best Practices of Software Engineering
2Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Objectives
Identify activities for understanding and solving software engineering problems.
Explain the Six Best Practices. Present RUP within the context of the Six
Best Practices.
3Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Module 1 Content Outline
Software development problems The Six Best Practices RUP within the context of the Six Best
Practices
4Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Symptoms of Software Development Problems
User or business needs not metRequirements churnModules don’t integrateHard to maintainLate discovery of flawsPoor quality or end-user experiencePoor performance under loadNo coordinated team effortBuild-and-release issues
5Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Trace Symptoms to Root Causes
Needs not metRequirements churnModules don’t fitHard to maintainLate discoveryPoor qualityPoor performanceColliding developers Build-and-release
Insufficient requirementsAmbiguous communicationsBrittle architectures Overwhelming complexityUndetected inconsistencies Poor testingSubjective assessmentWaterfall development Uncontrolled changeInsufficient automation
Symptoms Root Causes Best Practices
Ambiguous communications
Undetected inconsistencies
Develop Iteratively
Manage Requirements
Use Component Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change
Model Visually (UML)
Continuously Verify Quality
Modules don’t fit
6Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Module 1 Content Outline
Software development problemsThe Six Best Practices RUP within the context of the Six Best
Practices
7Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Best PracticesProcess Made Practical
Develop IterativelyManage Requirements
Use Component Architectures
Model Visually (UML)Continuously Verify Quality
Manage Change
Practice 1: Develop Iteratively
8Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
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
Code and unit test
Design
Subsystem integration
System test
Waterfall Process Requirements
analysis
9Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Iterative Development Produces an Executable
InitialPlanning
Planning
Requirements
Analysis & Design
Implementation
Deployment
Test
Evaluation
ManagementEnvironment
Each iteration results in an executable release
10Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Risk ReductionRisk Reduction
Time
Risk
Waterfall Risk
Iterative Risk
Risk Profiles
11Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Practice 2: Manage Requirements
Best PracticesProcess Made Practical
Develop IterativelyManage Requirements
Use Component Architectures
Model Visually (UML)Continuously Verify Quality
Manage Change
12Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Requirements Management
A requirement is a condition or capability a system must have.
Managing the requirements of a project offers a number of solutions to the root causes of SW development problems. A disciplined approach is built into requirements
management. Communications are based on defined requirements Requirements can be prioritized and traced. An objective assessment of functionality and
performance is possible. Inconsistencies are detected more easily.
13Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Requirements Management
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.
14Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Aspects of Requirements Management
Analyze the Problem Understand User Needs Define the System Manage Scope Refine the System Definition Manage Changing Requirements
15Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Problem
Solution Space
Problem Space
Needs
Features
SoftwareRequirements
Test ScriptsDesign User
Docs
The The Product Product
to Be to Be BuiltBuilt
Traceability
Map of the Territory
16Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Practice 3: Use Component Architectures
Best PracticesProcess Made Practical
Develop IterativelyManage Requirements
Use Component ArchitecturesModel Visually (UML)
Continuously Verify QualityManage Change
17Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Resilient Component-Based Architectures
A system’s architecture is perhaps the most important deliverable for the purpose of managing the diverse viewpoints of the various stakeholders.
The architecture is helpful in controlling the incremental and iterative development of a system throughout its lifecycle.
18Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Resilient 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
19Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
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
20Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Practice 4: Model Visually (UML)
Best PracticesProcess Made Practical
Develop IterativelyManage Requirements
Use Component Architectures
Model Visually (UML)Continuously Verify Quality
Manage Change
21Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
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
22Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Visual Modeling with Unified Modeling Language
ActivityDiagrams
Models
Dynamic Diagrams
Static Diagrams
Multiple views Precise syntax and
semantics
SequenceDiagrams
CollaborationDiagrams
StatechartDiagrams
DeploymentDiagrams
ComponentDiagrams
ObjectDiagrams
ClassDiagrams
Use-CaseDiagrams
23Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Visual Modeling Using UML Diagrams
Actor A
Use Case 1
Use Case 2
Actor B
user : Clerk
mainWnd : MainWnd
fileMgr : FileMgr
repository : Repositorydocument : Document
gFile : GrpFile
9: sortByName ( )
L1: Doc view request ( )
2: fetchDoc( )
5: readDoc ( )
7: readFile ( )
3: create ( )
6: fillDocument ( )
4: create ( )
8: fillFile ( )
Window95
¹®¼ °ü¸® Ŭ¶óÀ̾ðÆ®.EXE
WindowsNT
¹®¼ °ü̧ ® ¿£Áø.EXE
WindowsNT
Windows95
Solaris
ÀÀ¿ë¼ ¹ö.EXE
AlphaUNIX
IBM Mainframe
µ¥ÀÌŸº£À̽º¼ ¹ö
Windows95
¹®¼ °ü¸® ¾ÖÇø´Document
FileManager
GraphicFile
File
Repository DocumentList
FileList
usermainWnd fileMgr :
FileMgrrepositorydocument :
DocumentgFile
1: Doc view request ( )
2: fetchDoc( )
3: create ( )
4: create ( )
5: readDoc ( )
6: fillDocument ( )
7: readFile ( )
8: fillFile ( )
9: sortByName ( )
ƯÁ¤¹®¼ ¿¡ ́ ëÇÑ º¸±â¸¦ »ç¿ëÀÚ°¡ ¿äûÇÑ´Ù.
È ÀÏ°ü¸®ÀÚ´Â Àоî¿Â ¹®¼ ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼
°́ ü¿¡ ¼³Á¤À» ¿äûÇÑ´Ù.
È ̧é °´Ã¼´Â ÀоîµéÀÎ °´Ã¼µé¿¡ ́ ëÇØ ÀÌ̧ §º°·Î Á¤·ÄÀ» ½ÃÄÑ È ̧é¿¡ º¸¿©ÁØ´Ù.
Forward and Reverse Engineering
TargetSystem
Openning
Writing
ReadingClosing
add file [ numberOffile==MAX ] / flag OFF
add file
close file
close fileUse Case 3
Use-CaseDiagram Class Diagram
Collaboration Diagram
Sequence Diagram
Component Diagram
StatechartDiagram
GrpFile
read( )open( )create( )fillFile( )
rep
Repository
name : char * = 0
readDoc( )readFile( )
(from Persistence)
FileMgr
fetchDoc( )sortByName( )
DocumentList
add( )delete( )
Document
name : intdocid : intnumField : int
get( )open( )close( )read( )sortFileList( )create( )fillDocument( )
fList
1
FileList
add( )delete( )
1
File
read( )
read() fill the code..
Deployment Diagram
24Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Practice 5: Continuously Verify Quality
Best PracticesProcess Made Practical
Develop IterativelyManage Requirements
Use Component Architectures
Model Visually (UML)ContinuouslyVerify Quality
Manage Change
25Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Continuously Verify Your Software’s Quality
Verifying SW quality offers a number of solutions to the root causes of SW development problems. Project status is objective, not subjective. Objective assessment exposes inconsistencies
in requirements, design and implementation. Testing can be focused on the highest areas of
risk. Defects are identified earlier thus reducing the
cost of fixing them.
26Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Continuously Verify Your Software’s Quality
Cost
TransitionConstructionElaborationInception
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
27Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Testing Dimensions of Quality
Reliability Test the application
behaves consistently and predictably.
Performance Test online response
under average and peak loading
Functionality Test the accurate
workings of each usage scenario
Usability Test application from the
perspective of convenience to end-user.
Supportability Test the ability to maintain
and support application under production use
28Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
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
29Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Test Within the Product Development Lifecycle
30Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Practice 6: Manage Change
Best PracticesProcess Made Practical
Develop IterativelyManage Requirements
Use Component Architectures
Model Visually (UML)Continuously Verify Quality
Manage Change
31Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Why manage change?
A key challenge when you are managing SW-intensive systems is that you must cope with multiple developers organized into teams, possible at different sites, working together on multiple iterations, releases, products, and platforms.
Without some sort of disciplined control, the development process rapidly degenerates into chaos.
32Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
ALERTREPORT
WorkspaceManagement
Process Integration
Parallel Development
Build Management
CM is more than just check-in and check-out
What Do You Want to Control?
Secure workspaces for each developer Automated integration/build management Parallel development
33Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Aspects of a CM System
Change Request Management (CRM) Configuration Status Reporting Configuration Management (CM) Change Tracking Version Selection Software Manufacture
34Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Unified Change Management (UCM)UCM involves: Management across the lifecycle
System Project Management
Activity-Based Management Tasks Defects Enhancements
Progress Tracking Charts Reports
35Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Best Practices Reinforce Each Other
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 PracticesDevelop Iteratively
Manage Requirements
Use Component Architectures
Model Visually (UML)
Continuously Verify Quality
Manage Change
36Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Module 1 Content Outline
Software development problems The Six Best Practices RUP within the context of the Six Best
Practices
37Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Rational Unified Process Implements Best Practices
Best PracticesProcess Made Practical
Develop IterativelyManage Requirements
Use Component ArchitecturesModel Visually (UML)
Continuously Verify QualityManage Change
38Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Achieving Best Practices
Iterative approach Guidance for activities
and artifacts Process focus on
architecture Use cases which
drive design and implementation
Models which abstract the system
39Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
A Team-Based Definition of Process
A process defines Who is doing What, When, and How, in order to reach a certain goal.
New or changed
requirements
New or changed
system
Software EngineeringProcess
40Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
InceptionInception ElaborationElaboration ConstructionConstruction TransitionTransition
Process Structure - Lifecycle Phases
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
time
41Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Phase Boundaries Mark Major Milestones
InceptionInception ElaborationElaboration ConstructionConstruction TransitionTransition
Lifecycle Objective Milestone
(LCO)
Lifecycle Architecture
Milestone (LCA)
Initial Operational Capability Milestone
(IOC)
Product Release
time
42Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Iterations and Phases
An iteration is a distinct sequence of activities based on an established plan and evaluation criteria, resulting in an executable release (internal or external).
PreliminaryPreliminaryIterationIteration
Architect.Architect.IterationIteration
Architect.Architect.IterationIteration
Devel. Devel. IterationIteration
Devel. Devel. IterationIteration
Devel. Devel. IterationIteration
TransitionTransitionIterationIteration
TransitionTransitionIterationIteration
InceptionInception ElaborationElaboration ConstructionConstruction TransitionTransition
Minor Milestones: Releases
43Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Bringing It All Together: The Iterative Approach
Disciplines group activities logically
In an iteration, you walk through all disciplines
44Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Disciplines Produce Models
Realized ByImplemented
By
ImplementationModel
Design Model
Use-Case Model
Models
Disciplines Implement-ation
Analysis &Design
Require-ments
Business Use-Case Model
Business Modeling
Business Object Model
BBBB
Realized By
AutomatedBy
45Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Disciplines Guide Iterative Development Business Modeling: Workflow
Requirements: Workflow
46Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Overview of Rational Unified Process Concepts
47Unified Software PracticesCopyright © 1999-2001 Rational Software, all rights reserved
Review
Best Practices guide software engineering by addressing root causes.
Best Practices reinforce each other. Process guides a team on who does what,
when, and how. Rational Unified Process is a means of
achieving Best Practices.