NEOTECH INSTITUTE OF TECHNOLOGY

LAB MANUAL

FOR

Software engineering

(3150711)

BE 5TH SEM

COMPUTER ENGINEERING

NEOTECH INSTITUTE OF TECHNOLOGY

 CERTIFICATE

This is to certify that

Trushan
Mithil Mali
Patel
Mr. / Ms. …..………………………………………………..........
201170107508
201170107001
……………………with enrollment no………………………..Has
successfully completed his / her laboratory experiments in the subject
Software Engineering
Engineering -- 3150711
(with code)…………………………………………………from 3150711 the
Computer Engineering
Computer (BE)
Engineering (BE)
department of………………………………………………...during
2021 - 22
2022-23
the academic year……………….

Date of Submission : ………… Staff in Charge : …………….

 Tutorial-1
SDLC PHASES
❖ Ecommerce website Recommendation Software Based On & Php and mysql
database.

1.Communication
▪ We will communicate with client regarding what type of software looking for
web app/website. It will give us broad idea about client’s needs so that we can
have a perfect objective in front of us.

▪ First we start with budget so that we can develop a software in particular that
budget.

▪ Second is come up with application/website name, funky name sounds

appealing to customers.

▪ Third is design we want to know what type of design client wants so futuristic or
fluent or material. Since it varies from system to system.

▪ Then for networking what type of cloud server client is looking for AWS or
Azure.

▪ What type of server configuration & data storage (HDD, SSD, NVMe) client
needs?

▪ What type of security client wants i.e. what type of encryption & data policies
client needs for that particular software?

▪ Communicating with client pave perfect road for developing the software.
Software Engineering(3150711) 201170107508

2.Planning

▪ Here we will plan upcoming project.

▪ We will develop web app.

▪ we can develop web app using PHP language.

▪ MySql data base used for store content.

▪ Cost Estimation of Developing Web app [₹ 50K+]

▪ Managing Data and Providing Security [₹15-20k]

▪ Total time of Completion Project [1 and Half Month]

▪ Number of Employees [8 – 10]

Software Engineering(3150711) 201170107508

Time Management
▪ Critical Chain
➢ As Per Developer ability chart of time require to complete work

Employee Type Employee Work Time of Completion

PHP Developer Project Coding 4-5 Days

UX Designer Designing Frontend 2-3 Days

Database Manager Managing Data [Backend] 4-5 Days

Security Expert Provide Security & Look 1 week

[White Hacker] Out vulnerability Data

▪ Critical Path
➢ Chart of all the things [In Days]

Completion Time

Frontend &
Coding Backend Security
33% Checkup
17%
Frontend & Backend

Security Checkup Coding

50%
Software Engineering(3150711) 201170107508

1.Construction

▪ We will use mainly PHP for web app.

▪ We will build machine learning from the scratch using following libraries.

→ Laravel Tinker

→ Laravel Backup

→ PHP Rector

→ Stripe-PHP

▪ We will also use wordPress standard library as well. We will also use and
advance sql connection for data stored in effective way.

▪ We use Apache Hadoop it is a collection of open-source software utilities that

facilitates using a network of many computers to solve problems involving
massive amounts of data and computation.
Software Engineering(3150711) 201170107508

1. Deployment

▪ Testing

➢ In testing we start with alpha version then beta version then insider preview &
finally public release so that we can tackle all the bugs along the way.

▪ Client review

➢ Here we approach the client and ask for about his opinion in broad sense
‘review’. What client thinks about software & did we meet up his expectations
or not.

▪ Bug fixes & update

➢ Here we try to find bugs in software so that software can run smoothly on any
system & also will talk about the features that we can come up with for further
updates.

▪ Software Support

➢ We will provide way for user to communicate with support in case they got any
issues related to software.

▪ Launch

➢ Finally this is phase where we launch the software publicly.

Software Engineering(3150711) 201170107508

2. Modeling

❖ Chart of Data Flows Table

▪ Minimum System Requirements -
▪ Windows 7/Windows10 – X64 bit.
▪ Mac OS Sierra & Later.
▪ Android 6 & Later.
▪ IOS 10 & Later.
Software Engineering(3150711) 201170107508
Software Engineering(3150711) 201170107508

Tutorial-2
Software Requirements Specification (SRS)
Book E-Commerce System (BECS)

1 Introduction
The Software Requirements Specification is designed to document and describe the agreement between the
customer and the developer regarding the specification of the software product requested . Its primary purpose
is to provide a clear and descriptive “statement of user requirements”. that can be used as a reference in further
development of the software system. This document is broken into a number of sections used to logically
separate the software requirements into easily referenced parts.

This Software Requirements Specification aims to describe the Functionality, External Interfaces, Attributes
and Design Constraints .

1.1 Purpose
Defining and describing the functions and specifications of the Book E-Commerce System (BECS) is the
primary goal of this Software Requirements Specification (SRS). This Software Requirements Specification
illustrates, in clear terms, the system’s primary uses and required functionality as specified by our customer.

1.2 Scope
The software system being produced is called Book E-Commerce System or BECS. It is being produced for a
customer interested in selling books via the Internet. This system is designed to “provide automation support”
for the process of placing books for sale on the Internet and facilitating the actual sale. The system will be run
on a central server with each user having a remote user interface through a web browser to interact with it.

