Introductio

n
we are surrounded by systems. There are
many systems such as transportation system,
education , manufacturing and human economic
activity systems.
System: “A system is an orderly
grouping of independent components
linked together according to a plan to
achieve a specific objective or goal”
Syste
m
⚫A system is a set or group of
components that interact to
accomplish some purpose.
⚫ System interacts with their
environment.
⚫ E.g brain , spinal cord, nerves etc.
 System
consist of
⚫ Standards: which
acceptable
performance.
⚫ Measurement: Measuring
actual performance.
⚫ Compare: Comparing
actual performance.
⚫ Feedback: A method for
feedback.
Elements of
system
⚫ Input and O utput
⚫ Processors
⚫ Control
⚫ Feedback
⚫ Environment
⚫ Boundaries and
Interface
 1. Input and
O utput
⚫A major objective of a system
is to produce the output as
per the user’s requirement.
⚫ The output could be in the form
of goods information as services.
It must be done with
expectations of user.
⚫ Inputs are elements that enter
the system for processing.
⚫ O utput is outcome of processing.
Process
ors:
⚫ The processor is the element of a
system that involves the actual
transformation of Input into output.
⚫ Processor should be designed of
such type that it can accept the
input in the given form and can
give output in desired format.
Control
:
⚫ The control elements guide the
system. The control element
controls the working of the
system at all stages.
⚫ It is necessary to control input,
process and output,
continuously, in order to get
desired results.
⚫ Management support is
required for screening control
Feedba
ck
⚫ Feedback measures output
against a standard in some form
of cybernetic procedure includes
communication and control.
⚫ Feedback may be positive or
negative. Positive feedback
reinforces the performance of
system.
 5.
Environmen
⚫ All thetthings which are outside
system are called environment
of the system.
⚫ The environment does affect
working or progress of the
system.
 Boundaries and
Interface:
⚫ The boundary indicates the
extent or limit of the system.
⚫ The boundary divides the things
into the system and its
environment.
⚫ The things which are inside
boundary are part of system
otherwise which are outside
boundary are its environment.
Interfa
ce:
⚫ Itmeans interaction of different
system parts with each other
as interaction of the system
with system outside its
boundaries.
⚫ Boundaries
⚫
are the limits that identify its
components, process and
interrelationships when it
interfaces with another system.
 Characteristics of a
system
Following are the some
important characteristics
of a system:
1. Organization
2. Interaction,
3. Interdependence,
4. Integration
5. Central objective
Organizati
on
⚫ Basically, O rganization means the
arrangement of components that
helps to achieve objectives.
⚫ Example in college system , the
hierarchical relationship starting
with the chairman on top and
leading downward to peon,
represent the organization
structure.
 Principal

HOD HOD HOD

(CompDept) (Physics ) (Chemistr
y)

Lecturer Lecturer Lecturer

Student Student Student

s s s
Interactio
n:
⚫ Interaction refers to the manner
in which each component
interacts with other components
of the system.
⚫ E.g. In a computer system all
component are interact with
other
Interdependen
ce:
⚫ Interdependence means parts
of organization depend on
one another.
⚫ They are coordinated and linked
together according to plan.
⚫ In computer system, the three
units Input, system unit, O utput
is interdependent for proper
functioning.
Integrati
on:
⚫ Integration is concerned with
how a system is tied
together in order to achieve
common goal, thus forming
integration.
⚫ It means that parts of system
work together within system
even though each part performs
unique function.
 Central
Objective:
⚫ Objectives may be stated or real.
⚫ The stated objective and real
objective of the system could differ
based on the policy of the
company.
⚫ The user should develop a central
objective by taking into consideration
real objective and stated objective .
⚫ The important point is that the
users must know the central
objective of computer application
in analysis for successful design and
conversion .
 Types of
systems:
Physical System
⚫ The physical system could be static or
dynamic in nature.
⚫ Static means which do not change as far
as working or life of the system is
concerned.
on other hand dynamic system may change due
to processing of system.
Examp
le
⚫ In
computer system the
hardware parts are static but the
data which changes due to
processing is dynamic. These both
together form physical system.
 2. Abstract
system:
⚫ The system which are
represented
conceptually(Non Existing)
⚫ It is prepared by studying the
physical system.
⚫ The computer is a physical
system and its block diagram is
called as abstract system A
model representation of real or
planned system.
 System
Model
⚫ The use of model makes it easier
for analyst to visualize
relationship in system study.
System Model
The analyst begins by creating a
model of reality i.e fact,
relationship, procedure… etc with
which the system is concerned.
Every computer system deal with
real world
Various system model are used
to show benefits of abstracting
systems to model form. The
major of this type models are:

Schematic models: It shows

a two dimensional system
elements and their linkages.

Flow system models: It shows

the flow of material , energy and
information that hold system
together. A widely used
Static system models: This type of
model exhibits are pair of relationship
such as activity time or cost quantity.
E.g. Gantt Chart

Dynamic system models:

Business organizations are dynamic
systems. It depicts constantly an
ongoing constantly changing the
system. It consists of:

1. Inputs that enter the system.

2. Processor through which
transformation takes place.
3. The programs required for
 3. Open and closed system:
a. Open system:

• Another classification of systems is based on

their
degree of independence.
• An open system is a one which does not
provide for its own control or modification. It
does not supervise itself so it needs to be
supervised by people.
• For example: If the high speed printer used
with computer systems did not have a
switch to sense whether paper is In the
printer, then a person would have to
notice when the paper runs out and
 Signal the system to stop
printing.
Characteristics of Open
system

Inputs from outside: O pen

system are self adjusting and self
regulating. When functioning properly an
open system reaches a steady state.

Entropy: All dynamic system tends to

run down over time resulting in entropy or
loss of energy.
O pen system resist entropy by seeking
new inputs or modifying the processes to
return to a steady state.
 Characteristics of Open system

3. Process, Output and cycle:

Open systems produce useful output
and operate in cycle.

B. Closed system:
A closed system in one which automatically
controls or modifies its own operation by
responding to data generated by the system
itself

For example: High speed printers used with

computer systems usually have a switch that
senses whether there is paper in the printer. If
the paper runs out, the switch signals to stop
4. M anmade system:

• With the help of information

