見積もり・発注

ドキュメント作成

詳細設計

アルゴリズム

サブトピック

一般

アーキテクチャ

アーキテクチャって何?という素朴な疑問にはなかなか答えづらいが、一般的には、設計時の大きな方向性や方針を意味する。要件は実現しようとする機能の内容に重点を置くが、アーキテクチャは機能の実現方式に重点がおかれる。

クリーンアーキテクチャ

基本設計

  • 基本設計は大雑把な設計、詳細設計は細かい設計だと思っている人がいるが、それは誤り
  • 基本設計は、システムを外から見たときどういう動きをするか(=外部設計、What)を決めるもの。詳細設計は基本設計で決められた動きをどうやって実現するか(=内部設計、How)を決めるもの、と考えるとよい。基本⇔詳細という言葉に惑わされず、外部から見たときの動きについての話なのであれば、どんなに細かいことでも基本設計に書く。
  • 機能要件設計書だけで20種類 2009.1.8
    • 基本設計は大きく分けて三つのプロセスを踏む。いずれの設計も入力情報となるのは要件定義で作成した成果物である。
      • 「機能要件設計」どのような機能をアプリケーションに求めるかを設計する。その際「画面」「業務プロセス」「データ」という三つの切り口に分ける。
      • 「システム方式設計」システム方式設計では、性能や信頼性などの非機能要件を整理する。それを踏まえて、ハードウエアやソフトウエアなどの構造や実装方式を練る。
      • 「アプリケーション方式設計」アプリケーション方式設計では、非機能要件を考慮しつつ、機能要件設計で明確にした機能(画面、業務プロセス、データ)を適切なサイズのモジュールに割り当てる。
    • 基本設計で作成する設計書の一覧(日立システム開発方法論「HIPACE」を基に作成)
  • システムのリプレース案件が最も危険な理由 2008.2.24
    • 運用していくうちに、バグフィックスや機能追加で、恐竜のように馬鹿でかくなった中身は、最新のオブジェクト指向言語で、同じようにたくさんのバグフィックスを重ねて積み上げたものに変わる。 同じソースコードの断片は一つもないはず。
    • プログラムの保守性や移植性、再利用性が、どの時代になっても、言語がいくら発展しても難しいこと。
    • 特に再利用性は、そのライブラリの粒度に大きく依存する。
    • 再利用できる程度は、フレームワーク程度ぐらいで、昔から夢想するビジネスオブジェクトレベルまでなかなか辿り着けない。

画面設計

要件定義と基本設計の違い

  • 要件定義とは、乱暴に言うとそのシステムで実現したい(および実現しない)ことをまとめたもの
  • 要件定義の一般的項目→要件定義書の一般的な項目
     ・業務要件:現状、新業務フロー等
     ・システム要件:インフラ系を中心にネットワークやシステム構成等
     ・セキュリティー要件:セキュリティに関しての要求事項等
     ・機能要件:大まかな機能や、「これを実現して欲しい」等の要求
      ・非機能要件:性能要件や障害発生時にどうなるかなど
     ・運用要件:運用まわり、バックアップ、容量見積等
     ・その他:ケースバイケースで他に何かあれば
     ・昔はレスポンス要件等もあったがWEBでは保証できない
  • 基本設計の一般的項目 乱暴に言うと、要件定義をインプットとしてシステムの外部仕様を決めるのが基本設計
     ・システム設計:インフラ、ネットワーク、機器構成、プロダクト構成等
     ・画面設計:デザイン、項目定義等
     ・DB設計:論理/物理設計、ER図等
     ・インターフェイス設計:他システムとの外部インターフェイス、ファイル、帳票設計等
     ・処理設計:DFD、IPO、CRUD、コード設計等
     ・業務・運用設計:サービススケジュール、バックアップ、リカバリー方法
              新業務フローの詳細等
     ・テスト設計:テスト方法、ツール等の設計
     ・その他:補足資料他

要求開発

  • 観察力と推理力のプロ 2008.4.9
    • 「企業の本社や管理部門は報告書やら何やらであまり役に立っていないものがどっさりありますが,物流センターのような現場には無駄な物なんてないんですよ。どんなに旧式のプリンタであっても業務に必要だからそこに置いてあるわけで,そういう意味では紙切れ1枚にも大概役割があるんですね」
  • システム開発には広い視点で取り組め 2008.4.7
    • 利用部門が主体ということと,利用部門の言うことをなんでも聞くことは全く異なる。利用部門は新システムに対しても従来通りの機能を要求したり,自分が困っていることを解決してほしいという観点だけで要件を出すことが多い。
  • RoRで要求仕様を開発(RfS)
    • 要件定義フェーズでRfSを行うときには,もらった設計書を単にプログラム化するだけの能力しかないプログラマでは荷が重い。
    • 変化に強いスタイルで構築しなければならないため,オブジェクト指向をちゃんと理解したうえで,アジャイルの設計スキルと,きれいにコードを作成できる技術を身に付けた開発者である必要がある。そうでないと,要件定義の間に「仕様」のアプリケーションが変化に対応できなくなってしまう。また,開発しながら仕様を決めるので,要件定義のスキルも必要だ。
    • つまり,このフェーズでプログラミングを行う開発者は高度なスキルを要求される。RfSとは,上流フェーズをプログラミングを使って行うということなのだ。
  • 要求を洗い出す4つの工夫
    • 模型を作って動かす
    • 壊しては作る
    • サンプル集で動きを確認
    • UI仕様書と画面見本
  • 要求分析ツリー
  • 開発プロセスの本質・要求開発のフロントローディング開発
    • 【現状の課題】
      • 要求自体がどんどん複雑化し,とらえづらくなっています
      • 既存の人の業務をコンピュータ化するという観点だけではなく,業務をIT化することで付加価値を創出しなければならないという課題を負うことが多くなります。
      • このような要求については,要求提案当初は非常にあいまいな場合が多いのです。
      • 様々なテクノロジを組み合わせて開発した結果,はたしてビジネス要求を実現できるかのかどうか,ちょっとやってみないとわからない
    • 【対策】
      • これらのリスクをできるだけ早期にヘッジするために,反復開発やアジャイル開発
      • (1)要求を早期に検証する
      • (2)技術的リスクを早期にヘッジする
    • 【上記対策の問題点】
      • システム開発よりも前段階で,つまり企業の将来ビジネスを構想する要求開発の段階にて,両リスクをヘッジするための対策を講じる必要が出てくる
      • ビジネスとITが密接に関係するような問題領域では,ビジネス要求をITでどう表現するかによってIT化の価値が左右するため,試行錯誤しながらビジネス価値を創出するIT表現を洗練させることが重要となる。
  • 要求定義の基本を知る
    • あらゆる要求定義に共通する「4つの必須スキル」がある。それは,
      • (1)ヒアリング技法
      • (2)業種・業務知識
      • (3)要求定義の方法論
      • (4)要求をモデル化するための図法――の4つだ。
    • 要求定義を成功させるためには,まずこの4つの必須スキルを身に付けて地道に実践するしかない。

業務知識


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2022-10-13 (木) 23:07:41 (44d)