Читать книгу The Essentials of Modern Software Engineering - Ivar Jacobson - Страница 15
Оглавление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.
4.1 Getting to the Basics
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 formed, with an appropriate way of working.
These terms map out what software engineering is about. When something goes wrong, it is normally an issue with one or more of these facets. The way we handle these issues has a direct impact on the success or failure of the endeavor. We will now look at each of these facets in turn. Later, in Chapter 6, we will once more discuss issues and their relationships.
Figure 4.1 The things involved in all development endeavors.
4.2 Software Engineering Is about Delivering Value to Customers
First, software engineering is about delivering value to customers. This value can be in improvements to existing capabilities or in providing new capabilities that are needed by the customer. (In our TravelEssence mode, customers are the users. They can be travelers or travel agents who make reservations on behalf of actual travelers.) Different customers would have different needs. If the endeavor does not deliver value, then it is a waste of time and money. As the saying goes, life is too short to build something that nobody wants!
4.2.1 Opportunity
Every endeavor is an opportunity for success or failure. It is therefore very important to understand what the opportunity is about. Perhaps you have heard of Airbnb. Airbnb started out in 2008 with two men, Brian Chesky and Joe Gebbia, who were struggling to pay rent. They came up with the idea of renting out three airbeds on their living-room floor and providing their guests with breakfast. It turned out that during that time, there was an event going on in their city and many participants weren’t able to book accommodations. Brian and Joe realized they were onto something. To cut the story short, Airbnb became a 1.3 billion USD business in 2016.
However, not all businesses grow and are successful like that. In fact, far more companies do not make it, and miss many opportunities. In fact, there has been a 90% failure rate for startups.1 Many successful companies become failures due to missed opportunities. Thus, understanding opportunities is critical.
An opportunity is a chance to do something, including fixing an existing problem. In our context, an opportunity involves building or enhancing software to meet a need. Regardless of what the opportunity is, it can either succeed or fail. It can deliver real value, or it could be something that nobody wants.
As an example, our TravelEssence model revealed that customers like to engage travel staff because of the recommendations that the staff provides. The opportunity here is that if TravelEssence can provide recommendations online through a software solution, it can provide better service to customers, thereby shortening the time customers need to make a purchase decision. Of course, whether this opportunity is truly viable depends on many factors.
Thus, when working with an opportunity it is important to continuously evaluate the viability of the opportunity as it gets implemented.
• When the opportunity is first conceived, some due diligence is necessary to determine if it truly addresses a real need or a real new idea that customers are willing to pay money for.
• It would likely be the case that different solution options are available to address the opportunity, and some difficult choices will have to be made.
• When the solution goes live, it normally takes some time before the benefits become visible to customers.
4.2.2 Stakeholders
For opportunities to be taken up, there must be some people involved in the decision. The name we have for those individuals, organizations, or groups is stakeholders. Stakeholders who have some interest or concern in the system being developed are known as external stakeholders; those interested in the development endeavor itself are called internal stakeholders. In our TravelEssence case, internal stakeholders include a development team assembled to develop the new services for travelers, along with key managers in the organization who need to agree to the new venture. Examples of external stakeholders being affected by the system include a manager in our TravelEssence organization who needs to agree to fund the new software effort, or a traveler who might benefit by using the new services.
One of the biggest challenges in a development endeavor is getting stakeholders to agree. Before that can occur, they must first be involved in some way. The worst thing that could happen is that when all is said and done, someone says, “This is not what we want.” This happens too often.
Thus, it is really important early in the endeavor to:
• understand who the stakeholders are and what their concerns are;
• ensure that they are adequately represented and involved in the process; and
• ensure that they are satisfied with the evolving solution.
4.3 Software Engineering Delivers Value through a Solution
What sets a software development endeavor apart from other endeavors is that the solution that addresses the opportunity is via a good piece of software. Nobody wants a poor-quality product. Customers’ needs are ever evolving, so the solution needs to evolve as well, and for that to happen it has to be extensible. This extensibility applies to both the requirements of the solution and the software system that realizes the requirements.
In TravelEssence, the requirements for the solution cover different usage scenarios for different kinds of customers (e.g., new travelers, frequent travelers, corporate travelers, agents, etc.). The software system involves a mix of mobile applications and a cloud-based backend.
4.3.1 Requirements
Requirements provide the stakeholders’ view of what they expect the software system to provide. They indicate what the software system must do, but do not explicitly express how it must be done. They identify the value of the system in respect to the opportunity and indicate how the opportunity will be pursued via the creation of the system.
As such, requirements serve like a medium between the opportunity and the software system. Among the biggest challenges software teams face are changing requirements. Usually, there is more than one stakeholder in an endeavor, and stakeholders will of course have different and even conflicting preferences and opinions. Even if there is only one stakeholder, he/she might have different opinions at different times. Moreover, the software system will evolve together with the requirements. What we see affects what we want. Thus, requirement changes are inevitable because the team’s understanding of what’s needed will evolve. What we want to prevent is unnecessary miscommunication and misunderstanding.
At TravelEssence, Smith encountered this when working on a discount program. The team had thought that this enhancement would be very simple. However, the stakeholders had different ideas on how long the program should last, which group of users the discount program should focus on, the impact of the discount program on reservation rates, etc. They had wanted to launch the discount program within a month’s time, yet there was a great deal of debate even to the very last hour.
Thus, how a team works with requirements is absolutely crucial, with principles like:
• ensuring that requirements are continuously anchored to the opportunity;
• organizing the requirements in a way that facilitates understanding and resolves conflicting requirements;
• ensuring that the requirements are testable, i.e., that one can verify that the software system does indeed fulfill the requirements without ambiguity; and
• using the requirements to drive the development of the software system. In fact, code needs to be well structured and easy to relate back to the requirements. Progress is measured in terms of how many of the requirements have been completed.
4.3.2 Software System
The primary outcome of a software endeavor is of course the software system itself. This software system can come in one of many different forms. It could be the app running on your mobile phone; it could be embedded in your air conditioner; it could help you register for your undergraduate program; it could tally election votes. It could run on a single machine or be distributed on a server farm in data centers or across a vast network as in the Internet today.
Whatever the case, there are three important characteristics of software systems necessary before they can be of value to users and stakeholders: functionality, quality, and extensibility.
The need to have functionality is obvious. Software systems are designed and built to make the lives of humans easier. They each must serve some functions, which are derived from the software system’s requirements.
The need for quality is easy to understand. Nobody likes a software system that is of poor quality. You do not want your word processor to crash when you are finishing your report, especially if you have not saved your work. You want your social media posts to be instantaneous. Thus, quality attributes like reliability and performance are important. Other qualities, such as ease of use or a rich user experience, are becoming more important as software systems become more ubiquitous. Of course, the extent of quality needed depends on the context itself. This again can be derived from the software system’s requirements.
The third characteristic is that of being extensible. It can be said that this is another aspect of quality, but we want to call this out separately. Software engineering is about changing and evolving the software system, from one version to the next, giving it more and more functionality to serve its users. This evolution occurs over time as a series of increments of more functionality, where every increment is described by more requirements. This is illustrated in Smith’s job at TravelEssence, which involves introducing changes to the existing travel reservation software system when TravelEssence introduces new discount programs, initiates membership subscription incentives, integrates with new accommodation providers, etc.
There are several important aspects of this evolution. First, it does not merely entail hacking or patching code into the software system. Otherwise, as the software system grows in size, it will be harder to add new functionality. Consequently, teams often organize software systems into interconnecting parts known as components. Each component realizes part of the requirements and has a well-defined scope and interface. As a student, the lessons you will learn about object orientation, etc. are about organizing the software system into manageable components.
Second, code needs to be well structured and easy to relate back to the requirements. Just as the requirements will evolve, the software system needs to be extensible to such changes.
Third, the evolution involves transitioning the software system across different environments, from the developer’s machines, to some test environment, to what is known as the production environment, where actual users will be using the software system. It is not unusual to find that software that works on the developer’s machines will have defects (or bugs) in the test or production environment. Many senior developers get irritated when they hear novices say: “But it works on my machine.” A developer’s job is not done until they system works well in the production environment. A quality software system must:
• have a design that is a solution to the problem and agreed to;
• have demonstrated critical interfaces;
• be usable, adding value to stakeholders; and
• have operational support in place.
4.4 Software Engineering Is Also about Endeavors
An endeavor is any action that we take with the purpose of achieving an objective, which in our case means both delivering value according to the given opportunity and satisfying stakeholders. Within software engineering, an endeavor involves a conscious and concerted effort of developing software from the beginning to the end. It is a purposeful activity conducted by a software team that achieves its goals by doing work according to a particular way of working.
4.4.1 Team
Software engineering involves the application of many diverse competencies and skills in a manner similar to a sports team. As such, a team typically involves several people and has a profound effect upon any development endeavor. Without the team there will be no software.
Good teamwork is essential for high performance. It creates a synergy, where the combined effect of the team is much greater than the sum of individual efforts. But getting to a high-performance state does not come naturally; instead, it results from a deliberate attempt to succeed.
To obtain this high level of performance, the team members should reflect on the way they work together and how they focus on the team goal.
Teams need to:
• be formed with enough people to start the work;
• be composed of personnel possessing the right competencies/skills;
• work together in a collaborative way; and
• continuously adapt to their changing environment.
When working in TravelEssence, Smith belonged to a development team. Although members of Smith’s team had slightly different skill sets, they collaborated to achieve the team’s goal together. Smith was particularly focused on backend technologies (i.e., the part of the software system running on the cloud), whereas Grace, a colleague, focused on front-end JavaScript and React Native technologies. (Since these technologies are not the emphasis of this book, you don’t need to know them. Moreover, technologies change rather quickly. Instead, what we want to emphasize is that effective teams have to address the opportunity presented to them to satisfy stakeholders.)
4.4.2 Work
When a team comes together to do the work of making the opportunity a reality in the software system they build, the purpose of all their efforts is to achieve a particular goal. In general, there is a limited amount of time to reach this goal: they must get things done fast but with high quality. The team members must be able to prepare, coordinate, track, and complete (stop) their work. Success in this has a profound effect upon meeting commitments and delivering value to stakeholders. Thus, the team members must understand how to perform their work and recognize if the work is progressing in a satisfactory manner. Doing the work, then, involves:
• getting prepared;
• communicating the work to be done;
• ensuring that progress and risk are under control; and
• providing closure to the work.
In TravelEssence, Smith and his team managed their work through a backlog. The backlog is a list of things to do, which originated from requirements. They communicated regularly with their stakeholders to make sure that their backlog was accurate, up-to-date, and represented the stakeholders’ priorities. In this way, they could focus on getting the right things done.
4.4.3 Way of Working
A team can perform their work in different ways and this may lead to different results. It can be performed in an ad hoc manner, meaning that you decide how to work while doing the work. For instance, while cooking a soup, you may not follow a recipe—you might decide on the fly which ingredients to use and in what order to mix and cook them together. When following an ad hoc way of working, the result may or may not be of high quality. This depends on many factors: among them, the skill of the people involved and the number of people involved in the process.
All of us are acquainted with the saying “too many cooks spoil the broth.” If too many cooks cook the soup in an ad hoc manner, the soup won’t taste good. Translating the analogy to software, if too many people participate in agreeing on how to do the job, the job will probably not be done well. There are many reasons for this. One of them is that each person has his/her own idea of how to conduct the job and, often, they do not work in an orchestrated manner.
Smith’s team addressed this issue by regularly looking at their prioritized backlog. They made sure that they correctly understood the scope of each item in the backlog, checking with stakeholders and getting feedback from them. Smith’s team regularly examined their method or, in other words, their way of working. If things did not seem right, they made changes.
It is therefore important for team members to come into some kind of consensus regarding their way of working. Disagreements about the way of working are significant barriers to team performance. You would think that coming to an agreement would be easy. The truth of the matter is that it is not. On a small scale, within a single team, there is still a need for members to agree on the foundations and principles, followed by specific practices and tools. This would of course need to be adapted to the team’s context, and evolve as the environment and needs change.
The way of working must:
• include a foundation of key practices and tools;
• be used by all the team members; and
• be improved by the team when needed.
In an industry scale, one of the things we hope to achieve through Essence is to simplify the process of reaching a common agreement. We do that at this scale by identifying a common ground or a kernel and having a way to deal with diversity of approaches. In the subsequent chapters, we will discuss the approach taken by Essence in greater detail.
In this chapter, we have introduced the following terms: opportunity, stakeholders, requirements, software system, work, team, and way of working. Essence will give these terms greater rigor and provide guidance to software teams on how to build a stronger foundation to achieve their goals.
What Should You Now Be Able to Accomplish?
After studying this chapter, you should be able to:
• list and explain the things involved in all development endeavors, related to the customer (i.e., opportunity, stakeholders), solution (i.e., requirements, software 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.
