“Implementation Of Extreme Programming At CheckFree I .
University of WaterlooSoftware Engineering“Implementation of Extreme Programming atCheckFree i-Solutions”CheckFree i-SolutionsWaterloo, OntarioPrepared by:Matthew StephanID xxxxxxxxmdstepha1B Software EngineeringSeptember 14, 20031
Matthew StephanXXXSeptember 15, 2003Professor Joanne AtleeDirector of Software EngineeringUniversity of WaterlooWaterloo, OntarioN2L 3G1Dear Professor Atlee:The following work term report, entitled “Implementation of Extreme Programming atCheckFree i-Solutions”, has been created for CheckFree i-Solutions as required aftercompleting my 1B term. This is my first work term report. The objective of this report isto investigate and scrutinize the execution of Extreme Programming specifically atCheckFree i-Solutions. This report is intended for an individual who has a basic grasp ofhow software is created, but not, necessarily, any knowledge of Extreme Programming.CheckFree i-Solutions is the software component of the CheckFree Corporation, and hasthe responsibility of providing software which enables a business to engage in financialtransactions with other businesses or customers. The company is extremely motivated inensuring that the utilization of online billing continues to escalate.My specific job at CheckFree i-Solutions was to work with the Business to Business teamunder the Director of Software Engineering, Mike Toohey. The team’s mainresponsibility is the creation of a user friendly and efficient web application that allows aparticular business to conduct transactions with a number of other businesses via theInternet.I would like to thank Phil Salmon, Erik Van Der Ahe, Debbie Gutpell, Tony Van DerValk, Rhonda Henderson, Peter Szabo, and Kevin Thomson for providing me with theirprospective on Extreme Programming at CheckFree i-Solutions. I would like to thankFrances Stephan for proofreading this report.I hereby confirm that I have received no help other than what is mentioned above inwriting this report. I also confirm this report has not been previously submitted foracademic credit at this or any other academic institution.Sincerely,Matthew Stephan2
ContributionsThe business to business (B2B) development team at CheckFree i-Solutionsconsists of four developers, one project leader, and one project manager. The B2Bcomponent of CheckFree i-Solutions deals, primarily, with all business to businesstransactions. As the B2B team, it is the group’s responsibility to create a product whichallows a specific business to conduct transactions with others businesses online. Thegroup’s main goal and ambition is to have the B2B product facilitate transactions that areas efficient and straightforward as possible, for all parties concerned. The team aims tomake both the logical components of the application and the graphical user interface(GUI) interrelate coherently. Another key objective for the team is to make the productas generic as possible so that, when a specific company decides to purchase the B2Bproduct, it can be easily customized by both the company in question and the B2Bdevelopers. In the instance where a company purchases the B2B software during thedevelopment of the B2B product, the team’s responsibilities expand to include thedevelopment of specific components and amendments agreed upon by theaforementioned company and CheckFree i-Solutions.The logical components of the B2B application, commonly referred to as the B2BEngine, were completed prior to the commencement of my employment with CheckFreei-Solutions. Thus, the responsibilities accompanied by my job were limited to thedevelopment of the B2B GUI component. As a developer on the team, one of my dutieswas to create the GUI that the transactions would be preformed on, and ensure that theGUI was comprehensible and aesthetically pleasing. This included, but was not limitedto, making flow charts indicative of a user’s path, deciding where specific components ofthe GUI belong, and making the user’s experience as unproblematic as possible.After the GUI was created, it was then my task to create code that would allow forthe GUI components to interact with the logical components of the B2B application.This code had to be able to respond to a multitude of different possible inputs from theuser, and decide what the next logical course of action is. Error handling, efficiency, andcorrectness were all prevalent concerns of mine when manufacturing the code. In order3
to verify that the code continues to behave in the manner expected, I was also responsiblefor creating a large number of automated tests. Since the software must have the abilityto be modified by another developer or company, I also had the duty of documenting mycode in such manner that would facilitate another developer or company to understandand amend the code as they see fit.As a member of the B2B team, not only did I have the ability to observe ExtremeProgramming (XP) in practice, but I was also an active member in the process. Theproject manager and project leader were continually utilizing XP when allocating thedevelopers time, assigning tasks, scheduling meetings, and planning project cycles. Iacquired first-hand experience with key elements of XP including, the discovery anddesign phase, pair programming, incremental planning, automated testing, shortiterations, and a host of others. During my tenure with the B2B team, I attempted tosatisfy the XP principles as meticulously as possible by way of using my knowledge ofXP I acquired through academic means, and by following the example of the othersmembers of the team. Being a relative newcomer to the software industry, I was able toquickly adapt to the XP process. As my term with the team progressed, both the benefitsand shortcomings of XP in relation to our team’s goals became quite evident andconspicuous.CheckFree i-Solutions is one of many companies who are attempting to utilize XPin order to developer software both quickly and efficiently. Since such a key part ofhaving a successful XP project is to use all twelve XP practices simultaneously, aweakness in any one of the practices will have a strongly negative impact. Therefore, itbecomes rather imperative to analyze the current implementation of XP at the company,and, more importantly, identify any shortcomings that exist in order to achieve an idealrealization of XP at CheckFree i-Solutions.4
Executive SummaryThe following report summarizes each of the twelve Extreme Programmingpractices and scrutinizes the implementation of those practices specifically at CheckFreei-Solutions. Deficiencies in the execution of the practices are then explored andelaborated on. The main purpose of the report is to present CheckFree i-Solutions an indepth analysis of their implementation of Extreme Programming in order for thecompany to be able to improve it.Since CheckFree i-Solutions is a company whose primary function is to developsoftware and the entire company is implementing the Extreme Programmingmethodology, the scope of this report touches the majority of the company. Given thatdevelopers, project managers, and project leaders are the ones most affected by thepractices, this report will be of the most relevance to them.The main weakness discovered was CheckFree i-Solutions’ implementation ofpair programming. Although the environment at the company is very cooperative,helpful, and positive, almost no pair programming actually occurs. The main cause ofthis is the individual developer’s resistance to programming in pairs. This inertia issomething that has yet to be overcome with developers at the company. A minor issuethat may be acting as an obstacle to having a successful pair programming environment iseach developer’s cubicle is not very supportive of pair programming.Another prominent flaw was regarding the lack of detail acquired from theplanning game practice. The more detail that is associated with each task the easier thedeveloper and project leader can manage time, make estimations, plan important tasksfirst, and create code easier. It is apparent that some of the tasks defined for a number ofprojects at the company have the potential to contain much more detail than they areoriginally bestowed with.5
Other notable deficiencies were the lack of coding standards across separateprojects within the company, the developers’ unwillingness to refactor code until the endof a project cycle, the absence of an actual on-site customer to work with thedevelopment team, and the fact that the developers at the company must learn to programwith restraint in relation to the simple design practice. Although not as serious as the pairprogramming and planning game shortcomings, the synergy that exists between thetwelve practices is still affected by the aforementioned weaknesses.Although CheckFree i-Solutions has implemented Extreme Programmingadmirably, there are still a number of deficiencies which exist that must be addressed.The pair programming and planning game practices contained the most conspicuousshortcomings. Other weaknesses were discovered in a number of the other practices thathave a negative effect on the Extreme Programming methodology at the company.If CheckFree i-Solutions desires an implementation of Extreme Programming thatis effective and beneficial as possible then pair programming must become a realizationat the company. This can be achieved by assigning tasks in pairs, by encouraging pairprogramming through seminars and by creating a development environment supportive ofpair programming.The planning game practice at the company must yield more detailed tasks. Thiscould be achieved by allocating a significant amount of time to ensure that each taskcontains enough detail to satisfy both the customer and the developer. Although timewill be expended, the results will be better estimation, and easier time management fordevelopers.By ensuring that all the practices are performed optimally, CheckFree i-Solutionswill be able to use the Extreme Programming methodology much more effectively in thedevelopment of software.6
List of FiguresFigure 1.1: Graph of Cost versus Time in an XP project 2Figure 2.2.4.1: Results from Pair Programming Experiment . .6Figure 3.7.1.1: Online Project Tracking Tool 15Figure A.1: Comparison of Cubicle Setups . 227
List of TablesTable 2.2.7.1: Delegation of Responsibilities 78
1. IntroductionEver since the introduction of programming languages in the 1960s, softwareindustrialists have been attempting to discover the most efficient methods and practices tobe utilized in the manufacturing of software. As technological advances continue toescalate in both computing and programming, businesses and consumers are demanding ahigher quality of software products within a shorter amount of time. The business axiomthat time is equal to money still reigns true in today’s high paced, competitive businessworld. Because of that ideology, software companies are sometimes forced to commit todeadlines and, in many instances, the software delivered is not at the level of excellenceacceptable for the standards of today. Other factors that can be attributed to thedegradation of the overall value of software are poor communication, inadequate humanresource management, inaccurate time and cost estimates, and inferior designing andplanning of projects.It is this dissatisfaction with software along with the negative publicity associatedwith software projects that has generated the need for the Software Engineeringdiscipline. Software Engineers must have an advanced understanding of ComputerScience, and be ready to either utilize effective methods of software development orproduce new approaches, should the preexisting ones be deemed incapable of enabling aproject to reach its goals. Software Engineers must harness all their abilities and trainingin order to more efficiently manage the four controllable variables that exist in everyproject: quality, time, scope, and cost [1]. The skill of ensuring that all four variables aremanaged efficiently, and attempting to find a harmonious equilibrium between them, isone of the defining characteristics of a Software Engineer.As the field of Software Engineering continues to expand, so has the number ofdifferent software development methodologies. The increase in performance of bothhardware and software in recent years has only amplified the need for a successfulapproach. If a team is using a development method that is not well suited for the project9
in question, there is a high likelihood that the project will fail. Depending on how faralong in a project a team is, the cost of failure and the waste of resources can be quitedetrimental. Thus, the importance of selecting the correct software strategy becomes aparamount concern for both developers and customer.Until recently, one of the biggest drawbacks of development approaches was theirinability to deal with the exponential relationship between the amount of time the projecthas been underway and the cost of changing software at that point in time. This is whatelevates the Extreme Programming (XP) software development methodology above therest. Kent Beck, one of the founding fathers of XP, has said “ the exponential rise inthe cost of changing software over time can be flattened. If we can flatten the curve, oldassumptions about the best way to develop software no longer hold” [2]. Judging by theamount of developers who utilize XP since he first introduced the idea in the late 1990s,he was correct. Figure 1.1 exhibits the fact that as time progresses in an XP project, thecost of change increases minimally. By employing the XP ideology, it is quite clear thatthe cost of change over time can be greatly reduced.Figure 1.1: Graph of Cost versus Time in an XP project. Taken from [1].10
The advantages of keeping the cost of change low over time are quite profound.The main benefit is that it allows developers to keep designs simple. Less anticipation isrequired for both developer and customer because the expense of not anticipatingsomething becomes much more trivialized. If a feature is not considered essential at acertain moment in time then it can be ignored and, since the cost of developing afterwardis relatively the same as it was before, if the feature does become essential it can beimplemented economically.Being devoted to releasing the best quality software product possible, CheckFreei-Solutions has decided that Extreme Programming is the right software developmentmethod for them. Employees are instructed in many of the practices and principalsrelating to Extreme Programming. Project managers and project leaders are encouragedto lead their teams by following the XP model as closely as possibly. Informationsessions are held in order to inform developers on how to adhere to the XP methodologyand to assist in disposing of old habits that would hinder the success of an XP project.Understandably, as can be expected when attempting to put into practice a systemas involved as XP is, there can be many setbacks and unforeseeable events that occur thatcan make a methodology difficult to implement flawlessly. Issues such as a person’sreluctance to adapt, economic pressures facing the company, a customer’s specific needs,a lack of sufficient resources, and a plethora of others can all be attributing factors tohindering the implementation of a software development method, such as XP.This report will present a summary of the twelve practices that are the veryessence of making an XP project successful. Furthermore, since “The practices supporteach other. The weakness of one is covered by the strengths of others” [2], it followsthat, in order to investigate the XP practice at CheckFree i-Solutions, an analysis of theeffectiveness of each of the twelve practices in the specific context of CheckFree iSolutions is required. Lastly, recommendations will be made regarding possibleimprovements to the way in which XP is implemented at CheckFree i-Solutions.11
2. Background Information2.1The Extreme Programming MethodologyAlthough the concept of XP is relatively new, the basic activities of XP have beenaround since people first began creating software. The fundamental activities of anysoftware development project are coding, testing, listening, and designing [1]. What setsXP apart from other software creation methodologies, and the justification for the nameExtreme Programming, is that XP takes these activities to the extreme via the twelvepractices.2.2Practices of Extreme ProgrammingSimilar to the activities of XP, the twelve practices of XP are not novel, but theway in which they are approached is. Each of the twelve practices is performed in such away that the four basic activities are accomplished as optimally as possible. Whenexamining the twelve practices of XP, it is important to keep in mind that all the practicesmust be performed well in order for an XP project to be successful. Thus, it is rathercrucial that all the practices are executed in order to nullify the shortcomings of anotherpractice. If this is not done, the synergy that exists between the twelve practices will benot as strong as it should be.2.2.1 40-Hour WeekIt is a commonly known truism that the more rested and relaxed a person is, themore focused and driven they are. An employee who is in high spirits and physicallyhealthy will be easier to deal with, more productive, more energetic, and an overallsuperior member of the team. On the other hand, an employee who is over worked andunduly tired can only have a negative effect on the team. They become volatile, easilyfrustrated, unproductive, unenergetic, and a poor member of the team. XP deals with thispossibility by ensuring that employees are well rested and not made to work excessiveamounts of overtime. The practice does not necessarily have an employee work precisely40 hours a week, as the title would indicate, but simply that they do not perform12
unwarranted amounts of work. Overtime is acceptable, but overtime for two weeksstraight is unacceptable [2]. Also, employees should be allowed to take one longvacation, such as two weeks, and a quantity of off days equal to the amount of days of thelong vacation.2.2.2 RefactoringOne of the most prevalent considerations a programmer takes into account whendeveloping code is the level of simplicity. If the code is already completed, than adeveloper will attempt to simplify the code as much as possible, while still maintainingthe exact functionally of the code before the change. This process is known asrefactoring. While most software development methodologies would have refactoring asa single and isolated part of a cycle, the XP strategy has refactoring done on a continualbasis. In XP, refactoring is done in order to eliminate any duplication of code, allowmodularity, and enable future upgrades to be simpler.2.2.3 Small ReleasesSoftware that is being shipped to customers should be done in very small releases.That is, it should be able to be released as a functional, although incomplete, productinstead of only being ready for shipment biyearly or yearly [3]. Development planningshould cover a number of weeks instead of a number of months. This allows planning tobe simplified immensely, and allows for developers to use each release as a way to seehow well they are doing according to schedule. One of the most paramount benefits ofthis XP practice, is it allows customers to continually analyze what the developers aredoing, and since the customers are not dealing with a finished product, any amendmentsthey suggest to the developers should be less onerous to complete.2.2.4 Pair ProgrammingTypically, one of the most neglected practices of XP is pair programming. This isdue to a developer’s reluctance to program in pairs. Pair programming has twodevelopers situated at one computer. The role of one of the programmers is
The pair programming and planning game practices contained the most conspicuous shortcomings. Other weaknesses were discovered in a number of the other practices that have a negative effect on the Extreme Programming methodology at the company. If CheckFree i-Solutions desires an implementation of Extreme Programming that
Extreme Programming John T. Bell Department of Computer Science University of Illinois, Chicago Prepared for CS 442, Spring 2017 2 Sources 1. Wikipedia: Extreme Programming 2. Wikipedia: Extreme Programming Practices 3. Wikipedia: Kent Beck 4. Kent eck and ynthia Andres, “Extreme Programming Explained: Embrace hange”, 2nd Edition 5.
Extreme Programming Extreme Programming (XP) takes commonsense software engineering principles and practices to extreme levels For instance “Testing is good?” then “We will test every day” and “We will write test cases before we code” As Kent Beck says extreme programming takes
Extreme Programming: A Gentle Introduction. Extreme Programming: A gentle introduction. The goal of this site is to provide an introduction and overview of Extreme Programming (XP). For a guided tour of XP follow the trail of little buttons, starting here. Returning visitors can jump to recent changes to see what's new.
Page 1 of 12 EXTREME PROGRAMMING 2.1 Extreme programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development,[1][2][3] it advocates frequent "releases" in short development cycles, which is intended to improve productivity
A majority ofArizona voters say that wildfires (84%), heat waves (79%), and drought (74%) have become at least somewhat more extreme in the past 3-5 years. 38% 36% 29% 36% 26% 43% 21% 55% 16% Drought Heat waves Wildfires Much more extreme Somewhat more extreme Not changed much at all Somewhat less extreme Much less extreme Perceptions of .
Extreme Programming Waterfall model inspired by civil engineering Civil engineering metaphor is not perfect – Software is more organic than concrete – You “grow the software” to meet changing requirements Extreme Programming (XP) addresses this – An iterative model – Recommended reading: “Extreme Software Engineering.
Programming? Extreme Programming (XP) is an agile software development methodology. It is a lightweight methodology combining a set of existing software development practices [5]. XP tends to rapidly develop high-quality software that provides the highest value for the customers in the fastest way possible. Extreme Programming is based on values
Plays are sometimes written from scratch; others are well known. KS3 Dramatic Society Club . of those students currently studying for ABRSM theory exams. Bring your lunch and have a chat. School Choir Large mixed (male and female voices) choir open to all years and abilities, which prepares for major musical events. Senior Jazz Combo Wild and unpredictable band of senior musicians in years .
