品質確保に効果のあった派生開発プロセスの工夫#17

掲題の派生開発プロセスに関する、シリーズ・エントリです。
派生開発の設計品質確保について問題意識を持たれている方は、ご一読頂けると幸いです。
レポートの要約、および背景については第一回を参照ください。

エントリ内容の目次

まずはこのレポートの主旨について述べた後、一般的な派生開発の現状を俯瞰する。その後、派生開発プロセスの１つであるＸＤＤＰと、当方の開発プロセスの工夫についての概要を述べる。

時間のない場合は、ここまでの内容（１部 レポート・サマリー）だけでも、本論述の概要はつかめると考える。その次の２部から、詳細なレポート内容を述べていく。

もちろん２部から読み始めても構わない。そちらのほうが、概要説明ではなく詳細な論述を行っているため、理解しやすい可能性がある。１部はサマリーのみであり、詳細情報は把握できないだろう。

（１）このレポートの概要と背景について
　　　⇒記事はこちら

１部　レポート・サマリー－－－－－－－－－－－－
（２）派生開発を巡る現状
　　　⇒Ｐａｒｔ１
　　　⇒Ｐａｒｔ２

（３）ＸＤＤＰでの問題提起と解決策の概要
　　　⇒記事はこちら

（４）当方が遭遇した派生開発の問題と解決策の概要
　　　⇒記事はこちら

２部　レポートの詳細－－－－－－－－－－－－－－
（１）派生開発の課題とプロセス改善について
　１．派生開発の課題
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３
　　
　２．派生開発のプラクティス、プロセス
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３

（２）派生開発プロセスの内容
　１．対処検討プロセス群
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３
　　　⇒ｐａｒｔ４
　　　⇒ｐａｒｔ５
　　　⇒ｐａｒｔ６（本記事が該当）

　２．開発プロセス群
　３．検証プロセス群

（２）派生開発プロセスの内容

１．対処検討プロセス群(part６)

対処検討プロセスを順に解説していく。今回は最後のプロセスである「1.5 対処決定」の解説を行う。

　・1.1　原因特定
　・1.2　スコープ定義
　　　　　├─1.2.1　要求コンセプトの明確化
　　　　　└─1.2.2　要求仕様の特定
　・1.3　対処案の特定
　・1.4　対処案の検証
　・1.5　対処決定

※プロセスの全体像を参照したい場合はこちら。

1.5 対処決定

1.5.1 プロセスの目的・概要

対処決定プロセスの目的は、「1.4対処案の検証」プロセスの結果を関係者間で協議し、決定することである。
採用された対処案が決定することで、本プロセスは終了となるが、次の「2.開発プロセス群」の実施に先立って、要求事項トレーサビリティ・マトリクスを作成する。本資料の作成によって、次工程の開発箇所を明確にすると共に開発量の見積りを行うことができる。
続きを読む →

品質確保に効果のあった派生開発プロセスの工夫#16

掲題の派生開発プロセスに関する、シリーズ・エントリです。
派生開発の設計品質確保について問題意識を持たれている方は、ご一読頂けると幸いです。
レポートの要約、および背景については第一回を参照ください。

エントリ内容の目次

まずはこのレポートの主旨について述べた後、一般的な派生開発の現状を俯瞰する。その後、派生開発プロセスの１つであるＸＤＤＰと、当方の開発プロセスの工夫についての概要を述べる。

時間のない場合は、ここまでの内容（１部 レポート・サマリー）だけでも、本論述の概要はつかめると考える。その次の２部から、詳細なレポート内容を述べていく。

もちろん２部から読み始めても構わない。そちらのほうが、概要説明ではなく詳細な論述を行っているため、理解しやすい可能性がある。１部はサマリーのみであり、詳細情報は把握できないだろう。

（１）このレポートの概要と背景について
　　　⇒記事はこちら

１部　レポート・サマリー－－－－－－－－－－－－
（２）派生開発を巡る現状
　　　⇒Ｐａｒｔ１
　　　⇒Ｐａｒｔ２

（３）ＸＤＤＰでの問題提起と解決策の概要
　　　⇒記事はこちら

