sign in sign up
<<
Home , Extreme programming

The Quality of in Extreme Programming Richard Duncan Mississippi State University

Extreme Programming (XP) is a process methodology that nominates writing code as the key activity throughout the development process. While at first glance this sounds chaotic, a disciplined group utilizing XP performs sufficient . This paper describes and evaluates the quality of requirements gener- ated by an ideal group using XP and discusses how the XP process can assist or hinder proper requirements engi- neering.

ent throughout the development, that cus- stories and acceptance tests, while the pro- xtreme Programming (XP) is a hot, tomer can be considered part of the speci- gram parameters are dealt with in release Enew software process methodology for fication since he or she is available to and iteration planning. medium to small sized organizations. It is answer questions and clear up ambiguity. The product parameters are chiefly designed with requirements drift as a fun- The XP life cycle is evolutionary in communicated through stories. These sto- damental occurrence to be embraced, nature, but the increments are made as ries are similar to Use Cases defined in rather than dealing with it as a necessary small as possible. This allows the customer UML, but are much simpler in scope [4]. evil. XP nominates coding as the key activ- (and management) to see concrete Developing a comprehensive written spec- ity throughout the development process, progress throughout the development ification is a very costly process, so XP uses yet the methodology is based on econom- cycle and to respond to requirements a less formal approach. The requirements ics [1]. changes faster. There is less work involved need not be written to answer every possi- presented that the cost in each release, therefore the time-con- ble question, since the customer will of change grows exponentially as the proj- suming stages of stabilization before always be there to answer questions as they ect progresses through its lifecycle [2], releases take less time. With a longer itera- come up. This technique would quickly Stuart Faulk reiterates this by stating that tion time it may take a year to incorporate spiral out of control for a large develop- the relative repair cost is 200 times greater a new idea: with XP this can happen in less ment effort, but for small- to medium- in the maintenance phase than if it is than a week [1]. sized teams (teams of fewer than 20 people caught in the requirements phase [3]. XP A fundamental of XP is testing. The are most often reported) it can offer a sub- challenges that this is no longer the case. customer specifies system tests; the devel- stantial cost savings. It should be noted, While it is more expensive to modify code opers write unit tests. This test code serves however, that an inexperienced customer than to modify a prose description, with as part of the requirements definition – a representative would jeopardize this prop- modern languages and development tech- coded is an unambiguous medi- erty. niques it is not an exponential increase. um in which to record a . XP The programmers then take each story Instead, Beck asserts that the cost for calls for the test cases to be written first, and estimate how long they think it will change levels out. Rather than spend extra and then the simplest amount of code to take to implement it. Scope is controlled effort in the phase to be written to specify the test case. This at this point – if a programmer thinks that nail down all requirements (some of which means that the test cases will exercise all the story, in isolation, will take more than will become obsolete through require- relevant functionality of the system, and two weeks to implement, the customer is ments drift anyway), accept that changes irrelevant functionality should not make it asked to split the story. If the programmers due to incomplete requirements will be into the system [1]. do not understand the story they can dealt with later. XP assumes that lost This paper describes and evaluates the always interact directly with the customer. resources in rework will be less than the requirements engineering processes associ- Once the stories are estimated, the cus- lost resources in analyzing or developing ated with the XP paradigm. tomer selects which stories will be imple- to incomplete requirements 1. mented for the upcoming release, thereby The primary vehicle for requirements The XP Requirements driving development from business inter- elicitation in XP is adding a member of Engineering Process ests. At each release, the customer can the customer’s organization to the team. evaluate if the next release will bring busi- Harwell et al. break requirements into two This customer representative works full ness value to the organization [1]. types – product parameters and program time with the team, writing stories – simi- Each story to be implemented is bro- parameters. A product parameter applies lar to Universal Markup Language (UML) ken up into tasks. A pair of programmers to the product under development, while Use Cases – developing system acceptance will work to solve one task at a time. The a program parameter deals with the mana- tests, and prioritizing requirements [4]. first step in solving a task (after under- gerial efforts that enable development to The specification is not a single monolith- standing, of course) is to write a test case take place [5]. The customer who becomes ic document; instead, it is a collection of for it. The test cases will define exactly a member of the XP team defines both user stories, the acceptance tests written by what needs to be coded for this task. Once product and program parameters. The the customer, and the unit tests written for the test cases pass, the coding is complete product parameters are defined through each module. Since the customer is pres- [1]. Thus the unit tests may be considered

