ソフトウェア工学 第五回 知能情報学部 新田直也.

Presentation on theme: "ソフトウェア工学 第五回 知能情報学部 新田直也."— Presentation transcript:

1 ソフトウェア工学 第五回 知能情報学部 新田直也

2 本日のお話 古典的なソフトウェア工学の話の残り物． 開発工程の話： さまざまな見積もり，評価の話： テスト工程 保守工程
たとえば工数の見積もりが正確にできれば，スケジュールの遅延も人員不足もなくなるので，ソフトウェア危機も解消される?

3 ウォーターフォールモデル（復習） 要求分析（要求定義）と設計は開発プロセスにおいて上流に位置する．
要求定義においても，設計においても，作業の結果は文書（ドキュメント）に残される． 要求定義の結果を記した文書を要求定義書，設計の結果を記した文書を設計書という． システム 要求定義 要求定義 上流工程 検証 ソフトウェア 要求定義 検証 基本設計 設計 検証 詳細設計 検証 コーディング 検証 テスト 検証 下流工程 運用保守 検証

4 障害と故障 ひとことでバグというが… エラー： 人間の（アクティビティにおける）間違い．
エラー： 人間の（アクティビティにおける）間違い． 障害： エラーによってドキュメントやプロダクトに混入した間違い． 故障： 障害によって引き起こされる，要求に合わないシステムの動作． 障害が必ずしも故障を引き起こすとは限らないことに注意．

5 不具合（障害）の原因 どの工程でも障害が混入する可能性がある． 特に上流工程での障害は深刻．大きな手戻りを発生する危険性．
プログラムが間違っていた． 設計が間違っていた． 要求仕様が間違っていた． 不具合の修正によって新たな障害が混入した． バージョンアップで障害が新たな障害が混入した． 特に上流工程での障害は深刻．大きな手戻りを発生する危険性． 要求仕様が間違っていたので仕様から作り直し． 実装不可能だったので仕様から作り直し． 実装不可能だったので設計から作り直し．

6 不具合修正の手順 不具合は以下のような手順で修正される． 障害識別： どのような障害であるか，障害に起因する故障であるかを特定するプロセス．
障害訂正，除去： 障害を除去できるようにシステムを変更するプロセス．

7 テストの工程 テストは部分から全体へ…（開発と逆の流れ） 単体テスト： 部品（モジュール単位でのテスト）
ブラックボックステスト ホワイトボックステスト 結合テスト： 複数のモジュールを組み合わせたテスト 機能テスト： システムが機能的要件を満たしているか 性能テスト： システムが非機能的要件を満たしているか 受け入れテスト： 顧客を交えたテスト 設置テスト： システムを利用環境にインストールしてのテスト

8 保守（maintenance）とは 出荷した製品の機能拡張，不具合修正，バックログ（backlog, 開発積み残し）の処理を行う工程．
保守作業は開発作業より難しい? ドキュメントが整備されているとは限らない． 開発要員が抜けてしまっている場合もある． 暗黙知が失われている．

9 保守の種類 修正保守： 障害に起因した問題への対応作業．多くの場合，故障が発見されたことにより発生する．
修正保守： 障害に起因した問題への対応作業．多くの場合，故障が発見されたことにより発生する． 適応保守： 他の要素の変更に伴う変更作業．たとえば，OSのバージョンアップへの対応など． 改善保守： システムのある側面（プログラムの可読性，機能の拡張性など）を向上させるために行う変更作業． 予防保守： 故障を未然に防ぐために行う変更作業．

10 レガシーシステム（legacy system）
古くから利用している既存のシステムのこと．多くの場合，開発者は（退職などで）在籍しておらず，残されているドキュメントも不十分． 2000年問題などに代表されるように現実的には重要な問題． パッチ当て（patch）： パッチとは完成したプログラムの部分的な修正のこと．稼働中のシステムは，ダウンさせるわけに行かないため，本質的で大規模な修正を避け不具合の発生箇所を表面的に修正する場合が多い．これをパッチ当てという．レガシーシステムはパッチ当ての繰り返しによって保守性が大きく損なわれている場合が多い．

11 見積もりと評価 工数の見積もり： 通常，工数見積もりはエキスパートの経験的な判断に委ねられる．
工数の見積もりは，資源の割り振りとプロジェクトの実行可能性に大きく影響するため，開発プロセスのできるだけ早い段階で行う必要がある． 一方，早期に正確な見積もりを出すことは不確定要素が多く困難である． 通常，工数見積もりはエキスパートの経験的な判断に委ねられる． 見積もりに対して，評価はプロジェクトの終了後に行われる．

12 見積もりの方法 規模見積もり： 工数見積もり：
SLOC / KLOC ソースコードの行数を指す．ほぼ作業量と比例することが知られている．ただし，開発言語によって変わる．また，冗長なプログラムのサイズを大きく評価してしまうという問題もある． ファンクションポイント（function point）法 規模見積もりとして機能の複雑さを測るよう改善した方法． 工数見積もり： COCOMO ソースコードの予想SLOC，エンジニアの能力，要求の信頼性などから工数を見積もる方法．分析，設計工程に使えない，スパイラル型やプロトタイピング型に使えないなどの問題がある．

13 CMMI プロセス成熟度評価モデル，能力成熟度評価モデル統合． カーネギーメロン大学ソフトウェア工学研究所（CMU-SEI）で開発．
アンケートに基づいて開発組織を5段階で評価． レベル1: 初期 レベル2: 反復可能 レベル3: 既定義 レベル4: 管理下 レベル5: 最適化 日本での導入は見送られた．

14 本日のまとめ テスト工程の内容と位置づけ． 開発時の問題は保守の問題として現れる． 見積もりについては今のところよい方法はない．
本質的に正確な見積もりは不可能? ソフトウェア開発の予期不可能性．