L5 PROJECT

BANDA MUKOMELA COMPUTING PROJECT Page 1

ABSTRACT

The cancer diseases hospital management system is an IT based solution that has

been developed to enable the cancer diseases hospital to maintain electronic patient’s

appointments records of the hospital.

The project is based on a dynamic website that will improve the current system of the

hospital. A secure data storage and allocation of appointments to patients is a huge

problem the hospital faces. However, a suitable method had to be chosen on how to

develop a project that will help the hospital securely store data, provide online

registration, appointment request, patients booked for appointments and improved data

retrieval

This web based solution aims at enhancing effectiveness, accuracy efficiency and ease

of use In the current manual system by addressing the challenges faced by the CDH

with regards to proper record keeping and retrieval of patients and the way

appointments are handled which has brought about a lot of difficulties.

However, The project enables the CDH members of staff to allocate appointments to

patients by request and this can be done despite where the patient can be in the

country or world due to the networkability features the solution has


ACKKNOWLAGEMENT

Firstly I would like to thank God Almighty for giving me the strength to be who and

where I am today, indeed you are faithful to your word “you have never left me nor

forsaken me”. Special thanks go to Mr. A Malumo my project supervisor for his support

and guidance during the development of the project. I would also like to acknowledge

the support given to me by the members of staff at the Cancer Disease Hospital the

director Dr K Lishimpy, Mr. Mwale, Mrs. Mwila and many others.

To all my L5 classmates of June 2013 intake, I would like to say thank you and urge

them to continue working hard.

Lastly my special appreciation goes to my lovely beautiful sister Belita Banda

Nsenduluka and her husband, thank you for standing by me spiritually and financially. I

would not have achieved this without their support may God bless you.


Contents

ABSTRACT....................................................................................................................................................1

ACKKNOWLAGEMENT.................................................................................................................................2

introduction.................................................................................................................................................6

Current System........................................................................................................................................6

The System Developed............................................................................................................................6

Methodology Used..................................................................................................................................7

THE FINAL SOLUTION...............................................................................................................................8

PROJECT AIMS AND OBJECTIVES.................................................................................................................9

OVERVIEW OF THE REMAINING CHAPTERS...............................................................................................10

ANALYSIS...............................................................................................................................................10

DESIGN..................................................................................................................................................10

IMPLIMENTATION.................................................................................................................................10

OTHER PROJECT ISSUES.........................................................................................................................10

TOPIC 2......................................................................................................................................................11

ANALYSIS...................................................................................................................................................11

FACT FINDING TECHNIQUES......................................................................................................................11

INTERVIEWS...........................................................................................................................................12

OBSERVATION.......................................................................................................................................12

CATEGORIES OF REQUIRMENTS................................................................................................................12

Requirements........................................................................................................................................12

FUNCTIONAL REQUIREMENTS...............................................................................................................12

Table for functional requirements.....................................................................................................14

NON-FUNCTIONAL REQUIREMENTS......................................................................................................14

Non functional requirements............................................................................................................15

MoSCoW Prioritization of Requirements...............................................................................................15

USE CASE DIAGRAM...............................................................................................................................16

ARCHITECTURE......................................................................................................................................17

SYSTEM ARCHITECTURE.........................................................................................................................18

SYSTEM ARCHITECTURE DIAGRAM........................................................................................................18

TECHNICAL ARCHITECTURE........................................................................................................20


IMPLEMENTATION ARCHITECTURE.......................................................................................................20

INITIAL CLASS DIAGRAM........................................................................................................................21

CONCLUSION.........................................................................................................................................22

TOPIC 3......................................................................................................................................................23

DESIGN......................................................................................................................................................23

INTRODUCTION.....................................................................................................................................23

STRUCTURAL MODEL.............................................................................................................................23

BEHAVIOURAL DIAGRAM.......................................................................................................................24

CONCLUSION.........................................................................................................................................25

CHAPTER 4.................................................................................................................................................26

IMPLEMENTATION....................................................................................................................................26

INTRIDUCTION.......................................................................................................................................26

SYSTEM CUTOVER..................................................................................................................................27

Direct Cutover.......................................................................................................................................28

Phased Cutover.....................................................................................................................................29

DATA MIGRATION..................................................................................................................................29

TRAINING...............................................................................................................................................30

CONCLUSION.........................................................................................................................................30

CHAPTER 5.................................................................................................................................................31

