jlect11

Disciplined Software
Engineering
Lecture #11
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213
Sponsored by the U.S. Department of Defense
Copyright © 1994 Carnegie Mellon University1
Lecture #11 概要
個人的ソフトウエアプロセスの拡張
•拡張性の原則
•ソフトウエアの複雑さの取り扱い
•開発戦略
循環的PSP
ソフトウエアインスペクション（現在はＰＳＰ２）
Copyright © 1994 Carnegie Mellon University2
拡張性とは何か?
製品開発プロセスは使用される方法と技法が、より大
規模なプロジェクトに対しても同様にうまく働く時、拡張
可能である。
拡張性は典型的には以下である。
•製品規模の狭い範囲を越えて適用される
•類似のアプリケーション領域に限定される
•先例のないシステムには適用しない
•管理が貧弱なプロジェクトには働かない
•技術作業に規範がないところで適用される事はあり
そうにない。
Copyright © 1994 Carnegie Mellon University3
拡張性の原則
拡張性が可能であるためには、より大きなﾌﾟﾛｼﾞｪｸﾄの
要素は小さなﾌﾟﾛｼﾞｪｸﾄと同じ様に振る舞う事が必要で
ある。
したがって製品設計はそのﾌﾟﾛｼﾞｪｸﾄをそれぞれ分割開
発される要素に分けなければならない。
これは開発ﾌﾟﾛｾｽは個人が効率的に開発できるﾌﾟﾛｼﾞｪ
ｸﾄのｽｹｰﾙ（規模）を考慮に入れることを要求する。
Copyright © 1994 Carnegie Mellon University4
拡張性のｽﾃｰｼﾞ
我々はｿﾌﾄｳｴｱｼｽﾃﾑを５つの拡張性ｽﾃｰｼﾞに分類され
るものとして見る事が出来る。
これらの拡張性ｽﾃｰｼﾞは以下のようになる：
•ｽﾃｰｼﾞ 0 - 単純ルーチン
•ｽﾃｰｼﾞ 1 - プログラム
•ｽﾃｰｼﾞ 2 - コンポーネント
•ｽﾃｰｼﾞ 3 - システム
•ｽﾃｰｼﾞ 4 - 複合システム
Copyright © 1994 Carnegie Mellon University5
拡張性ｽﾃｰｼﾞ 0
ｽﾃｰｼﾞ 0 は基本的な構成物レベルである。これはルー
プ、ｃａｓｅ文、などの構築に関係する。
ｽﾃｰｼﾞ０はﾌﾟﾛｸﾞﾗﾐﾝｸﾞ入門コースの主要な焦点である
。
ｽﾃｰｼﾞ 0では, 各ﾌﾟﾛｸﾞﾗﾐﾝｸﾞ構成物を意識して設計する
。
あなたの思考がこれらの詳細に没頭している時には、
より大きな構成物を思い浮かべる事は難しい。
Copyright © 1994 Carnegie Mellon University6
拡張性ｽﾃｰｼﾞ 1
ｽﾃｰｼﾞ１は数百ＬＯＣまでの小規模ﾌﾟﾛｸﾞﾗﾑに関係が
ある。
ｽﾃｰｼﾞ０からｽﾃｰｼﾞ１への移行は言語に習熟してくれば
自然に起こる。あなたは今や小規模ﾌﾟﾛｸﾞﾗﾑをその詳
細な構成物を意識的に設計することなしに一つの実体
として考える。
あなたがｽﾃｰｼﾞ１で経験を得るのにしたがって、あなた
が理解し、自信を持って使う事が出来る小規模プログ
ラム機能を表す語嚢を増やしていく。
Copyright © 1994 Carnegie Mellon University7
拡張性ｽﾃｰｼﾞ 2
ｽﾃｰｼﾞ2はｺﾝﾎﾟｰﾈﾝﾄレベルである。ここで、複数のﾌﾟﾛｸ
ﾞﾗﾑが結合され高度な機能を提供する。ｽﾃｰｼﾞ２のｺﾝﾎﾟ
ｰﾈﾝﾄは典型的には数千LOCである。
ｽﾃｰｼﾞ１からｽﾃｰｼﾞ２への移行は経験の増加に伴って
起こる。今や一人で多分作成できるﾌﾟﾛｸﾞﾗﾑよりも大規
模なﾌﾟﾛｸﾞﾗﾑについて考えることが出来る。
ｽﾃｰｼﾞ２では, システム問題：すなわち品質、性能、使
用性、などが出始める。
（図11.1参照：知識の自覚）
Copyright © 1994 Carnegie Mellon University8
拡張性ｽﾃｰｼﾞ 3
ｽﾃｰｼﾞ３のシステムは数百万LOCくらいの大きさになる
かもしれない。ここで、システム問題が目立ってくる。
•ｺﾝﾎﾟｰﾈﾝﾄは協調して働かなければならない。
•ｺﾝﾎﾟｰﾈﾝﾄ部品はすべて高品質でなければならない。
ｽﾃｰｼﾞ２からｽﾃｰｼﾞ３への移行は次のことを含む。
•ﾌﾟﾛｸﾞﾗﾑの複雑さの取り扱い
•システムとアプリケーション問題を理解すること
•チーム環境で働くこと
ｽﾃｰｼﾞ３では、主要な力点をプログラムの品質に置かね
ばならない。
Copyright © 1994 Carnegie Mellon University9
拡張性ｽﾃｰｼﾞ 4
ｽﾃｰｼﾞ４の複合システムは数千万LOCを含むかもしれ
ない。
•複数の半独立システムが協調して働かねばならない
•品質は最高に重要である。
ｽﾃｰｼﾞ３からｽﾃｰｼﾞ４への移行では集中制御について
の問題のみならず大規模かつ分散したシステムの問
題が起こる。
ｽﾃｰｼﾞ４は半自主的な開発グループと自己管理するチ
ームを要求する。
Copyright © 1994 Carnegie Mellon University10
拡張性条件 - 1
拡張可能であるためには
•ﾌﾟﾛｾｽは管理されなければならない。
•ﾌﾟﾛｼﾞｪｸﾄは管理されなければならない。
•製品は管理されなければならない。
管理されたﾌﾟﾛｾｽは
•定義されるべきである
•その仕事を分離可能な要素に分解するべきである
•これらの要素を最終システムに効果的に統合する
べきである。
Copyright © 1994 Carnegie Mellon University11
拡張性条件 - 2
管理されたﾌﾟﾛｼﾞｪｸﾄに対して
•仕事は計画されねばならない
•仕事はその計画に対して管理されねばならない
•要求の変更は制御されねばならない
•システム設計とシステムアーキテクチャはプロジェク
トを通して一貫して継続しなければならない。
•構成管理が使用されなければならない。
Copyright © 1994 Carnegie Mellon University12
拡張性条件 - 3
管理された製品に対しては
•欠陥は追跡され制御されなければならない
•統合とシステムテストを行わねばならない
•縮退テストは首尾一貫して使用される
製品品質は高くなければならない
•モジュール欠陥は統合とシステムテストの前に除去
すべきである
•モジュール品質の目的は統合とシステムテストの前
に全ての欠陥を発見することであるべきである。 (す
なわち、百万LOCあたり１００未満の欠陥を見逃す）
→１KLOCあたり０.１未満
Copyright © 1994 Carnegie Mellon University13
拡張性の目的
拡張性の目的は大規模製品を小規模製品と同様な品
質と生産性で開発することである。
拡張性は小規模ﾌﾟﾛｼﾞｪｸﾄにおいて行われたタスクにだ
け適用される。
より大規模なﾌﾟﾛｼﾞｪｸﾄにより要求される新しいタスクは
追加の作業を要求するので、生産性は一般的にジョブ
の規模が増加するのに伴って下降する。
Copyright © 1994 Carnegie Mellon University14
拡張性の範囲 - 1
製品 Z
大規模
ﾌﾟﾛｼﾞｪｸﾄ
ｺﾝﾎﾟｰﾈﾝﾄ X
ｺﾝﾎﾟｰﾈﾝﾄ Y
中規模
ﾌﾟﾛｼﾞｪｸﾄ
モジュールA
モジュールＢ
ﾓｼﾞｭｰﾙC
モジュールD
モジュールE
モジュールF
モジュールG
モジュールH
モジュールI
モジュールJ
モジュールK
モジュールL
モジュールM
モジュールN
モジュールO
小規模
ﾌﾟﾛｼﾞｪｸﾄ
Copyright © 1994 Carnegie Mellon University15
拡張性の範囲 - 2
ﾓｼﾞｭｰﾙﾚﾍﾞﾙからｺﾝﾎﾟｰﾈﾝﾄﾚﾍﾞﾙへの拡張において
•ﾓｼﾞｭｰﾙﾚﾍﾞﾙの作業の品質と生産性の維持を求める
•ｺﾝﾎﾟｰﾈﾝﾄﾚﾍﾞﾙの作業は新しいので拡張が出来ない
製品ﾚﾍﾞﾙへの拡張において
•ｺﾝﾎﾟｰﾈﾝﾄﾚﾍﾞﾙ作業の品質と生産性の維持を求める
•製品ﾚﾍﾞﾙの作業は新しいので拡張が出来ない
Copyright © 1994 Carnegie Mellon University16
複雑さの管理 - 1
規模と複雑さは密接に関係している。
小規模ﾌﾟﾛｸﾞﾗﾑは程々に複雑であり得るが、極めて重
要な問題は大規模ﾌﾟﾛｸﾞﾗﾑを扱う事である。
ﾌﾟﾛｸﾞﾗﾑが大規模になると一般にプログラムは非常に
複雑になる。
Copyright © 1994 Carnegie Mellon University17
複雑さの管理 - 2
ソフトウエア開発は主として個人によって行われる。
•個人は小規模プログラムを一人だけで書く。
•大規模プログラムは普通複数の小規模プログラムか
ら構成される
以下を実施するための方法に関連した３つの問題があ
る。
•高品質の小規模プログラムを開発する
•より大きなそしてより複雑なプログラムを個人が取り
扱えるようにする
•これらの個人的に開発されたプログラムをより大きな
システムに組み合わせる
Copyright © 1994 Carnegie Mellon University18
複雑さの管理 - 3
ソフトウェアの複雑さについての主要な問題は人間が
次に関してかぎられた能力しかもっていないと言う事で
ある。
•詳細を記憶すること
•複雑な関係を視覚化すること
したがって我々は次第に複雑になるプログラムを個人
が開発するのに役立つ方法を探し求める。
•抽象化
•アーキテクチャ
•再利用
Copyright © 1994 Carnegie Mellon University19
抽象化の力 - 1
人間は概念的なチャンク(塊)で考える
•積極的に使えるのは7+/-２個のチャンクの範囲であ
る。
•チャンクが豊かであれば我々の思考が強力になる。
このことはアマチュアのチェスプレイヤーにゲーム中の
チェスの駒の位置を記憶することを求めることで示され
た。
•彼等は僅か5~6駒しか覚えられなかった．
•エキスパートは盤全体を記憶することが出来た。
•ランダムに置かれた駒に対しては,エキスパートもア
マチュアもほとんど同程度の結果になった。
Copyright © 1994 Carnegie Mellon University20
抽象化の力 - 2
以下のことが成り立てば、ソフトウエアの抽象化はこの
様なチャンク(塊)を形作ることが出来る
•抽象化が精密である
•我々が完全に理解している
•考えたとおりに正しく実行する
いくつかの可能性のある抽象化は以下である
•ルーチン
•標準手続きと再利用可能なプログラム
•完全なサブシステム
Copyright © 1994 Carnegie Mellon University21
抽象化の力 - 3
概念的な複雑さを減らすため, これらの抽象化は次で
なければならない
•仕様化されたとおりに精密に実行する
•仕様化された以外の相互関連を持っていない
•首尾一貫しかつ自己完結的なシステム機能を
概念的に表現する
Copyright © 1994 Carnegie Mellon University22
抽象化の力 - 4
これらのより大きな言葉で考えるとき, 我々のシステム
を精密に定義できる。
そうするとそれらから構成される抽象化を構築すること
が出来る。
これらの抽象化がシステムに結合されるとき、期待さ
れたように働く可能性がより大きくなる。
Copyright © 1994 Carnegie Mellon University23
抽象化の力 - 5
抽象化において主要な制約になることは以下である。
•開発者(人間)は仕様化において誤りをする
•抽象化はしばしば欠陥を含む
•多くの抽象化は特殊であり汎用性がない
このことは他人の仕事を活用することが滅多に出来な
いことを意味している。
したがって複雑なｿﾌﾄｳｴｱシステムを知覚する我々の
知的能力は、われわれ自身が開発してきた抽象化に
よって制約される。
Copyright © 1994 Carnegie Mellon University24
アーキテクチャと再利用 - 1
ｼｽﾃﾑｱｰｷﾃｸﾁｬ設計は以下の理由から複雑さを減少さ
せることが出来る
•首尾一貫した構造的な枠組みを与える
•概念的に類似な機能を識別する
•ｻﾌﾞｼｽﾃﾑを明確に分離する
よく構造化されたｱｰｷﾃｸﾁｬは標準設計の利用を促進
する
•アプリケーションの固有事項は一番下のレベルまで
決定が延ばされる
•可能なところでは、調整可能なパラメータが定義され
る。
Copyright © 1994 Carnegie Mellon University25
アーキテクチャと再利用 - 2
このことは標準化されたｺﾝﾎﾟｰﾈﾝﾄの使用を通して再利
用可能性を増加させる。
これらの精密に定義された標準ｺﾝﾎﾟｰﾈﾝﾄがそのとき
概要設計の抽象化として使用できる
もしこれらのｺﾝﾎﾟｰﾈﾝﾄが高品質なら, 拡張性が達成で
きる可能性はより大である。
Copyright © 1994 Carnegie Mellon University26
フィーチャオリエンテッドなドメイン分析 - 1
ﾌｨｰﾁｬｵﾘｴﾝﾃｯﾄﾞなドメイン分析はSEIによって開発され
た。それはｱｰｷﾃｸﾁｬの設計手法の１つで
•概念的に類似な機能を識別する
•これらの機能をｸﾗｽにカテゴリ分けする
•各ｸﾗｽに対する共通の抽象化を定義する
•可能なところではﾊﾟﾗﾒーﾀを使用する
•ｱﾌﾟﾘｹｰｼｮﾝに特有な機能は後に回す
•ﾌﾟﾛｸﾞﾗﾑ部品の最大限の共有を可能にする
Copyright © 1994 Carnegie Mellon University27
フィーチャオリエンテッドなドメイン分析 - 2
ﾌｨｰﾁｬｵﾘｴﾝﾃｯﾄﾞなドメイン分析の例は
•ｼｽﾃﾑ出力機能を定義する
•最高ﾚﾍﾞﾙはﾒｯｾｰｼﾞを作成し送る
•次に低いﾚﾍﾞﾙはﾌﾟﾘﾝﾀやﾃﾞｨｽﾌﾟﾚｲなどを定義する
•次のﾚﾍﾞﾙはﾌﾟﾘﾝﾀﾌｫｰﾏｯﾃｨﾝｸﾞを取り扱う
•次のﾚﾍﾞﾙは特定のﾌﾟﾘﾝﾀﾀｲﾌﾟをｻﾎﾟｰﾄする
Copyright © 1994 Carnegie Mellon University28
開発戦略 - 1
開発戦略はｼｽﾃﾑがあまり大きすぎて１つの製品に作
り込めない時要求される
•その時システムを要素に分割しなければならない
•それからこれらの要素を開発しなければならない
•それから開発された要素は最終ｼｽﾃﾑに統合される
Copyright © 1994 Carnegie Mellon University29
開発戦略 - 2
戦略は
•より小規模な要素を定義する
•それらの要素が開発される順序を確立する
•要素が統合される方法を確立する
もし戦略が適切で、要素が適切に開発されるならば
•開発ﾌﾟﾛｾｽは拡張できるであろう
•開発全体は部品の和にｼｽﾃﾑ設計及び統合を加えた
ものである。
Copyright © 1994 Carnegie Mellon University30
いくつかの開発戦略
多くの開発戦略がありうる
目的はﾌﾟﾛｾｽの最も早い時点で主要な問題を識別する
ように、そのｼｽﾃﾑを逐次的に構築していく事である。
いくつかの戦略例は以下である：
•段階的戦略
•機能拡張戦略
•高速ﾊﾟｽ拡張戦略
•ﾀﾞﾐｰ戦略
Copyright © 1994 Carnegie Mellon University31
段階的戦略
サイクル 1
In
1st
モジュール
Out
サイクル 2
In
1st
モジュール
1st
拡張
サイクル 3
In
1st
モジュール
1st
拡張
Out
2nd
拡張
Out
段階的戦略においては, 機能はそれらが実行される順序で
開発される。このやり方は比較的単純なﾃｽﾄで済み、足場や
特別なﾃｽﾄ機能はほとんど要らない。
Copyright © 1994 Carnegie Mellon University32
機能拡張戦略
Ist
機能拡張
3rd
機能拡張
コアシステム
4th
機能拡張
2nd
機能拡張
機能拡張においては、ﾍﾞｰｽｼｽﾃﾑを最初に構築し、それ
から拡張しなければならない. ﾍﾞｰｽｼｽﾃﾑが大規模になる
としばしばその開発に対して別の戦略が必要になる.
Copyright © 1994 Carnegie Mellon University33
高速パス拡張戦略
1st
拡張
4th
拡張
c
b
a
その性能が適切であれば機能
拡張が行われる。
d
3rd
拡張
h
e
f
高速ﾊﾟｽ拡張では,高性能ﾙｰﾌﾟ
が最初に構築され、ﾃﾞﾊﾞｯｸﾞさ
れ計測される。
性能がまだ仕様の範囲内にあ
ることを保証するために各々の
拡張を計測する。
g
2nd
拡張
Copyright © 1994 Carnegie Mellon University34
ダミー戦略
コア
システム
A
B
コア
システム
C
B
機能
A
コア
システム
C
コア
システム
C
機能
A
機能
A
機能
B
機能
B
機能
C
ダミー戦略においては, システムの機能の全部また
は大部分をダミーコードで置き換えたコアシステムが
最初に作られる。
これらのダミーは、その後開発が進むのにしたがって
完全な機能に次第に置き換えられる。
Copyright © 1994 Carnegie Mellon University35
循環的ＰＳＰ - 1
循環的PSPは中規模のプログラムを開発するために
循環的開発戦略を使用する枠組みを与える。
複数のPSP2.1のような循環的要素を含むより大規模
なプロセスである。
PSPの要求、計画立案、および事後分析ステップはプ
ログラム全体に対し一度実行される。
Copyright © 1994 Carnegie Mellon University36
循環的 PSP フロー
仕様
製品
要求＆計画立案
サイクルの明確化
概要設計
詳細設計 &
設計ﾚﾋﾞｭｰ
概要設計ﾚﾋﾞｭｰ
テスト開発と
レビュー
循環的開発
実装とｺｰﾄﾞﾚﾋﾞｭｰ
事後分析
コンパイル
統合とシステムテスト
テスト
再評価と再循環
Copyright © 1994 Carnegie Mellon University37
循環的ＰＳＰ - 2
概要設計はプログラムを小規模要素に分解して開発
戦略を確立する。
そのプロセスは統合、システムテストおよびそれに続く
事後分析によって終了する。
開発戦略は以下のような循環的ステップを決定する。
•要素の選択
•テスト戦略
•最終統合を不要にするかもしれない。
Copyright © 1994 Carnegie Mellon University38
チームソフトウェアプロセス - 1
プロジェクト規模をさらに大きくするために、典型的に
はチーム開発ﾌﾟﾛｾｽが要求される。
これは主要なプロジェクトタスクを識別する。
•これらのタスクを相互に関係づける
•開始と終了の条件を確立する
•チームメンバーの役割を割当てる
•チーム尺度を確立する
•チームの目標と品質評価基準を確立する
Copyright © 1994 Carnegie Mellon University39
チームソフトウェアプロセス - 2
チームプロセスはまた個々のPSPがチームの中で関係
をもつ事が出来る枠組みを与える, それは
•チーム--PSPインタフェースを定義する
•標準と尺度を確立する
•何処でｲﾝｽﾍﾟｸｼｮﾝされるべきか規定する
•計画立案と報告のガイドラインを確立する
たとえPSPをもっていたとしても,ｲﾝｽﾍﾟｸｼｮﾝではチーム
サポートを得るように試みたほうがよい
PSPの欠陥摘出率を改善するために設計のｲﾝｽﾍﾟｸｼｮﾝ
を使用する事を最初に考えなさい.
Copyright © 1994 Carnegie Mellon University40
インスペクション - 1（現在はＰＳＰ２）
インスペクションはソフトウエア品質の改善と開発時間
およびコストを減少させるためにもっともコスト効率のよ
いテクニックとして知られている。
インスペクションは次のことに役立つ
•よりよい仕事をするよう動機づける
•効果的なチームコミュニケーションを保証する
•優れたものへのこだわりを維持する
（個人的なベンチマークの設定）
Copyright © 1994 Carnegie Mellon University41
インスペクション - 2
インスペクションの目的は
•出来るだけ早期の時点でエラーを発見すること
•全ﾊﾟｰﾃｨｰが仕事に合意している事を保証すること
•その仕事が定義された判断基準に適合している事を
検証すること
•公式に仕事を完了すること
•ﾃﾞｰﾀを提供すること
インスペクションは任意のｿﾌﾄｳｴｱ製品の要素に使用
できる、例えば
•要求、仕様、設計、ｺｰﾄﾞ
•ﾃｽﾄ資料
•文書
Copyright © 1994 Carnegie Mellon University42
インスペクションプロセス - 1
インスペクションは公式に構造化されたﾌﾟﾛｾｽに従う
ﾁｪｯｸﾘｽﾄと標準がインスペクションの各ﾀｲﾌﾟに対して
開発される。
インスペクションは技術者のために技術者によって
運営される。管理者は出席しない。
Copyright © 1994 Carnegie Mellon University43
インスペクションプロセス - 2
計画立案
管理者
開発者
司会者
説明会議
司会者
開発者
ﾚﾋﾞｭｰ者
準備
ﾚﾋﾞｭｰ者
ｲﾝｽﾍﾟｸｼｮﾝ
会議
司会者
記録者
開発者
ﾚﾋﾞｭｰ者
ﾌｫﾛｰｱｯﾌﾟ
司会者
開発者
Copyright © 1994 Carnegie Mellon University44
インスペクションプロセス - 3
ﾚﾋﾞｭｰ者は前もって準備する.
インスペクション会議は焦点を問題の識別に置き、問
題の解決には置かない.
インスペクションﾃﾞｰﾀを収集して追跡と分析のためにイ
ンスペクションﾃﾞｰﾀﾍﾞｰｽに入力する.
Copyright © 1994 Carnegie Mellon University45
インスペクションにおける役割 - 1
司会者
•インスペクションﾌﾟﾛｾｽをﾘｰﾄﾞする
•焦点を問題解決よりもむしろ問題識別に置き続ける
•識別された問題が解決される事を保証する
•インスペクション報告書を提出する
開発者（その仕事をした開発者）
•ﾚﾋﾞｭｰ資料を作成する
•質問に答える
•識別された問題を解決する
Copyright © 1994 Carnegie Mellon University46
インスペクションにおける役割 - 2
ﾚﾋﾞｭｰ者
•インスペクションｷｯｸｵﾌ会議に出席する
•前もってﾚﾋﾞｭｰ資料をﾚﾋﾞｭｰする
•インスペクション会議に出席する
•識別された欠陥または他の関心のある事について問
題を提起し質問する
記録者
•識別された問題点を文書化しそれらの解決に責任を
もつ人を記録する
•全ての関連するﾃﾞｰﾀを記録する
Copyright © 1994 Carnegie Mellon University47
演習課題#11
ﾃｷｽﾄの第１１章を読みなさい
PSP3を使用して、あるﾃﾞｰﾀｾｯﾄから説明変数が３つの
重回帰ﾊﾟﾗﾒｰﾀと予測区間を計算するためのﾌﾟﾛｸﾞﾗﾑ
１０Aを書きなさい。t分布を計算するためにﾌﾟﾛｸﾞﾗﾑ５A
を使用しなさい。この宿題のために３つの期間が許さ
れる。
付録Dにあるﾌﾟﾛｸﾞﾗﾑ仕様と付録Cにあるﾌﾟﾛｾｽ説明と
報告書仕様を読んでそのとおりやりなさい。
Copyright © 1994 Carnegie Mellon University48
重回帰 - 1
あなたは６ﾌﾟﾛｼﾞｪｸﾄについて以下のようなﾃﾞｰﾀをもつと
仮定しよう
•要求される開発時間
•新規LOC、再利用LOC、および修正LOC
あなたが新規ｺｰﾄﾞ６５０LOC、再利用ｺｰﾄﾞ3,000LOC、
および修正ｺｰﾄﾞ155LOCをもつだろうと判断した新規ﾌﾟ
ﾛｼﾞｪｸﾄにかかる時間を見積もりたいと仮定しよう。
開発時間と予測区間をどのように見積もるだろうか？
Copyright © 1994 Carnegie Mellon University49
重回帰 - 2
ﾌﾟﾛｸﾞﾗﾑ#
1
2
3
4
5
6
合計
見積り値
新規再利用
w
x
1,142 1,060
863
995
1,065 3,205
554
120
983 2,896
256
485
修正
y
325
98
23
0
120
88
時間
z
201
98
162
54
138
61
4,863
650
654
155
714
???
8,761
3,000
Copyright © 1994 Carnegie Mellon University50
重回帰 - 3
重回帰はあなたが各変数に対して別々の効果ﾃﾞｰﾀを
持たない時に多変量の効果を見積もるための1つの方
法を与える。
1. 見積もり値を計算するため次のような
重回帰公式を使用するだろう。
zk  0  wk1  xk 2  yk3
Copyright © 1994 Carnegie Mellon University51
重回帰 - 4
2. 次のような連立1次方程式を解くことによって
あなたはBetaﾊﾟﾗﾒｰﾀを求めることが出来る
n
n
n
n
i 1
i 1
i 1
i 1
0 n  1  wi  2  x i  3  yi   zi
n
n
n
n
n
i1
i 1
i 1
i 1
i1
n
n
n
n
i1
i 1
0  wi  1  wi2  2  wi x i  3  wi yi   wi zi
n
0  xi  1  wi x i  2  x  3  xi y i   x izi
i1
i 1
i 1
n
n
n
2
i
n
n
0  yi  1  wi yi  2  x i yi   3  y   yi zi
i1
i 1
i 1
i 1
2
i
i 1
Copyright © 1994 Carnegie Mellon University52
重回帰 - 5
3. あなたが項の値を計算するとき,
次のような連立1次方程式が得られる。
6 0  4, 8631  8, 7612  6543  714
4, 863 0  4, 521, 8991  8, 519, 9382  620, 707 3  667, 832
8, 761 0  8, 519, 9381  21, 022, 0912  905, 925 3  1, 265, 493
654 0  620, 7071  905, 9252  137, 902 3  100, 583
Copyright © 1994 Carnegie Mellon University53
重回帰 - 6
4. 次に、Gaussの方法を使用して対角化する。
この方法は以下の式を与えるために継続的に掛け
算と引き算を行って方程式から1回に1ﾊﾟﾗﾒｰﾀずつ
消去して行く。
6 0  4 , 8631  8, 761 2  654 3  714
0 0  580, 437. 51  1, 419,148 2  90, 640 3  89 , 135
0 0  01  4 , 759, 809 2  270, 635 3  5, 002. 332
0 0  01  0 2  37, 073. 93 3  9, 122. 275
Copyright © 1994 Carnegie Mellon University54
重回帰 - 7
5. このようにしてＢｅｔａ項が得られる
 0  6. 7013
1  0. 0784
 2  0. 0150
 3  0. 2461
Copyright © 1994 Carnegie Mellon University55
重回帰 - 8
6. 次のような方程式を解くことによって範囲に対する
予測区間を決定する。
x k  x avg
yk  y avg


1 wk  wavg
Range  t  / 2, n  4  1  
2 
2 
2
n  wi  wavg   xi  xavg   yi  yavg
2
2
2
7 - 分散を次のように計算する
2
 1  n
  

zi  0  1 wi  2 xi  3yi 

i
1
n  4 
2
Copyright © 1994 Carnegie Mellon University56
重回帰 - 9
8. 分散は次のように計算する
    513.058  22.651
2
9. 平方根の中の項は
Newk  Newavg   wk  wavg  650  810.52  25,760.25
2
2
Re use  Re use   x  x   3,000 1,460.17  2,371,076.43
Modify  Modify   y  y   155 109  2,116
2
k
2
avg
k
avg
2
k
avg
2
2
k
2
avg
Copyright © 1994 Carnegie Mellon University57
重回帰 - 10
10. n=6, p=4 のときの７０%予測区間に対するｔ分布
の値は, 表Ａ２における85%の列で自由度２の
ところで見つかる。その値は 1.386である.
11. 平方根はそのとき次のように計算される
Range  1.386 *22.651 1 1 / 6  
25,760.25 2,371,076.43 2,116


 38.846
580,437.5
8,229,571
66,616
Copyright © 1994 Carnegie Mellon University58
重回帰 - 11
12. 最終見積もり値はそのとき
z = 6.71+0.0784*650+0.0150*3,000+0.2461*155
= 140.902 時間
13. 38.846 時間の予測区間は見積もりが
102.1 から 179.7時間であることを意味している。
Copyright © 1994 Carnegie Mellon University59
講義11で覚えておくべきメッセージ - 1
1.ｿﾌﾄｳｴｱﾌﾟﾛｾｽが拡張可能であれば生産性向上と
計画立案に非常に役立つ。
2. 拡張性のためにはﾌﾟﾛｾｽが定義され、良く管理され、
そして高い品質をもつことが必要である。
Copyright © 1994 Carnegie Mellon University60
講義11で覚えておくべきメッセージ - 2
3. 欠陥摘出管理に焦点を当てたＰＳＰは拡張性を達
成するために役に立つ。（→インスペクション）
4. 抽象化、ｱｰｷﾃｸﾁｬ、および再利用を利用すること
はまたプロセスを拡張可能にすることにも役に立
つであろう。
Copyright © 1994 Carnegie Mellon University61

Download Report