Tek Sap 08 Swe Showfiles

Software Engineering
Teknoturf Info Services Pvt. Ltd. | © Copyright 2008 (Do not redistribute or reuse) Slide# 1
Objectives
To understand the softeware engineering discipline and

the structured approach of solving a problem
To gather an idea of various models and their usage
To have an in-depth study of various phases of SDLC
Agenda
(00:30) Introduction to Software Development Process
(00:45) Different Phases of SDLC
(00:45) Various Models
(00:15) Break
(00:45) System Decomposition – Different Levels of DFD
(01:30) Data Modeling – Normalization ERD
(01:00) Lunch Break
(00:30) Quality Attributes
(00:15) Testing – Introduction.
(00:15) Types: Static & Dynamic Testing.
(00:20) Black Box Testing,White Box Testing- Basis Path Testing
(00:20) Levels of Testing- Unit, Integration, System, Acceptance Testing
(00:15) Break
(01:30) Activities – Case study work outs
What is a Software ?
Is it a collection of computer programs and associated

documents ?
Is it an Information transformer which produces,

manages, acquires, modifies or displays information ?
SOFTWARE ENGINEERING
Software Engineering is a systematic approach to

Development,
Operation,
Maintenance and retirement of software.
Establishment and use of sound engineering principles

in order to obtain economical software that is reliable
and efficient.
Software Product - Features
Extensive documentation
Detailed testing
Third party maintenance
Team effort
Conformance to standards
Software Product - Features
(contd…)
Usage of tools
Quality assurance
Project management
Risk management
Change management
SOFTWARE DEVELOPMENT
PROCESS (SDP)
A process of transforming user needs into an effective

software solution
User needs Effective s/w solution

SDP
NEED FOR SDP:
Helps organize complex job
To achieve a task in ordered manner
Provides visibility and clarity
Helps accomplishing task by assigning
responsibilities
SOFTWARE LIFE CYCLE MODEL
A life cycle model represents all the activities required

to make a software product transit through its life cycle
phases.
It also captures the order in which these activities are

to be undertaken.
NEED FOR SDLC MODEL
SDLC defines entry and exit criteria for every

phase.
Becomes difficult for software project managers to

monitor the progress of the project.
Product would not be in a systematic and disciplined

manner.
PHASES INVOLVED IN
THE SDLC
SDLC PHASES….
REQUIREMENT ANALYSIS
The aim of the requirements analysis phase is to understand
the exact requirements of the customer and to document
them properly.
This phase consists of two distinct activities,

Requirements gathering and analysis.
Requirements specification(SRS)
Some basic questions for problem analysis…
What is the problem?
Why is it important to solve the problem?
What are the possible solutions to the problem?
What exactly are the data input to the system and

what exactly are the data output by the system?
What are the likely complexities that might arise

while solving the problem?
TYPES OF REQUIREMENTS
Functional requirements
Those requirements that is explicitly stated and has
to be met by the software developed.
Ex: The software must have a response time of less

than 5 seconds
Non functional requirements
The attributes which enriches the quality of the

overall system.
Ex: The system should be portable
Software Requirement Specification Document
(SRS)
The customer requirements identified during the requirements
gathering and analysis activity are organized into a SRS
document.
The important parts of SRS document are
Functional requirements of the system
Non-functional requirements of the system
Goals of implementation
PROPERTIES OF A GOOD SRS
Unambiguous
Consistent
Complete
Structured (easy to modify)
Response to undesired events.
Verifiable.
DESIGN
The process of defining the architecture , interface,
component and other characteristics of a system.
Software design deals with transforming the

customer requirements, into a form (a set of
documents) that is suitable for implementation in a
programming language.
Analysis Vs Design
The aim of analysis is to understand the problem

with a view to eliminate any deficiencies in the
requirement specification such as incompleteness,
inconsistencies, etc.
The aim of design is to produce a model that will

provide a seamless transition to the coding phase.
Levels of Design
High level design (or Preliminary)

Low level design
Architectural Design
Defines the relationship between major structural
elements of the software.
Helps to develop a modular program structure and
represent the control relationship between modules.
Eg: Structure chart
Data Design
Is a process of gradual refinement of data,

by which application's data access is fast, easily
maintained, and can gracefully accept future
data enhancements
Ex. Normalization
Procedural and Interface Design
PROCEDURAL DESIGN:
The pseudo codes,algorithms,flow charts which are required to
represent the logic for each and every individual module are
prepared.
INTERFACE DESIGN:
This is basically used to design how to input data to the system
and display the information from the system.
MEASURES OF GOOD DESIGN
Good software design implies decomposition of

