INTRODUCTION

________________________________________________
1.1 PROJECT SUMMARY
A Student Management System (SMS) for Hospital Management Information
System (HMIS) is a System that manages the records of student regarding admission and
examination part.
A Student Management System (SMS) is designed to help collages for
management of dental student. Extensive information is available at your fingertips
through this System. Viewing student data, managing admission and reshuffling,
managing seats, quota, board, semester, faculty, category and for examination, block
allocation, subject 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. SMS allows the keeping of
personnel data in a form that can be easily accessed and analyzed in a consistent way.
The SMS module is a component covering many other student aspects from
application to retirement. The system records basic personal information, admission
information, education 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. Student management function involves

Manage new admission and enrolment

Manage quota

Manage board

Manage category

Manage Fees Structure

Roll number generation

Fees payment

student Basic Information

Manage faculty

Manage designation

Manage course and specialty

Manage semester and year

admission seat management

Exam scheduling

Result management

Subject management

Block management

In SMS, 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, accountant and operator. Admin has
complete access to the whole system, while accountant is only concerned with payment of
fees for the admission of the student. Operator is the role that is responsible for the use of
the system.
The Admin role can be as follow:

Introduce new quota, board, category, course, etc

Set fees structures

Manage faculties

Manage subjects

Seat management

Management of semester

Generation of student roll number

Set examination

The operator role can:

New admission and enrolment

Search student

Block allocation

Result, etc

Now when the user with the particular role Logs on he can see only those pages which
are allowed to them.

1.2 PURPOSE
The project is about to handle all the information of the student regarding
admission 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:
Automation of admission and enrolment as per board, quota, category and available
seats.
Assistance in decision-making.
To manage information of student, faculty and courses.
Consistently update information of all the students.
Reports- To gather all the related information about any application of the HRMS.
All the above-mentioned matters are to be incorporated in the application along with some
additional requirements.
The main purpose of the Admin Module is to introduce new things and configure
important aspects. For e.g. only admin is authorized to introduce quota, board, subject,
category, etc. and only admin is allowed to configure exam and set fees structure. So the
master screens for all these are visible to only admin role. This is done by the Admin

Module. It also can create the users and Physical and Logical Locations. Thus the main
purpose of the Admin Module is to managing the dynamic working of the system.

1.3 SCOPE
The scope of the project includes the following
Any college can use this system as it is not client centric.
All admission and examination related work for the student can be done using this
system.
Deliver Electronic Workplace
Provide Bi-lingual support
Application Support & Maintenance after deployment to production
The Admin Module can be reused for projects as well which have many users with
different rights. Hence it is reusable.

1.4 TECHNOLOGY & LITERATURE REVIEW

We are not having any past work system. We are designing this project for
the first time. So we are free to use any technology that we want. Online
Recruitment is a web application developed using PHP using C#, HTML, AJAX
used as front end with SQLserver-2005 used as back end.
PHP is a server-side scripting language designed for web development but also
used as a general-purpose programming language. Originally created by Rasmus Lerdorf
in 1994,[4] the PHP reference implementation is now produced by The PHP Group.[5] While
PHP originally stood for Personal Home Page,[4] it now stands for the recursive
backronym PHP: Hypertext Preprocessor

PROJECT MANAGEMENT

________________________________________________
2.1 PROJECT PLANNING AND SCHEDULING
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 network diagram that enables identification of the critical path. Float or slack
time in the schedule can be calculated using project management software. Then the
necessary resources can be estimated and costs for each activity can be allocated to each
resource, giving the total project cost. 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
2.1.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 2.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 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. The code
can, in some cases, represent the major source of documentation of the system. The
analysis of an iteration is based upon user feedback, and the program analysis facilities
available. 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.1.2 Project Plan

Once we examine that the project is feasible, we undertake project planning. The table below
describes how we planned our project.
Table 2.1 Project Plan
Phases

Time Period

No. of days

Deliverables of the phase

Feasibility Analysis

14th July. 20th July

Feasibility Report document

21st July 01st Aug

10

Requirement
Gathering

