Third SEI Software Architecture Technology User Network Workshop
May 14-16, 2007 | Sheraton Station Square | Pittsburgh, Pennsylvania

Session Abstracts

15 May 2007
10:30 - 12:00 Session 1: Architecturally Significant Requirements

 

Requirements and Standards Analysis and Modeling
David L. Curry, NAVAIR

Presentation Abstract:
The Automated Requirements Processor (ARP) is a tool currently being developed at NAWS China Lake in support of the Navy Unmanned Air Systems Support Activity. ARP's goal is to introduce, automate and augment the software architecture discipline by isolating individual requirements presented in plain text, providing reports on the quality of the requirements and generating an XML file that can be directly imported by the SEI OSATE tool for further adornment and analysis.

ARP provides software architects, requirements developers, proposal analysts and standards analysts with the ability to judge the quality of what they are writing and reading, reconcile mismatches in terminology, produce drop-in reusable component models and develop reference models quickly, inexpensively, accurately and repeatably, with no data entry beyond converting the target documentation to plain text.

 

Architecting Security In
Jon R. Ramsey, SecureWorks

Presentation Abstract:
The Internet Security problem is thriving on the lack of secure software. The CERT® Coordination Center (www.cert.org) reported a 35% increase in the number of software vulnerabilities discovered in 2006 over 2005. As the world has become interconnected, the gains from hacking and the number of hackers are increasing. Ideally software would be built securely from the start. Like other non-functional requirements such as quality, reusability and maintainability, security is greatly determined by the architecture of a system. This presentation will
1. Give examples of software architectures gone wrong.
2. Give examples of software architecture that take security into consideration.
3. Discuss the role of the software architect in architecting secure systems.
4. Provide recommendations on how to analyze an architecture for security.

 

The Negative Impacts of Ignoring Stakeholder Quality Attributes: A Joint Fire Support Command and Control (C2) Case Study
John Andrew Landmesser, U.S. Army

Presentation Abstract:
This presentation, after providing an overview of the collaborative coordination of the mission execution problem space, will focus on the attempted replacement solution and the current system evolution solutions for the coordination of joint operated deep operations. The presentation will describe the business drivers and key quality attributes of Army Battle Command Systems (ABCS) and lessons learned for future ABCS migration to Net-Enabled Command Capability (NECC).

 

15 May 2007
1:00 - 2:30 Session 2: Application of the SEI's Software Architecture Methods Within Organizations

 

SEI Architecture Techniques Enhancements to the RUP
Stuart Kerrigan, Ericsson
Richard van Schelven, Ericsson

Presentation Abstract:
The Rational Unified Process (RUP) is a software engineering process framework. It provides a disciplined customer-focused approach to assigning and managing tasks and responsibilities in a software development process. The RUP guides software practitioners in effectively applying modern best practices for software, such as developing iteratively and incrementally, taking an architecture-centric approach, mitigating risk at every stage in the process, and continuously verifying the quality of the software.

Although the RUP is quite comprehensive, enhancements are required, specifically in the areas of Architecture, Project Management and Product Development. The Software Engineering Institute (SEI) leads in the architecture field, specifically in the areas of architecture definition, architecture documentation, architecture evaluation and the software product lines approach. These approaches, along with others, can be used and integrated into the RUP. The flexibility of the RUP allows these additional approaches to be integrated into a robust process framework.

This presentation gives an overview of the enhancements we made to the RUP-specifically in the area of architecture-and how we use the techniques from the SEI to help overcome these issues. It will highlight the areas where the techniques where used, how effective they were, where we differed in approaches and some of the challenges we were faced with as we introduced the changes.

 

How the QAW Helped Our Enterprise Architecture Effort
Stephen T. Le Tourneau, Sandia National Laboratories

Presentation Abstract:
This presentation will describe our experiences of applying the SEI Quality Attribute Workshop to enterprise-level application projects and how it (unexpectedly) played a key role in uncovering architectural elements for a larger Enterprise Architecture effort.

 

