SOFTWARE ENGINEERING

9th Edition — Ian Sommerville

Chapter 2: Software Processes — Descriptive Notes
 LECTURE 1

1. Capability Maturity Model (CMM)

The Capability Maturity Model (CMM) is a benchmark for measuring the maturity of an
organisation's software process. It was developed by the Software Engineering Institute (SEI)
at Carnegie Mellon University to help organisations evaluate and improve their software
development processes. [p. 29]
The CMM defines 5 levels of process maturity based on certain Key Process Areas (KPA).
Each level represents a different degree of process capability, from chaotic (Level 1) to
continuously optimising (Level 5).

CMM Level Name Approx. % of Key Process Areas

Orgs

Level 1 Initial ~70% No defined processes. Success depends on

individual heroics. Unpredictable outcomes.

Level 2 Repeatable ~15% Requirements management, software project

planning, tracking & oversight, quality
assurance, configuration management.

Level 3 Defined <10% Peer reviews, intergroup coordination, software

product engineering, integrated software
management, training program, organisation
process definition & focus.

Level 4 Managed <5% Software quality management, quantitative

process management. Processes are measured
and controlled.

Level 5 Optimizing <1% Defect prevention, technology change

management, process change management.
Continuous improvement focus.

Key Insight: The vast majority of organisations (~70%) operate at Level 1, meaning their
processes are ad hoc and chaotic. Only the most mature organisations reach Level 5.
Moving from one level to the next requires systematic improvement of Key Process Areas.
2. The Software Process
A software process is a structured set of activities required to develop a software system.
Despite the variety of approaches, all software processes share four fundamental activities: [p.
27]

1. Specification: Defining what the system should do; establishing the requirements and
constraints on the system's operation.
2. Design and Implementation: Defining the organisation of the system and translating
that organisation into an executable system.
3. Validation: Checking that the system does what the customer wants; verifying that it
conforms to its specification.
4. Evolution: Changing the system in response to changing customer needs and market
requirements.

A software process model is an abstract representation of a process, presenting a description

from a particular perspective. These models are not definitive descriptions but abstractions that
can be extended and adapted to create more specific engineering processes. [p. 29]

3. Software Process Descriptions

When describing and discussing software processes, we talk about the activities in those
processes and their ordering. Process descriptions may also include: [p. 28]

• Products: The outcomes of a process activity. For example, the outcome of

architectural design is a model of the software architecture.
• Roles: Reflect the responsibilities of people involved in the process. Examples: project
manager, configuration manager, programmer.
• Pre- and Post-conditions: Statements that are true before and after a process activity
has been enacted or a product produced. Example: before architectural design begins,
all requirements must be approved by the customer.

4. Plan-Driven and Agile Processes

Software processes are broadly categorised as either plan-driven or agile, though in practice
most projects blend elements of both: [p. 29]
 • Plan-Driven Processes: All of the process activities are planned in advance and
progress is measured against this plan. Documentation-heavy; suitable for large or
critical systems where requirements are stable.
• Agile Processes: Planning is incremental and it is easier to change the process to
reflect changing customer requirements. Less documentation; suitable for business
systems where requirements evolve rapidly.

Important (p. 29): In practice, most practical processes include elements of both plan-
driven and agile approaches. There are no right or wrong software processes — the best
process depends on the type of system, team, and organisation.

5. Software Process Models

The book identifies three generic process models that serve as frameworks for more specific
development processes: [p. 29]

• The Waterfall Model: A plan-driven model with separate and distinct phases of
specification and development. Each phase must be completed before the next begins.
[p. 30]
• Incremental Development: Specification, development, and validation are interleaved.
The system is built as a series of versions. May be plan-driven or agile. [p. 32]
• Reuse-Oriented Software Engineering: The system is assembled from existing
reusable components. May be plan-driven or agile. [p. 34]

Note (p. 30): In practice, most large systems are developed using a process that
incorporates elements from all of these models. No single model is universally superior.

6. The Waterfall Model