The Book E-Commerce System will allow any user to create an account to become a customer. The customer,
through the process of account creation, will have the option to become a member of the site. The system will
allow customers to browse, search, select, and add books to a shopping cart. Then, provided they have books in
their shopping cart, check out books in shopping cart and decrement the stock that the inventory the system
maintains. The BECS also allows a manager to manage the inventory with full create, retrieve, update and
delete (CRUD) functionality with regards to books in the system. It will also allow, on an inventory wide basis,
customers and managers to interact with a
promotion system that handles percentage-off promotions that can be applied to member’s orders.
The BECS will have numerous constraints on what it can do. The system will not have full credit-card
processing capabilities. It will not allow managers to be customers. The manager will be a hard-coded user and
only a single manager will exist. There will be no actual book ordering and order completion, however the
system will provide the customer with a receipt and it will log the transaction details. The system will not allow
Software Engineering(3150711) 201170107508

multiple promotions to be added to a single shopping cart nor will it allow a customer to add more than one of
each item to their cart. The system also will not allow users to retrieve passwords or edit their user details.

1.3 Definitions, acronyms, and abbreviations

BECS Book E-Commerce System
Barcode A unique identifier assigned to single items
Book An instance of an Item that has these additional attributes: Title, Author
Button A user interface element that allows a User to click and inform the
system to take an action
Checkbox A user interface element that allows a User to inform the system that
he/she selected a particular item
Checkout The process a Customer goes through to purchase an Item
CRUD Create, Retrieve, Update, Delete
Customer A person that is a user of the system but has created an account
Inventory An object that holds items available for purchase by the Customer
Item An individual entity in the inventory which has several descriptive
attributes:
Barcode, Price, Reorder Threshold, Stock
Manager A single person that has the ability to create, retrieve, update and delete
items in the store. This person cannot simultaneously act as a Customer
and Manager.
Member A person that is a customer of the system and has requested to be sent
promotions
Promotion An item-wide percentage-off price discount applied to a Member's
shopping cart
Reorder The system process that automatically orders new stock of an item
Reorder The numeric value of an item's stock that must be reached before the
Threshold system will order additional quantities of the item
Session The time which a User is actively using the system
Shopping Cart An object that lists a Customer's selected Items, their applied
promotions and gives them an option to check out
SRS Software Requirements Specification
Stock The quantity of any particular item the inventory has on hand
Text Box A user interface element that allows a User to input text to the system
Transaction The information related to a customer's purchase that is logged
User The person who operate the software product.

1.4 Organization
This Software Requirements Specification document is divided in to multiple subsections. The first section
includes explanations of the Purpose, Scope and Organization of the document. The first section also handles
the description of project specific words, acronyms and abbreviations that will be used in the document. The
second section of the document is separated into the following five different sections, each detailing specific
details of system uses and their corresponding actions: Product Perspective, Product Functions, User
Characteristics, Constraints, Assumptions and Dependencies, Apportioning of Requirements. The third section
Software Engineering(3150711) 201170107508

is an enumerated listing of all of the requirements described for this system. The fourth section encompasses all
of the Use-case, Sequence, State and Class diagrams that model the system. In the fifth section there exists a
Prototype of the system along with a sample scenario that graphically describes the use of the system. The sixth
section contains a listing of all related reference materials used in this document. The seventh and final
subsection is dedicated to providing a point of contact for any viewer of this document.

2 Overall Description
This section includes details about what is and is not expected of the BECS system in addition to which cases
are intentionally unsupported and assumptions that will be used in the creation of the BECS system.

2.1 Product Perspective

BECS is an online bookstore website which supports a number of functions for both the consumer and store's
management.

The website must be available to anyone using the Computer Science Department’s provided computer
resources in the MSU Engineering Building and as such must work correctly in both Internet Explorer and
Mozilla Firefox. As stated by the customer, there are no hardware or software requirements beyond these
including, but not limited to, memory or specific software packages that need to be utilized nor software
packages that need not be utilized.

2.2 Product Functions

BECS will provide a number of functions; each is listed below.
• Maintain data associated with the inventory (a collection of books)
• A book has a title, author and price
• The inventory also keep track of the stock/quantity of each book
• Maintain records for many customers
• A customer can be either a member or non-member.
• A customer has a username (unique across all users), password (no restrictions), email address (no restrictions),
and postal address (unverified.)
• Anyone may sign up for a customer account.
• Allow any customer to become a member.
• Show a listing of available books
• Books are to be displayed in ascending alphabetical order by title.
• Each book will list the following from left to right
• Title
• Author
• Price
• Allow customers and managers to log in and out of the system.
• Users (both customers and the manager) will be logged out if inactive for 30 minutes.
• Shopping cart
• Anyone is able to add one or more books to the shopping cart.
• The shopping cart does not need to allow multiple copies of any book.
• Checkout
• Checkout is only available to logged-in customers. A user that is not logged in as a customer is given a chance to
log in.
• Member customers may enter a promotion code.
Software Engineering(3150711) 201170107508

• Only one promotion code may be used per purchase

