開発フェーズのいろは その2

前回は要件定義、基本設計とういう上流工程について説明しました。
今回は後続の詳細設計、実装・単体テストについてお話ししてみたいと思います。
実装については言語毎に詳細な作業が変わってくると思いますので、概略にレベルの説明になるかと思います。
ただ、プロジェクト全体から見たときの役割はしっかりお伝えできるようにしたいと思います。

詳細設計

詳細設計とは？

詳細設計とは基本設計で実施した『どんな風に作るか』をさらにブレイクダウンする作業です。
機能単位に記載される基本設計を構成される実装単位に分解しそれぞれがどのような処理を行うかを明確にしていく作業となります。
目的は実装する人がこれだけ見れば実装出来るのが理想です。
昔のシステムでは1プログラム1機能だったのですが、現在はWebシステムが主流となりさらにフロントとバックエンド(サーバーサイド)にプログラムを分けてデータをやりとりする形が主流となりました。
そのためフロントとバックエンドでどのようなデータをどのようにやりとりするかも分かるように記載しましょう。

具体的な成果物は？

詳細設計で作成する成果物は主に以下のようなものになります。
・画面はどのような構成になっているか(画面遷移図)
・イベント毎にどんな処理をするか(アクティビティ図)
・フロントとバックエンドはどんなやりとりをするか(シーケンス図)
・データをどのように扱うか(SQL定義など)
・バッチ処理で何をどう処理するか(バッチ処理詳細定義書)
つまり目に見える部分(画面まわり、フロント)と見えない部分(バックエンド、データアクセス、バッチ)を明確にする資料が必要になります。

作業のポイント

詳細設計と実装は言葉で書くかプログラミング言語で書くかの違いで似たようなことをしているという理由からか「実装終わってから後付けで詳細設計やるよ」って人をまま見かけますが非常に悪手です。
詳細設計は言葉で考えられる最後のチャンスです。
実装というのは動かして見た結果からのフィードバックであり人間の構成力をベースにしていません。
なのでどんな物をどう作るのか、詳細設計で必死に考える事がとても重要になります。
作ってみたらダメだったからやり直して、と横展開で100人に言ったら1日掛かったとしても100人月であることを忘れてはいけません。
規模が小さいから、というのは言い訳にならず、なぜ詳細設計を先にやった方が効率が悪い状態になっているか、という問題に真面目に取り組む必要があります。

実装・単体テスト

実装・単体テストとは？

実装・単体テストのフェーズではついにプログラムを書く事になります。
ここまで長かったですねｗ
プログラム作るのをシステムエンジニアのお仕事、と思っている人も多いかと思いますが、逆に言うとこれだけ色々あるフェーズの中の一つの作業というのがおわかり頂けるかと思います。
単体テストは作ったプログラムが正しく動くかを確認するフェーズになります。
ツールを使ってテストする場合もあれば、手作業でデータ作って一つ一つオペレーション(実際に操作)する場合もあります。
個人的には昔から面倒で嫌いなフェーズでしたｗ

具体的な成果物は？

実装の成果物としては
・プログラミングした結果(ソースのcommit、オブジェクトなど)
になります。これも言語やソース管理方法によって違うので難しいです。
単体テストの成果物としては
・どんなテストを実施したか(単体テスト仕様書)
・結果はどうだったか(単体テスト結果、エビデンス、テストツール結果)
になります。

作業のポイント

実装に関して言うと標準化に則ってルール通りに記載することが非常に大切です。
コーディングのルール、共通化・共通処理利用のルールなど守るべきルールはたくさんあり、それを守ることで保守性の高いわかり安いソースになるので気を付けましょう。
単体テストで大切なのはエビデンスを正しく取る、に尽きます。
当たり前の事に聞こえますが、意外と守らない人が多いんですよねｗ
正しく動かし正しく結果を整理する点を心掛けましょう。

おわりに

詳細設計、実装のフェーズというのは通常エンジニアが最初にチャレンジするフェーズになります。
だからかこれだけがシステムエンジニアの仕事と誤解されている節もありますが、実はここは最初の一歩、ここでしっかり実力を養い次のフェーズに進んでいく事が重要です。
ここで受け取り基本設計書はどのような書き方がわかり安いのか、どんなことを言ってくれれば実装しやすいのかなど先輩エンジニアとして後進の指導する際はこの立場での経験を活かして貰えると嬉しいです。