1. CS5103 Software Engineering Lecture 02 More on Software Process Models

2. UTSA CS5103 2 Requirements engineering Validate prototype Design + build prototype Design and implementation Formalize requirements Integration The Prototype Model

3. UTSA CS5103 3  Looks like a two-cycle water fall model  Actually not, it is weak + strong  Improvements from waterfall Good: users involve more (by using prototype), reveal small errors in requirements / design Not solved: still can not handle frequent requirement changes Bad: prototype is discarded (waste of some effort, sometimes can be even more expensive than water fall) The Prototype Model

4. UTSA CS5103 4  Used frequently for requirement collection  Rarely used as a whole software development process In practice

5. UTSA CS5103 5 The Iterative Model Requirements engineering Design & Implementation & Integration Testing Solve these risks by infinite weak cycles

6. UTSA CS5103 6  Plan for change  Use the same steps as waterfall  But expect to iterate the whole process continually, and spend less effort on each iteration (weak cycles) Iterative Model

7. UTSA CS5103 7  Building tool for Java  First stable version 1.1 released in June 2000  Small developer group with 3-4 people  First prototype version released in one month  First stable version released in about half a year Example: Ant Project

8. UTSA CS5103 8  The Project evolves for 13 years  5770 issue (bugs & new features) reports from users, 2581 reports handled  7 more major versions in 13 years  Code commits 12,000 +  File modifications 50,000 +  Lines of code from 25.6k to 260k Example: Ant Project

9. UTSA CS5103 9  Cheaper to get a working software  Get the first version very fast  Users involve earlier  User can give feedback after the first version released  The software always work, though not perfect  Important in many cases, e.g., in competitions  Keep refining requirements, and accommodates changes  Cost for requirement changes/errors are small Advantages

10. UTSA CS5103 10  More bugs, sometimes may cause severe loss  Design is critical to make sure a change does not affect the whole system Disadvantages

11. UTSA CS5103 11  Most existing software projects use this model  Daily builds  Releases  Not suitable for systems that are costly for testing or very critical in quality  NASA programs  Military / Scientific / … In practice

12. UTSA CS5103 12  Time is the enemy of all software projects  Why time matters? Before we go to Extreme Programming, Let’s see an opinion on time

13. UTSA CS5103 13  The World Changes  requirement may change  Techniques become obsolete  Computing environment changes  Business Competition  Within a very short period of time, the world can be viewed as unchanged Time matters

14. UTSA CS5103 14  Extreme Programming still uses iterative process model, but goes to extreme Extreme Programming

15. UTSA CS5103 15  Small requirements  Testable user stories  Write test cases first  Simple design  Simplest design to pass test cases  Pair programming  Code refactoring frequently  Quick evaluation  Have customers involved to evaluate the software frequently Shorter cycles (2-4 weeks)

16. UTSA CS5103 16 Simple Requirements – User Stories

17. UTSA CS5103 17 Simple Requirements – User Stories

18. UTSA CS5103 18  Customer must describe how the stories are tested  With concrete data examples  Tests should be automated  Test case example 1. I create an account “savings” 2. I ask for list of accounts, I must obtain “savings” 3. I create an account “savings” again, I must get error 4. I check the balance the account “savings”, I must get 0 5. … Sample Requirements – test cases

19. UTSA CS5103 19  Just in time  Design and implement what you know now, not worry too much about future : future is unpredictable  No optimization for future  It is common that the optimization becomes unnecessary  Example: optimization to handle large input data, but later found the input changed (e.g., smaller format, or available in a summarized form) Simple design

20. UTSA CS5103 20  Programmer and Monitor  Pilot and Copilot  Or Driver and Navigator  Programmer types, monitor think about high-level issues  Disagreement points to design decisions  Pairs are shuffled Pair programming

21. UTSA CS5103 21  Result in better code  Instant code review  Monitor always notice the big picture  Knowledge and skill migration  Better coding styles  Reduces Risk  More people understands the code Advantages

22. UTSA CS5103 22  Stressful to relate to people all the time  Slows the programming  But save for time in maintenance  Waste of personnel  But less bugs, and more people can work on it, once bugs are revealed Why people don’t like

23. UTSA CS5103 23  Automatic comprehensive suite is required  Always keeps code working  Do regression testing before/after any major changes  Plan coding to allow frequent tests  Do not do too comprehensive changes, try to break them to smaller phases  Example: Add a product query feature for shopping software  Add list all products first  Add text query  Add filtering conditions one by one  Add sorting  … Regression Testing and Evaluation

24. UTSA CS5103 24  Use for:  Requirement prone to change  Easy to get testable requirements (often true in the maintenance phase on a software)  Need quick delivery (business competition)  In practice, frequently used in start-up companies  Not to use for:  Large group for large project (still can be used for components)  No highly-involved customers When to use extreme programming

25. UTSA CS5103 25  Software Requirements  Concepts  Process  Elicitation  Analysis  Specification  Validation  Elicitation Approaches Next Class

26. UTSA CS5103 26 Assignment I is online now: http://xywang.100871.net/CS5103.htm