System Requirement Study

Analysis

02nd Aug 10th Aug

09

Design

11th Aug. 30th Aug

19

Design document

Implement Coding

1st Sep. 9th Sep

Implementation of system

Testing

10th Sep. 13th Sep

Testing Document

Phases

Time Period

No. of days

Deliverables of the phase

Final Evaluation

20th Sep

Report Submit

Roles and Responsibilities

Table 2.2 Roles and Responsibilities

Role

Responsibility

Project Guide

Defining scope

Team/Member
Mr. Jitendra Pawar

Providing required resources

Project planning, tracking and monitoring.
Analysis and Effort Estimation.
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

2.1 RISK MANAGAMENT

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

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

2.2.1

Assess continuously what could go wrong (risks)

Determine which risks are important to deal with

Implement strategies to deal with those risks

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:
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:
A1. Schedule slippage.
A2. Incomplete requirement specification.
A3. Change in user Requirements.
9

A4. Non-availability of required resources.

A5. Lack of communication with end user.
A6. Improper vision about the project.
A7. Staffing and organization problems.
A8. 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:
B1. Unavailable library files.
B2. Problem in connection to database server.
B3. Problem in application server.
B4. Problem in browser view.
C. Business Risk:
The Business Risk threatens the viability of the software to be built.
C1. Project not delivered on time.
C2. 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 includes mainly:
D1. Language error predictions.
D2. Lack of End user support in future project enhancement.
E. Unpredictable Risk

10

The Unpredictable risks are the joker in the deck. They can and do occur, but they are
extremely difficult to identify in advance.
2.2.2

Risk Analysis

Each identified risk is considered and the effect and probability of each risk is identified
during risk analysis.

2.2.3

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.

Perform thorough requirement gathering and analysis.

Confirm the collected requirements with the guide.

SYSTEM REQUIREMENT STUDY

________________________________________________
3.1

USER CHARACTERISTICS
11

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.
User :
Applicant is the one who wish to visit HMIS website. The applicant can fill in his own
details and register himself for membership to use portal services. The applicant has rights
to view and modify his own details, generate its candidature of containing his own details
in academic web part. The applicant also rights to create groups, modify groups, invite
member, modify member, join group, slam book requests, etc. In sort, the applicant can
access the application like a moderator of his/her group.
Faculty :
He can view log sheet submitted by trainee day to day filled student which is applying for
his/her status and day to day log sheet submission- this can be done, only when the
supervisor approve their log sheet, faculty gives review to trainee after looking his/her
remarks by the supervisor.
Supervisor :
The Supervisor is approving the log sheet is done by administrator and give them remarks
on it and supervisor also update trainee log sheet.

3.2

HARDWARE AND SOFTWARE REQUIREMENTS

The following are minimum hardware and requirements that should be present to run the
project successfully.

12

Table 3.1 Tools and Technology

Development technologies

PHP, C++, HTML SQL server 2005, AJAX, JavaScript,

Development tools
Application server
Database
Operating system

XML
WordPress, xoomla
XAMP
SQL
Windows XP Profession Edition, Windows Vista

Web browser
Hardware

Enterprise Edition
Internet Explorer 6.0 and above
P-IV 2.4, 1 GB RAM, 80 GB HDD

Hardware Requirements

Table 3.2 Hardware Requirement

Client Configuration
Pentium IV, 750 MHz, 20GB HDD
Operating System: Windows XP/2000
RAM: 256 MB minimum
400MB Minimum Free Space on Drive
Microsoft Office
Server Configuration
2 Servers, each with following configuration
2 CPU
Operating System: Win XP
RAM: 512MB Minimum
40GB Minimum Free Space on Drive
750MHz
One Server with Sql Application Server
Other Server with Sql Database Server

Software Requirements

Table 3.3 Software Requirement

System Software
wordpress
Xoomla
Microsoft Office
Reporting server
XAMP

13

SYSTEM ANALYSIS

________________________________________________
4.1

STUDY OF CURRENT SYSTEM

The current system for the Student Management System deals with maintaining a

