1. A Framework for Integrating Systems and Software Engineering
ICM Workshop Washington, DC
Art Pyster
Richard Turner
July 15, 2008

2. Agenda Rationale: Why integrate systems and software engineering?
The evolution of systems
Assertions
Barriers and missing pieces
Touchpoint: A framework
The concept
Touchpoints
TP Faults
Resolution Strategies
Next steps

3. Rationale - 1 Current zeitgeist: Evolution of Systems
We need to integrate systems and software engineering
Evolution of Systems

4. Rationale 2: Assertions
Interdependent systems are those where:
A "major" portion of the capabilities/value of the system is delivered through software
A "major" portion of system quality attributes "largely" depend on software (safety, security, agility, reliability, availability, resilience,...)
Today almost all high value systems interdependent and the percentage is increasing
In such interdependent systems, very few important decisions do not require equal consideration of software engineering and systems engineering expertise, including those associated with technical, management, personnel and customer concerns.
Most critical decisions are made most effectively by people who have strong software and systems engineering competencies and maturity.
But, what does it mean to integrate SE and SwE?

5. Missing Pieces, challenges
What outcomes do we expect from SE/SwE integration?
Are there key risks that integration mitigates?
How and why do the SwE and SE activities conflict, complicate, or reinforce each other?
What are the business areas where integration occurs?
What is the scope of integration (development, operations,…)?
How much integration is needed?
Is more integration always better?
What changes would improve integration and its effects?
Is integration domain- or application-dependent?
How do you measure integration or it’s outcomes?
Why haven’t IPTs or CMMI solved this problem?

6. Barriers Historical context and vestigial prejudices
SE and SwE cultures are significantly different
SE and SwE have different educational backgrounds
SE and SwE vocabularies are similar but meanings differ
SE and SwE process implementations are usually incompatible (e.g. V versus spiral)
SE and SwE may use the same tools differently (UML)
No language to discuss integration of SE and SwE
No measurement paradigm for integration
An initial step – develop a vocabulary and framework to discuss and measure the degree of “integrated-ness”

7. The OUSD(AT&L) iSSE project
Create a framework that identifies critical aspects or dimensions of systems and software engineering integration
Describe
Possible consequences for being at different points along the dimension
Explore how to move between points - is more integration always better?
Apply to one or two DoD entities to evaluate insight into the state of integration and its impact on program success
Look systematically at DoD and industrial data to refine framework
Recommend specific actions for broader improvement relative to framework across DoD

8. Touchpoint Framework : Issues
Vocabulary. There is no precise way to talk about the integration of systems and software engineering.
Measurement. There is no precise way to talk about how much integration there is between systems and software engineering in a particular situation.
Entanglement. There is no way to simultaneously understand the many ways in which the software and systems engineering disciplines touch.
Value. There is no comprehensive list of benefits that can be achieved by integrating systems and software engineering nor is there an understanding of the associated costs.

9. Touchpoint Framework : Components
Processes. The ordered activities that define the systems and software engineering disciplines
Touchpoints. The two discipline’s processes touch when interactions between their constituent activities affect program risk or value – positively or negatively.
Faults. A touchpoint may exist, but in the process or activity fail to produce its maximum value.
Resolution Strategies. For each fault, there may be one or more resolution strategies, which, when executed well, will eliminate the fault or at least reduce its impact.

10. Touchpoint Framework : Processes
ISO provides “harmonized” systems and software engineering processes
Agreement, Organizational Project-enabling, Project, and Technical processes

11. Touchpoint Framework : Faults
Faults fall into 3 categories
3 kinds of “Clashes”

12. Touchpoint Framework : Example TPs

13. Touchpoint Framework : Resolution Strategies
There is a desire to fix faults, especially those with high impact on risk or value.
For each fault, there may be one or more resolution strategies, which, when executed well, will eliminate the fault or at least reduce its impact.
In some cases, resolution strategies are known and just need to be applied
On the other hand, resolving some faults will require research
Resolution strategies are grouped into four traditional categories: process, people, environment, and technology. Any number of resolution strategies in each category is possible for a fault.

14. Touchpoint Framework RS Samples

15. Touchpoint Framework : Measures
Provides a way to measure how much integration has been achieved and how good that integration is.
The amount of integration is simply the total number of touchpoints in the implementation of the 25 processes – a higher number indicates more integration.
A somewhat more sophisticated approach associates a weight with each touchpoint to reflect its potential impact on program risk or value.
The number of faults determines integration quality.
Faults can also be weighted based on their consequence.
A fault that severely impacts an important touchpoint would be of far greater consequence than a fault that barely impacts a minor touchpoint.

16. Some evaluation approach options
What kind of scale? How to evaluate?
Range of discrete (mostly) measurable points (as with the BAD diagrams)
Set of n yes/no questions, and plot the number of yes answers
Conceptual scale that uses judgment
Worksheet with Likert item questions and scoring algorithm
How to identify transition activities
Set of “canned” approaches (like practices in CMMI)
Option set or menu of possible activities with selection guidance
Guidebook-like text describing options

17. Next steps Begin to populate the framework
Continue to incrementally improve framework
Present it to knowledgeable people for discussion, including
USC CSSE✔
US/UK/AUS SISAIG✔
SSTC✔
INCOSE✔
ICM Workshop - Today
NDIA SE – October
Begin to populate the framework
Use the NDIA Software Advisory Group and other expert panels as Delphi subjects to identify/validate common touchpoints, faults and resolution strategies
Capture touchpoints et al from systems and software engineering processes of several programs identified byAT&L/SSE

18. Questions and Discussion