情報処理技術者試験対策のページ＞午前対策 目次

テクノロジ系 開発技術 システム開発技術

開発プロセス・手法

1. ソフトウェア開発モデル
   • プロトタイピング（プロトタイプモデル）
     • システム開発の初期段階で試作品を作成して、ユーザ部門と開発部門との認識のずれや曖昧さを取り除き、利用者の要求を明確にすることによって、仕様を評価・確定し開発を推進する
     • 開発初期段階での試作を通じて、ユーザインタフェースの確定や、応答性などの性能確認を行い、後続段階での仕様変更による手戻りのリスクを減少させる
     • 試作品を作り、利用者の要求をフィードバックして開発を進める
     • システム開発を上流工程から下流工程まで順番に進めるとき、システムの利用者によるテストの段階で大幅な手戻りが生じることがある
       それを防ぐために、早い段階で試作ソフトウェアを作成して利用者の要求事項を明確にする手法
     • 利用者、開発者双方の誤解を早期に排除し、手戻りのない開発を進めるために、試作プログラムをシステム分析もしくは外部設計段階で作成・評価すること
     • 実際に運用する前に評価モデルを作り、評価、改良を繰り返すので、システムの使用や性能の早期確定に有効である
   • スパイラルモデル
     • 要求分析から実装までの開発プロセスを繰り返しながら、システムを構築していくソフトウェア開発手法
     • 開発工程を分析、設計、開発、検証の工程に分けて順次行い、検証から再度分析に戻り、この工程を繰り返す手法
     • 大規模なアプリケーションを開発するときに、システムを独立性の高いサブシステムに分割して、設計、設計、プログラミング、テストの開発工程を反復しながらリスク分析を行い、開発機能の規模を拡大し、完成度を高めていく開発手法
     • 開発コストなどによってリスクを評価しながら開発するので、リスクが最小となる
     • 複雑なソフトウェアを全部最初から作成しようとするのではなく、簡単な部分から分析、設計、実装、テストを繰り返し行い、徐々に拡大していく
     • システム全体を独立性の高い部分に分解できる場合、その部分ごとに分析・設計・プログラミングを繰り返し、システム全体を完成させるモデル
     • 要件定義、設計、プログラミング、テストを循環的に繰り返すので、未確定の要求があるシステムを開発する場合に有効である
   • ウォータフォールモデル
     • 開発を上流から下流に一方向に進めるモデル
     • 開発工程を設計、実装、テストなどに分け、前の工程が完了してから、その成果物を使って次の工程を行う
     • 要求定義、設計、製作、試験、保守の順序で開発を進め、各工程でそれぞれの成果物を確認し、前工程には戻らないことを前提に各工程を完了させていく手法
     • 計画・分析・設計・プログラミング・テスト・運用の各工程を順に進め、逆流しないように開発するモデルのこと
     • 要求分析から設計、プログラミング、テストへと前フェーズの成果物を元に開発を進め、原則として後戻りを認めない
     • システム開発を工程順に進めるので、後戻りすればシステムの開発効率が著しく低下する
     • 開発効率を高めるには、各工程内でのレビューやテストによって品質を確保し、前の工程への逆戻りが起こらないようにする
     • 上流工程で作り込まれた誤りが後工程まで検出できずに残る危険がある
     • 内部設計、プログラミング、単体テストなどの各工程の中で、並行作業を可能とするために開発要員を追加することで開発期間の短縮に効果が期待できる
     • ウォータフォール型のソフトウェア開発において、運用テストで発見された誤りの修復に要するコスト
       外部設計の誤りは、プログラムだけでなく、マニュアルなどにも影響を与えるので、コーディングの誤りに比べて修復コストは高い
   • 成長モデル（インクリメンタルモデル）
     • 最初にシステム全体の要求定義を行い、要求された機能を幾つかに分割して 分析→設計→製造→テストという開発行程を繰り返し、継続的にバージョンアップを施し、徐々に機能を追加していくプロセスモデル
     • 段階的にリリースするので、すべての機能がそろっていなくても、最初のリリースからシステムの動作確認をすることができる
     • 一度の開発ですべてを作るのではなく、基本的なシステムアーキテクチャの上に機能の優先度に応じて段階的に開発する
     • スパイラルモデルを改良した方法であり、機能分割と段階的な機能追加を繰り返すので、大規模システム開発に最適である
   • ラウンドトリップ
     オブジェクト指向開発において、分析と設計、プログラミングを何度か行き来しながらトライアンドエラーで完成させていく手法
   • RADモデル ( Rapid Application Development )
     • 早期にアプリケーションを開発するための手法
     • プロトタイプを多用することで設計期間を短縮する
     • ライフサイクルの無制限な繰り返しを防ぐため、タイムボックスと呼ばれる一定の開発期間を設定する
     • 高品質のシステム開発を、早く、安く行う事を目的とするシステム開発方法論
     • 少数精鋭のチームを組み、各種開発ツールを活用し、プロトタイプモデルによってシステム開発を進める
     • 要求分析や設計作業に対するエンドユーザの参画を重視する
     • CASEツールを多用し、ユーザの積極的な参画を得ながら、短期間(90〜180日)でシステムを完成させる手法
   • エクストリームプログラミング (XP ； Extreme Programming )
     • ユーザー要求や仕様の変更リスクを軽減するために、顧客や開発者間のコミュニケーションを重視し、コーディングとテスト、リファクタリング（コードの書き直し）に重点を置いて、短期間のリリースを繰り返して開発を進めていくソフトウェア開発方法論
     • ペアプログラミング ( pair programing )
       2人のプログラマが1台のコンピュータで共同でソフトウェア開発を行う手法
       プラクティスの一つに取り入れられている
   • アジャイルソフトウェア開発
     • ペアプログラミング
       品質の向上や知識の共有を図るために、2人のプログラマがペアとなり、その場で相談したりレビューしたりしながら、一つのプログラムの開発を行う
   • エキスパートシステムの開発アプローチ
     • 専門家と同等の知識をあらかじめ準備することが困難であるため、一般に進化型のアプローチをとる
     • 進化型のアプローチ：部分的に定義された要求から開発を開始し、後続するいくつかの開発で要求を見直していく
   • デザインパターン
     度々発生する設計上の課題を解決するために繰り返し用いる、オブジェクトやクラスの構造を記述したもの
   • ソフトウェア再利用
     再利用可能な部品の開発は、同一規模の通常のソフトウェアを開発する場合よりも工数、コストがかかる
   • リファクタリング
     プログラムの外部仕様を変えずに、内部構造を分かりやすいものに変更すること
   • 形式手法
     ソフトウェアの品質向上手段
     仕様の厳密な定義とモデルの論理的な検証により品質を向上させる
   • リバースエンジニアリング
     • ソフトウェアの再利用技術
     • 既存のプログラムを解析し、プログラムの仕様と設計の情報を取り出す手法
     • モデリングツールを使用して、本稼働中のデータベースシステムの定義情報からE-R図などで表現した設計書を生成する手法
     • 過去に作成されたソフトウェアの保守のときに利用される
     • プログラムからUMLのクラス図を生成すること
     • 既存のプログラムからそのプログラムに仕様を導き出すこと
     • 既存のソフトウェアを解析し、その仕様や構造を明らかにする
   • フォワードエンジニアリング
     リバースエンジニアリングによって既存のシステムから解析された仕様をもとに、新規のシステムを開発すること
   • コンカレントエンジニアリング
     既存のプログラムやファイルを解析して仕様書を作成し、これを参考にして同等の機能をもったプログラムやファイルを作成する開発手法
   • マッシュアップ
     • 公開されている複数のサービス（API）を利用して、新たなサービス（Webサービス）を作成・提供すること
     • 例
       店舗案内のページ上に、他のサイトが提供する地図情報を表示する
