College Complain & Requisition Automation

COLLEGE
COMPLAIN &
REQUISITION
AUTOMATION
NAME OF STUDENT: KOMAL MAHESHWARI
COLLEGE NAME: SVIT
EN_NO:100410116035
DEPARTMENT: I.T
GUIDE NAME: Mr.BHAVESH PATEL

SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
COLLEGE COMPLAINTS & REQUISITION

AUTOMATION
A PROJECT REPORT
Submitted by
KOMAL MAHESHWARI
In partial fulfilment for the award of the degree

Of
BACHELOR OF ENGINEERING
in
Information & Technology
Sardar Vallabhbhai Patel Institute of Technology, Vasad– 388306
Gujarat Technological University, Ahmadabad

APRIL,2013
SVIT- IT DEPT Page 2

Sardar Vallabhbhai Patel Institute of Technology, Vasad

Information & Technology
2013
CERTIFICATE
Date: 22 / 10 /2013
This is to certify that the project entitled “COLLEGE COMPLAINTS &
REQUISITION AUTOMATION” has been carried out by KOMAL
MAHESHWARI(100410116035) under my guidance in fulfilment of the
degree of Bachelor of Engineering in Information & Technology (7th-8th
Semester) of Gujarat Technological University, Ahmadabad during the
academic year 2013-14.
Guides:
Project Guide : Head of Department:
Prof. Prof.
Mr. Bhavesh Patel Mr. Sameer chauhan
Assistant Professor, IT Department,
IT Department, S.V.I.T. Vasad.
S.V.I.T. Vasad.

ACKNOWLEDGEMENT
No project can be completed by an individual or two people. Many people have
supported and helped us during the development period of our project. The contribution of
each of the person is valuable in the development of this project. It gives us great pleasure
and gratification to present our project, “COLLEGE COMPLAINTS & REQUISITION
AUTOMATION”. We would like to thank all people who were behind and along with us,
and who constantly guided us during the time of difficulties we faced while developing this
project.
My obligation remains due to all those who have directly or indirectly helped me in
successful completion of my project. No amount of words written here will suffice for my
sense of gratitude towards them all.
We would like to express our special thanks to Mr. Bhavesh Patel for helping us
exuberantly in order to develop the project. He is always ready with his invaluable
suggestions through his sheer perseverance.
Lastly, we would express our wholehearted appreciation to the SVIT family for their
active suggestions to the development of our project.
Thanking you,
Komal Maheshwari

ABSTRACT
Our project is to managing the complaint and request. In this project, our aim is
to serve customers (i.e. students and employee) with an automated system.
Using of this individual quotient, complaint of their problem to the respective

department is possible but it takes more time to solve it. Hence, some website
needs other resource to solve problem. In this project whatever student and
faculties complains on our website that directly transfers to the respective
department. So they get a faster reply. As the complaint solution is done can be
inform by mails, phone, message as soon as possible solution is given to any
complaint. This system also accepts requests which are done by faculties. We
solve all the complaints of any students and faculties that are viable. They can
have a one atop solution for all his complaints. Plus we provide possible
solutions of all the complaints on this website that are within the budget of the
college maintenance budget.
In the final part of the project, steps of product are finished by us. Product is
made up of associated documentation and computer programs. SRS, SDD and
STD are the steps of the associated documentation. In these steps, we introduce
characteristics of project like defining requirements, making prototype for
inquirers and scheduling a project. Secondly, our software is a web application.
Internet programming is mostly used in our project. Customers must use
internet for reaching our system. When we look at computer programs, they
include databases, collection of programs which are related to finding optimal
paths with algorithms, graphical user interface for visual projection. There are
databases for storing information about students

Our project includes:
• User Management
• Complaint Management
• Request Management
• Response Management
• Report Generation
LIST OF ABBREVIATIONS
Dept. Department
H/W Hardware
S/W Software
Admin Administrator
Config. Configuration
GUI Graphical User Interface
ERD Entity Relationship Diagram
OS Operating System
IEEE Institute of Electrical & Electronics

Engineers

LIST OF SYMBOLS
Use Case Diagram:-
System
Boundary
Use Case
Actor
Uses
Data Flow Diagram:
Actor
Data
Process
Data Flow
Data Store

LIST OF TABLES
Table No. Table Name Page No.
5.4.1 Table of User-Details……………………………………………….41
5.4.2 Table of Login Information………………………………………...41
5.4.3 Table of Subject……………………………………………………42
5.4.4 Table of Batch Subject…………………………………….............42
5.4.5 Table of Batch……………………………………………………..42
5.4.6 Table of Batch User……..……………………………..……….....42
5.4.7 Table of Result………….…………………………………………43
5.4.8 Table of Attendance…………………………………………........43
5.4.9 Table of Document……..……………………………………........43
5.4.10 Table of Forum………..…………………………………………..44
5.4.11 Table of News………..………...…………………………............44
5.4.12 Table of Forum User………….…………………………………..44

