Software Engineering

(LECT 1)

Dr. Bharat Singh

Organization of this Lecture:

· What is Software Engineering?

· Programs vs. Software Products
· Evolution of Software
Engineering
· Notable Changes In Software
Development Practices
· Introduction to Life Cycle
Models
What is Software
Engineering?
· Engineering approach to
develop software.
- Building Construction Analogy.
· Systematic collection of past
experience:
- techniques,
- methodologies,
- guidelines.
Engineering Practice
· Heavy use of past experience:
- Past experience is systematically
arranged.
· Theoretical basis and
quantitative techniques
provided.
· Many are just thumb rules.
· Tradeoff between alternatives
· Pragmatic approach to cost-
Technology Development Pattern

Engineering

Technology

Esoteric Past
Craft Systematic Use of Past
Experience Experience and Scientific Basis
Unorganized Use of
Past Experience
Art
Time
Why Study Software Engineering? (1)

· To acquire skills to develop

large programs.
- Exponential growth in complexity and
difficulty level with size.
- The ad hoc approach breaks down
when
size of software increases: --- “One thorn

of experience is worth a whole wilderness of

warning.”
Why Study Software Engineering? (2)

· Ability to solve complex

programming problems:
- How to break large projects into
smaller and manageable parts?
· Learn techniques of:
- specification, design,
interface development,
testing, project management,
Why Study Software Engineering? (3)

· To acquire skills to be a
better programmer:
*Higher Productivity
*Better Quality Programs
Software Crisis
· The term software crisis refers to the numerous
challenges and difficulties faced by the software
industry during the 1960s and 1970s.
· The difficulty of writing the code for a computer program
which is correct and understandable is referred to as
software crisis.
· or Software crisis is also referred to as inability to hire
enough qualified programmers.
Software Crisis
· Software products:
- fail to meet user
requirements.
- frequently crash.
- expensive.
- difficult to alter, debug, and
enhance.
- often delivered late.
- use resources non-optimally.
Software Crisis (cont.)

Hw cost
Sw cost

1960 Year
1999
Relative Cost of Hardware and Software
 Software Crisis (cont.)

• The North East blackout in 2003- has been major power system failures in
the history of north which involves 100 power plants, 50 million customer
faced problem, $ 6 million dollar financial loss.

• Year 2000(Y2k) refers to the widespread snags in processing date after the
Year 2000. In 1960-80 when shortened the four digit date format like 1972 to
a 2 digit format like 72 because of "Limited Memory. Because of that 2000 was
shortened to 00. Million dollar were spent to handle this problem.

• Arian- 5 Space Rocket: In 1996, developed at cost of $7000 Million

Dollars over a period of 10 years was destroyed within less than 1 minutes after
its launch. As there was software bugs in rocket guidance system.

• "Dollar 924 lakhs": In 1996, US bank credit accounts of nearly 800 customer
with dollar 924 lakhs. This problem was due to main programming bug in the
banking system.

• 1991 during Gulf War, :The USA use patriot missiles as a defence against Iraqi
scud missile . However, patriot failed to hit the scud many times with cost life of
28 USA soldiers. In an inquiry it is found that a small bug had resulted in
miscalculation of missile path.
Factors contributing to the
software crisis

· Larger problems,
· Lack of adequate training in
software engineering,
· Increasing skill shortage,
· Low productivity
improvements.
General issues that affect
most software
· Heterogeneity
- Increasingly, systems are required to operate as
distributed systems across networks that include
different types of computer and mobile devices.
· Business and social change
- Business and society are changing incredibly quickly as
emerging economies develop and new technologies
become available. They need to be able to change their
existing software and to rapidly develop new software.
· Security and trust
- As software is intertwined with all aspects of our lives, it
is essential that we can trust that software.

Chapter 1 Introduction
Software engineering
diversity

· There are many different types of

