AGILE UNIFIED PROCESS (AUP)
Under Supervision of:
Prof. Dr. Walid Rabie
Student Name: Karim Mohamed Monir Abdelfattah Hassan Abouelmakarem
Registration No.: 20135001

A bit of history:
■ Agile Unified Process (AUP) is based on
Rational Unified Process (RUP).
■ The Rational Unified Process (RUP) is a
software engineering approach whose goal is to
produce high-quality software that meets or
exceeds the expectation of its users.
■ The agile unified process is a hybrid modeling
approach created by Scott Ambler when he
combined the Rational Unified Process (RUP) to
agile methods
■ AUP uses an agile approach which focuses on
both the larger life-cycle and the iterations
within each step to deliver incremental releases
over time.

Serial in the Large
The serial nature of Agile UP is captured in its four
phases :
■ 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.
■ Elaboration: The goal is to prove the
architecture of the system.
■ Construction: The goal is to build working
software on a regular, basis which meets the
highest-priority needs of your stakeholders.
■ Transition: The goal is to validate and deploy
your system into your production environment.

Iterative in the Small
Disciplines are performed in an iterative manner,
defining the activities which development team
members perform to build, validate, and deliver
working software which meets the needs of their
stakeholders. The disciplines are:
■ Model: The goal of this discipline is to understand
the business of the organization, the problem
domain being addressed by the project, and to
identify a viable solution to address the problem
domain.
■ Implementation: The goal of this discipline is to
transform your model(s) into executable code and
to perform a basic level of testing, in particular unit
testing.
■ Test: The goal of this discipline is to perform an
objective evaluation to ensure quality. This
includes finding defects, validating that the system
works as designed, and verifying that the
requirements are met.

Iterative in the Small
■ Deployment: The goal of this discipline is to plan
for the delivery of the system and to execute the
plan to make the system available to end users.
■ Configuration Management: The goal of this
discipline is to manage access to your artifacts.
This includes not only tracking artifact versions
over time but also controlling and managing
changes to them.
■ Project Management: The goal of this discipline
is to direct the activities that takes place on the
project. This includes managing risks, directing
people (assigning tasks, tracking progress, etc.),
and coordinating with people and systems outside
the scope of the project to be sure that it is
delivered on time and within budget.
■ Environment: The goal of this discipline is to
support the rest of the effort by ensuring that the
proper process, guidance (standards and
guidelines), and tools (hardware, software, etc.)
are available for the team as needed.

The Over Time Incremental Releases Delivery
■ Instead of the "big bang" approach where we deliver software all at once we
instead release it into production in portions. AUP teams typically deliver
development releases at the end of each iteration.
■ 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, testing, and deployment processes.

AUP Philosophy
The Agile UP is based on the following principles:
■ Your staff knows what they're doing: People aren't going to read detailed process
documentation, but they will want some high-level guidance and/or training from time to time.
■ Simplicity: Everything is described concisely using a handful of pages, not thousands of them.
■ Agility: The Agile UP conforms to the values and principles of the Agile alliance.
■ 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.
■ 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 tools or even open
source tools.

The Agile Manifesto
■ Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.
■ Welcome changing requirements, even late in development. Agile processes harness change
for the customer’s competitive advantage.
■ Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
■ Business people and developers must work together daily throughout the project.
■ Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done.
■ The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.

The Agile Manifesto
■ Working software is the primary measure of progress.
■ Agile processes promote sustainable development. The sponsors, developers,
and users should be able to maintain a constant pace indefinitely.
■ Continuous attention to technical excellence and good design enhances
agility.
■ Simplicity–the art of maximizing the amount of work not done–is essential.
■ The best architectures, requirements, and designs emerge from self-
organizing teams.
■ At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.