ECNG-3023 Introduction to

Software Engineering
(September 2009)

What is Software Engineering?

The IEEE Computer Society defines software
engineering as:
The application of a systematic,
disciplined, quantifiable approach to the
development, operation and maintenance of
software; that is, the application of
engineering to software.

Dr. Sastry MKS

Department of Electrical &
Computer Engg
University of West Indies
St. Augustine Campus
Trinidad & Tobago

The study of approaches as above.

Problem solving (Analysis)

We typically solve a problem by analysing it,
that is by breaking it down into pieces.

Problem solving (Synthesis)

Once we have analysed the problem, we must
construct our solution from components that
address the problem's various aspects

Problem

1
4

4
2

3
4

Solution

How are Software Projects different?

The Software Iceberg

The
Product

Invisibility
No physical presence

Flexibility
After all it's software

Complexity
no physical constraints, yet many possible paths
of solution flow depending on the logic for
decision making.

What the customers see

Code

Specifications
Simulators Data Definitions
Plans
Development Systems Databases
Standards & Procedures
Automatic test Equipment
Manuals
Compilers, Operating Systems, Utilities

DBMS

Configuration Management

CASE

What is CASE???
Computer Aided Software Engineering
Find out different CASE Tools!!!

Key Issues Facing Software Developers

Unfulfilled demand
Increasing complexity
Greater customer expectations
Rapid obsolescence
Increasing competition
Shorter product cycle times
Producing more with less
Evolving methods and tools

What Does Project Failure Mean??

Late delivery? No delivery at all?
Not delivering what was agreed to
or what was announced?
Over budget?
Not meeting revenue expectations?
Quality below expectations?

Some reasons why Products Fail

Price
Mature market
Lack of essential capabilities
Difficult to use
Unreliable
Poor developer reputations
Poor product support

Terminology Bugs
A fault occurs when a human makes a mistake,
called an error in performing some software
activity.
A failure is a departure from the systems
required behaviour It can be discovered before
or after system delivery or during operation and
maintenance. Since requirements documents
can contain faults, failures can exist even
though the system is performing as specified!

Some reasons why SW Projects Fail

Not understanding what the product
must do
Uncontrolled changes
Optimistic thinking
Insufficient resources
Lack of disciplined development
Confusion about what needs to be done
Ineffective teamwork
Failure to consider business needs

Reasons for Success

Good understanding of the problem to solve
Good planning and execution
Extraordinary effort and commitment by
individuals
Luck
Satisfy an unfulfilled need
Novelty
Value
Marketing strategy

What is a good SW?

Quality of the product?
Quality of the process?
Quality in the context of the
Business Environment?

Quality of SW Product
Correctness
extent to which program
fulfils its specification

Reliability
systems ability not to
fail

Efficiency
use of resources, e.g.
processor time, storage

Integrity
protection of program
from unauthorised
access

Usability
ease of software

Quality of SW Product
Correctness
Reliability
Efficiency
Integrity
Usability
Maintainability

Testability
Flexibility
Portability
Reusability
Interoperability

Quality of SW Product

Maintainability
effort required to locate
and fix a fault in
program within its
operating environment

Testability
ease of testing program,
to ensure it is error-free
and meets its
specification

Flexibility
Ease of making
changing required by
changes in the operating
environment

Quality of SW Process
many activities can affect ultimate product quality
By modelling a process, we can examine it and look
for improvements
Where and when are we likely to find a particular kind of
fault?
How can we find faults earlier in the development
process?
How can we build in fault tolerance so that we can
minimize the likelihood that a fault will become a
failure?
Are there alternative activities that can make our process
more effective or efficient at assuring quality?

Portability
Effort required to transfer a program
from one environment to another

Reusability
Ease of reusing software in a
different context

Interoperability
Effort required to couple system to
another system

Quality from Business Point of View

A view in terms of the products and
services being provided by the business
in which the software is embedded.
i.e., we look at the business value.
can be as simple as Return On Investment
(ROI) or some more elaborate measure.

Who does SWE?

$$$,
needs

Customer
Sponsors system
development

Elements of a system:
Activities and Objects

Contractual
obligation

User
Uses
system

Systems Approach

Relationships and the System Boundary

Needs
Software system

Developer
Builds
system

Activities and Objects

Distinguish between activities and objects:
activity is something that happens in a system.
Usually described as event initiated by trigger
Transforms one thing to another by changing a characteristic,
e.g.
data element moved from one location to another
data element is changed from one value to another
data element is combined with other data to supply input for yet
another activity

object or entity is element involved in the activity.

Nested systems and system interrelationships

Relationships and the System

