Software Engineering for Students A Programming Approach
Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach
Summary 327 Inappropriate patches, once incorporated into code can irreparably damage a project. Having an explicit manager on all open source projects means that all contributions are monitored and approved. This ensures that the freedom to contribute is upheld, but lessens the risk of any sabotage attempts. Open source program code is extremely reliable because bugs are found and fixed by a huge viewing audience with highly proficient programming abilities. Proprietary software corporations are being forced to acknowledge open source development as a valid approach and are beginning to experiment with its techniques. The high viewing audience that can track and fix bugs is seen as an efficient way of “cleaning up” software that is proving to be unreliable. Consequently, some companies have now opened up previously closed code. This suggests that the open source development approach can influence other mainstream techniques. Contributors to open source projects have a passion for programming, so that writing code is seen as more of a hobby than a chore or a job. They gain enormous satisfaction in seeing their patches integrated into a program. However, because open source projects generally rely upon voluntary contributions, there is always the risk that the community will cease to contribute to the project. This would result in a stagnation of a development project and an unfinished product. Similarly, the lack of documentation also potentially limits maintenance to the original developer base and lessens the ability of someone else being able to take on the project. If the initial developer base tires of a project, it is not easy for another developer to take on the project without documentation as a means of communicating the design of the program. The usefulness of informal support mechanisms is questionable, particularly for the general user. Website tutorials are often aimed at a technically adept audience. In addition, since support services are voluntary, there is no guarantee that someone will be available when required and users may have to wait until someone responds to their enquiry. Summary Open source development is a collaborative approach relying upon voluntary contributions of program code. It has its roots in a hacker ethic that promotes individual skill, but also upholds the importance of community. The approach produces extremely reliable software because open source code means bugs are exposed to a vast audience. More bugs are likely to be found and fixed. The regular release of the software also means that program code is continually tested before the final product version is released. Non-commercial open source is generally deficient in supporting the general user. However, the commercial sector, acknowledging the superiority of the program code, is addressing this problem, providing support services for open source products and adopting open source development techniques.
328 Chapter 25 ■ Open source software development • Exercises 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 products 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? Answers to self-test questions 25.1 Reliable software. 25.2 Yes. 25.3 Code sharing. 25.4 The internet. • Further reading 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 licensing 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
- Page 299 and 300: 276 Chapter 19 ■ Testing 3. apply
- Page 301 and 302: 278 Chapter 19 ■ Testing made con
- Page 303 and 304: 280 Chapter 19 ■ Testing 19.3 Dev
- 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 352 and 353: Further reading 329 Cathedral and t
- Page 354 and 355: These are qualified by the statemen
- Page 356 and 357: 26.3 Extreme programming 333 develo
- 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
328 Chapter 25 ■ Open source software development<br />
• Exercises<br />
25.1 Can you think of any situations or products <strong>for</strong> which the open source procedure<br />
might be most appropriate?<br />
25.2 Can you think of examples of situations in which open source development of products<br />
might be unwise?<br />
25.3 Assess whether open source would be suitable <strong>for</strong> each of the developments given in<br />
Appendix A.<br />
25.4 Compare and contrast the approaches of the Free <strong>Software</strong> Foundation and the Open<br />
Source Movement.<br />
25.5 Is open source development just hacking?<br />
Answers to self-test questions<br />
25.1 Reliable software.<br />
25.2 Yes.<br />
25.3 Code sharing.<br />
25.4 The internet.<br />
•<br />
Further reading<br />
This book provides a rare insight into the history of hacking, from its origins at MIT<br />
in the 1950s to the rise of open source software: S. Levy, Hackers: Heroes of the<br />
Computer Revolution, Anchor Books, 2002.<br />
The following title is a comprehensive collection of essays covering topics from licensing<br />
issues to the engineering of such major open source products as Mozilla and<br />
Perl: Open Sources: Voices from the Open Source Revolution, C. DiBona, S. Ockman<br />
and M. Stone, O’Reilly, 1st edn, 1999.<br />
This is a very accessible book which depicts the development of the GNU/Linux<br />
Operating System, including interviews with major contributors in the open source<br />
field: G. Moody, Rebel Code: Inside Linux and the Open Source Revolution, Perseus<br />
Publishing, 2001.<br />
This is a response to Fred Brooks’s seminal proprietary software development text The<br />
Mythical Man Month (1974). Raymond argues why the open source approach to<br />
software development will provide a higher-quality product: E.S. Raymond, The