Lifecycle of Software Projects
• Lifecycle models are useful to compare project ECE450 – Software Engineering II management strategies in abstract terms – Birds-eye view strategy – Detect strengths and weaknesses – ... but reality is always more messy Today: Lifecycles and Methodologies
ECE450 - Software Engineering II 1 ECE450 - Software Engineering II 2
Waterfall Model V Model material adapted from Steve Easterbrook material adapted from Steve Easterbrook
perceived • View of development: need – A process of stepwise system system refinement requirements integration – High-level requirements management view software acceptance • Problems: requirements test
design – Static view of abstraction of Level requirements (ignores preliminary software volatility) design integration “test code – Lack of user “analyze and involvement once and detailed component integrate design test spec is written design” ” test – Unrealistic separation code and unit of spec from design debug test – Doesn’t accomodate integrate prototyping, reuse time ECE450 - Software Engineering II 3 ECE450 - Software Engineering II 4
1 Prototyping Model Phased Models material adapted from Steve Easterbrook material adapted from Steve Easterbrook Release 1 Incremental development design code test integrate O&M (each release adds more
Preliminary design build evaluate Requirements functionality) requirements prototype prototype prototype release 2 design code test integrate O&M
design code test integrate O&M
Specify full release 3 design code test integrate requirements design code test integrate O&M
• Prototyping is used for: release 4 – Understanding the requirements for the user interface version 1 reqts design code test integrate O&M – Examining feasibility of a proposed design approach – Exploring system performance issues lessons learnt • Problems reqts design code test integrate O&M – Users treat the prototype as the solution Evolutionary developmentversion 2 – A prototype is only a partial specification (each version reqts design code test integrate ECE450 - Software Engineering II 5 incorporates new ECE450 - Software Engineering II 6 requirements) lessons learnt
version 3
Spiral Model Agile Model (XP) material adapted from Steve Easterbrook material adapted from Steve Easterbrook
Determine goals, Evaluate alternatives, s 4 alternatives int ris tra k Collect constraints ons an c aly and risks sis User stories ts 3 4 ain tr ris ons k s 4 c an e al v ys i 3 is t s tr- 3 Planning a e ons n iv C ri r t nts 2 a sk Each cycle: game e a ai na lt n - ly r n s s Release a r 2 ve is e e s ti r 2 approx 2 weeks t t e a ts isk l l v rn in a i te a ana A t al tr lysis a ns 1 co budget4 budget3 budget2 budget1 prototype1 prototype2 prototype3 prototype4 e s Write test concept of r t d re a n e qu e l n ire w i m oper t m g cases lif en ation e a i e ts f e t s code cyc , o r r le i a e e p s u d lan w n d d ev q t ig elo e f s pm r o e in en ted s d te t p lida integrate gr la va nts e a n eme d tio quir o n a re c nd t test es ed, t t p dat gn ni la vali esi u t n d d s ifie te Develop ver em Plan syst and st implem cceptance te entation a test ECE450 - Software plan Engineeringtest II 7 ECE450 - Software Engineering II 8
2 Project lifecycle choices Software Methodologies
• Which lifecycle model to choose? •Reminder: A lifecycle is an abstract description – First of all, CHOOSE ONE! of the life of a project • Too many projects drift aimlessly without this kind of strategy – Second, if possible, AVOID WATERFALL •A methodology is a set of techniques that work • Most derided, error-prone lifecycle well together • Though still the lifecycle of choice in many corporations – Third, prototypes and iterations are good for you • Lifecycles != Methodologies • Sanity checks – Methodologies are usually (but not exclusively) built • Almost never a waste of time/resources upon a lifecycle strategy – Fourth, choose based on context and convenience
ECE450 - Software Engineering II 9 ECE450 - Software Engineering II 10
Methodology Types CMM
• Main distinction: Sturdy vs. Agile • CMM: Capability Maturity Model • Key difference is how they handle – (now CMMI, where “I” stands for “integration”) – Developed by Watts Humphrey and the Software uncertainty Engineering Institute (SEI) at CMU – Sturdy approaches attempt to minimize the – Five levels amount of uncertainty – Certification process • Planning, risk prevention • Companies are evaluated as “CMM level 3”, for example – Agile approaches attempt to minimize the – Mirrors Total Quality Management approaches impact of uncertainty • Adaptatability, incremental processes
ECE450 - Software Engineering II 11 ECE450 - Software Engineering II 12
3 CMM variants: CMM (cont) TSP and PSP •Pros: • TSP: Team Software Process – Proven techniques – Your company isn’t keen on the CMM? – Self-sustained process • You can still embrace its processes at the team level – Required for some • Same recipe as CMM, but in smaller scale software contracts • Cons: – Fear of taking risks • PSP: Personal Software Process – Not popular among – No, not PlayStation Portable! employees nor stellar – Same story as TSP, on an individual scale companies •“A Discipline for Software Engineering”, Humphrey – Doesn’t get more rigid than this! – Worth reading and doing the exercises, at least for • Unless you go for ISO self-awareness
ECE450 - Software Engineering II 13 ECE450 - Software Engineering II 14
Cleanroom RUP
• Best realization of “software engineering is formal • RUP: Rational methods” concept Unified Process – Main idea: Don’t let the bugs in in the first place – Propietary process, • To be added to product, piece of code must be proven correct IBM •Pros: – Characterized by use of UML (Unified – Very high-quality software Modelling Language) – Optimal for mission-critical projects – Feels like a matrix • Cons: evolution on the – Slow, not cost-effective waterfall model – Good luck finding trained people • “Phases” and “Disciplines”
ECE450 - Software Engineering II 15 ECE450 - Software Engineering II 16
4 RUP (cont) XP
•Pros: • XP = eXtreme Programming – More relaxed, though still “sturdy” approach to – Yes, terrible name software projects – Intuition: Requirements changes are inevitable; – Popular in some mid-large software companies emphasize adaptability – Discards naive view of waterfall models –Practices: •Cons: •User Stories • Planning Game – Need to train people in new modelling skills • System Metaphor – Controversy on cost-effectiveness of analysis and • Test-Driven Development modelling • Small Releases – Doesn’t work well in changing environments • Pair Programming
ECE450 - Software Engineering II 17 ECE450 - Software Engineering II 18
XP (cont) SCRUM
• The most successful of the agile methodologies • An agile, lightweight “methodology” alternative – 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 19 ECE450 - Software Engineering II 20
5 SCRUM (cont) Methodology choices
•Pros: • THEY ALL WORK – Just about the easiest “methodology” to implement – Really! – Spends little developer time in documentation and – They provide a framework for your project plans meetings – But you need to be committed to make it work – 15-minute daily meetings are a great practice • Choice depends on personal/company/customer •Cons: preference – Not every customer is agreeable – Difficulties of scale – Long-term planning concerns • What about Open Source projects?
ECE450 - Software Engineering II 21 ECE450 - Software Engineering II 22
6