July/August 2018 issue of acmqueue The July/August issue of acmqueue is out now
Subscribers and ACM Professional members login here


  Download PDF version of this article PDF

Error 526 Ray ID: 46d6856d19c391fa • 2018-10-21 20:37:16 UTC

Invalid SSL certificate








What happened?

The origin web server does not have a valid SSL certificate.

What can I do?

If you're a visitor of this website:

Please try again in a few minutes.

If you're the owner of this website:

The SSL certificate presented by the server did not pass validation. This could indicate an expired SSL certificate or a certificate that does not include the requested domain name. Please contact your hosting provider to ensure that an up-to-date and valid SSL certificate issued by a Certificate Authority is configured for this domain name on the origin server. Additional troubleshooting information here.


Originally published in Queue vol. 10, no. 10
see this item in the ACM Digital Library



Jez Humble - Continuous Delivery Sounds Great, but Will It Work Here?
It's not magic, it just requires continuous, daily improvement at all levels.

Nicole Forsgren, Mik Kersten - DevOps Metrics
Your biggest mistake might be collecting the wrong data.

Alvaro Videla - Metaphors We Compute By
Code is a story that explains how to solve a particular problem.

Ivar Jacobson, Ian Spence, Pan-Wei Ng - Is There a Single Method for the Internet of Things?
Essence can keep software development for the IoT from becoming unwieldy.


(newest first)

Hugh Ching | Thu, 11 Jun 2015 12:03:11 UTC

Post-science proposes the Requirement of Permanence as a discipline for software. Post-science has satisfied the Requirement of Permanence with the solution to completely automated software (Hugh Ching Completely Automated and Self-generating Software System Pat. No. 5,485,601). Software becomes permanent with self-generation, auto-updating, and auto-documentation. Today, the bulk of the software budget is for updating software manually, for sooner or later all software will have to be updated to new systems.

Pan-Wei Ng | Tue, 12 Feb 2013 06:11:45 UTC

This comment is a response to Kevin Kautz's comment on scalability.

Thanks for your interest in the kernel.

This article is just an introduction to the kernel and we have limited ourselves to explain one possible use of the kernel alphas. There are in fact many other uses, which is explained in our book  The Essence of Software Development: Applying the SEMAT Kernel. This article summarizes basically Part I and II of the book. In Part III of the book, we go beyond just doing an iteration, but instead demonstrate how development progresses through various decision points (which can be described as a set of alpha states) from idea to product. These decision points are part and parcel of an enterprises development lifecycle model.

We have Part IV of the book dedicated to discuss different dimensions of scaling: (a) when going beyond small teams to large teams who have members with different background and experiences (b) an enterprise with different kinds of development, such as in-house, offshore, etc. (c) when a single project is large and involves many teams collaborating with each other, such as a large scale product line organization.

In short, it is possible to (i) describe a development lifecycle using alpha states, and (ii) describe a teams emphasis (as part of a much larger team) in terms of alpha states.

Of course, the kernel does not have everything. It is just a kernel, but it is extensible. Through practices (described using the kernel), you can add more details specific to your organization and development context.

David Allen | Fri, 08 Feb 2013 13:14:55 UTC

@Ben Bovee, I am still new to the SEMAT work, though I've been watching it for some time. Regarding your comment "How well could it realistically both enable educational curriculum development and industry practice?"

Thinking back to my educations, here is how I would like to see it advance the education of software engineering. Before the Kernel, professors might choose an established method or two to teach. A creative instructor might have students compare and contrast them to discern the essence of software engineering. With the Kernel, we now have an explicit, method-agnostic language to describe the essence of software engineering. And we have a well-designed framework to compare and contrast methods.

Since I am in industry, my foremost motivation for studying the SEMAT Kernel is to find language to bridge the gap between me and my colleagues who share the same goals but come from different backgrounds (Scrum vs Lean vs RUP vs Waterfall). I intuitively know that we have more in common than appears on the surface. And I want to help us work better together without requiring one or the other to discard what they know and conform to the others language, though some compromise and adjustment may indeed be necessary.

Ben Bovee | Wed, 06 Feb 2013 13:41:26 UTC

About the SEMAT Kernel--details of which were new to me before reading this article:

1 I like some things: a. Forward-thinking; b. Built around perceived pandemic issues subject to relative whim; c. Open to accepting/fostering new ideas; and d. The cards provide a portable common reference.

