ソフトウェアメンテナンス

良い記事ですね。詳しくはこちらをクリックしてください。

ソフトウェアメンテナンスとは、納品後のソフトウェアの修正のことです。

ソフトウェアのメンテナンスは、新規開発に比べてスキルが低く、報酬も低いとよく考えられています。そのため、アウトソーシングやオフショアリングの対象となることがよくあります。通常、ソフトウェアを開発するチームと保守するチームは異なります。開発者には、保守しやすいコードを書くインセンティブがありません。ソフトウェアは不完全な状態で納品されることが多く、ほとんどの場合、保守チームが修正しなければならないバグが含まれています。ソフトウェアのメンテナンスには、当初は新機能の開発が含まれることがよくありますが、製品の寿命が近づくにつれて、メンテナンスは必要最低限​​にまで削減され、製品が廃止される前に完全に中止されます。

各メンテナンスサイクルは、通常エンドユーザーからの変更要求から始まります。その要求は評価され、実装が決定された場合、プログラマーは変更を実装する前に既存のコードの動作を調査・理解します。既存の機能が維持され、必要な新機能が追加されていることを確認するためのテストが、メンテナンスコストの大部分を占めることがよくあります。

ソフトウェア保守は、コストの大部分を占めるにもかかわらず、ソフトウェアライフサイクルの他のフェーズほど十分に研究されていません。1980年代以降、ソフトウェア保守に関する理解は大きく変わっていません。ソフトウェア保守は、予防的なものか事後的なものか、また機能の追加を目的とするか既存機能の維持を目的とするかによって、いくつかの種類に分類できます。後者は、一般的に環境の変化に直面した際に行われます。

歴史

1970年代初頭、企業はソフトウェア開発チームをサポート業務から解放するため、ソフトウェアメンテナンスを自社のエンジニアチームに分離し始めました。[ 1 ] 1972年、RG・キャニングは「メンテナンスの氷山」を出版し、ソフトウェアメンテナンスは既存のシステムという新たな入力要素を加えたソフトウェア開発の延長線上にあると主張しました。[ 1 ]ソフトウェアメンテナンスの分野はそれ以来ほとんど変わっていません。[ 2 ] 21世紀のイノベーションの一つは、企業が意図的に不完全なソフトウェアをリリースし、リリース後に完成させる計画を立てることです。この種の変更や機能を拡張する変更は、メンテナンスではなくソフトウェアの進化と呼ばれることがよくあります。[ 2 ]

ソフトウェアライフサイクル

1988 年の従来のソフトウェア開発ライフサイクルの図

テストと品質保証にもかかわらず、事実上すべてのソフトウェアには、システムが意図したとおりに動作しないバグが含まれています。これらのバグが見つかった場合、リリース後のメンテナンスで修正する必要があります。 [ 3 ]ほとんどのソフトウェアは、既存の商用オフザシェルフ(COTS) およびオープンソースソフトウェアコンポーネントとカスタム記述コードを組み合わせたものです。 COTS およびオープンソースソフトウェアは通常、時間の経過とともに更新されるため、メンテナンスの負担は軽減されますが、これらのソフトウェアコンポーネントへの変更は最終製品で調整する必要があります。[ 4 ]特定の要件を満たすことに重点が置かれたソフトウェア開発とは異なり、ソフトウェアメンテナンスは、ユーザーリクエストやバグの検出などのイベントによって推進されます。[ 5 ]その主な目的は、通常、要件の変化に直面してもソフトウェアの有用性を維持することです。[ 6 ]

ソフトウェア開発ライフサイクルの一部として考えると、保守はサイクルの最後であり、通常は最も長いフェーズであり、[ 7 ] [ 8 ]ライフサイクルコストの80～90%を占めます。[ 9 ]他のモデルでは、保守をソフトウェア開発とは別のものとして考え、ソフトウェア保守ライフサイクル（SMLC）の一部として扱います。[ 8 ] SMLCモデルには通常、コードの理解、変更、再検証が含まれます。[ 8 ]

リリースからメンテナンス、そして寿命の終わりへの移行

ソフトウェア廃止の手順を示す図

ソフトウェアは不完全な状態で納品されることが多い。開発者は、時間や予算を超過するよりも、不完全な製品で生じる影響の方が少ないため、時間や資金が尽きるまで製品をテストする。[ 10 ]開発チームから保守チームへの移行は、既知の問題や検証テストのリストがなければ非効率的になることが多く、保守チームはそれらを再作成する可能性が高い。[ 11 ]リリース後、開発チームのメンバーは異動になるか、何らかの理由で利用できなくなる可能性が高い。保守チームは、リリース後1年間は、技術サポートと開発中に残った欠陥の修正のために、追加のリソースを必要とする。[ 10 ]

