Issues

The following text may need refinement, uses the passive voice, and uses the past tense.

• https://issues.omg.org/browse/ESSENCE2-2 - Passive Voice
• https://issues.omg.org/browse/ESSENCE2-3 - Present Tense
• https://issues.omg.org/browse/ESSENCE2-5 - Streamline text

Original Text

The kernel is described using a small subset of the Language defined in Clause 9 Language Specification. It is organized into three areas of concern, each containing a small number of:

• 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 systems and, as such, are relevant to assessing the progress and health of an engineeringendeavor. They also act as the anchor for any additional sub-alphas and work products required by the engineering practices.
• Activity Spaces - representations of the essential things to do. The Activity Spaces provide descriptions of the challenges a team faces when developing, maintaining, and supporting systems, and the kinds of things that the team will do to meet them.
• Competencies - representations of the key capabilities required to carry out the work of engineering.

To maintain its practice independence the kernel does not include any instances of the other language elements such as work products or activities. These only make sense within the context of a specific practice.
The best way to get an overview of the kernel as a whole is to look at the full set of Alphas and Activity Spaces and how they are related

Suggestion

The kernel description uses a small subset of the Language defined in Clause 9 Language Specification. It is organized into three areas of concern, each containing a small number of:

• Alphas: Representations are the essential things involved in the work. Alphas describe what a team manages, produces, and uses in developing, maintaining, and supporting systems. They are relevant for assessing the progress and health of an engineering endeavor and act as anchors for any additional sub-alphas and work products required by engineering practices.
• Activity Spaces: Representations of the essential things to do. Activity Spaces describe the challenges a team faces when developing, maintaining, and supporting systems and the kinds of activities undertaken to meet these challenges.
• Competencies: Representations of the key capabilities for engineering work.

To maintain its practice independence, the kernel does not include any instances of other language elements, such as work products or activities. These elements only make sense within the context of a specific practice.
To get an overview of the kernel, examine the full set of Alphas and Activity Spaces and understand their relationships.

Issues

The following text may need refinement, uses the passive voice, and uses the past tense.

• https://issues.omg.org/browse/ESSENCE2-2 - Passive Voice
• https://issues.omg.org/browse/ESSENCE2-3 - Present Tense
• https://issues.omg.org/browse/ESSENCE2-5 - Streamline text

Original Text

Methods, practices and the Essence Kernel itself are defined using the Essence Language. The Essence Language is a domain-specific language for practices and methods (where in turn a typical domain for those is engineering as expressed by the Essence Kernel), which has a static base (syntax and well-formedness rules) to allow the effective definition of kernels, methods and practices, and additional dynamic features (operational semantics) to enable usage, and adaptation.

teams. The first objective led to the definition of both textual and graphical syntax as well as to the development of a concept of views in the latter. This way, teams can represent methods in exactly the way that suits their purposes best. By providing both textual and graphical syntax, nobody is forced to use a graphical notation in situations where textual notation is easier to handle, and vice versa. By providing a concept of views, nobody is forced to show a complete graphical representation in situations where a partial graphical representation of a method is sufficient.

The second objective led to the definition of dynamic semantics for methods. This way, a method is more than a static definition of what to do, but an active guide for a team's way-of-working. At any point in time in a running engineering endeavor, the method can be consulted and it will return advice on what to do next. Moreover, the method can be tweaked at any point in time and will still return (possibly alternate) advice on what to do next for the same situation.

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.

Suggestion

Methods, practices, and the Essence Kernel are defined and described using the Essence Language. The Essence Language is a domain-specific language for defining and describing practices and methods. In contrast, the Essence Kernel defines and describes a particular engineering domain, such as software engineering. The Essence Kernel is a static base (syntax and well-formedness rules), allowing for the effective definition of kernels, methods and practices, and additional dynamic features (operational semantics) to enable usage and adaptation.

The language design is driven by two main objectives: making methods visible and useful to teams. The first objective leads to the definition of textual and graphical syntax and the development of a concept of views in the latter. This way, teams represent methods exactly that suit their purposes best. By providing both textual and graphical syntax, nobody is forced to use a graphical notation in situations where textual notation is easier to handle, and vice versa. By providing a concept of view, nobody is forced to show a complete graphical representation in situations where a partial graphical representation of a method is sufficient.

The second objective leads to the definition of dynamic semantics for methods. In this way, a method becomes more than a static definition of what to do; it is an active guide for a team's work. At any point during an engineering endeavor, the method is consulted to provide advice on what to do next. Furthermore, the method is tweakable at any moment and still offers (possibly alternate) advice on what to do next in the same situation.

The Essence Language emphasizes intuitive and concrete graphical syntax over formal semantics. This does not imply that semantics are unimportant or unnecessary. However, the description should be provided in a language easily understood by the vast developer community, whose primary interest is quickly understanding and using the language rather than appreciating the elegance of its design. Hence, Essence pays extreme attention to syntax.

Issues

The following text is may need refinement, uses the passive voice, and uses the past tense.

• https://issues.omg.org/browse/ESSENCE2-2 - Passive Voice
• https://issues.omg.org/browse/ESSENCE2-3 - Present Tense
• https://issues.omg.org/browse/ESSENCE2-5 - Streamline text

Original Text

The successful development of systems benefits from the application of effective methods and well-defined practices. Traditionally, methods have been defined up-front before a team starts to work. They are then instantiated so that the activities – created from the definition – are ready to be executed by practitioners (e.g., analysts, developers, testers, project leads) in a predefined order to get the result specified by the definition. Methods defined in this way are often considered by development teams to be too prescriptive, heavyweight and inflexible. The view – “the team is the computer, the process is the program” – is not suitable for creative engineering work, which is agile, trial-and-error based and collaboration intensive.

