The adoption of new practices, such as agile
or any new practice for that matter, is a task that is best undertaken
with both eyes open. There are often disconnects between the adopting
organization’s current practice and culture and the new practices being
adopted. This posting is the second installment in a series on Readiness & Fit Analysis (RFA),
which is a model and method for understanding risks when contemplating
or embarking on the adoption of new practices, in this case agile
methods. The RFA method helps organizations understand the barriers and
enablers to successful adoption that are present when an analysis is
performed. The first post in this series outlined the principles of RFA and described the Acquisition Support Program’s
work in extending RFA to support profiling and adoption risk
identification to organizations that are adopting agile methods. This
blog post continues the discussion with a more in-depth dive into one
more of the six RFA categories that we have identified.

When
a system fails, engineers too often focus on the physical components,
but pay scant attention to the software. In software-reliant systems
ignoring or deemphasizing the importance of software failures can be a
recipe for disaster. This blog post is the first in a series on recent
developments with the Architecture Analysis Design Language (AADL) standard.
Future posts will explore recent tools and projects associated with
AADL, which provides formal modeling concepts for the description and
analysis of application systems architecture in terms of distinct
components and their interactions. As this series will demonstrate, the
use of AADL helps alleviate mismatched assumptions between the hardware,
software, and their interactions that can lead to system failures.