Crystal ClearSlide 2Crystal Clear assumptionsSlide 4Slide 5PeopleOther rolesPoliciesSlide 9Work ProductsSlide 11Requirements work productsDesign work productsTests and final systemMaking it workRequirementsCommon Object ModelSlide 181Crystal ClearThe Simplest Process That Can WorkApplied anthropologyCS427 26-2Crystal ClearGood, small teams have been putting out good software for decades, using thinking, communicating and delivering as their primary tools. Good, small teams do not scale up in number, so keep them small, permit them to move fast, do project tracking through their final results, not their intermediate thinking.CS427 26-3Crystal Clear assumptionsPeople are good at looking around. People are not as tidy as abstractions of them make them appear. Communication involves a lot more than the words spoken or written. Software construction is growing understanding of problem and solution.CS427 26-4Crystal Clear assumptionsActual, working processes are extremely complicated, hard to write down, hard to follow, and likely to be wrong when written down. Methodologists are prone to overcomplicate or embellish things.CS427 26-5Crystal ClearMake process as simple as you canRely on communication, individual skillSize: 4-6Essential moneys, but not lifeCS427 26-6Peoplesponsorsenior designeruserdesignersCS427 26-7Other rolesCan be separate people, or can be one of the designers, perhaps the senior designerbusiness expertcoordinator testerwriterCS427 26-8PoliciesUse increments for project staging, tracking by milestones and predicted risks Involve user directlyRequirements are annotated usage scenariosPeer code reviewsCS427 26-9PoliciesCode ownership modelRegression testing framework Code standardUser interface standardCS427 26-10Work ProductsNot a substitute for understandingunderstanding is primarywork products are secondaryA substitute for disciplineA “minimal set”CS427 26-11Work ProductsMethodologyTeam structureRelease sequenceViewing and release scheduleRisk listProject statusCS427 26-12Requirements work productsMission statementActor-goal pairsAnnotated use casesRequirements fileCS427 26-13Design work productsSystem designCommon object modelScreen draftsDesign sketchesSource codeMigration codeCS427 26-14Tests and final systemTest casesTest resultsPackaged systemUser manualCS427 26-15Making it workHow do you make sure people communicate?How do you decide on an ownership model, coding standard, etc?CS427 26-16RequirementsWhere do requirements come from?How are they recorded?How are they validated?How are they used?CS427 26-17Common Object ModelHow is the object model recorded?How is the object model created?How is the object model used?CS427 26-18Is XP just a special case of Crystal Light?Could a RUP project also be a Crystal Light project?Could a Bazaar project be a special case of Crystal
View Full Document
Unlocking...