By Julien Delange
Member of the Technical Staff
Software Solutions Division
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.
By Carol Woody
This blog post was co-authored by Robert Ellison.
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.
By C. Aaron Cois
Software Engineering Team Lead
CERT Cyber Security Solutions Directorate
This blog post is the second in a series on DevOps
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. Beyond innovation and delivery, DevOps provides a means for automating repetitive tasks within the software development lifecycle (SDLC), such as software builds, testing, and deployments, allowing them to occur more naturally and frequently throughout the SDLC. This blog post, the second in our series, presents a generalized model for automated DevOps and describes the significant potential advantages for a modern software development team.
By Douglas C. Schmidt
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.
This post includes a listing of each report, author(s), and links where the published reports can be accessed on the SEI website.
By Sarah A. Sheard
Software Solutions Division
This post is the first in a series on this topic.
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 engineering effort. 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.