physical contact with the academy management dept. for filling all the details and the
documentation work. The management doesnt need 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
14

system. Thus a simulation of this entire process can be a boon to the applicants as well as
the admin.

4.2

PROBLEMS AND WEAKNESSES 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 the government may need to change the structure of the
process flow in certain cases so that the system output can become faster.

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.

4.3

REQUIREMETNS OF NEW SYSTEM

4.3.1

User Requirements

R1: login
Actor: Admin, Operator, Accountant
Pre Condition: None
15

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

R2: Pay fees

Actor: Accountant
Pre Condition: User must be logged on
Input: Student ID
Output: Fees paid
Flow:
(1) Accountant enters student ID
(2) Details of student is shown with the status of fees paid or not.
(3) If fees not paid then Accountant collects the fees.
(4) student can get the print receipt of paid fees.

Alternate Flow:
(1) If the fields marked with * are empty then alert is displayed.
(2) If student ID does not exist then the system alerts it.

R3: Get admission

16

Actor: operator
Pre Condition: User must be logged on
Input: Complete Details of the student including personal, academic records.
Output: Student ID is generated and student is admitted.
Flow:
(1) Admin clicks on New admission link
(2) New generated Student ID is displayed.
(3) Details of student is filled in the form by operator.
(4) Newly generated ID is given to student.
(5) The student is admitted to the particular course.
Alternate Flow:
(1) If the mandatory fields are not filled then alert is shown.
(2) If there is no available seat for the particular admission then alert is
shown.

R4: Enrolment
Actor: operator
Pre Condition: User must be logged on and student has already got admission.
Input: Details for the enrolment of the student.
Output: student has got enrolment.
Flow:
(1) Admin selects the enrolment link.
(2) Then he enters the student ID.
(3) Details that is applicable to the student for the enrolment is shown.
(4) student is enrolled to the next year or semester.
Alternate Flow:
(1) If student has not passed last semester then system alerts.
17

R5: Modify student Details

Actor: operator
Pre Condition: User must be logged on
Input: student ID
Output: The changes as per modification of the student details in DB
Flow:
(1) Operator selects the link from the list.
(2) Then he enters the ID of the student to be modified.
(3) Then he modifies the details as required.
(4) Then he submits to effect the changes.
Alternate Flow:
(1) If the user clicks the Cancel button, then no changes are reflected in
the DB.

R6: Search student

Actor: Admin, Operator
Pre Condition: User must be logged on
Input: Detail of student as per selected search criteria.
Output: Student with his/her complete details.
Flow:
(1) User selects the link from the list.
(2) Then he selects the search criteria.
(3) Then he enters the details as per search criteria.
(3) Then he deletes, adds or edits the roles from the list.
(4) Search result is displayed.
Alternate Flow:
18

(1) If the user clicks the Cancel button, then no changes are reflected in
the DB.
(2) If there is no such student, then appropriate message is shown.

R7: Add board

Actor: Admin
Pre Condition: User must be logged on
Input: Board details that is to be added.
Output: The changes are reflected in the DB
Flow:
(1) Admin selects the link from the list.
(2) Then he enters the proper details of the board to be added.
(3) On clicking Save button, the board is added to the DB.
Alternate Flow:
(1) If the user clicks the Cancel button, then no changes are reflected in
the DB.
(2) If the admin did not provide the mandatory fields, then alert is shown.

R8: Add quota

Actor: Admin
Pre Condition: User must be logged on
Input: Quota details that is to be added.
Output: The changes are reflected in the DB
Flow:
(1) Admin selects the link from the list.
(2) Then he enters the proper details of the Quota to be added.
(3) On clicking Save button, the Quota is added to the DB.

19

Alternate Flow:
(1) If the user clicks the Cancel button, then no changes are reflected in
the DB.
(2) If the admin did not provide the mandatory fields then alert is shown.

R9: Add Category

Actor: Admin
Pre Condition: User must be logged on
Input: Category details that is to be added.
Output: The changes are reflected in the DB
Flow:
(1) Admin selects the link from the list.
(2) Then he enters the proper details of the Category to be added.
(3) On clicking Save button, the Category is added to the DB.

Alternate Flow:
(1)If the user clicks the Cancel button, then no changes are reflected in the
DB.
(2)If the admin did not provide the mandatory fields then alert is shown.

R10:Set Fees Structures

Actor: Admin
Pre Condition: User must be logged on and he must be Admin
Input: fees details of the particular year, course and semester.
Output: The changes of the fees structure are reflected in the DB
Flow:

20

(1) Admin clicks on the Fees Master link.

(2) He then selects the Course, Year and Semester.
(3) He then sets various fees for it.
(4) On clicking save button, the DB is saved for the fees structure.
Alternate Flow:
(1) If the admin clicks on Cancel button then no changes should be
reflected.
(2) If mandatory fields are empty then alert is shown.

R11: Add/update Designation

Actor: Admin
Pre Condition: User must be logged on
Input: Designation details that is to be added.
Output: The changes are reflected in the DB
Flow:
(1) Admin selects the link from the list.
(2) Then he enters/updates the proper details of the Designation.
(3) On clicking Save button, the data is saved to the DB.
Alternate Flow:
(1)If the user clicks the Cancel button, then no changes are reflected in the
DB.
(2)If the admin did not provided the mandatory fields then alert is shown.

R12: Modify/Manage Faculty Details

Actor: Admin
Pre Condition: User must be logged on

21

Input: Faulty ID
Output: The changes as per modification of the Faculty details in DB
Flow:
(1) Admin selects the link from the list.
(2) Then he enters the ID of the Faculty to be modified.
(3) Then he modifies the details as required.
(4) Then he submits to effect the changes.
Alternate Flow:
(1) If the Admin clicks the Cancel button, then no changes are reflected in
the DB.

R13: Manage Specialization Details

Actor: Admin
Pre Condition: User must be logged on
Input: Details as per Specialty
Output: The changes as per modification of the Specialty details in DB

Flow:
(1) Admin selects the link from the list.
(2) Then he enters the Details of the Specialty to be added/Modified.
(3) Then he submits to effect the changes.
Alternate Flow:
(1) If the Admin clicks the Cancel button, then no changes are reflected in
the DB.
(2) If the mandatory fields are not provided then alert is shown.
22

R14: Configure Semester Details

Actor: Admin
Pre Condition: User must be logged on and he must be Admin
Input: Details of the Semester to be configured.
Output: The changes are reflected in the DB
Flow:
(1) Admin selects the link.
(2) then He selects Semester to be configured.
(3) Details of the Semester are provided.
(4) On clicking Save, information is saved to DB.
Alternate Flow:
(1) If the Admin clicks on Cancel button then no changes should be
reflected.
(2) If semester Details are not valid then alert are shown.
(3) If mandatory fields are empty then alerts are shown.

R15: Seat Management

Actor: Admin
Pre Condition: User must be logged on and he must be Admin
Input: No of Seats for the particular course.
Output: The changes are reflected in the DB
Flow:
(1) Admin clicks on the Seat Master link.
(2) He then selects the course for which the seat is to be set.
(3) He then sets the number of seat for the course and save the details.
23

Alternate Flow:
(1) If the admin clicks on Cancel button then no changes should be
reflected.

R16: Generate Roll Number

Actor: Admin
Pre Condition: User must be logged on and he must be Admin
Input: Year, Course and Semester are selected for which roll number are to be
assigned.
Output: The Students are assigned with roll numbers.
Flow:
(1) Admin clicks on the Roll number Master link.
(2) He then selects the Course, Year and Semester.
(3) He then clicks on assign roll no button.
(4) Roll number and student are saved in DB.
Alternate Flow:
(1) If the user clicks on Cancel button then no changes should be
reflected.

R18: Schedule Exam

Actor: Admin
Pre Condition: User must be logged on and he must be Admin
Input: (1) Year, Course and Semester details
(2) Subjects wise time and date allocation for exam.
Output: Exam is Scheduled and stored in DB.
Flow:
(1) Admin clicks on the Schedule Exam link.
(2) He then selects the Course, Year and Semester.
24