（４）当方が遭遇した派生開発の問題と解決策の概要
　　　⇒記事はこちら

２部　レポートの詳細－－－－－－－－－－－－－－
（１）派生開発の課題とプロセス改善について
　１．派生開発の課題
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３
　　
　２．派生開発のプラクティス、プロセス
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３

（２）派生開発プロセスの内容
　１．対処検討プロセス群
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３
　　　⇒ｐａｒｔ４
　　　⇒ｐａｒｔ５（本記事が該当）

　２．開発プロセス群
　３．検証プロセス群

（２）派生開発プロセスの内容

１．対処検討プロセス群(part5)

対処検討プロセスを順に解説していく。今回は「1.4 対処案の検証」の解説を行う。

　・1.1　原因特定
　・1.2　スコープ定義
　　　　　├─1.2.1　要求コンセプトの明確化
　　　　　└─1.2.2　要求仕様の特定
　・1.3　対処案の特定
　・1.4　対処案の検証
　・1.5　対処決定

※プロセスの全体像を参照したい場合はこちら。

1.4 対処案の検証

1.4.1 プロセスの目的・概要

対処案の検証プロセスは、特定された対処案の調査アイテムに従って、ソースコードやドキュメントを調査し、必要に応じてスペックアウトを行いながら、対処案が正常に動作することを検証するプロセスである。

対処案をリストアップした時点では、設計情報やソースコードの詳細までを確認しているわけではない。そのため、詳細な調査を行った結果、当初検討した対処案では要求仕様を満足できないことが判明する場合もある。

対処案の検証では、対処案が要求仕様を満足していることを徹底的に調査する。対処案の正常性を確認するのではなく、対処案が要求仕様を満たしていない事項がないかを検証していく。
続きを読む →

品質確保に効果のあった派生開発プロセスの工夫#15

掲題の派生開発プロセスに関する、シリーズ・エントリです。
派生開発の設計品質確保について問題意識を持たれている方は、ご一読頂けると幸いです。
レポートの要約、および背景については第一回を参照ください。

エントリ内容の目次

まずはこのレポートの主旨について述べた後、一般的な派生開発の現状を俯瞰する。その後、派生開発プロセスの１つであるＸＤＤＰと、当方の開発プロセスの工夫についての概要を述べる。

時間のない場合は、ここまでの内容（１部 レポート・サマリー）だけでも、本論述の概要はつかめると考える。その次の２部から、詳細なレポート内容を述べていく。

もちろん２部から読み始めても構わない。そちらのほうが、概要説明ではなく詳細な論述を行っているため、理解しやすい可能性がある。１部はサマリーのみであり、詳細情報は把握できないだろう。

（１）このレポートの概要と背景について
　　　⇒記事はこちら

１部　レポート・サマリー－－－－－－－－－－－－
（２）派生開発を巡る現状
　　　⇒Ｐａｒｔ１
　　　⇒Ｐａｒｔ２

（３）ＸＤＤＰでの問題提起と解決策の概要
　　　⇒記事はこちら

（４）当方が遭遇した派生開発の問題と解決策の概要
　　　⇒記事はこちら

２部　レポートの詳細－－－－－－－－－－－－－－
（１）派生開発の課題とプロセス改善について
　１．派生開発の課題
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３
　　
　２．派生開発のプラクティス、プロセス
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３

（２）派生開発プロセスの内容
　１．対処検討プロセス群
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３
　　　⇒ｐａｒｔ４（本記事が該当）

　２．開発プロセス群
　３．検証プロセス群

（２）派生開発プロセスの内容

１．対処検討プロセス群(part4)

対処検討プロセスを順に解説していく。今回は「1.3 対処案の特定」の解説を行う。

　・1.1　原因特定
　・1.2　スコープ定義
　　　　　├─1.2.1　要求コンセプトの明確化
　　　　　└─1.2.2　要求仕様の特定
　・1.3　対処案の特定
　・1.4　対処案の検証
　・1.5　対処決定

※プロセスの全体像を参照したい場合はこちら。

1.3 対処案の特定

1.3.1 プロセスの目的・概要

対処案の特定プロセスの目的は、要求仕様を満足する対処案を複数検討し、対処案を実現するために明らかにしなければならない調査事項（調査アイテム）を洗い出すことである。

本プロセスでは、必要であれば要求仕様を更に要素分解して、設計書やソースコードの調査を行う。調査の過程で、要素分解、バリエーション検討、マトリクス表記の３手法を活用しながら、対処案を検討する。
続きを読む →

前回エントリから１ヵ月以上空いてしまいました。
多忙と試験勉強が言い訳なのですが。。
このシリーズエントリは先が長すぎて、No.50とか平気でいきそうなので、きりのいいところでpdf化した内容を一括ダウンロードで終わりにしたいかな、、と考えているこの頃です。

ではプロセス改善のNo.14をどうぞ。

品質確保に効果のあった派生開発プロセスの工夫#14

掲題の派生開発プロセスに関する、シリーズ・エントリです。
派生開発の設計品質確保について問題意識を持たれている方は、ご一読頂けると幸いです。
レポートの要約、および背景については第一回を参照ください。

エントリ内容の目次

まずはこのレポートの主旨について述べた後、一般的な派生開発の現状を俯瞰する。その後、派生開発プロセスの１つであるＸＤＤＰと、当方の開発プロセスの工夫についての概要を述べる。

時間のない場合は、ここまでの内容（１部 レポート・サマリー）だけでも、本論述の概要はつかめると考える。その次の２部から、詳細なレポート内容を述べていく。

もちろん２部から読み始めても構わない。そちらのほうが、概要説明ではなく詳細な論述を行っているため、理解しやすい可能性がある。１部はサマリーのみであり、詳細情報は把握できないだろう。

（１）このレポートの概要と背景について
　　　⇒記事はこちら

１部　レポート・サマリー－－－－－－－－－－－－
（２）派生開発を巡る現状
　　　⇒Ｐａｒｔ１
　　　⇒Ｐａｒｔ２

（３）ＸＤＤＰでの問題提起と解決策の概要
　　　⇒記事はこちら

（４）当方が遭遇した派生開発の問題と解決策の概要
　　　⇒記事はこちら

２部　レポートの詳細－－－－－－－－－－－－－－
（１）派生開発の課題とプロセス改善について
　１．派生開発の課題
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３
　　
　２．派生開発のプラクティス、プロセス
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３

（２）派生開発プロセスの内容
　１．対処検討プロセス群
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３（本記事が該当）

　２．開発プロセス群
　３．検証プロセス群

（２）派生開発プロセスの内容

１．対処検討プロセス群(part3)

対処検討プロセスを順に解説していく。今回は「1.2.2 要求仕様の特定」の解説を行う。

　・1.1　原因特定
　・1.2　スコープ定義
　　　　　├─1.2.1　要求コンセプトの明確化
　　　　　└─1.2.2　要求仕様の特定
　・1.3　対処案の特定
　・1.4　対処案の検証
　・1.5　対処決定

※プロセスの全体像を参照したい場合はこちら。

1.2.2 要求仕様の特定

1.2.2.1 プロセスの目的・概要

要求仕様の特定プロセスの目的は、システムやソフトウェアの構成要素が特定できる形まで、要求コンセプトをブレイクダウンし、適切な作業スコープを設定することである。

要求コンセプトは、「トランザクションの同時受付数を５０００まで拡張する」とか「機器の障害発生時に、アクティブ系の機器が存在しない状態を３０秒以上継続させない」などといった、システムの構成要素や設計・プログラム構成要素を特定しにくい表現になっている。

この表現を、「Ａ機器管理処理ブロックにおいて、○○通知を受信した場合は、□□の動作を行う」といったシステムやソフトウェアの構成要素の振る舞いがわかる程度の詳細度にブレイクダウンしていく。このブレイクダウンされたものを要求仕様と呼ぶ。
続きを読む →

品質確保に効果のあった派生開発プロセスの工夫#13

掲題の派生開発プロセスに関する、シリーズ・エントリです。
派生開発の設計品質確保について問題意識を持たれている方は、ご一読頂けると幸いです。
レポートの要約、および背景については第一回を参照ください。

エントリ内容の目次

