A Framework for Integrating Systems and Software Engineering

1. A Framework for Integrating Systems and Software Engineering ICM WorkshopWashington, DC Art Pyster art.pyster@stevens.edu Richard Turnerrichard.turner@stevens.edu 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: • 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 15288 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 traditionalcategories: 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 • 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