ST.

THOMAS’ COLLEGE OF ENGINEERING AND TECHNOLOGY

Software Engineering Code: OEC-AIML 801C

T
E
BASICS OF SOFTWARE ENGINEERING
C
T
S A. K. SIROMONI
STCET
 Lecture on BASICS of SOFTWARE ENGINEERING

At the End of the Lecture Students will be able to -

T
E
Lecture Objective 1 : Understand the utility of Software Engineering

C
Lecture Objective 2 : Understand Software Development Life Cycle

T
Lecture Objective 3 : Explain different SDLC Models

S
A.K.SIROMONI (AIML) 2
 PROBLEM -> SOLUTION -> PRODUCT

• WHY WE NEED TO LEARN AND WORK WITH COMPUTER

IN SCHOOL , COLLEGE, OFFICE AND EVEN IN HOME ?

• WE HAVE TO SOLVE SOME PROBLEM AND PRODUCE A T

E
SOFTWARE PRODUCT . THE BIGGEST PROBLEM IN
SOLVING THIS IS , THE PROBLEM IS ALWAYS UNIQUE

C
AND THE PRODUCT WILL BE A NEW ONE NOT
AVAILABLE IN THE MARKET.

T
S
THE CREATER OF THE PRODUCT MAY BE SATISFIED
WITH THE QUALITY OF THE FINAL PRODUCT BUT IT
IS ULTIMATELY USER’S SATISFACTION AND
ACCEPTANCE DETERMINE THE QUALITY OF THE
FINAL PRODUCT.

A. K. Siromoni ( STCET) 3
 SOFTWARE ENGINEERING

SOLVING THE COMPLETE

PROBLEM STEPWISE AND T
PRODUCE A SOFTWARE PRODUCT E
WITHOUT
FULFILLING
ANY
C
COMPLETE
DEFECT
USER
REQUIREMENTT IS SOFTWARE
S
ENGINEERING.

A. K. Siromoni ( STCET) 4
 ERROR – DEFECT - EXCEPTION
• Error
- Coding that is producing wrong output / can not be converted to
machine level language : Detected during Software preparation
time and corrected accordingly
• Defect

ET
No problem with coding but not accepted by user at the end as the

T C
Software is not according to the user specification or user
requirement : Rebuild some modules of the Software or may be
build the Software again.
• Exception S
In general cases , the coding will give correct output for any input ,
but in specific cases it will give error : In most of the Object
Oriented Languages like C++, Java, Python etc. , this situation is
handled with Exception Class Objects available with language.

A.K.SIROMONI (STCET) 5
 REQUIREMENT and PRODUCT
REQUIREMENT : FROM
P CLIENT L
1. FEASIBILITY STUDY : VENDOR
T
R
O
D
I
U 2. UNDERSTANDING PROBLEM IN DEPTH : VENDOR F
C
T
3. SOLVING THE PROBLEMS : VENDOR E E
C

C
D
E
4. CREATING THE PRODUCT : VENDOR Y
V
E C
L
O
P T
5.CHECKING THE PRODUCT : CLIENT and VENDOR L
E
M
E
N
T
S
6a) If accepted : CLOSE THE JOB

6b) Otherwise : START FROM STEP2

A. K. Siromoni ( STCET) 6
 MODEL
• Definition from DICTIONARY :

T
A representation, generally in miniature, to show
the construction or appearance of something.

E
C
• Definition from SOFTWARE ENGINEERING :

T
An abstract representation of creation of a software
system that helps all stakeholders related to that

S
software understanding its structure, behavior, and
intended use

A. K. Siromoni ( STCET) 7
 SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)
Requirement from client to develop a software to
deliver the software product to client with fulfillment
of all client need.
T
Types of SDLC MODEL
E
C
• WATERFALL MODEL
• V MODEL
• ITERATIVE MODEL
• SPIRAL MODEL
• INCREMENTAL MODEL
T
S
• RAPID ACTION DEVELOPMENT MODEL
• PROTOTYPE MODEL
• OBJECT ORIENTED MODEL
• AGILE MODEL

A. K. Siromoni ( STCET) 8
 FEASIBILITY
