Software Dev Process Lecture Notes - Part 1 Lesson 2 - Life Cycle Models
Life Cycle Models
Phases of the software lifecycle
- Each of these will be covered in great depth
- Requirements Engineering
- The process of establishing th needs of stakeholders
- Cost of correction climbs over time. Cheapest to find mistakes here.
- 4 phases
- Elicitation
- Analysis
- Specification
- Validation
- Management
- Accounts for changes * Iterative process
- Design
- Consists of series of design activities
- General theme is to design from high level view down to low
- Result in a set of design products
- Implementation
- 4 pillars
- Reduction of complexity
- Anticipation of diversity
- Structuring for validation
- Use of standards
- Verification and Validation
- Validation: did we build the right system?
- Verification: did we build the system right?
- Can be done at multiple levels
- Unit - is each unit right?
- Integration - do the units interact correctly?
- System - does the system overall behave correctly?
- Maintenance
- After software is finished and deployed, might have environment changes, feature requests, or bug reports
- 3 kinds of maintenace
- Corrective maintenance - fix bugs
- Perfective maintenance - add features
- Adaptive maintenance - adjust for env changes
- maintenance is expensive
- regression testing is testing software after changes to ensure no new bugs were added
Software Process Model (aka Software Lifecycle Model)
- Main function is to determine the order of software dev activities
- Also to determine transition criteria between each step
- Waterfall Process
- Performs well for products where there is a stable product definition
- Progresses through orderly steps from first to alst with review before each step forward
- Pro: Allows you to find errors early
- Con: Very inflexible
- Spiral Process
- Incremental risk-oriented model
- 4 main phases
- Determine objectives
- Identify and resolve risks
- Development and Tests
- Plan the next iteration
- A project iterates through all 4 phases
- Pros: risk reduction advantage. Functionality can be added later. Software produced pretty early in iterative lifecycle
- Cons: requires specific expertise, lots more complexity
-
Evolutionary prototyping *4 main phases 1. Initial concept 2. Design and implement initial prototype 3. Refine prototype until acceptable 4. Complete and release prototype
- Ideal when not all requirements are well understood
- Pros: Immediate feedback
- Cons: Difficult to plan
- Rational Unified Process
- Based on UML
- Iterative
- Each iteration has 4 phases
- Inception
- elaboration
- Construction
- Transition
- We do different software dev stuff in each phase. We do more or less of each thing depending on the phase
- Agile
- Highly iterative and flexible
- Going to focus on TDD. Iterates through 3 phases
- Write tests. Red phase, no code yet, they all fail
- Green phase, write just enough code to make all tests past
- Refactor, rewrite code to make it more readable and maintainable
Choosing a model
- How to choose a model?
- Requirements understanding
- Also requirements stability
- Expected lifetime
- Risk
- Schedule constraints
- Interaction with stakeholders
- Hard to iterate a lot if they don’t respond
- Level of expertise of people involved
- Requirements understanding
Lifecycle Documents
- Lots of different kinds
- IEEE has official ones, very heavy
- This class will use our own lightweight versions
Classic Mistakes
- People
- Heroics
- too much emphasis on ‘heroic efforts’
- causes risk-taking and burnout
- Bad work environment
- strong evidence this affects productivity (no duh)
- Poor people management
- lack of leadership, poor leadership
- adding people to a late project. never works!
- Heroics
- Process
- Scheduling issues - due to poor time estimation
- Planning issues
- unforeseen failures
- Product
- gold plating - excessive unnecessary requirements
- feature creep - adding additional (unneeded) feature creep
- avg 25% creeped features on projects
- Research /= development - manage research differently
- Technology
- Silver bullet syndrome - too much reliance on some (new) technology
- Switching tools (or adding)
- No version control