• The promotion is a fixed percentage discount that is to be applied to an entire order.
• The discount is specified by the manager at the time of the promotion’s creation or most recent update/edit.
• Collect a 16-digit credit card number from the customer
• Log/record the transaction
• Allow manager to specify a stop-order for a book
• Each book has its own stop-order status – either on or off. Details of its use are involved in the following feature.
• Notify manager when books need to be reordered
• When the quantity a book falls below a threshold, the manager is notified that the book
needs to be reordered.
• One exception is if the manager has already specified a stop-order for this book.
• Every book must either have stop-order enabled or disabled
• Allow manager to update stock quantities
• Allow manager to change any book's price
• Allow manager to view transaction logs
• Allow manager to create promotions
• A promotion is a percentage discount that can be applied to an entire order
• Promotions may only be used by member customers
• A promotion has an expiration date specified by the manager
When a promotion is created, it is emailed to all member customers via the email address on record

2.3 User Characteristics

The typical BECS user is simply anyone that has access to the Internet and a web browser in the computer
science department at Michigan State University. It is assumed that the user is familiar enough with a computer
to operate the browser, keyboard and mouse and is capable of browsing to, from and within simple websites .

2.4 Constraints
As stated by the customer, security is not a concern for this system. The database may store passwords in plain
text and there doesn't need to be a password recovery feature nor lockout after numerous invalid login attempts.
As such, the system may not work correctly in cases when security is a concern. These cases include those
listed above in addition to lack of an encrypted connection when sending credit card information and forcing
users to use “strong” passwords. A strong password is a password that meets a number of conditions that are set
in place so that user's passwords cannot be easily guessed by an attacker. Generally, these rules include
ensuring that the password contains a sufficient number of characters and contains not only lowercase letters
but also capitals, numbers, and in some cases, symbols.

Condition Table
Mode Conditions
Software Engineering(3150711) 201170107508

AddPromotion TRUE FALSE PromotionAdded TRUE FALSE

Mode Class
Old Mode Login IsManager IsCustomer Logout New Mode
UserLoggedOut @T t - - ManagerLoggedIn
@T - t - CustomerLoggedIn
ManagerLoggedIn - - - @T UserLoggedOut
CustomerLoggedIn - - - @T UserLoggedOut

Event Table
@T(User::Login() ==
UserLoggingIn TRUE) never
@T(Logout() ==
UserLoggingOut never TRUE)
User::LoggedIn TRUE FALSE

Condition Table
Mode Conditions
UserLoggedOut FALSE TRUE
ManagerLoggedIn TRUE FALSE
CustomerLoggedIn TRUE FALSE
UserLoggedIn TRUE FALSE

2.5 Assumptions and Dependencies

Client:
We have assumed that all of the computer systems in the Engineering building labs are in proper working
condition and that the user is capable of operating these system's basic functions including but not limited to
being able to power on the system, login and open either Internet Explorer or Mozilla Firefox, and navigate the
browser to the address of this BECS website.

Provider:
We have assumed that the BECS will be running on a properly working web server and database system with
an Internet connection that allows this system to perform all communications with clients.

Assumptions:
• There is no need for anyone to be able to order more than a single copy of a book (or any item) in a
single transaction.
• The manager account’s username and password maybe hard coded.
• The manager cannot be a customer.
• Any user cannot edit their account information.

2.6 Approportioning of Requirements

As stated by the customer, security is not a concern of this project. As such, it is beyond the scope of this
system to encrypt personal user data, encrypt credit card information, prevent unauthorized login attempts, or
any other concern of this nature. Additionally, the system is not responsible for the following:
Software Engineering(3150711) 201170107508

• Verifying that credit card information is valid

• Verifying the email address provided by a user
• Storing additional information about a book beyond simply the title, name of author, and price
• Allowing users to edit their account details (username, password, mailing address, etc.)
• Allowing customers to order multiple copies of a book in a single order
• Providing individual product pages (one page for every item in the inventory)
• Allowing the manager to update login credentials or other information about the manager

Additionally, the system may need to later be extended to provide additional functions. One such example is
added support for visually impaired users. In many cases a screen reading program is used and ensuring that
page-layout reads from top-left to bottom-right in a logical manner would be required.

3 Specific Requirements
1. Restrictions
1.1. User Side
1.1.1.Software
1.1.1.1. Internet Explorer or Mozilla Firefox
1.1.2.Hardware
1.1.2.1. Computer Science Department Laboratory Terminal
1.2. System Side
1.2.1.Software
1.2.1.1. Web-based application
1.2.1.2. Database information storage system
2. Data Structure
2.1. Book has these attributes
2.1.1. Unique ID (auto-increment starting at 1)
2.1.2.Title
2.1.3.Author
2.1.4.Price
2.1.5.Reorder Threshold
2.1.6.Stop-order Boolean value
2.1.7.Stock
2.2. Customer has these attributes
2.2.1.Unique Username
2.2.2.Password
2.2.3.Name
2.2.4.Email Address
2.2.5.Postal Address
2.2.6.Member/Not Member Boolean value
2.3. Manager has these attributes
2.3.1.Username
2.3.2.Password
2.3.3.Email address
2.4. Order log entries have these attributes:
2.4.1.Unique ID (auto generated)
2.4.2.Time transaction took place
2.4.3.Date transaction took place
Software Engineering(3150711) 201170107508

2.4.4. Username of customer

