Software Engineering (KCS-601)

Dr. Sanjeev Kumar Ojha

B.Tech, M.Tech, M.S, Ph.D
Assisstant Professor
Department of IT
HCST, Mathura
 Syllabus

Unit 1 : Intorduction
Unit 2 : Software Requirement Specifications
Unit 3 : Software Design
Unit 4: Software Testing
Unit 5 : Software Maintenance and Software Project
Management
 Unit 1 :Introduction
Introduction to Software Engineering
Software Components
Software Characteristics
Software Crisis
Software Engineering Processes,
Similarity and Differences from Conventional Engineering Processes
Software Quality Attributes
Software Development Life Cycle (SDLC) Models:
Water Fall Model,
Prototype Model,
Spiral Model,
Evolutionary Development Models,
Iterative Enhancement Models
Unit 2: Software Requirement &
Specifications
Requirement Engineering Process:
Elicitation
Analysis
Documentation
Review and Management of User Needs
Feasibility Study
Information Modeling
Data Flow Diagrams
Entity Relationship Diagrams
Decision Tables
SRS Document
IEEE Standards for SRS
 ----Unit 2 Continues

Software Quality Assurance (SQA):

Verification and Validation
SQA Plans
Software Quality Frameworks
ISO 9000 Models
SEI-CMM Model
Unit 3 : Software Design
Basic Concept of Software Design
Architectural Design
Low Level Design
Modularization
Design Structure Charts
Pseudo Codes
Flow Charts
Coupling and Cohesion Measures
Design Strategies
Function Oriented Design
Object Oriented Design
Top-Down and Bottom-Up Design
 -----Unit 3 Continue

Software Measurement and Metrics:

Various Size Oriented Measures:
Halestead’s Software Science
Function Point (FP) Based Measures
Cyclomatic Complexity Measures:
Control Flow Graphs.
 Unit 4 : Software Testing

Testing Objectives
Unit Testing
Integration Testing
Acceptance Testing
Regression Testing
Testing for Functionality and Testing for Performance,
Top-Down and Bottom-Up Testing Strategies:
Test Drivers and Test Stubs
 --continue

Structural Testing (White Box Testing),

Functional Testing (Black Box Testing),
Test Data Suit Preparation,
Alpha and Beta Testing of Products.
Static Testing Strategies:
Formal Technical Reviews (Peer Reviews)
Walk Through
Code Inspection
Compliance with Design and Coding Standards.
Unit 5: Software Maintenance and Software
project Management
Software as an Evolutionary Entity
Need for Maintenance
Categories of Maintenance:
Preventive Maintenance
Corrective Maintenance
Perfective Maintenance
Cost of Maintenance,
Software Re-Engineering,
Reverse Engineering
 --Continue

Software Configuration Management Activities

Change Control Process
Software Version Control,
An Overview of CASE Tools.
Estimation of Various Parameters such as Cost, Efforts,
Schedule/Duration,
Constructive Cost Models (COCOMO),
Resource Allocation Models,
Software Risk Analysis and Management.
 Reference

1.R. S. Pressman, Software Engineering: A Practitioners

Approach, McGraw Hill.
2. Rajib Mall, Fundamentals of Software Engineering, PHI
Publication.
3.K. K. Aggarwal and Yogesh Singh, Software Engineering,
New Age International Publishers.
4.Pankaj Jalote, Software Engineering, Wiley
5.Deepak Jain,”Software Engineering:Principles and
Practices”, Oxford University Press.
Course Outcome
 Introduction to Software Engineering

The term software engineering is composed of two words,

software and engineering.

Software is more than just a program code.

A program is an executable code, which serves some
computational purpose.
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.
 Programs versus Software Products

Usually small in size Large

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

Feasibility
Study

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

Project Management
 Introduction to Software Engineering

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.
 Introduction to Software Engineering

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.
Software engineering helps to reduce this programming complexity.
Software engineering principles use two important techniques to
reduce problem complexity: abstraction and decomposition.
 Introduction to Software Engineering

“Application of systematic, displined, quantifiable approach to

development, operation and maintenamce of a software “
---IEEE 1990
“Software engineering is the establishment and use of sound engineering
principles in order to obtain economically software that is reliable and
work efficiently on real machines”
----Fritz Bauer
 Or
Software Engineering is a collection of techniques,
methodologies and tools that help with in production of a
high quality software system with a given budget and
before a given deadline while change occurs.
 Need of Software Engineering
l
Software enginnering is needed because high rate of change in
user requirements and environment in which software operate
l
Large software
l
Scalability
l
Cost
l
Dyanamic Nature
l
Quality Managemet
 Software Components

There are three components of the software:

1. Program : A computer program is a list of instructions that tell a

computer what to do.
2. Documentation:Source information about the product contained in
design documents, detailed code comments, etc.
3. Operating Procedures: Set of step-by-step instructions compiled by an
organization to help workers carry out complex routine operations.
 Software Characteristics

Software characteristics can be classified into six major components

l
 Functionality
It refers to the degree of performance of the software against its intended
purpose. It basically means are the required functions.
Functionality Covers.

Suitability: the degree to which a product or system provides functions

that meet the stated or implicit requirements when used under specific
conditions.
Accuracy: In a set of measurements, accuracy is closeness of the
measurements to a specific value, while precision is the closeness of
the measurements to each other.
Inteoperabilty: a characteristic of a product or system to work with
other products or systems
Compliance: Software compliance refers to how well an application
obeys the rules in a standard
Security:Ability to provide different level of Secutiy.
 Reliability

A set of attribute that Bear on the capability of software to maintain its

