PROJECT REPORT ON

Student Marks Analysing System

Under the supervision of

Dr. Neena Gupta

Assistant Professor

Dept. of Comp.Sc.

KGC, Dehradun

Submitted By

Sarika Rajput

Semester 4th sem

MASTER OF COMPUTER APPLICATION

DEPARTMENT OF COMPUTER SCIENCE
KANYA GURUKUL CAMPUS,DEHRADUN
2017

1
ACKNOWLEDGMENT

I would like to express my profound gratitude and thanks to respected DR. Neena
Gupta and kamika chaudhary for her immense support, valuable guidance and advices
during the preparation of this seminar. She helped nurse this project from idea of stage
to the record. I tried my maximum to make this seminar according to her suggestion
and direction.

I also thankful to Dr. NIPUR and Dr. PRAVEENA CHATURVEDI who never
hesitated to extend her helping hand whenever required during the seminar. I also
extend my sincere thanks to Dr. NEENA GUPTA for support and also making available
the computer resources.

Date: Sarika
Rajput

2
CERTI FICATE
This is to certify that the project work entitled Student Marks Analyzing System
has been done by Sarika Rajput, student of M.C.A(4 th SEM) of Kanya Gurukul
Campus, Dehradun, is an authentic work carried out by her at the Department of
Computer Science under my supervision of Dr Neena Gupta.

DR. Neena Gupta

Assistant
Professor
Dept of Comp.
Science
Kanya Gurukul
Campus, (Dehradun)
3
Contents
1 Introduction...........................................................................................................
1.1Purpose:................................................................................................................
1.2Scope....................................................................................................................
1.3Definition, Acronyms, and Abbreviation:...............................................................
1.4References:...........................................................................................................
1.5Overview...............................................................................................................
2 Overall Description...............................................................................................
2.1Product prospective:..............................................................................................
2.1.1.................................................................................................. System interface
9
2.1.2...................................................................................................... User interface:
9
2.1.3............................................................................................. Memory constraints:
10
2.1.4............................................................................................................
10
2.2Product functions:...............................................................................................
2.3User Characteristics:...........................................................................................
2.4Constraints..........................................................................................................
2.5Assumption and Dependencies:..........................................................................
2.6Apportioning of Requirement..............................................................................
3 Specific Requirement..........................................................................................
3.1External Interface Requirements.........................................................................
3.1.1....................................................................................................... User interface
11
3.1.2............................................................................................... Hardware interface
12
3.1.3................................................................................................ Software interface
12
3.1.4..................................................................................... Communication interface
13
3.2System Features..................................................................................................
4
1 Introduction
Student mark analyzing system has been designed to carry out the mark analysis
process in an educational institution. The results of respective departments can be
efficiently computed without much of manual involvement. The final product will
be having only features mentioned in this document and assumption for any
additional feature should not be made by any of the parties involved in
developing /testing/implementing using this product.

1.1 Purpose:
This specification document describes the capabilities that will be provided by the
software application student marks analyzing system. It also states the various
required constraints by which the system will abide.

1.2 Scope
This system is very essential for every educational institution as it reduces man
power. This system can be used for all kinds of educational institutions to
evaluate and analyze the marks and generate reports of specified criteria.

1.3Definition, Acronyms, and Abbreviation:

Following abbreviation have been used throughout this document.

MCA: Master of computer application

IT: Information technology

DBMS: Data base management system

5
 DA: Design and analysis of algorithm

TOC: Theory of computer

DBA: Data Base Administrator

1.4References:

University website: for information about course of MCA

IEEE recommended practice for software requirement specification-IEEE std 830-
1993.
www.google.co.in
www.winkipedia.com

1.5Overview
This result of SRS document describes the various system requirement, interface,
features and functionalities in detail.

2 Overall Description
For analyzing the marks obtained by students in an educational institution. We are
tasked to build up student mark analyzing system. This is done to replace the
manual entering and processing of marks which are error prone and tedious. This
system also maintains information about student.

The system will have a Windows based desktop interface to allow the faculty to
enter marks obtained by the students, update them and generate various reports
.For security reasons, the administrator and faculty only can update the marks and

6
 other information. First the user needs to login to the system for accessing it. The
