dotkuwaの日記: なぜ、詳細設計の表現は「後知恵としてなら存在する」と思ったか 1
日記「V字モデル」のコメント#2585095で、
#(自分では、「詳細設計」の表現は設計としては(プログラムの上位の存在として
#は)原理的に存在し得ない、後知恵としてなら存在すると思っています。)
と書きました。
詳細設計 単体テスト
| |
プログラミング
で無く、
プログラミング 単体テスト
| |
詳細設計
で有るべきだと言う事です。
なぜそう思ったかを書きます。
---------------------------------------------------------------------
日記「ISO9000とかWBSとか」で、
たぶん、それらの管理対象は、
・プログラムなんかと違って、安定していて、
・そのくせ、きちんとトレサビ出来るだけの細かさもある
“詳細設計の項目”を想定してるのだと思います。
と書きました。
なぜ、詳細設計がプログラミングの上流だと、上記が必要かというと、
・上流なので下流より安定していないといけない
・下流を管理する為には、十分管理対象と対応していないといけない
からです。
その様な表現が有るなら、是非使うべきです。しかし、無いのです。
無いから、別の(緩和された)やり方が必要なのです。
それは、
・管理項目の初期値は、基本設計そのものとする。(別にこれは実際に行われている事)
・管理対象はプログラムそのものにし、プログラムの不安定さは許容できる
(不安定に追従可能な)管理手法である事を必須とする。
・詳細設定は、後知恵としてプログラミングの下流に置く。
です。
---------------------------------------------------------------------
では、
なぜ、後知恵なら、詳細設計が書けるかと言うと、
・プログラミングの上流で無いので、安定で有る必要が無い
・プログラミングを管理する必要が無いので、プログラムと十分対応している
必要が無い。
からです。
その結果、(後知恵の)詳細設計は、
・プログラミングで、引っかかった部分を自然言語で列挙する。(秘訣集)
となると思います。
その結果、
・後から入ってきた人がはじめに読むべき文書となる。
・引っかかった部分は重点的にテストしないといけない部分なので、テスト工程
に役に立つ。
・引っかかった部分は技術的負債になりがちなので、負債の萌芽の一覧となり得る。
という利点が生まれます。
その代わり、
・その文書のみを見て、次回改定の修正内容を決める。
なんて事は不可能になります。ソースの調査が必須となってしまいますが、
昔はそれでやっていた事で、別に古典的が悪くて、非古典的が良いばかりとは
限らないので、問題ありません。
ソースから仕様書起こすソフトウェア (スコア:0)
ソースから仕様書起こすソフトって昔からいろいろありますよね。
富士通、COBOLなどによる既存アプリの資産を日本語に変換するサービス
http://news.mynavi.jp/news/2012/08/16/006/ [mynavi.jp]
富士通ミドルウェアの仕様書工房
http://jp.fujitsu.com/solutions/sdas/document/events/java-tech-conf200... [fujitsu.com]
NTTデータ、既存システムのソースコードから設計書を自動生成するサービスを開始
http://it.srad.jp/story/13/04/26/0945211/NTT%E3%83%87%E3%83%BC%E3%82%B... [srad.jp]
SDEMというV字モデルを推進している富士通ですら、ソースから仕様書起こすソフトウェア売っていたのだから、V字モデルも万能じゃないって事なのでしょう。