BULE HORA UNIVERSITY

COLLEGE OF INFORMATICS

DEPARTEMENT OF INFORMATION
TECHNOLOGY

Industrial Project I

Title: - Web based Department placement System for Bule Hora University

Members of the project

Name ID

1/ Boru Bante………………………………………………….015/15

2/ Masert Girma………………………………………………036/15

3/ Selam Abrha…………………………………………………..052/15

4/ Tesfamariam semere…………………………………….054/15

5/ Kedir Ahmed…………………………………………………028/15
 ABSTRACT
Education is the backbone for the development of one country. To expand ensure
quality of education university play a great role. This web based Department
Placement System for Bule Hora University is ensuring quality of education. On the
other hand ,the existing system have many problem such as The data will loss and it
takes time to manage, The system cannot give full information about the College and
Department of study. Due to this students will confused when they choose
Department they want, Misplacement, students cannot update the selection of
department after choice, The student fill their choice by paper and they haven’t
chance to see their choice whether it is correct or not. So, our aim to design a new
proposed system to solve the existing problem. The new proposed system Provides
such as changing the manual system (Department selection) into a web based system,
Develop web based system in order to secure placement system, Uses technological
way to provide reliable services, and Develop web based system to satisfy student
placement system.
 ACKNOWLEDGMENTS
Over all, we would like to thanks our Allah, Allah giving for us the ability to think, analysis
idea and health for patients, as well as strength and us to complete our project on time. Next
to this we would like to thanks our Department Information Technology for gave us the
brilliant opportunity to do this project on the topic to develop web based department
placement system for Bule Hora University. We would like express our special thanks of
appreciativeness for our advisors Instructor Mr. Sadiq Abas for his valuable and constructive
suggestions during the planning and development of this project work. His willingness to
give his time so generously has been very much appreciation. Thirdly, we would like to
thanks Academics Affairs directors to tell some information about the college how the
student selects the department in manually. We would like to extend our thanks to our friends
who have been supporting us in advice, moral or pray their Allah for completion of the
project. To all others who helped us in completing this project, we are equally grateful.
In conclusion, we wish to thank our parents for their support and encouragement throughout
our study.
 COMMITMENT-CERTIFICATE
This is to pronounce that the project work done under the supervision of Mr. Sadiq Abas
and having the title of web based department placement system for Bule Hora University by
contribution of team:
1. Boru Bante
2. Selam Abrha
3. Maserta Girma
4. Kedir Ahmed
5. Tesfamariam Semare
No part of this project work has any reproduced illegal job, which can considered as
Plagiarism. All referenced properly. We will be responsible for any consequence if violation
of this declaration is occur.

___________________________________

Date

Team Name signature

1. Boru Bante _______________________

2. Selam Abrha _______________________
3. Maserta Girma _______________________
4. Kedir Ahmed _______________________
5. Tesfamariam Semare _______________________

This project submitted to the examiner within the counter signature of advisor.

______________________________________
_________________
Advisor’s name Advisor’s Signature
 ENDORSEMENT MASS
This venture is entitled as “Web based department placement system” have been read and
approved as the requirement of the department of Information Technology for partial
fulfilment of the honor of Bachelor Degree in Information Technology, at Bule Hora
University

Approved by examination committee

___________________________________ _________________________

Chairperson /dept.’s head name Dept.’s signature

___________________________________ _________________________

Project Coordinator’s name Coordinator’s signature

___________________________________ _________________________

Advisor’s name Advisor’s signature

___________________________________ ___________________________

Examiner’s name Examiner’s signature

 ACRONYM
LAN: Local Area Network
CD:Compact Disc
PHP: Hypertext Preprocessor
HTML: Hypertext Markup Language
MYSQL: Multi-user Structural Query Language
CSS: Cascade Style Sheet
BR: Business Rule
FR: Functional Requirement
NFR: Non-functional Requirement
SDLC:System Development Life Cycle
UC: Use Case
UML: Unified Manipulate Language
CRC: Class Responsibility Collaborator
UI: User Interface
ID: Identification
 CHAPTER ONE
1.1 Introduction
The purpose of the project “WEB BASED DEPARTMENT PLACEMENT SYSTEM”, the
manual work makes the process slow and other problems such as Students choose a specific
department where the placement will be held, there is a need to maintain all these papers, and
it is manually done. In order to avoid this web based placement managed system is proposed,
where the student information in the college with regard to placement is managed efficiently.
It intends to help fast in fast access procedures in placement related activities and ensures to
maintain the details of the student. Students logging should be able to upload their personal
and educational information. The key feature of this project is that it is one time registration
enabled.

1.2 Background
Bule Hora University was started 2004 E.C in Bule Hora Town and it provides different
function for the environment as well as fair education access and implementing quality of
education for all. It has different college such as Informatics College, College of Engineering
and Technology, FB College, Healthy College, and etc. Each college has its own department.
After it starts the work load of managing students is more complex, especially during a
student select the department. Now there are many teacher and student are there. All College
has its own activity such as guide a student select to department, teaching process, manage
department staff as well as student and develop a knowledgeable student.

