1

COMPUTER ENGINEERING
DELHI TECHNOLOGICAL
UNIVERSITY (FORMERLY
Delhi College of Engineering)
Bawana Road, New Delhi 110042

Software Engineering
Lab File

Submitted towards the partial

fulfillment of The requirement
of the award of the degree of
Bachelor of Technology
In
Computer Engineering

Submitted by:
Roll No 2K20/CO/389
Name: SAHIL KUMAR

Submitted to:
Prof. Rajni Jindal

Department of Computer Science and Engineering

Delhi Technological University
Bawana Road, Delhi-110042
 2

CONTENTS
S.No. Experiment Pg. No. Date Signature

1. Hands-on experience on working of CASE Tools like Meta 3

Edit+, StarUML, and Rational rose.

2. Draw use case diagram along with a use case description of 5

the project.

3. Draw use case diagrams for different domains, like library 10

systems, banking systems, hospital management systems and
hotel management systems.

4. To gain knowledge about ER Diagram and prepare an ER 13

Diagram for Airline Reservation System.

5. To gain knowledge about Class Diagrams and prepare a Class 16

Diagram for the Airline Reservation System.

6. To gain knowledge about Object Diagrams and prepare one for 18

the Airline Reservation System.

7. To gain knowledge about the Data Flow Diagram and draw the 20
level-0 and level-1 Data Flow Diagram (DFD) for the Airline
Reservation System.

8. Develop code to calculate effort and time period using 22

different forms of COCOMO Model.

9. Develop test cases using boundary value analysis for the area 37
of a triangle, factorial of a number n.

10. Develop program to find cyclomatic complexity using dd path 41

for problems like root of quadratic equation

11. Develop equivalence class test cases for classification of a 45

triangle and calculating weekdays for a given date and next
date.

12. Program to predict reliability metric using different models. 49

13. Develop a program to calculate maintenance metrics using 53

different models
 3

Experiment 1

Aim:
Hands-on experience on working with CASE Tools like Meta Edit+, StarUML, and
Rational rose.

Theory:

MetaEdit+:
MetaEdit+ has comprehensive modeling tool features for many users and projects, and
it runs on all major platforms. It retrieves the modeling language created using
MetaEdit+ Workbench from the repository and automatically follows it.
MetaEdit+ fully supports your language's modeling tools. Your entire team may quickly
begin editing designs as graphical diagrams, matrices, or tables, moving between views
as needed. You may use filters to browse designs, apply components, link your models
to other designs, and test your models using different predefined or user-defined
reports.

StartUML:
StarUML is an open source software modeling tool for system and software modeling
that supports the UML (Unified Modeling Language) architecture. It is based on UML
version 1.4, supports eleven distinct diagram kinds, and accepts UML 2.0 notation. It
aggressively promotes the MDA (Model Driven Architecture) method by supporting the
UML profile idea and generating code in many languages.
StarUML is designed to be a modular and open tool. It provides frameworks for
expanding the tool's capabilities. It is intended to enable COM Automation access to all
functionalities of the model/meta-model and tool, as well as menu and option item
expansion. Users can also develop their own techniques and frameworks based on their
methodology. The utility may also be combined with other programmes.
StarUML offers a plethora of advanced capabilities and is far more than a "basic"
diagramming tool. With its MDA (Model Driven Architecture) capabilities, it is intended at
users that use UML intensively and with code generation goals rather than merely
creating diagrams to capture requirements. However, just utilizing StarUML as a
diagramming tool works good, especially on Windows, because the tool is developed
using Delphi and may run quicker than Java-based tools.
 4

Rational Rose:
Rational Rose Software is a collection of visual modeling tools for the creation of
object-oriented models. The practice of graphically portraying the software system is
known as object oriented modeling.
The Rational Rose programme is mostly used to create UML diagrams. It is a
professional tool that is frequently used in industry. During the design phase of the
software development life cycle, rational rose software assists in the creation of
diagrams in academia.

Finding and learning:

Computer assisted software engineering (CASE) tools are tools developed to support
certain business modeling methodologies. A CASE tool is a product that aids in the
analysis, modeling, and documentation of business processes. It is a tool or
combination of tools that aids in the application of the underlying ideas and procedures
of analysis.
 5

Experiment 2

Aim:
Draw a use case diagram along with a use case description of the project.

Theory:
The purpose of a use case diagram is to capture the dynamic aspect of a system. But
this definition is too generic to describe the purpose.
Use case diagrams are used to gather the requirements of a system including internal
and external influences. These requirements are mostly design requirements. So when
a system is analyzed to gather its functionalities use cases are prepared and actors are
identified. Use case diagrams are considered for high level requirement analysis of a
system. So when the requirements of a system are analyzed the functionalities are
captured in use cases. Use case diagrams are drawn to capture the functional
requirements of a system.

Use Case Descriptions for the AirplaneTicket Management Use Case

1. Login:
1.1Introduction: A passenger can log in the system to book flight
tickets.
1.2 Actors: Passenger, Clerk
1.3 Pre-Conditions: The system must be maintained by the
administrator, and passengers must have an existing account..
1.4 Post Conditions: If the Use Case is successful, then the
Passenger will be able to do various activities like Book
Ticket,Cancel Ticket
1.5 Basic Flow: If successfully Logged in, then various
activities Book Ticket,Cancel Ticket can Take place.
1.6 Alternative Flows: If login credentials are not working
then the login Error message will pop-up .
1.7 Special Requirements : None
1.8 Use Case Relationship : None
 6

2. Check Ticket Availability:

2.1 Introduction: The customer can check for ticket availability.
2.2 Actors: Passenger, Clerk
2.3 Pre-Conditions: The system must be logged in by
the Passenger.
2.4 Post Conditions: If the Use Case is successful, then passengers
can know about ticket availability .
2.5 Basic Flow: If successfully logged in, then various activities
like Check Tickets Availability and Login will occur.
2.6 Alternative Flows: If login credentials are not working then a
login Error message will pop-up or then no information regarding
ticket availability will be shown.
2.7 Special Requirements: None
2.8 Use Case Relationship : None
3. Book Tickets:
3.1 Introduction: The customer can book tickets.
3.2 Actors: Passenger, Clerk
3.3 Pre-Conditions: The system must be logged in by the
Passenger.
3.4 Post Conditions: If the Use Case is successful, then passengers
can book tickets .
3.5 Basic Flow: If successfully logged in, then various activities
like Book Tickets and Login will occur.
3.6 Alternative Flows: If login credentials are not working then a
login Error message will pop-up or if inadequate balance then
passengers will not be able to book the tickets.
3.7 Special Requirements : None
3.8 Use Case Relationship : None

4. Enter Personal Details:

4.1 Introduction: The customer can enter personal details.
4.2 Actors: Passenger, Clerk
 7

4.3 Pre-Conditions: The system must be logged in by the

Passenger.
4.4 Post Conditions: If the Use Case is successful, then passengers
enter personal details.
4.5 Basic Flow: If successfully logged in, then various activities
like Enter Personal Details and Login will occur.
4.6 Alternative Flows: If login credentials are not working then a
login Error message will pop-up or if personal details entered are
incorrect then passengers will not be able to book the tickets.
4.7 Special Requirements : None
4.8 Use Case Relationship : None
5. Enter Personal Details:
5.1 Introduction: The customer can enter personal details.
5.2 Actors: Passenger, Clerk
5.3 Pre-Conditions: The system must be logged in by the
Passenger.
5.4 Post Conditions: If the Use Case is successful, then passengers
enter personal details.
5.5 Basic Flow: If successfully logged in, then various activities
like Enter Personal Details and Login will occur.
5.6 Alternative Flows: If login credentials are not working then a
login Error message will pop-up or if personal details entered are
incorrect then passengers will not be able to book the tickets.
5.7 Special Requirements : None
5.8 Use Case Relationship : None
6. Cancel Tickets:
6.1 Introduction:The passenger can cancel the ticket and get a
refund.
6.2 Actors: Passenger, Clerk
6.3 Pre-Conditions: The system must be logged in by the
Passenger.
6.4 Post Conditions: If the Use Case is successful, tickets will be
canceled and money is refunded.
 8

6.5 Basic Flow: If successfully logged in, then various activities

like check status and Login will occur . If that is successful, then
tickets will be canceled and money will be refunded.
6.6 Alternative Flows: If login credentials are not working then a
login Error message will pop-up or if no tickets booked then
tickets will not be canceled and money will not be refunded.
6.7 Special Requirements : None
6.8 Use Case Relationship : None
7. Print Tickets
7.1 Introduction: Passengers can print the booked tickets.
7.2 Actors: Passenger.
7.3 Pre-Conditions: The system must be logged in by the
Passenger.
7.4 Post Conditions: If the Use Case is successful, then a report
will be generated .
7.5 Basic Flow: If successfully logged in, then various activities
like check status and Login will occur . If that is successful, then
a report of tickets will be printed.
7.6 Alternative Flows: If login credentials are not working then
login Error message will pop-up or if no tickets booked then
report of tickets will not be printed.
7.7 Special Requirements : None
7.8 Use Case Relationship : None

OUTPUT
Use case diagram for Airline Reservation System :-
 9

DISCUSSION
We learnt to make the Use Case diagram of the Airline Reservation System case study
by identifying use cases, A Use Case diagram is an important part of requirement
engineering and in the process of developing one we learnt how to identify the important
functionalities of the project, the users involved with the application and the relationship
between them.

FINDING AND LEARNING

A use-case diagram can help provide a higher-level view of the system. It has been said
before that "Use case diagrams are the blueprints for your system". They provide a
simplified and graphical representation of what the system must actually do.
 10

Experiment 3

Aim:
Draw use case diagrams for different domains, like library systems, banking systems,
hospital management systems and hotel management systems.

Theory:
The purpose of a use case diagram is to capture the dynamic aspect of a system. But
this definition is too generic to describe the purpose.
Use case diagrams are used to gather the requirements of a system including internal
and external influences. These requirements are mostly design requirements. So when
a system is analyzed to gather its functionalities use cases are prepared and actors are
identified. Use case diagrams are considered for high level requirement analysis of a
system. So when the requirements of a system are analyzed the functionalities are
captured in use cases. Use case diagrams are drawn to capture the functional
requirements of a system.

OUTPUT

1. Library Management System :-

 11

2. Banking System :

3. Hospital Management System:

 12

4. Hotel Management System:

DISCUSSION
We learnt to make the Use Case diagrams of library system, banking systems, hospital
management systems and hotel management system case study by identifying use
cases, A Use Case diagram is an important part of requirement engineering and in the
process of developing one we learnt how to identify the important functionalities of the
project, the users involved with the application and the relationship between them.

FINDING AND LEARNING

A use-case diagram can help provide a higher-level view of the system. It has been said
before that "Use case diagrams are the blueprints for your system". They provide a
simplified and graphical representation of what the system must actually do.
 13

Experiment 4

Aim:
To gain knowledge about ER Diagram and prepare an ER Diagram for Airline
Reservation System.

Theory:
An Entity-Relationship model (ERM) is an abstract and conceptual representation of
data. Entity-relationship modeling is a database modeling method, used to produce a
type of conceptual schema or semantic data model of a system, often a relational
database, and its requirements in a top-down fashion. Diagrams created by this process
are called entity relationship diagrams, ER diagrams, or ERDs. The building blocks:
entities, relationships, and attributes. An entity may be defined as a thing which is
recognized as being capable of an independent existence and which can be uniquely
identified.

● ENTITY: An entity may be a physical object such as a house

or a car, an event such as a house sale or a car service, or a
concept such as a customer transaction or order. Entities
can be thought of as nouns. Examples: a computer, an
employee, a song, a mathematical theorem. Entity sets are
drawn as rectangles, relationship sets as diamonds. If an
entity set participates in a relationship set, they are
connected with a line.

