Chapter 9

While object-oriented programming languages have been available for a long time, it was only in the late 1980's and early 1990's object-oriented software development started to emerge as a mature technology. Before this time, structured development techniques and methodologies dominated.

In the early 1990's, there were several competing object-oriented analysis and design methodologies to choose from. Most of these methodologies had one thing in common: they were designed for large-scale software projects. In addition, each of the methodologies had their own set of principles, and their own graphical design notation.

One of the earliest methodologies was known as Coad-Yourdon Object-Oriented Systems Design. Coad-Yourdon's design notation was among the easiest to learn and use of any of the methodologies. While some of its features resembled older structured methodologies in the approach to the software lifecycle, it had many outstanding concepts for object design, including its approach to object discovery and evaluation. Many of the principles discussed in Chapter 4 are derived from Coad-Yourdon.

Another major methodology from the early 1990's was the Booch Method, designed by Grady Booch. It, too, had many sound object-oriented design concepts, as well as its own design notation (often called Booch Clouds). Today, Booch's book, Object-Oriented Analysis and Design, remains a classic OO reference.

Two other methodologies are worth mentioning. James Rumbaugh developed a methodology called the Object Modelling Technique, or OMT, which has heavily influenced the design of the UML. Ivar Jacobson developed the Objectory methodology, which was based largely on the Use Case.

In the mid-1990's, James Rumbaugh and Ivar Jacobson joined Grady Booch (together often known as The Three Amigos) at Rational Software to unify their methodologies. One of the first results of this collaboration was the UML, followed by the Rational Unified Process (or RUP as it is commonly called). RUP is discussed in the next section.

RUP has emerged as the most dominate object-oriented design methodology used today. Unfortunately, probably more projects don't use any kind of methodology. One reason for this may be that RUP is best suited for large projects with good management teams in place. Another is that until recently, there has not been much in the way of alternate development methodologies.

Fortunately, this is changing. Several new methodologies more suited to small scale projects have emerged. Just as there were many competing heavyweight OO development methodologies in the early 1990's, the turn of the millennium has seen the rise of several competing lightweight methodologies.

In the next section, we will briefly discuss the Rational Unified Process. Following that, we will look at some of the smaller, agile methodologies, especially eXtreme Programming. Finally, we will go over open source development, which really can be considered an alternate development methodology.

Methodologies for Large Scale Projects

It is a fact that large software projects require significant planning and management. The largest projects, which involve tens or even hundreds of programmers, can take years to finish. Any software project that involves people numbering in the tens, and time frames of a year or more, really need a well-defined development process.

Today, the Rational Unified Process, or RUP, developed by The Three Amigos, is the main heavyweight methodology in widespread use. While the main principles of RUP may be used by themselves as a development process, they are almost exclusively associated with Rational Software which has a large number of software development tools to help with RUP-based development.

Let there be no doubt about just what RUP is. It is a very good development process, most suitable for large software projects. It has many strong points to its procedures and philosophies. It is somewhat adaptable to different project needs.

However, it is large and comprehensive. This means it requires extensive training to use properly. It is also expensive. Rational Software is the principle supplier of the software tools used for RUP. It can cost several thousand dollars for each developer seat. The whole process is heavily documentation oriented, and requires significant management resources.

This is not to imply that there is anything wrong with RUP. It was developed by some of the best software methodologists around. It has been shown to work for a wide variety of software projects. What is not clear, though, is if such a heavyweight process is best, or even needed, for smaller projects.

Overview of the Unified Process

In many ways, RUP is not all that different from the basic software development process we discussed in Chapter 4. It starts with significant planning, includes analysis and design, and finishes with building and releasing. One of the strengths of RUP is that it makes all these steps part of an overall process that includes support for both the management and the software engineering sides of the process.The whole process is iterative, with a goal of producing some tangible result at the end of each iteration.

Basic Concepts

One way to look at RUP is to view it as a two-dimensional process as shown in Figure 9-1. Overall, a software development cycle is made up of four phases: Inception, Elaboration, Construction, and Transition. There are activities, or workflows, that are parts of each cycle, including Business Modeling, Requirements, Analysis and Design, Implementation, Test, and others.

		Management View
		Phases