ソフトウェアは、リリース後、当初は機能強化の期間を経る場合があります。ユーザーからのフィードバックに基づいて新機能が追加されます。ある時点で、企業は機能改善を行うのはもはや利益にならないと判断し、サポートをバグ修正と緊急アップデートに限定する場合があります。専門知識の不足やソフトウェアの老朽化によるアーキテクチャの劣化により、変更はますます困難で費用もかかります。製品がメンテナンスされなくなり、この限られたレベルのアップデートさえ受けられなくなると、一部のベンダーは、製品がますます敬遠される可能性が高くなるにもかかわらず、できるだけ長くソフトウェアから収益を上げようとします。最終的には、ソフトウェアは市場から撤退しますが、引き続き使用される可能性があります。このプロセスの間に、ソフトウェアはレガシーシステムになります。[ 12 ]

変化のサイクル

変更サイクルの最初のステップは、顧客から変更要求を受け取り、それを分析して問題を確認し、変更を実施するかどうかを決定することです。[ 13 ]これには複数の部門からの意見が必要になる場合があります。たとえば、マーケティングチームは、変更によってより多くのビジネスがもたらされると予想されるかどうかを評価するのに役立ちます。[ 14 ]ソフトウェア開発の労力見積もりは、保守変更要求を含めて難しい問題です。[ 15 ]しかし、要求が高すぎるか実行不可能な場合は拒否される可能性があります。[ 16 ] 要求を実施することが決定された場合、スケジュールされたリリースに割り当てて実装することができます。[ 16 ]アジャイル方法論には保守フェーズはありませんが、[ 17 ] 変更サイクルはスクラムスプリントとして制定できます。[ 18 ]

既存のコードを理解することは、コードを変更する前に不可欠なステップです。[ 2 ]理解の速さは、コードベースとプログラマーのスキルの両方に依存します。[ 19 ]目的に合った明確な関数名や変数名を使用するなどのコーディング規約に従うと、理解が容易になります。[ 20 ]コードが複数回実行される場合にのみ条件付きループ文を使用し、実行されないコードを削除することでも、理解しやすさが向上します。 [ 21 ]経験豊富なプログラマーは、コードが高レベルで何をするかを理解するのが容易です。[ 22 ]ソフトウェアの視覚化は、このプロセスを高速化するために使用されることがあります。[ 23 ]

コードの変更は、あらゆる方法で行われる可能性があります。一方では、コードド​​キュメントを更新する十分な時間を与えられずに、場当たり的に応急処置を施すことが一般的です。[ 24 ]一方では、最上位レベルの要件ドキュメントを変更し、その変更をシステムの下位レベルに伝播させることで、しっかりと構造化された反復的な機能強化を開始できます。[ 25 ]変更には、多くの場合、コードのリファクタリング（機能を変えずに構造を改善する）と再構築（構造と機能を同時に改善する）が含まれます。 [ 26 ]商用ソフトウェアとは異なり、フリーソフトウェアやオープンソースソフトウェアの変更サイクルは、主にコーディングとテストに限定されており、ドキュメントは最小限です。オープンソースソフトウェアプロジェクトでは、代わりにメーリングリストや多数の貢献者に頼ってコードベースを理解し、効率的にバグを修正しています。[ 27 ]

保守に関するさらなる問題は、コードを変更するたびにほぼ必ず新しいバグや予期しない波及効果が発生し、再度の修正が必要になることです。[ 2 ]変更があった場合はソフトウェア全体を再検証する必要があるため、安全性が重要なコードの保守リソースの大部分はテストに費やされる可能性があります。[ 28 ]再検証には、コードレビュー、ユニットテストのサブセットを含む回帰テスト、統合テスト、システムテストが 含まれる場合があります。[ 26 ]テストの目的は、以前の機能が保持され、新しい機能が追加されたことを確認することです。[ 29 ]

ソフトウェアメンテナンスのカテゴリ

ソフトウェアメンテナンスの主な目的は、製品がユーザビリティ要件を継続的に満たし続けることを保証することです。場合によっては、当初想定されていた範囲を超えて製品の機能を拡張することを意味することもあります。[ 30 ]

ISO / IEC 14764仕様によれば、ソフトウェア保守は4つのタイプに分類できる。[ 31 ]

ある推計によると、機能強化（後者の2つのカテゴリ）はソフトウェアメンテナンスの約80％を占めています。[ 35 ]

保守性

