Project Report on Student

A PROJECT REPORT On Student Database Management System

Submitted in partial fulfillment of the requirement for the award of the Degree of

Bachelor of Technology In Computer Science and Engineering

Submitted By ASHISH ARORA Roll No: 0911483108 Batch I-2 1

Acknowledgement Acknowledgement is not only a ritual, but also an indebtedness to all those who have helped in the completion process of the project. One of the most pleasant aspects in collecting the necessary and vital information and compiling it is the opportunity to thank all those who actively contribute to it. First of all I am thankful to the IT department, where I got the golden opportunity to undertake this project. The help, assistance and guidance that I have received here will be earnestly cherished throughout my life. I would also like to thank my APTECH teacher Mr. Bhupesh who taught me very well and helped me in completing the project. I am really fortunate to be placed under her guidance. Not only to fulfill a formality but also to express the feelings in my heart, I put on record my deepest gratitude and profound appreciation to all of them who helped me by correct guidance upgrading my programming skills, and troubleshooting while doing the assignments. And last but not the least, I would like to pay my sincere regards to the faculty members for the invaluable support and blessing, which were vital necessity for the completion of my project.

2

Index

S. No.

Title

Page No.

1.

Certificate

1

2.

Acknowledgement

2

3.

Project Overview

3

4.

SRS Documentation

5

5.

Use Case Diagram

16

6.

Entity Relationship Diagram

17

7.

System Data Flow Diagram

19

8.

Introduction of the project

21

9

Outputs of the project

28

10.

Conclusion

33

12.

References and Bibliography

34

3

Project Overview Student Database Management System has become important factors in modern education field. This system should help the institutional to streamline the administrative task and provide real-time access to the data. Building this system in web based interface will further help the ease of accessibility through any web browser. The study findings enable the definition of the project problem statement, its objectives, scopes and advantages of the Student Database Management System. Student Database Management System streamlines data collection, storage & retrieval and the management of records to improve both operational (admission, registration, scheduling, examination and grading) and management tasks (planning, evaluation and decision-making). It focuses on storing & processing curriculum data, student data and produce outputs supporting the operational activities. These outputs include student cards, subject descriptions, invoices, schedules and management information.

4

1. SRS Documentation

1. Introduction A software requirements specification (SRS) is a complete description of the behavior of the system to be developed. This Software Requirement Specification is written accordance with the IEEE STD 830-1998 model.

1.1 Purpose This SRS Document contains the complete software requirements for a Student Database Management System (SDMS) and describes the design decisions, architectural design and the detailed design needed to implement the system. It provides the visibility in the design and provides information needed for software support. The intended audiences for this document are the development team, testing team and the end users of the product

1.2 Scope The software product “Student Database Management System” will be an application that will be used for maintain the records in an organized manner and to replace old paper work system. The application will manage the information about various students and teachers. It is also designed to calculate the annual fee of the students. Specific reports will also be generated regarding the teachers and the students.

5

1.3 Definitions, Acronyms and Abbreviations Following abbreviations have been used throughout this document: IEEE : The Institute of Electrical and Electronics Engineers, Inc. SRS

: Software Requirements Specification

SDMS : Student Database Management System

1.4 Overviews This document has been prepared in accordance with the IEEE STD 830-1998, IEEE Recommended Practice for Software Requirements Specification. [IEEE 830-1998 (1998)]. It provides the information of Product perspective, Product functions, User characteristics, Constraints, Assumptions and dependencies and specific requirement.

2. The Overall Description 6

This section of the SRS describes all general factors of the product and its requirements.

2.1 Product Perspective The application will be a window-based, self contained and independent software product.

Front end client application (with data entry/update/delete/ view and reporting facility)

Backend Database

Fig 2.1 Product Perspective

2.1.1 System Interfaces None

2.1.2 User Interfaces The application that will be developed will have a user friendly and menu based interface. Following screens will be provided: •

A login screen for entering the username and password, so that the authorized user can

have an access without any problems. •

There will be a screen which will be displaying the major tasks that the system will be

performing i.e. add details, delete details, view details of the student and fee management. •

All the major tasks mentioned above will have their separate forms and will perform the

desired actions. 7

Following reports will also be generated: •

Student Report

•

Student Fees Report

2.1.3 Hardware Interfaces •

Screen resolution of at least 800 X 600required for proper and complete viewing of

screens. Higher resolution would not be a problem •

Support for printer (dot-matrix/desk-jet/inkjet, etc. – any will do) – that is, appropriate

drivers are installed and connected printer will be required for printing of the reports. •

