システム開発の流れ｜基礎を学ぶ

システム開発は、いきなりプログラムを書き始めるわけではありません。何を作るかを決めてから、どう作るかを決め、そのあとで作り、最後に確かめます。この順番と、各工程で何ができあがるのかが試験の中心です。

開発工程の流れ

代表的な工程の並びは次のとおりです。上から順に進みます。

試験では工程の並べ替えがよく出ます。設計はプログラミングより前であり、要件定義は設計より前です。「プログラミングをしてから要件定義を行う」といった順序の入れ替えは、それだけで誤りと判断できます。

この2つの区別は、マネジメント系で最も狙われる論点のひとつです。区別の軸は誰から見た設計かです。

外部設計は、利用者から見える部分の設計です。画面のレイアウト、入力項目、帳票の様式、他システムとのやり取りの取り決めなどが該当します。利用者が内容を確認できる設計です。
内部設計は、作る側から見た内部構造の設計です。プログラムをどう分割するか、データをどう持つか、処理をどういう手順で書くかを決めます。利用者は通常この内容を見ません。

引っかけの典型は、「画面のレイアウトを決めるのは内部設計である」という言い換えです。画面は利用者に見えるので外部設計です。逆に「プログラムの内部構造の分割を利用者と合意する」という記述も誤りで、これは作る側の話です。利用者に見えるかどうかで機械的に振り分けてください。

共通フレームは、システムの企画から開発、運用、保守、廃棄までの作業内容と用語を共通化するために作られた指針です。発注する側と受注する側で「設計」という言葉の指す範囲がずれると、あとで大きなトラブルになります。それを防ぐために、作業の区切りと呼び名をそろえた辞書のようなものだと考えてください。

注意点として、共通フレームは作業の順番や進め方を強制するものではありません。開発モデルを決めるものだ、と書いてある選択肢は誤りです。あくまで用語と作業項目をそろえる共通の物差しです。

システムは作って終わりではなく、稼働後の保守が続きます。保守は目的で分類されます。

法改正や税率変更への対応は適応保守であり、是正保守ではありません。是正保守は「壊れていたものを直す」もので、環境が変わったから合わせるのは適応保守です。ここは言葉が似ているため、対応表で覚えるのが確実です。