15288解説_D.pptx

Similar documents
ISO 9001:2015 改定セミナー (JIS Q 9001:2015 準拠 ) 第 4.2 版 株式会社 TBC ソリューションズ プログラム 年版改定の概要 年版の6 大重点ポイントと対策 年版と2008 年版の相違 年版への移行の実務

ISO 9001:2015 から ISO 9001:2008 の相関表 JIS Q 9001:2015 JIS Q 9001: 適用範囲 1 適用範囲 1.1 一般 4 組織の状況 4 品質マネジメントシステム 4.1 組織及びその状況の理解 4 品質マネジメントシステム 5.6 マネジ

どのような便益があり得るか? より重要な ( ハイリスクの ) プロセス及びそれらのアウトプットに焦点が当たる 相互に依存するプロセスについての理解 定義及び統合が改善される プロセス及びマネジメントシステム全体の計画策定 実施 確認及び改善の体系的なマネジメント 資源の有効利用及び説明責任の強化

実地審査チェックリスト (改 0) QA-057_____

<90528DB88EBF96E2955B2E786C73>

JIS Q 27001:2014への移行に関する説明会 資料1

PowerPoint プレゼンテーション

スキル領域 職種 : ソフトウェアデベロップメント スキル領域と SWD 経済産業省, 独立行政法人情報処理推進機構

AAプロセスアフローチについて_ テクノファーnews

品質マニュアル(サンプル)|株式会社ハピネックス

プロジェクトマネジメント知識体系ガイド (PMBOK ガイド ) 第 6 版 訂正表 - 第 3 刷り 注 : 次の正誤表は PMBOK ガイド第 6 版 の第 1 刷りと第 2 刷りに関するものです 本 ( または PDF) の印刷部数を確認するには 著作権ページ ( 通知ページおよび目次の前 )

<4F F824F B4B8A B818E968D802E786C73>

ISO9001:2015内部監査チェックリスト

