ソフトウェアの進化

ソフトウェアの進化とは、最初のリリース後に、変化する利害関係者や市場の要件に対応するためにソフトウェアを継続的に開発することです。組織はソフトウェアに多額の資金を投資し、このソフトウェアに完全に依存しているため、ソフトウェアの進化は重要です。ソフトウェアの進化により、ソフトウェアは変化するビジネス要件に適応し、欠陥を修正し、ソフトウェア システム環境内の他の変化するシステムと統合できるようになります。

フレッド・ブルックスは、彼の主要著書『人月の神話』^[1]の中で、典型的なシステムのコストの90%以上が保守段階で発生し、成功したソフトウェアは必ず保守されると述べています。

実際、アジャイル手法は、Web ベースのテクノロジ内外のメンテナンスのような活動から生まれたもので、その機能の大部分はフレームワークと標準から生まれています。^[要出典]

ソフトウェアのメンテナンスではバグ修正とマイナーな機能強化に取り組みますが、ソフトウェアの進化では適応と移行に重点が置かれます。

ソフトウェア技術は今後も発展し続けるでしょう。これらの変化には、新しい法則や理論の創造と正当化が必要になります。また、将来のプログラムを開発する際には、いくつかのモデルにも追加の側面が必要になります。革新と改善により、ソフトウェア開発の予期せぬ形態が増加します。メンテナンスの問題も、将来のソフトウェアの進化に適応するために変化するでしょう。ソフトウェアプロセス自体は進化しており、学習と改良を経て、常に効率と有効性が向上しています。^[2]

ソフトウェアの進化の必要性は、ユーザーの要件がどのように進化するかを事前に予測できる人がいないという事実から生じます。^[3] 言い換えれば、既存のシステムは決して完全ではなく、進化し続けます。^[4]システムが進化するにつれて、これらの問題を解決するためのより良いソリューションがない限り、システムの複雑さは増大します。ソフトウェアの進化の主な目的は、システムの機能的関連性、信頼性、柔軟性を確保することです。ソフトウェアの進化は、完全に手動（ソフトウェアエンジニアによる変更に基づく）、部分的に自動化（リファクタリングツールの使用など）、または完全に自動化することができます。

ソフトウェアの進化はインターネットによって大きな影響を受けています。

• ワールドワイドウェブとインターネットリソースの急速な成長により、ユーザーやエンジニアが関連情報を見つけやすくなりました。

• 誰でもソースコードをダウンロードして変更できるオープンソース開発により、高速かつ並行した進化（フォーク経由）が可能になりました。

EB Swansonは当初、保守を3つのカテゴリーに分類しました。それは、修正保守、適応保守、完全保守です。その後、LientzとSwanson (1980) によってソフトウェアの4つのカテゴリーが分類されました。^[5] これらはその後更新され、ISO/IEC 14764:2006で国際的に標準化されました。^[6]

• 修正保守: 発見された問題を修正するために納品後に実行されるソフトウェア製品の事後的な修正。
• 適応型メンテナンス: 変更された環境または変化する環境でもソフトウェア製品が使用可能であり続けるように、納品後に実行されるソフトウェア製品の変更。
• 完全保守: パフォーマンスや保守性を向上させるために納品後にソフトウェア製品を変更すること。
• 予防保守: ソフトウェア製品の潜在的な欠陥が実際の欠陥になる前に検出して修正するために、納品後にソフトウェア製品を修正すること。

前述のすべては、変更が必要であることがわかっている場合に発生します。

これらのカテゴリはWarren et al. (1999) ^[7]やChapin (2001) ^[8]などの多くの著者によって補足されましたが、 ISO/IEC 14764:2006国際規格では基本的な4つのカテゴリが維持されています。

最近では、ソフトウェアの保守と進化の記述はオントロジー（Kitchenham et al.（1999）、^[9] Deridder（2002）、^[10] Vizcaíno（2003）、^[11] Dias（2003）、^[12]およびRuiz（2004）^[13]）を使用して行われており、多くの進化活動の記述が充実しています。

現在の傾向と実践は、段階的モデルと呼ばれるソフトウェア進化の新しいモデルを使用して予測されています。^[14]段階的モデルは、ソフトウェア進化に貢献するのが難しいという難しさのために急速に変化している現代のソフトウェア開発にはあまり適していない従来の分析に代わるものとして導入されました。単純な段階的モデルには、5つの異なる段階（初期開発、進化、サービス、段階的廃止、および終了）が貢献しています。

