RUP

1
RUP
2
Components of RUP

• Artifacts - what - Vision, Iteration Plan, Use
  case model (UML), Software arch doc (UML), Design
  model (UML), Component, Integration build plan
• Workers - who - Project mgr, Architect, System
  analyst, Use case specifier, Designer,
  Implementor, Tester, CM Manager
• Activities - what - Implement classes, Review
  Code, Perform unit test, Fix a defect, Plan
  subsystem integration, Integrate subsystem
• Workflow - when Project mgmt, Business
  modeling, Requirements, Analysis and design,
  Implementation, Test, Configuration and change
  mgmt, Deployment, Environment

3
Worker

• A worker defines the behavior and
  responsibilities of an individual, or a group of
  individuals working together as a team. You could
  regard a worker as a "hat" an individual can wear
  in the project. One individual may wear many
  different hats. This is an important distinction
  because it is natural to think of a worker as the
  individual or team itself, but in the Unified
  Process the worker is more the role defining how
  the individuals should carry out the work. The
  responsibilities we assign to a worker includes
  both to perform a certain set of activities as
  well as being owner of a set of artifacts.

4
Activity

• An activity of a specific worker is a unit of
  work that an individual in that role may be asked
  to perform. The activity has a clear purpose,
  usually expressed in terms of creating or
  updating some artifacts, such as a model, a
  class, a plan. Every activity is assigned to a
  specific worker. The granularity of an activity
  is generally a few hours to a few days, it
  usually involves one worker, and affects one or
  only a small number of artifacts. An activity
  should be usable as an element of planning and
  progress if it is too small, it will be
  neglected, and if it is too large, progress would
  have to be expressed in terms of an activitys
  parts.

5
Examples

• Plan an iteration, for the Worker Project
  Manager
• Find use cases and actors, for the Worker System
  Analyst
• Review the design, for the Worker Design
  Reviewer
• Execute performance test, for the Worker
  Performance Tester

6
Artifact

• An artifact is a piece of information that is
  produced, modified, or used by a process.
  Artifacts are the tangible products of the
  project, the things the project produces or uses
  while working towards the final product.
  Artifacts are used as input by workers to perform
  an activity, and are the result or output of such
  activities. In object-oriented design terms, as
  activities are operations on an active object
  (the worker), artifacts are the parameters of
  these activities.

7
Artifact(2)

• Artifacts may take various shapes or forms
• A model, such as the Use-Case Model or the Design
  Model
• A model element, i.e. an element within a model,
  such as a class, a use case or a subsystem
• A document, such as Business Case or Software
  Architecture Document
• Source code
• Executables

8
Workflow

• A workflow is a sequence of activities that
  produces a result of observable value.
• In UML terms, a workflow can be expressed as a
  sequence diagram, a collaboration diagram, or an
  activity diagram.

9
Best Practices

• Develop s/w iteratively
• Manage requirements
• Use component-based architectures
• Visually model software
• Continuously verify software quality
• Control changes to s/w

10
In Practice

• Sustained development of quality software
• Delivered on-time and on-budget
• Requires more than heroic individuals
• Cohesive teamwork common understanding of
  development tasks
• Ensures implementation is predictable and
  repeatable

11
In Practice(2)

• Attack major risks early and continuously
• Risk Mitigation
• Use working software as primary measure of
  progress
• Completed plans, requirements, and design are
  good working software is better
• Produce only artifacts you need
• When in doubt, dont produce it
• Accommodate changes in requirements and design
• Allow for changes, but manage them

12
In Practice(3)

• Ensure that you deliver value to your customer
• Design, implementation, and testing address
  customer needs
• Documenting customer needs is good, implementing
  them is better
• Baseline an executable architecture early
• First build the skeleton structure, then fill in
  the holes
• Work closely as one team
• Affects organization, tooling and team values
• Quality is a way of life, not an afterthought
• Quality from the beginning, quality by design

13
Phases
14
4 Phases and Milestones

• 1. Inception
• lifecycle objectives milestone
• 2. Elaboration
• lifecycle architecture milestone
• 3. Construction
• initial operational capability milestone
• 4. Transition
• product release milestone

15
Inception Phase

• Overriding goal is obtaining buy-in from all
  interested parties
• Initial requirements capture
• Cost Benefit Analysis
• Initial Risk Analysis
• Project scope definition
• Defining a candidate architecture
• Development of a disposable prototype
• Initial Use Case Model (10 - 20 complete)
• First pass at a Domain Model

16
Lifecycle Objective Milestone

• The Inception phase ends at the Life Cycle
  Objective Milestone. This milestone is crossed
  when the project team and stakeholders agree
  upon
• what the business need is, and what set of
  behaviors will satisfy that need.
