CSI37W1 Software

Engineering I -2023

Unit 1 – Why Software Engineering

Lecturer:
C. Kabuya
Topics

1.1 What is Software Engineering?

1.2 How Successful Have We Been?
1.3 What Is Good Software?
1.4 Who Does Software Engineering?
1.5 A System Approach
1.6 An Engineering Approach
1.7 Members of the Development Team
1.8 How Has Software Engineering Changed?
1.9 Information System Example

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.2
Learning Outcomes

• Explain what is software engineering.

• Examine the Software engineering’s track
record.
• Discover what constitutes good software
• Assess system approach is important to how
we develop software.
• Summarize description of stakeholders in
software team

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.3
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

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.4
1.1 What is Software Engineering
Solving Problems (continued)

• The analysis process

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.5
1.1 What is Software Engineering
Solving Problems (continued)

• The synthesis process

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.6
1.1 What is Software Engineering
Solving Problems (continued)

• Software engineering is the process of

designing, developing, and maintaining
software applications. It involves a
systematic approach to ensure the software
meets the user’s needs and is reliable,
efficient, and secure.
• Software engineering requires the application
of engineering principles, methods, and
techniques to the design, development,
testing, and maintenance of software
systems.
Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.7
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

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.8
1.1 What is Software Engineering
Where Does the SW Engineer Fit in? (continued)

• Relationship between computer science and

software engineering

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.9
1.2 How Successful Have We Been?

• Perform tasks more quickly and effectively

– Word processing, spreadsheets, e-mail
• Support advances in medicine, agriculture,
transportation, multimedia education, and
most other industries
• Many good stories
• However, software is not without problems

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.10
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

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.11
1.2 How Successful Have We Been?
Examples of Software Failure

• IRS hired Sperry Corporation to build an automated

federal income tax form processing process
– An extra $90 M was needed to enhance the original $103
product
– IRS lost $40.2 M on interests and $22.3 M in overtime
wages because refunds were not returned on time
• Malfunctioning code in Therac-25 killed several
people
• Reliability constraints have caused cancellation of
many safety critical systems
– Safety-critical: something whose failure poses a threat to
life or health

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.12
1.3 What Is Good Software?
Sidebar 1.2 Perspective on Quality

• The transcendental view: 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

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.13
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

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.14
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

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.15
1.3 What Is Good Software?
The Quality of the Product (continued)

• McCall’s quality model

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.16
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

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.17
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)

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.18
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)
Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.19
1.4 Who Does Software Engineering?

• Customer: the company, organization, or

person who pays for the software system
• Developer: the company, organization, or
person who is building the software system
• User: the person or people who will actually
use the system

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.20
1.4 Who Does Software Engineering?
(continued)

• Participants (stakeholders) in a software

development project

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.21
1.5 System Approach

• Hardware, software, interaction with people

• Identify activities and objects
• Define the system boundary
• Consider nested systems, systems
interrelationship

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.22
1.5 System Approach
The Element of a System

• Activities and objects

– An activity is an event initiated by a trigger
– Objects or entities are the elements involved in
the activities
• Relationships and the system boundaries
– A relationship defines the interaction among
entities and activities
– System boundaries determine the origin of input
and destinations of the output

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.23
1.5 System Approach
The Element of a System (continued)

• Example of systems: a human respiratory

system

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.24
1.5 System Approach
The Element of a System (continued)

• A computer system must also be clearly

described: System definition of a paycheck
production

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.25
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

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.26
1.5 System Approach
Interrelated Systems (continued)

• A layered system

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.27
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
Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.28
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

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.29
1.7 Members of the Development Team
(continued)

• Typical roles played by the members of a

development team

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.30
1.8 How Has Software Engineering Changed?
The Nature of the Change

• Before 1970s
– Single processors: mainframes
– Designed in one of two ways
• as a transformation: input was converted to output
• as a transaction: input determined which function
should be performed
• After 1970s
– Run on multiple systems
– Perform multi-functions

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.31
1.8 How Has SE Changed?
Wasserman's Seven Key Factors

1. Critically of time-to-market
2. Shifts in the economics of computing
3. Availability of powerful desktop computing
4. Extensive local- and wide-area networking
5. Availability and adoption of object-oriented
technology
6. Graphical user interfaces
7. Unpredictability of the waterfall model of
software development

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.32
1.8 How Has SE Changed?
Wasserman's Seven Key Factors (continued)

• The key factors that have changed the

software development

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.33
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

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.34
1.8 How Has SE Changed?
Abstraction

• A description of the problem at some level of

generalization
– Hide details

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.35
1.8 How Has SE Changed?
Analysis and Design Methods and Notations

• Provide documentation
• Facilitate communication
• Offer multiple views
• Unify different views

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.36
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

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.37
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

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.38
1.8 How Has SE Changed?
Software Process

• Many variations
• Different types of software need different
processes
– Enterprise-wide applications need a great deal of
control
– Departmental applications can take advantage of
rapid development

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.39
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
Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.40
1.8 How Has SE Changed?
Measurement

• Objective: describe quality goals in a

quantitative way

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.41
1.8 How Has SE Changed?
Tools and Integrated Environments

• Platform integration (on heterogeneous

networks)
• Presentation integration (commonality of
user interface)
• Process integration (linking tools and the
development process)
• Data integration (to share common data)
• Control integration (the ability of one tool to
initiate action in another one)

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.42
1.9 Information Systems Example
Piccadilly System

• Piccadilly Television: regional British TV

franchise
• Advertising scheme has many constraints:
– alcohol adverts only after 9 pm
– if actor in show, no same actor in advert within 45
minutes
– if advert in a class of products, no other advert in
same class during same break
– rates dependent on amount of time bought
• Software to determine, track advertising time

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.43
1.9 Information Systems Example
Piccadilly System (continued)

• Piccadilly Television franchise area

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.44
1.9 Information Systems Example
Piccadilly System (continued)

• Piccadilly system’s context diagram

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.45
1.10 Real Time Example

• Ariane-5 rocket, from the European Space

Agency
• June 4, 1996: functioned well for 40
seconds, then veered off course and was
destroyed
• Contained four satellites: cost was $500
million
• Reused code from Ariane-4 rocket

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.46
1.10 Real Time Example
Ariane-5 Definition of Quality

• From the Lions et al report:

– “… demonstrated the high quality of the Ariane-5
programme as regards engineering work in
general and completeness and traceability of
documents.”
– “… the supplier of the SRI … was only following
the specification given to it. … The exception
which occurred was not due to random failure but
a design error.”

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.47
1.11 What this Chapter Means for You

• Given a problem to solve

– Analyze it
– Synthesize a solution
• Understand that requirements may change
• Must view quality from several different
perspectives
• Use fundamental software engineering
concepts (e.g., abstractions and
measurements)
• Keep system boundary in mind

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.48
Questions

• Next Software Products

– Quiz 1
– Keep working on your projects.
– How does this unit influence your understanding
of your project.

Pfleeger and Atlee, Software Engineering: Theory and Practice Chapter 1.49