まずはこのレポートの主旨について述べた後、一般的な派生開発の現状を俯瞰する。その後、派生開発プロセスの１つであるＸＤＤＰと、当方の開発プロセスの工夫についての概要を述べる。

時間のない場合は、ここまでの内容（１部 レポート・サマリー）だけでも、本論述の概要はつかめると考える。その次の２部から、詳細なレポート内容を述べていく。

もちろん２部から読み始めても構わない。そちらのほうが、概要説明ではなく詳細な論述を行っているため、理解しやすい可能性がある。１部はサマリーのみであり、詳細情報は把握できないだろう。

（１）このレポートの概要と背景について
　　　⇒記事はこちら

１部　レポート・サマリー－－－－－－－－－－－－
（２）派生開発を巡る現状
　　　⇒Ｐａｒｔ１
　　　⇒Ｐａｒｔ２

（３）ＸＤＤＰでの問題提起と解決策の概要
　　　⇒記事はこちら

（４）当方が遭遇した派生開発の問題と解決策の概要
　　　⇒記事はこちら

２部　レポートの詳細－－－－－－－－－－－－－－
（１）派生開発の課題とプロセス改善について
　１．派生開発の課題
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３
　　
　２．派生開発のプラクティス、プロセス
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３

（２）派生開発プロセスの内容
　１．対処検討プロセス群
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２（本記事が該当）

　２．開発プロセス群
　３．検証プロセス群

（２）派生開発プロセスの内容

１．対処検討プロセス群(part2)

対処検討プロセスを順に解説していく。今回は、1.2.1 要求コンセプトの明確化から解説を行う。

　・1.1　原因特定
　・1.2　スコープ定義
　　　　　├─1.2.1　要求コンセプトの明確化
　　　　　└─1.2.2　要求仕様の特定
　・1.3　対処案の特定
　・1.4　対処案の検証
　・1.5　対処決定

※プロセスの全体像を参照したい場合はこちら。

1.2.1 要求コンセプトの明確化

1.2.1.1 プロセスの目的・概要

要求コンセプトの明確化プロセスの目的は、派生開発における欠陥是正要求や変更要求に含まれる真の目的をあぶり出し、作業スコープを最大限に拡張することである。

スコープを広げることで、欠陥是正要求や変更要求を実現する際に、同時に対応しなければならない派生的な要求事項を見逃さないようにする効果が得られる。

派生開発におけるスコープの幅は、本プロセスで最大になり、以降のプロセスを経るに従い次第に具体化され縮小していく。

要求コンセプトの明確化が効果を発揮するケースは、ソフトウェアの具体的な欠陥是正要求が到来した場合である。

欠陥是正要求は、実際に発生している個別具体的な欠陥事象やその発生原因をふまえて発行されるため、はじめの要求時点から、かなり具体的な対処方針や修正内容を含んでいる場合がある。

例えば、「対向システムの回線障害検出論理を変更するため、○○処理の□□動作を、△△へ改修する」といった内容である。要求内容が具体的であればあるほど、担当者はすぐに具体的な修正内容の検討に着手しようとする。

その結果、同種の原因による他の欠陥が潜在していないかを水平展開して洗い出す作業が漏れたり、そもそもの要求で依頼された内容に誤りがあったりすることを見逃しやすくなる。
続きを読む →

品質確保に効果のあった派生開発プロセスの工夫#12

掲題の派生開発プロセスに関する、シリーズ・エントリです。
派生開発の設計品質確保について問題意識を持たれている方は、ご一読頂けると幸いです。
レポートの要約、および背景については第一回を参照ください。

エントリ内容の目次

まずはこのレポートの主旨について述べた後、一般的な派生開発の現状を俯瞰する。その後、派生開発プロセスの１つであるＸＤＤＰと、当方の開発プロセスの工夫についての概要を述べる。

時間のない場合は、ここまでの内容（１部 レポート・サマリー）だけでも、本論述の概要はつかめると考える。その次の２部から、詳細なレポート内容を述べていく。

もちろん２部から読み始めても構わない。そちらのほうが、概要説明ではなく詳細な論述を行っているため、理解しやすい可能性がある。１部はサマリーのみであり、詳細情報は把握できないだろう。

