Essence Avatar
  1. OMG Specification

Essence — All Issues

  • Acronym: Essence
  • Issues Count: 63
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
ESSENCE12-2 Semantics update Essence 1.0 Essence 1.2 Resolved closed
ESSENCE12-1 Team and Team Member alpha refinement proposals Essence 1.0 Essence 1.2 Resolved closed
ER-45 ActivitySpaceAndActivity::Language elements diagram lost Essence 1.0 Essence 1.1 Resolved closed
ER-43 Correction to the resolution to Issue ER-2 Essence 1.0 Essence 1.1 Resolved closed
ER-13 None of the Activity Spaces seems to address the Requirements::Addressed Alpha State Essence 1.0 Essence 1.1 Duplicate or Merged closed
ER-8 Wrong usage of Alpha Containment Essence 1.0 Essence 1.1 Resolved closed
ER-7 Error in recent change of definition of Practice Essence 1.0 Essence 1.1 Resolved closed
ER-5 Request to change phrase "completion criteria" to "prmary goals" Essence 1.0b1 Essence 1.1 Closed; No Change closed
ER-4 Change Requested to Activity Space Symbol Essence 1.0b1 Essence 1.1 Closed; No Change closed
ER-3 Introduction of level of detail cards Essence 1.0b1 Essence 1.1 Resolved closed
ER-2 Enhancements on attributes and card layout for checkpoints Essence 1.0b1 Essence 1.1 Resolved closed
ER-1 Enhancements on Competencies and Competency level definition Essence 1.0b1 Essence 1.1 Closed; No Change closed
ER-11 Completion criteria typo Essence 1.0 Essence 1.1 Duplicate or Merged closed
ER-12 Issue on Essence 1.0 metamodel Essence 1.0b1 Essence 1.1 Resolved closed
ER-37 Semantics update Essence 1.0 Essence 1.1 Deferred closed
ER-36 Team and Team Member alpha refinement proposals Essence 1.0 Essence 1.1 Deferred closed
ER-15 SEMANTIC DISCIPLINE ISSUE Essence 1.0b1 Essence 1.1 Closed; No Change closed
ER-14 PRINCIPLE OF ALPHA STATE INDEPENDENCE Essence 1.0b1 Essence 1.1 Closed; No Change closed
ER-21 Completion criteria with multiple states from the same alpha Essence 1.0 Essence 1.1 Resolved closed
ER-16 UNDERSTANDABILITY ISSUE Essence 1.0b1 Essence 1.1 Closed; No Change closed
ER-6 Error in definition of Activity Essence 1.0 Essence 1.1 Resolved closed
ESSENCE-223 New Section on Competency Detail Level Card Essence 1.0b1 Essence 1.0 Resolved closed
ESSENCE-208 Wrong reference in OCL expression on LanguageElement Essence 1.0b1 Essence 1.0 Resolved closed
ESSENCE-207 Wrong reference in OCL expression on kernel Essence 1.0b1 Essence 1.0 Resolved closed
ESSENCE-205 In element Action, change attribute kind from type String to Enumeration Essence 1.0b1 Essence 1.0 Resolved closed
ESSENCE-204 Diagram Interchange Metamodel missing in Essence Metamodel Essence 1.0b1 Essence 1.0 Resolved closed
ESSENCE-203 Request to change phrase "completion criteria" to "prmary goals" Essence 1.0b1 Essence 1.0 Deferred closed
ESSENCE-202 Change Requested to Activity Space Symbol Essence 1.0b1 Essence 1.0 Deferred closed
ESSENCE-201 Wrong reference in OCL expression on practices Essence 1.0b1 Essence 1.0 Resolved closed
ESSENCE-177 Attribute “approach” on Activities should be promoted to a first class citizen Essence 1.0b1 Essence 1.0 Resolved closed
ESSENCE-176 Name of Requirements Alpha state between Conceived and Coherent Essence 1.0b1 Essence 1.0 Closed; No Change closed
ESSENCE-175 Acknowledgment missing Essence 1.0b1 Essence 1.0 Resolved closed
ESSENCE-174 Coherency vs. Coherence usage Essence 1.0b1 Essence 1.0 Resolved closed
ESSENCE-173 Substitute Method's property name Completeness by Sufficiency Essence 1.0b1 Essence 1.0 Closed; No Change closed
ESSENCE-172 Practices has objectives not purposes Essence 1.0b1 Essence 1.0 Resolved closed
ESSENCE-171 Missing reference for a subclause in Method definition Essence 1.0b1 Essence 1.0 Resolved closed
ESSENCE-170 Consistency of definitions in the specification Essence 1.0b1 Essence 1.0 Resolved closed
ESSENCE-169 Alpha: Essential Qualities Essence 1.0b1 Essence 1.0 Resolved closed
ESSENCE-168 CRUD on Activities Essence 1.0b1 Essence 1.0 Closed; No Change closed
ESSENCE-167 Entry Criteria on Abstract Activities Essence 1.0b1 Essence 1.0 Resolved closed
ESSENCE-166 Enhancements on competency levels and cards Essence 1.0b1 Essence 1.0 Resolved closed
ESSENCE-165 Introduction of level of detail cards Essence 1.0b1 Essence 1.0 Deferred closed
ESSENCE-164 Level of detail diagram is counter intuitive Essence 1.0b1 Essence 1.0 Resolved closed
ESSENCE-163 Enhancements on attributes and card layout for checkpoints Essence 1.0b1 Essence 1.0 Deferred closed
ESSENCE-162 There are two errors in the listed Activity Space Completion Criteria Essence 1.0b1 Essence 1.0 Resolved closed
ESSENCE-161 Missing checklist item on key technical risks Essence 1.0b1 Essence 1.0 Resolved closed
ESSENCE-160 Enhancements on Competencies and Competency level definition Essence 1.0b1 Essence 1.0 Deferred closed
ESSENCE-159 Figure 132 – SPEM Taxonomy of Core Describable Elements is hard to read. Essence 1.0b1 Essence 1.0 Closed; No Change closed
ESSENCE-158 Subclause: A.3.2.3 System Element Essence 1.0b1 Essence 1.0 Resolved closed
ESSENCE-157 Subclause: 8.2.4.3 Testing Essence 1.0b1 Essence 1.0 Closed; No Change closed
ESSENCE-156 Subclause: 8.3.4.2 Development Essence 1.0b1 Essence 1.0 Closed; No Change closed
ESSENCE-155 Subclause: 8.1.4 Alphas: The Things to Work With Essence 1.0b1 Essence 1.0 Resolved closed
ESSENCE-154 Subclause 8.1.2 Essence 1.0b1 Essence 1.0 Resolved closed
ESSENCE-153 The definition of "Alpha" is confusing to me Essence 1.0b1 Essence 1.0 Resolved closed
ESSENCE-152 Subclause: 7.4.2 Essence 1.0b1 Essence 1.0 Closed; No Change closed
ESSENCE-151 There are no symbols defined in this specification Essence 1.0b1 Essence 1.0 Resolved closed
ESSENCE-150 Formal definition of Practice, Alpha and other terms Essence 1.0b1 Essence 1.0 Resolved closed
ESSENCE-149 In figure 9, what is the consequence of a stakeholder not being involved? Essence 1.0b1 Essence 1.0 Closed; No Change closed
ESSENCE-148 It is not clear what a customer area of concern is Essence 1.0b1 Essence 1.0 Resolved closed
ESSENCE-147 stakeholders in section 8.1.4 Essence 1.0b1 Essence 1.0 Resolved closed
ESSENCE-146 The XML namespace URI for xmi is incorrect Essence 1.0b1 Essence 1.0 Resolved closed
ESSENCE-191 Lifecycle Diagram for Multi-Phase Waterfall Requirements State Mislabeled Essence 1.0b1 Essence 1.0 Resolved closed
ESSENCE-189 Inconsistency of definitions for Bounded/Scoped requirements Alpha State. Essence 1.0b1 Essence 1.0 Resolved closed

Issues Descriptions

Semantics update

  • Status: closed  
  • Source: Ivar Jacobson International AB ( Stefan Bylund)
  • Summary:

    The semantics of "Action" only talks about work products but it can do the same things on alphas also I assume.

  • Reported: Essence 1.0 — Fri, 27 Mar 2015 15:00 GMT
  • Disposition: Resolved — Essence 1.2
  • Disposition Summary:

    Update the description of Action

    The description of Action needs to be changed from "An operation performed by an activity on a particular work product" to "An operation performed by an activity on a particular alpha or work product" because Action has Associations with both Alpha and Work Product.

  • Updated: Tue, 10 Jul 2018 14:20 GMT

