Issue 18763: The XML namespace URI for xmi is incorrect
Issue 18764: stakeholders in section 8.1.4
Issue 18765: It is not clear what a customer area of concern is
Issue 18766: In figure 9, what is the consequence of a stakeholder not being involved?
Issue 18767: Formal definition of Practice, Alpha and other terms
Issue 18768: "There are no symbols defined in this specification"
Issue 18769: Subclause: 7.4.2
Issue 18770: The definition of "Alpha" is confusing to me
Issue 18771: Subclause 8.1.2
Issue 18772: Subclause: 8.1.4 Alphas: The Things to Work With
Issue 18773: Subclause: 8.3.4.2 Development
Issue 18774: Subclause: 8.2.4.3 Testing
Issue 18775: Subclause: A.3.2.3 System Element
Issue 18776: Figure 132 – SPEM Taxonomy of Core Describable Elements is hard to read.
Issue 18763: The XML namespace URI for xmi is incorrect (essence-ftf)
Click here for this issue's archive.
Source: Ivar Jacobson International AB (Mr. Ed Seidewitz, eseidewitz(at)ivarjacobson.com)
Nature: Revision
Severity:
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”.
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.)
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.)
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.)
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.)
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.)
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.)
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.)
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.)
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.)
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.)
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.)
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.)
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.)