ソフトウェア開発

ソフトウェア開発とは、特定のユーザーニーズやビジネス目標を満たすソフトウェアアプリケーションの設計、作成、テスト、保守を行うプロセスです。このプロセスは、プログラミング（コードの作成）よりも包括的であり、目標の構想、実現可能性の評価、要件分析、設計、テスト、リリースなどが含まれます。このプロセスは、組織管理、プロジェクト管理、構成管理などの側面も含むソフトウェアエンジニアリングの一部です。 [ 1 ]

ソフトウェア開発には、プログラミング、テスト、ドキュメント作成、グラフィック デザイン、ユーザー サポート、マーケティング、資金調達など、多くのスキルと職務の専門分野が関係します。

ソフトウェア開発には、コンパイラ、統合開発環境(IDE)、バージョン管理、コンピュータ支援ソフトウェアエンジニアリング、ワードプロセッサ など、多くのツールが関係します。

開発作業に用いられるプロセスの詳細は様々です。プロセスは、正式な文書化された標準規格に限定される場合もあれば、開発作業に合わせてカスタマイズされ、新たに出現する場合もあります。プロセスは順次進行し、各主要フェーズ（設計、実装、テスト）が完了するまで次のフェーズに進む場合もありますが、反復的なアプローチ、つまり小さな側面を個別に設計、実装、テストすることで、リスクとコストを削減し、品質を向上させることができます。

方法論

反復型開発モデルである進化型プロトタイピングモデルのフローチャート[ 2 ]

利用可能な各方法論は、さまざまな技術、組織、プロジェクト、チームの考慮事項に基づいて、特定の種類のプロジェクトに最適です。[ 3 ]

  • 最もシンプルな手法は「コーディング＆フィックス」で、通常は小規模なプロジェクトに携わる一人のプログラマーが用いる。プログラマーはプログラムの目的を簡単に検討した後、コードを記述し、動作確認を行う。完了すると、製品がリリースされる。この手法はプロトタイプには有効だが、より複雑なプログラムには適用できない。[ 4 ]
  • トップダウン型のウォーターフォールモデルでは、実現可能性調査、分析、設計、開発、品質保証、実装が順に行われます。このモデルでは、次のステップを開始する前に1つのステップを完了する必要があるため、遅延が発生し、必要に応じて前のステップを修正することが不可能になります。[ 5 ] [ 6 ] [ 7 ]
  • 反復的なプロセスでは、これらのステップは互いに交互に実行されるため、柔軟性、効率性、およびより現実的なスケジュールが向上します。プロジェクトを一度にすべて完了するのではなく、一度に 1 つのコンポーネントでほとんどのステップを実行することもできます。反復的な開発では、開発者が最も重要な機能を優先し、優先度の低い機能を必要に応じて後で削除することもできます。[ 6 ] [ 8 ]アジャイルは、もともと小規模または中規模のプロジェクトを対象とした人気の高い手法の 1 つで、開発者が作業する機能に対する制御を強化して、時間やコストの超過のリスクを軽減することに重点を置いています。[ 9 ]アジャイルの派生としては、エクストリームプログラミングやスクラムなどがあります。[ 9 ]オープンソースソフトウェア開発では、通常、ボランティア貢献者の分散ネットワークに依存しているため、設計、コーディング、テストを並行して行うアジャイル手法が使用されます。[ 10 ]
  • アジャイルを超えて、一部の企業は情報技術（IT）運用とソフトウェア開発を統合しており、これはコンピュータセキュリティを含むDevOpsまたはDevSecOpsと呼ばれています。[ 11 ] DevOpsには、継続的な開発、テスト、バージョン管理システムへの新しいコードの統合、新しいコードの展開、場合によってはクライアントへのコードの配信が含まれます。 [ 12 ]この統合の目的は、ITサービスをより迅速かつ効率的に提供することです。[ 11 ]

多くのプログラミング方法論におけるもう一つの焦点は、セキュリティ上の脆弱性やバグなどの問題をできるだけ早く捕捉し（シフトレフトテスト）、それらの追跡と修正にかかるコストを削減するという考え方です。 [ 13 ]

