ABSTRACT

This project 'Student Mark Analysis deals with the complete details oI academic
details oI t he St udent. It comprises oI t he st udents Roll no, Name, Marks Obtained,
Total, Average, At t enda nce P er cent et c. I t ca n be acces s ed by t he t eac her
or t he I acul t y who al one ca n change or updat e t he mar ks oI t he st udent s. It is
also dut y oI t he Iacult y t o distribut e t he records maintain the records. The duty oI the
administrator is to generate the report cards to t he I acul t y member s . The
I acul t y wi l l ca l cul at e t he t ot al ma r ks and t hem bas ed on t he percentage
obtained by the student he/she will be awarded the grades. Here the role oI the student is to
just view the marks entered by the Iaculty. This project is constructed with modularity Ior
easy understanding oI the project and instant access oI the students database.















TABLE OF CONTENTS
CHAPTER NO TITLE PAGE NO
ABSTRACT
1 INTRODUCTION
1.1. Purpose oI the system
1.2. Scope oI the system
1.3. Objective and success criteria oI the project
1.4. DeIinition
2 CURRENT SYSTEM
3 PROPOSED SYSTEM
3.1. Overview
3.2. Functional requirements
3.3. Non-Iunctional requirements
3.3.1. Usability
3.3.2. Reusability
3.3.3. PerIormance
3.3.4. Supportability
3.3.5. Implementation
3.3.6. InterIace
3.3.7. Packaging
3.3.8. Legal
4 SYSTEM MODELS
4.1. Use case diagram
4.2. Class diagram
4.3. Activity diagram
4.4. Sequence diagram
4.5. Collaboration diagram
4.6. Component diagram
4.7. Deployment diagram
5 CODE GENERATION
6 CONCLUSION
7 REFERENCES














INTRODUCTION
PURPOSE OF THE SYSTEM:
Student Mark Analysis system is used Ior the Students and the Iaculty to have an easy
access Ior viewing the marks. It also makes the work simpler. Here in this the students can
only view the marks iI their Username and the Password are correct. They do not have the
permission to change or update the marks. It is only the Iaculty who can update and view the
students mark. It is also the duty oI the Iaculty to distribute the report cards. The duty oI the
administrator is to generate the report card and he/she can view the report cards. But the
administrator cannot update cards. All these processes are done eIIiciently and easily in
this Student Mark Analysis System.
SCOPE OF THE SYSTEM:
This Supplementary SpeciIication applies to the Student Mark analysis System, which
will be developed by the OOAD students.
This SpeciIication deIines the non-Iunctional requirements oI the system; such as
reliability, usability, perIormance, and supportability, as well as Iunctional requirements that
are common across a number oI use cases.

1.3. OB1ECTIVE AND SUCCESS CRITERIA OF THE PRO1ECT:
The main objective oI designing and implementing this project is to enable
the students and the Iaculty to see the marks easily.

DEFINITIONS:
Faculty/Class Advisor
Person who enters the marks Ior generating report.
List
List contains the set oI marks obtained by each student.
Result analysis Report
The report should contain analysis oI student marks obtained in the semester exam.
Student
Student whose mark to be analyzed.


EXISTING SYSTEM
System Analysis is a detailed study oI the various operations perIormed by a system
and their relationships within and outside oI the system. The key question is- what all
problems exist in the present system? What must be done to solve the problem? Analysis
begins when a user or manager begins a study oI the program using existing system.
During analysis, data collected on the various Iiles, decision points and transactions
handled by the present system. The commonly used tools in the system are Data Flow
Diagram, interviews, etc. Training, experience and common sense are required Ior collection
oI relevant inIormation needed to develop the system. The success oI the system depends
largely on how clearly the problem is deIined, thoroughly investigated and properly carried
out through the choice oI solution. A good analysis model should provide not only the
mechanisms oI problem understanding but also the Irame work oI the solution. Thus it should
be studied thoroughly by collecting data about the system. Then the proposed system should
be analyzed thoroughly in accordance with the needs.
System analysis can be categorized into Iour parts.
O System planning and initial investigation
O InIormation Gathering
O Applying analysis tools Ior structured analysis
O Feasibility study
O Cost/ BeneIit analysis.
In the current system we need to keep a number oI records related to the student and want
to enter the details oI the student and the marks manually. In this system only the teacher or
the school authority views the mark oI the student and they want to enter the details oI the
student. This is time consuming and has much cost.

PROPOSED SYSTEM
OVERVIEW:
In our proposed system we have the provision Ior adding the details oI the students by
themselves. So the overhead oI the school authorities and the teachers is become less.
Another advantage oI the system is that it is very easy to edit the details oI the student and
delete a student when it Iound unnecessary. The marks oI the student are added in the
database and so students can also view the marks whenever they want.
Our proposed system has several advantages
O User Iriendly interIace
O Fast access to database
O Less error
O More Storage Capacity
O Search Iacility
O Look and Feel Environment
O "uick transaction
All the manual diIIiculties in managing the student details in a school or college have been
rectiIied by implementing computerization.

FUNCTIONAL REQUIREMENTS:
'eriIying details Supervisor veriIies the student details beIore
the exam.
Answering The students should answer the questions
within the given time limit.
Evaluation The analyzer evaluates the answer and
awards marks Ior the correct answers.
Calculating grade The system generates the grade Ior the
students based on the percentage they have
scored.
Store the results The administrator stores the results in the
database.
Display the result The student view their result by logging into
the system.


