INF2001/ICT2201

Introduction to
Software Engineering
Dr. Alex Q. Chen
Alex.Q.Chen@SingaporeTech.edu.sg
@AlexQChen
 TODAY

▪ Motivation for Software

Engineering?
▪ What is Software
Engineering?

SIT INF2001 - AY23/24, Tri 1 2

Motivation for Software
Engineering

3
 In 1968…

▪ Reveal of Boeing 747

▪ Apollo 8 - 1st manned

spacecraft (soon followed
by Apollo 11)

SIT INF2001 - AY23/24,Introduction

SIT ICT2101/2201 Tri 1 to Software Engineering, AY21/22, Tri 1 4
 In 1968: Raising Demand for Software
▪ ↑ demand for software
▪ ↑ complexity for software
▪ ↓ productive for programmers

▪ Search for “Million Line of code” to see reported size of

applications.

SIT INF2001 - AY23/24, Tri 1 5

 IN 1968 THE MAJOR COMPLAINTS WERE:

u n n i ng over - er -
Projects r ts r u n n i ng o v
P roje c
time.
Projects were unmanageable and code budget.
Software was of
difficult to maintain.
Software was very
Softw low quality.
inefficient. a re was
ed
t e n e v e r
a re oft e n d i d not m e l ivered.
So ftw
e m en ts .
requir
SIT INF2001 - AY23/24, Tri 1 6
 Software Engineering: The Reality In Numbers

SIT INF2001 - AY23/24, Tri 1 7

 Software Engineering: The Reality In Numbers

SIT INF2001 - AY23/24, Tri 1 8

 We Are Getting Better…
16% STANDISH REPORT, 1995

51%

33%
29% 2015

52%

19%

SIT INF2001 - AY23/24, Tri 1 9

 CHAOS Resolution by Project Size
SUCCESSFUL CHALLENGED FAILED

Grand 2% 7% 17%
The resolution of all
Large 6% 17% 24% software project by size
from FY2011-FY2015
Medium 9% 26% 31%
with in the new CHAOS
Moderate 21% 32% 17% database

Small 62% 16% 11%

Total 100% 100% 100%

SIT INF2001 - AY23/24, Tri 1 10

 Cutter Consortium Data
▪ 2002 survey of information technology
organisations
• 78% have been involved in disputes ending in litigation

▪ For the organisations that entered into litigation:

• In 67% of the disputes, the functionality of the information
system as delivered did not meet up to the claims of the
developers.
• In 56% of the disputes, the promised delivery date slipped
several times.
• In 45% of the disputes, the defects were so severe that the
information system was unusable.

SIT INF2001 - AY23/24, Tri 1 11

 The software crisis from 1968 is still relevant and
has not been solved yet…

SIT INF2001 - AY23/24, Tri 1 12

What is Software
Engineering?

13
 Defining “SOFTWARE ENGINEERING”

SIT INF2001 - AY23/24, Tri 1 14

 Defining “SOFTWARE ENGINEERING”

SIT INF2001 - AY23/24, Tri 1 15

 Defining “SOFTWARE ENGINEERING”

“The application of a systematic, disciplined,

quantifiable approach to the development,
operation and maintenance of software.”

SIT INF2001 - AY23/24, Tri 1 16

 Defining “SOFTWARE ENGINEERING”

“The application of a systematic, disciplined,

quantifiable approach to the development,
operation and maintenance of software.”

SIT INF2001 - AY23/24, Tri 1 17

 Defining “SOFTWARE ENGINEERING”

“The application of a systematic, disciplined,

quantifiable approach to the development,
operation and maintenance of software.”

SIT INF2001 - AY23/24, Tri 1 18

 Defining “SOFTWARE ENGINEERING”

“The application of a systematic, disciplined,

quantifiable approach to the development,
operation and maintenance of software.”

SIT INF2001 - AY23/24, Tri 1 19

 Defining “SOFTWARE ENGINEERING”

“The application of a systematic, disciplined,

quantifiable approach to the development,
operation and maintenance of software.”

It’s not just coding!

SIT INF2001 - AY23/24, Tri 1 20
 Defining “SOFTWARE ENGINEERING”

“Software engineering is a discipline whose aim

