Investigations into potential causes of Unintended Acceleration (UA) for Toyota vehicles have made news several times in the past few years. Some blame has been placed on floor mats and sticky throttle pedals. But a jury trial verdict found that defects in Toyota's Electronic Throttle Control System (ETCS) software and safety architecture caused a fatal mishap. This verdict was based in part on a wide variety of computer hardware and software issues. This talk will outline key events in the still-ongoing Toyota UA story and pull together the technical issues that have been discovered by NASA and other experts. The results paint a picture that should inform not only future designers of safety-critical software for automobiles but also all computer-based system designers.
It is our intent that they form the industry de facto standard taxonomy of testing pitfalls and will be widely used for the following:
Video-game development is arguably one of the most difficult kinds of software development due to its combination of performance requirements, diverse team, immovable deadlines, and the fact that the software must be more than functional, it must also be fun. In this talk, Jesse Schell explains what he has learned from 20 years of professional game development about the secret forces that help teams succeed or cause them to fail.
Since its inception in 1988, the CERT Coordination Center (CERT/CC) has been analyzing and coordinating software vulnerabilities. The CERT/CC’s vulnerability response process includes discovering and reporting, analyzing, coordinating with vendors (software development organizations), and public disclosure. The results of this work are documented in the Vulnerability Notes Database. One observation highlights a disconnect between software engineering, design, and development practices and constantly evolving threats posed to highly interconnected software and systems.
The CERT/CC contributed to the Data-Driven Software Assurance (DDSA) project recently published by the SEI. A significant area of the DDSA research investigated operational vulnerabilities that “likely had their origins early in the life cycle, in the requirements and design phases.” To give one example, the lack of threat modeling, particularly in emerging domains, leads to insecurity.
This session will provide background on and examples of the life cycle of vulnerabilities, with the goal of improving the connection between software development and increased operational security. The session will also highlight design-related causes of vulnerabilities and software security issues affecting the growing “Internet of Things.”
From the beginning of a little process to the start of a hybrid Scrum-Team Software Process (TSP) product development process, the presenters will describe the two-year development methodology journey of a fast-growing company leading solutions for medical device information systems. The hybrid development method is a perfect example of TSP as a data and process framework combined with the best of Scrum practices and adapted to the regulated environment of health care. The presenters will explain how the journey evolved from the launch of one small software development TSP team to cross-functional hybrid team launches.
Have you ever worked on a software project that didn’t result in what the users really wanted? Stakeholders often have requirements that they aren’t aware of. Uncovering them can be challenging and involves ways of thinking not found in more traditional elicitation approaches. It requires probing interviews and expanded use of context information that go well beyond what the requirements engineer typically achieves with a specification-driven process. It requires a method that transforms stakeholders’ tacit knowledge into themes of experience so that insightful and innovative requirements can emerge.
The KJ+ method for eliciting unstated requirements, currently under development by a research team at the Software Engineering Institute, helps determine the unstated needs of the varied stakeholders typical of today’s large, diverse software projects. This method will be scalable to address the needs of multiple categories of stakeholders; be usable by a diverse, non-collocated team of requirements analysts; and result in a more complete set of requirements for subsequent system design, implementation, and sustainment. It can be used to support both traditional requirements specifications and Agile user stories.
This tutorial will present the traditional KJ method for eliciting unstated user needs and the extensions that allow KJ to be used in a virtual environment. Also included are activities integral to learning the KJ+ method:
Practitioners who are concerned with delivering exciting and innovative features will learn how to apply KJ+ in their own projects. Researchers will find the kinds of requirements obtained using KJ+ vs. more traditional approaches of interest.
Learning Outcomes