ERP on School Management System

ERP (Enterprise Resource Planning)
Page-I
PREFACE
The main objective of any computer science student is to get as much of practical
knowledge as possible. Being an able to have a practical knowledge by developing a
project is a lifetime experience. As practical knowledge is as important as theoretical
knowledge we are thankful of having a project.
Through the development of the project we had a great experience of various
strategies that can be applied in development of project. This project is the stepping
stone for our carrier.
We are pleased to present this project. Proper care has been taken while organizing
the project so that it is to comprehend. Also, various software engineering concepts
have been implemented.

Page-II
ACKNOWLEDGEMENT
I would like to extend our heartiest thanks with a deep sense of gratitude and respect
to all those who provides me immense help and guidance during my training period.
I would like to thank my Project guide Mr. Shailesh Gohil for providing a vision
about the system. I have been greatly benefited from their regular critical reviews and
inspiration throughout my work.
I would like to express my sincere thanks to our Head of Department. Prof. V. A.
Gandhi and my internal guide Prof. Milan Vachhani who gave me an opportunity to
undertake such a great challenging and innovative work. I am grateful to them for
their guidance, encouragement, understanding and insightful support in the
development process.
I am also thankful to entire staff of Tops Technologies for their constant
encouragement, suggestions and moral support throughout the duration of my project.
Last but not the least I would like to mention here that I am greatly indebted to each
and everybody who has been associated with my project at any stage but whose name
does not find a place in this acknowledgement.
Gandhi Amitkumar K
Branch: MCA
Enroll No. : 115030693037

Page-III
Table of Contents
Project Abstract .........................................................................................................................1
Company Profile.........................................................................................................................3
1. Introduction ...........................................................................................................................5
1.1 Project Summary..............................................................................................................5
1.2 Purpose ............................................................................................................................7
1.3 Scope................................................................................................................................7
1.4 Objective..........................................................................................................................7
2. Project Management .............................................................................................................9
Feasibility Study .....................................................................................................................9
2.1.1 Technical Feasibility ..................................................................................................9
2.1.2 Implementation Feasibility .......................................................................................9
2.1.3 Operational Feasibility............................................................................................10
2.2. Project Planning............................................................................................................10
2.2.1 Project Development Approach .................................................................................11
2.2.2 Project Plan.............................................................................................................12
2.2.3 Schedule Representation........................................................................................13
2.3. Risk Management .........................................................................................................15
2.3.1 Risk Identification....................................................................................................15
2.3.2 Risk Analysis............................................................................................................17
3.2 Constraints.....................................................................................................................20
3.2.1 Regulatory Policies..................................................................................................20
3.2.2 Reliability Requirements.........................................................................................20
3.2.3 Criticality of the Application ...................................................................................20
3.2.4 Safety and Security Considerations ........................................................................21
4. System Analysis....................................................................................................................22
4.1 Study of the Current System..........................................................................................22
4.2 Problems and Weakness of Current System..................................................................22
4.3 Requirement of New System .........................................................................................23
4.4 Feasibility Study .............................................................................................................23
4.4.1 Operational Feasibility:...........................................................................................23
4.4.2 Technical Feasibility:...............................................................................................24
4.4.3 Economical Feasibility:............................................................................................24

Page-IV
4.4.4 Implementation Feasibility: ....................................................................................24
4.5.5 Requirements Validation ............................................................................................24
4.6 Use Case Diagram ..........................................................................................................26
5. System Design......................................................................................................................31
5.1 System Architecture.......................................................................................................31
5.1.1 Class Diagram..........................................................................................................31
5.1.2 Activity Diagram:.........................................................................................................32
5.1.3 Activity Diagram:.....................................................................................................33
5.1.4 Sequence Diagram:.................................................................................................34
5.2 Database Design.................................................................................................................35
5.2.1 Data Dictionary ...........................................................................................................35
6. User Manual.........................................................................................................................42
7. Testing..................................................................................................................................79
7.1TESTING PLAN.................................................................................................................79
7.2 The Testing Process........................................................................................................80
7.2.1 Requirement Traceability............................................................................................80
7.2.2 Testing Schedule .....................................................................................................80
7.3 TESTING STRATEGY ........................................................................................................80
7.3.1 White Box Testing...................................................................................................81
7.3.2 Black Box Testing ....................................................................................................84
7.3.3 Unit Testing.............................................................................................................86
7.3.4 Integration Testing..................................................................................................89
7.3.5 Validation Testing ...................................................................................................91
8. LIMITATIONS AND FUTURE ENHANCEMENTS .....................................................................93
8.1 Limitations......................................................................................................................93
8.2 Future Enhancements....................................................................................................93
9 Conclusion.............................................................................................................................94
10 Reference............................................................................................................................95

Page-V
List of figure
Figure 1 Iterative and Incremental Life Cycle ..........................................................................11
Figure 2 Work breakdown structure of ERP System................................................................14
Figure 3 Activity Network representation of ERP System .......................................................14
Figure 4 : Gantt chart...............................................................................................................15
Figure 5 Use case Diagram of ERP...........................................................................................26
Figure 6 Login Use Case ..........................................................................................................27
Figure 7 calculate marks use case............................................................................................28
Figure 8Managing Test.............................................................................................................29
Figure 9 Appearing Test...........................................................................................................30
Figure 10 Class Diagram...........................................................................................................31
Figure 11 Student Activity Diagram .........................................................................................32
Figure 12 Faculty Activity Diagram ..........................................................................................33
Figure 13 Sequence Diagram ...................................................................................................34
Figure 14 Login page................................................................................................................42
Figure 15 Forgot password page..............................................................................................43
Figure 16 Conformation page ..................................................................................................44
Figure 17 Change password page ............................................................................................45
Figure 18 Student Home Page ................................................................................................46
Figure 19 Student profile page ................................................................................................47
Figure 20 Course Information page .........................................................................................48
Figure 21 Lecture Attendance page........................................................................................50
Figure 22 Exam Detail page.....................................................................................................51
Figure 23 Assignment Download page ....................................................................................53
Figure 24 Download Document Page......................................................................................55
Figure 25 Selecting exam paper page......................................................................................57
Figure 26 Exam page................................................................................................................58
Figure 27 Online Exam page ...................................................................................................59
Figure 28 Online Exam Page ....................................................................................................60
Figure 29 Suggestion page.......................................................................................................61
Figure 30 Logout page.............................................................................................................62
Figure 31 Faculty Home page ..................................................................................................63
Figure 32 Faculty Lecture Flow page.......................................................................................64
Figure 33 Assignment page......................................................................................................65
Figure 34 Faculty Batch page...................................................................................................66
Figure 35 Faculty Search page .................................................................................................67
Figure 36 Faculty Search Result page .....................................................................................68
Figure 37 Faculty Reporting page ............................................................................................69
Figure 38 Faculty Reporting Page ............................................................................................70
Figure 39 Faculty Reporting Page ............................................................................................71
Figure 40 Admin Home page ...................................................................................................72
Figure 41 Admin New Faculty page .........................................................................................73
Figure 42 Admin View, Update, Remove Faculty page............................................................74

Page-VI
Figure 43 Admin New Student page ........................................................................................75
Figure 44 Admin View, Update, Remove page ........................................................................76
Figure 45 Insert new paper page ............................................................................................77
Figure 46 New Questions page ...............................................................................................78
Figure 47 Testing Step..............................................................................................................79

Page-VII
List of table
Table: 1 Roles and Responsibilities..........................................................................................13
Table 2 Student Table ..............................................................................................................36
Table 3 Faculty Table ...............................................................................................................37
Table 4 Course Table................................................................................................................37
Table 5 Batch Table..................................................................................................................38
Table 6 Attendance Table ........................................................................................................38
Table 7 Suggestion Table .........................................................................................................38
Table 8 Question Table ............................................................................................................39
Table 9 Options Table ..............................................................................................................39
Table 10 Correct Option Table.................................................................................................39
Table 11 Exam Table ................................................................................................................40
Table 12 Result Table...............................................................................................................40
Table 13 Research Table ..........................................................................................................40
Table 14 Admin Table ..............................................................................................................41
Table 15 Global note................................................................................................................41

Page-VIII
NOTATIONS:
 Class Diagram: -
Class:
Class Name
Attribute: Type
+Operation (arglist):return type
Abstract Class:
Class Name
{abstract}
Composition: Generalization:
Usage: Association:
1
*
«uses»

