3.7 ソフトウェア保守

概要と動機

ほとんどのソフトウェアは、その寿命の圧倒的大部分を、作られることではなく、保守されることに費やします。システムが本番に入った瞬間、欠陥を直し、変化する環境に適応し、すでに動いているものを改善し、将来の問題を防ぐ、フェーズ(しばしば何年も何十年も続く)に入ります。大きな企業、特に政府では、このフェーズが支配的です。税のエンジン、給付のシステム、防衛のプラットフォーム、中核の財務の元帳は、それを発注した誰もが予想したより、日常的にはるかに長く保守されます。ソフトウェア保守とは、納品されたソフトウェアを、その運用寿命の全体にわたって、正しく、最新で、価値あるものに保つ規律です。

保守は慢性的に過小評価され、過小に価値づけられており、その間違いは高くつきます。何十年にもわたる研究が繰り返し、保守を生涯ソフトウェアコストの優に半分以上に位置づけ、長寿命のシステムでは一般に60から90パーセントの範囲と引用されます。それでも組織は、初期の構築が全体の事業であるかのように計画し、予算を組み、人員を配置し、祝います。そしてその後のすべてを後付けとして扱い、縮んでいく予算から資金を出し、空いている誰かに割り当てます。結果は予測どおりです。脆いシステム、意欲を失った保守担当者、増え続ける変更のコスト、そして最終的に、実はずっと管理されていない保守の問題だったのに、「レガシーの問題」(3.6章)として枠づけられる危機。

本章は、SWEBOK(ソフトウェアエンジニアリング知識体系)のソフトウェア保守の知識領域とISO/IEC 14764に従います。保守の基礎と認められた四つのカテゴリ、コスト、人員配置、士気を含む保守を難しくする主要な問題、保守のプロセス、プログラム理解、リエンジニアリング、リファクタリングという中核の技法、保守コストをどう見積もるか、そして(本章で最もてこの効く考え方である)最初から保守性のためにどう設計するかを扱います。中心的な信念は、保守はエンジニアリングに続く劣った活動ではないということです。それはソフトウェアエンジニアリングの最大の部分であり、そのように計画され、資源を与えられ、尊重されなければなりません。

主要原則

保守はライフサイクルの大部分であり、エピローグではない。 初日から計画し予算化します。それは構築より多くのコストがかかります。
四つのカテゴリは異なる仕事である。 是正、適応、完全化、予防の保守は、異なる駆動要因と周期を持ちます。労力の大半はバグ修正ではありません。
理解していないものは変更できない。 プログラム理解は保守における最大の単一の活動です。コードとその履歴を読めるようにします。
保守性は設計の性質である。 将来の変更のコストは、おもに構築の間に下された決定によって決まります。意図してそのために設計します。
小さく安全で継続的な変更は、先送りされた大きな変更に勝る。 変更の負債を積み上げるのではなく、テストの安全網のもとで漸進的にリファクタリングし、モダナイズします。
ソフトウェアは、じっとしていても老いる。 環境(依存関係、プラットフォーム、規制)が動くので、静的なシステムは静かに腐ります。予防の保守は本物の仕事です。
保守担当者には第一級の地位がふさわしい。 保守チームの士気、知識の保持、人員配置が、長期のコストとリスクを直接決めます。

推奨事項

保守の四つのカテゴリを区別し、そのすべてのために人員を配置する

ISO/IEC 14764とSWEBOKは四つのカテゴリを認めており、それらの混同は一般的な計画の誤りです。是正保守は、運用で見つかった欠陥を直します。適応保守は、環境が変わるにつれてソフトウェアを動かし続けます。新しいオペレーティングシステム、ブラウザ、依存関係、ハードウェア、規制、接続するシステム。完全化保守は、新機能、より良い性能、改善された使いやすさ、強化された保守性を通じて、ユーザーと保守担当者のためにソフトウェアを改善します。予防保守は、潜在的な欠陥を是正し、顕在化する前に将来のリスクを減らします。堅牢化、片付け、脆弱な領域のモダナイゼーションを通じて。有用なさらなる分類は、是正と予防を訂正(欠陥を扱う)、適応と完全化を拡張(新しい要求を扱う)としてまとめます。決定的に、経験的な研究は一貫して、保守の大半は是正ではないこと、拡張と適応が支配的であることを見出しています。それに応じて予算を組み人員を配置し、労力が実際にどのカテゴリに落ちるかを追跡して、それを管理できるようにします。

