はじめに
2021年度のSQiP研究会の特別講義で、「パターン・ランゲージ」について教えていただいた。
自分でもパターンを書いてみようと思う。
まずは、自分の論文・発表を入力にパターンを記述してみる。
次に、論文・発表にしていない知見についてもパターンを記述してみる。
また、パターンとプロセスモデルの比較もしてみる。
SQiP研究会の特別講義
原田騎郎，「パタンと品質」，ソフトウェア品質管理研究会 2021年度特別講義 第3回特別講義，2021
https://www.juse.or.jp/sqip/workshop/lecture/index.html#kougi3
補足：学び方について
- 小池利和さんからは、何かを学ぶときに、「手を動かしなさい」と教えていただきました。
- 清水吉男さんからは、何かを学ぶときに、「比較をしなさい」と教えていただきました。
パターン
上記記事で、パターンが以下のように定義されている。
パターンとは、ある「状況」で繰り返し発生する「問題」の「解決方法」をまとめたものに「名前」をつけたものを言います。また、状況を取り巻く様々な力、「フォース」を明らかにするのもパターンの特徴です。フォースは解決方法を制限し、簡単には解決できない問題であることを表します。
パターンを書く
論文・発表を入力に書いたパターン
対象論文
| 論文タイトル | リンク |
|---|---|
| 統合テストにおいて影響範囲に対するテスト漏れを防止する「影響波及パス分析法」の提案 | https://www.juse.jp/sqip/symposium/archive/2017/day1/files/ronbun_C1-1.pdf |
| 欠陥混入メカニズムの知識を活用したDRBFMの提案 | https://www.juse.jp/sqip/symposium/archive/2018/day1/files/B2-1_ronbun.pdf |
| 派生開発におけるテスト漏れを防止するDifference Statement Coverage分析法の提案 | https://www.juse.jp/sqip/symposium/archive/2019/day2/files/A3-1_ronbun.pdf |
| 要求仕様の誤解釈を検出するDomain Word Modelingの提案 | https://www.sea.jp/ss2020/download/SS2020-2.pdf |
| 要求仕様に対する形態素ベースドレビューの提案 | https://www.sea.jp/ss2021/download/22-SS2021.pdf |
パターン
| 名前 | 状況 | 問題 | フォース | 解決策 |
|---|---|---|---|---|
| 影響波及パス分析法 | 派生開発で，変更の影響箇所に潜在する欠陥を検出するために，回帰テストを実施する．回帰テストでは，変更に対する影響範囲を特定したうえで，実施するテスト項目を絞り込まざるを得ない． | 回帰テストで，影響範囲に対するテスト漏れが発生する可能性がある． | 「対象システムの有識者が不在」「影響範囲を特定するためのトレーサビリティマトリクスがない」「網羅的なテストをするためのテスト自動化環境がない」という特徴をもつプロジェクトで効果を出す必要がある． 対決策を実行するために，影響波及パスの抽出と影響波及パスカバレッジの算出をするためのツールが必要となる． |
テスト網羅性を示す影響波及パスカバレッジ，設計で考慮すべき影響量を示す影響波及パス数を技術要素とし，回帰テストと設計にフィードバックをする．影響波及パスは，変更箇所を起点とした関数コールの繋がりを表現する． |
| 欠陥混入メカニズムの知識を活用したDRBFM | 派生開発において，変更漏れに分類される欠陥の流出を防止することは重要な課題であり，ソースコードの変更箇所の特定漏れを防止するため，XDDP，影響波及パス分析法，DRBFMを適用している．しかし，「ベースソフトの設計制約の変化が影響して変更が必要となる箇所」については，変更漏れを完全に防止することはできていない． | DRBFMの結果が人の知識・経験に依存することから，我々のプロジェクトではDRBFMを実施していても欠陥を防止し切ることができなかった． | 解決策の効果を出すためには，以下の3つが揃っていることが前提となる． ・欠陥を理解するために必要となる「経験」 ・設計制約の変化を捉えやすくするために必要となる「明文化された制約」 ・欠陥混入のメカニズムをモデリングするために必要となる「能力」 |
DRBFMにおいてソフトウェアの欠陥混入メカニズムの知識を蓄積・活用する．欠陥混入メカニズムは，ABC構造を参考に，「Aという設計のベースソフトが，Bという制約の変化にさらされると，影響箇所の特定漏れにより，Cという欠陥が起きる」という表現とする．欠陥混入メカニズムは，DRBFMワークシートを入力に，蓄積する方針とする． |
| Difference Statement Coverage分析法 | ソフトウェアの派生開発において，「変更誤り」に分類される欠陥については，変更箇所に対して漏れなくテストを実行することで，欠陥の流出を防止する効果が期待できる．しかし，テスト設計のレビューを実施し，変更仕様に対して漏れなくテストケースが作成されていることを確認しているが，テストケースの漏れは検出し切れていなかった． | ソースコードの変更箇所に関連する仕様が明確に定義されていない場合は，テスト設計のレビューでテストケースの漏れを検出することが難しい． | 解決策により検出したテストケースの漏れに対して，テスト設計・テスト実装・テスト実行をやり直すための工数・期間が必要となることを，計画時に考慮しておく必要がある． | 「ソフトウェアの検算」と「テストデバッグ」という理論を参考に，テストカバレッジを利用する方針とした．ソースコードの差分を抽出し，変更箇所に対してテストカバレッジを計測する． |
| Domain Word Modeling | 要求仕様の誤解釈による手戻りが発生していた．誤解釈は，「抽象的に表現された用語」を「不足している前提知識」で解釈することにより発生していた． | 要求仕様のレビューは実施していても，このような用語の誤解釈を防止しきることはできていなかった． | 解決策の導入障壁を下げるために以下の条件を満たす手法とする． ・実開発で使用されている要求仕様の形式を変更せずに実行できる ・考案手法を未経験の状態からでも，手法の説明を受けただけで実行できる ・フリーソフトウェアで実行できる 解決策の有効性と効率性は，「モデリング実施者とモデルのレビューアがもっている前提知識」と「入力文書の質」に依存する． |
Domain Word Modelは，要求仕様と前提知識を入力として，用語の関連を木構造で表現する．モデリング実施者とモデルのレビューアの間で解釈の相違を検出するために，用語を解釈するための前提知識を，モデルで可視化し，レビューする．モデルの作成とモデルのレビューを通して，「抽象的に表現されている曖昧な用語」と「解釈のための前提知識が不足している用語」を検出する． |
| 形態素ベースドレビュー | 要求仕様の修飾性と類義性により，不具合が引き起こされた事例があった．具体的には，「修飾語」または「同義語」を使用していた文が，不具合を誘発していた． | 要求仕様に対するレビューを実施していても，修飾性（修飾関係が一意に決まらない）と類義性（異なる単語で同じ意味を表現する）の問題を見逃していた． | 解決策の導入コストを下げるために，事前にキーワードリストや辞書を作成しない． 要求仕様を理解している人がレビューをする． |
修飾語・同義語が使用されている文を抽出するために，形態素解析を活用する．形態素解析器で，品詞毎に単語を抽出し，修飾語となり得る品詞である単語を特定しやすくする．また，形態素解析器で，単語一覧を作成し，同義語を抽出するために実施する単語の比較をしやすくする．要求仕様の文ではなく，形態素解析器により抽出された単語をもとにレビューをする． |
論文・発表にしていない知見を入力に書いたパターン
| 名前 | 状況 | 問題 | フォース | 解決策 |
|---|---|---|---|---|
| 発表駆動改善 | プロセス改善はしているつもり。 | プロセス改善はやりっぱなしで、効果を確認ができず、その知見の形式知化・共有もできていない。 | やる気 | 成果が出てから形式知化・共有をすることを考えるのではなく、最初に形式知化・共有をすることをゴールに設定する（最初に発表をする場を決めてしまう）。 以下の手順で改善を進める。 1 発表をする場（シンポジウム等）を決める 2 発表に向けて実開発の中でネタになりそうなことを日々探す 3 ネタを見つけたら発表のために効果確認に必要なデータを集めておく 4 論文・発表資料を作成する 5 論文・発表資料の作成を通して気づいたことをもとに、またプロセスを改善する |
パターンを書いた結果
- 私の論文では、「状況」「問題」「解決策」が、論文内の「はじめに」「おわりに」に書かれていた。
- 私の論文では、「フォース」が、論文内の「はじめに」「おわりに」に書かれていないことがあった。
- 私の論文では、「フォース」が、論文内に一部明確に書かれていないものがあった。
- 明確に書かれていなかった「フォース」は、発表のときによく質問をされていた気がする（申し訳ございません）。
パターンとプロセスモデルを比較する
パターンの構成要素と、CMMI®、Automotive SPICE®のモデル構成要素を比較してみる。
CMMI®とAutomotive SPICE®のモデル構成要素は以下の文献から抽出した。
- 開発のためのCMMI® 1.3 版
https://resources.sei.cmu.edu/asset_files/WhitePaper/2011_019_001_28778.pdf - Automotive SPICE® プロセスアセスメントモデル／プロセス参照モデル バージョン3.1
http://www.automotivespice.com/fileadmin/software-download/Change_log_Automotive_SPICE_PAM_Jap_30_-_31.pdf
比較結果
プロセスモデルの構成要素である「目的」は裏返せば「問題」であると捉える。
このように捉えた場合、パターンの構成要素にある「状況」「フォース」が、プロセスモデルの構成要素にはないことがわかる。
プロセスモデルでは、「状況」「フォース」が明確に示されていない可能性があると思われる。
パターンの構成要素
- 名前
- 状況
- 問題
- フォース
- 解決策
CMMI®のモデル構成要素
- 目的
- 導入説明
- 関連プロセス領域
- 固有ゴール
- 固有プラクティス
- 作業成果物の例
- サブプラクティス
- 固有プラクティス
- 共通ゴール
- 共通プラクティス
- サブプラクティス
- 共通プラクティスの詳細説明
- 共通プラクティス
Automotive SPICE®のモデル構成要素
- プロセス名
- プロセス目的
- プロセス成果
- 基本プラクティス
- アウトプット作業成果物
考察
- 論文の内容を見直すときに一度、パターンの形式で書いてみるとよいかも。
- 論文の「はじめに」「おわりに」に、「状況」「問題」「フォース」「解決策」の概要が示されていると読みやすいかも。
- プロセスモデルを理解するときに、パターンの形式で書いてみるとよいかも。
- 「フォース」に何を書くべきかは、まだ言語化できない（理解しきれていない）。
参考文献
- 小室睦，「「なぜ」を考えるプロセス改善 プロセス改善の根底に横たわる仮説について」，SPI Japan 2018，2018
http://www.jaspic.org/event/2018/SPIJapan/session1B/1B2_ID030.pdf
参考記事・資料
関連記事