target="_blank" rel="nofollow" href="#ucea95eac-2318-5a2a-8abc-2bf74e716718">Chapter 22Foreword by Ian Sommerville
There’s some debate over whether the term software engineering was first coined by Margaret Hamilton at NASA in the 1960s or at the NATO conference at the end of that decade. It doesn’t really matter because 50 years ago it was clear that software engineering was an idea whose time had come.
Since then, developments in software engineering have been immense. Researchers and practitioners have proposed many different methods and approaches to software engineering. These have undoubtedly improved our ability to create software, although I think it is fair to say that we sometimes don’t really understand why. However, we have no basis for comparing these methods to see if they really offer anything new and we can’t assess the limitations of software engineering methods without experiencing failure. Although we are a lot better at developing software than we were in the 20th century, it is still the case that many large software projects run into problems and the software is delivered late and fails to deliver the expected value.
The SEMAT initiative was established with the immense ambition to rethink software engineering. Rather than inventing another new method, however, Ivar Jacobson and his collaborators went back to first principles. They examined software engineering practice and derived a common underlying language and kernel (Essence) that could be used for discussing and describing software engineering. Essence embodies the essential rather than the accidental in software engineering and articulates new concepts such as alphas that are fundamental to every development endeavor.
Essence is not a software engineering method but you can think of it as a meta-method. You can use it to model software engineering methods and so compare them and expose their strengths and weaknesses. More importantly, perhaps, Essence can also be the starting point for a new approach to software engineering. Because of the universality of the concepts that it embodies, Essence can be used across a much wider range of domains than is possible with current methods. It wisely separates the notion of specific practices, such as iterative development, from fundamental concepts so it can be used in a variety of settings and application domains.
The inventors of Essence understand that the value of Essence can only be realized if it is widely used. Widespread use and experience will also expose its limitations and will allow Essence to evolve and improve. This book is an important contribution to transferring knowledge about Essence from specialists to a more general audience. Although notionally aimed at students, it provides an accessible introduction to Essence for all software engineers.
Organized into four parts, the first three parts focus squarely on using Essence as a means of thinking about, planning, and describing software development. Using real but manageable examples, Parts I and II of the book cover the fundamentals of Essence and the innovative use of serious games to support software engineering. Part III explains how current practices such as user stories, use cases, Scrum, and microservices can be described using Essence and shows how their activities can be represented using the Essence notions of cards and checklists. Part IV is perhaps more speculative but offers readers a vision of how Essence can scale to support large, complex systems engineering.
Software engineering has been both facilitated and hampered by the rate of technological innovation. The need to build software for new technologies has led to huge investment in the discipline but, at the same time, has made it difficult to reflect on what software engineering really means. Now, 50 years on, Essence is an important breakthrough in understanding the meaning of software engineering. It is a key contribution to the development of our discipline, and I’m confident that this book will demonstrate the value of Essence to a wider audience. It, too, is an idea whose time has come.
Ian Sommerville
Emeritus Professor of Software Engineering at St. Andrews University, Scotland. For more than 20 years, his research was concerned with large-scale complex IT systems. He is the author of a widely used textbook on software engineering, titled Software Engineering, first published in 1982, with the 10th edition published in 2015.
Foreword by Grady Booch
The first computers were human; indeed, the very noun “computer” meant “one who computes or calculates” (and most often those ones were women).
My, how the world has changed.
Computing has woven itself into the interstitial spaces of society. Softwareintensive systems power our cars and airplanes; they serve as our financial conduits; they track our every action; they fight our wars; they are as intimate as devices we hold close to us or even within us and as grand as the wanderers we have flung into space and that now inhabit other planets and venture to other stars. There is no other invention in the history of humanity that has such a potential to amplify us, diminish us, and perhaps even replace us.
I have often observed that the entire history of software engineering can be characterized as the rising levels of abstraction. We witness this in our programming languages, in our tools, in our frameworks, in the very ways with which we interact with software-intensive systems … and even in the ways in which we craft these systems. This is the world of software engineering methods.
I am proud and humbled to call myself a friend of Ivar Jacobson. The two of us, along with Jim Rumbaugh, were at the center of a sea change in the way the world develops and deploys software-intensive systems. We got some things right; we got some things wrong. But, most important, we helped to codify the best practices of software engineering in their time. Indeed, that was an incredibly vibrant time in the history of software engineering, wherein many hundreds if not thousands of others were struggling with how to codify the methods by which systems of importance could best be built.
The nature of software development has changed—as it should and as it will again—and even now we stand at an interesting crossroads in the field. Agile methods have proven themselves, certainly, but we are at the confluence of technical and economic forces that bring us again to a very vibrant point in time. As the Internet of Things brings computing to billions of devices, as computational resources grow in unceasing abundance, and as deep learning
