このページでは、ウォータフォールやスパイラルなどの開発モデル、スクラムとXP、リエンジニアリング、共通フレームとV字モデル、CMMIの5段階がわかります。
- 一言で言うと：
- システムを「どんな段取りで作るか」の型（開発モデル、アジャイル）と、作り方を楽にする工夫（再利用、ローコード）、公式の工程表（共通フレーム）、組織の開発力を測る物差し（CMMI）の話
開発の型を選ぶ → 短く回す型（アジャイル）→ 機器向けの作り方（組込み）→ なるべく作らずに済ませる（再利用・ローコード）→ 公式の工程表（共通フレーム）→ 組織の実力を測る（CMMI）
覚え方の軸
- 開発モデルは「1回で流す」か「分けて繰り返す」かで分ける
- 1回で流すのがウォータフォール。試作で確かめるのがプロトタイプ
- 分けて繰り返す3つは、何を前提に分けるかで見分ける
- 要求は最初に全部決まっているのがインクリメンタル、要求があいまい・変わるのが進化的、繰り返すたびにリスクやコストを評価するのがスパイラル
- アジャイルの3つの流派は「何をまとめたものか」で分ける
- スクラムはチームの進め方（4つのイベント）
- XPはプログラマの実践手法（ペアプロ、テスト駆動、リファクタリングなど）
- リーンはムダをなくす考え方（七つの原則）
- 再利用は「さかのぼって仕様を取り出す → 前へ作り直す」
- リバースエンジニアリング → フォワードエンジニアリング（合わせてリエンジニアリング）
- V字モデルは「左の設計と、同じ高さの右のテストが対になる」
- 要件定義 ⇔ 適格性確認テスト、方式設計 ⇔ 結合テスト、詳細設計 ⇔ ユニットのテスト
- 上の段がシステム、下の段がソフトウェア
- CMMIの5段階は「場当たり → 繰り返せる → 標準がある → 数字で予測できる → 改善し続ける」
ソフトウェア開発モデル：どんな段取りで作るか
- ソフトウェアライフサイクル（SLC）：
- 情報システムが、計画されて、作られて、使われて、最後に捨てられて次の計画につながる、一生の流れ
- 計画（Plan）・開発（Do）・運用・保守（See）の3つのフェーズ
- 例えば、車なら、買う計画 → 買う → 乗りながら修理 → 直しきれなくなったら買い替え
- ライフサイクル全般のガイドライン：
- ライフサイクル全般で必要な作業を包括的に決めたガイドラインに、共通フレームがある
- DevOps（参考、★）：
- 開発（Dev）と運用（Ops）を合わせた言葉
- 開発側と運用側が互いに連携して、素早く柔軟に開発したり、サービスを改善したりする取組み
- ソフトウェア開発モデル（プロセスモデルともいう）：
- 「要求の定義（要件定義）→ 設計 → プログラミング → テスト」という開発工程を標準化して、1つのモデルにしたもの
- システムの規模や開発期間などによって、いろいろな型がある
| モデル | 進め方 | 長所 | 短所・向いている場面 |
|---|---|---|---|
| ウォータフォール | 要件定義 → 外部設計 → 内部設計 → プログラム設計 → プログラミング → テストを、滝のように上から下へ1回で流す | 前の工程の成果物をもとに進めるので、開発作業の一貫性が保てる | 上流の不具合が下流に広がる。工程を並行できない。後戻りを許さないので、仕様変更に弱い |
| プロトタイプ | 早い段階で試作品をユーザに試してもらい、修正を繰り返す | 早い段階で要求のあいまいさがなくなり、後の仕様変更が減る | ユーザ部門と開発部門の意見が食い違って調整に手間取ると、かえって時間とコストが増える |
| スパイラル | 独立性の高い部分に分け、部分ごとに開発工程を繰り返しながら完成度を上げる。繰り返すたびにコストなどを評価する | 小さな開発を先にやり、その評価を後に生かすので、コスト増などのリスクを最小にできる | − |
| インクリメンタル | 要求を最初に全部定義し、いくつかに分けて順番に開発・提供する（並行もある） | 全部の機能がそろわなくても、最初のリリースから動作を確認できる | コア部分を先に作り、機能を足していく場合に向く |
| 進化的 | 要求があいまい・変わりやすいことを前提に、繰り返しながら要求を洗練していく | 要求変更に、新しいサイクルで対応できる | − |
- ウォータフォールモデル：
- 工程の順番に、滝（ウォータフォール）が上流から下流へ流れるように進める
- 「後戻りを許さない」は、実際には「後戻りに制限を設けている」という意味
- 例えば、設計図を全部決めてから家を建てる。建て始めてから間取りを変えるのは大変
- プロトタイプモデル：
- 例えば、服の試着。着てみて「袖が長い」とわかれば、作る前に直せる
- プロトタイプ：
- 外部設計の有効性、仕様の漏れ、実現できるかなどを評価して、手戻りを防ぐために作る試作品
- モックアップ：
- 見た目だけを確認するための試作品
- スパイラルモデル：
- 例えば、まず小さな店を1つ出して、売上やコストを確かめてから次の店を出す
- インクリメンタルモデル：
- 段階的モデルの一つ
- 開発の順番は決まっていて、時期をずらして順番に開発する
- 例えば、間取りが決まった家を、1階から順に完成させて住み始める
- 進化的モデル：
- 要求を分けて順に実現するところは段階的モデルに似ている
- 違いは、要求に不明確な部分や変更の可能性があることを前提にしている点
- 例えば、住みながら「ここに棚がほしい」とわかったら、そのたびに増改築する
- 要求変更への対応の違い：
- ウォータフォールモデルでは、保守工程で対応する
- 進化的モデルでは、新しいサイクルで対応する
アジャイル型開発：短く回して、変化にすばやく対応する（★試験によく出る）
- アジャイル型開発：
- 要求やビジネス目標の変化に、すばやく柔軟に対応するための反復型の開発手法
- 短い期間（一般に1週間〜1か月）ごとに「計画、実行、評価」を繰り返す
- イテレーション：
- アジャイルでの反復（1回のサイクル）
- 繰り返すことで、使える機能を段階的・継続的にリリースする
- 顧客の要求とのずれなどの問題やリスクを、短いサイクルで見つけて解消できる
- ふりかえり（レトロスペクティブ）：
- 各イテレーションの最後に、チーム全員で実施事項を振り返り、次に向けて改善する
- 超短期リリースを成功させるために欠かせない
① スクラム：チームの進め方のフレームワーク
- スクラム：
- アジャイル開発のアプローチの1つ
- 開発チームに適用する、プロダクト管理のフレームワーク
- スプリント内の開発の進め方は、「テスト駆動」が基本
- スプリント：
- スクラムでの反復の単位
- 4つのイベントと開発作業でできている
- スプリントの長さ：
- 1〜4週間の時間枠（タイムボックス）
- どのスプリントも期間は同じで、延長されることはない
- プロダクトインクリメント：
- スプリントの期間内に開発チームが作り出す、リリースを判断できる成果
| イベント | いつ | 何をする |
|---|---|---|
| スプリントプランニング（イテレーション計画） | スプリントの始まる前 | プロダクトオーナが、プロダクトバックログから順位に従って項目を選ぶ。開発チームが見積もり、前回の実績を参考に、どこまで今回入れるかを決める（スプリントバックログの決定） |
| デイリースクラム（スタンドアップミーティング、朝会） | 毎日、決まった場所・時刻 | 立ったまま15分。進み具合や問題点を共有し、今日の計画を作る |
| スプリントレビュー（デモ） | スプリントの最後 | 成果物をデモし、リリースするかどうかをプロダクトオーナが判断する |
| スプリントレトロスペクティブ | スプリントレビューの後 | スプリントをふりかえり、次のスプリントに向けて改善する |
- イベントの順番：
- プランニング → （毎日デイリースクラム）→ レビュー → レトロスペクティブ
- レビューは「作ったもの」を見る。レトロスペクティブは「やり方」を見直す
- プロダクトバックログ：
- 今後のリリースで実装する機能を、ユーザストーリ形式で書いたリスト
- プロダクトオーナが管理し、内容・実施するかどうか・並び順（優先順位）に責任を持つ
- スプリントバックログ：
- 今回のスプリントでやると決めた項目のリスト（スプリントプランニングで決める）
- プロダクトバックログリファインメント：
- 次回以降のスプリントに向けて、バックログ項目を見直したり、詳細・見積り・並び順を追加したりすること
- ユーザストーリ：
- ユーザが求める機能を、簡潔に書いたもの
- 例えば、「会員として、パスワードを忘れたときに再設定したい」
- INVEST：
- ユーザストーリを作るとき、また完成度を評価するときの6つの観点
- Independent（独立している）、Negotiable（交渉可能）、Valuable（価値がある）、Estimable（見積もり可能）、Small（適切なサイズ）、Testable（テスト可能）
- 進捗の見える化：
- バーンダウンチャートやタスクボードを使う（プロジェクトの進捗管理でも出てくる）
- 注意（新しい情報）：
- 公式の「スクラムガイド」2020年版では、「開発チーム」という呼び方をやめて「開発者」と呼ぶ。スクラムチームは、プロダクトオーナ・スクラムマスター・開発者の3つの責任でできている
- 2025年6月には、スクラムの共同考案者らが「スクラムガイド拡張パック」を公開した（2020年版の置き換えではなく、補足の位置づけ）
- 試験では「開発チーム」という言い方も出るので、どちらも同じものと思っておけばよい
② XP（エクストリームプログラミング）：プログラマの実践手法集
- XP（eXtreme Programming）：
- アジャイル開発での、開発手法やマネジメントの経験則をまとめたもの
- 「共同、開発、管理者、顧客」の4つの立場ごとに、全部で19のプラクティス（実践手法）がある
- アジャイル開発のアプローチの1つ。「プラクティスを実行すること＝XPを実行すること」といえる
| 開発のプラクティス | 中身 |
|---|---|
| ペアプログラミング | 2人のプログラマがペアになり、その場で相談やレビューをしながら1つのプログラムを作る（品質向上、知識共有） |
| テスト駆動開発 | 最初にテストケースを設計し、テストに通る最低限の実装をしてから、コードを洗練させる |
| リファクタリング | 完成したプログラムでも随時改良し、保守性の高いプログラムに書き直す。外から見た動作は変えない。改良後は回帰テストをする |
| 継続的インテグレーション | コードの結合とテストを継続的に繰り返す。単体テストに通ったら、すぐ結合テストをして問題を早く見つける |
| コードの共同所有 | 誰が書いたコードでも、チーム全員が改善・再利用できる |
| YAGNI | 「You Aren’t Going to Need It（今、必要なことだけする）」。今必要な機能だけ作り、将来を見越した機能追加はしない。後の変更に対応しやすくなる |
- ドライバ：
- ペアプログラミングで、コードを書く人
- ナビゲータ：
- ドライバに指示や助言をする人
- 役割を交替しながらチェックし合うことが大事
- 例えば、車の運転手（ドライバ）と、助手席で道案内する人（ナビゲータ）
- 回帰テスト：
- 改良したことで、想定外の箇所に悪い影響が出ていないかを確かめるテスト
- リファクタリングの例え：
- 部屋の片付け。部屋の使い道（外から見た動作）は変えずに、中を整理して使いやすくする
③ リーンソフトウェア開発：ムダをなくす
- リーンソフトウェア開発：
- 製造業から生まれたリーン生産方式（ムダのない生産方式）の考え方を、ソフトウェアに当てはめた開発手法
- アジャイル型開発の1つ
- 行動指針となる「七つの原則」と、それを実現する22のツールがある
- 七つの原則：
- ①ムダをなくす ②品質を作り込む ③知識を作り出す ④決定を遅らせる ⑤早く提供する ⑥人を尊重する ⑦全体を最適化する
- 「決定を遅らせる」は、情報がそろうまで大事な決定を先延ばしにして、変更に強くするという意味（ひっかけ注意）
組込みソフトウェア開発：機器向けソフトを効率よく、早く作る
- プラットフォーム開発：
- 組込み機器の開発で、複数の機器に共通して使える部分（プラットフォーム）を最初に作り、それを土台に機器ごとの機能を作る手法
- ソフトを複数の機器で使い回せるので、開発の効率が上がる
- 例えば、同じ車台を使って、セダンやワゴンなど違う車種を作る
- プラットフォーム：
- プログラムを動かすための土台となる環境
- コンカレントエンジニアリング（コンカレント開発ともいう）：
- 複数の工程を順番にではなく、同時にできる工程を並行して進めて、開発期間を短くする手法
- もともとは、システム設計プロセスでの並行性の向上に関する研究から使われだした言葉
- コデザイン（協調設計）：
- 組込みシステムでコンカレントエンジニアリングを実現する技術・手法
- 開発の早い段階で、ハードウェアとソフトウェアを同時に設計する
- ハードとソフトの機能分担とインタフェースを、シミュレーションで十分に検証し、その後もシミュレーションを使いながら並行して開発する
- 開発期間の短縮と、品質の向上が期待できる
- コベリフィケーション：
- シミュレーション技術を使って、ハードウェアとソフトウェアの検証を同時に行うこと
- コデザインは「同時に設計」、コベリフィケーションは「同時に検証」
- MDA（モデル駆動型アーキテクチャ）：
- システムを、プラットフォームに依存する部分と依存しない部分に分けてモデル化する技法
- 組込みソフトウェアなどの設計にも有効
ソフトウェアの再利用とローコード開発：なるべく作らずに済ませる
- 考え方：
- 開発の生産性や品質を上げるために、既存のソフトや部品を再利用する、または最小限のソースコードで開発する
① リエンジニアリングによる再利用（★）
- リエンジニアリング：
- 既存のソフトウェアを利用して、新しいソフトウェアを作る技術
- リバースエンジニアリング → フォワードエンジニアリングの順で行う
- リバースエンジニアリング：
- 既存のソフトウェアを解析して、その仕様を導き出す技術
- 例えば、完成した料理を味見して、レシピを割り出す
- フォワードエンジニアリング：
- 導き出した仕様を、新しいソフトに合うように修正・変更し、それをもとに新しいソフトを作ること
- 例えば、割り出したレシピを自分好みに変えて、新しい料理を作る
- リエンジニアリングの流れ：
- 既存ソフトウェア →（解析）→ 既存ソフトウェアの仕様 →（修正・変更）→ 新規ソフトウェアの仕様 → 新規ソフトウェア
- 前半がリバースエンジニアリング、後半がフォワードエンジニアリング
- リバースエンジニアリングの目的：
- 新しいソフトの再利用開発を助けるだけでなく、既存ソフトの機能の修正や追加といった保守作業にも役立てる
- E-R図の生成：
- モデリングツールで、データベースの定義情報からE-R図などの設計書を作るのも、リバースエンジニアリング
- 知的財産権の注意：
- 元のソフトの権利者の許可なくリエンジニアリングで開発・販売すると、元の製品の知的財産権を侵害するおそれがある
② 部品による再利用
- 部品による再利用：
- 既存のソフトを部品化し、新しいソフトで使うことで、生産性や品質を上げる
- 部品化の短所：
- 部品はそれだけで完結している必要があるので、標準性・汎用性が厳しく求められる
- そのため、ふつうの開発より開発工数やコストがかかることがある
- 部品化の長所：
- 一度部品にしておけば、あとは使うだけなので、コストがかからず、期間も短く、品質も上がる
- 例えば、レゴブロック。ブロックを作るのは手間だが、一度作れば何度でも組み合わせられる
- ドメインエンジニアリング：
- 銀行の勘定系システムなど特定分野（ドメイン）のシステムについて、業務知識・再利用部品・ツールなどを体系的に整え、再利用を進めて開発の効率を上げる活動や手法
③ ローコード開発
- ローコード開発：
- できるだけソースコードを書かずに、高品質なソフトをすばやく作る開発
- 見て操作できるGUIで、開発ツールに用意された部品を組み合わせて作る
- 専門的なコーディングの知識や経験がなくても開発できる
- 例えば、プログラムを書かずに、画面上でパーツを並べてアプリを作る
共通フレームの開発プロセス：公式の工程表とV字モデル（★）
- 共通フレームの開発プロセス：
- ウォータフォール型の流れとV字モデルを意図して、開発プロセスのアクティビティが組み立てられている
- V字モデル：
- 設計（品質を埋め込むプロセス）と、テスト（品質を検証するプロセス）を対応させたもの
- 左側を下りながら要求を細かくし、右側を上りながらテストする
- 例えば、レストランで、注文を受けて（要件）作り方を決め（設計）、料理を作り、最後にお客さんが「注文どおりか」を確かめる
アクティビティとV字モデルの対応
| 区分 | 設計（左側） | 対になるテスト（右側） |
|---|---|---|
| システム開発プロセス | システム要件定義 | システム適格性確認テスト（システムテスト） |
| システム開発プロセス | システム方式設計 | システム結合テスト |
| ソフトウェア実装プロセス | ソフトウェア要件定義 | ソフトウェア適格性確認テスト |
| ソフトウェア実装プロセス | ソフトウェア方式設計 | ソフトウェア結合テスト |
| ソフトウェア実装プロセス | ソフトウェア詳細設計 | ソフトウェアユニットのテスト（単体テスト） |
- V字の一番下：
- ソフトウェアユニットの作成
- ユニットの作成と、ユニットのテスト（単体テスト）を合わせて「ソフトウェア構築」という
- 対応の覚え方：
- 「要件定義」は「適格性確認テスト」、「方式設計」は「結合テスト」、「詳細設計」は「ユニットのテスト」
- 要件定義のときに「何を満たせば合格か（適格性確認要件）」を決めておき、最後にそれを確かめる
各アクティビティの主な作業
- システム要件定義：
- システム化の目標と対象範囲を決め、システムで実現する機能要件や性能要件を定義する
- システムの適格性確認要件を決める
- システム方式設計：
- すべてのシステム要件を、ハードウェア、ソフトウェア、手作業に振り分け、それぞれを実現するのに必要なシステム要素を決める
- システム結合のためのテスト要件を決める
- ソフトウェア要件定義：
- システム方式設計でソフトウェアに割り振られたシステム要素（ソフトウェア品目）に求められる機能や能力などを定義する
- ソフトウェアの適格性確認要件を決める
- ソフトウェア方式設計：
- ソフトウェア品目の要件を、どう実現するかを決める
- ソフトウェア品目の外部インタフェースの方式を決める
- ソフトウェア品目をソフトウェアコンポーネント（プログラム）まで分け、各コンポーネントの機能や、コンポーネント間の処理の手順や関係をはっきりさせる
- ソフトウェア結合のための暫定的なテスト要件とスケジュールを決める
- ソフトウェア詳細設計：
- 各ソフトウェアコンポーネントを、ソフトウェアユニットのレベルまで細かくし、詳細設計を文書にする
- ソフトウェアユニットのテスト要件とスケジュールを決める
- ソフトウェア結合のためのテスト要件とスケジュールを更新する
- ソフトウェア構築：
- ソフトウェアユニットのコードを作り（コーディング）、動作確認（単体テスト）をする
- 分解の順番（ひっかけ注意）：
- システム →（方式設計で振り分け）→ ソフトウェア品目 →（方式設計で分割）→ ソフトウェアコンポーネント（プログラム）→（詳細設計で分割）→ ソフトウェアユニット（モジュール）
- システム要素：
- システム方式設計で決める、システム要件を実現するための構成要素（ハード、ソフト、手作業）
- ソフトウェア品目：
- システム要素のうち、ソフトウェアに割り振られたもの
- ソフトウェアコンポーネント：
- ソフトウェア品目を分割したもの（プログラム）
- ソフトウェアユニット：
- 「コーディング → コンパイル → テスト」を行う単位（モジュール）
ソフトウェアプロセスの評価：組織の開発力を測る物差し（★）
- 背景：
- ソフトウェアへの期待や需要が増え、規模や難しさが上がる一方、開発期間はどんどん短くなっている
- 顧客が満足するソフトを出すには、品質の向上・生産性の向上・短期間の開発を同時に達成する必要がある
- そのために、開発作業をすべてのプロセスについて評価し、改善していく
- CMMI（能力成熟度モデル統合、Capability Maturity Model Integration）：
- ソフトウェアを開発・保守する組織のプロセスのあり方を示したモデル
- プロセスの評価・改善の「物差し」
- 組織の作業水準を「プロセスの成熟度」でとらえ、成長の過程を5段階のレベルでモデル化している
- CMMIの特徴：
- 成熟度を具体的に実現するためのプロセス領域を、成熟度レベルに沿って定義している
- そのため、CMMIを使うと継続的なプロセス改善ができる
- プロセス領域：
- 関連するプラクティスをまとめたもの
- そのレベルでのプロセス改善のゴール
- プラクティスエリア：
- CMMI V2.0以降で、プロセス領域から置き換えられたもの（さらに使いやすくなった）
| レベル | 名前 | 状態 | 例え（部活のチーム） |
|---|---|---|---|
| 1 | 初期 | プロセスが確立されていない。場当たり的で、一部のメンバの力量に頼る | エース頼み。エースが休むと負ける |
| 2 | 管理された | 基本的なプロジェクト管理ができる。似たプロジェクトなら繰り返せる | 前と同じような相手なら、同じように戦える |
| 3 | 定義された | プロセスが標準化・定義され、各プロジェクトで標準プロセスを使っている | チーム共通の戦術マニュアルがあり、全員が使う |
| 4 | 定量的に管理された | プロセスの実績を数字で把握し、結果を予測（危機予測）して、それをもとにプロセスを制御できる | 試合データを取り、結果を予測して作戦を調整できる |
| 5 | 最適化している | プロセスの問題の原因分析ができ、継続的にプロセスを改善している | データから負けた原因を分析し、練習方法を改善し続ける |
- レベルの覚え方：
- 「場当たり → 繰り返せる → 標準がある → 数字で予測できる → 改善し続ける」
- 「管理された（2）」と「定量的に管理された（4）」の違いは、数字（定量）があるかどうか
- SPA（Software Process Assessment）：
- ソフトウェアプロセスを改善するために、CMMIなどの成熟度モデル（アセスメントモデル）を使って、自分の組織が今どの状態かを評価すること、またはその手法
- プロセスアセスメントの規格：
- JIS X 33002:2017（プロセスアセスメント実施に対する要求事項）などを含む、JIS X 330xx規格類（JIS X 33000シリーズ）にまとめられている
- 注意（新しい情報）：
- CMMIは2023年にV3.0が出ている（現在はISACAが管理）
- V2.0以降の公式の成熟度レベルには、「0：不完全（Incomplete）」も加わっている
- 試験は5段階（初期〜最適化している）で問われるので、それで覚えてよい
混同しやすいペア
- インクリメンタルモデル ／ 進化的モデル ／ スパイラルモデル
- インクリメンタルは、要求を最初に全部決め、分けて順番に作る
- 進化的は、要求があいまい・変わる前提で、繰り返しながら要求を洗練する
- スパイラルは、部分ごとに工程を繰り返し、そのたびにコストなどを評価してリスクを減らす
- 要求変更への対応（ウォータフォール ／ 進化的）
- ウォータフォールは、保守工程で対応する
- 進化的は、新しいサイクルで対応する
- プロトタイプ ／ モックアップ
- プロトタイプは、仕様の漏れや実現性などを評価するための試作品
- モックアップは、見た目だけを確認する試作品
- スプリントレビュー ／ スプリントレトロスペクティブ
- レビューは、成果物をデモし、プロダクトオーナがリリースの可否を判断する
- レトロスペクティブは、やり方をふりかえって改善する
- プロダクトバックログ ／ スプリントバックログ
- プロダクトバックログは、今後作る機能の全リスト。プロダクトオーナが管理する
- スプリントバックログは、今回のスプリントでやる分。スプリントプランニングで決める
- スプリントプランニング ／ プロダクトバックログリファインメント
- スプリントプランニングは、今回のスプリントでやる項目を決める
- リファインメントは、次回以降に向けてバックログ項目を見直し、詳細・見積り・並び順を加える
- スクラム ／ XP ／ リーン
- スクラムは、チームの進め方のフレームワーク（4つのイベント）
- XPは、開発の実践手法集（19のプラクティス）
- リーンは、ムダをなくす考え方（七つの原則と22のツール）
- ドライバ ／ ナビゲータ
- ドライバは、コードを書く人
- ナビゲータは、指示や助言をする人
- テスト駆動開発 ／ 継続的インテグレーション
- テスト駆動開発は、テストを先に作ってから実装する
- 継続的インテグレーションは、結合とテストを継続的に繰り返す
- リファクタリング ／ リエンジニアリング
- リファクタリングは、外から見た動作を変えずに、中身を保守しやすく書き直す
- リエンジニアリングは、既存ソフトから仕様を取り出して、新しいソフトを作る
- リバースエンジニアリング ／ フォワードエンジニアリング
- リバースは、既存ソフトから仕様を導き出す（さかのぼる）
- フォワードは、仕様を修正して新しいソフトを作る（前へ進む）
- コンカレントエンジニアリング ／ コデザイン ／ コベリフィケーション
- コンカレントエンジニアリングは、工程を並行して進める考え方全般
- コデザインは、ハードとソフトを同時に設計する
- コベリフィケーションは、ハードとソフトを同時に検証する
- プラットフォーム開発 ／ ドメインエンジニアリング
- プラットフォーム開発は、複数の機器に共通の土台を先に作る（組込み）
- ドメインエンジニアリングは、特定分野の業務知識や部品を整えて再利用する
- 部品による再利用 ／ ローコード開発
- 部品による再利用は、既存ソフトを部品にして使い回す。最初は部品化に手間がかかる
- ローコード開発は、ツールに用意された部品をGUIで組み合わせる。専門知識がなくてもできる
- ソフトウェア品目 ／ ソフトウェアコンポーネント ／ ソフトウェアユニット
- ソフトウェア品目は、システム方式設計でソフトに割り振られたもの
- ソフトウェアコンポーネントは、ソフトウェア方式設計で分けたプログラム
- ソフトウェアユニットは、ソフトウェア詳細設計で分けたモジュール
- 適格性確認テスト ／ 結合テスト ／ ユニットのテスト
- 適格性確認テストは、要件定義と対になる
- 結合テストは、方式設計と対になる
- ユニットのテスト（単体テスト）は、詳細設計と対になる
- CMMIの「管理された」 ／ 「定量的に管理された」
- 管理された（レベル2）は、基本的なプロジェクト管理ができ、似たプロジェクトを繰り返せる
- 定量的に管理された（レベル4）は、実績を数字で把握し、結果を予測して制御できる
- CMMIの「定義された」 ／ 「最適化している」
- 定義された（レベル3）は、標準プロセスがあり、各プロジェクトで使っている
- 最適化している（レベル5）は、原因分析をして、継続的に改善している
- CMMI ／ SPA
- CMMIは、成熟度を測るモデル（物差し）
- SPAは、そのモデルを使って自分の組織を評価すること