(前NTTデータ フェロー システム科学研究所長)山本 修一郎
最近、Use Case図やUMLで知られるJacobsonらが取り組んでいることが、理論に裏打ちされた実践的なソフトウェア開発方式SEMAT(Software Engineering Method and Theory)である[1][2][3][4]。
SEMATについての最初の書籍が2013年1月に出版された[1]。筆者もAMAZONで早速入手して読んでみたところ、小説仕立てで要求を抽出してソフトウェア・システムとして実現して運用するまでの物語を展開しており、具体的にSEMATとはなんであるかが分かりやすく解説されている。本稿では要求工学の立場からSEMATについて説明しよう。
SEMATのプリンシプル
SEMATには、活動可能性、拡張性、実務性という3つのプリンシプルがある。
◆活動可能性(Actionable)
SEMATでは、アルファ(alpha, AspirationLed Progress and Health Attribute)によって、活動すべき目標を指示できる。アルファでは、(1)開発活動の進捗と健全性について、(2)肯定的な成果の達成に着目することにより、(3)個別ではなく全体を検討する必要がある。ソフトウェア開発活動全体の健全な進行状態を示す本質的な要素がアルファである。基本的なアルファとして、SEMATでは、機会、ステークホルダ、要求、ソフトウェア・システム、作業、作業方法、チームを定義している。これらのアルファの内容については後述する。
◆拡張性(Extensible)
SEMATでは、多様な開発に適用できるだけでなく、必要に応じて実践的手法を追加できる。たとえばアルファでは、ソフトウェア開発活動の基本的な状態だけを定義しており、成果物や作業の内容については、具体的な活動を選択できるようになっている。これにより、アジャイル開発や大規模開発に対してSEMATを適用できる。
◆実務性(Practical)
SEMATでは、実務担当者を支援するために、アルファの状態を定義するとともに、各状態にあることを確認するための検査目標(チェックポイント)を一覧提示するアルファ状態カードを用意することにより、実践的で具体的な思考の枠組みを提供している。
従来のソフトウェア工学との比較
上述したSEMATのプリンシプルは、従来のソフトウェア工学の問題を解決するために、新しいソフトウェア開発方式の再構築に向けた取組み姿勢を表現している。SEMATカーネルのプリンシプルが、従来のソフトウェア工学と、どのように異なるかを比較した結果を表1に示した。
表1から分かることは、SEMATが従来のソフトウェア工学には、3つの問題があると認識しており、それを解決するのが3つのプリンシプルであるということである。
つまり、これまでのソフトウェア工学の問題点は、(1)開発文書などの成果物を対象としている、(2)たくさんの類似手法が提案されており、適切な手法を比較選択する基盤がない、(3)プロセスエンジニアや品質エンジニアを支援することはできても、開発の実務担当者を支援していないということである。
表1 SEMATカーネルと従来のソフトウェア工学の比較(クリックで拡大)
SEMATでは、後述する7種類のアルファとその状態と検査目標を定義するだけで、開発プロセスを明示的に定義していない。開発プロセスと工程生産物は、状態間の遷移を実現するために選択されるプラクティスによって具体化されるようになっている。ここで、特定の目的に対して何かを実施するために反復できるアプローチがプラクティスである。プラクティスの組合せがメソッドである。
このように、開発プロジェクトの進捗と健全性を可視化するために、ソフトウェア開発に共通するアルファ状態に着目したゴール指向手法がSEMATである。
主な図形要素
SEMATでは、アルファ、状態、活動空間、活動、作業成果物に対して、表2に示す5種類の図形要素を用いている。
表2 SEMATで用いられる主な記号(クリックで拡大)
◆アルファ
業務を成功させるために、進捗と健全性を監視する必要のある物事をアルファという。したがって、アルファには進捗と健全性を判断するための状態がある。カーネル・アルファには、後述するように、①機会、②ステークホルダ、③要求、④ソフトウェア・システム、⑤作業、⑥作業方法、⑦チームがある。アルファの記号は、文字「α」を表現しているようである。
◆状態
ある条件が成立する状況を状態で表現する。アルファごとに状態が定義されている。後述するアルファカードで、状態名を明示する際に使用する。
◆活動空間
一つ以上の実施すべき作業があることを明示する。具体的な活動によって活動空間を埋める必要がある。
◆活動
一つ以上の作業項目の種類を活動によって定義する。作業をどのように遂行すべきかを活動が指示する。
◆作業成果物
作業によって生産される成果物を定義する。作業成果物によってアルファを記述する。
カーネル・アルファ
カーネル・アルファの7つのアルファは、カスタマ層、ソリューション層、エンデバー層からなる3層に分類されている(表3)。カスタマ層のアルファには、機会とステークホルダがある。ソリューション層のアルファには、要求とソフトウェア・システムがある。エンデバー層のアルファには、作業、作業方法、チームがある。
◆機会
ソフトウェア・システムの開発・変更を適切化する周辺環境の集合が機会である。
続きは本誌でご覧頂けます。→本誌を購入する
ご購入のお申込みは電話(03-3507-0560)でも承っております。
- 60:要求とアーキテクチャ
- 61:要求と保守・運用
- 62:オープンソースソフトウェアと要求
- 63:要求工学のオープンな演習の試み
- 64:Web2.0と要求管理
- 65:ソフト製品開発の要求コミュニケーション
- 66:フィードバック型V字モデル
- 67:日本の要求定義の現状と要求工学への期待
- 68:活動理論と要求
- 69:ビジネスゴールと要求
- 緊急:今、なぜ第三者検証が必要か
- 71:BABOK2.0の知識構成
- 72:比較要求モデル論
- 73:第18回要求工学国際会議
- 74:クラウド時代の要求
- 75:運用要求定義
- 76:非機能要求とアーキテクチャ
- 77:バランス・スコアカードの本質
- 78:ゴール指向で考える競争戦略ストーリー
- 79:要求変化
- 80:物語指向要求記述
- 81:要求テンプレート
- 82:移行要求
- 83:要求抽出コミュニケーション
- 84:要求の構造化
- 85:アーキテクチャ設計のための要求定義
- 86:BABOKとREBOK
- 87:要求文の曖昧さの摘出法
- 88:システムとソフトウェアの保証ケースの動向
- 89:保証ケースのためのリスク分析手法
- 90:サービス保証ケース手法
- 91:保証ケースのレビュ手法
- 92:要求工学手法の再利用
- 93:SysML要求図をGSNと比較する
- 94:保証ケース作成上の落とし穴
- 95:ISO 26262に基づく安全性ケースの適用事例
- 96:大規模複雑なITシステムの要求
- 97:要求の創造
- 98:アーキテクチャと要求
- 99:保証ケース議論分解パターン
- 100:保証ケースの議論分解パターン[応用編]
- 101:要求発展型開発プロセスの事例
- 102:参照モデルに対する保証ケース
- 103:参SEMATの概要
- 104:参SEMATの活用
- 105:SEMATと保証ケース
- 106:Assure 2013の概要
- 107:要求の完全性
- 108:要求に基づくテストの十分性
- 109:システムの安全検証知識体系
- 110:機能要求の分類
- 111:IREB
- 112:IREB要求の抽出・確認・管理
- 113:IREB要求の文書化
- 114:安全要求の分析
- 115:Archimate 2.0のゴール指向要求
- 116:ゴール指向要求モデルの保証手法
- 117:要求テンプレートに基づく要求の作成手法
- 118:ビジネスゴールのテンプレート
- 119:持続可能性要求
- 120:操作性要求
- 121:安全性証跡の追跡性
- 122:要求仕様の保証性
- 123:システミグラムとドメインクラス図
- 124:機能的操作特性
- 125:セキュリティ要求管理
- 126:ソフトウェアプロダクトライン要求
- 127:システミグラムと安全分析
- 128:ITモダナイゼーションとITイノベーションにおける要求合意
- 129:ビジネスモデルに基づく要求
- 130:ビジネスゴール構造化記法
- 131:保証ケース導入上の課題
- 132:要求のまとめ方
- 133:要求整理学
- 134:要求分析手法の適切性
- 135:CROS法の適用例
- 136:保証ケース作成支援ツールの概要