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 CERT Division of the SEI has a history of helping organizations develop, improve, and assess their incident management functions. Frequently we discover that an organization's primary focus is on security incident response, rather than the broader effort of security incident management. Incident response is just one step in the incident management lifecycle. In this blog post, we look at five recurring issues we regularly encounter in organizations' Incident Management programs, along with recommended solutions. By discovering and resolving these issues, organizations can attain a better cybersecurity posture.