Workflows	Inception	Elaboration	Construction	Transition
Business Modeling	********	***********	**************	*
Requirements	********	***********	**************	**
Analysis & Design	******	***********	**************	**
Implementation	****	***********	**************	******
Test	*****	***********	**************	*******
Deployment		******	**************	****
Configuration and Change Management	****	***********	**************	********
Project Management	********	***********	**************	********
	Inception Iterations	Elaboration Iterations	Construction Iterations	Transition Iterations
		Iterations
		Engineering View
Figure 9-1.
Overview of RUP

The entire process is iterative. Each phase will itself consist of one or more the four phase cycles. Thus, the main construction phase may consist of several cycles, each producing a more complete product than the last. One of the goals of RUP is to produce some kind of product at the end of each cycle.

The vertical lines between each phase in Figure 9-1 are milestones. Progress on the project is tracked using these milestones.

The horizontal lines associated with each workflow help indicate when the activity is carried out during the development cycle. While Figure 9-1 shows the time line of each work flow, there is also an intensity associated with each workflow not shown by the *'s in this diagram. For example, the Analysis & Design workflow will involve the most effort at the beginning of the development cycle in inception and elaboration, while the implementation workflow will be most intense in the construction phase.

This view of development also can be used to help control the project from both a high level management viewpoint, and a lower lever engineering viewpoint. Top level management can view the whole project as one big cycle of the four phases, while the engineering view will see the iterative cycles that really make the project work. Different levels of management can use different milestones to track project progress.

One of the features of RUP is that it is designed to be flexible. The RUP support tools available from Rational Software can be used to modify the process to fit a particular project. The number of iterations involved, the timing of milestones, the total number of people involved can be handled flexibly. And because the process is inherently iterative, there is some flexibility built in to handle changing requirements.

One of the problems with any activity involving tens or hundreds of people is that the whole process can get too rigid and impersonal. With many people involved, there will often be a management bureaucracy and an emphasis on producing documentation to track project progress. This may be inevitable when dealing with that many people. However, it can also be quite impersonal, and frustrating for programmers who like to think of their work as having a high level of creativity.

Agile Methodologies for Small Projects

It isn't only large projects that need a development methodology. Any software project can benefit. While a heavyweight methodology like RUP may be adaptable to smaller projects, most small projects simply cannot afford the training and management overhead needed to make using them effective. For projects with up to 10 or 15 programmers, what is needed is a lightweight methodology that is small, easy to learn and use, and doesn't require extensive management support. Methodologies need to recognize the talents of the programmers involved, and treat everyone as a member of a team working toward a common goal.

The Agile Alliance

In February, 2001, there was an amazing meeting at Snowbird in Utah. Seventeen people, representatives from several development methodologies (including eXtreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others who see a need for alternatives to heavyweight methodologies) met to find some common ground. Getting seventeen software gurus to agree on anything was nothing short of a miracle. The group formed what is known as the Agile Alliance, and produced a manifesto and set of basic principles that is posted on the www.agilealliance.org web site.

It has become clear that there is a place for both lightweight, agile methodologies, and large, heavyweight methodologies. Because the principles set forth by the Agile Alliance are important, and because the alliance wants their message to be freely disseminated, the manifesto and principles are reproduced here from the Agile Alliance web site:¹

We are uncovering better ways of developing software by doing it
and helping others do it. Through this work we have come to value:

That is, while there is value in the items on
the right, we value the items on the left more.


Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler	James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick	Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.

Welcome changing requirements, even late in development.
Agile processes harness change for the customer's competitive advantage.

Deliver working software frequently, from a couple of weeks to
a couple of months, with a preference to the shorter timescale.

Build projects around motivated individuals.
Give them the environment and support they
need, and trust them to get the job done.

The most efficient and effective method of conveying information to and
within a development team is face-to-face conversation.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able to
maintain a constant pace indefinitely.

At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.

