ブログ

サイト管理人のブログです。
このエントリーをはてなブックマークに追加

ブログ一覧

派生開発プロセスの工夫(その10)

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

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

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

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

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

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

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

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

エントリ内容の目次

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

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

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

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

(1)このレポートの概要と背景について
   ⇒記事はこちら

1部 レポート・サマリー------------
(2)派生開発を巡る現状
   ⇒Part1
   ⇒Part2

(3)XDDPでの問題提起と解決策の概要
   ⇒記事はこちら

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

2部 レポートの詳細--------------
(1)派生開発の課題とプロセス改善について
 1.派生開発の課題
   ⇒part1
   ⇒part2
   ⇒part3
  
 2.派生開発のプラクティス、プロセス
   ⇒part1
   ⇒part2(本記事が該当)

(2)派生開発プロセスの内容
 序.品質確保に効果的な派生開発プロセス
 1.対処検討プロセス群
 2.開発プロセス群
 3.検証プロセス群

2部 (2)派生開発のプラクティス、プロセス

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

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

2.1 派生開発のプラクティス(part2)

前回までは、

(1)ドキュメントのトレーサビリティ強化
(2)フロントローディング強化

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

(3)ドキュメントのアカウンタビリティ強化

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

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

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

派生開発プロセスの工夫(その9)

品質確保に効果のあった派生開発プロセスの工夫(その9)

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

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

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

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

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

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

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

エントリ内容の目次

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

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

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

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

(1)このレポートの概要と背景について
   ⇒記事はこちら

1部 レポート・サマリー------------
(2)派生開発を巡る現状
   ⇒Part1
   ⇒Part2

(3)XDDPでの問題提起と解決策の概要
   ⇒記事はこちら

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

2部 レポートの詳細--------------
(1)派生開発の課題とプロセス改善について
 1.派生開発の課題
   ⇒part1
   ⇒part2
   ⇒part3
  
 2.派生開発のプラクティス、プロセス
   ⇒part1(本記事が該当)

(2)派生開発プロセスの内容
 序.品質確保に効果的な派生開発プロセス
 1.対処検討プロセス群
 2.開発プロセス群
 3.検証プロセス群

2部 (2)派生開発のプラクティス、プロセス

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

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

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

2.1 派生開発のプラクティス(part1)

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

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

通番 プラクティス 概要

ドキュメントのトレーサビリティ強化

・全工程の成果物を横串で通した「対処検討資料」を作成する。

・各工程の成果物の変更箇所を「要求事項トレーサビリ
 ティ・マトリクス」で示し、変更箇所を追跡可能にする。

フロントローディング強化

・検討する対処が妥当だと判断できるまで、下流工程の調査を前倒し実施する。

・成果物だけで対処の妥当性を確認しなくてもよく、実シ
 ステムを動かして確認してもよい。

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

・「対処検討資料」には検討の結論だけでなく、結論に至
 るまでの過程もドキュメント化する。

超上流のスコープ・

マネジメント強化

・要求に含まれるスコープを適切にコントロールして、検
 討漏れなく開発を行えるようにする。

(さらに…)

派生開発プロセスの工夫(その8)

品質確保に効果のあった派生開発プロセスの工夫(その8)

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

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

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

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

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

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

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

エントリ内容の目次

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

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

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

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

(1)このレポートの概要と背景について
   ⇒記事はこちら

1部 レポート・サマリー------------
(2)派生開発を巡る現状
   ⇒Part1
   ⇒Part2

(3)XDDPでの問題提起と解決策の概要
   ⇒記事はこちら

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

2部 レポートの詳細--------------
(1)派生開発の課題とプロセス改善について
 1.派生開発の課題
   ⇒part1
   ⇒part2
   ⇒part3(今回の記事)
  
 2.派生開発のプラクティス、プロセス

(2)派生開発プロセスの内容
 序.品質確保に効果的な派生開発プロセス
 1.対処検討プロセス群
 2.開発プロセス群
 3.検証プロセス群

2部 (1)派生開発の課題とプロセス改善について

1.派生開発の課題(part3)

1.3 特に解決が必要だと考えた4つの問題

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

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

●問題内容と原因

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

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

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

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

派生開発プロセスの工夫(その7)

