Experiences with Extreme Programming in Telehealth

Download PDF
1 downloads 0 Views 406KB Size Report
Comment
Ann Fruhling, Kimberly Tyser, Gert-Jan de Vreede. University of Nebraska ...... [6] T.C. Ricketts, Rural Health in the United States, Oxford. University Press, 1999.
Experiences with Extreme Programming in Telehealth: Developing and Implementing a Biosecurity Health Care Application Ann Fruhling, Kimberly Tyser, Gert-Jan de Vreede University of Nebraska at Omaha College of Information Science & Technology [email protected], [email protected], [email protected] Abstract There has been limited research on how nonconventional system development methodologies such as, Agile modeling methods could improve the successful development and implementation of telehealth services. The goal of this research was to increase the understanding of the impact of using the Extreme Programming process, an Agile modeling approach, to the development effort of a biosecurity telehealth project. Overall, the research indicates that Extreme Programming is an effective methodology to develop health care applications. The rapid prototyping enabled IT developers and health care users to clarify system requirements, communicate openly, and quickly build rapport. Further, the research found that that where the technology was new or foreign, the Extreme Programming process was flexible enough to support several iterations of technology and produce prototypes in a timely manner.

1. Introduction Recently, it has become evident that terrorist organizations have acquired the technology and the reagents for launching an attack using biological agents. Health laboratories throughout the US need to be prepared to encounter situations that may be due to intentional or unintentional exposure to certain organisms such as the plague or anthrax bacillus. A possible scenario is that a health laboratory will notice the unusual occurrence of rarely seen infectious disease such as tularemia [1]. The rapid movement of the West Nile virus in the US underscores the ease with which emerging infectious pathogens can move into new geographical areas. In 2003, the Nebraska Health and Human Services System reported 2,204 confirmed/probable human cases and twenty deaths in Nebraska. Mechanisms for chemicalinduced, radiological-induced, or infectious air-borne and water-borne diseases, affecting humans, animals and agriculture are serious ongoing health, environmental, and economic concerns. Health care is the largest information business in the US economy. However, as an information industry, health care is complex and inefficient [2] and lags behind

other industries in adopting information technology [3], [4]. Though this trend is poised to change, there still are many barriers to overcome. One of the most important challenges is to develop quality telehealth services for remote populations that meet rural health providers’ needs and at a cost that is affordable. Telehealth is defined as the use of advanced telecommunication technologies to exchange health information and provide health care services across geographic, time, social, and cultural barriers [5]. The development and implementation of public telehealth services is still limited, especially for rural communities [6]. The success of a telehealth application is dependent on the end-users, in this case the health care professionals, thus their early ownership of and dedication to a health care application development project is critical to the long-term acceptance and sustainability of the system. Health care organizations, especially rural, have limited resources. High system development overhead makes the development and implementation of some rural telehealth projects almost impossible [6]. A key challenge in establishing successful telehealth partnerships with rural communities is keeping ruralbased physicians and providers connected to the main academic medical center [7] which has propelled the movement towards distributed health care applications and the increased emphasis on telehealth applications using leading edge telecommunication technologies. A number of research studies indicated that the lack of health care users’ involvement was a leading cause of system failure [8]. And, if the users are involved, then there was a good chance that they didn’t know what technology was available and therefore, couldn’t fully articulate how an application might work, causing unclear, incomplete, and changing requirements. Another issue is the health care culture. Often the target populations in most information technology acceptance studies are MBA students or middle managers, not health care professionals. Health care professionals, especially physicians, enjoy authority and prestige in their environment. Telehealth systems, sometimes, are seen as a threat to health care professionals’ expertise [9]. Another key reason that telehealth system implementations have failed in the past was the lack of physicians’ adoption of the new technology [10]. Perceived usefulness of telemedicine has been proven to

have a strong impact on physicians’ intention to adopt the new technology. This makes it even more critical for system developers to do the necessary work to enhance physicians’ perception of telehealth usefulness [11]. There has been limited research on how nonconventional system development methodologies (i.e. Agile methods) could impact the successful implementation of telehealth services. This research attempts to fill this void by applying an Agile modeling methodology (i.e. extreme programming), to the development effort of a telehealth project and evaluating the process. In addition, this research presents insights for academics and IT practitioners on how telehealth applications can more successfully be developed and deployed in a cost effective and efficient manner and how the health care user can be more involved. The paper begins with a literature review of three distinct software engineering models. Next, the research method is presented, followed by a brief description of the telehealth application applied in this research. Next, the development and deployment process of the telehealth application is examined. Lastly, the paper concludes with a discussion of the results and key insights.

