タグ

プロジェクト管理に関するshigerianのブックマーク (5)

  • システム設計 設計の考え方

    要件定義、基設計、詳細設計、プログラム設計、テスト、運用というシステム構築の手順が一般的に浸透しているが、このプロセスは 実践ではほとんど守られておらず、要件定義の中で、ユーザと一緒に一部分を掘り下げて行っているうちに混合されることが多い。 ここではその区別について考える。ただし、実践手順が多少、イレギュラーに設計されるのは全体の合理化を促進しようとするためであり、必ずしも良くないこととは言い切れない。 基的には必要とされるアクターを考えることが重要だと思われる。 外部設計(システム設計) =システム方式設計+ソフトウェア設計 内部設計           =コンポーネント設計 詳細設計            =プログラム設計                                       (IPA) 1.システム方式の決定:アーキテクチャーとして、H/

    shigerian
    shigerian 2007/08/08
    システム設計 設計の考え方
  • [ThinkIT] 第2回:PMBOKをベースにしたプロジェクト管理の管理 (1/2)

    ここ数年、さまざまな企業でプロジェクト管理への意識が高まり、IT産業にとって良い方向に向かっていると思います。常駐・派遣型ビジネスならセーフなのに、一括請負型ビジネスで赤字を出すという図式から脱却するには、プロジェクト管理力を高めるしかないと経営者も気づいてきたのでしょう。かくして、あちこちでPMBOK(通常、ピンボックと呼びます)やCMMなどをテーマとした"プロジェクトマネージメント セミナー"が開催され、一時期活況を呈していました。 セミナー参加者は、PMBOKやCMMを理解し、プロジェクト管理の重要さを再認識しました。しかし、PMBOKはそもそもプロジェクト管理に関する知識体系をまとめたものに過ぎないので、それを利用して自社に生かすという肝心のアプローチが見えません。結局、"セミナーに参加して意識が高まった"というだけに終わり、いつの間にかブームも尻すぼみになりそうにも感じています。

    shigerian
    shigerian 2007/08/01
    第2回:PMBOKをベースにしたプロジェクト管理の管理 (1/2)
  • 『見積のKKD法』

    受託開発のソフトウェア、つまりオーダーメイドのソフトウェアの価格は、そのソフトウェアを作るのに必要な労働力によって決定されます。 ソフトウェアを作るのに必要な工数x単価で価格が決まります。工数は人月で数えます。1人に人間が1カ月労働すると1人月。10人が10ヶ月労働すると100人月です。誰が作業するとか、そのソフトウェアを使って得られる価値などは関係ありません。 人月x単価の商売を是正して、創出した価値を評価してくれという要望は昔からソフトウェア業界にあります。しかしながら、今のところは、人月x単価でソフトウェアの価格が決まります。 従って、見積額の根拠として、見積書に工数と単価を必ず書きます。単価は技術者の労務費+会社の経費+会社の利益で決まりますが、工数はどうやって見積もるのでしょうか。 一部のシステム・インテグレータではファンクション・ポイント(FP法)と呼ばれる手法を導入しています

  • [ThinkIT] 第1回:プロジェクトマネージャとプロジェクトリーダの役割とは (1/3)

    システム開発プロジェクトを管理・遂行していくのは、大変に骨の折れる仕事です。見積もり手法1つを取ってみても、KKD法、FP法、COCOMO2、機能一覧法(積み上げ式)、LOC(Lines Of Code:プログラム行数)式など、思いつくままにあげても相当な数に上ります。 さらに、最新の見積もり手法もキャッチアップしていくならば、先ごろ日情報システム・ユーザー協会が発表した「システム開発プロジェクトの標準工期は投入人月の立方根の2.4倍」といった内容も考慮に入れていく必要があるでしょう。また、実務でのプロジェクト見積もりとなると、見積もり提出期限という制約や顧客からのRFP資料の不足など、様々なリスク要因が追加されていることも珍しくありません。 見積もりはプロジェクト管理の一部に過ぎません。しかし、いまだどのシステム開発プロジェクトにもあてはまるような方法論がないことが、さらにシステム管理

    shigerian
    shigerian 2007/08/01
    第1回:プロジェクトマネージャとプロジェクトリーダの役割とは (1/3)
  • 最適な工期は「投入人月の立方根の2.4倍」、JUASが調査 ― @IT

    2007/07/05 日情報システム・ユーザー協会(JUAS)は7月5日、ユーザー企業102社の357プロジェクトを調査した「ソフトウェアメトリックス調査2007」を発表した。システム開発の企画、開発計画に始まり、保守や運用管理まで実態を調査した内容で、企業情報システムの実態を伝える。調査結果からは“デスマーチ”となるプロジェクトの実態も浮かび上がった。 デスマーチ化するプロジェクトの条件の1つは工期の設定が不適切であることだろう。調査から導き出された標準開発工期は「投入人月の立方根の2.4倍」。調査対象のプロジェクトの全体工数と全体工期をグラフ化し、回帰直線によって求めた。この計算によれば1000人月のプロジェクトの場合は24カ月の工期を設定するのが標準的といえる。事情によってこの標準工期よりも短い工期しか取れない場合は、その短縮率を計算して対策を採るべきとJUASは提言。だが、「(短

    shigerian
    shigerian 2007/07/09
    最適な工期は「投入人月の立方根の2.4倍」、JUASが調査 - @IT
  • 1