システム構築プロジェクトの各フェーズにおける注意点

①提案・計画
・複数案提案し、お客様に選択してもらう
・オススメはハード更改案、前回同額案、理想案、推奨案
・理想案は不採用が濃厚であっても、次回の更改に向けての課題明確化と、自らの技術的な知見をアピールすることで長期的に良好な関係を築けるかもしれない
・選択された案だけでなく、選択されなかった案がどういう理由で選択しないかをお客様と合意することも大事

・コストの計算にはシステム更改後の運用コスト、データセンターの空調・電力、ネットワーク費用、移行のコストなどもある

②要件定義
・未決定の要件は必ず仮決めをする
・リスクを減らすために「使う」「活用する」「作る」の順で考える
・日付またがりの処理に要注意
・オンラインとバッチの並行処理の要否検討。キャパシティ要件に関わる。
・資料は少ない枚数に凝縮したほうがよい
・製品の選定も複数候補を比較して決める
・新バージョンの製品ではできなくなったことも確認する
・製品選定の時点で移行のことを考えないと、特にストレージ製品ではデータ移行がスムーズにいかない可能性もある
・移行に業務停止を伴う場合はこの段階でお客様に伝える
・移行方針は要件定義完了時点で明確化しておく 
 
③設計
・障害時のシステムの可用性を考える(ハードウェア、ソフトウェア、ネットワークの冗長化、災対環境への自動切り替え)
・キャパシティ設計への影響としてオンラインとバッチの競合が大きい
・メジャーな方法を取らない場合、なぜメジャーな方法にしなかったかを書いたほうがよい
 
 
④構築
・インフラの構築はクリティカルパスになる場合がほとんどなので肝に命じておく
・システムパラメータは設計書より現物を見たほうがいい。とりあえず実機から全パラメータの取得はやっておいたほうがよい
 
⑤テスト
・テスト工程ごとにテスト環境と本番環境のどこが違うかは意識しておくべき
・システムテストからは本番と同等の環境を用意すべき
・動かし続けることでわかる不具合もある
・同じ稼働スケジュールで動かさないとわからない問題もある
・サービス開始日を想定したテストを考える
・現行システムの世代を受け継ぐのか、それとも1から開始するのか
・ハードウェアの交換は誰がどこまでやるのか明確に
・受け入れ確認テストの計画を忘れずに
 
⑥移行
・システム内のハードウェアの一部を交換する場合、交換しない方の使い続ける側のハードウェアでの変更作業が漏れやすいので気をつける
・移行は3つの視点で考える。システム移行、データ移行、アプリケーション移行
・移行方針は要件定義完了時点で明確化しておく
・移行リハで移行手順を全て確認する
・段階移行の検討。メリットはリスクの局所化、デメリットは現行と新の並行稼働
スポンサーリンク
勉強wikiの下部広告
  • このエントリーをはてなブックマークに追加
スポンサーリンク
勉強wikiの下部広告

コメントをどうぞ

メールアドレスが公開されることはありません。

CAPTCHA