システム開発の流れ
要件定義から運用・保守までの工程を順にたどり、外部設計と内部設計の違いや、各工程で誰が主役になるかを説明できるようになります。
ねらい
システムができあがるまでの工程を学びます。このレッスンを終えると、工程の順序と各工程で決めることを説明でき、利用者から見える部分と見えない部分をどこで分けるのかが分かるようになります。
工程は、外から内へ進みます
システム開発は、利用者に近いところから決めて、だんだん機械に近いところへ降りていきます。
| 工程 | 決めること | 主役 |
|---|---|---|
| 要件定義 | 何ができるシステムにするか | 利用部門 |
| 外部設計 | 利用者から見える部分(画面・帳票・操作) | 利用部門と開発者 |
| 内部設計 | 利用者から見えない部分(内部の分担・処理手順) | 開発者 |
| プログラミング | 実際のプログラムを書く | 開発者 |
| テスト | 決めたとおり動くかを確かめる | 開発者と利用部門 |
| 運用・保守 | 動かし続け、直し続ける | 運用部門 |
ポイント
外部設計と内部設計の境目は「利用者に見えるかどうか」です。画面の並びやボタンの位置は外部設計、その裏でどう処理を分担するかは内部設計です。外部設計は利用者と一緒に決められますが、内部設計は開発者の領域です。
各工程の中身
要件定義では、何ができるシステムにするかを合意します。
外部設計(基本設計)では、利用者が触る部分を決めます。画面の見た目と並び、入力する項目、出力する帳票、他システムとのやり取りの形です。ここで決めたことは、利用者が確かめられます。だから利用部門が関わります。
内部設計(詳細設計)では、外部設計で決めた動きを、どう実現するかを決めます。処理をいくつの部品に分けるか、データをどう受け渡すか。利用者には見えないので、利用者に確認を求めても答えられません。
プログラミングでは、設計に沿ってプログラムを書きます。書いた本人が動作を確かめる単体テストまで含めて考えます。
テストでは、決めたとおりに動くかを確かめます。工程をさかのぼる形で、小さい単位から大きい単位へ確かめていきます。
運用・保守では、動かし続けます。システムの費用と手間の多くは、この段階にかかります。作って終わりではありません。
保守には理由が3種類あります
動き始めた後に手を入れる理由は、大きく3つです。
- 不具合を直す。見つかった誤りを修正します。
- 環境の変化に合わせる。法改正、消費税率の変更、OSの更新。
- 良くする。使いにくいところを改善し、性能を上げます。
「作り終えたら終わり」ではないことが、システムの費用を見積もるときの要点です。運用と保守にかかり続ける費用を含めて考える必要があります(TCO)。
まとめ
システム開発は、要件定義→外部設計→内部設計→プログラミング→テスト→運用・保守の順に、利用者に近いところから機械に近いところへ進みます。外部設計と内部設計の境目は、利用者から見えるかどうかです。保守は不具合の修正だけでなく、環境の変化への対応と改善も含みます。
理解の確認
システム開発の工程のうち、利用部門の担当者に内容を確認してもらうことが特に重要なのは外部設計と内部設計のどちらでしょうか。理由も述べてください。
答え: 外部設計です。外部設計では、画面の並び、入力する項目、出力する帳票といった利用者が実際に触る部分を決めます。これらは利用部門が日々の業務と照らして「この項目では足りない」「この順序では入力しにくい」と判断できる内容であり、確認してもらう意味があります。一方の内部設計は、処理をいくつの部品に分けるか、データをどう受け渡すかといった利用者には見えない実現方法を決める工程です。利用部門に見せても業務の観点から判断する材料がないため、開発者が責任を持って決めます。
分からなかった点・気になった点
読み込み中です。