DEPARTMENT OF CSE
SOFTWARE ENGINEERING LAB
CO 301- Software Engineering
LAB FILE
SUBMITTED TO: -
SUBMITTED BY: -
Mr. Nikhil Sharma
Sandeep Kumar
(2K20/CO/405)
INDEX
S. No.
Objective
1.
Overview of Software Engineering
2.
Write the SRS (Software Requirement
Specification) online food ordering system
3.
To identify various elicitation techniques and
their usage for the problem.
4.
To classify the requirement into functional and
non-functional requirements.
5.
6.
7.
8.
9.
10.
To perform the Requirement analysis of the
specified problem and draw a flowchart.
Draw the ER Diagram with generalization,
specialization and aggregation of a specified
problem statement.
Draw different levels of DFD for a specified
problem statement.
Convert DFD for a specified problem to
structure chart.
Draw Use case diagram for the specified
problem.
Estimate the Project Metrics using all COCOMO
models.
Date
Sign
EXPERIMENT-1
Aim: - Overview of Software Engineering
Introduction: -
✓ What is Software Engineering?
The application of a systematic, disciplined, quantifiable approach to the development, operation,
and maintenance of software; that is, the application of engineering to software. It is the
establishment and use of sound engineering principles in order to obtain economic software thatis
reliable and works efficiently on real machines. It is an engineering branch associated with
analyzing user requirements, design, development, testing, and maintenance of software products.
✓ Principles of Software Engineering
The principles of software engineering are: •
•
•
•
•
•
•
•
•
•
•
•
One of the basic software Engineering principles is Better Requirement analysis which gives a
clear vision of the project. At last, a good understanding of user requirements provides value to
its users by delivering a good software product that meets users’ requirements.
All designs and implementations should be as simple as possible mean the KISS (Keep it
Simple, Stupid) principle should be followed. It makes code so simple as a result debugging
and further maintenance become simple.
Maintaining the vision of the project is the most important thing throughout complete
development process for the success of a software project. A clear vision of the project leads to
the development of the project in the right way.
Software projects include a number of functionalities, all functionalities should be developed
in a modular approach so that development will be faster and easier. This modularity makes
functions or system components independent.
Another specialization of the principle of separation of concerns is Abstraction for suppressing
complex things and delivering simplicity to the customer/user means it gives what the actual
user needs and hides unnecessary things.
Think then Act is a must-required principle for software engineering means before starting
developing functionality first it requires to think about application architecture, as good
planning on the flow of project development produces better results.
Sometimes developer adds up all functionalities together but later find no use of that. So,
following the Never add extra principle is important as it implements what actually needed and
later implements what are required which saves effort and time.
When other developers work with another’s code they should not be surprised and should not
waste their time in getting code. So, providing better documentation at required steps is a good
way of developing software projects.
Law of Demeter should be followed as it makes classes independent on their functionalities and
reduces connections and inter dependability between classes which is called coupling.
Principle of Consistency is important in coding style and designing GUI (Graphical User
Interface) as consistent coding style gives an easier reading of code and consistency in GUI
makes user learning easier in dealing with interface and in using the software.
Performing continuous validation helps in checking software system meets requirement
specifications and fulfils its intended purpose which helps in better software quality control.
Scalability in Software Engineering should be maintained to grow and manage increased
demand for software applications.
✓ Characteristics of Software Engineering
The characteristics of software engineering are: •
•
•
•
•
•
The functionality of software refers to its ability to perform and function according to design
specification.
The user-friendliness of the software is characterized by its ease of use. In other words, learning
how to use the software should require less effort or time.
Efficiency refers to the software’s ability to utilize human and system resources such as time,
effort, CPU, memory, computation power, network bandwidth, files, databases, etc., as
effectively and efficiently as possible.
Software Flexibility refers to the ability of the software solution to adapt to potential or future
changes in its requirements. When evaluating the flexibility of software, look at how simple it
is to add, modify, or remove features without interfering with the current operation.
The reliability of a software product describes the likelihood it will operate without failure over
a specified period of time under certain conditions. It determines the ability of software to
maintain its level of performance under specified conditions.
Maintainability refers to how easily you can repair, improve and comprehend software code.
Apart from it the characteristics that differ from hardware are as follows:
•
•
•
Software is developed or engineered; it is not manufactured in the classical sense.
The software doesn’t “wear out”.
The software continues to be custom-built.
✓ Components of Software Engineering
The components of software engineering are: •
•
•
Program - A computer program is a list of instructions that tell a computer what to do.
Documentation - Source information about the product contained in design documents, detailed
code comments, etc.
Operating Procedures - Set of step-by-step instructions compiled by an organization to help
workers carry out complex routine operations.
✓ Applications of Software Engineering
Following are the applications of software engineering: •
•
•
•
•
System software - a collection of programs written to service other programs. Some system
software (e.g., compilers, editors, and file management utilities) processes complex, but
determinate, information structures.
Application software - stand-alone programs that solve a specific business need. Applications
in this area process business or technical data in a way that facilitates business operations or
management.
Engineering/scientific software - has been characterized by “number crunching” algorithms.
Applications range from astronomy to volcanology, from automotive stress analysis to space
shuttle orbital dynamics, and from molecular biology to automated manufacturing.
Embedded software - resides within a product or system and is used to implement and control
features and functions for the end user and for the system itself.
Web applications - called “Web Apps,” this network-centric software category spans a wide
array of applications. In their simplest form, Web Apps can be little more than a set of linked
hypertext files that present information using text and limited graphics.
•
•
Artificial intelligence software - makes use of non-numerical algorithms to solve complex
problems that are not amenable to computation or straightforward analysis. Applications within
this area include robotics, expert systems, pattern recognition etc.
Product-line software - designed to provide a specific capability for use by many different
customers. Product-line software can focus on a limited and esoteric marketplace (e.g.,
inventory control products).
✓ Tools to design SRS – Software Requirement Specification
Following are the tools used to design SRS: •
Jira - Although Jira is primarily a product management tool, it also includes requirements
management. Mostly used by Agile teams, Jira helps configure your requirements, facilitates
test case traceability process, and allows for collaboration with sharing, watching, and
commenting features.
•
Perforce Helix RM - A stand-alone module in Perforce’s Application Lifecycle Management
suite, Helix RM is a useful tool for large, distributed teams. Its key features are requirements
traceability, graphical tools, scalability, real-time collaboration features, impact analysis tools,
and test case management, file history graphs, and even a time-lapse tool to visualize an item’s
progress over time. Helix RM integrates well with Jira, various Microsoft products, Slack,
Eclipse, GitHub, Go2Group, Rational DOORS, and OpsHub. The tool has quite a steep learning
curve, so it’s accompanied by video tutorials, training, and a knowledge base.
•
Pearls - Once you’ve defined your use cases, actors, conditions, and flows, Pearls allows you
to generate a requirements specification document with a single click. The tool has strong team
collaboration features like comments and notifications about member activity, features for
defining project goals, and managing stakeholders.
•
Reqchecker - It’s a simple tool for checking requirements coverage. Often used as an added
level of assurance, Reqchecker’s traceability analysis makes sure requirements and tests are
covered. Importing Word, pdf, Excel, PowerPoint, or XML files into Reqchecker, you can turn
them into requirements.
•
Rational Rose - Rational Rose is an object-oriented Unified Modeling Language (UML)
software design tool intended for visual modeling and component construction of enterpriselevel software applications. Rational Rose documents the diagram as it is being constructed and
then generates code in the designer's choice of DDL.
EXPERIMENT-2
Aim: - Write the SRS (Software Requirement Specification) for the online food Ordering System.
Problem Statement: The technology we recommend is an easy-to-use online meal ordering system
for customers. It overcomes the disadvantages of traditional queueing systems. Our system is both a
convenient way to order food from restaurants and a mess service. The procedure of taking a customer's
order is made easier with this technology. Customers may place orders fast utilizing the online meal
ordering system, which generates an online menu. Customers can also use a meal menu to keep track
of their orders. Users can also rate the food goods using this system's feedback feature. In addition,
based on the user's ratings, the proposed system can recommend hotels and meals, and the hotel staff
will be notified of any quality adjustments.
Getting so many orders
at a specific period of
time is not easy to
manage
Frequent updates in the
details of the order
Updates, are quite
change
hectic
Standing in queue or go
outside to order the food is
quit time consuming which
is not worth it.
An efficient, secure and easy to
use software is needed to manage
and record customer’s details
SRS:
The software should:
•
•
•
•
•
•
•
•
Allow the customers: to create their accounts, to maintain theirpersonal details, past
Orders are taken, current Orders etc.
Search and navigation: The customers can search and browse the restaurants on the food ordering app
& website and view their details.
Geo fencing: By fetching their current location, the customers can even view their nearby restaurants
or food stores and order food locally for themselves. These can be viewed both in map & list view.
Sorting and filtering: Searching can be made simpler through the options of sorting and filtering for
restaurants and products.
Ratings and reviews: For every order, the customers can rate the restaurant and the delivery driver and
also, write reviews for them.
Schedule orders: What if the customer is not planning to order something immediately? Not an issue,
with the schedule feature, the customers can have it delivered anytime.
Social media sharing: The options to share the food experience can be achieved through social media
like Facebook or WhatsApp, where customers can share the links to the products directly from the food
ordering app.
Favorite Restaurants: The access to the favorite restaurants is much more easier when customers mark
a restaurant as favorite and just browse the favorites list to place an order from a restaurant.
diagram:
EXPERIMENT-3
Aim: - To identify various elicitation techniques and their usage for the problem.
Introduction: Every programmer should have a rigorous and accurate approach for gathering requirements. The
following tasks are aided by this:
•
•
•
•
preserving the continuity of the requirements
preventing conflicts between requirements
ensuring the viability of needs
maintaining the requirements' correctness
Elicitation methods used: Following are the elicitation methods used in my problem statement: -
➢ Interviews
The purpose of an interview is to learn what the customer expects from the programme. Since it is not
possible to speak with all of the stakeholders, representatives from different groups are chosen based
on their experience and reputation. Interviews maybe be open-ended or structured. In my problem
statement, I have interviewed my family members and friends to understand what use cases they desire
from the software.
➢ Brainstorming Sessions
It is a group strategy to provide a forum for people to express their opinions and is designed to spark
many fresh ideas. To manage group bias and group conflicts, a highly skilled facilitator is needed. In
brainstorming sessions, every concept is recorded for everyone to see. The list of needs and, if possible,
their priority is then put together in a paper. In my problem statement, I have referred some YouTube
videos of some brainstorming sessions to understand what use cases I should consider.
➢ Facilitated Application Specification Technique (FAST)
Its goal is to close the expectation gap, or the discrepancy between what customers want and what
developers believe they should build. The requirements-gathering process is designed using a teamoriented approach.
Each attendee is asked to make a list of objects that are• Part of the environment that surrounds the system
• Produced by the system
• Used by the system
Each participant makes a list, which is integrated with other lists and superfluous items are removed.
The team is then divided into smaller sub-teams to generate mini-specifications, and eventually a
draught of the specifications is written incorporating all of the meeting's contributions.
➢ Quality Function Deployment
This method places a strong emphasis on the needs that are important to the consumer because it places
it as its top priority. It has 3 types of requirements: -
•
•
•
Normal requirements – In this the objective and goals of the proposed software are discussed with
the customer. Example – normal requirements for a result management system may be entry of
marks, calculation of results, etc
Expected requirements – These requirements are so obvious that the customer need not explicitly
state them. Example – protection from unauthorized access.
Exciting requirements – It includes features that are beyond customer’s expectations and prove to
be very satisfying when present. Example – when unauthorized access is detected, it should backup
and shutdown all processes.
The major steps involved in this procedure are –
• Identify all the stakeholders, e.g., Users, developers, customers etc
• List out all requirements from customer.
• A value indicating degree of importance is assigned to each requirement.
• In the end the final list of requirements is categorized as –is possible to achieve, should be deferred
and the reason for it, is impossible to achieve and should be dropped off.
➢ Use Case Approach
This method mixes text and images to make the criteria easier to understand. The use cases explain the
"what," not the "how," of a technology. Hence, they only give a functional view of the system. Actor,
use cases, and Use Case Diagram are the three main components of the use case design.
•
•
•
Actor - It is the external agent that is not a part of the system but nevertheless engages with it. An
actor could be a machine, a person, etc. It's depicted as a stick person. customer, Admin, and
company staff are the actors involved in my problem statement.
Use Cases - They outline the order of the system's actors' interactions. They record what people
(actors) do as they interact with the system. Creating accounts, placing order, getting order details,
getting customer details, and logging in the users are the actors involved in my problem statement.
Use Case diagram - The events that take place when an actor interacts with a system are graphically
depicted in a use case diagram. It captures the system's functionality.
EXPERIMENT-4
Aim: - To classify the requirement into functional and non-functional requirements.
Introduction: Requirements analysis is very critical process that enables the success of a system or software project
to be assessed.
Requirements are generally split into two types:
❖ Functional requirements: These are the requirements that the end user specifically demands as
basic facilities that the system should offer. All these functionalities need to be necessarily
incorporated into the system as a part of the contract.
The following are the functional requirements involved in my problem statement: •
Authentication: - The system should be able to authenticate the user whenever he/she logs
in. The system should allow the user to enter the user id and password for the purpose of login
and cross-verifying across the login DB. Also, customers should be able to create a new account.
On authentication, the system should provide different facilities depending upon the type of
user whether it is a customer /company staff.
• Navigate the restaurant’s menu:- System should provide a list of possible food items
matching the criterion of user inputs. Customers should be able to search for food for a specific
category. Customers should be able to specify the cooking instructions whileordering for a
meal.
• Place Order – The system should allow customer to place the order of his choice for a
maximum of 15 itmes at a time. It should demand customer to provide his/her full name and
locations access to place order. It should demand customer to choose the payment method. It
should be able to process the payments done by the customer. In case of payment failed, it
should be able to refund the amount to costomers’s bank account in case amount deducted.
Also, customer should be able to download the payemt reciept.
• Receive confirmation in the form of an order number.- System should be able to provide
all the details ofthe authenticated costomer. It should be able to provide the details of past and
current orders.It should allow to cancel the ordered mealsor change the ordered meal. Customer
should be able to see given response to cancellation request. Customers should be able see
unique ordered number.
• Access and Update employee details: - System should be able to provide all the details of
the authenticated employee. Employee should be able to update their details to the database.
• Create, modify and delete accounts: - System should allow admin to create new accounts
for admin and company employees. It should allow admin to delete and modify details of a
particular account.
❖ Non-functional requirements: These are basically the quality constraints that the system must
satisfy according to the project contract. The priority or extent to which these factors are
implemented varies from one project to other.
Following are the non-functional requirements involved in my problem statement: -
•
Security: - After a certain amount of inactivity, the system must automatically log out all
customers. The system shouldn't save any cookies revealing the user's password on the
customer's computer. Only authorised management shall have access to the system's back-end
servers.
•
Reliability: - The dependability of the individual components determines the reliability of the
project as a whole. The database backup, which is continuously updated to reflect the most
recent changes, is the primary tenet of the system's dependability. Therefore, the stability of the
container and its underlying OS determines the system's overall stability.
•
Availability: - The system ought to be accessible at all times via a web browser, with the only
exception being downtime for the server on which it is hosted. A user-friendly system that is
accessible to people all around the world should be available around-the-clock. The organiser
should retrieve and save database backups from the server in case of hardware failure or
database damage. After that, the service will restart. It denotes availability every single day.
•
Maintainability: - The system will be reinstalled in the event of a failure. Additionally,
modularity is taken into consideration during the software design process to facilitate effective
maintenance.
• Supportability: - The system's supporting modules and code will be clear and thoroughly
documented. Requirements for the Help system and online user documentation will be given.
EXPERIMENT-5
Aim: - To perform the Requirement analysis of the specified problem and draw a flowchart.
Introduction: Software requirement analysis is the process of thoroughly studying, analysing, and describing software
requirements with the goal of understanding the precise needs of the customer and properly
documenting those needs in order to solve problems. Requirements analysis is very critical process that
enables the success of a system or software project to be assessed.
General users (or customers) have access to the following features •
•
•
•
•
•
By registering on the platform, a user can join.
Information about various meals available.
Users can place an order.
Users can view their placed order and download the payment receipt.
Users can view and update their location of delivery.
Users can explore various meals depending on price and availability.
Company Employees have access to the following features •
•
•
Company Employees can view and update their personal details.
Company Employees can add and remove meals depending upon the availability of food items.
Company Employees can view any customer’s details.
A task that the Administrator can perform •
•
Administrator can create, modify and delete any account.
Specifically, Employees’s accounts are being created by administrator to limit the special
features to employee only.
Flow chart: -
EXPERIMENT-6
Aim: - Draw the ER Diagram with generalization, specialization and aggregation of a specified
problem statement.
Introduction: Generalization, Specialization ,and Aggregation in ER model are used for data abstraction in which an
abstraction mechanism is used to hide details of a set of objects.
• Generalization Generalization is the process of extracting common properties from a set of entities and create a
generalized entity from it. It is a bottom-up approach in which two or more entities can be generalized
to a higher-level entity if they have some attributes in common.
email
addre
s
id
name
phon
e
user
role
Employee
Admin
• Specialization In specialization, an entity is divided into sub-entities based on their characteristics. It is a top-down
approach where higher level entity is specialized into two or more lower-level entities.
email
addre
s
id
name
phon
e
user
role
Employee
Admin
•
Aggregation –
An ER diagram is not capable of representing relationship between an entity and a relationship which
may be required in some scenarios. In those cases, a relationship with its corresponding entities is
aggregated into a higher-level entity. Aggregation is an abstraction through which we can represent
relationships as higher level entity sets.
Enquiry handle
costomer
Restaurant
Placed order
EXPERIMENT-7
Aim: - Draw different levels of DFD for a specified problem statement.
Introduction: 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. Data flow diagrams can range from simple, even handdrawn process overviews, to in-depth, multi-level DFDs that dig progressively deeper into how the data
is handled.
• Level-0 DFD: DFD Level 0 is also called a Context Diagram. It’s a basic overview of the whole
system or process being analyzed or modeled. It’s designed to be an at-a-glance view, showing the
system as a single high-level process, with its relationship to external entities. It should be easily
understood by a wide audience, including stakeholders, business analysts, data analysts and
developers.
• Level-1 DFD: DFD Level 1 provides a more detailed breakout of pieces of the Context Level
Diagram. You will highlight the main functions carried out by the system, as you break down the
high-level process of the Context Diagram into its subprocesses.
EXPERIMENT-8
Aim: - Convert DFD for a specified problem to structure chart.
Introduction: The structure Chart represents the hierarchical structure of modules. It breaks down the entire system into
the lowestfunctional modules, and describe functions and sub-functions of each module of a system to
greater detail.Structure Chart partitions the system into black boxes (functionality of the system is known
to the usersbut inner details are unknown). Inputs are given to the black boxes and appropriate outputs
are generated.
Enter Login
Details
Login
Database
Login details
are passed
Verify Login
Details
Load
Account
View
Dashboard
Create, modify and
delete accounts
Account details are
passed and account is
created and updated
View costumer
details
View Employee
Details
Updated staff details is
passed and details are
updated
Return account
details
Account
Database
Current order
Return staff
details
Place order
Status of
order
Return costumer
details
details
order details are
passed
Payment
Add transaction
Staff
costumer
Database
Database
Return order
details
ordered
Database
Transaction
Database
EXPERIMENT-9
Aim: - Draw Use case diagram for the specified problem.
Introduction: The Use Case Diagram is a UML Diagram where each use-case specifies the behaviour expected from
software from the perspective of end-user and relation as well as provides brief overview for different
components concerning interaction between use-case, actors and systems.
The Use-Case Diagram is used to prepare, present and understand functional requirements of the
system. Use-Case Diagram specifies exact context of the software being developed. It does not specify
order in which actions must be performed. Each use-case represents function of system which is either
process-automated or manual. system. Actor, use cases, and Use Case Diagram are the three main
components of the use case design.
•
Actor - It is the external agent that is not a part of the system but nevertheless engages with it. An
actor could be a machine, a person, etc. It's depicted as a stick person. Costumer, Admin, and
restaurant staff are the actors involved in my problem statement.
•
Use Cases - They outline the order of the system's actors' interactions. They record what people
(actors) do as they interact with the system. The following are the use cases: ✓ Authentication: The system should be able to authenticate the user whenever he/she logs in.
The system should allow the user to enter the user id and password for the purpose of login and
cross-verifying across the login DB. Also, the customer should be able to create a new account.
Onauthentication, the system should provide different facilities depending upon the type of user
whether it is costumer//admin/restaurant staff. Administrators, costumer, and restaurant staff
are the actors involved.
✓ Access order details: The system should provide a list of possible orders matching the criterion
of user inputs. Customers should be able to search for meals for a specific category. Customers
should be able to specify the price tags while searching for a meal. The company’s employee
and delivery person are the actors involved.
✓ Place an order: System should allow the customer to place the order of his choice for a
maximum of 10 people at a time. It should demand the customer to provide his/her full name and
location access to place an order. It should demand customers choose the payment method. It
should be able to process the payments done by the customer. In case of payment failed, it
should be able to refund the amount to the customer’s bank account in case the amount is
deducted. Also, the customer should be able to download the payment receipt.
✓ Cancel and replace order: The system should be able to provide all the details of the
authenticated Customer. It should be able to provide the feature of canceling the order for
a specific duration of time. It should also allow for the replacement of the ordered meal,
change the delivery location, etc.
✓ Access and Update Employee details: The system should be able to provide all the details of
the authenticated employee. Employees should be able to update their details in the database.
The company’s employee is the actor involved.
✓ Create, modify and delete accounts: The system should allow the admin to create new accounts
for the admin and the company’s employees. It should allow the admin to delete and modify
the details of a particular account. The administrator is the actor involved.
•
Use Case diagram - The events that take place when an actor interacts with a system are graphically
depicted in a use case diagram. It captures the system's functionality.
EXPERIMENT-10
Aim: - Estimate the Project Metrics using all COCOMO models.
Introduction: COCOMO is one of the most generally used software estimation models in the world. COCOMO
predicts the efforts and schedule of a software product based on the size of the software.
The necessary steps in this model are:
•
•
•
•
Get an initial estimate of the development effort from the evaluation of thousands of delivered lines
of source code (KLOC).
Determine a set of 15 multiplying factors from various attributes of the project.
Calculate the effort estimate by multiplying the initial estimate with all the multiplying factors i.e.,
multiply the values in step1 and step2.
The initial estimate (also called nominal estimate) is determined by an equation of the form used in
the static single variable models, using KLOC as the measure of the size. To determine the initial
effort Ei in person-months the equation used is of the type is shown below
Ei=a*(KLOC)b
The value of the constants a and b are depended on the project type.
Code: #include<bits/stdc++.h>
using namespace std;
int fround(float x)
{
int a;
x = x + 0.5;
a = x;
return (a);
}
void calculate(float table[][4], int n, string mode[], int size)
{
float effort, time, staff;
int model;
if (size >= 2 && size <= 50)
model = 0;
else if (size > 50 && size <= 300)
model = 1;
else if (size > 300)
model = 2;
effort = table[model][0] * pow(size, table[model][1]);
time = table[model][2] * pow(effort, table[model][3]);
staff = effort / time;
cout<<"The mode is "<<mode[model];
cout<<"\nEffort = "<<effort<<" Person-Month";
cout<<"\nDevelopment Time = "<<time<<" Months";
cout<<"\nAverage Staff Required = "<<fround(staff)<<" Persons";
}
int main()
{
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};
string mode[] = {"Organic", "Semi-Detached", "Embedded"};
int size = 4;
calculate(table, 3, mode, size);
return 0;
}
Output: -