Students Attendence And Internal

Assessment Management System

SOFTWARE ENGINEERING PROJECT REPORT
[Submitted in partial fulfillment]
As a part of the curriculum

B.sc (H) COMPUTER SCIENCE (sem IV)

From

Mata Sundri College ,New Delhi

University of Delhi

Submitted by:

Neha Thakran(17044570025)

Ekta Ruhal(17044570024)

Aishwarya Gupta(17044570023)
 Acknowledgement
"It is not possible to prepare a project report without the guidance and
encouragement of other people. This one is certainly no exception."

One the very outset of this project report, we would like to extend our sincere
and heartfelt obligation towards all the personages who have helped us in this
endeavor. Without their active guidance, help, cooperation and encouragement ,
we would not have made headway in this project.

First of all, we would like to thank the supreme power the almighty God and our
parents who always guided us to work on the right path of life and have showered
love and encouragement to this stage.

Secondly, we would like to thank our worthy teacher of software engineering Ms.
Ashema Hasti.

We have no valued words to express our thanks but our heart is still full of favors
received from every person.

Thank you

Aishwarya Gupta

Neha Thakran

Ekta Ruhal
 Abstract
The need for developing students attendance and internal assessment
management system is driven due to the fact that students attendance and
assessment records are one of the most important factors of their academic
achievements.

First of all, we have gathered the requirements from end users so that we can
build a software that withstand with the users satisfaction. Then we have chosen
the appropriate process model to develop the software depending upon the
duration we have to build the project and ever changing requirements of the end
users and providing them prototype of the software before it has ready to be
used. Then we have divided the tasks so that we can work in an efficient manner
and project will be able to complete with in time constraint and for that very
purpose we have built the timeline chart to see our progress report while making.
Then we have gathered some software requirements regarding the functionality
that is to be involved in software and which user is doing what . Not only that
here we have been dealing with some software, hardware requirements of the
software we are about to built. Then we have made context level diagram to see
the basic transfer of information. Then data flow diagrams to see how the data is
flowing in every module. Then we have calculated the project metrics. And then
we have calculated the effort involved in the project. The we have made the basic
data design to create the entity relationship diagram. So that we can see the
pictorial representation of the interaction between between different users of the
software. Then we have built the use case diagram and description to see the
functionality of the system. And last but not the least and most importantly we
have have risk analysis and testing of out system software to make our system
more reliable.
 CERTIFICATE
This is to certify that Aishwarya , Ekta ,Neha students of BSC(H)
Computer Science, semester IV has successfully completed this
Software Engineering project on the topic Students Attendance And
Internal Assessment Management System under the supervision of
Ms. Ashema Hasti (subject teacher).

ASHEMA HASTI

(Assistant Professor)

(Department Computer Science)

Table of contents
Problem Statement. ............................................................................................................. 6

Process Model ...................................................................................................................... 6

1. INTRODUCTION .................................................................................................. 8

1.1 PURPOSE ..............................................................................................................9

1.2 PROJECT SCOPE ..................................................................................................9

1.3 DEFINITION, ACRONYMS , ABBREVIATIONS.................................................10

1.5 OVERVIEW.............................................................................................11

2. PROJECT PERSPECTIVE.................................................................................12

2.1 PRODUCT PERSPECTIVE.....................................................................................13

2.2 PRODUCT FEATURES...........................................................................................15

2.3 USER CLASSES AND CHARACTERISTICS..........................................................17

2.4 DESIGN AND IMPLEMENTATION CONSTRAINTS..............................................18

2.5 ASSUMPTION AND DEPENDENCIES...................................................................19

3. SPECIFIC REQUIREMENTS............................................................................. 20

3.1 EXTERNAL INTERFACE............................................................................................ 21

3.2 FUNCTIONAL REQUIREMENT.................................................................................. 21

3.3 PERFORMANCE REQUIREMENTS........................................................................... 22

3.4 LOGICAL DATABASE REQUIREMENTS.................................................................. 23

3.5 DESIGN CONSTRAINTS.......................................................................................... 23

3.6 SECURITY REQUIREMENTS.................................................................................... 23

3.7 SOFTWARE SYSTEM ATTRIBUTES................................................................ 24

3.8 DATA FLOW DIAGRAM...................................................................................... 25

3.9 DATA DICTIONARY........................................................................................... 36

3.10 USE CASE........................................................................................................ 38

4. DESIGN............................................................................................................ 45

4.1 ER DIAGRAM..................................................................................................................... 46

4.2 DATA DESIGN.................................................................................................................. 47.

4.3 COMPONENT LEVEL DESIGN............................................................................................ 53

5. ESTIMATION AND SCHEDULING................................................................................. 54

5.1 PROJECT SCHEDULING............................................................................................. 56

5.2 TIMELINE CHART......................................................................................................... 57

5.3 SIZE ESTIMATION (FUNCTION BASED METRICS)......................................... 58

5.4 COST ESTIMATION (COCOMO II MODEL)......................................................... 61

6. RISK ANALYSIS.................................................................................................................. 63

7. TESTING............................................................................................................................... 65

8. ANNEXURES......................................................................................................................... 67
Problem Statement
The online students attendance and internal assessment Management system is build to
overcome the drawbacks of present system , proposed system has been evolved. This project
reduces the paperwork and saves the calculations and reports generation time . It also provide
the accuracy in reports generation. This system provides best user interface.

The existing system is the manual entry for the students. Here the attendance is carried out in
handwritten register format. It will be a tedious job to maintain the record for the user. And at
the end of the session the reports are generated. The human effort is more.