Integrated City Operation Center: An architecture Case Study with ADD and Data Analysis
Changhyun Baek, Samsung SDS, IT Engineering Center

Presentation Abstract:
Integrated City Operation Center (ICOC) is the operating and control center for the ubiquitous city (U-city), where virtually everything is linked to an information system through various u-services and u-devices across the whole city.

Since the ICOC is an emerging concept, it is expected to be playing a vital role in the success of U-city. With this given major business driver, the ICOC system was started, but it wasn't clear how to build the architecture for it. It was expected to be a software-intensive system that combines the various COTS components including GIS products, rule engines, and 3-D modeling engines and databases. Also, since the concept was new to every stakeholder, it was very difficult to identify the clear requirements as well.

To solve this problem, we decided to define a conceptual architecture that can present the high-level concerns of stakeholders. Therefore, we tailored the SDS architecting process in order to apply the ADD and data flow analysis. At first, we defined a specific business case from existing city planning data and several assumptions. Then we analyzed I/O data in the u-city environment. Data flow analysis was the key activity in this process; thus we could define the architectural elements and their relationship to ICOC.

This case study will show following:

In this session, we will introduce the case study of the ICOC architecture of Samsung SDS and describe the architecture process with ADD, data flow and I/O analysis.

 

16 May 2007
1:00 - 2:30 Session 3: System of Systems Architecture

 

Systems of Systems Architecture Evaluation with Concurrent Development
Mike Gagliardi, Software Engineering Institute
Bill Woods, Software Engineering Institute

Presentation Abstract:
Large-scale software-intensive widely-distributed battlefield systems of systems (SoSs), such as FCS, have some challenging characteristics. There are software elements being developed concurrently by different contractors that will (1) be installed in different weapons, sensor, and command and control platforms, (2) be the basis for providing a shared view of the battlespace across platforms, and (3) allow for distributed planning, decision making and remote engagements. The development is usually done in a number of phases, with roughly 18 months to 2 years between phases. Each phase typically demonstrates the capability to provide the planned functionality and performance for the phase and may spin off some of these capabilities to the field.

There are a number of mission threads that are used to describe the inter-platform and inter-element operations of the system. Mission threads can describe tactical operations, logistical operations, support operations, and maintenance, training, test and development operations. Mission threads serve as drivers for developing the architecture and as the basis for test cases during a verification cycle.

The major software elements being developed for the SoS may each have their own software architecture design documentation (SADD), perhaps built with diverse tools and using diverse notations. This makes it difficult to evaluate whether the integrated architecture composed of many of these shared elements will satisfy the mission threads. Moreover, since the architecture is driven primarily by the quality attributes, the mission threads need to be augmented with quality attribute considerations for architecture development and evaluation activities.

This presentation will describe an approach to integrating all of these factors in such a way that successful evaluation of the SoS architecture against the mission threads can take place.

 

Technology and Product Evolution - Impact on the Architecture of a Complex Medical Product
Pramod Chandrasekhar, Philips Electronics India Ltd

Presentation Abstract:
In the history of complex systems, a recurring development process pattern exists in which a new approach, design or architecture is introduced to partly replace existing functionality that is attaining obsolescence. The reason for this partial line of attack is that a complete replacement of existing functionality is deemed too invasive and risky. The intention is that at the next occasion (typically a development cycle) the remains of the obsolete implementation will be fully replaced by the new approach. It is not until this time that the functional and architectural benefits of the new method can be reaped. The practice is that, when the next project emerges, great emphasis is placed on a few new functional features that must enter the market in the shortest time possible. Promises or agreements that the old hat must be gotten rid of are quickly traded for seemingly more attractive short-term goals.

What seems to be overlooked is that each time a new dual-track is entered, maintenance costs rise. What is much worse is that future development is curtailed because whatever is developed in the new design must remain compatible with the old implementation with which the new line is condemned to cohabitate in the same or similar applications. When this cohabitation is forced to go on for an extended time, the new implementation starts to suffer from its (potentially advantageous) adaptability and starts to adopt the idiosyncrasies of the components it was designed to replace.

