school billing system report

SCHOOL MANAGEMENT SYSTEM 2016
1
PROJECT REPORT
(Training Period: From 20.05.2016 To 02.07.2016)
(SCHOOL MANAGEMNET SYSTEM)
SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENT FOR THE
AWARD OF
THE DEGREE OF
BACHELOR OF TECHNOLOGY
IN
COMPUTER SCIENCE AND ENIGNEERING
(ANKIT SHUKLA)
Roll No. - MAU14UCS056
Under the Guidance of
Kaushik Adhikary Sanjay Sharma
Asst. Professor, CSE Senior Manager - IT
Maharaja Agrasen University, SPL Ltd.
Baddi Ghaziabad
Maharaja Agrasen Institute of Technology
MAHARAJA AGRASEN UNIVERSITY
HIMACHAL PRADESH
20.05.2016 to 02.07.2016 , 2016
(Start Date) (End Date) (Year)

2
DECLARATION
I hereby declare that the project work entitled “School Management System” is an authentic
record of my own work carried out at SPR Ltd. during my four weeks industrial training as a
part of one month industrial training for the award of the degree B.Tech. in Computer
Science And Engineering by Maharaja Agrasen Institute of Technology, Maharaja Agrasen
University, Himachal Pradesh, under the guidance of Mr. Sanjay Sharma and Asst. prof.
Kaushik Adhikary, during 20 may, 2016 to 2 July, 2016.
Ankit Shukla
MAU14UCS056
Certified that the above statement made by the student is correct to the best of our knowledge
and belief.
Kaushik Adhikary
Asst. Professor, CSE

3

4
ACKNOWLEDGEMENT
School Management System has been developed successfully with a great contribution of
many people in a period of four weeks. I would like to appreciate their guidance,
encouragement and cooperation since without their support the project would not have been a
success.
I would like to take the opportunity to thank and express my deep sense of gratitude to my
corporate mentor Mr. Mukesh Badhwar for giving me the opportunity to work and learn with
SPR Ltd. and my faculty mentor Mr. Kaushik Adhikary for providing his valuable guidance
at all stages of the study.
I would also like to thank my project mentor Mr. Naveen who in spite of busy schedule has
co-operated with me continuously and indeed, his valuable contribution and guidance have
been certainly indispensable for my project work.
I owe my wholehearted thanks and appreciation to the entire staff of the company for their
cooperation and assistance during the course of my project.
I hope that I can build upon the experience and knowledge that I have gained and make a
valuable contribution in coming future.

5
ABSTRACT
The purpose of this study was to develop a School management system to assist in the
management of Fees and Salary which ease the process of doing this job than earlier pen and
paper based management. So the development of a software application – ‘Student
Management System’ introduces the automation in the organizations serving this purpose.
This project is carried out as a partial fulfillment of the degree of B.Tech. Nowadays this kind
of application is very essential for any small or medium sized organization. An Accountant,
regardless of the number of Staff and Student, must maintain all records pertaining to
payment/fees system digitally.
This application will help to calculate the student’s fee, teacher’s salary and other relevant
calculations automatically.

6
Chapter CONTENTS Page no
1
Introduction
Overview 8
1.1 Background to the study 9
1.2 Objectives 10
1.3 Feasibility Study 10
1.5 Benefits 12
1.6 Scope & Limitation 12
1.7 Significance 13
2
Work
2.1 System Design Methods 14
2.2 Data gathering instruments 15
2.3 Requirement Analysis 16
2.4 System Development Life Cycle 19
3
Industry
3.1 Introduction 28
3.2 Services Overview 30
4
Work Details
4.1 System Overview 33
4.2 Screenshots 34
5
Conclusion
5.1 Limitations 42
5.2 Future Scope 42
6 Bibliography 43

7
LIST OF TABLES
Table No. Contents Page No.
2.3.1 Hardware Requirements 25
2.3.2 Software Requirements 26