system, we can define some standard
for the working of the system. This
we can try to make the system to
work according to the standards
defined.
• W e can define information system as
a set of devices, procedures, rules
but most of the work performs
manually.
• It provides instructions,
commands and feedback. It
determines nature of
 5. Formal Information system:
• A formal information system is
represented by organization chart. It
gives a representation of the different
parts of system and flow of information
among them.
• Categories of information

• 1. Strategic information: It relates to

long range planning in system.
• 2. Management
• Strategic Information
• Managerial Information
• Operational Information

• The first level relates to long range planning

policies that are of direct interest to upper
management
• The second level is of direct use of middle
management and department heads for
implementation and control.
• The Third level is short term, daily
information is used to operate department and
enforce day- to-day rules and regulations of
information
6. Informal Information system:
 The informal information system is employee
based system design to meet personnel and
vocational needs and to help in the solution of
work-related it is considered to be a useful
system because it works within the framework
of the business and its stated policies.
 It is related with what is happening practically
rather than what is shown on paper, it is an
employee based system designed to meet
personal and vocational needs and help work
related problem.
7. Computer Based Information
System:
 Computer based information is more
accurate, more neat and attractive it is
possible to perform different
operations easily. Security of data
is possible in this system.
8. Management Information System (MIS)
A management information system (MIS) is
a computer system consisting of hardware
and software that serves as the backbone of
an
organization’s operations. An MIS gathers data from
multiple online systems, analyzes the information,
and reports data to aid in management decision-
making.
Advantages:

 Processing time and number of programs

written are reduced.

 All applications share centralized files.

 Storage space duplication is eliminated.

• Data are stored once in database and are

easily accessible when needed
9. Decision Support system (DSS)


A decision support system (DSS) is a computerized
system that gathers and analyzes data, synthesizing it
to produce comprehensive information reports.

A decision support system differs from an ordinary
operations application, whose function is just to collect
data.

Decision support systems allow for more informed
decision-making, timely problem-solving, and
improved efficiency in dealing with issues or
operations, planning, and even management

The primary purpose of using a DSS is to
present information to the customer in an easy-
to-understand way. A DSS system is beneficial
because it can be programmed to generate many
types of reports, all based on user
specifications. For example, the DSS can
generate information and output its information
graphically, as in a bar chart that represents
projected revenue or as a written report.
10. Expert System(ES)
Expert Systems
 Artificial Intelligence is a piece of software that simulates
the behavior and judgment of a human or an organization
that has experts in a particular domain is known as an
expert system. It does by acquiring relevant knowledge
from its knowledge base and interpreting it according to
the user’s problem. The data in the knowledge base is
added by humans that are expert in a particular domain
and this software is used by a non-expert user to acquire
some information. It is widely used in many areas such as
medical diagnosis, accounting, coding, games etc.
• An expert system is an AI software that
uses knowledge stored in a knowledge base
to solve problems that would usually
require a human expert thus preserving a
human
expert’s knowledge in its knowledge base.
They can advise users as well as provide
explanations to them about how they
reached a particular conclusion or advice.
• One expert system may contain knowledge
from more than one human experts thus
making the solutions more efficient.
Limitations:
• Don’t have human-like decision
making power.
• Can’t possess human capabilities.
• Can’t produce correct result from less
amount of knowledge.
• Requires excessive training.

Advantages:
• Low accessibility cost.
• Fast response.
• Not affected by emotions unlike
humans.
• Low error rate.
• Capable of explaining how they
reached a solution.
Executive information system (EIS)

An executive information system (EIS) is a decision

support system (DSS) used to assist senior executives in
the decision-making process. It does this by providing
easy access to important data needed to achieve
strategic goals in an organization. An EIS normally
features graphical displays on an easy-to-use interface.

Executive information systems can be used in many

different types of organizations to monitor enterprise
performance as well as to identify opportunities and
problems.
Advantages of EIS
[Link] is easy for upper level
executives.
[Link] provides timely
delivery of company summary
information.
[Link] filters data for
management.
 Integrated system:

• Integrated systems, or systems integration, is the

process of bringing together component sub-systems
into one functional system. It provides a system
with coherence by making the parts or components
work together, or ‘building or creating a whole from
parts

• It consists of individual computers may be

workstations or multiple systems.
• Each of them runs a set of standard
software and deals initially with it’s own
application.
• It is a different approach, sometimes
called the integrated model and
provides truly distributed system by
designing it from scratch. In this
integrated model and provides truly.
Sub System:

• A Larger system divided into subparts

that subparts is known as subsystem.
• For example:
• Microprocessor of a motherboard. Where
Motherboard is system and microprocessor
is subsystem.
Transaction processing system(TPS)
• A Transaction processing system is a type of
information system. TPS collect, store,
modify and retrieve the transactions of an
organization. A transaction is an event that
generates or modifies data that is eventually
stored in an information system.
• It works on transaction in database system. This
system is useful in online shopping, online
booking.
Unit 2 Introduction to
Software Engineering
 Definition of
Software
⚫ Software is defined as
collection of computer
programs, procedures, rules
and data. Software
Characteristics are classified
into six major components:
 Definition of Software
Engineering
⚫ Softwareis more than just a program
code. A program is an executable
code, which serves some
computational purpose. Software is
considered to be 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
 Definition of Software
Engineering
⚫ Software engineering is an
engineering branch associated
with development of software
product using well-defined
scientific principles, methods
and [Link] outcome
of software engineering is an
efficient and reliable software
product.
 SOFTWARE
C H ARACTERISTICS
⚫ Software is developed: It is not
manufactured. It is not something
that will automatically roll out of an
assembly line. It ultimately depend
on individual skill and creative
ability
⚫ Software does not W ear Out :
Software is not susceptible to the
environmental melodies and it does
not suffer from any effects with
time
⚫
⚫ Most
Software is C reated and
Not Assembled from Existing
⚫ Several models of software quality
factors and their categorization have
been suggested over the [Link]
classic model of software quality
factors, suggested by McCall, consists
of 11 factors (McCall et al., 1977).
Similarly, models consisting of 12 to
15 factors, were suggested by
Deutsch and Willis (1988) and by
Evans and Marciniak (1987).

⚫ All
these models do not differ
substantially
from McCall’s [Link] McCall
factor model provides a practical, up-
to-date method for classifying
 McCall’s Factor
