Chapter 1

Introduction

Computerized on school administration System is developed to facilitate the General

administration system to manage the various information of the school and the processes
involved in an administration system of the school.So, that organization can access accurate
information quickly and easily as and when required, thereby improving its operational
efficiency & effectiveness
In today’s competitive environment, where Everybody wants to be on the top,
Information plays very crucial role. As fast as information is accessed and processed, it can give
good results.
Computerized system helps to fulfill these goals. Computerization of the official
works will help in doing lot of manual work quickly. It will help in easy storage and access of all
information, in short period of time.

1
 Synopsis school administration

What contribution would the Project make: -

The project would help in effective and systematic record keeping that is storing and retrieving
of useful data. Project will be able to give the report so that management can make decisions on
the basis of those reports.

Scope of the study

The main Scope of study: -

1. It should contain all the information of students and teachers working in the school.
2. It should contain all the information like Personal Detail, Professional Detail, and
Educational Detail etc.
3. It should process and evaluate teachers recruited and students admitted.

2
 Modules of project:
The project can be divided in to three main modules.
• Addition of information
• Modification of information
• Deletion of information

Module 1:
Addition of information involves:
• Addition of new teacher hired.

• Addition of personal details of the teacher.

• Addition of new student admitted.

• Addition of detail of the student.

• Addition of fee detail.

Module 2:

Modification of information,involves :

• Editing of students’ detail.

• Editing of teachers’ detail.

• Save the modified data.

3
Module 3:

Deletion of information involves:

• Delete the details of a particular student.

• Delete the details of a teacher.

4
 Company Profile

1.1 Brief description about the organization.

1.1.1 Company profile

Njoy DEVELOPERS TM is equipped with necessary infrastructure and fresh manpower

VAT provides accurate, confidential & cost effective services & integrity solutions to its

customers. It strive to achieve total customer satisfaction by delivering in time & through

quality products, services, solutions and training. They aim for continuous improvement

in their services and products through structured employee training programs and

involvement of their business partners.

Their journey has been eventful and designated for growth.

They are the young & trusted names in software solution and services, through it's

advanced research and development. The main mission of the company is science and

success and their vision is leading software solution company.

1.1.2. services

1. Software Solutions

Njoy Developers is a leading software developing company in India. It has an excellent

reputation in fulfilling the client requirements and keeping the project duration in
accordance to the business needs. It employ some of the market best professionals to
deliver their clients exactly what they want and cost effective.

NJOY DEVELOPERS undertake all forms of application development as desired by their

perspective clients. C, C++, Visual Basic, .Net, JAVA etc. are few of the technologies
taking care of robust application development. As and when required they indulge
databases from oracle, SQL etc. to even independent databases for inlaying the concept
behind the approach.

5
NJOY DEVELOPERS analyze a project and define its goals, and plan a detail roadmap
to achieve those goals. By following a rigorous and proven methodology of defining,
designing and developing software projects, turn project concepts into reality. With Njoy
Developers, you can reap benefits that you always wanted to achieve.

2.)WEB DEVELOPMENT

Njoy Developers provides advanced web development services which aims at executing
dynamic applications that would meet the growing business needs on the web.Technical
excellence allows them to deliver projects of any complexity: from simple scripts to
complex applications.Its web developers stay updated with newest web development
technologies constantly advancing in knowledge and technique.

Every business requires promotion via marketing (direct/indirect) for its future growth
and therefore to achieve reach at large distances with less expenses, web plays a vital role
incurring business. Sometimes few pages of information sharing about the company fetch
business more than enough to compel upon. This is what it call static site playing its role
by doing its part of marketing in this globalized network.

Dynamic sites are the second half of the coin in this web arena. Doing business sitting
anywhere in the world with the safety of transactions of products/services to the transfer
of funds safely to bank accounts. Organizational requirements of mailing, data sharing,
shared strategy and approach development etc. can be accumulated via dynamic website.
From ticketing, shopping, training the scope is endless and is dependent on the
requirement and the dynamic approach of doing the same.

NJOY DEVELOPERS cater most of the languages ASP, JSP, CFM, PHP, .NET,
PYTHON etc. It includes static form as in HTML/DHTML/XHTML. It serve WEB 2.0
standards by maintaining XML, CSS and JAVASCRIPT standardized utilization. Flash
and FLEX are also providing groundbreaking lead in the market full of competition. It
also provide bank transfer facilities for online sales.

3. SEO/SEM

SEO or Search Engine Optimization is a very strategic act of speeding the search in the
web. There are several search engine providers who look into various websites and
collect their relevance and maintain their databases with facts and figures in regards to
the website. Few of the top search engine providers namely Google, Yahoo, MSN (Bing)
etc. are few of different search engines with their strategy of its own kind to rank
websites.

Njoy Developers is undisputed pioneer in Search Engine Optimization and Search Engine
Marketing. It not only just rank you top on major search engines but it assure to achieve a

6
good click through rate from the targeted visitors. This means that your website definitely
comes up in the search results of the search engines with targeted keywords that are
related to your content or theme of your site.

Every search engine has its own pros and cons but definitely has customers comfortable
with the feature it provides that leads us to our target market. Every search engine also
has their own algorithms of doing search and to rank websites in accordance to keywords
and popularity recurring to visits by users. Therefore, it is important to understand the
algorithms to reach up to the top rank with desired keywords.

It is always good to save time and quickly get up to the top of search engines and for that
there are several steps to trace pass the standard approach. But doing such an act leads to
blacklist the website which brings it to the lowest of the rank and is bad to the image of
the company. Therefore, standards are best to follow to get the perfect result as expected.

Search engine marketing is another level to promote a website which brings you to
people’s notice by investing some share of money. This also brings notice of desired
customers towards our website. Both SEO & SEM plays a vital role to take fair share of
business. One shows the web popularity and other one shows the market trend with the
right words fetched with good business strategy.

7
 1.2 About the Project

As the person operating the school administration software had to spend days in the
hassles that come bundled with this software. He had to handle and maintain bulky
registers, All calculations were done manually, It was very difficult to find a
particular record or file, It was very difficult to maintain bulky registers and resulted
in the loss of information and It was difficult to produce and maintain accurate
results.
Objective of developing this software is to automate and computerize the daily
working of a school department, so that transactions become fast and error free. It
replaces all the paper work. It keeps records of students and teacher, and produces the
desired report whenever required.

8
 1.2.1 Platform

In computing, a platform describes some sort of hardware architecture or software

framework (including application frameworks), that allows software to run. Typical
platforms include a computer's architecture, operating system, programming languages
and related runtime libraries or graphical user interface.

Platform includes the firmware, device drivers, an operating system, and typically a
graphical user interface which, in total, allow a user to interact with the computer and its
peripherals (associated equipment). Platform software often comes bundled with the
computer. On a PC you will usually have the ability to change the platform software.

Platform is a hardware and/or software architecture that serves as a foundation or base.

