table of contentsfaculty.kutztown.edu/tan/csc354/datafiles/new/354/a… · web viewthe mobile app...

Software Project Plan October 12, 2018

1

Software

Project

PlanVersion 2.1

App Team

Tyler Bartnick

Duong Doan

Andrew Reichard

Ryen Shearn

Peter Shively

Phillip Yoder

CSC 354

Dr. Tan


Table of ContentsTable of Contents......................................................................................................................................... i

REVISION HISTORY........................................................................................................................................ i

1.0 INTRODUCTION..............................................................................................................................1

1.1 Abbreviations.....................................................................................................................................1

1.2 Project Description............................................................................................................................1

1.3 Project Scope.....................................................................................................................................2

1.4 Major Functions.................................................................................................................................2

1.5 Users and User Environment.............................................................................................................2

1.6 Performance Issues...........................................................................................................................2

1.7 Management and Technical Constraints...........................................................................................2

2.0 PROJECT ESTIMATES..............................................................................................................................4

2.1 Team Experience...............................................................................................................................4

2.2 Estimates...........................................................................................................................................4

2.2.1 Cost.................................................................................................................................................4

2.2.2 Schedule.........................................................................................................................................4

2.3 Resources..........................................................................................................................................5

2.4 Team Structure..................................................................................................................................5

3.0 RISK MANAGEMENT..............................................................................................................................7

4.0 PROJECT SCHEDULE...............................................................................................................................9

5.0 TEAM MEETING SCHEDULE.................................................................................................................10

6.0 SYSTEM ARCHITECTURE DIAGRAM......................................................................................................12

7.0 CONTEXT DIAGRAM.............................................................................................................................13

8.0 FEASIBILITY..........................................................................................................................................14

i


REVISION HISTORYBelow is the up-to-date revision history chart. As changes to this document are made, the chart will be edited to include it.

Version Date Description Editor

1.0 9/20/18 Added to sections:

1.0 Introduction

1.1 Project Description

1.2 Project Scope

1.3 Major Functions

1.4 Users and User environment

1.5 Performance Issues

1.6 Management/Tech Constraints

Phillip Yoder

9/20/18 Added to sections:

2.2 Estimates

2.2.1 Cost

5.0 Team Meeting Schedule

Duong Doan

9/20/18 Added to sections:

2.1 Team Experience

2.3 Resources

2.4 Team Structure

Andrew Reichard

9/20/18 Added to Sections:

1.0 Introduction

Peter Shively

ii



1.2 Project Scope

3.0 Risk Management

4.0 Project Schedule

6.0 System Architecture Diagram

7.0 Appendix

9/20/18 Added to Sections:

2.4 Team Structure

5.0 Team Meeting Schedule

Ryen Shearn

2.0 10/6/2018 Modified Sections:

Page numbering


Peter Shively

2.1 10/11/2018 Modified Sections:

2.2 Estimates

2.2.1 Cost

2.2.2 Schedule

Duong Doan

10/11/2018 Modified Sections:

2.1 Team Experience

2.3 Resources

2.4 Team Structure

Andrew Reichard

10/11/2018 Modified Sections

Moved Abbreviations to section 1.1

Section 8.0 moved to 7.0


5.0 Team Schedule

Peter Shively

10/11/2018 Added Sections:

7.0 Context Diagram

Ryen Shearn

ii


10/11/2018 Added Sections:

8.o Feasibility

8.1 Economic Feasibility

8.2 Schedule Feasibility

8.3 Collaborative Feasibility

8.4 Technical Feasibility

8.5 Resource Feasibility

8.6 Over Feasibility Assessment

Tyler Bartnick

10/11/2018 Modified Sections:

3.0 Risk Management

Phillip Yoder

Table 1 – Revision History

iii


1.0 INTRODUCTIONThe purpose of this SPP for the LTC-TMS app development team is to plan and understand the important features of the app and tablet versions as the project evolves. They will often refer to this document to ensure that everything is going smoothly. The main goals of the app development team are to allow CNAs and patient family members view patient vitals and daily records, as well as the facility’s schedule and announcements; CNA's will have specific features associated with their position.

1.1 Abbreviations

The acronyms and terminology used within this document is listed below in alphabetical order:

- CNA – Certified Nursing Assistant

- CNO – Chief Nursing Officer

