By Mike Konrad Principal Researcher
SEI Software Solutions Division
As recent news attests, the rise of sociotechnical ecosystems (STE)—which, we define as a software system that engages a large and geographically-distributed community in a shared pursuit—allows us to work in a mind space and a data space that extends beyond anything that we could have imagined 20 or 30 years ago. STEs present opportunities for tackling problems that could not have even been approached previously because the needed experts and data are spread across multiple locations and distance. Since STEs can be complex and have many diverse stakeholders, a key challenge faced by those responsible for establishing and sustaining them is eliciting requirements to inform their development efforts. Yet stakeholders often have requirements that they are not aware of, so they do not specify them. Uncovering these unstated requirements can be hard and is not well-supported by traditional approaches to requirements elicitation. This blog post describes initial results of an effort by researchers at the Carnegie Mellon University Software Engineering Institute—in addition to myself, the team included Nancy Mead, Robert Stoddard, and Mary Beth Chrissis—aimed at developing an approach for determining the unstated needs of stakeholders typical of large, diverse programs and especially STEs.
By Neil Ernst
Member of the Technical Staff
Software Solutions Division
This post is co-authored by Stephany Bellomo
Continuous delivery practices, popularized in Jez Humble’s 2010 bookContinuous Delivery, enable rapid and reliable software system deployment by emphasizing the need for automated testing and building, as well as closer cooperation between developers and delivery teams. As part of the Carnegie Mellon University Software Engineering Institute's (SEI) focus on Agile software development, we have been researching ways to incorporate quality attributes into the short iterations common to Agile development. We know from existing SEI work on Attribute-Driven Design, Quality Attribute Workshops, and the Architecture Tradeoff Analysis Method that a focus on quality attributes prevents costly rework. Such a long-term perspective, however, can be hard to maintain in a high-tempo, Agile delivery model, which is why the SEI continues to recommend an architecture-centric engineering approach, regardless of the software methodology chosen. As part of our work in value-driven incremental delivery, we conducted exploratory interviews with teams in these high-tempo environments to characterize how they managed architectural quality attribute requirements (QARs). These requirements—such as performance, security, and availability—have a profound impact on system architecture and design, yet are often hard to divide, or slice, into the iteration-sized user stories common to iterative and incremental development. This difficulty typically exists because some attributes, such as performance, touch multiple parts of the system. This blog post summarizes the results of our research on slicing (refining) performance in two production software systems. We also examined the ratcheting (periodic increase of a specific response measure) of scenario components to allocate QAR work.
By Douglas C. Schmidt
As part of an ongoing effort to keep you informed about our latest work, I would like to let you know about some recently published SEI technical reports and notes. These reports highlight the latest work of SEI technologists in assuring software reliability, future architectures, Agile software teams, insider threat, and HTML5. This post includes a listing of each report, author(s), and links where the published reports can be accessed on the SEI website.
By David Keaton
CERT Secure Coding Initiative
According to a 2013 report examining 25 years of vulnerabilities (from 1998 to 2012), buffer overflow
causes 14 percent of software security vulnerabilities and 35 percent
of critical vulnerabilities, making it the leading cause of software
security vulnerabilities overall. As of July 2014, the TIOBE index indicates that the C programming language,
which is the language most commonly associated with buffer overflows,
is the most popular language with 17.1 percent of the market. Embedded
systems, network stacks, networked applications, and high-performance
computing rely heavily upon C. Embedded systems can be especially
vulnerable to buffer overflows because many of them lack hardware memory
management units. This blog post describes my research on the Secure Coding Initiative in the CERT Division of the Carnegie Mellon University Software Engineering Institute to create automated buffer overflow prevention.
By Joseph Elm
Program Integration Manager
Software Solutions Division
today’s systems it’s very hard to know where systems end and software
begins. Software performs an integrating function in many systems, often
serving as the glue interconnecting other system elements. We also find
that many of the problems in software systems have their roots in systems engineering,
which is an interdisciplinary field that focuses on how to design and
manage complex systems over their life cycles. For that reason, staff at
the Carnegie Mellon University Software Engineering Institute (SEI)
often conduct research in the systems engineering realm. Process
frameworks, architecture development and evaluation methods, and metrics
developed for software are routinely adapted and applied to systems.
Better systems engineering supports better software development, and
both support better acquisition project performance. This blog post, the latest in a series
on this research, analyzes project performance based on systems
engineering activities in the defense and non-defense industries.