design intent in an agile context - university of texas at...
TRANSCRIPT
1
Architecture and Design Intent
© 2006, Paul S Grisham
Lecture 10.1
EE 382V
Design Intent in an Agile ContextPart I
Paul S [email protected]
Feb. 16, 2006
2
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
Goals of this LectureProvide an overview of the Agile software development philosophyProvide an overview of Extreme Programming (XP)Consider the role of process, organization, and artifacts in software developmentExplore opportunities to capture and utilize design intent and design rationaleEnumerate design intent strategies for Agile software developmentIntroduce the context for the lectures for the remainder of the semester
3
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
Definitions of IntentFunctional Intent – WHAT
Functional RequirementsDesign Intent – HOW
Scenarios / Use-casesContractsObligations
Design Rationale – WHYCriteriaPlansAlternativesNon-functional Requirements (?)
4
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
How Do We Use Intent?Replication
Use existing patterns and processes to build something newStrategies, Patterns and Idioms
Be sure we are replicating the important thingsCutting off the end of the ham
ReuseInclude legacy modules in new systems
Identify opportunities for reuseMake sure we use those modules correctlyIdentify assumptions about usage
ModificationPerform risk analysis
Explore semantic and operational dependencies
MaintenanceIdentify out-of-date or invalidated assumptions
5
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
Outline of this LectureQuick ReviewAgile Software DevelopmentExtreme Programming (XP)Test-Driven DevelopmentCommunication and DocumentationIterative and Adaptive DesignAgile MaintenanceConcepts for Intent-Driven Development in an Agile context
6
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
What is Agile Software Development?A combination of old and new ideas to respond to:
Customer NeedsChanging Requirements (See above)
“Agile Software Development” includes several techniques that feature:
Close collaboration between technical and business staffFace-to-face interactionsFrequent demonstration of working functionalityFrequent delivery of business valueSelf-organizing teamsCommitment to innovative craftsmanship
7
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
The Agile ManifestoWe 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/
8
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
Characteristics of Plan-Driven Development
Goal: Make process and product predictableDetailed planning and predictive models
Do we have reliably predictive models in Software?Can a customer understand a software system from a model?
Inspired by engineering methods in other fieldsPhysical engineering disciplines have well-understood functional concepts
A bridge is a bridge. What is a software bridge?Engineering models are generally comprehensibleEnvironmental requirements change slowly
Assume separation between design and constructionDesign is creative and riskyConstruction is predictable and repeatableTreat programming as construction
http://www.martinfowler.com/articles/newMethodology.html
9
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
The Cost of ChangeConventional 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?
10
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
What If?
Cost of adding a feature did not increase significantly over time?Requirements could be iterative and feature-drivenWe could defer long-range design decisions and focus on delivering functionality nowCan we separate essential complexity from process complexity?
11
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
Sources of ChangeRequirements Uncertainty (Nidumolu, 1996)
Instability – Changes over the life of the projectEnvironmental changes – business driversTechnology changesScope changes
Diversity – Differences between stakeholdersAnalyzability – How requirements can be reduced to objective specifications
Requirements errors that cause faults (Perry, ESEC93)Incomplete / Omitted RequirementsAmbiguous RequirementsLack of Knowledge
Additional FactorsEmergent dependenciesExperimental / Conditional RequirementsBrooks’s “Plan to throw one away”
12
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
Assumptions About UncertaintyPlanned Development assumes requirements are:
CorrectCompleteConsistentAnalyzable – For correctness, consistency, completenessUnderstood – No ambiguitiesStatic – Unchanging
None of these things are true…everSolutions:
Disallow change – Build the system as contracted, even if it no longer meets the customer’s needsAllow 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
13
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
Responding to ChangeRequirements Instability
Problem: Requirements change before system is deployedSolution: Deploy system quickly to maximize business valueSolution: Evaluate which dimensions are fluid Solution: Plan for the unforeseen
Requirements DiversityProblem: Different users have competing requirementsSolution: Identify users/stakeholdersSolution: Stakeholder/Viewpoint analysisSolution: Negotiate and explicit documentation
Requirements AnalyzabilityProblem: Some requirements are hard to quantifySolution: ???
14
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
Responding to Change (2)Incomplete/Omitted Requirements
Solution: Rigorous interview processSolution: Use of domain models to identify incompleteness
Ambiguous RequirementsSolution: Formal requirements models and analysisSolution: Stakeholder sign-off on requirements models
Lack of KnowledgeSolution: ???How do you ask what you don’t know?
Emergent Dependenciese.g., Requirements inherited from choice of tech. solutions
Experimental / Conditional RequirementsRequirements which depend on how solutions work in practicee.g., Cumulative performance measures
15
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
Characteristics of Agile DevelopmentAgile Methodologies
Increase adaptability by:Increasing communicationIncreasing feedbackDecreasing bureaucracyDecreasing iteration length
Recognize the difficulty in separating design and construction for softwareRecognize the extremely high rate of change in software requirementsStrive for asymptotic cost of late changes
16
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
The Agile SolutionRequirements Instability
Short, feature-driven iterations of partial functionalityMaximized deployed business value
Requirements DiversityMake ongoing customer interaction part of the process
Requirements AnalyzabilityDe-emphasize formal requirement modelsPrefer working understanding and concrete evaluation
Incomplete/Omitted Requirements, Lack of Knowledge, Ambiguous Requirements
Bring the customer into the development teamEmergent Dependencies, Conditional Requirements
Short iterations for more frequent risk analysis
17
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
The Agile Problem
Scalability
Research Question: How to increase scalability of agile software development without creating process burdens
18
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
Agility and DisciplineProcess Maturity
Ad Hoc -> Repeatable -> Defined -> Managed -> OptimizingProcess advocates equate Agile with Ad HocBut Agile is highly disciplined
Requires personal and team disciplineNo process-enforced discipline
Process has become ritualized, inward-lookingProcess is “process conformance” drivenAgile is “customer satisfaction” drivenProcess is “contract” orientedAgile is “service” oriented
19
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
Agility and Discipline (2)Process is a religionAgile is a philosophyE.g., Documentation:
Process:Everything is documentedDocumentation is continuously maintainedTraceability is essential
Agile:Treat documentation as a toolEvaluate the cost of creation and maintenanceDiscard it when it ceases to be usefulBuild systems with clear designs
So agile development efforts don’t use documentation, right?Actually, many agile projects use documentation
LightweightLong-lifespanEasy to maintain, if necessary to keep
20
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
Agile Software Development “Methods”Agile Database Techniques
Scott AmblerAM (Agile Modeling)
Scott AmblerAdaptive Software Development
Jim HighsmithCrystal
Alistair CockburnFDD (Feature-Driven Development)
Jeff De Luca, Peter Coad(Contributor)
DSDM (Dynamic Systems Development Method)
Industry Consortium (Oracle, British Airways, AmEx, etc.)
Lean Software DevelopmentMary Poppendieck, TomPoppendieck
ScrumKen Schwaber, Jeff Sutherland, Mike Beedle(Contributor)
TDD (Test-Driven Development)
Kent BeckXbreed
Mike BeedleXP (Extreme Programming)
Kent Beck, Ward Cunningham, Ron Jeffries
21
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
Lecture OutlineQuick ReviewAgile Software DevelopmentExtreme Programming (XP)Test-Driven DevelopmentCommunication and DocumentationIterative and Adaptive DesignAgile MaintenanceConcepts for Intent-Aware Tools in an Agile context
22
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
Extreme Programming (XP)XP is the most visible (and most viable?) form of agile software developmentDeveloped adaptively on the Chrysler C3 project by Kent Beck, et. al.Consists of several interacting techniques
Compared to Crystal, which emphasizes adaptable subsets of techniques
Emphasizes technical and collaborativeCompared to Scrum, which emphasizes team management
Core techniques updated continuouslyMost empirical research (and criticism) of agile software development features XP practices
Pair Programming, On-Site Customer, Refactoring
23
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
What’s So Extreme?XP takes ideas it as far as they can goIf testing is good, write tests firstIf code inspections are good, conduct them continuouslyIf requirements documentation helps programmers understand the customer, put the customer in the middle of the processIf prototyping is good, build working functionality on short iterations
24
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
XP Practices OverviewXP was designed and evolved so that the practices are interdependentHowever, they were developed separately and offer benefits independently
25
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
XP Core Practices
Fine-Scale FeedbackTest-Driven DevelopmentThe Planning GameThe Whole TeamPair Programming
Continuous ProcessContinuous IntegrationDesign ImprovementSmall Releases
SharedUnderstandingSimple DesignSystem MetaphorCollective Code OwnershipCoding Standard
Programmer WelfareSustainable Pace
26
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
XP Feedback PracticesTest-Driven Development*
Write programmer (unit) tests an customer (acceptance) tests before planning a solution
The Planning Game*Process of selecting development priorities for an iteration
The Whole TeamBringing a customer representative into the development workspaceA single customer unifies requirements diversity but may be impracticalA team of customer specialists may not integrate with the development staff
Pair Programming*Continuous design and development feedbackArgumentative design space exploration
27
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
XP Process ActivitiesContinuous Integration
The system should pass all tests and compile at all timesDifferent from “Releases”
Design Improvement*RefactorFix “bad-smelling” codeEliminate unused code
Small ReleasesA Release comes at the end of a set of iterationsDeployable functionalityShort iterations guarantee close progress monitoringShort release cycles provide additional functionality
28
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
XP Comprehensibility PracticesSimple Design*
Code should be readable without commentsDon’t build for functionality you don’t know aboutFunctionality should not be repeated
System Metaphor*Instead of a solution-space architectureA story of how the system worksLeast developed, adopted core technique
Collective Code OwnershipEach developer works on each part of the systemNo/Little specializationAny developer can make a change to any part of the system
Coding Standard*Formatting, Naming, Idioms, Patterns
29
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
XP 2nd Ed. and Corollary PracticesSit Together
Common, open development workspace with no partitionsUser Stories
Like a use-case or scenarioIncremental DesignAsk the Code
Code should be readable, intent inferableSpike Solution
Feature oriented developmentNeither top-down or bottom-up
Lazy Optimization and Early ProfilingConstant Velocity
Make progress every dayNo overtime death marches
30
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
Lecture OutlineQuick ReviewAgile Software DevelopmentExtreme Programming (XP)Test-Driven DevelopmentCommunication and DocumentationIterative and Adaptive DesignAgile MaintenanceConcepts for Intent-Aware Tools in an Agile context
31
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
Test-Driven DevelopmentCreate test cases up-front, then write code that causes the test case to passTwo kinds of tests:
Programmer (Unit) TestSpecific test of a moduleDrives the design and implementation in the solution space
Customer (Acceptance) TestScenario specificationTests conformance to end-user (black-box) requirements
Relies on developer and team discipline rather than process discipline
32
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
TDD ProcessThink about what and how to test
Yes, there is a plan!Write a small initial test
Explore the interfaceWrite enough code to compile and failWrite enough code to pass (Simplest design possible)
Write the next testDevelop the functional requirementsWrite code to pass all testsRefactor if necessaryRepeat
If you want to add code to an existing module:Write a test that fails under the current implementationWrite code to pass all the tests
33
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
Benefits of TDDQuality
Up-front testing means that QA is not an afterthoughtUsing an automated framework leads to continuous testing
MaintenanceDesign tests become regression tests across refactorings
Project ManagementAcceptance tests provide feedback on progress for iteration
DocumentationA test suite is a kind of “programmer’s intent” model“The act of writing tests first is an act of discerning between design decisions” (Robert C. Martin)
Design QualityIncremental implementation -> incremental conceptual modelTestable code is decoupled, allows for ease of refactoring
34
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
TDD IdiomsStarter Test
Not a realistic test, doesn’t do anythingWhere does operation belong?What is its interface?
Explanation TestA test that explains how an operation should workDrives design and development
Learning TestA test that explores legacy codeA type of integration contract
Regression TestFacilitates impact of change analysisConstrain refactoring activities
35
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
TDD PatternsSmall Tests
Making code testable leads to simple, comprehensible designsMock Objects
Implement top-down, deferring design until the requirements are better understoodCreate stubs to simulate functionality until then
Self-ShuntAllow test case to simulate external interactionsTests read betterExplores interface design
LoggingForced error conditionsLeave the last test broken
It’s what you were working on when you stopped for the day
36
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
Approaches to TestingBlack Box Testing
Input Coverage – All combinations of legal input valuesExpensive - exponential growth of input spaceExcessive - congruency of groups of inputsIncomplete – out of bounds/illegal inputs
White Box TestingData-flow, control-flow coverageAttempt to create minimal, adequate test suiteInflexible – small code changes render test suite inadequateUndecidable – due to loops and unreachable code
Test-First TestingCode and data structures are driven by the test cases that necessitate themDesigned for testability, reachabilityThe goal is to create code that can be tested, not tests that can exercise codeTest reflect design intent, not just exhaustive coverage
37
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
Testing and SpecificationsTypes of specifications
StaticCompiler-enforced language constructs
Isolated TestingSpecialized execution to explore specific conceptsNot complete on inputs, data flow, control flow
Runtime checkingAssertionsDesign by ContractNot necessarily complete
Formal and Semi-formal specification with generationDefine a complete specificationGenerate assertions, test cases, etc. to check correctnessMay be white-box (control flow, data flow)Or black-box (input coverage)
38
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
TDD ObservationsTest-Driven Development is an example of how Agile is not Ad HocCreates a kind of documentation artifact which is:
Useful for the life of the projectAutomatableClearly tied to the source code (i.e., the design)
Choice of test cases impacts designBut no research yet on how test selection impacts iterative design qualities
Test cases provide a rudimentary intent and change rationale model
But still desiccated like source codeTDD is non-methodical and tests are difficult to check for consistency, completeness, etc.
39
Architecture and Design Intent Lecture 10.1
© 2006, Paul S Grisham EE 382V
The Plan for Next TimeOrganizational memory and the social patterns of XPThe cost of producing, maintaining documentationThe dramatic tension of agile design
YAGNI vs. DOGBITEGuiding refactoring through design rationaleProgrammatic approaches to specifying design intentMaintainance of test suitesIdeas for a prototype implementation of an intent-aware, agile-friendly IDE