Читать книгу The Essentials of Modern Software Engineering - Ivar Jacobson - Страница 16

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

Figure 5.3 Requirements alpha state cards.

The other alpha in our example, the Software System, has the states shown in Figure 5.4.

The states are defined on the basis of an incremental risk-driven approach to building the Software System, first by establishing a sound architecture, and then by demonstrating key decisions about the Software System. These states are summarized as follows.

Figure 5.4 Software System alpha card.

Architecture Selected. Key decisions about the Software System have been made. For instance, the most important system elements and their interfaces are agreed upon.

Demonstrable. Key use of the Software System has been demonstrated and agreed.

Usable. The Software System is usable from the point of view of its users.

Ready. The Software System has sufficient quality for deployment to production, and the production environment is ready.

Operational. The Software System is operating well in the production environment.

Retired. The Software System is retired and replaced by a new version of the Software System, or by a separate Software System.

5.2.3 Work Products

Work products, again, are tangible things such as documents and reports, and may provide evidence to verify the achievement of alpha states. An example of a work product for the Requirements alpha might be some kind of a requirements specification—a description of the software system to be built. When a complete and accepted requirements document has been developed, it can be one way to confirm having achieved certain checklists within a state of the Requirements alpha. Yet the fact that you have a document is not necessarily a sufficient condition to prove evidence of state achievement. Historically, documentation has not always provided an accurate measurement of progress. Thus, you may reach the same state without any documentation or with very brief documentation, as long as the checklist for that state has been achieved satisfactorily.

Figure 5.5 The Code work product card.

Code is the example of a work product for our programming practice. We provide a concise description of this work product in the form of a poker-sized card, as shown in Figure 5.5.

Note that the work products you produce do not belong to the common ground represented by the Essence standard. They are dependent on how you want to work (which practices you want to use). Thus, Essence does not specify exactly which work products are to be developed, but it does precisely specify what work products are, how you represent them, and what you can do with them.

Work products can have different levels of detail. In a development endeavor, the degree of detail needed in work products can vary greatly, depending on many factors such as past history of team members working together, customer requirements, regulatory requirements (e.g., regulation for software validation of medical devices), and organizational policies.

In TravelEssence, for example, Smith’s team expressed requirements through use case narratives, which we will cover in Part III. These also have different levels of detail. For simple requirements, Smith’s team did not need as many specifics, but relied on more direct communication with their stakeholders. However, for more sophisticated requirements involving complicated calculation and decision rules, Smith had more complete explanations in his use case narratives.

Practitioners often have trouble figuring out how detailed the various work products they produce should be. Explicit practices, which we will cover in later parts of the book, can provide guidance on this.

5.3 Competencies

The team members applying the programming practice must, of course, be able to program; that is, they must have a development competency. Competencies are the abilities needed when applying a practice. Often, software teams struggle because they don’t have all the abilities needed for the task they have been given. In these situations, a coach can help by explaining different ways the practitioner can address the problem, such as learning something that is missing in their competencies.

Figure 5.6 shows the card for the Development competency. Similar in format to the alpha and work product cards, the top of a competency card has the competency icon (a star) and the competency name followed by a very brief description of the competency. Then a list of competency levels follows.

Figure 5.6 The Development competency card.

The Development competency has five levels of achievement.

1. Assists. Demonstrates a basic understanding of the concepts and can follow instructions.

2. Applies. Able to apply the concepts in simple contexts by routinely applying the experience gained so far.

3. Masters. Able to apply the concepts in most contexts and has the experience to work without supervision.

4. Adapts. Able to apply judgment on when and how to apply the concepts to more complex contexts. Can enable others to apply the concepts.

5. Innovates. A recognized expert, able to extend the concepts to new contexts and inspire others.

Teams should be encouraged to conduct a self-assessment of their competencies and compare the results to the competencies they believe they need to accomplish their specific endeavor. This useful exercise can help software teams objectively determine any competency gaps they may have, which they can raise to management for resolution before serious problems occur that could hurt their team’s performance.

5.4 Things to Do

To make progress in a development endeavor, or for that matter, any endeavor, all participants must do something. In our programming practice, this concerns writing code. The Essence language calls this an activity.

5.4.1 Activities

Activities are things that practitioners do, such as holding a meeting, analyzing a requirement, writing code, testing, or peer review. Similar to the challenges practitioners often face with determining the appropriate level of detail in work products, they also often struggle to determine the appropriate degree of detail or formality with an activity, or exactly how to go about conducting it. This is another motivation to specify explicit practices as they can provide guidance to practitioners in selecting appropriate activities, as well as in how to go about conducting each activity. A practice may include several activities that are specific to the practice being described. Thus, activities are specific and not standard—they are not a part of Essence. Figure 5.7 shows the activity card for Write Code. Its icon is an arrowed pentagon. (The activity space concept will be described in the next section.)

Figure 5.7 The Write Code activity card.

An activity is always bound to a specific practice and cannot “float around” among the practices. If you find an activity that needs to be reused by many practices, then you may want to create a separate practice including this activity. The alternative is that you decide not to reuse it, but each practice that potentially could have reused it will have to keep its own copy of that activity. Changes to one copy of it will not impact the other copies; they will just change independently of one another, which means no reuse.

5.5 Essentializing Practices