System Analysis and Design for Headspace- myassignmenthelp.com

Question: Discuss about the System Analysis and Design for Headspace. Answer: Introduction Technology is being used and applied in many of the business sectors with healthcare being a prime user and applicant of technology. There are several technological tools and applications that healthcare industries make use of for a variety of operations. Headspace is an organization that has decided to adapt the same by using an automated health record system. Headspace provides treatment and assistance to the patients suffering from any form of mental illness. The use of the health record system will enhance the quality of service provided by the organization. System Qualities (Non-Functional Requirements) The health record system that will be developed for Headspace will have the prime objective of easy management of the patient details and information along with ease of services for the patients. In order to achieve these aims, there will be many specifications and requirements that will be incorporated. One of the most significant set would be the non-functional requirements covering the qualities of the system that will be covered. Usability of Health Record System The system qualities of a particular system determine the alignment of the system with the specifications that are provided and the level of user experience that is earned by the system. For the health record system for Headspace, it would be essential that the expectations and necessities of the users are met through the functionalities included in the system. System Usability would be the non-functional requirement that would make it possible (Lauesen Younessi, 2016). The users must be provided with the ability to login, access information, control privacy setting of information etc. and the system shall be easy to navigate and the layout of the system must be simple. Reliability of Health Record System Health information is extremely sensitive information category and the sensitivity further intensifies with the involvement of mental health information. In cases of incorrect or invalid display of information by the system, the consequences can be extremely adverse (Chung, 2016). The system shall, therefore, always provide the users with reliable information and output. Performance of Health Record System The main aim of automation is to enhance the service speed and accuracy (Malan Bredemeyer, 2010). In case of delays by the system in terms of the time taken to respond to the user queries or the throughput time, the user experience will drop. Therefore, the system must be high-performing in nature at all times irrespective of the network connections or the number of users accessing the system. Supportability of Health Record System The health record system that is designed and implemented for Headspace must have the scope to be changed and modified as per the changing technology and user expectations. It must support the operating systems and other technical components for the purpose of strong integration (Shaikh Misbahuddin, 2016). System Interfaces User Interfaces of Health Record System Interaction and connectivity will be the two major parameters of the system and it would be essential that the maximum interactivity is maintained. Responsive web design shall be used as the design methodology for achieving this objective. The color scheme for the system shall be kept in accordance with the theme and the nature of the application. There shall not be use of extremely bright or extremely dull colors and a moderate color scheme shall be used and implemented. The users must be able to see the system behavior in terms of its recognition and response to the user action. For instance, when a user click on a button then it shall be highlighted with a different color and likewise. The choice of colors and the themes may vary from one user to the other. There shall be an option of customization and personalization that must be available for this purpose (Fosse Delp, 2016). The system shall also have consistency in terms of the layout of the UI elements and their placement, color scheme and themes. The layout of the system shall be simple and the patients as well as the medical team must be able to easily understand it. It is because of the reason that none of these users will have a very strong technical background to deal with the complexities of the technical concepts. The flow and navigation that would be implemented in the system must be simple and smooth. The users must be able to understand the flow of the system on their own without any external help. The text that would be present on the system must have a uniform style on all the system screens. There shall be use of a uniform color for all the headings and a uniform color shall be used for the text in the body section as well. The extraction of reports by the users shall be customized by allowing them to download or view the report in the desired format. External Systems/Devices Interfaces for Health Record System Patients shall be allowed to communicate with the medical professional using Simple Mail Transfer Protocol (SMTP). The sharing of the files shall be allowed on the system between the patient, medical professionals and among the medical team. The File Transfer Protocol (FTP) shall be set up for this purpose. The network connections shall be functional and their functionality shall be determined by the protocols as Transmission Control Protocol (TCP) along with the User Datagram Protocol (UDP). Real Time Protocol (RTP) shall be set up to allow the users to communicate with each other in real-time using options like instant messaging or tele-conferencing. There shall also be integration of the system with the basic health equipment for recording of the health signs by the patients (Conde et al., 2010). There shall be use of HTTPS and SSL for securing the information on the system from any of the security risks and attacks (Wheatcraft, 2010). System Constraints of Health Record System The front end of the system shall be developed using a programming language that is flexible and secure in nature. PHP shall be used as the language for creating the source code. Cloud databases and NoSQL databases shall be used for information storage, processing and management. TestLink shall be used for the creation and execution of the testing activities for the system (Dettmer, 2016). The defects shall be reported and managed by using the tool called Bugzilla. Review of the Applicable Cloud Based Solutions Cloud computing will have a great role to play in this case as the system will be deployed on cloud for making sure that remote access to the patients and medical team is possible. There will also be cloud databases that will be used for the information management. The deployment of the system can be done using any of the cloud models that are available on the basis of service, platform or infrastructure. The most suitable delivery model for health record system for Headspace would be Platform as a Service (PaaS) model of cloud. Health information is very sensitive in nature and the most important parameter behind the selection of the cloud model would be security. PaaS model would provide advanced security to the information and will also allow the updates to be easily installed. The maintenance will also be smooth and less complex and there will also be no issues around the ownership of the data and information in this model. The cloud services will be usable once they are deployed on the cloud using any of the cloud deployment models. There are three such models available which can be used viz. public, hybrid or private cloud models. The model most applicable in this case would be the hybrid cloud deployment model. This is because there will be sensitive, private, public and internal data sets that will be involved with specific cloud services around each. The deployment model would be required to handle all of these information types which would be best possible with a hybrid model. SDLC Approach for Health Record System SDLC stands for Software Development Life Cycle and it a process that involves all the activities that are involved in the development of particular software. There are many methodologies and mechanisms through which software such as health record system for Headspace can be developed. Predictive SDLC Approaches One of the SDLC approaches for health record system is the predictive approach in which the set of phases and activities to be applied are determined beforehand. These estimations and decisions are taken on the basis of the specifications and requirements along with the information collected from different sources. This approach will provide the management and leadership with the guidelines and framework that they must follow. However, it does not have the ability to handle the frequent changes in the project and the risk management is also weak in this case. One of the examples of this approach is the Waterfall model. Adaptive SDLC Approaches The second approach for the development of health record system is the adaptive approach that is value based. It is ad-hoc approach that carries out the set of tasks and activities on the basis of the situations in the project. It is extremely flexible in nature and can manage the changes with utmost ease. However, there may be certain hidden costs involved in this case. One of the examples of the adaptive SDLC methodology is the agile methodology for software development. Recommendations Conclusions The two different sets of approaches have been analyzed as per the requirements of the health record system for Headspace and the one that has been recommended is the adaptive approach. This is because in case of this system, the requirements are already determined but there can be a few modifications in terms of the number of patients to be handled by the system, new healthcare concepts to be integrated and likewise. Such requirements would be difficult to incorporate with the predictive SDLC approach. The adaptive SDLC methodology such as agile methodology would allow a flexible approach to be followed in all of the developmental tasks. Another recommendation that is provided to the project team is the use of an applicable project management methodology in the project life cycle. These methodologies will provide the project leadership and managers with the ability to manage the project risks, conflicts and problems and will also allow easy planning and estimation activities to be carried out. The methodology recommended for this project is Project Management Body of Knowledge (PMBOK). It will include five stages for the management of the project as initiation, planning, execution, control and closure. References Agilemodeling,. (2016). UML 2 Use Case Diagramming Guidelines. Agilemodeling.com. Retrieved 27 September 2017, from https://agilemodeling.com/style/useCaseDiagram.htm Bourne, L. (2016). Stakeholder Relationship Management. Retrieved 27 September 2017, from https://www.mosaicprojects.com.au/PDF_Papers/P128b_Stakeholder_Relationship_Management.pdf Chung, L. (2016). Non-Functional Requirements. Retrieved 27 September 2017, from https://www.utdallas.edu/~chung/SYSM6309/NFR-18-4-on-1.pdf Conde, J., De, S., Hall, R., Johansen, E., Meglan, D., Peng, G. (2010). Telehealth Innovations in Health Education and Training. Telemedicine And E-Health, 16(1), 103-106. https://dx.doi.org/10.1089/tmj.2009.0152 Dettmer, H. (2016). Systems and Constraints: The Concept of Leverage. Retrieved 27 September 2017, from https://goalsys.com/systemsthinking/documents/Part-6-SystemsandConstraints.pdf Fakhroutdinov, K. (2016). UML actor is a role played by a human user of the designed system, some other system or hardware that interacts with the subject by using services of the subject.. Uml-diagrams.org. Retrieved 27 September 2017, from https://www.uml-diagrams.org/use-case-actor.html Fosse, E. Delp, C. (2016). Systems Engineering Interfaces: A Model Based Approach. Retrieved 27 September 2017, from https://www.omgsysml.org/System_Engineering_Interfaces-IEEE_2013.pdf Lauesen, S. Younessi, H. (2016). Six Styles for Usability Requirements. Retrieved 27 September 2017, from https://www.itu.dk/~slauesen/Papers/SixStyles.pdf Malan, R. Bredemeyer, D. (2010). Defining Non-Functional Requirements. Retrieved 27 September 2017, from https://www.bredemeyer.com/pdf_files/NonFunctReq.PDF McAtee, M. (2016). A good compliance system takes the administrating out of managing. Qualitydigest.com. Retrieved 27 September 2017, from https://www.qualitydigest.com/nov01/html/paperless.html Rhyous,. (2011). The 8 Types of Technical Documentation and Why Each Is Important. Rhyous. Retrieved 27 September 2017, from https://www.rhyous.com/2011/07/21/the-different-types-of-technical-documentation-for-software-and-why-each-is-important/ Shaikh, A. Misbahuddin, M. (2016). A system design for a telemedicine health care system. Retrieved 27 September 2017, from https://gupea.ub.gu.se/bitstream/2077/10498/1/gupea_2077_10498_1.pdf Walker, D. (2016). Influence, Stakeholder Mapping and Visualisation. Retrieved 27 September 2017, from https://mosaicprojects.com.au/PDF_Papers/P062_Influence_Stakeholder_Mapping_and_Visualisation.pdf Watt, A. (2016). 5. Stakeholder Management | Project Management. Opentextbc.ca. Retrieved 27 September 2017, from https://opentextbc.ca/projectmanagement/chapter/chapter-5-project-stakeholders-project-management/ Wheatcraft, L. (2010). Everything you wanted to know about interfaces, but were afraid to ask. Retrieved 27 September 2017, from https://spacese.spacegrant.org/uploads/images/UserContributedFiles/WheatcraftInterfaces110909.pdf Wick, S. (2016). User Stories and Use Cases - Dont Use Both!. Batimes.com. Retrieved 27 September 2017, from https://www.batimes.com/articles/user-stories-and-use-cases-dont-use-both.html