ソフトウェア工学

プロセスモデル

最終更新日:2006.10.19 - 渕田孝康

ソフトウェアのライフサイクル

一般に、ソフトウェアには次のようなサイクルがあるといわれる。

PM-図1

ソフトウェアの開発には時間がかかるものであり、以前のソフトを改良しつつ使いまわすケースが多い。要求が発生してからソフトウェアが作成され、何年かに渡って修正や改良を繰り返し、最後に廃棄されるまでの過程をソフトウェアのライフサイクルと呼ぶ。

ライフサイクルの各工程について簡単に述べる。

要求分析
発注者(顧客)がそのソフトウェアを使って行いたいこと(業務)を明確にし、ソフトウェアが満たすべき機能を決定する。
システム設計
要求をどのようにして機能として実現するかを決定する。この段階で利用者とシステムの情報交換の方法(ユーザーインターフェイス)を決定することが多い。
プログラム設計
機能をどのようにプログラムで実現するかを決定する。複雑なソフトウェアでは複数のプログラムが同時に協調して動作する必要がある。
コーディング
設計にしたがって高級言語でプログラムを作成し、コンパイルする。マニュアル等もこのとき同時に作成する。
テスト
顧客が意図したとおりのプログラムが作成されたか、およびプログラムが意図したとおり動作するかを検査する。単体でのテストの他に、他のプログラムと組み合わせたときのテスト(統合テスト)を行う場合もある。
保守
運用中に発見された不具合の修正や、機能・性能・使いやすさの向上などを目的としたシステムの改良を行う。変更が軽微な場合はプログラム設計に戻る程度でよいが、大規模な変更の場合はシステム設計からやり直しになる。その場合、別なプロジェクトとして最初から立ち上げることが多い。保守に耐えられなくなったとき、ソフトウェアは廃棄される。

ウォーターフォールモデル

ソフトウェアの開発プロセスのモデルとして最初に提案されたものがウォーターフォールモデルである(1970年代)。このモデルは、下の図に示すように、滝から水が落ちるように工程が上から下へと実行されることが特徴である。各工程において、次の工程へ渡すために生成される成果物をプロダクトと呼ぶ。

PM-図2

上の例では、要求分析の結果として仕様書が生成され、その仕様書を基にしてシステム設計が行われ、その結果として基本仕様書が生成される。さらに、基本仕様書を基にしてプログラム設計が行われ、結果として詳細仕様書が生成される。

このように、各工程での作業の結果としてのプロダクトを残していくことによって、プロジェクトの開発履歴が明文化された形で残ることになり、下工程のテストや保守が容易になる。

ウォーターフォールモデルでは、1つの工程を完了しない限り、次の工程へ進むことはできない。各工程には、生成されたプロダクトを検査する方法と、各工程をいつまでに完了するかの計画(マイルストーン)が付随する。

このモデルは非常に分かりやすいモデルであるが、さまざまなプロジェクトに応用されていくにつれて、実際のソフトウェア開発の手順とは一致しないことが明らかになってきた。特に下流工程においては、たとえばプログラムが完成するまでテストは行われない、などといったことは、実際の開発現場ではありえない。実際の現場では、少し開発してはテストして、それを踏み台にしてさらに開発を進めるといった形態がとられる場合が多い。

また、実際のソフトウェア開発においては、さまざまな箇所で繰り返しが発生するが、ウォーターフォールモデルでは複数の工程にまたがった繰り返しを記述できない。たとえば、開発工程が進んでいき、コーディング段階になって要求分析に不十分な点が発見されたとしたら、それまでに得られたプロダクト(仕様書、基本設計書、詳細設計書)をすべて破棄してから要求分析をやり直し、再度すべてのプロダクトを作り直さなければならない。現実にこのような開発を行うことは効率が悪すぎる。

このようなウォーターフォールモデルの問題点は、システム全体に対する分析や設計を一括して行うところに原因がある。すなわち、最初にシステム全体を見通して問題領域を分析し、それが完成してから全体を設計するというやり方は、ソフトウェアの開発には向かないのである。

スパイラルモデル

このようなウォーターフォールモデルの欠点を補い、繰り返し処理を含んだプロセスを表現可能としたモデルが、1988年に Boehm によって提案されたスパイラルモデルである。

スパイラルモデルでは、最初から複雑な要求を全部満たすソフトウェアを作成することはしない。まず全体の要求を分析し、より本質的なもの、あるいは単純で実現が容易なもののみに限定した要求のみを抽出する。そしてこれに対する仕様書1を作成し、この仕様書に基づいて設計・コーディングの工程へと進む。

PM-図3

工程によって生成されるプロダクトも、システム全体の要求を完全に満たすものではなく、大まかな動作や事象の流れを把握するためのもの(プロトタイプ)となる。プロトタイプにおいては、システムの機能は完全には動作しない。たとえば、インベーダゲームのプロトタイプで、自分の宇宙船の動作を目的としていた場合、敵のインベーダは現れないかもしれない。宇宙船が完全に正しく動作することを確認した後、次はインベーダを動かすための工程に入ることになる。

スパイラルモデルは、小さいプロジェクトから初めて、分析・設計・コーディング・テストを繰り返しつつ、少しずつシステム構築していく方法であり、現実のソフトウェア開発プロセスに合った、非常に有効な工程管理手法である。実際、多くのソフトウェアはこのようなプロセスを経て開発されていると思われる。

しかし、このモデルは、ソフトウェア開発者にとっては、たいへん効率よく開発を進めることができるわかりやすいモデルを提供したが、開発全体を管理する管理者にとっては、徐々に構築されていくソフトウェアシステムが本当に正しく(要求を満たして)作られているのかを把握しにくい、という問題があった。すなわち、システム開発全体に対してのリスクを管理しにくいという点が、スパイラルモデルの問題点として指摘されていた。

統一プロセス(United Process:UP)

Booch によると、失敗するソフトウェアプロジェクトには、欠如している次の2つの特徴があるという。

前者は開発プロセス全体を巨視的な視点から見て、プロセスの進め方を把握することであり、マクロプロセスと呼ばれる。マクロプロセスは従来のウォーターフォールモデルに関連が強く、開発工程全体を管理するためのプロセスであるといえる。

一方後者は、システムを徐々に繰り返して構築していくことを意味しており、マイクロプロセスと呼ばれる。マイクロプロセスはまさにスパイラルモデルそのものであり、システムに対してさまざまな改良を加えつつ、少しずつ完成に近づけていく。この作業は現場のソフトウェアエンジニアになじみの方法であり、エンジニアの創造性や技術革新が反映されやすい。

しかしながら、これら2つの特徴は相反する要求であり、実際に適用する上においては、これら2つの要求をいかに融合させ調和させていくかが問題になる。すなわち、「開発者は、マイクロプロセスの非形式性とマクロプロセスの形式性の間の釣り合いをとらなければならないという点が重要である(Booch)」。

このような要求に対して出された1つの解答が、統一プロセス(United Process:UP)である。

PM-図4

UP では、工程管理は大きく2つのレベルに分けられる。1つは管理者が開発過程全体を見渡して大域的な観点から管理を行うマクロプロセスであり、もう1つは開発現場のエンジニアが少しずつソフトウェアの改良、進化を行うことができるマイクロプロセスである。

マイクロプロセスはいわゆるスパイラルモデルを採用しており、与えられた要求を、より小さな要求に分解して繰り返し開発を行う。この過程で、エンジニアの創造性や技術革新性が発揮される。

このプロセスは、「要求分析」、「システム分析」、「設計」、「実装」、「テスト」の5段階の分かれており、この流れを繰り返すことでスパイラル的に工程を進めていく。

また、マクロプロセスはフェーズと呼ばれる4つの工程を管理者の立場から管理するものであり、形としてはウォーターフォールモデルに似ている。4つのフェーズは、それぞれ次のような意味を持つ。

方向付け(インセプション)フェーズ
どんなソフトウェアを作成するかの概念化を進めるフェーズ。アイディアのプロトタイプを作成し、そのアイディアが開発するに値するかどうか、あるいは開発可能であるかどうかの評価を行う。
推敲(エラボレーション)フェーズ
システム構築のための核となるアーキテクチャベースラインを作る。骨組みと黄金ルート(必ず通る基本のルート)を作る。
作成(コンストラクション)フェーズ
システムとして仕上げる。もっとも工数をかける工程。β版のリリースが目標。
移行(トランジッション)フェーズ
β版のリリースとフィールドでの評価結果の反映。出荷の準備など、製品化のための作業を行う。

このような段階的なフェーズを経て、管理者が開発に伴うリスクをできるだけ軽減しつつ、高い開発効率を目指す工程管理手法である。

コストモデル

ソフトウェアのコストモデル(cost model)とは、ソフトウェアのライフサイクルのある作業工程において必要となる原価の算出方法を、何らかのモデルにもとづいて抽象化したものである。

ソフトウェアの開発保守で実施される原価管理では、納期遅延と予算超過が大きな問題となる。ソフトウェアの品質を完璧なものにするためにはその分の工数を追加しなければならない反面、工数を追加すると原価が超過してしまい予算超過となってしまうのである。この意味で、これら2つの要素はトレードオフの関係にあるといえる。

また、納期遅延と予算超過が生じる原因としては、正確な原価管理ができないことがあげられる。従来の経験や勘に頼る定性的な方法では適切な原価管理を行うことは非常に困難であった。そこで、コストモデルから導き出された計算式によって、原価を定量的に見積もる方法が提案された。

ソフトウェアライフサイクルにおける原価管理には、規模見積もりや工数見積もり、原価見積もりなどがあるが、ここでは、規模見積もりと原価見積もりについて説明する。

規模見積もり

ソフトウェアの規模を見積もる場合、何をその尺度とすればよいだろうか?

良く使われるひとつの尺度として、ソースコードの行数(あるいは命令数)がある。しかし、プログラムの命令数は、使用するプログラミング言語の種類によって、同じ処理をするプログラムでも命令数が大きく変化してしまう。たとえば、エキスパートシステムにおける推論部分を、C言語で書いた場合とPrologで書いた場合では、記述量に大きな差が生じる。これは、Prologが推論記述するために特化された命令を持っているためである。

このようなことから、もう少し普遍的にソフトウェアの規模を算出する方法が検討されている。そのひとつに「ファンクションポイント(Function Point:FP)」がある。

ファンクションポイントは、ソフトウェアの規模を、それが実現する機能(Function)の数によって見積もるという方法である。このことは、顧客の立場に立った見積もりの方法であるということができる。つまり、顧客から見れば、開発されたソフトウェアが要求どおりの機能を満たしていれば良いのであって、そのプログラムが何行あるかなどには興味はないのである。

ファンクションポイントでは、ソフトウェアの機能を入出力の数やマスターファイルの数として捉える。そして、それぞれのファイルに対する開発の難易度を付加する形で算出する。 通常、難易度は3段階で評価され、次のような表が使われる。

ファンクションタイプ 意味 容易 普通 複雑
外部入力(EI) アプリケーション境界外からデータや制御情報を受け取って内部ファイルを処理するか、アプリケーションの振る舞いを変える処理。 3 4 6
外部出力(EO) アプリケーション境界外に出て行くデータや制御情報を生成する処理。同時に内部ファイルを処理することもある。 4 5 7
外部参照(EQ) データや制御情報を検索してアプリケーション境界外に提示する処理。現在の情報を画面に表示する処理など。 3 4 6
内部論理ファイル(ILF) アプリケーション境界内にあるデータグループ。このアプリ自身が保守しているファイルなど。 7 10 15
外部インターフェイスファイル(EIF) アプリケーション境界外にあるデータグループ。他のアプリケーションが保守するファイルなど。 5 7 10

(ただし、数値はそれぞのレベルの重みであり、過去の経験に基づいて決められる。上の値は1つの例)

たとえば、外部入力を扱う機能において、容易が2つ、普通が5つ、複雑が3つ含まれていたならば、

P(EI) = 3×2+4×5+6×3=44

のように計算される。このようにして、ファンクションポイント FP は、

未調整FP = P(EI) + P(EO) + P(EQ) + P(ILF) + P(EIF)

として算出される。ただし、この値は「未調整FP」と呼ばれ、次の調整値を乗じて最終的なFPを求めるのが一般的である。

未調整FPに、一般的なシステムの特性に関して以下の項目でその複雑さを0点〜5点の6段階で評価し、それを乗じて調整値を得る。

項目 影響度(0〜5点)
1. データ通信  
2. 分散処理  
3. 性能  
4. 高負荷構成  
5. 要素処理(トランザクション)量  
6. オンラインデータ入力  
7. エンドユーザ効率  
8. オンライン更新  
9. 複雑な処理  
10. 再利用可能性  
11. インストール容易性  
12. 運用性  
13. 複数サイト  
14. 変更容易性  
  ただし、影響度は次のように定める。
影響度 意味
0 該当しない。まったく影響なし。
1 弱い影響がある。
2 やや弱い影響がある。
3 平均的な影響がある。
4 かなり強い影響がある。
5 全体にわたり強い影響がある。

この表から、調整値は、

調整値 = (影響度の合計 × 0.01) + 0.65

で計算する。もし影響度がすべて5だったとすると調整値は 1.35 となるが、一般的には、バッチアプリケーションで 0.7未満、フロントエンドアプリケーションで 0.7〜0.95、対話型アプリケーションで0.95〜1.1、リアルタイムプロセス制御アプリケーションで0.95〜1.25程度になることが多い。

最後に、未調整FPと調整値を掛けることで、最終的なFPを計算する。

FP = 未調整FP × 調整値

FPの簡易計算手法

このように見てくると、ソフトウェアの規模を見積もるかなり大変そうだ、ということがわかる。実際、どの程度のソフトを作ることになるのかを事前にはっきりと見積もることはたいへん困難であり、なかなか思ったようには行かないのが現状である。

このため、FP値をもっと簡単に計算する方法がいくつか提案されている。

FP試算法

この方法は、ILFには平均して3つのEIと2つのEO、1つのEQを伴い、EIFには平均して1つのEOと1つのEQを伴う、という仮定に基づいている。

FP概算法

この方法は、個々のファンクションに対しての評価をせずに、デフォルト値を使ってしまうという点が簡単になっている。

これらの方法は、いずれも統計的なデフォルト値を使ってしまう、という発想を基にしている。特殊なアプリケーションであっても、その統計的な量がある程度わかっていれば、同様な方法で簡易的なFPを計算できるかもしれない。

原価見積もり

ソフトウェアの生産管理に関する原価を算術的に見積もることが原価見積もりである。これには、1981年にベーム(B.W.Boehm)が提案したCOCOMO(COnstructive COst MOdel)が代表的である。

COCOMOは、プログラマの作業量とコストの関係を算術的に計測するモデルである。たとえば、プログラマの作業工数を P とすると、

P = x × KDSI^y

の式で計算する。ここで、KDSI(Kilo Delivered Source Instruction)はプログラムサイズ(主にソースの行数)を示す。また、x,y (y>1) はソフトウェアのさまざまな要因で決まる定数であり、その要因としては、

がある。これらの要素値は開発環境や開発要員のスキルに依存する部分が多いので、統計的なデータ値の蓄積が必要である。

このようにして求めた P に対して、開発期間 T は、

T = 2.5 × P^y

として計算できる。この値にプログラマの単価を掛け合わせれば、原価を計算することができる。

具体的に、COCOMOによりソフトウェアの工数などを見積もる試作ページがある。(COCOMOによる工数計算

また1997年には、COCOMOの計算手法を改良し、上述のFP法等を取り入れてより正確な工数算出を実現したCOCOMO IIも提唱されている。


前へ
(オブジェクト指向)
TOP
(ソフトウェア工学)
次へ
(オブジェクト指向モデル)