328 Chapter 25 ■ Open source software development 25.1 Can you think of any situations or products for which the open source procedure might be most appropriate? 25.2 Can you think of examples of situations in which open source development of prod- ucts might be unwise? 25.3 Assess whether open source would be suitable for each of the developments given in Appendix A. 25.4 Compare and contrast the approaches of the Free Software Foundation and the Open Source Movement. 25.5 Is open source development just hacking? Exercises • Answers to self-test questions 25.1 Reliable software. 25.2 Yes. 25.3 Code sharing. 25.4 The internet. This book provides a rare insight into the history of hacking, from its origins at MIT in the 1950s to the rise of open source software: S. Levy, Hackers: Heroes of the Computer Revolution, Anchor Books, 2002. The following title is a comprehensive collection of essays covering topics from licens- ing issues to the engineering of such major open source products as Mozilla and Perl: Open Sources: Voices from the Open Source Revolution, C. DiBona, S. Ockman and M. Stone, O’Reilly, 1st edn, 1999. This is a very accessible book which depicts the development of the GNU/Linux Operating System, including interviews with major contributors in the open source field: G. Moody, Rebel Code: Inside Linux and the Open Source Revolution, Perseus Publishing, 2001. This is a response to Fred Brooks’s seminal proprietary software development text The Mythical Man Month (1974). Raymond argues why the open source approach to software development will provide a higher-quality product: E.S. Raymond, The Further reading • BELL_C25.QXD 1/30/05 4:27 PM Page 328 Further reading 329 Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary, O’Reilly, rev. edn, 2001. Primarily focusing on the life and moral crusade of Stallman, this text also describes the development of GNU project and other projects of the Free Software Foundation: S. Williams, Free as in Freedom: Richard Stallman’s Crusade for Free Software, O’Reilly, 2002. SourceForge.com is a website that coordinates open source development projects. If you want to contribute to projects, this is the place. The URL is http://www.sourceforge.net A social scientist’s view of open source development, showing how it challenges con- ventional wisdom: Steven Weber, The Success of Open Source, Harvard University Press, 2004. BELL_C25.QXD 1/30/05 4:27 PM Page 329 Agile methods is a term that embraces a number of techniques that share common prin- ciples. These principles are articulated in what is called the agile Manifesto. The principles emerged from an analysis that older methods (referred to as heavyweight) were simply too big and unwieldy; that there was a need to use more lightweight approaches to develop- ment. These new methods explicitly recognize that software development is primarily about individual skill and communication between people (between developers and with the clients). One of the best-known of the methods is named extreme programming (XP), but others are DSDM, SCRUM, Crystal and FDD. The manifesto begins with a statement of four core values: 1. individuals and interactions over process and tools 2. working software over comprehensive documentation 3. customer collaboration over contract negotiation 4. responding to change over following a plan. 26.2 ● The agile manifesto 26.1 ● Introduction CHAPTER 26 Agile methods and extreme programming This chapter explains: ■ the principles behind agile methods ■ the practice of agile methods ■ the principles behind extreme programming ■ how to carry out extreme programming. BELL_C26.QXD 1/30/05 4:27 PM Page 330 These are qualified by the statement that while there is value in the items on the right, the items on the left are valued more. Thus agile methods do not throw out the baby with the bath water; they simply give precedence to certain choices. The first value recognizes that individual creativity and group collaboration are more effective than following a prescriptive methodology. The second value recognizes that software is code, not the accompanying documentation. The third value recognizes that a good relationship between the clients and the developers is more important than arguing about contracts. The fourth value prioritizes users’ changing needs rather than adhering to some meaningless inflexible plan. Twelve supporting “statements” give guidance on achieving the four core values: 1. our highest priority is to satisfy the customer through early and frequent delivery of software 2. deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale 3. working software is the primary measure of progress 4. welcome changing requirements, even late in development 5. business people and developers work together daily throughout the project 6. build projects around motivated individuals. Give them the environment and sup- port they need, and trust them to get the job done. 7. the most efficient and effective method of conveying information to and within a development team is face-to-face conversation 8. the best architectures, requirements and designs emerge from self-organizing teams 9. continuous attention to technical excellence and good design enhance agility 10. agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely 11. simplicity – the art of maximizing the amount of work not done – is essential 12. at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. We shall see how these can be put into practice shortly, when we look at extreme programming. Tools for agile methods Many people believe that appropriate software tools are vital to successful software projects. Agile methods take an independent attitude to tools and use whatever tools are useful, particularly the simplest tools available. This might mean a computer aided software engineering (CASE) tool but it also includes non-computer tools. Here are examples. Sketches can be made on paper, using color as appropriate for all sorts of diagrams, informal and more formal (such as UML diagrams). A scanner or digital camera can record the results for computer storage. 26.2 The agile manifesto 331 BELL_C26.QXD 1/30/05 4:27 PM Page 331 A whiteboard and colored pens are useful for drawing diagrams, such as use case dia- grams, class diagrams, user interface mock-ups and also informal sketches. It is easy to change the diagram, and it can be viewed collaboratively and discussed by a group of people. A digital camera is a convenient way of capturing the information on a whiteboard. Index cards and a large table are useful for designing the class structure of software, using CRC (Class–Responsibility–Collaborator) modeling (see Chapter 11). The cards can easily be moved around, changed or removed. Again a digital camera can record the end product. Sticky notes can be used with a whiteboard or a large sheet of paper to create dia- grams during design. Simple tools such as those mentioned are cheap, portable, quick to use, flexible, assist collaborative working and can be used for communication with the user. On the other hand, simple tools can be limited, are not amenable to computer-assisted check- ing and do not support distributed working. This is perhaps the best-known of the agile methods. Its name conveys something dan- gerous and foolhardy, but this is far from true. The name instead denotes a radical per- spective which is a contrast to heavyweight methods. Centrally, extreme programming (XP) recognizes that requirements continually change and the method embraces the changes, rather than considering them to be disruptive. Before we look at the values of XP and its full set of techniques, we will explore its principal approaches. In XP, the client (or a representative) is always present as a member of the development team. This person writes use cases, termed stories in XP. (We met these in Chapter 4 on requirements engineering.) A use case is a small individual function that is required of the software. It is written in English (or another natural language) in non-technical language and typically occupies three sentences. It is a statement of a requirement, not a statement of implementation – what to implement, not how to implement. Thus a use case is a use- ful fragment of a requirements specification. For each use case, the developers make an estimate of how much effort will be needed for implementation. Because use cases are small, this will typically be a few weeks of person time. A longer estimate means that the use case is too large and needs to be broken down into smaller use cases. Once a use case has been priced, and a decision has been taken to implement it, then the client provides more detailed information about the requirement. The client specifies acceptance tests for each use case. These are a set of black box (functional) tests to ascertain whether the use case has been implemented correctly. XP uses the term acceptance test, rather than functional test, to emphasize their role in guaranteeing a system that is acceptable to the client. Acceptance tests are automated, so that they can be run repeatedly easily and objectively. A use case has not been suc- cessfully implemented until all its acceptance tests have been passed. The client is responsible for checking that tests have ultimately been successful. Acceptance tests drive the project. They are written before implementation of the use case is begun. They are repeatedly applied before and while the use case is being 26.3 ● Extreme programming 332 Chapter 26 ■ Agile methods and extreme programming BELL_C26.QXD 1/30/05 4:27 PM Page 332 26.3 Extreme programming 333 developed. Initially, of course, the tests fail, but as development proceeds they will be passed one by one, and eventually the implementation is complete. This approach is termed test-driven development. SELF-TEST QUESTION 26.1 Write an acceptance test for a boiling kettle. The client has a third role. In XP, development takes place incrementally. At any time, only a subset of use cases are selected for implementation. Because the use cases are small, it is possible to estimate with some confidence how long they will take. But usually it is not possible to implement all the use cases at once. It is the client who decides which are implemented next, and which are postponed until later. Usually, the client selects those use cases that meet the most immediate business need. At the outset of each phase of development (termed a release in XP), the project team (including the client) meet to decide what to do next. It is the client who decides what shall be undertaken next. The information available is: ■ the list of use cases, together with estimates of their development times ■ the number of developers available. Ideally a client would like everything done as soon as possible. But the client who is a member of an XP team knows that software cannot be delivered to an acceptable stan- dard in less time than the estimate. SELF-TEST QUESTION 26.2 What roles does the client take in XP? XP values Extreme programming is based on four clearly articulated values: 1. communication 2. simplicity 3. feedback 4. courage. Maximizing communication between the members of the development team and between the clients and the team is clearly vital in any project. But instead of regarding communication as a problem, XP exploits it, both as a principle and in practice. BELL_C26.QXD 1/30/05 4:27 PM Page 333 334 Chapter 26 ■ Agile methods and extreme programming Software that has a simple structure (and does the required job) is better than a com- plex structure. However, XP realizes that achieving simplicity is not easy. Feedback is about obtaining frequent reliable information about the state of the soft- ware as it is being developed, so that any problems can be accommodated. It also describes a relationship between the developers and the client in which the client is immediately aware of the consequences of their requests. Finally, the most surprising value is courage, which is not a concept that you expect to see in the context of software development. What it means is that the developers must have the courage to throw away code, or even re-design large parts of the archi- tecture, if the need arises. This is dramatically different from the common approach, which attempts to patch up software when it demonstrates faults, minor or serious. Techniques Extreme programming uses a combination of 12 techniques (called, in the terminology of XP, practices). The 12 techniques are: 1. replan frequently – quickly determine the scope of the next release by resolving business priorities and technical estimates. As reality overtakes the plan, update the plan. 2. small releases – put a simple system into production quickly, and then release new versions on a very short cycle 3. metaphor – guide all development with a simple shared story of how the whole system works 4. maintain a 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. 5. testing – programmers continually write unit tests, which must run flawlessly for development to continue. Customers write tests demonstrating that features are finished. 6. refactoring – programmers restructure the system without changing its behavior to remove duplication, improve communication, simplify or add flexibility. 7. pair programming – all production code is written with two programmers at one machine. 8. collective ownership – anyone can change any code anywhere in the system at any time. 9. continuous integration – integrate and build the system many times a day, and every time a task is completed 10. avoid overwork – work no more than 40 hours a week as a rule. Never work over- time a second week in a row. 11. involve the client – include a real, live user on the team, available full-time to answer questions 12. coding standards – programmers write all code in accordance with rules, empha- sizing communication through the code. BELL_C26.QXD 1/30/05 4:27 PM Page 334 Summary 335 Frequent replanning means that the client should decide which function is most important and should therefore be implemented next. The team estimates how long the next stage of the project will take and gains agreement (or not) for it to proceed. This way everyone takes responsibility for the planning. Pair programming (see Chapter 28 on teams) is a novel idea, which sounds expen- sive, but in reality saves time and improves quality by harnessing collaboration. A maximum 40-hour week emphasizes that no good is achieved by continually work- ing too hard. In a conventional project, it is common to resort to overtime to remedy delays. But this is usually a sign that something has gone wrong and the project is at the start of the slippery slope that leads to a disaster. XP avoids the need for desperate measures in two principal ways. First, continual testing prevents unpleasant surprises. Second, frequent releases means that any planning mistakes are quickly evident. The provision of an on-site customer is quite radical. It stresses that meeting the user requirements is so important that it needs continual special treatment – the permanent involvement of a client representative – which, though time-consuming, saves time over- all because reworking is avoided. The use of coding standards illustrates that some aspects of XP are quite rigorous. Also the code is the paramount product of a project. Emphasis is placed on clear code, rather than auxiliary documentation, such as UML diagrams. It is important to realize that these techniques complement each other, so that it is sometimes ineffective to use one without another. It is possible, but undesirable to use one of the XP techniques on its own. This is because they complement each other – a weakness in one practice is compensated by strength in another. For example, it would seem expensive in time continually to refactor the design, but the practice of keeping to a simple design ensures that refactoring is easy. SELF-TEST QUESTION 26.3 Which of the techniques suggest that XP is an incremental approach? Summary Agile methods are a range of lightweight techniques that subscribe to the agile manifesto. XP is one agile method with its own values and techniques. The values are com- munication, simplicity, feedback and courage. The twelve techniques include pair programming, test-driven development and continual refactoring. XP makes the coding, rather than any other documentation, the center of the product. BELL_C26.QXD 1/30/05 4:27 PM Page 335 336 Chapter 26 ■ Agile methods and extreme programming 26.1 Assess extreme programming. 26.2 Compare and contrast heavyweight methods (in general) with lightweight methods (in general). 26.3 Assess how extreme programming could be used in developing each of the systems described in Appendix A. 26.4 Compare and contrast extreme programming with open source development. 26.5 Assess how well the values and methods of extreme programming match up with those of the agile manifesto. 26.6 “Extreme programming is just hacking”. Discuss. Exercises • Answers to self-test questions 26.1 The whistle sounds. 26.2 Providing use cases, supplying acceptance tests, verifying that accept- ance test have succeeded, deciding what will be implemented next. 26.3 The use of small releases and continuous integration strongly suggest an incremental approach. Kent Beck, Extreme Programming Explained, Addison-Wesley, 2000. http://www.extremeprogramming.org/index.html Alistair Cockburn, Agile Software Development, Addison-Wesley, 2002. Further reading • BELL_C26.QXD 1/30/05 4:27 PM Page 336 The unified process (UP) is a process model for developing software. In common with other available process models, it provides an overall plan for a software development project. It also incorporates some recommendations for the techniques to be used as part of the process. The UP provides a general purpose strategy that can be tailored for an individual project – large or small, straightforward or risky. The UP is sometimes known as the rational unified process or RUP after the company that first promoted it. The word “Rational” was the company name and, of course, it also implies rationality. The “Unified” part of its name derives from the same source as the unified modeling language (UML). The founders of UML, Booch, Rumbaugh and Jacobson, were formerly rivals, but later collaborated (and were then termed the three amigos) to devise UML and the UP. UML is the notation; the UP is the process. The UP is the most recent process model to be widely used. As we shall see, the UP incorporates many of the ideas we have met in other chapters in this book. UP primarily aims to: ■ meet user needs ■ accommodate risks. 27.2 ● Overview 27.1 ● Introduction CHAPTER 27 The unified process This chapter explains: ■ the aims of the unified process ■ the techniques involved in the unified process ■ how to use the unified process. BELL_C27.QXD 1/30/05 4:27 PM Page 337 . 331 A whiteboard and colored pens are useful for drawing diagrams, such as use case dia- grams, class diagrams, user interface mock-ups and also informal sketches. It is easy to change the diagram,. diagram, and it can be viewed collaboratively and discussed by a group of people. A digital camera is a convenient way of capturing the information on a whiteboard. Index cards and a large table are. diagrams, informal and more formal (such as UML diagrams). A scanner or digital camera can record the results for computer storage. 26.2 The agile manifesto 331 BELL_C26.QXD 1/30/05 4:27 PM Page