ごきげんよう、Zei(ゼイ)です。
個人開発をするにあたって、「個人開発ではありながらもしっかりとシステム開発のプロセスを踏んで形にしていこう」と以前の記事で決意しましたので、今回はシステム開発の工程と各工程の簡単な説明、開発手法をまとめました。
以前の決意した記事↓
システム開発はどんな工程が必要か、またどんな開発手法があるかを簡単にざっくり知りたい方におススメです。
システム開発の9つの工程
システム開発の工程は大きく9つの工程に分かれている
- 要求定義
- 要件定義
- 基本設計
- 詳細設計
- プログラミング
- 単体テスト
- 結合テスト
- 総合テスト
- 受入テスト
その後システムをリリースし、リリースした後は運用保守をしていく
要求定義
依頼者がシステム開発の目的やシステムに求めることを定義する工程。
- 要求定義書
実際にシステムを利用する依頼者側が業務を整理した上で「システムで何を実現したいのか？」を要求定義として作成する。
あくまでも「要望・希望」になるので、作成した要求定義書の中身すべてが機能やシステムとして実現するかはこの時点では不明。
開発者はこれをもとに要件定義を作成し開発を進めるので、設計の基礎や大枠となる部分になる。
要求をしっかりと整理し形にすることが求められる。
要件定義
システム開発者が依頼者と打ち合わせをして、要望を明らかにする工程。
- 要件定義書
- 受入テスト仕様書
- 総合テスト仕様書
搭載する機能や仕様、運用方法などの方向性を決め、すべての要件を記載する。
開発者は要求定義書を確認しながらしっかり「どんなシステムが必要か？」をヒアリングし、依頼者はしっかりと「こんなシステムが欲しい」と要望を伝え決めていく。
ここで食い違いが起こると、希望しているシステムと異なったものが出来上がり事故るので、双方のすり合わせをしっかり行う必要がある。
※受入テスト仕様書・総合テスト仕様書も作っておく。
※受入テスト
本番稼働直前のテスト工程の一番最後に行う確認テストのこと。
本番環境と同様(または本番環境そのもの)の環境で依頼者がテストするので、顧客側の視点で作成する。
※総合テスト
本番環境とほぼ同程度の環境を用いて、要件定義を満たしているかを確認するためのテスト。
開発側が実施する最終確認テスト。
基本設計
搭載すべき機能や特徴を具体的に設計する工程。
- 機能一覧
- テーブル定義
- システム構成図
- 画面レイアウト設計
- 帳票レイアウト設計
- ER図
- 結合テスト仕様書
依頼者向けに行われる設計になり、依頼者から見た時にどのような動作になるかを決める内容なので「外部設計」と呼ばれる場合もある。
文章だけで作成するのではなく、図を用いて視覚的に分かりやすくすることが重要。
また、開発に要する期間や費用について、依頼者とすり合わせを行う(らしい)。
※結合テスト仕様書も作っておく。
※結合テスト
複数のプログラムを組み合わせた際に、意図したとおりに動作するかを確認するテスト。
詳細設計
基本設計で定めた機能を、プログラムでどう実現するか具体的に設計する工程。
- 画面遷移図
- クラス図
- シーケンス図
- 状態遷移図
- データベース物理設計書
- 入手力設計書
- バッチ処理詳細定義
- プログラミングのルール
- 単体テスト仕様書
「プログラム設計」とも呼ばれる場合もある。
基本設計は依頼者向けだったが詳細設計はプログラマ向けになり、システムの内部構造・処理方法・データの流れなど、ユーザーからは見えない細部まで設計を行う。
この設計をもとに、実際にプログラミングを行うことになる。
※単体テスト仕様書も作っておく。
※単体テスト
個々のプログラム単体の各機能が、意図したとおりに動作するかを確認するテスト。
プログラミング
コンピュータへの指示を記述する工程。
プログラム
詳細設計まで進んだら、プログラミング言語を用いてコンピュータへの指示を記述する。
単体テスト
作成した個々のプログラムが詳細設計の仕様通り正しく動作するか確認する工程。
- 単体テスト成績書
- 単体テストに合格したプログラム
詳細設計の工程で作成した単体テスト仕様書をもとに実施。
不備が見つかり次第、プログラマーが修正を行う。
結合テスト
単体テストで動作確認したプログラム同士の接続やデータのやり取りが正しく機能するか確認する工程。
- 結合テスト成績書
- 実行プログラム
基本設計書で定めた機能が実現できているか確認する工程になる。
不備が見つかり次第、プログラマーが修正を行う。
総合テスト
開発側が行う最後のテスト、システム全体が要件定義の工程で定めた要件が実現しているか確認する工程。
- 総合テスト成績書
- システム
テスト環境も実環境に近いものを用意する。
リリースした後に問題が起きてはいけないので、システムが利用される中で起こりうる、ありとあらゆる状況や出来事を検証する必要がある。
受入テスト
一般的に最後に行われる、実際の運用環境でシステムが問題なく機能するかを確認するテスト工程。
- システム
依頼者が行うテスト。
システムが求めた要件を実現しているか、実際の利用環境で問題なく稼働するかなどを確認する重要な工程。
納品されたシステムが成果物として認められるかを見極めることが目的なので、受入テストを疎かにすると実際に利用開始した際に思わぬ不具合が起こる可能性があるのでしっかり確認する必要がある。
内容はほぼ同じになるが、必ず開発側の目線と依頼者側の目線の両方でテストを行う必要がある。
V字モデル
この9つの工程は、開発工程とテスト工程をリンクさせたモデル「V字モデル」ともいわれる。
1.要求定義ー9受入テスト.
2.要件定義ー8.運用テスト
3.基本設計ー7.結合テスト
4.詳細設計ー.6単体テスト
5.プログラミング
ウォーターフォール開発とアジャイル開発
開発手法は大きく2つ、「ウォーターフォール開発」と「アジャイル開発」があるそう。
※他にもあるらしいが今回はこの2つ
ウォーターフォール：「滝」という意味
上(上流工程)から下(下流工程)へ降りて(進めて)いき、上の工程に戻らない開発。
すごい大きなシステムで、作ったらそこまで大きな変更がない開発に向いている。
例）銀行のシステムなど
アジャイル：「機敏な」「素早い」という意味
部分的に導入する形の開発が可能。
規模が小さかったりニーズが変化する開発に向いている。
例）WEBコンテンツなど？
おわりに
今回はシステム開発の流れを勉強してきましたが、これをもとに個人開発を進めていきたいと思います。
実際に作りたいシステムの要求定義を作成し自分に対して要件定義をし、基本設計・詳細設計と、もろもろ行ってみたいと思います。
今回の自己開発の開発手法に関しては、どんどん機能が追加されていく感じになりそうなので「アジャイル開発」のイメージで進めていこうと思います。
※正直、「アジャイル開発」の具体例が見つからなかったので、どなたか教えていただけましたら幸いでございます。
自分の頭の中にあるフワフワとしたシステムを実際に形にするために頑張りたいと思います。
コメント