TYPE THE NAME OF YOUR Project

Topic HERE
A
Project Based Learing Project Report submitted to Savitribai Phule Pune
University, Pune

In partial Fulfillment for the awards of Degree of Engineering in

Computer Engineering
Submitted by
Mr./Ms. Type Your name here Exam Seat No.
Mr./Ms. Type Your name here Exam Seat No.
Mr./Ms. Type Your name here Exam Seat No.
Mr./Ms. Type Your name here Exam Seat No.

Under the Guidance of

Mr/Ms./Mrs./Prof. A B C
Designation of Guide

Department of Computer Engineering

NBN Sinhgad School of Engineering,
Ambegaon Dist.Pune
NBN Sinhgad School of Engineering, Ambegaon
Dist.Pune
Department of Computer Engineering
(2022-23)

Certificate

This is to certify that,

Name of Student, Exam seat no:
Name of Student, Exam seat no:
Name of Student, Exam seat no:
Name of Student, Exam seat no:
have successfully completed the Mini project entitled “ Project Title ” under my guidance in
partial fulfillment of the requirements for the Third Year of Engineering in Computer
Engineering under the Savitribai Phule Pune University during the academic year 2022-2023

Date : ……………….
Place:……………….

……………………………….
Mr./Ms./Mrs./Prof. A B C Prof.S.P.Bendale
Project Guide Head,
Department of Computer Engineering
 Acknowledgements
(Font size 12 times new roman)

With deep sense of gratitude we would like to thank all the people who have lit our path with
their kind guidance. We are very grateful to these intellectuals who did their best to help
during our project work.
It is our proud privilege to express a deep sense of gratitude to Prof. Dr.S.P.Patil,
Principal of NBN Sinhgad School of Engineering, Ambegaon,Pune for his comments and
kind permission to complete this project. We remain indebted to Prof.S.P.Bendale, H.O.D.
Computer Engineering Department for his timely suggestion and valuable guidance.
The special gratitude goes to (Guide Name) excellent and precious guidance in
completion of this work .We thanks to all the colleagues for their appreciable help for our
working project. With various industry owners or lab technicians to help, it has been our
endeavor throughout our work to cover the entire project work.
We are also thankful to our parents who provided their wishful support for our project
completion successfully .And lastly we thank our all friends and the people who are directly
or indirectly related to our project work.

(Project members name)

Mr./Ms. Name of Student
Mr./Ms. Name of Student
Mr./Ms. Name of Student
Mr./Ms. Name of Student
 Abstract
(/*Font size Italicized 12 times new roman,
should be preferably less than or equal to 300 words*/ )
For example :
In Medical organization, a large amount of personal data are collected and analyzed by the
data miner or researcher or adversaries. Such data may contain sensitive information like
disease from medical history or credit records. On the other hand, these data is useful to
organization for decision making like to investigate the health condition of the country. While
analyzing these data can poses threats to individual privacy, if not done properly. Data
mining techniques can expose critical sensitive information about medical databases.
Keywords:
 Table of Contents

Abstract
Table of Contents i
List of Abbreviations ii
List of Figures iii
List of Tables
1 Introduction 1
1.1 Overview
1.2 Aim/Motivation
1.3 Objective
1.4 Organization of Report
2 Problem Statement
3. Software Requirements Specification
3.1 Hardware Requirements
3.2 Software Requirements
4. Literature Survey
5. System Design
5.1 Project Block Diagram
5.2 GUI of Working System
5.3 UML Diagram
5.3.1 ER Daigram
5.3.2 Use Case Diagram
5.3.2 Sequence Diagram
5.3.3 Class Diagram
5.3.4 DFD Diagram
5.3.5 Activity Diagram
6. Risk Analysis
6.1 Risk Management
6.2 Risk Analysis
6.3 Project schedule
6.4 Team Organization
7.Testing
7.1 Test Environment
7.2 Formal Technical Review
7.3 Software to be tested
8.Conclusion and Future Scope
References
 List of Abbreviations

1 PBS - phosphate buffered saline

