1.

Project Information
1.1

Context and Motivation

The context behind this project AR2Consultancy is very clear and

simple. This is a small scale project for Online consultancy helpline. The basic
idea is that to provide customer a anytime, anywhere online guidance in their
projects and research. The database will maintain the project details
information. This Online consultancy system involves with two types of users.
USER
ADMINISTRATOR

CUSTOMER ROLE:
Customer can view his/her problem details and get help in their
research subjects. The customer can just view the information whereas
he/she could not make changes in the database.

ADMINISTRATOR ROLE:
The administrator plays a vital role in the Online Consultancy system.
The administrator controls the entire database. The report of the research is
generated by the administrator itself. The main role of the administrator is to
guide the user in their research subject and help them through online chat
method. And also guide other in their research subjects to provide
accreditation and approval.

1 | Page

1.2

Objectives

Our project aim to provide anywhere, anytime online guidance in research and
projects. Customer can submit their research subjects and get help from admin.

1.3. Scope
This project would be very useful for those users who wants to have guidance in
their research projects .This will save their time. Further it can also be useful for
anyone who want any help in their projects approval.

1.4. Definitions, Acronyms

The sub-section provides the definitions of all terms, acronyms, and
abbreviations used in this document to understand the SRS properly.
Sr No.
1.

Terms/Acronym
s
User

2.

Administrator

2 | Page

Description
Anyone who is student or want guidance from Admin
related to research subjects.
Super user, adds products and manages the facilities.

2.Functional or Specific Requirements

Required software is for conducting on-line consultancy portal for customers
to have guidance online and for administrator this project aims to provide
guidance in research projects. The system should satisfy the following
requirements:

Administrator Aspect:
1. Taking backup of the database
2. Editing/Deleting/Creating the database.
3. Providing guidance to User.
4. Adding/Editing/Deleting the research proposal.
5. Editing/Deleting/Creating the chat help to User.

Customer Aspect:
1. Submit Research projects.
2. Chat with user for guidance
3. Can send Feedbacks.

Analysis
1. Keeping session track of user activity
2. Recording user responses to the research.
3. Keeping history of responses of all users

2.1. External Interface Requirements

2.1.1. Hardware Interfaces
Server side hardware
Hardware recommended by all the software needed.
Communication hardware to serve client requests

Client side hardware

Hardware recommended by respective clients operating system and
web browser.
Communication hardware to communicate the server.

2.1.2. Software Interface

Server side software
1.
2.
3.
4.

Web server software, Apache Tomcat

Server side scripting tools: PHP
Database tools: MySql.
Compatible operating system: Linux

Client side software

1. Web browser supporting JavaScript, refer Browser Compatibility

2.1.3. Third Party Software Interfaces

None

3.Problem Statement

Problem Statement tells about the problem with existing system.

Here are some key problems are described below:
1. Nowadays as increase in study subjects students are attracting towards
research subjects, but due their unsupportive environment they do not get
required guidance.
2. Every student do not have as skilled faculty or consultant as required in a
research related guidance.
3. There is limited consultancy websites, which provide such guidance to
students.

4.Problem Analysis
4.1

Planning

The key to a successful project is in the planning. Creating a project plan is

the most
important thing you should do when undertaking any kind of
project.
Step 1: Project Goals
A project is successful when the needs of the stakeholders have been
met. A stakeholder is anybody directly or indirectly impacted by the
project. The Goal of our project is to develop a user friendly shopping
Website.
Step 2: Project Deliverables
At the end the project source code along with a report is to be
submitted.

Step3: Project Schedule

Planning & Requirement Phase - 5 Days

Design Phase
- 7 Days
Coding
- 10 Days
Testing
- 3 Days

4.2

Project Requirements

Operating System: Windows 7 or better

Server: Apache Server
Software: XAMPP, Adobe Dreamweaver CS6, MySQL
Hardware: Core 2 Duo Processor, RAM 1GB and Hard-disk 320 GB.

5.Project Design
5.1

High Level Design

A high-level design provides an overview of a solution, platform, system,

