Home Lecture Software Process Models W02 & Review

Software Process Models W02 & Review


Software Process Models

  • You will learn about a number of alternate generic models for structuring the software development process. The advantages and disadvantages of each. And when it is appropriate to use each model.

The Software Process

  • The structured set of activities required to develop a software system.
  • Many different software processes but all involve:
    – Specification – defining what the system should do;
    – Design and implementation – defining the organization of the system and implementing the system; – Validation – checking that it does what the customer wants;
    – Evolution – changing the system in response to changing customer needs.

Software Process Models

  • Software project composed of activities.
  • Activities organised into phases.
  • A software process:
    – prescribes the order and frequency of phases.
    – specifies criteria for moving from one phase to the next.
    – defines the deliverables of the project.
  • A process is sometimes associated with overhead, unnecessary paperwork, longer schedule etc. If processes are implemented incorrectly problems will arise, if applied with a degree of flexibility and adaptability they are of great benefit and invaluable to the success of a project.

Plan-Driven and Agile Processes

  • Plan-driven processes are processes where all of the process activities are planned in advance and progress is measured against this plan.
  • In agile processes, planning is incremental and it is easier to change the process to reflect changing customer requirements.
  • In practice, most practical processes include elements of both plan-driven and agile approaches.
  • There are no right or wrong software processes.

Software Process Models

  • The waterfall model
    – Plan-driven model. Separate and distinct phases of specification and development.
  • Incremental development
    – Specification, development and validation are interleaved. May be plan-driven or agile.
  • Integration and Configuration
    – The system is assembled from existing components. May be plan-driven or agile.
  • Initial software development efforts were very chaotic and employed a very basic process of code and fix. This was untenable and led to the creation of a step-by-step lifecycle based model published by Royce 1970.
  • The traditional software development lifecycle, the ‘waterfall model’.

The Waterfall Process Model (1970)

  • One of the oldest software process models. Despite its many weaknesses it is still widely used and is the basis for many other more effective processes.
    – Separate and distinct phases of specification and development executed in a sequential manner.
    – The output of one phase is the input for the next, a phase is not started until the previous is complete.
    – Milestones are reached if the appropriate documentation is delivered (e.g., requirements specification, design specification, program, test document)
    – Document-driven, planning driven, heavyweight.
    – Much planning upfront, often heavy contracts are signed.
    – Testing is performed at the end of development.
The Waterfall Process Model (1970)
The Waterfall Process Model (1970)

Waterfall Model Phases

  • Requirements analysis and definition.
  • System and software design.
  • Implementation and unit testing.
  • Integration and system testing.
  • Operation and maintenance.
  • The main drawback of the waterfall model is the difficulty of accommodating change after the process is underway. One phase has to be complete before moving on to the next.

Waterfall Model Advantages

  • Simple and easy to use. Phases are carried out and completed sequentially with specific inputs and deliverables.
  • Practised for many years and there is a lot of experience in its use.
  • Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a review process.
  • Facilitates allocation of resources – staff with phase specific skills.
  • Works well for projects where requirements are well understood.

Waterfall Model Disadvantages

  • Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements.
    – Therefore, this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process.
    – Few business systems have stable requirements.
  • Requirements must be known up front.
  • Hard to estimate reliably – estimates become more precise as the project progresses
  • Testing occurs at the end of development, the first time the system is tested as a whole.
  • No feedback by customers until after the testing phase – there are no intermediate versions.
  • The software process is not a simple linear model but requires iteration.


  • Waterfall
    – High risk for new systems because of specification and design problems. Does not accommodate change
    – Low risk for projects using familiar technology and where requirements are understood.
  • The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites.
    – In those circumstances, the plan-driven nature of the waterfall model helps coordinate the work.

Coping with change

  • Change is inevitable in all large software projects.
    – Business changes lead to new and changed system requirements.
    – New technologies open up new possibilities for improving implementations.
    – Management priorities change
  • Change leads to rework so the costs of change include both rework (e.g. reanalysing requirements) as well as the costs of implementing new functionality

