NAME OF STUDENT: KOMAL MAHESHWARI
COLLEGE NAME: SVIT
EN_NO:100410116035
DEPARTMENT: I.T
GUIDE NAME: Mr.BHAVESH PATEL
COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 2
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/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 3
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.
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 4
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
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 5
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
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 6
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
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 7
LIST OF SYMBOLS
Use Case Diagram:-
Use Case
Actor
Uses
System Boundary
Data Flow Diagram:
Actor
Data Store
Data Process
Data Flow
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 8
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
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 9
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
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 10
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
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 11
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
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 12
7. USERINTERFACE DESIGN……………………………………………… 63
8. TESTING…………………………………………………………………….75
9. REFRENCES AND BIBLOGRAPGY………………………………………………………..79
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 13
CHAPTER-1
INTRODUCTION
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 14
• 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
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 15
• Advantages:-
• User friendly interface
• Fast access
• Less error
• More storage capacity
• Search facility
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 16
CHAPTER-2
BRIEF HISTORY OF
WORK
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 17
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.
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 18
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.
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 19
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.
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 20
• 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
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 21
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
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 22
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
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 23
• Interoperability
2.3 Timeline Chart:
Task
June-
July
August-
September
October-
November
December-
April
April
Initial discussion
with company
•
System Analysis •
Requirement
Gathering and
System Design
•
Coding and
Implementation
•
System Testing •
Documentation • • • • •
Figure 3 Timeline Chart
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 24
Chapter-3
LITERATURE SURVEY
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 25
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
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 26
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
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 27
finally emphasize the value of making student information connection with a subject teacher
for instance geared upon for in-depth education success.
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 28
CHAPTER-4 SYSTEM ANALYSIS
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 29
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
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 30
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.
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 31
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.
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 32
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
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 33
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.
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 34
• 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.
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 35
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.
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 36
CHAPTER-5
SYSTEM DESIGN
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 37
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.
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 38
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.
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 39
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.
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 40
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 41
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 42
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 43
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 44
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 45
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:
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 46
Login:
Log_In
Enter Name & Password
Security Quetions
View Account
Change Password
PasswordIncorrect
Correct
Incorrect
Correct
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 47
Complain:
Enter Complain
Post complain
Forward complain
Review complain
Responce
Not Accept
AcceptReject
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 48
Request:
Enter Request
Post Request
Forward Request
Review Request
Responce
Not Accept
AcceptReject
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 49
Log_in:
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 50
Complain:
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 51
Request:
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 52
User Management:
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 53
Report Generation:
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 54
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.
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 55
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 56
CHAPTER 6: DATA DISCTIONARY
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 57
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.
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 58
• 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.
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 59
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 Data Type Description
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
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 60
Table 3: Employee Table
Name Data Type Description
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
Name Data Type Description
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
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 61
Table 5: complaint Box
Name Data Type Description
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
Name Data Type Description
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 purchased
NVarchar It give the answer of Why this 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
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 62
Table 7: CCTV Footage
Name Data Type Description
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
Name Data Type Description
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
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 63
CHAPTER 7:
USER INTERFACE DESIGN
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 64
USER INTERFACE DESIGN:
HOME PAGE:
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 65
LogIn:
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 66
REGISTRATION:
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 67
FORGOT PASSWORD:
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 68
CONTAVT US:
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 69
COMPLAIN FORM:
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 70
SPORTS ITEM FORM:
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 71
COORDINATOR PAGE:
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 72
REQUEST:
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 73
HALL:
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 74
CCTV FOOTEGE:
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 75
CHAPTER:8
TESTING
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 76
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.
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 77
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.
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 78
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 C#.NET Page
Test Case Expected Result
Actual Result
1 Windows form Login If User id & Password Valid then user Logs in. If not Error Msg. Displayed
As Expected
2 Windows form Forget password and user id
If user-id /Password is forgotten then answering the question and providing email-id
As Expected
3 Windows Form Complain If user enters invalid complain it will show message
As Expected
4 Windows Form Request If user enters invalid complain it will show message.
As Expected
5 Windows Form Admin Login If Admin id & Password Valid then Admin Logs in. If not
As Expected
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 79
CHAPTER:9
REFRENCES AND BIBLOGRAPGY
SVIT/IT/DEC/2013/PROJECT/42 COLLEGE COMPLAIN & REQUISITION AUTOMATION
SVIT- IT DEPT Page 80
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.