« 「組込みソフトウェアギルド」への想い | トップページ | 組込みソフトウェア開発者にとっての要求仕様書 »

2011年2月21日 (月)

処理の流れ図(フローチャート等)について、再考

先日、「フローチャート使用に、賛成?反対?」というタイトルで、記事を書きました。
それを見てくださった方から、twitter でこんな意見をもらいました。

『PS工程で使用する一つの手法としてフローチャートを使うのはありと思います。
PS工程で処理の流れを日本語で書いてPGではPSの内容を落とし込むだけです。その作業ができればどんな手法でもいいのかなと思います。』 (tweet原文を引用)

これについて、少し補足しておきましょう。
こちらの会社では、ソフトウェアの開発工程を次のような略称で呼んでいるようです。
 ・SS工程 : システム構造設計
 ・PS工程 : プログラム構造設計
 ・PG工程 : プログラミング
 ・PT工程 : プログラムテスト
 ・IT工程 : 結合テスト
 ・ST工程 : システムテスト
つまり、上記のtweetは、プログラム構造設計の工程で”処理の流れ”を設計書として作成するのには、フローチャートも有用ではないか。ということです。
なるほど、この方の仰る状況もわかります。


設計者と、コーディング以後を受け持つ担当者が異なる場合、しばしばこのような現場が見受けられます。
なぜ、このような現場では、処理の流れを設計書として渡す必要があるのか。
それは、次のようなケースだと考えられます。
 case 1. コーディング以後担当者のスキルが心配
    担当者が、まだアルゴリズムを自作する十分なスキルになっていないため、
    そのままコーディングできるレベルの詳細な処理の流れを設計書として渡す
 case 2. コーディングレビューがしやすいように
    外部へ委託する場合など、コードレベルでの確認が必要な場合
    依頼内容と、成果物(コード)が比較しやすいように、処理の流れを図式化する

しかし、いずれのケースでも、作成した設計書(流れ図)が使われるのは、PT工程まででしょう。その後の工程や、後の運用・保守においては、参照されることはないのではないでしょうか。

フローチャートなどで、詳細な設計書(処理の流れ図)を作成する場合、「それを作成する効果」 を、チーム内で共有しましょう。
それが使われる理由を知らずして、ただ決まりだから... で作成していては、作成する側は疲弊してしまい、受け取る側もコードへの変換者のままで成長が見られない、と思います。
今の組織の状況と、処理の流れ図を作成する意図を、皆で理解することが大切です。
そうすることで、組織として成長し、開発現場の改善への繋がることになるからです。


今回も最後に注意事項。
フローチャートのような処理の流れ図を使う場合でも、次のドキュメントは別途必要です。
 (1) より広い範囲の構造が分かる設計図
    その部分が、全体の中の何処に位置し、他とどのような関係を持つのか がわかるもの。
    これは、設計を管理するうえで必須です。
    トップダウンで設計する場合なら、本来こちらがあり、小さな範囲の流れ図が書かれるべきです。
 (2) 担当範囲の仕様を示したもの
    流れ図では、具体的なアルゴリズムしか示せず、その部分の仕様は表現できません。
      何が入出力であり、どのような機能を実現するか。
    その部分についての仕様を、明確に定義しておきましょう。

(前回からの繰り返しになりますが...)
フローチャートなどの処理の流れ図は、その性質をしり、適材・適所、適宜、使用して欲しいものです。

「社内の決まりだから...」という事だけで、ひたすら労力を使うようなことがないように、この点は節にお願いしたいものです。

※ 関連記事: Interface 2011年2月号

« 「組込みソフトウェアギルド」への想い | トップページ | 組込みソフトウェア開発者にとっての要求仕様書 »

ソフトウェア開発」カテゴリの記事

Interface記事」カテゴリの記事

コメント

コメントを書く

(ウェブ上には掲載しません)

トラックバック


この記事へのトラックバック一覧です: 処理の流れ図(フローチャート等)について、再考:

« 「組込みソフトウェアギルド」への想い | トップページ | 組込みソフトウェア開発者にとっての要求仕様書 »