Grady Booch, Ivar Jacobson and James Rumbaugh turned their efforts to the development process after creating UML as a single complete notation for describing object models.
They came up with the Rational Unified Process (RUP), which is a general framework that can be used to describe specific development processes.
Accordingly to The Unified Software Development Process every 'software life cycle' is a cycle over four phases in the following order:
The inception phase contains whatever workflows are necessary to get the stakeholders to agree
(the keyword there is agree, and not "have sure knowledge")
on the objectives, rough architecture, and rough schedule of the project.
If the stakeholders are extremely knowledgeable, then little analysis will be required.
If they need to be severely educated, then lots of analysis will be required.
The essence of RUP is iteration.
And the essence of iteration is that each iteration ends in a deliverable -- preferably one that executes.
Even in inception, you are going to want a few iterations that show growing functionality.
During inception you will gather a significant (a half? a third? it depends...) fraction of the use cases.
You will focus on those that seem to be central or key. The iterations will be implementing some of these.
During elaboration you will tighten up your architecture and your plan.
The nature of the iterations won't necessarily change much; but the longevity of the software produced will certainly increase.
Early iterations (usually in the inception phase) have a tendency to get thrown out.
During elaboration you will discover the rest of the use cases (or at least their first approximations) and will implement the minimal set.
During construction you will drive towards giving the customer the minimum system that they need.
The nature of the iterations will not change much,
but your focus will be on identifying the smallest possible deliverable that will still meet at least some of the customers needs.
During construction, the use cases will change a bit as the customer sees the growing system and feeds changes back to you.
During transition, you will drive towards fleshing out the functionality of the system, and incorporating the mounds of customer feedback that you are surely to get.
During transition the use cases are likely to undergo drastic changes as the customers actually use the system and realise that it is not exactly what they needed.
Again, the essence of Rational Unified Process ( RUP ) is iteration, and the essence of iteration is the production of executable deliverables.
You may also be producing UML diagrams, or some other form of model as well.
Such models take two forms.
One is a model of the architecture which is seeded during inception and established during elaboration.
This model is likely to be a permanent document.
The other kind of model is created at the beginning of each iteration, as a way to plan what the structure of the iteration will look like.
These models are most likely temporary documents.
You might find a few that are essential and should be retained; but many will be discardable.
The transition from phase to phase is gradual.
Management is not done by placing dates upon the phase boundaries.
Nor are there phase gate events that mark the transition from one to another.
Rather, management is done based upon iterations of the development.
The first iterations start in the inception phase.
The project plan is pretty straightforward.
It contains a list of proposed iterations (which all parties agree is likely to change).
Each proposed iteration has an estimate (which all parties agree are likely to change).
The proposed iterations are not assigned dates.
Rather decision points are identified.
|Analysis & Design|
|Configuration & Change Management|
The Rational Unified Process captures many of modern software development's best practices in a form suitable for a wide range of projects and organizations:
Most software teams still use a waterfall process for development projects, completing in strict sequence the phases of requirement analysis, design, implementation/integration, and test. This inefficient approach idles key team members for extended periods and defers testing until the end of the project lifecycle, when problems tend to be tough and expensive to resolve, and pose a serious threat to release deadlines. By contrast, RUP represents an iterative approach that is superior for a number of reasons:
Project managers often resist the iterative approach, seeing it as a kind of endless and uncontrolled hacking.
In the Rational Unified Process, the iterative approach is very controlled; the number, duration, and objectives of iterations are carefully planned,
and the tasks and responsibilities of participants are well defined.
In addition, objective measures of progress are captured. Some reworking takes place from one iteration to the next, but this, too, is carefully controlled.
Requirements management is a systematic approach to eliciting, organizing, communicating, and managing the changing requirements of a software-intensive system or application.
The benefits of effective requirements management are numerous:
It is often difficult to look at a traditional object-oriented system model and tell how the system does what it is supposed to do.
This difficulty stems from the lack of a consistent, visible thread through the system when it performs certain tasks.
In the Rational Unified Process, use cases provide that thread by defining the behavior performed by a system.
Use cases are not required in object orientation, nor are they a compulsory vehicle in the Rational Unified Process.
Where they are appropriate, however, they provide an important link between system requirements and other development artifacts, such as design and tests.
Other object-oriented methods provide use-case-like representation but use different names for it, such as scenarios or threads.
The Rational Unified Process is a use-case-driven approach, which means that the use cases defined for the system can serve as the foundation for the rest of the development process.
Use cases used for capturing requirements play a major role in several of the process workflows, especially design, test, user-interface design, and project management.
They are also critical to business modeling.
Use cases drive the Rational Unified Process throughout the entire lifecycle, but design activities center on architecture -- either system architecture or, for software-intensive systems, software architecture.
The main focus of early iterations is to produce and validate a software architecture.
In the initial development cycle, this takes the form of an executable architectural prototype that gradually evolves, through subsequent iterations, into the final system.
The Rational Unified Process provides a methodical, systematic way to design, develop, and validate an architecture.
It offers templates for describing an architecture based on the concept of multiple architectural views.
It provides for the capture of architectural style, design rules, and constraints.
The design process component contains specific activities aimed at identifying architectural constraints and architecturally significant elements, as well as guidelines on how to make architectural choices.
The management process shows how planning the early iterations takes into account the design of an architecture and the resolution of major technical risks.
A component can be defined as a nontrivial piece of software: a module, package, or subsystem that fulfills a clear function, has a clear boundary, and can be integrated into a well-defined architecture.
It is the physical realization of an abstraction in your design. Component-based development can proceed in several ways:
The first point above exploits the old concepts of modularity and encapsulation, bringing the concepts underlying object-oriented technology a step further.
The final two points shift software development from programming software (one line at a time) to composing software (by assembling components).
The Rational Unified Process supports component-based development in several ways.
Models are simplifications of reality; they help us to understand and shape both a problem and its solution, and to comprehend large, complex systems that we could not otherwise understand as a whole.
A large part of the Rational Unified Process is about developing and maintaining models of the system under development.
The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system.
It gives you a standard means of writing the system's blueprints, covering conceptual items such as business processes and system functions,
as well as concrete items such as classes written in a specific programming language, database schemas, and reusable software components.
While it provides the vocabulary to express various models, the UML does not tell you how to develop software.
That is why Rational developed the Rational Unified Process, a guide to the effective use of the UML for modeling.
It describes the models you need, why you need them, and how to construct them. RUP2000 uses UML version 1.4.
Often people ask why there is no worker in charge of quality in the Rational Unified Process.
The answer is that quality is not added to a product by a few people. Instead, quality is the responsibility of every member of the development organization.
In software development, our concern about quality is focused on two areas: product quality and process quality.
Particularly in an iterative development, many work products are often modified.
By allowing flexibility in the planning and execution of the development and by allowing the requirements to evolve, iterative development emphasizes the vital issues of keeping track of changes and ensuring that everything and everyone is in sync.
Focused closely on the needs of the development organization, change management is a systematic approach to managing changes in requirements, design, and implementation.
It also covers the important activities of keeping track of defects, misunderstandings, and project commitments as well as associating these activities with specific artifacts and releases.
Change management is tied to configuration management and measurements.