May 6
2013
Second of a Two-Part Series
By Donald Firesmith
Senior Member of the Technical Staff
Acquisition Support Program
In the first blog entry
of this two part series on common testing problems, I addressed the
fact that testing is less effective, less efficient, and more expensive
than it should be. This second posting of a two-part series
highlights results of an analysis that documents problems that commonly
occur during testing. Specifically, this series of posts identifies and
describes 77 testing problems organized into 14 categories; lists
potential symptoms by which each can be recognized; potential negative
consequences, and potential causes; and makes recommendations for
preventing them or mitigating their effects.
Read more...
Apr 5
2013
First of a Two-Part Series
By Donald Firesmith
Senior Member of the Technical Staff
Acquisition Support Program
A widely cited study for the National Institute of Standards & Technology (NIST)
reports that inadequate testing methods and tools annually cost the
U.S. economy between $22.2 and $59.5 billion, with roughly half of these
costs borne by software developers in the form of extra testing and
half by software users in the form of failure avoidance and mitigation
efforts. The same study notes that between 25 and 90 percent of software
development budgets are often spent on testing. This posting, the first
in a two-part series, highlights results of an analysis that documents
problems that commonly occur during testing. Specifically, this series
of posts identifies and describes 77 testing problems organized into 14
categories, lists potential symptoms by which each can be recognized,
potential negative consequences, potential causes, and makes
recommendations for preventing them or mitigating their effects.
Read more...
Sep 24
2012
By Don Firesmith
Senior Member of the Technical Staff
Acquisition Support Program
Engineering
the architecture for a large and complex system is a hard, lengthy, and
complex undertaking. System architects must perform many tasks and use
many techniques if they are to create a sufficient set of architectural
models and related documents that are complete, consistent, correct,
unambiguous, verifiable, usable, and useful to the architecture’s many
stakeholders. This blog posting, the second in a two-part series, takes
a deeper dive into the Method Framework for Engineering System Architectures (MFESA), which is a situational process engineering framework for developing system-specific methods to engineer system architectures.
Read more...
Aug 20
2012
By Don Firesmith
Researcher
Acquisition Support Program
Engineering
the architecture for a large and complex system is a hard, lengthy, and
complex undertaking. System architects must perform many tasks and use
many techniques if they are to create a sufficient set of architectural
models and related documents that are complete, consistent, correct,
unambiguous, verifiable, and both usable by and useful to the
architecture’s many stakeholders. This blog posting, the first in a
two-part series, presents the Method Framework for Engineering System Architectures (MFESA), which is a situational process engineering
framework for developing system-specific methods to engineer system
architectures. This posting provides a brief historical description of
situational method engineering, explains why no single system
architectural engineering method is adequate, and introduces MFESA by
providing a top-level overview of its components, describing its
applicability, and explaining how it simultaneously provides the
benefits of standardization and flexibility.
Read more...
Jan 16
2012
By Donald Firesmith
Senior Member of the Technical Staff
Acquisition Support Program
In our work with acquisition
programs, we’ve often observed a major problem: requirements
specifications that are incomplete, with many functional requirements
missing. Whereas requirements specifications typically specify normal
system behavior, they are often woefully incomplete when it comes to
off-nominal behavior, which deals with abnormal events and situations
the system must detect and how the system must react when it detects
that these events have occurred or situations exist. Thus, although
requirements typically specify how the system must behave under normal
conditions, they often do not adequately specify how the system must
behave if it cannot or should not behave as normally expected. This blog
post examines requirements engineering for off-nominal behavior.
Read more...
Recent Comments