2005年度前期 IT教育基礎論特論B
ソフトウェアの開発におけるソフトウェア工学の役割を理解するとともに、 ソフトウェア工学において提案されている、 各種プロセスモデルに基づくソフトウェアの設計と開発の手順の概要を学習する。
ソフトウェア工学とは、ソフトウェアを効率的に 設計、開発するための手法に関する学問、 もしくはそのための技術のことをいう。
コンピュータの発達、普及にともない、 これを利用するためのソフトウェアも、より複雑で大規模なものとなり、 技術者が不足するようになってきた。 このため、図1に示すように、 ハードウェアは、大量生産と技術開発によりコストが下がった反面、 ソフトウェアの開発コストは年々増大し、1960年代の後半には、 ハードウェア開発にかかるコストと、 ソフトウェア開発にかかるコストが反転したと言われている。 さらにこのころには、生産されたソフトウェアの品質に対する 発注者からのクレームと、 発注者による要求のあいまい性に対する生産者の主張との衝突が 表面化することとなる。 これをソフトウェア危機(software crisis)と呼ぶ。
このような背景のもと、 品質の高いソフトウェアを効率的に開発する手法が重要視されることとなり、 ソフトウェア工学(software engineering)という言葉がはじめて使用されたのは、 1968年にNATOの技術委員会の主催でドイツで開催された 「ソフトウェア工学会議」が最初であると言われている。
ソフトウェア工学の主な役割は以下の項目である。
- 開発効率、生産性の向上
- ソフトウェアが発注されてから いかに効率よく短期間でソフトウェアを完成できるようにするか。
- 品質の向上
- ソフトウェアの発注者の要求を満たし、かつ不具合(バグ)のない信頼性の高い ソフトウェアを開発するか。
- プログラミングの簡単化
- プログラマの負担を軽減し、また、 特別な技術を必要とせず熟練プログラマではないプログラマにも プログラムの開発を可能とするにはどうするか。
このような目的を実現するために、 ソフトウェア工学では、以下のような技術や手法について議論されている。
- 開発過程の形式化
- 開発プロセスを各段階に分割し、各段階毎に行う作業を明確化することにより、 開発の分業、誤りの検証、部分的な自動化を促進する。
- 再利用性の向上
- 新規に全てのプログラムを作成することは困難であるため、 プログラムのモジュール化(機能毎にプログラムを部品化)し、 APIの規格化を行うことにより、プログラムの再利用性を向上する。 また、ドキュメントの作成、モジュールのデータベース化により、 再利用を促進する。
- 開発支援環境の開発
- エキスパートシステム、グループウェア、ビジュアルプログラミング、 ミドルウェア等により、 特別な専門知識を有しない開発者でも比較容易にソフトウェアの開発を 行える開発環境を開発する。
ソフトウェアを開発するということは、単にプログラムを記述することだけではない。 何らかのソフトウェアを開発するためには、 どのようなソフトウェアを開発するかを企画することから始め、 また完成したソフトウェアをどのように運用していくかを考える必要がある。
ソフトウェアの企画から運用までの一連の流れを ソフトウェアのライフサイクルと呼び、 また、このソフトウェアのライフサイクルは、 一般に、図2のように大きく5段階に分けることができる。
- 仕様定義
- 仕様定義は、さらに以下の2つの段階に分けられ、 開発するソフトウェアに要求される仕様を明らかにする。
- システム要求定義(要求分析)
- 開発しようとするソフトウェアを利用することにより何ができればよいか、 そのソフトウェアにより実現されるシステムに対する 利用者の要求を分析する。
- ソフトウェア要求定義(仕様作成)
- 利用者の要求に基づき、 そのソフトウェアにより提供される機能を明らかにする。
- 設計
- 設計では、仕様定義で明らかにされた仕様に基づき、 以下の2つの段階により、具体的なソフトウェアの設計を明らかにする。
- 外部設計(基本設計)
- 外部設計では、システム形態、ユーザインタフェース、利用方法等、 ソフトウェアで実現されるシステムの全体像の設計を行なう。
- 内部設計(詳細設計)
- 内部設計では、外部設計に基づき、 システムを構成する個々のサブシステムのアーキテクチャ(モジュール構成)、 各モジュールのAPI、プロセス間通信プロトコル、 およびデータ構造やアルゴリズムなどの設計を行なう。
- プログラミング(コーディング)
- 設計に基づき、実際のプログラムの記述を行ない、ソフトウェアを実装する。
- 試験(テスト)
- 実装されたソフトウェアが、設計や仕様通り正しく動作するかをテストし、 不具合等の発見を行なう。
- 運用・保守
- 完成したソフトウェアを現場に導入し、運用するとともに、 試験において発見できなかった未知の不具合の発見、 利用者からの新たな要求の分析を行なう。
ソフトウェアのライフサイクルは、 一見すると、仕様定義から運用保守までの一連の流れのようにも見えるが、 これはあくまでソフトウェア開発における各段階の概要を示したものであり、 必ずしも上から下まで順番に進むとは限らない。 例えば、プログラミングにおいて設計の間違いが発見され、 実装ができないことが判明した場合には、 その間違いが設計上の間違いなのか、 それとも仕様に起因する間違いなのかを分析し、 それぞれの段階に戻って再設計もしくは仕様の再定義を行なうこととなる。
このようにソフトウェア開発では、 一般に各段階を繰り返し、開発を進めていくこととなる。 そこで、品質の高いソフトウェアを効率よく開発するために、 ソフトウェアのライフサイクルに基づき、 各段階をどのように進めていくと良いかをモデル化したものが、 ソフトウェア開発のプロセスモデルである。 例えば、図3に示すウォータフォールモデルでは、 ソフトウェアのライフサイクルの各段階において、 その段階での作業が終了すると次の段階に進み、 逆に、その段階で何かしらの不具合が発見された場合には、 前段階に戻るという工程をとる。
ソフトウェア開発のプロセスモデルでは、 開発対象となるソフトウェアの種類や規模、 その開発グループの形態の違いなどにより、 多数のモデルが提案されており、 その代表的なモデルとして以下のようなものがある。
ソフトウェア開発のプロセスモデルとして提案されている、 ウォータフォールモデル、成長モデル、プロトタイプモデル、 スパイラルモデルの各モデルについて調べ、概要をまとめるとともに、 どのような利点、欠点があり、どのようなソフトウェア開発に適しているかなど、 特徴を述べよ。
近年注目されているソフトウェアの開発手法として、 エクストリーミングプログラミング(XP)がある。 XPは、開発手順だけでなく、 使用する開発環境や開発者の協力体制など、 開発手法全体を総合的に提案しているものであるが、 ソフトウェア開発のプロセスモデルの観点からXPを見た場合に どのようなモデルとなっているか、 そのモデル名を挙げ、考察せよ。