Rational Unified Process (RUP) Methodology
Printed From: One Stop Testing
Category: Quality Assurance @ OneStopTesting
Forum Name: Software Process Improvement
Forum Discription: It includes lots of process oriented things like requirements engineering, risk management, software peer reviews, project management, metrics, and process assessment etc.
URL: http://forum.onestoptesting.com/forum_posts.asp?TID=1427
Printed Date: 16May2024 at 1:07pm
Topic: Rational Unified Process (RUP) Methodology
Posted By: Leela
Subject: Rational Unified Process (RUP) Methodology
Date Posted: 04Jun2007 at 3:15am
RUP Methodology:
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.
By contrast, RUP represents an iterative approach that is superior for a number of reasons:
* 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.
* Integration is not one "big bang" at the end; instead, elements are integrated progressively.
* Risks are usually discovered or addressed during integration. With the iterative approach, you can mitigate risks earlier.
* 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.
* Iteration facilitates reuse; it is easier to identify common parts as they are partially designed or implemented than to recognize them during planning.
* 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.
* 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.
* The development process itself can be improved and refined along the way. The assessment at the end of an 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.
|
|