1

COMP 350: Object Oriented Analysis and Design

Lecture 2 Iterative, Evolutionary and Agile

References: Craig Larman Chapters 1-2

OOAD

2

Key Steps in OOAD [1]

• Use Case: a textual description or story” describing the system

• Example:

• Play A Dice Game: “A player picks up and rolls the dice.

If the dice face values total seven, they win; otherwise, they lose.”

3

Key Steps in OOAD [2]

4

Domain Model: diagram(s) showing domain concepts, attributes, and associations

Key Steps in OOAD [3]

5

Interaction Diagram: shows the flow of messages between software objects(method invocation)

Key Steps in OOAD [4]

6

Design Model: shows attributes, methods and associations for software (solution) objects (not domain objects!)

7

Iterative, Evolutionary & Agile• Higher success and productivity rates, lower

defect rates

• Contrast with sequential waterfall lifecycle

• Quick development steps and feedback

• Feedback is used to clarify and improve evolving specifications

• Development starts before all requirements are defined in detail

• Involves early programming and testing of a partial system, in repeating cycles

8

Iterative Development• Iterative and incremental development:

System grows incrementally over time, iteration by iteration.

• Iterative and evolutionary development: System evolves based on feedback and adaptation

• Iterations: time boxed, fixed length (e.g. 2-6 weeks)

Iterative Development• The result of each iteration is an executable

but incomplete system; it is not ready to deliver into production. Maybe after 10 to 15 iterations it can go into production

• The result of each iteration is not an experimental or throw away prototype. Rather it is a subset of the final system. Iterative development is not prototyping.

9

Iterative Development

• Development is organized into a series of short fixed length (e.g., 3 weeks) mini projects called iterations

• The outcome of each is a tested, integrated, and executable system.

• Each iteration involves choosing a small subset of the requirements, and quickly designing, implementing, and testing.

10

Iterative and Incremental Development (RUP)

11

Embracing Change: Feedback and Adaptation

12

Benefits of Iterative Development

• early rather than late mitigation of high risks (technical, requirements, objectives, usability, and so forth)

• early visible progress

• early feedback, user engagement, and adaptation, leading to a refined system that more closely meets the real needs of the stakeholders

• managed complexity; the team is not overwhelmed by "analysis paralysis" or very long and complex steps

• the learning within an iteration can be methodically used to improve the development process itself, iteration by iteration

13

Best Practices and Concepts

• The central idea- short time boxed iterative, adaptive development.

• (implicit, but core) use of object technologies, including OOA/D and OOP.

• tackle high-risk and high-value issues in early iterations

• continuously engage users for evaluation, feedback, and requirements

• build a cohesive, core architecture in early iterations

• continuously verify quality; test early, often, and realistically

• apply use cases

• model software visually (with the UML)

• carefully manage requirements

• practice change request and configuration management

14

(R) UP Phases• Inception –Approximate vision, business case, scope,

vague estimates

• Elaboration –refined vision, iterative implementation of the core architecture, resolution of high risks, identification of most requirements and scope, more realistic estimates

• Construction –iterative implementation of the remaining lower risk and easier elements, and preparation for deployment

• Transition –beta tests, deployment

• This is not the old waterfall model

• Inception is not requirements analysis

• Elaboration is not requirements and design phase

15

(R) UP Phases

16

(R) UP Disciplines

17

(R) UP Disciplines

18

(R)UP Disciplines

• A discipline is a set of activities and their related artifacts.

• Artifact is the general term for any work product e.g. code, diagrams, models, database schema, text docs etc

19

Relationship between UP Phases and Disciplines

• In each iteration work goes on in most or all disciplines. However, relative efforts across these disciplines change over time

• During elaboration: more emphasis on requirements and design but little on implementation

• During construction: other way round

20

Agile Methods

• Started in 2001

• A group interested in iterative and agile methods met and formed the Agile Alliance with a manifesto and a statement of principles

• www.agilealliance.com

21

Agile Methods• Encourage Agility – rapid and flexible response to

change• Values and Practices advocated by Agile Methods:

– Time boxed iterative and evolutionary development

– Adaptive planning– Simplicity, communication, lightness– Pair programming– Test driven development– Common project workroom– Daily meetings 22

Agile Manifesto• Individuals, Interactions, Working Software

over Processes and Tools

• Working Software over Comprehensive Documentation

• Customer Collaboration over Contract Negotiation

• Responding to Change over Following a Plan

23

Agile Principles

• Review from Chapter 2 in Larman’s book

24

What is Agile Modeling

• Purpose of modeling (sketching UML diagrams) is primarily to understand, not to document

• In practice, digital pictures of whiteboard drawings can be used (focus on model rather than tool)

• Create models in parallel, e.g., class diagrams and interaction diagrams

• Model in pairs

• Stick to simple, frequently used UML elements rather than UML details that are not used widely

• All models will be inaccurate – only the final tested code is the best design. All prior models and diagrams are incomplete hints , best treated lightly as throwaway explorations

25