Software Engineering

Fundamentals and Motivation

Chapter 1- Software Engineering: Theory and Practice

Yoones A. Sekhavat, Ph.D.

Spring 2025
 Boeing 737 MAX carriers crashed
In 2019, two Boeing 737 MAX
carriers crashed, taking the lives of
347 passengers in total. Boeing
lost $18.4 billion from grounded
flights, lawsuits from bereaved
families, and cancelled orders.

Had the software engineers

understood the realities of aircraft
operation and the need for pilot
control, perhaps these issues could
have been addressed in production.
 Motivation
Hamilton lost
the first place
in the 2021
Formula 1
season during
the final race in
Abu Dhabi due
to a
controversial
decision
regarding the
safety car and
subsequent
laps.
 Therac-25 : Software Errors in Medical Devices

A patient received an overdose of

approximately 100 times the intended
dose of radiation due to a software
error.

The patient experienced severe burns

and other injuries, eventually leading
to death.

Investigation revealed that the machine’s

software allowed operators to inadvertently
bypass critical safety checks, resulting in
the fatal overdose.
Motivation

Complex Vs.

Complicated

?
Motivation

Complex Vs.

Complicated
Complex = composed of many simple parts related to one
another

Complicated = not well understood, or explained

Complexity Example:
Scheduling Fence Construction Tasks

Nailing Painting
Setting posts Cutting wood
[ 2 time units for unpainted; [ 5 time units for uncut wood;
[ 3 time units ] [ 2 time units ]
3 time units otherwise ] 4 time units otherwise ]

…shortest possible completion time = ?

[  “simple” problem, but hard to solve without a pen and paper ]
 The Frog in Boiling Water

• Frog in gradually heated water analogy:

• The problem with little things is that none of
them is big enough to scare you into action, but
they keep creeping up and by the time you get
alarmed the problem is too difficult to handle
8

• Consequently, “design smells” accumulate,

“technical debt” grows, and the result is
“software rot”
The Role of Software Engg. (1)
A bridge from customer needs to programming implementation

Customer
Programmer

First law of software engineering

Software engineer is willing to learn the problem domain
(problem cannot be solved without understanding it first)
The Role of Software Engg. (2)
Customer:
Requires a computer system to achieve some business goals
by user interaction or interaction w ith the problem domain
in a specified manner

System-to-be
(includes hardware)

Problem Domain
Software-to-be
User

Software Engineer’s task:

To understand how the system-to-be needs to interact w ith
the user or the problem domain so that customer’s requirement is met
and design the software-to-be

May be the Programmer’s task:

same person To implement the software-to-be
designed by the software engineer
Cartoon Strip : How ATM Machine Works
A Enter B C Verify
account
D
your PIN
XYZ
Verify
this
account

Typing in XYZ valid. Account

PIN number Balance: valid.
… $100 Balance:
$100

E How may F Release

G Record
I help $60 $60 less
you?

Withdraw Dispense
H Dispensing!

$60 $60
Please take
your cash
Software Engineering
Blueprints
 Specifying software problems and solutions is like
cartoon strip writing
 Unfortunately, most of us are not artists, so we will
use something less exciting:
UML symbols
 However …
UML – Unified Modeling Language
«interface»
Stereotype
BaseInterface
«» provides
ClassName additional info/
+ operation()
annotation/
# attribute_1 : int explanation
Three common # attribute_2 : boolean
compartments: # attribute_3 : String
1. Classifier name Inheritance
+ operation_1() : void relationship:
+ operation_2() : String Class1Implement Class2Implement
2. Attributes BaseInterface
+ operation_3(arg1 : int) is implemented
+ operation() + operation()
3. Operations by two classes
Software Class
Actor Comment Software Interface Implementation

instance1 : Class1 instance5 : Class2 instance8 : Class3

doSomething()
doSomethingElse()

Interaction Diagram
doSomethingYetElse()
Online information:
http://www.uml.org
 Work Estimation Strategy

1. Make initial guess for a little part of the work

2. Do a little work to find out how fast you can go

3. Make correction on your initial estimate

4. Repeat until no corrections are needed or work is
completed
Formal hedge pruning
Sizing the Problem (1)
Step 1: Divide the problem into small & similar parts

Step 2:
  Estimate relative sizes of all parts

Size(  ) = 4

Size(  ) = 7
 Size(  ) = 10
Size(  ) = 3
Size(  ) = 4

 Size(  ) = 2

 Size(  ) = 4
Size(  ) = 7
Sizing the Problem (2)

• Step 3: Estimate the size of the total work

Total size =   points-for-section i (i = 1..N)

• Step 4: Estimate speed of work (velocity)

• Step 5: Estimate the work duration

Path size

Travel duration = Travel velocity

Sizing the Problem (3)

How about Software?

Can we Estimate the size of work for a software?
Sizing the Problem (3)

Unfortunately:
• Unlike hedges, software is mostly invisible and
does not exist when project is started

 The initial estimate hugely depends on experience and

imagination
1.1 What is Software Engineering
Solving Problems

• Software products are large and complex

• Development requires analysis and synthesis
• Analysis: decompose a large problem into smaller, understandable
pieces
• abstraction is the key
• Synthesis: build (compose) a software from smaller building blocks
• composition is challenging
1.1 What is Software Engineering
Solving Problems (continued)

• The analysis process

1.1 What is Software Engineering
Solving Problems (continued)
• The synthesis process
1.1 What is Software Engineering?
Solving Problems (continued)

• Method: a formal “recipe” for accomplishing a goal that is typically

