ARCHIVE  ENTRY  COMMENT  TRACKBACK  CATEGORY  RECOMMEND  LINK  PROFILE  OTHERS
<< June 2017 | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 >>
2016.02.05 Friday

スポンサーサイト

一定期間更新がないため広告を表示しています

2011.04.03 Sunday

【ファンクションポイント法】13.まとめ

ファンクションポイントの計算方法は以上です。

仕事を受注するのに必要かなと思っていたんですが、まず、基本設計が出来ていないとコレ、適用できませんね。。
で、基本設計をしたあとに見積もりをしているかというと、そんなプロジェクトはみたことがない。。
ステップカウントで、規模は出しますけど、それくらいかなあ。
それも、だいたい、品質の分析に使っていると思います。

仕事を受注するときの見積もりはというと、各工程にかかる人月を難易度づけして、求めてました。
では、この難易度の根拠はどこから算出したのか?
分からないので、聞いてみたいと思います。
会社の実績だったり、IPAの実績だったり、いろいろあると思いますが、まあ、見積もりはそれぞれであり、根拠を明確にすればいいのかなと感じました。
基準があれば、私もやれると思います。

テキストはまだ演習編へ続きます。
引き続き学びます。
2011.04.03 Sunday

【ファンクションポイント法】12.調整済みファンクションポイントの計算

未調整FP値とVAFから調整済みFP値を求める。
3つの計測タイプがある。

1.新規開発FP計測における計算法
新規開発におけるソフトウェアの規模。
システムアプリケーションと移行アプリケーションが対象。

DEP = (UFP + CFP) * VAF

DEP:新規開発FP計測のFP値
UFP:未調整FP値
CFP:データ移行機能のFP値
VAF:調整係数


2.機能拡張FP計測における計算法
機能拡張におけるソフトウェアの規模。
追加、変更、削除アプリケーションと移行アプリケーションが対象。

EFP = {(ADD + CHGA + CFP) * VAFA} + (DEL * VAFB)

EFP:機能拡張FP計測のFP値
ADD:追加導入される機能のFP値
CHGA:変更される機能のFP値
DEL:削除される機能のFP値
CFP:データ移行機能のFP値
VAFA:機能拡張FP計測後の調整係数
VAFB:機能拡張FP計測前の調整係数

3.アプリケーションFP計測における計算法
アプリケーション全体の規模。
初期と更新で2通りの計算方法を用いる。

・初期アプリケーションFP計測の計算
AFP = ADD * VAF

AFP:アプリケーションFP計測のFP値
ADD:未調整FP値
VAF:調整係数

・更新アプリケーションFP計測の計算
AFP = {(UFPB + ADD + CHGA) - (CHGB + DEL)} * VAFA

AFP:アプリケーションFP計測のFP値
UFPB:機能拡張FP計測前の未調整FP値
ADD:追加導入される機能のFP値
CHGA:変更される機能のFP値
DEL:削除される機能のFP値
CFP:データ移行機能のFP値
VAFA:機能拡張FP計測後の調整係数
2011.04.03 Sunday

【ファンクションポイント法】11.調整係数の計算

未調整FP値を補正する調整係数を求める。
→VAF(Value Adjustment Factor)

システムに関するGSCという14項目の特徴を評価し、0-5の評価点(DI:Degree Of Influence)をつけ、その合計(TDI:Total Degree Of Influence)からVAFを求める。

VAF = (TDI * 0.01) + 0.65

1.Data Communications(データ通信)
アプリケーションの通信度合い

0:バッチ処理のみ、またはスタンドアロン
1:バッチ処理だが、リモートでのデータ入力またはリモートでの印刷
2:バッチ処理だが、リモートのデータ入力およびリモートでの印刷両方
3:オンラインでデータ収集するか、バッチ処理のためのTP(遠隔操作)フロントエンド
4:フロントエンド以上の通信機能を持つが、1種類のTP通信プロトコルのみサポート
5:フロントエンド以上の通信機能を持つが、複数種類のTP通信プロトコルをサポート


2.Distributed Data Processing(分散処理)
アプリケーション構成要素間でのデータ転送の度合い

