Fee Management System

Submitted in partial fulfillment of the requirements

for the award of the degree of
Bachelor of Business Administration
( Computer Aided Management)

To
Guru Gobind Singh Indraprastha University, Delhi

Guide:

Submittedby:

Ms. Shukun Tokas

Yash Kapoor

Ms. Kamalpreet kaur

01290301910
Deeksha Gupta
04790301910

Institute of Innovation in Technology & Management,

New Delhi 1100 58

Batch (2010 - 2013 )

Certificate

We, 1. Yash Kapoor 01290301910 & 2. Deeksha Gupta 04790301910 certify that the
Minor Project Report (BCAM-306) entitled Fee Management System is done by us
and it is an authentic work carried out by us at Institute of Innovation in Technology
& Management. The matter embodied in this project work has not been submitted
earlier for the award of any degree or diploma to the best of my knowledge and belief.
1. Signature of the Student
2. Signature of the Student
Date:

Certified that the Project Report (BCAM-306) entitled Fee Management System done
by the above students is completed under my guidance.

Signature of the Guide

Date:
Name of the Guide:
Designation:

Countersigned

Director

ACKNOWLEGEMENT

Apart from our efforts , the success of our project depends largely on the encouragement
and guidelines of many others. We take this opportunity to express my gratitude to the
people who have been instrumental in the successful completion of this project.
We would like to show my greatest appreciation to my Project guide Ms. Shukun
Tokus. I cant say thanks enough for the tremendous support and help. Without her
encouragement and guidance this project work would not have been materialized.
Im highly grateful to my senior team members. They actually laid the ground for
conceptual understanding of technologies and planning used in project.
Finally I would also like to extend my profound thanks to all my esteemed colleagues
who helped me in specific areas of the project.

Yash Kapoor
01290301910
Deeksha Gupta
04790301910

TABLE OF CONTENTS
S No

Topic

Page No

Certificate

Acknowledgements

List of Tables/Figures/Symbols

Chapter-1: Introduction

1-25

Chapter-2: Physical Design

26-37

Chapter-3: Interface Design

38-51

Chapter 4: Scope of Improvement, Summary and

Conclusions

52-56

Appendices

LIST OF TABLES
Table No

Title

Page No

Registration table Description

34

Login table Description

35

Fee Payment table Description

35

Test Case Of login

51

Test Case Of Registration

51

Test Case Of Fee Payment

51

LIST OF DIAGRAMS

Figure No

Title

Page No

Waterfall Model Diagram

10

Block Diagram

13

Context Level Diagram

17

Use Case

19

Zero Level DFD

29

Level One DFD

30

Level Two DFD Login Module

31

Level Two DFD Registration Module

32

Level Two DFD Fee Payment Module

33

10

Level Two DFD Fee Report Module

33

11

ER Diagram

37

CHAPTER 1
System Introduction

1. Introduction
The Fee Management Software Module of School is one of the most automated fee
collection modules available in the market. Apart from being automated fee management
system, it is at the same time, flexible, enough to accommodate the varying nature of the
fee most of the academic institutions come across.
The fee management software module automatically calculates the pending fees, payment
details, deduction and concessions, if any applicable to the selected student.
Fee collection processing is a key monthly activity in a school and one that requires close
control to ensure there are no lapses in financial management of the school.
This system ensures fee processing automation by:

Creation and management of fee types and fee periods.

Generating fee reports of students

Providing search option to view details of a particular student.

2. Data Collection Methods

There are 2 types of data collection:

Primary Data Collection

Secondary Data Collection

Primary Data: The primary data is the data which has been collected by an individual
through questionnaires, observation, direct interview etc. In this project, Primary data
collection is used.
There are many methods of collecting primary data. The few important ones are :
Questionnaires
Interviews
focus group interviews
Observation
case-studies
Portfolios.

Secondary Data: Secondary data is the data that has been already collected by and
readily available from other sources or we can say that Secondary data is data collected
by someone other than the user. The various sources of secondary data are- internet, ejournals, websites, newspapers etc.

Here we have used two techniques for developing the software:

2.1 Interviews and QuestionnairesThe technique we used is questionnaire and interview. Here we asked closed-ended, (i.e.,
multiple-choice), open-ended, (i.e., conversational responses) questions. it is best to gain
information that cannot be relayed by more specific information seeking questions. To
implement interviews and questionnaires effectively, we prepared some questionnaire to
ensure that the data collected is meaningful.
2.1.1 Questionnaire
If you are making a software that involves developing or enhancing software, it can be
hard to ask the right questions. Below are some questions that a project developer should
ask their techie counterparts. A specimen of questionnaire is as followsQue1- What is the problem with the current system?
Data management is quite difficult in current manual / Traditional system because of the
following

Maintenance Cost is high.

Its time consuming.

Lack of security.

Repetition of work, Slow retrieval of data

Cannot update the data in paper work

Inability to share the data

3

Que2- What do you want in this system exactly?

The system shouldnt be complex. Storage capacity should be large and system should be
flexible enough and cost effective to enhance. The system should not respond slowly. It
should work at high speed. Maintenance cost should be low. Report should be exported to
Excel/PDF/Word.
Que3- What modules you would like to be in the system?

Fee Report - administrator can generate the report of each and every student.

Registration of student- administrator will register the student first.

Login- administrator is provided with login option.

Fee Payment- admin only should pay on user behalf.

Que4- What kinds of features do you think would attract you to use this system?
Students can view only information related to their own fee. Some key features
-

Viewing of Fees status of Students

Fee collection- Full/Partial on-line or though bank with the carry on facility and
advance adjustments.

Report generation.

3. Feasibility Study
A feasibility study is conducted to select the best system that meets performance
requirement. This entails an identification description, an evaluation of candidate
system and the selection of best system for the job. The system required performance
is defined by a statement of constraints, the identification of specific system objective
and a description of outputs.

S Steps in feasibility analysis

E The following steps are involved in the feasibility analysis. They are :
Form a project team and appoint a project leader.
Prepare system flowcharts.
Enumerate potential proposed systems.
Define and identify characteristics of proposed system.
Determine and evaluate performance and cost effectiveness of each proposed
weight system performance and cost data.
Select the best proposed system.

3.1 Type of feasibilities

The key considerations in feasibility analysis are:

Operational Feasibility

The preliminary investigation of the current system leads to the fact that it is
operationally feasible. Users of the system will not resist for the induction of the new
system because the project is going to help them a lot as, it will increase their
efficiency by reducing the time for doing the same repetitive task. It is mainly related
to human organizational and political aspects. The points to be considered are:

what changes will be brought with the system?

what organizational structures are disturbed?

Generally project will not be rejected simply because of operational infeasibility but
such considerations are likely to critically affect the nature and scope of the eventual
recommendations.

Economic feasibility

Since the current system is small the investigation on the project would be of normal
expense. It is economical, as investment needed for developing this project would need
one personnel computer and some operational cost is needed for the project. There is
very little development cost.
6

According to the computerized system we propose, the costs can be broken down to
two categories. Costs associated with the development of the system. Costs associated
with operating the system. From our analysis, we came to result that both these costs
occurred to the developers will be recurred within first 6 months of project
implementation thereafter providing economical benefits so ever. So, we can see that
current system is economically feasible.

Technical feasibility

This is concerned with specifying equipment and software that will successfully satisfy
the user requirement. The technical needs of the system may vary considerably, but
might include:
The facility to produce outputs in a given time.
Response time under certain conditions.
Ability to process a certain volume of transaction at a particular speed.
Legal feasibility
Legal feasibility is a determination of whether a proposed project infringes on known
Acts, Statutes, as well as any pending legislation.basically legal feasibility is to
determine whether the proposed system conflicts with the legal requirements. e.g a
data processing system must comply with the Local Data Protection Acts
Its simply to determine the any infringement and every thing must comply the legal
requirements.
7

