# Chapter14-2「システムの開発手法」

## 7/5(月)

###### tags:`基本情報技術`

さつき：
* ウォーターフォールモデル
* 基本的に一方通行
* 工程ごとにすっぱり分かれている
* 遅延を把握しやすい
* 大規模開発に向いている
* 手戻りを想定していないため、認識がちがっていると大変
* プロトタイピングモデル
* 開発初期の段階でプロトタイプを作り、利用者に確認してもらう
* 作る手間はある。大規模開発にはむかない
* スパイラルモデル
* システムを複数のサブシステムに分割して、それぞれのサブシステムごとに開発を進めていく手法
* サブシステムに対する利用者の声は、次のサブシステムに反映されていく
* レビュー
* 開発作業の各工程で、その工程完了時にレビューを行う
* CASEツール
* 上流CASEツール...DFD、ER図などの作成ツール
* 下流CASEツール...プログラムの自動生成ツール、テスト支援ツール
* 保守CASEツール...リエンジニアリング機能
* 過去問
* 問1:OK。今の現場はプロトタイピングモデル、次の現場はウォーターフォールだな～。
* 問2: [リバースエンジニアリング](https://e-words.jp/w/%E3%83%AA%E3%83%90%E3%83%BC%E3%82%B9%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0.html)

にわ：
- 読み込み
* システムの開発手法にはいろいろある
* ウォーターフォールモデル
* 順番通りにやってく。基本手戻りしない。工程管理がしやすいので大規模開発に向いてる。
* プロトタイピングモデル
* 開発初期段階でプロトタイプを作ってユーザーに確認してもらう。プロトタイプ作るのも手間かかるので小規模開発に向いてる。
* スパイラルモデル
* システムを複数のサブシステムに分けてそれぞれ開発していく。個々のサブシステムではウォーターフォールで進める。
* サブシステムA開発→確認→サブシステムB開発→確認→…と進められるのでウォーターフォールとプロトタイピングのいいとこ取り的な感じ。
* レビュー手法
* ウォークスルー：開発者主体で行う
* インスペクション：第３者であるモデレータがレビュー責任者を務める。基本的にレビューと言ったらこれ。
* https://www.itmedia.co.jp/im/articles/1111/07/news208.html
* ラウンドロビン：参加者全員が持ち回りでレビュー責任者を務める。
* CASEツール
* システム開発を支援するツール。ER図作成ツールやテスト支援ツールなど。
* 上流、下流、保守と各工程で各種ツールがあるが、例えば保守CASEツールは既存プログラムの仕様を解析して設計を探る「リバースエンジニアリング」で使うもの、など。
- 過去問
* 問１：OK
* 問2：OK

まい：

* システム開発は規模や種類に応じて色んなやり方がある
* ウォーターフォールモデル
* それぞれの工程を完了させてから次に進む
* 管理がしやすい、大規模開発などで広く使われる
* 利用者がシステムを確認できるのは最終段階に入ってからなので、思ってたのと違うとなったらやばい
* プロトタイピングモデル
* 開発初期の段階でプロトタイプを作って、利用者に確認してもらう
* プロトタイプを作るのも手間がかかるので大規模システム開発には向かない
* スパイラルモデル
* システムを複数のサブシステムに分割し、完成したサブシステムに対する利用者の声を次のサブシステムに反映していく
* すべての機能の品質が保証されればシステム全体が一挙にリリース
* アジャイル/ １つの機能の開発が完了し、品質が保証された段階で、その都度リリース
* レビュー
* 工程の完了ごとに成果物を検証し問題発見に努める
* デザインレビュー、コードレビュー
* CASEツール (Computer Aided Software Engineering)
* 上級CASEツール/ E-R図の作成ツールなど
* 下流CASEツール/ プログラム自動生成ツール、テスト支援ツールなど
* 保守CASEツール
* リバースエンジニアリング/ コードを解析し、プログラムの仕様と設計情報を取り出す手法、通常手順と逆だから
* リポジトリで開発情報を一元管理

* 練習問題
* 問1
* 問2