So there is a need for a software which reduces the work. This software will have three types of
user administrator, faculty and students who interact with each other via this software system
in order to perform various activities like Attendence and internal assessment records.

Software lifecycle model

Model best suited for this project is Prototyping model.

Software implementers and designers can obtain feedback from the user early in the project so
accommodating the changes is quite easy and cost of changes will also be less. Client and software
manager can compare if the software made matches the software specification prior to the delivery of
the final product. Stable funding would not be an issue for iterative process as it is a government project

Prototyping process model

Prototyping is defined as the process of developing a working replication of a product or system
that has to be engineered. It offers a small scale facsimile of the end product and is used for
obtaining customer feedback.

The Prototyping Model is one of the most popularly used Software Development Life Cycle
Models (SDLC models).This model is used when the customers do not know the exact project
requirements beforehand. In this model, a prototype of the end product is first developed,
tested and refined as per customer feedback repeatedly till a final acceptable prototype is
achieved which forms the basis for developing the final product.
Advantages –
1. The customers get to see the partial product early in the life cycle. This ensures a greater
level of customer satisfaction and comfort.

2. New requirements can be easily accommodated as there is scope for refinement.

3. Missing functionalities can be easily figured out.

4. Errors can be detected much earlier thereby saving a lot of effort and cost, besides enhancing
the quality of the software.

5. The developed prototype can be reused by the developer for more complicated projects in
the future.

6. Flexibility in design.

Use In our project : –

The Prototyping Model should be used when the requirements of the product are not clearly
understood or are unstable. It can also be used if requirements are changing quickly. This
model can be successfully used for developing user interfaces, high technology software-
intensive systems, and systems with complex algorithms and interfaces. It is also a very good
choice to demonstrate the technical feasibility of the product. So we have used this model as
you wish to show the user how the software will look like even before the completion of the
project.
 1. INTRODUCTION
1.1 PURPOSE

1.2 PROJECT SCOPE

1.2.1 OBJECTIVE OF THE PROPOSED SYSTEM

1.2.2 FEATURES

1.3 DEFINITION, ACRONYMS , ABBREVIATIONS

1.5 OVERVIEW
1.1 PURPOSE
The main aim purpose of this project is to make an online system which is provide
quick and easy way of managing student's attendance and assessment marks in
any institute or college. We are manufacturing this project to provide an
interactive communication bridge and build a strong well managed online system
to avoid miss management and dissatisfaction of the attendance records.

1.2 PROJECT SCOPE

The main scope of the project is to totally eliminate the paper work in managing
the student's attendance records manually. With this project:-

1.faculty members can take student's attendance and internal assessment marks
according to their batch timings.

2.teachers can monitor and handle large number of students with attendance and
academic performance report and leave status.

3.No need to give any training to faculty members to access and use this easy
application.

4.addition or editing of any record in this application is very easy.

5.Faculty can generates all the necessary attendance related reports.

6.there is no need for the students to stand in a queue to fill the attendance
shortage forms or bonds in case of attendance shortage.

7.students can able to know for how many days they can take leave from college
to in order to meet the required attendance percentage.

8.students can keep a watch on the correctness of their attendance and

assessment marks for any day and if there is any fault, he/she can ensure it's
correctness.
1.2.1 OBJECTIVE OF THE PROPOSED SYSTEM
To overcome the drawbacks of present system , proposed system has
been evolved. This project reduces the paperwork and saves the calculations and
reports generation time . This system provides best user interface. This system
provides User-friendly system because retrieval and storing of the data is fast and
data is maintained efficiently. The reports are easily generated so user can
generate the report as per the requirement or in the middle of the session.

1.3 DEFINITION, ACRONYMS , ABBREVIATIONS

List of acronyms and abbreviations.

Acronyms and abbreviation Description

SRS Software requirement Specification

DD Data dictionary

DFD Data flow diagram

GUI Graphical user interface

1.5 OVERVIEW
 Attendance and internal assessment Management System basically has two main
modules for proper functioning • First module is admin which has right for creating
space for new batch. Any entry of new faculty, Updation in subject if necessary,
and sending notice. • Second module is handled by the user which can be a faulty
or an operator. User has a right of making daily attendance, generating report.

Attendance can be taken in two ways:

• On the basis of Subject and month.

• On the basis of Class.

 2. PROJECT PERSPECTIVE
2.1 PRODUCT PERSPECTIVE

2.1.1 SYSTEM INTERFACE

2.1.2 HARDWARE INTERFACE

2.1.3 COMMUNICATION INTERFACE

2.1.4 MEMORY CONSTRAINTS

2.1.5 OPERATION

2.1.6 SITE ADAPTATION REQUIREMENTS

2.2 PRODUCT FEATURES

2.2.1 ADMINISTRATOR FUNCTIONALITIES

2.2.2 FACULTY FUNCTIONALITIES

2.2.3 STUDENT FUNCTIONALITIES

2.3 USER CLASSES AND CHARACTERISTICS

2.3.1 USER CHARACTERISTICS

2.3.2 CLASSES CHARACTERISTICS

2.4 DESIGN AND IMPLEMENTATION CONSTRAINTS

2.5 ASSUMPTION AND DEPENDENCIES

2. PROJECT PERSPECTIVE
2.1 PRODUCT PERSPECTIVE
The product students attendance and internal assessment management
system is an independent product and does not depend upon any other
product or system. The product will automate various tasks associated with
handling students details ,their marks and attendance reports and better
organizing stored information and better performance for wide range of
user's use . So it helps colleges to ensure the smooth and better working of
these features.

2.1.1 SYSTEM INTERFACE

