Agile Methodology vs. Rational Unified Process

AGILE METHODOLOGY

Agile methodology is an approach to project management, typically used in software

development. It helps teams respond to the unpredictability of building software through

incremental, iterative work cadences. The life cycle of the project is based on the development

iterations throughout the process. It is a framework that helps in minimizing the risk by

developing the software in short amount of time. Agile methods break tasks into small

increments with minimal planning, and do not directly involve long-term planning. The time in

which the software is being developed is called iteration. Each one of the iterations is a project

with analysis, design, coding, testing and also documentation. Multiple iterations takes place as

it is not possible to cover all the functionality of the product in just one iteration. The aim of the

developing unit is to produce a defect free release at the end of each iteration.

There are various Agile methodologies that have been in practise:

Agile Modeling

Agile Unified Process(AUP)

Dynamic Systems Development Method (DSDM)

Essential Unified Process(EssUP)

Extreme Programming (XP)

Feature Driven Development (FDD)

Open Unified Process (OpenUP)

Scrum

Velocity Tracking

Lean Software Development

Generalized Agile Process model:

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. In this method, an iterative approach is practiced to develop

the software. This method helps us to understand the problem through successive refinement

and to incrementally grow an effective solution over multiple iterations. Each iteration leads to

an iteration release (which may be only an internal release) that integrates all software across

the team and is a growing and evolving subset of the final system.

The six best practices that the process effectively utilizes to develop the software products are:

1. Develop software iteratively

2. Manage requirements

3. Use component-based architecture

4. Visually model software

5. Continuously verify software quality

6. Control changes to software

RUP has a series of phases and milestones that flow into each other. Phases consist of:

1. Inception, where the project's scope, estimated costs, risks, business case, environment

and architecture are identified.

2. Elaboration, where requirements are specified in detail, architecture is validated, the

project environment is further defined and the project team is configured.

3. Construction, where the software is built and tested and supporting documentation is

produced.

4. Transition, where the software is system tested, user tested, reworked and deployed.

The three strategies captured by RUP are a customizable process that guides development,

automated tools to expedite the process, and services that help to adopt process and tools

faster. These strategies intern captures the six best practices of software engineering (iterative

development, managing requirements, component based architecture, visual software models,

continuous verification and management of changes).

Comparison of few Agile Methodologies with Rational Unified Process

Extreme Programming

Extreme Programming or Xp is a software development methodology that is supposed to

improve the development of software. Xp is a form of agile software development that uses

time boxing for productivity and checkpoints during the software development phase.

Xp is popular among the truly faithful adherents to the methodology, but Xp encourages the

return to DAFTCRAP (DESIGN AFTER FIRST TESTING, and CONSTANT REFACTORING AFTER PROGRAMMING).

XP is a symbiotic process that focuses on the next part in order to work properly. In other words

it’s all or nothing, if you don’t run the methodology faithfully it will probably back fire at some

point. The theory is that each of its practices reinforces each other to produce something

stronger.

RUP (Rational Unified Processes) is a project framework that describes a class of processes that

are iterative and incremental. RUP process deliver functionality in small augmentations, each

building on the previous, and each being driven by use cases rather than being the construction

of a subsystem. RUP processes estimate tasks and plan schedules by measuring the speed of

iterations relative to their original estimates. Early iterations of RUP driven projects are strongly

focused upon software architecture; rapid implementation of features is delayed until a firm

architecture has been identified and tested.

A minimal implementation of RUP is called dX . The principles and practices of dX were

identified several years ago by Ward Cunningham, Kent Beck, Ron Jeffries, and a host of other

developers and methodologists. They have used this process on several projects with significant

success. Because of that success, they have gathered quite a following. They call the process

Extreme Programming; or Xp for short: Kent Beck is the one that wrote the book “Extreme

Programming Explained” which launched the popularity of this methodology, but never

credited other people that first identified the principles of Xp.

Rational Unified Process is process framework whereas Extreme Programming is a Process. The

following shows the brief comparison between RUP and Extreme Programming:

-Both proscribe iterative development - RUP's Inception Phase = User Stories -XP's User Stories map to RUP Use Cases -RUP's Elaboration Phase is XP's Planning Game (prioritization of use cases/user stories and

design the architecture/architectural spike).

-Both RUP and XP address and prioritize risk. -Both RUP and XP recognize that ongoing change is part of the process. - XP has some specific coding practices, but such things are (for now) outside of the scope of

RUP, though RUP does provide some sample standards and guidelines.

-RUP describes a core process with lots of options. XP follows most of the core process and omits most of the options. The following table shows how the phases of RUP compare with those of Extreme programming.

RUP Phase XP Notion

Inception:

-User Stories

