Software Engineering for Students A Programming Approach
Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach
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 standard 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 complex structure. However, XP realizes that achieving simplicity is not easy. Feedback is about obtaining frequent reliable information about the state of the software 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 architecture, 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 overtime 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, emphasizing communication through the code.
- Page 305 and 306: 282 Chapter 19 ■ Testing 19.2 The
- Page 307 and 308: 284 Chapter 20 ■ Groups The term
- Page 309 and 310: 286 Chapter 20 ■ Groups Of course
- Page 311 and 312: 288 Chapter 20 ■ Groups • Exerc
- Page 314 and 315: CHAPTER 21 This chapter explains: 2
- Page 316 and 317: Stage Input Output 21.3 Feedback be
- Page 318 and 319: Summary The essence and the strengt
- Page 320 and 321: CHAPTER 22 This chapter: 22.1 ● I
- Page 322 and 323: 22.2 The spiral model 299 to try to
- Page 324 and 325: 22.4 ● Discussion Exercises 301 A
- Page 326 and 327: CHAPTER 23 Prototyping This chapter
- Page 328 and 329: Therefore, in summary: ■ the prod
- Page 330 and 331: 23.5 Evolutionary prototyping 307 U
- Page 332 and 333: Reuse components 23.6 Rapid prototy
- Page 334 and 335: Pitfalls For users, the problems of
- Page 336 and 337: Answers to self-test questions 313
- Page 338 and 339: 24.2 ● Big-bang implementation 24
- Page 340 and 341: Tested component Figure 24.1 Top-do
- Page 342 and 343: 24.7 ● Use case driven implementa
- Page 344 and 345: ■ middle-out ■ use case based.
- Page 346 and 347: SELF-TEST QUESTION 25.1 What is the
- Page 348 and 349: sharing of software or their own re
- Page 350 and 351: Summary 327 Inappropriate patches,
- Page 352 and 353: Further reading 329 Cathedral and t
- Page 354 and 355: These are qualified by the statemen
- Page 358 and 359: SELF-TEST QUESTION 26.3 Which of th
- Page 360 and 361: CHAPTER 27 This chapter explains:
- Page 362 and 363: Figure 27.1 The phases of the unifi
- Page 364 and 365: 27.5 ● Iteration 27.6 Case study
- Page 366 and 367: The transition phase Summary 343 Th
- Page 368: PART F PROJECT MANAGEMENT
- Page 371 and 372: 348 Chapter 28 ■ Teams The commun
- Page 373 and 374: 350 Chapter 28 ■ Teams Level of s
- Page 375 and 376: 352 Chapter 28 ■ Teams A chief pr
- Page 377 and 378: 354 Chapter 28 ■ Teams benefits o
- Page 379 and 380: 356 Chapter 28 ■ Teams • Furthe
- Page 381 and 382: 358 Chapter 29 ■ Software metrics
- Page 383 and 384: 360 Chapter 29 ■ Software metrics
- Page 385 and 386: 362 Chapter 29 ■ Software metrics
- Page 387 and 388: 364 Chapter 29 ■ Software metrics
- Page 389 and 390: 366 Chapter 29 ■ Software metrics
- Page 391 and 392: 368 Chapter 29 ■ Software metrics
- Page 393 and 394: CHAPTER 30 This chapter: 30.1 ● I
- Page 395 and 396: 372 Chapter 30 ■ Project manageme
- Page 397 and 398: 374 Chapter 30 ■ Project manageme
- Page 399 and 400: 376 Chapter 30 ■ Project manageme
- Page 401 and 402: 378 Chapter 30 ■ Project manageme
- Page 403 and 404: 380 Chapter 30 ■ Project manageme
- Page 405 and 406: 382 Chapter 30 ■ Project manageme
26.3 Extreme programming 333<br />
developed. Initially, of course, the tests fail, but as development proceeds they will be<br />
passed one by one, and eventually the implementation is complete. This approach is<br />
termed test-driven development.<br />
SELF-TEST QUESTION<br />
26.1 Write an acceptance test <strong>for</strong> a boiling kettle.<br />
The client has a third role. In XP, development takes place incrementally. At any<br />
time, only a subset of use cases are selected <strong>for</strong> implementation. Because the use cases<br />
are small, it is possible to estimate with some confidence how long they will take. But<br />
usually it is not possible to implement all the use cases at once. It is the client who<br />
decides which are implemented next, and which are postponed until later. Usually, the<br />
client selects those use cases that meet the most immediate business need.<br />
At the outset of each phase of development (termed a release in XP), the project<br />
team (including the client) meet to decide what to do next. It is the client who decides<br />
what shall be undertaken next. The in<strong>for</strong>mation available is:<br />
■ the list of use cases, together with estimates of their development times<br />
■ the number of developers available.<br />
Ideally a client would like everything done as soon as possible. But the client who is<br />
a member of an XP team knows that software cannot be delivered to an acceptable standard<br />
in less time than the estimate.<br />
SELF-TEST QUESTION<br />
26.2 What roles does the client take in XP?<br />
XP values<br />
Extreme programming is based on four clearly articulated values:<br />
1. communication<br />
2. simplicity<br />
3. feedback<br />
4. courage.<br />
Maximizing communication between the members of the development team and<br />
between the clients and the team is clearly vital in any project. But instead of regarding<br />
communication as a problem, XP exploits it, both as a principle and in practice.
Change language