ソフトウェア工学
第五回
知能情報学部
新田直也
本日のお話
古典的なソフトウェア工学の話の残り物.
 開発工程の話:




テスト工程
保守工程
さまざまな見積もり,評価の話:

たとえば工数の見積もりが正確にできれば,スケジュー
ルの遅延も人員不足もなくなるので,ソフトウェア危機も
解消される?
ウォーターフォールモデル(復習)



要求分析(要求定義)と設計は
開発プロセスにおいて上流に
位置する.
要求定義においても,設計にお
いても,作業の結果は文書(ド
キュメント)に残される.
要求定義の結果を記した文書
を要求定義書,設計の結果を
記した文書を設計書という.
要
求
定
義
システム
要求定義
検証
ソフトウェア
要求定義
上流工程
検証
基本設計
設
計
検証
詳細設計
検証
コーディング
検証
テスト
検証
下流工程
運用保守
検証
障害と故障
ひとことでバグというが…
 エラー:
人間の(アクティビティにおける)間違い.
 障害:
エラーによってドキュメントやプロダクトに混入した間
違い.
 故障:
障害によって引き起こされる,要求に合わないシス
テムの動作.
 障害が必ずしも故障を引き起こすとは限らないこと
に注意.

不具合(障害)の原因

どの工程でも障害が混入する可能性がある.






プログラムが間違っていた.
設計が間違っていた.
要求仕様が間違っていた.
不具合の修正によって新たな障害が混入した.
バージョンアップで障害が新たな障害が混入した.
特に上流工程での障害は深刻.大きな手戻りを発
生する危険性.



要求仕様が間違っていたので仕様から作り直し.
実装不可能だったので仕様から作り直し.
実装不可能だったので設計から作り直し.
不具合修正の手順

不具合は以下のような手順で修正される.


障害識別:
どのような障害であるか,障害に起因する故障であるか
を特定するプロセス.
障害訂正,除去:
障害を除去できるようにシステムを変更するプロセス.
テストの工程


テストは部分から全体へ…(開発と逆の流れ)
単体テスト: 部品(モジュール単位でのテスト)







ブラックボックステスト
ホワイトボックステスト
結合テスト: 複数のモジュールを組み合わせたテスト
機能テスト: システムが機能的要件を満たしているか
性能テスト: システムが非機能的要件を満たしているか
受け入れテスト: 顧客を交えたテスト
設置テスト: システムを利用環境にインストールしてのテスト
保守(maintenance)とは
出荷した製品の機能拡張,不具合修正,バックログ
(backlog, 開発積み残し)の処理を行う工程.
 保守作業は開発作業より難しい?




ドキュメントが整備されているとは限らない.
開発要員が抜けてしまっている場合もある.
暗黙知が失われている.
保守の種類
修正保守:
障害に起因した問題への対応作業.多くの場合,故
障が発見されたことにより発生する.
 適応保守:
他の要素の変更に伴う変更作業.たとえば,OSの
バージョンアップへの対応など.
 改善保守:
システムのある側面(プログラムの可読性,機能の
拡張性など)を向上させるために行う変更作業.
 予防保守:
故障を未然に防ぐために行う変更作業.

レガシーシステム(legacy system)
古くから利用している既存のシステムのこと.多くの
場合,開発者は(退職などで)在籍しておらず,残さ
れているドキュメントも不十分.
 2000年問題などに代表されるように現実的には重
要な問題.
 パッチ当て(patch):

パッチとは完成したプログラムの部分的な修正のこと.稼働
中のシステムは,ダウンさせるわけに行かないため,本質的
で大規模な修正を避け不具合の発生箇所を表面的に修正
する場合が多い.これをパッチ当てという.レガシーシステム
はパッチ当ての繰り返しによって保守性が大きく損なわれて
いる場合が多い.
見積もりと評価

工数の見積もり:


工数の見積もりは,資源の割り振りとプロジェクトの実行
可能性に大きく影響するため,開発プロセスのできるだけ
早い段階で行う必要がある.
一方,早期に正確な見積もりを出すことは不確定要素が
多く困難である.
通常,工数見積もりはエキスパートの経験的な判断
に委ねられる.
 見積もりに対して,評価はプロジェクトの終了後に行
われる.

見積もりの方法

規模見積もり:

SLOC / KLOC
ソースコードの行数を指す.ほぼ作業量と比例することが知られてい
る.ただし,開発言語によって変わる.また,冗長なプログラムのサイ
ズを大きく評価してしまうという問題もある.

ファンクションポイント(function point)法
規模見積もりとして機能の複雑さを測るよう改善した方法.

工数見積もり:

COCOMO
ソースコードの予想SLOC,エンジニアの能力,要求の信頼性などか
ら工数を見積もる方法.分析,設計工程に使えない,スパイラル型や
プロトタイピング型に使えないなどの問題がある.
CMMI



プロセス成熟度評価モデル,能力成熟度評価モデル統合.
カーネギーメロン大学ソフトウェア工学研究所(CMU-SEI)
で開発.
アンケートに基づいて開発組織を5段階で評価.






レベル1:
レベル2:
レベル3:
レベル4:
レベル5:
初期
反復可能
既定義
管理下
最適化
日本での導入は見送られた.
本日のまとめ
テスト工程の内容と位置づけ.
 開発時の問題は保守の問題として現れる.
 見積もりについては今のところよい方法はない.



本質的に正確な見積もりは不可能?
ソフトウェア開発の予期不可能性.
ダウンロード

5回目