プログラム理解に投資する

保守における最大の単一の活動は、安全に変更できるほど既存のシステムを理解することです。保守担当者は日常的に、コードを修正するよりも、読んで推論することに多くの時間を費やします。これを意図して安くします。ドキュメントをコードの近くに置いて最新に保ちます(2.7章)。アーキテクチャ決定記録(1.6章)ときれいなコミット履歴(2.6章)で決定の履歴を保存します。静的解析、依存関係グラフ、コードのナビゲーションツールを使って、見慣れない領域をマップします。特性化テスト(癖を含む現在の振る舞いを固定するテスト)は、暗黙の理解を、実行可能で持続的な知識に変えます。理解が高価なとき、あらゆる変更は遅く危険です。それが安いとき、保守は日常になります。

テストの安全網のもとで継続的にリファクタリングする

リファクタリングは、外部の振る舞いを変えずに、コードの内部の質を改善する規律ある再構成です。小さなステップで継続的に行えば、複雑さへの自然なずれに対抗し、変更のコストを上昇させず平らに保ちます。交渉できない前提条件は、信頼できる自動テストスイート(2.4章)です。それがなければ、「リファクタリング」は単に危険な書き直しです。リファクタリングを日々の仕事に織り込みます。まれで大きく危険な片付けのために取っておくのではなく、各モジュールを見つけたときより少しきれいにして去る。これは実践における予防保守であり、存在する中で最も安い保守です。

漸進的な変更ではもう足りなくなったら、リエンジニアリングする

コンポーネントが、日常的な変更があまりに高価または危険になるまで劣化したとき、リエンジニアリング(システムを調べ変更して、新しい形に再構成すること)がより重い道具です。リエンジニアリングは通常、リバースエンジニアリング(実装から設計と意図を回復する)と、順方向のリエンジニアリング(振る舞いを保存しながらより良い構造に再構築する)を組み合わせます。全面的な書き直しではなく、ストラングラーフィグや抽象化によるブランチ(3.6章)のようなパターンを使って、限られた漸進的なスライスでリエンジニアリングすることを好みます。リエンジニアリングは、保守からモダナイゼーションへの連続体にあります。小さく局所的なものにはリファクタリング、構造的なものにはリエンジニアリング、プラットフォームレベルにはモダナイゼーション。

定義された保守プロセスを運用する

保守は、ISO/IEC 14764に述べられているように、明示的で繰り返し可能なプロセスから利益を得ます。プロセスの実装(計画と手順の確立)、問題と変更の分析(トリアージ、再現、影響とコストの評価)、変更の実装、保守のレビューと受け入れ、移行、そして退役。それを規律ある変更管理で包みます。あらゆる保守の要求(欠陥の報告であれ拡張であれ)は、記録され、カテゴリで分類され、影響を評価され、優先順位付けされ、テストを伴ってバージョン管理のもとで実装され、レビューされ、通常のパイプライン(11.2章)を通じてリリースされるべきです。影響分析、つまり提案された変更が触れるかもしれないすべてを理解することは中心的で、本物の労力に値します。退役もプロセスの一部です。システムを安全に廃止し、データとユーザーを移行し、記録を保存することは、場当たりではなく計画しなければならない保守の仕事です。

保守コストを明示的に見積もり、資金を出す

保守を無料として、あるいは構築の予算の雑音として扱ってはいけません。見積もってください。一般的なアプローチには、保守の労力の比率(年間の保守が元の開発コストのおよそ15から25パーセントという広く使われる経験則。ただし長寿命の重要なシステムは、その生涯でははるかに多く積み上げます)、保守と再利用の拡張を伴うCOCOMO II(構築的コストモデル)のようなパラメトリックなモデル、そして欠陥率、変更の量、変更のコストについての自社の過去のデータに基づく指標駆動の予測が含まれます。これらの見積もりを総所有コストの分析と10.10章で議論される経済学に反映します。システムの購入価格や構築コストは頭金です。住宅ローンは保守であり、すべてのビジネスケースに現れるべきです。

