|
Modeling Practice and Requirements Models are useful in different settings in different ways. Models can test facts, ideas and understanding, simulate operation, and aid coordination between systems and people. In this column, Becky Winant lists six model patterns she has seen in practice in software development organizations, talking about where each is appropriate, and the strengths and weaknesses of each.
|
|
|
A Baker's Dozen of Dirty Words III offers alternatives to thirteen commonly misused terms and phrases, including walkthrough, quality assurance, phase, O-O analysis, maintenance, function, and estimate.
|
|
|
The Two Faces of Quality Lina Watson questions the conflicting views of quality assurance and describes the distortions that can occur between software process realities and their perceived image in the corporate world.
|
|
|
One Size Does Not Fit All For all of the effort we've made in the software field to find the best methodology, the best programming language, the best operating system, the best set of tools, even the best process maturity model—the search for the "best" is often futile. Robert L. Glass urges you to not be confined by a software approach that doesn't match your specific needs.
|
|
|
Faults of Omission Brian Marick is obsessed with faults of omission in software code, and he thinks you should be too. In this Bug Report, Marick describes coding omissions, design omissions, and requirements omissions, and offers some ways to prevent (or at least test) them.
|
|
|
The Spirit of the Times Brian Marick points to Web resources and email lists that help keep you current with software and computing trends.
|
|
|
Learning from Pathfinder's Bumpy Start Steve March discusses problems experienced by the Mars Pathfinder. He imparts the following lessons: 1) design defensively in the face of complexity; 2) design defensively for post-shipment problems; and 3) beware of best cases.
|
|
|
My Summer as a Hacker Pete TerMaat shares some valuable lessons learned from a summer with "hacking legend" Richard Stallman. He learned that attitude, passion for one's work, was most important. Reviews, coding standards, porting guidelines, bug hunting advice, and other measures can fall flat without a passion for clean code, for "getting things right."
|
|
|
Speaking of Quality Technical Editors Esther Derby and Brian Marick introduce Volume Four of STQE magazine.
|
|
|
A Study in Failures Examples of mistakes, manifestations, and problems help us understand all parts of the software. Brian Marick suggests Web resources that examine software failures.
|
|