12:15 p.m. – 1:15 p.m.
ISE 01 – Influencing Without Authority
Presenter: Rick Hefner
Description: When an organization needs to change (for example, adopting a new quality standard), the change initiative is often assigned to a change agent. Leading the change can be difficult if that change agent does not have any direct authority over the people whose behavior needs to change have not bought in, and they do not see the benefit in changing.
1:30 p.m. – 2:30 p.m.
ISE 02 – Software Reliability Engineering Contributions to Software Security
Presenter: Taz Daughtery
Description: Software reliability engineering represents a well-established set of techniques supporting specification and assessment of dependability aspects of software-based systems. Key aspects include: establishing quantitative reliability targets, constructing usage profiles of the operational system, and conducting statistically based testing to predict system reliability. Security analysis would involve suitable modifications, such as: establishing multiple quantitative targets including availability and loss function, using threat modeling to identify a variety of misuse/abuse cases, and rethinking reliability growth modeling for application to security growth modeling. Security growth modeling, analogous to reliability growth modeling, is an attempt to quantify how the projected security of a system increases with additional detection and removal of software vulnerabilities. Such insights would be crucial in allocating development and assurance resources, as well as making informed release or revision decisions.
ISE 03 – Risk–based Agile Deployment of Mobile Medical Apps in Healthcare IT
Presenter: Byron Mattingly
Description: This talk focuses on risk management/control throughout the software lifecycle and how to use the FDA’s Mobile Medical Applications (draft) guidance and "Agile Manifesto" (expected to be finalized in 2012 as AAMI TIR 254) to optimally deploy smartphone and tablet apps in a rapidly changing healthcare technology landscape. Specific examples illustrate the importance of supporting Agile systems engineering and software development best practices (e.g., “test-first,” “loose coupling,” etc.) with some of the newest quality technologies. First, the scope of the definitions for mobile platforms, mobile applications, and mobile medical applications (as per the FDA’s guidance) is examined in the context of validations of iPad and Android-based tablet apps. Next, the so-called “FDA Agile Manifesto” (AAMI TIR 254) is investigated. Finally, mobile medical apps will be considered as complex systems in a validation environment of an ever-changing healthcare IT ecology. Recommendations will be made to minimize the effects of “vertical cascading,” which can push an overall system to a tipping point and into catastrophic failure.
3:00 p.m. – 4:00 p.m.
ISE 04 – Proving the Value of Quality Through Metrics and Communication
Presenter: Carol Dekkers
Description: As software and quality practitioners, we understand the value and positive return on investment (ROI) of quality, yet the rest of the world often needs to be convinced. This presentation focuses on tools, techniques, and tips to aid the quality professional to effectively communicate (and prove) the value of quality to constituents, peers, bosses, and subordinates to achieve success.
4:15 p.m. – 5:15 p.m.
9:15 a.m. – 10:15 a.m.
ISE 06 – Leveraging the CMMI to Pursue Excellence in Software Development
Presenter: David Walker
Description: The CMMI has been used by tens of thousands of software organizations to improve product development processes in an incremental manner. This presentation will describe what the CMMI is, how it is properly used, distinguishing features, and how to leverage the CMMI to get started, get good, and pursue excellence in software development.
10:45 a.m. – 11:45 a.m.
ISE 07 – Risk–based Approach to Grading Software
Presenter: David Peercy
Description: A graded approach for determining an acceptable software practice level based on consequence and likelihood levels is described in this presentation. The risk-based approach depends on the system context for the software application and is linked to the practice activities of the SEI CMMI. In addition, depending on the criticality of the software (e.g., safety consequences) additional practice activities are defined. The following steps summarize the graded approach described in this presentation. Step 1: Determine consequence of failure level. The consequence table provides five levels of potential impact or consequence of an undesirable event resulting from a software failure. The consequence level is selected based on the intended use for the software application and the potential consequence of a software failure without consideration of potential mitigation factors. Step 2: Determine likelihood of failure level. The likelihood table provides five levels of likelihood that a software failure would result in an undesirable event. In this case, all nonsoftware-specific mitigations are considered. Step 3: Determine risk level and associated practice level. The pairing of the consequence and likelihood of failure levels determines the risk level for a project. Each of these risk levels is associated with a recommended practice implementation level. The recommended practice level provides the additional software mitigations against failure that should provide an acceptably low level of risk. Step 4: Risk level adjustment. If a different practice level than the one resulting from the combination of consequence and likelihood of failure levels is warranted, then specific adjustments with documented rationale can be performed.
1:15 p.m. – 2:15 p.m.
ISE 08 – Risk-based Configuration Control — Balancing Flexibility With Stability
Presenter: Linda Westfall
Description: There is a dichotomy in software configuration management. On one side, individual developers need the flexibility necessary to do creative work, to modify code to try out what-if scenarios, and to make mistakes, learn from them, and evolve better software solutions. On the other side, teams need stability to allow code to be shared with confidence, to create builds and perform testing in a consistent environment, and to ship high-quality products with confidence. This requires an intricate balance to be maintained. Too much flexibility can result in problems, including unauthorized and/or unwanted changes, the inability to integrate software components, uncertainty about what needs to be tested, and working programs that suddenly stop working. On the other hand, enforcing too much stability can result in costly bureaucratic overhead, delays in delivery, and may even require developers to ignore the process in order to get their work done.
8:00 a.m. – 9:00 a.m.
ISE 09 – Converting Requirements into Tests
Presenter: Louise Tamres
Description: When receiving requirements, many perceive a magical step that automatically yields test cases. This could be true if requirements are complete, unambiguous, and presented in an all-encompassing format. Applying test design techniques is one way of analyzing and modeling requirements. Using the principle that a picture is worth a thousand words, a good model focuses on content and helps the consumer ask the right questions. Common examples include Decision Tables, Use Cases, Classification Trees, and Pairwise Testing. These methods, which apply at all levels – from unit testing through system testing – can improve requirements, software designs, and test documentation. These same techniques can also assist developers in identifying key functionality to implement. Next time, why not incorporate the development of these models as part of the actual requirements definition?
9:30 a.m. – 10:30 a.m.
ISE 10 – Safe and Secure Software Systems and the Role of Professional Licensure
Presenter: Phillip Laplante
Description: Licensure of certain software engineers in the United States will be required in at least 10 states by 2013 and, likely, by all U.S. states and jurisdictions within a few years. States license engineers to ensure that those who offer services directly to the public are minimally competent. But what kinds of software systems affect the health, safety, and welfare of the public? Which software engineers will need to be licensed? The answers to these two questions are both a matter of law and of science. This session introduces some of the scientific aspects of these two questions from the perspective of reliability engineering and suggests new research directions to help answer these questions.