（１）このレポートの概要と背景について
　　　⇒記事はこちら

１部　レポート・サマリー－－－－－－－－－－－－
（２）派生開発を巡る現状
　　　⇒Ｐａｒｔ１
　　　⇒Ｐａｒｔ２

（３）ＸＤＤＰでの問題提起と解決策の概要
　　　⇒記事はこちら

（４）当方が遭遇した派生開発の問題と解決策の概要
　　　⇒記事はこちら

２部　レポートの詳細－－－－－－－－－－－－－－
（１）派生開発の課題とプロセス改善について
　１．派生開発の課題
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３
　　
　２．派生開発のプラクティス、プロセス
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３

（２）派生開発プロセスの内容
　１．対処検討プロセス群
　　　⇒ｐａｒｔ１（本記事が該当）

　２．開発プロセス群
　３．検証プロセス群

（２）派生開発プロセスの内容

１．対処検討プロセス群

今回からは、当派生開発プロセスを１つ１つ詳細に見ていく。説明は、

・プロセスの目的・概要
・プロセスフローの説明
・要素成果物の説明
・個々のプロセスの説明

の流れで行う。

個々のプロセスの詳細な説明になるため、現在位置が分からなくなることもあると思う。その時は、全体プロセスを参照し、現在地を確認しながら参照してもらえるとよろしいかと思う。

今回は「対処検討プロセス群」について解説を行う。

対処検討プロセス群

●プロセスの目的・概要

対処検討プロセス群は、派生開発における欠陥是正要求、変更要求を受け付けて、要求への対応方法を十分に検討し、関係者と協議し、決定を下す一連のプロセスで構成されている。

対処検討プロセス群の目的は、漏れのない対処検討を行うことを保証し、その結果として高い設計品質を確保することである。

対処検討プロセス群には、派生開発プロセスの４つのプラクティスの全てが含まれる。
続きを読む →

品質確保に効果のあった派生開発プロセスの工夫#11

掲題の派生開発プロセスに関する、シリーズ・エントリです。
派生開発の設計品質確保について問題意識を持たれている方は、ご一読頂けると幸いです。
レポートの要約、および背景については第一回を参照ください。

論述対象となるプロジェクト、および開発プロセスの特徴

・組込み系の社会インフラを担うミッションクリティカル・システム。

・信頼性・成熟性について高い品質が求められている。

・稼働直前の総合テストからプロジェクトを引き継ぎ。

・母体システムのドキュメントが不足、母体品質も悪い。

・論述対象の開発プロセスは、主にシステムの欠陥修正（改修）案件に焦点を当てている。

エントリ内容の目次

内容はかなり長くなるため、順を追って述べる。

まずはこのレポートの主旨について述べた後、一般的な派生開発の現状を俯瞰する。その後、派生開発プロセスの１つであるＸＤＤＰと、当方の開発プロセスの工夫についての概要を述べる。

時間のない場合は、ここまでの内容（１部 レポート・サマリー）だけでも、本論述の概要はつかめると考える。その次の２部から、詳細なレポート内容を述べていこうと考えている。

もちろん２部から読み始めても構わない。そちらのほうが、概要説明ではなく詳細な論述を行っているため、理解しやすい可能性がある。１部はサマリーのみであり、詳細情報は把握できないだろう。

（１）このレポートの概要と背景について
　　　⇒記事はこちら

１部　レポート・サマリー－－－－－－－－－－－－
（２）派生開発を巡る現状
　　　⇒Ｐａｒｔ１
　　　⇒Ｐａｒｔ２

（３）ＸＤＤＰでの問題提起と解決策の概要
　　　⇒記事はこちら

（４）当方が遭遇した派生開発の問題と解決策の概要
　　　⇒記事はこちら

２部　レポートの詳細－－－－－－－－－－－－－－
（１）派生開発の課題とプロセス改善について
　１．派生開発の課題
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３
　　
　２．派生開発のプラクティス、プロセス
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３（本記事が該当）

（２）派生開発プロセスの内容
　序．品質確保に効果的な派生開発プロセス
　１．対処検討プロセス群
　２．開発プロセス群
　３．検証プロセス群

