Find a term
Understand the metrics, models, and methods behind modern engineering. Clear definitions, practical examples, and a closer look at what the numbers actually mean.
Terms beginning with S
160 termsService level objective
A service level objective, or SLO, is a target value or range for a service level indicator. It states the level of service a team aims to provide over a defined period and measurement boundary.
Reliability and observabilityService map
Service map is a representation of services and observed communication paths between them.
Reliability and observabilityService ownership
Service ownership is a software delivery concept used to describe a specific event, interval, control, or operating condition in the path from source change to production behavior. A useful definition names the boundary, unit, and decision the measure supports.
DORA and DevOpsService rate
Service rate is the number of items that a stage or system completes per unit of time. It is a measured outcome of capacity, work mix, policies, and variation, not a fixed property of a person.
Flow and capacity planningService template
A service template is a reusable starting point for creating a software service and its supporting configuration. It may include repository structure, build and deployment workflows, observability, security controls, documentation, and defaults that teams can adapt to their context.
Measurement and experimentationService time
Service time is the serving concept concerned with service time during AI inference.
Inference performanceServing backpressure
Serving backpressure is the serving concept concerned with serving backpressure during AI inference.
Inference performanceShadow routing
Shadow routing is a model-routing or gateway concept used to manage traffic selection for AI requests. It describes a distinct decision, control, interface, or observation point between an application and one or more model providers.
Model routing and gatewaysShadow traffic
Shadow traffic is a model-routing or gateway concept used to manage traffic selection for AI requests. It describes a distinct decision, control, interface, or observation point between an application and one or more model providers.
Model routing and gatewaysShared fate
Shared fate is a reliability concept used to describe a specific condition, control, or decision in the operation of software services.
Reliability and observabilityShared understanding
Shared understanding is a way to organize, support, or evaluate software work so that teams can make useful progress with less avoidable friction. It is most valuable when connected to a concrete outcome and the local conditions of the team using it.
Developer productivityShift-left testing
Shift-left testing is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.
Code quality and technical debtShift-right testing
Shift-right testing is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.
Code quality and technical debtShotgun surgery
A code smell in which one conceptual change requires small edits across many modules.
Code quality and technical debtSignificance test
Significance test is a defined lens for examining AI system behavior with a stated task, evidence, and interpretation rule.
Evaluations and benchmarksSimplify conditional
Simplify conditional is a software maintenance concern describing a condition that can make future changes, verification, operation, or ownership harder. Its practical importance depends on supported behavior, rate of change, and the consequences of delay.
Code quality and technical debtSimpson's paradox
Simpson's paradox is a statistical or measurement concept used to describe, compare, or interpret engineering data. Its meaning depends on the unit of analysis, data-generating process, and question being asked.
Measurement and experimentationSingle point of failure
Single point of failure is a reliability concept used to describe a specific condition, control, or decision in the operation of software services.
Reliability and observabilitySingle responsibility principle
A design principle that asks a software unit to have one coherent reason to change.
Code quality and technical debtSingle-piece flow
Single-piece flow is a process pattern in which work advances individually or in very small units through the value stream. It aims to expose problems early and reduce the waiting created by large batches.
Flow and capacity planningSkewness
Skewness is a statistical or measurement concept used to describe, compare, or interpret engineering data. Its meaning depends on the unit of analysis, data-generating process, and question being asked.
Measurement and experimentationSlack time
Slack time is a concept used in software delivery planning to describe a condition, relationship, estimate, or decision about engineering work.
Flow and capacity planningSlice-based evaluation
Slice-based evaluation is a defined lens for examining AI system behavior with a stated task, evidence, and interpretation rule.
Evaluations and benchmarksSLO alerting
SLO alerting is creation of notifications from measured service objectives and remaining error budget.
Reliability and observabilitySLO breach
SLO breach is a software delivery concept used to describe a specific event, interval, control, or operating condition in the path from source change to production behavior. A useful definition names the boundary, unit, and decision the measure supports.
DORA and DevOpsSmall batch
Small batch is a way to organize, support, or evaluate software work so that teams can make useful progress with less avoidable friction. It is most valuable when connected to a concrete outcome and the local conditions of the team using it.
Developer productivitySmall sample size
Small sample size is an analytical risk or quality concern that can make an engineering analysis appear more certain, comparable, or causal than it is.
Engineering analyticsSmoke test deployment
Smoke test deployment is a release engineering and DevOps concept for controlling how software changes are prepared, introduced, or understood.
DORA and DevOpsSmoke testing
Smoke testing is a brief set of checks that determines whether a build or deployment is stable enough for more detailed testing. It typically exercises a few critical paths and fails fast when a basic capability is unavailable.
Code quality and technical debtSnapshot metric
Snapshot metric describes state at one point in time.
Engineering analyticsSoak testing
Soak testing is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.
Code quality and technical debtSoftware bill of materials
Software bill of materials is a software maintenance concern describing a condition that can make future changes, verification, operation, or ownership harder. Its practical importance depends on supported behavior, rate of change, and the consequences of delay.
Code quality and technical debtSoftware delivery system
A software delivery system is the connected set of workflows, tools, people, controls, and feedback loops that moves a software change from an idea or request through development and validation into production and operation.
Engineering analyticsSoftware factory
A software factory is the connected system an organization uses to design, build, test, review, release, and learn from software. It includes human responsibilities, delivery workflows, platforms, automation, quality controls, and the feedback that improves the system over time.
Engineering analyticsSoftware factory baseline
A software factory baseline is a documented snapshot of a software delivery system before an intervention or comparison. It records the work population, event definitions, time window, measures, and relevant operating conditions needed to interpret later change.
Engineering analyticsSoftware factory bottleneck
A software factory bottleneck is a person, team, policy, tool, or workflow stage whose effective capacity limits the rate at which the delivery system can complete work. It is identified through sustained evidence of constrained flow and queues.
Flow and capacity planningSoftware factory cadence
Software factory cadence is the recurring rhythm by which a software delivery system receives work, creates changes, gathers feedback, releases software, and reviews outcomes. It is a property of the system's flow, not a requirement that every team work to the same schedule.
Engineering analyticsSoftware factory capacity
Software factory capacity is the amount of work a software delivery system can complete during a defined period under stated conditions. It depends on people, tools, queues, policies, work mix, dependencies, and quality requirements, so it is not a fixed count of engineers multiplied by hours.
Flow and capacity planningSoftware factory change size
Software factory change size is the amount of code or delivery scope included in a software change as defined by a chosen unit. It is a context signal that can affect review effort, feedback speed, failure isolation, and queue behavior.
Developer productivitySoftware factory feedback loop
A software factory feedback loop is a recurring path in which an observation about a software change or outcome informs a decision, the decision changes the system, and a later observation tests the result. Feedback may come from code review, tests, delivery, production, customers, or developers.
Engineering analyticsSoftware factory governance
Software factory governance is the set of policies, controls, ownership rules, and review practices used to guide software delivery toward security, reliability, compliance, and product goals. Effective governance makes expectations visible and provides a workable path for exceptions.
DORA and DevOpsSoftware factory improvement experiment
A software factory improvement experiment is a time-bounded change to a software delivery system that tests whether a specific intervention improves a defined outcome. It uses a baseline, a stated hypothesis, comparable measures, and a review of the evidence before the change is adopted more broadly.
Measurement and experimentationSoftware factory metrics
Software factory metrics are a defined set of measurements used to understand how an organization's software delivery system performs. They cover the movement, quality, stability, cost, and experience of work rather than reducing the factory to one activity count.
Measurement and experimentationSoftware factory observability
Software factory observability is the ability to understand what is happening inside a software delivery system by using connected signals about work, workflow state, timing, failures, ownership, and outcomes. It supports investigation by preserving enough context to explain why a result occurred.
Engineering analyticsSoftware factory queue time
Software factory queue time is the elapsed time a software work item spends waiting for a person, decision, resource, check, environment, or next workflow stage. It is a part of total delivery time and should be defined by the queue boundary being measured.
Engineering analyticsSoftware factory rework
Software factory rework is software work performed again because an earlier change was defective, incomplete, misunderstood, rejected, or made obsolete. It includes corrective changes and repeated effort that consumes delivery capacity without representing a new independent outcome.
Engineering analyticsSoftware factory stability
Software factory stability is the ability of a software delivery system to release changes predictably, limit the harm from failures, and recover when intervention is required. It describes the behavior of the system around delivery, rather than the absence of all change or risk.
DORA and DevOpsSoftware factory throughput
Software factory throughput is the amount of software work that reaches an agreed completion point during a defined period. The completion point may be a merged change, a production deployment, or a customer outcome, and the chosen boundary must remain consistent.
Engineering analyticsSoftware factory work in progress
Software factory work in progress is the unfinished software work currently carried by a delivery system. It includes changes being implemented as well as work waiting for review, testing, approval, deployment, clarification, or another dependency.
Flow and capacity planningSoftware supply chain
Software supply chain is a release engineering and DevOps concept for controlling how software changes are prepared, introduced, or understood.
DORA and DevOps