Software engineers face a universal problem when developing software: weighing the benefit of an approach that is expedient in the short-term, but which can lead to complexity and cost over the long term. In software-intensive systems, these tradeoffs can create technical debt, which is a design or implementation construct that is expedient in the short term, but which sets up a technical context that can make future changes more costly or even impossible.
This post is co-authored by Will Hayes and Eileen Wrubel.
On July 14, 2016, the House Ways and Means Subcommittee on Social Security convened a hearing on the Social Security Administration's (SSA) information technology modernization plan. The hearing focused on the current state of the Social Security Administration's (SSA) Information Technology (IT) modernization plan and best practices for IT modernization, including oversight of agile software development. Agile development approaches, relatively new in government settings, create opportunities for rapid deployment of new capabilities but also pose challenges to traditional government oversight and management practices. A team of researchers from the SEI's Agile in Government (AIG) team were part of an expert panel brought in to testify before the members of the subcommittee. The team, comprised of me, AIG principal engineer Will Hayes, and AIG program manager Eileen Wrubel, developed written testimony that was submitted to the committee in conjunction with verbal testimony delivered by Hayes. This blog post, the first in a series, presents the written testimony as submitted to Congress, drawing upon seven years of research the SEI has conducted on the use of Agile in government settings. Specifically, this post provides a summary of challenges observed by the SEI in overseeing Agile programs in governmentsuch as progress measurements, IT transformations beyond Agile, and workforce development of government staff working in Agile settings.
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.
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 second practice described in the newly released edition of the Common Sense Guide to Mitigating Insider Threats is Practice 2: Develop a formalized insider threat program. In this post, I discuss why this practice is so important to preventing...