research proposal

Document Sample
research proposal Powered By Docstoc
					                    UNIVERSITY OF THE WESTERN CAPE
                     RESEARCH PROPOSAL (DRAFT 02)

Name of candidate       : Xolisa Vuza
Student number          : 9912326
Proposed degree         : Master of Science
Department              : Computer Science
Title of thesis          : IP- based Multimodal Communication Services in South
Supervisor              : Mr. W.D. Tucker
Date                    : 23 March, 2004
                                      1. ABSTRACT

Currently, in two Eastern Cape villages, Tsilitwa and Sulenkama, there is a communication
infrastructure that was put into place by the Council for Scientific and Industrial Research
(CSIR). This infrastructure is used to provide a wireless (WIFI) connection between a clinic
in Tsilitwa and a hospital in Sulenkama. This connection helps the nurse and doctor to
communicate using GSM phones and send webcam video to support remote diagnosis of
patients. This infrastructure is vulnerable to several problems at the moment, the most
important being power failure and frustration with the video quality that comes from the

This project seeks to address these problems by adopting a community centered approach to
bridge the digital divide where the users will be involved from the first stage until the last
stage of development. We believe that by following this approach we can deliver a system
that addresses the problems that are currently in place. The approach that we would like to
follow is an iterative community centered approach where we develop prototypes for the
user and show them at each stage. This will allow us to develop interfaces as the users would
really wish us to. This means that there will be improvement in prototypes at each stage
according to the need and conditions as specified by the target community to ensure that
what we deploy at the end of the day is acceptable and comfortable for the users.

This means that we would like to provide both synchronous as well as asynchronous
communication modes for the user. When the power is up, the users can continue
communicating in a synchronous fashion. As soon as the power goes down, the users can
now communicate in an asynchronous fashion. Through this approach we would like to
produce interfaces that are tolerant to the rural conditions as mentioned above by giving two
types of communication modes.

This project seeks to improve the current system, MuTi, by Marshini Chetty [24] from UCT.
MuTi currently uses a store and forward communication approach. This means that when
the power is up the users can communicate in a normal way but as soon as the power and
the network are down, the communication becomes a store and forward where the
communication data will be stored and sent later on as soon as the power and the network
come up again. The system currently supports voice, text and images as modalities. This
project therefore looks at porting the current system and run it on top of the Softbridge, a
server by John Lewis [25] from UCT.

We also want to therefore explore adding video to the current MuTi system. We want to
bring handheld devices like PDAs and Laptops because these devices can use a battery when
the power is down. This will enable the users to communicate even if the power is down.

                                         2. TITLE

Internet Protocol Based Multimodal Communication Services in South Africa
                                      3. KEYWORDS

Digital divide, Java Media Framework, Jain SIP, Java Messaging Service, HCI, MuTi,

                              4. RESEARCH QUESTIONS

As we are interested in the use and provision of ICT applications in developing countries,
we have a number of research questions that we are addressing relating to this study. We
have questions that relate to the users, environment as well as the acceptability of the
application itself as it will be used by the users. In summary we can put the research
questions as follows

       How do we further technically develop the MuTi system in such a way that it
        becomes user friendly to the doctors and nurses in Tsilitwa and Sulenkama
       How do we support and encourage doctors and nurses in the Tsilitwa and
        Sulenkama communities so that they use the MuTi system?

                         5. RATIONALE FOR THE PROJECT

The primary aim of this project is to develop a multimodal communication application that
can be appropriate as well as used in a rural environment using VoIP technology. This
proposed application will be developed mainly from the needs of the particular target
community. To ensure that this is done, we will involve the user in every stage of the
development to make sure that at the end of the day the application is relevant to the target

The other aspect that the project looks at is to show that user involvement in software
development using an iterative approach can produce systems that are locally relevant to the
target community. The project also wishes to show that the most important thing in
developing software is involving the user and understanding the real needs and problems of
the user. Again we would like to show that innovative technologies are really appropriate for
rural type of environment while developing systems. This will be done by making use of
these technologies throughout the development of the project.

The last important aspect that the project looks at is making sure that the technologies that
we deliver for rural environments can cope with conditions in the target areas. In this case
the main problem is the power failure and bandwidth which means that the users cannot
communicate at all if it happens or will have poor communication. The project looks at
investigating and deploying a system that will overcome these difficulties by also on the
other hand introducing handheld devices and laptops.
                             6. SCOPE OF THE PROJECT

