Student management system university erp

STUDENT MANAGEMENT SYSTEM (SMS) –University ERP
A PROJECT REPORT
Submitted by
MEHUL THAKKAR (090290131002)
In fulfillment for the award of the degree
Of
BACHELOR OF ENGINEERING
In
Computer Science & Engineering Department
Laljibhai Chaturbhai Institute of Technology, Bhandu-384 120
Ta: Visnagar, Dist: Mehsana
Gujarat Technological University, Ahmedabad
April/May, 2013

April/May, 2013
CERTIFICATE
Date: 24th
April 2013
This is to certify that the project entitled “STUDENT MANAGEMENT SYSTEM (SMS) -
University ERP” has been carried out by MEHUL THAKKAR under my guidance in
fulfillment of the degree of Bachelor of Engineering in Computer Science & Engineering
(8th
Semester) of Gujarat Technological University, Ahmedabad during the academic year
2012-13.
Project Guide
Prof. H.B. Patel
Head, CSE Dept.

L C Institute Of Technology Student Management System (UERP)
I
ACKNOWLEDGEMENT
I remain indebted to Mr. Rakesh Ray and Mr. Dharmesh Bhatt, Company Director for
providing us an opportunity to work in such a professional and healthy environment. Our great
obligations remain towards. Mrs. Dipa, for being a constant source of inspiration, and acting as
a guide, helping us throughout our stint in the company, participating actively in our
development process, providing us with all the facilities, and has done much beyond expectation
to bring out the best in us.
I offer my gratitude to our project guide Prof. H.B. Patel to guide us in the project that have
always encouraged and motivated us providing valuable guidance at each and every phase of our
training .It has been a fascinating learning experience which will always remain etched in our
heart and memory. I am also thankful to Mr. Mukesh Sharma Training and Placement Officer,
L.C.I.T for providing us an opportunity to work with such esteemed organisation. I am also
thankful to Prof.Maulik Chaudhary for his kind support. Our obligations remain to all those
people and friends who have directly or indirectly helped us in successful completion of our
training. No amount of words written here will suffice for our sense of gratitude towards all of
them.

II
ABSTRACT
Student Management system (SMS) part of University Enterprise Resource Planning
(UERP) is a versatile student monitoring solution, which is a virtual one-stop-module that
delivers up-to-the-minute details of every pupil on your rolls -- past and present. Whether you
are looking for a detailed report on every student enrolled in an academic year it gets displayed
instantly on your desktop. Incorporating smart search options, Student Monitor not only provides
a comprehensive database of students but is also an efficient tool to generate certificates and
send mass SMSs or e-mails cost-effectively. Parent/guardian when provided with a Student
Management System log-in ID can also monitor the activities of their ward online, 24x7.
Student Management System (SMS) system is an integrated solution to do all the work in proper
as well as efficient manner and manage the Student details. This system will provide accuracy as
well as efficiency to manage information of all the students of whole University. The system will
preserve all the records and data of Student in digital form and provide online connectivity.
Which allow intended user to connect it gives clear and precise description of all the
functionality of Students so user can access the desired data and collect the required info.

III
LIST OF TABLES
Table No Table Description Page No
Table 1.1 Service offered by company 15
Table 3.1 Basic Info 70
Table 3.2 Course 70
Table 3.3 College Info 71
Table 3.4 Personal Info 72
Table 3.5 Contact Info 73
Table 3.6 Work And Education 74
Table 3.7 Extracurricular 74
Table 3.8 Placement 75
Table 3.9 Conduct 75
Table 3.10 Conveyance 76
Table 3.11 Attendance 76
Table 3.12 Examination 77
Table 3.13 Exam Result 77
Table 3.14 Subject 78
Table 3.15 Fees 78
Table 4.1 Test Case For Login 83
Table 4.2 Test Case For Updating Student Record 84
Table 4.3 Test Case For Getting Examination Records 85
Table 4.4 Test Case For Report & Certificate Generation 86
Table 4.5 Test Case For Mark The Student Generation 87
Table 4.6 Test Case For Update The Student Attendance 88
Table 4.7 Basic HTML Tags 90

IV
LIST OF FIGURES
Figure No Figure Description Page No
Figure 1.1 Divisions of the organization 13
Figure 3.1 A multiple incremental Model 52
Figure 3.2 Multiple releases incremental model 53
Figure 3.3 Timeline chart 55
Figure 3.4 Level 0 Dataflow diagram 57
Figure 3.5 Level 1 Dataflow Diagram 58
Figure 3.6 Level 2 Dataflow Diagram (Student) 59
Figure 3.7 Level 2 Dataflow Diagram (Professor) 60
Figure 3.8 Level 2 Dataflow Diagram (Admin) 61
Figure 3.9 Level 2 Dataflow Diagram (Bank) 61
Figure 3.10 Use case diagram 63
Figure 3.11 Sequence diagram 68
Figure 3.12 Activity diagram 69
Figure 5.1 Homepage of UERP 97
Figure 5.2 Gallery of UERP 99
Figure 5.3 Gallery View 100
Figure 5.4 Achievements 101
Figure 5.5 Login Page 102
Figure 5.6 Dashboard 103
Figure 5.7 Examination Details Page 104
Figure 5.8 Select Semester to see the Result 105
Figure 5.9 Select Exam After Selecting Particular Semester 106
Figure 5.10 Result Displayed 107
Figure 5.11 Select Semester for Checking Schedule 108
Figure 5.12 Select Type Of Exam 109
Figure 5.13 Schedule Displayed 110
Figure 5.14 Attendance 111
Figure 5.15 Fees Details 112

V
Figure 5.16 Select Semester to View Fees Details 113
Figure 5.17 Fees Details Displayed 114
Figure 5.18 Reports & Certificate 115

VI
LIST OF SYMBOLS, ABBREVIATIONS AND NOMENCLATURE
Symbol/Abbreviation Meaning
User A person who provides the data for a computer system, updates the
data, and uses reports from the system in his or her daily work.
User profile User characteristics maintained by the system
Archive To maintain data in a designated repository; in UERP, data will be
maintained in the central database.
Mapping The linkages of two objects, e.g., an outcome to an assessment unit.
SMS Student Management System
UERP University ERP
DBMS Database Management System
SRS Software Requirements Specification
DBA Database Administrator

VII
TABLE OF CONTENTS
Acknowledgement I
Abstract II
List of Tables III
List of Figures IV
List of Symbols/Abbreviations VI
Table of Contents VII
Chapter: 1 Organization Profile 11
1.1 History & Objective 12
1.2 Activities 13
1.3 Facilities & Organizational Structure 15
Chapter: 2 Concept & Fundamental of Project 16
2.1 Study of Existing System 17
2.2 Proposed System 17
2.2.1 Objective 18
2.2.2 Project Definition 18
2.2.3 Project Platform 19
2.2.4 Project Scope & Summary 19
Chapter: 3 System Analysis, Design & Development 22
3.1 System Analysis 23
3.1.1 Problem Definition 23
3.1.2 Fact Finding Techniques 23
3.1.3 Feasibility Study 24
3.1.4 Requirement Specification 25
3.1.5 Process Model 50
3.1.6 Schedule for the Milestone Activities 55
3.2 System Design 56
3.2.1 Software Design Principles 56
3.2.2 Data Flow Design 57
3.2.3 Use-case Diagrams 62

VIII
3.2.4 Sequence Diagrams 68
3.2.5 Activity Diagrams 69
3.2.6 Data Dictionary 70
3.3 Software Development 79
3.3.1 Hardware Interfaces 79
3.3.2 Software Interfaces 79
3.3.3 User Interface 79
3.3.4 Communication interface 80
Chapter: 4 Software Testing & Implementation 81
4.1 Software Testing 82
4.1.1 Software Testing methods 82
4.1.2 Test-cases 83
4.2 Software Implementation 89
4.2.1 Language Concepts 89
4.2.2 Tools/techniques 92
Chapter: 5 User’s Manual & Screen Layouts 95
5.1 User’s Manual 96
5.2 Screen Layouts 97
Chapter: 6 Conclusion 116
6.1 Advantages & Limitations 117
6.2 Future Enhancement 117
6.3 Bibliography/References 118

IX
Student Management System (SMS) – University ERP
A PROJECT REPORT
Submitted by
MEHUL THAKKAR (090290131002)
In fulfillment for the award of the degree
Of
BACHELOR OF ENGINEERING
In
Ta: Visnagar, Dist: Mehsana
Gujarat Technological University, Ahmedabad
April/May, 2013

11
CHAPTER
1 Organizational Profile
Contents
 History & Objectives
 Activities
 Facilities & Organizational Structure
Learning Objectives
This chapter will enable you to understand:
 Companies :
 Profile.
 Work Details.
 Environment.
 Available Facilities.

12
Organization Profile Chapter 1
1.1 History and Objective
 The company