The system is designed to be transparent to its users and hence all the
complexity is hidden from the user. The user will interact with system using the
GUI along with meaning frames and buttons. Reports are generated as per the
requirements.

2.1.2 HARDWARE INTERFACE

Various interfaces for software could be:-

1. Touch screen/ monitor

2. Continuous battery backup

3. Interface that connects the device to university portal.

2.1.3 COMMUNICATION INTERFACE

The machine will be the part of college local area network to access the
central database.
2.1.4 MEMORY CONSTRAINTS
Hardware environment processor Dual core 2nd generation

System configuration or hard disk RAM -500 MB

Operating system Windows XP /Vista /7/8/8.1/10 iOS

2.1.5 OPERATION
User can do multiple operation after visiting the portal. Some of them are:-

1. User get access to the university portal

2. He/ she can login as admin or faculty(teachers) or student by giving their user
ID and password.

3. Admin can add students and teachers detail and update the attendance and
internal assessment marks.

4. Teachers can upload attendance and internal assessment marks.

5. Students get access to the view their attendance or internal assessment

marks and generate PDF.

2.1.6 SITE ADAPTATION REQUIREMENTS

This project doesn't require any site adaptation. The entire system get
Transported wherever it is needed because it is portal, which the user can access
from anywhere and anytime. No external dependencies are in place and
operation of the system will not change due to the change in location.
2.2 PRODUCT FEATURES
1. It provides quick integration to the existing operating system.

2. It is very easy to use and user friendly.

3. There is no need for some specific hardware requirements.

4.This application software can work on all devices such as mobiles phones ,
laptops , personal desktop computers , etc.

5. It provides secured access to the data as no other person can access

another person's data/information because everyone is given his/her unique ID
and password .

2.2.1 ADMINISTRATOR FUNCTIONALITIES

1. He/she is the main or super user of the system.

2. They enjoy all the privilege features.

3. They can add , update or delete the subject studied by the students.

4. Approvals of all the accounts , whether teacher or student is dependent on

admin.

5. They by themselves add students and teachers account.

6. They can view attendance and internal assessment marks of each student.

7. They can view all the marks given on the basis of attendance , internals or any
class test

8. Download attendance report as PDF

10. They can send any information to anyone or group of people.

11. They can also notify students about their below average percentage.
2.2.2 FACULTY FUNCTIONALITIES
1. First of all , teachers have to create account and then get approved by admin.

2. After approvals they can update the password.

3. They can also makes some minor changes in the

4. Teachers can choose about the type of lecturer they are taking in that period
(like tutorial, scheduled theory or lab classes)

5. Teachers can manage multiple lectures

6. They can get to know about which department's students have assigned to
them in which period.

7. They can easily mark the attendance and internal assessment marks.

8. They can view each student's attendance

9. They can also download the attendance report in the form of PDF.

2.2.3 STUDENT FUNCTIONALITIES

1. He/she needs to create an account.

2. Students can check the attendance of each lecture.

3. They can see in which of the classes they were absent or didn't attended.

4. They can see Attendance report and internal assessment marks reports from
anywhere on the globe , there is not need to go in admin and ask for the
attendance status.

5. They can also generate and download there attendance report in the form of
PDF.
6. They can also see how many leaves he /she can take in order to maintain the
average level of attendance.

7. They can also change ,update their profile.

8. Students can able to see if there is any notification aur notice from admin or
department about the shortage of attendance or to attend any event.

2.3 USER CLASSES AND CHARACTERISTICS

2.3.1 USER CHARACTERISTICS

1. The students, administrator and teachers should have a basic idea to use
the system.

2. They must have a work experience on the internet.

3. They must know basic language i.e English.

2.3.2 CLASSES CHARACTERISTICS

1. Administrator:- he/ she shall be the employee of the university administration
who has been given access to the privileged operations to add details of students
and teachers and update students attendance and internal assessment marks.
They have given a unique user I'd and password. Only after login they can perform
after mentioned functions. They don't required to register themselves.

2. Faculty/ Teachers:- He/ she can also be employee of the university who is also
given user if and password by administration to login and perform the after
mentioned functions. But they don't get access to some specific privileged
operations which the administrator of get

3. Students:- This class contains the functionalities that students can perform.
They have given user id( name, roll no) and password as date of birth to login into
the portal and perform only specified (restricted) operations.
2.4 DESIGN AND IMPLEMENTATION CONSTRAINT
CON-1: SOFTWARE CONSTRAINTS
CON-1.1: Students attendance and internal assessment management system
shall be designed for future upgrade as per needed.

CON-1.2: The application shall meet the general standards of online website
portal.

CON-2: HARDWARE CONSTRAINTS

Hardware environment processor:-Dual core 2nd generation

System configuration or hard disk:-RAM -500 MB

Operating system:-Windows XP /Vista /7/8/8.1/10 iOS

CON-3: ACCEPTANCE CONSTRAINTS

To validate the system, the developers must complete the following:

CON-.1: Providing Demo of the working system and any features upon request.

CON-3.2: All the significant functional requirements are met.

CON-3.3: Sufficient test cases to show that the system is complete and correct.

2.5 ASSUMPTION AND DEPENDENCIES

1. We assume that the admin ,teachers and students are familiar with the
operating software.
 2. We assume that the admin and teachers can can do all the data entry based
on the correct values obtained from the form and registers.

3. We assume that the computer that will use the software be connected with
the college LAN.

4. User's of the type administrator access should be careful in deleting or

modifying any information knowingly or unknowingly which will lead to the
inconsistency of the database.

5. The end users are assumed to have basic knowledge of database.