2.4.5. Listing of the contents in customer’s shopping cart
3. System
3.1. Browse Inventory
3.1.1.Organization
3.1.1.1. Items Listed on single page
3.1.1.2. Items shown in tabular format
3.1.1.3. Each Item listing contains
3.1.1.3.1. Title
3.1.1.3.2. Name of Author
3.1.1.3.3. Price
3.1.1.4. Listing sorted by Ascending item Title
3.1.1.5. No individual Item pages
3.1.2.Interaction
3.1.2.1. Each Item has checkbox to mark selection
3.1.2.2. Single button to add all selected items to Shopping Cart
3.2. Shopping Cart
3.2.1.Logged In
3.2.1.1. Can add items to cart
3.2.1.1.1. If Item is not in stock, message displayed informing user to try again later
3.2.1.1.2. Customer can only purchase one of each item (no quantities associated with orders)
3.4.1.1.3.
3.2.1.2. If shopping cart not empty, a user may begin Checkout procedure
3.2.2.Not Logged In
3.2.2.1. Can add items to cart
3.2.2.2. User required to login before they may begin Checkout procedure
3.3. Checkout procedure
3.3.1. User must successfully use shopping cart before beginning this procedure
3.3.2.Checkout page consists of
3.3.2.1. A text box for promotion entering
3.3.2.2. An overview of the purchase
3.3.2.3. A text box to hold the credit card number
3.3.2.4. A button to complete the order
3.3.3. Order details sent via email after the checkout has completed
3.3.4. On order completion the inventory is decremented based on items purchased by user
3.4. Authentication System
3.4.1.User Levels
3.4.1.1. Manager (single, hardcoded user, no orders)
3.4.1.2. Customer (unlimited, open creation, unlimited orders)
3.4.2.Account Creation
3.4.2.1. Everyone is allowed to create an account
3.4.2.2. Required Information
3.4.2.2.1. Listed in section 2.2
3.4.3. Account Modification
3.4.3.1. Users are not able to modify any aspect of their account after creation
(“it would be nice but not needed”)
3.4.4. Login and Logout
3.4.4.1. There is no lost-password recovery
3.4.4.2. Logging in allows one to logout
3.4.4.3. Logging in allows checkout
Software Engineering(3150711) 201170107508

3.4.4.4. There is a 30-minute session time out after which a logged in user will be logged out
automatically.
3.4.4.5.3.4.4.5.
3.5. Order Logging
3.5.1.Specifications
3.5.1.1. Required Information:
3.5.1.2. A manager can view all past transactions from all users
Order log entries are generated when a user successfully checks out their shopping cart

4. Modelling Requirements

Use Case Diagram

The purpose of this diagram is to demonstrate how objects will interact with BECS and map out the basic
functionality of the system. Below is a list of the elements that you will see in the diagram on the next page as
well what is included in the use case templates that follow.

Actors Shown in the diagram as stick figures with a name

underneath. They represent elements that will be directly
interacting with the system.
Use Cases Oval shapes that have their names in the center. These
represent direct functionality within the system that must be
implemented.
Interactions Lines that connect the actors with the different Use Cases.
These show that there is some form of direct interaction
between the actor and that specific functionality.
Includes Dotted lines labeled “<<include>>” that connect two use
cases and have an arrow pointing towards one. This means
that the use case without the arrow calls on the functionality
of the use case with the arrow.
Extends Dotted lines labeled “<<extend>>” that connect two use
cases and have an arrow pointing towards one. This means
that the use case without the arrow takes all of the
functionality of the use case with the arrow and adds extra
functionality.
The System Boundary The large rectangle that contains the Use Cases. Everything
within the rectangle is what the system is responsible for
implementing
Use Case Template Describes the basic functionality and features of each use
case and the can be found in the pages following the use
case diagram.
Type A field in the use case template that states whether or not
the use case is directly interacted with by an actor (Primary)
or not (Secondary) as well as whether or not it is essential
to having a functioning system.
Software Engineering(3150711) 201170107508
Cross Ref A field in the use case templates that states which one of the
original requirements that particular use case satisfies.
Use-Cases A field in the use case templates that state which other use
cases must be executed prior to that particular use case.

Class Diagram
The purpose of this diagram is to show how objects within the BECS system will interact with each other in
order to achieve the functionality required by the Use Case diagram. Below is a list of what you will see in the
diagram itself as well as the class descriptions that follow.

Classes Rectangles in the diagram that are split into three parts. The top
section is the name of the class, the middle section is the list of
variables that are stored in the class and the bottom section is
the list of functions in the class. These rectangles represent
objects within the system.
Variables These have a name followed by a semicolon and then a type.
The type denotes what kind of data can be stored in the variable.

Functions These have a name followed by a list of any variable that the
function receives in-between the parenthesis “()”. After that
there is a semicolon and any variables that the function may
return, if none it will be void.
Software Engineering(3150711) 201170107508
Generalizations Shown using a line from one object to the other with an unfilled
triangle on one end. The object without the triangle inherits the
functionality and variables from the object that has the triangle
pointing towards it.
Aggregations Lines that have an unfilled diamond on one end. This means
the object with the diamond contains the object(s) without the
diamond. This may have numbers on the ends (multiplicities).
Associations Lines connecting two classes that can have a name beside it,
may point in one direction, and may have numbers at the ends
(multiplicities). These designate some relationship between the
objects. Arrows are simply there to assist you in recognizing
which direction the name of the association is read.

