Principles That Guide Practice

Software engineering practice has a single overriding goal- to deliver on-time, high-quality, operational software that contains functions and features that meet the needs of all stakeholders. To achieve this goal, you should adopt a set of core principles that guide your technical work. These principles have merit regardless of the analysis and design methods that you apply, the construction techniques (e.g., programming language, automated tools) that you use, or the verification and validation approach that you choose. The following set of core principles are fundamental to the practice of software engineering:

Principle 1. Divide and conquer. Stated in a more technical manner, analysis and design should always emphasize the separation of concerns (SoC). A large problem is easier to solve if it is subdivided into a collection of elements (or concerns). Ideally, each concern delivers distinct functionality that can be developed, and in some cases validated independently of other concerns.

Principle 2. Understand the use of abstraction. At its core, an abstraction is a simplification of some complex element of a system used to communicate meaning in a single phrase. When I use the abstraction spreadsheet, it is assumed that you understand what a spreadsheet is, the general structure of the content that a spreadsheet presents, and the typical functions that can be applied to it. In software engineering practice, you use many different levels of abstraction, each imparting or implying meaning that must be communicated. In analysis and design work, a software team normally begins with models that represent high levels of abstraction (e.g., a spreadsheet) and slowly refines those models into lower levels of abstraction (e g., a column Or the SUM function).

Joel Spolsky [Spo02] suggests that "all non-trivial abstractions, to some degree, are leaky. " The intent of an abstraction is to eliminate the need to communicate details. But sometimes, problematic effects precipitated by these details "leak" through. Without an understanding of the details, the cause of a problem cannot be easily diagnosed.

Principle 3. Strive for consistency. Whether it's creating a requirements model, developing a software design, generating source code, or creating test cases, the principle of consistency suggests that a familiar context makes software easier to use. As an example, consider the design of user interfaces for a WebApp. Consistent placement of menu options, the use of a consistent color scheme, and the consistent use of recognizable icons all help to make the interface ergonomically sound.

Principle 4. Focus on the transfer of information. Software is about information transfer- from a database to an end-user, from a legacy system to a WebApp, from an end-user into a graphic user interface (GUI), from an operating system to an application, from one software component to another- the list is almost endless. In every case, information flows across an interface, and as a consequence, there are opportunities for error, or omission, or ambiguity. The implication of this principle is that you must pay special attention to the analysis, design, construction, and testing of interfaces.

Principle 5. Build software that exhibits effective modularity. Separation of concerns (Principle l) establishes a philosophy for software. Modularityprovides a mechanism for realizing the philosophy. Any complex system can be divided into modules (components), but good software engineering practice demands more. Modularity must be effective. That is, each module should focus exclusively on one well-constrained aspect of the system- it should be cohesive in its function and/or constrained in the content it represents. Additionally, modules should be interconnected in a relatively simple manner- each module should exhibit low coupling to other modules, to data sources, and to other environmental aspects.

Principle 6. Look for patterns. Brad Appleton [App00] suggests that: and The goal of patterns within the software community is to create a body of literature to help software developers resolve recurring problems encountered throughout all of the software development. Patterns help create a shared language for communicating insight and experience about these problems and their solutions. Formally codifying these solutions and their relationships lets us successfully capture the body of knowledge that defines our understanding of good architectures that meet the needs of their users.

Principle 7. When possible, represent the problem and its solution from a number of different perspectives. When a problem and its solution are examined from a number of different perspectives, it is more likely that greater insight will be achieved and that errors and omissions will be uncovered. For example, a requirements model can be represented using a data-oriented viewpoint, a function-oriented viewpoint, or a behavioral viewpoint. Each provides a different view of the problem and its requirements.

Principle 8. Remember that someone will maintain the software. Over the long term, the software will be corrected as defects are uncovered, adapted as its environment changes, and enhanced as stakeholders request more capabilities. These maintenance activities can be facilitated if solid software engineering practice is applied throughout the software process. These principles are not all you'll need to build high-quality software, but they do establish a foundation for every software engineering method discussed in this book.