Disciplined Software Engineering Lecture #11

1. Disciplined Software Engineering Lecture #11 • Software Engineering Institute • Carnegie Mellon University • Pittsburgh, PA 15213 • Sponsored by the U.S. Department of Defense

2. Lecture #11 概要 • 個人的ソフトウエアプロセスの拡張 • 拡張性の原則 • ソフトウエアの複雑さの取り扱い • 開発戦略 • 循環的PSP • ソフトウエアインスペクション（現在はＰＳＰ２）

3. 拡張性とは何か? • 製品開発プロセスは使用される方法と技法が、より大規模なプロジェクトに対しても同様にうまく働く時、拡張可能である。 • 拡張性は典型的には以下である。 • 製品規模の狭い範囲を越えて適用される • 類似のアプリケーション領域に限定される • 先例のないシステムには適用しない • 管理が貧弱なプロジェクトには働かない • 技術作業に規範がないところで適用される事はありそうにない。

4. 拡張性の原則 • 拡張性が可能であるためには、より大きなﾌﾟﾛｼﾞｪｸﾄの要素は小さなﾌﾟﾛｼﾞｪｸﾄと同じ様に振る舞う事が必要である。 • したがって製品設計はそのﾌﾟﾛｼﾞｪｸﾄをそれぞれ分割開発される要素に分けなければならない。 • これは開発ﾌﾟﾛｾｽは個人が効率的に開発できるﾌﾟﾛｼﾞｪｸﾄのｽｹｰﾙ（規模）を考慮に入れることを要求する。

5. 拡張性のｽﾃｰｼﾞ • 我々はｿﾌﾄｳｴｱｼｽﾃﾑを５つの拡張性ｽﾃｰｼﾞに分類されるものとして見る事が出来る。 • これらの拡張性ｽﾃｰｼﾞは以下のようになる： • ｽﾃｰｼﾞ 0 - 単純ルーチン • ｽﾃｰｼﾞ 1 - プログラム • ｽﾃｰｼﾞ 2 - コンポーネント • ｽﾃｰｼﾞ 3 - システム • ｽﾃｰｼﾞ 4 - 複合システム

6. 拡張性ｽﾃｰｼﾞ 0 • ｽﾃｰｼﾞ 0 は基本的な構成物レベルである。これはループ、ｃａｓｅ文、などの構築に関係する。 • ｽﾃｰｼﾞ ０ はﾌﾟﾛｸﾞﾗﾐﾝｸﾞ入門コースの主要な焦点である。 • ｽﾃｰｼﾞ 0では, 各ﾌﾟﾛｸﾞﾗﾐﾝｸﾞ構成物を意識して設計する。 • あなたの思考がこれらの詳細に没頭している時には、より大きな構成物を思い浮かべる事は難しい。

7. 拡張性ｽﾃｰｼﾞ 1 • ｽﾃｰｼﾞ１は数百ＬＯＣまでの小規模ﾌﾟﾛｸﾞﾗﾑに関係が ある。 • ｽﾃｰｼﾞ０からｽﾃｰｼﾞ１への移行は言語に習熟してくれば自然に起こる。あなたは今や小規模ﾌﾟﾛｸﾞﾗﾑをその詳細な構成物を意識的に設計することなしに一つの実体として考える。 • あなたがｽﾃｰｼﾞ１で経験を得るのにしたがって、あなたが理解し、自信を持って使う事が出来る小規模プログラム機能を表す語嚢を増やしていく。

8. 拡張性ｽﾃｰｼﾞ 2 • ｽﾃｰｼﾞ2はｺﾝﾎﾟｰﾈﾝﾄレベルである。ここで、複数のﾌﾟﾛｸﾞﾗﾑが結合され高度な機能を提供する。ｽﾃｰｼﾞ２のｺﾝﾎﾟｰﾈﾝﾄは典型的には数千LOCである。 • ｽﾃｰｼﾞ１からｽﾃｰｼﾞ２への移行は経験の増加に伴って起こる。今や一人で多分作成できるﾌﾟﾛｸﾞﾗﾑよりも大規模なﾌﾟﾛｸﾞﾗﾑについて考えることが出来る。 • ｽﾃｰｼﾞ２では, システム問題：すなわち品質、性能、使用性、などが出始める。 • （図11.1参照：知識の自覚）