What has been missing is a simple way to bootstrap a method, one that allows a team to experiment and evolve a way of working that meets their needs while they do their work. A living method that they can continuously inspect and adapt so that it learns as they learn and reflects what the team is actually doing rather than what the team thought they would be doing before they started work. A living method where the set of practices the team uses can change over time as their systems mature and they continuously improve their way of working.

Suggestion

The successful development of systems benefits from applying effective methods and well-defined practices. Traditionally, methods are defined up-front before a team starts to work. They are then instantiated so the activities – created from the definition – are ready for practitioners (e.g., analysts, developers, testers, and project leads) in a predefined order to get the result specified by the definition. Development teams often consider methods definitions built this way too prescriptive, heavyweight, and inflexible. The view – “the team is the computer, the process is the program” – is unsuitable for creative engineering work, which is agile, trial-and-error based, and collaboration intensive.

What is missing is a simple way to bootstrap a method that allows a team to experiment and evolve a way of working that meets their needs while continuing to work. It is a living method that continuously inspects and adapts so that it learns as the team learns and reflects what the team is doing rather than what the team thought they would be doing before work started. A living method is one where the set of practices the team uses changes over time as the systems mature and continuously improve their working methods.

Issues

The following text is cumbersome and awkward, uses the passive voice, and uses the past tense.

• https://issues.omg.org/browse/ESSENCE2-3 - Present Tense
• https://issues.omg.org/browse/ESSENCE2-5 - Streamline text

Original Text

• Separate the method support that different types of user are interested in to make methods useful for, and accessible to, everyone involved in engineering. For example, process engineers are usually more interested in methodology aspects but their interest should not overload developers, analysts, testers, team leaders, and project managers.

Suggestion

• Separate the method supporting different types of users interested in making methods useful for and accessible to everyone involved in engineering. For example, process engineers usually have an interest in methodology aspects, but their interest should not overload developers, analysts, testers, team leaders, and project managers.

Isuues

The following text is cumbersome and awkward, uses the passive voice, and uses the past tense.

• https://issues.omg.org/browse/ESSENCE2-3
• https://issues.omg.org/browse/ESSENCE2-2
• https://issues.omg.org/browse/ESSENCE2-5

Original Text

• Enable method building by the composition of practices, so that methods can be quickly assembled by a project team to match their needs, experiences, and aspirations. Allowing the method to start small and grow as needed.

Suggestion

• Enable method building by the composition of practices supporting a project team's quick assembly of methods to match their needs, experiences, and aspirations. Allowing the method to start small and grow as needed.

Issues

The text is stiff and does not stream well:

• https://issues.omg.org/browse/ESSENCE2-5

Original Text

• Actively support practitioners in the conduct of their work by providing guidance based on state and practice definitions.

Suggested Text

• Actively support practitioners by providing guidance based on state and practice definitions.

Isuues

The following text may need refinement, uses the passive voice, and uses the past tense.

• https://issues.omg.org/browse/ESSENCE2-3
• https://issues.omg.org/browse/ESSENCE2-2
• https://issues.omg.org/browse/ESSENCE2-5

Original Text

They allow people to describe the essentials of their existing and future methods and practices so that they can be compared, evaluated, tailored, used, adapted, simulated, and measured by practitioners as well as taught and researched by academics and researchers.

Suggestion:

They allow people to describe the essentials of their existing and future methods and practices. They also allow for the comparison, evaluation, tailoring, usage, adaptation, simulation, and measurement by practitioners and being taught and investigated by academics and researchers.

Issue

The text is cumbersome and awkward. It uses past tense and passive voice and does not read well.

• https://issues.omg.org/browse/ESSENCE2-2
• https://issues.omg.org/browse/ESSENCE2-3
• https://issues.omg.org/browse/ESSENCE2-5

Original Text

• Provide a common base that is useful for engineering endeavors of all sizes (small, medium, and large) and that can easily be extended without changing or complicating the kernel.

Suggested Text

• Provide a common base useful for engineering endeavors of all sizes (small, medium, and large), which is easily extensible without changing or complicating the kernel.

Issues

Content

In the text it says:

Note: other kernels for other domains could be defined using the Essence Language, but these are outside the scope of this specification.

Question: Aren't all domains outside the newly defined Engineering Essence scope versus the original Software Essence proposed?

Grammatical

The following text is cumbersome and awkward, uses the passive voice, and uses the past tense.

• https://issues.omg.org/browse/ESSENCE2-5 - Streamline text

Original Text

• The Essence Kernel captures the essential elements of engineering, those that are integral to all engineering methods. Note: other kernels for other domains could be defined using the Essence Language but these are outside the scope of this specification.

Suggestion

• The Essence Kernel captures essential engineering elements integral to all engineering methods. Note: other kernels for other domains could be defined using the Essence Language, but these are outside the scope of this specification.

Issues

The following text is cumbersome and awkward, uses the passive voice, and uses the past tense.

• https://issues.omg.org/browse/ESSENCE2-2 - Passive Voice
• https://issues.omg.org/browse/ESSENCE2-3 - Present Tense
• https://issues.omg.org/browse/ESSENCE2-5 - Streamline text

Original Text

• Support method agility, so that practices and methods can be refined and modified during a project to reflect experiences, lessons learned, and changing needs.

