American International University – Bangladesh (AIUB)

Project Title: Software Project Management Plan for Medical Assistant

Name: Ridwan Mahmud
ID: 17-34172-1
Course: Software Development Project Management
Section: B

1|Software Development Project Plan

 Table of Contents
I
Introduction 03
Project Title 03
Objective 03
04
Justification 03-04
Stakeholders Analysis 04
Feasibility Study 05

Effort Estimation 06-07

Activity Diagram & Schedule Planning 08-10

Risk Analysis 11-13

Conclusion 14

2|Software Project Management Plan

Introduction: This document serves as the project plan for the medical assistant. The
content of this document is divided into four chapters: Stakeholders analysis, Risk
analysis & Feasibility, System components & effort estimation.
Nowadays, in our country doctor’s checkup 2/3 patients at a time in hospital. When
doctors observing patients their disease symptoms can be ambiguous. In that situation
doctor sometimes made medical error and doctor’s prescription might be harmful for
patients. When a doctor faces a new disease symptom then doctor might be prescribed
from guessing the disease. Thereby patient’s life can be in danger. Sometimes it seen that
patients can’t remember to carry or can lost their previous prescription or reports. Then
doctors are giving prescription without knowing patient’s previous medical records and it
becomes harm more than good.

System users:
Admin - Government or hospital authority who will hire or assign doctor in the
system, can appoint receptionist to a doctor.
Doctor - Prescribed patient, communicate with another doctors, see appointment list.

Pathologist – Arrange test object, Arrange & insert test result, communicate with other
pathologist/pathology assistant.
Patient - Can login, see prescription and see doctor’s information.
Receptionist - Make appointment, provide patients account, collect patient’s previous
medical history from patient and input in the system and take payment from patient.

Project name: Medical’s assistant

(Desktop and mobile-based application)

Objective:
The main purpose/objective of this system is to make easier the whole medical system
which include patient, doctors, administration, pathology, reception all of those problem’s
solution through a single system. By this system all of medical related activity (doctor’s,
patient’s, administrative, receptionist’s, pathologist) become easier and more flexible for
all.

Justification:
My system will be medical (doctor, pathologist, admin, patient) assistant. It will help
doctor when doctor prescribe the patient about disease, suggesting medicine, suggesting
test, suggesting admit to the hospital situation or not. It will help patients to find out the
best doctor according to his/her medical problem, he/she can take an appointment as
his/her selected time.

3|Software Project Management Plan

If the doctor isn’t available in his/her selected time then it will be helpful for him/her to
select another doctor from same department in same time slot.
Patient can consult with doctor at any time through this system. It will records patient’s
previous medical history. Suggest the doctor about patient’s previous history when
prescribing the patient. When a doctor facing a new problem/diseases symptoms doctor
can communicate with other doctors by posting the symptoms status. Doctor can accept
system suggestions about disease or not because doctor is the superior being in that
environment. Patient can see their prescription from home or workplace. Pathologist
input test result, update test result in the system and doctors will be up to date about
patient disease and problems through the system. Patients can also be up to date about
their report. Admin can observe others regular activity through the system.

Stakeholders Analysis:
Stakeholders are those people who involved in the project or affected by project activities
and also include the project sponsor, project team, support staff, customers, users,
suppliers, and even opponents to the project.

There Stakeholders are categorized by:

Interface Stakeholders - Those who function internally and externally to the Medical
Sector. For example, Govt. (Ministry) for government medical/hospital, Trustees and
Senior Staff for private medical sector who represent the Hospital's interests.

Internal Stakeholders - Those who operate within an organization (medical hospital), in

this case generally specific organization’s staff.

External Stakeholders - Stakeholders who are impacted or impact the

Organization/Hospital, but are not employed by the Organization/Hospital. According to
this there is also three categories: those that provide inputs like suppliers and those that
rely on the hospital/organization outputs, competitors and special interest groups.

4|Software Project Management Plan

Feasibility study:
There 3 types of feasibility study are given bellow: -
Economic feasibility
Analysis of a project’s costs and revenues in an effort to determine whether it or not it is
logical and possible to complete.
Technical feasibility

Technical feasibility helps organizations determine whether the technical resources meet
capacity and the team is capable to build the system. Technical feasibility also involves
evaluation of the hardware, software, and other technical requirements of the proposed
system.
Operational feasibility
Operational Feasibility, we consider whether the current system become implemented
using existing human resource or not. To find functional feasibility we determine
whether the proposed solution can participate in existing operations and whether the right
information in the right time is, provide to end users. Operational feasibility of our
proposed system is modularized.

5|Software Project Management Plan

Effort estimation:
For effort estimation, we are going to use the COCOMO (Cost
Constructive Model).
Based on SLOC characteristics, here it operates according to these equations which are
given bellow;
1) Effort = PM = Coefficient <Effort Factor> * (SLOC/1000) ^ P
2) Development time = DM = 2.50 * (PM) ^ T
3) Required number of people = ST = PM / DM
Here,
PM- Person-months needed for project (labor working hours)
SLOC- Source lines of code
P- Project complexity (1.00-1.20)
DM- Duration time in months for project (week days)
T- SLOC-dependent coefficient (0.29-0.35)
ST- Average staffing necessary

