work in progress
comments appreciated!
In search of the Higgs
or
What's wrong with SEMAT?
Rich Hilliard
richh@mit.edu

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 Higgs
Physicists 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]

All very nice, but ...
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

(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 development
Concerns 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 concerns
Concerns 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

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

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 SEMAT
SEMAT 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