● RELATIONSHIP: A relationship captures how two or

more entities are related to one another. Relationships
can be thought of as verbs, linking two or more nouns.
Examples: A performs relationship between an artist and
a song, a proved relationship between a mathematician
and a theorem. Relationships illustrate how two entities
share information in the database structure.

● ATTRIBUTES: Attributes are drawn as ovals and are

connected with a line to exactly one entity or
relationship set. Key attribute is the unique,
distinguishing characteristic of the entity. For example,
an employee's social security number might be the
employee's key attribute.
 14

● CARDINALITY: Cardinality specifies how many instances of an entity relate to

one instance of another entity. Cardinality is also closely linked to cardinality.
While cardinality specifies the occurrences of a relationship, Cardinality
describes the relationship as either mandatory or optional. In other words,
cardinality specifies the maximum number of relationships and Cardinality
specifies the absolute minimum number of relationships.

OUTPUT
E-R Diagram for Airline Reservation System :-
 15

DISCUSSION
We learnt to make the Entity relationship diagram of the “Airline Reservation System”
case study by identifying the Entities and their attributes. Also we learnt to identify the
relationship between two Entities and their cardinality.

FINDING AND LEARNING

Using entity relationship diagram to represent data is an important technique. It should
not be used in isolation, but together with techniques that fully represent the business
object.
 16

Experiment 5

Aim:
To gain knowledge about Class Diagrams and prepare a Class Diagram for the Airline
Reservation System.

Theory:
The class diagram is a static diagram. It represents the static view of an
application. Class diagram is not only used for visualizing, describing and
documenting different aspects of a system but also for constructing executable
code of the software application.
The class diagram describes the attributes and operations of a class and also
the constraints imposed on the system. The class diagrams are widely used in
the modeling of object oriented systems because they are the only UML
diagrams which can be mapped directly with object oriented languages.
The class diagram shows a collection of classes, interfaces, associations,
collaborations and constraints. It is also known as a structural diagram.

OUTPUT
Class diagram for Airline Reservation System :-
 17

DISCUSSION
The purpose of the class diagram is to model the static view of an application.
The class diagrams are the only diagrams which can be directly mapped with
object oriented languages and thus widely used at the time of construction.

FINDING AND LEARNING

We are successfully able to prepare a class diagram for Airline Reservation
System. Class diagrams are the best way to illustrate a system's structure in a detailed
way, showing its attributes, operations as well as its inter- relationships.
 18

Experiment 6

Aim:
To gain knowledge about Object Diagrams and prepare one for the Airline Reservation
System.

Theory:
Object diagrams are derived from class diagrams so object diagrams are
dependent upon class diagrams.
Object diagrams represent an instance of a class diagram. The basic concepts
are similar for class diagrams and object diagrams. Object diagrams also
represent the static view of a system but this static view is a snapshot of the
system at a particular moment.
So the purpose of the object diagram is to find Object relationships of a
system, Static view of an interaction and understand object behavior and
their relationship from a practical perspective.

OUTPUT
The Object Diagram for Airline Reservation System :-
 19

DISCUSSION
The purpose of an object diagram should be understood clearly to implement
it practically. The purposes of object diagrams are similar to class diagrams.
The difference is that a class diagram represents an abstract model consisting
of classes and their relationships. But an object diagram represents an instance
at a particular moment which is concrete in nature.

FINDING AND LEARNING

An object diagram represents an instance at a particular moment, which is
concrete in nature. It means the object diagram is more close to the actual
system behavior. The purpose is to capture the static view of a system at a
a particular moment.
 20

Experiment 7

Aim:
To gain knowledge about the Data Flow Diagram and draw the level-0 and level-1 Data
Flow Diagram (DFD) for the Airline Reservation System.

Theory:
Data flow diagram is graphical representation of flow of data in an information
system. It is capable of depicting incoming data flow, outgoing data flow and
stored data. The DFD does not mention anything about how data flows
through the system. A DFD shows what kind of information will be input to and
output from the system, how the data will advance through the system, and
where the data will be stored.
Levels of DFD
● Level 0 - Highest abstraction level DFD is known as Level 0 DFD, which depicts
the entire information system as one diagram concealing all the underlying
details. Level 0 DFDs are also known as context level DFDs.
● Level 1 - The Level 0 DFD is broken down into more specific, Level 1 DFD. Level
1 DFD depicts basic modules in the system and flow of data among various
modules. Level 1 DFD also mentions basic processes and sources of
information.

DFD Components
DFD can represent Source, destination, storage and flow of data using
the following set of components -
● Entities - Entities are source and destination of information data. Entities are
represented by rectangles with their respective names.
● Process - Activities and action taken on the data are represented by Circle or
Round-edged rectangles.
● Data Storage - There are two variants of data storage - it can either be
represented as a rectangle with absence of both smaller sides or as an
open-sided rectangle with only one side missing.
● Data Flow - Movement of data is shown by pointed arrows. Data movement is
shown from the base of the arrow as its source towards the head of the arrow as
destination.

OUTPUT
Level-0 DFD for Airline Reservation System :-
 21

Level-1 DFD for Airline Reservation System :-

DISCUSSION
We learnt to implement the Level-0 and Level-1 DFD for Library Management
System and the flow of data between various processes and the repositories in
the Library Management System. A data flow diagram (DFD) maps out the flow
of information for any process or system. It uses defined symbols like
rectangles, circles and arrows, plus short text labels, to show data inputs,
outputs, storage points and the routes between each destination.

FINDING AND LEARNING

With a data flow diagram, users are able to visualize how the system will
operate, what the system will accomplish, and how the system will be
implement.
 22

Experiment 8

Aim:
Develop code to calculate effort and time period using different forms of COCOMO
Model.

Theory:
COCOMO (Constructive Cost Model) is a regression model based on LOC, i.e., number of Lines
of Code. It is a procedural cost estimate model for software projects and often used as a process
of reliably predicting the various parameters associated with making a project such as size,
effort, cost, time and quality.

