スポンサードリンク
こんにちは、ももやまです。
今回は、システム開発のそれぞれの工程で、どんなことが行われているのかを説明していきたいと思います。
前回のソフトウェア工学の記事はこちら！
ウォーターフォールモデルをベースにシステム開発の工程をおさらいすると、
- 基本計画（要求分析・要件定義）
- 各種設計（外部設計・内部設計・プログラム設計）
- プログラミング
- テスト
の4段階に分かれているのでしたね。
では、この4段階の中でどんなことが行われているかを説明していきましょう。
目次
スポンサードリンク
１．基本計画（要求分析〜要件定義）
(1) 基本計画とは
この工程では、
- 利用者（利害関係者）と打ち合わせを行い、「システムに必要な要素・性能」を聞き出す
（要求を聞き出す 例：処理速度は早いほうがいい、80歳の人でも操作できるほうがいい……） - 聞き出した要求から、必要な「品質要件・技術要件・運用要件」などを明らかにする
- 必要な期間、予算、人員などを計画する
- 計画した内容、要件を利用者に説明し、合意を得る
のような利用者からの要求を明確にし、どのような機能が求められているかを明らかにしていきます。
料理で例えると、
- 何を食べたいのかを聞き出す
（「カレー食べたい、でも玉ねぎ入れないで！」のような感じ） - 聞き出した結果から必要な材料や値段を明らかにする
- 調理者、食べる人との合意を得る
のようなことをするのが基本計画となります。
(2) 要求仕様書と要件定義書
利用者と打ち合わせを行い、聞き出した要求は要求仕様書にまとめられます。
この仕様書を見ることで、利用者がどのような要求をしたのかがすぐにわかるようになっています。
また、聞き出した要求から得られた要件、必要なものを取りまとめた結果は要件定義書にまとめられます。
利用者が最後に合意を得る際には、要件定義書をチェックする場合がほとんどです。
(3) 基本計画における注意
基本計画は、システムを作る際の土台になります。
万が一、利用者との要求と実際のシステムに差が発生してしまうと、その後の設計、プログラミングがどんなにうまく行っても利用者が満足するようなシステムとはなりません。
（料理でも、最初のレシピ計画を間違えてしまうと、その後どんなに正確に料理ができたとしても満足した料理とはなりませんよね。）
特に「ウォーターフォールモデル」では、後戻りができないため、基本計画の問題点が設計、プログラミング時に見つかると取り返しがつかないことになります。
そのため、
- 利用者がどんな風にシステムを使いたいのかを聞き出す
（例：システムの速度を重視するのか、誰にとっても使いや - 聞き出した要求をもれなく満たせる要件を定義する
必要があります。
スポンサードリンク
２．設計（外部設計〜プログラム設計）
この工程では、要件定義をもとにシステム設計を行っていきます。
システム設計は、
- 外部設計
- 内部設計（ソフトウェア方式設計）
- プログラム設計（ソフトウェア詳細設計）
の3つのステップにわかれています。
(1) 外部設計
「利用者が実際に操作する部分」のような、システムを利用者の立場から見た設計を中心に行います。
具体的には、
- ユーザーインタフェース
- サブシステムの定義・分割
（1つの大きいシステムから複数の単純なシステムへ分割） - 入出力画面設計
- 帳票設計
- コード設計
- 論理データ設計
などを行います。
料理に例えると、
- 料理を実現するための材料、調味料の買い出し
が外部設計部分に相当します。
(2) 内部設計（ソフトウェア方式設計）
外部設計で決めた内容を「どうすれば効率よく実装できるか」を考えるのが内部設計です。
内部設計では、システムを開発者の立場から見た設計を中心に行います。
具体的には、
- 機能をプログラム単位へ分割
- 物理データ設計
（外部設計で作成した論理データを具体的なファイル・データベースへ変換する） - （入出力画面や帳票への）出力条件・チェック条件の詳細化
- 処理の詳細化
などを行います。
料理に例えると、
- 料理を作るための作り方（レシピ）を考える
が内部設計部分に相当します。
(3) プログラム設計（ソフトウェア詳細設計）
分割したプログラムをどう実装するのかを考えます。
具体的には、プログラムをモジュール単位に分けます*1。
料理だと「下ごしらえ」に相当します。
スポンサードリンク
３．プログラミング（コード作成）
設計内容に従って、プログラムをモジュールごとに作成していきます。
料理に例えると「調理」に相当します。
４．テスト
作成したプログラムに問題がないかをチェックしていきます。
料理でいう「味見」に相当します。
とは行っても、やみくもにテストをしただけでは意味がありません。
そこで、
- まずは小規模でテスト
- 問題がなければ徐々に規模を大きくしながらテスト
を行います。
（テストは下流から上流に行われていく）
テストの段階は、規模別に下の4つに分かれています。
(1) 単体テスト
まずは、モジュール単位で正しく動作をするかを確認します。
（プログラム設計、および実装部分のテストに相当します）
具体的には、
- ある入力に対し、思った通りの出力が得られるか
を確認していきます。
(2) 結合テスト
モジュール単位で正しく動作することを確認したら、次はモジュールを結合させた状態で確認を行います。
（内部設計部分のテストに相当します。）
具体的には、
- 機能・処理単位での入力チェック
を行います。
(3) システムテスト
結合テストをクリアすると、つぎはシステム全体を稼働させ、動作確認を行います。
（外部設計部分のテストに相当します。）
具体的には、
- システム全体が正しく機能するかどうかの確認
- システムの負荷試験・耐久試験
を行います。
(4) 運用テスト（受け入れテスト）
最後に、実際の運用と同じ条件による動作確認を行います。
（要件定義部分のテストに相当します。つまり、要件定義の要件がちゃんと満たされているかどうかを確認します。）
運用テストを行うことで、利用者にとってシステムの定義が満たされていることを確認することができます。
（運用テストをクリアすれば、テストをクリアしたことになります。）
システム開発のV字モデル
システム開発の一連の流れを「開発工程とテスト工程の対応関係」として表したものにV字モデルがあります。
例えば、「結合テスト」は「内部設計」のテストに対応していることが簡単に読み取ることができます。
なお、V字モデルの上側が上流工程、下側が下流工程を表しています。
５．レビュー
例えば、模試を受けた後は解いた問題の解説を見て復習し、振り返ることをしますね。
システム開発においても、それぞれの工程が終了したときに振り返りを行います。これをレビューと呼びます。
レビューを行うことで、隠れた問題点を見つけ出すことができ、後々になって大きな問題となることを防ぐことができます。
(1) レビューの種類
レビューの種類には、大きく分けて2つあります。
それぞれを簡潔にですが説明していきましょう。
(i) デザインレビュー
要件定義、外部設計、内部設計、プログラム設計などの定義・設計段階で作成したものに対して振り返ることで、設計の良しあしを検証します。
設計段階で振り返りを行うため、要件の不備、誤りを早期に発見することができます。
(ii) コードレビュー
プログラミングの際に組まれたプログラムの良しあしを検証します。
(2) レビューの実施方法
また、レビューの実施方法、つまり振り返りの仕方も何通りかあるので、紹介していきましょう。
(i) インスペクション
モデレータと呼ばれる第3者が主体となって振り返りを行います。
主な特徴としては、
- レビュー参加者の役割が明確
- レビューは形式的な文章（チェックリストなど）に基づいて実施
- レビュー結果を記録する
が挙げられます。
(ii) ウォークスルー
開発者（作成者）が主体となり、要件やプログラムに問題点がないかを確認する手法です。
短時間で行い、管理者は参加せずに作業者のみでレビューするのが特徴です。
(iii) ラウンドロビン
レビューの参加者が持ち回りで責任者を務めながらレビューを行います。
全員が責任者を務めるため、参加者全体の意欲を高めることができるのが特徴です。
６．練習問題
では、今回の内容について、基本情報の問題で復習していきましょう。
全部で4問あります。
練習1
システム開発の最初の工程で行う作業として、適切なものはどれか。
[基本情報技術者平成21年春期 午前問44]ア：各プログラムの内部構造を設計する。
イ：現状の業務を分析し、システム要件を整理する。
ウ：サブシステムをプログラム単位まで分割し、各プログラムの詳細を設計する。
エ：ユーザインタフェースを設計する。
練習2
外部設計の成果物に基づいて、実現方法や処理効率を考慮しながら、システム開発者の立場から進める設計作業はどれか。
[基本情報技術者平成17年春期 午前問42]ア：画面フロー設計
イ：機能分割・構造化
ウ：コード設計
エ：論理データ設計
練習3
運用テストにおける検査内容として、適切なものはどれか。
[基本情報技術者平成24年秋期 午前問49]ア：個々のソフトウェアユニットについて、仕様を満足していることを確認する。
イ：ソフトウェア品目の中で使用しているアルゴリズムの妥当性を確認する。
ウ：ソフトウェアユニット間のインタフェースが整合していることを確認する。
エ：利用者に提供するという視点で、システムが要求を満足していることを確認する。
練習4
ソフトウェアのレビュー方法の説明のうち、インスペクションはどれか。
ア：作成者を含めた複数人の関係者が参加して会議形式で行う。レビュー対象となる成果物を作成者が説明し、参加者が質問やコメントをする。
イ：参加者が順番に司会者とレビュアになる。司会者の進行によって、レビュア全員が順番にコメントをし、全員が発言したら、司会者を交代して次のテーマに移る。
ウ：モデレータが全体のコーディネートを行い、参加者が明確な役割をもってチェックリストなどに基づいたコメントをし、正式な記録を残す。
エ：レビュー対象となる成果物を複数のレビュアに配布又は回覧して、レビュアがコメントをする。
７．練習問題の答え
解答1
解答：イ
システム開発の最初の工程では「要件定義」を行うのでしたね。
4つの選択肢の中で「要件定義」について記述されてあるのは「イ」なので、これが正解となります。
[☆他の選択肢☆]ア：各プログラムの内部構造を設計する。
→ プログラム設計のこと
イ：現状の業務を分析し、システム要件を整理する。
→ 正解。要件定義のこと。
ウ：サブシステムをプログラム単位まで分割し、各プログラムの詳細を設計する。
→ 内部設計のこと。
エ：ユーザインタフェースを設計する。
→ 外部設計のこと。
解答2
解答：イ
システム開発者の立場から進める設計作業は「内部設計」に該当します。
4つの選択肢の中で「内部設計」について記述されてあるのは「イ」なので、イが正解です。
残りの選択肢は、すべて「外部設計」について記述です。
- 画面フロー設計
- コード設計
- 論理データ設計
この3つは外部設計の処理内容としてたまに試験で出るのでこちらも頭に入れておきましょう。
解説3
解答：エ
運用テストは、テストの最終段階で、利用者にとってシステムの要件を満足しているかどうかを確かめるテストです。
よって、答えはエとなります。
[☆他の選択肢☆]
ア：個々のソフトウェアユニットについて、仕様を満足していることを確認する。
→ 単体テストのことです。
イ：ソフトウェア品目の中で使用しているアルゴリズムの妥当性を確認する。
→ 単体テストのことです。
ウ：ソフトウェアユニット間のインタフェースが整合していることを確認する。
→ 結合テストのことです。
エ：利用者に提供するという視点で、システムが要求を満足していることを確認する。
→ 正解。運用テストのことです。
解説4
解答：ウ
インスペクションの特徴に「第3者であるモデレータ」が全体をとりまとめ、レビューを行うことが挙げられます。
よって、ウが答えです。
[参考までに]
ア：作成者を含めた複数人の関係者が参加して会議形式で行う。レビュー対象となる成果物を作成者が説明し、参加者が質問やコメントをする。
→ ウォークスルーの説明です。全体を取りまとめるのは「開発者（作成者）」です。
イ：参加者が順番に司会者とレビュアになる。司会者の進行によって、レビュア全員が順番にコメントをし、全員が発言したら、司会者を交代して次のテーマに移る。
→ ラウンドロビンの説明です。参加者全員が責任者（レビュア）になるのが特徴です。
８．さいごに
今回は、「システム開発の工程」の詳細について説明していきました。
次回は少しソフトウェアの話から離れて「プロジェクトマネジメント」について少しお話ししていきます。
*1:モジュールとは、プログラムをさらに分割し、処理内容ごとにまとめたものだと思ってください。モジュールに分けることで、モジュール単位で作成やテストを行えるなどのメリットがあります。
関連広告・スポンサードリンク
