Software Development Process Models

Transcription

1 Software Development Process Models From classical notions to more agile approaches BA8134

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

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

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

5 Waterfall model Software specification Design document 5

6 Software specification I 1. Goal MUST MAY MUST NOT Software requirements 2. Use of the product Purpose Target Group Environment Analysis 6

7 Example: Use Case diagram ehotel hotel reservation system inform book <<actor>> Pegasus Customer book online book by phone book by fax/ settle up ehotel clerk cancel Hotel clerk cancel at Hotel cancel online (ehotel) cancel by phone (ehotel) cancel by fax/ (ehotel) 7

8 Software specification II 3. Functionality Can do a time estimate per feature Can track progress Software requirements 4. Data (persistent) 5. Performance 6. User Interface 7. Non-functional requirements & qualities Analysis Not too much details: -No implementation details (algorithms, data structure) -No technical solution (database, language, infrastructure) 8

9 V-model Requirements Use-case scenarios Acceptance test Validation Analysis Test cases System test Design Test cases Integration test Verification Coding (Modules) Test cases Module test 9

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

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

12 Incremental process model Initial definition changes complete software specification X=0 Design version X X=X+1 modefied model Define extended functionality changes partial architecture changes Code & test version X new ideas & wishes Product version X Use version X 12

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

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

15 Development process models Static process models Waterfall model V-Model Incremental process models Modern approaches (Agile) extreme Programming Prototypic development Test-driven development 15

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

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

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

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

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

21 Horizontal vs. vertical prototype vertical prototype horizontal prototype 21

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

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

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

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

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

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