保守性とは、既存の機能を壊すことなくソフトウェアを簡単に変更できる品質です。[ 31 ] ISO / IEC 14764仕様によると、リリース前にソフトウェアの保守性を保証する活動は、ソフトウェア保守の一部です。[ 5 ]多くのソフトウェア開発組織は、長期的なコストが増加するにもかかわらず、保守性を無視しています。[ 36 ]技術的負債は、プログラマが、多くの場合、期限に間に合わせるための怠惰または緊急性から、コードに保守性を組み込むのではなく、急ごしらえの解決策を選択した場合に発生します。[ 37 ]一般的な原因は、ソフトウェア開発の労力見積もりを過小評価し、開発に割り当てられるリソースが不十分になることです。[ 38 ]重要な側面の1つは、既存の機能が変更によって損なわれたかどうかを検出できる大量の自動化されたソフトウェアテストを持つことです。[ 31 ]

保守性指標は、コード行数の尺度、McCabe の尺度、およびHalstead の複雑性の尺度から特定の式を使用して計算できます。

保守性の測定と追跡は、システムの「コード エントロピー」または整合性の低下の傾向を軽減または逆転させ、コードを変更するよりもコードを書き直す方が安価でリスクが低くなる時期を示すことを目的としています。

保守性に関する課題は、多くのソフトウェアエンジニアリングのコースが保守性を重視しておらず、明確で変更不可能な仕様を持つ1回限りの課題を与えていることである。[ 39 ]ソフトウェアエンジニアリングのコースでは、現実世界で発生するような複雑なシステムは扱われない。[ 40 ]ソフトウェアの保守を担当しないことを知っている開発エンジニアには、保守性を組み込むインセンティブがない。[ 2 ]

労働力

メンテナンスはソフトウェアエンジニアにとってやりがいのない仕事だと考えられていることが多く、メンテナンスに配属されたら辞めてしまう可能性が高い。[ 41 ] [ 42 ]メンテナンスの賃金は、ソフトウェア開発における同等の仕事よりも低い場合が多い。[ 42 ]この仕事は臨時労働者やスキルの低いスタッフに割り当てられることが多いが、[ 2 ] [ 43 ]メンテナンスエンジニアは、時代遅れの技術に精通している必要があることもあり、開発者よりも年齢が高いのが一般的である。[ 43 ] 2008年には、米国で働く130万人のソフトウェアエンジニアとプログラマーのうち約90万人がメンテナンスを行っていた。[ 44 ]

企業はメンテナンスのために別のチームを立ち上げ、その結果、この作業を別の会社にアウトソーシングするようになり、21 世紀に入ると、元の会社の一部または別の事業体として、作業を他の国にオフショア化することもありました。 [ 45 ] [ 9 ]アウトソーシングの一般的なソースは、米国、英国、日本、オーストラリアなどの先進国ですが、目的地は通常、中国、インド、ロシア、アイルランドなどの低コストの国です。[ 46 ]オフショアリングの理由には、人件費の低さを利用すること、24 時間サポートを可能にすること、開発者にかかる時間的プレッシャーを軽減すること、サポートを製品の市場に近づけることなどがあります。[ 47 ]オフショアリングの欠点には、タイムゾーンや組織の分離、文化の違いなどの要因の形でのコミュニケーション障壁があります。 [ 9 ] 多くの雇用主がメンテナンスは低技能の仕事であり、ソフトウェア開発の段階はオフショアリングに最も適していると考えているにもかかわらず、[ 9 ] [ 48 ]顧客との緊密なコミュニケーションと迅速な対応が必要であり、どちらもコミュニケーションの難しさによって妨げられています。[ 9 ]

メンテナンスの代替手段

