対応するシラバスの範囲（応用情報技術者試験シラバス Ver.7.2）：大分類「開発技術」（中分類12「システム開発技術」、中分類13「ソフトウェア開発管理技術」）
一言で言うと
- 開発プロセス、DFDやUMLによる分析・設計、モジュール設計、テストとレビューの手法（計算問題あり）
覚え方の軸
開発プロセス・手法
- 開発モデルは「1回で流す」か「分けて繰り返す」かで分ける
- アジャイルの3つの流派は「何をまとめたものか」で分ける
- 再利用は「さかのぼって仕様を取り出す → 前へ作り直す」
- V字モデルは「左の設計と、同じ高さの右のテストが対になる」
- CMMIの5段階は「場当たり → 繰り返せる → 標準がある → 数字で予測できる → 改善し続ける」
分析・設計手法
- 3つの項は「何に注目するか」で分かれる
- DFDは「4つの記号＋1つのルール」
- モデル化の順番は「物理 → 論理 → 論理 → 物理」のサンドイッチ
- データは変わりにくく、処理は変わりやすい
- 事象応答分析の図は「1つずつ順番か、並行か」で使い分ける
オブジェクト指向設計
- オブジェクト＝「データ（属性）＋処理（メソッド）」のセット
- クラスは「型紙」、インスタンスは「型紙から作った実物」
- クラスどうしの関係は2つだけ
- 「オーバー○○」は2つ
- UMLの図は「形（構造）」と「動き（振る舞い）」に分ける
モジュール設計
- 分割技法は「データの流れ」か「データの構造」かで2つに分かれる
- 評価の物差しは2つで、向きが逆
- 一番良いものと一番悪いものを押さえる
- 橋渡しの1組
- 領域評価は「制御領域 ≧ 影響領域」なら良い
テスト
- テストケースの作り方は「中を見るか、見ないか」の2つ
- ブラックボックスの4つは「何を工夫するか」で分ける
- ホワイトボックスの網羅は「判定（分岐の結果）」と「条件（判定の中の部品）」のどちらを真偽にするか
- 結合テストは「どっちから積むか」で、代わりの部品が決まる
- その他のテスト（システム結合テストなど）は、V字モデルの右側に並ぶ
テスト管理手法
- 順調なテストでは、バグの累積数は「S字」になる
- S字から外れたら、どちらにずれたかで原因を読む
- バグ数の推測は「割合が同じ」と仮定した比例の式
レビュー
- レビューの目的は2つ
- ピアレビューの手法は「誰が仕切るか、集まるか」で分ける
- 上流のミスほど、直すのが高くつく
ページ一覧
| テーマ | 何の話か |
|---|---|
| 開発プロセス・手法 | どんな段取りで作るか（ウォータフォール、アジャイルなど）、再利用、共通フレームとV字モデル、組織の実力を測るCMMI |
| 分析・設計手法 | DFDでデータの流れを図にし、データ中心で設計し、状態遷移図やペトリネット図で事象と時間を表す |
| オブジェクト指向設計 | データと処理をまとめたオブジェクトで作る（カプセル化、継承、ポリモーフィズム）。設計図はUML |
| モジュール設計 | プログラムを分け（STS、TR、ジャクソン法など）、結合度は弱く、強度は強くなっているかで評価する |
| テスト | ブラックボックス（同値・限界値）とホワイトボックス（網羅、サイクロマチック数）でテストケースを作り、ドライバやスタブを使って結合する（計算あり） |
| テスト管理手法 | バグ累積数のS字曲線で品質を読み、バグ埋込み法や2段階エディット法で残りのバグ数を推測する（計算あり） |
| レビュー | 設計書やプログラムを人の目で早めに確かめる（ウォークスルー、インスペクションなど）。数学で確かめるのが形式手法 |