OTHER PROJECT ISSUES.............................................................................................................................31

INTRODUCTION.....................................................................................................................................31

PROJECT MANAGEMENT.......................................................................................................................31

RISK MANAGEMENT..............................................................................................................................32

RISK ANALYSIS.......................................................................................................................................33

RISK RESPONSE......................................................................................................................................34

RISK RESPONSE STRATAGIES..................................................................................................................34

CONFIGURATION MANAGEMENT..........................................................................................................34

TESTING.................................................................................................................................................35

TABLE UNIT TESTING.........................................................................................................................36

INTERGRATION TESTING........................................................................................................................37

CONCLUSION.........................................................................................................................................39

CHAPER 6...................................................................................................................................................40


CONCLUSION.............................................................................................................................................40

PROJECT EVALUATION...........................................................................................................................40

CRITICAL EVALUATION...........................................................................................................................40

PROBLEMS EXPERIENCED..........................................................................................................................41

FEATURES OF FUTURE PROJECT............................................................................................................41

REFRENCES........................................................................................................................................43

APPENDIXES...........................................................................................................................................44

APPENDIXES 1....................................................................................................................................44

APPENDIXES 2....................................................................................................................................44

APPENDIXES 3....................................................................................................................................44

APPENDIXES 4....................................................................................................................................44


introduction

This report covers the processes that were taken in the development of a patient’s

management system for Cancer Disease Hospital (CDH). However, it brings out the

details of the systems development with reference to system analysis, design and

implementation of a system that is aimed at addressing some of the needs of the client.

Current System

The (CDH) currently maintains a manual paper based system that enables them to

manage patient’s records and other related information. Therefore, the current system is

not able to meet certain deadlines because it is slow hence ends up delaying some

appointments since they are records one at a time. In addition to that CDH does not

have a website that will help people know more about cancer, how it can be treated and

other health services both the people in and out of Zambia.

The System Developed

The system that has been developed is a web based patient management system

application for CDH its aim is to address the current problems that have been explained

earlier. The system is a website that consists of web forms and functions that looks like

the current system. However, the main purpose of this project is to create a system that

will enable online appointments booking. Its real time and appends information to a

database that’s created for that purpose. Patients that book for an appointment should

be able to see that they have booked and receive a feedback to confirm their

transaction. Doctors will also be able to login in to the system and check patents that

will to be attended by them on a particular date and time depending in which

department the doctor belongs and the type of patient, the doctor will be able to modify

the appointment if has attended to the patient and also delete that patient from his list of

pending patents list. The doctor will able to send his patient then send them email on

what the doctor wants to update his patients on their health status. The system is also

able to send reminders to patients that they are due for an appointment or review.


Methodology Used

I have decided to use the object oriented analysis and design methodology for the

development of the dynamic website for CDH. Object oriented analysis views a system

as a collection of interacting objects that work together to accomplish a task. It users

classes, objects and relationships to create a system. Below are the reasons why I

chose object oriented analysis:

Advantages

It enables systems to be developed fast

It allows scalability in case the user changes requirements

It has a reputation of delivering high quality software’s

Object oriented analysis looks at the real world environment in which a system

will operate with this environment and consisting of people and things interacting

to create some results

The people and the things are first analyzed in the most abstract form and these

abstractions become classes

Object oriented analysis reduces maintenances a first goal to assure that the

system enjoys a life while having a smalle maintenances cost

It encourages training for all the people involved in the analysis process by the

using a low risk project first to allow the analysts to learn from their mistakes.

Object oriented analysis examines system requirements from the prospective of

classes and objects found in the specified domain

It focuses on what the system is supposed to do rather than how it will be done

and looks at the behavior of the system independent of its domain

Disadvantages

It requires a trade-off between coupling and cohesion

It can be too technical and complicated

Badly designed class can be produced if the developer dose not fully

understands object oriented methodology


THE FINAL SOLUTION

The final solution has been implemented as a php web based application with

accompanied with MYSQL database management system. The application is a

stand-alone application. The solution includes the following key features:

user

Sign up form

User login form

A form for a patient to request for an appointment

A form for a patient to view their appointments

Staff

Staff login form

A form for creating a doctor account

A form for creating a patient account

A form for creating appointments

A form for viewing

All doctors in the system

All patients in the system

All appointment requests

All appointments created

Doctor

Doctor login form

View his patients

View his appointments

