ソフトウェア開発

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

ソフトウェア開発は、アプリケーションフレームワーク、またはその他のソフトウェアコンポーネントの作成と保守に関連する、構想、指定、設計、プログラミング文書化テスト、およびバグ修正のプロセスです。ソフトウェア開発はソースコードを記述および保守するプロセスですが、広義には、目的のソフトウェアの構想からソフトウェアの最終的な明示まで、場合によっては計画され構造化されたプロセスに含まれるすべてのものが含まれます。 [1]したがって、ソフトウェア開発には、研究、新規開発、プロトタイピング、変更、再利用、リエンジニアリング、メンテナンス、またはソフトウェア製品をもたらすその他の活動が含まれる場合があります。[2]

ソフトウェアはさまざまな目的で開発できます。最も一般的な3つは、特定のクライアント/ビジネスの特定のニーズを満たすこと(カスタムソフトウェアの場合)、潜在的なユーザーの認識されたニーズを満たすこと商用の場合)です。およびオープンソースソフトウェア)、または個人的な使用(たとえば、科学者が日常的なタスクを自動化するソフトウェアを作成する場合があります)。組み込みソフトウェアの開発、つまり、消費者製品の制御に使用されるような組み込みソフトウェアの開発では、開発プロセスを制御された物理的製品の開発統合する必要があります。システムソフトウェア アプリケーションとプログラミングプロセス自体の基礎となり、多くの場合、個別に開発されます。

ソフトウェア開発プロセスのより良い品質管理の必要性はソフトウェアエンジニアリングの分野を生み出しました。これは、エンジニアリング パラダイムで例示されている体系的なアプローチをソフトウェア開発のプロセスに適用することを目的としています

ソフトウェア開発ライフサイクルモデル、方法論、プロセス、またはモデルとして知られる、ソフトウェアプロジェクト管理への多くのアプローチがあります。ウォーターフォールモデルは、より最近の技術革新とは対照的、伝統的なバージョンであり、アジャイルソフトウェア開発

方法論

ソフトウェア開発プロセス(また、ソフトウェア開発方法論、モデル、またはライフサイクルとして知られる)に使用されるフレームワークである構造計画、及び現像のプロセス制御情報システムこのようなフレームワークは何年にもわたって進化してきており、それぞれに長所と短所があります。ソフトウェア開発にはいくつかの異なるアプローチがあります。ソフトウェアを開発するために、より構造化されたエンジニアリングベースのアプローチを採用するアプローチもあれば、ソフトウェアが1つずつ開発されるにつれて進化するより段階的なアプローチを採用するアプローチもあります。1つのシステム開発方法論が、必ずしもすべてのプロジェクトでの使用に適しているとは限りません。利用可能な各方法論は、さまざまな技術的、組織的、プロジェクト、およびチームの考慮事項に基づいて、特定の種類のプロジェクトに最適です。[3]

ほとんどの方法論は、ソフトウェア開発の次の段階のいくつかの組み合わせを共有しています。

  • 問題の分析
  • 市場調査
  • 提案されたソフトウェアの要件の収集
  • ソフトウェアの計画または設計を考案する
  • ソフトウェアの実装(コーディング)
  • ソフトウェアのテストとデバッグ
  • 展開
  • メンテナンスバグ修正

多くの場合、これらの段階はまとめてソフトウェア開発ライフサイクル(SDLC)と呼ばれます。ソフトウェア開発へのさまざまなアプローチは、これらの段階をさまざまな順序で実行するか、さまざまな段階に多かれ少なかれ時間を費やす可能性があります。ソフトウェア開発の各段階で作成されるドキュメントの詳細レベルも異なる場合があります。これらの段階は、順番に実行することも(「ウォーターフォール」ベースのアプローチ)、さまざまなサイクルまたは反復で繰り返すこともできます(より「極端な」アプローチ)。より極端なアプローチでは、通常、計画と文書化に費やす時間が少なくなり、自動テストのコーディングと開発に費やす時間が長くなります。。より「極端な」アプローチは、開発ライフサイクル全体にわたる継続的テストを促進するだけでなく、常に機能する(またはバグのない)製品を提供します。より構造化された、または「ウォーターフォール」ベースのアプローチは、実装(コーディング)が始まる前にリスクの大部分を評価し、ソフトウェアの詳細な計画を作成し、ソフトウェア開発ライフサイクル計画の後の段階で大幅な設計変更と再コーディングを回避しようとします。 。

