system), and endeavor (i.e., work, team, way of working);
• give examples of different types of stakeholders, together with their interests and concerns;
• explain the mediating role of requirements;
• name and explain the three key characteristics of software systems (i.e., functionality, quality, and extensibility); and
• explain what makes a good team.
Understanding the facets of software engineering covered in this chapter provides an overview of the main core of Essence. This core may seem fairly abstract at this point, but as you read on, you will recognize all these facets in the Essence alphas, and be able to apply them in more and more practical and detailed ways.
5
The Language of Software Engineering
The goal of this chapter is to present how the concepts discussed in the previous chapter are expressed as a language similar to how a programming language is expressed in computer science. Thus, we learn the concepts of alpha, alpha state, work product, activity, activity space, competency, and pattern, and how these concepts are expressed. We will show in this chapter
• the language constructs of Essence;
• the role of alpha states in two alphas and related checklists;
• the meaning and benefits of essentializing a practice; and
• the concept of cards as a practical way to use the various language elements of Essence.
What you learn here provides the necessary handles to use Essence in practice!
5.1 A Simple Practice Example
Essence provides a precise and actionable language to describe software engineering practices. Just as there are constructs like nouns and verbs in English, there are constructs in the Essence language in the form of shapes and icons. Just as a child learns a language by first using sentences without understanding the underlying grammar, we will introduce the Essence language through a simple pair programming practice. We choose this very simple practice because it is easily understandable even for students new to software engineering. We will introduce more sophisticated ones in later parts of the book.
We describe this programming practice as follows.
• The purpose of this practice is to produce higher quality code. In this case, we assume that the concept of code quality is understandable to the different members of the team.
Figure 5.1 Simple programming practice (pair programming) described using Essence language.
• Two persons (students) work in pairs to turn requirements into a software system by writing code together.
• Writing code is part of implementing the system.
Essence uses shapes and icons to communicate the Things to Work With, the Things to Do, and Competencies. We shall describe each of these categories in turn and at the same time demonstrate how Essence provides explicit and actionable guidance for them, delivered through associated checklists and guidelines.
Figure 5.1 shows the elements in our simple programming practice. The shapes and icons are the constructs, i.e., the “nouns” and “verbs,” in the Essence language.
These different shapes and icons each have different meanings, as quickly enumerated in Table 5.1. As the text continues, we will go into greater depth for each one of them and explain their significance.
5.2 The Things to Work With
The “things to work with” in our programming practice are requirements, software systems, and code. If you compare the icons in Figure 5.1 with their definitions in Table 5.1, you will see that two of these are alphas, but one is a work product.
Essence distinguishes between elements of health and progress, which are called alphas, versus elements of documentation, which are known as work products. Alphas are the important intangible things we work with when conducting software engineering activities. They have states to help practitioners evaluate the progress and health of their endeavor. Work products, in contrast, are the tangible things that practitioners produce when conducting software engineering activities, such as requirement specifications, design models, and code. In TravelEssence, for example, the work products include user story index cards, use case narratives, and deployment scripts. As a student, your programming assignment worksheet is an example of a tangible work product.
Table 5.1 Essence language as used in our simple programming practice
| Element Type | Syntax | Meaning of Element Type |
| Alpha |
|
An essential element of the development endeavor that is relevant to an assessment of the progress and health of the endeavor. |
| Work Product |
|
A tangible thing that practitioners produce when conducting software engineering activities. |
| Activity |
|
A thing that practitioners do. |
| Competency |
|
An ability, capability, attainment, knowledge, or skill necessary to do a certain kind ofwork. |
Alphas are not work products. Alphas are elements of the development process that we want to track the progress of. An alpha is not tangible by itself, but it is understood or described by the work products that are associated with it. Their states describe how far in the lifecycle these aspects of development have progressed.
To illustrate this, in our programming practice example, Requirements and Software System1 are alphas. Taking Requirements as our first instance: there will always be requirements for a software development endeavor, regardless of whether you document them or not, or how you document them (e.g., as requirements items, test cases, user manuals, etc.). In some cases, the requirements for an endeavor may just exist in the heads of people. However, the alpha may be evidenced by providing one or more descriptions; that is, by attaching work products to the alpha. This is not always needed but very often desirable, in particular for larger endeavors.
Software System is another example of an alpha. Similarly, there will always be a software system, regardless of techniques used and documents produced. Software System too has a work product, which is code. Code is the physical thing that you as a developer write. The computer processes the Code into a Software System. The Software System itself (the alpha) is intangible, whereas the Code (the work