Reducing the costs of rework

  • Change avoidance, where the software process includes activities that can anticipate possible changes before significant rework is required.
    – For example, a prototype system may be developed to show some key features of the system to customers.
  • Change tolerance, where the process is designed so that changes can be accommodated at relatively low cost.
    – This normally involves some form of incremental development. Proposed changes may be implemented in increments that have not yet been developed. If this is impossible, then only a single increment (a small part of the system) may have be altered to incorporate the change.

Coping with changing requirements

  • System prototyping, where a version of the system or part of the system is developed quickly to check the customer’s requirements and the feasibility of design decisions. This approach supports change anticipation.
  • Incremental delivery, where system increments are delivered to the customer for comment and experimentation. This supports both change avoidance and change tolerance.


  • Based on the idea of developing an initial implementation, showing this to the user and refining it through many versions until an adequate system has been developed.
  • Specification, development and validation activities are interleaved rather than separate, with rapid feedback across activities.

Prototyping in the software process

  • Evolutionary prototyping
    – An approach to system development where an initial prototype is produced and refined through a number of stages to the final system.
  • Throw-away prototyping
    – A prototype which is usually a practical implementation of the system is produced to help discover requirements problems and then discarded. The system is then developed using some other development process.

Evolutionary Prototyping

  • Analysis, design and implementation are performed concurrently and the three phases are performed repeatedly until the system is complete.
  • The first prototype is the part of the system which has the best know requirements and this is shown to the user for feedback. This feedback is incorporated to produce a second prototype and the process continues until the system is complete.
  • Spans the entire SDLC.
Evolutionary Prototyping
Evolutionary Prototyping

Strengths and Problems with Evolutionary Prototyping

  • Strengths
    – Very quickly delivers a system the user can interact with. The resulting system is easier to use.
    – Users needs are accommodated.
    – As users develop a better understanding of their problem this can be reflected in the software.
  • Problems
    – If systems are developed quickly it is not cost effective to produce documentation, careful methodical analysis is absent.
    – Lack of visibility, managers need regular deliverables to measure progress.
    – Systems are often poorly structured. Continual change corrupts the software structure.

Throw-away Prototyping Approach

  • A thorough analysis is performed, any requirement or technical issue that the user does not understand will be examined by building a design prototype.
  • Users are shown the prototype and using user feedback the designers generate another prototype and again show it to the users.
  • The model-critique-refine process continues until the prototype is approved.
  • Once approved, the prototype is discarded and its design specifications are used to implement the production system with other tools and techniques.
  • Is used only during the design phase of the SDLC.
Throw-away Prototyping Approach
Throw-away Prototyping Approach

Strengths and Problems with Throwaway Prototyping

  • Strengths
    – Balance the benefits of well thought out analysis and design phases with the advantage of using prototypes to examine to examine key issues. The resulting system will be more stable than that developed using system prototyping.
  • Problems
    – It can take longer to deliver the final system as compared to system prototyping and will consequently add to the expense of the project.

Prototype delivery

  • Developers may be pressurised to deliver a throwaway prototype as a final system
  • This is not recommended
    – It may be impossible to tune the prototype to meet nonfunctional requirements such as performance, security and reliability which were ignored during prototype development.
    – Rapid change during development means the prototype is undocumented. This will lead to maintenance problems.
    – The system structure will be degraded through changes made during development leaving it difficult and expensive to maintain.
    – Normal organisational quality standards may not have been applied


  • Throwaway Prototyping
    – Unclear requirements.
    – Unfamiliar technology.
    – Complex, require careful and detailed planning. A prototype is delivered early in the process.
  • Evolutionary Prototyping
    – Unclear requirements.
    – Familiar technology
    – Short time schedule, using people familiar with tools the product can be delivered quickly.
    – High risk because of lack of process visibility. – Use for short lifetime projects.

Iterative and Incremental Development

  • An iterative process is typified by repeated execution of the waterfall phases in whole or part. An iterative process is incremental if each iteration is relatively small and delivers a subset of the final products functionality and features.
  • Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality.
  • Normal approach used in agile methods.
  • The essence of an iterative process is that the specification is developed in conjunction with the software.
  • This conflicts with the complete specification forming part of the development contract. In the incremental approach there is no complete specification until the last increment is delivered.
  • Cheaper than waterfall easier to get feedback, early delivery.
Iterative and Incremental Development
Iterative and Incremental Development