Xcellance Techno Labs Pvt. Ltd. is a biggest IT-giant having its origination from Gujarat
with its office in Northern India looking for further expansion over the globe, offering
application design, development, testing services and asset-based solutions in niche segments
through turnkey projects of civic importance.
Xcellance Techno Labs Pvt. Ltd. over the time has followed a multi-dimensional approach to
support its growth and expansion in becoming a leading player.
With their hard efforts in sync with leading Industries and IT Technocrats they have designed
a special Campus-to-Industry Project Development Programme to improve quality of resource
getting out from the esteemed organisations and increase their competence level so that they are
having easy absorption into the Global Industry Mechanism and reach to the desired spaces with
great pace.
Vision
To be among top 20 Development & Training Organizations of India by 2025.
 Mission
To Innovate world class methodology to equip the new generation to be more hire able and
serve our clients with high end solutions.
 Our values
Openness, Trust, Team Work, Responsibility & Innovation is our key drivers.
 Board of directors

13
Guiding Xcellance Techno Lab’s quest for excellence and global expansion is our eminent
bunch of directors Mr. Rakesh Ray, Mr. Gaurav Makkar & Mr. Dharmesh Bhatt.
Mr. Rakesh Ray with a rich experience of 19 years in Product Management, SOA
Architecture and SaaS, System Analysis & Designing and SDLC in several domains like
Banking & Finance, Manufacturing, Travel and E-Commerce is the Think Tank behind the
organisation. He has been working as Sr. VP Product & Operations with Avani Cimcon
Technologies Inc. Jacksonville, FL, USA., Sr. Java Architect with Volvo Trucks, Greensboro,
NC, USA & Senior Technical Consultant with Premier Alliance Group, Charlotte, NC, USA
Mr. Dharmesh Bhatt with a vivid experience of 19 years into Sales & Marketing and
Training & Development holds entrepreneurial experience of 3 years in USA and Pioneer in
bringing concept of International Team Project Development concept to India.
Mr. Gaurav Makkar with a rich 16 years experience into Software Development and System
Design, Web Content Development, E-Commerce, Technical Writings, E-Journalism and
Trainings is having its expertise into Subject Matter and Educational diversification.
1.2 Activities
 Divisions of the organization
Figure 1.1 Divisions Of The Organization
Directors
Accounting &
Adminstration
Services
Product
Development
Eductaional
Training
QA, QC &
Process

14
 Public & private co. In clientele
1. Godrej & Boyce
2. NIIT Ltd.
3. Apple Technologies
4. CMC Ltd.
5. Tata AIG
6. Kotak Life
7. ICICI Prudential
8. Kotak Bank
9. Standard Charted Bank
10. Citi Bank
11. Uttar Pradesh Finance Corporation (U.P. State Govt. Cooperative)
12. Postal Training Centre (A. wholly owned Govt. Subsidiary)
13. Paradise Group Of Companies
14. Pyramid Software, Noida,
15. Primus Software, Noida
16. Mehsana DudhSagar Dairy, India. (Asia’s Largest Dairy)
 Some global clientele
1. Avani Cimcon Technologies Inc. Jacksonville, FL, USA.
2. CyberThink InfoTech Pvt. Ltd. Ahmedabad
3. Volvo Trucks N.A, Greensboro, NC, USA
4. Premier Alliance Group, Charlotte, NC, USA
5. Datamas Limited, Bahrain. (Business Application & System Integration)
6. United Guaranty (AIG), Greensboro, NC (Mortgage Insurance - Financial)
7. Bank of America, Charlotte, NC, (Formerly Nations Bank) (Financial)
8. United Guaranty (AIG), Greensboro, NC (Mortgage Insurance - Financial)

15
1.3 Facilities & Organizational Structure
 Services we offer
CREATIVE
SOLUTIONS
SOFTWARE
SOLUTIONS
EDUCATION
Web Design &
Development
Website (HTML/Flash)
Accessibility & Usability
Search Engine
Optimization
Banner Design
E-mailers
E-Newsletters
Portal Development
KIOSK Application
MIS
E COMMERCE
CRM
Customized Application
Manufacturing and Retail
ERP
E Learning Software
Faculty Development
Program
Industrial Visits
Industry Training
Specialized training
Develop and maintain
Labs
Table : 1.1 : Services Offered By Company

16
CHAPTER
2
Concept & Fundamental Of
Project
Contents
 Study of Existing System
 Proposed System
 Objective
 Project Definition
 Project Platform
 Project Scope & Summary
Learning Objectives
 Project’s:
 Definition
 Proposed System and its Scope.
 Survey of Some Similar Products.

17
Concept & Fundamental of Project Chapter 2
2.1 Study of Existing System
Student management system is Prime module of University Enterprise Resource
planning (UERP). Before developing our system we have surveyed lots of other
similar products available in market. Few of them are listed below:
 Fedena
 Opensis
 Akura
 Academia
 Slate ERP
 Honey comb School management system
As few of them some are open source which are easily available for free. As there
are few things which will make this existing system even better and flexible to use.
As we are developing UERP, as name suggests it can be used for whole university
whereas this all systems can only use for school management system.
In particular student management system we are adding few new facilities which
will enhances the existing system. These facilities are ID- Card with net banking,
Instant ID-Card generation, Birthday reminder of any student for their group. And it
will keep track to extra-curricular activities of students too.
2.2Proposed System
UERP (University Enterprise Resource Planning) system is an integrated solution to
do the all work in proper as well as efficient manner and manage the University
details. This system will provide accuracy as well as efficiency to manage whole
university information. So this system can reduce manpower. It will provide lots of

18
features like attendance management, examination management, student management,
admission management etc.
In UERP as I am working on Student Management System (SMS), so in this document
we will discuss Student Management System.
2.2.1 Objective
Every Academic Institution attempts to monitor the different academic and non-
academic aspects of the students admitted in the Academic Institution. Most often,
relevant information like medical reports are stored only at specific location like
clinic etc. UERP student Monitor is a resourceful onsite student monitoring module
that integrates all the details of students in Academic Institution. It is an essential one-
stop-module that delivers up-to-the-minute details of every pupil on the roll with
detailed reporting and smart search options.
Student Management system delivers entire details of the student during his/her
academic life in the Academic Institution, beginning from admission time till their
TC is issued. Whatever information you search regarding the student, it will be
displayed instantly on your desktop via this module. Thereby, student monitoring
becomes an easy task and the Academic Institution can send alerts to their parents in
case of any urgency. Fee, medical, attendance, disciplinary and other personal records
can be closely scrutinized through this multi-functional module. The Student Monitor
module allows the management to promote students from one grade/class to the next
one. All available sources of information can be intelligently used for more accurate
estimate of the student profile.[3]
2.2.2 Project Definition
 Student Management System (SMS) In University Enterprise Resource
Planning (UERP).
 Academic institutions are facing the demands of a new environment with:
 Changing student demographics and expectations
 More acute resource constraints
 Greater demands for institutional accountability

19
 While the challenges before educators are daunting, they motivate everyone
involved in education to be more innovative, resourceful and use technology more
effectively to devise new approaches to solve problems.
 The purpose of the Student management system is easy to maintain all the records
and data of Student in digital form and provide online connectivity. Which allow
intended user to connect it gives clear and precise description of all the
functionality of Students so user can access the desired data and collect the
required info.
 This system will be used by students & management of the institute in order to
maintain their own account or to get information of others as well.
2.2.3 Project Platform
The System will be developed by using the following technologies:
 J2EE
 Mysql
2.2.4 Project Scope & Summary
The Student management system contains different modules. They are as below.
2.2.4.1 Student Profile
 Login into or access the user/student account.
 Student profile in detail.
 Modify Student Details.
 Customized student search (Smart Search).
 Maintenance of student housing details.
 Monitor student conveyance details.
 Instant generation of student ID-Card.
 Birthday reminder.
 ID-Card with net banking.

20
2.2.4.2 Student Academic Records
 Detailed reports of former students.
 Handling records of examination, assessments, marks, grades and
academic progression.
 Student promotion can be done with ease.
 Continuous assessment and student monitoring made possible.
 Preparation of student’s academic progress card on selecting the
exams
2.2.4.3 Student Attendance and monitoring
 Maintaining records of absence and attendance (Primarily student’s
classrooms attendance).
2.2.4.4 Admin Tasks
 Recording history of admission.
 Students overall performance, extra-curricular activities.
 Communication with students.
 Maintaining discipline records.
 Tracking the activities and events of the students.
 Data integration and segregation.
 Student status (DLM, Current, Detained, D-to-D).
 Batch generation.
 Roll no. allocation.
 Tailor-made reports
 Issue of certificates.
 Student achievements.
 SMS alerts make communication smarter, efficient and effective.
 Examine student health records.