LIST OF FIGURES
Figure Name Page No.
• Software Process Model(Incremental model)………………………………..04
• ASP.NET Architecture……………………………………………………….06
• Timeline Chart…………………………………..........…………………......10
• 3-Tier Architecture…………………………………………………….…….22
• Use case Diagram for Login…………………………………………………24
• Use Case Diagram for Manage complaints……………………………........25
• Use Case Diagram for Request management……………………………….26
• Use Case Diagram for User Management…………………………………..26
• Use Case Diagram for Report management………………………………...28
• Activity Diagram for Login…………………………………………………29
• Activity Diagram for Complaints…………………………………………..30
• Activity Diagram for Request………………………………………………31
• Sequence Diagram for Login……………………..………………………...32
• Sequence Diagram for Complaints………………………………………...33
• Sequence Diagram for Request……………………………………………..34
• Sequence Diagram for Report Generation……………………………….....35
• Sequence Diagram for User Management……………………………….....35
• E-R Diagram……………………………………………………………...36

TABLE OF CONTENTS
• ACKNOWLEDGEMENT...............................................................................i
• ABSTRACT………………………………………………………................i
• ABBREVIATIONS…………………………..………..………………….....ii
• LIST OF SYMBOLS......................................................................................iv
• LIST OF TABLES..........................................................................................v
• LIST OF FIGURES…………………………..………………..……..……..vi
1. INTRODUCTION........................................................................................1
1.1 PROJECT DEFINITION……………………………………1
1.2 PURPOSE…………………………………………………..1
1.3 PROJECT OBJECTIVE…………………………………….3
2. BRIEF HISTORY OF WORK.................................................4
2.1Software Process Model................................…………................4
2.1.1 Advantages of Process Model……………...6
2.1.2 Disadvantages of Process Model……………..6
• Reasons to choose process model……………………………………….7

• Tools Technology…………………………………………………………...7
• Hardware Requirement............................................................................7
• Software Requirement….........................................................................7
• Technology Review…………………………………………………….7
• Timeline Chart………………………………………………………..10

3. LITERATURE SURVEY.............................................................................................11
Literature Review ..........................................................................................11
4. SYSTEM ANALYSIS ...............................................................................................14
Study of Current System.......................................................................................14
4.1.1 about manual system.....................................................................................14
4.1.2 Problems and weaknesses of current system……..……………………14
• Requirements of New System...................................................15

• Functional requirements………………………….……...15
• Non-functional requirements……………………………………………17
• Feasibility Analysis ...............................................................................18
5. SYSTEM DESIGN...................................................................................................22
• Introduction to System Design…………………………………………22

• Software Architecture…...........................................................................22
• Data Tier……….......................................................................................23
• Logical Tier……......................................................................................23
• Business Tier………………………………….…………………............23
• Presentation Tier………………………….……………………………..23
• UML Diagrams………………….............................................................24
• Use case diagram………..........................................................................24
• Activity Diagram ….................................................................................27
• Sequence Diagram…………………........………………........................33
• E-R diagram……………..……………....................................................35
• Data flow diagram……………………………….………..…………….37
• Database Design…………………………………………………………39
6. DATA DICTIONARY………………………………………………………56

7. USERINTERFACE DESIGN……………………………………………… 63
8. TESTING…………………………………………………………………….75
9. REFRENCES AND BIBLOGRAPGY………………………………………………………..79

CHAPTER-1
INTRODUCTION

• Purpose
The purpose of Software Requirement Specification (SRS) is to give the introduction &
detailed description of the “REQUISITION COMPLAINT AUTOMATION” system. The
main purpose to make this system is to solve all the requirement and complaints as well as
request of students and faculties. Students and faculties have complaints so they do by
lodging it on the network and this system stores all the complaint and request related to
college and employee give the response on it. This SRS will allow for a complete
understanding of this system. This SRS will provide the foundation for the project.
• Product Scope
The main goal of this project is to develop website for employee and students of college for
complaints and requests. Employee/student wherever he/she can request about her/his need.
It can be related to classroom bench , fan etc. if they are in not working condition or it can be
water related anything. Employee can do complaint about student misbehaviour or if he/she
wants a leave for few days he/she can request via this system.
The main scope of this system is that everyone can easily access and response he/she may
immediately get so, it is time saving. If anyone lost his/her thing so via webcam footage we
can easily find.
Proposed system:-
• Manage complaints of faculties and students
• Manage Requests
• Manage all the data of the students and faculties who are registered in
system
• Give the response of complaints and requests
• Give the status of the complaints

• Advantages:-
• User friendly interface
• Fast access
• Less error
• More storage capacity
• Search facility

CHAPTER-2
BRIEF HISTORY OF
WORK

2.1 Software Process Model

A process model is a development strategy that is used to achieve a goal that satisfies the
requirement abiding by the constraints. There are many types of software process model,
which are linear sequential model, RAD model, Incremental model, and Spiral model. But
we have selected the Incremental Model for our project.
The Incremental Model:-

The Incremental model combines elements of the linear sequential model (applied
repetitively) with the iterative philosophy of prototyping. Referring to Figure, the incremental
model applies linear sequences in a staggered fashion as calendar time progresses. Each
linear sequence produces a deliverable “increment” of the software.
Figure 1 Incremental Model

For example, word-processing software developed using the incremental Paradigm might
deliver basic file management, editing, and document production functions in the first
increment; more sophisticated editing and document production capabilities in the second
increment; spelling and grammar checking in the third increment; and advanced page layout
capability in the fourth increment. It should be noted that the process flow for any increment
can incorporate the prototyping paradigm.