8
OVERVIEW
The school billing system project in C keeps record of all the students, teachers and staffs
working in the institution. The program is run by the administrator who can add, record,
modify, delete and find records according to the need. The basic feature of this project is that
it shows fees that the students need to pay or dues and advance of the students. It also records
the information related to salary that is to be provided to teachers and staffs working in the
organization.
The data within the program can be recorded by the input of current month and date. The
administrator will need to select the type of account for either student or teachers and can
perform the billing operation as per the requirement.
The project keeps record of students name, class and roll number while it also keeps the
record of teachers in the similar way.
The School billing system project in C utilizes data structure to store the records and provides
access to the user whenever required. Individual structures are created for the date of input,
for storing students’ information and to keep record of teachers and staffs.
Together with the data structure, the project utilizes functions to perform various operations.
The function in the program are used for checking data, adding records, modifying records,
searching and deleting records, calculating dues, total and advance information about fees of
students and calculating salary of teachers.
In this project, you can add, record, modify, search and delete the records of both account
types. In addition to that, this mini project in C allows you to display fees, dues, total and
advance of students, and salary-related information of teachers and staffs.
For the entry of records, current date and month is asked. Then, you can select the account
type, and perform billing operations like I mentioned above. In the add record, the name,
class and roll no. of the student is asked, and it is similar for all other functions as well as the
teachers account.

9
CHAPTER 1 -INTRODUCTION
teachers account.
1.1 BACKGROUND TO THE STUDY
School management is a very common task for any School which has a number of employees
and student. Though the method differ from organization to organization. The school
management system of the earlier times had a manual system using ledger books to keep
track of every single employee’s salary and student fees history, calculate. This pen and paper
based system is much time consuming and there is a great chance to make mistake as there
are very good number of employees and student in this organization and keeping patience is a
tough job to manipulate so many things. Unauthorized persons however, easily accessed the
paper system and hence making it impossible to keep secrecy and confidentiality. So such a
system is time consuming, prone to errors of entry and analysis resulting from the fatigue of
the users.
Now if we view the system from the other employees’ and student (who are the end user of
the system) point of view, then the system is also monotonous. Because if one
employee/student wants to check his/her statistics of the salary/fees record then it is very
difficult to get it without any help of automated system.
So, it is obvious to migrate the whole process in an automated way so that which help the
authority and user to maintain all the things with ease.
1.1.1 Purpose
Main aim of developing School Management System is to provide an easy way not only to
automate all functionalities involved managing leaves and Payroll for the employees of
Company, but also to provide full functional reports to management of School with the
necessary details.

10
Nowadays large scale organizations (schools in this case) are committed to bring the best way
of management in the various forms of SMS. We understand that SPM is not a product to be
sold, it is a tool to manage the inner operation of school related to employee salary and
student fees.
1.1.2 Benefits
 To improve the efficiency.
 Quickly find out information of an teacher/student details.
 To provide easy and faster access information.
 To provide user friendly environment.
1.2 General Objective
This study aimed to help a school to have an efficient and effective way of monitoring
their staff/student salary/fees to give a higher quality of service.
1.3.1 Specific Objectives
Specifically, attain to:
o Develop a system that will improve the school process in the Timekeeping and
maintanining accounts;
o Develop a system that will monitor teachers/student data that is efficient to use;
o Secure the records of teachers/student and to have more manageable files, managed
by the administrator of the department.
o Calculate salary/fees transaction easily; and
o Summarize all the accounts detail of teachers/student.
1.3 Feasibility Study
Before developing this project we need a feasibility study to understand whether the project
would be successful or not. Feasibility study is detailed analysis of any system. The two
criteria to judge feasibility are cost required and value to be attained.

11
1.3.1 Factors of Feasibility Study:
i. Technology and system feasibility: The assessment is based on an outline design of
system requirements, to determine whether the company has the technical expertise to
handle completion of the project. In our case, ‘The People’s university of Bangladesh’
has an efficient IT department and the personnel from the accounts department has
that expertise.
ii. Economic feasibility: Economic analysis is the most frequently used method for
evaluating the effectiveness of a new system.
More commonly known as cost/benefit analysis, the procedure is to determine the
benefits and savings that are expected from a candidate system and compare them
with costs. If benefits outweigh costs, then the decision is made to design and
implement the system. The analysis must accurately weigh the cost versus benefits
before taking an action.
It is important to identify cost and benefit factors, which can be categorized as
follows: 1. Development costs; and 2. Operating costs. This is an analysis of the costs
to be incurred in the system and the benefits derivable out of the system.
The development cost of the proposed system is affordable for any organization like
The PUB. And it needs no operating cost as to implement the system, they do not
need purchase any extra equipment. Current hardware and network system is more
than requirement for the future system. Again there is no training cost associated to
cope up with the system.
iii. Operational feasibility: Operational feasibility is a measure of how well a proposed
system solves the problems, and takes advantage of the opportunities identified during
scope definition and how it satisfies the requirements identified in the requirements
analysis phase of system development.
After analyzing the problems of the current system and the benefits of the proposed
system, it will be clear that the proposed system will not be considered as loss at all.

