An Introduction to

Software Engineering
 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 = ?

This is an example of complexity for
Scheduling Fence Construction Tasks
 Small problems tolerate complacency—lack of
immediate penalty leads to inaction THE FROG IN BOILING WATER
 Negative feedback accumulates subtly and by
the time it becomes painful, the problem is too
big to address
 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
 Consequently, “design smells” accumulate,
“technical debt” grows, and the result is
“software rot”
WHAT IS A SOFTWARE?

Set of
instructions
WHERE DOES THE SOFTWARE RESIDES?
TYPES OF SOFTWARE

System Application
Software Software
Operate and control the Set of one or more programs
computer hardware and designed to carry out
provide a platform for operations for a specific
running application software. application.
SYSTEM SOFTWARE
System System
Management System Support Development
Programs Programs Programs

Programming
Operating Systems System Utilities Language
Translators

Operating Performance Programming

Environments Monitors Environments

Computer Aided
Database
Software
Management Security Monitors
Engineering (CASE)
Systems
Tools
APPLICATION SOFTWARE
General Purpose Specific Purpose
Application Programs Application Programs

Word Processing Accounting

Electronic Spread Marketing-Sales

Sheets Analysis

Manufacturing-
Graphics Software Production
Control
COMMON SOFTWARE TYPES
 Business Software

 Embedded Software Web-based

Software

 Artificial Intelligence
Software

 Scientific Software
SOFTWARE CRISIS
• It was in late 1960’s
• Many software projects failed.
• Many software projects late, over budget, providing unreliable software that is
expensive to maintain.
• Many software projects produced software which did not satisfy the
requirements of the customer.
• Complexities of software projects increased as hardware capability increased.
• Larger software system is more difficult and expensive to maintain.
• Demand of new software increased faster than ability to generate new software.

All the above attributes of what was called a ‘Software Crisis’. So the term
‘Software Engineering’ first introduced at a conference in late 1960’s to discuss the
software crisis.
WHY SOFTWARE ENGINEERING?
• Once the need for software engineering was identified and software
engineering recognized as a discipline.
• The late 1970’s saw the widespread evolution of software engineering
principles.
• The 1980’s saw the automation of software engineering and growth of CASE
(Computer Aided Software Engineering).
• The 1990’s have seen increased emphasis on the ‘management’ aspects of
projects and the use of standard quality and ‘process’ models like ISO 9001
and the Software Engineering Institute’s Software Capability Maturity Model
(CMM).

These models help organizations put their software

development and management processes in place
WHAT IS SOFTWARE ENGINEERING?
• In1969 Fritz Bauer defined software eng. as, ‘the establishment and use of sound
engineering principles in order to obtain, economically, software that is reliable and
works efficiently on real machines’.

• According to Boehm, software engineering involves, ‘the practical application of

scientific knowledge to the design and construction of computer programs and the
associated documentation required developing, operating and maintaining them’

• IEEE, in its standard 610.12-1990, 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.

• By combining all the above definition we can define software engineering as, ‘Software
engineering is the technological and managerial discipline concerned with systematic
production and maintenance of software products that are developed and modified on
time and within cost estimates.’
GOAL OF SOFTWARE ENGINEERING
The primary goals of software engineering are:
• To improve the quality of the software products.
• To increase the productivity
• To give job satisfaction to the software engineers.
FOUNDATION OF SOFTWARE ENGINEERING
Software engineering is a technological discipline distinct from, but based
on the foundation of the following disciplines:

• Computer Science
• Management Science
• Economics
• System Engineering
• Communication Skills
RELATIONSHIP OF SOFTWARE ENGINEERING
WITH OTHER DISCIPLINES
• Computer Science gives the scientific foundation to the software as electrical engineering
relies on physics.
• Management Science provides the foundation for software project management. Since
software engineering is labor intensive activity, it requires both technical and managerial
control.
• Economics provides the foundation for resource estimation and cost control. Since,
computing system must be developed and maintained on time and within cost estimates;
thus economics plays an important role.
• System Engineering is the field concerned with studying complex systems. Software is
often a component of a much larger system. For example, the software in a factory
monitoring system or the flight software on an airplane; is just the component of more
complex system. System engineering techniques can be applied to study of such systems
• Good oral, written and interpersonal communication skills are crucial for the software
engineers, because software engineering activities occur within an organizational context,
and a high degree of communication is required among customers, managers, software
engineers, hardware engineers and other technical workers.
THE ROLE OF SOFTWARE ENGINEER
The evolution of software engineering field has defined the role of the
software engineer. A software engineer should have the following qualities:

• Should be a good programmer, be well-versed in data structures and

algorithms, and be fluent in one or more programming languages.