level of performances understated conditions for a stated period of time.
Reliability Covers
Recoverability: It is ability of software to be recover from failure or not.
Fault Tolerance: ability for software to detect and recover from a fault
that is happening or has already happened in either the software or
hardware in the system in which the software is running to provide
service by the specification
Maturity :State of software being fully developed.
 Efficiency
l
It refers to the ability of the software to use System Resources in the
most Effective and Efficient Manner. The software should make effective
use of storage space and executive commands as per desired timing
requirement.
l
Efficiency Covers
l
In time
l
In resource
 Usabiltiy
l
It refers to the extent to which the software can be used with ease.
Or the amount of effort or time required to learn how to use the
software should be less.
l
Usability Covers
l
Understandability
l
Learnability
l
Operability
 Maintanabilty

l
Refers to the ease with which the modifications can be made in a
software system to extend its functionality, improvement, performance or
correct errors.
l
Maintanability Covers
l
Tastability
l
Changeability
l
Tracebility
l
Analyzability
 Portability
l
A set of attributes that bears on the ability of the software to be
transferred from one environment to another, without or minimum
changes.
l
Portability Covers
l
Adaptability
l
Replacebiltiy
l
Installability
l
Robustness: It refers to the degree to which the software can keep on
functioning in spite of being provided with invalid data.
l
Integrity: It refers to the degree to which Unauthorized Access to the
software data can be prevented.
 Other Charcteristics

l
Software is developed or engineered; it is not manufactured in the
classical sense:
l
Although some similarities exist between software development and
hardware manufacturing, few activities are fundamentally different.
l
In both activities, high quality is achieved through good design, but the
manufacturing phase for hardware can introduce quality problems than
software.
 The software doesn’t “wear out.”:

l
Hardware components suffer from the growing effects of many other
environmental factors. Stated simply, the hardware begins to wear out.
l
Software is not susceptible to the environmental maladies that cause
hardware to wear out.
l
When a hardware component wears out, it is replaced by a spare part.
l
There are no software spare parts.
l
Every software failure indicates an error in design or in the process
through which design was translated into machine-executable code.
Therefore, the software maintenance tasks that accommodate requests
for change involve considerably more complexity than hardware
maintenance. However, the implication is clear—the software doesn’t
wear out. But it does deteriorate.
 The software continues to be custom-built:

l
A software part should be planned and carried out with the goal that it
tends to be reused in various projects.
l
Current reusable segments encapsulate the two information and the
preparation that is applied to the information, empowering the
programmer to make new applications from reusable parts.
l
In the hardware world, component reuse is a natural part of the
engineering process.
 Software Crisis

l
Software Crisis is a term used in computer science for the difficulty of writing
useful and efficient computer programs in the required time.
l
software crisis was due to using same workforce, same methods, same tools
even though rapidly increasing in software demand, complexity of software and
software challenges.
l
With increase in the complexity of software, many software problems arise
because existing methods were insufficient.
l
If we will use same workforce, same methods and same tools after fast
increasing in software demand, software complexity and software challenges,
then there arise some problems like software budget problem, software
efficiency problem, software quality problem, software managing and delivering
problem etc.
l
This condition is called software crisis.
 Causes of Software Crisis

l
The cost of owning and maintaining software was as expensive as
developing the software
l
At that time Projects was running over-time
l
At that time Software was very inefficient
l
The quality of software was low quality
l
Software often did not meet requirements
l
The average software project overshoots its schedule by half
l
At that time Software was never delivered
 Solution to Software Crisis

l
There is no single solution to the crisis.one possible solution of
software crisis is Software Engineering because software
engineering is a systematic, disciplined and quantifiable approach.
l
For preventing software crisis, there are some guidelines:
l
Reduction in software over-budget
l
The quality of software must be high
l
Less time needed for software project
l
Experience working team member on software project
l
Software must be delivered
 Software Engineering Process

A software engineering process is the model chosen for managing the

l

creation of software from initial customer inception to the release of the

finished product.
l
The chosen process usually involves techniques such as•
l
Analysis
l
Design
l
Coding
l
Testing and Maintenance
 Software Engineering Process

Several different process models exist and vary mainly in the frequency,
l

application and implementation of the above techniques, for example,

different process models use different analysis techniques, other models
attempt to implement the solution to a problem in one big-bang
approach, while others adopt an iterative approach whereby
successively larger and more complete versions of the software are built
with each iteration of the process model.
Difference between SE and Conventional Engineering
S. No Software Engineering Process Conventional Engineering Process

1 Software Engineering Process is a process Conventional Engineering Process is a process

which majorly involves computer science, which majorly involves science, mathematics and
information technology and discrete empirical knowledge.
mathematics.

2 It is mainly related with computers, It is about building cars, machines, hardware,

programming and writing codes for building buildings etc.
applications.

3 In Software Engineering Process construction In Conventional Engineering Process construction

and development cost is low. and development cost is high.

4 It can involve the application of new and It usually applies only known and tested principles
untested elements in software projects. to meet product requirements.

5 In Software Engineering Process, most In Conventional Engineering Process, most

development effort goes into building new development efforts are required to change old
designs and features. . design

6 It majorly emphasize on mass production.

It majorly emphasize on quality.
 Software Quality Attributes

l
1) Usability
l
It is described as how the user is utilizing a system effectively and the
ease of which users can learn to operate or control the system. The well-
known principle of usability is KISS (Keep It Simple Stupid). Software
applications should be user-friendly.
l
2) Reliability
It is the ability of a system to continue to keep operating over time
l

3) Availability
It is the ratio of the available system time to the total working time it is
l

required or expected to function.

 Software Quality Attributes

4) Portability
l

It is the ability of a software application to run on numerous platforms