2. ソフトウェアライフサイクルプロセス （ SLCP ； Software Life Cycle Process ）
   • ソフトウェア開発とその取引の適正化に向けて、それらのベースとなる作業項目を一つ一つ定義し、標準化したもの
   • ソフトウエアを中心としたシステムの企画、開発、運用、保守、及びそれらに関わる諸活動のこと
   • ベースライン
     ソフトウェアライフサイクルにおいて、成果物の構成管理をするための基準となる構成要素の集合
   • システムの運用・管理の観点から、システムのライフサイクルの終わりと判断するには不適切なもの
     不正なアクセス、プログラムやデータの破壊、パスワードの盗難などが起きるようになってきた
   • ソフトウェアライフサイクル
     • 企画プロセス
       • システムを実現するための実施計画が策定され、承認されている
       • 経営上のニーズと課題の確認
     • 要件定義プロセス
       • 開発するソフトウェアの要件が定義され、レビューされている
       • システムに対する要件と制約条件が定義され、合意されている
       • 新しい業務の手順やルール、制約条件を明確にし、利害関係者間で合意する
       • システム方式の設計と評価
       • 機能要件と非機能要件の定義
     • 開発プロセス
       • データベースが最上位のレベルで設計され、レビューされている
       • ソフトウェア方式の設計と評価
     • 運用プロセス
     • 保守プロセス

知的財産適用管理

1. 著作権管理
2. 特許管理
3. 保管管理

開発環境管理

