Leveraging Key Development Principles to Achieve Software Engineering Best Practices
This chapter is from the book
This chapter is from the book
This chapter is from the book
Practices can be adopted individually.
This book provides a set of software engineering best practices that your project can start using right away to improve the way you develop software. The practices can be adopted individually, but they also support each other. This means that you can pick a set of practices to adopt and be able to make sense of them without having to adopt all of the practices. As you adopt more and more of the practices, you will start to notice the synergy among them. Each practice becomes a piece of a puzzle, and taken together, though not complete, they constitute the backbone of a process that is iterative, agile, and scales to your project needs. See the Preface for how to use this book.
Where Do the Practices Come From?
We have chosen the best practices in this book based on principles gleaned from a huge number of successful projects and distilled into a few simple guidelines that we call key development principles (see the section Key Development Principles later in this chapter). Grouping the practices under these key development principles allows you to identify proven principles that address the issues your project is facing and review the practices supporting each principle to see how you can make progress toward adopting the principle. We will discuss the topic of adoption in more detail in Chapter 8, "Making Practical Use of the Best Practices."
These practices borrow from a large number of iterative and agile processes, all sharing a focus on iterative development; continuous integration; early and continuous testing; addressing customer needs; people and team collaboration; and minimizing process overhead.
OpenUp is an open-source version of the Unified Process. EPF is an open source process framework.
The practices capture much of the thought that was formative in the creation of the Open Unified Process (OpenUP), especially its most agile and lightweight form, OpenUP/Basic, targeting smaller and collocated teams interested in agile and iterative development. OpenUP is a part of the Eclipse Process Framework1 (EPF), an open source process framework developed within the Eclipse open source organization.2 It provides best practices from a variety of software development thought leaders and the broader software development community that cover a diverse set of perspectives and development needs. Some of the practices in the EPF may differ from the ones you find in this book, because they were produced by people with a different view of how to develop software or targeted a different type of project. This is one of EPF’s strengths: allowing diversity of ideas, while encouraging learning from each other, thereby driving unification and evolution of best practices. We believe that reading this book will help you gain insights into key aspects of OpenUP/Basic as well as EPF; see the section OpenUP/Basic later in this chapter and Appendix A for more detail.
RUP is a continually evolving process framework that extends EPF.
The key development practices also have a strong connection to RUP. RUP is a continually evolving process framework. It started in 1987 as the Objectory Process3, a use-case-driven and object-oriented process, and in 1996 was integrated with the Rational Process4, an iterative and architecture-centric process. Since 1996, it has integrated best practices from a broad set of sources, including processes for testing, configuration management, agile development, service-oriented architecture, and business engineering5. RUP extends EPF with in-depth process content for specific technologies and tools, such as J2EE and IBM tools; for specific domains, such as packaged application development, systems engineering, and program management; and for process maturity standards and frameworks, such as SEI CMMI.
Some of the practices in this book are more appropriate for projects that need to follow a higher-ceremony process, making them better reflect RUP than the lighter-weight guidance in EPF. We believe that RUP users will find the practices in this book valuable, because they articulate a clear set of principles for developing software. Unfortunately, too many RUP users do not adhere to these principles (see Key Development Principles later in this chapter) and so misinterpret the underlying spirit of RUP.
XP, Scrum, Agile Modeling, Crystal, Agile Data Method, and DSDM have influenced this book.
Other iterative and agile processes, including eXtreme Programming (XP),6 Scrum,7 Agile Modeling,8 Crystal,9 Agile Data Method,10 and Dynamic Systems Development Method (DSDM)11 have influenced the practices in this book, just as they have influenced RUP and OpenUP.