Practice
Computing Applications Practical programmer

A Deja-Vu Look at Software Engineering Researchers Who Care About Practice

Reflections on institutes performing practice-relevant research.
Posted
  1. Article
  2. References
  3. Author

I’ve long argued that there is a tremendous communication chasm between computing theory and computing practice. I first made that observation in a keynote address I delivered in the early 1970s, and if anything I think the chasm has grown deeper and broader since then.

So it has been a particular pleasure to me to acknowledge some folks, over the years, who have tried to overcome that chasm. My favorite people in the quest to overcome that chasm are researchers who go out of their way to do research that is relevant to practice.

There are all too few of them, unfortunately.

My favorite places, in that regard, are institutes that devote themselves to pragmatic research. I had previously acknowledged, in an article titled "Software Productivity Improvement: Who’s Doing What?" (see [1]) three such institutes that were doing what I consider meaningful, practice-focused research: The Microelectronics and Computer Technology Consortium (MCC), then located in Austin, TX; the Software Engineering Institute (SEI) in Pittsburgh; and the Software Productivity Consortium (SPC), then located in Reston, VA.

That was then, this is now. The MCC closed a number of years ago, the SEI still does some practice-focused research but is better known for its Capability Maturity Model advocacy work, and the SPC has changed enough that it is difficult to recognize it (its name is now the "Software and Systems Consortium"). And that leaves us with the question, who is doing practice-focused research today?

I am pleased to say there are three relatively new software institutes that are trying to ensure the research they perform is relevant to practice. This column will be devoted to comparing and contrasting the three software institutes.

The three institutes to which I’m referring are: the Fraunhofer Center, located in both Germany and in Maryland; the National Information and Computing Technology Center of Australia (NICTA); and the Simula Research Laboratory in Norway. (It is interesting to note the growing international flavor of this kind of research.)

All three of these institutes are focused more broadly than just software engineering. But the Fraunhofer organization has as a subset a group focused on "Experimental Software Engineering" (in Germany, Fraunhofer Institute for Experimental Software Engineering (IESE); in Maryland, Fraunhofer Center for Experimental Software Engineering (FC-MD)). And NICTA has a similarly named group exploring "Empirical Software Engineering." And finally, Simula has a department specifically focused on "Software Engineering."

I’m not a big believer in "vision" and "mission" statements—they’re all too often full of meaningless promises—but it’s interesting to compare the highest, goal-focused view of these three organizations.

Fraunhofer states "our mission is to advance the state-of-the-practice in software development and acquisition organizations by applying state-of-the-art research results." Fraunhofer’s work emerges in part from the historically significant explorations of Vic Basili’s Software Engineering Laboratory (SEL), combining the strengths of the academic University of Maryland Computer Science Department, NASA-Goddard’s government space flight support role, and the industry efforts of Computer Sciences Corp.

NICTA has a vision that focuses on "use-inspired ideas and products transforming the Australian software engineering sector," and a mission "to develop research ideas and products capable of transforming the … software engineering sector, underpinned by evidence about software engineering process and product collected by empirical research methods." Whereas academe starts from "what we know," NICTA says it "starts from what we don’t know."

Simula aims to "be an international leader in understanding software engineering technologies … proposing and validating theories on the basis of experiments and other empirical studies, primarily conducted in software development organizations."

All three, in other words, are clearly focused on the blending of research/theory and practice, the absence of which I have lamented for a long period of time. All three organizations are also performing a blend of exploration and consulting, offering as a product/service technology transfer of the successful ideas they study.

Staffing at all three organizations is significant. Fraunhofer has approximately 20 scientists in Maryland, and more than 100 in Germany. NICTA empirical software engineering has nearly a dozen senior faculty/staff participants, and at any one time nearly two dozen graduate/Ph.D. candidate students. Simula also has nearly a dozen faculty researchers, and a slightly smaller number of Ph.D. and graduate students. But Simula also uses as experimental subjects paid consultants, to ensure they are studying real practitioners, not student surrogates.

It is interesting to explore the directions all three institutes are taking, topic by topic:

  • Process: All three institutes have process-focused groups, pursuing process as a means of improving our ability to build software.
  • Risk: Both Fraunhofer and NICTA pursue studies of the role of risk management in software development.
  • Architecture: Once again, both Fraunhofer and NICTA are looking into architecture approaches.
  • Measurement: … and both are also looking into metrics.
  • After those three similarities, differences begin to appear. NICTA includes "measurement" as part of its process group, "requirements" as part of its risk studies, and "adaptive software" as part of architecture. Simula has a group devoted to object-oriented analysis and design, and studies use case approaches to requirements therein. Fraunhofer also has groups devoted to: product lines (as part of its architecture group); a "best practices" clearinghouse; encouraging the use of "experience factories"; high-dependability product requirements; reading and inspection; and product quality. Simula also explores improvements of expert judgment-based cost estimation approaches and ways of conducting empirical software engineering research, including methods and tools.

In my view, it is refreshing that these institutes see the software engineering world of needs through such diverse facets. They may tend to aggregate around certain topics, and yet each has cut a different path in the search for findings of value to practitioners.

It is important for practitioners to keep abreast of what these software engineering institutes are learning and offering. I encourage you to contact these institutes for further information; fc-md.umd.edu, or rcleaveland@fc-md.umd.edu, to contact Fraunhofer’s experimental software engineering group in Maryland (or, in Germany, iese.fraunhofer.de or dieter.rombach@iese.fraunhofer.de); nicta.com.au, or ross.jeffery@nicta.com.au to contact NICTA’s empirical software engineering group; and simula.no or dagsj@simula.no to contact Simula’s software engineering group.

Back to Top

Back to Top

    1. Glass, R.L. Software Conflict version 2.0. Developer.*Books (an independent publisher accessible at www.DeveloperDotStar.com), 2006 (this is an updated version of the original book published by Prentice-Hall's Yourdon Press in 1991).

Join the Discussion (0)

Become a Member or Sign In to Post a Comment

The Latest from CACM

Shape the Future of Computing

ACM encourages its members to take a direct hand in shaping the future of the association. There are more ways than ever to get involved.

Get Involved

Communications of the ACM (CACM) is now a fully Open Access publication.

By opening CACM to the world, we hope to increase engagement among the broader computer science community and encourage non-members to discover the rich resources ACM has to offer.

Learn More