Sana_Final_Project_Documentation
- 1. SANA Project documentation Project overview: Sana is a cross-disciplinary organization,includingclinicians,engineers,policy,public health,and business experts along theentirehealthcarevaluechain.The approach is to democratize access to quality healthcare through open source technologies, democratize knowledge through the exchange of learning across partners, and to democratize access to global networks of multidisciplinary experts. We believe that geniuses abound in the partner countries, and these geniuses are more likely to develop sustainable and scalable solutions, as they better understand the local problems and environment. It is an open source project which enables high quality health diagnosis in rural area also. Since it is an open MRS project, anybody can extend it to include new features and functionality. Project scope: In the Sana module application,the end user, a clinician in the rural area,have to login or sign up into the application. He has to add new case or edit into existing case by taking audio, video, images and text as information. He then sends this information to the server in which it is queued and forwarded to the specialist.Based on provided information,the specialist diagnose the disease. That diagnosis is sent back to thesame clinician whoadvised the patient about theillness and directs him/her toproper medication or treatment. The history of patient is saved and stored in the database for future reference. Requirement metadata: The team Impulse considered the following two requirements to extend the Sana module. ļ· Extend current protocol builder that provides a repository of Sana compatible apps, allows clinicians toselect and include them in protocols, and an API for downloadingthem to the mobile client. ļ· To play media files (audio-mp3, video-flv, and mp4) directly on the mobile application (Impulse media player) without using externa players. It should be able to pause as well as forward/rewind media files on the application. Progress on scrum-board: Team scored the given list of projects and select Sana module as a first priority and gets Sana as a project. Following is progress of team Impulse in each sprint. Sprint 1: (21 September ā 5 October) ļ· The team didnāt have proper requirements and also no single point of contact. So, the team did self-research on the requirements by going through the screenshots of Sana module. ļ· The team also searched in the different websites about technical frameworks used in Sana and got the pdf about requirements document.
- 2. ļ· The team mailed and contacted the developers of Sana module in MIT. Sprint 2: (5 October ā 19 October) ļ· The team gone through all the requirements in the obtained requirement document found in the first sprint. ļ· The team then decided to choose the first requirement mentioned above (protocol builder). ļ· The team started analyzing components required and installed them. ļ· The team did the feasibility study on the protocol builder and recognized that it cannot be done given the number of frameworks involved and the tight time constraint. ļ· Team choose the second requirement mentioned above (Media rendering). ļ· The team did feasibility check by verifying if an external android library can be used to render media files (.mp4 format was chosen). ļ· The team communicated with Professor Gary about the finalized requirements. 3. Sprint 3: (19 October ā 02 November) ļ· Design pattern applied in this sprint,Creational- Abstract factory pattern: where the pattern can be used with the intent to provide an interface for accessingfamily of related objects,but without exposing theunderlying concreteclasses. Here, our implementation of playing, pausing, forward, reverseoptions arecommonly occurringamongst the various media formats.A factory method to enable format specific invoking of functions and an interface that implements access to the functions mentioned above for different formats, without exposing the underlying classes are provided. ļ· The basic framework for implementation of the API and android interface to be used committed to the master code on GitHub, although it is open to further changes. ļ· The implementation for the media formats mp4 and flv have been analyze, coded and proposed for merging to master branch via individual branches.It is open to changes and is to be integrated during the last stages of the last sprint. ļ· User story compliance check has been performed. 4. Sprint 4: (02 November ā 16 November) ļ· MediaViewer features such as play, pause, forward, reverse were implemented for all the media formats. ļ· The design pattern used for this part of coding is thestructural design pattern-Bridge.Here, every formatās object interfaceis separated from its implementation,which is to betested in an integrated way in sprint 5. ļ· Integration plan for the final sprint where the wrapper is integrated and tested with a test application designed. 5. Sprint 5: (16 November ā 23 November) ļ· Design pattern applied in this sprint, Structural design pattern- Facade: where the whole subsystem that represents media player activities for each format is encapsulated in a single class. ļ· The basic frameworkfor implementation of the API, along with its complete implementation and android application to be used for testing committed to the master code. ļ· User story compliance check has been performed.
- 3. ļ· Final testing after integration of all formats into a single class has been performed using a test application created by the team. ļ· Based on the instructions given in class, presentation is ready to be delivered. Current status: The team has completed successfully the Impulse Media Player for rendering media files (.mp3, mp4 and .flv formats). Risk management: Major risks ļ· As agile cannot capture non-functional requirements properly, there is a risk of not addressing non-functional features. Risk Probability Impact Exposure 1 0.20 3 0.60 Risk mitigation strategy: ļ· Non-functional requirements can be addressed as future enhancements to the project. Method, Tools and Techniques: Tools: i) Android studio 1.4 or eclipse with android support ii) Nexus 5 API 21 and above device (Testing purpose) Methods: Scrum Methodology: The whole project will bedelivered in chunks depending on therequirements prioritization. Development team will get a specific amount of time to implement each chunk of functionality. Test plan: Major Milestones The final product release is on 23rd November 2015.
- 4. Minor Milestones These milestones are the iterative and incremental feature delivery at the end of each sprint. This allows customers to see the progress made compared to the overall project. This also allows customers to give feedbacks on the developed features, which can then lead to changes or additional features to be implemented in the next sprint. Resource Identification: Staff: The team size will be constant throughout the project. Time: Start Date: 21 September, 2015. End Date: 23rd November, 2015. The final released date is set to3rd December 2015. Features are tobe delivered iteratively every onetofour weeks, depending on the complexity of the implementing feature. Cost: N/A. Project Artifacts: Document Name Description Project Outline A general overview of the project with someof its key features. Requirements List of product backlogs capturing user requirements. (Available on taiga https://tree.taiga.io/project/ser515asu- sanamodules-impulse/ ) User acceptance test plan Document capturing acceptance test cases. Project Schedule (Sprint Schedule) The breakdown of how long each iteration will take and tasks accomplished. (Available as Sprint documentation update).
- 5. Source Code Source code required to build an executable product and incorporatethesolution with deployment tools on theclient- ad server-side platforms. (Available on Github https://github.com/ser515asu/SanaModules-Impulse.git ) User Manual/ Setup Documents Formal setup documents and User manual will be provided to help users in setup and maintenance of the product. (User Manual will beoptional and will only be provided if time permits) Design Document Design document will be provided for maintenance purposes. Lessons learned: Adherence to software process important to track progress. Feasibility analysis serves as a main source to confirm the successful implementation. Hurdles: Requirements elicitation was a hurdle due to the broken communication with the clients, i.e. Sana developers. Frameworkanalysis ofalready developed platform,which was timeconsumingand could not enable covering study of all the frameworks in the given time frame. References: Score: http://score-contest.org/2016/projects/sana.php MIT: http://sana.mit.edu/# Sana Technical: http://sana.mit.edu/wiki/index.php?title=Features http://sana.mit.edu/mobile/documentation/developers/ http://sana.mit.edu/mobile/documentation/developers/mobile/ http://sana.mit.edu/mobile/documentation/developers/middleware/ http://sana.mit.edu/mobile/documentation/developers/module/