June 2001 www.stsc.hill.af.mil 19 Methodologies a form of requirements as well. Every test attributes. write test cases for it. These test cases (across the entire system) must pass before Unambiguous, Correct, and Under- become a permanent part of the specifica- new code may be integrated, so these unit- standable: Since the customer is pres- tion/test suite. Customers (with the help test requirements are persistent. This is not ent, ambiguity and problems understand- of the XP coach) will also make sure that to say that simple counts as an ing the requirements are generally mini- the specification is verifiable, since they executable specification – but XP’s test- mal and easily solvable [1] . Requirements know that they will have to write test cases for it. driven software development does record are correct if and only if each represents an Annotated by Relative Importance: the specific requirements of each task into actual requirement of the system to be The customer defines which user stories test cases. built. Since the customer writes the stories they wish implemented in each release. The final specification medium for from business interests, the requirements Hence, each requirement is annotated by product requirements is the customer should all be correct. With so much relative importance at this time – the cus- acceptance tests. The customer selects sce- responsibility and freedom, clearly the tomer should ask for the highest-priority narios to test when a has been selection of an appropriate customer rep- stories to be implemented first and pro- correctly implemented. These are black- resentative is crucial to the success of the grammers are never left guessing priorities. box system tests, and it is the customer’s . Even if the customer does not Achievable: Since each release provides responsibility to ensure that the scenarios know exactly what he or she desires at the some business value, a portion of the sys- are complete and that they sufficiently start of the project, the evolutionary tem found to be unachievable should not exercise the system [6]. These acceptance nature of XP development leads to a sys- leave the customer with a very expensive tests serve as an unambiguous determiner tem more in line with the customer’s yet unusable piece of technology. If the as to when the code meets the customer’s needs. high-risk piece is important, it will be expectations. Modifiable: The XP lifecycle allows implemented first, in which case the changes to the requirements specification unachievable component should be found How XP Rates at nearly any point in system develop- quickly and the project aborted relatively The XP requirements engineering process ment. The specification exists as a collec- inexpensively. If it is less important, then can be analyzed by considering the 24 tion of user stories, so the customer can the system may be delivered in useful form quality attributes for software require- switch out one future story for another without it. ments specification (SRS) proposed by with little impact on existing work. Since Design Independent: Design inde- [7]. Davis et al. propose that a quality SRS the planning, tests, and integration are all pendence is a classic goal for requirements, is one that exhibits the 24 attributes listed performed incrementally, XP should but today’s object-oriented development in Table 1. Rather than applying these receive highest marks in modifiability. Of methods recognize that design independ- metrics to a given document, they are used course, work may be lost in this ent requirements are often impractical. here to measure the requirements that the- changeover, but with XP the programmers Portions of the requirements (such as the oretically come out of the XP process. Of should be able to estimate how much a user stories) can be very design independ- course, a quality SRS is mostly dependent change will cost. ent, but the unit tests that are archived as on the discipline used by the people asso- Unambiguous, Verifiable: Since the part of the requirements and used to cross- ciated with the project, but specific fea- customer writes acceptance tests (with the check new modules may depend heavily tures of XP can influence the quality of a assistance of programmers), it could be on the actual system. SRS. argued that the is Electronically Stored: XP calls for the A specification created with XP would recorded in an unambiguous format. stories to be written on index cards, so this appear to score very well across most of Furthermore, the first activity performed portion of the requirements is not elec- these attributes, but fare poorly on others. by a programming pair to solve a task is to tronically stored. While the stories could Those qualities with a “+” symbol indicate Table 1: The 24 Quality Attributes [7] that the subsequent paragraphs argue the XP process can lead to an improvement in the area: a “-” that XP detracts from the quality. The “+/-” annotation indicates that XP partially helps and partially harms a specification in achieving the quality. Many of the qualities are not addressed by XP and are hence annotated with a “?,” for these qualities a group’s organization, dis- cipline, and specific project needs will decide. It should be noted that to reli- giously follow XP requires a great deal of discipline: This discipline should be expected to carry over into the other qual- ities. Following is a look at some of the quality

20 CROSSTALK The Journal of Defense June 2001 The Quality of Requirements in Extreme Programming

