Introduction to Agile Unified Process AUP AUP is a simplified version of the (RUP). (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 lifecycle of the AUP. The first thing that you'll notice is that the disciplines disciplines have changed. First, the Model discipline discipline encompasses the RUP's Business Modeling, Requirements, and Analysis & Design disciplines. Model is an important 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 typically deliver development releases at the end of each iteration into 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 aren't going to read detailed process documentation, but they will want some highlevel guidance The AUP A UP 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 using a handful of pages, not thousands of them. 3. Agility. The Agile UP conforms to to the values and principles of the Agile Alliance. 4. Focus on high-value activities. The focus is 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 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 n egotiations • 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 scop e, 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 /Agile_Software_Developm entwww.google.com 2. www.perftestplus.com/resou rces/rupfordummies_ppt.pdf
3.
http://www.agilemodeling.c om/essays/agileModelingRUP.ht m http://www.mariosalexandr 4. ou.com/methodologies/agile software-development.asp