such as data portability, hosting, viewing, etc.,
l
5) Testability
l
It shows how well the system or component facilitates to perform tests to
determine whether the predefined test criteria have been met.
6) Scalability
It is the ability of a system to handle the demand for stress caused by
increased usage without decreasing performance.
 Software Quality Attributes

7) Flexibility
It is the ability of a system to adapt to future changes
8) Reusability
It is the use of existing software I more than one software with small or
no change. It is a cost-efficient and time-saving quality attribute.
l
9) Maintainability
l
It is the ability of a software application to maintain easily and support
changes cost-effectively.
l
10) Supportability
l
It is the ability of a system that satisfies necessary requirements and
needs to identifying and solving problems.
 Software Quality Attributes

l
11) Interoperability
l
It is the ability of two or more systems to communicate or exchange data
easily and to use the data that has been exchanged.
l
12) Performance
l
It is the ability of a system in the form of responsiveness to various
actions within a certain period of time
l
13) Security
l
It is the ability of a system to resist or block malicious or unauthorized
attempts that destroy the system and at the same time provide access to
legitimate users
 Software Development Life Cycle Models

Software Development Life Cycle (SDLC) is a framework that defines

the steps involved in the development of software at each phase.
It covers the detailed plan for building, deploying and maintaining the
software.
SDLC defines the complete cycle of development i.e. all the tasks
involved in planning, creating, testing, and deploying a Software Product.
The various SDLC models are
Water Fall Model,
Prototype Model,
Spiral Model,
Evolutionary Development Models,
Iterative Enhancement Models
 Waterfall Model

The first detailed digram of this process was cited as 1970 article
by Wiston W Royce.
The earliest use of the term "waterfall" may have been in a 1976
paper by Bell and Thayer
This model was earliest approach of software development.
In waterfall model each phase must be comleted before next
phase can begin
It is also called classical waterfall model.
It is an example of lineal sequential model
Waterfall Model
 Classical Waterfall Model

Classical waterfall model divides life cycle into phases:

feasibility study,
requirements analysis and
specification,
design,
coding and unit testing,
integration and system testing,
maintenance.
 Classical Waterfall Model (CONT.)

Most organizations usually define:

standards on the outputs (deliverables) produced at the
end of every phase
entry and exit criteria for every phase.
They also prescribe specific methodologies for:
specification,
design,
testing,
project management, etc.
 Classical Waterfall Model (CONT.)

The guidelines and methodologies of an organization:

called the organization's software development
methodology.
Software development organizations:
expect fresh engineers to master the organization's software
development methodology.
 Feasibility Study

Main aim of feasibility study:determine whether

developing the product
financially worthwhile
technically feasible.
First roughly understand what the customer wants:
different data which would be input to the system,
processing needed on these data,
output data to be produced by the system,
various constraints on the behavior of the system.
 Activities during Feasibility Study

Work out an overall understanding of the problem.

Formulate different solution strategies.
Examine alternate solution strategies in terms of:
resources required,
cost of development, and
development time.
 Activities during Feasibility Study

Perform a cost/benefit analysis:

l

l to determine which solution is the best.

l you may determine that none of the solutions is feasible due
to:
l
high cost,
l
resource constraints,
l
technical reasons.
 Requirements Analysis and Specification

Aim of this phase:

understand the exact requirements of the customer,
document them properly.
Consists of two distinct activities:
requirements gathering and analysis
requirements specification.
 Goals of Requirements Analysis

Collect all related data from the customer:

analyze the collected data to clearly understand what
the customer wants,
find out any inconsistencies and incompleteness in the
requirements,
resolve all inconsistencies and incompleteness.
 Requirements Gathering

Gathering relevant data:

usually collected from the end-users through interviews and
discussions.
For example, for a business accounting software:
interview all the accountants of the organization to find
out their requirements.
 Requirements Analysis (CONT.)

The data you initially collect from the users:

would usually contain several contradictions and
ambiguities:
each user typically has only a partial and incomplete
view of the system.
 Requirements Analysis (CONT.)

Ambiguities and contradictions:

must be identified
resolved by discussions with the customers.
Next, requirements are organized:
into a Software Requirements Specification (SRS)
document.
Engineers doing requirements analysis and
specification:
are designated as analysts.
 Design
Design phase transforms requirements specification:
l

l into a form suitable for implementation in some

programming language.
l
In technical terms:
l
during design phase, software architecture is derived
from the SRS document.
l
Two design approaches:
l
traditional approach,
l
object oriented approach.
 Traditional Design Approach

Consists of two activities:

l

l Structured analysis
l Structured design
 Structured Analysis Activity

l
Identify all the functions to be performed.
l
Identify data flow among the functions.
l
Decompose each function recursively into sub-functions.
l Identify data flow among the subfunctions as well.
 Structured Analysis (CONT.)

l
Carried out using Data flow diagrams (DFDs).
l
After structured analysis, carry out structured design:
l architectural design (or high-level design)
l detailed design (or low-level design).
 Structured Design
l
High-level design:
l decompose the system into modules,
l represent invocation relationships among the modules.
l
Detailed design:
l different modules designed in greater detail:
l
data structures and algorithms for each module are
designed.
 Object Oriented Design
First identify various objects (real world entities) occurring in
l

the problem:
l identify the relationships among the objects.
l For example, the objects in a pay-roll software may be:
l
employees,
l
managers,
l
pay-roll register,
l
Departments, etc.
 Object Oriented Design (CONT.)

l
Object structure
l further refined to obtain the detailed design.
l
OOD has several advantages:
l lower development effort,
l lower development time,
l better maintainability.
 Implementation
Purpose of implementation phase (aka coding and unit
l

testing phase):
l translate software design into source code.
 Implementation
During the implementation phase:
l

l each module of the design is coded,

