Software development glossary

How to use this software development glossary

This software development glossary explains the terms decision-makers and practitioners encounter when planning products, evaluating vendors, and operating digital services. Rather than treating terminology as a vocabulary exercise, it connects definitions to concrete choices: what to build, how to deploy it, which risks to accept, and how to measure delivery quality.

A useful glossary also exposes ambiguity. “Serverless” does not mean servers disappear; “open source” does not mean maintenance is free; and “dedicated team” does not automatically mean exclusive staffing.

Use the definitions below to align technical proposals, procurement documents, engineering plans, and acceptance criteria.

Core software development terms

Software development life cycle, Agile, and Scrum

Software development life cycle (SDLC) is the process used to plan, design, build, test, release, maintain, and retire software. An SDLC should identify responsibilities and evidence required at each stage, even when those stages overlap.

Agile describes principles favoring collaboration, incremental delivery, and adaptation. It is not a specific project-management tool or permission to avoid documentation.

Scrum is a framework for organizing complex work through defined accountabilities, events, and artifacts. Its timeboxed sprints support regular inspection and adaptation.

For evaluation, ask:

• Who prioritizes work and accepts outcomes?
• How are security and testing included?
• What happens when requirements change?
• Can the team demonstrate working software regularly?

Jira and Azure DevOps can support these practices, but buying either does not establish an effective delivery process.

Requirements, user stories, and acceptance criteria

Requirements describe capabilities, constraints, or qualities a system must satisfy. Functional requirements specify behavior; nonfunctional requirements address qualities such as reliability, accessibility, and performance.

A user story describes a need from a user’s perspective. It is a conversation aid, not necessarily a complete specification.

Acceptance criteria define the conditions that make work acceptable. “Search should be fast” is ambiguous. “Search returns results within the agreed latency target under the documented load profile” creates a testable obligation.

For outsourced work, connect acceptance criteria to review procedures and contractual acceptance milestones.

MVP, proof of concept, and prototype

A minimum viable product (MVP) is a usable product with enough functionality to test a meaningful business hypothesis with intended users.

A proof of concept (PoC) tests feasibility, such as whether a legacy system exposes the data an integration needs.

A prototype explores design or interaction and may contain no production-ready implementation.

The trade-off is speed versus completeness. A disposable prototype can accelerate learning, but promoting it directly into production may leave gaps in security, accessibility, and operations.

Technical debt and refactoring

Technical debt is the future cost created by expedient or inadequate technical decisions. Some debt is deliberate; some emerges as requirements change.

Refactoring changes internal code structure without intentionally changing observable behavior. It can reduce debt, but it is not synonymous with rewriting a system.

Track debt through consequences: difficult upgrades, recurring defects, slow builds, or excessive effort to make routine changes. Prioritize repayment where those consequences materially affect delivery or risk.

Architecture and integration terminology

APIs, REST, GraphQL, and webhooks

An application programming interface (API) defines how software components interact.

REST is an architectural style emphasizing constraints such as stateless interactions and a uniform interface. Many HTTP APIs are described as REST APIs without implementing every REST constraint.

GraphQL is a query language and execution model that lets clients request selected fields from a defined schema.

A webhook sends an HTTP notification when an event occurs, reducing the need for repeated polling.

For webhook consumers, require idempotency: repeated delivery of the same event should not cause unintended repeated effects, such as duplicate payments.

Monolith, microservices, and modular monolith

A monolith packages an application as a single deployable unit. It can still have well-organized internal modules.

Microservices divide a system into independently deployable services organized around capabilities. They introduce network communication, distributed failure modes, and coordination overhead.

A modular monolith preserves strong internal boundaries while retaining simpler deployment.

Choose using concrete criteria:

• Do components need independent scaling or release schedules?
• Can teams own services through deployment and incident response?
• Are domain boundaries sufficiently understood?
• Does the organization have distributed tracing and automated provisioning?

Microservices can improve autonomy, but a modular monolith is often more practical when operational capacity is limited.

Framework, library, and SDK

A library provides reusable functionality that application code calls. A framework supplies a broader structure that application code extends or runs within.

Examples include React as a user-interface library, Django as a Python web framework, and Spring Boot for building Spring-based Java applications.

A software development kit (SDK) bundles tools for a platform or service, often including libraries, examples, and authentication helpers.