2009年には、ソフトウェアプロジェクトの32%が予定通り予算内で、完全な機能を備えて納品されたと推定されました。さらに44%は納品されたものの、少なくとも1つの機能が欠落していました。残りの24%はリリース前にキャンセルされました。[ 14 ]

ライフサイクル

ソフトウェア開発ライフサイクルは、ソフトウェア開発プロセスの典型的な段階を説明します。[ 15 ]

実現可能性

ソフトウェア製品のアイデアの源は豊富にあります。これらのアイデアは、市場調査（潜在的な新規顧客、既存顧客、製品を拒否した見込み客、社内の他のソフトウェア開発スタッフ、あるいは創造的な第三者の人口統計を含む）から生まれます。ソフトウェア製品のアイデアは通常、マーケティング担当者によって最初に評価され、経済的な実現可能性、既存の流通チャネルとの適合性、既存の製品ラインへの影響の可能性、必要な機能、そして会社のマーケティング目標との適合性が評価されます。マーケティング評価段階では、コストと時間の想定が評価されます。[ 16 ]実現可能性分析では、プロジェクトの投資収益率、開発コスト、そして期間が見積もられます。この分析に基づいて、会社はさらなる開発への投資に関するビジネス上の決定を下すことができます。[ 17 ]ソフトウェア開発を決定した後、会社は見積もられたコストと期間内で、またはそれ以下で、高い品質基準（つまり、バグがない）と必要な機能を備えた製品を提供することに注力します。しかしながら、ほとんどのソフトウェアプロジェクトは遅延し、期限に間に合わせるために機能や品質が妥協されることもあります。[ 18 ]

分析

ソフトウェア分析は、ソフトウェアのビジネスニーズを把握するための要件分析から始まります。 [ 19 ]ニーズを特定する際の課題は、現在のユーザーまたは潜在的なユーザーがそれぞれ異なる互換性のないニーズを持っている場合があり、自分のニーズを理解していない場合や、ソフトウェア開発の過程でニーズが変化する場合があることです。[ 20 ]最終的に、分析の結果は、開発者が作業できる製品の詳細な仕様です。ソフトウェアアナリストは、多くの場合、プロジェクトをより小さなオブジェクト、つまり再利用できるコンポーネントに分解して、費用対効果、効率性、信頼性を高めます。[ 19 ]プロジェクトを分解することで、マルチプロセッサコンピュータで大幅に高速に動作するマルチスレッド実装が可能になります。[ 21 ]

ソフトウェア開発の分析および設計段階では、構造化分析がよく使用され、顧客の要件をソフトウェアプログラマが実装できる部分に分解します。[ 22 ]プログラムの基礎となるロジックは、データフロー図、データ辞書、疑似コード、状態遷移図、および/またはエンティティ関係図で表すことができます。[ 23 ]プロジェクトにモデル化されていないレガシーソフトウェアが組み込まれている場合は、このソフトウェアをモデル化して、新しいソフトウェアに正しく組み込まれるようにすることができます。[ 24 ]

デザイン

設計には、使用するプログラミング言語やデータベースソフトウェア、ハードウェアとネットワーク通信の構成方法など、ソフトウェアの実装に関する選択が含まれます。設計は、ユーザーのニーズを試行錯誤の過程で相談しながら反復的に行われる場合があります。設計には、データベース設計、画面アーキテクチャ、サーバーやその他のハードウェアのパフォーマンスなどの専門家が関与することがよくあります。 [ 19 ]デザイナーは、ソフトウェアの機能からパターンを見つけて、オブジェクト指向プログラミングで再利用できる個別のモジュールを作成しようとすることがよくあります。その一例は、グラフィカルユーザーインターフェイスとバックエンドの間のインターフェイスであるモデル・ビュー・コントローラーです。[ 25 ]

プログラミング