Model
⚫ Thismodel classifies all software
requirements into 11 software quality
factors. The 11 factors are grouped into
three categories – product operation,
product revision, and product transition
factors.

⚫ Product operation factors − Correctness,

Reliability, Efficiency, Integrity, Usability.

⚫ Product revision factors − Maintainability,

Flexibility, Testability.

⚫ Product transition factors − Portability,

Reusability, Interoperability.
 Product Operation
Software Quality
Factors
⚫ According to McCall’s model,
product operation category
includes five software quality
factors, which deal with the
requirements that directly affect the
daily operation of the
[Link] are as follows −
 Correctn
⚫ ess deal with the correctness of the output of the software
These requirements
system. They include −

⚫ Output mission

⚫ The required accuracy of output that can be negatively affected by

inaccurate data or inaccurate calculations.

⚫ The completeness of the output information, which can be affected by

incomplete data.

⚫ The up-to-dateness of the information defined as the time between the event
and the response by the software system.

⚫ The availability of the information.

Reliabil
ity
⚫ Reliabilit requirements deal
y
service failure. They with
maximum allowed failure ratethe
determine of
the software system, and can
refer to the entire system or to
one or more of its separate
functions.
Efficien
cy
⚫ Itdeals with the hardware resources
needed to perform the different functions
of the software system. It includes
processing capabilities (given in MHz), its
storage capacity (given in MB or GB)
and the data communication capability
(given in MBPS or GBPS).

⚫ Italso deals with the time between

recharging of the system’s portable units,
such as, information system units located
in portable computers, or
meteorological units placed outdoors.
Integri
ty
⚫ This factor deals with the
software system security, that
is, to prevent access to
unauthorized persons, also to
distinguish between the group of
people to be given read as well
as write permit.
Usabil
ity
⚫ Usabilityrequirements deal with
the staff resources needed to
train a new employee and to
operate the software system.
 Product Revision Quality
Factors
⚫ According to McCall’s model, three
software quality factors are included
in the product revision
[Link] factors are as
follows −

⚫ Maintainability
⚫ This factor considersthe efforts that
will be needed by users and
maintenance personnel to identify
the reasons for software failures, to
correct the failures, and to verify the
success of the corrections.
Flexibili
ty
⚫ This factor deals with the capabilities and
efforts required to support adaptive
maintenance activities of the [Link]
include adapting the current software to
additional circumstances and customers
without changing the [Link] factor’s
requirements also support perfective
maintenance activities, such as changes and
additions to the software in order to
improve its service and to adapt it to
• changes in the firm’s technical or commercial
• environment.
Testabili
ty
⚫ Testabilityrequirements deal with the
testing of the software system as well as
with its operation. It includes predefined
intermediate results, log files, and also
the automatic diagnostics performed by
the software system prior to starting the
system, to find out whether all
components of the system are in
working order and to obtain a report
about the detected faults. Another type
of these requirements deals with
automatic diagnostic checks applied by
the maintenance technicians to detect
the causes of software failures.
 Product Transition
Software Quality Factor
⚫ According to McCall’s model, three
software quality factors are
included in the product transition
category that deals with the
adaptation of software to other
environments and its interaction
with other software systems. These
factors are as follows −
Portabili
ty
⚫ Portability
requirements tend to the
adaptation of a software system
to other environments consisting
of different hardware, different
operating systems, and so
[Link] software should be
possible to continue using the
same basic software in diverse
situations.
Reusab
ility
⚫ Thisfactor deals with the use of
software modules originally
designed for one project in a new
software project currently being
[Link] may also enable
future projects to make use of a
given module or a group of modules
of the currently developed
[Link] reuse of software is
expected to save development
resources, shorten the development
Interoperab
ility
⚫ Interoperability
requirements
focus on creating interfaces with
other software systems or with
other equipment firmware. For
example, the firmware of the
production machinery and testing
equipment interfaces with the
production control software.
 Software
Processes
⚫ The term software specifies to the set of
computer programs, procedures and
associated documents (Flowcharts,
manuals, etc.) that describe the program
and how they are to be used.
⚫ A software process is the set of activities
and associated outcome that produce a
software product. Software engineers
mostly carry out these activities. These are
four key process activities, which are
common to all software processes. These
activities are:
1.: The software must evolve to meet
changing client needs.
 Software
Processes
[Link] specifications: The
functionality of the software and
constraints on its operation must
be defined.
[Link] development: The
software to meet the
requirement must be produced.
[Link] validation: The
software must be validated
to ensure that it does what
the customer wants.
4. Software evolution
 The Software
Process Model
⚫A software process model is a
specified definition of a software
process, which is presented from
a particular perspective. Models,
by their nature, are a
simplification, so a software
process model is an abstraction
of the actual process, which is
being described. :
 The Software Process
Model
⚫ Process models may contain
activities, which are part of the
software process, software
product, and the roles of people
involved in software engineering.
Some examples of the types of
software process models that
may be produced are
⚫ 1.A workflow model:This shows
the series of activities in the
process along with their inputs,
outputs and [Link]
activities in this model perform
human actions.
⚫ 2.A dataflow or activity model:This
represents the process as a set of
activities, each of which carries out
some data transformations. It shows
how the input to the process, such
as a specification is converted to an
output such as a [Link]
activities here may be at a lower
level than activities in a workflow
[Link] may perform
transformations carried out by
⚫ 3.A role/action model:This
means the roles of the people
involved in the software
process and the activities for
which they are responsible
Software Engineering |
SDLC V- Model
⚫ V-Model
⚫ V-Model also referred to as the
Verification and Validation Model.
In this, each phase of SDLC
must complete before the next
phase starts. It follows a
sequential design process same
as the waterfall [Link] of
the device is planned in parallel
with a corresponding stage of
development.
⚫ There are the various phases of
Verification Phase of V-model:

⚫ Business requirement analysis:This is the