• a preliminary schedule of iterations.
• a preliminary architecture
• Though it may be common to wait till the end of
  an iteration to make these agreements, this is
  not strictly necessary. Once the agreements can
  be made, the project enters the Elaboration
  phase.

17
Elaboration Phase

• Requirements Analysis and Capture
• Use Case Analysis
• Use Case (80 written and reviewed by end of
  phase)
• Use Case Model (80 done)
• Scenarios
• Sequence and Collaboration Diagrams
• Class, Activity, Component, State Diagrams
• Glossary (so users and developers can speak
  common vocabulary)
• Domain Model
• to understand the problem the systems
  requirements as they exist within the context of
  the problem domain
• Risk Assessment Plan revised
• Architecture Document

18
Life Cycle Architecture Milestone

• This milestone marks the end of the Elaboration
  phase, and the beginning of the Construction
  phase. It is delineated by the ability of the
  project team and stakeholders to agree that
• the use cases describe the detailed behavior that
  will address the business need,
• the chosen architecture will scale to support the
  full software development,
• the major risks have been addressed,
• the project plan is achievable, and will achieve
  the project objectives.

19
Construction Phase

• Focus is on implementation of the design
• cumulative increase in functionality
• greater depth of implementation (stubs fleshed
  out)
• greater stability begins to appear
• implement all details, not only those of central
  architectural value
• analysis continues, but design and coding
  predominate

20
Initial Operational Capability Milestone

• Often called a beta release, this milestone marks
  the end of the Construction phase and the
  beginning of the Transition phase. This is not
  the end of the project, nor even close. Indeed,
  the project may be much closer to its beginning
  than its end. This milestone is crossed when the
  project team and stakeholders agree that
• the product is stable enough to be used,
• the product provides at least some useful value,
• all parties are otherwise ready to begin the
  transition.

21
Transition Phase

• beta testing to validate the new system against
  user expectations
• parallel operation with a legacy system that it
  is replacing
• conversion of operational databases
• training of users and maintainers
• roll-out the product to the marketing,
  distribution, and sales teams
• achieving user self-supportability
• achieving stakeholder concurrence that deployment
  baselines are complete and consistent with the
  evaluation criteria of the vision
• achieving final product baseline as rapidly and
  cost effectively as practical

22
Product Release Milestone

• This milestone marks the end of the Transition
  phase, and possibly the beginning of the next
  Inception phase. It is crossed when the project
  team and the stakeholders agree that
• The objectives set during the Inception phase
  (and modified throughout the other phases) have
  been met.
• The user is satisfied (which may or may not be
  synonymous with point 1)

23
Software Lifecycle

• Four sequential phases,
• Each concluded by a major milestone
• At each phase-end an assessment is performed to
  determine whether the objectives of the phase
  have been met.
• A satisfactory assessment allows the project to
  move to the next phase.

24
Effort and Scheduling
25
Workflows

• Business Modeling
• Requirements
• Analysis Design
• Implementation
• Test
• Deployment
• Configuration Change Management
• Project Management
• Environment

26
Business Modeling

• Purpose
• Understand the structure and the dynamics of the
  organization in the target organization
• Understand current problems in the target
  organization and identify improvement potentials
• Ensure that customers, end users, and developers
  have a common understanding of the target
  organization
• Derive the system requirements needed to support
  the target organization.

27
Requirements

• Purpose
• To establish agreement with the customers and
  other stakeholders on what the system should do
• To provide system developers with a better
  understanding of the system requirements
• To define the boundaries of the system
• To provide a basis for estimating cost and time
  to develop the system
• To define a user-interface for the system,
  focusing on the needs and goals of the users

28
Analysis Design

• Purpose
• To turn the requirements into a design of the
  system-to-be
• To develop a comprehensive architecture for the
  system
• To adapt the design for performance

29
Implementation

• Purpose
• To define the organization of the code, in terms
  of subsystems organized in layers
• To implement classes and objects in terms of
  components (source files, executables, and
  others),
• To test the developed components as units
• To integrate the results produced by individual
  developers (or teams), into an executable system

30
Test

• To verify the interaction between objects.
• To verify the proper integration of all
  components of the software.
• To verify that all requirements have been
  correctly implemented.
• To identify and ensure defects are addressed
  prior to the deployment of the software.

31
Deployment

• Purpose
• The custom install
• The "shrink wrap" product offering
• Access to software over the internet

32
CM

• Purpose
• Identifying configuration items
• Restricting changes to those items
• Auditing changes made to those items
• Defining and managing configurations of those
  items
• Ensure completeness and correctness of the
  configured product
• Provide an audit trail on why, when and by whom
  any artifact was changed

33
Project Management

• Purpose
• To provide a framework for managing
  software-intensive projects.
• To provide practical guidelines for planning,
  staffing, executing, and monitoring projects.
• To provide a framework for managing risk
• Risk management
• Planning an iterative project, through the
  lifecycle and for a particular iteration
