内部一貫性

ソフトウェアのコードやテスト結果などの成果物が、要件や設計といった上位の成果物と矛盾なく対応している性質。ソフトウェアコードとテスト結果の評価基準の一つで、内部一貫性、追跡可能性、テスト網羅性と並べて用いる。

システムを構成するソフトウェアに求められる機能、能力、インタフェースなどを明確にし、ソフトウェア要件として文書化する工程。システム要件定義の結果を受けて行い、業務モデルやデータモデルを作成しながら要件を定め、取得者と供給者が共同でレビューする。

JIS X 0170（ISO/IEC/IEEE 15288）が定める、システムの構想から開発、運用、保守、廃棄までのライフサイクルで行うプロセスの体系。合意プロセス、組織のプロジェクトイネーブリングプロセス、テクニカルマネジメントプロセス、テクニカルプロセスの4つのプロセス群からなる。ソフトウェアを対象にしたJIS X 0160と対になる。

システムやソフトウェアそのものを定義し、作り、検証して、運用・保守・廃棄に至らせる技術的なプロセス群。利害関係者のニーズ及び要件の定義、システム要件定義、アーキテクチャ定義、設計定義、実装、統合、検証、移行、妥当性確認、運用、保守、廃棄などを含む。計画や管理を担うテクニカルマネジメントプロセスと対になる。

ソフトウェアの企画から開発、運用、保守、廃棄までに行う作業をプロセスとして定義し、用語と構成を標準化したもの。国際規格ISO/IEC/IEEE 12207（JIS X 0160）が基になり、日本ではIPAが共通フレーム（SLCP-JCF）として取りまとめている。発注者と受注者が同じ言葉で作業範囲や役割を合意するために使う。

標準として定められたライフサイクルプロセスを、プロジェクトの規模、リスク、契約条件などに合わせて取捨選択し、必要な形に調整すること。共通フレームやISO/IEC/IEEE 12207は、全部をそのまま適用するのではなく、修整して使うことを前提にしている。