Automated Expert System For Ambulance Management In Arba A Senior Project

ARBA MINCH UNIVERSITY
ARBA MINCH INSTITUTE OF TECHNOLOGY
Automated Expert System for Ambulance Management in Arba
Minch Hospital
Group Members
Name ID
Debalkew Geremew…….………………….RNS/276/04
Demeke Asratie…………….………………RNS/287/04
Shimeles Derjew …………………………...RNS/740/04
Merhawit Abrha………………………….....RNS/601/04
Zelalem Emiru……………………………....RNS/947/04
Advisor name: - Dr.Arun Kumar
Examiner name:-
A Senior Project
Submitted to Department of Computer Science and IT, Institute of Technology, Arba Minch
University, in Partial fulfillment for the requirement of the Degree of Bachelor Science in
Computer Science.
Arba Minch, Ethiopia
01st
June 2015

Automated Expert System for Ambulance Management in Arba Minch Hospital [2015]
Final Year Project CSIT i
Arba Minch University
Arba Minch Institute of Technology (AMiT)
Approval Sheet
--------------------------------------------------------------------------------------------------
This is to certify that the senior project titled “Automated Expert System for Ambulance
Management in Arba Minch Hospital (AESAMAH)” Submitted by
Debalkew Geremew…….………………….RNS/276/04
Demeke Asratie…………….………………RNS/287/04
Shimeles Derjew …………………………...RNS/740/04
Merhawit Abrha………………………….....RNS/601/04
Zelalem Emiru……………………………....RNS/947/04
To the department of Computer Science and Information Technology, Arba Minch for the partial
fulfillment of the requirement of the Degree of Bachelor Science in Computer Science, is a bona
fide record of the project done by them under my supervision. The contents of this document in
full, or in parts, have not been submitted to any other institute or university for the award of any
degree or diploma.
Dr.Arun Kumar
(Guide)
Date: 01st
June 2015
Arba Minch

Final Year Project CSIT ii
Acknowledgement
First of all we would like to thank GOD keeping us healthy. Lots of problems have overcome
with the assistance of GOD. Without his will nothing could be done. We have taken efforts in
this project. And also thank our Advisor Dr. Arun for all his support with this project. We have
learnt a lot from Dr. Arun, how to work hard and getting right results. Dr. Arun always has time
for our questions and his comments on our thesis have been valuable. We are also thankful to our
project coordinator Hayileyesus and Bekila. In addition to this we wish to thank our friends for
supporting us in many ways. Last but not least, we are deeply grateful to our family supported in
many ways. Lastly, our thanks‟ and appreciation also go to AMIT, Department of Computer
Science and Information Technology in developing the project and people who have willingly
helped us out with their talents.
Debalkew Geremew
Demeke Asratie
Shimeles Derjew
Merhawit Abrha
Zelalem Emiru

Final Year Project CSIT iii
ABSTRACT
Expert system is a system that gives a decision automatically. It developed by various experts
clearly indicates that different software‟s were used to develop computer based expert system for
different applications. We can apply this knowledge in various application domains. Our system
deliberates about the development of Automated Expert System for Ambulance Management in
Arba Minch hospital (AESAMAMH). The patient can call to the expert system (AESAMAMH)
by using specific caller number; system will take some decisions to deliver the ambulances.
Automated expert system is retrieving the patient information like name, address, from the
database automatically. After identified the patient information, system will be checked the
availability of ambulances in hospital. Then, automatically system will send SMS to particular
ambulance driver mobile phone immediately.

Final Year Project CSIT iv
TABLE OF CONTENTS
Content Page No
Acknowledgement ..........................................................................................................................ii
ABSTRACT...................................................................................................................................iii
LIST OF TABLES.......................................................................................................................viii
LIST OF FIGURES ....................................................................................................................... ix
ABBREVIATION.......................................................................................................................... xi
CHAPTER ONE............................................................................................................................. 1
1.1 Introduction........................................................................................................................... 1
1.2 Background Information of the Organization ....................................................................... 1
1.3 Background of the Project..................................................................................................... 1
1.4 Statement of the problem ...................................................................................................... 2
1.5 Team composition................................................................................................................. 3
1.6 Objective of the Project......................................................................................................... 3
1.6.1 General Objective........................................................................................................... 3
1.6.2 Specific Objective .......................................................................................................... 3
1.7 Feasibility Analysis............................................................................................................... 4
1.7.1 Technical Feasibility ...................................................................................................... 4
1.7.2 Operational Feasibility ................................................................................................... 4
1.7.3 Economic Feasibility...................................................................................................... 4
1.7.4 Behavioral Feasibility..................................................................................................... 4
1.8 Scope of the Project.............................................................................................................. 5
1.9 Significance of the Project .................................................................................................... 5
1.10 Target Beneficiaries of the System ..................................................................................... 6

Final Year Project CSIT v
1.11 Overview of the System...................................................................................................... 6
1.12 Methodology ....................................................................................................................... 7
1.12.1 Fact-finding techniques................................................................................................ 7
1.12.2 Systems Analysis and Design...................................................................................... 7
1.12.3 Development Tool/ Program........................................................................................ 7
1.12.4 Requirement Structuring and Data Modeling Tools .................................................... 8
1.12.5 Required Resources with Costs.................................................................................... 9
1.13 Limitation of the project………………………………………………..……………………9
CHAPTER TWO .......................................................................................................................... 10
2. DESCRIPTION OF THE EXISTING SYSTEM ..................................................................... 10
2.1 Introduction to the Existing System.................................................................................... 10
2.2 Players of the Existing System............................................................................................ 10
2.3 Major Functions/Activities in the Existing System............................................................. 10
2.4 Business Rule...................................................................................................................... 11
2.5 Report Generated In the Existing System ........................................................................... 11
2.7 Bottleneck of the Existing System ...................................................................................... 11
2.7.1 Performance.................................................................................................................. 11
2.7.2 Security and Controls ................................................................................................... 11
2.7.3 Efficiency ..................................................................................................................... 11
2.8 Practices to be preserved..................................................................................................... 12
2.9 Proposed Solution for Existing System............................................................................... 12
2.10 Requirements of the Proposed System.............................................................................. 12
2.10.1 Functional Requirements............................................................................................ 12
2.10.2 Non Functional Requirements.................................................................................... 13

Final Year Project CSIT vi
CHAPTER THREE: SYSTEM ANALYSIS................................................................................ 14
3.1 Introduction......................................................................................................................... 14
3.2 System Requirement Specifications (SRS)......................................................................... 14
3.2.1 Use Case Diagram........................................................................................................ 15
3.2.2 Use Case Documentation ............................................................................................. 16
3.2.3 Sequence Diagram........................................................................................................ 25
3.2.4 Activity Diagram.......................................................................................................... 34
3.2.5 Analysis level class diagram ........................................................................................ 39
3.2.6 User Interface Prototype............................................................................................... 40
CHAPTER FOUR: SYSTEM DESIGN....................................................................................... 41
4.1 Introduction......................................................................................................................... 41
4.2 Class Type Architecture...................................................................................................... 41
4.3 Class Modeling.................................................................................................................... 43
4.4 State Chart Modeling .......................................................................................................... 44
4.5 Collaboration Modeling ...................................................................................................... 46
4.6 Component Modeling.......................................................................................................... 48
4.7 Deployment Modeling........................................................................................................ 49
4.8 Persistence Data Modeling.................................................................................................. 50
4.9 User Interface design sample .............................................................................................. 51
CHAPTER FIVE: TESTING AND IMPLEMENTATION ........................................................ 55
5.1 Coding................................................................................................................................. 55
5.2 Finale Testing of the system................................................................................................ 62
5.2.1 Unit Testing.................................................................................................................. 67
5.2.2 Integration Testing ....................................................................................................... 68

