システムに携わる仕事も様々ありますが、システムエンジニアと聞いて1番イメージされる仕事がシステム開発かと思います
世の中のシステムはどうやって作られているのか、または改善されていっているのか、そんなシステム開発の流れを解説していきます
- SEを目指している
- SEの仕事内容を具体的に知りたい
- システム開発に携わって間もない
要件定義
要件定義とは
「システムを導入したい」
「システムを修正したい」
などのクライアントからの要望をまとめ、どういった内容で開発を行なっていくのかを決める工程となります
この工程では打ち合わせや調査がメインの作業となり、担当するエンジニアはそれなりの経験、知識が必要となります
最終的にはシステム開発の方針、クライアントの要望、予算、スケジュールなどをとりまとめた文書を作成し、クライアントの了承を得る事で要件定義工程は完了となります
設計
要件定義で取りまとめた内容をシステムで実現する為に設計書の作成、修正を行なっていきます
設計書は担当するシステム毎にフォーマットや記載範囲も異なってきますが、外部設計書、内部設計書等に細分化して存在しています
外部設計
要件定義書をもとにシステムを利用するユーザーが直接触れる部分について、文書に取りまとめていきます
外部設計書の記述方法などは各作業現場、システム毎に異なっている事が多いですが、一般的には下記のような文書を作成していきます
- インターフェース
- 画面のレイアウト
- 各処理の概要
- データベースの設定、レイアウト
作成が完了した文書はユーザーに確認をしてもらう必要があり、場合によっては説明をする為の資料を別に作成する事もあります
内部設計
外部設計で決めた仕様を実現する為、ユーザーから見えない部分を文書に取りまとめていきます
この工程の後にプログラミングや画面の作成をしたりするので、その際に困らないように細かい仕様を決めていきます
- プログラムの細かい動き
- データベースの具体的な設定値
- 他システムとのファイル送信、受信の設定方法
内部設計については開発者寄りの文書となる為、ユーザーへの直接的な説明は無い場合が多いです
製造
設計で決めた内容を実現する画面、プログラム、ツール等の作成または修正をしていきます
OSの設定、ミドルウェア系(DB等)の設定に変更がある場合、自動的に設定を変更するツールの作成を行うこともあります
後の工程で不具合が発生した場合、プログラムの修正等が発生しますが、基本的にはコードを書くのはこの工程で全て行います
一般的なイメージではプログラミングなどをひたすらやっていると思われがちですが、各工程別の期間でみると短い事が多いです
テスト
システム開発の工程の中でテストの期間が1番長くスケジュールされている事が多いです
テストは不具合(バグ)の検知を目的としており、開発規模にもよりますが全く不具合が出ないという場合は逆に評価されない場合があります
開発規模が小さい
- バグが少ない場合・・・製造、テストの内容が妥当
- バグが多かった場合・・・設計、製造での考慮漏れ、スキル不足
開発規模が大きい
- バグが少ない場合・・・テスト内容に問題がある場合あり
- バグがそれなりの数発生・・・適正なテストが行われている
テストの中でも観点別に工程を細分化しており、それぞれの工程別にどんなテストを実施するのかを解説していきます
- 単体テスト：プログラムの最小単位に不具合が無い事を確認
- 結合テスト：引出し、振込み、残高照会など機能毎に動作を確認
- システムテスト：実際に使用する流れで機能、耐久性に問題がない事を確認
- ユーザ受け入れテスト：ATMをクライアント動作してもらい、要件を満たしている事を確認
単体テスト
製造で作成、修正したプログラムをデバッガーなどを使用してステップ単位(プログラムの最小単位)で処理を確認していきます
ステップ単位で全ての分岐、ループ処理回数などを確認し、コーディングにミスが無い事を確認していきます
また、期待さていない値を入力し、エラーハンドリング(エラー時の処理)が想定通りされていることもここで確認していきます
結合テスト
システムは複数のプログラムが集まって動作をしていますが、結合テストではプログラム同士を結合させた際の動作が想定通りの動きをするか、確認していきます
単体テストで検証した機能以外にもそこに関わる機能、画面があれば併せて無影響確認を行っていきますので、修正内容が少ない場合でも主要な部分を修正している場合はテスト工数が高くなる場合があります
- 新規項目の動作確認
- 修正対象の画面の基本的な機能が損なわれていないか確認
- 修正対象の画面から別の画面に遷移する機能の確認（別画面の簡単な機能確認）
- 新規項目を格納する為、DBにも値を追加している場合、対象のテーブルを使用している機能の動作確認
システムテスト
実際に使用する環境に近い状況でシステムを動作させ、要件に沿った動きをする事、修正外の機能に影響が無い事などを確認していきます
また、他のシステムや企業を超えてテストを行う事もあるため、テスト内容は担当するシステム、修正内容によって異なってきます
システムテストは開発規模が小さい修正内容の場合は実施しない事もありますが、新規システムの開発や大規模なシステム改修の場合は必須となり、テストに関わる人数も増えてくるので、スケジュール調整等を数か月前から行う必要があります
ユーザ受け入れテスト
開発者側でのテストで問題無い事を確認後、最終段階としてシステムを利用するユーザに本来の使用用途に基づいてテストを行ってもらいます
開発側での作業としてはテスト環境の準備とテスト実施の際にユーザから問い合わせがあった場合の対応を行なっていきますので、結合テストやシステムテスト程の工数がかからない事が多いです（テストする際に立ち合いを求められる場合もあります）
リリース作業
全てのテストが完了後、実際にシステムの稼働または更新を行います（リリース作業日以降の事をカットオーバーとも言います）
リリース作業は新規導入、更新等で作業内容が変わってきますが、準備として作業手順書を作成し、手順に沿って作業を行っていきます
また、リリース作業の時間帯はシステムが稼働をしていない時間帯に実施する事が多く、ほとんどは休日か夜間に実施されます
リリース作業完了後は一定の期間、問題なく動作しているかの確認を行ったり、不具合、問い合わせの対応を行っていきます
まとめ
システム開発の一般的な流れについて解説しましたが、各工程を上から順番に進めていく方法や機能毎に製造→テストを繰り返して行く方法など現場によって開発方法は様々となっています
システム開発のイメージが少しでも伝わったでしょうか。工程の中でも多くの割合を絞めるテストの実施方法などは別の記事で掲載させて頂きます
コメント