紹介文 :
過去に発生したトラブル事例を有効活用を図るための、阻害要因を事例から追及し、どのように構成すればよいか、スクリーニングの方法等を研究した論文である。結論は使い続けることが必要。

紹介文 :
組み込み系における品質活動特にSQAに関する責任と権限を明確にして活動を行うことのヒント。組み込み製品のジャンル分けをしてプロセスの特徴を整理しどのような観点でプロセスチェックを行うべきかをヒント。等を研究しSQAの活動を報告されている。

紹介文 :
開発期間が短い派生開発において、追加機能の要求仕様書が短期間に精度の高いものが書けることは重要だ。そこで仕様モレが少ない表記法として「USDM」を導入しようとしたが、従来の書き方に慣れた人たちにとってギャップが障壁となった。そこで慣れない現場の人たちを誘導するために何が必要かを「現場の目線」から探り出し、初心者向けにUSDMガイドラインを作成した。このような障壁は新しい方法を導入しようとするときにつきものであるが、その解決方法として今回のような優しく誘導するという取り組み方は、ガイドラインを作成することで推進者自身がその手法を理解することになり、いろんなケースに応用できる取り組み方である。

紹介文 :
要求仕様書の作成ページ数及び指摘件数とソース量とシステムテストでの障害件数等を採用し重回帰分析で上流での検出量からシステム試験での障害発生との相関を分析した研究論文。

紹介文 :
要求仕様書の品質を上げるための施策を3つ提案している．一つはWモデルの考えで，要求仕様書とテスト設計書を同時作成し，テスト設計書から要求仕様書にフィードバックをかけるとうもの．もう一つは，仕様書にハイパーテキストを使って，仕様書間の矛盾を発見しやすくしたもの．最後は，記載漏れを防ぐためのチェックリストを提案している．

紹介文 :
レビューでよくつかわれるチェックリストは絶えずメンテナンスをしていかなければならない。本論文は、効果的なチェックリストを作るために、ベテランエンジニアの暗黙知を導入する方法を提案している。

紹介文 :
ASILモデルの安全性レベルをベースにして危険要素を監視する構成モデルの検出レベルと独立性の評価を行いシステムの分割要件をまとめた研究論文である。

紹介文 :
組み込み開発では、移植とか再利用と称してコードを流用することが多い。コードの部品化は、SPL(Software Product Line)で議論されている。本論文での課題は、組み込み開発で、何を部品化するか、その優先度はどう決めていくか問うことである。それが決まれば、作り方やテストの仕方を変えることができるからである。本論文の特徴は、そのための分析の仕方、特に、要求レベルでの重要度も取り入れて優先度を決めているところにある。コードの部品化を考える際に大変参考になる文献である。

紹介文 :
派生開発では、依頼された変更に対して隠れた変更箇所を見極めにくいことが見積りを難しくしている。その中に変更依頼の内容が具体的すぎるケースがあることに気付いた。
そこでこの問題の解決方法として、「USDM」の「仕様」から「要求」を探る方法に着目したが、この研究のポイントは、届いた変更依頼が「仕様」レベルであるかどうかの「判断」の方法を考案したことであり、これによって、隠れた変更の存在に気付く方法を模索したものである。
この方法に習熟することで見積りのズレが大幅に解消されることが期待できる。
逆にいうと、一般の単純な箇条書きの要求仕様の表現では、この具体的すぎる変更依頼から隠れた変更箇所に気付くことは難しいのかもしれない。

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

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

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

紹介文 :
非熟練技術者プロジェクトではデグレードの防止が極めて難しいことに着目し、習熟度に関わらず変更内容に関するチェック項目を確認できる「気づきナビ」を提案しています。これにより、デグレード防止に必要な知識を補うことができるようになります。

紹介文 :
問題の発生源が組織の役割分担の仕方に起因することが少なくない。しかもその分担方法が「前提」として認識されている場合は、そこに改善の手が入らない。この種の問題は、組織を跨ぐことがあるが、単に役割分担の問題だったりすることもある。
この報告書は、目立たない取り組みだが、問題を分析する過程で、問題の源泉が不適切な慣行にあることに気付いたケースであり、問題を分析することの重要性を示唆している。

紹介文 :
システムが大規模化し、関係組織が多岐にわたる状態になっているにもかかわらず、多くの組織ではシステム全体を知る人材を確保してこなかった。そのため、変更が他部門に影響することを事前に判断できなければ、大きな問題が起きる。特に、「仕様」の状態で変更依頼が届くケースでは、直接関係する部分がイメージしやすいため、他への影響に気付きにくい。この報告書では、仕様レベルで届いた変更依頼から、組織レベルで変更を捉え直す方法を提案している。ただし、変更においても「要求」と「仕様」の階層で捉えることが前提となる。

紹介文 :
熟練担当者が暗黙の了解として扱うためドキュメントに記載されない仕様や設計の理由に関する情報（「マイスター情報」）を引き出し、形式知として残す方法を提案しています。

紹介文 :
短納期開発現場で、成果物の形態を変えたり新しい手法を導入したりするには、時間に対する不安や効果に対する不安を排除する必要があります。本研究は、XDDPを短納期開発現場に導入する際の不安を払しょくするための施策を提案しています。

紹介文 :
派生開発では新規開発時の作りの悪さや、その後の派生開発での変更作業によってソースコードの劣化が進んでいることが多く、変更ミスを引き起こす要因になっている。ソースコードの劣化を改善する方法としてリファクタリングがあるが、仕様の変更作業の中で、”良かれ“と思って、担当者の判断で安易に構造を変えてしまったり、無造作にリファクタリングにとりかかったりすることでかえって事態を悪化させることが多い。
XDDPでは、仕様変更の中でソースコードの劣化を和らげるために、当該関数に限定した「小さなリファクタリング」を許しているが、これだけでは足りない。
そこで、XDDPを応用してリファクタリングに特化した派生開発プロセスとして「R-XDDP」という方法を提案し、リファクタリング・パターンを限定しながら、混乱することなくリファクタリングに取り掛かる方法を勧めている。

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