システムの内部設計手順

学校で習ってたやつが出てきました。システム構築をするときに必要となる設計の手順的なやつです。

定義的なところは書籍を参考にし、それ以外の部分を自分の言葉で書きます。

内部設計とは

内部設計は「エンジニア視点から見た設計」です。顧客向けではありません。そのため、データの設計とかプログラムの詳細な機能とかを記述する必要が出てきます。様々な制約・条件を把握し、それに対応したシステムを設計します。

内部設計の工程

①外部設計書の確認

ユーザ目線で作られた「外部設計書」を元にどのような機能が要求されているのかを把握します。

エンジニア目線で内部設計に取り組むと、いきなり必要な機能や処理が爆増するのでかなり戸惑いますが、根気よくやってきましょう。

②機能分割・構造化

外部設計書で要求された機能を処理レベルで詳細に分割し、その処理間の関連性を明確化します。この工程をしっかりと行うことで、システムの運用・保守がしやすくなります。

怠ってしまうと引き継ぎが困難になるため、開発者を1つのシステムに長期間縛り付けることになります。

③物理データ設計

外部設計書で作られた「論理データ設計」にある、データ項目やファイルの仕様を元にして、実際のデータベースの構造を設計していきます。データへどうアクセスするのか、レコード・レイアウトをどうするのかなどです。

ここを失敗すると、主キーとか外部キーをプログラミング中に後付けすることになり、地獄を見ます。

④入出力詳細設計

外部設計で作られた画面プロトタイプなどを元に、データの入出力やエラー対処、メッセージのレイアウトなどをどのように表示するのか…詳細部分まで設計します。ハードウェア制約にも注意！

ここは攻撃の容易さに関わってきます。例えば、ログインフォームでパスワードエラーを起こした（IDはあってる）時に「パスワードが間違っています」などと表示してしまえば、「お、このIDは実在するんやな」と攻撃者に悟られてしまいます。「IDまたはパスワードが間違っています」とエラー対処するべきです。

⑤内部設計書の作成

上記のあれこれを内部設計書としてまとめます。これをもとにシステム構築を進めます。

でも昨今は「如何に早くデプロイするか」が重要になっていることもあり、厳密な内部設計書が求められるのは、金融業界や医療情報など「設計に欠陥があると人命に直結する」事業くらいなものかもしれません。

じっくりと検討したうえで1つのものを作るくらいなら、10回失敗して1つのものを完成させた方が良いです。なんとなく。

⑥デザインレビュー

Verification（外部設計との一貫性を”検証”）とValidation（要求を満たしているか”確認”）が大切。

無駄な手戻りが発生するのはここで甘さを見逃しているから。

上流工程の設計は想像以上に大変なのだと学びました。「頭脳労働は疲れなくていいよね…」とはもう言えそうにありません。ゴリゴリと精神力が削られていく。廃人に近付いていく。

参考書籍はこれです。

最新 図解でわかる データベースのすべて