システム開発の仕事の流れ

職種を説明する前に、その仕事の流れを説明しておきます。システム開発は大きく６つの段階に分かれます。
　
　　　１　基本計画
　　　２　外部設計（基本設計）
　　　３　内部設計（詳細設計）
　　　４　プログラム設計
　　　５　プログラミング
　　　６　テスト　（評価、検証）
　　［７　業務開始（オペレーション、メンテナンス）］

　これらの段階の最後にはレビューが行われます。　レビューとは、システム開発の担当者から顧客に開発に成果について説明をし、顧客から検証をしてもらった上で、これでOKという承認をもらうプロセスです。　このレビューが終わった時点で次の段階に進めるわけです。　システム開発は開発担当者と顧客との間の契約であるので、このレビューはおろそかにできません。　承諾した、しない、の不一致からトラブルになってしまうことがままあるからです。
　それでは、各段階についてもう少し詳しく説明していきましょう。

１　基本計画
　　基本計画の段階にくる前には、顧客の内部でシステムに対する要求が生じています。
　　　例えば、今までコンピュータシステムをまったく使っていなかったが、業務の合理化などのた
　　めに新たに導入したい、といったものから、今までシステムを使っていて、その性能を向上させ
　　たい、新しい機能を追加したい、業務に変更があったのでシステムもこれに対応させたい、
　　問題点が生じたのでこれを修復したい、といったものがあります。
　　　この顧客側の要求をうけて、システム担当者が現状システムの問題点などを調査し、
　　これから開発しようとするシステムの概略をまとめて、開発計画を立案・確定させるのが
　　基本計画です。
　　　この段階で、開発担当者は以下の３つのドキュメント（記録・書類）を作成し、顧客からの
　　レビューを受けます。
　　　①　要求仕様書　　　　　：　顧客からの要求をシステム開発の観点から取りまとめる。
　　　②　システム化計画書　：　上の要求をシステムに反映させたとき、既存のシステムに
　　　　　　　　　　　　　　　　　　　どのような修正が行われ、最終的な形がどうなるかを示します。
　　　③　開発計画書　　　　　：　システム化計画書をもとに、開発に要する人数・日数・
　　　　　　　　　　　　　　　　　　　予算などを計画としてまとめる。

２　外部設計　（　基本設計　）
　　外部設計では、基本計画での決定をもとに開発の大枠を確定させます。
　　大体、以下の手順を踏みます。
　　　①　システム全体をいつかのサブシステムに分割する。　　　（システム分割）
　　　②　システム内で使用するデータをコード化する。　　　　　　　（コード設計）
　　　③　コード化した各データの関係（計算式など）を定義する。　（論理データ設計）
　　　④　システム内で使用する画面・帳票（レポート）にどのデータを表示するのかを決める。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　（画面設計・帳票設計）
　　　⑤　以上により外部設計書（基本設計書）を作成する。
　　　⑥　レビュー

３　内部設計　（　詳細設計　）
　　内部設計では、外部設計書をもとに、さらに詳細な設計をします。
　　　①　サブシステム内の機能をプログラム単位に分割する。　（サブシステム分割）
　　　②　外部設計でコード化・定義したデータの、物理的定義を行う。物理的定義というのは、
　　　　　データのタイプ（文字・数値）と桁数（バイト数）を決定すること。システム内でのデータ
　　　　　の受け渡しはファイルの形で行われるので、ファイルの設計を行うことになる。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　（物理データ設計／ファイル設計）
　　　③　外部設計で作成した画面・帳票設計書をもとに、画面・帳票の詳細（レイアウト・入出力
　　　　　など）を設計する。　　　　　　　　　　　　　　　　　　　　　　　（入出力詳細設計）
　　　④　設計内容を内部設計書（詳細設計書）に文書化する。
　　　⑤　レビュー

