Last week, we posted a link here to an article at the SEI blog about how Bursatec, the technology arm of Groupo Bolsa Mexicana de Valores (BMV, the Mexican Stock Exchange), used architecture-centric engineering to respond to its challenges.
Part two of this article was posted today: Using Team Software Process (TSP) to Architect a New Trading System, by James McHale.
Posted in Architecture-Centric Engineering, Architecture-Centric Practices, Quality Attribute Analysis
Tagged ADD, architecture evaluation, architecture review, Architecture Tradeoff Analysis Method, ATAM, attribute-driven design, non-functional requirements, SEI, software architecture, software architecture evaluation, software architecture requirements, software architecture review, software design, software development, software engineering, Software Engineering Institute
Bursatec, the technology arm of Groupo Bolsa Mexicana de Valores (BMV, the Mexican Stock Exchange), recently embarked on a project to replace three existing trading engines with one system developed in house. Given the competitiveness of global financial markets and recent interest in Latin American economies, Bursatec needed a reliable and fast new system that could work ceaselessly throughout the day and handle sharp fluctuations in trading volume. To meet these demands, the SEI suggested combining elements of its Architecture Centric Engineering (ACE) method, which requires effective use of software architecture to guide system development, with its Team Software Process (TSP), which teaches software developers the skills they need to make and track plans and produce high-quality products. This post at the SEI blog by Felix Bachmann—the first in a two-part series—provides a case study of how Bursatec used architecture-centric engineering to respond to its challenges.
Posted in Architecture-Centric Engineering, Architecture-Centric Practices, Quality Attribute Analysis
Tagged ADD, architecture evaluation, architecture review, Architecture Tradeoff Analysis Method, ATAM, attribute-driven design, non-functional requirements, SEI, software architecture, software architecture evaluation, software architecture requirements, software architecture review, software design, software development, software engineering, Software Engineering Institute
On Thursday, June 23 from 1:30 to 2:30 Eastern time, Grace Lewis of the SEI will present a free SEI webinar, titled “Service-Oriented Architecture: A Quality Attribute Perspective.”
Service orientation is an approach to software systems development that has become a popular way to implement distributed, loosely coupled systems, because it offers such features as standardization, platform independence, well-defined interfaces, and tool support that enables legacy-system integration. From a quality attribute point of view, the primary drivers for service-orientation adoption are interoperability and modifiability. However, a common misconception is that an architecture that uses a service-oriented approach can achieve these qualities by simply putting together a set of vendor products that provide an infrastructure and then using this infrastructure to expose a set of reusable services to build systems. In reality, there are many architectural decisions that need to be made. An architectural decision that promotes interoperability or modifiability can negatively impact other qualities, such as availability, reliability, security, and performance. This presentation will talk about the effect that service orientation has on system quality attributes.
Posted in Architecture-Centric Engineering, Architecture-Centric Practices, Cloud Computing, Quality Attribute Analysis, Service-Oriented Architecture
Tagged cloud computing, non-functional requirements, SEI, SOA, software architecture, software design, software development, software engineering, Software Engineering Institute, system of systems
I enjoy finding places in the world where concepts I work with daily exist in different forms. In Software Product Lines: Practices and Patterns, one of the sidebars is about the product lines of manufactured goods that I see all around–cars, newspapers, suburban houses, light bulbs, and so on. Recently in this blog I wrote about stylized subway maps and argued that these are architectural representations. (This week I was in Venice, Italy, and saw the same kind of map for its ubiquitous water-based mass transit system, the vaporetti.)
Several years ago I read a wonderful article in the Smithsonian Institute’s Air and Space magazine entitled How the 747 Got Its Hump. Besides answering that question, the article also talked about why, for example, almost all cargo aircraft look alike in a few important ways: Engines in the wings, wings mounted high on the fuselage, a short main landing gear snuggled against the body of the aircraft, and a rear-opening cargo door.
Here are a few examples. All are in service today, although some of the designs date back to the 1950s.
Lockheed C-130
Lockheed C-141
Boeing C-17
Antonov AN-124
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
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
The primary purpose of the architecture for a software-reliant system is to satisfy the driving behavioral and quality attribute requirements. Quality attribute requirements tend to be poorly captured and poorly represented in requirements specifications, which focus on functionality. It is often up to the architect’s own initiative to capture the actual quality attribute requirements for a system under development.
After more than 15 years of writing and discussing the distinction between functional requirements and quality requirements, the definition of functional requirements still eludes me. Quality attribute requirements are well defined – performance has to do with the timing behavior of the system, modifiability has to do with the ability of the system to support changes in its behavior or other qualities after initial deployment, availability has to do with the ability of the system to survive failures, and so forth.
Good morning all,
Welcome to our January 18 Link Roundup. Here are some notable posts from other software engineering blogs that you may have missed this past week:
How Cloud Collaboration Changes the Way Software Developers Work, by Phil Wainewright at The Connected Web. This seven-minute podcast interview with Michael Knighten, director of hosted services at Atlassian, discusses the ways in which cloud computing affects software developers.
Non-Functional Architectural Woes, by Udi Dahan at The Software Simplist. Udi muses on functional and non-functional requirements and how they move from the problem to the solution domain.
Evolving Architectures, Part 1: What’s Software Architecture, by Arnon Rotem-Gal-Oz at Dr. Dobb’s CodeTalk. Arnon spends some time explaining his own thorough definition of software architecture.
Thursday, January 21, 2010
Time: 1:00 PM – 2:00 PM EST
Cost: Free
A system of systems (SoS) can experience costly rework, schedule overruns, and the failure to achieve performance goals–from problems that surface late in the development life cycle or after the SoS is in operation. One prominent reason for these severe integration and operational problems is inconsistency, ambiguity, and omission in addressing quality attributes in SoS architectures (and in their constituent system/software architectures). Examples of quality attributes are performance, availability, reliability, security, safety, and interoperability.
SEI senior researcher Mike Gagliardi shares an SoS architecture definition and evaluation approach that involves stakeholders in augmenting end-to-end mission threads with quality attribute considerations. This approach yields architectural challenges and risks that can be mitigated earlier in the development life cycle, when they are much less expensive to resolve.
The SEI and the U.S. Army Aviation and Missile Research Development and Engineering Center (AMRDEC) recently began a one-year engagement that aims to develop a comprehensive approach to overcome deficiencies with the testing now being done to validate software and system reliability. This comprehensive approach will include the development of a roadmap for the research and application of technologies such as model-based engineering, assurance cases, analytical tools, and industry standards, such as the Architecture Analysis and Design Language (AADL) in the assessment and validation of complex system reliability.
Read more here.