最初から保守性のために設計する

保守コストに対する最大のてこは、保守が始まる前に働きます。保守性(ISO/IEC 25010の語彙では、解析性、修正性、テスト容易性、モジュール性)は、偶然の産物ではなく、明示的な要求でなければならない設計の質です。モジュール化された、疎結合で高凝集の設計(2.2章)、明確なインターフェースと関心の分離、強い自動テスト、読みやすいコードと最新のドキュメント、そして運用者と保守担当者がシステムが何をしているかを見られるようにする豊かなオブザーバビリティ(第9部)を好みます。これらの決定のそれぞれが、システムが実際に生きる数十年にわたる大きく複利で効く節約と引き換えに、今の少しの追加の労力を取引します。保守性のために築くことは、ライフサイクル全体で最も見返りの高い投資です。

トレードオフ: 長所と短所

アプローチ	長所	短所
継続的なリファクタリング / 予防保守	変更のコストを平らに保ち、リスクを減らし、ROIが高い	目に見える新機能のない継続的な労力。強いテストが必要
保守の先送り(「明かりをつけておく」)	今四半期は最も安い。機能のための容量が空く	変更の負債が複利で増える。最終的な危機と強いられる高価な行動
劣化したコンポーネントのリエンジニアリング	保守性を回復し、有用な寿命を延ばす	相当な労力とリスク。振る舞いを慎重に保存しなければならない
前もっての保守性のための設計	複利で効く生涯の節約。将来のあらゆる変更が容易になる	初期コストと規律が高い。利益は先送りされ、目に見えにくい

保守における繰り返されるトレードオフは、現在のコストと将来のコストであり、誘惑は常に先送りへ向かいます。リファクタリングを飛ばし、依存関係を古くし、保守チームを飢えさせることは、すべて今四半期は無料に見えます。請求書は後で届くからです。より遅く、より危険で、より高価なシステムとして、そして最終的に「レガシーの危機」として。良い保守の規律は、後の大きく突然のキャリアを左右するコストを避けるために、今、小さく継続的で目に見えるコストを払うことです。節約は先送りされ見えないので、この取引には、ローンチの日付だけでなくライフサイクルの経済学を理解するリーダーシップが必要です。

チームで議論すべき問い

