the field (see the âArticlesâ sidebar). References. 1. M. Fayad, M. Laitinen, and R. Ward, âSoftware Engi- neering
focus
guest editors’ introduction
Software Engineering in the Small Mauri Laitinen, Laitinen Consulting Mohamed Fayad, University of Nebraska, Lincoln Robert Ward, Ofoto.com
A
s a sign of its increasing maturity, the software engineering community has begun to accommodate the needs of different development organizations. Organization size, customer needs, product cost, time to market, and product safety all affect the way software will be built. If it is a part of a line of products,
compatibility with other products becomes a primary design issue. As our community has become more comfortable with the methods and processes required to build software, we recognize that the methods developed for large systems are not optimal for all systems. In particular, development done by small groups does not always fit into the development model originated to cope with large, contract-based software. Software engineering originally targeted
large, contract-based development for defense and industry, and the discipline has achieved significant improvement in that area. Although contract software is no less important than it was, there are so many more types and modes of development that deserve serious investigation from a software engineering standpoint. There are three reasons to advance the study of software engineering in the small: ■ ■ ■
changes in the industry, underestimates of the number of small companies, and the differences in small group development methods from the standard models.
Industry Change Although the predicted Y2K cataclysm fizzled, even those people who hitherto hadn’t paid much attention became acutely aware of how much the industrialized world relies on computers and on the software that runs them. That growing awareness of our dependence on computers forces us to recognize the importance of engineering reliable software. 0740-7459/00/$10.00 © 2000 IEEE
September/October 2000
IEEE SOFTWARE
75
Articles The six articles in this section are evenly divided between European and US contributors and show a particular breadth of application. The first article, Tore Dyba’s “Improvisation in Small Software Organizations,” examines the idea of structured improvisation in software using a jazz metaphor. Dyba discusses the limitations of rationalistic, best-practice–based approaches applied to small groups in turbulent environments. The article suggests that improvisation leads to exploration of new and better-adapted development methods. Such exploration can also lead to failures. In contrast to failures in the large, small-group failures should be seen as a way of developing new competencies. In “Applying Product Line Concepts in Small and Medium-Sized Companies,” Peter Knauber, Dirk Muthig, Klaus Schmid, and Tanya Widen present the Pulse software engineering method, which addresses the challenges of small companies that must grow single
About the Editors Mauri Laitenen’s biography
appears on page 80. Mohamed Fayad is the J.D. Ed-
wards Professor, Computer Science & Engineering, at the University of Nebraska, Lincoln. He received an MS and a PhD in computer science from the University of Minnesota at Minneapolis. He coauthored OO Enterprise Frameworks and Software Stability (John Wiley and Sons, New York). He is a senior member of the IEEE, a senior member of the IEEE Computer Society, a member of the ACM, and an editorial advisor and a columnist for The Communications of the ACM. Contact him at the Dept. of Computer Science and Eng., Univ. of Nebraska, Lincoln, Ferguson Hall, Lincoln, NE 68588-0115;
[email protected]; www.cse.unl.edu/~fayad. Robert Ward is director of product engineering at Ofoto.com. He has more than 15 years’ experience as a software engineer, primarily developing business applications. He is a member of the IEEE and the ACM. Contact him at
[email protected].
76
IEEE SOFTWARE
products into product lines. The article introduces a set of processes to help tie the architecture to product variants that meet the needs of various market niches. The authors discuss the method’s analysis of product scope, domains, common components, customization, and reuse to achieve lines of products from a single core. “A Software Development Process for Small Projects,” by Melissa Russ and John McGregor, addresses the issues adapting an iterative development process to small groups. Particularly interesting is the idea that processes must be matched to the group to be useful and used. It discusses ways of reducing the number of processes to match group bandwidth while retaining effective project control. As we have discussed elsewhere, the consequences of overloading processes or using ill-adapted ones is magnified in small groups.1,2 The fourth article in this section, Vaclav Rajlich’s “Incremental Redocumentation Using the Web,” introduces a Web-based method of
The last decade has changed both the character of the software industry and the composition of the companies engaged in development. Mass market, the Internet, and game software are large industry segments, subject to intense competition. With PCs doing the complex computing tasks that once required mainframes, small companies have sprung up to create all sorts of software. Groups of six or fewer software developers now commonly create products in excess of 100,000 source lines in 18 to 24 months. Mass-market software companies have their own set of development and maintenance issues that relate not only to their size but also to dealing with the large volume of shipped products. For example, effective distribution of maintenance and feature updates requires specialized forms of development and testing. Startup companies have development needs that are almost in a class by themselves. Development speed is a primary concern, even as development for reuse might be consciously avoided. These specialized needs combine with the challenges of framework and component integration that play an increasing role in modern software building. Traditional software engineering has paid little attention to these industry segments that small companies often perform. Underestimating the Number of Small Companies The overwhelming majority of companies developing software are small—a fact that’s often overlooked. According to the US Bureau of the Census 1995 County Business Patterns, almost 90% of software and data-processing companies have fewer than 50 employees.1 The
September/October 2000
rate of small startups continues to grow, with the industry’s prepackaged software segment growing especially dramatically. We suspect that these figures are conservative. According to the American Electronics Association, the growth in software employment has increased dramatically in the last few years.2 Because industry statistics often omit temporary workers, the growth in softwarerelated work is greater than officially reported. Moreover, these numbers do not include companies whose primary product is not software, but who still develop software for in-house use or for sale. We expect that the 2000 census data will show an even larger shift toward small companies. Here’s the critical point: at least one person in each company should be versed in appropriate software engineering techniques. Given the preponderance of small and very small companies, we find it all the more compelling that we pay attention to their development needs. One Size Does Not Fit All Small groups, especially those developing mass-market and Internet software products, rarely work according to the published formal contract models. Although they are intensely interested in best practices, software engineers in small organizations find it difficult to separate the methods useful to them from the methods needed only to coordinate multiple large groups. These differences surface in three main ways: ■
Management is so richly structured in large organizations that it is difficult to
documenting changes for programs that is especially valuable for small groups. The method was motivated by the high cost of code comprehension in maintenance and the unequal demands that code “ownership” makes on some developers. Using a hypertext annotation system, it links information about code and design to the corresponding source. The opportunistic approach provides the most information about parts of the system that are most volatile. Additionally, new task assignments can be given to the first available programmer rather than waiting for code’s owner to become available. New developers can also come up to speed more quickly. “When to Test Less,” by Tim Menzies and Bojan Cukic, presents a new model of testing that allows small organizations to reduce the testing burden without appreciably impairing test effectiveness. The model partitions the odds of finding program faults into three categories and shows that in one case the chances of fault finding peak within a few dozen tests. The other cases require hundreds to
■
■
adapt to the small. The specialized functions, reporting arrangements, and metrics are hard to scale down. Software architecture reflects organization architecture. In software engineering circles, this is known Conway’s law, which states, “Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations.”3,4 Many methods such as inspection and testing were created to work on larger, nondistributed groups. These methods need serious reworking to adapt them to smaller groups and groups where the members are not physically colocated.
A
lthough software professionals have known for years that large-scale systems needed the discipline of software engineering to build software that met time, cost, and performance goals, they have only recently started looking at the particular needs of different types of development. We now realize that small-scale software engineering is not just a degenerate case of large-scale software engineering but an important subfield in its own right. We trust that the articles presented here will spur further research work in the field (see the “Articles” sidebar). References 1. M. Fayad, M. Laitinen, and R. Ward, “Software Engineering in the Small,” Comm. ACM, Vol. 43, No. 3, Mar. 2000, pp. 115–118.
thousands of test cases to find defects. For projects that are not safety-critical, the model says that a limited set of test cases using random inputs yields the majority of faults. Only cost- and timeprohibitive exhaustive testing would do a better job. With “Wisdom: A Software Engineering Method for Small Software Development Companies,” Nuno Nunes and João Cunha introduce a project method that turns speed, flexibility, and good communication into a coherent, evolutionary prototyping approach. This UML-based approach does not require expensive CASE support. It features strong customer interaction that fits well with the business needs of many small companies.
References 1. M. Fayad and M. Laitinen, Transition to Object-Oriented Software Development, John Wiley & Sons, New York, 1998. 2. M. Laitinen and M. Fayad, “Surviving a Process Performance Crash,” Comm. ACM, Vol. 41, No. 2, Feb. 1998, pp. 83–86.
2. CyberNation: The Importance of the High-Technology Industry to the American Economy, American Electronics Assoc., Santa Clara, Calif., 1997. 3. M.E. Conway, “How Do Committees Invent?” Datamation, Vol. 14, No. 4, 1968, pp. 28–31. 4. J. Herbsleb and R. Grinter, “Architectures, Coordination, and Distance: Conway’s Law and Beyond,” IEEE Software, Vol. 16, No. 5, Sept./Oct. 1999, pp. 63–70.
