2013300120

2013300151
2013300018

Systems Analysis and Design

Case Analysis 2
Medical Appointments System
Section A
A1.

a) Context diagram of the Medical Appointments System

Patient
information,
Appointment
details, Check-in 0
details, Appointment
Cancellation MEDICAL details
PATIENT details APPOINTMENTS DOCTOR
SYSTEM
Booked Appointment
Appointment outcomes
Details,
Appointment
outcomes
 b) Top level dataflow diagram of the Medical Appointments System

Unknown Patient 1
Number Patient Number
CONFIRMATION PATIENT RECORDS
PROCESS Unregistered
Patient Number
Unregistered Patient
Number
Name, Date of Birth,
Address, Contact 2
number Patient Information
REGISTRATION
PROCESS
Registered Registered Patient Number
Patient Number

Patient Information
Booking 3
details
Appointment APPOINTMENT RECORDS
MAKE
details
APPOINTMENT
PATIENT
Booked Available time slots
appointment
Booked appointment details
4
Registered Patient Number
CHECK-IN
PROCESS
Appointment
outcomes Checked-in Patient Information

5
Checked-in Appointment Outcome, Details of
Patient
DOCTOR APPOINTMENT prescription
Information
PROCESS
Appointment
Outcome, Checked-in Patient Information
Details of
prescription 6 Checked-out Patient
Information
APPOINTMENT RECORDS
DEREGISTER
PROCESS

Booked appointment details

Cancellation 7
details Cancellation details
CANCELLATION
Confirmed Cancellation details PROCESS
A2.
a) Difference between a waterfall and an iterative/incremental System Development Life
Cycle (SDLC)

In a waterfall model, each phase must be completed before the next phase can
begin and there is no overlapping in the phases as shown in the figure below. It illustrates
that software development process in a linear sequential flow which means that any
phase in the development process begins only if the previous phase is complete.

In an iterative or incremental model, the whole requirement is divided into various

builds. Each module passes through the requirements, design, implementation and
testing phases. A working version of software is produced during the first module, so we
have working software early on during the software life cycle. Each subsequent release
of the module adds function to the previous release. The process continues till the
complete system is achieved.
The figure above shows how a feasibility study is conducted through an application of a
waterfall SDLC. Here, the whole process of conducting a feasibility study is divided into
separate phases. Typically, the outcome of one phase acts as the input for the next phase
sequentially All these phases are cascaded to each other in which progress is seen as
flowing steadily downwards through the phases. The next phase is started only after the
defined set of goals are achieved for previous phase and it is signed off, so the name
"Waterfall Model". In this model, phases do not overlap. Each phase of development
proceeds in strict order.
 Iterative or incremental SDLC can be clearly illustrated in painting. When we
work incrementally, we are adding piece by piece but expect that each piece is fully
finished. When we work iteratively, we are breaking down processes of painting into
smaller chunks to finish the piece.

b) Recommended approach for developing a system for medical appointments.

We would recommend to use the iterative or incremental model because not only
that the model generates working software quickly and early during the software life cycle,
easier to test and debug during a smaller iteration, and easier to manage risk because
risky pieces are identified and handled during iteration but this model is more flexible and
customer can respond to each built or increment. Moreover, the requirements of the
complete system are clearly defined and understood based on the given. The biggest
advantage to doing system development iteratively is that we’ll avoid getting into long
system development cycles where work can drag on indefinitely without user feedback.
In developing a Medical Appointment System, the center can already start to use the
system when the system for recording patients’ name and doctors’ name is finished.

A3.
a) General criteria used to decide which OTS software applications are suitable
1. Does the package meet our current requirements: How much configuration /
customization would be required and how easy would this be to do? Would the software
require us to make changes to our existing business processes?
2. Does it meet our future requirements: Will the package meet requirements that we
can anticipate having in the future?
3. Implementability: What platform does the package require? Will we be able to integrate
it with our existing systems?
4. Support: What is available in terms of training? Consulting? Documentation?
Community? How stable is the supplier?
5. Cost: How much will it cost to implement (license, hosting, customization), maintain,
upgrade, modify?
6. Deliverability: Will customization be done through APIs (good) or will it need to be done
by modifying the source code (bad)? How difficult is it to test the package (especially in
an automated fashion)?
7. Supplier – The supplier is one of the most important thing to consider when buying the
package. How stable is the supplier when it comes to supplying the software?
8. Manageability- It is also needed to consider if the OTS software could be easily handled
and used by the user in managing its business aspects.
9. Success - One route to mitigating the perceived risk in OTS software is to choose a
package based on its historical and current success, as measured by the financial
success of the software package's producer and the size of the associated network.
10. Standardization - Standardization can be achieved at various levels and in many forms
in packaged software. it is important to choose the type that is right for the particular
organization, according to its available resources and constraints
 b) Other options
