Online
Health Monitoring System
Project Management Plan
COP4331, Fall, 2014
Modification history:
|
Version |
Date |
Who |
Comment |
|
v0.0 |
|
G. H. Walton |
Template |
|
v1.0 |
|
C. N. McCue |
First draft |
|
V1.1 |
|
C. N. McCue |
Minor grammar and spelling corrections |
|
v1.2 |
|
C. N. McCue |
Minor grammar and spelling corrections |
Team Name: Team 14
Team Members:
· Jon Carelli - email - web page
· Chris McCue - email - web page
· Chris Chaffin - email - web page
· Ethan Pitts - email - web page
· David Gundler - email
- web
page
· James Luke - email - web page
Contents
of this Document
Tools and Computing Environment
Table of Work Packages, Time Estimates, and Assignments
Plan for tracking, control, and reporting of progress
The Online Health Monitoring System allows online management of patient health care. Doctors electronically manage patient care by setting health appointments and pill schedules. Patients are automatically sent text alerts concerning appointments and pills to take. Doctors and patients can communicate with each other via text messaging or video chat.
·
Software
Requirement Specification
· Coding Standard:
Code should be concise and readable. Methods will be no longer than one page. Indentation of four spaces will be required for each nested statement. Methods longer than ten lines will require documentation above the method. Variables and methods will be camel-cased. Class names will use upper case letters for each new word. Methods, classes and variables should clearly indicate what function they are performing.
· Document Standard:
Document standards will be based off of the artifact templates. Font will be 10 point Times New Roman. Heading will be in bold-face Times New Roman 10 point font. Paragraphs will be single-spaced. There will be a double-spacing between paragraphs. All documents are expected to be proofread and checked using spelling and grammar checking. Modification history will include version, date, author and comment fields. The table of contents will list all the subdivisions of the document. Large figures and tables will be attached as an appendix.
· Artifact Size Metric Standard:
Document size
metrics will calculated based on the total of sections completed divided by
total sections. For example, if seven
out of fourteen sections are completed, the document will be considered 50%
complete. For document revisions, if two
subdivisions need revision and one is complete, 50% will be considered
complete.
Presentations will
be measured by slides complete divided by expected number of slides. If a presentation consists of twenty slides
and five are completed, the presentation will be considered 25% complete.
Coding percentages
will be based on the amount of classes and methods determined in the design
phase. If there are ten methods expected
and seven of those methods are complete, 70% will be considered completed.
The Project 14 Team members are Chris McCue,
Jon Carelli, Chris Chaffin, Ethan Pitts, David Gundler and Luke James. Our goal is to divide the administrative and
technical tasks equally among team members.
Each member should have a main administrative artifact and module from
the overall system. On the
administrative side, Chris McCue is the project manager. Other team administrative tasks include
Concept of Operations (Ethan), Software Requirements Specification (Jon and
David) and the Test Plan (James Luke/Chris Chaffin). On the technical side, Jon Carelli has taken
the initiative. Jon is also maintaining
the team website.
We feel that it is crucial to maintain team communication throughout the life cycle of this project. Therefore, team members are required to weekly submit an individual log. As individual web pages are developed, the individual log will be posted in web page form. These will then be summarized in a team log. Based on the log, corrective actions will be taken to ensure deadlines are met. As needed, team members will communicate by email and cell phone. Face-to-face meetings will be held concerning each major deliverable.
|
Artifact |
Due Dates |
|
Meeting Minutes |
Same day as meeting |
|
Individual Logs |
|
|
Group Project Management Reports |
|
|
Concept of Operations |
|
|
Project Plan |
|
|
SRS |
|
|
High-Level Design |
|
|
Detailed Design |
|
|
Test Plan |
|
|
User's Manual |
|
|
Final Test Results |
|
|
Source, Executable, Build Instructions |
|
|
Project Legacy |
|
Our team will follow a hybrid model. This will consist of phased development and
the prototyping model. The Online Health
Monitoring System lends itself to an incremental phased development
approach. The system can roughly be
broken into two parts: a scheduler and
communications. Communications can
further be decomposed into text messaging and video chat. Therefore, these can be developed
independently of each other and then integrated into the main scheduler module
gradually.
In addition to the incremental phased
development approach, the prototyping model adds more structure without being
overly rigid. Most team members are
relatively inexperienced with administrative duties. Therefore, a flexible model, such as the
prototyping model, is necessary. It is
anticipated that requirements will undergo refinement and revision during the
course of this project. The prototyping
model allows for this repeated investigation of requirements and design. In addition, team members are relatively
inexperienced in JavaScript. Given this
uncertainty, it is important to use a model which reduces risk and uncertainty,
hence, the prototyping model. The prototyping
model provides a balance of structure and flexibility which suits this team.
Tools and Computing
Environment
The computing environment will consist of Windows 7 and 8 operating systems. Tools shall include HTML, JavaScript, SMS for text messaging, MySQL and jQuery libraries. Video chat will consist of a readily available component, such as Skype.
Configuration Management
Configuration management is the task of all team members. Each team member is responsible for version and change control of the artifact he has completed. Artifacts will be placed on the team website and sent to any other team member requesting the artifact. Project management reports will list all artifacts completed.
Concerning administrative documents, the
Project Manager will review these documents.
If the Project Manager is unable to review a document, the
responsibility for reviewing that document will be delegated to another
available team member. The reviewer will
then report the results to the Project Manager.
If a document does not meet document standards, the Project Manager will
ask the original author to revise the document to meet standards or the
document will be assigned to another available team member. Since each major deliverable consists of
multiple documents, these documents will be assigned to individuals. The target for each individual to submit his
artifact is two weeks before the deliverable due date. This allows for a two-week window in which to
check for quality assurance. In the end,
all original and revised documents will be sent to the Project Manager and
placed on the team website.
Once a code module is completed, the Project Manager will assign another team member to review it according to team coding standards. The results will be reported the Project Manager who will relay the results to the programmer. The programmer will have a maximum of two weeks to make the necessary revisions.
There are three identifiable risks at this point: JavaScript, video chat and text messaging. Many team members are inexperienced in JavaScript. However, Jon has JavaScript experience. He sent team members a tutorial on JavaScript. One of the current action items for every team member is to learn JavaScript. We believe that the video chat component will be the most complex module of code. Luke has researched options for video chat which will be discussed further during the design phase. Text messaging will also require more time than other modules. David has already researched text messaging. This will be an action item in the near future. Although there is low to moderate risk, we are implementing a plan to eliminate risk as early as possible.
Table of Work
Packages, Time Estimates, and Assignments
See Appendix A.
See Appendix B.
The system is decomposed into five
phases: three documentation phases,
group formation phase and a coding phase.
The group formation phase is 100% complete. Because the two weeks associated with group
formation is considered a substantial portion of the allotted 16 week project
cycle, it was considered as Phase 0- 5% of the project. Phase I consists of documentation. Phase I is further decomposed into drafts and
revisions. Each template has a certain
amount of subdivisions. If a template
has ten subdivisions and four of the subdivisions have been completed, 40% of
the document will be considered completed.
For revisions, if two subdivisions need revision and one is complete,
50% will be considered complete. In
addition to documentation for Phases II and III, presentations are a further
subdivision. If a presentation is
expected to consist of twenty slides and five are completed, the presentation
will be considered 25% complete. For the
Phase II design stage, the number of diagrams, classes and methods expected
will be totaled. The number of these
completed divided by the total will yield a percentage. Coding percentages will be based on the amount
of classes and methods determined in the design phase. If there are ten methods expected and seven
of those methods are complete, 70% will be considered completed.
In summary, percentages are considered the most useful metric. The project has been divided into phases, sub-phases and tasks. Each phase has an estimated percentage weight of time and effort associated with it. Each phase is further decomposed into sub-phases with associated percentage weights. Each sub-phase is further decomposed into tasks with associated percentage weights. In this way, if a task has a 2% weight and an individual’s weekly log reports 50% of that task completed, 1% of the project will be considered completed. The bi-weekly Project Management Report will reflect a summary of these reported percentages.
Plan for tracking, control, and reporting of progress
Each team member will post the following
information weekly: each action item assigned, time spent on that action item,
percentage completed of the action item and cumulative percentage completed of
that action item. In addition, each team
member will estimate the aforementioned items for the next week. Team members will also report issues
encountered and resolutions to these issues.
Furthermore, a team member will summarize his overall status in one or
two sentences. Initially, the first two
individual logs will be emailed to the project manager. Afterward, individual logs will be posted on
individual web pages. A reminder email
will be sent Wednesday. Replies are
expected by
The project manager will perform a weekly analysis
of individual logs. Weekly analysis
consists of reading and analysis of individual logs. Time, percentage completed, total percentage
completed will be analyzed. Quality and
risks will be assessed and, if necessary, corrective actions will be taken. The weekly analysis deadline will be Monday
at
In addition, the project manager will issue a
bi-weekly Project Management Report. The Project Management Report will include
one or two sentences summarizing overall status, expenditures, technical
progress metrics, an updated PERT chart and one or two sentences of
comments. Comments will indicate any
planned changes or corrective actions.
Template created by G. Walton (GWalton@mail.ucf.edu) on
This page last modified by Chris McCue (christopher.mccue@knights.ucf.edu) on 9/25/14