4. SYSTEM STUDY
Systems Development Life Cycle (SDLC) is any logical process used by a systems
analyst to develop an information system, including requirements, validation, training,
and user ownership. An SDLC should result in a high quality system that meets or
exceeds customer expectations, reaches completion within time and cost estimates,
works effectively and efficiently in the current and planned Information Technology
infrastructure, and is inexpensive to maintain and cost-effective to enhance. Computer
systems have become more complex and often (especially with the advent of ServiceOriented Architecture) link multiple traditional systems potentially supplied by
different software vendors. To manage this level of complexity, a number of system
development life cycle (SDLC) models have been created: "waterfall," "fountain,"
"spiral," "build and fix," "rapid prototyping," "incremental," and "synchronize and
stabilize." Although the term SDLC can refer to various models, it typically denotes a
waterfall methodology.
In project management a project has both a life cycle and a "systems development life
cycle," during which a number of typical activities occur. The project life cycle (PLC)
encompasses all the activities of the project, while the systems development life cycle
focuses on realizing the product requirements.To manage this, a number of system
development life cycle (SDLC) models have been created: waterfall, fountain, spiral,
build and fix, rapid prototyping, incremental, and synchronize and stabilize.
8

4.1 SOFTWARE LIFE CYCLE MODELS

The goal of Software Engineering is to provide models and processes that lead to the
production of well-documented maintainable software in a manner that is predictable.
The period of time that starts when a software product is conceived and ends when
the product is no longer available for use. The software life cycle typically includes a
requirement phase,design phase, implementation phase, test phase, installation and
check out phase, operation and maintenance phase, and sometimes retirement phase.
Methodology used4.1.1 WATER FALL MODEL
The oldest of these, and the best known, is the waterfall: a sequence of stages in which
the output of each stage becomes the input for the next. These stages can be
characterized and divided up in different ways, including the following:
Project planning, feasibility study: Establishes a high-level view of the intended
project and determines its goals.
Systems analysis, requirements definition: Refines project goals into defined
functions and operation of the intended application. Analyzes end-user information
needs.
Systems design: Describes desired features and operations in detail, including screen
layouts, business rules, process diagrams, pseudocode and other documentation.
9

Implementation: The real code is written here.

Integration and testing: Brings all the pieces together into a special testing
environment, then checks for errors, bugs and interoperability.
Acceptance, installation, deployment: The final stage of initial development, where
the software is put into production and runs actual business.
Maintenance: What happens during the rest of the software's life: changes, correction,
additions, moves to a different computing platform and more. This, the least
glamorous and perhaps most important step of all, goes on seemingly forever.
4.1.2 Water Fall Model

Fig(1): Waterfall Model Diagram

10

How Waterfall model is helpful at each stage/modules of the project-

1. In feasibility study firstly we focused on possible requirements of the system at

the start of software development phase. Requirements are gathered from the
end user through questionnaire like what modules should be there and what
does he wants in the system? Finally, a requirement specification document is
created which serves the purpose of guideline for the next phase of the model.
2. After understanding the requirement s of the end user, we prepared a system
design. It helped in specifying hardware and system requirements and also
helped in defining the overall system architecture. The system design
specifications served as an input for the next phase of the model.
3. Then the system is developed in small programs called units or modules,
which are integrated in the next phase. Each unit is developed and tested for its
functionality ie, Login then registration which succeeds payment etc.
4. These units are finally integrated into a complete system in a proper sequence
ie Login, registration of student, fee payment and fee report generation, during
integration phase and tested to check if all modules/units coordinate with each
other, and the system as a whole behaves as per the specifications. After
successfully testing the software(by using test cases), it is delivered to the
customer.

11

4.1.3 Reasons for choosing waterfall model