This project builds on previous projects aimed at developing an application that will be
helpful in improving the health care of people in developing countries and most importantly
provide communication among these people in order to bridge the digital divide. We assume
for now that the developed application is for rural environments because this is where our
focus is. The project goes on and on in building and evaluating as well as testing up to
deploying this system to see if it meets the specifications as expected. The project will work
towards maintenance and sustainability but the project is not ultimately responsible for
maintenance. We hope someone like the government can intervene in this regard.

                                     7. HYPOTHESIS

User involvement in an iterative fashion (iterative participatory design) will lead to the
development of a communication system that is user friendly to the target users. It will also
lead to the development of a communication system that best meets their needs as well as a
system that is mostly relevant to the type of an environment they live and work on. This will
therefore lead to the users liking as well as believing in the system as a tool to help them
solve their communication problems.
                                    8. RELATED WORK

 The India healthcare project [1] is one example that shows how the use of ICT can help in
improving the lives of people in rural areas of developing countries. In this example, nurses
are using handheld devices to collect data about patients in rural India. This shows how this
method can help in reducing time taken while doing this job compared to when using a
book. This example in general shows how helpful it is to use ICT in these types of problems.
The nurses here use handhelds to store patient data and this data can be easily integrated to
the government and the government can easily see how many people need health care and
how many people are already receiving healthcare. This then helps the government to speed
up delivery as well as have an idea as to how far they are with the process of health care

 Designing a Graphical User Interface for Healthcare Workers in Rural India [2] shows us
how helpful it is to involve the users in the process of user interface design. In this case the
interface is designed for the project specified in [1]. This shows us the strategies of taking the
current situation, data in books in this case, and designing an electronic storage form for that
situation. What is more important here is that the specification for this interface comes from
the users of the system, which I think is very vital.

A cost effective kit for developing countries [5] is a thesis by Ari Tadler who was a
mechanical engineering student. He developed a kit that uses wireless networks. This kit can
be used anywhere to provide health care in developing countries.
SIP Communicator [6] is an application that is used for videoconferencing. This application
uses JAIN SIP and JMF and is purely in java. This application was developed by the network
research team at Louis Pasteur University.

OOPS Isee [4] is a low bandwidth (~20kbps) videoconferencing application that was
developed by an Indian engineer. This application is used for a variety of things, amongst
them, telehealth.

Cash project [7] is a handheld based electronic medical record (EMR) in operation in
Ballabhgarh, India. This system is primarily intended for use in rural areas to serve in the
areas of parental care and child health.

The Handy Valid Initiative [8] uses PDAs to collect information from villagers using a pre-
designed consultation form. This information is then transferred to a doctor in the city, who
diagnoses the problem and suggests appropriate treatment, precautions, and medication. The
doctor's diagnosis and suggested treatment is then once again transferred to the PDA and
carried back to the villager.

The Videophone Telemedicine Project [9] in Indonesia uses low-cost videophone equipment
to enable local doctors to consult with specialists in major hospitals over conventional
telephone lines

The Vovixa Health Alert and Reporting System [10] use the phone network to integrate
remote health centers into the national disease reporting network.
TelmedPak [11]is using high-speed rich-data transfers to provide rural hospitals in Pakistan
with access to healthcare teleconsultations with specialists from hospitals located in larger,
more developed cities.

In Senegal, Pesinet [12] weighs babies and transmits the results to remote health providers
via e-mail. Doctors compare the infants' actual weights to the target weights for their ages to
determine whether they need to come in to be examined.

The Aravind Eyecare System [13] is helping to eradicate blindness by using Internet-
connected kiosks to provide video consultations and diagnosis, as well as extensive
education and training, to local healthcare providers.

Remote HealthCare Surveillance [14] is a project that uses PDAs and GPS in the collection
as well as the analysis of health data in Brazil.

Warana: The case of an Indian Rural Community adopting ICT [3] shows how ICT can be
used as an effective tool for rural development. The ICT here is used to streamline the
operations connected with sugar cane growing and harvesting. It is shown in this project that
the use of ICT saves time and benefits on transparency. Of most importance here again is
that they show lessons that they learnt. They learnt that before embarking on an ICT project,
the information needs of a community should be assessed. When developing ICT, it is
important to involve the users and get feedback from them every time.

The satellite project [28] shows how Personal Digital Assistants (PDAs) can be used to
enhance medical care in rural areas. These PDAs were used to gather health data about
patients to enable easy sharing and dissemination by the doctors.

                               8.1 LITERATURE REVIEW