The term originally dealt with only hardware, and it may still refer to only a CPU model
or computer family. For example, the x86 PC is the world's largest hardware platform.
IBM's iSeries (AS/400) and Sun's SPARC are also hardware platforms. The terms
"platform" and "environment" are used interchangeably.

The term Platform often refers to an operating system, and the hardware is generally
implied. For example, when an application is said to "run on the Windows platform," it
means that the program has been compiled into the x86 machine language and runs under
Windows. It implies x86 because Windows runs mostly on x86 PCs. Operating systems
are always "software platforms" because applications must interface with them.

9
C++ language is used as a platform for this project. It is CUI(console user interface)
based. It is a general-purpose programming language. It is regarded as a middle-level
language, as it comprises a combination of both high-level and low-level language
features.[1] It is a statically typed, free-form, multi-paradigm, compiled language where
compilation creates machine code for a target machine hardware, supports procedural
programming, data abstraction, object-oriented programming, and generic programming.

The language was developed by Bjarne Stroustrup in 1979 at Bell Labs as an

enhancement to the C programming language and originally named "C with Classes". It
was renamed to C++ in 1983. Enhancements started with the addition of classes,
followed by, among other features, virtual functions, operator overloading, multiple
inheritance, templates, and exception handling.

The C++ programming language standard was ratified in 1998 as ISO/IEC 14882:1998,
the current version of which is the 2003 version, ISO/IEC 14882:2003. A new version of
the standard (known informally as C++0x) is being developed.

C++ enjoys wide use in the software industry. Some of its application domains include
systems software, device drivers, embedded software, high-performance server and client
applications, and entertainment software such as video games. Several groups provide
both free and commercial C++ compiler software, including the GNU Project, Microsoft,
Intel, Borland and others.

C++ is an object oriented programming language. It was developed by Bjarne Stroustrup

at AT&T Bell Laboratories in USA developed it in the early 1980’s. Stroustrup wanted to
create a powerful language that could support object-oriented features.

C++ is an extension of C. C++ is nothing but enhanced with a few grand new concepts
like data hiding, encapsulation, polymorphism, and inheritance. C++ is derived from C
increment operator ++ . Thus in every sense C++ is a superset of C. A valid C program is
a valid C++ program. But the reverse is not correct.

OOPs Concepts:
Operators and operator overloading

C++ provides more than 30 operators, covering basic arithmetic, bit manipulation,
indirection, comparisons, logical operations and more. Almost all operators can be
overloaded for user-defined types, with a few notable exceptions such as member access
(. and .*). The rich set of overloadable operators is central to using C++ as a domain
specific language.

10
As a simple example, a class that represents a matrix could overload the multiplication
(*) and other arithmetic operators, allowing it to be treated by application code similarly
to the standard numerical types.

matrix a, b;
matrix c = a * b;

The overloadable operators are also an essential part of many advanced C++
programming techniques, such as smart pointers.

Overloading an operator does not change the precedence of calculations involving the
operator, nor does it change the number of operands that the operator uses (any operand
may however be ignored).

Overloading also implements the concept of Polymorphism which is a property of an

Object Oriented language.

Templates

C++ templates enable generic programming. C++ supports both function and class
templates. Templates may be parameterized by types, compile-time constants, and other
templates. C++ templates are implemented by instantiation at compile-time. To
instantiate a template, compilers substitute specific arguments for a template's parameters
to generate a concrete function or class instance. Templates are a powerful tool that can
be used for generic programming, template metaprogramming, and code optimization,
but this power implies a cost. Template use may increase code size, since each template
instantiation produces a copy of the template code: one for each set of template
arguments. This is in contrast to run-time generics seen in other languages (e.g. Java)
where at compile-time the type is erased and a single template body is preserved.

Templates are different from macros: while both of these compile-time language features
enable conditional compilation, templates are not restricted to lexical substitution.
Templates are aware of the semantics and type system of their companion language, as
well as all compile-time type definitions, and can perform high-level operations including
programmatic flow control based on evaluation of strictly type-checked parameters.
Macros are capable of conditional control over compilation based on predetermined
criteria, but cannot instantiate new types, recurs, or perform type evaluation and in effect
are limited to pre-compilation text-substitution and text-inclusion/exclusion. In other
words, macros can control compilation flow based on pre-defined symbols but cannot,
unlike templates, independently instantiate new symbols. Templates are a tool for static
polymorphism (see below) and generic programming.

11
For example, a template replacing the common, but ill-advised, macro

#define max(x,y) ((x)>(y)?(x):(y)):

template <typename T>

const T& max(const T& x, const T& y)
{
return x < y ? y : x;
}

This can be found in the algorithm header as std::max(). Traditionally the

keyword class may also be used in place of typename.

In addition, templates are a compile time mechanism in C++ which is Turing-complete,

meaning that any computation expressible by a computer program can be computed, in
some form, by a template metaprogram prior to runtime.

In summary, a template is a compile-time parameterized function or class written without

knowledge of the specific arguments used to instantiate it. After instantiation the
resulting code is equivalent to code written specifically for the passed arguments. In this
manner, templates provide a way to decouple generic, broadly-applicable aspects of
functions and classes (encoded in templates) from specific aspects (encoded in template
parameters) without sacrificing performance due to abstraction.

Objects
Main article: C++ structures and classes

C++ introduces object-oriented (OO) features to C. It offers classes, which provide the
four features commonly present in OO (and some non-OO) languages: abstraction,
encapsulation, inheritance, and polymorphism. Objects are instances of classes created at
runtime. The class can be thought of as a template from which many different individual
objects may be generated as a program runs.

Encapsulation

Encapsulation is the hiding of information. C++ implements encapsulation by allowing

all members of a class to be declared as either public, private, or protected. A public
member of the class is accessible to any function. A private member is accessible only to
functions that are members of that class and to functions and classes explicitly granted
access permission by the class ("friends"). A protected member is accessible to members
of classes that inherit from the class in addition to the class itself and any friends.

12
The OO principle is that all of the functions (and only the functions) that access the
internal representation of a type should be encapsulated within the type definition.C++
supports this (via member functions and friend functions), but does not enforce it: the
programmer can declare parts or all of the representation of a type to be public, and is
allowed to make public entities that are not part of the representation of the type. Because
of this, C++ supports not just OO programming, but other weaker decomposition
paradigms, like modular programming.

It is generally considered good practice to make all data private or protected, and to make
public only those functions that are part of a minimal interface for users of the class. This
hides all the details of data implementation, allowing the designer to later fundamentally
change the implementation without changing the interface in any way.

Inheritance

Inheritance allows one data type to acquire properties of other data types. Inheritance
from a base class may be declared as public, protected, or private. This access specifier
determines whether unrelated and derived classes can access the inherited public and
protected members of the base class. Only public inheritance corresponds to what is
usually meant by "inheritance". The other two forms are much less frequently used. If the
access specifier is omitted, a "class" inherits privately, while a "struct" inherits publicly.
Base classes may be declared as virtual; this is called virtual inheritance. Virtual
inheritance ensures that only one instance of a base class exists in the inheritance graph,
avoiding some of the ambiguity problems of multiple inheritance.

