Development Processes UML just is a modeling technique, yet for using it we need to know: »what do we model in an analysis model? »what do we model in system design / architecture model? »what do we model in a detailed design model? »how do these models relate to each other? refinement? pure extension? mapping? tracing? »when, in which order do we make these models? »which techniques/diagrams do we use to which extent? Modeling all  all on a high-level, some detailed design of complex issues plus good code-documentation  some high-level models  no documentation at all? Quality assurance, prototyping, …: how do they match into the process? WHAT - WHY - WHO - WHEN - HOW

Process of Fusion The Fusion process knows seven main activities: Requirements: use case model (actors, use cases), some high- level use case specifications, non-functional requirements Analysis: system class diagram containing basic classes; system interface with detailed use case specifications, system operations and events, pre- and post-conditions for system operations GUI Design Architecture: technical framework of system, main components of the system, component interfaces and interactions Database Design Design for each component: design class diagrams, object collaboration diagrams, visibility, representation of associations, initial object configuration, detailed class descriptions Implementation: code

Rational Unified Process A product goes through various cycles, each cycle having the following phases: - Inception: proof of concept, feasibility, goals - Elaboration: detailed requirements, usage scenarios, architecture, components, high-level interaction patterns - Construction: refinement of architecture, risk-driven implementation iterations - Transition: facilitating user acceptance,... Each phase is split up into various iterations. Each iteration has analysis, design and implementation activities. Guiding principles in the Rational Unified / Objectory process: - Use-case driven - Controlled and iterative - Architecture-centric - Risk-driven

Deliverables Inception Phase Project description »about the project in general and its goals, not requirements »“unless you write it out, you can’t be sure everyone agrees on the same project description” »one short paragraph to a few pages for really large projects (r) Risk analysis –list of market factors (r) –list of risk factors: list of things that can go wrong in contrast to use cases that model expected behavior –list of assumptions Use case diagram, description of actors and use cases »determine system boundaries and project scope »one sentence descriptions for use cases and actors Project proposal –to get go / no-go decision

Scoping the project Defines that part of the system that will be build in this project. Project scope is not given by system boundaries! –prioritize requirements –take into account »market forces »skill of developers »money and time frame »risks –start small, grow powerful (in follow up projects) Similar to defining iterations, yet project wide. Helps to avoid getting stuck in requirements and use case modeling Scoping itself is iterative and scope must be redefined!

Deliverables Elaboration Phase Detailed primary scenarios Secondary scenarios Activity diagrams User interface diagrams or examples »e.g. by using story boarding Architecture, maybe class diagrams Prototypes Project plan »break down into iterations »cost estimates for iterations Changes to boundaries, scope, list of risk factors, list of actors, description of use cases as defined in inception phase!

Planning Construction Iterations What is done in the first iterations? core functionality »either implemented (if high risk) or as stubs (if low risk) use cases that handle high risks »update list of risks to reflect current situation (complex issues that are crucial and for which no solution is yet known) »prioritize risks and decide which ones need to be solved first primary scenarios of use cases only »first goal is to solve high risk challenges, full functionality comes later on Each iteration produces an executable, testable, in later iterations even deployable release of the system. »stubs, simulators, additional test-components »tested by other people than its developers (d: What should be planned for last iteration?)

Use Cases in the Process Inception phase: Use cases are developed to help scope out the project. Elaboration phase: More detailed use cases are developed for: »risk analysis »baseline architecture »plan the construction phase Construction phase: Uses cases are starting points for: »design (where more detailed use cases may be developed) »developing test plans Use cases are part of requirements to be satisfied. Transition phase: Use cases can be used to develop user guides and training.

Use Case Driven Use cases bind all workflows together Use cases are the starting point for requirements capture Use cases are used to define iterations Use cases help to structure user documentation Use cases help to define and structure test cases ==> advantages of use case driven approach? ==> dangers of use case driven approach ? (d)

Function versus Form ==> process is use case driven (helps organizing work and models) but architecture centric (is focus of models and work) ==> architecture and design patterns are not part of notation but have to be designed into models Use cases specify function Architecture specifies form

Other Elements of a Process Definition Either predefined or project-specific Consider a process like Rational Unified just as a framework where you plug in and derive from it the project specific, adapted and detailed process definition Also project definition is created incrementally and refined iteratively (inclusive project plan reviews) during the project! Other elements? (d)