Page-IX
 Sequence Diagram:
Object and Lifeline: Activation:
Message: Message (call): Message (return):
 Use Case Diagram:
Actor Use Case:

Page-1
Project Abstract
The main objective behind the ERP (Enterprise resource planning) is creating a
central system while in traditional approach is to do a manual work in paper. So for
that it’s very difficult to manage all the record and also difficult to analyze all the
record in any departments. A manual work are to lengthy and its very time
consuming for the entire department. So for that needs of central system is arising
which gives the effective and efficient result within a few time. All departments can
access the data with the system and also they can perform a desire task. With that
all the data can easily manipulate and get easily whenever anybody wants.
With an ERP system in place, people in different departments can view the same
information about Student Information, making sure that every single interaction
with student is based on accurate information. It also means that manual processes
can be automated to free up people’s time and make internal processes more
efficient. It’s all about to how to manage the student record in a master file as well
as how admin and faculty can manage the profile and keep information about the
student. All the information regarding student can see and edit if necessary apart
from that faculty can keep record of student and they can manage information like
student profile, exam, reporting or other information.
ERP function involves:
 Manage new admissions
 Manage courses
 Student Basic Information
 Manage faculty
 Exam scheduling
 Result management
 Declaration global notes

Page-2
 Manage attendance
 Manage batches
 Report generation
The Admin role can be as follow:
 Add/Modify faculty
 Add/Modify student
 Add/Modify batches
 Attendance
 Search student(course, progress, batch, , basic information)
 Search faculty(course, batch, basic information)
 Reports
The faculty role can be as follow:
 Manage task(upcoming event, lecture flow, assignment, self assessment)
 Search student(course, batch student status, progress)
 Reporting(student information, daily report)
The student role can be as follow:
 Viewing profile
 Assessment(exam detail, assignment, lecture flow)
 Supporting document
 Suggestion

Page-3
Company Profile
TOPS Technologies is one of the largest IT Training, Outsourcing and Placement
Service provider. TOPS offer a wide array of solutions customized for a range of key
verticals and horizontals in the IT industry, through our multiple offices located in
Ahmedabad, Vadodara, Rajkot, Surat, Navsari, Mehsana, Junagadh, Indore, Bhopal,
Jabalpur, Noida, Kota, Jaipur, Nagpur, Dehradun in India and sales offices in
Chicago, IL and Mountain View, CA in USA.
TRAINING:
Started with a vision of bridging the gap between skills required and talent created by
colleges, today TOPS Technologies is one of the largest IT Training and Finishing
Schools with expertise in ASP.Net Training, PHP Training, Java Training, iPhone
Training, Android Training, Software Testing Training, SEO Training, Web Design
Training. Today we have Software Development training centers in Ahmadabad,
Vadodara, Rajkot, Surat, Navsari, Mehsana, Junagadh, Indore, Bhopal, Jabalpur,
Noida, Kota, Jaipur, Nagpur, and Dehradun. As one of the largest Software
Development Company in Gujarat we have also been accorded the Microsoft Silver
Learning Partnership by Microsoft Corporation.
OUTSOURCING:
At TOPS Technologies we don’t like to be termed as just an Outsourcing company;
we believe in becoming your solutions partner. Our approach of “You think it, we
build it” gives us the perfect mantra for the work we do. Our implementations have
benefited organizations in creating the best solutions along with major cost savings.
Today we have a team of 100+ developers with varied expertise in creating some of
the best web/mobile applications in the market. All our effort revolves around the

Page-4
business goals of our clients and this helps to bring the Unique Selling Point of the
product to the end customer.
PLACEMENT:
TOPS Technologies specializes in providing placements to students for all software
languages & international certifications. With our flagship courses, TOPS Certified
and TOPS Professional we have managed to garner the largest market presence in the
state’s competitive IT training market and have given a platform for professionals to
create the career they dreamt about.
We have partnered with more than 1000 software companies across Gujarat and India
for placements. Our team works with each software company on a personal level to
understand their requirements and provide them with required talent.
Our management team has 15+ years of work experience working for companies JP
Morgan, Verizon Wireless, Capegemini, US Cellular in different verticals ranging
from banking solutions to health care industry to mobile applications.

Page-5
1. Introduction
1.1 Project Summary
ERP is a System that manages the records of student regarding admission, courses,
examination part, and exam result summary for particular student and also other
facilities to provide generating reports for faculty.
The system is designed to help for keeping data, storing, manipulating data and
analysing the data. Extensive information is available at your fingertips through this
System. Viewing student data, managing student information and category and for
examination, courses management, scheduling exam, result and related issues are
made simple and easy. There are custom search capabilities to aid in finding student
information and working on student records. This can make the system easier to
navigate and to use maximizing the effectiveness of time and other resources. ERP
allows the keeping of personnel data in a form that can be easily accessed and
analyzed in a consistent way.
Each of modules in ERP is covering many other student aspects from application to
retirement. The system records basic personal information, admission information,
courses information regarding student. Leading edge systems provide the ability to
"read" applications and enter relevant data to applicable database fields, notify student
and provide result.
ERP function involves:
 Manage new admissions
 Manage courses
 Student Basic Information
 Manage faculty
 Exam scheduling
 Result management
 Declaration global notes
 Manage attendance
 Manage batches

Page-6
 Report generation
In ERP, every user has a Login ID and Password. Also all the users have different
permission rights to access the applications. These rights are Dynamic and can be
changed.
There are three main roles in the system. Admin, Faculty and Student. Admin has
complete access to the whole system, while faculty is concerned with courses, check
their tasks, checking examination results for the student. Students role are responsible
for the use of the system.
The Admin role can be as follow:
 Add/Modify faculty
 Add/Modify student
 Add/Modify batches
 Attendance
 Search student(course, progress, batch, , basic information)
 Search faculty(course, batch, total leave, basic information)
 Reports
The faculty role can be as follow:
 Manage task(upcoming event, lecture flow, assignment, self assessment)
 Search student(course, batch student status, progress)
 Reporting(student information, daily report)
The student role can be as follow:
 Viewing profile
 Assessment(exam detail, assignment, lecture flow)
 Supporting document
 Suggestion

Page-7
1.2 Purpose
The project is about to handle all the information of the student regarding course and
examination. Also it manages resources which were managed and handled by
manpower previously. The main purpose of the project is to integrate distinct sections
of the organization into consistent manner so that complex functions can be handled
smoothly by any technical or non-technical persons.
The project aims at the following matters:
 To manage information of student, faculty and courses.
 Consistently update information of all the students.
 Reports.
 Assistance in decision-making.
1.3 Scope
 Different people, place from different departments can view the same
information about Student Information.
 To enable the head and technical supporting group to access the system from
anywhere.
 To enable the Student to view as well as raise suggestion from anywhere.
 To enable the student evolution with giving online exam and get the result on
the spot.
1.4 Objective
 View the all the record of the student and faculty.
 Student can interact with his basic profile which includes course details,
personal detail.
 Student can download the appropriate document in the supporting document.
 Student can give the online exam and get the result on the spot time.

Page-8
 Give the suggestion or complain to the administrator.
 Faculty can get the information about the student, his batches.
 To enable to send a daily report to the administrator.
 Faculty get perform the online assessment of student.
 Keep the information about the student.
 Administrator can add/modify to the student as well as faculty.
 Also can manage the batches and course for particular student.
 Admin can set the exam paper, and many other tasks

Page-9
2. Project Management
Feasibility Study
The aim of the feasibility study activity is to determine whether it would be
financially and technically feasible to develop the system or not. A feasibility study is
carried out from following different aspects:
2.1.1 Technical Feasibility
Technical feasibility corresponds to determination of whether it is technically feasible
to develop the software. It refers to the ability of the process to take advantage of the
current state of the technology in pursuing further improvement. The technical
capability of the available technology should be considered.
The following technical feasibility areas were probed during the feasibility study
phase:
 The necessary technology i.e. front-end development tools, back-end database
technology for developing the system are already available within the
organization.
 The front-end tool proposed in easily compatible with the current hardware
configuration in the organization.
 The back-end tool proposed has the capacity to hold the data required for
using the new system.
 The System is expandable in many dimensions with respect to addition of
