The SEI has long advocated software architecture documentation as a software engineering best practice. This type of documentation is not particularly revolutionary or different from standard practices in other engineering disciplines. For example, who would build a skyscraper without having an architect draw up plans first? The specific value of software architecture documentation, however, has never been established empirically. This blog describes a research project we are conducting to measure and understand the value of software architecture documentation on complex software-reliant systems.
As industry and government customers demand increasingly rapid innovation and the ability to adapt products and systems to emerging needs, the time frames for releasing new software capabilities continue to shorten. Likewise, Agile software development processes, with their emphasis on releasing new software capabilities rapidly, are increasing in popularity beyond their initial small team and project context. Practices intended to speed up the delivery of value to users, however, often result in high rework costs that ultimately offset the benefits of faster delivery, especially when good engineering practices are forgotten along the way. This rework and degrading quality often is referred to as technical debt. This post describes our research on improving the overall value delivered to users by strategically managing technical debt, which involves decisions made to defer necessary work during the planning or execution of a software project.
In some key industries, such as defense, automobiles, medical devices, and the smart grid, the bulk of the innovations focus on cyber-physical systems. A key characteristic of cyber-physical systems is the close interaction of software components with physical processes, which impose stringent safety and time/space performance requirements on the systems. This blog post describes research and development we are conducting at the SEI to optimize the performance of cyber-physical systems without compromising their safety.
As part of an ongoing effort to keep you informed about the latest work of SEI technologists, I will keep you apprised of SEI-related work that's published each month as SEI technical reports and notes. This post includes a listing of each report, author/s, and links where reports published in March can be accessed on the SEI website. The first report, A Framework for Evaluating Common Operating Environments, is based on a recent SEI blog postingand is an area I'm actively working on at the SEI. As always, we welcome your feedback on our work.
This is a second in a series of posts focusing on Agile software development. In the first post, "What is Agile?" we provided a short overview of the key elements of the Agile approach, and we introduced the Agile Manifesto. One of the guiding principles from the manifesto emphasizes valuing people over developing processes. While the manifesto clearly alludes to the fact that too much focus on process (and not results) can be a bad thing, we introduce the notion here that the other end of the spectrum can also be bad. This blog explores the level of skill that is needed to develop software using Agile (do you need less skill or more?), as well as the importance of maintaining strong competency in a core set of software engineering processes.
If you ask the question, "What is Agile?" you are likely to get lots of different answers. That's because there is no universally accepted formal definition for Agile. To make matters worse, there are ongoing debates over what Agile software development SHOULD mean. That being the case, when answering the question, "What is Agile?" the safest bet is to stick to what people can agree on, and people generally agree on three key elements of Agile. Taken together, these describe the Agile software development method, as well as the software development approach. In this post--the first in a series on Agile--I will explain the foundations of Agile and its use by developers.
Many people today carry handheld computing devices to support their business, entertainment, and social needs in commercial networks. The Department of Defense (DoD) is increasingly interested in having soldiers carry handheld computing devices to support their mission needs in tactical networks. Not surprisingly, however, conventional handheld computing devices (such as iPhone or Android smartphones) for commercial networks differ in significant ways from handheld devices for tactical networks. For example, conventional devices and the software that runs on them do not provide the capabilities and security needed by military devices, nor are they configured to work over DoD tactical networks with severe bandwidth limitations and stringent transmission security requirements. This post describes exploratory research we are conducting at the SEI to (1) create software that allows soldiers to access information on a handheld device and (2) program the software to tailor the information for a given mission or situation.
Malware--generically defined as software designed to access a computer system without the owner's informed consent--is a growing problem for government and commercial organizations. In recent years, research into malware focused on similarity metrics to decide whether two suspected malicious files are similar to one another. Analysts use these metrics to determine whether a suspected malicious file bears any resemblance to already verified malicious files. Using these metrics allows analysts to potentially save time, by identifying opportunities to leverage previous analysis. This post will describe our efforts to develop a technique (known as fuzzy hashing) to help analysts determine whether two pieces of suspected malware are similar.
The 19th practice described in the newly released edition of the Common Sense Guide to Mitigating Insider Threats is Practice 19: Close the doors to unauthorized data exfiltration. In this post, I discuss how organizations are vulnerable to data exfiltration...