2. Software Engineering Methods 2.1 Traditional methods Software engineering addresses all aspects of software production from the early stages of systems specification to maintaining the system after it is deployed [12]. The waterfall methodology [13], shown in Figure 1, was one of the first structured software development methodologies introduced.

project to the next step. The model also allows for feedback and error correction. Subsequent steps may reveal problems with the previous steps necessitating some rework. The first step is system analysis where the system’s requirements are specified and goals are determined from business processes. The next step is system design. This is when the overall architecture is established including hardware and software systems. The third step is coding. Requirements from the system design are transformed into computer readable code. Next, the system’s software is tested for efficiency and effectiveness in the testing step. Lastly, in the implementation and maintenance step, the system software is deployed. Maintenance involves error correction and improvements to the system. Still today, the waterfall method is largely used in practice because of its simplistic nature. The problem with the model is that it requires commitment from the user early in the development stages and is inflexible when requirements are altered. Often, it is a long process. It is not unusual for some system development projects to take multiple years before a functional prototype is complete [12]. To address some of the waterfall method shortcomings (i.e. inflexibility and long development time), the spiral model [14] was proposed. In the spiral model, shown in Figure 2, each loop represents a phase in the development process. The entire spiral process will include several iterations of software prototypes; however, there are no defined phases. Instead, the spiral model is divided into four sections that are performed for each new iteration.

System Analysis System Design

Coding

Testing Implementation and Maintenance

Figure 1 Waterfall Method This model is based on a linear approach of the steps needed to define functions that must be completed before proceeding to the next step. The waterfall model requires users to decide upon a set of requirements prior to beginning software engineering. The completion of each step provides documentation that is approved by the user. Approval of the documentation allows continuation of the

Figure 2 Spiral Method In the first section, objective setting, system objectives, alternatives, and constraints are determined and a detailed management plan is created for development. Risks of the project are identified and addressed including alternatives based on risks.

The next section, risk assessment, identifies risks and the appropriate risk prevention steps are taken. Examples include prototyping, simulation, and benchmarking. Next, in the development and verification section, risks identified in the risk assessment phase, aid in determining which development model to use. For example, if business workflow is of concern, a simulated system may be appropriate. In the planning phase, a decision is made as to whether the project will continue on to another loop of the spiral in which case, the four sections will repeat and plans are created for the next phase. The spiral model is an improvement over the waterfall model because it allows more flexibility for changing requirements since the process is not locked and each loop of the model allows for changes to be made to the previous prototype. In addition, the spiral model includes a risk assessment at each new loop or prototype. Not assessing the risk of a project can lead to increased cost and schedule overrun [15]. The spiral model has been a relatively good model for software development, but there is a need for some clarity within the model such as more clearly defining longerterm objectives and plans [16]. These objectives need to be carried from one cycle to the next and integrated with the shorter-term objectives and plans. The model also needs to include hierarchical relationships for spirals within spirals [16].

approach is to devise a detailed plan for a two-week period and a general plan for a three month time period. One of the more prominent processes that adhere to the principles of Agile software development is extreme programming.

2.3 Extreme Programming The extreme programming approach [17], [18] shown in Figure 3, operates on iterative development, working in frequent consultation with the customer, and having small and frequent releases. Gather/Adjust User Stories

Write Unit Tests

Fail Interim or Full Release

Final Delivery

Assign Programming Pairs Parallel

Acceptance Testing

Code

Documentation

2.2 Agile Software Development Continued dissatisfaction with the available development methods led to the introduction of various Agile approaches (i.e. extreme programming [17], [18], Scrum [19], Crystal [20], etc. ) based on the principles outlined in the The Agile Manifesto [21]. The Agile approach focuses on four key ideas [22]. 1. Individuals and interactions over processes and tools, argues that often there is too much emphasis placed on coding knowledge and development tools. Instead, team members and their communication with each other should carry a much larger role in the successful completion of a project. 2. Working software over comprehensive documentation, states that while software documentation is an important piece of development; the more effective tool is the code itself and training through human interaction. 3. Customer collaboration over contract negotiation is based on the critical premise that successful software development requires frequent communication between the user and the developer. 4. Responding to change over following a plan, addresses the problem that oftentimes; long-term plans created for projects do not easily allow for changes; whereas, short-term plans provide more flexibility in responding to change. Therefore, a more effective

