SOFTWARE ENGINEERING CSC 423 B - MWF 11-12 EXTREME PROGRAMMING

SOFTWARE ENGINEERING CSC 423 B - MWF 11-12 EXTREME PROGRAMMING TO: Dr. Khaldoun El Khalidi FROM: Lamia Nassif, Jessy, Nadine Ghanem, & Pedro Maroun Eid Due: 20 March 2002 1

Table of Contents I. ABSTRACT...3 II. TECHNICAL INVESTIGATION...4 A. Principles...4 B. Practices...4 C. The Process...6 III. RUP vs. XP... Error! Bookmark not defined. IV. REFERENCES...16 2

EXTREME PROGRAMMING I- ABSTRACT Extreme Programming, or XP, is a lightweight discipline of software development based on values of simplicity, communication, feedback, and courage. It was developed by Kent Beck in 1996 who wrote the original book on the subject, Extreme Programming Explained. XP is designed for use with small teams who need to develop software quickly in an environment of rapidly changing requirements. [1] It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation. Extreme Programming challenges many common assumptions about software development. One of the most controversial is its rejection of significant effort in upfront design, in favour of a more evolutionary approach. To its detractors, this is a return to "code and fix" development usually derided as hacking. To its fans, it's often seen as a rejection of design techniques, principles and patterns. [3] 3

II- TECHNICAL INVESTIGATION A- Principles: Extreme Programming rests on the values of simplicity, communication, feedback, and aggressiveness, which are considered as The Four Commandments of Extreme Programming (XP). [2] SIMPLICITY means that the software is developed using the simplest possible design and constructs, but it means more: simplicity pervades the entire process. XP eliminates, as much as possible, the unnecessary elements of building software. One of our rules is You aren t going to need it, which reminds us to add software or process only when we really need them, not in anticipation of need. COMMUNICATION is key to rapid development and to customer satisfaction. XP embodies communication with a focus on simplicity: Use person-to-person communication instead of written documents wherever possible. It also stresses continual communication between the customer and development team members by having an on-site customer while development progresses. The on-site customer decides what will be built and in what order. FEEDBACK is important to any development process, but when you are trying to eliminate everything you can, you need feedback to be sure you re on track. Software testing is a major source of quality feedback in XP, but we include resource, scope, and time feedback as well. AGGRESSIVENESS (or courage) in moving forward is possible when you take the simplest possible approach and employ a process high in communication and feedback. In other words, doing the right thing even when it is not the most popular thing to do. It means being honest about what you can and cannot do. B- Practices: Twelve XP practices support the four values. These practices tend to keep the team on track while they build up a grasp of the principles that form the basis for the practices. In XP, every contributor to the project is an integral part of the whole team formed around a business representative the Customer. There are twelve XP practices that the team should depend on when adopting XP. i. The Planning Process, sometimes called the Planning Game: The XP planning process allows the XP "customer" to define the business value of desired features, and uses cost estimates provided by the programmers, to choose what needs to be done and what needs to be deferred. The effect of XP's planning process is that it is easy to steer the project to success. There are two planning steps in XP: The Release planning: a practice where the customer presents the desired features to the programmers in the team who in return estimate their difficulty. Iteration planning: a practice whereby the team is given direction every couple of weeks building a software in 2-weeks iterations and delivering running useful software at the end of each iteration. 4

