(なし)
| 共通キャリア |
出題範囲（出題の考え方） | ||||
|---|---|---|---|---|---|
| 分野 | 大分類 | 中分類 | |||
| マ ネ ジ メ ン ト 系 |
4 | 開発技術 | 8 | システム開発技術 |
|
| 9 | ソフトウェア開発管理技術 |
|
|||
| 5 | プロジェクトマネジメント | 10 | プロジェクトマネジメント |
|
|
| 6 | サービスマネジメント | 11 | サービスマネジメント |
|
|
| 12 | システム監査 |
|
|||
システム開発の流れの概要は以下の通り。
| プロセス | 内容 | 利用者とのかかわり |
|---|---|---|
| 要件定義 | ◎（密接なかかわりが必要） | |
| システム設計 | 外部設計（システム要件定義） →内部設計（システム方式設計） |
△（通常，外部設計まで） |
| ソフトウェア設計 | 外部設計（ソフトウェア要件定義） →内部設計（ソフトウェア方式設計） →プログラム設計（ソフトウェア詳細設計） |
△（通常，外部設計まで） |
| ソフトウェアコード作成 （プログラミング） |
×（通常，利用者はかかわらない） | |
| テスト | 単体テスト →結合テスト →システムテスト →運用テスト |
△（通常，運用テストのみ） |
共通フレーム2007とは，コンピュータシステムの開発において，システム発注側（ユーザ）と受注側（ベンダ）の間で相互の役割や業務の範囲・内容，契約上の責任などに対する誤解がないように，双方に共通して利用できるよう用語や作業内容の標準化するために作られたガイドライン。
対象について，事業（ビジネス） ＞ 業務 ＞ システム（ITシステム，情報システム，コンピュータシステムなど） ＞ ソフトウェア と階層化して考えている。
内容は，プロセス ＞ アクティビティ ＞ タスク ＞ リスト の順に詳細化されている。
以下の項目からなる。
| 分類 | ライフサイクルプロセス | プロセス | 注釈 |
|---|---|---|---|
| 共通フレーム2007 | I. 主ライフサイクルプロセス | a. 取得プロセス b. 供給プロセス c. 契約の変更管理プロセス |
【契約と合意の視点】 |
| 1. 企画プロセス 2. 要件定義プロセス |
【企画と要件定義の視点】 | ||
| 3. 開発プロセス 4. 保守プロセス |
【エンジニアリングの視点】 | ||
| 5. 運用プロセス | 【運用の視点】 | ||
| II. 支援ライフサイクルプロセス | a. 文書化プロセス b. 構成管理プロセス |
||
| c. 品質保証プロセス d. 検証プロセス e. 妥当性確認プロセス f. 共同レビュープロセス g. 監査プロセス |
【品質管理の視点】 | ||
| h. 問題解決プロレス i. ユーザビリティ（使用性向上）プロセス |
|||
| III. 組織に関するライフサイクルプロセス | a. 管理プロセス b. 環境整備プロセス c. 改善プロセス d. 人的資源プロセス e. 資産管理プロセス f. 再利用プログラム管理プロセス g. ドメイン技術プロセス |
||
| IV. システム監査 | システム監査プロセス | 【システム監査の視点】 | |
| 共通フレームの修整 | 修正プロセス |
| プロセス | アクティビティ | タスク |
|---|---|---|
| 3. 開発プロセス | 3.1 プロセス開始の準備 |
|
| 3.2 システム要件定義 |
|
3.3 システム方式設計 |
|
3.4 ソフトウェア要件定義 |
|
3.5 ソフトウェア方式設計 |
|
3.6 ソフトウェア詳細設計 |
|
3.7 ソフトウェアコード作成及びテスト |
|
3.8 ソフトウェア結合 |
|
3.9 ソフトウェア適格性確認テスト |
|
3.10 システム結合 |
|
3.11 システム適格性確認テスト |
|
3.12 ソフトウェア導入 |
|
3.13 ソフトウェア受入れ支援 |
|
システム設計は，「外部設計」と「内部設計」の2種類に大別される。
外部設計は「システム要件定義」と，内部設計は「システム方式設計」と呼ばれこともある。
| 種類 | 説明 |
|---|---|
| 外部設計 （システム要件定義） |
システムの外部（利用者や他のシステム）に対して，提供する機能や入出力を設計する。 利用者と開発者の両者が協力して実施する。 |
| 内部設計 （システム方式設計） |
システムの内部構造の設計を行う。 具体的には，必要とされるハードウェア構成品目，ソフトウェア構成品目，及び，手作業を明確にする。 原則として，開発者のみで実施する。 |
企画プロセスで明らかになった機能要件をもとに，システムに求められる具体的な機能と能力を明らかにする。
共通フレーム2007によればシステム要件に記述されるものは，以下の事項。
太字の項目は共通フレーム2007においても太字で記載されている重要と思われる部分なので，把握しておくといいかも知れない。
システムの最上位レベルでの方式を確立する。
具体的には，必要とされるハードウェア構成品目，ソフトウェア構成品目，及び，手作業を明確にする。
ソフトウェア設計では，「外部設計」と「内部設計」と「プログラム設計」の3種類に大別される。
外部設計は「ソフトウェア要件定義」と，内部設計は「ソフトウェア方式設計」と，プログラム設計は「ソフトウェア詳細設計」と呼ばれることもある。
| 種類 | 説明 |
|---|---|
| 外部設計 （ソフトウェア要件定義） |
ソフトウェアの外部（利用者や他のソフトウェア）に対して，提供する機能や入出力を設計する。 利用者と開発者の両者が協力して実施する。 |
| 内部設計 （ソフトウェア方式設計） |
ソフトウェアの内部構造の概要を設計する。 具体的には，ソフトウェアの複数のプログラム（モジュール）への分割や，処理の手順の決定などを行う。 原則として，開発者のみで実施する。 |
| プログラム設計 （ソフトウェア詳細設計） |
各プログラム（モジュール）の詳細を設計する。 開発者のみで実施する。 |
システムを構成する個々のソフトウェアごとの必要な機能や能力などを明らかにする。
具体的には，データ定義，画面や帳票などのインタフェース設計などが含まれる。
ソフトウェアの最上位レベルの構造と，必要とされるソフトウェアコンポーネントを明らかにする。
また，結合テストのための暫定的なテスト要求事項および予定を定義する。
各ソフトウェアコンポーネントに対して詳細な設計を行う。
ソフトウェアコンポーネントは，コーディング，コンパイル，及び，テストを実施するレベルまで詳細化する。
プログラムごとの機能・インタフェース・プログラムの流れ図などを作成する。
ソフトウェアコード作成（プログラミング）では，プログラム設計（ソフトウェア詳細設計）に従ってプログラムを作成し，作成した個々のプログラムに誤り（バグ）がないかを検証するために，単体テストを行う。
詳細は次週。
設計では徐々に細分化しながら行うが，テストでは逆に徐々に範囲を広くしながら進行していく。
テストは，通常，以下の順序で実施される。
| 工程 | 対応する設計の工程 | 説明 | 主なテスト方法 |
|---|---|---|---|
| 単体テスト | プログラミング（ソフトウェアコード生成） 及び，プログラム設計（ソフトウェア詳細設計） |
それぞれのプログラムが単体で設計通りに動作するかを確認する。 | ホワイトボックステスト |
| 結合テスト | 内部設計（ソフトウェア方式設計） | プログラム同士を組み合わせて正しく動作するかを確認する。 | ブラックボックステスト |
| システムテスト | 外部設計（ソフトウェア要件定義） | 実際の運用環境と近い状況で設計通りに動作するかを確認する。 | ブラックボックステスト |
| 運用テスト | 要件定義 | 利用者が，実際の運用環境で要求通りの機能や性能を備えているかどうかを確認する。 |
テストは，内部構造を考慮するか／しないかによって，「ホワイトボックステスト」と「ブラックボックステスト」に大別される。
| 種類 | 説明 | 主に用いられるテストの工程 |
|---|---|---|
| ホワイトボックステスト | 内部構造にもとづいて行うテスト | 単体テスト |
| ブラックボックステスト | 内部構造を考慮せず，入力と出力にもとづいて行うテスト | 結合テスト， システムテスト |
ホワイトボックステストの手法には以下のようなものがある。
| 手法 | 説明 |
|---|---|
| 命令網羅 | すべての命令が少なくとも1回は実行されるようにテストデータを選ぶ。 |
| 分岐網羅 | すべての分岐経路が少なくとも1回は実行されるようにテストデータを選ぶ。 |
| 条件網羅 | すべての分岐条件の真偽値の組合せが実行されるようにテストデータを選ぶ。 |
ブラックボックステストの手法には以下のようなものがある。
| 手法 | 説明 |
|---|---|
| 同値分割 | 入力を結果が同じとなるグループ（同値クラス）に分類し，それぞれのグループの代表値での動作を確認する。 |
| 境界値分析 （限界値分析） |
動作の変わり目となる「境界値」に着目し，①境界値と②その一つ下と③その一つ上の動作が正しいかを確認する。 |
複数のモジュールを結合させたプログラムのテストの手法には，トップダウンテスト，ボトムアップテスト，ビッグバンテストなどがある。
| 手法 | 説明 |
|---|---|
| トップダウンテスト （Top Down Test） |
上位モジュールから順に結合して検証していく。 利点は，重要な中核部分のエラーが早期に発見しやすいことである。 テスト対象の下位には，「スタブ」と呼ばれるダミーのモジュールを用意して結合する。 |
| ボトムアップテスト （Bottom Up Test） |
下位モジュールから順に結合して検証していく。 利点は，並行作業に向いているということである。 テスト対象の上位には，「ドライバ」と呼ばれるダミーのモジュールを用意して結合する。 |
| ビッグバンテスト （Big Bang Test） |
すべてのモジュールを組み合わせてから，一気に動作を検証する。 利点は，トップダウンテストやボトムアップテストに比べて手間が少ないということである。 基本的に，小規模なシステムや構造の単純なプログラムのテストにしか用いられない。 |
システムテストおよび運用テストで行われるテストには以下のような種類がある。
| 種類 | 説明 |
|---|---|
| 機能テスト | 目標の機能が提供されているかのテスト |
| 性能テスト | 応答時間（レスポンスタイム），ターンアラウンドタイムやスループットなどの性能が，目標の基準を満たしているかのテスト |
| 例外テスト | 例外的なデータの入力や操作を行ったときに，適切にエラー処理されるかどうか確認するテスト |
| 耐久テスト | システムが処理の集中など，負荷に耐えられるかのテスト |
時間経過に従い，発生数が減少してゼロに近づくことを収束，逆に，時間経過に従い，発生数が増加していくことを発散と呼ぶ（一般的には収束と発散以外になる場合も多い）。
テスト工程が進捗するに従って，バグ累積数は収束することが望ましい。
実環境（本番環境）にソフトウェア製品を導入するために計画を作成し，計画に従ってソフトウェア製品を導入する工程。
開発プロセスの最後の工程。
開発者は，取得者によるソフトウェア製品の受入れレビュー及びテストの支援，及び，利用者に対する教育訓練及び支援を提供する。
受入れ時には，取得者（受入れ側）がテストケース，テストデータ，テスト手順及びテスト環境を準備することが望ましい。
ソフトウェアの保守では，システムの安定稼働，情報技術の進展や経営戦略の変化に対応するために，プログラムの修正や変更が行われる。
ソフトウェアの保守は，「訂正」と「改良」の2種類に大別される。
訂正には，発生した問題を解決する「是正保守」と，障害の原因となりうる問題を見つけて解決する「予防保守」の2種類がある。 なお，是正保守実施までにシステムを運用するために，計画外で行われる一時的な修正を「緊急保守」と呼ぶ。
改良には，環境の変化に対応するために修正を行う「適応保守」と，性能や保守性を向上させるために修正を行う「完全化保守」の2種類がある。
ソフトウェア保守で行われるテストに回帰テスト，退行テスト（レグレッションテスト）がある。
| 種類 | 説明 |
|---|---|
| 回帰テスト， 退行テスト （レグレッションテスト） |
ソフトウェアの保守に際し，修正や変更が他に影響を及ぼしていないかどうかを確認するテスト |
ソフトウェア構成管理とは，プロジェクトの作業成果物の完全性を維持し，関係者が利用できる状態に保つことを目的とするプロセスのことである。
ソフトウェアの見積りの手法には大きく分けて，以下の3種類がある。
それぞれの特徴は以下の表の通り。
| 分類 | 概要 | 精度 | 適用可能な段階 | 手法の例 |
|---|---|---|---|---|
| 類推見積法 | 過去の類似プロジェクトの工数やコストを参考にして見積もる | 低 | 企画 | 類推見積法，デルファイ法 |
| 係数モデル法 | 画面数，出力する帳票の種類数や機能などの数に複雑さなどの計数を乗じて見積もる | 中～高 | 要件定義～設計 | FP法，LOC法，COCOMO |
| ボトムアップ法 | 細かい作業に分解し，個々の作業を詳細に見積もり，これを積算することで全体を見積もる | 中～高 | 要件定義～設計 | 標準タスク法 |
すぎうら しげき <>