When an incremental model is used, the first increment is often a core product. That is, basic
requirements are addressed, but many supplementary features (some known, others unknown)
remain undelivered. The core product is used by the customer (or undergoes detailed review).
As a result of use and/or evaluation, a plan is developed for the next increment.
The plan addresses the modification of the core product to better meet the needs of the
customer and the delivery of additional features and functionality. This process is repeated
following the delivery of each increment, until the complete product is produced.
The incremental process model, like prototyping and other evolutionary approaches, is
iterative in nature. But unlike prototyping, the incremental model focuses on the delivery of
an operational product with each increment. Early increments are stripped down versions of
the final product, but they do provide capability that serves the user and also provide a
platform for evaluation by the user.
Incremental development is particularly useful when staffing is unavailable for a complete

implementation by the business deadline that has been established for the project. Early
increments can be implemented with fewer people. If the core product is well received, then
additional staff (if required) can be added to implement the next increment. In addition,
increments can be planned to manage technical risks.
For example, a major system might require the availability of new hardware that is under
development and whose delivery date is uncertain. It might be possible to plan early
increments in a way that avoids the use of this hardware, thereby enabling partial
functionality to be delivered to end-users without inordinate delay.
Software Requirement Analysis
The requirement gathering process is focused specially on software. To understand nature of

program to be built information domain as well as required functions, Behavior, performance
and interface.

Design
It is multi step process that focuses on four distinct attributes of a program; Data structure,
software architecture, interface representation and procedure details.
Code Generation
The design must be translated into a machine-readable form.
Testing
The testing process is focused on the logically internal of the software. It ensures that all the
statement have been tested and conducted test to uncovered errors and also ensures that
defined input will produces actual results, which were required.
2.1.1 Advantages of Incremental Process Model

• After iteration faulty software piece can be identified easily.
• Unlike other models this model gives a deliverable product after iteration.
• Increments can be planned to manage risks.
• Testing may be easier on smaller portion of the system.
• A usable product is available with the first release, and cycle results in additional
functionality.
2.1.2 Disadvantages of Incremental Process Model

• Resulting cost may exceed the cost of organization.
• Problem may arise regarding to system architecture.
• Because development is spread out over multiple iterations, interfaces between

modules must be well defined in the beginning.
• Users are required to learn how new system with each deployment.
2.1.3 Reasons to Choose Incremental Model

• Our team is small made of three members.

• If company or user is not satisfied with core product than we can provide better
solution in next increment.
• On demanding upon user’s requirement we can add those functionalities.
• Basic requirement for the core products are very clear.
• Using this model we can easily expand our model.
• As we are doing first time the implementation of project we can fix our mistakes in
following iterations.
2.2 Tools and Technology

2.2.1 Hardware requirements
Hard disk : 40 GB
RAM : 1 GB
Processor Speed : 1.6 GHz
Processor : Pentium IV or above
2.2.2 Software requirements
Front End : Microsoft Visual Studio 2010
Language used : C#.NET
Back End : SQL SERVER 2010
2.2.3 Technology Review
(A) Overview of .NET Framework
The .NET Framework (pronounced dot net) is a software framework that runs primarily
on Microsoft Windows. It includes a large library and supports several programming
languages which allow language interoperability (each language can use code written in
other languages). Programs written for the .NET Framework execute in a software
environment (as contrasted to hardware environment), known as the Common Language
Runtime (CLR), an application virtual machine that provides important services such as

security, memory management, and exception handling. The class library and the CLR
together constitute the .NET Framework.
Figure 2 MS .NET Architecture
The .NET Framework's Base Class Library provides user interface, data access, database
connectivity, cryptography, web application development, numeric algorithms, and network
communications. Programmers produce software by combining their own source code
with the .NET Framework and other libraries. The .NET Framework is intended to be
used by most new applications created for the Windows platform. Microsoft also produces
a popular integrated development environment largely for .NET software called Visual
Studio.
• ASP.NET
ASP.NET is a Web application framework developed and marketed by Microsoft to allow
programmers to build dynamic Web sites, Web applications and Web services. It was first
released in January 2002 with version 1.0 of the .NET Framework, and is the successor to
Microsoft's Active Server Pages (ASP) technology. ASP.NET is built on the Common
Language Runtime (CLR), allowing programmers to write ASP.NET code using any

supported .NET language. The ASP.NET SOAP extension framework allows ASP.NET
components to process SOAP messages.
• MAIN FEATURES OF ASP.NET:-
• Easy Programming Model
• Flexible Language Options
• Tool Support
• Rich Class Framework
• Compiled execution
• Rich output caching
• Web-Farm Session State
• Enhanced Reliability
• Memory Leak, Deadlock and Crash Protection
• Easy Deployment
• Dynamic update of running application
(B) Language: C#.NET
C# (pronounced see sharp) is a multi-paradigm programming language encompassing

strong typing, imperative, declarative, functional, generic, object- oriented (class-based),
and component-oriented programming disciplines. It was developed by Microsoft within its
.NET initiative and later approved as a standard by Ecma (ECMA-334) and ISO
(ISO/IEC 23270). C# is one of the programming languages designed for the Common
Language Infrastructure. C# is intended to be a simple, modern, general-purpose,
object-oriented programming language.
• MAIN FEATURES OF C# :-
• Simple
• Modern
• Object Oriented
• Type Safe

• Interoperability
2.3 Timeline Chart:
Task June- August- October- December- April

July September November April
Initial discussion •
with company
System Analysis •
Requirement •
Gathering and
System Design
Coding and •
Implementation
System Testing •
Documentation • • • • •
Figure 3 Timeline Chart

Chapter-3
LITERATURE SURVEY

3.1 Literature Review:

Notably, Student Information Portal incurs such application software designed for
educational establishments to manage student data. Student Information Portal provide
capabilities for entering student test and other assessment scores, building student schedules,
tracking student attendance as well as managing many other student-related data needs within
the institution university.
Moreover, before universities have created their own bespoke student record systems, but
with growing complexity in the business of educational establishments, organizations now
choose to buy customizable within the shelf software. It can be that, modern student
Information Portal s are usually server-based, with the application residing on central
computer server and are being accessed by client applications at various places within and
even outside the school. During the year 2010, student Information Portal s have been
changing and are fast adopted through the presence of a web medium as a channel for
accessing student Information Portal without any hassle upon viewing student details and
information.
Ideally, educational institutions are under constant pressure to demonstrate both willingness
and capacity to incorporate the latest developments in student Information Portal s along with
communications technology supporting various teaching ways. Student Information Portal
application can be appealing to students and to the academic faculty as well as the parents.
Thus, believing that technology is the repository of the bulk of the information that underpins
society’s major enterprises and concerns and the medium of communication through which
Students can interact with one another.
The strong implication for education is that skills in effective online searching should occupy
more value and more important place within the education curriculum at all levels wherein
the adaptation of Student Information Portal is most valued for academic effectiveness. From
the perspective of the individual student, Student Information Portal incorporates enormously
increased potential for representing and manipulating information in range of structured
education paradigms and strategic study forms as appropriate for a justifiable application of
diverse learning styles. Furthermore, the student Information Portal s do provides greater
range of ways through which learners can express their knowledge, including the publication
of multimedia presentations to the world at large through the Internet. Aside, some of the
information system know-how needs that certain students must grapple with inclusion to

discovering how to complete comprehensive reviews of such research studies, learning how
to evaluate sources within the context of their projects, and properly citing and including
these sources within their theses or dissertations.
Then, because the Student Information Portal process is typically completed early into
students’ school career and encapsulates each of the facets of knowledge built up and literacy
value, including learning what type of Student Information Portal is available, finding and
accessing system sequence, evaluating tools for the information and then synthesizing the
student Information Portal into certain end product for a better career patterns as it seemed
like the ideal project to focus Student Information Portal and relate it to sample literacy
instruction around. While the students had all performed database searches before, they were
less likely to have taken advantage of the search management tools available to them through
educational databases, how to set up automatic searches to help streamline the research
process. Like for example, there discusses the benefits of using such bibliographic
management software system in order to help illustrate more sophisticated ways of
organizing their research. Before the students came to the workshop, they were asked them to
fill out brief pre-assessment surveys designed to provide acceptable profile details including
their year in school, whether or not they were pursuing their college degree and possible
departmental affiliation.
Thus, pointing towards Student Information Portal within the knowledge of education
services as utilized that include databases used and whether or not students were familiar with
curriculum software packages. Truly, it is crucial for the advancement of informative
research within composed disciplines and the continued successful integration of Student
Information Portal as applied in the Philippine setting with resources to higher education
systems determining that certain group of students can acquire and gain effective knowledge
literacy skills through the Student Information Portal process and understanding the value of
education services crafted to provide best teachings as possible. Then, for Student
Information Portal assumption, there is a need to engage students with academic assessment
such as upon helping students start thinking about what they would like to learn with regards
to a better research investigation and knowing what the gaps in students’ understanding might
be. Also, encourage the use of Student Information Portal in parallel to active learning style
which allows students to interact with their classmates and does help the instructor facilitate
an enhanced learning experience through Student Information Portal application mode and to

finally emphasize the value of making student information connection with a subject teacher
for instance geared upon for in-depth education success.

CHAPTER-4
SYSTEM ANALYSIS

4.1 Study of Current System

4.1.1 About Manual System
System Analysis is a detailed study of the various operations performed by a system and their
relationships within and outside of the system. Here the key question is- what all problems
exist in the present system? What must be done to solve the problem? Analysis begins when a
user or manager begins a study of the program using existing system.
Now a days, most of the existing system are static, which provides only the information about
their Institute. In such systems students & employees can’t do complain and request online
they do this all on paper & even they can’t share their views publically. So we have develop
this system.
• Problems and weaknesses of current system
Disadvantages of manual system:

• Require more accuracy
• Require more resources
• Require to long procedure to be completed (manual queue procedure)
• Not Interactive
• High probability of errors
• Maintenance is also problem
• No User friendly interface
• Difficult access to database
• Less Storage Capacity
• No Search facility
• Slow transaction

Advantages of software over existing manual system:
• User friendly interface
• Fast access to database
• Less error
• More Storage Capacity
• Search facility
• Look and Feel Environment
• Quick transaction
• Requirement of new system
4.2.1 Functional requirement modules:-

MAIN MODULES OF SYSTEM:-
• User Management
• Complain Management
• Request Management
• Response Management
• Report Generation
User Management
• The personal details can be store in the database of the student and employees.
• In this admin can delete, update, insert the data of the user and he/she can modify
the data as per requirement.
• This database contains the admin, employee, student’s information.

Complain Management:
• This module that manage the complain which were done by the employees. This
complains is related to the college. Normally they are facing the in college and it
will forward to the HOD and HOD forward it to the related complain
coordinators.
Request Management
• This module that manage Request which were done by the employees. This Request is
related to the college. Normally they are facing the in college and it will forward to
the HOD and HOD forward it to the related request coordinators.
• This complains related to the networking and college resources requirement.
Response Management:
• This module is done by the coordinators and purchase department. Coordinators