Incremental Development

  • Customers identify the services to be provided by the system and prioritise these.
  • A number of delivery increments are then defined each providing a subset of the system functionality.
  • Allocation of services depends on the service priority the highest priority are delivered first.
  • Once increments have been identified the requirements for the services to be delivered in the first increment are defined in detail and that increment is developed.
  • Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve.
  • Once an increment is completed and delivered, customers can start to use it thus taking early delivery of system functionality.
Incremental Development
Incremental Development

Incremental Development Advantages

  • Customer value can be delivered with each increment.
  • Accelerated delivery of customer services.
  • Highest priority services are delivered first and later increments are integrated with them, thus undergoing the most testing – less failures in the most important part of the system.
  • Early increments act as a prototype to help elicit requirements for later increments.
  • Lower risk of project failure

Incremental Development Disadvantages

  • Increments should be small and yet deliver some functionality. It may be difficult to map functionality onto increments of the right size.
  • Some systems require a set of basic facilities used by different parts of the system. It can be hard to identify common facilities.
  • Specification develops with the software.

Incremental Development

  • The aim of the waterfall and prototyping models is to deliver to the client a product that satisfies all requirements and is ready for use.
  • The incremental model delivers an operational quality product at each stage which satisfies a subset of the requirements. A typical product consists of 5 to 25 builds, portions of what is required may therefore be available in weeks rather than months or years.

Extreme Programming

  • An approach to development based on the development and delivery of very small increments of functionality.
  • Relies on constant code improvement, user involvement in the development team and pairwise programming.
  • Covered later.

Spiral Development

  • Barry Boehm, TRW Defense Systems,1988
  • Process is represented as a spiral rather than as a sequence of activities with backtracking.
  • Each loop in the spiral represents a phase in the process.
  • Project starts at the center, and each loop of the spiral represents one iteration
  • Goal of each cycle is to increase the degree of system definition and implementation, while decreasing the degree of risk
  • Risks are explicitly assessed and resolved throughout the process. Risk-driven process
Spiral Development
Spiral Development

Spiral Model

  • Objective setting – Specific objectives for the phase are identified.
  • Risk assessment and reduction – Risks are assessed and activities put in place to reduce the key risks. Evaluation of project and process alternatives for achieving the objectives.
  • Development and validation – A development model for the system is chosen which can be any of the generic models.
  • Planning – The project is reviewed and the next phase of the spiral is planned.

Spiral Model Advantages

  • Risks are managed early and throughout the process – they are reduced before they become problematic.
  • Software evolves as the project progresses – it is a realistic approach to the development of largescale software. Errors and unattractive alternatives are eliminated early.
  • Planning is built into the process – each cycle contains a planning step to help monitor and keep a project on track

Spiral Model Disadvantages

  • Complicated to use requires risk assessment expertise.
  • Can only be used for large scale, in-house development due to possible contractual problems.
  • May be overkill for small projects – does not make sense if the cost of risk analysis is a major part of the overall cost.

Hybrid Process Models

  • Large systems are usually made up of several sub-systems.
  • The same process model need not be used for all subsystems.
  • Prototyping for high-risk specifications
  • Waterfall model for well-understood developments.

Integration and configuration

  • Based on software reuse where systems are integrated from existing components or application systems (sometimes called COTS -Commercial-off-the-shelf) systems).
  • Reused elements may be configured to adapt their behaviour and functionality to a user’s requirements
  • Reuse is now the standard approach for building many types of business system

Reuse-oriented software engineering

Reuse-oriented software engineering
Reuse-oriented software engineering
  • Advantages
    – Reduces the amount of software to be developed and so reduces costs and risks.
    – Leads to faster delivery and deployment of the system.
  • Disadvantages
    – Leads to requirements compromise and systems may not meet user requirements.
    – Control over system evolution is lost as new versions of the components are not under the control of the organisation.


  • Software development projects are often large with many people working for a long time therefore they need to be carefully planned controlled and monitored. To this end a phased development process with milestones is used.
  • A software process describes the interrelationships among the phases by expressing their order and frequency, as well as defining deliverables.
  • Specific software processes are called software process models.

The Development Context

‘The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.’

Brooks (1987)

Review Process Models

Previous articleIntroduction W01
Next articleRisk Management W03