software system and there is no
universal set of software techniques
that is applicable to all of these.
· The software engineering methods
and tools used depend on the type of
application being developed, the
requirements of the customer and
the background of the development
team. Chapter 1 Introduction
Application types
· Stand-alone applications
- These are application systems that run on a local
computer, such as a PC. They include all necessary
functionality and do not need to be connected to a
network.
· Interactive transaction-based applications
- Applications that execute on a remote computer and are
accessed by users from their own PCs or terminals.
These include web applications such as e-commerce
applications.
· Embedded control systems
- These are software control systems that control and
manage hardware devices. Numerically, there are
probably more embedded systems than any other type
Chapter 1 Introduction
Application types
· Batch processing systems
- These are business systems that are designed to
process data in large batches. They process large
numbers of individual inputs to create corresponding
outputs.
· Entertainment systems
- These are systems that are primarily for personal use
and which are intended to entertain the user.
· Systems for modeling and simulation
- These are systems that are developed by scientists and
engineers to model physical processes or situations,
which include many, separate, interacting objects.

Chapter 1 Introduction
Application types

· Data collection systems

- These are systems that collect data
from their environment using a set of
sensors and send that data to other
systems for processing.
· Systems of systems
- These are systems that are composed of
a number of other software systems.

Chapter 1 Introduction
Software engineering
fundamentals
· Some fundamental principles apply to all types of
software system, irrespective of the development
techniques used:
- Systems should be developed using a managed and
understood development process. Of course, different
processes are used for different types of software.
- Dependability and performance are important for all
types of system.
- Understanding and managing the software specification
and requirements (what the software should do) are
important.
- Where appropriate, you should reuse software that has
already been developed rather than write new software.
Chapter 1 Introduction
Software engineering and the
web
· The Web is now a platform for running application
and organizations are increasingly developing
web-based systems rather than local systems.
· Web services (discussed in Chapter 19) allow
application functionality to be accessed over the
web.
· Cloud computing is an approach to the provision
of computer services where applications run
remotely on the ‘cloud’.
- Users do not buy software but pay according to use.

Chapter 1 Introduction
Web software engineering
· Software reuse is the dominant approach for
constructing web-based systems.
- When building these systems, you think about how you can
assemble them from pre-existing software components and
systems.
· Web-based systems should be developed and
delivered incrementally.
- It is now generally recognized that it is impractical to
specify all the requirements for such systems in advance.
· User interfaces are constrained by the capabilities of
web browsers.
- Technologies such as AJAX allow rich interfaces to be
created within a web browser but are still difficult to use.
Web forms with local scripting are more commonly used.
Chapter 1 Introduction
Web-based software
engineering
· Web-based systems are complex
distributed systems but the fundamental
principles of software engineering
discussed previously are as applicable to
them as they are to any other types of
system.
· The fundamental ideas of software
engineering, discussed in the previous
section, apply to web-based software in
the same way that they apply to other
types of software system.
Chapter 1 Introduction
Key points
· Software engineering is an engineering discipline
that is concerned with all aspects of software
production.
· Essential software product attributes are
maintainability, dependability and security,
efficiency and acceptability.
· The high-level activities of specification,
development, validation and evolution are part of
all software processes.
· The fundamental notions of software engineering
are universally applicable to all types of system
development.
Chapter 1 Introduction
Key points
· There are many different types of system
and each requires appropriate software
engineering tools and techniques for their
development.
· The fundamental ideas of software
engineering are applicable to all types of
software system.
Software engineering ethics

· Software engineering involves wider

responsibilities than simply the application
of technical skills.
· Software engineers must behave in an
honest and ethically responsible way if
they are to be respected as professionals.
· Ethical behaviour is more than simply
upholding the law but involves following a
set of principles that are morally correct.
Issues of professional
responsibility
· Confidentiality
- Engineers should normally respect the
confidentiality of their employers or
clients irrespective of whether or not a
formal confidentiality agreement has
been signed.
· Competence
- Engineers should not misrepresent their
level of competence. They should not
knowingly accept work which is outwith
their competence.
Issues of professional
responsibility
· Intellectual property rights
- Engineers should be aware of local laws governing the
use of intellectual property such as patents, copyright,
etc. They should be careful to ensure that the
intellectual property of employers and clients is
protected.
· Computer misuse
- Software engineers should not use their technical skills
to misuse other people’s computers. Computer misuse
ranges from relatively trivial (game playing on an
employer’s machine, say) to extremely serious
(dissemination of viruses).
ACM/IEEE Code of Ethics
· The professional societies in the US have
cooperated to produce a code of ethical
practice.
· Members of these organisations sign up to
the code of practice when they join.
· The Code contains eight Principles related
to the behaviour of and decisions made by
professional software engineers, including
practitioners, educators, managers,
supervisors and policy makers, as well as
trainees and students of the profession.
Rationale for the code of
ethics
- Computers have a central and growing role in
commerce, industry, government, medicine, education,
entertainment and society at large. Software engineers
are those who contribute by direct participation or by
teaching, to the analysis, specification, design,
development, certification, maintenance and testing of
software systems.
- Because of their roles in developing software systems,
software engineers have significant opportunities to do
good or cause harm, to enable others to do good or
cause harm, or to influence others to do good or cause
harm. To ensure, as much as possible, that their efforts
will be used for good, software engineers must commit
themselves to making software engineering a beneficial
and respected profession.
Chapter 1 Introduction
The ACM/IEEE Code of
Ethics
Software Engineering Code of Ethics and Professional Practice

ACM/IEEE-CS Joint Task Force on Software Engineering Ethics and Professional

Practices

PREAMBLE
The short version of the code summarizes aspirations at a high level of the
abstraction; the clauses that are included in the full version give examples and
details of how these aspirations change the way we act as software engineering
professionals. Without the aspirations, the details can become legalistic and
tedious; without the details, the aspirations can become high sounding but
empty; together, the aspirations and the details form a cohesive code.
Software engineers shall commit themselves to making the analysis,
specification, design, development, testing and maintenance of software a
beneficial and respected profession. In accordance with their commitment to the
health, safety and welfare of the public, software engineers shall adhere to the
following Eight Principles:

Chapter 1 Introduction
Ethical principles
1. PUBLIC - Software engineers shall act consistently with the public interest.
2. CLIENT AND EMPLOYER - Software engineers shall act in a manner that is in the best
interests of their client and employer consistent with the public interest.
3. PRODUCT - Software engineers shall ensure that their products and related modifications
meet the highest professional standards possible.
4. JUDGMENT - Software engineers shall maintain integrity and independence in their
professional judgment.
5. MANAGEMENT - Software engineering managers and leaders shall subscribe to and
promote an ethical approach to the management of software development and
maintenance.
6. PROFESSION - Software engineers shall advance the integrity and reputation of the
profession consistent with the public interest.
7. COLLEAGUES - Software engineers shall be fair to and supportive of their colleagues.
8. SELF - Software engineers shall participate in lifelong learning regarding the practice of
their profession and shall promote an ethical approach to the practice of the profession.

Chapter 1 Introduction
Ethical dilemmas

· Disagreement in principle with the

policies of senior management.
· Your employer acts in an unethical
way and releases a safety-critical
system without finishing the testing
of the system.
· Participation in the development of
military weapons systems or nuclear
systems.
Case studies
· A personal insulin pump
- An embedded system in an insulin pump used
by diabetics to maintain blood glucose control.
· A mental health case patient management
system
- A system used to maintain records of people
receiving care for mental health problems.
· A wilderness weather station
- A data collection system that collects data
about weather conditions in remote areas.
Chapter 1 Introduction
Programs versus Software
Products
· Usually small in size · Large
· Author himself is · Large number of
sole user users
· Single developer · Team of developers
· Lacks proper user · Well-designed
interface interface
· Lacks proper · Well documented &
documentation user-manual
· Ad hoc prepared
· Systematic
development. development
Computer Systems
Engineering
· Computer systems
engineering:
- encompasses software
engineering.
· Many products require
development of software as
well as specific hardware to
run it:
- a coffee vending machine,
- a mobile communication
product, etc.
Computer Systems
Engineering

· The high-level problem:

- deciding which tasks are to be
solved by software
- which ones by hardware.
Computer Systems Engineering
(CONT.)

· Often, hardware and software

are developed together:
- Hardware simulator is used
during software development.
· Integration of hardware and
software.
· Final system testing
Computer Systems Engineering
(CONT.)

Feasibility
Study
Requirements
Analysis and
Specification Hardware
Development
Hardware
Software
Partitioning
Software
Development Integration
and Testing

Project Management
Emergence of Software Engineering

· There are mainly Six Stages of

the Emergence of Software
Engineering:
- Early Computer Programming
- High-level Language Programming
- Control Flow-based Design
- Data Structure-oriented Design
- Data Flow-oriented Design
- Object-oriented Design
Emergence of Software Engineering

· Early Computer
Programming (1950s):
- Programs were being written
in assembly language.
- Programs were limited to
about a few hundreds of lines
of assembly code.
Early Computer Programming
(50s)
· Every programmer
developed his own style of
writing programs:
- according to his intuition
(exploratory programming).
* informal development style or
builds and fix the style
High-Level Language
Programming (Early 60s)

· High-level languages such

as FORTRAN, ALGOL, and
COBOL were introduced:
- This reduced software
development efforts greatly.
High-Level Language
Programming (Early 60s)

· Software development
style was still exploratory.
- Typical program sizes were
limited to a few thousands
of lines of source code.
Control Flow-Based Design (late
60s)

· Size and complexity of

programs increased further:
- exploratory programming
style proved to be insufficient.

· Programmers found:
- very difficult to write cost-
effective and correct
Control Flow-Based Design
(late 60s)

· Programmers found:
- programs written by others
very difficult to understand and
maintain.
· To cope up with this
problem, experienced
programmers advised: ``Pay
particular attention to the design
of the program's control
Control Flow-Based Design (late 60s)

· A program's control structure

indicates:
- the sequence in which the
program's instructions are
executed.
· To help design programs having
good control structure:
- flow charting technique was
developed.
Control Flow-Based Design (late 60s)

· Using flow charting

technique:
- one can represent and
design a program's control
structure.
- Usually one understands a
program:
*by mentally simulating the
Control Flow-Based Design
(Late 60s)

· A program having a
messy flow chart
representation:
- difficult to understand
and debug.

111
Control Flow-Based Design (Late 60s)

· It was found:
- GO TO statements makes
control structure of a program
messy
- GO TO statements alter the
flow of control arbitrarily.
- The need to restrict use of GO
TO statements was
recognized.
Control Flow-Based Design (Late 60s)

· Many programmers had

extensively used assembly
languages.
- JUMP instructions are
frequently used for program
branching in assembly
languages,
- programmers considered use
Control-flow Based Design (Late 60s)

· At that time, Dijkstra

published his article:
- “Goto Statement Considered
Harmful” Comm. of ACM,
1969.
· Many programmers were
unhappy to read his article.
Control Flow-Based Design (Late 60s)

· They published several

counter articles:
- highlighting the
advantages and
inevitability of GO TO
statements.
Control Flow-Based Design (Late 60s)

· But, soon it was conclusively