The Waterfall Model is the first and most widely known software process model. It takes the
fundamental development activities and represents them as separate, sequential process
phases, like a cascade from one phase to another. It is a plan-driven process — in principle, all
activities must be planned and scheduled before work begins. [p. 30]

6.1 Waterfall Phases

The Waterfall Model has five clearly defined phases: [p. 31]
 5. Requirements Analysis and Definition: The system's services, constraints, and goals
are established by consultation with users. These are defined in detail and serve as a
system specification.
6. System and Software Design: The design process allocates requirements to hardware
or software systems. Software design involves identifying fundamental software
abstractions and their relationships.
7. Implementation and Unit Testing: The software design is realized as programs or
program units. Unit testing involves verifying that each unit meets its specification.
8. Integration and System Testing: Individual program units are integrated and tested as
a complete system to ensure requirements have been met. The software system is
delivered to the customer.
9. Operation and Maintenance: Normally the longest phase. The system is installed and
put into practical use. Maintenance involves correcting errors, improving implementation,
and enhancing services as new requirements are discovered.

6.2 Waterfall: Strengths, Deficiencies, and When to Use

✅ Strengths ❌ Weaknesses / Deficiencies

Easy to understand and easy to use. All requirements must be known upfront — rarely
possible in practice.

Provides structure to inexperienced staff. Deliverables for each phase are considered
'frozen', inhibiting flexibility.

Milestones are well understood and clearly Can give a false impression of progress.
defined.

Sets requirements stability — good when Does not reflect the iterative, problem-solving
requirements are known. nature of software development.

Good for management control (plan, staff, track Integration is one 'big bang' at the end, increasing
progress). integration risk.

Works well when quality is more important than Little opportunity for the customer to preview the
cost or schedule. system until it may be too late.

🔧 When to Use: Requirements are very well known and stable. | Product definition is
stable. | Technology is well understood. | New version of an existing product or porting to a
new platform.
6.3 Waterfall Model Problems
The major drawback of the Waterfall Model is the difficulty of accommodating change after
the process is underway. In principle, a phase has to be complete before moving to the next.
The book notes: [p. 32]
• Inflexible partitioning of the project into distinct stages makes it difficult to respond to
changing customer requirements.
• Few business systems have stable requirements — making the Waterfall Model
unsuitable for most business applications.
• The Waterfall Model is mostly used for large systems engineering projects developed
at several sites, where the plan-driven nature helps coordinate work across teams.

7. The Iterative Waterfall Model

The Iterative Waterfall Model is a modification of the classic Waterfall Model that allows for
feedback loops between phases. Rather than a strictly linear sequence, this model permits
teams to return to earlier phases when problems are discovered in later stages.
A Feasibility Study is typically added as the first step, assessing whether the proposed system
is technically and financially viable before committing to full development. This reduces risk by
identifying potential problems early.

Improvement over Classic Waterfall: By allowing iteration between phases, the Iterative
Waterfall is more realistic. In the classic model, problems discovered late (e.g., during
testing) could only be corrected by restarting from the beginning. The iterative version allows
controlled backtracking.

8. The V-Shaped (V-Model) SDLC Model

The V-Model is a variant of the Waterfall Model that explicitly emphasises the relationship
between development phases and their corresponding testing activities. Testing of the product
is planned in parallel with the corresponding development phase — for every phase of
development there is a directly associated testing phase.

8.1 V-Model Steps

The V-Model consists of the following steps, with the left side representing development and the
right side representing the corresponding testing activities:

Development Phase (Left Side) Corresponding Test Phase (Right Side)

 Project and Requirements Planning — allocate System and Acceptance Testing — check the
resources and define scope. entire software system in its environment.

Product Requirements and Specification Analysis Integration and Testing — check that modules
— complete specification of the software system. interconnect correctly.

Architecture / High-Level Design — defines how Unit Testing — check that each module acts as
software functions fulfil the design requirements. expected.

Detailed Design — develop algorithms for each (All test plans are created during this phase)
architectural component.

