RUP for Software Development Projects

1. RUPfor Software Development Projects By George Merguerian Senior Partner Business Management Consultants Merguerian@bmc-online.com www.BMC-Online.com

2. Agenda • IT Project Management Developments • Introduction to RUP • Understand the differences between RUP and Classical Project Management • Key RUP Concepts: Familiarise yourself with the RUP Project Management Approach

3. Global Consultancy 20 years old Training, Coaching, Consulting in 10 languages PMI, APM, PRINCE2 Capabilities

4. Seminar Content References Content material have been drawn from the following sources: • BMC Experiences • The Rational Unified Process Made Easy – A Practitioner’s Guide to RUP – Per Kroll, Philippe Kruchten – Addison Wesley- 2003 • Adopting the Rational Unified Process – Success with RUP – Stefan Bergström, Lotta Raberg – Addison Wesley - 2004 • Managing Agile Projects – Sanjiv Augustine - Robert C. Martin S.- 2005 • Agile and iterative development - Larman, Craig - Addison-Wesley – 2003 • Extending The Rational Unified Process – S.W. Ambler, J. Nalbone, M.J. Vizdos – Prentice Hall -2005

5. IT Project Management Developments

6. The IT Situation • 52.7% of IT projects cost 189% of their original estimates, • Nearly half of all application development projects cost 70% more than originally budgeted. Managers cite lack of user input as the main reason for project failure • 31.1% of projects will be canceled before they ever get completed, • For every 100 projects that start, there are 94 restarts, with some projects having more than 1 restart. Source: The Standish Group

7. In Europe and North America • More than 200 billion Euros are spent each year on IT application development of approximately 175,000 projects. • Every year, Euros 50 billion is spent on failed IT projects Source: Solutions Integrator

8. The IT Situation • The average canceled IT project is scheduled to last 27 weeks and is canceled on week 14 • The average organization annually ties up 10% of the organization's IT staff each year on work that contributed no value to the business • Management failure - team members indicate they know the likelihood that the project will fail 6 weeks before it is canceled • For these projects, an average of 11 IT professionals come to work and contribute nothing Source: TechRepublic/Gartner Group

9. Inadequately trained and/or inexperienced project managers Poor effort estimation Failure to set and manage expectations  Poor communications Poor leadership at any and all levels Misalignment between the project team and the business or other organization it serves Failure to adequately identify, document and track requirements Inadequate or misused methods Poor plans and planning processes Poor planning, control, change management Poor or no Methodology Key Reasons for Project Failure Source: Frank Winters, ”The Top 10 Reasons Projects Fail” in gantthead.com

10. Reasons Projects Succeed in Organisations Objectives Clarified Early 34% 29% Consistent, Transparent Communication Stakeholder Collaboration 3% Ability to Adapt to Changes 34% Source – PMI Network

11. PM-IT Approaches Evolution Classical PM – SSDM/CMM/ISO etc 1960s Incremental/Iterative Approaches As of 1986 Objectory Process Rational Objectory Process RUP (1998) 1996 1997 Rational Approach Agile Methods As of 2001 RUP@DIGIT 2005

12. Comparing Classical and Iterative PM Waterfall CMM Classical- SSDM Hybrids Manzo – AgileTek Code Agile Plus Boehm-Turner Risk Based Low Ceremony High Ceremony Plan-Driven, Well-Documented, Traceability, Change Control Board Little Documentation Light Process Lean DSDM XP Crystal Lite Orange RUP RUP@EC CMMI & ISO/IEC 15504 Iterative

13. A Risk-based Balancing Process Source: CMMI conference 2003

14. Introduction to RUP

15. RUP? • Rational Unified Process Framework is a family of agile methodologies XP, DSDM, developed in the 90s • Adaptive approaches (Vs predictive) with phases, iterations, and workflows

16. Classical Project Management (waterfall) Agile/Dynamic Project Management Well Defined Needs of the Customer Customer Requirements not fully defined Resource (Budget) Resource (Budget) Schedule (Time) Schedule (Time) Quality (Planned Results) Quality (Planned Results)

17. Schedule (Time) Customer Requirements not fully defined Iterative Approach to Project Management Quality (Planned Results) Resource (Budget)

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

19. Iterative development Versus “Waterfall” • Each iteration builds on the previous one • Each step comes closer to the final product • Emphasis changes with each iteration

20. Now is the time for men in the ranks to stay in the ranks. • Now is the time for men in the ranks to stay in the ranks. • Now is the time for men in the ranks to stay in the ranks. • Now is the time for men in the ranks to stay in the ranks. • Now is the time for men in the ranks to stay in the ranks. • Now is the time for men in the ranks to stay in the ranks. • Now is the time for men in the ranks to stay in the ranks. • Now is the time for men in the ranks to stay in the ranks. • Now is the time for men in the ranks to stay in the ranks. • Now is the time for men in the ranks to stay in the ranks. • Now is the time for men in the ranks to stay in the ranks. Waterfall Cycle What if changes from requirements are identified at this stage? 2 months 1 month 4 months And at this stage? Capture requirements 12 months Analyze 2 months Design Code Integrate, test & perform QA

