The Rational Unified Process attempts to capture many of modern software development's best practices in a form suitable for a wide range of projects and organizations. This process recognizes that the traditional waterfall approach can be inefficient because it idles key team members for extended periods of time. Many feel that the waterfall approach also introduces a lot of risk because it defers testing and integration until the end of the project lifecycle. Problems found at this stage are very expense to fix.
Inception phase
In this phase the business case which includes business context, success factors (expected revenue, market recognition, etc), and financial forecast is established. To complement the business case, a basic use case model, project plan, initial risk assessment and project description (the core project requirements, constraints and key features) are generated. After these are completed, the project is checked against the following criteria:
If the project does not pass this milestone, called the Lifecycle Objective Milestone, it can either be cancelled or it can repeat this phase after being redesigned to better meet the criteria.
Elaboration phase
The elaboration phase is where the project starts to take shape. In this phase the problem domain analysis is made and the architecture of the project gets its basic form.
This phase must pass the Lifecycle Architecture Milestone by meeting the following criteria:
• A use-case model in which the use-cases and the actors have been identified and most of the use-case descriptions are developed. The use-case model should be 80% complete.
• A description of the software architecture in a software system development process.
• A development plan for the overall project.
If the project cannot pass this milestone, there is still time for it to be canceled or redesigned. After leaving this phase, the project transitions into a high-risk operation where changes are much more difficult and detrimental when made.
Construction phase
In this phase the main focus goes to the development of components and other features of the system being designed. This is the phase when the bulk of the coding takes place. In larger projects, several construction iterations may be developed in an effort to divide the use cases into manageable segments that produce demonstrable prototypes.
This phase produces the first external release of the software. Its conclusion is marked by the Initial Operational Capability Milestone.
Transition phase
In the transition phase, the product has moved from the development organization to the end user. The activities of this phase include training of the end users and maintainers and beta testing of the system to validate it against the end users' expectations. The product is also checked against the quality level set in the Inception phase. If it does not meet this level, or the standards of the end users, the entire cycle in this phase begins again.
If all objectives are met, the Product Release Milestone is reached and the development cycle ends.
Deliverables in Each Phase of RUP:
Inception phase: Vision Document, Initial Use-case model (10-20%), a Project Plan, an Initial Risk Assessment, Initial Glossary.
Elaboration: UML diagrams, a Use Case Model (80%), Development Plan for overall project, revised Risk List.
Construction: System code – QA test cases/test scripts, a Test Plan, Description of the current release.
Transition: Product delivery, Project Documentation.
By contrast, RUP represents an iterative approach that is superior for a number of reasons:
o It lets you take into account changing requirements which despite the best efforts of all project managers are still a reality on just about every project.
o Integration is not one "big bang" at the end; instead, elements are integrated progressively.
o Risks are usually discovered or addressed during integration. With the iterative approach, you can mitigate risks earlier.
o Iterative development provides management with a means of making tactical changes to the product. It allows you to release a product early with reduced functionality to counter a move by a competitor, or to adopt another vendor for a given technology.
o Iteration facilitates reuse; it is easier to identify common parts as they are partially designed or implemented than to recognize them during planning.
o When you can correct errors over several iterations, the result is a more robust architecture. Performance bottlenecks are discovered at a time when they can still be addressed, instead of creating panic on the eve of delivery.
o Developers can learn along the way, and their various abilities and specialties are more fully employed during the entire lifecycle. Testers start testing early, technical writers begin writing early, and so on.
o The development process itself can be improved and refined along the way. The assessment at the end of iteration not only looks at the status of the project from a product or schedule perspective, but also analyzes what should be changed in the organization and in the process to make it perform better in the next iteration.
View blog reactions
Inception phase
In this phase the business case which includes business context, success factors (expected revenue, market recognition, etc), and financial forecast is established. To complement the business case, a basic use case model, project plan, initial risk assessment and project description (the core project requirements, constraints and key features) are generated. After these are completed, the project is checked against the following criteria:
If the project does not pass this milestone, called the Lifecycle Objective Milestone, it can either be cancelled or it can repeat this phase after being redesigned to better meet the criteria.
Elaboration phase
The elaboration phase is where the project starts to take shape. In this phase the problem domain analysis is made and the architecture of the project gets its basic form.
This phase must pass the Lifecycle Architecture Milestone by meeting the following criteria:
• A use-case model in which the use-cases and the actors have been identified and most of the use-case descriptions are developed. The use-case model should be 80% complete.
• A description of the software architecture in a software system development process.
• A development plan for the overall project.
If the project cannot pass this milestone, there is still time for it to be canceled or redesigned. After leaving this phase, the project transitions into a high-risk operation where changes are much more difficult and detrimental when made.
Construction phase
In this phase the main focus goes to the development of components and other features of the system being designed. This is the phase when the bulk of the coding takes place. In larger projects, several construction iterations may be developed in an effort to divide the use cases into manageable segments that produce demonstrable prototypes.
This phase produces the first external release of the software. Its conclusion is marked by the Initial Operational Capability Milestone.
Transition phase
In the transition phase, the product has moved from the development organization to the end user. The activities of this phase include training of the end users and maintainers and beta testing of the system to validate it against the end users' expectations. The product is also checked against the quality level set in the Inception phase. If it does not meet this level, or the standards of the end users, the entire cycle in this phase begins again.
If all objectives are met, the Product Release Milestone is reached and the development cycle ends.
Deliverables in Each Phase of RUP:
Inception phase: Vision Document, Initial Use-case model (10-20%), a Project Plan, an Initial Risk Assessment, Initial Glossary.
Elaboration: UML diagrams, a Use Case Model (80%), Development Plan for overall project, revised Risk List.
Construction: System code – QA test cases/test scripts, a Test Plan, Description of the current release.
Transition: Product delivery, Project Documentation.
By contrast, RUP represents an iterative approach that is superior for a number of reasons:
o It lets you take into account changing requirements which despite the best efforts of all project managers are still a reality on just about every project.
o Integration is not one "big bang" at the end; instead, elements are integrated progressively.
o Risks are usually discovered or addressed during integration. With the iterative approach, you can mitigate risks earlier.
o Iterative development provides management with a means of making tactical changes to the product. It allows you to release a product early with reduced functionality to counter a move by a competitor, or to adopt another vendor for a given technology.
o Iteration facilitates reuse; it is easier to identify common parts as they are partially designed or implemented than to recognize them during planning.
o When you can correct errors over several iterations, the result is a more robust architecture. Performance bottlenecks are discovered at a time when they can still be addressed, instead of creating panic on the eve of delivery.
o Developers can learn along the way, and their various abilities and specialties are more fully employed during the entire lifecycle. Testers start testing early, technical writers begin writing early, and so on.
o The development process itself can be improved and refined along the way. The assessment at the end of iteration not only looks at the status of the project from a product or schedule perspective, but also analyzes what should be changed in the organization and in the process to make it perform better in the next iteration.
No comments:
Post a Comment