6. The administrator users are trained to use the software.

 3. SPECIFIC REQUIREMENTS
3.1 EXTERNAL INTERFACE

3.2 FUNCTIONAL REQUIREMENTS

3.3 PERFORMANCE REQUIREMENTS

3.4 LOGICAL DATABASE REQUIREMENTS

3.5 DESIGN CONSTRAINTS

3.6 SECURITY REQUIREMENTS

3.7 SOFTWARE SYSTEM ATTRIBUTES

3.7.1 RELIABILITY

3.7.2 AVAILABILITY

3.7.3 SECURITY

3.7.4 MAINTAINABILITY

3.7.5 PORTABILITY

3.8 DATA FLOW DIAGRAM

3.8.1 CONTEXT LEVEL DIAGRAM

3.8.2 LEVEL -1 DFD

3.8.3 LEVEL -2 DFD

3.9 DATA DICTIONARY

3.10 USE CASE

3.10.1 USE CASE DIAGRAM

3.10.2 USE CASE DESCRIPTION

3. SPECIFIC REQUIREMENTS
3.1 EXTERNAL INTERFACE
The user can interact with the system by using graphical user interface.

3.2 FUNCTIONAL REQUIREMENTS

1. Login

Input:- user id and password by students, admin or teacher

Output:- if successful then the attendance portal will be opened for

further activities to perform.

2. Add faculty details

Input:- department, semester, course, year , faculty code , subject code

given by admin to add or update teachers account

Output:- if successful the teachers details will be added or update or

deleted.

3. Add student details

Input:- department, semester, course, year , roll number , subject code

given by admin to add or update students account

Output:- if successful the students details will be added or update or

deleted.

4. Upload attendance

Input:- roll number, semester, subject, faculty code given by teacher to

upload students attendance.
 Output:- if successful Students attendance will be added and later on
students and teachers can view it.

5.. Upload internal assessment marks

Input:- roll number, semester, subject, faculty code given by teacher to

upload students marks.

Output:- if successful Students marks will be added and later on students

and teachers can view it.

6. Update attendance

Input:- roll number, semester, subject, faculty code given by admin to

updated students attendance.

Output:- if successful Students attendance will be added and later on

students and teachers can view it.

7. Update Internal assessment

Input:- roll number, semester, subject, faculty code given by admin to

update students marks.

Output:- if successful Students marks will be added and later on students

and teachers can view it.

8. Leave exemption

Input :- roll number, no of days.

Output:- Attendence and marks will be given according to that.

9. View

Input :- roll number, name, subject , course

Output:- attendance and marks report is displayed

3.3 PERFORMANCE REQUIREMENTS
There are no particular extra performance requirements at this point of
time.

3.4 LOGICAL DATABASE REQUIREMENTS

The database contains the following information:

1. Credentials details(like login ID or password or college roll number any

thing like this).

2. Details of faculty entered by administrator.

3. Details of the students entered by administrator.

4. Attendance database to store the attendance details of the students.

5. Internal assessment details of the students.

3.5 DESIGN CONSTRAINTS

1. Students doesn't have any write to edit sync kind of data.

2. Teachers can edit only restricted data / information.

3. Non of the user is allowed to perform functionalities (except viewing

the home page and basic functionalities) without login into the portal.

3.6 SECURITY REQUIREMENTS

1. Data is kept secure on various systems so that if it is lost it can easily be
retrieved.
 2. Only authenticated user can use the system to perform operations in
order to keep the system secure.

3.7 SOFTWARE SYSTEM ATTRIBUTES

3.7.1 RELIABILITY
The software will not be able to connect to the centralized database in
the event that the college LAN fails or in the event of the server being down due
to a hardware or software failure.

3.7.2 AVAILABILITY
The software will be available only to the authorized users of the
college like teachers to mark the students attendance , student to view their
attendance and internal assessment marks , admin to add an update students
records.

3.7.3 SECURITY
The security requirement deals with the primary security. The software
should be handled only by the administrator and authorized users using
username and password.

3.7.4 MAINTAINABILITY
Backups for the database are available

3.7.5 PORTABILITY
The software is web based application and is built in php and MySQL so
it is platform independent of operating system.
3.8 DATA FLOW DIAGRAM

3.8.1 CONTEXT LEVEL DIAGRAM

3.8.2 DFD level 1
3.8.3 level 2 dfd

1. Login
2. faculty details
3. student details
4. Attendance upload
5. Internal assessment marks upload
6. Update attendance
7. Internal assessment update
8. leave exemption
9. View report
3.9 DATA DICTIONARY
A dfd is always accomplished by a data dictionary. A data dictionary
lists all data items appearing in a dfd:-

Definition of all composite data items in terms of their component data

items. All data names along with the purpose of data items.

Importance of Data Dictionary Provides all engineers in a project with

standard terminology for all data:-

A consistent vocabulary for data is very important different engineers tend

to use different terms to refer to the same data, causes unnecessary
confusion.

legal_characters= [a-z] or [A-Z]

legal_digits=[0-9]

special_characters= $ or # or @

Name=f_name+(m_name)+l_name.

f_name=(legal_characters)*

m_name=(legal_characters)*

l_name=(legal_characters)*

ID=(legal_characters+legal_digits)*.

password=(legal_characters + legal_digits + special_characters)*

Adate=(legal_digits)*.

Week_no=(legal_digits).*

Period_no=(legal_digits)*.

Admno=(legal_digits)*.
Bcode=(legal_characters+legal_digits)*.

Course=(legal_characters)*.

Sem=(legal_characters)*.

Fcode=(legal_characters+legal_digits)*

Fname=f_name+(m_name)+l_name.

