Software Engineering For Students: A Programming Approach Part 35 pps

■ there is no visible, working system until a very late stage, system testing, is complete.
True there are tested components and subsystems, but there is normally nothing
that can be demonstrated to the client as even providing a limited vision of what the
system will eventually do.
■ not all systems have a bottom.
Middle-out development starts with an architectural design for the software. It then
chooses some central component as the starting point for testing. A driver and stubs are
written and the component is tested. Then some adjoining component is added to the
system and testing carried out. The system emerges from its centre.
This approach could be useful in developing a large software system that involves a
number of developers. In such a development, the work needs to be divided among a
number of people who work concurrently. Hopefully the architecture can be cleanly
divided into weakly coupled subsystems, which are initially developed independently.
These subsystems need to be surrounded by drivers and stubs, developing in a middle-
out fashion.
This approach suffers from all the combined drawbacks of bottom-up and top-down
development.
24.6
●
Middle-out implementation
318 Chapter 24 ■ Incremental development
Component
1
Component
2
Component
under
test
Test
bed
Figure 24.3 Bottom-up implementation

SELF-TEST QUESTION
24.1 Suggest a drawback of middle-out development
BELL_C24.QXD 1/30/05 4:26 PM Page 318
24.8 Discussion 319
A use case is a single independent function that a system provides for a user. For example,
the word processor (Appendix A) provides tens of functions to carry out the tasks of
editing, formatting and displaying text. Each of these is a use case. This approach takes
one use case at a time and implements it.
In the word processor example, we might first choose to implement the save file
function. This is a good choice because, once it is implemented, this feature is useful in
providing a mechanism for testing the other use cases. Implementing this function
means single-mindedly concentrating on it to the exclusion of all the other functions.
Only the methods necessary to achieving this end are implemented. Drivers are not
needed and a minimal number of stubs are required.
The use case approach is different to the top-down approach explained above. Top-
down starts with the user interface and implements each of the various functions in a
breadth-first fashion. It creates a forest of trees that grow simultaneously. In contrast, the
use case approach is a depth-first approach. It creates individual trees one after the other.
The stages of the use case approach are:
1. choose an initial use case to implement
2. implement the use case
3. test the use case
4. demonstrate the use case to the client.
These stages are repeated until the user is satisfied with the product.
The strengths of this approach are:
■ the system acts as its own drivers
■ there are immediate and repeated, visible products.
24.7
●
Use case driven implementation

SELF-TEST QUESTION
24.2 Suggest a second use case for implementation.
We have assumed in the above explanation that architectural design is complete prior
to incremental implementation. This is one approach, but an alternative is to allow the
architectural structure to emerge from the implementation. This means that the struc-
ture will probably be subject to frequent refactoring (see Chapter 13). This takes some
courage and it might be too risky an approach for a large project.
24.8
●
Discussion
BELL_C24.QXD 1/30/05 4:26 PM Page 319
320 Chapter 24 ■ Incremental development
Summary
The aim of incremental development is easier bug detection. The mechanism is
incorporation of components one by one. Incremental methods include:
■ top-down
■ bottom-up
■ middle-out
■ use case based.
Use case based development provides early and frequent functionality. This in turn
means:
■ improved confidence by the client and the developer
■ the opportunity for the user to change their requirements
■ the opportunity for the user to decide what should be implemented next.
Use case based development also reduces the work of creating test drivers and
stubs.
Exercises
•
24.1 Draw up an incremental process model for preparing a meal, including buying the
ingredients and washing up afterwards. Don’t forget to identify the product at each

stage.
24.2 Draw up an incremental process model for writing a student assignment. The assign-
ment is to write an essay reviewing the process models that are explained in this book.
The non-incremental approach is:
Step 1 read and digest all the relevant chapters
Step 2 write the review.
24.3 Draw up an incremental process model for a large civil engineering project, such as
building a road bridge across the channel between England and France. Identify
similarities and differences between this project and a large software development
project.
24.4 Create an outline plan for developing each of the systems in Appendix A, using an
incremental approach.
24.5 Compare and contrast the following approaches to development:
■ top-down
■ bottom-up
BELL_C24.QXD 1/30/05 4:26 PM Page 320
Further reading 321
■ middle-out
■ use case based.
24.6 Evaluate the incremental process model the following criteria:
■ capability to accommodate risk
■ capability to respond to changed requirements
■ capability to meet user requirements
■ visibility of the development to developers and clients.
24.7 Identify the main goals and the main techniques of each of the following process
models:
■ waterfall
■ spiral
■ prototyping
■ incremental