Standalone system or network based – not a concern, as it will be possible to run the

application on any of these.

2.1.4 Software Interfaces •

Any window based operating system can be used (windows 95/98/2000/XP/NT/Vista/7)

•

Oracle as DBMS for database. Future release of the application will aim at upgrading

oracle 8i as the DBMS. •

Visual Studio 9 for coding, developing the software.

2.1.5 Communications Interfaces None 8

2.1.6 Memory Constraints At least 64MB RAM and 2GB space on hard disk will be required for running the application.

2.1.7 Operations The product release will not cover any automated housekeeping aspects of the database. The DBA (Database Administrator) at the client site (i.e. the school) will be responsible for manually deleting old/non required data. Database backup and recovery will also have to be handled by the DBA. However, the system will provide a “RESET SYSTEM” function that will delete (upon confirmation from the administrator) all the existing information from the database.

2.1.8 Site Adaptation Requirements The terminals at the client site will have to support the hardware and software interfaces specified in the above sections.

2.2 Product Functions The system will allow access only to authorized users entering the appropriate password. A summary of the major function that the software will perform are as follows: •

A login facility to allow only the authorized users to have an access to the software

system. This prevents the unauthorized users to misuse the software. •

User (as Data Entry Operator) will be able to add/delete/modify information about

different students and moderator present in the school.

9

•

The reports can also be generated in case a user wants them. The reports will contain all

the details about the student whose report is generated. For e.g. their name, id, age, gender, phones no etc.

2.3 User Characteristics •

Educational level: At least graduate should be comfortable with English language.

•

Experience: The operator should be well versed about the nature and the processes of the

school. •

Technical expertise: should be comfortable using general purpose applications on a

computer.

2.4 Constraints •

GUI is only in English.

•

Login and password is used for identification of user and there is no facility for Guest.

2.5 Assumption and Dependencies •

The fee structure differs for the students in different standards.

•

The amount for personal deposit will remain the same for all the students.

2.6 Apportioning of Requirements Not required. 10

3. Specific Requirements This section contains the software requirements to a level of detail sufficient to enable designers to design the system and the tester to test that system.

3.1 External interfaces This interface will be the actual interface through which the user will communicate with the application and perform the desired tasks. The following screens will be provided:

Login Screen: The login screen will be the first screen that a user will face. This screen is responsible to allow the authorized users to access the application. It will accept the username and password from the user and verify it. If the username and password match, then the user will be allowed an access to the application else and error will be raised i.e. ACCESS DENIED. The fields available on this screen will be: •

Username

: Varchar2 of length up to 10 characters.

•

Password

: Number of length up to 15 characters.

Menu Screen:

11

This screen will display 4 small screens inside of it which will perform the major tasks. In the menu screen we can select any of these four screens and perform the desired actions. The four screens will be Student Information and Fee Management.

Student Information Screen: The user can add, delete and modify the student record as per his needs. This screen will show the user, information about each and every student present in the school. He can also add a new record in the database if a new student takes admission in the school. The fields available on this screen will be: •

ID

•

Name

•

Admission No : Number of length up to 10 digits

•

Roll No

•

Age

: Number of length up to 10 digits : Varchar2 of length up to 20 digits

: Number of length up to 10 digits : Number of length up to 2 digits

Fee Management Form: 12

This form will display the fee information i.e. the fee that has to be paid by the parents. It includes the details like hostel charges, admission fees, personal deposit etc. The fields available on this screen will be: •

Annual Fees

: Number of length up to 5 digits

•

Tuition Fees

: Number of length up to 5 digits

•

Activity Fees

: Number of length up to 5 digits

•

Security Fees

: Number of length up to 5 digits

•

Transport Fees

: Number of length up to 5 digits

3.2 System features Student Information Management Description The system will maintain all the information regarding the students such as Name, Gender, Date of Birth, ID (Unique), Address, Phone no., Age, etc. This system will also allow the user to add/delete/update the information as per his requirements. Validity checks: •

If you are adding any record then you must give a unique ID number.

•

If you are adding any record then you must give a unique roll no. number.

•

The phone number must exceed 10 digits.

•

The ID field cannot be left blank.

Sequencing information 13

After a successful login the user will be allow to choose from the options such as Student Information and Fee Management. He can choose any one of these. As far as Student Information Management is concerned the user will have to enter the ID of the student in order to generate the desired details. After the ID has been given the user will click on the “Show Record” button and he will be displayed the necessary information about that student.

