Software Development Processes and Models

Plan-Driven and Agile Processes

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

Software Process Models

  • 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.
  • Reuse-oriented software engineering
    • The system is assembled from existing components. May be plan-driven or agile.
  • In practice, most large systems are developed using a process that incorporates elements from all of these models.

Waterfall Model Phases

  • There are separate, identified phases in the waterfall model:
    • 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. A phase has to be complete before moving onto the next phase.

Software Specification

  • The process of establishing what services are required and the constraints on the system’s operation and development.
  • Requirements engineering process
    • Feasibility study
      • Is it technically and financially feasible to build the system?
    • Requirements elicitation and analysis
      • What do the system stakeholders require or expect from the system?
    • Requirements specification
      • Defining the requirements in detail
    • Requirements validation
      • Checking the validity of the requirements

Design Activities

  • Architectural design: Identifying the overall structure of the system, the principal components (sub-systems or modules), their relationships, and distribution.
  • Interface design: Defining the interfaces between system components.
  • Component design: Designing how each system component will operate.
  • Database design: Designing the system data structures and how these are to be represented in a database.

Software Evolution

  • Software is inherently flexible and can change.
  • As requirements change with business circumstances, the supporting software must also evolve.
  • The demarcation between development and evolution (maintenance) is increasingly irrelevant as fewer systems are completely new.

Software Prototyping

  • A prototype is an initial version of a system used to demonstrate concepts and try out design options.
  • A prototype can be used in:
    • The requirements engineering process to help with requirements elicitation and validation.
    • Design processes to explore options and develop a UI design.
    • The testing process to run back-to-back tests.

Benefits of Prototyping

  • Improved system usability.
  • A closer match to users’ real needs.
  • Improved design quality.
  • Improved maintainability.
  • Reduced development effort.

Incremental Delivery Advantages

  • Customer value can be delivered with each increment, so system functionality is available earlier.
  • Early increments act as a prototype to help elicit requirements for later increments.
  • Lower risk of overall project failure.
  • The highest priority system services tend to receive the most testing.

Incremental Delivery Problems

  • Most systems require a set of basic facilities that are used by different parts of the system.
    • As requirements are not defined in detail until an increment is to be implemented, it can be hard to identify common facilities needed by all increments.
  • The essence of iterative processes is that the specification is developed in conjunction with the software.
    • However, this conflicts with the procurement model of many organizations, where the complete system specification is part of the system development contract.

Boehm’s Spiral Model

  • Process is represented as a spiral rather than a sequence of activities with backtracking.
  • Each loop in the spiral represents a phase in the process.
  • No fixed phases such as specification or design – loops in the spiral are chosen depending on what is required.
  • Risks are explicitly assessed and resolved throughout the process.

The Rational Unified Process (RUP)

  • A modern generic process derived from the work on the UML and associated process.
  • Brings together aspects of the three generic process models discussed previously.
  • Normally described from three perspectives:
    • A dynamic perspective that shows phases over time.
    • A static perspective that shows process activities.
    • A practice perspective that suggests good practices.

RUP Phases

  • Inception
    • Establish the business case for the system.
  • Elaboration
    • Develop an understanding of the problem domain and the system architecture.
  • Construction
    • System design, programming, and testing.
  • Transition
    • Deploy the system in its operating environment.