0:システム構成要素間でのデータ転送、データ処理機能に関与しない
1:PCの表計算やDBMSなどの構成要素でエンドユーザーコンピューティング(EUC)向けのデータを準備
2:エンドユーザーコンピューティング(EUC)のためではなく、データが転送のために準備され、システムのほかの構成要素に転送、処理される
3:一方向のみのオンラインでの分散処理とデータ転送あり
4:双方向でのオンラインでの分散処理とデータ転送あり
5:データ処理がシステムの最適な構成要素上で動的に実行


3.Performance(性能)
レスポンスタイム、スループットに対する要求おける開発影響の度合い

0:性能に対する特別な要求はない
1:性能条件と設計について要求が明言され、レビュー実施されるも、対応要求なし
2:レスポンスタイムまたはスループットがピーク時に厳しい状況だが、CPU使用率に対する設計上の特別な配慮は不要。処理の期限は翌営業日
3:レスポンスタイムまたはスループットが全業務時間中厳しい状況となるが、CPU使用に対する設計上の特別な配慮は不要。インターフェースをとっているシステムによって、処理の期限に制限あり
4:3に加え、ユーザーの指定した性能要件が厳しいため、設計段階で性能分析が必要
5:4に加え、ユーザーの指定した性能要件を満たすため、設計、開発、導入の段階で性能分析ツールを使用する必要がある


4.Heavily Used Configuration(高負荷構成)
コンピュータの資源制約における開発影響の度合い

0:運用上の制約は明示されておらず、暗黙的にもない
1:運用上の制約はあるが、通常よりも厳しくなく、特別の配慮は不要
2:セキュリティまたはタイミング上の配慮が必要
3:アプリケーションの特定部分に対して、特別なプロセッサ要件がある
4:指定された運用上の制約によって、セントラルプロセッサまたは専用プロセッサに関して特別の制約が必要
5:4に加えて、システムの分散構成要素に関してアプリケーションに特別な制約が必要


5.Transaction Rate(トランザクション量)
トランザクション量における開発影響の度合い

0:トランザクションのピーク期間はないと予測
1:トランザクションのピーク期間は、毎月、四半期、季節ごと、年に一回程度に予想
2:毎週トランザクションのピークがあると予想
3:毎日トランザクションのピークがあると予想
4:アプリケーションに対するユーザー要求、サービス契約の面でユーザーから高いトランザクション処理率が要求されるため、設計段階で性能分析作業が必要
5:4に加えて、設計、開発、導入の段階で性能分析ツールを使用する必要がある


6.Online Data Entry(オンライン入力)
データがインタラクティブに入力される度合い

0:すべてのトランザクションがバッチモードで処理
1:トランザクションの1〜7%がオンライン画面経由で入力
2:トランザクションの8〜15%がオンライン画面経由で入力
3:トランザクションの16〜23%がオンライン画面経由で入力
4:トランザクションの24〜30%がオンライン画面経由で入力
5:トランザクションの30%以上がオンライン画面経由で入力


7.End-User Efficiency(エンドユーザ効率)
ユーザの使いやすさやヒューマンファクターへの配慮の度合い

・以下の機能をカウント
メニュー、オンラインヘルプ、オンラインドキュメント、カーソル移動の自動化、スクロール、オンライントランザクションによる遠隔印刷、ファンクションキーの事前割当、オンライントランザクションからのバッチジョブ起動、画面上のデータのカーソルによる選択、反転表示、ハイライト表示、カラーアンダーライン表示およびその他の表示機能の多用、オンライントランザクションのユーザードキュメンテーションのハードコピー、マウスインターフェース、ポップアップウィンドウ、必要最小限の画面による業務機能の実現、二ヶ国語サポート(4項目としてカウント)、多言語サポート(6項目としてカウント)

0:機能のいずれも実現していない
1:機能の1〜3項目を実現
2:機能の4〜5項目を実現
3:機能の6項目以上を実現。しかし操作効率についてユーザーからの要求は特にない
4:機能の6項目以上を実現。さらに操作効率に対するユーザー要求が厳しいため、ヒューマンファクターに対する設計作業が必要である
5:4に加えて専用のツールおよび処理を用いて目的が達成されたことを証明する必要がある