Report Generation Student Report: A report will be generated containing the details of all the students. There will be an individual report for each student which will tell the user about his/her ID, Name, Age, Class etc. Student Fee Report A report will be generated containing the details of fees deposited by the student. There will be an individual report for each student which will tell the user about his/her ID, Name, Age etc.

3.3 Performance Requirements None

3.4 Design Constraints None

14

3.5 Software System Attribute 3.5.1 Security The application will be password protected. The users will have to enter the correct user name and password in order to access the software.

3.5.2 Maintainability The system will be designed in a maintainable order. The system can be easily modified and renewed according to the need of the user. 3.5.5 Portability The system will be easily portable on any windows based application that has oracle installed.

3.6 Logical Database Requirements The following information will be stored in the database: •

Student Info: ID, Name, Admission No, Roll No, Father’s Name, Mother’s Name,

Address, Gender, Age, Phone No, Date of Birth. •

Fee Info: Admission Fees, Tuition Fees, Hostel Charges, Administrative Charges,

Personal Deposit.

3.7 Other Requirements None

15

2. Use Case Diagrams A use case diagram is defined by and created from a Use-case analysis. Its purpose is to present a graphical overview of the functionality provided by a system in terms of actors, their goals (represented as use cases), and any dependencies between those use cases. The main purpose of a use case diagram is to show what system functions are performed for which actor. Roles of the actors in the system can be depicted. The actions which they perform are also displayed.

In the following use case diagram, three actors are defined: Administrator, Moderator and Student. All these can access, update, and delete information on the basis of their roles, rights provided to them.

16

3. ER Diagram Entity-relationship model (ERM) is an abstract and conceptual representation of data. Entityrelationship modeling is a database modeling method, used to produce a type of conceptual schema or semantic data model of a system, often a relational database, and its requirements in a top-down fashion. The first stage of information system design uses these models during the requirements analysis to describe information needs or the type of information that is to be stored in a database. An entity may be defined as a thing which is recognized as being capable of an independent existence and which can be uniquely identified. An entity is an abstraction from the complexities of some domain. A relationship captures how two or more entities are related to one another. Relationships can be thought of as verbs, linking two or more nouns. Diagrams created by this process are called entity-relationship diagrams, ER diagrams, or ERDs. We have presented below the ER Diagram for our software system.

17

18

4. System DFD A data-flow diagram (DFD) is a graphical representation of the "flow" of data through an information system. DFDs can also be used for the visualization of data processing (structured design). On a DFD, data items flow from an external data source or an internal data store to an internal data store or an external data sink, via an internal process. A DFD provides no information about the timing of processes, or about whether processes will operate in sequence or in parallel. It is therefore quite different from a flowchart, which shows the flow of control through an algorithm, allowing a reader to determine what operations will be performed, in what order, and under what circumstances, but not what kinds of data will be input to and output from the system, nor where the data will come from and go to, nor where the data will be stored (all of which are shown on a DFD). Following are the DFD’s of level 0 and level 1 for this software system.

19

20

5. Introduction of the Project 5.1 Purpose Student Database Management System has become important factors in modern education field. This system should help the institutional to streamline the administrative task and provide real-time access to the data. Building this system in web based interface will further help the ease of accessibility through any web browser. The study findings enable the definition of the project problem statement, its objectives, scopes and advantages of the Student Database Management System. Student Database Management System streamlines data collection, storage & retrieval and the management of records to improve both operational (admission, registration, scheduling, examination and grading) and management tasks (planning, evaluation and decision-making). It focuses on storing & processing curriculum data, student data and produce outputs supporting the operational activities. These outputs include student cards, subject descriptions, invoices, schedules and management information.

5.2 Description Of the organization A school is an institution designed for the teaching of students (or "pupils") under the supervision of teachers. Most countries have systems of formal education, which is commonly compulsory. In these systems, students progress through a series of schools. The names for these schools vary by country, but generally include primary school for young children and secondary school for teenagers who have completed primary education. In addition to these core schools, students in a given country may also have access to and attend schools both before and after primary and secondary education. Kindergarten or pre-school provide some schooling to very young children (typically ages 3–5). University, vocational

21

school, college or seminary may be available after secondary school. A school may also be dedicated to one particular field, such as a school of economics or a school of dance. Alternative schools may provide nontraditional curriculum and methods. There are also non-government schools, called private schools. Private schools may be for children with special needs when the government does not supply for them; religious, such as Christian schools, hawzas, yeshivas and others; or schools that have a higher standard of education or seek to foster other personal achievements. Schools for adults include institutions of corporate training and Military education and training. A Student Database Management System is a software application for educational establishments to manage the data of the students. This system provides capabilities for management of students, their complete information. It also provides the capabilities to manage the fee structure, the attendance of the students and teachers.