Suggestion

• Support method agility so practices and methods are refinable and modifiable during a project lifecycle, reflecting experiences, lessons learned, and changing needs.

Issues

The following text is cumbersome and awkward, uses the passive voice, and uses the past tense.

• https://issues.omg.org/browse/ESSENCE2-2 - Passive Voice
• https://issues.omg.org/browse/ESSENCE2-3 - Present Tense
• https://issues.omg.org/browse/ESSENCE2-5 - Streamline text

Original Text

Teams need to be agile when working with methods so that:

• The focus is on method use, rather than comprehensive method description.
• The full team owns the method rather than a select few.
• The method evolves to address the team's ongoing needs, rather than staying fixed and unchanged.
• The method remains as close to practitioners' practice as possible, so that it evolves and adapts to their particular context and challenges.
• The method supports all competency levels helping the experienced and inexperienced practitioners alike.

This requires a separation of concerns:

• Separating the what from the how.
• Separating the results from the documentation.
• Separating the essence from the details.
• Separating what the least experienced developers need from what the most experienced developers need.
• Separating the complexity of engineering from the complexity of defining methods.

Key to achieving this is the separation of the kernel - capturing the essence of engineering - from 1) the practices that will be combined to form the method and 2) the language used to capture the kernel and the practices. This allows them all to be kept small, focused, and as simple as possible.

Suggestion

Agility in Team Methodologies

Teams must adopt agile approaches to method implementation to ensure effectiveness and responsiveness to dynamic needs:

• Method Utilization Over Description: Prioritize practical use of methods over exhaustive descriptions to enhance adaptability.
• Collective Ownership: Ensure the entire team, rather than a select few, owns and engages with the method.
• Continuous Evolution: Allow methods to evolve in response to the team's changing needs instead of remaining static.
• Practitioner Alignment: Keep methods aligned with practitioners' actual practices, allowing adaptation to specific contexts and challenges.
• Support Across Competency Levels: Design methods to aid all practitioners, from novices to experts, enhancing skill development and application.

Essential Separations for Method Effectiveness

Effective method management involves distinct separations:

• What vs. How: Distinguish between the goals of the method and the means of achieving them.
• Results vs. Documentation: Separate outcomes from their documentation to streamline processes.
• Essence vs. Details: Focus on the core (essence) of engineering principles while minimizing excessive details.
• Needs of Varying Expertise Levels: Tailor method accessibility to cater to the least and most experienced developers.
• Engineering vs. Method Definition Complexity: Differentiate the complexities inherent in engineering from those in defining methods.

Key Strategy: Kernel and Method Separation

Central to these practices is the distinction between the kernel, which captures the essence of engineering, and:

1. The practices combined to form the method.
2. The language used to describe the kernel and the practices.

This separation ensures that all components remain streamlined, focused, and simple, facilitating adaptability and effectiveness.

Issues

The following text is cumbersome and awkward, uses the passive voice, and uses the past tense.

• https://issues.omg.org/browse/ESSENCE2-2 - Passive Voice
• https://issues.omg.org/browse/ESSENCE2-3 - Present Tense
• https://issues.omg.org/browse/ESSENCE2-4 - Personal Pronouns
• https://issues.omg.org/browse/ESSENCE2-5 - Streamline text

Original Text

This specification contains detailed descriptions of both the Essence Kernel and the Essence Language. You do not need a detailed knowledge of the language to be able to read and understand the kernel. Although the kernel is specified using the language it only uses a small subset of the language, and is designed to be intuitive, self-contained and accessible to those without a detailed knowledge of the language.

Some readers will be more interested in the Essence Kernel and its usage than the details of the language. If you fall into this category, it is recommended that you focus on Clause 8 Kernel Specification dipping into Clause 9 Language Specification when and where you require more information about the language elements or icons used. You may also want to look at the examples and extensions described in the annexes before looking at the details of the language itself.

Other readers will want to understand the detail of the language before looking at the Kernel or the examples. In this case it is recommended that you first read Clause 9 Language Specification before reading Clause 8 Kernel Specification and looking at the example and extensions presented in the annexes.

We expect most readers to prefer to read the Kernel Specification before diving into the Language Specification because 1) it only uses a small subset of the language, 2) it provides a good example of the expressive qualities of the language, and 3) if it cannot be understood without first reading the entire language specification it is not a good basis for the definition and sharing or your practices and methods.

Suggestion

This specification contains detailed descriptions of the Essence Kernel and the Essence Language. Detailed language knowledge is not required to read and understand the kernel. Although the kernel is specified using the language, it only uses a small subset of the language. It is designed to be intuitive, self-contained, and accessible to those without detailed language knowledge.

Some readers are more interested in the Essence Kernel and its usage than in the details of the language. For those readers, it is recommended to focus on Clause 8 Kernel Specification, dipping into Clause 9 Language Specification when and where more information about the language elements or icons is required. The examples and extensions described in the annexes may also be helpful to review before looking at the details of the language itself.

Other readers want to understand the details of the language before looking at the Kernel or the examples. In this case, it is recommended to first read Clause 9 Language Specification before reading Clause 8 Kernel Specification and looking at the examples and extensions presented in the annexes.

Most readers prefer reading the Kernel Specification before the Language Specification because:
1. iI only uses a small subset of the language
2. It provides a good example of the expressive qualities of the language
3. if it cannot be understood without first reading the entire language specification, it is not a reasonable basis for defining and sharing practices and methods.

Issues

The following text is repetitive, uses the passive voice, uses the past tense and personal pronouns.