2 I am unsure about some things: a. Could some card terms be correlated to others commonly used (e.g., Storming, Forming, Norming, Documented, Institutionalized)?; b. Could the "Selected Next States" indicate a level of Capability Maturity?; c. Are the cards intended to provide all necessary and sufficient criteria?; d. How could it be used by businesses developing and operating in time-boxes?; and e. How well could it realistically both enable educational curriculum development and industry practice?

3 I would like to see some things: a. "Further Reading" on--or at least documented--related to each card; b. Whether--and if so, how--it could be applied to non-SW Dev projects (e.g., EA); and c. Documentation of how the Kernel maps to other SW Dev & Engineering Life Cycle methods.

Paul E. McMahon | Mon, 04 Feb 2013 14:07:09 UTC

This comment is a response to Skip Pletcher's comment. Hi Skip. Sorry for taking so long to respond to your comment, but I just recently became aware of this site. Let me answer your excellent question.

First, yes -- all the Alpha states are positive, but that doesn't mean we don't recognize that on real endeavors we often face, as you say, "conflicting" situations, or situations that cause us to "revert". For example, an endeavor could start out using an agile approach and assess their Way of Working as having reached the Principles Established state. Then some new personnel are added to the project, and the new people know nothing about agile and want to use their traditional waterfall process.

What happens here is that when we assess the state again (and we do need to be reassessing our endeavor's progress and health at regular intervals) we do in fact revert to a previous state. The point is--yes--you can revert back to a previous state, or even revert to the point where you are just trying to get to the first state. In other words, you can reach a state, and then at a later point because the conditions on your endeavor change, you find yourself no longer meeting the checklist criteria for that state. So you don't always move forward in a strict linear fashion through the states.

We have found that many people when they are first exposed to the SEMAT kernel misinterpret the states as requiring a waterfall sequential approach. This is not at all the case. Not only can you revert to a previous state at any point in your project based on the current situation, you may also find that you need to iterate through the states of a given Alpha many times on long, or short cycles, depending on your chosen life cycle and practices. Keep in mind that the SEMAT approach is agnostic to life cycle, practice and method choices.

I hope this response is helpful to you, and we look forward to hearing any further feedbacks or thoughts you might have.

Paul E. McMahon Co-Author: "The Essence of Software Engineering: Applying the SEMAT Kernel"

Kevin Kautz | Mon, 24 Dec 2012 01:20:34 UTC

Solid article and the kernel concepts are strong. On scalability, however, I question the fit to large enterprises where risk-based financial decisions on project portfolios drive project funding. This has always been a weakness of Agile -- not that it conflicts, but simply that it ignores it. Can we as an industry ever learn to expand the Customer layer to include the ability of a stakeholder to procure funding to pursue an opportunity? Requirements and estimates of team and work and system are engaged prior to funding commitment, and beyond these, we also need to quantify the unknowns so that the risk can be expressed in dollars with confidence levels ... before funding happens. Yes, I know this is very waterfall ... but this is reality in all publicly owned enterprises and in many private ones.

Better Yet | Thu, 15 Nov 2012 03:35:01 UTC

Wonderful model, expertly written. The entire article, as great as it is, points up the flaw that software development is presently stymied which is why intellectual property theft in the industry is high. New and better software must throw the rules & reasons out the window - all the rules & reasons expertly written in this article. Need I mention the development of color monitors was by those who had no respect, perhaps knowledge, of rules & reasons.

Skip Pletcher | Fri, 26 Oct 2012 15:54:45 UTC

Alpha states seem to be all positive. What if the actual state of Way of Working is 'Conflicted' or 'Reverting?' In other words, we mix waterfall and agile practictioners but they do not blend well. That doesn't sound like Principles Established because they haven't yet acieved that state -- and may revert to this condition even after In Use doesn't get the results expected.

Consider the Requirements Alpha state described as "Requirements are obtuse and conflicting. Specific goals of the project are in direct conflict with one another while generic goals are not yet coherent." We've all been in projects which experienced such a state, but doesn't seem to match Conceived because the Clear opportunity clause doesn't exist. Further, in an UP Inception phase, it may very well be that just such a state is recognized and the project wisely killed. We had an initial small team, they looked at what was being asked and decided that it lacked enough clarity to implement -- so we never achieved Conceived state.

See what I'm asking? CMMI provides a Capability Level of 0, which is just a placeholder for no real capability. Might there be a similar grounding for Alpha states? Or are those examples considered exceptional states which would violate the defined bounds of software engineering? In other words, under those conditions we really aren't engineering anything because we lack the necessary minimal preconditions to do so.

Leave this field empty

Post a Comment:

© 2018 ACM, Inc. All Rights Reserved.