SOFTWARE ENGINEERING

9th Edition — Ian Sommerville

Some New SDLC Models — Descriptive Notes
 PART 1 — THE AGILE SDLC

1. The Agile SDLC

Agile methods are a family of incremental development approaches that emerged in the late
1990s in response to the limitations of heavyweight, plan-driven methods. They prioritise speed,
flexibility, and working software over comprehensive documentation and rigid processes. [p.
58]

The core characteristics of Agile SDLC (from the PPT) are:

• Speed up or bypass one or more lifecycle phases — Agile reduces or eliminates
phases (like separate requirements and design phases) to accelerate delivery.
• Usually less formal and reduced scope — Documentation is minimised. Teams
communicate directly rather than through formal written artefacts.
• Used for time-critical applications — Agile is ideal when rapid market delivery is more
important than exhaustive upfront planning.
• Used in organisations that employ disciplined methods — Paradoxically, Agile
requires discipline; without it, 'agile' degrades into uncontrolled, chaotic development.

The book (p. 57) captures the business pressure that drives Agile adoption: "Businesses now
operate in a global, rapidly changing environment. Rapid development and delivery is therefore
now often the most critical requirement for software systems." [p. 57]

The Agile Manifesto (p. 59): Agile methods share four core values — Individuals and
interactions over processes and tools; Working software over comprehensive
documentation; Customer collaboration over contract negotiation; Responding to change
over following a plan.

2. Overview of Major Agile Methods

The PPT lists eight widely used Agile methods. The book (p. 59) notes that all of these are
based around the notion of incremental development and delivery, though they propose
different processes to achieve this. [p. 59]

Agile Full Name Key Focus

Method
 ASD Adaptive Software Adaptive, collaborative approach to managing complex,
Development rapidly changing systems.

FDD Feature Driven Building features in short, focused iterations using a

Development feature list driven by business value.

Crystal Clear Crystal Clear Lightweight methodology for small co-located teams,
emphasising communication and reflection.

DSDM Dynamic Systems Applies the 80/20 rule — delivering 80% of requirements
Development Method in 20% of the time; timeboxed iterations.

RAD Rapid Application Uses prototyping and iterative development to deliver

Development systems quickly.

Scrum Scrum Agile project management framework using fixed-length

'Sprints' with daily stand-up meetings.

XP Extreme Programming Engineering-focused agile method with 12 core practices

including TDD, pair programming, and continuous
integration.

RUP Rational Unified Process Hybrid process model combining iterative development
with structured phases and UML modelling.

3. Extreme Programming (XP)

Extreme Programming (XP) is perhaps the best-known and most widely used agile method.
The name was coined by Kent Beck because it pushes recognised good software development
practices to 'extreme' levels. XP is best suited for small-to-medium-sized teams developing
software with vague or rapidly changing requirements. [p. 64]
A defining characteristic of XP is that coding is the key activity throughout the project.
Communication among teammates is done through code itself — life cycle and behaviour of
complex objects are defined in test cases, again in code. [p. 64]

3.1 The 12 XP Practices

The book describes these core practices in Figure 3.4 (p. 66), grouped into the 12 XP practices
highlighted in the PPT:

# XP Practice Description (Book p. 66)

1 Planning Game Determine the scope of the next release by combining business priorities
and technical estimates. Requirements are recorded on Story Cards; the
development team breaks these into tasks.
 2 Small Releases Put a simple system into production first, then release new versions in
very short cycles. The minimal useful set of functionality that provides
business value is developed first.

3 Metaphor All development is guided by a simple, shared story of how the whole
system works — serving as a common vocabulary for the team and
customer.

4 Simple Design The system is designed as simply as possible at all times. Extra
complexity is removed as soon as it is discovered. 'Enough design is
carried out to meet the current requirements and no more.'

5 Testing Programmers continuously write unit tests before writing the code (Test-
First Development). Customers write tests to validate features. All tests
must pass before a new release.

6 Listening / Programmers continuously restructure the system without changing its

Refactoring external behaviour, to remove duplication, simplify the code, and improve
structure.

7 Pair Programming All production code is written with two programmers at one machine.
Pairs are created dynamically so all team members work with each other
during development.

8 Collective Ownership Anyone can change any code anywhere in the system at any time. No
individual owns any part of the system — the team has collective
responsibility for all code.

9 Continuous Integrate and build the system many times a day — every time a task is
Integration completed. When new code is integrated, all unit tests in the system must
pass.