さまざまな方法論には大きな長所と短所があり、ソフトウェアを使用して問題を解決するための最良のアプローチは、多くの場合、問題の種類によって異なります。問題が十分に理解されており、事前に効果的に作業を計画できる場合は、より「ウォーターフォール」ベースのアプローチが最適な場合があります。一方、問題が(少なくとも開発チームに)固有であり、ソフトウェアの構造を簡単に想像できない場合は、より「極端な」インクリメンタルアプローチが最適な場合があります。

ソフトウェア開発活動

必要性の特定

ソフトウェア製品のアイデアのソースは豊富です。これらのアイデアは、潜在的な新規顧客、既存の顧客、製品を拒否した販売見込み客、他の社内ソフトウェア開発スタッフ、または創造的な第三者人口統計含む市場調査から得られます。ソフトウェア製品のアイデアは通常、経済的実現可能性、既存のチャネル配布との適合性、既存の製品ラインへの影響の可能性、必要な機能について、マーケティング担当者によって最初に評価されます。、および会社のマーケティング目標に適合させるため。マーケティング評価フェーズでは、コストと時間の仮定が評価されます。マーケティングおよび開発スタッフによって生成されたより詳細な情報に基づいて、プロジェクトをさらに追求する必要があるかどうかについて、第1フェーズの早い段階で決定が下されます。[4]

「GreatSoftwareDebates」という本の中でAlan M. Davisは、「要件」の章の「ソフトウェア開発の欠けている部分」のサブチャプターで述べています

工学の学生は工学を学び、金融やマーケティングにさらされることはめったにありません。マーケティングの学生はマーケティングを学び、金融や工学に触れることはめったにありません。私たちのほとんどは、たった1つの分野のスペシャリストになります。問題を複雑にするために、私たちのほとんどは労働力の学際的な人々に会うので、模倣する役割はほとんどありません。それでも、ソフトウェア製品の計画は開発の成功に不可欠であり、複数の分野の知識が絶対に必要です。[5]

ソフトウェア開発には、クライアントが必要とするものを妥協したり超えたりすることが含まれる場合があるため、ソフトウェア開発プロジェクトは人材リスク管理知的財産予算編成危機管理などの技術的な懸念に迷い込む可能性があります。これらのプロセスは、ソフトウェア開発と重複するビジネス開発の役割

計画プロセス

計画は、プロジェクトに属するものを発見したいすべての活動の目的です。ソフトウェアプログラムを作成する際の重要なタスクは、要件または要件分析を抽出することです[6]顧客は通常、最終結果として何を望んでいるかについて抽象的な考えを持っていますが、ソフトウェアが何をすべきかを知りません。熟練した経験豊富なソフトウェアエンジニアは、この時点で、不完全、あいまい、または矛盾する要件を認識しています。ライブコードを頻繁にデモンストレーションすることで、要件が正しくないリスクを減らすことができます。

「要件が完全で一貫していることを保証するために要件フェーズに多大な努力が払われていますが、そうなることはめったにありません。新しい要件や変更された要件の影響を最小限に抑えることに関しては、ソフトウェア設計フェーズを最も影響力のあるフェーズとして残します。要件の変動性将来の、またはすでに進行中の開発努力に影響を与えるため、挑戦的です。」[7]

一般的な要件がクライアントから収集されたら、開発の範囲の分析を決定し、明確に述べる必要があります。これは、スコープドキュメントと呼ばれることがよくあります。

デザイン