Dept=(legal_characters)*.

Scode=(legal_digits)*.

Stname=f_name+(m_name)+l_name.

Clg_roll_no=(legal_characters+legal_digits)*

Exam_roll_no=(legal_digits)*.

Subject=(legal_characters)*.
3.10 USE CASE

3.10.1 USE CASE DIAGRAM

3.10.2 USE CASE DESCRIPTION

1. Login
1.1 Brief Description

This use case describes how an actor logs into the ‘Students attendance and
internal assessment Management system ’ .

1.2 Actors

Admin

Faculty

Student

1.3 Basic flow

This use case starts when the actor wishes to log in to the system.

The system requests that the actor enter his/her username and
password.

The actor enters his/her username and password.

The system validates the entered name and password and the actor is
then logged in to the system.

1.4 Alternative flow

If in the basic flow, the actor enters an invalid name or password, the
system displays an error message. The actor can use to either return to
the beginning of the basic flow or cancel the login at the point where
use case ends.
 1.5 Special Requirements
None

1.6 Precondition
All actors must have an account created for them in the system prior to
executing the use cases.

1.7 Postcondition
If the use case was successful, the actor is logged in to the system. If not, the
system state is unchanged. Every actor has the access to the corresponding
screens to his/her role.

1.8 Extension point

None

2. ADD FACULTY DETAILS

2.1.Brief description
This use case describes how an actor(admin) adds faulty details into the
system.

2. 2. Actors

Admin

2. 3.Preconditions

Admin should know the teachers faculty code.

2. 4.Postconditions
 If the use case was successful,faculty details are added to the faculty
database by admin. If not successful then details are not added.

2.5 Basic flow

This use case starts when the actor needs to add a faculty to the system .

The system requires the actor to enter teacher’s name and other information
regarding department,year,sem,etc.

The actor then enters all the details.

3. ADD STUDENT DETAILS

3.1.Brief description
This use case describes how an actor adds student details to the system.

3.2. Actors

Admin

3.3.Preconditions

Admin should know the students admission number.

3.4.Postconditions
If the use case was successful, student details are added to the student
database by admin.

3.5.Basic flow
 This use case starts when the actor needs to add a student record to the
system . The system requires the actor to enter student ’s name and other
information such as roll no,course,year,sem,date of birth,etc.

The actor then enters all the details.

4. UPLOAD
4.1.Brief description

This use case describes how an actor uploads attendance or internal assessment
marks

4.2. Actors

Faculty
4.3.Preconditions

Teachers should know the students course, year , semester and subject.

4.4.Postconditions

If the use case was successful, attendance is successfully uploaded so that

students can view it.

4.5.Basic flow
This use case starts when the actor uploads attendance or internal assessment
marks. After entering the subject, semester, course , attendance is uploaded. And
after that teacher and students can view the report.

5. UPDATE CHANGES

5.1. Brief description

This use case describes how an actor updates the desired changes in different
fields in a user’s records.
5.2.Actors

Admin

5.3. Flow of events

a) Basic flow

This use case starts when the actor needs to update the desired changes in
different fields in a user’s records.

5.4.Preconditions
None

5.5.Postconditions

If the use case was successful, the changes are updated in corresponding fields in
the database. If not, the system state is unchanged.

6. VIEW
6.1.Brief description
This use case describes the display of attendance .

6.2.Actors
Student

Faculty

6.3.Preconditions
Attendance or internal assessment marks is successfully uploaded by the faculty
or updated by admin.

6.4.Postconditions
Attendance or internal assessment marks are displayed.

6.5.Basic flow
This use case starts when admin or faculty has uploaded or updated attendance
or internal assessment marks respectively.

After that ,when actor clicks on view button, attendance or internal assessment
marks are displayed.

6.6 Alternative flows

Attendance or internal assessment marks are not uploaded.

7. LEAVE EXEMPTION
7.1.Brief description
This use case describes how an actor can apply for leave exemption.

7.2.Actors
Faculty

Student

7.3.Precondition
None

7.4. Basic flow

This use case starts when student or faculty grants leave from college.

7.5.postcondition
Leave is granted.
 4. DESIGN
4.1 ER DIAGRAM

4.2 DATA DESIGN

4.3 COMPONENT LEVEL DESIGN

4. DESIGN

4.1 ER DIAGRAM
4.2 DATA DESIGN
The data objects, attributes, and relationships depicted in entity relationship
diagrams and the information stored in data dictionary provide a base for data
design activity.

Name:- Faculty

When used/ how used:- to store faculty code, their department and name ,to
upload attendance and to upload marks.

S.no Field Data type Description Key Constraints

name

1. Fcode Varchar(15) Used to store faculty NOT NULL, PRIMARY

code KEY

2. Pwd Varchar(15) Used to store the NOT NULL

password of faculty

3. Fname Varchar(50) Used to store faculty NOT NULL

name

4. Dept Varchar(50) Used to store faculty NOT NULL

from which
department

Name: ADMIN

Where used/ how used- to add student, to add faculty ,to update attendance,to
update marks , to notify faculty teacher.
S.no Field Data type Description Key Constraints
name

1 Name Varchar(50) Gives name to the NOT NULL

admin

2 Id Varchar(15) Primary key, gives Id NOT NULL, PRIMARY

to the admin KEY

3 Password Varchar(15) Used to login into the NOT NULL

software.

Name: Attendance

When used/ how used:- to store the attendance parameters depending upon
weather the attendance is day wise or monthly.

S.no Field Data type Description Key Constraints

name

1. Adate Date time Store date and time of the NOT NULL
period

2. Week_no Int Store week number NOT NULL