As the time this book was written, several development methodologies fall into the agile development philosophy. The one getting the most attention is known as eXtreme Programming, or simply XP. We will discuss some of the major features of XP in the next section, then briefly discuss some of the other agile methodologies in following sections.

eXtreme Programming

Extreme Programming come mainly from the work of Kent Beck and Ward Cunningham who have been leaders in the object-oriented programming world for some time. The main reference is Kent Beck's book, Extreme Programming Explained: Embrace Change.

As the title of the book indicates, one of the main tenants of XP is to embrace change. The traditional development process puts the analysis and design at the beginning, and hopes to get it right. This is partly based on the assumption that making changes in software is more expensive the later in the development the change is required. It will cost far more to fix some flaw in the design after the software is mostly written than to discover and fix the flaw early in the design process.

The problem trying to lock in a design early is that the requirements almost always change as the project progresses. If nothing else, both the customer's and developer's understanding of the problem will increase, making things obvious that weren't at the beginning. XP says software requirements will change, so embrace that change. Use a development process that will make it easy to change software, and reduce the cost of doing so.

With this in mind, XP has developed a set of practices that define the process. Four basic values help make these practices work: communication, simplicity, feedback, and courage.

Communication is critical. This is communication between the developer and the customer, between management and the programmers, and between the programmers themselves. Problems in software systems can often be traced back to some missed communication. With an emphasis on communication, discovery of problems will come as early as possible.

Simplicity is another important XP value. Part of the idea is to not overdesign. The software should be as simple as possible to meet the most important business requirements. This means doing what needs to be done now, not maybe later, because often code written for future possibilities won't ever be used, possibly because the requirements have changed. By focusing on what needs to be done now, everyone's understanding of just how the system works and what it can do will be maximized.

Communication and simplicity also help with the third XP value, feedback. Feedback is important to know just what the current state of the system is. Which tests are working, which have failed? How far along is the project, and how do the current capabilities meet the customers expectations? All this feedback keeps the project on track.

And the final XP value is courage. This means courage to change, courage to act when flaws are found, and courage to trust that XP practices will work. Many parts of XP are indeed radical when compared to traditional development methodologies, and it does take a certain amount of courage from both management and programmers to embrace the change of XP.

XP Practices

The Planning Game

This is the XP planning process. The customer plays an important part of the XP process. The customer first writes user stories, short descriptions of the behavior of the product, and ranks them by importance. The developers then estimate the development effort required. Together, the customer and developer rank the stores and select what should be implemented next, and what should be deferred.

Short Releases

XP teams get a system working as early as possible, and follow up with frequent updates with added functionality on very short cycles.

Metaphor

Communication is important, so XP teams use a common terminology and system of names to guide the development.

Simple Design

One of the major principles of XP is to always design as simply as possible. Thus, an XP program should be the simplest program that meets the current requirements. It will avoid adding features for the future that may never be needed. The focus is always on providing business value. To keep the incremental changes inherent to this design philosophy, XP relies on refactoring.

Testing

One practice that XP follows is to write tests based on the requirements first, and then the software that meets the tests. These tend to be unit tests for specific objects that are part of the design. The customer helps develop the overall acceptance tests for the full product.

Refactoring

Refactoring is an integral part of the XP process. All code is subject to constant refactoring to keep the design clean, simple, and complete.

Pair Programming

Pair programming is one of XP's most unusual, and even controversial features. All programming is done in pairs - two programmers working together on one machine (and not necessarily the same two all the time). The idea is to maximize productivity, reduce errors, and increase communication.

Collective Ownership

All code is owned by all the programmers. This maximizes communication, minimizes the importance of single programmers, and gives great flexibility in who is able to change any part of the code.

Continuous Integration

XP code is constantly integrated, perhaps several times per day. This keeps all the code synchronized, and enables rapid progress with continuous feedback as to the state of the software.

40-Hour Week

XP recognizes that fresh, healthy, and happy programmers are effective and productive. Tired programmers make more mistakes and are less productive. Thus, it is a core principle of XP to avoid excessive working hours.

On-Site Customer

XP requires a dedicated, on-site representative of the customer. The representative will be able to determine and clarify requirements, set priorities, and answer questions as the programmers have them. This enhanced communication can reduce the need for expensive documentation, and eliminate costly delays waiting for clarifications.

