SEMAT: Software Engineering Method and Theory
Interesting initiative to revitalize the software engineering discipline. SEMAT (Software Engineering Method and Theory), launched in October’09 by Ivar Jacobson, Bertrand Meyer and Richard Soley, is trying to recognize the fundamental problems and to develop a sound and general theory for software engineering.
They’ve started with a “Call for Action”:
Software engineering is gravely hampered today by immature practices. Specific problems include:
- The prevalence of fads more typical of fashion industry than of an engineering discipline.
- The lack of a sound, widely accepted theoretical basis.
- The huge number of methods and method variants, with differences little understood and artificially magnified.
- The lack of credible experimental evaluation and validation.
- The split between industry practice and academic research.
We support a process to refound software engineering based on a solid theory, proven principles and best practices that:
- Include a kernel of widely-agreed elements, extensible for specific uses
- Addresses both technology and people issues
- Are supported by industry, academia, researchers and users
- Support extension in the face of changing requirements and technology
and the vision statement (PDF), specifying what the community want to achieve in the next twelve months.
Despite agreeing with the above statements and the impressive expert lists who had signed the call for action, I’m quite sceptical about the results. Starting with the discussion whether software development is an engineering discipline or not, to the danger that this initiative will become just another fad. Anyway, interesting enough to keep an eye on it.






2 Comments to “SEMAT: Software Engineering Method and Theory”
Trackbacks/Pingbacks:
February 18th, 2010 at 8:51 am
[...] More here: SEMAT: Software Engineering Method and Theory » SDLC Blog [...]
Comments:
August 7th, 2011 at 1:44 pm
I am a bit disappointed though that SEMAT does not make explicit the overweight representation of “Object Orientation” in our industry. This is because OO does not let you “code” your solution with semantics aligned with the class of solution you are building
Leave a reply or a trackback from your own site
Please be respectful in your comments. Do not use fake names or email address, otherwise your comments will be moderated.