Unified Profile for DoDAF and MODAF Avatar
  1. OMG Specification

Unified Profile for DoDAF and MODAF — All Issues

  • Acronym: UPDM
  • Issues Count: 12
  • Description: All Issues
Open Closed All
All Issues

Issues Descriptions

Replace ActivityPerformableUnderCondition with a Tag

  • Key: UPDM2-53
  • Legacy Issue Number: 16223
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Replace ActivityPerformableUnderCondition with a Tag

  • Reported: UPDM 1.1 — Wed, 11 May 2011 04:00 GMT
  • Disposition: Resolved — UPDM 2.0
  • Disposition Summary:

    Rationale Reduces the amount fo drawing required to create the
    tuple
    Resolution Created a tag with the same name on an Activity and
    typed by environment

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Need to change generalisation section text for all elements to be a specialisation

  • Key: UPDM2-52
  • Legacy Issue Number: 16222
  • Status: closed  
  • Source: International Business Machines ( Graham Bleakley)
  • Summary:

    Need to change generalisation text for each element from

    original text format
    • Generalizations
    The following are generalization relationships for OrganizationalProjectRelationship:

    To, revised text format

    · Specializations

    The OrganizationalProjectRelationship element is a specialization of:

  • Reported: UPDM 1.1 — Wed, 11 May 2011 04:00 GMT
  • Disposition: Resolved — UPDM 2.0
  • Disposition Summary:

    Rationale Correct text required
    Resolution Change format

  • Updated: Fri, 6 Mar 2015 23:15 GMT

Broken link for issue reporting


Incorrect acknowledgement

  • Key: UPDM2-10
  • Legacy Issue Number: 16688
  • Status: closed  
  • Source: Logica UK ( Peter Bryant)
  • Summary:

    C.3.2 includes an acknowledgement for the original authors of the SAR model in MODAF, which I believe was included at my request.
    The listing for 'Peter Martin of LogicaCMG' should read 'Peter Bryant of Logica'.

  • Reported: UPDM 1.1 — Wed, 16 Nov 2011 05:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    Think this was done in the Jan 12 revision but we need to note in RTF.

    Current text in OMG 12-01-03 document is the following:
    ________________________________
    D.3.2 Acknowledgements
    The scenario is derived from the UK Search and Rescue framework, which is publicly available on the internet3. The sample problem is based on a concept derived by VEGA under contract for the UK MOD.4 The UPDM Group acknowledges its debt owed to the authors of the original problem:

    • Ian Bailey of Model Futures,
    • Peter Bryant of Logica, and
    • Paul King of Vega
    ____________________________________________________________

    We need to ensure that this change is in version 2.1 as well

  • Updated: Fri, 6 Mar 2015 20:59 GMT