２部　（２）派生開発のプラクティス、プロセス

前回までは派生開発のプラクティスを見てきた。今回からは、このプラクティスを組み込んだプロセスについて見ていく。

２．２　派生開発のプロセス

本節では、以上までにみた４つのプラクティスを具体的に実行するためのプロセスを説明する。最上位のプロセスでは、大きく３つのプロセス群に分かれている。

1.対処検討プロセス群
派生開発特有の課題に対応するために、開発工程の前に設けた事前検討を行うプロセス群。４つのプラクティスの全てが含まれる、本派生開発プロセスで特に重要なプロセスである。

2.開発プロセス群
一般的な開発プロセスである。本書ではウォーターフォール・モデルのプロセスを前提としている。ただし、本書は開発プロセスを規定する意図を持たないため、組織やプロジェクトにおいていずれの開発プロセス・開発モデルを採用していても、本派生開発プロセスを適用することが可能である。４つのプラクティスのうち、１つのプラクティス（ドキュメントのトレーサビリティ強化）が含まれる。

3.検証プロセス群
一般的なテスト工程を定めるプロセスである。検証プロセスについても、本書では特段の規定をする意図を持たない。組織やプロジェクトにおいていずれの検証プロセスを採用していても、本派生開発プロセスを適用することが可能である。

プロセス群のうち「2.開発プロセス群」と「3.検証プロセス群」は、理解度向上のために参考までに記載したものであり、本書は開発プロセスや検証（テスト）プロセスを規定するものではない。各プロセス群はさらに詳細なプロセスに分解される。
続きを読む →

品質確保に効果のあった派生開発プロセスの工夫#10

掲題の派生開発プロセスに関する、シリーズ・エントリです。
派生開発の設計品質確保について問題意識を持たれている方は、ご一読頂けると幸いです。
レポートの要約、および背景については第一回を参照ください。

論述対象となるプロジェクト、および開発プロセスの特徴

・組込み系の社会インフラを担うミッションクリティカル・システム。

・信頼性・成熟性について高い品質が求められている。

・稼働直前の総合テストからプロジェクトを引き継ぎ。

・母体システムのドキュメントが不足、母体品質も悪い。

・論述対象の開発プロセスは、主にシステムの欠陥修正（改修）案件に焦点を当てている。

エントリ内容の目次

内容はかなり長くなるため、順を追って述べる。

まずはこのレポートの主旨について述べた後、一般的な派生開発の現状を俯瞰する。その後、派生開発プロセスの１つであるＸＤＤＰと、当方の開発プロセスの工夫についての概要を述べる。

時間のない場合は、ここまでの内容（１部 レポート・サマリー）だけでも、本論述の概要はつかめると考える。その次の２部から、詳細なレポート内容を述べていこうと考えている。

もちろん２部から読み始めても構わない。そちらのほうが、概要説明ではなく詳細な論述を行っているため、理解しやすい可能性がある。１部はサマリーのみであり、詳細情報は把握できないだろう。

（１）このレポートの概要と背景について
　　　⇒記事はこちら

１部　レポート・サマリー－－－－－－－－－－－－
（２）派生開発を巡る現状
　　　⇒Ｐａｒｔ１
　　　⇒Ｐａｒｔ２

（３）ＸＤＤＰでの問題提起と解決策の概要
　　　⇒記事はこちら

（４）当方が遭遇した派生開発の問題と解決策の概要
　　　⇒記事はこちら

２部　レポートの詳細－－－－－－－－－－－－－－
（１）派生開発の課題とプロセス改善について
　１．派生開発の課題
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３
　　
　２．派生開発のプラクティス、プロセス
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２（本記事が該当）

（２）派生開発プロセスの内容
　序．品質確保に効果的な派生開発プロセス
　１．対処検討プロセス群
　２．開発プロセス群
　３．検証プロセス群

２部　（２）派生開発のプラクティス、プロセス

前回からの繰り返しになるが、本章では、派生開発で品質確保に効果のあった４つのプラクティスとプロセスを示す。

