There are several risks specific to big data system development. Software architects developing any system--big data or otherwise--must address risks associated with cost, schedule, and quality. All of these risks are amplified in the context of big data. Architecting big data systems is challenging because the technology landscape is new and rapidly changing, and the quality attribute challenges, particularly for performance, are substantial. Some software architects manage these risks with architecture analysis, while others use prototyping. This blog post, which was largely derived from a paper I co-authored with Hong-Mei Chen and Serge Haziyev, Strategic Prototyping for Developing Big Data Systems, presents the Risk-Based Architecture-Centric Strategic Prototyping (RASP) model, which was developed to provide cost-effective systematic risk management in agile big data system development.
Safety-critical software must be analyzed and checked carefully. Each potential error, failure, or defect must be considered and evaluated before you release a new product. For example, if you are producing a quadcopter drone, you would like to know the probability of engine failure to evaluate the system's reliability. Safety analysis is hard. Standards such as ARP4761 mandate several analyses, such as Functional Hazard Assessment (FHA) and Failure Mode and Effect Analysis (FMEA). One popular type of safety analysis is Fault Tree Analysis (FTA), which provides a graphical representation of all contributors to a failure (e.g., error events and propagations). In this blog post, I present the concepts of the FTA and introduce a new tool to design and analyze fault trees.
This blog post was co-authored by Carol Sledge.
To deliver enhanced, integrated warfighting capability at lower cost, the DoD must move away from stove-piped solutions and embrace open systems architecture (OSA) approaches that integrate business and technical practices to create systems with interoperable and reusable components. In November, the SEI launched a series of blog posts that highlight the perspectives of DoD stakeholders--including contractor and government employees--on OSA-based approaches and how they can best be integrated in DoD software (and hardware) development. The first post in this series highlighted our discussion with David Sharp, a senior technical fellow at The Boeing Company and an expert in software architecture for embedded systems and systems of systems. This post highlights a discussion with Nickolas H. Guertin, in the Office of the Deputy Assistant Secretary of the Navy for Research, Development, Test, and Evaluation.
Guertin has a long history with open systems, both for U.S. Navy OSA initiatives and broader DoD initiatives. Based on his experiences over the past several decades, he discussed with the SEI how OSA offers developers the ability to create more resilient and adaptable systems. He noted that Under Secretary of Defense for Acquisition, Technology and Logistics Frank Kendall, in his Better Buying Power 3.0, highlights how the acquisition community can address that demand signal. Together, they have established that we are behind in technology innovation and need to use OSA as a method to bridge that divide. This new direction is helping the DoD introduce new technologies more quickly and less expensively to the warfighter. Throughout this post, we will present excerpts from our conversation (Editor's note: These excerpts have been edited to improve readability).
The crop of Top 10 SEI blog posts published in the first half of 2016 (judged by the number of visits by our readers) represents a cross section of the type of cutting-edge work that we do at the SEI: at-risk emerging technologies, cyber intelligence, big data, vehicle cybersecurity, and what ant colonies can teach us about securing the internet. In all, readers visited the SEI blog more than 52,000 times for the first six months of 2016. We appreciate your readership and invite you to submit ideas for future posts in the comments section below. In this post, we will list the Top 10 posts in descending order (#10 to #1) and then provide an excerpt from each post, as well as links to where readers can go for more information about the topics covered in the SEI blog.
What is technical debt? Why identify technical debt? Shouldn't it be captured as defects and bugs? Concretely communicating technical debt and its consequences is of interest to both researchers and software engineers. Without validated tools and techniques to achieve this goal with repeatable results, developers resort to ad hoc practices, most commonly using issue trackers or backlog-management practices to capture and track technical debt. We examined 1,264 issues from four issue trackers used in open-source industry and government projects and identified 109 examples of technical debt. Our study, documented in the paper Got Technical Debt? Surfacing Elusive Technical Debt in Issue Trackers, revealed that technical debt has entered the vernacular of developers as they discuss development tasks through issue trackers. Even when developers did not explicitly label issues as technical debt, it was possible to identify technical debt items in these issue trackers using a classification method we developed. We use our results to motivate an improved definition of technical debt and an approach to explicitly report it in issue trackers. In this blog post, we describe our classification method and some implications of tracking debt for both practice and research.
This blog post was co-authored by Nancy Mead, SEI Fellow.
To ensure software will function as intended and is free of vulnerabilities (aka software assurance), software engineers must consider security early in the lifecycle, when the system is being designed and architected. Recent research on vulnerabilities supports this claim: Nearly half the weaknesses identified in the Common Weakness Enumeration (CWE) repository have been identified as design weaknesses. These weaknesses are introduced early in the lifecycle and cannot be patched away in later phases. They result from poor (or incomplete) security requirements, system designs, and architecture choices for which security has not been given appropriate priority. Effective use of metrics and methods that apply systematic consideration for security risk can highlight gaps earlier in the lifecycle before the impact is felt and when the cost of addressing these gaps is less. This blog post explores the connection between measurement, methods for software assurance, and security. Specifically, we focus on three early lifecycle methods that have shown promise: the Software Assurance Framework (SAF), Security Quality Requirements Engineering (SQUARE) Methodology, and Security Engineering Risk Analysis (SERA) Framework.
The mix of program-scale Agile and technical baseline ownership drives cheaper, better, and faster deployment of software-intensive systems. Although these practices aren't new, the SEI has seen how their combination can have dramatic effects. The Air Force Distributed Common Ground System (AF DCGS)--the Air Force's primary weapon system for intelligence, surveillance, reconnaissance, planning, direction, collection, processing, exploitation, analysis, and dissemination--employs a global communications architecture that connects multiple intelligence platforms and sensors. The AF DCGS challenge is to bring new sensors and processing applications online quickly and efficiently. Other large government software-intensive systems face similar challenges. The SEI has found that Agile cultural transformation--along with strong technical baseline ownership--is critical for programs like DCGS to deliver new capability faster and with greater confidence. These strategies working together can help create incremental and iterative approaches to deliver more frequent and more manageable technical capability. In this blog, I present the SEI's experiences in helping large Department of Defense (DoD) programs, such as AF DCGS, use concepts like owning the technical baseline and Agile software development techniques to deliver new capability on a regular basis.
In 2015, the National Vulnerability Database (NVD) recorded 6,488 new software vulnerabilities, and the NVD documents a total of 74,885 software vulnerabilities discovered between 1988-2016. Static analysis tools examine code for flaws, including those that could lead to software security vulnerabilities, and produce diagnostic messages ("alerts") indicating the location of the purported flaw in the source code, the nature of the flaw, and often additional contextual information. A human auditor then evaluates the validity of the purported code flaws. The effort required to manually audit all alerts and repair all confirmed code flaws is often too much for a project's budget and schedule. Auditors therefore need tools that allow them to triage alerts, strategically prioritizing the alerts for examination. This blog post describes research we are conducting that uses classification models to help analysts and coders prioritize which alerts to address.