• Should be familiar with several design approaches, be able to translate vague

requirements and desires into precise specifications and be able to converse
with the use of a system in terms of applications.

• Needs the ability to move among several levels of abstraction at different

stages of the project, from specific application procedures and requirements, to
abstraction for software systems, to a specific design for system and finally to
the detailed coding level.
THE ROLE OF SOFTWARE ENGINEER
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 ENGINEER
Customer:
Requires a computer system to achieve some b usiness goals
by user interaction or interaction w ith the problem domain
in a specif ied manner

System-to-be
(includes hardware)

Problem Domain
Software-to-be
User

Software Engineer’s task:

To understa nd how the system-to-be needs to interact w ith
the user or the problem domain so that customer’s requirement is met
and desi gn the sof tw are-to-be

May be the Programmer’s task:

same person To i mpl ement the sof tw are-to-be
designed by the sof tw are 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
EXAMPLE: ATM MACHINE
Understanding the money-machine problem:

1
7
4
0
2
5 3
8 6
9
Communication link

Bank’s
remote
ATM machine
datacenter
Bank
customer
HOW ATM MACHINE MIGHT WORK
Domain Model

Transaction
How may I record
help you? Cash

Bookkeeper
Speakerphone Safe
Safe keeper
Phone

Window clerk

Datacenter
liaison

Dispenser

Bank’s
remote
datacenter
Customer
PROBLEM-SOLVING STRATEGY
Divide-and-conquer:
 Identify logical parts of the system that each solves a part of the problem
 Easiest done with the help of a domain expert who already knows the steps in the
process (“how it is currently done”)
 Result:
A Model of the Problem Domain
(or “domain model”)
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
THE CHARACTERISTICS OF SOFTWARE ENGINEER
• Should be able to build and use a model of the application to guide choices
of the many trade- offs that he or she will face. The model is used to
answer questions about both the behavior of the system and its
performance.

• Needs communication skills and interpersonal skills. He also needs the

ability to schedule work both of his own and that of others.
WHAT IS WELL ENGINEERED SOFTWARE?
If the software system does what the user wants, and can be made to
continue to do what the user wants, it is well engineered.

• Any well engineered software system should have the following attributes:
• Be easy to maintain
• Be reliable
• Be efficient
• Provides an appropriate user interface

The development of software must make trade-offs between these attributes.

THE SOFTWARE PRODUCT
The objective of software engineering is to produce software products. Computer
software is the product that software engineers design and built. Software
products are software systems delivered to a customer with the
documentation which describes how to install and use the system.

• Software products fall into two broad classes:

• Generic products: These are stand alone systems which are produced by a
software development organizations/firms and sold on the open market to
any customer who is able to buy them.

• Customized products: These are systems which are commissioned by a

particular customer. The software is developed specially for that customer by
some developer.
SOFTWARE PRODUCT ATTRIBUTES
Product Description
characteristics
Maintainability It should be possible to evolve software to meet the changing
needs of the customer.

Dependability Software dependability includes a range of characteristics including

reliability, security and safety. Dependable software should not cause
physical or economic damage in the event of system failure.

Efficiency Software should not make wasteful use of system resources

such as memory and processor cycle

Usability Software should have an appropriate user interface and

documentation
SOFTWARE PROCESSES
AND MODELS
THE SOFTWARE PROCESSES
❑ A structured set of activities required to develop a software system.

❑ Many different software processes but all involve:

❑ Specification – defining what the system should do;
❑ Design and implementation – defining the organization of
the system and implementing the system;
❑ Validation – checking that it does what the customer wants;
❑ Evolution – changing the system in response to
changing customer needs.

❑ A software process model is an abstract representation of a process. It

presents a description of a process from some particular perspective.
 SOFTWARE PROCESS DESCRIPTIONS
• When we describe and discuss processes, we usually talk about the
activities in these processes such as specifying a data model,
designing a user interface, etc. and the ordering of these activities.
• Process descriptions may also include:
– Products, which are the outcomes of a process activity;
– Roles, which reflect the responsibilities of the people involved in the
process;
– Pre- and post-conditions, which are statements that are true before and
after a process activity has been enacted or a product produced.
SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)
• A life cycle model prescribes the different activities that need to be carried out
to develop a software product and sequencing of these activities.
• Also referred to as Systems Development Life cycle.
• Every software product starts with a request for the product by the customer
• The software life cycle can be considered as the forsoftware
business process development and
therefore is often referred to as a Software process. (SLCM).
• Process models – More detailed and precise life cycle activities.
• Different stages in a life cycle model: After Product conception. The
stages are: (Life cycle phase)
➢ Feasibility study stage
➢ Requirements analysis and specification.
➢ Design
➢ Coding
➢ Testing and
➢ Maintenance
• A SDLC is a series of identifiable stages that a software product undergoes
during its lifetime.
• A SDLC is a descriptive and diagrammatic representation of the software life
cycle.
• A life cycle model maps the different activities performed on a software product
from its beginning to retirement into a set of life cycle phases.
1. THE CLASSICAL WATERFALL MODEL
BASIC LIFE CYCLE MODEL- THEORETICAL WAY OF DEVELOPING
SOFTWARE
CLASSICAL WATERFALL MODEL PHASES