Coding Standards

Pair programming and shared code ownership requires that all programmers write code following a common standard. Thus, XP requires a clearly specified coding standard for all programmers to follow.

The Rise of XP

Many of the XP practices are indeed quite different than more traditional approaches. XP is almost more a philosophy on how to develop code than it is a specific set of design rules. For example, XP does not specify the use of one design notation over another, or even any design notation at all. Some XP projects will use virtually no formal design techniques. CRC cards are one of the more commonly used design tools by XP projects, partly because they are so easy to learn to use and are well suited for informal group design sessions. On the other hand, UML can and does have a place with XP projects. It all depends on the specific project, and the personalities of the programmers involved.

In many ways, XP is a programmer first process. The pair programming, the 40-Hour workweek, and the need for constant communication and feedback, are all programmer friendly practices. This fact alone may be responsible for the rapid rise of interest in XP in the OO programming community. XP principles are even being applied to other methodologies, such as efforts to build a variant of RUP that uses XP practices.

DSDM

The Dynamic Systems Development Method, or DSDM, is an open standard for a development process originally based on Rapid Application Development, or RAD, principles. It is targeted for developing business systems on tight time schedules.

The DSDM Consortium met for the first time in 1994, and had 16 originating founders. The goal of the DSDM Consortium was the development of a public domain RAD methodology. Currently, most active DSDM support is based in Europe.

The main source for information about DSDM is its website, www.dsdm.org. DSDM is independent of any particular set of software tools or techniques, and can be adapted to common object-oriented or structured analysis and design practices.

Somewhat like RUP, the DSDM lifecycle is iterative and incremental. It has a core five phase process that can be adapted to the particular project:

5. Iterative and incremental development is necessary to converge on an accurate business solution.

Note that this is only a brief outline of DSDM. The website has much more information.

Crystal - Adaptive Software Development

The developers of two lightweight methodologies, Jim Highsmith with Adaptive Software Development, and Alistair Cockburn with Crystal, have recently joined forces to unify their work on light and self-adaptive methodologies. Highsmith and Cockburn are well known names in object-oriented software development circles.

While the combined methodology is still in development, it is likely to be an important alternative. Both Highsmith and Cockburn were signatories of the Agile Alliance manifesto, so the new combined effort will no doubt reflect those values.

Open Source Development

The methodologies we've talked about so far all have one thing in common, they are all commercial products, and other than DSDM, all proprietary to one degree or another. Someone has an interest in each, and usually with a goal of financial gain. Rational Software sells many support tools for the RUP. The developers of the other methodologies all profit from books, consulting, or providing training. There is nothing wrong with this, but that is a fact.

The Open Source movement is somewhat of a contrast. The main tenant of open source is that the source code of any program is available for anyone to see, use, and adapt. Open Source software is usually released under one of several licenses (see the Open Source website, www.opensource.org, for details of specific licenses). Even though the source code is open, people can still get financial gain by adding value to the software through support and training.

The best known example of a successful open source project is the Linux operating system. What is commonly called Linux is really a combination of an operating system kernel originally written by Linus Torvalds combined with a large collection of software utilities developed by the GNU project. All are open source software licensed under the GNU Public License (GPL).

While open source is one way to release and license software, it also can be considered a development methodology. A definite set of conventions and customs that really describe how to develop open source software have evolved since the beginning of the open source software movement.

While some commercial companies are releasing code that once was proprietary under various open source licenses, most open source programs were developed by individuals spread all over the world. For most open source programs, the development process is really a distributed development model.

Open Source is Distributed Development

A typical open source program usually originates with a single dedicated programmer who sees a need for a specific program and writes it. Sometimes a small group of programmers will band together to build a program. If the program is useful, it usually attracts a user community when it is released. These users become the customers who beta test the program, and suggest changes. Sometimes, they even contribute changes directly to the source code. The original author incorporates the changes, and releases new versions.

As the size and popularity of a program grows, it may attract many other developers. The original author often then becomes the program's coordinator, and serves mostly to coordinate and incorporate changes contributed by other developers, and to sanction official releases.

