アーキテクチャドキュメントに何を書くか

開発プロセス

アーキテクチャドキュメントに書くべき内容について考える


めざすものは、
結構ベタでもいいから、読み手が知りたい箇所にすぐにアクセスでき利用できること。

読み手の興味は？

  • 調達者
    • 必要なシステム特性を満たしているか
    • ほしいもの
  • 運用部門
    • 運用しやすいか
    • 障害発生時に切り分けに必要な情報を、どのような手段で得られるか
  • 保守を行う開発部門
    • アーキテクチャの意図を正しく把握でき、保守時に不具合を埋め込みにくいこと
    • 開発方法、

書くべきと考える内容

方針

基本は、読み手の知りたいことに答える内容。

  • 要求にアーキテクチャ面からどう答えたか
  • 保守時に気をつけなくてはいけない点は何か

というあたりか。

具体例

具体的な内容を思いつく侭に列挙する

  • プロダクトに対する要求
    • 機能
      • 電話自動受付したい
      • 受注したらメール送りたい
    • 非機能
      • 365D×24H稼働
      • バッチを2時間以内で終わらせる
      • 電話しながら使うので、レスポンス重視
      • 大量入力があるので、操作性重視
      • 拡張性重視のため、コンポーネントの組み合わせが
      • 短納期のため、とにかく生産性（FP生産性）が高い（テストしやすさも）
  • アーキテクチャを選定した経緯、基準（新しいツールがでれば、基準は変わるかもしれない）
    • いくつかのアーキテクチャを比較した場合は、決定に至った経緯
      • 比較した項目
        • 要求にどの程度適合するか
        • 枯れているか（枯れていることを要求されないシステムもあると思うが）
        • 技術者の調達が可能か
        • 価格
        • サポート

今後のすすめかた

列挙しただけで、構成もめちゃくちゃなので、少し整理していきたい。
また、大きく欠けている観点があれば、追加していきたい。