• https://issues.omg.org/browse/ESSENCE2-2 - Passive Voice
• https://issues.omg.org/browse/ESSENCE2-3 - Present Tense
• https://issues.omg.org/browse/ESSENCE2-4 - Personal Pronouns
• https://issues.omg.org/browse/ESSENCE2-5 - Streamline text

Original Text

The kernel is a stripped-down, light-weight set of definitions that captures the essence of effective, scalable engineering in a practice independent way.
The focus of the kernel is to define a common basis for the definition of engineering practices, one that allows them to be defined and applied independently. The practices can then be mixed and matched to create specific engineering methods tailored to the specific needs of a specific engineering community, project, team, or organization. The kernel has many benefits including:

• Allowing you to apply as few or as many practices as you like.
• Allowing you to easily capture your current practices in a reusable and extendable way.
• Allowing you to evaluate your current practices against a technique neutral control framework.
• Allowing you to align and compare your on-going work and methods to a common, technique neutral framework, and then to complement it with any missing critical practices or process elements.
• Allowing you to start with a minimal method adding practices as the endeavor progresses and when you need them.

Suggestion

The kernel is a stripped-down, lightweight set of definitions that captures the essence of effective, scalable engineering in a practice-independent way. Its focus is on defining a common basis for the definition of engineering practices, allowing them to be defined and applied independently. These practices can then be mixed and matched to create specific engineering methods tailored to the needs of a particular engineering community, project, team, or organization.

The kernel offers numerous benefits, including:

• Flexibility in Practice Application: Allows the application of as few or as many practices as needed.
• Capture of Current Practices: Facilitates the easy capture of current practices in a reusable and extendable manner.
• Evaluation Against a Neutral Framework: Enables evaluation of current practices against a technique-neutral control framework.
• Alignment and Comparison: Allows alignment and comparison of ongoing work and methods to a common, technique-neutral framework, complementing it with any missing critical practices or process elements.
• Incremental Method Development: Supports starting with a minimal method and adding practices as the endeavor progresses and as needed.

Issues

The following text is cumbersome and awkward, uses the passive voice, and uses the past tense.

• https://issues.omg.org/browse/ESSENCE2-2 - Passive Voice

Original Text

In the solution area of concern the team has to be able to capture and analyze the requirements, and build and operate a system that fulfills them. This requires the following competencies to be available to the team:

Suggestion

In the solution area of concern, the team needs to capture and analyze the requirements and build and operate a system that fulfills them. This necessitates the following competencies being available to the team:

Issues

The following text is informal, has redundancies, uses the passive voice, and uses the past tense.

• https://issues.omg.org/browse/ESSENCE2-2 - Passive Voice
• https://issues.omg.org/browse/ESSENCE2-3 - Present Tense
• https://issues.omg.org/browse/ESSENCE2-5 - Streamline text

Original Text

In the solution area of concern the team has to be able to capture and analyze the requirements, and build and operate a system that fulfills them. This requires the following competencies to be available to the team:

• Analysis: This competency encapsulates the ability to understand opportunities and their related stakeholder needs, and transform them into an agreed and consistent set of requirements.
• Development: This competency encapsulates the ability to design and produce effective systems following the standards and norms agreed by the team.
• Testing: This competency encapsulates the ability to test a system, verifying that it is usable and that it meets the requirements.

In the endeavor area of concern the team has to be able to organize itself and manage its work load. This requires the following competencies to be available to the team:

• Leadership: This competency enables a person to inspire and motivate a group of people to achieve a successful conclusion to their work and to meet their objectives.
• Management: This competency encapsulates the ability to coordinate, plan and track the work done by a team.

Each competency has five levels of achievement. These are standard across all of the kernel competencies and summarized in Table Error: Reference source not found.1. The table reads from top to bottom with the lowest level of competency shown in the first row and the highest in the last row.

Suggestion

In the solution area of concern, the team's responsibilities include capturing and analyzing requirements and building and operating a system that fulfills these requirements. To effectively manage these tasks, specific competencies must be accessible to the team:

• Analysis: is crucial for understanding the opportunities presented and their related stakeholder needs. It involves transforming these opportunities and needs into a set of agreed-upon and consistent requirements, ensuring that the system developed aligns with stakeholder expectations.
• Development: focuses on designing and producing effective systems. It requires adherence to the team's established and agreed-upon standards and norms, ensuring consistency and quality in system development.
• Testing: is essential for ensuring the system's usability. It involves rigorous testing to verify that the system functions as intended and meets all the specified requirements.

In the endeavor area of concern, the team's ability to organize and manage its workload is paramount. This organizational capacity hinges on the availability of the following competencies within the team:

• Leadership: This competency is vital for inspiring and motivating the team. Effective leadership drives the team towards achieving successful outcomes and meeting their objectives by providing direction, motivation, and a clear purpose.
• Management: This competency involves coordinating, planning, and tracking the team's work. It ensures that projects are executed efficiently, resources are allocated effectively, and deadlines are met while aligning with the project's goals.

Each of these competencies is structured into five levels of achievement, which provide a framework for assessing and developing team skills. These levels are consistent across all kernel competencies and are detailed in Table <TABLE>. This table outlines the progression from the most basic level of competency, shown in the first row, to the most advanced level, displayed in the last row. The structured approach allows teams to clearly understand the development path for each competency, facilitating targeted growth and improvement.

By ensuring these competencies are developed and maintained, teams can enhance their effectiveness and efficiency, directly contributing to the success of their projects.

Issues

