拾って落とすエンジニア活動ログ

各種技術や周辺知識のTIPS、振り返り

初級ソフトウェア品質技術者のシラバスから用語まとめ（2章）

初級ソフトウェア品質技術者の資格試験のシラバスVer2.0から第2章分のメモです。

第1章はこちらです。

yb300k.hateblo.jp

 

脱線、SQuBOKはよくこれだけまとめたなという感想ですが、単語だけ紹介されているものなどは、ググらないとよくわからない場合があります。ググった結果を使うときは、科学技術連盟のものをできるだけ使おうとは思いましたが・・そうもいかなかったので、参考まで、ということで。

 

2ソフトウェア品質マネジメント

＜組織レベルのソフトウェア品質マネジメント＞

2.1ソフトウェア品質マネジメントシステムの構築と運用
  • QMS（QualityManagementSystem)：組織の主たるアウトプットである製品・サービスの「品質に関して組織を指揮し、管理するためのマネジメントシステム」。ISO9000シリーズに規定されているのは、品質マネジメントシステムは品質計画、品質管理、品質保証、品質改善の4つの活動から構成され、トップマネジメントによる品質に関する方向付けのもと、目指すべき品質目標が設定されている。日本のTQC、TQMのなかの品質マネジメントシステムは上記とは異なっていて、お客様に安心して使っていただけるような製品を提供するすべての活動であり、顧客満足の追及や品質を中核とした全員参加の改善が基本。
  • TQC（TotalQualityControl）総合的品質管理：全社的品質管理、品質管理の教育・訓練、方針管理、マーケットイン思想、QCサークル活動、QC診断、全国的品質管理推進活動などの特徴を持つ。1997年に呼称がTQMにかわる。理念は引き継がれ、経営管理技術へと発展した。
  •  TQM（TotalQualityManaement）総合的品質マネジメント：経営管理の技法。品質第一の考え方、データ・事実に基づく管理、人間性尊重 の3つの思想がTQMを支えている。継続的改善の技法として代表的なのは方針管理、機能別管理、QCサークル。
  • 現地・現物：実際に問題が起きた現場に足を運び、実際の現場で自分の目と足で確かめ、事実を確認する。 その上で、頭で考える
  • 小集団活動：従業員の経営参加の方法の一つであり、企業内で少数の従業員が集まったグループを結成し、そのグループ単位で共同活動を行うことを目的として運営するもの。QCサークルが広い分野で展開されたものが、より一層の人と組織の活性化を目指す動きとして、間接部門を含む全員参加の幅広い改善活動として進化したもの。
  • プロセスアプローチ：組織内で用いられるプロセス及び、特にそのプロセス間の相互作用を体系的に明確にし、運営管理すること。
2.1.1品質マネジメントシステム
  • QCサークル：同じ職場内で品質管理を自主的に行うグループ活動。QC手法を活用して職場の改善などを全員参加で行う。
  • 方針管理：会社から出た方針を達成するための取り組み。たとえば（中長期の）経営計画→年度方針→部門方針といった具合に、全社的な方針（重点課題）を徐々に展開（ブレークダウン）していく。
  • 機能別管理：製造や販売といった直接的な実施部門での取り組み（部門別管理）に対し、品質や原価といった各部門に共通するような、管理部門の視点から見た取り組み。実施部門ごとの縦割りで見るのではなく、たとえば実施部門同士を品質などの視点から横串を通し、定められた目標を達成する取り組みであり、部門横断的な役割を担う。そのため、英訳ではcross-functional managementと表現される事もある。
  • 人間性尊重：TQMの思想の一つ。はたらく人に負荷をかけるのではなく、主体的な取り組みを助長することによって効率や安全性、企業としてのパフォーマンスを向上させる。