Edit his patients appointments

Delete his patients

An administration page for


A form for creating doctors accounts

A form for creating staff accounts

A form for creating a departments

A page for viewing reports

View all staff in the system

View all patients in the system

View all doctors in the system and patients appointments report

The system database in MYSQL.

PROJECT AIMS AND OBJECTIVES

Below is a list of the aims and objectives of the project

Aims- the aims of the project were as follows

To design a website-based application that would enable manages its patient’s

appointments.

To develop a database that will have all the data for the patients, departments,

members of staff and doctors the hospital

Objectives -The following were the objectives

To identify carry the requirements for the CDH with the view to determining which

ones would be ok for the solution.

Deploy the working system as a stand-alone system within a period of two

months.

Test the working project in different types of test requirements

Deploy the working application

Document a user manual for the system

Document the project

Demonstrate the working application on ZCAS facility


OVERVIEW OF THE REMAINING CHAPTERS.

The Remaining Chapters of This Report Will Cover the Following Aspects of the

System.

ANALYSIS

The analysis part of the report covers issues with regards to the functional and non-

functional requirements of the system as well as the architecture to be used in order to

reach all the requirements.

DESIGN

This chapter will contain the design specifications of the system with regards to

structural and behavioral models of the system.

IMPLIMENTATION

This chapter will focus on describing every implementation approach that was used

programming language, system cutover from development architecture and

implementation, data migration as well as user training.

OTHER PROJECT ISSUES

This chapter will focus at other issues of the project such as risk management, project

management, configuration management and system testing.


TOPIC 2

ANALYSIS

When developing a new system for an organization, it is very important to understand

how the current system is working in order to identify what should be needed in the new

system so that the needs of the user are meeting. This part of the report will focus on

the different analysis techniques that are used in the collection of requirements for CDH

and the detailed list of requirements that resulted from them. These requirements are

divide into two categories the functional and the non-functional requirements. This

chapter will also look at the architecture that will be used to implement the system.

However, the requirements of the project are stated here and the architecture to be

used.

The use case diagram presents the uses case that will support the requirements

of the new system.

Initial class diagram is produced to show how the new system will be made use

of.

FACT FINDING TECHNIQUES

For me know how the current system works for CDH. I found time to visit the hospital to

observe how the system works and interview the members of staff that user the existing

system. This is an important stage of analysis as it helps identify the main requirements

of the new system and clarify problems faced in the old system.

INTERVIEWS

Using this technique, a lot of information was gathered from a Varity of staff members

and patients. Among the staff member I interviewed was the Director of Cancer

Diseases Hospital Dr Lishmpy, He told me that since the hospital was opened it has

only been using the paper based system to register and manage patients appointments

and health information, However, he said that when a patient reaches the hospital they

must be under a reference that the patient may have cancer. Hence, they have to


register by filling in a patients form then go for screening in the screening room, this

information has to be taken to the information room were the data has to be stored into

the hospital file and them book the patient an appointment with the doctor depending on

outcome from the screening room.

OBSERVATION

Having spent time at the hospital, I observed that patients have to make a queue to

collect the patients registration form . They also have to wait for the receptionist to

check for them when their appointment with the doctor will be after they have come

back for the screening room and at which department of the hospital. Not forgetting

those who have forgotten or misplace their appointment date and what to check for their

appointment. Through this technique it is time consuming and can also lead to

bleaching confidentiality.

CATEGORIES OF REQUIRMENTS

Requirements

A requirement is a service or function that the user wishes the solution to perform, or a

function that the solution should exhibit (Tudor and Tudor, 2010). Requirements are

classified as either functional or non-functional

FUNCTIONAL REQUIREMENTS

Functional requirements are what the system is expected to do, which is referred to as

the functionality of the system. Non-functional requirements are highlight aspects

relating to the system concerning how well functional requirements are provided.

It is important to deliver a solution that is of high quality and within time. Therefore, for

this desired quality to be delivered.


ID REQUIRMENTS REQUIRMENTS

DESCRIPTION

Priority

FR1 To capture details of a patient The application should be

allow patents details to be

captured

Must have

FR2 To capture details for an appointment request The application should be

able to capture details that

are being requested for an

appointment

Must have

FR3 To capture details for a doctor The application should be

able to capture doctor

detals

Must have

FR4 To capture details for a new member of staff The application should be

able to capture staff

details

Must have

