システム開発の工程
要点と定義
システム開発は、企画、要件定義、開発、運用、保守という流れで捉えられます。各工程の目的を手掛かりに、作業がどこに当たるかを判断します。
要件定義では必要な機能や性能を明確にし、設計では実現方法を定めます。システム方式設計では、ハードウェア、ソフトウェア、手作業のどれで実現するかを分けます。
ユースケースは、利用者がシステムを使う場面をもとに、利用者とシステムのやり取りを記述する方法です。
プログラミングでは設計に沿って作成し、個々のプログラムを単体テストします。複数のプログラムをつなぐ確認が結合テスト、システム全体が要件を満たすか確認するのがシステムテストです。
受入れでは利用者側が、意図した用途や要求事項に照らして使用可能かを確認します。
品質管理はテストだけでなく、要件定義、設計、プログラミングを含む各工程で行います。 プログラムの品質をみる材料には、発見されたバグの数があります。
適用条件と例
例えば、利用者が「月末の集計を短時間で終えたい」と伝えたら、要件定義で必要な機能や性能を明確にします。方式設計では、集計をソフトウェアで行うか、手作業を含めるかなどの分担を決めます。
テストの対象を小さい順にたどると判断しやすくなります。個々のプログラムなら単体、プログラム間の連携なら結合、システム全体の性能要件ならシステムテストです。利用者が実際の業務で要件を満たすかを確かめる段階とは区別します。
本番環境へ導入するときは、実施者や責任者などの体制を明確にし、手順を計画して結果を関係者に伝えます。 導入後、利用者側が要求事項を確かめて受入れ可否を判断するのが受入れテストです。
見積りでは方法の基準を区別します。ファンクションポイント法は、入力画面や出力帳票など利用者から見た機能をもとに規模を見積もります。 例えば、画面や帳票が増えれば、機能規模の見積りにも影響し得ます。
保守は稼働後の修正、変更、改善です。本番運用中の障害対応や、環境変化に合わせた修正が例です。開発中のテストで見つけた不具合の修正とは、作業時点が異なります。
この節の続き
- 誤りやすい点
ここまでが冒頭部分です。ログインすると、無料でも1日2節まで全文をお読みいただけます。
アプリでこの節を読む