Iteration Length and Timeboxing

32

The UP (and experienced iterative developers) recommends an iteration length between two and six weeks. Small steps, rapid feedback, and adaptation are central ideas in iterative development; Long iterations subvert the core motivation for iterative development and increase project risk. Much less than two weeks, and it is difficult to complete sufficient work to get meaningful throughput and feedback; much more than six or eight weeks, and the complexity becomes rather overwhelming, and feedback is delayed. A very long iteration misses the point of iterative development. Short is good.

32

OOAD,

Timeboxing
33

A key idea is that iterations are timeboxed, or fixed in length. For example, if the next iteration is chosen to be four weeks long, then the partial system should be integrated, tested, and stabilized by the scheduled date date slippage is discouraged. If it seems that it will be difficult to meet the deadline, the recommended response is to remove tasks or requirements from the iteration, and include them in a future iteration, rather than slip the completion date.
33

OOAD,

Iterative and Incremental Development

34

34

OOAD,

UP Artifacts and Process Context

35

Business Modeling As illustrated in Figure, use cases influence many UP artifacts. Requirements
Terms, attributes relationships

Domain Model

Partial artifacts, refined in each iteration

Terms, attributes, validation

Use-Case Model

Vision

requirements

Supplementary Specification

Glossary

Software Architecture Doc.

Requirements, I/O events Design Model

Design

Requirements, priorities Software Dev. Plan

Project Management

Acceptance tests

Development Case

Test OOAD,

Test Plan

Sample UP Artifacts
35

Environment

UML Diagrams Are Key System Artifacts

36

Use-Case Diagram
Use Case 1 Actor A Use Case 2 Actor B

Class Diagram
DocumentList FileMgr add( ) delete( ) Document name : int docid : int numField : int get( ) open( ) close( ) read( ) sortFileList( ) create( ) fillDocument( ) read() fill the code.. fetchDoc( ) sortByName( ) FileList fList add( ) delete( ) 1

State Diagram
add file [ numberOffile==MAX ] / flag OFF Openning

add file

Writing

close file

close file Reading

rep Repository (from Persistence) File GrpFile

Closing

read( )

Domain Expert

name : char * = 0 readDoc( ) readFile( ) read( ) open( ) create( ) fillFile( )

Use Case 3
UI

<<entity>> Customer name addr receive() withdraw() fetch() send()

MFC

Class
Repository DocumentList

Deployment Diagram
- 95 : - NT: - - : - -, - - IBM : -, -

DocumentApp

RogueWave Persistence

Window95

Windows95 Windows95

global

FileManager

- .EXE -

User Interface Definition

Collaboration Diagram

Package Diagram

Windows N T

Document
- .EXE

Solaris

Alpha UNIX -.EXE Windows N T

GraphicFile File FileList

IBM Mainframe

Component Diagram

Forward Engineering(Code Generation) and Reverse Engineering

Source Code edit, compile, debug, link Sequence Diagram Executable System
36

OOAD,

Major Workflows Produce Models

37

Business Modeling
Business Model

supported by

Requirements Analysis & Design Implementation

Use-Case Model

realized by

implemented by Analysis and Design Model verified by Implementation Model

Test
Test Model
37

OOAD,

Artifacts/Models in UP Workflows
38

Discipline

Artifact Iteration

Incep. I1

Elab. E1En

Const. C1-Cn

Trans. T1-T2

Business Modeling

Domain Model Use-Case Model Vision Supplementary Specification Glossary s s s s

s r r r r s s s s s s
38

Design

Design Model SW Architecture Document Data Model

r r r r r r r

Implementation Project-Management Testing Environment*

OOAD,

Implementation Model SW Development Plan Test Model Development Case*

.

r s r

s-start; r-refine

Feedback on Evolutions
39

A two year study reported (in the MIT) of successful software projects identified four common factors for success [MacCormack01] ;
1) 2) 3) 4)

iterative development (was first on the list) at least daily incorporation of new code into a complete system build, and rapid feedback on design changes (via testing); and early focus on building and providing a cohesive architecture

39

OOAD,

The Agile UP (1)

40

Methodologists speak of processes as heavy vs. light, and predictive vs. adaptive. A heavy process is a pejorative term meant to suggest one with the following qualities [FowlerOO]: many artifacts created in a bureaucratic atmosphere rigidity and control elaborate, long-term, detailed planning predictive rather than adaptive

40

OOAD,

Agile UP (2)
41

A predictive process is one that attempts to plan and predict the activities and resource (people) allocations in detail over a relatively long time span, such as the majority of a project

Predictive processes usually have a "waterfall" or sequential lifecyclefirst, defining all the requirements; second, defining a detailed design; and third, implementing.

In contrast, an adaptive process is one that accepts change as an inevitable driver and encourages flexible adaptation; they usually have an iterative lifecycle
41

OOAD,

Agile UP(3)
42

An agile process implies a light and adaptive process, nimble in response to changing needs. The UP was not meant by its authors to be either heavy or predictive, although its large optional set of activities and artifacts have understandably led to that impression. Rather, it was meant to be adopted and applied in the spirit of an agile process agile UP.

42

OOAD,

43

You didnt understand

You Didnt Understand

44

You Know You Didnt Understand the UP When

You

think that inception = requirements, elaboration = design, and construction = implementation (that is, superimposing a waterfall lifecycle on to the UP). think that the purpose of elaboration is to fully and carefully define models, which are translated into code during construction.

You

44

OOAD,

You Didnt Understand

45

You Know You Didnt Understand the UP When

You try to define most of the requirements before starting design or implementation. You try to define most of the design before starting implementation; you try to fully define and commit to an architecture before iterative programming and testing. A "long time" is spent doing requirements or design work before programming starts.

45

OOAD,

You Didnt Understand

46

You

believe that a suitable iteration length is four months long, rather than four weeks long (excluding projects with hundreds of developers).

You

think UML diagramming and design activities are a time to fully and accurately define designs and models in great detail, and of programming as a simple mechanical translation of these into code.

46

OOAD,

You Didnt Understand

47

You think that adopting the UP means to do many of the possible activities and create many documents, and thinks of or experiences the UP as a formal, fussy process with many steps to be followed. You try to plan a project in detail from start to finish; you try to speculatively predict all the iterations, and what should happen in each one.

You want believable plans and estimates for projects before the elaboration phase is finished.

47

OOAD,

Summary: Unified Process

48

The Unified Modeling Language (UML) is a language for specifying, visualizing, constructing, and documenting the artifacts of a softwareintensive system A software development process defines Who is doing What, When and How in building a software product The Unified Process has four phases: Inception, Elaboration, Construction and Transition Each phase ends at a major milestone and contains one or more iterations An iteration is a distinct sequence of activities with an established plan and evaluation criteria, resulting in an executable release

48

OOAD,