ii. Small Releases: XP teams put a simple system into production early, and update it frequently on a very short cycle. The team releases running, tested software, delivering business value chosen by the Customer, every iteration. The most important aspect is that the software is visible, and given to the customer, at the end of every iteration. This keeps everything open and tangible. iii. Testing, also known as customer tests: XP teams focus on validation of the software at all times. Programmers develop software by writing tests first, then software that fulfils the requirements reflected in the tests. Customers provide acceptance tests that enable them to be certain that the features they need are provided. The best way for success is that once the test runs, the team keeps it running correctly thereafter. iv. Metaphor: XP teams develop a common vision of how the program works, which we call metaphor. In other words they use a common "system of names" and a common system description that guides development and communication. v. Simple Design: A program built with XP should be the simplest program that meets the current requirements. There is not much building "for the future". Instead, the focus is on providing business value. Of course it is necessary to ensure that you have a good design. There are design steps in release planning and iteration planning, plus teams engage in quick design sessions and design revisions through refactoring, through the course of the entire project. In an incremental, iterative process like Extreme Programming, good design is then essential. That's why there is so much focus on design throughout the course of the entire development. vi. Refactoring, or design improvement: Extreme Programming focuses on delivering business value in every iteration. To accomplish this over the course of the whole project, the software must be well designed. This is done by keeping the software clean: without duplication, with high communication, simple, yet complete. Refactoring is, of course, strongly supported by comprehensive testing to be sure that as the design evolves. Thus the customer tests are a critical enabling factor. The XP practices support each other: they are stronger together than separately. vii. Pair Programming: XP programmers write all production code in pairs, two programmers working together at one machine. This practice ensures that all production code is reviewed by at least one other programmer, and results in better design, better testing, and better code. In fact, many experiments have shown that pair programming produces better software at similar or lower cost than programmers working alone. viii. Collective Code Ownership: All the code belongs to all the programmers. This lets the team go at full speed, because when something needs changing, it can be changed without delay, which increases code quality and reduces defects. ix. Continuous Integration: XP teams integrate and build the software system multiple times per day. This keeps all the programmers on the same page, and enables very rapid progress. Perhaps surprisingly, integrating more frequently tends to eliminate integration problems that plague teams who integrate less often. 5

x. Sustainable Pace sometimes known as 40-hour week: XP programmers work hard and at a pace that can be sustained indefinitely. This means they do not work overtime, unless it s effective, keeping themselves fresh, healthy, as to reduce as much as possible mistakes. xi. On-site Customer: An XP project is steered by a dedicated individual who is empowered to determine requirements, set priorities, and answer questions as the programmers have them. The effect of being there is that communication improves, with less hard-copy documentation - often one of the most expensive parts of a software project. xii. Coding Standard: For a team to work effectively in pairs, and to share ownership of all the code, all programmers need to write the code in the same way, with rules that make sure the code communicates clearly. C- The Process: As all other software engineering methods, the process in XP is similar to the process used elsewhere. In fact, we can divide the above discussed practices into four clear progressions that are the planning, the design, the coding and the testing. i. Planning: The Onsite Customer participates in the Planning Game. The development team interviews the customer to determine user stories about how the system will work. User stories are combined or split to come up with a story that can be described on a CRC Card, and completed by a pair of programmers during one release cycle (typically about three weeks). The customer prioritizes the cards according to the business value of the user stories, which puts stories into the release schedule based on the development resources available. This lets customers have an accurate commitment schedule. After each release, the customer has a system that works according to the stories completed so far; they don't have to wait for the whole thing to be done to start using the initial functionality. The development group identifies which stories are risky to complete on time (mainly because of a lack of experience with that type of coding) and does worst things first based on a spike solution. 6

ii. Designing: XP relies on test driven development for its inner loop. This pumps the outer loop, and makes the political end of XP possible. Promises are automatically kept. Unit tests are written which the successful software will be able to pass. At first, the tests fail because the software hasn't been written yet. A simple design is developed by doing the simplest thing which might pass the tests. Big-design-up-front is avoided because you are not going to need it. However, once the simplest thing is done the programmers refactor (combine similar code) mercilessly, because in the end things should be expressed once and only once. iii. Coding: XP involves pairs of programmers working together on code, so that the entire development team achieves Code Stewardship. Code Stewardship is the opposite of Code Ownership, emphasizing that code is the team's property, and not the sole province of any one person or pair. Programmers should code Unit Tests first. This Pair Programming leads to Collective Code Ownership. Programmers follow the coding conventions (standards) whenever they write new code, and while they refactor mercilessly. The customer should always be available upon the coding phase; this is to ensure that the code is being written as the customer wants. The written code should be integrated often, typically each day. Code should be optimized as it is written; there should be no need for revision afterwards. Coding should be done according to the corresponding user stories written in the order that the customer informs. Each story is written stand alone and at the end of the day integrated into the rest of the project. Programmers or coders should work no more than 40 hours a week, this is to always be sure that these programmers are always giving out their best. Basically, No overtime should be allowed. 7