21
 List of Certificates
 Bonafied certificate
 I-card.
 Character certificate
 Domicile Certificate.
 Migration Certificate.
 Transfer certificate.
 Leaving certificate.
 Transcript.
 Trial Certificate
 List of reports
Reports for the students can be customized for the institute, topics include:
 Conduct report: Behavior in the institute, involved in anti-social activities like
ragging, etc
 Activity report: Participation in games, sports, event management, social activities,
state/nation and international level tests and competitions.
 Leave Reports.
 Performance appraiser report.
 Placement Report: Designation, company, package. [3][4][5]

22
CHAPTER
3
System Analysis Design &
Development
Contents
 System Analysis
 Problem Definition.
 Fact Finding Techniques.
 Feasibility Study.
 Requirement Specification.
 Process Model.
 Schedule for the Milestone
Activities.
 System Design
 Software Design Principles.
 Data Flow Diagrams.
 Use case Diagram.
 Sequence Diagram.
 Activity Diagram.
 Data Dictionary.
 Software Development
 Hardware Interfaces.
 Software Interfaces.
 User Interfaces.
 Communication Interfaces.
Learning Objectives
 System’s:
 Design, Analysis & Development
Conception.

23
System Analysis, Design & Development Chapter 3
3.1 System Analysis
3.1.1 Problem Definition
 Student Management System (SMS) In University Enterprise Resource
Planning (UERP).
 While the challenges before educators are daunting, they motivate everyone
involved in education to be more innovative, resourceful and use technology more
effectively to devise new approaches to solve problems.
 The purpose of the Student management system is easy to maintain all the records
and data of Student in digital form and provide online connectivity. Which allow
intended user to connect it gives clear and precise description of all the
functionality of Students so user can access the desired data and collect the
required info.
 This system will be used by students & management of the institute in order to
maintain their own account or to get information of others as well.
3.1.2 Fact Finding Techniques
For Finding Facts & Problems Regarding this system I have walk through several
techniques as explained below:
 Brainstorming- Unstructured.
I have discussed the problem in informal discussion of friends and found some
of the existing problems and technique for its mitigation.
 Focus group- structured.
I have discussed the same problem in formal discussion with all our faculties.
 Interview:
 One-to-one

24
For finding Facts and problems I have interviewed all the HOD’s and
Convener of Examination Department & Student Section.
 Group.
I have interviewed group of students regarding system.
 Questionnaire (Survey Part)
I have prepared Questionnaire for surveying problems as some of them are
listed below:
 What type of system you need?
 What type features makes this system better?
 What are the functionalities you think this system need to provide?
 JAD(Joint application development)
 Collaborative work.
 Better understanding of system
3.1.3 Feasibility Study
Once the problem is clearly understood, the next step is to conduct feasibility
study, which is high-level capsule version of the entered systems and design process. The
objective is to determine whether or not the proposed system is feasible. The three tests
of feasibility have been carried out.
 Technical Feasibility
 Economical Feasibility
 Operational Feasibility
3.2.3.1 Technical feasibility
In Technical Feasibility study, one has to test whether the proposed system can be
developed using existing technology or not. It is planned to implement the proposed system
using java technology. It is evident that the necessary hardware and software are available for
development and implementation of the proposed system. Hence, the solution is technically
feasible.
3.2.3.2 Economical feasibility
As part of this, the costs and benefits associated with the proposed system compared and
the project is economically feasible only if tangible or intangible benefits outweigh costs.

25
The system development costs will be significant. So the proposed system is economically
feasible.
3.2.3.3 Operational feasibility
It is a standard that ensures interoperability without stifling competition and
Innovation among users, to the benefit of the public both in terms of cost and service
quality. The proposed system is acceptable to users. So the proposed system is
operationally feasible.[7]
3.1.4 Requirement Specification
3.1.4.1 System Features & Functional Requirements
3.1.4.1.1 Recording History of Admission
 Description and Priority
 The user will insert/enter the required info.
 The Administrator will save all the info. In the central database.
 As the priority of this feature is high.
 Stimulus or Response Sequence
Use Case: Recording History of Admission
Actor: User, Administrator, Database
Scenario:
1. The user enters the required info.
2. The user will save the required info. To the database.
3. The administrator will verify the info.
 Functional Requirements
[SRSreq 01] User needs to provide all the required info.
[SRSreq 02] User can modify only authorized info.
[SRSreq 03] User can’t enter invalid inputs.
[SRSreq 04] User can download his info.
[SRSreq 05] User can save his info.

26
[SRSreq 06] User can cancel the database transaction.
3.1.4.1.2 Login/Access user account
 The user can access the account by using unique Login name/ID and Password.
Use Case: Login/Access user account
Actor: User, Database
Scenario:
1. The user enters a login name.
2. The user enters a password.
3. The local database confirms the password through the local database.
[SRSreq 07] User needs to provide correct Login Name.
[SRSreq 08] User needs to provide correct password.
3.1.4.1.3 View student profile
 The user can access all the information of particular student by entering their
unique identification no.
Use Case: View Student Profile
Scenario:
1. The user will enter the unique identification no.
2. The user detail is displayed on screen from database.

27
[SRSreq 09] The user needs to enter correct identification no.
[SRSreq 10] The user can only view the details of other user but can’t modify or delete
it.
3.1.4.1.4 Customized Student Search
 The user can search by defining several other fields.
Use Case: Customized Student Search.
Scenario:
1. The user will enter unique identification no.
2. The user will define several fields for customized search.
3. The user will enter the required info. For search.
4. The results will be displayed on screen from database.
[SRSreq 11] The user needs to enter correct identification no.
[SRSreq 12] The user needs to enter correct info. In customized search field.
3.1.4.1.5 Data integration and segregation
 The data stored in the database are incorporated and segregate.
Use Case: Data integration and segregation
Actor: Administrator, Database
Scenario:

28
1. The administrator request for integration of data.
2. The updated is reflected in database.
3. The administrator request for segregation of data.
4. The update is reflected in database.
[SRSreq 13] The administrator needs to maintain database consistency.
3.1.4.1.6 Generation of ID cards
 This system is useful for generating student ID card on demand.
Use Case: Generation of ID-Card.
Scenario:
1. The user will login to his account.
2. The database will allow user to login.
3. The user will click on generate user ID.
4. The database will print the user ID.
[SRSreq 14] The user needs to enter correct user name.
[SRSreq 15] The user needs to enter correct password.
3.1.4.1.7 Report generation
 The user can use this system to view, download and print necessary reports.

29
Use Case: Report Generation
Scenario:
1. The user/administrator will request for particular report.
2. The user/administrator will enter required info. For generating
reports.
3. The administrator will approve user’s request.
4. The database will generate the report.
5. The user/administrator will view, download or print the report.
[SRSreq 16] User needs to provide correct info.
[SRSreq 17] For some reports user need to have administrator permission.
[SRSreq 18] User can view, print or download his own reports.
3.1.4.1.8 Alerts
 This system is used to notify user for any alerts via e-mail/sms.
 The priority of this feature is medium.
Use Case: Alerts
Actor: User, Administrator
Scenario:
1. The administrator will create a message for users.
2. The administrator will enter list of users to send alerts.
3. The administrator will send the message.

30
[SRSreq 19] The administrator needs to have unique identification no. of all the users
who he wants to notify.
3.1.4.1.9 Communication with students
 This system is used for communication among user as well as in between user and
administrator.
 As the priority of this system is medium.
Use Case: Communication With Students.
Actor: User, Administrator
Scenario:
1. The user/administrator will enter the unique ID of the other user whom
he/she wants to communicate.
2. The connection is established between two users/administrator.
3. The user/administrator will send message to other user.
4. The user will respond it.
5. The loop will be continuing.
6. The user/administrator will close the chat.
7. The connection is terminated.
[SRSreq 20] The user needs to have unique ID of the other user whom he wants to
connect.
[SRSreq 21] The user must have authority to connect to a particular user.
3.1.4.1.10 Handling records
 The user and administrator will use this system to keep all the records of user.

31
Use Case: Handling Records
Actor: User, Database, Administrator
Scenario:
1. The user/administrator will select particular record.
2. The database will display the results.
3. The user/administrator will be able to view, download or print the reports.
[SRSreq 22] The user can only view, modify or delete the authorized records only.
3.1.4.1.11 Batch generation
 The administrator will generate several batches of students who have enrolled for
particular courses.
Use Case: Batch Generation
Scenario:
1. The administrator will select particular course from database.
2. The administrator will select unique no. fields of all the students.
3. The administrator will divide all the students in several batches.
4. The administrator will save the changes to the database.
[SRSreq 23] The course must have required amount of students.
[SRSreq 24] The administrator should create batch in every courses.

32
3.1.4.1.12 Student Status
 This system is useful to know the student status weather he is current student,