EVERY MODEL STARTS WITH THE PHASE
FEASIBILITY STUDY
FEASIBILITY STUDY BEFORE BUILDING A SOFTWARE T
PRODUCT INCLUDES
E
•
•
Legal Feasibility
C
Cultural and Political Feasibility
•
• T
Technical Feasibility
Operational Feasibility
•
•
•
S
Economic Feasibility
Resource Feasibility
Schedule Feasibility
• Market Feasibility
A. K. Siromoni ( STCET) 9
 SCENERIO

• CLIENT HAS APPROACHED TO A COMPANY FOR THE

PREPARATION OF A CUSTOMIZED SOFTWARE ASSUMING THAT
COMPANY CAN PREPARE THAT SOFTWARE ACCORDING TO
THEIR NEED.
• A COMPANY WILL DEVELOP A SOFTWARE AND WILL MARKET
T
E
THIS SOFTWARE AMONG THE SPECIFIED TARGET PEOPLE.

LEGAL FEASIBILITY
•
C
LEGAL FEASIBILITY INCLUDES THE LAWS AND CYBER

T
REGULATIONS OF THE COUNTRY WHERE THE SOFTWARE WILL
BE USED.

S
CULTURAL AND POLITICAL FEASIBILITY
• CULTURAL AND POLITICAL FEASIBILITY INCLUDES TAKING CARE
OF CULTURAL AND POLITICAL SENSITIVITY SO THAT NO
ORGANIZATIONAL PROBLEM OCCURS AFTER SOFTWARE
PREPARATION.
A. K. Siromoni ( STCET) 10
TECHNICAL FEASIBILITY
• TECHNICAL FEASIBILITY INCLUDES UNDERSTANDING OF
REQUIREMENT OF HARDWARE AND SOFTWARE AND MANPOWER
WITH THEIR TECHNICAL EBILITY AND SKILL FOR PREPARATION

T
OF SOFTWARE.

OPERATIONAL FEASIBILITY

E
• OPERATIONAL FEASIBILITY INCLUDES CHECKING OF USER’S
OPERATIONAL ENVIRONMENT AND FITNESS OF THE SOFTWARE

C
WITH THAT. IT INCLUDES HARDWARE, SOFTWARE AND OTHER
ACCESSORIES IN USER ENVIRONMENT AND USER’S KNOWLEDGE

T
FOR FUTURE TRAINING TO USE THE SOFTWARE.

ECONOMIC
•FEASIBILITY S
ECONOMIC FEASIBILITY INCLUDES STUDYING THE COST AND
BENEFITS OF THE PROJECT CONSIDERING MAN-HOUR AND
OTHER REQUIREMENT FOR COMPLETION OF THE SOFTWARE.

A. K. Siromoni ( STCET) 11
 RESOURCE FEASIBILITY
• RESOURCE FEASIBILITY INCLUDES UNDERSTANDING THE
AVAILIBILITY OF REQUIRED FINANCIAL, TECHNOLOGICAL AND
HUMAN RESOURCES DURING THE PREPARATION OF SOFTWARE.

T
SCHEDULE FEASIBILITY
E
• SCHEDULE FEASIBILITY INCLUDES ANALYZING AND DETERMINIG

C
THE TIMELINE / DEADLINE FOR COMPLETION OF SOFTWARE

T
S
MARKET FEASIBILITY
• MARKET FEASIBILITY INCLUDES STUDYING THE SOFTWARE
REQUIREMENT AND BUSINESS ASPECTS OF THE SOFTWARE
WITH REFERENCE TO PRESENT AND FUTURE MARKET .

A. K. Siromoni ( STCET) 12
 WATER FALL MODEL
DEVELOPERS LIFE CYCLE PR
PROBLEM (REQUIREMENT)
FEASIBILITY STUDY
OJ
REQUIREMENT ANALYSIS T EC
T
DESIGN
SO E
LU
IMPLEMENTATION TIO
C N

T
TESTING

S DEPLOYMENT (PRODUCT)

MAINTENANCE

A. K. Siromoni ( STCET) 13
 WATER FALL MODEL
REQUIREMENT ANALYSIS

REQUIREMENT : CLIENT
( UNDERSTAND PRESENT SYSTEM WITHOUT COPMPUTERIZATION)
T F
<< INTERACTS >>
E I
N
RESEARCH AND REALISING : ANALYST
C
( ANALYSING THE REQUIREMENT FOR COMPUTERIZATION )
A
L

