disciplined software engineering lecture #11

Copyright © 1994 Carnegie Mellon University1

Disciplined Software Engineering Lecture #11

Software Engineering Institute

Carnegie Mellon University

Pittsburgh, PA 15213

Sponsored by the U.S. Department of Defense


Lecture #11 概要個人的ソフトウエアプロセスの拡張

•拡張性の原則•ソフトウエアの複雑さの取り扱い•開発戦略

循環的 PSP

ソフトウエアインスペクション（現在はＰＳＰ２）


拡張性とは何か ? 製品開発プロセスは使用される方法と技法が、より大規模なプロジェクトに対しても同様にうまく働く時、拡張可能である。

拡張性は典型的には以下である。•製品規模の狭い範囲を越えて適用される•類似のアプリケーション領域に限定される•先例のないシステムには適用しない•管理が貧弱なプロジェクトには働かない•技術作業に規範がないところで適用される事はありそうにない。


拡張性の原則拡張性が可能であるためには、より大きなﾌﾟﾛｼﾞｪｸ

の要素は小さなと同じ様に振る舞う事がﾄﾌﾟﾛｼﾞｪｸﾄ必要である。

したがって製品設計はそのをそれぞれ分ﾌﾟﾛｼﾞｪｸﾄ割開発される要素に分けなければならない。

これは開発は個人が効率的に開発できるﾌﾟﾛｾｽﾌﾟﾛｼの（規模）を考慮に入れることを要求すﾞｪｸﾄｽｹｰﾙ

る。


拡張性のｽﾃｰｼﾞ我々はを５つの拡張性に分類されｿﾌﾄｳｴｱｼｽﾃﾑｽﾃｰｼﾞるものとして見る事が出来る。

これらの拡張性は以下のようになる：ｽﾃｰｼﾞ• ｽﾃｰｼﾞ 0 - 単純ルーチン• ｽﾃｰｼﾞ 1 - プログラム• ｽﾃｰｼﾞ 2 - コンポーネント• ｽﾃｰｼﾞ 3 - システム• ｽﾃｰｼﾞ 4 - 複合システム


拡張性ｽﾃｰｼﾞ 0 ｽﾃｰｼﾞ 0 は基本的な構成物レベルである。これはループ、ｃａｓｅ文、などの構築に関係する。

０は入門コースの主要な焦点でｽﾃｰｼﾞﾌﾟﾛｸﾞﾗﾐﾝｸﾞある。

ｽﾃｰｼﾞ 0 では , 各構成物を意識して設ﾌﾟﾛｸﾞﾗﾐﾝｸﾞ計する。

あなたの思考がこれらの詳細に没頭している時には、より大きな構成物を思い浮かべる事は難しい。


拡張性ｽﾃｰｼﾞ 1 １は数百ＬＯＣまでの小規模に関係ｽﾃｰｼﾞﾌﾟﾛｸﾞﾗﾑがある。

０から１への移行は言語に習熟してくｽﾃｰｼﾞｽﾃｰｼﾞれば自然に起こる。あなたは今や小規模をﾌﾟﾛｸﾞﾗﾑその詳細な構成物を意識的に設計することなしに一つの実体として考える。

あなたが１で経験を得るのにしたがって、あｽﾃｰｼﾞなたが理解し、自信を持って使う事が出来る小規模プログラム機能を表す語嚢を増やしていく。


拡張性ｽﾃｰｼﾞ 2 ｽﾃｰｼﾞ 2 はレベルである。ここで、複数のｺﾝﾎﾟｰﾈﾝﾄ

が結合され高度な機能を提供する。ﾌﾟﾛｸﾞﾗﾑｽﾃｰｼﾞ２のは典型的には数千ｺﾝﾎﾟｰﾈﾝﾄ LOC である。

１から２への移行は経験の増加に伴っｽﾃｰｼﾞｽﾃｰｼﾞて起こる。今や一人で多分作成できるよりﾌﾟﾛｸﾞﾗﾑも大規模なについて考えることが出来る。ﾌﾟﾛｸﾞﾗﾑ

２ではｽﾃｰｼﾞ , システム問題：すなわち品質、性能、使用性、などが出始める。

（図 11.1 参照：知識の自覚）


拡張性ｽﾃｰｼﾞ 3 ３のシステムは数百万ｽﾃｰｼﾞ LOC くらいの大きさになるかもしれない。ここで、システム問題が目立ってくる。• は協調して働かなければならない。ｺﾝﾎﾟｰﾈﾝﾄ• 部品はすべて高品質でなければならない。ｺﾝﾎﾟｰﾈﾝﾄ

