紹介文 :
派生開発で常に悩まされる問題は、変更に伴って予想外のバグが発生することである。
そのための「気付き」の工夫は、これまでも「派生開発」の分科会でもテーマに取り上げられてきた。「DRBFM」の視点を取り入れて「品質」への支障を取り上げる研究も行われているが、それでは範囲が広がり過ぎて、この種の取り組みに慣れていない現場のエンジニアでは見逃しやすい。そこで研究員の組織の中で実際に起きている「影響」の問題を調べてみると、副作用が起きる「場」として「時間」や「メモリー領域」といった、いわゆる「リソース」に共通することに気付いた。「リソース」に着目する効果としては計測が可能で判断のための「限界値」が定義できることである。

紹介文 :
ソフトウェアテストの自動化ツールは、導入の要望は高いものの、効果や導入の準備などさまざまなことを考えるとなかなか踏み切れない方も
多いのではないでしょうか。
この論文は、テスト自動化への「取り組みやすさ」を考えて、段階的に導入を進める方法を提案しています。

紹介文 :
設計段階で数値要求又は数値定義を記述しないというバグを予防するため、仕様書に数値記入が必要と考えた振る舞いを定義した。それを使って仕様書の記述漏れ・誤りを抽出したことが報告されている。

紹介文 :
　エンジニアからアイデアを引き出すための手順としての研究です。アイデアは時流にのった旬が大切ですが、採用/不採用に関わらず選定者の観点や責任問題が気になります。最低限何を提出してもらい、どんな観点でレビューすれば良いのかで悩んでいる方にお勧めします。

紹介文 :
外部からの，プロジェクトとは無関係の「外乱」，とくに保守におけるあらかじめ考えておくことが難しい「外乱」の分類や，要因，対応策を示しています．対応には，外乱が発生した場合の対策と，外乱を発生させないための対策があります．現実のプロジェクトにおいて，すべての外乱をなくしていくことはできないでしょうから，いつ何時であっても，今後発生しうるリスクについて思いを巡らせておく必要があります．このようなときに，現実のプロジェクトとのギャップ分析を行うことによって，それまでは想定外であった外乱があるかもしれないことに気がつくかもしれません．

紹介文 :
トップレビューアの頭の中がのぞけたら・・・本論文の研修者たちは挑戦した。トップレビューアの思考プロセス、それがHDR法だ。もしこの方法で優秀なレビューアが育つなら試してみない手はない。悩みを抱えるPMや品質管理部門の方はぜひご一読をお勧めする。

紹介文 :
通常、XDDPの変更プロセスでは「3点セット」を必須としている。これは派生開発で混乱している組織にあっては、この3点セットの成果物を作りながら作業を進めることで秩序を確保するのが狙い。しかしながら、ビジネス系においては「SLCP」などでそれなりの成果物が作られプロセスの秩序も維持されていることがある。また、短納期の要求などもあって、「3点セット」を作成することに抵抗がある。そのような中で、変更を含む要求仕様に関するトラブルに的を絞って取り組むことにしたケース。得意なケースなので、なぜこの「部分適用」の方法が可能なのか、本報告書から読み取って欲しい。

紹介文 :
チームが自立的に動いてくれない。どうすれば自立的に動いてくれるかという古くて新しい問題に立ち向かった。
まずは、チームの能力のよってたつ構造を明らかにした。チームの能力は、4つの属性から成り立っている。環境属性、リーダ属性、メンバ属性、組織属性である。各々の属性は説明変数に分解される。これらの変数には、変えられる変数と変えられない変数、さらにその中間的な変数がある。
リーダは、チームの状況に応じて、どの説明変数を変化させれば良いかを考え、組織を変えたり、メンバーを変えたり、教育したり働きかける。こうすることで、メンバの自主性・主体性が発揮され、チームを活性化できる。

紹介文 :
本研究は継続的にレビューする手法ContinuousReviwについて記すものである。レビュー品質の向上を目指すうえで、「短時間、レビューアのばらつき」の問題は大きい。CR法はプロセスを持つレビュー法であるが、参加者自身がレビューの目的とルールを定め、振り返りを行い、新たなレビュー観点やルールの変更を検討する。特にレビュー期間が限られているプロジェクトの品質担当者にご一読いただきたい。