Multiple inheritance is a C++ feature sometimes considered controversial. Multiple

inheritance allows a class to be derived from more than one base class; this can result in a
complicated graph of inheritance relationships. For example, a "Flying Cat" class can
inherit from both "Cat" and "Flying Mammal". Some other languages, such as Java or
C#, accomplish something similar (although more limited) by allowing inheritance of
multiple interfaces while restricting the number of base classes to one (interfaces, unlike
classes, provide only declarations of member functions, no implementation or member
data).

Polymorphism

Polymorphism enables one common interface for many implementations, and for objects
to act differently under different circumstances.

C++ supports several kinds of static (compile-time) and dynamic (run-time)

polymorphisms. Compile-time polymorphism does not allow for certain run-time
decisions, while run-time polymorphism typically incurs a performance penalty.

13
Static polymorphism
Function overloading

Function overloading allows programs to declare multiple functions having the same
name (but with different arguments). The functions are distinguished by the number
and/or types of their formal parameters. Thus, the same function name can refer to
different functions depending on the context in which it is used. The type returned by the
function is not used to distinguish overloaded functions.

Default arguments

When declaring a function, a programmer can specify default arguments for one or more
parameters. Doing so allows the parameters with defaults to optionally be omitted when
the function is called, in which case the default arguments will be used. When a function
is called with fewer arguments than there are declared parameters, explicit arguments are
matched to parameters in left-to-right order, with any unmatched parameters at the end of
the parameter list being assigned their default arguments. In many cases, specifying
default arguments in a single function declaration is preferable to providing overloaded
function definitions with different numbers of parameters.

Class and function templates

Templates in C++ provide a sophisticated mechanism for writing generic, polymorphic

code. In particular, through the Curiously Recurring Template Pattern it's
possible to implement a form of static polymorphism that closely mimics the
syntax for overriding virtual functions (a dynamic polymorphism technique
described below). Since C++ templates are type-aware and Turing-complete
they can also be used to let the compiler resolve recursive conditionals and
generate substantial programs through Dynamic polymorphism

Inheritance

Variable pointers (and references) to a base class type in C++ can refer to objects of any
derived classes of that type in addition to objects exactly matching the variable type. This
allows arrays and other kinds of containers to hold pointers to objects of differing types.
Because assignment of values to variables usually occurs at run-time, this is necessarily a
run-time phenomenon.

14
C++ also provides a dynamic_cast operator, which allows the program to safely
attempt conversion of an object into an object of a more specific object type (as opposed
to conversion to a more general type, which is always allowed). This feature relies on
run-time type information (RTTI). Objects known to be of a certain specific type can also
be cast to that type with static_cast, a purely compile-time construct which is faster
and does not require RTTI.

Virtual member functions

Ordinarily when a function in a derived class overrides a function in a base class, the
function to call is determined by the type of the object. A given function is overridden
when there exists no difference, in the number or type of parameters, between two or
more definitions of that function. Hence, at compile time it may not be possible to
determine the type of the object and therefore the correct function to call, given only a
base class pointer; the decision is therefore put off until runtime. This is called dynamic
dispatch. Virtual member functions or methods allow the most specific implementation of
the function to be called, according to the actual run-time type of the object. In C++, this
is commonly done using virtual function tables. If the object type is known, this may be
bypassed by prepending a fully qualified class name before the function call, but in
general calls to virtual functions are resolved at run time.

In addition to standard member functions, operator overloads and destructors can be

virtual. A general rule of thumb is that if any functions in the class are virtual, the
destructor should be as well. As the type of an object at its creation is known at compile
time, constructors, and by extension copy constructors, cannot be virtual. Nonetheless a
situation may arise where a copy of an object needs to be created when a pointer to a
derived object is passed as a pointer to a base object. In such a case a common solution is
to create a clone() (or similar) function and declare that as virtual. The clone()
method creates and returns a copy of the derived class when called.

A member function can also be made "pure virtual" by appending it with = 0 after the
closing parenthesis and before the semicolon. Objects cannot be created of a class with a
pure virtual function and are called abstract data types. Such abstract data types can only
be derived from. Any derived class inherits the virtual function as pure and must provide
a non-pure definition of it (and all other pure virtual functions) before objects of the
derived class can be created. An attempt to create an object from a class with a pure
virtual function or inherited pure virtual function will be flagged as a compile-time error.

15
 1.2.2 Frontend

Front-end is generalized term that refers to the initial stage of a process. The front-end is
responsible for collecting input in various forms from the user and processing it to
conform to a specification the back-end can use. The connection of the front-end to the
back-end is a kind of interface.

In software design, the front-end is the part of a software system that interacts directly
with the user, and the back-end comprises the components that process the output from
the front-end . . However, sometimes programs are written which serve simply as a front-
end to another, already existing program, such as a graphical user interface (GUI) which
is built on top of a command-line interface.

Some common methods for interacting with computers can be conceptualized in terms of
a "front-end" and "back-end". For example, a graphical file manager, such as Windows
Explorer, can be thought of as a front-end to the computer's file system. At the OS level,
the concept of a graphical user interface (GUI) can be thought of as a front-end for the
system (for general users), while the command line or "TUI" is sufficiently technical to
be considered as a back-end. Another common use for the term front-end is for network
application front-end hardware.

This Project use Command Prompt or you can say DOS as a Frontend.as it is built on C+
+ it doesn’t have any graphical user interface (GUI).It shows the output of the program
on Command Prompt.

16
 1.2.3 Backend

Front-end and Backend is the generalized term that refer to the initial and the end stages
of a process. The front-end is responsible for collecting input in various forms from the
user and processing it to conform to a specification the back-end can use. The connection
of the front-end to the back-end is a kind of interface.

In software design, the front-end is the part of a software system that interacts directly
with the user, and the back-end comprises the components that process the output from
the front-end. The separation of software systems into "front-ends" and "back-ends" is an
abstraction that serves to keep the different parts of the system separated.

Many programs are divided conceptually into front and back-ends, but in most cases, the
"back-end" is hidden from the user. However, sometimes programs are written which
serve simply as a front-end to another, already existing program, such as a graphical user
interface (GUI) which is built on top of a command-line interface. This type of front-end
is common in Unix GUIs, where individual programs are developed as many small
programs, able to run independently or together. See graphical (desktop environment)
and semi-graphical (such as ncurses) front-ends.

Some common methods for interacting with computers can be conceptualized in terms of
a "front-end" and "back-end". For example, a graphical file manager, such as Windows
Explorer, can be thought of as a front-end to the computer's file system. At the OS level,
the concept of a graphical user interface (GUI) can be thought of as a front-end for the
system (for general users), while the command line or "TUI" is sufficiently technical to
be considered as a back-end. This often applies to software packages as well, which may
have both graphical interfaces (front) as well as command-line scripts (back).

