The Essentials of Modern Software Engineering. Ivar Jacobson

Чтение книги онлайн.

      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.¹ 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.²

      • 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.³

      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.