Documentation For Software Engg Project

Education Management System 1
Education Management System
SUBMITTED BY :
Ryan Prasad (PT0881151)
Abhishek Kumar Jha (PT0881155)
1
Contents
Certificate ............................................................................. Error! Bookmark not defined.
APIIT SD INDIA | PANIPAT

Acknowledgement ................................................................................................................ 5
Chapter 1: Introduction ........................................................................................................ 6
Requirements Analysis .......................................................................................................... 7
Objectives of the new system ................................................................................................ 7
Requirements Analysis .......................................................................................................... 7
Normal Requirements ........................................................................................................... 7
Expected Requirements ......................................................................................................... 8
Chapter 2: Schedule planning-schedule network and Gantt chartError! Bookmark not

defined.
2.1 Gantt chart Screen Shot of the Gantt Chart(The Gantt chart approved and signed by the
supervisor has been attached at the end of document.) ........... Error! Bookmark not defined.
2.2. Schedule Network .......................................................... Error! Bookmark not defined.
2.2. Schedule Network .......................................................... Error! Bookmark not defined.
Chapter 3: Selection of methodology..................................................................................... 9
Status of development team:................................................................................................ 10
Involvement of user: ........................................................................................................... 10
Type of project and associated work:................................................................................... 11
Scope of Spiral Analysis ................................................................................................. 12
The reason why we have used Spiral model: ....................................................................... 13
Chapter 4: Problem Analysis-Current System...................................................................... 14
Problems related with the Admin ........................................................................................ 15
Major problem related to the Education system ................................................................... 15
Chapter 5: Overview: Proposed system ............................................................................... 16
The following module was identified: ................................................................................. 16
Assumptions Made: ............................................................................................................. 16

2
Major Functionalities: ......................................................................................................... 18
Chapter 6: Process Model for Proposed Systems ................................................................. 20

6.1. Context Diagram .......................................................................................................... 20
6.2 Level 0 DFD .......................................................................................................... 21
6.3 Level 1 DFDs ................................................................................................................ 25
Process 3.0 Level 1 DFD ..................................................................................................... 25
6.4 Level 2 DFDs ................................................................................................................ 29
6.5 Process Specification ..................................................................................................... 33
Structured English ............................................................................................................... 33
Decision table ..................................................................................................................... 37
Decision Tree ...................................................................................................................... 37
7.1 Entity Relationship Diagram ...................................................................................... 38
Chapter 8: Data Dictionary for Proposed Systems ............................................................... 41
8.1. External Entity ............................................................................................................. 41
8.2. Process ......................................................................................................................... 42
8.3. Data Stores ................................................................................................................... 43
8.4. Data Flows ................................................................................................................... 46
Chapter9: Event Model ....................................................................................................... 49
Entity Life History .............................................................................................................. 49
10. Object-Oriented Design ................................................................................................. 55 3
Use Case Diagram ............................................................................................................... 55

Use Case Diagram for Admin.............................................................................................. 58
Use Case Writing For Admin .............................................................................................. 58
Use Case Diagram for FACULTY ...................................................................................... 60
Writing Use Case for FACULTY ........................................................................................ 60
Use Case Diagram for Student ............................................................................................ 62
Writing Use case: ................................................................................................................ 63
11. Interactive Screen Design .............................................................................................. 64
Chapter11: Programming Environment ............................................................................... 77
Development tools: ............................................................................................................. 77
Documentation tools: .......................................................................................................... 78
The Front End and Back End .............................................................................................. 78
Justification why we used PHP with Dream Weaver as a development tool: ........................ 78
Justification for using MySQL: ........................................................................................... 79
Conclusion .......................................................................................................................... 80
References .......................................................................................................................... 81

Acknowledgement
First, I, thank our lecturer and advisor,( Mr. Ankur Singla) for his continuous support towards
the learning the subject matter. He was always there to listen and to give fruitful advice.
He taught us how to ask questions and express our ideas. He showed us different ways to
approach a research problem and the need to be persistent to accomplish any goal.
He is the most responsible for helping us complete the writing of this dissertation as well as
the challenging research that lies behind it. He has been a friend and mentor. He taught us
how to write academic papers and had confidence in us when we doubted ourselves, and
brought out the good ideas in us. (More importantly, he taught us how to work hard and
play hard, and how to reduce stress!) Without his encouragement and constant
guidance, we could not have finished this dissertation.
We would like to thank almighty for being a source of constant spiritual support and guiding
us towards the successful completion of this project.
We would like thank our friends for always helping us out.
Finally a special thanks to our parents who have always stood besides us and supported by
every other fair means.

Chapter 1: Introduction
In modem 21st century, technological developments and the need to beat the heat of
increasing competition has made life very fast. In such scenarios we need automated
solutions for ensuring fast and accurate completion of work. This module also demands a
Management System for College APIIT.
The management of the College decided that they will have to invest in a new information
management system (called Education Information System– EMS) to systematically manage
the things.
The management software will be used to handle and manage the system. With the help of
this system the administrator will be able to register the new Student and new Faculty
member who will be associated with the APIIT Organisation. The management will be able
to keep track record of the Information of Student like Attendance, profile, Branch,
Programm etc.
There will be a consistency in the maintenance of the Student or Faculty as the maintenance
Manager (Admin) will be able to see the maintenance schedule of course. Lecture Course
will be able to handle Faculty as per their qualification .Feedback and query will also be
handled by this system. The Course of the student will be incremented automatically with
some predefined values.
There are 4 modules in Education management System.
 Admin Module
 Faculty Module
 Student Module
 Unregistered Student (Placement/Counselling) Module