Multiplicities Numbers that may be on the ends of Aggregations and

Associations. They state how many of the one object can be
related to the other. The first number is the minimum and the
second number is the maximum. An asterisk ‘*’ means many, so
“1..*” can be read as 1 to many. If no number exists it is assumed
to be 1.
Software Engineering(3150711) 201170107508
Software Engineering(3150711) 201170107508

State Diagrams
The state diagrams take all of the functionality found in the previous diagrams and combines them together to
demonstrate the possible changes in the state within BECS. These state diagrams contain all the possible scenarios
shown in the sequence diagrams.

Starting Point This is where the system starts at and it is represented with a
filled circle that has an arrow that point towards the starting
state.
States These are represented in the diagram by the boxes that have the
rounded edges. They are separated into two half’s the top half
is the title of the state and the bottom half can have additional
states encapsulated within but these state diagrams do not
contain any encapsulated states within states.
Transitions The arrows that connect the states to each other and have a
label of the event that occurs which triggers the transition These
triggers are normally functions but they can also be a
new call that is the event of creating a new object; this is
represented simply with the word “new”. Some transitions do
not have a label, these are returns from the current state to the
previous state.
Objects The larger boxes that can contain several states and transitions.
They are classes within the state diagram. The text at the top
of the box is the name of the class.
Software Engineering(3150711) 201170107508
Software Engineering(3150711) 201170107508

5 Prototype
Software Engineering(3150711) 201170107508
Software Engineering (3150711)

Tutorial 3
A.. Development of Software Requirements Specification(SRS)
Functional Requirements :
A functional requirement describes what a software system should do. Functional
requirements define the inputs, outputs and their behavioral interrelationships. The
proposed system will be able to perform the following functional requirements:
• A person can search for the nearest available ambulance.
• Include a login and admin feature to access the software system by the ambulance
dispatch staff.
• Depending on the number of people involved in the accident, the dispatching
team will allocate the required number of ambulances.
• The ambulance dispatch system will calculate and display the time required to
dispatch the ambulance for each incident.
• The proposed system will be able to track the status of the ambulance.

Non–Functional Requirements :

Non-functional requirements define the qualities and restrictions of the system being
developed. The following are the non-functional requirements:
• Usability. Ambulance Dispatch System shall provide mouse and keyboard
navigation. Ambulance Dispatch System shall be easy to navigate by using clear
words, menus and drop-down lists. Ambulance Dispatch System shall be
accompanied with a user manual.
• Reliability, Ambulance Dispatch System shall be available 24 hours a day for
application users.
• Performance. Ambulance Dispatch System shall not take longer than 15 seconds
to respond to a page request for members; when using an internet connection that
is 56k or higher
• Supportability. The ambulance dispatch system should be supportable in current
equipment such as computers, monitors, printers etc.
• Capacity requirements: The system will store data for a large amount of data.
Software Engineering (3150711)

Function oriented design using SA/SD

Flow Chart
Software Engineering (3150711)

Object-oriented design using UML

Approach
Software Engineering (3150711)

Use Case Diagram

Software Engineering (3150711)

Use Case Model

Software Engineering (3150711)

D.. Test case design

The testing effort will require two single processor desktop PC. To properly test our
non-functional performance requirement, it must have no more than 1 GHz CPU and
256 MB RAM. One of these machines will be running Windows XP and the other
will be using Linux. Both machines will be using the Java Runtime Environment
version 1.5. We won’t be using any testing tools as we will be manually testing all the
interfaces.
We will document all the test results using following template while delivering the
application.
Tested By:

Test Type

Test Case Number

Test Case Name

Test Case Description

Item(s) to be tested

Specifications

Expected

Input Output/Result

Procedural Steps

7
Software Engineering (3150711)

Test cases
Test Case # - 001
Test Case Name - User Login
Test Items –
Functionality of the User Login screen
Input Specifications –
Valid UserName – User123
Valid Password – pass
Invalid UserName – User13
Invalid Password - pas
Output Specifications –
Input Expected Output
Valid UserName + Valid Display Dispatch Screen
Password
Invalid UserName + Valid Display Error Message
Password
Valid UserName + Invalid Display Error Message
Password
Invalid UserName + Invalid Display Error Message
Password

Environmental Needs –
Working CAD System.
Special Procedural Requirements –
None
Intercase Dependencies –
None
Test Case # - 002
Test Case Name – Enter Incident Info
Test Items –
Software Engineering (3150711)

Functionality of the Dispatcher screen

Input Specifications –
Name - Shyam
Valid Phone # - 9898349898
Invalid Phone # - 8989348989
Patient condition – In car accident.

Output Specifications –
Input Expected Output
Valid Phone # Address field is populated
Invalid Phone # Throws exception

Environmental Needs –
Working CAD System.
Special Procedural Requirements –
None
Intercase Dependencies –
None
Software Engineering (3150711)

E.. Implementation using Java and testing

The Prototype Graphical User Interface Screens for the system are designed as shown
below in the next few Pages.

Login Screen

Active Emergency Screen

Software Engineering (3150711)

New Emergency Screen

