Principles & Practices of Software DevelopmentIn This TalkOutlineBackgroundBackgroundSimplified OrganizationRequirements & EstimationRequirements & EstimationFirst Solution(!) ResultsProduct ManagementSecond SolutionMore DocumentationThird(!) Solution ResultsInterleaved StagesInterleaved StagesOngoing ChallengesLessons LearnedTerminologyTerminologyTerminologyTerminologyTerminologyTerminologyTerminologyOur GoalsPrinciples, Problems and PracticesPrinciples, Problems and PracticesDomain ExpertiseDomain ExpertiseChanging RequirementsChanging RequirementsSpecification CostSpecification CostLittle or No Specification?Unreliable MemoryUnreliable MemoryAdequate SpecificityAdequate SpecificityDetailed Specification?Competing PrinciplesClear StatementClear StatementIncremental & IterativeDriving Force: Ship DateReal UseReal Use… & Incremental ProcessesSummaryPrinciples & Practices Principles & Practices of Software Developmentof Software DevelopmentDaniel Spoonhower Daniel HuttenlocherCarnegie Mellon University Cornell UniversityPittsburgh, PA Ithaca, NYIntelligent Markets, Inc.San Francisco, CANew York, NYIn This TalkIn This Talk•Purpose– Relate some of our experience– Introduce way of talking about software development• Language for dialogue•Audience• Not in this talk– Breadth of experiences– Scientific studyOutlineOutline• Background• Experience: Requirements & Estimation• Terminology: Principles, Problems and Practices– Some examples & comparisons– Things to look out for (e.g. competing Principles)• Relating Principles to experienceBackgroundBackground• Our task – system for trading convertible bonds• Our (prior) experience• Our team – best people we’d ever worked with• Our challenge:– High reliability– Complex (user) requirements– Technically challenging– Demanding scheduleBackgroundBackground• Your experiences?– Written software (or just programs)?• Your teams?– Size, project duration?• Your challenges?Simplified OrganizationSimplified OrganizationMarketingProduct ManagementQACustomersEngineeringRequirements & EstimationRequirements & EstimationRequirements & EstimationRequirements & Estimation• First implementation– Started with partial outsourced version– Screen shots used as requirements• No product management– Responsibilities shared by marketing & engineering• Internal customer– Frequent delivery, rapid feedbackFirst Solution(!) ResultsFirst Solution(!) Results• Sparse documentation– Both requirements and implementation– Verbally conveyed = many changes– Written by developers• Success!– Very flexible, agile process– System launched in 8 months– Many lessons learnedProduct ManagementProduct Management• Second solution–Now enterprise software not service– External customers– Demanded clearer definition of product• Feature by feature description– Hierarchical, outline format• Specification change process– Manage document updates– Understand effects of changesSecond SolutionSecond Solution•Problems:– Lacked coherence– Serving many different parts of the company• Marketing, product design, engineering– Didn’t convey understanding– Delivered on-time but with poor set of featuresMore DocumentationMore Documentation• Third solution (attempted, not fully implemented):– Several levels of documentation, one for each use, e.g.• MRD (Marketing)• HLD & DLD (Product Management and QA)• TD (Engineering and QA)• Conventional big company approachThird(!) Solution ResultsThird(!) Solution Results•Problems:– Lots of effort, difficult to manage• Many dependencies, gated tasks– Skew between different documents– Focus on documents more than on developmentInterleaved StagesInterleaved Stages• Our final solution: incremental!– Alternate requirements with estimates– Start with quick, rough ideas; work towards details– Drive to ship date – cut features to do soInterleaved StagesInterleaved Stages• Requirements– Business need, short descriptions, detailed functional and UI specs– Reprioritize as estimates established• Several levels of specs and estimates– Day-week-month, “factor of 2 guess”, then +/- 25% with small tasks– More specific estimates derived from more detailed specsOngoing ChallengesOngoing Challenges• “Delta” specifications – note changes to product– Need both complete and difference spec• Product team gaining understanding of implementation– Can find more workable solutions– More difficult to think independently• Meet the needs of testing– Function point combinations– Workflow sequencesLessons LearnedLessons Learned• Communication is important– Business needs Æ engineering– Estimates & implementation Æ PM• Conflicting forces:– Include the best features– Ensure maintainability– Ship on time• Make sure the process focuses resources on getting product doneTerminologyTerminologyTerminologyTerminologyPrincipleA comprehensive and fundamental law, doctrine, or assumption. Principles may be universal, or they may apply only to certain types of projects.TerminologyTerminologyPrincipleA comprehensive and fundamental law, doctrine, or assumption. Principles may be universal, or they may apply only to certain types of projects.•Predictive• Broadly applicable• Relates to experience• Expands understandingTerminologyTerminologyProblemSomething that can get in the way of rapidly developing high quality software that meets customer needs, while having fun doing it.TerminologyTerminologyProblemSomething that can get in the way of rapidly developing high quality software that meets customer needs, while having fun doing it.• Observable• Describes a state of being• To be identified, minimized, avoided, solvedTerminologyTerminologyPracticeA way of acting or working so as to avoid or to alleviate problems in developing software.TerminologyTerminologyPracticeA way of acting or working so as to avoid or to alleviate problems in developing software.• Most importantly: an action• Still abstract (as opposed to implementation)• Focus of many methodologiesOur GoalsOur Goals• Explicitly enumerate• Study interactions• Compare resultsBUT……keep them separate!PrinciplesProblemsPracticesPrinciples, Problems and Principles, Problems and PracticesPracticesPrinciples, Problems and Principles, Problems and PracticesPractices• Seen some Problems and Practices related to requirements and
View Full Document
Unlocking...