• There are separate identified phases in the waterfall model:

– Requirements analysis and definition
– System and software design
– Implementation and unit testing
– Integration and system testing
– Operation and maintenance
• The main drawback of the waterfall model is the difficulty of
accommodating change after the process is underway. In principle, a
phase has to be complete before moving onto the next phase.
CLASSICAL WATERFALL MODEL PROBLEMS

• Inflexible partitioning of the project into distinct stages makes it difficult to

respond to changing customer requirements.

– Therefore, this model is only appropriate when the requirements are well-
understood and changes will be fairly limited during the design process.
– Few business systems have stable requirements.

• The waterfall model is mostly used for large systems engineering projects
where a system is developed at several sites.
– In those circumstances, the plan-driven nature of the waterfall model helps
coordinate the work.
 2. Structured Evolutionary Prototyping Model
• Developers build a prototype during the requirements
phase.
• Prototype is evaluated by end users.
• Users give corrective feedback.
• Developers further refine the prototype.
• When the user is satisfied, the prototype code is brought up to the standards
needed for a final product.
STRUCTURED EVOLUTIONARY PROTOTYPING STEPS

• A preliminary project plan is developed.

• An partial high-level paper model is created.
• The model is source for a partial requirements specification.
• A prototype is built with basic and critical attributes
• The designer builds
– the database
– user interface
– algorithmic functions
• The designer demonstrates the prototype, the user evaluates for
problems and suggests improvements.
• This loop continues until the user is satisfied.
3. SPIRAL MODEL
• Spiral with many loops.
• Each loop of the spiral is called the phase of a software
process.

• Over each loop, one or more features of the product are

elaborated and analysed and risks at that point of time are
identified and resolved through prototyping. Based on this, the
identified features are implemented.
4 QUADRANTS OF SPIRAL MODEL
• 1st Quadrant:
– The objectives are investigated, elaborated and analysed.
– Risks are also identified.
– Alternative Solutions are proposed
• 2nd Quadrant:
• Alternative solutions are evaluated to select best.
• 3rd Quadrant:
• Developing and verifying the next level of the product
• 4th Quadrant:
• Reviewing the results of the stages traversed so far with the customer.
• Planning the next iteration around the spiral.

:
4. EVOLUTIONARY MODEL
• Successive versions model.
• Incremental model.
• A simple working system is built, which
subsequently undergoes many functionality improvements and
additions until the desired system is realized .
• Also sometimes referred to as design a little, build a little, test a
little, deploy a little model.
• That is once the requirements have been specified, the design,
build, test and deployment activities are interleaved.
• The software requirements is first broken down into several modules(functional
units) that can be incrementally constructed and delivered.
• The development team first develop the core modules of the system.
• The Core modules are those that don’t need services from the other modules.
• The initial product Skelton is refined into increasing levels of capability by adding
new functionalities in the successive versions.
LIFE CYCLE ACTIVITIES
ITERATIVE MODEL
• A Requirements phase, in which the requirements for the software are gathered
and analysed. Iteration should eventually result in a requirements phase that
produces a complete and final specification of requirements.

• A Design phase, in which a software solution to meet the requirements is

designed. This may be a new design, or an extension of an earlier design.

• An Implementation and Test phase, when the software is coded, integrated

and tested.

• A Review phase, in which the software is evaluated, the current requirements

are reviewed, and changes and additions to requirements proposed.
ITERATIVE WATERFALL MODEL
• The iterative waterfall model is classical waterfall model with necessary
changes so that it becomes applicable to practical software development
projects.
• The main change to the classical waterfall model is in the form of providing
feedback paths from every phase to its preceding phase.
• The feedback paths allows for correction of errors
committed during a phase, as and when these are detected in a later phase.
• The principle of detecting errors as close to their points of introduction as
possible is known as phase containment of errors.
COMPARISON OF LIFE-CYCLE MODELS
• Different life-cycle models have been presented
– Each with its own strengths and weaknesses

• Criteria for deciding on a model include:

– The organization
– Its management
– The skills of the employees
– The nature of the product

• Best suggestion
– “Mix-and-match” life-cycle model