The ISO8601:2004 is probably a normative reference and should be placed in section 3

  • Key: UPDM2-9
  • Legacy Issue Number: 16641
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The ISO8601:2004 is probably a normative reference and should be placed in section 3.

    Recommended text:

    ISO 8601:2004 Data elements and interchange formats – Information interchange – Representation of dates and times”, IS0, TC154

  • Reported: UPDM 1.1 — Fri, 28 Oct 2011 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    Update the document section 3 as proposed

    Add the following text as an additional bullet point in section 3.2:

    • ISO 8601:2004 Data elements and interchange formats – Information interchange – Representation of dates and times, IS0, TC154
    http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?ics1=01&ics2=140&ics3=30&csnumber=40874

  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.2.1.1.3 and 8.2.1.1.3.1 define ISO8601DateTime

  • Key: UPDM2-8
  • Legacy Issue Number: 16640
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The text for the definition in 8.2.1.1.3.1 is not internally consistent, nor consistent with ISO8601

    Current Text

    “MODAF: A date and time specified in the ISO8601 date-time format including timezone designator (TZD):
    YYYY-MMDDThh:mm:ssTZD So, 7:20pm and 30 seconds on 30th July 2005 in the CET timezone would be represented as “2005- 07-30T19:20:30+01 :00.”

    You may notice that the “-“ and “ “ in the pattern definition and in the example are not consistent. The ISO definition is as follows:

    YYYY-MM-DDThh:mm:ssTZD

    Where TZD= Z for Zulu (GMT)

    = or ±NN:NN

    With the example of 7:20 pm and 30 seconds on 30th July 2005 in the CET (Central European)Timezone would be

    “2005-07-30T19:20:30+01:00”

    Suggested Fix.

    a) Correct Pattern definition

    YYYY-MMDDThh:mm:ssTZD à YYYY-MM-DDThh:mm:ssTZD (where TZD=Z or ±NN:NN)

    This adds the – between the MM and DD subfields, and explains the possible values for the TZD field

    b) Correct Example

    2005- 07-30T19:20:30+01 :00 à 2005-07-30T19:20:30+01:00

    This drops the extra space before the month and after the timezone offset hour.

  • Reported: UPDM 1.1 — Fri, 28 Oct 2011 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    The current version of the specfiication has the correct definition of IS08601 date time in the spec. Therefore it was decided to close this issue with no change

    Proposed Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Increment and out of service milestones do not pair

  • Key: UPDM2-7
  • Legacy Issue Number: 16580
  • Status: closed  
  • Source: No Magic, Inc. ( Aurelijus Morkevicius)
  • Summary:

    Increment and out of service milestones do not pair. For instance if you have two out of service milestones defined you cannot know which one is the right one for a concrete increment. I'm thinking about solving this issue by using milestone sequence relationship; however project sequence can be used for other purposes as well. The usage of it is somehow ambiguous, especially in a case like this.

  • Reported: UPDM 1.1 — Mon, 3 Oct 2011 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    After discussion with Lars, there are some rules that need be made explicit in the spec. I.e capability increments that are related by CapabilityIncrement then ConfigurationDeployed, ConfigurationNoLongerUsed (as configuration is dropped by Actual org) and finally OutOfService when no org is using the configuration.

    Add some descriptive text to the elements above as guidance on usage. This is added in the description of the diagrams that are used to capture Milestones which are AcV-2/PV-2

    Add the following Descriptive text to the following section:

    Updated Text:

    B.1.1.2 AcV-2/PV-2

    IncrementMilestone and OutOfServiceMilestone are both tied to a particular SystemResource, this implies that the connection to a given SystemResource indicates how the pairing should be made.

    All in all there are 4 different milestones for which there is an implied order. This order is however not enforced by the framework and needs to be dealt with by the architect. The rules for this ordering are as follows:
    • IncrementMilestone:
    Has to be associated with a date that precedes all milestones below for a specified uniquely identifiable SystemResource.
    • DeployedMilestone:
    Has to be associated with a date that occurs after the IncrementMilestone and associated the SystemResource with a specific Organization,
    • NoLongerUsedMilestone:
    Has to be associated with a date that occurs after the DeployedMilestone for a specific SystemResource, Organization combination. This milestone cannot exist if the DeployedMilestone does not exist for the same given SystemResource, Organization combination.
    • OutOfServiceMilestone:
    Has to be associated with date that occurs after or at the same time as the latest NoLongerUsedMilestone for the uniquely identifiable SystemResource and requires that no organization still has this system resource deployed (or after the IncrementMilestone if the SystemResource was never deployed to any organization before being put outOfService).

  • Updated: Fri, 6 Mar 2015 20:59 GMT

capability to assign actual organizational resources to a project in a particular time frame missing

  • Key: UPDM2-6
  • Legacy Issue Number: 16579
  • Status: closed  
  • Source: No Magic, Inc. ( Aurelijus Morkevicius)
  • Summary:

    . I'm missing a capability to assign actual organizational resources to a project in a particular time frame. There is a relationship called Organizational Project Relationship, however it does not have start and end date properties. By not having this capability I cannot calculate how much time on a project spent one or another employee and compare this value with a number required by typical organizational resources for the same project.

  • Reported: UPDM 1.1 — Mon, 3 Oct 2011 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    see pages 39 through 44 of dtc/2012-12-16 for details

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Project Sequence should have a tag Sequence Kind

  • Key: UPDM2-5
  • Legacy Issue Number: 16578
  • Status: closed  
  • Source: No Magic, Inc. ( Aurelijus Morkevicius)
  • Summary:

    I would suggest Project Sequence would have a tag Sequence Kind to store values like "start-to-start", "start-to-finish", "finish-to-start", and “finish-to-finish".

  • Reported: UPDM 1.1 — Mon, 3 Oct 2011 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    The rationale behind the request is that it keeps alignment with standard project management tools. Aurelijus suggested a text field to describe this relationships, Lars said this is outside the intent of MODAF and there is an implicit understanding that a target project cannot start until source project finishes.

    There is a workaround which is to use measurements applied to project to capture this information.

    Therefore it was decided to close this issue with no change

    Proposed Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