Figure 3. Extreme Programming Method First, user stories are gathered, representing system requirements. Then, users and developers determine which requirements will be developed in the next iteration. Next, test plans are written prior to coding. Unit tests and coding are done in parallel corresponding to a particular unit of system development. Programming pairs are assigned to specific tasks. As a unit of the system is developed, the user performs an acceptance test. If the acceptance test fails, the user and developer will meet again to adjust the user stories and the process will repeat. A passing acceptance test will continue on to an interim release for individual units or a full release for a complete system. Following the release, documentation is completed and a final delivery of the system is made to the end-user. Table 1 presents nine key practices of extreme programming. Research indicates that following these practices leads to several advantages over traditional software engineering methods.

Table 1 – Nine Key Practices [18], [23], [24] Practice Small Releases Simple Design Testing

Refactoring

Pair Programming Collective Ownership Continuous Integration 40-hour week On-siteCustomer

Practice Overview Frequent releases of unit development provide feedback for future iterations and releases. Simple and small pieces of design allow frequent changes to be made as necessary. Writing and running unit tests as code is written to make sure the system is working properly. Frequent user acceptance tests to ensure the system is fulfilling user requirements. A technique used to improve code without altering functionality. Focuses on simple, clean, non-repeating code that can be easily changed. Two programmers developing production code at the same time on one machine. Everyone owns all of the code allowing necessary changes to be made by anyone at any time. Integrating changes as they are complete to detect system failures as soon as possible. Developers keep a normal work schedule to remain productive, and interested in the project. An on-site customer available for requirements clarification and business decisions that should not be made by the developer

2.3.1 Advantages of Extreme Programming. The extreme programming process affords many benefits. Extreme programming enables software development to cater to today’s fast paced business and technological environment by allowing organizations to deliver and change requirements quickly during the software engineering process. Advantages of extreme programming over conventional practices include lower management overhead, higher team productivity, happier customers and shorter release cycles [23]. Small releases and the continuous design process allows for frequent review of the system by the developers and the users [26]. This constant and quick feedback helps identify errors, supports ongoing usability tests [27], [28], and builds trust between the user and the developer. The simple design approach enables frequent changes to be made to the system easily and encourages design experimentation. The implementation of an automated testing method in which unit tests are developed before actual code is written, has shown to increase confidence in functional and system reliability [29], [30]. Refactoring helps developers respond quickly to changing requirements [30]. Refactoring is a technique used to improve code without altering functionality and

its goal is to produce programming units with a strong internal structure. These programming units are generally more reusable, object-oriented, pattern oriented, maintainable, and simplier [30]. There is ongoing debate on the cost/benefit value of pair programming. However, empirical research has found that pair programming produces higher quality code at a lower cost [29]. In pair programming, tasks are completed by a pair of developers using one computer for coding. Pair programming allows developers to share ideas immediately, enabling them to come to conclusions quickly and detect defects early [31]. Further, it is argued that the increase in cost of development using extreme programming is offset by productivity gains (e.g. a pair of programmers has a higher development speed than a single programmer) and increased quality of the code through the continuous checking of the code against test cases and by the second programmer [32], [33]. Extreme programming maintains group ownership where everyone owns all the code and coding changes are made by anyone at any time. Close team interaction, shared goals and limited time invested in elaborate designs provide for an environment where there is less defensiveness and territoriality [34]. Lastly, developers often have a high sense of accomplishment from the fast release pace. 2.3.2 Disadvantages of Extreme Programming. Extreme programming has some drawbacks such as project size and type constraints. Agile methods, such as extreme programming, can be difficult to scale up to large projects because of a lack of sufficient architecture planning and over-focusing on early results [35]. Therefore, extreme programming is more useful in small to medium scale projects [23]. In some cases, the use of pair programming doubles the cost of development personnel and the test-drive approach adds to the development effort in that it requires extra effort to continuously adapt and run test cases causing the task completions to be delayed [31]. Additionally, the fact that extreme programming does not maintain specific requirements from the start of development makes it difficult to guarantee the customer’s needs are actually satisfied [31]. Many managers view extreme programming as dangerous and unpredictable because to them it appears to neglect planning and controlling in large-scale or previous projects [36]. Other noted disadvantages are the requirement of only employing experienced developers, insisting on on-site access to users, and the lack of documentation. A summary of the advantages and disadvantages are shown in Table 2.

