決算の数字をよくすることは、IT部門にとっても企業レベルの組織全体にとっても同じように重要なことだ。ITのフレームワークの中で健全な財務管理を実現することには、単なる効率以上の幅広い事柄が含まれており、多くの要素が関係している。IT費用の主要因を理解すること、IT関連予算支出計画を全体的な事業戦略と結びつけること、財源を効率的に使うこと、IT費用を投資と見なしその成果を追跡する手続きを持つこと、IT投資判断を行うための健全な手続きを実現することなどがこれに含まれる。プロジェクト費用の見積もりは戦いの半分に過ぎない。プロジェクトの最中や納品後にその費用をコントロールすることも、同様に大事なことだ。この記事では、全体的なIT財務管理の信頼できる土台の一部として、費用の予測と管理を行ういくつかの手法を検証する。 1．基準コストを管理する 既存のITシステムの維持のために支払わなければならない義務
記者は日経SYSTEMS7月号（6月26日発売）で「自信が持てる見積もり技術」という特集を担当した。そこで強く感じたのは，いわゆる「KKD（勘・経験・度胸）」は本当に必要ないのか，ということだった。 ある中堅ベンダーのプロジェクト・マネージャ（PM）は，ため息交じりにこうつぶやく。「勘や経験に頼っていたときの方がよっぽど精度が高かったよ」――。同社では昨年より，FP（Function Point）法とWBS（Work Breakdown Structure）を標準的な見積もり技法に定めた。だが，逆に見積もりの“ブレ”が大きくなったという。 別のメーカーの見積もり担当者は，会社から指定された見積もり支援ツールを使って規模や工数を算出している。しかし，算出手順がブラックボックス化したため，「ユーザーに根拠を聞かれても『ツールを使うとこうなる』としか言いようがない」（ある見積もり担当者）と話す。
最終更新日：2006.10.19 - 渕田孝康 ソフトウェアのライフサイクル 一般に、ソフトウェアには次のようなサイクルがあるといわれる。 PM-図1 ソフトウェアの開発には時間がかかるものであり、以前のソフトを改良しつつ使いまわすケースが多い。要求が発生してからソフトウェアが作成され、何年かに渡って修正や改良を繰り返し、最後に廃棄されるまでの過程をソフトウェアのライフサイクルと呼ぶ。 ライフサイクルの各工程について簡単に述べる。 要求分析 発注者（顧客）がそのソフトウェアを使って行いたいこと（業務）を明確にし、ソフトウェアが満たすべき機能を決定する。 システム設計 要求をどのようにして機能として実現するかを決定する。この段階で利用者とシステムの情報交換の方法（ユーザーインターフェイス）を決定することが多い。 プログラム設計 機能をどのようにプログラムで実現するかを決定する。複雑なソフトウ
サマリー �@FP計測のタイプの決定 タイプ1) 新規開発計測 タイプ2) 機能拡張計測 タイプ3) アプリケーション計測 �A計測範囲の決定、アプリケーション境界の決定 計測範囲を明確にする為にアプリケーション境界を決定する。 �Bデータファンクションの計測 FP計測２つの計測対象の１つ ILF(Internal Logical File):追加・更新・削除など操作対象となるファイル EIF(External Interface File):参照されるファイル データエレメントタイプ(DET)：繰り返しを含まないデータ項目 レコードエレメントタイプ(RET)：繰り返しのあるデータ項目 ■ILF、EIFの複雑度 1〜19 DET 20〜50 DET 51以上DET 1 RET
１．ソフトウェア開発環境の変化と見積手法 ソフトウェアの開発形態がメインフレーム（以下Ｍ/Ｆ）からクライアントサーバ（以下Ｃ/Ｓ）に移ってきている中で、プログラムレベルでは、開発方法が手続き（コード）記述ベースからビジュアル開発ツールベースにシフトしてきている。このため、ソフトウェア規模・工数の見積を行う際に、これまでの事実上の標準だった「LOC（Lines of Code:プログラム行数のこと）」を使うことが困難になってきている。こうした中で、ソフトウェアの持つ機能を数えることでソフトウェアの規模を測る尺度「ファンクションポイント法(以下ＦＰ法)」が現在その後を埋める有力候補となっている。 当部では、ＦＰ法の普及動向を把握するため、見積手法に関するアンケート調査、ＦＰ法先行導入企業に対するヒアリング調査を行ったので、ここにご紹介する。 ２．ファンクションポイント法とは ＦＰ法は
ファンクションポイント法とは、ソフトウェアの規模（大きさ）をそのソフトウェアが持っている機能を元に測るための手法です。ソフトウェアという目に見えないものの大きさを測るのは難しい事ですが、現在ISOでも検討が進められており、このファンクションポイント法をベースとした「機能的規模計測」として標準化される見込みです。 ファンクションポイント法の概要については、こちらをご覧下さい→ファンクションポイント法
[Programs] / 最終更新時間：2004年06月24日 23時45分47秒 概要 最近、開発効率をなんとかしたいという思いが強くていろいろ調べている。どの手法を使うとどうなるのかが分からないと判断がつかない。そこで開発効率を測る物差しとしてファンクションポイント(FP)法に注目してみた。 よりよい開発のあり方については、楽しいプロジェクト運営もどうぞ。 目次 概要 目次 参考本 現状 ソフトウェアの規模 注意すること FP法の用語 用語の言い換え データファイル 要素処理 FP値の計測手順 どんなレポートを書くか？ プロジェクト見積もり 1. FPの計測タイプを識別する 2. 計測範囲とアプリケーション境界を識別する 3. すべてのデータファイルと、その複雑度を識別する ファンクションポイント計測一覧表-ファイルをリスト化 ファンクションポイント計測一覧表-ファイルの複雑度を加える
◆ＦＰ法の全体像 まず、ファンクションポイントの説明をする前に、システムの機能とは何かを説明しておく。システムの機能とは、 ユーザが要求する効用 のことである。 ファンクションポイント（ＦＰ）法が注目されているのは、ＦＰ法が計測対象としている機能が「ユーザからみて」の基準というところに最大のポイントがある。機能は量として計測して、機能量（Functional Size）という形で表現する。 機能量の意味は、工数ではない中間的な量であり，プラットホームに依存しにくいことである。また、ユーザとシステム開発者の見積もりの意識あわせにもつながっていく。 ＦＰ法は機能を一旦、機能量で表現しておき、そこから、本来の見積もり目的である、規模（例えば、行数）や工数に換算する見積もり手法である。図にＦＰ法の全体像を示す ※ 児玉公信「システム開発の見積もりのための実践ファンクション
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