l each module is unit tested
l
tested independently as a stand alone unit, and
debugged,
l each module is documented.
 Implementation (CONT.)

l
The purpose of unit testing:
l test if individual modules work correctly.
l
The end product of implementation phase:
l a set of program modules that have been tested
individually.
 Integration and System Testing

l
Different modules are integrated in a planned manner:
l modules are almost never integrated in one shot.
l Normally integration is carried out through a number of
steps.
l
During each integration step,
l the partially integrated system is tested.
Integration and System Testing

M1 M2

M3 M4
 System Testing

l
After all the modules have been successfully integrated and
tested:
l system testing is carried out.
l
Goal of system testing:
l ensure that the developed system functions
according to its requirements as specified in the
SRS document.
 Maintenance
Maintenance of any software product:
l

l requires much more effort than the effort to develop the

product itself.
l development effort to maintenance effort is typically 40:60.
 Maintenance (CONT.)

Corrective maintenance:
l

Correct errors which were not discovered during the product

development phases.
Perfective maintenance:
Improve implementation of the system
enhance functionalities of the system.
Adaptive maintenance:
Port software to a new environment,
l
e.g. to a new computer or to a new operating system.
 Classical Waterfall Model (CONT.)
Metaphor of mathematical theorem proving:
l

l A mathematician presents a proof as a single chain of

deductions,
l
even though the proof might have come from a
convoluted set of partial attempts, blind alleys and
backtracks.
 Waterfall Model

l
Requirements are not changing frequently
l
Application is not complicated and big
l
Project is short
l
Requirement is clear
l
Environment is stable
l
Technology and tools used are not dynamic and is stable
l
Resources are available and trained
 Advantage

Before the next phase of development, each phase must be completed

They should perform quality assurance test (Verification and
Validation) before completing each stage
Elaborate documentation is done at every phase of the software’s
development cycle
Project is completely dependent on project team with minimum client
Any changes in software is made during the process of the
development
Suited for smaller projects where requirements are well defined
 Disadvantage

l
error can be fixed only during the phase
l
It is not desirable for complex project where requirement changes
frequently
l
Testing period comes quite late in the developmental process
l
Documentation occupies a lot of time of developers and testers
l
Clients valuable feedback cannot be included with ongoing development
phase
l
Small changes or errors that arise in the completed software may cause
a lot of problems
 Iterative Waterfall Model
Classical waterfall model is idealistic:
assumes that no defect is introduced during any
development activity.
in practice:
defects do get introduced in almost every phase of the life
cycle.
Defects usually get detected much later in the life cycle:
For example, a design defect might go unnoticed till the coding or testing
phase.
 Iterative Waterfall Model (CONT.)

Once a defect is detected:

we need to go back to the phase where it was introduced
redo some of the work done during that and all subsequent
phases.
Therefore we need feedback paths in the classical waterfall
model.
Iterative Waterfall Model (CONT.)

Feasibility Study

Req. Analysis

Design

Coding

Testing

Maintenance
 Iterative Waterfall Model (CONT.)
Errors should be detected
in the same phase in which they are introduced.
For example:
if a design problem is detected in the design phase
itself,
the problem can be taken care of much more easily
than say if it is identified at the end of the integration
and system testing phase.
 Phase containment of errors

Reason: rework must be carried out not only to the design

but also to code and test phases.
The principle of detecting errors as close to its point of
introduction as possible:
is known as phase containment of errors.
Iterative waterfall model is by far the most widely used
model.
Almost every other model is derived from the waterfall
model.
 Classical Waterfall Model (CONT.)

l
Irrespective of the life cycle model actually followed:
l the documents should reflect a classical waterfall model
of development,
l comprehension of the documents is facilitated.
 Prototyping Model
Before starting actual development,
a working prototype of the system should first be built.
A prototype is a toy implementation of a system:
limited functional capabilities,
low reliability,
inefficient performance.
 l
Reasons for developing a prototype
Illustrate to the customer:
input data formats, messages, reports, or interactive
dialogs.
Examine technical issues associated with product
development:
Often major design decisions depend on issues like:
response time of a hardware controller,
efficiency of a sorting algorithm, etc.
 Prototyping Model (CONT.)

The third reason for developing a prototype is:

it is impossible to ``get it right'' the first time,
we must plan to throw away the first product
if we want to develop a good product.
 Prototyping Model (CONT.)

Start with approximate requirements.

Carry out a quick design.
Prototype model is built using several short-cuts:
Short-cuts might involve using inefficient, inaccurate, or
dummy functions.
A function may use a table look-up rather than performing
the actual computations.
 Prototyping Model (CONT.)
The developed prototype is submitted to the customer
for his evaluation:
Based on the user feedback, requirements are refined.
This cycle continues until the user approves the prototype.
The actual system is developed using the classical
waterfall approach.
 Prototyping Model (CONT.)

Build Prototype

Requirements Customer Customer satisfied

Gathering Quick Design Evaluation of Design
Prototype

Refine Implement
Requirements

Test

Maintain
 Prototyping Model (CONT.)

Requirements analysis and specification phase becomes

redundant:
final working prototype (with all user feedbacks
incorporated) serves as an animated requirements
specification.
Design and code for the prototype is usually thrown away:
However, the experience gathered from developing the
prototype helps a great deal while developing the actual
product.
 Prototyping Model (CONT.)

Even though construction of a working prototype

l

model involves additional cost --- overall

development cost might be lower for:
l systems with unclear user requirements,
l systems with unresolved technical issues.
Many user requirements get properly defined and
l

technical issues get resolved:

l these would have appeared later as change requests and
resulted in incurring massive redesign costs.
 Evolutionary Model