12
1.4 Benefits of Our System
School Management System developed for organisational application gives them the power
to:
 Interact with the software with menu-driven programs with user friendly interface.
 Manage Employee Information Efficiently.
 Maintain student data efficiently.
 Manage the data.
 Efficiently manage the salary taken by the employees.
 Prepare the detailed salary record of all the employees in an organization.
1.5 Scope and Limitation
1.5.1 Scope
The proposed School Management System will cover many aspects of time keeping and
fee/salary process. This includes the capture of information based on the employee’s work
schedule, time worked and daily time rendered. The software process encompasses all
activities necessary to report employees’ time worked.
 The system will have a file management where it covers the records of staff/student.
 The system also covers the tracking of salary/fees of staff/student.
1.5.2 Limitation
The proposed system cannot be accessed online and it focuses only on the school
management System software of the organisation.. This proposed system is only applicable
and can only be used by the management of any school. The proposed system may face data
redundancy.

13
1.6 Significance
1.6.1 To the management
An organization will greatly benefit with the proponent’s study because they don’t
need to hire any programmers to do the work in their system. The proponents will develop
their system. So the proponents ask for the support of the company.
This will lead in lessening the expenses of the company which can be used in their other
expenses. They will also find it easier to do task with the system like the biometrics wherein
they can assure that their time keeping system is secure.
1.6.2 To the STAFF/STUDENT
The staff/student will benefit in the system. They will find it easier to transact about
their records since searching in the system is faster than tracking in the record book or log
book. The software will give them an easier time with their time log and they don’t have to
worry about losing their time cards because it is not necessary.
Human Resources Personnel managing the time keeping will not be the same again as
they will experience relieve. It would be fast and easy for them to handle transactions such as
report making and monitoring time entries. Further determining or computing the salry/fees
manually will be eliminated that will lead to faster transaction.

14
CHAPTER 2 -WORK
Following the literature review, background information and correlative knowledge, design
methods and analysis regarding this research project follows. In the initial part of this chapter,
the design methods adopted are mentioned; demand and requirements of the proposed system
are discussed and analysed.
2.1 SYSTEM DESIGN METHODS
If the broader topic of product development "blends the perspective of marketing, design, and
manufacturing into a single approach to product development," then design is the act of
taking the marketing information and creating the design of the product to be manufactured.
Systems design is therefore the process of defining and developing systems to satisfy
specified requirements of the user.
Until the 1990s, systems design had a crucial and respected role in the data
processing industry. In the 1990s, standardization of hardware and software resulted in the
ability to build modular systems. The increasing importance of software running on generic
platforms has enhanced the discipline of software engineering.
Object-oriented analysis and design methods are becoming the most widely used methods for
computer systems design. The UML has become the standard language in object-oriented
analysis and design. It is widely used for modeling software systems and is increasingly used
for high designing non-software systems and organizations.
2.1.1 The Descriptive Method
The proponent talked to the security accountant for gathering of data about the
system specification, needed for creating the proposed system that can help them for
their security, timekeeping and student management system in an efficient manner.
a) Interview
During requirements gathering stage, the proponent conducted interview with
security personnel.
b) Observation

15
The proponent had some inspection regarding the current system to gather more
ideas on how to design the proposed system. From this observation, the proponent
noted some problems being encountered.
c) Internet Research
The proponent also conducted an internet research to gather more data and
topics that are related to our study.
d) Library Research
The proponent also used library materials like thesis documentation and books
that are related to our study in gathering significant information and validation of our
study.
e ) Survey and Testing
The proponent conducted a survey and user testing to derive interpretations and
inferences. The survey is presented in accordance with the statement of the specific problem.
f) System Testing
Proponent also conducted System Testing of software. The testing conducted on
a complete was based on the system's compliance with its specified requirements.
2.2 Data Gathering Instruments
2.2.1 Company Observation.
The proponent had some inspection regarding the current system to gather more
ideas on how to design our proposed system. From this observation, we noted some
problems being encountered.
2.2.2 Naturalistic observation
Naturalistic observation is a research tool in which a subject is observed in
its natural habitat without any manipulation by the observer.
2.2.3 Participant observation

