TABLE OF CONTENTS



Software Project PlanVersion 2.1Hardware, Database, Project ManagementJustin FryeTyler WhittakerNolan PeruginiLucas StricklandMatt SauchelliNicolas AltamiranoCSC 354 Dr. TanTABLE OF CONTENTS TOC \h \u \z TABLE OF CONTENTS PAGEREF _Toc527063642 \h iREVISION HISTORYii1.0 INTRODUCTION PAGEREF _Toc527063644 \h 11.1 Project Description PAGEREF _Toc527063646 \h 11.2 Project Scope PAGEREF _Toc527063647 \h 11.3 Major Functions PAGEREF _Toc527063648 \h 11.4 Users and User Environment PAGEREF _Toc527063649 \h 11.5 Performance Issues PAGEREF _Toc527063650 \h 11.6 Management/Technical Constraints PAGEREF _Toc527063651 \h 23.0 RISK MANAGEMENT PAGEREF _Toc527063652 \h 64.0 PROJECT SCHEDULE / ACTIVITIES PAGEREF _Toc527063653 \h 86.0 TRACKING AND CONTROL MECHANISMS PAGEREF _Toc527063654 \h 126.1 Fulfilling Quality Assurance and Quality Control PAGEREF _Toc527063655 \h 126.1.1 Training and Preparation PAGEREF _Toc527063656 \h 126.1.2 Measurements and Logging PAGEREF _Toc527063657 \h 126.1.3 Testing PAGEREF _Toc527063658 \h 126.1.4 Version Control PAGEREF _Toc527063659 \h 126.1.5 Handling Change PAGEREF _Toc527063660 \h 137.0 SYSTEM ARCHITECTURE DIAGRAM PAGEREF _Toc527063662 \h 148.0 CONTEXT DIAGRAM PAGEREF _Toc527063668 \h 169.0 FEASIBILITY PAGEREF _Toc527063671 \h 17 9.1 Economic Feasibility PAGEREF _Toc527063672 \h 17 9.2 Organizational and Cultural Feasibility PAGEREF _Toc527063676 \h 17 9.3 Technical Feasibility PAGEREF _Toc527063677 \h 17 9.4 Schedule Feasibility PAGEREF _Toc527063678 \h 18 9.5 Resource Feasibility PAGEREF _Toc527063679 \h 18 9.6 Overall Assessment PAGEREF _Toc527063680 \h 1810.0 APPENDIX/ACRONYMS PAGEREF _Toc527063681 \h 19REVISION 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).VersionDateDescriptionEditor1.09/18/18Added to sections:1.2 Project ScopeAdded to sections:1.0 INTRODUCTION1.1 Project DescriptionNolan PeruginiAdded to sections:1.0 INTRODUCTION1.1 Project DescriptionLucas StricklandAdded to sections:3.0 RISK MANAGEMENTMatt Sauchelli1.19/19/18Added to sections:6.0 TRACKING AND CONTROL MECHANISMS6.1 Fulfilling Quality Assurance and Quality Control6.1.1 Training and Preparation6.1.2 Measurements and Logging6.1.3 Testing6.1.4 Version Control6.1.5 Handling ChangeNolan PeruginiAdded to sections:2.0 PROJECT ESTIMATES2.1 Historical Data2.2 Estimates2.2.1 Cost2.2.2 Schedule2.3 Resources2.4 Team StructureTyler WhittakerAdded to sections:1.2 Project Scope1.3 Major Functions1.4 Users and User Environment1.5 Performance Issues1.6 Management/Tech ConstraintsLucas StricklandAdd to sections:3.0 RISK MANAGEMENTMatt Sauchelli1.29/20/18Modified sections:3.0 RISK MANAGEMENTAdded to sections:4.0 FUNCTIONAL REQUIREMENTS5.0 PROJECT SCHEDULE/ACTIVITIES9.1 Economic Feasibility10.0 Appendix/AcronymsJustin Frye Added to sections:8.0 CONTEXT DIAGRAMLucas StricklandAdded to sections:9.2 Organizational and Cultural Feasibility 9.3 Technical Feasibility 9.5 Resource Feasibility.Nolan PeruginiAdded to sections:3.0 RISK MANAGEMENTMatt SauchelliAdded to sections:9.4 Schedule Feasibility section3.0 RISK MANAGEMENTNicolas AltamiranoAdded to sections:7.0 SYSTEM ARCHITECTURE DIAGRAM1.0 INTRODUCTION1.1 Project Description1.2 Project Scope1.3 Major Function1.4 User and User Environment1.5 Performance Issues1.6 Management/Technical ConstraintsTyler WhittakerLucas Strickland2.010/10/18Added to sections:2.0 PROJECT ESTIMATES2.1 Historical Data2.2 Estimates2.2.1 Cost2.2.2 Schedule2.3 Resources2.4 Team Structure Tyler Whittaker2.110/11/18Added to sections:2.4 Team Structures7.0 System Architecture Diagram10.0 Appendix/AcronymsTyler WhittakerAdded to sections:9.0 FEASIBILITY 9.1 Economic Feasibility 9.2 Organizational and Cultural Feasibility9.3 Technical Feasibility9.4 Schedule Feasibility9.5 Resource Feasibility9.6 Overall AssessmentNicolas Altamirano Modified sections:6.1 Fulfilling Quality Assurance and Quality Control6.1.1 Training and Preparation6.1.2 Measurements and Logging6.1.3 Testing6.1.4 Version Control6.1.5 Handling ChangeNolan PeruginiAdded to sections:3.0 RISK MANAGEMENT1.0 INTRODUCTIONMatt SauchelliAdded to sections:1.1 Project Description1.2 Project Scope1.3 Major Function2.2 Estimates 8.0 CONTEXT DIAGRAMLucas StricklandAdded to sections:1.0 INTRODUCTION4.0 FUNCTIONAL REQUIREMENTS5 10Table 1.0: Revision History1.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 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. 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 Tier100 simultaneous users1 GB storage10 GB per month bandwidth20,000 doc writes50,000 reads per day 20,000 deletesFirebase $25 per month100,000 simultaneous users2.5 GB database storage50 GB general storage20 GB per month bandwidth100,000 doc writes250,000 reads per day100,000 delete2.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. 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 editorNotepad++Visual Studio CodeCommunicationGoogle HangoutsSlackLineFile SharingGoogle Drive FirebaseDatabaseCloud server/web hostingHardwareRaspberry Pi 3 Model BMicro-bit Dust/Air quality sensorTemperature and humidity sensorBreadboardT-GPIO expansion board40 pin rainbow cableHeart rate sensorGrove shield for micro bitMCP3008 analog to digital convertorMicro-bit batteryMicro-bit case Miscellaneous Google search engineYouTubeMCU studentsKU computer labs2.4 Team StructureThe Hardware/Database/Project Management team is composed of six KU members.Justin Frye - Team Lead, Project ManagerJustin 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 LeadTyler 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 LeadLucas 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 ManagerNolan 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 ManagerNicolas 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 ManagerMatt 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.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 SecurityThe 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 PrivacyThere 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 IssuesAll 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 PrivilegeDatabase 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 position is only given enough access in order to fulfill the duties of the position, without being granted unnecessary access. Database reliabilityThis 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. 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.TaskEstimated Work DaysDue DateResponsibilityCurrent Status Interact with MCU via Video Conference1/weekN/AAll Team MembersOngoingResearch Hardware10N/AAll Members, Primary Hardware LeadCompleteComplete Document: RFP V1 5September 14, 2018All MembersCompleteCreate Initial Gantt Chart3September 19, 2018Justin FryeCompleteKeep Gantt Chart Up-to-dateN/AN/AJustin FryeOngoingComplete Document: SPP V15September 21, 2018All MembersCompleteComplete Document: RMP Draft2September 28, 2018Matt SauchelliCompleteComplete Document: RMP V15October 5, 2018All MembersCompleteComplete Document: RFP V25September 28, 2018All MembersNot StartedPropose Hardware List and Sellers to Class1October 5, 2018All MembersCompleteComplete Document: SPP V25October 12, 2018All MembersCompleteComplete Document: RMP V25October 19, 2018All MembersNot StartedComplete Document: SRS V15October 26, 2018All MembersNot StartedDevelop Database Schema10Late October, 2018Lucas Strickland, Nolan Perugini, Nick AltamiranoNot StartedOrder Hardware1Early November, 2018Dr. Tan / All MembersNot StartedComplete Document: SRS V25November 5, 2018All MembersNot StartedComplete Document: HLD V15November 16, 2018All MembersNot StartedBuild Product With Hardware Components10Mid-Late November, 2018All MembersNot StartedComplete Document: HLD V25December 3, 2018All MembersNot StartedDevelop Team Presentation14December 2018All MembersNot StartedTable 2.0: Project Schedule5.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.TimeLocationDateMeeting LeaderStatus 6:30pm-7:30pmLibrary RL109/Google Hangouts9/11/18Justin FryeComplete7:00pm-8:00pmLibrary RL109/Google Hangouts9/19/18Justin FryeComplete7:00pm-8:00pmGoogle Hangouts9/24/18Nicholas Altamirano(Alternative Team Lead)Complete7:15pm-8:15pmGoogle Hangouts10/1/18Justin FryeCompleteTable 3.0: Team Meeting Schedule6.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 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.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.Figure 1.0: SYSTEM ARCHITECTURE DIAGRAM for LTC-TMS8.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 DIAGRAM9.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. HardwareThe 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.DatabaseAs 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 ManagementThe 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, 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. 10.0 APPENDIX/ACRONYMSThe following acronyms are used throughout the SPP document and should be referred to for extrapolation of all acronyms utilized.DB - DatabaseHLD - High Level DesignHW - HardwareKU - Kutztown UniversityLTC - Long-Term CareMCU - Ming Chuan UniversityPM - Project ManagerRFP - Request for ProposalSPP - Software Project PlanTOC - Table of ContentsTMS - Task Management SystemCNO - Chief Nursing OfficerCNA - Certified Nursing AssistantWIFI- Wireless local area networkHIPPA - Health Insurance Portability and Accountability ActQA - Quality AssuranceRMP - Risk Management PlanSRS - Software Requirements Specifications HLD - High Level Design ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download