system will retain information on all the result reports. The marks and information
about the students are stored in a database and the system works with the database.

The faculty can enter the marks and student information through a visual
environment. The updated details are stored in the database. The system generates
the overall result by analyzing the marks. Mark analyzer monitors this process. The
application in run by the mark analyzer. The trial for illegal updating would render
the system to be locked.
One of the most important features of the system is creating reports based on the
given criteria. The user can create the following reports: Overall Class, Department
result, Individual student result, Toppers list, Arrears list and Improvement rate for
the academic year report has to be generated by entering the register number of the
student. These reports can also be viewed by the management and placement
officers. The administrator is responsible for adding, deleting student details form
the system and updating the marks to the system with the external queries. So, the
system design will generate reports automatically and there will be no need for
manual intervention.

2.1Product prospective:
The application will be a windows based, self-contained and independent
software product.

Fig 1: product prospective

7
2.1.1 System interface
None

2.1.2 User interface:

There will be a screen that will capture information regarding which student
have scored how many marks(internal + external evaluation).in each subject(in a
particular semester).Credit in each subject will be calculated depending on the
marks obtained in that subject.

2.1.3 Memory constraints:

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

2.1.4 Operation:
The DBA at the client site will be responsible for manually deleting old /non
required data. Data base and backup and recovery will also have to be handled
by the DBA.

2.2Product functions:
The system will allow access only to authorized users will specify roles.
1. A login facility for enabling only authorized access to the system.

2. User (with role data entry operator) will be able to add/modified/delete

information for the course in different years

3. User (with role data entry operator) will be able to add/modified/delete

information for the course in different semester.

2.3 User Characteristics:

8
1. Educational Characteristics: At least should be comfortable with English
language.

2. Experience: Should be well versed/information about the course structure of

MCA program of university.

3. Technical expertise: Should be comfortable using general purpose application on

a computer.

2.4Constraints

1. Since the DBMS being used in MS Access 2000 which is not a very powerful
DBMS,it will not be able to store a very huge number of records.
2. Due to limited features of DBMS being used, database auditing will also not be
provided.
3. Due to limited features of DBMS being used performance Turing features will not
be applied to the queries and thus the system may become slow with the increase in
number of record being stored.
4. User at university will have to implement a security policy to safeguard the marks
related information from being modified by unauthorized users.

2.5 Assumption and Dependencies:

1. The number of subject to be taken up by a student in each semester does not

change.
2. The number of subject types (elective, core, lab paper) does not change
3. The number of semester in MCA Program does not change.

9
2.6Apportioning of Requirement
Not required.

3 Specific Requirement

3.1 External Interface Requirements

3.1.1 User interface

Login screen:
This will be the first screen that will be displayed. It will allow to access
different screens based upon the users role.Varioues field available on this
screen will be
1. User ID: alphanumeric of length up to 10 characters
2. Password: Alphanumeric of length up to 8 characters
3. Role: Will have the following values:
Administrator, Marks entry clerk, co-ordinateor, data entry operator.
Subject info parameters screen: This screen will be accessible only to
user with role Administrator.
Marks entry parameters screen:
This screen will be accessible to user with role Marks Entry Clerk.
Marks entry screen: This screen will be accessible to user with role
Marks Entry Clerk.
1. Student Enrollment No: It will display the enrollment number of all students.
2. Student Name: will display the name of student.
3. Internal Marks: between 0 to 30.
4. External Marks: 0 to 70.
5Total Marks: sum of internal and external marks.

10
 3.1.2 Hardware interface
1. Screen resolution of at least 800*600- required for proper and complete
viewing oh screens. Higher resolution would not be a problem.
2. Support for printer (dot matrix/DeskJet)and printer connected printer will
be required for printing of report and mark-sheets.
3. Standalone system or network based not a concern, as it will be possible
to run the application on any of these.

3.1.3 Software interface

1. Any windows based operating system(Windows 95/2000/XP/NT)
2. MS Access 2000 as the DBMS for database. Future release of the
application will aim at upgrading to oracle 8i as the DBMS.
3. Visual Basic6- for coding /developing the software.

3.1.4 Communication interface

None