Its strong points lie in the fact that it is sequential, so there would be no confusion on
the steps and the processes are straight down--no need to worry about so many
conditions while working on a project. Additionally, this type of model tends to pack
up on so much documentation. Therefore, such tends to be useful for future code
revisions and reference.
and the staged development cycle enforces discipline: every phase has a defined start
and end point, and progress can be conclusively identified (through the use of
milestones) by both vendor and client. The emphasis on requirements and design
before writing a single line of code ensures minimal wastage of time and effort and
reduces the risk of schedule slippage, or of customer expectations not being met.
Getting the requirements and design out of the way first also improves quality; it's
much easier to catch and correct possible flaws at the design stage than at the testing
stage, after all the components have been integrated and tracking down specific errors
is more complex. Finally, because the first two phases end in the production of a
formal specification, the waterfall model can aid efficient knowledge transfer when
team members are dispersed in different locations.Waterfall protects software
development projects from:
a. Identifying solution requirements before understanding the problem/need.
b. Architecting/Designing the solution before understanding the solution's
requirements
12

c.Coding/Unit Testing the solution before understanding the solutions

architecture/design
d. Integration Testing the solution before coding/unit testing the solutions components
e. Deploying the solution before testing the solution
5. Block diagram of the systemBlock diagram of the system consist of entity, process, input and outputs. In the system
there are many entities, processes and many inputs to these entities and processes to
give out the desired output. In required system for fee management admin will enter
the data regarding students fee, and generated a structured report of the student.

Admin

Id, pwd

Login

student details

Registration

Student registered

fee paid
fee deposited

report generation
reStudent view report
Fig(2): Block Diagram

13

Fee Report

Fee Payment

6. SRS (SOFTWARE REQUIREMENT SPECIFICATION)

6.1 INTRODUCTION:
The Systems Requirements Specification (SRS) is designed to express the behavioral,
performance, and development requirements of this product and serves as the
fundamental requirements document for the development of the product. The Systems
Requirements Specification includes a description of every input into the system, every
output from the system and all functions performed by the system in response to input
or in support of an output. The SRS meets IEEE standards and is the exclusive
requirements document to be used in development; all design and testing choices must
be compatible with this document.
6.1.1 Purpose:
The purpose of this document is to outline the requirement of fee management system
making it computerized and to study the requirement of its various users.
6.1.2 Scope
The software to be produced would be fee management system of ABC school. This
product would make the fee management system automated from manual system. It
shall reduce the

14

6.1.3 Administrators
Admin should be able to insert, modify or update the records. work load and paper
work of maintaining the records in a file or folder manually. The overall goal of this
would be :

Reduce paper work

Easy to update

Computerized

Maintain security

6.1.4 Overview
The software requirement specification provides the developer with the requirements
of the user. When developer knows about the requirements of the user he can design it
accordingly. SRS also helps in feasibility study as well by providing an input for the
latter. The requirements would help to determine whether the software can be
developed.

6.2

OVERALL DESCRIPTION

6.2.1 Product Perspective

Fee management system is a replacement for the manual system which depend on
paper work for recording fee related information. The software will ease the burden of
administrator by performing various tasks such as mailing to defaulters, updating of
15

databases etc. This school fee management also generates a complete summary of
payable fees and collected amount. In addition, with this school fee management
software daily fee collection reports can be made available to the concerned staff.

6.2.2 Product Functions

It would help in providing adequate data to the management / school. It would also end the
practice of tearing out fee slips. This would help the school prepare and organize its fee related
records more efficiently on the basis of each student report. Another additional feature is
students will be provided login Id and password

6.2.3 Normal Users (Students)

The students should be provided with the updated information about their fee Student
have the facility to view their report or any information related to it. They can also see
their fee status ie, paid, outstanding etc.
6.2.4 User Characteristics
Users of the software are students, parents, and the administrators who maintain the
system. Members are assumed to have basic knowledge of computers and Internet
browsing. Administrators of the system should have more knowledge of internal
modules of the system and are able to rectify small problems that may arise due to disk
crashes, power failures and other catastrophes. Friendly user interface, must be
sufficient to educate the users on how to use this product without any problems or
difficulties.

16

6.2.5 Assumptions and Dependencies

The product needs the following third party products.
Microsoft Access to store the database.

6.3 Context diagram:

login

Administrator

Fee
Management
System

Register
Fee Report

Fee Payment
Report

Fig(3): Context level Diagram

17

Student

6.3

USE CASE

It is a visually representation what happens when actor interacts with system.