8.Onlne Update(オンライン更新)
ILFがオンラインで更新される度合い

0:オンライン更新はない
1:1〜3のILFをオンラインで更新。更新量は少なく、回復は容易
2:4以上のILFをオンラインで更新。更新量は少なく、回復は容易
3:主要なILFをオンラインで更新
4:3に加え、データ損失保護が必須、特別な設計、プログラムあり
5:4に加え、更新量が多く、回復処理の費用面の考慮がなされている。オペレータの介在が最小となるような高度に自動化された回復手順が必要


9.Complex Processing(複雑な処理)
処理ロジック複雑さにおける開発影響の度合い

・以下の要素をカウント
 きめ細かい制御、または特有のセキュリティ処理
 広範な論理的処理
 広範な演算処理
 再処理が必要となる不完全トランザクションが原因での多くの例外処理
 多様の入出力機能を扱う複雑な処理

0:要素のいずれにも該当せず
1:要素のいずれか1項目に該当
2:要素のいずれか2項目に該当
3:要素のいずれか3項目に該当
4:要素のいずれか4項目に該当
5:要素の5項目すべてに該当


10.Reusability(再利用可能性)
アプリケーションを他アプリケーションでも利用可能とする場合の特別な配慮の度合い

0:再利用できるコードはない
1:再利用できるコードがアプリケーション内で使用されている
2:アプリケーションの10%未満で複数のユーザーのニーズを考慮
3:アプリケーションの10%以上で複数のユーザーのニーズを考慮
4:アプリケーションは再利用し易くするために特別なパッケージ化および文書化がされている。またアプリケーションはソースコードレベルでユーザーによりカスタマイズされる
5:アプリケーションは再利用し易くするために特別なパッケージ化および文書化がされていて、アプリケーションのカスタマイズはユーザーのパラメータ維持管理で可能


11.Installation Ease(インストール容易性)
前環境からの移行難易度における開発影響の度合い

0:導入に対してユーザーの特別な指定、特別な設置作業も不要
1:導入に対してユーザーの特別な指定はないが、特別なセットアップが必要
2:移行および導入にユーザー指定があり、移行および導入ガイドを提供するとともにテストされている。プロジェクトに対する移行の影響は重大ではない
3:移行および導入にユーザー指定があり、移行および導入ガイドを提供するとともにテストされている。プロジェクトに対する移行の影響は重大である
4:2に加えて、自動移行および自動導入ツールを提供するとともにテストされている
5:3に加えて、自動移行および自動導入ツールを提供するとともにテストされている


12.Operational Ease(運用性)
起動、バックアップ、復旧などの運用における開発留意の度合い

0:通常のバックアップ手続き以外、ユーザーからの運用上の指定は特にない
1〜4:アプリケーションに適用される項目を以下から選択。各項目1度数としてカウント。1.効率的な始動、バックアップ、回復処理が提供されているが、オペレータの介入も必要。2.効率的な始動、バックアップ、回復処理が提供されており、オペレータの介入が不要(2度数としてカウント)。3.アプリケーションは、テープマウントの必要性が最小限になるようにしている。4.アプリケーションは用紙操作の必要性が最小限になるようにしている。
5:アプリケーションは無人操作となるように設計されている。無人操作とは、アプリケーションの始動、シャットダウン以外はオペレーターがシステムを操作する必要がないことを意味する。自動エラー回復機能付アプリケーション。


13.Multiple Sites(複数サイト)
アプリケーションの利用度合い

0:複数サイトへの導入の要求はない
1:複数サイトへの必要性を考慮し、アプリケーションは同一のハードウェア、ソフトウェア環境だけで運用するように設計されている。
2:複数サイトへの必要性を考慮し、アプリケーションは類似のハードウェア、ソフトウェア環境だけで運用するように設計されている。
3:複数サイトへの必要性を考慮し、アプリケーションは異なるハードウェア、ソフトウェア環境だけで運用するように設計されている。
4:複数サイトでアプリケーションを使用するためのドキュメントとサポート計画が提供され、テストされている。アプリケーションの状態は1と2の記述の通り。
5:複数サイトでアプリケーションを使用するためのドキュメントとサポート計画が提供され、テストされている。アプリケーションの状態は3の記述の通り。


