Software Development Methods
Software Development Methods
It is well known that software development is a complex process. This process suffers from problems such as budget overruns, late delivery, and, maybe most important, failing to meet the customer s needs.
In his famous article, No Silver Bullet [Brooks87], Frederick Brooks presents his argument that even though the software development community seeks a silver bullet ”a software method that may solve such problems ”such a bullet is not foreseen. However, because software should go on being developed (whether we have the silver bullet or not), this chapter focuses on software development methods highlighting their human perspective.
Specifically , we focus on three software development methods: Spiral Model, Unified Process (UP), and eXtreme Programming (XP). There are other software development methods, but these three are accepted today by many software practitioners and are used by many software houses . Our intention in this chapter is neither to teach the development methods nor to outline their details. There are many software engineering books that address software development methods. Rather, our intention is to illustrate the human aspects of these development methods and to increase the reader s awareness of these aspects when they come to evaluate and adopt a specific development method. Because XP emphasizes the human aspect of software development, the majority of this chapter discusses this method.
For each method we describe how the four basic activities of the paradigm of software engineering ”specifying, designing, coding, and testing ”are implemented. The rationale for this set of activities, on which most of the accepted software development methods are based, is explained in Chapter 8, where the history of software engineering is presented. In addition to having common characteristics, the three methods implement abstraction and information hiding (see Chapter 8), and all use iterations; that is, the development process is incremental.
We chose this organization to reflect the fact that though a set of activities are conceived and accepted as the core of software engineering, they may be implemented in different ways (depending on people s orientation and preferences, types of projects, etc.). We hope that this organization will help those who are interested in analyzing other methods of software development.
Spiral Model
The Spiral Model of software development is defined by Barry Boehm [Boehm88]. Primarily, Boehm thought of his method as a risk-reducing method. It is called the Spiral Model because the software continually gets larger as each increment goes through the activities of specifying, designing, coding, and testing several times.
The Spiral Model begins with engineers trying to build the least-known kernel of the software. The idea is that the part that needs most exploration is the riskiest. A portion of the risk is poor time estimation because we do not know what it will take to build the software. Another portion of the risk is the sheer unknowns. The first spiral through software development is meant to respond to these risks, and, if possible, to build an active kernel on which later software can hang (see Figure 2.1). Engineers should then decide which is the next most risky component and build it, going through the activities again. This cycle is repeated until the software is complete.
Figure 2.1: The Spiral Model.
Risks are addressed in decreasing complexity. The software is grown rather than just developed. The Spiral Model is the first complete capturing of the principal characteristics of modern software engineering. It is iterative and goes through specifying, designing, coding, and testing during each iteration.
The Spiral Model is one of the last modifications to the Waterfall Model (see Chapter 8). As such, it has the nascent origins of human aspects. Most are encapsulated in risk reduction. Humans worry a lot about risk. The Spiral Model, in reducing risks, eases the minds of the managers who choose it.
| Tasks |
|
Unified Process
The Unified Process (UP) bills itself as use-case driven, architecture-centric , iterative, and incremental. The third characteristic, and consequently the last, are a result of the software development paradigm (see Chapter 8). Use cases and architecture pervade the UP.
Use cases are what the user wants a computer system to do, not how to do it. Formal descriptions of use cases contain pre-conditions and post-conditions. Actors in use cases can be either persons or other systems. Both are depicted in the Unified Modeling Language (UML) as a stick figure. As an example, a withdrawal at an automated teller machine (ATM) could be one type of use case; a program that needs reservations from a flight is another. In a way, use cases represent the object-oriented view of the world. Objects represent real-world things just as use cases reveal real-world activities and relations.
UP takes advantage of these things. It is often misnamed the Rational Unified Process (RUP) since Rational has done more to popularize it. Rational was bought by International Business Machines (IBM) in February 2003.
UP is the international standard for development, especially software development. It consists of running the paradigm activities of software development through several iterations, one or more of which are phases (see Figure 2.2).
Figure 2.2: The Unified Process.
Eighty percent of the use cases are made during the Inception and Elaboration phases, which drive part of the shape of design with minimal code and tests. The use cases represent the highest risks, and the requirements can be derived from them. An important product at the Initiation phase is a Vision document for the software.
At the Elaboration Phase, more of the use cases are done, engineers revise the architecture, if needed, and more code and tests are completed. The Use Case View and some of the Analysis View of the Unified Modeling Language (UML) help here.
| Task | Select a system with which you work on a daily basis. Identify what use cases define this system. |
The next phase, by now probably the third iteration, is the Construction Phase. The project ramps up in personnel to actually build the software. Although Brooks Law [Brooks95] states that adding personnel to a late software project will make it later , adding planned expansion to an on-time project is all right.
The last phase is the Transition Phase, which contains activities often done in other projects, but not part of most methods. These activities include training, begun in earlier phases, and installation. Few methods actually spell these out like UP does.
Basically, the architecture is driven as a complement to the use cases. Some use cases represent business drivers, and thus are key contributors to the architecture. Requirements and the Vision statement are products of use cases. The architecture is more refined during the Elaboration Phase, and little ought to be done to it in either the Construction or Transition Phases. Specifying, designing, coding, and testing are done as part of the workflows of UP, each assigned to a person with a specific job. They know exactly what to do in each phase [Jacobson99].
The human aspect of UP begins with the use cases. Each shows something that will be done to the user when he interacts with a component of the software. Since the architecture is extracted from these interactions, there is plenty of opportunity to make the software relevant to humans.
| Task | Discuss how going through the four phases of UP (inception, elaboration, construction, and transition) enlarges the roles of the four activities of software development. |
eXtreme Programming
eXtreme Programming (XP) is one of the agile methods of software development [Beck00]. In general, agile methods are more tied to the human aspects of development (see the Manifesto for Agile Software Development at http://agilemanifesto.org/ ). XP is based on four values that are expressed by 12 practices. The four values are communication, simplicity, feedback, and courage. The 12 practices are the planning game, pair programming, refactoring, simple design, continuous integration, test-first programming, collective ownership, coding standards, short releases, a metaphor, sustainable race, and an on-site customer. Many times, the practices are shown as dependent on each other [Beck00, p. 70].
The reason XP is called extreme is that the volume of each practice is turned up. Let s not just have periodic access to the clients; let s offer to let the clients move into our workplace and communicate their goals, even though that might mean that requirements change. Let s not just program with occasional inspections; let s pair off, using one keyboard and mouse for each pair, and open ourselves to continually finding defects [Williams and Kessler02]. As can be seen, turning up the volume is a metaphor for taking practices to their extreme.
A key concept of the XP method is that of bringing a more humane experience back to programming. With other methods, people who just want to program start by looking at a mountain of documentation and analysis and putting code on paper. XP, as befits a method designed for change, emphasizes rapid delivery of business value to the customer. Therefore, some code is inevitably given to the customer very soon.
There really is no project manager in XP. The closest anyone comes is the Coach. The Coach is usually some senior person, familiar with XP, who keeps everyone on process. Collective ownership of the code, to the point that someone could change someone else s code, works against having hierarchical organizations (see Chapter 3, Working in Teams ).
Pair programming is just that. Each pair codes at one workstation: the driver works the keyboard and mouse, the navigator, looks for defects. Communication can take place at a micro-scale between these two. Traditional managers are often horrified, feeling that pair programming takes twice as much time and effort. In fact, however, it takes less time to fix any defect [Tomayko02], and there is increased corporate knowledge about the product. This leads to knowledge sharing, and if one person leaves the team, the development can go on smoothly, as no private knowledge has been retained.
| Task | Look at the pair programming Web site ( http://www.pairprogramming.com/ ). Summarize the main findings about pair programming presented there. What are your conclusions? |
The client and the developers, fostering macro-level communication, play the Planning Game. The customer comes to the table with a deck of cards, one high-level story per card. The deck is given to the team, which spreads out the cards among themselves , choosing what they are going to do. Their move is to then figure out what tasks make up each story and estimate its length. They then give the cards back to the client, who indicates which stories are most important from the business value standpoint. The team s second move is to give the prioritized stories back to the developers. The developers, knowing their velocity, [1] figure whether they can do the indicated stories in the time of the planned iteration (two to three weeks). They then pass back the lowest priority stories for the client to confirm that is the case and that the customer will receive software that has the highest current value. Then, the developers do load balancing among individuals to further ensure that they can finish the selected stories in the planned iteration. Note that the responsibility for task development is personal, although the development is done in pairs. Furthermore, it is important to note that at the end of each planning game, each developer knows that each team member has the same load. This is very encouraging. This feeling, together with the fact that the responsibility for the development task is personal (although the development itself is done in pairs), almost ensures that free riders do not enter XP teams.
| Task | Discuss connections among load balance and team work (see Chapter 3). |
Empowered, the developers then go to work. There is more contact with the actual people who do the work than clients often have. Similarly, there is more contact with the customer than developers usually have. Note that the developers wind up working on exactly what the client wants now. In addition, as the developers take part in the planning game, they all know the role of each feature they develop (and should not derive this information from a written document).
The Human Aspects of eXtreme Programming
Of the 12 practices of XP, many are humane, particularly the 40- Hour Week (or sustainable pace, or no extended overtime). The practice is based on the assumption that tired programmers make more mistakes.
However, it is in the four values of XP that we find the human aspects of XP most clearly. The first of these is communication. That value is encapsulated in pair programming. Moreover, communication is accomplished by the metaphor, simple design, on-site customer, the Planning Game, and the coding standard.
Members of pairs can speak with each other, and do. They wind up being the grapevine for the project, as change is reflected immediately and constantly in their work. They are the ones who bring the architecture up to date, or modify the database schema.
The metaphor is developed early. It is meant to provide a common language for both developers and clients to discuss the software. As it becomes more entrenched into the project, it leads both developers and clients toward architecture to guide the work of the pairs.
Simple Design will show up again under a different value. Here, it means the design of software architecture, and is easy for the pairs to understand. This way, the pairs can tell at a glance if they are doing work that leads to eventual success.
The Planning Game will also show up later, but here it is a way to communicate individual velocities and customer priorities.
The on-site customer is even more of a communication tool than the pairs. Do you need something clarified? Just shout across the room. This naturally leads to the production of software that the customer needs, not software that the developers assume the customer needs. Indeed, more than once you will hear developers claim that customers do not know what they want. XP helps developers reveal these needs together with the customer in a gradual process.
A coding standard is another aspect of communication. The theory is that everyone looking at the code will see the same style. It is not important what the coding standard looks like, more that there is one. For example, Java has a coding standard on the Sun Web site. Use it! It is okay as long as pairs can move around the code and not be confused as to style. It is clear how naturally the practice of coding standards supports the practice of collective ownership.
Note that communication subsumes most XP practices. Indeed, communication is very much a human characteristic of software engineering.
Simplicity is the second XP value. It is most often exemplified in, of course, simple design, and refactoring (see Chapter 9, Program Comprehension, Code Inspections, and Refactoring ). The main purpose of refactoring is to make the code simpler. It turns out that simpler is hard to do. Constant rewriting of the code, which is refactoring, and simplifying the design as the project progresses are a part of simplification. Another important part is always doing the simplest thing that results in value returned to the customer. Sometimes, people skip refactoring, because it does not add functionality to the code. However, the added value that refactoring has is expressed in later stages of the development when the code is better understood , more readable, and more manageable.
Feedback, the core of modern systems theory [Mindell02], is the third XP value, shown by test-first programming, short releases (frequent builds), continuous integration, and the on-site customer. Test-first programming is the most direct and shortest form of feedback. It shows how an individual unit can be made better and whether the thing that we are working on is functioning. Short releases tell us whether the system is progressing. The customer is there to keep us honest. This value is the closest to at least one tenet of reflective practice in XP (see Chapter 10, Learning Processes in Software Engineering ).
The final value is courage, which is sometimes difficult to describe. It means that optimism is well placed. The 40-hour week (sustainable pace) falls under courage, as does the Planning Game. Basically, we believe that everything will turn out all right in the end. We believe we will find any requirements changes from our customer, and will be able to implement them; hence, no overtime. Everything we decide to do in the Planning Game will be done, if not in this iteration, then in the next. Courage is also expressed by other practices. Courage is needed for refactoring code that has already proved to run and pass all tests; when the ownership of the code is collective, each pair needs the courage to modify code that another pair wrote. Because all these activities are supported by the atmosphere that XP inspires, it is obvious that they are conducted by all team members in order to improve the developed software.
As is illustrated previously, some of the XP practices outline specifically how to behave (e.g., pair programming, sustainable race), others specify what to do (Planning Game, refactoring, continuous integration, test-first programming, coding standards, on-site customer), and yet others may be conceived of as inspiration practices (simple design, collective ownership, short releases, a metaphor). The practices in the first group tell us how to interact with others and with ourselves; the practices in the second group outline very specific guidelines how to carry out the development process; and the practices in the third group are guiding principles that inspire the actual development.
| Tasks |
|
[1] Velocity is like ideal engineering time. It is the total time you can spend each day on the project, minus breaks, pep talks, and other irrelevancies. For example, if we normally work on a project six hours a day, and two hours disappear somewhere, the velocity is .75.
EAN: 2147483647
Pages: 242