保守・廃棄
要点と定義
保守要件は、保守を受ける側の目的やサービスレベルと、提供する側の実現性・費用を考慮して定める。保守では、問題への対応や改善・機能拡張のため、既存システムやソフトウェアの安全性を維持しながら修正・変更する。保守性は、欠陥の診断、故障原因の追究、修正箇所の特定や変更を行いやすい性質である。
リバースエンジニアリングは、既存のソフトウェアを解析して仕様や設計などの情報を抽出する技術であり、保守では現行コードから仕様情報を得る際に利用できる。
保守性の定量評価では、修正時間の合計を修正件数で割った値が、修正一件当たりの時間の指標となる。 適正規模の基準を満たすプログラム数をプログラム総数で割った割合も、保守性の評価に用いる。
保守のタイプには、是正保守、適応保守、完全化保守、予防保守がある。
適用条件と例
発見された問題や誤りを直すのは是正保守、実行環境の変化に合わせて変更するのは適応保守である。 潜在的な障害が顕在化する前の訂正は予防保守、機能や文書などの品質を高める改善は完全化保守に当たる。
たとえば、仕様書を現行コードに合わせて整備し、文書の整合性や保守性を高める作業は完全化保守に当たる。
廃棄では、運用・保守の支援を終えるか対象を最終状態にし、廃棄後に運用へ支障がないようにしてから、起動不能化、解体または撤去を行う。計画・利用者への通知、必要に応じた新旧環境の並行運用や利用者教育、関連データの保持とアクセス可能性の確保も手順に含まれる。
誤りやすい点
仕様を抽出するために既存プログラムを解析することと、修正箇所や変更の影響を調べることは別の作業である。前者がリバースエンジニアリングに当たる。 また、ソースコードの構造を見直す作業と、仕様情報を抽出する作業も区別する。
保守性の指標を取り違えない。修正一件当たりの平均時間と、適正規模のプログラムの割合は保守性の評価に使える一方、不具合密度、分岐網羅率、残存エラー数の推定は、それぞれ別の観点の指標である。
保守タイプは、作業の目的で判別する。問題発見後の訂正は是正、将来の障害を防ぐ訂正は予防、環境変化への対応は適応、問題が顕在化していない段階での品質改善は完全化に当たる。
ここまでが冒頭部分です。ログインすると、無料でも1日2節まで全文をお読みいただけます。
アプリでこの節を読む