NON-FUNCTIONAL REQUIREMENTS:
USABILITY:
The system must be easy to handle even to the new users. The system must be tolerant
to user errors. The system should allow user goals to be met. The system must be easily
understandable. The Iorm must be simple and Iamiliar to the users.


REUSABILITY:
It must be easy to add new Iunctionalities with slight or no modiIications. It is the
design Ieatures oI a soItware element (or collection oI soItware elements) that enhance its
suitability Ior reuse.
PERFORMANCE:
The system should perIorm well in terms oI responsiveness and stability under a
particular workload. It can also serve to investigate, measure, validate or veriIy
other quality attributes oI the system, such as scalability, reliability and resource usage.
SUPPORTABILITY:
The system must understand all the soItware Iailures and deal with them correctly.
When something unexpected happens, it should not conIuse the users. When writing code
we must avoid random, hard-to-diagnose, unpredictable Iailures at all costs. Any problem
must be visible as early as possible.
3.3.5. IMPLEMENTATION:
The implementation process consists oI 4 phases: Discovery, System development,
User acceptance testing and Production rollout. Discovery included the identiIication oI
users and Iunctionalities in the system. System development involves the building oI the
entire system. Testing involves conIormation that the system meets the customer
requirements. And Iinally the system is implemented in the operational environment.
INTERFACE:
InterIaces are used to encode similarities which the classes oI various types share, but
do not necessarily constitute a class relationship. Implementing an interIace allows a class
to become more Iormal about the behaviour it promises to provide. InterIaces Iorm a
contract between the class and the outside world, and this contract is enIorced at build
time by the compiler. II your class claims to implement an interIace, all methods deIined
by that interIace must appear in its source code beIore the class will successIully compile.
PACKAGING:
Packaging bundles up your application's executable Iiles into a single Iile, called a
distribution unit, so that it is easier to deploy and install our application to our user's
computer.
LEGAL:
The Iirst owner oI copyright in a computer program and any documentation is the person
who wrote it, or iI that individual wrote it in the course oI their employment, then the
employer oI that individual that wrote is the Iirst owner oI that copyright. It is important to
note that the person who commissioned or paid Ior the computer program or documentation
to be created Ior it is not the Iirst owner oI the copyright.

SYSTEM MODELS:
USE CASE DIAGRAM:










USE CASE DAGRAM FOR STUDENT
MARK ANALYSS SYSTEM
login
enter student personal details
student
view result
get student personal details
get student marks
display result
calculate percentage
administrator
display result
CLASS DIAGRAM:











CLASS DAGRAM FOR STUDENT
MARK ANALYSS SYSTEM
student personal details
regno : int
pwd : string
name : string
dob : date
dept : string
address : string
add_per_details()
display_avail()
display_per_details()
student marks
regno : int
sem : string
mark1 : int
mark2 : int
mark3 : int
mark4 : int
mark5 : int
percentage : float
grade : string
result : string
add_mark_details()
dis_mark_details()
cal_percentage()
dis_grade()
dis_result()
admin
username : string
pwd : string
login_verify()
ACTIVITY DIAGRAM:



ACTVTY DAGRAM
no of
student
pass fail
analyze marks
total marks
calculate
percentage
display grade
display result
SEQUENCE DIAGRAM:









student stu_per_details stu_mark_detai
ls
result admin
SEQUENCE DAGRAM FOR STUDENT MARK
ANALYSS SYSTEM
login verify
display avail
add per details
add mark details
display mark details
calculate percentage
display grade
display result
COLLABORATION DIAGRAM:













student stu_per_de
tails
stu_mark_de
tails
result
admin
2: display avail
COLLABORATON DAGRAM
1: login verify
3: add per details
4: add mark details
6: calculate percentage
5: display mark details
7: display grade
8: display result
COMPONENT DIAGRAM:














personal
details
student
marks
administr
ator
COMPONENT DAGRAM
DEPLOYMENT DIAGRAM:











get student details
get mark details
administrator
DEPLOYMENT DAGRAM
CODE GENERATION:
STUDENT PERSONAL DETAILS:

public class stuperdetails



address;

dept;

dob;

name;

pwd;

regno;


addperdetails()


// implement here...

}


displayavail()


// implement here...

}


displayperdetails()


// implement here...

}

}

STUDENT MARKS:

public class stumarks



regno;
sem;

grade;

mark1;

mark2;

mark3;

mark4
mark5;

percentage;

regno;

result;

sem;


addmarkdetails()


// implement here...

}


calpercentage()


// implement here...

}


disgrade()


// implement here...

}


dismarkdetails()


// implement here...

}


disresult()


// implement here...

}

}

ADMIN:

public class admin



pwd;

username;


loginveriIy()


// implement here...

}

}


CONCLUSION:
Thus the problem analysis & requirement analysis and various use case scenarios,
UML diagrams has been studied successIully.

REFERENCES:
hLLp//wwwschoolsofLwarescom/sLudenLsmarkanalyslsrankcardpreparaLlonsofLware
overvlewhLml
hLLp//wwwlndlasLudychannelcom/pro[ecLs/1482S1uuLn1MA8kAnAL?SlSaspx
hLLp//w3schoolscom/
hLLp//enwlklpedlaorg/wlkl/8aLlonal_SofLware