サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
PostgreSQL において、メモリサイジングの方法を示します。計算方法が何種類かあるので紹介します。 1. 正式サイトの共有メモリ見積もり http://www.postgresql.jp/document/pg814doc/html/ kernel-resources.html#SHARED-MEMORY-PARAMETERS 共有メモリ使用量の計算式 = max_connections * ( 400 + 220 * max_locks_per_transaction ) + max_prepared_transactions * ( 600 + 220 * max_locks_per_transaction ) + shared_buffers * 8300 + wal_buffers * 8200 + max_fsm_relations * 70 + max_fsm_pages
プロジェクトの工数算出というものに対して非常に疑問に思うことがある。 工数とは、各機能を算出してそれらを足していき、そこにある程度のスパイス（保険）を足して算出する感じだろう。 ここに、スパイスというよくわからないものがあるが、このスパイスが経験でズバッと３倍とか、１．５倍とか… ここまでいい加減でないにしても、それぞれの機能に複雑度・影響度を加味した係数をかけて、足していき・・・・・ って、これで実際に工数を出してみても、本当にその考え方あってるの？と疑問に思う。 そもそも、 そのプロジェクトはいつまでに完了（納品）しなければいけないのか、とか？ 何人投入するのか（できるのか？） が、関係するんじゃないんかなー。 それらは、工数を出してからというかもしれないが。 だったら、導き出せる工数というのは場合の数だけ複数あるのではないだろうか？ そんな状況を示すのは、こういう会話では
見積りの概念と、手順の説明。 「～を見積もれ」と命じられたとき、技術者として見積りができるようになることを目標としている。 ソフトウェア開発の流れについて、知識があることが前提です。 営業見積りは範囲外だ。 「ゴタクはいいからてっとり早く」の人は、「エッセンス」だけ読むといい。 まず、「見積もり」の用語をはっきりさせる。用語がはっきりすることで、意識が向くようになるからである。 次に、例から見積りを作る手順を説明する。 次に、自分自身の見積り能力をチェックしてもらう。 最後に実習だ。 ■エッセンス 見積もり、ターゲット、コミットメントを区別する。 見積もりは工数で、確率で表わされる。 計測できるものの最小単位で、最良ケースと最悪ケースにあたりをつける 最良ケース：完璧に準備された場合。 最悪ケース：まあ70%はこの期間内でできるだろう。 ※これは私の勘による算出方法で、根拠も何もない。 「
2007年06月17日02:24 ソフトウェア見積もり 入門（１） カテゴリプロジェクトマネジメント gaseidou2 Comment(0)Trackback(0) ソフトウェアエンジニアが、 苦手意識を持ちやすい仕事の一つが、 見積もりです。 チームリーダーがまとめて、 見積もってしまうことが多いのも事実ですが、 見積もりができなければ、 一人前のエンジニアとは言えません。 なぜ、見積もりに苦手意識があるかというと、 ・教えてもらったことがない ・やり方を知らない ・見積もりが"当たった"ためしがない からです。 ほとんどのエンジニアは、 見積もりの仕方を習ったことがありません。 自分で勉強することもありません。上司や先輩も習ったことがないので、 教えられないのです。 「ざっくり○○人月」 「だいたい○日かな」 と言っても、 そこに明確な根拠があるわけではないのです。 まさに、KKD
見積もりは手法こそ整備されてきたものの，精度を上げるのが難しくなってきた。現場担当者が疑問に思う七つの問題を取り上げる。 問題＆解決 根拠なくして納得感は得られない 「こんな見積もりはのめない！」。味噌メーカー，マルコメの役員はあるシステム開発プロジェクトの会議の席上，決断を下した。販売/生産/財務など基幹システム再構築を発注していたベンダーとの契約を打ち切り，改めて他ベンダーを探すことになった。プロジェクトは既に要件定義を終え，設計工程に入ろうとしていた。ここで最初に開発を発注していたベンダーが「最初の見積もりではできません」と，当初とはまるで違う再見積もりを通知してきたのである。 当初の見積もりと再見積もりの乖離幅は2倍以上。発注時に4社から相見積もりを取り，最も安価なベンダーに発注した経緯があるだけに，後になって2倍超ものコスト上積みなどとうてい受け入れがたいものだった。 現場の指
思えばここ数年，「ソフトウエア見積もり」というテーマを追い続けてきた。2004年9月，日経ITプロフェッショナル（現在は日経システム構築と統合して日経SYSTEMS）で「本当に使える見積もり技術」という特集記事を担当。多くのユーザー企業やベンダーに取材し，現場の問題意識の高さや見積もりの難しさを知った。日本ファンクションポイント・ユーザ会をはじめ関連団体の会合にも参加し，現場のエンジニアの生の声を聞いた。 その特集が高スコアを得て，気をよくした記者は同タイトルの連載記事を企画（寄稿者は日立製作所の初田賢司氏）。2005年5月から11回にわたって，同連載の編集を担当した（おかげ様でこの連載も大変好評だった）。そしてこの10月2日，同連載をベースに大幅に加筆・修正した単行本を刊行する（要求定義に関する単行本も同時に刊行）。今回の記者の眼では，これまでの取材や編集などを通じて，見積もりについて“
WBS法のメリットとデメリット WBS法のメリットとしては、以下のものが挙げられます。 工期と工数、体制（人件費）までを同時に見積もれる 個々のタスクは非常に正確 タスクの深さであるテストの段階数やドキュメント化の程度を完全に取り込める 客観的であり理解しやすい 対してデメリットを挙げると、以下のようなものがあります。 A.タスクごとにバッファを取ってしまい、コストやスケジュールが過重になりやすい（後述） B.設計の精度をかなり進める必要がある。概算という使い方が困難 C.実績のないシステムではタスクごとの見積もりの類推が困難 一般的なタスクからの見積もり方法について解説します。この手法は特に方法論化されているわけではなく、ごく一般的に用いられている方法です。 ここでは、SEが1人、プログラマ（TT1、TT2）2人のほか、SEのアシスタント（いわゆる新人ぐらい）が1人というチーム構成を例と
三者三様の見積もり結果となった。工程別に工数を積み上げるやり方，ステップ数を生産性係数で割って工数を算出するやり方，FP法を使うやり方など見積もりプロセスはまちまち。コストの見積もり結果も165万円から300万円までと，大きな差があった 3人はいずれも10年以上のキャリアを持つベテランSEである。にもかかわらず，見積もり結果には大きな開きが出た。なぜこんなに差が出たのか。彼らが使った手順とそのコメントから考えてみよう。 銀行のシステム開発・運用を担当する小沢勉氏（仮名，46歳）の場合，最初にプロジェクトを「基本設計」「詳細設計」「プログラミング」といった工程別に分割し，それぞれに必要と思われる工数を積み上げた。ただ，小沢氏はWebシステムの開発に携わった経験がない。「ホスト系の開発と同じような感覚で素直に計算すると，実績とズレた値が出ると思った。なので，工数の一部を修正した」と言う。 中堅
業務としてソフトウェアを開発するならば、工数の見積もりは避けては通れない。見積もりは、ソフトウェア開発プロセスのはじめの一歩に過ぎないが、その成否はプロジェクト全体の命運を握ることになる。プロジェクトに焦燥と混乱をもたらすことなく、堅実に開発を進めていくためには、正確で具体的な見積もり手法が求められる。 良く知られた見積もり手法の１つに、ファンクションポイント法がある。外部との入出力に着目して、ソフトウェアの機能から工数を見積もるファンクションポイント法は、有効な見積もり手法である。 だが、実際のソフトウェア開発の現場では、ファンクションポイント法で見積もりを行っているケースは多くはない。その原因の１つには、ファンクションポイント法を使うためには、入出力を定めたモデルの作成や、ポイントの計算方法など、専門的な知識と技能が必要なことが挙げられる。 小規模なソフトウェア開発では、見積もりのしや
「プロジェクト管理実践特論」の第9回では、コスト見積もりについて説明します。ここでは、「プロジェクト・コスト・マネジメント」、「コスト見積り」、「予算化」の話をします。最後に例としてソフトウェア開発における見積もり手法の説明をしたいと思います。 コスト見積りについて考えてみましょう。これまでスケジュールやスコープの話をしてきましたが、コスト見積りというのは実は非常に大事で、コストが正確に見積もれないとさまざまな悪いことが起こります。まず、コストを少なく見積もってしまった場合には、そのプロジェクトを実際にやってみると赤字になってしまいます。逆に、コストを多く見積もってしまった場合には、他社の方が安く仕事ができるということになってしまいますので、今度は仕事がもらえなくなってしまいます。 「コスト見積り」のインプットには、「組織体の環境要因」があります。景気の状況もここに含まれます。「組織のプロ
今回は，契約を結んでからプロジェクトが始まるまでに，何をしなければならないかを考えてみましょう。 見積もりは通常，プレ・プロジェクトと呼ぶ段階で，提案活動に付随して進めます。では，提案活動に付随して行う見積もりが，なぜ切り出されてこれだけ注目を集めているのでしょうか？ 私は，スコープや工数，コスト，納期など，マネジメントの要素が見積もりに集約されているからだと考えています。 大事なのは，この見積もりを「プロジェクトを成功させる」という最終ゴールにつなげることです。契約が決まったからと言って，安心していてはだめです。最後のツメが甘くなっては元も子もありません。 苦労して作成した見積もりを実際のプロジェクトにつなげる――。これこそが見積もりプロセスの最後の作業です。私はこの段階で，次の四つを心掛けるべきだと考えています。 一つ目は，最初に出した見積もりと最終的に決まった見積もりを比較し，何が変
今回と次回は，見積もり技法の分類を考えます。見積もり技法は細かく分けるとたくさんあるのですが，今回取り上げるのは「工数見積もり」に分類される技法です。 「PMBOKガイド」では工数見積もりの技法が三つ紹介されています。「類推（トップダウン）見積もり」「係数モデル見積もり」「ボトムアップ見積もり」です。この三つを知っておけば，現実的には困らないでしょう。 類推（トップダウン）見積もりは，過去の事例や経験から類推する技法です。まず全体のリソース量を見積もってから，個々の作業に配分します。最も簡単に使えますが，見積もり精度は低くなります。属人的な方法であり，見積もる人の能力に精度は大きく依存します。 係数モデル見積もりは，基準値（生産性係数）や数式などの「見積もりモデル」を使って，工数を算出する技法です。成果物やプロセスの特性をパラメータ化して，見積もりモデルに当てはめます。代表的なモデルとして
工数見積もりのチェック項目で特に重要なのは，見積もりの「範囲」を明確にするもの。3番および7～14番に当たり，見積もり対象となる工程や作業をはっきりさせる。 作業の漏れだけでなく，役割分担も必ず確認したい。ここで誤解が生じると，工数が大きくブレる原因となる。特にシステムテストや運用テスト，移行，ユーザー教育，マニュアル作成は忘れられることが多いので，注意が必要である。 変動要因となるリスクについては，技術リスクと人的リスクという二つの観点を持つ。技術リスクは規模見積もりの際に把握した機能要件と非機能要件を改めて確認しよう。適用する製品や技術，開発支援ツールも考慮し，メンバーのスキルが十分かどうかもチェックしたい（4～6番および23～25番）。一方の人的リスクについては，意思決定の遅れを招く，関連部門やステークホルダー（利害関係者）の数や特徴を把握するほか，利用部門の参加度合いも見極めたい（
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