Oracle Un お問合せ : Oracle Data Integrator 11g: データ統合設定と管理 期間 ( 標準日数 ):5 コースの概要 Oracle Data Integratorは すべてのデータ統合要件 ( 大量の高パフォーマンス バッチ ローブンの統合プロセスおよ

ISO9001:2015規格要求事項解説テキスト(サンプル) 株式会社ハピネックス提供資料

untitle

16年度第一回JACB品質技術委員会

説明項目 1. 審査で注目すべき要求事項の変化点 2. 変化点に対応した審査はどうあるべきか 文書化した情報 外部 内部の課題の特定 リスク 機会 関連する利害関係者の特定 プロセスの計画 実施 3. ISO 14001:2015への移行 EMS 適用範囲 リーダーシップ パフォーマンス その他 (

Microsoft Word - 04_品質システム・品質保証モデル_TCVNISO doc

個人依存開発から組織的開発への移行事例 ~ 要求モデル定義と開発プロセスの形式化 による高生産性 / 高信頼性化 ~ 三菱電機メカトロニクスソフトウエア ( 株 ) 和歌山支所岩橋正実 1

9100 Key Changes Presentation

<4D F736F F D2095B68F E838A F939D8D8794C55F>

説明項目 1. 審査で注目すべき要求事項の変化点 2. 変化点に対応した審査はどうあるべきか 文書化した情報 外部 内部の課題の特定 リスク 機会 利害関係者の特定 QMS 適用範囲 3. ISO 9001:2015への移行 リーダーシップ パフォーマンス 組織の知識 その他 ( 考慮する 必要に応

PowerPoint プレゼンテーション

京橋スマートコミュニティ協議会 制定 改訂履歴 改廃年月日版改訂理由作成者承認者 制定 XXXX XXXX 一次審査 XXXX XXXX 2/21

[ 指針 ] 1. 組織体および組織体集団におけるガバナンス プロセスの改善に向けた評価組織体の機関設計については 株式会社にあっては株主総会の専決事項であり 業務運営組織の決定は 取締役会等の専決事項である また 組織体集団をどのように形成するかも親会社の取締役会等の専決事項である したがって こ

スライド 1

Microsoft Word - ModelAnalys操作マニュアル_

2015 TRON Symposium セッション 組込み機器のための機能安全対応 TRON Safe Kernel TRON Safe Kernel の紹介 2015/12/10 株式会社日立超 LSIシステムズ製品ソリューション設計部トロンフォーラム TRON Safe Kernel WG 幹事

f2-system-requirement-system-composer-mw

Microsoft Word - con 監査チェックリスト QMR

<4D F736F F D F95698EBF837D836C EBF95DB8FD882C98AD682B782E98AEE8F805F E49534F D312D E646F63>

5. 文書類に関する要求事項はどのように変わりましたか? 文書化された手順に関する特定の記述はなくなりました プロセスの運用を支援するための文書化した情報を維持し これらのプロセスが計画通りに実行されたと確信するために必要な文書化した情報を保持することは 組織の責任です 必要な文書類の程度は 事業の

Microsoft Word - IRCA250g APG EffectivenessJP.doc

Microsoft PowerPoint - se06-UML(UseCase)_2.ppt [互換モード]

< E9197BF C C A88D5C BA492CA29817A C982A882AF82E98FEE95F1835A834C A CE8DF4834B BD82BD82AB91E4816A5F34325F E977095D E786C7

Microsoft Word - 規則11.2版_FSSC22000Ver.4特例.doc

何故 2 つの規格としたのですか (IATF 16949:2016 及び ISO 9001:2015)? 2 つの規格となると 1 つの規格の場合より, 読んで理解するのが非常に難しくなります 1 まえがき 自動車産業 QMS 規格 IATF と ISO との間で,IATF を統合文書と

< C582C C58B4B8A6982C682CC95CF8D58935F88EA C30382D31312D33302E786C73>

4.4 マネジメントシステム プロセス 5 リーダーシップ 5.1 リーダーシップ コミットメント 組織の状況を考慮し リスク ( 不確かさに影響 ) 及び機会 ( 何かをするのによい時期 ) として取り組むことを決定した情報から適用範囲に含まれていない範囲が存在していませんか恣意的に限定した適用範

本シラバスに記載されている会社名又は製品名は, それぞれ各社又は各組織の商標又は登録商標です なお, 本シラバスでは, 及び TM を明記していません Copyright(c) 2016 IPA All rights reserved

1. のれんを資産として認識し その後の期間にわたり償却するという要求事項を設けるべきであることに同意するか 同意する場合 次のどの理由で償却を支持するのか (a) 取得日時点で存在しているのれんは 時の経過に応じて消費され 自己創設のれんに置き換わる したがって のれんは 企業を取得するコストの一

Microsoft Word - JSQC-Std 目次.doc

監査に関する品質管理基準の設定に係る意見書

<4D F736F F D F815B B E96914F92B28DB8955B>

日経ビジネス Center 2

ISO19011の概要について

バリデーション基準 1. 医薬品 医薬部外品 GMP 省令に規定するバリデーションについては 品質リスクを考慮し 以下の バリデーション基準 に基づいて実施すること 2. バリデーション基準 (1) バリデーションの目的バリデーションは 製造所の構造設備並びに手順 工程その他の製造管理及び品質管理の

Microsoft PowerPoint - 【別紙1-2】メトリクスセットの利用ガイド.pptx

Sol-017 BPMSとの連携 _ppt [互換モード]

要求仕様管理テンプレート仕様書

<4D F736F F F696E74202D D4C82F08A B582BD A A F2E707074>

< E F824F F C581408B4B8A B818E968D80815E F824F825794C582C682CC918A88E1935F2E786C7378>

目次 4. 組織 4.1 組織及びその状況の理解 利害関係者のニーズ 適用範囲 環境活動の仕組み 3 5. リーダーシップ 5.1 経営者の責務 環境方針 役割 責任及び権限 5 6. 計画 6.1 リスクへの取り組み 環境目標

目次 1: 安全性とソフトウェア 2: 宇宙機ソフトウェアにおける 安全 とは 3:CBCS 安全要求とは 4: 宇宙機ソフトウェアの実装例 5: 安全設計から得た新たな知見 6: 今後 2

FSMS ISO FSMS FSMS 18

2. 目的 1RationalRose を利用する場合にプログラム仕様書としての最低限必要な記述項目を明確にする 2 プログラム仕様書として記載内容に不足がない事をチェックする 3UML の知識があるものであれば 仕様書の内容を理解できること 4Rose にて入力した内容を SoDaWord を利用

目次 1. 目的と適用範囲 定義 原則 使用機器 審査資料交付システム タブレット端末 管理運用体制 電磁的記録管理運用責任者の役割 電磁的記録管理運用担当者の役割

Microsoft Word - con 監査チェックリスト EMR

ISO/IEC 改版での変更点

<4D F736F F D20939D8D87837D836A B B816996E BB8DEC8F8A816A F90BB8DEC E646F63>

SGEC 附属文書 理事会 統合 CoC 管理事業体の要件 目次序文 1 適用範囲 2 定義 3 統合 CoC 管理事業体組織の適格基準 4 統合 CoC 管理事業体で実施される SGEC 文書 4 CoC 認証ガイドライン の要求事項に関わる責任の適用範囲 序文

目次 1. 一般 目的 適用範囲 参照文書 用語及び定義 内部監査 一般 内部監査における観点 内部監査の機会 監査室

システムズエンジニアリングとは? システムを成功させるための複数の専門分野にまたがるアプローチと手段である JCOSE(Japan Council on Systems Engineering) ここでいう システム は コンピュータシステムにとどまらず 機械 電気機器 人間系 ( 操作者 ) 環境

< C94C593E095948AC48DB E838A F902E786C7378>

Microsoft Word - ISO 9001要求事項のエッセンス 改 国府保周

5、ロット付番

1 適用範囲 2 引用規格 3 用語の定義 69の用語 4- 組織の状況新規 4.1- 組織とその状況の理解 [1] 2 組織は 組織組織の目的目的と戦略戦略の方向方向に関係する内外の課題課題を決定しなければならない これらの課題は 想定された結果を達成する上で品質マネジメントシステムの能力に影響す

ISO9001-whitepaper.pdf

Microsoft Word - №5 ISO22000.doc

Advance_LIMS+ESER_ pdf

<4D F736F F F696E74202D E291AB8E9197BF A F82CC8A A390698DF42E707074>

ISO/FDIS ISO 9001 の主要な変更点 1. 附属書 SL の適用 2. 組織の状況の理解と QMS の適用範囲の決定 3. プロセスアプローチの適用向上それを支援する PDCA サイクルとリスクに基づく考え方 4. リーダーシップの強化 5. 組織の意図した結果 顧客満足の向上 パフォ

DumpsKing Latest exam dumps & reliable dumps VCE & valid certification king

ISO/TC176/SC2/N1291 品質マネジメントシステム規格国内委員会参考訳 ISO 9001:2015 実施の手引 目次 1.0 序文 2.0 ISO 9001:2015 改訂プロセスの背景 3.0 ユーザグループ 4.0 実施の手引 4.1 一般的な手引 4.2 ユーザグループのための具

総合衛生管理製造過程と PDCAサイクル

図表 11に都道府県別取得件数 ( 上位 10 位 ) を 図表 12に産業分野別取得件数 ( 上位主要産業分野 ) を 図表 13に産業分野別取得件数の推移を示します 産業分野別件数 ( 図表 12) では最も多いのが 建設 の15,084 件 次いで 基礎金属 加工金属製品 の6,434 件 電

目 次 1. 適用範囲 P4 2. 引用規格 P5 3. 用語及び定義 P5 4. 組織の状況 P7 4.1 組織及びその状況の理解 P7 4.2 利害関係者のニーズ及び期待の理解 P7 4.3 個人情報保護マネジメントシステムの適用範囲の決定 P7 4.4 個人情報保護マネジメントシステム P7

恣意的に限定した適用範囲になっていませんか 主力サイトは適用範囲外になっていませんか ( 当該サイト活動を適用範囲外することにより経営的に大きな影響を受けていませんか ) 環境マネジメントシステムの意図した成果 ( 箇条 4.1) に影響する部門 部署を除外していませんか 適用範囲に含まれるサイトと

Microsoft PowerPoint - ISO9001規格要求事項の理解


< F2D816995BD90AC E30398C8E303493FA88EA959489FC90B3>

【NEM】発表資料(web掲載用).pptx

Microsoft Word - 品質マニユアル2015.doc

日本機械学会 生産システム部門研究発表講演会 2015 資料

統合化の概要次回の改訂時迄には ISO D Guide83 に沿って整合性を図った 要求事項の定義 要求事項タイトル 要求事項の順番 そして定期的な適切性や妥当性有効性等の強化を含む見直しによって追加補充や変更点への対応を含めた対応が必要とされるが 統合化の構成の概要は 以下の通りススムパートナーズ

i コンピテンシ ディクショナリ を 活用した品質エンジニアの育成 その 2 独立行政法人情報処理推進機構 HRD イニシアティブセンター 奥村有紀子

障害管理テンプレート仕様書

(情)07年度事業運営方針

Microsoft Word 移行監査の着眼点160402

目 次 1. タムラグループの環境活動 1 2. グリーン調達基準 1 第 1 章総則 1 第 2 章取引先様への要求事項 3 第 3 章材料 部品等の選定基準 3 第 4 章取引先様への調査内容 4 附則 5

Copyright Compita Japan ISO33k シリーズとは? これまで使用されてきたプロセスアセスメント標準 (ISO/IEC 本稿では以降 ISO15504 と略称する ) は 2006 年に基本セットが完成し 既に 8 年以上が経過しています ISO

組織内CSIRT構築の実作業

IAF ID 2:2011 Issue 1 International Accreditation Forum Inc. 国際認定機関フォーラム (IAF) IAF Informative Document ISO/IEC 17021:2006 から ISO/IEC 17021:2011 への マネ

Microsoft Word - ㆿㆡㆮ㆑EMS覑怼ï¼ı第丛盋_å“°å‹·çfl¨

変更履歴 バージョン日時作成者 変更者変更箇所と変更理由 RIGHTS R ESER VED. Page 2

表 3 厚生労働省新旧ガイドライン目次比較 は新ガイドラインで追加された項目 コンピュータ使用医薬品等製造所適正管理ガイドライン 第 1 目的 1. 総則 1.1 目的 第 2 適用の範囲 2. 適用の範囲 第 3 開発業務 1. 開発検討段階 (1) 開発段階の責任体制の確立 (2) 開発マニュア

040402.ユニットテスト

レジリエンスの取り組みに 関わるディスカッション

Transcription:

ISO/IEC 15288:2015 テクニカルプロセス解説 2015/8/26 システムビューロ

システムライフサイクル 2

テクニカルプロセス a) Business or mission analysis process b) Stakeholder needs and requirements definieon process c) System requirements definieon process d) Architecture definieon process e) Design definieon process f) System analysis process g) ImplementaEon process h) IntegraEon process i) VerificaEon process j) TransiEon process k) ValidaEon process l) OperaEon process m) Maintenance process n) Disposal process 赤 : 新規緑 : 名前の変更 3