2.1.2セキュリティのマネジメント
  • セキュリティのマネジメント：守るべき資産の価値が損なわれる脅威を回避、もしくは軽減するためのマネジメント。
  • 脆弱性管理：開発段階において脆弱性を作り込まないことを目的とした活動と、出荷後の運用段階で脆弱性が発見された場合に対応することを目的とした活動がある。脆弱性の悪用による被害を最小限にするために脆弱性管理を行う。
  • CC/CEM：1章のメモ参照。CCがセキュリティ評価の共通基準。CEMが評価方法。
  • プロテクションプロファイル：CC（コモンクライテリア）に従って、調達者が要求するセキュリティ要件を定義した文書。主に政府機関で調達要件として使用される。
  • セキュリティターゲット：プロテクションプロファイルを満たすための、開発者がその製品固有のセキュリティ要件を定義した文書
  • CC承認協定（CCRA、CommonCriteriaRecognitionArrangement）：条約に準ずる国際協定。CCに基づいたセキュリティ評価・認証の相互承認に関する協定。2003年に日本が参加。2017年は27か国参加。
  • 暗号アルゴリズムの危殆化：コンピューターの能力向上や、新たな攻撃手法の発生などにより、特定の暗号アルゴリズムの安全性が危ぶまれる状態になること。
2.1.3ソフトウェア品質推進活動
  • シックスシグマ：ミスの発生確率を100万分の3.4以下にするという目標を実現するための経営革新技法。DMAICと呼ばれるシックシグマ達成プロセスを繰り返すことにより6シグマのミス発生確率を達成する。
  • DMAIC：Define、Measurement、Analysis、Improvement、Controlの5段階のプロセス。GEがDefineを追加する前は、モトローラの開発したMAICだった。
  • SWQC（SoftwareQualityControl）：NECで行われてきたソフトウェアの総合的品質管理活動。”品質を追求しよう！生産性は後からついてくる”
  • Qfinity：富士通が全社的に進めている品質改善活動
  • 品質会計：NECが考案したソフトウェア品質マネジメント技法。バグを負債とみて、バグ件数を主要メトリクスとしてバグ摘出目標管理を実施。
  • TPS（ToyotaProductionSystem）：トヨタ生産システム
2.2ライフサイクルプロセスのマネジメント
  • ライフサイクルプロセスのマネジメント：システムやソフトウェアの構想から廃棄までの活動に対するマネジメント。
2.2.1ライフサイクルモデル
  • ソフトウェアライフサイクルプロセスに関する規格（ISO/IEC12207）：ソフトウェアを開発し、運用するための標準プロセスを提供する規格。企画から廃棄までの43個のプロセスを包含している。各プロセスは7つのカテゴリに分類されている。目的と成果を定義した後に、アクティビティに分解し、具体的な活動をタスクとして定義している。
  • システムライフサイクルプロセスに関する規格（ISO/IEC 15288)：システムを開発し、運用するための標準プロセスを提供する規格。システムの要求定義から設計、実装、運用、保守、処分までの25個のプロセス。各プロセスは合意、組織プロジェクトイネーブリング、プロジェクト、テクニカル、の4つに分類されている。（※2008だとそうだったらしい。2015だと、30プロセスで、合意、組織プロジェクトイネーブリング、技術管理、技術の4プロセス）
2.2.2セーフティ・クリティカル・ライフサイクルモデル
  • セーフティ・クリティカル・ライフサイクルモデル：災害や事故防止のための安全機能に使用されるシステムやソフトウェアのためのライフサイクルモデル。安全性重視のためのライフサイクル。安全性解析・開発・安全妥当性確認の三つの要素で構成する。
  • 安全度要求：想定したハザードが引き起こしうる危険事象に対するリスクとSIL。
  • 安全機能要求：リスクを許容範囲内に収めるために必要な安全機能。
  • 安全妥当性確認：安全度要求に応じた安全機能要求が高い信頼性で作り込まれ、想定したハザードが発生しても危険事象に至らないことを検証する。
  • 機能安全（IEC61508）：機能安全の基本安全規格。7部で構成されていて、1部から3部が要求事項を含んでいる。
  • 自動車電子制御の機能安全（ISO26262）：安全に関する国際規格のうち産業分野用に詳細化したグループ安全規格の一つ。各ハザードに対して対応の厳格さの目安となるASIL（自動車用安全度水準）を決定する。
  • セーフティゴール：安全要件の最上位。危険事象を回避、または影響を低減するための目標。
  • 医療機器ソフトウェアーソフトウェアライフサイクルプロセス（IEC62304）：医療機器ソフトウェアの安全設計・保守に必要なライフサイクルプロセスに関する要求事項を規定した規格。アクティビティ及びタスクからなるライフサイクルプロセスのフレームワークと各ライフサイクルプロセスに対する要求事項を、ソフトウェア安全クラスに応じて規定する。
  • ソフトウェア安全クラス：危害が患者、操作者、他の人におよぼす影響に応じて分類したもの。クラスA、B、Cがあり、Aは負傷または健康障害の可能性はない。Cは死亡または重傷の可能性があるもの。
  • SOUP（Software Of Unknown Pedigree）：開発過程が不明なソフトウェア。医療機器のIEC62304では、SOUPに対する要求事項を定義する。