ソフトウェア開発の中心的な特徴は、望ましい機能を実装するソフトウェアを作成し、それを理解することです。[ 26 ]コードの記述にはさまざまな戦略があります。凝集性の高いソフトウェアには、互いに独立したさまざまなコンポーネントがあります。[ 19 ]結合とは、異なるソフトウェアコンポーネントの相互関係であり、保守の難易度が増すため望ましくないと見なされています。[ 27 ]多くの場合、ソフトウェアプログラマは業界のベストプラクティスに従わず、非効率で理解しにくいコードや、機能に関するドキュメントが不足しているコードが作成されます。 [ 28 ]これらの標準は、期限がある場合に特に破綻する可能性が高くなります。[ 29 ]その結果、コードのテスト、デバッグ、および修正がはるかに困難になります。コードリファクタリング、たとえばコードにコメントを追加することは、コードの理解可能性を向上させる解決策です。[ 30 ]

テスト

テストとは、コードが正しくエラーなく実行されることを確認するプロセスです。各ソフトウェア開発者は、自分のコードに対してデバッグを実行し、コードが意図したとおりに動作することを確認します。特に、結果が間違っていても、ソフトウェアがすべての入力に対して実行できることが非常に重要です。[ 31 ]他の開発者によるコードレビューは、プロジェクトに追加された新しいコードを精査するためによく使用され、ある推定によると、テスト完了後に残るバグの数が大幅に減少します。[ 32 ]コードが提出されると、品質保証（ほとんどの大企業では非プログラマーで構成された独立した部門）がソフトウェア製品全体の正確性をテストします。元のソフトウェア要件から派生した受け入れテストは、このための一般的なツールです。[ 31 ]品質テストには、ストレスおよび負荷チェック（ソフトウェアが大量の入力や使用に対して堅牢かどうか）、統合テスト（ソフトウェアが他のソフトウェアと適切に統合されていることを確認する）、互換性テスト（さまざまなオペレーティングシステムやブラウザー間でのソフトウェアのパフォーマンスを測定する）も含まれることがよくあります。[ 31 ]コードの前にテストを書くことをテスト駆動開発と呼びます。[ 33 ]

生産

生産段階は、ソフトウェアがエンドユーザーに展開される段階です。[ 34 ]生産段階中に、開発者はユーザー向けの技術サポートリソース[ 35 ] [ 34 ]を作成したり、以前に発見されなかったバグやエラーを修正するプロセスを作成したりすることがあります。ユーザーのニーズが変化したり、誤解されたりした場合は、以前の開発段階に戻る必要がある場合もあります。[ 34 ]

労働者

ソフトウェア開発は、通常チームを組んで作業するソフトウェア開発者によって行われます。チームメンバー間の効率的なコミュニケーションは成功に不可欠です。チームが小規模で、共同作業に慣れており、メンバーが近くにいる場合、これはより容易に実現できます。 [ 36 ]コミュニケーションはまた、開発の早い段階で問題を特定し、重複作業を回避するのにも役立ちます。多くの開発プロジェクトでは、複数の作業者が各コンポーネントに精通していることを確認することで、1人の従業員だけが持つ重要な知識が失われるリスクを回避しています。[ 37 ]ソフトウェア開発には、ソフトウェアプログラマーだけでなく、製品の戦略とロードマップを策定するプロダクトマネージャー、 [ 38 ]テスト、ドキュメント作成、グラフィックデザイン、ユーザーサポート、マーケティング、資金調達の専門家など、様々な分野の専門家が関わっています。プロプライエタリソフトウェアの作業員は有給ですが、オープンソースソフトウェアの貢献者のほとんどはボランティアです。[ 39 ]あるいは、ソフトウェアの販売ではなく、オープンソースソフトウェアへのサービスや改変など、別のビジネスモデルを持つ企業から有給で報酬を得る場合もあります。 [ 40 ]

モデルとツール

コンピュータ支援ソフトウェアエンジニアリング

コンピュータ支援ソフトウェアエンジニアリング（CASE）は、ソフトウェア開発の部分的な自動化のためのツールです。[ 41 ] CASEを使用すると、設計者は、これから作成するプログラムでも、既存のプログラムでも、プログラムのロジックをスケッチして、新しいコードと統合したり、リバースエンジニアリング（たとえば、プログラミング言語を変更する）したりできます。[ 42 ]