Business or mission analysis process( 新規 ) u ビジネスまたはミッション分析プロセスの目的は ビジネスまたはミッションの問題や機会を定義することであり 解空間を特徴づけて 問題に対処または機会を利用するための解クラスを決定する u 問題または機会空間の定義 u 解空間の特徴づけ u 予備的な操作上の概念およびライフサイクル段階の他の概念の定義 u 解クラスの選択肢候補の識別または分析 u 解クラスの選択肢候補の選定 u ビジネスまたはミッション分析のために必要な対象システムまたはサービス u ビジネスまたはミッションの問題または機会に対する解クラスのトレーサビリティの確立 u ビジネスまたはミッション分析を準備する u 問題または機会空間を定義する u 解空間を特徴付ける u 解クラスを評価する u ビジネスまたはミッション分析を管理する 4

Stakeholder requirements definieon process( 変更前 ) u 定義された環境において 利害関係者に必要とされるサービスを提供できるように システムに対する要求を定義する u サービスで要求される利用の文脈 ( 内容 状況及び背景 ) の明示 u システムソリューションにおける制約の定義 u 利害関係者ニーズへのトレーサビリティの確立 u 利害関係者要求事項の定義 u 妥当性確認のための利害関係者要求事項の識別 u 利害関係者要求事項の引出し u 利害関係者要求事項を定義する u 利害関係者要求事項を分析及び維持する 5

