erp on school management system

ERP (Enterprise Resource Planning)

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-I


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-II


Table of ContentsProject 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-III


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-IV


List of figure

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

Page-V


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

Page-VI


List of table

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

Page-VII


NOTATIONS:

Class Diagram: -

Class:

Class Name

Attribute: Type

+Operation (arglist):return type

Abstract Class:

Class Name

{abstract}

Composition: Generalization:

Usage: Association:

Page-VIII


Sequence Diagram:

Object and Lifeline: Activation:

Message: Message (call): Message (return):

Use Case Diagram:

Actor Use Case:

Page-IX


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

Manage attendance

Page-1


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-2


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-3


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-4


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

Report generation

Page-5


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

1.2 Purpose

Page-6


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.

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.

Page-7


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-8


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-9


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-10


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-11


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.

Coordination between project teams.

Page-12


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.

Work Breakdown Structure

Page-13ERP System


Figure 2 Work breakdown structure of ERP System

Figure 3 Activity Network representation of ERP System

Page-14

Requirement Specification Design Code Test Document

Database part

Graphical user interface part

Database part

Graphical user interface

Specification

Design database part

Integrate and test

Code database part

Write user manual

Finish

Code GUI partDesign

GUI part


Gantt chart

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-15


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-16


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.

Take backups regularly.

Page-17


Perform thorough requirement gathering and analysis. Confirm the collected

requirements with the guide.

Page-18


3. System Requirement Study3. System Requirement Study

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.

3.1 Hardware Requirement Study3.1 Hardware Requirement Study

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-19


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-20


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-21


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-22


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

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.

Page-23


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.

All sources of requirements are covered to get maximum requirement.

All methods of finding requirements are applied.

Page-24


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-25


4.6 Use Case Diagram

Figure 5 Use case Diagram of ERP

Page-26


Figure 6 Login Use Case

Page-27


Figure 7 calculate marks use case

Page-28


Figure 8Managing Test

Page-29


Figure 9 Appearing Test

Page-30


5. System Design

5.1 System Architecture

5.1.1 Class Diagram

Figure 10 Class Diagram

Page-31


5.1.2 Activity Diagram:

Figure 11 Student Activity Diagram

Page-32


5.1.3 Activity Diagram:

Figure 12 Faculty Activity Diagram

Page-33


5.1.4 Sequence Diagram:

Figure 13 Sequence Diagram

Page-34


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-35


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.

AttributeData Type

Constrains

Description Null KeyId Int No pri id of the student

fname varchar(20) No student firstnamelname varchar(20) No student last namegender varchar(6) No student genderAdd varchar(50 No student addressCity varchar(20) No city of the studentState varchar(20) No student stateemail varchar(50) No student emailQual varchar(10) No qualification of the student

course Int No course of the studentj_date Date No joining date of the studentmo_no Int No student mobile nup_no Int No student phone num

u_name varchar(30) No username of the studentPwd varchar(30) No password of the studentstatus varchar(10) No status of the student

Table 2 Student Table

2. Faculty table

Page-36


Storing the all the information related faculty.

AttributeData Type

Constrains

DescriptionIs

NullKey

Id Int no pri faculty id

fnamevarchar(20) first name of the faculty

mnamevarchar(20) middle name of the faculty

lnamevarchar(20) last name of the faculty

gen varchar(6) faculty gender

addvarchar(50) faculty address

cityvarchar(20) city of the faculty

statevarchar(20) state of the facutly

emailvarchar(50) faculty email detail

coursevarchar(25) faculty for which course

qualivarchar(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_namevarchar(30) username of the faculty

passvarchar(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.

AttributeData Type

Constrains

DescriptionNull Keyc_id Int no pri id of the course

c_namevarchar(25) No course name

b_namevarchar(15) No batch name

stud_status varchar(10 No status of the student

Page-37


)

lec_status varchar(8) no status of the lecture

f_namevarchar(20) no faculty name

f_id Int nofk(faculty_mstr) id of the faculty

b_id Int no fk(batch_mstr) id of the batch

Table 4 Course Table4. Batch table

All the information related batch will be stored in this table.

AttributeData Type

Constrains

DescriptionNul

lKey

b_id Int No pri id of the batch

b_namevarchar(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_durationvarchar(12) time of the batch

b_progress varchar(8) progress of the batch

b_days varchar(4) days of the batch

b_stutusvarchar(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.

AttributeData Type

Constrains

DescriptionNull Key

id Int no pri id of the attendancelec_date Date no date of the lecture taken by the faculty

attendancevarchar(7) fill attendace

topic Text topic which run by the faculty

Table 6 Attendance Table

6. Suggestion table

Page-38


Recording the suggestion send from the student whatever he/her wants. So that suggestion will be implement for future progress.

AttributeData Type

Constrains

DescriptionNull Key

id Int no pri id of the suggestionsuggestion Text yes suggestion of the studentdate Date no date of the suggestion

Table 7 Suggestion Table

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 questionquestions varchar(300) storing the questionspaper_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 optionque_id Int no stroing the id of the questionsopt 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.

AttributeData Type

Constrains

DescriptionNull Keyquestion_id Int no id of the question

Page-39


option_id Int no id of the option

Table 10 Correct Option Table

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.

AttributeData 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.

AttributeData Type

Constrains

DescriptionNull Key

id Int no Pri id of the result

categoryvarchar(15) category of the exam

ex_date Date date of the examob_marks Int obtained marksto_marks Int total marksattendace varchar(8) attendace of the student

coursevarchar(25) for which course

batchvarchar(25) from which batch

Table 12 Result Table

Page-40


12. Research table

Faculty research will be stored in this table for finding the new research.

AttributeData Type

Constrains

DescriptionNull Key

id Int No Pri id of the researchf_id Int id of the faculty

researchvarchar(50) No research of the faculty

Table 13 Research Table

Page-41


13. Admin Table

AttributeData Type

Constrains

DescriptionNull Key

id Int No Pri id of the admin

usernameVarchar(30) Username of the admin

pas varchar(30) No Password of the admin

Table 14 Admin Table14. Global note

AttributeData Type

Constrains

DescriptionNull Key

id Int No Pri id of the notenote text noteDate Date No Date of the note

Table 15 Global note

Page-42


6. User ManualLogin Page:

Figure 14 Login pageR1: 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:

1. If the username is wrong then it is asked to login again.

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:

1. User Logs in with username.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:

1. User Logs in with username.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:

1. User Logs in with username.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:2. If the username is wrong then it is asked to login again.

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


1. User Logs in with username.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

Pre Condition: Must be logon

Page-51


Input: Click on Attendance

Output: Displaying attendance and related information

Flow:

1. User Logs in with username.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:

1. User Logs in with username.

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:

2. If the students don’t want to write suggestion then he can skip.

Page-62


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.

Faculty Assignment Page:

Page-65


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.

Faculty Batches Detail:

Page-66


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.

Add new questions, options and correct answer

Page-78


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

Page-80

Unit Testing

Module Testing

Sub-system Testing

System Testing

Acceptance Testing


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.

Integration testing typically still relies heavily on humans testing manually; high-level

Page-88


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

testing activities, as they can only show the presence or absence of particular errors;

Page-89


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.

Aspects of ValidationAspects of Validation

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

Page-96

http://books.google.com/