detained or Distance learning mode student.
Use Case: Student Status
Scenario:
1. The user will request the system to know about his/her status.
2. The database will display the results.
3. The administrator will request for status of any user.
4. The administrator will enter the unique ID of user.
5. The database will display the status of required user.
[SRSreq 25] User is must enrolled in the database.
[SRSreq 26] The administrator needs to enter correct unique Id of user.
3.1.4.1.13 Issue of certificates
 This system is used to issue certificate to particular user.
 There are several types of certificate which can be allocated to the user (Student).
Use Case: Issue of Certificates
Actor: Administrator, User, Database
Scenario:

33
1. The user will request for particular certificate.
2. The administrator will generate the certificate according to availability of
respective data in the database.
3. The certificate will be allocated the user.
[SRSreq 27] User record must be present in database.
[SRSreq 28] User needs to pay fees amount for more than one certificate as per terms
and condition of particular academic institution.
[SRSreq 29] System needs to generate fees receipt for more than one certificate as per
terms and condition of particular academic institution.
3.1.4.1.14 Modify student details
 This system is useful to update the user information.
 As the priority of this system is high.
Use Case: Modify Student Details
Scenario:
1. The user will enter user name.
2. The user will enter password
3. The user will request to change his info.
4. The user will update his info.
5. The info. Will be stored in database.
[SRSreq 30] User needs to enter correct user name.
[SRSreq 31] User needs to enter correct password
[SRSreq 32] User can modify only those details which he is allowed to do.

34
[SRSreq 33] User can’t modify detail of any other user.
3.1.4.1.15 ID-Card with net banking
 This system will allow user to have ID card with net-banking facilities, so that
user can purchase anything inside or outside the campus by using it.
 As the priority of this system is low.
Use Case: ID-Card with net banking
Actor: User, Administrator, Database, bank
Scenario:
1. The user will login into the system.
2. The user will request for net banking enabled ID-Card.
3. The administrator will verify user details from database.
4. The administrator will forward the request to bank.
5. The bank will respond to the administrator
6. The administrator will issue net banking enabled ID-Card to user.
[SRSreq 34] The user must have all the required documents needs to have bank account.
[SRSreq 35] The user needs to follow all the terms and condition of bank as well as
academic institution.
[SRSreq 36] The user should have valid unique identification no.
3.1.4.1.16 Placement reports
 This system is used to generate reports related to training and placement details of
the students.
 This system will keep all the details regarding training and placement of all the
students’ in particular academic institution.

35
Use Case: Placement Reports
Scenario:
1. The user/administrator will request the database for placement report.
2. The database will respond with the report.
[SRSreq 37] The user can only generate his own placement report.
[SRSreq 38] The administrator can generate reports of all the students.
3.1.4.1.17 Performance appraiser report
 This system will generate the performance related report.
 As this report is used to appreciate student according to their performance.
 This can be generated by administrator/user and send it to user.
Use Case: Performance appraiser reports
Actor: Administrator, User, Database
Scenario:
1. The administrator/user will request for the performance appraiser report.
2. The database will generate performance appraiser report on the basis of
available details.
3. The administrator/user will send the report to the user (student).
[SRSreq 39] Student can’t generate performance appraiser report.

36
[SRSreq 40] The user who can generate report must be instructor, professor, lecturer,
counselor or HOD.
3.1.4.1.18 Conduct reports
 This system is used to keep track to student behavior in the institution.
Use Case: Conduct Report
Scenario:
1. The administrator/user will request for the conduct report.
2. The database will generate conduct report on the basis of available details.
3. The administrator/user will send the report to the user (student).
[SRSreq 41] Student can’t generate performance appraiser report.
[SRSreq 42] The user who can generate report must be instructor, professor, lecturer,
counselor or HOD.
3.1.4.1.19 Leave report
 This system is used by user to generate user leave reports.
Use Case: Leave Report
Scenario:
1. The user will create Leave Report.

37
2. The user will send leave report to the administrator/user.
3. The administrator will save the report in the database of particular student.
[SRSreq 43] The student user can forward his leave report to his particular counselor.
[SRSreq 44] The student can generate two types of leave reports.
 For approval
 Acknowledgement report.
3.1.4.1.20 Activity report
 This system will keep all the info. Related to student activities, extra-curricular
achievements etc.
Use Case: Activity Report
Scenario:
1. The user will login to the system.
2. The user will request for activity report.
3. The user will enter the particular time duration to generate report.
5. The administrator will login to the system.
6. The administrator will request for activity report generation.
7. The administrator will select the student(s).
8. The administrator will enter the particular time duration.

38
[SRSreq 45] The user can generate, print or download the reports.
[SRSreq 46] The user can update his new activities in the database.
[SRSreq 47] The administrator/user needs to verify the updated activities.
[SRSreq 48] The administrator/user will store the verified activities in the database.
3.1.4.1.21 Attendance records
 This system is used to maintain all the attendance related details of the
students.
 As this module is linked with attendance management system.
Use Case: Attendance Records
Actor: User, administrator, database
Scenario:
1. The user will request database for attendance record.
2. The database will respond with attendance records.
3. The administrator with request for attendance records.
4. The database will respond with attendance records.
5. The administrator can view, modify or delete the records.
[SRSreq 49] The user (Student) can’t modify his attendance details.
[SRSreq 50] The administrator can view, delete or modify the attendance details.
3.1.4.1.22 Discipline records

39
 This system is used to maintain all the discipline records of user (Student) we can
produce conduct report on the basis of this records.
Use Case: Discipline Records
Scenario:
1. The user/administrator will request for discipline records.
2. The database will display discipline records.
[SRSreq 51] The user can only view the records.
3.1.4.1.23 Extracurricular activities
 This system is used to keep detail info. Of Extra-curricular activities of the students.
 This system is used to generate activity report.
Use Case: Extra-Curricular activities
Scenario:
1. The user/administrator will request for extra-curricular activities records.
2. The database will display the extra-curricular activity records.
3. The user can view the records.
4. The user can request administrator to modify or delete the extra-curricular
activity.
5. The administrator will approve the modification from user.
6. The user saves the user modification to the database.

40
[SRSreq 52] The user can’t update or delete his extra-curricular activity detail without
approval from administrator.
[SRSreq 53] The user can cancel the update request sent to administrator for approval.
3.1.4.1.24 Health records
 This system will keep all the health related records of the user.
Use Case: Health Records
Scenario:
1. The user will request database for health record.
2. The database will respond with health records.
3. The administrator with request for health records.
4. The database will respond with health records.
5. The administrator can view, modify or delete the records.
[SRSreq 54] The user can update his health record.
[SRSreq 55] The administrator can view health records of any no. of students.
3.1.4.1.25 Bonafied
 This system is used to generate Bonafied certificate as per the requirement of the
user.

41
Use Case: Bonafied
Scenario:
1. The user will request for Bonafied certificate.
2. The administrator will approve the users request and generate the
Bonafied certificate.
[SRSreq 56] The user status must not be detained.
3.1.4.1.26 Domicile
 This system will generate Domicile certificate of user on the basis of availability of
information in the database.
Use Case: Domicile
Scenario:
1. The user will request for Domicile certificate.
Domicile certificate.
[SRSreq 57] The user can’t generate Domicile certificate without approval from
administrator.
3.1.4.1.27 Character
 This system is used to generate character certificate of the user.
 As this system use the conduct record to generate Character Certificate.

42
Use Case: Character Certificate
Scenario:
1. The user will request for Character Certificate.
2. The administrator will verify all the details of conduct records.
3. The administrator will generate Character Certificate.
[SRSreq 58] The Character certificate can’t be generated without approval of
administrator.
3.1.4.1.28 Migration
 This system is used to generate Migration certificate of the user.
Use Case: Migration Certificate
Scenario:
1. The user will request for Migration certificate.
Migration certificate.
[SRSreq 59] The user can’t generate Migration certificate without approval from
administrator.

43
3.1.4.1.29 Transfer
 This system is used to generate Transfer certificate of the user.
Use Case: Transfer Certificate
Scenario:
1. The user will request for Transfer certificate.
2. The administrator will approve the users request and generate the Transfer
certificate.
[SRSreq 60] The user can’t generate Transfer certificate without approval from
administrator.
3.1.4.1.30 Leaving
 This system is used to generate Leaving certificate of the user.
Use Case: Leaving Certificate
Scenario:
1. The user will request for leaving certificate.
2. The administrator will approve the users request and generate the Leaving
certificate.

44
[SRSreq 61] The user can’t generate Leaving certificate without approval from
administrator.
3.1.4.1.31 Transcript
 This system is used to generate Transcript certificate of the user.
 This system will take all the details from examination department and generate
transcript.
Use Case: Transcript
Scenario:
1. The user will request for Transcript
2. The administrator will approve the request.
3. The administrator will generate transcript of user by using examination
details.
[SRSreq 62] The user can generate tentative transcript by using information from
database without approval of administrator for his convenience.
3.1.4.1.32 Trial
 This system is used to generate Trial certificate of the user.
 This system will take all the details from examination department and generate trial
