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

2.
Agenda <ul><li>Waterfall vs. Iterative Development </li></ul><ul><li>Prerequisites and Common Pitfalls </li></ul><ul><li>An Approach for Iterative Development </li></ul><ul><li>Case Study – Small Project </li></ul><ul><li>Summary </li></ul>

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

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

5.
Iterative Development Characteristics <ul><li>Critical risks are resolved before making large investments </li></ul><ul><li>Initial iterations enable early user feedback </li></ul><ul><li>Testing and integration are continuous </li></ul><ul><li>Objective milestones provide short-term focus </li></ul><ul><li>Progress is measured by assessing implementations </li></ul><ul><li>Partial implementations can be deployed </li></ul>

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

7.
Introduction to the Rational Unified Process (RUP) <ul><li>RUP is a complete lifecycle software engineering process </li></ul><ul><li>It provides a risk driven approach to assigning tasks and responsibilities within a development organization </li></ul><ul><li>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 </li></ul><ul><li>Developed over many years of working with customers </li></ul><ul><li>Architecture focus </li></ul><ul><li>Easily customized </li></ul><ul><li>Web based implementation </li></ul>

8.
The Six Best Practices of Software Engineering Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change

9.
Six Best Practices: Develop Iteratively <ul><li>Delays confirmation of critical risk resolution </li></ul><ul><li>Measures progress by assessing work-products that are poor predictors of time-to-completion </li></ul><ul><li>Delays and aggregates integration and testing </li></ul><ul><li>Precludes early deployment </li></ul><ul><li>Frequently results in major unplanned iterations </li></ul>Code and unit test Design Subsystem integration System test Waterfall Process Requirements analysis

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

11.
Six Best Practices: Manage Requirements <ul><li>Making sure you </li></ul><ul><ul><li>solve the right problem </li></ul></ul><ul><ul><li>build the right system </li></ul></ul><ul><li>by taking a systematic approach to </li></ul><ul><ul><li>eliciting </li></ul></ul><ul><ul><li>organizing </li></ul></ul><ul><ul><li>documenting </li></ul></ul><ul><ul><li>managing </li></ul></ul><ul><li>the changing requirements of a software application. </li></ul>

12.
Six Best Practices: Use Component Architectures <ul><li>Resilient </li></ul><ul><ul><li>Meets current and future requirements </li></ul></ul><ul><ul><li>Improves extensibility </li></ul></ul><ul><ul><li>Enables reuse </li></ul></ul><ul><ul><li>Encapsulates system dependencies </li></ul></ul><ul><li>Component-based </li></ul><ul><ul><li>Reuse or customize components </li></ul></ul><ul><ul><li>Select from commercially available components </li></ul></ul><ul><ul><li>Evolve existing software incrementally </li></ul></ul>

13.
Six Best Practices: Model Visually <ul><li>Capture structure and behavior </li></ul><ul><li>Show how the system elements fit together </li></ul><ul><li>Keep design and implementation consistent </li></ul><ul><li>Hide or expose details as appropriate </li></ul><ul><li>Promote unambiguous communication </li></ul><ul><li>Plan before implementing </li></ul>

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

15.
Six Best Practices: Continuously Verify Quality Functionality Reliability Performance <ul><li>Verification of each usage scenario </li></ul><ul><li>Verification of sustained application operation </li></ul><ul><li>Test performance under expected and worst-case load </li></ul>Does my application do what’s required? Does the system perform under production load? Does my application behave consistently?

16.
Six Best Practices: Manage Change <ul><li>Manage changes to enable iterative development </li></ul><ul><li>Secure workspaces for each developer </li></ul><ul><li>Automated integration/build management </li></ul><ul><li>Parallel development </li></ul>Workspace Management Process Integration Parallel Development Build Management ALERT REPORT CM is more than just check-in and check-out

17.
<ul><li>Test and Release Iterations with Work Components </li></ul>RUP – An Iterative Test & Release Process

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

19.
<ul><li>Typical Schedule </li></ul>RUP – An Iterative Test & Release Process