Team and Team Member alpha refinement proposals

  • Status: closed  
  • Source: Ivar Jacobson International AB ( Stefan Bylund)
  • Summary:

    Refinement proposals as in the attached file, primarily related to state checklists.

  • Reported: Essence 1.0 — Mon, 1 Dec 2014 13:29 GMT
  • Disposition: Resolved — Essence 1.2
  • Disposition Summary:

    Refine Team and Team Member Alphas

    In the Team alpha, the last checklist item for the "Seeded" state should be changed from "Leadership model is selected" to "Leadership model is determined", because "selected" implies there is a finite predefined list to choose from. The description of "Formed" state should be changed to "The team has been populated with enough committed people to start to pursue the team mission". The last checklist item of the "Collaborating" state should be changed from "The team members know each other" to "The team members know and trust each other". The last checklist item of the "Performing" state should be changed from "Wasted work, and the potential for wasted work are continuously eliminated" to "Wasted work, and the potential for wasted work are continuously identified and eliminated". These changes all better clarify the semantics.

    The description of the (optional) Team Member alpha should be changed from "An individual acting as part of a team" to "An individual working as part of a team", because "working" relates better than "acting" with other related alphas such as Work and Way of Working. The last checklist item of "Contributing" state of this alpha should be changed to from "The Team member actively contributes to the well-being of the team" to "The Team member actively contributes to the team", because "well-being of the team" may not be the focus of contribution.

  • Updated: Tue, 10 Jul 2018 14:20 GMT
  • Attachments:

ActivitySpaceAndActivity::Language elements diagram lost

  • Key: ER-45
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Subclause 9.3.4.1 originally had an "ActivitySpaceAndActivity::Language elements" diagram (similar to language elements diagrams for other areas). However, this seems to have gotten lost in the preparation of the FTF Beta 2 document and it does not appear in the formal version of the specification.

  • Reported: Essence 1.0 — Thu, 28 May 2015 16:14 GMT
  • Disposition: Resolved — Essence 1.1
  • Disposition Summary:

    Restore the diagram

    Restore the ActivitySpaceAndActivity::Language elements diagram that was in the FTF Beta 1 document.

  • Updated: Fri, 2 Oct 2015 15:41 GMT
  • Attachments:

Correction to the resolution to Issue ER-2

  • Key: ER-43
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    The resolution to Issue ER-2 added a shortDescription attribute to the Checkpoint language element and updated the invariant for that element to "self.shortDescription <> null implies self.description <> null". However, the Checkpoint::description attribute is mandatory (multiplicity [1]), so it can never be null. This means that the new invariant is unnecessary.

    Also, the correct number for the new subclause is 9.7.5.8.2, not 9.7.4.7.5.

  • Reported: Essence 1.0 — Thu, 28 May 2015 16:08 GMT
  • Disposition: Resolved — Essence 1.1
  • Disposition Summary:

    Do not add invariant

    As proposed in the issue description, do not add the invariant proposed in the adopted resolution to Issue ER-2 and correct the subclause number.

  • Updated: Fri, 2 Oct 2015 15:41 GMT

None of the Activity Spaces seems to address the Requirements::Addressed Alpha State

  • Key: ER-13
  • Legacy Issue Number: 19641
  • Status: closed  
  • Source: Anonymous
  • Summary:

    None of the Activity Spaces seems to address the Requirements::Addressed Alpha State. All other Alpha States of the Kernel are addressed by Completion Criteria of Activity Spaces.

    If an Alpha States is not be addressed by any of the Alphas it would not be defined how to progress from its preceding Alpha state to itself.

    Having an Endeavour in a Method Enactment standing at Requirements::Acceptable the Kernel would not determine which next Activity (Space) to choose in order to progress the Alpha.

  • Reported: Essence 1.0 — Wed, 15 Oct 2014 04:00 GMT
  • Disposition: Duplicate or Merged — Essence 1.1
  • Disposition Summary:

    Merge with ER-11

    Resolving ER-11 results in an activity space with Requirements::addressed as a completion criterion, which also resolves this issue.

  • Updated: Fri, 2 Oct 2015 15:41 GMT

Wrong usage of Alpha Containment

  • Key: ER-8
  • Legacy Issue Number: 19509
  • Status: closed  
  • Source: Ivar Jacobson International AB ( Michael Striewe)
  • Summary:

    Point 3b) says “Bind transformed Work Product Definitions to Essence kernel Alphas […] by establishing Essence Alpha Containments […].”

    This is wrong. Instead, second part should be “[…] by establishing Essence Work Product Manifests […].”

  • Reported: Essence 1.0 — Fri, 4 Jul 2014 04:00 GMT
  • Disposition: Resolved — Essence 1.1
  • Disposition Summary:

    Change wording

    The correction is agreed to.

  • Updated: Fri, 2 Oct 2015 15:41 GMT

Error in recent change of definition of Practice

  • Key: ER-7
  • Legacy Issue Number: 19465
  • Status: closed  
  • Source: Ivar Jacobson International AB ( Paul McMahon)
  • Summary:

    There was an error made in a recent change to the definition of practice. Please return the definition to the original "A practice is a repeatable approach to doing something with a specific purpose in mind."

    The current definition states that a practice is a description...
    A practice is not a description. A practice does not need to be described to be a practice.

  • Reported: Essence 1.0 — Tue, 10 Jun 2014 04:00 GMT
  • Disposition: Resolved — Essence 1.1
  • Disposition Summary:

    Update glossary and language specification descriptions

    This resolution makes the description of the Practice language element give a primacy to the definition as given in Clause 4 on what a practice actually is, while still providing additional information on what is included in a Practice model element in the language.

  • Updated: Fri, 2 Oct 2015 15:41 GMT

Request to change phrase "completion criteria" to "prmary goals"

  • Key: ER-5
  • Legacy Issue Number: 19244
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Request a change be made to the phrase "completion criteria" under Kernel Activity Spaces, to "primary goals".

    Rationale: Phrase "Completion criteria" is leading people to the wrong understanding, such as the wrong belief that activities will end when "completion criteria" met.

    "primary goals" is a more accurate phrase for the intent.

  • Reported: Essence 1.0b1 — Tue, 18 Feb 2014 05:00 GMT
  • Disposition: Closed; No Change — Essence 1.1
  • Disposition Summary:

    Closed, no change

    Changing the phrase "completion criteria" to "primary goals" would not be consistent with the language specification, which specifically indicates that both activities and activity spaces have criteria, of which completion criteria are one kind. Changing this, especially if just for activity spaces, would be a significant update to the language that does not seem to be justified by the rationale given in this issue. The fact that activities can span multiple activity spaces is clear from the language metamodel, in that one Activity can have ActivityAssociations with multiple ActivitySpaces. This should be made clear in tutorial presentations on Essence, but an update to the specification is not necessary.

  • Updated: Fri, 2 Oct 2015 15:41 GMT

Change Requested to Activity Space Symbol

  • Key: ER-4
  • Legacy Issue Number: 19243
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Request a change to the symbol used for Activity Spaces from the current rectangle with a "pointie head" to a basic rectangle with NO pointie head similar to the Areas of Concern symbol.

    Rationale: The symbol is causing confusion to people leading them to think this is an activity rather than a generic container for activities and leading them to believe their is an implied sequential order which is not the case.

  • Reported: Essence 1.0b1 — Tue, 18 Feb 2014 05:00 GMT
  • Disposition: Closed; No Change — Essence 1.1
  • Disposition Summary:

    Not worth the change

    It was decided that making such a change was not worth the benefit.

  • Updated: Fri, 2 Oct 2015 15:41 GMT

Introduction of level of detail cards

  • Key: ER-3
  • Legacy Issue Number: 18978
  • Status: closed  
  • Source: Ivar Jacobson International AB ( Michael Striewe)
  • Summary:

    Problem to be solved:

    The spec supports state cards but not level of detail cards.

    Proposed solution:

    Add new section “9.7.5.8.2 Level of Detail Card” similar to section “9.7.4.7.5 Alpha State Detail Card”.

  • Reported: Essence 1.0b1 — Wed, 25 Sep 2013 04:00 GMT
  • Disposition: Resolved — Essence 1.1
  • Disposition Summary:

    Add new subclause

    Add a new subclause describing level of detail cards.

  • Updated: Fri, 2 Oct 2015 15:41 GMT
  • Attachments:

Enhancements on attributes and card layout for checkpoints

  • Key: ER-2
  • Legacy Issue Number: 18976
  • Status: closed  
  • Source: Ivar Jacobson International AB ( Michael Striewe)
  • Summary:

    Problem to be solved:

    The cards may not have enough space to display the full descriptions of all checkpoint in all cases. The language only defines one property “description” for checkpoints and does not support abbreviated descriptions. On the other hand, it declares attribute “name” which is not used on the cards or anywhere else.

    Proposed solution:

    The attribute “name” in language element “Checkpoint” is renamed to “shortDescription” for an optional abbreviated version of the full description. An OCL constraint is added to ensure that "shortDescription" is not empty only if “description” is not empty.
    The definition of a card body (page 119) is extended by: “If provided, the abbreviated description of a checkpoint is used as a default.”

  • Reported: Essence 1.0b1 — Wed, 25 Sep 2013 04:00 GMT
  • Disposition: Resolved — Essence 1.1
  • Disposition Summary:

    Add short description

    It is agreed that this would make the normative cards be the most useful. However, for backwards compatibility, it would be best to keep the name attribute and just add shortDescription.

  • Updated: Fri, 2 Oct 2015 15:41 GMT