Coding — transform algorithms into software. (Bottom of the 'V' — the lowest point where
development and testing meet)

8.2 V-Model: Strengths, Weaknesses, and When to Use

✅ Strengths ❌ Weaknesses / Deficiencies

Emphasises planning for verification and Does not easily handle concurrent events.
validation early in development.

Each deliverable must be testable — improves Does not handle iterations within or across
quality focus. phases.

Project management can track progress by Does not easily handle dynamic changes in
milestones. requirements.

Easy to understand and use. Does not contain risk analysis activities — no risk
management built in.

🔧 When to Use: Excellent for systems requiring high reliability (e.g., hospital patient control
applications). | All requirements are known upfront. | Solution and technology are known. |
When it can be modified to handle changing requirements beyond the analysis phase.

9. The Prototype (Structured Evolutionary

Prototyping) Model
Prototyping is an approach where an initial version of the system is built quickly to explore
requirements, try design options, and get early user feedback. Rather than building the full
system upfront, a working prototype is developed, evaluated, and refined iteratively until the
user is satisfied. [p. 45]
According to Sommerville (p. 45), a prototype can be used in two key ways:
• In the requirements engineering process: to help with elicitation and validation of
system requirements.
• In the system design process: to explore particular software solutions and to support
user interface design.

9.1 Structured Evolutionary Prototyping Steps

The prototyping process (Figure 2.9, p. 45) follows these steps:

10. Develop a preliminary project plan and a partial high-level paper model.
11. Create a partial requirements specification from this model.
12. Build a prototype with basic and critical attributes — including the database, user
interface, and algorithmic functions.
13. The designer demonstrates the prototype; the user evaluates it for problems and
suggests improvements.
14. The cycle of evaluation and refinement continues until the user is satisfied. The
prototype code is then brought up to the standards needed for a final product.

Warning (p. 46): Developers are sometimes pressured to deliver throwaway prototypes as
production systems. This is usually unwise because: (1) non-functional requirements such
as performance, security and reliability were ignored during prototyping; (2) the prototype is
undocumented; (3) the structure has degraded through rapid change; (4) quality standards
were relaxed.

9.2 Prototyping: Strengths, Weaknesses, and When to Use

✅ Strengths ❌ Weaknesses / Deficiencies

Customers can 'see' requirements as they are Tendency to abandon structured development for
being gathered. 'code-and-fix' methods.

Developers learn directly from customers. Bad reputation for 'quick-and-dirty' methods.

Leads to a more accurate end product. Overall maintainability may be overlooked.

Unexpected requirements can be accommodated. The customer may want the prototype delivered
as the final product.

Allows for flexible design and development. Process may continue forever — scope creep is a
serious risk.

Steady, visible signs of progress are produced.

 Interaction with the prototype stimulates
awareness of additional needed functionality.

🔧 When to Use: Requirements are unstable or must be clarified. | As the requirements

clarification stage of a Waterfall model. | For developing user interfaces. | Short-lived
demonstrations or proofs of concept. | New, original development with unclear scope. | With
the analysis and design portions of object-oriented development.

10. The Incremental Development Model

Incremental development is based on the idea of developing an initial implementation,
exposing it to user comment, and evolving it through several versions until an adequate
system has been developed. Specification, development, and validation activities are
interleaved rather than separate, with rapid feedback across activities. [p. 32]
In this model, each increment delivers an operational product with a subset of the system's
functionality. The most important or most urgently required functionality is typically included in
the earliest increments, giving the customer immediate value.

10.1 Incremental Development Benefits

The book (p. 33) identifies three important benefits compared to the Waterfall Model:

15. Reduced cost of accommodating changing requirements: The amount of analysis

and documentation that has to be redone is much less than with the Waterfall Model.
16. Easier customer feedback: Customers can comment on demonstrations of the
software and see how much has been implemented. This is much more effective than
reviewing abstract documents.
17. More rapid delivery: Useful software is delivered and deployed to the customer more
quickly. Customers are able to use and gain value from the software earlier than is
possible with a Waterfall process.

