パスワードを忘れた? アカウント作成
10854179 journal
日記

dotkuwaの日記: なぜ、詳細設計の表現は「後知恵としてなら存在する」と思ったか 1

日記 by dotkuwa

日記「V字モデル」のコメント#2585095で、

#(自分では、「詳細設計」の表現は設計としては(プログラムの上位の存在として
#は)原理的に存在し得ない、後知恵としてなら存在すると思っています。)

と書きました。

詳細設計         単体テスト
   |        |
     プログラミング

で無く、

プログラミング      単体テスト
   |        |
     詳細設計

で有るべきだと言う事です。

なぜそう思ったかを書きます。

---------------------------------------------------------------------

日記「ISO9000とかWBSとか」で、

たぶん、それらの管理対象は、
・プログラムなんかと違って、安定していて、
・そのくせ、きちんとトレサビ出来るだけの細かさもある
“詳細設計の項目”を想定してるのだと思います。

と書きました。

なぜ、詳細設計がプログラミングの上流だと、上記が必要かというと、
・上流なので下流より安定していないといけない
・下流を管理する為には、十分管理対象と対応していないといけない
からです。

その様な表現が有るなら、是非使うべきです。しかし、無いのです。
無いから、別の(緩和された)やり方が必要なのです。

それは、
・管理項目の初期値は、基本設計そのものとする。(別にこれは実際に行われている事)
・管理対象はプログラムそのものにし、プログラムの不安定さは許容できる
 (不安定に追従可能な)管理手法である事を必須とする。
・詳細設定は、後知恵としてプログラミングの下流に置く。
です。

---------------------------------------------------------------------

では、
なぜ、後知恵なら、詳細設計が書けるかと言うと、
・プログラミングの上流で無いので、安定で有る必要が無い
・プログラミングを管理する必要が無いので、プログラムと十分対応している
 必要が無い。
からです。

その結果、(後知恵の)詳細設計は、
・プログラミングで、引っかかった部分を自然言語で列挙する。(秘訣集)
となると思います。

その結果、
・後から入ってきた人がはじめに読むべき文書となる。
・引っかかった部分は重点的にテストしないといけない部分なので、テスト工程
 に役に立つ。
・引っかかった部分は技術的負債になりがちなので、負債の萌芽の一覧となり得る。
という利点が生まれます。

その代わり、
・その文書のみを見て、次回改定の修正内容を決める。
なんて事は不可能になります。ソースの調査が必須となってしまいますが、
昔はそれでやっていた事で、別に古典的が悪くて、非古典的が良いばかりとは
限らないので、問題ありません。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
typodupeerror

身近な人の偉大さは半減する -- あるアレゲ人

読み込み中...