21. Waterfall Approach The project Moves from Analysts send requirements  Designers  Programmers send components  Integrators Testers  ‘poor’ responsibility for the final product.

22. 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 risk changes to the product

23. What is RUP ? • Software Development Approach • Software Engineering Process • Customisable process framework

24. RUP – Software Development Approach • Iterative • Architecture centric • Use Case driven

25. RUP – Software Engineering Process • RUP provides a structure for the lifecycle of a RUP project • Roles and responsibilities • How things are done • When things are done – milestones and decision points are defined

26. RUP – Customisable Process • RUP allows for a variety of processes and process configurations to be derived from it • The software provides guides, reviews tests etc to support software development

27. KEY RUP Concepts

28. Key RUP Concepts • Address risks early • Deliver value to customers • Stay focused on executable software • Accommodate change early in the project • Baseline an executable architecture early • Build your system with components

29. 1. Key RUP Concepts – Address risks early Risks Waterfall Risk Reduction Iterative Time

30. 2. Key RUP Concepts – Deliver Value to Customers • Use iterative development • Engage the customer continuously • Use cases to capture functionality

31. 3. Key RUP Concepts – Stay focused on Executable Software • Measure progress by measuring executable software produced. • Detailing all user cases does not necessarily mean that the customer requirements are met.

32. 4. Key RUP Concepts – Accommodate change early • Some changes that come late in the project may mean a lot of rework, increased cost, reduced quality, and probable delays. • To optimise your Change Management strategy, consider the relative cost of introducing at different stages of the project lifecycle.

33. 5. Key RUP Concepts - Baseline an executable architecture early • Project risks can be mitigated by designing, implementing, and testing the architecture early in the project. Establishing a stable architecture early on also facilitates communication and localizes the impact of changes. • As the architecture comprises of the system’s building blocks, it allows you assess the effort needed to complete the project.

34. 6. Key RUP Concepts - Build your system with components. Applications built with components are more resilient to change and can have radically reduced system maintenance costs. Components facilitate reuse, allowing you to build higher quality applications faster than using functional decomposition.

35. RUP – Getting into depth

36. RUP has Dynamic and Static Dimension • Dynamic structure. The horizontal (Time) dimension of the project. It shows how the project processes, expressed in terms of cycles, phases, iterations, and milestones, unfolds over its lifecycle. • Static structure. The vertical dimension describes how process elements — activities, workflows, artifacts, and roles — are logically grouped into core process disciplines.

37. Dynamic Structure of RUP • RUP provides a structured approach to iterative development, dividing a project into fourphases: • Inception • Elaboration • Construction • Transition.

38. The RUP Phases’ Objectives • Inception Phase: • Understand the scope of the project, Functional and non-Functional requirement, Build the business case and get stakeholders buy-in. • Milestone: Lifecycle Objective • Elaboration Phase: • Mitigate key technical risks and develop an architecture baseline. • Milestone: Lifecycle Architecture • Construction Phase: • Build the first operational version of the product • Milestone: Initial Operational Capability • Transition Phase: • Build the final version of the product and deliver it to the customer • Milestone: Product Release

40. Static Structure of RUP – 9 Core Process Disciplines • Represents the logical grouping of the process elements- activities, disciplines, artifacts and roles encapsulated into nine core process disciplines: • Business modelling • Requirements • Analysis and Design • Implementation • Test • Deployment • Configuration and change management • Project management • Environment Discipline: The logical grouping of the process elements

41. Static Structure • Grouping of process elements into core disciplines • 4 process elements – activities, workflows, artifacts and roles Artifacts – Use case realisation Designer Use Case Analysis Use Case Design Roles Activities

42. The Concept of Role, Activity and Artifact are central for RUP

43. The Process Elements • Roles define how the individual does the work and the competence required to do the task • Activity is a task that is executed. Activities may be repeated several times during the lifecycle of the project (not necessarily by the same individual • Artifact is something tangible that the project produces (source code, model, document etc.) • Workflow is a sequence of activities and interaction of roles shown in a meaningful way • High-level workflows (disciplines) • Details (workflows within the disciplines)

44. RUP Process Architecture

45. Common Activities Elements for RUP Lifecycle • Starting a project, a phase or an iteration and reviews – Project Management • Design, coding, testing, and integration • Configuration management, production releases and change management • Measuring Progress

46. The RUP Phases The Inception Phase

48. Inception Key Objectives Think what the customer wants to achieve • Understand what to build – vision • Identify Key system functionality • Identify a candidate architecture • Understand costs schedule and risks • Decide on process and what tools to use Ideally one iteration should get you there

49. Example of a Vision document 1. Problem Statement 2. Proposed solution 3. Proposed Approach 4. Stakeholder & User Description 5. User Environment 6. Information System Perspective: The system, links, assumptions, €, Time, Quality 7. Features – Need, Priority, Feature 8. Planned Resources, Constraints (security, other)

50. Capture Requirements through Use Cases • A use casemodel describes a system's functional requirements in terms of actors and use cases. • An actor represents a type of user of the system, or another system that will interact with the system.