Emergency Details Screen

Software Engineering(3150711)
Tutorial-4
An infrastructure definition tool, such Cloud Formation, Terraform, or OpenStack Heat,
allows people to specify what infrastructure resources they want to allocate and how they
should be configured.The tool then uses the dynamic infrastructure platform to implement
the specification.Looking for the best suitable DevOps tools for Infrastructure automation
and Monitoring?
Every DevOps engineer is striving for good tools that help them in speeding the application
delivery. The DevOps tools are utilized for automated actions among the teams to build,
test and deploy highly reliable and scalable applications/ Software. But, choosing the right
tool isn’t an easy task.
Practically, you have to determine the tools to use in your infrastructure because there is
no single tool that fulfills all the requirements. There are several factors you should
consider such as monitoring, automate builds, code deployments, configuration
management, server provisioning, operating model, tool architecture, usability, your
experience, and much more technical or business requirements.

What are the benefits of DevOps infrastructure automation and

monitoring tools?
Infrastructure automation is a process describing the configuration as a script. Every single
configuration is created for different purposes. It is processed to manage communications
and operating systems. To put it in short words there two major reasons for automating
your infrastructure.
The DevOps engineers save loads of time in regular tasks and also on solving critical issues.
Automation helps to manage complex environments for faster scaling. The DevOps tools
can help you get the most out of infrastructure automation.
We will take a look at the core tools that are used in a typical DevOps environment to
achieve faster delivery.

Infrastructure automation and Monitoring Tools:

1. Jenkins
2. Puppet
3. Chef
4. Vagrant
5. Docker
6. Saltstack
7. Ansible
8. Juju
Software Engineering(3150711)
9. Sensu
10. Consul
11. New Relic
12. Monit

1. Jenkins

Jenkins is a Java-based continuous integration tool used for orchestration for the
application provisioning and deployment. It has to be associated with a version control
system (SVN) when you want a new code to push into the code repository.
The Jenkins server allows you to build and test the new code and notifies the team about
the process, changes and final results. Jenkins as an orchestration tool used for building
pipelines. You can also configure polls for any comments on SVN and trigger builds and
regression tests on the new code that is added according to the latest code commits.

2. Puppet

Puppet is a ruby based configuration management tool. It is written with puppet DSL and
is wrapped in modules. Puppet is developed with special consideration of system
administrators. The design of Puppet felicitates fast deployment, efficiently manages the
infrastructure as code with a task-based approach. Which improves the overall quality of
the software.
It runs a puppet agent running on all servers that need to be configured. Instead of running
any codes on the infrastructure it builds a graph that represents the code base of the
Software Engineering(3150711)
infrastructure. It will also figure out the best possibilities to achieve the desired state.
Puppet pulls a complied module with the specification desired and installs the software
needed to complete the tasks. You can find all the puppet community modules called
Puppetforge here.

3. Chef
Chef is one of the most popular agent-based cloud infrastructure automation tool for
configuration management. Ruby-based DSL is used, you have to code your infrastructure
and define the configuration scenarios. It uses agents to configure VMs and severs
according to the rules define in the cookbooks.
You’ll need an agent running on all the servers that require to be configured. Chef is helpful
to maintain consistent configuration, this reduces the operating costs, with effective data
centers management. And it also offers customization, flexibility, and readable
configuration policies.
The tools provide the support of simple migration, allows you to integrate with multiple
platforms such as FreeBSD and AIX. Chef provides you with a rich selection of ready to
use templates. You can find everything you need on the community cookbook here.

4. Vagrant
Vagrant is another most popular tool for configuring virtual machines for your
development environment. The tools run on the top of VM solutions such as Virtualbox
HyperV etc. Vagrant can handle all the configurations with help fo Vagrantfile. This
Vagrantfile contains all the configurations required for the Virtual machines. You can
create a configuration, it can be shared with other developers to imitate the process of the
same configuration. Vagrant also provides plugins for cloud provisioning, infrastructure
automation tools, and Docker.

5. Docker
Docker will be another most preferred tools for continuous integration and deployment.
Docker is an automation tool build on the top of Linux containers with the support for
containerization.
Docker works on the concept of process-level virtualization and creates isolated
environments for applications which are known as containers. The containers can be easily
shipped to another server without any changes made to the application, which further
doesn’t have any OS-related dependencies. Docker is predominantly used by DevOps
professionals in cloud computing and has active community support on both Windows and
Linux.
Software Engineering(3150711)
6. Saltstack
Saltsack is a Python-based configuration management tool. Unlike like few other tools
which pull the code for configuration from the server, Saltstack pushes the code to various
node simultaneously.
It compiles the code faster than Puppet and Chef and the configuration of the code is also
pretty quick.

7. Ansible
Ansible is complete agentless configuration management as well as an orchestration tool.
The configuration modules are written in YAML format and it is termed as “Playbooks”.
You can find all the community playbooks for your use here. Ansible is used for
integration, automation, development, testing, deployment and performance management.
The way of interaction between the system and its components is described by the user. It
reduces the complexity and removes unnecessary repetition in your infrastructure with ease
use. Ansible can also be modulated for multi-tier deployments and cloud provisioning.