ドキュメント

ドキュメントには、通常分けて保管される2つの形式があります。1つはソフトウェア開発者向けで、もう1つはエンドユーザーがソフトウェアを使用する際に役立つように提供されます。[ 43 ] [ 44 ]開発者向けドキュメントのほとんどは、各ファイル、クラス、メソッドのコードコメントの形式をとっており、アプリケーションプログラミングインターフェース（API）（ソフトウェアが他のソフトウェアからアクセスする方法）と実装の詳細について説明しています。 [ 45 ]このドキュメントは、新しい開発者がプロ​​ジェクトに取り組み始める際にプロジェクトを理解するのに役立ちます。[ 46 ]アジャイル開発では、ドキュメントはコードと同時に作成されることがよくあります。[ 47 ]ユーザードキュメントは、テクニカルライターによって作成されることが多いです。[ 48 ]

労力見積もり

正確な見積りは、実現可能性の段階と、製品を時間通りに予算内で納品する上で非常に重要です。見積りを作成するプロセスは、多くの場合、プロジェクトマネージャーによって委任されます。[ 49 ]労力の見積りは完成したアプリケーションの規模に直接関係するため、要件への機能の追加によって大きく影響されます。要件が多いほど、開発コストは高くなります。ソフトウェア開発者の経験やコードの再利用性など、機能性に関係のない側面も、見積りにおいて考慮することが不可欠です。[ 50 ] 2019年現在、ソフトウェア開発にかかる時間とリソースの量を見積もるツールのほとんどは、従来のアプリケーション向けに設計されており、 Webアプリケーションやモバイルアプリケーションには適用できません。[ 51 ]

統合開発環境

Anjuta、GNOME 環境用の C および C++ IDE

統合開発環境（IDE）は、単純なテキストエディタに比べて強化された機能でソフトウェア開発をサポートします。[ 52 ] IDEには、自動コンパイル、構文エラーの強調表示、[ 53 ]デバッグ支援、[ 54 ]バージョン管理との統合、テストの半自動化などが含まれることがよくあります。 [ 52 ]

バージョン管理

バージョン管理は、ソフトウェアに加えられた変更を管理する一般的な方法です。新しいバージョンがチェックインされるたびに、ソフトウェアは変更されたすべてのファイルのバックアップを保存します。複数のプログラマーが同時にソフトウェアで作業している場合、ソフトウェアはコード変更のマージを管理します。ソフトウェアは、2つの変更セットの間に競合がある場合にそれを強調表示し、プログラマーが競合を修正できるようにします。[ 55 ]

モデルを表示

TEAFの視点と観点のマトリックス

ビューモデルとは、ソフトウェア開発プロセスで使用される、システムとその環境に関する視点を提供するフレームワークです。ビューの基盤となるセマンティクスをグラフィカルに表現したものです。

ビューポイントとビューの目的は、人間のエンジニアが非常に複雑なシステムを理解し、専門分野を中心に問題の要素を整理できるようにすることです。物理的に集約的なシステムのエンジニアリングにおいて、ビューポイントはエンジニアリング組織内の能力と責任に対応することがよくあります。[ 56 ]

適応度関数

適合性関数は、新しい開発が確立された制約、チェック、コンプライアンス管理から逸脱しないことを確認するための自動化された客観的なテストです。[ 57 ]

知的財産

開発者がオープンソースコードやライブラリをプロプライエタリ製品に統合する場合、知的財産権の問題が生じる可能性があります。これは、ソフトウェアに使用されるオープンソースライセンスのほとんどが、改変版を同じライセンスの下でリリースすることを要求しているためです。開発者は代替案として、プロプライエタリライセンスを選択したり、独自のソフトウェアモジュールを作成したりすることもできます。[ 58 ]

