総工数（人月） ＝ 0.97 × 画面数 + 0.26 × バッチ数――JUAS「ソフトウェアメトリックス調査」から | IT Leaders
システム開発案件が寄せられた時、それがどの程度の工数を必要とするかを見積もることはとても重要だ。開発の「規模感」がイメージできれば、投入すべきリソースも見当がつくし、それはそのままコスト面での計画にも結び付く。 経験則に拠ったり、開発協力ベンダーが提示してきた概算に頼るという方法もあるが、世の中一般の開発プロジェクトから導き出した「指標」を参考にすることも検討したい。 日本情報システム・ユーザー協会（JUAS）が2004年度から毎年続けている「ソフトウェアメトリックス調査」では興味深い調査結果を発表している。スクラッチ開発、つまりパッケージソフトを利用せずに独自でゼロから開発することを前提とした場合、対象システムに実装する「画面数」「バッチ処理数」から、おおよその総工数が見積もれるというものだ。その計算式は以下で表される。 総工数（人月） ＝ 0.97 × 画面数 ＋ 0.26 × バッチ
実プロジェクトから学ぶオフショア開発のリスクと解決策のフレームワーク | IT Leaders
※本記事は日本ＩＢＭ発行の「PROVISION No.63/Fall 2009」の論文紹介記事に一部加筆・編集して掲載しています。 筆者の経験に基づく個人の意見であり、ＩＢＭを代表する見解ではありません。 日本国内のITエンジニア不足が深刻な問題となる中、海外へITシステムの開発を委託するオフショア開発は当たり前の形態となっている。しかし、残念ながらビジネスとしての実態を見る限り、オフショア開発のすべてが成功しているわけではない。理由は文化や商慣習の違いからくる各種の摩擦、言語面でのコミュニケーション不備、そこから生じるさまざまなトラブルなど実に多種多様である［1］。 IBMもグローバル・デリバリー（海外IBM要員との協業：GD）という形で積極的にオフショア開発を推進している。だが、GDに関しても問題は多種多様であり、いまだに個々のプロジェクトだけでは解決できない問題が数多く発生しているの
RACやASMなどに見る論理層の仮想化―Oracle 11g R2、その実力を解剖する Part 3 | IT Leaders
DBを革新させる「RAC」 仮想化などにより、拡張性や可用性を高める原理を詳説 Oracle DatabaseはDBエンジンとしての性能向上と並行して、DBシステムとしての技術も充実させてきた。中でも大きく進化したのが「RAC」だ。パート3ではテクノロジーの側面からRACを解剖すると共に、ストレージを仮想化する「ASM」などを用いてDBシステムの拡張性や可用性を高める仕組みを分かりやすく解説する。 安価なハードウェア（サーバー、ストレージ）を利用可能にしながら、性能や可用性、運用の容易性といった相反する要件を満足させる。Part1で示した通り、これがOracle Database 11g R2の最大の特徴である。それを支えるのが、複数のサーバーやストレージをあたかも1つのコンピュータ資源であるかのように使えるようにする「Oracle Real Application Clusters（RA
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
