debre markos university duplication center
TRANSCRIPT
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_____________
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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-------------------
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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!!
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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.
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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.
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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.
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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.
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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.
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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.
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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.
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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.
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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.
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
Page | 21
3. The Head, Admin, Manager, fill their
username and password
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
username and password
5.Head page displayed
8. End of use case.
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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.
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
Page | 23
Figure 2: Sequence diagram for login
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
Page | 24
Figure 3: Sequence diagram for registering customers
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
Page | 25
Figure 4: Sequence diagram for submitting service request
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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.
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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.
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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
Enter passwordEnter Username
Click Login
Userpage Displays
validate
Login controller
Invalid
Figure 8: Activity diagram for submitting customer service request
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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
Enter passwordEnter Username
Click Login
Userpage Displays
validate
Login controller
Invalid
Figure 9: Activity diagram for approving customer service request
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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.
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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.
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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
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
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
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
Page | 37
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.
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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
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
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
Page | 39
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
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
Page | 41
3.3.1 User Interface Screen shoots
Figure 13: Homepage Interface
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
Page | 42
Figure 14: Register customer Interface
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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.
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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
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
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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>
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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))
{
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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);
$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"];
//}
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
Page | 51
$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;
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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);
}
}
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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.
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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.
DEBRE MARKOS UNIVERSITY DUPLICATION CENTER 2010 E.C
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)