Table 2 Summary Advantages and Disadvantages Extreme Programming Advantages Quick prototype production Iterative process Frequent feedback from user Encourage design experimentation Increased system reliability Refactoring High code production Quality code Team ownership of code Cohesive developer environment Flexibility Lower overhead More effective on small to medium size projects

Disadvantages Scalability Issues Over focusing on early results Pair programming not cost effective “Test-drive” approach adds development time Lack of specific requirements to ensure user satisfaction Unstructured Unpredictable Neglected Planning Required experienced developers Access to committed users Lack of documentation Higher overhead Not effective on large projects

3. Method The aim of this research was to evaluate the extreme programming method in practice, to make adjustments where needed for each iteration and to reflect on those adjustments, therefore, action research was considered the most suitable research methodology. Action research, a qualitative approach, allows researchers to gain a rich understanding of people and the context in which they live and work [37]. [37] identifies four approaches to qualitative enquiry: action research, case study, ethnography, and grounded theory. Below we will explain further this point in more detail and highlight the collection and analysis of our data. We also discuss the role of the researchers in this study.

3.1 Action research Action research has the dual intention of improving the practice and contributing to theory and knowledge [38], [39]. We followed the model proposed by [40] (Figure 4) that states that an action research study may consist of four activities that can be carried out over several iterations. ‘Plan’ concerns exploration of the research site and the preparation of the intervention. ‘Act’ refers to the actual intervention made by the researcher. ‘Observe’ concerns the collection of data during and after the actual intervention to enable evaluation. Finally, the ‘Reflect’ activity analyses the collected data and infers conclusions that may feed into the ‘Plan’ activity of a new iteration.

Action research was selected as our research approach for several reasons. First, action research is especially appropriate to address ‘how to’ research questions. Our research aimed to explore and develop ways in which

plan

reflect

act

observe

Figure 4 Action research model [40] health care development projects could benefit from using extreme programming development approach. Second, the continuous design and evaluation of a software engineering process was considered too complex to be studied in a constructed setting. Third, action research is very well suited for continuous learning. It allows researchers to continuously evaluate and improve their problem solving techniques or theories during a series of interventions. In our research, we produced several iterations of the STATPack™ prototype. The experiences from each prototype resulted in changes to the extreme programming processes that were effectuated immediately. Finally, as far as we knew at the initiation of the project, very little research had been conducted on the use of extreme programming in the telehealth application development environment.

3.2 Data sources and analysis We collected data from both quantitative and qualitative sources: - Direct observation. The researchers notes of incidents, participants’ remarks, and events that conveyed critical information. - Interviews. The researchers held by-weekly status meetings with the project team that provided an open forum to discuss what was going well on the project and where adjustments were needed. - Usability Evaluation. After the release of three key prototypes at different points in time, full-system usability evaluation was done. - System documentation. Test plans and release notes were stored electronically for each prototype. - Timeline. A timeline of the prototype iterations was documented.

User scenarios, release notes, prototype requirements, meeting minutes were kept in an online blackboard for all team members to share. All team members, developers and users, contributed to the online blackboard. The variety of data sources gave a rich representation and enabled comparison and contrast of the collected data. Given the exploratory nature of the study, we analyzed the development process of the system at each iteration, monitored the feedback from the user, and reviewed the test plans and outcomes in which we identified areas of improvement and refinement. In particular, we investigated user satisfaction through usability testing, project team satisfaction through informal one on one meetings with the project manager, and made note of critical insights on the process and quality of the extreme programming method.

3.3 Role of the researcher The role of the researchers was that of observer and participant at the same time. Researcher participation was twofold. First, one of the researchers also served as the project manager. This included assigning development tasks, coordinating meetings, budget oversight, and technical guidance. The other researcher assisted in the usability testing.

Figure 5 STATPack™ Hardware These images along with descriptive text messages can be sent to the NPHL for consultation as shown in Figure 6. Should a serious situation need to be communicated to the laboratories, the STATPack™ system enables NPHL to send notices to each lab including an audible computer alarm. It was critical that the STATPack™ provide an easy to learn and use interface for rural health laboratorians and the NPHL staff.

