Glossary

Sigrid is a technology agnostic tool. To avoid ambiguities between technologies, SIG uses terminology that applies to most- or all technology. A simplified list of such terms are listed in this page.

• Anti-patterns: Architecture communication antipatterns are undesirable patterns of dependencies between components that will complicate maintenance. See the system maintainability’s Component Dependencies section.
• Architecture: High level overview of the components of a system. In Sigrid’s context, this is the implemented architecture, so how it manifests in source code. See Component depedencies and the elaboration on architectural quality.
• Benchmarking: A comparison against a representative set. In a system quality context, how a system’s quality relates to that of other systems measured by SIG, as a representation of the “current state of software development”. See section on our approach.
• Component: A component (see Component Dependency section) is part of the top-level division of a system, and is defined by a system’s software architecture. In the context of maintainability, this is the highest unit of code division. It can be defined in a system’s scoping configuration.
• Findings: Depending on the capability in scope, a finding is any deviation from the best practices related to that capability. These can be seen as system-overviews or portfolio overviews. For Maintainability, this is related to how the metrics calculated from its code source, relate the thresholds of the different risk profiles in SIG’s models.
• Maintainability: Maintainability is a quality characteristic applied to source code. It is a spectrum of ease or difficulty of being able to change source code, regardless of whether it is being changed. In Sigrid’s context, maintainability is based on SIG’s benchmarked implementation of the ISO 25010 model. This model and SIG’s approach are certified by TÜViT. Maintainability can be considered to be an “enabler” for other software quality improvements such as security.
• Modules: The concept of a module is a level above the unit. It is typically a file or a class in object-oriented languages such as Java. An example of a module-specific metric is Module coupling, of which an example is described on the technical monitor page.
• Objective: The code quality goal (non-functional requirement) set in Sigrid for a system or capability.
• Open Source Health (OSH): The software quality capability that assesses the risks of the use of open source software (3rd party libraries) within a system, as detected by static analysis (mostly by package manager configuration and in some cases, binaries).
• Portfolio: A set of systems (software) that are part of a single organization, also referred to as IT/software portfolio. An overview is described on the portfolio overview page.
• Quality: All software quality terms and capabilities are mainly based on the definition of ISO 25010 standard for software product quality. See a discussion on our Approach page.
• Repository: Contains the source code for a particular customer project that is often, but not necessarily, a system’s complete codebase. Repository-to-system mapping is described on the Systems page.
• Role: The role of the Sigrid user within their own organization. Sigrid accommodates at least four main Sigrid users (the links describe their typical workflows): the Developer, Project Owner, Architect, and Manager.
• Sigrid CI: Sigrid CI is the integration of Sigrid calculations into your pipeline, that can be run after each commit. Technically it consists of a number of Python-based client scripts that interact with Sigrid in order to analyze your project’s source code and provide feedback based on the results. Its workflow is described here and supported technologies here.
• System: An organization’s software implementation with a specific (business) purpose, typically defined as a “unit” that can exist and perform independently. Nuances between repositories and systems are described here, and systems’ scope configuration here.
• Unit: Units are the smallest groups of code that can be maintained and executed independently. For example, in Java, units are methods. The place to start to explore unit metrics is probably the system maintainability overview.