An Analysis of the Extreme Programming Methodology, Through the Development of an Emergency Response System, and Through a Comparisons of Its Techniques against Other Methodologies

feature-top

Abstract

The Extreme Programming (XP) methodology is the reason why every programmer in the world, should be happy they chose to learn and master the art of programming and developing great applications. Great applications can be developed fast, through the XP methodology, and this paper will prove this, by analyzing and critiquing the work, of other researchers; who analyzed the power of XP, when it was being put to use, in order to develop great applications.

This paper will analyze a comparison that was made between the XP methodology and the iterative style of software development. The first analysis proved, that XP does save a lot of time, effort and money, in order to develop software. Another analysis that is made on this paper, looks at the use of XP, in order to develop an Emergency Response System. The second analysis demonstrated that the XP methodology is capable of helping a team, develop an Emergency Response System effectively. Through analyzing the work of several researchers, this paper studies an effective development environment setup, for systems and applications.

 

Introduction

The XP methodology has definitely revolutionized the software engineering arena, because it has been the most talked about methodologies, over the past decade (Coleman & McAnallen, 2006). Since it was developed in the late 1990’s, the movement lead by Kent Beck, known as XP, has become a major player in helping, organize the work in a collective basis, where the client is involved, throughout the design and development of the software (Wood, Michaelides & Thomson, 2013). Teamwork is the emphasis of XP because in XP the developers have to write the code in pairs, also the code is the most important part of XP according to Beck & Andres (2012???). On the first work analyzed, the author makes a comparison between the XP methodology and the iterative methodology used by the software company, Microsoft (Cusumano, 2007).

Three techniques are used in order to plan a project in XP, according to Cusumano, (2007); the three techniques are user stories creation, which makes sure that all the functionalities and features the customer wants are delivered (Cusumano, 2007). Another technique used in XP, according to Cusumano (2007), is to assess the time it will take developers to develop, each of the functionalities. Prioritizing each feature and functionalities according to what the customer wants, as well as the time allowed by the customer, to deliver each feature or functionality, is also another technique used in the XP methodology (Cusumano, 2007). According to Fruhling & de Vreede (2006), there is no one way, considered to be universal, which a developer can follow, in order to develop a system.

The project on the emergency response system (ERS) demonstrated that, through the XP methodology, a successful effort to improve, U.S. biosecurity preparedness is possible (Fruhling & de Vreede, 2006). The ERS is supposed to be new and innovative, where a laboratory is used as a response system, which would tackle terrorism and pandemics (Fruhling & de Vreede, 2006). On another research project, by Bulajic, Sambasivam & Stojic (2013), attempt to bring attention to the adequate tools, which are promoted by XP and other methodologies, needed in order to cultivate an effective development environment. The software development methodology tools are analyzed on the research paper, written by Bulajic, Sambasivam & Stojic (2013), in order to recommend a set of tools, which can provide an effective environment for software development.

 

Methods and Results

Techniques such as pair programming, collective code ownership and frequent meeting that are short, are some of the practices used in XP, because these techniques, imply a higher level of independence, collaboration, and responsibility (Wood, Michaelides & Thomson, 2013). On the work done by Cusumano (2007), he demonstrated, through the product planning phase, that the Microsoft style of planning used features, which represented small chunks of functionalities and structured their requirements based on those functionalities.

The Microsoft style of programming also relied on how the user of the product uses it, in order to understand the requirements better (Cusumano, 2007). The XP style of programming allows each project team members, to be the focus of the project and to understand, what the most important features of the project are. The Microsoft-style of programming uses a short vision statement, which would define each key features, of the product (Cusumano, 2007).

The Microsoft style of development though does not account for the features, which customers never really use, and can call for a lot of unnecessary work, which was the case with Windows Longhorn (Cusumano, 2007). Microsoft resembles the XP methodology according to Cusumano (2007), however just as any other company, the Microsoft Company uses overtime, in order to meet unrealistic expectations, due to poor project management and teamwork (Cusumano, 2007). On the other work performed by Fruhling & de Vreede (2006), they utilize the XP development methodology, because the requirements of the system were, evolutionary and were not well established at the beginning. Working as a pair was attractive, in order to develop the ERS, because team members didn’t have a lot technical skills.

The XP methodology was also used, because it promises to cut overhead costs, and have the ability to produce a working prototype of the software, in a timely manner. Small releases of the software, through rapid prototyping, was a key factor, in the success of the ERS system, to be distributed to potential buyers (Fruhling & de Vreede 2006). Several modifications had to be made to XP however, but small releases, simple design, and collective ownership, XP principles worked best for the development of the ERS.

Coding standards, refactoring and writing the test plan first, were hard to implement (Fruhling & de Vreede 2006). On the work done by Bulajic, Sambasivam & Stojic (2013), they actually proposed an effective environment for software development. Most of the tools and practices that they presented are actually promoted by the XP methodology; these help in team collaboration, automatic build and test procedure, and finally early detection of problems, which may happen in the future (Bulajic, Sambasivam & Stojic, 2013).

 