Requirements Analysis
Requirements Analysis includes those tasks that help in determining the needs or
conditions required to develop or alter a product, taking in account of the possible
conflicting requirements of the various users and beneficiaries.
Objectives of the new system

 The main objective of developing this system is to automate Education
Management System. This will benefit a large number of bodies in the
organization for example Faculty, Administrator, and Student etc.
 Second Objective of developing this system is to allow the Administrator to
manage the Student and faculty.
 Economize in terms of effort and time
 Fast and accurate in performance.
 Organizing data and prevent any data loss.
Requirements Analysis
Normal Requirements
1. The system must allow administrator to add, edit, delete and update Student’
profiles that are a part of the Education Management System.
2. The system must be able to generate Report for Attendance apparels of the Student.
3. The Admin should be able to enter the Student details which in turn will be
forwarded to the Faculty for taking the attendance every day.
4. The system must be able to generate reports of the Student profile and absent
report of the Student incurred in the maintenance of the Class Attend.

Expected Requirements
1. The system must be able to provide proper access to the different
categories of user. For instance a Student can just view Profile; Admin
Manger can able to register the student and faculty information and
maintain their profile etc.
2. The system must be able to update the records.
3. The system must be able to handle the profiles of the Student of the
organisation.
4. The system must be able to handle the Maintenance of Attendance details
of the Student.

Chapter 3: Selection of methodology

The ultimate objective of software engineering is to produce good quality software within
reasonable time frame. This is only achievable if we have matured process to develop it.
Software development organization follows some process when developing a software
product. The key component of any software development process is life cycle model on
which process is based. The particular life cycle model can significantly affect over all life
cycle costs associated with a software product. Life cycle of the software starts from concept
exploration and ends at the retirement of software.
The selection of methodology is based on the following characteristics:-
1. Requirement
2. Development team
3. Users
4. Project type and associate risk
Characteristic of requirement:
Requirement is very important for the selection of any model. There are a number of
situations and problem during requirement gathering and analysis.
Requirement Waterfall Prototype Spiral RAD Iterative
Are requirements easily Yes Yes No No Yes

understandable and define?
Do we change requirement No Yes Yes No Yes

often?
Can we define requirement Yes Yes No No No

early in the cycle?
Requirements are indicating No Yes Yes Yes Yes 9

a complex system to be built

Status of development team:

The status of the development team in terms of availability, effectiveness, knowledge,
intelligence, team work etc., is very important for the success of the project. If we know
above mentioned parameters and characteristics of the team, then we may choose an
appropriate life cycle model for the project.
Less experience on similar No Yes No No No

projects
Less domain knowledge(new to Yes Yes Yes No Yes

the knowledge)
Less experience on tools to be Yes Yes No No No

used
Availability of training if required No No No Yes Yes
Involvement of user:
User involvement is the key concept in the development of useful and usable systems and has
positive effects on system success and user satisfaction. Hence user participation, if available,
plays a very significant role in the selection of methodology.
User involvement in all phases No Yes Yes No No
Limited user participation Yes No No Yes Yes
User have no previous No Yes Yes No Yes

experience of participation in
similar project
Users are expert in problem No No No No Yes

domain
10

Type of project and associated work:

Very few models incorporate risk assessment. Project type is also important for the selection
of methodology.
Project is the enhancement of the No No No No Yes

existing system
Funding is stable for the project No Yes Yes Yes No
High reliability requirement No No No Yes Yes
Tight project schedule Yes Yes Yes No Yes
Use of reusable component No Yes Yes No No
Are resource (time, money, people, No Yes Yes No No

etc.,) scarce?
To develop the system of Education Management System we have not used any traditional
method or approach rather we have used the Spiral Model. The Spiral model that we used is
the combination of two traditional models i.e., Waterfall and Agile model. These both models
were very successful in the software development but combining these two models results in
a better action. This approach allows the development team to make changes to the system
early in the project if problems occur with the high-risk components.
11
Fig1.1

Spiral model is an evolutionary version of incremental prototyping, developed by Boehm in

1988. Each iteration of the prototype represented as a cycle in the spiral. The Spiral software
development model is a risk-oriented.
Spiral software development model may be applicable to projects where:
 The projects requirements are very difficult
 Where new technologies are used
Scope of Spiral Analysis
The scope of Spiral Analysis is to provide quality improvements in:
The next Phase of the current project

New projects
Following are some of the steps for Spiral analysis exercise:
Fig 1.2 Stage of Spiral Method
12

The reason why we have used Spiral model:

 The basic objective of using Spiral is that we can develop high quality system at a
relatively low cost.
 We would be able to reduce the risk factor as we will divide the project into smaller
segments.
 Through prototyping model we will be able to have active user involvement.
 Project will be completed in time. If the project slips the deadline then it will be