20.
<ul><li>Phase: Inception [3 weeks] </li></ul><ul><ul><li>High Level Plan prepared </li></ul></ul><ul><ul><li>RUP Customized for the project </li></ul></ul><ul><ul><li>Scope Defined: 20 Use Cases + Supplementary Specs </li></ul></ul><ul><ul><li>Architecture Outlined </li></ul></ul><ul><ul><li>Milestone: Lifecycle Objective </li></ul></ul><ul><li>Phase: Elaboration [6 weeks] </li></ul><ul><ul><li>Iteration E1: Detailed Scope & Prototype (6 weeks) </li></ul></ul><ul><ul><ul><li>Scope Detailed: Over 80% Use Cases written </li></ul></ul></ul><ul><ul><ul><li>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 </li></ul></ul></ul><ul><ul><li>Milestone: Lifecycle Architecture </li></ul></ul>RUP – An Example A Software Development Project

21.
<ul><li>Phase: Construction [14 weeks] </li></ul><ul><ul><li>Iteration C1: Functionality X (8 weeks) </li></ul></ul><ul><ul><ul><li>All scenarios of 4 Use Cased of Iteration: E1 Completed </li></ul></ul></ul><ul><ul><ul><li>8 more Use Cases Designed & Implemented </li></ul></ul></ul><ul><ul><ul><li>Testing Conducted: Incl. Regression Testing of Prev. Release </li></ul></ul></ul><ul><ul><ul><li>Milestone: Functionality X Release </li></ul></ul></ul><ul><ul><li>Iteration C2: Functionality X + Y (6 weeks) </li></ul></ul><ul><ul><ul><li>8 more Use Cases Designed & Implemented </li></ul></ul></ul><ul><ul><ul><li>Testing Conducted: Incl. Regression Testing of Prev. Release </li></ul></ul></ul><ul><ul><li>Milestone: Initial Operational Capability </li></ul></ul><ul><li>Phase: Transition [3 weeks] </li></ul><ul><ul><li>Iteration T1: UAT & Product Release (3 weeks) </li></ul></ul><ul><ul><ul><li>User Interface Testing Conducted </li></ul></ul></ul><ul><ul><ul><li>Application Released </li></ul></ul></ul><ul><ul><li>Milestone: Product Release </li></ul></ul>RUP – An Example A Software Development Project (continued)

22.
Agenda <ul><li>Waterfall vs. Iterative Development </li></ul><ul><li>Prerequisites and Common Pitfalls </li></ul><ul><li>An Approach for Iterative Development </li></ul><ul><li>Case Study – RUP on Small Projects </li></ul><ul><li>Summary </li></ul>

23.
Common Issues With Iterative Development <ul><li>How do you know the status of the project? </li></ul><ul><li>How do you decide what goes into an iteration? </li></ul><ul><li>Delivered code is a rat nest, too expensive to maintain and extend! </li></ul><ul><li>How do you know when you are done? </li></ul><ul><li>Expensive with all rework during the project… </li></ul><ul><li>How do you manage consistent change? </li></ul>

24.
<ul><li>Mature technology and process </li></ul><ul><ul><li>Object-oriented methods / component-based development </li></ul></ul><ul><ul><li>Management understands what is different about managing iterative development </li></ul></ul><ul><ul><li>Supporting best practices in place </li></ul></ul><ul><li>Mature software environment </li></ul><ul><ul><li>Advanced, integrated environments </li></ul></ul><ul><ul><li>Change management </li></ul></ul><ul><ul><li>Integrated configuration control and quality assessment </li></ul></ul>Prerequisites to Successful Iterative Development

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

26.
Required Tool Support <ul><li>Configuration management </li></ul><ul><li>Traceability </li></ul><ul><li>Round-trip Engineering </li></ul><ul><li>Automated Documentation </li></ul><ul><li>Automated testing </li></ul><ul><li>Automated metrics collection </li></ul><ul><li>Automated status updates </li></ul><ul><li>Common process </li></ul>Controlled iterative development Reduces cost of change Understand priorities

27.
Reasons for Failure of Iterative Development <ul><li>Lack of planning of each iteration </li></ul><ul><li>Lack of commitment to stabilize the architecture early </li></ul><ul><li>Poor choice of requirements to implement in earlier iterations </li></ul><ul><li>Failure to time box an iteration </li></ul><ul><li>Focus on documents and reviews </li></ul><ul><li>Treatment of early iterations as throw-away prototypes </li></ul>

28.
Agenda <ul><li>Waterfall vs. Iterative Development </li></ul><ul><li>Prerequisites and Common Pitfalls </li></ul><ul><li>An Approach for Iterative Development </li></ul><ul><li>Case Study – RUP on Small Projects </li></ul><ul><li>Summary </li></ul>