8. Juju
Juju is a Python-based orchestration tool used to configure applications, scaling and
deployment of the application. It was developed by Canonical with attractive UI for cloud
environments when orchestrating your applications. Juju comes with the provision of using
a Command Line Interface to perform all the related tasks.

9. Sensu
Sensu is a monitoring framework used as a monitoring tool, specially built for cloud
environments. It is open source and written in Ruby. Sensu comes with ease of deployment
just like Chef and Puppet. It also has an enterprise edition for advanced monitoring.

10. Consul
Consul is an open source secret/ configuration management tool. It is considered ideal for
server discovery and a highly accessible key-value store. Consul allows you to have a use
case to store and retrieve the configurations in real-time.

11. New Relic

New Relic is a cloud-based solution for monitoring. This tool provides monitoring support
for PHP, NodeJS, Ruby, and Java. New relic gives real-time notifications about running
the application. The agent should be configured in the application which will get all the
real-time data and provides various metrics on the monitoring of the application.
Software Engineering(3150711)
12. Monit
Monit is one of the best tools for managing and monitoring Unix systems, sever protocols,
IP ports, remote hosts and several cloud services. It is an open source tool is easy to
configure and can be used for multi-service architecture with hundreds of
microservices.This tool provides monitoring of the machining process to ensure it is
running accordingly. Monit will fix the detected errors and repair them. It will restart the
Apache process if needed. It logs all the information about the recorded errors and system
state. You will receive notifications while you configure if there is any recovery status,
restarts of services, critical processes or any critical errors are handled.

Configuration Management
Ansible
Ansible is an agentless configuration management tool. It uses SSH to access the servers
it manages to communicate with them and execute predefined commands. It uses modules
called “Playbooks” that describe automation tasks it performs. Playbooks are the
configuration files written using a yaml file. The main reason it is so attractive, both to the
newer users and more experienced admins is its simplicity.
Pricing: Offers Standard and Premium versions.

Chef is a popular tool which is used for the configuration and management of your cloud
infrastructure. The chef server stores information about your node’s current and desired
configuration. Chef’s main task is to push the desired configuration instructions, also
known as cookbooks, to all other nodes connected to the server. These instructions help us
easily scale and modify our infrastructure if needed.
With Chef, we are using infrastructure as code - meaning that you are managing your IT
infrastructure using configuration files. To download Chef click here.
Pricing: Free and open source but does have enterprise options.
Software Engineering(3150711)

Puppet
Puppet is another popular configuration management tool on our list which consists of a
puppet master server and puppet agents which are located on the servers that we are
managing. The Puppet master server stores the configuration files needed for the servers
that are being managed. The Puppet master communicates constantly with puppet agents
and checks if something needs to be updated/changed. Opposite to Ansible, it uses more
complicated Puppet DSL’s (Domain Specific Language), so if you want to use it you need
to learn its code. Luckily, there are more than 6000 “Puppet modules” you can use to
quickly automate desired parts of infrastructure. If you wish to test it out yourself here are
step-by-step instructions on how to install Puppet on Ubuntu server.
Pricing: Information is available by contacting the Puppet sales team.

SaltStack
SaltStack is the fourth in our list of configuration management tools. It is an open source,
command-line driven utility delivering configuration automation for DevOps and site
reliability engineers. Salt has an active community and effective support mechanism. It is
designed to allow for low-latency, high-speed communication between nodes when
performing remote execution. Salt is designed to work with the Unix/Linux and Windows
operating systems, but the Master Salt server can only work on Unix/Linux operating
systems. Salt can also be utilized in a multi-master configuration increasing its resiliency.
Pricing: Free and open source.
Monitoring
Nagios
Software Engineering(3150711)
Nagios XI is an open-source tool used for system-wide monitoring. You can observe any
number of devices as long as they are connected to the internet and have the Nagios plugin
installed. If there is not a plugin available for your device, we can code our own using
various coding languages. The learning curve for Nagios is a gradual one. There is also a
graphical user interface which allows you to configure Nagios with only a few clicks, and
start monitoring your devices right away. Nagios contains multiple features which can be
reviewed here: https://www.nagios.com/products/nagios-xi/#features
Pricing: Nagios offers various products.
Prometheus

Prometheus is an open-source monitoring and alerting tool. It actively scrapes multiple

metrics using flexible queries in a http based pull model. It supports the latest technologies
and is widely supported by an active user base. Because Prometheus is open-source, the
TCO investment is low and the learning curve is small.
Pricing: Free and open source.
Software Engineering(3150711)
Tutorial-5
FP (Function Point) ORIENTED ESTIMATION MODEL
Calculating effort for Attendance Management System using FP oriented model.

Objective
Calculating effort for Attendance Management System using Function Point
oriented estimation model. It is a method to break systems into smaller components,
so they can be better understood and analyzed. It is used to express the amount of
business functionality, an information system (as a product) provides to a user. Fps
measure software size. They are widely accepted as an industry standard for functional
sizing. Function points are used to compute a functional size measurement (FSM) of
software. The cost (in dollars or hours) of a single unit is calculated from past
projects.Function Point Analysis can provide a mechanism to track and monitor scope
creep. Function Point Counts at the end of requirements, analysis, design, code, testing
and implementation can be compared. The function point count at the end of
requirements and/or designs can be compared to function points actually delivered. The
amount of growth is an indication of how well requirements were gathered by and/or
communicated to the project team. If the amount of growth of projects declines over
time it is a natural assumption that communication with the user has improved.