adjusted according to the time box.
 Produce a tighter fit between user and specification.
 Small scale system is developed in initial stage to meet the user requirements.
 There is always a chance of improvement.
 Improves user participation and communication among stakeholders.
 Provides quick and easy development of the segments.
 Provides flexible design for the development.
 Our project was quit large and it was taking the quit good ample time. We were not
fully confirmed of the finale requirement.
 Our users were not very much expert about their need and they was discovering theit
needs in the later use.
 We had to discover the estimated budget of the project at the very earl steps.
 We had to put our hand earlier on to the project for its development.
 We had involved the users at the every steps of the project development.
 We did not want any uneven activity to occur at the later stage. So we were interested
in vanishing the risk at the development step, so we decided to take the spiral model
for our project development.
Advantages: 13
 High amount of risk analysis
 Good for large and mission-critical projects.

 Software is produced early in the software life cycle
Disadvantages:
 Can be a costly model to use.

 Risk analysis requires highly specific expertise.
 Project's success is highly dependent on the risk analysis phase.
 Doesn't work well for smaller projects.
Chapter 4: Problem Analysis-Current System
The most important problems could arise while taking the management decisions, if no
computerized system is there and much of the paper work has to be referred to take decisions
which can be the time consuming job.
As this is based on Education System so it would have been tough job to maintain
everything manually. Because as the number of Student increases it is not feasible to
maintain details about the Student and Faculty and retrieve information easily.
Problems that could have been faced based on Student details are as follows:
 Adding new Student’s details about each and every Student would have consumed
much time. Also updating details about the Student manually would have been the
much complex task.
 Also it would have been very complex job manually to calculate and maintain the
Attendance of Students.
Problems that could have been faced related with the Faculty Details are as follows.
 It would have been the tough job to maintain all the details about the Faculty
manually.
 Also the details of taking attendance by the faculty maintaining would have been
the complex process manually.
14

Problems related with the Admin

 Record maintenance of faculty as well as student has been not possible manually.
 Also all the details about the profile, course, programs and every other detail
about the program of college are hard to maintain manually.
 Report collected at faculty by any means such as attendance summary, No of
student absent would have been the complex job to maintain.
Major problem related to the Education system

 Calculating the Attendance Summary for each and every Student is very complex.
 Also same is the problem for the faculty.
 Claims that the Student is absent could not be given accurately through manual
system.
 Also much of the details have to be viewed and much paper work has to be done
for the calculating of attendance for the students.
Student could not express their feeling in front of whole class easily. Feedback can be the
solution. These existing problems need to be sorted in order to maintain Education
Management System in efficient and flexible manner.
15

Chapter 5: Overview: Proposed system
The following module was identified:

 Registration
 Program Allocation
 Attendances Management
 Faculty Management
 Course Management
 Feedback Management
Assumptions Made:
The following assumptions were made while making the system
1) The above roles and persons are present in person

2) The admin is the administrator
3) Some maintenance activities are scheduled and some are miscellaneous
16

Roles and Permissions:
ROLE PERMISSION
 View Profile
Student
 Edit profile
 View Attendances
Edit own Profile
Message Send
 Student registration
Administrator
 Faculty registration
 Report
 Course Allocation
 Program Allocation
 Attendances Review
 Message Send
 Database update
Faculty  View Profile

 Edit profile
 Take Attendances
 Message Send
17

Major Functionalities:
The proposed system will implement in PHP as its front end and MYSQL as its back end.
The main functionalities of the system are:-
Module Functionality
Registration Registration of new Student
Attendances Management Attendances are managed by the faculty as

well as admin.
Course Maintenance Maintenance of Course(assign the course to

faculty as well as assign to student)
Student Management Student management along with their profile
 Attendances
 Message Response
 Course Assign
 Program Assign
Faculty Management Manage the profile of the faculty; generate

the attendance sheet,
Program Management Program Management consists Student’s

leave module, Student’s schedule
management and Student’s history
management
Bold rimmed bubbles contain activities we suggest can be done by utilising a database. 18
Normal bubbles contain activities which will be facilitated by a database but which still

require the user to do part of the job. Dashed bubbles contain the activities which cannot be
replaced by a database - or which are obviously not worth replacing.
The probable database system is enclosed in the doughnut
19

Chapter 6: Process Model for Proposed Systems
6.1. Context Diagram
20

6.2 Level 0 DFD
21

22

23

24

6.3 Level 1 DFDs
Process 3.0 Level 1 DFD
25

26

27

28

6.4 Level 2 DFDs
29

30

31

32

6.5 Process Specification
Structured English
Process 1.0 Authenticate
Read Username and Password
IF Username and Password Correct Then

Redirect to Home Page
ELSE
Redirect to Error Page
END IF
Process 2.0: Student registration
READ Student details
SELECT CASE
CASE 1(first name is anything other than alphabets)
Give msgbox” enter only character value in first name”
CASE 2(Father Name is anything other than alphabets)
Give msgbox” enter only character value in father Name”
CASE 3(sex is anything other than alphabets)
Give msgbox” enter only character value in Sex”
CASE 4(email is alphanumeric and not in proper format)
Give Msgbox” Please enter the required format of email”
CASE 5(Address include alphanumeric, than alphabets)
Give msgbox” enter the proper format of address”
CASE 6(city is anything other than alphabets)
Give msgbox” enter only character value in city”