certificate.
Use Case: Trial

45
Scenario:
1. The user will request for Trial Certificate
2. The administrator will approve the request.
3. The administrator will generate trial certificate of user by using
examination details.
[SRSreq 63] The user can’t generate Trial certificate without approval from
administrator.
3.1.4.1.33 Student housing details
 This system will keep track to all the details of student’s accommodation that are
living in hostels.
 As this system use all the details of hostel management system.
Use Case: Student Housing Details
Scenario:
1. The User/Administrator request for the housing details of User.
2. The database responds with the housing details of particular student.
3. The user/administrator can view, modify, and delete several records on the
basis of their permissions.
[SRSreq 64] This system will only work for those users who are living in hostels.
[SRSreq 65] User can view all the details regarding him but can modify only authorized
fields.

46
3.1.4.1.34 Birthday reminder
 This system will notify user about birthday of subscribed/selected users.
 As the priority of this system is low.
Use Case: Birthday Reminder
Scenario:
1. The user will select other users.
2. The System will notify the user on birthday of selected users.
[SRSreq 66] System will only notify about those user that are selected from beginning.
[SRSreq 67] By default system will notify user about his batch mates.
3.1.4.1.35 Student conveyance details
 This system will keep track to all the details of student’s Transportation that are
travelling in institution vehicles.
 As this system use all the details of Transportation management system.
Use Case: Student Conveyance Details
Scenario:
1. The User/Administrator request for the conveyance details of User.
2. The system responds with the conveyance details of particular student by
using information stored in database.

47
3. The user/administrator can view, modify, and delete several records on the
basis of their permissions.
[SRSreq 68] This system will only work for those users who are travelling in
institutions vehicle.
[SRSreq 69] User can view all the details regarding him but can modify only authorized
fields.
3.1.4.1.36 Assessment
 This system is used for assessment of user.
 As this system is linked with/Part of examination management system.
Use Case: Assessment
Scenario:
1. The user will request for assessment or evaluation of his performance.
2. The system will communicate with the examination management system
and respond with results.
3. The administrator will verify results.
4. The system will display the results.
[SRSreq 70] The user must have some examination details.
3.1.4.1.37 Mark sheet generation
 This system is used to generate mark sheet of examination as per user convenience.

48
 As the system is linked with examination management system and use all the
information stored in it to generate mark sheets.
Use Case: Mark sheet Generation
Scenario:
1. The user will request for mark sheet.
2. The user will select no. of exams to generate the mark sheets.
3. The system will generate mark sheet by using available info. In the
database.
[SRSreq 71] The user can select no. of examination to generate mark sheet.
[SRSreq 72] The user should have given the exam which he is selecting to generate the
mark sheet.
3.1.4.1.38 Roll no allocation
 This system is used to allocate the roll no. to the users.
 After batch generation the administrator will allocate roll no. to all the users.
Use Case: Roll no. allocation
Scenario:
1. The administrator will request the list of students.
2. The system will respond with list of students.
3. The administrator will allocate unique no. to all of them in single batch.

49
[SRSreq 73] The student should have selected some course.
[SRSreq 74] The roll no. must be creating by considering student status.
3.1.4.2 Behavioral Requirements
3.1.4.2.1 Same Class of User
The general user is the only type of user of the system; however, to use the system the user
must be authorized to access information. The requirements in this section address
authorization and access issues.
[SRSreq 75] The first time, a user logs into Student Management System (UERP), the
system will ask the user to enter a new password.
[SRSreq 76] Only authorized users are allowed to login and, will be able to view, modify,
or delete their information.
3.1.4.3 Non-behavioral Requirements
3.1.4.3.1 Security
[SRSreq 77] Each time there is a security violation, the log file will be updated with the
login, date, and time.
[SRSreq 78] Each time user login details will be maintained in log file with login date,
time and duration.
3.1.4.3.2 Maintainability
[SRSreq 79] The system will be designed to allow the following changes:
 Reports consisting of plots and graphs
 Administration of accounts, Student Management System outcomes, mapping of
Student Management System outcomes.
 Database queries
 Administration of Database
 Archive files to central database

50
3.1.4.3.3 Portability
[SRSreq 80] The system will run on multiple platforms, in particular Windows.
3.1.4.3.4 Design and Implementation Constraints
[SRSreq 81] The system will be designed for the following future extensions:
 Archive user information.
 Use of existing information as template for creation of new features.
 Administration of database
 Student access
 Attendance calculation
 Student examination format
 Student Grade format
 Student mark sheet generation format
 Prorated grade calculation
3.1.4.4 Other Requirements
This section includes requirements relating to database structures and operations, any
special operations required by the user, and any installation or software portability issues.
3.1.4.4.1 Database
This section describes requirements associated with a database. The database schema will
be provided at a later date.
[SRSreq 82] All information created, modified, or deleted through Student Management
System will be stored in the database.
3.1.5 Process Model
The objective of software project planning is to provide a framework that enables the
manager to make reasonable estimates of resources, cost and schedule.

51
These estimates are made within a limited time frame at the beginning of the software
project and should be updated regularly as the project progresses.
The planning objective is achieved through a process of information discovery that leads
to reasonable estimates.
3.1.5.1 Project Development Approach and Justification
Main steps following project development consisted of Analysis, Designing,
Implementation and Testing. The goal of any development effort is to produce some
product.
A development process is a set of activities, together with an ordering relationship
between activities, which if performed in a manner that satisfies the ordering relationship,
will produce the desired product.
A process model is an abstract representation of a development process. In a software
development effort, the goal is to produce high quality software. The development process
is, therefore, the sequence of activities that will produce such software.
A software development process model specifies how these activities are organized in
the entire software development effort. The purpose of specifying a development process
model is to suggest an overall process for developing software.
Following are the types of software models.
 The Linear Sequential Model (Waterfall Model)
 The Iterative waterfall Model
 The Prototyping Model
 The Rapid Application Development (RAD) Model
 The Incremental Model
 The Spiral Model
 The WINWIN Spiral Model

52
 Incremental Model
The incremental model may be viewed as a modification to the waterfall model. As
software projects increased in size, it was recognized that is much easier, and sometimes
necessary to develop the software if the large projects are subdivided into smaller
components, which may thus be developed incrementally and iteratively. In the early days,
each component followed waterfall process model, passing through each step iteratively. In
the incremental model the component were developed in an overlapping fashion, as shown
in figure 1. The component all had to be integrated and then tested as whole in a final system
test. The incremental model provided certain amount of risk containment. If any one
component ran into trouble, the other components were able to still continue to be developed
independently.
Figure : 3.1 : A Multiple Incremental Model
Unless the problem was a universal one such as the underlying technology being faulty,
one problem would not hold up the entire development process.
Another perspective in utilizing the incremental model is to first develop the ―core‖
software that contains most of the required functionality. The first increment may be
delivered to users and customers as release 1. Additional functionality and supplemental

53
features are then developed and delivered separately as they are completed, becoming
Release 2, Release 3, and so on. Utilizing the incremental model in this fashion provides an
approach that is more akin to an evolutionary software product development. When utilized
in this development mode, the model in figure 1 would not have the integration bucket.
The incremental model in figure 1 would have individual releases. For example,
Requirement 1 would be the core functionality release. Other requirement would each depict
different deliveries scenario where the first release, Release 1, is the core function, followed
by subsequent release that may include fixes of bugs from previous releases along with new
functional features. The multiple release incremental models also make it possible to evolve
the first release, which may have flaws, into an ideal solution through subsequent releases.
Figure : 3.2 : Multiple Releases Incremental Model
Thus it facilities evolutionary software development and management, a model that has
been advocated by many, especially by tom Glib who has written recently about the ―evo‖
process (2004). The number of releases for a software project will depend on the nature and
goals of the project. Although each release is independently built, there is a link between
releases because the existing design and code of the previous release is the basis upon which
future release are built.
Both incremental models utilize the ―divide and conquer‖ methodology where a large,
complex problem is decomposed into parts. The difficulty with this model is that such
problems are also intertwined, making the decoupling of the parts into independently
implementable components difficult. It will require a deep understanding of the problem, the
solution, and the usage environment. Overlapping the different increment is another area of

54
difficulty in that there may be some amount of sequential dependency of information among
the components. How much overlapping can take place depends on how much prerequisite
information is required.[7]

55
3.1.6 Schedule for the Milestone Activities
Figure : 3.3 : Timeline Chart

56
3.2 System Design
3.2.1 Software Design Principles
Software design principles represent a set of guidelines that helps us to avoid having a
bad design. The design principles are associated to Robert Martin who gathered them in
"Agile Software Development: Principles, Patterns, and Practices".
According to Robert Martin there are 3 important characteristics of a bad design that
should be avoided:
 Rigidity - It is hard to change because every change affects too many other parts of the
