SW開発で火を噴くパターン - プログラマの思索
【1】SW開発ではいつも結合テスト以降で火を噴く。 設計、開発、単体テストまで順調であっても、結合テストから受入テストに至るまでに致命的な問題が発覚する。 例えば、下記のような問題がいつでもどこでも噴出するのではないか。 設計書には、複数の画面遷移による業務フローが考慮されていなかった。 業務のインターフェイスがシステムとして整合性が取れていなかった。 シナリオに従ってテストしたら、設計時には気付かなかった業務フローが見つかったり、想定しなかったデータが作られて、その対応が漏れていた。 つまり、設計漏れ。 実際に結合テスト環境で動かそうとすると、そもそも動かない。 実は、DB環境にViewやプロシージャがもれていた。 あるいは、帳票出力やPDF出力、バッチ処理などに必要なサードパーティのライブラリがテスト環境に無かった。 モジュールをビルドして、Webサーバーを再起動する作業が手順化されて
Java400万行の大規模再構築，1年3カ月遅れるも全面稼働 | 日経 xTECH（クロステック）
輸出入リスクに対する保険を提供する日本貿易保険は2007年4月、メインフレーム上で稼働していた保険業務システムの再構築を完遂した。設計、開発は日本IBMが担当。その開発規模はJavaで400万行に上る。仕様漏れによるやり直しから、当初計画より稼働が1年3カ月遅れた。 「『来月にはプロジェクトの遅れを取り戻せる』と先月言っていたが状況は変わっていない。いったいどうなっているんですか」。 ベンダーの経営層が集まるプロジェクト進捗会議の席上、日本貿易保険（NEXI）の情報システム担当理事である大林直樹氏は、保険業務システムの遅れについて日本IBMの役員に問いただした。約2年で完了予定のプロジェクトが、残り半年にきたところで遅れが拡大していた。それとともに、大林理事の不安は膨らんでいった―。 結果的にその不安は現実のものとなる。稼働開始が1年3カ月遅れ、ユーザー、ベンダー合わせて数十億円とみられる
計画には何が盛り込まれていなくてはならないか : SEの残業しない仕事術
2008年02月17日22:08 計画には何が盛り込まれていなくてはならないか カテゴリプロジェクトマネジメント gaseidou2 Comment(0)Trackback(1) ソフトウェアプロジェクトで起こる、 ほとんどの問題は、 計画に起因します。 では、計画には、 どんなことが考慮されていなければならないか。 SECが発行している、 『組込みソフトウェア向けプロジェクトマネジメントガイド[計画書編]』 によれば、 計画書の全体構成は、 以下のようになっています。 ==================================== Chapter1 プロジェクトの概要 1.1 プロジェクトの目的 1.2 プロジェクトの目標 1.3 目標達成のための方針・手段 1.4 プロジェクトの範囲 1.5 プロジェクトの前提条件 1.6 プロジェクトの成果物 1.7 スケジュールと予算 1
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