14.Facilitate Change(変更容易性)
アプリケーション変更を容易さの度合い

・以下の特性をカウント
 簡単な要求(eg-1つのILF)を処理するための柔軟な照会、レポート機能を提供
 平均的な要求(eg-複数のILF)を処理するための柔軟な照会、レポート機能を提供
 複雑な要求(eg-複数のILFに対する複数のロジック)を処理するための柔軟な照会、レポート機能を提供
 オンライン対話型処理によりユーザーが保守できるように、制御データが保持されるが、反映されるのは翌営業日
 オンライン対話型処理によりユーザーが保守できるように、制御データが保持され、直ちに反映される

0:特性のいずれにも該当しない
1:特性のいずれか1項目に該当
2:特性のいずれか2項目に該当
3:特性のいずれか3項目に該当
4:特性のいずれか4項目に該当
5:特性のいずれか5項目に該当

2011.04.03 Sunday

【ファンクションポイント法】10.未調整ファンクションポイントの計算

ファイル、アプリケーションで求めたFP値を合計し、それを未調整FP値とする。
2011.04.03 Sunday

【ファンクションポイント法】9.トランザクショナルファンクションの計測

アプリケーション境界ごとの要素処理の計測する。
要素処理の単位で、どれだけの情報をやりとりするかを値化。

1.アプリケーションに存在する要素処理を抽出
要素処理は「アプリケーション境界の決定」で抽出済み
【ファンクションポイント法】7.計測範囲の決定、アプリケーション境界の決定


2.要素処理をEI、EO、EQのいずれかに区別
要素処理を以下のいずれかに決定する。
・EI(外部入力)
→データ入力を受け付ける。

・EO(外部出力)
→データを加工し、出力する。

・EQ(外部照会)
→データを加工しないで出力する。


3.要素処理のデータエレメントタイプとファイルタイプリファレンスを数える
・DET(Data Element Type)
→要素処理がアプリケーション境界をまたいで使用し、かつユーザが認識できる繰り返しのないデータのフィールド数。
 ボタンなどのトリガーも1と計上する。
 ユーザが認識できるフィールドであるが、キー値も1と計上する。

・FTR(File Type Reference)
→要素処理が参照、更新などでアクセスするファイル数。

を計測し、要素処理の複雑度を求める。


4.要素処理の複雑度を求める
以下の表から要素処理の複雑度を求める。
・EIの複雑度の求め方

1 - 4DET5 - 15DET16以上DET
0 - 1 FTRLowLowAverage
2FTRLowAverageHigh
3以上FTRAverageHighHigh

・EO、EQの複雑度の求め方

1 - 5DET6 - 19DET20以上DET
0 - 1 FTRLowLowAverage
2 - 3FTRLowAverageHigh
4以上FTRAverageHighHigh


5.複雑度から要素処理のFP値を求める
以下の表から要素処理のFP値を求める。
・FP値の求め方

LowAverageHigh
EI346
EO457
EQ346
2011.01.10 Monday

【ファンクションポイント法】8.データファンクションの計測

アプリケーション境界決定後に、データファンクションの計測を行う。
データファンクションには、前述したとおり、以下の2つがある。
 ・内部論理ファイル(Internal Logical File:ILF)
 ・外部インタフェースファイル(External Interface File:EIF)

それぞれに対し、以下の手順で計測する。
1.アプリケーションがアクセスするファイルを抽出する。
 →ユーザが認識するものとなるので、テンポラリなどは含まない。

2.出されたファイルがILFとEIFのどちらかを区別する。
 →ILFは、アプリケーションがファイルを維持管理する(追加、変更、削除を行う)もの。
  EIFは、アプリケーションがファイルを維持管理しない(参照を行う)もの。

3.ファイルのデータエレメントタイプ(DET)とレコードエレメントタイプ(RET)を算出する。
 →DETは、ファイルのフィールド数。
  RETは、ファイルのフィールドのサブグループ数。
  サブグループとは、データ項目を更に構成する下位のデータグループ。

4.ファイルの複雑度を求める。
Low, Average, Highを以下の表から求める。

1 - 19DET20 - 50DET51以上DET
1RETLowLowAverage
2 - 5RETLowAverageHigh
6以上RETAverageHighHigh


