教育系パッケージソフトの導入 -詳細設計・開発・単体テスト-

詳細設計・開発・単体テスト

教育系パッケージソフトの導入は詳細設計・開発・単体テストに入りました。

これらの工程は基本的には同一人物が行うべきだと考えていますので、纏めてしまいました。また、場合によっては、基本設計と詳細設計の間に機能設計と言うフェイズを挟むことがあります。

 

詳細設計では、基本設計にて落とし込んだ要件をプログラム処理レベルに落とし込みます。イメージとしては、詳細設計書を読み全く同じ通りに作ったものがプログラムになるという感じです。

このフェイズの手間は、基本設計書がどれだけしっかりしているかに左右されます。
というのも、プロジェクトの方針や設計者のマメさにもよりますが、基本設計書がざっくりしており、それなりに行間を読み取らなければいけない場合があります。反対に、基本設計書が細かく書かれていると、ほとんど丸写しした上でプログラム開発に入れてしまいます。

 

個人的には、詳細設計とコーディングは今後海外にシフトしていくと考えているため、その直前の基本設計書は読み違えることのないレベルまで仕上げておくことが理想化と思います。基本設計が手抜きだと、成果物をレビューした際にとんでもないものが出来上がっており、検収不可能な状態になることも考えられます。

 

今回のプロジェクトでは、基本設計を細かく行っていたため、設計書自体はあっさり終了しました。続いての開発作業もバッチ系なのでこれまたあっさり終了しました。

…ところが、問題は単体テストにて発覚しました。

 

単体テストでは、実際に連系する予定のデータをテストデータとして利用したのですが、ここで想定していない書式のデータが混在していたため、意図通りに変換がなされなかったり、想定外の動きをしてアベンドするなど、データの中身に起因する問題が多発しました。

内容を見てみると、クレンジングで何とかなるレベルではなかったため、結局プログラム側にて色々と処理をするよう改修するはめになりました。ここでも手戻りがかなり大きく、

 基本設計書の修正⇒レビュー⇒詳細設計書の修正⇒レビュー⇒開発

という手順を再度繰り返すこととなりました。

品質に厳しい会社だったため、手を抜くわけにはいかず、かなり必死になりながら作業を続けました。残業で吸収したので、工程上は遅れがないように見えますが、終電近くまで残る日々が続き、あまりに悲壮すぎたので原因不明の病気を患うなど精神的なダメージはかなり大きかったです。

 

テストでは、境界値・型チェック以外にもC0・C1メジャーの網羅がポイントとなります。

プロジェクトの予算にもよりますが、C1メジャーは100%、C0メジャーも80、90%などできるだけ高い値となることを目標にすると良いでしょう。どこまでテストするかはプロジェクト内でPMが決めることが多いため、指示に従って淡々と進めるのが良いでしょう。概して地味な作業です。

転職サイト・エージェントの選び方を徹底検証!

転職サイト ランキング

管理人が実際の転職を通じて学んだ転職サイトの選び方とおすすめのエージェントを紹介しています。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です