Evolutionary model (aka successive versions or
l

incremental model):
l The system is broken down into several modules which
can be incrementally implemented and delivered.
l
First develop the core modules of the system.
l
The initial product skeleton is refined into
increasing levels of capability:
l by adding new functionalities in successive versions.
 Evolutionary Model (CONT.)

l
Successive version of the product:
l functioning systems capable of
performing some useful work.
l A new release may include new
functionality:
l
also existing functionality in the current
release might have been enhanced.
 Advantages of Evolutionary Model

Users get a chance to experiment with a partially developed

system:
much before the full working version is released,
Helps finding exact user requirements:
much before fully working system is developed.
Core modules get tested thoroughly:
reduces chances of errors in final product.
 Disadvantages of Evolutionary Model

Often, difficult to subdivide problems into functional

l

units:
which can be incrementally implemented and delivered.
evolutionary model is useful for very large problems,
where it is easier to find modules for incremental
implementation.
 Evolutionary Model with Iteration

Many organizations use a combination of iterative and

l

incremental development:
a new release may include new functionality
existing functionality from the current release may also
have been modified.
 Evolutionary Model with iteration
Several advantages:
l

Training can start on an earlier release

customer feedback taken into account
Markets can be created:
for functionality that has never been offered.
Frequent releases allow developers to fix unanticipated
problems quickly.
 Spiral Model
Proposed by Boehm in 1988.
Each loop of the spiral represents a phase of the
software process:
the innermost loop might be concerned with system
feasibility,
the next loop with system requirements definition,
the next one with system design, and so on.
There are no fixed phases in this model, the phases
shown in the figure are just examples.
 Spiral Model (CONT.)

The team must decide:

how to structure the project into phases.
Start work using some generic model:
add extra phases
for specific projects or when problems are identified
during a project.
Each loop in the spiral is split into four sectors (quadrants).
Spiral Model (CONT.)
Spiral Model
 Objective Setting (First Quadrant)

Identify objectives of the phase,

Examine the risks associated with these objectives.
Risk:
l
any adverse circumstance that might hamper
successful completion of a software project.
Find alternate solutions possible.
 Risk Assessment and Reduction (Second Quadrant)

For each identified project risk,

a detailed analysis is carried out.
Steps are taken to reduce the risk.
For example, if there is a risk that the requirements are
inappropriate:
a prototype system may be developed.
 Spiral Model (CONT.)

Development and Validation (Third quadrant):

develop and validate the next level of the product.
Review and Planning (Fourth quadrant):
review the results achieved so far with the customer and
plan the next iteration around the spiral.
With each iteration around the spiral:
progressively more complete version of the software gets
built.
 Spiral Model as a meta model

Subsumes all discussed models:

a single loop spiral represents waterfall model.
uses an evolutionary approach --
iterations through the spiral are evolutionary levels.
enables understanding and reacting to risks during each
iteration along the spiral.
uses:
prototyping as a risk reduction mechanism
retains the step-wise approach of the waterfall model.
 Comparison of Different Life Cycle Models

Iterative waterfall model

most widely used model.
But, suitable only for well-understood problems.
Prototype model is suitable for projects not well
understood:
user requirements
technical aspects
Comparison of Different Life Cycle Models (CONT.)

Evolutionary model is suitable for large problems:

can be decomposed into a set of modules that can be incrementally
implemented,
incremental delivery of the system is acceptable to the customer.
The spiral model:
suitable for development of technically challenging software
products that are subject to several kinds of risks.
 Software Design

l
It is process of transforming the user requirements into the form
suitable for programmer in software coding and implementation .
l
During the software design phase design documents are prepared
on the basis of SRS documents.
l
The following items are designed and documented during the
design phase:
l
Differnt modules are required.
l
Control relationship among modules.
l
Interface among different modules
l
Data structure among different modules.
l
Algorithms required to imlement among different modules.
 Objective of Software Design
1.Correctness: A good design should be correct i.e. it should correctly
implement all the functionalities of the system.
2. Efficiency: A good software design should address the resources,
time, and cost optimization issues.
3. Understandability: A good design should be easily understandable,
for which it should be modular and all the modules are arranged in
layers.
4. Completeness: The design should have all the components like data
structures, modules, and external interfaces, etc.
5. Maintainability: A good software design should be easily amenable
to change whenever a change request is made from the customer side.
 Software Design Concepts

l
The software design concept simply means the idea or principle
behind the design.
l
It describes how you plan to solve the problem of designing
software, the logic, or thinking behind how you will design software.
The software design concept provides a supporting and essential
structure or model for developing the right software.
l
There are many concepts of software design and some of them
are given below:
 Software Design Concepts

Abstraction

Refactoring

Modularity Software Design

Concepts Information hinng

Architecture
Patern

Refinement
Abstraction- hide Irrelevant data
l
Abstraction simply means to hide the details to reduce complexity
and increases efficiency or quality.
l
Different levels of Abstraction are necessary and must be applied
at each stage of the design process so that any error that is
present can be removed to increase the efficiency of the software
solution and to refine the software solution.
l
The solution should be described in broad ways that cover a wide
range of different things at a higher level of abstraction and a more
detailed description of a solution of software should be given at the
lower level of abstraction.
 Modularity- subdivide the system
l
Modularity in design means subdividing a system into smaller parts so
that these parts can be created independently and then use these parts
in different systems to perform different functions.
l
It is necessary to divide the software into components known as
modules because nowadays there are different software available like
Monolithic software that is hard to grasp for software engineers.
l
If the system contains fewer components then it would mean the system
is complex which requires a lot of effort (cost) but if we are able to divide
the system into components then the cost would be small.
 Architecture
