Adopting the rational unified process success with the rup pdf

Common Language. Examples of the New Language. Essential Concepts in RUP. RUP Is Iterative. The Spirit of RUP. Planning to Death. Detailing Too Much.

Skipping Problem Analysis. Letting End Dates of Iterations Slip. Testing Only at the End of the Project. Failing to Move the Product to Maintenance. Assessing Your Organization. Who Wants the Assessment and Why? Kicking Off the Assessment. How to Assess. Interviewing People. Reading Process Documentation. Comparing with Other Organizations. What to Assess. The Organization. Types of Products and Projects.

Supporting Tools. The Current Process. The Current Process Description. Compiling the Material. Identifying Problems. Drawing Conclusions. Formulating Recommendations. The Assessment Report. Presentation of the Findings. Motivating the RUP Adoption.

Reducing the Productivity Dip. Increasing the Improvement. Comparing the Initial Investment and the Dip with the Improvement. Other Aspects to Cover in a Business Case. Motivating the People.

Reactions to Change. Keep Moving between the Four Rooms of Change. Examples of Goals and Measurements. Planning the RUP Adoption. Creating the Implementation Team. Setting Adoption Goals. Identifying Risks and Opportunities. Why Use a Documented Formal Plan? Who Owns the Plan? Developing a Communication Plan. Identifying Software Development Projects to Support. Wide and Shallow or Narrow and Deep? How Much Time? Obtaining Support from the Organization.

The Implementation Team and Project. Documenting Your Project Implementation Plan. Stand By for Changes. Communicating with People in the Organization. Building Competence Among the Employees. Training Sessions. Performing Reviews.

Artifact Reviews. Milestone Reviews. Performing Mentoring. Training the Mentors. Assessing Your Project. What Are the Characteristics of the Project? Documenting the Project Assessment. Deciding upon and Documenting Your Process, Part 1.

Planning the Process Support. Documenting the Process Support. Deciding upon and Documenting Your Process, Part 2. Sharing Your Experiences. What Will Happen after the Project? Deciding upon Your Process.

Selecting Parts of RUP. Best Practices. Things to Not Exclude. Adding Process Information. Adding Guidelines and Examples. Adding Disciplines, Roles, Activities, and Artifacts. Adding a Project Management Method. Changing RUP. Pearson offers affordable and accessible purchase options to meet the needs of your students. Connect with us to learn more.

He joined Rational Software in November He has been a mentor and an instructor since then, helping several of Rational's customers in Sweden to implement RUP.

He now manages the training business at Rational in Scandinavia. Her special interest in visual modeling led her to join Rational Software in May She has gained solid real-life experiences using RUP through consulting and mentoring at a variety of organizations, helping them succeed with RUP implementations. We're sorry! We don't recognize your username or password. Please try again.

The work is protected by local and international copyright laws and is provided solely for the use of instructors in teaching their courses and assessing student learning. You have successfully signed out and will be required to sign back in should you need to download more resources. Out of print. The second vertical dimension represents the static aspect of the process described in terms of process components: activities, disciplines, artifacts, and roles.

It is general and comprehensive enough to be used "as is," i. But the adopting organization can also modify, adjust, and expand the Rational Unified Process to accommodate the specific needs, characteristics, constraints, and history of its organization, culture, and domain.

A process should not be followed blindly, generating useless work and producing artifacts that are of little added value.

Instead, the process must be made as lean as possible while still fulfilling its mission to help developers rapidly produce predictably high-quality software. The best practices of the adopting organization, along with its specific rules and procedures, should complement the process. The process elements that are likely to be modified, customized, added, or suppressed include artifacts, activities, workers, and workflows as well as guidelines and artifact templates.

The Rational Unified Process itself contains the roles, activities, artifacts, guidelines, and examples necessary for its modification and configuration by the adopting organization.

Starting in , the RUP contains several variants, or pre-packaged development cases for different types of software development organizations. 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. The truth is that requirements usually change.

With the iterative approach, you can mitigate risks earlier. As you unroll the early iterations, you test all process components, exercising many aspects of the project, such as tools, off-the-shelf software, people skills, and so on. 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.

Design reviews in early iterations allow architects to spot potential opportunities for reuse, and then develop and mature common code for these opportunities in subsequent iterations.

As the product moves beyond inception into elaboration, flaws are detected even in early iterations rather than during a massive testing phase at the end. Performance bottlenecks are discovered at a time when they can still be addressed, instead of creating panic on the eve of delivery. Testers start testing early, technical writers begin writing early, and so on.

In a non-iterative development, the same people would be waiting around to begin their work, making plan after plan but not making any concrete progress. What can a tester test when the product consists of only three feet of design documentation on a shelf?

In addition, training needs, or the need for additional people, are spotted early, during assessment reviews. 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.

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.

Manage Requirements Requirements management is a systematic approach to eliciting, organizing, communicating, and managing the changing requirements of a software-intensive system or application. The fundamental measure of quality is whether a system does what it is supposed to do.

With the Rational Unified Process, this can be more easily assessed because all stakeholders have a common understanding of what must be built and tested. Fixing errors in requirements is very expensive. With effective requirements management, you can decrease these errors early in the development, thereby cutting project costs and preventing delays.

Requirements management facilitates the involvement of users early in the process, helping to ensure that the application meets their needs. Well-managed requirements build a common understanding of the project needs and commitments among the stakeholders: users, customers, management, designers, and testers. 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.