システム開発現場で作成していたドキュメント
私が実際に経験した開発現場で作成していた設計書などのドキュメントをまとめました。第1弾です。
Contents
はじめに
ネットを探してみると、プログラム言語の解説の記事は多いですが、設計書に関する記事ってあまりないと思いませんか？
私が経験したプロジェクトとそこで作成していた設計書などの各種ドキュメントを、プロジェクト単位で複数回に分けて紹介したいと思います。
今回は新卒で入って初めて経験したフューチャーフォン向けのアプリ開発についてまとめます。
共通
どのフェーズ向けにもWBSは作成されていました。
遅延状況を可視化するのにはやはりWBSが必要で、どのプロジェクトでも採用すべきですね。
さすがにどんなプロジェクトでも採用されていると思いますが。
要件定義
Wordで作成された要件定義書はありましたが、正直うろ覚えで割愛します。
基本設計
基本設計書
私が作成したわけではないですが、該当機能の機能などを日本語で書いた基本設計書はありました。
ベースとなるものでリーダーの方が作成されていたと思います。
UML図
基本設計フェーズでは、開発言語がC++だったこともあり、オブジェクト指向言語向けのUMLを使用しました。
UML図全部作成したか？というとNOで、具体的にはクラス図とシーケンス図のみ作成義務がありました。
新規機能だったため、別機能の参考書とUMLの参考書にらめっこしながら作成した記憶があります。
内容としてはザックリとしたクラスの構成、処理の流れを論理名（日本語）で書いたもので、結局製造フェーズで考慮漏れがあり、製造→設計書直すといったエンジニアあるあるの状況でした。
ツールはMicrosoft Visioという専用のツールを利用していました。
インターフェース仕様書
担当アプリは、フューチャーフォン内部の機能を利用するもので、該当機能と連携するためのインターフェース仕様書も作成しました。
担当アプリが該当機能に渡すパラメータ、受け取るパラメータ、形式などを記載したものです。
やはり別部署とやるのでスムーズにいかず、難航した記憶があります。
ツールはMicrosoft Excelを利用していました。
詳細設計
UML図
基本設計同様、クラス図とシーケンス図のみ作成しました。
基本設計ベースでクラスやメソッドの物理名を記載します。
UML図以外にもあった気がしますがうろ覚えなので割愛します。
単体テスト
単体テスト仕様書もどき
通常の開発であれば単体テスト項目書を作成し、処理の網羅するための条件をメソッド単位で項目としてピックアップして記載すると思いますが、このプロジェクトは違いました。
ソースコードを張り付けるだけというものでした。。
単体テスト手法が、IDEでステップ実行して各分岐をチェックするというもので漏れはないと思いますが、証跡も何も取らなかったのでこれで良いのかという疑問はありましたね。
結合テスト
結合テスト項目書
アプリを大項目、中項目、小項目とカテゴリ化し、各カテゴリを観点として項目をピックアップするというやり方でした。
こちらは割と妥当なやり方だったと思います。
総合テスト
総合テスト項目書
別の機能との連携を観点に同様に大項目、中項目、小項目とカテゴリ化し、各カテゴリを観点として項目をピックアップするというやり方でした。
また、総合テストということでパフォーマンス観点でも項目をピックアップしましたね。
納品
納品物一覧表＋過去のドキュメントのフルチェック
受託開発だったこともあり、開発終了に際して納品物の提出が必要でした。開発の中で作成したドキュメントを再度フルチェックし、納品物一覧表とあわせて納品という形でした。
納品物ということで、各Word、Excelのヘッダー、フッターや表紙、改訂履歴の誤字脱字までフルチェックが必要で（なぜか新人のみ・・）、1週間近く毎日終電間際まで納品物チェックしていた気がします。
さいごに
以上、簡単ですが実際のプロジェクトで作成したドキュメントを紹介しました。
次回は次にアサインされた開発現場で作成したドキュメントをまとめたいと思います。皆無だった気がしますが・・