プラクティスは、品質確保に効果のあった慣行の概要を理解するために、簡潔に表現したタイトルに相当する。タイトルは概要を理解するには適しているが、実際どのようにプロジェクトへ適用するのかは示していない。実務への適用を検討する場合は、４つのプラクティスが組み合わされたプロセスを参照する。４つのプラクティスは、実行するタイミングが異なっている箇所と、互いにオーバラップしている箇所がある。これらの関係がプロセスとして表現されていることで、４つのプラクティスを実務へ適用しやすくなる。

２．１　派生開発のプラクティス（part2）

前回までは、

（１）ドキュメントのトレーサビリティ強化
（２）フロントローディング強化

について見てきた。今回はプラクティスの残りの２つを見ていこう。

（３）ドキュメントのアカウンタビリティ強化

ドキュメントのアカウンタビリティ強化で実現したい課題は、部分理解の制約の中でも、レビューアが設計内容の妥当性を検証することが可能になるようなドキュメントを作成することである。

これを実現するためには、結論に至るまでの検討過程をドキュメントに記載すること、検討過程では検討アイテムについて漏れのない調査を行うこと、の２つが達成されなければならない。

結論に至るまでの検討過程をドキュメントに記載するための具体的な手法、および漏れのない調査を行うための具体的な手法については、派生開発プロセスの手法として後述している（手法は主に、要素分解、バリエーションの検証、マトリクス表記、を用いる）。
続きを読む →

品質確保に効果のあった派生開発プロセスの工夫（その９）

掲題の派生開発プロセスに関する、シリーズ・エントリです。
派生開発の設計品質確保について問題意識を持たれている方は、ご一読頂けると幸いです。
レポートの要約、および背景については第一回を参照ください。

論述対象となるプロジェクト、および開発プロセスの特徴

・組込み系の社会インフラを担うミッションクリティカル・システム。

・信頼性・成熟性について高い品質が求められている。

・稼働直前の総合テストからプロジェクトを引き継ぎ。

・母体システムのドキュメントが不足、母体品質も悪い。

・論述対象の開発プロセスは、主にシステムの欠陥修正（改修）案件に焦点を当てている。

エントリ内容の目次

内容はかなり長くなるため、順を追って述べる。

まずはこのレポートの主旨について述べた後、一般的な派生開発の現状を俯瞰する。その後、派生開発プロセスの１つであるＸＤＤＰと、当方の開発プロセスの工夫についての概要を述べる。

時間のない場合は、ここまでの内容（１部 レポート・サマリー）だけでも、本論述の概要はつかめると考える。その次の２部から、詳細なレポート内容を述べていこうと考えている。

もちろん２部から読み始めても構わない。そちらのほうが、概要説明ではなく詳細な論述を行っているため、理解しやすい可能性がある。１部はサマリーのみであり、詳細情報は把握できないだろう。

（１）このレポートの概要と背景について
　　　⇒記事はこちら

１部　レポート・サマリー－－－－－－－－－－－－
（２）派生開発を巡る現状
　　　⇒Ｐａｒｔ１
　　　⇒Ｐａｒｔ２

（３）ＸＤＤＰでの問題提起と解決策の概要
　　　⇒記事はこちら

（４）当方が遭遇した派生開発の問題と解決策の概要
　　　⇒記事はこちら

２部　レポートの詳細－－－－－－－－－－－－－－
（１）派生開発の課題とプロセス改善について
　１．派生開発の課題
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３
　　
　２．派生開発のプラクティス、プロセス
　　　⇒ｐａｒｔ１（本記事が該当）

（２）派生開発プロセスの内容
　序．品質確保に効果的な派生開発プロセス
　１．対処検討プロセス群
　２．開発プロセス群
　３．検証プロセス群

２部　（２）派生開発のプラクティス、プロセス

本章では、派生開発で品質確保に効果のあった４つのプラクティスとプロセスを示す。またこれらのプラクティスやプロセスでは、特有の成果物をアウトプットする。

プラクティスは、品質確保に効果のあった慣行の概要を理解するために、簡潔に表現したタイトルに相当する。タイトルは概要を理解するには適しているが、実際どのようにプロジェクトへ適用するのかは示していない。実務への適用を検討する場合は、４つのプラクティスが組み合わされたプロセスを参照する。４つのプラクティスは、実行するタイミングが異なっている箇所と、互いにオーバラップしている箇所がある。これらの関係がプロセスとして表現されていることで、４つのプラクティスを実務へ適用しやすくなる。