Stakeholder needs and requirements definieon process( 変更後 ) u 利害関係者のニーズおよび要求定義プロセスの目的は 定義された環境においてユーザおよび他の利害関係者に必要な機能を提供できるシステムのための利害関係者要求を定義することである u システムの利害関係者を識別 u サービスで要求される利用の文脈 ( 内容 状況及び背景 ) の明示 u システム制約の識別 u 利害関係者ニーズの定義 u 利害関係者ニーズは優先度を付けられて 明確に定義された利害関係者要求へ変換 u 重要な性能指標の定義 u 要件においてそれらのニーズと予想が適正に反映される利害関係者合意の達成 u 利害関係者ニーズや要求のために必要なシステムまたはサービス u 利害関係者ニーズと利害関係者要求のトレーサビリティの確立 u 利害関係者ニーズと要求定義を準備する u 運用概念と他のライフサイクルの概念を開発する u 利害関係者ニーズを利害関係者要求へ変換する u 利害関係者ニーズおよび要求定義を管理する 6

Requirements Analysis Process( 変更前 ) u 望まれたサービスの利害関係者要求の視点を これらのサービスを提供できる要求された製品の技術的な視点へ変換する u 要求される特性 属性並びに機能及び性能への要求事項 u 方式設計及びそれを実現する手段に影響を及ぼす制約 u システム要求事項から利害関係者要求事項への完整性 (integrity) 及び追跡可能性 u システム要求事項が満たされていることを検証する基礎の定義 u システム要求事項の定義 u システム要求事項の分析及び維持 7

