through his experience at TravelEssence thus far had started to appreciate the complexities involved in producing and sustaining high-quality software that meets the needs of stakeholders. He now appreciated that while programming is an important aspect, there is much more involved. It is the engineering discipline that is concerned with all aspects of the development and sustainment of software products.
Smith then reflected upon the knowledge he had attained thus far in his career. As a student with no other experience than having done some programming, it is quite difficult to understand what more is involved in software engineering. Typically, when creating a program in a course setting, the exercise starts from an idea that may have been explained in a few words: say, less than one hundred words. Based on the idea, Smith and his classmates developed a piece of software, meaning they wrote code and made sure that it worked. After the assignment they didn’t need to take care of it. These assignments were small and to perform them they really did not need much engineering discipline. This situation is quite unlike what you have to do in the industry, where code written will stay around for years, passing through many hands to improve it. Here a sound approach to software engineering is a must. Otherwise, it would be impossible to collaborate and update the software with new features and bug fixes. Nevertheless, the experience in school is an important and essential beginning, even though Smith wished that it were more like the industry.
The authors of this book have all experienced, through their personal journeys, the importance of utilizing an engineering approach in providing high-quality software. Thus, we can characterize, for you, what is important in respect to software engineering.
Considering the software industry, let’s put the success of Microsoft, Apple, Google, Facebook, Twitter, etc. on the side because they are so unique—relying on innovative ideas that found a vast commercial market—and programming, per se, was not the root cause of their success. In a more normal situation you will find yourself employed by a company that as part of their mission needs to develop software to support their business or to sell a product needed by potential customers. The company may be rather small or very large, and you will be part of a team. The reasons you won’t be alone are many. What needs to be done is more than what one person can do alone. If the software product is large your team will most likely not be the only one; there will be many teams that have to work in some synchronized way to achieve the objectives of your company.
As a young student having spent most of your life at school and not yet working in the industry, you may be more interested in the technologies related to software—the computer, programming languages, operating systems, etc.—and less interested in the practicalities of developing commercial software for a particular business.
However, this is going to change with this book.
First, let us consider the importance of a team. The team has a role in the company to develop some software. To do that, they need to know what the users of the software need, or in other words they need to agree on the requirements. In some cases, they will receive the requirements indicating that they want software that does what another piece of software does. In these cases, the team must study the other product and do something like that product or better. In other situations, someone will just tell them what to do and be with the team while they do it. In more regulated organizations, someone (or a group of people) has written a document specifying what is believed to be some or all of the requirements. Typically, people don’t specify all the requirements before starting the development, but some requirements will be input to the team, so they can start doing something to show to the future users of the product. Interacting with users on intermediary results will reveal weaknesses and tell the team what they need to do next. These discussions may imply that the team has to backtrack and redo parts of what they have done and demonstrate the new results to the users. These discussions will also tell the team what more needs to be done.
Anyway, the team will in one way or the other have to understand what requirements they should use as input to the work of their team. Understanding the requirements is normally not trivial. It may take as much time or even more as it takes to program a solution. As we just stated, you will typically have to modify them and sometimes throw away some of the requirements as well as work results before the users of the software are reasonably satisfied with what they have received.
As a newcomer to software engineering but with some background in programming, you may think that working with requirements is less rewarding and less interesting than programming. Well, it is not. There is an entire discipline (requirements engineering) that specifies how you dig out the requirements, how you think about them to create great user experiences supported by the software, and how you modify them to improve and sustain the software. There are requirements management tools to help you that are as interesting to work with as programming tools. There are many books and other publications on how to work with requirements, so there is a lot to learn as you advance in your career. Therefore, working with requirements is one of the things to do that is more than programming but part of software engineering.
Another thing to do that is more than programming is the design of the software. Design means structuring the code in such a way that it is easy to understand, easy to change to meet new requirements, easy to test, etc. You can describe your design by using elements of a programming language such as component, class, module, interface, message, etc. You can also use a visual language with symbols for such elements that have a direct correspondence in the programming language you are utilizing. In the latter case, you use a tool to draw diagrams with symbols representing, for instance, components with interfaces. In short, you express the design in a diagram form. The visual language can be quite sophisticated and allow you to not just express your design; for example, you can do quality controls using a visual language tool as well as testing the design to some extent. Doing design is as interesting and rewarding as programming and it is an important part of software engineering.
Apart from working with requirements and creating a design, there are many other things we need to do when we engineer software. We do extensive testing of the software; we deploy it on a computer so it can be executed and used. If the software we have developed is successful, we will change it for many years to come. In fact, most people developing software are engaged in changing existing software that has been developed, often many years ago. This means we need to deal with versions of existing software and if the software has been used at many places (even around the world) we often need to have different versions of the same original software at different locations in the world. Each version will change independent of the other existing versions. And, the complexity of the software product just continues to increase. The only way to deal with this complexity is to use tools specifically designed for its purpose: testing, deployment, version and configuration control, etc.
So, you see that software engineering is certainly much more than programming. While definitions of software engineering are always a subject of debate among professionals, the following neatly summarizes our view. Software engineering is the application of a systematic, disciplined, and quantifiable approach to the development, testing, deployment, operation, and maintenance of software systems.
To us, “a systematic, disciplined, and quantifiable approach” means it is repeatable and consistent from one project to another, with continuous improvement on the way. It means it is accompanied by some form of description of the way of working and it allows us to automate more. Software engineering includes understanding what users and other stakeholders need and transforming those needs into clear requirements that can be understood by programmers. It also includes understanding the specific technologies needed to build and to test the software. It requires teams that have the social skills to work together, so each piece of the software works with other pieces to achieve the overall goal. So, software engineering encompasses the collaboration of individuals to evolve software to achieve some goal.
Programming is very rewarding since you immediately see the impact of your work.