要件が確立されると、ソフトウェアの設計ソフトウェア設計ドキュメントで確立できますこれには、メインモジュールの予備的または高レベルの設計、パーツがどのように組み合わされるかについての全体像(ブロック図など)が含まれます。この時点で、言語、オペレーティングシステム、およびハードウェアコンポーネントはすべてわかっている必要があります。次に、詳細な設計または低レベルの設計が作成されます。おそらく、概念実証としてまたは要件を強化するためのプロトタイピングが使用されます。

実装、テスト、文書化

実装は、ソフトウェアエンジニアが実際にプロジェクトのコードをプログラムするプロセスの一部です

ソフトウェアテストは、ソフトウェア開発プロセスの不可欠で重要なフェーズです。プロセスのこの部分では、欠陥ができるだけ早く認識されるようにします。一般にテスト駆動開発として知られている一部のプロセスでは、テストは実装の直前に開発され、実装の正確さのガイドとして機能する場合があります。

将来のメンテナンスと拡張を目的としたソフトウェアの内部設計の文書化は、開発全体を通じて行われます。これには、外部または内部のAPIの記述も含まれる場合があります開発チームが選択したソフトウェアエンジニアリングプロセスによって、必要な内部ドキュメント(ある場合)の量が決まります。プラン駆動型モデル(ウォーターフォールなど)は、通常、アジャイルモデルよりも多くのドキュメントを生成します

展開とメンテナンス

デプロイメントは、コードが適切にテストされ、リリースが承認され、販売されるか、実稼働環境に配布された直後に開始されます。これには、インストール、カスタマイズ(パラメーターを顧客の値に設定するなど)、テスト、および場合によっては長期間の評価が含まれる場合があります。[要出典]

ソフトウェアは正しく使用された場合にのみ有効であるため、ソフトウェアのトレーニングとサポートは重要です。[要出典]

新たに発見された障害や要件に対処するためのソフトウェアの保守拡張には、要件を見逃すとソフトウェアの再設計が必要になる可能性があるため、かなりの時間と労力がかかる可能性があります。[要出典]ほとんどの場合、報告された問題を修正し、ソフトウェアを実行し続けるために、定期的にメンテナンスが必要です。

サブトピック

モデルを見る

TEAFビューと展望のマトリックス。

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

視点とビューの目的は、人間のエンジニアが非常に複雑なシステムを理解し専門分野の領域を中心に問題の要素を整理できるようにすることです。工学物理的に集中的なシステムの、視点は、多くの場合、エンジニアリング組織内の能力と責任に対応しています。[8]

ほとんどの複雑なシステム仕様は非常に広範囲にわたるため、仕様のすべての側面を完全に理解できる人は誰もいません。さらに、私たちは皆、特定のシステムにさまざまな関心を持っており、システム仕様を調べる理由もさまざまです。業務執行は、システムの実装よりも思われるシステムメイクアップの異なる質問をします。したがって、視点フレームワークの概念は、特定の複雑なシステムの仕様に個別の視点を提供することです。これらの視点はそれぞれ、システムのいくつかの側面に関心を持つ聴衆を満足させます。各視点に関連付けられているのは、その視点の聴衆のために語彙とプレゼンテーションを最適化する視点言語です。

ビジネスプロセスとデータモデリング

情報の現在の状態をグラフィカルに表現することで、ユーザーとシステム開発者の両方に情報を提示するための非常に効果的な手段が提供されます。

ビジネスプロセスとデータモデル間の相互作用の例。[9]
  • ビジネスモデルは、ビジネス・プロセスをモデル化しているに関連する機能と、これらの機能を実行する組織を示しています。アクティビティと情報フローを描写することにより、プロセスの性質を視覚化、定義、理解、および検証するための基盤が作成されます。
  • データモデルは、格納される情報の詳細を提供し、最終製品は、コンピュータの生成である場合主な用途であるソフトウェアコードアプリケーションまたはコンピュータソフトウェアを補助するために、機能仕様の準備メイクまたは、購入決定を。ビジネスプロセスとデータモデル間の相互作用の例については、右の図を参照してください。[9]

