Software Process Tutorial

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..
  • Implementation
    • Developing working code from models
  • Testing
    • Testing developed implementation
  • Deployment
    • Deploying the system in a production enviroment
  • Maintenance
    • Bug fixes and patching.

Attributes

  1. Documents produced at the end of each phase.
  2. 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
  3. It makes no allowances for prototyping
  4. 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
  5. 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.

  1. a project undergoes a large number of cycles, starting with a small prototype
  2. each loop of the spiral follows a mini-waterfall process
  3. before each cycle of the spiral ends, a review is held
  4. subsequent cycles become official releases
  5. the cycling only ends when the system is finally retired

eXtreme Programming

From eXtremePrograming.com

  • 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

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.