FR5 To create appointments The application should be

able to capture

appointments that have

been created

Must have

FR6 To capture new departments The application should be

able to capture new

departments

Must have

FR7 To generate patient reports Allow patients to view

their appointments

Must have

FR8.1 To generate staff reports Allow staff members to

view reports

Must have

FR.8.2 To generate doctor reports Allow doctors to view

reports

Must have

FR.8.3 To generate appointment request Allow the user to request

for appointments

Must have

FR8.4 To generate individual patients reports Allow patients to view Must have


their own appointment

FR8.5 To delete individual patients appointments The system will individual

patients documents to be

deleted

Must have

FR8.6 To edit individual patients appointments The application will enable

the individual patients

details to be deleted

Must have

FR9.0 Patient be able to delete himself The application should

enable the patients to

delete themselves from

the system

Should have

Table for functional requirements

NON-FUNCTIONAL REQUIREMENTS

Non-functional requirements are those that concern themselves with performance

issues of the solution. They specify how the system should function (Tudor and Tudor,

2010).below are the non-functional requirements of the system which is under

development.

ID REQUIMENTS REQUIRMENT

DISCRIPTION

PRIORITY

NFR1 No online payments The application

should be able to

allow online payments

Should have

NRF2 Produce a PDF format The application

should be able

produce a PDF

formats

documentation

Should have

NFR3 No detailed information about The application must Must have


doctor on patients view side be able to allow

patients to see the

doctor details

NRF4 To ensure that some parts of the

system is only accessed by the

CDH staff only

For security reasons

the system muss only

be accessed specific

members of staff

Must have

NFR5 Restrict logging into the system at

specified times of the day

Restrict login at

particular times of the

day

Could have

Non functional requirements

MoSCoW Prioritization of Requirements

The requirements prioritization is a method that is used to determine what level of

priority is attached to functional requirements (Tudor and Tudor, 2010). The levels of

prioritization include the following below.

Must Haves: these are requirements that are fundamental to the system, without

them the system cannot function without them.

Should Haves: they are considered as important requirements that the system

can still function without them.

Could Haves: could have requirements are requirements which can improve the

system or business but are more easily left out.

Won’t Have This Time: these are valuable requirements which can be left out

but maybe incremented later.

USE CASE DIAGRAM

A use case diagram is a model that is developed to clearly identify the users of the

system and the tasks each user will have with the system. This model also shows how

the users will interact with the system. These users are called actors. StarUML is

software that I have used to generate the model to help understand the system.


However, the use case is based on functional requirements that have been classified as

‘Must Haves’ under the MoSCoW protestation of requirements in Table 1. Below is the

use case diagram.

USE CASE DIAGRAM


System

Request for an appointment

Staff

User DoctorView all appointment

create Doctor account

create staff account

View all pateints

Create pateint account

create patients appointments

view Reports

adminstrator

Create Department

delete appointments

edit appointments

view all patients

sign up

Log in

ARCHITECTURE

Architecture refers to the various components modules of an information system

and how they work together referred definition by schach (2004, p. 30). Bennent

McRobb & Farmer (2006, p.340) defines architecture as a fundamental

organization of a particular system that is exemplified in system components,

their relationships to each other and the environment as well as the principles

that guide the system’s design and evolution

SYSTEM ARCHITECTURE

System architecture refers to a system’s high level view. The modeling is based

on the major components and the interconnection between them. The detailed

design of the system is not usually addressed. However, it does not normally

address the detailed design of the system, through standards to be applied may

be best. (Bennett,McRobb & 2006, P,339)

The system architecture presents an over view of how a system has been

developed. It shows how the system interfaces with other existing systems. The

diagram below shows how the under development system should communicate

with other interfaces, the dynamic website is being developed using PHP which

will connect to the database using MySQL. I am using wampServer which has all

these applications embedded in it.


PATIENT DOCTOR MEMBER OF STAFF

USER INTERFACE

ADMINSTRATOR

CDH INTERFACE

PHP

Doctor| Staff members |Patients|view appointment, staff,doctor|edit, delete appointment

DATABASE

WAMPSERVER

SYSTEM ARCHITECTURE DIAGRAM


The system above shows how the system interacts; A user visits the website, signs up

as a patient then logs in. If already a patient, can just login, can request for an

appointment and view them. Doctor can login and then view his appointments, his

patients, edit his appointments and delete his appointments when complete. A member

