Scribd
Upload
27 views16 pages

SE 2324 01 Introduction

The document provides an introduction to software engineering and a comparison of traditional vs agile development approaches. It discusses that traditional approaches emphasize extensive upfront planning and documentation but are inflexible to change, while agile approaches focus on iterative development and prioritize working software over documentation to allow for flexibility. The document also notes that software development is challenging due to factors like complexity, size, changeability over long lifetimes, and the need to solve real-world problems. An effective development process is needed to address these challenges of complexity and constant change.

Uploaded by

Muhammad Ghassan Jawwad
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
27 views16 pages

SE 2324 01 Introduction

The document provides an introduction to software engineering and a comparison of traditional vs agile development approaches. It discusses that traditional approaches emphasize extensive upfront planning and documentation but are inflexible to change, while agile approaches focus on iterative development and prioritize working software over documentation to allow for flexibility. The document also notes that software development is challenging due to factors like complexity, size, changeability over long lifetimes, and the need to solve real-world problems. An effective development process is needed to address these challenges of complexity and constant change.

Uploaded by

Muhammad Ghassan Jawwad
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 16

Software

Engineering

Introduction
The road to Agile

Will be clear from the Preliminaries: our course will focus


on Agile development

We’ll take a deeper look at Agile in a later lecture, but


we’ll give a short introduction here.

We’ll also see why software is difficult compared with


other engineered products.

COMP3297: Software Engineering 2


Traditional vs Agile Brief introduction
We’ll revisit
Traditional later

Early software development projects produced some spectacular


failures. And development was typically unpredictable in terms of
time and cost. Products were unreliable.

Attempts to impose a more disciplined approach were modelled on


what worked for well other engineering disciplines like civil
engineering to produce reliable, high-quality results, on a
predictable schedule and budget.

This was named Software Engineering.

Goal: To discover methods to build software that were as


predictable in outcome as those used, for example, to build
bridges and other civil engineering infrastructure.
COMP3297: Software Engineering 3
Traditional vs Agile Brief introduction

The methods emphasised:

- careful, detailed planning at the beginning of a project

- extensive documentation including complete specifications of


requirements, analysis and design models, and formal quality
assurance documentation. Cannot move forward until
everyone is in agreement.

- usually, a commitment to a contract

This brought the desired discipline. Plan carefully and then


measure progress against the plan.

Heavyweight Plan-driven development, or Plan-and-Document


methodology.
COMP3297: Software Engineering 4
Traditional

Planning and thorough specification is required, in some form, for critical


systems and massive, complex multi-year projects involving many sub-
systems such as developing control systems for a new aircraft.

Done well, the approach can work. But the overheads are huge. Too big
for smaller products where the documentation may never even be read.

Also, knowledge is never perfect at the start of a project. So initial


specifications will be wrong, and rework will be needed.

Problem: Plan and Document approaches aren’t flexible enough to


respond to change and work needs to be redone after it is first “finished”.
Means software can’t be delivered quickly in most cases.

COMP3297: Software Engineering 5


Agile

The idea is to take a more lightweight approach, dropping rigid plans


and documentation and focusing on the software itself.

Agile processes deliver working software to customers quickly, get


feedback for changes and build those into future versions, adding
further functionality and repeating the cycle.

Incremental development. Think of it as cycles of refining a prototype


on the basis of this continuous feedback.

Agile aims to deliver what is valuable and to avoid working on


anything that is not of value.
2018

Applies to product features, too:

COMP3297: Software Engineering 6


The Agile Manifesto
“Manifesto for Agile Software Development”

“We are uncovering better ways of developing software by doing it


and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools


Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the
items on the left more.”

There is a plan: we have a vision of where we want to get to, and a


strategy for getting there.

But nothing like the sort of plans in the traditional approach.


COMP3297: Software Engineering 7
Last Chaos Report from the Standish Group (2020)

Traditional vs. Agile vs. Project Size. Agile no longer controversial

SIZE PROCESS SUCCESSFUL CHALLENGED FAILED

All Agile 42% 47% 11%


Projects Traditional 13% 59% 28%

Large Agile 19% 56% 25%


Projects Traditional 8% 56% 36%

Medium Agile 34% 53% 13%


Projects Traditional 9% 66% 25%

Small Agile 59% 36% 5%


Projects Traditional 45% 46% 9%
Completed on time and Cancelled at some point
within budget, with a during development or
satisfactory result. never used
COMP3297: Software Engineering 8
Why is it hard?
What makes software development different?

Other branches of engineering seem to


achieve better results with traditional
approaches.

Why is it so difficult to achieve similar


success in software development?

These are issues we need to address to become more successful

COMP3297: Software Engineering 9


What makes software development different?
Software is relatively easy to create and modify - it's not hard to write
code - but it is not easy to create or modify software well.

Consequences: Poor quality products

Poorly trained developers can easily create poorly designed products


that work but that are very fragile and difficult to maintain even by good
developers.

Similarly, it is easy to destroy a good design by modifying it poorly when


adding new code.

Consequences: Software decline

Software doesn't "wear out". It gets continually modified over its long
lifetime and tends to get worse - more complex - until further changes
can’t Software
COMP3297: be done safely.
Engineering 10
What makes software development different?
Software systems can be large and highly complex.

For a developer or maintenance engineer working on some component,


it can be difficult to fully understand its effect on the rest of the system.

Retrieved today (16/1/24):

How big: how many lines of code?

COMP3297: Software Engineering 11


What makes software development different?
A few more factors we touched on in the previous slide set:

Development is still a highly skilled task at all levels.


Unlike other branches of engineering, not much is automated.
But we can reuse.

Software engineering usually requires experts in one domain (software


development) to create systems for members of another domain.
We usually don't have expert knowledge of the application area – we
aren't the future users of the system.

Typically, there are many possible solutions to a particular problem, and


no single, standard, best solution.
We constantly must evaluate trade-offs, costs versus benefits.

COMP3297: Software Engineering 12


What do we need in a process?

To develop well, we first need a software


process that helps us tackle two main issues à

COMP3297: Software Engineering 13


1 Complexity
Large systems are complex – many components must interact to
provide the functionality required by users

The problem the system is required to solve (the required


functionality) is usually complex too. The real-world is messy.

Because large systems are developed in teams, the required


communication and coordination is also complex.

Our approach to development must handle complexity well:

in the system being developed

in the development process itself

COMP3297: Software Engineering 14


2 Change
Large systems take a long time to develop

their environment and the needs of stakeholders are likely to change


during development

if ignored, it can happen that technical development is executed


"perfectly" but the product is a failure

Large systems have a long lifetime

can expect a lot of modification during that lifetime in order to adapt


to new requirements or new technology – the real-world changes

Our approach to development must support constant change:

during initial development, and

after delivery
COMP3297: Software Engineering 15
What form of
Process Model
can help?

COMP3297: Software Engineering 16

You might also like