Boundary
A system is defined as a collection of things:
a set of entities,
a set of activities,
a description of the relationships among entities and
activities,
and a definition of the boundary of the system.

Boundary states what is included and what is not

Usually related in some way: arranged in a table or grouped as

records with pre-defined format

Examples: the human respiratory system, a paycheck

production system

Nested systems
It is possible for one system to exist within
another system, e.g. sensor system
One can have various functions of the sensors nested
within each other.

Boundary of system is important to see what is:

within the system
outside of the system
what crosses the boundary of the system

An analogy of software
engineering
Determining and

Requirements analysis
analysing
and definition
requirements
Producing and
System design
documenting the
design
Detailed
specifications
Identifying and
Program design
designing components

7 Factors Altering SW Engineering

Analogy ...
Building components Writing programs
Testing components Unit testing
Integrating
Integration testing
components

Making final
modifications
Continuing
maintenance

System testing
System delivery
Maintenance

Key Factors affecting SWE

Key Factors that changed SWE

1.Criticality of time to market for commercial

products
Business must ready their new products and services
before their competitors do

2.Shifts in the economics of computing

Lower hardware costs and greater development and
maintenance costs

3.Availability of powerful desktop computing

More development power in hands of users, therefore
software engineers are likely to be building more
complex systems than before

4.Extensive networks available

Makes it easier for users to find information without
special applications e.g. searching WWW is quick, easy
and effective

5. Availability and adoption of object-oriented

technology
Makes available reusable modules for immediate and
speedy inclusion in new applications

6. Graphical User Interfaces (GUIs)

Helps to put a friendly face (appearance) on
complicated applications

7. Unpredictability of the waterfall method

Developing subsystems in parallel requires
development process very different from waterfall
model

Discipline of SWE
Abstraction

Abstraction
Analysis and Design methods and Notations
User Interface Prototyping
Software Architecture
Software Process
Reuse
Measurement
Tools and Integrated Environments

Abstraction is a description of the problem at some

level of generalisation that allows us to concentrate
on the key aspects of the problem without getting
involved in the difficulties of the details.
Typically involves identifying classes of objects
that allow us to group items together so we:
Can deal with fewer things, and
Concentrate on the commonalities of items in each class

Analysis and Design Methods and

Notations
These offer a
Communication medium
Communication and documentation of decisions among
development team

Ability to build models

Ability to check models for completeness and
consistency
Reuse requirements and design components from
previous projects

User interface Prototyping

Prototyping is building a small version of a system,
usually with limited functionality
Prototypes can be used to:
Help the user/customer identify the key requirements of a
system
Demonstrate feasibility of a design or approach

Usually an iterative process:

Build prototype
Evaluate it with user and customer feedback
Consider how changes might improve product or design
Build another prototype OR iteration ends when
developer and customer are satisfied with solution

Software architecture (continued)

Software architecture
Importance of overall architecture of system is:
ease of implementation and testing
speed and effectiveness of maintenance and change.

The quality of the architecture can make or break a

system.
Systems architecture describes system in terms of:
set of architectural units, and
map of how units relate to each other

Software process

Five ways of decomposing a system

Modular: based upon assigning functions to
modules
Data-oriented: based upon external data structures
Event-oriented: based upon events that the system
must handle
Outside-in: based upon user inputs to the system
Object-Oriented: based upon identifying classes of
objects and their interrelationships

Reuse
We take advantage of commonalities across
applications by reusing items from previous
development.
Reuse pertains not only to code but to design, test
data, requirements etc.

Measurement
Measurement is a driving force in software
engineering research:
improving our processes, resources and methods so that
we produce and maintain better products.
But sometimes we express measurements generally, with
no quantitative description.

We would like to quantify:

where we can and what we can,
describe our actions and outcomes in a common
mathematical language that allows us to compare
progress across disparate projects.

Therac-25 (A SW Disaster)
Computers are increasingly being introduced into safetycritical systems and as a consequence, have been involved
in accidents.

Tools and integrated environments

Issues in tool integration
Platform: the ability of tools to interoperate on a
heterogeneous network
Presentation: commonality of the user interface
Process: linkage between the tools and the
development process
Data: the way the tools share data
Control: the ability of one tool to notify and initiate
action in another.

Therac-25 routines(from IEEE Computer

July 1993)

Some of the most widely cited software-related accidents in

safety-critical systems involved a computerized radiation
therapy machine called the Therac-25.
The Therac-25 is a medical linear accelerator manufactured
by AECL to treat Cancer Patients with radiation therapy.
Between June 1985 and January 1987, six known accidents
involving massive overdoses by the Therac-25 --- with
resultant deaths and serious injuries.

End of Lesson I

Thank you