1CS 350, slide set 12M. OverstreetOld Dominion UniversityFall 2005Final Exam Comprehensive Take-home part & in-class part Final is 8:30 - 11:30, Tuesday, Dec. 13 Take-home due at start of in-class finalRefs 1. http://www.agilealliance.org Agile alliance manifesto:• Individuals and interactions over processes andtools• Working software over comprehensivedocumentation• Customer collaboration over contract negotiation• Responding to change over following a plan XP series of books from Addison-Wesley McBreen: Questioning Extreme Programming2Topic: Views on ExtremeProgramming (XP) Loved by programmers Factor 6 improvement in productivity! No documentation needed: code isdocumentation If not, bad code. Recode. Glorifies “cowboy coders” Hackers paradise Sets software engineering back 30 years! I.e., lots of flame wars!Agile Programming Small agile team – 5 to 10 Dominated by people with extensive project experience Can only tolerate a few inexperienced enthusiasticbeginners Regular delivery schedule – incremental systemdelivered to customer every few weeks Customer co-located with development team Customer decides what to include in nextincrement “Must have,” “should have,” “can have” With advice from team (feasibility, difficulty)XP & CMM Characterizations - 1 In 60’s, big software systems werereplacing existing manual systems What was needed was pretty wellunderstood Today’s systems (web apps, e.g.)are fundamentally different. Requirements cannot be known at start3CMM & XP characterizations – 2(as seen by XP advocates) CMM designed by managers Addresses management needs Traditional SE processes minimize risk of makingmistakes even at cost of making proceed at glacial pace CMM is based on fear: Don’t let what happened on last project happen on thisone Need reviews, approvals, committees, forms to avoidproblems XP designed by programmers Based on Smalltalk development systems• Programming env. developed at Xerox Parc• Apple stole interface from Xerox for Lisa (before Mac)• Windows stole interface from Apple. Apple sued. & lost Addresses programmer needsHow to decide what’sbetter? Fact: Hawthorne Effect (Western Elec. plant inChicago, 1930’s) Beginning of industrial engineering Goal: improve worker productivity• Increase light levels: prod. up• Give rest breaks: prod. up• Decrease light levers: prod. up• Decrease again: prod. up• Put light levels back to original: prod. up What’s going on? Expectations effect results? Excitement of participating in a study? Knowing people are watching? Makes medical experimentation more difficult!Perceived problem: change expensive,get it right the first time Do exhaustive analysis; build system so that allforeseeable changes made with configurationchanges Smalltalk problem: programmers tended to build awonderful environment for developing a product ratherthan developing a product. Do analysis; build system so that likelychanges can be made easily Write components so that dependencies areminimized; easy to change parts as necessary Focus on getting current version shipped;changes, if needed, will come from anotherbudget4XP influenced byprogrammer worries: Schedule slippages Cancelled project System goes sour Defect rate Problem misunderstood World changes Feature-rich software Staff turnover If you’ve been part of a failed project,damages your career for a long timeXP “solutions” - 1 Schedule slippages Deliver new version every few weeks Cancelled project Get product in hands of users System goes sour Tight delivery schedule Tight coupling with customer on site Feedback from usersXP “solutions” - 2 Defect rate Extreme unit testing Problem misunderstood Customer co-located with developmentteam World changes Customer co-located with developmentteam5XP “solutions” - 3 Feature rich software(Fun for inexperienced programmers; feared byexperienced programmers) Customer selects features based on need Staff turnover(More concern about other people leaving) People stick with exciting successful projects• They’re challenging and funXP life cycle - 1 Exploration - short period. teamexperiments with technology to gainconfidence in estimating what’sneeded to satisfy customer desires Planning - very short; team createsinitial release plan for the date atwhich the smallest, most valuablecapabilities will be doneXP life cycle - 2 Iteration to First Release - teamworks in short iterations to deliverytested functionality. Every 3 or 4releases, release plan (step 2) isupdated to reflect team performanceand changed requirements Productizing – End game of initialiteration, leads to 1st release ofproduction version6XP life cycle - 3 Maintenance – normal state of an XPproduct. regular iterations resulting innew and changed features for productionuse Death of project – customer cannotthink of any more features (or unwillingto pay for more). team writesdocumentation needed for futureenhancements then is disbandedWhat’s XP missing? No efficiency gains through specialization Part of the fun of XP is that every teammember designs, codes, tests No detailed project plans How do we know when we’re 50% done? No comprehensive documentation toensure auditability and traceability (Almost) no second set of eyes checkingpeople’s work Though XP uses “Pair Programming:” peoplework in pairsOther developmentmethodologies Game development Driven by predictable delivery of a stableproduct Why? Marketing budgets See http:/www.gamasutra.com Open source (linux primary example) No shortage of developers People develop many competing, duplicateitems Management committee then selects the best7Is XP the solution? Sometimes. Programmers really like it. What if you need 200 people? What about software to fly new Airbus orBoeing aircraft? Requirements relatively well understood Many organizations will not put customeron site with developers, too expensive