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. However, as you will learn during your journey, the other activities in software engineering—requirements, design, testing, etc.—are also fascinating for similar reasons. It has been more difficult, though, to teach these other activities in a systematic and generic manner. This is due to the fact that there are so many variations of these activities and there has not been a common ground for teaching them until now as presented in this book. You will find that most students who study in the software domain have an initial desire to work with programming. However, as these people become more and more experienced they gradually move into the other areas of software engineering. This is not because programming is not important. In fact, without programming there is no product to use and sell. No, it is because they find the other areas to be more challenging; also, success in these other areas requires more experience. By essentializing software engineering as presented in this book, the full scope of the discipline will be easier to grasp and to teach.
What Should You Now Be Able to Accomplish?
After studying this chapter, you should be able to:
• explain the terms programming, software development, and software engineering, and how they relate to each other;
• explain the difference between professional programming and hacking;
• understand how teamwork affects the dynamics of software engineering (e.g., importance of code understandability);
• explain the importance of testing as a tool to promote safe modification of existing code;
• understand how people management blends into software engineering and why it is important to consider it;
• explain the role of requirements engineering.
In order to support your learning activities, we invite you to visit www.software-engineering-essentialized.com. There one can find additional material, exercises related to this chapter, and some questions one might encounter in an exam.
In addition to this you will find a short account of the history of software engineering in Appendix A.
2
Software Engineering Methods and Practices
In this chapter we present how the way of working to develop software is organized, and to some extent what additional means are needed (e.g., notations for specifications). In particular, we
• describe the challenges in software engineering covering a wide range of aspects like how to proceed step by step, involve people, methods and practices;
• outline various key concepts of some commonly used software engineering methods created during the last four decades (i.e., waterfall methods, iterative lifecycle methods, structured methods, component methods, agile methods); and
• describe the motivation behind the initiative to create the Essence standard as a basic and extendable foundation for software engineering.
This will also take the reader briefly through the development of software engineering.
2.1 Software Engineering Challenges
From Smith’s specific single-person view of software engineering, we move to take a larger worldview in this chapter and the next. We will return to Smith’s journey in Chapter 4. From 2012–2014, the IEEE Spectrum published a series of blogs on IT hiccups.1 There are all kinds of bloopers and blunders occurring in all kinds of industries, a few of which we outline here.
• According to the New Zealand Herald, the country’s police force in February 2014 apologized for mailing over 20,000 traffic citations to the wrong drivers. Apparently, the NZ Transport Agency, which is responsible for automatically updating drivers’ details and sending them to the police force, failed to do so from October 22 to December 16, 2013. As a result, “people who had sold their vehicles during the two-month period … were then incorrectly ticketed for offenses incurred by the new owners or others driving the vehicles.” In New Zealand, unlike the U.S., license plates generally stay on a vehicle for its life.2
• The Wisconsin State Journal reported in February 2013 that “glitches” with the University of Wisconsin’s controversial payroll and benefits system had resulted in US $1.1 million in improper payments which the university would likely end up having to absorb. This was after a news report in the previous month indicated that problems with the University of Wisconsin’s payroll system had resulted in $33 million in improper payments being made over the past two years.3
These types of highlighted problems seem to be those which we can find amusing; however they are really no laughing matter if you happen to be one of the victims. What is more surprising is that the problem with these situations is that they can be prevented, but they almost inevitably do occur.
2.2 The Rise of Software Engineering Methods and Practices
Just as we have compressed Smith’s journey from a young student to a seasoned software engineer in a few paragraphs, we will attempt to compress some 50 years of software engineering into a few paragraphs. We will do that with a particular perspective in mind: what resulted in the development of a common ground in software engineering—the Essence standard. A more general description of the history is available in Appendix A.
However, the complexity of software programs did not seem to be the only root cause of the so-called “software crisis.” Software endeavors and product development are not just about programming; they are also about many other things such as understanding what to program, how to plan the work, how to lead the people and getting them to communicate and collaborate effectively.
For the purpose of this introductory discussion, we define a method as providing guidance for all the things you need to do when developing and sustaining software. For commercial products “all the things” are a lot. You need to work with clients and users to come up with “the what” the system is going to do for its users—the requirements. Further, you need to design, code, and test. However, you also need to set up a team and get them up to speed, they need to be assigned work, and they need a way of working.
These things are in themselves