Wolkite poly technic collage and Satellite University

Department of Information Technology

Project Title: Student Management System
For Wolkite poly technic collage and Satellite
University, wolkite.

BY
1. Tinsae Neri
2. Ashenafi Dabera

March, 03/03/2014
Wolkite, Ethiopia

i
 APPROVAL SHEET

This Group technology Proposal titled Student Management System for Wolkite poly
technic collage and Satellite University.

Position Name Signature

Department Head Amaha Alemayehu ____________

Technology v/dean Bogale Tekele ____________

ii
iii
 Acronyms and Abbreviations
SMS: Student Management System

SDD: system Design Document

RAD: Requirement Analysis Document.

Wptc: Wolkite poly technic collage.

UML: Unified Modelling Language

ODD: Object Design Document.

IIS: Internet Information Server

IT: Information Technology

HTTP: Hyper Text Transfer Protocol

RAD: Requirement Analysis Document

RDMS: Relational Database Management System

SMS: Collage Management System

SDD: System Design Document

iv
 Table of Content
Chapter 1:Requirement Analysis Document (RAD).....................................................................................1

1. Introduction......................................................................................................................................1
1.1. Purpose of the System................................................................................................................1
1.2. Statement of the Problem...........................................................................................................2
1.3. Scope of the System...................................................................................................................2
1.4. Objective and Success Criteria of the Project............................................................................2
1.4.1. General Objective..............................................................................................................2
1.4.2. Specific Objectives............................................................................................................2
1.4.3. Success Criteria of the Project...........................................................................................3
1.5. Definitions, Acronyms, and Abbreviations...............................................................................3
1.5.1. Definition...........................................................................................................................3
1.5.2. Acronyms and Abbreviations............................................................................................3
1.6. Feasibility Analysis ..................................................................................................................3
1.7. Tools..........................................................................................................................................3
2. Current System................................................................................................................................5
3. Proposed System..............................................................................................................................8
3.1. Overview....................................................................................................................................8
3.1.1. Benefit of the New System................................................................................................8
3.2. Functional requirement..............................................................................................................8
3.3. Non Functional Requirement.....................................................................................................9
3.3.1. Usability.............................................................................................................................9
3.3.2. Reliability...........................................................................................................................9
3.3.3. Performance.....................................................................................................................10
3.3.4. Supportability...................................................................................................................10
3.3.5. Availability......................................................................................................................10
3.3.6. Security............................................................................................................................10
3.3.7. Interface...........................................................................................................................10
3.3.8. Implementation................................................................................................................10

v
 3.3.9. Operations........................................................................................................................11
3.4. System Models.........................................................................................................................11
3.4.1. Scenarios..........................................................................................................................11
3.4.2. Use Case Model...............................................................................................................12
3.4.3. Object Model...................................................................................................................20
3.4.3.1. Data Dictionary...........................................................................................................20
3.4.3.2. Class Diagrams............................................................................................................20
3.4.4. Dynamic Model...............................................................................................................23
3.4.4.1. Sequence Diagram.......................................................................................................23
3.4.4.2. Activity Diagram..........................................................................................................27
4. Glossary..........................................................................................................................................30
Chapter 2: System Design Document SDD.................................................................................................31
1. Introduction....................................................................................................................................31
1.1. Purpose of the System..............................................................................................................31
1.2. Design goals.............................................................................................................................31
1.3. Definition, Acronyms and Abbreviations................................................................................33
1.4. References................................................................................................................................34
1.5. Overview..................................................................................................................................34
2. Current Software Architecture....................................................................................................35
3. Proposed Software Architecture..................................................................................................36
3.1. Overview..................................................................................................................................36
3.2. Subsystem Decomposition.......................................................................................................38
3.3. Hardware/Software Mapping:..................................................................................................40
3.4. Persistent Data Management....................................................................................................41
3.5. Access Control and Security....................................................................................................43
3.6. Global Software Control..........................................................................................................44
3.7. Boundary Conditions...............................................................................................................44
4. Subsystem Services........................................................................................................................45
5. Glossary..........................................................................................................................................46
Chapter3: Object Design Document (ODD)................................................................................................47
1. Introduction....................................................................................................................................47
1.1 Object design trade-offs...........................................................................................................47
1.1.1 Development Cost versus Functionality..........................................................................47

vi
 1.1.2 Understand ability versus Cost........................................................................................47
1.2 Interface documentation guidelines.........................................................................................47
1.2.1 Naming and Coding Conventions....................................................................................47
1.3 Definition , Acronyms and Abbreviations...............................................................................48
1.4 References................................................................................................................................48
2. Packages..........................................................................................................................................49
2.1 Package Diagram.....................................................................................................................49
2.2 Package Definition...................................................................................................................50
The following are some of the main packages including:.......................................................................50
3. Class Interface................................................................................................................................51
3.1 Class Definition.......................................................................................................................51
3.2 Class Diagram..........................................................................................................................52
Chapter 4: Implementation and Testing Document.....................................................................................53
1. Implementation..............................................................................................................................53
1.1. Programming Tool...................................................................................................................53
1.2. The SMS Prototype..................................................................................................................53
2. Testing Document..........................................................................................................................55
2.1. Test plan...................................................................................................................................55
2.1.1 Introduction......................................................................................................................55
2.1.2 Relationship to Other Documents....................................................................................55
2.1.3 System Overview.............................................................................................................55
2.1.4 Features to be tested/not to be tested...............................................................................56
2.1.5 Pass/Fail criteria...............................................................................................................56
2.1.6 Approach..........................................................................................................................56
2.1.7 Test Suspension / Resumption Criteria............................................................................57
2.1.8 Testing materials (HW/SW requirements).......................................................................57
2.1.9 Testing cases....................................................................................................................58
2.1.10 Testing Schedule..............................................................................................................58
2.2. Test Cases Specification..........................................................................................................59
2.2.1 Test Case Specification Identifier....................................................................................59
2.2.2 Input and Output Specification........................................................................................60
2.3. Test Incident Report.................................................................................................................62

vii
 2.4. Test Report Summary..............................................................................................................62
Chapter 6:-Conclusions and Recommendations..........................................................................................66
1. Conclusion.......................................................................................................................................66
2. Recommendations............................................................................................................................67

viii
 List of Tables
Table 1: Scenario for student Registration..................................................................................................11

Table 2: Scenario for ReportGeneration......................................................................................................12

Table 3: Use case description for RegisterStudent......................................................................................14

Table 4: Use case description for UpdtaeRecord.........................................................................................14

Table 5: Use case description for Generate Transcript................................................................................15

Table 6: Use case description for GenerateReport......................................................................................15

Table 7: Use case description for GenerateSchedule...................................................................................16

Table 8: Use case description for NotifyInformation..................................................................................16

Table 9: Use case description for ViewInformation....................................................................................17

Table 10: Use case description for UploadMark.........................................................................................18

Table 11: Use case description for UpdateMark.........................................................................................18

Table 12: Use case description for GenerateReport ...................................................................................19

Table 13: Use case description for TakeAttendance...................................................................................19

Table 14:Data Dictionary.............................................................................................................................20

Table 15: Access Control Matrix.................................................................................................................43

Table 16:- Testing Schedule........................................................................................................................58

Table 17:- Test cases produced....................................................................................................................60

ix
 List of Figures
Figure 1: Use case diagram for Wolkite poly technic collage and Satellite University SMS.....................13

Figure 2: Entity, boundary and Control objects...........................................................................................22

Figure 3: Register Student Sequence Diagram............................................................................................23

Figure 4: Update Record Sequence Diagram...............................................................................................23

Figure 5: Generate Schedule Sequence Diagram.........................................................................................24

Figure 6: Generate Transcript Sequence Diagram.......................................................................................24

Figure 7: Generate Report Sequence Diagram............................................................................................25

Figure 8: Generate Report Sequence Diagram............................................................................................25

Figure 9: Take Attendance Sequence Diagram...........................................................................................26

Figure 10: Manage Mark Sequence Diagram..............................................................................................26

Figure 11: Student Registration activity diagram........................................................................................27

Figure 12: Report Generation activity diagram..........................................................................................28

Figure 13: Take Attendance activity diagram.............................................................................................29

Figure 14: Organizational Structure of the system......................................................................................36

Figure 15: Architecture of the proposed System.........................................................................................37

Figure 16: Layered Representation of the System.......................................................................................39

Figure 17: Subsystem Decomposition Diagram..........................................................................................40

Figure 18: Deployment Diagram of the System..........................................................................................41

Figure 19: Sample Mapping Objects into Tables........................................................................................42

Figure 20:- Package Diagram.....................................................................................................................49

Figure 21:-Describes the classes and their public interfaces (UML Class Diagram)..................................52

Figure 22:- Login page.................................................................................................................................53

Figure 23:-Student Registration form..........................................................................................................54