product, service, or process.
The highest level solution design should briefly describe all platforms,
systems, products, services and processes that it depends upon and include
any important changes that need to be made to them.
A high-level design document will usually include a high-level architecture
diagram depicting the components, interfaces and networks that need to be
further specified or developed.
The document may also depict or otherwise refer to workflows and/or data
flows between component systems.
In addition, there should be brief consideration of all significant commercial,
legal, environmental, security, safety and technical risks, issues and
assumptions.
Today, most high-level designs require contributions from a number of
experts, representing many distinct professional disciplines.
Finally, every type of end-user should be identified in the high-level design
and each contributing design should give due consideration to customer
experience.

5.2

Low Level Design

We would need to incorporate the above and develop some pseudo-code

incrementally. This will be a very time consuming stage where programming
skills are essential. Also, efficiency issues should be addressed here,
otherwise they will have to wait to a much later stage where the e ort spent
will be greater.
Design of the algorithms for all the different approaches takes place at this
stage. This is a good point to refer to the information sources and reveal
some of the different conventional methodologies that are used to solve the
problem of computing a good play. A simple and useful starting point would
be designing one algorithm that will make an arbitrary placement of a stone
(preferably a random one).
5.2.1

Entity Relationship Diagram

An entity-relationship (ER) diagram, a graphical representation of entities and

their relationships to each other, typically used in computing in regard to the
organization of data within databases or information systems. An entity is a
piece of data-an object or concept about which data is stored.
A relationship is how the data is shared between entities. There are three
types of relationships between entities:

1. One-to-One
One instance of an entity (A) is associated with one other instance of
another entity (B). For example, in a database of employees, each
employee name (A) is associated with only one social security number
(B).
2. One-to-Many
One instance of an entity (A) is associated with zero, one or many
instances of another entity (B), but for one instance of entity B there is
only one instance of entity A. For example, for a company with all
employees working in one building, the building name (A) is associated
with many different employees (B), but those employees all share the
same singular association with entity A.

3. Many-to-Many
One instance of an entity (A) is associated with one, zero or many
instances of another entity (B), and one instance of entity B is
associated with one, zero or many instances of entity A. For example,
for a company in which all of its employees work on multiple projects,
each instance of an employee (A) is associated with many instances of a
project (B), and at the same time, each instance of a project (B) has
multiple employees (A) associated with it.

FIG 1.E.R DIAGRAM

5.2.2 Data Flow Diagram (D.F.D)

A data flow diagram (DFD) is a graphical representation of the "flow" of data through an information system,
modelling its process aspects. Often they are a preliminary step used to create an overview of the system
which can later be elaborated. DFDs can also be used for the visualization of data (structured design).
A DFD shows what kind of information will be input to and output from the system, where the data will come
from and go to, and where the data will be stored. It does not show information about the timing of processes,
or information about whether processes will operate in sequence or in parallel (which is shown on
a flowchart).

FIG2.DATA FLOW DIAGRAM

5.2.3 Use case Diagram
Use Case diagrams show the various activities the users can perform on
the system. The System is something that performs a function. They model
the dynamic aspects of the system. It provides a users perspective of the
system.
Actor:
An actor is a user of the system playing a particular role.
Use case:

Use case is a particular activity a user can do on the system.

Relationship:
Relationships are simply illustrated with a line connecting actors to use
cases.

FIG3.USE CASE DIAGRAM

6.Project Implementation
This portal contains mainly five features in the form of following dashboards:
1.
2.
3.
4.
5.

Home Page
Service Page
Dashboard
Message Panel
Profile Panel

Home Page
- This page is the home page of the webiste, through which anyone can
interface with the content.

Service Page
This is the service page, where all type of services, which are provided
by the website.
Three types of services provided are.
1. Accreditation and Approval
2. Research Writing
3. Research Guidance

Dashborad
This is the main page where the user or admin interface first after login.
From this page user can redirect to any page.

Message Panel

This panel is the main panel which is used to chat with other user and
admin.

Profile Page
This is the page where the user can see or edit their profile and contact
information.

7.Screenshots

About us

Register

Contact

Login

Service 1 Accreditation and Approval

