Rational Unified Process

Rational Unified Process #

The foundation stone for RUP was laid by the three Amigos 1, who wanted to agree on a unified notation system. This system is known today as UML.

It has been confirmed several times that planning as in the waterfall model causes many problems. However, it has also been shown that no planning at all can also be very risky. Finding the right measure is complex. 2

The Rational Unified Process describes a partly structured, partly agile approach.

It includes:

  • 4 phases (Inception, Elaboration, Construction, Transition).
  • Always iterative
  • Disciplines, Activities
  • Roles
  • Work Products (Artefacts)

However, not everything should be used, but it should be seen as a kind of pharmacy, where only the where only the necessary drugs are used.

In UP, risk is often mentioned, but business values must also be included.

The four phases #

  • Inception: often given by management like time frame, cost ceiling, rough functional scope. There might be a requirements workshop in which risks and quality risks and quality requirements are defined. Here it is also whether the product will be made in-house or purchased. Project estimates are in the order of 1k, 100k to 1 million, i.e. very rough estimates.
  • Elaboration: The core architecture is implemented iteratively and risky problems are eliminated or problems are eliminated or secured. Here most of the requirements are discovered and stabilized. The result is a functional application with partial functionality.
  • Construction: From here on the direction is clear, there should be no more open risks. Implementation of the remaining features is in the foreground.
  • Transition: In waterfall-type projects, this is where data migration, system testing and data migration, system test and deployment. In an iterative approach this phase is minimal. For example, a feature freeze is made, and the code is deployed one last time

Iterations:

  • Each iteration should end in a runnable product. If work packages are not completely finished, they are moved to the next iteration. Ideally, the customer is already using the product after each iteration.
  • Customer feedback is important and one of the main features of agile.
  • Through constant feedback, ambiguities become known more quickly, which altogether leads to more joy for the customer as well as for the developers.

The following things should be looked at more closely before a full start is made.

  • Requirements: Use Cases, Domain model and non-functional requirements, in order to be able to grasp to be able to roughly capture the scope.
  • Architecture: The system and the software need an architecture that meets the requirements and the non-functional requirements.
  • Tool chain: Before starting, the entire tool chain should be set up, i.e. the IDE, version control, unit testing frameworks, continuous integration, metrics and Static Code Analysis tools.

  1. Grady Booch, Ivar Jacobson und James Rumbaugh ↩︎

  2. https://blog.seibert-media.net/blog/2010/05/12/agile-software-entwicklung-vs-wasserfall-modell-was-die-forschung-sagt/ ↩︎

Calendar September 21, 2021