FC2ブログ

スポンサーサイト

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

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



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


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

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

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

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

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

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

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



エントリ内容の目次


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

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

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

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

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

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

(3)XDDPでの問題提起と解決策の概要
   ⇒本記事が該当

(4)当方が遭遇した派生開発の問題と解決策の概要

2部 レポートの詳細--------------
(5)レポート内容





(3)XDDPでの問題提起と解決策の概要


前回までに派生開発の技術面、プロジェクト面の特徴を見てきた。
その結果、開発期間が短い、品質が新規開発と比較して悪い、といったような状況が確認できた。

今回は、派生開発の1つであるXDDPでは、どのような問題点を認識し、どのような解決策を提案しているのかを概観する。なおXDDPの内容については当方の理解の範囲内で概説するため、詳細は異なっている部分もあると思う。この点は書籍等で確認をして頂きたいと考える。

※スライドをいくつか見ながら概説をする。スライドをまとめたものは、本エントリの末尾からダウンロード可能。


1.XDDPの概要


清水氏が提唱しているXDDPの概要。派生開発推進協議会のサイトを参照してもらえると、より詳細な情報が得られる。
派生開発推進協議会はこちらから

hasei-04-01.png


2.XDDPで想定する問題点


XDDPで想定する、現状の派生開発の問題・課題をリストアップする。

hasei-04-02.png

結果的に母体システムを十分に理解することができないため、母体への影響箇所の把握が漏れてしまう、ということが品質不良の根本原因だとしている。

次に、XDDPで想定している現状の派生開発プロセスには何があるのかを見ていこう。





3.XDDPで想定している現状の派生開発プロセス


XDDPで想定している現状の派生開発を示す。「現状の」ということは、問題が含まれている開発プロセスであることを示す。

・開発プロセスがないパターン

XDDPで想定している、現状の派生開発プロセスの1つがこれだ。

hasei-04-03.png

これは、変更要求(文書または口頭などでの変更依頼と考えてよい)が到来したら、ソースをいきなり読み始め、変更になりそうなソースを見つけ次第にどんどん修正してしまう、というプロセス(といえるのかどうか)である。

変更になりそうなソースが見当たらなくなるか、もしくは時間切れ?になると、そこで変更は終了というわけである。

あまりにもお粗末なプロセスであり、こんなプロセスで開発を行っている組織があるのか疑問を抱いてしまうが、清水氏がコンサルティングしてきた結果について述べているということは、おそらくこのようなプロセスの組織が多いのだろう。


このプロセスを採用することの問題点は以下である。
このようなプロセスで開発をしていたら、ソースの変更理由をレビューで第三者が把握することも難しくなり、有効な指摘も行いにくくなる。

hasei-04-04.png

そもそも変更内容の妥当性はどのプロセスで保証されるのであろうか。
当方が見る限りでは、これは本当に最悪パターンである。

このような組織に対してであれば、XDDPを採用するまでもなく、もう少しまともな何かしらのプロセスを採用しただけでも品質は向上しそうだと思ってしまう。


・新規開発崩し

もう1つの現状の派生開発プロセスがこの「新規開発崩し」である。

hasei-04-05.png

当方の感覚では、このような新規開発(ウォーターフォール)の開発プロセスを採用している組織がほとんどなのではないかと考える。当方も、今回の派生開発プロジェクトを行うまでは、この「新規開発崩し」で行っていた。


このプロセスを採用することでの悪影響は以下である。悪影響については、2点ほど当方の考えを追記している。

hasei-04-06.png

XDDPの書籍には明記されていないが、当方が新規開発崩しを採用することの最も悪い影響は、新規開発のように工程を上流から区切って開発を行うことだと考えている。

工程を区切って派生開発を行うと、上流工程では下流工程の成果物(例えば詳細設計書やソースコードなど)をインプットしないままに設計を行うことになる。

