【第12回】システム開発の流れを、家を建てる工程で理解する

それ、けっこう大きな誤解。プログラミングは工程の一部でしかないよ

家を建てるとき、いきなり工事から始める？

システムも同じ。設計図なしで作り始めたら、間取りが決まってないのに壁を建て始めるようなものだよ

システム開発の基本的な流れはこう。要件定義（何を作るか決める）→外部設計（利用者から見える部分の設計）→内部設計（システム内部の設計）→プログラミング（実際にコードを書く）→テスト→移行（本番環境への切り替え）

家づくりに例えると、要件定義は『どんな家に住みたいか』の要望整理。外部設計は間取り図——住む人から見える部屋の配置。内部設計は配線図や配管図みたいな、住む人からは見えないけど必要な設計

そう。それぞれの工程で決めることが違うから、順番を飛ばしたり戻ったりすると手戻りが大きくなる

この工程の流れを図にしたのがV字モデル。左側に要件定義→外部設計→内部設計→プログラミングと下っていって、右側にテスト工程を上っていく、V字型の図

大事なのは、左側の設計工程と、右側のテスト工程が対応していること。要件定義で決めたことは、最終的なシステムテストで確認する。外部設計で決めたことは、結合テストで確認する。内部設計で決めたことは、単体テストで確認する

そう。だから『どのテストが、どの設計を確認するためのものか』という対応関係が、試験でもよく問われる

あと、テストのやり方自体にも種類がある。ブラックボックステストは、内部の作りを気にせず『入力に対して正しい出力が返るか』だけを確認する方法。ホワイトボックステストは逆に、内部のロジックや処理の分岐を確認しながらテストする方法

そう。あと、コードを書く前の段階でも、レビューという確認作業がある。代表的なのがインスペクション（決まった役割の参加者が、公式な手順に沿って厳密に行うレビュー）とウォークスルー（作成者が主導して、比較的気軽に行うレビュー）

1つ目は、V字モデルの対応関係。『要件定義⇔システムテスト』『外部設計⇔結合テスト』『内部設計⇔単体テスト』、この組み合わせを問う問題が定番

そう。『中身を見ずに入出力だけ確認する』のがブラックボックス、『内部のロジックまで確認する』のがホワイトボックス、と対にして覚えるといい

うん。次は、この開発の"進め方"そのものの話。ウォーターフォールとアジャイル、聞いたことある？

……その理解、半分だけ合ってる