Final

This project paper is submitted to department of information system to final
fulfillment of the requirement for degree of Bachelor of Science in

information system
Prepared by:
Kefale Tamene …….……………..KIOT1429/04
Wubie Bewuket ….……………….KIOT1461/04
Wubshet Tesfaye…..……………...KIOT1462/04
Ayalew Ashebir……………………KIOT1450/03
Adviser: Mr. Asmelash G/S.

Declaration
This project is our own and has not been presented in any previous application for a degree.
(Name and Signature of the project group members)
Name Signature
Kefale Tamene …….……………

Wubie Bewuket ….……………….
Wubshet Tesfaye …..……………...
Ayalew Ashebir ……………..
COLLEGE: INFORMATICS
Program: INFORMATION SYSTEM
Project subject: WEB BASED ACADEMIC AFFAIRS AINFORMATION MANAGEMENT SYSTEM

I certify that this project satisfies all the requirements as a project for the degree of Bachelor of
Science.
------------------------------------- ---------------------------------------------
Name of program coordinator Signature
This is to certify that I have read this project and that in my opinion it is fully adequate, in scope
and quality, as a project for the degree of Bachelor of Science.
------------------------------------- ---------------------------------------------
Name of Advisor Signature
Examining committee members signature Date
1. Examiner 1 ____________ ___________
2. Examiner 2 ____________ ____________

It is approved that this project has been written in compliance with the formatting rules laid
down by the college of the university.
Wollo University Kombolcha Institute of Technology college of
Informatics Department of Information System 2007 E.C
AKNOWLEDGEMENT
First of all we would like to say thanks to almighty God for giving us opportunity and strength to
complete this project.
Next we would like to thank our advisor Mr.Asmelash Gebressilassie for his constructive
opinion and willingness participation, assistance and guidance for the accomplishment of this
project.
We also wish to thank to dean of informatics collage and department head of information
system, who gave us the required information about this project.
Finally, we want to extend our thanks to our parents for their encouragement, Motivation and
support throughout our study.
WEB BASED ACADEMIC AFFIAR INFORMATION MANEGEMENT STSTEM FOR KIOT

[
WU KIOT Informatics College ,Department of Information System
] 2007 E.C
Abstract
Now days, using computers to simplify tedious manual work is significance. Because using
computer gives many benefits such as speed, accuracy, storage capacity, flexibility, cost
reduction and minimizing tedious manual work. Kiot academic affairs information management
system limited on manual works. This has limitation on data security, distribution, response time,
lost of data and high consumption on resources. Manual data processing system is not fast and
efficient way to accomplish tasks within short period of time and it is boring.
To overcome this problem we are proposing the new web based system for KIOT. The
programming tools used to develop this project like Wamp server for interfacing and coding,
MySQL for database application, and Microsoft Visio for designing different artifacts of the
project.
Finally the overall activity of this project work is about design and implementation of web based
academic affairs information management system for KIOT
Web Based Academic Affair Information Management System

[
] 2007 E.C
Acronomy
AA………………………………………..Academic Affair
UI……………………………………………User Interface
KIOT ………..…………………………….Kombolcha Institute Of Technology
INFO………………………………………Information
CRC………………….……………………Class Responsibility and Collaboration
SD…………………………………………Sequence Diagram
SRS…………………………………………System Requirement Specification
UC………………………………………….Use Case

[
] 2007 E.C
Content
s
AKNOWLEDGEMENT....................................................................................................................................ii
Abstract......................................................................................................................................................iii
Acronomy...................................................................................................................................................iv
Chapter one.................................................................................................................................................1
Proposal.......................................................................................................................................................1
1. Introduction.............................................................................................................................................1
1.1 Background/ Overview of the Organization......................................................................................1
Initiation of the project................................................................................................................................2
1.2 .Statement of the problem..................................................................................................................2
1.3. Project objectives..............................................................................................................................2
1.3.1. General objective.......................................................................................................................2
1.3.2. Specific objectives......................................................................................................................3
1.4. Scope and limitation of the project...................................................................................................3
1.4.1. Scope of the project...................................................................................................................3
1.4.2 Limitation of the project............................................................................................................3
1.5. Methodology....................................................................................................................................4
1.5.1 Data collection methods............................................................................................................4
1.5.2 Methodology for the system design and development..............................................................4
1.6. Tools for System development/implementation................................................................................5
1.7. Significance of the study..................................................................................................................6
1.8. Feasibility Study...............................................................................................................................6
1.8.1 Operational Feasibility...............................................................................................................6
1.8.2 Technical Feasibility...................................................................................................................6
18.3 Schedule Feasibility.....................................................................................................................6
1.8.4 Economic Feasibility...................................................................................................................7
1.9. Budget..............................................................................................................................................8
1.11. Communication plan.......................................................................................................................9

[
] 2007 E.C
1.12. Project Schedule (PERT)................................................................................................................9

1.13 Organization of the project..............................................................................................................9
CHAPTER TWO.......................................................................................................................................10
Analysis of the System..............................................................................................................................10
2.1 Introduction.........................................................................................................................................10
2.2. Why we describe the existing system.........................................................................................10
2.2.1. Description of the Existing system..............................................................................................10
2.2.2. Hierarchical structure of the existing system.........................................................................11
2.2.3. Problem of the existing system..............................................................................................11
2.2.4 .Alternative options to address the problems of existing system...........................................12
2.2.6. Advantage of the new system................................................................................................13
2.3. Requirements Definition.................................................................................................................13
2.3.1. Functional requirement...........................................................................................................13
2.3.2. Non-functional requirements.................................................................................................14
2.4. Business rules.................................................................................................................................15
2.5 Constraints.......................................................................................................................................15
The following are some of the constraints of our project:......................................................................15
2.6 Identifying the actors in the new system..........................................................................................15
2.7. Identifying the use case in the new system.....................................................................................16
2.8 Essential use case diagram...............................................................................................................16
2.8.1. Essential use case description.................................................................................................17
2.9 Domain modeling using CRC..........................................................................................................23
2.10. System Requirement Specifications (SRS)...................................................................................25
2.10.1 System Use case Diagram......................................................................................................25
2.10.2 Use case documentation........................................................................................................27
2.13. Conceptual class diagram.............................................................................................................52
2.14. User interface prototype................................................................................................................53
Chapter Three............................................................................................................................................54
System Design...........................................................................................................................................54
3.1. Introduction........................................................................................................................................54
3.2. Class Modeling...............................................................................................................................54

[
] 2007 E.C
3.3 Proposed software architecture......................................................................................................55

3.3.1. Class Type Architecture...........................................................................................................55
3.3.2. Deployment modeling............................................................................................................57
3.3.3. Component Modeling.............................................................................................................58
3.3.4 Persistence diagram.................................................................................................................59
3.3.5. State chart modeling................................................................................................................62
3.4. Access control and security..............................................................................................................65
3.5. USER INTERFACE DESIGN........................................................................................................66
Implementation and Testi..........................................................................................................................70
4.1 System Implementation...................................................................................................................70
4.1.1 Coding.......................................................................................................................................70
4.2 Testing.............................................................................................................................................79
4.2.1 Unit Testing..............................................................................................................................79
5.2.2. Integration testing..................................................................................................................80
2.2.3. Acceptance Testing.................................................................................................................81
4.2.2 System Testing.........................................................................................................................81
4.3 User manual preparation..................................................................................................................82
Chapter five...............................................................................................................................................82
4.4 .Conclusion and Recommendation..................................................................................................82
4.4.1 Conclusion................................................................................................................................82
4.4.2 Recommendation.....................................................................................................................83

[
] 2007 E.C
LIST OF TABLE page

Table1.1 for cost of project
Table 1.2.task breakdown
Table 1.3 time schedule
Table 2.1 Add new agenda/information
Table 2.2 search agenda/information
Table2.3 updates agenda/information
Table 2.4manege account
Table 2.5 generate report
Table 2.6 post info
Table 2.7 view posted info
Table 2.8 CRC for Chairperson
Table 2.9 CRC for Agenda
Table 2.10 CRC for create account
Table 2.11 CRC for Chair person and AA member
Table 2.14 Login
Table 2.15.Add new agenda/information
Table 2.17. For manage account
Table2.18 Update the agenda
Table 2.19 Generate report
Table 2.20.View Posted agenda

[
] 2007 E.C
Table 2.21 approve decision

Table 2.22. For Post agenda
Table 2.23 For Delete agenda
List of figure page

Figure 1 Structure of the existing system..............................................................................................................11
Figure 2 Essential use case diagrams.................................................................................................................17
Figure 4 System use case diagram.......................................................................................................................26
Figure 5 Sequence diagram for login....................................................................................................................35
Figure 6 Sequence diagram for insert...................................................................................................................36
Figure 7 Sequence diagram for update.................................................................................................................37
Figure 8 sequence diagram for search..................................................................................................................38
Figure 9 sequence diagram for delete agenda.....................................................................................................39
Figure 10 sequence diagram for generate report...............................................................................................40
Figure 11 sequence diagram for create user account...........................................................................................41
Figure 12 sequence diagram for view posted info................................................................................................42
Figure 13 sequence diagram for post information...............................................................................................43
Figure 14 Activity diagram for Login.....................................................................................................................44
Figure 15 Activity diagram for insert agenda.......................................................................................................45
Figure 16 Activity diagram for delete posted agenda...........................................................................................46
Figure 17 Activity diagram for update agenda.....................................................................................................47
Figure 18 Activity diagram for create account......................................................................................................48
Figure 19 Activity diagram for generate report....................................................................................................49
Figure 20 Activity diagram for search agenda/ information.................................................................................50
Figure 21 Conceptual Class diagram....................................................................................................................52
Figure 22 User interface prototype of system.....................................................................................................53
Figure 23 class diagram........................................................................................................................................55
Figure 24 Class type Architecture.........................................................................................................................56
Figure 25 deployment modeling.........................................................................................................................57
Figure 26 Component modeling...........................................................................................................................58
Figure 27 State chart diagram for login................................................................................................................63
Figure 28 state chart diagram for add/insert agenda..........................................................................................64
Figure 29 state chart diagrams for update...........................................................................................................65

Wollo University Kombolcha Institute of Technology college of
Informatics Department of Information System 2007 E.C
Chapter one
Proposal
1. Introduction
Information is very critical resource for any organization in order to achieve a certain
objective and it helps an organization to have a better condition and cooperation between them
and exchanging information each other in order to increase activities. This proposed system is
prepared for the project to design web based academic affairs information management system
of Wollo University, kombolcha institute of technology (KIOT) campus. The current system is
manual based and has different problems. So, our objective is to reduce these problems by
developing a database system. We believe that our new system will provide fast & modern
service for different users. For this, we will use different data collection methods and tools. The
AA information management system is focused on providing great services related to
information service.
1.1 Background/ Overview of the Organization

Wollo University is one of thirty three universities which were established by the Federal
Democratic Republic of Ethiopia .This university recognized in February 1999 E.C by higher
state authority and environmental society. It has two campuses, namely Dessie campus (main
campus) and Kombolcha (sub campus). Kombolcha campus located in Amhara region south
Wollo, in the east direction from Kombolcha town. It has two colleges. These are Engineering
and Informatics College. Each college has many departments. In engineering college, there is
around 7 departments namely, civil, textile, mechanical, soil and water, chemical, electrical and
architecture. In informatics college have 3 departments those are; Information system,
Information technology and computer science. Under this campus there are different academic
affair staff (office) those are; deputy scientific, chief library, ICT, tutorial service, academic
program, registrar, research and community service ,quality assurance, academic commission
and department committee. At this time kombolcha institute of technology play great role in
WEB BASED ACADEMIC AFFIAR INFORMATION MANEGEMENT STSTEM FOR KIOT

[
] 2007 E.C
teaching and learning process. KIOT receipt around 6000 students and teaches in different
departments.
Initiation of the project

The main reason or initiation to develop Web Based Academic Affairs Information
Management System for KIOT is by observing the current system that performs its activity is in
a manual (paper based).so there is loss of document (data) easily, when someone will try to
access this data or information s/he cannot get easily as expected. And also this is time
consuming to get it, cost of paper, pen and paint. So our team members by considering such type
of problems we will initiated to develop web based academic affairs information management
system for KIOT.
1.2 .Statement of the problem

The overall activities of the Academic Affairs Information Management System in our
campus (KIOT) are derived from being doing their task manually. As a result, it decreases their
efficiency and availability of information. It is also time consuming. The existing system is not
functioning as expected due to various reasons. Some of the problems of the existing system are
listed below:
 Information distribution /access problem
 Loss of data due to improper data storing system
 Security problem
 Wastage of time and materials
Therefore, the proposed system will solve these problems.
1.3. Project objectives

1.3.1. General objective

[
] 2007 E.C
The general objective of this project is to develop Web Based Academic Affairs Information
Management System for KIOT.
1.3.2. Specific objectives
The specific objectives of the project are:
To Study the background of the organization

To secure data
To identify the problem of the existing system
To implement the system
To test the system
To develop user friendly interface
To save cost and time
To make it computerized to retrieve information easily
To develop database to store relevant information
1.4. Scope and limitation of the project

1.4.1. Scope of the project
This project mainly focuses on identifying the main problems of Academic Affairs information
management system in kombolcha Institute of technology (KIOT) and designing an alternative
system to provide a solution for the problems. It supports only academic affairs related activities
such as:-
 Inserting agenda/information in the database
 Posting agenda/information
 Searching the existing agenda from the database
 Updating or modifying the existing data from the database
 Deleting agenda/information from the database
 Viewing and accesses information
 Generating reports.
But our system doesn’t include:-
 Online meeting

[
] 2007 E.C
1.4.2 Limitation of the project

There are different problems or obstacles faced which affects the properly developing of the
project. Some of these are:-
 Shortage of time: We are students and in learning process we have
shortage of time to complete the project in two semesters. This enforces our project team
to minimize the project scope.
 Insufficient information about the existing system because there is no
central office to give such full information
 Termination of electric power and network connection
1.5. Methodology
In order to gather relevant information which is used to develop our project we use different data
collection methods.
1.5.1 Data collection methods
Interview: - we gathered relevant information about the background of the academic

affairs for KIOT, their work activities and the functions of the existing system. We will conduct
interview to know how does the existing system function, when did it was established. This
interview will be conducted to the dean of the college and the department head.
Document analysis: - we also collected certain relevant information from written

documents in the office. Forms and documents which are the existing system currently uses, we
will be revised to know rules, regulation and constraints in the existing system that can be used
to design the new system.
We will also see the legislation of Wollo University.
 To find the organizational structure of the AA.
 To understand the current forms used by the institute.
1.5.2 Methodology for the system design and development
In this project the team will prefer OOSAD (Object Oriented System Analysis and Design)
methodology to develop our system. This is because an OOSAD provides the following
advantages:

[
] 2007 E.C
 Promotes better understanding of user requirements.

 Leads to clear design by using use case, activity diagrams and sequence diagrams.
 Allows to breakdown complicated systems into smaller, clearly defined and more
manageable parts.
 Easy maintenance.
 Enables the standardization of objects which increases design understanding and
decreases the risk associated with project development
1.6. Tools for System development/implementation

Hardware and software tools required for successful completion of the projects are listed below
with their respective significances
Hardware tools required are:-
 Personal computer (PC):- almost all tasks of our project are performed on computer
 Flash Drive: required for data movement
 Disks (CD, DVD):-necessary for the movement of relevant data and for backup and
recovery mechanism.
 Internet Connection: - since our system is web based, it is very necessary requirement.
It also helps us to extract relevant information about our project from internet
 Stationeries (pen, paper):- for writing all necessary documentations associated with the
project
 Note book: - to take notes during data collection and for other documentations
 Printer: to print documentations
Software tools required are:-
 Wampserver:-to test the system by running.

 MySQL(database ), for creating and manipulating databases
 PHP (Hypertext Preprocessor) to design user interface from the front end of
software.
 Microsoft office 2007 and Notepad++:- to write on any necessary documents
about the project

[
] 2007 E.C
 Adobe Photoshop: -to edit images

 Microsoft Visio and Edraw max: - used to draw UML diagrams
 Interface language:- English
 Java script: - used for validation purpose.
1.7. Significance of the study

The new web based AA information management system is highly reliable, easy, fast and
consistent and will play a crucial role for reliable service for the office, students, and academic
staff and for the management. The significance of the system includes:
 Minimize time and efforts needed to perform tasks
 Make tasks simple and efficient in every aspect
 Avoiding data loss because of improper data storage
 satisfy academic staff according to rules and regulation of the