Figure 24:- Login form of Record officer....................................................................................................60

Figure 25:- User Login Page........................................................................................................................63

x
Chapter 1: Requirement Analysis Document (RAD)
1. Introduction
1.1 Purpose of the System

The aim of the project is to implement a Student Management system suitable for Wolkite
poly technic collage and Satellite University, providing flexibility to adapt to new and
changing requirements. This Student management system is an automated version of manual
Student Management System and using this software means securing the activities of the
Student Management. The vision is to provide a progressive and expandable information
service to staff, students and applicants.

Education system forms the backbone of every nation and hence it is important to provide a
strong educational foundation to the young generation to ensure the development of open-
minded global citizens securing the future for everyone.

Advanced technology available today can play a crucial role in streamlining education-
related processes to promote solidarity among students, teachers, parents and the collage
staff. Education is central to development. It is one of the most powerful instruments for
reducing poverty and inequality and lays a foundation for sustained economic growth.

With this aim currently our government has given special emphasis to the educational sector
and collage improvement activities such as continuous professional development for
teachers, training and upgrading teachers and capacitating collage with manpower and
materials are among the major actions which have been taken in both primary and secondary
collages. In order to facilitate and simplify these actions one of the major tool is to have
automated student management system.

Automation is the utilization of technology to replace human with a machine that can
perform more quickly and more continuously. By automating SMS documents that took up
many large storage rooms can be stored on few disks.

Transcript images can be annotated. It reduces the time to retrieve old transcripts from
hours to seconds. However, the collage system in Wolkite poly technic collage and Satellite
1
University is not automated and the record officers generate transcripts and reports manually
and the college administrators use their experienced knowledge of miss and hit approaches to
prepare timetables. Therefore, the main purpose of developing the Student management
system of Wolkite poly technic collage and Satellite University is that to make easy to
management to store a large number of data/reports into the computer.

The proposed system consists of tasks such as registering students, attendance record
keeping to control absentees, producing report cards, producing official transcript, preparing
timetable and producing different reports for teachers, parents, officials from representatives
of education bureaus and other stakeholders.

2
1.2. Statement of the Problem
 To help promote students achievement and success, collages must have access to
complete, accurate, and timely information about students. One of the benefits of
automated SMS is that the student record system will simplify retrieval of required
information and is a great instrument for collage improvement by taking measures from
the information acquired.

 Despite the use of automated SMS, the government collages in Ethiopia are using paper
based documentation system for performing various tasks and the college administrators
apply their knowledge of hit and miss approach in scheduling classes and courses
(preparing the schedule) which wastes manpower and much time unnecessarily that does
not utilize the current technology.

 Grade Reports of students are prepared manually by the record officer. Attendance of
students is recorded by the teachers. In order to control absentees and know the number of
days that a student has been absent from the collage during the collage days the
attendance officer has to collect the attendance slips from the corresponding teachers and
compile it which is also a time taking process.

 In addition to that retrieving records of students who have graduated couple of years ago
has been a difficult task and the manual system also has difficulty of producing different
reports which are required by the stakeholders such as teachers, administrators. Teachers
may want to associate a student with his parent or emergency persons for disciplinary
measures which need searching of the students record in the record office.

 It has been difficult to search a record from thousands of such records and observed that
students can take any person claiming that he/she is their parent or emergency person
which creates problem in control of students. Due to the inefficiency of the current
manual system, the need arises to automate SMS in order to efficiently handle students‟
attendance, to produce Grade Report, report generations and the various reports satisfying
users and customers and to produce schedule which can schedule courses for teachers and
classes of student.

 Due to the inefficiency of the current manual system, the need arises to automate SMS in
order to efficiently handle students‟ attendance, to produce Grade Report, report
generations and the various reports satisfying users and customers.

 In general, the project team have tried to mention some problems of the manually system
by using the primary and secondary methodologies like observation, interview and data
analysis.

3
 Manual based student registration

 Inappropriate way of handling student information

 Shortage of the place to store student and teacher’s data manually using paper/card system

 Lack of security on the staff information.

 High work burden for the employee

 Time consuming: - most of the activities done take more time to be done.

 Lack of immediate retrievals: The information is very difficult to retrieve and to find
particular information like students record that stored before, the user has to go through
various registers and the workers are asked to find the history.

 Lack of prompt updating: Various changes to information like student or teacher details
are difficult to make as paper work is involved.

 Difficulty to generate report.

4
 1.3 Scope of the System
This project is delimited Student Management System for Wolkite poly technic collage and
Satellite University. There are many limitations that the team will encounter while
developing the project, so the project team will probably plan to accomplish at least the
following bulleted functionalities that used to manage the collage and allows the
administrators to register the daily required information of Students, Teachers & office staff.
Student Management System will organize work inside collage and the system boundary
including functions like:-

 Insert student’s information such as student name, student number, address etc.

 Insert section’s information such as section name etc.

 Insert marks for each student in each courses he/she has taken.

 Editing student’s information.

 Retrieve any information about students.

 Preparing both class and exam schedules

 Register student fees

 Notice announcements

 Upload TTLM.

 Manage class attendance

1.4 Objective and Success Criteria of the Project

1.4.1 General Objective

 The general objective of this project is to develop Student Management System
and automate the manual system.

1.4.2 Specific Objectives

 To develop student registration system,

5
  To facilitate attendance record keeping,

 To facilitate various report generation,

 To generate students‟ transcript

 To allow teachers, parents, collage community and Education bureau officials

to view reports on students,

 To add students‟ mark

 To update students‟ mark

 To produce a timetable for class and examination

1.4.3 Success Criteria of the Project

A project to be considered successful requires proper planning and the help from the
management because exceeding customer requirements will bring about success to the
project, so in order to recognize the success the project team will ensuring that the project
meets the objectives, set proper and conducive project plan, assigning tasks to the team
members, developing a plan to achieve common tasks, reviewing and doing a rework when
needed, managing project risks efficiently and allocating time for process improvement.

1.5 Definitions, Acronyms, and Abbreviations

1.5.1 Definition
Transcript: - a written or printed version of students result during his/her stay
in the collage, and is given when the student leaves the collage

Instructors: - an Instructor who is in charge of a given class, to take attendance and

calculate their result and upload to the system.

Constraints: -problem or obstacle that limits the project from fully achieving its goal.

Entity: -are individual instance of the entity, type, they represent the individual
instance of the project.

6
 1.6. Feasibility Analysis

 The main aim of the feasibility study activity is to determine whether it would be financially and
technically feasible to develop a project.

 The feasibility study activity involves the analysis of the problem and collection of all relevant
information relating to the academic such as the Course Management, Fee Management, grade
Management, and Intake Administration different data items which would be managed to the
system, the processing required to be carried out on these data, the academic required to be
produced by the system as well as the various constraints on the behaviour of the system.

1.6.1 Operational Feasibility:-

 In this project operational feasibility refers to an evaluation which analyses how well wptc
general academic student management system.

 This system will be easily acceptable by the user/users because the system will be user friendly
and accurately meet the user’s learning and teaching process.

 The current methods are using manually academic student management system, which lead to
the requirement of the new web based system. There is enough and more support and motivation
from the management. The current system has got series of limitation that has been mentioned
earlier.

1.6.2 Technical Feasibility:-

 The technical issues usually raised during the feasibility stage of the investigation include these,
this system will be technically feasible, since the whole system is designed using the latest
technologies which is front end and back end of the system is PHP and MYSQL respectively.
These development tools are most recent and popular technologies to develop web based
systems and design databases. Also we developers have some know how about these
technologies and the new system will be more secure. As a result this system will be technically
feasible.

1.6.3 Schedule Feasibility:-

 Projects are initiated with a specific deadline. We need to evaluate whether the deadline are
7
 mandatory or desirable. Time is one of the critical factors in the development of any system and
hence proper scheduling is very essential for the timely completion of a project.

1.6.4 Financial and Economic Feasibility:-

 This system is economically feasible, it will reduce resource cost like paper and pen, and it also
reduces time. The system can show all the data in at a time and provide information regarding to
the status of technician and items, thus the system reduces the cost to data retrieving.

 This less cost analysis makes our proposed system more feasible. Therefore we can say our
proposed system will be economically feasible.

1.7 Tools

 Software requirement tools to develop our project are

 PHP 5.0 and above

 Front End: HTML and JavaScript, CSS
 Operating system: window 10 pro
 Visio 2007 and Edraw max 7.9
 Apache server, MySQL database
 Wamp server

 Hardware requirement tools:

 Computer with internet connection

 Printer
 2GB Ram or Higher
 500 GB HDD or Higher
 USB Flash
 Desktop and laptop computer.
1.7 Significance of the project

 There are a number of benefits that come from using this web based Student Management System.
Some of these include:

8
 Flexibility: Using an SMS ensures increased flexibility, as individual can access it at any time
and from any location, that offers internet access. It can also be accessed by a number of users at
the same time, which adds to the flexibility these systems offer.
Enhanced monitoring: With an SMS, monitoring learning and progress becomes far easier,
which means it becomes easier to determine where improvements are needed as well as being
able to better identify areas of success. This can form an important part of the overall learning
experience and functionality of the system.
Convenience for companies or institutions and students: An SMS will be to offer increased
convenience to all concerned, from the company or institution that has invested in the system
through to those who will be using it to learn from it. The web based platform used by an SMS
means greater easy, convenience, and freedom when it comes to academic information
management system
This project has many benefits to the students, instructors, administrators, the registrars and
other community of the wolkite poly technic college.
 The new system that the project team wants to develop is a computerized system which
changes the above problems in simplified and advanced way.
 Checking and registering will be done by a computer by using user inputs, Data storage
will be done in safe mode and cost effective manner(Electronic information record),
Security issues can be enhanced and data loss will be decreased.
 Appropriate way of handling student mark list information and fast, reliable access for
staffs.
 Providing and maintaining all kinds of marks, schedule for students and generate report.

Benefit of the New System

 It reduces the work load of the collage workers

 It minimize paper wastage.
 The system will be more secured than the existing system
 Efficiency of the system increases in terms of time and cost
 The system will generate report about students in detail.

2. Proposed System

9
 1.3 Overview

The new system that the project team wants to develop is a computerized system which
changes the above problems in simplified and advanced way.

For instance, checking and registering will be done by a computer by using user inputs, Data
storage will be done in safe mode and cost effective manner(Electronic information record),
Security issues can be enhanced and data loss will be decreased.

Appropriate way of handling student mark list information and fast, reliable access for staffs,
Providing and maintaining all kinds of marks, schedule for students and generate report.

3.1.1. Benefit of the New System

 It reduces the work load of the collage workers

 The system will be more secured than the existing system

 Efficiency of the system increases in terms of time and cost

 The system will generate report about students in detail.

1.8 Functional requirement

1RegisterStudents

The Student management system shall allow the Record Officer to register students.

2UpdateRecords

The Student management system shall allow the Record Officer to update records.

3 Generate Transcript

The Student management system shall allow the Record Officer to generate transcript

4UploadMark

The Student management system shall allow Subject Teachers to upload

students‟ mark

5UpdateMark
10
 The Student management system shall allow Subject Teachers to update
students‟ mark

6GenerateSchedule

The Student management system shall allow the administrator to generate schedule

7NotifyInformation

The Student management system shall allow the administrator to notify information.

8GenerateReport

The Student management system shall allow the Record Officer and the
Administrator to generate report.

9 Generate Report

The Student management system shall allow the Home Room Teacher to
generate Report Card

10TakeAttendance

The Student management system shall allow the Home Room Teacher to
take students‟ attendance.

11ViewReports

The Student management system shall allow the Administrator, Record

officer, Home Room teacher, Teacher, student, parent and official to view
reports.

1.9 Non Functional Requirement

 Non-functional requirements, as the name suggests, are requirements that are not
directly concerned with the specific services delivered by the system to its users.
They may relate to emergent system properties such as reliability, response time,
and store occupancy.

1.9.1 Usability
 The system shall have a help support. The user can use the system by reading
11
 help and support or manual of the project.

1.9.2 Reliability
 The new system will be capable of dealing gracefully with errors, not stopping
at the first sign of trouble. Additionally, it is easy to separately monitor the
presence and performance of each component of the system, in order that support
the collage staff can identify and deal with any errors or overload that does
occur.

1.9.3 Performance
 This new system will have good performance rate when executing user’s input
and provide response within a short time period.

1.9.8 Supportability
 New capabilities can be added to the system without major changes to the basic
design. The system will be easily maintained by the developer or other
authorized trained person and it shall respond as fast as possible in generating
report and producing the timetable.

1.9.5 Availability
 The system should be available for access 24 hours, 5 days a week.

1.9.6 Security
 Security requirements are important factors in this system as classified data will
be stored in the database. User validation will be done during login to insure that
the user is valid and that the user only has access to his or her permission data.
General users will only have access through the user interface.

1.9.7 Interface
 The system will have consistent interface formats and button sets for all forms in
the application, will have a form based interface for all data entry and viewing
12
 formats, and will generate reports that are formatted in a table and that should
look like the existing manual report formats for user friendliness.

1.9.8 Implementation
 All users should be able to access an SMS with a web browser. The project team
used different tools to implement the new system. Such as:-

- Programming language: HTML, CSS,PHP and JSP for front end code
and MYSQL for backend.
- Other Software Tools: EdrawMax 7.9 for UML diagram,
AdobePhotoshop for layout and Notepad++ for coding the internal
system.
- SMS should run on any Window operating system.

1.9.9 Operations
 In order to accomplish the new system its goal properly supports from the
system administration and top level management are necessary.

13
2. System Models
2.1.1 Scenarios
The following are sample scenarios of our system.

Table 1: Scenario for student Registration

Scenario Name studentRegistration

Participating azeb: RecordOfficer

Actors Instances sara: Student

Flow of Events 1. Sara comes to Wolkite poly technic collage and Satellite
University record office for registration having thee essential
documents.

2. Azeb checks whether sara is placed into Wolkite poly technic

collage and Satellite University preparatory or not.

3. Azeblogs into the system

4. Azebclicks the RegisterStudent tab

5. Azebfills sara‟s detail information into the computer

6. Azeb submits the form to the system

14
Table 2: Scenario for ReportGeneration

Scenario Name ReportGeneration

Participating bekele: Administrator

Actors Instances anteneh: Official

Flow of Events 1. Mr anteneh, an educational bureau official went to Mr bekele’s

office to request a report regarding the number of female and male
students in each department

2. Bekele logs in to the system

3. Bekele clicks on generate report tab

4. Bekele queries students‟ data from database.

5. And finally bekele generates the report.

6. Anteneh logs into the system

7. And then views the generated report by clicking the view report
tab.

15
 3.3.2 Use case Diagram
A use case is a case (or situation) where your system is used to fulfil one or more of your
user’s requirements; a use case captures a piece of functionality that the system provides.
Use cases are at the heart of our model, since they affect and guide all of the other elements
with your system’s design.

The use case of Student management system in Wolkite poly technic collage and Satellite
University looks as follow.

16
Figure 1: Use case diagram for wolkite poly technic and Satellite University SMS

17
Use case Description
Table 1: Use case description for RegisterStudent

Use case Name RegisterStudent

Participating Actors Record Officer

Entry Condition The Record Officer is logged into SMS

Flow of Events 1. The RecordOfficer clicks the Student tab and Add New
button

2. SMS display RegisterStudent form

3. The Record officer fill and student’s detail information and

Save New button

4. System registers student confirms student’s registration.

Alternative Course of Action 4.1 system fails to register student

Exit Condition System confirms registration or sends failure message

Quality Performance Registration is confirmed within 10 seconds.

18
Table 2: Use case description for UpdateRecord

Use case Name UpdateRecord

Participating Actors Record Officer

Entry Condition The Record Officer is logged into SMS and record must be
available

Flow of Events 1. The RecordOfficer clicks the view tab to that you
prefer to update and click on the stored files that you
need to update

2. SMS display Recorded files form

3. The Record officer modifies record and clicks Save

changes button

4. System updates the data.

Alternative Course of Action 4.1 system fails to update data

Exit Condition System confirms update is accepted or error is detected

Quality Performance Update of record is confirmed within 10 seconds.

19
Table 3: Use case description for Generate GadeReport

Use case Name GenerateGadeReport

Participating Actors Record Officer

Entry Condition The Record Officer is logged into SMS and student
information.

including their marks must be available

Flow of Events 1. The RecordOfficer clicks the Grade tab and click on
Filter tab search and fill the form based on criteria by id
number then click on apply filter

2. SMS display list of student grade GadeReport form

3. The Record Officer searches and fill the form based on

criteria student’s mark using StudentID

4. System validates the existence of student’s mark

5. The Record Officer clicks apply filter button

6. System displays GadeReport.

Alternative Course of Action 4.1 Student’s full information is not found.

Exit Condition Student GadeReport is generated or generate empty table

Quality Performance Student GadeReport is generated within 20 seconds.

20
Table 4: Use case description for GenerateReport

Use case Name GenerateReport

Participating Actors Administrator, Record Officer, system admin, Department head

Entry Condition The Administrator or Record Officer is logged into SMS

and necessary information must be available

Flow of Events 1. The Admin/Record Officer/ Department head clicks the filter tab of
table that you prefer for report search and fill the form based on
criteria

2. Next clicks apply filter button

3. SMS display stored files in the database

4. The Admin/Record Officer queries necessary information from

