Glossary of Terms — Software Engineering

This glossary provides clear, concise definitions of essential software engineering terminology. Understanding this vocabulary is fundamental for effective communication within development teams, with stakeholders, and during technical interviews. Terms are organized alphabetically for easy reference.

A

Abstraction: The process of hiding complex implementation details and showing only essential features. A database connection class abstracts away TCP/IP socket management, authentication handshakes, and protocol details—callers simply execute queries.

Acceptance Criteria: Specific, measurable conditions that a software feature must satisfy to be accepted by stakeholders. Written in testable format, typically using Given-When-Then structure.

Agile: A family of iterative development methodologies emphasizing customer collaboration, working software, and responding to change over rigid planning. Includes Scrum, Kanban, and XP.

API (Application Programming Interface): A set of defined rules and protocols for building and integrating application software. APIs specify how software components should interact.

Architecture: The fundamental organization of a software system—its components, their relationships, and the principles governing their design and evolution.

B

Baseline: An approved version of a work product (code, document, configuration) that serves as the reference point for subsequent changes. Changes to a baselined artifact require formal change control.

Black-Box Testing: Testing based on external specifications without knowledge of internal code structure.

Build: The process of converting source code into executable software, including compilation, linking, and packaging.

C

CI/CD (Continuous Integration/Continuous Delivery): Practice of frequently merging code changes (CI) and maintaining software in a continuously deployable state (CD) through automated build, test, and deployment pipelines.

CMMI (Capability Maturity Model Integration): A framework for assessing and improving organizational process maturity across five levels, from ad-hoc (Level 1) to optimizing (Level 5).

Cohesion: The degree to which elements within a module are related and work together toward a single purpose. High cohesion is desirable—each module has a clear, focused responsibility.

Coupling: The degree of interdependence between modules. Low coupling is desirable—modules can be modified independently without affecting others.

COCOMO: Constructive Cost Model—an algorithmic software cost estimation model that uses project size (lines of code) and cost drivers to predict effort and schedule.

D

Defect: Any deviation between the software's actual behavior and its expected behavior as defined by requirements. Synonyms: bug, fault, error (though each has subtly different technical meanings).

Dependency Injection: A design technique where an object receives its dependencies from external sources rather than creating them internally, improving testability and flexibility.

DevOps: A culture and set of practices combining software development (Dev) and IT operations (Ops) to shorten the development lifecycle and provide continuous delivery.

E-F

Encapsulation: Bundling data and the methods that operate on that data within a single unit (class), and restricting direct access to some of the object's components.

Feasibility Study: An analysis evaluating whether a proposed project is technically possible, economically viable, operationally practical, and legally permissible.

Function Point: A unit of measurement expressing the amount of business functionality an information system provides, independent of the technology used for implementation.

G-I

Git: A distributed version control system that tracks changes in source code during software development. Created by Linus Torvalds in 2005.

Integration Testing: Testing the interaction between combined software modules to verify they work together correctly.

Iteration: A single development cycle within an iterative methodology, typically producing a working (if incomplete) version of the system.

K-M

KLOC: Thousands of Lines of Code—a size metric used in effort estimation and quality measurement.

Maintainability: The ease with which a software system can be modified to correct defects, improve performance, or adapt to a changed environment.

Microservices: An architectural style structuring an application as a collection of small, independently deployable services, each running its own process and communicating via lightweight mechanisms.

Mock Object: A simulated object that mimics the behavior of a real object in controlled ways, used during testing to isolate the component under test.

N-R

Non-Functional Requirement: A requirement specifying criteria for judging system operation (performance, security, usability) rather than specific behaviors.

Refactoring: Restructuring existing code without changing its external behavior to improve readability, reduce complexity, or improve maintainability.

Regression: A defect introduced by a change to existing code—functionality that previously worked correctly now fails.

Requirements Traceability: The ability to track each requirement forward to its implementation and tests, and backward to its origin and rationale.

S

SDLC (Software Development Life Cycle): The structured process for developing software systems, encompassing planning, analysis, design, implementation, testing, deployment, and maintenance.

SOLID Principles: Five design principles for creating maintainable object-oriented software: Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion.

Sprint: A fixed-duration iteration (typically 1-4 weeks) in Scrum during which the team commits to delivering a potentially shippable product increment.

Stakeholder: Any person or organization with an interest in or influence over a software project—users, customers, managers, regulators, or the development team itself.

T-Z

Technical Debt: The implied cost of future rework caused by choosing a quick, expedient solution over a more thorough approach during development.

UML (Unified Modeling Language): A standardized visual modeling language for specifying, constructing, and documenting software system artifacts.

Unit Testing: Testing individual software components (functions, methods, classes) in isolation from the rest of the system.

Use Case: A description of how a user interacts with a system to achieve a specific goal, capturing the sequence of actions and system responses.

Validation: Confirming that the software meets the actual needs of users ("building the right product").

Verification: Confirming that the software conforms to its specifications ("building the product right").

Waterfall Model: A sequential software development model where each phase (requirements, design, implementation, testing, deployment) must complete before the next begins.