agile methodology vs rational unified process1
Post on 26-Oct-2014
89 Views
Preview:
TRANSCRIPT
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
top related