10.2 Incremental Development Problems

The book (p. 34) also identifies two significant management problems:
 18. The process is not visible: Managers need regular deliverables to measure progress.
If systems are developed quickly, it is not cost-effective to produce documents that
reflect every version of the system.
19. System structure tends to degrade as new increments are added: Unless time and
money is spent on refactoring to improve the software, regular change tends to corrupt
its structure. Incorporating further software changes becomes increasingly difficult and
costly.

10.3 Incremental Model: Strengths, Weaknesses, and When to Use

✅ Strengths ❌ Weaknesses / Deficiencies

Develop high-risk or major functions first. Requires good planning and design upfront.

Each release delivers an operational product. Requires early definition of a complete and fully
functional system to allow definition of
increments.

Customer can respond to each build. Well-defined module interfaces are required.

Uses 'divide and conquer' breakdown of tasks. Total cost of the complete system is not lower
than other approaches.

Lowers initial delivery cost.

Initial product delivery is faster.

Risk of changing requirements is reduced.

🔧 When to Use: Risk, funding, schedule, complexity, or need for early realisation of
benefits. | Most requirements are known upfront but expected to evolve. | Need to get basic
functionality to market early. | Projects with lengthy development schedules. | Projects
involving new or uncertain technology.
 LECTURE 2

11. Boehm's Spiral Model

The Spiral Model, proposed by Barry Boehm (1988), is a risk-driven software process
framework. Unlike other models that represent the process as a sequence of activities, the
software process here is represented as a spiral. Each loop in the spiral represents a phase of
the software process. [p. 48]
The innermost loop might be concerned with system feasibility, the next with requirements
definition, the next with system design, and so on. The Spiral Model combines change
avoidance with change tolerance. It assumes that changes are a result of project risks and
includes explicit risk management activities to reduce those risks. [p. 48]

11.1 The Four Spiral Quadrants

Each loop in the spiral is split into four sectors (quadrants): [p. 49]

20. Determine Objectives, Alternatives and Constraints: Specific objectives for that
phase are defined. Constraints on the process and product are identified, and a detailed
management plan is drawn up. Project risks are identified. Objectives include:
functionality, performance, hardware/software interface, critical success factors.
Alternatives include: build, reuse, buy, sub-contract.
21. Evaluate Alternatives, Identify and Resolve Risks: For each identified project risk, a
detailed analysis is carried out. Steps are taken to reduce the risk. For example, if there
is a risk that requirements are inappropriate, a prototype system may be developed.
Sources of risk include: lack of experience, new technology, tight schedules, poor
processes.
22. Develop Next-Level Product: After risk evaluation, a development model for the
system is chosen and the development is carried out. Typical activities: create a design,
review design, develop code, inspect code, test product. The chosen development
approach depends on the dominant risks identified in Quadrant 2.
23. Plan Next Phase: The project is reviewed and a decision is made whether to continue
with a further loop of the spiral. Typical activities: develop project plan, configuration
management plan, test plan, and installation plan.

Key Difference from Other Models (p. 50): The main difference between the Spiral Model
and other software process models is its explicit recognition of risk. A cycle of the spiral
begins by elaborating objectives, enumerating alternatives, assessing risks, resolving them,
 then developing and planning the next phase.

11.2 Spiral Model: Strengths, Weaknesses, and When to Use

✅ Strengths ❌ Weaknesses / Deficiencies

Provides early indication of insurmountable risks, Time spent evaluating risks may be too large for
without much cost. small or low-risk projects.

Users see the system early because of rapid Time spent planning, resetting objectives, and
prototyping tools. prototyping may be excessive.

Critical high-risk functions are developed first. The model is complex to understand and
manage.

The design does not have to be perfect — Risk assessment expertise is required — not
evolves with each loop. always available.

Users can be closely tied to all lifecycle steps. Spiral may continue indefinitely if not controlled.

Early and frequent feedback from users. Developers must be reassigned during non-
development phase activities.

Cumulative costs assessed frequently. May be hard to define objective, verifiable