なお固有の成果物についても、派生開発プロセスの記述で併せて解説している。

２．１　派生開発のプラクティス（part1）

以下に派生開発で品質確保に効果のあった４つのプラクティスを示す。図表2.1-1に概要を示し、その後に１つ１つのプラクティスについて詳述する。

・図表2.1-1　我々の行った派生開発のプラクティス

続きを読む →

品質確保に効果のあった派生開発プロセスの工夫（その８）

掲題の派生開発プロセスに関する、シリーズ・エントリです。
派生開発の設計品質確保について問題意識を持たれている方は、ご一読頂けると幸いです。
レポートの要約、および背景については第一回を参照ください。

論述対象となるプロジェクト、および開発プロセスの特徴

・組込み系の社会インフラを担うミッションクリティカル・システム。

・信頼性・成熟性について高い品質が求められている。

・稼働直前の総合テストからプロジェクトを引き継ぎ。

・母体システムのドキュメントが不足、母体品質も悪い。

・論述対象の開発プロセスは、主にシステムの欠陥修正（改修）案件に焦点を当てている。

エントリ内容の目次

内容はかなり長くなるため、順を追って述べる。

まずはこのレポートの主旨について述べた後、一般的な派生開発の現状を俯瞰する。その後、派生開発プロセスの１つであるＸＤＤＰと、当方の開発プロセスの工夫についての概要を述べる。

時間のない場合は、ここまでの内容（１部 レポート・サマリー）だけでも、本論述の概要はつかめると考える。その次の２部から、詳細なレポート内容を述べていこうと考えている。

もちろん２部から読み始めても構わない。そちらのほうが、概要説明ではなく詳細な論述を行っているため、理解しやすい可能性がある。１部はサマリーのみであり、詳細情報は把握できないだろう。

（１）このレポートの概要と背景について
　　　⇒記事はこちら

１部　レポート・サマリー－－－－－－－－－－－－
（２）派生開発を巡る現状
　　　⇒Ｐａｒｔ１
　　　⇒Ｐａｒｔ２

（３）ＸＤＤＰでの問題提起と解決策の概要
　　　⇒記事はこちら

（４）当方が遭遇した派生開発の問題と解決策の概要
　　　⇒記事はこちら

２部　レポートの詳細－－－－－－－－－－－－－－
（１）派生開発の課題とプロセス改善について
　１．派生開発の課題
　　　⇒ｐａｒｔ１
　　　⇒ｐａｒｔ２
　　　⇒ｐａｒｔ３（今回の記事）
　　
　２．派生開発のプラクティス、プロセス

（２）派生開発プロセスの内容
　序．品質確保に効果的な派生開発プロセス
　１．対処検討プロセス群
　２．開発プロセス群
　３．検証プロセス群

２部　（１）派生開発の課題とプロセス改善について

１．派生開発の課題（part3）

１．３　特に解決が必要だと考えた４つの問題

前回は、当方が派生開発プロジェクトで遭遇した４つの問題のうち２つを述べた。今回は残りの２つを述べる。

（３）対処の結論だけが資料に記載されており、結論を導くまでの設計者の思考過程がわからないため、レビューで対処内容の妥当性の検証が困難で、欠陥の流出が発生した

●問題内容と原因

（１）と（２）の問題に対処することで、ある程度の設計品質を確保できるようになった上で、更に設計品質を高めるために解決が必要となった問題である。本問題の原因は、担当者が検討した結果のみを資料に記載していることである。

欠陥修正の対処方法を、母体ドキュメントやソースコードを調査して、対処検討資料としてまとめるが、その際に、検討した結果のみを記載する傾向が多かった。

もちろん、レビューアが母体システムについて熟知しているのであれば、その結論だけを見て、検討結果の妥当性を判断することもできよう。

しかし部分理解の制約があるため、どうしても検討結果だけを見ても、“なぜその結果が導かれたのか”、“なぜその結果が妥当といえるのか”を判断できないことが多い。
続きを読む →