Coefficient
Software Project Type P T
<Effort
Factor>

Organic 2.2 1.0 0.35

Semi-detached 2.8 1.05 0.32

Embedded 3.4 1.12 0.29

According to the definition, my system is an organic type of project.

When the project deals with developing a well understood application
program then the software development project will be considered as
organic type of project. In organic type, the size of the development team
is reasonably small.

6|Software Project Management Plan

 1) Effort = PM = Coefficient<Effort Factor>*(SLOC)^P

PM = 2.2*(80) ^1.00[As Coefficient <Effort Factor> = 2.2, SLOC = 50,000/1000 = 50, P = 1.0]
= 110

2) Development time = DM = 2.50*(PM)^T

DM = 2.50 * (110) ^ 0.35 [As PM= 110, T = 0.35]

= 12.955

3) Required number of people = ST PM/DM

ST = 110/12.955 [As PM = 110, DM = 12.955] = 8.50

7|Software Project Management Plan

Scheduling:
Label Task Week Duration(week) Precedence

A Field study 1st-2nd 2

B Prepare Requirement Scenario 2nd-3rd 1 A

C Identify user Requirements 3rd 1 B

D Design use case diagram 4th-6th 3 C

E Design Activity Diagram 6th-7th 2 C

F Design ER Diagram 7th 1 C

G Design class Diagram 8th-9th 2 C

H Coding 9th-20th 11 DEFG

I Construct Test Plan 21st-22nd 2 H

J Testing Software 23rd-27th 4 I

K Deployment 28th 1 J

L Documentation 27th- 30th 4 J

Total project time: 30 weeks

8|Software Project Management Plan

Activity Diagram:

Enter
Doctor’s/Patient’s/Pa
thologist ID, password

[verified] [not verified id/password]

Enter doctor’s/patient’s
phone number or test
no.

[Matched]

[Not matched]

Enter patient’s details,

doctors’ details, medical
View patient’s history,
history, report details
prescription, doctor
details, report result

9|Software Project Management Plan

**Plan Scheduling

10 | S o f t w a r e P r o j e c t M a n a g e m e n t P l a n
 Risk Analysis:
Risk Check List- These are the types of risks associated with project development

Product size (PS) — risks associated with the overall size of the software

to be built or modified

Business impact (BU) — risks associated with constraints imposed by

management or the marketplace

Customer characteristics (CU) — risks associated with the sophistication of
the customer and the developer's ability to communicate with the customer

in a timely manner

Process definition (PR) — risks associated with the degree to which the
software process has been defined and is followed by the development

organization [autopilot performance fixing with XP]

Development environment (DE) — risks associated with the availability
and quality of the tools to be used to build the product [resource

allocation plan]

Technology to be built (TE) — risks associated with the complexity of the
system to be built and the "newness" of the technology that is packaged

by the system

Staff size and experience (ST) — risks associated with the overall technical
and project experience of the software engineers who will do the work

11 | S o f t w a r e P r o j e c t M a n a g e m e n t P l a n
Risk Table:

Risk Category Probability Impact RMMM

Misunderstood requirements PS 30% 2 Requirement engineering

Customer will change PS 40% 2 Change control process

requirements

Less reuse than planned PS 50% 2 Proper management

Delivery deadline will be BU 40% 2 Float should be proper use

tightened
Funding will be lost CU 30% 1 Seek additional funding

Staff unexperienced ST 10% 2 Training

Project can go over budget CU 35% 1 Historical data, estimate

using multiple techniques,
standardization of methods

New technology TE 30% 3 Training

High staff turnover ST 40% 3 Increase job satisfaction

Too difficult to develop DE 25% 3 Technical analysis

Lack of externally supplied DE 40% 3 Formal specification,

components contractual agreement

Product fails to deliver the BU 40% 1 Market research

business objective

Performance issues BU 60% 3 Improve quality

Lack of users’ involvement CU 60% 3 Involve user in

development, feedback

Lack of communication ST 40% 4 Project charter, plan

meetings

Lack of interoperability BU 20% 3 Improve quality attributes

12 | S o f t w a r e P r o j e c t M a n a g e m e n t P l a n
 RMMM - Risk Mitigation, Monitoring & Management
Plan impact values: -
1) Catastrophic
2) Critical
3) Marginal
4) Negligible

13 | S o f t w a r e P r o j e c t M a n a g e m e n t P l a n
Conclusion:
Project management is very important for the organization to govern the project. So, in
this project a team leader needs to understand project lifecycle, risk and risk
management in order to create the strategy for the project to be successful. Moreover,
applying the proper tool during the process duration estimation by considering the iron
triangle can lead to reach the goal of the project.
However, the team project needs to keep in mind that when the project seems to not
achieve the goal, they have to stop the project before they are going to spend beyond
the budget. And they have to when to stop it(project).

14 | S o f t w a r e P r o j e c t M a n a g e m e n t P l a n