the problem into modules and the arrangement of these
modules in a hierarchy.
This can be measured through

- COUPLING
- COHESION
Coupling
Coupling is a measure of interdependence or

interconnection between the two modules.
Coupling depends on the interface complexity between

modules.
Coupling should always be low to reduce the ripple

effect b/w modules
DESIGN (contd..)
A visual representation of
(a) (b)
high coupling low coupling

Cohesion
Cohesion is a measure of functional strength of a module.

Cohesion refers to interdependency in a module.
Cohesion should be high to specify only related functions

are kept inside a module.
TESTING
We need to test a program to demonstrate the

existence of a fault.
Testing is the process of executing the program with

the intent of finding errors.
Testing has to be done efficiently – discover all

possible errors with minimum resources.
TESTING
Testing is the process of executing the program with
the intent of finding errors
VERIFICATION
Are we building the product right.
VALIDATION
Are we built the right product
Types of Testing
Static Testing
Reviews,inspections, walkthroughs are some of the
techniques used.
Dynamic Testing
In dynamic testing the source code has to be executed and
tested with the test case
Testing Approaches
Black-box (or) Functional Testing

Testing the software without the knowledge of the
internal workings.
White-box (or) Structural Testing

Testing the software with the knowledge of the
internal workings.
Black Box Testing - Advantages
Knowledge of implementation is not necessary
Tester and programmer are independent of each other
Tests done from user's point of view
Test cases can be designed as soon as the specifications are
complete
White Box Testing - Advantages
Used to identify infeasible path
Code optimization
Knowledge of internal code helps to identify the input type for

testing application efficiently
Test Case Generation - Methods
Equivalence Class Partitioning

Boundary Value Analysis
Cause Effect Analysis
Cause Effect Graphing
Levels of Testing
Unit Testing :
Testing each and every individual
module for its correctness by using
test cases and unit test specification(UTS).
Integration Testing:
Integration testing is the process of
assembling modules to check whether the
dependent modules are interacting properly or not.
Types of Integration Testing
Top-down Approach - Begins with the topmost module.
Bottom-up Approach-Begins with elementary modules.
Big Bang Approach- Test each module individually and linking all these
modules together only when every module in the system has been tested.
System Testing
System Testing - ensures that the system does what the

customer wants it to do. It uses system test specification(STS) .
The following are tested in system testing:

Functional requirements.
Non Functional requirements
Stress testing
Recovery testing........
Acceptance Testing
Acceptance Testing - customer evaluation of the system
Levels of acceptance testing:

Alpha Testing-done at developers end.
Beta Testing-done in clients environment
Pilot Testing-the system is installed on an
experimental basis
MODELS OF SDLC
Various standard models of SDLC:
Waterfall Model
Prototyping
Spiral Model
WATERFALL MODEL
Proposed Winston Royce in 1970
Sequential model
Systematic approach
Can’t retrieve to previous phase
WATERFALL MODEL
WATERFALL MODEL
(contd..)
ADVANTAGES
Linear approach
Equivalent importance to all the phases
Contract Related issues can be addressed
DISADVANTAGES
Not used in practical development projects
Output will be viewed at last stage
Late-risk resolution
Blocking of states
PROTOTYPE
A prototype is a toy implementation of the system.
Prototype usually exhibits:

Limited functional capabilities
Low reliability
Inefficient performance
Compared to the actual software
PROTOTYPE (contd..)
Valuable mechanism for gaining better understanding of the
customer’s needs
how the screens might look like
how the user interface would behave
how the system would produce outputs
TYPES
Throw-Away
Evolutionary
THROW-AWAY PROTOTYPE
Quick and dirty.

Quick requirements assessment, analysis, design.
Focus on rapid construction.
Ad-hoc development approach.
Discard prototype after objective is met.
EVOLUTIONARY PROTOTYPE
Build the software incrementally.
Adopt a rigorous, systematic approach.
Iterative model.
SPIRAL MODEL
Proposed by Barry Boehm in 1986.
Diagrammatic representation of this model appears

like a spiral with many loops.
Suitable for technically challenging software

products that are prone to several kinds of risks.
Accommodates prototyping.
SPIRAL MODEL (contd..)
Determine Evaluate
objectives, alternatives,
alternatives, Ri identify, resolve
constraints sk risks Prototype
Develop, verify next-

