By Donald Firesmith
Software Solutions Division
While evaluating the test programs of numerous defense contractors, we have often observed that they are quite incomplete. For example, they typically fail to address all the relevant types of testing that should be used to (1) uncover defects (2) provide evidence concerning the quality and maturity of the system or software under test, and (3) demonstrate the readiness of the system or software for acceptance and being placed into operation. Instead, many test programs only address a relatively small subset of the total number of potentially relevant types of testing, such as unit testing, integration testing, system testing, and acceptance testing. In some cases, the missing testing types are actually performed (to some extent) but not addressed in test-related planning documents, such as test strategies, system and software test plans (STPs), and the testing sections of systems engineering management plans (SEMPs) and software development plans (SDP). In many cases, however, they are neither mentioned nor performed. This blog, post, the first in a series on the many types of testing, examines the negative consequences of not addressing all relevant testing types and introduces a taxonomy of testing types to help testing stakeholders understand--rather than overlook--them.
By Kevin Fall
Deputy Director, Research, and CTO
This is the second installment in a series on the SEI's technical strategic plan.
Department of Defense (DoD) systems are becoming increasingly software reliant, at a time when concerns about cybersecurity are at an all-time high. Consequently, the DoD, and the government more broadly, is expending significantly more time, effort, and money in creating, securing, and maintaining software-reliant systems and networks. Our first post in this series provided an overview of the SEI's five-year technical strategic plan, which aims to equip the government with the best combination of thinking, technology, and methods to address its software and cybersecurity challenges. This blog post, the second in the series, looks at ongoing and new research we are undertaking to address key cybersecurity, software engineering and related acquisition issues faced by the government and DoD.
Object-oriented programs present considerable challenges to reverse engineers. For example, C++ classes are high-level structures that lead to complex arrangements of assembly instructions when compiled. These complexities are exacerbated for malware analysts because malware rarely has source code available; thus, analysts must grapple with sophisticated data structures exclusively at the machine code level. As more and more object-oriented malware is written in C++, analysts are increasingly faced with the challenges of reverse engineering C++ data structures. This blog post is the first in a series that discusses tools developed by the Software Engineering Institute's CERT Division to support reverse engineering and malware analysis tasks on object-oriented C++ programs.
This is the second installment of two blog posts highlighting recommended practices for achieving Agile at Scale that was originally published on the Cyber Security & Information Systems Information Analysis Center (CSIAC) website. The first post in the series by Ipek Ozkaya and Robert Nord explored challenges to achieving Agile at Scale and presented the first five recommended practices:
1. Team coordination
2. Architectural runway
3. Align development and decomposition.
4. Quality-attribute scenarios
5. Test-driven development
This post presents the remaining five technical best practices, as well as three conditions that will help organizations achieve the most value from these recommended practices. This post was originally published in its entirety on the SPRUCE website.
We are writing to let our SEI Blog readers know about some changes to SEI blogs that make our content areas more accessible and easier to navigate. On August 6, 2015, the SEI will unveil a new website, SEI Insights, that will give you access to all SEI blogs--the CERT/CC, Insider Threat, DevOps and SATURN, and SEI--in one mobile-friendly location. At SEI Insights, readers can quickly review the most recent posts from all SEI blogs and navigate to each blog.
The biweekly DevOps series that was part of the SEI Blog will now have its own blog page accessible from the Insights homepage. The SEI and DevOps blogs, as well as the other blogs on the site, will maintain individual RSS feeds.
To access SEI Insights, please visit http://insights.sei.cmu.edu/.
Your links to the former blog sites will temporarily redirect to SEI Insights, but we encourage you to update existing links and bookmarks.
Thank you for your continued support of the SEI blogs.
This post is the first in a two-part series highlighting 10 recommended practices for achieving agile at scale.
Software and acquisition professionals often have questions about recommended practices related to modern software development methods, techniques, and tools, such as how to apply agile methods in government acquisition frameworks, systematic verification and validation of safety-critical systems, and operational risk management. In the Department of Defense (DoD), these techniques are just a few of the options available to face the myriad challenges in producing large, secure software-reliant systems on schedule and within budget.