first step where product requirements
understood from the customer's
[Link] phase contains detailed
communication to understand
customer's expectations and exact
requirements.
⚫ System Design: In this stage system
engineers analyze and interpret the
business of the proposed system by
studying the user requirements
⚫ ArchitectureDesign:The baseline in
selecting the architecture is that it
should understand all which
typically consists of the list of
modules, brief functionality of
each module, their interface
relationships, dependencies,
database tables, architecture
diagrams, technology detail,
[Link] integration testing model
is carried out in a particular
⚫ Module Design: In the module
design phase, the system breaks
down into small [Link]
detailed design of the modules is
specified, which is known as Low-
Level Design
⚫ Coding Phase: After designing, the
coding phase is started. Based on
the requirements, a suitable
programming language is decided.
There are some guidelines and
standards for coding. Before
checking in the repository, the
final build is optimized for better
performance, and the code goes
through many code reviews to
check the performance.
There are the various
phases of Validation
Phase
⚫ Unit ofInV-model:
Testing: the V-Model, Unit
Test Plans (UTPs) are developed
during the module design
[Link] UTPs are executed to
eliminate errors at code level or
unit level. A unit is the smallest
entity which can independently
exist, e.g., a program module.
Unit testing verifies that the
smallest entity can function
correctly when isolated from the
rest of the codes/ units
 Integration
Testing
⚫ IntegrationTesting: Integration
Test Plans are developed during
the Architectural Design
[Link] tests verify that
groups created and tested
independently can coexist and
communicate among themselves.
 System
Testing:
⚫ System Testing: System Tests
Plans are developed during
System D esign Phase. Unlike
Unit and Integration Test Plans,
System Tests Plans are
composed by the client?s
business team. System Test
ensures that expectations from
an application developer are
met.
 Acceptance
Testing:
⚫ Acceptance Testing: Acceptance testing
is related to the business
requirement analysis part. It includes
testing the software product in user
atmosphere. Acceptance tests reveal
the compatibility problems with the
different systems, which is available
within the user atmosphere. It
conjointly discovers the non-
functional problems like load and
performance defects within the real
When to use V-
Model?
⚫ When the requirement is well
defined and not ambiguous.
⚫ The V-shaped model should be
used for small to medium-sized
projects where requirements are
clearly defined and fixed.
⚫ The V-shaped model should be
chosen when sample technical
resources are available with
essential technical expertise.
Advantage (Pros) of
V-Model:
⚫ Easy to Understand.
⚫ Testing Methods like planning,
test designing happens well
before coding.
⚫ This saves a lot of time. Hence
a higher chance of success over
the waterfall model.
⚫ Avoids the downward flow of
the defects.
⚫ W orks well for small plans
Disadvantage (Cons) of
V-Model:
⚫ Very rigid and least flexible.
⚫ Not a good for a complex project.
⚫ Software is developed during the
implementation stage, so no
early prototypes of the software
are produced.
⚫ If any changes happen in the
midway, then the test documents
along with the required
documents, has to be updated
 UNIT 3:SOFTWARE
DEVELOPMENT LIFE
CYCLE
 1
Introduction
⚫ Software Development Life Cycle
(SDLC) is a process used by the
software industry to design,
develop and test high quality
softwares. The SDLC aims to
produce a high-quality software
that meets or exceeds customer
expectations, reaches completion
within times and cost estimates.
• SDLC the acronym of
is Software
Development Life
• Cycle.
Itis also as
called Software
Development
Process.
• SDLC is a framework defining tasks
performed at each step in the
software development process.
• ISO/IEC 12207 is an
standard for
international software life-
cycle
processes It to be standar
.
that aims
defines thetasks requiredd
all the
for developing and maintaining
software
 What is
SDLC?
⚫ SDLC is a process followed for a
software project, within a
software organization. It consists
of a detailed plan describing how
to develop, maintain, replace and
alter or enhance specific
[Link] life cycle defines a
methodology for improving the
quality of software and the overall
development process.
 Stage 1: Planning and
Requirement Analysis
⚫ Requirement analysis is the most
important and fundamental stage
in SDLC . It is performed by the
senior members of the team with
inputs from the customer, the sales
department, market surveys and
domain experts in the [Link]
information is then used to plan
the basic project approach and to
conduct product feasibility study in
the economical, operational and
 Stage 1: Planning and
Requirement Analysis
⚫ Planning for the quality
assurance requirements and
identification of the risks
associated with the project is also
done in the planning [Link]
outcome of the technical
feasibility study is to define the
various technical approaches
that can be followed to
implement the project
successfully with minimum risks.
 Stage 2: Defining
Requirements
⚫ O nce the requirement analysis is
done the next step is to clearly
define and document the product
requirements and get them
approved from the customer or
the market [Link] is done
through an SRS (Software
Requirement Specification)
document which consists of all the
product requirements to be
designed and developed during the
project life cycle.
 Stage 3: Designing
the Product
Architecture
⚫ SRS is the reference for product
architects to come out with the
best architecture for the product
to be developed. Based on the
requirements specified in SRS,
usually more than one design
approach for the product
architecture is proposed and
documented in a DDS - Design
Document Specification.
 Stage 4: Building or
Developing the Product
⚫ Inthis stage of SDLC the actual
development starts and the
product is [Link] programming
code is generated as per D DS
during this stage. If the design is
performed in a detailed and
organized manner, code
generation can be accomplished
without much hassle.
 Stage 4: Building or
Developing the Product
⚫ Developers must follow the
coding guidelines defined by their
organization and programming
tools like compilers, interpreters,
debuggers, etc. are used to
generate the code. Different high
level programming languages
such as C , C++, Pascal, Java and
PHP are used for coding. The
programming language is chosen
with respect to the type of
software being developed
Stage 5:Testing the
Product
⚫ Thisstage is usually a subset of all
the stages as in the modern SDLC
models, the testing activities are
mostly involved in all the stages
of SDLC. However, this stage
refers to the testing only stage of
the product where product
defects are reported, tracked, fixed
and retested, until the product
reaches the quality standards
defined in the SRS.
 Stage 6: Deployment in
the Market and
Maintenance
⚫ O nce the product is tested and
ready to be deployed it is
released formally in the
appropriate market. Sometimes
product deployment happens in
stages as per the business
strategy of that [Link]
product may first be released in a
limited segment and tested in the
real business environment (UAT-
User acceptance testing).
Stage 6: Deployment in
the Market and
Maintenance
⚫ Then based on the feedback, the
product may be released as it is
or with suggested enhancements
in the targeting market segment.
After the product is released in
the market, its maintenance is
done for the existing customer
base.
 SDLC
