In search of the Higgs or What's wrong with SEMAT?
work in progresscomments appreciated! In search of the Higgs orWhats wrong with SEMAT? Rich Hilliard firstname.lastname@example.org
Note to the ReaderThis presentation sketches an argument whichis to be more fully elaborated (with references)as a full paperI am circulating it in this preliminary form toencourage feedback which I will take intoconsideration in completing that paper
Software Engineering and Physics:an analogyI wont argue for the analogy here -- youll haveto see the full paper for the details
The HiggsPhysicists have been searching for evidence of the Higgssince 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 ofEverything"?
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 methodspecification. They are scalable, extensible, and easy to use,and allow people to describe the essentials of their existingand future methods and practices so that they can becompared, evaluated, tailored, used, adapted, simulatedand measured by practitioners as well as taught andresearched by academics and researchers." [Essence]
The SEMAT Kernel..."... must include a concrete representation of the acts andartifacts of software development, applicable to a widerange of software projects. It must also provide anextension language for adaptation to specific methods,practices and patterns." [Vision]"... includes the essential elements that are always prevalentin every software engineering endeavor, such asRequirements, Software System, Team and Work."[Essence]
All very nice, but ...Is SEMAT an adequate basis for a SoftwareEngineering Theory of Everything?(I think not)There are questions that cannot be formulated-- nor answered -- within the SEMAT ontology
(Sample) Questions SEMAT cannotanswer● 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 ofSoftware EngineeringIf the SEMAT Alphas are the fundamentalparticles of Software Engineering, what is theHiggs field that holds them together and givesthem meaning?
Concerns!"Concerns are what we care about in software."[COSMOS]concern: interest in a system relevant to one or more of itsstakeholders ... A concern pertains to any influence on asystem in its environment; including developmental,technological, business, operational, organizational,political, economic, legal, regulatory, ecological and socialinfluences Concerns, as in Dijkstras phrase, "separation ofconcerns": ...
Dijkstras "separation ofconcerns"Let me try to explain to you, what to my taste is characteristic for all intelligentthinking. It is, that one is willing to study in depth an aspect of ones subjectmatter in isolation for the sake of its own consistency, all the time knowing thatone is occupying oneself only with one of the aspects. We know that a programmust be correct and we can study it from that viewpoint only; we also know thatit 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 isdesirable. But nothing is gained--on the contrary!--by tackling these variousaspects simultaneously. It is what I sometimes have called ``the separationof concerns, which, even if not perfectly possible, is yet the only availabletechnique for effective ordering of ones thoughts, that I know of. This is what Imean by ``focussing ones attention upon some aspect: it does not meanignoring the other aspects, it is just doing justice to the fact that from thisaspects point of view, the other is irrelevant. It is being one- and multiple-trackminded simultaneously. [Dijkstra]
Concerns bind the other elementsConcerns underwrite the reasons for work (processes andtasks):● e.g., We perform this work item because it yields an understanding of system deploymentConcerns 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 bindtogether processes, artifacts, people, in terms of theirrelevance
Therefore ...Concerns must be modeled and managed asfirst-class entities of any software engineeringontology to be useful to practical methoddefinition and executionThis is completely missing from SEMAT andother 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
AsideThere are other issues with the SEMAT,i.e., with its ontology -- but these aretopics for another time(Call me)
References ISO/IEC/IEEE 42010:2011, System and software engineering-- Architecture description.[COSMOS] S.M. Sutton Jr. and I. Rouvellou, "Concern Space Modelingin 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 EngineeringMethods, OMG, ad/2012-08-15[FSC] "Framing Stakeholders Concerns", special issue of IEEESoftware, Nov/Dec 2010.[Vision] Software Engineering Method and Theory -- A VisionStatement
Sidebar: Concerns in SEMAT"In everything we do we apply the principle of separationof concerns. For instance, we separate what thepractitioner wants to work with from what a processengineer needs, in such a way that the practitioner doesntneed to see more than what is of interest to her/him. Wealso separate practitioners from one another; all developersdo not have the same level of interest." [Vision]
Sidebar: Concerns in SEMATSEMAT uses the phrase, "separation of concerns" -- butdoes not follow through on taking concerns seriously asfirst-class entitiesRather than allowing first-class concerns, SEMAT fixesthree areas of concern:● Customer, Solution and EndeavorThis is too coarse (and static) to be of use in actual projects