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
<
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