Most of this effort is undertaken by self-selected volunteer programmers. Linux is a prefect example of this. Originally, the Linux kernel was pretty much the result of Linus Torvalds' individual effort. Eventually, tens of thousands of programmers have contributed to the whole that makes up Linux. Many years after the first versions of the Linux kernel were released, Linus Torvalds still serves as the main coordinator.

The Web has really made the open source distributed development model possible. First, the Web provides a potentially huge base of users and developers for any program. Web sites, e-mail, and user groups provide a worldwide network needed for this base of users and developers to communicate.

Once an open source program reaches the point that it has many users and developers, it requires some level of management. In the open source development model, program management can almost be considered as an inverted organization from traditional management.

First, it is the programmers who have the most control of a project. They are mostly self-selected volunteers who work on a program for the experience and fun of it. The programmers listen to user feedback, and then decide where to take the program based on a combination of the feedback and their own personal interests. The many developers involved with a program will ultimately decide what the final features are through consensus reached in group discussions carried out on the Web or by e-mail. The source code is usually held in a central repository (such as www.sourceforge.org), and changes most commonly submitted using Concurrent Versions System, or CVS.

One of the main principles of open source development is to release early and release often. It is common practice to have what are known as stable releases at infrequent intervals, and separate development snapshots that are updated frequently.

It usually up to the development coordinator to take care of the details of building a release version of a program, and then providing for its distribution. The coordinator is really just that, a coordinator and not a manager. This is the opposite of traditional management, where the programmers are guided by the manager. With open source, it is the programmers with most of the control.

Another feature of open source development is the many-eyes method of testing and quality control. The idea is that with the source code open to examination by anyone, that after enough eyes have examined the code, that most bugs will be spotted by someone or other. There is also the idea that since programmers know their code will be viewed by many others, that the peer pressure will encourage them to write their best code.

For the most part, open source really does deliver relative bug-free code. Linux, for example, is well known for its rock solid stability. It is nearly impossible to crash.

But, there are problems. Since open source is heavily dependent on volunteer programmers, it is difficult or impossible to have fixed feature sets or specific release deadlines. Even so, open source development does tend to respond to change and produce new code quickly. Some contributor to a project will often have a personal stake in adding a specific feature, and the release often philosophy sees to it that such enhancements are available almost immediately.

One of the main problems with open source development is quality code. While the peer review does tend to bring out the best in programmers, many open source developers are relatively new and inexperienced. While open source code generally works and is modified, it is not necessarily all that readable or maintainable compared to code developed under a good common coding standard.

Open source development is not necessarily object-oriented. If the original developer was an experienced object-oriented designer, it is possible for an open source program to be a well-designed object-oriented system. However, much open source software is designed on a more-or-less ad hoc basis, and isn't necessarily object-oriented.

There are some large software companies thriving on the open source model, but it remains to be seen if the approach will be viable over the long term. But the open source development model has merit, and some of its principles apply to any development methodology. And open source programs need not die since their source will remain available for others to take over if necessary.

Resources

Methodologies

Extreme Programming Explained: Embrace Change, Kent Beck, Addison-Wesley, 2000, ISBN 0-201-61641-6.

Object-Oriented Analysis and Design With Applications, Grady Booch, Addison-Wesley, 1994, ISBN 0-201-54435-0.

Object-Oriented Modeling and Design, James Rumbaugh, et al., Prentice Hall, 1991.

Object-Oriented Software Engineering: A Use Case Driven Approach, Ivar Jacobson, et al., Addison-Wesley, 1992.

Object-Oriented Systems Design, An Integrated Approach, Edward Yourdon, 1994, Yourdon Press, ISBN 0-13-6363325-3.

The Rational Unified Process: An Introduction, Philippe Kruchten, Addison-Wesley, 2000, ISBN 0-201-70710-1.

The Cathedral and the Bazaar, Eric S. Raymond,
tuxedo.org/~esr/writings/cathedral-bazaar/index.html

Web Sites

The Essence of Object Oriented Programming with Java and UML