Software Engineering for Students A Programming Approach
Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach
sharing of software or their own requirement for the software product. Code is commonly implemented via reuse and most open source projects begin immediately by rewriting the code of existing products, with enhancements and alterations made where necessary. When there is no original from which to copy, a core developer base begins writing the code before offering it to the wider community for critique. The design of the code is communicated via web-based tools. Sometimes UML diagrams or other cross-reference displays, using hyperlinks to depict the overall structure of the are deployed. However, generally, there is a lack of design documentation within open source products. An explicit project manager or management group is generally in place on open source projects. They decide on the usefulness and appropriateness of contributions that are made by the wider developer community. They also usually add the patch to the code and therefore act as chief implementer on the project. Once contributions have been implemented, beta versions of open source products are released. Releases are made frequently, so that the effectiveness of contributions can be tested immediately. Feedback on the latest version is received and contributions again incorporated into the code in a continuous cycle, which continues until the community is satisfied with the eventual outcome. Contributions then slow down or cease. Development communities and product websites act as sources of support for users of open source software. The websites contain installation tutorials and user forum groups providing technical support. The development community mostly provides these voluntarily. As an alternative means of support, commercially supported versions of open source software are available to buy. This software is an exact replica of the source code, but is provided with supporting manuals and services. These do not exist for all products and therefore many smaller open source products are only used by technically adept users. However, most of the larger open source projects now have their own commercial subsidiaries. SELF-TEST QUESTIONS 25.3 What is the main technique of open source development? 25.4 What is the main tool of open source development? 25.5 Case study: the GNU/Linux operating system 325 25.5 ● Case study: the GNU/Linux operating system GNU/Linux is an open source operating system, loosely based upon Unix. It contains over 10 million lines of code and has been developed using over 3,000 major contributors of code throughout 90 countries. Linus Torvalds, who still oversees the project today, instigated the project in 1991. Torvalds originally began the project because none of the current operating systems served his own requirements. They were either unreliable, too expensive or devoid of
326 Chapter 25 ■ Open source software development the functionality he required. He also feared that another open source operating system, GNU/HURD, was far off completion. He could not wait. Torvalds began to write the kernel for his operating system. He was also motivated by the enjoyment of writing code and claims that he wrote it “just for fun”! Torvalds targeted developer forums and websites, posting an early release of the kernel and requesting feedback and contributions. Increased contributions and collaborations between GNU/Linux and GNU groups meant that distribution of beta versions was frequent and continuous. The GNU/Linux operating system is licensed under the GPL, ensuring that the source code remains open. After years of continuous development, GNU/Linux is now a renowned open source operating system, competing on the world market with other commercial and proprietary software companies. What began as a personal project is now widely used and technically reputable. The GNU/Linux software code is still available in its original non-supported format. However, a number of commercial organizations also exist to provide appropriate support for various user markets. GNU/Linux remains in continuous development, often responding to technological advancements. 25.6 ● Discussion Open source development’s most attractive asset is the enormous enthusiasm and passion that resonates throughout the developer community and their building of software. Developers have an unrelenting belief in what they do; voice their pride in their hacker roots; find nothing more fulfilling than the art of programming. Forking ensures that developer requirements are established and implemented in a democratic process. This means that the requirements of the majority of the development community are satisfied. Similarly, any specific personal modification can be made by individuals, providing that they have the technical ability to implement them. However, it is worth noting that this process largely ignores non-developer user requirements. The general user does not have the power to register their vote via code implementation; neither can they personally modify their own code. The reuse of code is an important development approach. However, in the case of open source projects that attempt to rewrite entire systems and applications, a reuse approach can only be facilitated by source code that is not covered by a proprietary license. Liability issues may hinder entire projects because developers may not have legal access to any code that they would like to rewrite. However, the overall expertise of the hacker community usually means that volunteers are willing to take on the alternative and more difficult task of writing entire systems from scratch. Releasing frequent versions of the software brings benefits of continuous feedback. Whilst the beta code may not contain all the functionality that is required, it means that the developer base can immediately evaluate the code and get a feel for the software. Crucially, the potentially vast audience of testers can immediately begin to track and fix bugs, so that changes can be made incrementally, continuously and at a relatively fast pace.
- Page 297 and 298: 274 Chapter 19 ■ Testing if (a >=
- 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 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 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
sharing of software or their own requirement <strong>for</strong> the software product. Code is commonly<br />
implemented via reuse and most open source projects begin immediately by<br />
rewriting the code of existing products, with enhancements and alterations made where<br />
necessary. When there is no original from which to copy, a core developer base begins<br />
writing the code be<strong>for</strong>e offering it to the wider community <strong>for</strong> critique.<br />
The design of the code is communicated via web-based tools. Sometimes UML diagrams<br />
or other cross-reference displays, using hyperlinks to depict the overall structure<br />
of the are deployed. However, generally, there is a lack of design documentation within<br />
open source products.<br />
An explicit project manager or management group is generally in place on open<br />
source projects. They decide on the usefulness and appropriateness of contributions<br />
that are made by the wider developer community. They also usually add the patch to<br />
the code and there<strong>for</strong>e act as chief implementer on the project.<br />
Once contributions have been implemented, beta versions of open source products<br />
are released. Releases are made frequently, so that the effectiveness of contributions can<br />
be tested immediately. Feedback on the latest version is received and contributions<br />
again incorporated into the code in a continuous cycle, which continues until the community<br />
is satisfied with the eventual outcome. Contributions then slow down or cease.<br />
Development communities and product websites act as sources of support <strong>for</strong> users<br />
of open source software. The websites contain installation tutorials and user <strong>for</strong>um<br />
groups providing technical support. The development community mostly provides<br />
these voluntarily.<br />
As an alternative means of support, commercially supported versions of open source<br />
software are available to buy. This software is an exact replica of the source code, but<br />
is provided with supporting manuals and services. These do not exist <strong>for</strong> all products<br />
and there<strong>for</strong>e many smaller open source products are only used by technically adept<br />
users. However, most of the larger open source projects now have their own commercial<br />
subsidiaries.<br />
SELF-TEST QUESTIONS<br />
25.3 What is the main technique of open source development?<br />
25.4 What is the main tool of open source development?<br />
25.5 Case study: the GNU/Linux operating system 325<br />
25.5 ● Case study: the GNU/Linux operating system<br />
GNU/Linux is an open source operating system, loosely based upon Unix. It contains<br />
over 10 million lines of code and has been developed using over 3,000 major contributors<br />
of code throughout 90 countries.<br />
Linus Torvalds, who still oversees the project today, instigated the project in 1991.<br />
Torvalds originally began the project because none of the current operating systems<br />
served his own requirements. They were either unreliable, too expensive or devoid of