1.3 problems Statement

Students choose a specific college where the placement will be held, there is a need to
maintain all these papers, causing large amount of space. It is manually done, chances of
missing, difficult to handle the details of student. The student fill their choice by paper and
they haven’t chance to see their choice whether it is correct or not. So doing this manually it
makes difficult to accomplish tasks easily and effectively.

 If the number of student in our college increase in number, then it will be difficult to
manage and time taken.

 Automatic report generation problem

 It takes times and data redundancies.

  Not user friendly

 Losing of student’s files when transfer manual file place to place

 Assigning the students in their department manually is very tedious for the assigner.

1.4 Proposed System

The aim of the proposed system is to develop a system with improved facilities. The
proposed system can overcome all the limitation of the existing system, such as student’s
information is maintained in the database, it gives more security to data, ensures data
accuracy, reduces paper work and save time, it makes information flow efficient and paves
way for easy report generation, reduce the space. Proposed system is cost effective.

1.5 objective of the project

1.5.1 General objective
To develop Web based student department placement system for Bule Hora University.

1.5.2 Specific objectives

 To identify the problem of the existing system.

 To develop user friendly interface.

 To announce the result of assigned department on time

 To handle data manipulation

 To Register Student

 To approve the select department

 To manage the user of the system

1.6 Significance of the Project

The main benefits of this system as it is computerized web based system and it’s to provide
better services for student in department selection.

Other purposes are:

 It saves paper which provided by college to students to select their department.

 It minimizes man power.

  Improving efficiency

 To minimize problem of human error during at the time of assigning department

 It save time when a student select the department

 It minimizes work over load.

 To develop a system that provides fast and secured services.

 It helps students to choose their interested department without any confused

 The system helps the students and the college to communicate each other easily, so it
minimizes information gap.

 To minimize amount of cost paid by year to print a form

 To reduce the redundancy of information

1.7 Beneficiary of the project

 Student: student has many advantages after the complete the project such as to save
time, to select department easily, to view department quickly and soon.

 College: college has also many benefits such as to minimize a cost, to save time, to
register student and department easily and soon

 University: it has many benefits as college.

 Department: it has some benefit such as to view the student and soon.

1.8 Scope of the project

The scope of this project is Developing Web based department placement system for
Bule Hora University which its system boundary includes the following functions:

 Student selects the department in web based system.

 The system understand only English language

 The system is only for Regular student

 1.9 Limitation and constraint of the project
 This system work for LAN network.

 The system cannot be concerned other University it’s only for Bule Hora University.

 The system didn’t understand other language except English language.

1.10 Methodology
1.10.1 Data Collection Method

When we develop this system, data gathering plays a great role to know the tasks or activities
that can be done by the system. To do this system, it is important to know what activities are
done in existing system. After we know activity which is done on this manual system, it is
easy to develop the system. We can gather data from different sources. To gather our
requirement we use two type of data gathering methodology. These methodologies are
discussed below

 Primary Data collection Methodology

Interview
Interview is one of the best primary methods that used to gathering information because it
allows simply asking clear questions, it has high response rate and the interview is flexible
and adaptable way of finding information. We are Interview for interviewing the Deans of
college for recognizing the existing working procedure of the organization.
Observation
This technique is used to gather accurate information about how the system actually operates,
particularly about the processes. This method used to get the right information about the
organization and also to understand how the existing system works.
 Secondary Data collection Methodology
Documents Analysis: - To conduct this project we use document analysis method as an essential
in order to analyse different documents that used to develop this project.
Internet: we use internet by searching information and taking experience of other country through
internet to get information.
1.10.2 System Development and analysis methodology

System Development methodology

Object-oriented methodology is used because of the following reason:

 It implements the concept of object orientation like inheritance, encapsulation, and

polymorphism.

 The ability to challenging the problem domains.

 to make simple communication among users, analysts, designers and programmers

 it also unaffected to change because it uses prototyping and Unified Modelling

Language(UML) tools that minimize development time

 Use case diagram, Activity diagram, sequence diagram, class diagram, data modelling
and deployment diagram.
So it made the system maintenance easier and shortens the development time. Object-
oriented approaches also reduce the complexity of the system development. This is the reason
why object-oriented approach is used in developing this project.

System Analysis and Design Methodology

In the analysis and design of this project, object oriented analysis and designing methodology
is used. The methodology that is used here is prototyping because this methodology enables
us to do analysis, design and implementation concurrently

1.10.3 System Testing Methodology

In order to deliver this system as well operated system, this project is tested at
implementation phase by using different types of testing methodologies. Those testing
methods are:

 Unit testing: - The independent module is tested using this mechanism of

testing.

 Integration testing: - using this type of testing method, the modules which
are independent and dependent to each other are tested
  System Testing: -using this methods, the functionality of all modules
considering as a single system is tested

1.10.4 System Development Tools

Hardware Development Tools:

Different hardware used to develop our project

 Computer: -computer is a machine capable of doing many things. We use it to type

on it and install all software and programming language.

 Flash Disk and CD Hardware: - used for the movement of data from one machine to
another. We use both of them when we move our data from one machine to another.

Software Development Tools:

Item no Software Specification

1 Microsoft word To write the documentation part.

2 Edraw Max To draw diagram

3 XAMPP Server To make the website dynamic.

4 Notepad ++ To write code in a simple.

5 Browser(firefox, Since our system is web based, it is very necessary

Ucbrowser, chrome)

Table 1: Software development tools

1.10.5 System Implementation Tools

Database and Implementation Tools

Server side scripting: PHP, for server side scripting because it has the following advantages;
PHP has resource allocation machines and it can support object-oriented programming.
Although PHP is compatible with wide Varity of web server we will use Xampp server.
Client side scripting: by considering the following characteristics java script is used-: can be
embedded in HTML page, its popular.

Database: MYSQL rises to become one of the most popular database servers in the world.
This popularity is because of the servers speed, robustness and flexible. MYSQL has
arguable become PHP most popular database counterpart.

Static webpage: HTML is highly flexible with CSS and JavaScript.

Window -10 operating system

Power point and MS-word-: for Documentation and presentation.

1.11 Feasibility Study

Once the team understands the problem found in the system, the next step is to conduct which
high level capsule version of the entered system and design process.

Feasibility of a new system means ensuring that the new system, which we are going to
implement, is efficient and affordable. There are various types of feasibility to be determined.
Some of they are technical feasibility, organizational and operational feasibility, economical
feasibility and Ethical feasibility.

1.11.1 Operational Feasibility

This system addresses basic problems of the organization, particularly the daily routine
activities of the customer service department can be handled easily, which reduces the work
load of the department, and the organization can make its activities secure and go smooth,
thus they feel good because they believe that the system solves their basic problems.

1.11.2 Technical Feasibility

The system is going to be developed by following the php language, html, java script,
MySQL and other language and we have the ability to develop this system without any
difficulty since the team has studied the required methodologies and tools. So the system will
be technically feasible.

1.11.3 Organization Feasibility

Organizational feasibility attempts to developing and implementing a new system, against the
benefits that would accrue from having the new system in place. This feasibility study gives the
top management the organizational justification for the new system. So the new system is
considered to be organizationally feasible.
1.11.4 Ethical Feasibility

Ethical feasibility is a test to determine if the project is ethical, or even legal.  Ethical
feasibility should be tested from both the organizational perspective, as well as the
developer’s perspective.  The organization has a vested interested to develop applications that
show they are both professional and ethical. Therefore our project keeps all legal and ethical
of the country and the society.

1.12 Activity Plan/Time table

The time allocated for the smooth flow of the project by the team members is
described in the following table.

N Task name Start Finish durati 2018 2019

O on N De Ja Fe M A M Ju J
ov c n b ar pr ay n ul

1 Title 18/11/2 21/11/2 3 day

selection 018 018
2 Requiremen 26/11/2 4/12/20 9 day
t gathering 018 18
3 System 10/12/2 18/1/20 9 day
analysis 018 18
4 System 25/12/2 7/1/201 12
design 018 9 day
5 Implementa 3/3/201 6/6/201 2
tion or code 9 9 mont
h
with 9
day
6 Test and 10/6/20 18/6/20 8 day
recommend 19 19
ation
Table 2: Activity plan/time table

1.13 Cost break down of the project

This is for the budget invested to develop the system or total development cost of the
system through life of project.
 No Material Amount Unit price(birr) Total price

1 Pen 4 24 24

2 Flash 1 250 300

3 Paper 1 pack 230 230

4 Print - 300 300

Total 854 birr

Table 3: cost break down of the project

CHAPTER TWO
EXISTING SYSTEM

DESCRIPTION OF EXISTING SYSTEM

2 INTRODUCTIONS
As we described in first chapter current time students select their interested department based
on the mark of student and they see some criteria that means first see their mark and identify
whether female or male if it’s female add five marks for her. And also see whether they
come from under developed region like borana and gambella, if they come from that add five
marks for them. So, all these things are based on paper and also its take time and required
number of paper and cost.

Therefore the department selections are based on paper manually. During this, the huge
problem is at the side of college and department requires great human power, material and
other resources with manual based works and approaches. This makes us to involve in
developing web based student department placement system for Bule Hora University.

2.1. Overview of the existing system

In the existing system students select department manually on the paper. Thus students select
their interested department on paper that is given to them from the college. These papers are
forward to college and see the selection of student and give the department to the student.

2.1.1. Problem of existing system

 The selected way to help students to select their choice is paper which can be easily
damaged and get lost. Therefore this problem has great influence.
  It is manually done, chances of missing, difficult to handle the details of student

 The other problem is dis-order of student’s choice and these leads to work repetition
and students to become offensive.

 So doing this manually it makes difficult to accomplish tasks easily and effectively.

 Difficult to manipulate College information.

 Time consuming is another problem that found in an existing system.

2.1.2 Business rule of the system

The business rule in the existing system is as follow

#BR1:- the student didn’t select one department more than one.

#BR2:-the student must submit their choice at given time

#BR3:-Admin of the college is responsibility to manage the all department.

#BR4:-Admin of the college is responsible to announce the department

#BR5:-the time of selection department are at the student enter the university after
registration

#BR6:- department and student must have own account.

2.2 Reports generated and form of the existing system

Report generated - in this section we are going to describe the over view of report
generated form and contents of report. The reports are manpower intensive, time
taking, difficult to manage or arrange, and error prone since they are generated
manually.

Form:

Example we take Informatics College

2.3 New systems (proposed system)
The aim of proposed system is to develop a system of improved and enhanced area that
comfortable and secured environment to work with. The proposed system can overcome
existing students’ problems as well as the university problems by changing the manual to web
based system. The proposed system website is user friendly and it will be easy for the users to
access information easily. The proposed system takes problems of the existing system and
improves it for the sake of better performance. The proposed system can perform activity
using by automated system in order to provide fast, efficient and effective services to the
users and it saves the cost, time, and human labour of the office and the users. It can search,
update, delete and student and department using unique identifier (ID). The proposed system
has the following advantages including ensure data accuracy, security of data, manager
controls the entire system, greater efficiency, user friendly and interactive and minimum time
required. And also proposed system increase system performance, minimize human effort,
make the system more valuable than before, more satisfy student and department by
minimizing time to get service.
 2.4 System Requirements
There are two types of system requirements to develop this project. Namely Functional
requirements (FR) and Non Functional requirement’s (NFR).

2.4.1 Functional Requirement (FR)

Functional requirements are fundamental building block requirements. It is a statement
exactly what the system must do. The new system will take the following functional
requirements:-

 Enable students to select their interested department

 Register student depends on his/her department selection

 Register department as the student choice

 Display the department when the student enter their ID

 Generate report

2.4.1 Non-Functional Requirements

Non-functional requirements are global constraints of system. Non-functional
requirements cover all the remaining requirements which are not covered by the
functional requirements. They specify criteria that judge the operation of a
system, rather than specific behaviours.

1Usability : Since the system is easily accessed it is easily used everywhere in which
internet connection is available

2. Reliability: The system is always reliable and can operate for long period of time.

3. Security: The proposed system secures the entire user accounts and makes the selection
process with high degree of security.

4. Availability: The system should provide service for the user at any time and the college of
Informatics Student department Placement system should usable any year

5. Performance: -The system should have a quick response time for a single request made.

6. Maintainability: The system will be modifiable at any time to enhance features based on
the college’s needs. As needs change from time to time the original system will be made
available to fill the gap between the system and the newly emerging needs. The system could
be enhanced by adding new functionalities without necessarily changing the functionality of
the system.

7. Response time: -Response time is the total amount of time it takes to respond to a request for
service. So in our system, the service time is the time it takes to do the work you requested generally
the response time in our system is mostly short.

8. Accuracy: The college of Informatics Student department Placement system gives

only valid result if the user gives the correct input.

9. Portability: The system is able to run on different platforms as long as operating

system is installed

10. Graphical User Interface: The system should have easily understandable
graphical user interface. The user can interact with the system through the user
interface.

CHAPTER THREE
SYSTEM MODELING

3.1 System modelling

We should have to follow SDLC (System Development Life Cycle) as conceptual model
because it is used in project management to describe the stages involved in the system that we
have proposed to develop from an initial feasibility study through final document. System
model describes the scenarios like use case diagrams, sequence diagrams, class diagram and
etc. for the system. In this project, we used an object oriented system development
methodology.

3.1.1 Essential Use Case

Actor and use case Identification and Description

Actor Use case

manager  Post news
 Add criteria
  Manage department
 Manage student
 Report
 View comment
 Give comment
department  View student
 View post news
 View comment
 Add capability
 Give comment
student  View department
 Select department
 View post news
 Give comment
Table 4: Essential use case identification and description

3.1.2 Essential Use case diagram

Essential use case describes the interaction between the user and the system at a high level of
abstraction. The goal of an essential use case is to convey the most important aspects of the
user-system interaction by focusing on the user’s intent and on the observable result of the
system (without specifying the internal steps the system takes to achieve the result). Since an
essential use case describes only the most important information it represents a single success
scenario.
Figure 1: Essential use case diagram

3.1.3 Use case view

Use case approaches require the analyst to determine all the potential actors involved in a
system. Actors are external to the system and make use of it. An actor is typically a person,
but may be a third-party organization or another computer system. An actor makes use of a
system in different ways. Each of these ways is known as use cases. Use case is a
behaviourally related sequence of transaction (performed by a user/actor) in a dialog with the
system. A use case may involve a number of actors, just as an individual actor may make use
of several use case.

In our system we have three actors:

 Admin/deans of college:-a person who manage the all department and student.

 Department: - a person how takes student from college after a student register.

 Student: - student can view their choice of department and details information of the
college.
3.1.3.1 Use case identification
Identifying the activities that are mainly performed on the proposed system is the basic thing
in analysing a new system. The following use cases have been identified from the system
specification.

1. Login

2. Create account

3 .Change password

4. Register student

5. Add student

6. Delete student

7. Add department

8 .Delete department

9. View comment

10. Generate report

11. Give comment

12. View department

13. Select department

14. Delete account

15. Update account

16. View student

17. Post news

18. Add capability

19. Add criteria

20. Logout
3.2 Use case diagrams
Use case diagrams graphically depict system behaviour. The following diagram present a
high level view of how the system is used as viewed from an outside’s or actor’s perspective.
The use case diagram of the system is shown in Figure below.

Figure 2: proposed system Use Case Diagram

3.2.1 System Use case Description

Use case Name Login
ID UC#1
Actors Admin, department, student
Description Describe how the user logs into the
system
Pre-condition The user should have account which is
created first.
Post-condition The system is opened, then the user
logged into the system.
 Basic Flow of Event 1. The user opens the application and
clicks on login link.

2. The system will display login page

that asks the user to enter user name
and password.

3. The user fills the user name and

password to login to the system.

4. The user clicks Login Button.

5. The system checks the user name and

password.

6. The system displays access page for

the respective user.

7. Use case ends

Alternative flow of Event. If the user do not enter the correct user
name and password.

A6.The system asks the user to enter

correct user name and password.

A7. Use Case ends.

Exceptional flow of Events E6. Incorrect email or password or your
account is not activated

E7. Use Case ends.

Table 5: Use case description for Login

Use case Name Create account

ID UC#2

Description Create account for user and create account

use case allows the user to become a member
and get an account.

Actors Admin

Post Condition Account created for new user and user is a

 member of the system.

Basic Flow of Event 1. The user selects the option or click

create account link.

2. Create account form is displayed.

3. The user fills the required

information and press create button.

4. The system checks the information

entered by the user.

5. You are successfully created an

account message is displayed.

6.Use Case ends

Alternative Flow of Event E5. If information is not correct. Try again
Message is displayed.

E6. Use Case ends

Exceptional Flow of Event E5. Email already exist please try another.

E6. Use Case ends.

Table 6: Use case description for Create Account

Use Case Name Change Password

ID UC#3

Actors Admin, department, student

Description The user changes their password.

Precondition The user must have an account that is

previously created.

Post Condition The users successfully change the existing

 password.

Basic Flow of Event 1. The user click change password

link.

2. Change password form is

displayed.

3. The user fills the required

information and click on change
password button.

4. The system checks the entered

information by users.

5. The user change the password

successfully message is displayed.

6. Use Case ends

Alternative Flow of Events A4. The entered information is not correct.
Please try again. Message is displayed.

A6. Use Case Ends.

Exceptional Flow of Events E5. Old message did not match message.

E6. Use Case Ends

Table 7: Use case description for Change Password

Use case Name Delete account

ID UC#4

Actors Admin

Description To delete a user account field available

Precondition The Admin must log to the system

Post Condition Delete account of a user.

Basic Flow of Events 1. The Admin click on delete account

link.

2. The system displays the delete

 account page

3. The user press delete account

button.

4. The user can successfully delete an

account.

5. Use Case ends.

Alternative flow of Events A4. If it don’t deleted, please try again
message is displayed.

A5. Use Case ends

Exceptional view of an Event E4. Error, please contact system manager

message is displayed.

E5.Use case ends..

Table 8: Use case description for delete account

Use case Name Update account

ID UC#5

Actors Admin ,department,student

Description To update a user account available

Precondition The Admin must log to the system.

Post Condition Update account of a user

Basic Flow of Events 1. The Admin click on update account link.

2. The system displays the update account

form.

3. The user can fill the form.

4. The system checks the entered

information.

5. The user can successfully update an

account.
 6. Use Case ends

Alternative flow of Events A4. If incorrect value inserted please try

again message displayed.

A6. Use Case ends.

Exceptional view of an Event E5. Error!, message is displayed

E6.Use case ends.

Table 9: Use case description for update account

Use case Name View department

ID UC#6

Actors Student

Description To view the department available

Pre-condition First the department should have to be

registered

Post condition View the department

Basic Flow of Events 1. The user click on view department link.

2. The system displays the view department

form

3. The user can fill the form.

4. The system checks the entered

information.

5. The user can successfully view

department

6. Use Case ends

Alternative flow of Events A4. If the user can not view department
correctly, then error is there.

A6. Use Case ends.

Exceptional view of an Event E5. If the placement held is incorrect then

 the output is incorrect.

E6.Use case ends.

Table 10: Use case description for view department

Use case Name View student

ID UC#7

Actors Department

Description To view available student

Pre-condition First the student should have to be registered

Post condition View the student

Basic Flow of Events 1. The user click on view student link.

2. The system displays the view student

3. The user can see the view

4. The user can successfully view

department

5. Use Case ends

Alternative flow of Events A4. If the user can not view department
correctly, then error is there.

A5. Use Case ends.

Exceptional view of an Event E4. If the placement held is incorrect then

the output is incorrect.

E5.Use case ends.

Table 11: Use case description for view student

Use case Name Register Student

ID UC#8

Actors Admin

Description To register the Students that only selects the

 department.

Precondition The Admin must login to the system.

Post condition All students which selects the department of

informatics are registered

Basic Flow of Events 1. The Admin clicks on register student link.