2 FITC - fluorescein isothiocyanate

/* This information only for Understanding Pupose

A list of abbreviations is usually optional, but of great help to the reader. It contains all the
significant abbreviations used in your report
You should list on a separate page all the abbreviations that you have used in your report.
Many of these are standard, e.g.
● PBS - phosphate buffered saline
● Ig - immunoglobulin
● FITC - fluorescein isothiocyanate
Try not to invent too many abbreviations of your own, as it can make it hard work for your
examiner to read. In addition, the first time that you use an abbreviation in the main text, you
must define it, e.g.
Antibodies were diluted in phosphate buffered saline (PBS)
The next time you can simply use the abbreviation, e.g. Sections were rinsed three times in
PBS
You must be consistent. Once you have defined an abbreviation, always use the same

abbreviation and do not revert to the original words. */

 List of Figures

Figure 1 The General layout of the system 1

Figure 2 The evolution of Information Theory 9

.
.
.
.
 List of Tables

Table 1 A Micro-data of a hospital system 3

Table 2 A modified Micro-data 4
Table 3 A voter database 4

.
.
.
 Chapter 1

Introduction

1.1 Overview
1.2 Aim/Motivation
1.3 Objective
1.4 Organization of Report

/* This Content only for information,delete it

1.1 Overview
It provides a brief summary of previous engineering and/or scientific work on the topic.Here you
present an overview of what is known about the problem.

1.2 Aim/Motivation
1.3 Objective
Project objectives are the specific objectives for which the project works to achieve them
within a stipulated time.
They should directly address the problem mentioned in the Problem Statement.
1.4 Organization of Report
The rest of this report is organized in following manner. In all chapters, related contents are
described in detail.
● Introduction (Chapter 1):
● Literature Survey (Chapter 2):
●
●
●
● Conclusion (Chapter 6):

*/
 Chapter 2

Problem Statement

