「V字モデル」記事へのコメント

V字モデルねえ．．．．

[Anonymous Coward]

要件定義
    ↓
プログラミング／設計／ユニットテスト／結合しての動作確認
    ↓　　　　　　　　　 　　　　　　　　　　　　　　　　　 ↓
結合テスト、リグレッションテスト　　　　基本設計／詳細設計書作成
    ↓
受入テスト

かなあ。
参考： http://web.archive.org/web/20080803072849/www.biwa.ne.jp/~mmura/Softwa... [archive.org]

Re:

[Anonymous Coward]

> V字モデルは「机上の空論」って奴だと思う。

この考えの元になった部分って、まだ概念も何も無い時代に、現場がどうにかしようとして他分野でやってることとか参考に持ち込んだのですけどねー
まぁ、全部に賛同するわけではないですが、テストのやり方を考えるとき有用な考えのひとつだとは思ってます

Re:

[dotkuwa (9387)]

そりゃ、テスト（V字モデルで言うと右側）を軸と
して議論すれば、「何が（仕様で）正しいか」に
ついては「終わった」事としてくり込め、「捗る」
かも知れないけど、

それで、自動的に「正しいか」が湧き出して来る
とも思えません。

自分が気にしているのは、左の1番下辺りの事です。

Re:

[Anonymous Coward]

単に空論ってところを突っ込んだだけで、そこを議論したわけじゃないんですけどね
下3つの部分に関してはいろいろ議論があるのは理解してます

うちもTDDなので、ある意味大体元の方に沿っているといえば沿っていますし、沿っていないといえば沿っていないわけで
まぁ、全体的に言いたいこともわかるのですが、TDDやってるとやっぱり詳細設計が上になるのかなと感じます

Re:

[dotkuwa (9387)]

それほど、理解は食い違っていないと思います。

＞TDDやってるとやっぱり詳細設計が上

というのは自分にも理解できます。

その上で、

TDDをスムーズに行う為の前提資料としての詳細設計が書けるのは、
難しさが1から1万まで（大きい方が難しい）として、せいぜい1か2でないか、

つまり「詳細設計には（初歩の規模を超えた開発で）都合のよい表現が
無」く、もしプログラミングが詳細設計の下流とするなら、そのパチッと正しく
無い表現を元に、プログラマが試行錯誤を余儀なくされる事になり、
（それをごまかす為に、反復開発だとか言いますが、結局ごまかしで）

TDDをするにせよ、しないにせよ、プログラマの負担が

Re:

[Anonymous Coward]

テストを先に作るということは、つまり詳細設計相当のことを最初に考えておかなければならないということです
どういう形にするのかという目標を決めるということですから
そこを考えずに反復しても、ただただ無駄を重ねるだけです
# うちを形だけ真似て崩壊してるチームあったなぁ...

あと、うちみたいに非古典的な手法を採用している場合は、V字モデルの横方向の順序は無視できるという話があります
つまり、最終的な関係性だけを示唆しているという話です
うちはXP+TDD+αなので、そもそも順番が滅茶苦茶ですが、最終的な成果物の関係性はそこまでずれてません
途中時点では簡易な表現し

Re:V字モデルねえ．．．．

[dotkuwa (9387)]

＞別コメで指摘しましたが、下から2層目は"プログラム"を"詳細設計"にしたがっているかを確認するものが"単体テスト"という話です
＞単体テストでプログラム"を"確認してるなら、関係性についてその層よりプログラミングは下ですよ

この1節で、自説が補強された気がします。

現実の開発で、プログラム自体を検証するのは、結合テストからというのが通例だと思います。
プログラマが単体テストとして検証するのは、プログラミングの“結果”固まった、詳細設計相当の
知識だと思います。
（「詳細設計相当のことを最初に考えてお」くのが禁止的に困難だという認識で、それが固まるのは
プログラミングの後だという想定でですが。）

やっぱり、詳細設計をV字の谷底に据えるのが良いように思います。

＃こわい「品証部」の名前を持ち出すのは卑怯です。自分だってテストになったら四の五の言わず
＃黙々と協力します。じっさいしている実績があります。今言っているのはV字モデルの左下部分
＃の話です。