l
Architecture simply means a technique to design a structure of something.
l
Architecture in designing software is a concept that focuses on various
elements and the data of the structure.
l
These components interact with each other and use the data of the structure in
architecture.
 Refinement- removes impurities
l
Refinement simply means to refine something to remove any
impurities if present and increase the quality.
l
The refinement concept of software design is actually a process of
developing or presenting the software or system in a detailed
manner that means to elaborate a system or software.
l
Refinement is very necessary to find out any error if present and
then to reduce it.
 Pattern- a repeated form
l
The pattern simply means a repeated form or design in which the
same shape is repeated several times to form a pattern.
l
The pattern in the design process means the repetition of a
solution to a common recurring problem within a certain context.
 Information Hiding- hide the information

Information hiding simply means to hide the information so that it

l

cannot be accessed by an unwanted party.

l
In software design, information hiding is achieved by designing the
modules in a manner that the information gathered or contained in
one module is hidden and can’t be accessed by any other
modules.
 Refactoring- reconstruct something

l
Refactoring simply means reconstructing something in such a way
that it does not affect the behavior of any other features.
l
Refactoring in software design means reconstructing the design to
reduce complexity and simplify it without affecting the behavior or
its functions.
l
Fowler has defined refactoring as “the process of changing a
software system in a way that it won’t affect the behavior of the
design and improves the internal structure”
 Levels of Software Design
l
Architectural Design:
l
The architecture of a system can be viewed as the overall
structure of the system & the way in which structure provides
conceptual integrity of the system. The architectural design
identifies the software as a system with many components
interacting with each other. At this level, the designers get the
idea of the proposed solution domain.
l
Preliminary or high-level design:
l
Here the problem is decomposed into a set of modules, the
control relationship among various modules identified, and also
the interfaces among various modules are identified. The
outcome of this stage is called the program architecture. Design
representation techniques used in this stage are structure chart
and UML.
l
Detailed design:
l
Once the high-level design is complete, a detailed design is
undertaken. In detailed design, each module is examined
 Software Design process
l
The software design process can be divided into the following
three levels of phases of design:
l
Interface Design
l
Architectural Design
l
Detailed Design
 Interface Design

Interface design should include the following

l

details:
l
Precise description of events in the
environment, or messages from agents to which
the system must respond.
l
Precise description of the events or messages
that the system must produce.
l
Specification on the data, and the formats of
the data coming into and going out of the system.
l
Specification of the ordering and timing
relationships between incoming events or
 Architectural Design
l
Architectural design is the specification of the major components of a system,
their responsibilities, properties, interfaces, and the relationships and
interactions between them. In architectural design, the overall structure of the
system is chosen, but the internal details of major components are ignored.
l
Issues in architectural design includes:
l
Gross decomposition of the systems into major components.
l
Allocation of functional responsibilities to components.
l
Component Interfaces
l
Component scaling and performance properties, resource consumption
properties, reliability properties, and so forth.
l
Communication and interaction between components.
 Detailed Design

l
Design is the specification of the internal elements of all major system
components, their properties, relationships, processing, and often their
algorithms and the data structures.
l
The detailed design may include:
l
Decomposition of major system components into program units.
l
Allocation of functional responsibilities to units.
l
User interfaces
l
Unit states and state changes
l
Data and control interaction between units
l
Data packaging and implementation, including issues of scope and visibility of
program elements
l
Algorithms and data structures
 Modularization
l
Modularization is a technique to divide a software
system into multiple discrete and independent
modules, which are expected to be capable of
carrying out task(s) independently.
l
These modules may work as basic constructs for
the entire software.
l
Designers tend to design modules such that they
can be executed and/or compiled separately and
independently.
l
Modular design unintentionally follows the rules of
‘divide and conquer’ problem-solving strategy this
is because there are many other benefits attached
Modularization
 Design Structure and Charts

l
Structure Chart represent hierarchical structure of modules.
l
It breaks down the entire system into lowest functional modules,
describe functions and sub-functions of each module of a system
to a greater detail.
l
Structure Chart partitions the system into black boxes (functionality
of the system is known to the users but inner details are unknown).
l
Inputs are given to the black boxes and appropriate outputs are
generated.
l
Modules at top level called modules at low level.
l
Components are read from top to bottom and left to right.
l
When a module calls another, it views the called module as black
box, passing required parameters and receiving results.
 Symbols Used in Structure Charts

1.Module
l
It represents the process or task of the system. It
is of three types.
l
Control Module
l
A control module branches to more than one
sub module.
l
Sub Module
l
Sub Module is a module which is the part
(Child) of another module.
l
Library Module
l
Library Module are reusable and invokable
from any module.
 2. Conditional Call
It represents that control module can select any of the sub module
l

on the basis of some condition.

 3. Loop (Repetitive call of module)

l
It represents the repetitive execution of module by the sub module.
l
A curved arrow represents loop in the module.
 5. Data Flow

It represents the flow of data between the modules. It is

l

represented by directed arrow with empty circle at the end.

 5. Control Flow

It represents the flow of control between the modules. It is

l

represented by directed arrow with filled circle at the end.

 6. Physical Storage
Physical Storage is that where all the information are to be stored.
l
Example : Structure chart for an Email server
 Typrd of Structure Chart

1.Transform Centered Structured

2.These type of structure chart are designed for the systems that
receives an input which is transformed by a sequence of
operations being carried out by one module.
3.
4.Transaction Centered Structure:
5.These structure describes a system that processes a number of
different types of transaction.
 Pseudo Codes

