┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
┃ ■┃
●┃● ● オ ブ ジ ェ ク ト 倶 楽 部 ■ ┃
┃ ■ ┃
┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
No.63 2004/09/22
━お 詫 び━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
前回のメールマガジンにて掲載されました
【プログラミング】JVMで動く新言語、Groovy!!の著者名が編集上のミスで
記載が漏れてしまいました。著者は、懸田です。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■ I N D E X
┃
┣【見積もり手法】実践！ソフトウェアの見積もり手法［4］
┣【プログラミング】コード＝カタで目指せ達人プログラマ [番外]
┗【アンケート】気になるシステム業界 ホントのところ
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━1 s t ■━
■
┗【見積もり手法】実践！ソフトウェアの見積もり手法［4］
さまざまな見積もり手法を知ろう！(その2)
□ 前回のおさらい
前回(メルマガ59号：2004/08/25)では、デルファイ法をご紹介しました。デル
ファイ法は、「経験・実績ベース」の主観的な見積もり手法で、複数の専門家
の意見を集合することにより、個人で見積もるよりもさらに精度の高い見積も
り値を得ることが可能になるというお話でした。
今回は予告通り、ファンクションポイント法[*1]をご紹介します。
ファンクションポイント法は、1970年代後半から1980年代前半にかけて、
A. J. Albrecht氏がアプリケーションプログラムの大きさをプログラムの入出
力とデータの集合(ファイル)によって推定する手法として考案したものです。
米国にあるIFPUG(International Function Point Users Group) [*2]では、
A. J. Albrecht氏の考え方を引き継いでさらに発展させています。
□ ファンクションポイント法
ファンクションポイント(以下、FP)法は、下記の表(前回ご紹介した表)からも
分かるように客観的な見積もり手法であり、「開発規模」を推定するものです。
デルファイ法と同様に「開発規模」を推定する手法ではありますが、客観的な
視点でシステムの特徴を抽出して見積もりを行うという点において、異なる手
法といえます。
┏━━━━┳━━━━━┳━━━━━┓
┃ ┃客観的 ┃主観的 ┃
┣━━━━╋━━━━━╋━━━━━┫
┃開発規模┃FP ┃デルファイ┃
┣━━━━╋━━━━━╋━━━━━┫
┃開発工数┃COCOMO/UCP┃WBS ┃
┗━━━━┻━━━━━┻━━━━━┛
FP法は、ソフトウェアが取り扱うデータタイプから機能量を測定し、ソフトウ
ェア規模を推定する手法です。算出手順は以下の通りです。
【手順1】境界の設定
対象ソフトウェアの範囲(ソフトウェア境界)を明確にします。
【手順2】ユーザ機能の抽出
ソフトウェア内のデータタイプからユーザ機能を抽出します。データタイプに
は以下の5つがあります。
[1]内部論理ファイル(ILF)：該当アプリケーションが維持管理するデータ
の集合
[2]外部インタフェイスファイル(EIF)：外部アプリケーションで維持管理
されており、該当アプリケーションから参照のみ行うデータの集合
[3]外部入力(EI)：ILFを更新するためのデータ入力機能
[4]外部出力(EO)：該当アプリケーションが外部へデータを出力する機能
[5]外部照会(EQ)：入力と出力が一体になったデータ処理機能
【手順3】ユーザ機能量の算出
手順2で抽出したユーザ機能を、単純・平均・複雑の3種類の複雑さに分類し、
評価点を与えます。評価点は、以下に示す通り、データタイプごとに異なりま
す。
[1]内部論理ファイル(ILF)： 単純7点、平均10点、複雑15点
[2]外部インタフェイスファイル(EIF)： 単純5点、平均7点、複雑10点
[3]外部入力(EI)： 単純3点、平均4点、複雑6点
[4]外部出力(EO)： 単純4点、平均5点、複雑7点
[5]外部照会(EQ)： 単純3点、平均4点、複雑6点
複雑度を決定した後、ユーザ機能に与えられた評価点の合計値を計算します。
この合計値を、「調整前のFP」といいます。
【手順4】システム特性の評価
手順3では「調整前のFP」を算出しました。なぜ「調整前」なのでしょうか?
それは、手順3の結果では、まだシステムの特性が反映させてないからです。
そこで、システムの特性を考慮した調整を行います。システム特性として14項
目があります。14の項目すべてをここではご紹介はできませんが、以下に一部
をご紹介します。
システムの特性(一部)：
・オンライン処理機能(データ通信を行っているか)
・処理の複雑性(複雑な処理を行うか)
・プログラムの再利用性(再利用を考慮して設計を行うか)
14のシステムの特性ごとに影響度を6段階(0：影響なし、1：影響度軽微、2：影
響度小、3影響度中、4：影響度大、5：影響度重大)で評価します。
【手順5】システム全体のFPの算出
調整係数を算出します。調整係数は以下の通りになります。影響度合計は0〜70
点の範囲になるので、調整係数は0.65〜1.35の範囲になります。つまり、シス
テムの特性を考慮することにより、「調整前のFP」を±35%の範囲で調整します。
これが「調整済みFP」になります。
(調整係数) ＝ (影響度合計) × 0.01 ＋ 0.65
(調整済みFP) ＝ (調整前のFP) × (調整係数)
【手順6】開発規模の算出
FP法は、開発規模(ソースコード行数：LOC)を算出することができます。ただ
し、過去の経験から1FPあたりのLOCを準備しておく必要があります。1FPあた
りのLOCは言語によって大きく異なりますので、言語ごとの経験データが事前
に必要になります。
□ まとめ
今回は、「ファンクションポイント法」のご紹介をしました。一通りの算出手
順は理解していただけたと思います。
冒頭で「客観的な見積もり手法」とご紹介しましたが、厳密にはデータタイプ
(ユーザ機能)とシステム特性を客観的に抽出する一方で、複雑度や影響度の算
出方法については見積もりする人の主観に依存するのです。
ファンクションポイント法は、機能拡張されるソフトウェア開発よりも、新規
開発の見積もりに対して有用です。また、データタイプの抽出は、開発初期の
あいまいな要求仕様書などがもとになることが多く、しかも複雑度や影響度の
判断も難しいことから、経験豊かなファンクションポイントの専門家がいたほ
うが、より精度の高い結果が得られます。
□ 次回の予告
次回は、「COCOMO(COnstructive COst MOdel)」をご紹介します。「COCOMO」は
「ファンクションポイント法」同様に客観的な視点で見積もりをする手法です
が、コストに与える影響として、システムの特性だけでなく、開発要員・プロ
ジェクト・開発工程の特性を組み込んでいるのが大きく異なっている部分と言
えます。次回をお楽しみに。(中村)
[*1] ソフトウェアマネジメントモデル入門 共立出版社
[*2] International Function Point Users Group http://www.ifpug.org/
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://www.ObjectClub.jp/cgi-bin/question.cgi?J001+3+0
普通：
http://www.ObjectClub.jp/cgi-bin/question.cgi?J001+3+1
イマイチ：
http://www.ObjectClub.jp/cgi-bin/question.cgi?J001+3+2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2 n d ■━
■
┗【プログラミング】コード＝カタで目指せ達人プログラマ [番外]
■ はじめに
この連載では、かつてDave"達人"Thomasによるコード＝カタを筆者による乱暴
な要約でお届けしていたのですが、本業と余興[*1]にかまけて久しくサボって
いました。今回は達人の新刊を紹介します。といっても手元に現物はありませ
んが、「読書感想文は１行読めば書ける！」[*2]ならば「技術書紹介は目次を
読めば書ける！」んです。
■『Programming Ruby 2nd Edition』
来る10月3日、海の向こうでは「PickAxe本」[*3]、本邦では「ウサギ本」の通
称で御馴染みの『プログラミングRuby』の第2版が出版されます[*4]。
第1版が564頁であったのに対し、第2版は872頁と大幅に増量しています[*5]。
話が前後してしまいましたが、Rubyはまつもとゆきひろ氏が開発しているオブ
ジェクト指向スクリプト言語です。"エンジニア界のFowler"こと
Martin Fowlerも「オブジェクト指向を学ぶのに最適な言語」として推薦して
います(断言)[*6]。本メルマガの購読者の皆さんにもきっと気に入ってもらえ
る言語だと思うのですが、いかがでしょう。
■ 勝手にChangeLog
では、分量が300頁以上増えている第2版はどこが変っているのでしょうか？
目立つところでは、第1版出荷後にRuby 1.8がリリースされたので、それに合わ
せた改訂がなされています。が、それだけで300頁増量というわけではありませ
ん。目次をみると全体の章および付録の数は変っていない(27章＋付録A〜C)の
ですが、構成や順序が微妙に、しかし明確な意思と方向性を持って改訂されて
います。
個人的にポイントだと思うのは:
1. もっとRubyらしく
2. ドキュメントとパッケージング
の2点です。以下で順番に説明します。
■ もっとRubyらしく
第1部にTest::Unitによるユニットテストの章が追加されています(!!)。第1版
では付録扱いだったirbやirbsh(対話型Rubyシェル)が本文に昇格。トラブルシ
ュートの章も第1版よりも手厚くなっています。
単なるプログラミング言語の利用と言語仕様やライブラリの解説を超えた
「コードを、テストを書け！オブジェクトを触れ！」という野心が伝わってき
ます。
そして「DUCK TYPING」[*7]の章が新たに書き下ろされています。
* クラスは型ではない
* Rubyにはインターフェースが無い(というかすべてがインターフェース)[*8]
という、クロージャ(ブロック付きメソッド呼び出し)と並ぶ「Rubyらしさ」の
解説に期待が高まります。
■ ドキュメントとパッケージング
RDoc[*9]によるドキュメンテーションや、RubyGems[*10]によるパッケージ管理
に章が割かれ、付録では第1版のirbに代わってmkmf[*11]のリファレンスが収録
されました。
英語圏では「言語は良いけどドキュメントが足りない」と嘆かれることの多さ[*12]
を反映してのことだと思います。ドキュメンテーションは言うまでもありませ
んが、パッケージングも利用方法の簡易性・一貫性の観点からは重要です。
海の向こうでRubyは、新しい物好き[*13]が使う言語から、より幅広い人びとに
利用される言語へと成長することを志向しているのだと思います。
■ まとめ
10/3に発売される『Programming Ruby 2nd Edition』の改訂点を目次から邪推
しました。今回の改訂は、言語のバージョンアップに伴う改訂に留まりません。
プログラミング言語としてのRubyを (1) より「Rubyらしく」使えるように、
(2)より簡単で一貫した使い方ができるように、配慮した野心的な改訂です。
本メルマガ読者の皆さんならきっとRubyを気に入ってもらえると思います。
(かくたに＠日本Rubyの会会員[*14])
*1: http://www.kakutani.com/articles/LLW2004-LanguageUpdate-Groovy.live.pdf
*2: http://www.ne.jp/asahi/ymgs/hon/index03_kansou.htm
*3: http://www.amazon.co.jp/exec/obidos/ASIN/0201710897/xpjp-22/
本書のHTML版が http://www.rubycentral.com/book/ 等から参照できます。
Debianなら apt-get install rubybook で取得できます。
*4: http://www.pragmaticprogrammer.com/titles/ruby/index.html
Amazon.co.jp: http://www.amazon.co.jp/exec/obidos/ASIN/0974514055/xpjp-22/
第1版の邦訳: http://www.amazon.co.jp/exec/obidos/ASIN/4894714531/xpjp-22/
*5: 第1版の著者はDave ThomasとAndy Huntの『達人プログラマー』コンビでしたが、
第2版では新たに"Ruby界のFowler"ことChad Fowlerが加わっています。
*6: http://capsctrl.que.jp/kdmsnr/wiki/bliki/?LanguageForLearningObjects
*7: http://c2.com/cgi/wiki?DuckTyping
*8: http://www.sgtpepper.net/hyspro/diary/20040918.html#p01
*9: http://rdoc.sourceforge.net/ Javadocみたいなものだと思ってください。
*10: http://rubygems.rubyforge.org/wiki/wiki.pl
新世代のRubyパッケージシステムです。
*11: http://www.ruby-lang.org/ja/man/index.cgi?cmd=view;name=mkmf.rb
*12: 最近だと、http://kumiki.c.u-tokyo.ac.jp/~ichiyama/mt/archives/000007.html
*13: といってもRubyには10年以上の歴史があるのですが:
http://www.ruby-lang.org/ja/20030224.html
*14: http://jp.rubyist.net/
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://www.ObjectClub.jp/cgi-bin/question.cgi?E004+4+0
普通：
http://www.ObjectClub.jp/cgi-bin/question.cgi?E004+4+1
イマイチ：
http://www.ObjectClub.jp/cgi-bin/question.cgi?E004+4+2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━3 r d ■━
■
┗【アンケート】気になるシステム業界 ホントのところ
今週は「どのUML図を一番よく使いますか？」のホントのところ。
ユースケース図。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+28+0
クラス図。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+28+1
オブジェクト図。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+28+2
パッケージ図。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+28+3
シーケンス図。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+28+4
コラボレーション図。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+28+5
ステートチャート図。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+28+6
アクティビティ図。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+28+7
コンポーネント図。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+28+8
配置図。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+28+9
UML図は使いません。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+28+10
それは秘密です。
http://www.ObjectClub.jp/cgi-bin/question.cgi?Z001+28+11
ちょっと語らせて！
editors@ObjectClub.jp まで詳細を！！
アンケート結果はオブジェクト倶楽部サイト上にて公開します。お楽しみに。
なお、前号「オブジェクト指向(Object-Orinted)という概念があるのを初めて
知ったのはいつ？」の結果は公開中。是非ご覧下さい。
⇒http://www.ObjectClub.jp/special/kininaru
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記
こんにちは、編集人です。今週はとても短い一週間ですね。お休みが多くて嬉
しい反面、大忙しではありませんか？
「もー、間に合わん！でも間に合わせる！」というような状況のとき、皆さん
はどうされますか？すごく時間のないとき、例えば寝坊して起きたときなどは、
思いがけなく、はやく出発できますよね(笑)。そういうときのものすごいスピ
ードは、大抵、必要最低限の行動のみとった結果から出てきたことが多いです。
豊かな人生には無駄が不可欠ですが、時間のないときは、無理をして頑張るか、
思い切って何かを切り取ってしまうか、になります。皆さんは、大忙しの時に
何を選んだか、後で考えることはありますか？最近、後でゆっくり考えてみる
と大事なものを切り取っていたのかもしれないなーと思うことがあります。必
要最低限のもの、というのは、状況によって変わり、急いでいると、とっさに
習慣づいているものを選び取ってしまいます。休みの期間は、忙しい時に落と
した落し物も拾えるといいですよね。
今週の強引な一言
*** 馬には乗って見よ人には沿うて見よ（ことわざ） ***
なんとなくとっつきにくいからといって、距離をとっている人っていませんか。
まずは、話しかけてみてはどうでしょう。それから距離をとっても遅くはない
でしょう。もしかしたら、共通の趣味があることに気付いて、仲良くなれるか
もしれませんよ。（さわ）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒http://www.ObjectClub.jp/community/object_ml/help/
〇 免責事項、過去の記事は ⇒http://www.ObjectClub.jp/community/object_ml/
■ 発行：オブジェクト倶楽部 ⇒http://www.ObjectClub.jp/
■ 編集代表：平鍋 健児
Copyright (c)2003-2004 オブジェクト倶楽部. All Rights Reserved.
powered by Eiwa System Management, Inc.