 |
||||||||||||||||
|
||||||||||||||||
| 前のページ 1 2 3 | ||||||||||||||||
|
||||||||||||||||
| 業務システムの納品物の指定方法 | ||||||||||||||||
|
現状では、提案書に記載されている納品物をベースとして、各社が各案件の設計書、納品物（ドキュメント、プログラム類）を指定しているが、具体性を持たせていない。 業務システムのアプリケーションソフトウェアに関連して、次の点を成果物として納入させ、瑕疵担保責任を負わせる条件で検収することが大規模システムや基幹業務システムでは必要である。
表2：業務システムのアプリケーションソフトウェアに関連して成果物として納入させるもの |
||||||||||||||||
| 見積金額の内容評価 | ||||||||||||||||
|
的確な見積を行う習慣のあるシステムベンダーでは、請負契約では、設計開発構築の工程別に成果物量（ドキュメント量、プログラム量）を提示し、工程別の時間単価を明確にしてから見積金額を提示している。加えて、成果物当たりの生産性をも提示し、「発注側がこの生産性が守れるように協力することが契約上の条件」としている。 一般的には、工程別にSE（システムエンジニア）、PG（プログラマ）の必要人月と人月単価を提示した設計工数、開発工数を基準とした金額で契約を進めている。 最近は、ファンクションポイント当たりの単価を使用している企業もあり、アプリケーションソフトウェアの合理的な見積を行うために、SEC（ソフトウェアエンジニアリングセンター）がソフトウェア・メトリックスとしてソフトウェア設計開発構築での工程別の成果物のデータベース構築に着手している。 |
||||||||||||||||
| 見積金額評価 | ||||||||||||||||
|
最も進んでいる企業では、過去のプロジェクトにおけるファンクションポイント、機能数などからアプリケーション規模ごとの標準コストを設定し、この標準コストとの対比で見積金額を評価することを進めている。また、品質、納期により生産性が異なることから、これらをパラメータとして取扱い、評価に反映している。 一般的には、個別機能単位に開発規模を精査し、過去の実績を参照し、生産性をある程度斟酌してソフトウェア設計開発構築の見積金額の評価を行っている。 |
||||||||||||||||
| 見積仕様の評価 | ||||||||||||||||
|
進んでいる企業では、見積仕様が納入仕様であり、個別機能毎に各工程の設計内容／プログラム試験が要求した仕様に合致しているかを確認している。 大規模案件では、見積審査会などの合議体での各分野の専門家が評価した結果を基にした評価で進めている。見積契約後に発生した変更追加は、情報システム部門の経験を生かして対応することが重要である。 契約上の仕様／納品物からどれだけのギャップがあり、コスト、納期にどの様なインパクトを与えるかを整理し、明確にした上でプロジェクトとして精算することが必要である。 |
||||||||||||||||
|
前のページ 1 2 3 |
||||||||||||||||
|
「JUASマニュアル紹介」 JUASでは、情報システムユーザーとしての立場からの産業情報化の推進を目的に、様々なテーマや立場に応じた活動（委員会、研究会、研究プロジェクト）を行っており、その活動成果を報告書、マニュアルとして販売しております。JUAS報告書・マニュアルの詳細は、下記URLをご参照ください。 ご購入はコチラ http://www.juas.or.jp/product/ |
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
-
-
連載