16
Participant observation is a structured type of research strategy. Its aim is to
gain a close and mutual familiarity with a given group of individuals and their
practices through an intensive involvement with people in their natural environment,
usually over an extended period of time.
2.3 REQUIREMENT ANALYSIS
Conceptually, requirements analysis includes three types of activities:
Eliciting requirements:(e.g. the project charter or definition), business process
documentation, and stakeholder interviews. This is sometimes also called requirements
gathering or requirements discovery.
Analyzing requirements: determining whether the stated requirements are clear, complete,
consistent and unambiguous, and resolving any apparent conflicts.
Recording requirements: Requirements may be documented in various forms, usually
including a summary list and may include natural-language documents, use cases, user
stories, process specifications and a variety of models including data models.
Requirements analysis can be a long and tiring process during which many delicate
psychological skills are involved. Large systems may confront analysts with hundreds or
thousands of system requirements. New systems change the environment and relationships
between people, so it is important to identify all the stakeholders, take into account all their
needs and ensure they understand the implications of the new systems. Analysts can employ
several techniques to elicit the requirements from the customer. These may include the
development of scenarios (represented as user stories in agile methods), the identification
of use cases, the use of workplace observation or ethnography, holding interviews, or focus
groups (more aptly named in this context as requirements workshops, or requirements review
sessions) and creating requirements lists. Prototyping may be used to develop an example
system that can be demonstrated to stakeholders. Where necessary, the analyst will employ a
combination of these methods to establish the exact requirements of the stakeholders, so that
a system that meets the business needs is produced. Requirements quality can be improved
through these and other methods
Visualization. Using tools that promote better understanding of the desired end-product such
as visualization and simulation.

17
Consistent use of templates. Producing a consistent set of models and templates to document
the requirements.
Documenting dependencies. Documenting dependencies and interrelationships among
requirements, as well as any assumptions and congregations.
The system should also embrace the following requirements:
 User-friendly: The system must accommodate a clearly understandable user interface
as well as documentation help at any stage of the user interaction with the system.
 Security: The system should be designed to make it impossible for anybody to logon
without a valid username and password. Data encryption should be employed to keep
the user login name and password secret.
 Reliability: The system would be used by the accounting section of any organisation.
Since this application is subject to process monetary matters, this must be reliable to
the users of this application.
 Ease of Use: The views and operations should be easy to use and intuitive.
Documentation should be provided.
 Performance: The system should have a quick response time.
 System requirements: This system would be designed to run on a minimum
hardware configuration like 500MHz x86 machines. Considering the vast hardware
available nowadays, this would not pose any problems.

18
2.3.1. Hardware Requirements
The hardware minimum and maximum recommended requirements are listed below:
Hardware Minimum Recommended
Requirements
Maximum Recommended
Requirements
Internal Memory (RAM) 2.00 GB 3.00 GB or Higher
Hard Disk Capacity
(CPU)
60.00GB 80.00GB or Higher
Processor Intel Pentium 1.60GHZ Intel(R) Core i3 2.40 GHZ
or Higher
Monitor 17” Colored 32bit 18 ” Colored or
Higher 64bit
Video Card 128MB AGP 256 MB AGP or Higher
Table 2.3.1: Hardware Requirements
2.3.2. Software Requirements
The software minimum recommended requirements and maximum recommended
requirements are listed below:
Table 2.3.2: Software Requirements
Software Minimum Recommended
Requirements
Maximum Recommended
Requirements
System type Microsoft Win7 or XP
32bit Operating System
Microsoft Win10 64bit
Operating System
Storage FAT File System NTFS File System
Programming Language
Compiler
Turbo C++ for
Windows 7
Turbo C++ for
Windows 8 or Higher

19
 Disk Drives
Each client computer must have enough disk space available to store the client portion of the
software and any data files that needs to be stored locally.
It is best to provide a local disk drive for each client computer. However Client/Server
applications can use the “diskless workstations” for which the only disk access is the disk
storage located on a network file server. The hard disk drive at database server should be at
least of the capacity 4.1 GB. But it is recommended to have one of capacity 8.2 GB.
 Mouse
A mouse is a must for the client software running under Windows OS or any other graphical
environment.
 Keyboard
Each client must have a 104 keys extended keyboard.
2.4 SYSTEM DEVELOPMENT LIFE CYCLE
System development life cycle is a process of developing software on the basis of the
requirement of the end user to develop efficient and good quality software. It is necessary to
follow a particular procedure. The sequence of phases that must be followed to develop good
quality software is known as SDLC (system development life cycle).
As with most undertakings, planning is an important factor in determining the success or
failure of any software project. Essentially, good project planning will eliminate many of the
mistakes that would otherwise be made, and reduce the overall time required to complete the
project. As a rule of thumb, the more complex the problem is, and the more thorough the
planning process must be. Most professional software developers plan a software project
using a series of steps generally referred to as the software development life cycle. A number
of models exist that differ in the number of stages defined, and in the specific activities that
take place within each stage. The following example is a generic model that should give you
some idea of the steps involved in a typical software project.

20
2.4.1 PHASES OF SDLC
 System Analysis
 System Design
 Coding
 System Testing
 System Implementation
 System Maintenance
Figure 14: Phases of SDLC

21
Figure 15: Flowchart of SDLC
2.5.1.1 System Design:
The design document that we will develop during this phase is the blueprint of the software.
It describes how the solution to the customer problem is to be built. Since solution to
complex problems isn’t usually found in the first try, iterations are most likely required. This
is true for software design as well. For this reason, any design strategy, design method, or
design language must be flexible and must easily accommodate changes due to iterations in
the design . Any technique or design needs to support and guide the partitioning process in
such a way that the resulting sub-problems are as independent as possible from each other

22
and can be combined easily for the solution to the overall problem. Sub-problem
independence and easy combination of their solutions reduces the complexity of the problem.
Basic design principles that enable the software engineer to navigate the design process
suggest a set of principles for software design, which have been adapted and extended in the
following list:
Free from the suffer from "tunnel vision." A good designer should consider alternative
approaches, judging each based on the requirements of the problem, the resources available
to do the job.
The design should be traceable to the analysis model. Because a single element of the design
model often traces to multiple requirements, it is necessary to have a means for tracking how
requirements have been satisfied by the design model.
The design should not repeat the same thing. Systems are constructed using a set of design
patterns, many of which have likely been encountered before. These patterns should always
be chosen as an alternative to reinvention. Time is short and resources are limited! Design
time should be invested in representing truly new ideas and integrating those patterns that
already exist.
The design should "minimize the intellectual distance" between the software and the problem
as it exists in the real world. That is, the structure of the software design should (whenever
possible) mimic the structure of the problem domain.
The design should exhibit uniformity and integration. A design is uniform if it appears that
one person developed the entire thing. Rules of style and format should be defined for a
design team before design work begins. A design is integrated if care is taken in defining
interfaces between design components.
The design activity begins when the requirements document for the software to be developed
is available. This may be the SRS for the complete system, as is the case if the waterfall
model is being followed or the requirements for the next "iteration" if the iterative
enhancement is being followed or the requirements for the prototype if the prototyping is
being followed. While the requirements specification activity is entirely in the problem
domain, design is the first step in moving from the problem domain toward the solution

23
domain. Design is essentially the bridge between requirements specification and the final
solution for satisfying the requirements.
The design of a system is essentially a blueprint or a plan for a solution for the system. We
consider a system to be a set of components with clearly defined behavior that interacts with
each other in a fixed defined manner to produce some behavior or services for its
environment. A component of a system can be considered a system, with its own
components. In a software system, a component is a software module.
The design process for software systems, often, has two levels. At the first level, the focus is
on deciding which modules are needed for the system, the specifications of these modules,
and how the modules should be interconnected. This is what is called the system design or
top-level design. In the second level, the internal design of the modules, or how the
specifications of the module can be satisfied, is decided. This design level is often called
detailed design or logic design. Detailed design essentially expands the system design to
contain a more detailed description of the processing logic and data structures so that the
design is sufficiently complete for coding.
Because the detailed design is an extension of system design, the system design controls the
major structural characteristics of the system. The system design has a major impact on the
testability and modifiability of a system, and it impacts its efficiency. Much of the design
effort for designing software is spent creating the system design.
The input to the design phase is the specifications for the system to be designed. Hence, a
reasonable entry criteria can be that the specifications are stable and have been approved,
hoping that the approval mechanism will ensure that the specifications are complete,
consistent, unambiguous, etc. The output of the top-level design phase is the architectural
design or the system design for the software system to be built. This can be produced with or
without using a design methodology. A reasonable exit criteria for the phase could be that the
design has been verified against the input specifications and has been evaluated and approved
for quality.
A design can be object-oriented or function-oriented. In function-oriented design, the design
consists of module definitions, with each module supporting a functional abstraction. In
object-oriented design, the modules in the design represent data abstraction (these
abstractions are discussed in more detail later). In the function-oriented methods for design