Open-source software (OSS) can be an alternative. It is a computer software with its source
code made available with a license in which the copyright holder provides the rights to study,
change, and distribute the software to anyone and for any purpose. Open-source software may
be developed in a collaborative public manner. According to scientists who studied it, open-
source software is a prominent example of open collaboration. The term is often written without
a hyphen as "open source software".

Section B
B4.
a) Normalized table

First Normal Form

Doctor Doctor Doctor
No. Name Room
No.
1 Smith J G5
1 Smith J G5
3 Mills D G2
4 Fitzgeral G3
dJ

Doctor Appointment Appointment Appointment Appointment Patient Patient

No. Code Date Time detail No. Name
1 2016/702 2/9/16 10.20 - 217 Jones J
1 2016/717 3/9/16 9.40 - 357 Patel J
3 2016/726 3/9/16 13.40 - 87 Brown G
4 2016/705 2/9/16 11.20 - 412 Wilson P

Second Normal Form

Doctor Doctor Doctor

No. Name Room
No.
1 Smith J G5
1 Smith J G5
3 Mills D G2
4 Fitzgeral G3
dJ
 Doctor Appointment
No. Code
1 2016/702
1 2016/717
3 2016/726
4 2016/705

Appointment Appointment Appointment Appointment Patient Patient

Code Date Time detail No. Name
2016/702 2/9/16 10.20 - 217 Jones J
2016/717 3/9/16 9.40 - 357 Patel J
2016/726 3/9/16 13.40 - 87 Brown G
2016/705 2/9/16 11.20 - 412 Wilson P

Third Normalized Form

Doctor Doctor Doctor

No. Name Room Doctor Appointment
No. No. Code
1 Smith J G5 1 2016/702
1 Smith J G5 1 2016/717
3 Mills D G2 3 2016/726
4 Fitzgeral G3 4 2016/705
dJ

Appointment Appointment Appointment Appointment Patient Patient No. Patient Name

Code Date Time detail No. 217 Jones J
2016/702 2/9/16 10.20 001 217 357 Patel J
2016/717 3/9/16 9.40 002 357 87 Brown G
2016/726 3/9/16 13.40 003 87 412 Wilson P
2016/705 2/9/16 11.20 004 412

b) ERD of Medical Appointments System

B5.
a) Explanation of relationships between classes
(i) Association
(ii) Aggregation or Composition
(iii) Generalization/Inheritance

b) Explanation of how to map an inheritance hierarchy in a class diagram to

relational database tables

1. Only the superclass is implemented as a table. Attributes of subclasses become

attributes of the superclass table and have null values when they are not used. This
approach is in particular useful when subclasses differ from their superclass more in
behavior (operations) than in attributes.

2. Only the subclasses are implemented as tables. The attributes of the superclass are
kept in the subclass tables. This works if the superclass is abstract.

3. All the classes are implemented as separate tables. To retrieve the data for a subclass,
both its own table and the table of its superclass must be accessed.

B6.
a) Brief explanation of ‘object interaction and collaboration’ in object-oriented systems
Object-oriented design is a design strategy where system designers think in terms of
‘things’ instead of operations or functions. Rather than a program being designed as a set of
functions that interchange data through their parameters and through a shared memory (global
variables), an object-oriented program is made up of interacting objects. Objects maintain their
own local state and define operations on that state information. They hide information about the
representation of the state and hence limit access to it.

b) Sequence diagram for the use case ‘Check in’ in the Medical Appointments system
c) State machine/chart for the class Appointment in the Medical Appointments system

Arrange

Arranged

Check in

Checked in

Complete

Completed

Archive