Models
⚫ There are various software
development life cycle models
defined and designed which are
followed during the software
development [Link]
models are also referred as
Software D evelopment Process
Models". Each process model
follows a Series of steps unique to
its type to ensure success in the
process of software development.
⚫ Following are the most
important and popular SDLC
models followed in the
industry −
⚫ W aterfall Model
⚫ Iterative Model
⚫ Spiral Model
⚫ V-Model
⚫ Big Bang Model
⚫ Other related methodologies
are Agile Model, RAD Model,
Rapid Application
Development and Prototyping
W aterfall Model -
Design
⚫ Waterfallapproach was first SDLC
Model to be used widely in
Software Engineering to ensure
success of the project. In "The
W aterfall" approach, the whole
process of software development
is divided into separate phases. In
this Waterfall model, typically, the
outcome of one phase acts as the
input for the next phase
sequentially.
⚫ The following illustration is a
representation of the different
phases of the W aterfall Model.

⚫ SDLC W aterfall Model

⚫ Thesequential phases in
W aterfall model are −

⚫ Requirement Gathering and

analysis − All possible
requirements of the system to be
developed are captured in this
phase and documented in a
requirement specification
document.
 System
Design
⚫ System Design − The
requirement specifications from
first phase are studied in this
phase and the system design is
[Link] system design
helps in specifying hardware and
system requirements and helps in
defining the overall system
architecture.
Implementation
⚫ Im plementation − With inputs
from the system design, the
system is first developed in small
programs called units, which are
integrated in the next phase.
Each unit is developed and tested
for its functionality, which is
referred to as Unit Testing.
 Integration and Testing
⚫ Integration and Testing − All
the units developed in the
implementation phase are
integrated into a system after
testing of each unit. Post
integration the entire system is
tested for any faults and failures.
 Deployment of system
⚫ Deployment of system −
Once the functional and non-
functional testing is done; the
product is deployed in the
customer environment or
released into the market.
Maintenance
⚫ Maintenance − There are some
issues which come up in the
client environment. To fix those
issues, patches are released. Also
to enhance the product some
better versions are released.
Maintenance is done to deliver
these changes in the customer
environment.
⚫ Allthese phases are cascaded to
each other in which progress is
seen as flowing steadily
downwards (like a waterfall)
through the [Link] next
phase is started only after the
defined set of goals are achieved
for previous phase and it is signed
off, so the name "W aterfall Model".
In this model, phases do not
overlap.
 W aterfall Model -
Application
⚫ Every software developed is different
and requires a suitable SDLC
approach to be followed based on
the internal and external factors.
Some situations where the use of
W aterfall model is most
appropriate are −

⚫ Requirements
are very well
documented, clear and fixed.

⚫ Product definition is stable.

⚫ Technologyis understood and
is not dynamic.

⚫ Thereare no ambiguous
requirements.

⚫ Ample resources with required

expertise are available to support
the product.

⚫ The project is short.

 W aterfall Model -
Advantages
⚫ Simple and easy to understand and
use

⚫ Easy to manage due to the rigidity

of the model. Each phase has
specific deliverables and a review
process.

⚫ Phasesare processed and

completed one at a time.

⚫ Workswell for smaller projects

where requirements are very
 W aterfall Model -
Advantages
⚫ Clearly defined stages.

⚫ Well understood milestones.

⚫ Easy to arrange tasks.

⚫ Process
and results are well
documented.
 W aterfall Model -
Disadvantages
⚫ No working software is produced
until late during the life cycle.
⚫ High amounts of risk and uncertainty.
⚫ Not a good model for complex and
object- oriented projects.
⚫ Poor model for long and ongoing
projects.
⚫ Not suitable for the projects where
requirements are at a moderate to
high risk of changing. So, risk and
uncertainty is high with this
process model.
 W aterfall Model -
Disadvantages
⚫ Itis difficult to measure
progress within stages.
⚫ Cannot accommodate
changing requirements.
⚫ Adjusting scope during the life
cycle can end a project.
⚫ Integration is done as a "big-
bang. at the very end, which
doesn't allow identifying any
technological or business
bottleneck or challenges early.
Iterative Model -
Design
⚫ Iterativeprocess starts with a
simple implementation of a subset
of the software requirements and
iteratively enhances the evolving
versions until the full system is
implemented. At each iteration, design
modifications are made and new
functional capabilities are [Link]
basic idea behind this method is to
develop a system through repeated
cycles (iterative) and in smaller
⚫ Iterativeand Incremental
development is a combination of
both iterative design or iterative
method and incremental build
model for development. "During
software development, more than
one iteration of the software
development cycle may be in
progress at the same time." This
process may be described as an
"evolutionary acquisition" or
"incremental build" approach."
⚫ Inthis incremental model, the
whole requirement is divided into
various builds. During each
iteration, the development module
goes through the requirements,
design, implementation and
testing phases. Each subsequent
release of the module adds
function to the previous
[Link] process continues till
the complete system is ready as
⚫ The key to a successful use of an
iterative software development
lifecycle is rigorous validation of
requirements, and verification &
testing of each version of the
software against those
requirements within each cycle of
the model. As the software evolves
through successive cycles, tests
must be repeated and extended
to verify each version of the
software.
 Iterative Model -
Application
⚫ Likeother SDLC models, Iterative
and incremental development has
some specific applications in the
software [Link] model is
most often used in the following
scenarios −

⚫ Requirements of the complete

system are clearly defined and
understood.

⚫ Major requirements must be

defined; however, some
 Iterative Model -
Application
⚫ There is a time to the market constraint.

⚫A new technology is being used and is

being learnt by the development team
while working on the project.

⚫ Resources with needed skill sets are not

available and are planned to be used on
contract basis for specific iterations.

⚫ There are some high-risk features

and goals which may change in the
future.
Iterative Model
- Pros
⚫ Some working functionality
can be developed quickly and
early in the life cycle.
⚫ Results are obtained
early and periodically.
⚫ Parallel development can
be planned.
⚫ Progress can be
measured.
⚫ Less costly to
 disadvantages of the
Iterative and
Incremental SDLC
⚫ More resources may be required.
Model
⚫ Although cost of change is lesser,
but it is not very suitable for
changing requirements.
⚫ More management attention is
required.
⚫ System architecture or design issues
may arise because not all requirements
are gathered in the beginning of the
entire life cycle.
⚫ Defining increments may require definition
of the complete system.
⚫ Not suitable for smaller projects.
Spiral Model -
Design
⚫ The spiral model combines the idea
of iterative development with the
systematic, controlled aspects of
the waterfall model. This Spiral
model is a combination of iterative
development process model and
sequential linear development
model i.e. the waterfall model with
a very high emphasis on risk
analysis. It allows incremental
releases of the product or incremental
refinement through each iteration
around the spiral.
 Spiral Model -