milestones.

🔧 When to Use: When creation of a prototype is appropriate. | When costs and risk
evaluation are important. | For medium to high-risk projects. | When users are unsure of
their needs. | When requirements are complex. | New product lines or research/exploration
projects. | When significant changes are expected.

12. The Evolutionary Model

The Evolutionary Model views software development as an evolutionary process rather than
two separate activities of development and maintenance. The book argues (p. 43) that the
distinction between development and maintenance is increasingly irrelevant:
Hardly any software systems are completely new systems. It makes much more sense to see
development and maintenance as a continuum. Rather than two separate processes, it is more
realistic to think of 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): Define system requirements → Assess
existing systems → Propose system changes → Modify systems → New system (which
then becomes the new 'existing system' in the next cycle).

13. Software Process Activities

The four basic process activities — specification, development, validation, and evolution — are
organised differently in different development processes. In the Waterfall Model, they are
sequential; in incremental development, they are interleaved. [p. 36]

13.1 Software Specification (Requirements Engineering)

Software specification, or requirements engineering, is the process of understanding and
defining what services are required from the system and identifying the constraints on its
operation. It is a particularly critical stage as errors at this stage inevitably lead to later
problems in design and implementation. [p. 36]
The requirements engineering process has four main activities:
• Feasibility Study: An estimate of whether the identified user needs may be satisfied
using current software and hardware technologies, and whether the system will be cost-
effective.
• Requirements Elicitation and Analysis: Deriving system requirements through
observation of existing systems, discussions with users, task analysis, prototypes, and
models.
• Requirements Specification: Translating gathered information into a document that
defines the requirements. Includes user requirements (abstract) and system
requirements (detailed).
• Requirements Validation: Checking the requirements for realism, consistency, and
completeness. Errors in the requirements document are identified and corrected. [p. 37]

13.2 Software Design and Implementation

The implementation stage is the process of converting a system specification into an executable
system. It always involves software design and programming. [p. 38]
The design process involves four main activities (Figure 2.5, p. 39):
• Architectural Design: Identifying the overall structure of the system, its principal
components, their relationships, and how they are distributed.
• Interface Design: Defining the interfaces between system components. With a precise
interface, a component can be used without others needing to know how it is
implemented.
 • Component Design: Taking each system component and designing how it will operate.
This may be a simple statement of expected functionality or a detailed design model.
• Database Design: Designing the system data structures and how these are to be
represented in a database. [p. 39]

13.3 Software Validation

Software validation — or Verification and Validation (V&V) — is intended to show that a system
conforms to its specification and meets the expectations of the customer. Program testing is
the principal validation technique. [p. 41]
Testing proceeds through three stages (Figure 2.6, p. 41):
• Development Testing: Components are tested by the people developing the system.
Each component is tested independently without other system components. Test
automation tools such as JUnit are commonly used.
• System Testing: Components are integrated to create a complete system. Concerned
with finding errors from unanticipated interactions between components and with
showing that the system meets its functional and non-functional requirements.
• Acceptance Testing: The final stage before the system is accepted for operational use.
The system is tested with data supplied by the customer. May reveal errors and
omissions in the system requirements definition. [p. 42]

13.4 Software Evolution

The flexibility of software is one of its key strengths — changes can be made at any time during
or after development. Software evolution (historically called software maintenance) is the
process of modifying an existing system to meet new requirements. [p. 43]
Rather than treating development and maintenance as separate activities, Sommerville
advocates viewing them as a continuum — an evolutionary process where software is
continuously changed over its lifetime in response to changing requirements and customer
needs.

14. Coping with Change

Change is inevitable in all large software projects. Business requirements change, new
technologies emerge, and new design possibilities arise. Whatever software process model is
used, it must accommodate changes to the software being developed. [p. 43]
Change adds to the costs of software development because it usually means that completed
work has to be redone (rework). There are two related approaches to reducing the costs of
rework:
 • Change Avoidance: Activities that anticipate possible changes before significant rework
