システム設計 - IPA 独立行政法人 情報処理推進機構

簡易ビジネスシステムを利活用した
仮想企業間での導入実証実験テキスト
1
概要
本テキストでは，オープンソースソフトウェア（open source software, 以下 OSS と略す）
を利用したシステム構築に関するスキルを身に付けることに重点をおく．具体的には，OSS
を利用したシステム開発を習得するために，グループごとに仮想企業を立ち上げる．事前に
準備された OSS の教材用システム（商品受発注システム）を利用して発注，受注，出荷，入
荷などの業務について学習しつつ，その他必要な機能を考案し，ソースコードレベルで議論
を進め，実際に動作するシステムを開発する．
さらに，OSS のソフトウェア信頼性評価ツールを利用することにより，教材用システムを
開発する際におけるテスト工程において，信頼性を評価することにより，OSS の普及を阻害
する要因の１つとして知られている品質上の問題について評価・議論する．これらの成果物
を公表するために，成果発表を行う．
一般に，ソフトウェアの開発技術を習得するためには，ソースコードレベルでの実践的演
習が必要不可欠であり，こうしたロジックを理解して独自のアルゴリズムを考案し，プログ
ラムを実装することを繰り返す作業を通じて，ソフトウェア特有の問題解決能力を身に付け
ることができる．すなわち，こうした OSS を利用した演習内容を通して，グループによる協
調作業を行い，ソースコードレベルの議論することが可能となる．
キーワード
OSS，OSS 技術教育，ソフトウェアエンジニアリング，ビジネスシステム，プログラミング，
コミュニケーション能力，実践的技術力，開発フレームワーク，開発ツール，統合開発環境，
オペレーティングシステム，Linux，リレーショナルデータベース．
3
目次
システム設計 I
10
第 2 回 設計手法
11
2.1
ソフトウェアの設計
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.2
システムの高信頼化技術 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
第 5 回 ソフトウェアプロセス改善技術
19
5.1
OSS に対する信頼度成長モデル . . . . . . . . . . . . . . . . . . . . . . . . . .
21
5.2
ソフトウェア信頼性評価尺度
24
. . . . . . . . . . . . . . . . . . . . . . . . . . .
第 9 回 要件定義・概要説明
27
9.1
電子商取引
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
9.2
システム要件定義 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
9.3
システム概要説明 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
9.4
作業分担 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
第 10 回 性能評価ツールの概要
35
10.1 OSS の開発工程 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
10.2 ツールの紹介 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
10.3 ツールの実行環境の構築 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
10.4 実行方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
10.5 実行画面 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
10.6 要求仕様定義 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
10.7 信頼性評価手順 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
10.8 JFreeChart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
10.9 信頼性評価の実行例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
10.10最適バージョンアップ時刻推定の実行例 . . . . . . . . . . . . . . . . . . . . .
43
4
第 11 回 設計
45
11.1 機能設計及び詳細設計 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
11.2 MVC とは . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
11.3 詳細設計書項目説明 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
11.4 モデル設計書項目説明 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
11.5 DAO 設計書項目説明 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
第 12 回 開発・テスト
49
12.1 テストフェーズ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
12.2 ユニットテスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
12.3 結合テスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
12.4 システムテスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
12.5 不具合 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
システム設計 II
第 12 回 OSS の開発サイクル・種類・ライセンス
57
59
12.1 OSS の開発サイクル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
12.2 OSS の種類 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
12.3 OSS のライセンス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
第 13 回 OSS 導入における問題点
63
13.1 品質上の問題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
13.2 品質問題解決のためのテスト進捗度管理技術 . . . . . . . . . . . . . . . . . . .
64
第 14 回 組込み OSS の課題
67
14.1 組込み OSS の現状 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
14.2 移植作業 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
14.3 その他の問題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
謝辞
参考文献
5
ライセンス
7
図目次
2.1
ArgoUML の起動画面． . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.2
ArgoUML のメニュー画面． . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.3
アクティビティ図の部品選択画面． . . . . . . . . . . . . . . . . . . . . . . . .
13
2.4
アクティビティ図での設計例． . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.5
アクティビティ図の例． . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.6
シーケンス図の部品選択画面． . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.7
シーケンス図での設計例． . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.8
シーケンス図の例．
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.9
冗長化について． . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.10 並列システム． . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.11 直列システム． . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.12 システムの例． . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
5.1
OSS の開発サイクル． . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
9.1
電子商取引の形態．
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
10.1 推定された各コンポーネントに対する重要度とモデルパラメータの推定結果．
40
b ． . . . . . . . . . . . . . . .
10.2 推定された累積フォールト発見数の期待値，µ(t)
41
cd (t)． . . . . . . . . . . . . . . . . . . . .
10.3 推定された瞬間フォールト発見率，µ
41
10.4 推定された累積 MTBF，M Td
BFC (t)． . . . . . . . . . . . . . . . . . . . . . .
42
10.5 推定された予測相対誤差． . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
10.6 推定された総期待開発労力．
. . . . . . . . . . . . . . . . . . . . . . . . . . .
43
10.7 最適バージョンアップ時刻および総期待開発労力の推定結果． . . . . . . . . .
44
11.1 MVC と本システムの対応図． . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
12.1 単体チェック項目． . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
12.2 結合チェック項目/発注一覧画面． . . . . . . . . . . . . . . . . . . . . . . . . .
54
8
12.3 結合チェック項目/注文書発行画面． . . . . . . . . . . . . . . . . . . . . . . .
55
12.4 システムチェック項目． . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
12.5 不具合報告書． . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
12.1 OSS の開発サイクル． . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
12.2 ソフトウェアのウォーターフォール型開発モデル． . . . . . . . . . . . . . . .
60
14.1 ポーティングのイメージ図．
68
. . . . . . . . . . . . . . . . . . . . . . . . . . .
9
表目次
10.1 Fedora Core 7 におけるリリース候補版のスケジュール . . . . . . . . . . . . .
40
10
システム設計 I
11
第2回
設計手法
ソフトウェア設計の際に用いられる UML のような統一モデリング言語の使用例について
紹介する．さらに，システム設計の際に必要となる信頼性評価について，航空機のジェットエ
ンジンのシステム信頼性の例を取り上げながら，情報システムの高信頼化技術について習得
する．また，ソフトウェアの高信頼化技術として知られているフォールトアボイダンス技術
とフォールトトレランス技術について説明し，ソフトウェアの冗長化技術であるリカバリブ
ロック法や N バージョンプログラミングについて紹介する．
2.1
ソフトウェアの設計
ソフトウェアシステムは，要求仕様定義，設計，コーディング，テスト，運用・保守という
工程を経て開発が行われる．特に，設計工程はソフトウェア開発工程の中でも上流工程に位
置し，もし設計工程において誤った設計が行われたまま，コーディングやテスト工程まで経
過した場合には，設計自体を見直すことになり，開発プロジェクト自体が失敗に終わってし
まい，製品として出荷すらできなくなってしまうことになる．こうした意味からも，設計工
程はシステム開発を行う上で重要な工程となる．
設計言語
主に，設計のための言語として，統一モデリング言語として知られる UML（Unified Modeling
Language）がある．これは，オブジェクト指向に基づいて作成される設計図のことで，その
種類も豊富である．以下に，良く使用される代表的な UML を示す．
• クラス図
• ユースケース図
• シーケンス図
• アクティビティ図
第 2 回 設計手法
12
図 2.1: ArgoUML の起動画面．
図 2.2: ArgoUML のメニュー画面．
• コンポーネント図
演習：UML のダイアグラムについて調査し，全て示せ．
設計のための準備
UML 設計のための無料で使用できるソフトウェアツールとして，JUDE から提供されてい
る astah* community がある．これは，過去には JUDE/Community として公開されていたが，
入手するためには個人登録が必要であるなどの制約があることから，ここでは，オープンソー
スソフトウェアとして公開されている ArgoUML を使用する．ArgoUML は，以下の URL か
らダウンロードできる．Java で書かれており，マルチプラットホームである．
http://argouml.tigris.org/
ArgoUML の起動画面を図 2.1 に示す．
起動して，メニューの図 2.2 にカーソルを合わせれば，各 UML の種類に関するツールチッ
プが表示される．
演習：ArgoUML で扱うことのできる．ダイアグラムを調べよ．
2.1. ソフトウェアの設計
13
図 2.3: アクティビティ図の部品選択画面．
test1
test2
図 2.4: アクティビティ図での設計例．
アクティビティ図
ここでは，代表的な UML として，アクティビティ図について紹介する．アクティビティ図
は，動作や活動状態に着目した流れ図であり，アクティビティノードとアクティビティエッジ
とで構成される．
ArgoUML を用いてアクティビティ図を描いてみる．メニューから New Activity Diagram
にカーソルを合わせてボタンを押すと，右上ペインの画面に図 2.3 のようなアクティビティ図
を描くために必要な部品が表示される．
黒丸から右へ順番に，開始・終了・分岐・フォーク（ジョイン）
・SwimLane・動作ノード・
オブジェクトノードである．
演習：図 2.4 のようなアクティビティ図を描け．さらに，このアクティビティ図の流れを理
解せよ．
演習：図 2.5 のアクティビティ図の流れを理解せよ．
シーケンス図
さらに，代表的な UML として，シーケンス図について説明する．シーケンス図は，オブ
ジェクト同士の動作の時系列に着目した流れ図であり，オブジェクト，活性区間，メッセージ
第 2 回 設計手法
14
図 2.5: アクティビティ図の例．
とで構成される．
ArgoUML を用いてシーケンス図を描いてみる．メニューから New Sequence Diagram に
カーソルを合わせてボタンを押すと，右上ペインの画面に図 2.6 のようなアクティビティ図を
描くために必要な部品が表示される．
四角から右へ順番に，オブジェクト・アクションの呼び出し・アクションの送信・応答・ア
クション生成である．
演習：図 2.7 のようなシーケンス図を描け．さらに，このシーケンス図の流れを理解せよ．
演習：図 2.8 のアクティビティ図の流れを理解せよ．
2.2. システムの高信頼化技術
15
図 2.6: シーケンス図の部品選択画面．
/test1
/test2
/test3
data (a)
data (b)
data (c)
data (d)
図 2.7: シーケンス図での設計例．
2.2
システムの高信頼化技術
ソフトウェアシステムの高信頼化のための体系を以下に示す．フォールトアボイダンス技術
は，欠陥や誤りを開発プロセスで作り込まないようにする技術であり，ある程度の欠陥や誤
りは避けられないという立場から，その影響を最小限にしようとする技術である．また，同
一要求仕様のソフトウェアを二つ以上のバージョンで構成する冗長化技法がある [1]．


フォールトアボイダンス技術








 [冗長化技法]

フォールトレランス技術 リカバリブロック法






 N バージョンプログラミング

(2.1)
冗長化技術
冗長化とは，図 2.9 のように，別々の工程で作られたシステムが 2 つ以上搭載されているシ
ステムのことをいう．
システムの信頼度
一例として，図 2.10 のような並列システムの場合を考える．このときの信頼度は，
R = 1 − (1 − 0.9) × (1 − 0.8) = 1 − 0.1 × 0.2 = 1 − 0.02 = 0.98,
(2.2)
第 2 回 設計手法
16
図 2.8: シーケンス図の例．
のように計算できる．
また，図 2.11 のような直列システムの場合には，
R = 1 − (1 − 0.9 × 0.8) = 1 − (1 − 0.72) = 1 − 0.28 = 0.72,
のように計算できる．
演習：図 2.12 のシステム全体の信頼度を求めよ．
(2.3)
2.2. システムの高信頼化技術
17
図 2.9: 冗長化について．
図 2.10: 並列システム．
図 2.11: 直列システム．
図 2.12: システムの例．
19
第5回
ソフトウェアプロセス改善技術
現実のソフトウェア製品の開発においては，曖昧な計画作業に起因する作業のやり直しや
追加などの無駄が発生し，最悪の場合には作り直しの事態に陥ることも珍しくない．最近で
は，OSS のような既存のソースコードを利用することにより，開発コスト・開発労力を削減
する動きも盛んである．こうした OSS を利用した開発手法について紹介する．まず，ソフト
ウェアプロセスの全体像として，従来からのソフトウェア開発サイクルについて解説する．さ
らに，OSS の開発サイクルについて紹介した後，OSS の品質上の問題点について説明する．
従来のソフトウェア開発では，ホストコンピュータの周辺に複数のワークステーションを
つないだような同一企業内における開発形態が一般的であった．現在では，オブジェクト指
向技術，ネットワーク技術の進歩などにより，開発者同士が離れていても同じような作業が
できるという特徴をもつ，分散ソフトウェア開発環境が主流となっている．こうした開発形
態の変化と同時に，ソフトウェア開発形態についても，ウォーターフォールモデル，V 字型
モデル，スパイラルモデルなど，多くのソフトウェア開発モデルが存在している．
主に，ウォーターフォールモデルに代表されるように，ソフトウェア開発は，要求仕様定
義，設計，コーディング，テスト，運用・保守という工程を経て進められる．特に，最近のソ
フトウェア開発では，ある程度一定の品質を維持しながら，短納期達成や開発コスト削減を
行う必要があり，これらの要求を満たすためには，テスト工程の管理が重要となってくる．す
なわち，テスト工程に時間や費用を費やすほどソフトウェアの品質は向上するが，テストを
実施するためのテストコストが増大する．逆に，テストコストを抑えようとしてテスト期間
を短くすれば，ソフトウェア品質が低下するとともに，運用・保守段階における保守コスト
が増加する．ソフトウェア開発プロセスには，このようなトレードオフの関係が存在する．
従来から，ソフトウェア製品の開発プロセスにおけるテスト進捗管理や出荷品質の把握の
ための信頼性評価を行うアプローチとして，ソフトウェア故障の発生現象を不確定事象とし
て捉えて確率・統計論的に取り扱う方法がとられている．
また，OSS はサーバ用途を主として，多くの分野において使用されている．OSS は，世界
中の誰もが開発に参加でき，ソースコードが公開され，誰でも自由に改変可能なソフトウェ
アであることから，最近では組込みシステムやサーバ用途として広く採用され，急激に普及
が広まっている [2, 3]．また，オープン規格や OSS を利用することによって，電子行政機関が
第5回
20
ソフトウェアプロセス改善技術
図 5.1: OSS の開発サイクル．
プライバシーや個人の自由を保護するとともに，市民が電子政府と情報をやり取りできるよ
うにするのに役立つことから，EU 加盟国を中心に欧米においても政府関係機関が OSS を支
持する動きが広がっている [4]．最近の OSS の傾向として，組込み機器に対しても Android[5]
や BusyBox[6] に代表される組込み OSS が積極的に採用されつつある．
一方，OSS の利用に関しては，未だに多くの不安が残されている．まず第 1 に，システム
導入後のサポートや品質上の問題といった利用者側の一般的な不安である．第 2 に，OSS は
本当にビジネスになるのか，オープンソースのソフトウェアを事業化することによって自社
製のソフトウェア商品までが市場を失うことにならないか，といった開発者側の不安である
[4]．特にサポートや品質上の問題については，OSS の普及を妨げる大きな要因として考えら
れており，組込み OSS に関しては不安材料の大きな要因の 1 つとして考えられる．一般的な
OSS の開発プロセスを図 5.1 に示す．図 5.1 のように，OSS の開発プロセスの大きな特徴とし
て，テスト工程が存在しないことが挙げられる．
また，OSS はバージョンアップにより成長していく．バージョンアップには大きく分けて
マイナーバージョンアップとメジャーバージョンアップがある．しかしながら，どの程度の改
訂で区別されるという明確な基準がある訳ではない．マイナーバージョンアップは，旧版に
いくつかの細かい機能が追加されたり，性能が若干向上した場合に実施される．ただし，機
能の不具合やセキュリティ上の脆弱性を修復するような，クリティカルなフォールトがいく
つか発見され緊急に修正を施す必要がある場合に実施される改訂はマイナーバージョンアッ
プではなく，バグフィックスと呼ばれている．一方，メジャーバージョンアップは，OSS 自体
の機能が大きく変更されたり，大型の新機能の追加や，性能が劇的に向上した場合に実施さ
れる．
テスト工程に類似した段階として，OSS にはバージョンアップ直前に実施される Release
5.1. OSS に対する信頼度成長モデル
21
Candidate がある．この段階で，リリース候補版をリリースし，そこで実際の運用環境を想定
したテストが行われている．しかしながら，このリリース候補版の段階では，企業組織で開
発されるソフトウェアのように，テスト進捗管理は行われていないのが現状である．
こうしたオープンソースプロジェクトの下で開発されている OSS に対して，テスト管理に
関する問題の 1 つとして 2 種類のソフトウェア信頼度成長モデル（software reliability growth
model，以下 SRGM と略す）[1] に基づいた信頼性評価法が提案されている．
5.1
OSS に対する信頼度成長モデル
典型的な SRGM に関して理解していることを前提として，OSS に対する信頼度成長モデル
について解説する．
一般化非同次ポアソン過程モデル
従来から, ソフトウェアの信頼性を定量的に評価する手法として，ソフトウェア故障の発
生現象を不確定事象として捉えて確率・統計論的に取り扱う方法がとられている．その 1 つ
が，SRGM である [1]．中でも非同次ポアソン過程（nonhomogeneous Poisson process，以下
NHPP と略す）モデルは，実利用上極めて有効でありモデルの簡潔性が高いゆえにその適用
性も高く，実際のソフトウェア信頼性評価に広く応用されている．この NHPP モデルは，所
定の時間区間内に発見されるフォールト数や発生するソフトウェア故障数を観測して，これ
らの個数を数え上げる計数過程 {N (t), t ≥ 0} を導入し，以下の式で与えられる確率変数すな
わちポアソン過程を仮定する SRGM である [1]．
Pr{N (t) = n} =
{H(t)}n
exp[−H(t)]
n!
(n = 0, 1, 2, · · ·).
(5.1)
ここで，Pr{·} は確率を表し，H(t) は時間区間 (0, t] において発見される総期待フォールト数，
すなわち N (t) の期待値を表し，NHPP の平均値関数と呼ばれる．
特に，オープンソースプロジェクトについて考えた場合，通常のソフトウェア開発のテスト
工程で適用される SRGM のように，ソフトウェア内に潜在するフォールト数が有限であると
仮定されたモデルよりも，むしろ無限回のソフトウェア故障が発生すると仮定されたモデル
を適用する方が現実的である．すなわち，オープンソースプロジェクトでは常にフォールト
修正やバージョンアップが繰り返されており，使用頻度や人気の高い OSS になるほどフォー
ルト報告が頻繁に行われている．この運用形態はオープンソースプロジェクトが無意味なも
のとみなされ解散するまで続けられる．したがって，1 つの企業組織内において，ある特定の
第5回
22
ソフトウェアプロセス改善技術
使用目的に限定されたソフトウェアの開発を対象としている従来の SRGM により，OSS の信
頼度成長現象を包括することは難しくなる [7, 8]．
本ツールには，検出可能フォールト数が無限であると仮定された NHPP に基づく一般化さ
れた対数型ポアソン実行時間モデルが適用されている [1]．
このモデルでは，時間区間 (0, t] で発見される総期待フォールト数を表す平均値関数 µ(t) は，
µ(t) =
1
ln[λ0 (θ − P )t + 1]
θ−P
1
subject to (P − θ) <
λ0 t
(0 < θ, 0 < λ0 , 0 < P < 1),
(5.2)
により与えられる．ここで，パラメータ λ0 は初期故障強度，パラメータ θ はソフトウェア故
障 1 個当りの故障強度の減少率を表す．また，パラメータ P はシステム全体に及ぼすコンポー
ネントの影響率を表す．上記の NHPP モデルから，種々のソフトウェア信頼性評価のための
定量的尺度を導出できる．
一般化確率微分方程式モデル
さらに，本ツールには，確率微分方程式から導出されたソフトウェア信頼度成長モデルが
適用されている．まず，時刻 t = 0 で OSS がリリースされ，任意の時刻 t におけるソフトウェ
ア内の発見フォールト数 {S(t), t ≥ 0} は以下の常微分方程式によって記述されるものと仮定
する．
dS(t)
= λ(t)S(t).
dt
(5.3)
ここで，λ(t)(> 0) は時刻 t におけるソフトウェア故障強度を表す．
OSS のフォールト報告では，フォールトの発見と同時にバグトラッキングシステムへのフォー
ルト情報の登録が行われるというわけではなく，フォールト発見の前後に若干のタイムラグ
が生じた状態で登録が行われる場合が多い．このように，バグトラッキングシステム上への
フォールトの登録を考えた場合，OSS のフォールト発見事象は，常に不規則な状態であると
考えられる．こうした不規則性を，標準化された Gauss 型白色雑音によって近似的に表現す
ることを考える．さらに，OSS は常にバグフィックスやコンポーネントの加除が繰り返され
ており，ソフトウェア故障強度もそれに応じて変化するものと考えられる．
上記のことから，故障強度 λ(t) に不規則性を導入すると，式 (5.3) は，
dS(t)
= {λ(t) + σγ(t)} S(t),
dt
(5.4)
5.1. OSS に対する信頼度成長モデル
23
となる．ここで，σ (> 0) は定数パラメータであり，γ(t) は解過程の Markov 性を保証するた
めに標準化された Gauss 型白色雑音である．さらに，λ(t) は時刻 t におけるソフトウェア故
障強度関数を表す．式 (5.4) を以下の Itô 型 [9, 10] の確率微分方程式に拡張して考える [11]．
1
dS(t) = {λ(t) + σ 2 }S(t)dt + σS(t)dω(t).
2
(5.5)
式 (5.5) の確率微分方程式を初期条件 S(0) = v の下で Itô の公式 [9, 10] を用いて変換すると，
(∫
S(t) = v · exp
)
t
λ(s)ds + σW (t) ,
(5.6)
0
となる．ここで，v は以前のバージョンまでに発見されたフォールト数を表す．式 (5.6) で定
義された W (t) の性質は，次の通りである．
(1) W (t) は Gauss 過程である.
(2) W (t) の平均および分散は，それぞれ
E[W (t)] = 0, Var[W (t)] = σ 2 t,
(5.7)
により与えられる．
(3) W (t) は定常独立増分をもつ.
(4) Pr[W (0)=0]=1.
OSS に対する確率微分方程式モデルでは，ソフトウェア故障強度関数を以下のように仮定
する．
∫
0
t
λ(s)ds = (1 − exp[−αt]).
(5.8)
ここで，α はソフトウェア故障強度の加速係数を表す．式 (5.8) の強度関数は，その他にも S
字形などの形状を仮定することも可能である．しかしながら，OSS のフォールト報告の特徴
として，バージョンアップ直後においては，フォールト報告数は指数関数的に増加するとい
う経験的傾向があることから，これを反映するために指数形の強度関数を仮定した．さらに，
モデルの構築および適用可能性に関する考察に重点を置くために，単純な構造をもつ式 (5.8)
の強度関数について取り扱うこととする．
式 (5.6) から，
lim E[S(t)] = ∞.
t→∞
(5.9)
第5回
24
ソフトウェアプロセス改善技術
となり，時刻 t を ∞ と考えた場合の発見フォールト数は ∞ となることが分かる．
提案された一般化確率微分方程式（stochastic differential equation，以下 SDE と略す）モ
デルから，任意の時刻 t における発見フォールト数の期待値 E[S(t)] は，
E[S(t)] = v · exp
(∫
t
0
)
σ2
λ(s)ds + t ,
2
(5.10)
となる．
5.2
ソフトウェア信頼性評価尺度
上述した一般化 NHPP モデルおよび一般化 SDE モデルから，種々のソフトウェア信頼性評
価のための定量的尺度を導出できる．
瞬間フォールト発見率は強度関数により表すことができる．これは，単位時間当りに発見
されるフォールト数として定義される．瞬間フォールト発見率は，一般化 NHPP モデルから
以下のように導出できる．
µd (t) =
dµ(t)
.
dt
(5.11)
また，一般化 SDE モデルから，S(t) の分散を次のように求めることができる．
( ∫
Var[S(t)] = E[{S(t) − E[S(t)]}2 ] = v 2 exp 2
t
λ(s)ds + σ 2 t
0
){
}
exp(σ 2 t) − 1 .
(5.12)
平均ソフトウェア故障発生時間間隔（mean time between software failures: MTBF）は，ソ
フトウェア 故障の発生頻度を表すのに有益な尺度である．また，MTBF が大きな値を取るこ
とは，それだけフォールトが発見し難くなり，ソフトウェア信頼性が向上したと判断できる
ことになる．任意の時刻 t における瞬間 MTBF （instantaneous MTBF: MTBFI ）および累
積 MTBF（cumulative MTBF: MTBFC ）は，一般化 NHPP モデルおよび一般化 SDE モデル
から，以下のように導出できる．
任意の時刻 t における瞬間的なフォールト発見間隔の平均を意味する瞬間 MTBF は，
1
,
dµ(t)/dt
]
[
1
,
M T BFI (t) = E
dS(t)/dt
M T BFI (t) =
となる．
(5.13)
(5.14)
5.2. ソフトウェア信頼性評価尺度
25
運用開始時点から考えたときの発見フォールト 1 個当りに要する発見時間の平均を意味す
る累積 MTBF は，
t
,
µ(t)
[
]
t
M T BFC (t) = E
,
S(t)
M T BFC (t) =
(5.15)
(5.16)
により表すことができる．
上述した SRGM は，OSS のテスト工程を対象としたものであり，従来のソフトウェア開発
プロセスの総合テスト工程に類似したリリース候補版などの段階におけるフォールトデータ
を適用することを想定している．
27
第9回
9.1
要件定義・概要説明
電子商取引
電子商取引の歴史
1996 年に IBM 社が同社製品の販売促進戦略として打ち出したスローガンとして「e-business」
という用語が用いられた．
「e-business」とは企業活動におけるあらゆる情報交換・蓄積手段を
電子化し，経営効率を向上させること．また，その結果もたらされる電子化された企業活動
の諸形態．この用語が現在は一般的となり電子商取引 (Electronic Commerce，以下 EC と略
す) は「e-business」の中の取引形態を示す用語として広まった．EC とは，インターネットな
どのネットワークを利用して，契約や決済などを行なう取引形態．ネットワークの種類や取引
の内容を限定しない，包括的な意味を持つ言葉である．従来から企業間の取引の一部は EDI
などの技術を使って電子化されていたが，インターネットが一般消費者に普及するにつれて，
消費者を直接対象にした電子商取引サービスが急激に成長している．[17]．
電子商取引の種類
一般的な電子商取引の形態として以下のプロセスが存在する
1. B to B (Business to Business)
• サプライヤとメーカ間等の企業間取引
• 企業内で運用していた業務をネットワークを通じてアウトソーシングする ASP や
SaaS
2. B to C (Business to Customer)
• ショッピングモールや電子店舗のように企業と消費者間での商品の直接販売
• インターネット上で人材派遣や商品売買の仲介を行なうサービス
• 株式などの金融商品をインターネットを通じて売買するオンライントレード
3. C to C (Customer to Customer)
第9回
28
要件定義・概要説明
• ネットオークションのような消費者間での商品取引を行なう
4. B to E (Business to Employee)
• 企業が従業員に向けて商品を販売する
5. G to B/C (Government to Business/Citizen)
• 官公庁自治体における住民・企業等とのやり取り (電子申請・届出サービス)
上記以外のデータ連携プロセスとして最近では「A to A(Application to Application)」と
いう用語も使われ，企業内のアプリケーション同士を直接繋げることである．
本講義では，
「B to B」での業務及び取引の流れを理解し，その上で稼動するシステムの構
築及び実証実験を行なう．
図 9.1: 電子商取引の形態．
9.2
システム要件定義
要件定義の目的
要件定義とは，システムやソフトウェアの開発において，どのような機能が要求されいて，
実装されるべきなのかを明確にしていく作業のこと．開発者側と依頼者側の双方の協力によ
り定義が行われ，その成果は「要件定義書」としてまとめられる．開発を始める前に行う作
業であるが，最も重要なプロセスの一つである．要件定義を十分に行うことにより，開発後
のトラブルや開発途中での仕様変更などのリスクを低減させることができる．要件定義に対
して，ユーザの要求をまとめる作業を「要求定義」と呼び，
「要求定義書」が作成される．まと
められた要求を実現するために要件定義が行われ，それを基に開発の工数や費用の見積もり
が行われる．開発プロセスの基本的なモデルの一つである「ウォーターフォールモデル」に
9.3. システム概要説明
29
おいては，
「要件定義」は一番最初に行われる作業工程である．続いて「設計」，
「コーディン
グ」，
「テスト」，
「運用・保守」という作業工程に移る．
「要件定義書」は，次工程の基本設計の
ためのインプット資料となる．ウォーターフォールモデルは各作業工程ごとに成果を検証し，
承認を経て次の工程へと進むモデルであることから，前の工程に逆戻りできずフィードバッ
クができないという問題点がある．[17]．本講義では，依頼者側へのヒヤリングや問題点の洗
い出しが完了し要件定義書がまとめられと仮定し，次工程の「基本設計」より説明を行なう．
9.3
システム概要説明
基本設計
開発工程の中で要件定義と詳細設計の間に位置する工程．顧客が必要としている要件をま
とめた要件定義を基に，どのようなシステムを開発すればそれを満たすことが出来るかを検
討し，機器の構成や実装すべき機能，画面や帳票など操作や入出力に関する事項，生成・保
管されるデータの概要など，システムの基礎的な仕様をまとめる．[17] 以下，基本設計工程
で作成する各ドキュメントについて紹介しながら，本講義で構築するシステムの基本設計の
内容を具体的に説明する．
システム概要
システム全体の概略を文書や図で表示する．
基本設計書「システム概要」参照．
性能要件
システムが求められる性能 (主に応答速度) について記述する．
基本設計書「性能要件」参照．
セキュリティ対策
システムが完全性・機密性・可用性を確保する為の対策について記述する．
基本設計書「セキュリティ対策」参照．
30
第9回
要件定義・概要説明
障害対策
ハードウェア障害や災害などによってシステムに障害が生じた際に誰がどの様に対応する
かについて記述する．
基本設計書「障害対策」参照．
画面標準
画面の基本レイアウトや標準解像度，ボタンサイズ，メッセージ表示方法を記述する．
基本設計書「画面標準」参照．
メッセージ標準
画面に表示するメッセージの標準形式や体系を記述する．
基本設計書「メッセージ標準」参照．
命名規約
サブシステムや機能，変数名，定数名，関数名の命名基準について記述する．
基本設計書「命名規約」参照．
機能一覧
開発する機能の名称をサブシステム単位等に分類し一覧で表示する．
基本設計書「機能一覧」参照．
データフロー図 (DFD)
システム間のデータの流れを示す図．データを発生・吸収・処理・蓄積するシステムの間を，
データの流れを示す矢印で繋いで作成する．データの流れが明確になることによって，効率
化しやすい場所を容易に発見できる等のメリットがある．[17]
基本設計書「DFD」参照．
業務フロー
業務の流れや仕事の手順などを進行順に図で表したもの．DFD はデータの流れを中心に記
述するが，業務フローは，ユーザが確認しやすいように業務の流れを中心に記述する．
基本設計書「業務フロー」参照．
9.3. システム概要説明
31
画面遷移図
画面の構成を表す図の一つで，画面がどのような順序で表示されるか，あるいは各画面が
どのような関連性を持っているのかを図で示したもの．
基本設計書「画面遷移図」参照．
機能定義
機能ごとに概要，画面/帳票レイアウト，関連テーブル等を記述したもの．
基本設計書「機能定義書」参照．
エンティティ一覧
エンティティとは一単位として扱われるデータのまとまり．たとえば，顧客，社員，会社，
受注，発注などの情報．エンティティ一覧とはエンティティの名称を一覧に表したもの．
基本設計書「エンティティ一覧」参照．
エンティティ関連図 (ER 図)
情報のまとまりである「エンティティ(Entity)」と情報の相互関係である「リレーションシッ
プ (Relationship)」を図で表したもの．
基本設計書「エンティティ関連図 (ER 図)」参照．
エンティティ定義
エンティティに属する項目の内容と項目のレイアウトを表したもの．
基本設計書「エンティティ定義書」参照．
エンティティ更新参照表 (CRUD)
横軸，縦軸にエンティティまたは機能を配置し，それぞれ C(作成) R(検索) U(更新) D(削
除) の対応を記入し，データ入力系プロセスとエンティティの関連を示す．
基本設計書「エンティティ更新参照表」参照．
第9回
32
要件定義・概要説明
外部インタフェース定義
外部とデータをやり取りする際に用いられるプロトコルやファイルなどの定義を記述した
もの．
基本設計書「外部インタフェース定義」参照．
共通処理一覧
各機能で共通に使用されるクラスの名称と概要を一覧で記述したもの．
基本設計書「共通処理一覧」参照．
共通処理仕様
各共通処理の仕様 (概要，使用方法，I/O 等) を詳細に記述したもの．
基本設計書「共通処理仕様」参照．
コード定義
システムで使用されるコードのコード名，コードの意味・目的，コード桁数・属性，使用
方法，コード値を記述したもの．
基本設計書「コード定義」参照．
用語集
システムで使用される専門的な用語等の説明を記述する．
基本設計書「用語集」参照．
9.4
作業分担
前項で説明した基本設計の内容を理解し，この後の具体的な作業をイメージし，各グルー
プで作業を分担せよ．
なお，作業分担前に以下の役割を担当する人を決定せよ．
• プロジェクト管理者 (マネージャ)
プロジェクト全体のスケジュール管理，品質管理，コスト管理，リスク管理，コミュニ
ケーション管理を行う．
9.4. 作業分担
33
• プロジェクトリーダ
設計，開発，テストの管理を行ない，プロジェクト管理者をサポートする．
システム全体を理解し，実装がイメージできる人が理想的である．
• 標準化/共通化担当
設計標準及びコーディング基準，共通仕様の管理を行う．
以上の担当が決まったら，次に機能ごとに設計開発テストを行なう担当を決定せよ．プロジェ
クト管理者，プロジェクトリーダ，標準化/共通化担当が設計/開発しても構わない．
35
第 10 回
10.1
性能評価ツールの概要
OSS の開発工程
OSS を利用したシステム開発において，品質を評価するためのテスト工程は重要となる．特
に OSS は，以下のような流れで開発が行われる．
• コーディング
• Web 上に公開
• ユーザの使用
• バグトラッキングシステムへの不具合報告
• 開発者によるフォールトの修正
その開発工程には，従来の企業組織において存在したテスト工程が存在しないのが特徴であ
る．こうしたことから，OSS には潜在的に品質上の問題が存在しており，この問題が OSS の
普及を妨げる要因の１つであると言われている．ここでは，OSS を利用したシステム開発に
おける信頼性評価法について説明し，信頼性評価ツールの操作方法を習得する．
10.2
ツールの紹介
本ツールは，OSS の信頼性を評価するツールである．ソフトウェア信頼度成長モデルの非
同次ポアソン過程に基づく対数型ポアソン実行時間モデルを適用している．本ツールは，オ
ブジェクト指向型言語である Java を用いているため，以下のものをインストールし，実行可
能な状態に設定する必要がある．
第 10 回 性能評価ツールの概要
36
10.3
ツールの実行環境の構築
Windows の場合
まず，jdk-（バージョン番号）-windows-i586-p.exe をダウンロードしてインストールする．
インストールが完了したら，path の設定をする．マイコンピュータの詳細設定より環境変数
を選択し，ユーザー環境変数の path を選択する．既に path がある場合は，この値の前に「;」
を付ける必要がある．
path の設定ができているか確認するために，コマンドプロンプト上で javac と入力すれば
良い．コマンドプロンプトは，[スタート] メニューから [すべてのプログラム] → [アクセサリ]
→ [コマンドプロンプト] から実行できる．javac と入力すれば，コマンドに関する説明文が表
示される．
Linux の場合
Linux の場合は，ほぼ標準で JRE および JDK ともにインストールされている．もしインス
トールされていない場合は，パッケージマネージャを利用すれば簡単に導入できる．
10.4
実行方法
まず，以下のサイトで提供されているデータファイル（.zip）を展開する．
http://sourceforge.net/projects/sratfoross/
次に，展開されたファイル群と oss.jar（ツール本体）を同じディレクトリに保存する．
Windows 環境では oss.jar ファイルをダブルクリックすれば起動する．Mac や Linux 環境で
は，java -jar oss.jar とすれば起動する．
10.5
実行画面
実行画面には，以下のようなチェックボックスが配置されている．
Estimation Results Based on Neural Network
Estimation Results of Model Parameter
Cumulative number of detected faults
Instantaneous Fault Detection Rate
Cumulative MTBF
predicted Relative Error
10.6. 要求仕様定義
37
文字の左側のチェックボックスをクリックしたらそれぞれの実行結果が出てきます．各チェッ
クボックスについて以下に簡単に説明する．
・Estimation Results Based on Neural Network：
ニューラルネットワークにより算出された各コンポーネントに対する重み係数がテキストフィー
ルドに表示される．
・Estimation Results of Model Parameter：
最尤法により推定された未知パラメータ φ, λ0 および P の値が表示される．
・Cumulative number of detected faults：
別のウインドに，推定された累積フォールト発見数の期待値がグラフ表示される．
・Instantaneous Fault Detection Rate：
別のウインドに，推定された瞬間フォールト発見率がグラフ表示される．
・Cumulative MTBF：
別のウインドに，推定された累積 MTBF がグラフ表示される．
・predicted Relative Error：
別のウインドに，推定された予測相対誤差がグラフ表示される．
10.6
要求仕様定義
本ツールの要求仕様を以下に示す．
1. OSS に対する信頼性評価ツールとして，バグトラッキングシステムから採取された実測
データを用いて信頼性評価を行い，各推定結果をグラフ表示する．なお，信頼性評価に
必要な全てのデータは，1 つの CSV（Comma Separated Values）形式のファイルに記
述されるものとする．
2. システム全体を構成する複数のコンポーネントの重要度を推定するために，ニューラル
ネットワークを採用する．システム全体に対する信頼性評価のために適用するモデルは，
一般化対数型ポアソン実行時間モデルを採用する．
第 10 回 性能評価ツールの概要
38
3. 適用モデルに含まれる未知パラメータの推定，実測データに対するモデルの適合性評価，
信頼性評価を行う．
4. ニューラルネットワークに基づき各コンポーネントの重要度を推定し，各コンポーネン
トの重要度を表示する．
5. 実測データと推定値との適合性比較規準としては，予測相対誤差を用いる．
6. ソフトウェア信頼性評価尺度として，総期待発見フォールト数，瞬間フォールト発見率，
累積 MTBF を用いる．
7. すべてのグラフは，同時に表示することが可能であるとする．
8. 以上の操作は，GUI によりマウスボタンのクリックにより行う．
9. プログラム記述言語として，オブジェクト指向型言語の 1 つである Java を用いて開発
する．
10. 開発および保守労力削減のために，フリーのグラフ生成ライブラリである JFreeChart
を使用する．
11. 総期待開発労力をグラフ表示する．推定された総期待開発労力に基づき最適バージョン
アップ時刻を導出する．
10.7
信頼性評価手順
以下に，OSS に対するソフトウェア信頼性評価手順を示す．
1. 信頼性評価の対象となる OSS を選択し，バグトラッキングシステムからフォールトデー
タを採取する．
2. 得られたデータから，ツールで読み込むために必要な CSV 形式のデータファイルを作
成する．
3. ニューラルネットワークにより各コンポーネントの重要度を推定する．モデルに含まれ
る未知パラメータを最尤法により推定する．
4. 信頼性評価尺度として，総期待発見フォールト数，瞬間フォールト発見率，および累積
MTBF を推定し，結果をグラフ表示する．また，予測相対誤差の推定結果をグラフ表示
する．
10.8. JFreeChart
39
5. 総期待開発労力の推定結果をグラフ表示するとともに，最適バージョンアップ時刻を推
定する．
10.8
JFreeChart
J2SE には Java 2D と呼ばれる画像生成用の API が組み込まれているため，最低限の画像
描画を行うことは可能であるが，棒グラフのようなチャートを作成する場合には，あらかじ
め座標軸を綿密に計算しなければならない．特に，時系列グラフの場合には，横軸の単位の
調整を行わなければならないなど，非常に煩雑なコーディングが必要となってくる．
JFreeChart を使用することにより，グラフ描画に必要なデータセットを引き渡すだけで高
機能なグラフを生成することが可能となり，開発労力を大幅に削減することが可能となる．
JFreeChart は，The JFreeChart Project によって開発されたグラフィックライブラリである．
Java 1.3 以降の環境で動作し，LGPL（GNU Lesser General Public License）の下で OSS と
して配布されているため，商用製品にも利用することができる [?]．
本ツールでは，フリーのグラフ生成ライブラリである JFreeChart が使用されている．
10.9
信頼性評価の実行例
OSS に対する信頼性評価手法ならびに最適バージョンアップ問題の適用例を示すために，実
行例として Fedora プロジェクト1 で開発が進められている Fedora Core Linux の Kernel を取
り上げる [12]．ここでは，Fedora Core 7（FC7）のリリース候補版である Test 1 のリリース
以降における信頼性評価結果を示す．評価版において十分な信頼性を確認することは，正式
版リリース後のユーザに対する信頼や人気に大きく関係すると同時に，OSS の保守コストや
保守労力の増大に関係することから，リリース候補版の信頼性評価は正式版リリースへ向け
ての重要な段階となる．FC7 のリリーススケジュールを表 10.1 に示す．
上述したデータを本信頼性評価ツールで読み込むためのデータ形式に変換する必要がある
が，ここでは簡略化のため，変換後のデータである data.csv を利用する．実際のツールの操
作方法については，演習中に説明する．
まず，ニューラルネットワークにより推定された各 Kernel コンポーネントに対する推定結果
および式 (5.2) におけるモデルパラメータの推定結果を図 10.1 に示す．Fedora Core を構成す
るコンポーネント数は小規模なものを合わせると数百と非常に多いことから，ここではシステ
ムの主要コンポーネントとして Kernel を取り上げることとする．この結果から，Kernel コン
1
Fedora は Red Hat Inc. の登録商標である．
第 10 回 性能評価ツールの概要
40
表 10.1: Fedora Core 7 におけるリリース候補版のスケジュール
Date
1 February 2007
29 February 2007
27 March 2007
24 April 2007
31 May 2007
Event
Test1 Release
Test2 Release
Test3 Release
Test4 Release
Fedora 7 General Availability
図 10.1: 推定された各コンポーネントに対する重要度とモデルパラメータの推定結果．
ポーネントの信頼性に関する重要度が最大であり，Kernel-module-thinkpad，Kernel-pcmcia-
cs，Kenrel-utils，および Kernel-xen-2.6 のコンポーネントの重要度が最低であることが分かる．
これは，Kernel コンポーネントの成熟度が高く，Kernel-module-thinkpad，Kernel-pcmcia-cs，
Kenrel-utils，および Kernel-xen-2.6 のコンポーネントの成熟度が低いことを意味する．また，
b
推定された式 (5.2) における累積フォールト発見数の期待値の推定値 µ(t)
を図 10.2 に示す．さ
cd (t)，式 (5.15) における累積 MTBF の推
らに，式 (5.11) の瞬間フォールト発見率の推定値 µ
定値 M Td
BFC (t) の推定結果を図 10.3 および図 10.4 に示す．これらの結果から，時間の経過
とともに平均故障発生時間間隔が小さくなり，今後もソフトウェア故障が頻繁に発生するこ
とが確認できる．また，予測相対誤差の推定結果を図 10.5 に示す．図 10.5 から，実測値と推
定値との誤差は，2 月 16 日以降において安定していることが確認できる．
10.9. 信頼性評価の実行例
b ．
図 10.2: 推定された累積フォールト発見数の期待値，µ(t)
cd (t)．
図 10.3: 推定された瞬間フォールト発見率，µ
41
42
第 10 回 性能評価ツールの概要
図 10.4: 推定された累積 MTBF，M Td
BFC (t)．
図 10.5: 推定された予測相対誤差．
10.10. 最適バージョンアップ時刻推定の実行例
43
図 10.6: 推定された総期待開発労力．
10.10
最適バージョンアップ時刻推定の実行例
最適メジャーバージョンアップ時期推定の数値例として，Fedora Core を取り上げる．ここ
では一例として，FC6 までの過去のデータに基づき，FC7 への次期バージョンアップ時刻を
推定する．前バージョンである FC6 の評価版リリースから正式リリースまでの期間は 92 日で
あったことから，t0 を 92 と仮定し，2007 年 2 月 1 日以降における推定された総期待開発労力
を図 10.6 に示す．さらに，図 10.6 から推定された最適バージョンアップ時刻の推定結果を図
10.7 に示す．図 10.6 および図 10.7 から，総期待開発労力を最小にする最適バージョンアップ
時刻は FC 7 の評価版がリリースされてから 6 月 14 日となり，そのときの総期待開発労力は
19359.0 人・日であることが確認できる．
なお，実際の FC7 は，2007 年 2 月 1 日に評価版がリリースされ，120 日後の 5 月 31 日に正
式版がリリースされている．このことから，総期待開発労力を最小にするという観点から考
えた場合，2 週間早い正式版リリースであったことが読み取れる．
演習：上述した OSS に対する信頼性評価ツールの一連の操作と同様にして，サンプルデー
タの信頼性を評価せよ．
44
第 10 回 性能評価ツールの概要
図 10.7: 最適バージョンアップ時刻および総期待開発労力の推定結果．
45
第 11 回
11.1
設計
機能設計及び詳細設計
機能設計
機能設計は基本設計で決定した事項に基づき, 各機能について詳細に掘り下げた内容を記述
する.
GUI 周りではボタンやリンクなどをクリックした時の動作やその画面に出力される情報に
ついて. データ周りではその機能にどの様な情報が入力され/どの様な加工が行われ/どの様
な情報が出力されるかといった内容になる.
詳細設計
詳細設計は機能設計で決定した事項に基づき, 更に実装に落とし込めるレベルまでブレイク
ダウンしたものを記述する.
こちらはクラスやメソッド/関数やモジュールといった単位に分かれ, 使用するプログラム
言語に偏った記述も出てくる.
機能設計書や詳細設計書の段になってくると, 各会社や各プロジェクトでも記述される粒度
がまちまちになる傾向になる. それぞれに一長一短あり正解というものはないが, いずれにし
ろ次工程であるメイク (製造) を行うにあたって必要充分な情報が記述されている必要がある.
特に昔と違って開発者個人個人にコンピュータが割り当てられている現在ではアルゴリズムレ
ベルにまで落とし込んだ設計書は記述せずに, トライ＆エラーによる開発を行うことが多い.
今回のシステムでは機能設計と詳細設計の丁度中間位に位置づけされるものを作成している.
11.2
MVC とは
ソフトウェア設計モデルの一つで, ロジックの中核を担う Model, 画面などへの出力を担
当する View, Model と View の橋渡しを行う Controller の頭文字を取った言葉である. 元々,
Smalltalk における GUI アプリケーションの設計方針として生まれたが, 最近では J2EE など
によるエンタープライズシステムの開発などにも適用されている.
第 11 回
46
設計
それぞれの役割を明確にすることで分業の容易さや独立性が高まり, 変更に強く保守性の高
いシステムが構築できるという特長がある.
今回のシステムでは Model 層を更に二階層 (ビジネスロジック層とデータベースへのアク
セス層) に分けた四層構造を取っている.
図 11.1: MVC と本システムの対応図．
11.3
詳細設計書項目説明
画面遷移図
機能毎の画面の遷り変わりを図で表したもの. 機能全体としてどの様な画面構成になって
いるか, またどの様な契機で画面が遷移していくのかを把握出来る.
画面レイアウト
個々の画面についてレイアウトを記したもの. 各画面のイメージを伝えることが出来る.
項目説明
個々の画面について, 画面内に存在する項目とそのフォーマット等を記述することにより,
画面レイアウトだけでは伝わりにくい部分を補足する.
イベント一覧
画面から起こるイベントの一覧. イベントの起こる契機とその概略を記述する.
11.4. モデル設計書項目説明
47
シーケンス図
画面から起こるイベント毎に, 後述するイベント/BL/DAO/モデル間のメッセージの流れ
を時系列に沿って表現する. 各イベントの大まかな処理の流れが確認できる
イベント概要
イベント毎にコントローラ部分が担当するロジックの内容を記述する. コントローラが担
当するのは, 画面入力値の授受及びチェック. ビジネスロジックの選択と起動など.
BL(ビジネスロジック) 一覧
イベントから起動されるビジネスロジックの一覧. 対応するメソッド名とその引数及び戻
り値など, BL のインタフェースを記述する.
BL 概要
ビジネスロジック毎に処理内容を記述する. 基本的にはトランザクションを基礎とする不
可分な一連の処理を一 BL として定義する.
11.4
モデル設計書項目説明
システムで出現するデータをオブジェクト指向の観点から構築したもの.
インタフェース一覧
各モデルのメソッド一覧の内, 単純なアクセサメソッド (属性値に対するアクセス用メソッ
ド) 以外の一覧. 対応するメソッド名とその引数及び戻り値など, モデルのインタフェースを
記述する.
機能概要
メソッド内の処理内容を記述する.
第 11 回
48
11.5
設計
DAO 設計書項目説明
モデルデータに対する取得, 更新などの操作を行うためのオブジェクト. 今回のシステムで
は永続化されたデータ (データベースのレコード) に対するアクセスは全て DAO を通して行
われる. モデル (オブジェクト指向の観点から構築) とテーブル (リレーショナルデータベース
の観点から構築) の差異吸収もここで行う.
インタフェース一覧
各 BL やモデルがアクセスする際のメソッド名や引数などを記述する.
機能概要
各メソッド内の処理内容を記述する. 基本的にはデータベースへアクセスしてデータを取
得, 取得内容を各モデル型へ変換して返却, となる.
49
第 12 回
12.1
開発・テスト
テストフェーズ
目的と位置付け
テストではメイク (製造) 工程で作成されたプログラムが仕様通りに動作するかどうかをチェッ
クする. そしてちゃんと確認されたかどうかの証左としてチェックリスト等を残す. チェック
項目は各段階での仕様書を基に作成されるため, リストも設計と同様の流れで作成されること
になりテスト自体もその流れに沿って行われる. 具体的には
• 詳細設計−ユニットテスト
• 機能設計−結合テスト
• 基本設計−システムテスト
が対応づけられる.
この他, 性能要件を満たしているか検証する性能テスト・過負荷状態での動作を確認する負
荷テスト・実環境でエンドユーザによって動作するか検証する運用テストなどがある.
ブラックボックステストとホワイトボックステスト
ブラックボックステストとは, プログラムの内部構造を無視し, 入出力の部分にのみ着目し
て行われるテストである. 同値分割や限界値分析などがあり, 様々な入力に対して仕様通りの
出力が行われるかを確認する.
ホワイトボックステストとは, ブラックボックステストとは対照的にプログラムの内部構造
に着目して行われるテストである. 命令網羅や判定条件網羅などがあり, 基本的には作成した
プログラムの全ルートを最低一回は実行するものである.
第 12 回
50
開発・テスト
トップダウンテストとボトムアップテスト
トップダウンテストとは, 上位モジュールから下位モジュールへと順に結合していくテスト
である. スタブと呼ばれるダミーの下位モジュールを用意し, 上位モジュールに問題がなけれ
ば順次 (ユニットテストの終了した) 本物のモジュールと入れ替えていくことで最下位モジュー
ルまでをテストする. 機能仕様に係わってくる上位モジュールを先にテストするため, 機能漏
れや仕様間違いなど中核部分に対するエラーを早期に発見出来る利点がある.
ボトムアップテストとは, 下位モジュールから上位モジュールへと順に結合していくテスト
である. スタブに対してダミーの上位モジュールのことをドライバと呼ぶ. 下位モジュールは
数が多く独立性が高いため, 開発とテストの平行作業に向いているといった利点がある.
12.2
ユニットテスト
目的
メソッドや関数などの単位で行うテストである. 仕様上取り得る値の範囲内 (正常値) だけ
でなく, 境界値や範囲外 (異常値) に対しても確認を行う必要がある.
最近ではテストツール等も出回っており, ある程度自動化することが可能となってきてい
る. 自動化によりテスト時間が短縮されるだけでなく, 修正等が発生した場合の再テスト時の
テストケース漏れも防ぐことができる.
チェック項目の作成
詳細設計書を基にチェック項目を洗い出す. 前述の通り, 正常時だけでなく異常時に対する
動作も確認する必要がある.
図 12.1: 単体チェック項目．
12.2. ユニットテスト
51
検証用スタブ・ドライバの作成
テスト対象となっているクラスをコールするドライバや, ソース内でコールしているメソッ
ド等のスタブを作成する.
例として「HatchuDaoImple.java」のテストを取り上げる. 今回は以下の理由からスタブを
用意せずドライバ兼確認用ページとして JSP を用意した.
• 共通的なユーティリティ群は既に存在していたこと
• Tomcat から JNDI 経由で DB 接続を利用していること
<%@ page language=”java” %>
<%@ page contentType=”text/html; charset=UTF-8” %>
<%@ page import=”java.util.*” %>
<%@ page import=”jp.co.knc.ossmc.common.util.*” %>
<%@ page import=”jp.co.knc.ossmc.dao.*” %>
<%@ page import=”jp.co.knc.ossmc.dao.factory.*” %>
<%@ page import=”jp.co.knc.ossmc.exception.*” %>
<%@ page import=”jp.co.knc.ossmc.model.*” %>
<%@ page import=”jp.co.knc.ossmc.view.form.FormBean” %>
<%@ page import=”jp.co.knc.ossmc.view.form.odr.*” %>
<%@ page import=”jp.co.knc.ossmc.view.form.rcv.*” %>
<%@ page import=”jp.co.knc.ossmc.view.form.slp.*” %>
<%@ page import=”jp.co.knc.ossmc.view.form.smt.*” %>
<%@ page import=”jp.co.knc.ossmc.view.form.stk.*” %>
<html>
<body>
<%
/**
* 単一情報の取得が正しく行われていること
*/
JuchuDao jd1 = DaoFactory.getFactory(Constant.DAO TYPE).getJuchuDao();
Juchu j1 = jd1.getJuchuData(”4”);
jd1.close();
%>
<div>
<p>単一情報の取得が正しく行われていること</p>
<table>
<tr>
<th>コード</th>
<td><%= j1.getJuchuCode() %></td>
</tr>
<tr>
<th>ステータス</th>
<td><%= j1.getJuchuState() %></td>
</tr>
<tr>
<th>受注日</th>
<td><%= j1.getJuchuDate() %></td>
</tr>
<tr>
第 12 回
52
開発・テスト
<th>受注額</th>
<td><%= j1.getJuchuGaku() %></td>
</tr>
<tr>
<th>得意先発注コード</th>
<td><%= j1.getTokuisakiHatchuCode() %></td>
</tr>
<tr>
<th>出荷日</th>
<td><%= j1.getShukkaDate() %></td>
</tr>
</table>
</div>
<%
/**
* バージョン NO の一致しない情報を更新しようとすると例外がスローされること
*/
JuchuDao jd2 = DaoFactory.getFactory(Constant.DAO TYPE).getJuchuDao();
Juchu j2 = jd2.getJuchuData(”4”);
j2.setVersionNo(j2.getVersionNo()+1); // 無理矢理バージョン No を変更
boolean judge2 = false;
try
jd2.updateJuchuData(j2);
catch(Exception ex)
judge2 = true;
finally
jd2.close();
%>
<div>
<p>バージョン NO の一致しない情報を更新しようとすると例外がスローされること</p>
<%= judge2 %>
</div>
</body>
</html>
テストの実施
実際に Tomcat を起動しドライバ兼確認用ページへアクセス, 結果を目視にて確認する.
12.3
結合テスト
目的
ユニットテストが終了したプログラム同士を組合わせて行うテストである. 主に各機能に
着目したテストを行うため, ユーザの入力情報や操作に対する結果が正しいかを確認する.
12.4. システムテスト
53
チェック項目の作成
機能設計書を基にチェック項目を洗い出す (今回のシステムでは詳細設計書). 例として「注
文書発行」のテストを取り上げる. 関係する DAO やモデルは前述の通りユニットテストを行
うが, 画面周りは以下の理由からユニットテスト兼結合テストとしてここで纏めてテストを
行う.
• Service や Action は機能単位で製造担当をアサインしたこと
• より下位のモジュール (DAO やモデル) が先行して製造されていたこと
テストの実施
実際に Tomcat を起動し各機能へアクセス, 結果を目視にて確認しチェックする.
12.4
システムテスト
目的
結合テストが終了した機能同士を結びつけ, システム全体として正しく動作するかに着目し
たテストである. 運用の流れに沿って各機能を網羅し, システムが仕様通りに動作するかを確
認する.
チェック項目の作成
データの生成から最終的に到達する状態までの遷移を, 手順 (シナリオ) として作成する. 入
力データによってフローが変化する場合は, それぞれのフローを網羅できる形にする.
テストの実施
実際に Tomcat を起動し各機能へアクセス, 結果を目視にて確認しチェックする.
第 12 回
54
開発・テスト
図 12.2: 結合チェック項目/発注一覧画面．
12.5
不具合
バグとデバック
各段階でのテストを行っているとプログラムが仕様通りに動作しなかったり突然エラーで
終了したりといったことが起こる. その様な不具合のことをバグといい, プログラムの修正を
行ってバグを取り除く行為をデバックという. テストの実行者は不具合を発見すると不具合
報告書をあげ, 報告書を基にプログラム修正を行っていくことになる. 報告書でバグを管理す
ることにより, 類似するバグを発見したり, デバックすることによって新たにバグが発生した
12.5. 不具合
55
図 12.3: 結合チェック項目/注文書発行画面．
図 12.4: システムチェック項目．
場合の対処に役立つ.
第 12 回
56
図 12.5: 不具合報告書．
開発・テスト
12.5. 不具合
57
システム設計 II
59
第 12 回 OSS の開発サイクル・種類・ライ
センス
12.1
OSS の開発サイクル
現在のソフトウェア開発は，分散開発環境が主流となっている．ソフトウェアの開発環境
の変化として，開発言語の変化やネットワーク技術の進歩に伴うホスト集中型開発環境から
分散開発環境への変化の歴史について紹介する．また，分散開発環境を採用した代表的な成
功例としてオープンソースプロジェクトがある．オープンソースプロジェクトの下で開発さ
れた OSS は，現在，企業組織においても積極的に導入する動きが活発化しており，その現状
について開発サイクル・OSS の種類，ライセンス問題を含めて紹介する．
まず，OSS の開発サイクルを図 5.1 に示す．さらに，従来のウォーターフォール型の開発
モデルを図 12.2 に示す．OSS の開発サイクルは，開発者が開発を行い，オープンソースプロ
ジェクトの Web サイトへアップロードし，ユーザがダウンロード可能な状態にする．公開さ
れた OSS は，ユーザによりダウンロードされる．ユーザが使用している間に不具合が発見さ
れるとバグトラッキングシステム上へ障害内容が報告される．開発者はバグトラッキングシ
ステム上へ登録された障害内容に基づいてソースコードを修正するというサイクルが繰り返
されることにより，雪だるま式に開発が進められていく．また，従来から知られており，典型
的かつ古典的なソフトウェア開発モデルとしてウォーターフォール型のソフトウェア開発モ
デルがある．これは，要求仕様定義の段階でユーザからの要求を吸い上げ，ユーザ要求を満
たすような設計段階へと移る．設計段階においては，成果物として設計書が作成される．設
計工程が終了すれば，コーディング作業が開始される．ある程度の要求を満たす成果物が完
成すればテストが行われる．テスト工程では，単体テスト・統合テスト・総合テストと，ソ
フトウェアの部品化に応じて実施される．テスト工程で一定の品質が確保されれば，ソフト
ウェアがユーザに引渡され，運用・保守段階に入る．
演習：上述したように，OSS の開発サイクルと，従来のウォーターフォール型の開発モデ
ルには，大きな違いがある．その違いを説明せよ．
演習：これまでのソフトウェア開発モデルには，ウォーターフォールモデル以外にも，ス
パイラルモデル，プロトタイプモデル，インクリメンタルモデルなど，様々な開発モデルが
第 12 回 OSS の開発サイクル・種類・ライセンス
60
図 12.1: OSS の開発サイクル．
図 12.2: ソフトウェアのウォーターフォール型開発モデル．
存在する．この中から，OSS の開発形態に近いものを挙げ，その理由を説明せよ．
12.2
OSS の種類
一般的に，ソフトウェアの種類としては，大きく分けてアプリケーションソフトウェア，サー
バソフトウェア，組込みソフトウェアと分類することができる．現在，世界中に数多くの OSS
が開発・公開されている．その中でも代表的なものとして，以下のものが挙げられる．
オープンソースソフトウェア
Firefox, Fedora, OpenOffice, Apache, Android, MySQL, Samba, Thunderbird, Sunbird,
Chrome, BusyBox.
12.3. OSS のライセンス
61
演習：上述した OSS について Web サイトから調査し，OSS を 20 以上挙げよ．さらに，調
査した OSS をアプリケーションソフトウェア，サーバソフトウェア，組込みソフトウェアに
分類せよ．
演習：調査した OSS に対応し，同じ機能を有した商用ソフトウェアを挙げよ．
演習：OSS と商用ソフトウェアの特徴について説明せよ．
12.3
OSS のライセンス
OSS には，様々なライセンス形態が存在する．その代表的なものとしては，以下のものが
挙げられる．
• GPL（GNU General Public License）
プログラムにはソースコードを含んだ形で配布しなければならず，配布の際にはライセ
ンス料などが含まれていてはならない．利用者や分野に対して差別してはならず，再配
布は誰でも自由に行うことができる（その他詳細はライセンス文書を参照）．
• LGPL（GNU Lesser General Public License）
これは，上述の GPL の条項を緩やかにしたものであり，主に，ライブラリ・モジュー
ルなどのリンクする形態に対して適用しやすくしたものである．
• BSD ライセンス
主な特徴として，BSD のライセンスに従うソースコードを利用して，改変または複製
して作成されたものをソースコードを公開しないで配布できるという点である．そのた
め，利用者にとっては利用しやすいライセンス形態である．
• その他
X11 License，Apache Software License など，多数のライセンスが存在する．
演習：上述したライセンス以外について，Web サイトから調査し 3 つ挙げよ．さらに，調
査した 3 つのライセンスの利点と欠点を述べよ．
例 1）あるライセンスに従った OSS を利用して，別のソフトウェアを開発した場合，そのソー
スコードは公開する必要があるのかどうか．
例 2）あるライセンスに従った OSS を修正し，新たなソースコードを追加したものを製品と
して販売することは可能かどうか．
63
第 13 回 OSS 導入における問題点
近年，EU 加盟国や米国を中心として OSS 採用の動きが活発化している．特に，OSS を採
用する意欲はあるものの，その導入に踏み切れない企業が少なからず存在するのは事実であ
る．OSS 導入における問題点について紹介する．具体的には，OSS 導入の妨げとなっている
品質上の問題に焦点を当てることにより説明する．上述した問題点を認識した上で，これら
の問題が発生する経緯について，OSS の開発サイクル上の問題点を含めて紹介する．
13.1
品質上の問題
OSS はサーバ用途を主として，多くの分野において使用されている．OSS は，世界中の誰
もが開発に参加でき，ソースコードが公開され，誰でも自由に改変可能なソフトウェアであ
ることから，最近では組込みシステムやサーバ用途として広く採用され，急激に普及が広まっ
ている [2, 3]．また，オープン規格や OSS を利用することによって，電子行政機関がプライバ
シーや個人の自由を保護するとともに，市民が電子政府と情報をやり取りできるようにするの
に役立つことから，EU 加盟国を中心に欧米においても政府関係機関が OSS を支持する動きが
広がっている [4]．最近の OSS の傾向として，組込み機器に対しても Android[5] や BusyBox[6]
に代表される組込み OSS が積極的に採用されつつある．
一方，OSS の利用に関しては，未だに多くの不安が残されている．まず第 1 に，システム
導入後のサポートや品質上の問題といった利用者側の一般的な不安である．第 2 に，OSS は
本当にビジネスになるのか，オープンソースのソフトウェアを事業化することによって自社
製のソフトウェア商品までが市場を失うことにならないか，といった開発者側の不安である
[4]．特にサポートや品質上の問題については，OSS の普及を妨げる大きな要因として考えら
れており，組込み OSS に関しては不安材料の大きな要因の 1 つとして考えられる．
演習：OSS の普及を阻害する要因として品質上の問題が挙げられている．OSS の開発サイ
クルと従来のウォーターフォール型の開発モデルとの違いと関連付けることにより，OSS の
普及を阻害する原因について説明せよ．
第 13 回
64
13.2
OSS 導入における問題点
品質問題解決のためのテスト進捗度管理技術
こうした品質上の問題を改善するための技術として，テスト進捗度管理技術がある．従来
から，ソフトウェア製品の開発プロセスにおけるテスト進捗管理や出荷品質の把握のための
信頼性評価を行うアプローチとして，ソフトウェア故障の発生現象を不確定事象として捉え
て確率・統計論的に取り扱う方法がとられている．その代表的かつ古典的モデルの 1 つとし
て，ハザードレートモデルがある [1, 13, 14, 15, 16]．典型的なハザードレートモデルを以下
に示す．
Schick–Wolverton(S-W) model:
zk (x) = φ(N − k + 1)x
√
φ
E[Xk ] =
.
2(N − k + 1)φ
(N > 0, φ > 0; k = 1, 2, · · · , N ),
(13.1)
(13.2)
Jelinski–Moranda(J-M) model:
zk (x) = φ(N − k + 1)
1
E[Xk ] =
.
φ(N − k + 1)
(N > 0, φ > 0; k = 1, 2, · · · , N ),
(13.3)
(13.4)
Moranda model:
zk (x) = Dck−1
1
E[Xk ] =
.
Dck−1
Xie model:
(D > 0, 0 < c < 1; k = 1, 2, · · ·),
(13.5)
(13.6)
13.2. 品質問題解決のためのテスト進捗度管理技術
65
zk (x) = λ0 (N − k + 1)α
(N > 0, λ0 > 0, α ≥ 1; k = 1, 2, · · · , N ),
1
E[Xk ] =
.
λ0 (N − k + 1)α
(13.7)
(13.8)
上述したハザードレートモデルに対する各パラメータを以下に示す．
N
φ
D
c
λ
α
:
:
:
:
:
:
ソフトウェア内に潜在する総固有フォールト数,
固有フォールト 1 個当りのハザードレート,
1 番目のソフトウェア故障に対する初期ハザードレート,
ハザードレートの減少係数,
α を考慮した残存フォールト 1 個当りのハザードレート,
定数パラメータ.
OSS の信頼性評価に関する特徴として，サーバおよびアプリケーションソフトウェアにつ
いては信頼度成長曲線に関して一定の傾向を示すものが多いが [7, 8]，組込みソフトウェアに
ついては，ハードウェアに依存するコンポーネントが含まれていることから，信頼性を評価
することが難しくなってくる．
また，従来から SRGM による方法がとられている．中でも非同次ポアソン過程（nonhomo-
geneous Poisson process，以下 NHPP と略す）モデルは，実利用上極めて有効でありモデル
の簡潔性が高いゆえにその適用性も高く，実際のソフトウェア信頼性評価に広く応用されて
いる．
演習：SRGM とハザードレートモデルの違いについて説明せよ．
演習：ソフトウェアが無ければただの箱と言われているように，組込み製品についても，製
造・生産する上で，組込みソフトウェアの果たす役割は大きい．従来の組込みソフトウェア
と，組込み OSS との違いについて説明し，組込み OSS を利用することによる利点と欠点につ
いてレポートとしてまとめよ．
67
第 14 回
14.1
組込み OSS の課題
組込み OSS の現状
様々な種類の OSS が世界中で開発・公開されている．その種類は，アプリケーションレベ
ルから，サーバ，OS，組込み関係まで様々である．特に，組込み OSS は近年注目されており，
組込み製品の開発上の問題点として，従来から単納期・開発コストの問題が指摘されていた．
こうした問題点を改善する目的で組込み OSS の採用の動きが活発化している．しかしながら，
OSS 採用には様々な問題点が存在する．一例として，自社で開発された基盤上に組込み OSS
を導入する工程であるポーティング作業における問題点等について紹介する．
OSS は，世界中の誰もが開発に参加でき，ソースコードが公開され，誰でも自由に改変可
能なソフトウェアであることから，最近では組込みシステムやサーバ用途として広く採用さ
れ，急激に普及が広まっている．特に，最近の OSS の傾向として，組込み機器に対しても
Android[5] や BusyBox[6] に代表される組込み OSS が積極的に採用されつつある．
こうした組込み機器への OSS 導入の動きとしては，最近の代表的なものとして携帯電話用
OS として知られる Android[5] がある．その他にも，Linux や TRON などのプロジェクトが
存在する．こうした組込み OSS は，近年，急速に普及しつつある．しかしながら，実際の製
品への採用は進んでいないという現状もある．
演習：代表的な組込み OSS を 3 つ挙げよ．さらに，その組込み OSS の特徴を示せ．
14.2
移植作業
組込み製品を開発する上での特徴として，短納期，開発コストの削減という大きな目標が
ある．現在の市場では，いかに新製品を素早く市場に送り出すかということに焦点が当てら
れており，こうした消費者からのニーズに応えることが非常に重要な点の一つとして挙げら
れる．さらに，組込み製品を開発していく上で不可欠となってくるのが，採算性の問題であ
る．いくら市場に製品を素早く投入できても，開発に伴なうコストが多大なものとなってし
まい，採算がとれなければ企業にとっては無意味なものとなってしまう．
上述した問題点を解決する手段として利用できるのではないかという意味で，組込み OSS
68
第 14 回 組込み OSS の課題
図 14.1: ポーティングのイメージ図．
が近年注目を集めている．組込み OSS を利用すれば，一からソースコードを書いてソフトウェ
アを開発する必要もなく，既に標準化されているソフトウェアを搭載するだけで済むことか
ら，納期の短縮につながるだけでなく，開発労力の削減と同時に，開発コストの削減にも結
びつく．こうした背景から，組込み OSS を自社で開発した基盤上に搭載する移植作業という
動きが活発化してきた．このような移植作業をポーティングという．ポーティングとは，あ
る特定の用途のために開発された組込みシステムに対して，ある特定の用途のために開発さ
れたソフトウェアを，その組込みシステム上で動作するように修正および再構築するための
作業である．図 14.1 に Android OS を例にとったポーティング作業のイメージ図を示す．
しかしながら，図 14.1 のように，組込み OSS のポーティングにおいては，問題点が指摘され
ている．すなわち，自社で開発されたハードウェアは，各開発企業ごとに様々であり，Android
向けに標準化されたハードウェアのみを使用していれば大きな問題は発生しないが，その製
品独自のハードウェア構成であれば，そのハードウェア向けのデバイスドライバを新たに開
発する必要がある．さらに，そのデバイスドライバが組込み OSS 上で正常に動作するかどう
かを検証する必要も出てくる．また，組込み OSS 自体が，基板上で正常に動作するかを検証
する作業も必要となってくる．こうした様々な検証を，図 14.1 に示すような移植作業工程で
行う必要が出てくる．こうした問題には，他社とは異なるユニークな機能をもった製品を市
場に投入しなければ，組込み製品の市場で生き残ることが出来ないという背景がある．また，
OSS に関する知識をもった技術者が不足しているという問題も存在している．
演習：ポーティングとは何か，自分の言葉で具体的に説明せよ．
演習：日本の携帯電話市場はガラパゴス市場と言われている．ガラパゴス市場とは何か説
14.3. その他の問題
69
明せよ．
演習：日本の携帯電話会社について調査し列挙せよ．さらに，調査した携帯電話会社から，
組込み OSS を採用した携帯電話を生産しているものを調査し，その携帯電話会社名と携帯電
話のモデル名を列挙せよ．
14.3
その他の問題
組込み OSS を扱う上での問題点としては，以下のものが挙げられる．
• 技術者の不足
• 品質上の問題
• サポートの問題
• 多数のバージョンが存在することに対する依存性の問題
• ライセンスの問題
技術者の不足，品質上の問題，サポートの問題については，既に紹介した通りである．そ
の他にも，組込み OSS を扱う上での問題として，依存性の問題やライセンス上の問題がある．
まず，組込み OSS に限らず，OSS について考えた場合，OSS は常にバージョンアップを通し
て魅力的品質が向上する．また，OSS 開発では，開発者のみがソースコードを書き換えるだ
けではなく，ときにはユーザも開発者としてソースコードを書き換えることも可能である．す
なわち，ユーザは開発者にもなり，開発者はユーザにもなるという状態にある．これは，異
なるバージョンの OSS で，それぞれの機能が似ていても，ソースコードレベルでは全く別の
振る舞いをする OSS である可能性もあり，同じ内容であるにも関わらず互換性の無い改変が
行われてしまうと，数種類のバージョンが出来てしまうことになる．このような複数のバー
ジョンの存在する可能性は，ユーザだけではなく開発者にとっても非常に大きな問題となる．
また，ライセンス上の問題から，組込み OSS の採用を見送っているケースも少なくない．
これまでにも扱ってきたが，OSS には様々なライセンス形態が存在する．そのライセンス内
容については，商用製品として利用することが難しいケースもある．特に，利用し改変した
ソースコードの公開を義務付けるものになると，企業機密的な内容も公開せざるを得なくな
り，企業にとっては納期短縮やコスト削減のために利用した OSS が，逆に納期に間に合わず
コスト超過に陥ってしまう側面もある．
演習：OSS を，組込み製品，ソリューション製品，パッケージソフトウェア等に利用する
際における利点・欠点および注意すべき点について，レポートとしてまとめよ．
71
謝辞
本テキストは，IPA（独立行政法人 情報処理推進機構）の第 3 回 OSS モデルカリキュラム
導入実証事業の一環として作成されたものである．
73
参考文献
[1] 山田 茂, ソフトウェア信頼性モデル−基礎と応用−, 日科技連出版社, 東京, 1994.
[2] The Apache HTTP Server Project, The Apache Software Foundation,
http://httpd.apache.org/
[3] Mozilla.org, Mozilla Foundation, http://www.mozilla.org/
[4] ソフトウェア情報センター研究会報告書, オープンソースソフトウエアの利用状況調査／
導入検討ガイドラインの公表について, 東京, 2004.
[5] Open Handset Alliance, Android, http://www.android.com/
[6] Erik Andersen, BUSYBOX, http://www.busybox.net/
[7] 田村慶信, 山田茂, 木村光宏, “オープンソース共同開発環境に対するソフトウェア信頼
性評価法に関する考察,” 電子情報通信学会論文誌，vol．J88–A，no．7，pp．840–847,
2005．
[8] Y. Tamura and S. Yamada, “A Method of User-oriented Reliability Assessment for Open
Source Software and Its Applications,” Proceedings of the 2006 IEEE International Conference on Systems, Man, and Cybernetics, Taipei, Taiwan, Oct. 8–11, 2006, pp. 2185–
2190.
[9] L. Arnold, Stochastic Differential Equations–Theory and Applications, John Wiley &
Sons, New York, 1974.
[10] E. Wong, Stochastic Processes in Information and Systems, McGraw–Hill, New York,
1971.
[11] S. Yamada, M. Kimura, H. Tanaka, and S. Osaki, “Software reliability measurement
and assessment with stochastic differential equations,” IEICE Trans. Fundamentals, vol.
E77-A, no. 1, pp. 109-116, Jan. 1994.
第 14 回 組込み OSS の課題
74
[12] Fedora Project, sponsored by Red Hat. [Online]. Available: http://fedora.redhat.com/
[13] G.J. Schick and R.W. Wolverton, An Analysis of Competing Software Reliability Models,
IEEE Trans. Reliability Engineering, SE–4 (2), pp. 104–120, 1978.
[14] Z. Jelinski, P.B. Moranda, Software Reliability Research, in Statistical Computer Performance Evaluation, Freiberger, W.(ed.), pp. 465–484, Academic Press, New York, 1972.
[15] P.B. Moranda, Event–altered Rate Models for General Reliability Analysis, IEEE Trans.
Reliability, R–28 (5), pp. 376–381, 1979.
[16] M. Xie, On a Generalization of the J-M Model, Proc. Reliability ’89, 5 Ba/3/1–5 Ba/3/7,
1989.
[17] (1)IT-用語辞典 (http://e-words.jp/w/e-business.html)
75
ライセンス
※この著作物は、「クリエィティブ・コモンズ・ ライセンス 表示 2.1 日本」により、
ケイ・エヌ情報システム株式会社、山口大学から利用許諾されています。
詳しい利用許諾条項は、http://creativecommons.org/licenses/by/2.1/jp/legalcode をご覧下さい。