Rapid Lifecycle Development in an Agile Context

This blog post at the SEI blog describes research on providing software and systems architects with a decision-making framework for reducing integration risk with Agile methods, thereby reducing the time and resources needed for related work.

The research explores the implications of decisions made over the course of the software and systems lifecycle. It examines when these decisions are made and the time when the implications surface to validate the following hypotheses:

1. The fundamental early decisions made during the pre-engineering and manufacturing development (pre-EMD) phase have an impact throughout the lifecycle.
2. The implications of the early decisions often surface in the final stages of the lifecycle, downstream from development.

Read the full post here.

A New Approach for Handheld Devices in Tactical Networks

The U.S. Department of Defense (DoD) is increasingly interested in having soldiers carry handheld computing devices to support their mission needs in tactical networks. Not surprisingly, however, conventional handheld computing devices (such as iPhone or Android smartphones) for commercial networks differ in significant ways from handheld devices for tactical networks. For example, conventional devices and the software that runs on them do not provide the capabilities and security needed by military devices, nor are they configured to work over DoD tactical networks with severe bandwidth limitations and stringent transmission security requirements.

This post at the new SEI blog describes exploratory research that the SEI is conducting to (1) create software that allows soldiers to access information on a handheld device and (2) program the software to tailor the information for a given mission or situation.

SEI architecture research planned for 2011

Each year, the SEI conducts a program of research in architecture-centric engineering. These are the topics that we plan to investigate in 2011:

1. Quality Attribute Foundations and Analysis

• Resource allocation for massively parallel multicore platforms–developing task models, resource abstractions, and scheduling strategies for predicting real-time performance
• Static analysis for multicore—investigating use of scalable static analysis to ensure that concurrency-related invariants are preserved as systems move to multicore platforms.
• System reliability framework—developing new metrics and approaches for using architecture knowledge to assure the safe and reliable operation of software-reliant systems
• Architecture-based testing—investigating techniques for using architecture knowledge to inform and reduce system testing.

New Edition of Documenting Software Architectures: Views and Beyond

Documenting Software Architectures: Views and Beyond, Second Edition, is now available at the Addison-Wesley website InformIT, where lead author Paul Clements discusses the new edition in an interview.

SATURN 2010 TECHdotMN Session Notes, Wednesday, May 19

SATURN 2010 / TECHdotMN field notes
by Jeff Pesek 5/19/10

Architecturally Focused Techniques for Managing System Evolution by William Koscho

Based on the premise that business strategy, process and units will inevitably change – the architect’s objectives are to: (a) understand/accept potential changes in the environment, (b) manage relationships between the environment and the architecture and (c) minimize the risk of the implementing change.

“Is this strategic change we want to invest in or is it arbitrary and therefore cost-sensitive?” Mr. Koscho asks in describing the internal thought process.

SATURN 2010 Session: Software Architecting in Agile Software Development

Ger Schoeber, Sioux Embedded Systems: Architecting & Agile: Friends or Enemies

Described a system architecting process, an incremental multi-disciplinary development approach. Starts with requirements derived from business goals for customers. Develops embedded software on a project basis. “We get paid only if our customers meet their goals.” Known functional requirements are main drivers.

Development process follows Scott Ambler’s approach. Start with a first iteration or sprint–focusing on requirements and architecture as foundation for activity, then build software on top of that. Embedded systems must take into account the environment in which the software must operate. Short sprints for software, less frequent iterations for electronics, and less frequent for mechanics. Then find integration points among software, electronics, and mechanics as early and frequently as possible.

SEI Webinar May 13: Lisa Brownsword and Carol Woody, Engineering Improvement in Software Assurance: A Landscape Framework

Thursday, May 13, 2010
Time: 1:00 PM – 2:00 PM EDT
Cost: Free

Abstract

Many organizations are associated with producing, using, or funding technologies, practices, and policies purported to address assurance—a justified level of confidence that systems (and systems of systems) will function as intended within their operational environments. Understanding the value these solutions provide to assurance is often indirect and unclear. Where are the critical gaps in available technologies and practices? Where should resources be invested to gain the most benefit? To accelerate the formation and adoption of solutions, a more systematic approach is needed to model the assurance landscape.

INCOSE Webinar May 6, Peter Feiler, Model-Based Engineering of Software-Reliant Systems with the Architecture Analysis & Design Language (AADL)

Thursday, May 6, 2010
Time: 12:00 PM – 1:00 PM EDT
Cost: Free

Abstract

In this presentation we first discuss some of the challenges in building safety-critical systems that are increasingly software reliant and the need for formal analysis of system models discovering system-level problems earlier in the development. We then provide a summary of the capabilities of the SAE AADL standard suite, its application in industrial initiatives and research projects, as well as its relationship to other standards. We close the presentation with a case study of an international aircraft industry initiative called System Architecture Virtual Integration (SAVI).

Register.

About the Speaker

Peter Feiler is a 25-year veteran at the Software Engineering Institute (SEI). He is the technical lead and author of the SAE International Architecture Analysis & Design Language (AADL) standard suite. His research interest is in architecture-centric model-based engineering to improve the reliability of software-reliant systems.

Software architecture for acquisition people

I recently gave a presentation titled “The Importance of Software Architecture in the Acquisition Process.”

My basic argument was that software is critical in the system development process and software architecture is critical in the software development process.

The most difficult portion of the argument for me was the first premise. Arguing that software is critical for system development is kind of like arguing that 1+1=2. I have been in the software business too long to be able to look at this problem with outsiders’ eyes. I fell back to a cost argument and used cost figures from defense systems. I found this very unsatisfactory but it was the best I could do.

The criticality of software architecture to the software development process is something I have been arguing for years and I found this argument much easier to make.

The extension to acquisition depends on the level of involvement and oversight that acquisition personnel are willing and able to make.

In any case, you can see the presentation here.

Len Bass

Researchers Showing Interest in AADL Standard

In a recent paper, Peter Feiler, technical lead and author of the Architecture Analysis and Design Language (AADL) industry standard notation, points out that more than 160 publications in refereed conferences and journals have been published about the standard since it was published in 2004 by SAE International. An updated version was published in 2009. In his research brief, Peter provides detail on the development of AADL and on MetaH, a precursor to the standard.