design intent in an agile context - university of texas at...

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



Definitions of IntentFunctional Intent – WHAT

Functional RequirementsDesign Intent – HOW

Scenarios / Use-casesContractsObligations

Design Rationale – WHYCriteriaPlansAlternativesNon-functional Requirements (?)

4



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



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



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



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



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



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



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



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



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



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



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



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



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



The Agile Problem

Scalability

Research Question: How to increase scalability of agile software development without creating process burdens

18



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



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



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



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



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



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



XP Practices OverviewXP was designed and evolved so that the practices are interdependentHowever, they were developed separately and offer benefits independently

25



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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

design intent in an agile context - university of texas at...

Documents