"Computer programming is a human activity." | ||
| --(Weinberg 1971) | ||
Individuals choose software development as their career domain for a variety of reasons. Some read Popular Science and Popular Mechanics at home, gravitated to the one programming course available in high school, majored in engineering or computer science in college, and thereby directed their lives down this specific technical path. For others, it was serendipity; being at a place in space and time when the need for software was apparent, we could participate in meeting that need, and it gradually evolved into a full-time commitment in the field.
In any case, it was the allure of technology that kept the flame burning: We love the bits and bytes, the operating systems, the databases, the development tools, the keyboard shortcuts, the languages. Who else but software developers could have developed the UNIX operating system? We are focused on technology, and that is our driving motivation. Perhaps because of an innate genetic tendency or perhaps because we skipped all the "softer" classes in college—psychology, drama, or, even worse, English!—we are generally focused less on the people side of our business and more on the bits and bytes. We tend not to party well,[1] and some of us have trouble relating to people outside of work, when there is no common technology substrate on which to base a discussion.
One result of this, which was further compounded by the simple single-user nature of the tools we used and the more limited size of the applications we developed, was the tendency toward software development as an individual activity. The programmer defined, designed, wrote, and, typically, tested his or her own work. Perhaps testers were around to help with the heavy lifting at the end, but the focus clearly was on individual activity. The programmer as hero was the common paradigm.
"Software Development has become a team sport." | ||
| --(Booch 1998) | ||
At some point, the game changed. Why? Watts Humphrey (1989) observed that
the history of software development is one of increasing scale. Initially, a few individuals could hand craft small programs; the work soon grew beyond them. Teams of one or two dozen individuals were then used, but success was mixed. While many organizations have solved these small-system problems, the scale of our work continues to grow. Today, large projects typically require the coordinated work of many teams.
Humphrey goes on to observe that complexity continues to outpace one's ability to solve these problems intuitively as they appear. For example, we are involved in a requirements project that simultaneously affects approximately 30 products in a broad product family. The requirements that are being generated influence, in real time, the software being written by more than 400 programmers at distributed locations. Making this project a success requires intense coordination of a "team of teams" all working in a common methodology to address the requirements challenge.
What's to be done? Clearly, we have to make the "team thing" work and work well. As Boehm (1981) points out in the COCOMO cost estimation model, the capability of the team has the greatest impact on software production. Davis (1995b) supports this conclusion in his discussion of team productivity: "optimizing the productivity of all individuals does not necessarily result in optimizing the productivity of the team" (p. 170). So, it seems logical that we invest some of our resources in making software teams more productive.
This book is organized around the six team skills that are necessary for a modern software team to address the requirements challenge.
In Team Skill 1, Analyzing the Problem, we develop a set of techniques the team can use to gain a proper understanding of the problem that a new software system is intended to solve.
In Team Skill 2, Understanding User Needs, we introduce a variety of techniques the team can use to elicit requirements from the system users and stakeholders. No one set of techniques will work in all situations; nor will it be necessary for the team to master all of the techniques. But with a little practice and some judicious picking and choosing, the team will gain a much better ability to understand the real needs that the system must address.
In Team Skill 3, Defining the System, we describe the initial process by which the team converts an understanding of the problem and the user's needs to the initial definition of a system that will address those needs.
In Team Skill 4, Managing Scope, we arm the team with the ability to do a better job of managing the scope of the project. After all, no matter how well understood the needs are, the team cannot do the impossible, and it will often be necessary to negotiate an acceptable deliverable before success can be achieved.
In Team Skill 5, Refining the System Definition, we help the team organize the requirements information. Further, we introduce a set of techniques the team can use to elaborate on the system definition, or refine it to a level suitable to drive design and implementation, so that the entire extended team knows exactly what kind of system it is building.
Finally, in Team Skill 6, Building the Right System, we cover some of the more technical aspects of design assurance, verification, validation testing, and change management, and we show how traceability can be used to help ensure a quality outcome.
One of the most interesting things about teams is that individual team members have different skills. After all, that's what makes a team a team. Walker Royce (1998) points out that
balance and coverage are two of the most important aspects of an excellent team…. A football team has a need for diverse skills, very much like a software development team…. There has rarely been a great football team that didn't have great coverage, offense, defense, and special teams, coaching and personnel, first string and reserve players, passing and running. Great teams need coverage across key positions with strong individual players. But a team loaded with superstars, all striving to set individual records and competing to be the team leader, can be embarrassed by a balanced team of solid players with a few leaders focused on the team result of winning the game.
In the software team, we hope that some players have proven their ability to work with the customers effectively, that others have software programming abilities, and that others have testing abilities. Still other team players will need design and architecture abilities. Many more skills are required as well. We also expect that the requisite team skills for requirements management will affect various members of the teams in various ways. So, in a sense, we'll hope to develop every team member's ability to help manage requirements effectively. And we'll try to indicate, where we can, which team members may be best suited to a particular and necessary skill.
Software development is exceedingly complex, and the domains in which we apply our skills vary tremendously. It therefore seems unlikely that one specific way to organize a software team will work in all cases or is inherently more efficient than other approaches. Nonetheless, certain common elements occur in many successful teams. Therefore, we think it's important to establish a hypothetical team construct. But rather than invent an ideal team, which would be too easy and too academic, we decided to pattern our hypothetical team on a real software development team.
The team we'll model is based on a real-world software team that has proved effective in two major areas: (1) effective requirements management and (2) delivering on time and on budget. (Of course, we believe that this is an obvious cause-and-effect relationship!) Yet we also admit that many other skills must be present in a team that truly delivers the goods year in and year out. In our case study, the team works for a company called Lumenations, Ltd., that is developing a next-generation "home lighting automation system" for high-end residential use.
We can meet another objective in this book if we can develop a case study we can track from requirements start to requirements finish. In this way, we will be able to not only apply the techniques that we are about to discuss to our example but also provide example work products, or artifacts, to further illustrate key points and to serve as examples for your own projects. Appendix A of this book provides a sample set of artifacts from the case study.
Lumenations, Ltd., has been a worldwide supplier of commercial lighting systems for use in professional theater and amateur stage productions for more than 40 years. In 1999, its annual revenues peaked at approximately $120 million, and sales are flattening. Lumenations is a public company and the lack of growth in sales—no, worse, the lack of any reasonable prospect for improving growth in sales—is taking its toll on the company and its shareholders. The last annual meeting was quite uncomfortable, as there was little new to report about the company's prospects for growth. The stock climbed briefly to $25 last spring on a spate of new orders but has since crept back down to around $15.
The theater equipment industry as a whole is flat with little new development. The industry is mature and already well consolidated. Since Lumenations' stock is in the tank and its capitalization is only modest, acquisition is not an option for the company.
What's needed is a new marketplace, not too remote from what the company does best, but one in which there is substantial opportunity for growth in revenue and profits. After a thorough market research project and spending many dollars on marketing consultants, the company has decided to enter a new market: lighting automation for high-end residential systems. This market is apparently growing at 25%–35% a year. Even better, the market is immature, and none of the established players has a dominant market position. Lumenations' strong worldwide distribution channel will be a real asset in the marketplace, and the distributors are hungry for new products. Looks like a great opportunity!
The project we choose will be the development of HOLIS, our code name for an innovative new HOme Lighting automation System to be marketed by Lumenations. The HOLIS team is typical in its size and scope. For the purposes of our case study, we've made it a fairly small team, composed of only 15 team members, but it's large enough to have all the necessary skills fairly well represented by individuals with some degree of specialization in their roles. Also, it's the structure of the team that's most important, and by adding more developers and testers, the structure of the HOLIS team proved to scale well to a size of 30–50 people and commensurately larger software applications than HOLIS will require.
To address the new marketplace, Lumenations has set up a new division, the Home Lighting Automation Division. Since the division and technology are mostly new to Lumenations, the HOLIS team has been assembled mostly from new hires, although a few team members have been transferred from the commercial lighting division.
Figure 3-1 is an organization chart of the development team and the relationships among the team members. We'll revisit this team periodically throughout the book and see how it applies its new skills to the requirements challenge for HOLIS.
It's difficult for anyone to argue rationally against the idea of managing and documenting the requirements of a system in order to ensure that we deliver what the customer really wanted. However, as we have seen, the data demonstrate that, as an industry, we often do a poor job of doing so. Lack of user input, incomplete requirements and specifications, and changing requirements and specifications are commonly cited problem causes in projects that failed to meet their objectives. And we do know that a significant number of software projects do fail to meet their objectives.
A common attitude among developers and customers alike is that "even if we're not really sure of the details of what we want, it's better to get started with implementation now, because we're behind schedule and in a hurry. We can pin down the requirements later." But all too often, this well-intentioned approach degenerates into a chaotic development effort, with no one quite sure what the user really wanted or what the current system really does. With today's powerful and easy-to-use prototyping tools, there's a perception that if the developers can build a rough approximation of the user's needs in a prototype, the user can point out the features that need to be added, deleted, or modified. This can work, and it is an important aspect of iterative development. But due in part to the extremely high cost of fixing requirement errors, this process must be within the context of an overall requirements management strategy, or chaos results.
How do we know what the system is supposed to do? How do we keep track of the current status of requirements? How do we determine the impact of a change? It's because of issues like these that requirements management has begun to emerge as both a necessary and a practical software engineering discipline. We have introduced an encompassing philosophy of requirements management and have provided a set of definitions that support these activities.
Since the history of software development—and the future for at least as far as we can currently envision it—is one of increasing complexity, we also understand that the software development problem is one that must be addressed by well-structured and well-trained software teams. In the requirements management discipline in particular, every team member will eventually be involved in helping manage the requirements for the project. These teams must develop the requisite skills to understand the user needs, to manage the scope of the application, and to build systems that meet these user needs. The team must work, as a team, to address the requirements management challenge.
In order to do so, the first step in the requirements management process is to ensure that the developers understand the "problem" the user is trying to solve. We'll cover that topic in the next three chapters as Team Skill 1, Analyzing the Problem.
[1] During a 1979 RELA open house, for example, one programmer remained at his desk throughout the party, programming happily, even though his desk was in the middle of the party room. After finishing his work, he simply got up, arranged his desk, and left the building without a word to anyone. What is unusual about this behavior? In our industry? Nothing!