is required. Example: developing a prototype system to show key features to customers
before committing to production.
• Change Tolerance: Designing the process so that changes can be accommodated at
relatively low cost — normally through incremental development. [p. 44]

14.1 Prototyping for Change Avoidance

A prototype is an initial version of a software system used to demonstrate concepts, try out
design options, and find out more about the problem and its possible solutions (p. 45).
Rapid, iterative development of the prototype is essential so that costs are controlled and
stakeholders can experiment early.
The prototype development process (Figure 2.9, p. 45) involves: Establish Prototype Objectives
→ Define Prototype Functionality → Develop Prototype → Evaluate Prototype.

14.2 Incremental Delivery for Change Tolerance

Incremental delivery (Figure 2.10, p. 47) is an approach where some of the developed
increments are delivered to the customer and deployed for operational use. Customers
identify which services are most important, and the highest-priority services are implemented
and delivered first. [p. 47]
Advantages of incremental delivery (p. 47–48):
• Customers can use early increments as prototypes to gain experience that informs later
requirements — unlike prototypes, these are part of the real system.
• Customers do not have to wait until the entire system is delivered before gaining value
from it.
• As the highest-priority services are delivered first, the most important parts of the system
receive the most testing.

15. The Rational Unified Process (RUP)

The Rational Unified Process (RUP) is a modern generic process model derived from work on
the UML and the Unified Software Development Process. It is a hybrid process model that
brings together elements from all generic process models, illustrates good practice in
specification and design, and supports prototyping and incremental delivery. [p. 50]
The RUP is normally described from three perspectives:
• Dynamic perspective: Shows the phases of the model over time.
• Static perspective: Shows the process activities that are enacted.
• Practice perspective: Suggests good practices to be used during the process. [p. 50]
15.1 RUP Phases
The RUP identifies four discrete phases (Figure 2.12, p. 51), which are more closely related to
business concerns than technical activities:

24. Inception: Establish a business case for the system. Identify all external entities that will
interact with the system and define these interactions. If the system's contribution is
minor, the project may be cancelled here.
25. Elaboration: Develop understanding of the problem domain, establish an architectural
framework, develop the project plan, and identify key project risks. Results in a
requirements model (UML use cases), architectural description, and development plan.
26. Construction: System design, programming, and testing. Parts of the system are
developed in parallel and integrated. Results in a working software system with
documentation ready for delivery.
27. Transition: Move the system from the development community to the user community
and make it work in a real environment — often an expensive and sometimes
problematic activity. [p. 51]

15.2 RUP Six Best Practices

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

28. Develop software iteratively: Plan increments based on customer priorities; develop
the highest-priority features early.
29. Manage requirements: Explicitly document customer requirements and track changes.
Analyse the impact of changes before accepting them.
30. Use component-based architectures: Structure the system architecture into
components.
31. Visually model software: Use graphical UML models to present static and dynamic
views of the software.
32. Verify software quality: Ensure that the software meets the organisation's quality
standards.
33. Control changes to software: Manage changes using a change management system
and configuration management procedures. [p. 53]

Key Points Summary

The key points from Chapter 2 (p. 53) are:
• Software processes are the activities involved in producing a software system. Software
process models are abstract representations of these processes.
• General process models describe the organisation of software processes. Examples: the
Waterfall Model, incremental development, and reuse-oriented development. [p. 29]
• Requirements engineering is the process of developing a software specification,
intended to communicate the system needs of the customer to system developers.
• Design and implementation processes transform a requirements specification into an
executable software system. Systematic design methods may be used. [p. 38]
• Software validation is the process of checking that the system conforms to its
specification and meets the real needs of users. [p. 41]
• Software evolution takes place when existing systems are changed to meet new
requirements. Changes are continuous. [p. 43]
• Processes should include activities to cope with change — this may involve a
prototyping phase and incremental development/delivery. [p. 44]
• The Rational Unified Process is organised into phases (inception, elaboration,
construction, and transition) but separates activities from these phases. [p. 50]

— End of Chapter 2 Descriptive Notes —