『 ソフトウェア品質知識体系ガイド(第3版)』学習メモ
第3版出版によせて
- ソフトウェアシステムは、あらゆる社会活動の基盤であるとともに、新たな価値創造の基盤
- 成功の鍵は品質
- 過去の失敗や成功の経験から学び続ける
- → 品質管理の本質をあらためて尋ねること
- → 不確実な時代に必要な知見を新たに探ること
- 成功の鍵は品質
- SQuBOK(Software Quality Body Of Knowledge)
- 品質にまつわる経験や知見を体系化し、その体系へと容易にアクセス可能とするガイド
- 第3版の改訂の要点
- 引き続き重要なsoftware_qualityの知識体系の再整理
- 国際規格の改訂の判定、セキュリティに代表される専門性の高い品質の知識拡充
- 不確実な時代に不可欠なデータ駆動および価値共創における価値共創にソフトウェアの品質の考え方を取り込んだ
- データとデジタル技術を通じたDXを進めるうえでデータ駆動および価値共創のパラダイムが根幹にあり、リスクを押さえつつその真価を最大限に発揮させるために必要な品質のマインドと技術の変革を整理
- 引き続き重要なsoftware_qualityの知識体系の再整理
- データ駆動は、データに基づき知的なサービスを適応的に提供しビジネスや社会上の価値を創造し続ける
- 従来のような明確な正解に基づく計画的な品質保証よりも、目標に対し仮説的に組み上げてモニタリングし、変化に応じ改善し続ける仮説検証および探索的な品質の組み入れが重要性を増す
- データやその源泉の規模および多様性に王子、セキュリティやプライバシー、相互運用性がより重要になる
- 価値共創 → 能動的にあらゆる時点でモニタリングおよびフィードバックし続けるという品質の組み入れが重要
はじめに
序章 SQuBOKガイド 概略
- 知識領域を5つのカテゴリに大別
- software_qualityの基本概念
- software_quality_management
- software_quality技術
- 専門的なsoftware_qualityの概念と技術
- software_qualityの応用領域
- 構成
- サブカテゴリ、知識領域、副知識領域を各カテゴリで見る
- Error(誤り、誤差), Fault(障害), Failure(故障)の区別
- Error: 計算、観測もしくは測定された値または状態と、真の、指定されたもしくは理論的に正しい値または状態との間の相違
- Fault: 要求された機能を遂行する機能単位の能力の、縮退または喪失を引き起こす、異常な状態
- ソフトウェアバグなど
- Failure: 要求された機能を遂行する、機能単位の能力がなくなること
- ソフトウェアが意図したとおりに動かない現象
- 意図しない結果を引き起こす人間の行為はmistake, human_errorとして別に定義
- メトリクスに関する擁護
- measure, measurement_methodがmetricに代えて使用されているが、これまでの論に合わせて測定量や測定方法を区別したりISO/IEC 25000シリーズに言及するとき以外は、「メトリクス」を用いる
Ch01 software_qualityの基本概念
KA: 品質の概念
- 品質の定義
- software_qualityの代表的な定義: 明示された状況下で使用するとき、明示的ニーズまたは暗黙のニーズを満たすためのソフトウェア製品の能力
- 品質の本質の理解のためには、顧客の要求把握、要求の実現、結果として得られる顧客満足という3つの要素から考える
- 顧客の要求
- 明示的要求や規制要求事項だけでなく、明示されない常識的な要求や潜在的なニーズや期待などを含む
- 時間の要素も考える
- 要求の取捨選択やバランスが重要
- 要求の実現
- 多くの技術の中から適切な技術を選ぶ
- 技術利用の場面では、プロジェクトに与えられたQCDやプロジェクトの技術レベル、プロセス、開発環境などのプロジェクト特性を考慮し、適用する技術の効果が出るように工夫が必要
- セキュリティインシデントのようなリスクを低減させつつ、つながることによる便益を最大限にするといった要求の実現が求められている
- 結果として得られる顧客満足
- ICTの進展に伴ってIoTやAIの適用が拡大するにつれ、品質に対する要求はますます多様な広がりと深さを増す
- IoTでは、セキュリティ、セーフティ、信頼性に加えて、プライバシーやレジリエンス（跳ね返る→前の位置に戻る、中止する）などが重要な特性
- AI では、AIの予測精度だけでなく、利用目的に応じて、公平性、説明可能性、プライバシー、信頼性、セキュリティ、セーフティなどさまざまな特性が求められる
- → 幅広い要求を説明する用語として、Trustworthinessが使われるようになった
- 企業と品質のソフトウェア
- 企業の視点からの品質の意味
- どのような経営環境の変化にも的確に対応し、顧客からの高い評価を受け続けることで、持続的な経営ができる
- 経営の要素として、ヒト、モノ、カネ、情報
- DXにより企業の経営スタイルやビジネスモデルは変革期にある
- ソフトウェアシステムは社会基盤として極めて重要な位置づけとなった
- 社会生活を支えるうえで求められる品質は多岐にわたり、継続的な維持と時代に合わせた変革が必要
- サービスの価値が利用体験の中で便益を享受したものが独自に見出すものであることから、企業と顧客の価値共創が品質の要となる
- このように、ソフトウェアの位置づけの変遷、価値の認知や送出スピードの変化を的確に把握して、製品やサービスの品質を考えることが肝要
- software_qualityに関する用語
- 序章のError, Fault, Failureの部分
- 機能性欠陥は、障害の定義に該当し、故障を引き起こす
- 発展性欠陥は、コードの読みやすさや構造などに起因し、コーディングルールなどの組織標準との乖離（anomaly）に相当する
- 保守工数の増大や機能性欠陥の誘発へとつながるものの、必ずしも故障を引き起こさない
- 開発途中の障害には発展性欠陥も含める
- S-KA: 品質の定義（品質の考え方の変遷）
- S-KA: software_qualityモデル
- ソフトウェアの品質を階層構造のモデルで表現したもの
- 誤りの有無のみで評価されるのではなく、ユーザのニーズを満たすために様々な視点のsoftware_quality特性から評価が必要
- T: システムおよびソフトウェア製品の品質モデル(ISO/IEC 25000シリーズ)
- システムおよびソフトウェア製品の品質要求と評価に関して規定している国際規格
- SQuaREシリーズと呼ぶ
- 利用時の品質モデル
- 利用者が実際に把握できる品質特性からなるモデル
- 有効性、効率性、満足性、リスク回避性、利用状況網羅性
- 製品品質モデル
- 機能適合性、性能効率性、互換性、使用性、信頼性、セキュリティ、保守性、移植性
- データ品質モデル特性
- 正確性、完全性、一貫性、信憑性、最新性、アクセシビリティ、標準的合成、機密性、効率性、精度、追跡可能性、理解性、可用性、移植性、回復性
- 25000 シリーズの構成
- 品質管理部門
- 共通するモデル、用語の定義
- 品質モデル部門
- 品質測定部門
- 品質要求部門
- 品質評価部門
- SQuaRE拡張部門
- 品質管理部門
- T: その他の品質モデル
- ソフトウェアの品質を階層構造のモデルで表現したもの
- KA: software_qualityの概念
- software_quality: 品質に関する「組織を指揮し、管理するための調整された活動」
- 主眼: 顧客の要求事項を満たすことおよび顧客の期待を超える努力をすること
- 急激なビジネス環境の変化に対応するために、組織の状況に応じて動的に適応できる能力が重要
- → 制御や統制というより、環境変化へ柔軟かつ臨機応変に適応しながら目的を達成していく活動といった意味に拡大解釈されるようになった
- 品質は、意図した機能やパフォーマンスだけでなく、顧客によって認識された価値および顧客に対する便益も含まれる
- ISO 9000では、software_qualityは全体を包括する用語
- 品質計画において、品質要求事項を満足するための基準などの計画を策定する
- → この計画にしたがって基準と照合し、基準を満足した製品とすることが品質管理
- 品質保証は、品質を確認する活動の実施状況を、証拠をもって示す活動
- 新製品開発重点主義
- 品質は設計と工程で作りこむ
- 要因系に焦点を当てるsoftware_qualityは日本で発達してきた方法であり、製品とサービスを作り出すプロセス重視のマネジメント
- 原因を排除することで、初めから品質の良いものを作り出すプロセスづくりを基本とする
- → プロセス実施状況を計測して分析し、プロセスを改善する
- S-KA: 品質保証の考え方
- ISO 9000では、品質保証を「品質要求事項が満たされるという確信を与えることに焦点を合わせたsoftware_qualityの一部」と定義
- 活動内容について、信頼感を付与するために証拠をもって示すよう要求
- 国や地域によって意味が異なる
- 方法は、プロセスのアウトプットであるプロダクトの品質を直接確認する方法と、プロセスの実行状況を監視することで品質が確実に作りこまれていることを確認する方法がある
- これらを、要求品質レベルに応じて組み合わせて実施することが大切であり、どちらかに偏っては不十分
- 不適合品の生成を減らす必要もあるし、不適合品を検出する必要もある
- → プロダクトとプロセスの両面から品質を確認することが肝要
- そのほか、V&Vや測定などの品質保証のための重要な手法も、要求品質レベルに合わせて実施する
- ISO 9000では、品質保証を「品質要求事項が満たされるという確信を与えることに焦点を合わせたsoftware_qualityの一部」と定義
- S-KA: 改善の考え方
- 改善: 市場や事業環境の変化へ効果的に対応する自己変革のメカニズム
- 目的を効率よく達成するためのすべての活動がマネジメント
- 改善はそのための武器
- 目的に対して、より効率よく達成するための方法を模索し、不備を明確にして自己を変えていく、論理的かつ体系的は修正が改善
- 基盤となる標準が必要
- → 組織の経験やノウハウを標準として整理し、その標準を出発点として不備を明確化し、修正する
- ISO 9000では、改善を「パフォーマンスを向上するための活動」、継続的改善を「パフォーマンスを向上するために繰り返し行われる活動」、革新を「価値を実現するまたは再配分する、新しいまたは変更された対象」と定義して区別している
- 本来の改善は、それぞれの意味を含む
- 急激な社会変化に対応するためには、抜本的な改善や革新を含めた「改善」が必要
- T: PDCA
- 計画では、目的、目標、狙いを明確にし、目的達成のための手段や方法を決定する。そして管理項目を決め目標値を設定する
- 実施では、管理項目のデータを取りながら計画を遂行する
- 確認では、目標達成にかかわる進捗や対応状況を、データをもとにして論理的に判断する
- 処置では、目的あるいは目標と実施の結果に差があるかを見て、その差に応じて対処し、次の計画に結びつける
- OODA
- 指揮官のあるべき意思決定プロセスを理論化したもの
- スピードと柔軟性を重視し、ループを高速で回して意思決定を繰り返す
- 計画の代わりに観察から始まるので、状況に応じて臨機応変に意思決定できる
- T: 改善(KAIZEN)
- 現状の不備を明確にして、その不備を論理的かつ体系的に修正する活動
- 目的: 品質、コスト、納期の向上を含む総合的なsoftware_qualityを達成すること
- 全員参加かつ継続的な活動
- すべての人がプロセスオーナーの意識
- 責任感と自負心の向上を促す
- → 組織全体で自律的に不備を修正
- ↑ 常に変化する事業環境や市場に対応するための重要な施策
- ソフトウェアでは細かいミスにより致命的な結果を招くことがあるので、改善(KAIZEN)は重要
- 常に新しい技術やサービスが生み出される市場でもある
- ツールとして、QC_circle活動
- TQM(Total_Quality_Management)の中核
- software_quality: 品質に関する「組織を指揮し、管理するための調整された活動」
- KA: ソフトウェアのsoftware_qualityの特徴
- 物理的実体を持たない論理の集合体なので、開発の工程はハードウェアの設計工程に近い
- 物理化学法則や空間的干渉がないという点で、自由度が高い
- → 構成要素の組み合わせが膨大になり、論理無住などの誤りを作りこみやすい
- 技術の変化が速いので、再利用部品の開発は難易度が高くなっている
- 論理の集合体であるソフトウェアは、外部仕様である働きとその働きを実現する内部仕様との2つを関連付けることが難しい
- → ソフトウェアを変更する際の難しさの本質
- 測定すべき物理特性がほとんど存在しないため、何らかの特性を定義しながら設計する必要がある
- 生産工程がないうえに測定が難しいので、ソフトウェアのテスト工程はハードウェアの検査工程とは異なる位置づけになる
- → ソフトウェアのテストはハードウェアのDR（設計レビュー）に対応し、非常に高いスキルが要求される
- 物理的実体がない → 劣化しない
- ソフトウェアの障害はすべて系統故障 → 同一の条件下では必ず障害が発生してしまう
- → 故障率やMTBFなどの信頼性指標では単純にソフトウェアの信頼性を表せない
- ソフトウェアの障害の体系化のためには、障害の原因調査、影響評価を行い、ソフトウェア故障モードを抽出する取り組みが必要
- 自然言語の使用
- 開発そのものが難しいだけでなく、開発のゴールを記述する仕様の信頼性も低くなりがち
- ソフトウェアの開発は人間の知的作業による
- 人間の知的作業の質は、モチベーションが大きく関係する
- → やりがいを感じ、快適と感じられる環境が必要
- チームワークやリーダーシップ、それらを支えるコミュニケーションも重視
- これらの特徴を十分理解したうえで、ソフトウェアのsoftware_qualityを実施する必要がある
- まず、定石やデザインパターンなどを用いて設計の自由度を抑制し、品質向上に寄与する指標を検討するといったソフトウェアエンジニアリングの充実が必要
- 仕様のレビューや管理も重要
- 次に、障害を分析することで、故障モードのようなソフトウェア開発の悪さの知識を抽出し、体系化したうえで蓄積が必要
- モチベーションとチームワーク
- 例: アジャイル
- 開発の難しさの本質は変わらないが、細かい単位の開発は、ソフトウェアの仕様のあいまいさやそれに伴う信頼性の低下を緩和する可能性がある
- S-KA: プロダクト品質とプロセス品質
- ソフトウェア製品のライフサイクルにおける品質を、製品そのものおよび過程の2つの側面から捉えた品質
- 図1.3.1: ライフサイクルでの品質
- ソフトウェア製品の品質を、内部特徴、外部特徴、利用時の品質の3つに分類し、それぞれが影響と依存の関係にあるとしている
- 一般的な製品の品質管理では、プロセス品質をプロセス能力や工程能力もしくは工程性能を呼ぶことがある
- プロセスの品質をアウトプットのばらつきとして捉え、このばらつきを収束させることでプロセスの安定した結果を保証できると考えているため
- プロセスのばらつきとして管理する対象は、プロセスの成果物の障害だけでなく、コストや納期なども対象になる
- ばらつきを収束させる活動として、プロセスの改善活動が行われる
- 初期の段階でばらつきの少ない状態を得ることを目的として品質工学の手法が適用されることもある
- 仕様の間違いやプログラムの誤り（一般的な障害）は、プロダクト品質のばらつきとして品質管理手法で制御可能
- ソフトウェアの仕様や機能の品質は、上流工程の規格や設計で作りこむ必要がある
- S-KA: 品質作りこみ技術の考え方
- 成果物を作成する過程で品質を確保するための作業を施し、後に続く工程に障害を流さないようにするという考え方に基づく技術
- 主に作成後のソフトウェアの評価を目的とするテストとは考え方が異なる
- 要求分析や設計の工程では、対象をモデル化してシミュレーションや形式手法による検証を実施することにより、要素間の干渉や矛盾を明らかにし、実現可能性を評価できる
- モデル化: 認知したい構造、振る舞い、現象などについて、別の効率的な形式や方法による表現を用いること
- 複雑さ、不可逆性を回避するよう単純化し、もとの現象などを扱いやすくすることが多い
- たいていは抽象化を伴う
- モデル化: 認知したい構造、振る舞い、現象などについて、別の効率的な形式や方法による表現を用いること
- モデルを用いたシミュレーションは、実装前にシステムの振る舞いを確認できるという点で、開発中に品質を作りこむ方法
- 数理的な理論に基づき厳密なモデルを作成できれば、形式仕様記述やモデル検査を提供する各種の形式手法を用いて、論理的な不整合の検出や動作の妥当性の検証が可能になる
- ソフトウェアパターンの適用もまた、開発中に品質の作りこみを期待できる方法
- ソフトウェアパターン: ソフトウェア開発の工程や領域の特定文脈上で繰り返される問題と、それに対して繰り返し適用されてきた熟練者による解決策をまとめて名づけ抽象化したもの
- 繰り返し利用されてきた解決策の思考過程と成果を再利用することにより生産性や品質の向上を期待できると同時に、適用対象の構造を一貫させ、利害関係者間のコミュニケーションや理解を促進する
- S-KA: システムおよびソフトウェアの測定と評価の考え方
- システムおよびソフトウェアの測定は、「測定量の値を決定するという目的を持った操作の集合」と定義されている
- 測定を本格的、体系的に導入する際は、多くの工数が必要になる
- 測定の妥当性や必要性を真の目的に照らして絶えず見直し続け、形骸化させないよう留意する
- システムおよびソフトウェアの評価は、「ある"もの"が、規定要求事項をどれだけ満たすことができるかの程度を示すための体系的な審査」と定義されている
- ソフトウェア製品の品質を向上させるためには、製品の品質上の属性の測定だけでなく、測定結果を活用した品質評価が不可欠
- 評価結果のよしあしの判断根拠となる要求事項があらかじめ明確化されていること、および、評価プロセスが確立されていることが必要
- 要求事項は、汎用の品質モデルを用いることで、品質特性と品質副特性を網羅的に定義できる
- 評価プロセスの共通的な枠組みは、「最初に評価要求を確立し、次に評価を仕様化し、設計し、そして実行する」プロセスとして定義されている
- S-KA: V&V(Verification & Validation, 検証と妥当性確認)
- Verification: 仕様適合性を確認
- Validation: ニーズ充足性を確認
- merit
- リスクが高い問題の早期発見
- システム要求に対する成果物の評価
- 品質と開発進捗状況に関する情報の継続的な共有
- システムのできばえが順次見えることによるユーザとの早期調整
- Independent V&Vもある
Ch02 software_quality_management
- 品質管理のためのアクティビティについて
- 品質は経営層から現場に至るすべてのレイヤの体系化されたアクティビティにより追求すべきものであり、品質管理に関するアクティビティは多岐にわたる
組織レベルのsoftware_quality_management
- KA: software_quality_management_systemの構築と運用
- quality_management_systemと改善アプローチ
- 主眼: 顧客の要求事項を満たすこと、および顧客の期待を超える努力をすること
- quality_management_systemは、quality_management活動のパフォーマンスを計画し、実行し、監視し、改善するための枠組みを提供する
- 有効性の改善には、プロセスアプローチが推奨される
- 相互に関連するプロセスで構成されるため、システムによって結果がどのように生み出されるかを理解することで、組織はシステムやそのパフォーマンスを最適化できる
- 急激なビジネス環境の変化 → quality_management_systemを動的なシステムとして捉えるようになった
- この場合も、計画の実施をquality_management_systemのパフォーマンスの両方を定期的に監視および評価することが重要
- quality_management_systemの特徴と対応
- ソフトウェアは、開発過程を見える化しにくく状況や状態を把握しづらい、論理の塊
- チームワークなどの人間的要素が強く品質へ影響するといった特徴
- → 見えにくい対象を把握し、論理の塊を技術面から整理して取り扱い可能にするとともに、開発者のチームワークやモチベーションを向上させる仕組みを持ったquality_management_systemを構築することがポイント
- 2つの責務
- 品質
- プロセス
- この2つの責務を明確にした組織形態がソフトウェアには必要
- 製品の品質に対する責務だけでは、プロセスを大きく変えるような革新的な技術を導入する機会を持ちにくい
- 両方の責務を持つという動機付けを持った組織が、quality_management_systemを推進することが重要
- 組織的かつ継続的にquality_management_systemを改善するには、障害の顕在化を契機として改善のサイクルを実行する活動が取り込みやすく効果的
- 真の原因を分析することで、その障害が二度と作りこまれないようにプロセスを改善する
- サービスも提供している場合はサービスも対象とする
- サービスの品質は、モノの品質との違いから考えるのではなく、サービスを中心において、その提供者と受容者が共創しながらサービスやモノの価値を作っていく
- SLAやDevOpsとも関係が不快
- サービスの品質は、モノの品質との違いから考えるのではなく、サービスを中心において、その提供者と受容者が共創しながらサービスやモノの価値を作っていく
- S-KA: quality_management_system
- quality_managementには、品質方針および品質目標の設定、ならびに品質計画、品質保証、品質管理および品質改善を通じて、これらの品質目標を達成するためのプロセスが含まれている
- 目指すべき品質目標は、トップマネジメントによる品質に関する方向付けのもと設定される
- 日本のTQCおよびTQMの発展の中で培われたquality_managementの考え方: お客様が安心して使っていただけるような製品を提供するためのすべての活動
- 徹底した顧客満足の追求や品質を中核とした全員参加での改善が基本
- 不十分でもとにかく動き出して全員が今より高いところを目指してプロセスそのものを動的に改善しながら進めるという、日本独特の考え方
- 欧米は、プロセスを定義してそのとおりに実行しているかどうかを確認する
- QC_circle、統計的技法などの道具を試用し、組織全体がシステムとして機能しているかのような日本型のマネジメントシステムのメリットは、全員が同じ目的に向かって活動するために効率的で無駄のない組織運営ができる点
- T: quality_management_systemに関する規格(ISO 9000 series)
- 目的
- 経済活動のグローバル化が世界的に進む中、スムーズな商取引のためにquality_management_systemへの要求事項の標準化が求められた
- quality_management_systemの認証制度により急速に普及
- 方法
- quality_management_systemの認証制度の基準規格はISO 9001
- 効果
- 認証により、自組織のquality_management_systemが世界に通用するものであることを証明するとともに、継続的な審査によりそれを維持できる
- 留意点
- 認証があっても品質に問題がないとは限らない
- コストに見合う改善効果が得られるとは限らない
- ISO 9001の要求事項への適合にとどまらず、製品およびサービスレベルの改善や顧客満足の向上を意識した改善活動をするとよい
- 目的
- T: TQM(Total_Quality_Management)
- 企業及び組織の経営の「質」の向上に貢献する経営科学および管理技術
- 「質」: 経営プロセス(Value_Chain)とそのプロセスに関わる広義のリソース(経営資源)の質
- QC, TQCに続く第3世代の品質管理
- 世代ごとに、製品そのもの → プロセス → 総合「質」が管理対象
- 持続可能な成長をもたらすための方法論として、TQCの強みを継承して生まれたのがTQM
- 目的
- 企業や組織が「尊敬される存在」「ステークホルダーと感動を共有できる関係」を目指し、「称賛される競争力(技術力、対応力、活力)」の向上を図る
- 方法
- 構成要素
- フィロソフィー、コア・マネジメントシステム、手法、運用技術
- これらの適用により、経営プロセスや経営リソースの質的向上を目指す
- 手法には、科学的問題解決法、QC7つ道具、新QC7つ道具など、ソフトウェア組織でもなじみ深い手法が含まれる
- 構成要素
- 効果
- 企業の競争力向上による収益力の増大を実現するとともに、重要な経営課題をいち早く察知し、解決することに貢献する
- 留意点
- TQMは、プロセスとして定義可能であり、結果を左右する要因を制御できるような領域に適用可能
- 政治的要因や文化的要因、情緒的要因などが大きくかかわるような領域では効果を発揮しにくい
- T: quality_management_system-持続的成功の指針
- 成熟した経済社会環境にある企業が、経営環境の変化に的確に対応し、顧客からの高い評価を受け続けることによって、財務的にも持続的に成功するような経営スタイルを実現するための指針を示す規格
- 目的
- 成熟した経済社会環境にある企業が、持続的成長を実現するための指針を与える
- 方法
- 品質という観点から事業運営を見直し、事業運営とは競争環境における顧客価値提供マネジメントであるとの視点に立ち、製品およびサービスを通して顧客にどのような価値を提供すべきか、その価値提供において組織が持つべき能力は何か、その能力はquality_management_systemのどの要素に実装されるべきかを考察する
- → 事業環境変化によって組織が持つべき能力がどう変わるかを認識し、革新していく
- 効果
- 企業が高い顧客価値を創造し続け、競争優位を確保し、持続的成功を実現できる
- 留意点
- 第1版での「質」とした（「品質」としなかった）理由について
- S-KA: security_management
- セキュリティ、すなわち守るべき資産の価値が損なわれる脅威を回避、もしくは軽減することを、組織全体を対象としてマネジメントすること
- T: common_criteria(CC)
- ソフトウェア、ファームウェアまたはハードウェアとして実装されたIT製品のセキュリティ評価のための共通基準
- 構成
- 一般的な概念とモデル、機能性に関する共通要件、保証手段に関する共通要件
- 評価プロセスにおいてCCのための共通評価方法(CEM)を使うことで、広範な対象者が国際的に共通の枠組みに基づいて評価結果を比較及び参照可能となっている
- CC/CEMと表記
- 主要各国のIT製品のセキュリティ評価認証制度に適用され、主に政府機関で調達要件として活用される
- 目的
- 方法
- 開発するソフトウェアのセキュリティ評価にCC/CEMを適用する一般的な方法
- そのソフトウェアに適用すべきPP(Protection_Profile)の有無を確認の上、保証のレベルと評価対象の範囲を特定
- CCを参照し、保護資産、脅威、セキュリティ目標、セキュリティ機能要件、セキュリティ保証要件、および要件の実現方法を定義するST(Security_Target)を作成する
- ソフトウェア開発において、STに従ってセキュリティ機能を実装するとともにCC/CEMを参考として実装の各プロセスである開発、ガイダンス、ライフサイクルサポート、テストおよび脆弱性への対応に係る保証手段がSTで定義したレベルを満たすことを保証するエビデンスを作成する
- ITセキュリティ評価認証制度を利用する場合、認証申請手続きとしてST を認証機関に提出後、第三者評価機関による評価を受け、評価結果について認証機関の確認を経て、そのソフトウェア製品に対する認証書を取得する
- 開発するソフトウェアのセキュリティ評価にCC/CEMを適用する一般的な方法
- 効果
- ソフトウェア開発において、セキュリティ要件を英利子、具備すべきセキュリティ機能と実施する保証手段の妥当性を国際基準に基づき自己評価するために役立つ
- ITセキュリティ評価制度の評価及び認証プロセスを通して、セキュリティ機能と保証手段がセキュリティ要件を満たしているかどうかを明らかにできる
- STおよびこれにもとづく保証がCC/CEMを満たし、要件に対して顕在化する脆弱性が存在しないことが本評価および認証プロセスで確認された場合、対象製品のCC 認証を取得でき、CC認証製品であることが求められる調達に参加できる
- STおよび評価結果は、製品の購入を検討する利用者が、その製品が利用者の使用用途に対して十分なセキュリティ機能性を具備しているか、仕様に当たって残存するセキュリティリスクを許容できるかを決定するために役立つ
- 留意点
- CC/CEMは随時更新されるため、評価を受ける場合に有効なバージョンを確認する必要がある
- T: ISMS(Information_Security_Management_System)
- その組織が自身の情報セキュリティを確保し維持するために、継続的に運用する枠組みのこと
- 範囲: 組織全体にわたってセキュリティ管理体制を構築し、監査することと、リスクマネジメントを実施すること
- JIPDECが日本国内におけるISMSの適合性評価制度の確立と普及推進を実施している
- 目的
- 企業や組織が、セキュリティポリシーにもどついたセキュリティレベルの設定やリスクアセスメントの実施などを継続的に運用することで、自身の情報セキュリティを確保し維持する
- 方法
- 参考規格が記載されている
- 効果
- ISMSを構築し運用することで、その組織は一定のセキュリティ管理レベルを維持できる
- 認証を受けた場合、取引先などに対し、情報セキュリティについて一定レベルの管理ができていることを示せる
- 留意点
- メリットとデメリットの整理が必要
- quality_management_systemと改善アプローチ
- KA: lifecycle_process_management
- ソフトウェアやシステムの構想から廃棄までの活動に対するマネジメント
- 主たる目的: ライフサイクルモデルを使うことで、発注者、ベンダー、サブコントラクターなど、すべての関係者が共通の言語を使え正確に意思の疎通を図れるようにすること
- プロセスをアセスメントして改善する国際標準ISO/IEC 33002におけるプロセス参照モデルとして活用することなども想定
- 安全性を重視するソフトウェアの品質の確保には、ソフトウェア自体の機能的要因だけでなく、その開発過程に係る要因を考慮する必要があるとの認識から、safety_critical_lifecycle_modelが提案されるようになった
- ライフサイクルモデルにおけるプロセスモデルとは、ライフサイクルモデルが定義する活動のうち、開発部分をモデル化したもの
- プロセスモデルは、さまざまな開発方法論で定義する開発作業をプロセスとして構成し、開発工程と手順を抽象化してモデル化している
- 開発の内容や特性に応じてモデルの選定が必要
- S-KA: ライフサイクルモデル
- ソフトウェアおよびシステムの構想から廃棄までの活動を、特定の開発方法論およびベンダに依存しない「共通の言語」として制定したもの
- 多様なニーズに対して製品やサービスの統合が困難になったという問題の克服が必要になったため生まれた
- 方法
- ソフトウェアおよびシステムの企画、要求定義から廃棄、処分までのライフサイクルにわたるプロセスを包括的に規定
- 使用者は目的に応じて、組織、プロジェクト、業務に合わせて部分集合を選択したりテーラリングしたりする
- 効果
- 当事者間で開発手順、工程、作業内容、用語などが異なることから生じうるコストや品質面の混乱の防止
- 留意点
- 深い解釈や実際の行動面まで整合させると〇
- S-KA: プロセスモデル
- KA: ソフトウェアプロセス評価と改善
- ソフトウェアプロセスをプロセスアセスメントモデルに照らして評価し、それを継続的に改善する活動のこと
- 求める結果を獲得するためにソフトウェアプロセスを意図的に変更・改善する
- プロセスを系統的、継続的に改善するためには、プロセスに関する定量的なメトリクスを定義したうえで収集、分析し、評価することが必要
- 改善の対象は、ソフトウェア開発の技術やツールなどを含めた一連の工程、プロセス
- 包括的なプロセスモデルとしては、CMMI(Capability_Maturity_Model_Integration)など
- ISO/IEC 33000シリーズなど特定の産業や分野によらない汎用的なモデルがある一方で、Automotive SPICEやTMMiなど特定の業界及び分野に特化したプロセスモデルも提案されている
- プロセスモデル適合の目的化やトップダウン偏重による形骸化の回避のため、問題解決型アプローチも提案されている
- 特徴を十分に理解したうえでのプロセスモデルの活用、そしてそのプロセスがエンジニアのスキルやモチベーションにどのような影響があるかといった人的配慮を含めた本質的なプロセス改善のあり方について、引き続き検討が必要
- S-KA: software_process_evaluation_model
- ソフトウェアプロセスの改善を目的として作成されたプロセスモデル
- T: CMMI
- 顧客やエンドユーザのニーズを満たすための高品質な製品とサービスを開発する活動に対して、包括的で統合された一連の指針を提供するモデル
- 「システムや成果物の品質は、それを開発し保守するために用いられるプロセスの品質によって大きく影響される」というプロセス管理の前提にもとづいて開発された
- → 事業者が主要な事業プロセスの実績を改善することを可能にする、統合されたベストプラクティスの集合
- 単なるプロセス改善モデルから、ビジネス上のパフォーマンスを向上するためのモデルという位置づけに変わってきている
- 組織におけるプロセス改善に焦点
- 場当たり的で未成熟なプロセスから、改善された品質と有効性を伴った秩序ある成熟したプロセスへの深化の改善経路を、プラクティス領域により示す
- 成熟度レベル
- プロセス領域の集合に1つ1つ順番に取り組むことにより、関連するプロセスの集合を組織が改善するアプローチ
- 能力度レベル
- 組織が選択したプロセスを1つ1つ改善するアプローチ
- 今後、セーフティやセキュリティ管理、人材管理のプラクティスが追加される予定
- Method_Definition_Document(MDD)
- ベンチマーク、持続型、対応計画再評定、評価型
- 目的
- 製品の開発と保守、サービス提供、調達に関するプロセスの成熟度レベルおよび能力度レベルを、内部プロセス改善および外部向け成熟度および能力判定のために示す
- 方法
- MDDに定義された評定方法により、CMMIの選択した関連要素群と表現に照らして評定する
- 効果
- 客観的証拠に基づいた評定結果を提供できる
- 留意点
- 成熟度レベルや能力レベルの達成が、手段から目的に転化し、実際のプロセス改善に結びつかない場合がある
- → 真の目的を理解した上位管理者のリーダーシップのもと、現場の改善を推進するための資源の確保が〇
- T: プロセスアセスメントに関する規格(ISO/IEC 33000シリーズ)
- 目的
- 製品の開発と保守、サービス提供に関連するプロセスの能力レベルを、次の目的のために評価
- プロセス改善のために自己のプロセスの状態を理解する
- 特定の要求事項に対する自己のプロセスの適切性を判定する
- 契約相手のプロセスの適切性を判定する
- 製品の開発と保守、サービス提供に関連するプロセスの能力レベルを、次の目的のために評価
- 方法
- PRM(Process_Reference_Model)、測定の枠組み、PAM(Process_Assessment_Model)によりアセスメントを行い、プロセスの能力レベルを判定する
- 効果
- 目的に対して客観的証拠に基づいたアセスメント結果を提供できる
- 留意点
- 能力レベルの達成が、手段から目的に転化することがある
- → 真の目的を理解した上位管理者のリーダーシップのもと、現場の改善を推進するための資源の確保、さらに実務層が当事者意識を持ち取り組む環境の構築が〇
- 目的
- T: Automotive SPICE(Software Process Improvement and Capability dEtermination)
- T: TMMi(Testing Maturity Model Integration)
- テストプロセスを段階的に改善していくための技法
- CMMIと親和性が高く、テストプロセス部分を補完するモデル
- このほかに、TPI(Test Process Improvement)もある
- TMap(Test Management approach for structure testing)という構造化されたテストプロセスの方法論をベースにしている
- TPI NEXT
- BDTPI(Business Driven Test Process Improvement)を基本モデルとして利用したもの
- 目的
- 方法
- CMMIと同様に5段階の水準とそのゴールで構成されている
- 各水準は以下で構成されており、アセスメントをサポートするためのTMM-AM(TMM Assessment Model)を持つ
- 成熟度ゴールのセット
- 成熟度ゴールを支援するサブゴール
- アクティビティとタスクとレスポンジビリティ
- 効果
- 留意点
- S-KA: ソフトウェアプロセス改善技法
- 品質の良いソフトウェアを開発するために必要な、さまざまな作業のフレームワーク改善を目的とした技法
- T: Six_Sigma
- アメリカにおける品質革命運動の中心的な経営革新技法
- 標準偏差(σ)の6倍という意味
- 品質特性が正規分布に従っているとき、規格幅が±6σ分あると、特性地の分布の平均が1.5σずれていても、不良率は片側4.5σ外の確率3.4ppmに抑えられる、すなわちミスを無視できるレベルまで下げるための方法論
- DMAIC(Define, Measurement, Analysis, Improvement, Control)を繰り返すことで、6σのミス発生確率を達成する
- 目的
- 企業活動で発生するミスの確率を100万分の3.4以下にすることで、顧客満足度を向上し、よりよく、より早く、よりローコストを実現するとともに、競争優位獲得のための企業文化を構築
- 方法
- MAICまたはDMAICと呼ばれるシックスシグマ達成プロセスを繰り返し、6σのミス発生率を達成する
- 効果
- 全社最適化の発想により、事業目標を論理的にブレークダウンして実行する枠組みを持つ
- T: IDEAL
- T: PSP(Personal Software Process), TSP(Team Software Process)
- T: 企業などで考案された改善技法
- KA: 検査のマネジメント
- 検査活動の主眼は、製品を顧客に提供してよいかどうかの合否判定にある
- 検査部門、または品質保証部門と呼ばれる組織での実施が多い
- 顧客の立場に立ち客観的な視点で検査を行う必要がある
- 開発の途中段階から品質把握に努め、適宜、開発部門に品質向上策を推進させる必要がある
- 品質上の問題を後工程に持ち越さないための工夫が必要
- 検査計画
- 方針、体制、方法、検査環境および日程などの基本的な計画を明確にし、検査計画書を作成する
- ドキュメントの検査や製品の検査内容を盛り込む
- 過去の検査実績を十分把握して計画に反映する
- 関係部署とのレビューを行いステークホルダーに事前に明示
- 計画との照合、フィードバック
- 方針、体制、方法、検査環境および日程などの基本的な計画を明確にし、検査計画書を作成する
- ドキュメントの検査
- レビュー結果が設計書に確実に反映されていることの確認も必要
- ユーザマニュアルは、設計書と矛盾がないか、ユーザが理解しやすく読みやすい文章になっているか検査
- 中間品質監査
- 各開発工程の完了時に、次工程に向けてドキュメントなどの中間成果物や製品の品質が確保されているかの確認のために各工程の品質把握をする
- ドキュメントレビューの結果評価による設計工程完了監査、テストでの摘出障害件数や摘出傾向の妥当性評価によるテスト工程完了監査
- 製品検査
- 検査部門自らが、テスト項目の設計、テストツール、テストプログラム、テストデータなどのテストジョブの作成、テスト環境の構築を行い、製品検査を実施する
- ユーザの視点で、ユーザが製品に仕様する環境と同等の環境において実際に製品を動作させ、検証や妥当性確認を行う
- 開発部門のテスト結果も確認して、最終的な合否を判定
- 出荷後の活動
- 合格と判断して出荷した製品品質に対して責任を持つ
- 問題が生じた場合、同様の問題を起こさないよう、開発プロセスや自らの検査プロセスへフィードバックする
- 製品品質の責任部署として、出荷後問題のとりまとめや対応を行う場合もある
- KA: 監査のマネジメント
- 監査: 管理対象となる活動が、組織によって選択された基準をどの程度遵守しているかを、収集した証拠をもとに、客観的、体系的に評価する活動
- 監査の基準の前提として、その組織ですでに確立している組織規範を用いることもあれば、将来に向けて確立と定着を図る目的で、品質マネジメント規格などをもとに新しく定めた組織規範を用いる場合もある
- 組織方針、品質規格、規準などを明示的に文書化したものを用いるのが一般的だが、多くはその組織がこれまで培ってきた知識、経験をもとにした「あるべき姿」を整理した「組織固有の考え方」を含んでいる
- 目的
- 監査活動による組織プロセスの改善
- 組織内での適切な組織規範の遵守を担保することによる信頼の付与
- プロセス遵守状況の経営者によるレビューの実施
- 一般的な活動サイクル
- 監査計画の立案、監査の実施、監査の記録、監査のモニタリングとレビュー
- T: 購買先プロセス監査
- 購入者が購買先に対して、作業プロセスが適正なものか、標準に対する遵守状況はどの程度かを確認し、必要に応じて作業プロセスの是正および改善勧告を行うこと
- 第二者監査
- T: ソフトウェア開発における監査
- プロセスに焦点を当てて実施するプロセス監査および製品に焦点を当てて実施するプロダクト監査
- KA: 教育および育成のマネジメント
- 人材育成計画の立案と、それに従った教育および育成カリキュラムの整備、各個人の専門性の育成を管理するキャリア管理に分かれ、企業全体として取り組むべきマネジメント
- 人材に必要なスキルおよび知識
- S-KA: スキル標準
- S-KA: 開発現場における教育および育成のマネジメント
- チームビルディングについて
- キャリア開発計画: 目標となる職務を目指したキャリアパスにそって、経験すべき職務や開発すべき能力をまとめた計画
- キャリアは個人の生涯にわたって継続するもので、その人の仕事に対する自己イメージを反映したものであり、個人の人間的成長や自己実現の軌跡でもある
- 職務経歴の中で、経験すべき職務、開発すべき能力を自律的に計画して、職務移動の節目にキャリアを意識しながら職務を選択することが個人に求められる
- 目的
- 仕事に意欲を持って働き、個人およびチームの職務能力を向上する
- 方法
- キャリア開発計画では、目標となる職務を設定して、それを実現するための計画を立案する
- 品質に関する向上意欲を高めるための動機付け
- 具体例
- 高品質な製品およびサービスはコストカットでき利益を生み、顧客の信頼も得られ、経営的に貢献度が高いことを伝える
- 障害を隠蔽せずに報告することを妨げない組織文化を作る
- 品質目標達成の表彰制度などを設ける
- 具体例
- チームビルディングを進めるうえで、たとえば、アジャイル開発で実施されているスプリントの振り返りは成長の機会となり、チーム学習やチーム改善の活動となる
- 効果
- 人的資源のパフォーマンス向上
- 留意点
- 労務管理が必要
- KA: 法的権利および法的責任のマネジメント
プロジェクトレベル（共通）のsoftware_quality_management
- KA: 意思決定のマネジメント
- ビジネス上の判断もできる必要
- KA: 調達のマネジメント
- QCDを満足させるために必要となる既製の製品やサービス、技術者などの人的資源を外部から調達し、そのコスト、品質をマネジメントすること
- 背景: 市場や顧客の要請
- S-KA: 請負契約による外部委託
- 方法
- 委託先のソフトウェア開発プロセスの確認
- 委託先への要求仕様の提示
- 委託先が海外企業である場合
- 方法
- KA: リスクマネジメント
- 定義
- リスクについて、組織を指揮統制するための調整された活動
- 技術、コストまたはスケジュールに関する潜在的危険度を含んだプロジェクトの対象領域の管理
- リスクの定義
- 目的に対する不確かさの影響
- 起こり得る事象、結果、またはこれらの組み合わせについて述べることで、その特徴を記述する
- ある事象(周辺状況の変化も含む)の結果とその発生の起こりやすさとの組み合わせで表現
- 発生が不確実な事象または状態であり、もし発生した場合、1つ以上のプロジェクト目標にプラスまたはマイナスの影響を及ぼすもの
- 危害の発生確率およびその危害の度合の組み合わせ
- 継続的にリスクを識別する技法が必要
- リスクの発生可能性や発生後の影響を考慮して優先度の決定が必要
- ステークホルダーの参画方法やリスクを判断する規準などを予め明らかにする必要
- ↑ 立場によって捉えるべきリスクが異なるため
- S-KA: リスクマネジメントプロセス
- 定義
- 方針、手順および方策を、コミュニケーションおよび協議、状況の確定、ならびにリスクのアセスメント、対応、モニタリング、レビュー、記録作成および報告の活動に体系的に適用すること
- リスクを継続的に識別子、分析し、取り扱い、監視することを目的とする
- リスクマネジメントシステム: リスクマネジメントプロセスそのものを維持する枠組みと、実際のリスク分析を行うリスクマネジメントプロセスの実施に分けられる
- 目的
- プロジェクト成功の可能性を高めるために、リスクの発生確率と影響度を減少させる
- 方法
- アクティビティ
- リスクマネジメントの計画および実行
- プロジェクトリスク台帳の管理
- リスク分析の実施
- リスク監視の実施
- リスク対応の実施
- リスクマネジメントプロセスの評価
- これらのアクティビティを実際に運用するために必要となる計画書やリスク台帳、および運用主体となる組織などからなるリスクマネジメントシステムを整備する
- アクティビティ
- 効果
- 組織の事情に応じた、動的で、繰り返し行われ、変化に対応できるリスクマネジメントができる
- 留意点
- リスクマネジメントは、組織の主要な活動およびプロセスから切離された単独の活動ではなく、適用する組織の既存のプロセスを考慮しながら適用すると〇
- 定義
- S-KA: リスク識別および特定
- 目的
- 対象となるシステムやプロジェクトのリスクをもれなく識別する
- 方法
- データを収集し、当該システムやプロジェクトに関する専門家の意見を考慮しリスクをもれなく識別する
- データ収集方法
- チェックリスト
- ブレーンストーミング
- ブレーンライティング
- 実務家や専門家へのインタビュー
- 根本原因分析
- 前提条件と制約条件の分析
- SWOT分析
- 文書分析
- 特定の分野での技法
- FMEA(Failure Mode and Effects Analysis)法
- FTA(Fault Tree Analysis)法
- HAZOP(Hazard and Operability Studies)法
- AFD(Anticipatory Failure Determination)法
- HHM(Hierarchical Holographic Modeling)法
- 上の技法と併せてリスク区分を用いる
- 効果
- リスクをもれなく識別
- 留意点
- 対象とする分野に合わせた最適な技法を組み合わせるのが〇
- ステークホルダーの多様な知識や経験を持ちより、漏れを極力なくす
- 外部環境の変化に応じてリスクが有効なのか、新たなリスクが識別されないかなど考慮して更新する
- 目的
- S-KA: リスク分析と算定
- S-KA: リスク評価および対応
- リスク評価
- リスク分析の結果をリスク基準と比較
- ステークホルダーが優先順位を決定
- リスク対応
- 軽減、排除、予防、低減
- 目的
- リスク分析の成果に基づき、どのリスクへの対応が必要か、対応の優先順位をどうするかについて意思決定を支援
- 方法
- 代替案分析: 作業を完成する複数の方法を比較し、最適な方法を決める
- 費用便益分析
- 効果
- リスクに対し、優先順位に基づいた対応を行える
- 留意点
- 優先順位が高いリスクについては、すべてに対応
- 著しい困難が伴う、または費用がかかる場合は、すぐに対応しようとせず、定期的に外套のリスクが解消していないか、あるいは新たな対応が行えるようになっているか監視する
- リスク評価
- 定義
- KA: 構成管理
- ライフサイクルを通じてソフトウェア作業成果物（ドキュメントやソースコードなど）、およびそれ以外のシステムを構成する要素（OSやフレームワーク、DB、開発環境、ハードウェアなど）を識別し、その組み合わせの結果と変化を管理し、特定の時点における構成の再現および追跡を可能とすること
- システムやソフトウェアライフサイクルの全般にわたり、構成要素の機能や特性を特定可能にし、それらに対する変更を管理および検証し、その状況を記録する活動
- → 要素間やその変化が追跡可能になる
- 目的に対して正しいソフトウェア成果物の構成が得られるため、取り出しミスや認識の不一致など品質に負の影響を与えかねない損失や手戻りを防止できる
- 活動内容
- 構成要素の識別とベースラインの設定
- 構成を制御するための変更管理
- 構成要素への変更履歴を管理するバージョン管理
- 品目の完全性、一貫性および正確性を保証するための構成評価
- 複数の構成要素間の関係を管理するinterface管理
- 正しい構成要素の組み合わせを配布するためのビルド・リリース管理
- 広義では、変更管理プロセスも構成管理プロセスに含まれる
- 変更管理プロセスとバージョン管理を統一する方式が〇
- ツールを用いて変更管理プロセスとバージョン管理を統一する方式を取り入れることで、ソースコードに触れられないステークホルダーでも、バグやタスクの情報からソフトウェア開発の進捗状況や品質情報を得られるようになる
- 識別粒度の違いも吸収できる
- S-KA: 変更管理
- 構成管理下の構成要素を変更するためのアクティビティ
- 目的
- 提案された変更要求を深く吟味し、確実にシステムへ反映する
- 方法
- 変更管理の一般的な管理手順
- 変更要求を受け取り、評価を実施
- 変更管理委員会が変更を行うことを決定し、リソースを確保し、修正担当者に割り当て
- 修正担当者が変更を実施し、検証する
- 検証が終わり、修正済みの作業成果物をリリース
- 開発の責任者は、上記のような変更管理プロセスを定義し、変更管理ポリシーを定義する
- 開発者全員に周知徹底
- 変更管理委員会は、構成管理委員会またはCCB(Change Control Board)と呼ばれ、提案された変更要求と新しく提案された機能のどれを受け入れるかを決定する人々の集合
- 実際には設計部署の管理者、リーダークラスで構成されることが多い
- CCBは一度決定したベースラインの成果物に対して、変更を受け入れることの便益と影響を精査する
- 便益: 顧客満足度の向上や競争力の優位
- 影響: コスト、リリースの遅れ、品質劣化
- 変更管理の一般的な管理手順
- 効果
- 決められたプロセスを経ることで、変更要求の内容や影響をステークホルダー間で共有でき、提案された変更要求を正しく確実に反映できる
- 留意点
- 影響分析が重要
- 知見のある開発者に影響分析を指示
- 要領
- 変更要求と既存の要求との矛盾
- 変更を行うことのリスク、技術的な懸念、副作用、スキル面の妥当性
- 変更による品質要求への悪影響
- 現在進行中のプロジェクト計画に与える影響、開発環境に与える影響
- 既存資産(設計、ソース、テストケースなど)に与える影響
- 影響分析の結果を参考に、変更依頼の承認/却下の判断
- 影響分析が重要
- S-KA: バージョン管理
- ベースラインからの変更内容を把握可能にする管理
- ライフサイクルにおけるソフトウェア要素の変更履歴を管理し、任意の変更が反映されたバージョンを一意に識別
- 目的
- 特定の時点でのソフトウェアを復元できるように、ソフトウェアのバージョンを適切に管理する
- 方法
- バージョン管理ツールの使用
- 効果
- バージョン管理を適切に行うことで、必要なときに必要なバージョンを復元できる
- 特に、障害や故障時における現象を再現し、原因調査などを行う際に重要
- バージョン管理を適切に行うことで、必要なときに必要なバージョンを復元できる
- 留意点
- 各粒度でバージョン管理が必要
- 構成管理におけるほかのアクティビティと密接な関係
- ブランチの管理が必要な場合もある
- 各粒度でバージョン管理が必要
- ベースラインからの変更内容を把握可能にする管理
- S-KA: 不具合管理
- 目的
- 不具合によって発生する構成要素への変更と併せて、不具合の解決がなされたことを管理
- スムーズな不具合解決を目指す
- 方法
- 一般的な手順
- 不具合が発見された場合、報告された内容に基づき、その現象の再現と原因の調査を実施する
- 現象の再現は、不具合が発見されたソフトウェアのバージョンにて、現象を再現する環境を構築し調査を実施する
- 調査の結果、構成要素への変更が必要と判断された場合は、変更作業を行う
- 変更管理やバージョン管理も併せて実施
- 不具合が発見された場合、報告された内容に基づき、その現象の再現と原因の調査を実施する
- 個々の不具合の作業ステータスの管理が必要
- 発見から対処完了、優先度など
- 一般的な手順
- 効果
- 例えばテスト期間中の不具合解決の促進が可能
- 不具合管理を通じて収集した不具合情報を分析することで、プロセスや製品の改善すべき情報を得られる
- 留意点
- 不具合が多く発生する期間では、情報の収集について工夫が必要
- 例えば構成管理と結びつけた厳格な不具合管理など
- 不具合が多く発生する期間では、情報の収集について工夫が必要
- 目的
- S-KA: トレーサビリティ管理
- 目的
- 主に変更要求が発生した際の影響調査、および変更対象の特定を容易にするため、要求事項と、プログラムやモジュールなどのソフトウェア品目を追跡可能な状態に管理する
- 方法
- 管理する側の視点と管理する情報を考慮することで、いくつかの異なるアプローチ
- 要求のトレーサビリティ管理
- 獲得、分析、仕様化した要求の構造がどのように設計、構築に展開されていくかを管理する
- 成果物のトレーサビリティ管理
- 要求定義、方式設計、詳細設計、構築、テストの各アクティビティにおける成果物がどのようにつながっているかを管理する
- 製品のトレーサビリティ管理
- ソフトウェアの構成要素がソフトウェア製品にどのように組み込まれているかを管理する
- 要求のトレーサビリティ管理
- 管理する側の視点と管理する情報を考慮することで、いくつかの異なるアプローチ
- 効果
- いずれのアプローチも変更要求が発生した際に効力を発揮
- 例えば、変更要求が提案された場合の影響分析において、その変更がどの機能、ソフトウェア品目に影響するのか、テストがどれくらい必要か、などについて容易に調査可能になる
- いずれのアプローチも変更要求が発生した際に効力を発揮
- 留意点
- いずれのアプローチも、ソフトウェア・トレーサビリティをどのように管理するかというテーマに対処するもの
- 開発現場においては、現状の課題に対応したトレーサビリティ管理が求められる
- 目的
- KA: プロジェクトマネジメント
- 品質やコスト、納期などの制約の下で個々のプロジェクトの目標を達成するための計画立案や実行管理を行うこと
- ますます複雑かつ大規模化している情報システムの分野でも、あらゆるシステムの構築にプロジェクトマネジメントが欠かせない
- S-KA: PMBOK(プロジェクトマネジメント知識体系)
- よい実務慣行と一般的に認められているプロジェクトマネジメントの実施方法の集大成
- 10の知識エリア
- プロジェクト統合マネジメント
- プロジェクトスコープマネジメント
- プロジェクトスケジュールマネジメント
- プロジェクトコストマネジメント
- プロジェクト品質マネジメント
- プロジェクト資源マネジメント
- プロジェクトコミュニケーションマネジメント
- プロジェクトリスクマネジメント
- プロジェクト調達マネジメント
- プロジェクトステークホルダーマネジメント
- PDCAサイクルをプロジェクトマネジメントプロセスの基本としている
- 各プロセスはインプット、ツールと技法、アウトプットの3つで構成されている
- 目的
- プロジェクトマネジメントに関する優れた実務慣行などを特定する
- プロジェクトマネジメントの標準用語集とし、遂行上で関係者間の共通の理解の獲得に役立てる
- 方法
- 効果
- 留意点
- 明確なゴールの定義が難しい価値創造型プロジェクトにおいては、明確な計画策定やリスク洗い出しが困難となるため、状況に応じた高度な対応が必要になる
- 理想的なスキルセット
- テクニカル・プロジェクトマネジメント
- リーダーシップ
- 戦略的およびビジネスのマネジメント
- S-KA: プロジェクトマネジメントに関する規格
プロジェクトレベル（個別）のsoftware_quality_management
- KA: 品質計画のマネジメント
- 効果的かつ適切な品質計画のマネジメント
- 以下の事項を実施
- 1.製品およびサービスに関する要求事項の明確化
- 2.プロセス、製品およびサービスの合否判定に関する基準の設定
- 3.製品およびサービスの要求事項への適合を達成するために必要な資源の明確化
- 4.2の基準に従ったプロセスの管理の実施
- 5.次の目的のために必要な程度の、文書化した情報の明確化、維持および保持
- プロセスが計画通りに実施されたという確信を持つ
- 製品およびサービスの要求事項への適合を実証
- 品質計画書: 特定の製品やプロジェクト、契約に適用される品質マネジメントシステムの、プロセスおよび資源を規定する文書
- コスト面から、早い段階でレビューやテストによって設計やソースコードを確認するように計画する
- 要求品質を確保するために工数をかけ、あるいはスキルのある人を入れるなどして必要十分なコストをかける計画にすることも必要
- 競争力のある目標を設定するためには、ベンチマーキングにより世の中の水準や別組織との比較をすることも必要
- T: 品質計画書
- プロセス、製品、プロジェクトまたは契約の要求事項を、製品実現を支援する作業方法および慣行に関連付ける手段
- プロジェクト計画書の一部、レビュー計画書、テスト計画書など複数の計画書で構成されることが多い
- 目的
- 要求される品質の目標を設定し、それを達成するためのプロセスを定めることで、顧客満足の向上を目指す
- 文書化することで、計画を関係者と合意
- 方法
- 効果
- 品質目標を明確にして、その管理対象や達成状況の評価プロセスを定めることで、提供するソフトウェアの品質を保証し、さらにプロセスの改善に結びつけられる
- 文書として明示することで、関係者とプロセスや目標を共有できる
- 留意点
- 用いるレビュー技法やテストツール、基準とするメトリクス、進捗や実行結果の管理プロセスも計画に含めると、品質目標の達成度評価やプロセスの改善を実現しやすくなる
- 品質計画書は組織によって呼称や範囲が様々
- T: 費用便益分析
- T: ベンチマーキング
- 種類
- 自組織内を比較対象とするインターナルベンチマーキング
- 競合組織を比較対象とするコンペティティブベンチマーキング
- 業種に関係なく類似の組織機能を比較対象とするファンクショナルベンチマーキング
- 業種に関係なくビジネスプロセスを比較対象とするプロセスベンチマーキング
- 目的
- ベストプラクティスと自らの業務を比較して、結果を導入することで、自組織の業務を改善・改革
- 方法
- ベンチマーキングを行うプロセスの決定
- 信頼のおける比較対象とその情報源を選択
- 比較対象と自組織のプロセスパフォーマンスを比較し、ギャップを分析して、改善のための検討を行い、指標を決定する
- 設定した指標をもとに目標値を定めて、自組織の改善計画を立案し実行する
- 効果
- ベストプラクティスに基づいて自組織の目標を設定することで、業務改善・改革につながる
- プロセスパフォーマンスが向上することで、収益などの経営指標の改善が期待できる
- 留意点
- 単なる比較分析はベンチマーキングではない
- ベストプラクティスと自組織の実施方法とのギャップを分析し、プロセスを見直し、その効果を確認して改善や革新に結びつけるまでがベンチマーキング（行動を伴う必要）
- 種類
- KA: 要求分析のマネジメント
- 要求分析の計画
- 要求抽出
- 要求分析
- 異なるステークホルダーから抽出された要求間の競合を解決し、システムの境界、システムとハードウェアや人などとのinterfaceを定め、システム要求からソフトウェア要求へと詳細化すること
- 要求間の優先順位を明確化し、ユーザと合意する
- 優先順位付け
- 企業目標やビジネス戦略に合わせたKPIやBSCを用いることもある
- 予算や期間の制約によっては実現しないと決める要求もあり、要求のマネジメントを始める時期でもある
- 要求仕様化
- 要求の妥当性確認と評価
- 妥当性確認
- 仕様書として文書化された要求が、もともとの要求の発生源としてのステークホルダーなどが真に求めるシステムを定義していることを確認すること
- レビューやプロトタイピング、受入テストの検討などを通じて行われ、要求文書の誤りや間違った仮定などを見出す
- 評価
- 要求の明確さとリスクの抽出状況、要求間の整合性、記述の一貫性、明瞭性などを確認すること
- レビューをなどを通じて実施(妥当性確認と同じく)
- 要求分析の初期段階でテスト計画とテストケースを作成し、妥当性を確認することが有効
- ↑ テストは遅い段階のアクティビティになりがちなため
- 妥当性確認
- 要求分析の計画
- KA: 設計のマネジメント
- 設計: 指定された要求を満足するために、アーキテクチャ、システム要素、interface、データを定義するプロセス
- ソフトウェア設計のアクティビティを規定した計画を定め、要求されている品質特性と顧客ニーズを満たす設計結果を得るための設計方針を決定し、設計結果が要求仕様および品質を満足しているか評価すること
- 設計の計画
- 設計方針の決定
- 設計上の技法や方法の選択を根本的に左右する基本戦略を、関係者全員が共有できるように定めておくこと
- ソフトウェア構造に一貫性を持たせる一般的な設計方針
- 分割と統治、段階的詳細化など
- 設計技法の選択における考慮点
- ソフトウェア特性（リアルタイム性やuiなど）
- 品質特性
- プロジェクト目標、品質目標との整合
- 設計方針との整合
- 設計技法の完成度、普及度
- 開発環境の整備状況
- 要員の確保と要員教育の教材の充実度
- 技法
- 構造化設計、オブジェクト指向設計、データ構造中心設計、コンポーネントベース設計、サービス指向設計
- 設計の評価
- 設計成果物のレビュー、テストを実施し、設計結果が要求仕様を正しく実現しているか、求められている品質目標を達成しているか評価すること
- 評価方法は、選択した設計技法や設計成果物の記法により決定
- 評価基準の考慮点
- 要求事項への追跡可能性
- 外部一貫性
- 内部一貫性
- 利用した設計方法や作業標準の適切さ
- 実現可能性
- 品質目標の達成度合いは、策定した品質評価計画により評価
- KA: 実装のマネジメント
- 実装の計画
- 実装方針の決定
- 実装方針の決定とは、実装に際して、品質要求を含む各種の要求を満たすために必要な実装ルールを設定すること
- 考慮項目
- 採用する言語と再利用部品の利用
- コーディング規約とガイド
- 各条件から、プロジェクトに最適な規約とガイドを設定
- 標準の利用
- 外部標準(OMG(Object Management Group)やISOのような国際組織が規定)のソフトウェアおよびハードウェアのinterface仕様、実装言語、実装ツール、interfaceなどの利用を検討する
- 併せて内部標準(企業単位、部門単位、プロジェクト単位などの標準)の利用を検討
- 標準により、プロジェクト運営の負荷軽減
- 検証の組込などへの効果も期待できる
- 実装の評価
- 実装成果物のレビュー、テストを実施し、実装結果が要求仕様を正しく実現しているか、求められている品質目標を達成しているか評価すること
- 基準
- システム要求事項とシステム設計への追跡可能性
- システム要求事項との外部一貫性
- 内部一貫性
- テスト可能性
- ソフトウェア設計の実現可能性
- 運用と保守の実現可能性
- ウォークスルーによるコードレビューが代表的
- 要求仕様が正しくコーディングされていることを評価
- 規約の遵守性も評価
- テストでは、ホワイトボックステストによるモジュールテストが代表的で、命令や分岐が正しく動作することを評価する
- 命令や分岐の網羅性が評価基準
- モジュールを統合してテストするときは、仕様に基づくテスト（ブラックボックステストなど）により、統合したモジュールが要求仕様どおり動作することを評価する
- KA: レビューのマネジメント
- レビュー: ソフトウェア開発工程全般における評価と確認作業
- 関係者が参加し多角的に検討することで、論理の客観性と透明性、構造の妥当性、フィールドへの適応性などを評価し確認する
- デザインレビュー: 設計審査。品質保証のための合否判定の1手段
- レビュー計画
- 開催時期、対象成果物、レビューア、観点、適用する方法とリーディング技法、完了判断基準などのレビュー計画を、プロジェクト計画策定時に明確にする
- 対象はソフトウェアに関する直接的な成果物だけでなく、設計方針やテスト戦略などの成果物も含める
- 方法は、最も形式的で公式なインスペクションから、その逆のアドホックレビューまでさまざま
- 形式的なら、側面や観点に基づいた障害検出の属人性が低減されて管理しやすくなるが、手間やリソースがかかるので、目的に応じて選択する
- レビュー実施
- 対象成果物が、当該プロセスのインプットの要求事項を満たすことを確認する
- 前のプロセ腕示された要求を網羅した記述内容であることを確認
- 曖昧性がないこと、内容や構造に矛盾、誤り、漏れがないことも確認
- 人や組織ではなく成果物をレビューすることや、問題を指摘事項として挙げるものの解決はしなくてもよい場合があることなどを、ガイドラインとして作成しておく
- 対象成果物が、当該プロセスのインプットの要求事項を満たすことを確認する
- レビューの記録
- レビュー報告書の発行
- → 品質記録としての意味
- 品質保証活動の一環としてのレビューが確実に実施されたことの証拠となる
- この記録をもとに追跡して完結したことをフォローする
- 記録は、内容と手順をプロジェクト計画策定時に立案し、プロジェクトメンバに徹底しておく
- レビュー実施状況のマネジメント
- プロジェクト実行段階において、レビューが計画通りに行われていることを追跡し、指摘結果の反映確認を確実に行う
- レビュー: ソフトウェア開発工程全般における評価と確認作業
- KA: テストのマネジメント
- 対象のプロダクトやサービスが、プロジェクトで定義した品質を達成するために実施される、テストの活動のマネジメント
- テストの実行で、テスト対象がプロジェクトで定義した品質レベルに達しているかを確認する
- テストの対象に残存する欠陥がテストとデバッグにより除去されることで、テスト対象が持つ品質リスクを下げる
- テストは、設計とは違う視点から設計を洗練させ、開発プロセス全体の品質向上にも貢献
- 適切なテストは、十分な品質レベルにあり、残存リスクも許容レベルにあると判断された製品やサービスを市場にリリースするうえで必要であり、そのテストが適切に行われることについてのマネジメントも必要となる
- テストは欠陥があることは示せるが、欠陥がないことは示せないという限界がある
- テストの十分制覇、網羅性やテストの実施量、欠陥の傾向やそれらの管理グラフなどから総合的に判断する
- 品質レベルについても、上記のようなテストに関するメトリクスや残存するプロダクトリスクなど、テストマネジメントの実施の上で得られるすべてのデータを利用して総合的に判断する必要がある
- テスト活動に関与する組織の在り方も、テストマネジメントの成否を左右する
- 一般的に、開発組織から独立したテスト組織によってテストを実施するとテストの効果は向上するが、開発スピードを損なうことがある
- → 独立の度合いは、技術、管理、財務の観点から検討してテスト組織の位置づけを決める必要がある
- 独立強
- 技術面では、異なる視点でのテストができるため、効果up
- 管理面では、テスト組織に出荷権限を与えることで厳格な品質保証活動が可能になる
- 財務面では、テスト組織でのリソースの融通がしやすくなる
- 独立強
- テスト組織のメンバは、各テストレベルにおけるテストタイプを考慮し、性能や使用性などのテストのスペシャリストを含めて構成が〇
- 一般的にアジャイル開発では、開発担当やテスト担当が1つのチームで一体となって開発することが多く、単独のテスト組織は存在しない場合がある
- テストに関する標準や規格への適合が重要になってきている
- プロジェクトマネジメントの1要素でもあるので、ステークホルダーとの調整が不可欠
- 用語の統一も重要
- → ISTQBが発行しているGlossaryが使える
- S-KA: テストプロセス
- テストアクティビティを具体化するときは、ソフトウェア開発ライフサイクルの諸活動やさまざまなステークホルダーの存在を識別したうえで、ソフトウェア開発のプロセスと連携したテストプロセスの形成が必要
- 目的
- ソフトウェア開発のプロセスと連携した、効果的なテストプロセスを形成する
- 方法
- 効果
- ソフトウェア開発プロセスと対応付けたテストプロセスを策定することで、各テスト工程の設計の元になる情報やテスト対象範囲を明らかにできる
- W字モデルの導入により、上流工程からの品質の作りこみ、開発とテスト準備作業の並行性向上（ひいては短納期開発）、テストエンジニアの知見の活用、テストしやすいソフトウェア開発の促進が期待できる
- 留意点
- 開発プロジェクトが採用するプロセスモデルによってテストレベルの数が決まる（固定的ではない）
- W字モデルにおいて、テストの計画や設計の作業を通じて、上流工程で要求や設計の問題点を検出してフィードバックするには、相応の技術力が必要
- 経験の浅いテスターが上流工程で単にテストケースを作成するだけではW字モデルの効果は得られない
- S-KA: テストの構造
- 目的
- テストの構造を明確にすることで、テストのマネジメントを容易にする
- 方法
- テストレベル
- テストタイプ
- 機能品質特性の評価
- 非機能品質特性の評価
- 信頼性、パフォーマンス、セキュリティ、互換性、ユーザビリティ
- 構造やアーキテクチャの評価
- 構造テスト、ホワイトボックステストなど
- 変更の影響の評価
- 修正確認テスト、リグレッションテストなど
- 効果
- テストの構造を決めることで、対象や範囲を整理して、目的に沿ったテストを設計でき、段階的、体系的にテストを進められる
- 留意点
- テストレベルの種類や数は、プロジェクトが採用するプロセスモデルや開発スケジュールなど、そのプロジェクトの特徴に応じて設定する
- テストタイプは具体的なテストケースを示すものではないので、テストタイプの主旨に沿ってテストの詳細の設計が必要
- 目的
- S-KA: テストの計画と遂行
- 目的
- プロジェクトにおけるテストの目的やプロセス、ゴールとそれに至る手段、リスク、テスト環境を明確にして実現可能な実施計画を作成し、テストを遂行する
- 方法
- 開発プロジェクト発足後、プロジェクト計画策定とほぼ同時期に、開発ライフサイクル全体を包括するものとしてテスト計画を策定する
- 策定時は、プロジェクト計画で策定された目的、戦略と戦術、スケジュールや耐性、環境、リスクとその対策などを勘案し、最終的に全体計画となるマスターテスト計画書、テストレベルに応じた個別のテスト計画書などに記述する
- 検討事項
- テスト全般の内容と工数の見積もり
- 範囲、内容、方法、体制、要員、スケジュールの定義
- 工数見積もりは、過去や類似のプロジェクトの実績値を参考にする方法や、作業の実行者やエキスパートによる見積もりをベースにする方法がある
- テストにかかわるリスク
- 識別し、予防策、回避策、発生時の対策を決定
- 適切なテスト技法やテスト対象、優先順位を決定して実施することでプロダクトのリスクに対処
- リスクベースドテストでリスクの発生を最小限に抑える
- リソースについてのリスク分析、マネジメントも実施
- テスト環境
- テストレベルに応じた機器やソフトウェアの選定と調達
- 限界値/異常値テストが実施可能なテスト環境
- 場所や電源など物理的リソースの確保
- テスト全般の内容と工数の見積もり
- テストの遂行では、計画通りに進捗しているか品質なども含めて計画にフィードバック
- 状況や結果に関する情報
- テストの消化状況
- 障害情報
- 要求、仕様やコードに対する確認の網羅性
- 状況や結果に関する情報
- 効果
- 実施すべき作業とスケジュール、ゴールが明確になることでテストを円滑に実施、管理できる
- テストプロセスの進行状況の把握やテスト終了の判断、品質問題の早期発見ができる
- 留意点
- フィードバック要
- リスクの定期的再評価
- 必要な情報のみ収集、容易な収集方法
- 目的
- S-KA: テストに関する標準
- 目的
- 組織、テスト対象、テスト実施形態にかかわらず適用できる規格を用いてテストに関する作業を標準化する
- 方法
- 効果
- 公的・実質的な規格により作業が一定水準で標準化できる
- 技術者はグローバルな統一基準にもとづいて段階的にテスト技術を習得でき、開発組織は体系的に技術者を育成できる
- 留意点
- 規格の適用にあたっては、開発方法、プロセス、プロジェクトの特性に合わせてテーラリング
- プロジェクトが準拠する規格によりテストへの要求事項は変わる
- ISTQBで実施されている試験でも、JSTQBでは実施されていないものがある
- 目的
- KA: 品質分析と評価のマネジメント
- 実行過程、実行結果や成果物に関するデータを収集、分析し評価すること
- 留意点
- プロダクト品質とプロセス品質の両面から評価
- 障害件数のみでなく品質特性やプロセスの特性にも着目し、さまざまな観点で評価
- データの分析と評価結果の使用方法を明確にする
- 具体的なアクションやフィードバック、改善に結びつくデータ収集や分析、評価となるようにする
- 対象範囲を明確にし、偏りや抜けのないデータとする
- 分析と評価はCh03の技法を使う
- 定量的に行い客観性を保持
- 技法や評価観点を使うときは、自環境を考慮してカスタマイズ
- 技法や観点の背景の理解が必要
- S-KA: プロダクト品質とプロセス品質の分析と評価
- 目的
- プロダクト品質の分析と評価 → ユーザの視点でさまざまな側面から評価する
- プロセス品質の分析と評価 → 開発プロセスの妥当性と一貫性の確認
- 目的
- KA: リリース可否判定
- リリース: プロセスを次の段階またはプロセスに進めることを認めることを意味する
- 目的
- 実施時期に応じた目的
- 方法
- 判定責任者を設けて権限を明確にしておく
- ステークホルダーやその他の関係者を含めた版tネイの体制も明確にする
- KA: 運用および保守のマネジメント
- S-KA: ITIL
- S-KA: SLAとSLM
- 目的
- 方法
- 効果
- 留意点
- S-KA: サービスマネジメントに関する規格
- SMS(Service Management System)
- ITサービスの提供者に対する要求事項の規定
- S-KA: 保守に関する規格
- 保守プロセスの実行計画立案、実行とコントロール、レビューと評価、終了に対するガイド
- 分類
- 是正保守、予防保守、適応保守、完全化保守
(以下は、業務などで課題を見つけたときに通読するようにし、今は構成・概観だけ確認する。)
Ch03 ソフトウェア品質技術
- 品質の作りこみや確認のための技術について
工程に共通なソフトウェア品質技術
- KA: メトリクス
- S-KA: 測定理論
- T: 測定に関する用語
- T: 測定プロセス
- T: GQM(Foal-Question-Metric)
- S-KA: プロダクトメトリクス
- T: 製品品質メトリクス
- T: 利用時の品質メトリクス
- T: 複雑殿メトリクス
- T: LOC(Lines of Code)
- T: ファンクションポイント
- S-KA: プロセスメトリクス
- S-KA: 測定理論
- KA: モデル化の技法
- KA: 形式手法
- 数理論理学に基づいて、仕様記述や検証を行うアプローチの総称
- S-KA: 形式仕様記述の技法
- S-KA: 形式検証の技法
工程に個別なソフトウェア品質技術
- KA: 要求分析の技法
- S-KA: 要求抽出
- T: ステークホルダー識別
- T: 要求開発
- S-KA: 要求分析
- T: 機能要求分析
- T: 非機能要求分析
- T: 品質機能展開
- T: 要求可変性分析
- S-KA: 要求仕様化
- T: ソフトウェア要求仕様
- T: USDM
- S-KA: 要求の妥当性確認と評価
- S-KA: 要求抽出
- KA: 設計の技法
- S-KA: 方式設計の技法
- ソフトウェアアーキテクチャ設計の技法と同義
- T: 部品化の技法
- T: アーキテクチャパターン
- T: 品質に基づくアーキテクチャ設計と評価技法
- T: DSM(依存構造マトリクス, Dependency/Design Structure Matrix)
- T: フレームワーク
- S-KA: 詳細設計の技法
- T: TDD
- T: デザインパターン
- T: 設計原則
- S-KA: 方式設計の技法
- KA: 実装の技法
- T: コーディング規約とガイド
- T: リファクタリング
- T: 契約による設計
- KA: レビューの技法
- S-KA: レビュー方法
- S-KA: 仕様やコードに基づいた技法
- S-KA: フォールトに基づいた技法
- S-KA: リーディング技法
- KA: テストの技法
- S-KA: テスト設計技法
- T: 仕様に基づいた技法
- T: コードに基づいた技法
- T: 経験と直感に基づいた技法
- T: フォールトに基づいた技法
- T: リスクに基づいた技法
- T: 利用に基づいた技法
- T: 組み合わせの技法
- T: コード解析技法
- S-KA: テスト自動化技法
- S-KA: テスト設計技法
- KA: 品質分析と評価の技法
- KA: 運用と保守の技法
- S-KA: 運用の技法
- T: ソフトウェア若化(software rejuvenation)
- 経年劣化の未然防止
- T: ソフトウェア若化(software rejuvenation)
- S-KA: 保守の種類と技法
- T: 保守の種類
- 是正、予防、適応、完全化
- T: 保守の技法
- 理解と解析、拡張と変更
- T: 保守の種類
- S-KA: 運用の技法
Ch04 専門的なソフトウェア品質の概念と技術
- KA: ユーザビリティ
- KA: セーフティ
- S-KA: セーフティの品質の概念
- 本質安全
- ハザードを取り除く性質
- 機能安全
- ハザードにより危害に至らない性質や危害を回避できる性質
- リスク評価
- セーフティを最優先する組織文化
- 本質安全
- S-KA: セーフティの技法
- T: セーフティ実現のためのリスク低減技法
- T: セーフティ・クリティカルシステムのテスト
- S-KA: セーフティ・クリティカル・ライフサイクルモデル
- 安全性解析
- 開発
- 安全妥当性確認
- T: 電気・電子・プログラマブル電子安全間連携の機能安全
- T: 自動車-機能安全
- T: 医療機器ソフトウェア-ソフトウェアライフサイクルプロセス
- S-KA: セーフティの品質の概念
- KA: セキュリティ
- セーフティとの違いは、「攻撃者」を想定しているかどうか
- S-KA: セキュリティの品質の概念
- 機密性、完全性、可用性
- 真正性、責任追跡性、否認防止、信頼性、インテグリティ
- T: 情報セキュリティの定義
- 近年は、サイバーセキュリティの用語が多用されるようになっている
- S-KA: セキュリティの技法
- T: セキュリティ要求分析
- T: セキュリティ設計
- T: セキュリティパターン
- T: セキュアコーディング
- T: セキュリティテスト
- T: 脆弱性管理
- KA: プライバシー
- S-KA: プライバシーの品質の概念
- S-KA: プライバシーの技法
- T: プライバシー影響評価(PIA: Privacy Impact Assessment)
- T: プライバシー保護技術(Privacy Enhancing Technologies)
Ch05 ソフトウェア品質の応用領域
- KA: AIにおける品質
- KA: IoTシステムにおける品質
- KA: アジャイル開発とDevOpsにおける品質
- S-KA: アジャイル開発とDevOpsに置ける品質の概念
- T: アジャイル開発の品質
- 設計と同時にテスト
- 自動化
- 変更容易性
- 開発チームの自律性を尊重
- T: DevOpsの品質
- 表5.3.1: DevOpsにおける品質特性と意味
- T: アジャイル開発の品質
- S-KA: アジャイル開発とDevOpsの品質マネジメント
- S-KA: アジャイル開発とDevOpsの品質技術
- S-KA: アジャイル開発とDevOpsに置ける品質の概念
- KA: クラウドサービスにおける品質
- クラウドサービスプロバイダ、クラウドサービスカスタマー
- クラウドサービスカスタマーは、サービスプロバイダとエンドユーザを含む
- S-KA: クラウドサービスにおける品質の概念
- S-KA: クラウドサービスの品質マネジメント
- T: クラウドサービスのリスクマネジメント
- S-KA: クラウドサービスの品質技術
- クラウドネイティブ: クラウド上での利用を前提として設計されたシステムやサービス
- マイクロサービスを利用したシステムは複雑になりがち
- → 本番環境で実験するカオスエンジニアリングで、従来の手法で発見困難な障害を検出する
- T: 仮想化
- 計算機、ストレージ、ネットワーク
- 仮想化の利点を考慮した設計のソフトウェアでないと効果は限定的
- T: マイクロサービス
- 協調して動作する小規模で自律的なサービス
- 目的
- スケーラビリティを確保した迅速な機能追加や修正の能力などを持ったサービスを提供
- 方法
- 留意点
- 小さく複雑でなく改修頻度が低いシステムは、マイクロサービスに分割するデメリットの方が大きい
- Kubernetesなどの使用
- T: クラウドデザインパターン
- クラウドサービスプロバイダ、クラウドサービスカスタマー
- KA: OSS利活用における品質