campus
 Provide information and services to academic staff properly
 Reduce the wastage of resources
1.8. Feasibility Study

Feasibility study is an essential phase in software development process to evaluate the
cost and benefits of the new system. On the basis of the feasibility study decision is taken on
whether to proceed or to cancel the project.
1.8.1 Operational Feasibility
Operational feasibility is a measure of how well the solution will work in an organization.
The new system will provide efficient insertion, searching of information, easy updating, and
modification etc. This increases the efficiency of work in the office. So that we can say the
system is operationally feasible.
1.8.2 Technical Feasibility
The system to be developed by using familiar programming language such as PHP, Java
script, css and Mysql database without any problems and the group members have enough
capability to develop this project. So our project will be technically feasible.

[
] 2007 E.C
18.3 Schedule Feasibility
Schedule feasibility is making sure whether the potential time frames and Completion
date can met or not .The project team members expected the Project to be completed on time
without any delay.
1.8.4 Economic Feasibility
To identify the economic feasibility of the project the team has done cost-benefit analysis
which enable to specify the benefits and costs associated with the project. The following work
sheets specify the costs as well as benefits of the project.
 Tangible benefits: The team calculated the corresponding tangible benefits based
on the technique called the Time Value of Money (TVM).
1. Cost Reduction and Avoidance: - To calculate the following things will be considered.
 Total Number of workers in AA offices of the existing system= 15

 Average Salary of each workers per month = 1500.00Birr
 Total money required for payment per year= 15*1500*12= 270,000.000Birr
 Total stationary materials like( pen ,print and paper ) expense daily in the existing
system =150 birr
 Average monthly expense= 30*150=4500.00birr
 Total stationary expense for year=4500*12=54000.00birr
 Total cost = Total stationary expense per year + Total money required for payment per
year=270,000.000Birr+54000.00birr=324,000.00birr
 Average Number of workers needed when the new system is deployed= 8
 Average salary of each of them per month = 1800.00Birr
 Total money required for payment per year= 8*1800*12= 172,800.00Birr
 And total stationary expense per year in the new system= 15000.00birr
 Total cost required per year in the new system=172,800 + 15000=187,800.00birr
 Difference b/n before and after deployment money required for expense
 Cost Reduction and Avoidance= 324,000.00birr -187,800.00Birr= 136200.00Birr
Net Profit == 136200.00Birr

[
] 2007 E.C
Intangible benefit:
 Error reduction
 Increase security
 Increase efficiency
 Provides more timely information
1.9. Budget
The following table lists budget required for the successful development of the proposed system
Table1.1 for cost of project

Types of costs Tool name Quantity Unit price (in Total price (in
Birr) Birr)
Hardwar cost Flash(8GB) 2 180 360
CD ROM 2 7 14
DVD 2 18 36
Wamp server 1 Free Free
Microsoft office 2007 1 Free Free
Software costs Notepad++ 1 Free Free
Microsoft Visio 1 Free Free
Adobe Photoshop 1 Free Free
Windows 7 OS 1 Free Free
Other costs Miscellaneous cost - - 500
Total cost - - - 910
1.10. Task breakdown and deliverables

The project team is composed of 4 members. Each member will participate in each activity. This
are listed below in the table.

[
] 2007 E.C
Table 1.2.task breakdown

ID Tasks Responsibility
1 Data Gathering And Project Proposal Kefale and wubie
2 Data Gathering And System Analysis Wubishet and ayalew

3 System & Object Design Wubie and wubshet
4 Implementation And Testing All members
1.11. Communication plan

The group member meets 3 times in a week in order to do or discus about the project on
Saturday, Friday and Additionally on Sunday. The group members also contact with our advisor
on Monday morning.
1.12. Project Schedule (PERT)

Team members will produce the progress, report and other activities of the project development
based on the schedule as shown below
Table 1.3 time schedule

[
] 2007 E.C
1.13 Organization of the project

This project documentation is organized into five chapters. The first chapter project
proposal The second chapter requirement phase The third chapter covers about system and object
design The fourth chapter deals with implementation and testing. The fifth chapter encompasses
the conclusion and recommendation for future studies.
CHAPTER TWO
Analysis of the System
2.1 Introduction
In this chapter we will analyze a web based academic affairs information management
system for wollo University, Kombolcha Institute of Technology (KIOT) campus. And also we
overview the proposed system, it’s functional and non-functional requirement, business rules and
constraints actors of the system will be discussed. Also we cover the major activities such as
constructing a use case model, documenting the use case course of events, constructing CRC
diagrams, sequence and activity diagrams, class diagrams and user interface prototype about the
proposed system.
2.2. Why we describe the existing system
The main reason for describing the existing system is:-
 To know the back ground of the existing system of academic affair.

 To identify the problem of the existing system.
 To understand the current structure of the existing system
 To identify which of these problems could be solved by the current project.
 To know the statement of the problem, challenges of the system and to come up
with the solution.
2.2.1. Description of the Existing system

The existing academic Affairs information management system refers to the manual
system that is available currently. In this case we deeply describe the existing system in order to

[
] 2007 E.C
have a better understanding and a massive knowledge about the existing system and we will have
the concept of why describing the existing system, hierarchical structure, problems of existing
system, alternative solutions and the proposed system.
In this part we will identify all the activities or tasks performed in academic affairs
regarding to member’s data information management, the activities that are performed in
Academic Affairs are:
 Recording new agenda/data in manual or paper based

 Managing all activity related to academic affairs
 Distribution of material in each concerned staff
 Exchange of information to Registrar, DC, Quality assurance, research and
community office, chief liberty, tutorial service, and other related office which
is on academicals issues.
2.2.2. Hierarchical structure of the existing system

[
] 2007 E.C
Deputy scientific director of academic

affair
DIR ,chief DIR ,Research and

DIR ,ICT DIR ,Tituorial Service DIR ,Quality assurance
library community
DIR ,continuity and Academic Commission DIR ,Academic

DIR ,Registeral
distance education (AC) program
Department committe
(DC)
Figure 1 Structure of the existing system

2.2.3. Problem of the existing system
The existing AA information management system currently is functioning using manual system
so that, the system carried out has the following problems.
 The system records data manually

 The data may be expired after a long time because it’s simply put in hardcopy
 Searching and getting available information for the user is difficult, takes time
and it is boring
 Loss of data due to improper data storing mechanism

 Lack of data security
2.2.4 .Alternative options to address the problems of existing system

[
] 2007 E.C
After the team has identified the real problem of the existing system which is a manual system,
the team suggests an alternative option to overcome the problem.
These alternative options are:-
 Changing the manual system into desktop application.
 Changing the manual system into a computer system that works on web based
