Debre Markos University Duplication center

Web Based Customer Service management System

APROJECT REPORT
Submitted by
NAME OF THE STUDENT IDNUMBER

Weredaw Bazezew TER/4694/07

Abayneh Argachew TER/4640/07

Azmeraw Workneh TER/4648/07

Nigatu Amare TER/4683/07

In partial fulfillment for the Award of the Degree Of

BACHELOR OF SCIENCE IN INFORMATION TECHNOLOGY
Under the guidance of:
Kassahun T.
______________

DEPARTMENT OF INFORMATION TECHNOLOGY

INSTITUTE OF TECHNOLOGY
DEBRE MARKOS UNIVERSITY
DEBREMARKOS, ETHIOPIA
MAY 2010 E.C
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010
E.C

APPROVAL OF ADVISOR AND EXAMINERS

This project has been submitted for examination with our approval
as the project advisor.
Advisor Name Kassahun T Signature _____

This project has been examined with our approval as the project
examiner.
Examiner Name:
1. ____________________ signature______________
2. ____________________Signature______________
3. _____________________Signature_____________

Page | i
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010
E.C

Declaration
We,undersigned,declere that thesis our original work, has not
been presented for a degree in this or any other university, and all
the source of martial used for the thesis/project have been
acknowledged.
Signature

Name ID_NO Signature

1. Weredaw Bazezew TER/4694/07--------------------
2. Abayneh Argachew TER/4640/07--------------------
3. Azmeraw Workneh TER/4648/07-------------------
4. Nigatu Amare TER/4683/07-------------------

Page | ii
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010
E.C

Acknowledgment
First of all, we would like to praise our God who helps us to accomplish this project

documentation successfully. Our Next deepest gratitude will go to Mr. Kassahun T. who is our

advisor. He gave us a chance to acquire more detailed knowledge about the project and he helps

us in any confusion that was happening during the documentation development. This makes us

more knowledgeable about the project named Debre Markos University Duplication Center

Customer Service Management System. Thank you! Teacher. We are proud to be your students.

At the last but not the least, we would like to say Thank you for the Heads and Staffs of the

Debre Markos University Information Technology Department. Finally, we would like to thank

all the people who were with us in everything they have without hesitation.

With More Respect!!

Page | iii
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010
E.C

Abstract

Debre Markos University Duplication Center customer service Management

System is a web based application which aimed to change the manual system of the
Duplication Center process to automated system. The developed system makes the
duplication center process more attractive by reducing the problem that is
currently faced by this duplication center service. This paper shows the problem of
the existing system and the design of the new proposed system and show the
solution to the problems of the existing system in 3 chapters. Background,
Statement of the problem, objectives, the methodology and feasibility of assessment
clearly stated in the first chapter. Clear description of the existing system and
proposed system are also stated in this chapter. The second chapter mainly
describes the analysis phase. It deals with analyzing the general work flow and its
major players or participants of the existing system .The third chapter of this
documentation describe the different diagram and approaches used to compose the
new system.

Page | iv
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010
E.C

Contents
Acronym: .................................................................................................................................................... viii
List of tables................................................................................................................................................. ix
List of figures ................................................................................................................................................ x
CHAPTER ONE (1) .......................................................................................................................................... 1
1.1 Introduction ....................................................................................................................................... 1
1.2 Background ............................................................................................................................................. 1
1.3 Problem of statement ............................................................................................................................ 2
1.4 Over view of the Proposed System ......................................................................................................... 2
1.5 Objectives of the project ......................................................................................................................... 3
1.5.1 General objective ............................................................................................................................. 3
1.5.2 Specific objective:- ........................................................................................................................... 3
1.6 Scope of the project ................................................................................................................................ 3
1.8 Limitation of the project ......................................................................................................................... 4
1.7 Significance of the project ...................................................................................................................... 4
1.8 System requirements ............................................................................................................................... 5
1.8.1 Software requirement tools............................................................................................................. 5
1.8.2 Hardware requirement tool ............................................................................................................. 5
1.8.3 Programming and database tool ..................................................................................................... 6
1.9 Methodology ........................................................................................................................................... 6
1.9.1 Data gathering methods .................................................................................................................. 6
1.9.1.1 Primary data collection methods .......................................................................................... 6
1.9.1.2 Secondary data collection methods...................................................................................... 7
1.9.2 System Analysis and Design ............................................................................................................. 7
1.9.3 System development Methodology ...................................................................................................... 7
1.10. Feasibility Study .................................................................................................................................. 8
1.10.1 Technical feasibility ........................................................................................................................ 8
1.10.2 Operational Feasibility ................................................................................................................... 9
1.10.3 Economic Feasibility ....................................................................................................................... 9

Page | v
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010
E.C

1.10.4 Legal Feasibility ............................................................................................................................ 10

CHAPTER TWO (2) ....................................................................................................................................... 10
2.0 System Analysis .................................................................................................................................... 10
2.1 Overview of the Existing System.......................................................................................................... 10
2.1.1 Major players or participants of the existing system .................................................................... 11
2.2 System Requirement Specification ....................................................................................................... 11
2.2.1 Functional Requirements ............................................................................................................... 12
2.2.2 Nonfunctional requirements ......................................................................................................... 13
2.2.3 Business Rules ................................................................................................................................ 13
2.3 System Requirement Analysis ............................................................................................................... 14
2.3.1 Actor and Use Case Identification .................................................................................................. 14
2.3.2 Sequence Diagram ..................................................................................................................... 22
2.3.3 Activity diagram ........................................................................................................................ 26
2.3.4 Analysis Class Diagram ............................................................................................................. 32
3.0 System Design ...................................................................................................................................... 34
3.1 Design class Diagram......................................................................................................................... 34
3.1.1 Class Diagram Description ............................................................................................................. 36
3.2. Database Design............................................................................................................................... 37
3.2.1 Physical Data Model................................................................................................................... 37
3.3. User Interface Design ....................................................................................................................... 39
3.3.1 User Interface Screen shoots ..................................................................................................... 41
3.4 System Architecture .......................................................................................................................... 43
3.4.1. Deployment Diagram ................................................................................................................ 44
CHAPTER FOUR (4) ...................................................................................................................................... 45
4.1. Implementation ................................................................................................................................... 45
4.1.1. Overview of the programming language used ............................................................................. 45
4.1.2. Algorithms Used ...................................................................................................................... 45
4.1.2.1. Pseudo code .................................................................................................................... 45
4.1.2.1.1. Pseudo code for Login ..................................................................................................... 45
4.1.2.1.2. Pseudo code for Logout .................................................................................................. 46
4.1.2.1.3. Pseudo code for Search ...................................................................................................... 46

Page | vi
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010
E.C

4.1.3. Flow chart ................................................................................................................................. 46

