ソフトウェア開発工程

ウィキペディア

ソフトウェア開発工程

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2023/09/09 20:17 UTC 版)

ソフトウェア開発工程（ソフトウェアかいはつこうてい、英: Software Development Process）はソフトウェアライフサイクルプロセスのうち、開発に関わるプロセスである。すなわち、ソフトウェアの構想から廃止までの流れのうち、開発部分をプロセスとして捉えたものである。ソフトウェア開発プロセスとも。

ウィキペディア小見出し辞書

ソフトウェア開発工程

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/02/22 21:52 UTC 版)

「ソフトウェアプロジェクト管理」の記事における「ソフトウェア開発工程」の解説

ソフトウェア開発工程は、主にソフトウェア開発における生産側の視点と関係している。これは、ソフトウェアツールのような技術側の視点とは対照的である。ソフトウェア開発工程は、主にソフトウェア開発の管理を支援するために存在するのであり、ビジネス上の関心事に取り組む方向性とは異なる。多くのソフトウェア開発工程群を、一般的なプロジェクト管理工程群と似た方法で遂行することができる。例を示す。 リスク管理は、リスクの測定やリスクアセスメントを行い、そのリスクを管理する戦略を構築する過程である。一般的には戦略として、他の人々にリスクを移管する、リスクを回避する、リスクの負の効果を低減する、特定のリスクのすべてもしくは一部分を受け入れる、などが採用される。ソフトウェアプロジェクト管理におけるリスク管理は、プロジェクトを開始するためのビジネスケースに始まる。プロジェクト開始時のリスク管理には、費用便益分析や危機管理計画 (コンティンジェンシープラン) として知られているプロジェクト失敗からの後退オプション群のリストが、含まれる。リスク管理のサブセットとして、「機会管理」が注目されつつある。機会管理は、潜在的リスクにはその結果として非建設的な影響よりもむしろ建設的な影響があるとすることを除くと、リスク管理と同じ意味である。リスク管理と同一の方法で理論に基づいてプロジェクトを制御するが、非建設的な用語である「リスク」よりも「機会」という用語を使うことにより、プロジェクトチームが、自分たちのプロジェクトのリスク登録簿から得られる蓋然的に建設的な結果に注目するのを支援する。建設的な結果とは、スピンオフプロジェクトや、意外な果実、自由に使える余剰資源などである。 要求管理は、要求を同定し、顧客から聞き出し、文書化し、分析し、追跡し、優先順位づけし、顧客と合意する過程であり、要求の変更を制御する過程であり、また利害関係者 (ステイクホルダ) とコミュニケーションする過程である。新しく構築するコンピュータシステムもしくは代替するコンピュータシステムの、要求分析工程を含む要求管理は、ソフトウェア開発では重要な作業である。実際には、ビジネスアナリストもしくはソフトウェア開発者が顧客のニーズや要求を同定する。彼らはこうして要求を同定し、そして解決方法 (ソリューション) を設計する。 変更管理は、プロジェクトのスコープに対する変更を同定し、文書化し、分析し、優先順位づけし、顧客と合意する過程であり、変更を制御する過程であり、また利害関係者とコミュニケーションする過程である。新しいスコープもしくは代替スコープの変更波及分析は、変更部分の要求分析を含む。変更波及分析は、ソフトウェア開発では重要な作業である。実際には、ビジネスアナリストもしくはソフトウェア開発者が顧客のニーズや要求を同定する。彼らはこうして要求を同定し、そして解決方法 (ソリューション) を再設計もしくは変更する。理論的には、個々の変更はソフトウェアプロジェクトの予定と経費に影響する。そのため当然に、変更に対してはその承認前に管理の一環としてリスク便益分析が行われる。 ソフトウェア構成管理は、プロジェクトのスコープそれ自身、すなわち現に存在するソフトウェア製品を同定し文書化する過程である。付随するすべての製品とすべての変更の管理も含まれる。それにより、製品と変更について利害関係者とのコミュニケーションができるようになる。一般的には、バージョン管理、命名規約の過程を含む。 リリース管理は、ソフトウェアのリリースについて同定し、文書化し、優先順位づけし、顧客と合意する過程であり、リリーススケジュールを制御する過程であり、リリースについて利害関係者とコミュニケーションする過程である。多くのソフトウェアプロジェクトでは、ソフトウェアをリリースするために、3つのソフトウェア環境を利用する。すなわち開発環境、テスト環境、および本稼働環境 (プロダクション環境) である。非常に大規模なプロジェクトでは、地理的に分散したチームが、利用者へリリースする前に、自分たちの成果物を統合する必要がある。単体テスト、システムテストおよび統合テストなどと呼ばれるテストのための環境が別途に用意され、そして利用者受け入れテスト向けにリリースされる。リリース管理のサブセットとして、データ管理が注目されつつある。利用者になじみのあるデータに基づくテストができるのは、明らかに利用者だけである。そして「現実の」データは本稼働環境 (プロダクション環境) と呼ばれる環境にのみ存在する。そのためプログラマたちが自分たちの成果物をテストするためには、多くの場合「ダミーデータ」や「データスタブ」を作る必要がある。慣習的に、この目的には以前のバージョンの本稼働環境のシステムが使われてきた。しかし企業がソフトウェア開発のための外部の協力者を信頼しすぎているとの理由から、本稼働環境のデータを開発チームに渡さないこともある。複合的な環境では、全体的なソフトウェアリリーススケジュールと同様に、テストリリーススケジュールにしたがってテスト環境間で移行されるデータが作られることがある。