紹介文 :
仕様というソフトウェアの核となる成果物の品質向上については、様々なアプローチが議論されています。このため、それぞれの特徴や役割分担を明確に踏まえ、問題に応じて選択し、組み合わせ活用することが重要です。本論文は、形式仕様記述手法と要求記述手法に関し、この観点から位置づけの整理を試みています。

紹介文 :
レビュープロセスの質をチェックリスト形式で評価することで得点化する方法、および、レビュー指摘の価値を指摘工程と影響範囲でポイント化し、金額換算する方法を提案しています。従来のレビュー速度でレビューの質を捉えたり、単純に指摘件数をレビューのアウトプットとするよりは、より実感できる形でレビューの質と価値を把握できます。数値の精度は十分ではありませんが、簡便な方法で実践できるのが良いです。

紹介文 :
「測定と分析」の考え方から実例まで網羅されており、「測定と分析」の導入手引きとして有用な情報を提供している。 CMMIモデルをベースとしているが、「測定と分析」を幅広く捉えており、多くの組織に適用可能であり、業務の見える化を推進するツールとして使用可能である。

紹介文 :
上流で得られるメトリクスを用いて、後工程で生ずる問題を予測しようとした研究。 設計レビュー指摘密度が低いと下流の手戻り率が高いと言うことが言えそう。他に、上流のメトリクスとして、要件レビュー指摘密度、要件実現率、要件の複雑度、設計仕様実現率、設計の複雑度を調べてみたが、有為な相関は得られなかった。 現存する上流のメトリクスから下流の振舞いを推定するには、メトリクスの安定度を良くしないと難しい。

紹介文 :
今日、単に機能面の品質が良いというだけでは買ってもらえない。コスト（価格）や「プラスα」の何かが必要。そこでサービス品質を、この「プラスα」のひとつとして捉える。しかしなから、サービス品質は一様ではないため、お客様の要求を掴むためのプロセスの明確化とサービス要求の定量化が必要になる。 本報告書では、サービス品質をお客様の満足度で捉えている。このお客様満足度を掴むプロセスの一つとして「アンケート調査」があるが、これは集計までの時間がかかることと、そこから具体的なアクションを引き出しにくいという欠点がある。そ

紹介文 :
ISO 9126などの品質特性を、実際の現場でどのように使えばいいのかの一方策が提案されています。通常は外部品質特性のみ着目されがちですが、内部品質特性も使用されており、開発する立場が考えねばならないことも組み込まれています。 使用する際は、プロジェクトごとに品質特性の捉え方は異なるので、チェック項目と特性のリンクを再考し、チェックリストの補足も、プロジェクトにあった形にすると、より使いやすいものになります。

紹介文 :
リスク管理から閾値を超えた場合は課題管理にうつり、課題の振りかえりにより、次の開発時に新たなリスクの抽出にしよする。このリスクが閾値を超えた場合は課題管理にうつる。この無限につづく繰り返しを「乙∞（おつむげんだい）モデル」として開発した。課題管理プロセスとリスク管理プロセスを融合した、「乙∞（おつむげんだい）モデル」は、プロセス効果の定量化と合わせて有効性で現場で適用可能であると結論付けられた。

紹介文 :
品質確保の重要なポイントであるレビューをより効果的にするため、レビューによる指摘項目の、指摘分類、原因分類を最適化し、本質的な問題のみを対象とし、真の原因に応じた適切な対応が可能になるよう工夫をしています。レビューによる品質の評価を、単に指摘件数だけで評価するのではなく、指摘内容を踏まえてより正確にし、また、的確に品質向上につながる対応が取れるなど、有効な方法です。

紹介文 :
品質保証部門の目線でなく、開発現場での目線にてデータ活用の”見える化”・”うれしさ”を解り易く紹介している。 更に、現場での”うれしい”メトリクスを多面的に考察し、実践事例を基に最適データ活用を提示している。

紹介文 :
レビュー会議が時間通りに終わらない、効率的なレビュー会議にするためにはどうすれば良いか。 本論文では、レビュー会議での発言内容毎の時間を測定し、どのような発言がどの程度行われているのかを可視化することで、レビュー会議の参加者間で会議の目的に微妙なズレがあることを認識させ、レビュー会議の改善を促す手法を提案している。 時間というのは、その人の置かれた立場や状況の違いによって感じ方が異なる一方、絶対的で普遍的な指標とも言えるため、レビュー会議の現状把握や分析を行う際に大いに活用できそうである。

