TABLE OF CONTENTSfaculty.kutztown.edu/tan/csc354/Datafiles/NEW/354/HW... · Web view1.0...

Software Project Plan October 11, 2018

Software Project PlanVersion 2.1

Hardware, Database, Project Management

Justin Frye

Tyler Whittaker

Nolan Perugini

Lucas Strickland

Matt Sauchelli

Nicolas Altamirano

CSC 354

Dr. Tan


TABLE OF CONTENTSTABLE OF CONTENTS i

REVISION HISTORY ii

1.0 INTRODUCTION 1

1.1 Project Description 1

1.2 Project Scope 1

1.3 Major Functions 1

1.4 Users and User Environment 1

1.5 Performance Issues 1

1.6 Management/Technical Constraints 2

3.0 RISK MANAGEMENT 6

4.0 PROJECT SCHEDULE / ACTIVITIES 8

6.0 TRACKING AND CONTROL MECHANISMS 12

6.1 Fulfilling Quality Assurance and Quality Control 12

6.1.1 Training and Preparation 12

6.1.2 Measurements and Logging 12

6.1.3 Testing 12

6.1.4 Version Control 12

6.1.5 Handling Change 13

7.0 SYSTEM ARCHITECTURE DIAGRAM 14

8.0 CONTEXT DIAGRAM 16

9.0 FEASIBILITY 17

9.1 Economic Feasibility 17

9.2 Organizational and Cultural Feasibility 17

9.3 Technical Feasibility 17

9.4 Schedule Feasibility 18

9.5 Resource Feasibility 18

9.6 Overall Assessment 18

10.0 APPENDIX/ACRONYMS 19

i


REVISION HISTORYBelow is the current revision history (table 1.0). As changes are made to this document, the chart will reflect the date, description, and editor(s).

Version Date Description Editor

1.0 9/18/18 Added to sections:

1.2 Project Scope

Added to sections:

1.0 INTRODUCTION

1.1 Project Description

Nolan Perugini

Added to sections:

1.0 INTRODUCTION


Lucas Strickland

Added to sections:

3.0 RISK MANAGEMENT

Matt Sauchelli


6.0 TRACKING AND CONTROL MECHANISMS

6.1 Fulfilling Quality Assurance and Quality Control

6.1.1 Training and Preparation

6.1.2 Measurements and Logging

6.1.3 Testing

6.1.4 Version Control

6.1.5 Handling Change

Nolan Perugini

ii



Added to sections:

2.0 PROJECT ESTIMATES

2.1 Historical Data

2.2 Estimates

2.2.1 Cost

2.2.2 Schedule

2.3 Resources

2.4 Team Structure

Tyler Whittaker

Added to sections:

1.2 Project Scope

1.3 Major Functions

1.4 Users and User Environment

1.5 Performance Issues

1.6 Management/Tech Constraints

Lucas Strickland

Add to sections:

3.0 RISK MANAGEMENT

Matt Sauchelli

1.2 9/20/18 Modified sections:

3.0 RISK MANAGEMENT

Added to sections:

4.0 FUNCTIONAL REQUIREMENTS

Justin Frye

iii



5.0 PROJECT SCHEDULE/ACTIVITIES

9.1 Economic Feasibility

10.0 Appendix/Acronyms

Added to sections:

8.0 CONTEXT DIAGRAM

Lucas Strickland

Added to sections:

9.2 Organizational and Cultural Feasibility

9.3 Technical Feasibility

9.5 Resource Feasibility.

Nolan Perugini

Added to sections:

3.0 RISK MANAGEMENT

Matt Sauchelli

Added to sections:

9.4 Schedule Feasibility section

3.0 RISK MANAGEMENT

Nicolas Altamirano

Added to sections:

7.0 SYSTEM ARCHITECTURE DIAGRAM

1.0 INTRODUCTION


1.2 Project Scope

1.3 Major Function

