Table of Contents



Software Project Plan Version 2.3Browser TeamMamadou S DialloTamara JenningsAlexander PosipankoJordy ThenDavid VeraPerrillen ZunigaCSC 354 Dr. TanTable of Contents TOC \h \u \z Table of Contents……………………………………………………………………………………………………………………………..……iREVISION HISTORY…………………………………………………………………………………………………………………………….…. PAGEREF _3dy6vkm \h iii1.0 INTRODUCTION………………………………………………………………………………………………………………………………. PAGEREF _4d34og8 \h 11.1 Project Description……………………………………………………………………………………………………………………. PAGEREF _961zkh21kxu7 \h 11.2 Project Scope…………………………………………………………………………………………………………………………….. PAGEREF _17dp8vu \h 11.4 User and User Environment……………………………………………………………………………………………………….. PAGEREF _26in1rg \h 21.5 Performance Issues……………………………………………………………………………………………………………………. PAGEREF _lnxbz9 \h 21.6 Management Technical Constraints…………………………………………………………………………………………… PAGEREF _1ybwg8ggem3x \h 22.0 PROJECT ESTIMATES…………………………………………………………………………………………………………………………. PAGEREF _lsh3jhq3kmbx \h 42.1 Historical Data Used for Estimates…………………………………………………………………………………………….. PAGEREF _44sinio \h 42.2 Cost Estimates…………………………………………………………………………………………………………………………… PAGEREF _2jxsxqh \h 42.3 Schedule Estimates……………………………………………………………………………………………………………………. PAGEREF _z337ya \h 42.4 Resources………………………………………………………………………………………………………………………………….. PAGEREF _3j2qqm3 \h 42.5 Team Structure………………………………………………………………………………………………………………………….. PAGEREF _ie77g46zeh3r \h 53.0 RISK MANAGEMENT………………………………………………………………………………………………………………………… PAGEREF _ytfdla6pmglc \h 74.0 PROJECT SCHEDULE/ACTIVITIES……………………………………………………………………………………………………… PAGEREF _3whwml4 \h 125.0 TEAM MEETING SCHEDULE…………………………………………………………………………………………………………….. PAGEREF _qsh70q \h 146.0 TRACKING AND CONTROL MECHANISMS………………………………………………………………………………………… PAGEREF _1pxezwc \h 176.1 Quality Assurance and Control…………………………………………………………………………………………………. PAGEREF _n5k6t178q1ne \h 176.2 Training and Preparation………………………………………………………………………………………………………….. PAGEREF _2p2csry \h 176.3 Measurements of Quality Attributes………………………………………………………………………………………… PAGEREF _td9ksn8q7x9t \h 176.4 Change Management and Control……………………………………………………………………………………………. PAGEREF _147n2zr \h 186.5 Version Control and Handling Change………………………………………………………………………………………. PAGEREF _3o7alnk \h 187.0 SYSTEM ARCHITECTURE DIAGRAM………………………………………………………………………………………………… PAGEREF _23ckvvd \h 188.0 CONTEXT DIAGRAM……………………………………………………………………………………………………………………….. PAGEREF _32hioqz \h 209.0 FEASIBILITY…………………………………………………………………………………………………………………………………….. PAGEREF _2grqrue \h 219.1 Economic Feasibility………………………………………………………………………………………………………………… PAGEREF _vx1227 \h 219.2 Organizational and Cultural Feasibility……………………………………………………………………………………… PAGEREF _3fwokq0 \h 219.3 Technical Feasibility…………………………………………………………………………………………………………………. PAGEREF _1v1yuxt \h 219.4 Schedule Feasibility………………………………………………………………………………………………………………….. PAGEREF _4f1mdlm \h 229.5 Resource Feasibility…………………………………………………………………………………………………………………. PAGEREF _2u6wntf \h 2210.0 ABBREVIATIONS……………………………………………………………………………………………………………………………. PAGEREF _q77sufoc5k31 \h 2310.1 Acronyms and Abbreviations………………………………………………………………………………………………….. PAGEREF _3tbugp1 \h 2311.0 Reference Page PAGEREF _w1atnx3fsa4b \h 24 TOC \h \u \z 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.VersionDateDescriptionEditor1.09/19/2018 Created document.Wrote Project Description first draft (1.1).Worked on major functions first draft (1.3).Alexander PosipankoWorked on Project Resource (2.3)Worked on Cost Estimates (2.2)Jordy Then1.19/20/2018Wrote section on Version Control and Handling Change (6.2)Wrote Economic Feasibility (9.1)Alexander PosipankoWrote Management/Tech Constraints (1.6)Wrote Team Structure (2.5)Wrote Risk Management (3.0)Wrote Team Meeting Schedule (5.0)Wrote Schedule Feasibility (9.4)Wrote Resource Feasibility (9.5)Tamara JenningsWrote Historical Data Used for Estimates (2.1)Wrote Testing (6.1.3)Worked on the System Architecture Diagram (7.0)Worked on formattingJordy ThenWrote Project Scope (1.2)Wrote Performance Issues (1.5)Wrote Training and Preparation (6.1.1)Wrote Organizational and Cultural Feasibility (9.2)Wrote Technical Feasibility (9.3)Perrillen ZunigaWrote Users and Users Environment (1.4) Created Project Activities (4.0)David VeraWorked on Schedule Estimates (2.3)Worked on Tracking and Control Estimates (6.0)Worked on Quality Assurance and Control (6.1)Worked on Appendix (10.0)Mamadou S Diallo1.29/21/2018Updated Index and page numbersCreated Context Diagram (8.0)Updated Acronyms and Abbreviations (10.1)Tamara Jennings2.09/24/2018Created Software Project Plan version 2 documentAdded indentation to indexChanged name of section to Abbreviations (10.0)Tamara Jennings2.110/10/2018Worked on Historical Data (2.1)Worked on Schedule Estimates (2.3)Worked on Team Structure (2.5)Worked on Acronyms and Abbreviations (10.1)David VeraEdited Introduction (1.0)Edited Project description (1.1)Edited Project Scope (1.2)Edited Major function(1.3)Wrote User and User environment(1.4)Edited Performance issues (1.5)Edited Management technical constraints(1.6)Mamadou S DialloEdited Context Diagram(8.0)Edited System Architecture Diagram(7.0)Perrillen Zuniga2.210/11/2018Edited Team Meeting Schedule (5.0)Edited Economic Feasibility (9.1)Edited Organizational and Cultural Feasibility (9.2)Tamara JenningsEdited Acronyms and Abbreviations (10.1) Edited Project Description (1.1)Renamed subsections in section 6Edited Training and Preparation(6.2)Wrote Measurements of Quality Attributes (6.3)Alexander PosipankoEdited Revision History Perrillen ZunigaEdited Schedule Estimates (2.3)Edited Resources (2.4)Edited Reference Page (11.0)David VeraEdited Risk Management (3.0)Jordy Then2.310/12/2018Revised and edited Introduction (1.0)Revised and edited Project Description (1.1)Revised and edited Project Scope (1.2)Revised and edited Major Functions (1.3)Edited Risk Management (3.0)Edited Technical Feasibility (9.3)David VeraEdited Project Scope (1.2)Tamara JenningsTable 1: Revision History1.0 INTRODUCTIONThe Software Project Plan (SPP) describes the Browser team’s understanding of the Long Term Care Task Management system. This project is intended to help medical staffs with managing their patient’s activity and vitals efficiently.1.1 Project DescriptionThe purpose of the LTC-TMS is to help CNAs with managing their patients’ daily activities in a medical facility. The system will allow directors and CNOs to create tasks, save tasks, publish tasks, edit tasks, and manage tasks, as well as being able to assign tasks to the end users. CNAs and family members of the patients will also be able to view tasks. In addition to patient activities, this project will collect temperature, heart rate, and step count data from external sensors, which will be able to be viewed by all parties - the directors, CNOs, CNAs, and family members.1.2 Project ScopeThe LTC-TMS will consist of software and hardware components. The software components are the browser application and the mobile applications. The hardware components are the wearable sensors and the room sensors. The browser application will be available to the director and CNO of a facility employing LTC-TMS. It will allow them to monitor a patient’s vitals and tasks. These staff members will also be able to add a working schedule and a center schedule. The working schedule shows the hours that facility staff work. The center schedule shows the activities for the center, such as a planned family visit day. From the browser application, the director and CNO can also view data collected from the room sensors, like room temperature. They will be able to monitor data from the room sensors and patient vitals in real time.The mobile application will be available to CNAs and the family members of a patient. If will allow both the CNA and the family to monitor a patient’s vitals and tasks. CNAs will be able to assign tasks to patients and mark the status of the task (for example: in progress, complete, etc.). The CNAs will be able to view vitals and room data collected from the sensors in real time. There will be two hardware components - a wearable sensor and a room sensor. The wearable sensor will be worn by the patient on their wrist and collect heart rate and step count data. The room sensor will collect room temperature and humidity data. The data collected from the sensors will be sent to the database in real time.1.3 Major FunctionThe LTC-TMS will have differing functions depending on the type of user. Directors, CNOs, CNAs and family members will have different levels of privilege and features. The data to be collected from the sensors is identified below:The patient’s heart rate will be captured by the wearable sensor. The patient’s daily step count will be captured by the wearable sensor.The room’s temperature will be captured by the room sensor.The room’s humidity will be captured by the room sensor.The task management system functions will be as follows:Directors and CNOs will have the ability to assign tasks.Directors and CNOs will have the ability to create and assign surveys to tasks.Directors and CNOs will have the ability to record and modify medical As and patients will have the ability to view As and patients will have the ability to provide feedback on the applications.1.4 User and User EnvironmentThe browser application will used by directors and CNOs. The browser application is intended for use on desktop computers and will be compatible with Internet Explorer, Chrome, Safari, and Firefox.1.5 Performance IssuesPerformance issues may include issues loading web pages and issues uploading files, which may result from the server being overloaded or the web pages being inefficient. The browser application needs to be accessible to the director and CNO at all times of the day and should not have a response time delay that is more than 3 seconds. Other issues could include the failure to connect to the database. Internet connection is required for the LTC-TMS to work.1.6 Management Technical ConstraintsThis project will have a number of management constraints. Since this project does not have a real-life client to pay for software and hardware, the project team will have to apply for grants to cover the costs. The system must be able to support all of the medical staff and residents’ activities without any noticeable delay in response time. Without a true client, identifying requirements might be more difficult as planning and development continue. A major constraint is time. Since the timeline for completion is two semesters, there will be many things do accomplish in a short amount of time. Another constraint is the relationship between the KU teams and the MCU teams. There are cultural and language differences which can greatly affect communication. The 12-hour time difference also adds another layer of difficulty. In addition to the management constraints, this project will have technical constraints. Included in these is the lack of technical experience of the teams. Most of the team members’ technical experience comes from class-related activities, meaning that this is likely the first project of great magnitude for many of them. Time also affects this technical constraint because there is a limited amount of time for team members to learn and apply the required skills. Picking up where the MCU students is also a technical constraint because the teams will have to follow along with their formatting and style of coding and documentation. The coding languages that will be used will also be a technical constraint. JavaScript and HTML will be the languages used to develop the browser application, so the team must not use any other languages. The type of database is also a constraint. A real-time database must be used for this project to store data that is constantly being added and modified. 2.0 PROJECT ESTIMATESThe following sections will detail estimates relating to the project.2.1 Historical Data Used for EstimatesThe LTC-TMS Browser team has used the website, Kinvey, to estimate the cost of gathering all of the hardware required for creating the LTC-TMS. Resources including software and hardware expenses are covered by Kutztown University via a grant for the project team applied. 2.2 Cost EstimatesThe LTC-TMS will be the product of a team consisting of students who are working on this project for a course grade instead of monetary gains. Since labor costs will not be a factor, the only costs to consider are the hardware costs. 2.3 Schedule EstimatesThe LTC-TMS is expected to take roughly 3,360 man hours over the course of 30 weeks to complete this project. Many factors can change the time required to finish the application such as training, development, testing, unexpected delays, etc. Analysis and design will take place in the fall of 2018, while development and testing will happen in the spring of 2019. 2.4 ResourcesResources needed for this project include both software and hardware. Raspberry Pi and Micro:bit are needed for data collecting for the hardware, JavaScript is the programming language that will be used for the implementation of the browser application. An efficient and reliable database that provides real time data transfer is required. Private and reserved allocated resources, such as a server for hosting, will be provided by KU. Personnel will be gathered from Dr. Tan’s Software Engineer class and MCU who will be collaborating on the LTC-TMS.2.5 Team StructureTeam members and their designated roles are outlined in Table 2. MemberRoleDescriptionTamara JenningsTeam Lead / Back End DeveloperAs Team Lead, Tamara will provide leadership during the systems development life cycle as it applies to the Browser team. She will assign duties and allocate resources as necessitated by project requirements. As a Back End Developer, Tamara will work to make sure the server, database, and web application work together to allow the front end to function properly.Alexander PosipankoBack End Developer, System DesignerAs a Back End Developer, Alexander will work to make sure the server, database, and web application work together to allow the front end to function properly. As a System Designer, Alexander will be responsible for turning requirements into design models to be implemented.Mamadou S DialloFront End Developer, System DesignerAs a Front End Developer, Mamadou will be responsible for creating a functional user interface that allows users to interact with the system. As a System Designer, Mamadou will be responsible for turning requirements into design models to be implemented.MemberRoleDescriptionDavid VeraFront End Developer, System DesignerAs a Front End Developer, David will be responsible for creating a functional user interface that allows users to interact with the system. As a System Designer, David will be responsible for turning requirements into design models to be implemented.Jordy ThenSystems Analyst, TesterAs a Systems Analyst, Jordy will verify that all of the requirements are clear and that the team is meeting them. As a Tester, Jordy will be responsible for verifying that the system is functional and that any changes made, does not cause additional issues. Jordy will also be tasked with reporting and providing feedback about usability and whether the browser is simple to use and easy to understandPerrillen ZunigaSystems Analyst, TesterAs a Systems Analyst, Perrillen will verify that all of the requirements are clear and that the team is meeting them. As a Tester, Perrillen will be responsible for verifying that the system is functional and that any changes made, does not cause additional issues. Perrillen will also be tasked with reporting and providing feedback about usability and whether the browser is simple to use and easy to understandTable 2: Team Structure3.0 RISK MANAGEMENTRisk is unavoidable with any project, especially in software development. The table below outlines some major risks and mitigation strategies. Each risk has a risk ID, description of the risk, type, severity level, impact level, probability level, mitigation strategy, and assignee. Type categorizes risks into categories regarding whether the risk is a fiscal, personnel, or technical problem. Severity categorizes risks into different levels of intensity and determines the how badly each risk could affect the project. Probability determines the likelihood that risks will occur if not handled. Impact determines how badly the risks will affect the project. Mitigation strategy provides plans to reduce the impact of the risks and it categorizes the plans into whether the risks should be mitigated, transferred, accepted, or avoided. Assignee displays a team member assigned to each tasks, and they are responsible for mitigating the risks. The probability and potential impact of each risk identified in the risks table below will be evaluated and classified according to the following definitions.Severity● Critical (C): This refers to a risk that could lead to project failure (inability to deliver theproject as described).● Serious (S): This refers to a risk that could have a major impact on project cost anddelivery timeline. Second-tier requirements may not be completed in time.● Moderate (Mo): This refers to a risk that could have a moderate effect on the projectcost/schedule. Project-critical requirements would still be achieved.● Minor (Mi): This refers to a risk that could have only a small effect on the projectcost/schedule. Project requirements, both primary and secondary would still be met.● Negligible (N): This refers to a risk that would have no effect on the project. Allrequirements would still be met, with little to no effect on the schedule and budget.Probability● Very High: Greater than 85% probability of occurrence● High: Greater than 70% probability of occurrence● Medium: Greater than or equal to 45% probability of occurrence● Low: Less than 45% probability of occurrenceImpact● High: A risk that has the potential to have a significant impact on project schedule, cost,or requirements● Medium: A risk that has the potential to have a moderate impact on project schedule,cost, or requirements● Low: A risk that has a small potential of impacting project schedule, cost, orrequirementsIDDescriptionTypeSeverityImpactProbabilityMitigation Assignee01Software incompatibility (for example: program languages and database are not meshing together very well, or a decision to change programming language or change database)TechnicalCriticalMedium MediumMitigation: Do research beforehand and actually try out the relevant software/technology before using it in the actual projectPerie Zuniga02The lack of communication between teams due to various of reasons such as, misunderstanding or misconstruction, could occur.PersonnelHighHighLowMitigate: Team leads give weekly updates on their team’s progress.Tamara JenningsIDDescriptionTypeSeverityImpactProbabilityMitigation Assignee03Poorly specified scope of work that may result in the addition of unnecessary featuresTechnicalMediumHighMediumAccept: Allow for user feedback for insurance that it is what the client wants and envisionsPerie Zuniga04The project team currently has no real client to test the hardware/ application.TechnicalCriticalHighMediumMitigate: Designate team members to research a client to test the system to help achieve the highest probability of success. Mamadou Diallo05A team member could be unable to work due to being sick or unavailable due to personal problems such as doctor appointments, car accidents, etc.PersonnelModerateMediumMediumMitigation: Have an extra person who knows what needs to be done at the current stage of the project to cover on the behalf of the unavailable team memberJordy Then06The User Interface between multi- platform applications can be inconsistent, with one platform having different features than the other when both should have similar features and usability.TechnicalMinorMediumMediumMitigation: The app and browser teams must collaborate with each other to ensure a consistent experience and interface on all platforms.David VeraIDDescriptionTypeSeverityImpactProbabilityMitigation Assignee07Increase of Software Bugs with future feature implementationTechnicalModerate or SevereMedium/HighMedium /HighMitigation: Instilling a protocol for testing and approval of new features and an option to receive feedback from the end-user. Mitigation: Having a list of verified devices (i.e. testing the app functionality on specific devices like an iPhone 7 and Samsung Galaxy Tablet and verifying that there are no major issues) before deploying updates.Jordy Then08AppInventor2 was abandoned by its creators, meaning there will be little to no technical support (Google has already abandoned it).TechnicalCriticalLowLowTransfer: Find a solution to export AI2 programs into a more popular IDE (Android Studio). Mitigation: Rewrite in Android Studio.Tamara Jennings09Firebase has a change of management, where Google does not support Firebase anymoreTechnicalCriticalCriticalLowTransfer: Develop and test a plan to migrate the data off of Firebase and into another NoSQL database. See if it is even viable to do so.Perie ZunigaIDDescriptionTypeSeverityImpactProbabilityMitigation Assignee10Total hardware failure (when the hardware stop working).Technical Critical CriticalLowMitigation: Order hardware in case a component suddenly failsMamadou Diallo11If the user hardware is being overused, can lead to the potential of the hardware being destroyed.TechnicalCriticalCriticalMediumMitigation: Design the components to withstand more than daily use to prevent hardware from suffering user inflicted damage.Alex Posipanko12The lack of funding for the hardwareFinancialCriticalCritical MediumTransfer: Acquire a secondary funding source for the system such as sponsorships or grants. Jordy Then13Inconsistency when building a multiplatform app can be the result of separate teams working on separate application developmentTechnicalHighHighMediumMitigation: Constantly compare set-based codes and share visualization to detect the inconsistency. David Vera14Web Hosting Sites experiences an outage or the company that is hosting the site becomes out of serviceTechnicalCritical HighLowTransfer: Have a secondary web hosting site to back up our websiteTamara JenningsIDDescriptionTypeSeverityImpactProbabilityMitigation Assignee15 Project testing halted due to being put on a waitlist to get the permission to test on real clients on public facilities.TechnicalCriticalHighMediumMitigation: Have team members inquire facilities for authorization to perform testing, within the early stages of implementation to avoid waiting later on.Jordy ThenTable 3: Risk Log4.0 PROJECT SCHEDULE/ACTIVITIESIn order to complete the project on time, the project team will keep a schedule of activities, as shown in Table 4. It includes a brief description of each activity. This will include the duration, due date, and status. Activity details are subject to change.Tasks, Phases, ActivitiesDuration (in weeks)Due DateStatusDefined the problem (class discussion)19/7/2018CompleteDevelop Request for Proposal Version 119/14/2018CompleteDevelop Software Project Plan Version 1 19/21/2018CompleteDevelop Request for Proposal Version 219/28/2018CompleteDevelop Risk Management Procedure Version 1110/5/2018CompleteDevelop Software Project Plan Version 2 110/12/2018CompleteDevelop Risk Management Procedure Version 2110/19/2018In ProgressDevelop Software Requirement Specification Version 1110/26/2018Not StartedDevelop Software Requirement Specification Version 2211/7/2018Not StartedDevelop High Level Design Version 1111/16/2018Not StartedDevelop High Level Design Version 2312/5/2018Not StartedTable 4: Project Schedule5.0 TEAM MEETING SCHEDULEThe dates, times, and locations for Browser Team meetings for the rest of the semester are shown in Table 4. Typically, meetings are held on Thursdays between 11:00AM EST and 12:00PM EST. This schedule is tentative.The meetings with MCU are held using Google Hangouts, a video call service. The team members of MCU prefer to meet with the team member of KU at 11:00AM EST because this time does not interfere with their classes and meeting schedules. However, the KU Browser team remains in constant communication with the MCU team to adjust times as necessary. The meetings with only the KU Browser Team are held in person unless otherwise specified in the Location column.TimeAttendeesLocationDateScribeStatus11:00AM-11:30AMKU & MCU Browser TeamsOM 156/ MCU9/13/2018Jordy ThenComplete11:30AM-12:00PMKU Browser TeamOM 1569/13/2018Jordy ThenComplete11:00AM-11:20AMKU & MCU Browser TeamsOM 156/ MCU9/20/2018Tamara JenningsComplete11:00AM-12:00PMKU Browser TeamOM 1569/20/2018Tamara JenningsComplete11:00AM-11:30AMKU & MCU Browser TeamsOM 257/ MCU9/27/2018Jordy ThenComplete11:30AM-12:00PMKU Browser TeamOM 1569/27/2018Jordy ThenComplete11:00AM-11:30AMKU & MCU Browser TeamsOM 156/ MCU10/4/2018N/ACancelled11:00AM-11:40AMKU Browser TeamGoogle Hangouts10/4/2018David VeraComplete11:00AM-11:30AMKU & MCU Browser TeamsOM 156/ MCU10/11/2018Perrillen ZunigaComplete11:30AM-12:00PMKU Browser TeamOM 156/ Google Hangouts10/11/2018Perrillen ZunigaCompleteTimeAttendeesLocationDateScribeStatus11:00AM-11:30AMKU & MCU Browser TeamsOM 156/ MCU10/18/2018Alexander PosipankoNot Started11:30AM-12:00PMKU Browser TeamOM 15610/18/2018Alexander PosipankoNot Started11:00AM-11:30AMKU & MCU Browser TeamsOM 156/ MCU10/25/2018Mamadou DialloNot Started11:30AM-12:00PMKU Browser TeamOM 15610/25/2018Mamadou DialloNot Started11:00AM-11:30AMKU & MCU Browser TeamsOM 156 /MCU11/1/2018Tamara JenningsNot Started11:30AM-12:00PMKU Browser TeamOM 15611/1/2018Tamara JenningsNot Started11:00AM-11:30AMKU & MCU Browser TeamsOM 156/ MCU11/8/2018Jordy ThenNot Started11:30AM-12:00PMKU Browser TeamOM 15611/8/2018Jordy ThenNot Started11:00AM-11:30AMKU & MCU Browser TeamsOM 156/ MCU11/15/2018David VeraNot Started11:30AM-12:00PMKU Browser TeamOM 15611/15/2018David VeraNot Started11:00AM-11:30AMKU & MCU Browser TeamsOM 156/ MCU11/22/2018Perrillen ZunigaNot Started11:30AM-12:00PMKU Browser TeamOM 15611/22/2018Perrillen ZunigaNot Started11:00AM-11:30AMKU & MCU Browser TeamsOM 156/ MCU11/29/2018Alexander PosipankoNot Started11:30AM-12:00PMKU Browser TeamOM 15611/29/2018Alexander PosipankoNot StartedTimeAttendeesLocationDateScribeStatus11:00AM-11:30AMKU & MCU Browser TeamsOM 156/ MCU12/6/2018Mamadou DialloNot Started11:30AM-12:00PMKU Browser TeamOM 15612/6/2018Mamadou DialloNot StartedTable 5: Scheduled Browser Team Meetings6.0 TRACKING AND CONTROL MECHANISMSThe Browser team will be using a GitHub repository to store all of the code. GitHub also enables version control and allows team members to work on different parts of the code base without interfering with each other.6.1 Quality Assurance and ControlQuality assurance refers to all activities designed to measure and improve quality in a product, including the whole process, training, and preparation of the team.Quality control usually refers to activities designed to verify the quality of the product, detect faults or defects, and ensure that the defects are fixed prior to release. --p.200, Essentials of Software Engineering, 3rd EditionIn order to stay on schedule while meeting all requirements asked of the team, the following activities will take place weekly to ensure quality assurance and control:● Reviewing work to ensure it meets the specific requirements● Communication with MCU students● Communication between team member● Discussing any changes made to the schedule or project code● Timely reporting of activities to the team leader6.2 Training and PreparationThe team members will need to know how to work the front-end and the back-end of the web application. That includes becoming familiar with JavaScript, mongoDB, Firebase, HTML, and CSS. The team must also be aware as to where the browser will be used, which is most likely going to be in a long-term care facility. The website has potential to be used by many concurrent users and the team needs to be able to handle the system if it does become overloaded.6.3 Measurements of Quality AttributesThere are several important aspects to consider regarding the quality of the system.The most fundamental attribute that determines the quality of the system is uptime. The system should be down for no more than 20 minutes in any given 24 hour period, bar announced and scheduled maintenance periods.The user experience should remain consistent and functional throughout all major modern browsers (Chrome, Safari, Firefox, and Internet Explorer 11). All features should be identical in function between the browsers.The user interface should be easy to navigate for all users. To measure this, a survey given to sample users who are unfamiliar with the system will be required. At least 80% of UI navigation tests having positive reported results is ideal.6.4 Change Management and ControlAny major changes to the project will be discussed in the team meetings while immediate changes will be discussed in the Slack application used for communication. GitHub has a built in system for merging code that allows for users to code simultaneously and merge the code seamlessly.6.5 Version Control and Handling ChangeGitHub will be used for version control, allowing various team members to commit changes without risking the integrity of the code base. The programmers committing changes will do so by using the GitHub version management system so that changes will be easily tracked and reverted if necessary. When writing and editing documents, revision history will be maintained in a table within the document. Files will be located in the team’s Google Drive, where versions documents will have designated folders. When changes updated for hardware and programming languages are released, the project team will meet to discuss if the updates are compatible with the system and decide whether it is appropriate to update the system as well.7.0 SYSTEM ARCHITECTURE DIAGRAMFigure 1 displays the system architecture that depicts the operating environment of the LTC-TMS. Firstly, the hardware consists of Raspberry Pi, Micro:bit, heart beat rate sensor, and temperature and humidity sensor. Then a database is used to hold all the data gathered from the sensors, along with other data like account information and user tasks. A server will gather requests from the end users and send back responses. Lastly, the PC, mobile, and tablet provides information from the database to the end users through the front end-task assistant, such as a browser for computer, or the back end-task manager, which will be a way for the CNO to edit the patients information as well as provide personnel the ability to edit and add tasks to their profiles. The front end-task assistant will be the homepage where family of the patients can view their loved ones information.Figure 1: System Architecture Diagram8.0 CONTEXT DIAGRAMThe following context diagram shows, at the highest level, the users who will be interacting with the system. This diagram is specific to the browser version of the LTC-TMS. Since only long-term care facility members will be using the browser version, they are the only identified people that will interact with the system. Personnel include the facility director, nurses and doctors. Family members of the patient will also have the ability to have access to the browser version of system, but to only view the data collected from the device. The database will hold the information that the CNO and the patient’s individual devices either add or edits on the browser. Personnel Family MembersLTC-TMSAccess to task management systemsCan view the patients informationCNOCan both edit and add information to patient’s profileDatabase Hold all the patients information along with tasks for the personnelPersonnel Family MembersLTC-TMSAccess to task management systemsCan view the patients informationCNOCan both edit and add information to patient’s profileDatabase Hold all the patients information along with tasks for the personnelFigure 2: Context Diagram9.0 FEASIBILITYThe following section describes the feasibility of different aspects of the project and how they affect the project. 9.1 Economic FeasibilityIdentification of the hardware to be used for monitoring and data collection, the Kutztown University server to be used for hosting, and the cloud-based database system make the costs of development clear, meaning there will be little to no unexpected costs. All of these components are crucial to developing the LTC-TMS, and have been identified as attainable due to their low cost and the ease with which they can be procured for use by the project team. As a result, the development phase of the project is economically feasible.When the system is deployed, the cost of hosting the database via cloud-based systems will grow. These costs will be fairly low on a per-client basis, making ownership of the system financially feasible. If the database is to be self-hosted by Kutztown University using an open-source database system, this long-term cost will be negated.9.2 Organizational and Cultural Feasibility Due to the time difference between the MCU and KU students, the feasibility of the project will be difficult but doable. The language barrier has the potential to be a significant problem; however, to this point, it has not affected the project. To work together, both groups need to be able to communication and plan around the time difference accordingly.The personal and professional lives of the KU students also have the potential to affect the probability of this project being completed on time and in budget. Most of the students on the project team are taking other classes. In addition to other scholastic endeavors, some members of the project team have part-time or full-time jobs. These activities add another layer of complexity to the project since they could affect a team member’s ability to complete their work on time and/or attend meetings. Despite this, the feasibility of the project remains high given that the students have had years of experience balancing school and work related duties.Since the members of the project team have different backgrounds and levels of experience with a project of this magnitude, their work styles likely differ. Different work styles are not a bad thing as long as team members communicate regularly and complete their tasks on time. Differences could cause some issues initially, while team members get familiar with one another, but with communication, the number of issues related to this should drop. This should have few negative effects on the project. 9.3 Technical FeasibilityThere is a possibility that some features may be difficult to implement. No testing has been done, so it is hard to know which features may or may not cause difficulty. The features that are required for the browser should be prioritized, if there are any features that are proving to be too difficult to implement and if too much time is being spent working on the problem. then it should be removed from the tasks in order of from least to most important. The focus should be on what is absolutely required first.9.4 Schedule FeasibilityScheduling will be very important throughout this project. Organizing and maintaining a consistent schedule will be key in order to succeed. The team found common times to hold meetings so that all members can attend. Also, the team has a regularly scheduled weekly team meeting. Scheduling meetings with students from MCU will be challenging at times, but give-and-take from both teams should reduce the risk of this being a large issue.9.5 Resource FeasibilityThe resources needed for development are access to the embedded systems and sensors, listed below, and hosting provided by KU. It should be reasonable to get the funding needed for the hardware, being that the embedded systems and sensors are relatively inexpensive.10.0 ABBREVIATIONSThe following is a list of acronyms and abbreviations used throughout this document10.1 Acronyms and AbbreviationsThe below table is a listing of all acronyms and abbreviations used within this document with their meanings.Acronym Acronym Meaning CNACertified Nursing AssistantCNOChief Nursing OfficerKU Kutztown UniversityLTC-TMSLong Term Care Task Management SystemMCUMing Chuan UniversitynoSQLNon Structured Query LanguagePCPersonal ComputerSPPSoftware Project PlanSQLStructured Query LanguageSRSSoftware Requirements SpecificationTMSTask Management SystemTable 6: Acronyms and Abbreviations11.0 Reference PageBelow is the reference page of external sources that information was gathered fromEnterprise Mobile Experiences With Low Code Backend - Progress Kinvey. (n.d.). Retrieved from ................
................

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

Google Online Preview   Download