system.
 Fragility - When you make a change, unexpected parts of the system break.
 Immobility - It is hard to reuse in another application because it cannot be
disentangled from the current application.
The decision to implement system functionality using software is one that is typically
made during system design. Software requirements are typically derived from the overall
system requirements and design for those aspects in the system that are to be implemented
using software.
There are user needs and intended uses for a finished device, but users typically do not
specify whether those requirements are to be met by hardware, software, or some
combination of both. Therefore, software validation must be considered within the context
of the overall design validation for the system.
A documented requirements specification represents the user's needs and intended uses
from which the product is developed. A primary goal of software validation is to then
demonstrate that all completed.
Software products comply with all documented software and system requirements. The
correctness and completeness of both the system requirements and the software
requirements should be addressed as part of the design validation process for the device.
Software validation includes confirmation of conformance to all software specifications
and confirmation that all software requirements are traceable to the system specifications.

57
Confirmation is an important part of the overall design validation to ensure that all
aspects of the medical device conform to user needs and intended uses.
3.2.2 Data Flow Diagram
Figure : 3.4 : Level 0 Dataflow Diagram

58
Figure : 3.5 : Level 1 Data flow Diagram

59
Figure : 3.6 : Level 2 Dataflow Diagram (Student)

60
Figure : 3.7 : Level 2 Dataflow Diagram (Professor)

61
Figure : 3.8 : Level 2 Dataflow Diagram (Admin)
Figure : 3.9 : Level 2 Dataflow Diagram (Bank)

62
3.2.3 Use-case Diagrams
This will illustrates organizing the functional requirements for the project by system features and
the major services provided by the project.
Note: All the features of the project are divided in to 3 priorities; HIGH, MEDIUM, LOW
according to their functional requirement dependencies.
3.2.3.1 User Characteristics
The main user of Student Management System is the general user which we named as simply
USER. She/he is the person who is primarily using the system, because the system will have a
GUI with a standard format, the general user will not need to have a high level of technical
expertise.
The following subsections present the Use-Case model for Student Management System. After
presenting the use-case diagram, the section describes the actors and use cases.

63
3.2.3.2 Use-Case Diagram
/
Figure : 3.10 : Use Case Diagram

64
3.2.3.3 Actors
Student Management System classifies the actors of the system into three groups:
User: The user can enter data into the system, search other details, archive data, and view several
reports which he/she can access, and the user can be Student, Professor and any management
person.
Database: The database is responsible for storing data. The central database is an external entity,
which is used to store the data.
Administrator: The Administrator is user who is managing all the records and responsible for
successful run of the system.
Bank: The Bank will enable the net-banking feature and integrate it with student ID-Cards.[1][3]
3.2.3.4 Use-Case Descriptions
The following is a list of the use cases that have been developed for the Student Management
System:
 Recording history of admission: The administrator will use this to keep track on
admission activities of students.
 Login/ access user accounts: The user can Login and access their account by using unique
ID & Password.
 View student profile: The user will use this system to view profile of any other user.
 Customized student search: The user will use this system to search any other user as it
will provide smart search i.e. we can search any user by specifying search criteria.
 Data integration and segregation: This system will be used by administrator in order to
integrate and segregate the data or database.
 Generation of ID cards: The user and administrator will use this system to generate their
ID cards on demand, even it will allow user to print it on the spot.
 Report generation: The user can use the system to display, print, or download a
predefined report to the database.

65
 Alerts: The administrator will use this system to notify user or to send any alerts to
students.
 Communication with students: The administrator will use this system to communicate
with the students.
 Handling records: The system will be used by administrator and user to keep all the
records of user which are archived in database.
 Batch generation: The administrator will use this system for generation of batches of the
student after the user will select particular course.
 Student status: The user and administrator will use this system to know the status of the
system.
 Issue of certificates: The user and administrator will use system to generate several
certificates.
 The use cases that are associated with an include relationship are as follows:
 Modify student details: The user will use this system to update their information
including Password.
 ID-Card with net banking: As this is our future scope of development, the ID Cards of
user built with the net banking feature which enables her/him to use it for any purchase
inside the campus.
 Placement reports: The user and administrator will use this system for generation of
placement related details from database.
 Performance appraiser report: The user and administrator will use this system to generate
performance report of the student from database.
 Conduct reports: The user and administrator will use this system to generate the conduct
report of the students from database.
 Leave report: The user and administrator will use this system to generate the leave report
of the system from database.
 Activity report: The user and administrator will use this system to generate the activity
report of the system from database. This will keep all the info. Of student related to
student activities extra-curricular activities etc.

66
 Examination records: The user and administrator will use this system to keep all the
examination related records in the database like exams, grades, assessments, mark sheet
generation.
 Attendance records: The user and administrator will use this system to keep all the
records of student attendance in database which is available in several formats.
 Discipline records: The user and administrator will use this system to keep all the
discipline records of the student and maintain them in database.
 Extracurricular activities: The user and administrator will use this system to keep track to
all the activities of user including curricular and extracurricular activities and keep all the
records in database.
 Health records: The user and administrator will use this system to keep health records of
students which will be stored in database
 Bonafied: The user and administrator will use this system to generate Bonafied certificate
of the student.
 Domicile: The user and administrator will use this system to generate domicile certificate
of the student.
 Character: The user and administrator will use this system to generate character
certificate according to the availability of student discipline record available in the
database.
 Migration: The user and administrator will use this system to generate migration
certificate of the student as per request of the student.
 Transfer: The user and administrator will use this system to generate transfer certificate
of the student when demanding by student.
 Leaving: The user and administrator will use this system to generate Leaving certificate
of student when demanding by student or after the completion of the course or degree.
 Transcript: The user and administrator will use this system to generate Transcript of
student when needed.
 Trial: The user and administrator will use this system to generate Trial certificate of
student as and when needed.

67
 The use cases that are associated with an extend relationship are as follows:
 Student housing details: The user and administrator will use this system to keep housing
details of the students as it will use the information from hostel management system.
 Birthday reminder: The user will use this system to know the upcoming birthday of their
classmates of colleagues.
 Student conveyance details: The user and administrator will use this system to keep
conveyance details of the student as it will use the information from transportation
management system.
 Assessments: The user and administrator will use this system for evaluation of student.
 Mark sheet generation: The user and administrator will use this system to generate Mark
sheet of student from the data stored in the database, as and when student need it.
 Roll no allocation: The user and administrator will use this to allocate roll no. to all the
students who are enrolled in particular Courses.

68
3.2.4 Sequence diagrams
Figure : 3.11 : Sequence Diagram

69
3.2.5 Activity Diagrams
Figure : 3.12 : Activity diagram

70
3.2.6 Data Dictionary
3.2.6.1 Basic_Info
Basic_Info
Field Name Field
Type
Field
Size
Remark Table Description
Student_Registration_No Varchar2 15 From Admission Management
system, Primary Key
This is basic table containing
basic information as shown in
tableStudents_admission_Date Date Admission Management System
Student_Enrolment_no. Varchar2 15 Foreign Key
Admission_Status Varchar2 30 Admission Management System
Admission_Category Varchar2 30 From Admission Management
System, not null
Table 3.1 Basic Info
 Actor Interaction
 As System will interact with User When User is applying for his/her
Enrolment in Particular College/Course.
 System will allocate Registration No.
 After successful Enrolment of student the administrator will assign
Enrolment no to the students.
3.2.6.2 Course
Course
Field Name Field
Type
Field
Size
Remark Table Description
Student_Enrolment_no varchar2 20 Foreign key This table Containing All the
information regarding Courses
Offered by University
Course_Code Number 10,3 Primary Key
Name varchar2 50 filled by admin
Description varchar2 1000 filled by admin
Duration Date filled by admin
Table 3.2 Course
 Admin will add number of courses, which will be selected by any student.
 When Student will select particular course, it will be reflected in Database.

71
3.2.6.3 College_Info
College_info
Field Name Field
Type
Field
Size
Remark Table
Description
Student_Enrolment_no Varchar2 20 Foreign Key This Table
Contains All
The information
about all the
colleges
affiliated to
University
College_no Number 20 Primary key
College_name Varchar2 30 From Admission Management System, not null
College_category Varchar2 20 SFI/Grant-in-aid
address Varchar2 50 From Admission Management System, not null
City Varchar2 50 From Admission Management System, not null
Dist Varchar2 50 From Admission Management System, not null
State Varchar2 50 From Admission Management System, not null
Country Varchar2 50 From Admission Management System, not null
Postal_Code Varchar2 10 From Admission Management System, not null
E-Mail_Address Varchar2 50 From Admission Management System, not null
Website Varchar2 50 From Admission Management System, not null
Table 3.3 College Info
 Admin will add number of colleges in the university Database, which will be