参考文献

  1. ^ドゥーリー 2017、1ページ。
  2. ^ドゥーリー 2017、12ページ。
  3. ^ Web対応Eビジネスのためのシステム開発方法論：カスタマイズフレームワーク Linda V. Knight（米国デポール大学）、Theresa A. Steinbach（米国デポール大学）、Vince Kellen（米国ブルーウルフ大学）
  4. ^ドゥーリー 2017、8～9頁。
  5. ^ドゥーリー 2017、9ページ。
  6. ^ a bランガー 2016、pp.2–3, 5–6。
  7. ^タッカー、モレリ、デ・シルバ、2011、p. 8.
  8. ^ドゥーリー 2017、11ページ。
  9. ^ a bドゥーリー 2017、p. 13。
  10. ^タッカー、モレリ、デ・シルバ、2011 年、41–42 ページ。
  11. ^ a bヴィシュヌ 2019、pp.1–2。
  12. ^ Laukkanen, Eero; Itkonen, Juha; Lassenius, Casper (2017). 「継続的デリバリー導入における問題、原因、解決策 ― 体系的な文献レビュー」情報ソフトウェア技術82 : 55–79 . doi : 10.1016/j.infsof.2016.10.001 .
  13. ^ Winters、Manshreck、Wright 2020、17ページ。
  14. ^タッカー、モレリ、デ・シルバ、2011、p. 6.
  15. ^サイフ 2019、46～47頁。
  16. ^モリス 2001、1.10ページ。
  17. ^ランガー 2016、7ページ。
  18. ^ドゥーリー 2017、3、8頁。
  19. ^ a b c dランガー 2016、p.8。
  20. ^ランガー 2016、2～3頁。
  21. ^ドゥーリー 2017、193–194頁。
  22. ^ランガー 2016、103–104 ページ。
  23. ^ランガー 2016、117、127、131、137、141 ページ。
  24. ^ランガー 2016、106ページ。
  25. ^ドゥーリー 2017、142頁。
  26. ^タッカー、モレリ、デ・シルバ、2011、p. 31.
  27. ^ランガー 2016、8～9頁。
  28. ^タッカー、モレリ、デ・シルバ、2011 年、31–32 ページ。
  29. ^タッカー、モレリ、デ・シルバ、2011 年、34–35 ページ。
  30. ^タッカー、モレリ、デ・シルバ、2011 年、31–32、35 ページ。
  31. ^ a b cランガー 2016、9ページ。
  32. ^ドゥーリー 2017、272頁。
  33. ^タッカー、モレリ、デ・シルバ、2011、p. 9.
  34. ^ a b cランガー 2016、p. 10。
  35. ^タッカー、モレリ、デ・シルバ、2011、p. 37.
  36. ^ドゥーリー 2017、2ページ。
  37. ^ウィンターズ、マンシュレック、ライト 2020、30～31頁。
  38. ^ 「プロダクトマネージャーの仕事とは？そしてプロダクトマネージャーになるには？」 Coursera 、 2025年1月21日。 2025年5月5日閲覧。
  39. ^タッカー、モレリ、デ・シルバ、2011、p. 7.
  40. ^タッカー、モレリ、デ・シルバ、2011 年、14–15 ページ。
  41. ^ランガー 2016、22ページ。
  42. ^ランガー 2016、108–110、206 ページ。
  43. ^タッカー、モレリ、デ・シルバ、2011、p. 243.
  44. ^ Winters、Manshreck、Wright 2020、192ページ。
  45. ^ウィンターズ、マンシュレック、ライト 2020年、193～195頁。
  46. ^タッカー、モレリ、デ・シルバ、2011、p. 143.
  47. ^タッカー、モレリ、デ・シルバ、2011、p. 144.
  48. ^ Winters、Manshreck、Wright 2020、204ページ。
  49. ^サイフ 2019、50～51頁。
  50. ^サイフ 2019、52～53頁。
  51. ^サイフ 2019、45頁。
  52. ^ a bタッカー、モレリ、デシルバ 2011、68ページ。
  53. ^ドゥーリー 2017、236頁。
  54. ^ドゥーリー 2017、239頁。
  55. ^ドゥーリー 2017、246～247頁。
  56. ^ Edward J. Barkmeyer 他 (2003).システム統合の自動化の概念Archived 25 January 2017 at the Wayback Machine NIST 2003.
  57. ^ソフトウェアアーキテクチャの基礎：エンジニアリングアプローチ. O'Reilly Media. 2020. ISBN 978-1492043454。
  58. ^ランガー 2016、44～45頁。