通常、モデルは、ビジネス分析と呼ばれるインタビューの実施後に作成されます。インタビューは、プロセスを説明する必要な情報を抽出するように設計された一連の質問をするファシリテーターで構成されています。インタビュアーはファシリテーターと呼ばれ、情報を提供するのは参加者であることを強調します。ファシリテーターは、関心のあるプロセスについてある程度の知識を持っている必要がありますが、これは、プロセスの専門家に質問をするための構造化された方法論を持つほど重要ではありません。通常、ファシリテーターのチームが施設全体で情報を収集しており、すべてのインタビュアーからの情報の結果は、完了したらまとめる必要があるため、方法論は重要です。[9]

モデルは、プロセスの現在の状態を定義するものとして開発されます。この場合、最終製品は「現状のまま」のスナップショットモデルと呼ばれるか、プロセスに何を含めるべきかについてのアイデアのコレクションであり、「何ができるか」という結果になります。 -be "モデル。プロセスおよびデータモデルの生成を使用して、既存のプロセスおよび情報システムが健全であり、わずかな変更または拡張のみが必要かどうか、または是正措置としてリエンジニアリングが必要かどうかを判断できます。ビジネスモデルの作成は、情報処理を表示または自動化する方法以上のものです。分析を使用して、ビジネスまたは組織が業務を遂行する方法を根本的に変えることができます。[9]

コンピュータ支援ソフトウェア工学

コンピュータ支援ソフトウェア・エンジニアリング(CASE)、フィールド内のソフトウェア工学の発展にソフトウェアツールとメソッドのセットの科学的なアプリケーションであるソフトウェアいる高品質、欠陥のない、かつ保守ソフトウェア製品の結果。[10]また、ソフトウェア開発プロセスで使用できる自動化ツールと一緒情報システムを開発する方法も指します。[11]「コンピューター支援ソフトウェアエンジニアリング」(CASE)という用語は、システムソフトウェアの自動開発に使用されるソフトウェアを指す場合があります。、すなわち、コンピュータコード。CASE機能には、分析、設計、およびプログラミングが含まれます。CASEツールは、目的のプログラミング言語で構造化されたコンピューターコードを設計、文書化、および生成するためのメソッドを自動化します[12]

コンピュータ支援ソフトウェアシステムエンジニアリング(CASE)の2つの重要なアイデアは次のとおりです。[13]

  • ソフトウェア開発およびソフトウェア保守プロセスにおけるコンピュータ支援を促進し
  • ソフトウェアの開発と保守に対するエンジニアリングアプローチ。

典型的なCASEツールは、構成管理データモデリングモデル変換リファクタリングソースコード生成のために存在します

統合開発環境

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

統合開発環境(IDE)としても知られている統合設計環境デバッグ環境の統合は、あるソフトウェア・アプリケーションへの包括的な機能を提供するコンピュータプログラマソフトウェア開発のために。IDEは通常、次のもので構成されます。

IDEは、同様のユーザーインターフェイスを備えた緊密なコンポーネントを提供することにより、プログラマーの生産性を最大化するように設計されています通常、IDEは特定のプログラミング言語専用であり、その言語のプログラミングパラダイム最も近い機能セットを提供します

モデリング言語

モデリング言語は任意であり、人工言語表現するために使用することができる情報又は知識又はシステムにおける構造ルールの一貫したセットによって定義されます。ルールは、構造内のコンポーネントの意味を解釈するために使用されます。モデリング言語は、グラフィックまたはテキストにすることができます。[14]グラフィカルモデリング言語はダイアグラム技術を使用しますシンボルを接続し、関係を表す概念と線を表す名前付きシンボルと、制約を表す他のさまざまなグラフィック注釈を使用します。テキストモデリング言語は通常、パラメータを伴う標準化されたキーワードを使用して、コンピュータで解釈可能な式を作成します。

ソフトウェアエンジニアリングの分野におけるグラフィカルモデリング言語の例は次のとおりです。