/* This Content only for information,delete it

● problem statement is a clear description of the issue(s), it includes a vision, issue
statement, and method used to solve the problem.
● A problem statement expresses the words that will be used to keep the effort focused
and it should represent a solveable problem.
● The 5 'W's can be used to spark the discussion about the problem.

The 5 'W's - Who, What, Where, When and Why - is a great tool that helps get pertinent
information out for discussion.
Who - Who does the problem affect? Specific groups, organizations, customers, etc.
What - What are the boundaries of the problem, e.g. organizational, work flow, geographic,
customer, segments, etc. - What is the issue? - What is the impact of the issue? - What impact
is the issue causing? - What will happen when it is fixed? - What would happen if we didn’t
solve the problem?
When - When does the issue occur? - When does it need to be fixed?
Where - Where is the issue occurring? Only in certain locations, processes, products, etc.
Why - Why is it important that we fix the problem? - What impact does it have on the
business or customer? - What impact does it have on all stakeholders, e.g. employees,
suppliers, customers, shareholders, etc. Each of the answers will help to zero in on the
specific issue(s) and frame the Issue Statement. Your problem statement should be solveable.
That is, it should take a reasonable amount of time to formulate, try and deploy a potential
solution.
 Chapter 3

Software Requirements Specification

3.1 Introduction

3.1.1 Purpose
<Identify the product whose software requirements are specified in this document, including
the revision or release number. Describe the scope of the product that is covered by this SRS,
particularly if this SRS describes only part of the system or a single subsystem.>
3.1.2 Document Conventions
<Describe any standards or typographical conventions that were followed when writing this
SRS, such as fonts or highlighting that have special significance. For example, state whether
priorities for higher-level requirements are assumed to be inherited by detailed requirements,
or whether every requirement statement is to have its own priority.>
3.1.3 Intended Audience and Reading Suggestions
<Describe the different types of reader that the document is intended for, such as developers,
project managers, marketing staff, users, testers, and documentation writers. Describe what
the rest of this SRS contains and how it is organized. Suggest a sequence for reading the
document, beginning with the overview sections and proceeding through the sections that are
most pertinent to each reader type.>
3.1.4 Product Scope
<Provide a short description of the software being specified and its purpose, including
relevant benefits, objectives, and goals. Relate the software to corporate goals or business
strategies. If a separate vision and scope document is available, refer to it rather than
duplicating its contents here.>
3.1.5 References
<List any other documents or Web addresses to which this SRS refers. These may include
user interface style guides, contracts, standards, system requirements specifications, use case
documents, or a vision and scope document. Provide enough information so that the reader
could access a copy of each reference, including title, author, version number, date, and
source or location.>

3.2 Overall Description

3.2.1 Product Perspective
<Describe the context and origin of the product being specified in this SRS. For example,
state whether this product is a follow-on member of a product family, a replacement for
certain existing systems, or a new, self-contained product. If the SRS defines a component of
a larger system, relate the requirements of the larger system to the functionality of this
software and identify interfaces between the two. A simple diagram that shows the major
components of the overall system, subsystem interconnections, and external interfaces can be
helpful.>
3.2.2 Product Functions
<Summarize the major functions the product must perform or must let the user perform.
Details will be provided in Section 3, so only a high level summary (such as a bullet list) is
needed here. Organize the functions to make them understandable to any reader of the SRS.
<Describe any items or issues that will limit the options available to the developers. These
might include: corporate or regulatory policies; hardware limitations (timing requirements,
memory requirements); interfaces to other applications; specific technologies, tools, and
databases to be used; parallel operations; language requirements; communications A picture
of the major groups of related requirements and how they relate, such as a top level data flow
diagram or object class diagram, is often effective.>

3.2.3 User Classes and Characteristics

<Identify the various user classes that you anticipate will use this product. User classes may
be differentiated based on frequency of use, subset of product functions used, technical
expertise, security or privilege levels, educational level, or experience. Describe the pertinent
characteristics of each user class. Certain requirements may pertain only to certain user
classes. Distinguish the most important user classes for this product from those who are less
important to satisfy.>

3.2.4 Operating Environment

<Describe the environment in which the software will operate, including the hardware
platform, operating system and versions, and any other software components or applications
with which it must peacefully coexist.>

3.2.5 Design and Implementation Constraints

protocols; security considerations; design conventions or programming standards (for
example, if the customer’s organization will be responsible for maintaining the delivered
software).>

3.2.6 User Documentation

<List the user documentation components (such as user manuals, on-line help, and tutorials)
that will be delivered along with the software. Identify any known user documentation
delivery formats or standards.>

3.2.7 Assumptions and Dependencies

<List any assumed factors (as opposed to known facts) that could affect the requirements
stated in the SRS. These could include third-party or commercial components that you plan to
use, issues around the development or operating environment, or constraints. The project
could be affected if these assumptions are incorrect, are not shared, or change. Also identify
any dependencies the project has on external factors, such as software components that you
intend to reuse from another project, unless they are already documented elsewhere (for
example, in the vision and scope document or the project plan).>

3.3 External Interface Requirements

3.3.1 User Interfaces

<Describe the logical characteristics of each interface between the software product and the
users. This may include sample screen images, any GUI standards or product family style
guides that are to be followed, screen layout constraints, standard buttons and functions
(e.g., help) that will appear on every screen, keyboard shortcuts, error message display
standards, and so on. Define the software components for which a user interface is needed.
Details of the user interface design should be documented in a separate user interface
specification.>
3.3.2 Hardware Interfaces
<Describe the logical and physical characteristics of each interface between the software
product and the hardware components of the system. This may include the supported device
types, the nature of the data and control interactions between the software and the hardware,
and communication protocols to be used.>

3.3.3 Software Interfaces

<Describe the connections between this product and other specific software components
(name and version), including databases, operating systems, tools, libraries, and integrated
commercial components. Identify the data items or messages coming into the system and
going out and describe the purpose of each. Describe the services needed and the nature of
communications. Refer to documents that describe detailed application programming
interface protocols. Identify data that will be shared across software components. If the data
sharing mechanism must be implemented in a specific way (for example, use of a global data
area in a multitasking operating system), specify this as an implementation constraint.>

3.3.4 Communications Interfaces

<Describe the requirements associated with any communications functions required by this
product, including e-mail, web browser, network server communications protocols,
electronic forms, and so on. Define any pertinent message formatting. Identify any
communication standards that will be used, such as FTP or HTTP. Specify any
communication security or encryption issues, data transfer rates, and synchronization
mechanisms.>

3.4 System Features

<This template illustrates organizing the functional requirements for the product by system
features, the major services provided by the product. You may prefer to organize this section
by use case, mode of operation, user class, object class, functional hierarchy, or
combinations of these, whatever makes the most logical sense for your product.>
3.4.1 System Feature 1
<Don’t really say “System Feature 1.” State the feature name in just a few words.>
3.1.1 Description and Priority
<Provide a short description of the feature and indicate whether it is of High, Medium,
or Low priority. You could also include specific priority component ratings,
such as benefit, penalty, cost, and risk (each rated on a relative scale from a
low of 1 to a high of 9).>
3.1.2 Stimulus/Response Sequences
<List the sequences of user actions and system responses that stimulate the behavior
defined for this feature. These will correspond to the dialog elements
associated with use cases.>
3.1.3 Functional Requirements
<Itemize the detailed functional requirements associated with this feature. These are
the software capabilities that must be present in order for the user to carry out
the services provided by the feature, or to execute the use case. Include how the
product should respond to anticipated error conditions or invalid inputs.
Requirements should be concise, complete, unambiguous, verifiable, and
necessary. Use “TBD” as a placeholder to indicate when necessary
information is not yet available.>
<Each requirement should be uniquely identified with a sequence number or a
meaningful tag of some kind.>
REQ-1:
 REQ-2:
3.4.2 System Feature 2 (and so on)

3.5 Other Nonfunctional Requirements

3.5.1 Performance Requirements
<If there are performance requirements for the product under various circumstances, state
them here and explain their rationale, to help the developers understand the intent and make
suitable design choices. Specify the timing relationships for real time systems. Make such
requirements as specific as possible. You may need to state performance requirements for
individual functional requirements or features.>
3.5.2 Safety Requirements
<Specify those requirements that are concerned with possible loss, damage, or harm that
could result from the use of the product. Define any safeguards or actions that must be taken,
as well as actions that must be prevented. Refer to any external policies or regulations that
state safety issues that affect the product’s design or use. Define any safety certifications that
must be satisfied.>
3.5.3 Security Requirements
<Specify any requirements regarding security or privacy issues surrounding use of the
product or protection of the data used or created by the product. Define any user identity
authentication requirements. Refer to any external policies or regulations containing security
issues that affect the product. Define any security or privacy certifications that must be
satisfied.>
3.5.4 Software Quality Attributes
<Specify any additional quality characteristics for the product that will be important to
either the customers or the developers. Some to consider are: adaptability, availability,
correctness, flexibility, interoperability, maintainability, portability, reliability, reusability,
robustness, testability, and usability. Write these to be specific, quantitative, and verifiable
when possible. At the least, clarify the relative preferences for various attributes, such as
ease of use over ease of learning.>
3.5.5 Business Rules
<List any operating principles about the product, such as which individuals or roles can
perform which functions under specific circumstances. These are not functional requirements
in themselves, but they may imply certain functional requirements to enforce the rules.>

3.6.Other Requirements
<Define any other requirements not covered elsewhere in the SRS. This might include
database requirements, internationalization requirements, legal requirements, reuse
objectives for the project, and so on. Add any new sections that are pertinent to the project.>
 Chapter 4

Literature Survey

/* This Content only for information,delete it

Related work done in the previous systems with their advantages and disadvantages.
Short description of existing system along with its advantages and disadvantages.

Sample of Literature Survey

Features
Name Of Content Memory Model- Matrix
Hybrid Average RepresentingT
System/ Based based Based Factorizatio Machine
Approac ratings of op of 5 similar
Application Filterin collaborativ Collaborativ n Based Learning
h all movies users
s g e filtering e Filtering Model

Netflix TRUE TRUE TRUE TRUE TRUE TRUE FALSE TRUE

Amazon
Prime TRUE FALSE TRUE TRUE TRUE TRUE FALSE TRUE
Video
Hotstar TRUE TRUE FALSE TRUE FALSE TRUE FALSE TRUE
MX Player TRUE FALSE FALSE FALSE TRUE TRUE TRUE FALSE
Proposed
TRUE TRUE FALSE FALSE TRUE TRUE TRUE TRUE
System
 Chapter 5

System Design

5.1 Project Block Diagram

5.2 GUI of Working System
5.3 UML Diagram
5.3.1 ER Daigram
5.3.2 Use Case Diagram
5.3.3 Sequence Diagram
5.3.4 Class Diagram
5.3.5 DFD Diagram
5.3.6 Activity Diagram

/* This Content only for information,delete it

Firstly Explain your Propsed System shortly in one paragraph and then start Diagram and
Explain Each block of Project Block Diagram */
 Chapter 6

Risk Analysis
6.1 RISK MANAGEMENT W.R.T. NP HARD ANALYSIS
This section discusses Project risks and the approach to managing them.

6.1.1 Risk Identification

For risks identification, review of scope document, requirements specifications and

schedule is done. Answers to questionnaire revealed some risks. Each risk is categorized
as per the categories mentioned in [?]. Please refer table 5.1 for all the risks.
You can refered following risk identification questionnaire.
1. Have top software and customer managers formally committed to support the
project?
2. Are end-users enthusiastically committed to the project and the system/product
to be built?
3. Are requirements fully understood by the software engineering team and its
customers?
4. Have customers been involved fully in the definition of requirements?
5. Do end-users have realistic expectations?
6. Does the software engineering team have the right mix of skills?
7. Are project requirements stable?
8. Is the number of people on the project team adequate to do the job?
9. Do all customer/user constituencies agree on the importance of the project and
on the requirements for the system/product to be built?

6.1.2 Risk Analysis

The risks for the Project can be analysed within the constraints of time and quality

Impact
ID Risk Description Probability
Schedule Quality Overall
1 Description 1 Low Low High High
2 Description 2 Low Low High High

6.2 Risk Analysis

The risks for the Project can be analyzed within the constraints of time and quality
Impact
ID Risk Description Probability
Schedule Quality Overall
 1 Description 1 Low Low High High