紹介文 :
本論文は、効率よく欠陥を検出できる上級テストエンジニアのテストスキルを、経験の浅い初級テストエンジニアに移転するためのテスト実施トレーニング手法を研究したものです。
具体的には、過去の欠陥情報から上級テストエンジニアのノウハウを抽出し、それをSOHT表にまとめてトレーニングすることで初級テストエンジニアのスキルを向上します。

紹介文 :
ソフトウェア開発において変更が発生したとき、すべての範囲をテストしなおすことは難しい場合に、回帰テストの優先順位をつける方法を提案しています。
限られた期間でデグレードの確認が必要な場合にお勧めです。

紹介文 :
専門的なソフトウェアについて、利用者も気づいていない要求を抽出するために、該当ソフトウェアの初心者が熟練者に弟子入りして学ぶ様子を観察しています。
要求を実現する画面案と実機を組み合わせた簡易プロトタイプで評価することで、要求の妥当性検証を短期間・低コストで実施できるよう工夫されています。

紹介文 :
・パッチの情報を追いかけ適用について。特にパッチ起因の障害発生の可能性とパッチ検証の工数猶予がない問題を解説。NISTの文献 SP800-40（Procedures for Handling Security Patches：米国国家の連邦組織利用のパッチ適用標準）を中心に研究した成果が記載されている。
・また当該NIST基準について国内で展開した場合での弊害／課題についても深く考察されており、2005年当時の課題が今でも有効である点は特筆に値する。（例：NIST標準の適用事業規模、パッチ検証環境の保持困難、管理者負荷、言語の壁他）
・情報セキュリティ早期警戒体制の拡充、強化の一環として、平成16年7月7日に経済産業省から発表された「ソフトウェア等脆弱性関連情報取り扱い基準」および「情報セキュリティ早期警戒パートナーシップガイドライン」についても解説している。

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

紹介文 :
プロジェクトに関わるさまざまな人びとが，各自の仕事の進み具合や課題を全体に投げかけ，また全体として状況を把握し課題に立ち向かっていくためにはどうしたら良いのかということを示しています．このことを考えていくために，コミュニケーションと情報の構造を分析したうえで，具体的な進捗報告の方法の一例が提示されています．プロジェクト全体のコミュニケーションについて考え直したい人や，個々の具体的な進捗報告の方法について考えたい人のそれぞれにとって有用です．

紹介文 :
研究会で事例を発表し合った。ところが、内容が伝わらない。実際の仕事でも、仕様が誤解されたり、指示が伝わらなかった等、この種の事例にはこと欠かない。そこで、この問題を解こうとした。
　事実を正確に伝え、そこから推論を組み立てるべきなのに、推論が随所に入って議論が混乱してしまう。あるいは、推論同士で根拠の無い議論が空回りしてしまう。まず、事実を正確に伝えることが伝わる第一歩だ。事実が共有できれば、その上にたつ推論の範囲は狭められる。
　元々我々は、話を受ける側の教育ばかり受けてきて、話し手の教育をあまり受けてきていない。一度本論文を読んで、伝わる/えるにはどうすべきか考え直してみると良い。

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

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

紹介文 :
本研究は、二つのモデルを組織に導入するための、一手段を提供している。　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　興味深い内容としては、CMMIの前モデルである、ソフトウェアプロセス改善モデルCMMとISO9001を融合させる研究の活動内容より、現モデルCMMIへの進化の過程と改善のための構造・構成要素を深く理解することが可能となる。

紹介文 :
複数の組織がソフトウェアシステムを共有する状況で、届けられた変更依頼が「共通仕様」における変更かどうかを判断できずに変更モレを起こすケースが少なくない。このようなケースでは「人（熟練者）」に依存することが多いが、この研究では、共通仕様に関する変更情報を１箇所に集約して「共有」したことと、共通仕様の判断が困難なときは無理に判断せずに一時「保留」する仕組みを取り入れ、そこに熟練者が判断する機会を集中させたことで、熟練者の負荷を下げているという方法を取った。もう一つの特徴は、共通仕様から「USDM」への展開を自動化したことである。これによって、関係部門に対して同じフォームで展開できるというメリットがある。「熟練者」が関わる部分と「自動化」する部分をうまく使い分けている。