さらに読む

  • コンデ、ダン（2002年）『ソフトウェア製品管理：アイデアから製品、マーケティング、販売までソフトウェア開発を管理する』Aspatore Books. ISBN 1587622025。
  • デイビス, AM (2005). 『十分な要件管理：ソフトウェア開発とマーケティングの出会い』 ドーセット・ハウス・パブリッシング・カンパニー. ISBN 0932633641。
  • ドゥーリー、ジョン・F. (2017). 『ソフトウェア開発、設計、コーディング：パターン、デバッグ、ユニットテスト、リファクタリング付き』 Apress. ISBN 978-1-4842-3153-1。
  • キット、エドワード (1992). 『現実世界におけるソフトウェアテスト』 . Addison-Wesley Professional. ISBN 0201877562。
  • ヘイステッド、エドワード（2005年）『売れるソフトウェア：ソフトウェアプロジェクトの開発とマーケティングの実践ガイド』Wiley Publishing. ISBN 0764597833。
  • ホーマン、ルーク（2003年）『ソフトウェアアーキテクチャを超えて：勝利をもたらすソリューションの創造と持続』 Addison-Wesley Professional. ISBN 0201775948。
  • Horch, John W. (1995年3月). 「オブジェクトの操作方法に関する2つの方向性」. IEEEソフトウェア. 12 (2): 117–118 . ProQuest 215832531 . 
  • ランガー、アーサー・M. (2016).ソフトウェア開発ガイド：ライフサイクルの設計と管理. シュプリンガー. ISBN 978-1-4471-6799-0。
  • マッカーシー、ジム（1995年）『ソフトウェア開発のダイナミクス』マイクロソフトプレス、ISBN 1556158238。
  • モリス、ジョセフ・M. (2001).ソフトウェア産業会計（第2版）. John Wiley & Sons . OCLC  53863959 .
  • リッティングハウス、ジョン（2003年）『ソフトウェア成果物の管理：ソフトウェア開発マネジメント手法』デジタルプレス、ISBN 155558313X。
  • Saif, Syed Mohsin (2019). 「ソフトウェアアプリケーション開発を成功させるためのソフトウェア工数見積り」. Vishnu, Pendyala (編). 『大規模組織におけるソフトウェア開発のためのツールとテクニック：新たな研究と機会』 . IGI Global . pp.  45– 97. ISBN 978-1-7998-1865-6。
  • タッカー、アレン、モレリ、ラルフ、デ・シルバ、チャミンドラ (2011). 『ソフトウェア開発：オープンソースアプローチ』CRC Press. ISBN 978-1-4398-8460-7。
  • Vishnu, Pendyala (2019). 「統合、ビルド、テスト、リリースエンジニアリングのDevOpsおよびDevSecOpsへの進化」. Vishnu, Pendyala (編). 『大規模組織におけるソフトウェア開発のためのツールとテクニック：新たな研究と機会』 . IGI Global. pp.  1– 20. ISBN 978-1-7998-1865-6。
  • Wiegers, Karl E. (2005). 『ソフトウェア要件についてもっと知る：難題と実践的アドバイス』 Microsoft Press. ISBN 0735622671。
  • ウィンターズ、タイタス​​、マンシュレック、トム、ライト、ハイラム（2020年）『Googleのソフトウェアエンジニアリング：長年のプログラミング経験から学んだ教訓』 O'Reilly Media, Inc. ISBN 978-1-4920-8276-7。
  • ワイソッキー、ロバート・K.（2006年）『効果的なソフトウェアプロジェクトマネジメント』Wiley社、ISBN 0764596365。
「 https://en.wikipedia.org/w/index.php?title=Software_development&oldid=1334727856#Workers」より取得