more functionality, featured, etc.
 The front-end and back-end technologies provide a way to preserve the
accuracy, reliability and ease of access and data security.
2.1.2 Implementation Feasibility
This project can easily be made available online without much consideration of the
hardware and software. The only required thing at the applicant’s side is the Internet
connection and a web browser, which are a no difficult issue these days. A database

Page-10
server and application server are required to set up at the admin side. After setting up
the project online, even the administrator can access the system from anywhere.
2.1.3 Operational Feasibility
The system has been developed for any user who wants to use this system. I have
given a demo of my project and the users found the system friendly and easy to use.
The interoperability with the existing system is also checked. So they may face certain
problems in using the user interface. So keeping this consideration in mind we have
provided field for each and every field on the forms. The administrator also may be
non-technical, so the user interface is designed in such a way that it gets comfortable
for the non-technical person to operate easily.
2.2. Project Planning
Project planning is part of project management, which relates to the use of schedules
such as Gantt charts to plan and subsequently report progress within the project
environment. Initially, the project scope is defined and the appropriate methods for
completing the project are determined.
Following this step, the durations for the various tasks necessary to complete the work
are listed and grouped into a work breakdown structure. The logical dependencies
between tasks are defined using an activity diagram that enables identification of the
activity. At this stage, the project plan may be optimized to achieve the appropriate
balance between resource usage and project duration to comply with the project
objectives. Once established and agreed, the plan becomes what is known as the
baseline.
Progress will be measured against the baseline throughout the life of the project.
Analyzing progress compared to the baseline is known as earned value management

Page-11
2.2.1 Project Development Approach
We have used Iterative and Incremental Development model (IID) for our project
development. This development approach is also referred to as Iterative Waterfall
Development approach. Iterative and Incremental Development is a software
development process developed in response to the more traditional waterfall model.
Life Cycle:
Figure 1 Iterative and Incremental Life Cycle
The basic idea behind iterative enhancement is to develop a software system
incrementally, allowing the developer to take advantage of what was being learned
during the development of earlier, incremental, deliverable versions of the system.
Learning comes from both the development and use of the system, where possible.
Key steps in the process were to start with a simple implementation of a subset of the
software requirements and iteratively enhance the evolving sequence of versions until
the full system is implemented.
At each iteration, the procedure itself consists of the Initialization step, the Iteration
step, and the Project Control List. The initialization step creates a base version of the
system. The goal for this initial implementation is to create a product to which the
user can react. It should offer a sampling of the key aspects of the problem and
provide a solution that is simple enough to understand and implement easily. To guide

Page-12
the iteration process, a project control list is created that contains a record of all tasks
that need to be performed. It includes such items as new features to be implemented
and areas of redesign of the existing solution. The control list is constantly being
revised as a result of the analysis phase.
The iteration involves the redesign and implementation of a task from project control
list, and the analysis of the current version of the system. The goal for the design and
implementation of any iteration is to be simple, straightforward, and modular,
supporting redesign at that stage or as a task added to the project control list. It
involves analysis of the structure, modularity, usability, reliability, efficiency, and
achievement of goals. The project control list is modified in light of the analysis
results.
During the implementation of the project by this approach, a step called V&V i.e.
Verification and Validation is carried out at certain intervals.
 Verification: “Are we building the product right?”
 Validation: “Are we building the right product?”
2.2.2 Project Plan
Once we examine that the project is feasible, we undertake project planning. The table
below describes how we planned our project.
Roles and Responsibilities
Role Responsibility Team/Member
Project Guide Defining scope Mr. Shailesh Gohil
Providing required resources
Project planning, tracking and
monitoring.
Analysis and Effort Estimation.

Page-13
Coordination between project teams.
Project
Developer
Designing & Documentation Self
Execution project as per defined
schedule.
Reporting to PL
Testing & QA/QC
Software development as per the design
and Documentation
Table: 1 Roles and Responsibilities
2.2.3 Schedule Representation
Scheduling the project tasks is an important project planning activity. It involves
deciding which tasks would be taken up when. In order to schedule the project
activities, a software project guide needs to do the following:
 Identify all the tasks needed to complete the project.
 Break down large tasks into small activities.
 Determine the dependencies among different activities.
 Allocate resources to activities.
 Plan the starting and ending dates for various activities.
 Determine the critical path. A critical path is the chain of activities that determines the
duration of the project.

Page-14
Work Breakdown Structure
Figure 2 Work breakdown structure of ERP System
Figure 3 Activity Network representation of ERP System
ERP System
Requirement Specification Design Code Test Document
Database
part
Graphical user
interface part
Database
part
Graphical
user
interface
part
Specification
Design
database part
Integrate and test
Code database
part
Write user
manual
Finish
Code GUI partDesign
GUI part

Page-15
Gantt chart
ID Task Name Start Finish Duration
Jan 2014 Feb 2014 Mar 2014 Apr 2014 May 2014
19-1 26-1 2-2 9-2 16-2 23-2 2-3 9-3 16-3 23-3 30-3 6-4 13-4 20-4 27-4 4-5
1 6d22-01-201415-01-2014
System Analysis and Problem
definition
2 7d31-01-201423-01-2014Hardware and software requirements
3 7d11-02-201403-02-2014Requirement Gathering
4 7d21-02-201413-02-2014System Design ( UML Diagram )
5 15d14-03-201424-02-2014System Design ( GUI Design)
6 35d02-05-201417-03-2014Coding
7 5d09-05-201405-05-2014Testing
8 4d15-05-201412-05-2014
Final Documentation and presentation
of project report
Figure 4 : Gantt chart
2.3. Risk Management
Software Risk Management is a proactive approach for minimizing the uncertainty
and potential loss associated with a project. Some categories of risk include product
size, business impact, customer-related, process, technology, development
environment, staffing (size and experience), schedule, and cost. Risk Management is a
practice with processes, methods, and tools for managing risks in a project. It provides
a disciplined environment for proactive decision making to
 Assess continuously what could go wrong (risks)
 Determine which risks are important to deal with
 Implement strategies to deal with those risks
2.3.1 Risk Identification
Risk identification is a systematic attempt to specify threats to the project plan. By
identifying known and predictable risks, we can take a first step toward avoiding them
when possible and controlling them when necessary. To perform the risk
identification, we categorized the risk into different categories as:

Page-16
A. Project Risk
B. Technical Risk
C. Business Risk
D. Known Risk
E. Predictable Risk
F. Unpredictable Risk
A. Project Risk:
The Project Risk threatens the project plan. The project risks here are:
 Schedule slippage.
 Incomplete requirement specification.
 Change in user Requirements.
 Non-availability of required resources.
 Lack of communication with end user.
 Improper vision about the project.
 Staffing and organization problems.
 Non-technical customer with high technical expectations.
B. Technical Risk:
The Technical Risk threatens the quality and timeliness of the software to be
produced. If the technical risk becomes a reality, implementation may become
difficult or impossible. The technical risks identified in our project are:
 Unavailable library files.
 Problem in connection to database server.
 Problem in application server.
 Problem in browser view.

Page-17
C. Business Risk:
The Business Risk threatens the viability of the software to be built.
 Project not delivered on time.
 Switching of database structure.
D. Predictable Risk:
The Predictable risks are extrapolated from past project experience. Since we have not
done any live industry project during the academic years, the predictable risks were
very few. The predictable risk include mainly:
 Language error predictions.
 Lack of End user support in future project enhancement.
E. Unpredictable Risk
The Unpredictable risks are the joker in the deck. They can and do occur, but they are
extremely difficult to identify in advance.
2.3.2 Risk Analysis
Each identified risk is considered and the effect and probability of each risk is
identified during risk analysis.
a. Risk Planning
Risk planning lists the checkpoints that are made continually to find out situation where the
risk can becomes reality.
 Plan entire schedule on paper in the beginning and follow it.
 Understand the scope from external guide to have the correct design.
 Find out proper documentation, manuals and guides from the person having the
required knowledge.
 Schedule should not be delayed too much.

Page-18
 Take backups regularly.
 Perform thorough requirement gathering and analysis. Confirm the collected
requirements with the guide.