• KHBennett と VT Rajlich によると、^[14]重要な貢献は、「保守」段階を進化段階とそれに続くサービス段階および段階的廃止段階に分けることです。一部の機能が欠けているソフトウェア システムの最初のバージョンは、初期開発またはアルファ段階とも呼ばれる段階で開発されます。^[14]ただし、この段階で既にアーキテクチャが完成しているため、将来の変更や修正が必要になります。この段階でのほとんどの参照は、シナリオまたはケース スタディに基づいています。知識は、初期開発のもう 1 つの重要な成果として定義されています。このような知識には、アプリケーション ドメイン、ユーザー要件、ビジネス ルール、ポリシー、ソリューション、アルゴリズムなどの知識が含まれます。知識は、その後の進化段階にとっても重要な要素であると思われます。
• 前の段階が正常に完了したら（次の段階に入る前に正常に完了している必要があります）、次の段階は進化です。ユーザーは要件を変更する傾向があり、何らかの改善や変更を好みます。この要因により、ソフトウェア業界は急速に変化する環境の課題に直面しています。したがって、進化の目標は、常に変化するユーザー要件と動作環境にアプリケーションを適応させることです。^[14]前の段階では、作成された最初のバージョンのアプリケーションに多くの欠陥が含まれている可能性があり、それらの欠陥は、ケーススタディやシナリオによるより具体的で正確な要件に基づいて、進化段階で修正されます。
• ソフトウェアは、進化が不可能になるまで継続的に進化し、その後、サービス段階（ソフトウェア成熟とも呼ばれます）に入ります。この段階では、小さな変更のみが行われます。
• 次の段階は段階的な廃止であり、その特定のソフトウェアに対するサービスは提供されなくなります。ただし、ソフトウェアはまだ生産中です。
• 最後に、閉鎖です。ソフトウェアの使用は切断または中止され^[14]、ユーザーは代替品に誘導されます。^[14]

1972 年から 2002 年までインペリアル カレッジ ロンドンで勤務したMeir M. Lehman教授とその同僚は、プロプライエタリ ソフトウェアの進化における一連の動作を特定しました。これらの動作 (または観察) は、Lehman の法則として知られています。彼は、E 型システムを、現実世界の何らかのアクティビティを実行するために作成されたシステムと呼んでいます。このようなシステムの動作は、それが実行される環境と強く結びついており、そのようなシステムは、その環境のさまざまな要件や状況に適応する必要があります。8 つの法則は次のとおりです。

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

これらの法則があらゆる種類のソフトウェア システムに適用できるかどうかは、多くの研究者によって研究されてきたことは特筆に値します。たとえば、Nanjangud C Narendra ^[17]のプレゼンテーションでは、Lehman のソフトウェア進化の法則に照らしてエンタープライズ Agile プロジェクトのケース スタディについて説明しています。オープン ソース ソフトウェア開発の研究から得られたいくつかの経験的観察は、いくつかの法則に疑問を投げかけているようです^{[曖昧] [引用が必要]}。

この法則は、ソフトウェア システムの機能変更の必要性は避けられないものであり、要件の不完全または不正確な分析や不適切なプログラミングの結果ではないことを予測しています。変更や新機能を安全に実装するという点において、ソフトウェア開発チームが達成できる成果には限界があると述べています。

ソフトウェアの進化に特化した成熟度モデルは、プロセスを改善し、ソフトウェアが反復的に進化するにつれてソフトウェアが継続的に若返ることを保証するために開発されました^{[引用が必要]}。

多くの利害関係者 (開発者、ユーザー、その管理者など) によって作成される「グローバル プロセス」には、多くのフィードバック ループがあります。進化の速度は、フィードバック ループの構造とグローバル システムのその他の特性の関数です。システム ダイナミクスなどのプロセス シミュレーション技術は、このようなグローバル プロセスを理解し、管理するのに役立ちます。

ソフトウェアの進化は、ダーウィン的、ラマルク的、あるいはボールドウィン的ではないかもしれませんが、それ自体が重要な現象です。社会と経済のあらゆるレベルでソフトウェアへの依存が高まっていることを考えると、ソフトウェアの進化を成功させることはますます重要になっています。これは、あまり注目されていない重要な研究テーマです。

ソフトウェアの進化は、他の人工物と比較して急速に進んでいるため、レーマンは人工システムの進化の研究における「ミバエ」とみなしていました。

• ソフトウェアエントロピー
• メイア・M・レーマン
• ダーウィンの進化論
• ラマルク進化論
• ボールドウィン進化論
• ソフトウェアジャーナル：進化とプロセス

• LibVCS4j さまざまなバージョン管理システムや問題追跡ツールに共通の API を提供することで、既存のツールがソフトウェア システムの進化を分析できるようにする Java ライブラリ。

• Andrea Capiluppi、Jesus M.Gonzalez Barahona、Israel Herraiz、Gregorio Robles、「ソフトウェア進化の段階的モデル」を FLOSS に適応
• マーク・C・ポールク、能力成熟度モデルソフトウェアの歴史