記事について
今回は例として、お客さんとか上司とかから要望を聞いて、既存のWebアプリケーションの画面を改修していく作業を行う場合を想定しています。取り扱う範囲は詳細設計-実装-単体テストとします。
普段の仕事のやり方の備忘録として記載しますが色々と抜け漏れがあるので、加筆していく予定です。
大まかな順序
1.要望の聞き取り
2.調査
2.1画面概要調査
3.詳細設計
3.1詳細設計見積もり
3.2詳細設計
4.実装
4.1実装見積もり
4.2実装整理
4.3実装
4.4実装漏れ確認
4.5動作確認
5.単体テスト
5.1単体テスト仕様書作成
5.2単体テスト実施時間見積もり
5.3単体テスト
1.要望の聞き取り
改修内容の背景や目的、概要などを整理して、聞き取った内容をメモにまとめます。
2.調査
2.1画面概要調査
大体以下のものにまとめてます。
設計書に書かれていない場合は設計者や実装者にヒアリングです。
<使用目的・機能概要>
<機能詳細>
<使用シーン 業務フロー>
<用語>
<インターフェイス>
<使用テーブル CRUD>
<特記すべき仕様>
3.詳細設計
3.1詳細設計見積もり
要件の内容から、設計書の修正場所のあたりをつけ、調査すべき事と、単純作業でできる物を洗い出し、所要時間を計算します。
3.2詳細設計
詳細設計書を修正していきます。
4.実装
4.1実装見積もり
前回、掛かった作業時間や詳細設計書の修正箇所の個数から実装にかかる時間、実装で出るであろうバグの個数と解決にかかる時間を参考にし、計算します。
4.1実装整理
画面がまずどう動くか、及びメソッドの呼び出し順序の整理を行います。
次にソースにコメントをつけていき、修正箇所を絞りこんでいきます。
修正箇所を特定出来たら、詳細設計書を参考にして、日本語で処理を追記していきます。
もしも関連ソースに参考となる処理が無かった場合、他の画面の動きを見て、参考となるソースを探します。
4.2実装
4.1で書いた日本語で書いた処理を基にソースに処理を追加していきます。
4.3実装漏れ確認
実装に漏れが無いかを確認するために詳細設計書と要望を再度確認します。
また、コピペ漏れが無いかをgrepを使い、調査を行います。
4.4動作確認
要望でまとめた機能、詳細設計書に記載した処理が正しく動いているかを確認します。
5.単体テスト
5.1単体テスト仕様書作成
画面のイベントごとにテストケースを書いていきます。
主にマトリクスで組み合わせを網羅したり、境界値を意識したケースを心掛けます。
また、次回の単体テストのためにテストケースごとに作業の予定時間と実績時間を記載します。
5.2単体テスト実施時間見積もり
5.1で単体テストのテストケースが出そろうので、テストケースの作業予定時間を合計します。
また、単体テストで出るであろうバグの個数と解決にかかった時間を参考にします。
やはりここでも前回の単体テストでかかった時間が作業の見積もりをするのに重要になります。
5.3単体テスト
単体テストを実施していきますが、単体テスト仕様書の期待値があいまいだと何が正解が判断に困るので、
出来るだけ明確に書くことが必要になります。
作業は前工程で決まるといっても過言ではないと思います。
最後に
詳細設計、実装、単体テストの各フェーズごとに予定と実績を記録することは欠かせない作業です。
後で記録を参考にして、見積もりを作ろうと思っても物がないと参考には出来ないです・・・。