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


Test and Release Iterations – an Artifact View


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


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



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


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


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

http://www.ibm.com/

Use of RUP for Small Projects

Education

Transcript of Use of RUP for Small Projects