Just About IT
25May/100

Agile Unified Process

Agile Unified Process





The Agile Unified Process, or Agile UP, is an ultra-lightweight variant of the Unified Process
(UP) which was developed by Grady Booch, James Rumbaugh and Ivar Jacobson ~ and is
marketed by IBM Rational as the Rational Unified Process (RUP). UP is an extensive
process framework that can be applied to a very wide range of projects and is then adapted
to the requirements of each individual project. (http://www.radtac.co.uk/pdf/AUP.pdf)

Agile UP Phases

  1. Inception Phase
  2. Elaboration Phase
  3. Construction Phase
  4. Transition Phase

Agile UP Disciplines

  1. Model
  2. Implementation
  3. Test
  4. Deployment
  5. Configuration Management
  6. Project Management
  7. Environment

Philosophies

The Agile UP is based on the following philosophies:

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 and/or training from time to time. 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 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 or even open source tools.

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

(http://en.allexperts.com/e/a/ag/agile_unified_process.htm)
25May/100

Software Development Methodology

One part that is so critical in creating an information system is choosing the most appropriate methodology. It must be suitable to the project and so you'll be able to utilize them well. One common problem in selecting a methodology is that some end up selecting a model instead of a methodology.

Model Vs. Methodology


Generally, a model or a framework allows you to understand which project deliverable you should produce on a specific time.  It does not show off what you should do. On the other hand, a methodology as defined by the Treasury Enterprise Architecture Framework a methodology is a documented approach for performing activities in a coherent, consistent, accountable, and repeatable manner. It most likely serve as a  step by step guide for you, towards the end of your project development.

Software Development Methodology are like standards that we can employ to organize, plan, and manage the process of developing an Information System. There are different variety of methodologies available, each of these methodologies possesses its own strenghts and weaknesses. A methodology could be appropriate to a certain project and may not appropriate to another project. A specific methodology is best suited to specific kind of project.
Below are some of the commonly used methodologies that you may consider using on your project:

  • Agile Unified Process
  • Capability Maturity Model Integration
  • Crystal
  • Dynamic Systems Development Method
  • Enterprise Unified Process
  • Essential Unified Process
  • Evo
  • Extreme Programming
  • Feature Driven Development
  • Lean Software Development
  • Microsoft Solutions Framework
  • Open Unified Process
  • Prince2
  • Project Management Body of Knowledge
  • Rational Unified Process
  • Scrum
  • Unified Process
Filed under: Tutorials No Comments