April 29 to May 3, 2013
The SEI Software Architecture Technology User Network (SATURN) workshops bring together engineers, architects, technical managers, and product managers to exchange best practices in developing and acquiring software architectures and using them to build predictable, high-quality systems.
SATURN workshops provide a unique opportunity for participants to learn from each other through presentations, tutorials, and working sessions. Participants share how they successfully use software architecture practices within their organizations to ensure predictable product qualities, cost, and schedule. SATURN workshops also give participants an opportunity to give practical feedback to the SEI about future directions in software architecture technology and practices.
This year's SATURN workshop included four tutorials, two keynote presentations, 11 presentations on practitioner experiences in using SEI software architecture technology methods and techniques, a panel on experiences in using the SEI Architecture Tradeoff Analysis Method® (ATAM®), and four working sessions. Participant presentations covered topics in software architecture such as architecturally significant requirements, system of systems architecture, architecture design and evaluation, and architecture competence. Working sessions covered promising future directions in software architecture technology and practices. They provided participants opportunities to discuss these topics with colleagues in other organizations and to give feedback to the members of the SEI about their work in this area. This year, SATURN brought together professionals from over 30 organizations.
We hope you found the SATURN 2007 experience beneficial and look forward to seeing you at future workshops.
Ipek Ozkaya, Software Engineering Institute
Rob Wojcik, Software Engineering Institute
Architecting Security In
Jon R. Ramsey, SecureWorks
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 nonfunctional requirements such as quality, reusability, and maintainability, security is greatly determined by the architecture of a system.
How the QAW Helped our Enterprise Architecture Effort
Stephen T. Le Tourneau, Sandia National Laboratories
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 & Data Flow Analysis
Bae Changhyun, Samsung SDS
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 play 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 SEI Attribute Driven Design (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 the following:″ how ADD could help to define the architectural elements and their relations″ how the SDS architecting process was applied within this process″ how data flow analysis helped define this process 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.
SEI Architecture Techniques complementary to the RUP
S. Kerrigan, Ericsson
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 line 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, were we differed in approaches, and some of the challenges we were faced with as we introduced the changes.
Software Architecture Technology Initiative
Mark H. Klein
A presentation by Mark Klein of the Software Engineering Institute.
Welcome to SATURN 2007 the Third SEI Software Architecture Technology User Network Workshop
A presentation by Ipek Ozkaya and Rob Wojcik of the Software Engineering Institute.
A Light-Weight Architecture Trade Off Process Based on ATAM A Panel Presentation: Sharing Experiences with ATAM
Jon S. Edmondson, NCS
Charles G. Kille, NCS
Edwin W. Lee, SAS
This paper presents the creation and application of a process we named "ATO Lite" (Architecture Tradeoff Lite), derived from the SEI ATAM. Transformation of ATAM to "ATO Lite" created a front-end tool that assists architects with development of robust, focused architecture in a time- and cost-effective manner.
Common ATAM Errors
The intent is to be able to discuss based on experience how to be part of an ATAM evaluation, either as an evaluator or an evaluatee, depending on the audience.
A Case Study in applying Architecture Evaluation Methods
Opal Perry, Wells Fargo & Company
This presentation will discuss our efforts to introduce scenario-based architectural evaluation methods for new systems development efforts within a division of Wells Fargo and Company, a diversified financial services company providing banking, insurance, investments, mortgage and consumer finance for more than 23 million customers through 6,100 stores, the internet and other distribution channels across North America and elsewhere internationally.
Introducing Scenario-Based Architecture Reviews
Opal Perry, Wells Fargo & Company
Presentation for the 2007 SATURN workshop held in Pittsburgh.
Technology Evolution – Impact on Architecture of a Complex Medical Product
Pramod Chandrasekhar, Philips Medical Systems
Ajay Nitin, Philips Medical Systems
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 must 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
Sholom G. Cohen
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.
System of Systems Architecture Evaluation with Concurrent Development
Michael J. Gagliardi
William G. Wood
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 its 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.
Improving Software Architecture Competence
Paul C. Clements
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.
Neglected Aspects of Software Architecture
G. Todd Kaiser, Raytheon Intelligence and Information Systems
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, and so forth. 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, and so forth, 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.
Evaluating a Service-Oriented Architecture
Tools for Making Better Architecture Decisions
Tools are essential to support software architecture design and evaluation methods. In this talk, I'll describe some novel, prototype tools for architecture knowledge management, collaborative architecture design and decision making, and performance analysis of COTS-based architectures. A brief overview of the aims and major features of each tool will be presented, and their use in industrial projects will be discussed.
Automated Requirements Processing Overview
David L. Curry, NAWCWD China Lake
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.
The Negative Impacts of Ignoring Stakeholder Quality Attributes: Joint Fire Support (FS) Command and Control (C2) Case Study
John A. Landmesser
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).
An Architecture Journey
This talk is a retrospective, journaling experiences practicing architecture in environments as varied as telecommunications, academia, dot com and post-dot com era startups, a large (very!) independent software vendor and enterprises in media and financial services. Each environment provided many lessons that served to shape and guide the approaches to the discipline-the art and the science-of architecture: building on the base skills of software engineering, adding a structural modeling perspective for architecture definition, achieving an appreciation of the fundamental nature of architectural quality, and accumulating a deep respect for the human dynamics that drive organizations.
April 29 – May 3, 2013
Get the latest SATURN news, important dates, and announcements on the SATURN Network blog, sign up for our email updates, follow us on Twitter (@SATURN_News, #SATURN2013), and join the SATURN LinkedIn Group.
Phone: +1 412-268-5800
Toll Free (within the USA): +1 888-201-4479
FAX: +1 412-268-6257
Please tell us what you
think with this short
(< 5 minute) survey.