The Essentials of Modern Software Engineering. Ivar Jacobson

The Essentials of Modern Software Engineering - Ivar Jacobson


Скачать книгу
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.

      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.


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