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 “mini-methods” or what many people today would call practices. There are solution-related “practices,” such as work with requirements, work with code, and conduct testing. There are endeavor-related practices, such as setting up a collaborative team and an efficient endeavor as well as improving capability of the people and collecting metrics. There are of course customer-related practices, such as making sure that what is built is what the customers really want.
The interesting discovery we made more than a decade ago was that even if the number of methods in the world was huge, it seemed that all these methods were just compositions of a much smaller collection of practices, maybe a few hundred of such practices in total. Practices are what we call reusable because they can be used over and over again to build different methods.
To understand how we as a software engineering community have improved our knowledge in software engineering, we provide a description of historical developments. Our purpose with this brief history is to make it easier for you to understand why Essence was developed.