すべてのモデリング言語が実行可能であるとは限りません。実行可能である場合、それらを使用しても、必ずしもプログラマーが不要になるとは限りません。それどころか、実行可能なモデリング言語は、熟練したプログラマーの生産性を高めることを目的としているため、並列コンピューティング分散システムなどのより困難な問題に対処できます

プログラミングパラダイム

プログラミングパラダイムは、の基本的なスタイルであるコンピュータプログラミング一般(例えば、滝やアジャイルなど)プロジェクト管理方法論によって決定されていません、。パラダイムは、プログラムの要素(オブジェクト、関数、変数、制約など)を表すために使用される概念と抽象化、および計算を構成するステップ(割り当て、評価、継続、データフローなど)が異なります。パラダイムによって主張された概念は、高レベルのシステムアーキテクチャ設計で協力して利用されることがあります。その他の場合、プログラミングパラダイムの範囲は、特定のプログラムまたはモジュールの内部構造に限定されます。

プログラミング言語はサポートすることができ、複数のパラダイムを。たとえば、C ++またはObjectPascalで記述されたプログラムは、純粋に手続き型、または純粋にオブジェクト指向であるか、両方のパラダイムの要素を含むことができます。ソフトウェアの設計者とプログラマーは、これらのパラダイム要素の使用方法を決定します。では、オブジェクト指向プログラミングでいる間、プログラマは、オブジェクトの相互作用の集合としてプログラムを考えることができ、関数型プログラミングプログラムはステートレス関数評価のシーケンスとして考えることができます。多くのプロセッサを搭載したコンピュータまたはシステムをプログラミングする場合、プロセス指向プログラミングプログラマーは、アプリケーションを、論理的に共有されたデータ構造に作用する並行プロセスのセットとして考えることができます