give response of the complains and purchase department give response by
providing resources.
Report Generation:
• After giving response report will generated in which all the data are included by
whom the complain and request is done who gave the response what the price of
the resource and name recourses.

4.2.2 Non-Functional Requirements:
The quality in software development process is by periodic reviews documentation and

verification at all appropriate stages. Software engineering standards should be followed
throughout the development process. The quality in software product is ensuring by
embedding fooling quality attribute in the software package.
Readability:
Appropriate comments in the project source code will be provided for readability so that the
user can easily read and understand the project if need be. So the project will be helpful for
interested person. The application should be functionally correct as a wrong output of query
has no significance. Reliability is a must in the application to make it worth for the
employees. A great degree of care has to be taken to ensure minimum / zero defects in the
code.
Modularity:
The project will be divided into different modules so as to provide easy understanding and
debugging of the system.
Modifiability:
With the help of modularity and readability of the source code of the program the system will
be easy to modify in the future as and when needed.
Portability:
The project will be easy to implement on the client system which satisfy the minimum
hardware requirement.
Easy to use:
This project will be easy to use and so shall incorporate self-explanatory GUI.
Maintainability:
This project will provide easy maintenance of the well data. When application is used, it has
to be maintained. There could be additional requirements in terms of added functionality or

feature. As the application is not to be maintained by the developers, the code should be less
complex such that it can be easily understandable by the relevant person for modification.
Fault Tolerance/ Error Reporting:
Since the application will be used by users and by developers it might be possible that
operation might result into errors. The application should provide the user friendly error
messages and fault tolerance facility whenever any error occurs.
4.3 Feasibility Analysis
Whatever we think need not be feasible .It is wise to think about the feasibility of any
problem we undertake. Feasibility is the study of impact, which happens in the organization
by the development of a system. The impact can be either positive or negative. When the
positives nominate the negatives, then the system is considered feasible. Here the feasibility
study can be performed in two ways such as technical feasibility and Economical Feasibility.
Feasibility Study:-
1. Technical Feasibility
2. Economic Feasibility
3. Operational Feasibility
4. Schedule Feasibility
• 1. Technical Feasibility: -
Developers of computer-based system are optimists by nature. During an evaluation of
technical feasibility, a cynical, if not pessimistic attitude should prevail. Misjudgment at this
stage can be disastrous. The technical issues that came up during the analysis were…
What is the hardware and software requirement for the production was the first major issue of
the discussion. My implementation tool is .Net framework and I have used SQL Server as
my database server. As I have implemented my project successfully, it is technically
feasible. Some of more technical feasibility points are mentioned below.

• All the technical support I want for this project is easily available and also very easy to
maintain.
• I am aware of the technologies, which are used, in my project.
2. Economical Feasibility: -
Among the most important issues in feasibility study is “Cost Benefit Analysis”, an
assessment of the economic justification for a web-based product. The cost involved in
designing and developing a product should be a good investment for the any organization.
The financial benefits must be justified by the cost. Some of the points for Economical
Feasibility related to our project are mentioned below:
• The productivity of the scatter organization better Control over the different location’s
work done by providing them online services at their ease.
• Don’t have to maintain bunch of files of records and can maintain it online and in
integrated way.
• The availability of the required hardware and software used to develop our system make
it economically feasible moreover whole project is completed within given time period,
which also affects economy.
• As development tools and software are free of cost there is no burden to buying them.
• As most of work is carried our online, less paper work is required which is also
economically feasible.
One Time Cost: It includes Manpower cost, resources cost and software cost.
Man Power Cost: As I have worked for 5 month for this project, the manpower cost is 2
(persons) * 12(Months for work) * 30 (days for month) = 720 total days.
Resources Cost: The resources acquired for software development also has cost on account.
It can be countable as no. of Hours per day * No of Days=Total Hour Resources used. 8 *
720=5760
Software Cost: Generally all software has 2 years lifetime and average 3 projects during 2
years are developed. So for each project the software cost is 1/3 of total software cost.

3. Operation Feasibility: -
The new product is beneficial only if it satisfy the client’s requirements; in such a way that
resources utilization and optimum outcome is justifies. A new product should not only be
robust but also be able to work simultaneously with the other products.
Our product is implemented in ASP.Net environment, which has very powerful GUI features.
I also tried my best to provide very easy and user friendly GUI. Efforts were also made to
optimize the human efforts in data collections, storage, retrieval, security and presentation
and to have the generalize product for the clients at their disposal. As the area that our
product focuses is production organizations, so it contains many industrial terms but I have
also taken into account the novice user for concern. Any user who is familiar to this type of
terms can easily operate our product. Our product is being developed for the persons who
have so much experience in this field, so they hardly find any difficulties to operate.
If the user is novice (who has little knowledge about the system) requires a bit of training to
understand how the product works. So our system seems totally feasible when it is going
when it is going into actual operation. Also the performance is the major issue concerned
with the product development.
4. Schedule Feasibility: -
It is very important that project gets completed in allotted time. I had project duration of 12
months. It is a very huge amount of time; as a result the project within the allotted time
period was possible. Also I have followed the incremental model for the software
development hence I will divide it in various stages and achieve the objective of the stage in
predefined time limit. So my project is feasible with respect to schedule.

CHAPTER-5
SYSTEM DESIGN