Final Year Project CSIT vii
5.2.3 Acceptance Testing ...................................................................................................... 68
5.2.4 System Testing ............................................................................................................. 69
5.3 Hardware and Software Acquisitions.................................................................................. 69
5.3.1 Hardware &Software Configuration ............................................................................ 70
5.4 Installation/Integration ........................................................................................................ 70
5.5 User Manual Preparation..................................................................................................... 70
5.6 Training............................................................................................................................... 70
5.7 Installation Process.............................................................................................................. 70
5.8 Start-up strategy .................................................................................................................. 71
CHAPTER 6 : CONCLUSION and RECOMMENDATION ...................................................... 72
6.1 Conclusion........................................................................................................................... 72
6.2 Recommendations............................................................................................................... 73
APPENDIX................................................................................................................................... 74
REFERENCES ............................................................................................................................. 75

Final Year Project CSIT viii
LIST OF TABLES
Table 1 Team composition............................................................................................................................3
Table 2 Project Schedule ..............................................................................................................................5
Table 3: Software requirement......................................................................................................................8
Table 4: Required Resources with Cost........................................................................................................9
Table 5 Use Case Documentation for Login...............................................................................................16
Table 6 Use Case Documentation for View Message.................................................................................17
Table 7 Use Case Documentation for Send Request ..................................................................................18
Table 8 Use Case Documentation for Register...........................................................................................19
Table 9 Use Case Documentation for Generate Message...........................................................................20
Table 10 Use Case Documentation for Generate Report...........................................................................21
Table 11 Use Case Documentation for Manage Ambulance......................................................................22
Table 12 Use Case Documentation for Manage User.................................................................................23
Table 13 Use Case Documentation for View User Information.................................................................24
Table 14 Class type architecture description ..............................................................................................42
Table 15Test case for login.........................................................................................................................63
Table 16 Test Case for change password....................................................................................................64
Table 17 Test case Send request .................................................................................................................66
Table 18 Send request test specification.....................................................................................................67
Table 19 Login test specification................................................................................................................68
Table 20 User registration test specification...............................................................................................68
Table 21 Hardware &Software Configuration............................................................................................70

Final Year Project CSIT ix
LIST OF FIGURES
Figure 1 Overview of Automated Expert System.........................................................................................6
Figure 2 Use case diagram..........................................................................................................................15
Figure 3 Sequence diagram for Login.........................................................................................................25
Figure 4 Sequence diagram for Register.....................................................................................................26
Figure 5 Sequence diagram for Manage Ambulance..................................................................................27
Figure 6 Sequence diagram for Manage User.............................................................................................28
Figure 7 Sequence diagram for Generate Message.....................................................................................29
Figure 8 Sequence diagram for View User Information.............................................................................30
Figure 9 Sequence diagram for Send request..............................................................................................31
Figure 10 Sequence diagram for View Message.........................................................................................32
Figure 11 Sequence diagram for Generate Report......................................................................................33
Figure 12 Activity Diagram for Login........................................................................................................34
Figure 13 Activity Diagram for Register ....................................................................................................34
Figure 14 Activity Diagram for View Message..........................................................................................35
Figure 15 Activity Diagram for Send Request............................................................................................35
Figure 16 Activity Diagram for Manage Ambulance .................................................................................36
Figure 17 Activity Diagram for Generate Message....................................................................................36
Figure 18 Activity Diagram for Manage User............................................................................................37
Figure 19 Activity Diagram for View User Information ............................................................................38
Figure 20 Analysis level class diagram.......................................................................................................39
Figure 21 User interface prototype .............................................................................................................40
Figure 22 Class a type architecture diagram...............................................................................................41
Figure 23 Design class diagram..................................................................................................................43

Final Year Project CSIT x
Figure 24 State chart diagram for login: .....................................................................................................44
Figure 25 State chart diagram for manage user: .........................................................................................44
Figure 26 State chart diagram for send request...........................................................................................45
Figure 27 State chart diagram for manage Ambulance...............................................................................45
Figure 28 Collaboration diagram for registration: ......................................................................................46
Figure 29 Collaboration diagram for view message:..................................................................................46
Figure 30 Collaboration diagram for manage ambulance...........................................................................47
Figure 31 Collaboration diagram for manage send request ........................................................................47
Figure 32 Component diagram ...................................................................................................................48
Figure 33 Deployment modeling diagram ..................................................................................................49
Figure 34 Persistence diagram....................................................................................................................50
Figure 35 User interface Ambulance Registration Form ............................................................................51
Figure 36 User interface Home page ..........................................................................................................51
Figure 37 User interface for generate report page ......................................................................................52
Figure 38 User interface User registration..................................................................................................53
Figure 39 User interface send request.........................................................................................................53
Figure 40 User interface send request.........................................................................................................54
Figure 41 Ambulance phone receive form..................................................................................................74
Figure 42 Ambulance day to day service control form...............................................................................74

Final Year Project CSIT xi
ABBREVIATION
AMH Arba Minch Hospital.
AESAMAMH Automated Expert System for Ambulance Management in Arba Minch
hospital
AESAM Automated Expert System for Ambulance Management
DB Database
OOA Object Oriented Analysis
OOD Object Oriented Design
OODM Object Oriented Design Methodology
SMS Short Message System
SQL Structured Query Language
UI User Interface
UML Unified Modeling Language
VPS Visual Paradigm Suite

Final Year Project CSIT 1
CHAPTER ONE
1.1 Introduction
An expert system for health care management is caused to automated knowledge-based data used
in the field of health care. A healthy expert system provides input scenarios, problem solving
mechanisms and output data based on a review of common practices and hospital support
functions. Expert systems can also match human behavior and logic designs to answer questions
or solve problem. Expert system consists of large databases of information with various
components integrated into system package. Our system is used to find automatically the patient
address from database by using their phone number and automatically inform (send message) to
ambulance driver where incident occurred. Ambulance driver go to the incident site depend on
the information.
1.2 Background Information of the Organization
Arba Minch Hospital is a regional hospital. It is basically acting like a referral hospital for a large
area around it. The manager told us it serves an area of about 8.5 million people, and actually
sees over 100,000 patients per year. Even though they serve so many patients, they only have 5
specialists and also have only one ambulance. They have one other surgeon and a gynecologist,
and the last remaining surgeon is planning to leave soon. Though they have 4 operating rooms,
there is only one especial machine. The hospital was originally built to house 50 beds but has
now expanded to 300 beds. Yet, they only have one working autoclave, one laundry machine,
one suction machine, and one oxygen concentrator, according to the manager.
1.3 Background of the Project
Arba Minch Hospitals has many facilities and services to assist peoples to get good medical
facilities. Ambulance service helps many people for serious or life-threatening conditions. And
also provide a range of other urgent and planned health care and transport services. Ambulance
group can include a range medical staff, such as emergency care particular work and medical
work. Ambulance is equipped with a variety of emergency care equipment, such as heart
defibrillators, oxygen, intravenous drips, spinal traction splints, fire accident, car emergency and
also difference incidents. The Patient can call to the ambulance manager, if they need ambulance