database

5. System displays result for the query

6. The Admin/Record Officer clicks on print preview then click on print

button

7. System displays Report in printed format.

Exit Condition Report is generated

Quality Performance Report is generated within 20 seconds.

21
Table 5: Use case description for Classschedule

Use case Name Classschedule

Participating Actors Department head

Entry Condition The Department head is logged into SMS

Flow of Events 1. The Department head clicks the Class Schedule tab and click on
Add New button

2. SMS display Class Schedule form

3. Department head assign classes for each courses instructor by

filling a form and then submit it by click on Save New button

4. The system stores filled information

5. The system creates schedule

Exit Condition Class Schedule is generated.

Quality Performance Class Schedule is generated within 20 seconds.

Table 6: Use case description for NotifyInformation

Use case Name NotifyInformation

Participating Actors Administrator

Entry Condition The Administrator is logged into SMS

Flow of Events 1. The Admin clicks the Announcements tab and click on Add
New button

2. SMS display Announcements page

3. Admin writes by filling the form click on Save New button

4. The system Posts the notification.

Exit Condition Notification is written

Quality Performance Posting of notification is to be confirmed within 10 seconds.

22
Table 7: Use case description for ViewInformation

Use case Name ViewInformation

Participating Actors Administrator, RecordOfficer, Instructor, Parent, Instructor, Student,

Official

Entry Condition The User is logged into SMS

Flow of Events 1. If a parent needs to view status of his/her student

2. System displays a form for search criteria for a student

3. Parent fills in the form and submit

4. Parent selects to view the required report

5. System displays the appropriate report

6. If the user clicks on “view exam schedule” link.

7. The system displays the current exam schedule

8. If the user clicks on “view Schedule” link.

9. The system displays the current schedule

10. If the user clicks on “view Students Marks” link.

11. The system displays a page where the user can select year and
class and then click on “view Marks” button.

12. The system displays the specified year's and class's students'
marks. OR

13. The system gives an error message.

Exit Condition The user finished to view their respective information

Quality Performance Report to be viewed is displayed within 5 seconds.

23
Table 8: Use case description for Upload Mark

Use case Name UploadMark

Participating Actors Instructor

Entry Condition The Instructor is logged into SMS

Flow of Events 1. Instructor head clicks on Grade tab and then click on the Add
New button

2. System Displays Upload Mark form

3. Select student by clicking on student field/row then the database of

the system fills the remaining rows from student table.

4. Instructor insert the students mark and submit it by clicking on Save

New button

5. System stores the uploaded value and returns acknowledgement

Exit Condition Mark is uploaded

Quality Performance Upload of mark is confirmed within 10 seconds

Table 9: Use case description for UploadTTLM

Use case Name UploadTTLM

Participating Actors Instructor, Department head

Entry Condition The user is logged into SMS

Flow of Events 1. User head clicks on the Materials (TTLM)

2. System Displays the form
3. User clicks on clicks on Add New button
4. Users upload TTLM and submit it by clicking on Save New button.
5. System stores the uploaded files and returns acknowledgement
Exit Condition TTLM is uploaded

Quality Performance Upload of TTLM is confirmed within 10 seconds

24
Table 10: Use case description for Update Mark

Use case Name Update Mark

Participating Actors Instructor

Entry Condition The Instructor is logged into SMS

Flow of Events 5. Instructor clicks the grade tab

6. Instructor clicks the Filters tab

7. System Displays form then clicks on filter tab for search the
required record by filling the Grade Filters form by registration ID
number.

8. Then the system displays the search result.

9. Instructors verify the search result and clicking on the record and
update the mark row and submit it to the system by clicking on save
changes button.

10. System stores the updated value

Exit Condition Mark is updated

Quality Performance Update of mark is confirmed within 10 seconds

25
Table 11: Use case description for managefees

Use case Name ManageFees

Participating Actors RecordOfficer,

Entry Condition The RecordOfficer is logged into SMS

Flow of Events 1. The RecordOfficer clicks the Fees Types

2. SMS display the form of collage Fees Structure

3. The RecordOfficer clicks on Add New button

4. SMS display the form.

5. RecordOfficer fill the form and submit it to the system by

clicking on Save New button

6. The System stores the data that you filled.

Exit Condition Fees is created or failed to generate error message

Quality Performance A fee is generated within 3-10 seconds.

Table 12: Use case description for TakeAttendance

Use case Name TakeAttendance

Participating Actors Instructor

Entry Condition Instructor is logged into the system

Flow of Events 1. Instructor clicks the TakeAttendance tab

2. System Displays TakeAttendance form
3. Instructor selects the student by clicking on student field/row.
4. The system will fill the remaining field/row from the database.
5. Instructor fills attendance and submits it to the system by cling on
Save New button.
6. System stores attendance and displays acknowledgement
Exit Condition Attendance is recorded

Quality Performance Recording of attendance is confirmed within 4 seconds

26
Table 13: Use case description for ExamSchedule

Use case Name ExamSchedule

Participating Actors Department head

Entry Condition The Instructor is logged into SMS

Flow of Events 1 The Department head clicks the Exam Schedule tab and click on
Add New button.

2 SMS display Exam Schedule form

3 Department head assign Exam for each courses instructor by

filling a form and then submit it by click on Save New button

4 The system stores the information.

5 The system creates Exam schedule

Exit Condition Exam Schedule is generated.

Quality Performance Exam Schedule is generated within 10 seconds.

27
 3.3.2 Sequence Diagrams

Sequence diagrams show the interaction between participating objects in a given use case. They
are helpful to identify the missing objects that are not identified in the analysis object model. To
see the interaction between objects, the following describe the sequence diagram of each
identified use cases.

In Figure 4.2 below, once the user has activated the registration module by interacting with the
boundary object “AddNewRegisterationButton” button, the control object named
“RegisterationControl” manages the activities involved in “registerStudent” use case. First the
”RegisterationControl” creates registeration form which will be filled by the secretary and
submitted. The registration control sends the record to a persistent storage.

The sequence diagrams for “RecordAttendance”, “GenerateGadeReport”, “ViewReport“ and

“GenerateSchedule” use cases are shown in figures 4.3, 4.4, 4.5 and 4.6 respectively.

: AddNewRegistrationButt : Students
:RegistrationControll
:RecordOfficer
on <<UI>> Filters Form
<<UI>>

Press Button() Create()

Create()

Fill()

Submit()
Validate()

Acknowledge()

Figure 4.2 Sequence Diagram for Student Registration

28
 :RecordAttentandance_ :Attendance :TakeAttendanc
Button Control e Filters Form :AttendanceRecord_
Form

1: PressButton() 2: Create() 3: Display()

4: FillData() 6: Validate()
: Instructor
U

<<actor>> 5: Submit()
7: Display()

8: Validate()
9: FillData()

10: Submit()
11: SubmitForm()

12: Acknowledge()

Figure 4.3 Sequence Diagram for Recording Attendance

29
 : Grade Button Grade Controller : Grade Filters Grade
:RecorOfficer <<UI>>
<<UI>> Filters

Create() Create()
Press Button ()

Fill data()
submit()

Validate()

Generate()
acknowledge ()

Figure 4.4. Sequence Diagram for gradereport

tgradereportGeneration

- 30 -
 ViewStudent_
:StudentStatus :LoginForm :StudentStatusReport
Button Control :ReportForm
: Parent_
<<actor>>

1: PressButton() 2: Create() 3: Display()

4: FillData() 6: Validate()

5: Submit()
7: Display()

8: Validate()
9: FillData()

10: Submit()
11: SubmitForm()

12: GenerateReport()

Figure 4.5 Sequence Diagram for viewing student status by the parent

- 31 -
 : Schedule Button : Schedule Control :Generate Schedule : Schedule
:Admin <<UI>> Form <<UI>>

Press Button Create()

Display()

FillData()
Submit()

Validate()

Create()

Acknowledge()

Figure 4.6 Sequence Diagram for generating class

Schedule

- 32 -
- 33 -
3. Object Model

3.1 Data Dictionary

Table 14: Data Dictionary

Shape Representation of

Attribute of entity

Entity

Process

Data Flow

Relation

3.3.1 Class Diagrams

Class diagrams show the static structure of the model, in particular, the things that exist
- 34 -
(such as classes and types), their internal structure, and their relationships to other things.
The potential classes or the entireties of Wolkite poly technic collage and Satellite
University the Student management system as the follows:-
Student

Student is the main or the mandatory actor in these in Student management system. All
the other entities of the system are directly or indirectly give serves to the student class.
The Purpose of the student is very essential in collage management and without
student the system becomes functionless.

Attributes of Student are:-

First name, LastName, Sex,Age,Address,Id

Functions of student are: -

View mark, log in,

Teacher

The teacher in Student management is also very essential class or entity next
to student.

