1. Ivar Jacobson, Grady Booch, and James Rumbaugh The Unified Software Development Process Addison Wesley, 1999 1990: James Rumbaugh's OOMD 1992: Ivar Jacobson's Objectory 1993: Grady Booch's OOAD and diagrams 1995: Rational Software unites all three (“the three amigos”) Definition of unified process Definition of UML (Unified Modeling Language) Rational Rose toolset 2003: IBM buys Rational

2. Rambaugh et al. Prentice-Hall 1990 Use multiple views of the system Class diagram Statechart

3. The Unified Process Not really a process – Does not specify precisely what to do at each step More of a framework Needs to be adjusted to each project according to need Many refinements and extensions – Agile unified process – Enterprise unified process

4. Principles Iterative and incremental – Four phases divided into multiple iterations Use-case driven – Development is based on usage scenarios Architecture centric – Defining and refining the architecture is a major activity, baseline architecture a major milestone Risk focused – Activities in initial phases designed to reduce risk, Later phases fill details

5. Phases and Workflows

6. Similar to doing a waterfall in each iteration But each step in the waterfall continues across all iterations Not only the diagonal! Req’s analyze design code test

7. Phases

8. Inception Phase Define scope What will the system do for users / stakeholders Use cases Establish business case Cost vs. expected benefit Need ideas for architecture and construction plan to assess costs May discover that project is not worth doing Draw initial contract But maintain possibility of cancellation later

9. Elaboration Phase Fill in details of requirements and more use cases Identify and mitigate risks Use cases for requirements risks Prototypes for technical risks Use UML to create skeletal models Include only the important details Not high-level abstract models with no details Create baseline architecture Can change later Draw contract for whole system

10. Construction Phase Create a workplan Estimate time for each use case Decide on iteration time Assign use cases to iterations based on risk, priority, and work capacity Execute iterations Maintain rhythm – if schedule slips move a use case to a later iteration Test and integrate Refactor

11. Transition Phase First running system installed (beta test) Fix bugs based on user feedback Perform optimizations Do user training

12. Phase Milestones Inception: figure out what this is all about, and that it is feasible Outcome: green light for the project Elaboration: figure out how to actually do it Outcome: project architecture and contract Construction: now do it Outcome: initial running system installed, feedback from users

13. Phase Milestones Inception: figure out what this is all about, and that it is feasible Outcome: green light for the project Elaboration: figure out how to actually do it Outcome: project architecture and contract Construction: now do it Outcome: initial running system installed, feedback from users Similar to Royce and Boehm

14. Workflows

15. Workflows are Continuous Exist in all phases and iterations e.g. testing is done from the beginning – Even when there is no code to test – So test validity, completeness, and consistency of whatever artifact was produced – And plan relevant future code tests Relative weight may differ in different phases

16. Requirements Workflow Users don’t know what they want Hopefully they’ll know it when they see it Even when they know, they can’t specify it precisely and fully Shakespeare / Bedazzled Exercise specifications in courses Using formal methods need

17. Example There are multiple lights in the room. Every light is controlled by a switch. This just says:  L  S : S(L)

18. Example There are multiple lights in the room. Every light is controlled by a switch. This just says:  L  S : S(L) Could have two very different implementations:  L  S : S(L)   K≠L ¬S(K)  S :  L S(L)

19. Requirements Workflow Users don’t know what they need Hopefully they’ll know it when they see it Even when they know, they can’t specify it precisely and fully Exercise specifications in courses Developers come from a different background Don’t know what the users assume is self evident The requirements workflow is supposed to solve these problems

20. Requirements Workflow Understand the domain (create domain model) Two types of requirements: Functional requirements (use cases) Non-functional requirements (performance, …) Maintain list of ideas Things may change during the project Identify things that were missed New ideas New external requirements (change in tax law) Workflow extends throughout project

21. Use Cases Tool to foster discussion of requirements Focus on goals for using the system (what you want to achieve, not how you will do it) Identify roles / actors (not necessarily human) Identify interactions with system Expressed and recorded in use case diagrams Include scenario description Often also multiple failure scenarios Foreshadow agile user stories

22. Analysis Workflow Translate requirements from the language of the client to the language of the designer Add considerations of system internals Resource usage and conflicts Use more formal notation Organize the requirements for easier handling First cut at design that will realize required use cases

23. Design Workflow Shape the system and find a form that lives up to requirements Less abstract then analysis More detailed realization Define subsystems and interfaces between them Take constraints into account

24. Requirements / Analysis / Design Requirements are in the customer’s language Informal, intuitive Fill in background information and assumptions Analysis translates to the designer’s language Formalize Introduce implementation considerations Design re-shapes for implementation Detailed realization

25. Implementation Workflow Implement the classes in the design Integrate with results of previous iterations Map to platform

26. Test Workflow Unit tests for new code Integration tests for each build Regression tests: all previously passed tests System test at end of iterations Record tests and act on results (e.g. open defect reports)