The key parameters which define the quality of any software products, which are also an
outcome of the COCOMO are primarily Effort & Schedule:

Effort: Amount of labor that will be required to complete a task. It is measured in

person-months units.

Schedule: Simply means the amount of time required for the completion of the job, which is, of
course, proportional to the effort put. It is measured in the units of time such as weeks, months.

Types of Models: COCOMO consists of a hierarchy of three increasingly detailed and accurate
forms. Any of the three forms can be adopted according to our requirements. These are types of
COCOMO model:

1. Basic

2. Intermediate

3. Detailed

COCOMO models can be applied in three modes -

1. Organic Mode

2. Semi-detached Mode

3. Embedded Mode

CODE
1. Basic Model
 23

#include<stdio.h>

#include<conio.h>

#include<math.h>

#include<stdlib.h>

int main()

float effort,time;

float
table[3][4]={2.4,1.05,2.5,0.38,3.0,1.12,2.5,0.35,3.6,1.20,2.5,0.32};

int size,model;

char mode[][15]={"Organic","Semi-Detached","Embedded"};

system("cls");

printf("Enter size of project (in KLOC) : ");

scanf("%d",&size);

if(size>=2 && size<=50)

model=0; //organic

else if(size>50 && size<=300)

model=1; //semi-detached

else if(size>300)

model=2; //embedded

printf("\nThe mode is %s\n",mode[model]);

effort=table[model][0]*pow(size,table[model][1]);
 24

time=table[model][2]*pow(effort,table[model][3]);

printf("\nEffort = %f Person-Month",effort);

printf("\n\nDevelopment Time = %f Months",time);

return 0;

2. Intermediate Model
#include<stdio.h>
#include<conio.h>
#include<math.h>