The following text is verbose and long, uses the passive voice, and uses the past tense.

• https://issues.omg.org/browse/ESSENCE2-2 - Passive Voice
• https://issues.omg.org/browse/ESSENCE2-3 - Present Tense
• https://issues.omg.org/browse/ESSENCE2-4 - Personal Pronouns
• https://issues.omg.org/browse/ESSENCE2-5 - Streamline text

Original Text

The kernel Alphas 1) capture the key concepts involved in engineering, 2) allow the progress and health of any engineering endeavor to be tracked and assessed, and 3) provide the common ground for the definition of engineering methods and practices. The Alphas each have a small set of pre-defined states that are used when assessing progress and health. Associated with each state is a set of predefined checklists. These states are not just one-way linear progressions. Each time you reassess a state, if you do not meet all the checklist items, you can go back to a previous state. You can also iterate through the states multiple times depending on your choice of practices. The Alphas should not be viewed as a physical partitioning of your endeavor or as just abstract work products. Rather they represent critical indicators of the things that are most important to monitor and progress. As an example, team members, while they are part of the Team Alpha, are also stakeholders, and therefore can also be part of the Stakeholders Alpha. The Alphas, their relationships and their areas of concern are shown in Figure Error: Reference source not found.3. Note that the Alphas are agnostic to your chosen practices and method. For example, the relationship shown in Figure Error: Reference source not found.3 that the "team performs and plans work" does not imply any specific order in which they perform and plan the work.

Suggestion

The kernel Alphas capture the key concepts involved in engineering:

• Allow the progress and health of any engineering endeavor to be tracked and assessed.
• Provide the common ground for the definition of engineering methods and practices.

Each Alpha has a small set of pre-defined states used when assessing progress and health, with each state associated with a predefined set of checklists. These states are not merely one-way linear progressions; returning to a previous state is possible if all checklist items are not met upon reassessment. Additionally, iteration through the states is possible depending on chosen practices.

The Alphas should not be viewed as a physical partitioning of the endeavor or merely abstract work products; rather, they represent critical indicators of the most important things to monitor and progress. For example, team members, while part of the Team Alpha, are also stakeholders and can thus be part of the Stakeholders Alpha. Figure 8.3 illustrates the Alphas, their relationships, and their areas of concern.

Note that the Alphas are agnostic to chosen practices and methods. For instance, the relationship depicted in Figure 8.3, where the "team performs and plans work," does not imply any specific order in which work is performed and planned.

Issues

The following text is too informal, uses the passive voice, and uses the past tense.

• https://issues.omg.org/browse/ESSENCE2-2 - Passive Voice
• https://issues.omg.org/browse/ESSENCE2-3 - Present Tense
• https://issues.omg.org/browse/ESSENCE2-4 - Personal Pronouns
• https://issues.omg.org/browse/ESSENCE2-5 - Streamline text

Original Text

The Essence Kernel provides the common ground to, among other things, help practitioners to compare methods and make better decisions about their practices. Presenting the essence of engineering in this way enables us to build our knowledge on top of what we have known and learnt, and to apply and reuse gained knowledge across different application domains and systems of differing complexity.

The kernel elements form the basis of a vocabulary - a map of the engineering context - upon which we can define and describe any method or practice in existence or foreseen in the near future. They are defined in a way that allows them to be extensible and tailorable, supporting a wide variety of practices, methods, and development styles.

The Essence Kernel is also designed to be extensible to cater for the emergence of new technologies, new practices, new social working patterns, and new research. It is small and light at its base but extensible to cover more advanced uses, such as dealing with life-, safety-, business-, mission-, and security-critical systems.

The Essence Kernel can also be used whether or not a team has a documented method. The elements of the kernel are always prevalent in any engineering endeavor. They are what we always have (e.g., teams and work), what we always do (e.g., specify and implement), and what we always produce (e.g., systems) when we conduct engineering work. Even without a defined method the Essence Kernel can be used to monitor the progress and health of any endeavor, and to analyze the strengths and weaknesses of a team's way of working.

Suggestion

The Essence Kernel elements form the basis of a vocabulary, which is a map of the engineering context. This vocabulary then becomes the basis for definitions and descriptions of existing or future engineering methods or practices.

The definitions of methods and practices should be extensible and tailorable, supporting various practices, methods, and development styles.

Additionally, the Essence Kernel's intention is for extensibility to support the emergence of new technologies, practices, social working patterns, and research. It is small and light at its base but extensible to cover more advanced uses, especially mission-critical systems that cover life and safety, business, and security.

The Essence Kernel is also helpful whether or not a team has documented methods. The elements of the kernel are always prevalent in any engineering endeavor. They are the core of engineering (e.g., teams and work), the engineering processes (e.g., specify and implement), and the engineering results (e.g., systems). Even without a predefined method, the Essence Kernel can monitor the progress and health of any engineering endeavor and analyze the strengths and weaknesses of a team's way of working.

Issues

The following text is too informal, uses the passive voice, and uses the past tense.

• https://issues.omg.org/browse/ESSENCE2-2 - Passive Voice
• https://issues.omg.org/browse/ESSENCE2-3 - Present Tense
• https://issues.omg.org/browse/ESSENCE2-5 - Streamline text

Original Text

The Kernel is organized into three discrete areas of concern, each focusing on a specific aspect of engineering. As shown in Figure Error: Reference source not found.2, these are:

• Customer - This area of concern contains everything to do with the actual use and exploitation of the system to be produced.
• Solution - This area of concern contains everything to do the specification and development of the system.
• Endeavor - This area of concern contains everything to do with the team, and the way that they approach their work.