1.4 User and User Environment

1.5 Performance Issues

1.6 Management/Technical Constraints

Tyler Whittaker

Lucas Strickland

2.0 10/10/18 Added to sections: Tyler Whittaker

iv



2.0 PROJECT ESTIMATES

2.1 Historical Data

2.2 Estimates

2.2.1 Cost

2.2.2 Schedule

2.3 Resources

2.4 Team Structure


2.4 Team Structures

7.0 System Architecture Diagram

10.0 Appendix/Acronyms

Tyler Whittaker

Added to sections:

9.0 FEASIBILITY

9.1 Economic Feasibility

9.2 Organizational and Cultural Feasibility

9.3 Technical Feasibility

9.4 Schedule Feasibility

9.5 Resource Feasibility

9.6 Overall Assessment

Nicolas Altamirano

Modified sections:

6.1 Fulfilling Quality Assurance and Quality Control

6.1.1 Training and Preparation

Nolan Perugini

v



6.1.2 Measurements and Logging

6.1.3 Testing

6.1.4 Version Control

6.1.5 Handling Change

Added to sections:

3.0 RISK MANAGEMENT

1.0 INTRODUCTION

Matt Sauchelli

Added to sections:


1.2 Project Scope

1.3 Major Function

2.2 Estimates

8.0 CONTEXT DIAGRAM

Lucas Strickland

Added to sections:

1.0 INTRODUCTION

4.0 FUNCTIONAL REQUIREMENTS

5

10

vi



Table 1.0: Revision History

vii


1.0 INTRODUCTIONThis is the DB, HW and PM team’s Software Project Plan. This document provides an overview of the LTC-TMS and describes the various aspects of the system development.

1.1 Project Description The LTC-TMS is being designed to monitor the overall health of a patient while keeping a library of tasks and other related information for the user to observe. The information collected from the patient will consist of heart rate, step count, and the air humidity of the patient's room. The heart rate and step count data will be sent via radio frequency from a sensor the user wears to the raspberry pi and then to the database. A sensor mounted on the wall of the room will measure humidity, sending the information to the raspberry pi, will process the combined data points and push them to the database. Patient health data will be viewed in the form of a patient portfolio.

1.2 Project ScopeThe goals of LTC-TMS is to reduce paperwork for healthcare staff, store data digitally, increase the speed of data retrieval, and create an effective communication hierarchy for the staff. The purpose of the sensors being used to reduce the amount workload of healthcare staff by eliminating the majority of manual data entry and streamlining the workflow. The LTC-TMS will be available on different platforms to help fit the needs of healthcare staff. The tablet version, in particular, is ideal for healthcare staff who can carry a tablet around with them during their day. The TMS itself will store a library of different tasks which can be chosen by a user to receive step by step instructions on how to do them.

1.3 Major FunctionsThe major functions of the LTC-TMS are to store tasks with their instructions, which can be added to or altered by a supervisor, while taking real time data of the air humidity, heart rate and step count. After the data is sent and stored in a cloud database it will be formatted and then properly displayed to a user upon request. The user interface will be formatted properly depending on what device the user is accessing the application from. Certain restrictions will be set so only certified individuals who are authorized can change and see certain tasks and data.

1.4 Users and User EnvironmentAlthough specialized for healthcare workers who want to keep track of a patient’s daily tasks and current health, the users will consist of anyone who wants to monitor their health while receiving simple instructions on how to do certain tasks. This includes people of any age and health status. The user environment will either be a medical center or a user’s home.

1.5 Performance IssuesThere may be performance issues when it comes to the accuracy of the data collected by the sensors based on where the user has it on their body. If the sensor is placed over clothing or on a part of the body where the sensor does not pick up their heart rate accurately then there will be unreliable data. Another issue will be the range of worn sensors as the user could stray away from the receiver and

8