Attributes of teacher are: -

First name, LastName, Sex, Age, Id, salary

Functions of Teacher: -

Registering students, teaching students, Take attendance and Manage marks

RecordOfficer

Another potential entities or the class of Student management that he/she

know how about the records and how record keeping.

Attributes of RecordOfficer
- 35 -
First name, Last name, Sex, Age, Id, Address, Salary

Functions ofRecordOfficer

RegisterStudent, GenerateReports, GenerateTranscript, UpdateRecord

 - 36 -

Figure 2: Entity, boundary and Control objects

 3.3 Dynamic Model

3.3.1 Sequence Diagram

Sequence diagrams are an important member of the group known as interaction diagrams (
which are used to model important runtime interactions between the parts that make up a system
and form part of the logical view a system model).sequence diagrams are the most popular of the
three integration diagram types namely sequence diagram, state machine diagram and activity
diagram. Sequence diagram are all about capturing the order of interactions between parts of the
system. Here are some of the sequence diagrams for our system.

1. Register Student

Figure 3: RegisterStudent Sequence Diagram

2. Update Record

- 37 -
Figure 4: Update Record Sequence Diagram

- 38 -
3. Generate Schedule

Figure 5: Generate Schedule Sequence Diagram

4. Generate Transcript

- 39 -
Figure 6: Generate Transcript Sequence Diagram

- 40 -
5. Generate Report

Figure 7: GenerateReport Sequence Diagram

6. Generate Report

- 41 -
Figure 8:GenerateReport Sequence Diagram

- 42 -
7. Take attendance

Figure 9: TakeAttendance Sequence Diagram

8. Manage Mark

- 43 -

Figure 10: ManageMark Sequence Diagram

 3.3.2 Activity Diagram

Activity diagram are particularly good at modelling business process which is a set of
coordinated tasks that achieve a business goal. Some business process management (BPM) tools
allow you to define business process using activity diagrams, or a similar graphical notation, and
then execute them (Kim H. et al, 2006). Here are some activity diagrams of our project.

- 44 -

Figure 11: Student Registration activity diagram

Figure 12: Report Generation activity
- 45 -diagram
Figure 13: Take Attendance activity
- 46 diagram
-
3. Glossary
Actor: players (participants) of the system.

Attribute: The name or structure of field or an element.

Users: intended users for the web page.

Entity: An item that can be treated as a unit and often as a member of particular category or
type.

Flow diagram: shows how the program/system will be used, by showing the flow of
execution

User interface: the section to what the user interacts with system

Use case: a broad level diagram of the project showing a basic overview

Interface: something used to communicate a cross different mediums

Hard ware: is computer equipment. It including all the components use to make the
computer

Software: computer programs, instructions that make hardware work.

System: any collection of component element that work together to perform task.

Information: The meaning of data as it is intended to be interpreted by people.

Internet: the worldwide collection of network.

- 47 -
Chapter 2: System Design Document SDD
1. Introduction
This System Design Document (SDD) presents the technical details of the SMS system design.
More information about the specific features and the motivation for SMS can be found in the
Requirements Analysis Document (RAD) and the Problem Statement. This document starts with
an introduction to the architecture and the design goals to be considered. Then it presents the
proposed system architecture by describing the subsystem decomposition and the subsystem
services. The hardware/software mapping is defined and the management of persistent data is
explained. Access control and security issues are addressed. The global software control and
boundary controls are described. Finally a glossary of important terms is provided.

1.1. Purpose of the System

As we have identified the functional and non-functional requirements of the system and
produced the analysis model in RAD.

The purpose of the Software Design Document is to provide a description of the design of a
system fully enough to allow for software development to proceed with an understanding of
what is to be built and how it is expected to build.

The Software Design Document provides information necessary to provide description of the
details for the software and system to be built. The results of the system design process are
recorded in the System Design Document (SDD).

1.2. Design goals

- 48 -
The definition of design goals is the first step of system design. It identifies the qualities that our
system should focus on.

The goal of the system is to satisfy the functional and non-functional requirements as specified in
the requirements specification document.
Design goals describe the qualities of the system that developers should optimize. Such goals
are normally derived from the non-functional requirements of the system.

The project team tried to group design goals into five categories. These are: -

o Performance

o Dependability

o Development Cost

o Maintenance

o End User Criteria

1.1.1. Performance Criteria

The part of the system to be used for the record office should have a fast response time (real
time) with maximum throughput. Furthermore, the system should not be taking up too much
space in memory. The record officer has chosen fast response time over throughput and hence
the system should try to be more interactive.

In the case of the timetabling subsystem, the system should be more reliable in order to satisfy
the constraints than fast response time.

1.1.2. Dependability Criteria

The collage needs the system to be highly dependable as it is expected to be used by non-IT
professionals. The system should be robust and fault tolerant. Furthermore, as the system is
handling sensitive data of the collage, high emphasis should be given with regards to security, as
there are subsystems to be accessed through web.
- 49 -
1.1.3. Development Cost

The system should be developed with minimum cost possible. In reality there is always trade-
offs and therefore the office prefers to invest more on development cost than maintenance cost to
minimize bugs which may appear at the later stage.
 1.1.4. Maintenance Criteria

The system should be easily extensible to add new functionalities at a later stage. It should also
be easily modifiable to make changes to the features and functionalities.

Extensibility: - The new system is easy to add other functionality or new classes to the system
including managing other collage resources like library material, financial and human resource.

Readability: The code written by well-known programming language PHP, hence it is easy to
understand the system from reading the code.

1.1.5. End User Criteria

Usability: Usability is the extent to which a product can be used by specified users to achieve
specified goals with effectiveness, efficiency and satisfaction in a specified context of use. From
the end users‟ perspective the system should be designed in such a way that it is easy to learn
and use, efficient and having few errors if any.

Utility: the new system shall to support the work of the user.

Trade-off is inevitable in trying to achieve a particular design goal. One best case is the issue of
security versus response time. Checking User-Id and Password before a member can enter to the
SMS creates response time problem/overhead. The other case is the issue of response time versus
quality. There is some amount of time taken by the system to generate the timetable. So the user
has to wait a little after telling the system to generate the timetable and getting the result to get a
quality timetable.

1.3. Definition, Acronyms and Abbreviations

This subsection providing terms and definitions for internal use- of

50the
- document such as: -

Existing system: the current system running in the organization.

Design: a means of drawing produced to show the look and functions of something before it is
built and made.

Hardware: Physical component of computer system.

Internet: a global computer network providing a variety of information and communication

facilities.
Management: the process of managing resources.

Mapping: the diagrammatical representation of a collection of data showing their arrangements.

Collage: a place for educating people within the instruction is given in specific discipline.

Software: programs used by computer.

Trade-off: a balance achieved between two desirable but incompatible features.

Unit leader: A person who coordinate other individual to achieve a common goal.
Utility: useful, especially through having several functions.

1.4. References
As we have already discussed in the requirements analysis document to refer existing systems
problems, we have been used manual and reports documents made by the collage staff. The team
used internal or external source and SDD templates in order to meet to the objectives of the new
system and functional requirements identified in RAD.

 XML Legal Document Utility Software Design Document-version 1.0.

 Lawrence Chung, Advanced Software Engineering syllabus, CS 6354 section 581, summer
2007. http://www.utdallas.edu/~chung/CS6354

 Bernd Bruegge, Allen H. Dutoit, Object-Oriented Software Engineering using UML, second
edition. Prentice Hall, 2003. http://wwwbruegge.in.tum.de/OOSE

1.5. Overview

The purpose of this design document is to provide the design models and methodologies that are
developed and used to satisfy the requirements.
- 51 -
This document presents detailed diagrams that represent the functionality of the system from the
system's point of view to provide the necessary interfaces to the users.

The Software Design Document is divided into four sections with various subsections.
The sections of the Software Design Document are:-

 Introduction,

 Current Software Architecture,

 Proposed Software Architecture and

 Subsystem Services.

- 52 -
 2. Current Software Architecture
Currently there is no software architecture for the SMS. The system that is applied on consists of the
top level management, lower level management, middle level management and operational
employees. As shown in the figure below, regional educational and training board and Wolkite
poly technic collage dean are on the top level management who is responsible to lead and
coordinate the collage society in general.

Teaching, scheduling classes evaluating both teachers and students, managing teaching learning
process, ratifying the student grades and lesson plans are responsible of middle level
management. This level involves the assistant educational director and assistant administrative
director of the collage.

The unit leader part of lower level management have the responsibility of keeping good
educational standard, evaluating students and teachers, posting announcement and solving
problems in educational system of the collage. Though the existing system and its functionalities
seem well organized, as we discussed in the requirement analysis phase the collage working
system faces many problems in changing those aspects to practical.

3. Proposed Software Architecture

3.1. Overview