is the production of fault-free software,
delivered on time and within budget, that
satisfies the user’s needs”

SIT INF2001 - AY23/24, Tri 1 21

 Defining “SOFTWARE ENGINEERING”
▪ Programming in the large
• many people, more complex systems
▪ Disciplined development
▪ Repeatable practices
▪ Full life-cycle of activities

▪ A dual emphasis:
• Product: what is produced
• Process: how the product is produced
SIT INF2001 - AY23/24, Tri 1 22
 Fault-free Software
▪ What are Faults?
• software behaviour unaccounted for in its design
▪ Examples
• Patriot missile timing error
• Therac-25 medical linear accelerator incident “FAULT-FREE”??
• The pervasive Y2K bug
❖ Global economic impact

▪ How can we lessen our chances of faults?

• use a well-defined process that includes rigorous design, testing,
and programming techniques
• ICT2106, ICT3101…
image from: http://www.financialtraining.ca/wp-content/uploads/2012/01/Blame.jpg January 2015
SIT INF2001 - AY23/24, Tri 1 23
 Why Is It So Hard To Develop Software That Is…

▪ On time,
▪ Within budget
▪ Satisfies the user’s needs (functionalities and usability)

SIT INF2001 - AY23/24, Tri 1 24

 Time And Budget Case Studies
California DMV software (1987-1993)
• attempt to merge driver & vehicle registration systems
• Plan: $28 million over 5 years.
• spent 7 years and $50 million …
before pulling the plug
❖Estimated cost of over $200 million and at least 5 years delay

Round 2:
California DMV software (2006-2013)
➢ Project stopped after spending $134 million due to
“significant concerns with the lack of progress”
➢ 3 months before the original expected delivery date
➢ Some of the functions were delivered Data from: IEEE SPECTRUM, 2013 Los
Angeles Times, 2013
SIT INF2001 - AY23/24, Tri 1 25
 Time And Budget Case Studies
Digital Media Initiative (DMI) by BBC, UK
• To modernise the Corporation's production and archiving
methods by using connected digital production and media asset
management systems.
• Plan: ~£81.7 million
• Actual cost: >£98 million (>SGD200 million)
• 2008 - 2013
• Project scrapped due to bad management and outpaced by
changing technology.
• By 2013, much cheaper Commercial Off The Shelf (COTS)
alternatives by then existed.

Data from: BBC abandons £100m digital project

SIT INF2001 - AY23/24, Tri 1 26

 Economic Aspects: Example
▪ Coding Method CMnew is 10% faster than currently used Coding Method CMold.

Should it be used?

▪ Common sense answer:

Of course!

▪ Software Engineering answer:

• Consider the cost of training
• Consider the impact of introducing a new technology
• Consider the effect of CMnew on maintenance

SIT INF2001 - AY23/24, Tri 1 27

 Satisfies The User’s Needs
▪ Functionality and Usability
• does what the user’s tasks require (ICT2108, ICT3101)
• efficient to use & error rates kept to a minimum (ICT2102, ICT3102)
• easy to learn
• leads to high user satisfaction
▪ Bad (even if correct) user interfaces cost
• money (5%! satisfaction ⇒ up to 85%! profits)
• lives (Therac-25)
▪ User interfaces hard to get right
• people are unpredictable
• ICT2102 is all about how to get UIs right
SIT INF2001 - AY23/24, Tri 1 28
 Software Life Cycle
actual

▪ A life cycle: the steps performed when building a product

▪ A life cycle model:

• The steps to follow when building software
• A theoretical description of what should be done

▪ Having a defined process (model) is essential

▪ Maturity of the process is some gauge of success of organization

SIT INF2001 - AY23/24, Tri 1 29

What are the
Activities Involved in
Building Software?
30
 Software Development Activities Requirement
specification

▪ Understand User requirements(what the client needs) Analysis and

▪ Analysis and design software architecture(high level and Design

detailed)
Implementation
▪ Implement and document the design
▪ Testing(verify and validate) Testing

▪ Deploy the product

▪ Fix bugs after deployment Deployment

▪ Add features after deployment

