SEMATは2009年11月に「アジャイルマニフェスト」と同じようなマニフェストと共に始まった。
今日、ソフトウェア工学は未熟なプラクティスによって激しく阻害されています。次のような問題が挙げられます。
- 一時の流行が幅をきかせていて、工学の分野というよりファッション業界のようです。
- 広く受け入れられた健全な理論的基礎が欠落しています。
- さまざまな方法論やその亜種が大量にあります。それらの違いは正確に理解されておらず、また故意に誇張されています。
- 実証的で信頼に足る評価（"evaluation"）と検証（"validation"）が欠落しています。
- 業界のプラクティスと学会の研究との間に隔たりがあります。
私たちは、確かな理論、証明された原則、ベストプラクティスに基づき、ソフトウェア工学の建て直しを支援します。
- 広く合意された要素のカーネルを含みます。これは特定の目的のために拡張することもできます。
- 技術的課題と人間的課題の両方に取り組みます。
- 業界、学会、研究者、ユーザによって支えられています。
- 要件や技術の変化を考慮した拡張を支援します。
ここに名前を連ねている人の中にはソフトウェアとアジャイル業界でよく知られているが多くいる。Scott Ambler氏、Barry Boehm氏、Larry Constantine氏、Erich Gamma氏、Tom Gilb氏、Ellen Gottesdiener氏、Sam Guckenheimer氏、Watts Humphrey氏、Capers Jones氏、Ivar Jacobson氏、Philippe Kruchten氏、Robert Martin氏、Stephen Mellor氏、Bertrand Meyer氏、James Odell氏、Ken Schwaber氏、Edward Yourdon氏など。
SEMAT構想声明では、署名者たちが作ろうと合意したカーネルについて記述されている。「カーネルが注力するのは、ソフトウェア工学におけるあらゆる努力にとって本質的な諸要素を識別し、記述することです。それらがカバーしている典型的なものを挙げると、チームワーク、プロジェクトマネジメント、プロセス改善といったものがあります。このカーネルは他の工学の領域から得た概念と統合していくでしょう。変化に順応して行かねばなりません。」
現在5つの分野において活動しているグループがある。
- 定義（"Definitions"） - ソフトウェア工学とそれに関連する考え方を定義する
- 理論（"Theory"） ・ソフトウェア工学を支える理論（できるだけ数学的なもの）を識別する。ｦ
- 普遍性（"Universals"） ・カーネルに統合されるべき、ソフトウェア工学における共通要素を探索する。・
- カーネル言語（"Kernel Language"） ・他の諸要素を表現する言語を定義する。ｨ
- 評価（"Assessment"） ・ソフトウェア工学のプラクティスと理論を評価する方法。・
「Design Patterns Book」の共著者であるRalph Johnson氏が危惧しているのは、学者が「理論」という時には数学を意味しており、それは業界の人間が考えているものと違うのではないかということだ。氏は続けて、ソフトウェア工学とは何かという事すら明らかになっていないという。「これはあらゆるソフトウェア開発を意味しているのでしょうか、それともソフトウェア工学の学位をもった人々が実践するソフトウェア開発だけを指すのでしょうか？あるいはソフトウェア工学という表題がついているものでしょうか？典型的な銀行や保険会社はどうだろうか。ソフトウェア開発を行うグループのマネージャがソフトウェア開発の背景をほとんど持たず、平均的な開発者がコンピュータサイエンスの学位すら持っていない状況では、ソフトウェア工学における正式な訓練はそれほどされないでしょう。」氏はさらに続けて、ソフトウェア業界における真の問題は、30年以上も昔から知られている事柄をほとんどのグループが無視している事だと指摘する。
Jorge Aranda氏は、ソフトウェア業界に多くの一時的流行があることは認めている。しかし、それらの「一時的流行」の多く（例えば、オブジェクト指向開発や、XPなど）はかつて「一時的流行」と見なされたが、今や主流の一部として受け入れられていると指摘する。ソフトウェア工学に対してこのような保守的なアプローチを採用することについて氏が危惧しているのは、将来のイノベーションが押さえ込まれてしまうのではないかいうことだ。
わずか１年前に、Tom DeMarco氏はソフトウェア工学が死を迎えたと論じていた。氏はメトリクスに関して自身がかつて行った仕事が、はたして今でも妥当なのか疑問視している。
ソフトウェアプロジェクトをコントロールすること、つまり、マネジメント、計測、見積は多くの新進のソフトウェアエンジニアが作業を定量化し、プロジェクトを計画をするのに使われました。感傷的にですが、疑問に思う事があります。当時このアドバイスは正しかったのでしょうか？いまでも有効なのでしょうか？こういったメトリクスがソフトウェア開発の努力を成功させるのに必須なのでしょうか？私の答えはどれについてもNOです。」
氏はさらにこう続ける。「一貫性と予測可能性は相変わらず望ましいものではありますが、これらが最も重要だったことはありません。」
Geert Bellekens氏はSEMATを擁護して、次のように言う。
私たちは多くの異なる方法論を見てきたと言えると思います。しかし、一皮むけばどれも非常に似通っていることが分かっているのではないでしょうか？
これらの異なる方法論を並べて、少し遠くから眺めてみれば、似ている所を見つける事ができるし、どこが違うのかもはっきり分かると思います。
それこそがSEMAT構想が行おうとしていることなのです。つまり、別々の方法論が持つ共通の要素を見いだし、方法にとらわれない中立的なやり方で言い換えるということです。
Scott Ambler氏もSEMATの支持者に名を連ねており、業界には今現在あるものよりも優れたものが必要だと言う。優れた人の多くが参加しており、なにか価値のあるものが達成されると期待している。
あなたはSEMATについてどう考えるだろうか？将来のイノベーションを破壊するものだろうか？何か価値のあるものを作り出せるだろうか？あるいは、ソフトウェア工学のプラクティスにおいて何が欠けているのかすら知らない、本当に問題のあるチームなのだろうか？