5.1 Introduction to System Design
System design is a process through which requirements are translated into a representation of
software. Initially the representation depicts a holistic view of software. Subsequent
refinement leads to a design representation that is very close to source code. Design is a place
where quality fostered in software development. Design provides us with representation of
software that can be assessed for quality; this is the only way that can accurately translate the
customer requirements into finished software product or system.
5.2 Software Architecture
3-Tier architecture:-
A 3-tier application is a program which is organized into three major disjunctive tiers.
These tiers are,
• Presentation Tier (Front end)
• Logical Tier (Middleware)
• Data Tier (Backend)
Each layer can be deployed in geographically separated computers in a network.
Some architects divide Logic Tier in to two sub tiers i.e. Business and Data Access
Tiers, in order to increase scalability and transparency. The tiers can be deployed on
physically separated machines.
Figure 4 3-Tier Architecture
The characteristic of the tier communication is that the tiers will communicate only to
their adjacent neighbours. For an example, The Presentation Tier will interact directly
with the Business Tier and not directly with Data Access or Data Tiers.

5.2.1 Data tier
This Tier is responsible for retrieving, storing and updating from Information therefore
this tier can be ideally represented through a commercial database. We consider stored
procedures as a part of the Data Tier. Usage of stored procedures increases the
performance and code transparency of an application.
5.2.2 Logical tier
This is the brain of the 3.Tier Application. Some architects do not make any distinction
between Business Tier and Data Access Tier. Their main argumentation is that
additional tiers will screw down performance. I think that we will have more
advantages, if we separate Logical Tier in to Business Tier and Data Access Tier.
Some of these advantages are:-
• Increases code transparency
• Supports changes in Data Layer. You can change or alter database with out
touching the Business Layer and this would be a very minimum touch up.
5.2.3 Business tier
This sub tier contents classes to calculate aggregated values such like total revenue,
cash flow and edit and this tier doesn’t know about any GUI controls and how to
access databases. The classes of Data Access Tier will supply the needy information
from the databases to this sub tier.
5.2.4 Presentation tier
This tier acts as an interface to Data Tier. This tier knows, how to (from which
database) retrieve and store information. This tier is responsible for communication
with the users and web service consumers and it will use objects from Business Layer
to response GUI raised events.

5.3 UML Diagrams
5.3.1 Use case diagrams

A use-case diagram shows a number of external actors and their connection to the use cases
that the system provides. A use case is a description of a functionality that the system
provides. The use cases are described only as viewed externally by the actor and do not
describe how the functionality is provided inside the system.






5.3.2 Activity diagram

An activity diagram provides a view of the behaviour of a system by describing the sequence
of actions in a process. Activity diagrams are similar to flowcharts because they show the
flow between the actions in an activity; however, activity diagrams can also show parallel or
concurrent flows and alternate flows.
In activity diagrams, you use activity nodes and activity edges to model the flow of control
and data between actions.
Activity diagrams are helpful in the following phases of a project:

Login:
Log_In
Enter Name &

Password
Password
Incorrect
Security Quetions
Correct
Incorrect
View Account
Correct
Change Password

Complain:
Enter
Complain
Post complain
Not Accept
Reject Accept
Forward
complain
Review
complain
Responce

Request:
Enter Request
Post Request
Not Accept
Reject Accept
Forward
Request
Review
Request
Responce

Log_in:

Complain:

Request:

User Management:

Report Generation:

5.3.4 E-R diagram

Entity Relationship model:-
The Entity-Relationship data model is based on a perception of a real world,
which is consists of set of basic object called entities and relationships among these
objects. An entity is an object that exists and is distinguishable from other
objects/entity is an object as a concept meaningful to the organization. An entity set is
a set of entities of the same type. A primary key is an attribute which when take,
allows us to identify uniquely an entity in the entity set.


CHAPTER 6:
DATA DISCTIONARY

6.3 Database Design
6.3.1 Data Dictionary

A data dictionary or database dictionary is a file that defines the basic organization of a
database. A database dictionary contains a list of all files in the database, the number of
records in each file, and the names and types of each data field. Most database management
systems keep the data dictionary hidden from users to prevent them from accidentally
destroying its contents. Data dictionaries do not contain any actual data from the database,
only bookkeeping information for managing it. Without a data dictionary, however, a
database management system cannot access data from the database.
Database users and application developers can benefit from an authoritative data dictionary
document that catalogs the organization, contents, and conventions of one or more databases.
This typically includes the names and descriptions of various tables and fields in each
database, plus additional details, like the type and length of each data element. There is no
universal standard as to the level of detail in such a document, but it is primarily a distillation
of metadata about database structure, not the data itself. A data dictionary document also may
include further information describing how data elements are encoded. One of the advantages
of well-designed data dictionary documentation is that it helps to establish consistency
throughout a complex database, or across a large collection of federated databases.
The efficiency of an application developed using RDBMS mainly depend upon the database
tables, the fields in each table and the way the tables are opened using the contents in them to
retrieve the necessary information. Hence a careful selection of tables and their fields are
imperative.
The data dictionary consists of different major elements like Data Elements, Data Store
[Tables Used], Data Flow, Processes and other External entities used in the system. The data
dictionary stores details and description of these elements.
It is developed during data flow analysis and assists the analysts involved in determining the
system requirements.
Analysts use data dictionary for the following important reasons:
• To manage the details in large system.

• To communicate a common meaning for all system elements.
• To document the features of the system.
• To facilitate analysis of the details in order to evaluate the characteristics and

