1 / 18

A Framework for Integrating Systems and Software Engineering

A Framework for Integrating Systems and Software Engineering. ICM Workshop Washington, DC Art Pyster art.pyster@stevens.edu Richard Turner richard.turner@stevens.edu July 15, 2008. Agenda. Rationale: Why integrate systems and software engineering? The evolution of systems Assertions

galya
Download Presentation

A Framework for Integrating Systems and Software Engineering

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. 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 • 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 by AT&L/SSE and

  18. Questions and Discussion

More Related