2.2.3プロセスモデル
  • FDD(機能駆動型開発）：アジャイルプロセスモデルのひとつ。ユーザーにとっての機能価値（feature）を重視した開発手法。あらかじめビジネスモデルを理解し、ログイン機能や購入機能といったユーザー機能を中心に計画をたて、設計や開発を行う。
  • クリスタル：取り決めがゆるい。プロジェクトの規模や影響度に応じて，必要となるメンバーの役割や作成すべき成果物を分類・定義。

    Part7 最も取り決めの緩い「クリスタル」－－「反省」を通してプロセスを改善 | 日経クロステック（xTECH）

  • プロダクトライン開発：多品種製品向けのソフトウェア開発技法。PLEまたはSPLと呼ばれることもある。複数製品における共通のコア資産を構築して、そのコア資産から各製品を導出する戦略的な開発技法。フィーチャー（ユーザー視点でのシステム特性）に基づく可変性分析の導入が特徴。
  • 派生開発（XDDP）：すでに開発済のソフトウェア資産に対して、製品価値を高めるための新しい機能の追加や既存機能の改善を行う開発のこと。設計作業が必要かどうかの観点で、要求を機能追加（設計が必要）と、変更（絵設計不要）に分ける。
  • スペックアウト：上記変更の最初の手順として行うこと。要求仕様書、設計資料、ソースコードなどの既存資産から、現状の仕様を抽出すること。
  • USDM：要求と仕様のまとめ方の方法。自然言語を用いて「要求」と「仕様」を階層化して整理するのが特徴。

    ｢要求｣と｢仕様｣を階層化する【USDM】で｢要求仕様書｣を作成

  • トレーサビリティマトリクス（TM）：変更要求仕様に対する既存のシステムへの影響範囲を確認するため、変更要求仕様を「行」、システム構成要素（フォルダやファイルなどの単位）を「列」としてマトリクスを作成する。各升目に関数を記述する。
2.3ソフトウェアプロセス改善のマネジメント
2.3.1ソフトウェアプロセス能力改善のためのプロセスモデル
  • CMMI(Capability Maturity Model Integration 能力成熟度モデル統合)：顧客及び最終利用者のニーズを満たすための高品質な製品とサービスを開発する活動に対して、包括的で統合された一連の指針を提供するモデル。組織におけるプロセス改善に焦点を合わせており、場当たり的で未成熟なプロセス(初期）から、改善された品質と有効性を伴った秩序ある成熟したプロセス（最適化された）への進化の改善経路を、22個のプロセス領域により示す。成熟度レベル（１から５）と能力度レベル（０から３）という2種類の改善経路を持つ。ARCに要求事項がまとめられていて評定できる。評定方法のクラスとしてABCの3つがあり、クラスA準拠の評定方法としてSCAMPIがある。
  • PSP（パーソナルソフトウェアプロセス）：技術者の自己改善のためのプロセス。技術者のQCDにかかわる見積精度、生産性、成果物の質を向上させるのが目的。
  • TSP（チーム・ソフトウェア・プロセス）：チームでソフトウェア開発を行うプロセス。役割別に前提スキルや実施すべき活動を述べる。
  • TPI（テストプロセス改善）：TMap（TestManagementApproach for structuredtesting）構造化されたテストプロセスの方法論をベースにした、テストプロセスを改善するための技法。テストプロセスを20のキーエリアに分け、それぞれのプロセスの成熟度のレベルをAからDの4段階（一部のキーエリアは2-3段階）で評価。進化版がTPI NEXT。

    TPI NEXT入門

  • TMMi（テスト成熟度モデル統合）：テストプロセスを段階的に改善していくための技法。CMMIと親和性があり、CMMのテストプロセス部分を補完する。5段階の水準とそのゴールで構成されている。アセスメントをサポートするTMM-AM（TMMアセスメントモデル）が定義されている
2.3.2ソフトウェアプロセス改善のためのマネジメント技法
  • プロセスアセスメントに関する規格（ISO/IEC15504）：アセスメントと改善方法について規定した規格。プロセス参照モデル、測定の仕組、プロセスアセスメントモデルによりアセスメントを行う。
  • IDEAL：継続的及び組織的なソフトウェアプロセス改善のライフサイクルモデル。初期フェーズ（Initiating）、診断フェーズ（Diagnosing）、確立フェーズ（Establishing）、実行フェーズ（Acting）、学習フェーズ（Learning）の5フェーズから構成されている。PDCAに比べて手順が詳細に示されている。プロセス改善を計画する際のフレームワークとして利用できる。
  • ポストモーテム：ソフトウェア製品を開発した後に、開発時の良かった点、悪かった点を洗い出し、次期開発への改善点を明確にするための検討会。開発に参加した人から意見を集め整理する。整理した情報をもとに関係者を集め検討会を実施する。
  • 落穂拾い：日立製作所で行われている事故やトラブルの再発を防ぐための検討会。
  • なぜなぜ分析：根本的な原因を論理的にもれなく検討し、障害の再発防止を図るための分析技法。
  • 三階層SEPG（Software Engineering Process Group）：東芝。大規模組織で効果的にソフトウェアプロセス改善活動を推進するための階層的な活動体制。開発部門SEPG,カンパニーSEPG、コーポレートSEPGと三階層で、それぞれが役割と責任をもって推進する。現場、現物、現実を重視する三現主義でソフトウェア開発部門のプロセス改善活動を推進する。
2.4検査のマネジメント
  • 検査計画：検査方針、検査体制、検査方法、検査環境および検査日程などの基本的な計画を明確にし、検査計画書を作成する。検査計画書には中間成果物の検査であるドキュメント検査や探針、製品検査の各段階の検査内容を盛り込む。
  • ドキュメント検査：中間成果物である設計書やユーザーマニュアル、テスト計画を検査し、合否判定を行う。
  • 中間品質監査：各開発工程の完了時や、検査工程開始前に、製品品質が検査に耐えうるものになっているか否かを判断するために各工程の品質把握を行う。テスト工程での摘出障害件数や摘出傾向の妥当性評価によるテスト工程完了監査や探針を行う。
  • 製品検査：検査部自らがテスト項目の設計、テストツール、てすとプログラム、テストデータなどのテストジョブの作成、テスト環境の構築を行い、検査を実施する。開発部門のテスト結果も確認して合否を判定する。
2.5監査のマネジメント
  • 第一者監査、第二者監査、第三者監査：組織の内部の監査員が実施するのを第一者監査、顧客及び発注先またはその代理人などの組織に利害関係を有する者が実施する監査を第二者監査、外部の独立した組織によって実施される監査を第三者監査と呼び区別することがある。
  • 購買先プロセス監査：購入者が購買先に対して、作業プロセスが適正化、標準に対する順守状況はどの程度かを確認し、必要に応じて作業プロセスの是正および改善勧告を行うこと。
  • ソフトウェア開発における監査：ソフトウェア開発の各工程において、プロダクト監査またはプロセス監査の観点で確認する。
  • プロダクト監査：あらかじめ定めた各工程での成果物が、当該工程において作成されていることを外形的な要件を中心に確認する。
  • プロセス監査：当該工程において当該組織で定めた作業プロセスを順守して実施していることを確認する。
2.6教育・育成のマネジメント
2.6.1スキル標準
  • ITSS（ITスキル標準）：経済産業省が策定した人材の育成及び有効活用のための職種と能力を関連付けた共通指標。役割ごとに分類した１１の職種と、それらの職種の下に全部で35の専門分野を設け、各専門分野に応じて7段階のレベルを規定している。レベル１，２がエントリーレベル、３，４がミドルレベル、５，６，７がハイレベルである。経験や実績を評価する達成度指標と、実務能力を評価するスキル熟達度がある。
  • ETSS（組込みスキル標準）：組み込みソフトウェアの開発力強化のため、技術スキルを体系化した「スキル基準」、必要とする職種や職掌を定義する「キャリア基準」、産業横断的に使用可能な「教育研修基準」の３つの基準を骨格に構成する。
  • UISS（情報システムユーザースキル標準）：ユーザー企業における情報システム機能の枠組みを体系的に示す。調達、評価、活用に関する職務とその能力もITスキルとして定義した。15の業務機能と10の人材像をマトリクス型で定義。
  • CCSF（共通キャリア・スキルフレームワーク）：ITSS、ETSS,UISSの3つのスキル標準が備えるコンテンツを、「タスク」「職種・人材像」「スキル・知識」を軸に整理し、「タスクモデル」「人材モデル」「スキルモデル」の3つのモデルを定義。改訂版としてiコンピテンシ・ディクショナリ」が発表された。

    i コンピテンシ ディクショナリ概要：IPA 独立行政法人 情報処理推進機構

2.6.2教育・育成のマネジメント技法
  • アンカーキャリア：最終的に目標となる職務。
  • PS(パートナー満足）：プロジェクト形態の業務における仕事満足。さまざまな組織から人材が集められることが多いため、一企業に閉じず、プロジェクトにおいて共同する仲間の相互満足をはかる。
2.7法的権利・法的責任のマネジメント
2.7.1知的財産権の法的権利・法的責任のマネジメント
  • 知的財産権法：産業財産権法、不正競争防止法、著作権法などから構成される。
  • 特許法：アルゴリズムなどのアイデアが「発明」として特許法により保護される。
  • 著作権法：プログラムやコードで表現したものが著作権で保護される。プログラムは創作性のあるもの、データベースは配列やデータ素材そのものに思想が創作として表現されている場合、画面は創作的表現と認められる場合、ゲームソフトの映像の部分、が著作物となりえる。
  • OSSライセンス：OSSを利用する条件を、OSS著作者が定めたもの。利用とは主に改編や再頒布をいう。著作権法で保護されている。
2.7.2知的財産権以外の法的権利・法的責任のマネジメント
  • 不正アクセス禁止法：不正アクセス行為の防止を図ることを目的として、不正アクセス行為の禁止と処罰、不正アクセスを受ける立場の防御措置という２つの側面から定めた法。
  • 個人情報保護法：個人情報保護法の義務の対象となる個人情報取扱業者（個人情報の数が5000を超える者）が遵守すべきルールを定めた法。
  • PL法（製造物責任法）：製品が通常有すべき安全性を欠いているために生じる生命、身体または財産におよぼす損害を、被害者損害の因果関係ではなく被害自体を立証できる場合に、製造者に対して賠償を求められるようにする法。PL法による責任は「製造または加工された動産」が対象のため、プログラムだけでは法の対象にはならない。

＜プロジェクトレベル（共通）のソフトウェア品質マネジメント＞

2.8意思決定のマネジメント
  • IPD(統合製品開発）：IBM製品開発現場で適用されているプロセス群。意思決定メカニズムだけにとどまらない。製品開発のフェーズを「構想」「計画」「開発」「評価」「量産＆初出荷」「ライフサイクル（本格的な製造販売保守）」の6フェーズにわけて、この間に4つの意思決定チェックポイントを設けて、次フェーズへの着手を判断することにしている。開発期間の短縮と、投資回収期間の短縮を狙いとしている。企業における最上位のビジネス用プロセス群。
2.9調達のマネジメント
  • オフショア開発：自国以外の事業者や子会社にソフトウェア開発を委託すること。両者の橋渡し役のSE（ブリッジSE）を置いて種々の事柄の伝達を円滑にし、問題解決を図る。
2.10リスクマネジメント
  • リスクマネジメントに関する規格（ISO/IEC16085）：システム及びソフトウェアの全ライフサイクルにおけるリスクマネジメントのためのプロセス内容を規定したもの。6つのアクティビティからなる。1)リスクマネジメントの計画及び実行２）プロジェクトリスク台帳の管理３）リスク分析の実施４）リスク監視の実施５）リスク対応の実施６）リスクマネジメントプロセスの評価
  • システム及びソフトウェア保証に関する規格（ISO/IEC15026）：「保証ケース（AssuranceCase）という文書体系を導入して、ユーザーなど利用環境と相互作用するシステムやソフトウェアが、内在する不確実性やリスクに対して目標通りに動作することを、系統的に検討して保証する方法を規定したもの。
  • リスク識別：リスクを発見し、プロジェクトへの影響を見定め、その特性を記録すること。
  • リスク分析：発生原因であるリスクの因子や、因子とその結果における因果関係を分析し、リスクの発生度合いや影響度合いを明らかにすること。発生確率と影響度からなるマトリクスに識別したリスクを記入し評価することで、リスク対応への優先順位を決定する。
2.11構成管理
  • 構成管理：システムやソフトウェアライフサイクルの全般にわたり、構成要素の機能や特性を特定狩野西、それらに対する変更を管理・検証し、その状況を記録する活動であり、その活動により要素間やその変化が追跡可能となる。
  • 構成管理計画書：以下のような内容を含む文書。構成管理の目的、組織と責任、適用標準、ツール、構成の識別（構成管理対象の選定とベースレベル）、構成制御（変更管理方法）、ベースレベル計画（時期）、ベースレベル管理表
2.11.1変更管理
  • CCB（ChangeControlBoard）：製品のために提案された変更要求と新しく提案された機能のどれを受け入れるかを決定する人々の集合。構成管理委員会または変更管理委員会とも呼ばれる。
2.11.2バージョン管理
2.11.3不具合管理
2.11.4トレーサビリティ管理
  • トレーサビリティ管理：考慮の対象となっているものの履歴、適用または所在を追跡できること。要求のトレーサビリティ管理、成果物のトレーサビリティ管理、製品のトレーサビリティ管理に分類できる。
2.12プロジェクトマネジメント
2.12.1プロジェクトマネジメントの体系
  • PMBOK（プロジェクトマネジメント知識体系）：プロジェクトマネジメントに固有なプロセス群を10の知識エリアに分けて示している。PDCAサイクルをプロジェクトマネジメントプロセスの基本としており、各知識エリアの総計47プロセスは立ち上げ、計画、実行、監視・コントロール、終結の5つに分類されて時系列的な把握が容易になっている。
  • プロジェクト&プログラムマネジメント（P2M）：経産省の主導のもとに開発された日本発のプロジェクトマネジメント知識体系。プロジェクトマネジメントにとどまらず、それを包含するプログラムマネジメントを規定している。企業など組織の戦略の具体化のために複数のプロジェクトを有機的に統合した事業単位をプログラムと呼ぶ。
  • プロジェクトにおける品質マネジメントの指針に関する規格（ISO10006)：ISO9000シリーズは個々のプロジェクトの品質マネジメントの機能や組織、技法を網羅していないのでISO10006が手引きを提供する。プロジェクトの規模、複雑さ、期間、実施環境に関わらず適用可能。
  • プロジェクト計画に関する規格（ISO/IEC/IEEE16326）：プロジェクトマネジメント計画書の標準的な章構成を9章構成で具体的に示し、各章ごとに記述すべき内容とその参考情報を詳しく述べている。
2.12.2プロセス設計におけるテーラリング
  • テーラリング：プロジェクトの成果を最大化するため、組織の標準プロセス群の集合を、プロジェクトの個別事情によって変更し、詳細化して「プロジェクトの定義されたプロセス」を定義すること。テーラリングの方法や制限をルール化することで、プロジェクト間のプロセスのばらつきを減らし、組織として定量的なプロジェクトマネジメントが可能になる。

＜プロジェクトレベル（個別）のソフトウェア品質マネジメント＞

2.13品質計画のマネジメント
  • ベンチマーキング：業界内外のすぐれたベストプラクティスと自組織のプロセスのパフォーマンスを比較し、そのギャップを分析することにより、プロセスを見直す一連の活動。
2.14要求分析のマネジメント
  • 機能要求：業務要求、ユーザー要求、システム要求の3つのレベルに分けられる。
  • 非機能要求：品質特性、制約条件、外部インターフェースの3つに分けられる。
2.14.1要求分析の計画
  • 要求分析の計画：要求抽出、要求分析、要求仕様化を対象とする。
2.14.2要求の妥当性確認と評価
  • 要求の妥当性確認：仕様書として文書化された要求が、もともとの要求の発生源としてのステークホルダーなどが真に求めるシステムを定義していることを確認すること。要求分析の初期段階でテスト計画とテストケースを作成し、妥当性を確認することも要求の問題を発見するために有効な手段。
  • 要求の評価：要求の明確さやリスクの抽出状況、要求間の整合性、記述の一貫性、明確性を確認すること。
2.15設計のマネジメント（設計の計画、方針の決定、評価）
  • 設計の計画：設計のプロセスや方針、用いる技法、評価方法を決定すること。開発プロセス、保守プロセスの局面において発生する。
  • 設計方針の決定：設計上の技法や、方法の選択を根本的に左右する基本戦略を関係者全員が共有できるように定めておくこと。ソフトウェアの構造に一貫性を持たせるための設計戦略を設計方針と呼ぶ。
  • 設計の評価：設計結果が要求仕様を正しく実現しているか、求められている品質目標を達成しているか、を設計成果物のレビュー、テスト、検査を実施し設計結果に評価を与えること。設計を評価する際は、設計の評価方法や評価基準の妥当性をチェックする。
2.16実装のマネジメント（実装の計画、方針の決定、評価）
  • 実装の計画：実装方法に従い、WBS、品質を含むメトリクスの目標値・計画値、コンポーネントを作成して結合する順序、品質管理プロセス、その他を定める。
  • 実装方針の決定：品質要求を含む各種の要求を満たすために必要な実装のルールを設定すること。採用する言語と再利用部品の利用、コーディングルールや規約、外部標準や内部標準の利用などを考慮する。
  • 実装の評価：実装結果が正しく要求仕様を実現しているか、求められている品質目標を達成しているかを実装成果物のレビュー、テスト、検査を実施し、実装結果に評価を与えること。主要な対象や作成したコード、修正もしくは変更したコード、再利用したコード、プロジェクトによる実装作業。
2.17レビューのマネジメント
  • デザインレビュー（設計審査）：品質保証のための合否判定の一手段として位置づけられている
  • レビュー計画：開催時期、対象成果物、レビューア、適用するレビュー方法及びリーディング技法などのレビュー計画。レビューの完了判断基準を明確にし、計画内容が妥当であるかを確認する。
  • リーディング技法：アドホック、チェックリスト（Checklist-BasedReading,CBR、肥大化に注意）、シナリオ（Scenario-Based Reading、SBR、シナリオ列挙に手間がかかる）、パースペクティブ（Perspective-Based Reading,PBR、手間がかかる）がある。
2.18テストのマネジメント
  • テストドキュメントに関する規格：IEEE　Std829は、テストドキュメントのテンプレート集。MasterとLevelにわかれている。ISO/IEC/IEEE29119-3は、テスト方針やテスト戦略に関するドキュメント、テスト環境やテストデータに関するドキュメントをすべて含んで体系化されている。
  • テストの組織：一般に、開発組織とは独立したテスト組織によってテストを実施するとテストの効果が向上する。
  • テストレベル：テストアクティビティのまとまりのこと。V字モデルにおいては、開発の4つの工程に対応して、コンポーネントテスト、結合テスト、システムテスト、受け入れテストの4つのテストに分けられる。
  • W字モデル：V字モデルの左側の開発工程の段階から対応するテストアクティビティを開始するプロセスモデル。上流工程ではレビューやインスペクションなどの静的テスト、下流工程では動的テストがアクティビティとなる。
  • テスト計画：プロジェクトで実施されるテスト活動の目的やスケジュールの定義など、テストにおける計画活動全般。
  • テストリスクマネジメント：プロジェクトあるいはプロダクトのりすくのうち、てすとにかかわる要素をマネジメントすること。実施すべきテストが漏れることにより発生しうる損害について、損害の発生確率や影響を最小限に抑えるようテストを計画し管理する。
  • テスト進捗マネジメント：テストプロセスが計画通りに進んでいるかどうかのモニタリングと、その結果をもとにした作業のコントロールを行うこと。消化状況や、障害情報、要求・仕様やコードに対する確認の網羅性などの情報を収集する。
  • テスト環境マネジメント：計算機などの設備やOSなどのソフトウェアの保守、管理、利用計画を作成し、管理する。
  • テストに関する規格（ISO/IEC/IEEE29119）：テストの考え方や用語、テストプロセス、テストドキュメントが示されている。
2.19品質分析・評価のマネジメント（プロダクト品質の分析・評価、プロセス品質の分析・評価）
  • プロダクト品質の分析・評価：品質分析・評価は品質に関するニーズを定義した品質要求に即して行わなければならない。品質要求は、障害件数の観点だけではなく、品質特性の観点などから定義する。
  • 品質要求定義：品質に関するニーズを定義したもの。品質特性、副特性、メトリクスを使って定義する。
  • プロセス品質の分析・評価：開発過程で得られる開発データを用いて、プロセスの実行結果を分析・評価すること。プロセスを実際に実行しているかどうか、実行結果は予定通りの効果をもたらしているか分析、評価する。プロセスは高品質のアウトプットを効率よく作り出す手段であることを肝に銘じ、プロセスが目的になってしまわないように留意する。
2.20リリース可否判定
  • リリース：プロセスの次の段階に進めることを認めること
  • 出荷判定：プロセスの次の段階が市場への出荷の場合は、出荷判定と呼ばれる。
  • 特別採用：規定要求事項に適合していない製品の使用またはリリースを認めること。リリース可否判定で不合格と判定された場合でも、製品の使用方法によっては許容できると判断されリリースが認められることがある。
2.21運用のマネジメント
  • SLM（サービスレベルマネジメント）：ITサービス提供者と、サービス利用者が事前にサービスの内容と品質水準について明示的に契約したSLAを達成するための継続的な品質改善を目指すマネジメント活動。
2.22保守のマネジメント
  • 保守に関する規格（ISO/IEC14764)：保守プロセスの実行計画立案、実行とコントロール、レビューと評価、終了に対するガイド。対象はプログラム、コード、データ、文書、開発時に作成した支援ソフトウェア(テストソフトウェア、テストデータベース、テスト環境など）。利用者がカスタマイズしたものは対象としない。
  • 是正保守：訂正の一部。ソフトウェア製品の引き渡し後に発見された問題を訂正するために行う受け身の修正。是正保守の一部として、緊急保守（是正保守実施までシステム運用を確保するために、計画外で一時的な修正）がある。
  • 予防保守：訂正の一部。引き渡し後のソフトウェアの潜在的な障害が運用障害になる前に発見し、是正を行うための修正。
  • 適応保守：改良の一部。引き渡し後、変化したまたは変化している環境においてソフトウェア製品を使用できるように保ち続けるために実施するソフトウェア製品の修正 。
  • 完全化保守：改良の一部。引き渡し後のソフトウェア製品の潜在的な障害が、故障として現れる前に、検出し訂正するための修正。