予算の中の保守の数字は誰が所有し、それは第一級の項目ですか。それとも、構築が使わなかったものから削り出された残りですか。 保守は生涯コストの大半で、長寿命のシステムでは一般に60から90パーセントですが、日常的に後付けとして資金が出され、空いている人が担当します。予算が残りのものだと、予防の仕事が最初に削られ、変更の負債が複利で増え、予測可能な「レガシーの危機」への滑落が続きます。実際の見積り(保守の労力の比率、パラメトリックなモデル、自社の過去の変更コストのデータ)を持ち込み、システムの寿命にわたってそれに資金を出す責任者を名指ししてください。直し方は、購入価格の隣に住宅ローンがあるように、すべてのビジネスケースで保守を明示的に予算化することです。ローンチしか祝わないリーダーシップは、お金とリスクの大半が実際に存在するフェーズへの資金不足を続けます。
予防保守のために容量を確保していますか。それとも、常に次の機能に負けますか。 予防の仕事(テストの安全網のもとでのリファクタリング、依存関係を最新に保つこと、脆弱な領域の堅牢化)は、変更コストの曲線を上昇させず平らに保つので、存在する中で最も安い保守です。また、先送りするのが最も簡単です。飛ばすことは今四半期は無料に見え、請求書は後で、より遅く危険なシステムとして届くからです。具体的な仕組みが役立ちます。常設の割り当てで、多くの強いチームは容量のおよそ5分の1を守り、スプリントごとに交渉で手放されないようにします。証拠として変更コストの傾向を持ち込んでください。上昇しているなら、すでに投資不足です。規律は、後の大きく突然のキャリアを左右するコストを避けるために、今、小さく目に見えるコストを払うことで、それにはローンチの日付ではなくライフサイクルの経済学を読むリーダーシップが必要です。
システムを退役させる計画は何で、最後に実際に廃止したのはいつですか。 退役は保守プロセスの明示的な一部です(データ移行、ユーザーの切り替え、記録の保存、安全な停止)が、組織は、廃止が地味で予算化されていないために、死んだ冗長なシステムを何年も抱えます。すべてのゾンビシステムは、なおライセンス、セキュリティパッチ、統合の表面、他の場所にいられたはずの人々の注意を消費します。一覧を持ち込み、アクティブなユーザーがいない、あるいは完全な置き換えがすでに稼働しているシステムに印を付け、それらの停止を他の仕事と同様に計画してください。データを移行し、法令が求めるものを保存し、何も依存していないことを確認します。特に政府では、記録の保持法が退役の仕方を形づくるので、早期にコンプライアンスを巻き込んでください。追跡する価値のある成熟度のシグナル。組織が最後に意図して何かを停止したのはいつか。
すべての変更のどれだけが、触れる前にシステムを理解することに費やされ、最も重要なシステムのバスファクターは何ですか。 プログラム理解は保守における最大の単一の活動で、そのコストは、コード、その履歴、その振る舞いをどれだけ読める状態に保ってきたかで決まります。理解が少数の長く在籍する頭の中にだけあるとき、各離職や退職が将来のあらゆる変更の価格を上げ、一人の不在が重要な修正を止めえます。証拠を持ち込んでください。最近の変更での、読み推論する時間と編集する時間の比、各中核のモジュールを安全に変更できる人の数、ビジネスルールと決定がコードと並べて文書化されているか、毎回記憶から再構成されているか。相反する考慮は、ドキュメントと特性化テストが、後にしか現れない節約のために今労力がかかるので、飛ばしやすいことです。システムが元の作者より何十年も長生きし、法定のルールが誰も完全には覚えていない計算エンジンの中に埋まっている企業や政府では、捉えられた理解(アーキテクチャ決定記録、特性化テスト、最新のドキュメント)を、誰かに余裕があるときに起こる礼儀ではなく、意図して資金を出す資産として扱ってください。
保守の仕事に実際に人員を配置しているのは誰で、その地位と士気は重要性に見合っていますか。 保守は生涯コストの大半で、存在する中で最も難しいエンジニアリングです。自分で作っておらず完全には理解していないかもしれないシステムを安全に変更するのですが、日常的に最も経験の浅い人々に渡され、低い地位の「明かりをつけておく」こととして枠づけられます。そのシグナルは腐食的です。最良のエンジニアがその仕事を避け、知識が集中し、それから扉の外へ去り、誰も見ていない間に変更のコストが上昇します。最も長寿命のシステムを誰が保守しているかの年次構成、離職と知識保持のデータ、保守があなたの組織でキャリアの行き止まりか尊重される専門性かについての誠実な読みを持ち込んでください。緊張は本物です。野心的なエンジニアは新しいものを作りたく、リーダーは起動を祝いたいので、保守を尊重するには意図した構造が必要です。規制上および財務上のリスクを何十年も担うシステムを運用する大きな企業や公的機関にとって、尊敬される上級エンジニアを保守に配置することはリスク管理の決定であり、保守が罰としての配置になることは、次のレガシーの危機を製造する道です。
労力が実際に四つのカテゴリのどれに落ちるかを追跡し、変更コストを先行指標として測定していますか。 チームは日常的に、保守をほぼバグ修正であるかのように計画しますが、経験的な研究は拡張と適応が支配的だと示しているので、是正の仕事だけに資金が出されるポートフォリオは、最初から範囲を誤っています。カテゴリの追跡がなければ、システムが規制への適応の着実な流れによって作り変えられていることが見えず、変更コストの指標(変更のリードタイム、変更失敗率、複雑さの傾向)がなければ、曲線が平らなのか、静かに危機へ向かって上昇しているのかがわかりません。昨年の実際のカテゴリの内訳、持っていれば変更コストの傾向、影響分析が本物のステップか、締め切りの圧力のもとで飛ばされる形式かについての誠実なメモを持ち込んでください。相反する引力は、測定自体が労力を要し、システムがまだ動いているときにはオーバーヘッドに感じられうることです。多くのチームが多くのシステムを保守し、そのどれか一つの上昇するコスト曲線が行動に値する早期警告である企業や政府のポートフォリオでは、共有のカテゴリの追跡と変更コストの指標が、リーダーシップが、モジュールが公に失敗した後ではなく、劣化する前にリエンジニアリングできるようにするものです。

