紹介文 :
ISO9001（2000年版）の認証を取得してる企業がCMMを参考にしてさらに改善をしていくためのガイド
ISO9001未取得の企業の場合はIOS9001/CMMの要求から自社の状況で施策のベースを検討するのにも有効である。

紹介文 :
自社内での改善を進めていくと、開発現場での最終的な改善の目標は、いかに顧客の要求を早い段階で適切に引出して共有できるか、即ち“要求仕様の早期明確化”となる。然しながら、プロジェクトが進み仕様が詳細化されるに連れて、仕様齟齬が発生するケースが数多くみられる。アジャイル手法による反復開発の導入は解決策の一つだが、ウォーターフォール開発で経験を積んできたプロジェクトチーム全体がすぐに導入するのは難しい。そこで開発中に、仕様齟齬が大きくなり始めた開発対象機能の発生を把握して抽出し、そのような機能に限定して、テストシナリオの先行作成、プロトタイプ開発や先行開発など、部分的な反復開発を導入して対処する手段を提案している。
このため本研究では、仕様齟齬の予兆を、顧客と開発チームの特徴に関する「開発の特性」と仕様変更に関する「メトリクス」をモニタリングして察知し、「対処パターンと判断基準」を活用してプロジェクト進行中に部分的に開発プロセスを変更させていく、仕様齟齬の早期解決手段を提案し体系化した。
顧客との仕様整合の完成度は、その後のプロジェクト進捗に大きな影響を与えるが、本テーマは、“要求仕様の早期明確化”を支援する有用な一方策を提供する。

紹介文 :
アジャイル開発の品質保証における製品品質を評価プロセスの改善提案である。開発途中にプロセスゲートという評価マイルストンをおいて品質をみえる化し、それを積み上げていくことで、製品品質の品質保証のための評価法を提案している。

紹介文 :
要求獲得におけるゴール指向要求分析の活用は有効であるものの分析に時間がかかってしまうことや個人の知識や経験に依存してしまうような課題があり、その解決のため、誰でも簡単に活用できる手法として「ゴール指向Lite」を考案した、という内容の論文です。
従来手法の実用化を目指し、属人性排除の為の適度なガイドや効果を損なわない適度なシンプル化が秀逸であり、論文の構成や文章も大変分かり易く、定量的な分析や効果の確認が行われており大変面白い内容です。

紹介文 :
レビューの品質を第三者が評価して必要に応じて対策を促すことを目的とした「レビュー品質の可視化手法」および新しい品質指標「予測重大欠陥レビュー検出率」を提案しています。
第三者が客観的かつ容易に、そして各プロジェクトの特性を踏まえてレビュー品質を評価出来るように工夫した研究です。

紹介文 :
ソフトウェアの設計レビューで指摘できた不具合の発生原因を集め、うまく傾向を分類・分析し、原因の傾向に合わせて適切な対策を実施できているでしょうか？ 実際には傾向分析の入力である、分類した原因区分に誤りが割と多く、傾向分析の結果が不正確で、適切な対策になっていないことが起こりがちです。このため、下流工程のテストでも設計時と類似した原因による不具合が残っていることも少なくありません。
そこで、この論文では、品質管理責任者が原因区分の誤りの程度を判断して傾向分析の“確からしさ”を判断でき、そしてレビュー指摘を受けたレビューイも原因区分の誤りを是正できるような、設計レビューでの不具合の原因区分を明確にする仕組みを研究し、「ARCメソッド(Ascertain the Roots Cause method)」手法を提案しています。

紹介文 :
派生開発では機能の変更が中心であり、変更後のテストでも機能のデグレードに目が行きがちで、操作性や使い勝手が変化していることに気づくことは少なく、リリース後に「使いづらくなった」といったクレームが入ることがある。
また、操作に関連した変更の場合も、求められている操作性については確認するが、まったく意識していないところで影響がでることがある。
変更時に参照する機能仕様書や操作仕様書には、ユーザビリティについて詳しく書かれていないが、テストケースには、いろいろなケースが扱われている。
そこで、変更で影響を受けやすいユーザビリティの観点と関連するテストケースを組み合わせて「振る舞いbefore/afterシート」を作ることで、変更に伴うユーザビリティの影響に気づく方法を提供している。
この方法は、普段からテストケースを充実させておくことで対応しやすくなる。