Maintenance
▪ Planning and Team Management
SIT INF2001 - AY23/24, Tri 1 31
Among the Activities…
Which Activity is
Known to be the Most
Problematic?
32
SIT INF2001 - AY23/24, Tri 1 33
Which Phase Costs
the Most?
34
 Phase Cost Approximation
▪ 1976–1981 data
8%
7%
Maintenance constitutes 67% of total cost 5%

▪ Good software is maintained 6%

(for 10, 20 years or more) 5%

2% 67%

▪ Bad software is discarded

▪ We should design our software with
maintenance in mind Maintenance
Requirements
Speci ca on (Analysis)
Design
We need techniques, tools and practices Module Coding
to reduce maintenance costs! Module Tes ng
Integra on

SIT INF2001 - AY23/24, Tri 1 35

fi
ti
ti
ti
 What is the best way to arrange the phases in a workflow?
Requirement Analysis and
Implementation
specification Design

Testing Deployment Maintenance

▪ Which phase should come first?

▪ Should we work in parallel or sequential?
▪ Can we go through a phase more than once?
▪ Would your choice be affected by the type, size, and context of the
project and hosting organization?

SIT INF2001 - AY23/24, Tri 1 36

 Typical Classical Phases
▪ Requirements phase (ICT2108)
• Explore the concept
• Elicit the client’s requirements

▪ Analysis (specification) phase (ICT2108)

• Analyze the client’s requirements
• Draw up the specification document
• Draw up the software project management plan
• “What the product is supposed to do”

SIT INF2001 - AY23/24, Tri 1 37

 Typical Classical Phases
▪ Design phase (ICT2106 and others)
• Architectural design, followed by
• Detailed design
• “How the product does it”

▪ Implementation phase (ICT1002, ICT1009, ICT2105 and many others)

• Coding
• Unit testing
• Integration
• Acceptance testing

SIT INF2001 - AY23/24, Tri 1 38

 Typical Classical Phases
▪ Postdelivery maintenance (ICT3104 and others)
• Corrective maintenance
• Perfective maintenance
• Adaptive maintenance

▪ Retirement

SIT INF2001 - AY23/24, Tri 1 39

 Waterfall Life-cycle Model
Classical model (1970)

SIT INF2001 - AY23/24, Tri 1 40

 The Waterfall Process - 1970
Requirement
specification

Analysis and
Design

Implementation
▪ W. Royce “Managing the Development of
Large Software Systems” Verification
▪ Sequential & Distinct phases: one phase is Validation

completed and the next one begins

Deployment
▪ Document-driven (Plan and document
approach)
Maintenance
▪ Big Design Up Front (BDUF)
SIT INF2001 - AY23/24, Tri 1 41
 The Waterfall Process – Feedback loops
Requirement
specification

Analysis and
Design

Implementation

Verification
▪ The rationale is that the earlier you catch a bug Validation

the cheaper to fix it

Deployment
▪ However, it is not realistic
▪ Thus, you keep going back, then you must Maintenance
move forward again in sequence
SIT INF2001 - AY23/24, Tri 1 42
Maintenance
Classical perceptions:

development

maintenance

SIT INF2001 - AY23/24, Tri 1 43

 MAINTENANCE
Modern perception:
The process that occurs when a
software artefact is modified
because of a problem or because
of a need for improvement or
adaptation
(adopted by IEEE)

44 SIT ICT2101/2201 Introduction to Software Engineering, AY21/22, Tri 1

SIT INF2001 - AY23/24, Tri 1
 MAINTENANCE
Modern perception:

development

Maintenance

45 SIT ICT2101/2201 Introduction to Software Engineering, AY21/22, Tri 1

SIT INF2001 - AY23/24, Tri 1
 Importance Of Post-delivery Maintenance
▪ Good software is maintained (for 10, 20 years and more),
▪ Bad software is discarded

▪ Software is a model of reality, which is constantly changing

▪ Different types of maintenance
• Corrective maintenance [about 20%]
• Enhancement
❖ Perfective maintenance [about 60%]
❖ Adaptive maintenance [about 20%]

46
SIT INF2001 - AY23/24, Tri 1
 TIME (= COST) Of Post-delivery Maintenance

Between 1976 and 1981 Between 1992 and 1998

47
SIT INF2001 - AY23/24, Tri 1
 Consequence Of Relative Costs Of Phases
