Lecture 1 - Software Engineering and Software Development Processes
Learning Objective 1 — Understand what the DBA course is about
- What is DBA? Designing Business Applications (DBA) is about software development
from a business perspective.
- The focus is not on writing code, but on understanding how to design and develop valuable
software systems. The course simulates a software engineering project, including
requirements analysis and other development activities.
- Why is it important? Software increasingly contains the logic and value created by IT, making
software development an important business capability.
- Key takeaway: DBA is about understanding how to develop software that actually creates
value.
Learning Objective 2 — Explain the inherent difficulties of software systems
- There is no single development approach that works for every software project.
Different projects have different requirements and therefore require different approaches.
- Brooks 4 difficulties:
Difficulty Meaning
Complexity Software has many interconnected parts and relationships.
Conformity Software must fit existing organisational rules, systems and regulations.
Changeability Software needs to change as users, organisations and environments change.
Invisibility Software cannot easily be visualised like a physical object.
- This is why there is “no silver bullet” — no single technique that solves the fundamental
difficulties of software development.
- Key takeaway: The difficulty is not simply building software; it is understanding what people
actually need and creating something valuable for them.
Learning Objective 3 — Define software, systems, socio-technical systems, emergent
properties
- Software is more than code. It includes programs and associated documentation.
- A system consists of interacting components that work together to achieve an objective.
- Socio-technical system - a system involving technology and people.
- For DBA, the focus is mainly on software and the people who interact with it, rather than the
underlying hardware.
- Emergent properties - properties that arise from the system as a whole, rather than from
individual components.
- Two types:
- Functional: the system's parts work together to achieve an objective.
- Non-functional: properties concerning the system's behaviour, such as reliability,
performance, safety and security.
- Example: a reliable web application does not become reliable simply because every individual
component is reliable. Reliability emerges from how all the components work together.
,Learning Objective 4 — Explain software engineering, software processes, process flows
- Software Engineering - a systematic, disciplined and quantifiable approach to the
development, operation and maintenance of software.
- General software process:
- 1. Understand the problem → Requirements, stakeholders, analysis
- 2. Plan the solution → Modelling and software design
- 3. Carry out the plan → Implementation
- 4. Examine the result → Testing and quality assurance
- Software lifecycle: software engineering does not stop when the software is built. It also
includes operation, maintenance and evolution. Sommerville identifies specification,
development, validation and evolution as fundamental software process activities.
- Key takeaway: Understand → Plan → Build → Test → Maintain/Evolve
Learning Objective 5 — Compare and contrast prescriptive process flows (Waterfall, V-model,
Incremental, Prototyping, Spiral), RUP
- Waterfall - a linear process where you complete each stage before moving to the next:
requirements → design → implementation → testing → maintenance. Best when
requirements are stable.
- V-Model - similar to Waterfall, but each development stage is explicitly linked to a
corresponding testing stage. Emphasises testing and validation throughout the process.
- Incremental - the system is built and delivered in smaller parts (increments). Each increment
adds more functionality until the complete system is available.
- Prototyping - a quick, early version of the system is created so users and developers can
explore requirements and provide feedback. The prototype helps determine what the final
system should look like.
- Spiral - development happens through repeated cycles, with risk analysis at each cycle. Each
loop adds to the system while identifying and addressing risks.
- RUP (Rational Unified Process) - an iterative and structured approach where development
is divided into iterations and different activities can happen across those iterations. It also
emphasises established development practices.
Model Main Idea Main Strength Main Weakness
Waterfall Linear sequence of stages Structured/documented Poor at handling change
V-model Development linked Strong testing focus Still relatively linear
explicitly to testing
Incremental Build the system piece by Early delivery & feedback Difficult to divide some
piece systems into increments
Prototyping Build an early version to Clarifies requirements Prototype can lead to
learn poor long-term design
Spiral Iterative development + Handles uncertainty/risk Cost and completion
risk analysis difficult to predict
RUP Iterative process with Structured but adaptable More complex
activities at two levels
, Week 1 - Software Engineering and Software Development Processes
Objectives
- Understand what the DBA course is about.
- Explain the inherent difficulties of software systems.
- Define software, systems, socio-technical systems, emergent properties.
- Explain software engineering, software processes, process flows.
- Compare and contrast prescriptive process flows (Waterfall, V-model, Incremental,
Prototyping, Spiral), RUP.
Lecture Notes
- Designing Business Applications (DBA) is about software engineering from a business
perspective. The focus is not simply on whether software can technically be built, but
whether the software creates value for the people who use it. An engineer may primarily ask,
“Can we build this?”, whereas the business perspective asks, “If we build this, will it actually
be useful and valuable to our users?” The lecturer therefore treats software development as
both a technical and a human problem.
- The course assignments simulate parts of a real software-development project.
Rather than mainly writing code, the course focuses on activities such as
understanding a business problem, defining requirements and designing the software
solution. The lecturer describes the assignments as a controlled simulation of
software engineering practice.
- A very simple program can technically be software. The lecturer uses an example of a
program that takes two values, X and Y, and returns X + Y. The calculation itself is trivial, but
the moment users interact with it, design decisions appear.
- For example, should the software ask the user to enter X first and then Y? Should it
instead provide one box where the user can simply type “42 + 12”? Both approaches
can produce the same mathematical answer, but users may strongly prefer one
interface over the other.
- This illustrates an important distinction:
- Programming asks how to make the computer perform an operation.
Software engineering also asks how that operation should be designed
so that people can use it effectively.
- Even extremely simple software therefore contains decisions about requirements,
interfaces and user expectations.
- Software projects remain difficult even after decades of technological development. The
lecturer explains that many projects are still delivered late or over budget. Larger projects
make the problem particularly visible because thousands of components and large numbers
of developers must work together.
- The problem is therefore not merely that writing code is difficult. Software
development involves coordination, changing requirements, human behaviour and
complex interactions between system components.
- The lecturer focuses on several characteristics that make software fundamentally difficult:
complexity, invisibility, changeability and conformity.
- Complexity - software complexity increases rapidly as more functions are added. A
single switch has two states: on and off. With two switches, there are already four
combinations. As more elements are added, the number of possible combinations
and interactions grows rapidly.
- This means that software complexity does not simply increase because there
are more individual functions. Complexity also comes from the relationships
between those functions.
, - Software engineers therefore often use a “divide and conquer” strategy. A
large system is broken into smaller components so that each component is
easier to understand. However, once those components are connected
again, additional complexity can emerge from their interactions.
- Software complexity often emerges from interactions between
components, not merely from the number of components.
- Invisibility - Software is also difficult because it is largely invisible.
- When engineers construct a physical object such as a building or car, the
structure can be seen. Software does not have the same physical
representation. This makes it harder for developers, managers and
customers to form the same mental picture of what the system should look
like and how it should behave.
- This becomes especially problematic because non-technical users are often
the people who ultimately determine whether the software is successful. They
need to understand what is being developed even though the underlying
system is difficult to visualise.
- Changeability - Software constantly changes. The lecturer emphasises that
successful software does not simply remain unchanged for ten years. User
expectations change, technology changes, laws change, bugs are discovered and
organisations develop new requirements.
- The Google example illustrates this. Features that once seemed useful may
later be removed because users do not use them. New functionality may then
be introduced as user behaviour and technology change.
- This means that change is not necessarily evidence that the original software
was poorly designed. Change is an inherent characteristic of software.
- This also explains why maintenance is such an important part of software
engineering. Software continually needs to be updated, corrected and
adapted rather than simply being built once and left unchanged.
- Conformity - Software development also requires many people to work according to
shared rules and standards.
- In manufacturing, workers can often perform highly standardised tasks. In
software development, different programmers may approach the same
problem differently. They may even have different interpretations of what
constitutes correct behaviour, acceptable quality or a bug.
- When thousands of developers work on one system, these differences
become a major coordination problem. The organisation therefore needs
processes and standards that help everyone work together consistently.
- Software is not judged only by what it does. It is also judged by how well it does it.
Performance, security, reliability, availability and usability can be just as important as the
actual functionality.
- For example, a search engine technically fulfils its purpose if it returns search results.
However, if those results take too long to appear, users may move to another search
engine. Similarly, security may be relatively less critical for one application but
absolutely essential for something such as military communications. These
characteristics are referred to as non-functional requirements.
- The important distinction is: Functional requirements describe what the system should
do. Non-functional requirements describe qualities, constraints or conditions
concerning how the system should perform.
- The importance of a particular non-functional requirement depends on the system
and its context.
Learning Objective 1 — Understand what the DBA course is about
- What is DBA? Designing Business Applications (DBA) is about software development
from a business perspective.
- The focus is not on writing code, but on understanding how to design and develop valuable
software systems. The course simulates a software engineering project, including
requirements analysis and other development activities.
- Why is it important? Software increasingly contains the logic and value created by IT, making
software development an important business capability.
- Key takeaway: DBA is about understanding how to develop software that actually creates
value.
Learning Objective 2 — Explain the inherent difficulties of software systems
- There is no single development approach that works for every software project.
Different projects have different requirements and therefore require different approaches.
- Brooks 4 difficulties:
Difficulty Meaning
Complexity Software has many interconnected parts and relationships.
Conformity Software must fit existing organisational rules, systems and regulations.
Changeability Software needs to change as users, organisations and environments change.
Invisibility Software cannot easily be visualised like a physical object.
- This is why there is “no silver bullet” — no single technique that solves the fundamental
difficulties of software development.
- Key takeaway: The difficulty is not simply building software; it is understanding what people
actually need and creating something valuable for them.
Learning Objective 3 — Define software, systems, socio-technical systems, emergent
properties
- Software is more than code. It includes programs and associated documentation.
- A system consists of interacting components that work together to achieve an objective.
- Socio-technical system - a system involving technology and people.
- For DBA, the focus is mainly on software and the people who interact with it, rather than the
underlying hardware.
- Emergent properties - properties that arise from the system as a whole, rather than from
individual components.
- Two types:
- Functional: the system's parts work together to achieve an objective.
- Non-functional: properties concerning the system's behaviour, such as reliability,
performance, safety and security.
- Example: a reliable web application does not become reliable simply because every individual
component is reliable. Reliability emerges from how all the components work together.
,Learning Objective 4 — Explain software engineering, software processes, process flows
- Software Engineering - a systematic, disciplined and quantifiable approach to the
development, operation and maintenance of software.
- General software process:
- 1. Understand the problem → Requirements, stakeholders, analysis
- 2. Plan the solution → Modelling and software design
- 3. Carry out the plan → Implementation
- 4. Examine the result → Testing and quality assurance
- Software lifecycle: software engineering does not stop when the software is built. It also
includes operation, maintenance and evolution. Sommerville identifies specification,
development, validation and evolution as fundamental software process activities.
- Key takeaway: Understand → Plan → Build → Test → Maintain/Evolve
Learning Objective 5 — Compare and contrast prescriptive process flows (Waterfall, V-model,
Incremental, Prototyping, Spiral), RUP
- Waterfall - a linear process where you complete each stage before moving to the next:
requirements → design → implementation → testing → maintenance. Best when
requirements are stable.
- V-Model - similar to Waterfall, but each development stage is explicitly linked to a
corresponding testing stage. Emphasises testing and validation throughout the process.
- Incremental - the system is built and delivered in smaller parts (increments). Each increment
adds more functionality until the complete system is available.
- Prototyping - a quick, early version of the system is created so users and developers can
explore requirements and provide feedback. The prototype helps determine what the final
system should look like.
- Spiral - development happens through repeated cycles, with risk analysis at each cycle. Each
loop adds to the system while identifying and addressing risks.
- RUP (Rational Unified Process) - an iterative and structured approach where development
is divided into iterations and different activities can happen across those iterations. It also
emphasises established development practices.
Model Main Idea Main Strength Main Weakness
Waterfall Linear sequence of stages Structured/documented Poor at handling change
V-model Development linked Strong testing focus Still relatively linear
explicitly to testing
Incremental Build the system piece by Early delivery & feedback Difficult to divide some
piece systems into increments
Prototyping Build an early version to Clarifies requirements Prototype can lead to
learn poor long-term design
Spiral Iterative development + Handles uncertainty/risk Cost and completion
risk analysis difficult to predict
RUP Iterative process with Structured but adaptable More complex
activities at two levels
, Week 1 - Software Engineering and Software Development Processes
Objectives
- Understand what the DBA course is about.
- Explain the inherent difficulties of software systems.
- Define software, systems, socio-technical systems, emergent properties.
- Explain software engineering, software processes, process flows.
- Compare and contrast prescriptive process flows (Waterfall, V-model, Incremental,
Prototyping, Spiral), RUP.
Lecture Notes
- Designing Business Applications (DBA) is about software engineering from a business
perspective. The focus is not simply on whether software can technically be built, but
whether the software creates value for the people who use it. An engineer may primarily ask,
“Can we build this?”, whereas the business perspective asks, “If we build this, will it actually
be useful and valuable to our users?” The lecturer therefore treats software development as
both a technical and a human problem.
- The course assignments simulate parts of a real software-development project.
Rather than mainly writing code, the course focuses on activities such as
understanding a business problem, defining requirements and designing the software
solution. The lecturer describes the assignments as a controlled simulation of
software engineering practice.
- A very simple program can technically be software. The lecturer uses an example of a
program that takes two values, X and Y, and returns X + Y. The calculation itself is trivial, but
the moment users interact with it, design decisions appear.
- For example, should the software ask the user to enter X first and then Y? Should it
instead provide one box where the user can simply type “42 + 12”? Both approaches
can produce the same mathematical answer, but users may strongly prefer one
interface over the other.
- This illustrates an important distinction:
- Programming asks how to make the computer perform an operation.
Software engineering also asks how that operation should be designed
so that people can use it effectively.
- Even extremely simple software therefore contains decisions about requirements,
interfaces and user expectations.
- Software projects remain difficult even after decades of technological development. The
lecturer explains that many projects are still delivered late or over budget. Larger projects
make the problem particularly visible because thousands of components and large numbers
of developers must work together.
- The problem is therefore not merely that writing code is difficult. Software
development involves coordination, changing requirements, human behaviour and
complex interactions between system components.
- The lecturer focuses on several characteristics that make software fundamentally difficult:
complexity, invisibility, changeability and conformity.
- Complexity - software complexity increases rapidly as more functions are added. A
single switch has two states: on and off. With two switches, there are already four
combinations. As more elements are added, the number of possible combinations
and interactions grows rapidly.
- This means that software complexity does not simply increase because there
are more individual functions. Complexity also comes from the relationships
between those functions.
, - Software engineers therefore often use a “divide and conquer” strategy. A
large system is broken into smaller components so that each component is
easier to understand. However, once those components are connected
again, additional complexity can emerge from their interactions.
- Software complexity often emerges from interactions between
components, not merely from the number of components.
- Invisibility - Software is also difficult because it is largely invisible.
- When engineers construct a physical object such as a building or car, the
structure can be seen. Software does not have the same physical
representation. This makes it harder for developers, managers and
customers to form the same mental picture of what the system should look
like and how it should behave.
- This becomes especially problematic because non-technical users are often
the people who ultimately determine whether the software is successful. They
need to understand what is being developed even though the underlying
system is difficult to visualise.
- Changeability - Software constantly changes. The lecturer emphasises that
successful software does not simply remain unchanged for ten years. User
expectations change, technology changes, laws change, bugs are discovered and
organisations develop new requirements.
- The Google example illustrates this. Features that once seemed useful may
later be removed because users do not use them. New functionality may then
be introduced as user behaviour and technology change.
- This means that change is not necessarily evidence that the original software
was poorly designed. Change is an inherent characteristic of software.
- This also explains why maintenance is such an important part of software
engineering. Software continually needs to be updated, corrected and
adapted rather than simply being built once and left unchanged.
- Conformity - Software development also requires many people to work according to
shared rules and standards.
- In manufacturing, workers can often perform highly standardised tasks. In
software development, different programmers may approach the same
problem differently. They may even have different interpretations of what
constitutes correct behaviour, acceptable quality or a bug.
- When thousands of developers work on one system, these differences
become a major coordination problem. The organisation therefore needs
processes and standards that help everyone work together consistently.
- Software is not judged only by what it does. It is also judged by how well it does it.
Performance, security, reliability, availability and usability can be just as important as the
actual functionality.
- For example, a search engine technically fulfils its purpose if it returns search results.
However, if those results take too long to appear, users may move to another search
engine. Similarly, security may be relatively less critical for one application but
absolutely essential for something such as military communications. These
characteristics are referred to as non-functional requirements.
- The important distinction is: Functional requirements describe what the system should
do. Non-functional requirements describe qualities, constraints or conditions
concerning how the system should perform.
- The importance of a particular non-functional requirement depends on the system
and its context.