Enhancements on Competencies and Competency level definition

  • Key: ER-1
  • Legacy Issue Number: 18870
  • Status: closed  
  • Source: Ivar Jacobson International AB ( Michael Striewe)
  • Summary:

    Problem to be solved: The definition of five generic competency levels in section 8.1.6 (pages 16 to 19) is not supported in that detail by the definition of the language elements in section 9.3.5 (pages 86 to 88). Mismatches are in particular:
    - Section 8.1.6 states “Each competency has five levels of achievement. These are standard across all the kernel competencies […]”, while section 9.3.5.2 allows zero to many levels and does not enforce any standard instantiations.

    • Table 1 in section 8.1.6 summarizes the proposed competency levels in checklist style, while section 9.3.5.3 does only allow free text properties for that purpose.

    Proposed solution: It is proposed to enhance section 9.3.5 as follows:

    • Change section 8.1.6 to say “across all competencies”
    • Add a clarifying note in section 9.3.5 that each tool claiming conformance to the standard must implement the kernel and therefore has to provide the standard instantiations for competencies as defined in table 1 in section 8.1.6. To enforce this partially via the language directly, change multiplicity on association “possibleLevel” in section 9.3.5.2 from * to 5.
    • Add an association “checkListItem [*]” in section 9.3.5.3 that targets model element “Checkpoint”. For architectural clearness, move this element from package “AlphaAndWorkProduct” to “Foundation”.
  • Reported: Essence 1.0b1 — Tue, 13 Aug 2013 04:00 GMT
  • Disposition: Closed; No Change — Essence 1.1
  • Disposition Summary:

    Close no change.

    This has already partially been resolved. In particular, section 9.3.5.3 is already updated as suggested. The RTF does not feel that the suggestion to change the multiplicity definition in section 9.3.5.2 is a good idea. The other suggestions are just minor additions that might be a service to the reader, but not particularly important.

  • Updated: Fri, 2 Oct 2015 15:41 GMT

Completion criteria typo

  • Key: ER-11
  • Status: closed  
  • Source: Ivar Jacobson International AB ( Stefan Bylund)
  • Summary:

    "Requirements::Acceptable" should be "Requirements::Addressed"

  • Reported: Essence 1.0 — Sat, 3 May 2014 07:51 GMT
  • Disposition: Duplicate or Merged — Essence 1.1
  • Disposition Summary:

    Merged

    The resolution to ER-21 removes the listing of intermediate states (such as the one referenced in the issue) in the completion criteria of kernel activity spaces. The issue is effectively handle in the resolution to ER-21 by including "Requirements::Acceptable" (rather than Requirements::Coherent) as an entry criterion of the Test the System activity space, such that the first state to which Requirements may be progressed by activities in the activity space is Requirements::Addressed (the successor to Requirements::Acceptable).

  • Updated: Fri, 2 Oct 2015 15:41 GMT

Issue on Essence 1.0 metamodel

  • Key: ER-12
  • Legacy Issue Number: 19294
  • Status: closed  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    The Essence metamodel contains Dependencies which are not valid in MOF metamodels as per the constraints in the MOF spec.

  • Reported: Essence 1.0b1 — Mon, 24 Mar 2014 04:00 GMT
  • Disposition: Resolved — Essence 1.1
  • Disposition Summary:

    Change dependencies to package imports

    In subclause 7.3.1, it says "The dependency between the packages [depicted in Figure 9.3] is expressed with import relationships." However, the relationships shown in Figure 9.3 are actually captured in the abstract syntax model as Dependencies, rather than as PackageImports.

  • Updated: Fri, 2 Oct 2015 15:41 GMT
  • Attachments:

Semantics update

  • Key: ER-37
  • Status: closed  
  • Source: Ivar Jacobson International AB ( Stefan Bylund)
  • Summary:

    The semantics of "Action" only talks about work products but it can do the same things on alphas also I assume.

  • Reported: Essence 1.0 — Fri, 27 Mar 2015 15:00 GMT
  • Disposition: Deferred — Essence 1.1
  • Disposition Summary:

    Defer

    This issue was received too late for consideration for Essence 1.1, but the RTF feels it should be considered for Essence 1.2.

  • Updated: Fri, 2 Oct 2015 15:41 GMT

Team and Team Member alpha refinement proposals

  • Key: ER-36
  • Status: closed  
  • Source: Ivar Jacobson International AB ( Stefan Bylund)
  • Summary:

    Refinement proposals as in the attached file, primarily related to state checklists.

  • Reported: Essence 1.0 — Mon, 1 Dec 2014 13:29 GMT
  • Disposition: Deferred — Essence 1.1
  • Disposition Summary:

    Defer

    This issue was received too late for consideration for Essence 1.1, but the RTF feels it should be considered for Essence 1.2.

  • Updated: Fri, 2 Oct 2015 15:41 GMT
  • Attachments:

SEMANTIC DISCIPLINE ISSUE

  • Key: ER-15
  • Legacy Issue Number: 19699
  • Status: closed  
  • Source: Independent Consultant ( Don O'Neill)
  • Summary:

    SEMANTIC DISCIPLINE ISSUE
    1.The three concerns of Customer, Solution, and Endeavor are permitted to progress independently.
    2. Page 4 Areas of Concern, "Elements in kernels or practices may be divided into a collection of main areas of concern that a software engineering endeavor has to pay special attention to. All elements fall into at most one of these."
    3. However, the OMG Essence Standard employs "Solution", one of three concerns, in the Customer concern Opportunity alpha "Solution Needed" state.
    4. The result is the use of the word "Solution" in both the name of a concern and in the separate concern of Opportunity as an alpha state "Solution Needed."

    ACTION: Since software is known to be the domain of consideration in Opportunity, the "Solution Needed" state in the alpha Opportunity should be be relabeled "Software Needed", thereby eliminating this semantic intrusion of concern terminology into alpha state of a different concern. Suggest that the revised OMG Essence standard adopt this change.

  • Reported: Essence 1.0b1 — Mon, 29 Dec 2014 05:00 GMT
  • Disposition: Closed; No Change — Essence 1.1
  • Disposition Summary:

    Close, no change

    Currently, the specificity of the Essence kernel to "software" is captured almost entirely within the Solution domain – or, more accurately, the specificity is to "software system", which may also include the hardware the supports the software. The alphas in the Customer and Endeavor areas of concern can and should largely apply to cases where the solution may not be a software system. While the current standard kernel focus on software-system solutions, the intent is that it be customizable for use with other solution areas – and, in fact, some groups have actually done this.

    Further, from a Customer point of view it makes more sense to talk about whether a solution is needed than whether that solution is specifically a "software system" or even a "system". The focus should be on the value of the solution needed, not on what the solution "is". It was with this in mind that the term "solution" was specifically used in the name of the state "Solution Needed" when Essence was developed.

  • Updated: Fri, 2 Oct 2015 15:41 GMT

PRINCIPLE OF ALPHA STATE INDEPENDENCE

  • Key: ER-14
  • Legacy Issue Number: 19698
  • Status: closed  
  • Source: Independent Consultant ( Don O'Neill)
  • Summary:

    PRINCIPLE OF ALPHA STATE INDEPENDENCE
    The Essence Kernel framework is featured as independent of all methods and practices.

    Dependent relationships among Essence Kernel alphas are established and determined by the choice of methods and practices their users import, that is, methods and practices supply the integrating glue that binds alphas.

    Consequently, the checklist conditions for achieving an alpha state must be intrinsically associated with the alpha of which they are apart and should not explicitly import or repeat checklist conditions from other alphas.

    A careful and critical review of the OMG Essence standard reveals that while these principles and rules of construction are fait fully adhered to in the Stakeholder, Software System, Team, Work, and Way of Working alphas, they are violated in the Opportunity and Requirements alphas where checklist conditions from each are explicitly restated as well as the Software System alpha.

    It appears that the authors may be tilting towards the Agile Development Method and permitting the Agile way of thinking on the Opportunity and the Requirements to bleed through despite the method and practice promise and intention of Essence.

    Specifically:

    1.Stakeholders- OK

    2. Opportunity
    Issue 1: The Identified state imports checklist conditions from the Stakeholder alpha, that is, Recognized and Represented.
    Issue 2: The Solution Needed state imports checklist conditions from the Stakeholder alpha, that is, Recognized and Represented.
    Issue 3: The Solution Needed state imports checklist conditions from the Requirements alpha, that is, Acceptable and Addressed.
    Issue 4: The Addressed state imports a checklist condition from the Software System alpha, that is, Usable.

    3. Requirements
    Issue 1: The Conceived state imports checklist conditions from the Stakeholder alpha, that is, Recognized, Represented, and Involved.
    Issue 2: The Conceived state imports a checklist condition from the Opportunity alpha, that is, Identified.
    Issue 3: The Bounded state imports checklist conditions from the Stakeholder alpha, that is, Recognized, Represented, Involved, and In Agreement.
    Issue 4: The Coherent state imports checklist conditions from the Stakeholder alpha, that is, Recognized, Represented, Involved, and In Agreement.
    Issue 5: The Accepted state imports a checklist condition from the Stakeholder alpha, that is, In Agreement.
    Issue 6: The Addressed state imports checklist conditions from the Stakeholder alpha, that is, In Agreement and Satisfied for Deployment.
    Issue 7: The Fulfilled state imports a checklist condition, that is, Satisfied In Use.

    4. Software System- OK

    5. Team- OK

    6. Work- OK

    7. Way of Working- OK

  • Reported: Essence 1.0b1 — Mon, 29 Dec 2014 05:00 GMT
  • Disposition: Closed; No Change — Essence 1.1
  • Disposition Summary:

    Close, no change.

    The references from certain alpha checklist items to other alphas is intentional and not unreasonable, since there are associations between alphas, as reflected in kernel specification. However, this does not imply explicit dependencies between the alpha states – checklist items in one alpha do not actually refer explicitly to specific states in other alphas, but just general conditions that need to be checked. It should also be noted that kernel activity spaces are likely to advance alphas in the same area of concern together, indicating that alphas may move forward in "waves". Further formalization of this wave might allow the alpha checklists to be made more independent, but this is a topic that will require future research, and it would not be appropriate to change the specification in this regard at this time.

  • Updated: Fri, 2 Oct 2015 15:41 GMT

Completion criteria with multiple states from the same alpha

  • Key: ER-21
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    There are many cases in the kernel in which the completion criteria for an activity space include multiple states for the same alpha. But, from the definition of "completion criterion” in the language, it is unclear what it means to have to complete multiple states for the same alpha. It seems redundant, since when you achieve a later state, it is assumed that all earlier states have already been met.

  • Reported: Essence 1.0 — Fri, 23 Jan 2015 20:52 GMT
  • Disposition: Resolved — Essence 1.1
  • Disposition Summary:

    Add entry criteria and update completion criteria

    The states currently listed as "completion criteria" a kernel activity space are those states to which various alphas may be progressed by activities considered to be within the activity space. This is useful information, but it is confusing to refer to them all as "completion criteria", since some are really intermediate states of an alpha that must be progressed further before the activity space can truly be considered "complete".

    For alphas that are expected to be progressed from some starting state to some final state by activities within an activity space, it would seem more correct to list the starting state of the alpha as an entry criterion for the activity space and the final state as a completion criterion. The problem with this is that the current language definition of entry criteria for an activity or an activity space seems to indicate that all the entry criteria must be fulfilled before the activity or activity space can start (logical "and" of the criteria). But this is not what is desired for an activity space, because an activity within an activity space will be able to start progressing alphas within the context of that activity space as long as the entry criteria for that activity are fulfilled, even if alphas unrelated to the activity have not reached the entry criterion state required for the activity space.

    Therefore, the proposal for resolution of this issue is as follows:

    1. Update the language definition of EntryCriterion to make it clear that work of an activity space can start when "one or more of its entry criteria are fulfilled" (logical "or" of entry criteria).

    2. Update the kernel specifications for activity spaces to only list the final state of each alpha in the completion criteria (do not list intermediate states).

    3. Update the kernel specifications for activity spaces to add entry criteria listing the required initial states of relevant alphas (these will be a subset of the input alphas for the activity space).

  • Updated: Fri, 2 Oct 2015 15:41 GMT

UNDERSTANDABILITY ISSUE

  • Key: ER-16
  • Legacy Issue Number: 19700
  • Status: closed  
  • Source: Independent Consultant ( Don O'Neill)
  • Summary:

    UNDERSTANDABILITY ISSUE
    1. In Team alpha, the state label "Seeded" is not understandable. Perhaps "Seeded" is a language translation anomaly.
    2. The dictionary definition states, "given the status of seed in a sports tournament." Googling "Team Seeded" results in sports returns reflecting such a definition.
    3. "Selected" is understandable and the logical predecessor state for the successor state "Formed".

    ACTION: Suggest that the revised OMG Essence standard adopt the change of replacing "Seeded" with "Selected" as the initial state in the Team alpha.

  • Reported: Essence 1.0b1 — Mon, 29 Dec 2014 05:00 GMT
  • Disposition: Closed; No Change — Essence 1.1
  • Disposition Summary:

    Closed, no change

    The Team alpha's Seeded state is defined as: “The team’s mission is clear and the know-how needed to grow the team is in place."

    Merriam-Webster’s dictionary (the dictionary chosen by the team that developed Essence) defines "seed" as “the grains.. used for sowing” and refers to “capable...of germination...to produce a new plant”. It is this meaning of the word "seeded" that is meant in the choice of the state name because, in the Seeded state, the team knows how to grow, but there actually may not yet be team members selected. That starts to happen in the formed state.

    The term “selected” for this state would give an inaccurate meaning to the state, since team members have not necessarily been selected at this point.

  • Updated: Fri, 2 Oct 2015 15:41 GMT

Error in definition of Activity

  • Key: ER-6
  • Legacy Issue Number: 19464
  • Status: closed  
  • Source: Ivar Jacobson International AB ( Paul McMahon)
  • Summary:

    There was an error made in a recent change to the definition of Activity. Please return the definition to the original, "An activity defines one or more kinds of work items and gives guidance on how to perform these"

    The current definition refers to work products which is wrong because an activity does not require a work product.

  • Reported: Essence 1.0 — Tue, 10 Jun 2014 04:00 GMT
  • Disposition: Resolved — Essence 1.1
  • Disposition Summary:

    Update glossary and language specification descriptions

    The changes given in this resolution make, the descriptions in the language consistent with the definition in Clause 4, without using the term “work item”, which is not actually defined in the language.

  • Updated: Fri, 2 Oct 2015 15:41 GMT

New Section on Competency Detail Level Card

  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    The resolution to ESSENCE-166, adopted in Ballot 3 did not include the following part of the proposed solution given by the issue submitters:

    Add new section “9.7.6.8.4 Competency Level Detail Card” similar to section “9.7.4.7.5 Alpha State Detail Card”.

  • Reported: Essence 1.0b1 — Wed, 5 Mar 2014 04:44 GMT
  • Disposition: Resolved — Essence 1.0
  • Disposition Summary:

    Add subclause 9.7.7.8.4 as requested.

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

Wrong reference in OCL expression on LanguageElement

  • Legacy Issue Number: 19259
  • Status: closed  
  • Source: Ivar Jacobson International AB ( Michael Striewe)
  • Summary:

    Problem to be solved: The OCL invariant on LanguageElement uses incorrect references to "owningAssociation" towards its end. This is incorrect, because owningAssociation will never point to e1 or e2, which are LanguageElements.

    Moreover, it uses reference "a.member", which is undefined.

    Proposed solution: Replace "p1.owningAssociation" by "p1.languageElement" and "p2.owningAssociation" by "p2.languageElement".

    In addition, replace "a.member" by "a.memberEnd".

  • Reported: Essence 1.0b1 — Tue, 25 Feb 2014 05:00 GMT
  • Disposition: Resolved — Essence 1.0
  • Disposition Summary:

    Agreed.

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

Wrong reference in OCL expression on kernel

  • Legacy Issue Number: 19258
  • Status: closed  
  • Source: Ivar Jacobson International AB ( Michael Striewe)
  • Summary:

    Problem to be solved: The first OCL expression on kernel starts with "self.elements" which is undefined on kernel.

    Proposed solution: Replace "self.elements" by "self.referredElements->union(self.ownedElements)".

  • Reported: Essence 1.0b1 — Tue, 25 Feb 2014 05:00 GMT
  • Disposition: Resolved — Essence 1.0
  • Disposition Summary:

    Agreed.

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

In element Action, change attribute kind from type String to Enumeration

  • Legacy Issue Number: 19257
  • Status: closed  
  • Source: 88solutions ( Manfred Koethe)
  • Summary:

    Element Action in package ActivitySpaceAndActivity is specified to perform "create, read, update, delete". Therefore attribute "kind" should be of type Enumeration instead of type String.

    Proposed Solution:
    in ActivitySpaceAndActivity::Action,
    change the type of attribute "kind" to ActionKind.

    Define a new Enumeration ActionKind with enumeration literals "create, read, update, delete".

  • Reported: Essence 1.0b1 — Sat, 22 Feb 2014 05:00 GMT
  • Disposition: Resolved — Essence 1.0
  • Disposition Summary:

    Agreed, accept the proposed change. The transition from a String to an Enumeration improves the precision and expressiveness of the model.

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

Diagram Interchange Metamodel missing in Essence Metamodel

  • Legacy Issue Number: 19256
  • Status: closed  
  • Source: 88solutions ( Manfred Koethe)
  • Summary:

    In clause 9.7.2 on page 112, Figure 36 shows the Graphical Syntax, or Diagram Interchange Metamodel, residing in Package DiagramInterchange. This package and its content is missing from the metamodel in the XMI file (as well as from the ancillary MagicDraw model).

    Proposed Solution:
    Add Package DiagramInterchange and its content as shown in Figure 36 to the model.

  • Reported: Essence 1.0b1 — Sat, 22 Feb 2014 05:00 GMT
  • Disposition: Resolved — Essence 1.0
  • Disposition Summary:

    Update the model with elements shown in Figure 36 and replace Figure 36 with a version (from the model) that has the UML errors corrected.

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

Request to change phrase "completion criteria" to "prmary goals"

  • Legacy Issue Number: 19244
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Request a change be made to the phrase "completion criteria" under Kernel Activity Spaces, to "primary goals".

    Rationale: Phrase "Completion criteria" is leading people to the wrong understanding, such as the wrong belief that activities will end when "completion criteria" met.

    "primary goals" is a more accurate phrase for the intent.

  • Reported: Essence 1.0b1 — Tue, 18 Feb 2014 05:00 GMT
  • Disposition: Deferred — Essence 1.0
  • Disposition Summary:
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Change Requested to Activity Space Symbol

  • Legacy Issue Number: 19243
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Request a change to the symbol used for Activity Spaces from the current rectangle with a "pointie head" to a basic rectangle with NO pointie head similar to the Areas of Concern symbol.

    Rationale: The symbol is causing confusion to people leading them to think this is an activity rather than a generic container for activities and leading them to believe their is an implied sequential order which is not the case.

  • Reported: Essence 1.0b1 — Tue, 18 Feb 2014 05:00 GMT
  • Disposition: Deferred — Essence 1.0
  • Disposition Summary:
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wrong reference in OCL expression on practices

  • Legacy Issue Number: 19240
  • Status: closed  
  • Source: Ivar Jacobson International AB ( Michael Striewe)
  • Summary:

    Problem to be solved: The fourth OCL expression on practices makes two illegal references to "cc.workProduct". In addition, there is a typo in a reference to "self.allEments".

    Proposed solution: Replace both occurences of "cc.workProduct" by "cc.levelOfDetail" and correct the typo by writing "self.allElements".

  • Reported: Essence 1.0b1 — Thu, 13 Feb 2014 05:00 GMT
  • Disposition: Resolved — Essence 1.0
  • Disposition Summary:

    Agreed.

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

Attribute “approach” on Activities should be promoted to a first class citizen

  • Legacy Issue Number: 19116
  • Status: closed  
  • Source: Ivar Jacobson International AB ( Michael Striewe)
  • Summary:

    Problem to be solved:

    It is currently not possible to attach resources, patterns or anything else to approaches or refer to approaches in patterns, as they are a plain string attribute of Activities instead of being a language element.

    This makes it difficult to complement an approach with step-by-step instructions, scripts, tool mentors, examples or any other forms of guidance.

    Proposed solution:

    Replace attribute “approach” on langage element “Activity” by a new language element “Approach” (direct subclass of “LanguageElement”) with attribute “name” of type String. Add an association from “Activity” to “Approach” with multiplicity 1..* at the “Approach” end.

  • Reported: Essence 1.0b1 — Wed, 20 Nov 2013 05:00 GMT
  • Disposition: Resolved — Essence 1.0
  • Disposition Summary:

    Agreed. Accept the proposed resolution.

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

Name of Requirements Alpha state between Conceived and Coherent

  • Legacy Issue Number: 19097
  • Status: closed  
  • Source: omg.org ( OMG System User)
  • Summary:

    There is definitely a useful state between conceived and coherent. Some people think bounded is too waterfall but accept the need for a state between Conceived and Coherent. We offer the following list for their consideration as possible, but not necessarily better, alternatives to “bounded”.
    The candidate list of potential alternatives is (in no particular order):
    Understood, Clarified, Themed, Scoped, Profiled, Envisioned
    None of the new proposals are considered obviously superior to “bounded”

  • Reported: Essence 1.0b1 — Tue, 19 Nov 2013 05:00 GMT
  • Disposition: Closed; No Change — Essence 1.0
  • Disposition Summary:

    It has not been possible to reach a consensus on an alternative name. So the name will remain "Bounded".

  • Updated: Fri, 6 Mar 2015 20:58 GMT
  • Attachments:

Acknowledgment missing

  • Legacy Issue Number: 19091
  • Status: closed  
  • Source: omg.org ( OMG System User)
  • Summary:

    Problem to be solved:
    Acknowledgement missing in page 192 section B.1.1

    Proposed solution:
    Complete the following paragraph:
    Hanna J. Oktaba and Miguel Ehécatl Morales Trujillo lead the work on the KUALI-BEH Kernel extension, which was based on the KUALI-BEH 1.1 revised submission guided by Hanna J. Oktaba

    Adding:
    ... and Miguel Ehécatl Morales Trujillo, and on the KUALI-BEH 1.0 initial submission with participation of Magdalena Dávila Muñoz.

  • Reported: Essence 1.0b1 — Fri, 15 Nov 2013 05:00 GMT
  • Disposition: Resolved — Essence 1.0
  • Disposition Summary:

    Agreed.

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

Coherency vs. Coherence usage

  • Legacy Issue Number: 19090
  • Status: closed  
  • Source: omg.org ( OMG System User)
  • Summary:

    Problem to be solved:
    Both words are correct, however the word "coherency" is more common and more used in the specification.

    Proposed solution:
    Replace word "coherence" by "coherency" in:

    • page 204 Table 48, third row, first bullet
    • page 206 Table 49, second row, third column, first paragraph
    • page 220 subsection How Method Enactment drives the Work, fourth paragraph
  • Reported: Essence 1.0b1 — Fri, 15 Nov 2013 05:00 GMT
  • Disposition: Resolved — Essence 1.0
  • Disposition Summary:

    (Note: The page numbers in the issue description are the sequential page numbers from the cover page of the document, not the page numbers as given in the page footers.)

    It is not agreed that "coherency" is more common than "coherence". Indeed, online dictionary definitions seem to consistently define "coherency" as meaning "coherence", indicating that "coherence" is the primary term.

    However, the document current uses both "coherence" and "coherency". For consistency, only one should be used, and that should be the primary term "coherence", not "coherency".

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

Substitute Method's property name Completeness by Sufficiency

  • Legacy Issue Number: 19089
  • Status: closed  
  • Source: omg.org ( OMG System User)
  • Summary:

    Problem to be solved:
    The word "completeness" has a very specific meaning in mathematics and formal languages and needs a formal demonstration, while the word "sufficiency" is enough to describe this particular method property.

    Proposed solution:
    Replace word "completeness" by "sufficiency" in:

    • page 83 section 9.3.2.11 (twice)
    • page 200 section B.1.2.3 (twice) in: Description and States subsections
    • page 201 Figure 113
    • page 202 section B.1.2.3 Progressing the Method Authoring
    • page 203 section B.1.2.3 (thrice) Progressing the Method Authoring
    • page 203 Figure 116
    • page 204 Table 48, third row, first bullet
    • page 206 Table 49, second row, second column, first paragraph
    • page 206 Table 49, second row, third column, first paragraph
    • page 206 Progressing the Method Enactment
    • page 220 subsection How Method Enactment drives the Work, fourth paragraph
  • Reported: Essence 1.0b1 — Fri, 15 Nov 2013 05:00 GMT
  • Disposition: Closed; No Change — Essence 1.0
  • Disposition Summary:

    A lot of words have specific meanings in "mathematics and formal language", but they also have clear meanings in less formal language. Further, in the context of the use in question, "sufficiency" does not have the same connotation as "completeness" for the usual reader. The definition of the "completeness" property currently is that a method "is complete if the achievement of all practice objectives fulfills entirely the method purpose and produces expected output". The alternative of saying that a method is "sufficient" does not seem to capture nearly as well as "complete" the idea of "fulfilling entirely the method purpose".

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

Practices has objectives not purposes

  • Legacy Issue Number: 19088
  • Status: closed  
  • Source: omg.org ( OMG System User)
  • Summary:

    Problem to be solved:
    The definition of a practice establishes that it has a purpose.
    According to the Practice definition, it has an objective, not a purpose. The method is the one that has a purpose.

    Proposed solution:
    Replace the word "purpose" by "objective" in pages 20 (section 4) and 24 (section 7.3).

  • Reported: Essence 1.0b1 — Fri, 15 Nov 2013 05:00 GMT
  • Disposition: Resolved — Essence 1.0
  • Disposition Summary:

    Agreed.

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

Missing reference for a subclause in Method definition

  • Legacy Issue Number: 19087
  • Status: closed  
  • Source: omg.org ( OMG System User)
  • Summary:

    Problem to be solved:
    The subclause reference of the Method definition is missing.

    Proposed solution:
    Since other terms have a reference to their respective subclauses, (See subclause 9.3.2.11.) should be added.

  • Reported: Essence 1.0b1 — Fri, 15 Nov 2013 05:00 GMT
  • Disposition: Resolved — Essence 1.0
  • Disposition Summary:

    Agreed.

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

Consistency of definitions in the specification

  • Legacy Issue Number: 19086
  • Status: closed  
  • Source: omg.org ( OMG System User)
  • Summary:

    Problem to be solved:
    The terms and definitions, presented in section 4, must be consistent with the ones used in the specification, particularly:

    • Activity
    • Competency
    • Method
    • Practice

    Proposed solution:
    Replace the definitions of those terms in section 4 by the definitions presented respectively in:
    9.3.4.4 Activity
    9.3.5.2 Competency
    9.3.2.11 Method
    9.3.2.14 Practice

  • Reported: Essence 1.0b1 — Fri, 15 Nov 2013 05:00 GMT
  • Disposition: Resolved — Essence 1.0
  • Disposition Summary:

    Replace the first sentence of each of the four definitions in clause 4, with the first sentence of the corresponding description subclause in clause 9 for that term.

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

Alpha: Essential Qualities

  • Legacy Issue Number: 19082
  • Status: closed  
  • Source: Ivar Jacobson International AB ( Michael Striewe)
  • Summary:

    Problem to be solved: The Alpha class does not capture the essential qualities of an Alpha in a particular attribute. Thus section 9.7.4.7.3 should stop referring to, and displaying, essential qualities as though they were a referencable property of an Alpha. For example, they are shown on the sample Alpha card, Figure 53 in Section 9.7.4.7.3 Alpha Definition Card on page 118.

    Proposed solution: The offending references are removed and the card shown is replaced by one that is conformant with the language.

  • Reported: Essence 1.0b1 — Wed, 13 Nov 2013 05:00 GMT
  • Disposition: Resolved — Essence 1.0
  • Disposition Summary:

    The proposed solution is agreed to.

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

CRUD on Activities

  • Legacy Issue Number: 19030
  • Status: closed  
  • Source: Ivar Jacobson International AB ( Michael Striewe)
  • Summary:

    Problem to be solved: The spec allows Activities to perform four operations (create, read, update, delete) on a Work Product or an Alpha. The card just names input and output, which is less specific. Activity Spaces just allow input, which seems very limited. In general, the language spec seems unbalanced with respect to this aspect.

    Proposed solution:

    • Remove association “input” from language element “ActivitySpace”.
    • Remove language element “Action” and all its associations.
    • Add associations “input” and “output” from language element “AbstractActivity” to “Alpha”.
    • Add associations “input” and “output” from language element “Activity” to “WorkProduct”.
  • Reported: Essence 1.0b1 — Fri, 25 Oct 2013 04:00 GMT
  • Disposition: Closed; No Change — Essence 1.0
  • Disposition Summary:

    ActivitySpace is not in the position to create Alphas, it is merely importing them, acting like a containment, not a factory. Activities, on the other hand, are capable to influence the lifecycle of Alphas. Rearranging the Associations would distort this distinction. Also, the suggested removal of Action would remove the ability to specify the intended action on Aplhas and WorkProducts. The model as it stands is correct and shall not be changed.

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

Entry Criteria on Abstract Activities

  • Legacy Issue Number: 19029
  • Status: closed  
  • Source: Ivar Jacobson International AB ( Michael Striewe)
  • Summary:

    Problem to be solved: It can be considered useful in practice to have not only completion criteria for activities, but also entry criteria. While the spec supports the former, it does not support the latter.

    Proposed solution: Add optional entry criteria. Language element “CompletionCriterion” can be renamed to “Criterion” and be reused for that purpose. Possibly card updates in section 9.7.6.8 (pages 132-133) are necessary to make clear how entry criteria are shown on the cards.

  • Reported: Essence 1.0b1 — Fri, 25 Oct 2013 04:00 GMT
  • Disposition: Resolved — Essence 1.0
  • Disposition Summary:

    The issue author raises a valid point. Change the preexisting CompletionCriterion into an abstract and neutral Criterion, which then can be specialized into an EntryCriterion and CompletionCriterion.

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

Enhancements on competency levels and cards

  • Legacy Issue Number: 18979
  • Status: closed  
  • Source: Ivar Jacobson International AB ( Michael Striewe)
  • Summary:

    Problem to be solved:

    The spec does not allow for checklists on a competency level or the creation of a competency level detail card.

    Proposed solution:

    Add an association “checkListItem” of type “Checkpoint [*]” to language element “Competency level”. For architectural clearness, move language element “Checkpoint” from package “AlphaAndWorkProduct” to package “Foundation”.
    Add new section “9.7.6.8.4 Competency Level Detail Card” similar to section “9.7.4.7.5 Alpha State Detail Card”.

  • Reported: Essence 1.0b1 — Wed, 25 Sep 2013 04:00 GMT
  • Disposition: Resolved — Essence 1.0
  • Disposition Summary:

    Agreed. Accept proposal.

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

Introduction of level of detail cards

  • Legacy Issue Number: 18978
  • Status: closed  
  • Source: Ivar Jacobson International AB ( Michael Striewe)
  • Summary:

    Problem to be solved:

    The spec supports state cards but not level of detail cards.

    Proposed solution:

    Add new section “9.7.5.8.2 Level of Detail Card” similar to section “9.7.4.7.5 Alpha State Detail Card”.

  • Reported: Essence 1.0b1 — Wed, 25 Sep 2013 04:00 GMT
  • Disposition: Deferred — Essence 1.0
  • Disposition Summary:
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Level of detail diagram is counter intuitive

  • Legacy Issue Number: 18977
  • Status: closed  
  • Source: Ivar Jacobson International AB ( Michael Striewe)
  • Summary:

    Problem to be solved:

    The visualization is counter intuitive as the shape seems to point from bottom to top while the arrows run from top to bottom.

    Proposed solution:

    Invert the shape

  • Reported: Essence 1.0b1 — Wed, 25 Sep 2013 04:00 GMT
  • Disposition: Resolved — Essence 1.0
  • Disposition Summary:

    Agreed.

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

Enhancements on attributes and card layout for checkpoints

  • Legacy Issue Number: 18976
  • Status: closed  
  • Source: Ivar Jacobson International AB ( Michael Striewe)
  • Summary:

    Problem to be solved:

    The cards may not have enough space to display the full descriptions of all checkpoint in all cases. The language only defines one property “description” for checkpoints and does not support abbreviated descriptions. On the other hand, it declares attribute “name” which is not used on the cards or anywhere else.

    Proposed solution:

    The attribute “name” in language element “Checkpoint” is renamed to “shortDescription” for an optional abbreviated version of the full description. An OCL constraint is added to ensure that "shortDescription" is not empty only if “description” is not empty.
    The definition of a card body (page 119) is extended by: “If provided, the abbreviated description of a checkpoint is used as a default.”

  • Reported: Essence 1.0b1 — Wed, 25 Sep 2013 04:00 GMT
  • Disposition: Deferred — Essence 1.0
  • Disposition Summary:
  • Updated: Fri, 6 Mar 2015 20:58 GMT

There are two errors in the listed Activity Space Completion Criteria

  • Legacy Issue Number: 18975
  • Status: closed  
  • Source: Ivar Jacobson International AB ( Paul McMahon)
  • Summary:

    Problem to be solved: In both places the Completion Criteria: Requirements: Sufficient is wrong

    Proposed solution: In both referenced cases change Completion Criteria: Requirements Sufficient to Requirements: Acceptable

  • Reported: Essence 1.0b1 — Tue, 24 Sep 2013 04:00 GMT
  • Disposition: Resolved — Essence 1.0
  • Disposition Summary:

    Agreed.

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

Missing checklist item on key technical risks

  • Legacy Issue Number: 18974
  • Status: closed  
  • Source: Ivar Jacobson International AB ( Paul McMahon)
  • Summary:

    Problem to be solved: There is no checklist item in the Architecture Selected state that ensures the key technical risks are agreed to that are referred to in the name of the state.

    Proposed solution: Need to add one more checklist item to Software System Alpha, Architecture Selected State. Proposed wording for new checklist item is: Key technical risks agreed to.

  • Reported: Essence 1.0b1 — Tue, 24 Sep 2013 04:00 GMT
  • Disposition: Resolved — Essence 1.0
  • Disposition Summary:

    The proposed solution is agreed to.

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

Enhancements on Competencies and Competency level definition

  • Legacy Issue Number: 18870
  • Status: closed  
  • Source: Ivar Jacobson International AB ( Michael Striewe)
  • Summary:

    Problem to be solved: The definition of five generic competency levels in section 8.1.6 (pages 16 to 19) is not supported in that detail by the definition of the language elements in section 9.3.5 (pages 86 to 88). Mismatches are in particular:
    - Section 8.1.6 states “Each competency has five levels of achievement. These are standard across all the kernel competencies […]”, while section 9.3.5.2 allows zero to many levels and does not enforce any standard instantiations.

    • Table 1 in section 8.1.6 summarizes the proposed competency levels in checklist style, while section 9.3.5.3 does only allow free text properties for that purpose.

    Proposed solution: It is proposed to enhance section 9.3.5 as follows:

    • Change section 8.1.6 to say “across all competencies”
    • Add a clarifying note in section 9.3.5 that each tool claiming conformance to the standard must implement the kernel and therefore has to provide the standard instantiations for competencies as defined in table 1 in section 8.1.6. To enforce this partially via the language directly, change multiplicity on association “possibleLevel” in section 9.3.5.2 from * to 5.
    • Add an association “checkListItem [*]” in section 9.3.5.3 that targets model element “Checkpoint”. For architectural clearness, move this element from package “AlphaAndWorkProduct” to “Foundation”.
  • Reported: Essence 1.0b1 — Tue, 13 Aug 2013 04:00 GMT
  • Disposition: Deferred — Essence 1.0
  • Disposition Summary:
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 132 – SPEM Taxonomy of Core Describable Elements is hard to read.

  • Legacy Issue Number: 18776
  • Status: closed  
  • Source: PTC ( Matthew Hause)
  • Summary:

    Specification: Essence – Kernel and Language for Software Engineering Methods (ad/2013-02-01)

    Figure 132 – SPEM Taxonomy of Core Describable Elements is hard to read. Recommend that the diagram should be cleaned up.

    (From an evaluation comment by Matthew Hause.)

  • Reported: Essence 1.0b1 — Tue, 11 Jun 2013 04:00 GMT
  • Disposition: Closed; No Change — Essence 1.0
  • Disposition Summary:

    This diagram is simply copied from the SPEM spec, for purposes of reference. The resolution is similar to what is in the SPEM spec.

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

Subclause: A.3.2.3 System Element

  • Legacy Issue Number: 18775
  • Status: closed  
  • Source: PTC ( Matthew Hause)
  • Summary:

    Specification: Essence – Kernel and Language for Software Engineering Methods (ad/2013-02-01)

    Subclause: A.3.2.3 System Element

    I strongly object to the term System Element used in A.3.2.3 System Element. I think it is a poorly defined term and seems to imply that a system is part of a software system. In systems engineering and in industry in practice, system is used to describe the larger component. INCOSE describes a system in the following way: "An interacting combination of elements viewed in relation to function (INCOSE)". It then goes on to say: "The elements, or parts, can include people, hardware, software, facilities, policies, and documents; that is, all things required to produce systems-level results. The results include system level qualities, properties, characteristics, functions, behavior and performance." The subsequent definition in this specification only includes software, hardware and date. I think this is shortsighted. I recommend that a new term should be found such as software system element.

    (From an evaluation comment by Matthew Hause.)

  • Reported: Essence 1.0b1 — Tue, 11 Jun 2013 04:00 GMT
  • Disposition: Resolved — Essence 1.0
  • Disposition Summary:

    Even though, in Essence, a "Software System" is defined to include "software, hardware and data". this is still not as expansive as the INCOSE definition of "system" and the elements it includes. Therefore, it is reasonable to make it clear in A.3.2.3 that the elements being considered are specifically "Software System Elements".

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

Subclause: 8.2.4.3 Testing

  • Legacy Issue Number: 18774
  • Status: closed  
  • Source: PTC ( Matthew Hause)
  • Summary:

    Specification: Essence – Kernel and Language for Software Engineering Methods (ad/2013-02-01)

    Subclause: 8.2.4.3 Testing

    Destructive testing concepts should be added to the following statement. It is mentioned above as a competency and should be repeated here as well.
    "The testing competency encapsulates the ability to conceive and execute tests to demonstrate that the system is fit for purpose, usable, meets one or more of its requirements and constitutes an appropriate solution to the stakeholders needs."
    (From an evaluation comment by Matthew Hause.)

  • Reported: Essence 1.0b1 — Tue, 11 Jun 2013 04:00 GMT
  • Disposition: Closed; No Change — Essence 1.0
  • Disposition Summary:

    The earlier part of the subclause does not refer to "destructive testing", but to the ability to "think destructively".

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

Subclause: 8.3.4.2 Development

  • Legacy Issue Number: 18773
  • Status: closed  
  • Source: PTC ( Matthew Hause)
  • Summary:

    Specification: Essence – Kernel and Language for Software Engineering Methods (ad/2013-02-01)

    Subclause: 8.3.4.2 Development

    I couldn’t help but notice the emphasis on coding and programming in this section, with very little mention of design and no mention at all on modeling. Is Essence not meant to support MDA or MBD at all? If so, it should be specifically mentioned.

    (From an evaluation comment by Matthew Hause.)

  • Reported: Essence 1.0b1 — Tue, 11 Jun 2013 04:00 GMT
  • Disposition: Closed; No Change — Essence 1.0
  • Disposition Summary:

    Essence as such is completely agnostic to MDA or MDD. The Development competency covers design, and modeling code be a practice used by those with this competency.

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

Subclause: 8.1.4 Alphas: The Things to Work With

  • Legacy Issue Number: 18772
  • Status: closed  
  • Source: PTC ( Matthew Hause)
  • Summary:

    Specification: Essence – Kernel and Language for Software Engineering Methods (ad/2013-02-01)

    Subclause: 8.1.4 Alphas: The Things to Work With

    The following sentence does not make sense: "For example, the team performs and plans work does not imply any specific order in that they perform and plan the work. "

    (From an evaluation comment by Matthew Hause.)

  • Reported: Essence 1.0b1 — Tue, 11 Jun 2013 04:00 GMT
  • Disposition: Resolved — Essence 1.0
  • Disposition Summary:

    Agreed that the sentence needs to be edited.

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

Subclause 8.1.2

  • Legacy Issue Number: 18771
  • Status: closed  
  • Source: PTC ( Matthew Hause)
  • Summary:

    Specification: Essence – Kernel and Language for Software Engineering Methods (ad/2013-02-01)

    Subclause 8.1.2

    The definition of Competencies is self-referential: "Competencies –representations of the key competencies required to do software engineering."

    (From an evaluation comment by Matthew Hause.)

  • Reported: Essence 1.0b1 — Tue, 11 Jun 2013 04:00 GMT
  • Disposition: Resolved — Essence 1.0
  • Disposition Summary:

    In Clause 4, "Competency" is defined as "a characteristic of a stakeholder or team member that reflects the ability to do work" and "a capability to do a certain job". The description of "Competencies" in 8.1.2 should follow this definition, which would be non-circular.

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

The definition of "Alpha" is confusing to me

  • Legacy Issue Number: 18770
  • Status: closed  
  • Source: PTC ( Matthew Hause)
  • Summary:

    Specification: Essence – Kernel and Language for Software Engineering Methods (ad/2013-02-01)

    The definition of "Alpha" is confusing to me. The following two definitions are contained in the spec and are radically different:

    Section 4.1 Alpha An essential element of the software engineering endeavor that is relevant to an assessment of the progress and health of the endeavor. Alpha is an acronym for an Abstract-Level Progress Health Attribute.

    Section 8.1.2 What is in the Kernel? Alphas – representations of the essential things to work with. The Alphas provide descriptions of the kind of things that a team will manage, produce, and use in the process of developing, maintaining and supporting software. They also act as the anchor for any additional sub-alphas and work products required by the software engineering practices.

    Also, an Alpha is far more that simply an “attribute” as defined in the name. The term "Progress Health Attribute" implies that it is a simple metric. Clearly it is far more than that.

    (From an evaluation comment by Matthew Hause.)

  • Reported: Essence 1.0b1 — Tue, 11 Jun 2013 04:00 GMT
  • Disposition: Resolved — Essence 1.0
  • Disposition Summary:

    Agreed that this is confusing.

    I would suggest that the best way to do that is to update the bullet on alphas in 8.1.2, to adding to the end of the first sentence something like " and, as such, are relevant to assessing the progress and health of a software endeavor."

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

Subclause: 7.4.2

  • Legacy Issue Number: 18769
  • Status: closed  
  • Source: PTC ( Matthew Hause)
  • Summary:

    Specification: Essence – Kernel and Language for Software Engineering Methods (ad/2013-02-01)

    Subclause: 7.4.2

    "The Essence Language emphasizes intuitive and concrete graphical syntax over formal semantics. This does not mean that the semantics are not as important or necessary. However, the description should be provided in a language that can be easily understood by the vast developer community whose interests are to quickly understand and use the language, rather than caring about the beauty of the language design. Hence, Essence pays extreme attention to syntax."

    Reading the specification it is obvious that much care and attention was put into the definition of the language and its semantics. Also, making the statement that how things are arranged (syntax) is more important that what the mean (semantics) is an inappropriate selling point for a language. Both are equally important.

    (From an evaluation comment by Matthew Hause.)

  • Reported: Essence 1.0b1 — Tue, 11 Jun 2013 04:00 GMT
  • Disposition: Closed; No Change — Essence 1.0
  • Disposition Summary:

    The quoted statement, as currently written, accurately reflects the intent of the designers of the Essence language.

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

There are no symbols defined in this specification

  • Legacy Issue Number: 18768
  • Status: closed  
  • Source: PTC ( Matthew Hause)
  • Summary:

    Specification: Essence – Kernel and Language for Software Engineering Methods (ad/2013-02-01)

    Subclause: 5.1 Symbols

    "There are no symbols defined in this specification"
    I found this somewhat confusing, as the specification is full of symbols. Possibly I do not understand what is meant by this section.

    (From an evaluation comment by Matthew Hause.)

  • Reported: Essence 1.0b1 — Tue, 11 Jun 2013 04:00 GMT
  • Disposition: Resolved — Essence 1.0
  • Disposition Summary:

    Clause 5 is an optional clause anyway. Since there are no symbols, it seems to make the most sense to just remove subclause 5.1 and make the clause include only the abbreviation currently under 5.2.

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

Formal definition of Practice, Alpha and other terms

  • Legacy Issue Number: 18767
  • Status: closed  
  • Source: PTC ( Matthew Hause)
  • Summary:

    Specification: Essence – Kernel and Language for Software Engineering Methods (ad/2013-02-01)

    I would have preferred a formal definition of Practice, Alpha and other terms prior to a discussion of the different levels of conformance and rigor of these elements. It would make it easier to understand what is meant, especially since the word practice is previously in several different contexts. Possibly referencing section 4 at the beginning would help. It was also difficult to tell when the terms were referring to parts of the Essence language or just using the terms in normal English. Also, the fact that Alpha is in fact an acronym but is used throughout the specification as the proper noun is also confusing.
    (From an evaluation comment by Matthew Hause.)

  • Reported: Essence 1.0b1 — Tue, 11 Jun 2013 04:00 GMT
  • Disposition: Resolved — Essence 1.0
  • Disposition Summary:

    The fact that there are terms used in a specific technical sense in the Essence specification is unavoidable – it is a large part of the purpose of any specification document to make exactly such definitions, and understanding this is necessary to understand the specification. The extensive set of definitions provided in Clause 4 is intended to help with this for Essence. The fact that the term "Alpha" was originally coined as an acronym does not seem particularly important in understanding its technical definition as given in Clause 4 and later use in the main body of the specification.

    Placing the definition of conformance in Clause 2 before the definitions in Clause 4 is as required by the OMG and ISO specification document template, and this organization is true of all current OMG specifications. Nevertheless, it would not hurt if, as suggested, a reference is made at the beginning of Clause 2 to the definitions in Clause 4.

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

In figure 9, what is the consequence of a stakeholder not being involved?

  • Legacy Issue Number: 18766
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( J.D. Baker)
  • Summary:

    Specification: Essence – Kernel and Language for Software Engineering Methods (ad/2013-02-01)

    In figure 9, what is the consequence of a stakeholder not being involved? Can I add that to the state machine if for example the person assigned to answer questions for a key organization refuses to respond to those questions?
    (From an evaluation comment by JD Baker.)

  • Reported: Essence 1.0b1 — Tue, 11 Jun 2013 04:00 GMT
  • Disposition: Closed; No Change — Essence 1.0
  • Disposition Summary:

    This issue is on what is now Figure 6, the "States of the Stakeholders" in 8.2.2.1. Some endeavors may never progress the Stakeholder alpha to the Involved state. The main consequence of this would be that you could not then get to the Agreed state and it is likely that the endeavor will not meet Stakeholder expectations.

    This is not necessarily something that needs to be explained in the specification, though. Perhaps it is more a users guide issue.

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

It is not clear what a customer area of concern is

  • Legacy Issue Number: 18765
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( J.D. Baker)
  • Summary:

    Specification: Essence – Kernel and Language for Software Engineering Methods (ad/2013-02-01)

    It is not clear what a customer area of concern is. In section 8.1.4 it appears that the customer area of concern includes stakeholders. In section 8.2 that statement is made that "Software engineering always involves at least on customer" which begs the question, what is a customer? Is it a set of stakeholders and opportunities? In that case it would be a customer are of concern. Is customer an alias for Customer Area of Concern?

    (From an evaluation comment by JD Baker.)

  • Reported: Essence 1.0b1 — Tue, 11 Jun 2013 04:00 GMT
  • Disposition: Resolved — Essence 1.0
  • Disposition Summary:

    Regardless of what a "customer" is, the area of concern is defined in 8.2.1 as "This area of concern contains everything to do with the actual use and exploitation of the software system to be produced." In the sentence "Software engineering always involved one customer", the colloquial sense of "customer" seems largely sufficient – i.e., there is always some intended consumer expected to actually "use and exploit" what the software engineering endeavor produces. However, perhaps a small clarification on what a customer is could be helpful.

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

stakeholders in section 8.1.4

  • Legacy Issue Number: 18764
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    Specification: Essence – Kernel and Language for Software Engineering Methods (ad/2013-02-01)

    In defining stakeholders in section 8.1.4, the spec states "All stakeholders must be involved throughout the software engineering endeavor to support the team and ensure that an acceptable software system is produced." Keeping all stakeholders involved throughout any project is an ideal but in my experience, never happens, at least not in large projects. Is this a key factor in Essence or just highly desirable from a method/process perspective?

    (From an evaluation comment by JD Baker.)

  • Reported: Essence 1.0b1 — Tue, 11 Jun 2013 04:00 GMT
  • Disposition: Resolved — Essence 1.0
  • Disposition Summary:

    Saying "must" here is awfully prescriptive and, as indicated in the submitted issue, not always realistic. It is also stronger than the more detailed discussion on the Stakeholder alpha later in 9.2.2.1 would seem to support.

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

The XML namespace URI for xmi is incorrect

  • Legacy Issue Number: 18763
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    File: Essence Metamodel XMI (ad/2012-11-02)

    The XML namespace URI for xmi is incorrect. It should be “http://www.omg.org/spec/XMI/20110701”.

  • Reported: Essence 1.0b1 — Tue, 11 Jun 2013 04:00 GMT
  • Disposition: Resolved — Essence 1.0
  • Disposition Summary:

    Agreed.

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

Lifecycle Diagram for Multi-Phase Waterfall Requirements State Mislabeled

  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    In Figure 154, the Lifecycle Diagram for "Multi-Phase Waterfall Requirements Alpha Extensions" the requirements state labeled "Described" should be labeled "Acceptable".

    Attached is a corrected figure which has change the state "Described" to "Acceptable"

  • Reported: Essence 1.0b1 — Sat, 22 Feb 2014 21:28 GMT
  • Disposition: Resolved — Essence 1.0
  • Disposition Summary:

    Agreed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT
  • Attachments:

Inconsistency of definitions for Bounded/Scoped requirements Alpha State.

  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Issue 176 has a proposed resolution to change the name of the Bounded Requirements alpha state to Scoped.

    However there is still a need to change the definition to better reflect the checklist and the concept of scoping with respect to its making the extent of the system clear.

    We need to have a high level definition which captures the concept of clear extent and purpose.

    the current definition in 8.2.3.1 does not capture the extent concept of scoping or boundedness properly.

    "Bounded: The purpose and theme of the new system are clear."

    Also, if you look at clause 9.8.3 in the examples of the textual notation there is a another definition which is different than the one in the alpha section, but it uses the "extent" concept

    "state Bounded

    {"The theme and extent of the new system is clear"}

    This is adds extent concept but keeps the "theme" concept.

    The concept of "theme" seems too loose for a proper definition.

    Proposed Resolution

    I suggest that we resolve this issue by replacing the definition in
    8.2.3.1 and in 9.2.3 for the new
    named state "Scoped" with the following:

    "Scoped: The purpose and extent of the new system are clear"

  • Reported: Essence 1.0b1 — Tue, 18 Feb 2014 15:44 GMT
  • Disposition: Resolved — Essence 1.0
  • Disposition Summary:

    Updated the definition of the Bounded state as suggested (independent of the resolution to Issue 176). (Note, however, that the subclause references given in the issue description are incorrect. They should be 8.3.2.1 and 9.8.3.)

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