The proposed system is expected to replace the existing manual system by an automated system
in all facets. It is mainly based on the system Analysis document (RAD).

The architecture used for the system is a three tier Client/Server Architecture where a client can
- 53 -
use Internet browsers to access the online report provided by the system within the local area
network of the collage or anywhere using the Internet.

The data tier maintains the applications data such as student data, teacher data, timetable data etc.
It stores these data in a relational database management system (RDBMS).

The middle tier (web/application server) implements the business logic, controller logic and
presentation logic to control the interaction between the application’s clients and data.
The controller logic processes client requests such as requests to view student’s result, to record
attendance or to retrieve data from the database. Business rules enforced by the business logic
dictate how clients can and cannot access application data and how applications process data.

A web server is a program that runs on a network server (computer) to respond to HTTP
requests. The most commonly used web servers are Internet Information Server (IIS) and
Apache. The web server used in this system is Apache.

HTTP is used to transfer data across an Intranet or the Internet. It is the standard protocol for
moving data across the internet.

The client tier is the applications user interface containing data entry forms and client side
applications. It displays data to the user. Users interact directly with the application through user
interface.

The client tier interacts with the web/application server to make requests and to retrieve data
from the database. It then displays to the user the data retrieved from the server.

- 54 -

Figure 15: Architecture of the proposed System

 3.2. Subsystem Decomposition

Subsystem decompositions will help reduce the complexity of the system. The subsystems can
be considered as packages holding related classes/objects. The SMS under consideration is
decomposed into subsystems as shown in Figure 3.2. These subsystems are further decomposed
into other subsystems.

The major subsystems identified are “StudentRegistration”, “UploadMark”, “TakeAttendance”,

“GenerateReport ”, “GenerateTranscript”, “GenerateSchedule” and “ViewReport” subsystems.
Users are classified in to roles.

The “StudentRegistration” subsystem registers a student offline. It allows recording the details
information of the student including parental and emergency person.

The “Transcript” and “GenerateReport ” subsystems are used to generate transcript and report
card respectively. The “Timetable” subsystem generates a timetable, which involves allocating a
time slot to a subject teacher for a class of students.

The “UploadMark” subsystem enters student mark to the database by subject teacher.

The “TakeAttendance” subsystem facilitates recording absent students on the collage day by the
homeroom teacher to control absentees and to report to parents and the administrator to take
corrective measures. The “ViewReport” subsystem generates reports to parents, officials from
any stakeholders and teachers in order to facilitate viewing students‟ status and course
achievement online.

- 55 -
 Figure 16: Layered Representation of the System

Further decomposition of some of the subsystems is shown in Figure 3.3.

- 56 -

Figure 17: Subsystem Decomposition Diagram

 3.3. Hardware/Software Mapping: -

One of the major tasks in system design deals with hardware/software mapping which deals with
which components would be part in which hardware and so on. The SMS is a broad system that
performs many functions as described in RAD. It consists of web based system used by
homeroom teachers to record attendance. The web based system also assists parents and officials
to get or view status and report on students‟ achievement and progress. The system assists the
record officer to generate transcript and report cards. So the web based part is expected to run on
a networked environment on different Operating System platforms. The client/server architecture
of the system enables different clients to connect to the server remotely through Internet
connection. The system has two nodes such as the Web server and Clients. These nodes are
shown as UML Deployment diagrams in Figure 3.4. The nodes can represent specific instances
(workstations) or a class of computers (web server), which is a virtual machine. The applications
of the system will run on the web server connected to the database server by MySQL.

- 57 -

Figure 18: Deployment Diagram of the System

 3.4. Persistent Data Management

Persistent data management deals with how the persistent data (file, database, etc) are stored and
managed and it outlives a single execution of the system. Student Management System will
largely depend on a relational database to perform day-to-day operations and storing log data.

Therefore, the subsystems discussed in the above subsystem decomposition section user interface
subsystems that run on client computer and the persistent data aspects of these subsystems will
be stored in MySQL Server DB. Information related to student basic information, student‟s
attendance and grade mark, the timetable produced and other related information are persistent
data and hence stored on a database management system.

This allows all the programs that operate on the SMS data to do consistently. Moreover, storing
data in a database enables the system to perform complex queries on a large data set. The
collages register students every year in thousands per grade level. For complex queries over
attributes and large dataset Microsoft SQL Server is implemented, which is a Relational
Database Management System.

Mapping

In order to store information persistently the team map objects into tables and the attributes into
fields to the specific table based on the objects found on the system. Therefore, team also
identified the major tables that will be implemented on the selected DBMS. For this reason,
some of the mapping of objects to tables is displayed as in Fig 19.

- 58 -
 Figure 19: Sample Mapping Objects into Tables

Relationships among Tables

This part is to describe and show the necessary relationships among the tables, which are
selected to store the data persistently in the system. Generally there are three types of
relationships in a relational database system. These are one-to-one, one-to-many and many-to-
many relationships. The system under consideration has one-to-many and many-to-many
relationships. Student and AcademicSubject tables have many-to-many relationships. One of the
aims in a database system is to reduce redundancy and for that purpose many-to-many
relationship has to be reduced to one-to-one relationship. The Student and StudMarks and the
AcademicSubject and StudMarks have one-to-many relationship by using the StudMarks table as
the associate table.

3.5. Access Control and Security

Access controls are security features that control how users and systems communicate and
interact with other systems and resources. For authentication, we choose login and password
which is the simplest method, would only provide a password service within their privilege.
Each subsystem must then decide and enforce any access rights for the different kinds of users
that use that subsystem. The database will be backed up on a daily basis to ensure data security.

For Authorization, different actors have different access rights for system functionalities. The
system should always display clear error messages as alert box and be able to make suggestions
to the user as to what measures should be taken in order to fix the problem. Access Control
Matrix: A common way to describe access control of objects is to create Access Control Matrix.
- 59 -
The following illustrates model different access right by associating some of actors with objects.
Table 15: Access Control Matrix

Administrator(Director) Record Instructor Student Department

head
Officer

Logging In Yes Yes Yes yes Yes

AddRecords Yes Yes No No No

DeleteRecords
UpdateRecords

TakeAttendance No No Yes No No

NotifyInformation Yes No No No No

GenerateTranscript No Yes No No No

RegisterStudents

UploadMark No No No No Yes

- 60 -
 3.6. Global Software Control

As the sequence diagram looks like a stair the project team choose explicit control (decentralized
one) hence decentralized control arises when the participating objects communicate directly
with one another, not through one or more controlling objects. And also possible speedup by
mapping the objects on different processors, increased communication overhead and fits nicely
into object-oriented development.

The project team choose Procedure-Driven Control which operations wait for input whenever
they need data from an actor

3.7. Boundary Conditions

One of the main proposals of Boundary Conditions is to describe how the whole system can be
started, what services initialize first.

Initialization: - To startup just go to system URL and login.

Shut Down: Click log out and close browser.

Error Conditions:

 Logging in possible alert messages are:-

o Username or passwords are required.

o Password is not 8 characters long.

o Password and username don‟t match.

o Username is wrong or does not exist.

- 61 -
 Logging out

Are you sure to leave this page?

 4. Subsystem Services
The fourth section, Subsystem services, describes the services provided by each subsystem in
terms of operations. This section describes the services each subsystem provides along with their
needs and abilities. The interface of each subsystem is derived from this section and detailed in
the Object Design Document.

Services of the StudentRegistrationsubsystem

 Needs

 There must be available student list with their detail information including full address.

 Abilities

- Registers a student and allows recording the details information of the student including
parental and emergency person.

Services of the GenerateTranscript subsystem

 Needs

- Student information including their marks must be available.

 Abilities

- Used to generate transcript

Services of the Report subsystem

 Needs

- In order to generate student report card, student information including their marks must
be available. - 62 -

 Abilities

- Used to generate report card of the students.

Services of the GenerateSchedule subsystem

 Needs

- In order to generate schedule, teacher and class information must be known and
 available.

 Abilities

- It involves allocating a time slot to a subject teacher for a class of students.

- Used to generate timetable for students that able to manage their class properly.

Services of the UploadMark subsystem

 Needs

- In order to upload each student mark, subject teacher must know his/her student marks
and some details including Stud ID.

 Abilities

- Enters student mark to the database.

Services of the TakeAttendance subsystem

 Needs

- Home room teacher wants attendance taken date, student name and Stud ID.

 Abilities

- To facilitate recording absent students on the collage day

- To control absentees and to report to parents and the administrator to take corrective
measures.

Services of the ViewReport subsystem

 Needs
- 63 -
- Generated reports.

 Abilities

- View reports to parents, officials from kebeles and kifle-ketema and teachers in order to
facilitate viewing students‟ status and course achievement online.
 5. Glossary
Actor: external entity that needs to exchange information with the system; an actor can represent
either a user role or another system

