As I just said, today we're going to talk about the
Rational Unified Process. And you know that I like to provide
the historical perspective of the topics that we cover in class
and this lesson is no exception. So let's see a little bit
of history of RUP. To do that we have to go
back to 1997 when Rational defined six best practices for modern software
engineering. So let's look at what these practices were. The first
practice involved developing in an iterative way with risk as the primary
iteration driver. The second practice had to do
with managing requirements, including updating them and keeping
traceability information between requirements and other software
artifacts. Practice number three was to employ a
component-based architecture. What that means is to have
a high level design that focuses on cooperating
components that are nevertheless very cohesive and highly
decoupled. Modeling software visually is another key aspect
of the rational unified process. And the key concept
here is to use visual diagrams, and in particular UML
visual diagrams, in a very extensive way so as
to make artifacts easier to understand and agree upon among
stakeholders. And the fact that the process is defined
in an iterative way, allows for performing quality assurance activities
in a continuous way. So it allows for continuously
verifying quality throughout the development
process. Finally, change management and
control were also at the center of the rational
approach These six practices, that I just mentioned were
the starting point for the development of the Rational
Unified Process, which is what we're going to discuss next.