T << CREATES >>

I
Z

S
SOFTWARE REQUIREMENT SPECIFICATION (SRS)
( SIGNED BY CLIENT AND VENDOR BOTH)
E

A. K. Siromoni ( STCET) 14
 SRS
CONTENT OF SRS

1. Introduction
i) About the Product

T
: General Description of the product
ii) Product Price

E
: Detailed Calculation with supporting documents
iii) Completion Schedule

C
: Detailed flow of work mentioning completion of each
module

T
iv) Use of the Product

S
: Simple Description about utility and unique features of
the product
v) Intended Users
: Minimum requirement of Knowledge (usually Computer
)
and Skill of the user.
A. K. Siromoni ( STCET) 15
 SRS
CONTENT OF SRS

2. Functional Requirements :
Functional requirements describe a system, its

T
components, and the functions it must perform
according to user’s requirement .
It includes :
E
a) ALGORITHM
b) DATABASE C
T
c) USER INTERFACE
d) LEGAL PAPERS

S
e) BACKUP AND RECOVERY
f) SEARCHING DATA
g) REPORTS
h) AUTHANTICATION etc ……
A. K. Siromoni ( STCET) 16
 SRS
CONTENT OF SRS

3. Non Functional Requirements :

Non-Functional Requirements define the quality of

T
the software operation and constraints on its
performance
It includes : E
a) SECURITY
b) PERFORMANCE C
T
c) RELAIBILITY
d) COMPATIBILITY

S
e) AVAILABILITY
f) PORTABILITY
g) MAINTAINABILITY etc…

A. K. Siromoni ( STCET) 17
 SRS
CONTENT OF SRS

4. Appendices :
It includes references used in the document like definitions

T
of some specific terms, acronyms, abbreviations, etc.
What to avoid in SRS
E
1. C
Some of the main things which should be avoided are …
Ambiguity: Use of words like may or /
2.
3. T
Repetitive Statement: Use of same points in multiple clause
Insufficient Details: It causes misunderstanding during and

4.
5.
S after software preparation
Escalation of Budget/ Pricing : It may bring legal problems .
Assumptions : It causes hampering the time schedule and
escalate cost
A. K. Siromoni ( STCET) 18
 SRS
Who uses SRS

1. Customers for understanding what will be the purpose , use ,

security and quality of the product

T
2. Project managers to schedule and plan the project for
completion

E
3. Designers and programmers to plan for the efficient
implementation
C
4. Testers to prepare for testing activities

T
5. Maintenance teams for planning schedule and tools

S
6. Trainers to prepare training material for training the end users
7. Users to understand the proposed system and prepare for the
changeover.

A. K. Siromoni ( STCET) 19
 ITERATIVE WATER FALL MODEL
DEVELOPERS LIFE CYCLE PR
PROBLEM (REQUIREMENT)
FEASIBILITY STUDY
OJ
REQIREMENT ANALYSIS T EC
T
DESIGN
E
F
E IMPLEMENTATION
C
T
E
D TESTING

S
B
A DEPLOYMENT (PRODUCT : SOLUTION )
C
K MAINTENANCE

A. K. Siromoni ( STCET) 20
 V MODEL

DEVELOPER REQUIREMENT : PRODUCT TESTER

V V
E
PROBLEM SOLUTION A
R
I
FEASIBILITY STUDY
T PRODUCT L
I
F
I
REQUIREMENT ANALYSIS
E ACCEPTANCE TESTING D
A
C
A
T
DESIGN
C SYSTEM TESTING
T
I
O
I
O T
IMPLEMENTATION INTEGRATION TESTING N

N
S (CODING) UNIT TESTING

ACCEPTANCE TESTING DECIDES DEPLOYMENT

A. K. Siromoni ( STCET) 21
 VERIFICATION and VALIDATION
ROGER S PRESSMAN :
VERIFICATION REFERS TO THE SET_OF_ACTIVITIES THAT
ENSURE THAT SOFTWARE CORRECTLY IMPLEMENTS A SPECIFIC
FUNCTIONS .
T
E
VALIDATION REFERS TO A DIFFERENT SET_OF_ACTIVITIES THAT
ENSURE THAT THE SOFTWARE THAT HAS BEEN BUILT IS