4. STATPack™ Project 4.1 STATPack™ Application Purpose The Secure Telecommunications Application Terminal Package, STATPack™ project is an effort to address critical health communication and biosecurity needs in Nebraska [41]. The STATPack™ application is a secure, dedicated, HIPPA compliant, web-based network system that supports telecommunication connectivity of clinical health laboratories in Nebraska to the Nebraska Public Health Lab (NPHL). The system architecture uses client/server technology and operates in a distributed environment connecting regional and rural health laboratories. This connectivity allows for immediate communication and data transfer of urgent health information by transmitting images and text. For example, when a rural laboratory is processing a "suspicious" organism growing from a culture, the STATPack™, serves as a means for providing immediate consultation with the NPHL. Currently, the STATPack™ has been deployed to six Nebraska health laboratories. Both the hardware and software were engineered for this project. The STATPack™ system consists of a computer terminal which includes a flat screen, a minivirtually indestructible keyboard that can be sanitized, speakers and a high-resolution digital camera that can capture images of culture plates as depicted in Figure 5.

Figure 6 STATPack™ Image Capture The STATPack™ project had several challenges. One of the most difficult challenges was that the STATPack application was a brainstorm idea of one of the senior users. There was no existing system to evaluate or reengineer. This required that the developers and the users have good communication on what system functions were envisioned and how they might work. Because the STATPack™ has the potential of being placed in 86 health laboratories across Nebraska it was necessary for the STATPack™ application work in a distributed environment. As is the case in most health care organizations with rising costs, there are minimal funds to purchase the hardware and software, so system development overhead was a concern.

In addition, developers were truly working in a R&D environment (i.e. researching and evaluating various open source and hardware technologies) which created an unstable technical environment. Another issue of the STATPack™ project was the requirement of developing a scalable system that supported rural health laboratories. The telecommunications infrastructure and information technology experts in most rural communities are minimal, so the requirements of the telecommunications infrastructure were unclear and sometimes unknown. Other barriers included unfamiliar terminology and different cultures. Often times, jargon from both disciplines caused some confusion. Also, the organizational culture of the medical field and information technology fields are very different. They each have their own priorities, hierarchy protocols, communication channels, etc. Security was another concern that the STATPack™ development team had to address. Health care applications need to be extremely secure. In many cases, health care applications must follow HIPPA guidelines. The STATPack™ also had the unique situation that the technical requirements of the system were as important, if not more important, than the functional requirements. For example, since this system was intended for biosecurity alerts and notifications, response time was very important. Also, the quality of the image that was captured by the camera needed to be a high resolution and the “footprint” of the STATPack™ needed to be minimal, as most health laboratories are cramped for space. A virtually indestructible keyboard was specifically selected for STATPack™ that could be sterilized, if needed. Lastly, a very important consideration of the development of the STATPack™ was that it could potentially save lives. Therefore, the system needed to have high reliability and be extremely accurate.

the STATPack™ system and their expectations of the communication between the labs, yet, at times the information was ambiguous. For example, sometimes the requirements were unclear and incomplete because the users didn’t know what technology could be used. Although the users were eager to answer questions and share their ideas on the requirements of the STATPack™ system, they were extremely busy health care professionals and their other responsibilities did not permit them to be on-site users. After the initial discussions with the users, the development team then began to research what type of technology could be used for the STATPack™ development effort, this helped clarify some of the requirements. In the first two iterations of the system prototype, the developers wrote the unit test plans prior to the coding. Also, at that time, the team was made up of two developers and they worked together on the coding (i.e. pair programming). As the system became more sophisticated (year 2), two additional part-time student developers were added to the project team. For the most part, “pair programming” continued. The developers tested the functions and had a working prototype up within a few weeks after the initial meeting and continued to produce iterations of prototypes through out the project. As shown in the timeline displayed in Figure 7, ten prototypes were produced in 21 months. Sep-02

Oct-02

Nov-02

Dec-02

Initial Meeting Generate User Stories Prototype (1)

Jan-03

Feb-03

Mar-03

Prototype (2)

Apr-03

May-03

Jun-03

Dec-03

Prototype (3) Prototype (4) Prototype (5) Prototype (6)

