基本設計書 テンプレート。 エンジニア歴20数年の私が、設計書を書く際に心がけていること

ホームページの設計書ってどうやって作ればいいの!?

基本設計書 テンプレート

Contents• はじめに この章では、ドキュメントに関する決め事を記載します。 更新履歴 ドキュメントリリース後の更新履歴を表で記載します。 版数は、0. 01からはじめ、システムリリース時に1. 00としてFIXさせます。 版数管理のルールもここに記載します。 例:版数はx. xzで管理する。 xはシステム新規構築、リプレース時に増加させる。 yはサブシステムの追加、削除、変更時に増加させる。 zは、サブシステム内の軽微なパラメータ修正時に増加させる。 本書の目的 作成するドキュメントが、何のプロジェクトの、どの部分の基本設計書なのか記載します。 インフラ案件であれば、システム基盤 ネットワーク及びサーバ の外部的な動作の仕様を示す基本設計書である旨を記載します。 ドキュメント体系 基本設計書の位置づけを記載します。 プロジェクト全体フェーズを図で示し、基本設計書を作成するためのインプット情報 要件定義書 、基本設計書をアウトプットとした後続フェーズの資料 詳細設計書 について定義します。 用語の定義 ドキュメントの中で使用する用語を定義する。 プロジェクト体制 プロジェクトの構築体制図を記載します。 大規模プロジェクトで、サーバ担当、ネットワーク担当などチームが分かれている場合は、体制図をチームごとに分け、作成する基本設計書はどのチームが作成するものなのかを記載します。 基本設計範囲 設計範囲について、図および表で記載します。 既存システムとの接続要件や、他社ベンダが構築に絡む場合は、具体的な相互接続点の責任区分についても述べます。 ネットワーク設計であれば、外部システムへ接続するケーブルは範囲に含むかどうかを明記します。 サーバ設計であれば、ミドルウェア、アプリケーションをどこまで含むかを明記します。 システム設計 この章では、基本設計を実施するインフラシステムの全体方針を記載します。 システム概要 設計するシステムの概要を記載します。 全体構成図および構成一覧表 提供するシステムの機能、それに紐付く機器やソフトウェア を記載します。 機器一覧 機器用途、機器型番、選定理由を記載します。 機器緒元 別紙で機器緒元一覧を用意します。 ソフトウェア一覧 サーバ種別ごとに、インストールするソフトウェア名、バージョン、用途を記載します。 バージョンの選定方針も記載します。 物理設計 この章では、物理的な機器や配線に関する決め事を記載します。 クラウド環境のみの場合はこの章は不要です。 物理構成図 WAN WAN網を中心に置き、通信を行うデータセンタやオフィス拠点を記載します。 物理構成図 LAN 拠点内に設置する機器間の配線図を記載します。 接続するケーブル種別やポート番号も記載します。 フロア図 機器を設置する場所がフロア内のどのラックなのか図示します。 ラック収容設計 ラック内のどのユニット番号の位置に機器が設置されるか図示します。 機器の電源を接続する電源ユニットもラック収容図の中で表します。 廃熱のための空きユニットスペース、ケーブルの整線方針もここで示しておきます。 電源収容設計 機器ごとの最大消費電力一覧と、収容するラック内の電源設備を一覧で記載します。 UPSの設置有無もこの項目に記載します。 ポート収容設計 機器のポートをどういった順番で使用するか収容規則について定義します。 別紙でポート収容表を用意します。 インターフェース設計 機器間のインターフェース規格は何を使うのか記載します。 ケーブル設計 機器間のケーブル媒体、規格、色、タグの書式を定義します。 クラウド環境設計 AWSやAzureなどのクラウド環境では、物理環境の代わりにクラウド環境の設計を行います。 以下の内容について記載します。 使用サービス• プラン• 用途 仮想ネットワーク設計 仮想ロードバランサ設定 仮想サーバインスタンス設計 仮想ストレージ設計 論理設計 この章では、機器の論理的構成について記載します。 ネットワーク設計 ホスト名設計 機器ホスト名の命名規則を定義します。 論理構成図 どの機器が、どの論理的なネットワークで接続されているか記載します。 仮想機能を使用して物理的な機器に複数の機能を持たせている場合は、論理機器単位で図示します。 VLAN設計 セグメント名、用途、VLAN IDを定義します。 ネットワークの規模に応じて、百の位、十の位でフロアや用途を分けたり、IPアドレスの第3オクテットを使用するルールを決めると運用時に便利です。 IPアドレス設計 採番方針、セグメント名、ネットワークアドレス、対応するVLAN ID、用途を定義します。 ホストごとの詳細なアサイン表は、別紙で用意します。 プライベートIPアドレス• グローバルIPアドレス ルーティング設計 機器別の使用ルーティングプロトコル一覧、各プロトコルの方針を記載します。 WANルータ• 拠点L3SW• 全体構成図にアドレス変換ポイントを記載した図を用意します。 トラフィック制御設計 優先制御 優先制御を実施する目的、対象通信種別、対象機器について記載します。 QoS分類について、トラフィック種別、プロトコル、ポート番号を一覧で定義します。 マーキングについて、トラフィック種別、プロトコル、DCSP種別を一覧で定義します。 帯域制御 帯域制御を実施する目的、対象通信種別、対象機器について記載します。 WANルータの回線側インターフェースで回線帯域へ通信速度を合わせるためによくこの機能が使われます。 トラフィックフロー設計 正常時と異常時それぞれにおける、パケットの通信経路を記載します。 正常時は、通信種別ごとにどのような経路を通るか図示します。 異常時は、機器、ケーブルの障害ポイントごとに、どのような迂回経路をとるか図示します。 トラフィックフロー 正常時• トラフィックフロー 異常時 サーバ設計 Windows 時刻と言語 使用する時刻 タイムゾーン と言語を記載します。 ディスク構成 RAID利用有無について記載します。 パーティション構成 パーティションのフォーマット、パス、サイズ、役割を記載します。 役割と機能 Windows Serverで使用する役割と機能について記載します。 RHEL 時刻と言語 使用する時刻 タイムゾーン と言語を記載します。 ディスク構成 RAID利用有無について記載します。 パーティション構成 パーティションのフォーマット、パス、サイズ、役割を記載します。 パッケージ インストールするパッケージ グループ を記載します。 インフラ機能設計 この章では、インフラシステムの提供機能について、どのように動作するか記載します。 インフラシステムの提供機能が多い場合、この章は別ドキュメントで個別の基本設計書にしてもよいでしょう。 また、サーバ機器とネットワーク機器の括りで基本設計書のドキュメントを分ける場合もありますが、近年では専用アプライアンスの普及により区別が曖昧になってきています。 本記事ではサーバ、ネットワークを一纏めにして、L4以上の分野は「インフラ機能」として定義します。 ロードバランサ設計 機能概要 ロードバランサがどのような機能を提供するのか記載します。 対象機器一覧 ロードバランサ機能を提供する機器の一覧を記載します。 負荷分散対象 負荷分散対象となる機能、機器一覧を記載します。 負荷分散方式 負荷分散方式の方針および対応一覧を記載します。 ヘルスチェック方式 ヘルスチェックの方針を記載します。 パーシステンス方式 セッション維持のためにどのような通信にパーシステンスを適用するのか記載します。 UTM設計 機能概要 UTMがどのような機能を提供するのか記載します。 ゾーン設計 ゾーン名、用途、適用インターフェースを定義します。 オブジェクト設計 オブジェクト一覧 ポリシーで使用するオブジェクトを定義します。 アドレス、アドレスグループ、サービス、サービスグループ オブジェクトに付与する命名規則を定義します。 アンチウイルス設計 ウイルスチェックを適用する通信プロトコルの一覧とそれに対するアクションの一覧を記載します。 スパイウェア設計 適用プロトコルの一覧とそれに対するアクションの一覧を記載する。 ファイルブロッキング設計 適用プロトコルの一覧とそれに対するアクションの一覧を記載する。 公開Web設計 閲覧可能ネットワーク、ホスティングするWebコンテンツ種別、URL、通信プロトコルを記載します。 内部Web設計 閲覧可能ネットワーク、ホスティングするWebコンテンツ種別、URL、通信プロトコルを記載します。 SMTP設計 機能概要 SMTP機能を提供する機器、及びメールの転送元、転送先を俯瞰した図を記載します。 外部SMTP 外部から内部へ配送を行うメールについて、通信フロー、プロトコル、対象ドメインを記載します。 内部SMTP 内部から外部へ配送を行うメールについて、通信フロー、プロトコル、対象ドメインを記載します。 メール配送制御 送信元、宛先のネットワークアドレスやドメインに制限やルーティングを行う条件を記載します。 エイリアスやメッセージサイズ上限、同時接続数といった項目も方針があれば記載します。 DNS設計 機能概要 DNS機能を提供する機器、及び名前解決要求の送信元、転送先を俯瞰した図を記載します。 キャッシュDNS 名前解決要求を受け付ける送信元、名前解決要求の転送先を記載します。 可用性設計 この章では、システムの可用性について記載します。 基本方針 システム全体の稼働時間 夜間や休日の停止を許容するのか 、後述の各要素の可用性設計を行うことによる目標稼働率について記載します。 ネットワーク機器 機器の部品 電源、ファン、ディスクなど について、冗長化する箇所を記載します。 また、筐体の冗長化について、対象範囲、使用する機能やプロトコルを記載します。 ファイウォールやロードバランサといったL4〜L7の通信を扱う機器では、セッション同期、コネクション同期の方式について記載します。 サーバ機器 機器の部品 電源、ファン、ディスクなど について、冗長化する箇所を記載します。 また、筐体の冗長化について、対象範囲、使用する機能やプロトコルを記載します。 HAクラスタを組む場合は、データ同期方式について記載します。 ストレージ機器 機器の部品 電源、ファン、ディスクなど について、冗長化する箇所を記載します。 また、筐体の冗長化について、対象範囲、使用する機能やプロトコルを記載します。 ネットワーク 以下の事項について、どの機器でどのような機能やプロトコルによって実現させるか記載します。 回線冗長化• 経路冗長化• リンク冗長化 性能設計 この章では、システムの性能について記載します。 ネットワーク機器 スループット bps や応答値 ms について性能目標を記載します。 また、ロードバランサやUTMについては、同時セッション数も合わせて記載します。 サーバ機器 サーバが提供するインフラ機能について、単位時間あたりの処理数を記載します。 物理拡張性 物理的な回線帯域や、機器のスケールアップ、スケールアウトの可否を記載します。 回線帯域 WANルータ 拠点L3SW サーバ 論理拡張性 論理的な構成要素について、拡張可否、拡張時の方針を記載します。 VLAN IPアドレス セキュリティ設計 脆弱性対策 外部からの脆弱性を突いた攻撃をどのように防御するか方針を記載します。 また、セキュリティパッチの適用方針有無、対象についても一覧で記載します。 マルウェア対策 マルウェア対策を行うサーバ、導入するアンチウイルスソフトを一覧で記載します。 アクセス制御 各システムコンポーネントに対して、アクセス制御の方式と条件を記載します。 データ暗号化 通信データ、ストレージデータについて、暗号化対象と方式を定義します。 管理機能設計 アカウント設計 機器に設定するアカウントの一覧とその役割を記載します。 パスワードは設計書に載せず、別の手段で運用担当者へ共有したほうがよいでしょう。 リモートアクセス設計 機器ごとのログイン方式 SSHやWebUI について記載します。 また、接続を許可するリモートアクセス元の環境についても記載します。 時刻同期設計 機器に設定するタイムゾーンについて、UTCまたはJSTのどちらかを記載します。 また、時刻同期先のNTPサーバの情報を記載します。 名前解決設計 各機器の名前解決利用有無、方式、名前解決先を記載します。 ログ設計 機器のOS、アプリケーションが出力するログの一覧を記載します。 ログローテーション周期、圧縮有無、保存世代数も記載します。 SNMP設計 監視運用のため、SNMPポーリングを許可するアクセス元IPアドレス、コミュニティ名を記載します。 また、SNMP Trapを使用する場合は送信先SNMPマネージャも記載します。 サーバ機器は監視ソフト付属のエージェントをインストールすることが望ましいですが、システム要件などで制約がある場合はひとまずSNMPで最低限の監視をします。 保守運用設計 保守運用設計では、リリース後にシステムを運転し続けるために必要な項目を記載します。 保守 システムをあるべき姿に保つために変更を加える作業 と、運用 システムを動かし続けるために必要な作業や確認 は厳密に異なりますが、それぞれが連携する業務が多いので、システム運用を行う組織内で保守を兼任する場合が多いです。 運用をMSP企業にアウトソースする場合、保守運用設計はインプットとなる情報なので、重要な設計項目です。 保守運用業務一覧 システムが動作し続けるために実施する必要のある業務の一覧を記載します。 以下の内容も整理しておくと良いでしょう。 保守と運用の区分 担当部署が分かれている場合• 誰が行うか 人 or 自動化• いつ行うか 定常 or 非定常 定常業務 以下のように定期的に発生する業務について、実施周期と作業概要を記載します。 [保守]• セキュリティパッチ適用 計画• SSL証明書更新 [運用]• バックアップ• ログローテーション• ジョブ実行• 製品EoL情報管理• ベンダ保守契約情報管理• 定期レポート作成 非定常業務 以下のように都度発生する業務について、実施の契機と作業概要を記載します。 [保守]• セキュリティパッチ適用 緊急• 障害対応 復旧作業• ソフトウェアバージョンアップ• 機器増設 拡張性設計に準拠した内容• 機器設定変更 [運用]• 障害対応 アラート切り分け、正常性確認• 監視対象 監視対象の機器一覧、監視項目、監視監視プロトコルを記載します。 監視項目 以下のような監視項目ごとに、値取得間隔、閾値を定義します。 死活監視• トラフィック監視• プロセス監視• ポート監視• ログ監視• HW状態監視• サービス応答監視 バックアップ・リストア設計 基本方針 バックアップの目的、対象機器、データ種別、バックアップ手段の概要を記載します。 バックアップ バックアップ対象 対象機器、データについて定義します。 対象データは、OSイメージ、DBデータ、ログデータなどがあります。 バックアップ方式 どのような方式でバックアップし、どのストレージに保存するか記載します。 バックアップポリシー 対象データごとに、フルバックアップ、差分バックアップ、増分バックアップなど方式を記載します。 日次、週次、月次などバックアップスケジュールも記載します。 リストア リストア基本方針 バックアップ対象について、どういった場合にリストアを行うのか記載します。 リストア方式 バックアップ対象を、どのデータでどういった手段でリストアするのか記載します。 障害対応設計 基本方針 データ保全を優先させるのか、サービス復旧を優先させるのかなど、対応の基本方針を記載します。 詳細設計以降に具体的な手順を作成するので、この段階では概要レベルでよいです。 対応契機 障害対応を開始する契機を記載します。 例: 監視検知、ユーザ申告 切り分け 複数機器で異常を検知した場合、どのような切り分けをするか記載します。 ネットワーク: Ping試験、トラフィックグラフの確認• ハードウェア: リモート管理ボードの異常表示有無の確認• OS: CPU、メモリ、ディスクに関するリソース異常有無の確認• ミドルウェア: サービス起動状態、ポートリッスン状態の確認 対応内容 障害の原因となっている箇所に応じて、どのような対応をするか記載します。 共通: サービス切り離し、対応完了後のサービス切り戻し• ハードウェア: 筐体交換を保守ベンダへ依頼• OS: バックアップからリストア• ミドルウェア: バックアップからリストア.

次の

基本設計に必要なのは全体視点 情報システムをまとめる基本設計とは?

基本設計書 テンプレート

クラス設計とは 外部的な振る舞いを設計する基本設計(外部設計)と違い、クラス設計は、プログラム内部の構造を設計する詳細設計フェーズに位置します。 極端な話、クラス設計などなくても、全ての処理をひとつのメソッドに書いてしまうこともできます。 では、なぜそうしないのか?先に述べたようなプログラムでは、様々なコストが掛かってしまう可能性が非常に高いからです。 劣悪な設計によるコスト増大 保守コスト たとえば、一人でプログラムを組むとしましょう。 プログラムの隅々までしっかり把握しており、何か変更を加えなくてはならなくなったときでも、素早くその箇所に辿り着き、変更を加えることができます。 しかし、現実に、一人でそのプログラムを永久にメンテナンスすることはあり得ません。 自分ひとりで運営しているサービスであったとしても、不慮の事故により、誰かにサービス運営を任せることになるかもしれません。 そうなったとき、先ほど述べたようなプログラムは、コードリーディングに膨大な時間が掛かることは容易に想像できます。 変更コスト 変更は常に起こり得るものです。 サービスの拡張や、新機能の追加など、変更の理由は挙げればキリがありません。 単一の、メソッド分割すら行っていないプログラムでは、1つの変更が発生したとき、必ず複数個所の変更が発生します。 場合によっては、100か所を超える変更が必要になるかもしれません。 いくらIDEの進化が進み、置換一発で変更できるとはいえ、無限に発生する変更のことを考えるたび、頭を抱えたくなることは疑いようもありません。 クラス設計の手順 インターフェース設計 プログラムは、基本的に何かを受け取って何かを返すものです。 こういった入出力を表現するため、まずはインターフェースを設計します。 インターフェースは、ごく抽象的な概念です。 お馴染みの、JavaのListインターフェースを例にとって考えてみましょう。 Listは、Listであることが明示されていますが、その内部構造までは示されていません。 これは、ただのインターフェースであり、使用者はこの仕様さえ理解していれば、中身が何であっても利用できます。 我々が通常使うのは、「ArrayList」ですが、内部の構造や、アルゴリズムが違う「LinkedList」や、「Vector」なども存在します。 これらはListとしてのメソッドを全て備えており、定義された規約どおりに実装されているので、細かい実装を理解することなく使うことができます。 インターフェースは、現実世界の自動車などに例えて説明されることがあります。 先ほどのListになぞらえると、add メソッドは「アクセルペダル」という規格、「要素を追加する」という規約は、「自動車が動く」という規約に当てはまります。 これにより、自動車の使用者は何の疑問もなく利用することができますが、内部的にどういう仕組みで動いているのかは、一般人にはあまり知られていませんよね。 インターフェース設計のコツは、「入力と出力」のみに着目することです。 この段階で実装を見越した定義を行ってはいけません。 そうしてしまうと、どうしても「実装ありき」のインターフェースになってしまうからです。 クラス構造を設計する クラス設計におけるメインのフェーズです。 ここでは、クラスにおける「責務」を常に意識して構造を組み立てます。 たとえば、通販サイトで使う、「商品」クラス構造を考えてみます。 これは、取扱い製品の例です。 まずItemインターフェースを次のように定義します。 getPriceは、商品の価格を返すメソッド、getNameは、商品名をStringで返すメソッド、getDescriptionは、サイトに掲載する説明文を返すメソッドです。 次に、実装クラスであるBookを作成していきましょう。 しかし待ってください。 この実装には、getPriceやgetNameなど、共通化できる箇所がありそうですね。 この場合、AbstractClassを作って、実装クラスのコーディング量を減らすことができます。 AbstractItemクラスで処理を共通化したので、Bookクラスを以下のように変更します。 AbstractClass(抽象クラス)とInterface(インターフェース)の違い これまで説明してきたように、インターフェースとは、外部に対する入出力を定義したものです。 対して抽象クラスは、もう少し具象的な概念として、メソッドの振る舞いや、フィールドの定義を行うことができます。 極端な話、全てを抽象クラスとして定義することも可能です。 しかしJavaは、多重継承ができません。 ところで、「フォークとしてもスプーンとしても使うことができる」という、スポークと呼ばれる便利な食器があります。 これを継承で表現することは出来ませんから、こういった概念を表現したい場合は、必然的にインターフェースを利用することになります。 クラス図を作成する 何も、UMLを用いてしっかりと作る必要はなく、場合によっては紙とペンや、ホワイトボードを用いて設計する場合もあります。 クラス図は、クラス構造の理解を助ける大切なドキュメントです。 他者とのチーム開発を行う場合は、必ず形として残しておきましょう。 先ほど述べたように、UMLで作る必要はありません。 クラス同士の結びつきがわかりさえすれば、エクセルやパワポ、ペイントなどでも構いません。 ノートに手書きで残してもよいのです。 大切なのは、プロジェクトメンバーや後任者に「伝わること」です。 クラス設計における重要な原則 単一責任原則 Single Responsibility Principle 「クラスを変更する理由は、単一でなければならない」 クラスを変更する要因は様々ありますが、変更を見越した設計にすることが大切です。 もし、変更する理由が複数ある場合、チーム開発ではタスクを割り当てられた複数人が同時にそのクラスを触ることになります。 この場合、クラスは非常に不安定な状態になり、多数のコンフリクトを生む原因となってしまいます。 これが、単一責任原則に則った設計になっていれば、ひとつの変更理由に対応するメンバーは通常1名ですので、コンフリクトを懸念することなく作業することができます。 ことプログラミングにおいては、重複コードというのは大抵の場合、「邪悪」なものです。 遠い未来に渡ってコードやビジネスロジックが変更されない保証はありません。 コピー&ペーストで作るロジックは、確かに新規に記述するときは楽でしょうが、変更が生じた場合、そのすべての重複箇所を変更しなくてはなりません。 それが2つや3つなら大した問題にはなりませんが、20、30だったら?あるいは、変更漏れがあったら? こういった問題を避けるために、プログラム上のコードは、できるだけ重複を避けることが大切です。 クラス設計に限って言えば、適切な継承や、クラスの分離などが挙げられます。 KISS原則 Keep it simple, stupid! 「シンプルにしておけ!」 プログラムにおいて、シンプルであることは美徳であると同時に、最も重要なことです。 必ずこれを念頭に置いてクラス構造を設計しましょう。 しかし、上で述べた単一責任原則は、KISS原則と相容れません。 単一責任原則を突き詰めると、クラス数が増大し、お世辞にもシンプルとは言えない構造になります。 どちらを重視するかは、正直なところケースバイケースであると言わざるを得ません。 設計者の好みによるところではありますが、シンプルにしておくことは非常に重要な要素ですので、可能な限り意識して設計を行っていきましょう。 まとめ プログラムはどのような乱暴な設計でも動かすことが可能ですから、クラス設計に答えはありません。 しかし、メンテナンスをしやすい、他者が理解しやすいクラス設計を行うことは、チームの生産性向上にもつながり、効率的な製造を行うことが可能になります。 うまく抽象化を行って、変更に強いシステムを構築しましょう。

次の

基本設計とは?詳細設計とは?仕様書との違い、書き方、目次、成果物とサンプル (外部設計と内部設計)

基本設計書 テンプレート

はじめに 基本設計のことを「外部設計」と呼ぶ場合もあるが、当サイトでは「基本設計」に統一して記載している。 基本設計は、要件定義の結果を受けて、具体的なシステム構成や機能を設計する工程だ。 基本設計書には、下記の4つを検討のうえ成果物としてまとめる。 ・業務設計 ・システム方式設計 ・アプリケーション機能設計 ・非機能要件設計 要件定義書と同じく、企業によっては記載内容やテンプレートを整備している企業もあるので、まずは自社のルールを確認することをお勧めする。 基本設計書のサンプル 私が参考にした基本設計書のサンプルを紹介する。 上記の中でも、IPAの資料は、具体的な書き方や検討のコツも紹介されているので、特に参考になると思う。 基本設計書の目次(成果物一覧) それでは、ここからは基本設計書の書き方を説明していく。 プロジェクトの特性にもよるが、基本設計書には下記の内容を記載する。 基本設計書の目次 1. 業務設計 1-1. システム化の背景・目的 1-2. システム化の対象範囲 1-3. システム化業務一覧 1-4. 新業務フロー 1-5. システム化業務説明 2. システム方式設計 2-1. ハードウェア構成図 2-2. ソフトウェア構成図 2-3. ネットワーク構成図 2-4. アプリケーション機能構成図 3. アプリケーション機能設計 3-1. 画面設計 3-1-1. 画面一覧 3-1-2. 画面遷移図 3-1-3. 画面レイアウト 3-1-4. 画面入出力項目一覧 3-1-5. 画面アクション定義 3-2. 帳票設計 3-2-1. 帳票一覧 3-2-2. 帳票概要 3-2-3. 帳票レイアウト 3-2-4. 帳票出力項目一覧 3-2-5. 帳票編集定義 3-3. バッチ設計 3-3-1. バッチ処理フロー 3-3-2. バッチ処理一覧 3-3-3. バッチ処理定義 3-4. テーブル・ファイル設計 3-4-1. テーブル関連図 3-4-2. テーブル・ファイル一覧 3-4-3. テーブル定義 3-4-4. ファイル定義 3-4-5. CRUD図 3-5. 外部インターフェース設計 3-5-1. 外部システム関連図 3-5-2. 外部インターフェース一覧 3-5-3. 外部インターフェース項目定義 3-5-4. 外部インターフェース処理概要 4. 非機能要件設計 4-1. 性能設計 4-2. 信頼性設計 4-3. 拡張性設計 4-4. 情報セキュリティ設計 4-5. テスト方針 4-6. 移行方針 4-7. 運用保守設計 これらを簡単に説明していく。 業務設計 業務設計は下記5つの成果物を整理する。 アプリケーション機能設計 3-1. 画面設計 3-1-1. 画面一覧 3-1-2. 画面遷移図 3-1-3. 画面レイアウト 3-1-4. 画面入出力項目一覧 3-1-5. 画面アクション定義 3-2. 帳票設計 3-2-1. 帳票一覧 3-2-2. 帳票概要 3-2-3. 帳票レイアウト 3-2-4. 帳票出力項目一覧 3-2-5. 帳票編集定義 3-3. バッチ設計 3-3-1. バッチ処理フロー 3-3-2. バッチ処理一覧 3-3-3. バッチ処理定義 3-4. テーブル・ファイル設計 3-4-1. テーブル関連図 3-4-2. テーブル・ファイル一覧 3-4-3. テーブル定義 3-4-4. ファイル定義 3-4-5. CRUD図 3-5. 外部インターフェース設計 3-5-1. 外部システム関連図 3-5-2. 外部インターフェース一覧 3-5-3. 外部インターフェース項目定義 3-5-4. 外部インターフェース処理概要 基本設計のメインとなる作業だ。 要件定義のざっくりとした内容を元に、システムを実装できるレベルまで具体的に記載しよう。 画面一覧 ・規模の拡張性 利用者やデータの増加に伴うシステム拡張の対応策 ・機能の拡張 機能追加の対応策 セキュリティ設計 要件定義のセキュリティ要件に対して、対応方針を記載する。 ・情報(データ)や情報システムへのアクセスを制限するために、利用者IDの管理(パスワードの管理など)を行う。 ・重要な情報に対するアクセス権限の設定を行う。 ・インターネット接続に関わる不正アクセス対策(ファイアウォール機能、パケットフィルタリング、ISP サービス 等)を行う。 ・無線LANのセキュリティ対策(WPA2 の導入等)を行う ・ソフトウェアの選定や購入、情報システムの開発や保守に際して、情報セキュリティを前提とした管理を行う。 出典:,pp. 7-8 テスト方針 要件定義のテスト要件に対して、テスト方針を記載する。 単体テスト・結合テスト・総合テスト・運用テストといった各テスト工程について、プロジェクトの特性に応じて、下記のような観点を記載する。

次の