紹介文 :
派生開発における開発プロセスとして、XDDPの有効性が多くの現場で示されています。一方で、従来とは違う成果物が必要になるなど、短期間での開発を求められる現場では、導入への抵抗感が強いのも事実です。本発表では、この両者をスムーズにつなぐための具体的な方法を提示しており、XDDPの推進に意欲的なチームの助けになることでしょう。

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

紹介文 :
基本仕様の制度や品質は、ソフトウェア開発の後工程の工数や品質に 大きな影響を与えます。 そこでこの論文では、テスト技法であるCFD法を基本仕様策定時に取り入れることで、機能仕様の組合せを正確かつ網羅的に抽出し、あいまい性のない表記で記述する方法を提案しています。 テスト技法を利用した上流工程の改善に効果があります。

紹介文 :
ＣＭＭＩと品質会計を軸にしながら、定量的管理プロセスを含む開発プロセスを構築したの事例です。 現状を分析しながら、一つずつ、一歩一歩 進めていくアプローチは、標準化に取り組むところ全てに参考になるものです。

紹介文 :
「ビジネスを成すエンジニアリング」という視点に立った場合、これから生まれるであろう様々な新技術を用いた開発の現場ではどのような、発想支援/情報共有/評価方法が必要になって行くのであろうかを検討しています。題材としては現時点では実現できない、任意の目的地までの誘導システムです。それが実装できるのかではなく、それらが実装できる時には、どのようなスキルが求められるのかという視点です。3D映像が手軽に活用できる様になったとき、文字ベースの仕様書以外にどのような方法で仕様化し共有していくのかという未来予想図です。

紹介文 :
Pair-wise法を適用するにあたって必要となる因子・水準・制約を、論理的に導出する方法を提案しています。これらがツリーとしてモデル化されることからレビューが容易になり、思考の過程も蓄積されるという長所があります。さらにそのモデルからテストケースの抽出にまでつなげているところもポイントです。

紹介文 :
ソフトウェアテストにおけるテスト技法については、効果は理解されているものの展開が難しく、人によるばらつきや抜け漏れのためにテスト品質が 確保できずにお困りの方も多いのではないでしょうか。 とはいえ、本や机上で学んだだけでは、適用が難しいのも事実です。 この論文では、テスト技法を現場に適用したときの問題を想定し、解決策を提案しました。

紹介文 :
過去のレビュー指摘を分類・活用しようとすると、これまでは必ずと言っていいほど、管理者視点で行われてきた。 本論文では管理者視点と共存する形で、作成者視点の分類・活用方法が提案されている。 実験で付与されたタグは大きく６つに分類され、「機能系」「対応方法系」「品質特性系」だけでなく、「注意喚起系」「表現方法系」「影響度系」といった作成者ならでは視点があり、具体的なキーワードでタグが付与されている。 作成者にとってレビュー指摘を検索・活用しやすくなると共に、作成者自身が自由にタグを付与できるため、品質向上活動への能動的な関与の促進が期待できる。 レビュー指摘を組織的に蓄積・横展開し、作成時の品質向上に活用したいと考えている組織の方は、一読されることをお勧めする。

紹介文 :
自動テスト支援ツールの選定は誰でもが悩む問題です。この事例紹介では、性能測定テストや回帰テストといったテストの種類によってどういったツールを選定すべきかを実践して結果をまとめています。「WSH」、「UWSC」、「TestComplete」、「UIAutomation」を選定候補としています。これらのツールを使用されている方、使用を検討されている方は参考になります。

紹介文 :
2013年SQiP Best Presentation AwardとSQiP Best Paper Future Awardを同時受賞しています。レビュー熟練者の頭の中を写し取るという試みが書かれています。レビューがうまくなってくるといわゆる「匂い」というものが感じられるようになってきますが、それを「兆候」→「仮説」→「仮説検証」という形で説明しています。日頃のレビューの中で、このような考え方で進めているのだなということを再認識させてくれる内容になっています。ただ、「匂い」そのものについては軽く触れているだけなので、これ以上は実践して経験を貯めていくしかないのかもしれません。

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

紹介文 :
レビューという品質向上活動そのものを改善することを目的として、 「レビューの振り返り手法」を提案しています。 「レビュー記録という客観的な事実を活用する」、「作成者とレビューアが個別に振り返る」、 「作成者とレビューアがお互いを振り返る」、「継続すべき項目にも着目する」など、 心理的安全性を高めて参加者全員から前向きな意見が抽出され、有意義で合意と納得の行く振り返りができるように工夫をしています。

紹介文 :
ソースコード品質評価にドメインの特性や開発者の意図を反映させ、より適切な評価結果を得る方法を提案しています。 測定されたメトリクスに対する開発者へのヒアリングの流れや結果、得られた評価結果の分析、ツールの改善点などが示されています。ソースコード品質評価における課題や改善の進め方に興味がある人にとって有意義な内容となっています。 本研究に登場する既存のソースコード品質評価ツール「Adqua」を使っている方にはもちろん、他のソースコード品質評価ツールを使っている方にとっても、参考になる研究です。

紹介文 :
１つの変更要求が及ぼす影響というのは時として他システムに跨ることもあります。この影響範囲を特定する方法として派生開発で使用されるXDDPを採用しました。 変更依頼を要求と仕様の階層構造で表現し、要求レベルで他システムへの影響を検討することで影響範囲を特定しようとした試みです。

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

紹介文 :
レビューアとして自分の指摘の有効性は気になるものです。いかに短時間に重大な欠陥を指摘できるかはレビューアの腕といってもいいでしょう。本論文はビジネスリスクから有効なレビュー観点が導き出せるかを試しています。基本的にはビジネス要求からレビュー観点までをFTAに似たツリー方式で分解し、実際のレビューにその観点を持ち込むかどうかの判定はリスクベースドテストの考え方で行っています。特にレビュー初心者のアドホックレビューを防ぎ、レビュー全体の底上げ手段として有効です。

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

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

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

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