Plan next phase
level product
APPLICATION SITUATIONS
Waterfall model - Requirements are clear and stable.
Prototype
Throw away - Requirements are not clear
Evolutionary - Requirements are unstable
(keeps changing).
Spiral Model - Risk involved.
SYSTEM DECOMPOSITION
Divide the complex system into modules,which represents the

functionalities of the system. so that the module will become
more simple and manageable – DIVIDE AND CONQUER.
SYSTEM DECOMPOSITION
The process modelling is used to

represent the system decomposition.
Components of process modelling:

Data Flow Diagram
Data Dictionary
DATA FLOW DIAGRAM
Depicts how the information flows through the

processes and their storage
Used to describe how the system transforms inputs

into specific outputs.
COMPONENTS OF DFD
EXTERNAL ENTITIES (or) EXTERNAL AGENT
DATA FLOWS
DATA STORES
PROCESS
LEVELS OF DFD
DFD has an levelled approach- TOP-DOWN.
Level 0 – Represents the scope and environment of the
system(context).System is considered as a single process.
Level 1- The system is broken into its major
functionalities,each as a individual process.
Level 2- Decompose the major functionalities into sub
functionalities. Deals with each process in detailed.
No standard limit for number of levels in a DFD.
DATA MODELLING
Data model helps to identify the data objects to be processed

by the system and the attributes that describes the object.
It also helps to identify the relationship between each object

and other object
e.g: - E-R diagram
E-R DIAGRAM
Widely used conceptual level data model

Components
Entity
Attributes
Relationship
Entity
Collection of similar objects that share the common

attributes..
Employee
Jack (Instance1)
Jim ( Instance2)
Attributes
Attributes
Each entity is described by a set of attributes/properties
NAME
e.g:Empid,Ename,Eaddress (Attributes of Employee)
Relationships
Relationships
When two or more entities are associated with each
other, we have an instance of a Relationship.
Mentioned by straight line -Relationship name
Types of relationship
- Cardinality
- Optionality
PROBLEMS WITH INCOREECT DB DESIGN
Redundant Storage of Data

Insertion Anomaly
Deletion Anomaly
Update Anomaly
TO Minimize This
-NORMALIZATION
NORMALIZATON
1st normal form

-eliminating repeating groups
-primary key from the non-repeating group to the
repeating group which forms the composite key
2nd normal form

eliminating partial functional dependency
3rd normal form

eliminating transitive dependency
NORMALIZATON
Example for Normalization-One Student can take many

courses,Cost depends on the duration of the course
Stud Stud Course Course Name Duration Cost Grade
Id Name Id (Months)
101 Vijay 301 Java 2 50000 A
102 Kishore 304 C 4 60000 C
101 Vijay 302 C++ 4 60000 B
104 Vipin 303 . Net 2 50000 A
105 Sachin 305 J2EE 2 50000 O
1st Normal Form
R - Relation
R(Stud Id, Stud Name,Course Id,Course Name,Duration,Cost,Grade)
1st normal form:

R1(Stud Id, Stud Name)
R2(Course Id,Stud Id, Course Name, Duration, Cost, Grade)
2nd Normal Form
2nd normal form:
R1(Same)
R21(Course Id, Course Name, Duration,Cost)
R22(Course Id, Stud Id, Grade)
3rd Normal Form
3rd normal form:

R1(Same),R22(Same)
R211(Course Id,Course Name,Duration *)
R212(Duration *,Cost)
QUALITIES OF GOOD
SOFTWARE
Correctness
If there is no difference between what the software is
expected to do and what it does, the software is correct.
Correctness is absolute.
Usability
The measure of how friendly the software is to users.
QUALITIES OF GOOD
SOFTWARE (contd…)
Robustness
The capability to function acceptably in abnormal
circumstances.
Abnormal circumstances could be excess load, failure of
some parts.
Portability
Ability to use software across different hardware and
software environments.
QUALITIES OF GOOD
SOFTWARE (contd…)
Reliability
The capability of functioning correctly considering some
criteria.
The criteria could be , for example

Period of operational availability.
Accuracy of output or operations.
QUALITIES OF GOOD
SOFTWARE (contd…)
Maintainability
The ability to correct, refine and adapt with minimal

resource expenditure.
Efficiency
Optimal use of available resources.
In Summary…
Software Development Process
Different Phases of SDLC
Models – Waterfall, Prototype, Spiral
Process Modelling - DFD
Data Modelling –ERD, Normalization
Quality Attributes
Testing - Static & Dynamic Testing.
Black Box Testing, White Box Testing- Basis Path Testing
Levels of Testing- Unit, Integration, System, Acceptance
Testing