3.2System Features
3.2.1 Identified use cases
Login:
This use case describes how a user logs in to the mark analyzing system.
Marks entry:
This use case allows faculty to enter the marks into the student table.
Mark analysis:
This use case describes how the system generates the overall.

11
 Maintain student information:

This use case allows the administrator to maintain the student information and it
also includes adding, changing and deletion of information about the students
from the system.
Create result report:

This use case allows the system to generate various reports based on the criteria
specified by the user.

3.2.2 Identified Actors

Faculty:

The person responsible for entering and updating the marks obtained by the
students.
Administrator:

The person responsible for maintaining student information in the system.

Database:
The database that contains all the information about the student and their marks.

Mark analyzer:
The person responsible for monitoring the mark analyzing
process.

Student:

Details about the students are entered into the system so that the student can
view the results and reports.

12
 Placement Officer:
The placement officers can also view the reports based on the
criteria specified.

3.2.3 Use Case Diagram:

13
Fig 2: use case diagram for student marks analyzing system

14
 4 System Features

4.1Design Documentation
4.1.1 Login
This use case describes how the user logs into the Student Marks Analyzing
System (SMAS).

4.1.2 Flow of events:

Basic flow:
This use case starts with the actor wishes to log in to the SMAS.
1. The system requests the actor to enter their name and password.
2. The actor enters their name and password.
3. The system validates the entire name and password and logs the actor into the
system.

Alternative flow:
1. Invalid name and password.
2. If in Basic flow the actor enters and invalid name and password, the system
displays an error message. The actor can choose to either return to the beginning
of basic flow or cancel the login at which point the use case ends.

4.1.3 Pre conditions:

None.

4.1.4 Post conditions:

If the use case was successful, the actor is now logged into the
system, if not, the system status unchanged.

15
 4.2 Marks Entry
This use case allows the faculty to enter the marks into the student table.

4.2.1 Flow of events:

Basic flow:
This use case starts when the faculty wishes to enter the marks
obtained by the student in different subjects.
1. The system retrieves and displays the student table. If a student table does not
exist, it creates a new one. The names of the student and reg. no cant be
changed by the faculty.
2. Once the faculty has entered marks, the system saves the table and adds it to the
database.
Alternative flow:
i. Invalid Marks:

In Basic flow, if invalid marks are entered, the system displays an error message
and prompts for a valid mark. The faculty must enter a valid mark or cancel the
operation in which case, the use case ends.

ii. Marks already entered:

If in basic flow, the student mark has already been entered, the system displays the
read only copy of marks and informs the faculty that the mark has already been
entered. So, no changes can be made to it. The faculty acknowledges the message
and the use case ends.

iii. Fields left empty:

If in basic flow, the field is left empty, the system prompts the
faculty to correct the error. The faculty can enter the mark or
mark the student as absent.
16
 4.2.2 Pre Condition:
The faculty must be logged on to the system before the use case begins.

4.2.3 Post Condition:

If the use case was successful, the student mark is saved to system otherwise the
system status is unchanged.

4.3 Mark Analysis

4.3.1 Flow of events:
Basic flow:

This use case begins when the mark analyzer wishes to calculate the total
percentage of marks obtained by the students.
1. The system retrieves and displays the current student marks information from
the database.
2. The system calculates the total marks and percentage obtained by all the
students.
3. The results are stored in the database.
4. The use case ends when all the students marks have been processed.
Alternative flow:
i. Marks unavailable:
If in basic flow, the information about student marks could not be located, the system
displays error message and use case ends.
ii. Results already calculated:
If in basic flow, the result has already been calculated, the system displays the copy
of the information and informs mark analyzer that marks have already been
processed. The mark analyzer acknowledges the message and the use case ends.

17
 4.3.2 Pre Condition:
The mark analyzer must be logged on to the system before this use case begins.

4.3.3 Post Condition:

If the use case was successful, the processed mark information
is saved to the system otherwise the system status is
unchanged.

4.4 Maintain Student Information

4.4.1 Flow of events:
Basic flow:
This use case starts when the administrator wishes to change, add or delete
student information from the system.
1. The system requests the administrator to specify the function that the
administrator would like to perform.
2. Once the administrator provides the requested information, one of the sub flows
is executed. If administrator selects add a student, then the add a student sub
flow is executed. If administrator selects update student information, then the
update student information sub flow is executed. If the administrator selects
delete a student, then the delete a student sub flow is executed