▪ Return to CMold and CMnew

▪ Reducing the coding cost by 10% yields at

most a 2% reduction in total costs
• Consider the expenses and disruption incurred

▪ Reducing postdelivery maintenance cost

by 10% yields a 6-7% reduction in overall
costs
SIT INF2001 - AY23/24, Tri 1 48
 Requirements, Analysis, And Design Aspects

The cost of detecting and correcting a fault at each phase

SIT INF2001 - AY23/24, Tri 1 49
 Requirements, Analysis, And Design Aspects
▪ To correct a fault early in the life cycle
• Usually just a document needs to be changed

▪ To correct a fault late in the life cycle

• Change the code and the documentation
• Test the change itself
• Perform regression testing
• Reinstall the product on the client’s computer(s)

SIT INF2001 - AY23/24, Tri 1 50

 It is vital to improve our requirements, analysis, and
design techniques

• To find faults as early as possible

• To reduce the overall number of faults (and, hence, the overall
cost)
• To reduce the cost of maintenance

SIT INF2001 - AY23/24, Tri 1 51

Did the Waterfall Model Work?

52
US Department of
Defense (DOD)
experienced an
alarming amount of
software failure
using Waterfall

They hired an expert, Jarzombek

(1999), to investigate the cause of
failure

SIT INF2001 - AY23/24,Introduction

SIT ICT2101/2201 Tri 1 to Software Engineering, AY21/22, Tri 1 53
 Among the
systems that
worked, not all
features were
used

SIT INF2001 - AY23/24, Tri 1 54

Which phase caused
significant failures when
using the Waterfall
model?
55
 Misinterpretation
of requirements
from users

SIT ICT2101/2201
SIT INF2001 - AY23/24, Tri Introduction
1 to Software Engineering, AY21/22, Tri 1 56
 Attributes of the Waterfall Process
The Good The Bad
▪ Waterfall model is easy to understand ▪ Success depends on precise requirements
due to its simple linear structure and ▪ No working model of the software until
clearly defined stages the end of the life cycle
▪ Provides structure to less experienced ▪ High amounts of risk / uncertainty.
staff
▪ When in a later stage, it is very difficult to
▪ Facilitates project management make any changes to the product
▪ It helps to define the goals and ▪ Not realistic: Does not reflect real
deliverables at the early stage of the processes
project
▪ Expensive

SIT INF2001 - AY23/24, Tri 1 57

 When to Use Waterfall Model?
When to Use When Not to Use
▪ Requirements are very well known ▪ Not a great choice for complex and
and understood long-term project
▪ Technology is understood ▪ Doesn’t work for maintenance type
project
▪ If you are building a new version of
an existing product (with some ▪ When client is strict with timeline
exceptions) and budget
▪ Low-risk in-house projects ▪ New idea that have not done before
▪ Small and simple Projects ▪ Technology is new or team doesn’t
know it.
▪ Government projects that heavily
regulated.
SIT INF2001 - AY23/24, Tri 1 58
Rapid Prototyping Model
A variation of the Waterfall model

59
 Rapid Prototyping Model
▪ Linear model
▪ Instead of ‘Requirements’:
• Listen to customer
• Build prototype
• Customer “test drives” prototype
• Should be quick (can’t be long)

▪ Challenges:
• “Throw-away” phenomenon
• Demos can set unrealistic expectations
• Compromises that solidify

SIT INF2001 - AY23/24, Tri 1 60

 KEY POINTS: Rapid Prototyping
▪ Do not turn the prototype into product

SIT INF2001 - AY23/24, Tri 1

 (at the end)
▪ The customers don’t know what they want till they see
something working.
▪ Same issues as Waterfall
(one shot delivery and expensive)

62
The Spiral Model

63
The Spiral Model

▪ 15 years later…
▪ 4 Specific phases
▪ Uses in iterations
▪ Combines planning and documentation with
prototyping in iterations
▪ There is an emphasis on risk analysis
▪ The radius of the iteration reflects the
accumulated cost involved
▪ Customer is involved throughout

SIT
SIT ICT2101/2201 Introduction
INF2001 - AY23/24, Tri 1 to Software Engineering, AY21/22, Tri 1 64
 Attributes of the Spiral Model
