University of Southern California
Center for Systems and Software Engineering
Integrating Systems & Software
Architecting Workshop
• Participants
• Problem space examples
• Followed JAL approach: two full pages of (20)
issues
– All Issues, refactored as appropriate
– Issues with an incomplete list of proposed solutions
• Bottom line summary of Issues
University of Southern California
Center for Systems and Software Engineering
•
•
•
•
•
•
•
•
•
•
•
•
•
Architecture Workshop Participants
Art Pyster, Stevens Inst. Tech (WDC)
David Klappholz, Stevens Inst. Tech (NJ)
Bruce Amato, OSD
J. D. Baker, BAE Systems
Pongtip Aroonvatanaporn, USC CSSE
Ramin Moazini, Sun Microsystems & USC CSSE
Itti Charoenthongtrakul, USC CSSE
Clyde Chittister, SEI
Ed Colbert, USC CSSE & Absolute Software
Jinbo Chen, NGC
A Winsor Brown, USC CSSE & ISTI
Charles Driessnack, SAIC
Barry Boehm, USC CSSE
University of Southern California
Center for Systems and Software Engineering
University of Southern California
Center for Systems and Software Engineering
Problem Space by Examples
From ARR
•
•
•
•
WBS & Organizations
Fractionated, incompatible sensor data management
Domain-Specific Reference Architectures
Effect of Software Underrepresentation
University of Southern California
Center for Systems and Software Engineering
Effect of Software Underrepresentation
•Software risks discovered too late
•Slow, buggy change management
•Recent large project reorganization
Original (WBS-based)
New
PM
PM
C4ISR
Sys Engr
Platforms
C4ISR
Software
Sys Engr
SW
Sensors
Networks
WMI
SW
SW
SW
Sensors
SW
03/19/2008
©USC-CSSE
Networks
SW
5
University of Southern California
Center for Systems and Software Engineering
Examples of Architecture
Mismatches
• Fractionated, incompatible sensor data management
…
…
Sensor 1
SDMS1
…
Sensor 2
Sensor 3
Sensor n
SDMS2
SDMS3
SDMSn
• “Touch Football” interface definition earned value
– Full earned value taken for defining interface dataflow
– No earned value left for defining interface dynamics
• Joining/leaving network, publish-subscribe, interrupt handling,
security protocols, exception handling, mode transitions
– Result: all green EVMS turns red in integration
03/19/2008
©USC-CSSE
6
University of Southern California
Center for Systems and Software Engineering
Domain-Specific Reference Architectures
•
•
…
Examples: ADAGE avionics reference architecture
June 27, 2016
7
University of Southern California
Center for Systems and Software Engineering
Workshop Issues, Goals, and Approach
– Discuss architecting (system/SW; NDI legacy; concurrent
requirements/architecture engineering)
– Identify, prioritize key architecting issues
– Discuss solution approaches for top-priority issues
– Evaluate degree of payoff, difficulty of solution
approaches on 0-10 scale
– Prepare summary briefing
© USC CSSE 2008
8
University of Southern California
Center for Systems and Software Engineering
The system
is the fundamental
and unifying
Whatarchitecture
is a software
architecture?
system structure defined in terms of system elements,
interfaces, processes, constraints, and behaviors.
- INCOSE
The software architecture of a program or computing system
is the structure or structures of the system, which comprise
software elements, the externally visible properties of those
elements, and the relationships among them.
- Len Bass, Paul Clements, Rick Kazman, SEI, 2003
An architecture is the fundamental organization of a system
embodied in its components, their relationships to each other
and to the environment, and the principles guiding its design
and evolution
- IEEE 1471-2000, Recommended Practice for Architectural
Description of Software-Intensive Systems
9
University of Southern California
Center for Systems and Software Engineering
System/Software Architecture Mismatches
- Maier, 2006
• System Hierarchy
• Software Hierarchy
– Part-of relationships; no
shared parts
– Uses relationships; layered
multi-access
– Function-centric; single
data dictionary
– Data-centric; class-object
data relations
– Interface dataflows
– Interface protocols;
concurrency challenges
– Dynamic functionalphysical migration
– Static functional-physical
allocation
03/19/2008
©USC-CSSE
10
University of Southern California
Center for Systems and Software Engineering
Top level issues (1/3)
1.
2.
3.
(11) Inconsistent ways of viewing the entities – system architect
looks at things thru functional allocation mentality – sw architect
looks at things as reusable objects – a different perspective –
different notations – makes it harder to move work from system
architects to software architects. The sw and hw engineers use
different notations/vocabularies – the way we discuss the logic of
how we construct hw and sw are different. Hw and sw engineers
have trouble communicating – use the same word to mean
different things. Some se won’t use sw terms such as “class”
(point of contention – some believe SEs shouldn’t deal with
classes). We need ways to represent ideas about systems and their
solutions for analysis and communication
(11) Too many people think of swe architecting and se architecting
as separate disciplines
(8) How to decide in the first place what to have the hw do and
what to have the sw do
03/19/2008
©USC-CSSE
11
University of Southern California
Center for Systems and Software Engineering
Top level issues (2/3)
4.
5.
6.
7.
(6) Definition of terms from a domain perspective or discipline
perspective - even system engineers use the same term differently
and have trouble communicating among themselves – likewise for
software engineers
(6) Chief engineers who come up the career ladder from hw and
other traditional engineering disciplines don’t know or respect sw
engineering
(6) Sw engineers are often not in the discussions from the
beginning when requirements and architecture, etc. are
established
(6) Sw architects and SE architects have different experiences –
they grow up in different worlds – and so they see the world
differently
03/19/2008
©USC-CSSE
12
University of Southern California
Center for Systems and Software Engineering
Top level issues (3/3)
8.
9.
10.
11.
12.
13.
14.
(4) Models are incompatible between SWE and SE
(3) SEs and SWEs focus on different levels of abstraction – what
and how
(3) Change will happen to both system and sw architecture – how
do we efficiently make sure the two architectures remain
consistent
(2) Many SW Engineers aren’t “real” engineers
(1) SEs spend more time on paper than SWEs do – SWEs use more
real models
(0) The way we talk about funding and testing is different between
hw and sw
(0) With sw systems on generic ubiquitous hw, hardware/software
integration is not an issue
03/19/2008
©USC-CSSE
13
University of Southern California
Center for Systems and Software Engineering
Issue 1
Inconsistent ways of viewing the entities – system architect
looks at things thru functional allocation mentality – sw
architect looks at things as reusable objects – a different
perspective – different notations – makes it harder to move
work from system architects to software architects
1. We need compatible representations and terminology and models that cover both sw and
se concepts and solutions that can be used for both analysis and communication
2. We need training on terminology, representations and models for both SEs and SWEs
3. We need to validate that the uniform representations, models, and terminology really work
4. There needs to be active on the job mentoring of SWEs on systems engineering – the goal
is for a SWE to become a SE
5. SEs should know something about SWE – but don’t expect them to become SWEs – they
need mentoring
6. Career path should encourage movement between SE and SWE
7. Controversial: SE and SWE should be combined into a single discipline
8. SE and SWEs should have an understanding of the other discipline
9. Establish an industry/government team to create uniform representations, etc. – include
vendors – go beyond sysml
10.Rosetta stone between systems and software terminology
03/19/2008
©USC-CSSE
14
University of Southern California
Center for Systems and Software Engineering
Issue 2
Too many people think of sw architecting and
system architecting as separate (stovepiped)
disciplines
1.Teach everyone to do both SWE and SE architecting
2.Achieving the last chart mitigates this issue as well.
03/19/2008
©USC-CSSE
15
University of Southern California
Center for Systems and Software Engineering
Issue 3
How to decide in the first place what to have
the hw do and what to have the sw do
1. Develop patterns and antipatterns to guide hw sw allocation.
2. Develop domain specific architectures
3. Integrating teams of SWEs and SEs
4. Propagating what is easy and what is hard for HW and SW to do
5. Having the common notations, etc. help achieve this
03/19/2008
©USC-CSSE
16
University of Southern California
Center for Systems and Software Engineering
Issue 4
Definition of terms from a domain perspective or
discipline perspective - even system engineers use
the same term differently and have trouble
communicating among themselves – likewise for
software engineers
1. Training and mentoring the organization what the organization wants
for systems engineering and software engineering
2. Get an industry/government team that is multi-discipline and multidomain to identify and define terminology and taxonomies
3. Create domain architectures, domain models, reusable components,
etc. that span software and systems engineering
4. Propagate through industry associations
5. Create “relatively” open architectures
03/19/2008
©USC-CSSE
17
University of Southern California
Center for Systems and Software Engineering
Issue 5
Chief engineers who come up the career ladder
from hw and other traditional engineering
disciplines don’t know or respect sw engineering
1. Educate the chief engineers on software engineering
2. Make knowing software engineering a condition of becoming a chief
engineer
3. If we “unify” the two subjects, then the problem goes away
4. Chief engineers should get a masters degree in software engineering
03/19/2008
©USC-CSSE
18
University of Southern California
Center for Systems and Software Engineering
Issue 6
Sw engineers are often not in the discussions from
the beginning when requirements and architecture,
etc. are established
1. An organizational policy solution: no early stage system architecting
activity be allowed to proceed without software architects being
involved
2. Software architect should sign off on the system architecture
03/19/2008
©USC-CSSE
19
University of Southern California
Center for Systems and Software Engineering
Issue 7
Sw architects and system architects have different
experiences – they grow up in different worlds –
and so they see the world differently
1. Encourage career moves that cross-train software and system
architects
2. Encourage educational approaches that cross-train software and
system architects
03/19/2008
©USC-CSSE
20
University of Southern California
Center for Systems and Software Engineering
Bottom Line Summary
Issues
1. Systems architecting and software architecting have grown up as
separate disciplines and cultures, whereas to produce high
quality products, they need to be unified either partially or
completely.
2. Because of the separation, engineers on each side tend to be
“ignorant”, “suspicious”, “disrespectful” of the other side. Most
early career systems architects are from systems engineering
and may not bring in software architects early enough with the
result that their projects often get in trouble.
Solutions
1. Workshop specifically focusing on issue of integrating system
and software architecting
03/19/2008
©USC-CSSE
21