IES College of Technology, Bhopal

Practical File

Name of student : SHAILESH KUMAR

Enrollment Number : 0177AL231116

Subject : SOFTWARE ENGINEERING

Subject code : AL-403

Branch : CSE

Semester : 4th

Session : 2021-22

Department of Computer Science & Engineering

 LIST OF EXPERIMENTS

S. No Name of Experiment Course Outcome

1 To prepare PROBLEM STATEMENT for any project. C403.1

2 To identify the problem related to software crisis for a given scenario. C403.1,2

a) To classify the requirements into functional and non-functional

3 requirements. C403.2
b) To verify the requirements against quality attributes.
Identify the design principle that is being violated in relation to the
4 C403.2
given scenario.

5 To prepare DATA FLOW DIAGRAM for any project. C403.2,3

Identify the usage of stubs or drivers in the context of an integration

6 C403.4
testing scenario.

7 To identify the different types of integration testing. C403.5

8 To understand usage of software metrics. C403.4,5

 Experiment No. 1
AIM: To prepare problem statement for any project.
REQUIREMENTS:
 Hardware Interfaces
Pentium(R) 4 CPU 2.26GHz, 128 MBRAM
Screen resolution of at least 800x600 required for proper and complete viewing of screens. Higher
resolution would not be a problem.
CD ROM Driver
 Software Interfaces
Any window-based operating system (Windows 95/98/2000/XP/NT)
Word Pad or Microsoft Word.

THEORY:
The problem statement is the initial starting point for a project. It is basically a one-to-three-page
statement that everyone on the project agrees with that describes what will be done at a highlevel. The
problem statement is intended for a broad audience and should be written in non-technical terms. It helps
the non-technical and technical personnel communicate by providing a description of a problem. It
doesn't describe the solution to the problem.
The input to requirement engineering is the problem statement prepared by customer.
It may give an overview of the existing system along with broad expectations from the new system.
The first phase of requirements engineering begins with requirements elicitation i.e. gathering of
information about requirements. Here, requirements are identified with the help of customer and existing
system processes. So from here begins the preparation of problem statement.
So, basically a problem statement describes what needs to be done without describing how.

Conclusion: The problem statement was written successfully by following the steps described above.
 Experiment No. 2
AIM: To identify the problem related to software crisis for a given scenario.

THEORY:

In the early years of computers applications, the focus of the development and innovation were on
hardware. Software was largely views as an afterthought. Computer programming was an art.
Programmers did notfollow any disciplined or formalized approaches. This way of doing things was
adequate for a while, until the sophisticated of computer applications outgrow. Software soon took over
and more functions which were donemanually. A software houses begin to develop for widespread
distribution. Software development projects produced thousands of source program statement. With the
increase in the size and complexity of the software, following situation resulted is collectively termed as
software crisis.
1. Time Slippage
2. CostSlippage
3. Failure at customer Site
4. Intractable Error after delivery

Problem Description:

In the context of this background, for each of the scenario mentioned below, identify the most
appropriate problem related to software crisis and mention the same in the table provided.
Scenario A: Railways reservation software was delivered to the customer and was installed in one of
the metro station at 12.00 AM (mid-night) as per the plan. The system worked quite fine till the next
day 12.00 PM (noon). The system crashed at 12.00PM and the railways authorities could not continue
using software for reservation till
02.00M. It took two hours to fix the defect in the software in the software.
Scenario B: A polar satellite launch vehicle was scheduled for the launch on August 15th. The auto-
pilot of the rocket to be delivered for integration of the rocket on may15th. The design and development
of the software for the
auto-pilot more effort because of which the auto-pilot was delivered for the integration on June 15 th
(delayed by a month).The rocket was launched on Sep15th (delayed by a month).
Scenario C: Software for financial systems was delivered to the customer. Customer informed the
development team about a mal-function in the system. As the software was huge and complex, the
development team could not identify the defect in the software.
Scenario D: Due to the defect in the software for the baggage handling system. There was also of &
2M of revenues for the airport authorities.
Scenario Situation (as given A to D)
A Failure at Customer Site
B Time Slippage
C Intractable Error after Delivery
D Cost Slip page

Summary: mapped the problems related to software crisis to the given scenarios.
 Experiment No. 3
