Figure 1:RUP
The Rational Unified Process (RUP) is a use-case-driven, architecturecentric,
iterative, and incremental software development process. Its goal
is to enable software development teams to produce high-quality software
that meets user needs,on time and within budget :).
The Rational Unified Process captures a number of modern software
engineering best practices in a tangible and practical form. These best
practices have been identified by the industry as major contributors to the
success of many software projects. They are:
- Develop iteratively
- Manage requirements
- Model visually
- Use component-based architectures
- Continuously verify quality
- Control changes
The iteration model graph shown in Figure 1 provides an overview of the
process, emphasizing its two dimensions: time along the horizontal axis
and structure along the vertical axis. This two-dimensionality distinguishes
the Rational Unified Process from many other process models, which use a
single dimension to illustrate development lifecycle phases.
The Rational Unified Process's structural dimension describes the software
development lifecycle in terms of roles, artifacts, activities, and workflows.
Roles describe a cohesive set of responsibilities that a person may
play in the development process. Examples of roles are Architect
and Design Review Board.
An artifact is a deliverable that is used, produced, or modified
during the development lifecycle. Examples of artifacts are Use
cases, Design model, and Risk list.
An activity is a unit of work, performed by one or more persons
playing a role, which produces or modifies one or more artifacts.
Examples of activities include Determine system boundaries and Fix
a defect.
A workflow is a collection of functionally related activities and the
roles and artifacts related to these activities. Within a workflow, we
can see which roles perform which activities with which artifacts.
The workflow also outlines the sequence of these activities, so that
we know when they must occur. Examples of workflows are
Business Modeling, Test, and Deployment.
Phases and Iterations
The dynamic dimension of the Rational Unified Process describes the
development lifecycle in temporal terms, using phases and iterations. The
four phases are Inception, Elaboration, Construction, and Transition.
Inception is the phase in which the scope of the project is
determined and the business case is defined.
Elaboration focuses on defining and validating a robust architecture
to eliminate technical risk and uncertainty.
Construction is the phase in which the product is built. Functionality
is incrementally added to the architectural baseline.
Transition is the phase in which the product is delivered to end
users.
Each phase ends with a project milestone; this includes a review and a
decision as to whether the project can safely proceed to the next phase. A
phase, therefore, is not a distinct step during development, as is analysis
or implementation. Rather, a phase describes 1) what the focus of
activities should be at a specific point during the product lifecycle, and 2)
the evaluation criteria for determining whether the phase has been
successfully accomplished or not.
Phases consist of one or more iterations. The number of iterations is
determined by how rapidly and accurately the milestone for that phase
can be reached. For example, if the problem is vague and the
development team has little domain experience, more iterations will be
necessary during Inception. This will ensure that the team can reach an
accurate description of the problem and that they will not encounter
domain-related surprises later. A project that involves a new, unproven
technology will have more iterations during Elaboration, to ensure that the
architecture incorporates the technology in a sufficient and stable manner.
Every iteration is a miniproject in its own right because it includes
activities from all the core workflows: Business Modeling; Requirements;
Analysis and Design; Implementation; Test; and Deployment. The phase
the iteration belongs to dictates how much emphasis needs to be placed
on each of these workflows. Having said this, it might be useful to refer
back to Figure 1.
That's it for first post, enjoy the work :)
development lifecycle in terms of roles, artifacts, activities, and workflows.
Roles describe a cohesive set of responsibilities that a person may
play in the development process. Examples of roles are Architect
and Design Review Board.
An artifact is a deliverable that is used, produced, or modified
during the development lifecycle. Examples of artifacts are Use
cases, Design model, and Risk list.
An activity is a unit of work, performed by one or more persons
playing a role, which produces or modifies one or more artifacts.
Examples of activities include Determine system boundaries and Fix
a defect.
A workflow is a collection of functionally related activities and the
roles and artifacts related to these activities. Within a workflow, we
can see which roles perform which activities with which artifacts.
The workflow also outlines the sequence of these activities, so that
we know when they must occur. Examples of workflows are
Business Modeling, Test, and Deployment.
Phases and Iterations
The dynamic dimension of the Rational Unified Process describes the
development lifecycle in temporal terms, using phases and iterations. The
four phases are Inception, Elaboration, Construction, and Transition.
Inception is the phase in which the scope of the project is
determined and the business case is defined.
Elaboration focuses on defining and validating a robust architecture
to eliminate technical risk and uncertainty.
Construction is the phase in which the product is built. Functionality
is incrementally added to the architectural baseline.
Transition is the phase in which the product is delivered to end
users.
Each phase ends with a project milestone; this includes a review and a
decision as to whether the project can safely proceed to the next phase. A
phase, therefore, is not a distinct step during development, as is analysis
or implementation. Rather, a phase describes 1) what the focus of
activities should be at a specific point during the product lifecycle, and 2)
the evaluation criteria for determining whether the phase has been
successfully accomplished or not.
Phases consist of one or more iterations. The number of iterations is
determined by how rapidly and accurately the milestone for that phase
can be reached. For example, if the problem is vague and the
development team has little domain experience, more iterations will be
necessary during Inception. This will ensure that the team can reach an
accurate description of the problem and that they will not encounter
domain-related surprises later. A project that involves a new, unproven
technology will have more iterations during Elaboration, to ensure that the
architecture incorporates the technology in a sufficient and stable manner.
Every iteration is a miniproject in its own right because it includes
activities from all the core workflows: Business Modeling; Requirements;
Analysis and Design; Implementation; Test; and Deployment. The phase
the iteration belongs to dictates how much emphasis needs to be placed
on each of these workflows. Having said this, it might be useful to refer
back to Figure 1.
That's it for first post, enjoy the work :)
No comments:
Post a Comment