System requirements definieon process( 変更後 ) u システム要求定義プロセスの目的は 要求された機能の利害関係者またはユーザ指向のビューを ユーザの運用上のニーズを満たしているソリューションの技術ビューに変換することである u システムソリューションのためのシステム説明 システムインターフェース 機能 および境界を含む の定義 u システム要件 ( 機能 性能 プロセス 非機能 およびインターフェース ) と設計制約の定義 u 重要な性能指標の定義 u システム要求の分析 u 任意の有効システムやシステム要求定義のために必要なサービス u 利害関係者要求とシステム要求のトレーサビリティの開発 u システム要求定義を準備する u システム要求を定義する u システム要求を分析する u システム要求を管理する 8

Architecture Design process( 変更前 ) u システム要求事項を満たすソリューションをまとめあげる u 方式設計のベースラインが確立 u 要求事項を満足するシステム要素記述の実装可能な集合 u インターフェース要求事項 u 方式設計からシステム要求事項への追跡可能性 u システム要素を検証するための基礎の定義 u システム要素の結合のための基礎の確立 u 方式の定義 u 方式の分析及び評価 u 方式の文書化及び維持 9

Architecture definieon process( 変更後 ) u アーキテクチャ定義プロセスの目的は システムアーキテクチャの選択肢を生成し 利害関係者の懸念に対処する1つ以上の選択肢を選び システム要求を満たし 一貫性のあるビューのセットを定義することである u 識別された利害関係者の懸念はアーキテクチャによって対処 u アーキテクチャのビューポイントの開発 u システムのコンテキスト 境界 および外部のインターフェースの定義 u システムのアーキテクチャビューとモデルの開発 u 概念 プロパティ 特徴 行動 機能 またはシステムのアーキテクチャ決定のために重要な制約は アーキテクチャ上のエンティティに割り当て u システム要素およびそれらのインターフェースの識別 u アーキテクチャ候補の評価 u ライフサイクルにわたるプロセスのためのアーキテクチャ上の基礎の達成 u 要求および設計特性を持つアーキテクチャのアライメントの達成 u システムまたはアーキテクチャの定義に必要なサービス u 利害関係者およびシステム要求とアーキテクチャ要素のトレーサビリティの開発 u アーキテクチャ定義を準備する u アーキテクチャのビューポイントを開発する u モデルとアーキテクチャのビュー候補を開発する u 設計するアーキテクチャを関連付ける u アーキテクチャ候補を評価する u 選択されたアーキテクチャを管理する 10

Design definieon process( 新規 ) u 設計定義プロセスの目的は システムアーキテクチャのモデルとビューにおいて定義されるたアーキテクチャ上のエンティティと一致している実装を可能にするために システムおよびその要素についての十分な詳細データと情報を提供することである u 各システム要素の設計特性の定義 u システム要求をシステム要素に割り当て u 設計定義に必要な設計イネーブラの選択または定義 u システムを構成するシステム要素間のインターフェースの定義または洗練 u システム要素の設計代替案の評価 u 設計成果物の開発 u 設計定義に必要な任意の有効システムやサービス u システムアーキテクチャのアーキテクチャ上のエンティティへのデザイン特徴のトレーサビリティの確立 u 設計定義の準備する u 各システム要素に関連する設計特性と設計イネーブラを確立する u システム要素を取得するための代替案を評価する u 設計を管理する 11