- HIPAA – Health Insurance Portability and Accountability Act

- KU – Kutztown University of Pennsylvania

- LTC – Long Term Care

- MCU – Ming Chuan University

- MIT – Massachusetts Institute of Technology- NoSQL – refers to a “non-SQL” database

- SQL – Structured Query Language

- TMS – Task Management System


The core idea behind the LTC-TMS is to allow the end users to check on a patient’s vitals, daily records; more details will be discussed in section 1.3, Major Functions. <There will be different versions with different information to be accessed, depending on whether the user is a family member or CNA. > There are various versions of the app that allow different levels of information and access based on role and device type. The CNAs specifically have access to the tablet app for use only within the facility. The CNO and Director have access to the desktop app, while family members have access to the mobile app.

1


For family members, they can view daily records, vitals, and the patient’s portfolio. Examples of accessible information for family members include step count and heart rate, facility announcements, facility hours of operation, and providing feedback on their experience.

The CNA app version is similar with a few minor differences. They can see their own portfolio and past work hours. CNAs also have a tablet version that allows them to input the daily status and vitals of the patients.

1.3 Project Scope

LTC-TMS will aim to reduce the paper work of the facilities staff, have data available digitally with an increased retrieval efficiency, effective hierarchal communication, and increased productivity. As well as let the families check on the patient quickly and conveniently.

1.4 Major Functions

The major functions will depend on who is using it, though there are major similarities. Those are that the user can see the daily records, vitals, and the patient’s portfolio, such as step count and heart rate, announcements for the facility, as well as it’s hours of operation, and give feedback on their experience with the app.

The differences between the CNA and family perspective is that they CNAs can see their own portfolio and past work hours.

The functionalities that are only accessible if the user is a CNA using the tablet version allows them to input the daily status and vitals of the patients.

1.5 Users and User Environment

The app will be used by CNAs and family members outside of the facility to check up on the patient and see how they are doing. This means that the design will have to be simple and clean, the information they need to see should be quickly accessed and fit into the borders of the device screen without any over lapping of text or images.

1.6 Performance Issues

Potential performance issues can arise from a device software update that causes app incompatibility, connection problems that prevent a stable internet connection loss, a change or changes from programming causing a loss of connection to the database.

1.7 Management and Technical Constraints

A management constraint could be scheduling and communication problems with the MCU and KU teams. Since there is a twelve-hour (thirteen hours during Daylight Savings Time) time difference between the two teams, there is no obvious time available for them to meet. Added on, each team has different holidays they celebrate and the possibility of natural disasters, this makes it very difficult for the teams to meet, ask questions, and discuss the project in greater

2


detail. Lack of experience using the database or languages used will also lead to problems and hiccups along the way.

Some technical constraints could be iOS or Android releasing a new phone that has unusual dimensions and ruin the constraints on text boxes and images set up or having a system update that isn’t compactable with the app’s program anymore.

A lack of experience from the team members in writing with programming languages being used or working on a project of this size could lead to a dead end where no one knows how to fix a problem.

3


2.0 PROJECT ESTIMATES

2.1 Team Experience

The Mobile App development team has limited experience working with iOS and Android applications. Some members have experience with the iOS platform, while others have worked with Android before. All members have some sort of programming background, which will help them all contribute meaningfully to the LTC-TMS project.

2.2 Estimates

This project consists of team members from Kutztown University of Pennsylvania. There are six team members assigned to iOS and Android app development. These members will be working and meeting on a regular basis. Three members will be focusing their efforts primarily on the iOS application, and the other three will be focusing their efforts towards the Android application. In addition to the six team members from Kutztown, they will also collaborate with four additional students from Ming Chuan University (MCU) which is in Taiwan.

2.2.1 Cost

The cost for the project will be time team members spend working on the project and the cost for hardware and software use for this project. Each member will spend time on meeting with their own team and collaborate with other teams such as web development and database management and students from MCU. Each team members will require to spend time on their own to obtain necessarily knowledge for project. Base on the parts list from MCU, they assemble a list of hardware that are required this project. The hardware cost estimation is $467.03 US dollars at the time the estimation was done. The price of hardware might change slightly in the future. For software, there is no cost until they decide to put it into production. Publishing LTC-TMS apps into the market will cost a $99 USD/year charge on the Apple App Store and one-time registration fee of $25 USD on the Google Play store.