紹介文 :
「一般的な言語 対 ドメイン特化言語」、「上流での実装詳細の捨象の程度」など、記述方式の特化性はソフトウェア開発における難しい問題です。本論文は、フレームワークを用いた開発における形式仕様記述の活用に関し、この問題について様々な観点からの試行と議論を試みています。

紹介文 :
仕様というソフトウェアの核となる成果物の品質向上については，様々なアプローチが議論されています．このため，それぞれの特徴や役割分担を明確に踏まえ，問題に応じて選択し，組み合わせ活用することが重要です．本論文は，形式仕様記述手法と要求記述手法に関し，以前の位置づけ整理を踏まえ，具体的な手法確立に向けた試行を行っています．

紹介文 :
　システムをリリースした後にくるクレームの「言葉」をどのように改修要件に落とし込むかについての研究です。「ぼやき」のような曖昧な言葉を、システム的にどのように解釈すれば良いのかを考察しています。一人でもチームでも運用できるチェックシート形式の問診票で改修の必要度を探ります。ユーザから直接フィードバックを得られる立場の方に、特にお勧めします。

紹介文 :
1)リスクを低減するプロジェクト計画についての一考察 要求分析工程のデザインレビューの評価結果から、成功/失敗を予測するモデル「プロジェクト失敗予測モデル」を提案しています。 2)『ソフトウェア開発プロセス点検』の実践と考察 点検の実施結果を定量的に可視化する指標「開発プロセス良好率」を提案しています。 3)4アイテム要求モデルによる要求分析 簡単に導入できる要求分析の手法として、4アイテム（現在の状態、望まれる状態、解決されるべき問題、要求）モデルによる分析方法を提案しています。

紹介文 :
1)要求の評価方法の研究 要求の具体的な検証方法として、「貢献度評価による、妥当性及び完全性の評価」を提案しています。 2)形式仕様記述言語による派生開発でのモデル検証 組み込みソフトウェアの派生開発において、スペックアウトした仕様を形式仕様記述言語を用いて整理した事例が紹介されています。 3)プロジェクト管理における統合モデルの提案 特性の異なるプロジェクトに対して統一的な概念で評価およびフィードバックを行うためのプロジェクト管理フレームワークを提案しています。

紹介文 :
仕様というソフトウェアの核となる成果物の品質向上について、「形式手法（形式仕様記述）」と「テスト」といった、視点や参加者が異なるコミュニティーにおいて、閉じた視点で別々に議論されてしまっていることが多くあります。本論文では、それらを一つの系統的な視点から比較、議論することを試みています。

紹介文 :
プロジェクトにおける標準プロセスの定着度を、実態に合う形でより正確に評価するメトリクスを提案しています。具体的には、プロセスが定着していることを、仕組みが機能し、ルールが守られ、継続的な改善が行われていることととらえ、それぞれの観点から評価するメトリクスを用意しています。また、測定を正確に行うための各種チェックリストを用意している点も、この方法の有効なポイントです。

紹介文 :
アジャイル開発手法「スクラム」を用いた開発プロジェクトでは、プロダクトオーナー(PO)から見ると、反復開発するスプリント毎では順調に思えたのが、実は開発状況をうまく把握できていなかったために、品質(Quality) ，コスト(Cost) ，納期(Delivery)の問題が開発プロジェクトの後半に発覚することも少なくありません。 そこで、各スプリントと開発プロジェクト全体の問題を可視化し、POがQCD問題の予兆を察知して対策するきっかけを掴めるような「勘所性」のあるメトリクスを提案しています。プロダクト品質の技術面とプロジェクト管理面から絞り込んだ１７種のメトリクスで、開発プロジェクトのメンバからの有益性、実現可能性の評価についても調査しています。

紹介文 :
メトリクスの組織への導入には、先ず「何のために測定するのか」「何に使うか」が、明確である必要がある。 GQM手法（Goal Question Metrics）は、組織の改善目標と測定データを紐付する道筋を与えてくれるツールであるが、GQM手法の有益性を解り易く紹介している。

紹介文 :
単体テストで見逃す欠陥数に最も相関が高いのが規模であるという、非常に単純かつ強烈なメッセージを投げかけています。データ分析の進め方という意味では非常に参考になる論文です。サイクロマティック数やネスト深さなどいかにも関係ありそうな数値はあまり効いていないことがわかるのもよい点です。ただ惜しむらくは、肝心の規模等すべて相対値なので、読んですぐ使えるタイプの論文ではありません。また対象としているソフトウェア規模も比較的小さく、実験的性格の強い論文であることを念頭に置いて読む必要があるでしょう。