４　プログラム設計
　　ここでは、内部設計で分割したサブシステム内のプログラム１本１本の設計書を作成します。
　　大体、以下のような手順になります。
　　　①　プログラムをモジュール（部品の意）と呼ばれる小プログラムに分割する。
　　　②　モジュール間のインターフェイス（データのやり取り）を決める。
　　　③　モジュール間の処理手順を決める。
　　　＊　プログラムが小さい場合は、①、②、③は省略して、プログラム内の処理手順だけを
　　　　　決定します。
　　　④　設計内容を文書化　（プログラム設計書）
　　　⑤　テストケース作成　（単体テスト計画書）
　　　　　　　モジュールをつないだ１本のプログラムとして、正しく動くかをテストする
　　　　　　　ための計画書をつくる。
　　　⑥　レビュー

５　プログラミング
　　内部設計書（詳細設計書）を元にプログラムを組み立てる段階です。
　　手順は次の通りになります。
　　　①　モジュールの論理を設計する。　　　　　　　　　　　（モジュール設計書）
　　　②　モジュールの論理を、プログラム言語にします。　（コーディング）
　　　③　モジュールごとのテストを行う。　
　　　④　プログラム設計で作成したテスト計画書のテストケースにもとづいて、ここで組み立てた
　　　　　プログラムが、モジュールをつないだ１本のプログラムとして、正しく動くかをテストする。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　（単体テスト）
　　　⑤　テスト結果を文書化する（単体テスト報告書）
　　　⑥　レビュー

　　＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

　　　　プログラム設計とプログラミングは厳密に区別されないことが多いようです。
　　　プログラム設計書とモジュール設計書を同意に書いてしまうことや、この２つをひと
　　　つにまとめてしまうことが多いのです。
　　　　さらに、慣れたプログラマの場合、内部（基本）設計書をもらったら、文書化をと
　　　ばして、頭の中で設計してしまって、いきなりコーディングに入ってしまうこともし
　　　ばしば見受けます。この場合ドキュメントは、あと付けで作成されます。こういう手
　　　順のひっくり返しは、システム開発のスケジュールが厳しくて、ドキュメントよりも
　　　プログラム本体の作成が最優先といった現場で現れます。

　　＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

６　テスト
　　単独で正常に動くことが確認された１本１本のプログラムが、他のプログラムやサブシステムと
　　連動させたときにも正常に動くかをテストで確認します。
　　テストのレベルによって、以下のテストが行われます。
　　　①　結合テスト　（　IT：インターフェイス・テスト　）
　　　　　　　　サブシステム内のプログラムをつなぎあわせて、サブシステムとして正常に作動する
　　　　　　　　ことを確認する。　テストケース・テスト結果を文書化（結合テスト計画書、結合テ
　　　　　　　　スト報告書）し、レビューを行う。
　　　②　システムテスト　（　ST　）
　　　　　　　　結合テストをパスしたサブシステムをつなぎ合わせて、システム全体が正しく作動す
　　　　　　　　ることをテストで確認する。　テストケース・テスト結果を文書化（システムテスト
　　　　　　　　計画書、システムテスト報告書）し、レビューを行う。
　　　③　運用テスト
　　　　　　　　実際の業務でシステムを動かすときと同じ環境でテストを行う。
　　　　　　　多くの場合、今までの旧システムと開発した新システムを並行して動かす。　
　　　　　　　　テストケースを作成し、結果を文書化する。
　　　　　　　（運用テスト計画書、運用テスト報告書・実績報告書）
　　　　　　　　レビュー

７　業　務
　　テストを通過すれば、いよいよ業務の上で新システムが単独で動き出します。
　　新システムのスタートをリリースといいます。
　　システム稼動となると以下のような仕事がともないます。
　　　　●　システムを実際に動かすオペレーション
　　　　●　システムにトラブルがないかを、定期的に点検するメンテナンス（保守）
　　　　●　ユーザーからのシステムに関する質問などに対応するシステムサポート

 

以上、システム開発の段階を大まかに説明しました。
　これを踏まえてシステムの職種について、次項で説明しましょう。
 

 

←前へもどる　　次へ進む→