The Good The Bad
▪ Customers see the product as it ▪ Iterations are very long - they could be 0.5-2
evolves. years

▪ A lot of documentation for every iteration

▪ Risk management is part of the life-
cycle (in every iteration) ▪ You can’t start a phase till the other ends
▪ Need staff who are experts in risk
▪ Project monitoring and scheduling are
easy because of the clear phases ▪ identification and resolution
▪ Cost of the process is high (eg. time in
▪ Features can be added
prototyping)

▪ Requires Stakeholder engagement

SIT INF2001 - AY23/24, Tri 1 65
 When to Use the Spiral Model?
When to Use When Not to Use
▪ High Risk and large systems ▪ Client is not available
▪ Can be used for totally new ▪ Progress is urgent
ideas ▪ When client is strict with
timeline and budget
▪ Low risk and low budget projects
(unnecessary expenses)

SIT INF2001 - AY23/24, Tri 1 66

The Rational Unified Process

67
 The Rational Unified
Process - 2003
▪ Another 15 years later ...
▪ Closely tied to UML (Unified model language) and
component-based modelling
▪ The Unified Process is not a series of steps for
constructing a software product
• No such single “one size fits all” methodology could
exist
• There is a wide variety of different types of software
▪ The Unified Process is an adaptable methodology
• It must be modified for the specific software
product to be developed

SIT ICT2101/2201
SIT INF2001 Introduction
- AY23/24, Tri 1 to Software Engineering, AY21/22, Tri 1 68
 The Rational Unified Process (Framework)
A Phase represents the Business context of a step
Workflow: Technical context

Time

https://www.scnsoft.com/blog/software-development-models

SIT INF2001 - AY23/24, Tri 1 69

 Phases of Business Context
Inception Elaboration Construction Transition
▪ Begin to make the ▪ To refine the ▪ Emphasis is on ▪ Move to
initial business initial Implementation customers’ real
requirements and and Testing environment
case define priorities
• Integration (deployment)
▪ Set tentative of use cases
testing of ▪ Ensure that the
schedule and ▪ Refine the subsystems requirements are
budget software
architecture • Product testing met
▪ Risk assessment of the overall ▪ Correct Faults
▪ Refine the system
business case ▪ Complete manuals
▪ Understand the
▪ Refine the project ▪ Operational
domain
management releases ▪ Driven by
feedback from
▪ Usually short plan ▪ Usually longer client
than the rest
SIT INF2001 - AY23/24, Tri 1 70
 Example of the Rational United Process - 2003

Technically you can have as many You can deliver a component here or
iterations as you want. deliver all of them at the end in parallel
The above case is typically used.

https://www.scnsoft.com/blog/software-development-models

SIT INF2001 - AY23/24, Tri 1 71

 Key Points for the Rational Unified Process
▪ Use case and architecture centric
▪ Deals with software in components with defined interfaces
▪ The Unified Process framework is an adaptable methodology
It has to be modified for the specific software product to be developed

SIT INF2001 - AY23/24,Introduction

SIT ICT2101/2201 Tri 1 to Software Engineering, AY21/22, Tri 1 72
 Attributes of the Rational Unified Process
The Good The Bad
▪ Business Process tied to the development ▪ Complicated
process
▪ Expensive tools are needed
▪ Tool support for gradual improvement of a
project ▪ Only good for medium and large- scale
projects
▪ Risk Mitigation
▪ Extensive Documentation and planning (a lot
▪ Focus on quality of design of overhead)
▪ A framework that allows the use of other
models
▪ Doesn’t need all requirements to be known at
the beginning
▪ Deliver value early (if needed)
SIT INF2001 - AY23/24, Tri 1 73
 When to Use the Rational Unified Process?
When to Use When Not to Use
▪ Medium to large projects ▪ Small simple projects
▪ Budget and schedule can be ▪ Limited budget projects
strict
▪ You need to show value early
(you can show something
working in the first iteration of
construction phase)
▪ Engineers experienced with
object-oriented design
SIT INF2001 - AY23/24, Tri 1 74
 Document & Plan Driven Approaches
▪ Plan-and-document methods were created to make software as
dependable as civil engineering
• Extensive documentation and planning
• Experienced project managers
Write Contracts
Hire talents
Evaluate development Team

