2013: The Research Year in Review

Agile , Architecture Analysis & Design Language (AADL) , CERT , Insider Threat , Malware No Comments »

By Douglas C. Schmidt
Principal Researcher

Douglas C. Schmidt As part of our mission to advance the practice of software engineering and cybersecurity through research and technology transition, our work focuses on ensuring that software-reliant systems are developed and operated with predictable and improved quality, schedule, and cost. To achieve this mission, the SEI conducts research and development activities involving the Department of Defense (DoD), federal agencies, industry, and academia. As we look back on 2013, this blog posting highlights our many R&D accomplishments during the past year.

Read more...

Hacking the CERT FOE

CERT No Comments »

By Will Dormann
Senior Member of the Technical Staff
CERT Vulnerability Analysis Team

Will DormannOccasionally this blog will highlight different posts from the SEI blogosphere. Today we are highlighting a recent post by Will Dormann, a senior member of the technical staff in the SEI’s CERT Division, from the CERT/CC Blog. In this post, Dormann describes how to modify the CERT Failure Observation Engine (FOE),when he encounters apps that “don’t play well” with the FOE. The FOE is a software testing tool that finds defects in applications running on the Windows platform.

Read more...

Using Scenario-Based Architecture Analysis to Inform Code Quality Measures

Architecture Tradeoff Analysis Method (ATAM) , Technical Debt 1 Comment »

By Robert Nord,
Senior Member of the Technical Staff
Software Solutions Division

(This blog post was co-authored by Ipek Ozkaya)

Robert Nord As the pace of software delivery increases, organizations need guidance on how to deliver high-quality software rapidly, while simultaneously meeting demands related to time-to-market, cost, productivity, and quality. In practice, demands for adding new features or fixing defects often take priority. However, when software developers are guided solely by project management measures, such as progress on requirements and defect counts, they ignore the impact of architectural dependencies, which can impede the progress of a project if not properly managed. In previous posts on this blog, my colleague Ipek Ozkaya and I have focused on architectural technical debt, which refers to the rework and degraded quality resulting from overly hasty delivery of software capabilities to users. This blog post describes a first step towards an approach we developed that aims to use qualitative architectural measures to better inform quantitative code quality metrics.

Read more...

Detecting Architecture Traps and Pitfalls in Safety-Critical Software

Architecture Analysis & Design Language (AADL) No Comments »

By Julien Delange
Member of the Technical Staff   
Software Solutions Division

Julien Delange Safety-critical avionics, aerospace, medical, and automotive systems are becoming increasingly reliant on software. Malfunctions in these systems can have significant consequences including mission failure and loss of life. So, they must be designed, verified, and validated carefully to ensure that they comply with system specifications and requirements and are error free. In the automotive domain, for example, cars contain many electronic control units (ECU)—today’s standard vehicle can contain up to 30 ECUs—that communicate to control systems such as airbag deployment, anti-lock brakes, and power steering. The design of tightly-coupled software components distributed across so many nodes may introduce problems, such as early or late data delivery, loss of operation, or concurrent control of the same resource. In addition, errors introduced during the software design phase, such as mismatched timing requirements and values beyond boundaries, are propagated in the implementation and may not be caught by testing efforts. If these problems escape detection during testing, they can lead to serious errors and injuries, as evidenced by recent news reports about problems with automotive firmware. Such issues are not specific to a particular domain and are very common in safety-critical systems. In fact, such problems are often found when reviewing code from legacy systems designed and built more than 20 years ago and still operating, as in the avionics and aerospace domains. This blog post describes an effort at the SEI that aims to help engineers use time-proven architecture patterns (such as the publish-subscribe pattern or correct use of shared resources) and validate their correct application.

Read more...

Is Your Organization Ready for Agile?

Agile , Readiness & Fit Analysis 4 Comments »

Fourth Installment in a Series
By Suzanne Miller
Principal Researcher
Software Solutions Division

Suzanne MillerGovernment agencies, including the departments of Defense, Veteran Affairs, and Treasury, are being asked by their government program office to adopt Agile methods. These are organizations that have traditionally utilized a “waterfall” life cycle model (as epitomized by the engineering “V” charts). Programming teams in these organizations are accustomed to being managed via a series of document-centric technical reviews that focus on the evolution of the artifacts that describe the requirements and design of the system rather than its evolving implementation, as is more common with Agile methods. Due to these changes, many struggle to adopt Agile practices. For example, acquisition staff often wonder how to fit Agile measurement practices into their progress tracking systems. They also find it hard to prepare for technical reviews that don’t account for both implementation artifacts and the availability of requirements/design artifacts. My ongoing series on the Readiness & Fit Analysis (RFA) approach focuses on helping organizations understand the risks involved when contemplating or embarking on the adoption of new practices, in this case Agile methods. This posting explores project and customer environment, one of many challenging factors to assess when considering Agile adoption readiness.

Read more...