|
|
Cornering the Chimera |
| |
R. Geoff Dromey
|
|
Page: 33-43 |
|
doi>10.1109/52.476284 |
|
Full text available:
Publisher Site
|
|
Over the past decade, the term "software quality" has been widely used. In many instances the term has been loosely used in relation to process and product. This has created considerable confusion and diverted the industry from its primary goal - improving ...
Over the past decade, the term "software quality" has been widely used. In many instances the term has been loosely used in relation to process and product. This has created considerable confusion and diverted the industry from its primary goal - improving the quality of the products of the various phases of software development.While some attention has been paid to high-level quality attributes, little has been devoted to the systematic study of tangible product properties and their influence on high-level quality attributes. Today the dominant modus operandi for software development is heavily process-oriented. This rests on the widely held belief that you need a quality process to produce a quality product. The flaw in this approach is that the emphasis on process usually comes at the expense of constructing, refining, and using adequate product quality models. The fundamental axiom of software product quality is: a product's tangible internal characteristics or properties determine its external quality attributes. Developers must build these internal properties into a product in order for it to exhibit the desired external quality attributes. A product quality model, therefore, must comprehensively identify the tangible (measurable and/or assessable) internal product characteristics that have the most significant effect on external quality attributes.I suggest a framework for the construction and use of practical, testable quality models for requirements, design, and implementation. Such information may be used directly to build, compare, and assess better quality software products. expand
|
|
|
Beyond the Black Box: Open Implementation |
| |
Gregor Kiczales
|
|
Pages: 8-11 |
|
Full text available:
Publisher Site
|
|
A forum for exchanging ideas, philosopies, and experience.Encapsulation, informally known as black-box abstraction, is a widely known and accepted principle. However, many practitioners find themselves violating it in order to achieve performance requirements ...
A forum for exchanging ideas, philosopies, and experience.Encapsulation, informally known as black-box abstraction, is a widely known and accepted principle. However, many practitioners find themselves violating it in order to achieve performance requirements in a practical manner. This gap between theory and practice must be filled. Open implementation is a controversial new approach that claims to do just that. The ideas that follow will spark further debate on black-box abstraction (a debate that is taking place, in part, on the Internet). I welcome your responses on this column and the subject at large.¿Tomoo Matsubara expand
|
|
|
Moore's Law: Change or Die |
| |
Ted J. Biggerstaff
|
|
Page: 4-6 |
|
doi>10.1109/MS.1996.476277 |
|
Full text available:
Publisher Site
|
|
In June, members of IEEE Software's Editorial Board and Industry Advisory Board met on how to make the magazine even better. Lots of fascinating and educational discussions and debates ensued. Our boards are not populated by many shy people! One IAB ...
In June, members of IEEE Software's Editorial Board and Industry Advisory Board met on how to make the magazine even better. Lots of fascinating and educational discussions and debates ensued. Our boards are not populated by many shy people! One IAB member, Ted Biggerstaff, offered to write down his perceptions of the challenges that we are likely to face soon, and the opportunities we have to leverage those challenges. The intent was that Ted's position paper would stir further controversy among the board members, and so it has! But it is so well-written and so challenging to the software industry in general, and to our magazine specifically, that I felt it was important to share it with our readers. I do not necessarily agree with everything that is written here, but Ted states his case very well. Please write us and let us know what you think.¿Al Davis expand
|
|
|
Mead Named to Editorial Board |
| |
T. J. Biggerstaff
|
|
Page: 5 |
|
doi>10.1109/MS.1996.476278 |
|
First Page of the Article
First Page of the Article  expand
|
|
|
1995 Best Practice Award |
| |
T. J. Biggerstaff
|
|
Page: 6 |
|
doi>10.1109/MS.1996.476279 |
|
First Page of the Article
First Page of the Article  expand
|
|
|
Beyond the black box: open implementation |
| |
G. Kiczales
|
|
Page: 8, 10-11 |
|
doi>10.1109/52.476280 |
|
Encapsulation, informally known as black-box abstraction, is a widely known and accepted principle. It is a basic tenet of software design, underlying approaches to portability and reuse. However, many practitioners find themselves violating it in order ...
Encapsulation, informally known as black-box abstraction, is a widely known and accepted principle. It is a basic tenet of software design, underlying approaches to portability and reuse. However, many practitioners find themselves violating it in order to achieve performance requirements in a practical manner. The gap between theory and practice must be filled. Open implementation is a controversial new approach that claims to do just that. The paper provides some ideas to spark further debate on black-box abstraction expand
|
|
|
Software Quality: The Elusive Target |
| |
Barbara Kitchenham,
Shari Lawrence Pfleeger
|
|
Page: 12-21 |
|
doi>10.1109/52.476281 |
|
Full text available:
Publisher Site
|
|
If you are a software developer, manager, or maintainer, quality is often on your mind. But what do you really mean by software quality? Is your definition adequate? Is the software you produce better or worse than you would like it to be? In this special ...
If you are a software developer, manager, or maintainer, quality is often on your mind. But what do you really mean by software quality? Is your definition adequate? Is the software you produce better or worse than you would like it to be? In this special issue, we put software quality on trial, examining both the definition and evaluation of our software products and processes. expand
|
|
|
Point-Counterpoint: Do Standards Improve Quality? |
| |
Norman F. Schneidewind,
Norman Fenton
|
|
Page: 22-24 |
|
doi>10.1109/52.476282 |
|
Full text available:
Publisher Site
|
|
Software standards are only one of many factors that influence quality. However, there is ample evidence to suggest that, on balance, standards and their related guides and recommended practices do improve product quality. The paper discusses some examples ...
Software standards are only one of many factors that influence quality. However, there is ample evidence to suggest that, on balance, standards and their related guides and recommended practices do improve product quality. The paper discusses some examples of standards that improve software product quality. It considers whether imperfect standards are better than none at all expand
|
|
|
Quality Outcomes: Determining Business Value |
| |
Pamela Simmons
|
|
Page: 25-32 |
|
doi>10.1109/52.476283 |
|
Full text available:
Publisher Site
|
|
Discussions of software quality typically focus on the development process or the characteristics of the software product. The third level of quality - the outcome of software development - is usually neglected, although this is perhaps of greatest interest ...
Discussions of software quality typically focus on the development process or the characteristics of the software product. The third level of quality - the outcome of software development - is usually neglected, although this is perhaps of greatest interest to business management. Outcome depends on how the product is used and determines the business value obtained from the development project.I conducted a study that investigated how a number of Australian organizations make their IT investment decisions. My research focused on how organizations evaluated individual projects, both at the justification stage and after implementation. I also examined how "effectiveness" was interpreted (that is, what was considered to be good business), the extent to which nonfinancial benefits influenced investment decisions, and the type of measures that were considered useful.From this work I developed a comprehensive framework of benefits and measures, and I validated the framework using the actual justifications of 25 projects. Thus, the framework provides a useful model for the analysis and measurement of the multiple dimensions of value that IT can bring to a business. expand
|
|
|
Support for Quality-Based Design and Inspection |
| |
Ilkka Tervonen
|
|
Page: 44-54 |
|
doi>10.1109/52.476285 |
|
Full text available:
Publisher Site
|
|
Debate using relevant, domain-specific quality terms is a mark of mature theory and expertise in a particular area. Wine connoisseurs and movie critics use domain-specific quality terms that even novices are at least partly familiar with. What about ...
Debate using relevant, domain-specific quality terms is a mark of mature theory and expertise in a particular area. Wine connoisseurs and movie critics use domain-specific quality terms that even novices are at least partly familiar with. What about software? Is software engineering mature enough so that software designers can use quality terms in discussions with their peers? Do inspectors of software artifacts evaluate them in terms of quality? Is the final software product advertised in such terms? Do customers understand the quality-based advantages of competing products?Most software engineers agree that there is too much variety in quality terms. Quality models such as Software Quality Metrics and Goal Question Metric and standards such as the IEEE Quality Metrics Methodology and ISO 9126 provide a quality terminology, but they tend to be too rigid or abstract, and of course they cannot guarantee that their terminology will be learned and used.This prevents software engineers from understanding the role of quality in practice: how to state quality goals, how to justify alternative solutions in quality terms, and how to evaluate the achievement of quality in alternative solutions. How do we solve this problem? In theory, the solution is easy. We need an appropriate quality model, a software-development method that uses this quality model, a supporting tool, and adequate training in the use of the method and tool. In practice, we all know how difficult this is.I propose to use a consistent quality structure for designing and inspecting software artifacts. This structure is based on a quality model that I call SQM synthesis because of my numerous modifications to the original Software Quality Metrics model. expand
|
|
|
Software Quality in Consumer Electronics Products |
| |
Jan Rooijmans,
Hans Aerts,
Michiel Van Genuchten
|
|
Page: 55-64 |
|
doi>10.1109/52.476286 |
|
Full text available:
Publisher Site
|
|
The software content in consumer electronics products has increased significantly in recent years. In the late 1980s, a high-end television set contained less than 64 Kbytes of ROM, while today's model often has more than 500 Kbytes. The expanding use ...
The software content in consumer electronics products has increased significantly in recent years. In the late 1980s, a high-end television set contained less than 64 Kbytes of ROM, while today's model often has more than 500 Kbytes. The expanding use of software in consumer electronics products calls for a more effective software-development process and the introduction of new technology. Until recently, the limited amount of software in consumer electronics products made it possible to deliver them without defects. Today, the amount of software contained in such products may reach 100,000 lines of source code. Organizations in the professional electronics industry have found how difficult it is to put a product of this size on the market without any defects.In 1991, Philips' CEO named a Software Process Improvement task force to focus on the increasing importance of software.We describe improvement activities undertaken at Philips Sound & Vision to meet the specific requirements of developing software for consumer electronics products at a time when the amount of software contained in each unit increased rapidly. In addition to improving its processes, the organization improved its requirements-and-design engineering architecture and its inspections, and it introduced metrics. We examine the results of these improvements in terms of effort and schedule overruns and defect density for three projects. expand
|
|
|
Early Quality Prediction: A Case Study in Telecommunications |
| |
Taghi M. Khoshgoftaar,
Edward B. Allen,
Kalai S. Kalaichelvan,
Nishith Goel
|
|
Page: 65-71 |
|
doi>10.1109/52.476287 |
|
Full text available:
Publisher Site
|
|
Predicting the number of faults is not always necessary to guide quality development; it may be enough to identify the most troublesome modules. Predicting the quality of modules lets developers focus on potential problems and make improvements earlier ...
Predicting the number of faults is not always necessary to guide quality development; it may be enough to identify the most troublesome modules. Predicting the quality of modules lets developers focus on potential problems and make improvements earlier in development, when it is more cost-effective. In such cases, classification models rather than regression models work very well.As a case study, this article applies discriminant analysis to identify fault-prone modules in a sample representing about 1.3 million lines of code from a very large telecommunications system. We developed two models using design product metrics based on call graphs and control flow graphs. One model used only these metrics; the other included reuse information as well. Both models had excellent fit. However, the model that included reuse data had substantially better predictive accuracy. We thus learned that information about reuse can be a significant input to software quality models for improving the accuracy of predictions. expand
|
|
|
Visualizing the Structure of Large Relational Databases |
| |
Jacqueline M. Antis,
Stephen G. Eick,
John D. Pyrce
|
|
Page: 72-80 |
|
doi>10.1109/52.476288 |
|
Full text available:
Publisher Site
|
|
Large relational databases, such as those associated with legacy software systems, can be difficult to engineer and extend. This visualization system abandons the use of entity-relationship diagrams in favor of a 2D, multiview, color representation of ...
Large relational databases, such as those associated with legacy software systems, can be difficult to engineer and extend. This visualization system abandons the use of entity-relationship diagrams in favor of a 2D, multiview, color representation of the database structure. It can easily display databases with more than 1,000 relations. expand
|
|
|
Multithreading Programs: Guidelines for DCE Applications |
| |
David E. Ruddock,
Balakrishnan Dasarathy
|
|
Page: 80-90 |
|
doi>10.1109/52.476289 |
|
Full text available:
Publisher Site
|
|
Multithreading provides a popular mechanism for achieving concurrency, but managing that concurrency can daunt even experienced programmers. The authors offer a tutorial on using threads safely and effectively in an RPC-supported, distributed environment.
Multithreading provides a popular mechanism for achieving concurrency, but managing that concurrency can daunt even experienced programmers. The authors offer a tutorial on using threads safely and effectively in an RPC-supported, distributed environment. expand
|
|
|
The Importance of Being Beautiful |
| |
Jakob Nielsen
|
|
Page: 92-94 |
|
doi>10.1109/52.476290 |
|
Full text available:
Publisher Site
|
|
The paper presents some tools, techniques and concepts to optimize user interfaces and considers some World Wide Web home pages as examples of user interface design. The importance of being beautiful has implications for how we evaluate the usability ...
The paper presents some tools, techniques and concepts to optimize user interfaces and considers some World Wide Web home pages as examples of user interface design. The importance of being beautiful has implications for how we evaluate the usability of our designs. The paper discusses how user preference measures will be relatively more important than traditional measures such as tasks per minute expand
|
|
|
Level 6: Why We Can't Get There from Here |
| |
Tom Gilb
|
|
Page: 97-98, 103 |
|
doi>10.1109/52.476291 |
|
Full text available:
Publisher Site
|
|
How to get people and technology to work togetherEach week, American comedian and social commentator Dennis Miller opens his TV show with a topic that he tears to pieces with biting satire. His self-proclaimed "rants" are often extreme, but his comments ...
How to get people and technology to work togetherEach week, American comedian and social commentator Dennis Miller opens his TV show with a topic that he tears to pieces with biting satire. His self-proclaimed "rants" are often extreme, but his comments ¿ when considered in their entirety ¿ are almost always on the mark.Tom Gilb is the Dennis Miller of software engineering. His opinions about software and its engineering have an edge. They are debatable, sometimes maddening, but, like Miller's rants, can serve as a catalyst for serious discussion. He is currently struggling to figure out how to think clearly about systems engineering, and is finding little meaningful guidance. The author or coauthor of several books, he is currently editing his manuscript on systems engineering, which has the working title The Results Method.As Tom advises at the end of this article, when you consider his opinions, have fun.¿Roger Pressman expand
|
|
|
Keys to Engineering a Workable Contract |
| |
Karl Dakin
|
|
Page: 99-100 |
|
doi>10.1109/52.476292 |
|
Full text available:
Publisher Site
|
|
Legal and policy aspects of information technology use and development.
Legal and policy aspects of information technology use and development. expand
|
|
|
Limiting the Dangers of Intuitive Decision Making |
| |
Lorenzo Strigini
|
|
Page: 101-103 |
|
doi>10.1109/52.476293 |
|
Full text available:
Publisher Site
|
|
New views of mature ideas on software and quality productivityWe scientists like to think that we bring objectivity to our work. But this month, Lorenzo Strigini shows us that subjectivity is inevitable, and that intuition should be used with great caution; ...
New views of mature ideas on software and quality productivityWe scientists like to think that we bring objectivity to our work. But this month, Lorenzo Strigini shows us that subjectivity is inevitable, and that intuition should be used with great caution; we should follow his guidelines for careful use.¿Shari Lawrence-Pfleeger expand
|
|
|
In the News |
| |
Stephen Barlas,
Michael Lutz,
Shari Lawrence Pfleeger
|
|
Page: 104-106, 108-112 |
|
doi>10.1109/MS.1996.476294 |
|
Full text available:
Publisher Site
|
|
First Page of the Article
First Page of the Article  expand
|
|
|
Now That Objects are Old Hat, Quo Vadis, Oppsla? |
| |
A. Burgess
|
|
Page: 106 |
|
doi>10.1109/MS.1996.476295 |
|
First Page of the Article
First Page of the Article  expand
|
|
|
Patent-Infringement Suit Filed |
| |
A. Burgess
|
|
Page: 106 |
|
doi>10.1109/MS.1996.476296 |
|
First Page of the Article
First Page of the Article  expand
|
|
|
Rational Acquires Objectory, Uniting OO Methodologies |
| |
A. Burgess
|
|
Page: 108 |
|
doi>10.1109/MS.1996.476297 |
|
First Page of the Article
First Page of the Article  expand
|
|
|
Workshop Defines Problems with Software-Engineering Data |
| |
S. L. Pfleeger
|
|
Page: 109 |
|
doi>10.1109/MS.1996.476298 |
|
First Page of the Article
First Page of the Article  expand
|
|
|
Signs of Life - and Growth - At Comdex |
| |
A. Burgess
|
|
Page: 110 |
|
doi>10.1109/MS.1996.476299 |
|
First Page of the Article
First Page of the Article  expand
|
|
|
Bookshelf |
| |
IEEE Software Staff
|
|
Page: 116-119 |
|
doi>10.1109/MS.1996.476300 |
|
Full text available:
Publisher Site
|
|
First Page of the Article
First Page of the Article  expand
|
|
|
Informal Survey of Software Fault Tolerance in Distributed Systems |
| |
J. M. Kusmiss
|
|
Page: 117 |
|
doi>10.1109/MS.1996.476301 |
|
First Page of the Article
First Page of the Article  expand
|
|
|
High-Level Text on Higher Order Logic |
| |
K. Periyasamy
|
|
Page: 117 |
|
doi>10.1109/MS.1996.476302 |
|
First Page of the Article
First Page of the Article  expand
|
|
|
Achieving Little Goals in Language Design and Implementation |
| |
D. F. Salomon
|
|
Page: 118 |
|
doi>10.1109/MS.1996.476303 |
|
First Page of the Article
First Page of the Article  expand
|
|
|
Meeting the Challenge of Software Maintenance |
| |
David Sharon
|
|
Page: 122-126 |
|
doi>10.1109/52.476304 |
|
Full text available:
Publisher Site
|
|
Research by Case Associates Inc. shows that between 50 to 70 percent of a software engineer's time is spent making changes to mission-critical software. Hence, the tool with the greatest potential impact on the software organization is no longer the ...
Research by Case Associates Inc. shows that between 50 to 70 percent of a software engineer's time is spent making changes to mission-critical software. Hence, the tool with the greatest potential impact on the software organization is no longer the development tool, it is the maintenance and enhancement tool. The paper considers the challenges of software maintenance and the selection of CASE tools expand
|
|
|
Who cares about software construction? |
| |
S. McConnell
|
|
Page: 127-128 |
|
doi>10.1109/52.476305 |
|
Software practitioners are subjected to a barrage of advice about effective development practices. The search for effective practices-programmers' gold-can be almost as chancy as the search for the precious yellow metal itself. Some mediocre practices ...
Software practitioners are subjected to a barrage of advice about effective development practices. The search for effective practices-programmers' gold-can be almost as chancy as the search for the precious yellow metal itself. Some mediocre practices are overhyped; many valuable practices are buried under the hype heaped on other practices. This paper aims to separate the gold from the ore by providing a practitioner's appraisal of past and present development practices expand
|
|
|
IEEE Software 1995 Referees |
| |
IEEE Software Staff
|
|
Pages: 113-115 |
|
Full text available:
Publisher Site
|
|
|
|
|
Who Cares About Software Construction? |
| |
Steve Mcconnell
|
|
Pages: 128-129 |
|
Full text available:
Publisher Site
|
|
Prospecting for programmer's gold.Software practitioners are subjected to a barrage of advice about effective development practices. The search for effective practices ¿ programmers' gold ¿ can be almost as chancey as the search for the precious yellow ...
Prospecting for programmer's gold.Software practitioners are subjected to a barrage of advice about effective development practices. The search for effective practices ¿ programmers' gold ¿ can be almost as chancey as the search for the precious yellow metal itself. Some mediocre practices are overhyped and don't pan out; many valuable practices are buried under the hype heaped on other practices. This column aims to separate the gold from the ore by providing a practitioner's appraisal of past and present development practices. Future columns will take up practitioner-oriented topics ranging from "Whatever happened to information hiding?" to "The estimation story ¿ defending unpopular estimates."¿Steve McConnell expand
|