Overview

Function-oriented software metrics use a measure of the functionality delivered

by the application as a normalization value. Since ‘functionality cannot be measured
directly, it must be derived indirectly using other direct measures. Function-oriented
metrics were first proposed by Albrecht, who suggested a measure called the function
point. Function points are derived using an empirical relationship based on countable
(direct) measures of software's information domain and assessments of software
complexity. Function points are computed by completing the table asshown below. Five
information domain characteristics are determined and counts are provided in the
appropriate table location. Information domain values are defined in the following
manner:
Software Engineering(3150711)

Number of user inputs: Each user input that provides distinct application oriented
data to the software is counted. Inputs should be distinguished from inquiries, which
are counted separately. Number of user outputs: Each user output that provides
application oriented information to the user is counted. In this context output refers to
reports, screens, error messages, etc. Individual data items within a report are not
counted separately.
Number of user inquiries: An inquiry is defined as an on-line input that results in the
generation of some immediate software response in the form of an on-line output. Each
distinct inquiry is counted.
Number of files: Each logical master file (i.e., a logical grouping of data that may be
one part of a large database or a separate file) is counted.
Number of external interfaces: All machine readable interfaces (e.g., data files on
storage media) that are used to transmit information to another system are counted.
Once these data have been collected, a complexity value is associated with each
count. Organizations that use function point methods develop criteria for determining
whether a particular entry is simple, average, or complex. Nonetheless, the
determination of complexity is somewhat subjective

Procedure
FPA provides different estimation mechanism within it for development and
maintenance projects. (having different multiplication factors).This approach computes
the total function points (FP) value for the project, by totaling the number of external
user inputs, inquiries, outputs, and master files, and then applying the following weights:
inputs , outputs , inquiries, and master files.

FP POINTS COMPUTATION
To compute function points (FP), the following relationship is used:
FP = count total [0.65 + 0.01 Σ ( Fi )]
Software Engineering(3150711)
where count total is the sum of all FP entries .
The Fi (i = 1 to 14) are "complexity adjustment values" based on responses to the
following questions :
1. Does the system require reliable backup and recovery?
2. Are data communications required?
3. Are there distributed processing functions?
4. Is performance critical?
5. Will the system run in an existing, heavily utilized operational environment?
6. Does the system require on-line data entry?
7. Does the on-line data entry require the input transaction to be built over
multiple screens or operations?
8. Are the master files updated on-line?
9. Are the inputs, outputs, files, or inquiries complex?
10. Is the internal processing complex?
11. Is the code designed to be reusable?
12. Are conversion and installation included in the design?
13. Is the system designed for multiple installations in different organizations?
14. Is the application designed to facilitate change and ease of use by the user?
Each of these questions is answered using a scale that ranges from 0 (not important or
applicable) to 5 (absolutely essential). The constant values in Equation and the
weighting factors that are applied to information domain counts are determined
empirically. Once function points have been calculated, they are used in a manner
analogous to LOC as a way to normalize measures for software productivity, quality,
and other attributes:
Errors per FP.
Productivity = FP/ Person-
Month Quality = No of
faults / FP
Cost= $/FP
Documentation = Pages count / FP.
Effort = FP/ Person-Month
Software Engineering(3150711)

Count Total can be obtained using the following table

Domain Count Weighting factor Count

characterist Simp Avera Compl
ics le ge ex
No of * 3 4 6
user
input
No of * 4 5 7
user
output
No of
user * 3 4 6
queries
No of files * 7 10 15
No of * 5 7 10
external
interfaces
Count total:

Example:
Assume that....
Number of user input :
5 Number of user
output : 5 Number of
user enquires : 6
Number of files :5
Number of external interfaces : 5
Software Engineering(3150711)
Apply these assumptions on a simple project and calculate the Count Total

Domain Count Weighting factor Count

characteris Simple Average Complex
tic s
No of 5 * 3 4 6 15
user
input
No of 5 * 4 5 7 2
user
output
No of 6 * 3 4 6 18
user
queries
No of files 5 * 7 10 15 35
No of 5 * 5 7 10 25
externa
l
interfac
es
Count total: 113

Therefore, Count Total =113

Now calculate the Functional Points using FP = count total *0.65 +
0.01 Σ ( Fi )] FP = count total *0.65 + 0.01 Σ ( Fi )]
= 113 * (0.65 +0.01 * 25) where Σ ( Fi )
=25
i.e the questions answered using a scale that ranges from 0 (not
important or applicable) to 5 (absolutely essential) in total 14
questions
=113 *(0.65 + 0.25)
=113 * 0.9
= 101.7

FP = 101.7
Effort = FP / person-month
Software Engineering(3150711)
Advantages:

This method is independent of programming languages.

1. It is based on the data which can be obtained in early stage of project.
2. Function Points are easily understood by the non-technical user. This helps
communicate sizing information to a user or customer.

Disadvantages:
1. This method is more suitable for Business systems and can be developed for that
domain.
2. Many aspects of this method are not validated.
3. The functional point has no significant ant meaning, it’s just a numerical value.
Software Engineering(3150711)
Software Engineering(3150711)