Webの仕事をしていると、Webサイトを作る過程で様々な設計書を作ります。ディレクトリマップやワイヤーフレーム、ときにはデータベース設計書など。このページでは、Web制作に携わるメンバー全員が共通の認識を持って作業ができるように必要な設計書についてお伝えしてます。 Pocket 9. どのような方式でバックアップし、どのストレージに保存するか記載します。論理的な構成要素について、拡張可否、拡張時の方針を記載します。セッション維持のためにどのような通信にパーシステンスを適用するのか記載します。通信データ、ストレージデータについて、暗号化対象と方式を定義します。バックアップ対象を、どのデータでどういった手段でリストアするのか記載します。サービス名、帯域、インターフェース、アクセス回線種別、Act/Stb系を一覧で記載します。適用プロトコルの一覧とそれに対するアクションの一覧を記載する。DNS機能を提供する機器、及び名前解決要求の送信元、転送先を俯瞰した図を記載します。この章では、基本設計を実施するインフラシステムの全体方針を記載します。障害対応を開始する契機を記載します。(例: 監視検知、ユーザ申告)内部から外部へ配送を行うメールについて、通信フロー、プロトコル、対象ドメインを記載します。Web機能を提供する機器、および社内/社外のクライアント端末を俯瞰した図を記載します。システム全体の稼働時間(夜間や休日の停止を許容するのか)、後述の各要素の可用性設計を行うことによる目標稼働率について記載します。以下のように定期的に発生する業務について、実施周期と作業概要を記載します。サーバが提供するインフラ機能について、単位時間あたりの処理数を記載します。この章では、物理的な機器や配線に関する決め事を記載します。クラウド環境のみの場合はこの章は不要です。名前解決要求を受け付ける送信元、名前解決要求の転送先を記載します。バックアップ対象について、どういった場合にリストアを行うのか記載します。物理的な回線帯域や、機器のスケールアップ、スケールアウトの可否を記載します。パーティションのフォーマット、パス、サイズ、役割を記載します。WAN網を中心に置き、通信を行うデータセンタやオフィス拠点を記載します。管理対象ドメイン、マスター/スレーブの種別、ゾーン転送元/転送先について記載します。ウイルスチェックを適用する通信プロトコルの一覧とそれに対するアクションの一覧を記載します。SMTP機能を提供する機器、及びメールの転送元、転送先を俯瞰した図を記載します。基本設計書の位置づけを記載します。プロジェクト全体フェーズを図で示し、基本設計書を作成するためのインプット情報(要件定義書)、基本設計書をアウトプットとした後続フェーズの資料(詳細設計書)について定義します。マルウェア対策を行うサーバ、導入するアンチウイルスソフトを一覧で記載します。Copyright © 電算星組 All Rights Reserved.この章では、将来的にリソース需要が増加した場合に、どの設計項目をどのように拡張できるか方針を示します。拠点内に設置する機器間の配線図を記載します。接続するケーブル種別やポート番号も記載します。外部から内部へ配送を行うメールについて、通信フロー、プロトコル、対象ドメインを記載します。以下の事項について、どの機器でどのような機能やプロトコルによって実現させるか記載します。各システムコンポーネントに対して、アクセス制御の方式と条件を記載します。障害の原因となっている箇所に応じて、どのような対応をするか記載します。ゾーン間の通信方向ごとに、通信を許可/拒否する送信元、宛先の用途を記載します。バックアップの目的、対象機器、データ種別、バックアップ手段の概要を記載します。閲覧可能ネットワーク、ホスティングするWebコンテンツ種別、URL、通信プロトコルを記載します。監視対象の機器一覧、監視項目、監視監視プロトコルを記載します。以下のように都度発生する業務について、実施の契機と作業概要を記載します。Windows Serverで使用する役割と機能について記載します。監視の目的、方式(ICMP/SNMP/エージェント)を記載します。機器別の使用ルーティングプロトコル一覧、各プロトコルの方針を記載します。複数機器で異常を検知した場合、どのような切り分けをするか記載します。
要求仕様書から見積、基本設計、詳細設計、コーディング規約、テスト仕様書、その他スケジュールや議事録まで システム開発に必要な書類のテンプレートがそろっています。 基本設計のことを「外部設計」と呼ぶ場合もあるが、当サイトでは「基本設計」に統一して記載している。基本設計は、要件定義の結果を受けて、具体的なシステム構成や機能を設計する工程だ。基本設計書には、下記の４つを検討のうえ成果物としてまとめる。 ・業務設計 ・システム方式設計 ・アプリケーション機能設計 ・非機能要件設計要件定義書と同じく、企業によっては記載内容やテンプレートを整備している企業もあ …
続の対象とするかは詳細設計で検討する。 1-2 インフラシステム 複合施設ネットワークのインフラシステムとして、以下システム（又はサーバ機能）を構築対 象とする。 表1-2.2 対象システム一覧 項番 システム区分 対象システム 備考 クラウド上にシステム構築を行う前の設計フェーズで使用するドキュメントを想定して作成しました。 一般的に言う「インフラ基本設計」にあたるドキュメントです。 ドキュメントはこちらで公開しています。ご自由にお使いください。 外部設計書: 外部設計書のテンプレートです。 更新履歴や未決事項のシートも用意してあるので活用してください。 GaibuSekkei.zip: 内部設計書: 内部設計書のテンプレートです。 更新履歴や未決事項のシートも用意してあるので活用してください。 NaibuSekkei.zip
移行計画が重要なことを疑う人はいないだろう。移行計画書を作成すること自体は，もはや当たり前と言ってよい。だが，問題があると感じる移行計画書は少なくない。何が問題か―。それは「作るのが遅い」「記述が足りない」「精度が甘い」ということだ。 仕様書のダウンロードができるサイト . クラウド上にシステム構築を行う前の設計フェーズで使用するドキュメントを想定して作成しました。 一般的に言う「インフラ基本設計」にあたるドキュメントです。 ドキュメントはこちらで公開しています。ご自由にお使いください。 多くの資料は、要件定義でまとめているはずなので、基本設計で新たに作成する資料は少ない。今回のシステムを実現するうえでのハードウェア構成を明確にする資料。今回のシステムを実現するうえでのソフトウェア構成を明確にする資料。例えば、上記サンプルでは、ログインボタンが押下されたときに「UsernameとPasswordの入力チェック」とだけ書いているが、どのようなチェックをするかまで具体的に書く必要がある。要件定義書にもまとめられているはずなので、基本設計で新しく記載する必要はないだろう。要件定義のネットワーク要件をもとに、基本設計で検討した内容を反映させる。単体テスト・結合テスト・総合テスト・運用テストといった各テスト工程について、プロジェクトの特性に応じて、下記のような観点を記載する。要件定義のハードウェア要件をもとに、基本設計で検討した内容を反映させる。基本的な流れ「基本シナリオ」、基本外の流れ「代替シナリオ」に分けて整理していくと良い。シンプルな帳票は「帳票出力項目一覧」で十分だが、複雑な編集方法を持つ帳票については、当資料を作成する。非機能要件設計の各資料には方針や考え方を記載し、具体的な設計内容は、アプリケーション機能や基盤設計の各資料に反映することとなる。今回のシステムを実現するうえでのネットワーク構成を明確にする資料。（要件定義での検討が不足していると、基本設計で苦労することになる）利用者のアクションに対して、システムがどうアクションをするのかを記載する。ちなみに、入力チェックをクライアント側に実装するのか、それともサーバー側で実装するのかは、次の工程である「詳細設計（内部設計とも言う）」にて検討する。下記のように、基本的な流れでは無いものの、一般的に起こる可能性のあるシナリオのことだ。各テーブルについて、どの機能で、作成・参照・更新・削除がされるかをまとめた資料。上記のサンプルのように、業務機能構成表に「システム化対象」という区分を設ける場合が多い。関連システムとやりとりするデータについて、主要なデータ項目を一覧にまとめた資料。最初に述べたように、作成する成果物やテンプレートや書き方は、企業の標準としてまとめられている場合もあるので確認してほしい。要件定義のソフトウェア要件をもとに、基本設計で検討した内容を反映させる。基本設計は、顧客の要件を実現するためのシステム構成や機能を具体化する工程だ。性能や信頼性などの非機能要件をもとに，システム全体の構成を検討する作業だ。この資料も業務部門の利用者にとっては理解しづらい資料であるものの、基本設計で検討しておく資料だ。要件定義では、定常運用・臨時運用・障害時運用における要件を記載したが、基本設計段階では、各要件を実現するに当たっての運用保守業務設計、および必要な環境や機能の設計を行う。運用保守業務に入る本番移行前〜フォロー期間にて詳細な内容を検討し、運用保守契約を締結することとなる。・ソフトウェアの選定や購入、情報システムの開発や保守に際して、情報セキュリティを前提とした管理を行う。業務部門の利用者にとっては理解しづらい資料であるものの、画面や帳票との関係が深いため、基本設計でまとめておくべき資料である。外部システムとやりとりするデータについて、その方法を記載した資料。要件定義では業務上の主要なテーブルのER図を作成するが、基本設計では、システムを実現する上で必要なテーブルを全て書き出す。後述の「業務機能構成表」や「アプリケーション機能構成図」に記載する場合もある。上記の中でも、IPAの資料は、具体的な書き方や検討のコツも紹介されているので、特に参考になると思う。基本設計工程では、画面・帳票・テーブルなどの設計した後に「基本設計書」としてまとめるが、どのような資料を作るのか不安を感じるエンジニアも多いと思う。基本設計のことを「外部設計」と呼ぶ場合もあるが、当サイトでは「基本設計」に統一して記載している。・情報（データ）や情報システムへのアクセスを制限するために、利用者IDの管理（パスワードの管理など）を行う。要件定義のざっくりとした内容を元に、システムを実装できるレベルまで具体的に記載しよう。要件定義書と同じく、企業によっては記載内容やテンプレートを整備している企業もあるので、まずは自社のルールを確認することをお勧めする。※当サイトでは、情報処理推進機構（以下、IPA）や行政機関の資料を参考に記載している。・インターネット接続に関わる不正アクセス対策（ファイアウォール機能、パケットフィルタリング、ISP サービス 等）を行う。前述のER図に記載したテーブルを一覧にまとめるだけでなく、機能の入出力で用いるファイル（txtやcsv等）についても記載する。出力項目は、どのテーブルの、どの項目から値をセットするかまで記載が必要だ。要件定義書から転記することになるが、アプリケーション機能を具体化していく中で修正が必要になる場合もある。システム構成は、要件定義段階でほぼ決定しているはずなので、設計の結果を反映させることが主な作業となる。なお、入力項目でも、プルダウン（コンボボックス）のような選択項目の場合は、どこから値をセットするのか検討が必要となる。画面の出力項目と同じく、どのテーブルの、どの項目から値をセットするかまで記載が必要だ。プロジェクトの特性にもよるが、基本設計書には下記の内容を記載する。上記図は、「テーブルと機能のCRUD図」だが、下記図のように「テーブル項目と機能とのCRUD図」を作成する場合もある。要件定義書に記載したテーブルはもちろんのこと、バッチ処理内で一時的に利用するテーブル（ワークテーブル）等の記載も書き出そう。基本設計は、要件定義の結果を受けて、具体的なシステム構成や機能を設計する工程だ。システム機能だけでなく、データ移行や新業務への移行等、プロジェクトの特性に応じて移行方法を記載する。基本設計では、ユーザーがどのようなアクションをしたときに、システムがどのようなアクションを返すのかを具体的に記載する必要がある。