-Metaphor

-initial spike.

Elaboration -More User Stories

-Establishing the metaphor, or other architecture.

-Some spikes, some production code.

-Calibration of estimation (Load Factor / Velocity)

Construction

-More User Stories

-Adding iterations onto the existing code, fleshing out the architecture.

-Refinement of process

-Refinement of estimation.

-First delivery to production, at a very early development phase. (If possible)

Transition

-Continued iterations, adding more and more features to production system.

-If necessary, old system runs in parallel with new system while new system takes

over more and more duties.

-Performance Tuning.

SCRUM

Scrum is an agile project management framework and as a management and control process

that cuts through complexity to focus on building software that meets business needs

(Schwaber/Beedle 2002). Scrum is an empirical development process wherein teams of 5 or 10

people produce increments of product every 14 to 30 days on the priority of work established

by the customer. A primary focus and benefit of Scrum is controlling risk. Scrum concentrates

on the project organization aspects of software development, completing increments of the

software product in 4 or less week iterations called sprints. Scrum team will meet daily to

review what was completed the previous day, plan the tasks for that day, and to identify

whether there are any issues or obstacles. Scrum uses frequent periodic reviews by the product

owners and stake holders, customer collaboration and response to changes desired by the

product owner throughout the development process to assure that the product is meeting

business expectations persistently as it is evolving.

Scrum principles:

Effective new product development is best performed and implemented using an

empirical process rather than a defined process.

A self-organized team that pulls work into development based upon its judgment and

capacity is critical to developing quality product quickly.

A team can deliver the most valuable software within a prescribed time and budget

using iterative development and the exact amount of functionality delivered will be

determined by the priority of the product backlog (requirements).

Product is delivered based upon the value of the features as prioritized by the product

backlog owners.

Current software projects using RUP can easily benefit from Scrum principles, even for projects

that are already started. The first area of investigation is the RUP process model and how Scrum

impacts the best practices in RUP, the four phases (Inception, Elaboration, Construction and

Transition), and the nine disciplines within RUP.

Scrum and RUP can enhance each other in various ways. The RUP process framework can be

tailored and customized to the project needs; the RUP development case and the software

development plan, for example, can reflect your decision to use Scrum techniques. In my

experience, the Scrum team will fall into a rhythm of activities and artifacts, which yield a most

effective development case. This output of artifacts can serve as an input document for other

projects within your organization.

In general, RUP satisfies organizational demands by bringing a structured and proven process

framework to the table, and Scrum patterns can add additional dynamics to the project. For

example, Scrum management patterns can be easily added to your current or future RUP

projects. Addressing the social side of software engineering, Scrum's proven process patterns

can offer immediate benefit in requirements management, change control, and project

management. With RUP artifacts guiding the development process and project documentation,

Scrum team members -- especially new or inexperienced ones -- are better equipped to avoid

software development pitfalls.

RUP vs. SCRUM Comparison

RUP SCRUM

Approach Iterative Iterative

Cycle Formal Cycle is defined across 4

phases, but some workflows

can be concurrent.

Each sprint (iteration) is a

complete cycle.

Planning Formal project plan, associated

with multiple iterations, is

used. The plan is end-date

driven and also has

intermediate milestones.

No end-to-end project plan.

Each next iteration plan is

determined at the end of the

current iteration (NOT end-

date driven). Product Owner

(Key Business User) determines

when the project is done.

Scope Scope is predefined ahead of Instead of scope, SCRUM uses a

the project start and

documented in the Scope

document. Scope can be

revised during the project, as

requirements are being

clarified, but these revisions

are subject to a strictly

controlled procedure.

Project Backlog, which is re-

evaluated at the end of each

iteration (sprint).

Artifacts Vision/Scope Document,

Formal functional

requirements package, system

architecture document,

development plan, test plan,

test scripts, etc.

The only formal artifact is the

operational software.

Type of Project/Product Recommended for large, long-

term, enterprise-level projects

with medium-to-high

complexity.

Recommended for quick

enhancements and

organizations that are not

dependent on a deadline.

Lean software Development:

Lean principles come from the Japanese manufacturing industry. Lean is described as a set of

tools that help to identify and eliminate waste. When waster is eliminated, quality improves

and costs are reduced. Used by Toyota, lean thinking emphasizes educating people to become

skillful systems thinkers.

Being more strategically focused than any other Agile Methodology, Lean Software

development aims at developing software at one third of each: time, budget and defect rate.

Lean Software Development is not a management or development methodology per se, but it

offers principles that are applicable in any environment to improve software development.

The seven principles in LEAN development:

1. Eliminate waste – developers should follow the principle that if something is not adding

value then it is considered to be waste. Examples are: unnecessary code, delays in the

