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

提供: Internet Web School

(版間での差分)
(関連項目)
(アジャイル型(反復)開発)
 
(間の28版分が非表示)
1 行: 1 行:
-
[[File:Agile_cycle.png‎|right|frame|The new new product development game. http://hbr.org/1986/01/the-new-new-product-development-game/]]
 
-
 
[[インターネットと経営]]
[[インターネットと経営]]
> [[インターネットと経営/ソフトウェア開発工程|ソフトウェア開発工程]]
> [[インターネットと経営/ソフトウェア開発工程|ソフトウェア開発工程]]
8 行: 6 行:
[[wikipedia_ja:ソフトウェア開発工程|ソフトウェア開発工程(Software Development Process)]]とは,ソフトウェア製品の開発の構造を意味する.
[[wikipedia_ja:ソフトウェア開発工程|ソフトウェア開発工程(Software Development Process)]]とは,ソフトウェア製品の開発の構造を意味する.
[[wikipedia_ja:システム開発ライフサイクル|ソフトウェアライフサイクル]],ソフトウェア開発プロセス,ソフトウェアプロセスもほぼ同義語である.
[[wikipedia_ja:システム開発ライフサイクル|ソフトウェアライフサイクル]],ソフトウェア開発プロセス,ソフトウェアプロセスもほぼ同義語である.
-
開発工程にはいくつかのモデルがあり,開発工程内の各種タスク・活動のための手法を提案している <sup>[[wikipedia_ja:ソフトウェア開発工程|[w1]]] </sup>
+
 
 +
ソフトウェア開発プロセスの代表例としては,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:要求分析|ソフトウェア要求分析]] <sup>[[wikipedia_ja:ソフトウェア要求分析|[w2]]] </sup>
+
開発工程にはいくつかのモデルがあり,開発工程内の各種タスク・活動のための手法を提案している <sup>[[wikipedia_ja:ソフトウェア開発工程|[w1]]] </sup>
-
: ソフトウェア製品を作るにあたっての最初のタスクは要求を引き出す・集めることである。顧客はソフトウェアに何をさせたいのかを知っているものである。しかし、その要求は不完全だったり、曖昧だったり、互いに矛盾していたりする。経験をつんだソフトウェア技術者はそれを聞き出して一貫性のある要求仕様に纏め上げる。
+
-
[[wikipedia_ja:プログラム仕様|仕様記述]]
+
[[wikipedia_ja:要求分析|ソフトウェア要求分析]] <sup>[[wikipedia_ja:要求分析|[w2]]] </sup>
-
: 仕様記述は可能な限り厳密な方法で開発すべきソフトウェアを正確に記述するタスクである。安全性が重要なソフトウェアシステムでは、開発に先駆けて仕様記述を注意深く行うが、実際に最も成功している仕様記述とは、既存のアプリケーションを理解して改善するために書かれるものであろう。安定していなければならない外部インターフェイスにとって仕様記述は最も重要である。
+
: システム工学やソフトウェア工学において新たなシステムやシステム更新に際しての調査/定義に関わる工程を指す.要求分析はシステム設計工程でも重要な部分であり,アナリストやシステムエンジニア/ソフトウェア開発者が顧客の必要性や要求を特定する工程である.顧客の要求が特定されたら,システム設計者がその解決策を設計することになる.
-
[[wikipedia_ja:ソフトウェアアーキテクチャ|ソフトウェアアーキテクチャ]]
+
[[wikipedia_ja:プログラム仕様|仕様記述]] <sup>[[wikipedia_ja:プログラム仕様|[w3]]] </sup>
-
:ソフトウェアシステムのアーキテクチャとは、システムを抽象的に表現したものである。アーキテクチャはソフトウェアシステムが製品として要求に適合しているかを検証するのに使用される他、将来の追加要求に応えるためにも使用される。アーキテクチャ作成段階ではソフトウェアシステム間や他のソフトウェア製品間のインターフェイスも規定し、ハードウェアやオペレーティングシステムも規定する。
+
: プログラムに求められることを定義したものである.プログラムの設計図や開発者から見たユーザーマニュアルの元となる文書のような「非形式的」な形態の場合と,数学的に厳密に動作を定義する「形式的」な形態の場合がある.実際,最もよい仕様は既存のアプリケーションを理解して改善するために書かれたものであることが多いが,重要なソフトウェアは開発前に注意深く仕様を記述する必要がある.仕様は特に常に安定性が求められる外部インタフェースでは重要である.
-
[[wikipedia_ja:実装|実装]]
+
[[wikipedia_ja:ソフトウェアアーキテクチャ|ソフトウェアアーキテクチャ]] <sup>[[wikipedia_ja:ソフトウェアアーキテクチャ|[w4]]] </sup>
-
: 設計からコードを作成する段階はソフトウェア開発において最も明白な工程であるが、必ずしも最大の工程とは限らない。
+
:ソフトウェアコンポーネント,それらの外部特性,またそれらの相互関係から構成される.また,この用語はシステムのソフトウェアアーキテクチャの文書化を意味することもある.ソフトウェアアーキテクチャの文書は開発依頼主とのコミュニケーションを容易にするもので,概要レベルの設計に関する早期の決定を促し,プロジェクト間でのコンポーネントとパターンの設計を再利用することを可能にする.
-
[[wikipedia_ja:ソフトウェアテスト|評価]]
+
[[wikipedia_ja:実装|実装]] <sup>[[wikipedia_ja:実装|[w5]]] </sup>
-
: 特に複数の技術者が開発したコードを結合して行う評価はソフトウェア技術者が行う。
+
: 実装とは「ある構成要素を全体に対して取り付けること(組み立て)」もしくは「ある機能を実現するための構成要素を具体化すること(実現する作業)」を指す.ある機能を実際に動作する状態に持っていくための最終段の作業である.ソフトウェアの分野では,プログラムを作成する作業を実装(implement)と呼び,「ある関数を実装する/あるクラスを実装する」などという文で用いられる.設計からコードを作成する段階はソフトウェア開発において最も明白な工程である.
 +
 
 +
