RUP for Software Development Projects George Merguerian www.bmc-online.com 1 Specialists in Global Project Management Brussels Frankfurt Houston Istanbul Milan Ottawa Shanghai Singapore Warsaw Washington DC Official Strategic Project Managemen t Advisor To AIRBU BMC 2006 2 1
Project Managed 3 Agenda IT Project Management Developments Agile Approaches and characteristics RUP Where do RUP and PMBOK meet? Challenges 4 2
IT Project Developments 1 out of 3 IT projects fail Standish Group, PM Network.. BMC s s experience indicates a higher failure ratio (Europe) Most failures occur because. Poor coupling of Projects to the Business Process/Strategy Inadequate funding and resourcing of the project Inadequate IT technical competence of team members Poor planning and control processes 5 Key Reasons for Project Failure 1. Inadequately trained and/or inexperienced project managers Poor effort estimation 2. Failure to set and manage expectations Poor communications 3. Poor leadership at any and all levels Misalignment between the project team and the business or other organization it serves 4. Failure to adequately identify, document and track requirements Inadequate or misused methods 5. Poor plans and planning processes Poor planning, control, change management 6. Poor or no Methodology 6 Source: Frank Winters, The Top 10 Reasons Projects Fail in gantthead.com 3
PM Approaches 1950s Classical PM SSDM/CMM/ISO etc 1980s Incremental/Iterative Approaches Objectory Process Rational Approach 1996 1997 Rational Objectory Process RUP (1998) 1990s Agile Methods 7 Agile Methodologies ASD, Adaptive Software Development Crystal Clear DSDM, Dynamic Software Development Method FDD, Feature Driven RAD, Rapid Application Development RUP, Rational Unified Process Scrum XP, Xtreme Programming. 8 4
Comparing Classical and Agile Project Management Approaches 9 Common Principles of Agile Approaches Iterative approach to software development Time-boxed iteration periods Agile processes can handle requirements change during the project s s development cycle Risk management is a key process Emphasize communications and interaction Emphasize resource competency and involvement 10 5
Classical Project Management (waterfall) Agile/Dynamic Project Management Well Defined Needs of the Customer Customer Requirements not fully defined Resource (Budget) Schedule (Time) Resource (Budget) Schedule (Time) Quality (Planned Results) Quality (Planned Results) 11 12 6
Iterative Approach What is it? The project produces a certain % of the ultimate product during each iteration (cycle) of the workflows below Number of iterations depends on the complexity of the project Each Iteration results into executable software 13 Iterative development Versus Waterfall Each iteration builds on the previous one Each step comes closer to the final product Emphasis changes with each iteration 14 7
1. Now is the time for men in the ranks to stay in the ranks. 2. Now is the time for men in the ranks to stay in the ranks. 3. Now is the time for men in the ranks to stay in the ranks. 4. Now is the time for men in the ranks to stay in the ranks. 5. Now is the time for men in the ranks to stay in the ranks. 6. Now is the time for men in the ranks to stay in the ranks. 7. Now is the time for men in the ranks to stay in the ranks. 8. Now is the time for men in the ranks to stay in the ranks. 9. Now is the time for men in the ranks to stay in the ranks. 10. Now is the time for men in the ranks to stay in the ranks. 11. Now is the time for men in the ranks to stay in the ranks. Waterfall Cycle The project Moves from Analysts send requirements Designers Programmers send components Integrators Testers poor responsibility for the final product. 15 Waterfall Cycle 2 months 1 month 4 months What if changes from requirements are identified at this stage? Capture requirements 12 months Analyse 2 months Design Code Integration and Testing 16 BMC 2006 8
Waterfall approach Iterative approach 17 Iterative approach advantages Easier to meet changing requirements (main cause of trouble for IT/IS projects) Integration becomes easier (not the big thing at the end) Risks are discovered earlier Management can make changes to the product Team members gain expertise as they assume several roles during each development cycle/iteration. 18 9
Comparing Classical and Iterative PM Waterfall Classical- SSDM CMM Low Ceremony Little Documentation Light Process Lean DSDM XP Crystal Lite Orange Hybrids Manzo AgileTek Code Agile Plus Boehm-Turner Risk Based High Ceremony Plan-Driven, Well-Documented, Traceability, Change Control Board RUP 19 Iterative Example of an Iterative Approach - SCRUM 20 Source: www.controlchaos.com 10
Introducing RUP 21 Why RUP? Addresses the requirements understanding challenge in IS Allows for requirements refining during the project lifecycle Risk Driven The user gets involved throughout the project s s lifecycle and do not get.. 22 11
23 RUP and the Spiral Model 24 The Spiral Model proposed by Barry W. Boehm 12
Key RUP Concepts Develop Iteratively Use Components Risk Driven Model Visually Manage Requirements Manage Change Fix Architecture early 25 1. Key RUP Concept Develop Iteratively 26 13
A RUP Project Lifecycle 27 2. Key RUP Concept Address risks early Risks Waterfall Risk Reduction Iterative Time BMC 2006 28 14
3. Key RUP Concept: Manage Requirements Business Requirements Vision & Scope Document User Requirements Business Rules Quality Attributes Use Case Document System Requirements Functional Requirements External Interfaces Constraints Source: Karl E. Wiegers Software Requirements Specification 29 BMC 2006 Requirements Development BMC 2006 30 15
4. Key RUP Concept Establish the Architecture Baseline Early A project s s technical risks can be mitigated by implementing and testing the architecture early. A stable architecture facilitates communications and makes it easier to see the impact of changing requirements on the system. Establishing the architecture early facilitates the estimation of a project s s effort. 31 5. Key RUP Concept - Build a components based system Applications built with components are more resilient to change and have reduced system maintenance costs. Components facilitate reuse, allowing you to build higher quality applications faster than using functional decomposition. Functional decomposition Component based architecture 32 16
6. Key RUP Concept Model Visually RUP is a Model- Based Development Process. Models are abstractions of reality and help to make communications between stakeholders more effective 33 7. Key RUP Concept Accommodate change early Changes that come late into the project mean rework, increase in costs, reduce quality, and cause schedule delays. The graphic below shows the impact of change on a project s costs during its lifecycle. 34 17
Managing Change Requests and Configuration Management 35 How The Development Lifecycle is Managed in RUP Process? Dynamic Elements: The horizontal (Time) dimension of the project expressed in phases, iterations and Milestones. Static Elements : The vertical dimension describes how process elements activities, workflows, artifacts,, and roles are logically grouped into core process disciplines. 36 18
Dynamic Elments 4 phases: 1. Inception Phase: Understand the scope of the project, Functional and non-functional requirements, build the business case and get stakeholders buy-in. 2. Elaboration Phase: Mitigate key technical risks and develop an architecture baseline. e. 3. Construction Phase: Build the operational version of the product 4. Transition Phase: Build the final version of the product and deliver it to the customer 37 Dynamic Aspect of RUP Changes in requirements A phase is a period of time between two major milestones of the project Each phase has exit criteria to ensure that objectives are met, artifacts are finalized. Upon satisfaction of the key stakeholders a decision is made whether to proceed to the next phase. An iteration is like a mini project with defined sequence of activities Each iteration has a plan and criteria for success. 38 19
RUP Lifecycle in terms of Schedule and Effort Inception Elaboration Construction Transition Effort ~5 % 20 % 65 % 10% Schedule 10 % 30 % 50 % 10% BMC 2006 39 Static Elements: 9 Core Process Disciplines Logical grouping of the process elements- activities, workflows, artifacts and roles encapsulated into nine core process disciplines: 1.Business modelling 2.Requirements 3.Analysis and Design 4.Implementation 5.Test Test 6.Deployment 7.Configuration and change management 8.Project Project management 9.Environment 40 20
A Core Process Discipline: Groups 4 process elements together activities, workflows, artifacts and roles Artifacts Use case realisation Designer Use Case Analysis Use Case Design 41 Roles Activities The Concept of Role, Activity and Artifact are central for RUP 42 21
Roadmap of RUP Workflows, Roles and Artefacts (Snapshot taken from IBM RUP Builder) 43 An Example of a Key Artefact The vision Document Who needs the project Who will use it The benefits of the project, what problem it will solve.. Key deliverables, Key features (use cases) Non-functional requirements The benefits that the application will produce business-wise, the problems it will solve, risks Who are the key stakeholders What will the product do key use cases Non functional requirements database support, OS related issues, scaleability etc. The Vision document is updated regularly it is like a contract document between the clients of the project and the project team. 44 22
I The Problem The current reporting system and structure at the Unit are inadequate. There are too many activities (critical and noncritical) which are being reported on. The situation is of an over-reporting one. The Head of the Unit requires a new reporting system which captures key information visually and yet allows more in depth probing if necessary.. II III III The benefits of a new system Key deliverables of the project Non-Functional requirements A reporting system of the above nature will save the head of the Unit 6 hours per week allowing him to focus on areas of priority. The system will also enable for reports to enter information on a centralized basis which is then automatically consolidated for viewing by the Directors.. A Secure report entry tool A database Report output based on a Dashboard system visual with links to the projects being reported on... The system should be flexible enough to allow future changes in the reporting structure. Easy addition of new Reports Potential links to other reporting systems that may be developed Capability for web based report generation. Example of vision IV Current Environment See Figure 1 (slide) V Proposed Solution See Figures 2 and 3 (slide) VI Stakeholders The Directorate: Receiving the reports of the Unit. A visual Dashboard system will be easier to follow and save time. The Director of the unit: the initiator of this project. The Reports: will welcome an automated reporting system. However may loose influence towards the leaders as data will be consolidated. Also some of the activities will loose their current visibility/importance of the work done. The DG: The DG may wish to consolidate such initiatives that may be undertaken in other directorates. The IRM of the DG. Will need to find time and space for the project. DIGIT: May have a similar tool in place. VII Risks & Constraints Business changes Transfer Missing Input Mitigate interact with users Users do not like to use application mitigate/transfer Access rights/data Protection Do not care VIII Resources Initial Estimates: 200 Person Days involving: o System Analyst o Architect 45 o Programmer o Dbase specialist BMC 2006 Vision Document Figure 2: System Perspective Features (needs) Filtering of activities Planned work/actual/issues/risks (input) Security (Role Based Access) Historical Trend (nice to have?) Assumptions/Risks Report types can evolve No other points of extensibility Weekly based process Data input is reliable Resources 1 Analyst Designer 1 PM 1 DB Expert 2 Developers (GUI) 1 Tester 1 Technical Writer 1 Support + Training Iterations Inception - 5% of effort 1 iteration Elaboration - - 25 % 1 or 2 iterations Iteration 1 Technical Architecture; Initial SW; Mitigate Key Technical risks: output function, input function. Construction 60% - 2 iterations Iteration 1: 70% of report. out; 40% of report. Input Iteration 2: 25% report. Out; 55% Report. In Transition 10% - 1 Iteration Delivery + Training 46 23
Use Case Example Input Data Happy Scenario 1. User Logs in 2. Select User s Projects 3. Display projects 4. Select project for editing 5. Edit 6. Save information 7. Back to list User Login Controller (checks ECAS) Login rejected Display Request Project Display Catalogue No Project Details Found Select Project for Edit Display Project Details Edit Project Dbase Update Dbase Display Updated Project Details Enter History 47 BMC 2006 Principal Key RUP Artefacts Vision Document Glossary Architecture Software Configuration Management Plan Test Plans, Scripts, Results User Support Manuals Support Software Development Plan Software Architecture Document Iteration Plan Risk Plan 48 24
The RUP Process Framework Dynamic & Static Elements 49 RUP Templates and Support Tools 50 25
Software is Available to Support The RUP Process 51 Where do RUP and Project Management (PMBOK ) ) Meet? Starting a project, a phase or an iteration and reviews Project Management Configuration management, production releases and change management Measuring Progress PMBOK is Project Management Institute s standard for managing projects Project Management Body of Knowledge 52 26
The PMBOK Process Groups 53 Key Outputs (Artifacts( Artifacts) ) of the PMBOK Process Groups Initiation Project Charter Planning The Project Execution Plan Execution and Control Closing Progress reports, Scope Verification, Time, $, Risk and Q control Admin/Contractual Closure & Lessons Learnt 54 27
The Project Management Core Discipline in RUP 55 Project Management 56 28
Elaboration Phase Revised Planning Inception Time (weeks) Revised (Weeks) Effort (Days) Revised (Days) Actual (Days) Artefacts 1 Iteration 1 W 1 W 3 D 4 D 4 D Vision (LCO) 1 Iteration 1 W 2 D 2 D 4 Use Cases Elaboration 1 Iteration 2 W 6 D Final & all Use Cases Architecture & SAD (LCA) 1 Iteration 4 W 6 W 10 D 15 D Functional Prototype Database Constructio n Iteration 1 12 W 10 W 30 D 24 D Dashboard V 1.0 Iteration 2 12 W 10 W 30 D 24 D Dashboard V Final Drill Down Transition 1 Iteration 2 W 10 D Manual & Training 57 Difficult to compare.. PMBOK Outputs and RUP Artifacts Project Charter s s Problem definition and Business Case Vision Document The Project Execution Plan Vision Document and Software Development Plan Software, Progress reports, software, test results Software, Progress reports, software, test results Config.. Management.. Config.. Management.. 58 29
RUP Project Management is one of the core disciplines Each iteration is like a project Risk management occurs throughout the lifecycle of the project Team roles change according to phase RUP is a comprehensive methodology packaged into a product by IBM (though UP is open to public) RUP does not cover how you can use PM tools 59 RUP Challenges Applying RUP in tendering situations involving contractors Documentation- notion that projects are over- planned Organisational readiness to work with X-X disciplinary teams Involving end users Relatively lower maturity across non-it/is companies in using RUP (Budget flexibility, teams, etc.) 60 30
Reflections on Contractors Most customers prefer fixed price contracts stable requirements Fixed Price Contracts and requirements change do not fit in RUP Customer needs to accept scope flexibility if T and $ are fixed In IT visualisation of the end product difficult RUP involves the customer in each iteration no surprise at the end 61 When to sign a contract?? 62 31
The 7 Sins of RUP 1. Planning to death 2. Detailing too much 3. Skipping Problem Analysis 4. Letting end dates of iterations slip 5. Starting the construction phase before fulfilling the exit criteria of the elaboration phase 6. Testing only at the end of the project 7. Failing to move the product to maintenance Adopting the Rational Unified Process Stefan Bergström and Lotta Raberg 63 RUP Concluding remarks Results into high quality software Less customer surprises than traditional Well supported product Large community of users - RUP and UP user groups Needs organisational support for success Select methodology according to your own needs 64 32
Questions? 65 33