CHAPTER FIVE (5) ........................................................................................................................................ 53
5.1. Testing .................................................................................................................................................. 53
5.1.1. Unit testing.......................................................................................................................... 53
5.1.2. Integration testing .............................................................................................................. 53
5.1.3. System testing ..................................................................................................................... 53
5.1.4. Performance Testing ........................................................................................................... 54
CHAPTER SIX (6) .......................................................................................................................................... 54
6.1. Conclusion and Recommendations...................................................................................................... 54
6.1.1. Conclusion ..................................................................................................................................... 54
6.1.2. Recommendation and Future Enhancement ................................................................................ 55
Reference .................................................................................................................................................... 55

Page | vii
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010
E.C

Acronym:
BR.......................................................................................................Business Rule

CId......................................................................................................Customer Identification

CSS......................................................................................................Cascading Style Sheet

DId......................................................................................................Department Identification

FId.......................................................................................................Feedback Identification

GUI.....................................................................................................Graphical User Interface

HId......................................................................................................Head Identification

HTML...............................................................................................Hyper Text Markup Language

ID......................................................................................................Identification

LCD..................................................................................................Liquid Crystal Display

MySQL...........................................................................................My Structured Query Language

PHP.................................................................................................Hyper Text Pre Processer

RAM...............................................................................................Random Access Memory

SId..................................................................................................service Identification

SRId..............................................................................................Service Request Identification

UC.................................................................................................Use Case

UML..............................................................................................Unified Modeling Language

USB...............................................................................................Universal Serial Bus

WAMP.................................................................................Windows, Apache, MySQL, and PhP

DMUDC....................................................................Debre Markos University Duplication center

Page | viii
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010
E.C

List of tables
Table 1: Software Requirement Table............................................................................................. 5
Table 2: Hardware Requirement Table ........................................................................................... 5
Table 3: Actor identification Table ................................................................................................ 14
Table 4: use case identification Table ........................................................................................... 16
Table 5: Use case description for login Table................................................................................ 18
Table 6: Use case description registering customers .................................................................... 19
Table 7: Use case description for submitting requests ................................................................. 20
Table 8: Use case description for viewing reports ........................................................................ 21
Table 9: Use case description of approving requests .................................................................... 22
Table 10: Customer class Description ........................................................................................... 36
Table 11: Service class Description ............................................................................................... 36
Table 12: Worker class Description ............................................................................................... 36
Table 13: Head class Description .................................................................................................. 36
Table 14: Service Request class description ................................................................................. 37
Table 15: Feedback description.................................................................................................... 37
Table 16: Customer table .............................................................................................................. 38
Table 17: Head Table .................................................................................................................... 38
Table 18: Service Request Table………………………………………………………………………………………........ 39
Table 19: Service Table…………………………………………………………………………………………………………….38

Table 20: Department Table ......................................................................................................... 39

Page | ix
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010
E.C

List of figures
Figure 1: System use case diagram ………………………………………………….…………………………………….17
Figure 2: Sequence diagram for login ........................................................................................... 23
Figure 3: Sequence diagram for registering customers ................................................................ 24
Figure 4: Sequence diagram for submitting service request ........................................................ 25
Figure 5: Sequence diagram for approving service request ......................................................... 26
Figure 6: Activity diagram for login .............................................................................................. 28
Figure 7: Activity diagram for registering customer ..................................................................... 29
Figure 8: Activity diagram for submitting customer service request ............................................ 30
Figure 9: Activity diagram for approving customer service request ............................................. 31
Figure 10: Analysis Class diagram ................................................................................................. 33
Figure 11: Design Class diagram ................................................................................................... 35
Figure 12: User Interface Structure ............................................................................................... 40
Figure 13: Homepage Interface .................................................................................................... 41
Figure 14: Register customer Interface ......................................................................................... 42
Figure 15: Submit service request Interface.................................................................................. 43
Figure 16: Deployment Diagram…..………………………………………………………………………………………….43

Figure 17: Flowchart Diagram for login…………………………………………………………………………………………….46

Page | x
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

CHAPTER ONE (1)

1.1 Introduction
Debre Markos University, which is in progress of growth, one of the second generation
universities in Ethiopia. Currently it has two campuses namely main campus, and Bure campus.
In main campus there are four colleges, two institutes and one school that is school of law. The
four colleges are colleges of Natural and computational science, colleges of Economics and
Business, colleges of Agriculture, colleges of social science and humanity and colleges of health
science. The two institutes are of institute Technology and institute of Land Administration.

At this University different services are provided such as student service directorate, which
comprises student clinic, student dormitory, student cafeteria and student supporting services,
and any other services including the duplication center of the university.
Debre Markos University Duplication center is a medium duplication center hat found inside the
university. This Duplication center provides copying, duplicating and binding service for
teachers and other societies of the university. This situation makes this duplication center useful
under the situation when students face a shortage of textbooks in the library. To solve this
problem legitimate customer’s take soft copies of textbooks that are less in number to this center
and will get hard copies of the textbooks. Therefore students can easily read and gain access of
textbooks. This Duplication center is very useful (helpful) since students most of a time use
hardcopies or textbooks to read than soft copies.

1.2 Background

Staff members of the university were beginning to understand the value and necessity of the
duplication center in this university and they began to discuss from June up to July 2006 E.c.
finally, they reached an agreement and established this center in august 2006 E.c.

This center immediately starts giving a service at the same month in 2006 E.c. This center is
established with six workers, four duplicating machine, two photocopies & printer machine and

Page | 1
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

three binding machines. Still the center works similarly as it does before without adding of any
human power or machines.

1.3 Problem of statement

The working environment in the existing system of the Duplication Center still uses a manual
system to communicate with customers. So this system has the following problems.

 Filling of forms incorrectly creates problems of identifying what type of service does the
customer wants to get and how much they need.
 Once the form is filled, it has to be used only in a limited number of days.
 Takes time to prepare different report in the center
 Once the customer got the service from the center and if the service request form is
incorrect, he/she may forget to bring correct service request form again to the center
which creates a problem in generating reports.
 It is difficult to know how many customers each worker in the center serves per day,
week or month.
 A customer may bring a service request form from another department even if he/she is
not a member that department.
 The existing system does not allow customers to give their feedback with regard to the
impact of the inputs on exam papers, copied textbooks, handouts, modules etc.

1.4 Over view of the Proposed System

There is mechanism for customers to gain the service of this center. The system has no
limitation in date specified.it also addresses the problem of wasting time. In addition to
this it solves the problem of generating incorrect reports. It is also possible to know how
many customers do each worker serves per day/week/month. Here the head should only
give permission to his/her staff members’ only. There is also a possibility for customers
to give feedback and complain to the center about the impacts of inputs on their work.

Page | 2
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

1.5 Objectives of the project

1.5.1 General objective

The general objective of this project is to develop a web based customer service management
system for the duplication center.

1.5.2 Specific objective:-

 To build a system that help to develop and send customer’s service request form
to the dep’t heads at any time.
 To build a system that registers the type of services provided in the center.
 To build a system that can approve service request form of customers
 To develop a system that confirms the service completion of customers.
 To build a system that generates reports about the number of customers that got
service.
 To develop a system that register complains of customers.
 To build a system that allows customers to give feedback (about the service,
quality of inputs etc.)