2 Description 2 Low Low High High

Table 5.1: Risk Table

Probability Value Description
High Probability of occurrence is > 75%
Medium Probability of occurrence is 26 − 75%
Low Probability of occurrence is < 25%
Table 5.2: Risk Probability definitions [?]

Impact Value Description

Very high > 10% Schedule impact or Unacceptable quality
High 5− Schedule impact or Some parts of the project have low
10% quality
Medium < 5% Schedule impact or Barely noticeable degradation in
quality Low Impact on schedule or Quality can be
incorporated
Table 5.3: Risk Impact definitions [?]

Overview of Risk Mitigation, Monitoring, Management

Following are the details for each risk.

Risk ID 1
Risk Description Description 1
Category Development Environment.
Source Software requirement Specification document.
Probability Low
Impact High
Response Mitigate
Strategy Strategy
Risk Status Occurred
Risk ID 2
Risk Description Description 2
Category Requirements
Source Software Design Specification documentation review.
 Probability Low
Impact High
Response Mitigate
Strategy Better testing will resolve this issue.
Risk Status Identified

6.3PROJECT SCHEDULE

6.3.1Project task set

Major Tasks in the Project stages are:

• Task 1:

• Task 2:

• Task 3:
Risk ID 3
Risk Description Description 3
Category Technology
Source This was identified during early development and testing.
Probability Low
Impact Very High
Response Accept
Strategy Example Running Service Registry behind proxy balancer
Risk Status Identified

• Task 4:

• Task 5:

6.3.2Task network