Another common use for the term front-end is for network application front-end
hardware. This is network hardware which can optimize or protect network traffic. It is
called application front-end hardware because it is placed on the networks front-end.
Meaning that network traffic passes through the application front-end hardware before
any other part of the network.

In compilers, the front-end translates a computer programming source language into an

intermediate representation, and the back-end works with the internal representation to
produce code in a computer output language. The back-end usually optimizes to produce
code that runs faster. The front-end/back-end distinction can separate the parser section
that deals with source code and the back-end that does code generation and optimization;
in some designs (such as GNU) there may in fact be multiple back-ends using the same
front end. Each target processor would have its own back end but use the same front end.
In speech synthesis, the front-end refers to the part of the synthesis system that converts
the input text into a symbolic phonetic representation, and the back-end converts the
symbolic phonetic representation into actual sounds.

17
 Chapter 2 Objective of the Study

Objective of developing this software is to automate and computerize the daily working

of a school department, so that transactions become fast and error free. It replaces all the

paper work. It keeps records of students and teacher, and produces the desired report

whenever required.

18
 2.1 Problem Definition

Project Definition at phase start

The Project Definition forms the project's definitive definition and mandate. It is used as
a major input to the detailed planning and resourcing that takes place as each phase of
work is planned, initiated and mobilized.

It is also important that the project's purpose and goals are communicated to the team
members and other participants. They need to understand the value and importance of
their work. In most cases it also improves their ability to deliver if they understand the
"big picture".

Project Definition during the project

Remember that things change. The business changes; customers' needs move on;
departments are restructured; there may be mergers and acquisitions; there may be
demands to cut costs or drive change faster. At any time when the project's purpose might
be challenged or the anticipated outcome is significantly changed, the Project Definition
should be re-examined to see in what ways it has changed or should be changed to reflect
the new circumstances. Where this has an impact on the benefit case, approach, planning,
timing, resourcing, or expected outcome, the Project Manager will need to review and re-
calculate the detailed changes and present a revised definition for agreement by the
project's sponsors and executive leaders.

Project Definition at phase end

Phase end is a good time to measure the success of the project to date. See how well the
project's original ambitions are being adhered to and how the anticipated benefit matches
up to the original definition. Report back successes, failures and revised expectations to
the project sponsors and executive. Give that feedback to the team as well so that they
understand how well they are performing and how valuable their work has been.

Where there has been some significant departure from the original intentions, the Project
Manager should investigate, review, analyze and report these conclusions to the project
sponsors and executive team, along with any specific recommendations or planning
revisions. As ever, the guiding principle should be to obtain the optimum benefit for the
organization.

19
Project Definition at project end

In all good projects, the leadership and participants take time to reflect upon successes
and failures. In particular, it is important to determine whether the defined project was
successfully completed - both in terms of the most recent definition and against the
original intentions. There are several reasons for this:

 to determine whether the work is really finished or whether further action is

required
 to consider whether further initiatives should be defined to build upon the success
of the project
 to show that benefit has been achieved and that the project will generate value
 so that the success can be communicated both within the organization and to
external parties such as customers, investors, suppliers etc
 for the organisation to learn lessons about this type of business initiative
 for the individuals to learn lessons about their strengths and weaknesses, and to
identify successful approaches to their work.

The project definition describes the purpose of the project and how it will be organized
and managed. A Project Definition Report (PDR) should be produced, and signed up to
by all the stakeholders. The PDR should include the following sections:

• Goals & Objectives

• Scope & Work Structure
• Organization
• Management Processes & Systems
• Key milestones and imperatives
• Risks & Assumptions
• Start-up Actions

A Project Definition Workshop with an independent facilitator is often used to complete

the PDR and gain consensus of the sponsors and stakeholders.

"An undefined project cannot be managed...an unmanaged project usually fails!!"

20
Problem of School Administration

The person operating the school administration software had to spend days in the hassles
that come bundled with this software. He had to handle and maintain bulky registers, all
calculations were done manually, it was very difficult to find a particular record or file, it
was very difficult to maintain bulky registers and resulted in the loss of information and it
was difficult to produce and maintain accurate results.

21
 2.2 Objectives and Purpose of the Study

Objective of developing this software is to automate and computerize the daily working
of a school department, so that transactions become fast and error free. It replaces all
the paper work. It keeps records of students and teacher, and produces the desired
report whenever required. School Administration Software is a complete suite of
applications that empowers you to automate all aspects of school management
without data redundancy and proper inter module exchange. School Management
Software permits you to capture, manipulate and present student data and teacher’s
data in a meaningful manner and also it is an easy-to-use application. Once data has
been captured, the student and teacher information module uses this data to compile
meaningful reports; and, replicates the student information wherever it is necessary.
The required student information is available to the registrar at the touch of a button.

22
 2.3 Significance of Study

The significance of study is actually the outcome of study process. The outcome of the
study process is the software for school administration.Only after studying the problem
and requirements of user we can devlop a software.

Significance of School Administration Project

Economical:- This project is economical or less costly as

Convenient:- Ii is very easier and convenient to use

• Helps to manage student’s records.
• Helps to manage teacher’s records.
• We can add new records.
• We can delete old records.
• We can also modify the records.
• We can view the personal information of all the students oo teachers together in a
list.

Very Less Time Consuming:- very faster to use and work with.

Source of Information:- provides the list of all teachers and students.

23
 Chapter 3 Methodology

Methodology means the methods used to solve the particular problem or methods used in
designing the project. The term methodology means particular steps or methods used in a
particular project.

In this project methodology means methods which are used to design this project.
Methods to design the website are mainly software platform, computer language, dialog
boxes, etc.

24
 3.1 Requirement Specification

The Importance of Requirements and Specifications

Behind any rational effort should be a formal structure and methodology known as a
project plan. Project planning is a technique now common to information technology and
media work.

Most projects include a body of information that describes the product or output of the
project's work effort; this information deals with the objectives of the final product,
defined in the project requirements, and any rules for creating the product, defined in the
project specifications.

Requirements Define Necessary Objectives

Any coherent and reasonable project must have requirements that define what the project
is ultimately supposed to do.

A requirement is an objective that must be met. Planners cast most requirements in

functional terms, leaving design and implementation details to the developers. They may
specify price, performance, and reliability objectives in fine detail, along with some
aspects of the user interface. Sometimes, they describe their objectives more precisely
than realistically.

There are actually several kinds of requirements; the term requirement is awkward
because it describes the concept of an objective or goal or necessary characteristic, but at
the same time the term also describes a kind of formal documentation, namely the
requirements document. Putting aside the particular document for now, requirements are
instructions describing what functions the software is supposed to provide, what
characteristics the software is supposed to have, and what goals the software is supposed
to meet or to enable users to meet.

I prefer to use the term requirements to refer to the general set of documents that describe
what a project is supposed to accomplish and how the project is supposed to be created
and implemented. Such a general set of requirements would include documents spelling
out the various requirements for the project -- the "what" -- as well as specifications
documents spelling out the rules for creating and developing the project -- the "how".