紹介文 :
設計を開始する前に要求の漏れを検知し手戻りを抑制することを目的とした「設計着手前レビュー」を提案しています。
「着手前要求確認フレームワーク」と「区分・パラメータ」シートを考案し、
5W1Hの観点で要求を整理し抜け漏れを検知しやすくするための工夫をしています。

紹介文 :
モチベーションやモラールを扱った著書や研究は多い。この問題は、古くは、ホーソンの実験から始まると考える人も多いだろうが、人類の誕生以来ずっとあるのでは無いだろうか。
　本論文を書き終わった時、研究員の全員が異口同音に「自分はプロジェクトリーダだと思っていたが、この１年研究していかに未熟かを実感した」と言っている。本論文には、現代のプロジェクリーダが見えていない世界が描かれている。
本論文は、そのエッセンスが書かれているので、1年かけた研究者と同じ実感はもてないかもしれないが、プロジェクト管理の世界の広さをかいま見ることが出来るだろう。

紹介文 :
レビュー指摘の伝達において、指摘の意図や期待を作成者に上手く伝えることを目的として、「レビューコミュニケーションスタイル手法」を提案しています。
人と人とのコミュニケーションにおいて「人の好みや性格」といった重要とされつつも取り扱うことが難しかった領域に踏み込み、具体的に理論化・手法化してレビューで活用できるように工夫しています。

紹介文 :
ソフトウェアテストの現場ではコスト制約と納期に迫られるなか、良さそうと分かっていながらテスト分析・設計を行うことができない現状がある。そこで、本研究では、そのような短納期でかつ小規模な開発プロジェクトに対して、テスト分析・設計の有効性の検証を行った。
その結果、小規模・短納期プロジェクトのテストにおいても、テスト分析・設計を行う効果を確信することができている。
これは、当然の結果ではあるが、多くの組織で未だテスト分析・設計の導入をためらっている現状において、背中を後押しする有用な論文である。

紹介文 :
本論文では，多くのソフトウェア開発現場で作成・運用されている「チェックリ
スト(チェックシート)」の改善を目指した，「Smile - Process for Checklist Design (S-PCD)」法を提案している。
　チェックリストが，チェックを実施する使用者にとっては分かりにくく，チェッ
ク作業の効率が良くないものであることが多い。チェックする目的や内容が曖昧で
あったり，項目数が必要以上に多いためである。こうした原因がチェックリストを
作成する手法と体系化にあると分析し，チェックリストを改善するために，チェッ
クリストの要件定義・設計プロセスをS-PCD法として定義し提案している。
　S-PCD法により、使用者がチェック作業を効率良く行え，ソフトウェア品質向上
に効果があることを実感し，「Smile」を浮かべて作業できるようになり，開発現
場のモチベーションアップに貢献することが期待される。

紹介文 :
本論文では、派生開発において高リスクな不具合を早期に検出しやすくするため、従来のリスクベースドテストよりも軽量なテスト手法を提案している。
具体的には、新旧ソフトウェア間における機能群単位でのテストケース数の変化割合および不具合の検出数からテスト実施の優先度を付ける手法（LightTest-Prioritization Method，LTP-Method）である。これらの情報はプロジェクト情報として揃う情報であるため、テスト実施のために新規で揃える必要がない。これらの情報を説明変数として重回帰分析を行い、高リスク不具合の潜在期待値を機能群ごとに導き出すことで、テスト実施の優先度をつける。
本手法は従来のリスクベースドテストよりも導入しやすくなるため、高リスクな不具合を早期に検出できることが見込まれる。

紹介文 :
開発チームがアジャイル開発のフレームワークを取り入れようとしたとき、従来、QAを行っていたチームはそれにどのように対応していけばよいだろうか。従来のやり方、考え方では、現場レベルでうまくかみ合わないことが多い。本論文は、現場レベルでどのようにやり方、考え方を変えていけばよいか、その対応のガイドラインを提案している。