independent of the tools used
• Tool: an instrument or automated system for accomplishing
something in a better way
• Procedure: a combination of tools and techniques to produce a
product
• Paradigm: philosophy or approach for building a product (e.g., OO
vs structured approaches)
1.1 What is Software
Engineering
Where Does the Software Engineer Fit In?
• Computer science: focusing on computer hardware,
compilers, operating systems, and programming languages

• Software engineering: a discipline that uses computer and

software technologies as a problem-solving tools
1.1 What is Software
Engineering
•Where Doesbetween
Relationship the SW Engineer
computer Fit in?
science and (continued)
software
engineering
 1.2 How Successful Have We Been?
Sidebar 1.1 Terminology for Describing Bugs

• A fault: occurs when a human makes a mistake, called an error,

in performing some software activities
• A failure: is a departure from the system’s required behaviour
 1.3 What Is Good
Software?
Sidebar 1.2 Perspective on Quality
quality is something we can recognize but not define

• The user view: quality is fitness for purpose

• The manufacturing view: quality is conformance to specification
• The product view: quality tied to inherent product characteristics
• The value-based view: depends on the amount the customers is
willing to pay for it
1.3 What is Good Software?

• Good software engineering must always include a strategy for

producing quality software
• Three ways of considering quality
• The quality of the product
• The quality of the process
• The quality of the product in the context of the business
environment
1.3 What Is Good Software?
The Quality of the Product

• Users judge external characteristics (e.g., correct functionality,

number of failures, type of failures)
• Designers and maintainers judge internal characteristics (e.g.,
types of faults)
• Thus different stakeholders may have different criteria
• Need quality models to relate the user’s external view to
developer’s internal view
1.3 What Is Good Software?
The Quality of the Product (continued)

McCall’s

quality
model
1.3 What Is Good Software?
The Quality of the Process

• Quality of the development and maintenance process is as important

as the product quality
• The development process needs to be modeled
• Modeling will address questions such as
• Where to find a particular kind of fault
• How to find faults early
• How to build in fault tolerance
• What are alternative activities
1.3 What Is Good
Software?
The Quality of the Process (continued)
• Models for process improvement
• SEI’s Capability Maturity Model (CMM)
• ISO 9000
• Software Process Improvement and Capability
dEtermination (SPICE)
1.3 What Is Good Software?
The Quality in the Context of the Business
Environment
• Business value is as important as technical value
• Business value (in relationship to technical value) must be
quantified
• A common approach: return on investment (ROI) – what is
given up for other purposes
• ROI is interpreted in different terms:
• reducing costs,
• predicting savings,
• improving productivity, and costs (efforts and resources)
1.4 Who Does Software Engineering? (continued)

• Participants (stakeholders) in a software development project

1.5 System Approach

• Hardware, software, interaction with people

• Identify activities and objects
• Define the system boundary
• Consider nested systems, systems interrelationship
1.5 System Approach
The Element of a System (continued)

• Example of systems: a human respiratory system

 1.5 System Approach
The Element of a System (continued)

• A computer system must also be clearly described: System definition

of a paycheck production
1.5 System Approach
Interrelated Systems

• Some systems are dependent to other systems

• The interdependencies may be complex
• It is possible for one system to exist inside another system
• If the boundary definitions are detailed, building a larger system
from the smaller ones is relatively easy
1.6 Engineering Approach
Building a System
• Requirement analysis and definition
• System design
• Program design
• Writing the programs
• Unit testing
• Integration testing
• System testing
• System delivery
• Maintenance
1.7 Members of the
Development Team
• Requirement analysts: work with the customers to identify and
document the requirements
• Designers: generate a system-level description of what the
system us supposed to do
• Programmers: write lines of code to implement the design
• Testers: catch faults
• Trainers: show users how to use the system
• Maintenance team: fix faults that show up later
• Librarians: prepare and store documents such as software
requirements
• Configuration management team: maintain correspondence
among various artifacts
1.7 Members of the Development Team
(continued)

• Typical roles played by the members of a development team

1.8 How Has SE Changed?
Wasserman's Seven Key Factors (continued)
• The key factors that have changed the software development
1.8 How Has SE Changed?
Wasserman's Discipline of Software
Engineering
• Abstractions
• Analysis and design methods and notations
• User interface prototyping
• Software architecture
• Software process
• Reuse
• Measurement
• Tools and integrated environments
 1.8 How Has SE Changed?
Abstraction

• A description of the problem at some level of generalization

• Hide details
1.8 How Has SE Changed?
Analysis and Design Methods and Notations

• Provide documentation
• Facilitate communication
• Offer multiple views
• Unify different views
1.8 How Has SE Changed?
User Interface Prototyping

• Prototyping: building a small version of a system

• Help users identify key requirements of a system
• Demonstrate feasibility
• Develop good user interface
1.8 How Has SE Changed?
Software Architecture

• A system’s architecture describes the system in terms of a set of

architectural units and relationships between these units
• Architectural decomposition techniques
• Modular decomposition
• Data-oriented decomposition
• Event-driven decomposition
• Outside-in-design decomposition
• Object-oriented decomposition
1.8 How Has SE Changed?
Software Reuse

• Commonalities between applications may allow reusing artifacts from

previous developments
• Improve productivity
• Reduce costs
• Potential concerns
• It may be faster to build a smaller application than searching for
reusable components
• Generalized components take more time to build
• Must clarify who will be responsible for maintaining reusable components
• Generality vs specificity: always a conflict
References

• http://eceweb1.rutgers.edu/~marsic/books/SE/instructor/slides/
• http://www.cs.ucf.edu/~turgut/COURSES/COP4331C_OOD_Fall19/CO
P4331C_OOD_Fall19.html