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/