Rational Unified

1

• Rational Unified
• Process
• By Siri.Akkina
• Borrowed from Philippe Kruchten, A Rational
  Development Process, CrossTalk, 9 (7), STSC, Hill
  AFB, UT, pp.11-16.

2
What is RUP?

• A Software engineering process based on best
  practices in modern software development
• A disciplined approach to assigning and managing
  tasks and responsibilities in a development
  organization
• Focused on high-quality software that meets the
  needs of its end users within a predictable
  schedule and budget
• A process framework that can be tailored to
  specific organization or project needs
• A process product developed and marketed by
  Rational Software with an interactive knowledge
  base integrated with tools.

3
Goal

• The main goal of RUP is to ensure the
  production of high quality software that meets
  the needs of its end users within a predictable
  schedule and budget.

4
Key Aspects of RUP

• Risk-driven process
• Risk management integrated into the development
  process
• Iterations are planned based on high priority
  risks
• Use-Case driven development
• Use cases express requirements on the systems
  functionality and model the business as context
  for the system
• Architecture Centric design activities
• Architecture is the primary artifact to
  conceptualize construct, manage, and evolve the
  system.

5
RUP Vs UML

• UML is a visual modeling language for software
  systems.
• RUP uses the UML visual notation and provides us
  with guidelines on how to use the UML
  effectively.
• RUP has been developed hand-in-hand with the
  UML.

6
Industry best Practices

• Develop software iteratively.
• Manage requirements.
• Use component-based architectures.
• Visually model software.
• Verify software quality.
• Control changes to software.

7
Develop Software Iteratively

• An iterative approach will help in understanding
  the problem through successive refinements.
• The Rational Unified Process supports an
  iterative approach to development.
• The iterative approach helps the development team
  to stay focus on the results and the time
  schedule.
• It makes it easier to accommodate tactical
  changes in requirements, features or schedule

8
Manage Requirements

• RUP describes
• how to manage and organize functionality along
  with the constraints of the project.
• how to capture and communicate the business
  requirements.
• RUP utilizes Use Cases and Scenarios as a means
  of capturing functional requirements as these
  increase the likelihood of the final system
  matching the user needs.

9
Use component-based architectures

• Design activities in RUP are based on
  architecture.
• System architecture or software intensive
  architecture is used
• RUP supports component-based architecture in many
  ways
• Iterative approach
• Structure can be articulated
• Subsystems and packages used in analysis and
  design
• Testing

10
Visually model software

• To capture the structure and behavior of
  architectures and components.
• To hide the details and write code using
  graphical building blocks.
• RUP uses UML to
• Act as a guide to the effective use of UML for
  modeling.
• Describe models needed and why they would be
  needed.

11
Verify Software Quality

• Quality is the responsibility of the whole
  development organisation
• Main concern about quality is focused on 2 main
  areas
• Product Quality - Quality of the product and
  its
• elements.
• Process Quality - the level at which an
  acceptable process was implemented and adhered to

12
Control changes to Software

• Rational Unified Process emphasizes
• Controlling changes to software.
• Coordination of activities and artifacts of
  developers/teams.
• Coordination of iterations and releases.

13
RUPLIFE CYCLE
14
Phases of RUP Lifecycle

• Inception
• Elaboration
• Construction
• Transition

15
Process Overview
16
Inception Phase

• Decide what to do, the business case, and the
  scope of the project.
• Make an initial project plan with rough
  estimations of time and resources required.
• Define risks that need to be handled in the
  elaboration phase. Delimit the project scope.
• Milestone Lifecycle Objective.
• Outcome
• 1. A vision document .
• 2. An initial use-case model .
• 3. An initial project glossary .
• 4. An initial risk assessment.

17
Evaluation criteria for Inception phase

• Stakeholder concurrence on scope definition and
  cost/schedule estimates.
• Requirements understanding as evidenced by the
  fidelity of the primary use cases.
• Credibility of the cost/schedule estimates,
  priorities, risks, and development process.
• Depth and breadth of any architectural prototype
  that was developed.
• Actual expenditures versus planned expenditures.

18
Elaboration Phase

• Analyze the problem domain.
• Define a technically feasible architecture.
• Mitigate the highest risks to the projects.
• Make a detailed project plan with prioritized
  activities.
• Milestone Lifestyle architecture.
• Outcome
• 1. A use-case model .
• 2. A Software Architecture Description.
• 3. An updated development case specifying
  the
• process to be used .

19
Evaluation Criteria of Elaboration Phase

• Is the vision of the product stable?
• Is the architecture stable?
• Does the executable demonstration show that the
  major risk elements have been addressed and
  credibly resolved?
• Is the plan for the construction phase
  sufficiently detailed and accurate? Is the actual
  resource expenditure versus planned expenditure
  acceptable?

20
Construction phase

• Developing application features.
• Integrating into the product.
• Testing the features.
• Milestone Initial Operational Capability.
• Outcome
• 1.The software product integrated on the
  
• adequate platforms.
• 2.The user manuals.
• 3.A description of the current release.

21
Evaluation criteria of Construction phase