2. Register student form is displayed

3. Admin fills the required information and

click on register student button.
Use case Name Select department
4. The system check the entered value
ID UC#9

Actors 5. Students are successfully registered

Student
message is displayed.
Description Student should able to select displayed
department
6. Use Case ends.
Pre-condition
Alternative flow of Events The
A5. student must login
The entered into the system
information is incorrect.
Post condition The department
Please try again.of select are
Message registered
is displayed.
Basic Flow of Events 1. The Student clicks on select department
A6. Use Case Ends
link.
Exceptional view of an Event E5. Error! Please try again message is
2. department form is display for the student
displayed.

3. The Student
E6.Use fills the required information
case ends.
and click on register department choice
button.

4. The system check the entered value

5. Department of choice is successfully

registered message is displayed.

6. Use Case ends

Alternative flow of Events A5. The entered information is incorrect.

Please try again. Message is displayed.

A6. Use Case Ends

Exceptional view of an Event E5. Can’t connect to system! Please contact

system administrator.

E6.Use case ends.

Table 12: Use case description for register student

Use case Name Select department

Table
13: Use ID UC#9
case
Actors Student

Description Student should able to select displayed

department

Pre-condition The student must login into the system

Post condition The department of select are registered

Basic Flow of Events 1. The Student clicks on select department

link.

2. department form is display for the student

3. The Student fills the required information

and click on register department choice
button.

4. The system check the entered value

5. Department of choice is successfully

registered message is displayed.

6. Use Case ends

Alternative flow of Events A5. The entered information is incorrect.

Please try again. Message is displayed.

A6. Use Case Ends

Exceptional view of an Event E5. Can’t connect to system! Please contact

system administrator.

E6.Use case ends.

description for select department

 Use case Name Add department

ID UC#10

Actors Admin

Description The admin add the department if its needed

Pre- condition The admin must login to the system

Post condition The department are added

Basic Flow of Events 1. The Admin clicks on add department link.

2. add department form is displayed

3. The Admin fills the required information

and click on add department button.

4. The system check the entered value

5. Department added successfully message is

displayed.

6. Use Case ends

Alternative flow of Events A5. The entered information is incorrect.

Please try again. Message is displayed.

A6. Use Case Ends

Exceptional view of an Event E5. The Current department name is inserted

Previously please try again

E6.Use case ends

Table 14: Use case description for add department

Use case Name Delete department

ID UC#11

Actors Admin

Description The admin responsibility to delete

department if its mandatory

Pre-condition The admin must login to the system

Post condition department are deleted

 Basics flow of Events 1. The admin click on delete department
link

2. Select the department want to delete

3. click on delete button

4. department successfully deleted

5. Use Case ends

Alternative flow of Events A4. If incorrect value inserted please try

again message displayed.

A5. Use Case ends.

Exceptional view of an Event E4. Error!, message is displayed

E5.Use case ends.

Table 15: Use case description for delete department

Use case Name Add Student

ID UC#12

Actors Admin

Description The admin add the student when it’s absent

at the time of selecting the department or
take the time to choices the department and
add the student.

Pre-condition View the presented student

Post condition Student are added

Basics flow of Events 1.The admin click into add student

link

2.Add student form is displayed

3.The Admin Fill the add student

information and click on add button

4.The system check the entered value

 5.Student is successfully added

6.Use case ends

Alternative flow of Events A5. The entered information is incorrect.
Please try again. Message is displayed

A6. Use Case ends.

Exceptional view of an Event E5. The Current department name is inserted

Previously please try again

E6.Use case ends

Table 16: Use case description for add department

Use case Name Delete student

ID UC#13

Actors Admin

Description The admin delete the student it doesn’t

presented

Pre-condition The admin login to the system

Post condition Student are deleted

Basics flow of Events 1.The admin click into the list of

student link

2.Select the student want to delete

3.click on delete button

4.student are successfully deleted

5. Use Case ends

Alternative flow of Events A4. If incorrect value inserted please try
again message displayed.

A5. Use Case ends.

Exceptional view of an Event E4. Error!, message is displayed

 E5.Use case ends.
Table 17: Use case description for delete student

Use case Name Post news

ID UC#14

Actors Admin

Description The admin post the news for the student and
department

Pre-condition The admin login to the system

Post condition the news are posted

Basics flow of Events 1.The admin click on post news link

2.Select the news or write the news

3. check the news is correctly written

or not

4.click on post button

5.news are successfully posted

6. Use Case ends

Alternative flow of Events A3. If news is not post please try again
message displayed.

A6. Use Case ends.

Exceptional view of an Event E4. Error!, message is displayed

E6.Use case ends.

Table 18: Use case description for post news
 Use case Name Add criteria

ID UC#15

Actor Admin

Description The admin add criteria for the student

depends on his/her address and gender

Pre-condition Admin login to the system

Post condition the criteria are added for student

Basic flow of Events 1.The admin click on add criteria link

2.Identify the student depends on

address and gender

3.add the mark for a student depends

on the criteria

4.Click on add button

5.Use case end

Alternative flow of Events A3. The entered information is incorrect.
Please try again. Message is displayed.