1. 開発環境稼働状況管理
2. 開発環境構築
3. 設計データ管理
4. ツール管理
5. ライセンス管理
   • 法人でPC100台分のソフトウェアXのライセンスを購入し、ライセンス分のインストールを実施した場合の対応
     • 使用許諾契約に反していない
       • PC10台を他部署へ移動させたが、ディスク内のソフトウェアXは消去せず、移動先でそのまま使用した
     • 使用許諾契約に反している
       • 新規にPC10台を購入し、ソフトウェアXをインストールしたが、ライセンスの追加購入はしなかった
       • ソフトウェアXが販売停止となったので、ライセンスの使用状況の管理を中止し、自由にインストールできるようにした
       • ソフトウェアXをインストールしたPCの台数ではなく、同時に利用している台数が、購入したライセンス数を超えないようにした
   • デュアルライセンスのソフトウェアを利用する条件
     複数のライセンスが設定されているので、利用者はそのうちの一つのライセンスを選択して同意する

開発資源

1. 開発工数
2. ハードウェア資源
3. ソフトウェア資源
4. 直接労務費
5. 直接材料費
6. 直接経費
7. 間接経費

工数見積り・開発規模見積り

1. ソフトウェアの開発規模と開発工数の関係を表すグラフ
   
2. 補正係数  (変動率 / 努力係数 / 目標係数 )
   開発規模を見積もるときに使用する当プロジェクトの特殊性を数値化したもの
3. 経験値による見積もり
   • 類似法 ( 類似見積り法 )
     • 過去に開発した類似したシステムの経験や数値から開発工数を見積もる方法
     • 経験豊富なメンバが必要
     • トップダウン見積もりの一つで、全体規模を見積もり、各サブシステムに所要開発量を割り振る
     • 一種の直感であり、各作業の見積り工数を積み上げたものではない
     • 精度が高くなる場合
       • 見かけだけでなく実質的に類似している場合
       • 見積りを実施する担当者が必要な専門知識を有する場合
   • 3点見積もり
     • システムやモジュールの規模を推定する
     • 最大値、最小値、最尤値（さいゆうち；もっとも確からしい値、最頻値とも）の加重平均により見積もる
     • 見積値 = （ 最小値 ＋ 最尤値 x 4 + 最大値 ) / 6
     • 見積値 = （ 楽観値 ＋ 最頻値 x 4 + 悲観値 ) / 6
   • 標準タスク法
     • 開発工数の見積もり方法の一つでWBSに基づいて、成果物単位や処理単位に工数を見積もり、ボトムアップ的に積み上げていく方法
     • ボトムアップ見積もり（ 標準値法 ）
       • 開発システムを機能分割してサブシステムを決め、サブシステムごとの規模を推定し、これらを積み上げて全体規模や工数を推定する
       • WBSの最下位の作業項目を個々に見積り、総合計して全体の見積り工数を算出する方法
       • 標準となる生産性に開発規模を乗じて見積り工数を算定する方法
       • 過去の経験から求めた作業ごとの工数を積み上げていくので精度が高くなる
       • プロジェクトの初期段階では、WBSの最下位の作業項目までの分解が困難であり、見積ができない場合が多い
