Software Engineering

1
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
 Summary
2
What is Software
Engineering?
 “A systematic collection of good program development practices and
techniques.”
 Engineering approach to develop software.
 Software engineering discusses systematic and cost effective
techniques for software development. These techniques help
develop software using engineering approach.
 Systematic collection of past experience:
 techniques,
 methodologies,
 guidelines.

3
Software + Engineering

 The term software engineering is composed of two words, software

and engineering.

 Software is considered to be a collection of executable programming code,

associated libraries and documentations. Software, when made for a
specific requirement is called software product.

 Engineering on the other hand, is all about developing products, using well-
defined, scientific principles and methods.

 So, we can define software engineering as an engineering branch

associated with the development of software product using well-
defined scientific principles, methods and procedures.

 The outcome of software engineering is an efficient and reliable

software product.
4
Definition

 IEEE defines software engineering as:

The application of a systematic,

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

5
 Scope and necessity of software engineering

 Ex- Difference between building a Wall and a

Multistoried Building.

 Without using software engineering

principles it would be difficult to develop
large programs.

 In industry it is usually needed to develop

large programs to accommodate multiple
functions.

 A problem with developing such large

commercial programs is that the complexity
and difficulty levels of the programs increase
exponentially with their sizes Increase in development time and
6
effort with problem size
 For example, a program of size 1,000 lines of code has
some complexity.

 But a program with 10,000 LOC is not just 10 times

more difficult to develop, but may as well turn out to be
100 times more difficult unless software engineering
principles are used.

 In such situations software engineering techniques

come to rescue. Software engineering helps to reduce
the programming complexity.

 Software engineering principles use two important

techniques to reduce problem complexity: abstraction
and decomposition.
7
 The principle of abstraction implies that a
problem can be simplified by
omitting irrelevant details.

 Consider only those aspects of the

problem that are relevant for
certain purpose and suppress other
aspects that are not relevant for the
given purpose.

 Once the simpler problem is solved, then

the omitted details can be taken into
consideration to solve the next lower
level abstraction, and so on.

 Abstraction is a powerful way of reducing

the complexity of the problem.

8
Abstraction
Problem 1 : Develop understanding on some country. How to start?
Solution
 Check maps first.
 Political map - It is the political abstraction, shows state, city,
national boundaries. But physical aspects are ignored.
 Physical map - It is the physical abstraction, shows all physical
features like mountains, rivers, coastlines etc. But ignores state/city
etc.
Multiple abstractions are possible for the same object.In each
abstraction, some properties are taken into consideration and
rest are ignored.
 The other approach to tackle problem complexity is decomposition.
A complex problem is divided into several smaller problems and then
the smaller problems are solved one by one.

 However, in this technique any random decomposition of a problem

into smaller parts will not help.

 The problem has to be decomposed such that each component of the

decomposed problem can be solved independently and then
the solution of the different components can be combined to get the
full solution.

 Challenge: A good decomposition of a problem as should minimize

interactions among various components.

 If the different subcomponents are interrelated, then the different

components cannot be solved separately and the desired reduction in
complexity will not be realized.
10
Decomposition
 Technology Development
Pattern
Engineering

Technology

Esoteric Past
Craft Systematic Use of Past
Experience Experience and Scientific Basis
Unorganized Use of
Past Experience
Art
Time

Esoteric : intended for or likely to be understood by only a small number of people

with a specialized knowledge or interest. 12
NEED OF SOFTWARE ENGINEERING

Because of higher rate of change in user requirements and

environment on which the software is working.
Large software - It is easier to build a wall than to a house or
building, likewise, as the size of software become large engineering has
to step to give it a scientific process.

Scalability- If the software process were not based on scientific and

engineering concepts, it would be easier to re-create new software
than to scale an existing one.

Cost- As hardware industry has shown its skills and huge

manufacturing has lower down the price of computer and electronic
hardware. But the cost of software remains high if proper process is
not adapted.

13
NEED OF SOFTWARE ENGINEERING

Dynamic Nature- The always growing and adapting nature

of software hugely depends upon the environment in which
the user works.

If the nature of software is always changing, new

enhancements need to be done in the existing one. This is
where software engineering plays a good role.

Quality Management- Better process of software

development provides better and quality software product.

14
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.

15
Software Crisis (cont.)

Ratio of Hw
cost to
Sw cost
(HW/SW)

1960 Year 1999

Relative Cost of Hardware and Software

At present, organisations are spending much more on

software than hardware. 16
Factors contributing to the
software crisis

 Larger problems,
 Lack of adequate training in
software engineering,
 Increasing skill shortage,
 Low productivity improvements.

17
Programs versus Software
Products

 Usually small in size  Large

 Author himself is sole  Large number of
user users
 Single developer  Team of developers
 Lacks proper user  Well-designed
interface interface
 Lacks proper  Well documented &
documentation user-manual prepared
 Ad hoc development.  Systematic development

18
CHARACTERESTICS OF GOOD SOFTWARE

 A software product can be judged by what it

offers and how well it can be used.

 This software must satisfy on the following

grounds:
 Operational
 Transitional
 Maintenance

19
Operational

 This tells us how well software works in

operations. It can be measured on:
 Budget : in terms of cost, manpower
 Usability : ease of use
 Efficiency : minimum expenditure of time and effort
 Correctness: with respect to a specification
 Functionality : having a practical use
 Dependability : extent to which a critical system is
trusted by its users
 Security : degree of resistance or protection from
20
Transitional
 This aspect is important when the software is moved from
one platform to another:
 Portability : usability of the same software in
different environments
 Interoperability : ability of a system or a product to
work with other systems
 Reusability : use of existing assets in some form
within the software product development
process
 Adaptability : able to change or be changed in order
to fit or work better in some situation
 C compilers are readily available for the majority of operating systems, which in turn makes C
programs very portable
 Interoperability is the design of things to work together- a contact management app might integrate
with a sales force automation tool to sync sales contacts.
 The software library is a good example of code reuse.
 Adaptability - a)dual cell phone changes switches sim. b)if user presses character keys while entering
21
numeric data the software can be designed to ignore such incorrect key presses.
Maintenance
 This aspect briefs about how well a software has
the capabilities to maintain itself in the ever-
changing environment:
 Modularity: degree to which a system's components
may be separated and recombined
 Maintainability: degree to which an application is
understood, repaired, or enhanced
 Flexibility: ability for the solution to adapt to
possible or future changes in its requirements
 Scalability: ability of a program to scale

22
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.

23
Computer Systems
Engineering
 The high-level problem:
 deciding which tasks are to be solved by software
 which ones by hardware.

24
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

25
Computer Systems
Engineering (CONT.)

Feasibility
Study

Requirements Hardware
Analysis and Development
Specification

Hardware Software
Partitioning
Software Integration
Development and Testing

Project Management

26
Evolution of software design techniques over the last
50 years.
 During the 1950s, most programs were being written in
assembly language.

 These programs were limited to about a few hundreds

of lines of assembly code, i.e. were very small in size.

 Every programmer developed programs in his

own individual style - based on his intuition.

 This type of programming was called Exploratory

Programming.

27
 The next significant development which occurred during early
1960s in the area computer programming was the high-level
language programming.

 Use of high-level language programming reduced development

efforts and development time significantly.

 Languages like FORTRAN, ALGOL, and COBOL were introduced at

that time.

 As the size and complexity of programs kept on increasing, the

exploratory programming style proved to be insufficient.

 Programmers found it increasingly difficult not only to write cost-

effective and correct programs, but also to understand and
maintain programs written by others.

28
 In late 1960s to cope with this problem, particular attention to the
design of the program’s control flow structure was advised.
 It introduced “GOTO” statement which makes control structure of
a program complicated and messy.
 The use of "GOTO" statements in high-level languages were very
natural because of their familiarity with JUMP statements which
are very frequently used in assembly language programming. But
sometimes GOTO is making the loop very complex, and considered
harmful.
 Due to the challenges of previous structure it was conclusively
proved that only three programming constructs – sequence,
selection, and iteration – were sufficient to express any
programming logic.
 This formed the basis of the structured programming
methodology.
29
Control Flow-Based Design (Late 60s)

Structured program

 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-k;)
Features of a structured program.

 A structured program uses three types of program constructs

i.e. selection, sequence and iteration. Easy to read and
understand

 Structured programs avoid unstructured control flows by

restricting the use of GOTO statements.

 A structured program consists of a well partitioned set of

modules.

 Structured programming uses single entry, single-exit program

constructs such as if-then-else, do-while, etc.

 Thus, the structured programming principle emphasizes

designing neat control structures for programs. 31
 After structured programming, the next important
development was data structure-oriented design.

 For writing a good program, it is important to pay more

attention to the design of data structure, of the program
rather than to the design of its control structure.

 Data structure oriented design techniques actually help

to derive program structure from the data structure of the
program.

 Example of a very popular data structure-oriented design

technique is Jackson's Structured Programming (JSP)
methodology, developed by Michael Jackson in the1970s.
a data structure is a data organization and storage format that enables
efficient access and modification. More precisely, a data structure is a
collection of data values, the relationships among them, and the
functions or operations that can be applied to the data 32
 Next significant development in the late 1970s was the
development of data flow-oriented design technique.

 Experienced programmers stated that to have a good

program structure, one has to study how the data
flows from input to the output of the program.

 Every program reads data and then processes that data

to produce some output.

 Once the data flow structure is identified, then

from there one can derive the program structure.

33
 Object-oriented design (1980s) is the latest and very
widely used technique.

 It has an intuitively appealing design approach in which

natural objects (such as employees, pay-roll register,
etc.) occurring in a problem are first identified.

 Relationships among objects (such as composition,

reference and inheritance) are determined.

 Each object essentially acts as a data hiding entity.

34
Evolution of Design
Techniques
Object-Oriented

Data flow-based

Data structure-
based

Control flow-
based

Ad hoc

35
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.

36
Exploratory Programming

Modern Software
development process
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.

38
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.
39
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.
40
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.
41
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.

42
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.
43
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.
 The models developed increases visibility
which makes software project management
easier.
44
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.

45
Differences between the exploratory
style and modern software
development practices (CONT.)

 Projects are being thoroughly

planned:
 estimation,
 scheduling,
 monitoring mechanisms.
 Use of CASE tools.

46
Exploratory style vs. modern style of software
development.

Exploratory style Modern style

Emphasis on error correction Emphasis on error prevention

Coding was considered Coding is regarded as only a

synonymous with software small part of the overall software
development. development activities.

Believed in developing a working There are several development

system as quickly as possible and activities such as design and
then successively modifying it until testing which typically require
it performed satisfactorily. much more effort than coding.

47
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
48
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.
49
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.

50
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.
51
Why Model Life Cycle ?

 Processes are tailored for special

projects.
A documented process model
 helps to identify where the
tailoring is to occur.

52
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.

53
Life Cycle Model (CONT.)

 When a program is developed

by a single programmer ---
he has the freedom to decide his
exact steps.

54
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.

55
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.
56
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.

57
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.

58
Life Cycle Model (CONT.)

 It becomes easier for software

project managers:
to monitor the progress of the
project.

59
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
depend on the guesses of the team 60
Life Cycle Model (CONT.)

 This usually leads to a problem:

known as the 99% complete
syndrome.

61
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
62
Summary

 Software engineering is:

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

63
Summary

 A fundamental necessity while

developing any large software
product:
adoption of a life cycle model.

64
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.

65
Reference

 R. Mall, “Fundamentals of Software

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

66
Activities
Group formation
 In the beginning of session, • Activities have
students will be divided into been identified in
groups (8 to 10 members)
every module.
Real world project prototypes
 Right after the group formation,
• Different focus
Students will be asked to areas have been
participate in prototype projects in identified as
different domains in real world.
applicable across
 After every module, they will be
preparing the relevant and all modules.
necessary
diagrams/documents/code/algorit
hm/test plan as required as part
of activity deliverables
 Focus areas have been identified
as
 Problem solving
 Critical thinking
Example of prototype from Real world domains identified as

No Systems to study Reference/Examples

1 Railway reservation system https://www.irctc.co.in

2 Online Banking system https://www.icicibank.com/
3 Online shopping sites www.amazon.in/Home
4 School website http://kiit-is.org/
5 University website http://kiit.ac.in/
6 Online Bill payment system https://www.odishaonline.gov.in/si
te/Common_Quick_Pay.aspx
7 Online hotel booking system https://www.trivago.in/
8 Online Grocery store sites www.bigbasket.com/

The basic process flow of these systems will be captured and understood.
 Module wise Activity - 1
Module 1 : Software Process Models

Focus Learnin List of Activities Mark Tangibl Mappi

Areas g s e ng CO
Practice Output
s
Problem 1. Identify criteria based on which 5 Assignm CO1
Solving Assignme a suitable life cycle model can be ent
nt chosen for s given software
development project. Illustrate
with diagrams.
2. What is a prototype? what are
the advantages ?
3. Explain the important features
of agile software model. Compare
the advantages and disadvantages
with iterative waterfall and
exploratory programming.
Total Marks = 10
 Module wise Activity - 2
Module 2 : Software Requirement Engineering

Focus Learning List of Activities Mark Tangible Mappi

Areas Practice s Output ng CO
s
Problem Group Refer the real world project, 5 Well CO2
Solving Report slide 10 documente
1. Study, analyse and prepare d SR
report on system requirements document.
of any one module of the real
world systems (mentioned in
slide 10).

Critical Assignme 1. What is traceability in SRS 5 Assignment CO2

thinking nts context ?how is traceability s
achieved in the above
mentioned modules? explain
with examples. Total Marks = 10
 Module wise Activity - 3
Module 3 : Software Project Management

Focus Learnin List of Activities Mark Tangible Mappi

Areas g s Output ng CO
Practice
s
Creation Group Refer the real world project, 5 1. CO3
Report slide 10 Schedule
1. Estimate size of the and
prototype selected. resource
2. Create schedule, cost plan sheet.
estimation and resource plan 2. Size
for a project prototype calculation
in report
form
Quiz Quiz Including modules 1, 2, 3. 5 Quiz CO3
Gate questions will be there on
these modules. Total Marks = 10
 Module wise Activity - 4
Module 4 : Structural Analysis & Design

Focus Learnin List of Activities Mark Tangible Mappi

Areas g s Output ng CO
Practice
s
Creation Group Refer the real world project, 5 Diagrams CO4
Report slide 10 in report
1. Create UML diagrams, DFD
1 from SRS

2. Algorithm / pseudo code for

one important module

Critical Assignme Create a guideline for design 5 Quiz CO4

thinking nt and its review from SRS
which should have check-list
for all possible errors. Total Marks = 10
 Module wise Activity - 5
Module 5 : Testing
Strategies
Focus Learnin List of Activities Mark Tangible Mappi
Areas g s Output ng CO
Practice
s
Creation Group Refer the real world project, 5 Diagrams CO5
Report slide 10 in report
1. Create test plan (unit,
integration, system, user
acceptance)
2. Create test scripts for one
module
Critical Assignme 1. Differentiate between black 2 Assignment CO5
thinking nt box testing and white box
+ testing. Give example of a bug
Problem which will be detected in white
solving box testing but not black box
testing, and vice versa.
Total
 Module wise Activity - 6
Module 6 : Software Reliability , Software Maintenance a

Focus Learnin List of Activities Mark Tangible Mappi

Areas g s Output ng CO
Practice
s
Assignme 1. Define three metrics to 5 Diagrams CO6
Problem nt measure software reliability. in report
solving Please justify your answers
if these metrics are
satisfactory enough.
2. What are the advantages of
client-server software?
Explain SOA and SaaS with
diagrams

Quiz Quiz Including modules 4, 5, 6. 5 Assignment CO6

Total
Gate questions will be there on Marks = 10