Jan-04 Prototype (7)

Feb-04

Mar-04

Apr-04

May-04

Prototype (8) Prototype (9) Prototype (10)

4.2 Applying Extreme Programming The STATPack™ project manager selected the extreme programming approach for the following reasons: flexibility, rapid prototyping, low overhead, and methodology suited for a small to medium size project. The initial information technology team consisted of two part-time developers who were computer science students working 20 hours a week, an on-call senior research technologist professional and a project manager. The user team consisted of the Director of the University of Nebraska Center for Biosecurity who is also a physician, the Assistant Director of the Nebraska Public Health Lab (NPHL) and two NPHL health professionals. At the onset of the project, there was a planning meeting for the STATPack™ project. The users provided several key scenarios on how they envisioned the usage of

Figure 7 - Timeline

5. Results The STATPack™ project fully adopted five of the nine extreme programming principles, one initially, one partially and one was not adopted, see Table 3. Testing initially started with the methodology of writing the test plan first and then code. This continued for awhile, until the system became more complex and additional testing was required to ensure other functions of the system were not impacted. Refactoring was partially adopted, this was due to having inexperienced developers on the team. Pair programming was modified by assigning a lead developer to report on the status of the task. It was not possible to

have an on-site user as s/he had responsibilities working at a health laboratory. Table 3 Summary of Adoption Practice Small Releases Simple Design Testing Refactoring Pair Programming Collective Ownership Continuous Integration 40-hour week On-site Customer

Adoption Fully Fully Initially Partially Modified Fully Fully Fully Not adopted

5.1 Lessons learned Rapid prototyping was a key factor in the early “buy in” of the users. Asking the key users to share stories and then producing a prototype in a matter of weeks that functionally performed the tasks was a major advantage. Any reluctance the user may have had about the new technology was dramatically diffused. The early user feedback from the prototype reduced the amount of rework and the possibility of the development team going down the wrong path. Also, by having a prototype up and running quickly created strong momentum and group synergy. The iterative prototyping allowed the user to have a better understanding of the technology available (e.g. the quality of the image taken by the camera, the durability of the keyboard, the size of the flat panel, the footprint size of the unit, etc.). It also provided a platform to define unfamiliar terminology. The project team also experienced positive IT developer / user relationship. By having a working prototype as a reference, communication barriers were minimized and the different cultures were diffused. The IT project team became a very cohesive group. This proved very valuable when certain milestones needed to be met, everyone helped each other and was dedicated to completing the task on time. This could partially be attributed to the close working relationships of the developers that is required with “pair programming” and also, from careful team selection. However, none of the developers had worked together on prior projects. Finally, the extreme programming approach proved to be adaptive to new technologies.

5.2 Modifications A short fall was not having code walkthroughs. If pair programming is done with experienced programmers then code walkthroughs may not be necessary, but pair

programming using novices requires more oversight. Also, the project experienced turnover Therefore, the project manager required a code walkthrough of the entire system prior to the departure of a key developer. The collective ownership of the code proved valuable in the code walkthrough for two reasons, no one’s ego was bruised and all programmers had a strong desire to understand every part of the system. The STATPack™ project needed more documentation than what was produced using the extreme programming process, i.e. self-documentation. The project manager addressed this issue by hiring an individual that was assigned the sole task of writing the technical documentation. This individual was not one of the developers. The technical writer interviewed the developers and then wrote the documentation. This kept the developers focused and did not interrupt their code production. Usability testing was also added as one of the steps in the extreme programming process. The usability testing was especially helpful in evaluating the technical requirements such as system processing speed, camera image clarity, etc. Further, usability testing identified additional functional requirements of the system for ease of use and ease of learning the new system. Users were again given another opportunity and format to define the requirements of the project. Also, the usability testing was a way to assess the effectiveness and accuracy of the development effort.

6. Discussion 6.1 Experienced advantages The STATPack™ project experienced many of the benefits of the extreme programming process. These are addressed below. 6.1.1 Early strong user “buy in”. Even though the users had many distractions, the meetings to “gather and adjust user stories” were effective and efficient. Producing a working prototype early in the development process had a considerable positive effect on user ownership. User ownership and dedication to the system occurred very early in the development process and, in fact, as time went on the STATPack™ project became one of the users’ priority distractions. The users were extremely pleased with the functionality of the system and even more impressed with having a functional system to evaluate at such an early point in the development process. After ten months, a prototype was deployed for field testing. 6.1.2 Iterative process. Requirements of new functions continued to be identified after each prototype. The rapid prototyping provided an fruitful environment for the users and the developers to communicate clearly the next round