Evaluate maintenance activity, security support, licensing, ecosystem compatibility, and migration costs—not popularity alone.

Delivery, testing, and security terms

Version control, pull requests, and CI/CD

Version control records changes and supports collaboration. Git is a distributed version-control system; GitHub and GitLab provide hosting and collaboration services around it.

A pull request, or merge request, proposes changes for review before integration.

Continuous integration (CI) merges changes frequently and validates them through automated builds and checks.

Continuous delivery keeps software releasable, while continuous deployment automatically releases changes that pass the required checks. Both are commonly abbreviated within “CI/CD,” so clarify which meaning a proposal uses.

GitHub Actions, GitLab CI/CD, and Jenkins can automate pipelines. Compare access controls, runner isolation, secret management, and deployment approval requirements.

Unit, integration, and end-to-end testing

Unit tests check small units of behavior in isolation. Integration tests check interactions between components. End-to-end tests validate complete workflows across a running system.

JUnit and pytest support automated testing; Playwright is commonly used for browser-based workflows.

More tests do not automatically mean better assurance. Evaluate whether tests cover critical behavior, detect realistic failures, and run reliably enough to remain useful.

Code coverage reports which code executes during tests. It does not establish that assertions are meaningful or business risks are covered.

DevSecOps and software supply chain security

DevSecOps integrates security responsibilities and controls into development and operations.

Software supply chain security addresses risks in dependencies, build systems, artifacts, and distribution. A software bill of materials (SBOM) inventories software components; it does not certify that those components are safe.

Useful controls include dependency scanning, restricted build credentials, artifact signing, and vulnerability-response procedures. The NIST Secure Software Development Framework provides an authoritative vocabulary for organizing secure development practices.

Cloud computing and operations terms

IaaS, PaaS, and SaaS

Infrastructure as a service (IaaS) provides infrastructure resources such as virtual machines and networks. Amazon EC2 is an example.

Platform as a service (PaaS) provides a managed application platform, reducing infrastructure administration. Azure App Service is an example.

Software as a service (SaaS) provides a finished application operated by a vendor, such as Salesforce.

Moving toward managed services generally reduces operational work but can constrain customization and portability. Compare total operating cost, data export capabilities, identity integration, and shared security responsibilities.

Containers, Kubernetes, and serverless

A container packages an application and its dependencies into an isolated execution environment. Containers typically share the host operating system kernel rather than each running a full guest operating system.

Kubernetes orchestrates containerized workloads, including scheduling, service discovery, and rollout management. Its capabilities come with configuration and operational complexity; the official Kubernetes concepts documentation explains its core abstractions.

Serverless shifts more provisioning and scaling responsibility to a provider. AWS Lambda and Azure Functions are examples of function services.

Compare workload duration, startup latency, concurrency limits, networking, and billing behavior. Serverless can suit variable workloads, while predictable high utilization may favor other hosting models.

Observability, SLI, SLO, and SLA

Observability is the ability to understand system behavior through outputs such as logs, metrics, and traces. OpenTelemetry supports instrumentation and telemetry exchange; Grafana and Datadog provide analysis and visualization capabilities.

A service-level indicator (SLI) measures service behavior, such as successful request proportion.

A service-level objective (SLO) sets a target for an indicator.

A service-level agreement (SLA) establishes contractual service commitments and potential remedies.

Do not substitute a provider’s infrastructure SLA for an application reliability target. Dependencies, deployment mistakes, and application defects can still interrupt the user journey.

Artificial intelligence terminology

Model training, inference, and fine-tuning

Training adjusts model parameters using data. Inference uses a trained model to produce outputs.

Fine-tuning continues training an existing model on additional data to adapt its behavior or capabilities.

These stages have different economics and risks. Training requires suitable data and compute; inference introduces recurring latency and usage costs. Fine-tuning also requires evaluation and model-version management.

PyTorch supports model development, while services such as Amazon Bedrock and Azure AI Foundry provide managed AI capabilities. Check regional availability, data handling, model access, and deployment options for the specific service offering.

LLMs, tokens, RAG, and hallucinations

A large language model (LLM) processes and generates language using learned statistical patterns.

A token is a unit of model input or output, often representing part of a word. Tokens are not equivalent to words, and tokenization varies.

Retrieval-augmented generation (RAG) retrieves relevant information and supplies it as context for generation. It can improve access to current or private knowledge without retraining the model.

