SEI’s Architecture Practices Work Showcased at 35th International Software Engineering Conference (ICSE)

From May 19–26 2013, many SEI staff members participated in the International Conference on Software Engineering (ICSE), the premiere venue for research in software engineering. The conference was in its 35th year, and ran over seven days in downtown San Francisco. You can find post-conference materials here, or here. This blog post discusses some of the activities of SEI staff in the Architecture Practices initiative.

ICSE is a great opportunity for SEI technical staff to present emerging results, listen to other researchers, engage with industry practitioners, and continue the SEI’s leading role in the software engineering research community.

The highlight of the SEI’s involvement was the keynote on the final day of the conference by Linda Northrop, entitled Does Scale Really Matter? Ultra-Large-Scale Systems Seven Years After the Study (PDF). Linda gave an overview of the state of the ULS systems research field since the seminal report.

This post highlight the efforts of the Architecture Practices research group. We had two papers accepted for the main conference, on rapid fielding practices and assurance case confidence.

Enabling Rapid Fielding

Stephany Bellomo, Robert Nord and Ipek Ozkaya presented A Study of Enabling Factors for Rapid Fielding: Combined Practices to Balance Speed and Stability, in the Software Engineering in Practice track. This paper suggests some methods to resolve the “natural tension between the pressure to deliver functionality quickly (speed) and the desire for a reliable, stable, and flexible product (stability).”

Typical experiences, based on a series of in-depth interviews the team conducted with five governmental and industrial organizations, were that projects began with a focus on speed, until some external trigger, such as the shift from a centralized workforce to a globally distributed one, forced a re-examination of the project and corresponding attention to stability.

Teams used different practices to balance their focus on speed with the need for stability, including:

  • Release planning with architectural considerations: The tradeoff is realized when it becomes difficult to coordinate parallel development, due to a lack of a common architecture. Teams then re-focused and began attaching “design memos” to feature descriptions, ensuring a shared understanding.
  • Prototype/demos with quality attribute focus: Here, a short-term focus on features at the expense of other qualities resulted in an unacceptable drop in performance. To overcome that lack of stability, teams would ensure that quality attribute scenarios were added to the prototyping sessions.

The paper includes several other enabling factors for rapid fielding. A companion paper, published at the Workshop on Twin Peaks of Requirements and Architecture (TwinPeaks), expands on the second enabling factor: Elaboration on an Integrated Architecture and Requirement Practice: Prototyping with Quality Attribute Focus, by the same three authors.

Eliminative Induction

John Goodenough, Chuck Weinstock, and Ari Klein presented “Eliminative Induction: A Basis for Arguing System Confidence,” in the New Ideas and Emerging Results track. There is a related piece of work from the ASSURE workshop entitled “Measuring Assurance Case Confidence Using Baconian Probabilities,” which expands on the main paper.

These papers lay a theoretical foundation for using eliminative induction for software assurance. Eliminative induction can be described using the following example. Suppose you are interested in understanding whether a light will turn on when the switch is flipped. The frequentist statistical approach will suggest that, having come on many times in the past, the light will come on this time when the switch is flipped. In Goodenough, Weinstock, and Klein’s paper, the approach is to ask instead whether there is any reason to doubt that the light will turn on. Examples of such doubts include

  • Is the switch connected to a power source?
  • Is there a bulb in the light socket?
  • Is the switch wired properly?

These are all considered prior to flipping the switch. If we have eliminated all known reasons for doubt, we can say we have reasonable confidence that the light will turn on. Now, this is a trivial example, but this research, part of the SEI’s wider work on software assurance, is focused on areas where data on past performance is not necessarily available, or it is not possible to complete system testing.

Other Involvement

Architecture Practices staff were also involved with panels: Ipek Ozkaya was invited to present at a panel on “Technical Debt: Past, Present, and Future.” Ipek shared her deep expertise on technical debt. Chuck Weinstock was a panelist at the Software Engineering in Health Care workshop, and John Goodenough was a panelist at the Assure workshop.

The Architecture Practices group also participated in a number of affiliated workshops:

  • Rick Kazman: Introducing Tool-Supported Architecture Review into Software Design Education, presented at Conference on Software Engineering Education and Training.
  • John Klein and John McGregor: “System-of-Systems Platform Scoping,” Product LinE Approaches in Software Engineering Workshop
  • John McGregor: “Exploring Software Supply Chains From a Technical Debt Perspective,” Managing Technical Debt Workshop
  • Ian Gorton: “Tales from the (Scientific Software) Engineering Abyss,” TwinPeaks Workshop keynote.
  • Chuck Weinstock gave an invited talk on “Are major new developments needed in software engineering to address the demands of the health care industry?” at Software Engineering in Health Care Workshop.

We also helped organize workshops:

  • Ian Gorton: Organizing Committee member, International Workshop on Software Engineering Challenges for the Smart Grid (SE4SG 2013)
  • Philippe Kruchten, Robert Nord, Ipek Ozkaya: Workshop organizers, 4th International Workshop on Managing Technical Debt

- Neil Ernst, SEI

About these ads

One response to “SEI’s Architecture Practices Work Showcased at 35th International Software Engineering Conference (ICSE)

  1. Using eliminative induction when you can’t test sounds interesting.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s