Project requirements provide an obvious tool for evaluating the quality of a project,
because a final review should examine whether each requirement has been met.
Unfortunately, it's never quite that easy. Requirements tend to change through the course
of a project, with the result that the product as delivered may not adhere to the available
requirements -- this is a constant and annoying facet to the quality assurance process.

25
Moreover, meeting all of the requirements doesn't ensure a quality product, per se, since
the requirements may not have been defined with an eye towards the quality of the end-
user's experience. A project's specifications are more useful for determining the product's
quality.

Specifications Define How to Meet the Objectives

A specification is literally the discussion of a specific point or issue; it's hard in this
instance to avoid the circular reference. A project's specifications consist of the body of
information that should guide the project developers, engineers, and designers through
the work of creating the software.

A specification document describes how something is supposed to be done. This

document may be very detailed, defining the minutia of the implementation; for example,
a specifications document may list out all of the possible error states for a certain form,
along with all of the error messages that should be displayed to the user. The
specifications may describe the steps of any functional interaction, and the order in which
they should be followed by the user. A requirements document, on the other hand, would
state that the software must handle error states reasonably and effectively, and provide
explicit feedback to the users. The specifications show how to meet this requirement.

Specifications may take several forms. They can be a straightforward listing of functional
attributes, they can be diagrams or schematics of functional relationships or flow logic, or
they can occupy some middle ground. Specifications can also be in the form of
prototypes, mockups, and models.

Project specifications are much more important for determining the quality of the
product. Every rule and functional relationship provides a test point. Adherence to
specification is not a perfect measure.

A mismatch between the program and its specification is an error in the program if and
only if the specification exists and is correct. A program that follows a terrible
specification perfectly is terrible, not perfect.

26
6 test points to be covered when reviewing requirements and specifications, described
here briefly:

• Are these the "right" requirements?

• Are they complete?
• Are they compatible?
• Are they achievable?
• Are they reasonable?
• Are they testable?
Examples of Requirements and Specifications Documentation

The following list describes the various kinds’ formal documents that belong to the body
of requirements and specifications document. These are not all mandatory for each and
every software project, but they do all provide important information to the developers,
designers and engineers tasked with implementing a project and to the quality assurance
people and testers responsible for evaluating the implementation of the project. These
topics may also be combined as sections of larger and inclusive requirements and
specifications documents.

System Requirements

The term system requirement has two meanings. First, it can refer to the requirements
that describe the capabilities of the system with which, through which, and on which the
product will function. For example, the web site may need to run on a dual processor box,
and may need to have the latest brandX database software.

Second, it can refer to the requirements that describe the product itself, with the meaning
that the product is a system. This second meaning is used by the authors of Constructing
Superior Software

There are two categories of system requirements. Functional requirements specify

what the system must do. User requirements specify the acceptable level of user
performance and satisfaction with the system.

Functional Requirements

Functional requirements describe what the software or web site is supposed to do by

defining functions and high-level logic.

27
In many cases, if the user requirements are written for the requestor and not the end-user,
the functional requirements are combined with the functional requirements; this is
common within companies that have a strong Information Technology department that is
tasked with doing the work.

User Requirements

User requirements typically describe the needs, goals, and tasks of the user. I say
"typically" here because often these user requirements don't reflect the actual person who
will be using the software; projects are often tailored to the needs of the project requestor,
and not the end-user of the software. I strongly recommend that any user requirements
document define and describe the end-user, and that any measurements of quality or
success be taken with respect to that end-user.

User requirements are usually defined after the completion of task analysis, the
examination of the tasks and goals of the end-user.

Functional Specifications

Functional specifications describe the necessary functions at the level of units and
components; these specifications are typically used to build the system exclusive of the
user interface.

With respect to a web site, a unit is the design for a specific page or category of page, and
the functional specification would detail the functional elements of that page or page
type. For example, the design for the page may require the following functions: email
submission form, search form, context-sensitive navigation elements, logic to drop and/or
read a client-side cookie, etc. These aren't "look" issues so much as they are
"functionality" issues. A component is a set of page states or closely related forms of a
page. For example, a component might include a page that has a submission form, the
acknowledgement page (i.e., "thanks for submitting"), and the various error states (i.e.,
"you must include your email address", "you must fill in all required fields", etc.).

The functional specifications document might have implications about the design of the
user interface, but these implications are typically super ceded by a formal design
specification and/or prototype.

Design Specifications

The design specifications address the "look and feel" of the interface, with rules for the
display of global and particular elements.

28
Flow or Logic Diagram

Flow diagrams define the end-user's paths throng the site and site functionality. A flow
diagram for a commerce site would detail the sequence of pages necessary to gather the
information required by the commerce application in order to complete an order.

Logic diagrams describe the order that logic decisions are made during the transmission,
gathering, or testing of data. So for example, upon submission of a form, information
may be reviewed by the system for field completeness before being reviewed for
algorithmic accuracy; in other words, the system may verify that required fields have in
fact been completed before verifying that the format of the email address is correct or the
credit card number is an algorithmically valid number. Another example would be the
logic applied to a search query, detailing the steps involved in the query cleanup and
expansion, and the application of Boolean operators.

System Architecture Diagram

A system architecture diagram illustrates the way the system hardware and software must
be configured, and the way the database tables should be defined and laid out.

Prototypes and Mock-ups

A prototype is a model of the system delivered in the medium of the system. For
example, a web site prototype would be delivered as a web site, using the standard web
protocols, so that it could be interacted with in the same medium as the project's product.
Prototypes don't have to be fully functioning, they merely have to be illustrative of what
the product should look and feel like. In contrast, a mock-up is a representation in a
different medium. A web site mock-up might be a paper representation of what the pages
should look like.

The authors of Constructing Superior Software describe several categories of prototypes:

low fidelity prototypes which correspond to what I've labeled "mock-ups", and high
fidelity prototypes.

Low fidelity prototypes are limited function and limited interaction prototypes. They are
constructed to depict concepts, design alternatives, and screen layouts rather than to
model the user interaction with the system....There are two forms of low fidelity
prototype: abstract and concrete....The visual designer works from the abstract prototype
and produces drawings of the interface as a concrete low fidelity prototype....High
fidelity prototypes are fully interactive

29
Prototypes and mock-ups are important tools for defining the visual design, but they can
be problematic from a quality assurance and testing point of view because they are a
representation of a designer's idea of what the product should look and feel like. The
issue is not that the designer's may design incorrectly, but that the prototype or mock-up
will become the de facto design by virtue of being a representation. The danger is that the
design will become final before it has been approved; this is known as "premature
concretization" or "premature crispness of representation", where a sample becomes the
final design without a formal decision. If you have every tried to get page element
removed from a design, you have an idea what this problem is like. The value of
prototypes is that they provide a visual dimension to the written requirements and
specifications; they are both a proof of concept and the designers' sketchpad wrapped up
in one package.