Access: is the flow of information between a subject and an object.

A subject: is an active entity that requests access to an object or the data within an object.

An object: is a passive entity that contains the information.

Initialization: The system is brought from a non-initialized state to steady-state

Subsystem: division of the system into subsystems

Subsystem Services: functionalities that must be provided by the subsystem

6. Cost Estimation
For the successful accomplishment of the technology, the costs associated with each items required have
been estimated. This will help us to limit the constraints related to cost while the technology is conducted.
From the beginning up to the end of this technology we planned the following cost list.

No. Item quantity Price per item Total price

1 Flash 1 (32GB) 400 400

2 DVD 2 25 birr 50

3 Microsoft office 2010 1 - -

- 64 -
4 Edrawmax 7.9 1 500 500

5 Wamp 1 -

6 Dreamweaver 1 2500 2500

Total 3450
6.1 Total cost of the project
Developing Cost = Materials cost + Labor cost + Overhead costs

= Materials cost + Labor cost +(Depreciation cost + Electric cost)

3450+(6000) developing cost +material cost

Dcost = 94508birr

Taking 5% of D cost as contingency = (5/100)* 4690.08birr r

Contingency =644.504

Total D cost = 9450

Profit = 20% of D cost=0.2x9450=1890 birr

Selling price = D cost + profit

The Selling price of the academic council =11340birr

- 65 -
Chapter3: Object Design Document (ODD)
1. Introduction
The proposed system consists of subsystems which work separately but concurrently.

Subsystems interact with each other and each subsystem works when it is called by another

subsystem. During the object design, characteristic of each system must be considered its own

and the whole system must be considered.

1.1 Object design trade-offs

In the object design phase some trade-off decisions may needed to be made:

1.1.1 Development Cost versus Functionality

Collage management broad concept and provides a lot of functions for users such as managing

student information and the like. Each function of the system requires extra design and this

causes an extra cost for the development.

1.1.2 Understand ability versus Cost

Understand ability of the code is too important especially during the testing phase. Each class

and method must be readable, so number of methods increase in the system and functions must

be implemented in a clear way. Writing comments into the source code increases the Understand

ability of the code. This causes an additional cost in the developing phase.
- 66 -

1.2 Interface documentation guidelines

Interface documentation guidelines and coding conventions are the most important factors that

can improve communications between developers during object design.

 1.2.1 Naming and Coding Conventions

Packages: lowercase.

Files: file names have the same base name as the public class they define.

Classes: Capitalized With Internal Words Also Capitalized

Exception class: Class Name Ends With Exception.

Interface. When necessary to distinguish from similarly named classes:

InterfaceNameEndsWithIfc.

Constants (finals): UPPER_CASE_WITH_UNDERSCORES

Private or protected: (pick one!) firstWordLowerCaseButInternalWordsCapitalized

Static private or protected: firstWordLowerCaseButInternalWordsCapitalized

Local variables: lower_case_with_underscores

Methods: firstWordLowerCaseButInternalWordsCapitalized()

1.3 Definition , Acronyms and Abbreviations

Interface: Used as a bridge between computer and users.

Packages: an object or group of objects wrapped packed in box.

1.4 References
- 67 -
 Brend, B., Allen, H.,Object- Oriented Software Engineering

 https://www.cs.uic.edu/~jbell/CourseNotes/OO_SoftwareEngineering.
2. Packages
2.1 Package Diagram

- 68 -

Figure 20:- Package Diagram

 2.2 Package Definition

The following are some of the main packages including:-

1. User Package

The package name is user package, and is responsible to add list of students, parents, Home

room teachers, subject teachers, administrators, record officer, and officials in to the

database. It takes users‟ list and detail information from users and sends them to database.

2. Certificate Package

The package name is Certificate package, and is responsible to generate student certificate. It

takes student information from the persistent storage and displays students‟ transcript and

report card.

3. Report Package

The package name is report package, and is responsible to prepare report with detail

information of activities under taken in the collage.

4. Attendance Package

The package name is attendance package, and is responsible to control student absentee on

the collage day.

5. Mark Package - 69 -

The package name is mark package, and is responsible to students‟ mark into the database.

6. Schedule Package

The package name is schedule package, and is responsible to generate schedule for both

class and exam.

 3. Class Interface
3.1 Class Definition

Admin Class

- This Admin class is part of the user package, and it has one private global variable
(section) and inherits four variables from its super class (name, sex, age and address).

- This Admin class has two public global methods (uploadMark(), and

Update Mark ()), and also inherits a method called viewReport().

- The first method upload Mark (), allows the Admin to add students‟ mark into the
database.

- The second method update Mark (), allows the Instructor to modify students‟ mark.

Instructor/ Teacher Class

- This Teacher class is part of the user package, and it has one private global variable
(section) and inherits four variables from its super class (name, sex, age and address).

- This Instructor/ Teacher class has two public global methods (takeAttendance(), and

generateRepCard()), and also inherits a method called viewReport().

- The first method takeAttendance(), allows the Instructor/ Teacher to take students‟
attendance daily.

- The second method generateRepCard(), allows the Instructor/ Teacher Classe to take
student‟s mark from the database filled by each Instructor for his/her respective course
and prepare a student‟s report card annually.
- 70 -
Student Class

- This Student class is part of the userpackage, and it has five private global variables
(name, id, sex, age,section).

- This student class has one public method (viewMark()).

- The method viewMark(), allows the Student to look his/her own mark he/she has
obtained for each course
3.2 Class Diagram

- 71 -

Figure 21:-Describes the classes and their public interfaces (UML Class Diagram)
 Chapter 4: Implementation and Testing Document
1. Implementation
In this section, the tools used in developing the prototype, the developed system and documenting
testing are described.

1.1. Programming Tool

The system has web based applications which is known as thin-client application. The Web
application is developed using PHP with MYSQL for back end.

1.2. The SMS Prototype

Here, the implemented system is described. How the user interacts with the system and some of the
results of interaction with the system along with the screen shots are described. When a user starts
the application, a login page is displayed as shown in Figure 7.1 within the main menus of the
system.

- 72 -

Figure 22:- Login page

Sample Login Page Description

(1). Title banner and system logo.

(2). Access type with some attribute.

(3). Footer banner: contain copy right and project team information.

The following sample page illustrates how students can register by clicking save data button
after filling the form with their specification value.

- 73 -
 2. Testing Document
2.1. Test plan

2.1.1 Introduction

The main objective of test plan is to define the various testing strategies and testing tools used
for complete testing life cycle of this project. This section describes the plan for testing the
architectural prototype of the collage management System. The Test Plan has been created to
communicate the test approach to team members. It includes the objectives, scope, schedule,
risks and approach. This document will clearly identify what the test deliverables will be and
what is deemed in and out of scope.

The Test Plan document documents and tracks the necessary information required to effectively
define the approach to be used in the testing of the project’s product. The Test Plan document is
created during the Planning Phase of the project. Its intended audience is the project manager,
project team, and testing team. Some portions of this document may on occasion be shared with
the client/user and other stakeholder whose input/approval into the testing process is needed.

2.1.2 Relationship to Other Documents

Those tests are related with other previous document such as RAD and SDD. Amongst tests
which are related with functional are register functionality, upload mark functionality, login
functionality. There are also non-functional requirements that the team going to test. Example: -
security, usability and performance.

2.1.3 System Overview

During unit testing there are components which are depend with- 74
one- another. For instance while
testing registration subsystem it is highly depending on the teacher and student detail information
within their valid data entry. The testing processes of the new system were split into two major
portions, such as: -

 The first part of this process involves testing the compliance of the system
against the functional requirements discussed in the previous document.

 The second part of the testing process is concerned with aspects such as
performance and efficiency.

- 75 -
 2.1.4 Features to be tested/not to be tested

Features to be tested

It is assumed that unit testing already provided thorough black box testing, and testing of all
module interfaces. The tam will be tested the User Interface by verify ease of navigation through
a sample set of screens and verify sample screens conform to GUI standards.

The basic features/functions that will be tested in our system include the interfaces between the
following subsystems:-

1. Registration subsystem

2. Report subsystem

3. Upload Mark subsystem

These functionalities will be tested individually by the team members with some selected
collage staffs as the system completed.

Features not to be tested

The functions or features not to be tested are not other than mentioned in features to be tested in
the above section.

2.1.5 Pass/Fail criteria

Pass Criteria

- Execute each use case, use case flow, or function, using valid and invalid data, to verify the
following:-
- 76 -
 The expected results occur when valid data is used.

 The appropriate error / warning messages are displayed when invalid data is used.

 Each business rule is properly applied.

- Additionally the user authentication is maintained through MD5 encryption technique for
better data base security.
Fail criteria: - If the above pass criteria are not fulfil.

2.1.6 Approach