services. However, ambulance manager inform to ambulance driver and sends ambulance to
incident sit.
Our project is to develop a new automated expert system to facilitate user request to get
ambulance service. It gives a decision automatically and makes easier way for the patient to use
ambulance services in Arba Minch Hospital. In this system main issues are to find availability of
ambulances in hospital, identify the location of incident places and send ambulance to the
incident location automatically. The system also used to store the patient and ambulance driver
information in the database and generates report. In addition to this our system provides only for
the people who live in Arba Minch town.
1.4 Statement of the problem
Ambulance services help many people with serious or life threatening conditions. They also
provide a range of other urgent and planned health care and transport services. But the manual
ambulance system is not giving this service.
 The patient information or data mismatch and lost. i.e. not store in the database.
 The patient difficult to get the ambulance service on time if they need due to the manpower,
unavailability ambulances, lack of information and accessibility.
 People will not be known detail information about ambulance service.
 difficult for ambulance driver to reach the patient address or incident area and
 Due to unavailability and unreliability of ambulances, people may loss their life.

1.5 Team composition
Table 1 Team composition
1.6 Objective of the Project
1.6.1 General Objective
The general objective of this project is to change the current manual system to AESAM in Arba
Minch Hospital.
1.6.2 Specific Objective
To achieve the above general objective, the project addressed the following specific objectives.
The system provides the following:-
 Review, analyze and study the current ambulance management system.
 Analyze and organize gathered information in such a way that it will be used to design
the new system.
 collect data that is used to develop automated expert system and study an automated
expert system.
 Design and develop the automated expert system.
 Design and implement a database for proper implementation of the system.
Student Name Id Number Email Responsibility
Debalkew Geremew RNS/276/04 Debalkew.g@gmail.com Manager & Programmer
Shimeles Derjew RNS/740/04 Shimeles740@gmail.com Programmer& Designer
Demeke Asiratie RNS/287/04 Asratie4@gmail.com System Analyst & Data collector
Merhawit Abrha RNS/601/04 Merigirl36@gmail.com Designer & System Analyst
Zelalem Emiru RNS/947/04 Zelalem.Emiru@gmail.c
om
Data collector &Time Keeper
Adviser Dr.Arun Kumar

 Store & manage patient and ambulance information in the database.
 Retrieve the patient information from database and send their information to ambulance
driver.
 Increase accessibility and availability of ambulance service in the hospital.
1.7 Feasibility Analysis
1.7.1 Technical Feasibility
The system is measure the practicality of a specific technical solution and the availability of
technical resources and expertise. The system has technological or a solution for practical. Also
mature for the technology.
1.7.2 Operational Feasibility
Proposed applications are beneficial only if they can be turned into user friendly that meet the
users‟ requirements. Simply stated, this test of feasibility asks if the application will be worked
when it is developed. Therefore, the system will be designed to be operationally feasible. That
means, the system will operate without failure. B/c of it is simplicity and easy access. In addition
to this the system is practical, applicable and also the system operation is easy for the users.
1.7.3 Economic Feasibility
Economic feasibility attempts to weight the costs of developing and implementing a new system,
against the benefits that would occur from having the new system in place. This feasibility study
gives the top management the economic justification for the new system. the system is Economic
feasible.
1.7.4 Behavioral Feasibility
The proposed system is behaviorally feasible and cannot cause any harm in the environments.
The project would be beneficial because it satisfies the need of the customer. The system act as
user friendly and improves the working environment.
1.7.5 Schedule Feasibility
The proposed system can be implemented in an acceptable timeframe given below. Project
manager is also responsible for monitoring & controlling the project development based on the
schedule shown below.

Table 2 Project Schedule
1.8Scope of the Project
The scope of this project is to develop and implement AESAM in Arba Minch Hospital. This
project will overcome the problems associated with the manual system. User can register the user
information, manage ambulance availability, send patient information to driver, generating
reports, maintain the patient information and the ambulance information and get feedback from
users in Automated Expert System.
1.9 Significance of the Project
The significances of this project are:-
 Transport safely and comfortably as soon as possible, wounded and sick persons to a
place where they can receive the emergency medical.
 Reduce the loss of human life.
 To reducing delays that currently contribute to feeling and newborn child, mortality and
disease.
 To serve the society in well way to save some one life in our living time.
 To provide fastest ambulance service to the victims of any emergency incidents.
 Easy to Finding the site of the incident area & ambulance location.

 Choosing the nearest ambulance to handle an emergency incident.
 One of the most important responsibilities of public safety is efficient and effective
emergency transport and care system.
1.10 Target Beneficiaries of the System
There are different bodies that will be benefited from this system. The main beneficiaries of this
system include:
 Arba Minch Hospital.
 Ambulance driver
 People.
1.11 Overview of the System
The new system will be used by the dispatcher to handle the dispatching operation. The system
allows dispatching the ambulances and also finds the patient location. Major high level functions
of the system are described in the following section.
Figure 1 Overview of Automated Expert System

1.12 Methodology
1.12.1 Fact-finding techniques
To gather data from the different users and ambulance workers of the existing system the team
used the following techniques.
Interview:-We orally discussed and interviewed some patients and hospital workers related to
ambulance service in Arba Minch Hospital. This methodology helps to identify the problems and
also to understand the current system. So, we analyzed the information of the ambulance
management and obtained some basic concepts on how the ambulance is managed in the current
system.
Observation: - We use this method to get the right information about the organization and also
to understand how the existing system works.
Document: -To get more secondary source information and ideas about the expert system,
project report documents and other reading materials that were needed to develop this system.
1.12.2 Systems Analysis and Design
Among the different methodologies available we plan to use the object oriented system
development methodology for the development of our system. The team will use object oriented
system development methodology. This methodology is used for simplicity, increased quality,
faster development, code reusability and maintainability of the system. OOSDM has two phases.
OOA Phase
During this phase the team will model the functions of the system (use case modeling), Find and
identify the business objects, Organize the objects and identify the relationship between them
and finally model the behavior of the objects.
OOD phase
During this phase the team will refine the use case model to reflect the implementation
environment, model object interactions and behaviors that support the use case scenario, and
finally update object model to reflect the implementation environment.
1.12.3 Development Tool/ Program
The programming tools that the project concentrates are the following:

Software requirements and its environment
Activities Tools/Programs
Platform MS windows 7
Database Server SQL server
Web Server Apache (IIS)
Coding Language C#
Browsers IE ,Mozilla Firefox, Google Chrome
Documentation MS Word
Prepare presentation MS PowerPoint
Modeling and Scheduling Visual Paradigm suite 5
Table 3: Software requirement
Hardware requirements
 Dell Computer core i3.
 Hard disk: - 456 GB.
 Processor:-Intel(R) core(TM) 2 Duo CPU. Speed 3.06GHz
 RAM: - 4.00GB.
 Pen Drive 8.00GB.
1.12.4 Requirement Structuring and Data Modeling Tools
Meanwhile in the team is being using an object oriented system development methodology, for
structuring requirements and for modeling the data the team used Unified modeling language
(UML). The team used UML diagrams for requirements structuring as well as data modeling.

1.12.5 Required Resources with Costs
Table 4: Required Resources with Cost
1.13 Limitation of the project
 SMS can not send from mobile to application.
 The system depends on electrical power and network connection.
 The employees who work in Arba Minch hospital they cannot give full information about
the ambulance management.
Item Unit Quantity Unit Price(ETB) Total Price(ETB)
Dell Computer core i3 Number 2 9,000.00 18,000.00
Paper Pack 1 145.00 145.00
Pen Pack ½ 4.00 125.00
Print paper Number 1 1.50 267
Pen Drive Number 3 200 600.00
CD Number 3 10 30.0
Mobil phone Number 5 1500 7000
Total cost 26,167.00

CHAPTER TWO
2. DESCRIPTION OF THE EXISTING SYSTEM
2.1 Introduction to the Existing System
This chapter describes about the existing system for Ambulance Management in Arba Minch
Hospital. When the patient needs ambulance service they call by their mobile phone to the
hospital. The Patient information store in a paper manually and also ambulance management in
Arba Minch hospital is not used a computerized system.
2.2 Players of the Existing System
The actors in the current system are:-
 Ambulance Manager: - Someone who can manage over all activity for ambulance
management.
 Ambulance Driver: - Someone who can transport user from incident site to hospital.
 Users/Patients: - Someone who can beneficiaries of Ambulance service and he/she live in
Arba Minch town.
2.3 Major Functions/Activities in the Existing System
The following section will summarize the function of existing system with their input, process
and output.
Manage ambulance
 Input:- Status of Ambulance.
 Process:- Arrange ambulance.
 Output:- Generate report for ambulance status, information.
Patient transport
 Input:- patient (incident) location information.
 Process:- go to incident site.
 Output:- Save human life i.e. Transport patient to hospital.
Record patient information
 Input:- Patient detail information and incident information.
 Process:-Ask patient about their information.

 Output:- Store information in record class.
2.4 Business Rule
 Emergency occurred: - Urgent situation exist or be found to be present in a place or
under a particular set of conditions.
 Users know ambulance service phone number: - To get ambulance service during
occurrences of emergency or any challenge.
 Know incident site:-Ambulance driver must know patient or incident location or
address.
 Know type of emergency (incident).
 Number of patient will Know in the incident site.
 Different forms and documents should be fulfilled by the respected body.
 When the patient send to other referral hospital he/she fee money to the hospital.
2.5 Report Generated In the Existing System
In an Existing system generates different reports for different purposes. In Arba Minch hospital
ambulance service report is generate daily activity. Those reports include the patient information,
Date, time, total number of patient, Ambulance driver name, distance, type of disease and
incident, and also reached place of patient like hospital or other health organization.
2.7 Bottleneck of the Existing System
2.7.1 Performance
The performance of existing system is less, because the response time is not fast. That means the
response time have direct relation with performance.
2.7.2 Security and Controls
Since all the records associated with in the system are recorded and stored manually, the
security that the system provides is not good. The system shouldn‟t provide sufficient protection
for accessing and manipulation of the records associated with the system. Therefore, it is not
easily protected and control.
2.7.3 Efficiency
The current system is insufficient, because of response time.

2.8 Practices to be preserved
The existing system gives ambulance service for different users by using manual system. This is
good practice that we want to preserve on the new system. However, the main goal of the project
is providing ambulance service which uses automated expert system service and a future
technology by reducing the problems of the current service.
2.9 Proposed Solution for Existing System
The team proposes an AESAM that benefits for Arba Minch town societies and hospital by
developing an automated expert system. Our System will provide good Ambulance service and
effective database storage.
2.10 Requirements of the Proposed System
2.10.1 Functional Requirements
The functionally of our proposed system requires process, Input related, Output related, Storage
related requirements, and other specific functionality that define what a system is supposed to
accomplish.
Process requirements.
 The system receives background information about each user of the beneficiary of
ambulance service from user and stores that information permanently in the database.
 The system receives patient/user phone number and retrieve patient information from
database.
 When the user didn‟t register the system gives the option to register.
Input related requirements
 Background information about each user should be entered in the database by the user.
 When the new users get to the ambulance service, their personal information should be
entered to the database.
Output related requirement
 The system shall provide immediate response to the users.
 The system shall store patient information in the database.
Storage related requirements
The system shall store all the data related with all the tasks performed into a database.

2.10.2 Non Functional Requirements
The Proposed system of non-functionally requires performance, User Interface, Security and
access permissions, and other specific functionality that define what a system is supposed to
accomplish.
Performance
 Our proposed system shall provide 24 hours accesses for the users.
 The proposed system runs on any kind of operating system.
 After the user send request the response time is fast.
User Interface
 Users easily navigate and access our system by using user interface designed.
 The system must be compatible with any operating system environment and user friendly
Security and Access Permission
 Our system is secured; means unauthorized body cannot access the system and system
resources.
 The system shall permit the Manager to edit user‟s information.
Usability
Ambulance Management System provide mouse and keyboard navigation. Ambulance
Management System shall be easy to navigate by using clear words, menus and drop-down lists.
Ambulance Management System is accompanied with a user manual.
Availability
Ambulance Management System is available every time for application of the users.
Supportability
The ambulance Management system application should be supportable in the current equipment
such as computers, monitors and smart mobile phone.

CHAPTER THREE: SYSTEM ANALYSIS
3.1 Introduction
The project development in a team used an object oriented system development methodology.
Because the Object oriented system development approach gives easier and natural way to break
down problems into simple, small and manageable components so that it reduces the vague
appearance of the big problem. Moreover, it is predominately used and popular method in
present software development trend.
The major activities described in this chapter are Constructing a use case model ,Documenting
the use case course of events, constructing sequence and activity diagram analysis level class
diagram and user proto type about the proposed system.
3.2 System Requirement Specifications (SRS)
Actor Identification
Managers: - A special user of the system who can manage the system setup access right for
other users. And also can remove the user information from the database.
Patient: - Someone who can access the system and use ambulance service. He/she in Arba
Minch town.
Ambulance Driver: - Someone who can access system and he/she drive ambulance to give
ambulance service for the society i.e. transport patient from incident site to hospital.

3.2.1 Use Case Diagram.
A use case diagram is simplest representation of a user's interaction with the system and
depicting the specifications of a use case. A use case diagram can portray the different types of
users of a system and the various ways that they interact with the system.
Figure 2 Use case diagram