environment.
The team has analyzed all of the alternative options based on the ability of performance,
information flow, and service to the user’s efficiency. This analysis has enforced to select the
web based system.
2.2.5 .Overview of the proposed system
Our web based AA information management system that is to be developed is to
minimize the problem of current system which is described in the problem statement. The system
should be effective at the time of registration/insertion/, update, access, search and generate
report. The proposed Academic Affair information management system that attempts to replace
the manual system has the following functions.
 The system can record new information within the database
 The system can generate report daily from members decisional table
 The system can enable to search agenda/information with the agenda`s unique ID
or agenda name that is available on the database.
 It shortness step by step processes during registering/insertion, searching, delete,

update and post data/agenda.
 The system has high database security. Since it cannot be accessed by

unauthorized user .But, each member in the AA information management system
has its own privilege to do any operation on the database.
2.2.6. Advantage of the new system
2.6.1. Advantages of the new system are:

[
] 2007 E.C
 Performance: provides fast response because it is easy to access data from the stored
document.
 Service: the system can provide services for users or can get fast service
 Economy: when we apply web based AA information management System there will be
reduce the cost different material like paper, pen and time
 Efficiency: the web based system by itself is short, clear and there is no duplication of
data also the ability responds quickly
2.3. Requirements Definition

The proposed system has the following requirement:-
Functional
Non functional
2.3.1. Functional requirement
The Functional requirement is concerned with actual performance of the system that is
going to be developed and describe what the system should do. Also it describes the functionality
or service provided by the new system:
The new proposed system is aimed to solve the problems in current system by creating web
based system that helps the academic affair to manage information. The system able to:-
 Authorization and Authentication: To identify the authorized person to use the

system
 Record new data: Our proposed system can register or records basic information
in the database. This helps users to access information easily and to store their
data and documents permanently
 Update information: Authorized users of the system can modify or change
agenda information whenever possible.
 Search for existing data from database: This enables the users of the system to
find available information from database which is previously registered or
recorded. The responsible person should search for that specific information. This
is done easily by agenda name or agenda identification number.

[
] 2007 E.C
 Viewing and accessing information: The system display or show the stored
basic information. And users can view and access that information.
 Create account: The chairperson can create user accounts.
 Delete recorded information: a person who is responsible to delete recorded
information from the database.
 Generate report: The system will generate daily or weekly as well as yearly
report.
2.3.2. Non-functional requirements

Non functional requirements are requirements that are not directly related to the
functional aspects of the system and it essentially specifies how the system should behave and
that it is a constraint upon the systems behavior besides the functional requirements, our system
possesses non-functional requirements that reflect the quality of the system.
Some of the non- functional requirements are:-
 Performance: The response time that the system uses to process and retrieve data
from the database is very short. That means it takes Short response time for a
given piece of work.
 Security: The system should be secured. Access is denied from unauthorized
users of the system.
 Integrity: Only authorized users of the system (chairperson, AA member or
other) can able to update, modify, or delete data.
 Availability: The data in the system will be available all the time.
 Reliability: The system should able to perform a required function under stated
conditions for a specified period of time.
2.4. Business rules

Business rules are statements about the organization’s way of doing business. They
reflect business policies. Organizations have policies in order to satisfy the business objective,
satisfy customers, and make good use of resources, and conform to laws or general business
conversions.

[
] 2007 E.C
Basic business rule of the academic affairs are:-

 BR1 students and teachers have no power to post new agenda rather than view
posted data
 BR2 each member must be signed their signature during the appointment
 BR3 the academic affair division shall be headed by deputy scientific director.
 BR4 each members of AA submit new agenda to the chairperson for approval.
 BR5a person that use the system she /he must be members of the organization.
2.5 Constraints
A constraint is restriction that imposes the activity done on the system.
The following are some of the constraints of our project:

 Lack of financial support from project stakeholders or from the department.
 We didn’t get central office or person to collect relevant data for the project.
 Lack of reference materials
 The system needs technical persons to use it.
2.6 Identifying the actors in the new system

 Chair person
 AA member
 Teacher
 Student
 AA Chair person: is a person who controls all activities
Main activities include:-

 Manage/control user accounts
 View posted information
 Update information/agenda from the database
 Delete information/agenda and
 Approve information/agenda
 Insert/post information

[
] 2007 E.C
 AA member:
 Search information
 View posted information
 Post agenda/info
 Generate report
 Student
 Student view posted agenda /information
 Teacher
 Teacher view posted agenda/ information
2.7. Identifying the use case in the new system

 Insert agenda
 Update agenda
 Manage account
 Generate report
 Search agenda
 Post info
 View posted info.
2.8 Essential use case diagram

Essential use case modeling is a simplified abstract, generalized use case that captures the
intentions of the user in a technology and implementation independent manner. It identifies use
case and actors of the proposed system.

[
] 2007 E.C
Figure 2 Essential use case diagrams
2.8.1. Essential use case description
Table 2.1 Add new agenda/information

Use case name: add /insert agenda
Use case number: UC1
Description: -Allows the Chairperson to register new information to the system with detail
descriptions about the information
Actor: Chairperson and AA member

[
] 2007 E.C
Pre-Condition: user wants to insert new agenda/information.

Post condition: The information is inserted to the system successfully
Basic course of Action
1. they want to add a new agenda
2. They requests add new information form page.
3. The system displays a form to be filled out for agenda/information registration
4. Enters information/agenda in the form
5. The system verifies that the fields have been filled out correctly
6. Click or press on the save or insert button.
7. The system displays a successfully stored message to database
8. Use case ends
Alternative course of action
If all fields are not filled out the system goes back or returns to step4 of basic course of Action.
Table 2.2 search agenda/information

Use case name: search agenda
Description: Chairperson and AA member find information by agenda/information types from
the system to know its status or display case types
Actor: Chairperson and AA member
Pre-Condition: --They agenda/info must be register in the database
Post condition: The required information will be successfully searched.

[
] 2007 E.C
.Basic course of Action

1. The Chairperson, AA member and click on search link.
2. The system displays list box to select search to agenda/information types.
3. They select agenda/information type from list box.
4. Clicks on search button.
5. Then the system displays all information.
6. Use case End.
If any lists are not selected from the list box system returns to step 3 to select.
Table2.3 updates account

Use case name: update account
Description: Chairperson to update or modify account
Actor: Chairperson
Pre-Condition: -- Chairperson wants to update account
Post condition: Account replaced/modified by new account successfully.

[
] 2007 E.C
1. The Chairperson wants to update account.

2. Search account by Email.
3. The system will display all information
4. They enters update account of new account
5. They click on update button.
6. The system successfully updates account in to database.
7. Use case Ends.
If the account is not updated, return back to step4 and fill correctly
Table 2.4 create account

Use case name: create account
Description: Used to create account for users
Actor: chair person
Pre-Condition: Chair person want to create account.
Post condition: The user account successfully created.
1. He wants to create account.
2. The system displays create account page.
3. The actor fills the required information and submits it.
4. The system validates the information.
5. The system registers and creates new account
If Invalid information entry. The system displays error message Go to step 2 to fill again..
Table 2.5 generate report

Use case name: generate report
Description: The process of Generate report

[
] 2007 E.C
Actor: members
Pre-Condition The members approve and organize the information that is available to users.
Post condition: The report will be generated
1. A members clicks on generate report button.
2. System display report form to be filled.
3. Users fill all relevant info, validate and click on submit button.
4. The system produces the report.
If a member not approves/organizes the information, report will not be generated.
Table 2.6 post info

Use case name: post info
Description: The chairperson used to post the information
Actor: Chairperson and AA member.
Pre-Condition: The agenda must be approved.
Post condition: The information is posted.
1. The chairperson or AA member wants to post info.
2. The system displays post agenda/info page.
3. The chairperson writes and submits the agenda.
4. The system validates the information
5. The agenda/info is posted
6. The use case ends
If the submitted information is not valid, the system displays error message.
Go to Step3 to submit the information again

[
] 2007 E.C
Table 2.7 view posted info

Use case name: view posted info
Description: It allows users to view posted information that is approved by chairperson
Actor: Chairperson, AA member, Student and Teacher
Pre-Condition: The agenda/info should be approved by the chairperson
Post condition: Users can view posted agenda or information.
1. User clicks the View link.
2. The user selects the information to be viewed
3. .The system loads the information from the data base with detailed description
4. The use case ends.
2.9 Domain modeling using CRC

A Class Responsibility Collaborator (CRC) model is a collection of standard index Cards
that have been divided into three sections; this is class name, responsibility and collaborator. A
class represents a collection of similar objects, a responsibility is something that a class knows
or does, and a collaborator is another class that a class interacts with to fulfill its
responsibilities. Those can be shown in the following table
Class name
Responsibility Collaborator
Table 2.8 CRC for Chairperson

Chairperson
Delete agenda Agenda

[
] 2007 E.C
Post agenda
Update agenda
Table 2.9 CRC for Agenda

Agenda/information
agenda code Chairperson
agenda date AA member
agenda type
agenda
description
Table 2.10 CRC for create account

account
Create() Chair person
Update()
Table 2.11 CRC AA member

Member
Id number agenda
First name
Middle Name
Last Name
Sex
Age

[
] 2007 E.C
address
Position
Email
Insert () view()
2.10. System Requirement Specifications (SRS)

2.10.1 System Use case Diagram
Use Case represents interaction between the user and the system.
Has the following actor and use case.
Actor:-
 Chair person
 AA member
 Teacher
 Student
Use case:-
 Insert agenda
 Login
 Update agenda
 Delete posted agenda
 Manage account
 Generate report
 post information

[
] 2007 E.C
 Search agenda
 View posted agenda/information

[
] 2007 E.C
Figure 3 System use case diagram

[
] 2007 E.C
2.10.2 Use case documentation
Table 2.14 Login

Use case name Login
Use case number UC01
description It allows authenticated users login into the system and can access.
Actor Chairperson and AA Member

Pre-condition Chairperson and AA Member must have user name and
password.
Post condition Users will login in to the system
Basic course of action Actor action System action

Step1: The user fills user Step2: The system validate the
name and password User name and password
Step3:The system checks user

authenticated
Step4: The system displays the

appropriate home page Step5. The
use case ends
Alternate course of If there is empty user name and password, displays error message
action and re-enter user name and password.
Table 2.15.Add new agenda/information

Use case name add /insert
Description Chairperson to register new Agenda to the system with detail
descriptions about the agenda.
Actor Chairperson and members
Pre- condition login into the system
Post condition The agenda/information is inserted to the system successfully.

[
] 2007 E.C
step1. they wants to add new step2. They requests add new
agenda/information cases for form page.
step4. They enters information step3. The system displays a

in the form form to be filled out for agenda
Step5. They click or press on registration.
the save or insert button.
step6. The system verifies that
the fields have been filled out
correctly.
Step7. The system displays a

successfully stored message to
database
step8. Use case ends
Alternate course of If all fields are not filled out the system goes back or returns to
action step4 of basic course of Action. To fill the empty field.
Table 2.16. Search the agenda

Use case name Search
Description It enables users to search for a particular agenda/ information
from the data base.
Actor Chairperson ,AA member
Pre-condition The data/info must be registered in the database.
Post condition The required data/info will be searched or displayed

[
] 2007 E.C
step1. Users click on search Step2.The system displays

link. search form
step3. Users select they want to Step5 Then the system display
search. all information
step4. Clicks on search button. step6. Use case End
Alternate course of If the agenda being searched is not in the database the
action system will display message like “the data is not found, please
try again select the correct information” and direct to step3.
Table 2.17. For manage account

Use case name manage account
Description Used to create account for users.
Pre-condition -
Post condition The user account successfully created.
Actor chair person
Basic Course of Actor action System action

action step1: .users wants to create
step2: The system displays
account.
create account page
Step3: The users fill the
required information and submit Step4: The system validates the
it. information.
step5 :The system registers and
creates new account

[
] 2007 E.C
step6: The use case ends.
Alternative If Invalid information entry, The system displays error

course of action message. Go to step 2 to fill again.
Table2.18 Update the agenda

Use case name Update
Description It allows the chairperson to update or modify account from the data
base
Actor Chairperson
Pre-condition Detail information about the agenda must be recorded in the database
Post-condition Agenda is updated or modified successfully.
Basic course of Actor action System action
action step3. The system will display
step1. The Chairperson wants to update
all information
agenda.
step6. The system
step2. Search agenda by successfully updates
agenda type or agenda name. information in to database.
step4 the chair person enters
update information of new agenda
step5. Chair person click on update

button.
step7. Use case Ends.

Alternate course of If the agenda is not correctly insert to the form return back and fill
action correctly

[
] 2007 E.C
Table 2.19 Generate report

Use case name Generate report
description The member used to generate report about the tasks
performed on the system
Actor member
Pre-condition The report to be generated should be available in the database
Post condition The report is generated

Step1. Member clicks on produce
Step2. System display
report button.
report form to be filled.
Step3.Users fill all relevant info,
validate and click on submit button. Step4. The system
produces the report
.
Step5.usecase ends.
Alternate course of action If agenda is not available in the database, report will not be
generated.
Table 2.20.View Posted agenda

Use case name View Posted agenda
description It allows users to view posted information that are approved by
chairperson
Actor Chairperson, AA member ,Student and Teacher

Pre-condition The agenda/info should be approved by the chairperson
Post condition Users can view posted agenda or information.

[
] 2007 E.C

action Step3.The system displays
Step1.the User wants to view posted
view posted info page
info.
Step2.The user selects the information

to be viewed
Step4.the posted info is viewed
Step5.The use case ends.
Alternative course If Chairperson not approves the info, users can not view posted
of action agenda/info.
Table 2.22. For Post agenda

Use case name Post agenda/information
Description The chairperson used to post the information.
Actor Chairperson and Members
Precondition The agenda must be approved
Post condition The information is added to the server and posted.

[
] 2007 E.C

action: Step1The chairperson and members Step2.The system displays
wants to post agenda. post agenda page.
Step3.The chairperson and members Step4.The system validates

writes and submits the agenda. the information.
Step5.The agenda is
posted.
Step6. The use case ends
Alternative course If the submitted information is not valid, The system displays error
of action: message.
Go toStep2 to submit the information again.
Table 2.23 For Delete agenda

Use case name Delete agenda/information

Description It allows chairperson to delete the agenda
Actor/s chairperson
Precondition The agenda must be Posted or inserted in the database.
Post condition The agenda is deleted from the database.
action: Step1.The chairperson wants to Step2.The system displays the
delete agenda. delete agenda page.
Step3.The chairperson press delete Step4.The system validates the

button. selected information.
.

[
] 2007 E.C
Step5.The system deleted the

agenda from the database..
Step6. The use case ends
Alternative If the selected agenda is not available, The system displays error
course of action: message, Go to step2 to select the agenda again.
2.11. Sequence Diagram (SD)

A sequence diagram shows an interaction arranged in time sequence. In particular, it shows the
instances participating in the interaction by their “lifelines” and the stimuli that they arranged in
time sequence. It does not show the associations among the objects

[
] 2007 E.C
Figure 4 Sequence diagram for login

[
] 2007 E.C
Figure 5 Sequence diagram for insert

[
] 2007 E.C
Figure 6 Sequence diagram for update

[
] 2007 E.C
Figure 7 sequence diagram for search

[
] 2007 E.C
Figure 8 sequence diagram for delete agenda

[
] 2007 E.C
Figure 9 sequence diagram for generate report

[
] 2007 E.C
Figure 10 sequence diagram for create user account

[
] 2007 E.C
Figure 11 sequence diagram for view posted info

[
] 2007 E.C
Figure 12 sequence diagram for post information
2.12. Activity Diagram

Activity diagram is similar to a flowchart to represent the flow from one activity to another
activity. Activity diagram focuses on the flow of activities involved in a single process. The
Activity diagram shows how these single-process activities depend on one another.

[
] 2007 E.C
login
Enter username and password
check username and password
if not valid valid
logged into the system
Figure 13 Activity diagram for Login

[
] 2007 E.C
click on add agenda button
enter agenda info
name,agenda type
invalid valid
adding success
Figure 14 Activity diagram for insert agenda

[
] 2007 E.C
select info to be deleted
fill info to be deleted
press delete button
invalid display error

message
valid
info deleted
Figure 15 Activity diagram for delete posted agenda

[
] 2007 E.C
click update button
fill information to update
click update
invalid
incorrect input
valid
is updated
Figure 16 Activity diagram for update agenda

[
] 2007 E.C
select create account link
create account page display
fill the information and submit it
display error invalid

message
valid
account is created
successfully
Figure 17 Activity diagram for create account

[
] 2007 E.C
click on generate report
fill information to generate
click on search to generate
invalid display error

message
valid
report is
generated
Figure 18 Activity diagram for generate report

[
] 2007 E.C
click on search
enter agenda
type/information
check agenda value
invalid agenda valid agenda

type/information
type/info
display information
Figure 19 Activity diagram for search agenda/ information

[
] 2007 E.C
User interface prototype
User interface prototype for login form
Account Type
User Email
Password
login
User interface prototype for agenda insertion form
Insert Cancle
PersonId
Agenda name
Agenda code
Agenda type
Agenda description
Registration date

[
] 2007 E.C
2.13. Conceptual class diagram

Class diagrams in the Unified Modeling Language (UML) is a type of static structure
diagram that describes the structure of a system by showing the system's classes, their attributes,
operations (or methods), and the relationships among the classes. The class diagram with its
corresponding objects will be present in the following diagram.

[
] 2007 E.C
AA member
Chair person Idnumber
username create * Fname
password 1 Mname
Lname
Agenda
Address
PersonID Age
manage account() 1 Sex
AgendaCode
insert() Position
AgendaName post
update() Email
1 register AgendaType
delete() 1
1 Description
postagenda()
Date login()
viewpostedagenda()
vew pos.info()
getvalue() * search ()
setvalue post()
declare()
*
view
1 view 1
Teacher
Student
Idnumber
Fname
Mname Idnumber
Lname Fname
Address Mname
Age Lname
Sex Address
Email Age
Sex
Departmen
veiw posted agenda() Email
veiwpostedagenda()
Figure 20 Conceptual Class diagram
2.14. User interface prototype

User interface prototyping is an iterative development technique in which users are actively
involved in the making-up of the UI for a system.

[
] 2007 E.C
Home page
Home About us Contact us View info Feedback
Chair_person AAmember
Student
Teacher
Login
Login
view posted
insert info view posted info
info
post info
update info
view posted
info
delete posted
agenda
search info
manage
account
generate report
view posted
info
approve
decision
post info
Figure 21 User interface prototype of system

[
] 2007 E.C
Chapter Three
System Design
3.1. Introduction
The purpose of design is to determine how the system is going to be built and to obtain
information needed to drive the actual implementation of the system. It focuses on understanding
the model how the software will be built.
This chapter mainly focuses on the design part of Academic Affairs Information Management
System for KIOT. In order to make the implementation of the system the design is very
important.
In this chapter we will see different type of class type architecture such as user interface layer,
process/control layer, business/domain layer, persistence layer, system layer and different types
of system modeling techniques that are used for the implementation of the system such as class
modeling, state chart modeling and system design techniques such as user interface design for
our system are included.
Generally this chapter describes how the project is designed, what tasks are done under this
project.
3.2. Class Modeling

Class diagrams in the Unified Modeling Language (UML) is a type of static structure diagram that
describes the structure of a system by showing the system's classes, their attributes, operations (or
methods), and the relationships among the classes. The class diagram with its corresponding objects will
be present in the following diagram

[
] 2007 E.C
AA member
Chair person -Idnumber:string
create * -Fname:string
-username:string -Mname:string
1
-password:string -Lname:string
Agenda
-Address:string
+manage account() -PersonId:string -Age:int
+insert() -AgendaCode:string 1 -Sex:string
+update() -AgendaName:string -Position:string
+delete() post
-AgendaType -Email:string
+postagenda() 1 register
-Description:string 1
+approveagenda() 1 -Date:int
+viewpostedagenda +login()
+getvalue() +vew posted.info()
()
* +setvalue +search ()
+approve() +post()
+declare()
* *
view view
1 Student
Teacher
-Idnumber:string
-Idnumber:string -Fname:string
-Fname:string 1 -Mname:string
-Mname:string -Lname:string
-Lname:string -Address:string
-Address:string -Age:int
-Age:int -Sex:sring
-Sex:string -Department:string
-Level:string -Email:string
-Email:string
+veiwpostedagenda()
+veiw posted agenda
()
Figure 22 class diagram
3.3 Proposed software architecture

3.3.1. Class Type Architecture
Class type architecture provides a strategy for layering the classes of the system to distribute the
functionality of the software among classes. Furthermore, class type architectures provide

[
] 2007 E.C
guidance as to what other types of classes will interact with, and how that interaction will occur.
This increases the extensibility, maintainability and portability of the system.
Interface: This layer wraps access to the logic of our system.
Class: user interface (UI) classes that provide people access to our system.
Domain: This layer implements the concepts pertinent to our business domain, focusing on the
data aspects of the business objects, plus behaviors specific to individual objects.
Process: The process layer implements business logic that involves collaborating with several
domain classes or even other process classes.
Persistence: Persistence layers encapsulate the capability to store, retrieve, and delete
objects/data permanently without revealing details of the underlying storage technology.
System: System classes provide operating-system-specific functionality for your applications,

isolating your software from the operating system (OS) by wrapping OS-specific increasing the
portability of your application.

[
] 2007 E.C
User interface class
process class
(Application controller)
System Class
(Infrastracture,plat
form)
Business class
(Domain)
Persistance class
(Data)
Data Source
Figure 23 Class type Architecture

.
3.3.2. Deployment modeling

Deployment modeling is used to show the hardware of the system, the software that is installed in the
hardware and also shows how the software and the hardware components work together.

[
] 2007 E.C
Customer Database
Web server Application server
computer
PHP insert
Web MYSQL
agenda
browser
AAIMS
manage DB
Wamp
account
search
agenda
Mozila
firefox
delete
agenda
post info
view
posted
info
generate
report
Figure 24 deployment modeling

3.3.3. Component Modeling
Component diagram shows how objects (classes) in your system will grouped together and form
components. The components interact with each other either in giving service to other
components or requesting service from other component.

[
] 2007 E.C
insert
agenda
manage
Chairperson account
security login
search
AA member agenda
persistance
delete
Teacher agenda
post info
Student
AAIMS
<<Database>>
view posted
info
generate
report
Figure 25 Component modeling

3.3.4 Persistence diagram
Persistent data of web based academic affairs information management system would be stored
in a Microsoft SQL Server Database Management System. The purpose of persistence modeling
is which objects in the system design are required to be stored persistently. Clearly, in a database
driven application like this one, almost all system interactions have deal with persistent data.
Information related to member, agenda, account and comment is persistent data, which should
be stored in the Database Management System. This allows the programs that operate on these

[
] 2007 E.C
data to do consistently. Moreover, storing data in a database enables the system to perform
complex queries on a large data set.
 Mapping
AAmember AAmember<<table>>
PersonId:string personId:varchar<<pk>>
Fname:string Fname:varchar
Mname:string Mname:varchar
Lname;string Lname:varchar
Address:string Address:varchar
Age:int Age:int
Sex:string Sex:varchar
Position:string Position:varchar
Email:string Email:varchar
Agenda<<table>>
Agenda
personId:varchar<<fk>>
personId:string
AgendaCode:varchar<<pk>>
AgendaCode:string
AgendaName:varchar
AgendaName:string
AgendaType;varchar
AgendaType;string
AgendaDescription:varchar
AgendaDescription:string
Registration_date:date
Registration_date:date
Comment
Name:string
Address:string
Email:string
Sex:string
Age:int
Comment:string Comment<<table>>
Name: varchar
Address:varchar
Email:varchar<<pk>>
Sex: varchar
Age:int
Comment:varchar

[
] 2007 E.C
Account Account<<table>>
FirstName : string FirstName :varchar(15)
MiddleName: string MiddleName:varchar(15)
LastName: string LastName:varchar(15)
AccountType: string AccountType:varchar(15)
Sex: string Sex:varchar(10)
Address: string Address:varchar(15)
Password: string Password:varchar(15)
ConfirmPassword: string ConfirmPassword:varchar(15)

Table and Attribute Format
Phonno: string Phonno:int(10)
1. Members table
Email: string Email:varchar(50)<<pk>>
Age:int Age:int(60)
Column Name Data Type and Size Index
Fname varchar(15)
Mname varchar(15)
Lname varchar(15)
Sex varchar(6)
Address varchar(15)

[
] 2007 E.C
Position varchar(15)
PersonId varchar(15) PRIMARY KEY
PhoneNo varchar(15)
Email varchar(50) FOREIN KEY
Age int(60)
2. Agenda table
PesonId varchar(15) FOREIGN KEY

AgendaCode varchar(15) PRIMARY KEY
AgendaName varchar(15)
AgendaType varchar(15)
AgendaDescription varchar(20000)
Registration_date Date
3. Comment table
Name varchar(12)
Address varchar(20)
Email varchar(23) PRIMARY KEY
Sex varchar(7)
Age int(90)
Comment varchar(20000)
4. account table
FirstName : varchar(15)
MiddleName:

[
] 2007 E.C
LastName
varchar(15)
AccountType
varchar(15)
Sex
varchar(6)
Address
varchar(15)
Password
varchar(15)
ConfirmPassword:
varchar(15)
Phonno:
varchar(15)
Email
varchar(50) PRIMARY KEY
Age:
int(60)
3.3.5. State chart modeling

The state chart diagram is shows the change of an object through time from one state to the other
state. State chart modeling is used to show the sequence of states that an object goes through the
events that cause the transition from one state to the other and the actions that result from a state
change. The following figure shows the state of the objects.

[
] 2007 E.C
Initial state
idle state
activate
login page
click
enter username &

password
press button
validate username &

password
login button turned on
invalid valid
logged into the

system
Final state
Figure 26 State chart diagram for login

[
] 2007 E.C
Initial state
idle state
activate
add agenda link
click
display add agenda page
click
add agenda info
press button
add agenda button

turned on
not added
display error
if
message
added
agenda inserted
Final state
Figure 27 state chart diagram for add/insert agenda

[
] 2007 E.C
Initial state
idle state
activate
update account
page
click
display account info
update
update account button

turned on
display error not updated

if
message
updated
update successfull
Final state
Figure 28 state chart diagrams for update
3.4. Access control and security

In our system, different actors have access to different functionality and data. Here is the list of
actors with their associated functionality.
The system uses Account Type, User Email and Password mechanisms to authenticate eligible
users in order to get the required services from the system.
The following table depicts an access matrix that associates actors with operations in some of
the sub system.
Actor class Operation/responsiblity
chairerson Agenda Insert,post, search,view
and delete
account Create, update
AAmember agenda Insert,post,search,generate
report and view info

[
] 2007 E.C
Teacher agenda Only view info

Student agenda Only view info
3.5. USER INTERFACE DESIGN

User interface design is the overall process of designing how a user will be able to interact with a
system. the goal of user interface design is to make the user's interaction as simple and efficient as
possible, in terms of accomplishing user goals.
User Interface design for home page

[
] 2007 E.C
User interface design for login

[
] 2007 E.C
User interface for members home page form

[
] 2007 E.C
User interface for chairperson home page

[
] 2007 E.C
Chapter four
Implementation and Testing
4.1 System Implementation

Implementation is the phase where objectives of physical operations of the system turned into
reality i.e. real working model. The crucial phase in the system development life cycle is the
successful implementation of the new system design. The process of converting as new system
into an operational one is known as system implementation. This includes all those activities that
take place to convert from an old system to a new system.
4.1.1 Coding
First phase of implementation is coding. Coding is the process whereby the physical design
specification created by the designers is turned in to working computer code by the programmer.
We used Hypertext Preprocessor (PHP) programming language.
The code is made simple in such a way that another programmer can easily understand and work
on that in the future.
4.1.1.1 Sample PHP code for login

<?php
session_start();
if (isset($_POST['submit'])){
$AccountType = $_POST['AccountType'];
$Password = $_POST['Password'];
$Email = $_POST['Email'];
$con = mysql_connect("localhost","root","");
if (!$con)

[
] 2007 E.C
die('Could not connect: ' . mysql_error());
mysql_select_db("agendadb", $con);
$query = "SELECT * FROM account WHERE AccountType = '{$AccountType}' AND

Password = '{$Password}' AND Email = '{$Email}' ;";
$result_set=mysql_query($query);
if(!$result_set){
die("query is failed".mysql_error());
if(mysql_num_rows($result_set)>0)
if($AccountType=="chairperson")
$_SESSION['validuser']=$AccountType;
echo "Welcome To chair person Page";
header("location:chair_per.php");
else if($AccountType=="AAmember")

[
] 2007 E.C
echo "Welcome To members Main Page";
header("location:AAmem.php");
else
echo "login is failed";
header("location:home.php");
if ($Email == '' || $Password == '' || $AccountType == '')
echo'Please check your useremail,password and Account Type';
else{
//header("location:login.html");
echo"<script language=\"javascript\" type=\"text/javascript\">alert(' please fill correct user

email and password')</script>";
include("index.php");

[
] 2007 E.C
?>
4.1.1.2 Sample PHP code create account

<?php
$con= mysql_connect("localhost", "root");
//check connection
if(!$con){
DIE('connection not created'.mysql_error());
//select database
mysql_select_db("agendadb",$con);
//insert form data from 'accountform' to "account" table in mysql
$sql="INSERT INTO
account(FirstName,MiddleName,LastName,AccountType,Sex,Address,Password,ConfirmPassw
ord,PhoneNo,Email,Age)
VALUES
('$_POST[FirstName]','$_POST[MiddleName]','$_POST[LastName]','$_POST[AccountType]','$
_POST[Sex]','$_POST[Address]','$_POST[Password]','$_POST[ConfirmPassword]','$_POST[P
honeNo]','$_POST[Email]','$_POST[Age]')";
// if successfully insert data into database, displays message "Successful"
if(!mysql_query($sql,$con))
die ("Error in creating account:".mysql_error());
else{
// display success message with table
echo "<html>";
echo "<head>";

[
] 2007 E.C
echo '<style type="text/css">';
echo "A:hover {color:blue; font-weight:bold;}"; /* style for active links – bold and red */
echo "</style>";
echo "</head>";
echo '<body background="capture.png" width="10%">';
echo '<table align="center" width="40%" heigth="800" border="0" >';
echo "<tr>";
//echo '<td colspan="3"> <img src="image/pharm2.PNG" alt="image/bed2.PNG"

width="100%" height="120"> </td>';
echo '</tr>';
echo '<tr bgcolor="lightblue" height="" >';
echo '<th colspan="3" valign="top">';
echo "<br>";
echo "<br>";
echo "Account created successfully.";
echo "<br>";
echo "<br>";
echo '</th>';
echo '</tr>';
echo '<tr bgcolor="#E4EBEB" >';
echo '<th colspan="3" valign="top">';
echo "<br>";
echo "<br>";
echo "<a href='Acount.php'> <STRONG>Privious pag</STRONG></a>";
echo "<br>";

[
] 2007 E.C
echo "<br>";
echo '</th>';
echo '</tr>';
echo '</table>';
echo '</body>';
echo '</html>';
//close connection
mysql_close($con);
?>
4.1.1.3 Sample PHP code for search data

<?php
if (!$con)
$searchword=$_POST['search'];
if($searchword!="" && $searchword!=0){
$result=mysql_query("SELECT * FROM agenda WHERE AgendaCode='$searchword'") or

die(mysql_error());
echo "<p><font size = '5' align='center'> Resuls</font></p>";
echo "<table align='center' border='1' bgcolor='white'>
<tr>

[
] 2007 E.C
<th>PersonId</th>
<th>AgendaCode</th>
<th>AgendaName</th>
<th>AgendaType</th>
<th>AgendaDescription</th>
<th>Registration_date</th>
</tr>";
if(mysql_num_rows($result) == 0) {
echo "<script> alert('No data found');
;</script>";
else {
while($row = mysql_fetch_array($result)){
echo "<tr>";
echo "<td>" . $row['PersonId'] . "</td>";
echo "<td>" . $row['AgendaCode'] . "</td>";
echo "<td>" . $row['AgendaName'] . "</td>";
echo "<td>" . $row['AgendaType'] . "</td>";
echo "<td>" . $row['AgendaDescription'] . "</td>";echo "<td>" . $row['Registration_date'] .

"</td>";
echo "</tr>";
echo "<script> alert('your search is successfull');
</script>";

[
] 2007 E.C
else {
echo "<script> alert('Please input AgendaCode?');
window.location = 'search.php';</script>";
?>
4.1.1.4 Sample PHP code for delete
<?php
if(isset($_POST["submit"]))
if (!$con)
$sql='SELECT AgendaCode FROM agenda WHERE AgendaCode = "'.$_POST["AgendaCode"].'"';
$result=mysql_query($sql,$con) or die(mysql_error($con));
$row=mysql_fetch_array($result);
if($row[0]=="")
echo '<table align="center">';
echo '<tr>';
echo '<td>';

[
] 2007 E.C
echo '<font color="red"><b>'.'Sorry,the entered Agenda Code ' . "

".'<h2>' .$_POST['AgendaCode']." ".'</h2>'.' is not found in database.'.'<br><br>Please enter the
Agenda Code.'.'<b><br></font>';
echo '<tr>';
echo '</table>';
die(); }
elseif($row[0]==$_POST["AgendaCode"])
$q='DELETE FROM agenda WHERE AgendaCode = "'.

$_POST["AgendaCode"].'"';
$result1=mysql_query($q,$con) or die(mysql_error($con));
echo '<tr>';
echo '<td>';
echo '<font color="green"><b>' . 'you have deleted the agenda

information with Agenda Code ' . " ".'<h2>' .$_POST['AgendaCode'].'</h2>'.' successfully.
'.'<b><br></font>';
echo '</table>';
die();
}else{
echo '<tr>';
echo '<td>';
echo '<font color="red"><b>' . 'The user account a' . " " .

$_POST['email'].' is not removed'.'<b><br></font>';
echo '</table>';

[
] 2007 E.C
die();
?>
4.2 Testing
Final phase of implementation is testing. Testing is a process to show the correctness of the
program. Testing is checking of the system workability in an attempt to discover errors and
avoiding such errors from the system. In this the team members tested the entire system as a
whole with all forms, code, modules. In this case we test the functionalities in the System. All
errors in the forms, functions, modules have been tested. The following are different testing
strategies.
4.2.1 Unit Testing
Unit testing is every module of the System is separately tested. It is often done by the
programmer to test that the unit he/she has implemented is producing expected output against
given input.
Test Case = TestCase1
Unit to Test = Authentication of login users
Assumptions = Login into appropriate page
Test Data = account type(empty, incorrect, valid)
User Email (empty , invalid email, valid user email)
Password (empty ,invalid password, valid password)
Steps to be Executed Data Expected Results
Empty account type and click Login Any valid data for the other fields
button
“ please select your

[
] 2007 E.C
account type”
“Please fill correct

Select incorrect account type, User user’s email and
email, password and Click Login Any valid data for the other fields password”
button
Select correct account type ,empty

user email, Password and Click Login
button Any valid data for the other fields “user’s email is empty”
Select correct account type, invalid “empty password,

user email and Click Login button Any valid data for the other fields
please enter your
password”
Select correct account type, User “your password must be

Any valid data for the other fields
email, Password length<6andClick at least 6 characters
And password=cbnnn
Login button long”
Select correct account type, User “sorry,spaces are not

Any valid data for the other fields
email, space b/n Password strings and allowed in passwords”
password string eg.cbn 123
Click Login button
Select incorrect account type, invalid All fields Fulfill with invalid data “please fill correct user
user email, incorrect Password and email and password”
Click Login button
Select account type, user email, All fields Fulfill with valid data “login to the
Password and Click Login button appropriate page”
Test Case1 –for User authentication
5.2.2. Integration testing
Integration testing is the activity of software testing in which individual software modules are
combined and tested as a group. It occurs after unit testing and before acceptance testing.
Thus, Integration testing is a logical extension of unit testing. In its simplest form, two units that
have already been tested are combined into a component and the interface between them is

[
] 2007 E.C
tested. Here a component refers to an integrated aggregate of more than one unit. In a realistic
scenario, many units are combined into components, which are in turn aggregated into even
larger parts of the program. The idea is to test combinations of pieces and eventually expand the
process to test your modules with those of other groups.
Integration testing can be done in a variety of ways but the following are three common
strategies:
 The top-down approach to integration testing requires the highest-level modules be test
and integrated first.
 The bottom-up approach requires the lowest-level units be tested and integrated first.
 The third approach, sometimes referred to as the umbrella approach, requires testing
along functional data and control-flow paths.
2.2.3. Acceptance Testing
Acceptance testing is the process of testing system (e.g. software, lots of manufactured
mechanical parts, or batches of chemical products) prior to its delivery. A system is mainly
developed for an end user normally a customer of the organization. A system is said to be
accepted if and only if the user of the system is satisfied. In this perspective acceptance testing is
widely used to prove that system performs as per the requirements.
In acceptance testing the customers provides the input data to validate the system operation. It is
also known as functional testing, black-box testing, release acceptance, QA testing, application
testing, confidence testing, final testing, validation testing, or factory acceptance testing
4.2.2 System Testing
It is the final step of testing. In this case the team members test the entire system as a whole with
all forms, code, modules. This form of testing is popularly known as Black Box testing or
System tests. Thus the team members test all the functionalities in the System. All errors in the
forms, functions, modules are tested.
Hardware and software acquisitions for Implementation

[
] 2007 E.C
For the project implementation, the following hardware and Software’s are used.
Hardware:-
 Printer: For printing Documentation
 Computers
 Flash Disk(8 GB)
 RG 45 cable
Software:-
 Microsoft SQL server
 Microsoft office
 Microsoft Windows Server
 Macromedia Dreamweaver
 Wamp Server
 Firefox browser
 Adobe photo shop
4.3 User manual preparation

In order to access the system, first of all every user must have an account or permission from
chairperson. So chairperson has the right to create an account for every user like AAmember,
student, teacher, and for him/herself. Users should enter into the system parts by selecting
their account type and by using their User Email and Password in order to access the system.
These Account Type, User Email and Password are created by the chairperson.
Chapter five
5.1 .Conclusion and Recommendation
5.1.1 Conclusion
The Academic Affairs Information Management System process made a web based application
to reduce human errors and to increase their efficiency. The main focus of this project is to
address data security and information distribution. The maintenance of the records is made
efficient, as all the records are stored in the database, and also data can be retrieved easily. The
editing is also made simpler. The user has to just type in the required field and press the update
button to update the information.

[
] 2007 E.C
The members are given a particular unique Email. So that they can access any information by
his/her Email and password correctly without errors. Our main aim of the project is to give
correct information effectively and efficiently to the users and make it more advantages than the
previous manual system by:
 Provide equal distribution of information
 Minimize the time required to perform task
 Provide sufficient security
 Minimize the wastage of materials
5.1.2 Recommendation
The system we have developed is an application web based system it needs a skilled person to
work with the system. So, we recommend the system should be required the responsible and
skilled person. We highly recommend the system should be kept in highly safe and favorable
condition

[
] 2007 E.C
5..3 .Reference
1. Wollo University Legislation

2. You tube
3. .Ambler, Scott (2001) The Object primer: The application Developers Guide to Object
Oriented and the UML.2nd rev. Ed England: The Cambridge University Press.
4. .http://en.wikipedia.org/wiki/Sequence_diagram
http://edutechwiki.unige.ch/en/User_interaction_and_user_interface_design
5. http://www.ambysoft.com/essays/classTypeArchitecture.html
6. http://en.wikipedia.org/wiki/Sequence_diagram
7. http://www.You tube about php tutorial
8. http://www.ambysoft.com/essays/userInterfacePrototyping.html
9. Generally internet is more preferable reference for our project

[
] 2007 E.C

Final

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Final

Uploaded by

Copyright:

Available Formats

This project paper is submitted to department of information system to final

fulfillment of the requirement for degree of Bachelor of Science in

Adviser: Mr. Asmelash G/S.

Kefale Tamene …….……………

Program: INFORMATION SYSTEM

Project subject: WEB BASED ACADEMIC AFFAIRS AINFORMATION MANAGEMENT SYSTEM

2. Examiner 2 ____________ ____________

WEB BASED ACADEMIC AFFIAR INFORMATION MANEGEMENT STSTEM FOR KIOT

Web Based Academic Affair Information Management System

KIOT ………..…………………………….Kombolcha Institute Of Technology

CRC………………….……………………Class Responsibility and Collaboration

SRS…………………………………………System Requirement Specification

Web Based Academic Affair Information Management System

Web Based Academic Affair Information Management System

1.12. Project Schedule (PERT)................................................................................................................9

Web Based Academic Affair Information Management System

3.3 Proposed software architecture......................................................................................................55

Web Based Academic Affair Information Management System

LIST OF TABLE page

Web Based Academic Affair Information Management System

Table 2.21 approve decision

List of figure page

Web Based Academic Affair Information Management System

1.1 Background/ Overview of the Organization

WEB BASED ACADEMIC AFFIAR INFORMATION MANEGEMENT STSTEM FOR KIOT

Initiation of the project

1.2 .Statement of the problem

 Information distribution /access problem

 Loss of data due to improper data storing system

 Wastage of time and materials

Therefore, the proposed system will solve these problems.

1.3. Project objectives

Web Based Academic Affair Information Management System

1.3.2. Specific objectives

The specific objectives of the project are:

To Study the background of the organization

1.4. Scope and limitation of the project

Web Based Academic Affair Information Management System

1.4.2 Limitation of the project

Interview: - we gathered relevant information about the background of the academic

Document analysis: - we also collected certain relevant information from written

Web Based Academic Affair Information Management System

 Promotes better understanding of user requirements.

1.6. Tools for System development/implementation

Hardware tools required are:-

Software tools required are:-

 Wampserver:-to test the system by running.

Web Based Academic Affair Information Management System

 Adobe Photoshop: -to edit images

1.7. Significance of the study

1.8. Feasibility Study

1.8.2 Technical Feasibility

Web Based Academic Affair Information Management System

18.3 Schedule Feasibility

1.8.4 Economic Feasibility

 Total Number of workers in AA offices of the existing system= 15

Web Based Academic Affair Information Management System

Table1.1 for cost of project

Total cost - - - 910

1.10. Task breakdown and deliverables

Web Based Academic Affair Information Management System

Table 1.2.task breakdown

1 Data Gathering And Project Proposal Kefale and wubie

2. Examiner 2