1 40-Hour Week Work no more than 40 hours a week as a rule. Excessive overtime
0 reduces code quality and medium-term productivity. 'Sustainable pace.'

1 On-Site Customer A user is on the development team and available full-time to answer
1 questions, define requirements, and write acceptance tests.

1 Coding Standards Programmers write all code in accordance with rules emphasising
2 communication through the code. All code looks as if it was written by a
single person.

3.2 Why XP is Called 'Extreme'

The book explains (p. 64) that XP was developed by taking recognised good practices to
extreme levels. The PPT captures this concept precisely:

• If code reviews are good → review code all the time (pair programming)
• If testing is good → everybody tests all the time (test-first development)
 • If simplicity is good → keep the simplest design that supports current functionality
• If design is good → everybody designs daily (refactoring)
• If architecture is important → everybody works at defining and refining the
architecture (metaphor)
• If integration testing is important → build and integrate tests several times a day
(continuous integration)
• If short iterations are good → make iterations really, really short (hours rather than
weeks)

Testing in XP (p. 69): XP emphasises test-first development — writing tests before

writing the code. Writing tests implicitly defines both an interface and a specification of
behaviour. This approach reduces problems of requirements and interface
misunderstandings and avoids 'test-lag' — where development gets ahead of testing.

Pair Programming (p. 71): Programmers work in pairs at the same workstation. Benefits:
(1) Supports collective ownership and responsibility; (2) Acts as an informal review process
— every line of code is looked at by at least two people; (3) Helps support refactoring for
long-term benefit.

4. Feature Driven Development (FDD)

Feature Driven Development is one of the agile methods listed in the book (p. 59). It organises
development around building software features — functions that can be developed in two
weeks or less and expressed in client terms with the template: <action> <result> <object>
(e.g., 'Calculate the total of a sale').

4.1 Five FDD Process Activities

The FDD process consists of five activities:

1. Develop an Overall Model: Produce class and sequence diagrams from a meeting of
the chief architect with domain experts and developers. This creates a shared
understanding of the system's domain.
2. Build a Features List: Identify all the features that support the requirements. Features
are functionally decomposed into Business Activities with steps within Subject Areas.
The features list drives all subsequent planning and development.
3. Plan by Feature: The development staff plan the development sequence of features,
assigning features to chief programmers based on complexity and dependencies.
 4. Design by Feature: The team produces sequence diagrams for the selected features,
refines the object model, and writes method skeletons.
5. Build by Feature: The team writes and tests the code for the selected features. Unit
tests are carried out before the feature is promoted to the main build.

FDD Feature Template: Features are expressed as: <action> <result> <object>.
Example: 'Calculate the total of a sale'. This ensures features are always expressed in
client-understandable business terms and are small enough to be built in two weeks or
less.

5. Dynamic Systems Development Method (DSDM)

DSDM (Dynamic Systems Development Method) is one of the earliest agile methods,
developed in the UK in the 1990s. It applies a framework for Rapid Application Development
(RAD) within short timeframes. Its core paradigm is the 80/20 rule — the majority of
requirements can be delivered in a relatively short amount of time. [p. 59]

5.1 DSDM Lifecycle

The DSDM lifecycle progresses through the following stages:

6. Feasibility Study: Assesses whether DSDM is an appropriate approach for the project
and whether the project is technically and commercially feasible.
7. Business Study: Establishes the business and technical requirements at a high level.
Requirements are prioritised using the MoSCoW rules (Must have, Should have, Could
have, Won't have this time).
8. Functional Model Iteration: Develops a working prototype through iterative cycles.
Each iteration includes risk analysis and produces a time-box plan for the next iteration.
9. Design and Build Iteration: Refines and extends the functional model into a system
that is robust enough for operational use.
10. Implementation: Delivers the system into the operational environment and trains users.

5.2 DSDM Principles

DSDM is governed by nine core principles:

• Active user involvement is imperative — Ambassador users represent the business

interests throughout development.
 • DSDM teams must be empowered to make decisions — Teams can make day-to-day
technical and business decisions without escalating.
• Focus on frequent product delivery — Working software is delivered frequently at
agreed intervals.
• Fitness for business purpose — The primary criterion for product acceptance is
fitness for business purpose, not technical perfection.
• Iterative and incremental development — Development converges on an accurate
business solution through progressive iteration.
• Requirements agreed at a high level initially — Detailed requirements are defined
during iterative development, not upfront.
• All changes made during development are reversible — Iterations are timeboxed; if
a change cannot be completed, it is rolled back.
• Testing is integrated throughout the lifecycle — Testing is not a phase at the end; it
is continuous throughout development.
• Collaborative and co-operative approach — All stakeholders must work together in a
spirit of partnership.

DSDM vs. Traditional Waterfall: Where the Waterfall Model fixes requirements and adjusts
time and cost, DSDM fixes time and cost and adjusts functionality. This is the practical
application of the 80/20 rule — deliver 80% of the value in 20% of the time.
 PART 2 — SPIRAL, RUP, QUALITY & REUSE

6. Boehm's Spiral Model (Recap)

The Spiral Model, proposed by Boehm (1988), represents the software process as a spiral
rather than a sequence of activities. Each loop represents a phase of the process. Unlike
other models, there are no fixed phases — loops in the spiral are chosen depending on what is
required. [p. 48]
Its most important distinguishing characteristic: risks are explicitly assessed and resolved
throughout the process. Every loop of the spiral begins with objective setting, moves through
risk assessment, development, and concludes with planning the next phase. [p. 49]

Four Quadrants (p. 49): (1) Determine Objectives, Alternatives & Constraints → (2)
Evaluate Alternatives, Identify & Resolve Risks → (3) Develop Next-Level Product → (4)
Plan Next Phase. This cycle repeats for each loop of the spiral.

7. The Rational Unified Process (RUP)

The Rational Unified Process (RUP) is a modern generic process model derived from work
on the UML and the associated Unified Software Development Process. It is a hybrid model
that brings together aspects of the three generic process models — Waterfall, Incremental, and
Reuse-Oriented. [p. 50]
RUP is normally described from three perspectives:
• Dynamic perspective: Shows the phases of the model over time.
• Static perspective: Shows the process activities (workflows) that are enacted.
• Practice perspective: Suggests good practices to use during the process. [p. 50]

7.1 RUP Phases

RUP defines four discrete phases (Figure 2.12, p. 51). Unlike the Waterfall Model, these phases
are related to business concerns rather than purely technical activities:

Phase Goal Key Output

Inception Establish the business case for the Business case; initial use-case model; initial
 system. Identify all external entities risk assessment. Project may be cancelled if
that interact with the system. business case is weak.

Elaboration Develop an understanding of the Requirements model (UML use cases);

problem domain and establish the architectural description; development plan.
system architecture. Identify key
project risks.

Construction System design, programming, and Working software system with documentation,
testing. Parts of the system ready for delivery to users.
developed in parallel and
integrated.

Transition Deploy the system in its operating Documented software system working
environment. Move from correctly in its operational environment.
development community to user
community.

7.2 RUP Iteration

Iteration is supported in two ways in the RUP:
• In-phase iteration: Each phase is iterative with results developed incrementally.
• Cross-phase iteration: The whole set of phases may be enacted incrementally, as
shown by the looping arrow from Transition back to Inception in Figure 2.12. [p. 51]

7.3 RUP Static Workflows

The static view of the RUP focuses on the activities (workflows) that take place during
development. There are six core process workflows and three supporting workflows (Figure
2.13, p. 52):

Workflow Description

Business Modelling The business processes are modelled using business use cases.

Requirements Actors who interact with the system are identified and use cases are
developed to model system requirements.

Analysis and Design A design model is created and documented using architectural models,
component models, object models, and sequence models.

Implementation The components in the system are implemented and structured into
implementation sub-systems. Automatic code generation from design
models helps accelerate this.

Testing An iterative process carried out in conjunction with implementation.

System testing follows completion of the implementation.
 Deployment A product release is created, distributed to users, and installed in their
workplace.

Config. & Change This supporting workflow manages changes to the system.
Management (support)

Project Management This supporting workflow manages the system development process.
(support)

Environment (support) Concerned with making appropriate software tools available to the
development team.

7.4 RUP Six Good Practices

The practice perspective of the RUP recommends six fundamental best practices for systems
development: [p. 52]

11. Develop software iteratively: Plan increments based on customer priorities; deliver
highest-priority increments first.
12. Manage requirements: Explicitly document customer requirements and keep track of
changes. Analyse the impact of changes before accepting them.
13. Use component-based architectures: Organise the system architecture as a set of
reusable components.
14. Visually model software: Use graphical UML models to present static and dynamic
views of the software.
15. Verify software quality: Ensure that the software meets organisational quality
standards.
16. Control changes to software: Manage software changes using a change management
system and configuration management tools. [p. 53]

8. Software Quality
Software quality is defined as the degree to which the software satisfies stated and implied
requirements. This encompasses three key dimensions from the PPT:
• Absence of system crashes — the software operates reliably without failures.
• Correspondence between software and users' expectations — the system does
what users expect it to do.
• Performance to specified requirements — the system meets its functional and non-
functional specifications.
The book (p. 656) expands on quality, noting that software quality is not just about whether
functionality has been correctly implemented, but also depends on non-functional system
attributes — reliability, performance, security, usability, and maintainability.
Boehm et al. (1978) identified 15 important software quality attributes (p. 656) including:
Safety, Security, Reliability, Resilience, Robustness, Understandability, Testability, Adaptability,
Modularity, Complexity, Portability, Usability, Reusability, Efficiency, and Learnability.

Why Quality Must Be Controlled (PPT): Poor quality lowers production speed,
increases maintenance costs, and can adversely affect the business. The book
reinforces this by noting that failing to meet non-functional requirements can render the
whole system unusable. [p. 87]

8.1 Quality Assurance Plan

A Quality Assurance (QA) Plan is a formal document that defines how quality will be measured
and maintained throughout the development process. According to the PPT and the book
(Ch24), the plan should:
• Be written down formally — the quality assurance plan must be documented.
• Define whether a separate QA group should perform quality assurance activities
(separate from the development team).
• Cover the following key elements: defect tracking, unit testing, source-code tracing,
technical reviews, integration testing, and system testing.

8.2 Key QA Plan Elements

The PPT identifies six critical elements of quality assurance:

QA Element Description

Defect Tracking Keeps track of each defect found: its source, when it was detected, when
it was resolved, how it was resolved. Provides data for process
improvement.

Unit Testing Each individual module is tested in isolation to verify that it meets its
specification. Detects defects early, when they are cheapest to fix.

Source Code Tracing Step through source code line by line to verify logic, detect errors, and
understand program behaviour.

Technical Reviews Completed work is reviewed by peers. The book (p. 663) describes
formal reviews/inspections as very successful in discovering a high
percentage of software errors.
 Integration Testing Exercises new code in combination with code that has already been
integrated. Focuses on detecting interface errors between components.

System Testing Execution of the complete software system for the purpose of finding
defects. Checks that the system meets its functional and non-functional
requirements.

Process-Based Quality (p. 657): A key assumption in software quality management is that
the quality of software is directly related to the quality of the software development
process. Improving the development process leads to fewer defects in the software.
However, software development is creative, so process standardisation alone is not
sufficient — individual skill and experience also matter significantly.

9. Reuse-Oriented Software Engineering

Reuse-oriented software engineering is based on systematic reuse — building systems by
integrating existing components or COTS (Commercial-Off-The-Shelf) systems rather than
developing everything from scratch. The book states: [p. 34]
"Reuse is now the standard approach for building many types of business system." [p. 35]

9.1 Process Stages

The reuse-oriented process (Figure 2.3, p. 35) has four stages, which differ significantly from
other process models:

17. Component Analysis: Given the requirements specification, a search is made for
components to implement that specification. Usually, there is no exact match —
components may provide only some of the required functionality.
18. Requirements Modification: Requirements are analysed against available
components. They may be modified to match components. Where modifications are
impossible, alternative components are sought.
19. System Design with Reuse: The framework of the system is designed (or an existing
framework is reused), taking into account the components that will be reused. Some new
software may need to be designed if no suitable components exist.
20. Development and Integration: Software that cannot be procured externally is
developed. Components and COTS systems are integrated to create the new system.
System integration is part of the development process. [p. 35]
9.2 Types of Software Component
The book (p. 36) identifies three types of reusable software component:

• Web services: Developed according to service standards and available for remote
invocation over the web. Provide specific, well-defined functionality that can be accessed
by any client.
• Collections of objects: Developed as a package to be integrated with a component
framework such as .NET or J2EE. These are language-specific components that
conform to a standard component model.
• Stand-alone software systems (COTS): Configured for use in a particular
environment. Examples: database systems, ERP systems, payroll systems. [p. 36]

✅ Strengths / Advantages ❌ Weaknesses / Limitations

Reduces amount of software to be developed — Requirements compromises are inevitable —

lowers cost and risk. system may not meet all real user needs.

Faster delivery — existing components are pre- Some control over system evolution is lost — new
tested and ready. versions of reused components are not under the
organisation's control.

Improved reliability — reused components have Difficulty identifying suitable components that
been proven in other systems. closely match requirements.

Reuse is now the standard approach for building Integration costs and compatibility issues with
many types of business system. existing systems.

10. Software Process Activities

Real software processes are inter-leaved sequences of technical, collaborative, and
managerial activities with the overall goal of specifying, designing, implementing, and testing a
software system. [p. 36]
The four basic process activities are organised differently in different development processes —
sequentially in the Waterfall Model, inter-leaved in incremental development.

10.1 Software Specification

Software specification — or requirements engineering — is the process of establishing what
services are required from the system and the constraints on its operation and development.
The book states it is a particularly critical stage because errors here inevitably lead to later
problems. [p. 36]
The requirements engineering process (Figure 2.4, p. 38) has four main activities:
• Feasibility Study: Is it technically and financially feasible to build the system? Results in
a feasibility report.
• Requirements Elicitation and Analysis: What do system stakeholders require or
expect from the system? Results in system models.
• Requirements Specification: Defining the requirements in detail — both user
requirements and system requirements.
• Requirements Validation: Checking the validity and completeness of the requirements.
Results in the requirements document. [p. 37]

10.2 Software Design and Implementation

The implementation stage is the process of converting the system specification into an
executable system. It involves both software design and programming. The activities of design
and implementation are closely related and may be inter-leaved. [p. 38]
The design process (Figure 2.5, p. 39) involves four activities:
• Architectural Design: Identify the overall structure of the system, the principal
components, their relationships, and how they are distributed.
• Interface Design: Define the interfaces between system components. Precise
interfaces allow components to be used without knowing their implementation.
• Component Design: Take each system component and design how it will operate.
• Database Design: Design the system data structures and how they are to be
represented in a database. [p. 39]

10.3 Software Validation (V&V)

Verification and Validation (V&V) is intended to show that a system conforms to its
specification and meets the requirements of the customer. It involves checking and review
processes and system testing. Testing is the most commonly used V&V activity. [p. 41]
Testing proceeds through three stages (Figure 2.6, p. 41):
• Development/Component Testing: Individual components are tested independently.
Components may be functions, objects, or coherent groupings of these entities.
• System Testing: Testing of the system as a whole. Testing of emergent properties
(behaviours arising from component interactions) is particularly important.
• Acceptance Testing: Testing with customer data to check that the system meets the
customer's needs. May reveal errors in the requirements definition. [p. 42]
10.4 Software Evolution
Software is inherently flexible and can change. As requirements change through changing
business circumstances, the software that supports the business must also evolve and
change. [p. 43]
Although there has historically been a demarcation between development and evolution
(maintenance), this distinction is increasingly irrelevant as fewer and fewer systems are
completely new. The book describes software engineering as an evolutionary process where
software is continually changed over its lifetime in response to changing requirements and
customer needs. [p. 43]

System Evolution Cycle (Figure 2.8, p. 44): The evolution cycle is: Define system
requirements → Assess existing systems → Propose system changes → Modify
systems → New system. This new system then becomes the 'existing system' in the next
cycle — evolution is continuous, not one-time.

Key Points Summary

This PPT covers advanced SDLC models across two major areas:

Agile Methods:
• Agile SDLC methods speed up development by reducing formality, enabling rapid
delivery for time-critical applications. [p. 57]
• Eight major agile methods exist: ASD, FDD, Crystal Clear, DSDM, RAD, Scrum, XP, and
RUP. [p. 59]
• XP's 12 practices push common-sense software development practices to extreme
levels, with coding, testing, and collaboration at the core. [p. 64]
• FDD organises development around small features (< 2 weeks) expressed in client-
understandable terms.
• DSDM applies the 80/20 rule with fixed time/cost and adjustable functionality, governed
by nine core principles.

Process Models:
• The Spiral Model explicitly addresses risk, making it suitable for medium-to-high risk
projects. [p. 48]
• RUP is a hybrid model with four phases (Inception, Elaboration, Construction, Transition)
and nine static workflows. [p. 50]
 • RUP's six best practices — iterative development, requirements management,
component-based architecture, visual modelling, quality verification, change control —
represent current software engineering best practice. [p. 52]

Quality and Reuse:

• Software quality = degree to which the software satisfies stated and implied
requirements. Quality must be controlled because poor quality increases costs. [p. 656]
• A QA Plan must cover defect tracking, unit testing, source-code tracing, technical
reviews, integration testing, and system testing.
• Reuse-oriented SE assembles systems from COTS, web services, or object packages. It
reduces development cost but requires requirements compromise. [p. 34]
• The four process activities — specification, design, validation, evolution — are present in
all processes but organised differently depending on the model used. [p. 36]

— End of SDLC Models Descriptive Notes —