２から３への移行は次のことを含む。ｽﾃｰｼﾞｽﾃｰｼﾞ• の複雑さの取り扱いﾌﾟﾛｸﾞﾗﾑ•システムとアプリケーション問題を理解すること•チーム環境で働くこと　　　　　　　　　　　　　　　　　　

３では、主要な力点をプログラムの品質に置かねばｽﾃｰｼﾞならない。


拡張性ｽﾃｰｼﾞ 4 ４の複合システムは数千万ｽﾃｰｼﾞ LOC を含むかもしれない。 •複数の半独立システムが協調して働かねばならない

•品質は最高に重要である。

３から４への移行では集中制御についｽﾃｰｼﾞｽﾃｰｼﾞての問題のみならず大規模かつ分散したシステムの問題が起こる。

４は半自主的な開発グループと自己管理するｽﾃｰｼﾞチームを要求する。


拡張性条件 - 1 拡張可能であるためには

• は管理されなければならない。ﾌﾟﾛｾｽ• は管理されなければならない。ﾌﾟﾛｼﾞｪｸﾄ•製品は管理されなければならない。

管理されたはﾌﾟﾛｾｽ•定義されるべきである•その仕事を分離可能な要素に分解するべきである

•これらの要素を最終システムに効果的に統合するべきである。


拡張性条件 - 2 管理されたに対してﾌﾟﾛｼﾞｪｸﾄ

•仕事は計画されねばならない•仕事はその計画に対して管理されねばならない•要求の変更は制御されねばならない•システム設計とシステムアーキテクチャはプロジェクトを通して一貫して継続しなければならない。

•構成管理が使用されなければならない。


拡張性条件 - 3 管理された製品に対しては

•欠陥は追跡され制御されなければならない•統合とシステムテストを行わねばならない •縮退テストは首尾一貫して使用される

製品品質は高くなければならない•モジュール欠陥は統合とシステムテストの前に除去すべきである

