タグ

システム開発に関するsidetailのブックマーク (6)

  • バッチ処理を再考する - 急がば回れ、選ぶなら近道

    最近そもそもバッチ処理というものを知らない人達を見ることが多くなりました。某プロジェクトで「いや、ストプロってよくわからないんですよ。最近書いたことないし。」という話をずーっと聞いていたのですが、人はバッチ処理という意味で話していたことが後から判明した、ということがありました。 ああ、この人はSQLでのバッチ処理しか知らないのですね、とちょっと衝撃ではありました。とうとうそーゆー時代になったかと。 まず、誤解のないようにいうとバッチ処理、という言葉自体はIT固有のものではないです。生産管理や物流や、そういった業務では普通に「バッチ」という言葉をIT以外で使います。ただし意味はある程度同じで、「一定の塊を一度に処理をする」ということです。物流システムの業務要件なんかを詰めているとバッチっていうと、どっちのこと?なんて普通に聞かれたりします。その意味ではバッチの対義語がリアルタイムというのは

    バッチ処理を再考する - 急がば回れ、選ぶなら近道
  • 「Amazon EC2を使った実践SaaS運用事例」の資料を公開します+参加記録 (ITproテクノロジ・カンファレンス) - 元RX-7乗りの適当な日々

    先日、4/10に開催された"ITproテクノロジ・カンファレンス(徹底理解「Amazonクラウドサービス」)"にて、『Amazon EC2を使った実践SaaS運用事例』というテーマで発表しました。 (参考: IT pro テクノロジ・カンファレンスで話をします(徹底理解「Amazonクラウドサービス」)) これは、TIS/SonicGardenで展開している「SKIPaaS」というサービスを構築・運用する過程で、何故Amazon EC2をインフラとして採用したのか、Amazon EC2をどう活用しているのか、何が問題点でどういう工夫をしているのか、今後の課題・改善点は何か、といった内容です。 日経BP社様のご好意で、資料を公開してOKという許可をいただきましたので、以下に公開します。 Amazon EC2を使った実践SaaS運用事例 from Yuuki Namikawa ↑の資料のポイン

    「Amazon EC2を使った実践SaaS運用事例」の資料を公開します+参加記録 (ITproテクノロジ・カンファレンス) - 元RX-7乗りの適当な日々
  • [IT業界の弱者]6億円を半額にしろととんでもない要求

    金融機関のシステム子会社に勤める高山真一さん(仮名)は,親会社の基幹系システムをオープン化するプロジェクトに,価格交渉の担当者として参加していた。このプロジェクトでは,親会社の担当者による強硬な値下げ要求により,数十人ものITエンジニアが苦しまされた。 「機能追加分は払わない」 親会社のシステム企画部門に所属するこのプロジェクトの担当者から,システムの概要仕様書を提示された。その仕様書に基づいて見積もることを求められ,約3億円(誌推定)と見積もった。悲劇の種はこの時点で既にまかれていた。後から考えれば,この概要仕様書は,どうやらユーザーへのヒアリングを十分に行わずに作成されたものだった。それに基づいて見積もった金額が基準となってしまい,その後の不当な値下げが要求される事態を招くことになった。 概算見積もりの後に機能を詳細に検討すると,概要仕様書にはない,必要な機能が次々と判明する。精査す

    [IT業界の弱者]6億円を半額にしろととんでもない要求
    sidetail
    sidetail 2009/03/09
    銀行のシステム開発評価はどこかおかしい
  • SI契約に変革迫る「進行基準」 IT業界に激震走る!:ITpro

    ユーザー企業のみなさんは、システム開発プロジェクトを進める際、ITベンダーに次のような依頼をしたことはないだろうか。 経営判断でシステムの稼働日は決まっている。だが、肝心の要件は固まっていない。「何としても納期を守ってくれ。要件定義と並行して、仕様が固まっている部分から、開発作業に着手してくれないか」。 すでに開発が済んだ部分について、利用部門から大きな仕様変更の依頼が来た。「予算はもう増やせない。申し訳ないが、最初に契約した金額のままで修正してくれないか。次の案件も御社に発注するから」。 新システムの予算を何とか確保した。あとはこの予算でシステムを開発してもらうだけ。「ハードウエア込み、要件定義から運用設計まで、すべて一括で契約してほしい」――。 頻繁とは言わないまでも、システム開発を進めるうえでは“よくある話”だ。問題があると分かっていても、経営層や他部門からの要請で、こうした依頼を

    SI契約に変革迫る「進行基準」 IT業界に激震走る!:ITpro
    sidetail
    sidetail 2008/06/30
    RFP作るところから手伝わされたり。「君のところに発注するからさぁ」。最終形は究極の丸投げか!?
  • デスマーチがなくなる? IT業界に義務付け「工事進行基準」ってなんだ ― @IT

    ユーザーの要件定義があいまいでシステム開発中も修正に次ぐ修正。プロジェクトは大幅に遅れて、予算が超過。しわ寄せは下請け、孫請けへ。デスマーチ……。新3Kともいわれるこんな日IT業界が2009年4月に大きく変わるかもしれない。そのきっかけとなるのが「工事進行基準」の原則義務付けだ。 【関連記事】 工事進行基準を分かりやすく解説してみよう【基編】 工事進行基準を分かりやすく解説してみよう【対応編】 工事進行基準(用語解説)とは会計基準の変更によって2009年4月にシステム・インテグレータ(SIer)など受注ソフトウェア開発業に原則として義務付けられる収益の計上方法。開発期間中にその売り上げと原価(費用)を、工事(ソフトウェア開発、システム開発)の進捗度に応じて、分散して計上する仕組みだ。 これまでSIerは、工事進行基準ではなく、開発終了時に売り上げと原価を一括計上できる「工事完成基準」

    デスマーチがなくなる? IT業界に義務付け「工事進行基準」ってなんだ ― @IT
  • ソフトウェア開発者のための推薦図書

    Code Complete 2 [ Code Complete第2版―完全なプログラミングを目指して (上・下) ] スティーブ・マコネルのCode Completeはソフトウェア開発者のための「楽しい料理だ。このを読むということは、自分の仕事を楽しんでいるということであり、自分のすることに真剣であるということであり、もっと向上したいと思っているということなのだ。Code Completeの中で、スティーブは平均的なプログラマが読む 技術書は年に1冊に満たないと指摘している。このを読んでいるという時点で、あなたはおそらく周りにいる開発者たちの90%と違う行動を取っていることになる。それもいい方向にだ。 私はこのがすごく好きで、ここから自分のWebサイトの名前(Coding Horror)を取ったくらいだ。このではやるべきでない悪い例には"coding horror"アイコンで印

  • 1