(3) He then add details like subject, date, time.

(4) On clicking Save Button DB is saved with scheduled exam.
Alternate Flow:
(1) If the user clicks on Cancel button then no changes should be
reflected.
(2) If mandatory fields are empty then alert is shown.

R19:Declare Result
Actor: Operator
Pre Condition: User must be logged on
Input: (1)Year, Course and Semester for which result to be set.
(2)Exam type for which result is to be declared.
(3)Marks details of student as per subject.
Output: The Students marks and status of pass or fail is stored in DB.
Flow:
(1) Admin clicks on the set result link.
(2) He then selects the Course, Year and Semester.
(3) He then selects type of the exam.
(4) He then add marks of each student as per subjects.
(5) Status of student is automatically set.
Alternate Flow:
(1) If the user clicks on Cancel button then no changes should be
reflected.
(2) If mandatory fields are empty then alert is shown.

R20: Configure subject for exam

Actor: Admin

25

Pre Condition: User must be logged on and he must be Admin

Input: Subjects and type of exam to be configured
Output: Database is saved as per configuration.
Flow:
(1) Admin clicks on the Subject Exam master link.
(2) He then selects the Subjects.
(3) He then selects type of exam.
(4) He then set duration, passing marks and other details.
(5) Details are saved in DB.
Alternate Flow:
(1) If the user clicks on Cancel button then no changes should be
reflected.
(2) If mandatory fields are empty then alert is shown.
(3) If entry is not found to be valid then alert is shown.

R21: Add Subject

Actor: Admin
Pre Condition: User must be logged on
Input: Subject details that are to be added.
Output: The changes are reflected in the DB
Flow:
(1) Admin selects the link from the list.
(2) Then he enters the proper details of the Subject to be added.
(3) On clicking Save button, the Subject is added to the DB.
Alternate Flow:
(1)If the user clicks the Cancel button, then no changes are reflected in the
DB.
26

(2)If the admin did not provided the mandatory fields then alert is shown.

R22: Add Block

Actor: Admin
Pre Condition: User must be logged on
Input: Block details like block number, ID, floor, etc.
Output: The changes are reflected in the DB
Flow:
(1) Admin selects the link from the list.
(2) Then he enters the proper details of the Block to be added.
(3) On clicking Save button, the Block is added to the DB.
Alternate Flow:
(1)If the admin clicks the Cancel button, then no changes are reflected in
the DB.
(2)If the admin did not provided the mandatory fields then alert is shown.

R23: Subject Semester master

Actor: Admin
Pre Condition: User must be logged on
Input: Subject details that are to place in particular semester.
Output: The changes are reflected in the DB
Flow:
(1) Admin selects the link from the list.
(2) Then he selects the Semester for which subject are to allocated.
(3) Then he select of the Subject to be added.
(4) On clicking Save button, the Subject is added to the DB.
27

Alternate Flow:
(1)If the user clicks the Cancel button, then no changes are reflected in the
DB.
(2)If the admin did not provided the mandatory fields then alert is shown.

R23:block allocation master

Actor: Admin
Pre Condition: User must be logged on
Input: (1) Exam that to be conducted.
(2) Block to be allocated to exam.
Output: The changes are reflected in the DB
Flow:
(1) Admin selects the link from the list.
(2) Then he selects the exam type for which block is to be allocated.
(3) Then he select of the block to be added.

(4) On clicking Save button, the data is added to the DB.

Alternate Flow:
(1)If the admin clicks the Cancel button, then no changes are reflected in
the DB.
(2)If the admin did not provided the mandatory fields then alert is shown.
(3)If block is not available then proper message is shown.

R24: Examination report

Actor: Admin
Pre Condition: User must be logged on

28

Input: criteria by which report is to be generated.

Output: Generated report is shown.
Flow:
(1) Admin selects the link from the list.
(3) Then he selects the criteria.
(4) On clicking show button, the report is shown.
Alternate Flow:
(2)If the admin did not provided the mandatory fields then alert is shown.

