Use of RUP for Small Projects
-
Upload
mahesh-panchal -
Category
Education
-
view
18.197 -
download
0
description
Transcript of Use of RUP for Small Projects
Use of RUP for Small ProjectsUse of RUP for Small Projects
Mahesh Panchal 07030244006Nitin Garg 07030244008Ravindra Nath Sharma 07030244018Utkarsh Khare 07030244025
Mahesh Panchal 07030244006Nitin Garg 07030244008Ravindra Nath Sharma 07030244018Utkarsh Khare 07030244025
AgendaAgenda
Waterfall vs. Iterative Development Prerequisites and Common Pitfalls An Approach for Iterative Development Case Study – Small Project Summary
RISK
T I M E
Waterfall Development Delays Reduction of RiskWaterfall Development Delays Reduction of Risk
Subsystem Testing
System Testing
Code & Unit Testing
Design
Requirements Analysis
Apply the Waterfall Iteratively to System IncrementsApply the Waterfall Iteratively to System Increments
Earliest iterations address greatest risksEach iteration produces an executable release, an additional increment of the systemEach iteration includes integration and test
TC
DR
T I M E
Iteration 1 Iteration 2 Iteration 3
TC
DR
TC
DR
Iterative Development CharacteristicsIterative Development Characteristics
Critical risks are resolved before making large investments
Initial iterations enable early user feedback Testing and integration are continuous Objective milestones provide short-term focus Progress is measured by assessing implementations Partial implementations can be deployed
Transition
Risk
Inception
Elaboration
Construction
PreliminaryIteration
Architect.Iteration
Architect.Iteration
Devel. Iteration
Devel. Iteration
Devel. Iteration
TransitionIteration
TransitionIteration
Post-deployment
Waterfall
Time
Staffing
Risk
Iterative Development Accelerates Risk ReductionIterative Development Accelerates Risk Reduction
Introduction to the Rational Unified Process (RUP)Introduction to the Rational Unified Process (RUP)
RUP is a complete lifecycle software engineering process It provides a risk driven approach to assigning tasks and
responsibilities within a development organization Its goal is to ensure the production of high-quality software
that meets the needs of its end users within a predictable schedule and budget
Developed over many years of working with customers Architecture focus Easily customized Web based implementation
The Six Best Practices of Software EngineeringThe Six Best Practices of Software Engineering
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
Six Best Practices: Develop IterativelySix Best Practices: Develop Iteratively
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
Risk ReductionRisk ReductionRisk ReductionRisk Reduction
TimeTime
Ris
kR
isk
Waterfall Risk
Iterative Risk
Six Best Practices: Develop IterativelySix Best Practices: Develop Iteratively
Six Best Practices: Manage RequirementsSix Best Practices: Manage Requirements
Making sure yousolve the right problembuild the right system
by taking a systematic approach toeliciting organizing documenting managing
the changing requirements of a software application.
Six Best Practices: Use Component Architectures Six Best Practices: Use Component 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
Six Best Practices: Model VisuallySix Best Practices: Model Visually
Capture structure and behavior Show how the system elements fit together Keep design and implementation consistent Hide or expose details as appropriate Promote unambiguous communication Plan before implementing
Six Best Practices: Model Visually Using the UMLSix Best Practices: Model Visually Using the UML
ActivityDiagrams
Models
Dynamic Diagrams
Static Diagrams
SequenceDiagrams
CollaborationDiagrams
StatechartDiagrams
DeploymentDiagrams
ComponentDiagrams
ObjectDiagrams
ClassDiagrams
Use-CaseDiagrams
Six Best Practices: Continuously Verify QualitySix Best Practices: Continuously Verify Quality
FunctionalityFunctionality
ReliabilityReliability
PerformancePerformance
Does my applicationdo what’s required?Does my applicationdo what’s required?
Does the systemperform under production load?
Does the systemperform under production load? Verification of each
usage scenario Verification of each
usage scenario
Verification of sustained application operation
Verification of sustained application operation
Test performance under expected and worst-case load
Test performance under expected and worst-case load
Does my applicationbehave consistently?Does my applicationbehave consistently?
ALERTREPORT
WorkspaceManagement
Process Integration
Parallel Development
Build Management
CM is more than just check-in and check-out
Six Best Practices: Manage ChangeSix Best Practices: Manage Change
Manage changes to enable iterative development Secure workspaces for each developer Automated integration/build management Parallel development
RUP – An Iterative Test & Release Process
Test and Release Iterations with Work Components
RUP – An Iterative Test & Release Process
Test and Release Iterations – an Artifact View
RUP – An Iterative Test & Release Process
Typical Schedule
Phase: Inception [3 weeks] High Level Plan prepared RUP Customized for the project Scope Defined: 20 Use Cases + Supplementary Specs Architecture OutlinedMilestone: Lifecycle Objective
Phase: Elaboration [6 weeks] Iteration E1: Detailed Scope & Prototype (6 weeks)
• Scope Detailed: Over 80% Use Cases written
• Architecturally Significant Use Cases Prototyped:An incremental prototype of the application Designed, Implemented, Tested, and Released to demonstrate mitigation of architectural risks through the main scenarios of 4 Significant Use Cases
Milestone: Lifecycle Architecture
RUP – An ExampleA Software Development Project
Phase: Construction [14 weeks] Iteration C1: Functionality X (8 weeks)
• All scenarios of 4 Use Cased of Iteration: E1 Completed
• 8 more Use Cases Designed & Implemented
• Testing Conducted: Incl. Regression Testing of Prev. Release
Milestone: Functionality X Release
Iteration C2: Functionality X + Y (6 weeks)• 8 more Use Cases Designed & Implemented
• Testing Conducted: Incl. Regression Testing of Prev. Release
Milestone: Initial Operational Capability Phase: Transition [3 weeks]
Iteration T1: UAT & Product Release (3 weeks)• User Interface Testing Conducted
• Application Released
Milestone: Product Release
RUP – An Example
A Software Development Project (continued)
AgendaAgenda
Waterfall vs. Iterative Development Prerequisites and Common Pitfalls An Approach for Iterative Development Case Study – RUP on Small Projects Summary
Common Issues With Iterative DevelopmentCommon Issues With Iterative Development
How do you know the status of the project? How do you decide what goes into an iteration? Delivered code is a rat nest, too expensive to maintain
and extend! How do you know when you are done? Expensive with all rework during the project… How do you manage consistent change?
Mature technology and process Object-oriented methods / component-based development Management understands what is different about managing
iterative development Supporting best practices in place
Mature software environment Advanced, integrated environments Change management Integrated configuration control and quality assessment
Prerequisites to Successful Iterative DevelopmentPrerequisites to Successful Iterative Development
Supporting Best PracticesSupporting Best Practices
Control Control ChangesChanges
Develop Develop IterativelyIteratively
Use Use ComponentComponent
ArchitecturesArchitectures
Model Model VisuallyVisually
VerifyVerifyQualityQuality
Ensures users involved as requirements evolve
Validates architectural decisions early on
Addresses complexity of design/implementation incrementally
Measures quality early and often
Evolves baselines incrementally
Manage Manage RequirementsRequirements
Required Tool Support Required Tool Support
Controlled iterative development
Controlled iterative development
Reduces cost of change
Reduces cost of change
Configuration management Traceability Round-trip Engineering Automated Documentation Automated testing Automated metrics collection Automated status updates Common process
Understand priorities
Understand priorities
Reasons for Failure of Iterative DevelopmentReasons for Failure of Iterative Development
Lack of planning of each iteration Lack of commitment to stabilize the architecture early Poor choice of requirements to implement in earlier
iterations Failure to time box an iteration Focus on documents and reviews Treatment of early iterations as throw-away prototypes
AgendaAgenda
Waterfall vs. Iterative Development Prerequisites and Common Pitfalls An Approach for Iterative Development Case Study – RUP on Small Projects Summary
The 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
Inception Elaboration Construction Transition
Major Major MilestonesMilestones
Phases in the ProcessPhases in the Process
Iterative Model GraphIterative Model Graph
PhasesProcess Workflows
Iterations
Supporting Workflows
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis & Design
Preliminary Iteration(s)
Iter.#1
Iter.#2
Iter.#n
Iter.#n+1
Iter.#n+2
Iter.#m
Iter.#m+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Workflows group activities logically
In an iteration, you walk through all workflows
Inception PhaseInception Phase
PurposeTo establish the business case for a new system or
for a major update of an existing systemTo specify the project scope
OutcomeA general vision of the project’s requirements, i.e.,
the core requirements• Initial use-case model and domain model (10-20% complete)
An initial business case, including:• Success criteria (e.g., revenue projection)• An initial risk assessment• An estimate of resources required
Elaboration PhaseElaboration Phase
Purpose To analyze the problem domain To establish a sound architectural foundation To address the highest risk elements of the project To develop a comprehensive plan showing how the project
will be completed Outcome
Use-case and domain model 80% complete An executable architecture and accompanying
documentation A revised business case, incl. revised risk assessment A development plan for the overall project
Construction PhaseConstruction Phase
Purpose To incrementally develop a complete software product which
is ready to transition into the user community Products
A complete use-case and design model Executable releases of increasing functionality User documentation Deployment documentation Evaluation criteria for each iteration Release descriptions, including quality assurance results Updated development plan
Transition PhaseTransition Phase
Purpose To transition the software product into the user community
Products Executable releases Updated system models Evaluation criteria for each iteration Release descriptions, including quality assurance results Updated user manuals Updated deployment documentation “Post-mortem” analysis of project performance
Iterations and PhasesIterations and Phases
An An iterationiteration is a distinct sequence of activities with an is a distinct sequence of activities with an established plan and evaluation criteria, resulting in an established plan and evaluation criteria, resulting in an executable release (internal or external).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
Releases
Iterative DevelopmentIterative Development
InitialPlanning
Planning
Requirements
Analysis & Design
Implementation
Test
Deployment
Evaluation
ManagementEnvironment
Each iteration results in an executable release
BenefitsBenefits
Each iteration provides you with exact (objective) status information allows you to address top risks allows for stakeholder feedback allows you to re-prioritize requirements and manage scope allows your development team to focus on a new short term
goal allows you to decide what needs to be reworked (improved) allows you to learn from earlier experiences
AgendaAgenda
Waterfall vs. Iterative Development Prerequisites and Common Pitfalls An Approach for Iterative Development Case Study – RUP on Small Projects Summary
Using Rational Unified Process in an SME – A Case StudyUsing Rational Unified Process in an SME – A Case Study
• Norwegian SME• Use of RUP• Output• key message
Using RUP•No restrictions or guidelines were put on the use of RUP
•Courses in RUP, and RUP Online (an electronic process guide on web) was purchased and installed.
•No common guidance for the use of RUP in projects was given.
•The company had no defined goals for introducing RUP.
•It was basically based on a belief that RUP would increase the professionalism in the company.
About Company•Norwegian software consultancy company with 50 employees, located in two different geographic offices.•They are mainly developing software systems with heavy back-end logic and often with a web front-end, typically portals. However, they also develop lighter solutions with most emphasis on the front-end.
Research Methodologies adoptedResearch Methodologies adopted
1. Data collection The first set of data was collected by interviewing project managers representing four
projects. The second set of data was collected by the means of interviews with five other
employees (each having experience with RUP from several various projects).
2 Data Analysis Analysis of the spreadsheet & interviews
Results: Interview round 1: Documenting the use of RUP
Results: Interview round 1: Documenting the use of RUP
The business modeling discipline• Project A was about porting functionality, no
new functionality was introduced, thus not needing business modeling.
• For project B the customer had provided a business use case that was sufficient.
• Project C was developing software to be integrated with other systems. The business modeling discipline was used to clarify these interfaces.
• Project D had a business modeling discipline although it was not performed exactly as described by RUP.
Documenting the use of RUP ..CNTDDocumenting the use of RUP ..CNTD
The requirements discipline The analysis and design discipline The implementation discipline The test discipline The deployment discipline The configuration and change management discipline The project management discipline The environment discipline
Word file: Case disciplines.doc
Interview round 2: Experiences with using RUPInterview round 2: Experiences with using RUP
Suggestions and DiscussionSuggestions and DiscussionBesides this overview of experience using RUP, the respondents also had improvement suggestions:• RUP should be used in a regular manner through the whole project (avoiding deep focus in only parts
of the project)• Projects must be guided in the use of RUP
• Establish a project manager forum (for learning and experience exchange)• Offer support in using and adapting RUP
• As the results from interview round one show, the use of RUP is scattered.• Project participants seems to end up using some RUP elements mixed with old practice• four of the respondents find RUP too comprehensive for small projects This indicates a
definitively need for tailoring of RUP in advance of use in projects.
ConclusionConclusion
• A methodology or framework (such as RUP) can not be provided “as is” without experiencing low/wrong use.
• The users of the methodology need to keep their focus on doing their job (developing software), not struggling to understand the theory.
(This is actually what the RUP documentation says,
… but that many unfortunately forget.)
• In this case the outcome could have been better if the introduction of RUP was carefully managed and not left as an autonomous effort in each project.
AgendaAgenda
Waterfall vs. Iterative Development Prerequisites and Common Pitfalls An Approach for Iterative Development Case Study – RUP on Small Projects Summary
Guidelines for Successful Iterative DevelopmentGuidelines for Successful Iterative Development
Baseline executable architecture early Address top risks early Plan upcoming iteration in detail Time box each iteration Focus on objective measures Control changes Test throughout the lifecycle Implement an integrated software engineering environment
that supports iterative development Learn from the experience of others - use a proven process
ReferencesReferences
www.ibm.com White paper on “Using Rational Unified Process in an SME
– A Case Study” Best practices of RUP – kruchten 2000