Page-19
33.. SSyysstteemm RReeqquuiirreemmeenntt SSttuuddyy
Administrator:
The administrator has all the rights to access the system. He is the one who has all
rights to view the applicant details, modify those details. The administrator also keeps
a track of the file status of the applicants.
Student:
Student is the one who wish to visit ERP website. The student can show in his own
details. The Student has rights to interaction with the ERP system with giving the
online examination as well as student can show the result. Student can see his
absenteeism as well as they have to right to collect document. Student can check the
remainder if found.
Faculty:
Faculty can show the responsible task provided by the administrator. He can view his
lecture flow and other related task. Faculty can assess the exam paper and also can
check the paper. He can generate his daily report to the administrator and full fill the
attendance of student. Apart from that he can see his batch with its progress and
evaluate of student progress. Faculty can also sending the global note to his desired
student.
33..11 HHaarrddwwaarree RReeqquuiirreemmeenntt SSttuuddyy
Development
technologies
Jsp-servlet, mysql, JavaScript, XML
Development tools Eclipse IDE
Application server Apache tomcat 7.0
Database MySQL
Operating system Windows 7
Web browser Google chrome, Mozilla Firefox
Hardware P-IV or +, 1 GB RAM, 80 GB HDD

Page-20
3.2 Constraints
3.2.1 Regulatory Policies
 The length of the project is 4 months which a limited amount of time.
 The project developers are beginners and will take time to understand about the
technology.
 The users of the system are any registered applicants to apply for membership in
HMIS, authorized administrator and non-registered users can also used interface
pages.
3.2.2 Reliability Requirements
 The system should be reliable enough so that the data found in the database
system is consistent at any point.
 The system should be able to handle loads of requests from different users
around the world at the same time.
3.2.3 Criticality of the Application
 The system is a web-based application and so fails to work if there is no Internet
connection. The system might not work if the Internet connection slows down.
 The system stops working in case if the database server or the application server
stops working.
 The system might give erroneous output if it fails to connect to the database
server.

Page-21
3.2.4 Safety and Security Considerations
 The Intranet password security
 Each applicant is given a login account through which he can view his own
information and also modify and save it. He has the rights to access only his
own information.
 The administrator has rights through which he can access and manage whole
system.

Page-22
4. System Analysis
4.1 Study of the Current System
The current ERP System deals with maintaining a physical contact with the academy
management dept. for filling all the details and the documentation work. The
management doesn’t needs to visit the academy management dept. and collect the
assignment and submitting his/her documents directly.
According to the current system, the management has to fill in the forms manually, go
to the account management dept., and submit him the form. The applicant needs to
visit the academy portal now and then in order to get his work accomplished. The
admin also has to manage all the users. He needs to maintain records of all the users,
their activity status, submission methods and installation details on paper. The Manual
process is more error prone and also slow. Moreover Students in the academy can
interface his/her work area only. But if an online application is available then they can
communicate whole system. Thus a simulation of this entire process can be a boon to
the applicants as well as the admin.
4.2 Problems and Weakness of Current System
 The present system has certain major disadvantages. A few to be listed can be
excessive paperwork, time consuming process flow, laborious work
environment for employees, difficulty to access historical data and all these
problems lead to inefficient working of government sector causing
dissatisfaction in the general public.
 Apart from the above stated problems there is lack of transparency in the
existing system. This being one of the major drawbacks in the system needs
special attention.
 The problem stated above have certain deep rooted problems like time
consuming process flow for which may need to change the structure of the
process flow in certain cases so that the system output can become faster.

Page-23
 The following listed are the problems or weaknesses of the current system:
 So much time consume in preparing registers which is having replicated data
 It is difficult to prepare report for decision making.
 Attendance related module is not there.
 Reporting and appraisal of the performance are not there.
4.3 Requirement of New System
 Registration details of the applicant.
 Login details of the applicant.
 Personal details of the applicant.
 Information of all the members of the applicant’s group.
 Educational and employment information
 All information and rules regarding the e-forms must follow.
 Certain legal details of the Student and Faculty.
 Answers to the questionnaire for exam.
 Communication with whole system.
4.4 Feasibility Study
The aim of the feasibility study activity is to determine whether it would be
financially and technically feasible to develop the system or not. A feasibility study is
carried out from following different aspects:
4.4.1 Operational Feasibility:
The system has been developed for any user who wants to use this system. We have
given a demo of our project and the users found the system friendly and easy to use.
The interoperability with the existing system is also checked after uploading the
website. So they may face certain problems in using the user interface. So keeping
this consideration in mind we have provided field for each and every field on the

Page-24
forms. The administrator also may be non-technical, so the user interface is designed
in such a way that it gets comfortable for the non-technical person to operate easily.
4.4.2 Technical Feasibility:
It determines if the system can be implemented using the current technology. This
system has been developed using jsp-servlet as front end and MySQL Server as
backend.
4.4.3 Economical Feasibility:
The company being a well-to-do company didn’t have any problem in buying any
software that was required in developing the application. The software’s we used
were readily available. So as such we didn’t face any economical constrains.
4.4.4 Implementation Feasibility:
This project can easily be made available online without much consideration of the
hardware and software. The only required thing at the applicant’s side is the Internet
connection and a web browser, which are a no difficult issue these days. A database
server and application server are required to set up at the admin side. After setting up
the project online, even the administrator can access the system from anywhere.
4.5.5 Requirements Validation
Requirement Validation examines the specification to ensure that all system
requirements have been stated unambiguously; those inconsistencies, errors have been
detected and corrected and the work products conform to the standard.
 Source of the requirements are identified. Final statement of requirement has
been examined by original source.
 Requirements related to main requirements are found.
 Requirements are testable.
 Requirements are clearly stated and are not misinterpreted.

Page-25
 All sources of requirements are covered to get maximum requirement.
 All methods of finding requirements are applied.
 Requirements are not duplicated and each of them gives distinct idea of
processes within project.
 Requirement associated with system performance, behavioural and operational
characteristics are clearly stated.
 Requirements are being discussed with the client in order to remove the
misinterpretations if they exist.
 Each requirement is being analyzed to prove its feasibility for the current
system.

Page-26
4.6 Use Case Diagram
Figure 5 Use case Diagram of ERP

Page-27
Figure 6 Login Use Case

Page-28
Figure 7 calculate marks use case

Page-29
Figure 8Managing Test

Page-30
Figure 9 Appearing Test

Page-31
5. System Design
5.1 System Architecture
5.1.1 Class Diagram
Figure 10 Class Diagram

Page-32
5.1.2 Activity Diagram:
Figure 11 Student Activity Diagram

Page-33
5.1.3 Activity Diagram:
Figure 12 Faculty Activity Diagram

Page-34
5.1.4 Sequence Diagram:
Figure 13 Sequence Diagram

Page-35
5.2 Database Design
5.2.1 Data Dictionary
In database management system file that defines the basic organization of a database.
A data dictionary contains a list of all files in the database, the number of records in
each file, and the names and types of each field. Most database management systems
keep the data dictionary hidden from users to prevent them from accidentally
destroying its contents.
Data dictionaries do not contain any actual data from the database, only book keeping
information for managing it. Without a data dictionary, however, a database
management system cannot access data from the database.
Following are the database tables of the project:
NO Table Name Table Description
1 student_mstr Student table
2 faculty_msr faculty table
3 course_mstr course table
4 batch_mstr batch table
5 attendace_mstr attendance table
6 suggestion_mstr suggestion table
7 que_mstr question table
8 options options table
9 correct_option correct option table
10 on_exam online exam table
11 result_mstr result table
12 reseach_mstr research table
13 Admin Admin table
14 Gloable_mstr Global note table