Conclusion

XP is based on bringing the whole team together, in order to practice simplicity, communication and give each other feedback, courage, and respect (Dalalah, 2013). The twelve practices known in XP are on-site customers, planning game, small releases, simple design, system metaphor, refactoring, coding standards, pair programming, 40-hours work week, continuous integration, collective code ownership, and testing (Dalalah, 2013).

It is without a doubt that XP is very beneficial to a development team; however, as good of a methodology this may be, there are certain drawbacks, that we should mention here. One drawback of XP is the fact that the project focuses on code rather than design, this could be a problem because, for some applications, a design is extremely important (Qureshi, & Hussain, 2012). Also, XP may result in weak documentation of the requirements, because these requirements are gathered, throughout the development lifecycle of the software; which assumes that the client will always be available. Also, XP methodologies, may not be effective with medium and large development projects (Qureshi, & Hussain, 2012).

 

References

Bulajic, A., Sambasivam, S., & Stojic, R. (2013). An effective development environment setup for system and application software. Informing Science & Information Technology, 1037-66.

 

Coleman, G., & McAnallen, M. (2006). Managing the challenges of legacy systems using extreme programming. Software Process: Improvement & Practice, 11(3), 269-275. doi:10.1002/spip.268

 

Cusumano, M. A. (2007). Extreme programming compared with Microsoft-style iterative development. Communications Of The ACM, 50(10), 15-18. doi:10.1145/1290958.1290979

 

Dalalah, A. (2013). Extreme programming: Strengths and weaknesses. The International Arab Conference on Information Technology. Retrieved from http://www.acit2k.org/ACIT/2013Proceedings/132.pdf

 

Fruhling, A., & de Vreede, G. (2006). Field experiences with extreme programming: developing an emergency response system. Journal Of Management Information Systems, 22(4), 39-68.

 

Kent, B., & Cynthia, A. (2012). Extreme programming explained: Embrace change. Westford, MA: Pearson Education, Inc.

 

Qureshi, M. J., & Hussain, S. A. (2012). An improved XP software development process model. Science International, 20(1), 5-7.

 

Wood, S., Michaelides, G., & Thomson, C. (2013). Successful extreme programming: Fidelity to the methodology or good teamworking? Information & Software Technology, 55(4), 660-672. doi:10.1016/j.infsof.2012.10.002

 

 

 

 

But I must explain to you how all this mistaken idea of denouncing pleasure and praising pain was born and I will give you a complete account of the system, and expound the actual teachings of the great explorer of the truth, the master-builder of human happiness. No one rejects, dislikes, or avoids pleasure itself, because it is pleasure, but because those who do not know how to pursue pleasure rationally encounter consequences that are extremely painful.

Nor again is there anyone who loves or pursues or desires to obtain pain of itself, because it is pain, but because occasionally circumstances occur in which toil and pain can procure him some great pleasure. To take a trivial example, which of us ever undertakes laborious physical exercise, except to obtain some advantage from it?

But I must explain to you how all this mistaken idea of denouncing pleasure

But who has any right to find fault with a man who chooses to enjoy a pleasure that has no annoying consequences, or one who avoids a pain that produces no resultant pleasure? On the other hand, we denounce with righteous indignation and dislike men who are so beguiled and demoralized by the charms of pleasure of the moment, so blinded by desire, that they cannot foresee.Nor again is there anyone who loves or pursues or desires to obtain pain of itself, because it is pain, but because occasionally circumstances occur in which toil and pain can procure him some great pleasure. To take a trivial example, which of us ever undertakes laborious physical exercise, except to obtain some advantage from it? Nor again is there anyone who loves or pursues or desires to obtain pain of itself, because it is pain, but because occasionally circumstances occur in which toil and pain can procure him some great pleasure. To take a trivial example, which of us ever

But I must explain to you how all this mistaken idea of denouncing pleasure and praising pain was born and I will give you a complete account of the system, and expound the actual teachings of the great explorer of the truth, the master-builder of human happiness. No one rejects, dislikes, or avoids pleasure itself, because it is pleasure, but because those who do not know how to pursue pleasure rationally encounter consequences that are extremely painful.

feature-top
feature-top

Add a Comment

Hernando Cadet

Collaboratively administrate empowered markets via plug-and-play networks. Dynamically procrastinate B2C users after installed base benefits. Dramatically visualize customer directed convergence without

Collaboratively administrate empowered markets via plug-and-play networks. Dynamically procrastinate B2C users after installed base benefits. Dramatically visualize customer directed convergence without revolutionary ROI.

Hernando Cadet

Collaboratively administrate empowered markets via plug-and-play networks. Dynamically procrastinate B2C users after installed base benefits. Dramatically visualize customer directed convergence without

Collaboratively administrate empowered markets via plug-and-play networks. Dynamically procrastinate B2C users after installed base benefits. Dramatically visualize customer directed convergence without revolutionary ROI.