Major portion of the application functionality will be tested whilst the system is being built. This
involved the use of structural or white box testing on completion of each functional unit, by
using the underlying knowledge of the code. The main reason to choose this approach is because
of it is aim to test boundary and decision conditions within the code.

Not only this but also, on completion of the new system, the black box testing method will be
applied to develop a set of test cases.

Usually, for specification based testing methods some sort of formal specification is written. For
each functional unit categories, partitions and constraints were identified and then written in a
test specification language.

2.1.7 Test Suspension / Resumption Criteria

As we planning to test the new system with the end users, their levels of understanding to the
system as well as their interest will be the suspension and the resumption criteria that were used
to suspend as well as resumed all or portions of our testing.

Another constraint for test suspension and resumption are the flow of events performed one
another.

For example

1. Before the actors logged in to the system within their valid data entry, other system
functionality will be suspension and resumed while they login successfully.
- 77 -
2. If the registration subsystem is not tested before, then view student report will not be tested.
etc.
 2.1.8 Testing materials (HW/SW requirements)

All tests will be carried out by using the following specification machine, with the proposed
system and load testing tool present on the same machine.

Hardware requirement

 Processor: 2 GHz

 Memory: 4GB RAM

 Operating System: Windows 7

Software requirement

 Apache web server

 MySQL database server

2.1.9 Testing cases

The testing procedure was carried out with test data which were written only after considering
the subsequent cases the system would pass through after becoming operational:-

Case1
Invalid Data
Case2

Ambiguous data

Case3

Forceful alteration of related records - 78 -

Case4

Changing the values of an automatically calculated fiel

 2.1.10 Testing Schedule

Table 16:- Testing Schedule

Task Name Start Finish Effort

Test Planning 25/01/2015 26/01/2015 1day

Review Requirements documents 27/01/2015 29/01/2015 2 day

Create initial test estimates 30/01/2015 01/02/2016 1 day

Staff and train new test resources 02/02/2016 04/02/2016 2 days

Functional testing – Iteration 1 05/02/2016 06/02/2016 1 day

Functional testing – Iteration 2 07/02/2016 08/02/2016 1 day

System testing 09/02/2016 10/02/2016 1day

Resolution of final defects and final 11/02/2016 13/02/2016 2 days

build testing

Performance testing 14/02/2016 15/02/2016 1 day

- 79 -

Test Execution 25/02/2016 18/02/2016 15 days

 2.2. Test Cases Specification

Test cases specifications for our system are more complex task. The traditional testing model is
insufficient, because objects in a program have their own states which may well be impacted by
the processing of input parameters.

2.2.1 Test Case Specification Identifier

Case1: Invalid Data

The system would face invalid data most often. The reasons might be either typographical errors
or lack of user experience and insight. An invalid data might be:

a). A String expression in a field, meant to hold number or currency.

b). An empty string in a field, marked “Not Null” (Required) in the

database c). An invalid date in date/time field.

A user might happen to enter invalid data unknowingly. For example, one might leave the Name
field of a student empty, or, might enter some text instead of a numeric data in a
currency/numeric data field. The test data was prepared to see how the system would deal such
situation!

Case2: Ambiguous data

Sometimes ambiguous data might be encountered by the system because of some sort of human
error or playful action of frustrated user(s).

To be a bullet-proof solution to the needs of a collage, the system must be able to successfully
identify and neutralize them. For example, let’s consider a hypothetical
- 80 - situation when the record
book shows that a student’s date of birth is greater than his date of joining the collage. It is quite
unnatural and thus this kind of woolly data must not be entertained by the system.

Case3: Forceful alteration of related records

Tables in the database are related to each other by foreign key references and same is the case
with records. A user might try to forcibly alter the related records. The system should be immune
against any such attack. Some test data was written specifically for the purpose of appraising the
system’s response in case of such conducts.

Case4: Changing the values of an automatically calculated field

The student report card generation is done automatically by the system. A user might try to
change the value in the „Total‟ field manually. The system must not agree to him. For that, the
field should be locked. Test data was written such that those locks should be tested to trust.

2.2.2 Input and Output Specification

Figure 24:- Login form of Record officer

Examples of test cases1invalid data produced from the Login form are given in Table 17.

Table 17:- Test cases produced - 81 -

For example, consider a program that has objects of this class in proposed system:-

<?php
if(file_exists("secret.
php"))

{ require_once("secret.php");

$formuser= !isset($_POST['formuser'])?NULL:$_POST['formuser'];

$formpassword= !isset($_POST['formpassword'])?NULL:
$_POST['formpassword']; if(($formuser != ADMINUSER ) ||
($formpassword != ADMINPASSWORD ))

include("adminLoginForm.
php"); exit();

if (($formuser == ADMINUSER ) && ($formpassword ==

ADMINPASSWORD )){ session_start();

$_SESSION['basic_is_logged_in'] = true;

$_SESSION['adminUser'] = ADMINUSER;

$_SESSION['adminPassword'] = ADMINPASSWORD;

$SID = session_id(); - 82 -

$adminHome =
ADMINHOME;
include($adminHom
e);}?>
Student

-name: String

-rank: int[]…

+addrank(int mark): void

+sortedrank(): int[]…

In our test case specification, only the important methods are listed. Suppose a test case is
developed for sortedrank(), where sortedrank() is supposed to sort the rankarray and then return
the sorted values. Consider the following test case item:

<add rank: (3, 2, 1), expected output of sortedrank(): 1, 2,3>

However, without examining the environmental need of the Student object, it is unknown
whether the rank array has actually been altered, or if thesortedrank() method simply returns a
sorted array of integers without actually altering the rank array.

The method sortedrank() is designed to return the rank[ ] array as a sorted list without affecting
the rank[ ] array itself. The reason for this is so that the user may specify in the interface that
they want rank in ascending order by percentage. However, they may also want special
requirement procedure the ranks in the order that they were entered, so it is important to preserve
the original state. This means that not only should the expected output of the method be tested,
but the expected state of the class should also be included in the test case.

<add rank: (3, 1, 2), expected output of sortedrank(): 1, 2, 3},Expected

- 83 - state of rank[]: {1, 2, 3}>
2.3. Test Incident Report

The Test Incident Report documents all issues (bugs) found during different test phases. It‟s the
detail of the actual versus expected results of a test, when a test has failed, and anything
indicating why the test failed.

 It‟s uniquely numbered and tracked to resolution.

 Defect tracking tools are preferred.

 2.4. Test Report Summary

A detail of all the important information to come out of the testing procedure, including an
assessment of how well the testing was performed, an assessment of the quality of the system,
any incidents that occurred, and a record of what testing was done and how long it took to be
used in future test planning.

This final document is used to determine if the software being tested is viable enough to proceed
to the next stage of development. Once approved, this report represents the approval and
acceptance of the executed tests.

o Scope of testing

o Deviations from the original Test Plan

– Justification for the deviation:

– Impact of deviation:

- 84 -
Chapter 5:-Conclusions and Recommendations
1. Conclusion
In this project, we developed an automated student management system that facilitates
the various activities taking place at the college.

The system developed in the project is a web application. This performs the activities such as
student registering, transcript, report card generation and report card generation and
producing the schedule.

The system facilitates attendance recording by the homeroom teachers and to view reports,
to view status of students by students, teachers and parents. Our solution of the scheduling
problem is very simple.

The scheduler selects a subject-teacher from the database, retrieves all the classes assigned to
the teacher, calculates the load of the teacher which cannot be greater than the maximum load
and selects one of the days randomly based on the number of lessons of the subject, searches
a free appropriate time slot and assigns the slot to the lesson. The scheduler repeats the
process until the load of the teacher becomes zero and all the teachers in the database are
visited.

The prototype has been tested with some staffs from the collage. It has been shown that the
system effectively registers students along with parental information, easily retrieves
information about a student and generates the required reports such as transcript, report card
and timetable.
- 85 -
In addition to generating a feasible master timetable it produces a timetable for each teacher.
Furthermore it has been shown that the system helps attendance recording by the homeroom
teacher and parents can view the status of their children using the Internet.
2. Recommendations
To enhance the efficiency of the system, we have listed some recommendations and future
works.

As education is central to development there should be a good facility to make

stakeholders participate in collage improvement programs and decision making. Parents
and officials are among the stake holders. To facilitate easy information access to such
bodies the system could be further enhanced by incorporating additional reports required
by officials from Education Bureaus. Such facilities will increase participants in decision
making at educational activities and students achievement.

We also believe that from the various facts that constitute the project, the following
recommendations also have come to light:

• Users of the system should have basic computer knowledge

• The collage should have adequate computer facilities for the introduction of
the new system.

• There should be network infrastructure in order to connect the computers each other.

• The collage should enhance its employees in to technology oriented

environment [i.e. it should provide the employees with short term computer
training.

- 86 -