Types of Popular Software Development Processes
Water Fall Model
A process model in which the software development works in a series of stages
- Requirements
- Develop and document the required features and functions that will be required to bring about the system concept.
- Problem Analysis
- Specification
- Listing of specific, measurable behavior system constraints that satisfy system requirements.
- Design
- Representing the system with models
- UML
- Sequence Diagrams
- Class Diagrams
- etc..
- UML
- Representing the system with models
- Implementation
- Developing working code from models
- Testing
- Testing developed implementation
- Deployment
- Deploying the system in a production enviroment
- Maintenance
- Bug fixes and patching.
Attributes
- Documents produced at the end of each phase.
- It has an overly rigid viewpoint that you should attempt to complete the entire specification before moving on to the design, and the entire design before moving on to implementation
- It makes no allowances for prototyping
- It implies that you can get the requirements right by simply writing them down and reviewing them, something that only works for simple, well-understood types of software development
- It implies that once the product is finished, everything else is maintenance
Spiral Model
An incremental process model that explicitly embraces prototyping and an iterative approach to software development.
- a project undergoes a large number of cycles, starting with a small prototype
- each loop of the spiral follows a mini-waterfall process
- before each cycle of the spiral ends, a review is held
- subsequent cycles become official releases
- the cycling only ends when the system is finally retired
eXtreme Programming
- User stories serve the same purpose as use cases but are not the same. Similar to our scenarios.
- A User story is also a work unit and an estimation unit. In this it's actually considerably heavier rather than lighter than a Use Case.
Story example: License Enforcement
When run for the first time, appX puts up a license dialog, and will not proceed until the user enters either:
- a valid non-time-limited (paid) license certificate or
- a valid time-limited (demo) license that has not yet expired.
A valid license is stored so the user doesn't have to re-enter it on subsequent runs.
License info is displayed on the splash screen.
When a demo license expires, the license dialog re-appears the next time appX is run.
- Iterations must past acceptence tests which are translated from user stories to be complete.
- Iterations are no longer than 3 weeks.
- Just-in-time planning, iteration plan at the beginning of each iteration to plan what will be done. Makes it easy to stay on top of changing user requirements.
- Against the rules to look ahead and try to implement anything that it is not scheduled for this iteration.
- All code to be included in a production release is created by two people working together at a single computer. Pair programming increases software quality without impacting time to deliver. It is counter intuitive, but 2 people working at a single computer will add as much functionality as two working separately except that it will be much higher in quality.
Our Process.....TELS eXtreme
So far:
Scenarios and Use Cases ~ user stories
Whats to come:
Requirements Document - maybe
Architecture Document/Diagrams
Design Docuemnt/Diagrams
Iterations 1-3 weeks