of functional requirements and also provided a springboard for new ideas and innovations. 6.1.3 Quick prototype production. Overall, the project produced prototypes in a rapid manner considering the fact that the student developers worked at most 20 hours a week and took off time during college breaks which artificially extended the timeline. Also, coordinating a time with the users inflated the timeline because of their busy schedules. 6.1.4 Extreme flexibility. The extreme programming methodology addressed the challenges of the technical requirements of the system as well. Several new technologies were coded, tested and deployed. In some cases, new technologies replaced old technologies. For example, the STATPack™ is on its third camera prototype.

6.2 Experienced disadvantages There was some “tweaking” of the extreme programming process by the project manager to mitigate the inherent disadvantages of extreme programming. The key issues are addressed below. 6.2.1 Testing function. Test plans of new functions were written before coding. But, as the system moved from R&D prototypes to field testing prototypes more thorough testing was required. This was also necessary because of the distributed nature of the system. Each client location had its own unique testing requirements. 6.2.2 Project scalability. As the project became more mature, “pair programming” continued, however, one of the developers of the team was the “lead developer” and was responsible for reporting the status of the task and informing the project manager when technical problems were encountered. 6.2.3 Lack of Documentation. Although the extreme programming methodology claims that selfdocumentation is enough, it was necessary to have more comprehensive documentation which was assigned to a non-developer.

7. Conclusions The goal of this research was to improve the understanding of the development and implementation of telehealth applications. The extreme programming method has important implications for academics as well as for IT practitioners. Overall, we can say that the extreme programming is an effective methodology to develop health care applications. The rapid prototyping enabled IT developers and health care users to clarify system requirements, communicate openly, and quickly build rapport.

The research found that where the technology is new or foreign, the extreme programming process was flexible enough to support several iterations of technology and produce prototypes in a timely manner. Lastly, the study showed that several of the benefits of extreme programming were realized, even though the process was modified. The research has some limitation. The IT developers in the project were novice IT developers and worked parttime. The users in the project were available as much as possible, but they did have other work priorities that were more important. These two factors probably affected the speed of the prototype development Further research is required to address how the extreme programming testing approach works in a dual environment of development and production support. Also, the issue of how much documentation is necessary to ensure a smooth transition when there is developer turnover needs to be studied.

8. References [1] S. Hinrichs, “Rold of NPHL in responding to bioterrorism,” NPHL Newsletter, Spring 2000, pg. 1 [2] P.Evans, T.S. Wurster, Blown to Bits, Harvard Business School Press, Boston, Massachusetts, 2000. [3] D. G. Kilman, D. W. Forslund, “An International collaboratory based on virtual patient records,” Communcations of the ACM, August, 1997, 40(8), pp. 111 – 117. [4] Eder, L, and Darter, M., “Physicians in cyberspace,” Communications of the ACM, March, 1998, 41(3), pp. 52 – 54. [5] J. Reid, A telemedicine primer: Understanding the issues, Artcraft Printers: Montana, 1996. [6] T.C. Ricketts, Rural Health in the United States, Oxford University Press, 1999. [7] J. Emery, “Partnerships between Academic Medical Centers & Rural Communities,” Health Forum Journal, January/February, 2001, pp. 29-46. [8] N.M. Lorenzi, R.T. Riley, “Managing Change: An Overview”, Journal of American Medical Informatics Association, Vol.7, Number 2, April 2000. [9] M.J. Succi, Z.D. Walter, “Theory of user acceptance of information technologies: an examination of healthcare professionals”, Proceedings of the 32nd Annual Hawaii Conference of System Sciences, Maui, 1999. [10] R. Bashshur, J.H. Sanders, and G.W. Shannon, Telemedicine: Theory and Practice, Springfield, Illinois, 1997.

[11] A. Croteau, D. Vieru, “Telemedicine Adoption by Different Groups of Physicians”, Proceedings of the 35nd Annual Hawaii Conference of System Sciences, Maui, 2002.

[29] J. McMahon, “5 Lessons from Transitioning to eXtreme Programming”, Control Engineering, March 2003, Vol. 50, Iss. 3. p.59.