A5. Use Case Ends

Exceptional view of an Event E4. Can’t connect to system! Please contact

system administrator.

E5.Use case
Table 19: Use case description for add criteria
 Use case Name Add capability

ID UC#16

Actor Department

Description The department add capability to how many

student needs in that years

Pre-condition Admin login to the system

Post condition the capability are added for department

Basic flow of Events 1.The admin click on add capability

link

2.Write the capability to how many

student needs

3.Click on add button

4.Use case end

Alternative flow of Events A3. The entered information is incorrect.
Please try again. Message is displayed.

A4. Use Case Ends

Exceptional view of an Event E3. Can’t connect to system! Please contact

system administrator.

E4.Use case
Table 20: Use case description for add capability

Use case Name Report generation

ID UC#17

Actor Admin
 Description The admin generate report to every one

Pre-condition Admin login to the system

Post condition Report are reached

Basic flow of Events 1.The admin click on report

generation link

2.Write the report on the place of a

view

3.Send to the department

4.Click on send button

5.Use case end

Alternative flow of Events A4. The entered information is incorrect.
Please try again. Message is displayed.

A5. Use Case Ends

Exceptional view of an Event E4. Can’t connect to system! Please contact

system administrator.

E5.Use case
Table 21: Use case description for Report generation

Use case Name Logout

ID UC#18

Actors Admin, department, student

Description To out from services.

Pre-condition The user should be logged in first

Post condition The user logged out from the system

 Basic flow of Events The user clicks on logout button.
Table 22: Use case description for logout

3.3 Sequence Diagram

Sequence diagrams are used to show how objects interact in a given situation. Since The
sequence diagram is used primarily to show the interactions between objects in the sequential
order that those interactions occur. It depicts the objects and classes involved in the scenario
and the sequence of messages exchanged between the objects needed to carry out the
functionality of the system. Generally Sequence diagram is an interaction diagram that shows
how objects operate with one another and in what order. It is a construct of a message
sequence.

Figure 3: sequence diagram for login

Figure 4: sequence diagram for create account
Figure 5: sequence diagram for add student
Figure 6: sequence diagram for delete department
Figure 7: sequence diagram for delete account
Figure 8: sequence diagram for select department
Figure 9: sequence diagram for update account
Figure 10: sequence diagram for view student
Figure 11: sequence diagram for Post news
Figure 12: sequence diagram for Add criteria
Figure 13: sequence diagram for Add capability
Figure 14: sequence diagram for generate report
Figure 15: sequence diagram for view department

3.3 Activity Diagram

Activity diagram is another important diagram in UML to describe dynamic aspects of the
system. Activity diagram is basically a flow chart to represent the flow form one activity to
another activity. The activity can be described as an operation of the system. So the control
flow is drawn from one operation to another. This flow can be sequential, branched or
concurrent.
Figure 16: activity diagram for login

Figure 17: activity diagram for select department

Figure 18: activity diagram for create account

Figure 19: activity diagram for change password

Figure 20: activity diagram for view department

Figure 21: activity diagram for delete account

Figure 22: activity diagram for generate report

Figure 23: activity diagram for student registration

Figure 24: activity diagram for post news

Figure 25: activity diagram for add capability

Figure 26: activity diagram for logout

3.4 Collaboration diagram

By using collaboration, diagram or interaction describes represents the structural organization
of a system and the messages sent/received. Under this issue, structural organization consists
of objects and links. The purpose of we using collaboration diagram is similar to sequence
diagram. Nevertheless, the specific purpose of collaboration diagram is to visualize the
organization of objects and their interaction. By using this, diagrams aim at showing the
communications that happen between objects, by defining messages that flow between each
other.

Figure 27: Collaboration diagram for login

Figure 28: Collaboration diagram for student registration

3.5 State diagram

By using State chart diagram, we are going to describes sequence of states that an object or a
system goes through, the events that cause the action of a state, the transition from one state
to the other and the actions. The following are the main purposes of we are using State chart
diagrams:

• To model dynamic aspect of a system our system.

• To model lifetime of a reactive system of our system.

• To describe different states of an object during its lifetime.

• Define a state machine to model states of an object.

Figure 29: State diagrams for Login

Figure 30: State diagrams for Create account

Figure 31: State diagram for add department

Figure 32: State diagrams for delete account

3.6 Key Abstraction with CRC Analysis
Class Responsibility Collaborator (CRC) Modelling is a method to gather and define the
user requirements for an object-oriented application. The output of CRC Modelling is a
CRC model which is a collection of CRC cards that represent the whole or part of an
application or problem domain.

Figure 33: CRC diagram

3.7 Conceptual: Modelling class diagram

Conceptual class is a method of express our system conceptually and it is a domain
model and object oriented analysis contains conceptual classes, association between
 conceptual classes and attributes. "Informally, a conceptual class is an idea, thing, or
object". The model is shown as a class diagram.

Figure 34: Conceptual class diagrams

3.8 User Interface Prototype

3.8.1 Essential User Interface Prototyping

