19-10-2016, 04:35 PM
1459952758-REPORT.docx (Size: 112.17 KB / Downloads: 5)
INTRODUCTION
Extreme Programming (XP) is actually a deliberate and disciplined approach to software development. About six years old, it has already been proven at many companies of all different sizes and industries worldwide. XP is successful because it stresses customer satisfaction. The methodology is designed to deliver the software your customer needs when it is needed. XP empowers software developers to confidently respond to changing customer requirements, even late in the life cycle. This methodology also emphasizes teamwork. Managers, customers, and developers are all part of a team dedicated to delivering quality software. XP implements a simple, yet effective way to enable groupware style development.
XP improves a software project in four essential ways; communication, simplicity feedback, and courage. XP programmers communicate with their customers and fellow programmers. They keep their design simple and clean. They get feedback by testing their software starting on day one. They deliver the system to the customers as early as possible and implement changes as suggested. With this foundation XP programmers are able to courageously respond to changing requirements and technology. XP is different. It is a lot like a jig saw puzzle. There are many small pieces. Individually the pieces make no sense, but when combined together a complete picture can be seen. This is a significant departure from traditional software development methods and ushers in a change in the way we program.
If one or two developers have become bottlenecks because they own the core classes in the system and must make all the changes, then try collective code ownership. You will also need unit tests. Let everyone make changes to the core classes whenever they need to. You could continue this way until no problems are left. Then just add the remaining practices as you can. The first practice you add will seem easy. You are solving a large problem with a little extra effort. The second might seem easy too. But at some point between having a few XP rules and all of the XP rules it will take some persistence to make it work. Your problems will have been solved and your project is under control. It might seem good to abandon the new methodology and go back to what is familiar and comfortable, but continuing does pay off in the end. Your development team will become much more efficient than you thought possible. At some point you will find that the XP rules no longer seem like rules at all. There is a synergy between the rules that is hard to understand until you have been fully immersed. This up hill climb is especially true with pair programming, but the pay off of this technique is very large. Also, unit tests will take time to collect, but unit tests are the foundation for many of the other XP practices so the payoff is very great.
XP projects are not quiet; there always seems to be someone talking about problems and solutions. People move about, asking each other questions and trading partners for programming. People spontaneously meet to solve tough problems, and then disperse again. Encourage this interaction, provide a meeting area and set up workspaces such that two people can easily work together. The entire work area should be open space to encourage team communication. The most obvious way to start extreme programming (XP) is with a new project. Start out collecting user stories and conducting spike solutions for things that seem risky. Spend only a few weeks doing this. Then schedule a release planning meeting. Invite customers, developers, and managers to create a schedule that everyone agrees on. Begin your iterative development with an iteration planning meeting. Now you're started.
Usually projects come looking for a new methodology like XP only after the project is in trouble. In this case the best way to start XP is to take a good long look at your current software methodology and figure out what is slowing you down. Add XP to this problem first. For example, if you find that 25% of the way through your development process your requirements specification becomes completely useless, then get together with your customers and write user stories instead.
HISTORY
Extreme Programming was created by Kent Beck during his work on the Chrysler Comprehensive Compensation System (C3) payroll project. Beck became the C3 project leader in March 1996 and began to refine the development methodology used in the project and wrote a book on the methodology (in October 1999, Extreme Programming Explained was published) Chrysler cancelled the C3 project in February 2000, after seven years, when the company was acquired by Daimler-Benz.
Many of extreme programming practices have been around for some time; the methodology takes "best practices" to extreme levels. For example, the "practice of test-first development, planning and writing tests before each micro-increment" was used as early as NASA's Project Mercury, in the early 1960s (Larman 2003). To shorten the total development time, some formal test documents (such as for acceptance testing) have been developed in parallel (or shortly before) the software is ready for testing. A NASA independent test group can write the test procedures, based on formal requirements and logical limits, before the software has been written and integrated with the hardware. In XP, this concept is taken to the extreme level by writing automated tests (perhaps inside of software modules) which validate the operation of even small sections of software coding, rather than only testing the larger features.
2.1 Origins
Software development in the 1990s was shaped by two major influences: internally, object-oriented programming replaced procedural programming as the programming paradigm favored by some in the industry; externally, the rise of the Internet and the dot-com boom emphasized speed-to-market and company growth as competitive business factors. Rapidly changing requirements demanded shorter product life-cycles, and were often incompatible with traditional methods of software development.
The Chrysler Comprehensive Compensation System (C3) was started in order to determine the best way to use object technologies, using the payroll systems at Chrysler as the object of research, with Smalltalk as the language and GemStone as the data access layer. They brought in Kent Beck,[5] a prominent Smalltalk practitioner, to do performance tuning on the system, but his role expanded as he noted several problems they were having with their development process. He took this opportunity to propose and implement some changes in their practices based on his work with his frequent collaborator, Ward Cunningham. Beck describes the early conception of the methods
The first time I was asked to lead a team, I asked them to do a little bit of the things I thought were sensible, like testing and reviews. The second time there was a lot more on the line. I thought, "Damn the torpedoes, at least this will make a good article," [and] asked the team to crank up all the knobs to 10 on the things I thought were essential and leave out everything else.
Beck invited Ron Jeffries to the project to help develop and refine these methods. Jeffries thereafter acted as a coach to instill the practices as habits in the C3 team.
Information about the principles and practices behind XP was disseminated to the wider world through discussions on the original wiki, Cunningham's WikiWikiWeb. Various contributors discussed and expanded upon the ideas, and some spin-off methodologies resulted (see agile software development). Also, XP concepts have been explained, for several years, using a hypertext system map on the XP website at "http://www.extremeprogramming.org" circa 1999.
Beck edited a series of books on XP, beginning with his own Extreme Programming Explained (1999, ISBN 0-201-61641-6), spreading his ideas to a much larger audience. Authors in the series went through various aspects attending XP and its practices. The series included a book that was critical of the practices.
2.2 Current state
XP generated significant interest among software communities in the late 1990s and early 2000s, seeing adoption in a number of environments radically different from its origins.
The high discipline required by the original practices often went by the wayside, causing some of these practices, such as those thought too rigid, to be deprecated or reduced, or even left unfinished, on individual sites. For example, the practice of end-of-day integration tests for a particular project could be changed to an end-of-week schedule, or simply reduced to mutually agreed dates. Such a more relaxed schedule could avoid people feeling rushed to generate artificial stubs just to pass the end-of-day testing. A less-rigid schedule allows, instead, for some complex features to be more fully developed over a several-day period. However, some level of periodic integration testing can detect groups of people working in non-compatible, tangent efforts before too much work is invested in divergent, wrong directions.
Meanwhile, other agile development practices have not stood still, and XP is still evolving, assimilating more lessons from experiences in the field, to use other practices. In the second edition of Extreme Programming Explained (November 2004), five years after the first edition, Beck added more values and practices and differentiated between primary and corollary practices.
CORE PRACTICES OF EXTREME PROGRAMMING
The basic practices of Extreme Programming addressed in this article are pair programming, re-factoring, testing, continuous integration, and evolutionarydesign. It should be noted that there are many other practices advocated in Extreme Programming and that the core practices of Extreme Programming have beennamed and renamed by many authors. However, we are examining only the practices that we believe can be adapted for use in a computer science curriculum.
3.1 Pair Programming
Pair programming is the practice of two programmers/engineers sitting in close proximity and participating in the development effort ofone programming unit. Both parties are working on the one programming unit, generally with each member performing a task the other is not doing. Typically, the pair is divided into one person entering code or test cases while the other is reviewing and thinking. For example, bothmembers might discuss a method needed in their unit and decide to implement the new method. While one member is keying the method, the other member might be thinking of mechanisms for testing that method. Another example might be the situation where one member is keying a needed class, while the other member might realize that the pair has already developed a similar class and would begin thinking about what programming concept would make this needed class be developed in a different manner.
The thinking member might realize that polymorphism, inheritance, or a design pattern usage would make a better design for the functionality of the class. The close proximity and focus on one programming unit promotes the sharing of ideas and encourages a better design to evolve. It has also been observed that the code resulting from pair programming is more defect free, does not take significantly more time to develop than if developed byone member, yields fewer lines of code, and is more satisfying to programmers. Pair programming encourages the design of the programming unit to evolve as the actual programming activity is being conducted.
3.2 Refactoring
Refactoring, as defined by Fowler, is an activity ofcontinuous re-design of a program unit to take advantage of programming techniques,especiallyobject-oriented design and design patterns, to make the programs more reusable, simpler, and more efficient. Refactoring can occur at various times throughout the development process. For example, if during the programming activity one of the programming pair determines that two methods are doing the same functions but with different data, the programming pair would refactor the code to take advantage of polymorphism. When a programmer finds two classes containing the same methods or methods with the same functionality, these classes again would be refactored. When code seems to be out of place, refactoring the code to another class makes sense. When code is repeated within a method, refactoring it by extraction makes it a more reusable method.
This re-designing of a programming unit takes advantage of programming techniques of both object-oriented and pattern-oriented programming. A goal of refactoring is to yield
programming units with a strong internal structure. In other words, the programming units are
generally more reusable, simpler, object-oriented, pattern oriented, and maintainable. Additionally, refactoring allows developers to respond quickly to a change in customer requirements or technology.
3.3 Testing
Testing, as defined by Extreme Programming, includes ideas such as unit testing by programmers, functional testing by users, and automated testing to generate test units thatmirror the actual programming units. These concepts fully support the testing of programming units to promote a defect free unit witheach unit release. The most promising idea of automated testing involves generating testing units (classes which test a programming unit automatically). These testing units are built as the actualprogramming unit is being built. This type of testing drives the development process. The scenario works as follows: a programmer/engineer codes the programming unit, tests the unit, thinks of more tests for the unit, tests the unit again, thinks of more tests for the unit, tests the unit again and continues this iterative testing until no more tests can be uncovered. The theory is that this scenario yields well tested modules at the end of the iterations.
Testing in Extreme Programming involves two types of tests. The first type of testing is unit testing whichis the testing of individualprogramming units suchas a class. Developers write tests for everyclass the yproduce and evenwrite the tests before writing the code. When they add functionality to the original class, they can test the prior functionality with the developed testing unit and add more tests for the new functionality. Unit tests must be 100% correct before testing continues.
The second type of testing in Extreme Programming is functional testing. Functional tests are scripts developed to test clusters of classes, perhaps in a use case, that meet the user requirements and meet performance and constraints prescribed by the users. Functional testing is typically use case driven tests. These tests are the responsibility of the users or customers while the unit tests belong to the developers.
3.4 Continuous Integration
Continuous integration is the concept of integrating new code into existing code and then utilizing the testing techniques defined by Extreme Programming. This practice yields units of code that are continually tested during development. Using continuous integration, a programmer/engineer integrates new code into existing code after the existing code has been relentlessly tested. Therefore, the release of the change is done when it is tested and everyone knows about the new functionality at the time of the release. While this is dynamic, it should not pose insurmountable problems since the code is released only after thorough testing. This particular idea generates much discussion among the software practitioners, but the result is that it does advocate the thorough testing of modules prior to release as its main premise. On this main premise there is no resistance. It also recognizes that the integration of code in the object-oriented paradigm deserves some focus.
Evolutionary design involves making iterations of a program within minutes rather than days. The programming pair defines each iteration of the problem and then implements these iterations. Upon completion, the problem is expanded to yield another iteration and then that iteration is implemented. The idea is explained as a planning game. The scenario of a planning game is to write a story (a lightweight use case) to define the problem, estimate the problem, make a commitment to develop the solution to the problem, develop the solution, present the solution, and then begin again by re-writing the story to define more of the problem.
EXTREME PROGRAMMING CONCEPTS IN COMPUTER SCIENCE CURRICULUMS
Since Extreme Programming proposes or uses concepts that are generally seenas good for software development, as computer science educators, we should be evaluating the role of this new methodology in computer science curriculums. In this next section, we will examine how the concepts of Extreme Programming, described above, can be utilized in a computer science curriculum, especially in introductory courses, to more effectively teach software development.
Currently, the practice of pair programming is not utilized in programming courses inmost colleges or universities. In fact, computer science faculty view joint work on programming assignments as plagiarism or cheating by students. Most courses in programming encourage students to design and code their own work. While there are exceptions to this observation , students are rarely exposed to more than one solution to a problem. However, Extreme Programming demonstrates that programmers can not only work well in pairs but also learn much from discussing code and design with another person. Students and faculty would benefit from the inclusion of the practice of pair programming in programming classes. At a minimum,
Extreme Programming demonstrates that the inclusion of the sharing and discussing various designs or examining the pros and cons of particular solutions to programming problems would be beneficial to students.
Harlan Mills did prescribe a similar method in his Cleanroom approach. In Mills' approach, one student programs the exercise while another writes the test to test the exercise. Then they change positions and redo the assignment. Each student receives two grades, one for the development of the exercise and one for the testing of the exercise. An approach that we have tried recently utilizes pair programming in a teaching model different from the traditional lecture and laboratory. Inthis approach, students receive a short lecture on a topic and thenproceed to the laboratory to do an exercise using pair programming.
This approach was first utilized because of too few computers in our teaching laboratory. However, it proved so useful that we decided to keep the approach even when more computers became available. This approach was especially beneficialwhenwe paired a good student programmer with a student who was struggling. In our approach, the instructor was always present in the laboratory during the programming exercise. The programming exercise was based on the concepts taught in the class, and students were rewarded iftheyfound design patterns or other object-oriented concepts that made the code simpler (which is one of the goals of pair programming).
Research in pedagogical patterns for implementing pair programming and grading the results of such activities are still emerging. However, a recent study in the use of pair programming in computer science classes appears to support the premise that this technique of Extreme Programming is an effective method for teaching programming concepts. Furthermore, this approach to learning port studies done on cooperative learning . Cooperative learning has been especially effective in the teaching of girls. Pair programming may be a useful practice in introductory programming classes in order to promote computer science as a major among female students.
Refactoring is also rarely utilized or taught currently in computer science courses. Many educators in curriculum meetings are debating such items as what language or when to introduce the concepts of objects and when to require students to write their own classes. The debates on when and where to introduce the ideas of refactoring or what is good design have not become the focus of many academic debates. While we teach polymorphism, most textbooks do not have adequate exercises that require students to think of it as a solution to a problem. With the exception of the model-view-controller pattern, most computer science textbooks do
not debate different design techniques, do not conduct design reviews, and do not require the use of patterns. Computer science courses often do not encourage or reward good design techniques. In fact, except for a few upper-level specialized courses on software engineering topics, computer science courses do not attempt to define the techniques of design.
This article is not so bold as to recommend the teaching of refactoring in a particular course. However, it does seem apparent that the traditional topics taught in the computer science courses need to be critically evaluated. Traditionally, the CS2 or Data Structures courses taught those items we thought were critical to understand procedural programming and the patterns needed for the procedural programming paradigm. These included building procedures and learning patterns such as linked list, stacks, and queues. With the integration of object-oriented and pattern-oriented programming in the computer science curriculum, it is time to revisit the topics taught and defend the inclusion of some refactoring and good design topics in these courses.
Testing is a topic that has been long overlooked in the computer science curriculum. There is no specific place in the typical computer science curriculum where testing is taught as a topic which requires some programming exercises. Generally, students learn the terms black box and white box testing but rarely are they asked to create tests which represent one or the other type of testing. Most computer science educators do not ask student to generate testing units for programming assignments, and rarely do students have a good understanding of how to investigate a programming unit in order to determine how to adequately test the unit. Students generally have the attitude that ifit works once, it is tested. The concept of exhaustive
testing, complete testing or iterative testing is typically not introduced in programming classes such as CS1 and CS2. Additionally, faculty who grade programming assignments rarely rigorously test student programs. Harlan Mills advocated a tight integration of testing with development in the early 70s, but few curriculum adopted this approach. Most of the programming courses could include a section of testing. For example, when teaching if statements, the process of testing if statements should also be addressed. Decomposition of testing into unit tests and scenario testing has been advocated for the last few years. However, now that a testing unit is normally defined as a class and scenarios are defined as those paths through use cases, it is even more important to integrate these types of tests into our computer science curriculum. When classes are first developed by students is the time to introduce class testing. When use cases of collaborating classes are first developed by students is the time to introduce scenario-based testing.
The approach that we have taken in our attempt to introduce more teaching into the CS1 course is to teach and practice testing techniques in the laboratory portion of our CS1 class. Extensive focus is given to testing during the first few weeks of a semester. Students learn different types of tests and have programs (provided by the faculty member) for which they must build tests. After generating tests individually, we discuss the pros and cons of the tests which individuals have produced in order to determine better tests for the code. The idea of systematically testing units of code is conveyed nicely to the students in this approach because they spend so much time actually building and running tests. They also gain a better understanding of functional requirements during this exercise. The students are the required to produce tests for all programming assignments during the semester.
Of all the concepts advocated by Extreme Programming, this concept is certainly in contrast to how we normally teach computer science courses. We often have students build units that are one-time-throw-awayunits. These units require no integration. Rarely do we ask students to integrate new functionality into existing code or to integrate working programming units.
In contrast to howwe teach, this concept maybe the easiest to integrate into the computer science curriculum. One approach is to have one large program developed incrementally during the first programming course. Techniques have evolved that allow the students to develop the first portion of the assignment and after that portion of the assignment is completed, the student is given a correct version on which to build the new functionality for this system. Large programming assignments built incrementally in this manner would be easy to implement in the programming courses and certainly would yield an approach to development of system that supported the concept of continuous integration.
During the age of procedural programming, educators gave students various hints on how to conduct evolutionary design on programming assignments. In walking the halls of the computer science buildings, the instructors could also be heard telling another student what to try and not to try in implementing a programming assignment. Incorporating this practice into programming courses could be designed to support the programming concepts being taught. This practice might work especially well in a programming course with a laboratory component.
APPLYING JUNIT
JUnit is a deceptively simple testing framework that can create a major shift in your personal development process and the enjoyment of programming. Prior to using JUnit, developers typically have resistance to making changes late in a project “because something might break.” With JUnit the worry associated with breaking something goes away. Yes, it might still break, but the tests will detect it. Because every method has a set of tests, it is easy to see which methods have been broken by the changes, and hence make the necessary fix. So changes can be made late on in a project with confidence, since the tests provide a safety net.
In order to create XP style Unit Tests however, developers need to make sure that their classes and methods are well designed. This means that there is minimum coupling between the class being tested and the rest of the classes in the system. Since the test case subclass needs to be able to create an object to test it, the discipline of testing all methods forces developers to create classes with well-defined responsibilities.
Lesson: Requiring all methods to have unit tests forces developers to create better designs. It is interesting to compare classes that have unit tests with those that do not have unit tests. By following the discipline of unit tests, methods tend to be smaller but more numerous. The implementations tend to be simpler, especially when the XP practice of “Write the Unit Tests first” is followed. The big difference I notice is that the really long methods full of nested and twisted conditional code don’t exist in the unit tested code. That kind of code is impossible to write unit tests for, so it ends up being refactored into a better design. As Kent Beck has reported elsewhere “Testing First Makes the Code Testable”
Lesson: Design for testability is easier if you design and implement the tests first. Adopting XP style unit testing also drastically alters the minute by minute development process. We write a test, compile and run (after adding just enough implementation to make it run) so that the test will fail. As William Wake notes “This may seem funny - don't we want the tests to pass? Yes, we do. But by seeing them fail first, we get some assurance that the test is valid.”
Now that we have a failing test, we can implement the body of the method and run the test again. This time it will probably pass, so now it’s time to run all the other unit tests to see if the latest changes broke anything else. Now that we know that it works, we can now tidy up the code, Refactor as needed and possibly optimize this correct implementation. Once we have done this we are ready to restart the cycle by writing the next unit test.
Lesson: Make it Run, Make it Right, Make it Fast (but only if you need to). Early successes with JUnit encouraged me to experiment with other XP Practices. Just having the unit tests in place made programming fun again, and if that practice was valuable, maybe other were as well.
PLANNING
The planning phase begins by writing users stories. User stories serve the same purpose as the use-cases, but are not the same. User stories are written by the customer and are used to create time estimates for release plan. The release plan is then used to create iteration plans for each of the iterations in the product life cycle.
The development team needs to release small releases, iterative versions, to the customers often. After the first release, the project velocity is calculated. The project velocity is a measure of how much work is getting done on your project. The velocity is used to decide the number of iterations and the time estimates for each of the iterations. Iterative Development adds agility to the development process. Iterative Development adds agility to the development process
One of the XP principles is to move people around. This is done to avoid any knowledge loss that might cause a coding bottleneck.
The next subsections introduces three practices of the XP methodology used in the planning phase, these are the on-site customers, the planning game, and small releases. For each of these practices, each subsection explains the main idea of the practice and discusses the strengths and weaknesses of the practice.
6.1. On-site Customers
On-site customer means to include real life customers in the development process. The customers will be always available to answer questions, provide the requirements, set the priorities, and steer the project.
As a result, this will ensure the customers’ satisfaction by including them in and will avoid frustration caused by negative feedback caused by misunderstanding the requirements.
On the other hand, it is not realistic to assume that the customers will be available all the time. The on-site customer is an ideal situation. Having on-site customers can sometimes be difficult since customers do not fully understandable the benefits of regular developer-customer interactions, and they do not want to be bothered by giving feedback to all team members all the time.
6.2. The Planning Game
There are two key planning steps in XP: release planning and iteration planning. The planning game tends to create a time estimate for the release plan. The release plan is then used to create iteration plans for each of the iterations. Release Planning is a practice where the developers and the customers decide on which features will be included in which release and when it will be delivered. The programmer gives a cost for each of the stories given by the customer – Exploration Phase. The cost is an estimate of the story difficulty and the time required to develop
the story. Using the cost estimates, and with knowledge of the features importance, a plan for the project is laid out and a commitment is done to deliver the features in the date agreed upon –Commitment Phase. The plan is not precise as the cost and priorities are not solid. However, the release plan is revised frequently when required Steering Phase.
Iteration Planning during Iteration Planning, the programmers’ break down the features provided by the customers into tasks, and estimates their cost. Based on the amount of work accomplished in the previous iteration, the team signs up for what will be undertaken in the current iteration. This gives directions to the team every couple of weeks.
The planning game is very simple, yet it provides very good information about what has been done and what could be accomplished in a two weeks period. It also
provides an excellent steering control for the customers. The customers are aware of the progress of the project, and whether the progress is sufficient or not.
On the other hand, progress is so visible, and the ability to decide what will be done next is so complete, that XP projects tend to deliver more of what is needed, with less pressure and stress.
6.3. Small Releases
The development team is required to make small frequent releases of working software that customers can evaluate. The first release includes the smallest set of useful features set. Subsequent releases include newly added features.
Small releases are important for both the customers and the development team. The customer can evaluate the software or release to end users which is highly recommended. This evaluation provides necessary feedback to the development team.
CHAPTER 7
ADVANTAGES AND DISADVANTAGES
7.1 Advantages
• 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.
• Small releases and the continuous design process allows for frequent review of the system by the developers and the users. This constant and quick feedback helps identify errors, supports ongoing usability tests 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.
Refactoring helps developers respond quickly to changing requirements
• 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.
• 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. 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.
7.1 Disadvantages
• 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.
• Therefore, extreme programming is more useful in small to medium scale projects.
• 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.
• 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.
• Other noted disadvantages are the requirement of only employing experienced developers, insisting on on-site access to users, and the lack of documentation.
CONCLUSIONS
The goal of this research was to improve the understanding of the development and implementation of Tele health 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.