System analysis process( 新規 ) u システム分析プロセスの目的は 意思決定のライフサイクル全体で支援するためのデータや技術的理解のための情報の厳格な基盤を提供することである n 分析対象 u 様々な異なる分析的な機能 複雑さのレベル 技術の性能 システム行動 実現可能性 値ごろ感 危険な品質特徴 技術のリスク ライフサイクルコストなど n 分析手法 u 数学的解析 モデリング シミュレーション 実験など u 必要なシステム分析の識別 u システム分析の前提と結果の検証 u システム分析結果 u システム分析のために必要なシステムやサービス u システム分析結果のトレーサビリティの確立 u システム分析を準備する u システム分析を実施する u システム分析を管理する 12

ImplementaEon process( 変更前 ) u 指定されたシステム要素を実現する u 実装戦略の定義 u 設計上の実装技術の制約 u システム要素の実現 u システム要素の合意に基づく供給及び保管 u 実装の計画 u 実装の遂行 13

ImplementaEon process( 変更後 ) u 指定されたシステム要素を実現する u 要件 アーキテクチャ またはデザインに影響する実装制約の識別 u システム要素の実現 u システム要素のグループ化および蓄積 u 実装のために必要などシステムまたはサービス u トレーサビリティの確立 u 実装を準備する u 実装を遂行する u 実装の結果を管理する 14

IntegraEon process( 変更前 ) u 方式設計と整合性がとれたシステムを組み立てる u システム結合戦略 u 要求事項に影響する不可避の結合制約 u 要求事項に対する検証が可能なシステムの結合 u 結合作業によって起こる不適合の記録 u 結合の計画 u 結合の実施 15

IntegraEon process( 変更後 ) u 統合プロセスの目的は システム要求 アーキテクチャ およびデザインを満たしている実現されたシステム ( 製品またはサービス ) にシステム要素のセットを統合することである u インターフェースを含むシステム要求 アーキテクチャ または設計に影響する統合制約の識別 u 組み立てられたインターフェースとシステム機能の正しい動作のためのアプローチとチェックポイントの定義 u 統合のために必要なシステムまたはサービス u 実装されたシステム要素により構成されているシステムの統合 u 実装されたシステム要素により構成されているシステムの要素間のインータフェース u システムと外部の環境の間のインターフェース u 統合結果と異常の識別 u 統合されたシステム要素のトレーサビリティの確立 u 結合を準備する u 結合を実施する 完全なシステムになるまで システム要素の構成を統合 u 結合の結果を管理する 16

VerificaEon process( 変更前 ) u 指定された設計要求事項がシステムによって満足されていることを確認する u 検証戦略の定義 u 要求事項に対する入力としての検証制約 u 是正処置のための提供情報 u システム要求事項及び方式設計を満足することを示す客観的な証拠 u 検証を計画する u 検証を実施する 17

VerificaEon process( 変更後 ) u 検証プロセスの目的は システムまたはシステム要素がその指定された要求と特性を満たしているという客観的な証拠を提供することである u 要求 アーキテクチャ またはデザインに影響する検証の制約の識別 u 検証に必要なシステムまたはサービス u システムまたはシステム要素の検証 u 矯正の行動のためのデータ 情報提供の報告 u 実現されるシステム要求を満たすアーキテクチャおよび設計が提供されることの客観的な証拠 u 検証結果や異常の識別 u 検証されたシステム要素のトレーサビリティの確立 u 検証を計画する u 検証を実施する u 検証結果を管理する 18

TransiEon process( 変更前 ) u 運用環境において 利害関係者要求事項によって指定されたサービスを供給する能力を確立する u システム移行戦略 u システムの運用場所への導入 u 指定されたサービスを提供する能力 u 導入された構成の記録 u 是正処置の報告 u サービスのイネーブリングシステムによる維持 u 移行を計画する u 移行を実施する 19

TransiEon process( 変更後 ) u 移行プロセスの目的は 運用環境における利害関係者の要求によって指定されたサービスを提供するためのシステムの能力を確立することである u システム要求 アーキテクチャ または設計に影響する移行制約の識別 u 移行のために必要なシステムまたはサービス u サイトの準備 u 運用場所にインストールされたシステムの指定された機能の供給 u システムの利用やサポートに必要なオペレータ ユーザや他の利害関係者の訓練 u 移行結果と異常の識別 u インストールされたシステムの稼働準備 u 移行要素のトレーサビリティの確立 u 移行を準備する u 移行を実施する u 移行結果を管理する 20

