スポンサーサイト 

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

ドキュメントの役割 

ソフトウェア開発において断定しにくい問題としてドキュメントをどうするかということがあります。ドキュメントに関してはおおよそソフトウェア開発を仕事としている人すべてが何らかの形で考えざるを得ない問題です。


日経ソフトウェアに「俊敏な開発のためのプログラミング 悪徳の栄え」というYugui(園田裕貴)さんが書かれているコラムがあります。普段、断定しにくいことに関して一旦断定することによって問題をはっきり見えるようにしようという趣旨のコラムだと個人的には解釈しています。第5回のコラムには以下のように書かれていました。



プログラムの仕様書はテスト・コードとして書くべきです。そうすればより精密に記述できますし、いつでも自動化されたテストによって検証可能になるからです。仕様書を自然言語で書いたとしても、それは「自動実行できないテスト・コード」かそれ以下のものでしかありません。逆にテスト・コードは、その期待に応えられる程度に厳密であるべきなのです。


通常、ソフトウェア開発時に発生する要件には機能要件と非機能要件があります。上記の文で言われているのは機能要件の範疇であることが前提となっています。ただし、任意のソフトウェア開発プロジェクトを対象とした場合、前提条件としてはまだ不十分です。機能要件の中にもテストコードとして表現できるものと出来ないものがあります。特にハードウェアに近いソフトウェア開発においてはその割合は増加します。「指定のポートから1kHzの方形波を出力すること」というごく簡単な機能要件ですらテストコードが書けない場合は普通に経験することができます。


また、以下のようなことも書かれていました。



ソフトウェア開発において真に必要とされる成果物はただ一つ。ソフトウェアそのものです。他の事に時間を費やすのは悪です。


ここでいう「ソフトウェアそのもの」というのが正しく動作するソフトウェアであるということは自明でしょう。そして正しく動作するソフトウェアというのはテストコード等によって検証されたソフトウェアということになります。厳密に表現されたテストコードが自然言語で書かれたドキュメントよりも有効であることは私も全く同意です。しかし、テストコードで書けない機能要件の割合が増えるほどソフトウェアが正しく動作することを検証するためには必要なドキュメントは増えてきます。


ソフトウェア開発におけるドキュメントはソフトウェアが正しく動作することを検証できるために書かれるものと、ソフトウェアがどのようにな構造になっているかを他の人間に理解してもらうためのものに少なくとも役割レベルで分けて扱われるべきです。テストコードもドキュメントも手間という面から見れば同様に必要悪です。関わるプロジェクトにおいてトータルの手間をどれだけ減らせるかという問題意識を持つことが重要だと思います。


 


コメント

コメントの投稿















管理者にだけ表示を許可する

トラックバック

この記事のトラックバックURL
http://ochoo.blog48.fc2.com/tb.php/110-2d221124

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