iv. Testing: Extreme Testing includes Unit Tests for all code, creating tests when bug is found, and running Acceptance tests often and publishing the scores. Extreme Testing is the best way to survive extreme change. With extreme testing you can develop software more quickly, with more confidence, and with higher quality. Extreme Testing includes two basic tests: unit tests and functional tests. 1- Unit Tests Unit Tests let developers evolve the system rapidly and with confidence. Developers have to learn how to build the system, and customers have to learn what they really want so that we can build the software and change it quickly. We should be sure that the code is well-factored so that we can easily transform yesterday's code into what we need tomorrow. Unit Tests specify two key actions: a. To be sure that new features work, write Unit Tests for every feature. Write them before you write the code and save all the Unit Tests for the whole system. b. To be sure that nothing is broken, run all the Unit Tests in the entire system before any code is released, and ensure that those tests run at 100% because if anything breaks you will know exactly where the problem is. When every Unit Test in the entire system is running 100% that shows us not just that the new feature works, but that the changes haven't broken anything anywhere. 2- Functional Tests Functional Tests are tests that check each increment to see if the value is there. These tests give customers and developers confidence that the whole product is progressing in the right direction. Customers need confidence to keep putting up the money and time. This confidence comes from seeing the system actually do what is being paid for. Here are the key dimensions of Extreme Functional Tests: c. Customer-owned: customers should understand the tests to get confidence from them. d. Comprehensive: customers should pick values where the test will have meaning if it succeeds and if it fails. e. Repeatable: developers should write new tests when you do a new increment. f. Automatic: developers should have a testing facility to set up and run 8

the tests, check the results, and report them. g. Timely: If the tests do not show up until weeks after the development is done, it just slows things down. h. Public: customers need to see progress in the software development, so if there is a decline in test scores the developers should not ignore that. Graph 2.1 can tell almost the complete story of quality. We can see the test status at the end of each development increment. The yellow band says that there are problems in getting validated answers. Then, as validated answers started to come along, we see that the system is making a lot of errors. In increment eight, quality took a big step upward, and has improved. Finally, in increment twelve, all the data values are validated, and there has been a healthy project, and we can have great confidence in the quality of the system. Graph 2.1 9

III- A Comparison: RUP VS XP Rational Unified Process (RUP) is a process framework, refined over the years by Rational Software and is being widely used on a variety of software projects, from small to large. Extreme Programming (XP) is a software development approach gaining increasing recognition as an effective method for building smaller systems in an environment of changing requirements. Most processes have some common elements that make a systematic comparison possible. They require sequences or groups of activities, which are performed by roles (usually played by people working as individuals or teams) to generate artifacts or work products, some or all of which are delivered to a customer. Most processes also acknowledge that instances of the process will have a time dimension, with a beginning and an end, and interesting intermediate milestones that represent the completion of significant activities (or clusters of activities) and the production of associated artifacts. [4] The purpose of this comparison is to clarify the relative positions of RUP and XP in the process spectrum to see what each can offer the other and to dispel the notion that XP is a lightweight, and therefore desirable, alternative to the heavyweight RUP. The dimensions of process that make the comparison between RUP and XP are the following: Time and Effort Allocation: It discusses how each process is arranged over time and how the staffing effort allocation compares. Artifacts: It compares the work products; those things produced in the course of an XP and RUP based project. Activities: It discusses the way in which each process says its artifacts should be produced. Disciplines: It compares the way in which XP and RUP delineate the major areas of concern in software engineering. Roles: It explores the differences between roles (that perform activities) in the RUP and roles that are closer to positions within a team in XP. Time and Effort Allocation RUP deals with projects whose lifespan is divided into phases named Inception, Elaboration, Construction, and Transition. Each phase is further split into iterations and each iteration may require several builds. For most projects in RUP, the duration of an iteration will be between two weeks and six months, and the number of iterations in a project s lifetime will be between three and nine. So at these default settings, RUP covers projects ranging in duration from six weeks to 54 months. [4] XP s iterations are about two weeks in duration. XP s releases are two months (or slightly longer); they are defined by the customer and released to the customer. In duration, XP s releases are like RUP s iterations, during Elaboration or Construction at least, for projects with a maximum team size of 10 that are based on an established architectural baseline. [4] 10