セクター別の視点

スタートアップ。 少数のエンジニアで余裕のないランウェイでは、重い保守プロセスを負担できませんが、誰も触れないコードベースも負担できません。各サイクルの小さな常設の一部(おおよそ5日に1日)を予防の仕事のために確保します。依存関係にパッチを当て、小さな欠陥を複利で増える前に片付け、すでに恐れている一角を、あるテストのもとでリファクタリングする。目標は、ピボットする間コードを変更に安く保ち、20人のエンジニアになったとき、先送りされた保守を「レガシーの問題」と取り違えて目覚めることがないようにすることです。

小規模事業者。 専任の保守の専門家はおらず予算も厳しいので、作るよりも買ってホストすることに傾き、適応保守(セキュリティパッチ、プラットフォームと依存関係の更新)が大部分は他の誰かの仕事になるようにします。自分でコードを所有する所では、小さく、退屈で、よく文書化されたものに保ち、事業が依存するものは少なくとも二人が理解しているようにします。失うわけにいかない少数のシステムを追跡し、保守が無料のふりをするのではなく、それらを最新に保つための控えめで明示的な項目を予算化します。

大企業。 規模では、多くのチームにわたって多くの長寿命のシステムを保守しているので、優先事項は、定義された繰り返し可能なプロセスです。記録されトリアージされる要求のパイプライン、四つのカテゴリへの分類、日常的な影響分析、交渉で手放されずに守られる常設の予防の割り当て。保守を第一級のプログラムとして資金づけ、ポートフォリオ全体で変更コストの指標を測定し、上昇する曲線を、モジュールが負債になる前にリエンジニアリングするきっかけとして使います。ガバナンスと監査の期待は、カテゴリの追跡と変更記録がオーバーヘッドではなく、資産が管理下にあるという証拠であることを意味します。

政府。 調達規則、透明性、公的な説明責任が、エンジニアリングと同じくらい保守を形づくります。制定法に駆動される適応保守は、ずらせない厳しい年次の期限とともに届くので、保守を無期限の運用コストとして予算化し、作者がとうに退職したルールの知識を保持する安定した専門家チームを配置します。退役は記録の保持法に制約されるので、最初からコンプライアンスとともに廃止を計画し、数十年にわたって単一のベンダーに縛りつけるのではなく、システムを保守可能で可搬に保つ契約とアーキテクチャを好みます。

事例

スタートアップ。 MVPを出荷したばかりのスタートアップは、すべての時間を新機能に注ぎ込みたい誘惑に駆られますが、創業エンジニアは最初の月から、スプリントごとの常設の一部(おおよそ5日に1日)を保守のために確保します。その予算が、依存関係にパッチを当て、小さな欠陥を複利で増える前に片付け、チームがすでに恐れている一角をリファクタリングするので、製品がピボットする間もコードベースは変更に安いままです。これを飛ばすスタートアップは、誰も触りたくないコードベースとともに20人のエンジニアに達し、それが実はずっと先送りされた保守だったのに、「レガシーの問題」と取り違えます。

大企業。 グローバルな銀行が、15年間本番にある決済プラットフォームを運用しています。保守を、残りの予算項目ではなく、恒久的な第一級のプログラムとして資金づけています。仕事は四つのカテゴリにトリアージされます。新しい規制とパートナー銀行のインターフェースの更新を追う適応的な変更の着実な流れ、機能を加えスループットを改善する完全化の仕事、厳格なサービスレベル合意(SLA)に対して欠陥を片付ける是正の仕事、そして包括的なテストスイートのもとでの継続的なリファクタリングを通じて複雑さを返済する、常設の予防の割り当て(チームの容量のおよそ5分の1)。チームは変更のリードタイムと変更失敗率を測定し、上昇する変更コストを、モジュールが負債になる前にリエンジニアリングする早期警告として扱います。保守担当者は、「明かりをつけておく」ことに配置された若手職員ではなく、上級の評価の高いエンジニアです。