33
CASE 7(Batchid is anything other than alpha numeric)
Give msgbox “Please enter a valid ID”

CASE 8(all fields entered in desired manner)
Give msgbox “Student is successfully registered”
END CASE
Process 5.0 Message
Write Email ID of Particular People
IF Emailed Valid
Send Message to Particular people

ELSE
Failure Message
END IF
Process 3.0: program
READ Program Name
SELECT CASE
CASE 1(program name is anything other than charter values)
Give mgsbox ”enter valid program name”
CASE 2(batch Name is anything other than charter value)
Give mgsbox ”enter charter value”
CASE 3(batch id is anything other than numeric value)
Give mgsbox”enter numeric value”
CASE 4(no of student is anything other than numeric value)
CASE 5(status is anything other than numeric value)
CASE 6(all fields entered in desired manner)
Give msgbox “added Program Successfully” 34

END CASE

1.0 Authenticate
Read Username and Password
IF Username and Password Correct Then

Redirect to Home Page
ELSE
Redirect to Login Page
END IF
3.4 Add Subject
READ the input data

IF No subject Assigned to the batch Then
Add subject to the Batch
Update Student Database
ELSE
No subject can be added
Give Message to ADMIN
END IF
3.4.3 UPDATE Subject
Read the Input data

IF subject available in attendance in same semester and batch THEN
Subject will not Updated
Else
Store the subject name in a array.
END IF
IF batch name and semester name match with the database batch name and semester name
THEN
Store all the subjects of that batch name and store in a array.
Assigned array value to the combo box
Admin can select the value and update it
ELSE
No Update can be done
END IF.
3.5 Assign Faculty
READ the desired data

IF no faculty assigned to desired subject THEN
Select the Faculty name and assign it
ELSE
Faculty name cant be added
Send Message to Admin 35
END IF
6.1 Take Attendance

READ the requested data

IF batch name and subject matches to the database THEN
Take attendence
ELSE
No Students available
END IF
6.1 Modify Attendance by intake id
READ the requested data

IF batch name, subject, Intake ID and Date matches to the database THEN
Modify Attendance
ELSE
No attendance available
END IF
36

Decision table
Decision Table:
No charges are reimbursed to the Student until the absent has been met. After the absent has
been met, reimburse Rs 2 for Medical Certificate or Rs 8 for Without Medical Certificate.
There will be 4 rules. The first condition (Is the absent met?) has two possible outcomes, yes
or no. The second condition (type of absent) has two possible outcomes, Medical Certificate
with absent or Without Medical Certificate .Two times two is four.
Conditions 1 2 3 4
1. Absent met? Y Y N N
2. Type of Absent M WM M WM
Actions
1. Rs 2 X
2. Rs 8 X
3. No reimbursement X X
Decision Tree 75%Attendence or more
Allow
Minimum 60% with
Medical (Acceptance)
Exam
Not Allow
Less then 60% without 37

Medical
Less then 60%

Attendance Verification for exam APIIT SD INDIA | PANIPAT
Medical Not Accepted
Allow
Authentication
Success
Login
Authentication
Not Allow Fail
Authentication of Admin
Allow for
<=60
Registration
No of Seat
DO Seat is full
READ >60
Username
and Check Seat Availability
password
IF
Username
=True and
Password
=True
THEN
W
RITE
38
Batch ID, 7.1 Entity Relationship Diagram
Program,
The ERD has been designed using “Crow Foot” notation. The legend for the same has been
Course
given below:
and date
READ
Attendanc
e of
Legendi
Mandatory
1
Mandatory
Many
Optional Many
Optional 1
39

40

Chapter 8: Data Dictionary for Proposed Systems
8.1. External Entity

Name Student
Description Studying in APIIT SD INDIA
Input Data Flow Login details, Profile Change Request, Attendance view Request
Send Messages , Update Profile, Update Password, Attendance

Output Data Flow
Record
Name Admin
Maintain and keep track of the records of Students, Faculty and

Description
Batches.
Register Students, Faculties, Maintain Batch, Create New Program,

Input Data Flow assign Subject and Module Lecturer
Attendance Details, View College Batches, Program and its

Output Data Flow
subjects, Read Messages.
Name Faculty
Description Teaching In APIIT SD INDIA College
Input Data Flow Take Attendance, Log In details, Request for Change Password.
Output Data Flow Attendance Report, Defaulter Report, Read Messages
41

8.2. Process
Name 3.0 Manage Program
Description Manages all the program, Subject and Batch of the College.
Input Data Flow Retrive Batch Status, Availablity, Request for change the data
related to Batches, Retrieve Subjects, Retrieve Module Lecturer.
Output Data Flow Batch and Program Information, Subject Information, Update
Subject, Module lecturer details.
Process Description If
Batch Registered
Add Subject
Add Batch id
Add Module Lecturer
Entire Program Details
End If
If
Not Batch Found
No action will be done.
Name 4.0 Check Profile
Description Will be able to check the profile, change Password, Edit Profile
and See the Teacher’s Profile.
Input Data Flow Request for Profile, Request to edit and change the password of
Profile..
Output Data Flow Profile Information, Change Password, Edit Profile and faculty’s
Profile Information.
Process Description If
Password match
Change Password
END if
42
Name 5.0 Send Messages