User interface (UI) prototyping is an iterative development technique in which users are
actively involved in a system. It have several purposes that basis from which to explore the
usability of our system. It represents the general ideas behind the UI, but not the exact details.
An essential UI prototype is effectively the initial state—the beginning point of the UI
prototype for the system.
Figure 35: User interface prototypes for Home page

CHAPTER FOUR

SYSTEM DESIGN

4.1. Introduction
In this part we can see about system design of Web based department placement system for
Bule Hora University. System design is part to get into the solution of a domain. In this
chapter, we define the design goals of the system; decompose the system into smaller
components that can be easily realized, the software architecture and persistent data
management of a system.

Design goals

The design goals represent the desired qualities of the system and provide a consistent set of
criteria that must be considered when making design decisions. The following design goals
are identified.

Performance

The response time of the system is reasonable. It also support parallel user with minimum
response time and it takes few minutes to process the placement
Usability

The system is user friendly, so that user can use the system without confusion.

Security

Since the system is going to handle sensitive data concerning an individual, the personal.
Information of an individual should be handled with a great care and hence it provides
authentication and database security.

Maintenance

The code for the system should be easily readable, understandable and should be easily
mapped to specific requirements.

Cost

The system should be developed with minimum cost possible.

4.2 Subsystem decomposition

Subsystem diagram shows the service it provides or it accepts from other subsystems, and the
coupling and the coherence between them. The system will be built on a layered architecture.
A layered architecture makes it easier to maintain or modify one part of the system without
affecting the others.

These are a grouping of model elements that represent a behavioural unit in a physical
system. The team used subsystem decomposition diagrams to express how the system is
decomposed to smaller parts or set of related operations that share a common purpose.
During decomposition of the system the system decomposed in to individual unit that can be
perform by one team member and one subsystem modification do not affect the other
subsystem and each subsystem class are related with each other.
Figure 36: subsystem decomposition diagram

4.3 Proposed System Architecture

The proposed subsystem will be implemented in Client/Server architecture. Wherever a user
is as long as there is Internet connection he/she can browse the Web based department
placement system page, fill the required inputs by the web page, and then submit it then the
request of the user will be sent to the central server. The server will give response based on
the user request. We represent the architecture of project as follows
Figure 37: proposed system architecture

4.4 Component diagram

By using, this Diagram of components of the system will be wired showing that there is
relation among components; management of the system, database and operations performed
on databases such security issue. This in some extent shows who will access which
component or objects and what type of security infrastructures it is using. The diagram
simulated as below.
Figure 38: Component diagram

4.5 Deployment diagram

Deployment modelling is used to show the hardware of the system, the
software that is installed in the hardware and also the middleware that is used
to connect the disparate machines to one and other. It also shows how the
software and the hardware components work together.
Figure 39: Deployment diagram

4.6 Design Class diagram

We used class diagram to describe the structure of the proposed system in terms of objects,
classes, attributes, operations, and their associations. Classes are abstractions that specify the
common structure and behaviour of a set of objects in Use Cases. Objects are instances of
classes that are created, modified, and destroyed during the execution of the system. The
proposed system consists of Admin, department, and Student. The class diagram will be
refined during system design to include classes representing the solution domain.

Classes are nothing but they represent participating objects found in use cases and sequence
diagrams and describe their attributes and operations. Objects can be anything having name,
attributes and properties. Associations between classes depicted as lines between classes. 
Associations should include multiplicity indicators at each end, for example, one representing
“1” and “*” represent many.
Figure 40: Design class diagram

4.6 Persistence Modelling for Object Oriented Database

Persistence modelling is the diagram that shows the relationship between the tables that
interrelated with each other. It also shows self-relation of the tables. It is only used for object
oriented database modelling; but for relational database modelling we use Entity Relationship
Figure 41: Persistence modelling diagram

4.7 Access Control and Security

Because of our system being multi-user environment, different actors have access to different
functionality and data. During analysis, we modelled this distinction by associating different
use cases to different actors. During system design, we model access by examining the object
model, by determining which objects are shared among actors, and by defining how actors
can control access. Depending on the security requirements on the system, we also define
how actors are authenticated to the system. The following access control matrix shows which
user has access to which function.
 Actor Functionalities

Manage Info Register news Give Comment

service

Admin Has authority Register Post view Serve View

to create, student and student student and comment on
update, delete department department student and
account and department
to generate
report,

department Has View student Serve Give

permission student comment on
to login to student and
his/her admin
account Has
authority
to
delete,
update his
/her account

student Has View Give

permission to department comment on
login to and select department
his/her department and admin
account Has
authority to
update his
/her
admission
number
Table 23: Actor Access control and security table
APPENDIXES
SYMBOL DESCRIPTION

Actor

System boundary

Use case

Package

Straight connector
 Include

Extending

Note

Time Activation

Object Lifeline

Class
 Message

Object deletion/destory

Self-delegation

Activity

State

Message return

Object

Decision activity
 Initial state/starting point of activity
diagram

Final state/Ending point of activity diagram

Association role

Component

Node in the Deployment diagram

Multiplicity many(zero)

Mandatory

Transition
 Database

Table 24: Appendix table

REFERENCES