Technical Specifications

Technical specifications are typically written the by developers and coders, and describe
how they will implement the project. The developers work from the functional
specifications, and translate the functions into their actual coding practices and
methodologies.

30
Implementation of Requirement Specification

The growing busy-ness of the people and there desire to get the accurate information
quickly has lead the software developers to create systems that satisfy the need of the
information. As there are a huge number of students in a school, it has become essential
for the management to change the manual system into an interactive computer based
system for effective performance, which means easy feeding up and retrieval of all the
information’s regarding any student. So the design of this system considers the various
requirements of the staff.

31
HARDWARE & SOFTWARE REQUIREMENTS

HARDWARE:

Processor : Pentium II 166 MHz or above

Memory : 4 MB RAM or above

Cache Memory : 128 KB or above

Hard Disk : 1 GB or above

[At least 3 MB Free space required]

Floppy Disk : 3.5” with 1.44 MB capacity

[At least one drive labeled A: required]

Printer : Dot Matrix/DeskJet connected to LPT port

SOFTWARE:

Operating System : MS-DOS 6.22, Windows 95, Windows 98,

Windows ME, Windows NT 4.0,
Windows 2000 and Windows XP

Application software : TURBO ++ [Dos based]

32
 3.2 Feasibility Study

A feasibility study is a preliminary study undertaken to determine and document a

project's viability. The term is also used to describe the preliminary analysis of an
existing system to see if it is worth upgrading all or a part. Also known as feasibility
analysis. The term feasibility study is also used to refer to the resulting document. The
results of this study are used to make a decision whether or not to proceed with the
project. If it indeed leads to a project being approved, it will — before the real work of
the proposed project starts — be used to ascertain the likelihood of the project's success.
It is an analysis of possible alternative solutions to a problem and a recommendation on
the best alternative. It, for example, can decide whether an order processing be carried
out by a new system more efficiently than the previous one.

A feasibility study is an important part of creating a business plan for a new enterprise,
since it has been estimated that only one idea in fifty is commercially viable.

If a project is seen to be feasible from the results of the study, the next logical step is to
proceed with it. The research and information uncovered in the feasibility study will
support the detailed planning and reduce the research time.

Three primary areas of interest in feasibility study are:-

Economic Feasibility: An evaluation of development cost weighed against the ultimate

income of benefit derived from the development system or product. In it, we have to
evaluate the cost of time spending to develop software, other charges like maintenance.
The total cost calculated to develop this software is Rs. 50,000.

Technical Feasibility: A study of function, performance, and constraints that may affect
the ability to achieve an acceptable system.

Behavioral Feasibility: People are inherently resistant to change; computers have been
known to facilitate change. An estimate should be made of how strong a reaction
the user staff is likely to have toward the development of a computerized system.

33
 3.3 System Design

System design is a solution, a “how to” approach to the creation of a new system. This
important phase is composed of several steps. It provides the understanding and
procedural details necessary for implementing the system recommended in the feasibility
study. Emphasis is on tranelating the psrformance requirements into design
specifications.

Design goes through two main stages of development which are as follows:-

1. Logical Design:- Various Steps in logical design are

• Logical design reviews the present physical system;

• Prepares input and output specifications;
• Makes edit, security, and control specifications;
• Details the implementation plan;
• And prepares a logical design walkthrough.

2. Physical Design:- Various steps in physical design are

• Physical design maps out the details of the physical system,

• Plans the system implementation,
• Devises a test and implementation plan,
• And specifies any new hardware and software.

Structured design methodologies are emphasized for design work. They include structure
charts, HIPO and IPO charts, and structured wolkthrough.

34
System Development Life Cycle :- System development revolves around a life cycle
that begins with the recognition of user needs. Following Feasibility study, the key stages
of the cycle are evaluation of the present system, information gathering, cost/benefit
analysis, detailed design, and implementation of the candidate system.

The software requirements analysis (SRA) step of a software development process

yields specifications that are used in software engineering. If the software is
"semiautomated" or user centered, software design may involve user experience design
yielding a story board to help determine those specifications. If the software is
completely automated (meaning no user or user interface), a software design may be as
simple as a flow chart or text describing a planned sequence of events. There are also
semi-standard methods like Unified Modeling Language and Fundamental modeling
concepts. In either case some documentation of the plan is usually the product of the
design.

System design is a process of problem-solving and planning for a software solution.

After the purpose and specifications of software are determined, software developers will
design or employ designers to develop a plan for a solution. It includes low-level
component and algorithm implementation issues as well as the architectural view.

Design methodologies

Design methodologies aim to provide a template process or a framework for the actual
design of a system. They aim to simplify the actual process of designing a system and
aim to enforce some standard design principles which improve the quality of a design.
One of the earlier design methodologies is the Responsibility Driven Design (RDD)
pioneered by Rebecca Wirth et al. It forms the basis of the URDAD, the Use Case,
Responsibility-Driven Analysis and Design method which aims to generate a technology
neutral design which is then mapped onto one's choice of implementation architecture
and technologies.

Design Patterns

A software designer or architect may identify a design problem which has been solved by
others before. A template or pattern describing a solution to a common problem is known
as a design pattern. The reuse of such patterns can speed up the software development
process, having been tested and proved in the past.

35
Usage

System design documentation may be reviewed or presented to allow constraints,

specifications and even requirements to be adjusted prior to programming. Redesign may
occur after review of a programmed simulation or prototype. It is possible to design
software in the process of programming, without a plan or requirement analysis, but for
more complex projects this would not be considered a professional approach. A separate
design prior to programming allows for multidisciplinary designers and Subject Matter
Experts (SMEs) to collaborate with highly-skilled programmers for software that is both
useful and technically sound.

Design considerations

There are many aspects to consider in the design of a piece of software. The importance
of each should reflect the goals the software is trying to achieve. Some of these aspects
are:

• Compatibility - The software is able to operate with other products that are
designed for interoperability with another product. For example, a piece of
software may be backward-compatible with an older version of itself.
• Extensibility - New capabilities can be added to the software without major
changes to the underlying architecture.
• Fault-tolerance - The software is resistant to and able to recover from component
failure.
• Maintainability - The software can be restored to a specified condition within a
specified period of time. For example, antivirus software may include the ability
to periodically receive virus definition updates in order to maintain the software's
effectiveness.
• Marketability - If the software is to be mass marketed, there must be a market for
the software. Research must be conducted to determine the target market and its
needs.
• Modularity - the resulting software comprises well defined, independent
components. That leads to better maintainability. The components could be then
implemented and tested in isolation before being integrated to form a desired
software system. This allows division of work in a software development project.
• Packaging - Printed material such as the box and manuals should match the style
designated for the target market and should enhance usability. All compatibility
information should be visible on the outside of the package. All components
required for use should be included in the package or specified as a requirement
on the outside of the package.
• Reliability - The software is able to perform a required function under stated
conditions for a specified period of time.