Artifacts RUP describes over 100 artifacts, which has led to the criticism that it imposes an intolerable bureaucratic overhead for small projects. This view is incorrect on four counts: Projects don t have to produce all artifacts: selecting and tailoring artifacts is a necessary part of the process. RUP provides guidelines on what can be omitted and what can be tailored. An artifact (in RUP, an artifact description) is a specification entity that specifies the information to be produced by an activity and, to do this systematically, it may describe the abstract form of an artifact. The RUP characterization of artifacts as models, model elements, or documents is not intended to imply a particular realization. A UML model could be captured and presented using a purpose-built tool (such as Rational Rose), or, at the other extreme, as diagrams made by using a simple graphics tool, or even as a sketch on a whiteboard. RUP documents are information sets composed of text and diagrams. To be useful, RUP specifies what this information should be, and a convenient and systematic way to do this is to point to a template, which enumerates and describes the items and issues to be considered. It s certainly possible to use these templates in a direct and formal way to realize the artifacts in document form that is, electronic or paper. Not everything presented in a template is necessarily relevant to a particular project and RUP gives a project the freedom to choose any appropriate realization for an artifact. The important thing is the information it contains. XP seems to be immune from the criticism of being artifact-heavy, but this is an oversimplification for two reasons: XP is already tailored to suit a certain kind of development; dealing with a subset of the RUP disciplines at a certain scale and so would be expected to call for fewer artifacts. XP emphasizes the importance of user stories and code, but other things that are work products are mentioned in passing when describing the process, so the artifact count is not as small as it appears at first sight. Here are some examples of artifacts: Stories Constraints Tasks Technical tasks Acceptance tests Software code Releases Metaphors The design CRC, UML sketch Design documents produced at the end of the project Coding standards Unit tests Workspace (development and other facilities) Release plan Iteration plan Reports and notes on any meetings Overall plan budget Reports on progress 11

Story estimates Task estimates Defects (and associated data) Additional documentation from conversations Supporting documentation Test data Testing framework tools Code management tools Test results Spikes (solutions) Task work time records Metrics data - Resources - Scope - Quality - Time Other metrics Tracking results There we have around 30 artifacts, some of which are composites too. The list is intended to be indicative, not exhaustive. Once a project has to realize them, more detail of their content and form will be needed. A project can certainly do that on the fly, but that takes time away from the real work; in contrast, RUP provides up-front guidance, thereby saving the project time. [4] The reasons for which XP does not need all the RUP artifacts are the following: 1- XP is about programming to meet a business need. How that business need occurred, and how it s modeled, captured, and reasoned about, is not XP s main concern. 2- XP asserts that requirements and design capture can be done rather simply. 3- RUP allows for a greater formality in project management, where this is necessary, and in some contract arrangements it will be. Many of RUP s project management artifacts are part of composite artifacts, and need only be realized as separate documents when the formality of the project demands it. Activities RUP formally defines the term activity as work performed by a role, using and transforming input artifacts, and producing new and changed output artifacts. RUP then goes on to enumerate these activities and categorize them according to discipline or major area of concern within project. [4] These disciplines are: Business Modeling Requirements Analysis & Design Implementation Test Deployment Configuration & Change Management Project Management Environment Activities are time-related through the artifacts that they produce and consume: an activity can logically begin when its inputs are available. This means that producer- 12

consumer activity pairs can overlap in time, if the artifact state permits; they need not be rigidly sequenced. Activities in RUP are intended to make the intellectual process of producing an artifact less opaque, to give some strong guidance on how something should be produced. Activities may also be used to help the project manager with his or her planning. Woven through the RUP as it s described in terms of lifecycle, artifacts, and activities, are the best practices : software engineering principles proven to yield quality software built to predictable schedule and budget. [4] The RUP, through its activities and their associated artifacts, supports and realizes these best practices they are themes running through the RUP. XP presents an engagingly simple view of software development as having four basic activities that are to be enabled and structured according to some supporting practices: Coding Testing Listening Designing Actually, XP s activities are closer in scope to RUP s disciplines than to RUP s activities, and much of what happens on an XP project (in addition to coding, testing, listening, and designing) will come from the elaboration and application of its practices. RUP s apparent prescription comes from its completeness and greater formality in its systematic treatment of activities, and their inputs and outputs. XP does not lack prescription, but perhaps in the attempt to remain lightweight, the formality and detail are simply omitted. The detail that is present in RUP will have to be added when XP is implemented on a project. Lack of specificity is not a strength or a weakness, but we should not confuse the lack of detailed information in XP with simplicity. At some point, the people on the project will need to know what to do and at that time will need the detail. [4] Disciplines and Workflow A discipline in RUP is the collection of activities and associated concepts producing a particular set of artifacts, which represents some important aspect or concern in software development. RUP s disciplines are Business Modeling, Requirements, Analysis & Design, Implementation, Test, Deployment, Configuration & Change Management, Project Management, and Environment. This does not cover every aspect of what an organization or business might do when employing people to develop, deploy, operate, support, sell, market, or otherwise deal with systems that are largely software. RUP currently does not cover Systems Engineering or all of the requirements of some international software process standards such as ISO 15504 since they are outside its engineering focus. [4] XP explicitly restricts itself even further. It includes four basic activities coding, testing, listening, and designing performed using a set of practices, which requires performing other activities that map to some of the other disciplines in RUP. The XP s practices are: 13

