The Rational Unified Process

The Rational Unified Process is a software engineering process. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end users within a predictable schedule and budget.

The Rational Unified Process is a process product. It is developed and maintained by Rational Software and integrated with its suite of software development tools. It is available from Rational Software on CD-ROM or through the Internet.

The Rational Unified Process is also a process framework that can be adapted and extended to suit the needs of an adopting organization.

The Rational Unified Process captures the following best practices in modern software development in a form that is suitable for a wide range of projects and organizations:

1. Develop software iteratively.
2. Manage requirements.
3. Use component-based architectures.
4. Visually model software.
5. Continuously verify software quality.
6. Control changes to software.

Posted in UP

The Four Phases of UP

The following are the four phases of the Unified Process:

1. Inception - approximate vision, business case, scope, vague estimates.
2. Elaboration - refined vision, iterative implementation of the core architecture, resolution of high risks, identification of most requirements and scope, more realistic estimates.
3. Construction - iterative implementation of the remaining lower risk and easier elements, and preparation for deployment.
4. Transition - beta tests, deployment.

Posted in UP

UP Practices

The following are the Practices of the Unified Process:

1. short timeboxed iterative, evolutionary, and adaptive development
2. tackle high-risk and high-value issues in early iterations
3. continuously engage users for evaluation, feedback, and requirements
4. build a cohesive, core architecture in early iterations
5. continuously verify quality; test early, often, and realistically
6. apply use cases where appropriate
7. do some visual modeling (with the UML)
8. carefully manage requirements
9. practice change request and configuration management

Posted in UP

Agile UP

The UP was not meant by its creators to be heavy or un-agile, although its large optional set of activities and artifacts have understandably led some to that impression. Rather, it was meant to be adopted and applied in the spirit of adaptability and lightness, an agile UP.

Some examples of how this applies:

• Prefer a small set of UP activities and artifacts. Some projects will benefit more than others, but, in general, keep it simple. Remember that all UP artifacts are optional, and avoid creating them unless they add value. Focus on early programming, not early documenting.
• Since the UP is iterative and evolutionary, requirements and designs are not completed before implementation. They adaptively emerge through a series of iterations, based on feedback.
• Apply the UML with agile modeling practices.
• There isn’t a detailed plan for the entire project. There is a high-level plan (called the Phase Plan) that estimates the project end date and other major milestones, but it does not detail the fine-grained steps to those milestones. A detailed plan (called the Iteration Plan) only plans with greater detail one iteration in advance. Detailed planning is done adaptively from iteration to iteration.

Posted in UP

The Agile Principles

The following are the Agile Principles:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development.
9. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
10. Continuous attention to technical excellence and good design enhances agility.
11. Simplicity, the art of maximizing the amount of work not done is essential.
12. The best architectures, requirements, and designs emerge from self-organizing teams.
13. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Posted in UP

The Agile Manifesto

The following are the Agile Manifesto

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

Posted in UP

Agile Methods and Attitudes

Agile development methods usually apply timeboxed iterative and evolutionary development, employ adaptive planning, promote incremental delivery, and include other values and practices that encourage agilityrapid and flexible response to change.

It is not possible to exactly define agile methods, as specific practices vary widely. However, short timeboxed iterations with evolutionary refinement of plans, requirements, and design is a basic practice the methods share. In addition, they promote practices and principles that reflect an agile sensibility of simplicity, lightness, communication, self-organizing teams, and more.

Example practices from the Scrum agile method include a common project workroom and self-organizing teams that coordinate through a daily stand-up meeting with four special questions each member answers. Example practices from the Extreme Programming (XP) method include programming in pairs and test-driven development.

Any iterative method, including the UP, can be applied in an agile spirit. And the UP itself is flexible, encouraging a “whatever works” attitude to include practices from Scrum, XP, and other methods.

Posted in UP

Risk-Driven and Client-Driven Iterative Planning

The UP encourage a combination of risk-driven and client-driven iterative planning. This means that the goals of the early iterations are chosen to

• identify and drive down the highest risks, and
• build visible features that the client cares most about.

Risk-driven iterative development includes more specifically the practice of architecture-centric iterative development, meaning that early iterations focus on building, testing, and stabilizing the core architecture. Why? Because not having a solid architecture is a common high risk.

Posted in UP

Iterative and Evolutionary Development, a UP Practice

A key practice in both the UP and most other modern methods is iterative development. In this lifecycle approach, development is organized into a series of short, fixed-length (for example, three-week) mini-projects called iterations; the outcome of each is a tested, integrated, and executable partial system. Each iteration includes its own requirements analysis, design, implementation, and testing activities.

The iterative lifecycle is based on the successive enlargement and refinement of a system through multiple iterations, with cyclic feedback and adaptation as core drivers to converge upon a suitable system. The system grows incrementally over time, iteration by iteration, and thus this approach is also known as iterative and incremental development. Because feedback and adaptation evolve the specifications and design, it is also known as iterative and evolutionary development.

Posted in UP

The Unified Process, an Introduction

A software development process describes an approach to building, deploying, and possibly maintaining software. The Unified Process has emerged as a popular iterative software development process for building object-oriented systems. In particular, the Rational Unified Process or RUP , a detailed refinement of the Unified Process, has been widely adopted.

The UP is very flexible and open, and encourages including skillful practices from other iterative methods, such as from Extreme Programming (XP), Scrum, and so forth. For example, XP’s test-driven development, refactoring and continuous integration practices can fit within a UP project. So can Scrum’s common project room (”war room”) and daily Scrum meeting practice. Introducing the UP is not meant to downplay the value of these other methods quite the opposite.

Posted in UP