Agile Unified Process (UP): Agile Process Overview Introduction to - - PDF document

1

Agile Unified Process (UP): Introduction to an OOA/D Process

Slide Sources: Applying UML and Patterns by C. Larman and Introduction to OOA/D Process slides by Dr. R. France

Eunjee Song

• Dept. of Computer Science

Baylor University

Overview

 Agile Process Overview  Agile Unified Process (UP) Basics  Introduction to an OOA/D Process

Introduction to an OOA/D Process - 2

 Agile Process Principles

What is an agile process?

A process that continuously adapts and adjusts to

 changes derived from experiences gained

during the development

Introduction to an OOA/D Process - 3

during the development,

 changes in software requirements and  changes in the development environment.

Why agile processes?

 Internet “age” characterized by rapid

changes in technologies and demands

 Increased pressure to develop new services

and enhance existing services quickly to gain

Introduction to an OOA/D Process - 4

and enhance existing services quickly to gain competitive advantage

 Focus is on producing “quality” code quickly

and economically

Agile UP Basics

 No detailed overall plan

 High-level plan that outlines major outlines and

estimates end-time (Phase Plan)

 Iterative, incremental, time-boxed

 Each iteration is a mini-project  Detailed plan for each iteration (Iteration Plan) Introduction to an OOA/D Process - 5  Detailed plan for each iteration (Iteration Plan)  Each iteration has a non-extensible fixed duration

 Risk-driven, quality-focused

 Tackle high-risk, high-value issues in early iterations  Build a cohesive core architecture in early iterations  Continuously verify quality

Iterative/incremental process

Requirements Design Implementation & Test & Integration & More Design Requirements Design Feedback from iteration N leads to refinement and adaptation of the requirements and design in iteration N+1. Time Implementation & Test & Integration & More Design Introduction to an OOA/D Process - 6 Final Integration & System Test 3 weeks (for example) The system grows incrementally. Iterations are fixed in length, or timeboxed. Final Integration & System Test

2

It ti 1 It ti 2 It ti 3 It ti 4 It ti 5 20% 2% requirements software 30% 5% requirements software 50% 8% 90% 90% 20% 10% requirem ents workshops Im agine this will ultim ately be a 20- iteration project. In evolutionary iterative developm ent, the requirem ents evolve

• ver a set of the early

iterations, through a series of requirem ents workshops (for exam ple). Perhaps after four iterations and workshops, 90% of the requirem ents are defined and refined. Nevertheless, only 10% of the software is 1 2 3 4 5 ... 20

Introduction to an OOA/D Process - 7

Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 10% of the software is built. week 1 M T W Th F week 2 M T W Th F week 3 M T W Th F kickoff m eeting clarifying iteration goals with the team . 1 hour team agile m odeling & design, UM L whiteboard sketching. 5 hours start coding & testing a 3-week iteration de-scope iteration goals if too m uch work final check-in and code- freeze for the iteration baseline dem o and 2-day requirem ents workshop next iteration planning m eeting; 2 hours M ost O O A/D and applying UM L during this period Use-case m odeling during the workshop

Phases

Activities and iterations organized around 4 major phases in UP:



Inception

 Early exploration of problem to determine project feasibility  What’s the perceived business value?  What are the risks? 

Elaboration

 Requirements detailing (major requirements identified)  Iterative implementation of “core” architecture Introduction to an OOA/D Process - 8 

Construction

 Iterative development of remaining low-risk elements  Prepare for deployment 

Transition

 Beta tests  Deployment

Iterations vs. Phases

inc. elaboration construction transition iteration phase development cycle Introduction to an OOA/D Process - 9 release A stable executable subset of the final

• product. The end of

each iteration is a minor release. increment The difference (delta) between the releases of 2 subsequent iterations. final production release At this point, the system is released for production use. milestone An iteration end- point when some significant decision

• r evaluation
• ccurs.

UP Disciplines (Workflows)

 Business modeling: modeling of business

processes and concepts

 Requirements: requirements analysis and

specification

 Design: solution analysis and synthesis  Implementation: Code realization of design

Introduction to an OOA/D Process - 10

 Test: Verification of implementation  Deployment: Installation and operation of system

in environment

 Configuration & Change Management  Environment

Business Modeling Requirements Design Implementation Focus

• f this

book Note that although an iteration includes work in most disciplines, the relative effort and emphasis change

• ver time.

This example is suggestive, not literal. A four-week iteration (for example). A mini-project that includes work in most disciplines, ending in a stable executable. Introduction to an OOA/D Process - 11 Test Deployment Configuration & Change Management Project Management Environment

Principles - 1



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.

Introduction to an OOA/D Process - 12 

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.

3 Principles - 2

 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

t d i ti l

Introduction to an OOA/D Process - 13

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.

Conclusions



Some aspects of a software development project can benefit from an agile approach while others can benefit from a less- agile or more predictive approach.



Practical software development processes can be classified along a spectrum depending on their degree of "agility".

 At one extreme are the predictive processes in which the

process steps are defined in detail early in the project, and project goals remain relatively stable throughout the

Introduction to an OOA/D Process - 14

project goals remain relatively stable throughout the execution of the process.

 At the other end are the purely agile processes in which

process steps and project goals are dynamically determined

 The agility of a process is determined by the degree to which

a project team can dynamically adapt the process based on changes in the environment and the collective experiences of the developers.

 Current agile processes are close to the purely agile end