Page-36
Following are the database tables with the fieldnames, data types, length, key field,
and description.
1. Student table
The information related student is stored in the student table. This gives various information
while student interact with its profile.
Attribute
Data Type
Constrains
DescriptionNull Key
Id Int No pri id of the student
fname varchar(20) No student firstname
lname varchar(20) No student last name
gender varchar(6) No student gender
Add varchar(50 No student address
City varchar(20) No city of the student
State varchar(20) No student state
email varchar(50) No student email
Qual varchar(10) No qualification of the student
course Int No course of the student
j_date Date No joining date of the student
mo_no Int No student mobile nu
p_no Int No student phone num
u_name varchar(30) No username of the student
Pwd varchar(30) No password of the student
status varchar(10) No status of the student
Table 2 Student Table

Page-37
2. Faculty table
Storing the all the information related faculty.
Attribute
Data
Type
Constrains
Description
Is
Null
Key
Id Int no pri faculty id
fname varchar(20) first name of the faculty
mname varchar(20) middle name of the faculty
lname varchar(20) last name of the faculty
gen varchar(6) faculty gender
add varchar(50) faculty address
city varchar(20) city of the faculty
state varchar(20) state of the facutly
email varchar(50) faculty email detail
course varchar(25) faculty for which course
quali varchar(10) qualification of the faculty
exp varchar(2) experience of the faculty
j_date Date joining date of the faculty
m_no Int mobile no of the faculty
u_name varchar(30) username of the faculty
pass varchar(30) password ot the faculty
Table 3 Faculty Table
3. Course table
It stores the different type of course and other related information which includes batch name
and other.
Attribute
Data
Type
Constrains
DescriptionNull Key
c_id Int no pri id of the course
c_name varchar(25) No course name
b_name varchar(15) No batch name
stud_status varchar(10) No status of the student
lec_status varchar(8) no status of the lecture
f_name varchar(20) no faculty name
f_id Int no fk(faculty_mstr) id of the faculty
b_id Int no fk(batch_mstr) id of the batch
Table 4 Course Table

Page-38
4. Batch table
All the information related batch will be stored in this table.
Attribute
Data
Type
Constrains
DescriptionNull Key
b_id Int No pri id of the batch
b_name varchar(25) name of the batch
b_tostud Int total no of student in the batch
b_start Date starting date of the batch
b_end Date ending date of the batch
b_duration varchar(12) time of the batch
b_progress varchar(8) progress of the batch
b_days varchar(4) days of the batch
b_stutus varchar(10) batch status
Table 5 Batch Table
5. Attendance table
Student attendance information is stored in this table for getting the information on which
date student have missed his topic. So that he/her can cover up his lecture.
Attribute
Data
Type
Constrains
DescriptionNull Key
id Int no pri id of the attendance
lec_date Date no date of the lecture taken by the faculty
attendance varchar(7) fill attendace
topic Text topic which run by the faculty
Table 6 Attendance Table
6. Suggestion table
Recording the suggestion send from the student whatever he/her wants. So that suggestion
will be implement for future progress.
Attribute
Data
Type
Constrains
DescriptionNull Key
id Int no pri id of the suggestion
suggestion Text yes suggestion of the student
date Date no date of the suggestion
Table 7 Suggestion Table

Page-39
7. Question table
Storing the question and paper id for fetching the questions while student appear for the
online test..
Attribute Data Type
Constrains
DescriptionNull Key
que_id Int no Pri id of the question
questions varchar(300) storing the questions
paper_id Int no id of the paper
Table 8 Question Table
8. Option table
Record the options for the question in this table which helps to get options to the student for
giving the online test.
Attribute
Data
Type
Constrains
DescriptionNull Key
op_id Int No Pri storing the id of the option
que_id Int no stroing the id of the questions
opt Text Yes storing the options
Table 9 Options Table
9. Correct option table
Stored only the correct option id and related its question. So that when student give the exam
that time it it is correct then he will get the positive mark of them and result will be shown as
per his correct option.
Attribute
Data
Type
Constrains
DescriptionNull Key
question_id Int no id of the question
option_id Int no id of the option
Table 10 Correct Option Table

Page-40
10. Online exam table
This table will helps to fetch the exam paper with getting the student id and student can give
the online exam.
Attribute
Data
Type
Constrains
DescriptionNull Key
ex_id Int no pri id of the exam
stud_id Int no id of the student
paper_id Int no id of the paper
ex_date Date no date of the exam
Table 11 Exam Table
11. Result table
The details about the student result is stored in this table for which he has done his online
exam and shown to the student for his information.
Attribute
Data
Type
Constrains
DescriptionNull Key
id Int no Pri id of the result
category varchar(15) category of the exam
ex_date Date date of the exam
ob_marks Int obtained marks
to_marks Int total marks
attendace varchar(8) attendace of the student
course varchar(25) for which course
batch varchar(25) from which batch
Table 12 Result Table
12. Research table
Faculty research will be stored in this table for finding the new research.
Attribute
Data
Type
Constrains
DescriptionNull Key
id Int No Pri id of the research
f_id Int id of the faculty
research varchar(50) No research of the faculty
Table 13 Research Table

Page-41
13. Admin Table
Attribute Data Type
Constrains
DescriptionNull Key
id Int No Pri id of the admin
username Varchar(30) Username of the admin
pas varchar(30) No Password of the admin
Table 14 Admin Table
14. Global note
Attribute
Data
Type
Constrains
DescriptionNull Key
id Int No Pri id of the note
note text note
Date Date No Date of the note
Table 15 Global note

Page-42
6. User Manual
Login Page:
Figure 14 Login page
R1: login
Actor: Admin, Faculty, Student
Pre Condition: None
Input: User Id and Password
Output: Home Page as per role
Flow:
1. User Logs in with username and password.
2. If correct then Home Page is displayed.

Page-43
Alternate Flow:
1. If the username is wrong then it is asked to login again.
2. If the password is wrong then the user is asked to enter again.
Forgot Password page:
Figure 15 Forgot password page
R2: Forgot password
Pre Condition: None
Input: username
Output: conformation message
Flow:

Page-44
1. User Logs in with username.
2. If correct then conformation is displayed.
Alternate Flow:
Conformation page for sending the password in mail id:
Figure 16 Conformation page
R3: Conformation message
Pre Condition: None
Input: None
Output: conformation message
Flow:
2. User Logs if Press Ok

Page-45
Password change page:
Figure 17 Change password page
R4: Change password
Pre Condition: Must be login
Input: old password and new password
Output: change the password
Flow:
2. User can change his password by clicking the change password
Alternate Flow:
1. If the username is wrong then ask for again login

Page-46
Student Home page:
Figure 18 Student Home Page
R5: Home page
Actor: Student
Input: None
Output: Displaying global note
Flow:
2. If correct then home page is displayed.
Alternate Flow:

Page-47
Student Profile Page:
Student Personal Information:
Figure 19 Student profile page
R6: Forgot password
Actor: Student
Input: click in profile
Output: Display personal profile
Flow:
1. User selecting the profile and get the personal profile.

Page-48
Alternate Flow:
Student Course Information:
Figure 20 Course Information page
R7: Forgot password
Actor: Student
Input: click in course information
Output: display the course information
Flow:

Page-49
2. If correct displayed course information by clicking the course information.
Alternate Flow:

Page-50
Student Lecture Attendance Information:
Figure 21 Lecture Attendance page
R8: Forgot password
Actor: Student

Page-51
Pre Condition: Must be logon
Input: Click on Attendance
Output: Displaying attendance and related information
Flow:
2. If correct then attendance is displayed an also other information.
Alternate Flow:
Assessment
Exam Detail:
Figure 22 Exam Detail page

Page-52
R9: Check Result
Actor: Student
Input: Click on exam result
Output: result of the all exam
Flow:
2. If correct result is getting.
Alternate Flow:

Page-53
Assignment download Page:
Figure 23 Assignment Download page
R10: Download assignment
Actor: Student
Input: click on assignment in assessment
Output: Getting the information and link for download assignment.
Flow:

Page-54
1. Students have to go in assessment menu and then click on assignment.
2. If Student clicks in download then he will be able to downloading the
document.
Alternate Flow:
1. If the students don’t want to download the assignment then he can skip.

Page-55
Supporting Document:
Figure 24 Download Document Page
R11: Download Documents
Actor: Student

Page-56
Input: click on supporting document
Output: Getting the information and link for download document.
Flow:
1. Downloading the document by clicking on download.
2. If Student clicks in download then he will be able to downloading the
document.
Alternate Flow:
1. If the students don’t want to download the assignment then he can skip.

Page-57
Online Assessment:
Online Exam:
Figure 25 Selecting exam paper page
R12: Selecting the exam paper
Actor: Student
Input: click on online exam in online assessment
Output: Getting the latest paper list.
Flow:
1. Students have to go in online assessment menu and then click on online
exam.
2. Student click on submit button and appear for online test.

Page-58
Exam instruction page:
Figure 26 Exam page
R13: For the online exam
Actor: Student
Input: click on OK menu
Output: Getting the information related exam
Flow:
1. Student have to click on the OK menu for continue the exam.

Page-59
Questions Page:
Figure 27 Online Exam page
R14: online questions
Actor: Student
Input: click on right option
Output: Display the question and options.
Flow:
(1) Choosing the appropriate option and click on the next button for rest of
questions.
(2) If Student wants to leave that question then go for further question.
Alternate Flow:
(1)If the students don’t want to attend question he can finish his exam.

Page-60
Question Page:
Figure 28 Online Exam Page
R15: online questions
Actor: Student
Input: click on right/Submit option
Output: Display the question and options.
Flow:
1. Choosing the appropriate option and click on the next button for rest of
questions.
2. If Student wants to leave that question then go for further question.
Alternate Flow:
1. If the students don’t want to attend question he can finish his exam.

Page-61
Student Suggestion:
Figure 29 Suggestion page
R16: For suggestion
Actor: Student
Input: click on Suggestion
Output: Display suggestion box for entering a suggestion.
Flow:
1. If student want to put suggestion then he can write in the suggestion box.
Alternate Flow:

Page-62
2. If the students don’t want to write suggestion then he can skip.
Logout:
Figure 30 Logout page
R17: Logout
Actor: Student
Input: click on logout
Output: logout successfully
Flow:
1 By clicking logout student is logout from the student module.

Page-63
Faculty:
Faculty Home Page:
Figure 31 Faculty Home page
R18: Faculty Home page
Actor: Faculty
Input: login with its username and password
Output: Display home page
Flow:
1. Faculty is login with his username and password.
2. By clicking the submit button he get the home page.
Alternate Flow:
1. If the username and password is wrong then ask again.
2. If the Faculty forgot his password then he can get the password by clicking
on forgot password.

Page-64
Faculty Lecture Flow:
Figure 32 Faculty Lecture Flow page
R19: Download Lecture flow
Actor: Faculty
Input: click on Lecture flow in Task menu
Output: Getting the information of various assignment
Flow:
1. By clicking on lecture flow, he gets the information for download the list of
the lecture flow.

Page-65
Faculty Assignment Page:
Figure 33 Assignment page
R20: Download assignment
Actor: Faculty
Input: click on assignment in task menu
Output: Display student assignment
Flow:
1. Faculty have to click on assignment in task menu for downloading the
student assignment.
2. By clicking the download he can download the assignment details.

Page-66
Faculty Batches Detail:
Figure 34 Faculty Batch page
R21: for batches detail
Actor: Faculty
Input: click in batches detail
Output: Display the detail of the batch
Flow:
1. By clicking on batches details he can able to see his batch.

Page-67
Search Student:
Figure 35 Faculty Search page
R22: for searching the student
Actor: Faculty
Input: click on search student.
Output: Display the table of the search student
Flow:
1. By clicking on the search student he gets the table for entering the details.

Page-68
Search Result:
Figure 36 Faculty Search Result page
R23: Result of searching student
Actor: Faculty
Input: Enter appropriate data in field.
Output: Display the information about the searching.
Flow:
1. Entering the appropriate information in the field.
2. By clicking the submit button he get the information of the searching student.

Page-69
Alternate Flow:
1. If data is wrong then he cannot able to get the information.
Faculty Reporting
Figure 37 Faculty Reporting page
R23.1: Daily report of the faculty
Actor: Faculty
Input: click on the batch and given input of his work
Output: Record the data in the database.
Flow:
1. By select the batch the he get the student of this batch and give input to the
checkbox for present student.
2. By clicking the submit button data is store in the database.

Page-70
Faculty report:
Figure 38 Faculty Reporting Page
R23.2: for reporting
Actor: Faculty
Input: enter data in to the extra research field and submit it
Output: open new window.
Flow:
1. By select the batch the he get the student of this batch and give input to the
checkbox for present student.
2. By clicking the submit button data is store in the database.

Page-71
Figure 39 Faculty Reporting Page
R23.3: for reporting
Actor: Faculty
Input: None
Output: Display information
Flow:
1. Click on submit button for sending the information about the daily work.

Page-72
Admin
Admin Home page:
Figure 40 Admin Home page
R24: Home page
Actor: Admin
Input: None
Output: Display home page
Flow:
1. Entering the username and password in login table and display the home
page.

Page-73
Admin New Faculty page:
Figure 41 Admin New Faculty page
R25: Add new Faculty
Actor: Admin
Input: Enter the data in the field.
Output: storing the record in the database.
Flow:
1. Open the menu of the faculty and select the new faculty.
2. Entering the data of the Faculty and submit it.

Page-74
Admin view, update and remove page:
Figure 42 Admin View, Update, Remove Faculty page
R26: view, update and remove Faculty
Actor: Admin
Input: click on the view faculty in faculty menu.
Output: Display the student faculty information.
Flow:
1. Open the menu of the faculty and select the View faculty.
2. If Admin wants to update the data of the faculty then he can update by click
on the update.
3. If Admin wants to remove the data of the faculty then he can remove data by
click on the remove.

Page-75
New Student page:
Figure 43 Admin New Student page
R27: Add new Student
Actor: Admin
Input: Enter the data in the field.
Output: storing the record in the database.
Flow:
1. Open the menu of the Student and select the new Student.
2. Entering the data of the student and submit it.

Page-76
Student view, update and remove page:
Figure 44 Admin View, Update, Remove page
R28: view, update and remove Student
Actor: Admin
Input: click on the view faculty in faculty menu.
Output: Display the student information.
Flow:
1. Open the menu of the student and select the View student.
2. If Admin wants to update the data of the student then he can update by click
on the update.
3. If Admin wants to remove the data of the student then he can remove data by
click on the remove.

Page-77
Admin new paper:
Figure 45 Insert new paper page
R29: insert the new paper
Actor: Admin
Input: click on the subject menu
Output: Display the information of the paper.
Flow:
i. Enter the paper name and select subject for which admin wants to add a new
paper.

Page-78
Add new questions, options and correct answer
Figure 46 New Questions page
R30: for new questions
Actor: Admin
Input: click on the view questions in question menu.
Output: Display the information
Flow:
1 Enter the question, option and choose its right answer.
2 Submit it for the store question in the database.

Page-79
7. Testing
7.1TESTING PLAN
Software Testing has a dual function; it is used to identify the defects in program and
it is used to help judge whether or not program is usable in practice. Thus software
testing is used for validation and verification, which ensure that software conforms to
its specification and meets need of the software customer.
Developer resorted Alpha testing, which usually comes in after the basic design of the
program has been completed. The project scientist will look over the program and
give suggestions and ideas to improve or correct the design. They also report and give
ideas to get rid of around any major problems. There is bound to be a number of bugs
after a program have been created.
Figure 47 Testing Step
Unit Testing
Module
Testing
Sub-system
Testing
System
Testing
Acceptance
Testing

Page-80
Branch coverage
It is strategy in which test cases are designed to make each branch condition assume
true & false values.
Conditional coverage
In this testing test cases are designed to make each component of composite
conditional expression both true & false.
7.2 The Testing Process
We test the software process activities such as Design, Implementation, and
Requirement Engineering. Because, design errors are very costly to repair once
system has been started to operate, it is quite obvious to repair them at early stage of
the system. So analysis is the most important process of any project.
7.2.1 Requirement Traceability
As most interested portion is whether the system is meeting its requirements or not,
for that testing should be planned so that all requirements are individually tested. We
checked the output of certain combination of inputs so that we can know whether it
gives desirable results or not. Strictly sticking to your requirements specifications,
give you the path to get desirable results from the system.
7.2.2 Testing Schedule
We have tested each procedure back-to-back so that errors and omissions can be
found as early as possible. Once the system has been developed fully we tested it on
other machines, which differs in configuration.
7.3 TESTING STRATEGY
There are types of testing that we implement. They are as follows:
 While deciding on the focus of testing activities, study project priorities. For
example, for an on-line system, pay more attention to response time. Spend
more time on the features used frequently.

Page-81
 Decide on the effort required for testing based on the usage of the system. If
the system is to be used by a large number of users, evaluate the impact on
users due to a system failure before deciding on the effort.
 A necessary part of the test case is a definition of the expected result.
 Write test cases for invalid and unexpected as well as valid and expected input
conditions.
 Thoroughly inspect the results of each test.
We have performed both Unit Testing and System Testing on WIMS to detect and fix
errors. A brief description of both is given below.
7.3.1 White Box Testing
White-box testing (also known as clear box testing, glass box testing, transparent
box testing, and structural testing) is a method of testing software that tests internal
structures or workings of an application, as opposed to its functionality (i.e. black-box
testing). In white-box testing an internal perspective of the system, as well as
programming skills, are used to design test cases. The tester chooses inputs to
exercise paths through the code and determine the appropriate outputs.
While white-box testing can be applied at the unit, integration and system levels of
the software testing process, it is usually done at the unit level. It can test paths within
a unit, paths between units during integration, and between subsystems during a
system–level test. Though this method of test design can uncover many errors or
problems, it might not detect unimplemented parts of the specification or missing
requirements.
White-box test design techniques include:
 Control flow testing
 Data flow testing
 Branch testing
 Path testing
 Statement coverage
 Decision coverage

Page-82
Overview
White-box testing is a method of testing the application at the level of the source
code. The test cases are derived through the use of the design techniques
mentioned above: control flow testing, data flow testing, branch testing, path
testing, statement coverage and decision coverage as well as modified
condition/decision coverage.
White-box testing is the use of these techniques as guidelines to create an error
free environment by examining any fragile code. These White-box testing
techniques are the building blocks of white-box testing, whose essence is the
careful testing of the application at the source code level to prevent any hidden
errors later on. These different techniques exercise every visible path of the source
code to minimize errors and create an error-free environment. The whole point of
white-box testing is the ability to know which line of the code is being executed
and being able to identify what the correct output should be.
Levels
1. Unit testing. White-box testing is done during unit testing to ensure that
the code is working as intended, before any integration happens with
previously tested code. White-box testing during unit testing catches any
defects early on and aids in any defects that happen later on after the code
is integrated with the rest of the application and therefore prevents any
type of errors later on.
2. Integration testing. White-box testing at this level is written to test the
interactions of each interface with each other. The Unit level testing made
sure that each code was tested and working accordingly in an isolated
environment and integration examines the correctness of the behaviour in
an open environment through the use of white-box testing for any
interactions of interfaces that are known to the programmer.
3. Regression testing. White-box testing during regression testing is the use of
recycled white-box test cases at the unit and integration testing levels.

Page-83
Basic Procedure
White-box testing's basic procedures involve the understanding of the source code
that you are testing at a deep level to be able to test them. The programmer must have
a deep understanding of the application to know what kinds of test cases to create so
that every visible path is exercised for testing. Once the source code is understood
then the source code can be analyzed for test cases to be created. These are the three
basic steps that white-box testing takes in order to create test cases:
Input, involves different types of requirements, functional specifications, detailed
designing of documents, proper source code, security specifications. This is the
preparation stage of white-box testing to layout all of the basic information.
Processing Unit involves performing risk analysis to guide whole testing process,
proper test plan, execute test cases and communicate results. This is the phase of
building test cases to make sure they thoroughly test the application the given results
are recorded accordingly.
Output, prepare final report that encompasses all of the above preparations and
results.
Advantages
White-box testing is one of the two biggest testing methodologies used today. It
primarily has three advantages:
1. A side effect of having the knowledge of the source code is beneficial to
thorough testing.
2. Optimization of code by revealing hidden errors and being able to remove
these possible defects.
3. Gives the programmer introspection because developers carefully describe any
new implementation.
Disadvantages
Although White-box testing has great advantages, it is not perfect and contains some
disadvantages. It has two disadvantages:

Page-84
1. White-box testing brings complexity to testing because to be able to test every
important aspect of the program, you must have great knowledge of the
program. White-box testing requires a programmer with a high-level of
knowledge due to the complexity of the level of testing that needs to be done.
2. On some occasions, it is not realistic to be able to test every single existing
condition of the application and some conditions will be untested.
7.3.2 Black Box Testing
Black-box testing is a method of software testing that examines the functionality of
an application (e.g. what the software does) without peering into its internal structures
or workings. This method of test can be applied to virtually every level of software
testing: unit, integration, system and acceptance. It typically comprises most if not all
higher level testing, but can also dominate unit testing as well.
Test Procedures
Specific knowledge of the application's code/internal structure and programming
knowledge in general is not required. The tester is aware of what the software is
supposed to do but is not aware of how it does it. For instance, the tester is aware that
a particular input returns a certain, invariable output but is not aware of how the
software produces the output in the first place.
Test Cases
Test cases are built around specifications and requirements, i.e., what the application
is supposed to do. Test cases are generally derived from external descriptions of the
software, including specifications, requirements and design parameters. Although the
tests used are primarily functional in nature, non-functional tests may also be used.
The test designer selects both valid and invalid inputs and determines the correct
output without any knowledge of the test object's internal structure.

Page-85
Test Design Techniques
Typical black-box test design techniques include:
 Decision table testing
 All-pairs testing
 State transition Analysis
 Equivalence partitioning
 Boundary value analysis
 Cause–effect graph
 Error guessing
Advantages
 Efficient when used on large systems.
 Since the tester and developer are independent of each other, testing is
balanced and unprejudiced.
 Tester can be non-technical.
 There is no need for the tester to have detailed functional knowledge of
system.
 Tests will be done from an end user's point of view, because the end user
should accept the system. (This testing technique is sometimes also called
Acceptance testing.)
 Testing helps to identify vagueness and contradictions in functional
specifications.
 Test cases can be designed as soon as the functional specifications are
complete.

Page-86
Disadvantages
 Test cases are challenging to design without having clear functional
specifications.
 It is difficult to identify tricky inputs if the test cases are not developed based
on specifications.
 It is difficult to identify all possible inputs in limited testing time. As a result,
writing test cases may be slow and difficult.
 There are chances of having unidentified paths during the testing process.
 There is a high probability of repeating tests already performed by the
programmer.
7.3.3 Unit Testing
In computer programming, unit testing is a software testing method by which
individual units of source code, sets of one or more computer program modules
together with associated control data, usage procedures, and operating procedures are
tested to determine if they are fit for use. Intuitively, one can view a unit as the
smallest testable part of an application. In procedural programming, a unit could be an
entire module, but it is more commonly an individual function or procedure. In
object-oriented programming, a unit is often an entire interface, such as a class, but
could be an individual method. Unit tests are short code fragments created by
programmers or occasionally by white box testers during the development process.
Ideally, each test case is independent from the others. Substitutes such as method
stubs, mock objects, fakes, and test harnesses can be used to assist testing a module in
isolation. Unit tests are typically written and run by software developers to ensure that
code meets its design and behaves as intended.
Benefits
The goal of unit testing is to isolate each part of the program and show that the
individual parts are correct. A unit test provides a strict, written contract that the piece
of code must satisfy. As a result, it affords several benefits.

Page-87
Unit tests find problems early in the development cycle.
In test-driven development (TDD), which is frequently used in both Extreme
Programming and Scrum, unit tests are created before the code itself is written. When
the tests pass, that code is considered complete. The same unit tests are run against
that function frequently as the larger code base is developed either as the code is
changed or via an automated process with the build. If the unit tests fail, it is
considered to be a bug either in the changed code or the tests themselves. The unit
tests then allow the location of the fault or failure to be easily traced. Since the unit
tests alert the development team of the problem before handing the code off to testers
or clients, it is still early in the development process.
Facilitates change
Unit testing allows the programmer to refactor code at a later date, and make sure the
module still works correctly. The procedure is to write test cases for all functions and
methods so that whenever a change causes a fault, it can be quickly identified.
Readily available unit tests make it easy for the programmer to check whether a piece
of code is still working properly.
In continuous unit testing environments, through the inherent practice of sustained
maintenance, unit tests will continue to accurately reflect the intended use of the
executable and code in the face of any change. Depending upon established
development practices and unit test coverage, up-to-the-second accuracy can be
maintained.
Simplifies integration
Unit testing may reduce uncertainty in the units themselves and can be used in a
bottom-up testing style approach. By testing the parts of a program first and then
testing the sum of its parts, integration testing becomes much easier.
An elaborate hierarchy of unit tests does not equal integration testing. Integration with
peripheral units should be included in integration tests, but not in unit tests.

Page-88
Integration testing typically still relies heavily on humans testing manually; high-level
or global-scope testing can be difficult to automate, such that manual testing often
appears faster and cheaper.
Documentation
Unit testing provides a sort of living documentation of the system. Developers
looking to learn what functionality is provided by a unit and how to use it can look at
the unit tests to gain a basic understanding of the unit's interface.
Unit test cases embody characteristics that are critical to the success of the unit. These
characteristics can indicate appropriate/inappropriate use of a unit as well as negative
behaviours that are to be trapped by the unit. A unit test case, in and of itself,
documents these critical characteristics, although many software development
environments do not rely solely upon code to document the product in development.
By contrast, ordinary narrative documentation is more susceptible to drifting from the
implementation of the program and will thus become outdated (e.g., design changes,
feature creep, relaxed practices in keeping documents up-to-date).
Design
When software is developed using a test-driven approach, the combination of writing
the unit test to specify the interface plus the refactoring activities performed after the
test is passing, may take the place of formal design. Each unit test can be seen as a
design element specifying classes, methods, and observable behaviour.
Limitations
Testing will not catch every error in the program, since it cannot evaluate every
execution path in any but the most trivial programs. The same is true for unit testing.
Additionally, unit testing by definition only tests the functionality of the units
themselves. Therefore, it will not catch integration errors or broader system-level
errors (such as functions performed across multiple units, or non-functional test areas
such as performance). Unit testing should be done in conjunction with other software

Page-89
testing activities, as they can only show the presence or absence of particular errors;
they cannot prove a complete absence of errors. In order to guarantee correct
behaviour for every execution path and every possible input, and ensure the absence
of errors, other techniques are required, namely the application of formal methods to
proving that a software component has no unexpected behaviour.
7.3.4 Integration Testing
Integration testing (sometimes called integration and testing, abbreviated I&T) is
the phase in software testing in which individual software modules are combined and
tested as a group. It occurs after unit testing and before validation testing. Integration
testing takes as its input modules that have been unit tested, groups them in larger
aggregates, applies tests defined in an integration test plan to those aggregates, and
delivers as its output the integrated system ready for system testing.
Purpose
The purpose of integration testing is to verify functional, performance, and reliability
requirements placed on major design items. These "design items", i.e. assemblages (or
groups of units), are exercised through their interfaces using black box testing,
success and error cases being simulated via appropriate parameter and data inputs.
Simulated usage of shared data areas and inter-process communication is tested and
individual subsystems are exercised through their input interface. Test cases are
constructed to test whether all the components within assemblages interact correctly,
for example across procedure calls or process activations, and this is done after testing
individual modules, i.e. unit testing. The overall idea is a "building block" approach,
in which verified assemblages are added to a verified base which is then used to
support the integration testing of further assemblages.
Some different types of integration testing are big bang, top-down, and bottom-up.
Other Integration Patterns are: Collaboration Integration, Backbone Integration, Layer
Integration, Client/Server Integration, Distributed Services Integration and High-
frequency Integration.

Page-90
Big Bang
In this approach, all or most of the developed modules are coupled together to form a
complete software system or major part of the system and then used for integration
testing. The Big Bang method is very effective for saving time in the integration
testing process. However, if the test cases and their results are not recorded properly,
the entire integration process will be more complicated and may prevent the testing
team from achieving the goal of integration testing.
A type of Big Bang Integration testing is called Usage Model testing. Usage Model
Testing can be used in both software and hardware integration testing. The basis
behind this type of integration testing is to run user-like workloads in integrated user-
like environments. In doing the testing in this manner, the environment is proofed,
while the individual components are proofed indirectly through their use. Usage
Model testing takes an optimistic approach to testing, because it expects to have few
problems with the individual components. The strategy relies heavily on the
component developers to do the isolated unit testing for their product. The goal of the
strategy is to avoid redoing the testing done by the developers, and instead flesh-out
problems caused by the interaction of the components in the environment. For
integration testing, Usage Model testing can be more efficient and provides better test
coverage than traditional focused functional integration testing. To be more efficient
and accurate, care must be used in defining the user-like workloads for creating
realistic scenarios in exercising the environment. This gives confidence that the
integrated environment will work as expected for the target customers.
Top-down and Bottom-up
Bottom up Testing is an approach to integrated testing where the lowest level
components are tested first, then used to facilitate the testing of higher level
components. The process is repeated until the component at the top of the hierarchy is
tested.
All the bottom or low-level modules, procedures or functions are integrated and then
tested. After the integration testing of lower level integrated modules, the next level of

Page-91
modules will be formed and can be used for integration testing. This approach is
helpful only when all or most of the modules of the same development level are
ready. This method also helps to determine the levels of software developed and
makes it easier to report testing progress in the form of a percentage.
Top down Testing is an approach to integrated testing where the top integrated
modules are tested and the branch of the module is tested step by step until the end of
the related module.
Sandwich Testing is an approach to combine top down testing with bottom up
testing.
The main advantage of the Bottom-Up approach is that bugs are more easily found.
With Top-Down, it is easier to find a missing branch link.
7.3.5 Validation Testing
Validations are independent procedures that are used together for checking that a
product, service, or system meets requirements and specifications and that it fulfils its
intended purpose. The words "verification" and "validation" are sometimes preceded
with "Independent" (or IV&V), indicating that the verification and validation is to be
performed by a disinterested third party.
Overview
Validation is intended to ensure a product, service, or system (or portion thereof, or set
thereof) result in a product, service, or system (or portion thereof, or set thereof) that
meets the operational needs of the user. For a new development flow or verification
flow, validation procedures may involve modelling either flow and using simulations
to predict faults or gaps that might lead to invalid or incomplete verification or
development of a product, service, or system (or portion thereof, or set thereof). A set
of validation requirements (as defined by the user), specifications, and regulations
may then be used as a basis for qualifying a development flow or verification flow for
a product, service, or system (or portion thereof, or set thereof). Additional validation
procedures also include those that are designed specifically to ensure that

Page-92
modifications made to an existing qualified development flow or verification flow
will have the effect of producing a product, service, or system (or portion thereof, or
set thereof) that meets the initial design requirements, specifications, and regulations;
these validations help to keep the flow qualified. It is a process of establishing
evidence that provides a high degree of assurance that a product, service, or system
accomplishes its intended requirements. This often involves acceptance of fitness for
purpose with end users and other product stakeholders. This is often an external
process.
AAssppeeccttss ooff VVaalliiddaattiioonn
The most tested attributes in validation tasks may include, but are not limited to
 Selectivity/specificity
 Accuracy and precision
 Repeatability
 Reproducibility
 Limit of detection – especially for trace elements
 Limit of quantification
 Curve fitting and its range
 System suitability
To solve this kind of difficulties, some regulatory bodies or compendia methods
usually provide the advices on what the circumstances or conditions that the
performing of a specified system suitability test should be bearded and compulsory.

Page-93
8. LIMITATIONS AND FUTURE ENHANCEMENTS
8.1 Limitations
The limitation of the application is more improve in online examination. Limited
questions had been stored and need more updation and maintenance of the
application.
Storage capacity too small so that it cannot be stored large amount of data so take
back up is necessary for the future requirement. So limited amount of data can be
stored.
A Print of the result cannot print out in this application.
8.2 Future Enhancements
Make online exam more effective, efficient and more dynamic so that it helps to get a
good support from the student.
It has been marking while this application open in other browser due to designing
support. It’s more support to Mozilla as compare to other browser.
Online result printing and more user interaction functionality and features need to be
developed.
Needs to improve more security for the purpose of the safety.

Page-94
9 Conclusion
No project can be termed as ‘perfect’ in real sense and there always remains scope for
future improvement and so that helps to develop a new version of the software. We
are always eager to know some new points and validation related to projects which
give us more knowledge and help us to create new version.
The “ERP” system has been developed by me and also done enhancement in
application through applying our knowledge gained in class room, referring to certain
books, browsing some sites and through the help of external and internal faculties and
using our knowledge related to subject it.
I am very thankful to the project guide and organization staffs that extended all their
support and helped us complete this project successfully.

Page-95
10 Reference
WEBSITES
 http://books.google.com
 http://sourceforge.net
 http://www.gnu.org
 http://www.thefreecountry.com
BOOKS
 Java™ Servlet Specification- By: Rajiv Mordani
 Core servlet and java server pages – By: Marty Hall, Larry Brown, Yaakov
Chaikin

ERP on School Management System

More Related Content

What's hot

Similar to ERP on School Management System

More from Amit Gandhi

Recently uploaded

ERP on School Management System