システム開発の工程は、ざっくり分けて下記の通りです。
- お悩み発生
- 設計書作成
- プログラム作成
- テスト
- 納品・運用
しかし設計書とひと括りにしても、要件定義書、基本設計書などの種類があります。
この記事では、詳細を含めた実際のシステム開発の流れを説明します。
プロジェクトによって名称や構造は多少異なりますが、今回紹介する工程は王道パターンなので覚えておくと約立ちます。
ITの基本については、よろしければ下記をご覧ください。
プロジェクトの発生
基本的にシステムは問題を解決する為に開発します。
例としては下記をあげます。
条件に合致するデータを100,000,000件から探したい。手作業だと多大な時間がかかる
→データ取得システムで効率化
・顧客情報を一元管理したい。紙だと紛失する
→顧客情報管理システムでデータの整理整頓
・遠くの人と顔を見ながら話したい
→ビデオ通話システムで通話できる
人間が手作業ですると面倒なモノなどをシステム化します。
他にも「〇〇があったらな」「〇〇があれば便利だよな」等、人のニーズに応えるモノ。
それが大半のシステムの役割です。
問題がある、それならシステムを作成して解決しよう。が大半のシステム開発、プロジェクトの始まりです。
プロジェクトとは
目的を達成するために、一時的に結成される組織・業務
工程のフレームワーク
システム工程にも多数の種類があります。
その工程の仕組みをまとめて『フレームワーク』と呼びます。
テンプレートのようにある程度の核部分が決まっており、システムの要です。
上から下へと進み、前行程には戻らない『ウォーターフォールモデル』。
システムの試作品を作成して、テストと改善を繰り返す『プロトタイピングモデル』。
開発とテストが対応した形を持つ『V字モデル』
など上記以外にも多数存在します。
今回は基本であり、王道の工程を全10種類ご紹介します。
関連人物について
ITプロジェクト、システムに関わる人物を『ステークホルダー』と呼びます。
ステークホルダーとは日本語で『利害関係者』です。
顧客・エンドユーザー
システムを購入・依頼する人を『顧客(クライアント)』といいます。
そして顧客の所有しているシステムを利用する人が『エンドユーザ』です。
2者の違いはシステムの権利を所持しているか、していないかです。
システム開発者
システムを売る・作成する側の人物です。
プロジェクトマネージャやプログラマーなどがいます。
1. 要件定義書
顧客の要望をまとめて、プロジェクトの要件を定義した資料です。
システム開発のプロジェクトにおいて目的、実装範囲、期間、内容の要件をまとめます。
それらの情報をステークホルダーが認識、合意するために作成します。
誰が・なぜ・何のために・いつ・どのようなシステムを開発するのかステークホルダーが知っておかないと、プロジェクト達成は困難ですよね。
全体の意識共有はプロジェクトの規模が大きくなるほど重要です。
そして後から言った・言ってない論争を避けるためにも大事です。
主な内容
・要件定義書の目的について
・プロジェクトの概要、目的、問題提起
・利害関係者の要件
・機能要件
・非機能要件
・システムの制約
・要件達成へのアプローチ
・リリース計画
機能要件
顧客が求める具体的な機能のこと
データ、システムの種類・構造など
非機能要件
機能要件以外の機能
処理速度、セキュリティなど
2. 基本設計書
要件定義書の内容を元に、システムの全体的な構造設計を記載した資料です。
要件定義書をより明確化、かつステークホルダーが理解できるように作成します。
主な内容
・システムの全体構造
・顧客とシステム開発目線、相互に理解するための設計書
・開発環境
・連携する他APIについて
・データフロー図
・処理フロー図
・ユースケース図
・セキュリティ設計
データフロー図
システムにおけるデータの流れを図で表したモノです。
別名は『DFD』といいます。
処理フロー図
プログラムの開始から終了までの処理を図で表したモノです。
プログラムの分岐や条件を図で記載します。
別名は『フローチャート』です。
ユースケース図
ユーザーの操作に対して、システムがどう反応するかを図で表したモノです。
ユーザ – 処理 – システム といった形で描かれます。
3. 詳細設計書
基本設計書を元にして、システム開発者側の具体的な設計を記載する資料です。
クラスや変数・実装するメソッドなどを設計します。
システム開発者達がシステム構成を理解するための資料です。
DB設計やセキュリティ設計など、プログラミングするための前提環境の内容も記載します。
主な内容
・クラス図
・シーケンス図
・DB設計
・データ構造
・エラーの処理対応
・プログラミングの詳細
・サーバーなどの性能調整
クラス図
クラスが持つ『役割』、『属性』、『変数』、『メソッド』、『他クラスとの関係性』を記載した図です。
シーケンス図
システムの処理や使用などの流れを記載した図です。
メソッドが呼ばれたとき、データがどのように動くかを簡潔に記載します。
4. 外部設計
画面設計・画面遷移など、ユーザが操作・閲覧するUIを作成するための設計です。
画面にIDを振って一覧化したり、『画面の○○ボタンを押下したら△△が起きる』など、画面のアクションを記載します。
主な内容
・インターフェイスのデザイン
・ボタンやリストなどの部品設定
・画面遷移
・画面レイアウト
・役割に沿った画面の設計
5. 内部設計
詳細設計を元に作成する、プログラミングなどのシステム開発者向けの設計書です。
内部設計と同時進行で作成する場合もあります。
主な内容
・プログラミングの具体的な設計
・デフォルト値の定義
・データ構造
・エラー時の処理
6. コーディング
プロジェクト達成のためのプログラムのコードを書く作業です。
内容は内部設計に依存します。
プログラミング言語と呼ばれるJavaやPython、Rubyなどを使用して、コーディングします。
主な内容
・クラス作成
・メソッド作成
・変数作成
・コードの記載
・コメント記述
7. 単体テスト
コーディングで作成したプログラムを最小単位でテストします。
こちらでいう最小単位とは『ユニット』と呼ばれます。
ユニットとは『関数』、『メソッド』です。
関数やメソッドとは、プログラムの一連の処理です。
例として、Random関数を使用するとランダムな値を取得するなど様々な関数・メソッドが存在します。
主な内容
・メソッド単体のテスト
・関数単体のテスト
8. 結合テスト
ユニットやモジュールなどを複数組み合わせて行うテストです。
『モジュール』とはユニットである関数やメソッドを組み合わせたモノです。
いわばシステムの『部品』です。
主な内容
・モジュールやユニットなど、多数のユニットを使用するテスト
9. 総合テスト
システム全体を対象とした大規模なテストです。
全てのモジュールが設計書通りに機能するかを検証します。
主な内容
・全システムの機能テスト
・全てのモジュールが設計書通りに機能するかを検証
・機能要件、非機能要件のテスト
・場合により、サーバーや端末の負荷テストを行う
10. 運用・保守
運用とは要件定義書を満たす構造のシステムを実際に稼働させ続けることです。
保守とはシステムを安定した状態で稼働する、修正などの変更管理の行為です。
修正の他にも、改良や拡張も含まれています。
サーバーやインターネットに接続しない、端末のみで完結するソフトウェアも存在します。
そちらの場合は運用・保守がほぼ不必要です。
主な内容
・システムのメンテナンス
・サーバーやシステムの管理
・エラーや障害の対応
・システムの監視
・ログ管理
最後に
システム開発の工程は上記で構成されています。
設計書をすっとばしてコーディングから入れ! という無茶なことを言われたら抗議しましょう。
設計書はシステム開発を当初の目的通り進めたり、相手との言った言わないを確実にするためにもあります。
全体を設計することで進捗が分かりやすくなるので、システム開発を行うなら個人でも作成をお勧めします。
コメント