ECE450 – Software Engineering II

1. ECE450 – Software Engineering II Today: Lifecycles and Methodologies ECE450 - Software Engineering II

2. Lifecycle of Software Projects • Lifecycle models are useful to compare project management strategies in abstract terms • Birds-eye view strategy • Detect strengths and weaknesses • ... but reality is always more messy ECE450 - Software Engineering II

3. perceived need requirements design code test integrate Waterfall Modelmaterial adapted from Steve Easterbrook • View of development: • A process of stepwise refinement • High-level management view • Problems: • Static view of requirements (ignores volatility) • Lack of user involvement once spec is written • Unrealistic separation of spec from design • Doesn’t accomodate prototyping, reuse ECE450 - Software Engineering II

4. system requirements system integration Level of abstraction software requirements acceptance test preliminary design software integration “test and integrate” “analyze and design” detailed design component test code and debug unit test time V Modelmaterial adapted from Steve Easterbrook ECE450 - Software Engineering II

5. Prototyping Modelmaterial adapted from Steve Easterbrook • Prototyping is used for: • Understanding the requirements for the user interface • Examining feasibility of a proposed design approach • Exploring system performance issues • Problems • Users treat the prototype as the solution • A prototype is only a partial specification ECE450 - Software Engineering II

6. design design design design code code code code test test test test integrate integrate integrate integrate O&M O&M O&M O&M Release 1 Incremental development (each release adds more functionality) Requirements release 2 release 3 release 4 version 1 reqts reqts design design code code test test integrate integrate O&M O&M lessons learnt version 2 lessons learnt Evolutionary development (each version incorporates new requirements) version 3 reqts design code test integrate Phased Modelsmaterial adapted from Steve Easterbrook ECE450 - Software Engineering II

7. Determine goals, alternatives, constraints Evaluate alternatives and risks constraints4 risk analysis4 constraints3 risk analysis3 Constr- aints2 alternatives4 risk analysis2 alternatives3 Altern- atives2 alternatives constraints risk analysis1 budget4 budget3 budget2 budget1 prototype1 prototype2 prototype3 prototype4 concept of operation software requirements detailed design requirements, lifecycle plan software design development plan validated requirements code integration and test plan validated, verified design unit test Plan Develop and test system test acceptance test implementation plan Spiral Modelmaterial adapted from Steve Easterbrook ECE450 - Software Engineering II

8. Collect User stories code Planning game Each cycle:approx 2 weeks Release integrate test Write test cases Agile Model (XP)material adapted from Steve Easterbrook ECE450 - Software Engineering II

9. Project lifecycle choices • Which lifecycle model to choose? • First of all, CHOOSE ONE! • Too many projects drift aimlessly without this kind of strategy • Second, if possible, AVOID WATERFALL • Most derided, error-prone lifecycle • Though still the lifecycle of choice in many corporations • Third, prototypes and iterations are good for you • Sanity checks • Almost never a waste of time/resources • Fourth, choose based on context and convenience ECE450 - Software Engineering II

10. Software Methodologies • Reminder: A lifecycle is an abstract description of the life of a project • A methodology is a set of techniques that work well together • Lifecycles != Methodologies • Methodologies are usually (but not exclusively) built upon a lifecycle strategy ECE450 - Software Engineering II

11. Methodology Types • Main distinction: Sturdy vs. Agile • Key difference is how they handle uncertainty • Sturdyapproaches attempt to minimize the amount of uncertainty • Planning, risk prevention • Agile approaches attempt to minimize the impact of uncertainty • Adaptability, incremental processes ECE450 - Software Engineering II

12. CMM • CMM: Capability Maturity Model • (now CMMI, where “I” stands for “integration”) • Developed by Watts Humphrey and the Software Engineering Institute (SEI) at CMU • Five levels • Certification process • Companies are evaluated as “CMM level 3”, for example • Mirrors Total Quality Management approaches ECE450 - Software Engineering II

13. CMM (cont) • Pros: • Proven techniques • Self-sustained process • Required for some software contracts • Cons: • Fear of taking risks • Not popular among employees nor stellar companies • Doesn’t get more rigid than this! • Unless you go for ISO ECE450 - Software Engineering II

14. CMM variants:TSP and PSP • TSP: Team Software Process • Your company isn’t keen on the CMM? • You can still embrace its processes at the team level • Same recipe as CMM, but in smaller scale • PSP: Personal Software Process • No, not PlayStation Portable! • Same story as TSP, on an individual scale • “A Discipline for Software Engineering”, Humphrey • Worth reading and doing the exercises, at least for self-awareness ECE450 - Software Engineering II

15. Cleanroom • Best realization of “software engineering is formal methods” concept • Main idea: Don’t let the bugs in in the first place • To be added to product, piece of code must be proven correct • Pros: • Very high-quality software • Optimal for mission-critical projects • Cons: • Slow, not cost-effective • Good luck finding trained people ECE450 - Software Engineering II

16. RUP • RUP: Rational Unified Process • Propietary process, IBM • Characterized by use of UML (Unified Modelling Language) • Feels like a matrix evolution on the waterfall model • “Phases” and “Disciplines” ECE450 - Software Engineering II

17. RUP (cont) • Pros: • More relaxed, though still “sturdy” approach to software projects • Popular in some mid-large software companies • Discards naive view of waterfall models • Cons: • Need to train people in new modelling skills • Controversy on cost-effectiveness of analysis and modelling • Doesn’t work well in changing environments ECE450 - Software Engineering II

18. XP • XP = eXtreme Programming • Yes, terrible name • Intuition: Requirements changes are inevitable; emphasize adaptability • Practices: • User Stories • Planning Game • System Metaphor • Test-Driven Development • Small Releases • Pair Programming ECE450 - Software Engineering II

19. XP (cont) • The most successful of the agile methodologies • Though it’s debatable whether people that say they follow XP really are doing so • Pros: • Little spending in initial stages, results appear early • Change is expected, software adapts faster • Short feedback loops • Cons: • No time spent in analysis may mean lots of rework later on • No clear end in sight, project may continue forever • Pair programming feels awkward for most ECE450 - Software Engineering II

20. SCRUM • An agile, lightweight “methodology” alternative ECE450 - Software Engineering II

21. SCRUM (cont) • Pros: • Just about the easiest “methodology” to implement • Spends little developer time in documentation and meetings • 15-minute daily meetings are a great practice • Cons: • Not every customer is agreeable • Difficulties of scale • Long-term planning concerns ECE450 - Software Engineering II

22. Methodology choices • THEY ALL WORK • Really! • They provide a framework for your project plans • But you need to be committed to make it work • Choice depends on personal/company/customer preference • What about Open Source projects? ECE450 - Software Engineering II