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 20

the 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.1 Introduction: 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
 56

and quality : OEE = availability x performance x quality

 57

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.
 58

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
 59

{
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
 60

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.