C
TRACEABLE TO CUSTOMER REQUIREMENTS .

BARRY BOEHM :
T
• ARE WE BUILDING THE PRODUCT RIGHT – VERIFICATION

S
• ARE WE BUILDING THE RIGHT PRODUCT – VALIDATION

VERIFICATION AND VALIDATION ENSURES SOFTWARE QUALITY

CONTROL
A. K. Siromoni ( STCET) 22
 SPIRAL MODEL
PLANNING

RISK
ENTRY
CUSTOMER
COMMUNICATION T ANALYSIS

E
C ENGINEERING
( Analysis and
CUSTOMER
EVALUATION
T Build up
Representation

S CONSTRUCTION and RELEASE

of the
Application)

THE MAIN PHASE OF SPIRAL MODEL IS RISK

A. K. Siromoni ( STCET) 23
ANALYSIS
 SPIRAL MODEL
CUSTOMER COMMUNICATION :
Defining OBJECTIVE . Initiation of the project with detailed study of detailed
requirement

PLANNING

T
Defining recourses, scheduling, modules and other project related information

RISK ANALYSIS
E
C
Analyzing both technical ( Unavailability / Change of job of skilled personnel )
and managerial ( Change in Customer Management / Policy )risk.

ENGINEERING
T
Build Up Prototype and confirm it from Customer

S
CONSTRUCTION and RELEASE
Building Final Product of THIS CYCLE and handing over to CUSTOMER for
Evaluation
After CUSTOMER FEEDBACK, the second spiral loop starts.
A. K. Siromoni ( STCET) 24
 SPIRAL MODEL
When to use Spiral Model
Large projects: The spiral model is better for larger projects that are more complex.
Complex requirements: The spiral model is used when requirements are unclear or
complex, and significant changes are expected.
Frequent releases: The spiral model is used when frequent releases are necessary.

medium to high-risk projects.

T
Medium to high-risk projects: The spiral model is used to mitigate potential risks in

Long-term projects: The spiral model is used for long-term projects that may be affected
by economic changes.
E
Disadvantages of Spiral Model

C
Complex: The Spiral Model is more complex than other SDLC models.
Expensive: Spiral Model is not suitable for small projects as it is expensive.

T
Too much dependability on Risk Analysis: The main phase of spiral model is Risk
Analysis . So anything wrong in risk analysis affects heavily in project.

S
Difficulty in time management: As the number of phases is unknown at the start of
the project, time estimation is very difficult.
Complexity: It involves multiple iterations of the software development process.
Time-Consuming: The Spiral Model can be time-consuming, as it requires multiple
evaluations and reviews.
Resource Intensive: It requires a significant investment in planning, risk analysis, and
evaluations.
A. K. Siromoni ( STCET) 25
 AdvantagesSPIRAL
Spiral Model
MODEL
Risk Handling: The projects with many unknown risks that occur as the development
proceeds, in that case, Spiral Model is the best development model to follow due to the
risk analysis and risk handling at every phase.
Good for large projects: It is recommended to use the Spiral Model in large and complex
projects.

T
Flexibility in Requirements: Change requests in the Requirements at a later phase can be
incorporated accurately by using this model.

E
Customer Satisfaction: Customers can see the development of the product at the early
phase of the software development and thus, they habituated with the system by using it
before completion of the total product.

C
Iterative and Incremental Approach: The Spiral Model provides an iterative and
incremental approach to software development, allowing for flexibility and adaptability
in response to changing requirements or unexpected events.

T
Emphasis on Risk Management: The Spiral Model places a strong emphasis on risk
management, which helps to minimize the impact of uncertainty and risk on the software
development process.

S
Improved Communication: The Spiral Model provides for regular evaluations and
reviews, which can improve communication between the customer and the development
team.
Improved Quality: The Spiral Model allows for multiple iterations of the software
development process, which can result in improved software quality and reliability.
A. K. Siromoni ( STCET) 26
 PROTOTYPE MODEL
PROBLEM (REQUIREMENT)
FEASIBILITY STUDY

T
REQUIREMENT ANALYSIS

E
QUICK DESIGN and IMPLEMENTATION of a PROTOTYPE SOFTWARE

CUTOMER EVALUATION

C
ACCEPTANCE BY CUSTOMER

T FINAL DESIGN

