保守・改訂、よいシステムとは、保守の頻出、保守の困難性
情報システムは、稼働後にいろいろな理由により保守改訂が必要になります。
・欠陥対処
テスト段階で発見できなかった欠陥が、稼働後に発見される
利用度の増加、データ量の増加による処理時間の増大
・改善要求
使いやすさなど非機能要件の向上の要請
利用レベルの向上による、新機能追加の要請
・ＩＴ環境の変化
レガシー環境→オープン環境→Ｗｅｂ環境などの変化
旧版ＯＳやＥＲＰパッケージなどのベンダサポートの打切り
・経営環境の変化
法律・基準の改正
新規事業や業務改革など経営戦略への対応
仕事の仕方は経営環境に大きく影響を受けます。日常的な仕事は情報システムを利用して行われています。そのため、情報システムは経営環境に合致したものでなければなりません。経営環境が変化すれば、情報システムを改訂する必要が生じます。しかも、企業競争が厳しいので、短期間で対応することが求められます。
ところが、情報システムの改訂はますます頻繁に発生し、しかも対応を困難にしています（例示）。
本来、情報システムは経営戦略実現を容易にすることが目的なはずなのに、情報システムの遅れが経営戦略の実現を遅らせていることが多いのです。
１９９０年代末には「西暦２０００年問題」が深刻な社会問題にまでなりました。たとえば１９９８年を９８のように下２桁で表現する慣習がありますが、２０００年では００になりますので、コンピュータはそれを２０００年ではなく１９００年と解釈してしまう危険があります。それを未然に防止するには、プログラムを調べて年を示す項目を２桁から４桁に変更すればよいのですが、それだけのために、平均的な大企業では、数年の年月と数億円の費用を必要としたのです。そのように、システムは巨大化・複雑化しているのです。
一般的に、情報システムの開発と運用は異なるグループが担当しています。システムの運用段階では、システムが安定して稼働することが求められますので、運用グループは、せっかく安定稼働している現行システムに手を加えることを嫌います。面倒なだけでなく、思わぬトラブルが発生するのを恐れるからです。
それで、両グループが互いに他のグループの立場を理解して協力することが必要になります。これをDevOps＝Development (開発) ＋ Operations (運用) といいます。
単に精神的な協力ではなく、安心して容易に手を加えることができるシステムにすることが重要になります。
Google社が提唱したシステム管理とサービス運用の方法論。>DevOpsでは、開発グループと運用グループの協力の重要性を示したのに対して、ＳＲＥはその具体的な行動を示したものだといえます。
信頼性を高める技術というより、信頼性を制御する技術です。
ユーザーが利用しながらも変更を続けていくような情報システムが対象になります。
多様な理由により、システムは改訂は必然的ですが、改訂作業により予期せぬエラーが発生が発生します。それを極度に抑えるには大きな時間や費用がかかります。そのバランスをとるためには、適切な
・ＳＬＩ（Service Level Indicator）サービスの信頼性レベルの指標
・ＳＬＯ（Service Level Objective）指標に対する目標値
を明確に設定し、目標を下回らなければリスクが生じるのは仕方ばない、過剰な対応を防ごうという考え方になります。
ＳＲＥは、適切なＳＬＩ／ＳＬＯを設定し管理する方法論です。ＳＬＩとＳＬＯにより、信頼性の予算（バジェット）を期間内にどれだけ消費したかを計測しておき、予算の残量に応じて、どれだけリスクを取って変更してよいかを定量的に判断できます。このような仕組みを、エラーバジェットといいます。
トイル（toil）とは、サービスを稼働させることに直結している作業で、繰り返されたり、手作業だったりするものです。ＳＲＥでは、ソフトウェアエンジニアリングやシステムエンジニアリングを活用して、トイル作業を５０％以下にするのだとしています。
保守改訂作業が増大しており、しかもその作業はベテランでないとできません。そのため、ＩＴ部門は、新規開発のための作業が十分に行えない状況になっています。情報システム部門はシステム開発だけでなく、経営戦略と情報技術の統合などの付加価値の高い任務が期待されていますが、保守改訂にベテランが張り付いている状態ではそれも困難です。
保守改訂によりＩＴ部門が硬直化して本来の業務ができなくなる状況を回避することが重要な課題ですが、既存のシステムを容易に保守改訂する効果的な方法はないので、システム設計の段階から、将来の改訂が容易に行えるように設計することが大切です。システムを開発するのは１回だけですが、保守改訂は何度も行なわれます。すなわち、「よいシステム」とは「保守・改訂を容易にできること」であるといっても過言ではありません。
ソフトウェアの生産性が低いことが、ＩＴの効果的な活用を妨げていることは、１９６０年代末頃でも指摘されておりソフトウェア・クライシスといわれました。それを解決するために、ソフトウェア工学が進みました。部品化・再利用や、各種のシステム開発の方法論は、ソフトウェア工学の主要な分野です（それらの説明）。
「ソフトウェア・クライシス」（Software Crisis）が初めて使われたのは、１９６８年のＮＡＴＯによる「ソフトウェアエンジニアリング・コンファレンス」だそうだ。予算超過、納期遅れ、品質低下などが頻繁に発生していることの危機感から生まれた言葉である。
この認識からソフトウェア工学が進んだ。１９７２年にはダイクストラがプログラミングをわかりやすく品質をよくすることの重要性を指摘した。そのなかでの「ＧＯＴＯ命令をなくせ」が注目された。
プログラマが不足していることが問題になり、日本では１９８７年には通商産業省（現経済産業省）が「２０００年にはプログラマが９７万人不足する」と予測した。しかしその後は、プログラマの不足ではなく、上流工程やプロジェクトマネジメントでの人材不足がいわれるようになってきた。
参照：
玉置 彰宏「ソフトウェア工学の勧め」２００４年