ソフトウェア工学において、 「レガシーシステム」という用語は固定された意味を持ちませんが、多くの場合、大規模で変更が困難でありながら、現在のビジネスニーズにも不可欠な古いシステムを指します。レガシーシステムは、時代遅れのプログラミング言語で記述され、ドキュメントが不足し、長年の変更によって構造が劣化しており、運用を維持するために専門家に依存していることがよくあります。[ 49 ]このようなシステムを扱う場合、ある時点で技術的負債が蓄積されすぎて、メンテナンスが現実的または経済的ではなくなります。[ 12 ]その他の選択肢としては、以下が挙げられます。

  • 凍結 - レガシーシステムでの作業は行わない。[ 50 ]ベンダーがメンテナンスコストを避けながら、できるだけ長く収益を上げ続けたい場合にこのオプションが選択される可能性がある。[ 12 ]
  • レガシーシステムの機能を別の会社にアウトソーシングすること。特にそれがコアビジネス機能ではない場合。 [ 50 ]
  • 既存のレガシーシステムを廃棄し、レガシーシステムと同じ目的を果たす新しいアプリケーションをゼロから再開発する。[ 50 ]しかし、このアプローチは稼働中のシステムを廃棄するため非効率的であり、新しいシステムが変化するビジネス要件を満たさなくなる危険性がある。[ 50 ]
  • レガシーアプリケーションを抽象化レイヤーでラップすることで、時代遅れのインターフェースを簡素化します。[ 50 ]ソースコードは変更されませんが、新しいインターフェースにより、実績のあるコンポーネントを新しいアプリケーションからアクセスできるようになります。このアプローチでは、レガシーシステムの保守に関する問題は解決されません。[ 51 ]データベース、関数、そしてアプリケーション全体をこの方法でラップすることができます。[ 52 ]
  • レガシーシステムを新しいプラットフォームに移行すると、レガシーシステムの実装、設計、仕様、要件を再利用することで、新しいソフトウェア開発の費用を削減できます。[ 53 ]移行には5年から10年かかる場合がありますが、柔軟性が向上し、ソフトウェアメンテナンスの長期的な節約につながります。[ 54 ]費用の80%はテスト、つまり新しいシステムが古いシステムと同じ出力を持つことを確認することに費やされます。[ 55 ]新しいシステムが完成したら、ビジネス機能への影響を最小限に抑えながら、古いシステムから新しいシステムに移行する必要があります。[ 55 ]

研究

ソフトウェア開発リソースの大部分を占めているにもかかわらず、保守はソフトウェア開発の中で最も研究されていないフェーズです。[ 56 ] [ 57 ]多くの文献は、最初から保守可能なコードを開発する方法に焦点を当てており、エンジニアが保守性を優先するように動機付けることについてはあまり焦点が当てられていません。[ 58 ] 2020年現在、保守の労力を削減するためのコードリファクタリングの自動化ソリューションは、研究が活発に行われている分野であり、[ 59 ]機械学習を強化した保守性評価も同様です。[ 60 ]

参照

参考文献

  1. ^ a bトリパシーとナイク 2014、p. 25.
  2. ^ a b c d e f Offutt, Jeff (2018年1月). 「ソフトウェアの保守と進化の概要」 .ジョージ・メイソン大学コンピュータサイエンス学部. 2024年5月5日閲覧。
  3. ^トリパシーとナイク 2014、p. 4.
  4. ^ Tripathy & Naik 2014、5–6 ページ。
  5. ^ a bトリパシーとナイク 2014、p. 26.
  6. ^マドゥスダンら。 2017、p. 761.
  7. ^ Varga 2018、3ページ。
  8. ^ a b cトリパシーとナイク 2014、p. 7.
  9. ^ a b c d eウルジットら。 2015、p. 764。
  10. ^ a bライファー 2012、22ページ。
  11. ^ライファー 2012、21ページ。
  12. ^ a b cトリパシーとナイク 2014、p. 89.
  13. ^マドゥスダンら。 2017、p. 763.
  14. ^トリパシーとナイク 2014、p. 120.
  15. ^マドゥスダンら。 2017、p. 762.
  16. ^ a bトリパシーとナイク 2014、p. 123.
  17. ^ Ali et al. 2024、126頁。
  18. ^ Ali et al. 2024、p.130。
  19. ^トリパシーとナイク 2014、p. 296.
  20. ^ Tripathy & Naik 2014、296–297 ページ。
  21. ^トリパシーとナイク 2014、p. 309.
  22. ^トリパシーとナイク 2014、p. 297.
  23. ^ Tripathy & Naik 2014、pp. 318–319。
  24. ^ Tripathy & Naik 2014、85–86 ページ。
  25. ^トリパシーとナイク 2014、p. 86.
  26. ^ a bトリパシーとナイク 2014、p. 94.
  27. ^トリパシーとナイク 2014、p. 59.
  28. ^ライファー 2012、5ページ。
  29. ^トリパシーとナイク 2014、p. 98.
  30. ^ Varga 2018、4ページ。
  31. ^ a b c d e fヴァルガ 2018、p. 5.
  32. ^ Tripathy & Naik 2014、26–27 ページ。
  33. ^ a b c d e fトリパシーとナイク 2014、p. 27.
  34. ^ a b Varga 2018、5～6頁。
  35. ^ Varga 2018、p.5 fn 4。
  36. ^ Varga 2018、12ページ。
  37. ^ヴァルガ 2018、6～7頁。
  38. ^ Varga 2018、7ページ。
  39. ^ヴァルガ 2018、7～8頁。
  40. ^ Varga 2018、9ページ。
  41. ^マドゥスダンら。 2017、p. 764。
  42. ^ a bライファー 2012、7ページ。
  43. ^ a bライファー 2012、p.8。
  44. ^ライファー 2012、1ページ。
  45. ^ラーマン他2024、p.1。
  46. ^ Rahman et al. 2021、研究の背景。
  47. ^ウルジットら。 2015、p. 763.
  48. ^ライファー 2012、2ページ。
  49. ^ Tripathy & Naik 2014、187–188 ページ。
  50. ^ a b c d e Tripathy & Naik 2014、p. 188.
  51. ^トリパシーとナイク 2014、p. 189.
  52. ^トリパシーとナイク 2014、p. 191.
  53. ^ Tripathy & Naik 2014、188–189 ページ。
  54. ^トリパシーとナイク 2014、p. 195.
  55. ^ a bトリパシーとナイク 2014、p. 196.
  56. ^マドゥスダンら。 2017、p. 759。
  57. ^ウルジットら。 2015、p. 766。
  58. ^ライファー 2012、4～5頁。
  59. ^ Baqais & Alshayeb 2020、459ページ。
  60. ^ Alsolai & Roper 2020、p.106214。