24
and describe one particular methodology the structured design methodology in some detail.
In a function- oriented design approach, a system is viewed as a transformation function,
transforming the inputs to the desired outputs. The purpose of the design phase is to specify
the components for this transformation function, so that each component is also a
transformation function. Hence, the basic output of the system design phase, when a function
oriented design approach is being followed, is the definition of all the major data structures in
the system, all the major modules of the system, and how the modules interact with each
other.
Once the designer is satisfied with the design he has produced, the design is to be
precisely specified in the form of a document. To specify the design, specification languages
are used. Producing the design specification is the ultimate objective of the design phase. The
purpose of this design document is quite different from that of the design notation. Whereas a
design represented using the design notation is largely to be used by the designer, a design
specification has to be so precise and complete that it can be used as a basis of further
development by other programmers. Generally, design specification uses textual structures,
with design notation helping in understanding.
2.5.1.2 Scheduling
Scheduling of a software project does not differ greatly from scheduling of any multi- task
engineering effort. Therefore, generalized project scheduling tools and techniques can be
applied with little modification to software projects.
Program evaluation and review technique (PERT) and critical path method (CPM) are two
project scheduling methods that can be applied to software development. Both techniques are
driven by information already developed in earlier project planning activities.
2.5.1.2.1 Estimates of Effort
 A decomposition of the product function
 The selection of the appropriate process model and task set
 Decomposition of tasks
Interdependencies among tasks may be defined using a task network. Tasks, sometimes
called the project Work Breakdown Structure (WBS) are defined for the product as a whole
or for individual functions.

25
Both PERT and CPM provide quantitative tools that allow the software planner to (1)
determine the critical path-the chain of tasks that determines the duration of the project; (2)
establish "most likely" time estimates for individual tasks by applying statistical models; and
(3) calculate "boundary times" that define a time window" for a particular task.
Boundary time calculations can be very useful in software project scheduling. Slippage in the
design of one function, for example, can retard further development of other functions. It
describes important boundary times that may be discerned from a PERT or CPM network: (I)
the earliest time that a task can begin when preceding tasks are completed in the shortest
possible time, (2) the latest time for task initiation before the minimum project completion
time is delayed, (3) the earliest finish-the sum of the earliest start and the task duration, (4)
the latest finish- the latest start time added to task duration, and (5) the total float-the amount
of surplus time or leeway allowed in scheduling tasks so that the network critical path
maintained on schedule. Boundary time calculations lead to a determination of critical path
and provide the manager with a quantitative method for evaluating progress as tasks are
completed.
2.5.1.3 Testing
In a software development project, errors can be injected at any stage during development.
There are different techniques for detecting and eliminating errors that originate in that phase.
However, no technique is perfect, and it is expected that some of the errors of the earlier
phases will finally manifest themselves in the code. This is particularly true because in the
earlier phases and most of the verification techniques are manual because no executable code
exists. Ultimately, these remaining errors will be reflected in the code. Hence, the code
developed during the coding activity is likely to have some requirement errors and design
errors, in addition to errors introduced during the coding activity. Behaviour can be observed,
testing is the phase where the errors remaining from all the previous phases must be detected.
Hence, testing performs a very critical role for quality assurance and for ensuring the
reliability of software.
During testing, the program to be tested is executed with a set of test cases, and 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 testing can only ascertain the presence of errors in the
program; the exact nature of the errors is not usually decided by testing. Testing forms the

26
first step in determining the errors in a program. Clearly, the success of testing in revealing
errors in programs depends critically on the test cases.
Testing a large system is a very complex activity, and like any complex activity it has to be
broken into smaller activities. Due to this, for a project, incremental testing is generally
performed, in which components and subsystems of the system are tested separately before
integrating them to form the system for system testing. This form of testing, though necessary
to ensure quality for a large system, introduces new issues of how to select components for
testing and how to combine them to form subsystems and systems.
2.5.1.3.1 Top-Down and Bottom-Up Approaches
Generally, parts of the program are tested before testing the entire program. Besides,
partitioning the problem of testing, another reason for testing parts separately is that if a test
case detects an error in a large program, it will be extremely difficult to pinpoint the source of
the error. That is, if a huge program does not work, determining which module has errors can
be a formidable task. Furthermore, it will be extremely difficult to construct test cases so that
different modules are executed in a sufficient number of different conditions so that we can
feel fairly confident about them. In many cases, it is even difficult to construct test cases so
that all the modules will be executed. This increases the chances of a module's errors going
undetected. Hence, it is clear that for a large system, we should first test different parts of the
system independently, before testing the entire system.
In incremental testing, some parts of the system are first tested independently. Then, these
parts are combined to form a (sub) system, which is then tested independently. This
combination can be done in two ways: either only the modules that have been tested
independently are combined or some new untested modules are combined with tested
modules. Both of these approaches require that the order in which modules are to be tested
and integrated be planned before commencing testing.
We assume that a system is a hierarchy of modules. For such systems, there are two common
ways modules can be combined, as they are tested, to form a working program: top-down and
bottom-up. In top-down strategy, we start by testing the top of the hierarchy, and we
incrementally add modules that it calls and then test the new combined system. This approach
of testing requires stubs to be written. A stub is a dummy routine that simulates a module. In

