dotkuwaの日記: V字モデル 18
よくソフトウェア開発の基本的モデルとして、V字モデルとか有って、大まかに言うと
要件定義 受入テスト
| |
基本設計 結合テスト
| |
詳細設計 単体テスト
| |
プログラミング
だが、実際は
要件定義 受入テスト
| |
基本設計 結合テスト
| |
プログラミング 単体テスト
| |
詳細設計
が正解なのではないか?
それは、
・要件定義は現実世界を使い、基本設計は基盤ソフトを使い、プログラミングは
応用ソフトを使い試行・検証が可能だが、詳細設計にはExcel・Word・パワポ・
TXT他しかなく、試行・検証出来ない。
(そのことは、ExcelをWordにした所で変わりない。)
・前者だと、単体テストをプログラマがやる理由が無いが、現実問題として、
単体テストはプログラマの仕事にされてしまっている。
・「現行の詳細設計書に今回追加機能を書く欄が無いから書くのはOMITする」とか
よく言われるが、それでは本末転倒。
・プログラミング出来ない人の方が、出来る人より多く、コミットされたソースに
基づき、詳細設計書を適宜更新していく役をし続ける事も仕事として継続可能
で無いか?
です。
V字モデルねえ.... (スコア:0)
要件定義
↓
プログラミング/設計/ユニットテスト/結合しての動作確認
↓ ↓
結合テスト、リグレッションテスト 基本設計/詳細設計書作成
↓
受入テスト
かなあ。
参考: http://web.archive.org/web/20080803072849/www.biwa.ne.jp/~mmura/Softwa... [archive.org]
V字モデルは「机上の空論」って奴だと思う。
プログラミングをやったことのない人が、空想上のプログラミング行程を、
絵に描いただけのもの。実用性/有効性を検証されたものではない。
Re:V字モデルねえ.... (スコア:1)
空論とはいえいろいろな国際規格として出版されていて、今後出る
ソフトウェア関係の規格でも参照する事を強制されるモデルで、
もしV字モデルに問題があるなら、今後出る国際規格はみんな問題
含みになってしまうとか。
基本設計もプログラミングも、「数をこなしていくと、粒のそろった
相異なる質が創発される」為に都合のよい表現がそろっていますが、
詳細設計にはそれが全くないのが問題で、
国際規格なんかだと、詳細設計の分野でも、将来的にはそういう表現が
出来る前提で、フレームワーク的な規格をすでに出版してしまっていて、
身動きが取れない状態の様に見えます。
だから、現実世界の現実の詳細設計といえば、
・要件定義のポンチ絵丸投げ
・要件、業務知識を自分らだけで隠し持ち、そのものずばりを言えば
数語で済むものを、数千に展開し「わかり易い一覧」と称する。
(しかも、展開時に間違いを入れ、その間違いも正になってしまう。)
しか見た事ありません。
もう詳細設計は「後知恵の文書作成」(これだって後続工程や、次回
改定時には大いに役に立つ)であると定義するより無いのでは。
Re: (スコア:0)
> V字モデルは「机上の空論」って奴だと思う。
この考えの元になった部分って、まだ概念も何も無い時代に、現場がどうにかしようとして他分野でやってることとか参考に持ち込んだのですけどねー
まぁ、全部に賛同するわけではないですが、テストのやり方を考えるとき有用な考えのひとつだとは思ってます
Re:V字モデルねえ.... (スコア:1)
そりゃ、テスト(V字モデルで言うと右側)を軸と
して議論すれば、「何が(仕様で)正しいか」に
ついては「終わった」事としてくり込め、「捗る」
かも知れないけど、
それで、自動的に「正しいか」が湧き出して来る
とも思えません。
自分が気にしているのは、左の1番下辺りの事です。
Re: (スコア:0)
単に空論ってところを突っ込んだだけで、そこを議論したわけじゃないんですけどね
下3つの部分に関してはいろいろ議論があるのは理解してます
うちもTDDなので、ある意味大体元の方に沿っているといえば沿っていますし、沿っていないといえば沿っていないわけで
まぁ、全体的に言いたいこともわかるのですが、TDDやってるとやっぱり詳細設計が上になるのかなと感じます
Re:V字モデルねえ.... (スコア:1)
それほど、理解は食い違っていないと思います。
>TDDやってるとやっぱり詳細設計が上
というのは自分にも理解できます。
その上で、
TDDをスムーズに行う為の前提資料としての詳細設計が書けるのは、
難しさが1から1万まで(大きい方が難しい)として、せいぜい1か2でないか、
つまり「詳細設計には(初歩の規模を超えた開発で)都合のよい表現が
無」く、もしプログラミングが詳細設計の下流とするなら、そのパチッと正しく
無い表現を元に、プログラマが試行錯誤を余儀なくされる事になり、
(それをごまかす為に、反復開発だとか言いますが、結局ごまかしで)
TDDをするにせよ、しないにせよ、プログラマの負担が大きくなってしまう。
と言っているのです。
ならば、基本設計を直接プログラミング工程が受け取り、プログラミング工程
内部で、TDDをするにしても、せずに試行錯誤するにしても、プログラムの
表現で結果を出し、
未定部分の無くなった所で、後知恵として、後学の為に詳細設計を書く、
のが合理的だと思うようになった次第です。
#しかし
#本当にTDDという手法は詳細設計を入力として、その上でテストを書き
#駆動しているのでしょうか。現実の開発で。
#TDDをするしないと無関係に、意味のある詳細設計が、実際に出回っている
#とは思えないのですが。
#(自分では、「詳細設計」の表現は設計としては(プログラムの上位の存在として
#は)原理的に存在し得ない、後知恵としてなら存在すると思っています。)
Re: (スコア:0)
テストを先に作るということは、つまり詳細設計相当のことを最初に考えておかなければならないということです
どういう形にするのかという目標を決めるということですから
そこを考えずに反復しても、ただただ無駄を重ねるだけです
# うちを形だけ真似て崩壊してるチームあったなぁ...
あと、うちみたいに非古典的な手法を採用している場合は、V字モデルの横方向の順序は無視できるという話があります
つまり、最終的な関係性だけを示唆しているという話です
うちはXP+TDD+αなので、そもそも順番が滅茶苦茶ですが、最終的な成果物の関係性はそこまでずれてません
途中時点では簡易な表現し
Re:V字モデルねえ.... (スコア:1)
>別コメで指摘しましたが、下から2層目は"プログラム"を"詳細設計"にしたがっているかを確認するものが"単体テスト"という話です
>単体テストでプログラム"を"確認してるなら、関係性についてその層よりプログラミングは下ですよ
この1節で、自説が補強された気がします。
現実の開発で、プログラム自体を検証するのは、結合テストからというのが通例だと思います。
プログラマが単体テストとして検証するのは、プログラミングの“結果”固まった、詳細設計相当の
知識だと思います。
(「詳細設計相当のことを最初に考えてお」くのが禁止的に困難だという認識で、それが固まるのは
プログラミングの後だという想定でですが。)
やっぱり、詳細設計をV字の谷底に据えるのが良いように思います。
#こわい「品証部」の名前を持ち出すのは卑怯です。自分だってテストになったら四の五の言わず
#黙々と協力します。じっさいしている実績があります。今言っているのはV字モデルの左下部分
#の話です。
Re: (スコア:0)
> プログラミングの“結果”固まった、詳細設計相当の知識
なんか微妙に前提がずれてる気がします
詳細設計って関数/メソッドの定義を決める部分まで含んでいる話ですよ
逆に言えば、古典的な手法ではプログラミング工程はそれを含んでおらず、それを決めることはできないという話です
一番下の"プログラミング"といってる部分は、関数内の実装程度の話に限られるということです(なので、単体テストでの確認対象なのです)
そちらは単に詳細設計工程とプログラミング工程が混ざっちゃってるものを、プログラミング工程と言ってるだけの話にしか見えません
このモデルはそういうものをプログ
Re:V字モデルねえ.... (スコア:1)
確かにそこが争点です。
そこというのは、
・詳細設計って関数/メソッドの定義を決める部分まで含んでいる
ところです。
その切り分けだと、あまりに詳細設計側がすかすか(関数/メソッドの切り分けだけしか
無い)で、プログラミング側に負担がかかり、不合理なのでリストラすべきだという話です。
後続工程の為に文書化されるなら、文句は出ないはずです。
SI事業だって赤字基調なんだし、一考に足るとは思います。
Re:V字モデルねえ.... (スコア:1)
あっ、リストラと言っても首切りでは無く、本来の意味のリストラクチャリングです。
#やばい意味になるところだった。
Re:V字モデルねえ.... (スコア:1)
プログラムを監視し、詳細設計をまとめる人間をプログラマーの下位だとして、
単価を下げれば、検証の為の“有効な”目の数も増えて、品証部という所にも
利点はあると思うのですが。
Re: (スコア:0)
むしろスカスカなのは本来のプログラミング工程の方ですよ
処理をどう組み合わせて定義された機能を実現するか、関数内で何を処理するか等、すべて詳細設計工程に定義されている話です
ちゃんとした詳細設計仕様書には、そういうことまで書かれてますし、私は実際それを扱っていたこともあります
このモデルのプログラミング工程という部分には、それに従って関数/メソッドを表現する以上の意味がないのです
そういう定義のモデルを、定義を変更せずに順番入れ替えたので話がおかしくなります
あなたはそれをプログラミングを通して決めてるのですよね?なら、その部分の作業はこのモデ
Re:V字モデルねえ.... (スコア:1)
そのような「ちゃんとした詳細設計仕様書」を
見たことの有るのはあなただけです。
それを以て、全てのソフトウェア開発で、そう
だというのは乱暴です。
全てのソフトウェアでそれを保証してもらえない
のなら、自分にとって意味ない事です。
しかしながら、プログラムでは、動かなければ
ならないという制約から、一定の質が保証され
ます。
大多数の為には現実的解を選ぶべきです。
Re: (スコア:0)
あくまでも、このモデルの定義とあなたの定義が一致していないという話です
モデルを適用するなら、工程の意味を合わせないとそりゃおかしい話になるというだけです
あなたがやってるプログラミングの内容に詳細設計が含まれているだけの話で、私が作った/見たものはあまり重要じゃありません
このモデルを適用すると、あなたの作業は大部分が"詳細設計"と定義されていている作業だというだけの話です
たからこそ、あなたの成果物の判定は単体テストではできないという話でしょう
V字モデル的には(不足/無駄はあるだろうけど)実際そんなにズレていないとかもと思いました
大体、そんな厳密な詳細設計仕様書がコーディングする上で重要だと思うなら、こっちはプロセス変更してませんよ
あと、すべてのやり方に適用できるモデルなんてありませんよ(なるべく対応範囲を広げようという話はありますが)
Vだと弱いと考えている分野もありますし、内容・目的を考えないとです
Re: (スコア:0)
と、言い忘れたので追加
仕様書に何をどこまで書くかまではこのモデルの定義外だったはずです、確か(責任があるよー...程度)
極論として、非常にクリティカルな場合に、徹底的に検証するために余すところ無く書く場合もあるという話です
そこは、このモデルで決めることじゃないはずです...多分
Re:V字モデルねえ.... (スコア:1)
いっその事、TDDが詳細設計を乗っ取ってしまうのも手かと。
テスト設計の書き方に基づく詳細設計なら十分あり得るかと。
Re: (スコア:0)
> ・前者だと、単体テストをプログラマがやる理由が無いが、現実問題として、
> 単体テストはプログラマの仕事にされてしまっている。
あと、このモデルの話って、別にそういう誰がやるものか的な話はしてませんよね?
詳細設計通りかを確認するテストは単体テストだという話はともかく、それを誰がやるという話はあまり本質的ではないですよね?
詳細設計を入力とするコーディングで、その成果物が詳細設計通りであるかを、詳細設計を基に作った担当が単体テストで確認するのはおかしいと?
# 単に誰がやってもいいという話にしかならないと思うのですが...まぁ、効率悪そうですけど