|
5.5 configuration_management［SHI］
configuration_management UoFは、モールド形状定義の承認・版・変更に関する履歴に必要な情報について定義する。ここではDIS−Annex G（ARM）を参照しながら、configuration_management UoFに含まれる20個のアプリケーションオブジェクトについて解説していく。
5.5.1 Approval_event（DIS−4.2.3）
Approval_eventは、組織的なレビューと承認の状態または若干の製品データの証明において変更点を記録するEvent（DIS−4.2..33参照）である。
Approval_eventと関連するデータは、以下の通りである。
−approval_reference
−result
−user_defined_result
5.5.1.1 approval_reference（DIS−4.2.3.1）
approval_referenceは、Approval_eventによって生じるApproval_historyについて詳述する。あらゆるApproval_eventは、正確に1つのApproval_history（DIS−4.2.4参照）を参照する。アプリケーションアサーション（DIS−4.3.1）を参照のこと。
| 注） |
|
| |
approval_feference属性は、Approval_history（DIS−4.2.4参照）のための属性承認とは逆のものである。 |
5.5.1.2 result（DIS−4.2.3.2）
resultは、承認を必要とする設計のバージョンのための承認決定である。resultは、以下のうちの1つである。
−approved
−rejected
−unapproved
−user_defined.
| 注） |
|
| |
resultのために許可される値の定義は、本報告書の5.5.1.2.1〜5.5.1.2.4（DIS−4.2.3.2.1〜4.2.3.2.4）を参照のこと。 |
5.5.1.2.1 approved（DIS−4.2.3.2.1）
製品データは適切な組織によってチェックされて、船のために使うことが認められる、あるいは船のために使うことが公認されることを言う。
5.5.1.2.2 rejected（DIS−4.2.3.2.2）
製品データは適切な組織によってチェックされて、船のために使うことが認められない、あるいは船のために使うことが公認されないことを言う。
| 注） |
|
| |
通常代わりの製品データが、拒絶された製品データを取り替えるために造られる。 |
5.5.1.2.3 unapproved（DIS−4.2.3.2.3）
製品データは、まだチェックされていない状態か、組織によって承認または公認のための確認されるプロセスの中にある状態を言う。
5.5.1.2.4 user_defined（DIS−4.2.3.2.4）
プロジェクトに特有の承認状態コードで製品データの特定のバージョンに割り当てられる。少なくとも2つ以上の交換している組織によって決定される。
5.5.1.3 user_defined_result（DIS−4.2.3.3）
user_defined_resultは、user-definedされた承認状態について詳述する。
user_defined_resultは、特定のApproval_eventのために詳述される必要はない。
| 注） |
|
| |
Approval_eventの結果がUSER_DEFINEDであるとき、User_defined_resultはオプションでない。 |
5.5.2 Approval_history（DIS−4.2.4）
Approval_historyは、製品データの部分のために定義される特定のタイプの全てのApproval_events（DIS−4.2..3参照）のコレクションである。Approval_historyと関連するデータは、以下の通りである。
−approvals
−status
−subject
5.5.2.1 approvals（DIS−4.2.4.1）
approvalsは、現在の時間まで起こったApproval_eventsのシーケンスについて詳述する。Approval_historyは、少なくとも1つのApproval_eventから構成されている。
アプリケーションアサーション（DIS−4.3.1）を参照のこと。
| 注） |
|
| |
Approval_eventsのシーケンスは、時系列順である。 |
5.5.2.2 status（DIS−4.2.4.2）
statusは、承認の現在の状態を詳述する。statusは、以下のうちの1つである。
−approved
−rejected
−unapproved
−user_defined
| 注） |
|
| |
statusのために許可される値の定義については、本報告書の5.2.2.2.1〜5.2.2.2.4（DIS−4.2.4.2.1〜4.2.4.2.4）を参照のこと。 |
5.5.2.2.1 approved（DIS−4.2.4.2.1）
製品データは適切な組織によってチェックされて、船のために使うことが認められる、あるいは船のために使うことが公認される。
5.5.2.2.2 rejected（DIS−4.2.4.2.2）
製品データは適切な組織によってチェックされて、船のために使うことが認められない、あるいは船のために使うことが公認されない。
| 注） |
|
| |
通常代わりの製品データが、拒絶された製品データを取り替えるために造られる。 |
5.5.2.2.3 unapproved（DIS−4.2.4.2.3）
製品データは、まだチェックされていない状態か、組織によって承認または公認のための確認されるプロセスの中にある状態を言う。
5.5.2.2.4 user_defined（DIS−4.2.4.2.4）
プロジェクトに特有の承認状態コードで製品データの特定のバージョンに割り当てられる。少なくとも2つ以上の交換している組織によって決定される。
5.5.2.3 subject（DIS−4.2.4.3）
subjectは、この承認の関連がある製品データについて詳述する。アプリケーションアサーション（DIS−4.3.2）を参照のこと。
| 注） |
|
| |
Definitionは、ゼロ、1または多くの関連するApproval_historyオブジェクトを持つ事がある。Definitionが1つ以上の関連するApproval_historyを持つ場合は、Approval_historyオブジェクトに同じものはない。 |
5.5.1〜5.5.2で解説した、2つのアプリケーションオブジェクト
−Approval_event
−Approval_history
に関する、ARM EXPRESS-Gを図5.5-1に示す。
| （拡大画面：16KB） |
|
| 図5.5−1 |
configuration_management ARM EXPRESS-G diagram（1） |
5.5.3 Change（DIS−4.2.10）
Changeは一種のItem（DIS−4.2..52参照）で、顧客または設計を行う組織からの変更要求によって生じる製品モデルに対する、潜在的なあるいは実際の変更点と関連する全てのステージの焦点について表現する。
| 注） |
|
| |
Changeは、製品モデル・データの修正に結びつくこともあるが、結びつかないこともある。全ての計画されたあるいは実際の製品モデルヘのchangeは、関連するChange_definitionオブジェクトの中で文書化される。Changeと関連するデータは、以下の通りである。 |
−the_class
5.5.3.1 the_class（DIS−4.2.10.1）
the_classは、変更点の組織的な役割の資格について詳述する。
| 例） |
|
| |
クラスの型は、Headquarter Modification RequestまたはEngineering Change
Proposalである。 |
5.5.4 Change_definition（DIS−4.2.11）
Change_definitionはDefinition（DIS−4.2..22参照）の1タイプで、Changeの主立った別々のステージの概念である。Change_definitionは、Change_plan（DIS−4.2..13参照）、Change_realization（DIS−4.2..14参照）またはChange_request（DIS−4.2..15参照）であるかもしれない。Change_definitionと関連するデータは、以下の通りである。
−author
−date_time;
−defined_for；
−local_units.
5.5.4.1 author（DIS−4.2.11.1）
authorは、前のものの終わりから、存在するならばChange-definitionが終わるまでの期間の間、Change activitiesに対して責任がある人または組織について詳述する。
5.5.4.2 date_time（DIS−4.2.11.2）
date_timeは、Change_definitionが着いたときの日付と時間について詳述する。
5.5.4.3 defined_for（DIS−4.2.11.3）
defined_forは、Change_definitionが適用できるChangeについて詳述する。アプリケーションアサーション（DIS−4.3.3）を参照のこと。
5.5.4.4 local_units（DIS−4.2.11.4）
local_unitsは、definitionによって使われて、船のグローバルに定義される単位と異なる単位について詳述する。Local_unitsは、Derived_unit（DIS−4.2..24参照）あるいはNamed_unit（DIS−4.2..70参照）であるかもしれない。Local_unitsはそれに含まれる値を持たないこともあり得る。あるいは、重複なしで、1つ以上の値を持つこともあり得る。アプリケーションアサーション（DIS−4.3.4,DIS−4.3.5）を参照のこと。
| 注） |
|
| |
Definition（DIS−4.2..22参照）から受け継いだlocal_units属性は、Functional_definitionによって必要とされない。 |
5.5.5 Change_impact（DIS−4.2.12）
Change_impactはChange（DIS−4.2..10参照）が引き起こすか、あるいは引き起こした、効果について定義する。Change_impactと関連するデータは、以下の通りである。
−impact
5.5.5.1 impact（DIS−4.2.12.1）
impactは、いくつかのDefinitionオブジェクト、Item_structureオブジェクトまたはItem_relationshipオブジェクトの作成、修正または削除に関する、Changeの効果について詳述する。アプリケーションアサーション（DIS−4.3.6）を参照のこと。
5.5.6 Change_plan（DIS−4.2.13）
Change_planは一種のChange_definition（DIS−4.2..11参照）で、Change（DIS−4.2..10参照）によって提案された解答を表現する。Change_planは、製品モデルでChangeを実行するために必要な活動のための基準である。Change_planと関連するデータは、以下の通りである。
−checks
−chosen_solution_for
−planned_impact.
5.5.6.1 checks（DIS−4.2.13.1）
checksは、Changeのために予定される確認について詳述する。アプリケーションアサーション（DIS−4.3.8）を参照のこと。
5.5.6.2 chosen_solution_for（DIS−4.2.13.2）
chosen_solution_forは、Change_planが適用できるChange_request（DIS−4.2.15参照）の識別について詳述する。アプリケーションアサーション（DIS−4.3.9）を参照のこと。
5.5.6.3 planned_impact（DIS−4.2.13.3）
planned_impactは、評価されるか計算されたChangeの効果について詳述する。アプリケーションアサーション（DIS−4.3.7）を参照のこと。
| 注） |
|
| |
このことによる影響は、通常Change_requestのsolution_alternativesのセットから選ばれる。 |
5.5.7 Change_realization（DIS−4.2.14）
Change_realizationは一種のChange_definition（DIS−4.2..11参照）で、Change（4.2.10参照）によって実際に観察された効果について定義する。
Change_realizationと関連するデータは、以下の通りである。
−checks
−impact
−realization_of.
5.5.7.1 checks（DIS−4.2.14.1）
checksは、Changeを実行する製品モデル改訂の組織的な承認について詳述する。アプリケーションアサーション（DIS−4.3.11）を参照のこと。
5.5.7.2 impact（DIS−4.2.14.2）
impactは、製品モデルに作られる修正の識別について詳述する。アプリケーションアサーション（DIS−4.3.10）を参照のこと。
5.5.7.3 realization_of（DIS−4.2.14.3）
realization_ofは、製品モデルの修正が実行されているChange_plan（DIS−4.2.13参照）について詳述する。アプリケーションアサーション（DIS−4.3.12）を参照のこと。
5.5.8 Change_request（DIS−4.2.15）
Change_requestは一種のChange_definition（DIS−4.2..11参照）であり、Change（DIS−4.2..10参照）と解決可能な選択肢の必要性が確立される最初のフェーズについて表現する。
Change_requestと関連するデータは、以下の通りである。
−addressee
−initiator
−problem
−solution_alternatives
−solution_description
5.5.8.1 addressee（DIS−4.2.15.1）
addresseeは、人と、あるいは宛名を依頼された人と組織について詳述する。addresseeは、特定のChange_requestのために詳述される必要はない。
5.5.8.2 initiator（DIS−4.2.15.2）
initiatorは、人と、あるいは要請が来ている人と組織について詳述する。
5.5.8.3 problem（DIS−4.2.15.3）
problemは、要請を引き起こした問題の原文の記述について詳述する。
5.5.8.4 solution_alternatives（DIS−4.2.15.4）
solution_alternativesは、問題を解決するために提案される代わりの解決案について詳述する。解決案は、Versionable_objectオブジェクト（DIS−4.2..121参照）に対する効果に関して記述される。アプリケーションアサーション（DIS−4.3.13）を参照のこと。
5.5.8.5 solution_description（DIS−4.2.15.5）
solution_descriptionは、問題の1つ以上の可能な解答の原文の記述について詳述する。solution_alternativesがまだ確立されないか、solution_alternativesによって提供される情報を強化しないならば、この原文の記述は存在しなければならない。
solution_descriptionは、特定のChange_requestのために詳述される必要はない。
5.5.9 Check（DIS−4.2.16）
Checkは、一種のEvent（DIS−4.2.33参照）で、計画されているあるいは完了した、Change_planまたはChange_realization.のための組織と承認の詳細について定義する。
|