2.2.2 Schedule

It is expected to take about 2808 man-hours, spanned over two school semesters to finish this project. There are several factors that can change the time required to finish the project such as, planning, designing, training, development, testing, unexpected delays, etc. The estimate man-hours included the 30 percent unexpected delay time.

4


See Project Schedule on page 8 for more information.

2.3 Resources

The Mobile App development team will utilize App Inventor 2 and the Java language for the Android app and XCode and the Swift language for the iOS app. To gather the health and room data, the Mobile App development team will use various sensors such as the Waveshare Dust Sensor Detector Module, the HiLetgo 5pcs DHT11 Temperature and Humidity Sensor Module, and they Grove Finger Clip Heart Rate Sensor, to gather data from the patients. The data will then be sent to the Raspberry Pi’s via a micro-bit that the patient is wearing. To store all the data, the Mobile App development team will use the Firebase database system, or another NoSQL database that meets all teams’ requirements. The team will utilize a single lead Raspberry Pi to communicate with the database, while other Raspberry Pi’s send data to the lead Raspberry Pi.

2.4 Team Structure

The KU Application Development Team is comprised of six members and their respective roles:

- Peter Shively - Team Leader, iOS Developer

o As Team Leader, Peter will be in direct contact with the MCU team leader to schedule meetings and ask questions the Mobile App team has. Peter will also

o As an iOS Developer, Peter will work on the iOS version of LTC-TMS. He will be involved in all aspects of the iOS version and collaborate with the Browser team and the Android Mobile App team to make sure they are on the same page, in terms of the user-interface and configuration.

- Andrew Reichard - Android Developer

o As an Android Developer, Andrew will work on the Android version of LTC-TMS. He will be involved in all aspects of the Android version and collaborate with the Browser team and the iOS Mobile App team to make sure they are on the same page, in terms of the user-interface and configuration.

- Duong Doan - iOS Developero As an iOS Developer, Duong will work on the iOS version of LTC-TMS. He will be

involved in all aspects of the iOS version and collaborate with the Browser team and the Android Mobile App team to make sure they are on the same page, in terms of the user-interface and configuration.

- Phillip Yoder - Android Developero As an Android Developer, Phillip will work on the Android version of LTC-TMS. He

will be involved in all aspects of the Android version and collaborate with the

5


Browser team and the iOS Mobile App team to make sure they are on the same page, in terms of the user-interface and configuration.

- Ryen Shearn - Lead iOS Developer

o As Lead iOS Developer, Ryen will work on the iOS version of LTC-TMS. He will oversee and be involved in all aspects of the iOS version and collaborate with the Browser team and the Android App team to make sure they are on the same page, in terms of the user-interface and configuration. Ryen is the first point of contact for the iOS Mobile App team.

- Tyler Bartnick - Lead Android Developero As Lead Android Developer, Tyler will work on the Android version of LTC-TMS.

He will oversee and be involved in all aspects of the Android version and collaborate with the Browser team and the iOS Mobile App team to make sure they are on the same page, in terms of the user-interface and configuration. Tyler is the first point of contact for the Android Mobile App team.

6


3.0 RISK MANAGEMENTThere are several risks that the Application Development team must foresee for to ensure the success of LTC-TMS. The Risk Management Plan will be a more comprehensive and in-depth resource of potential risks for LTC-TMS. Several risks that are pertinent to the app team are listed below:

- Dynamic Nature of XCode/Swift development

o There are methods of migrating from older versions of Swift code to newer versions. The app team needs to be fully aware of any potential issues with migrating between versions. Apple has made drastic changes between different versions of Swift; staying up-to-date with changes is wholly beneficial to everyone.

- Compliance with HIPAA (Health Insurance Portability and Accountability Act, 1996) and other required health data laws

o It will have to be determined if the data that is being worked with constitutes medical information, and the steps that will have to be taken to comply with local and federal law.

o Laws vary from state to state and could complicate putting the system into production.

o Breaching HIPAA can result in a maximum $50,000.00 per violation fine.

- Dependency on cloud-based services

o Being dependent on machines that are out of the scope of control of the project team means that the team is reliant on 3rd party services maintaining acceptable uptime.

Inconsistencies between different app versions and platforms o The more versions of a product there are, the increased chances of huge

differences have of coming up. o The app team is divided into iOS and Android; they must communicate any

changes in design or functionality between the versions and develop them to be consistent with each other.

o There is a web version that must be consistent with the mobile app design; communication between the Browser and App Team is crucial.

The discontinuation of support for App Inventor2 and/or Firebaseo The expectation of Google dropping Firebase is high; Google is known for

abandoning projects with little to no prior notice. This can be seen with App

7


Inventor2. Google was the owner of App Inventor until they dropped support in late 2011; afterwards, the Massachusetts Institute of Technology (MIT), picked up the project.

o <MIT has the probability of dropping App Inventor2 as well, so the app team will have to plan for if they do.> There is a probability that MIT will drop support for App Inventor 2; the app team will develop a plan to manage that possibility.

Patient data leako In the event of poor database integration, it can lead to unauthorized users

being granted access to the patients’ sensitive personal information.o This could lead to fines from the state and lawsuits from the patient or their

families.

8


4.0 PROJECT SCHEDULETable 2 is a schedule of deliverables this semester, along with an estimated time of completion, due dates, required resources, and the status information. Team meetings and meetings with MCU are listed in section 5.0.

Task Estimate (Days)

Due Date Resource(s) Status

Request for Proposal – v1

5 September 14,2018 All Members Complete

Software Project Plan – v1

7 September 21, 2018 All Members Complete

Request for Proposal – v2

7 September 28, 2018 All Members Complete

Risk Management Plan – v1

4 October 5, 2018 All Members Complete

Software Project Plan – v2

5 October 12, 2018 All Members Complete

Risk Management Plan – v2

4 October 19, 2018 All Members In Progress

Software Requirements

Specification – v1

7 October 26, 2018 All Members Not Started

Software Requirements

Specification – v2

5 November 7, 2018 All Members Not Started

High Level Design – v1

10 November 16, 2018 All Members Not Started

High Level Design – v2

5 December 5, 2018 All Members Not Started

Presentation 10 TBA All Members Not Started

Table 2- Project Schedule

9


5.0 TEAM MEETING SCHEDULEThe Team Meeting schedule is listed below with the following statuses: Completed, Pending, Rescheduled, or Cancelled. The primary meeting location is at Kutztown University, Old Main (OM) Building, Room 156. Meetings are scheduled weekly with Ming Chuan University (MCU) and the Application Development Team. Multiple scribes are denoted when collaborating with the Hardware Development Team, Browser Development Team, or MCU.

Time Location Date Scribe Status Synopsis

12:00PM – 1:00PM

OM156 9-14-2018 Peter Shively Completed First app team

meeting.8:00AM-9:00AM

OM156 and MCU

9-17-2018 Ryen Shearn Completed First meeting with MCU.

Mostly introductions

12:00PM-1:00PM

OM156 9-21-2018 Phillip Yoder Completed Discuss RFP & SPP, move to template

12:00PM-1:00PM

OM156 9-26-2018 Ryen Shearn Completed Review SPP feedback,

pick iOS and android leads

8:00AM-9:00AM

OM156 and MCU

9-27-2018 Peter Shively Completed Elaborated on app

specifications and

terminology used in MCU

SPP.8:00AM-9:00AM

OM156 and

OM157 and MCU

10-1-2018 Peter Shively, Justin Frye, Tin

Fen Lin (Raymond),

Tamara Jennings

Completed First meeting with all

teams and MCU. Q&A

session derived from

KU team member

questions.12:00PM- OM156 10-3-2018 Peter Shively Completed Reviewed

10


1:00PM answers from MCU

and split up RMP work

12:00PM-1:00PM

OM156 10-10-2018 Peter Shively Completed Reviewed SPP v1 and

RMP v1. Discussed

questions for MCU.

8:00AM-8:30AM

OM156 and MCU

10-11-2018 Peter Shively Completed Followed up on some

questions, talked about issues finding

clients.12:00PM-1:00PM

OM156 10-17-2018 TBA Pending TBD

12:00PM-1:00PM


12:00PM-1:00PM


12:00PM-1:00PM


12:00PM-1:00PM


12:00PM-1:00PM


12:00PM-1:00PM


11

Table 3 – Team Meeting Schedule


