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

提供: Internet Web School

移動: ナビゲーション, 検索

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

概要

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

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

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

開発工程

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

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

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

仕様記述 ^[w3]

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

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

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

実装 ^[w5]

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

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

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

文書化

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

トレーニングとサポート

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

保守

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

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

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

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

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

アジャイル型（反復）開発

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

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

顧客とエンジニアが少数精鋭の共同開発チームを作る
開発チームは開発範囲全体をいくつもの短い範囲，おおむね２週間程度でできると思われる範囲に区分する
業務プロセスの優先度を考慮し，どの範囲から着手するかを決定する
開発チームは２週間内に，その範囲の要求の決定、実装、テスト、修正、リリースを行う
リリースできた機能や残っている業務プロセスの範囲を検討し，次に着手する優先すべき区分を決める

図3. アジャイル型開発（『アジャイル開発』NEC情報システムズより引用）

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

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

参考文献

[r1] 『アジャイル開発』NEC情報システムズ.
[r2] Ken Schwaber, Jeff Sutherland : Scrum.
[r3] The new new product development game.

演習課題

CAIテストのページへ（新しいWindowが開きます）