Myログ

自分のためのブログ。

プロジェクトの文書化ルールのドラフト

管理

ルール策定の目的

ドキュメントの置き場や記述を統一し、必要な情報をすぐ見つけられるようにしたい
ドキュメントが常に最新にメンテされるようしたい
変更が発生した時の影響を把握したい
タスクの漏れをなくすようシステムを俯瞰できる情報がほしい。一覧系資料など。
情報を一元管理したい

ドキュメント構成

00_チーム運営
- 品質管理
  - テスト基準
  - 機能要件/非機能要件
  - レビューチェックリスト
    - マトリクスの更新
    - 一覧系資料の更新
- 標準化
- インボックス
- 変更管理
- 構成管理
- リリース管理
10_システム
- ドキュメント構成
- ドキュメント一覧
- システム全体図
- システム一覧
- システム概要図
- 機能一覧
- モジュール一覧
- システム構成
  - 開発環境, 検証環境, 本番環境
    - フォルダ構成
    - OS/ミドルウェア/ライブラリ
    - モジュール
- IF一覧
- DBオブジェクト一覧
- ジョブフロー
- ジョブ一覧
- 画面一覧
- 画面遷移図
- 監視一覧
- 運用一覧
- メッセージ一覧
- サービス/プロセス一覧
- 共通設計
  - アーキテクチャ
  - フレームワーク
  - 処理方式

20_案件
- 案件一覧
- PJ0001_○○対応
  - ドキュメント一覧
  - 00_管理
    - 課題管理表
  - 10_プロジェクト企画
    - 調査/見積
    - プロジェクト企画書
  - 20_要件定義
    - 要件一覧
  - 30_基本設計
    - 要件×機能
    - 要件×画面
  - 40_詳細設計
  - 50_実装/単体テスト
    - レビュー記録一覧
    - レビュー記録表
    - 単体テスト不具合管理表
  - 60_結合テスト
    - 結合テスト計画書
    - 結合テスト仕様書
    - 結合テスト証跡
    - 結合テスト不具合管理表
  - 70_総合テスト
    - 総合テスト計画書
    - 総合テスト仕様書
    - 総合テスト証跡
    - 総合テスト不具合管理表
  - 80_受入テスト
- 80_中止
- 90_完了
90_個人フォルダ
- Aさん
- Bさん

ドキュメントの記述ルール

変更履歴を書く [チケット番号]...
変更箇所がわかるように設計書に記述する ※削除箇所は取消線、グレーアウト+コメントなど
どの部分については最新なのかがわかるように変更履歴に記入する。すべて最新化したらすべて最新と書く
内容に関わらない表記の問題は、上記のルールを適用しなくてもよい。