DEBRE MARKOS UNIVERSITY DUPLICATION CENTER

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

Page | i

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 | ii

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 | iii

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 | iv

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 | v

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 | vi

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 | vii

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 | viii

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 | ix

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 | x

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 | 1

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 | 2

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 | 3

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 | 4

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 | 5

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 | 6

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 | 7

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 | 8

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 | 9

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 | 10

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 | 11

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 | 12

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 | 13

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

http://en.wikipedia.org/wiki/Requirement

http://en.wikipedia.org/wiki/Functional_requirements

http://en.wikipedia.org/wiki/Functional_requirements

http://en.wikipedia.org/wiki/Constraints


Page | 14

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:-

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.

Actor

1. Customers

2. Head

3. Worker

4. Manager

5. Administrator

Use case Name ID Include

Login UC1


Page | 15

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 | 16

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 | 17

Send service

request

Cancel service

request

Approve service

Request

Login

Logout

Generate report

Manager

Head

Worker

Customer

{includes}

{includes}

{includes}

{includes}

{includes}

{includes}

{exclude}

{includes}

View customer's

status

Give feedback

{includes}

{includes}

View Report

Reject service

request

{includes}

{includes}

Confirm service

completion

Check service

request status

Register worker

{includes}

Admin

View feedback

Register customer

{includes}

Create account

Block account

{includes}

{includes}

Activate account

{includes}

View Worked service

«extends»

{includes}

View service

request

{includes}

Register complain{includes}

{includes}

{includes}

View complain

Update

View

Register Service

{includes}

{includes}

{includes}

Fetch file

{}

Log File

Figure 1: System use case diagram


Page | 18

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.

3. User fills user name and

password and then click login

button.

6. Use case ends.

2.The System displays Login

page

4. The system validates the

entered information.

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 | 19

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

3.The head enters his/her

username and password

6. The head click register

link and fill customers profile

8. The head click register

button.

2. System displays the log in

page.

4. System validates

information’s provided by the

head.

5.The head page displayed

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 | 20

action 1. The customer open the system

3.The customer fill his/her username

and password

6. Customers fill their service request

form.

8. Customers submit their service

request to their head.

2. System displays the log in page.

4. System validates information’s

provided by the customer.

5.The customer page displayed

7.form validates the provided service

request information

9. End of use case.

Alternative course

of action

If the filled service request format step 3 above is invalid, The system displays

“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

the system

2.the system display login page


Page | 21

3. The Head, Admin, Manager, fill their


5. The Head, Admin, Manager, click

view report link.

4. System validates

information’s provided by the

user.

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

action

User Action System Response

1. Head open the system.

3. Head fill his/her user name and

password.[A1]

6. Head clicks view report link and

view customers that ask request.

7.approve customer’s service request-

2.Login page displayed

4.System validate the provided


5.Head page displayed

8. End of use case.


Page | 22

Alternative

course of action

login detail is incomplete or mismatch at step 2 above,

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 | 23

Figure 2: Sequence diagram for login


Page | 24

Figure 3: Sequence diagram for registering customers


Page | 25

Figure 4: Sequence diagram for submitting service request


Page | 26

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 | 27

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.

http://pic.dhe.ibm.com/infocenter/rsarthlp/v8r5/topic/com.ibm.xtools.modeler.doc/topics/cacts.html

http://pic.dhe.ibm.com/infocenter/rsarthlp/v8r5/topic/com.ibm.xtools.modeler.doc/topics/cactions.html


Page | 28

Display UserpageDisplay error messageInvalid valid

Activity diagram for login

Click login

Enter PasswordEnter username

Log in Page

Login controller

Figure 6: Activity diagram for login


Page | 29

Login page

Display error

message

Fill customers profile

System displays

successful message

Valid

Click Register buttonInccorrect correct

Display Error Message

Activity diagram for Registering customers

Enter passwordEnter Username

Click Login

Userpage Displays

Form validation

Login controller

Invalid

Figure 7: Activity diagram for registering customer


Page | 30

Login page

Display error

message

Fill service request form

System displays

successful message

Valid

Click submit buttonInccorrect correct

Click Reject button

Activity diagram for submitting customer service request


Click Login

Userpage Displays

validate

Login controller

Invalid

Figure 8: Activity diagram for submitting customer service request


Page | 31

Login page

Display error

message

View service request form

System displays

successful message

Valid

Click approve buttonInccorrect

correct

Click Reject button

Activity diagram for approving customer service request


Click Login

Userpage Displays

validate

Login controller

Invalid

Figure 9: Activity diagram for approving customer service request


Page | 32

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 | 33

Analysis Class Diagram

+Register customer:()

+Create account()

+Update Account()

+Update Customer()

-DId:

Head

+Create()

+Block()

+Activate()

+Update account()

Admin

+View thier status()

+Confirm service completion()

-DId:

Customer

+generate report()

+Register worker()

+Register service()

+Update worker()

+Create account()

+Update account()

Manager

+Login()

-UserId:

-Username:

-Password:

-Role:

-Date:

-Status:

Account

+Approve()

+View()

+Reject()

+cancel()

+submit()

-SRD:

-SDD:

-SRId:

-SRName:

-CId:

-SId:

Service Request

-DId:

-Dname:

Department

+Give()

+View()

-CId:

Feedback

1

*

1

1

Manage*

*

1

1

1

1

1

* View

*

*

Submit

1

*

Has

*

*

Give

