1. COMP 350: Object Oriented Analysis and Design Lecture 2
COMP 350: Object Oriented Analysis and Design Lecture 2 Iterative, Evolutionary and Agile References: Craig Larman Chapters 1-2

2. OOAD

3. 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.”

4. Key Steps in OOAD [2]
Domain Model: diagram(s) showing domain concepts, attributes, and associations

5. Key Steps in OOAD [3]
Interaction Diagram: shows the flow of messages between software objects(method invocation)

6. Key Steps in OOAD [4]
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)

9. 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.

10. 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.

11. Iterative and Incremental Development (RUP)

12. Embracing Change: Feedback and Adaptation

13. 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

14. 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

15. (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

16. (R) UP Phases

17. (R) UP Disciplines

18. (R) UP Disciplines

19. (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

20. 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

21. 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

22. 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

23. 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

24. Agile Principles
Review from Chapter 2 in Larman’s book

25. 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