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

FINAL REPORT DEC

Embed Size (px)

Citation preview

Page 1: FINAL REPORT DEC

NAME OF STUDENT: KOMAL MAHESHWARI

COLLEGE NAME: SVIT

EN_NO:100410116035

DEPARTMENT: I.T

GUIDE NAME: Mr.BHAVESH PATEL

COLLEGE COMPLAIN & REQUISITION AUTOMATION

Page 2: FINAL REPORT DEC

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

Page 3: FINAL REPORT DEC

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.

Page 4: FINAL REPORT DEC

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

Page 5: FINAL REPORT DEC

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

Page 6: FINAL REPORT DEC

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

Page 7: FINAL REPORT DEC

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

Page 8: FINAL REPORT DEC

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

Page 9: FINAL REPORT DEC

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

Page 10: FINAL REPORT DEC

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

Page 11: FINAL REPORT DEC

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

Page 12: FINAL REPORT DEC

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

Page 13: FINAL REPORT DEC

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

SVIT- IT DEPT Page 13

CHAPTER-1

INTRODUCTION

Page 14: FINAL REPORT DEC

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

Page 15: FINAL REPORT DEC

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

Page 16: FINAL REPORT DEC

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

SVIT- IT DEPT Page 16

CHAPTER-2

BRIEF HISTORY OF

WORK

Page 17: FINAL REPORT DEC

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.

Page 18: FINAL REPORT DEC

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.

Page 19: FINAL REPORT DEC

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.

Page 20: FINAL REPORT DEC

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

Page 21: FINAL REPORT DEC

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

Page 22: FINAL REPORT DEC

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

Page 23: FINAL REPORT DEC

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

Page 24: FINAL REPORT DEC

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

SVIT- IT DEPT Page 24

Chapter-3

LITERATURE SURVEY

Page 25: FINAL REPORT DEC

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

Page 26: FINAL REPORT DEC

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

Page 27: FINAL REPORT DEC

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.

Page 28: FINAL REPORT DEC

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

SVIT- IT DEPT Page 28

CHAPTER-4 SYSTEM ANALYSIS

Page 29: FINAL REPORT DEC

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

Page 30: FINAL REPORT DEC

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.

Page 31: FINAL REPORT DEC

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.

Page 32: FINAL REPORT DEC

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

Page 33: FINAL REPORT DEC

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.

Page 34: FINAL REPORT DEC

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.

Page 35: FINAL REPORT DEC

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.

Page 36: FINAL REPORT DEC

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

SVIT- IT DEPT Page 36

CHAPTER-5

SYSTEM DESIGN

Page 37: FINAL REPORT DEC

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.

Page 38: FINAL REPORT DEC

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.

Page 39: FINAL REPORT DEC

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.

Page 40: FINAL REPORT DEC

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

SVIT- IT DEPT Page 40

Page 41: FINAL REPORT DEC

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

SVIT- IT DEPT Page 41

Page 42: FINAL REPORT DEC

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

SVIT- IT DEPT Page 42

Page 43: FINAL REPORT DEC

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

SVIT- IT DEPT Page 43

Page 44: FINAL REPORT DEC

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

SVIT- IT DEPT Page 44

Page 45: FINAL REPORT DEC

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:

Page 46: FINAL REPORT DEC

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

Page 47: FINAL REPORT DEC

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

Page 48: FINAL REPORT DEC

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

Page 49: FINAL REPORT DEC

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

SVIT- IT DEPT Page 49

Log_in:

Page 50: FINAL REPORT DEC

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

SVIT- IT DEPT Page 50

Complain:

Page 51: FINAL REPORT DEC

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

SVIT- IT DEPT Page 51

Request:

Page 52: FINAL REPORT DEC

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

SVIT- IT DEPT Page 52

User Management:

Page 53: FINAL REPORT DEC

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

SVIT- IT DEPT Page 53

Report Generation:

Page 54: FINAL REPORT DEC

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.

Page 55: FINAL REPORT DEC

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

SVIT- IT DEPT Page 55

Page 56: FINAL REPORT DEC

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

SVIT- IT DEPT Page 56

CHAPTER 6: DATA DISCTIONARY

Page 57: FINAL REPORT DEC

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.

Page 58: FINAL REPORT DEC

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.

Page 59: FINAL REPORT DEC

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

Page 60: FINAL REPORT DEC

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

Page 61: FINAL REPORT DEC

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

Page 62: FINAL REPORT DEC

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

Page 63: FINAL REPORT DEC

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

SVIT- IT DEPT Page 63

CHAPTER 7:

USER INTERFACE DESIGN

Page 64: FINAL REPORT DEC

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

SVIT- IT DEPT Page 64

USER INTERFACE DESIGN:

HOME PAGE:

Page 65: FINAL REPORT DEC

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

SVIT- IT DEPT Page 65

LogIn:

Page 66: FINAL REPORT DEC

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

SVIT- IT DEPT Page 66

REGISTRATION:

Page 67: FINAL REPORT DEC

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

SVIT- IT DEPT Page 67

FORGOT PASSWORD:

Page 68: FINAL REPORT DEC

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

SVIT- IT DEPT Page 68

CONTAVT US:

Page 69: FINAL REPORT DEC

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

SVIT- IT DEPT Page 69

COMPLAIN FORM:

Page 70: FINAL REPORT DEC

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

SVIT- IT DEPT Page 70

SPORTS ITEM FORM:

Page 71: FINAL REPORT DEC

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

SVIT- IT DEPT Page 71

COORDINATOR PAGE:

Page 72: FINAL REPORT DEC

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

SVIT- IT DEPT Page 72

REQUEST:

Page 73: FINAL REPORT DEC

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

SVIT- IT DEPT Page 73

HALL:

Page 74: FINAL REPORT DEC

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

SVIT- IT DEPT Page 74

CCTV FOOTEGE:

Page 75: FINAL REPORT DEC

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

SVIT- IT DEPT Page 75

CHAPTER:8

TESTING

Page 76: FINAL REPORT DEC

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.

Page 77: FINAL REPORT DEC

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.

Page 78: FINAL REPORT DEC

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

Page 79: FINAL REPORT DEC

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

SVIT- IT DEPT Page 79

CHAPTER:9

REFRENCES AND BIBLOGRAPGY

Page 80: FINAL REPORT DEC

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.