selected by any student.
 When Student will select particular college, it will be reflected in Database.

72
3.2.6.4 Personal_Info
Personal_Info
Field Name Field
Type
Field
Size
Remark Table
Description
Student_Enrolment_no Varchar2 15 From Admission Management system, Primary Key This Table
Contains all the
Personal
information of
Particular
Student
Student_First_Name Varchar2 30 From Admission Management System, not null
Student_Middle_Name Varchar2 30 From Admission Management System
Student_Last_Name Varchar2 30 From Admission Management System
Father_First_Name Varchar2 30 From Admission Management System, not null
Father_Middle_Name Varchar2 30 From Admission Management System
Fathers_Last_Name Varchar2 30 From Admission Management System
Mother_First_Name Varchar2 30 From Admission Management System, not null
Mother_Middle_Name Varchar2 30 From Admission Management System
Mother_Last_Name Varchar2 30 From Admission Management System
Gender Varchar2 7 From Admission Management System, not null
Date_Of_Birth Date From Admission Management System, not null
Religion Varchar2 30 From Admission Management System, not null
Father_Occupation Varchar2 30 From Admission Management System
Mother_occupation Varchar2 30 From Admission Management System
Relationship_Status Varchar2 30 From Admission Management System
Hobbies Varchar2 50 From Admission Management System
Area_of_interest Varchar2 50 From Admission Management System
Mother_Tongue Varchar2 30 From Admission Management System
Language Varchar2 30 From Admission Management System
Nationality Varchar2 30 From Admission Management System
Hometown Varchar2 30 From Admission Management System
Birth_Place Varchar2 4 From Admission Management System
Blood_Group Varchar2 30 From Admission Management System, not null
Health_Description Varchar2 500 From Admission Management System
Student_Photograph blob 4 GB From Admission Management System
Table 3.4 Personal Info
 Student will enter his/her personal information.
 Information will be stored in database.

73
3.2.6.5 Contact_Info
Contact_Info
Field Name Field
Type
Field
Size
Remark Table
Description
Student_Enrolment_No Varchar2 15 From Admission Management System, Foreign key This table
Contains all the
contact
Information of
Student
Student_Contact_No Varchar2 20 From Admission Management System, not null
Residence_no Varchar2 20 From Admission Management System
Emergency_Contact_No Varchar2 20 From Admission Management System, not null
Student_E-Mail_ID Varchar2 50 From Admission Management System, not null
Fathers_E-Mail_ID Varchar2 50 From Admission Management System
Mothers_E-Mail_ID Varchar2 50 From Admission Management System
Current_Address Varchar2 100 From Admission Management System, not null
Permanent_Address Varchar2 100 From Admission Management System
City Varchar2 50 From Admission Management System
Dist Varchar2 50 From Admission Management System
State Varchar2 50 From Admission Management System
Country Varchar2 50 From Admission Management System
Postal_Code Varchar2 10 From Admission Management System
Mail_Address Varchar2 100 From Admission Management System, not null
Student_Screen_Name Varchar2 50 Entered by student
Students_Website Varchar2 50 Entered by student
Table 3.5 Contact Info
 Student will enter his/her Contact information.

74
3.2.6.6 Work_Education
Work_Education
Field Name Field Type Field Size Remark Table Description
Student_Enrolment_no Varchar2 20 Foreign key This Table Contains All
The information of
Students Work
Experience and
Education
Education_Level Varchar2 100 Entered by student
Any_other_Course Varchar2 100 Entered by student
Course_Duration Date Entered by student
Institute_Name Varchar2 200 Entered by student
Grade Varchar2 5 Entered by student
Work_Experience Varchar2 200 Entered by student
Student_Status Varchar2 20
Current_Semester Varchar2 10 Entered by student, not null
Table 3.6 Work and Education
 Student will enter his/her Work & Education Details.
3.2.6.7 Extracurricular
Extracurricular
Field Name Field
Type
Field
Size
Remark Table
Description
Student_Enrolment_No Varchar2 20 Foreign Key This table contains
information about
Students Extra-
curricular Work
Events Varchar2 100 From Extracurricular Activities Module
venue Varchar2 100 From Extracurricular Activities Module
Time Date From Extracurricular Activities Module
Activity Varchar2 100 From Extracurricular Activities Module
Table 3.7 Extracurricular
 Student will choose particular event or activity (In same Campus)
 Student will update their extracurricular info. (Outside campus)

75
3.2.6.8 Placement
Placement
Field Name Field
Type
Field
Size
Remark Table
Description
Student_Enrolment_no Varchar2 20 Foreign key This Table Contains
Students Placement
Details
Company_Name Varchar2 100 From Training & Placement Module
Company_Address Varchar2 100 From Training & Placement Module
Company_City Varchar2 50 From Training & Placement Module
Company_Dist Varchar2 50 From Training & Placement Module
Company_State Varchar2 50 From Training & Placement Module
Company_Country Varchar2 50 From Training & Placement Module
Company_Description Varchar2 500 From Training & Placement Module
Package Varchar2 20 From Training & Placement Module
Company_E-Mail
Address
Varchar2 50 From Training & Placement Module
Bond_Duration Varchar2 50 From Training & Placement Module
Terms_Condition Varchar2 500 From Training & Placement Module
Table 3.8 Placement
 Administrator will update students Placement Related Details.
 Student will interact with the system to check their status.
3.2.6.9 Conduct
Conduct
Student_Enrolment_No Varchar2 20 Foreign key This Table Contains Students
Conduct Record, i.e. Discipline
Records, Behaviour Records
Student_Discipline_Record Varchar2 1000 entered by admin
Duration Date Entered by admin
Table 3.9 Conduct
 Administrator will update students Conduct/Discipline Details.

76
3.2.6.10 Conveyance
Conveyance
Student_Enrolment_no Varchar2 20 Foreign key This Table Contains Students
Transportation DetailsVehicle_No Varchar2 20 Primary key
Table 3.10 Conveyance
 Administrator will update students Conveyance Details.
3.2.6.11 Attendance
Attendance
Field Name Field
Type
Field
Size
Remark Table
Description
Student_Enrolment_no Varchar2 20 Foreign key This Table
Contains Students
Attendance Related
Details
Batch_no Varchar2 10 From Admission Management System, not null
Roll_no number 10 Primary Key
Current_Date Date From System
Subject_Code Varchar2 50 From Subject Table
Subject_Wise_Attendance Number 10 From Attendance Management Module
Table 3.11 Attendance
 Administrator will update students Attendance Details.
 Student/Parents will interact with the system to check their status.

77
3.2.6.12 Examination
Examination
Field Name Field Type Field Size Remark Table
Description
Student_Enrolment_no Varchar2 20 Foreign Key This Table
Contains Brief
Details about
Examination
Student_Exam_No Number 20 Primary Key
Exam_Type varchar2 20 From Examination Module
Exam_Date Date From Examination Module
Subject_Code Varchar2 50 From Examination Module
Grades Varchar2 20 From Examination Module
Table 3.12 Examination
 Administrator will update students Examination Details (Upcoming).
 Student will interact with the system to check their examination status.
3.2.6.13 Exam_Result
Exam_Result
Field Name Field
Type
Field Size Remark Table Description
Student_Enrolment_no Varchar2 20 Foreign Key This Table Contains
information about students
performance in examinations
Semester_Performance_Index Number 5,3 From Examination Module
Cumulative_Performance_index Number 5,3 From Examination Module
CGPA Number 5,3 From Examination Module
Table 3.13 Exam Results
 Administrator will update students Exam_Result Details.
 Student/Parents will interact with the system to check their status.

78
3.2.6.14 Subject
Subject
Field Name Field
Type
Course_Code Number 10,3 Foreign Key This Table Contains all the
details about subject offered
in respective course
Subject_Code Number 10,3 Primary Key
Subject_Name varchar2 50 Entered by admin
Subject_Description varchar2 1000 Entered by admin
Reference_books_list varchar2 1000 Entered by admin
Resource Blob Any User Can Share Resources
Table 3.14 Subject
 Administrator will update all the Details of all subjects.
 Student will interact with the system to check subject details.
3.2.6.15 Fees
Fees
Field Name Field
Type
Student_Enrolment_no varchar2 20 Foreign Key This Table Contains All The
information About Students
Status About all Type Of
Fees
Semester number 1 From Fees Management System
Semester_Fees Number 10,3 From Fees Management System
Library_Fees Number 10,3 From Fees Management System
Lab_Fees Number 10,3 From Fees Management System
Hostel_fees Number 10,3 From Fees Management System
Internet_Fees Number 10,3 From Fees Management System
Transportation_fees Number 10,3 From Fees Management System
Mess_fees Number 10,3 From Fees Management System
Other Number 10,3 From Fees Management System
Fees_Status varchar2 10 From Fees Management System
Table 3.15 Fees
 Administrator will update students Fees Details and set due dates.
 Student/Parents will interact with the system to check their fees status.