政府。 国の税務当局が、30年以上稼働し、税法が変わるたびに毎年改正されるシステムを保守しています。ここで支配的なカテゴリは、制定法に駆動される適応保守で、ずらせない厳しい年次の期限があります。当局はプログラム理解に大きく投資しています。ビジネスルールはコードと並べて文書化され、特性化テストが、元の作者がとうに退職したルールの振る舞いを固定し、計算エンジンへのあらゆる変更の前に、影響分析が正式なステップです。環境(法律)が継続的に変わるので、システムは決して「完成」しえず、当局は保守を無期限の運用コストとして予算化し、知識を保持する安定した専門家チームを配置し、中核が存続する間も、ソース管理、継続的インテグレーション(CI)、自動テストといった周囲のデリバリーの実践をモダナイズします。

ビジネスケース: 動機、ROI、TCO

ソフトウェアの中核のビジネス上の事実は、お金が行くのは構築ではなく保守だということです。業界全体で、何十年もの研究にわたって、保守は生涯コストの明確な大半を占め、長く生きるシステム(企業と政府ではそのほとんど)で、しばしば60から90パーセントと引用されます。稼働開始で止まる総所有コストの分析は、数倍ずれています。保守を真剣に受け止める主要なビジネスケースは、単に正確さです。システムの全寿命のために予算を組むか、繰り返し請求書に驚かされるか。

投資収益は、コスト曲線を曲げることから来ます。放置されたシステムでは、複雑さが積み上がり理解が衰えるにつれて、各変更のコストは時間とともに上昇し、変更が法外に遅く危険になるまで続きます。よく保守されたシステムでは、継続的な予防の仕事(リファクタリング、依存関係の最新性、テストカバレッジ、ドキュメント)がその曲線を平らに保つので、千回目の変更は、十回目とほぼ同じコストです。保守性と予防保守への投資は、したがって最小化すべき費用ではありません。システムが変更に手頃なままか、レガシーの資産(3.6章)と10.4章の持続的な課題の、増え続けるコストとリスクにずれていくかを決めるてこです。保守に意図して資金を出し、変更コストを先行指標として測定し、上昇する曲線を自然の事実ではなく行動のシグナルとして扱ってください。経済学は10.10章でさらに扱います。

アンチパターンと落とし穴

保守を後付けとして扱う。 構築だけを予算化して祝い、はるかに大きく長い保守のフェーズを飢えさせること。
最も経験の浅い人々を保守に配置する。 最も難しい仕事(完全には理解していないシステムを安全に変更すること)を、最も備えのない人々に割り当て、保守は低い地位だと示すこと。
保守とバグ修正の混同。 適応と拡張が実際には労力を支配するのに、是正の仕事だけを計画すること。
予防保守を無期限に先送りする。 リファクタリングも依存関係の更新も決してせず、変更の負債が高価な危機を強いるまで続くこと。
影響分析なしにコードを変更する。 他の場所で予期しない失敗に波及する「小さな修正」を行うこと。
テストの安全網なしのリファクタリング。 振る舞いが保存されたことを証明する方法なしにコードを再構成すること。それは単に危険な書き直しです。
知識が扉から出ていくのを許す。 ビジネスルールと決定を文書化せず、すべての退職や離職が将来のあらゆる変更のコストを上げること。
何も退役させない。 廃止が地味で計画されていないために、死んだ冗長なシステムを永遠に抱えること。

成熟度モデル

