The Essentials of Modern Software Engineering. Ivar Jacobson
the book.
Finally, the following summary can be repeated 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
• It can help you, if you have challenges, to find root causes of 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 the complex discipline of 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 come into play. There is nothing wrong with that. Part of our profession is continuous 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 are 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, 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 “lite” 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 we teach here 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 have come and gone 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 the approach to teaching software engineering that we use in this book. While we do share some of the history of software engineering in Part I and in the appendix, our general approach throughout the book is a bottom-up approach instead of a top-down one. The “user” is a young student and he/she is presented with more and more advanced use cases of software development—from small systems to large systems. Or said in another way, we present the essence of software engineering through the eyes of a young student who moves from introductory courses into the 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 grow with their experiences.
So with this brief introduction, you are now ready to start your exciting journey toward the essentials of modern software engineering. During the journey, you will pass through the following.
Part I, The Essence of Software Engineering. Here, we introduce the student to software engineering and to the Essence standard.
Part II, Applying Essence in the Small. Here, 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 given team members 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 III, Small-Scale Development with Practices. We use practices defined on top of the kernel to provide further guidance to small teams.
Part IV, 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://software-engineering-essentialized.com, you are provided with additional training material and exercises associated with each part of the book. This website will be continuously updated and will provide you with additional insight. As you gain experience, we hope you will also be able to contribute to this growing body of knowledge.
How This Book Can Free the Practices from the Method Prisons and Why This Is Important
In 1968, more than 50 years ago, the term software engineering was coined to address the so-called software crisis. Thousands of books have been written since then to teach the “best” method as perceived by their authors. Some of them have been very successful and inspired a huge number of teams to each create their own method. The classical faith typically espoused by all these popular methods has been that the previous popular method now has become completely out of fashion and must be replaced by a new, more fashionable method. People have been swinging with these trends and, apart from learning something new, each time they must also relearn what they already knew but with just a new spin to it.
The problem is that among all these methods there has been almost nothing shared, even if in reality much more has been shared than what separated them. What they shared was what we will call practices—some kind of mini-methods. Every method author (if very successful, each became a guru) had their own way of presenting their content so that other method authors couldn’t simply reuse it. Instead, other authors had to reinvent the wheel by describing what could have been reusable—the practices—in a way that fit these other authors’ presentation styles. Misunderstandings and improper improvements happened and the method war was triggered. It is still going on. Instead of “standing on one another’s shoulders,” these various authors are “standing on one another’s toes.”