AIM: a) To classify the requirements into functional and non-functional requirements.
b) To verify the requirements against quality attributes.
THEORY: Functional requirements (FRs) specify the software functionality that the developer must
build in to the product to enable users accomplish their tasks, there by satisfying the business
requirements. Nonfunctional requirement as the name suggest, are those requirements which are not
directly concerned with the specific functions delivered by the system. Many non-functional
requirements (NFRs) related to the system as a whole rather than to individual functional requirements.
While failure to meet an individual functional may degrade the system, failure to meet a non-functional
system requirement may make whole system unusable. NFR‟s are of di reliability requirements etc.
Problem Description: Classify the following requirement by selecting the appropriate option.
1. ATM machine shall validate PIN of the user during log in along with bio-metric verification.
2. “Peak transaction-20,000 calls in Volume (s) a busy hour, average duration 20Secs, grade of
services 99.98%.
3. “Brahe System sounds the alarm Shall for10 seconds at frequency of 100H when the brake is
applied”.
4. “Mean Time Failure (MTTF) to-There should be no more than three Severity-
5. 1outage per month”.

Background: Software requirements specification formally captures the requirements of the software
to be developed. Hence it is important that requirements are free from defects like incorrect or
conflicting requirements.
Problem Description: Identify the requirements in the given SRS (Premium University Placement
Portal) for following issues:
1. Incorrectrequirements
Brahe- misspelled
“Brahe System sounds the alarm Shall for 10 seconds at frequency of 100H when the brake is applied”.

2. Ambiguous requirements
ATM (No need of Biometric only one login required)
ATM machines hall validate PIN of the user during login along with bio-metric verification.

3. Missing requirements
ATM machine shall validate PIN of the user during login along with bio-metricverification.

4. Conflicting requirements
“Mean Time Failure (MTTF) to-There should be no more than three Severity-1outage per month”.

5. Incomplete requirements
Peak, MTTF
“Peaktransaction-20,000 calls in Volume(s) a busy hour, average duration 20Secs, grade of services
99.98%.
“Mean Time Failure (MTTF) to-There should be no more than three Severity-1) outage per month”.
Summary:
a) classified the requirements into functional and non-functional requirements.
b) Identified the requirement defects in the given SRS
VivaQuestions:
1) Who are stake holders?
2) List few stakeholders involved in any example project.
3) What do you mean by failure?
4) Define a defect of software.
 Experiment No. 4
AIM: Identify the design principle that is being violated in relation to the given scenario.

THEORY:
A good object oriented design not only meets the specified requirements but also addresses implicit
requirements. There are five design principles which address most of the implicit requirements:
Software Design Principles:
1 Abstraction: Focus on solving a problem by considering the relevant details and ignoring the
irrelevant.
2 Encapsulation: Wrapping the internal details, thereby making these details inaccessible.
Encapsulation separates interface and implementation, specifying only the public interface to the
clients, hiding the details of implementation.
3 Decomposition and Modularization: Dividing the problem into smaller, independent, interactive
subtasks for placing different functionalities in different components
4 Coupling & Cohesion: Coupling is the degree to which modules are dependent on each other.
Cohesion is thedegree to which a module has a single, well defined task or responsibility. A good
design is one with loose coupling and strong cohesion.
5 Sufficiency, Completeness and Primitiveness: Design should ensure the completeness and
sufficiency with respect to the given specifications in a very simple way as possible.
Problem Description: Which of the following design principle(s) have been violated in the following
scenarios?
1. Abstraction
2. Decomposition and Modularization
3. Coupling & Cohesion
4. Encapsulation
5. Sufficiency, Completeness and Primitiveness
6. All
SNo. Description Principle Being Violated
1. Important information of a module is directly Encapsulation accessible by other modules.
2. Too many global variables in the program after Coupling & Cohesion, implementing
 design Decomposition and Modularization
3. Code breaks in unexpected places All
4. Unfulfilled requirements in the code after the design All has been implemented
5. Cyclic dependencies among classes Coupling & Cohesion, Decomposition and
6. Modularization