▪ Were we able to deliver high quality products on time and

within budget?

SIT INF2001 - AY23/24, Tri 1 75

In 1987, Fred Brooks, a very well-known
expert on how to produce software
systems led a task force to find out what
is going wrong with all these software
failures from traditional techniques.

"The document-driven, specify-then-build

approach lies at the heart of so many software
problems.”

76
Birth of Agile Approaches

77
 Agile Manifesto
▪ Signed in 2001 by “independent-minded practitioners”

“We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individual & Interactions Over Processed & Tools

Over Comprehensive
Working Software
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.”

SIT INF2001 - AY23/24, Tri 1 78

 Agile is a Mindset
SIT ICT2101/2201 Introduction to Software Engineering, AY21/22, Tri
1 79
SIT INF2001 - AY23/24, Tri 1
 Principles of Agile Method
▪ Embraces change as a fact of life
• Continuous improvement over fixed phase
▪ Incremental delivery (1-4 weeks)
▪ Increments have value
▪ Emphasize Test driven development
▪ Small teams
▪ Customer involvement (not during iterations)
▪ The automation of tasks where possible
▪ Light-weight documentation
▪ Velocity is the way to measure progress (how to predict progress with past
progress)
▪ Self management
SIT INF2001 - AY23/24, Tri 1 80
Source: Emmanuel Peña Alvarez

81
 Scrum

Types of Agile
Kanban
Methods

https://getnave.com/blog/kanban-workflow/
SIT ICT2101/2201 Introduction to Software Engineering, AY21/22, Tri
SIT INF2001 - AY23/24, Tri 1 1 82
 Attributes of the Agile Method
The Good The Bad
▪ Flexible to change and continuous ▪ May require some rework (since we
feedback which increases the change didn’t know EVERYTHING upfront)
of building the right product
▪ Requires close collaboration with the
▪ Customer Satisfaction client
▪ Early value delivery and early to ▪ Good tools for automation are a must
market have (poor ones might delay you)
▪ Team Ownership (self organizing ▪ Not every individual/team can adopt
team) Agile values, setup needs trust and
communication
SIT INF2001 - AY23/24, Tri 1 83
 Practising Agile
▪ Gives the client confidence to know that a new version with additional
functionality will arrive every 3 weeks

▪ The developers know that they will have 3 weeks (but no more) to
deliver a new iteration
• Without client interference of any kind

▪ If it is impossible to complete the entire task in the timebox, the work

may be reduced (“descoped”)
• Agile processes demand fixed time, not fixed features
SIT INF2001 - AY23/24, Tri 1 84
 CHAOS
Resolution by
Agile Versus
Waterfall

The resolution by Agile

versus Waterfall from
FY2011-FY2015 with in
the new CHAOS database

SIT
SIT ICT2101/2201
INF2001 Introduction
- AY23/24, Tri 1 to Software Engineering, AY21/22, Tri 1 85
 When to Use the Agile Method?
When to Use When Not to Use
▪ Lightweight methods suit small- ▪ Do not have a good team
to medium-size projects (or (attitude and skills)
large projects divided into ▪ For large projects where
components) customer needs specific
▪ Used for time-critical documentation and formal
applications and prototypes communication
▪ Requirements are sure to ▪ Large Systems that can’t be
change, new or uncertain broken into modules for smaller
▪ Technology is new teams
SIT INF2001 - AY23/24, Tri 1 86
Introduction to Scrum

▪ https://vimeo.com/334800839/3a7b2fa063
▪ Watch the video (4 mins) by Prof. Tan Chek
Tien

SIT
SIT ICT2101/2201 Introduction
INF2001 - AY23/24, Tri 1 to Software Engineering, AY21/22, Tri 1 87
 What We Have Learned Today
▪ Motivation
• Developing software is not simple, and often not done well.
• Developing software is not the same as coding. There is much more
to it.
▪ We need to have good systems and processes in place.
▪ We want to keep maintenance in mind when developing.
▪ We want to detect faults as early as possible.
▪ Software Development Life Cycle (SDLC)
▪ Software models – their Pros, Cons, and when to use them
SIT INF2001 - AY23/24, Tri 1 88