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

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

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

ソフトウェア保守は、コストの大部分を占めるにもかかわらず、ソフトウェアライフサイクルの他のフェーズほど十分に研究されていません。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]

  • 是正保守：エンドユーザーから報告されたバグや要件を満たさないその他の不具合を修正するためのソフトウェアの修正。 [31] [32]
  • 予防保守：ソフトウェアの納品後に将来を見据えた修正を行うことで、ソフトウェアが引き続き要件を満たしているかを確認したり、まだ顕在化していない問題を修正したりすること。[33] [31]このタイプの保守は、特に高い安全性や可用性が求められるシステムで実施される。 [ 33] ソフトウェアの若返りは、状態をクリーンアップして将来の問題を防ぐための予防保守の一種である。[33]
  • 適応型保守：ソフトウェアの納品後に行われるソフトウェアの修正であり、変更された環境や変化する環境でもソフトウェアが継続的に使用できることを保証する。[31] [33]
  • 完了保守：納品後のソフトウェアの機能強化により、ユーザーエクスペリエンス、処理効率、保守性などの品質を向上させること。[33] [34]完了保守は、他の種類の保守を実行する場合に必要です。既存のコードベースを変更すると、複雑さが増し、既存の構造が劣化する可能性があるためです。[34]完了保守には、ドキュメントの書き換え、コードのリファクタリング、パフォーマンスチューニングなどが含まれます。 [33]

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

保守性

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

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

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

保守性に関する課題は、多くのソフトウェアエンジニアリングのコースで保守性が重視されておらず、明確で変更不可能な仕様を持つ単発課題が与えられていることです。[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. ^ ab Tripathy & Naik 2014、p. 25.
  2. ^ abcdef Offutt, Jeff (2018年1月). 「ソフトウェアのメンテナンスと進化の概要」.ジョージ・メイソン大学コンピュータサイエンス学部. 2024年5月5日閲覧。
  3. ^ トリパシー＆ナイク 2014、4ページ。
  4. ^ Tripathy & Naik 2014、5–6 ページ。
  5. ^ ab Tripathy & Naik 2014、p. 26.
  6. ^ マドゥスダンら。 2017、p. 761.
  7. ^ Varga 2018、3ページ。
  8. ^ abc トリパシーとナイク 2014、p. 7.
  9. ^ abcde Ulziitら。 2015、p. 764。
  10. ^ ab Reifer 2012、22ページ。
  11. ^ ライファー 2012、21ページ。
  12. ^ abc トリパシーとナイク 2014、p. 89.
  13. ^ マドゥスダンら。 2017、p. 763.
  14. ^ Tripathy & Naik 2014、p. 120.
  15. ^ マドゥスダンら。 2017、p. 762.
  16. ^ ab Tripathy & Naik 2014、p. 123.
  17. ^ Ali et al. 2024, p.126.
  18. ^ Ali et al. 2024, p. 130.
  19. ^ Tripathy & Naik 2014、p. 296.
  20. ^ Tripathy & Naik 2014、296–297 ページ。
  21. ^ Tripathy & Naik 2014、p. 309.
  22. ^ Tripathy & Naik 2014、p. 297.
  23. ^ Tripathy & Naik 2014、pp. 318–319。
  24. ^ Tripathy & Naik 2014、85–86 ページ。
  25. ^ Tripathy & Naik 2014、p. 86.
  26. ^ ab Tripathy & Naik 2014、p. 94.
  27. ^ Tripathy & Naik 2014、p. 59.
  28. ^ ライファー 2012、5ページ。
  29. ^ Tripathy & Naik 2014、p. 98.
  30. ^ Varga 2018、4ページ。
  31. ^ abcdef Varga 2018、5ページ。
  32. ^ Tripathy & Naik 2014、26–27 ページ。
  33. ^ abcdef Tripathy & Naik 2014、p. 27.
  34. ^ Varga 2018、5～6頁参照。
  35. ^ Varga 2018、p.5 fn4。
  36. ^ ヴァルガ 2018、12ページ。
  37. ^ ヴァルガ 2018、6～7頁。
  38. ^ ヴァルガ 2018、7ページ。
  39. ^ ヴァルガ 2018、7～8頁。
  40. ^ ヴァルガ 2018、9ページ。
  41. ^ マドゥスダンら。 2017、p. 764。
  42. ^ ab Reifer 2012、p.7を参照。
  43. ^ ab Reifer 2012、p.8を参照。
  44. ^ ライファー 2012、1ページ。
  45. ^ ラーマン他2024年、1頁。
  46. ^ Rahman et al. 2021、「研究の背景」。
  47. ^ Ulziit et al. 2015, p.763.
  48. ^ ライファー 2012、2ページ。
  49. ^ Tripathy & Naik 2014、187–188 ページ。
  50. ^ abcde Tripathy & Naik 2014、p. 188.
  51. ^ Tripathy & Naik 2014、p. 189.
  52. ^ Tripathy & Naik 2014、p. 191.
  53. ^ Tripathy & Naik 2014、188–189 ページ。
  54. ^ Tripathy & Naik 2014、p. 195.
  55. ^ ab Tripathy & Naik 2014、p. 196.
  56. ^ マドゥスダンら。 2017、p. 759。
  57. ^ Ulziit et al. 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。