Chapter 1: Introduction — Descriptive Notes
SOFTWARE ENGINEERING
Chapter 1: Introduction
Descriptive Notes — Based on Ian Sommerville, 9th Edition
1. Software Engineering
Software engineering is central to the modern world. According to Sommerville, we cannot run
the modern world without software. National infrastructures and utilities are controlled by
computer-based systems, manufacturing and distribution is fully computerized, and
entertainment industries rely heavily on software. This makes software engineering essential for
the functioning of national and international societies. [Sommerville, p. 4]
The economies of all developed nations are dependent on software, and expenditure on
software represents a significant fraction of GNP. More and more systems are software-
controlled, making the discipline increasingly relevant. [Sommerville, p. 4–5]
2. Software Costs
Software costs are a major concern in any technology investment. Sommerville highlights two
important cost realities: [Sommerville, p. 8–9]
• Software costs often dominate computer system costs. For a personal computer, the
cost of installed software often exceeds the cost of the hardware itself.
• Software costs more to maintain than to develop. For systems with a long operational
life, maintenance costs may be several times higher than the original development costs.
This is why software engineering is specifically concerned with cost-effective software
development — not merely functional development, but development that remains economical
throughout the system's lifecycle. [Sommerville, p. 9]
3. Software Products
Sommerville distinguishes two fundamental kinds of software products that engineers develop:
[Sommerville, p. 6–7]
3.1 Generic Products
Generic products are stand-alone systems produced by a development organisation and sold
on the open market to any customer who wishes to buy them. Examples include PC
applications such as graphics programs, project management tools, CAD software, and dental
appointment systems. The specification for what the software should do is owned and controlled
Based on: Software Engineering, 9th Edition — Ian Sommerville | Page 1
Chapter 1: Introduction — Descriptive Notes
by the software developer. Decisions on changes, updates, and new features are made entirely
by the developer. [Sommerville, p. 6–7]
3.2 Customized (Bespoke) Products
Customized products are software systems commissioned by a specific customer to meet their
unique operational needs. Examples include embedded control systems, air traffic control
software, and traffic monitoring systems. In this case, the software specification is owned and
controlled by the customer, and the development team must adhere to it. Any software changes
must be approved by the customer. [Sommerville, p. 7]
An important trend noted by Sommerville is that the boundary between these two types is
increasingly blurred. Many systems are now built on a generic product as a base — such as
ERP systems like SAP — and then adapted to meet specific customer requirements.
[Sommerville, p. 7]
4. Frequently Asked Questions About Software Engineering
Sommerville provides a concise FAQ in Figure 1.1 (p. 6) that covers the foundational
understanding of software engineering. The key Q&A pairs are summarized below:
[Sommerville, p. 6]
• What is software?: Computer programs and associated documentation. Software
products may be developed for a particular customer or for a general market.
[Sommerville, p. 6]
• What are the attributes of good software?: Good software should deliver the required
functionality and performance to the user and should be maintainable, dependable, and
usable. [Sommerville, p. 6]
• What is software engineering?: An engineering discipline concerned with all aspects
of software production. [Sommerville, p. 6]
• Fundamental SE activities: Software specification, software development, software
validation, and software evolution. [Sommerville, p. 6]
• SE vs. Computer Science: Computer science focuses on theory and fundamentals;
software engineering is concerned with the practicalities of developing and delivering
useful software. [Sommerville, p. 6]
• SE vs. System Engineering: System engineering covers all aspects of computer-based
systems development including hardware, software, and process engineering. Software
engineering is part of this broader process. [Sommerville, p. 6]
• Key challenges: Coping with increasing diversity, demands for reduced delivery times,
and developing trustworthy software. [Sommerville, p. 6]
• Cost breakdown: Roughly 60% of software costs are development costs; 40% are
testing costs. For custom software, evolution costs often exceed development costs.
[Sommerville, p. 6]
• Web's impact: The web has led to the availability of software services and the
possibility of developing highly distributed service-based systems, advancing
programming languages and reuse. [Sommerville, p. 6]
Based on: Software Engineering, 9th Edition — Ian Sommerville | Page 2
Chapter 1: Introduction — Descriptive Notes
5. Essential Attributes of Good Software
Sommerville identifies four essential product characteristics (Figure 1.2, p. 8) that any
professional software system must exhibit: [Sommerville, p. 7–8]
• Maintainability: Software must be written so it can evolve to meet changing customer
needs. Change is inevitable in any business environment, making this the most critical
long-term attribute. [Sommerville, p. 8]
• Dependability and Security: Software dependability encompasses reliability, security,
and safety. A dependable system must not cause physical or economic damage on
failure, and must resist malicious attack. [Sommerville, p. 8]
• Efficiency: Software should not waste system resources such as memory and
processor cycles. This includes responsiveness, processing time, and memory
utilisation. [Sommerville, p. 8]
• Acceptability: Software must be acceptable to its target users — it must be
understandable, usable, and compatible with the other systems they use. [Sommerville,
p. 8]
6. Software Engineering — Definition and Scope
Sommerville formally defines software engineering as: [Sommerville, p. 7–8]
"Software engineering is an engineering discipline that is concerned with all
aspects of software production from the early stages of system specification
through to maintaining the system after it has gone into use."
There are two key phrases in this definition: [Sommerville, p. 7]
• Engineering discipline: Engineers apply theories, methods, and tools where appropriate,
recognising organisational and financial constraints. They seek solutions even when no
established method exists.
• All aspects of software production: This is not limited to technical development. It also
includes project management and the development of supporting tools, methods, and
theories.
Engineering is about getting results of the required quality within schedule and budget — this
often requires compromises. Software engineers adopt a systematic and organised approach as
this is typically the most effective way to produce high-quality software. [Sommerville, p. 8]
7. Importance of Software Engineering
Sommerville argues that software engineering matters for two key reasons: [Sommerville, p. 8–
9]
1. More and more, individuals and society rely on advanced software systems. We need to
be able to produce reliable and trustworthy systems economically and quickly.
Based on: Software Engineering, 9th Edition — Ian Sommerville | Page 3
Chapter 1: Introduction — Descriptive Notes
2. It is usually cheaper in the long run to use software engineering methods and techniques
rather than treating development as a personal programming project. For most system
types, the majority of costs arise from changing software after it has gone into use.
Without software engineering, many of the modern world's greatest achievements — space
exploration, the internet, modern telecommunications — would not have been possible.
[Sommerville, p. 4]
8. Software Process Activities
A software process is a sequence of activities that leads to the production of a software product.
Sommerville identifies four fundamental activities common to all software processes:
[Sommerville, p. 9]
3. Software Specification — Customers and engineers define the software to be produced
and the constraints on its operation.
4. Software Development — The software is designed and programmed.
5. Software Validation — The software is checked to ensure it is what the customer
requires.
6. Software Evolution — The software is modified to reflect changing customer and market
requirements.
Different types of systems need different development processes. Real-time safety-critical
systems require complete specification before development begins, while e-commerce systems
may develop the specification and program concurrently. [Sommerville, p. 9]
9. General Issues Affecting Software
Sommerville identifies three overarching challenges that affect most software systems in today's
environment: [Sommerville, p. 9–10]
• Heterogeneity: Systems are increasingly required to operate as distributed systems
across networks including different types of computers and mobile devices. New
software must often integrate with older legacy systems written in different programming
languages. [Sommerville, p. 10]
• Business and Social Change: Business and society are changing incredibly quickly as
emerging economies develop and new technologies become available. Organisations
need to change existing software and rapidly develop new software, but many traditional
SE techniques are time-consuming. [Sommerville, p. 10]
• Security and Trust: As software is intertwined with all aspects of our lives, we must be
able to trust it. Remote software systems accessed through web pages or services must
be secured against malicious users while ensuring information security is maintained.
[Sommerville, p. 10]
Based on: Software Engineering, 9th Edition — Ian Sommerville | Page 4
Chapter 1: Introduction — Descriptive Notes
10. Software Engineering Diversity
There is no universal set of software techniques applicable to all software systems. Software
engineering methods and tools depend on: [Sommerville, p. 10]
• The type of application being developed
• The requirements of the customer
• The background of the development team
Sommerville emphasises this is not just theoretical — the same approach that works for a web-
based e-commerce system would be completely inappropriate for a safety-critical embedded
automotive controller. [Sommerville, p. 12]
11. Application Types
Sommerville lists eight major categories of software systems, each requiring different
engineering approaches (pp. 10–12): [Sommerville, p. 10–12]
• Stand-alone applications: Application systems running on a local computer, including
all necessary functionality without needing a network (e.g., office software, CAD
programs, photo manipulation tools). [Sommerville, p. 10]
• Interactive transaction-based applications: Applications executing on a remote
computer accessed by users through PCs or terminals, including web and e-commerce
applications and cloud-based services. [Sommerville, p. 11]
• Embedded control systems: Software control systems that control and manage
hardware devices. Numerically, there are more embedded systems than any other type
(e.g., mobile phone software, anti-lock braking systems). [Sommerville, p. 11]
• Batch processing systems: Business systems designed to process data in large
batches — for example, phone billing systems and salary payment systems.
[Sommerville, p. 11]
• Entertainment systems: Systems primarily for personal use intended to entertain the
user, mostly games, where quality of user interaction is the key distinguishing
characteristic. [Sommerville, p. 11]
• Systems for modelling and simulation: Systems developed by scientists and
engineers to model physical processes or situations, often computationally intensive and
requiring high-performance parallel execution. [Sommerville, p. 11]
• Data collection systems: Systems that collect data from their environment using
sensors and send that data to other systems for processing, often installed in hostile
environments. [Sommerville, p. 11]
• Systems of systems: Systems composed of a number of other software systems, some
generic and some specially written for the environment. [Sommerville, p. 11]
12. Software Engineering Fundamentals
Despite the diversity of application types, Sommerville identifies four fundamental principles that
apply to all software systems: [Sommerville, p. 12]
Based on: Software Engineering, 9th Edition — Ian Sommerville | Page 5
Chapter 1: Introduction — Descriptive Notes
7. Systems should be developed using a managed and understood development process.
The organisation must plan development and have clear ideas of what will be produced
and when.
8. Dependability and performance are important for all types of systems. Software should
behave as expected without failures, be safe in operation, and perform efficiently.
9. Understanding and managing the software specification and requirements is important
— knowing what customers and users expect and managing those expectations to
deliver within budget and schedule.
10. Effective use should be made of existing resources. Where appropriate, reuse software
that has already been developed rather than writing new software from scratch.
13. Software Engineering and the Web
The development of the World Wide Web has had a profound effect on software engineering
practice. Around 2000, the Web evolved so that web-based systems could be accessed through
browsers, leading to vast new system products delivering innovative services. Sommerville
notes three key changes: [Sommerville, p. 13–14]
11. Software reuse has become the dominant approach for constructing web-based
systems. Developers think about how to assemble systems from pre-existing
components and services rather than building from scratch.
12. It is now generally recognised that specifying all requirements in advance for web-based
systems is impractical. Web-based systems must be developed and delivered
incrementally.
13. User interfaces are constrained by web browser capabilities. Technologies such as
AJAX allow rich interfaces within a browser, but web forms with local scripting are more
commonly used.
The fundamental ideas of software engineering still apply to web-based software. Cloud
computing — where applications run on shared computing infrastructure accessed over the
internet — represents the latest stage of this evolution. Users pay according to use rather than
purchasing software outright. [Sommerville, p. 13–14]
14. Software Engineering Ethics
Software engineering involves wider responsibilities than merely applying technical skills.
Sommerville argues that software engineers must behave in an ethical and morally responsible
way to be respected as professionals. Ethical behaviour goes beyond upholding the law — it
involves following a set of morally correct principles. [Sommerville, p. 14]
14.1 Issues of Professional Responsibility
Sommerville identifies four core areas of professional responsibility: [Sommerville, p. 14]
• Confidentiality: Engineers should normally respect the confidentiality of their employers
or clients, irrespective of whether a formal confidentiality agreement has been signed.
[Sommerville, p. 14]
Based on: Software Engineering, 9th Edition — Ian Sommerville | Page 6
Chapter 1: Introduction — Descriptive Notes
• Competence: Engineers should not misrepresent their level of competence. They
should not knowingly accept work outside their competence. [Sommerville, p. 14]
• Intellectual Property Rights: Engineers should be aware of local laws governing
intellectual property such as patents and copyright, and should protect the intellectual
property of employers and clients. [Sommerville, p. 14]
• Computer Misuse: Software engineers should not use their technical skills to misuse
other people's computers. Misuse ranges from relatively trivial (game playing on an
employer's machine) to extremely serious (dissemination of viruses or malware).
[Sommerville, p. 14]
15. The ACM/IEEE Code of Ethics
The ACM and IEEE have cooperated to produce a joint Code of Ethics and Professional
Practice (Figure 1.3, p. 15). The code exists in both short and long form and is based on the
rationale that software engineers have significant opportunities to do good or cause harm, and
must commit themselves to making software engineering beneficial and respected.
[Sommerville, p. 15–16]
The Code contains eight principles: [Sommerville, p. 15]
14. PUBLIC — Software engineers shall act consistently with the public interest.
15. CLIENT AND EMPLOYER — Software engineers shall act in the best interests of their
client and employer, consistent with the public interest.
16. PRODUCT — Software engineers shall ensure their products meet the highest
professional standards possible.
17. JUDGMENT — Software engineers shall maintain integrity and independence in their
professional judgment.
18. MANAGEMENT — Software engineering managers and leaders shall subscribe to and
promote an ethical approach to managing software development and maintenance.
19. PROFESSION — Software engineers shall advance the integrity and reputation of the
profession.
20. COLLEAGUES — Software engineers shall be fair to and supportive of their colleagues.
21. SELF — Software engineers shall participate in lifelong learning regarding the practice
of their profession.
16. Ethical Dilemmas
Sommerville acknowledges that ethical dilemmas are a real part of professional practice.
Common scenarios include: [Sommerville, p. 16–17]
• Disagreement in principle with the policies of senior management.
• An employer acting unethically — for example, releasing a safety-critical system without
completing required safety testing.
• Participation in the development of military weapons systems or nuclear systems, where
engineers may have strong personal objections.
Based on: Software Engineering, 9th Edition — Ian Sommerville | Page 7
Chapter 1: Introduction — Descriptive Notes
Sommerville notes there are no absolute answers in such situations. The appropriate ethical
position depends entirely on the views of the individuals involved, the potential for damage, the
extent of possible harm, and the people affected. The engineer must balance confidentiality to
their employer against the public interest. [Sommerville, p. 16–17]
17. Case Studies
To illustrate software engineering concepts throughout the book, Sommerville introduces three
case studies representing different system types. Each is chosen because software engineering
practice depends heavily on the type of system being produced. [Sommerville, p. 17–18]
17.1 Insulin Pump Control System (Embedded System)
An insulin pump is a medical device that simulates the operation of the pancreas. The
embedded software collects information from a blood glucose sensor and controls a micropump
to deliver a controlled dose of insulin to users with diabetes. [Sommerville, p. 18–20]
The hardware architecture (Figure 1.4, p. 19) includes a blood sensor, pump, clock, controller,
alarm, two displays, and a power supply. The activity model (Figure 1.5, p. 19) illustrates how
the software transforms blood sugar readings into pump commands. [Sommerville, p. 19]
This is a safety-critical system. Low blood glucose can lead to temporary brain malfunction,
coma, and death; high blood glucose has long-term consequences including eye and kidney
damage. The two essential high-level requirements are: [Sommerville, p. 19–20]
22. The system shall be available to deliver insulin when required.
23. The system shall perform reliably and deliver the correct amount of insulin to counteract
the current blood sugar level.
17.2 MHC-PMS — Mental Health Care Patient Management System
(Information System)
The MHC-PMS is a medical information system that maintains records of patients suffering from
mental health problems and the treatments they have received. Most mental health patients
attend specialist clinics rather than hospitals, so the system must work in diverse clinical
environments. [Sommerville, p. 20–21]
The system uses a centralised database but has been designed to run on a PC so it can
operate from sites without secure network connectivity. When connected, it uses the central
database; when disconnected, it uses local copies of patient records. [Sommerville, p. 20]
The two overall goals of MHC-PMS are: [Sommerville, p. 20]
24. To generate management information allowing health service managers to assess
performance against local and government targets.
25. To provide medical staff with timely information to support patient treatment.
Based on: Software Engineering, 9th Edition — Ian Sommerville | Page 8
Chapter 1: Introduction — Descriptive Notes
Key features include individual care management (clinicians creating and editing patient
records), patient monitoring (issuing warnings about potentially dangerous patients), and
administrative reporting (monthly management reports). Critical concerns include privacy
(patient information must be strictly confidential) and safety (the system must warn staff about
potentially suicidal or dangerous patients). [Sommerville, p. 21–22]
17.3 Wilderness Weather Station (Sensor-Based Data Collection System)
The government of a country with large wilderness areas deploys several hundred weather
stations in remote locations. Each station collects data on temperature, pressure, sunshine,
rainfall, wind speed, and wind direction. [Sommerville, p. 22–23]
The system is part of a larger weather information system (Figure 1.7, p. 22) consisting of three
sub-systems: [Sommerville, p. 22]
26. The weather station system — responsible for collecting weather data, initial processing,
and transmitting to the data management system.
27. The data management and archiving system — collects data from all stations, processes
and analyses it, and archives it for retrieval.
28. The station maintenance system — communicates by satellite with all weather stations
to monitor health, report problems, and update embedded software.
Because stations are battery-powered, self-contained, deployed in hostile environments, and
unattended, the software must go beyond simple data collection. Additional software
functionality includes: [Sommerville, p. 23]
• Monitor instruments, power and communication hardware, and report faults to the
management system.
• Manage system power — ensuring batteries are charged while shutting down generators
in potentially damaging weather conditions such as high wind.
• Support dynamic reconfiguration — replacing parts of the software with new versions
and switching backup instruments into service in the event of system failure.
Summary: Key Points
The following key points from Chapter 1 are highlighted by Sommerville: [Sommerville, p. 24]
• Software engineering is an engineering discipline concerned with all aspects of software
production.
• Software is not just programs but also includes documentation. Essential attributes are
maintainability, dependability, security, efficiency, and acceptability.
• The high-level activities of specification, development, validation, and evolution are part
of all software processes.
• The fundamental notions of software engineering — processes, dependability,
requirements, management, and reuse — are universally applicable to all types of
system development.
• There are many different types of systems, and each requires appropriate software
engineering tools and techniques.
Based on: Software Engineering, 9th Edition — Ian Sommerville | Page 9
Chapter 1: Introduction — Descriptive Notes
• Software engineers have responsibilities to the engineering profession and to society.
They should not simply be concerned with technical issues.
• Professional societies publish codes of conduct that set out the standards of behaviour
expected of their members.
Based on: Software Engineering, 9th Edition — Ian Sommerville | Page 10