This literature review concentrates mainly on two aspects of the research. The first aspect of
the research looks at the methodology itself i.e. iterative software development. The second
section concentrates on the importance of user involvement in software development


Hunger [15] describes an iterative software development process as a process that executes
all the stages more than once compared to the waterfall model. He mentions that the
iterative life cycle is based on successive enlargements and refinements of a system through
multiple developments life cycles of analysis, design, implementation and testing. He also
mentions that the system grows by adding new functions within each development cycle.
Hunger also mentions the advantages of an iterative process as follows:

 The complexity is never overwhelming
 Early feedback is generated because implementation occurs rapidly for a small subset of
  the system.
Matrais [16] lists the advantages of an iterative software development life cycle as follows:
    Tolerates changing requirements.
    Elements are added as the process of development goes on.
    It tolerates tactical changes in software.
    It facilitates Reuse in software.
    It results in a more robust structure because there is correction over several
    The process itself can be improved and refined along the way.

 Walton [17] compares an iterative development process to the waterfall process and argues
that software developers have a tendency to use the words design/development to have
different meanings depending on context, and that has confused the software developers’
thinking. He mentions that in the product life cycle, design/development refers to the set of
activities that occur before a product design is released to manufacturing. He goes on to say
that software developers have used the same words to represent measures of progress within
the design/development phase of the software development life cycle for internal software.
He goes on to mention that this has led to both customers and software people, into an
expectation that software development should be the same as hardware manufacturing. He
says that this is an invalid expectation. Walton also mentions a few points on why iterative
software development life cycle makes sense compared to internal software development
process. The points are as follows:

      Design/development phase activities in hardware domains are managed using an
         iterative, incremental approach.
      Software development is entirely a design/development phase activity.
      The ability to turn a software design into working software simply by compiling and
         linking it significantly reduces the costs of iteration.
Walton then makes a conclusion on the points above that an iterative approach should be
used more instead of hardware development efforts, given similar levels of innovation
embodied in the product or project.
Gaut [18] defines iterative development as a technique for developing software that reduces
risk by breaking a large body of work into smaller, more manageable units of work. He says
that iterative development fully embraces the notion that software development tends to be
an organic process, subject to constant change and evaluation throughout the project
lifecycle. He mentions that iterative process acknowledges that change will be constant and
that change to software system design, if effectively managed, is positive. He also mentions
that the iterative process provides the opportunities for full stakeholder involvement and
continuous feedback with the development team. Lastly he describes iteration as a mini
project itself with well defined start and end points and specific objectives to achieve.


Hilbert, Robbins and Redmiles [19] support the view that users should be involved in the
iterative software development process. They say that this is because user involvement
increases the likelihood that the system will be useful, meet the requirements as well as
usable. They say that this is because the users can always have input into the systems design.
They mention that users become their own system designers indirectly which makes it easy
for them to find the system more useful and usable to the users at the end of the day. Lazar,
Ratner, Jacko and Sears [20] also support this view and they mention that user involvement
is much more important where numerous usability challenges exist. They make an example
here by mentioning the Web Development Process. They argue that user involvement in the
development process is necessary to ensure that the website meets both the functionality and
the usability needs of the users. They also mention that when users are not involved at any
stages of website development, this has proven to be problematic, since there is no way of
determining that the website will meet the functionality and usability needs of the users.

Chang [21] also supports the view of user involvement in the software development process
and he says that user involvement has always been considered an important contributor to
the success of information systems. He say that literature on user involvement maintains that
for a system to be successful, users need to be involved in the initiation, requirements
definition, design and implementation stages of system development. He then mentions a lot
of literature that supports his views on user involvement. Al-Ghobiri and Mayhew [22] say
that many projects fail in developing countries because during the project development
process, more emphasis is placed on hard issues while soft issues such as cultural, political
and user involvement aspects have been less emphasized. They also say that efforts have to
be made to encourage real user involvement rather than merely observers. They say that the
research that they carried out to see what the important factors are while developing an
information system has shown them that user involvement should always be the first priority
while developing systems. This is highly the case in developing countries where there are a
variety of differences in beliefs, culture and language. Ignoring these factors in systems
development will lead into a useless system that is not acceptable or usable.

Terry and Standing [23] put a different view on the issue of user involvement. They say that
even if the users are involved in the systems development process, communication is a key
thing that will make sure that at the end the system is useful and acceptable. They say that
lack of communication between the users and the developers has become a common theme
in the well-documented reasons of information systems failure. They say that user
involvement is likely to result in increased user satisfaction and the perceived usefulness of
the system.
                          9. RESEARCH METHODOLOGY

