In search of the Higgs

orWhat's wrong with SEMAT?

Rich Hilliardrichh@mit.edu

work in progresscomments appreciated!

Note to the Reader

This presentation sketches an argument which is to be more fully elaborated (with references) as a full paper

I am circulating it in this preliminary form to encourage feedback which I will take into consideration in completing that paper

Software Engineering and Physics:an analogy

I won't argue for the analogy here -- you'll have to see the full paper for the details

The HiggsPhysicists have been searching for evidence of the Higgs since it was hypothesized (1964)

The Higgs plays two important roles:● as unifier: explaining physical phenomena (electricity,

magnetism and light as the electroweak force)● as evidence: that the Standard Model is valid

In Software Engineering ...What are our standard models?

Is there a Software Engineering "Theory of Everything"?

Software Engineering "theories of everything"?● Software & Systems Process Engineering Metamodel

(SPEM)

● ISO 24744, Software Engineering Metamodel for Development Methodologies (SEMDM)

● ISO/IEC TR 24774, Software and systems engineering -- Lifecycle management -- Guidelines for process description

● Software Engineering Method and Theory (SEMAT)

Software Engineering:"theories of everything"?

● Each offers a theory of what Software Engineering is

● Are the process models our "Standard Models"?

(I hope not)

Why SEMAT?● I focus on SEMAT because it is the most recent, it

should have learned from its predecessors, and it is still under development ...

● My goal is to point out a missing dimension which is not prominent -- actually altogether missing! -- from the current models

About SEMAT● The goal of SEMAT is to

"refound software engineering based on a solid theory, proven principles and best practices" [Vision]

● Following its predecessors (listed above), SEMAT outlines an ontology of software engineering process, method and product

SEMAT is built upon..."a Kernel and a Language for software engineering method specification. They are scalable, extensible, and easy to use, and allow people to describe the essentials of their existing and future methods and practices so that they can be compared, evaluated, tailored, used, adapted, simulated and measured by practitioners as well as taught and researched by academics and researchers." [Essence]

The SEMAT Kernel..."... must include a concrete representation of the acts and artifacts of software development, applicable to a wide range of software projects. It must also provide an extension language for adaptation to specific methods, practices and patterns." [Vision]

"... includes the essential elements that are always prevalent in every software engineering endeavor, such as Requirements, Software System, Team and Work." [Essence]

Is SEMAT an adequate basis for a Software Engineering Theory of Everything?

(I think not)

There are questions that cannot be formulated -- nor answered -- within the SEMAT ontology

All very nice, but ...

(Sample) Questions SEMAT cannot answer

● What Work Items should I look at to assess progress in developing this System?

● What links a Requirement on this System with a Work Item with a Team?

● Does this Team have the right skills to successfully deliver this Work Item?

● Is this Work Item affected (e.g., will it need reworking) by a change to this Requirement?

● What risks might befall this System? Are they being mitigated, managed and solved?

Process models are missing the Why of Software Engineering

If the SEMAT Alphas are the 'fundamental particles' of Software Engineering, what is the 'Higgs field' that holds them together and gives them meaning?

Concerns!"Concerns are what we care about in software." [COSMOS]concern: interest in a system relevant to one or more of its stakeholders ... A concern pertains to any influence on a system in its environment; including developmental, technological, business, operational, organizational, political, economic, legal, regulatory, ecological and social influences [42010]Concerns, as in Dijkstra's phrase, "separation of concerns": ...

Dijkstra's "separation of concerns"Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one is willing to study in depth an aspect of one's subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects. We know that a program must be correct and we can study it from that viewpoint only; we also know that it should be efficient and we can study its efficiency on another day, so to speak. In another mood we may ask ourselves whether, and if so: why, the program is desirable. But nothing is gained--on the contrary!--by tackling these various aspects simultaneously. It is what I sometimes have called ``the separation of concerns'', which, even if not perfectly possible, is yet the only available technique for effective ordering of one's thoughts, that I know of. This is what I mean by ``focussing one's attention upon some aspect'': it does not mean ignoring the other aspects, it is just doing justice to the fact that from this aspect's point of view, the other is irrelevant. It is being one- and multiple-track minded simultaneously. [Dijkstra]

Concerns bind the other elements

Concerns underwrite the reasons for work (processes and tasks): ● e.g., We perform this work item because it yields an

understanding of system deployment

Concerns give work products their meanings: ● e.g., This work product explains how reliability is

managed during system developmentConcerns are the things we are interested in; they bind together processes, artifacts, people, in terms of their relevance

Therefore ...

Concerns must be modeled and managed as first-class entities of any software engineering ontology to be useful to practical method definition and execution

This is completely missing from SEMAT and other process model approaches

Existing work on concernsConcerns are not a new idea...

● Concern spaces ● Concern-oriented software engineering ● Viewpoints● ISO/IEC/IEEE 42010 (originally IEEE 1471:

2000): concerns to select and organize architecture viewpoints

There are other issues with the SEMAT, i.e., with its ontology -- but these are topics for another time(Call me)

Aside

References[42010] ISO/IEC/IEEE 42010:2011, System and software engineering -- Architecture description.[COSMOS] S.M. Sutton Jr. and I. Rouvellou, "Concern Space Modeling in COSMOS", OOPSLA 2001. [Dijkstra] E.W. Dijkstra, On the role of scientific thought. 1974. http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD447.html [Essence] Essence – Kernel and Language for Software Engineering Methods, OMG, ad/2012-08-15 [FSC] "Framing Stakeholders' Concerns", special issue of IEEE Software, Nov/Dec 2010.[Vision] Software Engineering Method and Theory -- A Vision Statement

Sidebar: Concerns in SEMAT"In everything we do we apply the principle of 'separation of concerns''. For instance, we separate what the practitioner wants to work with from what a process engineer needs, in such a way that the practitioner doesn't need to 'see' more than what is of interest to her/him. We also separate practitioners from one another; all developers do not have the same level of interest." [Vision]

Sidebar: Concerns in SEMATSEMAT uses the phrase, "separation of concerns" -- but does not follow through on taking concerns seriously as first-class entities

Rather than allowing first-class concerns, SEMAT fixes three areas of concern:● Customer, Solution and Endeavor

This is too coarse (and static) to be of use in actual projects