proved:
- only three programming
constructs are sufficient to
express any programming logic:
* sequence (e.g. a=0;b=5;)
* selection (e.g.if(c=true) k=5 else
m=5;)
* iteration (e.g. while(k>0) k=j-
Control-flow Based Design (Late 60s)

· Everyone accepted:
- it is possible to solve any
programming problem
without using GO TO
statements.
- This formed the basis of
Structured Programming
methodology.
Structured Programming

· A program is called
structured
- when it uses only the
following types of
constructs:
*sequence,
*selection,
*iteration
Structured programs

· Unstructured control
flows are avoided.
· Consist of a neat set of
modules.
· Use single-entry, single-exit
program constructs.
Structured programs

· However, violations to
this feature are
permitted:
- due to practical
considerations such as:
*premature loop exit to
support exception handling.
Structured programs

· Structured programs are:

- Easier to read and
understand,
- easier to maintain,
- require less effort and time
for development.
Structured Programming

· Research experience
shows:
- programmers commit less
number of errors
*while using structured if-
then-else and do-while
statements
*compared to test-and-
Data Structure-Oriented Design
(Early 70s)

· Soon it was discovered:

- it is important to pay more
attention to the design of
data structures of a
program
*than to the design of its
control structure.
Data Structure-Oriented Design
(Early 70s)

· Techniques which
emphasize designing the
data structure:
- derive program structure from
it:
*are called data structure-
oriented design
techniques.
Data Structure Oriented Design
(Early 70s)

· Example of data
structure-oriented design
technique:
- Jackson's Structured
Programming(JSP)
methodology
*developed by Michael
Jackson in 1970s.
Data Structure Oriented Design
(Early 70s)

· JSP technique:
- program code structure
should correspond to the
data structure.
Data Structure Oriented Design
(Early 70s)

· In JSP methodology:
- a program's data structures
are first designed using
notations for
* sequence, selection, and
iteration.
- Then data structure design is
used :
* to derive the program structure.
Data Structure Oriented Design
(Early 70s)

· Several other data

structure-oriented
Methodologies also exist:
- e.g., Warnier-Orr
Methodology.
Data Flow-Oriented Design (Late 70s)

· Data flow-oriented
techniques advocate:
- the data items input to a
system must first be
identified,
- processing required on the
data items to produce the
required outputs should be
determined.
Data Flow-Oriented Design (Late 70s)

· Data flow technique

identifies:
- different processing
stations (functions) in a
system
- the items (data) that flow
between processing
stations.
Data Flow-Oriented Design (Late 70s)

· Data flow technique is a

generic technique:
- can be used to model the working
of any system
* not just software systems.
· A major advantage of the
data flow technique is its
simplicity.
Data Flow Model of a Car
Assembly Unit
Engine Store Door Store

Chassis with Partly

Engine Assembled
Fit Fit Car Fit Paint and Car
Engine Doors Wheels Assembled Test
Car

Chassis Store Wheel Store

Object-Oriented Design (80s)

· Object-oriented technique:
- an intuitively appealing
design approach:
- natural objects (such as
employees, pay-roll-register,
etc.) occurring in a problem
are first identified.
Object-Oriented Design (80s)

· Relationships among
objects:
- such as composition,
reference, and inheritance are
determined.
· Each object essentially acts
as
- a data hiding (or data
Object-Oriented Design (80s)

· Object-Oriented Techniques
have gained wide
acceptance:
- Simplicity
- Reuse possibilities
- Lower development time and
cost
- More robust code
- Easy maintenance
Evolution of Design
Techniques
Object-Oriented

Data flow-based

Data structure-
based

Control flow-
based

Ad hoc
Evolution of Other Software
Engineering Techniques
· The improvements to the
software design
methodologies
- are indeed very conspicuous.
· In additions to the software
design techniques:
- several other techniques
evolved.
Evolution of Other Software
Engineering Techniques
- life cycle models,
- specification techniques,
- project management
techniques,
- testing techniques,
- debugging techniques,
- quality assurance techniques,
- software measurement
techniques,
- CASE tools, etc.
Differences between the exploratory style
and modern software development
practices

· Use of Life Cycle Models

· Software is developed
through several well-defined
stages:
- requirements analysis and
specification,
- design,
- coding,
- testing, etc.
Differences between the exploratory style
and modern software development
practices

· Emphasis has shifted

- from error correction to error
prevention.
· Modern practices
emphasize:
- detection of errors as close to
their point of introduction as
possible.
Differences between the exploratory style
and modern software development
practices (CONT.)

· In exploratory style,
- errors are detected only
during testing,
· Now,
- focus is on detecting as
many errors as possible in
each phase of
development.
Differences between the exploratory style
and modern software development
practices (CONT.)

· In exploratory style,
- coding is synonymous with
program development.
· Now,
- coding is considered only a
small part of program
development effort.
Differences between the exploratory style
and modern software development
practices (CONT.)

· A lot of effort and attention is

now being paid to:
- requirements specification.
· Also, now there is a distinct
design phase:
- standard design techniques are
being used.
Differences between the exploratory style
and modern software development
practices (CONT.)
· During all stages of
development process:
- Periodic reviews are being
carried out
· Software testing has
become systematic:
- standard testing techniques
are available.
Differences between the exploratory style
and modern software development
practices (CONT.)
· There is better visibility of design
and code:
- visibility means production of good
quality, consistent and standard
documents.
- In the past, very little attention was
being given to producing good quality
and consistent documents.
- We will see later that increased
visibility makes software project
management easier.
Differences between the exploratory style
and modern software development
practices (CONT.)

· Because of good
documentation:
- fault diagnosis and maintenance
are smoother now.
· Several metrics are being used:
- help in software project
management, quality assurance,
etc.
Differences between the exploratory style
and modern software development
practices (CONT.)

· Projects are being thoroughly

planned:
- estimation,
- scheduling,
- monitoring mechanisms.
· Use of CASE tools.
Software Life Cycle
· Software life cycle (or software
process):
- series of identifiable stages
that a software product
undergoes during its life time:
* Feasibility study
* requirements analysis and
specification,
* design,
* coding,
* testing
Life Cycle Model
· A software life cycle model (or
process model):
- a descriptive and diagrammatic
model of software life cycle:
- identifies all the activities required for
product development,
- establishes a precedence ordering
among the different activities,
- Divides life cycle into phases.
Life Cycle Model (CONT.)

· Several different activities

may be carried out in each
life cycle phase.
- For example, the design stage
might consist of:
* structured analysis activity followed
by
* structured design activity.
Why Model Life Cycle ?
· A written description:
- forms a common understanding
of activities among the software
developers.
- helps in identifying
inconsistencies, redundancies,
and omissions in the
development process.
- Helps in tailoring a process model
for specific projects.
Why Model Life Cycle ?

· Processes are tailored for

special projects.
- A documented process
model
* helps to identify where the
tailoring is to occur.
Life Cycle Model (CONT.)

· The development team must

identify a suitable life cycle
model:
- and then adhere to it.
- Primary advantage of adhering to
a life cycle model:
* helps development of software in a
systematic and disciplined manner.
Life Cycle Model (CONT.)

· When a program is
developed by a single
programmer ---
- he has the freedom to decide
his exact steps.
Life Cycle Model (CONT.)

· When a software product is

being developed by a team:
- there must be a precise
understanding among team
members as to when to do what,
- otherwise it would lead to chaos
and project failure.
Life Cycle Model (CONT.)

· A software project will never

succeed if:
- one engineer starts writing code,
- another concentrates on writing
the test document first,
- yet another engineer first defines
the file structure
- another defines the I/O for his
portion first.
Life Cycle Model (CONT.)

· A life cycle model:

- defines entry and exit criteria
for every phase.
- A phase is considered to be
complete:
* only when all its exit criteria are
satisfied.
Life Cycle Model (CONT.)

· The phase exit criteria for the

software requirements specification
phase:
- Software Requirements Specification
(SRS) document is complete,
reviewed, and approved by the
customer.
· A phase can start:
- only if its phase-entry criteria have
been satisfied.
Life Cycle Model (CONT.)

· It becomes easier for

software project managers:
- to monitor the progress of the
project.
Life Cycle Model (CONT.)

· When a life cycle model is

adhered to,
- the project manager can at any
time fairly accurately tell,
* at which stage (e.g., design, code,
test, etc. ) of the project is.
- Otherwise, it becomes very
difficult to track the progress of
the project
* the project manager would have to
Life Cycle Model (CONT.)

· This usually leads to a

problem:
- known as the 99% complete
syndrome.
Life Cycle Model (CONT.)

· Many life cycle models have been

proposed.
· We will confine our attention to a
few important and commonly used
models.
- classical waterfall model
- iterative waterfall,
- evolutionary,
- prototyping, and
- spiral model
Summary

· Software engineering is:

- systematic collection of
decades of programming
experience
- together with the innovations
made by researchers.
Summary

· A fundamental necessity
while developing any large
software product:
- adoption of a life cycle
model.
Summary
· Adherence to a software life
cycle model:
- helps to do various development
activities in a systematic and
disciplined manner.
- also makes it easier to manage a
software development effort.
Reference

· R. Mall, “Fundamentals of Software

Engineering,” Prentice-Hall of India,
2015, CHAPTER 1.