7. Huge class doing too many unrelated operations Abstraction, Decomposition and
8. Several unrelated functionalities/tasks are carried Decomposition and Modularization,
out by a single module Abstraction
9. All data of all classes in public Encapsulation
10. Design resulting in spaghetti code
11. Sufficiency, Completeness and Primitiveness
12. An algorithm documented as part of design is not Sufficiency, Completeness and
understandable by the programmers Primitiveness
Summary: Identified the relevance of design principles.
VivaQuestions:
1) List all the design principles.
2) Define encapsulation.
3) Define coupling and cohesion.
4) What do you mean by modularization?
5) Define the term modularization.
 Experiment No. 5
AIM: To prepare DATA FLOW DIAGRAM for any project.

REQUIREMENTS:
Hardware Interfaces
Pentium(R)4 CPU 2.26GHz, 128 MBRAM
Screen resolution of at least 800x600 required for proper and complete view in of screens. Higher
resolution would not be a problem.

Software Interfaces
 Any window-based operating system (Windows 95/98/2000/XP/NT)
 WordPad or Microsoft Word

THEORY
Data flow diagrams illustrate how data is processed by a system in terms of inputs and outputs.
 Data Flow Diagram Notations
You can use two different types of notations on your data flow diagrams: Yourdon & Coad or Gane &
Sarson.

Process Notations
Yourdon and Coad Process Notations

Gane and Sarson Process Notation

Process
. A process transforms incoming data flow into outgoing data flow

Datastore Notations

Yourdon and Coad Datastore Notations

Gane and Sarson Datastore Notations

DataStore
Data stores are repositories of data in the system. They are sometimes also referred toas files.

Data flow Notations

Data flow
Data flows are pipelines through which packets of information flow. Label the arrows with the name of the
data that moves through it.
Data Flow Diagram Layers
Draw data flow diagrams in several nested layers. A single process node on a high level diagram can be
expanded to show a more detailed data flow diagram. Draw the context diagram first, followed by various
layers of data flow diagrams.

The nesting of data flow layers

Context Diagrams
A context diagram is a top level (also known as Level 0 ) data flow diagram. It only contains one process
node (process 0) that generalizes the function of the entire system in relationship to external entities.
 ExternalEntityNotations

External Entity
External entities are objects outside the system, with which the system communicates. External entities are
sources and destinations of the system's inputs and outputs.

DFD levels
The first level DFD shows the main processes within the system. Each of the processes can be broken into
further processes until you reach pseudocode.
 An example first-level data flow diagram

Conclusion: The data flow diagram was made successfully by following the steps described above.
 Experiment No. 6
AIM: Identify the usage of stubs or drivers in the context of an integration testing scenario.

Background: Integration testing is carried out after the completion of unit testing and before the
software is delivered for system testing. In top down integration testing, dummy stubs are required
for bottom level modules. Similarly in bottom up testing, dummy drivers are required for top level
modules.

Problem Description: Consider the scenario of development of software for Travel, Management
System (TMS) isin progress. The TMS software has 3 major modules namely
Ticket_Booking_Module, Hotel_Booking_Module and Taxi_Booking_Module. The
Ticket_Booking_Module has 3 sub modules namely Enquiry_Module,Booking_Module and
Update_Module. The enquiry module uses Date_Validation_Unit, Ticket_Validation_Unit and
Place_Validation_Unit.

In the context of the given scenario, identify the usage of driver for the following situations.
1. Except the Ticket_validation_Unit, the coding and unit testing of all other modules, sub modules
and units of TMS are completed. The top-down integration is in progress for the TMS software. To
carry out the integration testing, which among the following is necessary ?
 A Stub for Place Validation Unit
 A Driver For Ticket Validation Unit
 A Stub for Enquiry_ Module-YES
 A Driver for Enquiry_ Module
 A Stub For Ticket Booking Module -YES
 A Driver For Ticket Booking Module

2. The coding and unit testing of all the module, sub modules and units of TMS are completed
except the Update Module (coding and testing for Edit_Module, Cancel_Module and View_Module
are also completed). The bottom-up integration is to be started for the TMS software. Mention any
stub or driver needed to carry out the integration testing?
A driver for Ticket Booking Module A driver for Enquiry Module
A driver for Place Validation Unit

3. Except the Taxi_Booking_Module, the coding and unit testing of all other modules, sub
modules and units of TMS are completed. The top-down integration is to be started for the TMS
software. Mention any stub or driver needed to carry out the integration testing.
 A Stub for Place_Validation_Unit
 A Stub for Update_Module
 A Stub For Ticket_Booking_Module.
 A Stub for Enquiry_Module.