<FIGURE HERE>

Throughout the diagrams in the body of the kernel specification, the three areas of concern are distinguished with different color codes where green stands for customer, yellow for solution, and blue for endeavor. The colors will facilitate the understanding and tracking of which area of concern owns which Alphas and Activity Spaces. We have also added textual labels so the reader need not rely totally on the color codes.

Suggestion

The Kernel is organized into three discrete areas of concern, each focusing on a specific engineering aspect, as seen in Figure 8.2. These areas of concern are:

• Customer: Encompasses everything related to the actual use and exploitation of the system to be produced.
• Solution: Covers everything regarding the specification and development of the system.
• Endeavor: Includes everything concerning the team and how they approach their work.

<FIGURE HERE>

Throughout the diagrams in the body of the kernel specification, the three areas of concern are distinguishable with different color codes: green for customer, yellow for solution, and blue for endeavor. These colors aid in understanding and tracking which area of concern owned which Alphas and Activity Spaces. We also add textual labels so the reader does not rely solely on the color codes.

Issues

The following text is cumbersome and awkward, uses the passive voice, and uses the past tense.

• https://issues.omg.org/browse/ESSENCE2-2 - Passive Voice
• https://issues.omg.org/browse/ESSENCE2-3 - Present Tense
• https://issues.omg.org/browse/ESSENCE2-4 - Personal Pronouns
• https://issues.omg.org/browse/ESSENCE2-5 - Streamline text

Original Text

Competency Level Brief Description

1 - Assists Demonstrates a basic understanding of the concepts involved and can follow instructions.
The following describe the traits of a Level 1 individual:

• Understands and conducts his or her self in a professional manner.
• Is able to correctly respond to basic questions within his or her domain.
• Is able to perform most basic functions within the domain.
• Can follow instructions and complete basic tasks.

2 - Applies Able to apply the concepts in simple contexts by routinely applying the experience gained so far.
The following describe the traits of a Level 2 individual:

• Is able to collaborate with others within the Team.
• Is able to satisfy routine demands and do simple work requirements.
• Can handle simple challenges with confidence.
• Can handle simple work requirements but needs help in handling any complications or difficulties.
• Is able to reason about the context and draw sensible conclusions.

3 - Masters Able to apply the concepts in most contexts and has the experience to work without supervision.
The following describe the traits of a Level 3 individual:

• Is able to satisfy most demands and work requirements.
• Is able to speak the language of the competency's domain with ease and accuracy.
• Is able to communicate and explain his or her work.
• Is able to give and receive constructive feedback.
• Knows the limits of his or her capability and when to call on more expert advice.
• Works at a professional level with little or no guidance.

4 - Adapts Able to apply judgment on when and how to apply the concepts to more complex contexts. Can make it possible for others to apply the concepts.
The following describe the traits of a Level 4 individual:

• Is able to satisfy complex demands and work requirements.
• Is able to communicate with others working outside the domain.
• Can direct and help others working within the domain.
• Is able to adapt his or her way-of-working to work well with others, both inside and outside their domain.
  5 - Innovates A recognized expert, able to extend the concepts to new contexts and inspire others.
  The following describe the traits of a Level 5 individual:
• Has many years of experience and is currently up to date in what is happening within the domain.
• Is recognized as an expert by his or her peers.
• Supports others in working on complex problems.
• Knows when to innovate or do something different and when to follow normal procedure.
• Develops innovative and effective solutions to the current challenges within the domain.

Suggestion

Level 1 - Assists

• Description: Demonstrates a basic understanding of the concepts and follows instructions.
• Traits:
• Understands and conducts oneself professionally.
• Correctly responds to basic questions within one's domain.
• Performs most basic functions within the domain.
• Follows instructions and completes basic tasks.

Level 2 - Applies

• Description: Able to apply the concepts in simple contexts by routinely applying the experience gained.
• Traits:
• Collaborates effectively within the team.
• Satisfies routine demands and completes simple work requirements.
• Handles simple challenges with confidence.
• Manages simple work requirements but requires assistance with complications or difficulties.
• Reasons about the context and draws sensible conclusions.

Level 3 - Masters

• Description: Able to apply the concepts in most contexts and has experience working without supervision.
• Traits:
• Satisfies most demands and work requirements independently.
• Communicates fluently in the language of the competency's domain.
• Communicates and explains work clearly.
• Gives and receives constructive feedback effectively.
• Recognizes limits of own capability and knows when to seek expert advice.
• Works at a professional level with minimal or no guidance.

Level 4 - Adapts

• Description: Able to judge when and how to apply the concepts to more complex contexts and enable others to apply the concepts.
  Traits:
• Satisfies complex demands and work requirements.
• Communicates effectively with individuals outside the domain.
• Directs and assists others within the domain.
• Adapts working methods to collaborate effectively with others inside and outside the domain.

Level 5 - Innovates

• Description: A recognized expert, able to extend the concepts to new contexts and inspire others.
• Traits:
• Possesses extensive experience and remains current with developments within the domain.
• Recognized as an expert by peers.
• Supports others in addressing complex problems.
• Knows when to innovate and when to adhere to established procedures.
• Develops innovative and effective solutions to current challenges within the domain.

Jusitifcation

