In 2013, the Software Engineering Institute (SEI) Architecture Technology User Network (SATURN) software architecture onference will celebrate its 9th year. Each year SATURN attracts an international audience of practicing software architects, industry thought leaders, developers, technical managers, and researchers to share ideas, insights, and experience about effective architecture-centric practices for developing and maintaining software-intensive systems.
Posted in Architecture and Agile, Architecture-Centric Engineering, Architecture-Centric Practices, Conferences and Events, Quality Attribute Analysis, SATURN Conference, Service-Oriented Architecture
Tagged architecture certification, architecture evaluation, architecture review, Architecture Tradeoff Analysis Method, ATAM, attribute-driven design, Carnegie Mellon, cloud computing, documentation, non-functional requirements, SATURN 2013, SATURN Conference, SATURN Network, SEI, SOA, software architecture, software architecture evaluation, software architecture requirements, software architecture review, software design, software development, software engineering, Software Engineering Institute, system architecture, system of systems, systems architecture, technical debt, testing, ULS systems, ultra-large-scale systems
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:
- The fundamental early decisions made during the pre-engineering and manufacturing development (pre-EMD) phase have an impact throughout the lifecycle.
- The implications of the early decisions often surface in the final stages of the lifecycle, downstream from development.
Read the full post here.
Posted in Architecture and Agile, Architecture-Centric Practices, From the Trenches
Tagged agile release planning, SEI, software architecture, software design, software development, software engineering, Software Engineering Institute, system architecture, systems architecture
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.
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.
Posted in Architecture and Agile, Architecture-Centric Engineering, Quality Attribute Analysis, Ultra-Large-Scale Systems
Tagged architecture evaluation, SEI, software architecture, software design, software development, software engineering, Software Engineering Institute, system architecture, system of systems, systems architecture, testing, ULS systems, ultra-large-scale systems
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.
Posted in Architecture and Agile, Architecture-Centric Engineering, Architecture-Centric Practices, SATURN Conference
Tagged ADD, Agile Alliance, ATAM, attribute-driven design, documentation, non-functional requirements, SATURN 2010, SATURN Conference, software design, software development, system architecture, systems architecture
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.
Thursday, May 13, 2010
Time: 1:00 PM – 2:00 PM EDT
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.
Thursday, May 6, 2010
Time: 12:00 PM – 1:00 PM EDT
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).
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.
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.