Design
⚫ SpiralModel - Design
⚫ The spiral model has four
phases. A software project
repeatedly passes through these
phases in iterations called Spirals.
Identificat
ion
⚫ Thisphase starts with gathering
the business requirements in the
baseline spiral. In the subsequent
spirals as the product matures,
identification of system
requirements, subsystem
requirements and unit
requirements are all done in this
phase.
Identificati
on
⚫ Thisphase also includes
understanding the system
requirements by continuous
communication between the
customer and the system
analyst. At the end of the spiral,
the product is deployed in the
identified market.
Desi
gn
⚫ The D esign phase starts with the
conceptual design in the baseline
spiral and involves architectural
design, logical design of modules,
physical product design and the
final design in the subsequent
spirals.
Construct or
Build
⚫ The Construct phase refers to
production of the actual software
product at every spiral. In the
baseline spiral, when the product
is just thought of and the design is
being developed a POC (Proof of
Concept) is developed in this
phase to get customer feedback.
 Construct or
Build
⚫ Then in the subsequent spirals
with higher clarity on requirements
and design details a working
model of the software called build
is produced with a version
[Link] builds are sent to
the customer for feedback
Evaluation and Risk
Analysis
⚫ Risk Analysis includes identifying,
estimating and monitoring the
technical feasibility and
management risks, such as
schedule slippage and cost
overrun. After testing the build,
at the end of first iteration, the
customer evaluates the software
and provides feedback.
⚫ The following illustration is a
representation of the Spiral Model,
listing the activities in each
⚫ Based on the customer
evaluation, the software
development process enters the
next iteration and subsequently
follows the linear approach to
implement the feedback suggested
by the [Link] process of
iterations along the spiral
continues throughout the life of
the software.
 Spiral Model
Application
⚫ TheSpiral Model is widely used in
the software industry as it is in
sync with the natural
development process of any
product, i.e. learning with maturity
which involves minimum risk for
the customer as well as the
development firms.
 uses of a Spiral
Model −
⚫ When there is a budget constraint and risk evaluation is
important.
⚫ For medium to high-risk projects.
⚫ Long-term project commitment because of potential changes
to economic priorities as the requirements change with time.
⚫ Customer is not sure of their requirements which is usually
the case.
⚫ Requirements are complex and need evaluation to get
clarity.
⚫ New product line which should be released in phases to
get
enough customer feedback.
⚫ Significant changes are expected in the product during the
development cycle.
Spiral Model - Pros and
Cons
⚫ The advantages of the Spiral SDLC Model are as
follows −

⚫ Changing requirements can be accommodated.

⚫ Allows extensive use of prototypes.

⚫ Requirements can be captured more accurately.

⚫ Users see the system early.

⚫ Development can be divided into smaller parts

and the risky parts can be developed earlier which
helps in better risk management.
 The disadvantages of
the Spiral SDLC
Model are as follows
• Management is more complex.
−
• End of the project may not be
known early.
• Not suitable for small or low risk
projects and could be expensive
for small projects.
• Process is complex
• Spiral may go on indefinitely.
• Large number of intermediate
stages requires excessive
documentation.
 Prototype
Model
⚫ The prototype model requires that
before carrying out the
development of actual software, a
working prototype of the system
should be built. A prototype is a toy
implementation of the system. A
prototype usually turns out to be a
very crude version of the actual
system, possible exhibiting limited
functional capabilities, low reliability,
and inefficient performance as
 Prototype
Model
⚫ In many instances, the client only has a
general view of what is expected from the
software product. In such a scenario
where there is an absence of detailed
information regarding the input to the
system, the processing needs, and the
output requirement, the prototyping
model may be employed.
Steps of Prototype
Model
⚫ Requirement Gathering and
Analyst
⚫ Quick Decision
⚫ Build a Prototype
⚫ Assessment or User
Evaluation
⚫ Prototype Refinement
⚫ Engineer Product
Advantage of Prototype
Model
⚫ Reduce the risk of incorrect
user requirement
⚫ Good where
requirement are
changing/uncommitted
⚫ Regular visible process
aids management
⚫ Support early product
marketing
⚫ Reduce Maintenance
cost.
 Disadvantage of
Prototype Model
⚫ An unstable/badly implemented
prototype often becomes the final
product.
⚫ Require extensive customer
collaboration
⚫ Costs customer money
⚫ Needs committed customer
⚫ Difficult to finish if customer
withdraw
 Disadvantage of
Prototype Model
⚫ May be too customer specific, no
broad market
⚫ Difficult to know how long the
project will last.
⚫ Easy to fall back into the code and
fix without proper requirement
analysis, design, customer evaluation,
and feedback.
⚫ Prototyping tools are expensive.
⚫ Special tools & techniques are
required to build a prototype.
⚫ It is a time-consuming process.
U N I T 4 : R EQ U IREM ENT
ENGINEERING
Introductio
n
⚫ Requirements engineering (RE)
refers to the process of defining,
documenting, and maintaining
requirements in the engineering
design process..
⚫ Requirement engineering provides
the appropriate mechanism to
understand what the customer
desires, analyzing the need, and
assessing feasibility, negotiating a
reasonable solution, specifying
the solution clearly, validating the
specifications and managing the
requirements as they are
transformed into a working
system.
⚫ Thus,requirement engineering is
the disciplined application of
proven principles, methods, tools,
and notation to describe a
proposed system's intended
behavior and its associated
constraints
 Requirement
Engineering Process
⚫ Itis a four-step process, which
includes -
⚫ Feasibility Study
⚫ Requirement Elicitation and
Analysis
⚫ Software Requirement
Specification
⚫ Software Requirement Validation
⚫ Software Requirement
Management
 Requirement
Engineering Process
 Feasibility
Study:
⚫
The objective behind the
feasibility study is to create the
reasons for developing the
software that is acceptable to
users, flexible to change and
conformable to established
standards.
 Types of