Conclusion: Identified the usage of stubs or drivers in the context of integration testing

VivaQuestions:
1. Define testing
2. Differentiate between debugging and testing
3. Differentiate between a stub and driver
4. What do you mean by a module
5. What is validation.
 Experiment No. 7
AIM: To identify the different types of integration testing.
Background: Performance testing tests the non-functional requirements of the system. The
different types of performance testing are load testing, stress testing, endurance testing and spike
testing.

Problem Description: Identify the type of performance testing for the following:
1. A space craft is expected to function for nearly 8 years in space. The orbit control system of
the spacecraft is areal-time embedded system. Before the launch, he embedded software is to be
tested to ensure that it is capable of working for 8 years in the space. Identify the suitable
performance testing category to be carried out to ensure that the space craft will be functioning for
8years in the space as required.
2. Global Education Centre (GEC) at Infosys Mysore provides the training for fresh entrants.
GEC uses an automated tool for conducting objective type test for the trainees. At a time, a
maximum of 2000 trainees areexpected to take the test. Before the tool is deployed, testing of the
tool was carried out to ensure that it is capable of supporting 2000 simultaneous users. Indicate the
performance testing category?
3. A university uses its web-based portal for publishing the results of the students. When the
results of an examination were announced on the website recently on a pre-planned date, the web
site crashed. Which type of performance testing should have been done during web-site
development to avoid this unpleasant situation?
4. During unexpected terrorist attack, one of the popular websites crashed as many people logged
into the web-sitein a short span of time to know the consequences of terrorist attack and for
immediate guidelines from thesecurity personnel. After analyzing the situation, the maintenance
team of that website came to know that it wasthe consequences of unexpected load on the system
which had never happened previously. Which type of performance testing should have been done
during web-site development to avoid this unpleasant situation?

Scenarios Performance Testing Type

Scenario1 Performance testing
Scenario2 Load testing
Scenario3 Stress testing
Scenario4 Endurance testing.

Summary: Identified the different types of performance testing.

VivaQuestions:
1. Define performance testing
2. What do you mean by stress testing
3. List the categories of performance testing
4. What do you mean by load testing
5. Differentiate between white-box and black-box testing
 Experiment No. 8
AIM: To understand usage of software metrics.

Background: There are some metrics which are fundamental and the rest can be derived from
these. Examples ofbasic (fundamental) measures are size, effort, defect, and schedule. If the
fundamental measures are known, then we can derive others. For example if size and effort are
known, we can get Productivity (=size/effort). If the total numbers of defects are known we can get
the Quality (=defect/ size ) and soon.

Problem Description: Online loan system has two modules for the two basic services, namely Car
loan service and House loan service.
The two modules have been named as Car_Loan_Module and House_Loan_Module.
Car_Loan_Module has 2000 lines of uncommented source code. House_Loan_Modulehas 3000
lines of uncommented sour cecode.Car_Loan_Module was completely implemented by Mike.
House_Loan_Module was completely implemented byJohn. Mike took 100 person hours to
implement Car_Loan_Module. John took 200 person hours to implement House Loan Module.
Mike’s module had 5 defects. Jonh’s module had 6 defects. With respect to the context given,
which among the following is an INCORRECT statement?
ChooseOne:
1 Johns quality is better than Mike.
2 John’s productivity is more than Mike.
3 John introduced more defects than Mike.
4 John‟s efforts more than Mike.
Statement: 3
John introduced more defects than Mike.

Summary: under stood how to use basic and derived quality metrics
Important Viva questions

1. What do you mean by a metric?

2. Give an example metric?
3. What do you mean by quality?
4. Define software quality assurance?
5. What is software quality assurance plan?
6. What is SRS? What is SDLC?
7. Phases in software project development?
8. What do you mean by Size-oriented metrics?
9. Howtodocost estimationforaproject?
10. Explain design phase in software project development?
11. What are DFDandUMLdiagrams?
12. What is testing?
13. What is black box testing?
14. What isrisk analysis?
15. What id white box testing?
16. What isunittesting?
17. Explain integration testing?
18. What is quality assurance?

Internal Assessment Record of attainment of Course Outcomes

Measurement of CO attainment through Internal Assessments