be placed in a word processor, Jeffries et al. the XP product – since more money is higher points in nine attributes and lowers assert that handwritten index cards pro- spent on specification, the cost of change the score in two. The most noteworthy duce less feelings of permanence and allow will increase. But if each story were rewrit- gains are in ambiguity and understand- the customer to more freely change the ten in a formal notation it would be possi- ability, since the customer is always pres- system [4]. The customer is also available ble to formally verify the specification and ent to answer questions and clear up prob- as a requirements resource, obviously not design. lems. Furthermore, since the customer is electronically stored. However, the aside, the way an XP also responsible for developing test scenar- requirements are written on individual project progresses does offer many assur- ios he or she will create more verifiable cards so modifications can often be local- ances of trust. First, all code is written requirements. The discipline enforced by ized to a single card if rewriting is neces- directly from the user stories (the specifi- the XP process should also carry over into sary. Furthermore, the customer codifies cation). All functionality is tested in the other areas of requirements engineering.◆ the system requirements with acceptance unit tests and all integrated code is tests, so it could be argued that the most required to pass all tests all the time. Notes important part of the specification is While testing does not guarantee the 1. XP has been used on several . stored. absence of errors, many security holes Beck mentions a campaign manage- Complete, Concise: XP stresses program- come from poorly tested software. Hence, ment database, a large-scale payroll sys- ming as the most important development the test-oriented nature of XP may be a tem, a cost analysis system, and a ship- activity, hence little effort is spent on cre- great step forward. ping and tariff calculation system in [9]. ating documents, therefore the specifica- A strong security feature of XP is pair Yet there is little objective data available tion is very concise. The cost may be a lack programming. The observer in a pair con- for analysis at this time. More data of completeness, however. Since little up stantly evaluates the code being written by should be made available through the front analysis takes place, there may very his or her partner. This programmer can upcoming XP Universe Conference, well be holes in the system. Yet the cus- help reduce the probability of coding Raleigh, NC, July 2001, www. tomer drives what functionality is imple- errors that might later be exploited (e.g., xpuni verse.com mented and in what order, so true func- buffer overruns). XP also adds counterbal- 2. An unsolicited, undocumented piece of tionality should not be left out. ances to reduce the impact of a single code a programmer inserts into soft- Furthermore, since the XP process accom- malicious coder (either in a truly malevo- ware, generally for his or her own modates change, it should be possible to lent sense or inadvertently opening holes amusement. compensate for these holes later in the as Easter Eggs2 side effects) through the development lifecycle. pairing process. Rather than just inserting References code into the system, one programmer 1.Beck, Kent, Extreme Programming Security Assurances would have to convince the other of a Explained: Embrace Change, Boston, Since the XP development methodology rationale for why the code was being Addison Wesley, 2000. does not progress from a verified require- inserted. Due to collective code owner- 2.Boehm, Dr. Barry, Software Engineering ments document, how might a system ship, it is entirely possible that the next Economics, Prentice Hall, 1981. developed with XP rate on a security eval- pair in the course of re-factoring would uation? The Common Criteria has seven catch malicious code. Pair programming 3.Faulk, Stuart, : A evaluation assurance levels (EAL1-EAL7). and collective code ownership add further Tutorial, Software Engineering, IEEE For EAL5 and above the Common assurance that the code is written exactly 1996, pp. 82-103. to the specification. Evaluation Methodology calls for the sys- 4.Jeffries, Ron; Anderson, Ann; and tem to be semi-formally designed and test- Conclusions Hendrickson, Chet, Extreme ed [8]. This leaves two questions to be Programming Installed, Boston, Addison addressed. First, can a project use formal XP performs requirements engineering Wesley, 2001. methods with XP? Second, without formal throughout the life cycle in small informal methods, how trusted can a system devel- stages. The customer joins the develop- 5.Harwell, Richard; Aslaksen, Erik; oped under XP be? ment team full time to write user stories, Hooks, Ivy; Mengot, Roy; and Ptack, The XP process screams informality in develop system acceptance tests, set prior- Ken, What is a Requirement? many respects. The name alone conjures ities, and answer questions about the Proceedings, Third Annual images of snowboarders with laptops, and requirements. The stories are simpler in International Symposium National even the books about XP are written in a scope to use cases because the customer Council , 1993, conversational tone. Nevertheless, what need not answer every conceivable ques- pp. 17-24. would happen if the customer writes sto- tion. The informal stories are then trans- 6.Wells, J. Donovan, Extreme Program- ries and they are annotated with a formal lated into unit and system acceptance ming: A Gentle Introduction, specification? Clearly, this would entail a tests, which have some properties of an www.ExtremeProgramming.org 2.75 large cost in training personnel, writing executable specification. the specifications, and verifying the speci- Of the 24 quality attributes of a soft- fications. This also reduces the agility of ware specification, the XP process leads to Continued on page 31

June 2001 www.stsc.hill.af.mil 21 Continued from page 21 BACKTALK 7.Davis, Alan; Overmyer, Scott; Jordan, Have We Lost Our Focus? Kathleen; Caruso, Joseph; Dandashi, Fatma; too big for me to understand, I had to use Dinh, Anhtuan; Kincaid, Gary; Ledeboer, aving recovered from a wonderful some tool to help me understand and par- Glen; Reynolds, Patricia; Sitaram, Pradhip; Hcase of laryngitis, I just got back Ta, Anh; and Theofanos, Mary, Identifying and from a great Software Engineering Process tition the problem. Measuring Quality in Software Requirements Group conference in New Orleans. A I eventually became both a computer Specification, Proceedings of the First International great time was had by all. Between the scientist and later, a . Software Metrics Symposium, 1993, pp. 141-152. SEPG conference and reviewing papers Over the years, I went from flowcharting for this issue of CrossTalk, I am totally up-to Top Down Structured Design (TDSP); 8.Common Criteria, International Standard (IS) to-date on the latest and greatest in Hierarchical Input, Process, Output 15408, csrc.nist.gov/cc/ccv20/ccv2list.htm, (HIPO); and September 2000. methodologies. Back in 1969 I started my life as a pro- Structured Design (SASD); Transform 9.Beck, Kent, Embracing Change with Extreme grammer/developer/computer Analysis (TA); Object-Oriented Modeling Programming, Computer, October 1999, pp. scientist/software engineer. (As you get and Design (OOMD); Unified Modeling 70-79. promotions, you don’t just get pay raises. Language (UML); and Unified System You get neater and spiffier job titles, too!). Development Process (USDP). I tried to About the Author I first learned to program a Wang pro- become a Certified Data Processor Richard Duncan is pursuing grammable calculator in junior high – a (CDP). I earned degrees from institutions a master’s degree in comput- gift to the school from a local company that are Accreditation er science at Mississippi State that needed a tax break. At that time the Board-compliant (CSAB). I studied the University (MSU) with calculator was the size of a desk and filing Software Engineering Body of Knowledge emphasis in software engi- cabinet with (a whopping) 256 bytes of (SWEBOK). I learned lots of acronyms neering. He has held sum- memory, a paper tape reader, and a single and new methodologies – new method- mer internships at Microsoft, AT&T Labs punch card input. Not a deck of cards, ologies? You know, when I first saw activi- Research, and NIST. His current research mind you, but a single card: punched by ty diagrams and sequence diagrams in interests involve applying software-engineer- hand, 80 columns, 12 rows. UML and USDP, I felt right at home. I ing process to the development of a public There were only 61 possible instruc- had come full circle. I was flowcharting again! domain speech recognition system at the tions in the Wang instruction set, so each It’s never been about the methodology. Institute for Signal and Information column in the punched card could encode two six-bit operations. Therefore, each Methodologies are simply techniques and Processing at MSU. card could contain 160 instructions. To tools to help you partition and understand gain admission to the “Computer Science the problem. Here’s a kernel of truth – you Mississippi State University Club,” you had to be able to program the can’t design a system (let alone code it) P.O. Box 9571 unless you understand what the system is Mississippi State, MS 39762 quadratic equation on a single card. Voice: 662-325-8335 (Remember ax 2 + bx + c = 0, given a, b, supposed to do. The methodologies are Fax: 662-325-2292 and c, solve for x?) Once you accom- there to assist me. They are NOT ends in E-mail: [email protected] plished this Herculean task, why, you were themselves – they are simply a means to considered a programmer! the end. You have to focus on the larger Letter to the Editor I remember how smart I felt after picture – getting the system “out the door” Editor: accomplishing this task. I was a hacker, a on time. It’s not enough to be an expert in member of the brotherhood/sisterhood! I the latest and greatest methodology, unless Just a note to let you know the could code! We didn’t use a methodology you can also use it to help produce a sys- address for the SPI EGroups web site you reference on page 19 of March’s – design was for wimps! I remember trying tem on time and under budget. The CrossTalkneeds to be updated. Yahoo to explain to my girlfriend about what I methodology has to make you more pro- recently took over eGroups so the address had accomplished. (This might explain ductive. If a methodology helps, use it! If is now http://groups.yahoo.com/ why I didn’t date much during school). it doesn’t, get a better methodology! Focus group/spi Fortunately, I matured in my profes- on the ends, not the means. I am the creator, owner, and modera- sion. I joined the Air Force and had to And – if all else fails – try drawing a tor of this group, and just out of curiosi- learn how to design. As my first design flowchart. It might make you feel SMART ty, was wondering how you came about including it in this issue. I’m very pleased methodology, I flowcharted my code. Of again! to see it there! course – as a true hacker – I knew that if I finished the code first, the flowcharting Thanks, was much easier. I was lucky – I had a wise David A. Cook Maj. Andrew D. Boyd and tolerant boss who showed me that Principal Engineering Consultant Chief, Assurance flowcharting was a requirements and Shim Enterprises, Inc. Section design tool. That when the problem got [email protected] USAF

June 2001 www.stsc.hill.af.mil 31