Android案件を見積もる場合に考えておくことリスト - Qiita
アプリ自体のコーディング見積もりのみに注力してしまうと忘れがちで、たまにつらい目に遭うので、必要に応じて追加していく予定。 アプリ仕様 仕様はそもそも決まっているか 「仕様は決まっている。動かない」「移植なのでこれ以上はありません」と言ったな。 それは嘘だ。 既に仕様がガッチリ確定していることはありえない。要求仕様（必要機能リスト）がある程度固まっているならばまだ良い方で、「今から仕様を一緒に考えていきましょう」「アイディアレベルです」まで様々。 その他にも、GCM/FCM等のアプリ外サービスと連携する場合、遅延コスト等どの程度許容できるかも事前に確定させる。特にプッシュ系サービスでは、ありえないレベル（全端末遅延1秒以内必須、とか）を既定路線に含めないように留意する。 改修か、新規開発か これは見積もりの前提として大きな影響力をもつ。 テクノロジーや設計の自由度・柔軟性をある程度コントロ
フィボナッチ工数見積は「完成させます！（徹夜で）」という無理ゲーによる弊害を最小化するプロジェクトマネージメント手法 - ベルリンのITスタートアップで働くジャバ・ザ・ハットリの日記
今まで数々のプロジェクトマネージャーとそのプロジェクトマネージメント手法に翻弄されてきたが、現在の勤め先であるベルリンのITスタートアップで取り入れている手法が歴代の中でも一番マシ。まず工数見積がとても洗練されている。エンジニアが無理やりに「今週中に完成させます！」と言わされて、結局はその約束が守りきれずに翻弄される、というような弊害が最小化できているな、という話。 プロジェクトマネージメントチームのメンバー達はその見積方法を「フィボナッチ」と表現している。 だいたい工数見積なんてものが正確にできる人に出会ったことが無い。複雑なITプロジェクトの全体像を把握して「これをうちのチームで完了するためには＊＊日を要する」なんてピタッと当てたためしがない。絶対にズレる。 エンジニアに向かって「お前さー『今週中に完成させます』って言ったよな？誰だっけ、それ言ったの？オレじゃねーよ。お前だよ。おめーの
ＩＦＰＵＧ法でのＦＰ算出 - Xupper技術サポート部のページ
あっ！肝心のＩＦＰＵＧ法でのＦＰ見積りについて紹介するのを忘れていました・・・ これまで、ＩＦＰＵＧが規定しているＦＰ見積りの手順が既知のものであるという前提で、各種見積り方法を紹介してきましたが、ツールでのＦＰ算出の方法を紹介する前に、ここで、ＩＦＰＵＧで規定されている手順について解説（復習）しておきたいと思います。 ＩＦＰＵＧ法での見積り手順は以下のとおりです。 1.ＦＰ計測種別の決定 2.アプリケーション境界の決定 3.データファンクションのＦＰ算出 3.1 データファンクションの識別（ＩＬＦとＥＩＦの識別） 3.2 データファンクションの複雑度の判定 3.2.1 データファンクションのDET数識別 3.2.2 データファンクションのRET数識別 3.2.3 データファンクションの複雑度判定 3.3 データファンクションのＦＰ判定 4.トランザクションファンクションのＦＰ算出 4.1
FP法について - Writing Cafe
[Programs] / 最終更新時間：2004年06月24日 23時45分47秒 概要 最近、開発効率をなんとかしたいという思いが強くていろいろ調べている。どの手法を使うとどうなるのかが分からないと判断がつかない。そこで開発効率を測る物差しとしてファンクションポイント(FP)法に注目してみた。 よりよい開発のあり方については、楽しいプロジェクト運営もどうぞ。 目次 概要 目次 参考本 現状 ソフトウェアの規模 注意すること FP法の用語 用語の言い換え データファイル 要素処理 FP値の計測手順 どんなレポートを書くか？ プロジェクト見積もり 1. FPの計測タイプを識別する 2. 計測範囲とアプリケーション境界を識別する 3. すべてのデータファイルと、その複雑度を識別する ファンクションポイント計測一覧表-ファイルをリスト化 ファンクションポイント計測一覧表-ファイルの複雑度を加える
見積もり、まずはざっくり理解せよ
2009年度から適用される工事進行基準が、ソフトウェアの開発現場に大きな影響を与える。そこで本連載では、工事進行基準を採用する際に重要になるいくつかの項目のうち、見積もりに関して解説する。 (2/2)
「総工数(人月)＝0.97×画面数＋0.26×バッチ数」─JUASソフトウェアメトリックス調査から | IT Leaders
IT Leaders トップ ＞ テクノロジー一覧 ＞ システム開発 ＞ 調査・レポート ＞ 「総工数(人月)＝0.97×画面数＋0.26×バッチ数」─JUASソフトウェアメトリックス調査から システム開発 システム開発記事一覧へ [調査・レポート] 「総工数(人月)＝0.97×画面数＋0.26×バッチ数」─JUASソフトウェアメトリックス調査から 数字で見るITガバナンス 2008年12月22日(月)IT Leaders編集部 リスト システム開発プロジェクトが寄せられた時、それがどの程度の工数を必要とするかを見積もることはとても重要だ。開発の「規模感」がイメージできれば、投入すべきリソースも見当がつくし、それはそのままコスト面での計画にも結び付く。 経験則に拠ったり、開発協力ベンダーが提示してきた概算に頼るという方法もあるが、世の中一般の開発プロジェクトから導き出した「指標」を参考にす
なぜ開発で見積り失敗して忙しくなりがちなのか(アジャイルな見積りと計画づくり読んだ) - $shibayu36->blog;
最近タスクがどのくらいで終わるか見積もることが多いんだけど、そのたびにうまく見積もりができてなかったり、思ったより長引いてしまってすごく忙しくなってしまったり、といったことが何度かあった。このままじゃ良くないなーと思って、「アジャイルな見積りと計画づくり」を読んだ。 アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ 作者:Mike Cohn,マイク コーン毎日コミュニケーションズAmazon 実際読んでみると今の状況に非常にぴったりで良い本だった。この本を読んでいくと、最初から正確な見積りをするのは不可能で、作業をしながら見積りの精度をあげるといったり、変更やリスクに強いスケジュールをうまく作るということをしていく必要があるということが分かる。なんとなく自分がタスク管理をしないといけなくなったけど、なんかうまくいかないと思っている人には非常に参考になると思う。あと
[MEMO] ファンクションポイントの算出法、あれこれ - biac の それさえもおそらくは幸せな日々@nifty
■ 正規のファンクションポイント算出法 ◇ IFPUG 法 参考URL: http://www1.ocn.ne.jp/~matsuo3/words/fp1.htm http://www.kiis.or.jp/spoken/ksh/98jisseki/fp.htm + 世界共通のマニュアルがあり、安定した数値が得られる。 (日本ファンクションポイントユーザ会 http://www.jfpug.gr.jp/ ) - データベース設計とデータ入出力の設計がすべて終わっていないと、算出できない。 ※ メモ: 実際の数値の扱いにおいては、未調整FPと調整済FPの違いに留意すること。 ファンクションポイントと言えば IFPUG 法なわけですが、 しかしこれはウォーターフォールで言えば「製造」行程以降の見積もりにしか使えません。 もうすこし手前の段階で FP を概算したり推定したりできないだろうか、 そ
![[MEMO] ファンクションポイントの算出法、あれこれ - biac の それさえもおそらくは幸せな日々@nifty](https://cdn-ak-scissors.b.st-hatena.com/image/square/c50b1ca0898c13b4c2b9eaaf8b9adc0e9348ce3f/height=288;version=1;width=512/http%3A%2F%2Fbluewatersoft.cocolog-nifty.com%2F.shared-cocolog%2Fnifty_managed%2Fimages%2Fweb%2Fogp%2Fdefault.png)
NESMA: Early FPA
Early Function Point Counting 開発初期段階でのFPカウント方法 NESMA（Netherlands Software Metrics Association）では、システム開発の初期段階で使用できる二つのＦＰカウント方法を開発した。： FP概算法 (estimated function point count) FP試算法 (indicative function point count) (後者のFP試算法は、"オランダ方式 (the Dutch method)"としてＦＰＡリストサーバ／カナダ ケベック大学運営に、載っている。) ここでは、FPカウントの二つの異なる方法と、その適応性、検証の結果について説明する。 次の内容で説明を進める。 IFPUG法：The（detailed）Function point count FP概算法：The estimate
ファンクションポイント - MyMemoWiki
計測タイプの決定 計測範囲の決定、アプリケーション境界の決定 データファンクション計測 トランザクショナルファンクション計測 未調整ファンクションポイント計算 調整係数計算 調整済ファンクションポイント計算
漂流記
概要 概要（変化に強いシステムの構築方法）2000-12-10 データモデル エンティティとリレーションシップ2000-12-28 エンティティのライフサイクル2001-01-12 アプリケーションルール データフローダイアグラムの書き方2001-01-28 アプリケーションルールの定義2001-02-04 プログラム設計 プログラム設計2001-02-18 その他 ことの経緯 その１2001-03-04 ことの経緯 その２2003-09-21 その他更新：2002-11-24，2002-06-16 作成例：販売・生産・搬送計画立案支援システム 業務概要2001-09-09 データモデル2001-09-16 エンティティのライフサイクル2001-09-30 アプリケーションルール2001-09-23 プログラム設計2001-10-07 各論 データウェアハウス2001-03-25 ファンク
ファンクションポイント法の流れ | WEBシステム開発の見積り・構築依頼なら大阪の株式会社ヨドック
サマリー 1) FP計測のタイプの決定 タイプ1) 新規開発計測 タイプ2) 機能拡張計測 タイプ3) アプリケーション計測 2) 計測範囲の決定、アプリケーション境界の決定 計測範囲を明確にする為にアプリケーション境界を決定する。 3) データファンクションの計測 FP計測２つの計測対象の１つ ILF(Internal Logical File):追加・更新・削除など操作対象となるファイル EIF(External Interface File):参照されるファイル データエレメントタイプ(DET)：繰り返しを含まないデータ項目 レコードエレメントタイプ(RET)：繰り返しのあるデータ項目 ■ILF、EIFの複雑度 1～19 DET 20～50 DET 51以上DET 1 RET
http://www.zai-keicho.com/pdf/01_h22_jutaku_no01.pdf
平成２２年度 ソフトウェア開発に関する調査票（受託者向け） 集計結果その１ 平成２３年６月 財団法人経済調査会 白紙 調査票集計結果について 本集計結果は，本調査にご協力いただいた各企業にお送りしているものです。 本調査は，日本ファンクションポイントユーザ会FP法利用検討会（JFPUG／FPSMSG）および国立大学法人奈 良先端科学技術大学院大学との共同調査として財団法人経済調査会が実施しとりまとめいたしました。 調査対象は，日本ファンクションポイントユーザ会（JFPUG）に登録されている企業を中心とした全国の情 報処理サービス企業です。 本調査は，受託者（受注企業）への調査を想定しましたが，一部委託者（発注企業）の回答が含まれてお ります。 平成23年6月 財団法人経済調査会 1 調査期間 平成22年12月～平成23年1月 2 調査票の構成と概要 調査票Ⅰ 調査先組織の概
ついに登場！ 究極の見積もり技法（その1：解説編）
「ソフトウェア技術者の最高の能力は、見積もりだ！」――今回は、パラメトリックス法の1つ「SLIM」を取り上げます。上司からのムチャな開発期間の短縮要求をはねのける“究極の反撃法”が、このSLIMによる見積もりです。 「見積もり」は、ソフトウェア開発における大きなテーマであり、ソフトウェア工学における最重要課題の1つでもあります。 今回お届けしている“見積もり・シリーズ”では、「見積もりの目的（正確に見積もるだけでは不十分）」「見積もりの具体的な方法（精度を上げるため、少なくとも、2つ以上の方法で見積もる必要がある）」「見積もりの応用（見積もり値に合わせる制御と再見積もり）」「見積もりの調整（状況に応じて開発量とスケジュールを再見積もりしなければならない）」について、具体的に解説していきます。 見積もり技法は「類推法」「積み上げ法」「パラメトリックス法」の3つに分類することができます。前回は
ゲーム開発プロジェクトマネジメント講座(SQUARE ENIX OPEN CONFERENCE)
ゲーム開発 プロジェクトマネジメント講座 ２０１１年１０月８日 株式会社スクウェア・エニックス CTO 橋本 善久 1©SQUARE-ENIX 2011 SQUARE ENIX OPEN CONFERENCE なぜプロジェクトは 失敗するのか？ 2©SQUARE-ENIX 2011 プロジェクトの失敗ポイント • 見込みより売上が少ない • 計画よりもコストがかかっている • 発売時期が遅れた • 発売に間に合わせるため内容が削られた • ユーザーの評判が悪い • 不具合が発生 • スタッフの満足度が低い、故障者が出た、辞め てしまった • など・・・ 3©SQUARE-ENIX 2011 プロジェクトの失敗ポイントの分類 • スコープ（コンテンツの範囲）の問題 • 品質の問題 • コストの問題 • 時間の問題 • リソース（人員・環境）の問題 • ビジネスの問題 4©SQUARE-EN
OTN Japan - Oracle9i 物理設計：第3部 テーブルの設計
私の所属するOracleDirectでは電話やインターネットを利用して、各種のお問合せを頂いたお客様に対しまして、お客様の担当されておられるシステムの成約・成功のための各種ご支援をさせていただいております。単にお問合せに対する回答を行うだけでなく、ご要望があれば製品紹介や機能解説のプレゼンテーション、デモ等も電話とインターネット経由を併用して実施いたします。お問合せは無償ですのでOracle製品について確認したいことがございましたらお気軽にご連絡ください。 はじめに テーブルの容量見積については、OTN Japanに以下の資料・ツールが用意されています。 領域サイズの見積もり方法 領域サイズ見積シート ここで解説している見積方法は、資料「領域サイズの見積もり方法」の考え方をやや簡略化して、計算しやすくした方法です。また、指針を出すということを優先し、プラットフォームやバージョンによる違いを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.ipa.go.jp/archive/publish/qv6pgp0000000y34-att/000005124.pdf
http://typea-service.appspot.com/fp
http://pascom.jp/minutes/mitumori.pdf
上流工程-見積もり---目次：ITpro