of staff is able to log in and create a patients account, create appointments for patients

and view them Administrator logs in and is able to create doctor account, patient

account, staff account, create a department, view all staff, patents and doctor of the

hospital. All this data is stored in the database,

TECHNICAL ARCHITECTURE

Technical architecture contains information about the technical architecture

which is hardware and software used in the development of the system. The

diagram below shows the hardware and software objects used in develop the

website.

IMPLEMENTATION ARCHITECTURE

The new system and its database will be installed on the server. The hospital

administrator and other authorized members of staff will be access the system via the

local area network of the hospital while the patients and those that are just visiting the


website will use the internet in order to have access to the system. The diagram is show

below.

INITIAL CLASS DIAGRAM

This section of the report contains an initial class diagram derived from the use

case diagram. A class diagram is a model that illustrates the relationship and

dependencies among classes in the unified model language (UML). To produce

this diagram I used the StarUML software which is used to model diagrams like

this. The initial class diagrams does not show methods and attributes contained

in the classes. it only shows classes and the relationship between classes. The

initial class diagram is shown below.


CONCLUSION

Analysis phase involves the understanding of the current system, and looks at

the requirements of the user as well as modeling those using appropriate

implementations that make it easy to design and/or implement the new system.


AppointmentRequest

Patients

Users Staff

Appointment

Doctor

System

signUp/login

send request

appointment created

TOPIC 3

DESIGN

INTRODUCTION

Design involves producing a specific solution that meets the analyzed

requirements through enhancement of the requirements obtained during the

analysis phase. The main concern of the design phase is the specification of how

the requirements will be met by the new system. In this section of the report, the

design specifications are classified in two aspects: the structural and behavioral

model each represented by a class diagram and a sequence diagram.

STRUCTURAL MODEL

This section presents a detailed class diagram of the system to be developed. it

also includes the relationships between the classes, methods and attributes that

are associated with the class diagram. This class diagram is more detailed than

the initial class diagram in the previous chapter. Below is the class diagram.

CLASS DIAGRAM


BEHAVIOURAL DIAGRAM

A behavior diagram model defines what interactions the system been developed is

capable of handling. Behavioral models support use case diagrams, it specifies

behavior of each use case using UML diagram. A sequence diagram shows the

relationship between specific objects and allows you to understand how the set of

objects interact (NCC Education,p5-34).The development of the system under

development made use of the sequence diagrams which shows the flow of data in the

system. The sequence diagram below shows the login process for the users of the

system either the admin or user


CONCLUSION

The design phase involves enhancing of the requirements and the defining of the

aspects of the system such as the architecture. A good structural model the behavior

model help to come up with a right design for the system to be developed. The

behavioral model describes the behavior of the actors and classes in the system.


CHAPTER 4

IMPLEMENTATION

INTRIDUCTION

The implementation phase that is covered in this chapter details the evolution of the

system from analysis, design and the actual deployment of the working system. This

involves actual coding and a series of tests so as to transform the client’s requirements

and other related information into a working system.

CHOICE OF PROGRAMMING LANGUAGE

Hyper Text Markup Language (HTML)

This is a markup language that is used to create web pages and other related that is

viewed in a web browser.

CSS

Cascading style sheet (CSS) was used to make the user interface more appealing and

consistent to the users and the administrator. It is a configuration file that is used for

setting up common web page properties.

PHP

PHP is a server side scripting language. It handles the logic of a web application. It also

acts as a moderator between the presentation layer and the data layer. This language

was preferred over others due to the following reasons below

Easy to use. It is easy to use compared with other programming languages. It is

easy to learn and apply.

Cost. It is open source software meaning that it is free.

Platform Independence. It has got a high level of compatibly with popular

operation systems as well as browser.

WampServer


It is a windows web development environment that will be used to develop the

system because wampServer enables you to develop applications with PHP and

MySQL database. PhpMyAdmin will enable the management of the system.

MySQL

This is the data layer; it is used to create the database in which all the records of the

system will be stored. The database has got tables that makes saving particular data

in the right order. The retrieval and manipulation of data is done here

JavaScript

JavaScript is part of the presentation layer, used to handle user interface

JQuery

JQuery is a library that contains a JavaScript extension. It provides a large library of

functionalities that can make a front end look more attractive. However, it is

developed on top of JavaScript but has its own syntax.

SYSTEM CUTOVER

