CONTENTS

S. NO. PARTICULARS

1. Certificate of Originality

2. Acknowledgement

3. Introduction

4. Objective

5. System Analysis

6. Identification of Need

7. Preliminary Investigation

8. Feasibility Study

9. Database

10. Forms

11. Queries

12. Bibliography

CERTIFICATE OF ORIGINALITY
 Date:

This is to certify that the project entitled School Managrment System

submitted to Rayalaseema University, Kurnool in partial fulfillment of the

requirement during the study of degree IN COMPUTER SCIENCE (BSCs), is an

original work carried out by __________________________________________

register No____________________________ under my guidance.

The matter embodied in this project is a genuine work done by the student

and has not been submitted whether to this University or to any other

University/Institute for the fulfillment of the requirement of any course of study.

Signature of Student: Signature of the Guide:

Signature of External Examiner

INTRODUCTION AND OBJECTIVES OF THE PROJECT

 At present the school management and its all procedures are totally manual
based. It creates a lot of problems due to wrong entries or mistakes in totaling etc. This
system avoided such mistakes through proper checks and validation control methods in
checking of student record, fee deposit particulars, teachers schedule, examination
report, issue of transfer certificates etc. I met personally to the principal and manager
and discuss about the computerization of manual school management system. This
system registers a student and confirms its admission in school. When a student registers
in school a S.R. No (unique ID) is allotted to student. Student record is based on his/ her
S.R. No.
OBJECTIVE:
The objective of developing such a computerization system is to reduce the
paper work and safe of time in school management. There by increasing the efficiency
and decreasing the work load.
The project provides us the information about student record, school faculty,
school timetable, school fee, school examination result and library management. The
system must provide the flexibility of generating the required documents on screen as
well as on printer as and when required.
PROJECT DESCRIPTION:
The school management process can be described using different modules. Each
of the module performs a different function.

SCHOOL MANAGEMENT SYSTEM

Student School Faculty Time Examination Library

Record Fee Profile Table Result Management
(a) Student Record:
We can easily find out the details of student alongwith his photograph by
entering his/her S.R. No.
(b) School Fee: We can find out the fee structure of every class and the fee for student
whether the student has paid fee or not. If he/ she has not paid school fee within
prescribed period, he / she should have to pay penalty.
(c) Faculty Profile:
We can easily find out the description about the teacher posted in school .
(d) Time Table:
 We can search out the name of teacher and subject in particular class at a
particular time .
(e) Examination Result:
We can check the performance of students during the particular year . On
passing the particular class , student record and student TC is updated .
(f) Library Management:
Library management process updates the library database. It gives information
about a particular book when issued to the student and when it is taken back.
SCOPE:

The scope of the school management system facilitate us in the following

jobs :-
Maintaining Student Records
Automatic Preparation of Marksheet
Automatic updation in student TC
Library Managenent
PROJECT CATEGORY:

The Project is functioning under the RDBMS (Relational Database

Management System) category of the software which handles the database of all
the students and staff. It uses object oriented programming technology to develop
the system .
ANALYSIS :

SYSTEM ANALYSIS

System Analysis refers to the process of examining a situation with the intent of

improving it through better procedures and methods. System design is the process of

planning a new system to either replace or complement an existing system. But before

any planning is done, the old system must be thoroughly understood and the

requirements determined. System Analysis is therefore, the process of gathering and

interpreting facts, diagnosis problems and using the information to re-comment

improvements in the system. Or in other words, System Analysis means a detailed

explanation or description. Before computerizing a system under consideration, it has to

be analyzed. We need to study how it functions currently, what are the problems, and

what are the requirements that the proposed system should meet.

The main components of making software are:

System and software requirements analysis

Design and implementation of software

Ensuring, verifying and maintaining software integrity

System analysis is an activity that encompasses most of the tasks that are

collectively called Computer System Engineering. Confusion sometimes occurs because

the term is often used in context that all dues it only to software requirement analysis

activities, but system analysis focuses on all the system elements- not just software.

System analysis is conducted with the following objectives in mind:

Identify the customers need

Evaluate the system concept for feasibility

Perform economic and technical analysis

Allocate functions to hardware, software, people, database and other

system elements

Establish cost and schedule constraints

Create a system definition that forms the foundation for all the

subsequent engineering work.

System Analysis is consisting of two main works i.e. Identify the need and

Preliminary Investigation.

PHASE DEVELOPMENT PROCESS

