Transcript 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 wk1 x k 2 yk3 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 i1 i 1 i 1 i 1 i1 n n n n i1 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 i1 i 1 i 1 n n n 2 i n n 0 yi 1 wi yi 2 x i yi 3 y yi zi i1 i 1 i 1 i 1 2 i i 1 Copyright © 1994 Carnegie Mellon University52 重回帰 - 5 3. あなたが項の値を計算するとき, 次のような連立1次方程式が得られる。 6 0 4, 8631 8, 7612 6543 714 4, 863 0 4, 521, 8991 8, 519, 9382 620, 707 3 667, 832 8, 761 0 8, 519, 9381 21, 022, 0912 905, 925 3 1, 265, 493 654 0 620, 7071 905, 9252 137, 902 3 100, 583 Copyright © 1994 Carnegie Mellon University53 重回帰 - 6 4. 次に、Gaussの方法を使用して対角化する。 この方法は以下の式を与えるために継続的に掛け 算と引き算を行って方程式から1回に1ﾊﾟﾗﾒｰﾀずつ 消去して行く。 6 0 4 , 8631 8, 761 2 654 3 714 0 0 580, 437. 51 1, 419 ,148 2 90, 640 3 89, 135 0 0 01 4 , 759 , 809 2 270, 635 3 5, 002. 332 0 0 01 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. 次のような方程式を解くことによって範囲に対する 予測区間を決定する。 xk xavg yk yavg 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 z 0 1wi 2 xi 3yi i 1 i n 4 2 Copyright © 1994 Carnegie Mellon University56 重回帰 - 9 8. 分散は次のように計算する 513.058 22.651 2 9. 平方根の中の項は Newk Newav g wk wav g 650 810.52 25,760.25 2 2 Re usek Re useav g x k x av g 3,000 1,460.17 2,371,076.43 2 2 2 Modifyk Modifyav g yk yav g 155109 2,116 2 2 2 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