1.6 Scope of the project

Scope is the coverage area or the boundary that the project covers and the activities or operations
the system one. The scope of this project includes the following.

 Register customers that request for service in each head/on their department
 Fill service request forms
 Submit the service request form
 Approve the customer’s request
 Confirm the service completion

This project does not concern about the supplier of the inputs and the impact of quality of
inputs on exam papers, textbooks and others and also it does not provide a scheduled
checkup for machines that are nonfunctional in the center.

Page | 3
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

1.8 Limitation of the project

As there have been some limitations like time, resource and other external factors, the project is
not expected to include some of the following functionalities:

 It does not address the problem about the impact of quality of inputs on exam papers,
textbooks and others.
 There is no a scheduled checkup and service time for machines that are nonfunctional in
the center.
 Take time to do a repairing on malfunctioning machines.
 Payment for worked services is not handled in this project.

1.7 Significance of the project

The Duplication center users will get a benefit like:-

To the customer

 Ordering services of the center is easy and fast.

 Reduce time and energy that they waste to go to the head office to get service request
form and permission
 use their time wisely and properly

To the center

 Easy to handle workers and customers.

 Improve its working methodology because of customer’s feedback.
 Reduce complexity of information handling about the center.

To the worker

 Improve their working quality because of customer’s complain.

 use their time wisely and properly
 Decrease error

Page | 4
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

1.8 System requirements

System requirements are the hardware and software components of a computer system that are
required to do the proposed system and simply identify tools and methodology. There are
different System requirements:-

1.8.1 Software requirement tools

The software requirements are the instructional components used to develop a system. Software
requirement to develop system are as follows
No- Software tools Uses

1 32-bit Operating System-Windows 7 professional A platform to be used for implementing

and testing the project
2 Microsoft Power Point 2010 For presenting the project.

3 Microsoft office word 2010 Used to write documentation from start

to end of the project.

4 Wampserver To run php programs

5 Text-editors like php editor, notepad++ To develop texts, codes

6 Microsoft office Visio 2007 To draw UML diagrams

Table 1: Software Requirement Table
1.8.2 Hardware requirement tool
Computer used to write the proposal, documentation, develop web based customer management
system for the Duplication Center. The computer specifications have followed:-
No- Hardware tools Uses
1 Hard Drive 120 GB To store our data and other software’s

2 RAM 4GB To store files and other information’s

3 Processor Intel(R)Core(Tm)i3-4160 To processes tasks that we perform

4 Monitor LCD model Dell Used as interface

5 USB Flash Drive ,CD Drives For backup our data
Table 2: Hardware Requirement Table
Page | 5
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

1.8.3 Programming and database tool

1. Php

 Easy to use
 Fast feature development
 Open source licensing
 Storing user communities
 Speed
 Compatibility

2. Html, Css

 Easy to use cascading style sheet and to format

 Easy to create forms

1.9 Methodology
A methodology is a set of methods, processes, and practices that are repeatedly carried out to
deliver project. Some of the methodologies that the team members used to gather information
about the duplication center were listed below.

1.9.1 Data gathering methods

The method to be used for achieving the development of this project is based on need of getting
appropriate information related to the duplication center.

For the purpose of getting appropriate information we used the following types of data gathering
methodologies including Interview, direct observation, and document analysis.

1.9.1.1 Primary data collection methods

1.931.1.1 Interview
In this method, there was interaction between us and the manager of the duplication center.
Informal Interviews have been conducted with the manager and some of the potential workers to
find out what difficulties they encountered with the existing system. So the team members

Page | 6
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

gathered more information about the duplication center and requirements from workers and
manager.

1.9.1.1.2 Direct observation

The team members went to the duplication center and observed the activities of the workers and
manager and they did their task manually. It helps us to get real information about how the center
performs its function and this helps to strength the data that we gathered is true or correct.

1.9.1.2 Secondary data collection methods

1.9.1.2.1 Document Analysis
The team members went to the duplication center and got the duplication center’s manual or
document from the manager of the center and found important information’s about the
duplication center and the feedback given by the customer. It could also help us to understand
the center what and how it is doing.

1.9.2 System Analysis and Design

The system will be developed using Object Oriented Software Development
Methodology.
In this phase, the team members used UML (unified modeling language) tools, which is very
simple and easy to demonstrate the result of analysis with different models.

Some of them are:

 Use case diagram

 Class diagrams
 Deployment diagrams
 Sequence diagram
 Activity diagram

1.9.3 System development Methodology

This is a description of methods chosen to achieve the objectives of the proposed system. Object-
oriented system Analysis and Design (OOSAD) technique used to develop the proposed system.

Page | 7
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

System development methodology in system development refers to the frame work that is used
to structure plan and control the flow of developing an information system.

1.10. Feasibility Study

When doing any project it is fair to see some conditions with regard to cost, client (end users)
community and about the system developer. Feasibility is the measure of how beneficial or
practical the development of an information system will be an organization. To start with our
project first we should have to clearly notify the feasibility of the system that we are going to do.

There are some factors of feasibility for this system. Those are:-

1. Technical feasibility

2. Operational feasibility

3. Economic feasibility and

4. Legal feasibility

1.10.1 Technical feasibility

Technical feasibility is the measure of the practicality of a specific technical solution and the
availability of technical resources. In technical feasibility we should notify that our system can
implement with current technology and also the system user has enough experience using that
technology. Technical feasibility addresses three main things:
 Is the technology practical?
 Do we currently pass the necessary technology?
 The ability to do on the technologies.
So we can say that our system is technically feasible because of three main reasons. The first one
is our project is compatible with the era that we are living in, that is information era. The second
reason is we can implement our system using current technology that is by using notepad++&
Php editor for PHP development and also for organizing our data we have MySQL data base and
for system design we have Microsoft Visio 2007 and GUI. The last reason is users cannot face
additional burdens to be familiar with the system.

Page | 8
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

1.10.2 Operational Feasibility

Measure how much the proposed system solves the existing system problems. This project is
surely operationally feasible because the system (the project) is a good solution maker of the
problem and creates a good environment towards the user of the system by providing easy, user
interactive and everywhere access.
It is mainly related to human co-ordination and political aspects. The points to be considered are:

 What changes will be brought with the system?

 What organization structures are disturbed?
 What new skills will be required? Do the existing staff members have these skills?

If not, can they be trained in due course of time?

The system is operationally feasible as it is very easy for the End users to operate. It only needs
basic skill about computer system. The customers can operate the system with little training. The
system is developed using both English and Amharic languages and both the user manual and a
Help menu will also assist customers to easily interact with the system. So we can say that the
system is operationally feasible.

1.10.3 Economic Feasibility

Economic justification is generally the “Bottom Line” consideration for most systems. Economic
justification includes a broad range of concerns that includes cost benefit analysis. In this project
the team members weight the cost and the benefits associated with the candidate/existing system
and if it suits the basic purpose of the organization .i.e. profit making, the projects making to the
analysis and design phase.

