V Model material adapted from Steve Easterbrook. Waterfall Model material adapted from Steve Easterbrook. Lifecycle of Software Projects

Transcription

1 Lifecycle of Software Projects ECE450 Software Engineering II 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 Today: Lifecycles and Methodologies ECE450 - Software Engineering II 1 ECE450 - Software Engineering II 2 Waterfall Model perceived View of development: need A process of stepwise refinement High-level management view Problems: Static view of (ignores volatility) code Lack of user involvement once spec is written Unrealistic separation of spec from Doesn t accomodate integrate prototyping, reuse ECE450 - Software Engineering II 3 Level of abstraction system analyze and V Model preliminary detailed code and debug component unit acceptance integration system integration and integrate time ECE450 - Software Engineering II 4 1

2 Preliminary prototype Prototyping Model build prototype Specify full evaluate prototype code integrate Requirements Phased Models Release 1 Incremental development code integrate O&M (each release adds more release 2 functionality) code integrate O&M release 3 code integrate O&M release 4 code integrate O&M Prototyping is used for: Understanding the for the user interface Examining feasibility of a proposed approach Exploring system performance issues Problems Users treat the prototype as the solution A prototype is only a partial specification ECE450 - Software Engineering II 5 version 1 reqts code integrate O&M Evolutionary development (each version incorporates new ) lessons learnt version 2 reqts code integrate O&M lessons learnt version 3 reqts code integrate ECE450 - Software Engineering II 6 Determine goals, alternatives, constraints Plan alternatives 4 Spiral Model alternatives 3 constraints 4 constraints 3 Alternatives 2 Constraints 2 alternatives constraints risk analysis 1 risk analysis 2 risk analysis 4 risk analysis 3 Evaluate alternatives and risks budget 4 budget 3 budget 2 budget 1 prototype 1 prototype 2 prototype 3 prototype 4 development plan integration and plan, lifecycle plan concept of operation validated Develop and ECE450 - Software Engineering II 7 implementation plan validated, verified acceptance system unit code detailed Release Agile Model (XP) Collect User stories Each cycle: approx 2 weeks code integrate Write cases Planning game ECE450 - Software Engineering II 8 2

3 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 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 9 ECE450 - Software Engineering II 10 Methodology Types Main distinction: Sturdy vs. Agile Key difference is how they handle uncertainty Sturdy approaches attempt to minimize the amount of uncertainty Planning, risk prevention Agile approaches attempt to minimize the impact of uncertainty Adaptatability, incremental processes 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 11 ECE450 - Software Engineering II 12 3

4 Proven techniques Self-sustained process Required for some contracts Fear of taking risks Not popular among employees nor stellar companies Doesn t get more rigid than this! Unless you go for ISO CMM (cont) 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 13 ECE450 - Software Engineering II 14 Cleanroom Best realization of 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 Very high-quality Optimal for mission-critical projects Slow, not cost-effective Good luck finding trained people 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 RUP ECE450 - Software Engineering II 15 ECE450 - Software Engineering II 16 4

5 RUP (cont) More relaxed, though still sturdy approach to projects Popular in some mid-large companies Discards naive view of waterfall models Need to train people in new modelling skills Controversy on cost-effectiveness of analysis and modelling Doesn t work well in changing environments 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 17 ECE450 - Software Engineering II 18 XP (cont) The most successful of the agile methodologies Though it s debatable whether people that say they follow XP really are doing so Little spending in initial stages, results appear early Change is expected, adapts faster Short feedback loops 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 SCRUM An agile, lightweight methodology alternative ECE450 - Software Engineering II 19 ECE450 - Software Engineering II 20 5

6 SCRUM (cont) Just about the easiest methodology to implement Spends little developer time in documentation and meetings 15-minute daily meetings are a great practice Not every customer is agreeable Difficulties of scale Long-term planning concerns ECE450 - Software Engineering II 21 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 22 6