A use case diagram captures the functional aspects of a system.
The system is shown as a rectangle with name of the system inside ,the actor are shown
as stick figures, the use case are shown as solid bordered ovals labeled with name of the
use case and relationships are lines or arrows between actor and use cases.
Symbols used in DFD are as followsUse case

Relationship

Actors

18

Login

Student
Registration

User

Administrator
Fee
Payment

Fee Report

Fig(4): Use Case Diagram

19

6.5 Users Requirement:A requirement specifies capabilities that a system must provide in order to solve a
problem. Requirements include:

Functional requirements

Performance requirements

A clear statement of the user requirements and information needs is necessary for good system
design. If the information required is not complete or the objectives are not identified properly
and clearly, then the design effort will produce less than optimum results. Information needs also
vary at different levels.

6.6 Functional requirements:

Modules in the project-

1. Login
2. Fee Report
3. Registration
4. Fee Payment

20

When the user explains his current scenario of work, the developer may not quite get
him. It is very essential for the developer to understand the way things are functioning at
the users place, since it is on the basis of his understanding that he will develop the
software and computerize the current system. In turn the user also needs to understand
how things are going to get computerized and how is work scenario going to change once
things are computerized. To be able to fetch the purpose of the developer and the user we
develop a document called Software requirement Specification (SRS). SRS is a document
that explains what the proposed software should do. It focuses on what has to be done
and not on how. It describes the complete behavior of the proposed software. The user
usually does not understand software or software development process so he needs that
things are put down in black and white in simple manner. So, this communication gap is
bridged by the software requirement specification. An SRS establishes an agreement
between the user and the developer on what the user requires and what the software
product will do:

Aim

User characteristics

General constraints

General assumption

Information description:

21

6.7 PERFORMANCE REQUIREMENTS

The performance features which is required in the proposed system is

User Friendliness
The proposed system should be user friendly, understandable and easy to use. It should
provide on line help and error messages for user ease. User should be able to take the
output of reports on the screen.
Requirements

This software should not breakdown suddenly in any disaster like power failure.

The timeline of this software must be in our mind.

The performance of the functions and every module must be well.

At every step the output of the one phase is the input of the other phase and it will
be reliable and accurate.

The risk factor must be taken at initial step for better performance of the software.

For individual function the performance will be well.

For login to the software password and user name will be matched to the
password and name saved in the database and thus only authenticated users are
allowed to the login.

There will be various ways of retrieving data and it takes less time.

22

6.7.1 Safety Requirements

The database may get crashed at any certain time due to virus or operating system failure.
Therefore, it is required to take the database backup
6.7.2 Security Requirements
We are going to develop a secured database for the school. Depending upon the category
of user the access rights are decided. It means if the user is an administrator then he can
be able to modify the data, delete, append etc. Whereas the user can only view the
information but cannot update or delete the records.

6.7.3 HARDWARE REQUIREMENTS

PROCESSOR-

Intel Pentium III processor

RAM-

Minimum 128 MB RAM

Recommended 256 MB RAM

HARD DISKNETWORK-

Minimum hard disk 40GB

Internet connection through Modem or LAN Card

23

6.7.4 SOFTWARE REQUIREMENTS

WINDOWS XP OPERATING SYSTEM

MS Office Project 2007

MS Access 2007

MS WORD 2007

Microsoft Visual Basic-6.0

6.7.5 Technology Used

Front End: - Microsoft Visual Basic-6.0

Back End: - Microsoft Access.

Constraints:
The computer should have enough processor speed, memory, and hard disk space to run the
complier weve chosen. We can check the manufacturers specification to determine these
requirements
The above specific operating system will be available on the hardware designated for the
software product. If, in fact, the operating system is not available, the SRS would then
have to change accordingly.

24

6.8 SPECIFIC REQUIREMENTS

6.8.1 User Interface Constraints
Using this system is fairly simple and intuitive.

A user familiar with basic browser

navigation skills should be able to understand all functionality provided by the system.
6.8.2 Hardware Constraints
The system should work on only school administration desktop computers.
6.8.3 Software Constraints
No specific software required
6.8.4 Communications Constraints
System must have access to the included database.

