from the editor Editor in Chief: Steve McConnell (cid:2) Construx Software (cid:2) software@construx.com Closing the Gap Steve McConnell Y ears ago, Fred Brooks commented, world problems? “The gap between the best software en- (cid:2) Does the practice generally slow down gineering practice and the average prac- the programmers? tice is very wide(cid:151)perhaps wider than (cid:2) Can the practice be misapplied? in any other engineering discipline.” (cid:2) Is information available about the risks The past few years have seen a prolifer- involved with using the practice? ation of books on project manage- (cid:2) Does the practice include information ment, requirements, architecture, about how to integrate it with existing design, testing(cid:151)nearly every area of practices? software engineering. But within the (cid:2) Must the practice be applied in its en- companies I visit in my consulting tirety to realize significant benefits? business, I rarely see software engineering best practices being used. In- These are all fair questions, and I think creasingly, I ask myself, “Why aren’t it’s healthy for practitioners to ask them. In- people using the numerous good deed, part of IEEE Software’s mission is to software engineering practices that help our readers answer these questions. are now so readily available?” However, the practices I’m thinking of are hardly new, and, for many of them, I believe Classic barriers to innovation many of these questions have already been A conventional answer to this question is answered. Table 1 lists numerous practices that many of these practices simply aren’t that leading organizations have understood yet mature. When presented with a new well and deployed for decades. practice, software practitioners tend to ask In the management arena, we’ve had au- tough questions such as these:1 tomated estimation tools since the early 1970s, but most projects don’t use them. (cid:2) Do experimental results prove conclu- Measurement has been a key topic for 25 sively that the practice will work in the years, but few organizations collect quanti- field? tative data on their projects. I still see soft- (cid:2) Are successes a result of the practice it- ware developers housed in open work bays self, or might they be the result of the or cubicles far more often than I see them people using it? working in private or semiprivate offices— (cid:2) Is the practice complete, or does it need even though research about the effect of to be adapted or extended before it can physical environment on productivity has be applied? been conclusive for more than 15 years. (cid:2) Does the practice have significant over- One of the most fundamental practices in head (training, documentation) that off- software engineering is change control, espe- sets its value in the long run? cially as it relates to software requirements. I (cid:2) If the practice was developed in a re- teach a two-day workshop based on my book search setting, does it apply to real- Software Project Survival Guide (Microsoft Copyright © 2002 Steven C. McConnell. All Rights Reserved. January/February 2002 IEEE SOFTWARE 3 FROM THE EDITOR Table 1 Year of introduction of rarely used DEPARTMENT EDITORS software best practices Bookshelf: Warren Keuffel, Best practice Year first described in print or first wkeuffel@computer.org available commercially Construction: Andy Hunt and Dave Thomas, Pragmatic Programmers, Project planning and management practices {Andy, Dave}@pragmaticprogrammer.com Automated estimation tools 1973 Country Report: Deependra Moitra, Lucent Technologies Evolutionary delivery 1988 d.moitra@computer.org Measurement 1977 Design: Martin Fowler, ThoughtWorks, fowler@acm.org Productivity environments 1984 Loyal Opposition: Robert Glass, Computing Trends, Risk management planning 1981 rglass@indiana.edu Manager: Don Reifer, Reifer Consultants, dreifer@sprintmail.com Requirements engineering practices Quality Time: Jeffrey Voas, Cigital, Change board 1978 voas@cigital.com Throwaway user interface prototyping 1975 STAFF Joint Application Design 1985 Senior Lead Editor Dale C. Strok Design practices dstrok@computer.org Information hiding 1972 Group Managing Editor Design for change 1979 Crystal Chweh Associate Editors Jenny Ferrero and Construction practices Dennis Taylor Source code control 1980 Staff Editors Incremental integration 1979 Shani Murray, Scott L. Andresen, and Kathy Clark-Fisher Magazine Assistants Quality assurance practices Dawn Craig Branch-coverage testing 1979 software@computer.org Inspections 1976 Pauline Hosillos Art Director Toni Van Buskirk Process improvement Cover Illustration Software Engineering Institute’s Dirk Hagner Software Capability Maturity Model 1987 Technical Illustrator Alex Torres Software Engineering Process Groups 1989 Production Artist Carmen Flores-Garvey Executive Director Press, 1998). When I originally devel- practice’s central role in software pro- David Hennage oped the workshop, I included a mod- ject control, I am puzzled about why Publisher Angela Burgess ule on change control, because I could software projects don’t use this funda- Assistant Publisher easily pull together the necessary mate- mental practice universally. Dick Price rials and I was working under some Membership/Circulation deadline pressure. I assumed that it Barriers to software Marketing Manager Georgann Carter would be too basic for most of my stu- innovations Advertising Assistant dents and that I would need to replace Software presents unique chal- Debbie Sims that module as soon as I had time. To lenges to adopting better practices. CONTRIBUTING EDITORS my surprise, three years later, after One challenge is a lack of awareness teaching the class about 20 times, I’ve that good practices exist. Where, ide- Greg Goth, Denise Hurst, Gil Shif, Keri Schreiner, and Margaret Weatherford had only one group of students in ally, should someone learn about fun- which more than half were already us- damental software engineering prac- ing change control. Change control tices? In most fields, we expect Editorial:All submissions are subject to editing for clarity, style, and space. Unless otherwise stated, bylined articles has been described in the software en- universities to provide education in the and departments, as well as product and service descrip- gineering literature since 1978, but the fundamentals. Until very recently, tions, reflect the author’s or firm’s opinion. Inclusion in IEEE Softwaredoes not necessarily constitute endorsement basic practice has been employed in however, most undergraduate degree by the IEEE or the IEEE Computer Society. other branches of engineering for at programs related to computer pro- To Submit:Send 2 electronic versions (1 word-processed and 1 postscript or PDF) of articles to Magazine Assistant, least 50 years. All the tough questions gramming have not including training IEEESoftware, 10662 Los Vaqueros Circle, PO Box 3014, Los Alamitos, CA 90720-1314; software@computer.org. Ar- listed earlier were answered for change in these basic practices. Additional ticles must be original and not exceed 5,400 words including control decades ago. Considering the university programs are coming online figures and tables, which count for 200 words each. 4 IEEE SOFTWARE January/February 2002 FROM THE EDITOR EDITOR IN CHIEF: Steve McConnell 10662 Los Vaqueros Circle each year, and I think the lack of in- open a basic question: Why don’t Los Alamitos, CA 90720-1314 software@construx.com frastructure is due simply to software software engineers(cid:151)who are some of EDITOR IN CHIEF EMERITUS: engineering’s being such a young field. the brighter people on the planet(cid:151) Alan M. Davis, Omni-Vista In the absence of university educa- seek out better methods of doing tion systems, we might expect soft- their work? We’re all aware of the ASSOCIATE EDITORS IN CHIEF ware-producing companies them- pain arising from not using these Design: Maarten Boasson, Quaerendo Invenietis boasson@quaerendo.com selves to provide supplemental practices. So why don’t practitioners Construction: Terry Bollinger, Mitre Corp. training. In fact, a few leading com- more actively seek them out and use terry@mitre.org Requirements: Christof Ebert, Alcatel Telecom panies do train their software engi- them? christof.ebert@alcatel.be neers, but not to an extent great With all the advances during the Management: Ann Miller, University of Missouri, Rolla enough to ameliorate industry-wide past several years, it appears that the millera@ece.umr.edu Quality: Jeffrey Voas, Cigital software problems. challenge for the software industry voas@cigital.com In less advanced companies, the has shifted from good-practice devel- Experience Reports: Wolfgang Strigel, Software Productivity Center; strigel@spc.ca lack of training has been more diffi- opment to good-practice deployment. cult to address. Before a manager can EDITORIAL BOARD prescribe training, he needs to know W Don Bagert, Texas Tech University that a field of knowledge is deep hat do you see as the barriers to Richard Fairley, Oregon Graduate Institute Martin Fowler, ThoughtWorks enough to need training. Managers deployment of good practices? Robert Glass, Computing Trends who came up through the technical How do you think good prac- Andy Hunt, Pragmatic Programmers Warren Keuffel, independent consultant ranks 20 years ago, or even 10 years tices can be deployed more quickly? I Brian Lawrence, Coyote Valley Software ago, might underestimate the depth of invite your comments. Karen Mackey, Cisco Systems knowledge in modern software engi- Deependra Moitra, Lucent Technologies, India Don Reifer, Reifer Consultants neering. Many software managers are Suzanne Robertson, Atlantic Systems Guild not themselves well trained enough to Dave Thomas, Pragmatic Programmers Karl Wiegers, Process Impact realize that their staff needs training. INDUSTRY ADVISORY BOARD Calling all experts Reference Robert Cochran, Catalyst Software (chair) These are all descriptions of what 1. S.A. Raghavan and D.R. Chand, “Diffusing Annie Kuntzmann-Combelles, Q-Labs Software-Engineering Methods,” IEEE Soft- Enrique Draier, PSINet has not been done, but they still leave ware, vol. 6, no. 4, July 1989, pp. 81–90. Eric Horvitz, Microsoft Research David Hsiao, Cisco Systems Takaya Ishida, Mitsubishi Electric Corp. Andy Hunt and Dave Thomas Join IEEE SoftwareEditorial Board Dehua Ju, ASTI Shanghai Donna Kasperson, Science Applications International Andy Hunt and Dave Thomas, founders of The Pragmatic Programmers LLC, Pavle Knaflic, Hermes SoftLab Günter Koch, Austrian Research Centers recently joined IEEE Software’s Editorial Board. Wojtek Kozaczynski, Rational Software Corp. Prior to joining Pragmatic Programmers, Hunt worked in various senior posi- Tomoo Matsubara, Matsubara Consulting tions at Discreet Logic, Alias Research, Philips Medical Systems, and AT&T. He re- Masao Matsumoto, Univ. of Tsukuba Dorothy McKinney, Lockheed Martin Space Systems ceived his BS in information and computer science at the Geor- Nancy Mead, Software Engineering Institute gia Institute of Technology. He is a member of the IEEE Stephen Mellor, Project Technology Susan Mickel, AgileTV Computer Society, the ACM, and Independent Computer Con- Dave Moore, Vulcan Northwest sultants Association. Melissa Murphy, Sandia National Laboratories Thomas cofounded and ran a software company in the Kiyoh Nakamura, Fujitsu Grant Rule, Software Measurement Services United Kingdom prior to joining Pragmatic Programmers. Girish Seshagiri, Advanced Information Services Thomas holds an honor degree in computer science from Lon- Chandra Shekaran, Microsoft Andy Hunt don University. He is a member of the IEEEComputer Society Martyn Thomas, Praxis Rob Thomsett, The Thomsett Company and the ACM. John Vu, The Boeing Company Hunt and Thomas have coauthored two books, The Prag- Simon Wright, Integrated Chipware Tsuneo Yamaura, Hitachi Software Engineering matic Programmer: From Journeyman to Master(Addison- Wesley, 2000), and Programming Ruby: The Pragmatic Pro- MAGAZINE OPERATIONS COMMITTEE grammer’s Guide(Addison-Wesley, 2001). They have also writ- George Cybenko (chair), JamesH. Aylor, Thomas J. ten a number of articles together, including “Learning to Love Bergin, Frank Ferrante, Forouzan Golshani, Rajesh Gupta, Steve McConnell, Ken Sakamura, M. Satya- Unit Testing” for Software Testing and Quality Engineering narayanan, Nigel Shadbolt, Munindar P. Singh, Dave Thomas Magazine(Jan. 2002) and “Programming in Ruby” for Dr. Francis Sullivan, James J. Thomas Dobb’s Journal(Jan. 2001). Individually and together, they have also given nu- PUBLICATIONS BOARD merous talks and tutorials at conferences and workshops. Rangachar Kasturi (chair), Mark Christensen, Contact Andy Hunt at andy@pragmaticprogrammer.com and Dave Thomas at George Cybenko, Gabriella Sannitti di Baja, Lee Giles, Thomas Keefe, Dick Kemmerer, dave@pragmaticprogrammer.com; www.pragmaticprogrammer.com. Anand Tripathi January/February 2002 IEEE SOFTWARE 5 design Editor: Martin Fowler (cid:2) ThoughtWorks (cid:2) fowler@acm.org Modeling with a Sense of Purpose John Daniels I t’s all a question of purpose. These days, especially with UML diagrams—it isn’t al- practically everyone involved in devel- ways so obvious. oping software draws pictures that represent some aspect of the software or its Implementation, specification, and requirements. They do this to improve conceptual models their own understanding and, usually, to I call a model built to explain how some- communicate that understanding to others. thing is implemented an implementation But all too often, the understanding is mud- model and a more abstract model that ex- dled and confused because the designer plains what should be implemented a speci- hasn’t clearly established the pic- fication model. Both are models of software ture’s purpose or explained how systems, and if confusion often exists be- others should interpret it. Surpris- tween these two models, then far greater ingly, this is true even when the confusion surrounds the relationship be- designer uses an established mod- tween models of software and models of eling standard, such as the Unified real-world situations. Modeling Language (UML). In software projects, we frequently need For many years, it has been to find ways of gaining a better understand- common practice for database de- ing of the real-world problem to be solved. signers to create logical models Consequently, we often produce informa- and physical models. Typically, de- tion models that depict the items of infor- signers represent a logical model mation in a particular business situation and using some form of the entity-relationship their relationships, but two issues immedi- (ER) diagram, whereas they ultimately repre- ately arise. sent a physical model using a schema held by First, what should be the scope of such the database engine. The important difference models? As we saw with the Great Corpo- is the level of abstraction: a logical model ig- rate Data Modeling Fiasco of the 1980s and nores the constraints that the underlying data- 1990s, where large enterprises invested base technology imposes and presents a sim- heavily in attempts to capture all the infor- plified view. mation used in an organization, these mod- Sometimes physical database designs are els easily become so large that they are im- also drawn using ER diagrams but with ex- possible to keep up to date. The solution to plicit attributes for foreign keys that repre- this issue is, of course, to model only those sent relationships. So, when presented with parts of the organization needed to repre- an ER diagram I’ve never seen before, I sent the current situation of interest—not to must establish its purpose before I can un- worry too much about the bigger picture. derstand it. Fortunately, with an ER dia- Second, these models have no value un- gram, it’s usually easy to see what kind of less we can directly apply their content to model this is, but in other circumstances— system-building projects. Unfortunately, for 8 IEEE SOFTWARE January/February 2002 0740-7459/02/$17.00 © 2002 IEEE DESIGN reasons that I will explain shortly, the approach claiming to offer the most assistance with this—object-oriented design—has been slow to deliver ef- fective processes. I’ll refer to all models of situations in the world—of which information World Specification Software models are one example—as conceptual models; other terms that are Built to specify, Built to explain, used include essential models, do- Built to understand, interpreted as interpreted as main models, business models, and interpreted as constraints on descriptions of even, most confusingly in my view, statements of fact behavior behavior analysis models. So we have three Model of the Abstract model Model of world of software software kinds of models (see Figure 1) for Systematic correspondence quite different purposes: Conceptual model Specification model Implementation model (cid:2) Conceptual modelsdescribe a situation of interest in the world, such Figure 1. Three modeling perspectives. as a business operation or factory process. They say nothing about how much of the model is imple- cess, but the yearning for this corre- modeling the structure of things; life mented or supported by software. spondence between the conceptual gets much more complicated when (cid:2) Specification modelsdefine what a and implementation models has over- we attempt to model behavior. If we software system must do, the in- simplified the process of moving be- construct an implementation model formation it must hold, and the between them. One reason why this of an object-oriented program—for havior it must exhibit. They as- process is more complicated than example, one written in Java—we as- sume an ideal computing platform. we’d like is that, given the complexity sume that software objects cooperate (cid:2) Implementation models describe of modern layered application archi- by sending each other synchronous how the software is implement- tectures, we find different representa- messages. It might or might not be ed, considering all the computing tions of the same concept in many dif- satisfactory to adopt the same para- environment’s constraints and ferent parts of the application. digm when creating specification limitations. models of object systems, but that Notation overload paradigm is certainly useless if we Most of the modeling I’ve done has The examples we’ve looked at so want to capture the world’s concur- been in the field of object and compo- far—information models and data- rent and unpredictable nature in a nent systems, where opportunities for base models—are concerned with conceptual model. confusion between these three model- Despite these obvious problems, ing perspectives are particularly large. many methodologists devising ways This is because with object-oriented of designing object-oriented systems software, we are always striving to during the late 1980s and 1990s per- make the software elements that make sisted with the claim that conceptual up our program (classes, in most ob- models could be built using only the Given the complexity ject-oriented languages) correspond concepts of object-oriented program- closely to problem-domain concepts of modern layered ming. Furthermore, they claimed that with similar names. So, if our concep- the process of moving from concep- application tual model contains the concept of tual model to code was one that sim- customer, our software will contain architectures, we ply involved elaboration rather than direct representations of customers, mapping or translation. Although find different and our software customers will have we’ve since learned the hard way that similar attributes to their real-world representations of the this is too simplistic, that realization counterparts. same concept in many hasn’t been manifested in the model- We want this correspondence being notations we use or in the way different parts of the cause it improves traceability between people are often taught to use them. requirements and code, and because it application. Consider, for example, the facilities makes the software easier to under- in the UML for describing software stand. In this respect, object-oriented structure. The primary and ubiquitous programming has been a great suc- notation for this is the class diagram, January/February 2002 IEEE SOFTWARE 9 DESIGN Figure 2. One notation, three <> <> models. Conceptual Order UrgentOrder model deliveryCharge: Money <> deliveryCharge: Money <> Specification Order model deliveryCharge: Money isUrgent: Boolean beUrgent() <> DeliveryStrategy 1 <> getCharge(): Money Implementation Order model deliveryCharge(): Money isUrgent(): Boolean beUrgent() <> <> RegularDelivery UrgentDelivery getCharge(): Money getCharge(): Money S and we should be pleased that this rel- The same applies to all UML no- o, if a class diagram depicting an in- atively simple notation has proved tations. Table 1 shows how I use the formation model is, despite appear- useful for depicting everything from main UML notations within each ances, saying something fundamen- the structure of Web sites to the layout kind of model. A blank cell indicates tally different from a class diagram of XML documents. But its generality that I don’t use that notation within specifying the chosen object structures is part of the problem. Even within that kind of model, but surely you’ll in our software, doesn’t that just make the limited scope of a single develop- be able to find someone who does. So life more difficult and confusing? No. ment project, you’ll typically find it’s vital that whenever you use one By having these strong distinctions, we class diagrams used for a range of of these notations, you indicate can model at different levels of abstrac- purposes, including the structural as- clearly both what kind of model this tion at different times and separate the pects of all three kinds of models dis- is part of and precisely what you’re concerns that apply at the different lev- cussed earlier. Figure 2 illustrates this trying to depict. els. To get these benefits, though, mod- with a simple example. In the concep- The UML would be much better if elers must be very clear in their minds tual model, we are happy to use mod- it had a built-in understanding of the about the different perspectives pro- eling features that aren’t generally three kinds of model and at least in- vided by the three kinds of models, and supported by programming environ- sisted that you state which one you my experience is that even many expe- ments, such as dynamic subtyping. In are building. Unfortunately, it doesn’t, rienced developers have yet to think the implementation model, we use so unless you are lucky enough to be clearly about all this. They need to get only features that our chosen lan- working with UML tools that support a sense of purpose. guage directly supports, and we show profiles, the best you can do is use implementation choices such as the UML’s stereotype feature to mark John Danielsis a consultant at Syntropy Limited. Contact use of the strategy pattern here. model elements appropriately. him at john@syntropy.co.uk. Table 1 Using the main UML notations with conceptual, specification, and implementation models Diagrams Conceptual model Specification model Implementation model Use case — Software boundary interactions — Class Information models Object structures Object structures Sequence or collaboration — Required object interactions Designed object interactions Activity Business processes — — Statechart Event-ordering constraints Message-ordering constraints Event or response definitions 10 IEEE SOFTWARE January/February 2002 software construction Editors: Andy Hunt and Dave Thomas (cid:2) The Pragmatic Programmers andy@pragmaticprogrammer.com (cid:2) dave@pragmaticprogrammer.com Ubiquitous Automation Civilization advances by extending the number of important operations we can perform without thinking. —Alfred North Whitehead Welcome to our new column on software Many authors and pundits have compelling argu- construction. We hope that you’ll enjoy follow- ments for each of these viewpoints.1–3This is un- ing this series as we explore the practical nuts- derstandable because all the views have merit— and-bolts issues of building today’s software. software development is all these things, and this Before we start, though, we need to talk about plurality is what causes so much misunderstand- the column’s title. In some ways, “construction” is ing. When should we act like engineers, and an unfortunate term, in that the most immediate when shouldn’t we? (and often used) example involves building con- Many organizations still view coding as merely struction, with the attendant idea of an initial and a mechanical activity. They take the position that inviolate architecture from which springs forth de- design and architecture are of paramount impor- sign and code. tance and that coding should be a rigorous, repeatable, mechanistic process that can be rele- gated to inexpensive, inexperienced novices. We wish these organizations the best of luck. We’d like to think we know a better way. The SWEBOK (Software Engineering Body of Knowl- edge—view an online draft at www.swebok.org), for instance, states unequivocally that coding is far from a mechanistic translation of good design into code, but instead is one of those messy, im- precise human activities that requires creativity, in- sight, and good communication skills. Good software is grown organically and evolves; it is not Of course, nothing could be further from the built slavishly and rigidly. Design and coding must truth. Software development, including its con- be flexible. We should not unduly constrain it in a struction, is utterly unlike any other human en- misguided attempt to turn coders into robots. deavor. (Software development is also exactly the However, the way we construct software same as all other human endeavors, but that’s a should not be arbitrary. It must be perfectly con- topic for another time.) Software is unique in both sistent, reliable, and repeatable, time after time. its malleability and its ephemerality; it is (to bor- And that’s the topic of this first column. row the title of a Thomas Disch book) the dreams —Andy Hunt and Dave Thomas our stuff is made of. Yet we cannot simply wish a software system into being. We must create it using some semblance of engineering practice. This References tension between the nonrepeatable, ill-defined, 1. P. McBreen, Software Craftsmanship: The New Impera- chaotic creative process and the scientific, repeat- tive, Addison-Wesley, Reading, Mass., 2001. able, well-defined aspects of engineering is what 2. T. Bollinger, “The Interplay of Art and Science in Soft- causes so much heartburn in practitioners, au- ware,” Computer, vol. 30, no. 10, Oct. 1997, pp. 128, 125–126. thors, and scholars. 3. W. Humphrey, Managing the Software Process, Addi- Is software engineering? Is it art? Is it craft? son-Wesley, Reading, Mass., 1989. 0740-7459/02/$17.00 © 2002 IEEE January/February 2002 IEEE SOFTWARE 11 SOFTWADREEP TCO TNISTTLERUCTION I f software construction is to in- that every developer on a project com- tests to try to find holes in our soft- volve engineering, the process piles his or her software the same way, ware. (There are many other, equally must be consistent and repeat- using the same tools, against the same important, reasons for using unit able. Without consistency, know- set of dependencies. Make sure this tests, but that’s the subject of another ing how to build, test, or ship compilation process is automated. article.) However, most developers someone else’s software (or even This advice might seem obvious, we’ve seen skip unit testing or at best your own software two years later) is but it’s surprising how often it’s ig- do it in an ad hoc way. The standard hard, if not impossible. Without re- nored. We know teams where some technique goes something like this: peatability, how can you guarantee developers compile using the auto- the results of a build or a test run— matic dependencies calculated by 1. Write a wad of code. how do you know the 100,000 CDs their integrated development environ- 2. Get scared enough about some as- you just burned contain the same ment, others use a second IDE, and pect of it to feel the need to try it. software you think you just tested? still others use command-line build 3. Write some kind of driver that in- The simple answer is discipline: tools. The result? Hours wasted every vokes the code just written. Add a software construction must be disci- week tracking down problems that few print statements to the code plined if it is to succeed. But people aren’t really problems, as each devel- under test to verify it’s doing what don’t seem to come that way; in gen- oper tests against subtly different ex- you thought it should. eral, folks find discipline hard to take ecutables generated by his or her in- 4. Run the test, eyeball the output, and even harder to maintain. Fortu- dividual compilation system. and then delete (or comment out) nately, there’s a pragmatic solution: Nowadays, automated compila- the prints. automate everything you can, so that tions are pretty straightforward. Most 5. Go back to Step 1. the development environment itself IDEs offer a single-key “compile the provides the disciplined consistency project” command. If you’re using Let us be clear. This is not unit test- and repeatability needed to make the Java from the command line, there’s ing. This is appeasing the gods. Why process run smoothly and reliably. the Ant tool (http://jakarta.apache.org/ invest in building tests only to throw This approach leaves developers free ant/index.html). In other environ- them away after you’ve run them to work on the more creative (and ments, the “make” system, or less once? And why rely on simply scan- fun) side of software construction, common variants such as Aegis (www. ning the results when you can have which makes the programmers hap- pcug.org.au/~millerp/aegis/aegis.html), the computer check them for you? pier. At the same time, it makes the do the same job. Whatever the tool, Fortunately, easy-to-use automated accountants happier by creating a de- the ground rules are the same: provide testing frameworks are available for velopment organization that is more a single command that works out most common programming lan- efficient and less prone to costly hu- what needs to be done, does it, and re- guages. A popular choice is the set of man-induced errors and omissions. ports any errors encountered. xUnit frameworks, based on the Gamma/Beck JUnit and SUnit systems Compilation automation Testing automation (www.xprogramming.com/software. If you do nothing else, make sure During construction, we use unit htm). We’ll look at these frameworks Career Opportunities PURDUE UNIVERSITY compilers, databases, distributed and research. Salary and benefits are highly Department of Computer Sciences parallel computing, geometric modeling competitive. Special departmental and and scientific visualization, graphics, in- university initiatives are available for ju- The Department of Computer Sciences formation security, networking and oper- nior faculty. Candidates should send a at Purdue University invites applications ating systems, programming languages, curriculum vitae, a statement of career for tenure-track positions beginning Au- scientific computing, and software engi- objectives, and names and contact infor- gust 2002. Positions are available at the neering. The department implements a mation of at least three references to: assistant professor level; senior positions strategic plan for future growth which is Chair, Faculty Search Committee will be considered for highly qualified ap- strongly supported by the higher admin- Department of Computer Sciences plicants. Applications from outstanding istration. This plan includes a new build- Purdue University candidates in all areas of computer sci- ing expected to be operational in 2004 to West Lafayette, IN 47907-1398 ence will be considered. Areas of particu- accommodate the significant growth in Applications are being accepted now lar interest include security, networking faculty size. Further information about and will be considered until the positions and distributed systems, scientific com- the department is available at are filled. Inquiries may be sent to puting, and software engineering. http://www.cs.purdue.edu. fac-search@cs.purdue.edu. The Department of Computer Sciences Applicants should hold a Ph.D. in Purdue University is an Equal Opportu- offers a stimulating and nurturing acade- Computer Science, or a closely related nity/Affirmative Action mic environment. Thirty-five faculty discipline, and should be committed to employer. Women and minorities are es- members have research programs in excellence in teaching and have demon- pecially encouraged to apply. analysis of algorithms, bioinformatics, strated strong potential for excellence in 12 IEEE SOFTWARE January/February 2002 SOFTWADREEP TCO TNISTTLERUCTION in later articles. For now, it’s enough it work when it gets there? Think have no shoes. Often, people who de- to point out that they are simple to about how much of this process you velop software use the poorest tools use, composable (so you can build can automate, allowing the quality to do the job. You can do better than suites of tests), and fully automated. assurance staff to concentrate on the that. Learn how to automate your Remember when we talked about hard stuff. environment—write macros if your making the build environment con- Never underestimate the effort re- IDE supports it; grab your favorite sistent? Well, the same applies to quired to do all this. The cycle times scripting language if it doesn’t (Ruby testing: you need repeatable test envi- of testing the process are large. Every is a good choice; see www.ruby- ronments. However, that’s not to say small problem means starting again, lang.org). Get your computer to do they should all be the same. Test in a compiling and testing and so on. as much of the repetitive and mun- wide variety of situations—some However, there’s a trick: don’t leave dane work as you can. Then you can bizarre, some commonplace. Expose build automation until the end. In- move on to the really hard stuff. See your code to the true range of target stead, make it part of the very first you next issue. environments. Do it as early as possi- project iteration. At this stage it will ble during development. And do it as be simple (if incomplete). Then ar- Andy Hunt andDave Thomasare partners in The automatically as you can. range for it to run at least daily. This Pragmatic Programmers, LLC. They feel that software consul- Once you can compile code with a has two advantages. First, the build’s tants who can't program shouldn't be consulting, so they keep current by developing complex software systems for their button press, and test it soup-to-nuts, products give your quality assurance clients. They also offer training in modern development tech- what’s next? Integration, reviews, re- folks something to work with: anyone niques to programmers and their management. They are co- lease, perhaps—all fertile ground for can take a build snapshot at any time. authors of The Pragmatic Programmer andProgramming Ruby, both from Addison-Wesley, and speak on development practices the seeds of automation. And then Second, you get to find out that the at conferences around the world. Contact them via www. there’s the lowly shipping process. delivery build process failed the day it pragmaticprogrammer.com. Here automation is especially crucial. failed. The fixes will be immediate If you can’t reliably go from source and incremental. in the repository to code on a CD, how do you know what you’re ship- Other uses of automation ping? Every delivery is a stressful sit- We’ve barely scratched this topic’s uation, where each manual step must surface. Consider that you needn’t be completed correctly if the four-bil- restrict automation lion-odd bits on the CD are to be the to the build or even MIT correct ones. Too often, though, to just develop- transferring and replicating comment. Perhaps your pleted software is a heavily manual project has strict re- process, one that allows the intro- porting require- duction of all sorts of needless risks. ments, review and SOFTWARE ENGINEERING What this part of the whole process approval processes, FACULTY POSITION needs is an automated delivery build. or other onerous The Aeronautics and Astronautics Departmentat MIT, a leader in the What is an automated delivery secretarial chores. design and development of complex aircraft, space, transportation, build? At a minimum, it involves Where possible, try information and communications systems, has a faculty opening in the clean-room compilation, automated to automate these Aerospace Information Systems Division. The department seeks candidates for a position in software engineering for aerospace running of the unit tests, automated bits of drudgery as applications, available in September 2002.The successful candidate will running of whatever functional tests well. There’s more have a Ph.D.and relevant SW engineering research credentials in one or can be automated, and automated to constructing more of these areas: requirements specification and analysis, assurance techniques, human-machine interaction, software design for collection of the deliverable compo- software than just embedded systems, safety, reliability and other quality attributes, nents (not forgetting documentation) constructing soft- software fault tolerance, or real-time application issues like scheduling into some staging area. (Speaking of ware, and we can and verification.A joint professorship with Computer Science is possible. documentation, how much do you leverage automa- MIT encourages women and underrepresented minorities to apply.Send two copies of cover letter (which includes a statement of interest) and of currentlyproduce automatically? How tion throughout the your c.v.with the names and addresses of three individuals who will much could you? After all, the more process. provide letters of recommendation, by January 15, 2002, to:Professor documentation you automate, the Edward F. Crawley, Head, MIT Department of Aeronautics and more likely it will be up-to-date.) The cobbler’s Astronautics,33-207,77 Massachusetts Avenue,Cambridge,MA 02139-4307;or by electronic mail to:aa-fac@mit.edu (MS Word or Once you’ve generated your ship- children plain text).http://web.mit.edu/aeroastro/www/core/html pable software, take it to the next As we said in level, and automate the testing of the The Pragmatic Pro- MASSACHUSETTS INSTITUTE OF TECHNOLOGY result. Can the pile of bits you’re grammer (Addison- An Equal Opportunity/Affirmative Action Employer Non-Smoking Environment proposing to deliver be installed in Wesley, 2000), the web.mit.edu/personnel/www typical customer environments? Does cobbler’s children January/February 2002 IEEE SOFTWARE 13 focus guest editors’ introduction Building Software Securely from the Ground Up Anup K. Ghosh,Cigital Chuck Howell,MITRE James A. Whittaker,Florida Institute of Technology s software professionals first and computer security researchers sec- A ond, we believe that most computer security articles published in industry magazines focus on fixing security problems after the fact. Indeed, many of these “fixes” tend to be point solutions that address symptoms of a much larger problem and fail to address the root causes of the real computer security problem. Our assessment of the state of the industry motivated us to pull together a special theme issue for IEEE Software focusing on how to build software systems ally focus on addressing an enterprise’s se- securely from the ground up. curity defenses (such as firewalls, routers, Of course, we’re not the only people who server configuration, passwords, and en- believe that systems must be built this way. cryption) rather than on one of the key un- Richard Clarke, the US President’s Special derlying causes of security problems—bad Advisor for Cyberspace Security, admon- software. ished our industry at the Business Software Although point solutions are often neces- Alliance’s Global Technology Summit in sary, they are inadequate for securing Inter- Washington, D.C., on 4 December 2001: net-based systems. Point solutions are tem- porary barriers erected to stem the tide of To start, members of the IT industry attacks from unsophisticated attackers. In a must build information security into sense, point solutions are simply bandages their products at the point of development and not treat it as an afterthought. on a broken machine; they might stop some bleeding, but the wound underneath still festers. Fundamentally, we believe the prob- Break the cycle lem must be fixed at its core by building se- The types of approaches and point solu- cure, robust, survivable software systems. tions advocated by computer security pro- For this issue, we solicited articles from soft- fessionals to date have aimed at system ad- ware researchers and professionals to pro- ministrators, chief information officers, and vide guidance and innovation for building other personnel involved in system infra- software systems to be resistant to attack. structure management. These solutions usu- We start from the premise that most se- 14 IEEE SOFTWARE January/February 2002 0740-7459/02/$17.00 © 2002 IEEE

IEEE Software (January/February)

Similar IEEE Software (January/February)