3. Period_no Int Store period number NOT NULL

4. Fcode Varchar(15) Store faculty code NOT NULL,

FOREIGN KEY

5. Adm_no Int Admission number NOT NULL,

PRIMARY KEY

6. Status Char(1) Status of the student means NOT NULL

S.no Field Data type Description Key Constraints
name

absent or present or on
leave

7. Remark Varchar(50) It will give remark of the NOT NULL

student that he's on leave
or not.

Name:- student

When used/ how used :- student can see their attendance,internal assessment
marks and many more through college roll number or examination roll number or
admission roll number.

S.no Field name Data type Description Key Constraints

1. Admin_no Int Store the student's NOT NULL,

admission number PRIMARY KEY

2. Bcode Int Store batch code NOT NULL

3. Stname Varchar(50) Store student's NOT NULL

name

4. Clg_roll_no Int Store college roll NOT NULL,

number PRIMARY KEY

5. Exam_roll_no Int Store exam roll NOT NULL,

number PRIMARY KEY
Name:- Batches table

When used/ how used:- to store the batch number of the students, their
semesters and courses.

S.no Field Data type Description Key

name Constraints

1. Bcode Int To store the batch code NOT NULL

2. Course Varchar(50) Used to store the student's NOT NULL

stream

3. Sem Int Used to store the semester of NOT NULL

the student

Name :- subject

When used / how used:- to store which teacher is teaching which subject to
students .

S.no Field Data type Description Key Constraints

name

1. Scode Varchar(15) Used to store subject NOT NULL, PRIMARY

code KEY
S.no Field Data type Description Key Constraints
name

2. Sname Varchar(50) Used to store subject NOT NULL

name

Name:- internal assessment

When used/how used :- to upload the internal assessment marks of students in

each subjects so that students can check it
S.no Field name Data type Description Key Constraint

1. Type Varchar(50) Store the type of paper. NOT NULL

2. Fcode Varchar(50) Store the faculty code NOT NULL

3. Adm_no Int Store the admission roll number NOT NULL,

PRIMARY KEY

4. Scode Varchar(50) Store the subject code NOT NULL,

FOREIGN KEY

5. Marks Int Store the marks in the subject NOT NULL

Name:- Leave

When used/ how used:- if the student has taken any leave , then it store the
duration of the leave and reason with the students admission roll number.
S.no Field name Data type Description Key Constraints

1. To_dt Int The leave has been taken which NULL

date

2. From_dt Int The leave has been taken from NULL

which date

3. Reason Varchar(100) Reason for the leave NULL

4. Adm_no Int Admission roll number NOT NULL,

PRIMARY KEY

Table:- Teaches

When used/how used:- to show which how many teachers teaching same subject
or how many subjects taught by how many teachers.

S.no Field name Data type Description Key Constraints

1. No_of_faculty Int Stores the number of faculty NULL

member teaching same subject

2. No_of_subject Int Stores no of subjects taught by NULL

same faculty member

3. Fcode Varchar(15) Store unique faculty code NOT NULL,

PRIMARY KEY

4. Scode Varchar(15) Stores unique subject code NOT NULL,

PRIMARY KEY
 4.3 COMPONENT LEVEL DESIGN
Attendancemarks()

1. For(i=0 to total number of subjects)

2. conducted[i]=sum of total lecture conducted in each subject.

Endforloop

3. For(i=0 to total number of subjects)

4. attended[i]=sum of total lecture attended by Student in each subject.

Endforloop

5. For(i=0 to total number of subjects)

6. attendance [i]= conducted [i]/attended [i]

at_percentage[i]=attendance [i] / 100

Endforloop

7. For(i=0 to total number subjects)

8. If(at_percentage[i] >= 0.85)

9. Marks[i]=5

10. Elseif(at_percentage[i]<0.85 and at_percentage[i]>=0.80)

11. Marks[i]=4

12. Elseif(at_percentage[i]<0.80 and at_percentage[i]>=0.70)

13. Marks[i]=3

14. Elseif(at_percentage[i]<0.70 and at_percentage[i]>=0.60)

15. Marks[i]=2

16. Elseif(at_percentage[i]<0.60 and at_percentage[i]>=0.50)

17. Marks[i]=1

18. Else

19. Marks[i]=0

20. Endifelse

21. Endforloop

Endfunction
 5. ESTIMATION AND SCHEDULING
5.1 PROJECT SCHEDULING

5.2 TIMELINE CHART

5.3 SIZE ESTIMATION (FUNCTION BASED METRICS)

5.4 COST ESTIMATION (COCOMO II MODEL)

5. ESTIMATION AND SCHEDULING

5.1 PROJECT SCHEDULING

5.2 TIMELINE CHART
5.3 SIZE ESTIMATION (FUNCTION BASED METRICS)
Function oriented metrics use function point as normalization value. Function
points are derived using empirical relationship based on countable measure of
software’s information domain and qualitative assessments aof software
complexity.

To compute function points (FP), the following relationship is used:

FP= count total * [0.65 + 0.01 * ∑(fi)]

where count total is the sum of all FP entries obtained from the
following table:

Information Count Weighting

Domain value Factor
Simple Complex
Average
External 109 3 327
4 6
inputs(EIs)

External 23 7 92
4 5
output(EOs)

External 7 21
3 4 6
inquiries(EQs)

Internal Logical 20 10 15 140

7
files(ILFs)

External interface 0 5 10 0
7
files(EIFs)

Count total = 327+92+21+140= 580

The fi (i= 1 to 14) are value adjustment factors (VAF) based on following
responses:
Does the system require reliable backup and recovery? 4
1.
Are specialized data communications required to transfer 1
2.
information to or from the application?