•モジュール品質の目的は統合とシステムテストの前に全ての欠陥を発見することであるべきである。 ( すなわち、百万 LOC あたり１００未満の欠陥を見逃す）　　　　　　→１ KLOC あたり０ . １未満


拡張性の目的拡張性の目的は大規模製品を小規模製品と同様な品質と生産性で開発することである。

拡張性は小規模において行われたタスクﾌﾟﾛｼﾞｪｸﾄにだけ適用される。

より大規模なにより要求される新しいタﾌﾟﾛｼﾞｪｸﾄスクは追加の作業を要求するので、生産性は一般的にジョブの規模が増加するのに伴って下降する。


拡張性の範囲 - 1

小規模ﾌﾟﾛｼﾞｪｸﾄ

中規模ﾌﾟﾛｼﾞｪｸﾄ

大規模ﾌﾟﾛｼﾞｪｸﾄ

ﾓｼﾞｭｰﾙ C

モジュールＢ

モジュール A

モジュール F

モジュール E

モジュール D

モジュール I

モジュール H

モジュール G

モジュール L

モジュール K

モジュール J

モジュール O

モジュール N

モジュール M

ｺﾝﾎﾟｰﾈﾝﾄ X ｺﾝﾎﾟｰﾈﾝﾄ Y

製品 Z


拡張性の範囲 - 2 からへの拡張においてﾓｼﾞｭｰﾙﾚﾍﾞﾙｺﾝﾎﾟｰﾈﾝﾄﾚﾍﾞﾙ

• の作業の品質と生産性の維持を求めﾓｼﾞｭｰﾙﾚﾍﾞﾙる

• の作業は新しいので拡張が出来なｺﾝﾎﾟｰﾈﾝﾄﾚﾍﾞﾙい

製品への拡張においてﾚﾍﾞﾙ• 作業の品質と生産性の維持を求めるｺﾝﾎﾟｰﾈﾝﾄﾚﾍﾞﾙ•製品の作業は新しいので拡張が出来ないﾚﾍﾞﾙ


複雑さの管理 - 1 規模と複雑さは密接に関係している。

小規模は程々に複雑であり得るが、極めてﾌﾟﾛｸﾞﾗﾑ重要な問題は大規模を扱う事である。ﾌﾟﾛｸﾞﾗﾑ

が大規模になると一般にプログラムは非常ﾌﾟﾛｸﾞﾗﾑに複雑になる。


複雑さの管理 - 2 ソフトウエア開発は主として個人によって行われる。•個人は小規模プログラムを一人だけで書く。•大規模プログラムは普通複数の小規模プログラムから構成される

以下を実施するための方法に関連した３つの問題がある。•高品質の小規模プログラムを開発する　•より大きなそしてより複雑なプログラムを個人が取り扱えるようにする

•これらの個人的に開発されたプログラムをより大きなシステムに組み合わせる


複雑さの管理 - 3 ソフトウェアの複雑さについての主要な問題は人間が次に関してかぎられた能力しかもっていないと言う事である。•詳細を記憶すること•複雑な関係を視覚化すること

したがって我々は次第に複雑になるプログラムを個人が開発するのに役立つ方法を探し求める。•抽象化•アーキテクチャ•再利用


抽象化の力 - 1 人間は概念的なチャンク (塊 ) で考える

•積極的に使えるのは 7+/- ２個のチャンクの範囲である。

•チャンクが豊かであれば我々の思考が強力になる。

このことはアマチュアのチェスプレイヤーにゲーム中のチェスの駒の位置を記憶することを求めることで示された。 •彼等は僅か 5~6駒しか覚えられなかった．•エキスパートは盤全体を記憶することが出来た。•ランダムに置かれた駒に対しては , エキスパートもアマチュアもほとんど同程度の結果になった。


抽象化の力 - 2 以下のことが成り立てば、ソフトウエアの抽象化はこの様なチャンク (塊 ) を形作ることが出来る•抽象化が精密である•我々が完全に理解している•考えたとおりに正しく実行する

いくつかの可能性のある抽象化は以下である•ルーチン•標準手続きと再利用可能なプログラム•完全なサブシステム


抽象化の力 - 3

概念的な複雑さを減らすため , これらの抽象化は次でなければならない

•仕様化されたとおりに精密に実行する•仕様化された以外の相互関連を持っていない•首尾一貫しかつ自己完結的なシステム機能を　　　　概念的に表現する


抽象化の力 - 4 これらのより大きな言葉で考えるとき , 我々のシステムを精密に定義できる。

そうするとそれらから構成される抽象化を構築することが出来る。

これらの抽象化がシステムに結合されるとき、期待されたように働く可能性がより大きくなる。


抽象化の力 - 5 抽象化において主要な制約になることは以下である。•開発者 ( 人間 ) は仕様化において誤りをする •抽象化はしばしば欠陥を含む•多くの抽象化は特殊であり汎用性がない

このことは他人の仕事を活用することが滅多に出来ないことを意味している。

したがって複雑なシステムを知覚する我々ｿﾌﾄｳｴｱの知的能力は、われわれ自身が開発してきた抽象化によって制約される。


アーキテクチャと再利用 - 1 設計は以下の理由から複雑さを減少さｼｽﾃﾑｱｰｷﾃｸﾁｬせることが出来る•首尾一貫した構造的な枠組みを与える •概念的に類似な機能を識別する• を明確に分離するｻﾌﾞｼｽﾃﾑ

よく構造化されたは標準設計の利用を促進ｱｰｷﾃｸﾁｬする•アプリケーションの固有事項は一番下のレベルまで決定が延ばされる

•可能なところでは、調整可能なパラメータが定義される。


アーキテクチャと再利用 - 2 このことは標準化されたの使用を通してｺﾝﾎﾟｰﾈﾝﾄ再利用可能性を増加させる。

これらの精密に定義された標準がそのとｺﾝﾎﾟｰﾈﾝﾄき概要設計の抽象化として使用できる

もしこれらのが高品質ならｺﾝﾎﾟｰﾈﾝﾄ , 拡張性が達成できる可能性はより大である。


フィーチャオリエンテッドなドメイン分析 - 1

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


フィーチャオリエンテッドなドメイン分析 - 2 なドメイン分析の例はﾌｨｰﾁｬｵﾘｴﾝﾃｯﾄﾞ

• 出力機能を定義するｼｽﾃﾑ•最高はを作成し送るﾚﾍﾞﾙﾒｯｾｰｼﾞ•次に低いはやなどを定義するﾚﾍﾞﾙﾌﾟﾘﾝﾀﾃﾞｨｽﾌﾟﾚｲ•次のはを取り扱うﾚﾍﾞﾙﾌﾟﾘﾝﾀﾌｫｰﾏｯﾃｨﾝｸﾞ•次のは特定のをするﾚﾍﾞﾙﾌﾟﾘﾝﾀﾀｲﾌﾟｻﾎﾟｰﾄ


開発戦略 - 1

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

•それからこれらの要素を開発しなければならない

•それから開発された要素は最終に統合されｼｽﾃﾑる


開発戦略 - 2 戦略は

•より小規模な要素を定義する•それらの要素が開発される順序を確立する•要素が統合される方法を確立する

もし戦略が適切で、要素が適切に開発されるならば•開発は拡張できるであろうﾌﾟﾛｾｽ•開発全体は部品の和に設計及び統合を加えたｼｽﾃﾑものである。


いくつかの開発戦略多くの開発戦略がありうる

目的はの最も早い時点で主要な問題を識別すﾌﾟﾛｾｽるように、そのを逐次的に構築していく事であｼｽﾃﾑる。

いくつかの戦略例は以下である： •段階的戦略•機能拡張戦略•高速拡張戦略ﾊﾟｽ• 戦略ﾀﾞﾐｰ


2nd拡張

1st拡張

1st拡張

1stモジュール

1stモジュール

1stモジュール

段階的戦略

段階的戦略においては , 機能はそれらが実行される順序で開発される。このやり方は比較的単純なで済み、ﾃｽﾄ足場や特別な機能はほとんど要らない。ﾃｽﾄ

In

Out

Out

サイクル 1

サイクル 2

サイクル 3

In

In

Out


機能拡張戦略

機能拡張においては、を最初に構築し、そﾍﾞｰｽｼｽﾃﾑれから拡張しなければならない . が大規模ﾍﾞｰｽｼｽﾃﾑになるとしばしばその開発に対して別の戦略が必要になる .

4th機能拡張

2nd機能拡張

3rd機能拡張

コアシステム

Ist機能拡張


高速パス拡張戦略

高速拡張ではﾊﾟｽ , 高性能ﾙｰﾌが最初に構築され、ﾟﾃﾞﾊﾞｯｸﾞ

され計測される。

その性能が適切であれば機能拡張が行われる。

性能がまだ仕様の範囲内にあることを保証するために各々の拡張を計測する。

1st拡張

2nd拡張

3rd拡張

4th拡張

a

b

c

d

e

h

g

f


ダミー戦略

B C

コアシステム

機能A

ダミー戦略においては , システムの機能の全部または大部分をダミーコードで置き換えたコアシステムが最初に作られる。

これらのダミーは、その後開発が進むのにしたがって完全な機能に次第に置き換えられる。

A B C

コアシステム

機能B

コアシステム

機能A

C

機能C

機能B

コアシステム

機能A


循環的ＰＳＰ - 1 循環的 PSP は中規模のプログラムを開発するために循環的開発戦略を使用する枠組みを与える。

複数の PSP2.1 のような循環的要素を含むより大規模なプロセスである。

PSP の要求、計画立案、および事後分析ステップはプログラム全体に対し一度実行される。


概要設計

要求　＆　計画立案

概要設計ﾚﾋﾞｭｰ

統合とシステムテスト

事後分析

循環的開発

循環的 PSP フロー仕様

製品

詳細設計 &設計ﾚﾋﾞｭｰ

サイクルの明確化

テスト開発とレビュー

テスト

コンパイル

実装とｺｰﾄﾞﾚﾋﾞｭｰ

再評価と再循環


循環的ＰＳＰ - 2 概要設計はプログラムを小規模要素に分解して開発戦略を確立する。

そのプロセスは統合、システムテストおよびそれに続く事後分析によって終了する。

開発戦略は以下のような循環的ステップを決定する。•要素の選択•テスト戦略•最終統合を不要にするかもしれない。


チームソフトウェアプロセス - 1 プロジェクト規模をさらに大きくするために、典型的にはチーム開発が要求される。ﾌﾟﾛｾｽ

これは主要なプロジェクトタスクを識別する。•これらのタスクを相互に関係づける•開始と終了の条件を確立する•チームメンバーの役割を割当てる•チーム尺度を確立する•チームの目標と品質評価基準を確立する


チームソフトウェアプロセス - 2 チームプロセスはまた個々の PSP がチームの中で関係をもつ事が出来る枠組みを与える , それは•チーム --PSP インタフェースを定義する•標準と尺度を確立する•何処でされるべきか規定するｲﾝｽﾍﾟｸｼｮﾝ•計画立案と報告のガイドラインを確立する

たとえ PSP をもっていたとしても , ではｲﾝｽﾍﾟｸｼｮﾝチームサポートを得るように試みたほうがよい

PSP の欠陥摘出率を改善するために設計のｲﾝｽﾍﾟｸｼｮを使用する事を最初に考えなさいﾝ .


インスペクション - 1 （現在はＰＳＰ２）

インスペクションはソフトウエア品質の改善と開発時間およびコストを減少させるためにもっともコスト効率のよいテクニックとして知られている。

インスペクションは次のことに役立つ•よりよい仕事をするよう動機づける•効果的なチームコミュニケーションを保証する•優れたものへのこだわりを維持する（個人的なベンチマークの設定）


インスペクション - 2 インスペクションの目的は

•出来るだけ早期の時点でエラーを発見すること•全が仕事に合意している事を保証することﾊﾟｰﾃｨｰ•その仕事が定義された判断基準に適合している事を検証すること

•公式に仕事を完了すること• を提供することﾃﾞｰﾀ

インスペクションは任意の製品の要素に使用ｿﾌﾄｳｴｱできる、例えば•要求、仕様、設計、ｺｰﾄﾞ• 資料ﾃｽﾄ•文書


インスペクションプロセス - 1 インスペクションは公式に構造化されたにﾌﾟﾛｾｽ従う

と標準がインスペクションの各に対ﾁｪｯｸﾘｽﾄﾀｲﾌﾟして開発される。

インスペクションは技術者のために技術者によって運営される。管理者は出席しない。


インスペクションプロセス - 2

計画立案説明会議準備ｲﾝｽﾍﾟｸｼｮﾝ会議ﾌｫﾛｰｱｯﾌﾟ

管理者開発者司会者

司会者開発者

者ﾚﾋﾞｭｰ

者ﾚﾋﾞｭｰ司会者記録者開発者

者ﾚﾋﾞｭｰ

司会者開発者


インスペクションプロセス - 3 者は前もって準備するﾚﾋﾞｭｰ .

インスペクション会議は焦点を問題の識別に置き、問題の解決には置かない .

インスペクションを収集して追跡と分析のたﾃﾞｰﾀめにインスペクションに入力するﾃﾞｰﾀﾍﾞｰｽ .


インスペクションにおける役割 - 1

司会者 •インスペクションをするﾌﾟﾛｾｽﾘｰﾄﾞ•焦点を問題解決よりもむしろ問題識別に置き続ける

•識別された問題が解決される事を保証する•インスペクション報告書を提出する

開発者（その仕事をした開発者） • 資料を作成するﾚﾋﾞｭｰ•質問に答える •識別された問題を解決する


インスペクションにおける役割 - 2

者ﾚﾋﾞｭｰ•インスペクション会議に出席するｷｯｸｵﾌ•前もって資料をするﾚﾋﾞｭｰﾚﾋﾞｭｰ•インスペクション会議に出席する•識別された欠陥または他の関心のある事について問題を提起し質問する

記録者 •識別された問題点を文書化しそれらの解決に責任をもつ人を記録する

•全ての関連するを記録するﾃﾞｰﾀ


演習課題 #11 の第１１章を読みなさいﾃｷｽﾄ

PSP3 を使用して、あるから説明変数が３ﾃﾞｰﾀｾｯﾄつの重回帰と予測区間を計算するためのﾊﾟﾗﾒｰﾀﾌﾟﾛ　１０ｸﾞﾗﾑ A を書きなさい。 t 分布を計算するた

めに５ﾌﾟﾛｸﾞﾗﾑ A を使用しなさい。この宿題のために３つの期間が許される。

付録 D にある仕様と付録ﾌﾟﾛｸﾞﾗﾑ C にある説ﾌﾟﾛｾｽ明と報告書仕様を読んでそのとおりやりなさい。


重回帰 - 1 あなたは６について以下のようなをﾌﾟﾛｼﾞｪｸﾄﾃﾞｰﾀもつと仮定しよう•要求される開発時間•新規 LOC 、再利用 LOC 、および修正 LOC

あなたが新規６５０ｺｰﾄﾞ LOC 、再利用ｺｰﾄﾞ 3,000LOC 、および修正ｺｰﾄﾞ 155LOC をもつだろうと判断した新規にかかる時間を見積もりたいﾌﾟﾛｼﾞｪｸﾄと仮定しよう。

開発時間と予測区間をどのように見積もるだろうか？


重回帰 - 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 ???


重回帰 - 3 重回帰はあなたが各変数に対して別々の効果ﾃﾞｰﾀを持たない時に多変量の効果を見積もるための 1つの方法を与える。

1. 見積もり値を計算するため次のような

重回帰公式を使用するだろう。

zk 0 wk1 xk 2 yk3


重回帰 - 4 2. 次のような連立 1次方程式を解くことによってあなたは Beta を求めることが出来るﾊﾟﾗﾒｰﾀ

0n 1 wii1

n

2 x ii1

n

3 yii1

n

zii1

n

0 wii1

n

1 wi2

i1

n

2 wix ii1

n

3 wiyii1

n

wizii1

n

0 xii1

n

1 wix ii1

n

2 x i2

i1

n

3 xiy ii1

n

x izii1

n

0 yii1

n

1 wiyii1

n

2 x iyii1

n

3 yi2

i1

n

yizii1

n


重回帰 - 5 3. あなたが項の値を計算するとき ,

次のような連立 1次方程式が得られる。

6 4 863 8 761 654 714

4 863 4 521 899 8 519 938 620 707 667 832

8 761 8 519 938 21 022 091 905 925 1 265 493

654 620 707 905 925 137 902 100 583

0 1 2 3

0 1 2 3

0 1 2 3

0 1 2 3

, ,

, , , , , , ,

, , , , , , , ,

, , , ,


重回帰 - 6 4. 次に、 Gauss の方法を使用して対角化する。この方法は以下の式を与えるために継続的に掛け

算と引き算を行って方程式から 1回に 1 ﾊﾟﾗﾒｰﾀずつ

消去して行く。 6 4 863 8 761 654 714

0 580 437 5 1 419 148 90 640 89 135

0 0 4 759 809 270 635 5 002 332

0 0 0 37 073 93 9 122 275

0 1 2 3

0 1 2 3

0 1 2 3

0 1 2 3

, ,

, . , , , ,

, , , , .

, . , .


重回帰 - 7 5. このようにしてＢｅｔａ項が得られる

0

1

2

3

6 7013

0 0784

0 0150

0 2461

.

.

.

.


重回帰 - 8 6. 次のような方程式を解くことによって範囲に対する

予測区間を決定する。

7 - 分散を次のように計算する

Range t / 2, n 4 11

n

wk wavg 2

wi wavg 2

xk xavg 2

xi xavg 2

yk yavg 2

yi yavg 2

2 1

n 4

zi 0 1wi 2xi 3yi

i1

n2


重回帰 - 9 8. 分散は次のように計算する

9. 平方根の中の項は

2 513.058 22.651

Newk Newavg 2 wk wavg 2 650 810.5 2 25,760.25

Reusek Reuseavg 2 xk xavg 2 3,000 1,460.17 2 2,371,076.43

Modifyk Modifyavg 2 yk yavg 2 155 109 2 2,116


重回帰 - 10 10. n=6, p=4 のときの７０ %予測区間に対するｔ分布

　　の値は , 表Ａ２における 85% の列で自由度２の

ところで見つかる。その値は 1.386 である .

11. 平方根はそのとき次のように計算される

Range 1.386 *22.651 1 1 / 6 25,760.25580,437.5

2,371,076.43

8,229,5712,116

66,61638.846


重回帰 - 11 12. 最終見積もり値はそのとき

z = 6.71+0.0784*650+0.0150*3,000+0.2461*155

= 140.902 時間

13. 38.846 時間の予測区間は見積もりが 102.1 から 179.7 時間であることを意味している。


講義 11 で覚えておくべきメッセージ - 1

1. が拡張可能であれば生産性向上とｿﾌﾄｳｴｱﾌﾟﾛｾｽ　計画立案に非常に役立つ。

2. 拡張性のためにはが定義され、良く管理さﾌﾟﾛｾｽれ、そして高い品質をもつことが必要である。


講義 11 で覚えておくべきメッセージ - 2

3. 欠陥摘出管理に焦点を当てたＰＳＰは拡張性を達成するために役に立つ。（→インスペクション）

4. 抽象化、、および再利用を利用するこｱｰｷﾃｸﾁｬと

はまたプロセスを拡張可能にすることにも役に立

つであろう。

disciplined software engineering lecture #11

Documents