Abet- Accreditation Board for Engineering and

Technology

Naac- National Assessment and Accreditation Council

Nba- National Board of Accreditation

Ugc- University Grants Commission

Aicte- All India Council for Technical Education

Pci- Pharmacy Council of India

Ncte- National Council for Teacher Education

Service 2 Research Writing

Service 3 Research Guidance

Tools - Matlab

8. Testing
8.1
8.1.1

Introduction
Terminology

1. Mistake a human action that produces an incorrect result.

2. Fault [or Defect] an incorrect step, process, or data definition in a program.
3. Failure the inability of a system or component to perform its required function
within the specified performance requirement.
4. Error the difference between a computed, observed, or measured value or
condition and the true, specified, or theoretically correct value or condition.
5. Specification a document that specifies in a complete, precise, verifiable
manner, the requirements, design, behavior, or other characteristic of a
system or component, and often the procedures for determining whether
these provisions have been satisfied.

8.2
8.2.1

Testing Objectives
Direct objectives

1. To identify and reveal as many errors as possible in the tested software.

2. To bring the tested software, after correction of the identified errors and
retesting, to an acceptable level of quality.
3. To perform the required tests efficiently and effectively, within the limits
budgetary and scheduling limitation.

8.2.2

Indirect objectives

1. To compile a record of software errors for use in error prevention (by

corrective and preventive actions).
2. To discuss the distinctions between validation testing and defect testing.
3. To describe the principles of system and component testing.
4. To describe strategies for generating system test cases.
5. To understand the essential characteristics of system.

36

8.2.3

Testing Goals

1. Fault identification: what fault caused the failure?

2. Fault correction: change the system.
3. Fault removal: take out the fault.

8.3

Testing Process

8.3.1

Component (or unit) testing

Testing of individual program components; Usually the responsibility of the

component developer (except sometimes for critical systems).
8.3.2

Integration testing

Involves building a system from its components and testing it for problems
that arise from component interactions.
Top-down
integration
Bottom-up
integration
8.3.3

System testing

Testing of groups of components integrated to create a system or subsystem; The responsibility of an independent testing team; Tests are based on
a system speci cation.
8.3.4

Acceptance testing

Pilot test: install on experimental basis

Alpha test: in-house test
Beta test: customer pilot
Parallel testing: new system operates in parallel with old system
8.3.5

Testing Approaches:

Black box testing

Black box testing also called functional testing and behavioral testing,
focuses on determining whether or not a program does what it is supposed to
do based on its functional requirements. No knowledge of internal structure of
code.

White-box testing
White box testing is testing that takes into account the internal mechanism
of a system or component. White-box testing is also known as structural
testing, clear box testing, and glass box testing.

8.4

Test Plan

A test plan documents the strategy that will be used to verify and ensure
that a product or system meets its design specifications and other
requirements. A test plan is usually prepared by or with significant input from
Test Engineers.
Depending on the product and the responsibility of the organization to
which the test plan applies, a test plan may include one or more of the
following:
Design Verification or Compliance test - to be performed during the
development or approval stages of the product, typically on a small
sample of units.
Manufacturing or Production test - to be performed during
preparation or assembly of the product in an ongoing manner for
purposes of performance verification and quality control.
Acceptance or Commissioning test - to be performed at the time of
delivery or installation of the product.
Service and Repair test - to be performed as required over the service
life of the product.
Regression test - to be performed on an existing operational product,
to verify that exist-ing functionality didn't get broken when other aspects
of the environment are changed (e.g., upgrading the platform on which
an existing application runs).

9.Conclusion
9.1

Conclusion

This project is designed to meet the requirements of Customer. It has been

developed with the use of many programming languages like PHP and HTML
& CSS.
For designing the system we have used simple data flow diagrams. The
Project Is developed in the form of various modules. The project is tested on
the server of blitzinfocom.

10.References
PHP & JavaScript Tutorial: https://www.w3schools.com
Placement Portal: https://www.placement.iitk.ac.in
Xampp : www.apachefriends.org/en/xampp.html
PHP: http://php.net/
MYSQL: www.mysql.com