■ open source
■ XP
■ UP.
Answers to self-test questions
24.1 The need to create many drivers and stubs.
24.2 The open file use case.
For a discussion of evolutionary development see: Felix Redmill, Software Projects:
Evolutionary vs. Big-Bang Delivery, John Wiley, 1997.
Kent Beck suggests an incremental approach to development that is based entirely on
writing a series of tests: Test Driven Development, Addison-Wesley, 2003.
Further reading
•
BELL_C24.QXD 1/30/05 4:26 PM Page 321
Open source is a development approach in which the source code of the software is
entirely free to access. The term “open source” is used to refer to both the product
and the development approach. Any individual is able to view the code, modify it or
duplicate it. Access to the source code facilitates the distributed and cooperative
approach to software development that is fundamental to an open source style of
development.
Some examples of larger open source products are: Mozilla web browser; Apache
web server; GNU/Linux and GNU/HURD operating systems; MySQL database soft-
ware; Perl programming language; MyOffice and OpenOffice office suites. The range
of products illustrates that open source software development can produce a diverse
range of products.
The open source development approach is an extension of the hacker community’s atti-
tude to the building of software. The term hacker has been associated with negative
aspects of computing. However, hackers are now recognized as a community of highly
skilled programmers who relish the act of writing code and participate for enjoyment or
to enhance their programming reputation. It is fundamental to the hacker ethic that
information and knowledge should be freely shared without restriction because this

stimulates collaborative thinking, leading to superior ideas overall.
25.2
●
The principles of open source development
25.1
●
Introduction
CHAPTER
25
Open source
software
development
This chapter explains:
■ the principles behind open source development
■ the schism in the open source movement
■ how to carry out open source development.
BELL_C25.QXD 1/30/05 4:27 PM Page 322
Whilst there is a common belief in collaboration and openness within the development
community, a schism does exist in terms of the motivation and underlying philosophy
of open source. The main split is between the Free Software Foundation (FSF) and the
Open Source Movement (OSM).
The FSF was founded by Richard Stallman in 1985. This software development
community promotes free software projects and places emphasis on the social benefits
of working collaboratively. The FSF refer to their software as “freeware”, emphasizing
the absence of restrictions associated with this type of development. It is intended to be
25.3
●
The schism within open source development
SELF-TEST QUESTION
25.1 What is the primary goal of open source development?

25.2 Can you write and sell software with a GPL license?
The same principle is applied in open source development. Rather than the code
being confined to a small core of developers, as in proprietary methods, a greater audi-
ence facilitates a greater influx of ideas and a greater degree of innovation. It is also
believed that because the source code is examined by a larger audience than proprietary
software, any imperfections stand a greater chance of being identified and consequent-
ly rectified. The sharing of code therefore leads to more reliable code.
Hackers comprise a large portion of the open source development community.
Head figures within open source organizations are very often notorious hackers, whose
reputation for highly proficient programming strengthens their influence on the open
source community.
Because of the openness of the program code, the community has devised its own
license agreement for use on products developed as open source. The GNU General
Public License (GPL) is a software license which protects its “openness”, actually
making it illegal for anyone to make the code proprietary or “closed”. The GPL
restricts private modification to source code without publication and disallows the
incorporation of any GPL-covered software into a proprietary program. Some larger
open source development projects have devised their own open source licenses, which
differ in varying degrees from the GPL. However, the majority of projects still deploy
the GPL, particularly most of the founding open source projects and smaller devel-
opment communities that are not affiliated with proprietary companies.
However, the openness and concept of code sharing does not always mean that
open source products are free to buy. Open source is “free as in freedom, not as in free
beer”. Open source companies do offer their program code for free, most commonly
to download from their website. However, they often also sell their software as a com-
plete package, shrink wrapped, sometimes including user manuals and additional help
services.
25.3 The schism within open source development 323
BELL_C25.QXD 1/30/05 4:27 PM Page 323
a totally embracing ethic, increasing access to the practice of software development and

