ソースを表示

提供: Internet Web School

以下に示された理由により、このページの編集を行うことができません:

このページのソースを閲覧し、コピーすることができます:

[[インターネットと経営]] > [[インターネットと経営/ソフトウェア開発工程|ソフトウェア開発工程]] == 概要 == [[wikipedia_ja:ソフトウェア開発工程|ソフトウェア開発工程（Software Development Process）]]とは，ソフトウェア製品の開発の構造を意味する． [[wikipedia_ja:システム開発ライフサイクル|ソフトウェアライフサイクル]]，ソフトウェア開発プロセス，ソフトウェアプロセスもほぼ同義語である． ソフトウェア開発プロセスの代表例としては，Vモデル（V-Model）がある．これはIT製品開発の手法の一種で，また一般に利用可能であるため，様々な企業でも使われている（図1）． [[File:Iec61508_overview_software_Vmodel_small.png‎|center||図1. Software V-Model]] <center>図1. Software V-Model（『[http://www.v-modell-xt.de/ Das V-Modell XT]』より引用）</center> ==開発工程== 開発工程にはいくつかのモデルがあり，開発工程内の各種タスク・活動のための手法を提案している ^{[[wikipedia_ja:ソフトウェア開発工程|[w1]]]}． [[wikipedia_ja:要求分析|ソフトウェア要求分析]] ^{[[wikipedia_ja:要求分析|[w2]]]} : システム工学やソフトウェア工学において新たなシステムやシステム更新に際しての調査/定義に関わる工程を指す．要求分析はシステム設計工程でも重要な部分であり，アナリストやシステムエンジニア/ソフトウェア開発者が顧客の必要性や要求を特定する工程である．顧客の要求が特定されたら，システム設計者がその解決策を設計することになる． [[wikipedia_ja:プログラム仕様|仕様記述]] ^{[[wikipedia_ja:プログラム仕様|[w3]]]} : プログラムに求められることを定義したものである．プログラムの設計図や開発者から見たユーザーマニュアルの元となる文書のような「非形式的」な形態の場合と，数学的に厳密に動作を定義する「形式的」な形態の場合がある．実際，最もよい仕様は既存のアプリケーションを理解して改善するために書かれたものであることが多いが，重要なソフトウェアは開発前に注意深く仕様を記述する必要がある．仕様は特に常に安定性が求められる外部インタフェースでは重要である． [[wikipedia_ja:ソフトウェアアーキテクチャ|ソフトウェアアーキテクチャ]] ^{[[wikipedia_ja:ソフトウェアアーキテクチャ|[w4]]]} :ソフトウェアコンポーネント，それらの外部特性，またそれらの相互関係から構成される．また，この用語はシステムのソフトウェアアーキテクチャの文書化を意味することもある．ソフトウェアアーキテクチャの文書は開発依頼主とのコミュニケーションを容易にするもので，概要レベルの設計に関する早期の決定を促し，プロジェクト間でのコンポーネントとパターンの設計を再利用することを可能にする． [[wikipedia_ja:実装|実装]] ^{[[wikipedia_ja:実装|[w5]]]} : 実装とは「ある構成要素を全体に対して取り付けること（組み立て）」もしくは「ある機能を実現するための構成要素を具体化すること（実現する作業）」を指す．ある機能を実際に動作する状態に持っていくための最終段の作業である．ソフトウェアの分野では，プログラムを作成する作業を実装（implement）と呼び，「ある関数を実装する/あるクラスを実装する」などという文で用いられる．設計からコードを作成する段階はソフトウェア開発において最も明白な工程である． [[wikipedia_ja:ソフトウェアテスト|ソフトウェアテスト]] ^{[[wikipedia_ja:ソフトウェアテスト|[w6]]]} : コンピュータのプログラムを実行し，正しく動作するか，目標とした品質に到達しているか，意図しない動作をしないかどうかを確認する作業のことである．ソフトウェアテストは，プログラム中の仕様にない振舞又は欠陥（バグ）をできる限り多く発見することを目標する場合がある．欠陥を発見することを目標とする作業をデバッグという．目標とした品質には，規定した試験項目にすべて合格することもある．ソフトウェアテストに成功するとは，規定した試験項目にすべて合格するか，規定した品質目標に到達しているか，欠陥を発見することである． [[wikipedia_ja:ソフトウェアドキュメンテーション|文書化]] : ソフトウェアの内部設計を文書化するタスクは重要だが，しばしば見過ごされている．これは将来の保守と改良に使用される．文書化は外部インターフェイスにとっては最も重要である． トレーニングとサポート : ソフトウェアデプロイメントでは，実際にそのソフトウェアを使用する人を対象にトレーニングを行うことが重要である．また，実際に使ってみることでユーザーから問題点や疑問点が多数上げられてくる．それらが次のソフトウェアの開発への入力となる． [[wikipedia_ja:ソフトウェア保守|保守]] : ソフトウェア開発の3分の2は保守作業であると言われている．バグの修正は保守作業のほんの一部である．保守作業の大部分は既存のソフトウェアに新たな機能を組み込むことであり，それは別の新たな開発とみなされることが多い． == ウォーターフォール型開発工程 == 最もよく知られた従来型の開発工程モデルは，ウォーターフォール・モデルである（図2）．このモデルでは，開発者は上述の工程（局面、フェーズ）を順番に行う．要求仕様を作成し，それを分析し，解決法を設計し，そのためのソフトウェアフレームワークのアーキテクチャを作り，コードを書き，評価し（単体テスト→システムテストの順），配備し，保守する．各工程が完了すると，次の工程に進むことができる ^{[[wikipedia_ja:ウォーターフォール・モデル|[w7]]]}． [[File:SoftwareDevelopment_01_wf.png‎|center||図2. ウォーターフォール型開発]] <center>図2. ウォーターフォール型開発（『[http://www.nec-nis.co.jp/ja/column/01_agile.html アジャイル開発]』NEC情報システムズ より引用）</center> ウォーターフォール型開発の基本的な考え方は，『区切られた全ての工程が正しい』という前提で進めることである． この前提を守りながら進めるため，プロダクトはプロジェクト立ち上げ当初作成した要求仕様を忠実に実装し，その仕様を全て満たした時点で開発完了となる． 当初の要求仕様通りに進むという特徴から，契約時に契約内容・責任範囲が明確となるメリットがある． 一方，要求仕様作成時に要求ミス・漏れがあった場合や，開発途中で要求に変更があった場合，別途仕様変更として追加費用や開発期間が発生する可能性がある ^{[[#参考文献|[r1]]]} ． == アジャイル型開発工程 == === subsectionタイトル === === subsectionタイトル === == 参考文献 == *[r1] 『[http://www.nec-nis.co.jp/ja/column/01_agile.html アジャイル開発]』NEC情報システムズ. *[r2] Ken Schwaber, Jeff Sutherland : [https://www.scrum.org/scrum-guide/ Scrum]. *[r3] [http://hbr.org/1986/01/the-new-new-product-development-game/ The new new product development game]. == 関連項目 == *[w1] [[wikipedia_ja:ソフトウェア開発工程|ソフトウェア開発工程 (Wikipedia)]] *[w2] [[wikipedia_ja:要求分析|ソフトウェア要求分析 (Wikipedia)]] *[w3] [[wikipedia_ja:仕様記述|仕様記述 (Wikipedia)]] *[w4] [[wikipedia_ja:ソフトウェアアーキテクチャ|ソフトウェアアーキテクチャ (Wikipedia)]] *[w5] [[wikipedia_ja:実装|実装 (Wikipedia)]] *[w6] [[wikipedia_ja:ソフトウェアテスト|ソフトウェアテスト (Wikipedia)]] *[w7] [[wikipedia_ja:ウォーターフォール・モデル|ウォーターフォール・モデル (Wikipedia)]] *[w8] [[wikipedia_ja:アジャイルソフトウェア開発|アジャイルソフトウェア開発 (Wikipedia)]] == 演習課題 == *<span class="pops"> [[cai_ja:GRAINN00030001|CAIテストのページへ（新しいWindowが開きます）]] </span>

インターネットと経営/ソフトウェア開発工程 に戻る。