Software Development Process Models From classical notions to more agile approaches Torsten Hahmann [email protected], BA8134 “Code & Fix” or “Cowboy Coding” 1) Write program 2) Test and fix program Problems: • program users not satisfied with program: definition phase (requirements & analysis) • fixing programs requires extensive program redesign: design phase • ill-prepared tests: test phase + implementation phase 29/09/06 Models of Software Development 2 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering What defines a development process? • Who does what at what time? • tasks • starting condition • documents (artefacts) received • output from previous stage • end conditions: finish criteria • final documents produced • input for next stage • order of tasks • who is involved • qualification • responsibility 29/09/06 Models of Software Development 3 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Development process models • Static process models • Waterfall model • V-Model • Incremental process model • Modern approaches • Iterative/Incremental process model • eXtreme Programming • Prototypic development • Test-driven development 29/09/06 Models of Software Development 4 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Waterfall model Software specification Design document 29/09/06 Models of Software Development 5 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Software specification I • 1. Goal • MUST • MAY • MUST NOT Software requirements • 2. Use of the product Analysis • Purpose • Target Group • Environment 29/09/06 Models of Software Development 6 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Example: Use Case diagram ehotel hotel reservation system inform <<actor>> book Pegasus Customer book book by book by online phone fax/email settle up ehotel clerk cancel cancel cancel by cancel by cancel online phone fax/email at Hotel Hotel (ehotel) (ehotel) (ehotel) clerk 29/09/06 Models of Software Development 7 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Software specification II • 3. Functionality • Can do a time estimate per „feature“ • Can track progress Software • 4. Data (persistent) requirements • 5. Performance Analysis • 6. User Interface • 7. Non-functional requirements & qualities Not too much details: -No implementation details (algorithms, data structure) -No technical solution (database, language, infrastructure) 29/09/06 Models of Software Development 8 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering V-model Use-case scenarios Acceptance Requirements test Validation Test cases System Analysis test Test cases Integration Design test Verification Coding Test Module (Modules) cases test 29/09/06 Models of Software Development 9 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Classical process models in a nutshell • problems of classical process models: • successive steps • document-driven • limited customers/users involvement • changing requirements in real world • pros: • customer gets a defined process (feasibility study) at the beginning of a project • can be good for large project-based developments • cons: • hard to think of all requirements at the beginning • documentation seems more important than program 29/09/06 Models of Software Development 10 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Scope • Project-based: contract between customer and contractor • clearly-defined overall goal • requirements: system functionality • non-functional requirements & qualities • e.g. large-scale software, e.g. logistics, industry, etc. • Commercial-of-the-shelf (COTS) product • constantly improving/changing releases • e.g. end-customer software (office, etc.) • Open-goal projects • e.g. academic research, prototypes, demos 29/09/06 Models of Software Development 11 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Incremental process model Initial definition complete software changes specification X=0 Design Define extended modefied model version X functionality X=X+1 changes partial architecture changes Code & test new ideas & wishes version X Product version X Use version X 29/09/06 Models of Software Development 12 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Agile development processes • Practices for every-day development required • focus on small and medium-sized software projects (small teams) • progressing, not spending too much time on design and specifications that might be useless • Agility • adaptable instead of predictable • “light-weight methodology” • minimizing risk by short-term focus (1-8 weeks) • being able to release a product after each cycle 29/09/06 Models of Software Development 13 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering „Agile Manifesto“ • Individuals and interactions over processes and tools • close, daily cooperation (possibly face-to-face) • self-organizing teams • trust in motivated individuals • Working software over comprehensive documentation • Working software is the principle measure of progress • Simplicity • Customer collaboration over contract negotiation • Responding to change over following a plan see http://www.agilemanifesto.org/ 29/09/06 Models of Software Development 14 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Development process models • Static process models • Waterfall model • V-Model • Incremental process models • Modern approaches (Agile) • eXtreme Programming • Prototypic development • Test-driven development 29/09/06 Models of Software Development 15 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering eXtreme Programming (XP) • Communication • questions instead of assumptions • „coach“ helps to overcome communication issues • Simplicity • try not to think of every eventuality in future • just implement what is really necessary • refactoring after iterations • Feedback • everybody gives and receives feedback • everybody is a little bit happier ☺ • Courage • try and compare alternative designs • no problem to throw away code 29/09/06 Models of Software Development 16 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Planning in XP • Plan by priorities (feature, defect tracking) • Plan for the next iteration • Take responsibility, do not delegate it • Use techniques like “story cards” 29/09/06 Models of Software Development 17 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Methods of XP • Pair programming • Best form of communication • Coding and Thinking • „Two pairs of eyes see more“ • Testing • No feature without test • Independent, automated tests • Extensive refactoring after each iteration • Strict coding conventions 29/09/06 Models of Software Development 18 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Software Prototypes • Software prototype different from „Product prototype“ • Help to elicit requirements • Paper prototypes (GUI) • Fake GUI • Basis for discussion • Experimental: can try & show alternatives • Practical experience & feasibility 29/09/06 Models of Software Development 19 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Categories of prototypes • Demonstration • for project acquisition • Explorative prototype • for analysis • Experimental prototype • evaluate design alternatives • show technical feasibility • Pilote system (evolutionary) • e.g. selected customer 29/09/06 Models of Software Development 20 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Horizontal vs. vertical prototype vertical prototype horizontal prototype 29/09/06 Models of Software Development 21 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Explorative Prototyping • Paper • Usability Engineering • try to find a good user interface design with prospective users • use: paper, post-it notes, colors • one developer: „plays“ software • one developer: takes notes • Software • fake GUI (Visual Basic, C#) • discuss it with customers • what do they expect will happen • what do they miss 29/09/06 Models of Software Development 22 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Test-driven development (TDD) • Principle 1: Test-First-Development (TFD) • For each feature: • write test first (including automation) • code afterwards • Principle 2: Refactoring • try to remove duplicate code • essential for keeping code simple • improve code quality • make it maintainable 29/09/06 Models of Software Development 23 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Test-driven development If it's worth building, it's worth testing. If it's not worth testing, why are you wasting your time working on it? 29/09/06 Models of Software Development 24 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Test-driven development (TDD) • Advantages of TFD • immediate checking gives more confidence • can write several tests at the beginning of each release cycle • give a good overview of remaining effort • forces developers to write tests • But requires: Refactoring • otherwise software becomes unmaintainable TDD = TFD + Refactoring 29/09/06 Models of Software Development 25 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering When using agile methods? • Previously just „Code & Fix“ • A little bit more order, planning • Easier step than introduction of classical model • Small- & Medium-sized teams • About a dozen developers • Approaches • Volatile requirements • Motivated developers • Customers wish to be integrated 29/09/06 Models of Software Development 26 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering Classical vs. agile processes • Classical processes (anticipating) • Disciplined, detailed plan • Emphasis on long-term planning Focus: process Plan-driven • Agile processes (adaptive) • Compromise between no and too much process • Short-term focus • Less documentation, code is documentation Focus: humans Agile 29/09/06 Models of Software Development 27 Torsten Hahmann CSC444H, Fall 2006 – Software Engineering.