The SEMAT Charter – A proposal
2009/12/19
This blog entry was originally posted December 11, 2009 on www.semat.org. In order to make it easier for us to comment we now also post it here.
Where are we as a community?
Since this initiative was launched early October this year, we have 31 signatories, more than 600 supporters and 5 corporate signatories agreeing with our Call for Action. We have a web site and a blog. Still the hard work of defining our process and ultimately our “kernel” lies ahead of us.
What do we need to do?
We must agree on the direction for our work for the next 12 months. We propose 12 months as a suitable period as it is long enough to achieve some first steps and short enough to produce visible results. As for a software project, the goal will be larger as we get closer.
The call for action statement is the starting point:
“We support a process to re-found software engineering based on a solid theory, proven principles and best practices that:
- Includes a kernel of widely-agreed elements, extensible for specific uses.
- Addresses both technology and people issues.
- Is supported by industry, academia, researchers and users.
- Supports extension in the face of changing requirements and technology.”
At the launching workshop, in Zürich March 17-18, we will start discussing potential solutions. To get there, we need a clear sense of direction. Starting from the Call for Action, we need to narrow down the solution space with a Vision Statement laying out our expectations for the next twelve months. There should be a first widely-agreed version by 15 February 2009.
The SEMAT launch phase revealed that many of us already have, or feel they have, partial or full solutions to the problem. These should yield position statements. A Call for Position Papers will soon be presented on www.semat.org, and a blog entry will follow. The three of us will work as the program committee, making sure that all facets of the problem space are explored and all reasonable solutions presented.
Working on the vision statement?
In the meantime, let us work iteratively through the blog to create a series of exploratory discussions. These discussions can be harvested and turned into an initial vision statement. To get started, we have already published a blog entry “Establishing a kernel?” Please, start to comment on this. Feel free to suggest new blog entries leading to our goal. Let the Call for Action guide you.
We can envision blog entries to establish the width and breadth of SEMAT and the overall SEMAT vision. Moreover, there may be blog entries about the kernel from different perspectives: developers, computer scientists, researchers and so forth. Specific features of the kernel can be discussed also on the blog.
This will lead to useful materials, which we will share with the community,
Key to the success of this approach will be the comments and discussions
Perhaps not all subjects lend themselves to be explored in this way. A different approach might be needed to answer the question, “what is software engineering?” We want to draw upon the outstanding set of signatories, asking you to publish your thoughts on what software engineering is or isn’t. For example we could start with the following discussions:
Is Software Engineering? Why Software Engineering? Thoughts on Software Engineering by Alistair Cockburn
Thoughts on Software Engineering by Watt Humphreys
Beyond the vision statement
In order to get anywhere in Zurich, we need people to either strictly respond to the vision statement or express refusal of the vision statement. In the latter case, we will have to propose a new vision statement. Moving forward will normally require consensus. In the rare case that consensus turns out to be impossible to achieve, we — Ivar, Bertrand and Richard — will find a way forward.
Every participant at the Zurich meeting has to present a position statement describing a solution or a part of a solution. The meeting is over two days only. We hope that this will lead to selecting one or a few of the position statements as the basis for the future. This is, however, all speculation; at this point we really cannot see beyond getting together in Zurich.
Leading this effort
How much leadership do we need? After all we as a group include some of the best minds in the industry, many with long experience in consensus building. Our approach to leading this effort will be very open. We all want to find a great path forward, not being compromised by the consensus process. We are all intent to ensure that the end result is “widely-agreed” and it “addresses both technology and people issues, is supported by industry, academia, researchers and users.”
Join us! Only a lively discussion will lead to a widely-adopted work product based on the best thinking on the subject.
Ivar Jacobson, Bertrand Meyer and Richard Soley
2009/12/23 at 13:29
[...] This post was mentioned on Twitter by Rolf Götz, Geoff Crane. Geoff Crane said: RT @rolfgoetz: More things #SEMAT http://is.gd/5yGEX [...]
2009/12/30 at 17:36
If a vision statement mentions methodology, techniques, technology, roles, etc, it opens up the statement for much and heated debate. If it is a general statement more from a business perspective than IT perspective, management and executives will be able to relate, it will be less if at all debatable from a software design and development standpoint, and will be timeless. Businesses primary purpose is to make money and be profitable so why not align with that purpose? Consider the following vision statement: We are committed to engineering software that improves the financial efficiency, enhances customer capabilities, and provides absolute integrity for all businesses.
The most important item is the first, business efficiency. This is simply determined by how much user and customer productivity is added divided by software development costs. Now granted the way these numbers are determined is subjective and complex but in theory, after a project is completed, a ratio less than 1 is a loss, a ratio of 1 is break-even, and a ratio greater than 1 improves the financial efficiency of the business. If everything is evaluated in these terms, discussions will focus on what is the technique, when was it used, and how was it financially evaluated providing a structure for debate and evaluation. Then with charts, diagrams, and simulations; an optimal path can be determined that maximizes this ratio for each different type of project.
After 25 years of software development and project management I’m glad to see an effort like this, and as an engineer I welcome a permanent shift from the term Computer Science to Software Engineering.
2010/01/26 at 13:07
A few thoughts:
1. Perhaps we should consider the term solution engineering and not software engineering. The overall solution potentially includes changes to the software, hardware, and more importantly the overall business process surrounding the usage of the system. I think that we hobble ourselves by not considering the full picture.
2. Business efficiency is clearly important, but so are environmental concerns. The green revolution affects IT too. Societal concerns should also be considered too. In short, we have an interesting scoping challenge.
2010/01/26 at 15:06
I like the *solution* engineering consideration.
In its strictest sense “software engineering” would be the engineering of the knowledge of software and not the engineering of the knowledge of the *domain* the software is serving which Solution Engineering better describes. So “software engineering” is both a recursive and a fairly limited term, mostly focusing on language construction. This makes “software engineers” rather like English majors (!) in that they know how to program but not what to program. That people come out of college with this deficiency is one of the major criticisms of the educational process.
I agree that we have a scoping challenge and it will be so very easy to fall into conceptual wordsmithing and “meaning of meaning” discussions. Probably the best way to steer around this is to focus on the final aim: is this initiative going to attempt to be prescriptive or merely descriptive?
Is the output intended to be measurable and enforceable?
Are whatever resulting rules and guidelines supposed to cover all kinds of software or are they limited to (say) IT/business applications?
Do they cover:
+ Cognitive processes (how people understand domains and arrive at solutions to problems),
+ Operational processes (what people do in terms of lifecycle activities),
+ Organizational structures (how businesses and teams are set up to attain certain goals),
+ Work product formats (the typical structure and contents of intermediary executable and non-executable knowledge stores),
+ Work product content (the type, degree, precision, and verifiability of the knowledge stored in these work products).
In Peter Drucker’s “Knowledge Economy”, it is clear that software is the only viable currency of that economy. To some extend we are trying to lay a foundation for how this currency is minted so that it does have definable value.
Interesting indeed.
2010/02/17 at 20:48
Business efficiency is not determined by software development costs alone, but also by software maintenance costs. The least efficient projects are not those that are cancelled, but those that *appear* to succeed, delivering software on time and on budget that has a huge long tail of support costs.
2010/01/20 at 14:58
Crafting a “Vision Statement” can be a frustrating activity and easily turns into a wordsmithing session. I very much appreciate the comment on business efficiency since it gets at one of the key aspects of what the vision *could* be. However, I do disagree with overt inclusion that the purpose is to make money. This is not true for most scientific and research software, and even in IT, many companies and organizations have broken their hearts trying to compute true value and return on investment for software creation.
Even more profoundly, the true purpose of business is not to “make money” unless that business is a bank or a casino (or, I guess, a government), since those are the only enterprises for which “making money” is the purpose. All other businesses have other social reasons for existing. In the US we have seen that many businesses when taking this limited view of software creation come to the conclusion that the most cost effective way to make software is to not make it, but hope that someone else will/can make it. In the age of Peter Drucker’s “Knowledge Economy”, this abdication is an extraordinarily dumb thing to do, since business knowledge these days is pretty much *only* manifest in software. I means that businesses that perform this calculation and outsource their core competencies also withdraw from the search for better ways to operationalize what they do for a living.
Companies that do this often become de facto banks or casinos and lose their reason for existing.
I recommend against taking any strong financial focus in defining a vision.
2010/01/24 at 23:45
potential additional material four you sample initial discussion:
Software Engineering, Not Computer Science – Thoughts on Software Engineering by Steve McConnel
Software Craftmanship, the New Imperative – Thoughts on Software Engineering by Peter Mc Breen
2010/02/12 at 12:25
The current title of the initiative is Software Engineering Method and Theory. The singular use of the word “Method” seems to imply that this is another
RUP or OpenUP effort to produce a single industry standard software development method. Would it not be more accurate to replace “Method” with either “Methods” or “Methodology” (using the “study of” definition of methodology)?
2010/02/16 at 12:11
This is not a problem if we read “Software Engineering Method and Theory” as method and theory in software engineering. I believe this is the idea.
2010/02/22 at 14:48
Where do I find the overarching purpose statement (in 25 words or less ) for this effort? Is it the “Call for Action?”