Re:

[Anonymous Coward]

> プログラミングの“結果”固まった、詳細設計相当の知識

なんか微妙に前提がずれてる気がします
詳細設計って関数/メソッドの定義を決める部分まで含んでいる話ですよ
逆に言えば、古典的な手法ではプログラミング工程はそれを含んでおらず、それを決めることはできないという話です
一番下の"プログラミング"といってる部分は、関数内の実装程度の話に限られるということです(なので、単体テストでの確認対象なのです)

そちらは単に詳細設計工程とプログラミング工程が混ざっちゃってるものを、プログラミング工程と言ってるだけの話にしか見えません
このモデルはそういうものをプログ

Re:V字モデルねえ．．．．

[dotkuwa (9387)]

確かにそこが争点です。

そこというのは、

・詳細設計って関数/メソッドの定義を決める部分まで含んでいる

ところです。

その切り分けだと、あまりに詳細設計側がすかすか（関数/メソッドの切り分けだけしか
無い）で、プログラミング側に負担がかかり、不合理なのでリストラすべきだという話です。
後続工程の為に文書化されるなら、文句は出ないはずです。

SI事業だって赤字基調なんだし、一考に足るとは思います。

Re:V字モデルねえ．．．．

[dotkuwa (9387)]

あっ、リストラと言っても首切りでは無く、本来の意味のリストラクチャリングです。

＃やばい意味になるところだった。

Re:V字モデルねえ．．．．

[dotkuwa (9387)]

プログラムを監視し、詳細設計をまとめる人間をプログラマーの下位だとして、
単価を下げれば、検証の為の“有効な”目の数も増えて、品証部という所にも
利点はあると思うのですが。

Re:

[Anonymous Coward]

むしろスカスカなのは本来のプログラミング工程の方ですよ
処理をどう組み合わせて定義された機能を実現するか、関数内で何を処理するか等、すべて詳細設計工程に定義されている話です
ちゃんとした詳細設計仕様書には、そういうことまで書かれてますし、私は実際それを扱っていたこともあります
このモデルのプログラミング工程という部分には、それに従って関数/メソッドを表現する以上の意味がないのです
そういう定義のモデルを、定義を変更せずに順番入れ替えたので話がおかしくなります

あなたはそれをプログラミングを通して決めてるのですよね？なら、その部分の作業はこのモデ

Re:V字モデルねえ．．．．

[dotkuwa (9387)]

そのような「ちゃんとした詳細設計仕様書」を
見たことの有るのはあなただけです。

それを以て、全てのソフトウェア開発で、そう
だというのは乱暴です。

全てのソフトウェアでそれを保証してもらえない
のなら、自分にとって意味ない事です。

しかしながら、プログラムでは、動かなければ
ならないという制約から、一定の質が保証され
ます。

大多数の為には現実的解を選ぶべきです。

Re:

[Anonymous Coward]

あくまでも、このモデルの定義とあなたの定義が一致していないという話です
モデルを適用するなら、工程の意味を合わせないとそりゃおかしい話になるというだけです

あなたがやってるプログラミングの内容に詳細設計が含まれているだけの話で、私が作った/見たものはあまり重要じゃありません
このモデルを適用すると、あなたの作業は大部分が"詳細設計"と定義されていている作業だというだけの話です
たからこそ、あなたの成果物の判定は単体テストではできないという話でしょう
V字モデル的には(不足/無駄はあるだろうけど)実際そんなにズレていないとかもと思いました

大体、そんな厳密な詳細設計仕様書がコーディングする上で重要だと思うなら、こっちはプロセス変更してませんよ
あと、すべてのやり方に適用できるモデルなんてありませんよ(なるべく対応範囲を広げようという話はありますが)
Vだと弱いと考えている分野もありますし、内容・目的を考えないとです

Re:

[Anonymous Coward]

と、言い忘れたので追加

仕様書に何をどこまで書くかまではこのモデルの定義外だったはずです、確か(責任があるよー...程度)
極論として、非常にクリティカルな場合に、徹底的に検証するために余すところ無く書く場合もあるという話です
そこは、このモデルで決めることじゃないはずです...多分