29.
<ul><li>The Rational Unified Process has four phases: </li></ul><ul><ul><li>Inception - Define the scope of project </li></ul></ul><ul><ul><li>Elaboration - Plan project, specify features, baseline architecture </li></ul></ul><ul><ul><li>Construction - Build the product </li></ul></ul><ul><ul><li>Transition - Transition the product into end user community </li></ul></ul>Phases in the Process time Inception Elaboration Construction Transition Major Milestones

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

31.
Inception Phase <ul><li>Purpose </li></ul><ul><ul><li>To establish the business case for a new system or for a major update of an existing system </li></ul></ul><ul><ul><li>To specify the project scope </li></ul></ul><ul><li>Outcome </li></ul><ul><ul><li>A general vision of the project’s requirements, i.e., the core requirements </li></ul></ul><ul><ul><ul><li>Initial use-case model and domain model (10-20% complete) </li></ul></ul></ul><ul><ul><li>An initial business case, including: </li></ul></ul><ul><ul><ul><li>Success criteria (e.g., revenue projection) </li></ul></ul></ul><ul><ul><ul><li>An initial risk assessment </li></ul></ul></ul><ul><ul><ul><li>An estimate of resources required </li></ul></ul></ul>

32.
Elaboration Phase <ul><li>Purpose </li></ul><ul><ul><li>To analyze the problem domain </li></ul></ul><ul><ul><li>To establish a sound architectural foundation </li></ul></ul><ul><ul><li>To address the highest risk elements of the project </li></ul></ul><ul><ul><li>To develop a comprehensive plan showing how the project will be completed </li></ul></ul><ul><li>Outcome </li></ul><ul><ul><li>Use-case and domain model 80% complete </li></ul></ul><ul><ul><li>An executable architecture and accompanying documentation </li></ul></ul><ul><ul><li>A revised business case, incl. revised risk assessment </li></ul></ul><ul><ul><li>A development plan for the overall project </li></ul></ul>

33.
Construction Phase <ul><li>Purpose </li></ul><ul><ul><li>To incrementally develop a complete software product which is ready to transition into the user community </li></ul></ul><ul><li>Products </li></ul><ul><ul><li>A complete use-case and design model </li></ul></ul><ul><ul><li>Executable releases of increasing functionality </li></ul></ul><ul><ul><li>User documentation </li></ul></ul><ul><ul><li>Deployment documentation </li></ul></ul><ul><ul><li>Evaluation criteria for each iteration </li></ul></ul><ul><ul><li>Release descriptions, including quality assurance results </li></ul></ul><ul><ul><li>Updated development plan </li></ul></ul>

34.
Transition Phase <ul><li>Purpose </li></ul><ul><ul><li>To transition the software product into the user community </li></ul></ul><ul><li>Products </li></ul><ul><ul><li>Executable releases </li></ul></ul><ul><ul><li>Updated system models </li></ul></ul><ul><ul><li>Evaluation criteria for each iteration </li></ul></ul><ul><ul><li>Release descriptions, including quality assurance results </li></ul></ul><ul><ul><li>Updated user manuals </li></ul></ul><ul><ul><li>Updated deployment documentation </li></ul></ul><ul><ul><li>“ Post-mortem” analysis of project performance </li></ul></ul>

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

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

37.
Benefits <ul><li>Each iteration </li></ul><ul><ul><li>provides you with exact (objective) status information </li></ul></ul><ul><ul><li>allows you to address top risks </li></ul></ul><ul><ul><li>allows for stakeholder feedback </li></ul></ul><ul><ul><li>allows you to re-prioritize requirements and manage scope </li></ul></ul><ul><ul><li>allows your development team to focus on a new short term goal </li></ul></ul><ul><ul><li>allows you to decide what needs to be reworked (improved) </li></ul></ul><ul><ul><li>allows you to learn from earlier experiences </li></ul></ul>

38.
Agenda <ul><li>Waterfall vs. Iterative Development </li></ul><ul><li>Prerequisites and Common Pitfalls </li></ul><ul><li>An Approach for Iterative Development </li></ul><ul><li>Case Study – RUP on Small Projects </li></ul><ul><li>Summary </li></ul>