27
the top-down approach, a module (or a collection) cannot be tested in isolation because they
invoke some other modules. To allow the modules to be tested before their subordinates have
been coded, stubs simulate the behavior of the subordinates.
The bottom-up approach starts from the bottom of the hierarchy. First, the modules at the
very bottom, which have no subordinates, are tested. Then these modules are combined with
higher-level modules for testing. At any stage of testing, all the subordinate modules exist
and have been tested earlier. To perform bottom-up testing, drivers are needed to set up the
appropriate environment and invoke the module. It is the job of the driver to invoke the
module under testing with the different set of test cases.
Notice that both top-down and bottom-up approaches are incremental, starting with testing
single modules and then adding untested modules to those that have been tested, until the
entire system is tested. In the first case, stubs must be written to perform testing, and in the
other, drivers need to be written. Top-down testing is advantageous, if major flaws occur
toward the top of the hierarchy, while bottom-up is advantageous if the major flaws occur
toward the bottom. Often, writing stubs can be more difficult than writing drivers, because
one may need to know beforehand the set of inputs for the module being simulated by the
stub and to determine proper responses for these inputs. In addition, as the stubs often
simulate the behavior of a module over a limited domain, the choice of test cases for the
super-ordinate module is limited, and deciding test cases is often very difficult.
It is often best to select the testing method to conform with the development method. Thus, if
the system is developed in a top-down manner, top-down testing should be used, and if the
system is developed in a bottom-up manner, a bottom-up testing strategy should be used. By
doing this, as parts of the system are developed, they are tested, and errors are detected as
development proceeds. It should be pointed out that we are concerned with actual program
development here, not the design method. The development can be bottom-up even if the
design was done in a top-down manner.

28
CHAPTER 3 - INDUSTRY
Shriram Pistons & Rings (SPR) is one of the India’s oldest and most reputed industrial houses,
recognized by almost all OEMs of India and several OEMs in Europe and Asia. We are the largest
manufacturerandexporterof Pistons and Rings from India as well as the largest supplier of Engine
Valves.
Shriram Pistons & Rings Ltd. (SPRL) is one of the largest and most sophisticated manufacturers of
PrecisionAutomobile Componentsi.e.Pistons, Piston Rings, Piston Pins and Engine Valves in India.
The products are sold under brand name ‘USHA/SPR’ in the markets.
SPRL Manufacturing unit is located at Meerut Road in Ghaziabad (25 Km from Delhi).
The plant hasbeenrecognizedasone of the mostmodernand sophisticatedplants in North India in
the fields of Automobile.
The production capacity if the plant is as under
Piston : 15.8 million per year
Pin : 11.0 million per year
Rings : 76.5 million per year
Engine Valves : 32.8 million per year
The company suppliesitsproductstoseveral Original Equipment Manufacturers (OEMs) like Jaguar
Land Rover, Ashok Leyland, Tata Cummins, Tata Motors, Maruti Suzuki, Nissan, Ford & Riken etc.
Quality Objectives
At Shriram Pistons & Rings Ltd. (SPRL) quality is an integral part of whatever we do, which is
reflectedincompany‘squalitypolicy:“Total CustomerSatisfactionThoughQualityManagementand
Continuous Improvement “.
Organization which is sensitive and interactive to the needs of customer.
Continuous upgrading of quality and process to meet changing needs of customer.
Optimization of return on investment by-
Continuous improvement
Technology development
Organizational and Personal development
Cost reduction efforts

29
Effective use of all resources
Harmonious and safe working
Work to international norms of Quality and Management.
The company has practiced the best work ethics and technology along with the TPM & Kaizen
approach and harmony through teamwork.
Customers of SPRL
Domestic Oem’s