int main()
{
float table[3][4]={3.2,1.05,2.5,0.38,3.0,1.12,2.5,0.35,2.8,1.20,2.5,0.32};
int i,j,size,model,rating;
char mode[][15]={"Organic","Semi-Detached","Embedded"};
char
driver[15][6]={"RELY","DATA","CPLX","TIME","STOR","VIRT","TURN",
"ACAP","AEXP","PCAP",
"VEXP","LEXP","MODP","TOOL","SCED"};
float effort,EAF,a,time;
float costdrivers[15][6]={
{0.75,0.88,1,1.15,1.40,-1},
{-1,0.94,1,1.08,1.16,-1},
{0.70,0.85,1,1.15,1.30,1.65},
{-1,-1,1,1.11,1.30,1.66},
{-1,-1,1,1.06,1.21,1.56},
 25

{-1,0.87,1,1.15,1.30,-1},
{-1,0.87,1,1.07,1.15,-1},
{1.46,1.19,1,0.86,0.71,-1},
{1.29,1.13,1.00,0.91,0.82,-1},
{1.42,1.17,1,0.86,0.70,-1},
{1.21,1.10,1,0.90,-1,-1},
{1.14,1.07,1,0.95,-1,-1},
{1.24,1.10,1.00,0.91,0.82,-1},
{1.24,1.10,1,0.91,0.83,-1},
{1.23,1.08,1,1.04,1.10,-1}
};
system("cls");
printf("\nEnter the size of project : ");
scanf("%d",&size);
if(size>=2 && size<=50)
model=0;
else if(size>50 && size<=300)
model=1;
else if(size>300)
model=2;
printf("\nMode = %s",mode[model]);
EAF=1;
for(i=0;i<15;i++)
{
do
{
printf("\nRate cost driver %s on scale of 0-5 : ",driver[i]);
printf("\n0-Very Low\t1-Low\t2-Nominal\t3-High\t4-Very
High\t5-Extra High\n");
 26

scanf("%d",&rating);
a=costdrivers[i][rating];
if(a==-1)
{
printf("\nNo value exist for this rating..Enter another
rating...\n");
}
}while(a==-1);
if(rating!=2)
{
EAF=EAF*a;
}
}
printf("\nEAF = %f",EAF);
effort=(table[model][0]*pow(size,table[model][1])) * EAF;
time=table[model][2]*pow(effort,table[model][3]);
printf("\n\nEffort = %f Person-Month",effort);
printf("\nDevelopment Time = %f Months",time);
return 0;
}

3. Detailed Mode

#include<stdio.h>
#include<conio.h>
#include<math.h>
int main()
{
float table[3][4]={3.2,1.05,2.5,0.38,3.0,1.12,2.5,0.35,2.8,1.20,2.5,0.32};
int i,j,size,model,rating,size1,S;
 27

char mode[][15]={"Organic","Semi-Detached","Embedded"};
char model1[5][25]={"Plan & Requirements","System
Design","Detailed Design",
"Module code & test","Integration & test"};
char
driver[15][6]={"RELY","DATA","CPLX","TIME","STOR","VIRT","TURN",
"ACAP","AEXP","PCAP",
"VEXP","LEXP","MODP","TOOL","SCED"};
float effort,a,time,EAF;
float lifecyclephasemu[6][5]={
{0.06,0.16,0.26,0.42,0.16},
{0.06,0.16,0.24,0.38,0.22},
{0.07,0.17,0.25,0.33,0.25},
{0.07,0.17,0.24,0.31,0.28},
{0.08,0.18,0.25,0.26,0.31},
{0.08,0.18,0.24,0.24,0.34},
};
float lifecyclephasetp[6][5]={
{0.10,0.19,0.24,0.39,0.18},
{0.12,0.19,0.21,0.34,0.26},
{0.20,0.26,0.21,0.27,0.26},
{0.22,0.27,0.19,0.25,0.29},
{0.36,0.36,0.18,0.18,0.28},
{0.40,0.38,0.16,0.16,0.30},
};
float costdrivers[15][6]={
{0.75,0.88,1,1.15,1.40,-1},
{-1,0.94,1,1.08,1.16,-1},
{0.70,0.85,1,1.15,1.30,1.65},
 28

{-1,-1,1,1.11,1.30,1.66},
{-1,-1,1,1.06,1.21,1.56},
{-1,0.87,1,1.15,1.30,-1},
{-1,0.87,1,1.07,1.15,-1},
{1.46,1.19,1,0.86,0.71,-1},
{1.29,1.13,1.00,0.91,0.82,-1},
{1.42,1.17,1,0.86,0.70,-1},
{1.21,1.10,1,0.90,-1,-1},
{1.14,1.07,1,0.95,-1,-1},
{1.24,1.10,1.00,0.91,0.82,-1},
{1.24,1.10,1,0.91,0.83,-1},
{1.23,1.08,1,1.04,1.10,-1}
};
system("cls");
printf("\nEnter the size of project : ");
scanf("%d",&size);
if(size>=2 && size<=50)
model=0;
else if(size>50 && size<=300)
model=1;
else if(size>300)
model=2;
printf("\nMode = %s",mode[model]);
EAF=1;
for(i=0;i<15;i++)
{
do
{
printf("\nRate cost driver %s on scale of 0-5 : ",driver[i]);
 29

printf("\n0-Very Low\t1-Low\t2-Nominal\t3-High\t4-Very
High\t5-Extra High\n");
scanf("%d",&rating);
a=costdrivers[i][rating];
if(a==-1)
{
printf("\nNo value exist for this rating..Enter another
rating...\n");
}
}while(a==-1);
if(rating!=2)
{
EAF=EAF*a;
}
}
printf("EAF : %f",EAF);
effort=(table[model][0]*pow(size,table[model][1])) * EAF;
time=table[model][2]*pow(effort,table[model][3]);
printf("\nEffort : %f",effort);
printf("\nDevelopment time : %f",time);
printf("\n\nEnter the size equivalent : ");
scanf("%d",&S);
if(S<=26)
{
printf("\nModel : 'Organic Small'");
printf("\nPhase wise effort distribution is : ");
for(i=0;i<5;i++)
{
printf("\n%s = %f PM",model1[i],effort*lifecyclephasemu[0][i]);
 30

}
}
else if(S>26&&S<=50)
{
printf("\nModel : 'Organic Medium'");
printf("\nPhase wise effort distribution is : ");
for(i=0;i<5;i++)
{
printf("\n%s = %f PM",model1[i],effort*lifecyclephasemu[1][i]);
}
}
else if(S>50&&S<=175)
{
printf("\nModel : 'Semidetached Medium'");
printf("\nPhase wise effort distribution is : ");
for(i=0;i<5;i++)
{
printf("\n%s = %f PM",model1[i],effort*lifecyclephasemu[2][i]);
}
}
else if(S>175&&S<=300)
{
printf("\nModel : 'Semidetached Large'");
printf("\nPhase wise effort distribution is : ");
for(i=0;i<5;i++)
{
printf("\n%s = %f PM",model1[i],effort*lifecyclephasemu[3][i]);
}
}
 31

else if(S>300&&S<=450)
{
printf("\nModel : 'Embedded Large'");
printf("\nPhase wise effort distribution is : ");
for(i=0;i<5;i++)
{
printf("\n%s = %f PM",model1[i],effort*lifecyclephasemu[4][i]);
}
}
else
{
printf("\nModel : 'Embedded extra large'");
printf("\nPhase wise effort distribution is : ");
for(i=0;i<5;i++)
{
printf("\n%s = %f PM",model1[i],effort*lifecyclephasemu[5][i]);
}
}
if(S<=26)
{
printf("\n\nModel : 'Organic Small'");
printf("\nPhase wise development time duration is : ");
for(i=0;i<5;i++)
{
printf("\n%s = %f M",model1[i],time*lifecyclephasetp[0][i]);
}
}
else if(S>26&&S<=50)
{
 32

printf("\nModel : 'Organic Medium'");

printf("\n\nPhase wise development time duration is : ");
for(i=0;i<5;i++)
{
printf("\n%s = %f M",model1[i],time*lifecyclephasetp[1][i]);
}
}
else if(S>50&&S<=175)
{
printf("\nModel : 'Semidetached Medium'");
printf("\n\nPhase wise development time duration is : ");
for(i=0;i<5;i++)
{
printf("\n%s = %f M",model1[i],time*lifecyclephasetp[2][i]);
}
}
else if(S>175&&S<=300)
{
printf("\nModel : 'Semidetached Large'");
printf("\n\nPhase wise development time duration is : ");
for(i=0;i<5;i++)
{
printf("\n%s = %f M",model1[i],time*lifecyclephasetp[3][i]);
}
}
else if(S>300&&S<=450)
{
printf("\nModel : 'Embedded Large'");
printf("\n\nPhase wise development time duration is : ");
 33

for(i=0;i<5;i++)
{
printf("\n%s = %f M",model1[i],time*lifecyclephasetp[4][i]);
}
}
else
{
printf("\nModel : 'Embedded extra large'");
printf("\n\nPhase wise development time duration is : ");
for(i=0;i<5;i++)
{
printf("\n%s = %f M",model1[i],time*lifecyclephasetp[5][i]);
}
}
return 0;
}

OUTPUT
1. Basic Mode

2. Intermediate Mode
34
 35

3. Detailed Mode
 36

FINDING AND LEARNING

Cocomo (Constructive Cost Model) is a regression model based on LOC, i.e number of
Lines of Code. It is a procedural cost estimate model for software projects and is often
used as a process of reliably predicting the various parameters associated with making
a project such as size, effort, cost, time, and quality.
 37

Experiment 9

Aim:
Develop test cases using boundary value analysis for the area of a triangle, factorial of
a number n.

Theory:
Boundary Value Analysis (BVA) is a black box software testing technique where test
cases are designed using boundary values. BVA is based on the single fault
assumption, also known as critical fault assumption which states that failures are rarely
the product of two or more simultaneous faults. Hence while designing the test cases for
BVA we keep all but one variable to the nominal value and allow the remaining variable
to take the extreme value.
While designing the test cases for BVA first we determine the number of input variables
in the problem. For each input variable, we then determine the range of values it can
take. Then we determine the extreme values and nominal value for each input variable.

A polygon having three sides is said to be a triangle if each and every side is smaller
than the sum of the other two sides. Based on sides, A triangle can be classified into
three categories: scalene, equilateral and isosceles triangle.
An isosceles triangle is a triangle in which its two sides are equal.
An equilateral triangle is a triangle in which all three sides are equal ,
A scalene triangle is a triangle in which no sides are equivalent to one other.
We are supposing interval [1,10[ for test cases and will generate test cases using
Boundary value analysis accordingly . Expected output can be [Scalene, Not a Triangle
, Equilateral , Isosceles Triangle]

CODE
#include <conio.h>
#include <stdio.h>
void main()
{
int a, b, c, result;
printf(" Enter the values of a, b and c : = ");
scanf("%d %d %d", &a, &b, &c);
 38

if (((a + b) > c) && ((b + c) > a) && ((c + a) > b))

{

if ((a == b) && (b == c))

printf("\n It is an Equilateral Triangle");
else if ((a == b) || (b == c) || (c == a))
printf("\n It is an isosceles Triangle");
else
printf("\n It is a Scalene Triangle");
}
else
printf("\n not a triangle");

getch();
}

OUTPUT
 39

DISCUSSION
 40

FINDING AND LEARNING

A black box software testing technique called boundary value analysis (BVA) uses
boundary values to construct test scenarios. The single fault assumption, commonly
referred to as the critical fault assumption, is the foundation of BVA and states that
breakdowns are infrequently the result of two or more simultaneous problems. As a
result, when creating the test cases for BVA, we limit all variables to their nominal
values save for one, while allowing the other to assume an extreme value.
 41

Experiment 10

Aim:
Develop program to find cyclomatic complexity using dd path for problems like root of
quadratic equation

Theory:
A code section's cyclomatic complexity is a quantitative measure of the number of
linearly independent routes in it. It is a software statistic that is used to determine the
complexity of a programme. It is calculated using the program's Control Flow Graph.
The nodes in the graph represent the smallest collection of commands in a programme,
and a directed edge links the two nodes, indicating that the second command may
immediately follow the first.

CODE
#include<bits/stdc++.h>
using namespace std;
int main()
{
int a,b,c,validInput=0,d;
double D;
cout<<"\nEnter the 'a' value : ";
cin>>a;
cout<<"Enter the 'b' value : ";
cin>>b;
cout<<"Enter the 'c' value : ";
cin>>c;
if((a>=0) && (a<=100)&&(b>=0) && (b<=100)&&(c>=0) && (c<=100))
{
validInput=1;
if(a==0)
validInput=-1;
}
 42

if(validInput==1)
{
d = b*b - 4*a*c;
if(d == 0)
{
cout<<"\nRoots are equal and are r1 = r2 = "<<(-b)/(2*(float)a);
}
else if(d > 0)
{
D = sqrt(d);
cout<<"\nThe roots are real and are r1 = "<<(-b-D)/(2*a)<<" and
"<<(-b+D)/(2*a);
}
else
{
D = sqrt(-d) / (2*a);
cout<<"\nThe roots are imaginary and are r1 =
("<<-b/(2*a)<<","<<D<<") and r2 = ("<<-b/(2*a)<<","<<-D<<")";
}
}
else if(validInput==-1)
{
cout<<"\nThe values do not constitute a quadratic equation.";
}
else
{
cout<<"\nThe inputs belongs to invalid range.";
}
return 0;
 43

OUTPUT

PROGRAM FLOW
 44

DD GRAPH
 45

MAPPING TABLE FOR DD GRAPH

Cyclomatic Complexity
In the above DD Path Graph, we can find
Number of Nodes (n) = 19
Number of Edges (e) = 24
Number of Connected Components (P) = 1
(i) V(G) = e – n + 2P = 24 – 19 + 2 = 7
(ii) V(G) = Π + 1 = 6 + 1 = 7 (where Π is the number of predicate nodes contained in the
graph G)
(iii) V(G) = Number of Regions = 7
Therefore, there are 7 independent paths. They are:
1. ABGOQRS
2. ABCDEFG OQRS
3. ABGHIJNRS
4. ABG HIKERS
5. ABGOPRS
6. ABCDEFG OPRS
7. ABGHIKLNRS

DISCUSSION
 46

Cyclomatic complexity is useful for establishing separate route executions,

which has shown to be highly useful for developers and testers. It can
verify that each path has been checked at least once.
As a result, it is possible to concentrate more on unexplored pathways.
It is possible to enhance code coverage.
The risk connected with the programme can be assessed.
The adoption of these measures earlier in the programme helps to reduce
risks.

FINDING AND LEARNING

After generating DD Path, We calculate cyclomatic complexity which represents
the number of possible paths. After calculating cyclomatic complexity,
generate independent paths. And the last step is to formulate test cases
based on the calculated independent paths.
 47

Experiment 11
Aim:
Develop equivalence class test cases for classification of a triangle and calculating
weekdays for a given date and next date.

Theory:
Equivalence Class Testing
In this method, the input domain of a program is partitioned into a finite number of
equivalence classes such that one can reasonably assume, but not be absolutely
sure, that the test of a representative value of each class is equivalent to a test of
any other value.
Two steps are required to implementing this method-
1. The equivalence classes are identified by taking each input condition and
partitioning it into valid and invalid classes. For example, if an input
condition specifies a range of values from 1 to 999, we identify one valid
equivalence class [1<item<999]; and two invalid equivalence classes
[item<1] and [item>999].

2. Generate the test cases using the equivalence classes identified in the
previous step. This is performed by writing test cases covering all the valid
equivalence classes. Then a test case is written for each invalid equivalence
class so that no test contains more than one invalid class. This is to ensure
that no two invalid classes mask each other.
Most of the time, equivalence class testing defines classes of the input domain.
However, equivalence classes should also be defined for the output domain. Hence,
we should design equivalence classes based on input and output domains.

1. CLASSIFICATION OF A TRIANGLE

Output domain test cases-

Test Case Number x y z Expected Output

1 50 50 50 equilateral

2 50 99 100 scalene
 48

3 99 50 50 isosceles

4 1 50 100 not a triangle

Input domain test cases-

Test Case Number x y z Expected Output

1 0 50 50 invalid input

2 50 50 50 equilateral

3 101 50 50 invalid input

4 50 50 0 invalid input

5 50 50 50 equilateral

6 50 50 101 invalid input

7 50 0 50 invalid input

8 50 50 50 equilateral

9 50 101 50 invalid input

10 30 30 30 equilateral

11 30 30 45 isosceles

12 30 35 40 scalene
 49

13 30 35 35 isosceles

14 30 35 30 isosceles

15 30 25 55 not a triangle

16 30 55 25 not a triangle

17 55 30 25 not a triangle

18 90 25 40 not a triangle

19 25 40 90 not a triangle

20 40 90 25 not a triangle

1. CALCULATING WEEKDAYS FOR A GIVEN DATE AND NEXT DATE

Output domain test cases

Test Case Number M D Y Expected Output

1 6 15 1962 14th June, 1962

2 6 31 1962 Invalid Date

Input domain test cases

Test Case Number M D Y Expected Output

 50

1 6 15 1962 14th June, 1962

2 -1 15 1962 Invalid Date

3 13 15 1962 Invalid Date

4 6 15 1962 14th June, 1962

5 6 -1 1962 Invalid Date

6 6 32 1962 Invalid Date

7 6 15 1962 14th June, 1962

8 6 15 1899 Invalid input (Value out of range)

9 6 15 2026 Invalid input (Value out of range)

DISCUSSION
Strongly typed implementation language; no need for robust forms.
ECT is useful for specific types of data input. The next date function
problem exemplifies how complex functions can aid in the identification of
useful EC.
It is possible that many efforts will be required.

FINDING AND LEARNING

Boundary value testing is improved by Equivalence Class Testing. The
Equivalence Relationship is critical for developing relevant test cases.
Equivalence Class Testing is a viable option.
 51

Experiment 12

Aim:
Program to predict reliability metric using different models.

Theory:
A software reliability model indicates the form of a random process that defines the
behavior of software failures to time.

Software reliability models have appeared as people try to understand the features of
how and why software fails, and attempt to quantify software reliability.

Over 200 models have been established since the early 1970s, but how to quantify
software reliability remains mostly unsolved.

There is no individual model that can be used in all situations. No model is complete or
even representative.

Most software models contain the following parts:

● Assumptions

● Factors

A mathematical function that includes the reliability of the elements. The mathematical
function is generally higher-order exponential or logarithmic.

A reliability growth model is a numerical model of software reliability, which predicts how
software reliability should improve over time as errors are discovered and repaired.
These models help the manager in deciding how much effort should be devoted to
testing. The objective of the project manager is to test and debug the system until the
required level of reliability is reached.

Following are the Software Reliability Models are:

● Basic Execution Time Model
● Logarithmic Poisson Time Model
 52

CODE
#include <bits/stdc++.h>

using namespace std;

int main()
{
float choice, fi1, fi2, ef1, ef2, fit1, fidp, et1, et2;
cout << "Implement\n1.Basic Execution Time Model\n2.Logarithmic
Poisson Execution Time Model\n\nEnter choice : ";
cin >> choice;
if (choice == 1)
{
cout << "Enter failure intensity at the start of execution\n";
cin >> fi1;
cout << "Enter expected number of failures experienced\n";
cin >> ef1;
cout << "Enter number of failures that occur in infinite time\n";
cin >> fit1;
cout << "Enter execution time\n";
cin >> et1;
cout << "Current Failure Intensity:" << (fi1 * (1 - (ef1 / fit1))) <<
endl;
cout << "Slope of failure intensity function:" << -fi1 / fit1 << endl;
cout << "No of failures at execution time:" << fit1 * (1 - exp(-(fi1 *
et1) / fit1)) << endl;
cout << "Failure intensity at execution time:" << fi1 * exp(-fi1 * et1
/ fit1) << endl;
}
else if (choice == 2)
 53

{
cout << "Enter failure intensity at the start of execution\n";
cin >> fi2;
cout << "Enter expected number of failures experienced\n";
cin >> ef2;
cout << "Enter failure intensity delay parameter\n";
cin >> fidp;
cout << "Enter execution time\n";
cin >> et2;
cout << "Current Failure Intensity:" << fi2 * exp(-fidp * ef2) <<
endl;
cout << "Slope of failure intensity function:" << -fidp * fi2 *
exp(-fidp * ef2) << endl;
cout << "No of failures at execution time:" << log((fi2 * fidp * et2)
+ 1) / fidp << endl;
cout << "Failure intensity at execution time:" << fi2 / ((fi2 * fidp *
et2) + 1) << endl;
}
else
cout << "Wrong choice\n";
return 0;
}

OUTPUT
 54

DISCUSSION
Software dependability is a crucial component of software quality and an important
study subject. Metrics for software reliability can be used to evaluate present reliability
and project future reliability. The main goal for any software industry is to achieve
software reliability. Because software tends to be complicated, achieving software
reliability can be challenging. This is due to the tool's implementation of a number of
software reliability techniques, such as complexity metrics-based techniques used in the
pre-test phase, interfailure times-based techniques used in the testing phase, and
architecture-based techniques that can be applied at all stages of the software
life-cycle.

FINDING AND LEARNING

Software reliability is an important research area and software reliability is a
key part of software quality .Software reliability metrics can be used to
assess current reliability and forecast future. For any software industry
achieving software reliability is the key task. Achieving Software reliability is
hard because the complexity of the software tends to be high. This is
because the tool implements several software reliability techniques
including complexity metrics-based techniques used in the pre-test phase,
interfailure times-based techniques used during the testing phase, and
architecture-based techniques that can be used at all stages in the
software's life-cycle.
 55

Experiment 13

Aim:
Develop a program to calculate maintenance metrics using different models

Theory:
There are two categories of maintenance key performance indicators which include the
leading and lagging indicators. The leading indicators signal future events and the
lagging indicators follow the past events. The leading indicator comprises metrics like
the Estimated vs actual performance and PM Compliance, while the lagging indicators
are reflected in maintenance metrics like the Mean Time To Repair (MTTR) , Overall
Equipment Effectiveness OEE and Mean time between failure (MTBF).

Using these maintenance metrics and turning the data into actionable information,
organizations can acquire both qualitative and quantitative insights.
And there is no better way to spot opportunities for improvement.
Here are some important maintenance metrics you should track if you want to improve
and optimize your maintenance operations.

1. Planned maintenance percentage (PPC)

This metric represents the percentage of time spent on planned maintenance activities
against the unplanned. In simpler terms, this metric tells you how much maintenance
work done on a particular asset was a part of your preventive maintenance plan versus
how much time you’ve spent repairing it because it unexpectedly broke down.
In a great system, 90% of the maintenance should be planned.
The calculation is as follows:

PPC= (scheduled maintenance time/total maintenance hours) x 100

2. Overall Equipment Effectiveness (OEE)

OEE is the measure of the productivity of a piece of equipment. It gives informed data
on how effective an organization's maintenance processes are running based on factors
like equipment quality, performance, and availability.A 100% OEE means that your
system is producing no defects, as fast as possible, and with no stops in the production.
understanding OEE and the underlying losses , organizations can gain significant
insights into how to improve their manufacturing processes. Using this metric, you can
identify what has a negative impact on your production, so you can eliminate it.
To calculate the OEE, you multiply the availability by the performance and quality :

OEE = availability x performance x quality

 56

3. Mean time to repair (MTTR)

MTTR is the measure of the repairable items maintainability. The MTTR clock starts
ticking when the repairs start and it goes on until operations are restored. This includes
repair time, testing period, and return to the normal operating condition.
The goal of every organization is to reduce MTTR as much as possible. This is
especially important for critical assets as every additional hour you need to restore an
asset to a working condition amounts to huge losses for your firm.
To calculate MTTR, you divide the downtime period by the total number of downtimes:

MTTR= (SUM of downtime periods/ total number of repairs)

4. Mean time between failure (MTBF)

MTBF is the measure of the predicted time between one breakdown to the next during
normal operation.In essence, MTBF tells you the expected lifetime for a specific piece of
equipment. Higher MTBF means that the part (or product) you bought will work longer
before it experiences failure.If you know how long a specific part/equipment will last, it
gets much easier to predict and prepare for a failure or schedule some preventive work.

To calculate the MTBF, you divide the total operational time by the number of failures:

MTBF= (SUM of operational time/total number of failures)

5. Preventive maintenance compliance (PMC)

PM compliance is defined as the percentage of the preventive work scheduled and

completed in a set time.For example, you might have 60 Work Orders (that are a part of
the PM plan) scheduled but 51 completed at the end of the month.

In this case:
PMC= (51/60) x 100 = 85%

This tells you that 85% of all preventive WO’s have been covered for selected months.
The disadvantage of this metric is that it doesn’t tell you if the WO’s have been
completed on time.That is why you need to invest some additional effort and also track
if the Work Orders are actually being finished on time.
 57

By far the best way to do that is to use a CMMS as it allows you to quickly create,
assign, and track all of your WO’s from one place.

CODE
#include <iostream>
using namespace std;
int main()
{
float smh, tmh, choice, ava, per, qual, dp, rep, op, fal, pws, pwc;
cout << "1.Planned maintenance percentage\n2.Overall Equipment
Effectiveness\n3.Mean time to repair\n4.Mean time between
failure\n5.Preventive maintenance compliance\nChoose choice\n ";
cin >>choice;
if (choice == 1)
{
cout << "Enter scheduled maintenance hours\n";
cin >> smh;
cout << "Enter total maintenance hours\n";
cin >> tmh;
cout << "Planned maintenance percentage=" << smh * 100 / tmh <<
"%\n";
}
else if (choice == 2)
{
cout << "Enter availabality,performance and quality\n";
cin >> ava >> per >> qual;
cout << "Overall Equipment Effectiveness=" << ava * per * qual <<
endl;
}
else if (choice == 3)
 58

{
cout << "Enter sum of downtime periods\n";
cin >> dp;
cout << "Enter total no.of repairs\n";
cin >> rep;
cout << "Mean time to repair=" << dp / rep;
}
else if (choice == 4)
{
cout << "Enter sum of operational time\n";
cin >> op;
cout << "Enter total no.of failures\n";
cin >> fal;
cout << "Mean time between failure=" << op / fal;
}
else if (choice == 5)
{
cout << "Enter preventive work scheduled\n";
cin >> pws;
cout << "Enter preventive work completed\n";
cin >> pwc;
cout << "Preventive maintenance compliance=" << pwc * 100 / pws
<<"%\n";
}
else
cout << "Wrong choice\n";
}

OUTPUT
 59

DISCUSSION
The traits of various programming languages can be analysed, contrasted, and
evaluated. while contrasting and assessing the skills and output of software
development teams. The productivity gains and time saved throughout a project make
the time spent setting goals, choosing metrics, and adopting regular measuring
methods worthwhile. Application performance management (APM) tools are one
example of a solution that combines several software metrics with information and
insights on application utilization, code performance, delayed requests, and more.

FINDING AND LEARNING

The benefit of these metrics is that they provide you with quantifiable data to help you
set goals and make improvements to your development process. We can analyze,
compare, and evaluate the characteristics of various programming languages. When
comparing and evaluating the capabilities and productivity of software development
teams.While creating goals, selecting metrics, and implementing consistent measuring
methods takes time, the productivity improvements and time saved throughout a project
make it time well spent.Various software metrics, as well as data and insights on
application utilization, code performance, delayed requests, and more, are combined
into solutions such as application performance management (APM) tools.