5.複雑度からファイルのFP値を求める。

LowAverageHigh
ILF71015
EIF5710

2011.01.07 Friday

【ファンクションポイント法】7.計測範囲の決定、アプリケーション境界の決定

ファンクションポイント法で計測を行うにあたり、計測範囲を定義する。
・計測範囲の決定
 ユーザ視点でシステムの機能を決定する。
 過不足のないこと。

・アプリケーション境界の決定
 計測範囲のシステムから、アプリケーションというFP値の算出単位でグループ化する。

・要素処理への落とし込み
 アプリケーションを要素処理(elementary process)に分割する。
 要素処理とは、
  ユーザにとって意味のある最小単位のアクティビティである。(CPMの定義)


単位としては、システムがあり、システムの中にアプリケーションがあり、アプリケーションの中に要素処理が存在する。
つまり「システム→アプリケーション→要素処理」の順に機能を細分化する。
2011.01.06 Thursday

【ファンクションポイント法】6.FP計測タイプの決定

ファンクションポイント法で計測を行うにあたり、システム開発の工程により、3つの計測タイプが存在する。
1.新規開発FP計測(Development Project Function Point Counting)
 対象:新規開発+導入
 実施フェーズ:要件定義フェーズで実施

2.機能拡張FP計測(Enhancement Project Function Point Counting)
 対象:拡張機能+導入
 実施フェーズ:保守・運用

3.アプリケーションFP計測(Application Function Point Counting)
 対象:システム全体
 実施フェーズ:導入後

それぞれで、計測範囲が異なる。
1.2.での実施は予算を見積もるために必要なのは分かる。
3.は実績値を残すためにやるのだろうけれど、現場はそんな暇がない状況になりがち。。
2011.01.06 Thursday

【ファンクションポイント法】5.計測の流れ

ファンクションポイント法での、計測の流れについて示す。
詳細は後述。

1.FP計測タイプの決定
タイプは、
 1.新規開発計測
 2.機能拡張測定
 3.アプリケーション測定
の3つがある。


2.計測範囲の決定、アプリケーション境界の決定
計測対象を明確化する = 実装範囲の決定


3.データファンクションの計測
未調整ファンクションポイント(Unadjusted Function Point(UFP))のうち、
・ILF(Internal Logical File) → 内部論理ファイル
・EIF(External Interface File) → 外部インタフェースファイル
を測定する。
※CPMは、3.概要に前述


4.トランザクショナルファンクションの測定
未調整ファンクションポイント(Unadjusted Function Point(UFP))のうち、
・EI(External Input)  → 外部入力
・EO(External Output) → 外部出力
・EQ(External inQuiry) → 外部照会
を計測する。
※CPMは、3.概要に前述


5.未調整ファンクションポイントの計算
3および4で計測した未調整ファンクションポイントを合計する。


6.調整係数の計算
システムの難易度を示す調整係数(Value Adjustment Factor(VAF))を求める。
調整係数は、アプリケーションに見られる一般的特徴14項目を0〜5のレベルで評価し、それらを合計した値(Toral Degree of Influence(TDI))を以下の式に代入して求める。

VAF = (TDI * 0.01) + 0.65

VAFは、0.65〜1.35となる。(5で求めたFP値が±35%になるということ)


7.調整済みファンクションポイントの計算
調整済みファンクションポイント(Adjusted Function Point)を未調整ファンクションポイント、調整係数、計測タイプから算出する。
2011.01.06 Thursday

【ファンクションポイント法】4.ユーザ視点

ファンクションポイント法では、ユーザが認識するソフトウェアの機能を単位として見積もりを行う。
ユーザが認識するとは、
・ビジネス機能を記述するものである
・ユーザによって認識されるものである
・FP値を測定するために利用するものである。
・その物理的な表現はさまざまなものである。例えば、要求仕様であったり、詳細な仕様であったりする。
→システムの内部の作り込みは対象外ってことですね。

エンドユーザの要求となるビジネス的な概念と、開発者の技術的視点でのすり合わせを充分に行った上で、仕様を決定する。
→これは、要件定義の難しいところでありますね。
Powered by
30days Album
PR