1. Intro to Rational Unified Process Software Process Improvement Marion Lepmets 8.12.2003

2. Tarkvara-arendus raamistik

3. Rational Unified Process - RUP  Software development approach: –Iterative –Architecture-centric –Use-case-driven  Software engineering process: –Who is responsible for what –How things are done –When to do them  Process product: –Several out-of-the-box Process Configurations and Process Views that guide developers in sw development

4. RUP Approach  Essential Principles: –Attack major risks early and continuously –Ensure that you deliver value to your customer –Stay focused on executable software –Accommodate change early in the project –Baseline an executable architecture early on –Build your system with components –Work together as one team –Make quality a way of life, not an afterthought

5. RUP Approach RUP vs Waterfall  Waterfall development approach –Development phases are in a strict sequence –Leaves key team members idle for extended period of time –Leaves testing to the end of the project lifecycle  RUP approach –Iterative: a sequence of incremental steps or iterations –Each iteration includes most development disciplines –Each successive iteration builds on the work of previous iterations –Early iterations focus on requirements, later iterations on implementation and testing

6. RUP Approach Iterative approach  Iterative is superior to waterfall: –Accommodates changing requirements –Integration is not one ”big bang” at the end of the project –Risks are discovered and addressed during early integrations –Reuse is facilitated –Defects can be found and corrected over several iterations –Better use of project personnel –Team members learn along the way –The development is improved along the way  The number, duration and objectives of iterations need to be carefully planned  Tasks and responsibilities of participants need to be defined

7. RUP Process  A well-defined software engineering process  The process has two structures: –Dynamic structure: shows how the process, expressed in terms of cycles, phases, iterations, and milestones, unfolds over the lifecycle of a project. Represents the time dimension. –Static structure: shows how process elements – activities, disciplines, artifacts and roles – are logically grouped into core process disciplines (workflows).

8. RUP Process Dynamic Structure of Rational Unified Process  RUP divides a project into four phases: –Inception phase: Understand the scope of the project Build the business case Get stakeholder buy-in to move ahead –Elaboration phase: Mitigate major technical risks Create a baseline architecture Understand what it takes to build the system –Construction phase: Build the first operation version of the product –Transition phase: Build the final version of the product and deliver it to the customer  Each phase contains one or more iterations

9. RUP Process Static Structure of Rational Unified Process (1/2)  How process elements are logically grouped into core process disciplines  Process describes who is doing what, how and when  Four key modeling elements of the RUP: –The who – Roles –The how – Activities: Thinking steps – understanding the task Performing steps – creating or updating artifacts Reviewing steps – inspecting results against a criteria –The what – Artifacts –The when – Workflows

10. RUP Process Static Structure of Rational Unified Process (2/2)  RUP Disciplines: –Business modeling –Requirements management –Analysis and design –Implementation –Deployment –Test –Project management –Change management –Environment

11. RUP Product  RUP product constitutes a complete process framework composed of several integrated parts: –Best practices –Process delivery tools –Configuration tools –Process authoring tools –Community/Marketplace

12. The Spirit of RUP  Attack major risks early and continuously  Ensure that you deliver value to your customer  Stay focused on executable software  Accommodate change early in the project  Baseline an executable architecture early on  Build your system with components  Work together as one team  Make quality a way of life, not an afterthought

13. Attack Risks Early  ”Attack major risks early and continuously, or they will attack you!”, Tom Gilb  Unaddressed risks –Correct architecture –Accurate project estimation  Deal with risks at the beginning of each iteration  The right architecture – design, implement and test it in elaboration phase  Attack risks constantly

14. Deliver Value to Your Customer  Continuous feedback loops from customers  Use case driven approach –Focus on user’s perspective –Validate the design and implementation with respect of user requirements through sequence or collaboration diagrams –Solid basis for writing user manuals

15. Focus on Executable Software  Measure progress by measuring executable software  Artifacts other than the actual software are supporting artifacts –Minimise the number of artifacts produced to reduce overhead