出典

  • Ali, Muhammad; Cheema, Sehrish Munawar; Naz, Ammerha; Pires, Ivan Miguel (2024). 「SAMSEF：スクラムフレームワークを活用したアジャイルソフトウェア保守による効率性と効果性の向上」.情報システムと技術における優れた実践と新たな展望. ネットワークとシステムに関する講義ノート. 第989巻. Springer Nature Switzerland. pp.  126– 136. doi : 10.1007/978-3-031-60227-6_11 . ISBN 978-3-031-60226-9。
  • Alsolai, Hadeel; Roper, Marc (2020). 「ソフトウェア保守性予測のための機械学習技術に関する体系的な文献レビュー」(PDF) .情報・ソフトウェア技術. 119 106214. doi : 10.1016/j.infsof.2019.106214 .
  • Baqais, Abdulrahman Ahmed Bobakr; Alshayeb, Mohammad (2020). 「自動ソフトウェアリファクタリング：体系的な文献レビュー」. Software Quality Journal . 28 (2): 459– 502. doi : 10.1007/s11219-019-09477-y .
  • Madhusudhan, V.; Suma, V.; Rao, Jawahar J. (2017).ソフトウェア保守：労力とコスト要件の観点から. 国際データ工学・通信技術会議議事録. Springer. pp.  759– 768. ISBN 978-981-10-1678-3。
  • Rahman, Hanif Ur; da Silva, Alberto Rodrigues; Alzayed, Asaad; Raza, Mushtaq (2024). 「ソフトウェア保守のオフショアリングに関する意思決定に関する体系的な文献レビュー」『情報とソフトウェア技術』172 107475. doi : 10.1016/j.infsof.2024.107475 .
  • Rahman, Hanif Ur; Raza, Mushtaq; Afsar, Palwasha; Khan, Habib Ullah (2021). 「アプリケーション保守のオフショアアウトソーシング決定に影響を与える要因の実証的調査」. IEEE Access . 9 : 58589–58608 . Bibcode : 2021IEEEA...958589R . doi : 10.1109/ACCESS.2021.3073315 . hdl : 10576/37687 . ISSN  2169-3536 .
  • ライファー、ドナルド・J.（2012年）『ソフトウェアメンテナンス成功の秘訣』CRC Press. ISBN 978-1-4398-5167-8。
  • トリパシー、プリヤダルシ。ナイク、クシラサーガル (2014)。ソフトウェアの進化とメンテナンス: 実践者のアプローチ。ジョン・ワイリー＆サンズ。ISBN 978-0-470-60341-3。
  • Ulziit, Bayarbuyan; Warraich, Zeeshan Akhtar; Gencel, Cigdem; Petersen, Kai (2015). 「グローバルソフトウェアメンテナンス管理における課題と解決策の概念的枠組み」. Journal of Software: Evolution and Process . 27 (10): 763– 792. doi : 10.1002/smr.1720 .
  • Varga, Ervin (2018). 『ソフトウェア保守と進化を解き明かす：既成概念にとらわれない思考』 Springer. ISBN 978-3-319-71303-8。

「 https://en.wikipedia.org/w/index.php?title=ソフトウェアメンテナンス&oldid=1330618677# Categories_of_software_maintenance」より取得