A development process consists of various phases, each phase ending with a

defined output. The phases are performed in an order specified by the process model

being followed. The main reason for having a phased process is that it breaks the

problem of developing software into successfully performing a set of phases, each

 handling a different concern of software development. It allows proper checking for

quality and progress for given software during development (end of phases). One phase

would have to wait until the end what software has been produced. This will not work

for large system. Hence for managing the complexity, project tracking, and quality, all

the development process consists of set of phases. Various process models have been

proposed for developing software. Each organization that follows a process has its own

version. The different process can have different activities.

In general, we can say that any problem solving in software must consist of these

activities:

Requirement specification for understanding and clearly stating the problem.

Design for deciding a plan for a solution.

Coding for implementing the planned solution

Testing for verifying the programs

For small problem these activities may not be clearly defined, and no written

record of the activities may be kept. But for the complex and large system where the

problem solving activity may last couple of years and where many persons are involved

in development, and each of these four problem solving activities has to be done

formally. Each of these activities is a major task for large software projects.
 IDENTIFICATION OF THE NEED

REQUIREMENT ANALYSIS : Refines project goals into defined functions and

operation of the intended application. Analyzes end-user information needs. Analysis is

a detail study of the various operations performed by a system and their relationships

within and outside the system. The problem could be automating an existing manual

process, developing a new automated system, or a combination of the two. A key

question is: what is needed for the system, not how the system will achieve its goal.

During analysis, data are collected on the available files, decision points, and

transactions handled by the present system. For large systems that have many features,

and that need to perform many different tasks, understanding the requirements of the

system is a major task. Data flow diagrams, interviews, on-site observations, and

questionnaires are the examples of requirement analysis. Training, experience, and

common sense are required for collection of the information needed to do the analyst.

Once the analysis is completed, the analyst has a firm understanding of what is

to done. This task is complicated by the fact that there are often at least two parties

involved in software development-a client and a developer. The developer usually does

not understand the clients problem domain, and the client often does not understand the

issues in the software systems. This causes a communication gap between client and

developer. The goal of the requirement specification phase is to produce the software

requirements specification document (also called the requirement document). The

person responsible for the requirement analysis is often called the analyst.

There are two major activities in this phase: Problem understanding or analysis

and requirement specification. In problem analysis, the analyst has top understand the

problem and its context. Analysis requires a thorough understanding of the system, parts

of which have to be automated. The goal of this activity is to understand the requirement

of the new system that is to be developed. The client may not really know the need s of
the system. The analyst has to make the client aware of the new possibilities, helping

both client and the analyst the requirements for the new system.

Once the problem is analyzed and the essentials understood, the requirement is

specified in the requirement document. For requirement specification in the form of

document, some specification language has to be selected (e.g. English, regulates

expressions, tables, or combination of these). A preliminary user manual that describes

all the major uses interfaces frequently form a part of the requirement document.

The first step of system analysis process involves the identification of need. The

analyst (system engineer) meets with the customer & the end user (if different from

customer). Identification of need is the starting point in the evolution of a computer

based system. The analyst assists the customer on defining the goals of the system:

What information will be produced?

What information is to be provided?

What functions and performance are required?

The analyst makes sure to distinguish between customer needs and customer

wants. That is what the main aim behind the system is. Defining aim is very vital in

system work. If we do not know where we want to go, we will not know when we have

reached their. Once we know our aim, we can try to achieve it in the best possible way.

The user department has to define these objectives in terms of their needs. These

become the outputs which the system analyst keeps in to mind.

Once we know the output, we can easily determine what the input should be.

The essential elements of inputs are timeliness, accuracy, proper format and economy.

Information gathered during the need identification step is specified in a System

Concept Document. The customer before meetings sometimes prepares the original

concept document with the analyst. Invariably, customer-analyst communication results

in the modifications to the documents.

PRELIMINARY INVESTIGATION
 PRELIMINARY INVESTIGATION

Limitations or failure of existing systems, or the awareness of technological

advances relating to the particular are involved in particular systems which competitors

are developing.

Information systems projects originate from many reasons: to achieve greater

speed in processing data, better accuracy and improved consistency, faster information

retrieval, integration of business areas, reduced cost and better security. The sources

also vary project proposals originate with department managers, senior executives and

systems analysis. Sometimes the real origin is an outside source, such as a government

agency, which stipulates systems requirements the organization must meet. When the

request is made, the first systems activity, the preliminary investigation, begins. The