9. 拡張性ｽﾃｰｼﾞ 3 • ｽﾃｰｼﾞ３のシステムは数百万LOCくらいの大きさになるかもしれない。ここで、システム問題が目立ってくる。 • ｺﾝﾎﾟｰﾈﾝﾄは協調して働かなければならない。 • ｺﾝﾎﾟｰﾈﾝﾄ部品はすべて高品質でなければならない。 • ｽﾃｰｼﾞ２からｽﾃｰｼﾞ３への移行は次のことを含む。 • ﾌﾟﾛｸﾞﾗﾑの複雑さの取り扱い • システムとアプリケーション問題を理解すること • チーム環境で働くこと　　　　　　　　　　　　　　　　　　 ｽﾃｰｼﾞ３では、主要な力点をプログラムの品質に置かねばならない。

10. 拡張性ｽﾃｰｼﾞ 4 • ｽﾃｰｼﾞ４の複合システムは数千万LOCを含むかもしれない。 • 複数の半独立システムが協調して働かねばならない • 品質は最高に重要である。 • ｽﾃｰｼﾞ３からｽﾃｰｼﾞ４への移行では集中制御についての問題のみならず大規模かつ分散したシステムの問題が起こる。 • ｽﾃｰｼﾞ４は半自主的な開発グループと自己管理するチームを要求する。

11. 拡張性条件 - 1 • 拡張可能であるためには • ﾌﾟﾛｾｽは管理されなければならない。 • ﾌﾟﾛｼﾞｪｸﾄは管理されなければならない。 • 製品は管理されなければならない。 • 管理されたﾌﾟﾛｾｽは • 定義されるべきである • その仕事を分離可能な要素に分解するべきである • これらの要素を最終システムに効果的に統合するべきである。

12. 拡張性条件 - 2 • 管理されたﾌﾟﾛｼﾞｪｸﾄに対して • 仕事は計画されねばならない • 仕事はその計画に対して管理されねばならない • 要求の変更は制御されねばならない • システム設計とシステムアーキテクチャはプロジェクトを通して一貫して継続しなければならない。 • 構成管理が使用されなければならない。