determine where system changes should be made.
• To locate errors and omissions in the system.
The data dictionary contains different types of descriptions for the data flowing through the
system:
Data Elements is the most fundamental level, which is also considered as the building block
for all other data in the system. It refers to all the different data used like fields, data item, etc.
to make the system fully functional irrespective to the table used in the system. Here all the
different type of fields used to make table are written sequentially without referring to the
tables. This process helps in the process of Normalization of tables.
Next to Data Elements comes the Data storage which provides the information of where and
how each data element is stored in which table and it also give information of any constraints
if there. This step also gives knowledge of different data types used for different field and
their size. All the normalized tables are showed in data storage.
The database tables used in this system are created keeping the above points in mind. The
tables used are given below.

Table 1: Admin Table

Name Data Type Description
UserName NVarchar Admin’s Unique id
Password NVarchar Admin’s Password
Name NVarchar Admin’s Name
Table 2: Student Table

Name NVarchar Name of student
Department NVarchar Students’s department
Enrollment_No Numeric Students’s uniq no
Semester NVarchar Students’s semester
Password NVarchar Student’s password
Email_id NVarchar Student’s id
Forgot_password NVarchar Question when username or

password is forgotten

Table 3: Employee Table

Name NVarchar Name of Employee
Department NVarchar Employee’s department
Emp_id Numeric Employee’s uniq no
Emp_designation NVarchar Employee’s Designation
Password NVarchar Employee’s password
Email_id NVarchar Employee’s id
Forgot_password NVarchar Question when username or

password is forgotten
Table 4: Application

Application NVarchar Name of application whether it
is complain or request
Application_no Numeric Uniq_no
Sender’s uniq_id Numeric Uniq_no of sender

Table 5: complaint Box

User_id Numeric To identify who did complain
Complain_id Numeric Complain id
Subject NVarchar type of complain
Complain Description Nvarchar It shows that what is the
problem with existing
Table 6: Request

User_id Numeric To identify who did complain
Request_id Numeric Request id
Name of Item NVarchar Required item name
Purpose of item to be NVarchar It give the answer of Why this
purchased item needed
Total Quntity of items Numeric Total items to be require
Date of last purchase DateTime When last item purchased
Estimated price of item Numeric Price of item which is needed

Table 7: CCTV Footage

User_id Numeric Uniq_id of user
Location of footage NVarchar Of which area footage you
required
Reason for this request NVarchar It gives reason that why this
required
Timing DateTime It gives timing of footage that
needed
Losted item NVarchar It gives name of item which id
losted that’s why footage is
needed
Table 8: SMS

User_id Numeric Uniq_id of user
Name of Students NVarchar Name of students to send
message
Message NVarchar Whole Message to send
students
Phone_nos Numeric Student’s phone_nos

CHAPTER 7:
USER INTERFACE DESIGN

USER INTERFACE DESIGN:

HOME PAGE:

LogIn:

REGISTRATION:

FORGOT PASSWORD:

CONTAVT US:

COMPLAIN FORM:

SPORTS ITEM FORM:

COORDINATOR PAGE:

REQUEST:

HALL:

CCTV FOOTEGE:

CHAPTER:8
TESTING

8.1 Testing
Software testing is a critical element of software quality assurance and represents the ultimate
review of specification, design and coding. In fact, testing is the one step in the software
engineering process that could be viewed as destructive rather than constructive.
A strategy for software testing integrates software test case design methods into a well-
planned series of steps that result in the successful construction of software. Testing is the set
of activities that can be planned in advance and conducted systematically. The underlying
motivation of program testing is to affirm software quality with methods that can
economically and effectively apply to both strategic to both large and small-scale systems.
8.2 Types of Testing

8.2.1 White Box Testing
White box testing (also called structural testing and glass box testing) is testing that takes into
account the internal mechanism of a system or component. White box testing focuses on the
internal structure of the software code. The white box tester (most often the developer of the
code) knows what the code looks like and writes test cases by executing methods with certain
parameters.
This type of testing ensures that,
• All independent paths have been exercised at least once

• All logical decisions have been exercised on their true and false sides
• All loops are executed at their boundaries and within their operational bounds
• All internal data structures have been exercised to assure their validity.
8.2.2 Black Box Testing
Black box testing (also called functional testing) is testing that ignores the internal
mechanism of a system or component and focuses solely on the outputs generated in response
to selected inputs and execution conditions. With black box testing, the software tester does
not (or should not) have access to the source code itself. The code is considered to be a “big
black box” to the tester who can’t see inside the box. The tester knows only that information
can be input into to the black box, and the black box will send something back out.

8.3 Testing Done At Different Levels
8.3.1 Unit Testing
• Verification of Code
• Checking of Internal logical errors.
Testing Method: White Box Testing

Although this level of testing was performed parallel with coding. It was assured that
another round of testing shall make modules error-free. We’ve used Microsoft Visual
Studio’s Debugger to test logic and coding.
8.3.2 Integration Testing

• Uniformity between all modules
• Error-free integration
Testing Method: White Box and Black Box Testing

Since the system units were developed as modules assigned between all three partners
the level of testing was crucial for us. The integration testing was performed for this system
when all the modules were to make it a complete system. After Integration the project works
successfully.
8.3.3 System Testing

At this level of testing system as a whole was tested for various errors like
• Field level validations
• Blank and mandatory Validations
Testing Method: Black Box Testing

