Software Engineering For Students: A Programming Approach Part 36 pot

328 Chapter 25 ■Open source software development25.1 Can you think of any situations or products for which the open source procedure might be most appropriate?. 25.4 Compare and contrast

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 engineerlicens-ing 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

•

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

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

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

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

A whiteboard and colored pens are useful for drawing diagrams, such as use case dia-grams, class diadia-grams, 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 workcheck-ing

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

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

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

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

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

•

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

This chapter explains:

■ the aims of the unified process

■ the techniques involved in the unified process

■ how to use the unified process