Use of RUP for Small Projects

Use of RUP for Small Projects Mahesh Panchal 07030244006 Nitin Garg 07030244008 Ravindra Nath Sharma 07030244018 Utkarsh Khare 07030244025

Agenda

Waterfall vs. Iterative Development

Prerequisites and Common Pitfalls

An Approach for Iterative Development

Case Study – Small Project

Summary

Waterfall Development Delays Reduction of Risk R I S K T I M E Subsystem Testing System Testing Code & Unit Testing Design Requirements Analysis

Apply the Waterfall Iteratively to System Increments Earliest iterations address greatest risks Each iteration produces an executable release, an additional increment of the system Each iteration includes integration and test T C D R T I M E Iteration 1 Iteration 2 Iteration 3 T C D R T C D R

Iterative 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

Iterative Development Accelerates Risk Reduction Transition Risk Inception Elaboration Construction Preliminary Iteration Architect. Iteration Architect. Iteration Devel. Iteration Devel. Iteration Devel. Iteration Transition Iteration Transition Iteration Post- deployment Waterfall Time Staffing Risk

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 Engineering Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change

Six 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

Six Best Practices: Develop Iteratively Time Risk Waterfall Risk Risk Reduction Iterative Risk

Six Best Practices: Manage Requirements

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.

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 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 UML Activity Diagrams Models Dynamic Diagrams Static Diagrams Sequence Diagrams Collaboration Diagrams Statechart Diagrams Deployment Diagrams Component Diagrams Object Diagrams Class Diagrams Use-Case Diagrams

Six Best Practices: Continuously Verify Quality Functionality Reliability Performance

Verification of each usage scenario

Verification of sustained application operation

Test performance under expected and worst-case load

Does my application do what’s required? Does the system perform under production load? Does my application behave consistently?

Six Best Practices: Manage Change

Manage changes to enable iterative development

Secure workspaces for each developer

Automated integration/build management

Parallel development

Workspace Management Process Integration Parallel Development Build Management ALERT REPORT CM is more than just check-in and check-out

Test and Release Iterations with Work Components

RUP – An Iterative Test & Release Process

RUP – An Iterative Test & Release Process Test and Release Iterations – an Artifact View

Typical Schedule

RUP – An Iterative Test & Release Process

Phase: Inception [3 weeks]

High Level Plan prepared

RUP Customized for the project

Scope Defined: 20 Use Cases + Supplementary Specs

Architecture Outlined

Milestone: 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 Example A 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)

Agenda

Case Study – RUP on Small Projects

Summary

Common 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 Development

Supporting Best Practices Control Changes Use Component Architectures Model Visually Verify Quality 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 Requirements Develop Iteratively

Required Tool Support

Configuration management

Traceability

Round-trip Engineering

Automated Documentation

Automated testing

Automated metrics collection

Automated status updates

Common process

Controlled iterative development Reduces cost of change Understand priorities

Reasons 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

Agenda

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

Phases in the Process time Inception Elaboration Construction Transition Major Milestones

Iterative Model Graph Phases Process Workflows Iterations Supporting Workflows Management Environment 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 Transition Inception Construction Workflows group activities logically In an iteration, you walk through all workflows

Inception Phase

Purpose

To establish the business case for a new system or for a major update of an existing system

To specify the project scope

Outcome

A 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 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 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 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 Phases An iteration is a distinct sequence of activities with an established plan and evaluation criteria, resulting in an executable release (internal or external). Preliminary Iteration Architect. Iteration Architect. Iteration Devel. Iteration Devel. Iteration Devel. Iteration Transition Iteration Transition Iteration Inception Elaboration Construction Transition Releases

Iterative Development Initial Planning Planning Requirements Analysis & Design Implementation Test Deployment Evaluation Management Environment Each iteration results in an executable release

Benefits

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

Agenda

Summary

Using 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 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

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 ..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 RUP

Suggestions and Discussion

Besides this overview of experience using RUP, the respondents also had improvement suggestions:

• RUP should be used in a regular manne r 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.

Conclusion

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.

Agenda