基本情報技術者試験 第4章「開発技術」 – よく出る問題と抑えておきたいポイント

技術
#Satou
kihonjyoho4-ic

こんにちわ、佐藤です。

今回は、基本情報技術者試験、第4章「開発技術」になります。この章はソフトウェア開発管理技術が開発を取り巻く管理項目を取り上げており、より実務的な章となっています。


実務経験の有無で勉強の優先度も変わるので、実務経験がある方は「よく出る問題」へどうぞ!

今回の内容

今回は、幅広い対象範囲の中、「開発技術」に焦点を当てて、書いていきます。

  1. 抑えておきたいポイント

  2. 抑えておきたい単語

  3. よく出る問題

下記、試験範囲の詳細です。

試験範囲の詳細

  • 第1章 基礎理論
  • 第2章 コンピュータシステム
  • 第3章 技術要素
  • 第4章 開発技術
  • 第5章 プロジェクトマネジメント
  • 第6章 サービスマネジメント
  • 第7章 システム戦略
  • 第8章 経営戦略
  • 第9章 企業と法務



  • この章は2つの分類に分かれており、システム管理技術がシステム開発の手順および開発からテストに至る流れと、ソフトウェア開発管理技術が開発を取り巻く管理となっています。効率的に覚えるには、開発の流れに沿って覚えるといいと思います。


    以下、抑えておきたい項目です。


    システム開発プロセスの手順

    早速ですが、システム開発の流れを確認ください。


    システム開発の流れ

    企画プロセス
    経営上のニーズや課題を確認し、現行業務やシステムを分析し、対象業務の明確化。また、開発、運用、保守に関わる工数、費用、投資効果の検証も行われます。
    要件定義プロセス
    実現しようとする業務要件や組織要件を定義します。さらに、その業務で必要なシステムの機能を明確にして評価を行い、合意を得ます。
    システム要件定義
    システムに対するユーザの要求を明確化し、表面化していない隠れた要求を掘り起こす作業を行います。
    システム方式設計
    システム要件をハード・ソフト・手作業に振り分けそれぞれに必要なシステム構成を決めます。開発後に行うシステム総合テストのテスト計画も作成されます。
    ソフトウェア要件定義(外部設計)
    構築するシステムのソフトウェア部分について要件を確立します。また作業にあたって、ヒアリング、ユースケース図、プロトタイプ、DFD、E-R図、UML、決定表など、さまざまな手法を利用します。
    ソフトウェア方式設計(内部設計)
    開発者側の観点で、システムを機能単位のコンポーメント(サブシステム)に分割し、それらをつなぐコンポーメント間インターフェイス仕様、データベースの最上位レベルの仕様を設計していきます。
    また、個々のコンポーメントを完成したときに行うソフトウェア結合テストの仕様を決めておきます。
    ソフトウェア詳細設計(プログラム設計)
    前工程で分割したソフトウェアコンポーネントおよびインターフェースについて、それぞれの詳細内容を設計していくのがソフトウェア詳細設計です。
    ソフトウェア構築(コーディング)+デバック
    ソフトウェア詳細設計により、細部の仕様が決められ、分割した各ソフトウェアユニットについて、実際にコーディング(プログラミング)を行っていきます。ここで完成したユニットは、それぞれテストデータを用いて単体テストを行います。
    テスト
    結合テスト、評価、レビューを実施し、総合テストを行います。また総合テストも同様に評価、レビューが行われます。さらに、結果に応じてシステムのチューニング(調整)を実施します。
    移行
    移行計画に基づき、旧システムから新システムへの移行作業を行います。その後、利用者教育を実施し、受け入れテストを経て納入します。
    運用保守プロセス
    障害発生後に修復する作業だけでなく、システムの運用状況を監視したり、故障する前に部品を交換するなど、システム障害が発生しないように、事前に対策をとることも含みます。
     
     
     

    ホワイドボックステスト

    単体テストや結合テストなどに使うテストで、プログラム内部の処理や論理に着目してテストデータを作成します。

    命令網羅 すべての命令を少なくとも1回は実行します。
    条件網羅 判定条件の真と偽について、それぞれの組み合わせを満たし、少なくとも1回は実行します。
    判定条件網羅(分岐網羅) 判定条件で真、偽ともに少なくとも1回は実行します。
    条件/判定網羅 判定結果の中の個別の条件が少なくとも1回の真と偽の結果をもち(組み合わせは考慮しない)、かつ、判定条件で真、偽ともに少なくとも1回は実行します。
    複数条件網羅 判定条件の真と偽について、あらゆる組み合わせの経路を網羅し、かつ、すべての命令を少なくとも1回は実行します。

    ブラックボックステスト

    プログラムの内部構成は意識せず(中身が見えないブラックボックスとする)、インターフェース(入出力)だけに着目してテストデータを設計します。

    同値分割 入力データが取りうる値の範囲を同値クラスに分割し、各クラスの代表値をテストデータとします。
    限界値分析 同値クラスの端に位置するデータをテストデータとします。
    原因結果グラフ 対象となるデータが、明確にクラス分けできないときに使う方法です。入力と出力を書き出して、原因結果グラフを作成し、決定表で整理してテストデータを設計します。
    エラー埋込法 残存エラーを予測する際に使う方法です。プログラムの中に易怒的にエラーを埋め込んでおき、埋め込みエラーと真のエラーから、残存する真のエラーを推定します。

    システム開発に伴うさまざまな管理

    ソフトウェアの著作権管理

    システム開発に伴って作成するソフトウェアは、自社のシステム部門で開発する、他社に依頼する、パッケージを購入してカスタマイズするなど、途中の経緯はさまざまで、複数が混在している場合もあります。これらのソフトウェアを社内のシステムとして適切に使い続けるには、知的財産(著作権や特許権など)を把握し、きちんと管理しておく必要があります。


    ライセンス管理

    自社が権利を持たないソフトウェアを使用する場合には、ライセンス契約を交わす必要があり、獲得したライセンスは、契約の範囲で使用するよう、適切に管理する必要があります。
    ライセンス契約(使用許諾契約)には次のような形があります。

    シングルユーザライセンス ソフトウェアの使用許諾権。一般に1ライセンスで1人のユーザが1台のコンピュータで利用できる。
    サイトライセンス 1つのソフトウェアを企業内、学校内などの決められた範囲内で複数のユーザが利用する権利。
    サーバライセンス ネットワークのサーバにインストールされたソフトウェアを、クライアントが読み込んで利用できる。
    ボリュームライセンス インストールできる台数を複数許可した契約。企業や学校などで利用される。

    構成管理・変更管理

    システムを構成するハードウェアやソフトウェア、データベース、ドキュメントなどは、使用期間中に何度も変更や更新が行われます。そこで最新バージョンを把握し、更新履歴を記録しておくことが重要になります。

    構成管理 ハードウェアの台数や設置場所、ソフトウェアのライセンスやバージョンなどすべての情報資源を管理します。
    変更管理 ある時点での構成を基準にして、品目の完全性を確保したうえで、変更計画を策定し、変更部分を管理します。
    リリース管理 構成品目の完全性が保証されたものについて、ソフトウェアや関連文書のリリースを行い、バージョン管理と保管期間の管理を行います。

    以上、抑えておきたい項目でした。


    今回の押さえておきたい単語はこちらです!!

    スタブ
    コンピュータプログラムのモジュールをテストする際、そのモジュールが呼び出す下位モジュールの代わりに用いる代用品のこと。


    ドライバ
    ソフトウェアテストの分野で、複数のソフトウェア部品(モジュール)の結合テストを行なう際に、呼び出し側のモジュールが未完成であったりテストのために実行するのが面倒だったりする場合に、代用プログラムのこと。


    以上、抑えておきたい単語でした。


    それでは今回も過去の試験問題より抜粋した問題に挑戦してみてください!


    開発プロセスにおける、ソフトウェア方式設計で行うべき作業はどれか。


    ア: 顧客に意見を求めて仕様を決定する。
    イ: 既に決定しているソフトウェア要件を、どのように実現させるかを決める。
    ウ: プログラム1行ごとの処理まで明確になるように詳細化する。
    エ: 要求内容を図表などの形式でまとめ、段階的に詳細化して分析する。




    解答:イ

    2.ブラックボックステスト

    ブラックボックステストに関する記述として、適切なものはどれか。


    ア: テストデータを作成基準として、命令や分岐の網羅率を使用する。
    イ: 非テストプログラムに冗長なコードがあっても検出できない。
    ウ: プログラムの内部構成に着目し、必要な部分が実行されたかどうかを検証する。
    エ: 分岐命令やモジュールの数が増えると、テストデータが急増する。

    ヒント
    ブラックボックステストは、プログラムの外部仕様から、機能とデータの関係に着目してテストケースを設計する方式である。

    解答:イ

    3.ホワイトボックステスト

    下の図の構成をもつプログラムに対して、ホワイトボックステストのテストケースを設計するとき、少なくとも実施しなければならないテストケース数が最大になるテスト技法はどれか。

    基本情報_図1

    ア: 条件網羅
    イ: 判定条件網羅
    ウ: 複数条件網羅
    エ: 命令網羅




    解答:ウ

    4.ライセンス契約

    包括的な特許クロスライセンスの説明として、適切なものはどれか。


    ア: インターネットなどでソースコードを無償公開し、誰でもソフトウェアの改良および再配布が行えるようにすること。
    イ: 技術分野や製品分野を特定し、その分野の特許権の使用を相互に許諾すること。
    ウ: 自社の特許権が侵害されるのを防ぐために、相手の製造をやめさせる権利を行使すること。
    エ: 特許登録に必要な費用を互いに分担する取り決めのこと。

    ヒント
    包括的な特許とは、1件ごとではなく、より範囲を広げ分野ごとに交わすこと。

    解答:イ

    5.構成管理

    ソフトウェア開発において、構成管理に起因しない問題はどれか。


    ア: 開発者が定められた改版手続きに従わずにプログラムを修正したので、今まで正しく動作していたプログラムが、不正な動作をするようになった。
    イ: システムテストにおいて、単体テストレベルのバグが多発して、開発要諦が予定通りに進捗しない。
    ウ: 仕様書、設計書および、プログラムの版数が対応付けられていないので、プログラム修正時にソースプログラムを解析しないと、修正すべきプログラムが特定できない。
    エ: 1つのプログラムから多数の派生プログラムが作られているが、派生元のプログラムの修正がすべての派生プログラムに反映されない。

    ヒント
    構成管理は、システムやプログラムが正常に稼働している完全な状態を基準にして、最新構成の状態を管理し、バージョンの整合性を確保すること

    解答:イ

    まとめ

    お疲れさまでした。以上となります。

    ここから先の章はほとんどが暗記となります。範囲も膨大でやるべき所を見極めることも必要です。一通りの問題を解いて苦手な分野を重点的に勉強するといいかもしれません!

    それでは、また次回。




    《関連記事》
    基本情報技術者試験 第1章「基礎理論」 – よく出る問題と抑えておきたいポイント
    基本情報技術者試験 第2章「コンピュータシステム」 – よく出る問題と抑えておきたいポイント
    基本情報技術者試験 第3章「技術要素」(データベース) – よく出る問題と抑えておきたいポイント
    基本情報技術者試験 第3章「技術要素」(ネットワーク) – よく出る問題と抑えておきたいポイント
    基本情報技術者試験 第3章「技術要素」(セキュリティ) – よく出る問題と抑えておきたいポイント