Tek Sap 08 Swe Showfiles

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tek Sap 08 Swe Showfiles

Uploaded by

Copyright:

Available Formats

Software Engineering

To understand the softeware engineering discipline and

Is it a collection of computer programs and associated

Is it an Information transformer which produces,

 Software Engineering is a systematic approach to

 Maintenance and retirement of software.

 Establishment and use of sound engineering principles

 Third party maintenance

A process of transforming user needs into an effective

User needs Effective s/w solution

 Helps organize complex job

 To achieve a task in ordered manner

 Provides visibility and clarity

 Helps accomplishing task by assigning

 A life cycle model represents all the activities required

 It also captures the order in which these activities are

 SDLC defines entry and exit criteria for every

 Becomes difficult for software project managers to

 Product would not be in a systematic and disciplined

the exact requirements of the customer and to document

This phase consists of two distinct activities,

 Why is it important to solve the problem?

 What are the possible solutions to the problem?

 What exactly are the data input to the system and

 What are the likely complexities that might arise

Ex: The software must have a response time of less

 Non functional requirements

The attributes which enriches the quality of the

gathering and analysis activity are organized into a SRS

The important parts of SRS document are

 Functional requirements of the system

 Non-functional requirements of the system

 Structured (easy to modify)

 Response to undesired events.

component and other characteristics of a system.

 Software design deals with transforming the

 The aim of analysis is to understand the problem

 The aim of design is to produce a model that will

 High level design (or Preliminary)

Eg: Structure chart

 Is a process of gradual refinement of data,

Good software design implies decomposition of

This can be measured through

 Coupling is a measure of interdependence or

 Coupling depends on the interface complexity between

 Coupling should always be low to reduce the ripple

high coupling low coupling

 Cohesion is a measure of functional strength of a module.

 Cohesion should be high to specify only related functions

 We need to test a program to demonstrate the

 Testing is the process of executing the program with

 Testing has to be done efficiently – discover all

Are we built the right product

Black-box (or) Functional Testing

White-box (or) Structural Testing

 Knowledge of implementation is not necessary

 Tester and programmer are independent of each other

 Tests done from user's point of view

 Test cases can be designed as soon as the specifications are

 Knowledge of internal code helps to identify the input type for

 Equivalence Class Partitioning

 Cause Effect Analysis

To understand the softeware engineering discipline and

Is it a collection of computer programs and associated

Is it an Information transformer which produces,

Software Engineering is a systematic approach to

Maintenance and retirement of software.

Establishment and use of sound engineering principles

Third party maintenance

Helps organize complex job

To achieve a task in ordered manner

Provides visibility and clarity

Helps accomplishing task by assigning

A life cycle model represents all the activities required

It also captures the order in which these activities are

SDLC defines entry and exit criteria for every

Becomes difficult for software project managers to

Product would not be in a systematic and disciplined

Why is it important to solve the problem?

What are the possible solutions to the problem?

What exactly are the data input to the system and

What are the likely complexities that might arise

Non functional requirements

Functional requirements of the system

Non-functional requirements of the system

Structured (easy to modify)

Response to undesired events.

Software design deals with transforming the

The aim of analysis is to understand the problem

The aim of design is to produce a model that will

High level design (or Preliminary)

Is a process of gradual refinement of data,

Coupling is a measure of interdependence or

Coupling depends on the interface complexity between

Coupling should always be low to reduce the ripple

Cohesion is a measure of functional strength of a module.

Cohesion should be high to specify only related functions

We need to test a program to demonstrate the

Testing is the process of executing the program with

Testing has to be done efficiently – discover all

Knowledge of implementation is not necessary

Tester and programmer are independent of each other

Tests done from user's point of view

Test cases can be designed as soon as the specifications are

Knowledge of internal code helps to identify the input type for

Equivalence Class Partitioning

Cause Effect Analysis

Cause Effect Graphing

Top-down Approach - Begins with the topmost module.

Bottom-up Approach-Begins with elementary modules.

Proposed Winston Royce in 1970

Can’t retrieve to previous phase

A prototype is a toy implementation of the system.

Prototype usually exhibits:

Compared to the actual software

Quick and dirty.

Build the software incrementally.

Adopt a rigorous, systematic approach.

Diagrammatic representation of this model appears

Suitable for technically challenging software

Redundant Storage of Data

The criteria could be , for example

The ability to correct, refine and adapt with minimal