development process, requirements that are not clear, bureaucracy, slow communication

and delays in the development process.

2. Amplify learning – short iteration cycles along with refactoring and integration testing

should be used. By using feedback sessions with customers, developers can gauge the

success of the current phase of development and adjust as necessary. Using these sessions,

the developers and the customers learn more about the problems and have a better

understanding of the needs of the customer.

3. Decide as late as possible – since there is uncertainty in software development, results are

better when they are delayed as much as possible so that decisions can be made on facts

instead of assumptions.

4. Deliver as fast as possible – keeping iterations of the software short allows for better

learning and communication. Transparency of the process is also recommended for better

team communication. Just in time production technology can be used which means that a

result can be given to a team and they will organize themselves and divide tasks to

accomplish what is needed for that specific iteration.

5. Empower the team – managers should listen to developers and allow developers to provide

suggestions for improvement. Managers should motivate developers and give them access

to the customer/user and team leaders should be supportive and provide help as needed.

6. Build integrity in – the customer should have knowledge of the system such as how it is

advertised, delivered, deployed, accessed, used, priced and how well it works. Information

should flow back and forth between customers and developers. Refactoring also can be

used. Integrity should be verified with testing that is very thorough so that the product

does what the customer wants it to do.

7. See the whole – Since many different groups can be involved in the system being developed

it is important that the relationships between them are well defined so that the system

components work together as they should. Lean thinking should be understood by all those

working on the system so that all of the principles can be implemented.

The principle of delivering as fast as possible is similar to RUP which is an iterative process but

Lean does not define phases as RUP does. The six best practices of RUP are not specifically

defined in the Lean methodology but they can be seen in the seven principles. Lean software

development practices are expressed in different terms that other agile methodologies but

there are parallels.

Conclusion:

Agile methodologies promote an incremental, iterative approach to development of

functionality (including method signatures), with visibility of the impact of change given

through test coverage. Basically, working on the premise that, change is cheap if supported

correctly and Experiencing agile methods is proven to be worthy because it is more responsive

towards the improvement.

The Rational Unified Process uses iterative approach for organizing projects in terms of

workflow and phases, each consisting of one or more iterations. Each project iteration cycle

begins with a plan outlining what will be accomplished and concluding with an evaluation of

whether objectives have been met.

Agile processes on the other hand, spend time on each activity in each iteration. During each

iteration (usually 2-4 weeks) a little of all steps (requirements, analysis, design, development,

test, etc.) are undertaken. The goal is to have stable software which could be shipped at the

end of each iteration.

Although RUP is iterative, it follows the general phases of inception, elaboration, construction,

and transition in a more or less linear fashion. As the development proceeds less time is spent

on requirements and analysis, and more time is spent on construction, testing, and transition.

Agile on the other hand tends to be used for small to medium sized projects involving teams up

to 10 closely knit developers. Once teams become bigger than this, agile methodologies begin

to fail, as they don’t scale to large teams, or teams spread across geographies.

UP and it’s relative, the Rational Unified Process (RUP), are quite comprehensive, and were

designed to be modified to suit the project being developed. This adds another layer of

complexity to the development effort, as the process has first to be modified before being

implemented. While this allows for the flexibility to use UP on any project, it requires teams to

have access to UP experts to ensure that the process is being defined and used properly.

Agile methods emphasize real time communication, preferably face-to-face, over written

documents. Most agile teams are located in a bullpen and include all the people necessary to

finish the software. At a minimum, this includes programmers and the people who define the

product such as product managers, business analysts, or actual customers. The bullpen may

also include testers, interface designers, technical writers, and management.

RUP is a configurable software development process that is based on many years of experience

in using object technology to develop mission critical software in a variety of industries.

References:

1. Ken Schwaber, Mike Beedle (2002), Agile Software Development with Scrum.

2. http://www.ibm.com/developerworks/rational/library/feb05/krebs/

3. http://www.chiron-solutions.com/chiron-professional-journal/2010/12/20/what-is-the-

difference-between-rup-and-scrum-methodologies/

4. http://fox.wikis.com/wc.dll?Wiki~RationalUnifiedProcessAndExtremeProgramming

5. http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251

_bestpractices_TP026B.pdf

6. http://www.executivebrief.com/software-development/waterfall-rup-agile/

7. https://www.samrantech.com/methodologies-comparison-between-agile-and-rup-

2.html

8. http://ccollins.wordpress.com/2008/06/11/unified-process-vs-agile-processes/

9. http://practicalagility.blogspot.com/2008/11/waterfall-vs-rad-vs-rup-vs-agile-

scrum.html

10. https://wiki.smu.edu.sg/is200/Agile_Methodology