5.2.1 Organizational Objectives: •

To allow principal, teachers, and school officials to view required reports.

•

Handling the admissions process.

•

To facilitate administrator and moderator record keeping,

•

To manage the data of a particular student.

•

To control the fee management structure.

•

To retrieve the data of a particular student.

22

5.2.2 Services Provided: This Student Database Management System software provides various services to the user, mentioned below: •

A user account.

•

Maintains the profiles of the administrator, moderator, and students.

•

It also maintains the fees structure for the students.

5.2.3 Functions/Activities with respect to the proposed system: Records and Profiles Management: This software has a module dedicated to management of students, teachers and staff records, which makes it useful profile management software. This profile management system captures master data such as name and contact information of the students, parents, teachers and other supporting staff.

Fee Management: Fee collection and management is one of the critical processes of a school. This software stores all fee-related information along with the frequency at which it is collected. It also performs the task of adding all the fees submitted during different quarters.

5.3. System Analysis Systems analysis is the study of systems sets of interacting entities, including computer systems. This field is closely related to operations research. It is also "an explicit formal inquiry carried out to help someone, referred to as the decision maker, identify a better course of action and make a better decision than he might have otherwise made. 23

5.3.1 Block Diagram Administratr Enter Profile Details Profile Final

User Account

Output

Reports

Student Enter Details

Student Profile

Details

Student Fee Details Student Profile Fee Management Structure

Receipts Output

Fig.5.3 Block Diagram of the proposed system

24

5.3.2 Description of the system This software is basically developed for the user so that the user can maintain the records in an organized manner. For this purpose we have created different modules that are dedicated to the management of students, teachers and staff records, also the user can maintain the attendance records which makes it useful management software. Fee collection and management is one of the critical processes of a school. This software also stores all fee-related information along with the frequency at which it is collected.

5.3.3 Processes and input output identification This section contains the details about all the processes that are performed in the software system and also tells us about the input and output identification i.e. what is the input being given and what is the desired output.

•

Student and Administrator profile management process: These two processes are

responsible to maintain the profiles of the students, moderators and the administrator present in the school. All the details regarding each and every student and moderator are kept in their respective modules. Input: The user will enter the details of a new student if the user wants to add a new record, he can also update and delete a particular record. Process: All the processing regarding the addition, updating and deletion of a record is done here.

25

Output: The user can see the records of a particular student and moderator if he/she have particular rights.

•

Fee Management Process: This process is responsible to manage the fee record structure of

the each and every student present in the school. The user can see these records whenever he wants to. Input: The user will enter the details of a particular student. Process: Record processing will be done in this section in order to generate a particular fee record. Output: All the fee details of the student will be displayed.

26

5.3.5 Processing Logic Flowchart

27

Outputs of the Project

28

Student Database Management System Login Form

The above shows the snapshot of the Student Database Management System login form i.e. the page the users are first greeted with when they first visit the software.

Add Student Details Page

29

After the user log in he can select from the menu any option. This is the snapshot of add student details . The user can enter his details n save it in database for further use.

Delete Student Details

30

The above snapshot shows the delete user web page. The user can delete his details from the database after logging in. He requires filling in the details for deleting an account from the database.

View Reports

31

The above snapshot shows the view reports web page. The user can view his details from the database after logging in. He requires filling in the student name and the admission number to view the report from the database.

Fee Management

32

The above snapshot shows the fee management web page. The user can enter his fees details in the database after logging in. He requires filling in the student name, admission number and the corresponding fees after which total fees will be calculated and will be stored in the database.

Conclusion 33

Student Management System can completely implement all the basic things required to manage the student record in the school. It allows addition of student records, manage their profile, view their records, update / delete the details entered and also manage the fees deposited by the student. The user can also view the report of students and also their fees report. The user can access the record only after entering a valid username and a valid password associated with the username.

References and Bibliography 34

•

http://eljabiri1.tripod.com/sitebuildercontent/sitebuilderfiles/Req-Gathering-1-.pdf

•

http://www.westfallteam.com/Papers/The_Why_What_Who_When_and_How_Of_Softw

are_Requirements.pdf •

http://en.wikipedia.org/wiki/Microsoft_.NET#Microsoft_.NET

•

http://en.wikipedia.org/wiki/Requirements_analysis

•

http://portal.acm.org/citation.cfm?id=1010800.1010802

•

http://en.wikipedia.org/wiki/Secondary_data

•

http://brent.tvu.ac.uk/dissguide/hm1u3/hm1u3text3.htm

35