Our system has been tested by using validation testing and found to be working
satisfactorily.
For example, in this project validation testing is performed in Student registration module.
This module is tested with the following valid and invalid inputs for different fields like
Student Name, Email Id, Mobile Number etc.

8.3.4 Acceptance Testing

Acceptance testing is formal testing conducted to determine whether or not a system
Satisfies its acceptance criteria (the criteria the system must satisfy to be accepted by a
Client) and to enable the customer to determine whether or not to accept the system.
Testing Method: Black Box Testing

So far the data was used were relevant and dummy but at this level of testing the
original data of the client was taken into consideration. The project gave successful response.
Sr. No. Screen/Test Test Case Expected Actual Result

C#.NET Page Result
1 Windows form Login If User id & As Expected
Password Valid
then user Logs
in. If not Error
Msg. Displayed
2 Windows form Forget If user-id As Expected

password and /Password is
user id forgotten then
answering the
question and
providing
email-id
3 Windows Form Complain If user enters As Expected

invalid
complain it will
show message
4 Windows Form Request If user enters As Expected

invalid
complain it will
show message.
5 Windows Form Admin Login If Admin id & As Expected

Password Valid
then Admin
Logs in. If not

CHAPTER:9
REFRENCES AND
BIBLOGRAPGY

References:
• http://www.projects-forum.com/Thread-student-information-system-Project-report
• www.developer2blog.com
• http://aspsnippets.com/Articles/Upload-images-to-folder-and-display-uploaded-
images-in-ASPNet-GridView-using-C-and-VBNet.aspx
• www.stackoverflow.com
• http://mcaprojects.org/viewproject.php?topic=168
• www.codeproject.com
• http://www.mikesdotnetting.com/Article/125/ASP.NET-MVC-Uploading-and-
Downloading-Files
• http://forums.asp.net/t/1531645.aspx/1
Bibliography:
The following books were referred during the analysis and execution phase of the project
• The Complete Reference ASP.NET(3rd Edition) by Matthew MacDonald, Tata

McGraw Hill Publications, New Delhi.
• ASP.NET-OReilly.Learning.ASP.NET.3.5.2nd.Edition
• ASP.NET- dot net tutorial for beginners
• Software Engineering (Fifth edition) by Mr. Roger S Pressman.

This book helped us for understanding the concept of software engineering which is
needed for making the project’s relevant UML Diagrams and other useful notions.

College Complain & Requisition Automation

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

College Complain & Requisition Automation

Uploaded by

Copyright:

Available Formats

COLLEGE

NAME OF STUDENT: KOMAL MAHESHWARI

COLLEGE NAME: SVIT

GUIDE NAME: Mr.BHAVESH PATEL

COLLEGE COMPLAINTS & REQUISITION

In partial fulfilment for the award of the degree

Information & Technology

Sardar Vallabhbhai Patel Institute of Technology, Vasad– 388306

Gujarat Technological University, Ahmadabad

SVIT- IT DEPT Page 2

Sardar Vallabhbhai Patel Institute of Technology, Vasad

This is to certify that the project entitled “COLLEGE COMPLAINTS &

REQUISITION AUTOMATION” has been carried out by KOMAL

MAHESHWARI(100410116035) under my guidance in fulfilment of the

degree of Bachelor of Engineering in Information & Technology (7th-8th

Semester) of Gujarat Technological University, Ahmadabad during the

academic year 2013-14.

SVIT- IT DEPT Page 3

No project can be completed by an individual or two people. Many people have

and gratification to present our project, “COLLEGE COMPLAINTS & REQUISITION

sense of gratitude towards them all.

suggestions through his sheer perseverance.

active suggestions to the development of our project.

SVIT- IT DEPT Page 4

Using of this individual quotient, complaint of their problem to the respective

SVIT- IT DEPT Page 5

Our project includes:

GUI Graphical User Interface

ERD Entity Relationship Diagram

IEEE Institute of Electrical & Electronics

SVIT- IT DEPT Page 6

Use Case Diagram:-

Data Flow Diagram:

SVIT- IT DEPT Page 7

Table No. Table Name Page No.

5.4.1 Table of User-Details……………………………………………….41

5.4.2 Table of Login Information………………………………………...41

5.4.3 Table of Subject……………………………………………………42

5.4.4 Table of Batch Subject…………………………………….............42

5.4.5 Table of Batch……………………………………………………..42

5.4.6 Table of Batch User……..……………………………..……….....42

5.4.7 Table of Result………….…………………………………………43

5.4.8 Table of Attendance…………………………………………........43

5.4.9 Table of Document……..……………………………………........43

5.4.10 Table of Forum………..…………………………………………..44

5.4.11 Table of News………..………...…………………………............44

5.4.12 Table of Forum User………….…………………………………..44

SVIT- IT DEPT Page 8

Figure Name Page No.

• Software Process Model(Incremental model)………………………………..04

• Use case Diagram for Login…………………………………………………24

• Use Case Diagram for Manage complaints……………………………........25

• Use Case Diagram for Request management……………………………….26

• Use Case Diagram for User Management…………………………………..26

• Use Case Diagram for Report management………………………………...28

• Activity Diagram for Login…………………………………………………29

• Activity Diagram for Complaints…………………………………………..30

• Activity Diagram for Request………………………………………………31

• Sequence Diagram for Login……………………..………………………...32

• Sequence Diagram for Complaints………………………………………...33

• Sequence Diagram for Request……………………………………………..34

• Sequence Diagram for Report Generation……………………………….....35