情報システムの運用(第10回)

システム開発技術(マネジメント系・開発技術)


配布資料

第10回(問1~問47)
解答なし解答あり解説(要ID・パスワード)
第10回 補足(問1~問36)
解答なし解答あり解説(要ID・パスワード)

訂正

問13問16の問題文の一部語句を修正。


中分類8 「システム開発技術」

【位置付け】

表: ITパスポート出題範囲(マネジメント系)
共通キャリア
  • スキルフレームワーク
  • 出題範囲(出題の考え方)
    分野 大分類 中分類






    4開発技術 8システム開発技術
    • 要件定義,システム設計,プログラミング,テスト,ソフトウェア保守などシステム開発のプロセスの基本的な流れを問う。
    • システム開発における見積りの考え方を問う。
    9ソフトウェア開発管理技術
    • 代表的な開発モデルや開発手法に関する意義や目的について問う。
    5プロジェクトマネジメント 10プロジェクトマネジメント
    • プロジェクトマネジメントの意義,目的,考え方,プロセス,手法を問う。
    6サービスマネジメント 11サービスマネジメント
    • ITサービスマネジメントの意義,目的,考え方を問う。
    • サービスデスク(ヘルプデスク)など関連項目に関する理解を問う。
    • コンピュータやネットワークなどのシステム環境整備に関する考え方を問う。
    12システム監査
    • システム監査の意義,目的,考え方,対象を問う。
    • 計画,調査,報告など,システム監査の流れを問う。
    • 内部統制,IT ガバナンスの意義,目的,考え方を問う。

    【小分類】

    小分類25 「システム開発技術」

    【目標】
    【説明】
    【項目】
    (1) システム開発のプロセス
    システム開発にはどのようなプロセスがあるかについて理解する。
    ①システム要件定義及びソフトウェア要件定義
    システム及びソフトウェアに要求される機能,性能及び内容を明確化するシステム要件定義,ソフトウェア要件定義などが行われることを理解する。
    用語例:機能要件,非機能要件,共同レビュー
    ②システム設計及びソフトウェア設計
    システム方式設計,ソフトウェア方式設計,ソフトウェア詳細設計などがあることを知り,それぞれの基本的な役割を理解する。
    用語例:外部設計,内部設計
    ③プログラミング
    システム設計に従ってプログラムを作成する。また,作成した個々のプログラムに誤り(バグ)がないかを検証するために,単体テストを行うことを理解する。
    用語例:コーディング,コンパイラ,ホワイトボックステスト,デバッグ,コードレビュー
    活用例:テストデータの作成及び分析
    ④テスト
    単体テスト済のプログラムを結合し,ソフトウェアやシステムが要求どおり動作するかどうかを検証する。また,テストには計画,実施,評価のサイクルがあることを知り,テスト実施の際,目標に対する実績を評価する必要があることを理解する。
    用語例:結合テスト,システムテスト,運用テスト,ブラックボックステスト,回帰テスト(リグレッションテスト)
    ⑤ソフトウェア受入れ
    委託側が実際の運用と同様の条件でソフトウェアを使用し,正常に稼働するかを確認した上で,問題がなければ納入が行われることを理解する。また,システム利用者への教育訓練が行われることを理解する。
    用語例:利用者マニュアル,受入れテスト,移行
    ⑥ソフトウェア保守
    ソフトウェアの保守では,システムの安定稼働,情報技術の進展や経営戦略の変化に対応するために,プログラムの修正や変更が行われることを理解する。
    (2) ソフトウェアの見積り
    ソフトウェアの開発規模,開発環境などに基づいて,開発工数,開発期間などの見積りを行うときの基本的な考え方を理解する。
    用語例:ファンクションポイント(FP:Function Point)法,類推見積法

    小分類25 「システム開発技術」

    (1) システム開発のプロセス

    システム開発にはどのようなプロセスがあるかについて理解する。

    ①システム要件定義及びソフトウェア要件定義

    システム及びソフトウェアに要求される機能,性能及び内容を明確化するシステム要件定義,ソフトウェア要件定義などが行われることを理解する。

    用語例:機能要件,非機能要件,共同レビュー

    ②システム設計及びソフトウェア設計

    システム方式設計,ソフトウェア方式設計,ソフトウェア詳細設計などがあることを知り,それぞれの基本的な役割を理解する。

    用語例:外部設計,内部設計

    ③プログラミング

    システム設計に従ってプログラムを作成する。また,作成した個々のプログラムに誤り(バグ)がないかを検証するために,単体テストを行うことを理解する。

    用語例:コーディング,コンパイラ,ホワイトボックステスト,デバッグ,コードレビュー

    活用例:テストデータの作成及び分析

    ④テスト

    単体テスト済のプログラムを結合し,ソフトウェアやシステムが要求どおり動作するかどうかを検証する。また,テストには計画,実施,評価のサイクルがあることを知り,テスト実施の際,目標に対する実績を評価する必要があることを理解する。

    用語例:結合テスト,システムテスト,運用テスト,ブラックボックステスト,回帰テスト(リグレッションテスト)

    ⑤ソフトウェア受入れ

    委託側が実際の運用と同様の条件でソフトウェアを使用し,正常に稼働するかを確認した上で,問題がなければ納入が行われることを理解する。また,システム利用者への教育訓練が行われることを理解する。

    用語例:利用者マニュアル,受入れテスト,移行

    ⑥ソフトウェア保守

    ソフトウェアの保守では,システムの安定稼働,情報技術の進展や経営戦略の変化に対応するために,プログラムの修正や変更が行われることを理解する。

    (2) ソフトウェアの見積り

    ソフトウェアの開発規模,開発環境などに基づいて,開発工数,開発期間などの見積りを行うときの基本的な考え方を理解する。

    用語例:ファンクションポイント(FP:Function Point)法,類推見積法


    1. システム開発のプロセス

    システム開発の大まかな流れ

    システム開発の流れの概要は以下の通り。

    表: システム開発の流れ
    プロセス 内容 利用者とのかかわり
    要件定義   ◎(密接なかかわりが必要)
    システム設計  外部設計(システム要件定義)
    →内部設計(システム方式設計)
    △(通常,外部設計まで)
    ソフトウェア設計  外部設計(ソフトウェア要件定義)
    →内部設計(ソフトウェア方式設計)
    →プログラム設計(ソフトウェア詳細設計)
    △(通常,外部設計まで)
    ソフトウェアコード作成
    (プログラミング)
      ×(通常,利用者はかかわらない)
    テスト  単体テスト
    →結合テスト
    →システムテスト
    →運用テスト
    △(通常,運用テストのみ)

    共通フレーム2007(Software Life Cycle Process - Japan Common Frame 2007:SLCP-JCF2007)

    共通フレーム2007とは,コンピュータシステムの開発において,システム発注側(ユーザ)と受注側(ベンダ)の間で相互の役割や業務の範囲・内容,契約上の責任などに対する誤解がないように,双方に共通して利用できるよう用語や作業内容の標準化するために作られたガイドライン。

    対象について,事業(ビジネス) > 業務 > システム(ITシステム,情報システム,コンピュータシステムなど) > ソフトウェア と階層化して考えている。

    内容は,プロセス > アクティビティ > タスク > リスト の順に詳細化されている。

    以下の項目からなる。

    表: 共通フレーム2007の構成
    分類 ライフサイクルプロセス プロセス 注釈
    共通フレーム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. システム監査 システム監査プロセス 【システム監査の視点】
    共通フレームの修整   修正プロセス  


    2. 開発プロセス

    開発プロセスの手順(共通フレーム2007より)

    表: 共通フレーム2007における開発プロセスの手順
    プロセス アクティビティ タスク
    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によればシステム要件に記述されるものは,以下の事項。

    1. システム化目標,対象範囲
    2. システムの機能及び能力,ライフサイクル
    3. 業務,組織及び利用者の要件
    4. 信頼性,安全性,セキュリティ,人間工学,インターフェース,操作及び保守要件
    5. システム構成条件
    6. 設計条件及び適格性確認要件
    7. 開発環境
    8. 品質,コストと期待される効果
    9. システム移行に際しては移行要件,妥当性確認要件
    10. 主要データベースの基本的な要件の定義

    太字の項目は共通フレーム2007においても太字で記載されている重要と思われる部分なので,把握しておくといいかも知れない。

    「システム方式設計」アクティビティ(共通フレーム2007より)

    システムの最上位レベルでの方式を確立する。

    具体的には,必要とされるハードウェア構成品目,ソフトウェア構成品目,及び,手作業を明確にする。

    ソフトウェア設計

    ソフトウェア設計における外部設計と内部設計とプログラム設計

    ソフトウェア設計では,「外部設計」と「内部設計」と「プログラム設計」の3種類に大別される。

    外部設計は「ソフトウェア要件定義」と,内部設計は「ソフトウェア方式設計」と,プログラム設計は「ソフトウェア詳細設計」と呼ばれることもある。

    表: ソフトウェア設計における外部設計と内部設計とプログラム設計
    種類 説明
    外部設計
    (ソフトウェア要件定義)
    ソフトウェアの外部(利用者や他のソフトウェア)に対して,提供する機能や入出力を設計する。
    利用者と開発者の両者が協力して実施する。
    内部設計
    (ソフトウェア方式設計)
    ソフトウェアの内部構造の概要を設計する。
    具体的には,ソフトウェアの複数のプログラム(モジュール)への分割や,処理の手順の決定などを行う。
    原則として,開発者のみで実施する。
    プログラム設計
    (ソフトウェア詳細設計)
    各プログラム(モジュール)の詳細を設計する。
    開発者のみで実施する。

    「ソフトウェア要件定義」アクティビティ(共通フレーム2007より)

    システムを構成する個々のソフトウェアごとの必要な機能や能力などを明らかにする。

    具体的には,データ定義,画面や帳票などのインタフェース設計などが含まれる。

    「ソフトウェア方式設計」アクティビティ(共通フレーム2007より)

    ソフトウェアの最上位レベルの構造と,必要とされるソフトウェアコンポーネントを明らかにする。

    また,結合テストのための暫定的なテスト要求事項および予定を定義する。

    「ソフトウェア詳細設計」アクティビティ(共通フレーム2007より)

    各ソフトウェアコンポーネントに対して詳細な設計を行う。

    ソフトウェアコンポーネントは,コーディング,コンパイル,及び,テストを実施するレベルまで詳細化する。

    プログラムごとの機能・インタフェース・プログラムの流れ図などを作成する。

    ソフトウェアコード作成(プログラミング)

    ソフトウェアコード作成(プログラミング)では,プログラム設計(ソフトウェア詳細設計)に従ってプログラムを作成し,作成した個々のプログラムに誤り(バグ)がないかを検証するために,単体テストを行う。

    詳細は次週。

    テスト

    テストの実施順序

    設計では徐々に細分化しながら行うが,テストでは逆に徐々に範囲を広くしながら進行していく。

    テストは,通常,以下の順序で実施される。

    1. 単体テスト
    2. 結合テスト
    3. システムテスト
    4. 運用テスト

    表: テストの各工程の内容
    工程 対応する設計の工程 説明 主なテスト方法
    単体テスト プログラミング(ソフトウェアコード生成)
    及び,プログラム設計(ソフトウェア詳細設計)
    それぞれのプログラムが単体で設計通りに動作するかを確認する。 ホワイトボックステスト
    結合テスト 内部設計(ソフトウェア方式設計) プログラム同士を組み合わせて正しく動作するかを確認する。 ブラックボックステスト
    システムテスト 外部設計(ソフトウェア要件定義) 実際の運用環境と近い状況で設計通りに動作するかを確認する。 ブラックボックステスト
    運用テスト 要件定義 利用者が,実際の運用環境で要求通りの機能や性能を備えているかどうかを確認する。  

    ホワイトボックステストとブラックボックステスト

    テストは,内部構造を考慮するか/しないかによって,「ホワイトボックステスト」と「ブラックボックステスト」に大別される。

    表: ホワイトボックステストとブラックボックステスト
    種類 説明 主に用いられるテストの工程
    ホワイトボックステスト 内部構造にもとづいて行うテスト 単体テスト
    ブラックボックステスト 内部構造を考慮せず,入力と出力にもとづいて行うテスト 結合テスト,
    システムテスト
    ホワイトボックステストの手法

    ホワイトボックステストの手法には以下のようなものがある。

    表: ホワイトボックステストの代表的な手法
    手法 説明
    命令網羅 すべての命令が少なくとも1回は実行されるようにテストデータを選ぶ。
    分岐網羅 すべての分岐経路が少なくとも1回は実行されるようにテストデータを選ぶ。
    条件網羅 すべての分岐条件の真偽値の組合せが実行されるようにテストデータを選ぶ。
    ブラックボックステストの手法

    ブラックボックステストの手法には以下のようなものがある。

    表: ブラックボックステストの代表的な手法
    手法 説明
    同値分割 入力を結果が同じとなるグループ(同値クラス)に分類し,それぞれのグループの代表値での動作を確認する。
    境界値分析
    (限界値分析)
    動作の変わり目となる「境界値」に着目し,①境界値と②その一つ下と③その一つ上の動作が正しいかを確認する。

    結合テストの手法

    複数のモジュールを結合させたプログラムのテストの手法には,トップダウンテスト,ボトムアップテスト,ビッグバンテストなどがある。

    表: 結合テストの代表的な手法
    手法 説明
    トップダウンテスト
    (Top Down Test)
    上位モジュールから順に結合して検証していく。
    利点は,重要な中核部分のエラーが早期に発見しやすいことである。
    テスト対象の下位には,「スタブ」と呼ばれるダミーのモジュールを用意して結合する。
    ボトムアップテスト
    (Bottom Up Test)
    下位モジュールから順に結合して検証していく。
    利点は,並行作業に向いているということである。
    テスト対象の上位には,「ドライバ」と呼ばれるダミーのモジュールを用意して結合する。
    ビッグバンテスト
    (Big Bang Test)
    すべてのモジュールを組み合わせてから,一気に動作を検証する。
    利点は,トップダウンテストやボトムアップテストに比べて手間が少ないということである。
    基本的に,小規模なシステムや構造の単純なプログラムのテストにしか用いられない。

    システムテストおよび運用テストの種類

    システムテストおよび運用テストで行われるテストには以下のような種類がある。

    表: システムテストおよび運用テストの種類
    種類 説明
    機能テスト 目標の機能が提供されているかのテスト
    性能テスト 応答時間(レスポンスタイム),ターンアラウンドタイムやスループットなどの性能が,目標の基準を満たしているかのテスト
    例外テスト 例外的なデータの入力や操作を行ったときに,適切にエラー処理されるかどうか確認するテスト
    耐久テスト システムが処理の集中など,負荷に耐えられるかのテスト

    テスト工程の進捗とバグの累積発生数

    時間経過に従い,発生数が減少してゼロに近づくことを収束,逆に,時間経過に従い,発生数が増加していくことを発散と呼ぶ(一般的には収束と発散以外になる場合も多い)。

    テスト工程が進捗するに従って,バグ累積数は収束することが望ましい。

    開発プロセスのその他のアクティビティ

    「ソフトウェア導入」アクティビティ(共通フレーム2007より)

    実環境(本番環境)にソフトウェア製品を導入するために計画を作成し,計画に従ってソフトウェア製品を導入する工程。

    「ソフトウェア受入れ支援」アクティビティ(共通フレーム2007より)

    開発プロセスの最後の工程。

    開発者は,取得者によるソフトウェア製品の受入れレビュー及びテストの支援,及び,利用者に対する教育訓練及び支援を提供する。

    受入れ時には,取得者(受入れ側)がテストケース,テストデータ,テスト手順及びテスト環境を準備することが望ましい。


    3. ソフトウェア保守

    ソフトウェアの保守

    ソフトウェアの保守では,システムの安定稼働,情報技術の進展や経営戦略の変化に対応するために,プログラムの修正や変更が行われる。

    ソフトウェアの保守の分類

    ソフトウェアの保守は,「訂正」と「改良」の2種類に大別される。

    訂正には,発生した問題を解決する「是正保守」と,障害の原因となりうる問題を見つけて解決する「予防保守」の2種類がある。 なお,是正保守実施までにシステムを運用するために,計画外で行われる一時的な修正を「緊急保守」と呼ぶ。

    改良には,環境の変化に対応するために修正を行う「適応保守」と,性能や保守性を向上させるために修正を行う「完全化保守」の2種類がある。

    ソフトウェア保守でのテスト

    ソフトウェア保守で行われるテストに回帰テスト,退行テスト(レグレッションテスト)がある。

    表: ソフトウェア保守でのテスト
    種類 説明
    回帰テスト,
    退行テスト
    (レグレッションテスト)
    ソフトウェアの保守に際し,修正や変更が他に影響を及ぼしていないかどうかを確認するテスト

    ソフトウェア構成管理

    ソフトウェア構成管理とは,プロジェクトの作業成果物の完全性を維持し,関係者が利用できる状態に保つことを目的とするプロセスのことである。


    4. ソフトウェアの見積り

    見積り手法の分類

    ソフトウェアの見積りの手法には大きく分けて,以下の3種類がある。

    1. 類推見積法
    2. 係数モデル法
    3. ボトムアップ法

    それぞれの特徴は以下の表の通り。

    表: 見積り手法の分類
    分類 概要 精度 適用可能な段階 手法の例
    類推見積法 過去の類似プロジェクトの工数やコストを参考にして見積もる 企画 類推見積法,デルファイ法
    係数モデル法 画面数,出力する帳票の種類数や機能などの数に複雑さなどの計数を乗じて見積もる 中~高 要件定義~設計 FP法,LOC法,COCOMO
    ボトムアップ法 細かい作業に分解し,個々の作業を詳細に見積もり,これを積算することで全体を見積もる 中~高 要件定義~設計 標準タスク法

    代表的な見積り手法

    • ファンクションポイント(FP:Function Point)法
    開発するシステムのもつ機能とその複雑さから,開発規模を見積もる手法。
    外部入出力や内部ファイルの数と難易度の高さから,論理的に開発規模を見積もる手法。
    画面や帳票の数などを基準に見積もるので,依頼者からのコンセンサス(合意)が得られやすいという長所がある。
    • LOC(Lines Of Code)法,プログラムステップ法
    プログラムの行数(ステップ数)から,開発規模を見積もる手法。
    • COCOMO(COnstructive COst MOdel)
    予想されるプログラム行数にエンジニアの能力や要求の信頼性などの補正係数を掛け合わせて開発工数や期間,要員や生産性を見積もる手法
    • 標準タスク法
    WBS(Work Breakdown Structure)に基づいて,成果物単位や処理単位に工数を見積もり,ボトムアップ的に積み上げていく方法。

    3点見積法

    • 3点見積法
    不確かさを含んだ確率的な見積りを求める方法。
    最も可能性が高い最頻値,最良のシナリオ(最もトラブルが起こらず作業が進むと想定した場合)の楽観値,最悪のシナリオ(あらゆるトラブルが起こると想定した場合)の悲観値の3つの値から期待値と分散(標準偏差)を計算する。
    期待値 = ( 楽観値 + 最頻値 × 4 + 悲観値 ) ÷ 6
    分散 = ( 悲観値 - 楽観値 )2 ÷ 36
    標準偏差 = (悲観値 - 楽観値 ) ÷ 6

    すぎうら しげき <>