36
 • Reusability - the modular components designed should capture the essence of the
functionality expected out of them and no more or less. This single-minded
purpose renders the components reusable wherever there are similar needs in
other designs.
• Robustness - The software is able to operate under stress or tolerate unpredictable
or invalid input. For example, it can be designed with resilience to low memory
conditions.
• Security - The software is able to withstand hostile acts and influences.
• Usability - The software user interface must be intuitive (and often aesthetically
pleasing) to its target user/audience. In many cases, online help should be
included and also carefully designed.

A design document is a written outline of the development of a course or a description

of a software product that a software designer writes in order to give a software
development team an overall guidance of the architecture of the software project.

Instructional designers (used by corporate training entities) create design documents to

articulate how a course will be developed. It generally describes the learning objectives,
the modules, learning assessment methods, and source content.

When the design document is description of a software product, it usually accompanies

an architecture diagram and has pointers to detailed feature specifications of smaller
pieces of the design. Practically, a design document is required to coordinate a large team
under a single vision.

A design document needs to be a stable reference and outline all parts of the software and
how they will work. The document should give a fairly complete description while
maintaining a high-level view of the software.

The Software Design Document (SDD) is a comprehensive software design model

consisting of four distinct but interrelated activities: data design, architectural design,
interface design, and procedural design.

The SDD contains the following documents:

1. Data Design
2. Architecture Design
3. Interface Design
4. Procedural Design

37
1. The Data Design describes structures that reside within the software. Attributes and
relationships between data objects dictate the choice of data structures.

2. The Architecture Design uses information flow characteristics, and maps them into the
program structure. Transformation mapping method is applied to exhibit distinct
boundaries between incoming and outgoing data. The Data Flow diagrams allocate
control input, processing, and output along three separate modules.

3. The Interface Design describes internal and external program interfaces as well as the
design of human interface. Internal and external interface design are based on the
information obtained from the analysis model.

4. The Procedural Design describes structured programming concepts using graphical,

tabular, and textual notations. These design mediums enable the designer to represent
procedural detail that facilitates translation to code. This blueprint for implementation
forms the basis for all subsequent software engineering work.

38
DATA STRUCTURE

Two files have been used in this project:

1. STUDENT.DAT : Keeps record of students.

• admno (Int) : Admission no. is unique field and generated

• name (Character)
• father ( character)
• age (int)
• address (character)
• clas (character)
automatically by the program.
: Name of the student.
: Father’s name.
: Age of the student.
: Address of the student.
: Class of the student.

2. TEACHER.DAT : Keeps record of teachers.

• code (Int) : Code no. of the teacher.

• name (character)
• age (Int)
• designation (character)
• address (character)
• clas (character)
: Name of the teacher.
: Age of the teacher.
: Designation of the teacher.
: Address of the teacher.
: Class teacher of the class.

WORKING OF THE PROJECT

39
• Add Student records: User can add the students records by selecting option 1 from the
main menu.

• Add teacher records: User can add the teacher records by selecting option 2 from the
main menu.

• Modify student records: User can modify the student information by selecting option
1 from the edit menu.

• Deleting student records: User can delete the student records by selecting option 2
from the edit menu.

• Modify teacher records: User can modify the teacher information by selecting option
3 from the edit menu.

• Delete teacher records: User can delete the teacher records by selecting option 4 from
the edit menu.

• Students List: User can view the students list by selecting option 1 from the reports
menu.

• Teachers List: User can view the teachers list by selecting option 2 from the reports
menu.

• Class wise student list: User can view the list of students classwise by selecting
option 3 from the reports menu.

• Student record: User can view the student record by selecting option 1 from the query
menu.

• Teacher record: User can view the teacher record by selecting option 2 from the query
menu.

40
• Class teacher: User can view the class teacher record of the particular class by
selecting option 3 from the query menu.

STRUCTURE OF THE PROGRAM

This program is having 2 classes:

 STUDENT
 TEACHER

Modules in class STUDENT prepared by my co-member:

• addition () : FUNCTION TO ADD NEW RECORD IN

STUDENT FILE
• list () : FUNCTION TO DISPLAY LIST OF ALL THE
STUDENTS
• class_list () : FUNCTION TO DISPLAY CLASS WISE LIST
OF THE STUDENTS
• record () : FUNCTION TO DISPLAY SINGLE RECORD
OF THE STUDENT
• deletion () : FUNCTION TO DELETE STUDENT RECORD
• modification () : FUNCTION TO MODIFY THE STUDENT
RECORD

41
 Modules in class TEACHER prepared by me:

• addition () : FUNCTION TO ADD NEW RECORD IN

TEACHERS FILE
• list () : FUNCTION TO DISPLAY LIST OF ALL THE
TEACHER
• record () : FUNCTION TO DISPLAY SINGLE RECORD
OF TEACHER
• class_teacher () : FUNCTION TO DISPLAY THE CLASS
TEACHER RECORD
• deletion () : FUNCTION TO DELETE THE TEACHER
RECORD
• modification () : FUNCTION TO MODIFY THE TEACHER
RECORD

REPORT GENERATION

1. Students List: User can view the students list..

2. Class wise student list: User can view the list of students class wise.

3. Student record: User can view the student record.

REPORT GENERATION

1. Teachers List: User can view the teachers list..

2. Teacher record: User can view the teacher record.

3. Class teacher: User can view the class teacher record of the particular class.

VALIDATION CHECKS

42
1. Admission no. and teacher code is checked whether exist in the file or not
whenever user input, while adding, delete or modify.

2. Character check : When single character has to be input, like y (yes) or n (no), it
has been checked that user should input correct character..

Testing

Software testing is a critical element of software quality assurance and represents the
ultimate review of specification, design, and coding. The purpose of product testing is to
verify and validate the various work products viz. units, integrated unit, final product to
ensure that they meet their respective requirements.

Testing Objective: -
• Testing is a process of executing a program with the intent of finding an error.
• A good test case is one that has a high probability of finding an as yet
undiscovered error.
• A successful test is one that uncovers an as – yet undiscovered error.

Our objective is to design tests that systematically uncover different classes of errors and
do so with a minimum amount of time and effort.

This process has two parts: -

43
 1. Planning: - This involves writing an reviewing unit, integration, functional,
validation and acceptance test plans.
2. Execution: - This involves executing these test plans, measuring, collecting data
and verifying it if it meet to quality criteria set for it.

The quality of a product or items can be achieved by ensuring that the product meets the
requirement by planning and conducting the following tests at various stages.

Various tests done are as follows: -

Unit Tests at unit level, conducted by development team, to verify individual standalone
units.

Integration tests after two or more product units are integrated conducted by
development team, to test the interface between the integrated units.

Functional testing prior to the release to validation manager, designed and conducted by
the team independent of designers and coders, to ensure the functionality provided
against the customer requirement specifications.

Acceptance Testing prior to the release to validation manager, conducted by the

development team, if any supplied by the customers.