activity has three parts: request clarification, feasibility study and request approval.

Request Clarification

Many requests from employees and users in organizations are not clearly stated.

Therefore, before any systems investigation can be considered, the project request must

be examined to determine precisely what the originator wants. A simple telephone call

may suffice if the requester has a clear idea but does not know how to state it. On the

other hand, the requester may merely be asking for help without knowing what is wrong

or why there is a problem. Problem clarification in this case is much more difficult. In

either case, before any further steps can be taken, the project requests must be clearly

states.

This phase (initial study) involves estimating whether or not a development

project is worthwhile. Problems with the current automated or manual system are

identified, as well as the benefits and costs of an alternative system. If the benefits seem

to outweigh the costs (especially when compared with competing projects), a green

signal may be given to continue the project, and detailed plans and schedules are drafted

for making the system a reality.

 The proposed solution to the users problem may involve something between

dramatic change (completely new system) and slight change to the present system. If the

present system is manual and a computer system is proposed, the development project

will probably be very large. At the other extreme are small development project that

represent slight changes to existing systems, such as sorting information in a different

way or inserting subtotals or adding new columns to a report. The objectives of this

phase are:

1 To determine the feasibility of computerization of a particular system or area

of operation.

2. To define clearly the objectives, scope and limitations of the project.

3. To establish a good working relationship between the user department and the

data processing (DP) department.

4. To acquaint user management with the approach and method of work in

systems development.

5. To estimate the resources required for system development, live running and

maintenance.

6. To identify the likely benefits, which should accrue from the introduction

of the system.

FEASIBILITY STUDY

The data collection that occurs during preliminary investigations examines

system feasibility, the likelihood that the system will be beneficial to the organization.
Four tests of feasibility are studies: technical, economical and operational. All are

equally important.

1. Technical Feasibility: It involves determining whether or not a system can

actually be constructed to solve the problem at hand. Some users expect too much of

computers, assuming that computers can accurately predict the future, immediately

reflect all information in an organization, easily understand speech, or figure out how to

handle difficult problems. Such systems, even if they exist, are not yet available for

widespread use.

The technical issues raised during the feasibility stage of the investigation are:

1. Does the necessary technology exist (can it be acquired) to do what is

suggested?

2. Does the proposed equipment have the technical capacity to hold the data

required to use the new system?

3. Will the proposed system and components provide adequate responses to

inquires, regardless of the number or location of users?

4. Can the system be expanded, if developed?

5. Are there technical guarantees of accuracy, reliability, ease of access and data

security?

For example, if the proposal includes a printer that prints at the rate of 2,000

lines per minute, a brief search shows that this is technically feasible. Whether it should

be included in the configuration because of its cost is an economic decision. On the

other hand, if a user is requesting audio input to write, read, and change stored data, the

proposal may not be technically feasible.

2. Economical Feasibility: It involves estimating benefits and costs. These

benefits and costs may be tangible or intangible. Because of confusion between the

types of costs, it is sometimes very difficult to decide if the benefits outweigh the costs.
 Tangible benefits may include decreasing salary costs (by automating manual

procedures), preventing costly but frequent errors, sending bills earlier in the month, and

increasing control over inventory levels. Such benefits may be directly estimated in

rupees without much trouble. Intangible benefits may include increasing quality of

goods produced, upgrading or creating new customer services, reducing repetitive or

monotonous work for employees, and developing a better understanding of the market.

Such benefits may be much more important than tangible benefits, but they may be

ignored because estimating their rupee values involves pure guesswork.

Tangible costs are easily estimated. They include the one-time cost of

developing the system and the continuous costs of operating the system. Examples of