It's not possible to show that a resource configuration realizes two or more capabilities at different periods of time

  • Key: UPDM2-4
  • Legacy Issue Number: 16577
  • Status: closed  
  • Source: No Magic, Inc. ( Aurelijus Morkevicius)
  • Summary:

    It is not possible to show that a resource configuration realizes two or more capabilities at different periods of time. It is because increment and out of service milestones are not related to capability. By not having this relationship all periods of time that are described by milestones are applicable to both capabilities realized by the same resource. For instance I want to say that my configuration X will realize capability A starting from 2010.01.01 till 2011.02.12 and will realize capability G starting from 2011.03.01 till 2011.04.12. As I've mentioned before milestones that are holding the date values are not related to capabilities, so what I get is capabilities A and G are realized by the resource configuration X in two periods of time (from 2010.01.01 till 2011.02.12 and from 2011.03.01 till 2011.04.12). By not having relationship between capability and a milestone I can say that for instance increment milestone holding date 2011.03.01 is incrementing G capability. But it can increment A capability as well.

  • Reported: UPDM 1.1 — Mon, 3 Oct 2011 04:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    Leave it how it is. This information needed to be captured as it is outside the scope of MODAF STV-3

    Add guidance to the spec in the context of the framework that a person is using. Text added to STV-3 description in the model

    Add the following text to section A.1.5.4 StV-3/CV-3 and section B1.5.4 StV-3/CV-3

    The IncrementMilestone and RetirementMilestone in UPDM originate from the MODAF framework. They tie to a PhysicalArchitecture/ CapabilityConfiguration and if the latter is indicated this in turn ties to a Capability since it is a CapableElement that exhibits a Capability. Capabilities are by themselves timeless i.e. it should not be possible to associate Capabilities and time directly. If an IncrementMilestone connects to CapabilityConfiguration X at time T and this configuration realizes Capability A, it cannot at a later time also realize Capability B without something having changed, i.e. there has to be a CapabilityConfiguration X’ that is tied to an IncrementMilestone where capabilities A and B are realized. It is suggested that these two CapabilityConfigurations are treated as versions of a CapabilityConfiguration master (SV-8).

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Document still references DoDAF v1.5, when it should reference DoDAF V2.02

  • Key: UPDM2-12
  • Legacy Issue Number: 16912
  • Status: closed  
  • Source: MITRE ( Fatma Dandashi)
  • Summary:

    See Page 255 of the UPDM,

    “Table B.1 shows the traceability among UPDM stereotypes and DODAF 1.5/MODAF elements”

    The table column heading: “DoDAF 1.5 Model Elements”

    Page 275: “The scenario and modeling was easily updated to include UPDM concepts including US DoDAF 1.5.”

    Do a search and replace on all references to DODAF v1.5 in the UPDM v2.0 spec: dtc/2011-05-07

  • Reported: UPDM 1.1 — Thu, 15 Dec 2011 05:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    This issue appears to be fixed, but we did a search on other references to DoDAF 1.5 that should be DoDAF 2.0 and we found that the description for the technical standards elements needed to be updated.

    Make the following change:

    "Replace the text of section 8.3.1.3.7 UPDM L1: :UPDM L0: :Core: :TechnicalStandardsElements

    Section 1.4.4 of the DoDAF version 1.5 Definitions and Guidelines (Volume I): Define the purpose of the Technical View as follows:
    “The TV is the minimal set of rules governing the arrangement, interaction, and interdependence of system parts or elements. Its purpose is to ensure that a system satisfies a specified set of operational requirements. The TV provides the technical systems implementation guidelines upon which engineering specifications are based, common building blocks are established, and product lines are developed. It includes a collection of the technical standards, implementation conventions, standards options, rules, and criteria that can be organized into profile(s) that govern systems and system or service elements for a given architecture.”

    With:

    “UPDM 2.0 retains the TV Viewpoint which maps to the new DoDAF 2.02 StdV Standards Viewpoint. DoDAF Version 2.02, “DoDAF Viewpoints and Models: Standards Viewpoint” defines the purpose of the Standards Views. StdV-1 is a wider definition of the concept of “technical standard” than used in previous DoDAF versions. Such standards were restricted, for example, to ISO, OMG, OASIS, and similar standards) and could be found in the DoD IT Standards Registry (DISR). It now includes not only such software (information technology) standards but wider standards including hardware and other technologies. It includes protocols and data standards. It now is expanded to include technical, operational, and business standards defined liberally as well as guidance, policy, regulations, and laws applicable to the architecture being described. The StdV-1 is a set of such standards that applies to one (current) time-period. If emerging standards are addressed for a future period of time, a StdV-2 Standards Forecast should be completed as well. The purpose of StdV is both to specify the standards with which a project must comply as well as to planning for additional or future application of standards. The StdV collates the various systems, services, etc. with the rules (standards) that govern the implementation of the architecture. A typical StdV should reference elements used in the various other System Views (SV) (SV-1, 2, 4, 6), Service Views (SvcV-1, 2, 4, 6) and layers DIV (DIV-2 and DIV-3). Protocols often are Resource Flow descriptions defined in SV-2 and SvcV-2. The degree of compliance to standards may also be addressed in risk assessments."

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Need to add a conforms to relationship for an element of type Interface to be able to associate a standard with it

  • Key: UPDM2-11
  • Legacy Issue Number: 16718
  • Status: closed  
  • Source: MITRE ( Fatma Dandashi)
  • Summary:

    Need to add a conforms to relationship for an element of type Interface to be able to associate a standard with it

  • Reported: UPDM 1.1 — Fri, 18 Nov 2011 05:00 GMT
  • Disposition: Resolved — UPDM 2.0.1
  • Disposition Summary:

    We did not want to add any further elements to the UPDM spec and there are potential workarounds for this issue as it is possible to associate a standard using the ConformsTo tag on ResourceInterfaces or ResourcePorts or it could be done using a SysML satisfy between the interface and the standard.

    It was decided to close this issue with no change

    Proposed Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:59 GMT