cause the real-time data flow to stop. There must be measures taken in order to detect such an event and to alert the user. Other issues may arise with the database if there is data lag because of the above reasons or if the database is not able to handle the amount of data being fed to it.

1.6 Management/Technical ConstraintsTechnical constraints consist of not having the hardware in person to know the exact size and how it fits together physically as well as database limitations when it comes to the amount of data storage. Management constraints consist of group scheduling issues. It can be difficult to find a clear time slot for the entire group to come together for a meeting. Each team member has different availability hours which limit when they can work together.

9


2.0 PROJECT ESTIMATESThe following sections will cover estimations regarding costs, schedule, resources, and team structure. All estimates are subject to change.

2.1 Historical DataThe required hardware for the LTC-TMS is determined off of MCU’s equipment list. Once the hardware list is confirmed, prices may be properly researched, and an estimate will be determined and submitted for a sponsored grant.

2.2 EstimatesThe estimates that are presented are rough estimates and may change. Since this is a school project the cost of implementing the project only pertains to the costs of the hardware. The estimated cost of the hardware components is $455.24. Firebase is free as long as the project stays in the boundaries of the free tier. Below are further details on the levels of service offered by firebase.

Firebase Free Tier● 100 simultaneous users● 1 GB storage● 10 GB per month bandwidth● 20,000 doc writes● 50,000 reads per day ● 20,000 deletes

Firebase $25 per month● 100,000 simultaneous users● 2.5 GB database storage● 50 GB general storage● 20 GB per month bandwidth● 100,000 doc writes● 250,000 reads per day● 100,000 delete

2.2.1 CostThe cost of the project will only include hardware because the students are not being paid to implement the project. The estimated cost for the hardware is $455.24, this may change as the scope of the project changes.

2.2.2 ScheduleLTC-TMS is estimated to take two semesters to complete with the help of MCU. Currently in the first semester the planning, analysis and designing is taking place. Next semester the development, testing and deployment will take place.

10


2.3 ResourcesFor the project the team will be using many resources. A text editor will be used to configure the micro-bit’s and raspberry pi’s. For communication between team members, and other teams google hangouts, slack will be used. To communicate with MCU line will be used since they requested this application specifically. For sharing files google drive will be used. Firebase had been approved by the class as our database. Firebase can also be used as a web hosting site. Google search engine will be used for researching hardware to purchase, and how to assemble the hardware. YouTube video can also be used as a learning and how-to tutorial. The computer labs at KU will be utilized for the any online use and for hosting our monthly class meetings with MCU. The resources to be used for the project are listed below:

● Text editor○ Notepad++○ Visual Studio Code

● Communication○ Google Hangouts○ Slack○ Line

● File Sharing○ Google Drive

● Firebase○ Database○ Cloud server/web hosting

● Hardware○ Raspberry Pi 3 Model B○ Micro-bit ○ Dust/Air quality sensor○ Temperature and humidity sensor○ Breadboard○ T-GPIO expansion board○ 40 pin rainbow cable○ Heart rate sensor○ Grove shield for micro bit○ MCP3008 analog to digital convertor○ Micro-bit battery○ Micro-bit case

● Miscellaneous ○ Google search engine○ YouTube○ MCU students○ KU computer labs

11


2.4 Team StructureThe Hardware/Database/Project Management team is composed of six KU members.

Justin Frye - Team Lead, Project Manager Justin is in charge of updating the Gantt Chart, communicating with the MCU project manager,

scheduling meeting times for our weekly team meetings, and meeting with MCU. He is the leader of the DB/HW/PM team and the project manager for the class. He is responsible for keeping up to date with each team to make sure that the class is on track with the Gantt Chart. He is also responsible for submitting the team weekly work logs and submitting the technical documents when they are completed. He is also responsible for working on the database and hardware portion of the project and monitoring the risk manager.

Tyler Whittaker - Hardware Lead Tyler is the hardware lead, and he is responsible for making sure that the class is ordering the

necessary hardware components for the LTC-TMS. He is also responsible for completing technical documents, providing input on discussions, and proofreading documents. He is also helping with the database and monitoring risks.

Lucas Strickland - Database Lead Lucas is our main database lead and is responsible for making sure that database gets clean data

from the raspberry pi that is ready to be sent off to the end users. He is leading the schema and insuring that that the functionality is properly implemented. He is also working with Nolan and Nicolas with the entire database. He is also helping with the hardware, writing technical documents and monitoring risks.

Nolan Perugini - Database Manager Nolan is responsible for making sure that our database is correctly designed and implemented.

He is responsible for the database receiving data over Wi-Fi from the micro-bits. He is also assisting Nicolas and Lucas with the entire database. He is helping with the hardware, technical documents, and monitoring risks.

Nicolas Altamirano - Database Manager Nicolas is responsible for designing and implementing the database and making sure that the

data is being stored properly. He is also assisting Nolan and Lucas with the entire database. He is also helping with the hardware, writing technical documents, and monitoring risks.

Matt Sauchelli - Risk Manager

Matt is responsible for managing the risks of the project and making sure that a team member is assigned to each risk. If he finds that a risk starts to become a concern he is responsible to make sure that the proper actions are taking place to correct the issue. He is also working with the hardware, database, and writing technical documents.

12


3.0 RISK MANAGEMENTThe following risks have been identified by the HW/DB/PM team, which will be minimized and best mitigated by utilizing common industry practices and methodologies. A comprehensive description and coverage of risk management is located in the RMP document.

Hardware Security● The hardware being worn by the patient will transmit information to the main system for

monitoring by the staff. The device will be attached to the patient at all times and will not store any information locally. The hardware will be monitored by staff while in use. Staff will have proper training on how to handle patient information.

Patient Privacy● There are security practices defined under HIPPA to ensure the security of patient medical

records. This project will work to achieve the highest level of security possible. Due to the current scope of the project, the system will not be HIPPA compliant as the system is not set to be deployed to a medical facility. If the system is to be deployed in a hospital environment, then the system will be adjusted to meet HIPPA requirements.

Personnel Issues● All team members will have familiarity of hardware, database, network, and project

management components to mitigate the risk of a team member absence from impacting the project. There are multiple people assigned to each team, aiding in reliability.

● If a team member is unable to be present for a team meeting, whether in person or virtually, they will need to have informed the team lead prior to the meeting to not hinder meeting progress. It is the responsibility of the individual team member to catch up on information covered during the meeting.

● If a team member needs more clarification regarding a task they are assigned, the team member is to contact the team lead or another team member for clarification.

● if there is an issue of disrespect between team members the issue will first be brought to the attention of the team lead. If the team lead is unable to resolve the issue, it will be brought up to Dr. Tan for resolution.

● Each of the personnel issues will increase the risk of the project staying on schedule and meeting QA standards.

Rule of Least Privilege● Database users will be able to access the least amount of data that is necessary for their

position. This practice prevents users from accessing information that they have no need to access. This practice is industry standard and has been proven an effective method of risk mitigation. The Director, CNO, and CNA positions have varying levels of system access. Each

13


position is only given enough access in order to fulfill the duties of the position, without being granted unnecessary access.

Database reliability● This system will be using Firebase, a database service hosted by Google. All the information is

stored in the cloud negating the need for a local backup to be taken. Google has the necessary resources to properly support a system like this.

14


4.0 PROJECT SCHEDULE / ACTIVITIESTable 2.0 lists the different tasks that will be fulfilled by the HW/DB/PM team between the months of September-December of 2018. Tasks will be added to this table as the semester progresses. The columns include Task, Estimated Work Days, Due Date, Responsibility, and Current Status.

Task Estimated Work Days

Due Date Responsibility Current Status

Interact with MCU via Video

Conference

1/week N/A All Team Members

Ongoing

