情報システム 〜ソフトウェア開発〜
ここから４〜５問出題される。基礎知識とここ以外は、出題範囲が読みづらいので、ここの開発は押さえておきたい。
[開発方法論]
開発モデル
・ウォーターフォールモデル ー 大規模に適したモデル。前の工程に後戻りしない
・プロトタイプモデル ー 比較的小規模開発に限定。試作品を作成してユーザが評価
・スパイラルモデル ー システムを複数のサブシステムに分け、基本となるサブシステムをまずウォーターフォールモデルの方法で開発してユーザに試用してもらい、その結果を反映させて次のサブシステムを開発するのを繰り返していくモデル
・RAD ー スパイラルモデルの発展系。エンドユーザを含む少人数のチームで担当し、開発期間を短縮する手法
・オフショア開発 ー システムの開発・運用管理などを海外にある企業や子会社へ委託すること
開発アプローチ
・POA（Prcess Oriented Approach） ー 業務処理プロセスに着目するアプローチ方法。各業務処理が何を入力として、どのように加工し、何を出力するのかに注目して分析・設計を行う。業務の流れをDFDを使って表現する
・DOA（Data Oriented Approach） ー どんなデータを必要とするかに着目するアプローチ方法。 E-Rモデルを使って分析・設計していく。「誰が利用するのか」を明確にすることがポイント
・OOA（Object Oriented Approach） ー データと手続き両方に着目して分析・設計していく方法。UMLを使って分析・設計する。学校の成績管理など。一部のソフトウェアの変更が周囲に及ぼす影響を最小限に抑えることができる
※オブジェクト＝データと手続きを一体化したもの
モデリング技法 ＝図式化
・DFD（データフローダイアグラム） ー システムの持つ機能（処理）とデータの流れを示す図式化技法。○がデータの処理、＝がファイルやデータベースを表す
・E-Rモデル ー 実態と関連に分けて表現する図式が技法。３層スキーマのうちの概念スキーマで利用される
・UML ー オブジェクト志向のソフトウェア開発におけるプログラム設計図の統一表記法。表記法に過ぎず、開発手法ではない。開発モデルは限定しない
①ユースケース図 ー システムがどのように機能するかを表す図
②シーケンス図 ー メッセージのやりとりを時系列に並べた図
③コミュニケーション図 ー オブジェクト同士の相互作用を表現するための図
ユーザ情報入力→
メールユーザ ーーーーーーーーユーザ登録画面
←登録結果表示
④アクティビティ図 ー 「オブジェクトがどのような処理をするか」といった作業プロセスを視覚的に表現した図
メール確認をする → 新着メールあり → 返事を書く → 内容確認して削除
テスト方法
・テストケースの設計（入力値と期待される出力値のペアをテストケースという）
①ホワイトボックステスト ー 単体テスト。プログラムの内部構造に着目
②ブラックボックステスト ー 結合テスト以降。プログラムの外部構造に着目。「どのような入力を与えられたらどのような結果が得られるか」
・レグレッションテスト（回帰テスト） ー 機能の修正が今まで正常に動作していた他の機能に影響を与えていないことを検証する
レビュー
①ウォークスルー ー 各フェーズの終了時点で作成者と複数の開発者が設計書を評価・検証するレビュー
②インスペクション（査閲） ー ウォークスルーよりも厳格。開発責任者が進行する会議
ワンポイント用語
・CASEツール ー システム開発を支援するツール。それぞれの行程で作成したデータを記録蓄積したり、リポジトリを使って行程全体を一貫して一元管理するため、整合性の検証や、保守・変更時の影響範囲の確認などを効率的に行うことができる
・リポジトリ ー 各開発行程に生産される成果物を、データ資源として一元的に管理するデータ資源管理データベースのこと
アジャイル開発
比較的小規模。ウォーターフォール型とは対極をなす
・４つの価値
①プロセスやツールより人と人同士の相互作用を重視する
②包括的なドキュメントより動作するソフトウェアを重視する
③契約上の交渉よりも顧客との協調を重視する
④計画に従うことよりも変化に対応することを重視する
①XP（エクストリームプログラミング） ー アジャイル開発の先駆け。コーディングとテストを重視。単純さ、コミュニケーション、フィードバック、勇気の４つの価値を重視した開発手法。プラクティスが１９ある
②スクラム ー 要求変化や技術変化など、予測が難しいプロジェクトの運営に適した手法。ラウンドトリップ・エンジニアリングの手法を取り入れている
③FDD（ユーザ機能駆動型開発） ー ユーザにとっての機能価値（フィーチャ）を基本単位として開発を進める
[開発管理]
プロジェクト推進のための知識体系
①アメリカのPMIが提唱する、プロジェクトマネジメントのためのフレームワーク
②ISO10006のベース
③５つのプロセス群（立ち上げ群や計画群、実行群など）および１０の知識領域。
④QCDの視点
⑤テーラリング（そのまま使うのではなく、ここのプロセスに合わせて変更して使う）
・BABOK
①ビジネス分析のための知識体系
②６つの知識エリア、４つの要求
③知識エリアの実行順は規定されていない
プロジェクト計画立案技法
・WBS（Work Breakdown Structure） ー プロジェクトの目標達成に必要な「作業項目」をトップダウン的に階層構造で表現したもの。ガントチャートは進捗管理
ソフトウェア開発見積もり技法
・COCOMO ー 開発形態や規模に応じたモデル式によって、ソフトウェア開発の行程や期間を推定する
・ファンクションポイント法 ー 機能（ファンクション）に基づいて見積もる。
①開発初期から採用可
②工数に依存しない
③ユーザの理解を得やすい
上流工程推進のための方法論
・非機能要求グレード ー システムが実現する業務機能以外の要求。稼働率や障害対策など。可用性や性能・拡張性、運用・保守性など６つの項目がある
プロジェクト組織のプロセス成熟度評価技法
・CMM（能力成熟度モデル） ー ベンダーの組織およびプロジェクトのプロセス改善の成熟度を定量的に表すモデル
CMMI ー ベンダーの管理・能力指標（レベル１〜５）
COBIT ー ユーザ企業のIT運用管理（レベル０〜５）
ソフトウェア開発関連の規格
・ソフトウェア製品の品質
①機能性 ー 合致する機能を提供
②信頼性 ー 指定された達成水準を維持する能力
③使用性 ー 理解・習得・利用でき、利用者にとって魅力的である能力
④効率性 ー 使用する資源の量に対比して適切な性能を提供
⑤保守性 ー 修正のしやすさ
⑥移植性 ー 他の環境に移すための能力
ん〜、これだけあっても２、３問しか出ないこともあるから効率悪いな〜。
情報技術に関する基礎知識を確実に頭に入れるのが先決か。
