Communications of the ACM
Forum
Forum
The article "An Empirical Investigation of the Effectiveness of Systems Modeling and Verification Tools" by Anand Jeyaraj and Vicki L. Sauter (June 2007) seemed to have it backward by focusing on why "users do not adequately understand the system for which we seek approval." Rather, the great unrecognized major cause of function creep is our failure as software developers to understand users' business needs. Such failure is due largely to our mistaken belief that these needs are whatever we decide they are and that vague, high-level business requirements inevitably decompose into detailed product/system/software requirements.
One does not simply specify user requirements; one must discover them within the business environment. One specifies a design in response to business requirements, as I discuss in my book Discovering Real Business Requirements for Software Project Success. A design does not have to be technical. A product or system solution is itself a design but is not likely to be right when specified without a detailed definition of the business requirements it's intended to meet.
Robin F. Goldsmith
Needham, MA
Authors' Response:
We don't disagree with Goldsmith's view of how to design effective systems. However, there is a point where analysts must confirm whether they understand the system (as it is) so they can appreciate its related problems and opportunities; there is also a point where analysts must convey their understanding of user needs. It is for these two points in time that analysts tend to use the tools we described in our article.
Inappropriate use of tools inhibits communication between users and analysts. Users set the requirements. But analysts who fail to understand them cannot develop effective systems.
Anand Jeyaraj
Dayton, OH
Vicki L. Sauter
St. Louis, MO
Name That Abstraction
I have long had the same feeling as the one Jeff Kramer spelled out in his "Is Abstraction the Key to Computing?" (Apr. 2007) that programming is essentially concerned with the creation of abstractions. However, I am also convinced that there is an additional essential step: naming the abstractions being created.
I often say to novice programmers that the most difficult part of programming is choosing names. I mean to be provocative but increasingly also really believe it. If you were able to create an abstraction and devise a name that meaningfully captures the essence of that abstraction (in a way that makes sense to another programmer sometime in the future), then you understand programming.
Alistair Edwards
York, U.K.
Jeff Kramer's point that abstraction is a key skill for computing (Apr. 2007) is true but needs to be extended. The general definition of abstraction in software should include problem analysis, but what about the synthesis/implementation of the solution? A software developer must create the associated algorithms in order to know whether the attributes chosen during the process of abstraction are correct and ultimately can be processed.
Implementation invariably involves debugging. It then becomes apparent that all the long-recognized stages of writing software are inextricably linked and that all associated skills are required. I don't think I've ever run across anyone who was outstanding at computing but had only one of these skills.
Which people are typically good at computing? Smart ones, clearly, and standard IQ tests, while perhaps controversial, do a fairly good job identifying them. One definition of general intelligence could be the ability to generally understand and deal with complexity, especially under time pressure. Having it is indeed necessary to be good at computing. Still, it is not sufficient, since other abilities are also needed (such as attention to detail).
Alex Simonelis
Montreal
To Ensure Security, Improve Software Quality
We like Michael Wolfe's suggested improvement to our medical analogy he discussed in his "Forum" comment "See Past Self-Proclaimed Experts' Open-Source Security Evaluations" (May 2007). He was referring to our article "Increased Security Through Open Source" (Jan. 2007) in which we claimed that open source increases security. Indeed, in The Netherlands, doctors and hospitals are evaluated based on published reports of their performance, and openness and transparency increase quality. For software, better quality ensures better security.
The fact that these evaluations are usually done by organizations, not by individual users, doesn't matter. The point is that users decide which organizations they can trust. They might also hire outside organizations to do the evaluations for them. Moreover, users of software are not just consumers like you and me but might also be governments and businesses, with the budgets to perform whatever evaluations might be needed.
Jaap-Henk Hoepman
Bart Jacobs
Nijmegen, The Netherlands
©2007 ACM 0001-0782/07/0800 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2007 ACM, Inc.
No entries found