Research Hardware 10 N/A All Members, Primary

Hardware Lead

Complete

Complete Document: RFP V1

5 September 14, 2018

All Members Complete

Create Initial Gantt Chart


Justin Frye Complete

Keep Gantt Chart Up-to-date

N/A N/A Justin Frye Ongoing

Complete Document: SPP V1



Complete Document: RMP

Draft


Matt Sauchelli Complete

Complete Document: RMP V1

5 October 5, 2018 All Members Complete

15




Complete Document: RFP V2


All Members Not Started

Propose Hardware List and Sellers to

Class

1 October 5, 2018 All Members Complete

Complete Document: SPP V2

5 October 12, 2018


Complete Document: RMP V2

5 October 19, 2018


Complete Document: SRS V1

5 October 26, 2018


Develop Database Schema

10 Late October, 2018

Lucas Strickland,

Nolan Perugini, Nick

Altamirano

Not Started

Order Hardware 1 Early November, 2018

Dr. Tan / All Members

Not Started

Complete Document: SRS V2

5 November 5, 2018


Complete Document: HLD V1

5 November 16, 2018


16




Build Product With Hardware

Components

10 Mid-Late November, 2018


Complete Document: HLD V2

5 December 3, 2018


Develop Team Presentation

14 December 2018 All Members Not Started

Table 2.0: Project Schedule

17


5.0 TEAM MEETING SCHEDULETable 3.0 below provides a list of the weekly meeting information. Typically, meetings are held on Wednesdays or Thursdays at the Kutztown Library and/or Virtual (via Google Hangouts). Since the team was developed in week three in the semester, this table will reflect meetings beginning the week of 9/10/18.

Time Location Date Meeting Leader Status

6:30pm-7:30pm Library RL109/Google

Hangouts

9/11/18 Justin Frye Complete

7:00pm-8:00pm Library RL109/Google

Hangouts


7:00pm-8:00pm Google Hangouts

9/24/18 Nicholas Altamirano

(Alternative Team Lead)

Complete

7:15pm-8:15pm Google Hangouts


Table 3.0: Team Meeting Schedule

18


6.0 TRACKING AND CONTROL MECHANISMSGitHub will be the main resource used to track and control code. Google Drive will be used to store all project documentation which will be made available to everyone in the LTC-TMS development team. Slack is the primary communication platform for all team members with separate channels for each development team as well as a general channel for project-wide announcements. Google Hangouts will be used to conduct video meetings between MCU and KU. Meetings within the KU development teams will either be done on the Kutztown campus or through Google Hangouts.

6.1 Fulfilling Quality Assurance and Quality Control Every update to the code will have be tested with the hardware and database. Any change to the code could cause a piece of hardware to malfunction and send corrupted data. The integrity of the data collected and stored must be preserved in order for an update to occur. Multiple tests with small amounts of data will be done in order to ensure each piece is working.

6.1.1 Training and PreparationContact with MCU will be critical to the training and preparation of the KU LTC-TMS team as a whole. All members of the team should become familiar with the system prior to receiving the code. MCU must be frequently contacted to receive information on how the system functions. KU should learn about any potential pitfalls related to the LTC-TMS system from MCU. The KU team should also brainstorm about any unforeseen problems that MCU has not considered and prepare solutions to these problems. YouTube and other online resources should be used to supplement knowledge and help find solutions.

6.1.2 Measurements and LoggingGitHub and Google Docs will be used to document all changes in the code or hardware. A log containing the date, status, and reason for each update to the main code should be logged in Google Docs. A separate log documenting the development process of in-progress code will be stored in Google Docs. Changes to this in-progress version must be authorized by the team leader.