Feasibility:
⚫ Technical Feasibility - Technical feasibility
evaluates the current technologies,
which are needed to accomplish
customer requirements within the time
and budget.
⚫ Operational Feasibility - Operational
feasibility assesses the range in which
the required software performs a series of
levels to solve business problems and
customer requirements.
⚫ Economic Feasibility - Economic feasibility
decides whether the necessary software
can generate financial profits for an
 Requirement
Elicitation and
⚫ This
Analysis:
is also known as the
gathering of requirements. Here,
requirements are identified with
the help of customers and
existing systems processes, if
available.

⚫ Analysis of requirements starts

with requirement [Link]
requirements are analyzed to
identify inconsistencies, defects,
omission, [Link] describe
 Problems of Elicitation
and Analysis
⚫ Getting all, and only, the right people
involved.
⚫ Stakeholders often don't know what
they want
⚫ Stakeholders express
requirements in their terms.
⚫ Stakeholders may have conflicting
requirements.
⚫ Requirement change during the
analysis process.
⚫ Organizational and political factors may
influence system requirements
 3. Software
Requirement
Specification:
⚫ Software requirement
specification is a kind of
document which is created by a
software analyst after the
requirements collected from the
various sources - the
requirement received by the
customer written in ordinary
language. It is the job of the
analyst to write the requirement
in technical language so that they
can be understood and beneficial
⚫ The models used at this stage
include ER diagrams, data flow
diagrams (DFDs), function
decomposition diagrams (FDDs),
data dictionaries, etc.

⚫ Data Flow Diagrams: Data Flow

Diagrams (DFDs) are used widely for
modeling the requirements. DFD shows
the flow of data through a system. The
system may be a company, an organization,
a set of procedures, a computer hardware
system, a software system, or any
combination of the [Link] DFD is
also known as a data flow graph or
bubble chart.
⚫ Data Dictionaries: Data Dictionaries are
simply repositories to store information
about all data items defined in [Link]
the requirements stage, the data
dictionary should at least define
customer data items, to ensure that the
customer and developers use the same
definition and terminologies.
⚫ Entity-Relationship Diagrams:Another
tool for requirement specification is the
entity- relationship diagram, often called
an "E-R diagram." It is a detailed logical
representation of the data for the
organization and uses three main
constructs i.e. data entities, relationships,
and their associated attributes.
4. Software Requirement
Validation:
⚫ After requirement specifications
developed, the requirements
discussed in this document are
[Link] user might demand
illegal, impossible solution or
experts may misinterpret the
needs. Requirements can be the
check against the following
conditions -
 Software Requirement
Validation
⚫ If they can practically implement
⚫ If they are correct and as per
the functionality and specially
of software
⚫ If there are any ambiguities
⚫ If they are full
⚫ If they can describe
Requirements Validation
Techniques
⚫ Requirements
reviews/inspections:
systematic manual analysis
of the requirements.
⚫ Prototyping: Using an executable
model of the system to check
requirements.
⚫ Test-case generation: Developing
tests for requirements to check
testability.
⚫ Automated consistency analysis:
 Software Requirement
Management:
⚫ Requirement management is the
process of managing changing
requirements during the
requirements engineering process
and system development.

⚫ New requirements emerge

during the process as business
needs a change, and a better
understanding of the system is
⚫ Thepriority of requirements
from different viewpoints
changes during
development process.

⚫ Thebusiness and technical

environment of the system
changes during the development.
 3.
Elaborati
on
⚫ In this task, the information taken
from user during inception and
elaboration and are expanded and
refined in elaboration.
⚫ Its main task is developing pure
model of software using
functions, feature and
constraints of a software.
 Requirement Gathering
Techniques
⚫ Techniques describe how tasks
are performed under specific
circumstances. A task may have
none or one or more related
techniques. A technique should be
related to at least one task.

⚫ The following are some of the

well- known requirements
gathering techniques
Brainstor
ming
⚫ Brainstorming is used in
requirement gathering to get as
many ideas as possible from
group of people. Generally used
to identify possible solutions to
problems, and clarify details of
opportunities.
 Document
Analysis
⚫ Reviewing the documentation of an
existing system can help when
creating AS– IS process document, as
well as driving gap analysis for
scoping of migration projects. In an
ideal world, we would even be
reviewing the requirements that
drove creation of the existing system
– a starting point for documenting
current requirements. Nuggets of
information are often buried in existing
documents that help us ask
questions as part of validating
 Focus
Group
⚫A focus group is a gathering of
people who are representative of
the users or customers of a product
to get [Link] feedback can be
gathered about needs/opportunities/
problems to identify requirements, or
can be gathered to validate and
refine already elicited
[Link] form of market
research is distinct from
brainstorming in that it is a
Intervi
ew
⚫ Interviews of stakeholders and
users are critical to creating the great
software. Without understanding the
goals and expectations of the users
and stakeholders, we are very
unlikely to satisfy [Link] also have
to recognize the perspective of each
interviewee, so that, we can properly
weigh and address their inputs.
Listening is the skill that helps a great
analyst to get more value from an
Observat
ion
⚫ By observing users, an analyst can
identify a process flow, steps, pain
points and opportunities for
improvement. Observations can be
passive or active (asking questions
while observing). Passive observation
is better for getting feedback on a
prototype (to refine requirements),
where active observation is more
effective at getting an understanding
of an existing business process.
Either approach can be used.
 Definition of Fact-finding
Techniques
⚫ Factfinding is process of
collection of data and information
based on techniques which
contain sampling of existing
documents, research, observation,
questionnaires, interviews,
prototyping and joint requirements
planning. System analyst uses
suitable fact-finding techniques to
develop and implement the
current existing system.
⚫ Collecting required facts are very
important to apply tools in
System Development Life Cycle
because tools cannot be used
efficiently and effectively without
proper extracting from facts.
Fact-finding techniques are used
in the early stage of System
Development Life Cycle
including system analysis phase,
design and post implementation
⚫ Factsincluded in any information
system can be tested based on
three steps: data- facts used to
create useful information, process-
functions to perform the
objectives and interface- designs
to interact with users.
 Fact-finding
techniques
⚫ There are seven common fact-finding
techniques

⚫ Sampling of existing documentation, forms and

databases

⚫ Research and Site visits

⚫ O bservation of the work environment

⚫ Questionnaires

⚫ Interviews
 Software Requirement
