Introduction to Agile Unified Process AUP

AUP is a simplified version of the (RUP). It describes a simple, easy to understand

approach to developing business application software using agile techniques and concepts yet
still remaining true to the RUP. I've tried to keep the Agile UP as simple as possible, both in its
approach and in its description. 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.
Principles:
Some of the principles behind the Agile Manifestoare:
• Customer satisfaction by • Face-to-face conversation is
rapid, continuous delivery of the best form of
useful software communication (co-location)
• Working software is • Projects are built around
delivered frequently (weeks motivated individuals, who
rather than months) should be trusted
• Working software is the • Continuous attention to
principal measure of progress technical excellence and good
• Even late changes in design
requirements are welcomed • Simplicity
• Close, daily cooperation • Self-organizing teams
between business people and • Regular adaptation to
developers changing circumstances
AUP life Cycle:
Figure depicts the lifecycle of the AUP. The first thing that you'll
notice is that the disciplines have changed. First, the Model discipline
encompasses the RUP's Business Modeling, Requirements, and Analysis
& Design disciplines. Model is an important part of the AUP, as you can
see, but it doesn't dominate the process -- you want to stay agile by
creating models and documents which are just barely good enough.
Second, the Configuration and Change Management discipline is now the
Configuration Management discipline
Serial in the Large:
The serial nature of Agile UP is captured in its four
phases:
1. Inception. The goal is to identify the initial scope of
the project, a potential architecture for your system, and
to obtain initial project funding and stakeholder
acceptance.
2. Elaboration. The goal is to prove the architecture of
the system.
3. Construction. The goal is to build working software
on a regular, incremental basis which meets the highest-priority
needs of your project stakeholders.
4. Transition. The goal is to validate and deploy your system into
your production environment.
Delivering Incremental Releases over Time:
Instead of the "big bang"
approach where you deliver
software all at once you instead
release it into production in
portions (e.g. version 1, then
version 2, and so on). AUP teams typically deliver development releases
at the end of each iteration into pre-production staging area(s). A
development release of an application is something that could potentially
be released into production if it were to be put through your pre-
production quality assurance (QA), testing, and deployment processes
The Agile UP is based on the following principles:
1. Your staff knows what they're doing. People aren't going to
read detailed process documentation, but they will want some high-
level guidance The AUP product provides links to many of the details,
if you're interested, but doesn't force them upon you.
2. Simplicity. Everything is described concisely using a handful of
pages, not thousands of them.
3. Agility. The Agile UP conforms to the values and principles of the
Agile Alliance.
4. Focus on high-value activities. The focus is on the activities
which actually count not every possible thing that could happen to you
on a project.
5. Tool independence. You can use any toolset that you want with
the Agile UP. My suggestion is that you use the tools which are best
suited for the job, which are often simple.
6. You'll want to tailor this product to meet your own needs. The
AUP product is easily tailorable via any common HTML editing tool.
You don't need to purchase a special tool
Comparison with other methods:
Agile development differs from other development models: in this
model time periods are measured in weeks rather than months and work is
performed in a highly collaborative manner. Most agile methods also
differ by treating their time period as a timebox.
Agile methods, in contrast, produce completely developed and tested
features (but a very small subset of the whole) every few weeks. The
emphasis is on obtaining the smallest workable piece of functionality to
deliver business value early and continually improving it and/or adding
further functionality throughout the life of the project.
Criticism:
• Lack of structure and necessary documentation
• Only works with senior-level developers
• Incorporates insufficient software design
• Requires too much cultural change to adopt
• Can lead to more difficult contractual negotiations
 • Can be very inefficient.
• Impossible to develop realistic estimates of work effort needed to
provide a quote, because at the beginning of the project no one knows
the entire scope/requirements
• Drastically increases the risk of scope creep due to the lackof detailed
requirements documentation
Conclusion:
Agile software development stresses rapid iterations, small and
frequent releases, facilitated by direct user involvement in the
development process. It a framework to visualize scope, orchestrate
mundane and enforce process. Unlike agile-specific products offered by
agile-only vendors, methodology neutral and can be applied equally well
to agile as well as more traditional they can support all the development
activities within an enterprise.
References:
1. http://en.wikipedia.org/wiki 3. http://www.agilemodeling.c
/Agile_Software_Developm om/essays/agileModelingRUP.ht
entwww.google.com m
2. www.perftestplus.com/resou 4. http://www.mariosalexandr
rces/rupfordummies_ppt.pdf ou.com/methodologies/agile-
software-development.asp