Agile Unified Process (AUP).pptx
Download as PPTX, PDF0 likes1,584 views
The Agile Unified Process (AUP) is a hybrid software development framework that combines elements of the Rational Unified Process (RUP) with agile methodologies, emphasizing iterative development and the delivery of incremental releases. It consists of four main phases—Inception, Elaboration, Construction, and Transition—and includes essential disciplines like modeling, implementation, testing, deployment, project management, and configuration management. AUP is guided by the principles of agility, simplicity, and the prioritization of high-value activities, aligning with the core tenets of the Agile Manifesto.
Agile Unified Process (AUP).pptx
- 1. AGILE UNIFIED PROCESS (AUP) Under Supervision of: Prof. Dr. Walid Rabie Student Name: Karim Mohamed Monir Abdelfattah Hassan Abouelmakarem Registration No.: 20135001
- 2. 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.
- 3. 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.
- 4. 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.
- 5. 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.
- 6. 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.
- 7. 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.
- 8. 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.
- 9. 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.