ValidaEon process( 変更前 ) u システムによって提供されるサービスが利用中に利害関係者要求事項を遵守し 意図された運用環境で 意図された利用を達成していることを示す客観的な証拠を提供する u 妥当性確認戦略 u 利害関係者による必要なサービスの可用性の確認 u 妥当性確認データ u 是正処置のための提供情報 u 妥当性確認を計画する u 妥当性確認を実施する 21

ValidaEon process( 変更後 ) u 妥当性確認プロセスの目的は システムが 使用中に その意図された運用環境においてその使用目的を達成するため そのビジネスやミッションの目的と利害関係者要求を満たしていることを客観的な証拠を提供することである u 利害関係者の要件の妥当性確認基準の定義 u 利害関係者が必要とするサービスの可用性の確認 u 要求 アーキテクチャ または設計に影響する妥当性確認の制約の識別 u システムまたはシステム要素の妥当性確認 u 妥当性確認のために必要なシステムまたはサービス u 妥当性確認結果や異常の識別 u システムまたはシステム要素が 利害関係者ニーズを満たしているという客観的証拠 u 妥当性確認後のシステム要素のトレーサビリティの確立 u 妥当性確認を準備する u 妥当性確認を実施する u 妥当性確認結果を管理する 22

OperaEon process( 変更前 ) u サービスを提供するためにシステムを利用する u 運用の戦略 u 利害関係者要求事項に合致したサービス u 承認された是正処置の完了 u 利害関係者の満足度の維持 u 運用を準備する u 運用開始及びテストを実施する u 運用のためのシステムを利用する u 運用上の問題を解決する u 顧客をサポートする 23

OperaEon process( 変更後 ) u 運用プロセスの目的は サービスを提供するためにシステムを利用することである u システム要求 アーキテクチャ または設計に影響する運用制約の識別 u 運用に必要などのようなシステム サービス および素材 u トレーニングを受けたオペレータ u 利害関係者要求を満たしているシステムサービスのデリバリー u 運用中のシステム性能の監視 u 顧客へのサポートの提供 u 運用を準備する u 運用を実施する u 運用結果を管理する u 顧客をサポートする 24

Maintenance process( 変更前 ) u サービスを提供するためにシステムの能力を維持する u 保守の戦略 u 要求事項に対する入力としての保守に関する制約 u 交換するシステム要素 u 利害関係者要求事項に合致しているサービス u 是正のための設計変更のニーズ u 故障及び寿命時間データ u 保守を計画する u 保守を実施する 25

Maintenance process( 変更後 ) u 保守プロセスの目的は サービスを提供するためにシステムの能力を維持する u システム要求 アーキテクチャ または設計に影響する保守制約の識別 u 保守のために必要なシステムまたはサービス u 交換 修理 または改訂されたシステム要素 u 変更を補正するか 完全にするか 適応可能な保守に関する報告 u 費用を含む故障や生涯データの決定 u 保守を準備する u 保守を実施する u 物流のサポートを実施する u 保守や物流の結果を管理する 26

Disposal process( 変更前 ) u システム実体の存在を終了させる u システムの廃棄戦略 u 要求事項の入力としての廃棄の制約 u システム要素の破棄 保管 回収又は再生利用 u 元の状態又は合意した状態の環境 u 廃棄活動に関する知識保持及び長期的な危機の分析を可能にする記録 u 廃棄を計画する u 廃棄を実施する u 廃棄を終了する 27

Disposal process( 変更後 ) u 廃棄プロセスの目的は 指定され意図された用途のためのシステム要素またはシステムの存在を終了することで 交換または退去した要素を適切に処理し 識別された危険を適切に処分する ( 例えば 1 つの組織的な方針あたり または環境 法律 安全 セキュリティあたり ) u 廃棄の制約は 要求 アーキテクチャ 設計 実装の入力として提供 u 廃棄のために必要なシステムまたはサービス u システム要素または廃棄物は 安全でセキュリティ要求に従って破壊されるか 保存されるか 再利用されるか リサイクルされる u 環境はそのオリジナルまたは同意された状態に復帰 u 廃棄アクションと分析の記録 u 廃棄を準備する u 廃棄を実施する u 廃棄を終了する 28