Other components of the fee

management system may require access to certain data which is available with school
administration only.

25

CHAPTER -2
Physical Design
1. Processes and Input and Output identification
1.1 Login Process
Input: ID and Password
Process: Here administrator will input login ID and Password to Login
Output: After login the administrator can access the system

1.2 Registration process

Input: Student name, enrollment number, Class, section
Process: Here administrator will input above details.
Output: After registration administrator can insert records
1.3. Payment process
Input: mode of payment, amount to be paid, fee due.
Process: Here the administrator will input the above
Output: Payment will be recorded in the data base
26

1.4. Fee Report

Input: Amount paid, student name, fee due,
Process: This will generate receipt for the student
Output: Receipt will be the output for payment of fee

2. Data flow diagram

A data flow diagram or bubble chart (DFD) is a graphical representation of the "flow" of
data through an information system, modeling its process aspects. Often they are a
preliminary step used to create an overview of the system which can later be elaborated.
DFDs can also be used for the visualization of data processing (structured design).

A DFD shows what kinds of information will be input to and output from the system,
where the data will come from and go to, and where the data will be stored. It does not
show information about the timing of processes, or information about whether processes
will operate in sequence or in parallel (which is shown on a flowchart).

27

The primitive symbols used for constructing DFDs are:

Symbols used in DFD

A circle represents a process.

A rectangle represents external entity

A square defines a source or destination of the system data.

An arrow identifies dataflow.

Double line with one end closed indicates data store

28

Zero level DFD

login

Administrator

Register

Fee
Management
System

Fee Report

Payment
Fee report

Fig (5): Zero Level DFD

29

Student

First level DFD

Login_Table
Administrator
1.0

Id, Password

verify

Login

Registration_table
2.0

Student details

Add details

Register

Student

Payment_table

Amount

3.0

Save details

Fee Payment

Receipt

4.0
Fee Report

Fig (6): Level One DFD

30

Roll no, name amt paid

Login
Administrator

Login_Table
1.1

ID and Password

Login

Verify
Update

1.2

Old and new password

Verify

Change
password

Fig(7): Level 2 DFD Login Module

31

Registration
Registration_table

Administrator

Student details

2.1

Add details

Create profile

Student details

2.2

View details

View profile

Student details

Edit Details
2.3
Edit profile

Student details

Delete details
2.4
Delete profile
Fig(8): Level 2 DFD Registration Module

32

Fee Payment
3.1
Student

Amount paid

Fee Payment

Update in database

Payment

Fig(9): Level 2 DFD Fee Payment Module

Fee Report

Administrator

Payment_table
Receipt

4.1

Student details, amount paid

Fee Report

Fig(10): Level 2 DFD Fee Report Module

33

2.2 Database Design

2.2.1Registration table
Primary key- Roll no.
FIELD

TYPE

SIZE

DESCRIPTION

Name

Text

50

Name

of

CONSTRAINT

each Not null

client
Roll no.

Double

50

Roll no. of each Primary key

student

Address

Text

50

Address of each Not null

client

Class

Double

15

class

for

each Not null

client
Section

Text

50

Section of each Not null

client

Table(1): Registration table Description

34

2.2.2 Login table

FIELD

TYPE

SIZE

DESCRIPTION

CONSTRAINT

ID

Text

15

Password

Text

15

Id of the
Not null
administrator
Password used to Not null
access the
system

Table(2): Login Table Description

2.2.3Fee Payment Table

FIELDS
Student name

TYPE
Text

SIZE
50

DESCRIPTION
Name of each
client
Class of each
student

Class

Double

50

Amount Due

Double

10

Amount left

Roll no.

Double

15

Roll no. of each

student

Primary key

Amount paid

Double

15

Amount of fees
to be paid

Not null

Table(3): Fee Payment Table

35

CONSTRAINT
Not null
Not null

2.3 E-R Diagram

it is a detailed logical representation of the data for an organization and uses three main
constructs i.e. data entities, relationship and their associated attributes. The primary
purpose of the ERD is to represent data objects and their relationships.
Entity- Entities are the real world objects which have certain meaning and features.
They are depicted by a rectangular box with name inside it.
Example:

Administrator

Attributes: Each entity has a set of associated attribute with it. They are depicted by oval
shape.
Example:
Username

Password

Administrator

Relationships: it is a reason for associating two entity types. Relationship is depicted by

a diamond shape. There can be following degree of relationship:
One to One relationship
Logins

Administrator

Main Page

One to many relationship

Administrator

Registers

36

Students

ROLL NO.
ID

PASSWORD

STUDENT
NAME
FILLS

ADMINISTRATOR

CLASS

REGISTRATION
FORM

SECTION

FATHERS
NAME
ADDRESS

DATE OF
BIRTH

RECEIVED

HAS

RECEIPT
NAME

NAME

ROLL NO.

ADDRESS

FEES

PAYS
STUDENT

LATE FEES

AMOUNT
LEFT
AMOUNT
PAID

CLASS

Fig(11): ER Diagram

37

DATE OF
BIRTH
ROLL NO.

CHAPTER-3
Systems Development & Implementation
1. Interface Design

LOGIN

38

CHANGE PASSWORD

REGISTRATION

39

40

PAYMENT

41

REPORT GENERATION

42

FEE REPORT

REGISTRATION

PAYMENT

43

CODING

LOGIN FORM :
Private Sub Command1_Click()
If username = "username" And password = "password" Then
Form2.Show
Else
MsgBox "login unsuccessful"
End If
End Sub

Private Sub Command2_Click()

Form3.Show
End Sub

CHANGE PASSWORD FORM:

Private Sub Command1_Click()
Data1.Recordset.AddNew
Text1.Text = ""
Text2.Text = ""
With info
!rollno = Text1.Text
!Name = Text2.Text
44

!course = Text3.Text
.Update
End With
End Sub

REGISTRATION FORM:
Private Sub Command1_Click()
Form4.Show
End Sub
Private Sub Command2_Click()
Data1.Recordset.AddNew
Text1.Text = ""
Text2.Text = ""
Text3.Text = ""
Text4.Text = ""
Text5.Text = ""
Text6.Text = ""
45

Text7.Text = ""
End Sub
Private Sub Command3_Click()
Data1.Recordset.Fields(0) = Text1.Text
Data1.Recordset.Fields(1) = Text2.Text
Data1.Recordset.Fields(2) = Text3.Text
Data1.Recordset.Fields(3) = Text4.Text
Data1.Recordset.Fields(4) = Text5.Text
Data1.Recordset.Fields(5) = Text6.Text
Data1.Recordset.Fields(6) = Text7.Text
Data1.Recordset.Update
End Sub
FEE PAYMENT FORM:
Private Sub Command1_Click()
Form5.Show
End Sub
46

Private Sub Command2_Click()

Data1.Recordset.AddNew
Text1.Text = ""
Text2.Text = ""
Text3.Text = ""
Text4.Text = ""
Text5.Text = ""
End Sub
Private Sub Command3_Click()
Data1.Recordset.Fields(0) = Text1.Text
Data1.Recordset.Fields(1) = Text2.Text
Data1.Recordset.Fields(2) = Text3.Text
Data1.Recordset.Fields(3) = Text4.Text
Data1.Recordset.Fields(4) = Text5.Text
Data1.Recordset.Update
End Sub
47

FEE REPORT :
Private Sub Command2_Click()
Form4.Show
End Sub

Private Sub Command3_Click()

Form2.Show
End Sub
Private Sub Command4_Click()
With info
!rollno = Text1.Text
!Name = Text2.Text
!course = Text3.Text
.Update
End With
End Sub

48

2.Testing & Debugging

2.1Testing Methodology

Testing is the process of executing a program with the intent of finding errors As we know,
software is one component of a large computer based

system. Ultimately,software is

incorporated with other system components and thus, a series of special tests are to be
conducted. Petschenik gives some guidelines for choosing test cases during system testing.
The first is that testing the systems capabilities is more important than testing its
components. During system testing,we should evaluate a number of attributes of the
software that are vital to the user.