Add a Student:
1. The System requests the administrator to enter the student information. This
includes name, department, year, semester, age and sex.

18
 2. Once the administrator provides the requested information, the system generates
and assigns a unique register number to the student. Now the student is added to
the system database.
3. The system provides the administrator to write the new register number.

Update Student Information (USI):

1. The System requests the administrator to enter the register number.
2. Administrator enters the register number and then the system retrieves and display
the student marks information..
3. Administrator can make changes to the marks.
4. The System updates the student information to the database

Delete a Student:
1. The System requests the administrator to enter the register number.
2. Administrator enters the register number and then the system retrieves and displays
the information.
3. The System prompts administrator to confirm deletion of the student.
4. Administrator verifies the deletion.
5. The System deletes the student from the database.

Alternative flow:
i. Student not found:
If the Update Student Information (USI) or delete a student sub flow student with
specific with specific register number does not exist, then the System displays a error
message.
The System administrator can re enter or cancel at which point the us case ends.

19
 ii. Irrelevant data:
If in the add a student sub flow invalid information is entered, the system display an
error message so that the administrator can re enter or cancel.
iii. Delete Cancelled:
If in the delete a student sub flow, the administrator decides not to delete the
Student, the delete is cancelled and the Basic flow is restarted.

4.4.2 Pre Condition:

The administrator must be logged on to the system before this use case begins.

4.4.3 Post Condition:

If the use case was successful, the student information is added, updated or
deleted.

4.5 Create result/report

4.5.1 Flow of events:
Basic flow:
This use case starts with the actor user wishes to create a report.
1. The system requests the user to specify the following report criteria:
Report type (either Overall class/Department result, Individual
Student Result, Toppers List, Arrears List and Improvement Rate for the
academic year). Criteria for the respective report.

2. If the user selects the Overall class/department result report, the system
retrieves and displays the entire Students mark
3. Information from the database. The system then requests the user
4. To enter information he/she requires (criteria).

20
 5. If the user selects Individual Student Result report, the system
6. Requests the student to enter the register number. The system
7. Validates the register number and if it is valid, the displays the report.

8. Similarly, for the Toppers list, Arrears list, Improvement Rate reports, the
criteria are specified.

9. Once the user provides the requested information the System provides the report
satisfying the report criteria.
10. The user may require saving the report.
Alternative flow:

Requested Information Unavailable:

If in the basic flow, the requested information is unavailable, the system will display an
error message. The user can choose return to begin to basic flow or cancel it at which
the use case ends.

Invalid format or Insufficient Information:

If in the basic flow, the user has not specified sufficient information to create the
report, the system will prompt the user for missing information. The user can re-enter
or cancel, at which point the use case ends.

Invalid register number:

If the user enters invalid register number, the system will display an error message. The
user can re-enter or cancel the operation.

21
4.5.2 Pre condition:
The user must be logged on to the system before the use case begins.

4.5.3 Post condition:

The System state is unchanged by the use case.

5 SEQUENCE DIAGRAM

5.1Login ()

Fig 3: Login()

22
5.2Maintain student information

Fig 4: maintain student information

5.3Add a Student

23
 Fig 5: Add a student record

5.4Delete student.

24
5.5
5.6Update Information

25
6 DFD Of Student Marks Analyzing System

Fig 8: DFD of student marks analyzing system

26
 7 Performance Requirments
None

7.1 Design Constraints

None

7.2 Software system Attribute

7.2.1 Security
The application will be password protected.user will have to enter correct user
name,password in the application

7.2.2 Maintainability
The appliction will be desigend in a maintainable oreder.It will be easy to
incorporate new requirments in the individuals modules.

7.2.3 Poratbility
The appliction will be easily portable on any windows based system that has MS
Access 2000 installed.

7.3 Logical Requirments

Subject info: Subject name, code, credit points.
Student info: Student roll number, semester, choice of Elective 2 subject
User account info: User Name, User ID, password.

7.4 Other Requirements

None

27