企画プロセスでビジネス要件を整理し、
その内容を元に、要件定義プロセスでシステムの情報整理・言語化をおこないます。
これに続いて、システム開発プロセスの業務をおこないます。順番に、どんな手順があるかを見ていきましょう!
手順 | 概要 |
システム設計 |
要件定義で決めたことを、エンジニアがプログラムに落とすため、開発に必要な情報を整理し、ハードウェアやソフトウェアの仕様を決定する。 例えば、実装される画面ごとのパーツを、重複なく、役割に応じて命名するのもこの段階。 また、一定量まではアクセスが集中しても耐えられるよう、サーバの強度等もこの段階で決定する。 |
開発 |
エンジニアが設計に沿ってプログラムを書き、システムをつくる。 システム設計で定めたことを忠実に再現する。 また、システム設計どおりに実装できたか、誤りや過不足がないかは、 エンジニアと設計担当者の間でのレビュー(決めたことの確認・調査)により確認する。 |
テスト |
システムが設計どおりに動作するか、確認する工程。 単一画面で正しく動作するか、システムの一連の操作が要件に沿っているか、システムが仕様どおりに動くか、等「テスト」をする。 テストをする目的は、プログラムに誤り(バグ)がないか、システム設計に沿った成果物ができているか、などを確かめるため。 テストの単位と確認内容(テストケース)は、あらかじめ決める |
リリース/納品 | システムが完成したら、ユーザに使ってもらえるよう、ネットワーク上に公開する。この工程をリリースという。
BtoBのシステム開発の場合、この段階で顧客にシステムを納品することになる。 |
システム開発の手順のうち、「テスト」の工程はいくつかの種類があるため、その詳細も知っておきましょう。
テストの工程 | 概要 |
単体テスト | プログラムの部品(モジュール)単体をテストする。
プログラムの最小単位で誤りがな いことを検証する。 |
結合テスト | 単体テストが完了したプログラム 同士を組み合わせ、データの受け渡しや連携がうまくいくかを検証 する。 |
システムテスト | システム要件に沿った動作をするか、一連の流れを検証する。
業務で実際に使うデータを入力し、想定どおりに処理されている かなど、実際にリリースして問題がないかを確認する。 システムテストまでは、エンジニア組織のメンバーだけで確認できるよう、検品環境でテストをおこなう。 |
運用テスト
|
本番環境と同じ条件下でシステムを運用し、要件どおりにシステムが動作するかを検証する。
運用テストが設計どおりに動作す ることが確認できれば、いよいよシステムは顧客に届けられる状態 となる。 |
どちらも、つくったプログラムが設計どおりにできているかを確認するためのテスト手法です。
✅ホワイトボックステストは、主に単体テストのプロセスで実施されます。
内部構造に着目し、プログラムが意図したとおりに動くか(プログラム構造、エンジニアが作成したロジックや制御)等の検証をおこないます。
✅ブラックボックステストは、主に結合テストのプロセスで実施されます。
システム自体が仕様を満たしているかを確認するテストで、入力と出力のみに着目します。
今日も最後までブログを見てくださり、ありがとうございました!
次のITすきま教室でお会いしましょう👋
ITすきま教室では講師や講演のご依頼もお受けしております。
YouTubeチャンネル運営のほか、ナレーターや司会業としても活動してきた経験から、分かりやすく満足度の高い講義をご提供します!
解説が分かりやすいと沢山の方からご好評をいただいており、IT資格勉強コンテンツで日本トップの登録者数を集めています。すきま時間を使って勉強して資格合格や成績アップを目指しましょう!
YoutubeチャンネルはこちらX(旧Twitter)で関連用語を3時間に1度つぶやきます!
すきま時間の学習にお役立てください!
ITすきま教室の公式LINEスタンプができました!
ポップなTechnologyをテーマに、
ボケたり、ツッコんだり、使い勝手を意識して
プログラミングの世界を表現しています!