2008_06_05－品質管理とライブラリ管理。

２００８年６月５日発行

分割ラインです

　《　品質管理編　》

　　
　品質管理とライブラリ管理
　　
　　
　　大規模プロジェクトでは、当たり前に行われているライブラリ管理
　　このライブラリ管理が、うまく行われていない
　　または、小規模プロジェクトでは、個人の責任において行われている
　　ようなところではライブライ管理ミスによる弊害がいろいろ発生して
　　いるのです。
　　小さいところではＷｅｂ開発などでも同じです。
　　
　　
　　
　　試験工程に入ってから故障対応を行っていると、
　　　・モジュールが先祖帰りして、対応済みの故障が元に戻ってしまった。
　　　・最新ではない、いつ時点か不明のソースが存在する。
　　　・管理するライブラリの種類が多いため同期ズレが起こってしまった。
　　　・バックアップするライブラリの内数個を忘れた。
　　　・リカバリのためにバックアップから戻したら複数のライブラリ間で
　　　　　同期がズレてしまった。
　　　・バックアップから戻したが、どこまで故障対応したのかわからない。
　　　・同じ故障対応を何度も行っている。
　　　・削除済みモジュールの実行が要求され異常終了となる。
　　
　　
　　
　　このようなライブラリ管理の不手際による品質不良の増加は
　　　　　　　隠れていますが、結構どこでも発生している管理不良です。
　　
　　　主な原因は
　　　　(1)ライブラリ管理者がいない。
　　　　(2)スケジュールが遅れて、ルール違反行為が日常化している。
　　　　(3)管理手順がしっかり定まっていない。
　　　　(4)モジュールの修正履歴がない。
　　　　(5)修正履歴とライブラリ管理のバックアップタイミングが
　　　　　リンクしていない。
　　　　(6)故障報告書がないため、横展開の対応状況がわからない。
　　
　　
　　(4)(5)(6)は、モジュールの信頼性に影響し品質管理上の重要な
　　　　　　　　　　問題です。最悪の場合は、再試験になります。
　　
　　
　　
　　ライブラリ管理業務は、
　　　　故障対応の終了タイミングを待たなければなりません。
　　　　緊急度・重要度ともに高い場合は、故障対応の終了をまってから
　　　　コンパイルや試験環境モジュール入れ替えを行わなければなりません。
　　　　縁の下ですが、重要な役割を担っているのです。
　　
　　
　　品質管理の要となる管理業務です。
　　小さいプロジェクト程、ライブラリ管理が疎かになりがちです。
　　　　甘くみると結構痛い目にあうことになります。
　　　　　　作業方法の信頼性を疑われます。
　　
　　
　　
　　小さいプロジェクトと言えども、
　　　　・故障報告と修正履歴ルールの徹底
　　　　　　　追跡調査可能なようにしておく
　　　　・ライブラリ変更ルールの確立と運用の徹底
　　　　　　　個人の勝手な変更を許さない
　　　　・コンパイルなどの試験環境への反映ルールの確立
　　　　　　　作業手順を周知して全員に従っていただく
　　　　・退避と復元のルールの確立と運用の徹底
　　　　　　　管理基準を公開して全員が無駄な作業を行わないようにする
　　
　　　　　　　　　　　　以上は、しっかり行わなければなりません。
　　
　　
　　
　　開発側に著しい品質不良チームがいることにより
　　　　ライブラリ管理チームへの負荷が高くなることも考慮してください。
　　　　それが仕事かも知れませんが、直接の要因ではない所で頑張っています。