30
Global OEM’s
Achievements
SPR received the ISO-9001 certificate from RWTUV, Germany in 1994.
The company received QS-9000 certificate from TUV, Germany in the year 1999.
The company received ISO-14001 certificate in the year 2001.
SPR received the TS-16949 certificate in the year 2003.
The company received OHSAS-18001 certificate in the year 2003.
The company received TPMExcellence award in the year 2004 and many more awards till date.

31
Sales & Services
Features of SPR Factory
Total area covered by factory is 27 acres
The factory has manufacturing facilities for Piston, Ring, Pins and Engine valves
Classification the premises:
P.T.E. - Production Technology and Engineering
C.A.A. – Commercial Administration and Accounts

32
R&D – Research and Development.
Total strengthof the company is 5918 nos. consisting of officers, staff, workers and contract labors.
The turnover of the company of the year 2014-2015 is RS 1280.6 Cr.
The company is exporting in more than 35 countries.
Export sales are of Rs. 237 Cr. The year 2013-14.
Over10% of the productionisexportedtothe sophisticated marketssuchasEurope,UK, Egypt,USA,
Latin America, etc.
SPR has been vesting 30% of its retained earnings in quality upgradation and modernization every
year.
SPRL Collaborators

33
CHAPTER 4- WORK DETAILS
4.1 SYSTEM OVERVIEW
teachers account.
Data structures have been used effectively to handle co-related functions and store the record.
This school billing system C project comprises the following data structures:
struct dat – to store the date (month and day) of entry of records
struct student – to store and organize the record of individual students
struct teacher – to store and organize the record of individual teachers/staffs
I have used the different functions for performing different billing operations in School
Billing System. Listed below are some functions which will give you an outline of the project
and help you understand it better.
start() – shows the account selection screen
chkdat() – for checking date
addrec() – for adding records
modrec() – for modifying records
searchrec() – for searching records
delrec() – for deleting records
fee() – for recording the fee paid and displaying fine, due, total and advance
salary() – for calculating the salary of teachers and staffs
ext() – for exiting

34
4.2 SCREENSHOTS
4.2.1 MAIN MENU
Menu Screen is the first page the user gets to see, while running the School Management
Software.
The user or the Admin gets the following options with their specific functioning after the date
menu; to choose from the Menu screen :
1: STUDENT– to access student record.
2: TEACHER –to access teacher records. .
3: EXIT – Closes the running software.

35
4.2.2 MENU

36
This screen appears, when option 1: STUDENT is selected.
Here the record of a student can be accesed and maintained.
This screen appears, when option 2: TEACHERS is selected.

37
4.2.3 ADD RECORD
Record of student is saved.

38
4.2.4 SEARCH RECORD
Enlisting of all RECORD of student whose data is saved.

39
4.2.5 MODIFY RECORD
This is how the RECORD IS MODIFIED software.

40
4.2.6 DELETE RECORD
DELETE – delete the saved record of any employee.

41
4.2.7 : CALCULATE FEE

42
5. CONCLUSION
The objective of this research was to design and development a user friendly ‘SCHOOL
Management System’.
 This application is useful not for only ‘MAU’, but also any other organization who
are keen to utilize this kind of software.
 It can be operated very easily. There is no need to recruit extra dedicated person or
equipment to handle this application.
 It provides very high level user friendly function. Though we already added
maximum features to this application, we are willing to make the application more
flexible and professional.
5.1 LIMITATIONS
The limitations of the application are as follows:
 Till now there is no login system in our application.
 We worked with only testing arbitrary data, so the application is not tested with large
scale real data which help to find bugs easily.
 Reports are not generated in other application such as Excel, PDF etc.
 No such encryption algorithms.
 Different database connection procedure is complex. Here I used only Files.
 In this application the coding structure is simple.
5.2 FUTURE SCOPE
In future we will overcome current limitations implement the following issues:
a) We can develop the application in PHP or MYSQL.
b) Applying the SSL (Secure Socket Level) for production server.
c) Implementing user management system according permission level.
d) Appling time and skill reducing techniques.
e) Generating report in other application like Excel, PDF etc.
f) Merging modules.

43
6. BIBLIOGR A PHY
1. Robert Lafore “C”.
2. E.M. Awad “System Analysis & Design”V. RAJARAMA .
3. Venugopal “Mastering C”.
4. V. RAJARAMAN “Analysis & Design of Information System “
5. Yashavant Kanetkar “C PROJECT”.
6. Roger S. Pressman “Software Engineering A Practioner’s Approach”.

school billing system report

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à school billing system report

Similaire à school billing system report (20)

Dernier

Dernier (20)

school billing system report