Avoiding personal pronouns in specifications is a standard practice that enhances technical documents' professionalism, clarity, and objectivity. Here’s why it’s important:
1. Objectivity and Impartiality - Using personal pronouns like "I," "we," or "you" can introduce a subjective tone into specifications, which are meant to be objective and impartial. Specifications should provide clear, factual information applicable to anyone using or interpreting them, regardless of personal involvement. Avoiding personal pronouns helps maintain this neutral and universal tone.
2. Professionalism - Specifications are formal documents used in professional environments. They often serve as legal or contractual bases in projects and must uphold a level of professionalism that personal pronouns can undermine. Formal language, free of personal pronouns, helps establish and maintain the professional quality of these documents.
3. Clarity and Universality - Specifications are meant to be unambiguous guidelines that anyone on a project can follow, regardless of their role. Personal pronouns can create confusion about who is responsible for certain actions or decisions. For instance, "you must install" could be unclear, whereas "the contractor must install" specifies exactly who is responsible.
4. Consistency—Technical documentation benefits greatly from consistency, which helps reduce misunderstandings. Keeping the language impersonal ensures that different parties consistently understand the document without confusion about the roles and responsibilities, which might vary from project to project.
5. Scalability and Longevity - Documents without personal pronouns are easier to scale to larger projects and retain relevance over time. They can be used and reused in different contexts and remain applicable because they don’t tie the instructions or guidelines to specific individuals or groups.
6. Legal and Compliance Clarity - In legal contexts, especially in contracts and compliance documents, clarity about who must do what is crucial. Avoiding personal pronouns helps define rights and responsibilities clearly without ambiguity, which is critical for enforceability and compliance checking.

Example

The following are examples of avoiding personal pronouns in specifications:

• With Personal Pronouns: "You must check the system for errors."
• Without Personal Pronouns: "The system must be checked for errors by the maintenance team."

Removing personal pronouns results in a specification that assigns responsibility to a specific role or entity rather than an unspecified "you," enhancing clarity and accountability.

Summary

In summary, avoiding personal pronouns in specifications ensures that the documents are objective, professional, clear, and applicable across various contexts and projects, essential for technical, legal, and operational efficacy.

Justification

Removing unnecessary instances of "that" from sentences can indeed do more than streamline the text. Here are the additional benefits:
1. Improves Readability: Cluttered sentences can slow reading speed and make comprehension more challenging. By eliminating extra "that"s, sentences become easier to read and understand quickly.
2. Enhances Professionalism: In professional or academic writing, conciseness and clarity are highly valued. Redundant words can make text appear less polished. Streamlined sentences often appear more professional and well-considered.
3. Increases Engagement: Dense, wordy text can distract readers. By making sentences crisper and more direct, you're likely to keep your audience more engaged.
4. Clarifies Focus: Each unnecessary word in a sentence can dilute its impact. By removing superfluous "that"s, you sharpen the focus of your sentences, making your main points stand out more clearly.
5. Improves Flow: Excessive wordiness can disrupt the flow of your writing. Streamlined sentences contribute to a smoother, more natural narrative flow, which can greatly enhance the reader’s experience.
6. Reduces Ambiguity: Sometimes, "that" can introduce ambiguity about which clauses it's linking or what it's referring to. Removing unnecessary instances can reduce this ambiguity, making your meaning more explicit.

Summary

While streamlining is a primary reason to cut extra "that"s from the content, the practice also contributes significantly to the overall quality of the text, affecting readability, professionalism, engagement, clarity, flow, and precision.

Justification

Avoiding passive voice in specifications is generally recommended for several reasons, each contributing to clearer, more effective communication. Here’s why it’s important:

• Clarity and Precision: Passive voice can sometimes obscure who is responsible for acting. Specifications must clarify which party or component performs each action to avoid ambiguity. Using active voice clarifies the subject's acting, making the document easier to understand and implement.
• Directness and Authority: An active voice is more direct and forceful, which helps with authoritative and decisive expression. This is particularly important in specifications where direct instructions, clear guidelines, and unambiguous directives are crucial.
• Conciseness: The active voice often requires fewer words than the passive voice, making statements more concise. In technical writing, especially specifications, conciseness helps keep documents succinct and focused, avoiding overly complex constructions that confuse the reader.
• Readability: Texts written in active voice are generally easier to read and more engaging. In specifications, where the accuracy of the implementation is critical, ensuring that the document is easy to read reduces the risk of errors in interpretation.
• Efficiency in Communication: Active voice contributes to faster and more efficient communication, which is essential in specifications. Stakeholders and team members can more quickly grasp the essential points and what is expected of them.

Examples

For example, instead of writing "The system is to be restarted by the operator," which uses passive voice, it’s clearer and more direct to say, "The operator must restart the system." This immediately clarifies who is responsible for the action and what action they must take.

Summary

In summary, using active voice in specifications ensures clarity, directness, conciseness, readability, and effective communication, all of which are vital for precisely executing tasks described in such documents.

Issues

It's just a bit hard to read.

Original Text

• A method is a composition of practices. Methods are not just descriptions for team members to read, they are dynamic, supporting their day-to-day activities. This changes the conventional definition of a method. A method is not just a description of what is expected to be done, but a description of what is actually done.

Suggestion

• A method is a composition of practices. Methods are not just descriptions for team members to read; they are dynamic and support their day-to-day activities. This changes the conventional definition of a method. A method is not just a description of what is expected to be done but a description of what is done.

Issues

The following text has a typo

Original Text