2.2 Testing
The most crucial stage of software development, testing validates the application. During
testing we will be concerned about the inputs and their expected outputs. We emphasize on
the testing where we will input the data and compare the output with the expected results. At
this stage we are not concerned about the process; we are only looking for correct outputs.
Various software testing techniques exists which take different approaches to test and
validate a software.
Tests done on the designed software was to verify the following properties of the software:
Correctness (satisfaction of the specifications)
Reliability (how well it meets the requirements)
49

Portability (running in different environments)

Usability (ease with which user can use the software)
Maintainability (modifications after initial release)

2.3 Debugging
Debugging is removing the undesirable errors or bugs from the program. We implemented
debugging using the Visual basic compiler in which the application was developed.
During testing the program to tested is executed with the set of test cases and have the
output of the program for the test cases is evaluated to determine if the program is
performing as expected. Due to its approach dynamic if the program is performing as
expected. Due to its approach dynamic testing can only presence of errors in the program,
the exact nature of errors is not usually decided by testing. Testing forms is the process to
determine errors in the program.
Once a program are tested individually then the system as a whole needs to be tested.
During testing the system is used experimentally to ensure that the software does not fail i.e.
it will run according to its specification. The programs executed to check for any syntax and
logical errors. The errors are corrected and test is made to determine whether the program is
doing what supposed to do.

50

Test Cases-

Module1- Login
INPUT

ACTUAL OUTPUT

DESIRED
OUTPUT

STATUS

Id
Type: number
charform

Doesnt match

Matched

False

password
Type: text
text form

Login successfull

Login successful

True

Table(4): Test Case Of login

Module2- Registration
INPUT
Name
Type: Text
memoform

ACTUAL OUTPUT DESIRED

OUTPUT
enter valid data
ok

STATUS
False

Table (5): Test Case Of Registration

Module3- payment
INPUT

ACTUAL
OUTPUT

DESIRED
OUTPUT

STATUS

Amount paid
Type: Number
textform

enter valid data

ok

False

Table (6): Test Case Of Payment

51

Chapter-4
Scope of Improvement, Summary and Conclusions

Objectives Of The Project

The main objective of fee structures to perform all the functions or operations accurately
and correctly. The proposed system has the following objectives to be achieved.

1.

User Friendly Environment.

2.

Less Space.

3.

Fast Retrieval.

4.

Easy to Operate.

5.

Accuracy.

6.

Report generation

Scope of The Project

1.

Including module to enable the softwares user to record students fees.

2.

Including a module that adds the fees of a new student.

3.

Including a module to view the fees paid by the student.

4.

A module that helps modify the fee structure of student in database

52

Future Scope And Limitations

Fee management system, is in itself a complete system, though it has a few limitations
but it has a lot of future scope and features that could be added to make it more widely
acceptable. One limitation is that our software is limited to small and medium scaled
organizations/school. Also apart from fee records no new category can be added in the
system (or in turn beissued) like other records etc..One of the major future scope is
making our system online. Connecting the system of a particular school to a common
data centre will provide globalization to the school, and then the user will be able to share
the data across the branches.

53

Summary

The project entitled Fee Management is about Managing fee records. There are many
functions like registration, login, forgot password, change password, payment etc. The
end user can register the student by filling the necessary details and can make the
payment on students behalf. During login process there is one more function available
that is change password. This function allows the admin to change the password.
Successful login will lead to registration form where administrator can register the
student and proceed further.

54

Conclusion

This software is a database project with all the basic capabilities a database should have.
This application software is about student fee system and it records and maintains records
about the student fee.

In doing so, an appreciation of project management, communication and consultancy skills

should be acquired, along with a thorough understanding of the development of windows
based applications using Visual basic. I feel that all of these aims were achieved, some to
greater extent than others.

55

References

The references for the project FEE MANAGEMENT SYSTEM have been taken from
the following books and website.

WEB REFERENCES

http://en.wikipedia.org/

BOOKS REFERENCES
Software engineering by KK AGGRAWAL
Software engineering by Pankaj Jalote

56