Are there distributed processing functions? 3

3.
Is performance critical? 2
4.

5. Will the system run in an existing, heavily utilized operational 4

environment?

6. Does the system require online data entry? 5

7. Does the online data entry require the input transaction to be built 5
over multiple screens or operations?

Are the ILFs updated online? 5

8.
Are the inputs, outputs, files, or inquiries complex? 1
9.

10. Is the internal processing complex? 2

11. Is the code designed to be reusable? 3

12. Are conversion and installation included in the design? 0

Is the system designed for multiple installations in different 3

13 . organizations?
 Does the system require reliable backup and recovery? 4
1.

14. Is the application designed to facilitate change and ease of use by 3

the user?

Total fi 41
Therefore,
Fp=(580 )*[0.65+(0.01*41)]
= 580*[0.65+0.41]
= 580*[1.06]
= 614.8
5.4 COST ESTIMATION (COCOMO II MODEL)
COnstructive COst MOdel (COCOMO II) is a more comprehensive estimation
model. COCOMO II is actually a hierarchy of estimation models that address the
following areas

• Early design stage model - Used once requirements have been stabilized and
basic software architecture has been established

.• Post-architecture-stage model - Used during the construction of the

software.The COCOMO II models require sizing information.

Three different sizing options are available as part of the model hierarchy

: • object points

• function points

• lines of source code

The object point is an indirect software measure that is computed using counts of
the number of

(1) screens (at the user interface),

(2) reports, and

(3) components likely to be required to build the application. Each object instance
is classified into one of three complexity levels based on the following table -

Object type Simple Medium Difficult

Screens 1 2 3

Records 2 5 8

3GL components 10

NOP = (object points) X [(100 - % re-use)/100]

where NOP is defined as new object points.

PROD = NOP / person-month

Figure – Productivity rate for object points

Developers Very low Low Normal High Very high

Experience/capabilities

Environment maturity / Very low Low Normal High Very high

capabilities

PROD 4 7 13 25 50

Estimated effort = NOP / PROD

COCOMO Estimation for our project –

Number of screens = 22

Number of reports = 2

Number of 3GL components used = 0

Person month = 4

In our project, there are simple screens and reports.

So, Object point = 22*1 + 2*2

= 22+4= 26

we’are not re-using any of the components in our project, the % re-use is zero
here.

NOP = 26 * [(100-0)/100]

= 26

,Estimated Effort = 26/7 = 3.7 ~ 4 person-month

 6. RISK ANALYSIS
ASSESSING OVERALL PROJECT RISKS
1. Have top software and customer managers formally committed to support the
project? YES

2. Are end users enthusiastically committed to the project and the system product
to be built? YES

3. Are requirements fully understood by the software engineering team and its
customers? YES

4. Have customers been involved fully in the definition of requirements? YES

5. Do end users have realistic expectations? YES

6. Is the project scope stable? YES

7. Does the software engineering team have the right mix of skills? YES

8. Are project requirements stable? YES

9. Does the project team have experience with the technology to be

implemented? YES

10. Is the number of people on the project team adequate to do the job? YES

11. Do all customer/user constituencies agree on the importance of the project

and on the requirements for the system/product to be built? YES
S.no Risk Category Probability Impact Exposure RMMM
p I E=p*I MODEL

1. Wrong Business 10% 3 0.3 We should

budget risk have some
estimation extra
backup
budget

2. Some team Technical 20% 2 0.4 We should

members risk use back
on leave up staff
who
already
know
whats
going on in
the project

3. Hard Disk Project risk 20% 2 0.4 Backup

failure project to
every team
member

4. Lack of Project risk 10% 3 0.3 Make rules

cohesion to consult
each other
 7. TESTING
7.1 CONTROL FLOW GRAPH

7.2 CYCLOMATIC COMPLEXITY

7.3 BASIC PATH SET

7. TESTING
We are performing white box testing for giving MARKS to the students on the
basis of their ATTENDENCE

Pseudo code for attendance marks

Attendancemarks()

1. For(i=0 to total number of subjects)

2. conducted[i]=sum of total lecture conducted in each subject.

Endforloop

3. For(i=0 to total number of subjects)

4. attended[i]=sum of total lecture attended by Student in each subject.

Endforloop

5. For(i=0 to total number of subjects)

6. attendance [i]= conducted [i]/attended [i]

at_percentage[i]=attendance [i] / 100

Endforloop

7. For(i=0 to total number subjects)

8. If(at_percentage[i] >= 0.85)

9. Marks[i]=5

10. Elseif(at_percentage[i]<0.85 and at_percentage[i]>=0.80)

11. Marks[i]=4

12. Elseif(at_percentage[i]<0.80 and at_percentage[i]>=0.70)

13. Marks[i]=3
14. Elseif(at_percentage[i]<0.70 and at_percentage[i]>=0.60)

15. Marks[i]=2

16. Elseif(at_percentage[i]<0.60 and at_percentage[i]>=0.50)

17. Marks[i]=1

18. Else

19. Marks[i]=0

20. Endifelse

21. Endforloop

Endfunction

7.1 CONTROL FLOW GRAPH

 7.2 CYCLOMATIC COMPLEXITY

V(G) = Number of regions

= 10

V(G) = Edges – nodes + 2

= 29 – 21+ 2

= 10

V(G) = Predicate nodes + 1

= 9+1

=10

7.3 BASIC
PATH SET
Path
1 – 1 -2 -3 -4
-5 -6 -7 -8 -9-
20-21