レベル1: 開始。 保守は計画も資金もなく、空いている誰かによって反応的に扱われます。バグ修正と見なされ、低い地位の仕事です。カテゴリの追跡も、コストの見積りもなく、知識は少数の頭の中にあります。変更のコストは、修正が止まるか危機が注意を強いるまで、気づかれずに上昇します。
レベル2: 発展。 一部のチームは保守の要求を記録しトリアージし始め、予算項目を持っていますが、実践は組織全体で一貫せず、予算はたいてい残りです。是正の仕事は追跡されますが、適応と完全化の労力は明確に区別されません。一部のテストとドキュメントが局所に存在するので、変更は部分的に管理されていますが、理解はチームごとに高価で不均一なままです。
レベル3: 標準化。 定義された保守プロセス(ISO/IEC 14764に従う)が文書化され、組織全体で徹底されています。仕事は四つのカテゴリに分類され、影響分析と変更管理は日常的で、保守はすべてのビジネスケースで明示的に見積もられ資金づけされます。予防保守とリファクタリングは堅固なテストスイートのもとの標準の実践で、保守性(解析性、修正性、テスト容易性、モジュール性)は、局所的な習慣ではなく明示的な設計要求です。
レベル4: 管理。 保守がベースラインに対するデータで測定され、制御されています。変更コストの指標(変更のリードタイム、変更失敗率、複雑さと欠陥の傾向)がシステムごとに追跡され、四つのカテゴリの労力の内訳が期待に対して定量化され、保守の労力の比率とパラメトリックな見積りが、実際の過去の変更コストに対して確認されます。上昇するコスト曲線は先行指標として検出されて行動を引き起こし、予防の割り当ては推測ではなく証拠から大きさが決められます。リファクタリング、リエンジニアリング、退役の決定は、直感ではなく測定された閾値に基づいて行われます。
レベル5: オーケストレーション。 保守は継続的に改善され、組織全体とそのライフサイクルの経済学に統合されています。ライフサイクルのTCOがポートフォリオの投資を駆動し、リエンジニアリングはコンポーネントが劣化する前に意図して適用され、知識は積極的に保持され、退役は計画され日常的に実行されます。組織は環境(規制、プラットフォーム、依存関係)の変化に応じて保守の労力を再均衡させ、保守担当者は尊敬される上級エンジニアで、資産全体が適応して、数十年生きるシステムにわたって変更のコストが平らに保たれます。

議論のためのアイデア

エンジニアリングの労力のどれだけが実際に保守に行き、予算と人員配置はその現実を反映していますか。
保守の仕事を四つのカテゴリに分けられますか。そしてその内訳は想定に合っていますか。
典型的な変更のどれだけがシステムを理解することに対して修正することに費やされ、何が理解を安くしますか。
変更のコストは時間とともに上昇、平坦、下降のどれで、そもそも測定していますか。
チームには継続的なリファクタリングを安全にする信頼できるテストの安全網がありますか。それとも、再構成は試みるには危険すぎますか。
最も長寿命のシステムを誰が保守し、その知識はどう捉えられ、その仕事の地位と士気はどうですか。

要点

保守はソフトウェアの生涯コストの大半(長寿命のシステムでは一般に60から90パーセント)であり、第一級の活動として計画し、予算化し、人員を配置しなければなりません。
四つのカテゴリ(是正、適応、完全化、予防)は別個の仕事で、バグ修正ではなく、拡張と適応が通常支配的です。
プログラム理解は最大の単一の保守活動です。あらゆる変更を安く保つために、コード、履歴、振る舞いを読めるようにします。
テストの安全網のもとで継続的にリファクタリングし、劣化したコンポーネントを漸進的にリエンジニアリングして、変更のコストを平らに保ちます。
保守コストを明示的に見積もり、総所有コストと経済的な決定に反映します。
最初から保守性のために設計し(それはライフサイクル全体で最も見返りの高い投資です)、保守担当者を、そうあるべき上級の専門家として扱います。

参考文献とさらなる読み物

IEEE Computer Society, SWEBOK Guide (Software Engineering Body of Knowledge), Software Maintenance knowledge area
ISO/IEC 14764 / IEEE 14764, Software Engineering: Software Life Cycle Processes, Maintenance
ISO/IEC 25010, Systems and software Quality Requirements and Evaluation (SQuaRE): maintainability quality characteristics
Martin Fowler, Refactoring: Improving the Design of Existing Code
Michael Feathers, Working Effectively with Legacy Code
Thomas M. Pigoski, Practical Software Maintenance
Penny Grubb and Armstrong A. Takang, Software Maintenance: Concepts and Practice
Barry Boehm et al., Software Cost Estimation with COCOMO II (maintenance and reuse models)
Meir M. Lehman, “Laws of Software Evolution” (on why software must continually change or become less useful)
Robert C. Seacord, Daniel Plakosh, and Grace A. Lewis, Modernising Legacy Systems