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 product) is tangible.
We will develop these concepts throughout the book, but for now focus in a bit more on each of these differentiated Things to Work With.
5.2.1 Alphas
Alphas, again, are aspects of a software endeavor whose evolution we want to understand, monitor, direct, and control. Why are they called alphas? The developers of Essence, in searching for a word to describe these important key elements, chose the word alpha, which has been used to denote important elements such as a position in a social hierarchy or the first (often the brightest) star in a constellation (examples from Wikipedia). The alphas bound the work to be accomplished in progressing toward the provisioning of the software system. Alphas are portrayed as an icon that is a stylized variant of the first letter of the Greek alphabet (see Figure 5.1 and Table 5.1).
Simply put, alphas are the most important things you must attend to and progress in order to be successful in a development endeavor.
Although an alpha is commonly understood or evidenced by one or more associated work products (which thus describe particular aspects of it), it is not tangible by itself, so there must at least be tacit knowledge linked to each alpha. One form of this knowledge is the alpha’s state.
5.2.2 Alpha States
Alphas have states that describe progression through a lifecycle. As an example, Essence defines the states of the Requirements alpha as follows.
Conceived. The need for a new system has been agreed upon.
Bounded. The purpose and theme of the new system are clear.
Figure 5.2 Requirements alpha card.
Coherent. The requirements provide a consistent description of the essential characteristics of the new system.
Acceptable. The requirements describe a system that is acceptable to the stakeholders.
Addressed. Enough of the requirements have been addressed to satisfy the need for a new system in a way that is acceptable to the stakeholders.
Fulfilled. The requirements have been addressed to fully satisfy the need for a new system.
To help remember the states of the Requirements alpha, Essence provides a poker card description, as shown in Figure 5.2. As we will discuss later, such poker-sized cards will also serve as teaching tools, and even make software engineering more fun through games.
Let’s consider the layout of the card. At the top left, you see the icon representing an alpha. This distinguishes it as an alpha card rather than a work product card, competency card, or any other element. The top of the card also highlights the name of the element—in this case, the Requirements—followed by a brief description of the alpha and the states of the alpha. (This is a very concise overview of the requirements alpha. For more details, refer to the Essence specification.)
Cards are also available for each alpha state, as shown in Figure 5.3, which shows six cards, one for each of the Requirements alpha states. The layout of each of these cards comprises the alpha icon and … by the standard. (These abbreviations make it possible to fit the checklists on the cards for easy, quick reference. If you do not find them to be fully understandable, you should refer to the full checklists in the Essence Quick Reference Guide, available for download from www.software-engineering-essentialized.com.)