13. 拡張性条件 - 3 • 管理された製品に対しては • 欠陥は追跡され制御されなければならない • 統合とシステムテストを行わねばならない • 縮退テストは首尾一貫して使用される • 製品品質は高くなければならない • モジュール欠陥は統合とシステムテストの前に除去すべきである • モジュール品質の目的は統合とシステムテストの前に全ての欠陥を発見することであるべきである。 (すなわち、百万LOCあたり１００未満の欠陥を見逃す） 　　　　　　→１KLOCあたり０.１未満

14. 拡張性の目的 • 拡張性の目的は大規模製品を小規模製品と同様な品質と生産性で開発することである。 • 拡張性は小規模ﾌﾟﾛｼﾞｪｸﾄにおいて行われたタスクにだけ適用される。 • より大規模なﾌﾟﾛｼﾞｪｸﾄにより要求される新しいタスクは追加の作業を要求するので、生産性は一般的にジョブの規模が増加するのに伴って下降する。

15. 製品 Z ｺﾝﾎﾟｰﾈﾝﾄX ｺﾝﾎﾟｰﾈﾝﾄ Y モジュールA モジュールD モジュールG モジュールJ モジュールM モジュールＢ モジュールE モジュールH モジュールK モジュールN ﾓｼﾞｭｰﾙC モジュールF モジュールI モジュールL モジュールO 拡張性の範囲 - 1 大規模 ﾌﾟﾛｼﾞｪｸﾄ 中規模 ﾌﾟﾛｼﾞｪｸﾄ 小規模 ﾌﾟﾛｼﾞｪｸﾄ

16. 拡張性の範囲 - 2 • ﾓｼﾞｭｰﾙﾚﾍﾞﾙからｺﾝﾎﾟｰﾈﾝﾄﾚﾍﾞﾙへの拡張において • ﾓｼﾞｭｰﾙﾚﾍﾞﾙの作業の品質と生産性の維持を求める • ｺﾝﾎﾟｰﾈﾝﾄﾚﾍﾞﾙの作業は新しいので拡張が出来ない • 製品ﾚﾍﾞﾙへの拡張において • ｺﾝﾎﾟｰﾈﾝﾄﾚﾍﾞﾙ作業の品質と生産性の維持を求める • 製品ﾚﾍﾞﾙの作業は新しいので拡張が出来ない

17. 複雑さの管理 - 1 • 規模と複雑さは密接に関係している。 • 小規模ﾌﾟﾛｸﾞﾗﾑは程々に複雑であり得るが、極めて重要な問題は大規模ﾌﾟﾛｸﾞﾗﾑを扱う事である。 • ﾌﾟﾛｸﾞﾗﾑが大規模になると一般にプログラムは非常に複雑になる。

18. 複雑さの管理 - 2 • ソフトウエア開発は主として個人によって行われる。 • 個人は小規模プログラムを一人だけで書く。 • 大規模プログラムは普通複数の小規模プログラムから構成される • 以下を実施するための方法に関連した３つの問題がある。 • 高品質の小規模プログラムを開発する　 • より大きなそしてより複雑なプログラムを個人が取り扱えるようにする • これらの個人的に開発されたプログラムをより大きなシステムに組み合わせる

19. 複雑さの管理 - 3 • ソフトウェアの複雑さについての主要な問題は人間が次に関してかぎられた能力しかもっていないと言う事である。 • 詳細を記憶すること • 複雑な関係を視覚化すること • したがって我々は次第に複雑になるプログラムを個人が開発するのに役立つ方法を探し求める。 • 抽象化 • アーキテクチャ • 再利用

20. 抽象化の力 - 1 • 人間は概念的なチャンク(塊)で考える • 積極的に使えるのは7+/-２個のチャンクの範囲である。 • チャンクが豊かであれば我々の思考が強力になる。 • このことはアマチュアのチェスプレイヤーにゲーム中のチェスの駒の位置を記憶することを求めることで示された。 • 彼等は僅か5~6駒しか覚えられなかった． • エキスパートは盤全体を記憶することが出来た。 • ランダムに置かれた駒に対しては,エキスパートもアマチュアもほとんど同程度の結果になった。

21. 抽象化の力 - 2 • 以下のことが成り立てば、ソフトウエアの抽象化はこの様なチャンク(塊)を形作ることが出来る • 抽象化が精密である • 我々が完全に理解している • 考えたとおりに正しく実行する • いくつかの可能性のある抽象化は以下である • ルーチン • 標準手続きと再利用可能なプログラム • 完全なサブシステム

22. 抽象化の力 - 3 • 概念的な複雑さを減らすため, これらの抽象化は次でなければならない • 仕様化されたとおりに精密に実行する • 仕様化された以外の相互関連を持っていない • 首尾一貫しかつ自己完結的なシステム機能を　　　　概念的に表現する

23. 抽象化の力 - 4 • これらのより大きな言葉で考えるとき, 我々のシステムを精密に定義できる。 • そうするとそれらから構成される抽象化を構築することが出来る。 • これらの抽象化がシステムに結合されるとき、期待されたように働く可能性がより大きくなる。

24. 抽象化の力 - 5 • 抽象化において主要な制約になることは以下である。 • 開発者(人間)は仕様化において誤りをする • 抽象化はしばしば欠陥を含む • 多くの抽象化は特殊であり汎用性がない • このことは他人の仕事を活用することが滅多に出来ないことを意味している。 • したがって複雑なｿﾌﾄｳｴｱシステムを知覚する我々の知的能力は、われわれ自身が開発してきた抽象化によって制約される。

25. アーキテクチャと再利用 - 1 • ｼｽﾃﾑｱｰｷﾃｸﾁｬ設計は以下の理由から複雑さを減少させることが出来る • 首尾一貫した構造的な枠組みを与える • 概念的に類似な機能を識別する • ｻﾌﾞｼｽﾃﾑを明確に分離する • よく構造化されたｱｰｷﾃｸﾁｬは標準設計の利用を促進する • アプリケーションの固有事項は一番下のレベルまで決定が延ばされる • 可能なところでは、調整可能なパラメータが定義される。

26. アーキテクチャと再利用 - 2 • このことは標準化されたｺﾝﾎﾟｰﾈﾝﾄの使用を通して再利用可能性を増加させる。 • これらの精密に定義された標準ｺﾝﾎﾟｰﾈﾝﾄがそのとき概要設計の抽象化として使用できる • もしこれらのｺﾝﾎﾟｰﾈﾝﾄが高品質なら, 拡張性が達成できる可能性はより大である。

27. フィーチャオリエンテッドなドメイン分析 - 1 • ﾌｨｰﾁｬｵﾘｴﾝﾃｯﾄﾞなドメイン分析はSEIによって開発された。それはｱｰｷﾃｸﾁｬの設計手法の１つで • 概念的に類似な機能を識別する • これらの機能をｸﾗｽにカテゴリ分けする • 各ｸﾗｽに対する共通の抽象化を定義する • 可能なところではﾊﾟﾗﾒーﾀを使用する • ｱﾌﾟﾘｹｰｼｮﾝに特有な機能は後に回す • ﾌﾟﾛｸﾞﾗﾑ部品の最大限の共有を可能にする

28. フィーチャオリエンテッドなドメイン分析 - 2 • ﾌｨｰﾁｬｵﾘｴﾝﾃｯﾄﾞなドメイン分析の例は • ｼｽﾃﾑ出力機能を定義する • 最高ﾚﾍﾞﾙはﾒｯｾｰｼﾞを作成し送る • 次に低いﾚﾍﾞﾙはﾌﾟﾘﾝﾀやﾃﾞｨｽﾌﾟﾚｲなどを定義する • 次のﾚﾍﾞﾙはﾌﾟﾘﾝﾀﾌｫｰﾏｯﾃｨﾝｸﾞを取り扱う • 次のﾚﾍﾞﾙは特定のﾌﾟﾘﾝﾀﾀｲﾌﾟをｻﾎﾟｰﾄする

29. 開発戦略 - 1 • 開発戦略はｼｽﾃﾑがあまり大きすぎて１つの製品に作り込めない時要求される • その時システムを要素に分割しなければならない • それからこれらの要素を開発しなければならない • それから開発された要素は最終ｼｽﾃﾑに統合される

30. 開発戦略 - 2 • 戦略は • より小規模な要素を定義する • それらの要素が開発される順序を確立する • 要素が統合される方法を確立する • もし戦略が適切で、要素が適切に開発されるならば • 開発ﾌﾟﾛｾｽは拡張できるであろう • 開発全体は部品の和にｼｽﾃﾑ設計及び統合を加えたものである。

31. いくつかの開発戦略 • 多くの開発戦略がありうる • 目的はﾌﾟﾛｾｽの最も早い時点で主要な問題を識別するように、そのｼｽﾃﾑを逐次的に構築していく事である。 • いくつかの戦略例は以下である： • 段階的戦略 • 機能拡張戦略 • 高速ﾊﾟｽ拡張戦略 • ﾀﾞﾐｰ戦略

32. 段階的戦略 サイクル 1 In 1st モジュール Out サイクル 2 In 1st モジュール 1st 拡張 Out サイクル 3 In 1st モジュール 1st 拡張 2nd 拡張 Out 段階的戦略においては, 機能はそれらが実行される順序で開発される。このやり方は比較的単純なﾃｽﾄで済み、足場や特別なﾃｽﾄ機能はほとんど要らない。

33. 機能拡張戦略 Ist 機能拡張 3rd 機能拡張 コアシステム 4th 機能拡張 2nd 機能拡張 機能拡張においては、ﾍﾞｰｽｼｽﾃﾑを最初に構築し、それから拡張しなければならない. ﾍﾞｰｽｼｽﾃﾑが大規模になるとしばしばその開発に対して別の戦略が必要になる.

34. 1st 拡張 4th 拡張 c b d 3rd 拡張 a e h f g 2nd 拡張 高速パス拡張戦略 高速ﾊﾟｽ拡張では,高性能ﾙｰﾌﾟが最初に構築され、ﾃﾞﾊﾞｯｸﾞされ計測される。 その性能が適切であれば機能拡張が行われる。 性能がまだ仕様の範囲内にあることを保証するために各々の拡張を計測する。

35. コア システム コア システム コア システム コア システム B C B C C A 機能 A 機能 A 機能 A 機能 B 機能 B 機能 C ダミー戦略 ダミー戦略においては, システムの機能の全部または大部分をダミーコードで置き換えたコアシステムが最初に作られる。 これらのダミーは、その後開発が進むのにしたがって完全な機能に次第に置き換えられる。

36. 循環的ＰＳＰ - 1 • 循環的PSPは中規模のプログラムを開発するために循環的開発戦略を使用する枠組みを与える。 • 複数のPSP2.1のような循環的要素を含むより大規模なプロセスである。 • PSPの要求、計画立案、および事後分析ステップはプログラム全体に対し一度実行される。

37. 要求　＆　計画立案 サイクルの明確化 概要設計 詳細設計 & 設計ﾚﾋﾞｭｰ 概要設計ﾚﾋﾞｭｰ テスト開発と レビュー 循環的開発 実装とｺｰﾄﾞﾚﾋﾞｭｰ 事後分析 コンパイル 統合とシステムテスト テスト 再評価と再循環 循環的 PSP フロー 仕様 製品

38. 循環的ＰＳＰ - 2 • 概要設計はプログラムを小規模要素に分解して 開発戦略を確立する。 • そのプロセスは統合、システムテストおよびそれに続く事後分析によって終了する。 • 開発戦略は以下のような循環的ステップを決定する。 • 要素の選択 • テスト戦略 • 最終統合を不要にするかもしれない。

39. チームソフトウェアプロセス - 1 • プロジェクト規模をさらに大きくするために、典型的にはチーム開発ﾌﾟﾛｾｽが要求される。 • これは主要なプロジェクトタスクを識別する。 • これらのタスクを相互に関係づける • 開始と終了の条件を確立する • チームメンバーの役割を割当てる • チーム尺度を確立する • チームの目標と品質評価基準を確立する

40. チームソフトウェアプロセス - 2 • チームプロセスはまた個々のPSPがチームの中で関係をもつ事が出来る枠組みを与える, それは • チーム--PSPインタフェースを定義する • 標準と尺度を確立する • 何処でｲﾝｽﾍﾟｸｼｮﾝされるべきか規定する • 計画立案と報告のガイドラインを確立する • たとえPSPをもっていたとしても,ｲﾝｽﾍﾟｸｼｮﾝではチームサポートを得るように試みたほうがよい • PSPの欠陥摘出率を改善するために設計のｲﾝｽﾍﾟｸｼｮﾝを使用する事を最初に考えなさい.

41. インスペクション - 1（現在はＰＳＰ２） • インスペクションはソフトウエア品質の改善と開発時間およびコストを減少させるためにもっともコスト効率のよいテクニックとして知られている。 • インスペクションは次のことに役立つ • よりよい仕事をするよう動機づける • 効果的なチームコミュニケーションを保証する • 優れたものへのこだわりを維持する （個人的なベンチマークの設定）

42. インスペクション - 2 • インスペクションの目的は • 出来るだけ早期の時点でエラーを発見すること • 全ﾊﾟｰﾃｨｰが仕事に合意している事を保証すること • その仕事が定義された判断基準に適合している事を検証すること • 公式に仕事を完了すること • ﾃﾞｰﾀを提供すること • インスペクションは任意のｿﾌﾄｳｴｱ製品の要素に使用できる、例えば • 要求、仕様、設計、ｺｰﾄﾞ • ﾃｽﾄ資料 • 文書

43. インスペクションプロセス - 1 • インスペクションは公式に構造化されたﾌﾟﾛｾｽに従う • ﾁｪｯｸﾘｽﾄと標準がインスペクションの各ﾀｲﾌﾟに対して開発される。 • インスペクションは技術者のために技術者によって運営される。管理者は出席しない。

44. インスペクションプロセス - 2 計画立案 説明会議 準備 ｲﾝｽﾍﾟｸｼｮﾝ 会議 ﾌｫﾛｰｱｯﾌﾟ 管理者 開発者 司会者 司会者 開発者 ﾚﾋﾞｭｰ者 司会者 記録者 開発者 ﾚﾋﾞｭｰ者 司会者 開発者 ﾚﾋﾞｭｰ者

45. インスペクションプロセス - 3 • ﾚﾋﾞｭｰ者は前もって準備する. • インスペクション会議は焦点を問題の識別に置き、問題の解決には置かない. • インスペクションﾃﾞｰﾀを収集して追跡と分析のためにインスペクションﾃﾞｰﾀﾍﾞｰｽに入力する.

46. インスペクションにおける役割 - 1 • 司会者 • インスペクションﾌﾟﾛｾｽをﾘｰﾄﾞする • 焦点を問題解決よりもむしろ問題識別に置き続ける • 識別された問題が解決される事を保証する • インスペクション報告書を提出する • 開発者（その仕事をした開発者） • ﾚﾋﾞｭｰ資料を作成する • 質問に答える • 識別された問題を解決する

47. インスペクションにおける役割 - 2 • ﾚﾋﾞｭｰ者 • インスペクションｷｯｸｵﾌ会議に出席する • 前もってﾚﾋﾞｭｰ資料をﾚﾋﾞｭｰする • インスペクション会議に出席する • 識別された欠陥または他の関心のある事について問題を提起し質問する • 記録者 • 識別された問題点を文書化しそれらの解決に責任をもつ人を記録する • 全ての関連するﾃﾞｰﾀを記録する

48. 演習課題#11 • ﾃｷｽﾄの第１１章を読みなさい • PSP3を使用して、あるﾃﾞｰﾀｾｯﾄから説明変数が３つの重回帰ﾊﾟﾗﾒｰﾀと予測区間を計算するためのﾌﾟﾛｸﾞﾗﾑ　１０Aを書きなさい。t分布を計算するためにﾌﾟﾛｸﾞﾗﾑ５Aを使用しなさい。 この宿題のために３つの期間が許される。 • 付録Dにあるﾌﾟﾛｸﾞﾗﾑ仕様と付録Cにあるﾌﾟﾛｾｽ説明と報告書仕様を読んでそのとおりやりなさい。

49. 重回帰 - 1 • あなたは６ﾌﾟﾛｼﾞｪｸﾄについて以下のようなﾃﾞｰﾀをもつと仮定しよう • 要求される開発時間 • 新規LOC、再利用LOC、および修正LOC • あなたが新規ｺｰﾄﾞ６５０LOC、再利用ｺｰﾄﾞ3,000LOC、および修正ｺｰﾄﾞ155LOCをもつだろうと判断した新規ﾌﾟﾛｼﾞｪｸﾄにかかる時間を見積もりたいと仮定しよう。 • 開発時間と予測区間をどのように見積もるだろうか？

50. 重回帰 - 2 • ﾌﾟﾛｸﾞﾗﾑ# 新規 再利用 修正 時間 • w x y z • 1 1,142 1,060 325 201 • 2 863 995 98 98 • 3 1,065 3,205 23 162 • 4 554 120 0 54 • 5 983 2,896 120 138 • 6 256 485 88 61 • 合計 4,863 8,761 654 714 • 見積り値 650 3,000 155 ???