Project tasks and their dependencies are noted in this diagrammatic form.

6.3.3Timeline Chart
A project timeline chart is presented. This may include a time line for the
entire project. Above points should be covered in Project Planner as
Annex C and you can mention here Please refer Annex C for the planner

6.4 TEAM ORGANIZATION

The manner in which staff is organized and the mechanisms for reporting are noted.

6.4.1 Team structure

The team structure for the project is identified. Roles are defined.

6.4.2 Management reporting and communication

Mechanisms for progress reporting and inter/intra team communication

are identified as per assessment sheet and lab time table.
 Chapter 7

Testing

Testing

The main motive of software testing to check its ability, quality, consistency,
integrity, adaptability, service, error free, and last but not least the customer
satisfaction as per the requirement. Likewise this chapter does the investigation of
said terms over proposed system. This testing can be done on both manually and
using automated tools. Such kind of testing is checks the all requirements of
product such as functional or nonfunctional. After testing, the results generated
called test results are the proof of confirmation of the product ability with sustain
ability, quality and performance.

7.1Test Environment

To perform testing on the system various tools and test files are used for unit
integration, validation, system, and regression testing to intimate the working
condition of the system

7.1.1 Test environment

Testing of proposed system is done with Java Graphical User Interface.

7.1.2 Specialized hardware

No need of any specialized hardware.

7.1.3 Test Data

 In most cases, multiple sets of values or data are used to test the same functionality of a
particular feature. The test data is the system component which needs to be tested.
The components needs to execute and then the that test data is tested by using
different strategies.
7.2 Formal Technical Reviews

Formal technical reviews is nothing but the observation of the execution of software
product which is tested by software engineers. Engineers test the software product to find
bugs in that if any. Such phases are design modules, coding or implementation modules,
input and output modules, inter processing modules, parameters.

TABLE 7.2: Schedule Plan for software testing

1 16th Feb.2021 Unit testing Test software component

2 23rd Feb.2021 Integration testing Test the interface of the
architecture
3 2nd Mar. 2021 Validation testing Check every parameter value
4 9th Mar. 2021 System testing Check process functionality

and functions. The main aim of review team is to early discover the
errors/faults/bugs/leakage and solve it immediately. Therefore, it will not propagate in
next process/module. Review team also test the proposed system is implemented based
on standard specification or not. Such formal technical reviews keep momentum of
proposed system in terms of manageability, backup, resources and continuity of system.

7.2.1 Test Plan and Schedule

- Test Plan
Test plan is document detailing or test activities that systematically test a
system. The plan typically contains a detailed steps of the eventual work flow.

- Test Approach
Proposed system uses a systematic way to implement a system. The waterfall
model is one of the approach which is used for implementation of the proposed
system.
With his reference of the model, the test approach is being carried out at stage
four after the stages like requirement, design, and implementation.
7.3 Software to be Tested

7.3.1 Testing Strategy

Different strategies like unit testing, validation testing, integration testing, and
system testing is used.
1. Unit Testing
Unit testing, also known as component testing refers to tests that verify the functionality
of a specific section of code, usually at the function level. In an object-oriented
environment, this is usually at the class level, and the minimal unit tests include the
constructors and destructors. These types of tests are usually written by developers as
they work on code (white-box style), to ensure that the specific function is working as
expected. One function might have multiple tests, to catch corner cases or other
branches in the code. Unit testing alone cannot verify the functionality of a piece of
software, but rather is used to assure that the building blocks the software uses work
independently of each other. Each module is tested separately.

2. Integration Testing

Integration testing is any type of software testing that seeks to verify the interfaces
between components against a software design. Software components may be integrated
in an iterative way or all together. Normally the former is considered a better practice
since it allows interface issues to be localized more quickly and fixed. Integration testing
works to expose defects in the interfaces and interaction between integrated components
(modules). Progressively larger groups of tested software components corresponding to
elements of the architectural design are integrated and tested until the software works as
a system.
3. Validation Testing
The process of evaluating software during the development process or at the end of the
development process to determine whether it satisfies specified business requirements.
Validation Testing ensures that the product actually meets the client's needs. It can also
be defined as to demonstrate that the product fulfills its intended use when deployed on
appropriate environment.