3.2.2 Use Case Documentation
3.2.2.1 Use Case Documentation for Login
Use case name Login
Use case number UC1
Actors Ambulance Driver, Manager
Description The authentication for authorized users in the system and deliver them the
right to visit their specified privileged page.
Pre-condition The users must have user name and password.
Basic course of
action
Actors action systems response
Step1: Ambulance Driver, Manager
initiate to login.
Step 3: User enter user name and
password.
Step 2: System display login page.
Step 4: System checks the validity
of username and password and also
checks for authentication and
authorization.
Step5: If the user is authenticated
& authorized on the system then
user privilege to access only system
privileged pages for that user.
Alternate courses of
action
Step 4: If the user‟s entry (user name and Password) is not validated and
verified the system displays “invalid username or password” message and
return to step 2.
Post condition User able to access the required information i.e. user is now logged into
the system.
Table 5 Use Case Documentation for Login

3.2.2.2 Use Case Documentation for View Message
Use case name View Message
Use case number UC2
Actors Ambulance Driver, Patient
Description To get patient location from the system and also patient get ambulance
information.
Pre-condition Patient should be send request to the system.
Basic course of
action
Step1: Ambulance Driver, patient
initiate to View message.
Step 3: Ambulance Driver view
patient information and patient
view message about ambulance
information.
Step 2: System should send
generated message.
Alternate courses of
action
When the message not available return to step 1.
Post condition Ambulance reach to incident site Patient is reach to hospital.
Table 6 Use Case Documentation for View Message

3.2.2.3 Use Case Documentation for Send Request
Use case name Send Request
Use case number UC3
Actor Patient
Description When the patient is get ambulance service patient send request to the system.
Pre-condition Patient should be register before send the request.
Basic course of
action
Step1: patient initiates call to send
request.
Step2: patient call to the system.
Step 3: System receive caller phone
number.
Step4: If patient is register system accept
patient request.
-If patient is not register system display
error message.
Alternate courses
of action
Step 4: when the system is not give response return to step2
Post condition The system knows patient request and patient get ambulance service.
Table 7 Use Case Documentation for Send Request

3.2.2.4 Use Case Documentation for Register
Use case name Register
Use case number UC4
Actors Patient, Ambulance Driver
Description It describes about information record in the database.
Pre-condition Know required fields of registration.
Basic course of
action
Step1: patient initiate for register
-Ambulance driver initiate to
register
Step2: patient fills required
information in registration form
and click register button.
-Ambulance driver fills required
information in registration form
and click register button.
Step3: System display patient registration
form.
-System display ambulance driver
registration form.
Step4: System check form validation.
-If form validation is invalid display error
message.
Step5: system store or record information
in the database.
Alternate courses
of action
Step 4: when form validation is invalid return to step2.
Post condition Record patient and Ambulance Driver information in the database.
Table 8 Use Case Documentation for Register

3.2.2.5 Use Case Documentation for Generate Message
Use case name Generate message
Use case number UC5
Actor Manager
Description It describes the process of generate message
Pre-condition Manager should have an account and has to be remembering user name and
password to login the system.
Basic course of
action
Step1: Manager initiate to login
Step3: manager enters user name
and password and click login
button.
Step5: Prepare message to generate
message.
Step4: System checks the validity of user
name and password and also checks for
authentication and authorization.
-Invalid user name or password system
display error message
Step5: System generate message.
Alternate courses
of action
Step 4: invalid user name or password return to step2.
Post condition Manager generate message
Table 9 Use Case Documentation for Generate Message

3.2.2.6 Use Case Documentation for Generate Report
Use case name Generate report
Use case number UC6
Actor Manager
Description Generates a report of all activities undertaken in a specified period.
Basic course of
action
button.
- .
Step5: System display reports generate
page.
Alternate courses
of action
Post condition Manager generate report
Table 10 Use Case Documentation for Generate Report

3.2.2.7 Use Case Documentation for Manage Ambulance
Use case name Manage ambulance
Use case number UC7
Actor Manager
Description It describes the process of ambulance management activities.
Basic course of
action
button.
Step6: manager manages
ambulance.
Step5: System display ambulance list.
Step7:system store managed ambulance
information in the database
Alternate courses
of action
Post condition Manager manages ambulance in the hospital for ambulance distribution.
Table 11 Use Case Documentation for Manage Ambulance

3.2.2.8 Use Case Documentation for Manage User
Use case name Manage User
Use case number UC8
Actor Manager
Description It describe the process of allows manager to add/remove/update the users.
Basic course of
action
button.
Step6: Manager manages user
information for delete, modify and
control for user activity.
Step5: System display user information
page.
Alternate courses
of action
Post condition Manage user for different activities and difference operation are perform in user
information also store in the database.
Table 12 Use Case Documentation for Manage User

3.2.2.9 Use Case Documentation for View User Information
Use case name View User Information
Use case number UC9
Actor Manager
Description It describes the process of user information activities for different purpose.
Basic course of
action
button.
Step6: manager view user
information.
Invalid user name or password system
Step5: System display user information.
Alternate courses
of action
Post condition View patient in information in the system.
Table 13 Use Case Documentation for View User Information

3.2.3 Sequence Diagram
3.2.3.1 Sequence diagram for Login
Figure 3 Sequence diagram for Login

3.2.3.2 Sequence diagram for Register
Figure 4 Sequence diagram for Register

3.2.3.3 Sequence diagram for Manage Ambulance
Figure 5 Sequence diagram for Manage Ambulance

3.2.3.4 Sequence diagram for Manage User
Figure 6 Sequence diagram for Manage User

3.2.3.5 Sequence diagram for Generate Message
Figure 7 Sequence diagram for Generate Message

3.2.3.6 Sequence diagram for View User Information
Figure 8 Sequence diagram for View User Information
Manager
View User
information Course
of action

3.2.3.7 Sequence diagram for Send request
Figure 9 Sequence diagram for Send request

3.2.3.8 Sequence diagram for View Message
Figure 10 Sequence diagram for View Message

3.2.3.9 Sequence diagram for Generate Report
Figure 11 Sequence diagram for Generate Report

3.2.4 Activity Diagram
3.2.4.1 Activity Diagram for Login
Figure 12 Activity Diagram for Login
3.2.4.2 Activity Diagram for Register
Figure 13 Activity Diagram for Register

3.2.4.3 Activity Diagram for View Message
Figure 14 Activity Diagram for View Message
3.2.4.6 Activity Diagram for Send Request
Figure 15 Activity Diagram for Send Request

3.2.4.4 Activity Diagram for Manage Ambulance
Figure 16 Activity Diagram for Manage Ambulance
3.2.4.5 Activity Diagram for Generate Message
Figure 17 Activity Diagram for Generate Message

3.2.4.7 Activity Diagram for Manage User
Figure 18 Activity Diagram for Manage User

3.2.4.8 Activity Diagram for View User Information
Figure 19 Activity Diagram for View User Information

3.2.5 Analysis level class diagram
Figure 20 Analysis level class diagram

3.2.6 User Interface Prototype
Figure 21 User interface prototype

