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

OOAD

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

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

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

Key Steps in OOAD [4] Design Model: shows attributes, methods and associations for software (solution) objects (not domain objects!)

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

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.

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.

Iterative and Incremental Development (RUP)

Embracing Change: Feedback and Adaptation

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

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

(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

(R) UP Phases

(R) UP Disciplines

(R) UP Disciplines

(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

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

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

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

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

Agile Principles Review from Chapter 2 in Larman’s book

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