4. Graphical User Interface Testing

GUI testing is a process to test application's user interface and to detect if application is
functionally correct. GUI testing involves carrying set of tasks and comparing the result
of same with the expected output and ability to repeat same set of tasks multiple times
with different data input and same level of accuracy. GUI Testing includes how the
application handles keyboard and mouse events, how different GUI components like
menu bars, toolbars, dialogs, buttons, edit fields, list controls, images etc. reacts to user
input and whether or not it performs in the desired manner. Implementing GUI testing
for your application early in the software development cycle speeds up development
improves quality and reduces risks towards the end of the cycle. GUI Testing can be
performed both manually with a human tester or could be performed automatically with
use of a software program. TO test whether .net and java GUI is properly managed as
per flow in use case diagram. To test all controls of. In GUI testing check weather. Net
module GUI is been Working properly.

5. High-order or System Testing

This kind of testing focuses on the behavior of the proposed system. All modules are
tested together to check overall functionality. Though, the system will test all integrated
components and verify requirement specifications as per need.
 Table 7.3: Test Cases

Sr. No Module Name Input Expected Result Actual Result Test

Result
TC_00_0 GUI Working Design All the menus and System GUI Pass
1 buttons of the options are
data should work working
properly. properly.
TC_00_0 Dataset Train Dataset System should System is Pass
2 train phishing training
website data phishing
properly. website data
properly.
TC_00_0 Unified coding Input System should do System is Pass
3 URL and proper length and doing proper
URL do unified coding length and do
of URL unified coding
of URL
TC_00_0 URL Features Dataset System should System is Pass
4a Extraction URL extract URL extracting
features properly URL features
properly
TC_00_0 Dataset System should System is not Fail
4b URL extract URL generating
features properly URL Features
properly
TC_00_0 Web Page data Web System should System is Pass
5 Extraction Page extract web page extracting web
data features properly page features
properly

TC_00_0 Probability Dataset System should System is Pass

6 calculation and URL calculate calculating
and Page probability probability
data with properly properly
labels
TC_00_0 Calculate Distance Probabili Distance of URL Distance of Pass
7 ties of should be URL is been
inputs properly properly
calculated calculated
TC_00_0 Classification Similarit Proper Proper Pass
8 y and classification of classification
Distance website should to of website is
values be done. been done.
Sr. No Module Name Input Expected Result Actual Result Test
Result
 TC_00_0 Check that the - It should It is visible Pass
9 screen is be properly
properly visible visible
TC_00_0 Check that the - It should It is Pass
9 buttons and text Be placed properly
boxes are placed properly placed
in proper position

Table 6.4: Test Cases for Installation

Sr. No Module Name Input Expected Actual Test Result

Result Result
1 Check whether the java - It should be It is in- Pass
is installed stalled
properly installed or Not
2 Check whether the Jar - It should be It is in- Pass
File installed stalled
of System is installed or
not
3 If OS is Windows XP - It should be It is in- Pass
then installed stalled
check whether JDK 1.6 or
above is installed or not
4 Check whether the net - It should be It is in- Pass
beans installed stalled
IDE 8.0.2 is installed
5 Check whether jdom - It should be It is Pass
and saxon parser files are present present
present or not
6 Check that System is - It should be It is run- Pass
properly work after above running ning
all in- stallation

Chapter 8
 Conclusion and Future Scope,

/* This Content only for information,delete it

Conclusion should be in 10-15 lines

*/

References
 References

/* This Content only for information, delete it

Format for References

• Author, “Title”, Name of Journal/Transactions/ Book, Edition/Volume, Publisher,
pp.__.,Year of Publication,
• These references must be reflected in text at appropriate places in square bracket.
• In case of web pages complete web page address with assessing date has to be
enlisted.
• List of references should be as per use in the text of the report.

*/