• Monitoring progress of an iterative project,
  metrics

34
Environment

• Purpose
• To configure the process for a project
• To provide the software development organization
  with the software development processes and tools

35
RUP Goals

• Optimize the collaboration of your complete team
• RUP helps you unify your team
• Deliver the right product on time and on budget
• RUP helps you focus on delivering working
  software
• Effectively be able to adopt new techniques and
  tools on your projects
• RUP helps you leverage new tools and technologies

36
Iterative Development Process...

• Recognizes the reality of changing requirements
• Caspers Joness research on 8000 projects
• 40 of final requirements arrived after the
  analysis phase, after development had already
  begun
• Promotes early risk mitigation, by breaking down
  the system into mini-projects and focusing on the
  riskier elements first
• Allows you to plan a little, design a little,
  and code a little
• Encourages all participants, including testers,
  integrators, and technical writers to be involved
  earlier on
• Allows the process itself to modulate with each
  iteration, allowing you to correct errors sooner
  and put into practice lessons learned in the
  prior iteration
• Focuses on component architectures, not final big
  bang deployments

37
Iterative Development Process...

• Allows for software to evolve, not be produced in
  one huge effort
• Allows software to improve, by giving enough time
  to the evolutionary process itself
• Forces attention on stability, for only a stable
  foundation can support multiple additions
• Allows the system (a small subset of it) to
  actually run much sooner than with other
  processes
• Allows interim progress to continue through the
  stubbing of functionality
• Allows for the management of risk, by exposing
  problems earlier on in the development process

38
Goals Features of Each Iteration

• The primary goal of each iteration is to slowly
  chip away at the risk facing the project, namely
• performance risks
• integration risks (different vendors, tools,
  etc.)
• conceptual risks (ferret out analysis and design
  flaws)
• Perform a miniwaterfall project that ends with
  a delivery of something tangible in code,
  available for scrutiny by the interested parties,
  which produces validation or correctives
• Each iteration is risk-driven
• The result of a single iteration is an
  increment--an incremental improvement of the
  system, yielding an evolutionary approach

39
41 View Model of Arch.

• By Philippe Kruchten Kruchten95
• Rational Unified Process.

40
41 View Model of Arch.
Implementation/
Deployment/
41
Logical View

• Abstract.
• Main focus functional requirements.
• Components
• classes, modules, groups of ,
• Connectors (interrelationships)
• Usage.
• Containment, aggregation.
• Inheritance, instantiation.

42
Logical View - illustration
43
Process View

• Allocation of
• Logical view components to processes/tasks.
• Components processes, tasks,
• group of tasks single exec. unit.
• Control start, shutdown, recover, restore
• Primary / secondary (redundancy)
• Interrelationships
• Communication
• Synchronization mechanisms

44
Process View illustration
45
Process View illustration
46
Implementation (Development)View

• Actual S/W organization.
• Allocate logical components to impl. comp.
• Components
• Libraries, subsystems, exec., object files,
• Most common top-level arch. style layers
• Connectors containment, dependencies,
• Reuse
• Off-the-shelf.
• To-the-shelf sharing with other projects.

47
Implementation View illustration
48
Deployment (Physical) View

• Allocation of process view elements to H/W
  (processing nodes).
• Components processors, processing nodes,
• Network topology.
• Usually several topos are supported.
• S/W should be relatively independent of topo.
• Examples
• Network elt Process mapping into application
  cards.
• Network Mgmt one or more NOCs.

49
Deployment View - illustration
50
Deployment View - illustration
51
Use Case View

• Architecturally significant use cases.Use cases
  highlighting main
• Architectural decisions / choices

52
41 View Model of Arch.
53
Relationships between Views

• All the views are not independent and elements of
  one view are connected to elements in other
  views.
• From Logical to Process view
• From Logical to Development view
• From Process to Physical view

54
Using Views

• Every software architecture doesnt need 41
• views.
• Views that are not useful can be omitted.
  Example physical view can be omitted when only
  one processor exists or process view can be
  omitted when only one process or program exists.
• For very small systems, logical view and
  development view could be very similar.
• Scenarios useful in all circumstances.

55
Summary
56
In its simplest form, RUP consists of some
fundamental workflows

• Business Engineering. Understanding the needs of
  the business.
• Requirements. Translating business need into the
  behaviors of an automated system.
• Analysis and Design. Translating requirements
  into a software architecture.
• Implementation. Creating software that fits
  within the architecture and has the required
  behaviors.
• Test. Ensuring that the required behaviors are
  correct, and that all required behaviors are
  present.
• Configuration and change management. Keeping
  track of all the different versions of all the
  work products.
• Project Management. Managing schedules and
  resources.
• Environment. Setting up and maintaining the
  development environment.
• Deployment. Everything needed to roll out the
  project.