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’