CHAPTER FOUR: SYSTEM DESIGN
4.1 Introduction
System design is the transformation of the analysis model into a system design model. During
system design, developers define the design goals of the project and decompose the system into
smaller subsystems that can be realized by individual teams. The result of system design is a
model that includes a clear description is a model that includes a clear description of each of
these strategies, subsystem decomposition, and a UML deployment diagram representing the
hardware/software mapping of the system.
4.2 Class Type Architecture
The class type architecture describes how the system works and interacts with the user by
dividing work into different layers. A layered approach is used to design the system. These
layers are interface layer, control layer, domain layer, persistent layer and system layer.
Figure 22 Class a type architecture diagram

 User interface layer This Layer is the form which provides the application to either
programmer or end user.
 Process layer This Layer implements business logic that involves
collaborating with several domain classes or even other
process classes
 Domain layer This layer is used to transfer data from application layer or
presentation layer to data layer. This layer is also used when
a class variables are declared corresponding to the fields of
the database which can be required for the application and
make the properties. So that, the team can gets or sets the
data using these properties into the variables.
 Persistence layer This layer encapsulates the capability to store, retrieve, and
delete objects/data permanently without revealing details of
the underlying storage technology. This layer is also a class
to get or set data to the database queries back and forth.
 System layer This Layer provides operating-system-specific functionality for our
applications, isolating our software from the operating system (OS)
by wrapping OS-specific features, increasing the portability of our
application
 User interface layer This Layer is the form which provides the application to either
programmer or end user.
Table 14 Class type architecture description

4.3 Class Modeling
Class modeling used to describe the structure of this system. Classes are abstractions that specify
the common structure and behavior of a set of objects in the new system. In this modeling the
team‟s members have design the system in terms of objects, classes, attributes, operations and
their association. Of course the model depicted here is a sample.
Figure 23 Design class diagram

4.4 State Chart Modeling
State chart diagram shows the object undergoing a process. It describes the flow of control from
one state to another state. States are defined as a condition in which an object exists and it
changes when some event is triggered. So the most important purpose of State chart diagram is
to model life time of an object from creation to termination.
State chart for login:
Figure 24 State chart diagram for login:
State chart diagram for manage user:
Figure 25 State chart diagram for manage user:

State chart diagram for manage user:
Figure 26 State chart diagram for send request
State chart diagram for manage Ambulance:
Figure 27 State chart diagram for manage Ambulance

4.5 Collaboration Modeling
A collaboration diagram describes interactions among objects in terms of sequenced messages.
It represents a combination of information taken from class, sequence, and use case diagrams
describing both the static structure and dynamic behavior of a system.
Collaboration diagram for registration:
Figure 28 Collaboration diagram for registration:
Collaboration diagram for View message:
Figure 29 Collaboration diagram for view message:

Collaboration diagram for manage ambulance:
Figure 30 Collaboration diagram for manage ambulance
Collaboration diagram for manage send request:
Figure 31 Collaboration diagram for manage send request

4.6 Component Modeling
The component model illustrates the software components that will be used to build the system.
We build it up from the class model and written from scratch for the new system. Components
are high level aggregations of similar software pieces, and help us in providing a‟ black box‟
building block approach to software construction.
A component diagram has a higher level of abstraction than a Class Diagram component is
implemented by one or more classes (or objects) at runtime. They are building blocks so a
component can eventually encompass a large portion of a system.
Figure 32 Component diagram

4.7 Deployment Modeling
A UML deployment diagram depicts a static view of the run time configuration of processing
nodes and component that run on those nodes. Deployment diagram show how the software
components process and objects are deployed into physical architecture of the system. It shows
the configuration of the hardware units or communication device and how this software
components and objects redistributed across the unit and also the middle ware used to connect
the desperate machine one another.
Figure 33 Deployment modeling diagram

4.8 Persistence Data Modeling
Persistent data management deals with how the persistent data (file, database, etc) are stored and
managed and it outlives a single execution of the system. Information related to programs basic
information and other related information are persistent data and hence stored on a database
management system. Moreover, storing data in a database enables the system to perform
complex queries on a large data set. For complex queries over attributes and large dataset
Microsoft SQL Server is implemented, which is a Relational Database Management System.
Figure 34 Persistence diagram

4.9 User Interface design sample
User interface Ambulance Registration page
Figure 35 User interface Ambulance Registration Form
User Interface for Home page
Figure 36 User interface Home page

User interface for generate report
Figure 37 User interface for generate report page

User interface for User registration page
Figure 38 User interface User registration
User interface send request page
Figure 39 User interface send request

User interface for Manage user page
Figure 40 User interface send request

CHAPTER FIVE: TESTING AND IMPLEMENTATION
Implementation refers to the coding of the all documents gathered starting from requirement
analysis to Design phase. All documents, business logic, information gathered are designed into
the code so that the system will be implemented for the user to be used for the purpose it
developed. The chapter here describes about the final testing system, hardware and software
acquisitions, and installation process. The functional system from the design phase above is the
key input to the implementation phase. The deliverable of the implementation phase (the project)
is the operational system that will enter the operation and support stage of the system‟s life cycle.
Here is the sample code for each module.
5.1 Coding
The physical design specification created by the designers is turned in to working computer
code.
Login in sample code
protected void Page_Load(object sender, EventArgs e)
{
Session.RemoveAll();
Response.ClearHeaders();
Response.AppendHeader("Cache-Control", "no-cache"); //HTTP 1.1
Response.AppendHeader("Cache-Control", "private"); // HTTP 1.1
Response.AppendHeader("Cache-Control", "no-store"); // HTTP 1.1
Response.AppendHeader("Cache-Control", "must-revalidate"); // HTTP 1.1
Response.AppendHeader("Cache-Control", "max-stale=0"); // HTTP 1.1
Response.AppendHeader("Cache-Control", "post-check=0"); // HTTP 1.1
Response.AppendHeader("Cache-Control", "pre-check=0"); // HTTP 1.1
Response.AppendHeader("Pragma", "no-cache"); // HTTP 1.1
Response.AppendHeader("Keep-Alive", "timeout=3, max=993"); // HTTP 1.1
Response.AppendHeader("Expires", "Mon, 26 Jul 1997 05:00:00 GMT"); // HTTP 1.1
// coun = 0;

if (!IsPostBack)
{
SetImageUrl();
}
}
protected void Timer1_Tick(object sender, EventArgs e)
{
SetImageUrl();
}
Session["phone"] = txtlname.Text;
Session["inciedent"] = txtfname.Text;
Response.Redirect("account.aspx");
private void SetImageUrl()
{
Random _randm = new Random();
int i = _randm.Next(1, 16);
Image1.ImageUrl = "~/imageshow/" + i.ToString() + ".jpg";
}
protected void Button1_Click(object sender, EventArgs e)
{
SqlConnection checkuser = new
SqlConnection(ConfigurationManager.ConnectionStrings["registrationConnectionString"].
ConnectionString);
checkuser.Open();
string fname1 = "select count(*) from AccountDb where user_name='" + TextBox3.Text +
"' ";
SqlCommand com = new SqlCommand(fname1, checkuser);
int tem = Convert.ToInt32(com.ExecuteScalar().ToString());
checkuser.Close();
if (tem == 1)}}}}}