品質確保に効果のあった派生開発プロセスの工夫(その7)

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

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

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

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

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

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

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

エントリ内容の目次

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

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

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

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

(1)このレポートの概要と背景について
   ⇒記事はこちら

1部 レポート・サマリー------------
(2)派生開発を巡る現状
   ⇒Part1
   ⇒Part2

(3)XDDPでの問題提起と解決策の概要
   ⇒記事はこちら

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

2部 レポートの詳細--------------
(1)派生開発の課題とプロセス改善について
 1.派生開発の課題
   ⇒part1
   ⇒part2(今回の記事)
  
 2.派生開発のプラクティス、プロセス

(2)派生開発プロセスの内容
 序.品質確保に効果的な派生開発プロセス
 1.対処検討プロセス群
 2.開発プロセス群
 3.検証プロセス群

2部 (1)派生開発の課題とプロセス改善について

1.派生開発の課題(part2)

1.2 我々のプロジェクトで認識した派生開発の問題

我々の保守プロジェクトでも、前述した派生開発の特徴による問題を認識した。

まず、一般的な派生開発の特徴である、前述の1.~4.が当てはまった。この結果、部分理解の制約を抱えたまま、欠陥修正などの案件をこなすこととなった。

当該保守プロジェクトで採用している開発プロセスは、ウォーターフォール・モデルに従い、方式設計、基本設計、詳細設計、製造、単体テスト、結合テスト、総合テストを行い、各工程間では成果物のレビューを行うものである。前述した派生開発崩しの開発プロセスに該当する(図表1.2-1参照)。

・図表1.2-1 当初採用していた派生開発プロセス

hasei-05-sl06.png

よって、1人プロジェクトになったり、レビューをせずに対処を進めたりするようなことはなかった。

また、関連ドキュメントは変更差分を赤字で記載するルールとしていたため、変更前・変更後の動作差分を把握しやすく、新規開発崩しの問題点の2.に相当する問題は発生しなかった。

ただし、新規開発崩しの問題点の1.に相当する問題は発生した。ドキュメントの変更、例えばシーケンス図にメッセージを1つ追加することが、他の処理にどのように影響を与えるのかは、さらに下流工程に進み、詳細設計やソースコードの調査をしない限り把握することができなかった。

その結果、下流工程に進むにつれ上流工程で検討した内容の考慮漏れが見つかるなどし、手戻りが発生した。

これら当該プロジェクトで発生した問題について図表1.2-2にまとめる。
(さらに…)

派生開発プロセスの工夫(その6)

品質確保に効果のあった派生開発プロセスの工夫(その6)

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

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

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

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

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

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

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

エントリ内容の目次

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

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

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

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

(1)このレポートの概要と背景について
   ⇒記事はこちら

1部 レポート・サマリー------------
(2)派生開発を巡る現状
   ⇒Part1
   ⇒Part2

(3)XDDPでの問題提起と解決策の概要
   ⇒記事はこちら

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

2部 レポートの詳細--------------
(1)派生開発の課題とプロセス改善について
 1.派生開発の課題
   ⇒今回の記事が該当
  
 2.派生開発のプラクティス、プロセス

(2)派生開発プロセスの内容
 序.品質確保に効果的な派生開発プロセス
 1.対処検討プロセス群
 2.開発プロセス群
 3.検証プロセス群

2部 (1)派生開発の課題とプロセス改善について

1.派生開発の課題(part1)

1.1 一般的な派生開発の課題

派生開発とは、母体システムへの機能追加・変更、欠陥是正を行うシステム開発を指す。

母体システムが存在しているという点で、新規開発とは異なる特徴を持っている。派生開発プロセスの1つであるXDDPを提唱する清水吉男氏によると、一般的に考えられる派生開発の特徴には、次のようなものがある。

・図表1.1-1 派生開発の特徴

  1. 別の担当者が開発したソースコードを読む必要がある
  2. ドキュメントが不足していることが多くソースコードの理解が難しい
  3. これまでの改修によって、当初の設計思想が崩れている
  4. 案件ごとの変更量は新規開発に比べて少ないため、開発期間が短い
  5. 変更量が少ないと1人プロジェクトになることがある
  6. 派生開発に適したプロセスが検討されていない(存在しない)

(さらに…)