Software Development Models

3 min read Updated Sun Jun 07 2026 15:52:23 GMT+0000 (Coordinated Universal Time)

An abstract representation of a software process from a particular perspective.

Waterfall Model

A plan-driven model with clearly separated, sequential phases.

  1. Requirements analysis and definition
  2. System and software design
  3. Implementation and unit testing
  4. Integration and system testing
  5. Operation and maintenance

Difficult to accommodate changes once development has started.

Suitable when:

  • Requirements are well understood.
  • Changes are minimal.
  • Large, distributed system projects.

Incremental Development

Development done in small increments with feedback at each stage. Specification, development, and validation are interleaved. Each increment delivers working software. Can be plan-driven or agile.

Change cost is lower. Only the current increment needs reconsidering when changes arise. Working software is delivered earlier. Customers gain access to functional parts before the full system is built. Early access generates feedback while changes are still cheap.

Process visibility is low. Progress is typically measured through formal deliverables. Producing updated documentation for every version is not cost-effective. Managers therefore lack concrete artifacts to assess true project status. Without deliberate refactoring, each increment degrades system structure. Dependencies tangle, architecture drifts, and subsequent changes become progressively harder.

Reuse-Oriented Software Engineering

Integration of pre-existing software is focused more compared to writing new code from scratch. Driven by cost and schedule pressures, especially for commercial and internet-based systems.

Process stages:

  1. Requirements specification
    Initial requirements defined as in other models.
  2. Component analysis
    Search for components providing needed functionality. Typically no exact match.
  3. Requirements modification
    Requirements re-evaluated against available components. May be modified to fit a component. If unacceptable, the component is rejected and analysis resumes.
  4. System design with reuse
    Framework designed (or reused). New modules only where reusable components are unavailable.
  5. Development and integration
    Custom software built for gaps, then all components integrated.
  6. System validation
    Integrated system validated against requirements.

Types of reusable components:

  • Web services
    Remote functionality accessed over a network (REST, SOAP). Invoked at runtime rather than compiled in.
  • Component packages (.NET, J2EE)
    Objects/classes packaged for integration within a component framework. Component-level reuse.
  • Stand-alone COTS systems
    Complete application systems configured for a specific environment. Design shifts from building to configuring. System-level reuse.

Reuse levels:

  • Abstraction
    Design knowledge (patterns, architectural styles), not artifacts.
  • Object
    Library objects/classes used directly in code.
  • Component
    Collections of objects/classes as deployable units.
  • System
    Entire application systems (COTS).

Key tension: requirements compromise vs. development cost. Available components rarely match requirements exactly. Some loss of functionality is unavoidable. Development and integration cost is substantially reduced.

Boehm’s Spiral Model

A risk-driven iterative process model. Each loop of the spiral is a process phase; risks are explicitly identified and reduced.

Spiral sectors:

  • Objective setting
  • Risk assessment and reduction
  • Development and validation
  • Planning

Rational Unified Process

A modern generic process combining major process models.

Perspectives:

  • Dynamic
    Phases over time.
  • Static
    Workflows and activities.
  • Practice
    Recommended best practices.

RUP Phases

  • Inception: establish business case.
  • Elaboration: understand problem and architecture.
  • Construction: design, coding, and testing.
  • Transition: deployment to users.

Iteration occurs both within and across phases.

Workflows

Core: business modeling, requirements, analysis and design, implementation, testing, deployment.

Supporting: configuration and change management, project management, environment setup.

Good Practices

  • Iterative development
  • Requirements management
  • Component-based architecture
  • Visual modeling using UML
  • Quality verification
  • Controlled change management
Was this helpful?