[12] I. Sommerville, Software Engineering, seventh edition, Addison Wesley, 2004.

[30] S. Smith, S. Stoecklin, “What We Can Learn From Extreme Programming”, The Journal of Computing in Small Colleges, Vol. 17, Iss. 2, December 2001, pp. 144-151.

[13] W.W. Royce, “Managing the development of large software systems”, Proceedings, IEEE WESCON, August 1970, pp.1-9. [14] B. Boehm, “A Spiral Model of Software Development and Enhancement”, Computer, May 1988, pp.61-72. [15] I. Sommerville, Software Engineering, sixth ed., Addison Wesley, 2001. [16] G.J. Wolff, “The management of risk in system development: ‘Project SP’ and the ‘New Spiral Model’”, Software Engineering Journal, May 1989, pp.134-142. [17] K. Beck, “Embracing change with extreme programming”, IEEE Computer, 1999, 32(10), 70-8. [18] K. Beck, Extreme Programming Explained, Boston: Addison-Wesley, 2000. [19] K. Schwaber, and M. Beedle, Agile Software Development with Scrum, Englewood Cliffs, NJ: Prentice Hall, 2001. [20] A. Cockburn, Agile Software Development, Reading, MA: Addison-Wesley. 2001. [21] Manifesto for Agile Software Development. 2001, Agile Alliance [22] R. Martin, Agile software development: principles, patterns, practice, Pearson Education Inc., 2003 Upper Saddle River, NJ, 2003. [23] L. Cao, K. Mohan, P. Xu, and B. Ramesh, “How Extreme does Programming Have to be?”, Adapting XP Practices to Large-scale Projects, In 37th Hawaii International Conference on System Sciences, January 2004. [24] K. Keefe, M. Dick, “Using Extreme Programming in a Capstone Project”, In Proceedings of the sixth Australian Computing Education Conference, January 2004. [25] M. Griffin, “Extreme Programming: An Alternative Life Cycle Model Part 1”, Information Executive, Sep/Oct 2002; 6,5. [26] J. Shore, “Continuous Design”, IEEE Software, January/February 2004, pp. 20-22. [27] R. Martin, “eXtreme Programming Development through Dialog”, IEEE Software, July/August 2000, pp. 12-13. [28] M.M. Muller, F. Padberg, “Analyzing the Cost and Benefit of Pair Programming”, In Proceedings of the Ninth International Software Metrics Symposium, 2003.

[31] M. Muller, F. Padberg, “On the Economic Evaluation of XP Projects”, In Proceedings of the ninth European software engineering conference held jointly with 10th ACM SIGSOFT international symposium on Foundations of software engineering, September 2003, pp. 168-177. [32] A. Elssamadisy, G. Schalliol, “Recognizing and responding to bad smells in extreme programming”, In International Conference on Software Engineering ICSSE – 24, pp. 617-622, Orlando, Florida, USA, May 2002. [33] A. Cockburn, L. Williams, “The Costs and Benefits of Pair Programming”, Humans and Technology Technical Report, January 2000. [34] J. Armitage, “Are Agile Methods Good for Design”, Interaction, January + February, 2004, pp. 14-23. [35] B. Boehm, “Get Ready for Agile Methods, with Care”, IEEE Computer, Vol. 35, No.1, 2002, pp. 64-69. [36] M. Lippert, P. Beck-Pechau, H. Breitling, J. Koch, A. Kornstadt, S. Roock, A. Schmolitsky, H. Wolf, H. Zullighoven, “Developing Complex Projects Using XP with Extensions”, IEEE Computer Society, June 2003, pp. 67-71. [37] M.D. Myers, Qualitative Research in Information Systems, ISWorld Net, http://www.qual.auckland.ac.nz/, retrieved May 2004. [38] C. Argyris, R. Putnam, and D. MacLain Smith, Action science – Concepts, methods and skills for research and intervention, San Francisco: Jossey-Bass, 1982. [39] P.B. Checkland, Systems thinking, systems practice, Chichester: John Wiley & Sons, 1981. [40] O. Zuber-Skerritt, Action research for change and development, Aldershot: Gower Publishing, 1991. [41] A. Fruhling, A. Sambol, “Introducing STATPack™”, NPHL Newsletter, 2003, pg. 5.