1

1

-Sid:

-SName:

-Status:

Service

*

1

**

11

-Id:

-Fname:

-Lname:

-Sex:

-Phone no-:

User

*

*

Request

Inherite

InheriteInherite

1

1

Register

+View customer status()

+View worked service()

Worker

*

*

*

*

+Give()

+View()

-CId:

-Description:

Complain

*

*

**

Request

Figure 10: Analysis Class diagram


Page | 34

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 | 35

Design Class Diagram

+Register customer:()

+Create account()

+Update account()

+Update customer()

-DId:Int(10)

Head

+Create()

+Block()

+Activate()

+Update account()

Admin

+View thier status()

+Confirm service completion()

-DId:Int(10)

Customer

+generate report()

+Register worker()

+Register service()

+Create account()

+View Feedback()

+View Complain()

+Update worker()

+Update account()

Manager

+Login()

-UserId:varchar(20)

-Username:varchar(20)

-Password:Int

-Role:varchar(20)

-Date:date&time

-Status:varchar(20)

Account

+Approve()

+View()

+Reject()

+cancel()

+submit()

-SRD:Date & time(15)

-SDD:Date & time(15)

-SRId:Varchar(20)

-SRName:Varchar(20)

-CId:Int

-SId:Int

Service Request

-DId:Int

-Dname:Varchar(20)

Department

+Give()

+View()

-CId:Varchar(20)

Feedback

1*

1

1

Manage

*

*

1

1

1

1

1

*

View

*

*

Submit1

*

Has

*

*

Give

1

1

-Sid:Int(10)

-SName:Varchar(20)

-Status:varchar(10)

Service

*

1

*

*

-Id:Int(10)

-Fname:Varchar(20)

-Lname:Varchar(20)

-Sex:Varchar(10)

-Phone no-:Int

User

*

*

Request

Inherite

Inherite

Inherite

1

1

Register

+View customer status()

+View Worked service()

Worker

*

*

*

**

*

+Give()

+View()

-CId:Varchar(20)

Complain

*

*

**

*

*

Figure 11: Design Class diagram


Page | 36

3.1.1 Class Diagram Description

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


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


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


Customer Id Uniquely identify the customer Varchar

Customer Fname The forename of the customer Varchar

Customer Lname The father name of the customer Varchar


Page | 37


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


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 | 38

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


1 HId Int

2 Fname Varchar(30)

3 Lname Varchar(30)

4 DeptId Int

Table 17: Head Table


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 | 39


1 SId Int

2 SType Varchar(30)

3 Service Status Varchar(30)

Table 19: Service Table


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

http://en.wikipedia.org/wiki/Computer

http://en.wikipedia.org/wiki/Home_appliance

http://en.wikipedia.org/wiki/Communication

http://en.wikipedia.org/wiki/Software

http://en.wikipedia.org/wiki/Website

http://en.wikipedia.org/wiki/User_experience

http://en.wikipedia.org/wiki/User-centered_design


Page | 40

User Interface Design

Homepage

log in

HeadCustomer Manager Admin Worker

Submit request

confirm service

completion

check thier status Reject Request

Approve RequestCreate Account

View RequsetRegister worker create account

Block account

Activate account

View customer's

status

Register service

View worked service

Figure 12: User Interface Structure


Page | 41

3.3.1 User Interface Screen shoots

Figure 13: Homepage Interface


Page | 42

Figure 14: Register customer Interface


Page | 43

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 | 44

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

WebBrowsers

Approve Request

Request for Payment

View Customer’sStatus of service

Order forPayment

ConfirmPayment

Submit Request

Security

View Report

Generate Report

View Request

View TheirService Request

Status

Figure 16: Deployment Diagram


Page | 45

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 | 46

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


Ask the user to refill the form

End if

End if

4.1.2.1.2. Pseudo code for Logout


Logout

- delete database session

- display the home page

4.1.2.1.3. Pseudo code for Search


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)


Else

Display result End if

Else


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 | 47

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

program in various fields.

Open

homepage

Have an

account

Contact the

admin to get

an account

Login page

Enter

username

and

password

Valid

Login to the

system

No

Ye

sY

es

ActionState1

ActionState1

Figure 17: Flowchart Diagram for login


Page | 48

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 | 49

<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 | 50

$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);


//{

$custid=$row16["custid"];

$Didc=$row16["deptid"];

//{

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



{

$Did=$row2["Did"];

$Dname=$row2["Dname"];

//}


Page | 51

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



//{

$Didd=$row3["Hid"];

//}

$sql4="select * from service ";

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


//{

$sid=$row4["sid"];

$sql4="select * from servicerequist ";

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


//{

$Srid=$row4["Srid"];

//}

//session

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

$_SESSION['fullname']=$fullname;

$_SESSION['sun']=$un;

$_SESSION['spw']=$password;

$_SESSION['role']=$role;


Page | 52

$_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 | 53

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.

http://en.wikipedia.org/wiki/Source_code


Page | 54

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 | 55

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

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)

http://www.ambysoft.com/essays/userInterfacePrototyping.html

http://en.wikipedia.org/wiki/Activity_diagram

http://en.wikipedia.org/wiki/Class_diagram

http://en.wikipedia.org/wiki/Sequence_diagram

https://en.wikipedia.org/wiki/Deployment_diagram

http://www.dmu.edu.et/

Documents

DEBRE MARKOS UNIVERSITY DUPLICATION CENTER