IT パスポート試験
マネジメント系(IT管理)ー大分類4：開発技術ー
- 4-8 中分類8：システム開発技術
- 4-8-25 システム開発技術
- 4-9 中分類9：ソフトウェア開発管理技術
- 4-9-26 開発プロセス・手法
4-8 中分類8：システム開発技術
- 4-8-25 システム開発技術
- ソフトウェア開発のプロセス，及び，見積りを行うときの基本的な考え方を理解する．
- ソフトウェア開発のプロセス
- 要件定義： システム及びソフトウェアに要求される機能，性能，及び，内容を明確化すること
- システム設計： 外部設計（ユーザから見た設計．画面設計，帳票設計，データにコードを割り当てるコード設計など），内部設計（開発者から見た設計．機能の分割，データ構造の決定，入出力詳細設計など），及び，プログラム設計（モジュール分割，モジュール仕様，テスト仕様など）を行う．システム設計の際には，DFD や E-R 図などが使用される．また，外部設計においては，以下に示すように，ユーザとコンピュータをつなぐ部分であるユーザインタフェースの設計が使いやすさといった面から重要になる．
- CUI（ Character User Interface ）： キーボードからコマンドを入力する方法
- GUI（ Graphical User Interface ）： 画面に表示されたアイコンやボタンをマウスでクリックして選択するなど，入力画面を通して入力する方法（最近の主流）．
- チェックディジット： 検査文字の一種であり，入力した数字の誤りを検出するために付加される数字のこと．たとえば，「12345」の後に，1 から 5 までの和を 10 で割った余り 5 を付加し，「123455」のように入力させることによって入力誤りを検出する．
- 入力チェック方式： チェックディジット以外の入力データのチェック方法
- ニューメリックチェック： 数値であるか否か
- シーケンスチェック： 一定の順序か否か
- 重複チェック： 重複があるか否か
- フォーマットチェック： 形式が正しいか否か
- 論理チェック： 論理的に正しいか否か
- リミットチェック： 適切な範囲にあるか否か
- 照合チェック： データのコードと登録されたコードの照合
- バランスチェック： 同一であることが要求されるデータを別々に集計し，その値が一致することを確認
- ソフトウェアの開発・保守における設計情報（外部・内部設計などの段階で使用されるコード設計・画面設計に関する帳票などのファイル，プログラムのソースコードなど），及び，データの定義情報（メタデータ）を一元的に管理するデータベースをリポジトリと呼ぶ．リポジトリによって，過去の開発したシステムと似たシステムの場合は，設計工数などを削減できる．
- プログラミング： システム設計に従ってプログラムを作成し，それらのプログラムに誤り（バグ）がないかを検証するため，以下に示すような方法で，単体テストを実施する．
- ホワイトボックステスト： 入力データに対する応答やモジュールの内容を読むことによって，内部構造や制御ロジックをチェックする．
- ブラックボックステスト： モジュールをブラックボックスと見て，モジュールに適当な入力データを与え，その出力結果をチェックする．有効値と無効値の境界となるデータを使用する限界値分析，有効値と無効値の各グループ（有効同値クラスと無効同値クラス）からの代表的な値を使用する同値分析などの方法がある．
- テスト： 一般に，テストの開始段階では，多くのバグが存在するため，テストの実施と共に急激に減少していく．しかしながら，時間がたつと共に，バグが少なくなり，減少の度合いが緩やかになっていく．テスト項目消化件数と累積バグ件数との関係を示す信頼度成長曲線（ゴンペルツ曲線）は，この変化を表したものである．
- また，プログラム内には if 文，for 文，switch 文等，制御の流れが分岐する箇所がたくさんあるが，分岐を含まない連続した実行文の列をブランチと呼ぶ．プログラムテストにおいて通過したブランチの割合（通過ブランチ数 / 総ブランチ数）をテストカバー率という．一般にテストカバー率が高いほど，問題箇所が解消されていくため，プログラムの品質が高くなる．
- テストの方法としては，設計文書を関係者が会議形式で読み，その内容をチェックする方法（レビュー）と，プログラム自身を入力データを使用してチェックする方法がある．レビューには，以下に示すような方法が存在する．
- ウォークスルー： 各会議出席者が独自にチェックを行い，誤りや問題があれば文書作成者が訂正する
- インスペクション： 議長（モデレータ）の指揮に従ってチェックを進め，誤りや問題があればモデレータが修正する
- 次に，プログラム自身に対するチェックは以下に示すように実行される．まず，単体テスト済のプログラムを結合し，ソフトウェアが要求どおり動作するかどうかを検証（特に，インターフェース上の誤りをチェック）するため，以下に示すような結合テストを実施する．
- トップダウンテスト： モジュールの最上位から下位に向かって順次結合して行うテスト．このとき用いられる擬似的な下位モジュールをスタブと呼ぶ．
- ボトムアップテスト： モジュールの最下位から上位に向かって順次結合して行うテスト．このとき用いられる擬似的な上位モジュールをドライバと呼ぶ．
- サンドイッチテスト： トップダウンテストとボトムアップテストを組み合わせたテスト
- ビッグバンテスト： 全モジュールを結合した総合テスト
- 結合テストが終了した後，要求仕様が満たされていることをチェックするため，以下に示すようなシステム（総合）テストを実施する．
- 機能テスト： 要求仕様が満たされていることを確認するテスト
- 性能テスト： スループット（単位時間あたりの処理量），ターンアラウンドタイム（入力から出力までの時間），レスポンスタイム（応答時間）（処理を開始してから出力を開始するまでの時間）に対するテスト
- 負荷テスト： 多量のデータ，重い計算等，高負荷に対するテスト
- 耐久テスト： 長時間稼働に対するテスト
- システムテストが終了すると，実際の稼働環境でシステムを動作させ，その能力をチェックする運用テストが実施される．
- 承認テスト（受け入れテスト）： ユーザが提供するデータに基づき，要求仕様通りになっているか否かを確認するテスト
- レグレッション（退行）テスト： システムの一部を修正した場合に行うテストであり，修正が他の部分に悪影響を与えていないことを確認する
- ソフトウェア受入れ： 委託側が実際の運用と同様の条件でソフトウェアを使用し，正常に稼働するかを確認（確認テスト）した上で，問題がなければ納入及びシステム利用者への教育訓練が行われる．
- ソフトウェア保守： ソフトウェアの保守では，システムの安定稼働，情報技術の進展や経営戦略の変化に対応するために，プログラムの修正や変更が行われる．保守の種類には，修正保守，適合保守，改善保守，予防保守，遠隔保守などがある．なお，プログラムの修正が行われた場合は，レグレッション（退行）テストが実施される．
- ソフトウェアの見積り： ソフトウェアの見積り方法として，以下に示すような方法が存在する．なお，開発工数は，開発規模に比例するのではなく，幾何級数的に増加することを理解しておく必要がある．
- ファンクションポイント法（ FP：Function Point 法）： ソフトウェアの各機能に対して，その処理内容の複雑さなどからそれを点数化し，それらの合計点からソフトウェアの規模や工数を導き出す方法である．
- LOC 法（ Line of Code 法，プログラムステップ法）： プログラムの行数から見積もる方法である．
- COCOMO 法： LOC 法の発展型であり，作業の工程数とその難易度から見積もる方法である．過去の経験と実績データに基づいて難易度を決定するため，生産性データの収集が不可欠である．
- 標準タスク法： 開発プロジェクトで必要な作業をブレークダウンしながら，各作業の工数を見積もる方法である．
- 経験値による見積もり法： 過去の類似例を探し，その実績を参考に開発規模を見積もるである．
4-9 中分類9：ソフトウェア開発管理技術
- 4-9-26 開発プロセス・手法
- ソフトウェアの開発手法や開発モデルの概要を理解する．
- 主なソフトウェア開発手法
- 構造化手法： ソフトウェアを機能ごとに分割して開発を進める手法である．
- オブジェクト指向： 処理すべき対象に焦点を当て，その処理方法と必要なデータを一つの単位として開発を進める方法である．オブジェクト指向におけるモデリングは，UML（ Unified Modeling Language ）で記述する．UML においては，クラス図，オブジェクト図，コンポーネント図，ユースケース図，アクティビティ図，コラボレーション図などが使用される．
- ユースケース図は，オブジェクト指向分析のために使用される図であり，システム外部のアクタ（システム利用者の役割であり，普通は人であるが，他のシステムの場合もある）と内部のユースケース（システムの機能）との関連を図示したものである．
- エージェント指向： 何を処理するべきかを自ら判断し，実行できるソフトウエア・モジュール（エージェント）を使ってシステムを構築する考え方である．例えば，エージェントを使った航空機予約システムでは，航空会社や時刻などを細かく指定しなくても，「～月～日～時までにニューヨークに着きたい」と指示すれば，条件に合う飛行機を，予約状況を確認しながら，エージェントが自分で判断しながら探してくれることになる．
- データ中心アプローチ： データの構造や流れに着目してシステム開発を行なう手法
- プロセス中心アプローチ： 処理を中心にしてシステム開発を行なう手法
- 主なソフトウェア開発モデル
- ウォータフォールモデル： ソフトウェア開発の各プロセスを，後戻りしないように順にたどる開発方法である．
- プロトタイピングモデル： ソフトウェア開発の各段階において，プロトタイプ（中間段階の試作品）をユーザに示し，仕様を確認しながら進める開発方法．このように，開発当初からユーザが参加する開発を JAD（ Joint Application Development ）と呼ぶ．プロトタイピングモデルでは，修正するために後戻りすることがある．
- スパイラルモデル： ウォータフォールモデルとプロトタイピングモデルを組み合わせた方法である．サブシステム単位にプロトタイピングモデルを使用しながら，サブシステムの範囲を広げていく方法である．
- RAD（ Rapid Application Development ）： ユーザの参加，少人数による開発，CASE などの開発ツールの利用によって，短期間でソフトウェアを開発する手法
- CASE： ソフトウェアの開発作業の自動化，効率化を支援するツール
- 共通フレーム（ SLCP： Software Life Cycle Process ）： ソフトウェアの開発から運用・保守に至るまでのプロセス（ソフトウェア・ライフサイクル・プロセス）を，ユーザ（発注者）及びベンダ（受注者）が共通に使用できる明確に定義された用語によって規定したもの