Validation Testing prior to release to customer, conducted by the validation team to

validate the product against the customer requirement specifications and user
documentation.

TEST CASE DESIGN

44
Test case design focuses on a set of techniques for the creation of test cases that meet
overall testing objectives. In test case design phase, the engineer creates a series of test
cases that are intended to “demolish” the software that has been built.

Any software product can be tested in one of two ways: -

1. Knowing the specific function that a product has been designed to perform, tests
can be conducted that demonstrate each function is fully operational, at the same
time searching for errors in each function. This approach is known as black box
testing.
2. Knowing the internal workings of a product, tests can be conducted to ensure that
internal components have been adequately exercised. This approach is known as
white box testing.

Black box testing is designed to uncover errors. They are used to demonstrate that
software functions are operational; that input is properly accepted and output is correctly
produced; and that integrity of external information is maintained (e.g. data files). A
black box examines some fundamental aspects of a system with little regard for the
internal logical structure of the software.

White box testing of software is predicated on close examination of procedural details.

Providing a test case that exercise specific sets of conditions and / or loops tests logical
paths through the software. The “State of the program” may be examined at various
points to determine if the expected or asserted status corresponding to the actual status.

45
In our project, we had used black box testing because it will satisfy the requirement to
test all the functional requirements of the project. It is used to uncover different classes of
errors in the following categories: -

1. Incorrect or missing functions

2. Interface errors
3. Errors in data structures
4. Performance errors
5. Initialization and termination errors

TESTING IMPLEMENTATION

Execute test plans (Generate test reports)

After preparation of test cases and after making appropriate changes in the code we
execute the test cases. Execution of test plans is done in accordance with project
management plan. Test acceptance criteria for the functional tests in measurable terms
are specified in customer requirement specifications. Say not more than x number of
problems of severity code A and y number of problems of severity code b for acceptance
of the product under the test.
After running our test cases we run the test cases given by the company for the validation
of the product.

46
 3.3.1 Project Interface

A user, interface consisting of the set of dials, knobs, operating system commands,
graphical display formats, and other devices provided by a computer or a program to
allow the user to communicate and use the computer or program. A graphical user
interface) (GUI) provides its user a more or less "picture-oriented" way to interact with
technology. A GUI is usually a more satisfying or user-friendly interface to a computer.

User Interface Toolkit (UIT) was a C++-language, object-oriented layer on top of the
XView graphical toolkit. It was originally developed by the Sun Microsystems
employees, Mark Soloway (left Sun in 1993) and Joe Warzecha (still an employee of
Sun), as an internal tools project for Sun's Computer Integrated Manufacturing
organization in 1990. In 1991, Mark Soloway got permission from Sun to contribute the
UIT to the MIT X 11 distributions. Mark Soloway continued development on the UIT,
subsequently creating and releasing UITV2 in 1992.The source code is freely available.

The software is developed in c++ and found it better to work with TURBO C++ & its
FILES facility as database storage. It is quite difficult to maintain Database in Turbo C++
instead the availability of static. having unique capability of handling large database in
efficient manner. So, structural data is used in this project.

47
In it we have used waterfall model. This model has 5 phases. The phases always occur in
a following order:

1. requirement analysis & specification

2. design
3. implementation & unit testing
4. integration & system testing
5. operation & maintenance

The developer must complete each phase before the next phase begins. This model is
easy to understand and reinforces the information of “define before design” and “design
before code”.
We use this model to make:
• the requirements are easily understandable and defined
• by which we can define requirements early in the cycle
• less experience on tools to be used
• limited users have participation funding is stable for the project

As a verb, to interface means to communicate with another person or object. With

hardware equipment, to interface means making an appropriate physical connection so
that two pieces of equipment can communicate or work together effectively.

48
School Administration Project Interfaces

49
50
51
52
 Chapter 4

Conclusions and Future Perspective

To conclude this project helps in maintaining the record of the employees in any
organization. The project may be applied in any situation for which pre-specified set
of procedural steps has been defined. The efficiency and arithmetical accuracy of the
system is increased and hence fewer errors will occur. The project handles the records
of number of employees and their pay slip record and works up to the mark as
required by user. Objective of developing this software is to automate computerize
the daily working of a school department, so that transactions become fast and error
free. It replaces all the paper work. It keeps records of students and teacher, and
produces the desired report whenever required. As the person operating the school
administration software had to spend days in the hassles that come bundled with this
software. He had to handle and maintain bulky registers, all calculations were done
manually, it was very difficult to find a particular record or file, it was very difficult
to maintain bulky registers and resulted in the loss of information and it was difficult
to produce and maintain accurate results.

53
The following enhancements are to be done into the project in near
future:-

Database connectivity can be done with ACCESS or ORACLE.

The software is currently being made for LAN based systems.
WAN support will be included.
Customized versions will be provided to various schools on demand.

54
 APPENDIX

C++ as a Platform

• Real software runs on computers. It is a sequence of ones and zeros that is stored
on some magnetic media. It is not a program listing in C++ (or any other
programming language).
• A program listing is a document that represents a software design. Compilers and
linkers actually build software designs.
• Real software is incredibly cheap to build, and getting cheaper all the time as
computers get faster.
• Real software is incredibly expensive to design. This is true because software is
incredibly complex and because practically all the steps of a software project are
part of the design process.
• Programming is a design activity -- a good software design process recognizes
this and does not hesitate to code when coding makes sense.
• Coding actually makes sense more often than believed. Often the process of
rendering the design in code will reveal oversights and the need for additional
design effort. The earlier this occurs, the better the design will be.
• Since software is so cheap to build, formal engineering validation methods are not
of much use in real world software development. It is easier and cheaper to just
build the design and test it than to try to prove it.
• Testing and debugging are design activities -- they are the software equivalent of
the design validation and refinement processes of other engineering disciplines. A
good software design process recognizes this and does not try to short change the
steps.
• There are other design activities -- call them top level design, module design,
structural design, architectural design, or whatever. A good software design
process recognizes this and deliberately includes the steps.
• All design activities interact. A good software design process recognizes this and
allows the design to change, sometimes radically, as various design steps reveal
the need.
• Many different software design notations are potentially useful -- as auxiliary
documentation and as tools to help facilitate the design process. They are not a
software design.
• Software development is still more a craft than an engineering discipline. This is
primarily because of a lack of rigor in the critical processes of validating and
improving a design.
• Ultimately, real advances in software development depend upon advances in
programming techniques, which in turn mean advances in programming
languages. C++ is such an advance. It has exploded in popularity because it is a
mainstream programming language that directly supports better software design.
• C++ is a step in the right direction, but still more advances are needed.

55
 Bibliography

1. A.K.Sharma; Introduction to C++

2. Sumita Arora; C++ for Class 12th

3. Yashwant Kanetkar; Working with C++

4. Elias M.Awad;Galgotia Publications Pvt. Ltd; System Analysis and Design,

Second Edition

5. http://en.wikipedia.org

56