Читать книгу The Essentials of Modern Software Engineering - Ivar Jacobson - Страница 10

Preface

We have developed software for many years, clearly more than 50 years. Thousands of books and manymore papers have been written about how to develop software. Almost all teach one particular approach to doing it, one which the author thinks is the best way of producing great software; we say each author has canned his/her method. Most of these authors 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 ready to impose your own true way of doing it, all other top experts in the world seem to be in agreement that this proprietary approach is not the way to teach software development to students.

You now have in front of you a book that will teach you modern software engineering differently 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 that you create is easy to learn (intuitive), easy to adopt (by a team), easy to change (as you learn more), and fun to work with thanks to its user experience being based on games and playing cards.

It is worth repeating: This book does not primarily teach you one particular way of developing great software; rather, it teaches you how to create such a way of working that 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 has been made 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.¹

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 challenges, 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 gone deeper into 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.²

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

This book will show how reusable practices can be liberated from the methods that use them—their method prisons. Free the practices from the method prisons!

Acknowledgments

Special thanks and acknowledgment goes to Svante Lidman and Ian Spence for their work on the first Essence book [Jacobson et al. 2013a], from which some pieces of text have been used, to Mira-Kajko-Mattson for her role in the original shaping of this book, to Pontus Johnson for his work on theory in Part I, Chapter 7 and to Barbora Buhnova for in particular her clear and accurate writing of the goal and the accomplishments paragraphs in each chapter of the book. All these contributions improved the clarity of the book as a whole.

The authors also want to recognize and thank all the people that worked with us in creating the OMG Essence standard and in working on its use cases. Without these individuals’ work this book would never have been written:

• For founding the SEMAT (Software Engineering Method And Theory) community in 2009 and later leading it: Apart from Ivar Jacobson, the founders were Bertrand Meyer and Richard Soley. June Park chaired the SEMAT community from 2012 to 2016 and Sumeet Malhotra from 2016 until now.

• For serving as members of the Advisory Board chaired by Ivar Jacobson: Scott Ambler, Herbert Malcolm, Stephen Nadin, Burkhard Perkens-Colomb.

• For supporting the foundation of the SEMAT initiative and its call for action:

■ Individuals: Pekka Abrahamsson, Scott Ambler, Victor Basili, Jean Bézivin, Robert V. Binder, Dines Bjorner, Barry Boehm, Alan W. Brown, Larry Constantine, Steve Cook, Bill Curtis, Donald Fire-smith, Erich Gamma, Carlo Ghezzi, Tom Gilb, Robert L. Glass, Ellen Gottesdiener, Martin Griss, Sam Guckenheimer, David Harel, Brian Henderson-Sellers, Watts Humphrey, Ivar Jacobson, Capers Jones, Philippe Kruchten, Harold “Bud” Lawson, Dean Leffingwell, Robert Martin, Bertrand Meyer, Paul Nielsen, James Odell, Meilir Page-Jones, Dieter Rombach, Ken Schwaber, Alec Sharp, Richard Soley, Ian Sommerville, Andrey Terekhov, Fuqing Yang, Edward Yourdon.

■ Corporations: ABB, Ericsson, Fujitsu UK, Huawei, IBM, Microsoft Spain, Munich RE, SAAB, SICS, SINTEF, Software Engineering Institute (SEI), Tata Consulting Services, Telecom Italia, City of Toronto, Wellpoint.

■ Academics: Chalmers University of Technology, Florida Atlantic University, Free University of Bozen Bolzano, Fudan University, Harbin Institute of Technology, Joburg Centre for Software Engineering at Wits University, KAIST, KTH Royal Institute of Technology, National University of Colombia at Medellin, PCS—Universidade de São Paulo, Peking University, Shanghai University, Software Engineering Institute of Beihang University, Tsinghua University, University of Twente, Wuhan University.

• For developing what eventually became the Essence standard with its use cases and for driving it through the OMG standards process: Andrey Bayda, Arne Berre, Stefan Bylund, Dave Cuningham, Brian Elvesæter, Shihong Huang, Carlos Mario Zapata Jaramillo, Mira Kajko-Mattson, Prabhakar R. Karve, Tom McBride, Ashley McNeille, Winifred Menezes, Barry Myburgh, Gunnar Overgaard, Bob Palank, June Park, Cecile Peraire, Ed Seidewitz, Ed Seymour, Ian Spence, Roly Stimson, Michael Striewe.

• For organizing SEMAT Chapters around the world: Doo-Hwan Bae, Steve Chen, Zhong Chen, Barry Dwolatsky, Gorkem Giray, Washizaki Hironori, Debasish Jana, Carlos Mario Zapata Jaramillo, Pinakpani Pal, Boris Pozin.

• For co-chairing the “Software Engineering Essentialized” project with Ivar Jacobson: Pekka Abrahamsson. This project develops training material, quizzes, exercises, certification, games, essentialized practices, etc. to support teachers giving classes based on this book.

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 received 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, Winifred Menezes, Marcello Missiroli, 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, Armando Augusto Cabrera Silva, Kotrappa Sirbi, 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.

As you can see from these acknowledgments, many people have contributed to where we are today with Essence and its usage. Some people have made seminal technical contributions without which we wouldn’t have been able to create a kernel for software engineering. Some other people have contributed significant time and effort to move these technical contributions into a high-quality standard to be widely adopted. Some people have been instrumental in identifying the vision and leading the work through all the pitfalls that an endeavor can encounter when it is as huge as the SEMAT in fact is. Finally, some people have made huge efforts and with high passion marketed the work and the result to break through the barriers that fundamentally new ideas always face. We have not made an effort to rank all these contributions here, but we hope all these individuals are assured that we know about them and we are tremendously grateful for all they have done.

We would also like to thank the team at Windfall Software for carefully copy editing and preparing the content of this book. We are especially grateful to their professional developmental editor, who was instrumental in this endeavor and put in a huge effort to achieve this high-quality result.

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.