しかし派生開発は、母体がすでにソースコードまで存在しており、ソースコードの内容を理解しないままに勝手気ままに設計をすることは、不要な手戻りを発生させる。


もちろん、ドキュメントに全ての詳細事項が記載されていれば問題ないケースもあろうが、実際には母体システムの既存ドキュメントの内容は不十分である。その結果、設計書とソースコードの内容が一致していない、といったことが往々にして発生する。

こうした場合、誤ったドキュメントをベースに開発・設計したとしても、製造工程でソースコードを参照したときに、これまでの設計内容は妥当ではないことが判明してしまう。これは大変に大きな手戻りになってしまう。



4.XDDPで提唱する派生開発プロセス


これがXDDPで提唱する開発プロセスである。

hasei-04-07.png


PFDという手法で記載されているが、○がプロセスでそれ以外が成果物である、というだけで特に難しい内容ではない。

プロセスにおいて特徴的なのは、新規開発では当然に存在する開発工程がないことだ。


XDDPで想定しているプロセスは、まず変更要求が発生したら、変更要求をブレイクダウンし、変更仕様をまとめ変更要求仕様書として記載する。

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


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

これは、前述した現状の派生開発のプロセス(開発プロセスがないケース)に似ている。しかし、いきなりソースコードを変更するのではなく、変更要求をしっかりと対応する仕様にブレイクダウンして要求分析をし、そのブレイクダウンされた変更仕様の1つ1つに対して、ソースコードのどこが変更になるのかを調査する。

この時には、ソースコードはもちろん既存ドキュメントも含めて参照するため、開発工程の上流から下流までの全ての成果物を一緒くたに参照することになる。

結果的には、開発工程で区切らないプロセスになっており、前述した当方が最も悪影響を及ぼすと考えている問題にも対応できている。


5.XDDPで定める成果物


成果物は最低限のものだけを規定している。成果物をしっかりと作成することで、レビューでの指摘が行いやすくなり、品質を確保できることを狙っている。

hasei-04-08.png

hasei-04-09.png



6.XDDPを適用することでの効果


これらのプロセスを採用した結果目指す効果の概要をまとめた。

hasei-04-10.png



この結果、現状の開発プロセス及び新規開発崩しを採用することで発生していた問題について解消することが可能になる。現状の派生開発プロセスを用いることでの問題点について、解決策をもたらしていることがわかる。

hasei-04-11.png

hasei-04-12.png



7.XDDPに関する疑問点


最後にXDDPの成果物、プロセスなどについて疑問点をまとめてみた。

まずXDDPの成果物に関連した疑問点をリストアップし、自分で調査できる範囲で調査結果をまとめた。

hasei-04-13.png


同様にXDDPのプロセスに関連した疑問点をリストアップし、自分で調査した結果である。これらのうちのいくつかは、現時点では疑問が解消されているが、資料の作成当時の内容をベースに記載している。

hasei-04-14.png

今後も周辺領域の研究が進められることで、より適用範囲が広がっていくと思う。



以上がXDDPの概要である。

簡単に言うと、

  1. 変更要求に対して漏れのない要求分析を行う(変更要求から変更仕様へのブレイクダウン)。

  2. 変更仕様の1つ1つについて、どのソースのどこを変更するのかを、追跡可能な状態でドキュメント化する。

  3. ドキュメント化によってレビューでの指摘や気付きを誘発しやすくなり、品質確保が可能になる。

といったことを実現するためのプロセスであり、かつ作成する成果物のフォーマットなどにも細かな配慮や工夫が詰まっており、特にレビューによって設計誤りや漏れに気付きやすくする効果を狙っている。


次回は、当方の担当した派生開発プロジェクトで遭遇した問題と、解決策の概要について見ていく。


今回紹介したスライドをまとめてダウンロードする場合はこちらから。
xddp_overview_vsn.0.1.pdf(724KB)



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

コメントの投稿

非公開コメント

プロフィール

so-tan

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

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

全ての記事を表示する

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