Rational Unified Process

from Wikipedia, the free encyclopedia

The Rational Unified Process ( RUP ) is a commercial product from Rational Software , which has been part of the IBM group since 2003 . It contains both a process model for software development and the associated software development programs . IBM is further developing the RUP and the associated software. The 9th version is the current version since 2006. The RUP uses the Unified Modeling Language  (UML) as the notation language. The original form of the RUP was first presented by Philippe Kruchten in 1998.

History of origin

History of object-oriented methods and notations

The foundation stone for RUP was laid when the well-known programmers Grady Booch , Ivar Jacobson and James Rumbaugh ("The Three Amigos") of the company Rational Inc. agreed on a uniform notation system. As a result of these efforts, the UML was born . The standardization and further development of the language was handed over to the Object Management Group (OMG). With a common language, a common object-oriented method could now be developed. The unified process is a metamodel for process models for software development . The Unified Process was developed and published in parallel with the Unified Modeling Language by Ivar Jacobson, Grady Booch and James Rumbaugh.

The Unified Process is based on the following principles:

  • use cases
  • Architecture at the center of planning
  • incremental and iterative approach

A concrete implementation of the Unified Process is the Rational Unified Process. The first version of the RUP from 1999 brought together the suggestions of these three founders for a uniform modeling method.

Static aspects

The work steps are divided into nine disciplines for each iteration:

Core work steps (engineering disciplines) :

  • Business plan / business model: task, goal and strategy of the business as well as a derived business process modeling (business modeling)
  • Specification of the application model: application functions for the implementation of workflows / processes or formalized business processes (requirements)
  • Specification of the software architecture: Rough architecture: subsystems for surface, functionality and data management as well as user and basic machines; Fine architecture: object classes, software components and relationships (analysis & design)
  • Realization of software layers: (computer) programs (implementation)
  • Execution of program, module and integration tests (tests)
  • Acceptance test, installation, training and instruction (deployment)

Supporting steps (supporting disciplines) :

  • Configuration and change management
  • Project Management (Project Management)
  • Development environment, tool support and quality assurance measures (Environment & Quality Management)

Dynamic aspects

RUP aspects. The dynamic aspects are shown horizontally, the static aspects vertically.

Orthogonally , there are four phases in the RUP in which each of the above-mentioned work steps is applied more or less intensively. Each of these phases is divided into one or more iterations, resulting in a milestone ( English milestone ).

Inception

This first conception phase is used to formulate a vision, a clear goal and the creation of a rudimentary use case model that describes the essential functionality and a tentative / provisional architecture. In addition, the most important risks are identified and the elaboration phase is planned. It results in the Lifecycle Objective Milestone .

Elaboration

In this phase, the architecture prototype and a detailed description for around 80 percent of the use cases are developed. This is where the planning of the construction phase takes place. The result of this design phase is the Lifecycle Architecture Milestone .

Construction

After the architecture has been worked out, this phase focuses on developing and testing the product. This is where the first executable version of the software is created and ends with the Initial Operational Capability Milestone .

Transition

Handover phase and delivery of the software to the customer. The process ends with the product release milestone .

Best practices

The Rational Unified Process draws on procedures and empirical values ​​that have proven themselves in practice. These are formulated in the following six best practices:

  • Iterative software development , which, in contrast to linear process models (such as the waterfall model), can still take changing requirements into account at a later point in time.
  • Quality management accompanying the project with the aim of early error detection.
  • Component-based architecture : Components are developed as well as tested in isolation and thus contribute to the reusability of the product and an increase in productivity and quality.
  • Visual modeling for a better understanding of the problem. Mostly using the standardized modeling language UML. This enables parallel development in different departments.
  • Controlled change management : to manage changes and make old statuses reproducible.
  • Requirements management : Requirements are the basis of the system. Approach to identify, organize and implement changes. Serves for better control, improved quality and customer satisfaction.

See also

literature

  • Jim Arlow, Ila Neustadt: UML 2 and the Unified Process. Practical object-oriented analysis and design. 2nd edition. Addison-Wesley Professional, Upper Saddle River NJ et al. a. 2005, ISBN 0-321-32127-8 .
  • Andreas Essigkrug, Thomas Mey: Rational Unified Process compact. Spectrum Academic Publishing House, Heidelberg u. a. 2003, ISBN 3-8274-1440-7 .
  • Peter Hruschka, Chris Rupp , Gernot Starke: Agility compact. Tips for successful system development. Spectrum Academic Publishing House, Heidelberg u. a. 2004, ISBN 3-8274-1483-0 .
  • Ivar Jacobson , Grady Booch , James Rumbaugh : The unified software development process. UML. Addison-Wesley, Reading MA et al. a. 1999, ISBN 0-201-57169-2 .
  • Per Kroll, Philippe Kruchten : The Rational Unified Process Made Easy. A Practitioner's Guide to the RUP. Addison-Wesley, Boston MA a. a. 2003, ISBN 0-321-16609-4 .
  • Philippe Kruchten: The rational unified process. (An introduction). Addison-Wesley, Reading MA et al. a. 1998, ISBN 0-201-60459-0 .
  • Markus Reinhold: Rational Unified Process 2000 versus V-Modell'97: A Comparison of the two most common used Process Models in Germany. In: Ralf Kneuper, Manuela Wiemers (Hrsg.): Leichte procedural models . Workshop of Section 5.11 of the Society for Informatics eV (GI) 8. Shaker, Aachen 2001, ISBN 3-8265-8577-1 , p. 111ff.
  • Gerhard Versteegen: Project management with the Rational Unified Process. Springer, Berlin a. a. 2000, ISBN 3-540-66755-5 .
  • Wolfgang Zuser, Thomas Grechenig, Monika Köhle: Software engineering with UML and the Unified Process. 2nd revised edition. Pearson studies, Munich a. a. 2004, ISBN 3-8273-7090-6 .

Web links

Individual evidence

  1. Andreas Essigkrug, Thomas Mey: Rational Unified Process compact , p. 15
  2. Andreas Essigkrug, Thomas Mey: Rational Unified Process compact , p. 3