In our product, an MR scanner, this was evident from the striking fact that there evolved two distinct ways in which the scanner could be operated. In order to facilitate ease of use and thereby increase throughput, a solution evolved that automated a lot of tasks that were inherently performed by the operator. This new path, termed ExamCards, however could not provide the complete functionality that was present in the old way of operating the system-the ScanList environment as it was termed. This led to the fact that the operator had to switch between these environments in order to exercise the complete set of options provided.

Architecturally this was a nightmare, since solutions or software that had to be built into the system (for the introduction of new functionalities that the market demanded) had to support both of these worlds. Moreover, as in typically large software systems, there exists a lot of history and legacy that needs to be carried forward. The presentation will focus on experiences in dealing with the architectural challenges of the described system.

 

A Product Line Architecture for Army Aviation Diagnostics and Maintenance: Views and Evolution
Ken Capolongo, C-E LCMC, SEC, Avionics Brach
Sholom Cohen, Software Engineering Institute

Presentation Abstract:
Army Aviation vehicles are complex systems of systems and require many resources to operate and sustain, especially in a combat environment where aircraft availability and readiness are essential to the successful completion of battlefield missions. The Communications-Electronics Lifecycle Management Command (C-E LCMC) Software Engineering Center (SEC) is responsible for providing diagnostic products to support these aircraft in the field and is facing the challenge to produce more products with similar or fewer resources, brought on by the current business environment and operational tempo (OPTEMPO). This presentation discusses how the C-E LCMC SEC is meeting the challenge through the adoption of software product line engineering practices, especially that of Architecture Definition, for the Advanced Multiplex Test System (AMTS) product line.

A key factor in the success of this product line is the software architecture. This presentation focuses on that architecture and its evolution from supporting a single system to an architecture that supports a product line of diagnostic tools. These tools are currently used to support diagnostics/maintenance of the AH-64A Apache Attack Helicopter with other product line products in development for the Armed Reconnaissance (ARH-70A), Kiowa Warrior Scout/Attack (OH-58D), Chinook Cargo (CH-47F), and Black Hawk Utility (UH-60M) helicopters.

The architecture will continue to evolve to support new features, including tele-maintenance, condition-based maintenance, and service-oriented diagnostics/maintenance. The development of a flexible software product line architecture will be used to facilitate production of avionics maintenance software products that improve avionics field maintenance practices, reduce sustainment costs, and increase aircraft readiness.

 

16 May 2007
3:00 - 4:00 Session 4: Architecture Competence

 

Neglected Aspects of Software Architecture
G. Todd Kaiser, Raytheon Intelligence and Information Systems, Space Systems

Presentation Abstract:
In our zest to tackle the hardest problems in the software industry, software architects apply the latest techniques, processes, tools and technology to create the best software architecture for the systems they are working on. We apply service-oriented approaches, we claim that the architecture is going to be developed using agile methods, and we use architectural documentation to communicate our brilliant ideas. Our architectures rigorously examine the structure, data and behavior of the software that we are going to build. We examine the quality attributes of performance, reliability, etc.

For all the work we do to ensure the best architecture that we can devise, we often doom our architectures to failure because we neglect the aspects of the architecture that end up being the most important. Schedules, budgets, team agreements, workshare, etc., are very important aspects that affect and are affected by our architectures. This presentation will discuss how these aspects can (and should) affect software architectures and why the "best" architecture from a technology standpoint is not always the "optimum" architecture.

 

Improving Architecture Competence: A Status Report
Paul Clements, Software Engineering Institute

Presentation Abstract:
At the last SATURN workshop, participants heard about a new project in the SEI Software Architecture Technology Initiative titled "Improving Architecture Competence." The goal of this work is to be able to help a software-producing organization measure and improve its ability to predictably and reliably turn out high-quality architectures that align with the organization's business goals and requirements. This talk will discuss the project, its approach and strategies, and summarize results so far. In particular, different models of competence will be discussed, along with how they contribute to the goals of measurement and improvement.