ソフトウェアサイクルを合意プロセス、テクニカルプロセス、運用•サービスプロセス、支援プロセスなどのプロセス群に分けて、それぞれの作業内容を定めている。

ISO/IEC12207に対応する「ソフトウェアサイクルプロセス」の規格。 合意プロセス、組織のプロジェクトイネーブリングプロセス、テクニカルマネジメントプロセス、テクニカルプロセスの4つに分類。

各工程の終了基準を前もって明確に定義しておき、その基準を達成しない場合は次の工程に進まない。原則として前の工程には戻らない。

独立性の高い部分ごとに要件定義、設計、プログラミング、テストというプロセスを、「目的、代替案、制約の決定」「代替案の評価とリスクの明確化、解消」「開発と検証」「次サイクルの検討」のフェーズを繰り返しながら進める技法。

確定している要求を段階的に開発する方式で、事前に計画された製品改善モデルとも呼ばれる。

要求に不明確な部分があるために最初に要求の定義ができない場合に用いられる方式で、部分的に定義された要求を開発し、要求を洗練させる。

要件定義の段階で試作品を作成し、その結果を以降の開発工程に反映させる開発手法である。ユーザー要求の明確化や仕様の実現性評価を目的として、各種開発手法の中で採用される。

固定の期間中に、そのチームが達成できる要求のボリュームと作業量なこと。

プロダクトとして実現したいことを優先順位付けしてリストにしたもの。

顧客の要求であるユーザーストーリーを見積もるための単位

反復しながら開発を進める開発サイクル単位。スクラムではスプリントという。

未実現の機能や作業を時間軸に沿って折れ線グラフ化したもので、進捗を把握できる。

開発の初期段階の設計よりもコーディングとテストを重視し、各工程を順番に積み上げていくことよりも、常にフィードバックを行なって修正と再設計していくことを重視する。

プログラミングを2人1組で行い、片方が書いたコードを片方がチェックするという作業を交代しながら進める。

短い期間ごとにリリースを繰り返すこと。

まずテストを作成し、そのテストに合格するように実装を進めること。

バグがなくても、コードの効率や保守性を改善していくこと

日本の自動車製造におけるムダを省いた方式をソフトウェア開発に適用したもの。 「ムダをなくす」「品質を作り込む」「知識を作り出す」「決定を遅らせる」「早く提供する」「人を尊重する」「全体を最適化する」

スプリントという短い開発期間を設定し、透明性と検査、適応によって、経験に基づいた最適化をすすめながら、各スプリントの中で選択した機能を開発していく。

各スプリントの最後で実施する振り返り。

業務の中で取り扱われるデータそのものは比較的変化が少ない点に着目し、抽象データ型から構成されるデータ基盤を事前に構築して、そのデータ基盤上にビジネスプロセスを構築していく技法。

システムを構築する機能に着目し、機能ごとのモジュール分割を行って機能の階層構造化を図るとともに、構造化プログラミングを実施して品質を向上させる技法。

機能とデータが一体化したものをシステムの構成要素として捉え、識別したものを再利用可能なコンポーネントとして開発していく技法。

幾つかのクラスに共通する性質を持つクラスを定義すること

あるクラスを基に幾つかの性質を付加して新しいクラスを定義すること

ユースケース図やユースケースの詳細な記述で表された要求モデルを入力として、ユースケースのクラスをバウンダリクラス、コントロールクラス、エンティティクラスの3つに分けて分析し、クラス間の関連を定義する図を作成する。

システムで意図しない誤操作や正しくないデータが入力されないようにする信頼性設計技法のこと。

システムの一部に故障や異常が発生したとき、その影響が安全な方向に働くように、システムの信頼性を追求する耐障害設計の考え方。

システムの一部が故障した時に、故障を起こした装置や部分を切り離して、処理能力を落としてもシステムの全面停止を回避するという高信頼化設計技法。

冗長構成を講じることによって、システムが部分的に故障してもシステム全体として必要な機能を維持できるようにする高信頼化設計技法。

通常の開発作業とは逆にプログラムのソースコードから設計仕様などを導き出す技術のこと。

リバースエンジニアリングによって現行システムの上流開発工程の成果物を再生産し、その仕様を修正して新システムを構築する。

各手続きの構造を明確に、整理された形で（構造化定理に基づいて）記述する手法。

再利用を前提としたソフトウェア部品であるコンポーネントを組み合わせる事でシステムを構築する手法。

各機能を表すアイコンを画面上で並べるなど、視覚的な操作によってプログラム作成を支援する手法。

個々の利用者に提供するサービスを実現する機能単位の集まりととらえ、利用者や業務上から要求されるサービスを設計するという、大規模な情報システムの開発の考え方。サービス間の関係は疎結合で設計する。

複数の異なるコンテンツ（サービス）を取り込み、それらを組み合わせて利用し、新しいコンテンツ（サービス）を作成する手法を総称した言葉。

プログラム内部のロジックに基づいてテストケースを設計する技法。

ホワイトボックステストで、全ての命令を最低1回は実行させるテスト。

ホワイトボックステストで、各判定を少なくとも1回はとらせるテスト。

ホワイトボックステストで、判定条件中のすべての条件で、真と偽を少なくとも1回はとらせるテスト。

機能仕様に基づいて、入力とその結果に着目してテストケースを設計する技法。

ブラックボックステストで、正常処理となる入力値と異常処理となる入力値に分割して、それぞれの代表値を用意するテスト。

ブラックボックステストで、正常と異常の境界付近の値をテストケースとして採用するテスト。

故意に埋め込んだエラーもソフトウェアに潜在していたエラーも、同じ比率で発見されることを前提とした、ソフトウェアの残存エラー数を推定する方法。

直公表によるテストケースの作成条件を緩和した技法で、2因子間の取り得る値の組み合わせが同一回数でなくても、1回以上存在すればよいとしてテストケースを設計する技法。

プロジェクトメンバーがn人の場合、コミュニケーションチャネル数は、プロジェクトメンバーのうちから、任意の2人を選ぶ組み合わせの数だけ存在する。式は？

開発生産性の式は？

全体の生産性を表す式は？