Issues for Essence - Kernel & Language for Software Engineering Methods 1.3 RTF

To comment on any of these issues, send email to [email protected]. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to [email protected].

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Jira Issues

Issue 19464: Error in definition of Activity Jira Issue ER-6
Issue 19465: Error in recent change of definition of Practice Jira Issue ER-7
Issue 19509: Wrong usage of Alpha Containment Jira Issue ER-8
Issue 19641: None of the Activity Spaces seems to address the Requirements::Addressed Alpha State Jira Issue ER-13
Issue 19698: PRINCIPLE OF ALPHA STATE INDEPENDENCE Jira Issue ER-14
Issue 19699: SEMANTIC DISCIPLINE ISSUE Jira Issue ER-15
Issue 19700: UNDERSTANDABILITY ISSUE Jira Issue ER-16

Issue 19464: Error in definition of Activity (essence-rtf)

Click here for this issue's archive.
Source: Ivar Jacobson International AB (Mr. Paul McMahon, pemcmahon1(at)gmail.com)
Nature: Clarification
Severity: Significant
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.

Resolution: 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.
Revised Text: In Clause 4 (Terms and Definitions), change the definition of activity to: An activity defines one or more kinds of work items and gives guidance on how to perform these. In subclause 9.3.4.5 (in the Language Specification), change the Description of Activity to: An activity defines one or more approaches for carrying out some work to be performed and can recommend actions on alphas and/or work products in order to perform this work. In subclause 9.3.4.8, change the Description of Approach to: An approach defines one way to accomplish some work. An approach is specified in the context of a specific activity.
Actions taken:
June 10, 2014: received issue
July 8, 2015: Resolved
October 2, 2015: closed issue

Issue 19465: Error in recent change of definition of Practice (essence-rtf)

Click here for this issue's archive.
Source: Ivar Jacobson International AB (Mr. Paul McMahon, pemcmahon1(at)gmail.com)
Nature: Clarification
Severity: Significant
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.

Resolution: 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.
Revised Text: In Clause 4 (Terms and Definitions), change the definition of practice to (the definition it had before the FTF changed it): A practice is a repeatable approach to doing something with a specific objective in mind. In subclause 9.3.2.15 (under the Language Specification), change the Description of Practice to: A practice is a repeatable approach to doing something with a specific objective in mind. A practice describes how to handle a specific aspect of a software engineering endeavor, including the descriptions of all relevant elements necessary to express the desired work guidance that is required to achieve the purpose of the practice. A practice can be defined as a composition of other practices.
Actions taken:
June 10, 2014: received issue
July 8, 2015: Resolved
October 2, 2015: closed issue

Issue 19509: Wrong usage of Alpha Containment (essence-rtf)

Click here for this issue's archive.
Source: Ivar Jacobson International AB (Mr. Michael Striewe, michael.striewe(at)paluno.uni-due.de)
Nature: Clarification
Severity: Minor
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 [�].�

Resolution: Change wording The correction is agreed to.
Revised Text: In subclause C.4.2, point 3b, change "Essence Alpha Containments" to "Essence Work Product Manifests".
Actions taken:
July 4, 2014: received issue
July 8, 2015: Resolved
October 2, 2015: closed issue

Issue 19641: None of the Activity Spaces seems to address the Requirements::Addressed Alpha State (essence-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
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.

Resolution: Merge with [1]ER-11 Resolving [2]ER-11 results in an activity space with Requirements::addressed as a completion criterion, which also resolves this issue. ---------------------------------------------------------------------------------------- [1] http://solitaire.omg.org/browse/ER-11 [2] http://solitaire.omg.org/browse/ER-11
Revised Text:
Actions taken:
October 15, 2014: received issue
July 8, 2015: Duplicate or Merged
October 2, 2015: closed issue

Issue 19698: PRINCIPLE OF ALPHA STATE INDEPENDENCE (essence-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
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

Resolution: 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.
Revised Text:
Actions taken:
December 29, 2014: received issue
July 8, 2015: Closed; No Change
October 2, 2015: closed issue

Issue 19699: SEMANTIC DISCIPLINE ISSUE (essence-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
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.

Resolution: 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.
Revised Text:
Actions taken:
December 29, 2014: received issue
July 8, 2015: Closed; No Change
October 2, 2015: closed issue

Issue 19700: UNDERSTANDABILITY ISSUE (essence-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
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.

Resolution: 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.
Revised Text:
Actions taken:
December 29, 2014: received issue
July 8, 2015: Closed; No Change
October 2, 2015: closed issue

Discussion: