Preface

We have developed software for many years, clearly more than 50 years. Thousands of books and many more papers have been written about how to do it. Almost all teach one particular approach to do it, which the author thinks is the best way of getting great software; we say the author has canned his/her method. Most of them have some interesting ideas, but none can help you in all the circumstances you will be faced with when you develop software. Even the most modern books take this approach of presenting and selling “the one true way” of doing it. Unless you are a world leader with your own true way of doing it, all other top experts in the world seem to be in agreement that this is not the way to teach students software development and the engineering discipline that comes from it – software engineering.

You now have in front of you a book that will teach you modern software engineering different from how the subject has been taught since its infancy. On one hand it stands on the shoulders of the experience we have gained in the last 50 years or more. On the other hand, it teaches the subject in a universal and generic way. It doesn’t teach you one particular way of developing software, but it teaches you how to create one way of working that matches your particular situation and your needs. The resulting way of working you create is easy to learn (intuitive), easy to adopt (by a team), easy to change (as you learn more), and it is fun to work with thanks to its user experience based on games and playing cards.

It is worth repeating: The book doesn’t primarily teach you one particular way of developing great software, but it teaches you how to create such a way of working which should result in great software.

How this Book is Different from other Software Engineering Textbooks

On the surface this book looks like most other books in software engineering (and there are many of them; some are excellent books). It describes many important aspects of software engineering and how a typical software engineering initiative resulting in a new or improved software product takes place. However, underneath the surface, this book is fundamentally different. The things being described are selected because they are prevalent in every software engineering initiative. They are the essential things to work with, the essential things to do, and the essential competencies needed when you develop software. They are not just examples of things or typical things. They are selected because they are the things that underpin all recognized ways of developing software. The selection is done by a group of experts from around the world representing academia, research and industry under the auspices of an international group called Object Management Group that gave rise to the Essence standard[1].

Essence addresses first and foremost a number of serious challenges we have in the software industry today, one of which is that for 50 years we have had a war between the canned methods, but there are many more which we will discuss in the book. In addressing these issues Essence has made it possible to systematically improve the way we work which should result in better software, faster and cheaper. However, this will have to wait to be discussed until you have got deeper into the book.
Finally, it can to be said over and over again:

  • Essence supports people when working with methods and it helps people while they actually work developing software.
  • Essence is not yet another method. It is many things but not a method competing with any other method.
  • It is a foundation to be used to describe methods effectively and efficiently.
  • It is a thinking framework to be used when creating your method or using your method whether it is explicit or tacit.
  • It can help you in a method agnostic way to measure progress and health in your endeavor[2], and
  • It can help you, if you have challenges, to find root causes to the problems with your endeavor.

 

How this Book can help Students

If you are a student this book will play a significant role in your career because from this book you will learn the fundamentals of a complex discipline, software engineering. Even if you are not a student you will rediscover your discipline in a way you never expected. This is no ordinary software engineering textbook. What you will learn from this book you can take with you wherever you go for the rest of your software engineering career.

Other books will help you learn the latest technologies, practices and methods. While you will need that kind of information as you go through your career their value will fade over time as new technologies, practices and methods are coming into play. There is nothing wrong with that. Part of our profession is continual improvement and we encourage and expect that to go on forever.

What you will learn from this Book

So that you have the right expectations, we want to tell you what you can expect to learn from this book.

  • You will learn what is the essentials of software engineering presented as a common ground.
  • You will learn a simple, intuitive language by which you can describe specific ways of working, so called practices, using the common ground as a vocabulary.
  • You will learn how the common ground can be used to assess the progress and health of your software development endeavors no matter how simple or complex.
  • You will learn light versions of a number of practices that are popular at the time of writing this book, but they are only meant as examples to demonstrate how to use the common ground and the language to describe practices.
  • You will learn how to improve your way of working by adding or removing practices as and when the situation demands.
  • You will learn how to improve communication with your teammates.

To be clear this is what you won’t learn from this book:

  • You will not learn any fully developed practices to be used in a real endeavor (in a commercial production environment), since what they teach is not intended for that purpose. To learn practices that will work in such an environment you need to go to practice libraries such as the Ivar Jacobson International practice library (https://practicelibrary.ivarjacobson.com/start), or if the practices are not yet essentialized, you will have to go to books or papers written about these practices.
  • You will not learn the latest technologies, practices and methods.

This book is about learning a foundation that underlies all practices and methods that came and went during the last 50 years, and all that will likely come and go over the next 50 years.

What you learn from this book you can take with you and it will continue to help you grow throughout your software engineering career.

Our Approach to Teaching in this Book

We also want to share with you a little bit about our approach to teaching software engineering that we use in this book. While we do share some history of software engineering in part 1 and in an appendix, our general approach throughout the book is a bottom up approach instead of a top down. The “user” is a young student and he/she is presented more and more advanced use cases of software development – from small systems to large systems. Or said in another way we will present the essence of software engineering through the eyes of a young student as he/she moves from the introductory courses to industry. This approach will help you understand how software engineering is often first viewed by new software developers and how their perceptions and understanding of software engineering grows with their experiences.

So with this brief introduction you are now ready to start your exciting journey toward “software engineering essentialized”.  During the journey, you will pass through the following:

  • Part 1 - The Essence of Software Engineering. In this part, we introduce the student to software engineering and to the Essence standard.
  • Part 2 – Applying Essence in the small. In this part Essence is first used to carry out some simple, small, but very useful practices. They are so small that they could be called mini-practices, but we call them games – serious games. They are highly reusable when carrying out practices resulting in for instance software products.
    Then in the rest of this part we advance the problem and consider building some real, but rather small software. We make the assumption that the teams have worked together before, so they have tacit knowledge about the practices they use and don’t need any additional explicit guidance in the form of described practices.
  • Part 3 – Small Scale Development with Practices. We use practices defined on top of the kernel to provide further guidance to small teams.
  • Part 4 – Large Scale Complex Development. To describe how to develop large software systems is far too complex for a textbook of this kind. However, we do explain the impact large teams and organizations have on the practices needed and how they are applied. 
  • Appendix - A Brief History of Software Engineering.

On our website http://semat.org/web/book/ you are provided with additional training material and exercises associated with each part of the book.  This website will be continually updated and will provide you with additional insight. As you gain experience, hopefully you will also be able to contribute to this growing body of knowledge.

 

Acknowledgements

From the outset of the writing of this book, the authors were aware of the fundamental change they proposed to the education in software engineering. Therefore, they wanted the book to be meticulously reviewed before publication. The book has been reviewed in 5 phases each being presented as a draft.  About 1000 comments have been given by more than 25 reviewers and each comment has been discussed and acted upon. We are very grateful for the help we have got from the following people (alphabetically ordered) in making this a book we are very proud of: Giuseppe Calavaro, A.Chamundeswari, Görkem Giray, Emanuel Grant, Debasish Jana, Eréndira Miriam Jiménez Hernandez, Reyes Juárez-Ramírez, Marcello Missiroli, Winifred Menezes, Barry Myburgh, Anh Nguyen Duc, Hanna Oktaba, Don O'Neill, Gunnar Overgaard, Pinakpani Pal, Cecile Peraire, Boris Pozin, Antony Henao Roqueme, Anthony Ruocco, Vladimir Savic, Kotrappa Sirbi, Armando Augusto Cabrera Silva, Nebojsa Trninic, Hoang Truong Anh, Eray Tüzün, Murat Paşa Uysal, Ervin Varga, Monica K. Villavicencio Cabezas, Bernd G. Wenzel, Carlos Mario Zapata Jaramillo.

 

[1] Essence has been likened to the DNA of software engineering or the periodic table in chemistry.

[2] Throughout this book, except for the cases where the term project is more appropriate for historical reasons, we use the term endeavor.  This is because not all software development occurs within the context of a formal project.