JAXAの事例にみる実施価値に基づくソ フトウェア保証手法:VBSA 宇宙航空研究開発機構 研究開発部門 第三研究ユニット 山田興人 14th WOCS2 12/12/2016 Copyright © 2016 JAXA All Rights Reserved. 1 本チュートリアルの概要 • 価値に基づくソフトウェア保証（Value Based Software Assurance）という概念の概要、及び価値を見える化し関係者 と価値を共有可能とするモデルコンセプト（Value Chain Model, Decision Model）の概要を、 JAXAの事例と共に解説 する。 • JAXAが検討し、試行したValue Chain Modelの構成要素、作 成手順、及び知見を紹介する。 • Value Chain Modelの期待効果をまとめる。 14th WOCS2 12/12/2016 Copyright © 2016 JAXA All Rights Reserved. 2 ソフトウェア開発における保証活動 • • • 近年、ソフトウェア開発において、各国/業界/組織単位で標準的なソフト ウェア開発プロセスがスタンダードとして定義され、ソフトウェア開発プロ ジェクトに適用されてきた。 JAXAにおいてもソフトウェア開発プロセスに係るスタンダードを定義し、プ ロジェクトに適用している。 各プロジェクトでは、スタンダードに従って、プロセス/プロダクトに対する ソフトウェア保証の活動（Software Assurance activity：SA activity）が実施 される。 – スタンダードで要求されるSA activityの例 • • • • • • • • 14th WOCS2 12/12/2016 ソフトウェアの要求、設計、試験仕様に関する確認 ソフトウェアの開発・検証の計画、保証計画に関する確認 プロジェクトで発生した課題が管理・解決されているかの確認 システムの特性や製品の変更によって発生するリスクに関する確認 文書の構成管理が、確実にできていることの確認 安全に関する確認 プロジェクト管理活動に関する確認 ソフトウェアプロダクトを、顧客でも、受注者でもない、第三者による検証 Copyright © 2016 JAXA All Rights Reserved. 3 JAXAにおけるスタンダード ソフトウェア開発標準 JERG-2-610A JERG-0-049A(注) ソフトウェア開発標準 領域個別標準の内容を抽象化し ソフトウェア開発全般のプロセス を記述 (注)制定済のJERG-2-600A ソフトウェア開発標準(宇宙機用) を共通版化したもの • 仕事の仕方（プロセス）を 宇宙機ソフトウェア開発標準 宇宙機特有事項を含めたソフトウェア開発プロセスを記述 ソフトウエア開発標準として 定義 JERG-1-008A •ロケット搭載ソフトウェア開発標準 開発の初期段階から運用設 ロケット特有事項を含めたソフトウェア開発プロセスを記述 計に関わる活動を標準として JERG-3-003A 定義 ISOとの 整合性を 確保 ECSSとの との 整合性を 確保 地上ソフトウェア開発標準 JIS X 0160-1996 (ISO/IEC12207:1995) ECSS-E-40 Space engineering: Software ECSS-Q-80 Space product assurance 地上設備特有事項を含めたソフトウェア開発プロセスを記述 • アセスメントによって、実ソフトウエ ア開発におけるプロセス実施状況の評 価と改善点識別 開発活動を 評価する JAXAソフトウェアアセスメントモデル CSA-114006A JAXAソフトウェアアセスメントモデル (JAXA-PAM) アセスメントでの評価指標を記述 14th WOCS2 12/12/2016 Copyright © 2016 JAXA All Rights Reserved. ISOへの適合 結果の変換性を確保 ECSSの 知見を反映 ISO/IEC15504 ECSS-Q-80-02 Part 1A Software process assessment and improvement Part 1: Framework 4 SA activityに係る課題 その活動はたぶん スケジュールリスク を減らす狙いでは？ 「ソフトウェア？」 その活動はどんな 種類の利益を与えるのか？ ソフトウェア保証の予算を 最適化できないのか？ SA activity に関して 誤解がある とにかく要求された 活動に従うだけです。 SA activityは単なる ルーチンワーク ＝形骸化 プロジェクト担当 SA activityが マンジメント で利用されて無い ? SA activityが効果的に 開発へ導入されて無い 活動の成果 はプロジェクトに とってどんな判断に 繋がるのか？ プロジェクトマネージャー その活動を評価するため、 活動の結果をどのように 理解し使えばよいのか どのようにソフトウェア保証 計画が妥当と判断できるか ソフトウェア保証担当 14th WOCS2 12/12/2016 Copyright © 2016 JAXA All Rights Reserved. 5 課題に対する解決策 VBSA（Value Based Software Assurance)による、SA activityの価値理 解を通したSA activityの促進 そのSA activityは品質リスクを 低減するため、エンジニアに とって効果的ですね！ そのSA activityは〇〇な価値を 与えるのか！ その価値から考えると、今回の プロジェクトではそのSA activity を実施すべきだな！ SA activityの価値を踏ま えると××の方法を とる必要がありますね！ そのSA activityが完了した ので△△という意思決定 が行えるな！ プロジェクト担当 プロジェクトマネージャー SA activityとその価値に関する SA activity に関する 共通理解をベースとして 計画され実行される 14th WOCS2 12/12/2016 ソフトウェア 保証担当 SA activityが適切に実行される。 SA activity 結果は、開発に対して利用される。 Copyright © 2016 JAXA All Rights Reserved. 6 VBSA • VBSAの概要 （ハワイ大 Prof. Daniel Port 考案） NASA Jet Propulsion Laboratory(JPL)で開発された概念 ステークホルダー間でSA activityの価値を共有し理解する その価値を理解・共通する手法として、Value Chain Model、Decision Modelのコンセプトが提案されている。 Value Chain Modelは、Prof.DanielPort（ハワイ大/JPL)、 European Space Agency(ESA)、及びJAXAによって共同で改善された。 Value‐Chain‐Model Outcome Process SA activity Outcome Risk Factor Risk Factor Risk Factor Process Benefit Benefit Benefit Decision‐Model Decision Making SA activity Decision Making 14th WOCS2 12/12/2016 Copyright © 2016 JAXA All Rights Reserved. 7 モデル概要 • Value Chain Model: SA activityの価値 (なぜその活動が必要なのか？）を定義 Increased confidence in process Delivery Assurance Process Evaluate the SW Delivery Package Higher institutional requirements compliance requirements violation ・・・・・ SA activity Outcome Satisfied Assurance office 42: [Increased] confidence in mission success Compliance to delivery requirements 39: [Meeting] SW quality goals Factor Risk 32: [Increased] confidence from NASA Benefit • Decision Model: プロジェクトの意思決定とSA activityの関係性 (その活動の結果はプロジェクトのどのような意思決定の判断に繋がるのか？）を明示 Delivery Assurance Process Decision: Commit for operation? Risk factors: unexpected rework Evaluate the SW Delivery Package ・・・・・ SA activity 14th WOCS2 12/12/2016 Decision: Send delivery for integration or more test and fix? Risk factors: slip schedule, unexpected rework, unbudgeted work Decision Making in project Decision Makingの例 ・Are the defined software processes followed? ・Sufficient requirement V&V? ・Is the architecture sufficient? ・Is the software tested enough? ・Can we proceed to the next phase? Copyright © 2016 JAXA All Rights Reserved. 8 モデル概要 • ２つのモデルで表現される価値（SA activityの見える化） – 意思決定の判断に関連するのはどの活動で、なぜ必要なの か？ Decision Making in project SA activity Outcome Risk Increased confidence in process Decision: Commit for operation? Risk factors: unexpected rework Decision: Send delivery for integration or more test and fix? Risk factors: slip schedule, unexpected rework, unbudgeted work Decision Model 14th WOCS2 12/12/2016 Factor Evaluate the SW Delivery Package institutional requirements compliance requirements violation Satisfied Assurance office Benefit 32: [Increased] confidence from NASA 42: [Increased] confidence in mission success Compliance to delivery requirements 39: [Meeting] SW quality goals Value Chain Model Copyright © 2016 JAXA All Rights Reserved. 9 Value Chain Model構成要素 No 構成要素名 意味 ① SA activity 定義されたソフトウェア保証の活動 1つのProcessに、複数のSA activityが含まれる。 ② Outcome ステークホルダがソフトウェア保証活動から得られる、SA activityが達成されたと判断できる成果。 ③ Risk SA activityとそのOutcomeによって、ステークホルダーが 低減されるリスク。リスクとは、プロジェクトに潜在的な負 の影響を与える望ましくない状況や環境。 ④ Factor Riskの低減によってなぜBenefitが得られるのか、その理 由となる要因を示し、RiskとBenefitの橋渡しをする。 ⑤ Benefit Riskが低減されることで、ステークホルダが得られる一般 的な利益（ポジティブな結果、又は評価）。 Increased confidence in process Delivery Assurance Process Evaluate the SW Delivery Package Higher institutional requirements compliance requirements violation ・・・・・ ①SA activity 14th WOCS2 12/12/2016 ②Outcome ③Risk Copyright © 2016 JAXA All Rights Reserved. 32: [Increased] confidence from NASA Satisfied Assurance office 42: [Increased] confidence in mission success Compliance to delivery requirements 39: [Meeting] SW quality goals ④Factor ⑤Benefit 10 Value Chain Modelの示すValue Chain ENG 8. ｿﾌﾄｳｪｱ試験 SA Activity ソフトウェア 試験の計画・ 仕様を作成 Outcome ソフトウェア要 求との準拠を 示すソフト ウェアの基準 がつくられる Risk Factor より要求を 満足する Benefit 品質目標 の達成 ソフトウェア 要求を満足し ない Value Chain もし私たちが <ソフトウェア試験の計画・仕様を作成> すれば、 <ソフトウェア要求との準拠を示すソフトウェアの基準がつくられる> という成果をサポートする。 その成果は <ソフトウェア要求を満足しない>というリスクを低減する。 このリスク低減は<より要求を満足する>ことに寄与し、 <品質目標の達成>へ繋がる。 14th WOCS2 12/12/2016 Copyright © 2016 JAXA All Rights Reserved. 11 Value Chain Model作成手順 14th WOCS2 12/12/2016 1 モデルの利用シーン、目的・効果を定義する ２ SA activityを定義し、記述する ３ Outcomeを定義し、記述する ４ Riskを考察し、記述する ５ Benefitを考察し、記述する ６ Risk – Benefit間の繋がり（Factor）の根拠を記述する ７ レビューによってモデルを確認・修正する Copyright © 2016 JAXA All Rights Reserved. 12 Value Chain Model作成手順 14th WOCS2 12/12/2016 1 モデルの利用シーン、目的・効果を定義する ２ SA activityを定義し、記述する ３ Outcomeを定義し、記述する ４ Riskを考察し、記述する ５ Benefitを考察し、記述する ６ Risk – Benefit間の繋がり（Factor）の根拠を記述する ７ レビューによってモデルを確認・修正する Copyright © 2016 JAXA All Rights Reserved. 13 ①モデルの利用シーン、目的・効果を定義する ステークホルダ ソフトウェア保証 担当者 シナリオ SA activityに紐付く価値 全般を確認し、どのよう な狙いを想定してスタン ダードとして定義された のかを理解し、開発プロ ジェクトの計画及び実行 状況が妥当であるかを 判断し、納得感のある 助言・提言を行う ソフトウェア 担当者 プロジェクトマ ネージャ SA activityの価値 SA activityに紐付く SA activityがどのよ （特にBenefit）を確 価値（特にRisk）を確 うな価値（特にRisk、 認し、自分の作業方 Benefit）を与えるか、 認し、価値に基づい 法がRiskに対して妥 て自分のプロジェク 経営側に説明し、ソ トでどのSA activity 当であるか否か判 フトウェア保証予算 を採用するか否か 断し、必要に応じて の調整を行う 判断する 訂正する 効果・目的 納得感のある指摘・提言の実 行 • SA activityに基づく作業 の自己最適化 ソフトウェア保証予算の獲得 ソフトウェア保証コストの最 適化 モデルを誰が（ステークホルダ）、どの様に使用し（シナリオ） 、その結果どのような効 果・目的を達成したいか、定義する。 14th WOCS2 12/12/2016 Copyright © 2016 JAXA All Rights Reserved. 14 ①モデルの利用シーン、目的・効果を定義する • モデルの利用シーン、目的を定義する理由 • • モデルは表現手法に過ぎない。 モデルが対象とする利用シーン、目的・効果に応じて、モデルの構成 要素における表現と粒度は変化する。 – 利用シーン、効果・目的が定義されていない場合の事例 » モデルのレビュー時、レビューアー毎に異なる意見が提示され、ど の表現と粒度が妥当か判断できない。各意見は各レビューアーの 立場、利用想定から見ると正しい。 Comment Comment 14th WOCS2 12/12/2016 Comment Copyright © 2016 JAXA All Rights Reserved. 15 Value Chain Model作成手順 14th WOCS2 12/12/2016 1 モデルの利用シーン、目的・効果を定義する ２ SA activityを定義し、記述する ３ Outcomeを定義し、記述する ４ Riskを考察し、記述する ５ Benefitを考察し、記述する ６ Risk – Benefit間の繋がり（Factor）の根拠を記述する ７ レビューによってモデルを確認・修正する Copyright © 2016 JAXA All Rights Reserved. 16 ②SA activityを定義し、記述する スタンダード ソフトウェア要求分析 SA Activity (a)ソフトウェア要求 仕様の各要求項⽬につ いて、要求根拠を明ら かにするとともに、実 現可能性を評価するこ と。 (b)ソフトウェア要求 仕様の前提となってい る運⽤前提および制約 事項を抽出すること。 SA activity モデルの目的・効果に「ソフトウェア保証 予算の獲得」を想定する場合、 SA activity単位で詳細な価値分析を行うよ り、Process単位で価値を分析した方が、 情報量として妥当な場合もある。 ・モデルの利用シーン、目的・効果から、価値を分析すべきスタン ダード等で定義されたSA activityを選択し、記述する。 14th WOCS2 12/12/2016 Copyright © 2016 JAXA All Rights Reserved. 17 Value Chain Model作成手順 14th WOCS2 12/12/2016 1 モデルの利用シーン、目的・効果を定義する ２ SA activityを定義し、記述する ３ Outcomeを定義し、記述する ４ Riskを考察し、記述する ５ Benefitを考察し、記述する ６ Risk – Benefit間の繋がり（Factor）の根拠を記述する ７ レビューによってモデルを確認・修正する Copyright © 2016 JAXA All Rights Reserved. 18 ③Outcomeを定義し、記述する スタンダード ソフトウェア要求分析 Outcome SA Activity (a)ソフトウェア要求 仕様の各要求項⽬につ いて、要求根拠を明ら かにするとともに、実 現可能性を評価するこ と。 (b)ソフトウェア要求 仕様の前提となってい る運⽤前提および制約 事項を抽出すること。 ソフトウェア要求 仕様について、実 現可能性が確保 されている ソフトウェア要求 仕様の要求根拠 が明示されてい る 運用前提及び制 約事項が、明確 になっている ・スタンダード等の文書でOutcomeが定義されている場合は引用 する。 14th WOCS2 12/12/2016 Copyright © 2016 JAXA All Rights Reserved. 19 ③Outcomeを定義し、記述する • Outcomeの表現粒度 – Outcomeの表現粒度は、「SA activityが達成されたと判断でき る成果」が必要であり定量的な表現が望ましい。 • 定性的で曖昧な表現の場合、読み手毎に解釈の幅が生じるため、 「SA activityが達成された」と一意に判断できない。 • Outcomeの表現に解釈の幅を含むと、その影響がRisk,Factor,Benefit に波及し、Value Chain Model全体が曖昧な表現となる。 – ただ、定量的表現を定義するには今後多くの議論が必要。 • 「計測可能な表現か？」「単位を付けることが可能か？」の観点によ る検討等、解釈の幅を狭める工夫が挙げられている。 定量的な例 管理されたアクションアイテムの問題が 対処されている。[未処置AI数：0件] 14th WOCS2 12/12/2016 Copyright © 2016 JAXA All Rights Reserved. 件数 指摘数 バグ率 20 Value Chain Model作成手順 14th WOCS2 12/12/2016 1 モデルの利用シーン、目的・効果を定義する ２ SA activityを定義し、記述する ３ Outcomeを定義し、記述する ４ Riskを考察し、記述する ５ Benefitを考察し、記述する ６ Risk – Benefit間の繋がり（Factor）の根拠を記述する ７ レビューによってモデルを確認・修正する Copyright © 2016 JAXA All Rights Reserved. 21 ④Riskを考察し、記述する スタンダード ソフトウェア要求分析 SA Activity (a)ソフトウェア要求 仕様の各要求項⽬につ いて、要求根拠を明ら かにするとともに、実 現可能性を評価するこ と。 (b)ソフトウェア要求 仕様の前提となってい る運⽤前提および制約 事項を抽出すること。 Risk Outcome ソフトウェア要求 仕様について、実 現可能性が確保 されている ソフトウェアが要求（例：応答速度、 スループット、消費リソース、操作性 が悪い、他）を実現できないため、試 験⼯程で不具合として顕在化する。 ソフトウェア要求 仕様の要求根拠 が明示されてい る 既設計資産/現設計が正しく再利⽤側/ 修正側に伝わらず、再利⽤時/修正時 の仕様誤解が起因となる後戻り等が発 ⽣する。 運用前提及び制 約事項が、明確 になっている ソフトウェアの使⽤⽅法が共有されず、 制約に反した運⽤が⾏われる。 モデルの目的・効 果に「ソフトウェア 保証コストの最適 化」を想定する場 合、詳細な粒度表 現ですべのRiskを 表現すると、情報 量として過剰な場 合もある。 ・識別したOutcomeの内容から、モデルの利用シーン、目的・効果 をベースに、どんなRiskが低減できるのかを考察し、ブロック内に 内容を記述する 14th WOCS2 12/12/2016 Copyright © 2016 JAXA All Rights Reserved. 22 Value Chain Model作成手順 14th WOCS2 12/12/2016 1 モデルの利用シーン、目的・効果を定義する ２ SA activityを定義し、記述する ３ Outcomeを定義し、SA activityとの対応付けを行う ４ Riskを考察し、記述する ５ Benefitを考察し、記述する ６ Risk – Benefit間の繋がり（Factor）の根拠を記述する ７ レビューによってモデルを確認・修正する Copyright © 2016 JAXA All Rights Reserved. 23 ⑤Benefitを考察し、記述する スタンダード ソフトウェア要求分析 SA Activity (a)ソフトウェア要求 仕様の各要求項⽬につ いて、要求根拠を明ら かにするとともに、実 現可能性を評価するこ と。 (b)ソフトウェア要求 仕様の前提となってい る運⽤前提および制約 事項を抽出すること。 Benefit Outcome ソフトウェア要求 仕様について、実 現可能性が確保 されている Risk ソフトウェアが要求（例：応答速度、 スループット、消費リソース、操作性 が悪い、他）を実現できないため、試 験⼯程で不具合として顕在化する。 ソフトウェア要求 仕様の要求根拠 が明示されてい る モデルの目的・効果として、 「ソフトウェア保証コストの最 既設計資産/現設計が正しく再利⽤側/ 修正側に伝わらず、再利⽤時/修正時 適化」を想定する場合、更な の仕様誤解が起因となる後戻り等が発 る詳細化が必要。 ⽣する。 運用前提及び制 約事項が、明確 になっている ソフトウェアの使⽤⽅法が共有されず、 制約に反した運⽤が⾏われる。 機能・性 能目標の 達成 より戦略 的な資源 活⽤ 運⽤事故 の低減 ・モデルの利用シーン、目的・効果をベースに、定義したRisk低減 の内容が、ステークホルダに対してどのような利益（ポジティブな 結果、又は評価）をもたらすのか考察し、ブロック内に記述する。 14th WOCS2 12/12/2016 Copyright © 2016 JAXA All Rights Reserved. 24 Value Chain Model作成手順 14th WOCS2 12/12/2016 1 モデルの利用シーン、目的・効果を定義する ２ SA activityを定義し、記述する ３ Outcomeを定義し、SA activityとの対応付けを行う ４ Riskを考察し、記述する ５ Benefitを考察し、記述する ６ Risk – Benefit間の繋がり（Factor）の根拠を記述する ７ レビューによってモデルを確認・修正する Copyright © 2016 JAXA All Rights Reserved. 25 ⑥Risk – Benefit間の繋がりの理由を記述する スタンダード ソフトウェア要求分析 SA Activity (a)ソフトウェア要求 仕様の各要求項⽬につ いて、要求根拠を明ら かにするとともに、実 現可能性を評価するこ と。 (b)ソフトウェア要求 仕様の前提となってい る運⽤前提および制約 事項を抽出すること。 Outcome Risk Factor ソフトウェア要求 仕様について、実 現可能性が確保 されている ソフトウェアが要求（例：応答速度、 スループット、消費リソース、操作性 が悪い、他）を実現できないため、試 験⼯程で不具合として顕在化する。 ソフトウェア要求 仕様の要求根拠 が明示されてい る 既設計資産/現設計が正しく再利⽤側/ 修正側に伝わらず、再利⽤時/修正時 の仕様誤解が起因となる後戻り等が発 ⽣する。 運用前提及び制 約事項が、明確 になっている 関係者間で運⽤制約が 共有されることで、制 ソフトウェアの使⽤⽅法が共有されず、 約に基づいた正しい運 制約に反した運⽤が⾏われる。 ⽤が⾏われる 実現性が起因となる試 験⼯程での不具合が抑 制される 既設計資産の活⽤ が促進する Benefit 機能・性 能目標の 達成 より戦略 的な資源 活⽤ 運⽤事故 の低減 ・Risk低減の結果、なぜ識別したBenefitが得られるのか、 その理由（要因）をRiskとBenefitを繋いだ線上に記述する。 14th WOCS2 12/12/2016 Copyright © 2016 JAXA All Rights Reserved. 26 Value Chain Model作成手順 14th WOCS2 12/12/2016 1 モデルの利用シーン、目的・効果を定義する ２ SA activityを定義し、記述する ３ Outcomeを定義し、SA activityとの対応付けを行う ４ Riskを考察し、記述する ５ Benefitを考察し、記述する ６ Risk – Benefit間の繋がり（Factor）の根拠を記述する ７ レビューによってモデルを確認・修正する Copyright © 2016 JAXA All Rights Reserved. 27 ⑦レビューによってモデルを確認・修正する スタンダード ソフトウェア要求分析 SA Activity (a)ソフトウェア要求 仕様の各要求項⽬につ いて、要求根拠を明ら かにするとともに、実 現可能性を評価するこ と。 (b)ソフトウェア要求 仕様の前提となってい る運⽤前提および制約 事項を抽出すること。 Outcome Risk Factor ソフトウェア要求 仕様について、 実現可能性が確 保されている ソフトウェアが要求（例：応答速度、 スループット、消費リソース、操作性 が悪い、他）を実現できないため、試 験⼯程で不具合として顕在化する。 ソフトウェア要求 仕様の要求根拠 が明示されてい る 既設計資産/現設計が正しく再利⽤側/ 修正側に伝わらず、再利⽤時/修正時 の仕様誤解が起因となる後戻り等が発 ⽣する。 運用前提及び制 約事項が、明確 になっている 関係者間で運⽤制約が 共有されることで、制 ソフトウェアの使⽤⽅法が共有されず、 約に基づいた正しい運 制約に反した運⽤が⾏われる。 ⽤が⾏われる 実現性が起因となる試 験⼯程での不具合が抑 制される 既設計資産の活⽤ が促進する Benefit 機能・性 能目標の 達成 より戦略 的な資源 活⽤ 運⽤事故 の低減 ・モデルの利用シーン、目的・効果をベースに、以下のレビューを 行い、必要に応じてモデルを修正する。 ・Value Chainとして成り立っているか？ ・各要素に抜け、漏れ、誤りは無いか？ ・各要素の表現と粒度は妥当か？ 14th WOCS2 12/12/2016 Copyright © 2016 JAXA All Rights Reserved. 28 Value Chain Model作成手順 14th WOCS2 12/12/2016 1 モデルの利用シーン、目的・効果を定義する ２ SA activityを定義し、記述する ３ Outcomeを定義し、記述する ４ Riskを考察し、記述する ５ Benefitを考察し、記述する ６ Risk – Benefit間の繋がり（Factor）の根拠を記述する ７ レビューによってモデルを確認・修正する Copyright © 2016 JAXA All Rights Reserved. 29 Value Chain Modelの期待効果 価値に基づく指摘・提言 SA activityを計画する • SA activityの実施に関して、開発組織 側へSA activityの価値に基づく指摘・ 提言を行う • 価値に基づくテーラリングの基準を提 供する • SA activityの価値を経営層に示し、ソ フトウェア保証予算の調整を行う ソフトウェア保証 担当者 開発組織 スタンダードの見直し • スタンダードに記載されたSA activity の価値を分析することで、スタンダー ド自体の記述における妥当性も検証 可能 ソフトウェア開発 スタンダード 14th WOCS2 12/12/2016 価値 開発計画 ソフトウェア開発 スタンダード 価値 保証計画 教育 • SA activityをガイドする • 理解を強化し、自分の活動を見直す 気付きを与える ソフトウェア開発 スタンダード SA activityの背景 Copyright © 2016 JAXA All Rights Reserved. SA activity 初心者 30 JAXAの試行から得た効果 価値に基づく指摘・提言 • 事例：開発メーカがJAXAに提出したソフトウェア開発計画書を確認し、 JAXAのスタンダードを準拠していることをレビュー、必要に応じて指摘す る業務 従来の指摘内容： – 「スタンダードに記載れたXXXの活動計画が無い」 – 単に有る、無いの指摘。 – 指摘を受ける側に気付きも無く、納得感も無い。何故必要なのかも理解しな いまま字面通りの活動となり易い。 VBSA試行後の指摘内容： – 「スタンダードに記載れたXXXの活動は～という価値を意図としたものである。 対してこの計画書には、～という意図を踏まえると〇〇〇という活動計画では 不十分」 – 何故必要なのかを理解し、本質的な活動に繋がりやすい。 – 関係者からも、「従来の指摘より分かりやすく納得感 がある」とコメントを頂いている。 JAXA 開発メーカ 14th WOCS2 12/12/2016 Copyright © 2016 JAXA All Rights Reserved. 31 JAXAの試行から得た効果 スタンダードの見直し • 事例：JAXAのソフトウェア開発標準（JERG‐0‐049）に 記載された各項目に対して価値分析を実施する作 業 – 各項目の価値を整理・分析することで、スタンダードの記 載内容自体が、意図したい価値に対して不適切である等、 問題点、改善点を識別できた。 – 識別した問題点、改善点は、今後JERG‐0‐049又はJERG‐0‐ 049補足説明書に反映予定。 VBSA JERG‐0‐049補 足説明書 14th WOCS2 12/12/2016 Copyright © 2016 JAXA All Rights Reserved. JERG‐0‐ 049 32 課題 • プロセスを跨いだ各SA activityの関係性の表現 – 現在のValue Chain Modelは、１Process内の各SA activity に対して、価値を定義している。 – しかし、プロセスを跨いだ各SA activity間の価値に基づく 関係性をモデルで表現できない。 14th WOCS2 12/12/2016 図：運用時に問題が発生した場合の各プロセスの 関係性（ JERG‐0‐049） Copyright © 2016 JAXA All Rights Reserved. 33 まとめ • VBSAとは価値に基づくソフトウェア保証を実現する概念である。 • ステークホルダー間でSA activityの価値を共有し理解することを目 的としている。 • 価値を理解・共通する手法として、Value Chain Model、Decision Modelのコンセプトがある。 • Value Chain Modelの作成前に、モデルの利用シナリオ、目的・効 果を定義すると良い。また、上記定義を基に、レビューを行うことで、 モデルはより妥当な表現となる。 • Value Chain Modelの期待される効果として価値に基づく指摘・提 言、SA activity計画の立案、スタンダードの見直し、教育がある。 14th WOCS2 12/12/2016 Copyright © 2016 JAXA All Rights Reserved. 34 ご清聴ありがとうございました! question & comments [email protected] 14th WOCS2 12/12/2016 Copyright © 2016 JAXA All Rights Reserved. 35
© Copyright 2024 ExpyDoc