also the resultant products.
The philosophy of the FSF is that individual freedom should never be compromised
and that all individual action should also benefit the wider community. Therefore,
whilst individual programmers are encouraged and admired, they are also expected to
feed their findings and their skills back into the community of programmers to which
they ultimately belong. This is done through the sharing of code and the distribution
of good programming practice.
The FSF is absolutely resolute in not allowing any proprietary software to be incor-
porated into their software and were integral in the creation of the GPL. All their prod-
ucts are covered under the GPL, and they are largely unaffiliated with larger software
development companies.
The Open Source Movement is spearheaded by Eric S. Raymond. Their emphasis is
on the benefits of open source as a development approach, rather than the moral ben-
efits that can be brought by using this approach. They stress that open source can pro-
duce higher-quality software than proprietary software.
The OSM are more willing to collaborate with larger software companies, sometimes
including developers of proprietary products. They wish to appeal to the business sec-
tor because this enables greater distribution of their product. However, unlike the FSF,
greater use of their products is motivated primarily because of the quality, rather than
because of the freeness of the software. Forming contracts with larger companies is one
way of exposing OSM products to a larger potential market. However, it also means
that the product must compete with other commercial package products.
Despite the schism within open source in terms of ethics and philosophy, the develop-
ment practices principally remain the same between the two.
Within the open source development community, there is often no formal mechanism
for gathering initial user requirements. The process often consists of a software require-
ment that is instigated by a sole developer, with requests for collaboration, targeting the
hacker community. The Internet facilitates communication between developers and also
the distribution of source code, via the Web, File Transfer Sites and e-mail.
The head developer specifies most requirements. Additional user requirements are

either implemented by individual developers themselves via personal modification of
the source code, or through a communal process known as “code forking”. Code fork-
ing occurs when the developer base has alternative requirements or conflicting ideas on
how to implement a requirement. The code is seen to “fork” because it is split and each
copy of the code is developed in parallel. After this split occurs, the code is irreconcil-
able and therefore two different products exist, both growing from the same base code.
Each fork competes for developer attention, so that the most popular or the most reli-
able version survives.
The code writing on an open source project is sustained through voluntary contri-
butions. Developers are motivated by the enjoyment of programming, the belief in the
25.4
●
Techniques of open source development
324 Chapter 25 ■ Open source software development
BELL_C25.QXD 1/30/05 4:27 PM Page 324
sharing of software or their own requirement for the software product. Code is com-
monly 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 dia-
grams 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 with-
in 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 com-
munity 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 com-
mercial 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?
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 contrib-
utors 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
25.5
●
Case study: the GNU/Linux operating system
25.5 Case study: the GNU/Linux operating system 325
BELL_C25.QXD 1/30/05 4:27 PM Page 325
the functionality he required. He also feared that another open source operating sys-
tem, 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 ker-
nel and requesting feedback and contributions. Increased contributions and collabora-
tions 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 origi-
nal non-supported format. However, a number of commercial organizations also exist
to provide appropriate support for various user markets. GNU/Linux remains in con-
tinuous development, often responding to technological advancements.
Open source development’s most attractive asset is the enormous enthusiasm and pas-
sion that resonates throughout the developer community and their building of soft-
ware. 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 devel-
opment 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 soft-
ware. 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 rela-
tively fast pace.
25.6
●
Discussion
326 Chapter 25 ■ Open source software development
BELL_C25.QXD 1/30/05 4:27 PM Page 326
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 con-
tribute 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 soft-
ware corporations are being forced to acknowledge open source development as a valid
approach and are beginning to experiment with its techniques. The high viewing audi-
ence 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 writ-
ing code is seen as more of a hobby than a chore or a job. They gain enormous satis-
faction 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 orig-
inal 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 devel-
oper 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 addi-
tion, since support services are voluntary, there is no guarantee that someone will be avail-
able 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 con-
tributions of program code. It has its roots in a hacker ethic that promotes indi-
vidual 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 contin-
ually 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 prod-
ucts and adopting open source development techniques.
BELL_C25.QXD 1/30/05 4:27 PM Page 327