l
Pseudo code is a term which is often used in programming and
algorithm based fields.
l
It is a methodology that allows the programmer to represent the
implementation of an algorithm.
l
Often at times, algorithms are represented with the help of pseudo
codes as they can be interpreted by programmers no matter what
their programming background or knowledge is.
l
Pseudo code, as the name suggests, is a false code or a
representation of code which can be understood by even a layman
with some school level programming knowledge.
 Advantage of Pseudo Code

l
Improves the readability of any approach. It’s one
of the best approaches to start implementation of
an algorithm.
l
Acts as a bridge between the program and the
algorithm or flowchart. Also works as a rough
documentation, so the program of one developer
can be understood easily when a pseudo code is
written out. In industries, the approach of
documentation is essential. And that’s where a
pseudo-code proves vital.
l
The main goal of a pseudo code is to explain
what exactly each line of a program should do,
 How to write a Pseudo-code?

1.Arrange the sequence of tasks and write the pseudocode accordingly.

2.Start with the statement of a pseudo code which establishes the main
goal or the aim.
3.Example: This program will allow the user to check the number
whether it's even or odd.
4.The way the if-else, for, while loops are indented in a program, indent
the statements likewise, as it helps to comprehend the decision control
and execution mechanism. They also improve the readability to a great
extent.
5.

Example:
if "1"
print response
"I am case 1"
if "2"
print response
"I am case 2"
 How to write a Pseudo-code?
1.Use appropriate naming conventions. The human tendency follows the approach to
follow what we see. If a programmer goes through a pseudo code, his approach will be
the same as per it, so the naming must be simple and distinct.
2.Use appropriate sentence casings, such as CamelCase for methods, upper case for
constants and lower case for variables.
3.Elaborate everything which is going to happen in the actual code. Don’t make the
pseudo code abstract.
4.Use standard programming structures such as ‘if-then’, ‘for’, ‘while’, ‘cases’ the way we
use it in programming.
5.Check whether all the sections of a pseudo code is complete, finite and clear to
understand and comprehend.
6.Don’t write the pseudo code in a complete programmatic manner. It is necessary to be
simple to understand even for a layman or client, hence don’t incorporate too many
technical terms.
 Flow Chart
l
A Flow Chart (also known as a Process Flow Diagram or Process Map) is a
diagram of the steps in a process and their sequence.
l
Two types of flow charts are utilized in quality improvement.
l
A high-level flowchart, outlining 6-10 major steps, gives a high-level view of a
process. These flowcharts display the major blocks of activity, or the major
system components, in a process.
l
These charts are especially useful in the early phases of a project and help to
set priorities for improvement work.
l
A detailed flowchart is a close-up view of the process, typically showing dozens
of steps. These flowcharts make it easy to identify complexity, excessive steps,
etc. in a process and should be used when you want to standardize or make
changes in the process.
 When to Use the Flowchart
l
When you need to define or analyze an existing process.
l
When you need to standardize or redesign a process.
l
When you need to find areas for improvement in a process such
as unnecessary steps, gaps,
l
barriers, etc.
 How to Construct a Flowchart

1.Identify the goal for creating the flowchart and the level of detail
required-high or detailed.
2.Assemble the people who know the process best and outline the
process steps.
3.Define the first and last steps in the process.
4.4. Begin documenting the process steps in sequence. Some steps may
be parallel-they happen at the same time. Describe the process as it
really exists, not the ideal. Most flow charts are made up of three main
types of symbol:
 How to Construct a Flowchart

Elongated circles, which signify the start or end of a process.

l

Rectangles or squares which show instructions or actions.

l

Diamonds which show decisions that must be made

l
 Continue---
l
5. Work through the entire process, showing
actions and decisions appropriately in the order
they occur. Link these together using arrows to
show the flow of the process.
l
(Tip: Self-adhesive notes are a flexible way to
document steps, using one note for each
l
step. This allows you to easily change the order
or add new steps.)
l
6. At decision symbols, choose the most natural
branch and continue to the end.
l
7. Use notes for unfamiliar steps and continue to
the end.
Flowchart
 Coupling and Chesion Measures
l
Coupling
l
Intermodular dependency
l
Cohesion
l
Intramodular dependency
 Coupling

l
Coupling between two modules is a measure of the degree of interaction
or interdependence between the two modules. A module having low
coupling and high cohesion is said to be functionally independent of
other modules.
l
If two modules interchange huge amounts of data/information, then they
are highly interdependent.
l
The degree of coupling between two modules depends on their interface
complexity, which is basically determined by the number of types of
parameters that are interchanged while invoking the functions of the
module.
 Types of Coupling

l
Data Coupling: Two modules are data coupled if
they communicate through a parameter. An
example is an elementary data item passed as a
parameter between two modules, e.g. an integer,
a float, a character, etc. This data item should be
problem-related and not used for the control
purpose.
l
Stamp Coupling: Two modules are stamp
coupled if they communicate using a composite
data item such as a record in PASCAL or a
structure in C.
l
Control Coupling: Control coupling exists
 Types of Coupling

l
Common Coupling: Two modules are common coupled if they share
data through some global data items.
l
Content Coupling: Content coupling exists between two modules if they
share code, e.g. a branch from one module into another module.
 Cohesion
l
A good software design implies clean
decomposition of the problem into modules and
the neat arrangement of these modules in a
hierarchy. The primary characteristics of neat
module decomposition are low coupling and high
cohesion.
l
Cohesion is a measure of functional strength of a
module. A module having low coupling and high
cohesion is said to be functionally independent of
other modules. Functional independence means
that a cohesive module performs a single function
or task. A functionally independent module has
Types of Cohesion
 Types of Cohesion