39.
Using Rational Unified Process in an SME – A Case Study <ul><li>Norwegian SME </li></ul><ul><li>Use of RUP </li></ul><ul><li>Output </li></ul><ul><li>key message </li></ul><ul><li>Using RUP </li></ul><ul><li>No restrictions or guidelines were put on the use of RUP </li></ul><ul><li>Courses in RUP, and RUP Online (an electronic process guide on web ) was purchased and installed. </li></ul><ul><li>No common guidance for the use of RUP in projects was given. </li></ul><ul><li>The company had no defined goals for introducing RUP. </li></ul><ul><li>It was basically based on a belief that RUP would increase the professionalism in the company. </li></ul><ul><li>About Company </li></ul><ul><li>Norwegian software consultancy company with 50 employees, located in two different geographic offices. </li></ul><ul><li>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. </li></ul>

40.
Research Methodologies adopted <ul><li>1. Data collection </li></ul><ul><ul><li>The first set of data was collected by interviewing project managers representing four projects. </li></ul></ul><ul><ul><li>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). </li></ul></ul><ul><li>2 Data Analysis </li></ul><ul><ul><li>Analysis of the spreadsheet & interviews </li></ul></ul>

41.
Results: Interview round 1: Documenting the use of RUP <ul><li>The business modeling discipline </li></ul><ul><li>Project A was about porting functionality, no new functionality was introduced , thus not needing business modeling . </li></ul><ul><li>For project B the customer had provided a business use case that was sufficient. </li></ul><ul><li>Project C was developing software to be integrated with other systems . The business modeling discipline was used to clarify these interfaces. </li></ul><ul><li>Project D had a business modeling discipline although it was not performed exactly as described by RUP. </li></ul>

42.
Documenting the use of RUP ..CNTD <ul><li>The requirements discipline </li></ul><ul><li>The analysis and design discipline </li></ul><ul><li>The implementation discipline </li></ul><ul><li>The test discipline </li></ul><ul><li>The deployment discipline </li></ul><ul><li>The configuration and change management discipline </li></ul><ul><li>The project management discipline </li></ul><ul><li>The environment discipline </li></ul>Word file: Case disciplines.doc

43.
Interview round 2: Experiences with using RUP

44.
Suggestions and Discussion <ul><li>Besides this overview of experience using RUP, the respondents also had improvement suggestions: </li></ul><ul><li>• RUP should be used in a regular manne r through the whole project (avoiding deep focus in only parts of the project) </li></ul><ul><li>• Projects must be guided in the use of RUP </li></ul><ul><li>• Establish a project manager forum (for learning and experience exchange) </li></ul><ul><li>• Offer support in using and adapting RUP </li></ul><ul><li>As the results from interview round one show, the use of RUP is scattered. </li></ul><ul><li>Project participants seems to end up using some RUP elements mixed with old practice </li></ul><ul><li>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. </li></ul>

45.
Conclusion <ul><li>A methodology or framework (such as RUP) can not be provided “as is” without experiencing low/wrong use. </li></ul><ul><li>The users of the methodology need to keep their focus on doing their job (developing software), not struggling to understand the theory. </li></ul><ul><li>(This is actually what the RUP documentation says, </li></ul><ul><li>… but that many unfortunately forget.) </li></ul><ul><li>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. </li></ul>

46.
Agenda <ul><li>Waterfall vs. Iterative Development </li></ul><ul><li>Prerequisites and Common Pitfalls </li></ul><ul><li>An Approach for Iterative Development </li></ul><ul><li>Case Study – RUP on Small Projects </li></ul><ul><li>Summary </li></ul>

47.
Guidelines for Successful Iterative Development <ul><li>Baseline executable architecture early </li></ul><ul><li>Address top risks early </li></ul><ul><li>Plan upcoming iteration in detail </li></ul><ul><li>Time box each iteration </li></ul><ul><li>Focus on objective measures </li></ul><ul><li>Control changes </li></ul><ul><li>Test throughout the lifecycle </li></ul><ul><li>Implement an integrated software engineering environment that supports iterative development </li></ul><ul><li>Learn from the experience of others - use a proven process </li></ul>

48.
References <ul><li>www.ibm.com </li></ul><ul><li>White paper on “Using Rational Unified Process in an SME – A Case Study” </li></ul><ul><li>Best practices of RUP – kruchten 2000 </li></ul>