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