ソフトウェアライフサイクル
Plan, Do, Seeの三つのフェーズに関する計画
ウォーターフォールモデル
ソフトウェアに対して、工程順に開発を進める開発手法。工程間の平衡作業ができない
プロトタイプモデル
開発の早い段階で作成したプロトタイプをユーザーに試してもらい、ユーザーの要求に合うように修正を繰り返しながら開発する手法
スパイラルモデル
対象システムを独立性の高いいくつかの部分に分割し、部分ごとに一連の開発工程を繰り返しながら、徐々にシステムの完成度を高めていく手法。小規模開発を先行させ、その評価を皇族の開発に生かすことで開発コスト増加などのリスクを最小にしつつ開発を行う
インクリメンタルモデル
定義された要求を全部一度に実現するのではなく、いくつかの部分に分けて、順次、段階的に開発し提供していくモデル。例えば最初にコア部分を開発し、順次機能を追加していく場合に適している。
進化的モデル
システムへの要求に不明確な部分があったり、要求変更の可能性が高いことを前提としたモデル
アジャイル開発
ソフトウェアに対する要求の変化やビジネス目標の変化に迅速かつ柔軟に対応できるよう、短い期間単位で、計画、実行、評価を繰り返す反復（イテレーション）型の開発手法。
スクラム
アジャイル開発のアプローチの一つ。開発チームに適用されるプロダクト管理のフレームワーク。反復の単位をスプリントと呼ぶ
スプリントプランニング
スプリントの開始に先立って行われるミーティング。プロダクトバックログの中からプロダクトオーナが順位に従って、見積もりを行う
デイリースクラム
朝会のように、毎日決まった場所。時刻で行う短いミーティング
スプリントレビュー
スプリントの最後に成果物をデモンストレーションし、リリースの可否をプロダクトオーナが判断する
スプリントレトロスペクティブ
スプリントの振り返りを実施し、次のスプリントに向けての改善を図る
プロダクトバックログ
今後のリリースで実装するプロダクトの機能をユーザーストーリー形式で記述したリスト
XP
eXtreme Programming：アジャイル開発における手法やマネジメントの経験則をまとめたもの。対象者である「共同、開発、管理者、顧客」の四つの立場ごとに全部で19の具体的な実践手法が定義されている
ペアプログラミング
2人のプログラマがペアとなり、その場で相談したりレビューしながら一つのプログラム開発を行う
テスト駆動開発
最初にテストケースを設計し、必要最低限の実装を行った後、コードを洗練させる
リファクタリング
完成済みのプログラムも随時相良し、保守性の高いプログラムに書き直す
継続的インテグレーション
コードの結合とテストを継続的に繰り返す
YAGNI
You Aren't Going to Need it：今必要なことだけをする。将来を見据えた機能の追加を避ける
リーンソフトウェア開発
製造業の現場から生まれた無駄のない生産方式の考え方をソフトウェアに適用した開発手法
プラットフォーム開発
組み込み機器の設計・開発において、複数の異なる機器に共通して利用できる部分を最初に設計・開発し、それを土台として機器ごとに異なる機能を開発する
MDA
モデル駆動型アーキテクチャ：システムをプラットフォームに依存する部分と依存しない部分とに分けてモデル化する
コンカレントエンジニアリング
同時実行が可能な工程を平衡して進めることで、開発期間の短縮を図ること
コデザイン
開発の早期にハードウェアとソフトウェアを同時に設計すること
リエンジニアリング
既存のソフトウェアを利用して新しいソフトウェアを作製するための技術
リバースエンジニアリング
既存のソフトウェアからそのソフトウェアの仕様を持ちびき出す技術
フォワードエンジニアリング
新規ソフトウェアに合うように修正・変更し、それを基に新規ソフトウェアを構築する
V字モデル
設計とテストとを対応させたもの
CMMI
W.ハンフリーによって提唱。能力成熟度モデル結合と呼ばれ、ソフトウェアを開発・保守する組織の作業の在り方を示したモデル。5段階で管理される
構造化分析法
SA：システム機能間のデータの流れに注目して、開発の対象となるシステムの要求を仕様化する技法
DFD
業務を構成する処理と、その間で受け渡されるデータの流れを3つの要素（プロセス、源泉と吸収、データストア）及び、データフローを用いて図式表現したもの
コンテキストダイアグラム
一つだけのプロセスが記述された最上位のDFD
DFDの作成順
現物理モデル→現論理モデル→新論理モデル→新物理モデル
データディクショナリ（データ辞書）
階層化された全てのDFD中にある、データフローで示されたデータと、データストアを構成するデータ内容を定義したもの
ミニスペック（ミニ仕様書）
最終的に詳細化された基本的なプロセス、再開のDFDの機能仕様書
プロセス中心設計
データの設計に先行してプロセスを設計士、プロセスに合わせて必要なデータを設計する手法
データ中心設計
データ設計を先行して行う手法
CRUDマトリクス
データがどのプロセスによって、Create, Read, Update, Deleteされるかをマトリクス形式で表した図
事象応答分析
外部型の事象とその事象に応答するタイミングなどを時間的な関係の抽出を行い、制御の流れを分析すること
状態遷移図
時間の経過や状況の変化に応じて状態が変わるようなシステムの動作を記述するときに用いられる図式化技法
ペトリネット図
平衡動作する機能同士の同期を表現することができる図式化技法。トランジション（事象）とプレース（状態）によって表現し、トークン（印）の推移と発火によって記述される
システム開発プロジェクトのライフサイクル
こ
カプセル化
データとそれを操作する手続きを一体化して、オブジェクトの実装の詳細をオブジェクトの内部に隠ぺいすることを
クラス
いくつかの類似オブジェクトに共通する性質を抜き出し、属性やメソッドを一般化して新たに定義したもの。
インスタンス
クラスの使用宣言をしてはじめて実体が生成され、その実態のこと（具体的な値を持ったオブジェクト）
インヘリタンス
上位クラスの属性やメソッドを下位クラスが継承すること
is-a関係
汎化ー特化関係：動物と人間、犬など
part-of関係
集約－分解関係：車とタイヤ、エンジン、ボディなど
ポリモーフィズム
同じメッセージを送ってもオブジェクトごとに異なる動作が行われる特性
オーバーロード
同一クラス内に、メソッドが同一であって、引数の型、個数または並び順が異なる複数のメソッドを定義すること
UML
Unified Modeling Language：オブジェクト指向分析・設計で用いられるモデリング言語
クラス図（システム領域に存在するクラスとの関連を表す図）
シーケンス図（オブジェクト間の相互作用を時間軸に沿って表す図）
ユースケース図
機能（ユースケース）と利用者（アクタ）との相互作用を表す
ステートマシン図
オブジェクトの状態遷移の図
アクティビティ図
システムやユースケースの動作の流れを表す
データの流れに着目したモジュール分割技法（3つ）
STS分割、TR分割、共通機能分割
データの構造に着目した分割技法（2つ）
ジャクソン法、ワーニエ法
STS分割
Source, Translate, Sink, （源泉、変換、吸収）の三つのモジュールに分解
最大抽象入力点
入力とは言えない点まで抽象化された地点
最大抽象出力点
はじめて出力データといえる形をあた和下天
TR分割
トランザクション分割：入力トランザクションの種類により、実行する処理が異なる場合には有効な分割技法。
TR分割におけるプログラムの３つの分割
トランザクションを、入力するモジュール、属性ごとに振り分けるモジュール、処理モジュール
ジャクソン法
ワーニエ法
モジュール結合の６つの種類（強い順）
内容結合＞共通結合＞外部結合＞制御結合＞スタンプ結合＞データ結合
データ結合
相手モジュールをブラックボックスとして扱い、必要なデータだけを引数として渡す
モジュール強度（モジュール内の構成要素間の関連性の強さ：強い順）
暗号的強度＞論理的強度＞時間的強度＞手順的強度＞連絡的強度＞情報的強度＞機能的強度
コード設計
ブラックボックステスト
プログラムの内部構造や論理構造には一切着目せず、プログラムの外部使用に基づくテストケースを作製し、正しい出力が得られるかどうかに着網したテスト
同値分析
テスト対象となる、プログラムへの入力データを、同じ特性を持つい来るかのクラスに分割し、各クラスを代表する値をテストデータとする方法
限界値分析
それぞれのクラスの境界値をデータとして設定する。
原因結果グラフ
実験計画法
検証項目の組み合わせによるテストケースの数が膨大になる場合に有効なテストケース設計法。直交表を用いる
ホワイトボックステスト
プログラムの内部論理の正当性の検証を行うテスト
命令網羅
全ての命令を少なくとも一回は実行するようにテストケースを設計
判定条件網羅
結果が真になる場合と偽になる場合の両方がテストされるようにテストケースを設計
条件網羅
判定条件が複数条件である場合に採用する方法。
複数条件網羅
判定条件を構成する各条件の起こりうる真と偽の組み合わせと、それに伴う判定条件を網羅する
制御パステスト
プログラムの処理経路を網羅的に実行し、正しく動作しているかを検証
フローグラフ
プログラムを連続した逐次命令群と、分岐命令に分け、それぞれをノードとして処理の順にノードを結んだもの
サイクロマチック数
フローグラフから得られるすべての経路の数（N=E-V+2）
モジュール集積テスト技法
増加テストと非増加テストがある。結合テストを進めるための技法
増加テスト
ボトムアップテストとトップダウンテスト、折衷テストがある
ボトムアップテスト
下位のモジュールから上位のモジュールへと順にモジュールを結合しながらテストを行う。未完成の上位モジュールの代わりにドライバを用いる
トップダウンテスト
ボトムアップテストの逆。未完成の下位モジュールの代わりに、スタブを用いる
デシジョンテーブル
その他のテスト種類
α：テスト初期でバグが発生→プログラムの質が悪い。β：テストの中盤でもバグがない→テストの質が悪い。解決困難なバグに直面した
信頼度成長曲線
横軸にテスト時間、あるいはテスト消化件数をとり、縦軸にはバグの累積個数をとったもの
バグ埋め込み法
あたかじめ既知のバグをプログラムに埋め込んで、その存在を知らない検査グループがテストを行い、洗剤バグ数を推定
二段階エディット法
完全に独立した二つのテストグループが、テストケースやテストデータをそれぞれのグループで用意し、一定時間平衡してテストを行う
レビュー
成果物の問題点やあいまいな点、あるいは成果物としての妥当性を検証
承認レビュー
成果物の内容を審査してのレビュー
成果物レビュー
成果物の問題点を早期に発見し、品質向上を図る
ウォークスルー
レビュー対象物の作成者が説明者になり行われるレビュー
ピアレビュー
同僚や専門家仲間と行う
IV＆V
Independent Verification and Validation：ソフトウェア開発組織や開発委託組織から独立した組織の指導と管理に基づいて、V&Vを実施すること。そのV&Vを主導する組織をいう場合もある。 システムやソフトウェアの品質保証を行うことを考えたとき、開発を行った当事者がいくらテストやレビューを行ってもそれが組織内部の活動である限り、客観的な証拠にはならない。IV&Vは、開発組織とは技術面・管理面・財政面で独立した組織がV&V活動の作業や方法を定め、開発組織に義務付けることによってV&V活動の客観性を保証することをいう
インスペクション
作業成果物の作成者以外の参加者がモデレータとして会議の進行を取り仕切り行われるレビュー
ラウンドロビン
レビュー参加者が持ち回りでレビュー責任者を務めながら、全体としてレビューを遂行していくレビュー技法
バスアラウンド
レビュー対象となる成果物を複数のレビュアーに個別にレビューしてもらう方法
デザインレビュー
検証対象である成果物が設計仕様書であるレビュー
形式手法
論理学や離散数学を基礎とした形式的な仕様記述とモデル検証によって品質を確保しようとするもの
9章の内容をまとめたものです