6.1.3 TestingTesting will be paramount to the success of the project because of the transfer of code from MCU to KU. The KU LTC-TMS development team must proofread and test all systems upon reception of the code. All of the code will be tested using the hardware purchased by Kutztown. The hardware purchased by Kutztown is identical to the hardware used by MCU. Transferring the code and testing it on local hardware will be the main priority. Firebase will also be tested once the code is received. Test data will be sent to Firebase using all of the hardware. The data sent by the hardware must be checked for correctness as well as proper storage and interpretation on the database.

6.1.4 Version ControlGitHub will be used to track all versions of the LTC-TMS system. The exact code from MCU should be kept separate from all KU additions and alterations. A working version of code altered by KU will be stored in GitHub. Code that is to be tested and pending approval will be held separately until it is either

19


accepted or rejected. There will be a leader who has administrative privilege on GitHub to update the working version of code once it has been approved. A GitHub repository for code currently in progress will be held for editing and is open for all members of the team to edit.

6.1.5 Handling ChangeChange to the main version of code should undergo rigorous testing. The code should not be accepted into the main version until it has been reviewed by the team lead and voted in favor of by each team member. The code will be given to the member in charge of the GitHub repository for integration with the main code.

20


7.0 SYSTEM ARCHITECTURE DIAGRAMThe hardware will consist of a raspberry pi, a micro bit, and a few sensors to monitor vitals and air quality. Then the system will need a server and a database to send and receive requests. A tablet, mobile device and desktop computer will be used for the end user to view the LTC-TMS. The browser version is for the director and the CNO and is used on desktop computers. The app version for the mobile devices is going to be used by the CNA and family members. The app version for the tablet is going to be used by the CNA.

The raspberry pi and one of the micro-bits are going to act as a receiver of the patients’ data and will be then sent over WIFI to the database. The raspberry pi will also have two sensors connected to it to measure the temperature and humidity, and the air quality. The temperature and humidity, and the air quality sensor is wired directly to the raspberry pi which will then send the data to the database using WIFI. The other micro-bit and heart rate sensor will be be worn by the patient and will send the data using radio frequency. The micro-bit being worn by the patient will also be sending the number of steps the patient has made and the current position. Once the database has received the data it will then provide all of the data to the end users on the tablet, mobile device, and desktop computer to view.

The end users will navigate the web application which will interact with the server and database. The hardware will be sending its data to the database over WIFI.

The diagram below (Figure 1.0) shows how the hardware will connect to the database, server, and the end user devices.

21


Figure 1.0: SYSTEM ARCHITECTURE DIAGRAM for LTC-TMS

22


8.0 CONTEXT DIAGRAMA context diagram is a diagram which gives a general overview of the entire system to the highest level of data flow. This context diagram shows the relationships that the system has with all the external entities. Figure 2.0 below is the exact diagram representing the interaction between the (LTC-TMS) and the end users.

Figure 2.0: (LTC-TMS) CONTEXT DIAGRAM

23


24


9.0 FEASIBILITYThis section will cover project feasibility in the areas of economic (affordability), organizational/cultural between the KU and MCU team, technical, scheduling within KU and MCU team, as well as resources (budget).

9.1 Economic FeasibilityAs greater responsibility has been assigned to this team, there are three perspectives regarding economic feasibility. Such as perspectives include hardware, database, and project management.The Three sections below go in depth into what these perspectives are.

Hardware● The hardware required for this project is expected to be covered by a grant. A proposal for the

grant will be done by the professor which will be constructed by the class, especially by the hardware lead.

Database● As of now, the database to be used for this project has not officially been determined. The

recommended solution by the database lead will be Firebase (Google product). The basic plan for Firebase is free, which bundles both the database and server as one web-based solution. If further bandwidth/storage/functionality is required, there will be a cost, which will be specified in the RFP document.

Project Management● The only tool being used for project management thus far is a Gantt Chart which is based on a

free-of-charge Excel template that will be maintained by the PM. As further responsibility is given to the PM, other tools may be necessary.