紹介文 :
リモートワーク環境下での開発における品質／生産性向上を目的として、「リモート開発におけるレビュー改善方法」を提案しています。
「リモート開発におけるレビュー改善の手順」がわかりやすく、具体的に示されており、「レビュー成功要因関連図」や「レビュー改善Tips」も具体的で実践的な内容が紹介されています。

紹介文 :
本論文では、ソフトウェア開発において，プロジェクトマネージャ(PM)が様々な
進捗会議用の報告資料準備に多大な時間がかかっている問題を解決するために，
CSMA(Connect Similar Materials Automatically)法を提案している。
　特筆すべき点は，現在も進捗報告で多くの人が利用しているExcelツールを活用
して，進捗報告資料準備を効率化するところにある。このため特別なPC環境を用意
することなくCSMA法を導入して利用できる。
　初期設定しておくことで，PMが行っている進捗報告資料準備作業(複数の進捗報
告資料のマージ，データの修正)をExcelツールが代行するので，関係部門が多く
長期間で進捗報告の回数の多いプロジェクトほど削減効果を高められる。
　本論文にExcelツールを添付しているので是非活用いただきたい。

紹介文 :
一般に、派生開発では機能の追加と変更が中心になる。その結果、応答時間などに変化が生じることがある。設計の担当者は応答時間の変化に気づかなかったり、気づいていた時でも、これくらいなら問題ないだろうと勝手に決め込んだりしていることが多く、納品後に「時間効率性」の劣化としてクレームとなる場合がある。時間効率性に関するクレームは、必ずしも遅くなったから問題になるとは限らない。派生開発の場合、使い慣れている状況に対して変化が許容範囲を超えると操作に影響を与えるからである。
設計者が応答時間等の劣化に気づかない理由として、ソースコードの該当箇所を探す際も、機能の変更に気を取られ、その機能が操作と絡んでいることに気がついていないことがある。そこで、変更要求を捉える段階で、メモリー処理や通信処理などの時間効率性に影響を与えそうな機能を変更するときには、時間の変化を予測して、「EMOT(Estimation Method Of Time behavior degradation)」の確認表を使って変化時間の目安を確認する。そこで事前に想定している許容範囲を超える時は、早めに依頼者と変更方法などを協議する。また他に変更方法がない時は、操作側で事前にトレーニングして備えてもらうことになる。こうした対応によって、後からのクレームになることを回避する。

紹介文 :
熟練度が低いレビューアでも有効な指摘ができるようにすることを目的として、
「熟練レビューアの勘所「トリガーポイント」を活用するレビュー手法」を提案しています。
「他システムからの横展開は敢えて行わない」、「熟練レビューアが教育やフォローを行う」など、
「量」よりも「質」を重視して、実践の場で確実に成果を出せるようにするための工夫をしています。

紹介文 :
本研究は、開発プロジェクトが抽出した多数のリスクに対して、リスクを産む要因となるリスク事象ドライバーに着眼することで、品質部門がリスクの繋がりを分析（多変量解析によるモデル化）し、妥当性と網羅性の観点でレビューして、開発部門が見落とした可能性のあるリスクや軽減策を提案する、大変有用性の高い研究である。

紹介文 :
本論文では、派生開発での回帰テストにおいて、デグレード不具合を効率よく検知するため、テストケースにソフトウェア変更の影響範囲を基にしたスコア付けを行い、テスト実施するテストケースの選定手法を提案している。
具体的には、データフロー図(Data Flow Diagram, DFD)を用いてデータフローを介して繋がる機能数を機能ごとに計測し、その数を基にスコア付けを行い、スコアの高い順から優先的にテストケースを選定する手法である。
この手法により、変更後の機能からの影響を受けやすい機能をスコアとして表すことができる。そして、スコアが高い機能を優先的かつ重点的にテストを行うようにテストケースを選定することで、デグレード不具合を検知しやすくなることが見込まれる。