16. Accommodate Change Early in the Project  Cost of change to business solution  Cost of change to the architecture  Cost of change to the design and implementation  Cost of change to the scope  Change management

17. Baseline Executable Architecture Early On  Primary objective of Elaboration phase - baseline a functioning architecture  Architecture comprises of software system’s most important building blocks and their interfaces  Architecture provides a sceleton structure of the system – 10-20% of final amount of code –Accurate assessments of resource and time estimates of the project –New members are easily introduced to the project –Ready-made solutions to common problems

18. Build Your System With Components  Functional decomposition architecture  Component-based architecture –Systems more resilient to changes in requirements, technology and data –Encapsulation –Reuse

19. Work Together as One Team  Teams are organised around architecture  Communication between team members  Reduce the amount if documentation to the extent possible

20. Make Quality a Way of Life  Iterative development allows to initiate testing much earlier than waterfall development  RUP requires to test capabilities while implementing – increase on quality  More testing  Quality in every development phase

21. Comparison of processes: RUP, agile methods and government standards  Low Ceremony: produces minimum supporting documentation and has little formalism in the working procedure  High Ceremony: comprehensive supporting documentation and traceability maintained among artifacts  Waterfall: linear approach with late integration and testing  Iterative: risk-driven development approach with early implementation of an architecture and early integration and testing

22. Agile Development: Low Ceremony, Iterative Approach  Flexibility and ability to adapt to evolving business environments  Respond to changes that occur during the process  Iterative development with strong focus on executable software  Minimising the ceremony surrounding software development  Increasingly complex projects require more ceremony than a small project

23. Process Assessment Frameworks: CMM, CMMI and ISO/IEC 15504  Companies in need of high ceremony approaches: –Complex systems –Distributed teams –Cost of maintenance is low –Cost of development is high –Time to market slower than for low-ceremony approaches

24. The RUP: Iterative Approach with an Adaptable Level of Ceremony  RUP is a customisable process framework  Users can produce a variety of processes or RUP configurations: –Light RUP configurations with low ceremony –Average RUP configurations with an average level of ceremony –Large, more formal RUP configurations with high ceremony

25. How Iterative Do You Want to Be?  For a highly iterative, risk-driven approach with continuous integration and testing you need: –Know-how –Good process support –Good tool support

26. How Much Ceremony Do You Want?  Project factors for lower ceremony: –Operating in a rapidly changing marketplace –Co-located teams –Small teams –Less technical complexity  Project factors for higher ceremony: –Large-scale development –Distributed development –Technically complex projects –Complex stakeholder relationships

27. SPI – Software Process Improvement  Software Process Assessment  Software Process Improvement  Benefits of SPI: –Increase in productivity (10-30% - judged by companies) –Lifecycle of production shortens –Traceability of results possible – transparency –Personnel skills and know-how growing –The management and roles in organisation clarified

28. Tarkvaraprotsesside parandamise etapid (Part 2)

29. Software Process Models and Standards  ISO/IEC 15504 – Information Technology: Process Assessment  CMM-SW – Capability Maturity Model for Software  CMMI – staged and continuous representation  ISO 9001 – Quality systems-Model for quality assurance in design, development, production, installation and servicing  BOOTSTRAP model and methodology  ISO/IEC 12207 – International Standard of Software Life-cycle Processes

30. Definitions  Process: a set of interrelated activities, which transform inputs into outputs  Practice: a software engineering or management activity that contributes to the creation of the output (work products) of a process or enhances the capability of a process  Process assessment: a disciplined evaluation of an organisation’s software processes against a model compatible with the reference model  Process improvement: action taken to change an organisation’s processes so that they meet the organisation’s business needs and achieve its business goals more effectively  Process capability: the ability of a process to achieve a required goal  Process performance: the extent to which the execution of a process achieves its purpose

31. Marion Lepmets Tallinna Tehnikaülikool Arvutitehnika instituut Raja 15, Tallinn 12617 Telefon: +372 6202 260 Email: marion.lepmets@ttu.ee www: http://www.pori.tut.fi/~marionhttp://www.pori.tut.fi/~marion