4.3.2

System Requirements

Registration details of the applicant.

Login details of the applicant.

Personal details of the applicant.

Information of all the members of the applicants group.

Information of all the friend list of the applicants

account.

Educational and employment information

All information and rules regarding the e-forms must

follow.

Certain legal details of the applicant.

Details regarding the purpose of user visit to academy.

The statutory declaration of the applicant.

Answers to the questionnaire for skill assessment of

visitor.

4.3.3

Communication with whole system.

Non-Functional Requirements
29

Usability

The interface should use terms and concepts, which are drawn from the
experience of the people who will make most of the system. For example,
map and date should be displayed in its traditional fashion.

Efficiency
The system must provide easy and fast access without consuming more
cost.

Reliability
User should never be surprised by the behaviour of the system and it should
also provide meaningful feedback when errors occur so that user can
recover from the errors.

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:
Operational Feasibility:

30

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.
Technical Feasibility:
It determines if the system can be implemented using the current technology. This
system has been developed using PHP as front end and SQL as backend. This was also
new to us but it didnt take much effort and time to get used to it. We had earlier worked
with Access and not SQL Server 2005 but getting familiar with it was also easy.
Economical Feasibility:
The company being a well-to-do company didnt have any problem in buying any
software that was required in developing the application. The softwares we used were
readily available. So as such we didnt face any economical constrains.
Implementation Feasibility:
This project can easily be made available online without much consideration of the
hardware and software. The only required thing at the applicants 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

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.

31

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.

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.

4.6

FUNCTIONS OF SYSTEM

4.6.1

Use Case
The use case model for any system consists of a set if use cases. Intuitively, use

cases represent the different ways in which the users can use a system. Following is the
use case representation of the advantage immigration system.

32

Fig 4.1 Use Case Diagram (Admission Module)

33

Fig 4.2 Use Case Diagram (Examination Module)

4.7

FUNCTIONAL AND BEHAVIORAL MODELING

4.7.1

Context Diagram
The context diagram is the most abstract data flow representation of a system. It

represents the entire system as a single bubble and. The various external entities with
which the system interacts and the data flows occurring between the system and the
external entities are also represented. The name context diagram is well justified because it
represents the context in which the system is to exist i.e. the external entities (users) that
would interact with the system and specific data items they would be receiving from the
system.
34

Fig 4.19 Context diagram of Student Management System

35

Fig 4.20 Level-1 Data flow diagram of Student Management System

36

Fig 4.21 Level-2 Data flow diagram of examination

37

Fig 4.22 Level-2 Data flow diagram of category

38

Fig 4.23 Level-2 Data flow diagram of fees structure

39

Fig 4.24 Level-2 data flow diagram of subject

40

LIMITATIONS AND ENHANCEMENTS

______________________________________________
9.1 LIMITATIONS
The part of the system can be implemented using the current technology although
some modifications had to be done at various places. At various places some alterations
with the prototypes and functionalities would be done in order to work out the cost
constraints and to cope with the scheduling constraints.

In this system we have dont have facility for attendance management of

student.
In this application search is limited to String or by number. Cannot do search by
photo and figure prints.

9.2 FUTURE ENHANCEMENT

The SMS has been developed with a main aim of making work easier and
timesaving for the human capital. The whole system is bi-lingual at present and can be
extended to other languages too with minor changes (not in coded).
The coding pattern is kept as dynamic as possible with minimum amount of static
values to make it easier for future extensions. As the current system is expected to add
more functionality and dependency according to requirement changes and technology,
proper coding standards and working platform have been kept in mind to produce a quality
product.
One enhancement is that we can make this application in more than 1 language as
well. Adding attendance management is also one option for enhancement.

41

CONCLUSION

_____________________________________________
10.1 CONCLUSION

SMS will be helpful to perform paperless work and manage all data.
This provides easy, accurate, unambiguous and faster data access.

Lesser learning curve - Consistent user interface, customized for the group of
users, statistical information in various graphical and tabular forms.

42