79
3.3 Software Development
3.3.1 Hardware Interfaces
There are no hardware interface requirements specified at this time.
3.3.2 Software Interfaces
[SRSreq 83] The system will interface with the following software systems:
 J2EE
 MySql
3.3.3 User Interface
The requirements presented in this section describe the interfaces for Student Management
System. The requirements do not assume a particular interface; however, the requirements
are grouped according to the main features provided by the system. Note that the
requirements that follow a subheading support the activities associated with the feature
named by the subheading.
 Interface Formats
[SRSreq 84] All screens will have the name of the Product, UERP, displayed on the screen.
[SRSreq 85] After the login screen, all screens will provide the user with the ability to
navigate through the system, i.e., to select different functions of the system.
[SRSreq 86] The home screen will have one search box with advance search option.
[SRSreq 87] The user will have the option to update/edit his information stored in
database.
[SRSreq 88] The user will have the option to save changes to information stored in the
database.
[SRSreq 89] The user will need to provide least details which are required in his profile.
[SRSreq 90] The user will have the option to cancel a submission to the database.
[SRSreq 91] The user will have the option to print displayed information.
[SRSreq 92] The user will have option to generate any type of reports as mentioned

80
3.3.4 Communications Interfaces
[SRSreq 93] The system will run over the existing campus network.
[SRSreq 94] The system will be developed as a client-server application with the server
providing data access services only.

81
CHAPTER
4
Software Testing &
Implementation
Contents
 Software Testing
 Software testing methods.
 Test-cases
 Software Implementation
 Language Concepts.
 Function.
 Tools/Techniques.
Learning Objectives
 Software Testing & Testing Methods.
 Software implementation & tools & Techniques
used for the same

82
Software Testing and Implementation Chapter 4
4.1 Software testing
Software Testing is the process used to help identify the correctness, completeness, security, and
quality of developed computer software. Testing is a process of technical investigation,
performed on behalf of stakeholders, that is intended to reveal quality-related information about
the product with respect to the context in which it is intended to operate. This includes, but is not
limited to, the process of executing a program or application with the intent of finding errors.
There are many approaches to software testing, but effective testing of complex products
is essentially a process of investigation, not merely a matter of creating and following routine
procedure. One definition of testing is "the process of questioning a product in order to evaluate
it", where the "questions" are operations the tester attempts to execute with the product, and the
product answers with its behavior in reaction to the probing of the tester[citation needed].
Although most of the intellectual processes of testing are nearly identical to that of review or
inspection, the word testing is connoted to mean the dynamic analysis of the product—putting
the product through its paces. Some of the common quality attributes include capability,
reliability, efficiency, portability, maintainability, compatibility and usability.
4.1.1 Software testing methods
White box and black box testing are terms used to describe the point of view a test
engineer takes when designing test cases. Black box being an external view of the test object and
white box being an internal view. Software testing is partly intuitive, but largely systematic.
Good testing involves much more than just running the program a few times to see whether it
works. Thorough analysis of the program under test, backed by a broad knowledge of testing
techniques and tools are prerequisites to systematic testing.
In order to achieve consistency in the Testing style, it is imperative to have and follow a set of
testing principles. This enhances the efficiency of testing within SQA team members and thus
contributes to increased productivity. The purpose of this document is to provide overview of the
testing, plus the techniques.
At SDEI, 3 levels of software testing is done at various SDLC phases
 Unit Testing: in which each unit (basic component) of the software is tested to verify
that the detailed design for the unit has been correctly implemented

83
 Integration testing: in which progressively larger groups of tested software components
corresponding to elements of the architectural design are integrated and tested until the
software works as a whole.
 System testing: in which the software is integrated to the overall product and tested to
show that all requirements are met
A further level of testing is also done, in accordance with requirements:
 Acceptance testing: upon which the acceptance of the complete software is based. The
clients often do this.
 Regression testing: is used to refer the repetition of the earlier successful tests to ensure
that changes made in the software have not introduced new bugs/side effects.
4.1.2 Test Cases:
Test Case ID: Test Case for Login
Section – 1
(Before Execution)
Section – 2
(After Execution)
Purpose:
Verify user’s login
Execution History:
When user enters his Id, password and role,
system checks validity of inputs against values
stored in the database.
Pre Conditions:
Every users must have user id, password with
their role
Results:
(1) If inputs are valid then it displays the
―successful login‖ message.
(2) If inputs are invalid then it displays ―error
message‖.
Inputs:
User id, password and role
If Fail the Possible Reason:
User has entered invalid Id or password
Expected Outputs:
(1) Successful Login
(2) Error Message
Any Other Observation: --
Post Conditions:
(1) If login is successful then user is
logged on into the system
(2) If login is not successful then user
will not allowed m.
Any Suggestion:
If user fails then user may try with valid Id or
password.
Table 4.1 Test Case For Login

84
Test Case ID: Test Case for update student record
Section – 1
(Before Execution)
Section – 2
(After Execution)
Purpose:
Updating record in student database.
Execution History:
The system request that the operator to enter
the student roll no, the system retrieve and
display the student information. The data entry
operator makes desired changes. After
updating, system updates student record with
updated information.
Pre Conditions:
Operator must log on to the system before
entry.
Results:
―student updated successfully‖ message.
message‖.
Inputs:
Student roll no
Student with specified roll no does not exist in
database.
Expected Outputs:
(1) Updation successfully
(2) Error Message
Post Conditions:
(1) If test case is successful the student
information is updated into database.
(2) Otherwise error message will be displayed.
Any Suggestion:
If fails, operator can try with the other roll no
or cancel the operation.
Table 4.2 Test case for Updating Student Record

85
Test Case ID: Test Case for getting Examination Records
Section – 1
(Before Execution)
Section – 2
(After Execution)
Purpose:
To See the examination details.
Execution History:
The system request the student to select the
examination for displaying the results, the
system retrieve and display the examination
records.
Pre Conditions:
Student log on to the system before entry.
Results:
―Examination Records‖
message‖.
Inputs:
Type of Examination
Result is not yet declared.
Expected Outputs:
(1) Record Display
(2) Error Message
Post Conditions:
(1) If test case is successful then student’s
examination records will be displayed.
Any Suggestion:
If fails, student can try again with valid
selection.
Table 4.3 Test case for getting Examination Records

86
Test Case ID: Test Case for Reports & Certificate Generation
Section – 1
(Before Execution)
Section – 2
(After Execution)
Purpose:
Generate Reports or Certificates.
Execution History:
The system requests the student to select particular
Report or Certificate. After selection of any
certificate or report the system will collect relative
data from database and generate Report or
Certificate.
Pre Conditions:
Student must log on to the system before
Selection.
Results:
Certificate or Report.
message‖.
Inputs:
Selection Of Report or Certificate
If desired data does not exist
Expected Outputs:
(1) Certificate or Report Generated
Successfully
(2) Error Message
Post Conditions:
(1) If test case successful the Report or
Certificate generated.
(2) Otherwise error message will be
displayed.
Any Suggestion:
If fails, student can try again with desired
inputs/selection.
Table 4.4 Test case for Report & Certificate Generation

87
Test Case ID: Test Case for mark the student attendance
Section – 1
(Before Execution)
Section – 2
(After Execution)
Purpose:
To maintain the student attendance details.
Execution History:
The system request that the clerk to enter the
requested information, once the clerk provides
requested information the attendance is marked
to the database and appropriate message is
displayed.
Pre Conditions:
Clerk must log on to the system before entry.
Results:
―Attendance marked successfully‖ message.
message‖.
Inputs:
Branch, semester, subject, lecture/lab number,
date, faculty name
Clerk has entered some invalid data.
Expected Outputs:
(1) Attendance marked successfully
(2) Error Message
Post Conditions:
(1) If test case is successful the attendance is
marked into database.
Any Suggestion: --
Table 4.5 Test Case for mark the student attendance

88
Test Case ID: Test Case for update the student attendance
Section – 1
(Before Execution)
Section – 2
(After Execution)
Purpose:
To update the student attendance details.
Execution History:
The system request that the clerk to enter the
requested information, once the clerk provides
requested information the attendance is updated
to the database and appropriate message is
displayed.
Pre Conditions:
Clerk must log on to the system before entry.
Results:
―Attendance updated successfully‖ message.
message‖.
Inputs:
Branch, semester, subject, lecture/lab number,
date, faculty name
Clerk has entered some invalid data.
Expected Outputs:
(1) Attendance updated successfully
(2) Error Message
Post Conditions:
(1) If test case is successful the attendance is
updated into database.
Any Suggestion: --
Table 4.6 Test Case for update the student attendance

Student management system university erp

Student management system university erp

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Student management system university erp

Similar to Student management system university erp (20)

Recently uploaded

Recently uploaded (20)

Student management system university erp