システム開発に関する記事とニュース
「再見積もりで工数が2倍!?」~余裕が無いプロジェクトほどトレーサビリティ活動をすべき理由

今回は、もしユーザ主導のトレーサビリティを行わなかった場合、どんな不都合が起こるのか? その重要性についてお話していきます。トレーサビリティは投資や工数見積もりの交渉道具ではありません。ユーザの道具として、正しく使いましょう。

[2009年07月21日]
【拾七】それでもおこってしまったらすみやかに報告を。

 システムトラブルで記者会見といったニュースが後を絶ちません。昨今、システム停止が経営リスクとなっていますが、どのようなトラブルでも、経営危機を引きおこす可能性を持っているのです。トラブルがおこったときの心構えについて考えます。

[2007年10月26日]
【拾六】サービスイン(カットオーバー)時には必ず本番チェックを実施する。

 トラブルには必ず「原因」があり、その原因が作りこまれた誤りを「発見」しなければなりません。またおこってしまったトラブルは、適切に「対策」することが求められます。

[2007年10月26日]
【拾伍】プログラム類の本番移行管理は確実に行う。

 開発、テストがうまく行き、いざ本番!というところで、単純なヒューマンエラーが重大なトラブルを引き起こすことがあります。今回は、これを防ぐにはどうしたらいいかについてお話します。

[2007年10月26日]
【拾四】プログラムの修正が無い場合でもデータの流れるシステムはテスト・確認を実施する。

 トラブルの原因のひとつに「手当て漏れ」があります。人間なので、担当者判断ミスはどうしても起こってしまいますが、そこをテストなどでどう防いでいくことが可能かをお話します。

[2007年10月26日]
【拾参】リグレッションテストは必ず実施する。

 システムに修正を加えた時、今まで動いていたところに影響が出ないことを保証するのが、リグレッションテストです。仕様の変更に伴う修正が入った場合も、システム全体への影響を慎重に考える必要があります。

[2007年10月26日]
【拾弐】必ず原本に戻ってテスト・検証を行う。

 システムの品質を上げるには、テストをしっかり行っておくことが重要ですが、要件定義などに誤りがあれば、決めたとおりに出来ていたとしても誤りの作りこみはおこります。必ず原本に戻ってテスト・検証を行うことが大事です。

[2007年10月26日]
【拾壱】JCL修正のみでも、修正規模が小規模でも テスト、レビューを必ず実施する。

 ほんの些細なミスが、大きな事故を生むのは、システム開発も同様です。理由にならない言い訳を考える前にルールに従い愚直に実行することが大切です。

[2007年10月26日]
【拾】修正時の影響分析は有識者の経験やツールを駆使して入念に行う。

 保守作業において、プログラムを新設、修正する場合、その影響度の調査は念入りに行ってもしすぎるということはありません。ツールやドキュメントを駆使しながら、担当者の暗黙知も考慮しながら、慎重に事を進める必要があります。

[2007年10月26日]
【九】開発メンバーの成果は現物で確認する。

 分業の進んだシステム開発では、何時までにどこが完成するとか、何時どの部分がテスト出来るようになるかといった、各担当による成果物管理が大変重要になります。

[2007年10月25日]
記事をタグで絞り込む
スポンサーサイト