思ったことをデータに残しておかないともったいないので、走り書きで残す
基礎の基礎も含めて網羅したい
新しいことが書きたくなった時にこれを更新するか、新しくページを作るかは考える
目次#
- 試験行程に必要なもの
- 試験行程で行う実際環境とのマッチについて
- 設計について
- 他チーム、顧客に提示する必要があること
試験行程に必要なもの#
試験行程はテストシナリオがなければ正確に行えない
テストシナリオは正確な設計書がなければ作成できない
正確な設計書は正確な業務フロー、業務シーケンスがわからなければ作成できない
試験行程で行う実際環境との調和について#
顧客環境で動かす場合、それが一般に普及したブラウザ上で動くものでもない限り、先行検証を行うほうがベター
（ただし、ブラウザ上で動くものでも、性能要求を満たせているか確認する目的は達成できるため検証をする価値はある）
検証によって利用するアプリケーションやDLL、ライブラリ、ファイアウォールとの相性や実際の環境の性能においてパフォーマンスが出るか、確認できる
顧客人員の個人PCで動かすならそのPC（と可能ならばネットワーク）を借りて、
顧客の自社運用サーバーで動かすならできれば同様スペックのPCを借りて試す
設計について#
設計において、何かの要求について起こりうる業務フローをしっかりと検討する
検討した業務フローに対して必要な機能が定まる
- データ登録機能に対して、排他制御機能
- 個人PCインストール機能に対して、インストーラー機能、バックアップ/リストア機能
複数のパターンが考えられる場合は、資料上でわかりやすく示す必要がある
以下の図示方法の利用が考えられる
- デシジョンテーブル
- シーケンス図
- フロー図
他チーム、顧客に提示する必要があること#
他チームに連携する必要があるのは、まず他チームと連携して動作する必要がある事柄。
- 業務フローに対して、どのような方法(json,rpc,ファイルストリーム)でやり取りをするか
- やり取りの標準的な形式、（エラー、情報の）メッセージ情報のやり取りのkey、形式、内容
- 想定される文字種やデータ形式
他には、自身のアーキテクチャ設計の範囲内で製造業務を行うメンバーに対して、
- 開発を行うにあたり、用意しなければいけないアプリケーション、環境構成、変更が必要な設定