1.2.C. Software Process Modules - Operational Specification, Phased And Spiral

1.2.c. Software Process Modules - Operational Specification, Phased and Spiral

Operational Specification Model

• Requirements are executed (examined) and their implementation evaluated early in the development.
• Functionality and the design are allowed to be merged.
  
• The system requirements are created, sometimes informal or incomplete.
  • This is opposed to waterfall, where the requirements are fully completed and defined before the other steps are executed.
• This leads to the operational specification which is more formal way of defining the requirements, which can be executed.
  • This is different from prototypes, the requirements themselves can be turned into a specification which is so formal that they can even be executed.
  • This won't be the final system, but will give an indication whether the requirements may be inconsistent or incorrect.
  • Therefore there is a very early opportunity to execute the requirements and revise them accordingly, allowing for a lot more efficiency and certainty in the development process.
• Then comes the implementation, where we aim to turn what was just 'executing the requirements' to something which is more detailed that will feed into the final implementation.
• After that is the usual quality assurance and testing, then the system is finally delivered.

Phased Development: Increments & Iterations

• In complex software projects, it is often beneficial to break them into phases.
  • We have short cycles, avoiding the main issue of waterfall where there is a long wait before a usable product is produced.
  • The system is also developed in pieces, allowing us to give the client something that might already be used in production.
  • While the user is using version one in production, this then allows the developers to begin developing the second release, then version three, etc.
    • This allows a lot more flexibility and gives value to the client earlier.

There are two ways of approaching this.

• Incremental development: starts with small functional subsystem and adds functionality with each new release.
• Iterative development: starts with full system, then changes functionality of each subsystem with each new release.
  

Spiral Model

• Combines development with risk management.
  • Any software development project has a number of risks, especially complex projects. We must take this into consideration; spiral combines risk management within the development process, not simply treating it as an afterthought or a single planning phase.
  • The model is presented as a spiral with iterations around four major activities.
    • Plan
    • **Determine goals, alternatives and constraints
    • Evaluate alternatives and risks
    • Develop and test
      
• We start in the centre of the diagram at the 'start' node.
• We first have the requirements and the rough lifecycle plan of the development with the initial budget. Here we consider alternatives and constraints.
• Then we do risk analysis and initial prototype, and then produce a concept of operation document, which is essentially a high-level view of how the software should operate.
• Then, we enter on the outer side and start planning the requirements in more detail, another revised budget check, research alternative and constraints, do more risk analysis, prototype, and then that will result in the initial version of the software requirements which will be more formal, then we are able to produce validated requirements which we can use for the software design... etc.
• We go through the same loop over and over, then we enter the detailed design, then the code, testing, implementation plan, and entering production preperations.
• This is more complex than the other models, but has the benefit of making sure people consider alternatives, that we do risk analysis and ensure that each prototype has very good qualities to it. This is at the cost of complexity and more loops.