S IMPLEMENTATION

TESTING

DEPLOYMENT

A. K. Siromoni ( STCET) 27
 RAD (RAPID APPLICATION DEVELOPMENT) MODEL
PROBLEM (REQUIREMENT)
FEASIBILITY STUDY
REQIREMENT ANALYSIS

MODULE 1
DESIGN BREAKING UP INTO MODULES
MODULE 2 T
….... MODULE n
ANALYZE ANALYZE
E ANALYZE
DESIGN

IMPLEMENTATION C
DESIGN

IMPLEMENTATION
DESIGN

IMPLEMENTATION
T
UNIT TESTING

S UNIT TESTING
INTEGRATION OF ALL MODULES AND INTEGRATION TESTING

OTHER TESTINGS DEPLOYMENT

UNIT TESTING

MAINTENANCE
A. K. Siromoni ( STCET) 28
 INCREAMENTAL MODEL
PROBLEM (REQUIREMENT) EASIBILITY STUDY
REQUIREMENT ANALYSIS
INCREAMENT 1 INCREAMENT 2
DESIGN DESIGN DESIGN

IMPLEMENTATION IMPLEMENTATION
T
IMPLEMENTATION

TESTING TESTING
E TESTING

DEPLOYMENT DEPLOYMENT

C DEPLOYMENT

T
VERSION 1 VERSION 2 VERSION 3

MAINTENANCE

S
Incremental Model are used when :-
• Development schedule is lengthy.
• Software team are not very well skilled or trained.
• The customer demands a quick release of the product.
• Requirements can be priorized.
A. K. Siromoni ( STCET) 29
 ITERATIVE MODEL
ITERATION 1 ITERATION 2 ITERATION n
Requirement Design Design

Analysis Testing
T
…....
Testing

E
Design Implementation Implementation

Testing Review Review

Implementation
C
T
Deployment
Review

S
The Iterative Models are used when
• Requirements are defined clearly and easy to understand.
• The software application is large.
Maintenance

• There is a requirement of changes in future.

A. K. Siromoni ( STCET) 30
 AGILE MODEL
AGILE DICTIONARY MEANING :
ABLE TO MOVE QUICLY AND EASY .
AGILE SDLC MODEL:
AGILE SDLC MODEL is a combination of ITERATIVE andT
E
INCREAMENTAL MODEL. AGILE MODEL is used when frequent
changes are required and PROJECT SHOULD BE COMPLETED

C
QUICKLY . A person from the client team usually assists the
developer team.

T REQUIREMENT

FEEDBACK

DEPLOYMENT
S GATHERING
DESIGN

CONSTRUCTION
/ ITERATION
TESTING

A. K. Siromoni ( STCET) 31
 AGILE MODEL
• Requirement Gathering :-
Requirements are understood by interaction with the customer. Accordingly
development team plan the time and effort needed to build the project.
Based on this information technical and economical feasibility is evaluated.
• Design :-

T
Artifacts like DFD, ERD , UML diagrams prepared to demonstrate how they
will apply to the existing software, database and interfaces.
• Construction / Iteration :-
E
In this step, development team members start working on their project,

C
which aims to deploy a working product.
• Testing :-
All the testing (Unit Testing, Integration Testing,System Testing) are done in
this phase
• Deployment :- T
• Feedback:-
S
Development Team deploys the software to user.

This is the last step of the Agile Model. In this, the team receives feedback
about the product and works on correcting bugs based on feedback
provided by the customer.
A. K. Siromoni ( STCET) 32
 AGILE MODEL
ADVANTAGES of AGILE MODEL
• Customer friendly – requests of changes in requirement during preparation
of software can be incorporated.
• Development time is less .

T
• Produces no defect as customer feedback is taken during preparation of
software

E
• Customer gets acquainted with software during preparation time . So
no/little customer training is required for using the software.

C
DISADVANTAGES of AGILE MODEL
• As software is prepared with customer as a member of the developer

T
team, any misconception of customer leads to problem in development
time and cost

S
• Sometimes development is done with communication with customer. So
less documentation is done in such model which may lead to confusion
among team of developers.
• The development team requires highly expertise and experience .
• As the product is developed in short time, planning for project timelines
and deliverables are difficult to forecast.
A. K. Siromoni ( STCET) 33