アカウント名:
パスワード:
工程をいくつに分けるかとかは規模でも変わってくるだろうけど
・バグ管理とかを工程ごとに分けてチェックして品質をきちんと確保できてから、下流のフェイズに移行する
というのが鉄則だろうと。
ウォーターフォールのメリットは、あとどれくらいでアウトプットが出せるのか、現時点でどれくらい遅れているのかが把握しやすいということ。デメリットは、上流のバグが下流で見つかるととんでもない時間ロスをすること。なので、上流がいい加減だとそのプロジェクトは必ず火を噴く。
納期、予算を計画的に配分している場合はウォーターフォールのメリットが強く生きる。一
結局はオムニ7の脆弱性が問題だったわけで。
7payを作り出すときに決済アプリを作りますよ。認証は既存システムのID使うよって言われたらじゃあ認証の性能保証はそっちでやるんだ。うちの仕事じゃないなって思うもん。え、そっちで担保してくれるんじゃないの?そこでワザワザ、これから繋ごうとしてるシステムに問題がないかアセスメントなんかやんないよ。
想像だけどさ
下請けがオムニ7の方も調べて問題点を報告しても、その下請けが管轄外の、即ち無意味な報告出してきたって事で減点してお仕舞い、てなりそ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
私の知ってるウォーターフォールモデル (スコア:1)
工程をいくつに分けるかとかは規模でも変わってくるだろうけど
・バグ管理とかを工程ごとに分けてチェックして品質をきちんと確保できてから、下流のフェイズに移行する
というのが鉄則だろうと。
ウォーターフォールのメリットは、あとどれくらいでアウトプットが出せるのか、現時点でどれくらい遅れているのかが把握しやすいということ。
デメリットは、上流のバグが下流で見つかるととんでもない時間ロスをすること。なので、上流がいい加減だとそのプロジェクトは必ず火を噴く。
納期、予算を計画的に配分している場合はウォーターフォールのメリットが強く生きる。
一
しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
Re:私の知ってるウォーターフォールモデル (スコア:2, すばらしい洞察)
結局はオムニ7の脆弱性が問題だったわけで。
7payを作り出すときに
決済アプリを作りますよ。認証は既存システムのID使うよって言われたら
じゃあ認証の性能保証はそっちでやるんだ。うちの仕事じゃないなって思うもん。
え、そっちで担保してくれるんじゃないの?
そこでワザワザ、これから繋ごうとしてるシステムに問題がないかアセスメントなんかやんないよ。
想像だけどさ
Re: (スコア:0)
下請けがオムニ7の方も調べて問題点を報告しても、
その下請けが管轄外の、即ち無意味な報告出してきたって事で減点してお仕舞い、てなりそ。