COMP 350 Object Oriented Analysis and Design Lecture

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

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] Domain Model: diagram(s) showing domain concepts, attributes, and associations 4

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

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

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 7

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) 8

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