Description All user will be able to communicate to each other.
Input Data Flow Retrieve student, Faculty’s ID Details.

Output Data Flow Send the message to anyone.
Process Description If (Intake_id match)

Take username or intake_id
Send mail
END if
Name 6.0 Attendance
Description Take the attendance of all students.
Input Data Flow Retrieve student intake id, name,subject and date. Request for to
take attendance.
Output Data Flow Store the attendance of the students.
Process Description If (batch_id match in courses table) THEN

Take the subject to the respected module lecturer
Students details
Take attendance
END if
8.3. Data Stores

Name D1 ADMIN
Stores the name and Password of the Admin which able to login to
Description
admin
Input Data Flow Store Passowrd for admin.
Output Data Flow Able to Log in and maintain all the things.
Data Structure Username, Password, Email_id.
43

Name D2 STUDENT DATA
Description Stores all Records that helps in keeping records of the Students
Input Data Flow Store personal Details of Student
Output Data Flow Able to Log in, Retrieve Attendance report, Attendance report, send
Messages
Name, Father’s Name, Gender, Batch_name, Batch_id, Intake_id,
Data Structure
Address, Contact, Phone_number, email.
Name D3 FACULTY DATA
Description Stores all Records that helps in keeping records of the Faculty
Input Data Flow Store personal Details of Faculty.
Output Data Flow Able to Log in, Take Attendance, Retrieve Attendance report,
Attendance report, send Messages .
Username, Name, Gender, joining_date, leaving_date, Desigination,
Data Structure
Qualification, Address, Contact, Phone_number, email.
Name D4 BATCH DATA
Stores all Records that helps in managing the Batches, Program, Batch
Description
ID and Intake ID.
Input Data Flow Store Program and Batch Details
Output Data Flow Retrieve All the Program Records.
Data Structure Program_name, Batch_name, Batch_id, Nos, status, Last_intakeis
Name D5 COURSES
Stores all subjects details to keep record of the module which is

Description
teaching in APIIT
44
Input Data Flow Store Subjects Details

Output Data Flow Retrieve subject Details
Data Structure Batch_id, Semester, Subjects
Name D6 MODULE LECTURER
Description Stores the name of the module lecturer who is currently teaching
Input Data Flow Store Module Lecturer and Subject name.
Output Data Flow Retrieve Module Name with Lecture.
Data Structure Batch_id, Semester, Subject, Lecturer
Name D7 ATTENDANCE
Stores attendance of students that help to know about the students that
Description
is he doing classes or not?
Input Data Flow Store Attendance Details
Output Data Flow Retrieve Attendance Details

Intake_id, Subject, Module_name, faculty_name, Date, Status,
Data Structure
Remarks.
Name D8 MSEEAGES
Stores the Messages of the all the students, Faculty and admin, help to
Description
communicate with each other.
Input Data Flow Store Messages.

45
Output Data Flow Retrieve Messages.

Data Structure Name, Intake_id, Sender_Name, Subject, Message.
8.4. Data Flows

Name 4.0 PROFILE INFORMATION
Description Contain student’s and Faculty’s profile information.

Origin / Source Admin
Destination Student, Faculty
Data Structure Student ID, Batch ID, Intake_ID, Name, Address, Telephone
Name 3.2 BATCH CREATION
Description Contain Batches and Program’s Information.

Destination Admin
Data Structure Program_Name, Batch_Name, Batch ID, Number_ students
Name 4.2 VIEW PROFILE
Description Any Registered Person Able to View the Profile of everyone.

Origin / Source Student, Faculty and Admin
Destination Student, Faculty and Admin
Data Structure Inatke_id, Name, username(admin).
Name 5.0 SEND MESSAGES
Description Able to communicate to each one.

46
Origin / Source Student, Admin, Faculty
Destination Student, Admin, Faculty

Data Structure Intake_id, Name, sender_name, date, Subject, Message.
Name 6.1 TAKE ATTENDANCE
Description Take Attendance of the Students

Origin / Source Faculty
Destination Students
Data Structure Intake_id, Name, Subject, Status, Remarks, date.
Name 6.2 CHECK ATTENDANCE
Description To check the attendance of the System

Origin / Source Faculty
Destination Faculty, Admin, Student.
Data Structure Intake_id, Name, Subject, Status, Remarks, date.
Name 5.4 READ MESSAGES
Description All User will be able to receive teir message

Origin / Source Admin, Faculty, Student
Destination Admin, Faculty, Student
Data Structure Name, Intake_id, Sender_name, Date, Message, subject.
Name 3.0 VIEW COLLEGE’S BATCH DATA
Description Contains Information of the entire College’s Program.

47
Destination Admin, Faculty, Students.

Data Structure Batch_id, Program_name, Batch_name,
48

Chapter9: Event Model
Entity Life History

ELHs provide us with the third view of the system, the dynamic sequence or time-based
view. It shows the processing cycle of an entity from creation to deletion. It models all
possible changes to the values of the attributes (or data items) of the entity during its life
and the sequence in which the updates take place.
It is basically used to show sequencing, iteration and timing of an entity. The life of an
entity starts when it is created and it ends when it is deleted. Entity life history shows the
values of the attributes of the entity those changes during the life.
Entity life history (ELH) consists of three main steps for drawing Entity life history
diagram.
These are:
1. Sequence.
2. Selection
3. And iteration
The entities are:
Admin, Attendance, Batch, Course, Faculty, Message, Module Lecture, Student Data
49
Entity Life history For Administrator

