1 / 11

Reconciling Systems, Software, and other Architectures

Reconciling Systems, Software, and other Architectures. Mark W. Maier, Ph.D. Distinguished Engineer The Aerospace Corporation. © 2008 The Aerospace Corporation, . Topics To Consider. Reconciliation of what? Of “Architectures” (treated as decisions)? Of “Architecture Descriptions?”

leighanna
Télécharger la présentation

Reconciling Systems, Software, and other Architectures

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Reconciling Systems, Software, and other Architectures Mark W. Maier, Ph.D. Distinguished Engineer The Aerospace Corporation © 2008 The Aerospace Corporation,

  2. Topics To Consider • Reconciliation of what? • Of “Architectures” (treated as decisions)? • Of “Architecture Descriptions?” • Of programs and processes? • A discussion of the need to “reconcile system and software architectures” may be something of a cover for a variety of problems • A desire for common notations and tools (whether needed or not) • Poor compatibility between basic architectural decisions about the software with basic architectural decisions about the hardware within the system being developed • Poor compatibility between basic architectural decisions about the program with basic architectural decisions about the system being developed • Inefficient ordering of information developed in software-centric systems • We’ll consider the major cases in turn

  3. Architecture and Program Sequence • Take software-centric or intensive as meaning 70-80% of development is spent on software development • Then, architecting of software will/must start early, before systems engineering is complete, and will be very enduring • Needs at system level induced by software architecture should have priority

  4. Top Down vs Bottom Up Architecting • Stakeholders • Stakeholder Concerns • System level use-cases and objectives • Software architecture • Identification of the logical structure of the software • Concurrency and synchronization requirements, induced by software boundary Objectives-driven Function-centric Value-based invariants Many areas likely to gap Typically poor attention to HW/SW drivers Mismatched SE and SW-Architecture order Design-needs-driven Object-centric Design-based invariants

  5. Program and System • Systems engineering classically looks in physically oriented hierarchies • Software is now more typically structured in layers • At least in modern, complex systems • What happens when the WBS is written to follow the systems hierarchy, not the software layers? • Classic example of mismatch of the structure of the program (via the system) with the structure of the software to be developed by the program

  6. Which are the Subsystems? Shared Functions Backbone Platform Unique Interface Layer

  7. The Four Way Tension Organization Who’s doing what? One or several? What are they good/bad at? What is their “strategic identity?” System What are we building? What are the key tech decisions? What are the components? How is it tested? Problem What are we doing? What delivers value? What is the environment? What is success? Program How do we build/operate? Separation of responsibilities

  8. A Little Exercise Question • What aspects of the problem domain lead you to make a decision in favor of incremental development? • What aspects of the problem domain lead you to make a decision to avoid any sort of incremental development? • Given that you want an incremental development architecture for the program… • How does it (should it) change the architecture of the system? What system architectures are “consistent” with incremental development, and which ones are not? • How does it change design decisions in supporting areas (e.g. testing, verification, validation)? • How does it effect the organization that carries out development and the supported missions?

  9. Notations and Methods • Lack of attention to notations and methods may be the problem • Or, too much attention to notations and methods may be the problem • Can’t fix bad decisions by changing the description framework • And…it can also be part of a solution • The “right” notation can directly incorporate the bottom-up concerns of software developers • The right notation composition rules can support explicit layering, and parallel subsystem decomposition • The right descriptions can highlight issues between the system and program

  10. Some Pieces to Use Hard-coupled Push Hard-coupled Pull Soft-coupled Push Soft-coupled Pull Blocking Push Blocking Pull Queued Transfer

  11. Conclusions • Bringing architecture (and architecture description) together among systems and software is important stuff • But…the systems/software divide is only part of the story • Consider from the position of fundamentals • Things (software, systems, programs) have architectures. Those architectures are formed from the basic structural decisions. • Compatibility means (largely) consistent, coherent decisions between and among those levels • Between hardware and software • Between problem and system-solution • Between system, program, and organization • Compatibility of “architecture descriptions,” (models and documents) also is an issue • Good choices in tools and methods can help with compatibility, but isn’t a panacea

More Related