What is Agile Unified Process (AUP)?

Agile Unified Process (AUP) is a simplified version of the IBM Rational Unified Process (RUP) developed by Scott Ambler. 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. The AUP applies agile techniques including test driven development (TDD), Agile Modeling, agile change management, and database refactoring to improve productivity

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, incremental basis which meets the highest-priority needs of your project stakeholders.

Transition : The goal is to validate and deploy your system into your production environment

What are the Disciplines of AUP ?

1.Model. Understand the business of the organization, the problem domain being addressed by the project, and identify a viable solution to address the problem domain.

2.Implementation. Transform model(s) into executable code and perform a basic level of testing, in particular unit testing.

3.Test. 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.

4.Deployment . Plan for the delivery of the system and to execute the plan to make the system available to end users.

5.Configuration Management . Manage access to project artifacts. This includes not only tracking artifact versions over time but also controlling and managing changes to them.

6.Project Management . Direct the activities that takes place within 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.

7.Environment. 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.

What are the Philosophies of AUP ?

1.Your staff knows what they're doing. People are not going to read detailed process documentation, but they will want some high-level guidance and/or training from time to time. The AUP product provides links to many of the details, if you are 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 software development and 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. The recommendation is that you use the tools which are best suited for the job, which are often simple tools.

6.You'll want to tailor the AUP to meet your own needs.

Phases of Agile Unified Process

1.The Inception Phase 

Primary goal of inception phase is to obtain stakeholder's  consensus on the objectives and obtain funding for the project.Below are the major activities in inception phase.

Define project scope: At a high level define, what the system will do and will not do.This usually tales the form of a list of high-level features and/or point form use cases

Estimate cost and schedule: The schedule and cost for the project are estimated.As with all planning, those tasks that are to be completed in the near future are detailed more accurately and with greater confidence while tasks further down the line are understood to be estimates with larger margins of error.

Define risks:Risk management is important an AUP project. The list of risks is a living compilation that will change over time as risks are identified, mitigated, avoided and/or materialize and dealt with. Risks drive the management of the project, as the highest priority risks drive the scheduling of iterations. Higher priority risks, for example, are addressed in earlier iterations than lower priority risks.

Determine project feasibility: Project must make sense from technical, operational, and business perspectives. If the project isn't feasible, it should be cancelled.

Prepare the project environment: This includes reserving workspace for the team, requesting the resources that will be needed, obtaining hardware and software that are needed immediately, and compiling a list of anticipated hardware and software that will be needed later.

2.The Elaboration Phase

The primary goal of the Elaboration phase is to prove the architecture for the system to be developed. The point is to ensure that the team can actually develop a system that satisfies the requirements, and the best way to do that is to build a end-to-end, working skeleton of the system called an "architectural prototype".The goal is to write high-quality, working software which meets several high risk (from a technical point of view) use cases to show that the system is technically feasible.

The requirements are not specified completely at this point. They are detailed only enough to understand architectural risks and to ensure that there is an understanding of the scope of each requirement so that subsequent planning can be carried out. Architectural risks are identified and prioritized; the significant ones are addressed during Elaboration. Addressing architectural risks may take several forms: research into similar system(s), a stand-alone test suite, a working prototype, etc. In most cases, a working prototype showcasing the architecture is completed. The system level architecture should also reflect overall enterprise architecture.

During Elaboration, the team is also preparing for the Construction phase. As the team gains a handle on the architecture of the system, they begin setting up the environment for Construction by purchasing hardware, software, and tools. From a project management point of view, staffing is addressed; resources are requested and/or hired. Plans for communication and collaborating are finalized.

To exit the Elaboration phase the team must pass the Lifecycle Architecture (LCA) milestone. The primary issues addressed with this milestone is whether the team has shown that they have a working end-to-end prototype which shows the team has a viable strategy to build the system and that the stakeholders are prepared to continue funding the project.

3.The Construction Phase

The focus of the Construction phase is to develop the system to the point where it is ready for pre-production testing. In previous phases, the majority of the requirements have been identified and the architecture for the system has been baselined. Now its time to prioritizing and understanding the requirements, model storming a solution, and then coding and testing the software. If necessary, early releases of the system are deployed, either internally or externally, to obtain user feedback.

At the end of this phase the current version of the system should ready to move into pre-production test environment for system and acceptance testing. If the team passes this milestone the project moves to the Transition phase, otherwise it may be re-directed or cancelled.

4.The Transition Phase

The Transition phase focuses on delivering the system into production. There may be extensive testing that takes place during this phase, including beta testing. Fine-tuning of the product takes place here as well as rework to address significant defects.

The time and effort spent in Transition varies from project to project. Internal systems are generally simpler to deploy than external systems. High visibility systems may require extensive beta testing by small groups before release to the larger population. The release of a brand new system may entail hardware purchase and setup while updating an existing system may entail data conversions and extensive coordination with the user community.

To exit the Transition phase the team must pass the Product Release milestone. The primary issue here is whether the system can be safely and effectively deployed into production. If the team passes this milestone the project moves to production. If the project fails in any area above, the project may be re-directed or cancelled