システム開発の流れと見積り

要件が定まった後は、システム全体やソフトウェアの構造を設計します。大まかな構成や外部との関係を決めた後、プログラムを作れる程度まで具体化していきます。

設計内容に従ってプログラムを記述する作業がコーディングです。作成した個々のプログラムについて誤りを調べるのが単体テストで、内部構造を意識して確認するホワイトボックステストが用いられることがあります。

プログラム中の誤りを見つけ、原因を調べて修正する作業をデバッグといいます。コードレビューは人がソースコードを確認する活動であり、プログラムを実行するテストそのものとは限りません。

単体テストは個々のプログラムを確認する

単体テストを終えたプログラムを組み合わせ、プログラム同士が正しく連携するかを確認するのが統合テストです。その後、システム全体が要求された機能や性能を満たすかを確認します。

入力と出力の関係を中心に確認し、内部構造を前提としない方法をブラックボックステストといいます。大量の処理を与えて動作を確認する負荷テストや、処理時間などを調べる性能テストもあります。

修正によって以前動いていた部分に新しい不具合が生じていないかを調べるのが回帰テストです。テストは実施するだけでなく、計画した目標と結果を比べて評価することも含みます。

統合後は連携・機能・性能を段階的に確認

完成したシステムは、実際の利用環境またはそれに近い環境で、目的どおり使えるかを確認します。委託して開発した場合、発注側が行う受入れテストによって、要求を満たしていることを確認します。

導入では、データや業務を新しいシステムへ移す移行作業のほか、利用者への教育やマニュアルの準備も行います。受入れでは作った側ではなく、受け取る側の立場で利用目的を満たすかを確かめることがポイントです。

運用開始後も、不具合への対応や環境変化への対応、機能改善などが行われます。これらの活動が保守であり、安定運用だけでなく必要な変更や改善も対象になります。

受入れは利用者側、運用後の変更は保守

開発を始める前には、必要な工数や期間、費用を見積もります。過去の似たプロジェクトを参考にする方法が類推見積法で、詳細が固まっていない段階でも概算を出しやすい方法です。

ファンクションポイント法は、利用者から見た機能の種類や規模を基に開発規模を見積もります。プログラムの行数そのものではなく、入出力や照会などの機能に着目する点が特徴です。

作業を細かく分けて各作業の工数を見積もり、それを合計する考え方もあります。初期段階ほど情報が少ないため、細かな積み上げより類似案件などを使った概算が向く場合があります。

FP法は利用者から見た機能の規模で見積もる