FC2ブログ

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

派生開発プロセスの工夫(その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 我々の行った派生開発のプラクティス

通番プラクティス概要

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

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

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

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

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

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

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

超上流のスコープ・

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







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


ドキュメントのトレーサビリティ強化で実現したい課題は、1つは既存の工程別の成果物(ドキュメントなど)の間に、適切な追跡可能性を与え、工程間を通じた設計内容の妥当性を確認することである。

2つ目は、工程間で成果物の変更箇所に漏れ・誤りがないことを保証することである。

1つ目の課題への対策は、開発工程に入る前に、対処の検討工程を設け、そこで全工程を横断する形で「対処検討資料」を作成することである。そして、ドキュメントが不足している箇所については、内容を補足するドキュメントを新たに書き起こして補足することである。


そもそもの問題は、母体ドキュメントの基本設計書と詳細設計書で、トレーサビリティが確保できていないことであった。

また、その母体ドキュメントのみを更新していたため、結局ドキュメント間のトレーサビリティが確保できていない状態で設計をしていた。

ドキュメント間(工程間)の断絶をなくすためには、変更要求や欠陥是正要求の対処を検討する場合は、既存のドキュメントを更新するのではなく、「対処検討資料」という独立した資料を書き起こし、そこへ基本設計・詳細設計などの工程を通じた検討内容を記載する。

そしてドキュメントが不足している内容は、リバースエンジニアリングを行って、新たな資料として書き起こす(図表2.1-2を参照)。

・図表2.1-2 ドキュメント間のトレーサビリティ確保

hasei-09-01.png

対策前は、設計時に着目するのは対象となる工程のドキュメントのみとなり、前後のドキュメント間のトレーサビリティが取れていない場合はそのままになっていた。

対策後は、前後の成果物の内容を補完する補足資料を作成することで、上流の設計内容が、正しく下流の設計に落とし込まれていることを保証できるようになる。


なお、作成する補足資料をスペックアウトと呼ぶ。スペックアウトはXDDPにて規定されている、既存のドキュメントでは不足している部分を、ソースコードを調査して作成するドキュメントのことである。本プラクティスでの用途とXDDPでの用途が同じであったため、XDDPの用語をそのまま流用している。

本プラクティスでは検討をさらに一歩進め、工程間での設計の落とし込みを、確実に実現するための資料の作成手法について検討をしている。この手法については派生開発プロセスの節で解説をする(手法は主に、要素分解、バリエーションの検証、マトリクス表記の3つを用いる。詳細は第二部「1.2.2要求仕様の特定」を参照)。

もう1つの課題である、工程間で成果物の変更箇所に漏れ・誤りがないことを保証することへの対策としては、開発工程を実行する前に「要求事項トレーサビリティ・マトリクス」というドキュメントを作成する。「要求事項トレーサビリティ・マトリクス」は、縦軸に要求事項、横軸に工程別に変更を加えた成果物を表形式で記載したものである。

1つの要求事項を達成するために、基本設計工程ではどの成果物を変更したのか、詳細設計工程や製造工程ではどの成果物を変更したのか、といった内容を参照しやすくする(図表2.1-3参照)。

これによって、レビューアが要求事項の実現のために、工程間でどのような変更が加えられたのか、上流の成果物の内容が、下流の成果物に確実に反映されているのかを追跡することが容易になる。

XDDPでも類似するマトリクスを用いて、要求事項のトレーサビリティを確保している。XDDPのマトリクスは変更要求トレーサビリティ・マトリクスと呼び、記載のルールなども図表2.1-3とは異なる部分がある。

・図表2.1-3 要求事項TM第1表

hasei-09-02.png



(2)フロントローディング強化


フロントローディング強化で実現したい課題は、ドキュメントだけではソフトウェアの制約事項を把握できないことから、下流工程に進むにつれて調査工数が増大する手戻りのリスクを軽減することである。

この対策としては、上流工程で検討を行う際は、検討内容が妥当だと判断できるまで下流工程の調査を先取りして行うということである。

派生開発では既存の詳細設計やソースコードが存在しているため、これらの存在を無視して自由に設計をすることはできない。検討した設計内容が、下流の詳細設計やソースコードを踏まえても妥当だと判断できなければ、絵に描いた餅になってしまう。フロントローディングとは、上流工程で下流工程の作業を前倒しで実施し、上流設計力を強化することを言う。


フロントローディングを行うのは、前述の「対処検討資料」を作成している時点である。「対処検討資料」自体が、工程間をまたぐ設計情報を記載する目的で作られているため、フロントローディングを行いやすい。フロントローディングを行いながら、ドキュメント不足箇所のスペックアウトを作成し、対処の設計を行う。

XDDPでは、フロントローディングや、上流工程での設計を重視する記述は見られない。XDDPの開発プロセスでは、一般的な開発工程のフェーズが存在しない(図表2.1-4、図表2.1-5を参照)。

・図表2.1-4 XDDP全体のプロセス

hasei-09-03.png


・図表2.1-5 「1.変更要求を実現する」を詳細化したプロセス

hasei-04-07.png


XDDPで想定しているプロセスは、まず変更要求が発生したら、要求に対応する変更箇所(ソースファイルと関数)を特定する。次に、変更が特定された関数の変更設計書(差分設計書に相当するもの)を記載し、最後にソースコードを修正する、というプロセスである。

上流工程の設計書類については、テストが完了してから更新を行う、ということを提唱している。このため、製造工程に相当するプロセスのみの定義となっている。

ただし、XDDPでは、変更要求に対応する箇所を特定するためにソースコードの調査を行いながら、ドキュメントの記述が不足している部分をスペックアウトする。

つまり、既存のドキュメントもソースコードも両方参照して、変更箇所を特定する、というプロセスになる。結果的にはフロントローディングと同じく、上流工程のドキュメントも下流工程のソースコードも全て参照して対処を検討するため、この点で共通していると考える。


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

関連記事
↓記事が参考になったらクリックお願いします

コメントの投稿

非公開コメント

プロフィール

so-tan

Author:so-tan
佐藤 創。仙台のIT業界でシステム開発に従事しながら、情報処理試験プロマネの受験対策を実施(「このブログについて」参照)。情報処理技術者システムアナリスト、プロジェクトマネージャ、中小企業診断士。日々自分のキャリアや様々な問題に悩みつつも、前向きに問題に立ち向かえる自分でありたいと願う。そんな日々の記録です。
Twitter → @sato__so__
FB → facebook.com/creative.1st.pm

人気の連載エントリ
当ブログではテーマに沿った連載エントリがあります。掘り下げた議論がお好きなら以下からどうぞ。
  1. 受託・派遣型の中小ソフトウェア業が抱える課題
  2. 情報サービス産業の今を俯瞰する
  3. 自分の強みを仕事に活かし仕事を楽しむ
  4. 情報システム派生開発プロセスの工夫
全記事表示リンク

全ての記事を表示する

カテゴリ
最新記事
最新コメント
最新トラックバック
月別アーカイブ
アクセスカウンター
検索フォーム
RSSリンクの表示
リンク
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。