Lecture 10 1 Architecture and Design Intent Design Intent in an Agile Context Part I Paul S Grisham grisham mail utexas edu Feb 16 2006 2006 Paul S Grisham EE 382V 1 Lecture 10 1 Architecture and Design Intent Goals of this Lecture Provide an overview of the Agile software development philosophy Provide an overview of Extreme Programming XP Consider the role of process organization and artifacts in software development Explore opportunities to capture and utilize design intent and design rationale Enumerate design intent strategies for Agile software development Introduce the context for the lectures for the remainder of the semester 2006 Paul S Grisham EE 382V 2 Lecture 10 1 Architecture and Design Intent Definitions of Intent Functional Intent WHAT Functional Requirements Design Intent HOW Design Rationale WHY Scenarios Use cases Contracts Obligations Criteria Plans Alternatives Non functional Requirements 2006 Paul S Grisham EE 382V 3 Lecture 10 1 Architecture and Design Intent How Do We Use Intent Replication Use existing patterns and processes to build something new Strategies Patterns and Idioms Be sure we are replicating the important things Cutting off the end of the ham Reuse Include legacy modules in new systems Identify opportunities for reuse Make sure we use those modules correctly Identify assumptions about usage Modification Perform risk analysis Explore semantic and operational dependencies Maintenance Identify out of date or invalidated assumptions 2006 Paul S Grisham EE 382V 4 Lecture 10 1 Architecture and Design Intent Outline of this Lecture Quick Review Agile Software Development Extreme Programming XP Test Driven Development Communication and Documentation Iterative and Adaptive Design Agile Maintenance Concepts for Intent Driven Development in an Agile context 2006 Paul S Grisham EE 382V 5 Lecture 10 1 Architecture and Design Intent What is Agile Software Development A combination of old and new ideas to respond to Customer Needs Changing Requirements See above Agile Software Development includes several techniques that feature Close collaboration between technical and business staff Face to face interactions Frequent demonstration of working functionality Frequent delivery of business value Self organizing teams Commitment to innovative craftsmanship 2006 Paul S Grisham EE 382V 6 Lecture 10 1 Architecture and Design Intent The Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it Through this work we have come to value Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is while there is value in the items on the right we value the items on the left more http agilemanifesto org 2006 Paul S Grisham EE 382V 7 Lecture 10 1 Architecture and Design Intent Characteristics of Plan Driven Development Goal Make process and product predictable Detailed planning and predictive models Inspired by engineering methods in other fields Do we have reliably predictive models in Software Can a customer understand a software system from a model Physical engineering disciplines have well understood functional concepts A bridge is a bridge What is a software bridge Engineering models are generally comprehensible Environmental requirements change slowly Assume separation between design and construction Design is creative and risky Construction is predictable and repeatable Treat programming as construction http www martinfowler com articles newMethodology html 2006 Paul S Grisham EE 382V 8 Lecture 10 1 Architecture and Design Intent The Cost of Change Conventional Wisdom The cost of correcting a requirements fault increases exponentially over time What drives these costs Inflexible designs Antiquated programming techniques No silver bullet Cost to iterate the waterfall Process activities How are they measured Compared to original cost to implement What counts as a requirements fault 2006 Paul S Grisham EE 382V 9 Lecture 10 1 Architecture and Design Intent What If Cost of adding a feature did not increase significantly over time Requirements could be iterative and feature driven We could defer long range design decisions and focus on delivering functionality now Can we separate essential complexity from process complexity 2006 Paul S Grisham EE 382V 10 Lecture 10 1 Architecture and Design Intent Sources of Change Requirements Uncertainty Nidumolu 1996 Instability Changes over the life of the project Environmental changes business drivers Technology changes Scope changes Diversity Differences between stakeholders Analyzability How requirements can be reduced to objective specifications Requirements errors that cause faults Incomplete Omitted Requirements Ambiguous Requirements Lack of Knowledge Additional Perry ESEC93 Factors Emergent dependencies Experimental Conditional Requirements Brooks s Plan to throw one away 2006 Paul S Grisham EE 382V 11 Lecture 10 1 Architecture and Design Intent Assumptions About Uncertainty Planned Development assumes requirements are Correct Complete Consistent Analyzable For correctness consistency completeness Understood No ambiguities Static Unchanging None of these things are true ever Solutions Disallow change Build the system as contracted even if it no longer meets the customer s needs Allow change with cost Iterate lifecycle with impact analysis and forward and reverse traceability cost effort Adopt adaptive techniques which facilitate change through goal prioritization and communication 2006 Paul S Grisham EE 382V 12 Lecture 10 1 Architecture and Design Intent Responding to Change Requirements Problem Solution Solution Solution Requirements change before system is deployed Deploy system quickly to maximize business value Evaluate which dimensions are fluid Plan for the unforeseen Requirements Problem Solution Solution Solution Instability Diversity Different users have competing requirements Identify users stakeholders Stakeholder Viewpoint analysis Negotiate and explicit documentation Requirements Analyzability Problem Some requirements are hard to quantify Solution 2006 Paul S Grisham EE 382V 13 Lecture 10 1 Architecture and Design Intent Responding to Change 2 Incomplete Omitted Requirements Solution Rigorous interview process Solution Use of domain models to identify incompleteness Ambiguous Requirements Solution Formal requirements models