After the implementation stage of the new system, the next phase is the system

cutover. System cutover is the transitioning of the solution from its development

environment area to which is supposed to be implemented. There are four main cutover

strategies.

Parallel cutover

It is the implementation of the new system along side with the old system until such a

time when the new system has gained the users confidence, then the existing system is

replaced. This type of an approach can take weeks or months


Advantages

It is easy to detect discrepancies between the new system and the existing by

just comparing their output.

The existing system acts as a backup in an event were the new system develops

faults.

Disadvantages

It is expensive to maintain both systems running at the same time

User may not be supportive on working with the new system as they are more

familiar with the oil system.

Pilot Cutover

This involves implementing the new system into small departments or sites. It enables

more knowledge of how the system can work from a small point of view. However, it can

be also used as learning and training part of the new system. If the new system has

failed in a small site. It can be avoided

Advantages

It is ideal for on the job training

Before wider installation there is identification of errors

Disadvantages

It is an expensive approach.

The strategy has a long time scale.

Direct Cutover

This approach also known as big bang. It involves bringing into operation the new

complete new system. The old system is completely abandoned wit out the form of

transition period to cater for data migration.

Advantages


It is cheap

It is an organization wide switch over thus it is quick.

Disadvantage.

End up having live error detection which brings about risks to the operations of

the business

Phased Cutover

Here the new system is introduced in small phases depending on the sub systems of

the software. The phased Cutover enables better understanding of each subsystem. It

also provides testing as the phase is used and seen how it performs.

Advantages

The risk of errors and failure are limited

Low costs are involved

Disadvantages

The users morale is low because of the continuous change over the process

Modes of the interfacing modules will need continuous changes.

The suitable system cutover for Cancer Diseases hospital project is the parallel

approach because it has a low risk since the existing system is almost manual

based.

DATA MIGRATION

Data migration involves moving an existing systems data (database) to the new

system. Therefore, with regards to Cancer Diseases Hospital project, the data

will be copied from Microsoft word process document into the appropriate

database table of the new system. However, there will be a data verification to

confirm that data migration process was successful without any errors to losing

data.


TRAINING

Training is very important when it comes to the implementation of anything new

be it a product or a system. Proper training helps to increase the job knowledge

and the skills that are required to adopt the new system. Training takes place

after the implementation of the new system.

Face to face training: The hospital administrator and the doctors need to be

trained on how to keep in touch with the patients via the website.

Self Study: Training can be done in different ways among other approaches that

I have chosen toward user training is the creation of a user manual. Which

consist of information about the application? (See Appendix -User guide).

CONCLUSION

The implementation phase is the longest phase of the Cancer Diseases Hospital

patient’s management system because most of the tasks that were required to

be accomplished were done here, Ranged from deciding on the sailable

programming language to be used, deployment, and installation and data

migration. Finally training of which the appropriate staff were trained and the user

guide was provide.


CHAPTER 5

OTHER PROJECT ISSUES

INTRODUCTION

This chapter of the report looks at other issues of the project that have not been

taken into account but are important in order for a good project to be developed

according to the requirements specified. These include project management,

configuration and risk management.

PROJECT MANAGEMENT

For a project to be successful there is need for proper management of that

project. Project management needs planning for the project in order for all the

specifications to be taken care of. Time needs to be managed adequately and

make sure that the project is delivered on time. This was mainly done by the use

of a Gantt chart. The Gantt chart below shows how the project was managed.

March April

Week

1

Week

2

Week

3

Week

4

Week

1

Week

2

Week

3

Week 4

ACTIVITY

Completion of project

MOU

Drafting/Signing of

Memorandum Of

Understanding

Completion of project

proposal.

Drafting/Signing of


Memorandum Of

Understanding

System Analysis and

Design

-Analysis of current

system

-Gathering requirements

and designing of the new

system

Coding

-Write code for the new

system

Test and implementation

-test and implement the

developed system

-Documentation

Final Documentation

-Review and document all

the activates that took

place during the

development of the

system

Submission

-Submission of project to

the Lecturer

RISK MANAGEMENT

A risk is anything that exposes danger to a solution as the system is under

development. Almost every project has its own risks. Risk management can be

divide into four main parts.


Risk identification: helps to identify portent risks that are bound to happen.

Risk quantification: enables us to measure the impact of the risk in an event it

happens

Risk response: makes sure that any risk that has a potential risk has a response

