Loading article…
ソフトウェア開発は、ソフトウェアを作成するために使用されるプロセスです。ソースコードのプログラミングと保守はこのプロセスの中心的なステップですが、プロジェクトの構想、実現可能性の評価、ビジネス要件の分析、ソフトウェアの設計、テスト、リリースも含まれます。 ソフトウェアエンジニアリングには、開発に加えて、プロジェクト管理、従業員管理、およびその他の間接機能も含まれます。[1]ソフトウェア開発は、各ステップが完了してから次のステップを開始する順次的な開発方法である場合もありますが、複数のステップを一度に実行したり、以前のステップに戻ったりできる反復的な開発方法も考案されており、柔軟性、効率性、およびスケジュールを改善しています。
ソフトウェア開発には、ソフトウェア プログラマーだけでなく、テスト、ドキュメント作成、グラフィック デザイン、ユーザー サポート、マーケティング、資金調達など、さまざまな分野の専門家が関わります。ソフトウェア開発では、統合開発環境(IDE)、バージョン管理、コンピューター支援ソフトウェアエンジニアリング、ソフトウェア ドキュメントなど、さまざまなツールとモデルが一般的に使用されています。
方法論
利用可能な各方法論は、さまざまな技術、組織、プロジェクト、チームの考慮事項に基づいて、特定の種類のプロジェクトに最適です。[3]
- 最も単純な方法は「コードと修正」で、通常は小規模なプロジェクトに取り組む 1 人のプログラマーによって使用されます。プログラマーはプログラムの目的を簡単に検討した後、コードを記述して実行し、動作するかどうかを確認します。完了すると、製品がリリースされます。この方法論はプロトタイプには便利ですが、より複雑なプログラムには使用できません。[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]によって行われ、通常はチームで作業します。チームメンバー間の効率的なコミュニケーションは成功に不可欠です。チームが小規模で、共同作業に慣れていて、お互いの近くにいる場合、これはより簡単に達成できます。[37]コミュニケーションはまた、開発の早い段階で問題を特定し、重複した作業を回避するのに役立ちます。多くの開発プロジェクトでは、複数の作業者が各コンポーネントに精通していることを確認することで、1人の従業員だけが持つ重要な知識が失われるリスクを回避しています。[38]ソフトウェア開発には、ソフトウェアプログラマーだけでなく、テスト、ドキュメント作成、グラフィックデザイン、ユーザーサポート、マーケティング、資金調達を専門とする個人など、さまざまな分野の専門家が関与しています。プロプライエタリソフトウェアの作業員は報酬を受け取りますが、オープンソースソフトウェアの貢献者のほとんどはボランティアです。[39]あるいは、ソフトウェアの販売ではなく、サービスやオープンソースソフトウェアの変更など、他のビジネスモデルを持つ企業から報酬を受け取る場合があります。[40]
モデルとツール
コンピュータ支援ソフトウェアエンジニアリング
コンピュータ支援ソフトウェアエンジニアリング（CASE）は、ソフトウェア開発の部分的な自動化のためのツールです。[41] CASEを使用すると、設計者は、これから書くプログラムでも、既存のプログラムでも、プログラムのロジックをスケッチして、新しいコードと統合したり、リバースエンジニアリング（たとえば、プログラミング言語を変更する）したりできます。[42]
ドキュメント
ドキュメントには、通常、ソフトウェア開発者向けのものと、エンドユーザーがソフトウェアを使用する際に役立つように提供されるものの 2 つの形式があり、別々に保管されます。[43] [44]開発者向けドキュメントのほとんどは、ファイル、クラス、メソッドごとのコードコメントの形式であり、アプリケーションプログラミングインターフェース(API) (ソフトウェアが他のソフトウェアからアクセスされる方法) と実装の詳細をカバーしています。[ 45]このドキュメントは、新しい開発者がプロジェクトに取り組み始めるときにプロジェクトを理解するのに役立ちます。[46]アジャイル開発では、ドキュメントはコードと同時に作成されることがよくあります。[47]ユーザー向けドキュメントは、テクニカルライターによって作成されることが多いです。[48]
労力見積もり
正確な見積りは、実現可能性の段階や、製品を時間通りに予算内で納品する上で非常に重要です。見積りの作成プロセスは、多くの場合、プロジェクトマネージャーによって委任されます。[49]労力の見積りは完成したアプリケーションのサイズに直接関係するため、要件の機能の追加によって大きく影響されます。要件が多いほど、開発コストが高くなります。ソフトウェア開発者の経験やコードの再利用性など、機能に関係のない側面も、見積りで考慮することが重要です。[50] 2019年現在、ソフトウェア開発にかかる時間とリソースの量を見積もるツールのほとんどは、従来のアプリケーション用に設計されており、 Webアプリケーションやモバイルアプリケーション[update]には適用できません。[51]
統合開発環境
統合開発環境（IDE）は、単純なテキストエディタに比べて強化された機能でソフトウェア開発をサポートします。[52] IDEには、自動コンパイル、構文エラーの強調表示、[53]デバッグ支援、[54]バージョン管理との統合、テストの半自動化などが含まれることがよくあります。 [52]
バージョン管理
バージョン管理は、ソフトウェアに加えられた変更を管理する一般的な方法です。新しいバージョンがチェックインされるたびに、ソフトウェアは変更されたすべてのファイルのバックアップを保存します。複数のプログラマーが同時にソフトウェアで作業している場合、ソフトウェアはコード変更のマージを管理します。ソフトウェアは、2つの変更セットの間に競合がある場合にそれを強調表示し、プログラマーが競合を修正できるようにします。[55]
モデルを表示
ビューモデルは、ソフトウェア開発プロセスで使用されるシステムとその環境の視点を提供するフレームワークです。ビューの基本的なセマンティクスをグラフィカルに表現したものです。
視点とビューの目的は、人間のエンジニアが非常に複雑なシステムを理解し、専門分野を中心に問題の要素を整理できるようにすることです。物理的に集中的なシステムのエンジニアリングでは、視点はエンジニアリング組織内の能力と責任に対応することがよくあります。[56]
フィットネス関数
適合性機能は、新しい開発が確立された制約、チェック、コンプライアンス制御から逸脱しないことを確認するための自動化された客観的なテストです。[57]
知的財産
開発者がオープンソースコードやライブラリをプロプライエタリ製品に統合する場合、知的財産が問題となる可能性がある。ソフトウェアに使用されるオープンソースライセンスのほとんどでは、変更内容は同じライセンスの下でリリースされることが求められるためである。代替案として、開発者はプロプライエタリな代替案を選択するか、独自のソフトウェアモジュールを作成することができる。[58]
参考文献
- ^ ドゥーリー 2017、1ページ。
- ^ ドゥーリー2017、12ページ。
- ^ Web 対応 E ビジネス向けシステム開発方法論: カスタマイズ フレームワーク Linda V. Knight (DePaul University、米国)、Theresa A. Steinbach (DePaul University、米国)、Vince Kellen (Blue Wolf、米国)
- ^ ドゥーリー2017、8-9頁。
- ^ ドゥーリー 2017、9ページ。
- ^ ab Langer 2016、pp.2–3、5–6。
- ^ タッカー、モレリ、デ・シルバ、2011、p. 8.
- ^ ドゥーリー2017、11ページ。
- ^ ab Dooley 2017、p. 13を参照。
- ^ タッカー、モレリ、デ・シルバ、2011 年、41–42 ページ。
- ^ ab Vishnu 2019、pp.1-2を参照。
- ^ Laukkanen, Eero; Itkonen, Juha; Lassenius, Casper (2017). 「継続的デリバリーを採用する際の問題、原因、解決策 - 体系的な文献レビュー」.情報およびソフトウェア技術. 82 : 55–79. doi : 10.1016/j.infsof.2016.10.001 .
- ^ ウィンターズ、マンシュレック、ライト 2020、17ページ。
- ^ タッカー、モレリ、デ・シルバ、2011、p. 6.
- ^ サイフ2019、46-47頁。
- ^ モリス 2001、1.10 ページ。
- ^ ランガー 2016、7ページ。
- ^ ドゥーリー 2017、3、8頁。
- ^ abcd Langer 2016、8ページ。
- ^ ランガー 2016、2-3頁。
- ^ ドゥーリー2017、193-194頁。
- ^ ランガー2016、103-104頁。
- ^ ランガー2016、117、127、131、137、141頁。
- ^ ランガー2016、106頁。
- ^ ドゥーリー2017、142頁。
- ^ タッカー、モレリ、デ・シルバ、2011、p. 31.
- ^ ランガー2016、8-9頁。
- ^ タッカー、モレリ、デ・シルバ、2011 年、31–32 ページ。
- ^ タッカー、モレリ、デ・シルバ、2011 年、34–35 ページ。
- ^ タッカー、モレリ、デ・シルバ、2011 年、31–32、35 ページ。
- ^ abc Langer 2016、9ページ。
- ^ ドゥーリー2017、272頁。
- ^ タッカー、モレリ、デ・シルバ、2011、p. 9.
- ^ abc Langer 2016、10ページ。
- ^ タッカー、モレリ、デ・シルバ、2011、p. 37.
- ^ 「ソフトウェア開発とは? | IBM」www.ibm.com 2021年7月14日2024年9月29日閲覧。
- ^ ドゥーリー 2017、2ページ。
- ^ ウィンターズ、マンシュレック＆ライト 2020年、30～31頁。
- ^ タッカー、モレリ、デ・シルバ、2011、p. 7.
- ^ タッカー、モレリ、デ・シルバ、2011 年、14–15 ページ。
- ^ ランガー2016、22頁。
- ^ ランガー2016、108-110頁、206頁。
- ^ タッカー、モレリ、デ・シルバ、2011、p. 243.
- ^ ウィンターズ、マンシュレック、ライト2020年、192頁。
- ^ ウィンターズ、マンシュレック、ライト 2020年、193〜195頁。
- ^ タッカー、モレリ、デ・シルバ、2011、p. 143.
- ^ タッカー、モレリ、デ・シルバ、2011、p. 144.
- ^ ウィンターズ、マンシュレック、ライト2020年、204頁。
- ^ サイフ2019、50-51頁。
- ^ サイフ2019、52-53頁。
- ^ サイフ2019、45頁。
- ^ ab タッカー、モレリ、デ・シルバ、2011、p. 68.
- ^ ドゥーリー2017、236頁。
- ^ ドゥーリー2017、239頁。
- ^ ドゥーリー2017、246-247頁。
- ^ Edward J. Barkmeyer 他 (2003). システム統合の自動化の概念 Archived 25 January 2017 at the Wayback Machine NIST 2003.
- ^ ソフトウェアアーキテクチャの基礎：エンジニアリングアプローチ。オライリーメディア。2020年。ISBN 978-1492043454。
- ^ ランガー2016、44-45頁。
さらに読む
- Conde, Dan (2002)。『ソフトウェア製品管理: アイデアから製品、マーケティング、販売までのソフトウェア開発の管理』Aspatore Books。ISBN 1587622025。
- Davis, AM (2005)。十分な要件管理: ソフトウェア開発とマーケティングの出会い。Dorset House Publishing Company, Incorporated。ISBN 0932633641。
- Dooley, John F. (2017)。ソフトウェア開発、設計、コーディング: パターン、デバッグ、単体テスト、リファクタリング付き。Apress。ISBN 978-1-4842-3153-1。
- キット、エドワード (1992)。『現実世界におけるソフトウェアテスト』 。Addison -Wesley Professional。ISBN 0201877562。
- ハステッド、エドワード (2005)。『売れるソフトウェア: ソフトウェアプロジェクトの開発とマーケティングの実践ガイド』。Wiley Publishing。ISBN 0764597833。
- Hohmann, Luke (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。
- Wysocki, Robert K. (2006).効果的なソフトウェアプロジェクト管理. Wiley. ISBN 0764596365。
外部リンク
ウィキメディア・コモンズのソフトウェア開発に関連するメディア