2007年10月30日火曜日

EnterpriseZine : トラブル削減のための原則17条 続き

さっそく更新されてました。前回の続きで第10条から感想などを書き留めておこうと思います。

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

何らかのツールで業務フローとそれに対応する機能、その機能が触るリソース類、をサクサクと参照できるようなツールがあると良いのですが。 リリースから間が無いものだったら良いですが、数年前にリリースされた機能に対する修正なんかだと、ドキュメントの品質がものを言う(しかも大概において足りていない)んですよね。

【拾一】JCL修正のみでも、修正規模が小規模でもテスト、レビューを必ず実施する。

記事の中の見出しにあった中の
難しいときほど用意周到になろう
というのが何を意味するのか?難しいときほど用意周到にってのは当たり前の話で、単なる誤記なのかな?記事の内容自体は反論の余地はありません。

【拾弐】必ず原本に戻ってテスト・検証を行う。

可能であれば、テストケースは前工程の担当者が設定するべきでしょう。例えば、業務要件・事務要件のテストケースは開発依頼側のユーザー担当者が作成し、開発受託担当部門のサポートを得て自分でテストを実施するのが望ましいのです。
これが理想なのですが、実際はこうはいきません。 各フェーズの設計書には常にテストケースを記述する欄を設けて、それが埋まらなければ設計書の完成としないような仕組みを用意するくらいの事ができればよいのですが。さらに、以下の点が重要ですし意識してやっていくべきですから、「要件」「それに対するテストケース」を対で用意し、記入するのは別の担当者で、それぞれでレビューして始めて設計書が完成、という手順を踏むようにするとか?…は面倒ですね、現場からは不満ぶーぶーですね。それでも強制しないことには実現が難しいですしね。TestLinkとかも試して見ましょうかね。
システムテストケースは自分が受け取った前工程のドキュメントから設定し、テストデータを作成

【拾参】リグレッションテストは必ず実施する。【拾四】プログラムの修正が無い場合でもデータの流れるシステムはテスト・確認を実施する。

回帰テストは当たり前の事ですが、各個人にまかせておくとまず実現できませんから、ちゃんと意識してチェックする必要があります。とはいえ、常に全試験を…ともイカンでしょうから、第10条に書かれている「修正時の影響分析は有識者の経験やツールを駆使して入念に行う」によって範囲を絞る必要があります。全てを自動試験できるのであれば、毎回全部流しても良いのでしょうが、人間のUIがから内容はそうはいかんし、一番悩んでるところではあります。 影響範囲については極力「要求:機能:影響対象リソース:関連機能」を管理し、そこから引っ張れる影響範囲は必ず試験対象にする、というようなことを行うことがまず最初の一歩ですかねぇ。このあたりをうまく機械的にできている、仕組みを持っているところの手法を紹介して欲しいですね。

【拾五】プログラム類の本番移行管理は確実に行う。

急がば回れ、が大事ですね、極力、常に一から構築できるような仕組みを用意しておく事が必要だと思います。自動化できるところはできるだけ自動化しておくほうがいいですね、自動化に手間がかかるとしても、自動化できるのであれば手間をかけてでも自動化するほうが良いです。自動化できる事は幸せなことですから。

【拾六】サービスイン(カットオーバー)時には必ず本番チェックを実施する。【拾七】それでも起こってしまった時は速やかに報告を。

あと、何か起こった時の調査には、地道にひとつひとつ調査、という事が大事です。これも急がば回れですね。 17条以外にももうひとつ菊島先生の記事の紹介を。
コメントを投稿