見積もり・発注 - 技術情報Wiki
発注／調達 † 値切ってはいけない 2009.3.6 確かに，プロジェクトには予算が決められており，その予算の枠内でやり遂げる必要がある。どうしても予算と見積もり金額が合わない場合には，入念に価格交渉を行い，発注者と受注者の双方が金額の妥当性について合意した上で確定させるべきなのだ。 そのためには，PMは出てきた見積もりを査定する能力が必要であり，かつ高い折衝能力が必要である。 はじめてのRFP 2008.2.4 調達用語 RFP,SLCP,SPAとか ＲＦＰ（Request For Proposal：提案依頼書） ＳＬＣＰ−ＪＣＰ９８：Software Life Cycle Process - Japan Common Frame 1998 ＳＰＡ（Software Process Assessment）
情報システム関係の人とかこれ見とくといいよ - チョコっとラブ的なにか
こんなの出てたから、見ておくといいかもね。 経済産業省では、情報システムの取引において、現行の「人月方式」以外での価格決定方法を模索するため、情報システムの付加価値に着目して価格を決定する「パフォーマンスベース契約」について検討を行ってまいりました。 今般、「情報システムのパフォーマンスベース契約に関する調査研究」報告書として取りまとめましたので、公表いたします。 「情報システムのパフォーマンスベース契約に関する調査研究」報告書の公表について - 経済産業省 本文のさわりにはこんなことが書いてあったよ。 1 はじめに 1-1 背景と目的 我が国の情報システム市場は、現在、主として「人月ベース」の価格表示を行っており、それに伴う価格の根拠がユーザ側の価格への不信感につながっていることは従来から多数指摘されている※が、残念ながら、この課題は現在まで業界全体として抜本的に解決されるには至っていな
ユーザーと共通理解できる“システム観”が必要だ － ＠IT情報マネジメント
企業システム開発では、しばしばユーザーの思いどおりのシステムに仕上がらないことがある。その大きな原因の1つが、ユーザーの“要求”と開発者の“理解”のズレだ。ユーザーと開発者が共通認識にたどり着くには、何が必要だろうか？（→記事要約<Page2>へ） 業務システム向けの分析設計技法としてさまざまなやり方が提唱されています。有名なところがUMLを用いた「オブジェクト指向分析・設計手法」です。しかし、開発現場で実際に利用されているのは、昔から無批判に繰り返されてきた古めかしいやり方だったり、せいぜい「UMLもどき」とでもいえそうな案件ごと独自に「工夫」されたやり方です。 UMLは、バラバラだったオブジェクト指向系の表記法を統一するための体系として鳴り物入りで登場しましたが、必ずしも当初の期待どおりの効果を挙げているわけではありません。それは、システム開発においてボトルネックになっているのが「シス
ユーザーと共通理解できる“システム観”が必要だ － ＠IT情報マネジメント
大抵の手法や表記法には、それを支援するモデリングツールが存在しています。「三要素分析法」も例外ではなく、XEAD（Xml- based Enterprise Architecture Designerの略。ジード）というモデリングツールが提供されています。XEADは筆者が自作したJavaアプリケーションで、次のサイトから無償でダウンロードできます。 モデリングツールが提供されているだけでなく、そのツールで閲覧・編集可能な実践的な「サンプル」も提供されています。それが「CONCEPTWARE」と呼ばれるレファレンスモデルライブラリーで、上記のサイトからダウンロードできます。 CONCEPTWAREのライブラリーは現時点では「財務管理」だけですが、今後「販売管理」「生産管理」「人事給与管理」が発表される予定です。それらのコンテンツは設計スキルを磨くための教材にもなるし、実務で利用する設計情報の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