6.0 SYSTEM ARCHITECTURE DIAGRAMFigure 1 is a diagram illustrating the interaction and dependencies of the devices in the LTC-TMS. Android and iOS devices are the primary concern of the App Team to ensure a smooth and reliable experience for the end users; however, all aspects of the LTC-TMS must be operating correctly.

Figure 1: System Architecture Diagram

12


7.0 CONTEXT DIAGRAMFigure 2 showcases a context diagram for the LTC-TMS. The purpose of the context diagram is to illustrate how each type of end user, Director, CNO, CNA, and Family, interacts with the applications and how the hardware devices, Raspberry Pi and Microbit, interacts with the applications and database. End user interactions include adding tasks, viewing tasks, adding notes, viewing notes, posting announcements and schedules. Hardware interactions include sending and receiving data from the database, calculating and recording humidity, dust levels, heart rate levels.

Figure 2: Context Diagram

13


8.0 FEASIBILITY

This section examines the projected feasibility, or the probability of success, of the proposed system.

8.1 Economic Feasibility

The proposed system has some upfront costs, as well as potential recurring costs over the lifetime of the project once it is deployed to be used by the client. In order to build the proposed system to the project specification, a number of hardware components need to be purchased. In short, the hardware aspect of this project is estimated to cost $467.73. This cost will be offset by applying for a small grant from Kutztown University of Pennsylvania.

Other tools to be used are either free or already owned by team members. For application team members developing for Android, the intended development environment will be App Inventor 2, an MIT project. AI2 is a freely available development environment that will not impose any additional cost to the project. Similarly, Xcode will be freely available for those team members that are already running MacOS whom are intending to develop for iOS.

The database proposed for this system is Google’s cloud-based NoSQL datastore, Firebase. Firebase has a free tier that will be sufficient for development and small LTC facilities with a small number of patients whose data will be collected on a regular basis. If this project is to be implemented in an LTC facility with a large number of patients, the plan for storage will likely need to be upgraded from the free tier. The next logical step after the free tier would be the “Flame Plan” at $25.00/month. Another option would be the “Blaze Plan” which is a pay-as-you-go subscription plan where pricing varies widely, but at the most would cost $5 per GB used.

Given the fact that students will be developing the system, there is no financial cost imposed on the project for manpower.

With these projected costs, the project should be financially feasible.

8.2 Schedule Feasibility

Scheduling can be a potential pitfall for the project. In order to mitigate any scheduling issues, the team will work closely with one another, meeting and checking in often. Additionally, the application team will be divided into sub-teams for each platform, one for each Android and iOS. This will be done in order to help spread the burden of development amongst the team members. Scheduling should have minimal impact on the project, despite having the possibility of being disastrous.

14


8.3 Collaborative Feasibility

Due to the inherent nature of the project encompassing multiple sub-teams from two different universities separated by a 12-hour time difference, close collaboration between teams and sub-teams will be required. To further compound the issue of collaboration over a large time differential, Ming Chuan University does not follow the exact same academic schedule as Kutztown University of Pennsylvania. A lack of collaboration will ensure project failure.

In order to mitigate these issues, regular meetings will be scheduled and held with MCU students in order to keep track of any potential issues or concerns for the projects and discuss them in depth between teams. Additionally, local sub-teams (database/hardware, browser, app) will need to communicate at the leader level at the least. Collaboration should impact the project at a minor to moderate level.

8.4 Technical Feasibility

Improper training and inexperience can cause major project setbacks, or even project failure. The app team has a diverse skill set with some members having more experience than others. Team members who do not have a great deal of experience will have to undergo additional training with the related technologies in order to mitigate this issue. More experienced team members can and should provide assistance to other members when needed. Project technicality should remain feasible.

8.5 Resource Feasibility

All resources provided by Kutztown University of Pennsylvania - e.g. computer labs, LAN, working spaces, etc., are sufficient for all aspects of this project.

8.6 Overall Feasibility Assessment

The projected system currently has no major issues or projected hang-ups that would deem this project “not feasible”. However, the biggest issue facing the project at this point would be a lack of experience from team members and that must be addressed as quickly as possible. All other aspects of the feasibility study are not expected to cause issues.

15

table of contentsfaculty.kutztown.edu/tan/csc354/datafiles/new/354/a… · web viewthe mobile app...

Documents