タグ

設計に関するsigh2のブックマーク (4)

  • [方式設計編]性能要件はユーザーが決めると思ってはいけない

    「ユーザーが要件を決めてくれないので…」「性能要件を出していただかないと機器が見積もれません,早く要件を出してください!」。要件定義フェーズのみならず,プロジェクトの様々な工程でよく耳にする言葉である。 非機能要件はユーザーにヒアリングして洗い出すのが,インフラ設計における一般的な手法だ。だが,インフラ設計者はヒアリングによって得られたユーザーの「要望」を絶対的な「要件」としてとらえてはいけない。非機能要件を洗い出すに際しては,要望の裏にあるリスクやそこから派生する制約を先読みすることが重要である。その思考を停止してしまうと,後工程で様々な問題が発生する。 今回は,非機能要件の中でも読者にとって最も身近だと思われる「(オンラインの)性能要件」を例に解説する。なお,現在のシステム構築では,現行システムが存在せずゼロから開発することはほとんどない。従って,ここでは現行システムで何らかの稼働統計

    [方式設計編]性能要件はユーザーが決めると思ってはいけない
  • キミの設計に「トレーサビリティ」はあるか ― @IT情報マネジメント

    システム開発の流れを俯瞰(ふかん)する 1.1 「ビジネス要求」から「実装・テスト」までステップは5段階 システム開発の工程は5つに分けることができます。すなわち、 ビジネス要求(の分析) システム要求(の分析) 機能(の設計) メソッド(の設計) 実装・テスト(の実施) です(図1)。 「ビジネス要求(の分析)」から「機能(の設計)」までを開発工程の前半とします。前半段階では、構築すべきシステムに対するビジネス・サイドの要求を明らかにします。つまり、業務を見える化(モデル化)し、誰にでもわかる形に仕立てます。 「メソッド(の設計)」から「実装・テスト(の実施)」までを開発工程の後半とします。後半段階では主に、システムに対するビジネス要求を実現するための機能(メソッド)を設計します。設計作業が終了すると、実装、テストを行い、機能が正しく実装されているか、ビジネス要求が満たされているかを検証

    キミの設計に「トレーサビリティ」はあるか ― @IT情報マネジメント
  • 「設計」作業の成果は完成品質を左右する ― @IT情報マネジメント

    格的なシステム開発に初めて携わった青木室長、そして、豊富なシステム開発経験を武器に青木室長を支える部下の赤井君……。そんな、凹凸コンビの2人でしたが、社長や各部門の責任者・担当者、さらには実店舗の店員、開発ベンダなど、インターネットショップ開発・運営にかかわるすべての関係者との交渉・調整を重ねながら着実にシステム開発を進めてきました。プロジェクトがシステム設計工程に入り、後は開発ベンダにお任せ……といわんばかりの青木室長に、今日も赤井君の「ツッコミ」が入るのでした。 設計する内容は実にさまざま 青木室長と赤井君が作成したRFP(Request for Proposal)をもとに数社から受けた提案を比較・検討し、開発委託先ベンダの選考を行った結果、システム開発手法の柔軟さや、業務システムからインターネットシステムまで幅広い開発実績を持つB社に委託することが決定しました。そして、プロジェクト

    「設計」作業の成果は完成品質を左右する ― @IT情報マネジメント
  • HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方

    HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方 目次 この文書について 設計文書のうまい書き方 なぜ設計文書を書くのか 良い設計とは何か 同僚の開発者に向けて書く 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す 第 2 節に書くこと: 設計に使う高レベルなエンティティを定義する 第 3 節に書くこと: 個々のエンティティに関する低レベルの設計を書く 使い方 設定 モデル 相互作用 第 4 節に書くこと: 利点, 前提, リスク/懸念事項 マネージャ向けに書くこと 最後に 設計文書のうまい書き方 この文書について "How to Write an Effective Design Document" の日語訳です. http://blog.slickedit.com/?p=43 推敲歓迎: 誤訳, タイポ, 訳語の不統一,

  • 1