Path 2
– 1 -2 -3 -4 -
5 -6 -7 -8-10-
11-20-21

Path 3
- 1 -2 -3 -4 -
5 -6 -7 -8-10-
12-13-20-21
Path 4 – 1 -2 -3 -4 -5 -6 -7 -8-10-12-14-15-20-21

Path 5 - 1 -2 -3 -4 -5 -6 -7 -8-10-12-14-16-17-20-21

Path 6 - 1 -2 -3 -4 -5 -6 -7 -8-10-12-14-16-18-19-20-21

Path 7 - 1 -2 -3 -4 -5 -6 -7 -21

Path 8- 1-3-5-7-21

Path 9- 1-2-3-4-5-6-7-20-21

Path 10- 1-3-5-7-8-9-20-21

8. Annexure. Screen 2.
No. of External Inputs:0. No.of External Inputs:6

No. of External Outputs:2. No.of External Outputs:1

No. of External Inquiries:0. No.of External Inquiries:0

No. of internal logical files:0. No.of internal logical files:1

No. of external interface files:0. No.of external interface files:0

Screen 3. Screen 4.

No. of External Inputs:4 No. of External Inputs:4

No. of External Outputs:1 No. of External Outputs:1

No. of External Inquiries:0 No. of External Inquiries:0

No. of internal logical files:1 No. of internal logical files:1

No. of external interface files:0. No. of external interface files:0

Screen 5. Screen 6

No. of External Inputs:1. No.of External Inputs:1.

No. of External Outputs:1. No. of External Outputs:1

No. of External Inquiries:0. No. of External Inquiries:0

No. of internal logical files:0. No. of internal logical files:1

No. of external interface files:0. No. of external interface files:0

Screen 7. Screen 8.

No. of External Inputs:1 No. of External Inputs:1

No. of External Outputs:1. No. of External Outputs:1

No. of External Inquiries:0. No. of External Inquiries:0

No. of internal logical files:1. No. of internal logical files:1

No. of external interface files:0. No. of external interface files:0

Screen 9. Screen 10.

No. of External Inputs:3. No. of External Inputs=10

No. of External Outputs:1. No. of External Outputs=1

No. of External Inquiries:0. No. of External Inquiries:0

No. of internal logical files:1. No. of internal logical files:1

No. of external interface files:0. No. of external interface files:0

Screen 11. Screen 12.

No. of External Inputs:3. No. of External Inputs:15

No. of External Outputs:1. No. of External Outputs:1

No. of External Inquiries:1. No. of External Inquiries:1

No. of internal logical files:1. No. of internal logical files:1

No. of external interface files:0. No. of external interface files:0

Screen 13. Screen 14.

No. of External Inputs:10 No. of External Inputs:10

No. of External Outputs:1 No. of External Outputs:1

No. of External Inquiries:1 No. of External Inquiries:1

No. of internal logical files:1 No. of internal logical files:1

No. of external interface files:0. No. of external interface files:0

Screen 15

No. of External Inputs:5

No. of ExternalOutputs:1

No. of External Inquiries:1

No. of internal logical files:1

No. of external interface

files:0

Screen 16.

No. of External Inputs:4

No. of External Outputs:1

No. of External Inquiries:0

No. of internal logical files:1

No. of external interface files:0

Screen 17.

No. of External Inputs:2

No. of External
Outputs:1

No. of External
Inquiries:0

No. of internal logical

files:1

No. of external interface

files:0

Screen 18.

No. of External Inputs:1

No. of External
Outputs:1
No. of External Inquiries:0

No. of internal logical files:1

No. of external interface files:0

Screen 19.

No. of External
Inputs:2

No. of External
Outputs:1

No. of External
Inquiries:0

No. of internal logical

files:1

No. of external
interface files:0

Screen 20.

No. of External Inputs:0

No. of External Outputs:1

No. of External Inquiries:0

No. of internal logical files:1

No. of external interface files:0

Screen 21 Screen 22.

No. of External Inputs:13 No. of External Inputs:13

No. of External Outputs:1 No. of External Outputs:1

No. of
External
Inquiries:1
No. of
External
Inquiries:1
No. of internal logical files:1 No. of internal logical files:1

No. of external interface files:0. No. of external interface files:0

Report 1

Report 2
1.4 REFERENCES
We have taken references from various websites and some of them are:-

1.https://www.google.com/url?sa=t&source=web&rct=j&url=https://www.slideshare.net/
mobile/shubhamrastogi11/srs-student-attendance-management-system&ved=2ahUKEwi6-
7O3h9zhAhWV63MBHVkDA2IQFjAAegQIBhAC&usg=AOvVaw3a0Sa3GF6Jd8TRjnTGGerP&cshi
d=1555674325339

2.https://www.google.com/url?sa=t&source=web&rct=j&url=http://
www.westfallteam.com/sites/default/files/papers/
Basis_Path_Testing_Paper.pdf&ved=2ahUKEwjetqyfhdzhAhUKvY8KHbVhCVcQFjABegQIDhAE
&usg=AOvVaw37G4je6tV8qrsOJUFWzVG2

3 https://www.google.com/amp/s/www.geeksforgeeks.org/software-engineering-cocomo-
model/amp/

4.https://www.google.com/amp/s/www.youth4work.com/talent/software-engineering/
forum/126375-what-is-data-dictionary-and-what-are-the-importance-of-data-dicyionary
%3famp=true

5.1. R.S. Pressman, Software Engineering: A Practitioner’s Approach, McGraw-Hill, Edition

7,2010.6. P. Jalote, An Integrated Approach to Software Engineering, Narosa Publication
House, Edition 3, 2011