on how to dealt with it.

Risk monitoring and potential risks: helps to monitor repeating risks and how

they can be controlled.

With regards to the system underdevelopment, the table below shows the risks

that were identified, t heir chance of occurrence, possible effect and measures

taken to counter them.

RISK ANALYSIS

After risks have been identified it is necessary to analyse and make an

assessment of the impact and likelihood of the risk

The importance of risk analysis stage is to ensure that risks with higher

occurrence probability and risks with higher impact effects are identified so that

attention can be focused on them,

Hence, a risk plan and risk assessment methods have been selected to use on

the CDH project The advantages of the risk assessment method include

1. Approch to risk analysis is simple

2. The chance of occurrence and potential impact of the risk is assessed

3. The areas in which issues lie can be seen clearly

Below is the assessment plan:

RISK OCCURANCE% IMPACT%

Lack of commitment from staff 20% 70%

Staff busy schedules 40% 80%


Continuous change of requirements 50% 70%

Conflict requirements by staff 10% 70%

Over engineering of the system 2% 50%

Time limitation 50% 80%

Availability of software and hardware

tools

10% 90%

Risk assessment Table for CDH

RISK RESPONSE

Having identified and analyses the risks the cancer diseases hospital project, the

next stage is the response to the risk when they occur. This is the proactive way

of responding to the risks else the project would be re-active to the risk.

However, the protective way to risk management was undertaken

RISK RESPONSE STRATAGIES

Below are four basic risk management response strategies

Preventive: Risks prevented from occurring by being proactive

Reduction :the likelihood of occurrence of or the likely impact of the scale

of the risk, or both the likely occurrence and impact are reduced .An

approach that is proactive is essential

Acceptance : This approach is more risky thus being appropriate to

analysis phase where risks have less impact on the project

Transference: This response is approach involving. It involves the

transferring of risks to the third party such as insurance companies.

CONFIGURATION MANAGEMENT

Configuration management is the discipline which involves the identification of

components that comprise an evaluating system. This is meant to control

changes to the components and ensuring maintainability and tractability


throughout the system. As defined by Cadle and Yeates (2001,p.221). However,

a directory tree was created to define the developer’s own configuration

management approach.

Desktop:/Computer Project

PHASE 1 (Feasibility)

Office (Microsoft office)

PHASE 2 (Analysis)

Edraw (Diagram)

StarUML

PHASE 3 (Design)

Notepad++

Wamp

Google chrome

PHASE 4 (Implementation phase)

TESTING

Testing is the procedure intended to establish the quality, performance and

reliability of something. The dynamic website developed needs to be tested to

understand any issues that need to dealt with. The test results are obtained and

then documented so as to ascertain discern between expected results of a test

and the actual results. They are different types of tests that can be done to a

system.

Black box testing: Black box testing is concerned about the functionality of the

system without consideration of the code. It looks at test input and output of the

main features of the system. This type of test was done on the system under

development.


White box testing: this testing type looks at the actual code and analysis

response to impose certain functionality. However, this test was not done to the

system under development.

Unit testing: This is the type of testing where the module of the system is tested

one by one. When each module is tested it helps to identify how it functions and

or performs as a stand-alone. Each module needs to be well tested. Hence, the

system under development was tested and below is a table that shows how the

testing was done.

TABLE UNIT TESTING

UNIT TEST 1 TEST: Patients Designed by:Mukomela banda

Data Source: Data Entry Objective: To add a

new patient appointment

request to the system

Tester :Mukomela Banda

Test Case Description Task Expected Result Actual Result

Request

appointment

This test shows

if the user is

able to request

for an

appointment

The user needs to

enter

The username

Date of request

appointment

Which department

The reason for

appointment

The appointment

request is

supposed to be

added to the

database and a

feedback is given

The

appointment

request was

able to be add

and feedback

was given

Below are screen shots for the system


INTERGRATION TESTING

This is testing the entire system to see how it works. How all the components

work and interact with each other. For his system integration testing was carried

out to determine whether an appointment can be given a patient. Below is the

test script.

Integration Testing Tests Classes :create

appointment and view

appointment

Designed by Mukomela Band

Data source: Data entry Objective: to test

whether view

appointments class is

updated when create

appointment is

Tester : Mukomela Banda

Test Case Description Task Expected Actual Result


results

Capture

appointment

creation

To test when

an a

appointment

request has