4. モデル化による工数見積もり
   • Putnamモデル
     レイリー分布に基づく予測式モデルにより時間の変化に応じて変化する必要工数を数式化する
   • Dotyモデル
     ソフトウェア開発に要する工数はプログラムのステップ数の指数乗に比例するという考え方に基づいたモデル
   • ファンクションポイント法
     • 外部入出力や画面数、内部論理ファイルの数と開発の難易度から、システムの開発規模を見積もる方法
     • システムの機能を入出力データ数やファイル数などによって定量的に計測し、複雑さとアプリケーションの特性による調整を行なって、システム規模をみつもう方法
     • アプリケーションにおける外部入力、外部出力、内部論理ファイル、外部インタフェースファイル、外部照会の5つの要素の個数を求め、それぞれを重み付けして集計する。集計した値がソフトウェア開発の規模に相関するという考え方に基づいて、開発規模の見積に利用される
     • 外部入力や内部論理ファイル、照会、インタフェースなどの個数や特性などから開発規模を見積もる
     • 帳票数、画面数、ファイル数などのデータを基に、システム特性を考慮して、ソフトウェアの規模を見積もる
     • 入力、出力などを基に複雑さを加味してシステム規模を見積もる方法
     • プログラムの行数やファイルサイズなどを基に、ソフトウェアの規模を見積もる手法
     • 開発工数を算出するためには実績データの収集や評価が必要になる
     • ファンクションポイントを算出するときの考え方
       ファンクションの種別ごとに、最初に未調整ファンクションポイントを算定する
     • 外部仕様から、そのシステムがもつ入力、出力や内部論理ファイルなどの5項目に該当する要素の数を求め、さらに複雑さを考慮した重みを掛けて求めた値を合計して規模を見積もる
     • システムの外部仕様の情報からそのシステムの機能の量を算定し、それを基にシステムの開発規模を見積もる手法
     • 画面数、出力帳票数、ファイル数とその難易度からソフトウェアの開発規模を見積もる方法
     • 開発工数の見積りに5つの値(インタフェース)を用いる
       • 外部入力
         入力画面の数
       • 外部出力
         帳票の数
       • 内部論理ファイル
         使用するテーブル数(ファイル数)
       • 外部インタフェースファイル
         外部のシステムとデータ交換をするためのテーブル数
       • 外部参照
       • 参照画面の数
     • 算定式
       • ファンクションポイント数=ファンクション数×(補正係数×0.01+0.65)
       • 開発工数=ファンクションポイント数×生産性
         =ファンクションポイント数×(ファンクションポイント/人月)
       • 一般的に使用される補正係数の重み付け係数：０．０１
       • 一般的に使用される1ファンクション数をファンクションポイント数に換算する数値：０．６５
       • 生産性
         1人月で何ファンクションポイントを生産できたかを示す数値で、過去実績平均値をそのまま使用する
       • ファンクションポイント数
         作業の重みを表す数値で、ファンクションポイント数が多いほど工数がかかる作業であることを示す
       • 補正係数
         プロジェクトの特殊性を加味するために設定する
   • IFPUG法
     • ファンクションポイント法の一つ
     • 機能をデータファンクションとトランザクションファンクションとに分類する
     • データファンクション：EIF、ILF
     • トランザクションファンクション：EI、EO、EQ
       • 機能種別]
         • EI：外部入力
         • EO：外部出力
         • ILF：内部論理ファイル
         • EIF：外部インタフェースファイル
         • EQ：外部参照
   • COCOMOモデル / COCOMO法 ( Constructive Cost Model )
     • ソフトウェアの規模を入力変数として、コスト誘因とそれに対する計数を考慮しながら開発工数を計算してコストを見積もる
     • ソフトウェア開発の生産性に影響を与えるプログラム限度などの要員の影響度を設定し、開発規模を見積もる方法
     • プログラムステップ換算法
     • 自社における生産性のデータ収集が不可欠
     • プログラム生成ツールを使用すると正しく見積もれなくなり、不正確となる
     • COCOMOにはシステム開発の工数を見積もる式の一つに
       MM=3.0×(KDSI)^1.12
       がある。MMは開発工数(人月)、KDSIは開発規模(注釈を除いたソースコードの行数、単位はk行)としたときの開発規模(KDSI)と開発生産性(KDSI/MM)の関係を表したグラフ
       
     • 見積り工数=(予想プログラムステップ数×開発生産性)＾指数倍率 ×補正係数
       • 予想プログラムステップ数
         • 開発仕様としているプログラムの有効ステップ数(コメント行を除いた行数)
         • 開発言語が決定されていないと見積もれない
         • ”開発予定プログラム本数×1本あたり平均ステップ数”で考えることが多い
       • 開発生産性
         過去の実績平均から、kステップ/人月で算出する
       • 補正係数
         プロジェクトの特殊性(要員のスキルレベル、新技術の採用など)を加味するために開発工数に乗じる
     • COCOMOIIモデル
       • COCOMOモデルの改良モデル
       • ファンクションポイントによる規模見積もりを取り入れている
     • ソフトウェアの開発規模から開発工数を見積もる際に、必要な情報
       生産性
     • アプリケーションプログラムの規模を見積もるための基となる情報
       画面数と帳票数

その他

1. システム開発における品質管理
   システムへの要求機能の充足度だけでなく、ドキュメントなどすべての成果物を含めて品質管理の対象とする
2. システム開発における、エラーを検出した時期とその不具合にかかる対応費用の関係
   
3. 情報戦略の立案時に、必ず整合性をとるべき対象
   中長期の経営計画
4. システム開発においてシステム運用部門が果たすべき役割
   運用しやすいシステム作りや、本稼動へのスムーズな移行のために、システムの設計段階からプロジェクトに参加して運用ドキュメントの標準化を進める
5. ソフトウェア開発における問題
   • 構成管理に起因しない問題
     システムテストにおいて、単体テストレベルのバグが多発して、開発が予定通り進捗しない
   • 構成管理に起因する問題
     • 開発者が定められた改版手続きに従わずにプログラムを修正したので、今まで動作していたプログラムが不正な動作をする
     • 仕様書、設計書及びプログラムの版数が対応付けられていないので、プログラム修正時にソースプログラムを解析しないと、修正すべきプログラムが特定できない
     • 一つのプログラムから多数の派生プログラムが作られているが、派生元のプログラム修正がすべての派生プログラムに反映されない
6. ソフトウェア開発プロジェクトで行う構成管理の対象項目
   プログラムのバージョン