[[wikipedia_ja:ソフトウェアテスト|ソフトウェアテスト]] <sup>[[wikipedia_ja:ソフトウェアテスト|[w6]]] </sup>
 +
: コンピュータのプログラムを実行し,正しく動作するか,目標とした品質に到達しているか,意図しない動作をしないかどうかを確認する作業のことである.ソフトウェアテストは,プログラム中の仕様にない振舞又は欠陥(バグ)をできる限り多く発見することを目標する場合がある.欠陥を発見することを目標とする作業をデバッグという.目標とした品質には,規定した試験項目にすべて合格することもある.ソフトウェアテストに成功するとは,規定した試験項目にすべて合格するか,規定した品質目標に到達しているか,欠陥を発見することである.
[[wikipedia_ja:ソフトウェアドキュメンテーション|文書化]]
[[wikipedia_ja:ソフトウェアドキュメンテーション|文書化]]
-
: ソフトウェアの内部設計を文書化するタスクは重要だが、しばしば見過ごされている。これは将来の保守と改良に使用される。文書化は外部[[インターフェイス]]にとっては最も重要である。
+
: ソフトウェアの内部設計を文書化するタスクは重要だが,しばしば見過ごされている.これは将来の保守と改良に使用される.文書化は外部インターフェイスにとっては最も重要である.
トレーニングとサポート
トレーニングとサポート
-
: ソフトウェアプロジェクトの失敗の最大の要因は、そのソフトウェアを最終的に使用する人の育成を全く考えていないことにある。人々は不慣れな環境や領域に進むことには抵抗を示すものである。従って[[ソフトウェアデプロイメント|ソフトウェアを配備する段階]]では、実際にそのソフトウェアを使用する人を対象にトレーニングを行うことが重要である。また、実際に使ってみることでユーザーから問題点や疑問点が多数上げられてくる。それらが次のソフトウェアの開発への入力となる。
+
: ソフトウェアデプロイメントでは,実際にそのソフトウェアを使用する人を対象にトレーニングを行うことが重要である.また,実際に使ってみることでユーザーから問題点や疑問点が多数上げられてくる.それらが次のソフトウェアの開発への入力となる.
[[wikipedia_ja:ソフトウェア保守|保守]]
[[wikipedia_ja:ソフトウェア保守|保守]]
-
: ソフトウェアの保守と改良は初期の開発よりも長期に渡り、手間もかかる。本来の設計になじまないコードを追加しなければならなくなるだけでなく、既存のソフトウェアがどう動作しているのかを理解するだけでも多大な労力を必要とする。ソフトウェア開発の3分の2は保守作業であると言われているが、この統計は誤解を生みやすい。バグの修正は保守作業のほんの一部である。保守作業の大部分は既存のソフトウェアに新たな機能を組み込むことであり、それは別の新たな開発とみなされることが多い。同様に土木/建築でも保守作業が全体の3分の2を占めると言われている。
+
: ソフトウェア開発の3分の2は保守作業であると言われている.バグの修正は保守作業のほんの一部である.保守作業の大部分は既存のソフトウェアに新たな機能を組み込むことであり,それは別の新たな開発とみなされることが多い.
 +
 
 +
== ウォーターフォール型開発 ==
 +
 
 +
最もよく知られた従来型の開発工程モデルは,ウォーターフォール・モデルである(図2).このモデルでは,開発者は上述の工程(局面、フェーズ)を順番に行う.要求仕様を作成し,それを分析し,解決法を設計し,そのためのソフトウェアフレームワークのアーキテクチャを作り,コードを書き,評価し(単体テスト→システムテストの順),配備し,保守する.各工程が完了すると,次の工程に進むことができる
 +
<sup>[[wikipedia_ja:ウォーターフォール・モデル|[w7]]] </sup>.
 +
 
 +
[[File:SoftwareDevelopment_01_wf.png‎|center||図2. ウォーターフォール型開発]]
 +
<center>図2. ウォーターフォール型開発(『[http://www.nec-nis.co.jp/ja/column/01_agile.html アジャイル開発]』NEC情報システムズ より引用)</center>
 +
<br>
 +
 
 +
ウォーターフォール型開発の基本的な考え方は,『区切られた全ての工程が正しい』という前提で進めることである.
 +
この前提を守りながら進めるため,プロダクトはプロジェクト立ち上げ当初作成した要求仕様を忠実に実装し,その仕様を全て満たした時点で開発完了となる.
 +
当初の要求仕様通りに進むという特徴から,契約時に契約内容・責任範囲が明確となるメリットがある.
 +
一方,要求仕様作成時に要求ミス・漏れがあった場合や,開発途中で要求に変更があった場合,別途仕様変更として追加費用や開発期間が発生する可能性がある <sup>[[#参考文献|[r1]]]</sup> .
 +
 
 +
== アジャイル型(反復)開発 ==
 +
 
 +
反復型開発は,ソフトウェアを徐々に開発していく手法であり,問題点や前提の間違いを早期に検出して大きな問題となるのを防ぐ.
 +
反復型開発はパッケージでない商用ソフトウェア開発で好まれる.
 +
何故なら,自分がソフトウェアに何を求めているかをうまく定義できない顧客の要求にも,段階的に応えて開発していくことが可能だからである.
 +
 
 +
アジャイルソフトウェア開発は反復型開発からの派生手法である.
 +
アジャイルとは『すばやい』『俊敏な』という意味で,イテレーションが短い開発期間単位を採用することで,リスクを最小化しようとする開発手法の一つである.アジャイル型開発手法にはいろいろなバリエーションがあるが,例えば次のような進め方で開発を進める(図3).
 +
 
 +
#顧客とエンジニアが少数精鋭の共同開発チームを作る
 +
#開発チームは開発範囲全体をいくつもの短い範囲,おおむね2週間程度でできると思われる範囲に区分する
 +
#業務プロセスの優先度を考慮し,どの範囲から着手するかを決定する
 +
#開発チームは2週間内に,その範囲の要求の決定、実装、テスト、修正、リリースを行う
 +
#リリースできた機能や残っている業務プロセスの範囲を検討し,次に着手する優先すべき区分を決める
 +
 
 +
[[File:SoftwareDevelopment_01_ag.png‎|center||図3. アジャイル型開発]]
 +
<center>図3. アジャイル型開発(『[http://www.nec-nis.co.jp/ja/column/01_agile.html アジャイル開発]』NEC情報システムズ より引用)</center>
 +
<br>
-
== sectionタイトル ==
+
アジャイルでは,従来よりも軽量で人間中心の視点を導入した.
-
=== subsectionタイトル ===
+
アジャイルでは計画よりもフィードバックを重視する.
-
=== subsectionタイトル ===
+
フィードバックは主にテスト(評価)と開発途中のソフトウェアを外部にリリースすることで得られる
 +
<sup>[[wikipedia_ja:アジャイルソフトウェア開発|[w8]]] </sup>.
-
== sectionタイトル ==
+
アジャイルソフトウェア開発は従来の方法論よりも効率的と思われる.
-
=== subsectionタイトル ===
+
少ない工数でより多くの機能を開発でき,品質の高いソフトウェアを開発できる.
-
=== subsectionタイトル ===
+
しかしビジネス的観点から見ると長期的計画を立てるのが困難であるという問題がある.
 +
基本的に,顧客が必要な機能は開発されるが,それが何時になるのかは不明である.
== 参考文献 ==
== 参考文献 ==
54 行: 93 行:
*[w1] [[wikipedia_ja:ソフトウェア開発工程|ソフトウェア開発工程 (Wikipedia)]]
*[w1] [[wikipedia_ja:ソフトウェア開発工程|ソフトウェア開発工程 (Wikipedia)]]
*[w2] [[wikipedia_ja:要求分析|ソフトウェア要求分析 (Wikipedia)]]
*[w2] [[wikipedia_ja:要求分析|ソフトウェア要求分析 (Wikipedia)]]
-
*[[wikipedia_ja:仕様記述|仕様記述 (Wikipedia)]]
+
*[w3] [[wikipedia_ja:仕様記述|仕様記述 (Wikipedia)]]
-
*[[wikipedia_ja:ソフトウェアアーキテクチャ|ソフトウェアアーキテクチャ (Wikipedia)]]
+
*[w4] [[wikipedia_ja:ソフトウェアアーキテクチャ|ソフトウェアアーキテクチャ (Wikipedia)]]
-
*[[wikipedia_ja:実装|実装 (Wikipedia)]]
+
*[w5] [[wikipedia_ja:実装|実装 (Wikipedia)]]
-
*[[wikipedia_ja:アジャイルソフトウェア開発|アジャイルソフトウェア開発 (Wikipedia)]]
+
*[w6] [[wikipedia_ja:ソフトウェアテスト|ソフトウェアテスト (Wikipedia)]]
-
*[[wikipedia_ja:ウォーターフォール・モデル|ウォーターフォール・モデル (Wikipedia)]]
+
*[w7] [[wikipedia_ja:ウォーターフォール・モデル|ウォーターフォール・モデル (Wikipedia)]]
 +
*[w8] [[wikipedia_ja:アジャイルソフトウェア開発|アジャイルソフトウェア開発 (Wikipedia)]]
== 演習課題 ==
== 演習課題 ==
*<span class="pops"> [[cai_ja:GRAINN00030001|CAIテストのページへ(新しいWindowが開きます)]] </span>
*<span class="pops"> [[cai_ja:GRAINN00030001|CAIテストのページへ(新しいWindowが開きます)]] </span>

2015年5月25日 (月) 10:58 時点における最新版

インターネットと経営 > ソフトウェア開発工程

目次

概要

ソフトウェア開発工程(Software Development Process)とは,ソフトウェア製品の開発の構造を意味する. ソフトウェアライフサイクル,ソフトウェア開発プロセス,ソフトウェアプロセスもほぼ同義語である.

ソフトウェア開発プロセスの代表例としては,Vモデル(V-Model)がある.これはIT製品開発の手法の一種で,また一般に利用可能であるため,様々な企業でも使われている(図1).

図1. Software V-Model
図1. Software V-Model(『Das V-Modell XT』より引用)

開発工程

開発工程にはいくつかのモデルがあり,開発工程内の各種タスク・活動のための手法を提案している [w1]

ソフトウェア要求分析 [w2]

システム工学やソフトウェア工学において新たなシステムやシステム更新に際しての調査/定義に関わる工程を指す.要求分析はシステム設計工程でも重要な部分であり,アナリストやシステムエンジニア/ソフトウェア開発者が顧客の必要性や要求を特定する工程である.顧客の要求が特定されたら,システム設計者がその解決策を設計することになる.

仕様記述 [w3]

プログラムに求められることを定義したものである.プログラムの設計図や開発者から見たユーザーマニュアルの元となる文書のような「非形式的」な形態の場合と,数学的に厳密に動作を定義する「形式的」な形態の場合がある.実際,最もよい仕様は既存のアプリケーションを理解して改善するために書かれたものであることが多いが,重要なソフトウェアは開発前に注意深く仕様を記述する必要がある.仕様は特に常に安定性が求められる外部インタフェースでは重要である.

ソフトウェアアーキテクチャ [w4]

ソフトウェアコンポーネント,それらの外部特性,またそれらの相互関係から構成される.また,この用語はシステムのソフトウェアアーキテクチャの文書化を意味することもある.ソフトウェアアーキテクチャの文書は開発依頼主とのコミュニケーションを容易にするもので,概要レベルの設計に関する早期の決定を促し,プロジェクト間でのコンポーネントとパターンの設計を再利用することを可能にする.

実装 [w5]

実装とは「ある構成要素を全体に対して取り付けること(組み立て)」もしくは「ある機能を実現するための構成要素を具体化すること(実現する作業)」を指す.ある機能を実際に動作する状態に持っていくための最終段の作業である.ソフトウェアの分野では,プログラムを作成する作業を実装(implement)と呼び,「ある関数を実装する/あるクラスを実装する」などという文で用いられる.設計からコードを作成する段階はソフトウェア開発において最も明白な工程である.

ソフトウェアテスト [w6]

コンピュータのプログラムを実行し,正しく動作するか,目標とした品質に到達しているか,意図しない動作をしないかどうかを確認する作業のことである.ソフトウェアテストは,プログラム中の仕様にない振舞又は欠陥(バグ)をできる限り多く発見することを目標する場合がある.欠陥を発見することを目標とする作業をデバッグという.目標とした品質には,規定した試験項目にすべて合格することもある.ソフトウェアテストに成功するとは,規定した試験項目にすべて合格するか,規定した品質目標に到達しているか,欠陥を発見することである.

文書化

ソフトウェアの内部設計を文書化するタスクは重要だが,しばしば見過ごされている.これは将来の保守と改良に使用される.文書化は外部インターフェイスにとっては最も重要である.

トレーニングとサポート

ソフトウェアデプロイメントでは,実際にそのソフトウェアを使用する人を対象にトレーニングを行うことが重要である.また,実際に使ってみることでユーザーから問題点や疑問点が多数上げられてくる.それらが次のソフトウェアの開発への入力となる.

保守

ソフトウェア開発の3分の2は保守作業であると言われている.バグの修正は保守作業のほんの一部である.保守作業の大部分は既存のソフトウェアに新たな機能を組み込むことであり,それは別の新たな開発とみなされることが多い.

ウォーターフォール型開発

最もよく知られた従来型の開発工程モデルは,ウォーターフォール・モデルである(図2).このモデルでは,開発者は上述の工程(局面、フェーズ)を順番に行う.要求仕様を作成し,それを分析し,解決法を設計し,そのためのソフトウェアフレームワークのアーキテクチャを作り,コードを書き,評価し(単体テスト→システムテストの順),配備し,保守する.各工程が完了すると,次の工程に進むことができる [w7]

図2. ウォーターフォール型開発
図2. ウォーターフォール型開発(『アジャイル開発』NEC情報システムズ より引用)


ウォーターフォール型開発の基本的な考え方は,『区切られた全ての工程が正しい』という前提で進めることである. この前提を守りながら進めるため,プロダクトはプロジェクト立ち上げ当初作成した要求仕様を忠実に実装し,その仕様を全て満たした時点で開発完了となる. 当初の要求仕様通りに進むという特徴から,契約時に契約内容・責任範囲が明確となるメリットがある. 一方,要求仕様作成時に要求ミス・漏れがあった場合や,開発途中で要求に変更があった場合,別途仕様変更として追加費用や開発期間が発生する可能性がある [r1]

アジャイル型(反復)開発

反復型開発は,ソフトウェアを徐々に開発していく手法であり,問題点や前提の間違いを早期に検出して大きな問題となるのを防ぐ. 反復型開発はパッケージでない商用ソフトウェア開発で好まれる. 何故なら,自分がソフトウェアに何を求めているかをうまく定義できない顧客の要求にも,段階的に応えて開発していくことが可能だからである.

アジャイルソフトウェア開発は反復型開発からの派生手法である. アジャイルとは『すばやい』『俊敏な』という意味で,イテレーションが短い開発期間単位を採用することで,リスクを最小化しようとする開発手法の一つである.アジャイル型開発手法にはいろいろなバリエーションがあるが,例えば次のような進め方で開発を進める(図3).

  1. 顧客とエンジニアが少数精鋭の共同開発チームを作る
  2. 開発チームは開発範囲全体をいくつもの短い範囲,おおむね2週間程度でできると思われる範囲に区分する
  3. 業務プロセスの優先度を考慮し,どの範囲から着手するかを決定する
  4. 開発チームは2週間内に,その範囲の要求の決定、実装、テスト、修正、リリースを行う
  5. リリースできた機能や残っている業務プロセスの範囲を検討し,次に着手する優先すべき区分を決める
図3. アジャイル型開発
図3. アジャイル型開発(『アジャイル開発』NEC情報システムズ より引用)


アジャイルでは,従来よりも軽量で人間中心の視点を導入した. アジャイルでは計画よりもフィードバックを重視する. フィードバックは主にテスト(評価)と開発途中のソフトウェアを外部にリリースすることで得られる [w8]

アジャイルソフトウェア開発は従来の方法論よりも効率的と思われる. 少ない工数でより多くの機能を開発でき,品質の高いソフトウェアを開発できる. しかしビジネス的観点から見ると長期的計画を立てるのが困難であるという問題がある. 基本的に,顧客が必要な機能は開発されるが,それが何時になるのかは不明である.

参考文献

関連項目

演習課題

個人用ツール