been updated

in the

database table

Select username

patients name

Select date and

time

Select doctor

Select department

Click on ok button

When the

appointment

has been sent

to the database

.the patent

must be able to

see that an

appointment

has been

created for

them

The patient is

able to see that

an appointment

has been created

for them and is

able to view.


CONCLUSION

In conclusion, this chapter has looked at the need for project management, how it

will be handled in the project. Risk management has been taken into

consideration as to how know how to handle risks if any were to rise and

configuration management too.


CHAPER 6

CONCLUSION

PROJECT EVALUATION

In order evaluate the Cancer Disease Hospital patient’s management system. It

was imperative that the predefined aims, objectives and goals of the project are

considered in relation to the requirements that were fulfilled by the system.CDH

patients management system is designed to facilitate patients appointments

through the use of web based application system that can be accessed via the

hospital intranet or the internet. The attainment of this was through provision of

not only a system that is efficient but also reliable and easily accessed.

The aim of the project was to develop an efficient and reliable web application

patient managements system that would greatly improve the day to day

operations of CDH and eventually lead to excellent management of patients

appointments.

CRITICAL EVALUATION

In order to attain a thorough evaluation process. The critical assessment of the

system must be looked at. Although the evaluation of the project aim and

objectives had revealed that the project a success. But the new system

developed has got flow as indicated below.

System limitations

Accessibility: The system can only be accessed by the patient after they have

signed up, the administrator, doctor and staff members.

Usability: The graphical user interface is only in English. This can present

problems to users who are not conversant with the English language.


Security: There is no automated system to back up the data on the system.

Hence, the system administrator ought to always remember to backup data.

PROBLEMS EXPERIENCED

During the development of the system there were some challenges I face such

as

Interviewing patients proved to be difficult as most of them were not in the

best of their health.

There was time limitation, contrary to the initial view that the application

was very involving.

The application was developed using php programming language and for me it

was a challenge as I was learning for the first time and applying it in my project.

This made me spend a lot of time in figuring out the error that I was having.

FEATURES OF FUTURE PROJECT

My future projects would include the following features that have not been

included in the system that has been developed.

A telephone capacity so that the application is able to send messages

directly to the patients phone for any notifications or changes.

A provision that will enable patients to view their medical file online.

Inclusion of pharmaceutical review point

Inclusion of images to show which doctor is viewing his account

Finally, from the projects analysis, design, and implementation I have

obtained information on how to work in the in society. Throughout the

development of the project it has greatly improved my communication skills

and confidence in facing real world projects. However, developing the

dynamic website has also improved my programming skills using php and


MySql. The hospital management was happy with the system that was

developed and made it clear that the project did meet their requirements.

All in all, the project developed was a success and I am very glad and humble

to have helped out in the fight against cancer.


REFRENCES

Bennet, S, McRobb, S & Farmer 2006, p.145, Object-Oriented Systems Analysis and Design Using UML.

Boddy, D. (2002) Management an Introduction, 2nd ed., Prentice hall:

Pearson Education

Curtis, R & Cobham, D 2008, Business Information Systems Analysis, Design and Practice, Pearson Education Limited, London

Cadle, J & Yeats, D 2001, Project Management for Information Systems, Pearson Education Limited, England

Nixon,R (2012).Learning PHP,MSQL, Javascript and CSS. 2nd

Edition .USA: O'Reilly

NCC, 2008. The Purpose of Systems Analysis. In Systems Analysis. NCC

Education Services.

Sindhe, V., 2009. Software Testing Help. [Online] Available at:

http://www.softwaretestinghelp.com/software-testing-terms-complete-

glossary/ [Accessed 12 April 2014].

Tudor, D.J. & Tudor, I.J., 2010. The DSDM Atern Student Handbook.

Cheshire: Galatea Training services Ltd.


http://www.softwaretestinghelp.com/software-testing-terms-complete-glossary/

http://www.softwaretestinghelp.com/software-testing-terms-complete-glossary/

APPENDIXESAll the appendixes are in the folder Appendixes

APPENDIXES 1TEST SCRIPTS

APPENDIXES 2 SYSTEM REQUIRMENTS

APPENDIXES 3CODE

APPENDIXES 4USER GUIDE


L5 PROJECT

Documents

project supervisor

hospital faces

cancer disease hospital

retrieval of patients

allocation of appointments

way appointments

current manual system

web based solution