Admin
Close
Open Admin account
Registration
Registration Life
*
registration
Faculty
Student registration o registration o
Add o Update o Delete o Update

Add o Delete o
o
Entity Life history for Student
Student
Complete
Student s account Course
Join Course
life
Acquaint with o Communicate o

View Profile o Update Profile o
College Programm Through Mesage
50
Entity Life history For Faculty APIIT SD INDIA | PANIPAT

Faculty
Hire in the Leave organisation

Organisation Faculty Life
Teaching *
Communicate o
Take attendence o View Profile o through message
51
Entity Life history For Course

Course
Insert Course Manage Course Update Course
Issue Course Assign Course *
Program
52
Entity Life history For Registered Student

Student
Join Year Manage Student

Year End Year
Existing Student *
management
Monitor the o Student leave o Lecture o Student and o

Student management schedule Faculty history
management
Program Management
Program
Open
Program Manage Program Close Programm
Add Program *
Program
Name Batch Name No of Student
Batch ID
Message Entity:
53

Message
Message
request Process Message Delete Message
Accept Reject
54

10. Object-Oriented Design
Use Case Diagram

Admin Perspective:
Register Student
Assign course
Register Faculty
Assign Faculty
Update Profile Admin
Attendence_Summary
(
Database Update
Course_Assign_Faculty
55
Student Perspective:

See Profile
Update own Profile Student
Attendence_Summary
(
See_differnet_profile
Give feedback
56
Faculty Perspective:

See Profile
See course
Take Attendance
Update Profile Faculty
Attendence_Summary
(
Attendance Update
Course_Assign_Faculty
57

Use Case Diagram for Admin
58
Use Case Writing For Admin

Actor- Admin
Activities: Register New, Old students and faculties. Add New Program, new Batch and
Batch ID, Add Subject and Module Lecturer, update batch name, Program name, Batch ID,
Intake ID, Name of Students, Check The profile of Students and Faculty, send message to
student and faculty, View the data related to college and read their messages.
Pre Condition: Batch name only added when its respected Program Name will exist. Subject
name will only inserted when there is no any data exists related to that semester r of which
we want to add.
Normal Flow: First create Batch Name then Batch ID will be created.
Alternate Flow: Admin has many options to check the attendance: 1. With the Batch ID, With
Name, With ID, With Batch ID, with defaulter List.
Post Condition: System must connect to the Server and attached to the database and there
must be some logical data.
Exception: System will give error if its database is corrupted. If it disconnected suddenly then
there might be situation that user will not get the desired answer.
Include Use Case: User must log in with the correct password unless they will not be served
as a user. For updating the password old password must be in mind to the users.
Extended Use Case: Admin have many option to see the profile of a student. They can go to
check by Intake ID or Name or their respected Batch id.
59

Use Case Diagram for FACULTY
Writing Use Case for FACULTY 60

Actor- Faculty

Activities: Take Attendance, Modify attendance, create defaulter student’s report , Check The
profile of Students, Faculty and admin, send message to student and faculty, View the data
related to college and read their messages.
Pre Condition: Can take attendance only when there is a student whose status in batch is
present. If he is assigned to the subjected then only he can be able to take attendance.
Normal Flow: Only assigned teacher will take attendace. First send request for the lsit of the
students data then will be acle to take attendance.
Alternate Flow: Faculty has many option to Check the attendance: 1. With the Batch ID,
With Name, With ID, With Batch ID, With defaulter List.
Post Condition: System must connected to the Server and attached to the database and there
61

Use Case Diagram for Student
62

Writing Use case:

Actor- Student
Activities: View Attendance, Check The profile of Students, Faculty and admin, send
message to student and faculty, View the data related to college and read their messages.
Pre Condition: Can able to change password only when he knows the previous password.
Normal Flow: Only authenticated student will be able to view their attendance and able to
change their password or check other’s profile.
Alternate Flow: Students have many options to check the attendance: 1. With the Batch ID,
With Name, With ID, With Batch ID, with defaulter List.
Post Condition: System must connect to the Server and attached to the database and there
63

11. Interactive Screen Design
The screen design for the system has been developed keeping in mind the principles and
guidelines of Human Computer Interaction. Effort has been taken to maintain consistency
of design without sacrificing on the learn ability and simplicity of the designs. The Millers
Law has been duly implemented and also great precaution has been taken to ensure that all
major functionality is centred around the middle so as it becomes easy for the user to spot
things to do.
Here are some screen shots of the input/output screen designed for the system. Only some of
the screen has been included due to space constraint.
Three different set of screen designs have been made, one to be used for the EMS for Admin
Other to be used for the management system for the PCC staff.
Username and password

can’t be blank
Screenshot 1: Login screen for the EMS for Admin. 64

Names only
Alphabate
Minimum 3
letters must
be there.
Optional Field
Admin allows to
Leave it.
Screenshot 2: Screen showing data entry for adding a new/ Existimg Student
65

Name cant be Alpha

Numeric.
Password Must be more than

three words limited to six word.
Date in
mm.dd.yy
Format
Optional Field User

allows Leave it.
Screenshot 3: Screen showing data entry for adding a new/ Existimg Faculty
66

Only Alphabates
are allowed.
AlphaNumeric
Field.
Screenshot 4: Screen showing data entry for adding a newProgram
Must atleast three subjects

in a Batch
Admin Can Leave

it.
Screenshot 5: Screen showing data entry for adding Subject.
67

Must some letters.
Cant Leave Blank.
Screenshot 6: Screen showing sending message to the PT0781101 ID.
68

Screenshot 7: Screen showing report of PT08811 batch id of semester six.
69

Screenshot 8: Screen showing Defaulter list of students of PT08811 batch id of semester six.
70

Screenshot 9: Screen showing Profile of the students.
71

Screenshot 10: Screen showing Profile of the Faculty
72

Screenshot 10: Screen showing report of the all programes and its branches.
73

Screenshot 12: Screen showing report of the all Subjects in a Batch
74

Screenshot 13: Screen showing Attendance in a Batch
75

Screenshot 14: Screen showing Attendance report in a Batch
76
Screenshot 15: Screen showing Message report.

All fields must have

letters.
Screenshot 16: Screen showing How to change the Password.
Chapter11: Programming Environment

We have built the software using PHP It is a web based application with a centralized
database. This programming language is used because it acts as an integrated development
environment. This means that all the tools and graphics are predefined made with the Dream
viewer software. It is also an intelligent-sense programming so that it will be easy to
remember the programming code and saves the time while coding. Our objective is to make
fault free software so that the customers can use it with ease. Our project is done exactly as
we have the specification provided.
Development tools:
 PHP: Used for developing the design & building the code of the application.
 MYSQL: Required for large database maintenance.
 Adobe Photoshop: used for image editing.
77

Documentation tools:
Microsoft Word 2007: for writing the whole documentation including tables &
screen-shots.
Microsoft Project 2007: For making Gantt chart.
Microsoft Visio 2007: for making ER-diagrams and DFD’s.
The Front End and Back End

The nature and the selection of the language as every component of the system are according
to the objects of the world. We used PHP as our front end and MYSQL as our backend
because it is easy to maintain and develop a system as the software provides most graphical
tools. The programmer can reuse many used components of the programmed. Even
connecting to the database it is a simple job and there is no need of much programming
because the code is automatically generated. This software is event driven again program it
will be easy to restructure the program when the requirements changes.
PHP is an open source language and its interoperable with any type of environment as well as
language. This is the reason that the choice of language is primarily a matter of personal taste
or management as per requirements.
Our application is a web based application. Assessing the systems is again a judgmental
process that is informed by measurements of the systems and its maintenance process.
Whenever the system is re-engineered, it does not need much of the source code help. It can
be easily added by dragging the items into the forms. They might require coding for the
functionality of the system. The programming has been done adding a comment to each main
source code to understand the function. Once the system needs to be re-modified, they can
verify the lines provided in the system.
Justification why we used PHP with Dream Weaver as a development tool:

Includes fast developing tools like drag-and-drop design tools, customizable views
78
and code behind forms.

In addition, new features such as automatic control resizing eliminate the need for
complex resize code.
Provides flexible and Simple Data Access for project having a large database.
Easier deployment: There is no need to register components because the
configuration information is built-in.
The source code is executed on the server & is compiled the first time the page is
requested. Execution is fast as the Web Server compiles the page the first time it is
requested. The server saves the compiled version of the page for use next time the
page is requested.
Justification for using MySQL:

MySQL is a relational database that runs on the NT Operating System. SQL or
Structured Query Language is a widely accepted industry standard for designing,
changing and managing data and controlling how changes to database are made using
tables, indexes, keys rows and columns to store data. Its main features are:
Stores large databases: MySQL allows you to store large volumes of data which
include items like photographs, video, text, numbers and much much more.
Scalability: Scalability advancements in MySQL include table partitioning,
replication enhancements.
Security Enhancements: MySQL has been designed to help provide the highest
level of security for enterprise data through features such as database encryption,
more secure default settings, password policy enforcement, granular permissions
control, and an enhanced security model.
Reporting Services: MySQL Reporting Services is a comprehensive, server-based
reporting solution designed to help you author, manage, and deliver both paper-based
and interactive Web-based reports.
Backup Maintenance: MySQL can be setup to automatically back up. It can also do
incremental backups which means it can backup during the day rather than just once
at night. This feature helps from losing the latest updated information in the database.
79

Conclusion
After working on this project, we can see that the information management became the
important issue for all the organization and in every organization have their own
methodology to manage their data which need to be analyzed and kept in good manner.
In Cricket Club management System, especially, we see the example of the organization
which needs the well system to manage all the information in the club. The management
system should be able to fulfill the requirement of the user who use the system. Well
managing of information, arranging all the information according to the need of user, these
are some characteristics which need to be fulfilling in this system. In this assignment, we
tried to make all the possible facilities to provide the user more convenience and increase the
speed of work.
80

References
http://ptgmedia.pearsoncmg.com/images/0131872508/samplechapter/0131872508_ch01.
pdf
[Last Accessed: 10th March, 2011]
http://www.buzzle.com/editorials/1-5-2005-63768.asp
http://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci213458,00.html
http://www.buzzle.com/articles/waterfall-model-advantages-and-disadvantages.html
http://folkworm.ceri.memphis.edu/ew/SCHEMA_DOC/comparison/erd.htm
Books Referred
1. Kendall and Kendall (2005); System Analysis and Design; 4th Ed; New York:
Prentice Hall.
61-61, 235 – 260;
2. Jeffry L Whittem, Lonnie Bentley (2005). System Analysis and Design; London: Mc
Graw-Hill. 34-40;
3. Shelly Cashman (2002). System Analysis and design; 2nd Ed. Sydney: Shelly
Cashman Series. 125-127.
4. Shari Lawerence Pfleeger (2002). Software Engineering; 2nd Ed; New Jersy: Pearson
Education. 250-260.
5. Mc Fadden Fred R, Hoffer Jeffrey A., Prescott Mary B, Modern Database
Management, Fifth edition, 2001, Addison Wesley Company(Singapore) Pvt., Ltd.
6. Aggarwal K.K., Singh Yogesh, Software engineering, Third edition, New age
International, New Delhi, Page 20-36.
7. Jalote Pankaj, An Integrated approach to software Engineering. Third edition, 2005,

81
Narosa Publishing House.

8. Sommerville Ian, Software Engineering, 6th edition 2002, Pearson
Education(Singapore) Pvt., Ltd.
9. Schwabe, Information Technology, Project Management, Fourth edition, 2008 Baba
Barkha Nath Printers, Page 1-32.
10. Budgen David, Software Design, First edition(2004), Pearson Education (Singapore)
Pvt., Ltd., India branch.
11. Burke Rory, Project Management Planning and Control techniques, Fourth edition
2009, Santee Offset Printers, Delhi.
82

Documentation For Software Engg Project

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Documentation For Software Engg Project

Uploaded by

Copyright:

Available Formats

Education Management System 1

Education Management System

APIIT SD INDIA | PANIPAT

Chapter 1: Introduction ........................................................................................................ 6

Requirements Analysis .......................................................................................................... 7

Objectives of the new system ................................................................................................ 7

Requirements Analysis .......................................................................................................... 7

Normal Requirements ........................................................................................................... 7

Expected Requirements ......................................................................................................... 8

Chapter 2: Schedule planning-schedule network and Gantt chartError! Bookmark not

2.2. Schedule Network .......................................................... Error! Bookmark not defined.

2.2. Schedule Network .......................................................... Error! Bookmark not defined.

Chapter 3: Selection of methodology..................................................................................... 9

Status of development team:................................................................................................ 10

Involvement of user: ........................................................................................................... 10

Type of project and associated work:................................................................................... 11

Scope of Spiral Analysis ................................................................................................. 12

The reason why we have used Spiral model: ....................................................................... 13

Chapter 4: Problem Analysis-Current System...................................................................... 14

Problems related with the Admin ........................................................................................ 15

Major problem related to the Education system ................................................................... 15

Chapter 5: Overview: Proposed system ............................................................................... 16

The following module was identified: ................................................................................. 16

Assumptions Made: ............................................................................................................. 16

Chapter 6: Process Model for Proposed Systems ................................................................. 20

APIIT SD INDIA | PANIPAT

6.1. Context Diagram .......................................................................................................... 20

6.2 Level 0 DFD .......................................................................................................... 21

6.3 Level 1 DFDs ................................................................................................................ 25

Process 3.0 Level 1 DFD ..................................................................................................... 25

Process 4.0 Level 1 DFD ..................................................................................................... 26

Process 5.0 Level 1 DFD ..................................................................................................... 27

Process 6.0 Level 1 DFD ..................................................................................................... 28

6.4 Level 2 DFDs ................................................................................................................ 29

Process 3.2 Level 2 DFD ..................................................................................................... 29

Process 3.4 Level 2 DFD ..................................................................................................... 30

Process 5.2 Level 2 DFD ..................................................................................................... 31

Process 6.1 Level 2 DFD ..................................................................................................... 32

6.5 Process Specification ..................................................................................................... 33

Structured English ............................................................................................................... 33

Decision table ..................................................................................................................... 37

Decision Tree ...................................................................................................................... 37

7.1 Entity Relationship Diagram ...................................................................................... 38

Chapter 8: Data Dictionary for Proposed Systems ............................................................... 41

8.1. External Entity ............................................................................................................. 41

8.2. Process ......................................................................................................................... 42

8.3. Data Stores ................................................................................................................... 43

8.4. Data Flows ................................................................................................................... 46

Chapter9: Event Model ....................................................................................................... 49

Entity Life History .............................................................................................................. 49

10. Object-Oriented Design ................................................................................................. 55 3

Use Case Diagram ............................................................................................................... 55

APIIT SD INDIA | PANIPAT

Use Case Diagram for Admin.............................................................................................. 58

Use Case Writing For Admin .............................................................................................. 58

Use Case Diagram for FACULTY ...................................................................................... 60

Writing Use Case for FACULTY ........................................................................................ 60

Use Case Diagram for Student ............................................................................................ 62

Writing Use case: ................................................................................................................ 63

11. Interactive Screen Design .............................................................................................. 64

Chapter11: Programming Environment ............................................................................... 77

Development tools: ............................................................................................................. 77

Documentation tools: .......................................................................................................... 78