The financial and the economic questions during the preliminary investigation are verified to
estimate the following:

 The cost to conduct a full system investigation.

 The cost of hardware and software for the class of application being considered.
 The benefits in the form of reduced cost.
 The proposed system has given the minute information, as a result the
performance is improved which in turn may be expected to provide increased
profits.
Page | 9
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

 This feasibility checks whether the system can be developed with the available
funds.

The System does not require enormous amount of money to be developed. So it is economically
feasible because of the following

 Increased customer service

 Reduced the systems expense
 Fewer processing error

1.10.4 Legal Feasibility

Our project is having developed in the context of the organization rule and regulation and it
doesn’t conflicts with the rule of the organization. Our system will be developed to facilitate the
objective of the organization. Thus, the project team assumes that it is legally feasible.

CHAPTER TWO (2)

2.0 System Analysis

This section deals with analyzing the general work flow and its major players or participants of
the existing system. It produces a broad outline of the system that identifies the function to be
performed and the technical aspect that the system must fulfill and briefly describes the existing
system functionality, problem of the existing system. It also deals the functional and non-
functional requirements of the proposed system. The business rule is also identified here.

2.1 Overview of the Existing System

The existing system executes its task manually by letting customers to go to the duplication
center physically. There is limitation of waiting for their turn as many customers reach at the
same time. Another problem is that filling of the forms incorrectly. Therefore working manually
takes more time and the working condition is tedious. So our main purpose is to make
duplication center customer service management system web based, in which customers can get
service easily.

Page | 10
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

2.1.1 Major players or participants of the existing system

Participants of existing system represent external and internal entities that interact with the
system.
Here are the major participants of the existing system including:

 Customers interact with the center and fill forms in order to gain the service manually.
Rather and he/she requests a service from the duplication center in a computerized way.
The center then gives necessary services based on the order of customer and the customer
gets his/her requested service from the center.
 The manager of the center view reports manually. The report helps the manager to see
how many customers have gotten the center’s service.
 The workers of the duplication center work manually by viewing the orders of the
customers on the service-form.
 The head lets customers that are his/her staff members to get approvement for their
service request.

2.2 System Requirement Specification

In this section we have kept the basic understanding of the requirements and dependencies of the
current system prior to any actual design or deployment work.

A well-designed, well-written system specific requirement accomplishes four major goals

 It provides feedback to the system. A system specific requirement is the customer's

assurance that we have understood the issues or problems to be solved and the software
behavior necessary to address those problems.

 It decomposes the problem into component parts. The simple act of writing down
software requirements in a well-designed format organizes information, places borders
around the problem, solidifies ideas, and helps break down the problem into its
component parts in an orderly fashion.
 It serves as an input to the design specification. The system specific requirement serves
as the parent document to subsequent documents, such as the software design
specification and statement of work. Therefore, the system specific requirement must
Page | 11
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

contain sufficient detail in the functional system requirements so that a design solution
can be devised.
 It serves as a product validation check. The system specific requirement also serves as the
parent document for testing and validation strategies that will be applied to the
requirements for verification.

2.2.1 Functional Requirements

Functional requirements are the intended behaviors of the system. This behavior may be
expressed as services, tasks or functions that the system is required to perform. The system will
be used to manage and process data according to the rule & regulations of the center. It will also
provide report generation facilities. The database of the system provides the following
functionality.

 Data entry:
This is the functionality that data is entered to the systems. The system serves
different interface that can manage data entry mechanisms in the center.

The main data entries are the following:

 Customer registration
 Login
 Register center’s worker
 Register service types
 Register staffs(Customer)
 Data processing:-
The system on input data will provide the following data processing:

 Validate user’s provided data

 Approve service request
 View report
 Cancel service request
 Reject customer service request
 Report generation:-
 Total numbers of customers served in the center’s service.
Page | 12
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

2.2.2 Nonfunctional requirements

Non-functional requirement is a requirement that specifies criteria that can be used to judge the
operation of a system, rather than specific behaviors. This should be contrasted with functional
requirements that define specific behavior or functions. Non-functional requirements are often
called qualities of a system. Other terms for non-functional requirements are constraints, quality
attributes, quality goals and quality of service requirements.

This project will include the following system related nonfunctional requirements:-

 Security: - The system provides security since it validates customers and other users by
their username and password that this is not the case in the existing system.
 Performance: - The system has faster response time as it operates as expected over
specified time interval.
 Usability: - The system is easy and understandable to use since it does not require much
more expert or skill.
 Availability: - The system should available 24 hours a day as much as possible.
 Reliability: - The system used backup procedure to maintain and secure data of the head,
manager, worker and others.

2.2.3 Business Rules

A business rule is effectively and working principle or polices that we try to specify for both the
existing system and the new system must satisfy. The business rule is a principle or a policy in
which the proposed system works accordingly. It deals with access control issues.

It often concerns to working policies and principles of the center.

The following are business rules in the existed and proposed system:-

 Br1: customer must submit service requests that clearly identify what service and how
much they want.
 Br2: The customer must be allowed to send service requests only to his/her head.
 Br3: To ask for the service customers must have an account and must be login.
 Br4: Workers must verify the customer’s service request before performing the
service/task.
 Br5: Head must only confirm his/her staff member’s service request
Page | 13
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

2.3 System Requirement Analysis

System requirement analysis is an integral part of information systems design and is critical to
the success of interactive systems. It is now widely understood that successful systems and
products begin with an understanding of the needs and requirements of the users.

2.3.1 Actor and Use Case Identification

Actors represent external and internal entities that interact with the system. An actor can be
human, external and internal system. And it’s a type of role played by an entity that interacts
with the system (e.g., by exchanging signals and data). Generally, actor means something that
initiates, stimulates the system to react or something that responds to the systems requests. We
identify the following as actors:-

Actor

1. Customers

2. Head

3. Worker
4. Manager
5. Administrator

Table 3: Actor identification Table

Use case Identification

Use case is interactions between actor and a system, to achieve a goal. Derive from the scenarios
that completely represent the future system. This is primarily done in the form of a scenario that
describes a sequence of steps.

Use case Name ID Include

Login UC1

Page | 14
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

Logout UC2 UC1

Register customers UC3 UC1

Update customer UC4 UC1

View customers UC5 UC1

Register workers UC6 UC1

Update worker UC7 UC1

View worker UC8 UC1

Register service types UC9 UC1

Submit service request UC10 UC1

Approve service request UC11 UC1

Reject service request UC12 UC1

Cancel service request UC13 UC1

Check service request status UC14 UC1

Confirm service completion UC15 UC1

Generate report UC16 UC1

View/Print report UC17 UC1

Give feedback UC18 UC1

View log event UC19 UC1

Create account UC20 UC1

Update account UC21 UC1

View account UC22 UC1

Block account UC23 UC1

Activate account UC24 UC1

Register complains UC25 UC1

View complains UC26 UC1

Page | 15
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

Table 4: use case identification Table

Use Case Diagram

A use case is a sequence of action that provides a measurable value to an actor. When we look it
in another way, a use case describes a way to which a real world entities to interacts with the
system. An essential use case sometimes called a business the case is simplified, abstract,
generalized use case that captures the intention of the user in a technology and implementation
independent manner. The case models are used to document the behavioral (functional)
requirement of a system or the “what “of the system.

 A use case describes a sequence of action that provides a measurable value to an actor
and draw as a horizontal ellipse.
 An actor is a person, organization, external or internal system that plays a role in one or
more interactions with the system and draw as stickman figure.

Relationship between actors and use cases exists whenever an actor is involved with an
interaction described by a use case and modeled as a line connecting use cases and actors.

Page | 16
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

Register worker

Cancel service
request Register Service

Send service
request View feedback

«extends»

Give feedback View complain

{includes}
{includes}
{includes}

{includes}
Confirm service {includes} Generate report
completion
{includes} Manager
{includes}

Check service {includes} View Report

{includes}
request status
Customer {includes}
{includes}

Register complain
{includes}
{includes}
Login Update
View customer's {includes}

status
{includes}
{includes}

View Worked service View

{includes}
{includes}

{includes}
{includes}

Log File View service

{} {includes} request
Worker
{includes} {includes}

{includes}
Activate account {exclude} Approve service
Request

Fetch file Head

Reject service
request

Create account

Register customer

Block account

Admin Logout

Figure 1: System use case diagram

Page | 17
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

Use Case Description

Use case name Login

ID UC1
Actor Manager,Worker,Customers,Head,Admin
Description Help Users to login into the system by their user name and
password.
Pre-condition Users must have an account before
Post condition The authenticated user can be able to login into the system.
Basic course of action User action System response
1. User opens the system. 2.The System displays Login
3. User fills user name and page
password and then click login 4. The system validates the
button. entered information.
6. Use case ends. 5. User’s page displayed.

Alternative course of action If invalid “username or password” is provided, the system display
error message and the process resume from step 3 above.

Table 5: Use case description for login Table

Use case name Register customer

ID UC4
Actor Head

Description The head register customers that are under his/her

responsibility
Pre-condition Customers must be member of the staff that they will be
register

Page | 18
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

Post condition Customers registered and becomes member of a particular head

Basic course of action User action System response

1. The head open the system 2. System displays the log in
3.The head enters his/her page.
username and password 4. System validates
6. The head click register information’s provided by the
link and fill customers profile head.
8. The head click register 5.The head page displayed
button. 7.form validates the provided
information
9.Use case ends
Alternative course of action If the information entered is invalid or incomplete at step 3
above,
The system displays “error message”
The process returns to step 3.
Table 6: Use case description registering customers

Use case Name Submit service request

Id UC8

Actor Customer

Description Customers submit their request to the head

Precondition The customers should be a legitimate user and should be registered.

Post condition Customers send their request successfully

Basic course of Users action System response

Page | 19
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

action 1. The customer open the system 2. System displays the log in page.

3.The customer fill his/her username 4. System validates information’s

and password provided by the customer.

6. Customers fill their service request 5.The customer page displayed

form.
7.form validates the provided service
8. Customers submit their service request information
request to their head.
9. End of use case.

Alternative course If the filled service request format step 3 above is invalid, The system displays
of action “error message”

The process returns to step 3 above.

Table7: Use case description for submitting requests

Use case name View report

ID UC15

Actor Head ,Manager

Description See the reports that they generate/perform before.

Pre-condition First there must be a completed task

Post condition Head, Admin, Manager, can view the reports about the performed
activities.

Basic course of action Users action System response

1. The Head, Admin, Manager, open 2.the system display login page
the system

Page | 20
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

3. The Head, Admin, Manager, fill their 4. System validates

username and password information’s provided by the
5. The Head, Admin, Manager, click user.
view report link.
5. System displays the user
page.
6. Use case end.
Alternative course of action If the information provided at step 3 is incorrect, The system displays
error message.
The System continues at step3 above.

Table 8: Use case description for viewing reports

Use case Name Approve service request

Id UC9

Actor Head

Description The head approves service request form of customers.

Precondition First the customer that asks request must be a registered in the system.

Post condition The head approves the request of customers.

Basic course of User Action System Response

action
1. Head open the system. 2.Login page displayed

3. Head fill his/her user name and 4.System validate the provided
password.[A1] username and password

6. Head clicks view report link and 5.Head page displayed

view customers that ask request.
8. End of use case.
7.approve customer’s service request-

Page | 21
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

Alternative login detail is incomplete or mismatch at step 2 above,

course of action
The system displays error message.

The system continues at step 3 above.

Table 9: Use case description of approving requests

2.3.2 Sequence Diagram

A sequence diagram is an interaction diagrams that depicts the details of how operations are
carried out: what messages are sent and when. Sequence diagrams are organized according to
time. The time progresses as you go down the page. The objects involved in the operation are
listed from left to right according to when they take part in the message sequence.

Sequence diagrams are used to depict graphically how objects interact with each other via
messages in the execution of a use case or operation. They illustrate how the operations are
performed between objects and in what sequence. Sequence diagram is an interaction diagram
that shows how processes operate with one another and in what order. It is a construct of a
Message Sequence Chart. This sequence diagram shows object interactions arranged in time
sequence. 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.

Page | 22
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

Figure 2: Sequence diagram for login

Page | 23
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

Figure 3: Sequence diagram for registering customers

Page | 24
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

Figure 4: Sequence diagram for submitting service request

Page | 25
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

Figure 5: Sequence diagram for approving service request

2.3.3 Activity diagram

In UML, an activity diagram provides a view of the behavior of a system by describing the
sequence of actions in a process. Activity diagrams are similar to flowcharts because they show
the flow between the actions in an activity; however, activity diagrams can also show parallel or
concurrent flows and alternate flows.

In activity diagrams, you use activity nodes and activity edges to model the flow of control and
data between actions.

Page | 26
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

The header of the activity frame displays the name of the activity, Activity1, and the body of the
activity frame displays the nodes and edges that describe the activity.

The following topics describe model elements in activity diagrams:

Activities
in UML, activities are container elements that describe the highest level of behavior in an
activity diagram. Activities contain several activity nodes and activity edges that
represent the sequence of tasks in a workflow that result in a behavior.
Actions
In UML, an action represents a discrete unit of functionality in an activity.
Controls
In activity diagrams, a control node is an abstract activity node that coordinates the flow
of control in an activity.
Objects
In activity diagrams, an object node is an abstract activity node that helps to define the
object flow in an activity.
Activity edge
In activity diagrams, an activity edge is a directed connection between two activity nodes.
When a specific action in an activity is complete, the activity edge continues the flow to
the next action in the sequence.

Page | 27
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

Activity diagram for login

Log in Page

Enter username
Enter Password

Click login

Login controller

Invalid valid
Display error message Display Userpage

Figure 6: Activity diagram for login

Page | 28
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

Activity diagram for Registering customers

Login page

Enter Username Enter password

Click Login

Login controller

Valid
Display error Invalid
Userpage Displays
message

Fill customers profile

Form validation

Inccorrect correct
Display Error Message Click Register button

System displays
successful message

Figure 7: Activity diagram for registering customer

Page | 29
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

Activity diagram for submitting customer service request

Login page

Enter Username Enter password

Click Login

Login controller

Valid
Display error Invalid
Userpage Displays
message

Fill service request form

validate

Inccorrect correct
Click Reject button Click submit button

System displays
successful message

Figure 8: Activity diagram for submitting customer service request

Page | 30
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

Activity diagram for approving customer service request

Login page

Enter Username Enter password

Click Login

Login controller

Invalid Valid
Display error
message Userpage Displays

View service request form

validate

correct
Inccorrect
Click Reject button Click approve button

System displays
successful message

Figure 9: Activity diagram for approving customer service request

Page | 31
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

2.3.4 Analysis Class Diagram

Class models are the main study of object-oriented design and analysis. Class model shows the
classes of the system, their interrelationships (including inheritances, aggregation and
association) the operations and the attributes of classes. In this class diagram the team members
try to describe the types of object in the system and the various kinds of static relationships that
exist among them as well as depicted the detailed understanding of problem domain of the
system. These Class diagrams are developed based on the functional requirement.

Show the classes of the system, their inter-relationships, and the operations and attributes of the
classes. Class diagrams are typically used, although not all at once, to:

 Analyze requirements in the form of a conceptual/analysis model

 Depict the detailed design of object-oriented or object-based software

Class Diagram provides an overview of the target system by describing the objects and classes
inside the system and the relationships between them. It provides a wide variety of usages; from
modeling the domain-specific data structure to detailed design of the target system. With the
share model facilities, you can reuse your class model in the interaction diagram for modeling
the detailed design of the dynamic behavior. The Form Diagram allows you to generate diagram
automatically with user-defined scope.

Page | 32
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

Analysis Class Diagram

Service Request 1
Department -SRD:
-DId: -SDD: 1
1 Head
-Dname: -SRId:
-SRName: -DId:
Submit
* +Register customer:()
-CId:
1 -SId: 1 +Create account()
Has * +Update Account()
+Approve()
+View() +Update Customer()
* *
+Reject()
* +cancel()
Customer 1
+submit() 1 Admin
-DId: *
*
+View thier status()
+Confirm service completion() 1 * Manage
+Create()
*
Request Register
+Block()
* 1 +Activate()
*
+Update account()
Complain Account 1
Give -CId: Worker
-UserId:
-Description: * -Username: *
+View customer status()
+Give() -Password:
+View worked service()
Request +View()
-Role:
*
Inherite 1 Inherite
-Date: *
-Status:
Feedback +Login()
* -CId: *
* View *
+Give()
+View()
User 1 Manager
* * -Id:
+generate report()
-Fname: 1
Service +Register worker()
1 -Lname:
-Sid: +Register service()
-Sex:
-SName: +Update worker()
-Phone no-:
-Status: +Create account()
* Inherite +Update account()
1
1

Figure 10: Analysis Class diagram

Page | 33
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

CHAPTER THREE (3)

3.0 System Design

System design is the process of defining the elements of a system such as the architecture,
modules and components, the different interfaces of those components and the data that goes
through that system. It is meant to satisfy specific needs and requirements of a business or
organization through the engineering of a coherent and well-running system.

System design has a great part which describes the first solution of the system problem. So
designing a system is the important and necessary step in any system. System design provides a
clear description of the overall design of the Duplication center and bridging the gap between
desired and existing system in a manageable way.

3.1 Design class Diagram

a class diagram 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 objects.

The class diagram is the main building block of object-oriented modeling.

Page | 34
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

Design Class Diagram

1
Department Service Request
-DId:Int -SRD:Date & time(15) *
1
-SDD:Date & time(15) 1 Head
-Dname:Varchar(20)
-SRId:Varchar(20) -DId:Int(10)
-SRName:Varchar(20) +Register customer:()
1 Submit -CId:Int 1 +Create account()
Has -SId:Int +Update account()
*
+Approve() +Update customer()
* * +View()
+Reject()
Customer +cancel() 1 1 Admin
*
-DId:Int(10) * +submit()
* +Create()
+View thier status() * Manage
+Confirm service completion() Register
+Block()
1 * +Activate()
* 1 +Update account()
*

Complain Account 1 Worker

Give -CId:Varchar(20) -UserId:varchar(20) **
-Username:varchar(20) +View customer status()
+Give() *
-Password:Int +View Worked service()
+View()
* -Role:varchar(20)
1 Inherite
*
Request * Inherite
-Date:date&time
-Status:varchar(20)
Feedback +Login()
*
* -CId:Varchar(20) *
+Give()
User
+View() Manager
-Id:Int(10)
-Fname:Varchar(20) 1
* +generate report()
-Lname:Varchar(20) * +Register worker()
1 -Sex:Varchar(10) +Register service()
* -Phone no-:Int +Create account()
* 1 +View Feedback()
Service View
+View Complain()
-Sid:Int(10) +Update worker()
*
-SName:Varchar(20) * +Update account()
-Status:varchar(10) Inherite

Figure 11: Design Class diagram

Page | 35
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

3.1.1 Class Diagram Description

Attribute Purpose Data type

Customer Id Uniquely identify the customer Varchar
Customer Fname The forename of the customer Varchar

Customer Lname The father name of the customer Varchar

Table 10: Customer class Description

Attribute Purpose Data type

Service Id Uniquely identify the service Int
Service name Name of the service varchar
Service status The status whether the service is available or
not
Table 11: Service class Description

Attribute Purpose Data type

Worker Id Uniquely identify the workers Int(integer)
Worker Fname The first name of the worker Varchar
Worker Lname The father name of the worker Varchar
Table 12: Worker class Description

Attribute Purpose Data type

Head Id Uniquely identify the head Int
Head Fname The first name of the head Varchar

Head Lname The father name of the head Varchar

Table 13: Head class Description

Page | 36
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

Attribute Purpose Data type

Service Request Id Uniquely identify the service request Int
Service Request Name The name of the service Varchar

Service RequestDate The date that the service is requested Date & time
Service DeliberationDate The date that the service is delivered Date & time
Table 14: Service Request class description
Attribute Purpose Data type
Feedback Id Uniquely identify the Feedback Int
Feedback Fname The first name of the Feedback Varchar

Feedback Lname The last name of the Feedback Varchar

Table 15: Feedback description
3.2. Database Design
Database design is the process of producing a detailed data model of a database. This logical data
model contains all the needed logical and physical design choices and physical storage
parameters needed to generate a design in a Data Definition Language, which can then be used to
create a database. A fully attributed data model contains detailed attributes for each entity.
The term database design can be used to describe many different parts of the design of an overall
database system. Principally, and most correctly, it can be thought of as the logical design of the
base data structures used to store the data. In the relational model these are the tables and views.
In an object database the entities and relationships map directly to object classes and named
relationships.
However, the term database design could also be used to apply to the overall process of
designing, not just the base data structures, but also the forms and queries used as part of the
overall database application within the database management system (DBMS).

3.2.1 Physical Data Model

The process of doing database design generally consists of a number of steps which will be
carried out by the database designer. Usually, the designer must:-

 Determine the data to be stored in the database.

 Determine the relationships between the different data elements.

Page | 37
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

 Superimpose a logical structure upon the data on the basis of these relationships.

Database name DMUDC.

Table names are the following
No_ Name Type Primary key Foreign key
1 CId Int 
2 Fname Varchar(30)
3 Lname Varchar(30)
4 DeptId Int 
Table 16: Customer table

No_ Name Type Primary key Foreign key

1 HId Int 
2 Fname Varchar(30)
3 Lname Varchar(30)
4 DeptId Int 
Table 17: Head Table

No_ Name Type Primary key Foreign key

1 SRId Int 
2 SId Int 
3 CId Int 
4 SRD Date & time(15)
5 SDD Date & time(15)
Table 18: Service Request Table

Page | 38
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

No_ Name Type Primary key Foreign key

1 SId Int 
2 SType Varchar(30)
3 Service Status Varchar(30)
Table 19: Service Table

No_ Name Type Primary key Foreign key

1 DId Int 
2 Dname Varchar(30)
Table 20: Department Table
3.3. User Interface Design
User interface design or user interface engineering is the design of computers, appliances,
machines, mobile communication devices, software applications, and websites with the focus on
the user's experience and interaction. The goal of user interface design is to make the user's
interaction simple and efficient as possible, in terms of accomplishing user goals—what is often
called user-centered design. Good user interface design facilitates finishing the task at hand
without drawing unnecessary attention to it.The following Fig 3.3 shows User interface design

Page | 39
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

User Interface Design

Homepage

log in

Customer Head Manager Admin Worker

Register worker View customer's

Submit request create account
View Requset status

confirm service Create Account Block account

completion Approve Request
View worked service

check thier status Reject Request Register service Activate account

Figure 12: User Interface Structure

Page | 40
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

3.3.1 User Interface Screen shoots

Figure 13: Homepage Interface

Page | 41
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

Figure 14: Register customer Interface

Page | 42
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

Figure 15: Submit service request Interface

3.4 System Architecture
A system architecture or systems architecture is the conceptual model that defines the structure,
behavior, and more views of a system. An architecture description is a formal description and
representation of a system, organized in a way that supports reasoning about the structures and
behaviors of the system.

Page | 43
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

3.4.1. Deployment Diagram

A UML deployment diagram depicts a static view of the run-time configuration of processing
nodes and the components that run on those nodes. In other words, deployment diagrams show
the hardware for your system, the software that is installed on that hardware, and the middleware
used to connect the disparate machines to one another.

Deployment Diagram

Client side browser Application server MySQl Database server

Submit Request

View Their
Service Request
Status

Approve Request

Security
Request for
Payment

Generate
Report
WebBrowsers

View Customer’s
Status of service

Order for
Payment

View Request

Confirm
Payment

View Report

Figure 16: Deployment Diagram

Page | 44
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

CHAPTER FOUR (4)

4.1. Implementation

Implementation in the system includes implementing the attributes and methods of each object
and integrating all the objects in the system, to function as a single system the implementation
activity spans the gap between the detailed objects designed model and a complete set of source
code file that can be compiled together.

4.1.1. Overview of the programming language used

The project team used PHP programming language to develop this system, since this
programming language is open source, can support all major databases and web browsers. The
project team also used CSS, HTML and JavaScript to develop this system.

4.1.2. Algorithms Used

4.1.2.1. Pseudo code

Pseudo code is compact and informal high-level description of a computer programming

algorithm that uses the structural conventions of a programming language but is intended for
human reading rather than machine reading. Pseudo code typically omits details that are not
essential for human understanding of the algorithm, such as variable declaration, system-specific
code and subroutine. The programming language is augmented with natural language
descriptions of the details, where convenient, or with compact mathematical notation. The
purpose of using pseudo code is that it is easier for humans to understand than conventional
programming language code, and that it is a compact and environment-independent description
of the key principles of an algorithm.

4.1.2.1.1. Pseudo code for Login

Users Involved: Administrator/Customer/Head/Worker/Manager
Load Login Page
Fill the Login Form
Click the Login button
If (Form is filled)
If (valid)
Generate SQL select queries
Connect to database
Pass queries to database
If (any query fails)
Display error message
Else
Page | 45
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

Read session
If session exists on database, user is already logged in,
Display the page
Else
If they're correct
Create session ID
Store session ID on database

Display the page

End if
End if
Else
Display error message
Ask the user to refill the form
End if
End if

4.1.2.1.2. Pseudo code for Logout

Users Involved: Administrator/Customer/Head/Worker/Manager
Logout
- delete database session
- display the home page

4.1.2.1.3. Pseudo code for Search

Users Involved: Administrator/Customer/Head/Worker/Manager
Fill Search form
Click the Search button
If (Form is filled)
If (valid)
Generate SQL select queries
Connect to database
Pass queries to database
If (any query fails)
Display error message
Else
Display result
End if
Else
Display error message
Ask the user to refill the form
End if
Else
Display required field missing message
End if

4.1.2.2. Flow chart

A flowchart is a common type of diagram that represents an algorithm or process showing the
steps as boxes of various kinds, and their order by connecting them with arrows. This
diagrammatic representation can give a step-by-step solution to a given problem. Data is
represented in these boxes, and arrows connecting them represent flow / direction of flow of

Page | 46
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

data. Flowcharts are used in analyzing, designing, documenting or managing a process or

program in various fields.

ActionState1

Open
homepage

Contact the
Have an admin to get
No
account an account
Yes

Login page

Enter
username
and
password

Valid
Yes

Login to the
system

ActionState1

Figure 17: Flowchart Diagram for login

Page | 47
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

4.1.3 Sample code

<?php

session_start();

include("connection.php");

?>

<html>

<head>

<title>

Login Page

</title>

</head>

<body>

<div id="divlogin">

<table height="60px" width="50">

<tr width="30" height="30">

<td width="30" height="30">

<div id="container" style="margin-top: -20px;">

<form action="" method="post">

<fieldset style="height:250; width:230; margin-left:-3px">

<legend align="center">User's Login </legend>

<center><img src="photo/lock.png" height="35%" width="35%" ></center>

<label for="username">Username:</label><br><br><br><br>

<input type="text" id="username" name="username" placeholder="Username"

required><br><br>

<label for="password">Password:</label><br><br><br>

<input type="password" id="password" name="password" required placeholder="******"

required>

<div id="lower"><br><br><br><br>
Page | 48
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

<input type="submit" value="Login" name="login"onClick="clicked(this.form)">

<input type="reset" value="cancel"><br><br><br><br>

<a href="foregotpassword.php">Foregot Password</a>

</div>

