- 1 名前：仕様書無しさん [2008/06/28(土) 19:49:20 ]
- 何だよ、８割方終わった風な顔で、「コーディング終わりました。後はテストするだけです。」
って...
コーディングが終わってやっと３割終わったかどうかってところだろが。
コーディングが終わってからが本番だっちゅーの。テスト仕様書に従い、テストデータ用意して、
正常系、異常系含めて、抜かりなく全網羅テストすること。これがどれだけ大変なことか。
本当に理解してんのか？ コーディングが終わってやっとスタートラインに立ったぐらいの気持ち
でいろよ、ってくヘラヘラしやがって。
こういう、テストを軽視する輩共が、プログラミングという作業を軽んじ、工数見積りを誤り、
徒に製造を急かし、バグの混入率を間接的に高めているということに気づかんのか。
どんな優秀な奴だって、人間だもの、間違いを犯す。バグを生み出す。それを極力未然に防ぐのが
テストだろ。いつバグが判明するかとドキドキしながら納品後の時間を過ごすか、自信と満足感を
もって笑顔で過ごすか。どちらがいいか自明のことだろ。
プログラミングはなぁ、テストに始まりテストに終わるんだよ。要件を理解し、その中に潜む異常
パターンを見抜き、どんだけ抜かりなくテストをやれるかが一流とカスを分かつ分水嶺だ。
コーディングなんかできてあたり前、肝心なのはテストだ。テストを極めてこそ、一流のプログラ
マーって呼べるんだよ。
この馬鹿者どもが。
- 290 名前：仕様書無しさん mailto:sage [2008/07/11(金) 01:14:59 ]
- >>289
実際現場でテストやその後フェーズで苦労しだすと結構分かってくるんじゃない？
ってか品質面で問題でない現場ならそれが一番の幸せだよ｡゜（ﾟ´Д｀ﾟ)゜｡
- 291 名前：仕様書無しさん mailto:sage [2008/07/11(金) 01:15:27 ]
- >>281
仕様書はもちろん個々の機能についても書かれる。
そしてその仕様どおりの入出力を満たしていることの確認もする。
ただし、業務系ではそれをシステムテストとは呼ばない。
個々の機能の入出力を重点的にテストして、それより下位のテストは適当にするっていうのは
いいと思うよ。
本当にただ言葉の定義が違うために言ってることが分かりづらいだけ。
- 292 名前：仕様書無しさん mailto:sage [2008/07/11(金) 01:20:39 ]
- 今回うけた仕事、システム全体の中の1カ所の開発(というかリファクタ)なんだが
自分たちが受けた部分はともかく、他のところはいきなりシステムテストらしい。
ちゃんとモジュールテストされてない・・・
そのせいで、システムテストで
他の会社が作った部分のデバッグをやらされてる。
- 293 名前：仕様書無しさん mailto:sage [2008/07/11(金) 01:22:10 ]
- >>292
そういう段取り／スケジュール考えた奴は軽蔑していいよ
- 294 名前：仕様書無しさん mailto:sage [2008/07/11(金) 02:33:59 ]
- >>290
テスト後フェーズは幾度となく経験してるし、
修正後のテスト堂々巡りも経験してるけど、
大規模開発というものを経験したことがないので、
UT→IT→ST が同時進行ならまだしも、何度も巡る
というのが理解できず、議論についていけないｗ
というかあれだな、読んでいて思ったけど、
言葉の定義や論点がずれているだけで、
本質はみんな同じ認識の様な気がする。
- 295 名前：仕様書無しさん mailto:sage [2008/07/11(金) 06:03:21 ]
- >言葉の定義や論点がずれているだけで、
>本質はみんな同じ認識の様な気がする。
いや、違うね。俺だけが違ってるという可能性もあるが。
>>281
テストフェーズの定義について、素直に間違っていたと認めた80は評価する。
同じように「仕様書」に関しても、他とずれていると認識してほしいのだが。
そうでないと、>>281の後半部分には答えられない。
>つまり、仕様や性能を満たせているかを確認するテスト（ST）が
>ずいぶん後回しになるやり方を皆は支持しているわけだ。
何度も言うように、システムテストは機能テストと「性能を測る」テストだけではない。
後回しになる（後でやらないと意味がない）テスト（ケース）もあれば、先にやるものもある。
機能テストのことをずいぶん気にしているようだが、「皆」がどう取り組んでいるかは、
「受け入れテスト 自動化」でググってみるとわかるかもね。
- 296 名前：仕様書無しさん mailto:sage [2008/07/11(金) 06:12:26 ]
- 俺が80と違っている（と思っている）点は、
・ユニットテストは軽視してはならない。むしろ重視すべき。
・ユニットテストはプログラマが行うべき
・ユニットテストを重視することは、顧客のメリットになる
・（おまけ）外部設計と内部設計という考え方はある
80に同意する点もいくつもあるが、それは列挙しない。
- 297 名前：仕様書無しさん [2008/07/11(金) 19:44:58 ]
- 適当でいいんだよ適当で。
- 298 名前：仕様書無しさん mailto:sage [2008/07/12(土) 02:15:00 ]
- 適当、よりも、適度、がいいと思うんだ
- 299 名前：仕様書無しさん mailto:sage [2008/07/12(土) 15:17:35 ]
- 適当≠手抜き
- 300 名前：仕様書無しさん mailto:sage [2008/07/12(土) 19:29:48 ]
- サンビャク！
- 301 名前：80 mailto:sage [2008/07/13(日) 08:07:03 ]
- >>296
>・ユニットテストは軽視してはならない。むしろ重視すべき。
->軽視はしていない。重視もしていない。
おれは、テスターじゃなくて、プログラマー上がりなので、
ユニットテストの大切さを知っている。ただ、組織としてユニットテストを
成功させる場合は、以下の前提条件を満たせないとだめだ。
1. バグが減ったことを評価して、ボーナス査定をUPさせる。
2. 機能実装よりバグが少ないことを重視する。
重要なのは、2 だ。ユニットテストを重視した結果開発のスピードが
落ちたのだ。つまり、機能的要件（フレームワーク、下位コンポーネント
を除く）を実装するチームに関しては、ユニットテストがボトルネックになる。
よーは、すべてがトレードオフなのだ。ユニットテストを重視しすぎると
逆に効率が落ちる開発フェーズがあることを俺は、経験で学んだ。
>・ユニットテストはプログラマが行うべき
-> ユニットテスト＝ホワイトボックステストなら同意。
>・ユニットテストを重視することは、顧客のメリットになる
-> 大規模開発では、顧客には理解されない。
業務系ではないうちでは、専門的すぎて説明するのが難しい。
>・（おまけ）外部設計と内部設計という考え方はある
-> うちの会社にも昔はあったよ。外部設計、内部設計という言葉が
間違っているのに気がついた。
確かに、システムというものを対象にした時にそれの外部について
記述したドキュメントと内部について記述したドキュメントはある。
ただ、外部か内部かという言葉は、対象物を前提としている。
システム、サブシステム、コンポーネント、ライブラリ・・・・などだ。
そして、これらは、整然と関連付けられる。内部設計とか外部設計という
言葉をこれに当てはめると間違いである事が理解できる。
外部は仕様書で、内部は設計書なんだ。これでもわからないなら。
仕様書と設計書の違いを説明してくれないか
- 302 名前：80 mailto:sage [2008/07/13(日) 08:17:57 ]
- 補足だが、プログラマーとテスターの作業量を新規開発の初めから
終わりまで時間を追ってグラフにしてみると俺の言っていることが
分かるかもしれない。
理想を言えば、一番初めのインテグレートの時にテスターが
チームに参加すれば、コスト的にOKなのだが。
大抵は
1. 一番初めのインテグレートは遅れる。つまりテスターが遊ぶ。
2. テスターが開発初期から参加している場合、テスターは
プログラマーよりも暇である。
3. 機能要件は、よく変わる。せっかくユニットテストをばっちりしても
作り直しが多数発生する。さっさと、要求者に「うごく」ソフトを
見せるのは重要だ。
テスターを遊ばせないで、機能要件の間違いを早期に発見できる方法
を俺は支持しているんだ。
- 303 名前：80 mailto:sage [2008/07/13(日) 08:29:15 ]
- >>285
だいたい、同じ考えだ。
機能要件と再利用可能なコンポーネントでは、テストのやり方
を変えないとだめだ。
再利用可能なコンポーネントは、下位の層で人目につかない。
テスターに通信プロトコルや各種規格をすべて理解してもらうことは無理
なので、プログラマーしか「テストができない」と俺は思う。
違うところは、再利用可能なコンポーネントのテストは、
ホワイトボックステストと加えて回帰テスト（ブラックボックス）を
重視するところだ。
再利用可能コンポーネントは、最適化を繰り返すので、ソースコードが激変する。
つまり、ホワイトボックステストは毎回変わってしまう。
ホワイトボックステスト事態の品質を維持することは非常に難しい、
なので、回帰テストとの合わせ技が重要になる。
- 304 名前：80 mailto:sage [2008/07/13(日) 09:11:20 ]
- 開発工程の中のボトルネックはどこにあるのか？によってやり方は異なる。
プログラマーのスキルが高い場合、テスターのスキルが高い場合など
状況は様々だ。
うちのボトルネックは、「実装」フェーズだった。
スケジュールの遅れは、プログラマーの責任だという認識が多数を占めていた。
なので、ユニットテストが流行したが、結局、失敗に終わった。
ボトルネックにさらに仕事を増やした（人は増えない）結果、開発そのもの
が遅れ、テスターが遊び始めた。設計者は次の設計に入っている。
しかし、ボトルネックが解消されなければ、実装されない設計が溜まる
ばかりだ。テスターは、空いた時間で別のプロジェクトのテストをしている。
リソースが有効活用されていないのは明らかだ。
ボトルネックを解消するのに設計者にテスターにできることはないのか？
そう考えるのが普通だろう。
設計者には、設計を洗練させた。結果、不要なソースコードをプログラマー
が書かなくても良いようになった。
ユニットテストを強要することはやめた。その代りテスターの負担が増えた
が、もともとテスターは遊んでいたのでプロジェクト全体のスループットは
向上した。テスターのストレスは増えたが・・・。
ユニットテストを完璧にやるという事は、ウォーターフォールの考え方
に近い。うちは、繰り返し型の開発をやっているので、たとえバグが残っても
開発の最後の方でプログラマーの手が空いてきたころに網羅性の高いテストを
行うので実質品質が下がるようなことはない。
ユニットテストは有効だが、使い方を間違ってはいけないと思う。
重要なのは、部分最適化（ユニットテストだけを協調する）のではなく
全体最適化（全ての開発工程を見直す）の方だと思う。
- 305 名前：80 mailto:sage [2008/07/13(日) 09:30:44 ]
- >>291
業務系は、書籍などで知っているだけで現場は知らない。
うちは、メカトロニクス。半分は制御系。ただし、大規模な制御系だ。
Web技術、データーベース、各種通信、など色々開発要素も多い、
言語もC++, C#, Java, その他が入り乱れている。
うちのシステムは、多層になっているシステムの集合体だ。
担当者は、自分の担当範囲だけどをシステムと呼んでいる。
つまり、人によって、システムの範囲（スコープ）が違うんだ。
そして、多段階にインテグレートしてテストを行う。
なので、スコープとレベルの違うシステムテストはチーム内の複数存在
することになる。
見方を変えれば、下位のシステムは、ユニットとも言えなくもないが、
よほどの下位でもない限り「一般論で言うユニット」とは違う。
うちでは以下のように定義している。
・（粒度はともかく）機能的要件を実現する単位をシステム
（サブシステム）と呼んでいる
・下位の原始的なメカニズムを提供するものを、ユニットと呼んでいる。
・機能外要求や、システムのアーキテクチャーをつかさどるものを
フレームワークと呼んでいる。
- 306 名前：仕様書無しさん mailto:sage [2008/07/13(日) 11:05:04 ]
- >>301
>ユニットテストを重視した結果開発のスピードが落ちたのだ
結局ユニットテスト非重視と重視で品質面はどちらがあがったの？
非重視で品質落ち（最悪客先リリース後に不具合多々発現）だとしたら
開発スピードが落ちた、ではなく必要フェーズをはぶいてスピードあげてた、
ってだけでは？？
- 307 名前：仕様書無しさん mailto:sage [2008/07/13(日) 11:10:26 ]
- みんなの会社で「専任テスター」っている？うちは
a.管理：チームMGR、PL
b.営業／客対応：客対応向けSE、営業
c.開発：開発向けSE、PG
みたいな位置づけになってて、テストは
「それ開発の一環だろ」って見方を上がしているから結局c.が全員で当たってる。
いい形とは思ってないけど、この場合、
フェーズによって「テスター」が暇になる、ってのはないけどなー
- 308 名前：仕様書無しさん mailto:sage [2008/07/13(日) 12:54:44 ]
- 80の方法だと、ユニットが細かい区分になるので、つまり単純化される。
つまり単純で小さなテストが沢山できる。
質の問題を量に転化したと言っている。
で、コスト削減の為にテストを自動化したと。
まあ、制御系で1000万コードってどんだけーって話だけど。
工場の制御丸ごとやったとしか思えんなぁ。
- 309 名前：仕様書無しさん mailto:sage [2008/07/13(日) 18:02:22 ]
- グローバル変数が100万個位あるんだろ
- 310 名前：80 mailto:sage [2008/07/13(日) 20:32:06 ]
- >>306
品質は向上した。第三者テストの重要性を再認識することとなった。
多分、問題点や間違いを早期のうちに把握できたことと、プロジェクト管理
がやりやすくなったことなども良かったと思う。
プログラマーに、プレッシャーを与えることになったのと、
テスターの地位が向上したのも良かったのかもしれない。
- 311 名前：80 mailto:sage [2008/07/13(日) 20:40:06 ]
- >>307
うちは、専任のテスターがいる。
そして、開発の初めから開発に参加している。
要件定義が終わったら、これをもとにテストを作成しはじめる。
（テスターが要件を事細かに見るので要件は洗練されるというおまけもつく。）
- 312 名前：仕様書無しさん mailto:sage [2008/07/13(日) 21:11:33 ]
- つーか、日本の現場にありがちな曖昧な部分を消したという事が重要だと思う。
グラマーのプライドなんて、邪魔ものだからなー（本人にとってもー）。
- 313 名前：80 mailto:sage [2008/07/13(日) 23:04:06 ]
- >>312
そういう見方もできるな。要件の曖昧さとテスターのカバレッジを
ユニットテストで補えるとプログラマーが考えているなら、
勘違いも甚だしいな。
- 314 名前：仕様書無しさん mailto:sage [2008/07/13(日) 23:05:54 ]
- プログラマの常識は一般人の非常識って事ですね。わかります。
- 315 名前：仕様書無しさん mailto:sage [2008/07/14(月) 01:12:09 ]
- >そういう見方もできるな。要件の曖昧さとテスターのカバレッジを
>ユニットテストで補えるとプログラマーが考えているなら、
>勘違いも甚だしいな。
いや、それに甘えてきたSEが問題でしょ。
厳密に言えば、曖昧さは発生しない為に仕様があるわけで、
仕様抜けとか仕様に考慮を入れていないというミスを
グラマーがプログラミングやユニットテストで吸収するのは
よくある風景だ。
単純にそれはSEの怠慢でしかない。
ちなみにそれやらないと、ユニットテストが上がらないっていう
話になって仕様書を押し戻すと作成元の責任になったりする
ので出来ないってのも基本。
- 316 名前：仕様書無しさん mailto:sage [2008/07/14(月) 06:01:41 ]
- >>301
> よーは、すべてがトレードオフなのだ。ユニットテストを重視しすぎると
> 逆に効率が落ちる開発フェーズがあることを俺は、経験で学んだ。
バグを取り除くのが早ければ早いほど、トータルコストが少なくなるというのには同意してもらえるのかな？
もっと言えば、トータルコストが少なくなるような効果的なユニットテストを模索しなければならない。
> -> 大規模開発では、顧客には理解されない。
> 業務系ではないうちでは、専門的すぎて説明するのが難しい。
トータルコストが少なくなり、品質も安定するという意味で、顧客のメリットになる。
>-> うちの会社にも昔はあったよ。外部設計、内部設計という言葉が
>間違っているのに気がついた。
>そして、これらは、整然と関連付けられる。内部設計とか外部設計という
>言葉をこれに当てはめると間違いである事が理解できる。
君が間違っていると主張しても、それでも世界は回っているんだよ。
目をふさぐのは簡単だけどね。
- 317 名前：80 mailto:sage [2008/07/14(月) 06:56:34 ]
- >>316
>バグを取り除くのが早ければ早いほど、トータルコストが少なくなるというのには
>同意してもらえるのかな？
当然そうだが、早いというのは、開発のスケジュールの早い段階でという
意味でだ。うちはスパイラルだからできる芸当なんだが、早期の詳細な
テストが徒労に終わることを経験で知っている。
開発の初期で最低限の要件で開発して、さっさとインテグレート
してさっさとシステムテストをやることで早期にテストを行って
要件の問題を修正している。この場合、ユニットテストは簡単にしか
行われない。
- 318 名前：80 mailto:sage [2008/07/14(月) 07:10:39 ]
- >>316
>君が間違っていると主張しても、それでも世界は回っているんだよ。
>目をふさぐのは簡単だけどね。
世界って広いぞ。うちは外資系だからアメリカ、インド、ロシア・・・・
いろんな奴と一緒に仕事しているけど、ソフト開発なんてのは、世界的に
統一されたりしてないぞ。各国各様でばらばらだ。つまり、外部設計と
内部設計という言葉が通用しないのを、実際に経験で知っている。
- 319 名前：仕様書無しさん mailto:sage [2008/07/15(火) 01:47:04 ]
- なんでシステムテストをやると
ユニットテストをサボれると思うのだろう？
- 320 名前：仕様書無しさん mailto:sage [2008/07/15(火) 08:56:28 ]
- >>317
> 意味でだ。うちはスパイラルだからできる芸当なんだが、早期の詳細な
> テストが徒労に終わることを経験で知っている。
誰も、過剰なユニットテストをやれなんて言ってねーよ。ユニットテストをプログラマにやらせると
必ず過剰なものになるからやらせないってことか。
まぁ、お前のチームのプログラマがレベル低すぎて効果的なユニットテストをできないのならそれも仕方ないかもな。
>>318
どんだけ田舎者と仕事してんだよ。
internal designとexternal designも通じない奴と仕事してんのかよ。
- 321 名前：仕様書無しさん mailto:sage [2008/07/15(火) 08:58:53 ]
- そろそろメトリックスベースで話さないと埒があかんな。
1000万行のシステムで、第三者検証チームが検出したバグは何件だったんだ？
- 322 名前：仕様書無しさん mailto:sage [2008/07/15(火) 09:26:09 ]
- >>318
とりあえず、原著で読んだsoftware development processの本の題名を列挙してくれ。
- 323 名前：80 mailto:sage [2008/07/15(火) 23:50:38 ]
- >>320
シリコンバレーは、確かに田舎だな。。。。
ちなみに言うとうちでは設計書はあまりかかれない。仕様書を重視する。
うちの外人さんは、「設計書＝ソースコード」だと言い張る。
年収3000万を超えるプログラマーだからできる芸当なのかもしれない。
こいつらテストはしない。テストは、テスターの仕事だと言い張る。
- 324 名前：仕様書無しさん mailto:sage [2008/07/16(水) 00:20:17 ]
- ダメだ、はったりにしか見えない｡゜（ﾟ´Д｀ﾟ)゜｡おれもうROMるわ
- 325 名前：仕様書無しさん mailto:sage [2008/07/16(水) 01:51:18 ]
- 「顧客のメリットになる」ことにこだわっている人が
いるけど、それが必ずしも自社にとってメリットになる
わけでは無いわけで。そういった意味で顧客との間で
落とし所をさぐる時にユニットテストを一部省くというのは
普通にあると思うけど？
やった作業に対して全て金を払ってくれる契約
（それって派遣？）なら全ソースに対してユニット
テストするのもありかもね。
- 326 名前：仕様書無しさん [2008/07/16(水) 16:08:56 ]
- 経験上の話だが、（良い）詳細設計というものは考えていても作れない。
そういう頭の中で考えただけの設計というものは実際に作るときに、
絶対に問題点やバグがある。パフォーマンスの問題なんか
実際に作らないで目標を達成することなんか不可能。
結局コーディングして、その結果をフィードバックして
設計を完成させなければならない。
ユニットテストってのは、その設計を完成させる為のチェックポイントなんだ。
これは重要なこと。
「設計・コードは簡単に変わるが、チェックポイント（テスト内容）は変わらない。」
ゲームに例えるとこうなる。
仕様・・・世界を平和にする。
ユニットテスト・・・各ステージのボスを倒す。（チェックポイント）
設計・・・どういうルートを通ると早くすすめるか。
コーディング・・・実際のキー操作
最初に仕様があるが、これはすごくあいまいなもの。
システムを作るうえでの大前提だが、コレを決めてもシステムは作れない。
個々の目標が、ユニットテスト。これがシステムを作るうえで一番重要なもの。
これがあれば、設計やコードを柔軟に変更することができるし、間違っていない証明になる。
そして、ユニットテストを作ってから、設計とコーディングを行いながら開発していく。
（実際にキー操作をしないと、考えたルートが通れるのか本当に早いかはわからないね）
- 327 名前：仕様書無しさん mailto:sage [2008/07/16(水) 16:20:33 ]
- >>325
あなたが言っているのは、ユニットテストに限った話じゃないね。
「自社のメリットにならない場合はテストを省く。」
「やった作業に対して全て金を払ってくれる契約なら全部テストするのもありかもね。」
もし俺が客で、あなたの会社にシステム開発を依頼する立場なら、
お金を払って開発したシステムを、あなたがちゃんとテストしてくれるかどうか不安だけど。
> やった作業に対して全て金を払ってくれる契約
これは、全部のテストの作業量を見積もって、その金額で契約するわけだから、
全部テストするのが当たり前だと思うんだけど？(客が80%で良いとか言うのなら別）
- 328 名前：仕様書無しさん [2008/07/16(水) 16:37:47 ]
- >>1
おれの作ったプログラムにはバグがない。
だからテストは不要。
と書きたいところだが、
Ｃ言語だと１万ステップに３カ所ぐらいは
バグがある。
ただし重要なところでバグがでないように
単体テストをしっかりとやってから納品している。
バグは意思の疎通が十分にできていれば
ほとんどでることはない。
バグのでる仕事というのは、だいたい意志の疎通がとれていない
ということ。
- 329 名前：仕様書無しさん mailto:sage [2008/07/16(水) 16:45:46 ]
- 俺も1万行に一回くらいしかコンパイルしないけど
ほとんどバグないな
- 330 名前：仕様書無しさん mailto:sage [2008/07/16(水) 17:08:08 ]
- 何この全力で釣られるスレは・・・
- 331 名前：仕様書無しさん mailto:sage [2008/07/16(水) 19:24:52 ]
- >>327
>これは、全部のテストの作業量を見積もって、その金額で契約するわけだから、
>全部テストするのが当たり前だと思うんだけど？(客が80%で良いとか言うのなら別）
100%見積もれて、客が１つも仕様変更をしない場合の話だよね。それって。
そこら辺は開発スタイルの問題かと。俺が言いたいのは「仕様変更のリスクを設計や
計画に含めた形で客に説明しているし、客にもある程度納得してもらってる」
という事。
そういった意味でテストの手法や粒度をどうしましょうか？という事を>>80は言い
たいんじゃないの？
- 332 名前：仕様書無しさん mailto:sage [2008/07/16(水) 19:37:34 ]
- >>331
でも、最初っから変更出来るって頭を顧客に植え付けちゃうのもどうかと思う。
費用込みなんだから一度くらいは変更できるよね？ とか言われないか？
- 333 名前：仕様書無しさん mailto:sage [2008/07/16(水) 19:59:42 ]
- >>332
プロジェクトがある程度続いている or 続く事が期待できる
相手であればそれもありかと。いずれにしても開発・契約
スタイルによるわな。
- 334 名前：仕様書無しさん mailto:sage [2008/07/16(水) 20:01:37 ]
- まあ、変更は一切出来ませんとか言っててもどうせ変更させられるんだけどなwww
- 335 名前：仕様書無しさん mailto:sage [2008/07/16(水) 21:27:23 ]
- 普通は1000行あたりバグが5〜50個くらいかな。数え方やプロダクトの難易度にもよるが。
1000万行だったら、5万〜50万個くらいか。
まぁ、正直、これだけのバグを10人でさばけるのなら大したもんだよ。
- 336 名前：仕様書無しさん mailto:sage [2008/07/16(水) 23:05:12 ]
- >>335
ちょっと待て
最悪20行に一個出るのが普通か?
たとえ200行に一個でもかなり多いだろ
新人レベルがかなり混じってるならともかく･･･
- 337 名前：仕様書無しさん mailto:sage [2008/07/16(水) 23:25:32 ]
- >>336
設計から実装までやれば、延べにしてそのくらいは出るよ。
設計ミスで全面入れ替えの所とか、パフォーマンス出なくてとか、必ず出てくるwww
- 338 名前：仕様書無しさん mailto:sage [2008/07/16(水) 23:35:42 ]
- ここがコーディング界のネ申達がおわす所、バルハラですか（１万ステップに１バグあるかないかを誇るという）？
それにしては冴えない連中が多いのですが・・・
- 339 名前：仕様書無しさん mailto:sage [2008/07/16(水) 23:37:43 ]
- あいつ使えねーからこっちで直しておこーぜ。
いいよ、バグ無しって言っておけよ。
- 340 名前：仕様書無しさん mailto:sage [2008/07/16(水) 23:39:08 ]
- >>329
それはデータ込みの・・・むしろデータのみを扱ったコードですか？
社会保険庁よりは優秀ですねwww
- 341 名前：仕様書無しさん mailto:sage [2008/07/16(水) 23:42:32 ]
- >>340
一般人には想像すらできない天才っているもんなのよ。
天才というか、障害というか。
- 342 名前：仕様書無しさん mailto:sage [2008/07/16(水) 23:43:54 ]
- >>337
設計にしてもキモになる部分ならプロトタイプなりなんなりで
実装可能性やパフォーマンス検討するだろ。
それを実装まで持ち越しているなら設計工程が十分でないだけ。
ひょっとして手戻りが好きなのか？ｗ
- 343 名前：80 mailto:sage [2008/07/16(水) 23:46:47 ]
- >>324
はったりじゃないんだけど・・・。
それに、嘘ついても仕方がないじゃんか。
- 344 名前：仕様書無しさん mailto:sage [2008/07/16(水) 23:48:32 ]
- >>342
やらねえよ。
だって動作環境が半年後じゃないと揃わないとかザラにあるからな。
パソコン上で幾ら理論構築しても、載せて初めて発覚するパフォーマンスなんてのは普通だし。
- 345 名前：仕様書無しさん mailto:sage [2008/07/16(水) 23:54:42 ]
- まあ、何万行書いてもBUGなんて皆無と豪語してる奴は、信じられなくて当然。
そういうコードは結合後に醜い事になってる事が経験的に多いなw
要するに、俺様仕様でBUGゼロってだけだからwww
- 346 名前：仕様書無しさん mailto:sage [2008/07/17(木) 00:05:34 ]
- 入力がパンチカードとかだった時代ならともかく…
- 347 名前：仕様書無しさん mailto:sage [2008/07/17(木) 00:07:03 ]
- どこかの会社の面接を受けて
特技「１万ステップのコーディングでバグが１件です」
って言ったら、さてどうなるか？
- 348 名前：80 mailto:sage [2008/07/17(木) 00:07:24 ]
- >>342
パフォーマンスに関するチューニングを急いではいけない。
これは、鉄則なので、いまさら説明する必要はないだろう。
パフォーマンスのチューニングは、設計ではなくて
測定に基づいて行われるべきである。
>>345
正論だな。俺様仕様で作ったプログラムを、俺様が作ったユニットテストを
しても、そりゃー合格するよ。そもそも、自分が理解したとおりのプログラム
を書けない奴はうちにはいない。
たいてい、俺様仕様が間違っている時にバグが埋め込まれる。
- 349 名前：仕様書無しさん mailto:sage [2008/07/17(木) 00:10:11 ]
-
///なんか80に正論とか言われると萎える・・・
- 350 名前：仕様書無しさん mailto:sage [2008/07/17(木) 00:13:46 ]
-
// 80は極論派だと思う
- 351 名前：仕様書無しさん mailto:sage [2008/07/17(木) 00:15:48 ]
-
/うわなんでコンパイルエラー！？
- 352 名前：仕様書無しさん [2008/07/17(木) 00:38:06 ]
- >>1はいいこと書いてるな。
- 353 名前：仕様書無しさん mailto:sage [2008/07/17(木) 00:49:15 ]
- でも、なんか>>1ってチンコ臭そう
- 354 名前：仕様書無しさん mailto:sage [2008/07/17(木) 00:52:26 ]
- /* >>351 コメントとして間違っている！！ */
- 355 名前：仕様書無しさん mailto:sage [2008/07/17(木) 01:26:10 ]
- まて、もしかするとマンコかもしれないじゃないか
- 356 名前：仕様書無しさん mailto:sage [2008/07/17(木) 01:27:47 ]
- >>344
組み込みならモノがないのでやむを得ない面もあるが、
大概は前のチップや代替品を使って見当を付ければいい。
>>348
パフォーマンスを急げと言っているわけではない。
パフォーマンスがどれくらいでそうか当たりを付けて
速度重視にするかフットプリント重視にするかの設計方針に入れろと言っている。
それを設計工程で行わないで後に回すから手戻るんだよ。
- 357 名前：仕様書無しさん mailto:sage [2008/07/17(木) 02:14:55 ]
- パフォーマンスって、チップ次第だし。
パソコンアプリ作ってればそのまま試せるだろうがな。
石のアクセス自体仕様通りじゃない場合だって普通にあるからさw
- 358 名前：仕様書無しさん mailto:sage [2008/07/17(木) 02:22:35 ]
- >>356
設計段階でパフォーマンスのトレードオフ検討出来るってうらやましいな
たいていは、死守要求だったりするからな。
- 359 名前：仕様書無しさん mailto:sage [2008/07/17(木) 02:47:00 ]
- >>358
排反事象なら一方を満たして他方を次善にして、後は交渉術でそ。
全部実現するにはこれこれのコスト(金額、開発期間)がかかりますと言うだけだし。
金払わない以上どこか諦めてね♥
- 360 名前：仕様書無しさん mailto:sage [2008/07/17(木) 02:50:37 ]
- >>359
いや、払うだろ。
正当な追加費用ならなwww
- 361 名前：仕様書無しさん mailto:sage [2008/07/17(木) 03:09:11 ]
- >>360
まともな客ならなぇ。。。
大概はより良く(まぁいい)より安く(切り詰めてんじゃねぇ)。
- 362 名前：仕様書無しさん mailto:sage [2008/07/18(金) 02:24:12 ]
- たしかに>>1はいいこと書いてるな
先日面接で「ｘｘのシステムを作り直すとしたらどのくらい？」って聞かれて
「コアを作り直すなら２人月ぐらいですね、今まで自分らで作っていた部分が今ではライブラリとして提供されているから。
それよりも、テストの方に工数がかかると思いますよ。」って答えた。
でもよく考えたら、ｘｘを作り直す（完成させる）まで、ってのは当然テストが完了して、のことなんだよな。。。
どうも自分の中で実装とテストを別に考えてしまっていたわ・・・ちゃんとしたものを作る、っていう意味では
テストはものづくりの一部だわ、、、今ここで反省します m(^＿^;)m
遠足は家に帰るまでが遠足だかんね。
- 363 名前：仕様書無しさん [2008/07/18(金) 21:10:41 ]
- >>362
ど素人さんですか？
今まで何やってたの？
- 364 名前：仕様書無しさん mailto:sage [2008/07/19(土) 01:08:59 ]
- >>363
>>362はちゃんとテスト工数の話してるしちょっと区切り間違っちゃっただけだろ。
いじわるなんだからっ！
- 365 名前：仕様書無しさん mailto:sage [2008/07/19(土) 11:20:47 ]
- たかだか二人月のゴミみたいなプロジェクトの例を出されましても・・・
- 366 名前：仕様書無しさん mailto:sage [2008/07/19(土) 13:00:56 ]
- ttp://itpro.nikkeibp.co.jp/article/OPINION/20080423/299886/
6000人のSEが同時期に集まったのであって，「6000人月」ではない。
開発工数は先に書いた通り，11万人月である。
このSEパワーは開発だけではなく，テストに惜しみなく使われた。
ざっと5000人が8カ月テストをしたとするとこれだけで4万人月，開発工数の3分の1がテストに費やされた計算になる。
本来なら有り得ない開発工数とマネジメント工数とテスト工数である。
本来なら有り得ない開発工数とマネジメント工数とテスト工数である。
本来なら有り得ない開発工数とマネジメント工数とテスト工数である。
- 367 名前：80 mailto:sage [2008/07/19(土) 17:11:42 ]
- ttp://sankei.jp.msn.com/economy/finance/080512/fnc0805122000013-n1.htm
テスト段階では、全く想定していなかったトラブルが起きた
テスト段階では、全く想定していなかったトラブルが起きた
テスト段階では、全く想定していなかったトラブルが起きた
テストに開発工数の 1/3 を費やしてもシステム障害で行政処分。
部分最適化のもろさを露呈してしまう結果になった。
「全く想定していない」・・・要求定義者や分析・設計者のミスをテストで
カバーできないってこと。間違った仕様を完璧にコーディングしても
それは、バグ。
- 368 名前：仕様書無しさん mailto:sage [2008/07/19(土) 17:22:10 ]
- 6000人全員が派遣でしたwww って話？？
- 369 名前：仕様書無しさん mailto:sage [2008/07/19(土) 20:48:04 ]
- コーディングは終わったので、あとは人海戦術で手動テストしてくださいって
パターンなら最初からうまくいくはずないよ。
- 370 名前：仕様書無しさん mailto:sage [2008/07/19(土) 22:14:17 ]
- なんか、ぶっちゃけ私の方法ならうまくいくと間接的に言ってるように
見えるけど、ほんとそうなの？
- 371 名前：仕様書無しさん mailto:sage [2008/07/19(土) 22:22:01 ]
- >>369
テストの際に出てくる不具合報告を眺めてるだけじゃ完成しないがなw
テストに入ってからが本当のコーディング作業が始まると思わなきゃ上手く行かない。
- 372 名前：仕様書無しさん mailto:sage [2008/07/20(日) 02:22:31 ]
- >>371
メガプロジェクトじゃ、そんなの通用しないし。
- 373 名前：仕様書無しさん mailto:sage [2008/07/20(日) 02:34:44 ]
- >>372
はあ？
メガプロジェクトじゃ、最後までコーディングしてる部署が必ずあるよ。
つうか、不具合改修はやらねえの？
- 374 名前：仕様書無しさん [2008/07/20(日) 03:14:48 ]
- 普通、やるでしょ
PSPの海腹川背みたいな例もあるけどw
- 375 名前：仕様書無しさん mailto:sage [2008/07/20(日) 12:12:05 ]
- >>371
> テストに入ってからが本当のコーディング作業が始まると思わなきゃ上手く行かない。
だから、無駄なテスト前コーディングをしないで、
テストをやってコーディングをするんだよね。
- 376 名前：仕様書無しさん mailto:sage [2008/07/20(日) 12:16:01 ]
- >>367
> 「全く想定していない」・・・要求定義者や分析・設計者のミスをテストで
> カバーできないってこと。間違った仕様を完璧にコーディングしても
> それは、バグ。
ですよね。だからちゃんと想定して、
その想定した内容をテストとして書くんですよね。
これであなたもユニットテストの重要性を理解したと思います。
- 377 名前：仕様書無しさん mailto:sage [2008/07/20(日) 12:20:56 ]
- ついにマ板にも夏が来たか・・・
- 378 名前：仕様書無しさん mailto:sage [2008/07/20(日) 14:21:36 ]
- >>376
ユニットテストじゃ、要求定義や設計時のミスは取り除けないよ。
それを元にテストが作られるんだからね。
だいたい、設計時の矛盾は最終的な総合テストまで残る。
要求定義の矛盾は製品にまで残る。
- 379 名前：仕様書無しさん mailto:sage [2008/07/20(日) 15:00:32 ]
- >>373
「本当のコーディング作業」の定義次第だな。
そして、その定義を云々するのはくだらねー。
- 380 名前：仕様書無しさん mailto:sage [2008/07/20(日) 17:13:26 ]
- 80の言い分だけど、
うちの会社は1000万のコードで、
次に、基本証券・金融系では無い。制御系だといって、
最後に、国内最大の金融系の仕様段階での問題点を出している。
あ、あとシリコンバレーと仕事しているってのもあったな。
で、別に仕事のやり方は全否定する要素は無いが、具体例は
全否定されても仕方ないほど妄想力に満ちていると感じたの漏れだけ？
- 381 名前：仕様書無しさん mailto:sage [2008/07/20(日) 19:23:59 ]
- >>374
あれは、「仕様です」
- 382 名前：仕様書無しさん [2008/07/23(水) 01:01:35 ]
- とりあえずユニットテストやファンンクショナルテストをちゃんと書いていけば
設計時の矛盾とか普通にたくさんでてくるよ。
んで、短いサイクルでどんどんリファクタしていけばいい。
もちろん手動テストもするけど、ばかげた規模での人海戦術テストとかにはならないでしょ。
- 383 名前：仕様書無しさん [2008/07/23(水) 01:06:30 ]
- またまた富士通！東証システム障害 プログラムミスが原因 2008/7/22
headlines.yahoo.co.jp/hl?a=20080722-00000027-maip-brf
41 名前：仕様書無しさん 投稿日：2008/07/23(水) 00:00:22
∧∧
富 ( ･ω･) ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
士 （つ/￣￣/ ＜ 1銘柄当たり1280バイトの作業用メモリー領域だから、
通 /＿＿/ ＼ ＼ 2万8000銘柄分、合計3万5000Kバイト・・・
||＼ TOWNS ＼ ＼ 4万バイトということで"PIC 9(40M)"ってことだな
||＼||￣￣￣￣￣|| ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
|| ||￣￣￣￣￣||
.|| ||
え〜と40M・・と、 それ、ポチっとな
000230 01 WORKAREA.
000240 03 WORK PIC 9(04). <--- 4バイト
∧東∧
∧富∧ （´<_｀ ） さすがだな富士通
（ ´_ゝ`）/ ⌒i
＿(__つ/￣￣￣/i |＿ そんなこと言ってないで、チェックお願いしますよ、東証&NTTデータさん
＼/＿＿＿/ ヽ⊃
そして・・・・
. . : : : :: : : :: : ::: :: : :::: :: ::: ::: ::::::::::::::::::::::::::::::::::::::
. . .... ..: : :: :: ::: :::::: :::::::::::: : :::::::::::::::::::::::::::::::::::::::::::::
Λ＿Λ . . . .: : : ::: : :: ::::::::: :::::::::::::::::::::::::::::
/:彡ミ゛ヽ;）ー､ . . .: : : :::::: :::::::::::::::::::::::::::::::::
/ :::/:: ヽ、ヽ、 ::i . .:: :.: ::: . :::::::::::::::::::::::::::::::::::::::
/ :::/;;: ヽ ヽ ::ｌ . :. :. .:: : :: :: :::::::: : ::::::::::::::::::
￣￣￣（_,ノ ￣￣￣ヽ､_ノ￣￣￣￣
- 384 名前：仕様書無しさん [2008/07/23(水) 01:06:41 ]
- 【東証のシステム障害、設定ミスをテストでも見抜けず 2008/07/22 】
鈴木CIOは「設定をミスしたのはベンダーの富士通」とした上で、「多数の銘柄に対し板情報の
問い合わせがあった場合をテストケースに含んでいなかったのは我々の責任。もっと幅広く
テストすべきだった」と陳謝した。
itpro.nikkeibp.co.jp/article/NEWS/20080722/311271/
【富士通の開発ミスの全責任は東証にある」とみずほ証券、株誤発注裁判 2008/05/09 】
2005年12月にみずほ証券がジェイコム株の誤発注で出した損失を巡って東京証券取引所を
訴えた裁判の第9回口頭弁論が2008年5月9日、東京地方裁判所で開かれた。
原告のみずほ証券側は、被告の東京証券取引所にシステムの発注者としての注意義務違反と
重過失があったことを改めて主張する準備書面を地裁に提出した。
みずほ証券側は「東証はシステムの発注者として、業務上の要求を富士通に伝え、富士通が
開発したプログラムが要求と整合しているかをテストする責任がある」と訴え、「誤発注の
取り消しができなかったのは東証の重過失だ」と主張した。
：
次回口頭弁論は2008年7月25日の予定だ。
~~~~~~~~~~~~~~~~~~~~~~~~~~
itpro.nikkeibp.co.jp/article/NEWS/20080509/301077/
【「短期間で2回のシステム障害は、痛恨の極み」東証社長が会見 2008/03/25 】
証は2月8日の金融派生商品の取り引きを担う新派生売買システムの障害に続き、3月10日にも
株式売買システムで障害を起こした。
先月22日に新派生売買システムを中心とした障害の再発防止策を発表したばかりだが・・・
itpro.nikkeibp.co.jp/article/NEWS/20080325/297067/
【特集・東証システム問題リンク】
itpro.nikkeibp.co.jp/99/tousyou/index.html
- 385 名前：仕様書無しさん mailto:sage [2008/07/25(金) 03:00:06 ]
- ユニットテストは詳細設計どおりにプログラムが稼働するテストと認識しているんだが、
詳細設計が１ＳＴＥＰ対応の設計書でない場合、全パステストの結果って
どういう扱いになるのかな？
- 386 名前：仕様書無しさん mailto:sage [2008/07/26(土) 01:44:42 ]
- >詳細設計
の確認はうちではユニット-ユニットの結合テストだな
ユニットテスト対象はプログラム設計
ここ→ttp://msugai.fc2web.com/pgm/test.html
のV字モデルに近い
なので全パステストなんて結合テストで考えない
- 387 名前：386 mailto:sage [2008/07/26(土) 01:57:35 ]
- ttp://itpro.nikkeibp.co.jp/article/COLUMN/20051102/223934/
の図1もプログラム設計が書いてないけど同じっぽい
- 388 名前：仕様書無しさん mailto:sage [2008/07/28(月) 11:42:25 ]
- 今日初めて見たが、みんな何か勘違いしてないか？
テストで信頼性は上げられない、テストは
「このプログラムにはバグがあるます」を実証するもので
バグを沢山検出したからと言って、そのプログラムには
もうバグが存在しないと言う実証にはならない。
実際は逆で、統計的に見るとバグ密度の多いプログラムほど
残りの潜在バグが多く含まれている。
テストでは信頼性は旦保できない為、極度に
信頼性が求められるシステムでは、テストをしない開発手法もある。
- 389 名前：仕様書無しさん mailto:sage [2008/07/28(月) 15:31:02 ]
- >>388
asshole
- 390 名前：仕様書無しさん [2008/07/28(月) 18:11:43 ]
- >>388
＞信頼性が求められるシステムでは、テストをしない開発手法もある。
kwsk
|
 |