Code for registration
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Data.SqlClient;
using System.Configuration;
namespace AmbulanceManagement
{
public partial class registrationform_forderiver : System.Web.UI.Page
{
SqlConnection conn = new
ConnectionString);
{
conn.Open();
}
protected void btnregister_Click(object sender, EventArgs e)
{
try
{
string insertQuery = "insert into Table1
(First_Name,Last_Name,Age,Sex,Address,Salary,Ambulance_type,Phone_Number) values(
@fname ,@lName ,@age,@sex ,@address ,@salary ,@ambulance,@phone) ";
SqlCommand com = new SqlCommand(insertQuery, conn);
com.Parameters.AddWithValue("@fname", txtfname.Text);
com.Parameters.AddWithValue("@lname", txtlname.Text);

com.Parameters.AddWithValue("@age", int.Parse(TextBox1.Text));
com.Parameters.AddWithValue("@sex", DropDownList4.Text);
com.Parameters.AddWithValue("@address", DropDownList3.Text);
com.Parameters.AddWithValue("@age", int.Parse(TextBox5.Text));
com.Parameters.AddWithValue("@ambulance", txtambutype.Text);
com.Parameters.AddWithValue("@phone", int.Parse(txtphonenumber.Text));
com.ExecuteNonQuery();
abel1.Text = "Registration is successful";
txtfname.Text = "";
txtlname.Text = "";
TextBox1.Text = "";
DropDownList4.Text = "";
DropDownList3.Text = "";
TextBox5.Text = "";
txtambutype.Text = "";
txtphonenumber.Text = "";
}
catch (Exception ex)
{
Response.Write("Error" + ex.Message);
}
finally
{
conn.Close();
}}}}