</fieldset>

</form>

</div>

</td>

</tr>

</table>

</div>

<?php

if(isset($_POST["login"]))

$un=$_POST["username"];

$password=$_POST['password'];

$passw=md5($password);

if(strlen($password)>5)

if($con)

//account

$sql="select * from createaccount where username='$un' and password='$passw'";

$matchfound=mysqli_query($con,$sql);

if($row=mysqli_fetch_assoc($matchfound))

{
Page | 49
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

$u_id=$row["u_idl"];

$role=$row["role"];

$status=$row["status"];

$ema=$row["E_mail"];

$sqll="select * from users where u_id='$u_id'";

$matchfound1=mysqli_query($con,$sqll);

$row1=mysqli_fetch_assoc($matchfound1);

//{

$u_idl=$row1["u_id"];

$fname=$row1["ufname"];

$mname=$row1["umname"];

$lname=$row1["ulname"];

$role=$row1["role"];

$sqll6="select * from customer where custid='$u_idl'";

$matchfound16=mysqli_query($con,$sqll6);

$row16=mysqli_fetch_assoc($matchfound16);

//{

$custid=$row16["custid"];

$Didc=$row16["deptid"];

//{

$sqll2="select * from dept where Did='$Didc'";

$matchfound11=mysqli_query($con,$sqll2);

$row2=mysqli_fetch_assoc($matchfound11);

$Did=$row2["Did"];

$Dname=$row2["Dname"];

//}
Page | 50
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

$sqll21="select * from depthead where Hid='$Did'";

$matchfound11=mysqli_query($con,$sqll21);

$row3=mysqli_fetch_assoc($matchfound11);

//{

$Didd=$row3["Hid"];

//}

$sql4="select * from service ";

$matchfound4=mysqli_query($con,$sql4);

$row4=mysqli_fetch_assoc($matchfound4);

//{

$sid=$row4["sid"];

$sql4="select * from servicerequist ";

$matchfound4=mysqli_query($con,$sql4);

$row4=mysqli_fetch_assoc($matchfound4);

//{

$Srid=$row4["Srid"];

//}

//session

$fullname=$fname." ".$mname." ".$lname;

$_SESSION['fullname']=$fullname;

$_SESSION['sun']=$un;

$_SESSION['spw']=$password;

$_SESSION['role']=$role;
Page | 51
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

$_SESSION['u_id']=$u_id;

$_SESSION['u_idl']=$u_idl;

$_SESSION['$Dname']=$Dname;

$_SESSION['$Did']=$Did;

$_SESSION['$sid']=$sid;

$_SESSION['$Srid']=$Srid;

$_SESSION['Hid']=$Didd;

$_SESSION['$Didc']=$Didc;

if($role=='head' and $status=="active")

header("location:head.php");

else if($role=='manager' and $status=="active")

header("location:manager.php");

else if($role=='worker' and $status=="active")

header("location:worker.php");

else if($role=='admin' and $status=="active")

header("location:admin.php");

else if($role=='customer' and $status=="active")

header("location:customer.php");

else

echo "Invalid username/password";

else

echo "Invalid username".mysqli_error($con);

}
Page | 52
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

else

echo "please inter greater than 5 character!!!";

?>

</body>

</html>

CHAPTER FIVE (5)

5.1. Testing
Testing is a process of analyzing a system or system component to detect the difference between
specified (required) and observed behavior. The procedures that used are described below.

5.1.1. Unit testing

Unit testing is a software verification and validation method in which a programmer tests if
individual units of source code are fit for use. The duplication center customer service
management system units are tested one by one.

5.1.2. Integration testing

Combining modules and testing them is called integration testing. Integration testing is gradual.
First we test the highest level, or coordinating module, and only one of its subordinate modules.

After unit testing, the duplication center customer service management system is also tested
whether every unit is integrated to each other.

5.1.3. System testing

System testing of software or hardware is conducted a testing on a complete, integrated system to
evaluate the system’s compliance with its specified requirements. It is a testing process in which
the aim is to ensure that the overall system works as defined by the requirements.

 Is a testing process in which the aim is to ensure that the overall system works as defined by the
requirements?
 The duplication center customer service management system is functionally tested based on the
use case model developed during the analysis phase.

Page | 53
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

 The duplication center customer service management system also operationally tested based on
requirements.

5.1.4. Performance Testing

Determines how the system performs on the range of possible environments in which it may be
used. Often the goal is to have the system perform with similar response time and other
performance measures in each environment

The implementation of the duplication center customer service management system is done by
decomposing the system into different subunits that handle different tasks.

Each components of the system is tested independently with the intention that it should meet the
functionalities expected.

CHAPTER SIX (6)

6.1. Conclusion and Recommendations

6.1.1. Conclusion
The project is aimed at developing a web based duplication center customer service management
system.

In chapter one the team determined the title of the project to “Duplication center customer
service management system”. Then the team described the background of the center with the
explanation of how the organization is established, the objective of the project, the scope and
limitation of the project, significance of the project, feasibility and breakdown of the structure
have been discussed including the methodology of the project which describes what and which
material the team used to accomplished the proposed system.

In Chapter two the team performed a detailed business area analysis that describes what the
current system looks like. We used an essential use case by identifying actors and use cases.
After business area analysis we determined the requirements of the proposed system in terms of
functional and non-functional requirements. After these the team has studied object oriented
analysis and design techniques like activity diagram, sequence diagram, class diagram with
relations, attributes and methods.

The third chapter of the project discussed about the system design which tries to change the
conceptual model of information for the problem domain that rose on the chapter one of the
existing system and solve that problem into actual interface. To accomplish this, the team used

Page | 54
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

different types of designing and analysis tools like design class diagram, physical database
design, and user interface.

6.1.2. Recommendation and Future Enhancement

Our system is a web based system; we recommend that persons who want to develop application
on duplication center customer service management system develop mobile based application.
Also we use only English languages; we recommend that people who want to develop an
application in this area use many languages such as Amharic, oromic, Tigrigna, etc. Also we
recommend that delivering notification in mobile phone.

Page | 55
 DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C

Reference
(1)http://www.ambysoft.com/essays/userInterfacePrototyping.html
(08/01/2018 21:00)

(2)http://en.wikipedia.org/wiki/Activity_diagram(21/12/2017 16:00)

(3)http://en.wikipedia.org/wiki/Class_diagram(01/01/2018 18:00)

(4)http://en.wikipedia.org/wiki/Sequence_diagram(14/12/2017 20:00)

(5)https://en.wikipedia.org/wiki/Deployment_diagram(16/01/2018 22:00)

(6)http://www.dmu.edu.et(05/11/2017 21:40)

(7)[Hoffer 2000] Modern System Analysis and Design (Jeffery A. Hoffer fred R.
Mcfaddan)
(8)[Whitten] System Analysis and Design Methods (Jeffery l. Whitten and Loinnie D.
Bentley)
(9)[Castro] Information Systems Analysis and Design. (Jolson Castro and Mylopoulo)

Page | 55