ソフトウェア工学1012

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

Download Report