Code for send request
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Data.SqlClient;
using System.Configuration;
using System.Data;
namespace AmbulanceManagement
{
public partial class M_View_Request : System.Web.UI.Page
{
SqlConnection conn = new
ConnectionString);
{
try
{
conn.Open();
//int SID = Convert.ToInt32(TextBox1.Text);
string mr = "Null";
SqlCommand cmd = new SqlCommand("select
First_Name,Village_Name,House_Number,Phone_Number,Date From UserData where
Manager_Remark='" + mr + "'", conn);
//cmd.ExecuteNonQuery();
GridView1.DataSource = cmd.ExecuteReader();
GridView1.DataBind();

}
{
Response.Redirect("ex.message");
}
finally
{
conn.Close();
}}
protected void btnSend_Click(object sender, EventArgs e)
{
try
{
conn.Open();
SqlDataAdapter da = new SqlDataAdapter();
string ph = TextBox1.Text;
string DI = "select Manager_Remark,Date from UserData where Phone_Number='" + ph +
"' ";
SqlCommand com = new SqlCommand(DI, conn);
string manr = com.ExecuteScalar().ToString();
string date = com.ExecuteScalar().ToString();
string datee = DateTime.Now.ToString();
string ph1 = TextBox1.Text;
string dt = "select Manager_Remark from UserData where Phone_Number='" + ph1 + "' ";
DateTime datee = DateTime.Now;
da.UpdateCommand = new SqlCommand("Update UserData set Manager_Remark=@manr
where Phone_Number='" + ph1 + "'", conn);
da.UpdateCommand.Parameters.Add("@manr", SqlDbType.Text).Value = "Send";
da.UpdateCommand = new SqlCommand("Update UserData set Date=@date where
Phone_Number='" + ph1 + "'", conn);

da.UpdateCommand.Parameters.Add("@date", SqlDbType.Text).Value = datee;
SqlDataAdapter dr = new SqlDataAdapter();
string Da = "select Date from UserData where Phone_Number='" + TextBox1.Text + "' ";
SqlCommand cmm = new SqlCommand(Da, conn);
string date = cmm.ExecuteScalar().ToString();
dr.UpdateCommand = new SqlCommand("Update UserData set Date=@manr where
Phone_Number='" + TextBox1.Text + "'", conn);
dr.UpdateCommand.Parameters.Add("@date", SqlDbType.Text).Value = DateTime.Today;
int fin1 = da.UpdateCommand.ExecuteNonQuery();
lbl.Text = "Success";
}
{
lbl.Text = ex.Message;
}
finally
{
conn.Close();
}
try
{
conn.Open();
int SID = Convert.ToInt32(TextBox1.Text);
string mr = "Null";
SqlCommand cmd = new SqlCommand("select
First_Name,Village_Name,House_Number,Phone_Number,Date From UserData where
Manager_Remark='" + mr + "'", conn);
cmd.ExecuteNonQuery();
GridView1.DataSource = cmd.ExecuteReader();
GridView1.DataBind();

conn.Close();
}
{
lbl.Text = ex.Message;
}
finally
{
conn.Close();
}
}
}
}
5.2 Finale Testing of the system
Test case
Test case for login
Test Case #:1.1 Test case Name: Login
System: Login Sub system:
Designed by: Team Design Date: 09/05/2015
Executed by: User Execution Date: 20/05/2015
Short Description: Test the login Accessibility or check Authorized person
Pre-conditions
The user has a valid User Name and Password. The user has accessed the page by

Step Action Expected System
Response
Pass/Fail Comment
1 Click the „login‟
button
The system displays a login
page
pass
2 Enter user name and
password
The system displays a
message if user name or
password is incorrect asking
the user to re enter
if correct display main page
pass
Post-conditions
The user access the main page.
Table 15Test case for login
Test Case for change password
Test Case #:1.2 Test case Name: Change Password
System: Password Sub system: Login
Designed: Team Designed Date: 11/05/2015
Executed by: Manager Execution Date: 30/05/2015
Short Description: Test the change current password
entering User Name and Password.

Step Action Expected System Response Pass/Fail Comment
1 Click the „Change
password‟ button
The system displays a change
password page
pass
2 Enter user name,
current password and
new password with
confirm new
password.
The systems displays a Message if
user name and current password is
not match and confirm new
password is also not match the
user to re-enter again.
If both is correct display message
successfully change
pass
Post-conditions
1. The New password is store in database.
Table 16 Test Case for change password
Pre-conditions
The user has a valid User Name and Password.
The current password „de123? <>‟
The system displays the main page.

Test case Send request
Test Case #:1.3 Test case Name: Send Request
System: Send request Subsystem: patient
Designed by: Team Designed Date: 29/004/2015
Executed by: Execution Date: 20/05/2015
Short Description: Test user request is successfully send or not.
Response
Pass/Fail Comment
1 Click the „Send
Request‟ menu
Request page
pass
2 Enter phone number,
Click „Send‟ button
Message
If user is register in the
database send the request is
success. If not register
display registration page.
pass
Pre-conditions
The user is registered in the database.

Taste case for manage ambulance
Test Case #:1.4 Test case Name: Manage Ambulance
System: Manage Subsystem:
Designed: Team Designed Date: 29/004/2015
Executed by: Manager Execution Date: 20/05/2015
Short Description: Test management of Ambulance
Response
Pass/Fail Comment
1 Click the „Manage
Ambulance‟ menu
page
pass
2 Manager perform
Insert Update delete
operation in the system
The required information is
Correct manage all activity
Display error message
when the required
information is invalid
.
pass
post condition
The request is send to the destination
Table 17 Test case Send request

5.2.1 Unit Testing
The Automated Expert system for Ambulance Management System modules are tested unit by
unit. Some of the testing samples are given below
Send request test
Test location Send request Page.
Feature to be
tested
Verifies whether the user is registered in the database or not.
Data User Phone number.
Test Cases Whether the system provides us the request is send or not.
Result Ambulance driver get incidents address information
Table 18 Send request test specification
Login test
post condition
Manage ambulance and store information in the database
Test case identifier
Login process
location Test Log in page
Feature to be
tested
Checks whether the person is authorized or not
Feature to pass
criteria
The test passes:
When user inserts correct username and password in the login
page, the main menu.
If incorrect username and password inserted the system displays

User registration test
Test location User Registration Page
Feature to be tested Adding new users to the database without duplicate.
Feature to pass
criteria
The system checks whether mandatory fields are entered or not.
The system checks whether user information exists or not.
If passes the above condition adds user information to the database.
Data User‟s information such as first name, last name, village name,
phone number etc.
Table 20 User registration test specification
5.2.2 Integration Testing
This testing concentrates on confirming that the software is error-free in all respects. All the
specified validations are verified and the software is subjected to hard-core testing. It also aims at
determining the degree of deviation.
Test communication paths between different parts of the module done by the test department or
by developers to show that all modules work correctly together. After unit testing, the AESAM
is also tested by integration testing by integrating every unit that makes up the whole system.
5.2.3 Acceptance Testing
This testing is done by the customer (on-behalf) to ensure that the delivered product meets the
requirements and works as the customer expected. It includes:-
Alpha- Conducted by users to ensure they accept the system. Application is tested when
development is nearing completion and minor design changes were made as a result of such
testing.
error message and allow returning password and username.
Data Password and username information in the login page.
Result Authorized person is access the required page.
Table 19 Login test specification

Beta- Users use real data, not test data. When development and the above mentioned tests are
completed beta testing was completed and some few final bugs were found. Beta Testing also is
typically done by end-users or others, not by programmers or testers.
5.2.4 System Testing
Verification system: is functionally tested based on the use case model developed during the
analysis phase. It is also operationally tested based on requirements. We test the interface
between programs in the system rather than testing the interface between modules in the program
System testing is also intended to demonstrate whether the system meets its objective. Here the
system is partially functional and reached its requirement.
During system testing, which is a black box test, the complete system is configured in a
controlled environment to validate its accuracy and completeness in performing the functions as
designed. System testing is deemed complete when actual results and expected results are either
in line or differences are explainable/acceptable based on client input.
5.3 Hardware and Software Acquisitions
Hardware acquisition: The system is going to be implemented on the Arba Minch Hospital
intranet. Since our system is web based for its deployment a web server is needed. Here the
hardware requirements are the minimum that they need to be part of intranet.
Software acquisition: The client side application is compatible with windows environment. The
application part of our program is developed by Visual Studio 2010 and the database part is
developed SQL Server.

5.3.1 Hardware &Software Configuration
Production environments Recommended - 32-bit OS with Intel/AMD 2.0
GHZ+ CPU
RAM Recommend minimum - 4 GB
Temporary file space for installs and
upgrades
10 GB free disk space for software and logs
For Redundancy RAID/Mirroring for redundancy
Additional disk space for storage Temp files space- The store requires 5GB
Operating system Windows XP, and Windows 7,window 8 etc.
Internet Connection Speed Higher
Table 21 Hardware &Software Configuration
5.4 Installation/Integration
For bringing the application into a working standard first the application is deployed in AMH‟s
web server. Since it is designed as a web based application there is no issues faced here.
5.5 User Manual Preparation
No more manual preparation is needed for users, because the system developed is not software
and it is not installed on a client computer. After the implementation has been completed, it is
directly hosted on Network (server).
5.6 Training
During the deployment of the system, the project group members will give short time training for
the system administrators and workers explaining how the system works and in what way they
can manage the system developed.
5.7 Installation Process
Since the project is a web based System, there is no need to install it on a particular machine
rather it will be hosted on a web server. Database server will also be configured.

5.8 Start-up strategy
Once the system is hosted, it has two parts: One which needs password and username that is for
Manager. To access those parts one has to have password and user name so that he/she can enter
into it and use it. The other part is those which do not need pass word and username so they can
be view by anybody.

CHAPTER 6 : CONCLUSION and RECOMMENDATION
6.1 Conclusion
With all the accumulated effort invested, there are reasons to believe that at the end of the project
for “Automated Expert System for Ambulance Management in Arba Minch Hospital that ﬁnds
itself in a better way. We summarize the progress with respect to the main objectives of the
project. We the team members can conclude the following perceptional views as we have done
the project throughout this year.
AESAM system supports to manage ambulance and patient information Inside Arba Minch
hospital. Moreover the system can also be used for send the user request to the ambulance
driver, generate report and perform management activity. The new system will changes the
current manual system of AMH ambulance management to computerized manner. It is more
flexible and secure when it compared within the current system. Our project solves the current
ambulance management problem and problem of ambulance service for Arba Minch society.

6.2 Recommendations
We strongly recommend that one who under goes through this project can succeed, and they pay
attention for Expert System that Composing for Ambulance Management. Most of the time has
been taken for understanding the working of existing system, how applications are written in
existing system and how a third party tool can be integrated in this system. But since all these
areas are much clear through this project we recommend adding to sending features from Mobil
to system or Expert system. The final recommendation towards the target group who need to
work on and improving it can even think of different Expert System entirely developed for every
country.

APPENDIX
Form 1: Ambulance phone receive
Figure 41 Ambulance phone receive form
Form 2: Ambulance day to day service control form
Figure 42 Ambulance day to day service control form

REFERENCES
- Lawrence Chung, Advanced Software Engineering syllabus, CS 6354 section 581,2nd
Edition, summer 2007. http://www.utdallas.edu/~chung/CS6354.
- ImarSpaanjaars, Beginning ASP.NET 4: in C# ,Mar 22, 2010
- Requirements Specification Ambulance Dispatch System.
http://mimoza.marmara.edu.tr/~samet.tonyali/courses/cse344/PS/Requirements_Specification
_Ambulance_Dispatch_System.pdf..
- Jesse Liberty, Programming C# 4th Edition Building .NET Applications with C#, O'Reilly
Media, February 2005.

Automated Expert System For Ambulance Management In Arba A Senior Project

Recommended

Recommended

More Related Content

Similar to Automated Expert System For Ambulance Management In Arba A Senior Project

Similar to Automated Expert System For Ambulance Management In Arba A Senior Project (20)

More from Kelly Lipiec

More from Kelly Lipiec (20)

Recently uploaded

Recently uploaded (20)

Automated Expert System For Ambulance Management In Arba A Senior Project