Specification (SRS)
Format
⚫ Inorder to form a good SRS,
here you will see some points
which can be used and should
be considered to form a
structure of good [Link]
are as follows
⚫ Introduction
⚫ (i) Purpose of this
document
⚫ (ii) Scope of this
document
⚫ (iii) Overview
⚫.General description
[Link] Requirements
[Link] Requirements
[Link]
Requirements
[Link] Constraints
[Link]-Functional Attributes
[Link] Schedule and
Budget
[Link]
 Software Requirement
Specification (SRS)
⚫ Format as name suggests, is
complete specification and
description of requirements of
software that needs to be fulfilled for
successful development of software
system. These requirements can be
functional as well as non-
requirements depending upon type
of [Link] interaction
between different customers and
contractor is done because its
Quality Function Deployment
 Quality Function Deployment - QFD
 At the conclusion of this class – You will have a
thorough understanding of:
1. What is QFD?
2. Why it is important?
3. When it is used?
4. How it is used?
5. Understand the function of a QFD Team
6. Realize the Benefits of QFD
7. The Voice of The Customer
8. Organization of information
9. The House of Quality
10. QFD Process
 History of QFD
 Yoji Akao, a Japanese planning specialist,
conceptualized QFD in the 1960’s
 Dr. Shigeru Mizuno, Professor Emeritus of the
Tokyo Institute of Technology is credited with
initiated the quality function deployment system
 History of QFD
 Statistical Quality Control, SQC, was the central
quality control activity after WWII.
• SQC is an effective method of monitoring process
using control charts.

 SQC became Total Quality Control, TQC.

 QFD was derived from TQC.

 First Application of QFD
• 1966, Bridgestone Tire Corp first used a process
assurance table.
• 1972, the process assurance table was retooled
by Akao to include QFD process.
• 1972, Kobe Shipyards (of Mitsubishi Heavy
Industry) began a QFD Oil Tanker project.
• 1978, Kobe Shipyards published their quality
chart for the tanker.
 QFD in North America
• QFD spread rapidly in North America during the 1980’s

• The Automobile industry and Manufacturing began

heavy use of QFD at this time.

• QFD symposiums (North American, Japanese,

European, International) were set up to explore research
relating to QFD techniques.

• The QFD institute was formed in 1994.

 What is Quality Function Deployment?
• Quality Function Deployment is a comprehensive quality
design method that:

• Seeks out spoken and unspoken customer needs

from fuzzy Voice of the Customer verbatim;
• Uncovers "positive" quality that wows the
customer;
• Translates these into designs characteristics and
deliverable actions; and
• Builds and delivers a quality product or service by
focusing the various business functions toward
achieving a common goal—customer satisfaction.
 What is QFD?

• Quality Function Deployment, QFD, is a quality

technique which evaluates the ideas of key
stakeholders to produce a product which better
addresses the customers needs.

• Customer requirements are gathered into a

visual document which is evaluated and
remodeled during construction so the important
requirements stand out as the end result.
 What is QFD?
• The link between
• Customer
• Design Engineer
• Competitors
• Manufacturing

• Provide Insight
• Into the whole design & manufacturing operation
• From concept to manufacture (cradle to the grave)
• Can improve efficiency
 Creative Definitions of QFD
 A systematic way of documenting and breaking down
customer needs into manageable and actionable detail.
 A planning methodology that organizes relevant
information to facilitate better decision making.
 A way of reducing the uncertainty involved in product and
process design.
 A technique that promotes cross-functional teamwork.
 A methodology that gets the right people together, early,
to work efficiently and effectively to meet customers’
needs.
 • WHAT DOES QFD DO?
CONCEPT CUSTOMER
• Better Designs in Half the Time!

“Traditional Timeline”
Plan Design Redesign Manufacture

Benefits
Plan Design Redesign Manufacture

QFD is a Productivity Enhancer

 The QFD Paradigm
• QFD provides the opportunity to make sure you
have a good product before you try to design
and implement it.

• It is about planning and problem prevention, not

problem solving .

• QFD provides a systematic approach to identify

which requirements are a priority for whom,
when to implement them, and why.
 Why is it important?
• QFD is very powerful because it
incorporates the voice of customer
in the design
Resulting in :
– A better product design
– A satisfied customer
– Insight into the design/manufacture
operation
– Improved problem solving and
efficiency in production
 When is it used?
• Ask these important questions

– Why do QFD?
– What is the goal?
– What should its make-up be?
– Is QFD the right tool ?
– Is this the right time?
– Is this the right place to implement?
– What is success?
– Who all should be involved?
 When is QFD Appropriate?
 Poor communications and expectations get lost in the
complexity of product development.
 Lack of structure or logic to the allocation of product
development resources.
 Lack of efficient and / or effective product / process
development teamwork.
 Extended development time caused by excessive
redesign, problem solving, or putting out fires.
 QFD Team
QFD Team
1. Its function in deployment
2. Two Types of Teams
New product design
Improving an existing design
3. Cross functional
• Marketing, design, quality, finance
and production
 How to use it ?
• Comprehensive QFD involves
• Four phases:
 6
Quality Function Deployment’s
House of Quality
Correlation
Matrix

Design
Attributes

The 2

Importance Rankings
1 5
4

House Customer Relationships Customer

Needs between Perceptions
Customer Needs

of and
Design Attributes

Quality
7
Costs/Feasibility
 Establishes the Flowdown
 Relates WHAT'S & HOW'S
 Ranks The Importance Engineering Measures
8
The House of Quality
 Key Elements
 Informational
Elements

Two
Two Types
Types of
of Elements
Elements in
in Each
Each House
House
QFD Flowdown
Manufacturing
Manufacturing Software
Software Service
Service
Environment
Environment Environment
Environment Environment
Environment

Customer Wants Customer Wants

Customer Wants

Technical Requirements Service Requirements

Product Functionality

Part Characteristics Service Processes

System Characteristics

Manufacturing Process Process Controls

Design Alternatives

Production Requirements
Building the House of Quality
1. Identify Customer Attributes
2. Identify Design Attributes / Requirements
3. Relate the customer attributes to the design
attributes.
4. Conduct an Evaluation of Competing Products.
5. Evaluate Design Attributes and Develop Targets.
6. Determine which Design Attributes to Deploy in the
Remainder of the Process.