ソフトウェアエンジニアリングのさまざまなグループがさまざまな方法論を提唱しているように、さまざまなプログラミング言語がさまざまなプログラミングパラダイムを提唱しています。一部の言語は1つのパラダイムをサポートするように設計されています(Smalltalkはオブジェクト指向プログラミングをサポートしHaskellは関数型プログラミングをサポートします)が、他のプログラミング言語は複数のパラダイムをサポートします(Object PascalC ++C#Visual BasicCommon LispSchemePythonRubyなど)、およびOz)。

多くのプログラミングパラダイムは、それらがどのような方法を禁止するか、そしてそれらが何を可能にするかについてもよく知られていますたとえば、純粋関数型プログラミングは副作用の使用を禁じています。構造化プログラミングではgotoステートメントの使用は禁止されています。部分的にこの理由のために、新しいパラダイムは、以前のスタイルに慣れている人々によって、しばしば教義主義者または過度に厳格であると見なされます。[要出典]特定の方法を回避すると、プログラムの正しさに関する定理を証明したり、単にプログラムの動作を理解したりするのが簡単になります。

高レベルのパラダイムの例は次のとおりです。

ソフトウェアの再利用

ソフトウェアの再利用の定義は、事前定義されたソフトウェアコンポーネントからソフトウェアを作成するプロセスです。ソフトウェア再利用アプローチは、ソフトウェア開発ライフサイクルにおける既存のソフトウェアアーティファクトの使用を増加または最大化することを目的としています
以下は、いくつかの一般的なソフトウェアの再利用方法です。

も参照してください

役割と業界

特定のアプリケーション

参考文献

  1. ^ 「アプリケーション開発(AppDev)の定義と説明」Bestpricecomputers.co.uk。2007-08-13 2012年8月5取得
  2. ^ DRMアソシエイツ(2002)。「新製品開発用語集」2006年1029日取得
  3. ^ Web対応E-ビジネスのシステム開発方法論:カスタマイズフレームワークLinda V. Knight(DePaul University、USA)、Theresa A. Steinbach(DePaul University、USA)、Vince Kellen(Blue Wolf、USA)
  4. ^ ジョセフM.モリス(2001)。ソフトウェア産業会計p.1.10
  5. ^ アランM.デイビス。Great Software Debates(2004年10月8日)、pp:125-128 Wiley-IEEE Computer Society Press
  6. ^ Ralph、P。、およびWand、Y。設計コンセプトの正式な定義の提案In、Lyytinen、K.、Loucopoulos、P.、 Mylopoulos、J.、and Robinson、W。、(eds。)、Design Requirements Engineering:A Ten-Year Perspective:Springer-Verlag、2009、pp.103-136
  7. ^ オテロ、カルロス。「ソフトウェア設計の課題」ITパフォーマンスの向上テイラーアンドフランシスLLC 2017年10月19日取得
  8. ^ Edward J. Barkmeyer ea(2003)。システム統合の自動化の概念NIST2003。
  9. ^ a b c d Paul R. Smith&Richard Sarfaty(1993)。Computer Aided Software Engineering(CASE)ツールを使用して構成管理の戦略的計画を作成します。1993年の全国DOE /請負業者および施設CAD / CAEユーザーグループのペーパー。
  10. ^ Kuhn、DL(1989)。「コンピュータ支援ソフトウェアエンジニアリングツールの選択と効果的な使用」。毎年恒例のウェスティングハウスコンピュータシンポジウム; 1989年11月6〜7日; ペンシルベニア州ピッツバーグ(米国); DOEプロジェクト。
  11. ^ P. Loucopoulos and V. Karakostas(1995)。システム要件エンジニアリングマグロウヒル。
  12. ^ CASE アーカイブで2012-02-18ウェイバックマシンで定義:テレコム用語集2000年 アーカイブで2005年11月22日ウェイバックマシン2008年10月26日取得。
  13. ^ K.ロビンソン(1992)。ソフトウェアエンジニアリングをCASEに入れるニューヨーク:John Wiley and Sons Inc.
  14. ^ 蕭何(2007)。グラフィカルモデリング言語の表記のためのメタモデル」。In: Computer Software and Applications Conference、2007年。COMPSAC2007–Vol。1. 31st Annual International、第1巻、第1号、2007年7月24〜27日、219〜224ページ。
  15. ^ Merx、Georges G。; ノーマン、ロナルドJ.(2006)。Javaを使用した統合ソフトウェアエンジニアリングPrentice-Hall、Inc.p。 201ISBN 0130473766

さらに読む

  • キット、エドワード(1992)。実世界でのソフトウェアテストアディソン-ウェスリープロフェッショナル。ISBN 0201877562
  • マッカーシー、ジム(1995)。ソフトウェア開発のダイナミクスMicrosoftPress。ISBN 1556158238
  • コンデ、ダン(2002)。ソフトウェア製品管理:アイデアから製品、マーケティング、販売までのソフトウェア開発の管理アスパトーレブックス。ISBN 1587622025
  • デイビス、AM(2005)。十分な要件管理:ソフトウェア開発とマーケティングが出会う場所ドーセットハウスパブリッシングカンパニー株式会社。ISBN 0932633641
  • ヘイステッド、エドワード(2005)。販売するソフトウェア:ソフトウェアプロジェクトを開発およびマーケティングするための実用的なガイドワイリー出版。ISBN 0764597833
  • ホーマン、ルーク(2003)。ソフトウェアアーキテクチャを超えて:勝利のソリューションの作成と維持アディソン-ウェスリープロフェッショナル。ISBN 0201775948
  • ジョンW.ホルヒ(2005)。「オブジェクトの操作方法に関する2つの方向性」。で:IEEEソフトウェア12、いいえ。2、pp。117–118、1995年3月。
  • リッティングハウス、ジョン(2003)。ソフトウェア成果物の管理:ソフトウェア開発管理方法論デジタルプレス。ISBN 155558313X
  • ウィーガーズ、カールE.(2005)。ソフトウェア要件の詳細:厄介な問題と実用的なアドバイスMicrosoftPress。ISBN 0735622671
  • Wysocki、Robert K.(2006)。効果的なソフトウェアプロジェクト管理ワイリー。ISBN 0764596365