Professional Documents
Culture Documents
Sachin Training2
Sachin Training2
Introduction
1
Synopsis school administration
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.
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.
Module 2:
Modification of information,involves :
3
Module 3:
4
Company Profile
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
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
1.1.2. services
1. Software Solutions
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
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.
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 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 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).
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
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
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.
Polymorphism
Polymorphism enables one common interface for many implementations, and for objects
to act differently under different circumstances.
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.
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.
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.
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.
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
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".
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.
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:
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:
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.
Very Less Time Consuming:- very faster to use and work with.
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
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.
Any coherent and reasonable project must have requirements that define what the project
is ultimately supposed to do.
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.
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.
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:
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
Functional Requirements
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.
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.
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.
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:
SOFTWARE:
32
3.2 Feasibility Study
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.
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:-
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.
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
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 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.
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.
38
DATA STRUCTURE
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.
STUDENT
TEACHER
41
Modules in class TEACHER prepared by me:
REPORT GENERATION
2. Class wise student list: User can view the list of students class wise.
REPORT GENERATION
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.
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.
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.
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.
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.
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: -
TESTING IMPLEMENTATION
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:
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
48
School Administration Project Interfaces
49
50
51
52
Chapter 4
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:-
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
5. http://en.wikipedia.org
56