The Essentials of Modern Software Engineering. Ivar Jacobson

Чтение книги онлайн.

Читать онлайн книгу The Essentials of Modern Software Engineering - Ivar Jacobson страница 18

Автор:
Жанр:
Серия:
Издательство:
The Essentials of Modern Software Engineering - Ivar Jacobson ACM Books

Скачать книгу

first have to learn “all” there is to say about the subject.

      These essentials are usually just a small fraction of what an expert knows about a subject—we suggest 5%—but with the essentials you can participate in conversations about your work without having all the details. It helps to grow T-shaped people—people who have expertise in a particular field, but also broad knowledge across other fields. Such people are what the industry needs as work becomes more multi-disciplinary. Once you have learned the essentials it is relatively straightforward to find out more by yourself from different sources.

      Some teams and organizations need more than the essentials, so different levels of details must be made optional.

      Many books have been written to teach software engineering. Some people interested in learning about ideas and trends in this space read these books, but the vast majority of software development practitioners don’t—not even if they have bought the books. Thus, textbooks are not the best way to teach practices to practitioners. Modern method-authors have taken a different approach by presenting their methods as a navigable website.

      Essence has taken a different approach by providing a hands-on, tangible user experience focused on supporting software professionals as they carry out their work. For example, the kernel can be accessed (and actually touched) through the use of cards (see Figure 3.5). The cards provide concise reminders and cues for team members as they go about their daily tasks. By providing practical check-lists and prompts, as opposed to conceptual discussions, the kernel becomes something the team uses on a daily basis. This is a fundamental difference from traditional approaches, which tend to emphasize method description over method use and tend to be consulted only by people new to the team.

Image

      Cards have proven to be a lightweight and practical way to remember, but also to use in practice in a team. They make the kernel and the practices easy to digest and use. For this reason, throughout the book we will use cards to present elements in the kernel and in practices.

      After studying this chapter, you should be able to

      • name the key elements of Essence;

      • distinguish between a practice and a method (give some examples of both);

      • explain the concept of composition as a key technique to build methods using practices (and to support extensibility in Essence);

      • explain the concept of tacit vs. explicit practices;

      • explain the role of capability and background in deciding how explicit a practice should be; and

      • explain the layered architecture of Essence and its elements.

      Again, we point to additional reading, exercises, and further material at www.software-engineering-essentialized.com.

      Given that the reader is now equipped with ability to distinguish essential (i.e., the important) steps/aspects/decisions from those of minor importance, more knowledge can now be gained by proceeding in a given project and by working on the project with other people/stakeholders involved.

      4

       Identifying the Key Elements of Software Engineering

      The goal of this chapter is to present the key elements of the development endeavor, which later become “alphas,” the building blocks of Essence—the things we work with when developing software. In this chapter, we discuss

      • the key elements within software engineering that deliver value to the customer;

      • the key elements in software engineering that are related to the targeted solution and development endeavor; and

      • the role and importance of different stakeholders, requirements, and team composition.

      This knowledge will help us to lay out a model of software engineering with areas of concern and key elements, which will create the basis for our understanding of Essence. To understand this model in practical application, we now rejoin Smith in his journey into software development.

      After Smith had been working in the software industry for several years, he had his fair share of ups and downs. He wished there were more ups than downs. Without a doubt, software engineering is a creative process, but Smith had come to recognize that there are some fundamental basics—some things to be mindful of, to avoid making unnecessary mistakes.

      Smith’s colleagues also recognized that, but they had difficulty articulating these fundamentals due to their different backgrounds, experience, and, consequently, the different terms they used. It seemed that every time a new team was formed, members had to go through a “storming and norming” process to iron out these terms before starting to deal with the challenges.

      If you have been in the software industry for some time, you can empathize with Smith. For students new to software engineering, we want you to appreciate the complexities of a software development endeavor as you read this chapter and compare that against the complexities of your class, or of project assignments that you have worked on.

      Essence was developed to help people like Smith and companies like Travel-Essence who rely heavily on software to run their business. What the contributors to Essence did was to lay down the foundation of software engineering for folks like Smith and yourself to cut short this startup period and ensure health and speed as your software development endeavors progress. The term health is discussed and defined later on for the area of software development. See, for example, Chapter 11 for a more detailed discussion.

      Let’s begin with some commonly used terms found in software engineering, which we will briefly introduce in italics. Regardless of size and complexity, all software development endeavors involve the following facets (see Figure 4.1):

      • There are customers with needs to be met.

      ■ Someone has a problem or opportunity to address.

      ■ There are stakeholders who use and/or benefit from the solution produced, and some of these will fund the endeavor.

      • There is a solution to be delivered.

      ■ There are certain requirements to be met.

      ■ A software system of one form or another will be developed.

      • There is an endeavor to be undertaken.

      ■ The work must be initiated.

      ■ An empowered team of competent people must be

Скачать книгу