リーマンのソフトウェア進化の法則

ソフトウェア工学において、ソフトウェア進化の法則とは、1974年にレーマンとベラディがソフトウェアの進化に関して策定した一連の法則を指します。^{[1] [2]} これらの法則は、一方では新しい開発を推進する力と、他方では進歩を遅らせる力との間のバランスを説明しています。過去数十年にわたって、これらの法則は何度も改訂され、拡張されてきました。^[3]

ほとんどのソフトウェアは存在する過程で変更される傾向があることを観察し、著者らは、これらの変更が通常従う法則、またはソフトウェアが存続するために従わなければならない法則を決定しようと試みました。^[1]

1980年の論文^[1]で、レーマンはソフトウェアを3つのカテゴリーに区別して、このような法則の適用範囲を限定しました。

• Sプログラムは、そのプログラムが実行できることの正確な仕様に従って記述されます。たとえば、8 つのクイーン パズルの解答を見つけるプログラムはSプログラムです。これらのプログラムはほとんど静的であり、あまり進化しません。
• Pプログラムは、プログラムが実行できることを完全に決定する特定の手順を実装するために作成されます (前述の例はチェスをプレイするプログラムです)
• Eプログラムは、現実世界の活動を実行するために作成されます。その動作は、実行される環境に強く関連しており、そのようなプログラムは、その環境のさまざまな要件や状況に適応する必要があります。

これらの法則は最後のカテゴリーのシステムにのみ適用されると言われています。

全部で 8 つの法律が制定されました。

1. （1974）「継続的な変化」—E型システムは継続的に適応されなければならず、そうでなければ次第に満足度が低下します。^[4]
2. （1974）「複雑さの増大」—E型システムが進化するにつれて、複雑さを維持または軽減するための作業が行われない限り、複雑さは増大します。^[4]
3. （1974）「自己規制」—E型システム進化プロセスは、製品とプロセスの測定値の分布が正規分布に近い自己規制型です。^[4]
4. （1978）「組織安定性の保存（不変の作業率）」—進化するE型システムにおける平均有効グローバル活動率は、製品の寿命を通じて不変です。^[4]
5. (1978) 「習熟度の維持」 — E 型システムが進化するにつれ、開発者、営業担当者、ユーザーなど、システムに関わるすべての人が、満足のいく進化を達成するために、そのコンテンツと動作の習熟を維持する必要があります。過度の成長は習熟度を低下させます。したがって、システムが進化しても、平均増分成長は不変のままです。^[4]
6. (1991)「継続的な成長」 - E タイプ システムの機能内容は、その寿命を通じてユーザー満足度を維持するために継続的に増加する必要があります。
7. (1996)「品質の低下」—E型システムは、厳密に維持管理され、運用環境の変化に適応しない限り、品質が低下しているように見えます。^[5]
8. (1996)「フィードバック システム」(1974 年に初めて発表され、1996 年に法律として正式化) — E 型進化プロセスは、マルチレベル、マルチループ、マルチエージェントのフィードバック システムを構成しており、あらゆる合理的な基準を大幅に上回る改善を達成するには、そのように扱う必要があります。

^{[独自の研究？ ]}

現代のソフトウェア エンジニアリングのダイナミックな世界において、ソフトウェア進化の法則は依然として深い関連性を持っています。1970 年代に Lehman と Belady によって最初に定式化されたこれらの法則は、ソフトウェア システムの性質とその進化に関する永続的な洞察を提供します。俊敏性と適応性が何よりも重要である今日のソフトウェア開発環境では、これらの法則は指針として機能します。

「継続的な変化」は基本的な概念であり、ソフトウェアは満足のいく状態を維持するために継続的に進化する必要があることを強調しています。^[4]これは、反復的な更新と機能強化が標準であるアジャイル開発方法論と完全に一致しています。

「複雑性の増大」は、特に大規模で長期にわたるソフトウェアプロジェクトにおいて、複雑性の積極的な管理の必要性を強調するもう1つの重要な法則です。^{[4]ソフトウェアシステムが成長するにつれて、}モジュール設計、マイクロサービス、DevOpsなどの最新のエンジニアリング手法が複雑性の制御と削減に役立ち、ソフトウェアの保守性と拡張性を維持します。

ソフトウェア進化の法則は、DevOpsや継続的インテグレーション/継続的デプロイメント(CI/CD) の文脈でも関連性があります。DevOps 主導の環境では、「継続的な成長」の法則^[4]が例示され、進化するユーザーの要求を満たし、ユーザー満足度を維持するためにソフトウェア機能を継続的に拡張する必要があります。

「品質低下」の法則は、厳格なメンテナンスを行わないとソフトウェアの品質が時間とともに低下する可能性があることをはっきりと思い出させてくれるものであり、^[4]現代のソフトウェア開発における自動テストと品質保証の重要性を強調しています。さらに、「フィードバック システム」の法則^[4]は、ソフトウェアの進化は複数のループとエージェントが関与するフィードバック主導のプロセスであるという考えを強化しています。

これは、 DevOpsプラクティスにおけるコラボレーションとフィードバックの重視と一致しており、継続的な改善に重点を置いてソフトウェアが開発、テスト、展開されることを保証します。要約すると、ソフトウェア進化の法則は、アジャイル手法からDevOpsまで、現代の開発の複雑さを乗り越えるソフトウェア エンジニアのガイドとして引き続き機能し、堅牢で進化するソフトウェア システムの提供に役立ちます。