This research will adopt an iterative participatory prototyping methodology [26] in a
community centered manner. This methodology will be used for developing the system. This
of course will be done with the target community involved throughout all the stages of
development. The other methodology that will be used is Outcomes Mapping [27]. This
methodology will be used to evaluate the impact of the project to prove or disprove the
hypothesis. The specific steps in the development methodology are as follows. The
development methodology is also shown in the development methodology flowchart in the
next page.

      Establish the user requirements – this is to make sure that we know what is expected
       out of the prototype. This will involve various forms of interaction like interviewing
       the people or users in the community and understanding their needs as well. This
       will then give rise to the requirements gathering process which will then give
       direction in prototype development.
      Develop the prototype – this stage will involve taking the user requirements into
       some sort of a picture i.e. first prototype design. This is then followed by the
       implementation of the prototype according to the specifications collected from the
       first stage.
      Evaluate and test the prototype – This involves going to the target users or
       community and showing them the prototype. They will then have to say their views
       about the prototype. They can either criticize the prototype or say the prototype is
       fine. This will then give rise to new requirements being gathered that will then give
       rise to a new prototype.
      Modify the prototype with respect to the new specifications – This stage basically
       involves taking the new requirements specification and adding those to the current
       prototype. This is to make sure that at the end of the day we deliver a system that is
       both usable and acceptable to the target community.
      Repeat evaluation with users until the prototype meets the requirements – This
       means that as we develop the prototype, we have to show the users until the users
       and ourselves are both satisfied that the prototype meets the requirements and needs
       of the target community. This is where iteration occurs.
      Deploy the prototype – Deploy the prototype in a user environment and possibly
       observe its performance.

              Collect user requirements
              from the community

              Develop prototype according to
              the user specifications

            Test prototype with the target community
            or users to see if it is satisfactory or not
            (collect new specifications)

                       Satisfactory (meets all

                 Deploy prototype in the
                         9.2 EVALUATION METHODOLOGY

The evaluation methodology that will be used as explained previously will be Outcomes
Mapping. This methodology will help us observe or pick up changes in the behaviors of the
target user(s) of the envisaged system. We would like to monitor the changes in their
behaviors because what we would like to see is the system being used on regular basis. This
will make the users very happy as it will also make the patients happy because they will then
be able to get diagnosis from the doctor. We therefore feel that the most important thing to
monitor or evaluate is the use of certain features in the system to see how the users use the
system. We will use system logging to collect metrics about system usage to tell us which
feature was use, how many times it was used and for what purpose it was used. The other
way is to use questionnaires to get the information from the users themselves. The last thing
to do will then be to compare both qualitative and quantitative data to see if there are really
any changes or impact as expected. This will then help to prove or disprove the hypothesis.

                              10. EXPECTED OUTCOMES

A number of things are expected to fall out of the project. The project mainly produces
software that will be used in a rural environment. The software that will come out is
software that must meet the needs of the target community in such a way that they get value
out of it. The other thing that is expected out of the software is that it must be tolerant to
conditions in a rural setting where the software will be deployed.

Apart from producing the software, we wish to publish our results so that other people who
are also interested in doing the same thing can have a basis of improving or criticizing this
kind of work that we have produced. Since this project is also part of IDRC initiative to
produce locally relevant applications, we are going to have a chapter in the IDRC book that
is about projects of this nature.

Another important thing that will fall out of this study is the guidelines on how to conduct
these kinds of studies in rural South Africa. We hope to contribute these guidelines to other
computer scientists so that they can also follow this approach once it has proven to be
helpful or useful.

                Duration                                     Task

1 February – 1 March, 2004                    General research (learn the related
                                               knowledge and technology),
                                               Information Collection. Visit Eastern
                                               Cape for user requirements.
6 March – 31 April, 2004                      Develop the research proposal.
May, 2003                                     Start Prototype design
1 June, 2004 – 14 June, 2004                  Go Home and see family
15 June – 30 August, 2004                     Implement the Prototype
1 September – 30 September, 2004              Implement the Prototype
1 October, 2004 – 5 October 2004              Field Testing with the Eastern Cape
                                               Community and more user
                                               requirements gathering.
7 October - 7 November, 2004                  Prototype refinement according to the
                                               new requirements
9 November – 13 November, 2004                More field trials with prototype and
                                               results gathering
15 November 2004 – 23 December 2004           Evaluate the results at hand and try to
                                               answer the research question.
24 December 2003 – 5 January 2005             Go home and have a break
6 January 2005 – 6 February 2005              First Draft Thesis Write-Up
7 February 2005 – 11 February 2005            Field trials in Eastern Cape
13 February 2005 – 2 April 2005               More work on the prototype according
                                               to the new specifications + more
                                               concentration on the user interface
3 April 2005 – 3 May 2005                     More Field trials and requirements
                                               gathering in Eastern Cape
4 May 2005 – 10 June 2005                     Have a little break
11 June 2005 – 11 July 2005                   Working prototype with new specs +
                                          concentration on the user interface
13 July 2005 – 25 July 2005              Modify Thesis if necessary
27 July – 30 July 2005                   Visit Eastern Cape with prototype +
                                          requirements gathering
August 2005                              More work on the prototype to meet
                                          the new specs if necessary.
1 September 2005 – 9 September 2005      Thesis Modification
10 September 2005                        Birthday(no work to be done)
11 September 2005 – 15 October           Deploy prototype testing with more
                                          emphasis on softbridge communication
                                          + error fixing
16 October 2005 – 23 October 2005        Deploy Full prototype in Eastern Cape
                                          with users.
25 October 2003 – 30 November 2005       Final Thesis write-up
1 December 2005                          Submit Thesis

[1] Sastry, C. L. R. (2003). "India Health Care Project: An application of IT in rural health
care at grass root level." 13(1).
[2] Sally Grisedale, M. G., Alexander Grünsteidl, (1997). "Designing a Graphical User
Interface for Healthcare Workers in Rural India."
[3] Simone Cecchini, M. R. (2002). "Warana: The Case of an Indian Rural Community
Adopting ICT." 12(1).
[4] Chennai, S. W. i. (2003). "Low Bandwidth Videoconferencing in India”.
[5] Adler, A. T. (2000). "A cost effective Telemedicine Kit for use in developing countries."
[6] Team, N. R. "SIP Communicator."
[7] Vishwanath Anantraman, T. M., Reshma Khilnani, Vikram S Kumar, N Rao Machiraju,
Alex Pentland,Lucila Ohno-Machado (2000). "Handheld Computers for rural HelathCare,
experiences in a large scale implementation."
[8] JivaInstitute "Teledoc: Sustainable HealthCare for Rural India."
[9] Hirofumi Sugiyama, G. S. (1999). "Videophone Tele-medicine Project in Indonesia." Main
[10] Vovixa "Voxiva Health Alert and Reporting System."
[11] TelmedPak "TelmedPak Telemedicine."
[12] Pesinet "Pesinet."
[13] Aravind "The Aravind Eye Care System."
[14] Gustavo Sato Dos Santos, I. C. G., Carlos Gomez-Uribe, Lucila Ohno-Machado (2002).
"Remote HealthCare Surveillance: A case study using PDAs and GPS."
[15] Hunger, M. (2002). "Iterative, Incremental Development." http://emw.inf.tu-
[16] MITRAIS, P. "Why use the Unified Process?"
[17] Walton, B. (2004). "Iterative vs. waterfall software development: Why don't companies
get it?",4814,90325,00.html
[18] Gaut, R. E. "Iterative process development."
[19] David Hilbert, J. R., David Redmiles (1997). "Supporting ongoing users involvement in
development via expectation driven event monitoring."
[20] Jonathan Lazar, J. R., Julie Jacko, Andrew Sears "User Involvement in Web
Development Processes."
[21] Chang, J. C. J. "Business Environment, User Involvement, and Information System
[22] Mohammed Al-Ghobiri, P. M. "Factors Affecting System Usability in a Developing
[23] Julian Terry, C. S. (2004). "The Value of User Participation in E-commerce Systems
Development." Informing Science 7.
[24] M Chetty, W. Tucker, E. Blake (2003). "Using Voice over IP to Bridge the Digital
Divide- A Critical Action Research Approach."
[25] John Lewis, E. Blake (2003). "A multimodal Instant Messaging System using XML-
Based Protocols."
[26] Randy Trigg, Andrew Clement. (2000). "Participatory Design."
[27] Sarah Earl, Fred Carden., Terry Smutylo. "Outcome Mapping: building learning and
reflection into development programs." pp 1-15, 2001, International Development Research
Center, Ottawa, Canada
[28] Nelson Sewakambo, R. R. (2003). "The Healthnet Uganda - Satellite Handheld
Computer Project."

Shared By: