- 1 名前：仕様書無しさん mailto:sage [2011/11/26(土) 11:26:56.24 ]
- 外部だの内部だの基本だの詳細だの…
曖昧な基準で書かれた、いろいろな名前で呼ばれてて
「これってどうなの？」「意味あるの？」といった物に出くわす事も少なくない
しかし、純粋にプログラミングだけをして食べていくことは、昨今じゃ難しく
避けて通れない、否が応でも作る機会に出くわしてしまう、そんなドキュメントたち
設計書や仕様書についても、マ視点で語ろうぜ
・自分のなかでの仕様書/設計書の呼び方と分け方
・成功談、失敗談
・仕様書/設計書は何を使って作成する？(Word/Excel/HTML/手書き！)
・仕様書/設計書に含める図の作成方法や使っているツール紹介
・炎上プロジェクトでみた(よくない意味で)素晴らしい仕様書/設計書
・そもそも仕様書/設計書って本当に必要なの？
・こんな仕様書/設計書は、ぶっちゃけアリ？ナシ？
などなど、設計書にまつわる話題を募集
- 652 名前：仕様書無しさん mailto:sage [2012/06/23(土) 23:39:07.55 ]
- クソ仕様書から正確な仕様書を書く作業から始まる
- 653 名前：仕様書無しさん mailto:sage [2012/06/24(日) 01:08:52.21 ]
- 昔からバグのまったく無いプログラムは作れないといわれているが、
実際には、バグのまったく無いプログラムは見たことあるが、
バグのまったく無い仕様書は見たこと無いw
- 654 名前：仕様書無しさん mailto:sage [2012/06/24(日) 01:23:50.99 ]
- >>652
地味にそういう事からやるほうがいいんじゃね
余裕があるならコーディングしながら矛盾点を洗い出していくとか
- 655 名前：仕様書無しさん mailto:sage [2012/06/24(日) 03:30:05.08 ]
- >>652
だいたいそれやってるけど、必ず既存のバグ見つかってアレ
- 656 名前：仕様書無しさん mailto:sage [2012/06/24(日) 10:19:20.59 ]
- >>655
たしかにそうだけど、それは仕様書再作成作業による机上バグ摘出という成果であると
前向きに考えているよ
- 657 名前：仕様書無しさん mailto:sage [2012/06/24(日) 14:32:24.06 ]
- >>656
コンパイラができること（エラーチェック）を脳内でヤルわけですね？
- 658 名前：仕様書無しさん mailto:sage [2012/06/24(日) 14:41:26.41 ]
- コンパイルできることと、バグが無いことは違うよ？
- 659 名前：仕様書無しさん mailto:sage [2012/06/24(日) 14:49:36.03 ]
- テストがあることと
バグがないことも違うよ。
- 660 名前：仕様書無しさん mailto:sage [2012/06/24(日) 15:39:55.23 ]
- >>657
何を言いたいのか意味不明なんだが、もしかすると>>657はコードと
一対一に対応するような設計書(仕様書???)を書いているのか？
それとも>>657のコンパイラとは、
Z/VDM/CSPのような形式的仕様記述言語の検証系を指しているのかな？
まさかコンパイラが(構文エラー以外の)論理的なバグまで検出できると本気で思っているの？
訳が分からんわwww
- 661 名前：仕様書無しさん mailto:sage [2012/06/24(日) 15:51:32.09 ]
- >>660
”コンパイラができること” ってちゃんと書いてますよね？
コンパイラができないことが、コンパイラできるなんて
どうしてそんな変なことを言い出してるの？
- 662 名前：仕様書無しさん mailto:sage [2012/06/24(日) 16:17:42.24 ]
- >>661
>”コンパイラができること” ってちゃんと書いてますよね？
>>657では、「ちゃんと」書いているつもりなのか？
自分は、”コンパイラができることを” とは構文エラー検査であり、
"脳内でヤル" とは(>>656の)仕様書再作成作業のことだと解釈し、
「構文エラー検査を仕様書作成作業内でヤル」という>>657の発想が意味不明だと>>660で書いた
もしもこの解釈が間違っていたのなら教えて下さいませ
あと、仕様書再作成作業の前に全コードをコンパイル通過させておくのは、常識だと考えているよ
- 663 名前：仕様書無しさん mailto:sage [2012/06/24(日) 19:37:25.95 ]
- コンパル時にエラー出ても読まない、わからない人が仕様書書くことがあるからね
- 664 名前：仕様書無しさん mailto:sage [2012/06/24(日) 19:38:10.50 ]
- ×コンパル時
○コンパイル時
- 665 名前：仕様書無しさん mailto:sage [2012/06/24(日) 20:25:56.27 ]
- こんぱそ時
- 666 名前：仕様書無しさん mailto:sage [2012/06/24(日) 23:39:28.20 ]
- >>663
それって>>657のことかしら？
- 667 名前：仕様書無しさん mailto:sage [2012/06/24(日) 23:46:19.00 ]
- リアル会社でそういう人がいたんですよ
コンパイルのエラーって何？
って、感じの人が
- 668 名前：仕様書無しさん mailto:sage [2012/06/25(月) 06:24:49.76 ]
- またまたご冗談を
- 669 名前：仕様書無しさん mailto:sage [2012/06/25(月) 06:43:59.74 ]
- PC触ったことない、持ってないようなのも
口がうまければ普通に入ってくる業界だからな
- 670 名前：仕様書無しさん mailto:sage [2012/06/25(月) 20:56:34.12 ]
- 20世紀末ごろのエラーメッセージが英語の頃はなにそれが普通だった
エラーメッセージが日本語化されてもなにそれは状態な人がいっぱいいそうだけど
- 671 名前：仕様書無しさん mailto:sage [2012/06/26(火) 02:43:52.29 ]
- エラー出た、で思考停止する馬鹿は結構いるぞ
まじ辞めればいいと思うわ…
- 672 名前：仕様書無しさん mailto:sage [2012/06/30(土) 03:05:17.20 ]
- 工数稼ぐためにそういう人達が完成図書みたいなの作ってるんかね
- 673 名前：仕様書無しさん mailto:sage [2012/06/30(土) 21:27:28.45 ]
- >>671
赤バッテンのアイコンでエラー表示するとパニクって思考停止するヤツが
後を絶たないので黄色の警告アイコンにしてやったwwww
- 674 名前：仕様書無しさん mailto:sage [2012/06/30(土) 21:32:56.59 ]
- シイタケ？
- 675 名前：仕様書無しさん mailto:sage [2012/07/03(火) 02:36:38.73 ]
- ｢我々は高い技術力を持っている｣｢業務ソフトを開発した経験がないとわからないだろ｣が口癖のガイキチは、
グローバル変数とローカル変数の違いもわからず、
それこそプログラマ1年目でも小学生でも簡単に作れるようなサンプルプログラムを作らせてみたら
思った通り一目で動作しないとわかるものを出して来やがった。
- 676 名前：仕様書無しさん mailto:sage [2012/07/03(火) 20:31:28.12 ]
- 資料だって言ってる割には、時代についていってないような書き方だけが伝承されてるだけだったりして
- 677 名前：仕様書無しさん mailto:sage [2012/07/13(金) 01:47:24.24 ]
- ＞仕様書再作成作業の前に全コードをコンパイル通過させておくのは、常識
何言ってんだこいつ。
- 678 名前：仕様書無しさん mailto:sage [2012/08/22(水) 00:52:30.02 ]
- メンテナンス出来ない/しにくい仕様書はいらんな〜
- 679 名前：仕様書無しさん [2012/08/23(木) 17:15:51.25 ]
- うちの画面仕様書びっくりするほど横長だった。UXGA×2枚、SXGA×1枚でおさまりきらない。
書くのも大変だけど見るというか読むのも大変そうだ。
- 680 名前：仕様書無しさん mailto:sage [2012/08/23(木) 19:05:10.57 ]
- まるでWindows8のスタート画面みたいだな。
- 681 名前：仕様書無しさん [2012/08/24(金) 00:27:36.99 ]
- 今日気がついた。仕様書を書いてるときってかなりコピペしてる。
似たような記述が仕様書にいっぱいちりばめられてる。
仕様変更時にこれを全部メンテする自信はまったくない。
- 682 名前：仕様書無しさん mailto:sage [2012/08/24(金) 13:14:29.14 ]
- ソースコードの解読が容易な案件は仕様書なくていい。
糞みたいなソースコードの案件は、仕様書も糞。
仕様書いらね。
- 683 名前：仕様書無しさん mailto:sage [2012/08/25(土) 00:01:23.36 ]
- >>682
ソースコードの解読が容易だが
バグが含まれているコードの場合はどうなるんだ？
- 684 名前：仕様書無しさん [2012/08/28(火) 18:59:19.16 ]
- >>678
メンテしやすい仕様書ってどうやったらできるんだろう？
- 685 名前：仕様書無しさん mailto:sage [2012/08/28(火) 19:46:59.05 ]
- 使うためのマニュアルをメンテとかならわかるんだけど
プログラムのプの字もわからんでもやれる虎の巻みたいなのが欲しいだけなのかな
- 686 名前：仕様書無しさん mailto:sage [2012/08/28(火) 20:12:03.95 ]
- 仕様書は上司と実際に作った俺の頭の中にしかなく、
しかも上司が実装可能と考えていた仕様はほとんど実装不可能で、大幅に改変せざるを得なかった。
にもかかわらず上司の初期構想の仕様書しかなく、俺にはそんな時間はなかったため
引き継いだ奴らが実装をわからずメンテナンスしたためにとんでもないスパゲティに。
コメント文で仕様書の実装は不可能なのでこう実装したと全て書いたんだけどなあ。
- 687 名前：仕様書無しさん [2012/08/30(木) 09:18:06.05 ]
- >>685
仕様変更あったときに楽に間違いなく書き直せる仕様書であってほしいってことじゃね？
- 688 名前：仕様書無しさん mailto:sage [2012/08/30(木) 16:05:00.50 ]
- >>687
仕様書直したら、ソースが直ると、思ってるとか？
- 689 名前：仕様書無しさん mailto:sage [2012/08/30(木) 16:07:07.41 ]
- 回路図方面の解説書とか見たことないなあ
見れるのは図面とやれることが書いてあるもんぐらい
- 690 名前：仕様書無しさん [2012/08/30(木) 16:12:05.41 ]
- ソース直してると仕様の漏れが山ほど見つかる。
フィードバックするのもめんどくさいぐらいに。
- 691 名前：仕様書無しさん mailto:sage [2012/08/30(木) 19:01:44.84 ]
- >>684
う〜ん、難しいんだよね。
いま社内で仕様書の標準/統一化を進めてるんだけど、一向に進まないし…
確実に統一できそうなものは目次、表紙だけだわw
そもそも仕様書って誰のためのもの？プログラマ？ユーザー？上司？
ここをまず明確にすべきだと思うな〜
それによって、どう書いていった方がメンテナンスしやすいかが定まってくると思う
けど、これも難しいんだよね〜。あぁ死にたい。
- 692 名前：仕様書無しさん mailto:sage [2012/08/30(木) 19:48:40.68 ]
- ソースの中身を検証できるようにするほうがよくねえか？
客、上司に媚びうる資料でもうけようってのならわかるけど
- 693 名前：仕様書無しさん mailto:sage [2012/08/30(木) 20:15:15.09 ]
- >>691
> そもそも仕様書って誰のためのもの？プログラマ？ユーザー？上司？
一つで済まそうとせずに、それぞれ書き分けたほうがいい。
- 694 名前：仕様書無しさん [2012/08/30(木) 20:49:05.16 ]
- 書き分けるとそれぞれの内容が整合しなくてどこかでモメることになりそうな悪寒
- 695 名前：仕様書無しさん mailto:sage [2012/08/30(木) 20:50:24.03 ]
- 分けるにしても
どう分けるか考えんと
- 696 名前：仕様書無しさん mailto:sage [2012/08/30(木) 22:25:35.19 ]
- >>691
＞そもそも仕様書って誰のためのもの？プログラマ？ユーザー？上司？
引き継ぎをする人のためのものだよ。 客側、開発側関係なく開発時に
いなかった人間に対して、5W1Hじゃないけどソースを読んだだけじゃ
分からない、ソースを読まなくても最低限のことが分かることが書いて
あればいい。 逆に言うと、ずっと生き字引並にシステムに精通したのが
面倒見てくれるなら仕様書なんていらない。
- 697 名前：仕様書無しさん mailto:sage [2012/08/30(木) 22:52:23.45 ]
- 受験の虎の巻みたいなのが欲しいだけでしょ
- 698 名前：仕様書無しさん mailto:sage [2012/08/31(金) 01:19:12.12 ]
- ソースの改定記録残したほうが下手な完成図書作るよりマシだろうに
- 699 名前：仕様書無しさん mailto:sage [2012/08/31(金) 02:06:46.95 ]
- >>697
受験の問題には正解があるけど
仕様書には正解はないからな。
他人の考えや決めたルールを知るには仕様書が必要。
- 700 名前：仕様書無しさん mailto:sage [2012/08/31(金) 02:47:08.70 ]
- >>698
残すも何も、普通はVSSやCVS、Gitなんかのソースコード管理を使うはずで、
よっぽどアホなことしない限りは履歴は残る。
まあ、そのアホなことをする企業は少なからずあるし、小さい企業より
日常的に使わない大企業のSヨさんとかがやらかしてくれるけどね。
なんでSCM使ってるのに紙で別出しで台帳管理をしようとするかな、、、
- 701 名前：仕様書無しさん mailto:sage [2012/08/31(金) 10:05:42.42 ]
- ソースコード管理すると言ってる人が
実はソース読めませんというオチが
- 702 名前：仕様書無しさん mailto:sage [2012/08/31(金) 12:25:05.09 ]
- > なんでSCM使ってるのに紙で別出しで台帳管理をしようとするかな、、、
台帳管理を仕事としてる人の仕事を奪っちゃいけません。
- 703 名前：仕様書無しさん mailto:sage [2012/08/31(金) 20:01:57.98 ]
- 紙で承認受けないと管理したことにならない社内標準があるんだよ。
勘弁してくれ。
- 704 名前：仕様書無しさん mailto:sage [2012/08/31(金) 20:32:11.37 ]
- 電子データになってるのを知らない老害がいるの？
- 705 名前：仕様書無しさん mailto:sage [2012/08/31(金) 21:31:51.33 ]
- もうボケが始まってて、現代でもパンチカードでプログラム書いてると思ってるんだよ
- 706 名前：仕様書無しさん mailto:sage [2012/09/01(土) 07:15:19.81 ]
- 電子データは見方が判らんし、変更しても判らない。
紙で自分のサインがある書類がなきゃ信用しない老害は多い。
そしてそんな老害は、紙の2ページ目以降が丸ごと差し代わっていることを知らない。
- 707 名前：仕様書名無しさん mailto:sage [2012/09/01(土) 11:33:55.42 ]
- >>691
仕様書の標準化をする上で必ず議題となるのは、
•設計情報の網羅性
•誰が書いても同じ物になる記述レベルの統一性
•ドキュメント間の整合性
•ドキュメントのメンテナンス性
•作成コストおよび作成時間
•納品物件としての仕様書要求レベル
•設計するためのドキュメント
•プログラマーのためのドキュメント
•保守のためのドキュメント
•読ませる奴の技術レベル
•ドキュメント作る奴の技術レベル
•実際ドキュメントがいい加減でもプログラムはちゃんと出来たりする。
これらを考えると、結局みんなが幸せになる標準化なんて不可能って早々に気づく•••
- 708 名前：仕様書無しさん mailto:sage [2012/09/01(土) 16:51:17.22 ]
- 盗撮して御用になる元IBM社長みたいな老害がいっぱいの世の中
- 709 名前：仕様書無しさん mailto:sage [2012/09/02(日) 03:17:23.15 ]
- 大手ほど無能も多いからなー
なまじ職場は同じなだけに、技術職との開発業務に対する温度差が激しい
結局、出来ること出来ないことを理解してない層は調整とかそういうのは無理なんよ
ノウハウがないなら勉強しないといけないけど、そういうのしないでもなーなーでやって桁利するから、余計に成長しない
ドキュメントが詳細に必要になるのは、客と開発の間に人が無駄に入りすぎるせいだわなー
- 710 名前：仕様書無しさん mailto:sage [2012/09/02(日) 03:18:44.51 ]
- なまじ職場は同じなだけに、同じような仕事に見られるけど
実際に作ってる技術職してる人と、客とのやり取りだったりドキュメント弄繰り回したりする人とだと、
開発業務って部分に対する興味の温度差が激しい
訂正しようとしてたら書き込み押してしまったよ('`)
- 711 名前：仕様書無しさん mailto:sage [2012/09/02(日) 06:27:16.93 ]
- ちょっとスレ違い気味になるけど、日本の役所はいい加減ウォーターフォールに固執するの止めて欲しい。
役所の仕様基準の元がMILなのは良いけど、そのMILは30年以上前に改訂されとっくに廃止されてる。
かなり前からプロトタイプ推奨に変わったし、今はアジャイルやスパイラル前提だ。
ウォーターフォールの失敗を認めて非推奨にしてる。
で、アジャイル以降の場合、ドキュメントの自動化が必須なんだ。
そんな細かな修正、いちいち直してらんないから。
なのにウォーターフォールと手で作ったドキュメント求め続ける役所。
見積りの精査も出来ず、高々100行程度の改修で億払うって、ほんとバカしか居ない。
- 712 名前：仕様書無しさん mailto:sage [2012/09/02(日) 06:38:20.92 ]
- > このため現実のウォーターフォール・モデルの開発プロジェクトでは、
> 前工程の完了要件（要件定義局面であれば、要件定義書などの成果物の完成）を
> 徹底して品質を高め、後戻りの発生率を可能な限り低下させるとともに、
> 後戻りが発生する場合は変更管理によって公式に決定し、
> 後戻りや横展開を確実にフォローする。
２０年前ぐらいなら通用した考え方だね
今の情報量は半端じゃないからね
> 要件定義
って、うるさい文系院卒がいたけど
今のコンピュータのことが全然わかってなかった
今だに、非力なパソコンの流行りはじめの事例が通用するとか思ってるんかね
時代についていけてない人は...
紙の上で終わらせたいとか？
- 713 名前：仕様書無しさん mailto:sage [2012/09/02(日) 07:12:36.41 ]
- 昔はのんびりと時間がかけられたからね。
例えば一年単位でプロジェクトを回しているところとかだと、
プログラマに仕事が回ってくるのは年度の後半(10月とか11月〜)だったり
したもんだ。SEはそれまでに半年かけて文書の作成をやってればよかった。
ところが、今みたいに同じ作業を3〜4ヶ月で終わらせないといけない状況だと、
文書化とコード作成を同時並行で動かさないといけないわ、期間が短い分
精度が落ちてるから手戻りが増えてるわ(しかも、ウォーターフォールだと
手戻りがやたら面倒くさい管理方法とってるから大変)で、破綻してるんだよね。
- 714 名前：仕様書無しさん mailto:sage [2012/09/02(日) 07:28:41.54 ]
- 無理に短納期にして、自分の首絞めてるだけでしょ
人月計算が時代に合わなくなってきてる？
- 715 名前：仕様書無しさん mailto:sage [2012/09/03(月) 02:37:04.18 ]
- 客と作り手の間に挟まる人数をもっと減らすしかない
- 716 名前：仕様書無しさん mailto:sage [2012/09/03(月) 03:02:52.38 ]
- 大手から下請けにっていう構図があれなんだよな
リスク回避のための保険という意味はわかるんだけど
無駄を無駄だって言える人がいればなぁ
- 717 名前：仕様書無しさん mailto:sage [2012/09/03(月) 03:05:20.03 ]
- 大手が下請けって思いたいだけなの、今や
下請けいじめとかTVで報道されて恥ずかしくないのかね、大手系
- 718 名前：仕様書無しさん mailto:sage [2012/09/03(月) 18:12:13.96 ]
- 大手とか関係なく、自社に人が確保出来ないってのは大きいよ。
常に人を確保出来るほどの仕事がある会社は少ないから、必要な時に集める。
実際、土方と同じ理由だよね。
- 719 名前：仕様書無しさん mailto:sage [2012/09/03(月) 20:22:23.42 ]
- 人海戦術が通用しなくなってきてるから、困ってんじゃないの？
短納期にこだわりすぎて
短期で仕様と設計まとめれる人いるんかい
- 720 名前：仕様書無しさん mailto:sage [2012/09/04(火) 06:48:07.12 ]
- 色々無理のある業界だよね。
本当に設計を纏められる人は一握り。
なのに短期間でのウォーターフォールだから、ドキュメントすら作るのに精一杯。
そこにレベルの下がる派遣かき集めても、OJTする時間すらない。
しかも見積りは人月の数字を舐めさえすれば安くなるから営業は無理な案件でも取ってくる。
せめて、プロトタイプ手法でも使えれば、少数精鋭でプロトタイプ作った後、レベルの下がる派遣に展開する手が使えるのに。
- 721 名前：仕様書無しさん [2012/09/05(水) 16:42:22.18 ]
- 人海戦術でのソフト開発は、映画作りに似てるね？
原作という要件書があっても
監督のアタマの中のイメージと絵コンテを頼りに
セット制作を指示し、本番突入で何とか試行錯誤で
作り上げる。
映画と違う点は、その後も山のようなバグ取りと運用サポートに忙殺される。
- 722 名前：仕様書無しさん mailto:sage [2012/09/05(水) 21:00:16.80 ]
- マとSEは時間少なすぎて、残業まみれでしまいに頭おかしくなって
客はバグまみれでちょっと動かすと落ちたり計算結果が狂うシステムにイライラして
携わった人間だけをみると、Lose-Loseな状態だよなあ。こんなITで誰か幸せになってんのか？
- 723 名前：仕様書無しさん mailto:sage [2012/09/05(水) 23:08:08.10 ]
- 余裕のない状況作って、実は喜んでる人がいたりするのがなんとも
- 724 名前：仕様書無しさん mailto:sage [2012/09/06(木) 00:42:28.17 ]
- 安かろう悪かろうの需要がまだあるうちは何とかなるだろうけど、未来はないよね
- 725 名前：仕様書無しさん mailto:sage [2012/09/06(木) 01:18:00.25 ]
- 今の状況がわかってない人達が、自分で自分の首を絞めてるだけ？
- 726 名前：仕様書無しさん [2012/09/06(木) 06:06:54.00 ]
- >>722
ろくな仕事もないのに仕事をした振りできる公益法人やら天下り団体の職員が喜ぶんですよね。
そういう予算だけはあるけど仕事がないところがなんでもかんでも発注するし、
使い勝手とか機能とかがでたらめな内容で発注しまくるものだから
システム開発する側もろくなものを作らず、
結果として無能の再生産をする。
- 727 名前：仕様書無しさん [2012/09/06(木) 08:08:29.54 ]
- 基本も詳細も設計書は顧客向けに出すものではなく、V字モデルのテスト設計資料として活用するもの
そうやれてる企業は存在しないけどｗ
顧客向けなんてマニュアルと営業パワポでいい
- 728 名前：仕様書無しさん [2012/09/08(土) 11:30:54.54 ]
- このスレダメすぎ。
仕様書、設計書、言ってる地点でアウトなんだよ。
いいかげん、ウォーターフォールを滅ぼさないと日本が滅びる。
- 729 名前：仕様書無しさん mailto:sage [2012/09/08(土) 11:50:04.08 ]
- 顧客
↓
マニュアル
↓
結合テスト
↓
単体テスト
↓
コーディング
↓
仕様書
どうしてもウォーターフォールやりたいなら、こういう順序がいいと思うよ、本気で。
- 730 名前：仕様書無しさん [2012/09/08(土) 12:11:47.34 ]
- 「コードもないのにどうやって結合テストするの？」
とか言ってんの、もうねアホかとバカかと。
これはソフトだけの話じゃないんだよ、ハードだって開発はそういうもんなんだよ。
車の開発をしようとしたら、まずテストコースを準備する。
開発チームごとニュルに行く。
そこから始まる。当たり前の話。
- 731 名前：仕様書無しさん mailto:sage [2012/09/08(土) 12:41:35.07 ]
- テストコースなんてどこにでもあるじゃん。
俺なんか公道でドリフトの練習しまくったよ。
字乞田けど。
- 732 名前：仕様書無しさん mailto:sage [2012/09/08(土) 13:52:16.21 ]
- ツーホー
- 733 名前：仕様書無しさん mailto:sage [2012/09/08(土) 13:52:42.14 ]
- 面白いと思って言ってるんだろうから、そっとしておいてあげような
- 734 名前：仕様書無しさん mailto:sage [2012/09/08(土) 15:11:28.44 ]
- 「どこにでもある」
つまり、顧客環境＝開発環境が当たり前の場合、
理論と実際の誤差が生じていてもなんとかなってるんだ。
逆に、特殊環境で動かさなければならないソフトの場合だ。
そのエミュレータを手前に準備しなければコーディングしにくい。
「当たり前にないテスト環境を整えることを先にやらなければならない」
この手順を突き詰めると、ウォーターフォールの誤謬に直面する。
そこから、テスト・ファーストという考えに辿りつく。
- 735 名前：仕様書無しさん mailto:sage [2012/09/08(土) 15:30:21.57 ]
- > そのエミュレータを手前に準備しなければコーディングしにくい。
そんな事情は考慮しない。設計どおりのコーディングをすれば、
問題なく動くコードが出きるはずだ。
- 736 名前：仕様書無しさん [2012/09/08(土) 15:50:09.51 ]
- >>735
それは、ベテランの人間が小規模なプロジェクトをクリアする場合には当てはまる。
それ以上にはならない。
普通レベルの人間に真似させられないだけでなく、
高品質なプログラムにならない。
結果、顧客のダメだし確率も上がり、開発期間短縮にもならない。
リスクが高いので、趣味の範囲にとどめるべき手法だといえる。
- 737 名前：仕様書無しさん mailto:sage [2012/09/08(土) 17:56:39.57 ]
- よく、アジャイルは、ウォーターフォールを細かく繰り返すことだと言うけれど、
その認識じゃー、うまくいかないに決まってる。
なぜなら、ウォーターフォールモデルの手順自体が真逆だから。
>>729が正しい順序なのである。
それで、アジャイルがうまくいかないと嘆くことになるんだが、
ウォーターフォールの根源的問題を繰り返したら、
もっとうまくいかなくなるのは当たり前。
- 738 名前：仕様書無しさん mailto:sage [2012/09/08(土) 18:38:52.54 ]
- ボトムアップ的なやり方だけじゃダメじゃね
ボトムアップとトップダウンを混ぜたようなやり方のほうが
- 739 名前：仕様書無しさん [2012/09/08(土) 20:07:59.54 ]
- 顧客←────┐
↓ │
マニュアル←─-┤
↓ │
結合テスト←─-┤
↓ │
単体テスト←─-┤
↓ │
コーディング─→┤
↓ │
詳細設計──→┤
↓ │
基本設計──→┤
↓ │
要求定義──→┘
トップダウンとボトムアップはそうなんだけど、
実際的な流れをより明確にするとこうなる。
テスト⇔コーディングが日常。
より大枠のところで、バージョンアップだ。
- 740 名前：仕様書無しさん mailto:sage [2012/09/08(土) 20:11:22.02 ]
- >>739
試行錯誤が抜けてる。
全く同じ物のパラメータ違いを
作るなら話は別だけど、
プログラムで同じものは作らない
（自動生成すればいいから）
となると、ほとんどが新しいものであり、
試行錯誤しないと実現可能であるかもわからないものがある。
やってみて（コーディングしてみて）、この方法はダメだから
違う方法にするというのはよくある話。
そういう試行錯誤コーディングで
いちいちテストなんてやっても無駄。
- 741 名前：仕様書無しさん [2012/09/08(土) 20:29:03.63 ]
- >>740
テスト⇔コーディングが試行錯誤だよ？
というか、試行錯誤のコーディングでテストをやらない？
なんて、嘆かわしい。
むしろ、そこはTDDを絶対オススメしたい。
- 742 名前：仕様書無しさん mailto:sage [2012/09/08(土) 20:47:43.94 ]
- 基本的にはテストケース考えながら、作り込む方だな、俺は
底辺部分はテストケースはわりと考えなくてもいいんだけど
中間部分はテストケースを考えながらやるし、単体テストもやりやすい
上位部分は流してみないとわからないから、ラフに作って
全体流すときに徹底的につぶすほうかな
要求が一般的なわりと知られてるやり方が出来るのは
先に設計書作れってうるさいみたいだね
- 743 名前：仕様書無しさん mailto:sage [2012/09/08(土) 21:32:23.97 ]
- >>742
「テストケース考えながら」って、リストをエクセルなんかで書きなぐりながらってこと？
実行しながらじゃなく？
- 744 名前：仕様書無しさん mailto:sage [2012/09/08(土) 21:43:20.95 ]
- え、分岐のないやつしかやったことないの？
- 745 名前：仕様書無しさん [2012/09/08(土) 21:56:30.34 ]
- テスト駆動の話なんだけど、テスト用プログラム、走らせてる？
慣れると楽だよ。ある程度使いまわせるし。
なにより、脳内シミュでは完璧だったのに、バグがはじき出される時ある。
焦るけどホッとする。
そして、性能テストも同時にやっちゃう。
劇的な速度増加手段がそこで発見できることもある。
絶対いい。
テスト用プログラムっていっても、うまく作る必要なんか全然なくてさ、
つーか、統合開発環境がすでにテストプログラムなわけだし、
誰でも無意識にやってるはずのものなんだよね。
それを意識的に、プロジェクトフォルダの中には必ずテストソース入れるフォルダも作る。
で、なれると、テストコードを先に作った方がいいことに気づく。
結合テスト←─-┤
↓ │
単体テスト←─-┤
↓ │
コーディング─→┤
結合テストから入るってのは、C言語なら最初main()作って動かす。
PHPならZAMPP入れて動かす。
ただ、それだけのもの。出力真っ白、それがバージョン0.01
それをやるべき。つーか誰でもやってる。当たり前の話。
- 746 名前：仕様書無しさん mailto:sage [2012/09/08(土) 22:08:12.21 ]
- >>739 続き
どうして要求定義が一番最後なのか？
顧客ヒアリングの段階でまとめなければいけないのではないか？
もうね、アホかとバカかと。
例えば、「wordのドキュメントをそのままwebページにしてくれ」と
顧客が言ってくるとする。
はいはいと言って、見積もって基本設計やって
そして、・・・その要求が不可能なことに「途中で」気づくのだ！
もちろん、これはごく単純な例で最初の段階で無理だと断れるパターンだが、
実際問題、コーディングをちょっとやってみないと、
どんな要求が実際消化できるかわからない！（そして正確な見積も！）
そういうときは、正直に一巡するまで待ってもらう。
もしくはその顧客はあきらめ、次のために研究しておくべきだ。
それを、顧客即要求定義みたいに書くから、それが可能であると
勘違いされてしまう。これは深刻なミステイクだ。
後から顧客に怒鳴られ減額されるのは本当に嫌なものだ！
- 747 名前：仕様書無しさん mailto:sage [2012/09/08(土) 22:08:27.74 ]
- > 当たり前の話
?
- 748 名前：仕様書無しさん [2012/09/08(土) 22:32:38.48 ]
- 当たり前の話！
ウォーターフォール滅びろ！
みんな迷惑してる！
- 749 名前：仕様書無しさん mailto:sage [2012/09/08(土) 22:37:38.90 ]
- その手の流れにもってくと、勘違いする人が出るような
当たり前だと思ってるだけで、実際にやってる人が...
- 750 名前：仕様書無しさん mailto:sage [2012/09/08(土) 22:43:31.84 ]
- テスト書く為に早出、退行テストとベンチマークの為にサー残するならやっていいよ。つまり時間外でやれ
みたいなのだから一向に流行らん
それでもやるのが何人かいるのだけがまだ救いか
- 751 名前：仕様書無しさん mailto:sage [2012/09/08(土) 22:45:38.41 ]
- 時間で働いてる人に効率化とか無いですから
- 752 名前：仕様書無しさん mailto:sage [2012/09/08(土) 22:50:00.81 ]
- >>741
> テスト⇔コーディングが試行錯誤だよ？
> というか、試行錯誤のコーディングでテストをやらない？
やらない。テストの工数ってのをちゃんと意識していれば、
とてもやろうとは思わない。
試行錯誤ってのは、何度も仕様に修正が入るということ。
つまり、テストもそれだけ修正が入るということ。
テストがあればリグレッションを防げるが
試行錯誤中はリグレッションを防げない。
なぜなら仕様が変わるからテストが失敗するのがほとんど。
だからそんな状態では人間が流行ったほうが早い。
|
 |
