紹介文 :
CMMからCMMIへのスムーズな移行を目的として、両モデルの比較考察を行い、両モデルのゴールとプラクティスの対応関係と見解をまとめたマッピング表を作成しています。 また、CMMからCMMIへの移行の際に優れていると思われる点5つ（要件管理、リスク管理、計測と分析、エンジニアリング、決定分析と解決）につて整理されています。

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

紹介文 :
工程毎に分業化された複数のグループで同時並行で行われる小規模な派生開発における進捗管理の課題に対して「機能-作業マトリクス」という簡潔な進捗管理方法を提案している。「機能-作業マトリクス」では、進捗管理時に課題となりやすい計画立案、進捗情報入力、対策立案に対して属人的な計画にならず進捗管理負荷が軽減されるように工夫されているのが特徴で、ガントチャートのように専用ソフトウェアがなくても管理可能な点が負荷軽減の一助になっていると思われます。

紹介文 :
XDDPとSCRUMを組み合わせることにより、①後戻りに関する課題(終盤でのH/W変更リスク)、②人とチームが成長するチームビルディング、③ソフトウェアのリリースタイミングといった課題を解決した事例です。プロジェクトメンバへのアンケート結果もあり、現場からの声も一部紹介されています。

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

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

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

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

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

紹介文 :
派生開発において、変更要求を実現した結果、当初の”設計制約”が変わることがあります。このような、本来の変更に付随して発生する”前提条件の変更”は見つけにくいものです。本研究では、これを”欠陥混入メカニズムの知識”を活用して把握しようというものです。

紹介文 :
アジャイルは、顧客に価値を提供していく成果物を開発することを目標としているが、顧客が本当に求めている要求をとらえられず、価値の低い製品をデリバリーすることがしばしばある。それは、アジャイル開発における要求を表しているバックログ自身に問題があることも多い。本論文は、その課題に焦点を当てて、顧客の価値を考えたバックログを作るプロセスを提案している。

紹介文 :
セキュリティ対策など、優先度の高い対応をスピーディに行う場面では、使用性への配慮が不足しがちです。その結果、業務効率を悪化させることが開発終盤や納品後に判明し、手戻りの要因となっています。このような問題を、顧客のビジネスリソース(作業分担，システム連携，作業自動化の程度など）の違いに着目し、解決しようとしています。チェックリストで注意を促す古典的なやり方との違いは、顧客と自社のビジネスが両立する仕様決定を促す点です。

紹介文 :
ソフトウェア開発チームは、その開発活動において、いろいろなストレスを受ける。例えば、ある知見を持ったチームメンバーが突然移動になるなどは、チームの活動にに大きなインパクトがある。いったんそのインパクトを受け止めて、そのダメージから回復していく力をレジリエンスと呼ぶ。アジャイル開発では、その@プラクティスにおいて、数々のストレスを認識し、それに対するレジリエンスを持つ気づきを与えてくれる。この論文は、アジャイル開発のプラクティスとレジリエンスに関係性があることを仮説して、実際のチームを調査し、アジャイルプラクティスをうまく行うチームは、レジリエンスが高い傾向にあることを示した。

紹介文 :
コロナ禍によって研究活動自体がオンライン実施となったことを逆手にとって、完全オンライン環境でUXデザイン手法の実践に取り組んだ経験論文です。 UXデザインだけでなく、オンライン環境でのコミュニケーション実施例としても、とても参考になります。