1.1 On quality
It helps to have a clear definition of expectations. For these expectations, we’ll rely on the ISO 25010 standard to define quality goals for each project. For more details, see https://iso25000.com/index.php/en/iso-25000-standards/iso-25010.
The ISO/IEC 25010:2011 standard describes Systems and software Quality Requirements and Evaluation (SQuaRE). This standard provides eight characteristics of software. These characteristics are as follows:
Functional suitability. Does it do what we need? It is complete, correct, and appropriate for the user’s expressed (and implied) needs? This is the focus of each project’s description.
Performance efficiency. Does it work quickly? Does it use the minimum resources? Does it have enough capacity to meet the user’s needs? We won’t address this deeply in this book. We’ll talk about writing performance tests and ways to address performance concerns.
Compatibility. Does it co-exist with other software? Does it properly interoperate with other applications? To an extent, Python can help assure an application interoperates politely with other applications. We’ll emphasize this compatibility issue in our choices of file formats and communication protocols.
Usability. There are a number of sub-characteristics that help us understand usability. Many of the projects in this book focus on the command-line interface (CLI) to assure a bare minimum of learnability, operability, error protection, and accessibility. A few projects will include a web services API, and others will make use of the GUI interface of JupyterLab to provide interactive processing.
Reliability. Is it available when the users want it? Can we detect and repair problems? We need to make sure we have all of the parts and pieces so we can use the software. We also need to make sure we have a complete set of tests to confirm that it will work.
Security. As with usability, this is a deep topic. We’ll address some aspects of security in one of the projects. The remaining projects will use a CLI permitting us to rely on the operating system’s security model.
Maintainability. Can we diagnose problems? Can we extend it? We’ll look at documentation and test cases as essential for maintainability. We’ll also leverage a few additional project files to make sure our project can be downloaded and extended by others.
Portability. Can we move to a new Python version? New hardware? This is very important. The Python ecosystem is rapidly evolving. Since all of the libraries and packages are in a constant state of change, we need to be able to define precisely what packages our project depends on, and confirm that it works with a new candidate set of packages.
Two of these characteristics (Compatibility and Portability) are features of Python. A wise choice of interfaces assures that these characteristics are met. These are sometimes described as architectural decisions since they influence how multiple applications work together.
For Security, we will rely on the operating system. Similarly, for Usability, we’ll limit ourselves to CLI applications, relying on long-standing design principles.
The idea of Performance is something we won’t emphasize here. We will point out places where large data sets will require some careful design. The choice of data structure and algorithm is a separate subject area. Our objective in this book is to expose you to projects that can provide the stimulus for a deeper study of performance issues.
Three of these quality characteristics — Functional suitability, Reliability, and Maintainability — are the real focus of these projects. These seem to be essential elements of good software design. These are the places where you can demonstrate your Python programming skills.
Another view is available from The Twelve-Factor App ( https://12factor.net). This is narrowly focused on web applications. The concepts provide deeper insights and more concrete technical guidance into the quality characteristics shown above:
Codebase. ”One codebase tracked in revision control, many deploys.” We’ll use Git and GitHub or perhaps one of the other version managers supported by sourceforge.
Dependencies. ”Explicitly declare and isolate dependencies.” Traditionally, a Python
requirements.txtfile was used for this. In this book, we’ll move forward to using apyproject.tomlfile.Config. ”Store config in the environment.” We won’t emphasize this, but Python offers numerous ways to handle configuration files.
Backing services. ”Treat backing services as attached resources.” We touch on this in a few places. How storage, messages, mail, or caching work isn’t something we’ll examine deeply.
Build, release, run. ”Strictly separate build and run stages.” For command-line applications, this means we should deploy the application into a ”production” environment to use the high-value data and produce the results that the enterprise needs. We want to avoid running things in our desktop development environment.
Processes. ”Execute the app as one or more stateless processes.” CLI applications tend to be structured this way without making any additional effort.
Port binding. ”Export services via port binding.” We won’t emphasize this; it’s very specific to web services.
Concurrency. ”Scale out via the process model.” This is a subject for the interested reader who wants to process very large data sets. We won’t emphasize it in the main text. We will suggest some of these topics in the ”Extras” section of some chapters.
Disposability. ”Maximize robustness with fast startup and graceful shutdown.” CLI applications tend to be structured this way, also.
Dev/prod parity. ”Keep development, staging, and production as similar as possible.” While we won’t emphasize this deeply, our intent with CLI applications is to expose the distinctions between development and production with command-line arguments, shell environment variables, and configuration files.
Logs. ”Treat logs as event streams.” We will suggest applications write logs, but we won’t provide more detailed guidance in this book.
Admin processes. ”Run admin/management tasks as one-off processes.” A few of the projects will require some additional administrative programming. These will be built as deliverable CLI applications, complete with an acceptance test suite.
Our objective is to provide project descriptions and lists of deliverables that try to conform to these quality standards. As we noted earlier, each enterprise is unique, and some organizations will fall short of these standards, while some will exceed them.
1.1.1 More Reading on Quality
In addition to the ISO standard, the IEEE 1061 standard also covers software quality. While it has been inactive since 2020, it contains some good ideas. The standard is focused on quality metrics, which dives deeply into the idea of analyzing software for quality factors.
It can also help to read https://en.wikipedia.org/wiki/ISO/IEC_9126 for some background on the origins of the ISO standard.
When doing more reading on this topic, it can help to recognize the following three terms:
Factors are an external view of the software. They reflect the user’s understanding. Some of the underlying quality characteristics are not directly visible to users. Maintainability, for example, may appear to users as a reliability or usability problem because the software is difficult to repair or extend.
Criteria come from an internal view of the software. Quality criteria are the focus of the project’s deliverables. Our project code should reflect the eight quality characteristics listed above.
Metrics are how we can control the factors that are seen by the user. We won’t emphasize quality metrics. In some cases, tools like pylint provide tangible measurements of static code quality. This isn’t a comprehensive tool for software quality in general, but it provides an easy starting point for a few key metrics related to complexity and maintainability.
Given these standards for high-quality software, we can turn our attention to the sequence of steps for building these files. We’ll suggest a sequence of stages you can follow.