• Is this product release stable and mature enough
  to be deployed in the user community?
• Are all stakeholders ready for the transition
  into the user community?
• Are the actual resource expenditures versus
  planned expenditures still acceptable?

22
Transition Phase

• Purpose transition the software product to the
  user community.
• Objective
• 1. Achieving user self-supportability .
• 2. Achieving final product baseline as
  rapidly and cost effectively as practical .
• focuses on the activities required to place the
  software into the hands of the users .
• includes several iterations .
• Milestone Product Release.

23
Evaluation criteria for Transition phase

• Is the user satisfied?
• Are the actual resources expenditures versus
  planned expenditures still acceptable?

24
Iterations in RUP phases

• An iteration is a development loop which ends up
  with the release of an executable product which
  is a subset of the final product under
  development.
• Advantages of an iteration system as opposed to a
  waterfall process include
• Risks are alleviated quicker
• Modifications are more controllable
• The project team can learn along the way
• The overall quality of the product is more
  superior

25
Application of RUP
26
Applications of RUP

• Industries where the RUP is used include
• Telecommunications
• Manufacturing
• Financial sectors
• Organisations use RUP in different ways
• Some use it for advice, templates, and guidance
  through the software development process.
• The fact that RUP is being used for both small
  and large scale projects represents how adaptable
  it is.

27
Application of RUP

• Example
• Developing an automation tool for SQA purposes
  in company XYZ using RUP.

28
Application of RUP

• Steps involved
• problem statement
• Vision
• Plan
• Risks
• Business case
• Architecture
• Commitment
• Beta and ship

29
Application of RUP

• Problem statement
• Company XYZ uses a workflow process engine to
  support the services they provide to their
  customers. New features are added to this
  workflow process as per market requirements. The
  SQA department needs to automate this workflow
  processing, to test and certify the new products
  that are to be released on a monthly basis.
• Vision
• A Workflow Automation Testing Tool (WATT) that
  automates the testing of the workflow process by
  the SQA dept. needs to be developed. This will
  eliminate the need of manually performing the
  black-box testing by the SQA dept. which can
  concentrate on more vital white-box testing

30
Application of RUP

• 3.PLAN

31
Inception

• Establish project's scope and boundary
  conditions.
• Determine the critical uses of the system.
• Exhibiting at least one candidate architecture
  against some of the primary scenarios.
• Estimating the overall cost and schedule for the
  entire project.
• Estimating potential risks.

32
Elaboration

• The vision is elaborated.
• The process, infrastructure, and development
  environment are elaborated.
• Processes, tools, and automation support are put
  into place.
• The architecture is elaborated and the components
  are selected. .

33
Advantages of Elaboration

• Helps clients in getting their feedback on the
  requirements.
• Helps in creating a more detailed plan and
  schedule.
• A starting point for building the real product .
• An opportunity to refresh the requirements for
  the architecture.

34
Construction

• Minimize development costs by optimizing
  resources and avoiding unnecessary scrap and
  rework.
• Achieving adequate quality as rapidly as
  practical.
• Achieving useful versions as rapidly as
  practical.

35
Transition

• Beta testing.
• Parallel operation with any existing legacy
  system.
• Conversions of operational databases.
• Training of users.
• Product rollout.

36
Application of RUP

• 4.Risks
• The SQA department does not have the necessary
  hardware required for the software.
• They dont have the network connections required
  to talk to their workflow engine(s)

37
Application of RUP

• 5.Business case
• SQA automation is one of the biting requirements
  in a company. So this type of product can be
  customized and sold to other companies like
  Company XYZ that require a workflow engine
  testing tool. Company XYZ also has a convincing
  reason to use this tool, to realize that the
  break-even in about 3 months.
• 6.Architecture
• The architecture that is going to be used to
  develop the product needs to be created in UML. A
  Java-servlet based front-end, browser, a database
  to log the results needs to be included.

38
Application of RUP

• 7.Commitment.
• Include security certificates and a user database
  to be included in the plan.
• Adding risks to include the compatibility of the
  certificates with the browser.
• 8.Beta and Ship
• After beta testing WATT, the users find some bugs
  that needed to be fixed, like the servlet was not
  showing proper time of execution of test case
  etc. Once fixed, the product is ready for use and
  is shipped to the client with all the proper
  documentation.

39
Conclusion

• RUP supports an iterative approach to development
  that addresses the highest risk items at every
  stage in the life cycle.
• Main Purpose of RUP is to deliver Projects in
  time with least amount of defects.
• RUP is a very flexible process with a lot of
  powerful tools.

40
References

• Philippe Kruchten, A Rational Development
  Process, CrossTalk, 9 (7), STSC, Hill AFB, UT,
  pp.11-16.
• http//www.processwave.net/Downloads/Environment/C
  MMIRUPESEPG200120.pdf
• http//www.macs.hw.ac.uk/ism/ug3/Part20120-20Pr
  esentations/6
• http//www.devdaily.com/java/java_oo/node21.shtml
• http//www.samspublishing.com/articles/article.asp
  ?p20474