• Encourage and support incremental adoption by small and medium sized organizations by keeping the entry costs low and minimizing the barriers to adoption(e.g., starting by using "cards", the kernel or a single practice

Suggestion:

• Encourage and support incremental adoption by small and medium-sized organizations by keeping the entry costs low and minimizing the barriers to adoption (e.g., starting by using "cards," the kernel, or a single practice).

Problem

when referring to "above," it presumes the content is actually above the current location.

Original text

Still, the challenges with such practices are the same as outlined above for software engineering. The purpose of Essence is to make it easier for teams to capture, use and share such common engineering practices both locally within organizations as well as globally within the wider engineering community.

Suggested Text:

Still, software engineering challenges with such practices are originally described for software engineering. The purpose of this definition of Essence is to make it easier for teams to capture, use, and share such common engineering practices both locally within organizations and globally within the wider engineering community.

Justification

Writing specifications in the present tense is a best practice in technical documentation and requirements management for several compelling reasons:
1. Clarity and Immediacy - Writing in the present tense gives specifications a sense of immediacy and relevance. It makes the instructions and descriptions clearer and more direct as if they are universally and continually applicable. This helps to reduce confusion about when a specification or requirement should be implemented or is valid.
2. Standardization and Consistency - Using the present tense helps maintain consistency throughout a document or set of documents. Consistency in tense is crucial in specifications because it prevents the reader from having to interpret the temporal context of a requirement or instruction. This uniformity makes the documents easier to read and understand, reducing the risk of misinterpretation.
3. Future Proofing - Specifications often describe systems and processes intended to be used repeatedly over time. Using the present tense ensures that the document remains relevant and applicable regardless of when it is read. It avoids the need for future modifications to keep the language timely.
4. Simplicity and Efficiencym- Present tense is typically more straightforward and concise than other tenses. It eliminates the need for complex verb structures that can make documents more difficult to read and comprehend, particularly for non-native English speakers or technical staff without advanced linguistic training.
5. Authoritative and Definitive - The present tense can convey authority and definitiveness. It states that something is an ongoing fact, rule, or standard that adds weight to the requirements or guidelines provided in the specifications. This authoritative tone is essential for ensuring compliance and adherence to the criteria.

Example:

Past Tense: "The system was designed to handle up to 10,000 concurrent users."
Present Tense: "The system handles up to 10,000 concurrent users."

The present tense version clearly communicates an ongoing capability of the system, making it applicable at any time the specification is referenced.

In summary, using the present tense in specifications is not just a stylistic choice but a functional approach that enhances clarity, consistency, and authority of the documentation. It helps ensure that the specifications are easily understood and remain applicable over time, facilitating effective communication and implementation of requirements.

Currently the figures in the Essence 2.0 Beta 1 specification document are raster graphics directly embedded in the MS Word document. To improve figure quality and legibility, and to aid long-term maintenance of the specification, all figures and diagrams need to be converted to Vector-SVG figures, and included into the specification maintenance archive, besides replacing the figures in the actual document.

The Entry Criteria is incorrect. The spec for Activity Space Operate the System reads: "Entry Criteria: Software System::Ready".

I believe this should read "Entry Criteria: Software System::Operational".

My reasoning is as follows: The previous Activity Space "Deploy the System" reads "Entry Criteria: Software System::Ready, Completion Criteria: Software System::Operational". The Entry Criteria should match the Completion Criteria for the previous Activity Space. It also makes senses to not have both Activity Spaces active at the same time.

Second sentence under figure E.25 reads
"Milestones are shown as a vertical bar across the grid starting with an inverted triangle..."

Lines connecting to an inverted triangle and across the grid are horizontal, not vertical

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

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.

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

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 and added definitions of detail cards proposed. The detail cards represents a very important aspect of Essence to support agile approaches and in particular game playing.

See attachment for proposed updates (original link: https://www.dropbox.com/s/i69o6rr1lh3x1y3/Essence_detail_card_syntax_update_2.docx?dl=0 ).

Update the definition of detail cards

The proposed updates are agreed to.

The term "checkpoint" is loaded and used within the software industry to denote high-level checkpoints that is passed between lifecycle milestones and the like.

Suggest to rename checkpoint to "check" instead.

Retain the term "Checkpoint"

The term "checkpoint" seems colloquially and technically a better English term for items on a checklist than "check". Further, this would be a backward-incompatible change to the metamodel that would effect more than might be expected, because of the importance of checklists in Essence. Therefore, it changing the term is not considered important enough to warrent the effort of the change.

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.

Restore the diagram

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

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.

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.

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.

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.

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.

Not worth the change

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

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”.

Add new subclause

Add a new subclause describing level of detail cards.

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.”

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.

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.

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.

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”.

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.

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

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).

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

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.

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 […].”

Change wording

The correction is agreed to.

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.

Merge with ER-11

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

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

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.

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.

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).

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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”.

Add subclause 9.7.7.8.4 as requested.

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".

Agreed.

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.

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.

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

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"

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.)

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"

Agreed.

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”.

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.

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.

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.

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.

Agreed. Accept the proposed resolution.

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”

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

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.

Agreed.

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

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.

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.

The proposed solution is agreed to.

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

(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".

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

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".

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”.

Agreed. Accept proposal.

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”.

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).

Agreed.

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.

Agreed.

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.

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.

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".

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

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)".

Agreed.

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".

Agreed.

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.)

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".

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.)

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

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.)

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."

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.)

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

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.)

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.

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.)

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.

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.)

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.

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.)

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.

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”.

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.)

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

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.)

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.

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.)

Agreed that the sentence needs to be edited.

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

Agreed.

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.”

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

Agreed.

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.

The proposed solution is agreed to.

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.)

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.

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.)

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.

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”.

Agreed.