In the first half of this year, the SEI blog has experienced unprecedented growth, with visitors in record numbers learning more about our work in big data, secure coding for Android, malware analysis, Heartbleed, and V Models for Testing. In the first six months of 2014 (through June 20), the SEI blog has logged 60,240 visits, which is nearly comparable with the entire 2013 yearly total of 66,757 visits. As we reach the mid-year point, this blog posting takes a look back at our most popular areas of work (at least according to you, our readers) and highlights our most popular blog posts for the first half of 2014, as well as links to additional related resources that readers might find of interest.
Federal agencies depend on IT to support their missions and spent at least $76 billion on IT in fiscal year 2011, according to a report from the Government Accountability Office (GAO). The catalyst for the study was congressional concern over prior IT expenditures that produced disappointing results, including multimillion dollar cost overruns and schedule delays measured in years, with questionable mission-related achievements. The Office of Management and Budget (OMB) in 2010 issued guidance that advocates federal agencies employ "shorter delivery time frames, an approach consistent with Agile." This ongoing series on the Readiness & Fit Analysis (RFA) approach focuses on helping federal agencies and other organizations understand the risks involved when contemplating or embarking on the adoption of new practices, such as Agile methods. This blog posting, the fifth in this series, explores the Practices category, which helps organizations understand which Agile practices are already in use to formulate a more effective adoption strategy.
Introducing new software languages, tools, and methods in industrial and production environments incurs a number of challenges. Among other necessary changes, practices must be updated, and engineers must learn new methods and tools. These updates incur additional costs, so transitioning to a new technology must be carefully evaluated and discussed. Also, the impact and associated costs for introducing a new technology vary significantly by type of project, team size, engineers' backgrounds, and other factors, so that it is hard to estimate the real acquisition costs. A previous post in our ongoing series on the Architecture Analysis and Design Language (AADL) described the use of AADL in research projects (such as System Architectural Virtual Integration (SAVI)) in which experienced researchers explored the language capabilities to capture and analyze safety-critical systems from different perspectives. These successful projects have demonstrated the accuracy of AADL as a modeling notation. This blog post presents research conducted independently of the SEI that aims to evaluate the safety concerns of several unmanned aerial vehicle (UAV) systems using AADL and the SEI safety analysis tools implemented in OSATE.
The Wireless Emergency Alerts (WEA) service went online in April 2012, giving emergency management agencies such as the National Weather Service or a city's hazardous materials team a way to send messages to mobile phone users located in a geographic area in the event of an emergency. Since the launch of the WEA service, the newest addition to the Federal Emergency Management Agency (FEMA) Integrated Public Alert and Warning System (IPAWS),"trust" has emerged as a key issue for all involved. Alert originators at emergency management agencies must trust WEA to deliver alerts to the public in an accurate and timely manner. The public must also trust the WEA service before it will act on the alerts. Managing trust in WEA is a responsibility shared among many stakeholders who are engaged with WEA. This blog post, the first in a series, highlights recent research aimed at enhancing both the trust of alert originators in the WEA service and the public's trust in the alerts it receives.
To maintain a competitive edge, software organizations should be early adopters of innovation. To achieve this edge, organizations from Flickr and IBM to small tech startups are increasingly adopting an environment of deep collaboration between development and operations (DevOps) teams and technologies, which historically have been two disjointed groups responsible for information technology development. "The value of DevOps can be illustrated as an innovation and delivery lifecycle, with a continuous feedback loop to learn and respond to customer needs," Ashok Reddy writes in the technical white paper, DevOps: The IBM approach.
As part of an ongoing effort to keep you informed about our latest work, I would like to let you know about some recently published SEI technical reports and notes. These reports highlight the latest work of SEI technologists in cybersecurity risks, software assurance, advanced persistent threat, international insider threat, Wireless Emergency Alerts Service, security and survivability, and acquisition.
The Government Accountability Office (GAO) recently reported that acquisition program costs typically run 26 percent over budget, with development costs exceeding initial estimates by 40 percent. Moreover, many programs fail to deliver capabilities when promised, experiencing a 21-month delay on average. The report attributes the "optimistic assumptions about system requirements, technology, and design maturity [that] play a large part in these failures" to a lack of disciplined systems engineering analysis early in the program. What acquisition managers do not always realize is the importance of focusing on software engineering during the early systems engineeringeffort. Improving on this collaboration is difficult partly because both disciplines appear in a variety of roles and practices. This post, the first in a series, addresses the interaction between systems and software engineering by identifying the similarities and differences between the two disciplines and describing the benefits both could realize through a more collaborative approach.
The Heartbleed bug, a serious vulnerability in the Open SSL crytographic software library, enables attackers to steal information that, under normal conditions, is protected by the Secure Socket Layer/Transport Layer Security(SSL/TLS) encryption used to secure the internet. Heartbleed and its aftermath left many questions in its wake:
- Would the vulnerability have been detected by static analysis tools?
- If the vulnerability has been in the wild for two years, why did it take so long to bring this to public knowledge now?
- Who is ultimately responsible for open-source code reviews and testing?
- Is there anything we can do to work around Heartbleed to provide security for banking and email web browser applications?