development costs are the salaries of programmers and` analysts, the prices of the

computer equipment, and the expenses connected with user training. Operating costs

include the salaries of computer operators and the costs of computer time and computer

supplies. Intangible costs are usually not discussed because they are rarely large.

Examples of such costs include those associated with early user dissatisfaction and with

the problems of converting to the new system.

A system that can be developed technically and will be used if installed must still

be a good investment. That is, financial benefits must equal or exceed the financial

costs. The economic and financial questions raised by analysts during the preliminary

investigation seek estimates of:

1. The cost to conduct a full systems investigation.

2. The cost of hardware and software for the class of application being

considered.

3. The benefits in the form of reduced costs or fewer costly errors.

4. The cost if nothing changes (the system is not developed).

Cost and benefit estimates on each project provide a basis for determining which

projects are most worthy of consideration. Each estimate can be analyzed to determine
how rapidly costs are recovered by benefits, to calculate both the absolute and interest-

adjusted amounts of excess benefits, and to establish the ratio of benefits to costs. All of

these factors are considered when developing an overall sense of the project's economic

feasibility.

To be judged feasible, a project proposal must pass all these tests. Otherwise, it

is not a feasible project. For example, a personnel record system that is financially

feasible and operational attractive, is not feasible if the necessary technology does not

exist. Or a medical system which can be developed at reasonable cost but which nurses

will avoid using cannot be judged operationally feasible.

3. Operational Feasibility: Proposed projects are of course beneficial only if

they can be turned into information systems that will meet the organization's operation

requirements. Simply stated, this test of feasibility asks if the system will work when

developed and installed. Are there major barriers to implementation? Here are

questions that will help test the operational feasibility of a project:

1. Is there sufficient support for the project from the management and from

users? If the current system is well liked and used to the extent that persons will not see

reasons for a change, there may be resistance.

2. Are current business methods acceptable to the user? If they are not, user may

welcome a change that will bring about a more operational and useful system.

3. Have the users been involved in the planning and development of the project?

Early involvement reduces the chances of resistance to the system and change in

general, and increases the likelihood of successful projects.

4. Will the proposed system cause harm? The following questions are related to

this issue:

Will the system produce result in any respect or area?

Will loss of control result in any area?

Will accessibility of information be lost?

 Will individual performance be poorer after implementation than before?

Will customers be affected in an undesirable way?

Will it slow performance in any areas?

Operational feasibility is a measure of how people are able to work with the

system. For example, a system may require managers to write BASIC, COBOL, or

FORTRAN programs to access data. However, managers probably receive the greatest

help from a system when they can concentrate on the problems to solve rather than on

how programs should be constructed to solve them.

Necessary DFDs and ER Diagram are attached herewith.

(i) DFDs:
During analysis phase of SDLC (Software Development Life Cycle), the system
analyst or other members of the project team draw many diagrams to show how data
move within an organization. These diagrams, popularly called as DFD (Data Flow
Diagram), quickly convey to both the software developers and users how the current
system is working and how the proposed system will work. The main advantage of DFD
is that they are easily understood by the users and hence users can suggest modifications
in the proposed system.

We consider three levels of DFDs

Level 0 DFD Level 1 DFD Level 2 DFD

DFD Level 0

CFD (Context Flow Diagram)

or
CAD (Context Analysis Diagram)

Student or Applicant
 Fee
Depos
Admi it Book
ssion Reque
Form Fee st
Depos Issue/
it Retur
Valid/ n
Invali Repor
d t

School
Managemen
t System
Reports

ADMINISTRATOR

DFD level 0 (Context Level)

DFD Level 1
 L ib ra r y In f o .

2 .0
L ib ra ry
S tu d e n t R e c o rd M anagem ent
P ro ce ss

1 .0
S tu d e n t S tu d e n t M a s te r F ile
A d m is s io n F e e D a ta b a s e
P ro cess

F e e S tru c tu re

M a rk s D a ta b a s e

M o n th ly F e e
4 .0 R e c o rd
E x a m in a tio n

3 .0
T C D a ta b a s e M o n th ly F e e
5 .0 C o lle c tio n
T C R e co rd
U p d a tio n

Data Flow Diagram Level 1

 DFD LEVEL 2 School Management Process

S tu d e n t R e c o rd D e ta ils
S tu d e n t R e c o rd

S tu d e n t D e ta il
1 .1 1 .2
U p d a tio n R e q u e s t
C o n firm
R e g is tra tio n A d m is s io n
M ark s

E n try R e je c tio n C o n firm

T C G iv e n b y S c h o o l

F e e D a ta b a s e
A d m is s io n D e ta il

F e e B ill D e ta il
F e e S tr u c tu r e

S tu d e n t D e ta il
M a rk s D a ta b a s e
1 .3
F e e B ill
G e n e ra tio n

1 .5

B ill D e ta ils
S tu d e n t D e ta il
E x a m in a tio n S tu d e n t M a s te r F ile

M o n th ly F e e R e c o rd
T C D a ta b a s e
F e e D e ta ils
T C D e ta il

1 .6 1 .4
T C R e c o rd M o n th ly F e e
U p d a tio n C o lle c tio n
Data Flow Diagram Level 2 for School Management Process

DFD LEVEL 2 Library Management Process

 N e w B o o k E n try

B o o k D e ta ils
C h a n g e S ta tu s In fo ra m tio n B o o k D a ta b a s e

C h a n g e S ta tu s In fo ra m tio n
F e e D a ta b a s e
B o o k D e ta ils

F in e D e ta ils
S tu d e n t D a ta b a s e

S tu d e n t S tu d e n t
2 .1 D e ta il D e ta il
2 .2
Issu e R e tu rn

Issu e B o o k R e tu rn B o o k
D e ta il D e ta il

Is s u e D a ta b a s e

Data Flow Diagram Level 2 for Library Management Process

E-R Diagram:
 B o o k _ Id SR _N o. B o o k _ T itle

B o o k _ Id A u th o r

H as S tu _ L ib _ R e c o rd K eeps L ib _ In fo

P u b lic a tio n

N am e T u itio n _ F e e T o ta l_ F e e

SR _N o. C la s s C la s s E xam _Fee

S tu d e n t_ R e c o rd S e a rc h F e e _ S tru c tu re SR _N o.

A p p ears Fee SR _N o. D a te
P a id

S tu d e n t_ F e e
SR _N o.

S u b je c t B a la n c e

E xam

T C _ S ta tu s

Entity Relationship Diagram for School Management System

COMPLETE STRUCTURE OF THE PROGRAM:

No. of Modules used and their functions :

 The school management system of Unity Public School is divided into six parts:
-
(a) Student Record

(b) School Fee

(i) Fee Structure

(ii) Student Fee
(c) Faculty Profile

(d) School Time Table

(e) Examination Result

(f) Library Management

(a) Student Record:

S. No. Field Data Type Size Constraint
1. Student_Name Varchar 16 Not Null
2. Student_Fathers_Name Varchar 16 Not Null
3. Student_Mothers_Name Varchar 16 Not Null
4. Fathers_Occupation Varchar 16 Null
5. Mothers_Occupation Varchar 16 Null
6. Student_S.R._Number (Primary) Varchar 05 Not Null
7. Student_DOB Numeric 08 Not Null
8. Student_Sex Text 02 Not Null
9. Student_Caste Text 08 Not Null
10. Student_Photo Blob 20 Not Null
11. Student_Address Varchar 30 Not Null
12. Student_Phone_No. Numeric 10 Null
13. Date_of_Admission Numeric 08 Not Null
14. Student_Class_No. (Ref. Key) Numeric 02 Not Null
15. Student_Status Varchar 07 Not Null

(b -i) Fee Structure:

S. No. Field Data Type Size Constraint
1. Class_No. Numeric 02 Not Null
2. Tution_Fee Numeric 03 Not Null
3. Annual_Fee_Amount Numeric 03 Null
4. Exam_Fee_Amount Numeric 03 Null
5. Conveyance_Fee_Amount Numeric 03 Null
6. Total_Fee_Amount Numeric 04 Not Null
(b ii) Student Fee:

S. No. Field Data Type Size Constraint

1. Student_S.R. No.(F.K.) Numeric 05 Not Null
 2. AnnualFee_Dep_Date Numeric 08 Not Null
3. Fee_Amount_Paid Numeric 04 Not Null
4. Balance_Fee Numeric 04 Not Null
5. TutionFee_DepDate Numeric 08 Not Null
6. TutionFee_AmountPaid Numeric 04 Not Null
7. TutionFee_Balance Numeric 04 Not Null
8. ExamFee_DepositeDate Numeric 08 Not Null
9. ExamFee_AmountPaid Numeric 04 Not Null
10. ExamFee_Balance Numeric 04 Not Null
11. ConveyanceFee_DepDate Numeric 08 Not Null
12. ConveyanceFee_AmtPaid Numeric 04 Not Null
13. ConveyanceFee_Balance Numeric 04 Not Null
14. Total_Amount_Paid Numeric 04 Not Null
15. Total_Amount_Balance Numeric 04 Not Null
(c) Faculty Profile:

S. No. Field Data Type Size Constraint

1. Teachers_Name Varchar 20 Not Null
2. Teachers_Qualification Varchar 20 Not Null
3. Teachers_DOB Numeric 08 Not Null
4. Teachers_Sex Varchar 02 Not Null
5. Teachers_Photo Blob 40 Null
6. Teachers_Address Varchar 30 Null
7. Teachers_Phone No. Numeric 10 Null
.
8. Teachers_Date of Joining Numeric 08 Null
9. Teachers_Salary Numeric 04 Null
10. Teachers_Subject1 Varchar 12 Null
11. Teachers_Subject2 Varchar 12 Null
12. Teachers_Subject3 Varchar 12 Null
13. Teachers_Subject4 Varchar 12 Null
14. Teachers_Subject5 Varchar 12 Null
15. Teachers_Subject6 Varchar 12 Null
16. Teachers_Subject7 Varchar 12 Null
(d) School Time Table :

S. No. Field Data Type Size Constraint

1. Subject_Name Varchar 12 Not Null
2. Subject_Code Varchar 06 Null
3. Total No._of_Periods Numeric 02 Null
4. Time_ slots Numeric 04 Null
5. Class_No._Section Varchar 04 Null
6. Teachers _Name Varchar 12 Null
(e) Examination Result:
S. No. Field Data Type Size Constraint
1. Student_S.R.No. (Reference Key) Varchar 04 Not Null
2. Student_ClassNo. Varchar 05 Not Null
3. Student_Name Char 15 Not Null
4. Stud_Fathers_Name Char 15 Null
5. Result_Status Char 4 Not Null
6. Result_Year Numeric 4 Not Null
 7. TC_Status Boollean 1 Not Null
(f) Library Management:

S. No. Field Data Type Size Constraint

1. Book_Id Vanchar 05 Not Null
2. Book_Title Char 15 Not Null
3. Book_Author Char 15 Not Null
4. Publication Char 15 Null
5. Book_Issue Numeric 08 Null
6. Book_Return Numeric 08 Null
7. Book_subject Vanchar 15 Not Null
8. Book_Cost Numeric 04 Null
9. Book_Status Char 10 Null

TOOLS:

FRONT END / GUI TOOLs : Forms & Report Objects in MS-ACCESS

RDBMS / BACK END: ACCESS Database

OPERATING SYSTEM : WINDOWS Environment

Hardware Requirement (Minimum):

Any Latest / Pentium Processor.

2 GB RAM with 2.00 GB Hard Disk Free Space

Monitor

Mouse

CD-ROM/DVD Drive

Printer

SECURITY MECHANISMS:
Security is provided at administrative and user level by introducing the concept
of passwords for authentification purpose.
Password is categorized as :
Administrator - Complete
User - Student Record Display
- Faculty Display
- Time Table read only
- Results Read only
FUTURE SCOPE, FURTHER ENHANCEMENT AND LIMITATIONS:

This project will be useful for any schools and colleges with slightly
modification. It may be used for English Medium School as well as Hindi Medium
Schools. Project is flexible i.e. any change / modification in data base may be perform
easily. Also this project could be made web enabled.
This project may be upgraded with some more modules such as sports module,
prize module, student attendance module, employee salary module, annually receipt
and expenditure reports generation etc. This project can also be made for multi-user
environment.
 PROCESS LOGIC
The process logic for our project is depending on program structure.

School Management System

Student Database Faculty Database School Fee Structure

Faculty Time Table Library System

Student Fee Record Student Transfer Class & Subject
Certificate Database
Student Result Student Result

Each sub modules of school management system requires sub-sub modules or

different functions, such student database has new student entry, edit student record,
delete student record. Faculty database also has add, delete and modification functions.
Once we have entered school fee structure, we have maintained student fee record
effectively. Student Result is also has various options, such as individual result, class
result, fail and pass student record in each subject as well as in class. Also transfer
certificate will be made computerized. Another important module Library management
has also various sub-sub modules, such as new book entry, search book, issue and return
book, fine charges etc.
This project carried out for a full computerized school management system.
Most of the school function was computerized. This project will be useful for all schools
and colleges with some modification. The modification is customized so it is not
necessary to change complete project. Project is customised i.e. any change /
modification in data base may be perform easily. Also we are trying to make this project
web enabled.

ScreenShots(Queries, Forms, Reports)

Home
Pupils Entry

Form Payments
Report
 BIBLIOGRAPHY
1. An Introduction to Databse Management System by Bipin C Desai.

2. Software Engineering by Roger S. Pressman..

3. Software Engineering by Jalote.

4. PL/SQL by Evan Barros.

5. An Introduction to Databse Management System by C. J. Date.

6. Databse Concepts by Korth, Silbertz

7. Guide to Visual Basic 6.0 by Nortan & Groh