A hallucination is a generated claim that is unsupported or incorrect.

RAG does not guarantee accuracy. Evaluate retrieval relevance, source permissions, citation validity, abstention behavior, latency, and cost on representative tasks. Keep authorization checks outside the model’s discretion.

Blockchain terminology

Blockchain, smart contracts, and gas

A blockchain is a ledger organized into cryptographically linked blocks, with participants following a protocol to agree on accepted updates.

A smart contract is code executed under a blockchain’s rules. It is not automatically a legally enforceable agreement.

Gas measures computational work on networks such as Ethereum; transaction fees depend on gas usage and applicable fee conditions. The Ethereum developer documentation explains these mechanisms.

Assess whether multiple parties genuinely need shared execution without one trusted database operator. Blockchain adds complexity when ordinary access controls and audit logs already satisfy the requirement.

Consensus, finality, and oracles

Consensus is the mechanism participants use to agree on ledger state.

Finality describes the assurance that an accepted transaction will not be reversed under the protocol’s assumptions.

An oracle supplies external information to a smart contract. It introduces dependencies on data sources and delivery mechanisms.

Procurement reviews should examine administrative keys, upgrade permissions, oracle failures, transaction costs, and recovery options—not simply whether a contract has been audited.

Outsourcing and commercial terminology

Staff augmentation, dedicated teams, and managed services

Staff augmentation adds external personnel to a client-directed team.

A dedicated team is an assigned delivery group, but its exclusivity, management structure, and capacity commitments depend on the contract.

Managed services place responsibility for a defined service scope with a provider, usually against agreed service measures.

Compare arrangements through accountability: who prioritizes work, approves architecture, handles incidents, and owns delivery outcomes? Require named responsibilities rather than relying on engagement labels.

Fixed price, time and materials, and total cost of ownership

Fixed price establishes a price for an agreed scope. It works best when requirements and acceptance conditions are sufficiently stable.

Time and materials (T&M) charges for actual effort and agreed expenses. It supports evolving scope but requires budget visibility and prioritization discipline.

Total cost of ownership (TCO) includes acquisition, development, infrastructure, support, security, migration, and retirement costs.

A low hourly rate can be offset by rework or coordination overhead. Examine intellectual-property rights, subcontracting, repository access, documentation, and exit assistance alongside price.

A step-by-step process for applying this glossary

1. Identify the decision. Specify whether you are selecting architecture, comparing vendors, or approving a release.
2. Extract ambiguous terms. Flag phrases such as “production-ready,” “cloud-native,” and “AI-powered.”
3. Agree on operational definitions. Translate each phrase into observable capabilities and responsibilities.
4. Request evidence. Review pipeline runs, architecture diagrams, test results, service reports, or working demonstrations.
5. Compare trade-offs. Record operating effort, security exposure, portability, cost drivers, and delivery constraints.
6. Document acceptance and ownership. Assign measurable criteria and accountable people; revisit definitions when scope changes.

Common mistakes to avoid

• Treating terminology as proof: A “DevSecOps team” still needs demonstrable controls.
• Confusing tools with outcomes: Kubernetes does not automatically create resilience.
• Leaving commercial language undefined: “Dedicated” and “managed” need contractual detail.
• Optimizing a single metric: Coverage, hourly rate, and token price each omit important costs or risks.
• Ignoring lifecycle obligations: Every dependency, model, and deployed service needs maintenance and eventual retirement planning.

For related definitions, browse more Glossary topics.

Frequently asked questions

What should a software development glossary include?

Include engineering, architecture, testing, security, operations, and commercial terms. Each entry should explain meaning, practical implications, and common ambiguities—not merely expand an acronym.

What is the difference between software development and software engineering?

Software development emphasizes creating and maintaining software. Software engineering emphasizes systematic methods for managing design, quality, complexity, and lifecycle constraints. In practice, the roles and labels overlap.

Which terms matter most when comparing development vendors?

Prioritize scope, acceptance criteria, ownership, CI/CD, security responsibilities, SLA, TCO, and exit provisions. These terms directly affect accountability, delivery confidence, operating costs, and switching options.

How often should a team update its glossary?

Update it when technologies, contracts, or working practices change. Assign an owner and review terminology during major architecture or procurement decisions, especially when different teams use the same word differently.