9.2 Organizational and Cultural FeasibilityThe collaboration with MCU has gone well so far. There doesn't seem to be any organizational/cultural issues that would impact the project currently. The MCU students have been willing to thoroughly explain their work and answer questions in detail. The time difference between KU and MCU is a difficulty but it has been overcome so far and doesn't seem to dramatically affect the ability to collaborate. Organizing the project development and schedule in its entirety is a difficult task. The ability to create multiple teams that can keep up with deadlines will increase the likelihood of success. Team managers will need to be organized and in-touch with their members in order to keep them on track. Organizing within the KU teams will be the largest hurdle in development of the project, but it is something that is to be expected and will not deter progress.

9.3 Technical FeasibilityThe overall technical feasibility of the LTC-TMS system is dependent on a manageable number of hardware parts and functionality of database. If the hardware is acquired and functions as intended,

25


there are not many limitations that will arise from a technical standpoint. The overall cost of purchasing the hardware is sizable but it is not unreasonable. The hardware is also very portable and easy to use so once it is acquired there should not be many problems that arise. The need for a database is critical but the LTC-TMS project does not require a robust or expensive database setup as of now (minimal amount of data). However, if necessary, the database plan may be upgraded at a cost depending on the storage/bandwidth required. The many different versions of the LTC-TMS system such as the app, browser, and tablet versions are likely to be the most limiting factor the success of the project. All versions will need to be functioning properly in order for the system to function as a whole. Maintaining functioning code and compatible code for all the different versions will be a challenge for the development teams.

9.4 Schedule FeasibilityScheduling feasibility is a constant consideration with half of the members of the team being commuters, this has proven to not be an issue since collaborating virtually on google hangouts has been successful and worked out best for the team as a whole. After communicating with the MCU team, the KU team has established a time that works for all parties involved. As long as this is something that can be maintained, the team foresees no issues with scheduling conflicts between teams. Regarding work towards the project, there should not be any communication challenges regarding task deadlines not being met. Slack and other methods of communication have been a great resource, allowing team members to accomplish tasks in a more efficient manner. The biggest issue in the foreseeable future will be completion of tasks in the set amount of time given.

9.5 Resource FeasibilityThe current monetary resources for the project are undetermined as of now. Funding for the project may come from either the KU Computer Science Department or a grant from the school itself. Without either source of income, the project itself may not be feasible. The only need for a grant is to purchase the initial set of required hardware. There should not be any additional upkeep or database maintenance fees. The project manager will determine how funds will be spent on the necessary hardware and if any changes must be made to accommodate a budget limit. There will be many systems that need constant attention, so team managers will have to work closely with the project manager to make sure deadlines are met and standards are kept consistent.

9.6 Overall AssessmentOverall, the feasibility of the product in terms of hardware, database, and project management is promising. The team does not currently foresee any roadblocks that cannot be surpassed. With the continuous process of risk management and team communication, such roadblocks, as well as future ones, will be dealt with accordingly.

26


10.0 APPENDIX/ACRONYMSThe following acronyms are used throughout the SPP document and should be referred to for extrapolation of all acronyms utilized.

● DB - Database● HLD - High Level Design● HW - Hardware● KU - Kutztown University● LTC - Long-Term Care● MCU - Ming Chuan University● PM - Project Manager● RFP - Request for Proposal● SPP - Software Project Plan● TOC - Table of Contents● TMS - Task Management System● CNO - Chief Nursing Officer● CNA - Certified Nursing Assistant● WIFI- Wireless local area network● HIPPA - Health Insurance Portability and Accountability Act● QA - Quality Assurance● RMP - Risk Management Plan● SRS - Software Requirements Specifications ● HLD - High Level Design

27

TABLE OF CONTENTSfaculty.kutztown.edu/tan/csc354/Datafiles/NEW/354/HW... · Web view1.0...

Documents

Transcript of TABLE OF CONTENTSfaculty.kutztown.edu/tan/csc354/Datafiles/NEW/354/HW... · Web view1.0...