Software-engineering-software-maintenance-overview
ソフトウェア保守の概要
ソフトウェアメンテナンスは、今日ではSDLCの一部として広く受け入れられています。 ソフトウェア製品の配信後に行われたすべての変更および更新を表します。 いくつかの理由、変更が必要な理由がありますが、そのいくつかを以下に簡単に説明します。
- 市場条件-課税や簿記の維持方法などの新たに導入された制約など、時間の経過とともに変化するポリシーにより、変更の必要性が生じる場合があります。
- クライアントの要件-時間の経過とともに、お客様はソフトウェアの新しい機能を要求する場合があります。
- ホストの変更-ターゲットホストのハードウェアやプラットフォーム（オペレーティングシステムなど）が変更された場合、適応性を維持するためにソフトウェアの変更が必要です。
- 組織の変更-組織の強度の低下、別の会社の買収、新しいビジネスへの進出など、クライアント側でビジネスレベルの変更がある場合、元のソフトウェアを変更する必要が生じる場合があります。
メンテナンスの種類
ソフトウェアの寿命では、メンテナンスの種類はその性質に応じて異なる場合があります。 これは、一部のユーザーがバグを発見したための単なる日常的なメンテナンス作業の場合もあれば、メンテナンスのサイズや性質に基づいたそれ自体の大きなイベントの場合もあります。 以下は、その特性に基づいたいくつかのタイプのメンテナンスです。
- 修正メンテナンス-これには、ユーザーによって発見された、またはユーザーエラーレポートによって結論付けられた問題を修正または修正するために行われた変更および更新が含まれます。
- アダプティブメンテナンス-これには、ソフトウェア製品を最新の状態に保つために適用され、技術とビジネス環境の絶えず変化する世界に合わせた修正と更新が含まれます。
- 完全なメンテナンス-これには、ソフトウェアを長期間使用できるようにするために行われた変更と更新が含まれます。 これには、ソフトウェアを改良し、信頼性とパフォーマンスを向上させるための新しい機能、新しいユーザー要件が含まれています。
- 予防保守-これには、ソフトウェアの将来の問題を防ぐための変更と更新が含まれます。 現時点では重要ではないが、将来深刻な問題を引き起こす可能性がある問題に対処することを目的としています。
メンテナンス費用
報告によると、メンテナンスのコストが高いことが示唆されています。 ソフトウェアメンテナンスの見積もりに関する調査では、メンテナンスのコストは、ソフトウェアプロセスサイクル全体のコストの67％と同じくらい高いことがわかりました。
ソフトウェアメンテナンスのコストは、平均してすべてのSDLCフェーズの50％以上です。 以下のような、メンテナンスコストが高くなるさまざまな要因があります。
メンテナンスコストに影響する実際の要因
- ソフトウェアの標準年齢は、最大10〜15年と見なされます。
- 古いソフトウェアは、メモリとストレージ容量が少ない低速のマシンで動作することを目的としており、最新のハードウェアで新しく提供される拡張ソフトウェアに対して挑戦し続けることはできません。
- 技術が進歩するにつれて、古いソフトウェアを維持するのは費用がかかります。
- ほとんどのメンテナンスエンジニアは初心者であり、試行錯誤を行って問題を修正します。
- 多くの場合、変更はソフトウェアの元の構造を簡単に傷つけ、その後の変更を困難にします。
- 多くの場合、変更は文書化されずに残り、将来さらに競合が発生する可能性があります。
メンテナンスコストに影響するソフトウェア終了要因
- ソフトウェアプログラムの構造
- プログラミング言語
- 外部環境への依存
- スタッフの信頼性と可用性
メンテナンス活動
IEEEは、順次メンテナンスプロセスアクティビティのフレームワークを提供します。 繰り返し使用することができ、拡張してカスタマイズされたアイテムとプロセスを含めることができます。
これらのアクティビティは、次の各フェーズと密接に関連しています。
- 識別とトレース-変更または保守の要件の識別に関するアクティビティが含まれます。 ユーザーによって生成されるか、システム自体がログまたはエラーメッセージを介して報告する場合があります。ここでは、メンテナンスタイプも分類されます。
- 分析-変更は、安全およびセキュリティへの影響を含むシステムへの影響について分析されます。 予想される影響が深刻な場合、代替ソリューションを探します。 必要な変更のセットは、要求仕様に具体化されます。 変更/保守のコストが分析され、推定が完了します。
- 設計-交換または変更が必要な新しいモジュールは、前の段階で設定された要件仕様に対して設計されています。 検証と検証のためにテストケースが作成されます。
- 実装-新しいモジュールは、設計ステップで作成された構造化設計の助けを借りてコーディングされます。すべてのプログラマーは、ユニットテストを並行して行うことが期待されます。
- システムテスト-新しく作成されたモジュール間で統合テストが行われます。 統合テストは、新しいモジュールとシステムの間でも実行されます。 最後に、回帰テスト手順に従って、システム全体がテストされます。
- 受け入れテスト-システムを内部でテストした後、ユーザーの助けを借りて受け入れテストを行います。 この状態で、ユーザーが次の反復で対処するために対処または指摘された問題に苦情を申し立てた場合。
- 配信-受け入れテストの後、システムは小規模な更新パッケージまたはシステムの新規インストールによって組織全体に展開されます。 最終テストは、ソフトウェアが配信された後、クライアント側で行われます。 +必要に応じて、ユーザーマニュアルのハードコピーに加えて、トレーニング施設が提供されます。
- メンテナンス管理-構成管理は、システムメンテナンスの重要な部分です。 バージョン管理ツールを使用して、バージョン、セミバージョン、またはパッチ管理を管理できます。
ソフトウェアのリエンジニアリング
機能に影響を与えることなく、現在の市場に維持するためにソフトウェアを更新する必要がある場合は、ソフトウェアのリエンジニアリングと呼ばれます。 これは、ソフトウェアの設計が変更され、プログラムが書き直される徹底的なプロセスです。
レガシーソフトウェアは、市場で入手可能な最新のテクノロジーでチューニングを続けることができません。 ハードウェアが陳腐化するにつれて、ソフトウェアの更新は頭痛の種になります。 ソフトウェアが時間とともに古くなっても、機能は変わりません。
たとえば、当初Unixはアセンブリ言語で開発されました。 言語Cが登場すると、アセンブリ言語での作業が困難だったため、UnixはCで再設計されました。
これ以外に、プログラマーは、ソフトウェアのいくつかの部分が他の部分よりも多くのメンテナンスを必要とし、リエンジニアリングも必要であることに気付くことがあります。
リエンジニアリングプロセス
- *決定*リエンジニアリングするもの。 ソフトウェア全体ですか、それとも一部ですか？
- *実行*既存のソフトウェアの仕様を取得するためのリバースエンジニアリング。
- *必要に応じて*プログラムを再構築します。 たとえば、関数指向プログラムをオブジェクト指向プログラムに変更します。
- *必要に応じて*データを再構築します。
- *リエンジニアリングされたソフトウェアを入手するために、フォワードエンジニアリングの概念を適用します。
ソフトウェアのリエンジニアリングで使用される重要な用語はほとんどありません
リバースエンジニアリング
これは、既存のシステムを徹底的に分析、理解することにより、システム仕様を達成するプロセスです。 このプロセスは、逆SDLCモデル、つまり より低い抽象化レベルを分析することにより、より高い抽象化レベルを取得しようとします。
既存のシステムは以前に実装された設計であり、それについては何も知りません。 次に、設計者はコードを見てリバースエンジニアリングを行い、設計を取得しようとします。 設計を手に入れて、彼らは仕様を結論付けようとします。 したがって、コードからシステム仕様に逆順になります。
プログラムの再編
これは、既存のソフトウェアを再構築および再構築するプロセスです。 同じプログラミング言語で、またはあるプログラミング言語から別のプログラミング言語にソースコードを再配置することがすべてです。 再構築には、ソースコードの再構築とデータの再構築のいずれか、または両方が含まれます。
再構築はソフトウェアの機能には影響しませんが、信頼性と保守性を向上させます。 非常に頻繁にエラーを引き起こすプログラムコンポーネントは、変更したり、再構築で更新したりできます。
廃止されたハードウェアプラットフォームでのソフトウェアの信頼性は、再構築によって削除できます。
フォワードエンジニアリング
フォワードエンジニアリングは、リバースエンジニアリングによってダウンした手元の仕様から目的のソフトウェアを取得するプロセスです。 過去に既にソフトウェアエンジニアリングが行われていることを前提としています。
フォワードエンジニアリングは、ソフトウェアエンジニアリングプロセスと同じですが、唯一の違いがあります。リバースエンジニアリングの後に常に実行されます。
コンポーネントの再利用性
コンポーネントは、システム内の独立したタスクを実行するソフトウェアプログラムコードの一部です。 それは小さなモジュールまたはサブシステム自体である場合があります。
例
Webで使用されるログイン手順はコンポーネントと見なすことができ、ソフトウェアの印刷システムはソフトウェアのコンポーネントと見なすことができます。
コンポーネントは、機能の凝集度が高く、結合率が低い、つまり それらは独立して動作し、他のモジュールに依存せずにタスクを実行できます。
OOPでは、設計されたオブジェクトは懸念事項に非常に固有であり、他のソフトウェアで使用される可能性が少なくなります。
モジュール式プログラミングでは、モジュールは他の多くのソフトウェアプログラムで使用できる特定のタスクを実行するようにコーディングされています。
ソフトウェアコンポーネントの再利用に基づいたまったく新しい分野があり、コンポーネントベースソフトウェアエンジニアリング（CBSE）として知られています。
さまざまなレベルで再利用できます
- アプリケーションレベル-アプリケーション全体が新しいソフトウェアのサブシステムとして使用される場合。
- コンポーネントレベル-アプリケーションのサブシステムが使用される場所。
- モジュールレベル-機能モジュールが再利用される場所。 +ソフトウェアコンポーネントは、さまざまなコンポーネント間の通信を確立するために使用できるインターフェイスを提供します。
再利用プロセス
要件を同じにしてコンポーネントを調整する方法と、コンポーネントを同じにして要件を変更する方法の2種類の方法を採用できます。
- 要件仕様-機能要件と非機能要件が指定されており、既存のシステム、ユーザー入力、またはその両方の助けを借りて、ソフトウェア製品が準拠する必要があります。
- 設計-これは標準のSDLCプロセスステップでもあり、ソフトウェア用語の観点から要件が定義されます。 システム全体の基本アーキテクチャとそのサブシステムが作成されます。
- コンポーネントの指定-ソフトウェア設計を検討することにより、設計者はシステム全体をより小さなコンポーネントまたはサブシステムに分離します。 1つの完全なソフトウェア設計は、連携して動作する膨大なコンポーネントの集合に変わります。
- 適切なコンポーネントの検索-ソフトウェアコンポーネントリポジトリは、機能性と目的のソフトウェア要件に基づいて、設計者が一致するコンポーネントを検索するために参照します。
- コンポーネントを組み込む-一致したすべてのコンポーネントは、完全なソフトウェアとしてそれらを形作るために一緒に梱包されます。