l
Coincidental Cohesion: A module is said to have
coincidental cohesion if it performs a set of
function or tasks that relate to each other very
loosely. In this case, the module contains a
random collection of functions. It is likely that the
functions have been put in the module out of pure
coincidence without any design or thought.
l
For example, in a transaction processing system
(TPS), the get-input, print-error, and summarize
members functions are grouped into one module.
The grouping does not have any relevance to the
structure of the problem.
 Types of Cohesion
l
Temporal Cohesion: When a module contains functions that are
related by the fact that all the functions must be executed in the
same time span, the module is said to exhibit temporal cohesion.
The set of functions responsible for initialization, start-up, a
shutdown of some process, etc. exhibit temporal cohesion.
l
Procedural Cohesion: A module is said to possess procedural
cohesion, if the set of functions of the module are all part of a
procedure (algorithm) in which certain sequence of steps have to
be carried out for achieving an objective, e.g. the algorithm for
decoding a message.
 Types of Conversion
l
Sequential Cohesion: A module is said to
possess sequential cohesion if the elements of a
module form the parts of the sequence, where the
output from one element of the sequence is input
to the next. For example, in a TPS, the get-input,
validate-input, sort-input functions are grouped
into one module.
l
Functional Cohesion: Functional cohesion is
said to exist if different elements of a module
cooperate to achieve a single function. For
example, a module containing all the functions
required to manage employees’ pay-roll exhibits
 Software Design Startegies

l
Function Orientation Design
l
Object Oriented Design
l
Top-Down and Bottom-up Approach
 Function Oriented Design

l
Function-oriented design, the system is
comprised of many smaller sub-systems known
as functions. These functions are capable of
performing significant task in the system. The
system is considered as top view of all functions.
Function oriented design inherits some properties
l

of structured design where divide and conquer

methodology is used.
 Function Oriented Design

l
This design mechanism divides the whole system
into smaller functions, which provides means of
abstraction by concealing the information and
their operation.. These functional modules can
share information among themselves by means of
information passing and using information
available globally.
Another characteristic of functions is that when a
l

program calls a function, the function changes the

state of the program, which sometimes is not
 Design Process
l
The whole system is seen as how data flows in the system by
means of data flow diagram.
l
DFD depicts how functions changes data and state of entire
system.
l
The entire system is logically broken down into smaller units
known as functions on the basis of their operation in the system.
l
Each function is then described at large.
 Obejct Oriented Design

l
Object oriented design works around the entities
and their characteristics instead of functions
involved in the software system. This design
strategies focuses on entities and its
characteristics. The whole concept of software
solution revolves around the engaged entities.
l
Let us see the important concepts of Object
Oriented Design:
l
Objects - All entities involved in the solution
design are known as objects. For example,
person, banks, company and customers are
treated as objects. Every entity has some
 Obejct Oriented Design

l
Encapsulation - In OOD, the attributes (data variables) and methods (operation
on the data) are bundled together is called encapsulation. Encapsulation not
only bundles important information of an object together, but also restricts
access of the data and methods from the outside world. This is called
information hiding.
l
Inheritance - OOD allows similar classes to stack up in hierarchical manner
where the lower or sub-classes can import, implement and re-use allowed
variables and methods from their immediate super classes. This property of
OOD is known as inheritance. This makes it easier to define specific class and
to create generalized classes from specific ones.
l
Polymorphism - OOD languages provide a mechanism where methods
performing similar tasks but vary in arguments, can be assigned same name.
This is called polymorphism, which allows a single interface performing tasks for
different types. Depending upon how the function is invoked, respective portion
of the code gets executed.
 Design Process

l
Software design process can be perceived as series of well-defined
steps. Though it varies according to design approach (function oriented
or object oriented, yet It may have the following steps involved:
l
A solution design is created from requirement or previous used system
and/or system sequence diagram.
l
Objects are identified and grouped into classes on behalf of similarity in
attribute characteristics.
l
Class hierarchy and relation among them is defined.
l
Application framework is defined.
 Bottom-up approach:

l
The design starts with the lowest level
components and subsystems.
l
By using these components, the next immediate
higher-level components and subsystems are
created or composed.
l
The process is continued till all the components
and subsystems are composed into a single
component, which is considered as the complete
system.
l
The amount of abstraction grows high as the
design moves to more high levels.
l
By using the basic information existing system,
 Advantage and Disadvantage

l
Advantages:
l
The economics can result when general solutions can be reused.
l
It can be used to hide the low-level details of implementation and be
merged with the top-down technique.
l
Disadvantages:
l
It is not so closely related to the structure of the problem.
l
High-quality bottom-up solutions are very hard to construct.
l
It leads to the proliferation of ‘potentially useful’ functions rather than the
most appropriate ones.
 Top-Down Approach

l
Each system is divided into several subsystems and components.
l
Each of the subsystems is further divided into a set of subsystems and
components.
l
This process of division facilitates in forming a system hierarchy
structure.
l
The complete software system is considered as a single entity and in
relation to the characteristics, the system is split into sub-system and
component.
l
The same is done with each of the sub-systems.
 Top-Down Approach

l
This process is continued until the lowest level of the system is reached.
l
The design is started initially by defining the system as a whole and then
keeps on adding definitions of the subsystems and components.
l
When all the definitions are combined together, it turns out to be a
complete system.
l
For the solutions of the software that need to be developed from the
ground level, top-down design best suits the purpose.
 Advantage and Disadvantage

l
Advantages:
l
The main advantage of the top-down approach is that its strong focus on
requirements helps to make a design responsive according to its
requirements.
l
Disadvantages:
l
Project and system boundaries tend to be application specification-
oriented. Thus it is more likely that advantages of component reuse will
be missed.
l
he system is likely to miss, the benefits of a well-structured, simple
architecture.
l
Hybrid Design:
l
It is a combination of both the top-down and bottom-up design
strategies. In this, we can reuse the modules.