情報第５講まとめの続きです
第２章
開発方法論p199-p225
１．システム導入プロジェクト
①FS（フィジビリティスタディ）…システム化全体計画が実現可能なものかを評価する
②プロジェクト組織
発注企業…エンドユーザーと情報システム部門
受注企業…システムインテグレータとITコンサルティングファーム
２．開発モデル
①ウォーターフォールモデル…後戻りをしない
計画⇒設計⇒プログラミング⇒テスト⇒運用と順に行うモデル
●プロジェクト管理がやりやすい
●柔軟性に欠ける
●大規模システムに向いている
②プロトタイプモデル…小規模な試作品を作り、顧客の合意を得ながら工程を進める
③スパイラルモデル…繰り返して開発する
●プログラムを小分けし、サブシステムごとにプログラムを作る
●プロジェクト管理はしづらい
●柔軟性がある
④RAD…タイムボックスを設け、繰り返しの開発を防ぐ
●エンドユーザーを含む少人数で開発（CASEツールなどの手法を用いる）
●迅速に開発
☆ドキュメントの設計図は管理と標準化が大切
３．開発アプローチ
①POA…業務プロセスに着目してシステムを設計する、DEDを使って表現する
②DOA…どんなデータが必要かを着目、データのモデリングを行う
③ODA…データと手続きに着目し分析・設計していく方法、UMLを使って分析・設計する、処理の対象（人に関連したもの）に着目し開発の生産を高める
１）カプセル化…処理手順を一体化する
２）インヘリタンス…オブジェクトの共通する性質を抽象化（クラス）
上位クラスで定義したデータや手続きを下位クラスに引き継ぐ
３）ポリモリフィズム…同じメッセージを送っても受け取るオブジェクトによっ て振舞いが異なる
４．モデリング技法
①DFD…設計図を図解して分かりやすくする
●業務プロセスとデータの流れが明らかになる
●時間的情報を表現するものでない
②E-Rモデル…データをモデル化すること、正規化するツール
●エンティティ（E）とリレーションシップ（R）の関係性を明確にする
●概念スキーマで用いられる
③UML(Unified Modeling Language)…オブジェクト指向のソフトウェア開発におけるプログラムの設計図の複合体
１）ユースケース図…業務システムの内容を単純明かに表現する、システムの振る舞いを表現する
２）クラス図…UMLにおいて静的な構造を示すクラス図はE-R図
３）オブジェクト図
４）シーケンス図…時系列で表現
５）ステートマシーン図…オブジェクトの状態遷移を記述アクティビティ図…業務手順を表現する
６）状態遷移図…画面設計などに用いられる（レイアウトではない）
５．プログラム設計…プログラムをモジュールという機能単位に分割する
分割基準
①データの流れに着目 １）STS分割 ２）TR分割
②データの構造に着目 １）ジャクソン法 ２）ワーニエ法
６．テスト方法
１）ホワイトボックステスト…内部構造に着目
①単体テスト…モジュールごとにテスト、終了後はビッグバンテスト
２）ブラックボックステスト…入力と出力に関するテストケースを設計
②結合テスト…モジュールを結合する １）トップダウンテスト、スタブを利用 ２）ボトムアップテスト、ドライバを利用 終了後は一斉テスト
②システムテスト…
③承認テスト…客にみてもらう
④運用テスト…ユーザーが主体となりテストをする
☆レグレッションテスト…修正によって、新たな不具合が生じないことをテストする
☆信頼度成長曲線（ゴンペルツ曲線）
７．レビュー…検証作業のこと
①ウォークスルー
②インスぺクション…ウォークスルーと異なる点はレビューに開発責任者（モデレーター）がいること
③ラウンドロビン…全体として作業を均一に分担しながらレビューを遂行する
８．システム移行
①レガシーマイグレーション…従来のシステムから新しいシステムに移行
９．CASE
開発支援ツール モデル技法を自動的に作ってくれたりする。
ミドルウェアの一種類
１０．リポジトリ
各開発公的に生産される成果物を、データ資源として一元的に管理するデータ資源管理データベースのこと
１１．アジャイル開発
従来の開発モデルと比べて迅速に客の要望に反映するようにするモデル
XPやRADなどの技法のこと
１）アジャイル開発プロセス
●４つの価値
①人と人同士の相互作用を重視（コミュニケーションを円滑に）
②動作するソフトウェアを重視する
③顧客との協調を重視
④変化の対応に重視
２）XP
●４つの価値
①単純さ
②コミュニケーション
③フィードバック
④勇気
●１２のプラクティス（完成レジュメのコピー）
☆適用可能性
１．プロジェクト規模が比較的小さい
２．顧客の要求が明確でなく、プロジェクト期間中に変更の可能性がある
３．明確な顧客が存在し、プロジェクトに積極的に参加することができる
第２章
開発方法論p199-p225
１．システム導入プロジェクト
①FS（フィジビリティスタディ）…システム化全体計画が実現可能なものかを評価する
②プロジェクト組織
発注企業…エンドユーザーと情報システム部門
受注企業…システムインテグレータとITコンサルティングファーム
２．開発モデル
①ウォーターフォールモデル…後戻りをしない
計画⇒設計⇒プログラミング⇒テスト⇒運用と順に行うモデル
●プロジェクト管理がやりやすい
●柔軟性に欠ける
●大規模システムに向いている
②プロトタイプモデル…小規模な試作品を作り、顧客の合意を得ながら工程を進める
③スパイラルモデル…繰り返して開発する
●プログラムを小分けし、サブシステムごとにプログラムを作る
●プロジェクト管理はしづらい
●柔軟性がある
④RAD…タイムボックスを設け、繰り返しの開発を防ぐ
●エンドユーザーを含む少人数で開発（CASEツールなどの手法を用いる）
●迅速に開発
☆ドキュメントの設計図は管理と標準化が大切
３．開発アプローチ
①POA…業務プロセスに着目してシステムを設計する、DEDを使って表現する
②DOA…どんなデータが必要かを着目、データのモデリングを行う
③ODA…データと手続きに着目し分析・設計していく方法、UMLを使って分析・設計する、処理の対象（人に関連したもの）に着目し開発の生産を高める
１）カプセル化…処理手順を一体化する
２）インヘリタンス…オブジェクトの共通する性質を抽象化（クラス）
上位クラスで定義したデータや手続きを下位クラスに引き継ぐ
３）ポリモリフィズム…同じメッセージを送っても受け取るオブジェクトによっ て振舞いが異なる
４．モデリング技法
①DFD…設計図を図解して分かりやすくする
●業務プロセスとデータの流れが明らかになる
●時間的情報を表現するものでない
②E-Rモデル…データをモデル化すること、正規化するツール
●エンティティ（E）とリレーションシップ（R）の関係性を明確にする
●概念スキーマで用いられる
③UML(Unified Modeling Language)…オブジェクト指向のソフトウェア開発におけるプログラムの設計図の複合体
１）ユースケース図…業務システムの内容を単純明かに表現する、システムの振る舞いを表現する
２）クラス図…UMLにおいて静的な構造を示すクラス図はE-R図
３）オブジェクト図
４）シーケンス図…時系列で表現
５）ステートマシーン図…オブジェクトの状態遷移を記述アクティビティ図…業務手順を表現する
６）状態遷移図…画面設計などに用いられる（レイアウトではない）
５．プログラム設計…プログラムをモジュールという機能単位に分割する
分割基準
①データの流れに着目 １）STS分割 ２）TR分割
②データの構造に着目 １）ジャクソン法 ２）ワーニエ法
６．テスト方法
１）ホワイトボックステスト…内部構造に着目
①単体テスト…モジュールごとにテスト、終了後はビッグバンテスト
２）ブラックボックステスト…入力と出力に関するテストケースを設計
②結合テスト…モジュールを結合する １）トップダウンテスト、スタブを利用 ２）ボトムアップテスト、ドライバを利用 終了後は一斉テスト
②システムテスト…
③承認テスト…客にみてもらう
④運用テスト…ユーザーが主体となりテストをする
☆レグレッションテスト…修正によって、新たな不具合が生じないことをテストする
☆信頼度成長曲線（ゴンペルツ曲線）
７．レビュー…検証作業のこと
①ウォークスルー
②インスぺクション…ウォークスルーと異なる点はレビューに開発責任者（モデレーター）がいること
③ラウンドロビン…全体として作業を均一に分担しながらレビューを遂行する
８．システム移行
①レガシーマイグレーション…従来のシステムから新しいシステムに移行
９．CASE
開発支援ツール モデル技法を自動的に作ってくれたりする。
ミドルウェアの一種類
１０．リポジトリ
各開発公的に生産される成果物を、データ資源として一元的に管理するデータ資源管理データベースのこと
１１．アジャイル開発
従来の開発モデルと比べて迅速に客の要望に反映するようにするモデル
XPやRADなどの技法のこと
１）アジャイル開発プロセス
●４つの価値
①人と人同士の相互作用を重視（コミュニケーションを円滑に）
②動作するソフトウェアを重視する
③顧客との協調を重視
④変化の対応に重視
２）XP
●４つの価値
①単純さ
②コミュニケーション
③フィードバック
④勇気
●１２のプラクティス（完成レジュメのコピー）
☆適用可能性
１．プロジェクト規模が比較的小さい
２．顧客の要求が明確でなく、プロジェクト期間中に変更の可能性がある
３．明確な顧客が存在し、プロジェクトに積極的に参加することができる