The Planning Game: Quickly determine the scope of the next release by combining business priorities and technical estimates. As reality overtakes the plan, update the plan. Small Releases: Put a simple system into production quickly, and then release new versions on a very short cycle. Metaphor: Guide all development with a simple shared story of how the whole system works. Simple Design: The system should be designed as simply as possible at any given moment. Extra complexity is removed as soon as it is discovered. Testing: Programmers continually write unit tests, which must run flawlessly for development to continue. Customers write tests demonstrating that features are finished. Refactoring: Programmers restructure the system without changing its behavior to remove duplication, improve communication, simplify, or add flexibility. Pair programming: All production code is written with two programmers at one machine. Collective ownership: Anyone can change any code anywhere in the system at any time. Continuous integration: Integrate and build the system many times a day, every time a task is completed. 40-hour week: Work no more than 40 hours a week as a rule. Never work overtime a second week in a row. On-site customer: Include a real, live user on the team, available full-time to answer questions. Coding standards: Programmers write all code in accordance with rules emphasizing communication through the code. Activities performed as a result of the practice The Planning Game, for example, will mainly map to RUP s Project Management discipline. However, some topics are outside the scope of XP such as Business Modeling. Requirements elicitation is largely outside the scope of XP the customer defines and provides the requirements. Deployment of the released software is outside the scope of XP too. Because of the scale and types of development it addresses, XP can deal very lightly with issues in Environment and Configuration & Change Management disciplines that the RUP covers in detail. In the disciplines in which XP and RUP overlap, some of the practices described in XP could be employed in RUP and others could not. The following table distinguishes between these practices: XP practices that scale Pair Programming Test-first design and refactoring On-site customer Coding standards Continuous integration XP practices that do not scale Collective ownership Refactoring Metaphor Rapid releases Simple design 40-hour week 14

Roles In RUP, activities are performed by roles. Responsible roles will usually create the artifact and ensure that any changes made by other roles (if such changes are allowed), do not break the artifact. A role in RUP may be performed by an individual or by a group of people. Equally, an individual or a group may perform several roles. A role does not have to be mapped to a single position or slot in an organization; the mapping of roles to organizational units may also be many-to-many. RUP defines a total of 30 roles. There is not an exact mapping to disciplines since a role such as a software architect is not necessarily confined to one discipline, for example: Business Modeling has three roles Requirements has five roles Analysis & Design has six roles Implementation has three roles Test has two roles Deployment has four roles Configuration & Change Management has two roles Project Management has two roles Environment has three roles Roles in RUP are used to partition activities, and to finely discriminate the skills and competencies needed to perform the role, which helps guide the selection of staff to perform the roles. The level of division also facilitates the identification of new organizational positions when the importance of a role changes. For example, on a small, informal project, the role of Project Manager and Configuration Manager (RUP roles) may well be performed by the same individual. By describing roles in this way, RUP facilitates this mapping. [4] XP defines seven applicable roles with their responsibilities, the skills, and the traits required of the people who will perform them. These roles are: Programmer Customer Tester Tracker Coach Consultant Big Boss The difference in the number of XP and RUP roles is easily explained: XP is not covering all of the RUP disciplines. XP roles are actually closer to positions than RUP roles; for example, XP s programmer actually performs multiple RUP roles those of Implementer, Integrator, and Code Reviewer and these require slightly different competencies. When RUP roles are mapped to a small project, the number of XP-like roles that are mapped reduces considerably from 30. [4] 15

REFERENCES [1] Ronald E. Jeffries, What Is extreme Programming, Extreme Programming Magazine, August 2001. [2] Ronald E. Jeffries, extreme Testing, Software Testing & Quality Engineering (STQE) Magazine, March /April 1999. [3] Martin Fowler, Is Design Dead, Software Development (SD) Magazine, April 2001. [4] John Smith, A Comparison of RUP and XP, Rational Software White Paper, 2001. 16