タグ

2009年4月14日のブックマーク (6件)

  • 反復型開発における見積もりの実際:ベースとなるのはユースケース

    オブジェクト指向技術の浸透や,反復型開発の広がりなど,システム開発を巡る状況が大きく変化している。見積もり方法も,従来のやり方では通用しないケースが増えてきた。反復型開発における見積もりの基的な考え方や,ユースケース・ポイント法の活用手順について解説する。 オブジェクト指向開発の普及に伴い,ソフトウエアを段階的に繰り返して開発していく「反復型開発(イタラティブ開発)」を採用するプロジェクトが増えている。反復型開発は従来のウォーターフォール型開発とは基的な考え方やフェーズの分け方が異なるため,従来型の見積もり技法を適合できない面がある。 そこで第4部では,反復型開発における見積もりの基的な考え方と,現在,一般的に用いられている「ユースケース・ポイント法」を中心とした見積もり技法について解説する。なお,システム開発のプロセスは反復型開発において最も標準的な「統一プロセス(Unified

    反復型開発における見積もりの実際:ベースとなるのはユースケース
    fragarach_the_sword
    fragarach_the_sword 2009/04/14
    ITPro:反復型開発における見積もりの実際:ベースとなるのはユースケース
  • 工数見積もりの見える化

    なぜ工数の見積もりが必要なのか 最近ソフトウエア業界で話題となっている工事進行基準でも、「工事進ちょく度の計算根拠となる工事原価総額が信頼性を持って見積もられなければ工事進行基準を適用することができない」と述べられているように、ソフトウエア開発における工数見積もりの重要性はますます高くなってきている。 「見積もる」という言葉を広辞苑(こうじえん)で引くと、「1. 目で見て大体を測る。目分量ではかる。2. 物事のあらましを考え計算して予測を立てる。つもる。概算する」とある。ソフトウエアの工数見積もりは、2.の意味、つまり、対象となるソフトウエア開発のあらましを頭に描き、投入されるであろう、あるいは、投入すべき工数を予測する、ということになる。 ソフトウエア開発管理の主な観点はQCD(品質、コスト、納期)である。厳密にいえば、工数(人月)はコストとイコールではない。しかし、工数に基づき算出され

    fragarach_the_sword
    fragarach_the_sword 2009/04/14
    ThinkIT連載:【プロジェクト管理術】ソフトウェア工数を見積もる!(1)
  • どんな見積もり技法がある?【前編】

    今回と次回は,見積もり技法の分類を考えます。見積もり技法は細かく分けるとたくさんあるのですが,今回取り上げるのは「工数見積もり」に分類される技法です。 「PMBOKガイド」では工数見積もりの技法が三つ紹介されています。「類推(トップダウン)見積もり」「係数モデル見積もり」「ボトムアップ見積もり」です。この三つを知っておけば,現実的には困らないでしょう。 類推(トップダウン)見積もりは,過去の事例や経験から類推する技法です。まず全体のリソース量を見積もってから,個々の作業に配分します。最も簡単に使えますが,見積もり精度は低くなります。属人的な方法であり,見積もる人の能力に精度は大きく依存します。 係数モデル見積もりは,基準値(生産性係数)や数式などの「見積もりモデル」を使って,工数を算出する技法です。成果物やプロセスの特性をパラメータ化して,見積もりモデルに当てはめます。代表的なモデルとして

    どんな見積もり技法がある?【前編】
    fragarach_the_sword
    fragarach_the_sword 2009/04/14
    ITPro連載:ちょっと待った!その見積もり : どんな見積もり技法がある?
  • 初田賢次 ちょっと待った!その見積もり

    見積もりをプロジェクトにつなげる [2006年11月30日] 見積もりは通常,プレ・プロジェクトと呼ぶ段階で,提案活動に付随して進めます。では,提案活動に付随して行う見積もりが,なぜ切り出されてこれだけ注目を集めているのでしょうか? 私は,スコープや工数,コスト,納期など,マネジメントの要素が見積もりに集約されているからだと考えています。 保守開発の見積もりはどうする? [2006年11月20日] 保守開発による見積もりは,新規開発とは違った難しさがあります。母体部分と,修正を加えるエンハンス部分を分けて見積もる必要があるからです。今回は,保守開発における見積もりについて考えてみましょう。 見積もりの「心構え」とは? [2006年11月09日] 今回は,見積もりを実施するうえで常に意識してほしい,三つの心構えについて述べてみます。最初は「すべての情報やデータ,自らのノウハウを駆使して

    fragarach_the_sword
    fragarach_the_sword 2009/04/14
    ITPro連載:ちょっと待った!その見積もり
  • @IT:人月での見積もりがエンジニアをダメにする(前編)

    IT業界に巣くう大問題 人月での見積もりがエンジニアをダメにする(前編) 馬場史郎(グローバル ナレッジ ネットワーク) 2002/8/2 何げなく聞く“マンパワー”という言葉の裏に、ITベンダをむしばむ“人月問題”が横たわる。日IT業界に深く根を張ったこの問題が、エンジニアをダメにすると筆者はいう。人月問題とは何か、そしてそれを改善する方法とは? 筆者が現役のSEだったころ、“マンパワー”という言葉に抵抗があった。現在でもこの言葉に抵抗がある。IT業界では、プロジェクトを手掛けるときなどに「マンパワーが足りない」とか、「マンパワーは十分だ」という場合がある。その“マンパワー”という言葉だ。そうした言葉を聞くと、往々に「SEはスキルではなく頭数だけが問題とされている」ような気分となる。 さらに、プロジェクトでは「このプロジェクトは30人月掛かります。従って3000万円となります」

    fragarach_the_sword
    fragarach_the_sword 2009/04/14
    @IT:人月での見積もりがエンジニアをダメにする
  • PMO(プロジェクトマネジメントオフィス)を生かす

    最近話題のPMO(プロジェクトマネジメントオフィス)とは、一体どんな役割を果たすべき組織なのか。この点を見失うと、PMOは簡単に機能不全に陥ってしまうだろう。連載は、「プロジェクトマネジメントを組織的に実施する」「プロジェクトマネジャを煩雑な管理作業から解放する」「プロジェクトの潤滑油としてコミュニケーションを円滑にする」といったPMOの実務に関する知見を紹介していく。 目次

    PMO(プロジェクトマネジメントオフィス)を生かす
    fragarach_the_sword
    fragarach_the_sword 2009/04/14
    ITPro連載:本質を学ぶ-PMOを生かす