🌁Software Engineering: Six Sigma (Definitions)

"A statistical term meaning six standard deviations from the norm. Used as the name for a quality improvement program that aims at reducing errors to one in a million." (Judith Hurwitz et al, "Service Oriented Architecture For Dummies" 2nd Ed., 2009)

"1.Generally, a rigorous and disciplined statistical analysis methodology to measure and improve a company’s operational performance, practices and systems. 2.In many organizations, simply a measure of quality near perfection. 3.In data quality, a level of quality in which six standard deviations of a population fall within the upper and lower control limits of quality, allowing no more than 3.4 defects per million parts or transactions." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"A methodology to manage process variations that cause defects, defined as unacceptable deviation from the mean or target, and to systematically work toward managing variation to prevent those defects." (Linda Volonino & Efraim Turban, "Information Technology for Management" 8th Ed., 2011)

"A systematic quality improvement process used on both the production and transactional sides of the business to design, manufacture, and market goods and services that customers may desire to purchase." (Joan C Dessinger, "Fundamentals of Performance Improvement" 3rd Ed., 2012)

"A highly structured approach for eliminating defects in any process, whether from manufacturing or transactional processes. It can be applied to a product or a service–oriented process in any organization. Further, Six Sigma is 'a statistical term that measures how far a given process deviates from perfection'. The goal of Six Sigma is to systematically measure and eliminate defects in a process, aiming for a level of less than 3.4 defects per million instances or 'opportunities'." (Robert F Smallwood, "Managing Electronic Records: Methods, Best Practices, and Technologies", 2013)

"A business management strategy originally developed by Motorola in the 1980s. It is essentially a business problem-solving methodology that supports process improvements through an understanding of customer needs, identification of causes of quality variations, and disciplined use of data and statistical analysis." (Sally-Anne Pitt, "Internal Audit Quality", 2014)

"An approach from the production environment for managing quality that targets a mere 3.4 errors per million instances as its performance goal." (Boris Otto & Hubert Österle, "Corporate Data Quality", 2015)

"A disciplined approach to enterprise-wide quality improvement and variation reduction. Technically, it is the denominator of the capability (Cp) index." (Clyde M Creveling, "Six Sigma for Technical Processes", 2006)

"A business management strategy focusing on quality control testing and optimizing processes through reducing process variance." (Evan Stubbs, "Big Data, Big Innovation", 2014)

🌁Software Engineering: Penetration Testing (Definition)

"A method for assessing information systems in an attempt to bypass controls and gain access." (Weiss, "Auditing IT Infrastructures for Compliance" 2nd Ed., 2015)

"An attempt to circumvent various layers of a system or application’s security controls for the purpose of seeing how far into the system the attacker can get." (Mike Harwood, "Internet Security: How to Defend Against Attackers on the Web" 2nd Ed., 2015)

"A method of evaluating the security of a computer system or network by simulating an attack that a malicious hacker would carry out. This is done so that vulnerabilities and weaknesses can be uncovered." (Shon Harris & Fernando Maymi, "CISSP All-in-One Exam Guide" 8th Ed., 2018)

"Security testing in which evaluators mimic real-world attacks in an attempt to identify ways to circumvent the security features of an application, a system, or a network." (William Stallings, "Effective Cybersecurity: A Guide to Using Best Practices and Standards", 2018)

"The portion of security testing in which evaluators attempt to circumvent the security features of a system. The evaluators may be assumed to use all system design and implementation documentation and may include listings of system source code, manuals, and circuit diagrams. The evaluators work under the same constraints applied to ordinary users." (Mark S Merkow & Lakshmikanth Raghavan, "Secure and Resilient Software Development", 2010)

"The specialized testing of a system to determine if it is possible to defeat its security controls." (O Sami Saydjari, "Engineering Trustworthy Systems: Get Cybersecurity Design Right the First Time", 2018)

🌁Software Engineering: Peer Review (Definitions)

"The review of work products performed by peers during development of the work products to identify defects for removal. The term peer review is used in the CMMI Product Suite instead of the term work product inspection. Essentially, these terms mean the same thing." (Sandy Shrum et al, "CMMI: Guidelines for Process Integration and Product Improvement", 2003)

"A formal review of a complete work product performed by a group to identify defects for removal, and to collect metrics. See also inspection." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

"A system using reviewers who are professional equals; a process used for checking the work performed by one’s equals (peers) to ensure that it meets specific criteria." (Mark S Merkow & Lakshmikanth Raghavan, "Secure and Resilient Software Development", 2010)

"A review of a software work product by colleagues of the producer of the product for the purpose of identifying defects and improvements. Examples are inspection, technical review and walkthrough." (IQBBA, "Standard glossary of terms used in Software Engineering", 2011)

"In relation to internal audit, a form of external assessment that involves a minimum of three organizations assessing each other's internal audit functions using a round-robin approach (A reviews B who reviews C who reviews A)." (Sally-Anne Pitt, "Internal Audit Quality", 2014)

🌁Software Engineering: Inspection (Definitions)

"Visual examination of work products to detect errors, violations of development standards, and other problems. See also peer review and static analysis." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

"The process of examining a component, subassembly, subsystem, or product for off-target performance, variability, and defects during either product development or manufacturing. The focus is typically on whether the item under inspection is within the allowable tolerances. As with all processes, inspection itself is subject to variability, and out-of-spec parts or functions might pass inspection inadvertently." (Clyde M Creveling, "Six Sigma for Technical Processes: An Overview for R Executives, Technical Leaders, and Engineering Managers", 2006)

"Examining or measuring to verify whether an activity, component, product, result, or service conforms to specified requirements. " (For Dummies, "PMP Certification All-in-One For Dummies" 2nd Ed., 2013)

"A verification method in which one member of a team reads the program or design aloud line by line and the others point out errors" (Nell Dale & John Lewis, "Computer Science Illuminated" 6th Ed., 2015)

"Examination of a work product to determine whether it conforms to documented standards." (Project Management Institute, "A Guide to the Project Management Body of Knowledge (PMBOK® Guide )", 2017)

"A type of peer review that relies on visual examination of documents to detect defects, e.g. violations of development standards and non-conformance to higher level documentation. The most formal review technique and therefore always based on a documented procedure." (IEEE 610, 1028)

🌁Software Engineering: Quality Control (Definitions)

"The operational techniques and activities that are used to fulfill requirements for quality." (Sandy Shrum et al, "CMMI: Guidelines for Process Integration and Product Improvement" 2nd Ed., 2006)

"Monitoring project performance for quality and identifying sources of unsatisfactory quality measures." (Bonnie Biafore, "Successful Project Management", 2011)

"Procedures and methods for measuring process quality, identifying unacceptable performance, variance and taking corrective action." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"A set of activities that measure, evaluate, and report on the quality of software project artifacts throughout the project life cycle." (Project Management Institute, "Software Extension to the PMBOK® Guide 5th Ed", 2013)

"Review of all elements of development and production, often reliant on inspection." (Sally-Anne Pitt, "Internal Audit Quality", 2014)

"The practice of testing or measuring and recording results at checkpoints to assess performance and ensure that the project performance meets the standard within appropriate parameters." (Bonnie Biafore & Teresa Stover, "Your Project Management Coach", 2012)

"The operational techniques and activities, part of quality management, that are focused on fulfilling quality requirements." (ISO 8402)

🌁Software Engineering: Testing (Definitions)

"The process of operating a system or component under controlled conditions to collect measurements needed to determine if the system or component meets its allocated requirements. See also dynamic analysis." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

"Activity to verify if an object conforms with its requirements and to detect deviations." (Lars Dittmann et al, "Automotive SPICE in Practice", 2008)

"The application of test cases against a build to ensure that a system performs correctly in those cases." (Bruce P Douglass, "Real-Time Agility: The Harmony/ESW Method for Real-Time and Embedded Systems Development", 2009)

"Generally, a validation process that compares in an organized fashion the functionality or content of a thing or process against pre-established requirements for that thing or process." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"A set of one or more test cases test automation 1. The use of software tools to design or program test cases with the goal to be able to execute them repeatedly using the computer. 2. To support any test activities by using software tools." (Tilo Linz et al, "Software Testing Foundations, 4th Ed", 2014)

"The process consisting of all life cycle activities, both static and dynamic, concerned with planning, preparation and evaluation of software products and related work products to determine that they satisfy specified requirements, to demonstrate that they are fit for purpose and to detect defects." (Tilo Linz et al, "Software Testing Foundations, 4th Ed", 2014)

"Verifying that a program does what it is supposed to do - and doesn’t do what it is not supposed to do." (Matt Telles, "Beginning Programming", 2014)

"Software testing provides the mechanism for verifying that the requirements identified during the initial phases of the project were properly implemented and that the system performs as expected. The test scenarios developed through these competitions ensure that the requirements are met end-to-end." (Kamalendu Pal & Bill Karakostas, "Software Testing Under Agile, Scrum, and DevOps", 2021)

"A set or one of more test cases" (IEEE 829)

"Activity that verifies that a CI, service or process meets its specifications or agreed requirements" (ITIL)

🌁Software Engineering: Quality (Definitions)

"The totality of characteristics of an entity that bear on its ability to satisfy stated or implied needs." (Timothy J  Kloppenborg et al, "Project Leadership", 2003)

"The degree to which a system, component, or process meets specified requirements, user needs, or stakeholder expectations." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

"The degree or grade of excellence. In a product-development context, it is a product with superior features that performs on target with low variability throughout its intended life. In an economic context, it is the absence or minimization of costs associated with the purchase and use of a product or process." (Clyde M Creveling, "Six Sigma for Technical Processes: An Overview for R Executives, Technical Leaders, and Engineering Managers", 2006)

"A measure of the acceptability or 'goodness” of a system or element'." (Bruce P Douglass, "Real-Time Agility: The Harmony/ESW Method for Real-Time and Embedded Systems Development", 2009)

"1.The degree to which a set of inherent characteristics fulfills requirements. Quality is a multi-faceted concept. The dimensions of quality that are considered most important depend on user perspectives, needs and priorities, which vary across groups of users. 2.Adjective. In common use, of or having superior or high quality, or being perceived as superior, without specific qualification. 3.A peculiar and essential character, the degree of some characteristic meeting expectations. Quality is defined through four virtues - clarity, elegance, simplicity, and value." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"The degree to which a set of inherent characteristics fulfills requirements." (Cynthia Stackpole, "PMP® Certification All-in-One For Dummies®", 2011)

"The predetermined standard of excellence that may be applied to a product or service to measure how closely the product or service conforms to the standard and satisfies the customer." (Joan C Dessinger, "Fundamentals of Performance Improvement" 3rd Ed., 2012)

"A comparative concept that described the relative ability of two or more competing processes to drive outcomes. A higher-quality process drives a better outcome when considering a full variety of direct and indirect sources of value. Quality is subjective, and depending on organizational and personal objectives, the perception of which process is higher quality may vary." (Evan Stubbs, "Delivering Business Analytics: Practical Guidelines for Best Practice", 2013)

"A relative and unique concept that in effect refers to the standard of something as measured against other things of a similar kind; the degree of excellence of something." (Sally-Anne Pitt, "Internal Audit Quality", 2014)

"1. The totality of characteristics and their values relating to a product or service. They relate to the product’s ability to fulfill specified or implied needs. 2. The degree to which a component, system, or process meets user/customer needs and expectations. 3. The degree to which a set of inherent characteristics fulfills requirements." (Tilo Linz et al, "Software Testing Foundations, 4th Ed", 2014)

"A quality is an attribute or property of a resource. A quality is logically ascribable by a subject. (Ed.)" (Robert J Glushko, "The Discipline of Organizing: Professional Edition" 4th Ed., 2016)

"A subjective term for which each person or sector has its own definition. In technical usage, quality can have two meanings: 1) the characteristics of a product or service that bear on its ability to satisfy stated or implied needs; 2) a product or service free of deficiencies." (American Society for Quality)

"Software that meets business requirements, provides asatisfying user experience, and has fewer defects." (Forrester)

"the ability of a product, service or process to provide the intended value" (ITIL)

"The degree to which a component, system or process meets specified requirements and/or user/customer needs and expectations." [IEEE 610]

"The degree to which a set of inherent characteristics fulfills requirements." (ISO 9000:2000, SDMX) 

"The totality of features of a product or service that fulfill stated or implied needs." (ISO 8402)

"The totality of functionality and features of a software product that bear on its ability to satisfy stated or implied needs." (ISO/IEC 25000)

🌁Software Engineering: Black Box (Definitions)

"Objects or chunks of code that can function independently, where changes made to one part of a piece of software will not affect others." (Gavin Powell, "Beginning Database Design", 2006)

"A component or device with an input and an output, whose inner workings need not be understood by or accessible to the user." (Judith Hurwitz et al, "Service Oriented Architecture For Dummies" 2nd Ed., 2009)

"A risk model that lacks transparency of its specific risk assumptions, measures, and findings. These models sometimes create as many risks for the organization as they are meant to manage." (Annetta Cortez & Bob Yehling, "The Complete Idiot's Guide® To Risk Management", 2010)

"A component or device with an input and an output whose inner workings need not be understood by or accessible to the user." (Marcia Kaufman et al, "Big Data For Dummies", 2013)

"Is a metaphor describing how people are unable to see or understand how technologies work and is particularly used to characterize the lack of understanding of how an algorithm works. While we can understand the outputs of artificial intelligence (AI) - in terms of recommendations, decisions and so on - the processes to achieve them are too complicated for us to understand. Concerns about the black box nature of AI center on its apparent lack of accountability, potential unseen biases and the inability to have clear visibility into what is driving an AI’s potentially life-changing decisions." (Accenture)

🌁Software Engineering: Feature (Definitions)

"An attribute of a component or system specified or implied by requirements documentation (for example reliability, usability or design constraints). (IEEE 1008) 

"A product capability or attribute that fulfills a specific customer or market need and provides an appropriate benefit. A mobile device battery with a long life (the feature) meets the need of a customer who uses their portable device for communicating and Web browsing (needs)." (Steven Haines, "The Product Manager's Desk Reference", 2008)

[features:] "The specific attributes of a product or service." (Gina Abudi & Brandon Toropov, "The Complete Idiot's Guide to Best Practices for Small Business", 2011)

"Feature is used in data science and machine learning contexts for both “raw” or observable variables and “latent” ones, extracted or constructed from the original set." (Robert J Glushko, "The Discipline of Organizing: Professional Edition" 4th Ed, 2016)

"A distinctive factual attribute of a product or service." (Pamela Schure & Brian Lawley, "Product Management For Dummies", 2017)

"An aspect of system state (e.g., audit logs, network activity) that can be monitored for potential use in the detection of some phenomena of interest, such as an attack on a target system." (O Sami Saydjari, "Engineering Trustworthy Systems: Get Cybersecurity Design Right the First Time", 2018)

"A distinguishing characteristic of a software item (e.g., performance, portability, or functionality)." (IEEE 829)

"In a machine learning context, a feature is an attribute of an input, especially a numerical attribute. For example, if the input is a document, the number of unique tokens in the document is a feature. The words present in a document are also referred to as features." (Alex Thomas, "Natural Language Processing with Spark NLP", 2020)

🌁Software Engineering: Fault Tolerance (Definitions)

"A property of neural computing systems that allows the system to function and gradually degrade when a small number of processing elements are destroyed or disabled." (Guido Deboeck & Teuvo Kohonen (Eds), "Visual Explorations in Finance with Self-Organizing Maps" 2nd Ed., 2000)

"Fault Tolerance is the ability of an IT system to continue to function as designed even though a fault has occurred." (Martin Oberhofer et al, "Enterprise Master Data Management", 2008)

"The ability of a system to provide an uninterrupted service, despite the failure of one or more of the system’s components." (Judith Hurwitz et al, "Service Oriented Architecture For Dummies" 2nd Ed., 2009)

"The ability of a system or component to continue normal operation despite the presence of hardware or software faults." (Mark S Merkow & Lakshmikanth Raghavan, "Secure and Resilient Software Development", 2010)

"The capability of a system to provide uninterrupted service despite the failure of one or more of the system’s components." (Marcia Kaufman et al, "Big Data For Dummies", 2013)

"1. The capability of the software product or a component to maintain a specified level of performance in case of wrong inputs (see also robustness). 2. The capability of the software product or a component to maintain a specified level of performance in case of software faults (defects) or of infringement of its specified interface." (Tilo Linz et al, "Software Testing Foundations" 4th Ed., 2014)

"The ability of a system to tolerate a fault and continue to operate. Fault tolerance systems often use redundant hardware, such as additional hard drives or additional servers, to eliminate a single point of failure." (Darril Gibson, "Effective Help Desk Specialist Skills", 2014)

"Ability to continue operate after failure of a component part" (ITIL)

"The capability of the software product to maintain a specified level of performance in cases of software faults (defects) or of infringement of its specified interface." (ISO 9126)

🌁Software Engineering: Design Pattern (Definitions)

"A design pattern is a reusable solution for a software design problem. Patterns are platform independent, the same pattern can be used in different environments." (Jens Dietrich, "From Business Rules to Application Code: Code Generation Patterns for Rule Defined Associations", 2009)

"A way of representing a contextualized solution to a design problem with sufficient precision and explanation that it is an effective guide to action, but allowing scope for creative adaptation to specific needs." (Peter Goodyear & Dai F Yang, "Patterns and Pattern Languages in Educational Design", 2009)

"Common solutions to common problems, particularly in software design." (Tony C Shan & Winnie W Hua, "Data Caching Patterns" [in "Encyclopedia of Information Communication Technology"] 2009)

"Defines and explains systematically a general design to a recurrent problem of design in object oriented system." (Fuensanta Medina-Domínguez et al, "Patterns in the Field of Software Engineering" [in "Encyclopedia of Information Science and Technology" 2nd Ed.], 2009)

"Describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that one can use this solution a million times over without ever doing it the same way twice." (Franca Garzotto & Symeon Retalis, "A Critical Perspective on Design Patterns for E-Learning", 2009)

"Design patterns are standard solutions to common problems in software design." (Ghita K Mostéfaoui, "Software Engineering for Mobile Multimedia: A Roadmap", 2009)

"Design patterns represent solutions to problems that arise when developing software within a particular context. Design patterns capture the static and dynamic structure and collaboration among key participants in software designs. Design patterns are generic design pieces that need to be instantiated before uses." (Jing Dong et al, "Design Patterns from Theory to Practice" [in "Encyclopedia of Information Science and Technology" 2nd Ed.], 2009)

"Expressing the gist of a solution so that it can be reused many times. Defining a pattern, or a pattern system, is a way to capture the design knowledge of a community, to share it and to leverage it for future developments." (Eddy Boot et al, "Supporting Decision Making in Using Design Languages for Learning Designs and Learning Objects", 2009)

"In software engineering, it is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. [...] Design patterns deal specifically with problems at the level of software design." (Salvatore Scifo, "Accessing Grid Metadata through a Web Interface", 2009)

"A design pattern is a general, proven, and beneficial solution to a common, reoccurring problem in software design. Built upon similar experiences, design patterns represent 'best-practices' about how to structure or build a software architecture." (Jörg Rech et al, "Knowledge Patterns" [in "Encyclopedia of Knowledge Management" 2nd Ed.], 2011)

"A semi-formal way of documenting a solution to a design problem in a particular field of expertise." (Manuel Ecker et al, "Game-Based Learning Design Patterns: An Approach to Support the Development of 'Better' Educational Games", 2011)

"A well-tried solution to a common problem that captures experience and good practice in a form that can be reused. It is an abstract representation than can be instantiated in a number of ways." (Ian Sommerville, "Software Engineering" 9th Ed., 2011)

"General solution for a common problem that occurs when designing software. A design pattern is reusable, so that it might be applied in many systems that suffer of a common problem." (Márcio Ribeiro et al, "Recommending Mechanisms for Modularizing Mobile Software Variabilities", 2012)

"[...] a design pattern [...] describes a solution to a 'typical' software design problem. A pattern provides a general template for a solution that can be applied in many different situations. It describes the main elements of a solution in an abstract way that can be specialized for a specific problem at hand." (Michael T Goodrichet al, "Data Structures and Algorithms in Python", 2013)

"A design pattern is an abstract description of best practice that has worked successfully in different systems and environments, and it acts as a reusable solution that may be used in many situations. It is more a description or template on how to solve the problem within a particular context, rather than a finished solution." (Gerard O’Regan, "Concise Guide to Software Engineering: From Fundamentals to Application Methods", 2017)

"Design patterns consists of shared guidelines helping design problems. Design patterns commonly used in software engineering and is also used in ontological engineering to solve common problems." (Galip Kaya & Arif Altun, "Educational Ontology Development" [in "Encyclopedia of Information Science and Technology" 4th Ed.], 2018)

🌁Software Engineering: Arity (Definitions)

 "How many terms an operator takes. The possible values for a C++ operator's arity are unary, binary, and ternary." (Jesse Liberty, "Sams Teach Yourself C++ in 24 Hours" 3rd Ed., 2001)

"The characteristic defining the quantity allowed in a relationship. For example, unary = 1, binary = 2, and ternary = 3." (Sharon Allen & Evan Terry, "Beginning Relational Data Modeling" 2nd Ed., 2005)

"The number of arguments to a function." (Dean Wampler & Alex Payne, "Programming Scala", 2009)

"In object role modeling, the number of objects t a role in a predicate, or relationship." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"The degree or arity of a relationship is the number of entity types or categories of resources in the relationship. This is usually, though not always, the same as the number of arguments in the relationship expression." (Robert J Glushko, "The Discipline of Organizing: Professional Edition" 4th Ed., 2016)

🌁Software Engineering: Patterns (Definitions)

"A named description of a problem, solution, when to apply the solution, and how to apply the solution in new contexts." (Craig Larman, "Applying UML and Patterns", 2004)

"A named strategy for solving a recurring problem." (Bruce MacIsaac & Per Kroll, "Agility and Discipline Made Easy: Practices from OpenUP and RUP", 2006)

"A reusable entity representing knowledge and experience aggregated by an expert in solving a recurring problem in a domain." (Pankaj Kamthan, "A Perspective on Software Engineering Education with Open Source Software", 2007)

"Patterns (in the computer science sense) describe best practice solutions and different realization variants of a special group of systems. Patterns are abstractions from concrete forms. Examples are architecture patterns, design patterns, and process patterns." (Alke Martens & Andreas Harrer, "Software Engineering in e-Learning Systems", Encyclopedia of Information Technology Curriculum Integration, 2008)

"Patterns provide a proven solution to a repeating problem in a given context. In other words, patterns should be considered as a way to put artifacts into context and to describe a reusable solution to a recurring problem. These artifacts can be best practices, guidelines, services, blueprints, source code skeletons, and frameworks." (Martin Oberhofer et al, "Enterprise Master Data Management", 2008)

"A common combination of logic, interactions, and behaviors that form a consistent or characteristic arrangement. An important use of patterns is the idea of design templates that are general solutions to integration problems. They will not solve a specific problem, but they provide a sort of architectural outline that may be reused in order to speed up the development process." (David Lyle & John G Schmidt, "Lean Integration: An Integration Factory Approach to Business Agility", 2010)

"A recurring combination of data and task management, separate from any specific algorithm. Patterns are universal in that they apply to and can be used in any programming system. Patterns have also been called dwarfs, motifs, and algorithmic skeletons. Patterns are not necessarily tied to any particular hardware architecture or programming language or system." (Michael McCool et al, "Structured Parallel Programming", 2012)

"A general reusable solution to a commonly occurring problem within a given context." Sergey V Zykov, "Crisis Response and Management", 2018) 

🌁Software Engineering: Service-Oriented Architecture [SOA] (Definitions)

"A technology framework to support the design, development, and deployment of diverse business applications in a loosely coupled way. The goal of SOA is to encourage reuse of both data and functionality via the use of units of work (services) that are made available to different business processes across the enterprise." (Jill Dyché & Evan Levy, "Customer Data Integration", 2006)

"SOA is an architectural paradigm for dealing with business processes distributed over a large and heterogeneous landscape of existing and new systems that are under the control of different owners." (Nicolai M Josuttis, "SOA in Practice", 2007)

"An architectural style for creating an enterprise architecture that exploits the principles of service orientation to achieve a tighter relationship between the business and the information systems that support the business." (Tilak Mitra et al, "SOA Governance", 2008)

"A method for organizing a company's entire information system functions so all information components are viewed as services that are provided to the organization." (Jan L Harrington, "Relational Database Design and Implementation" 3rd Ed., 2009)

"A way of designing software applications for reusability and flexibility. It involves designing loosely coupled software components called services." (John Goodson & Robert A Steward, "The Data Access Handbook", 2009)

"An architectural style in which software systems are modular and some components (service providers) are distributable, discoverable, substitutable, and shareable." (W Roy Schulte & K Chandy, "Event Processing: Designing IT Systems for Agile Companies", 2009)

"An architecture that enables IT resources to be made available to other participants in a network as independent services that are accessed in a standardized way without knowledge of the underlying platform implementation." (David G Hill, "Data Protection: Governance, Risk Management, and Compliance", 2009)

"An IT infrastructure that allows disparate applications to exchange data and use consistent processes as they interact with each other. SOA is the foundation architecture for data services." (Tony Fisher, "The Data Asset", 2009)

"An architectural style to enable loosely coupled systems and promote re-usable services based on open standards." (Martin Oberhofer et al, "The Art of Enterprise Information Architecture", 2010)

"Defines a development paradigm which has loosely coupled, distributed modules called 'services' as its build blocks. Services offer clear interfaces through which service consumers can discover and make use of them." (Carlos Kamienski et al, "Managing the Future Internet: Services, Policies and Peers", 2010)

"In its most general sense, an approach for architectures where the interfaces are services. In a more specific sense, it is an architectural style for dealing with business processes distributed over a large and heterogeneous landscape of existing and new systems that are under the control of different owners." (David Lyle & John G Schmidt, "Lean Integration", 2010)

"The software design and implementation architecture of loosely coupled, coarse-grained, reusable services that can be integrated with each other through a wide variety of platform-independent service interfaces." (Alex Berson & Lawrence Dubov, "Master Data Management and Data Governance", 2010)

"An architectural concept that defines the use of services to support a variety of business needs. In SOA, existing IT assets (called services) are reused and reconnected rather than the more time consuming and costly reinvention of new systems." (Linda Volonino & Efraim Turban, "Information Technology for Management" 8th Ed, 2011)

"An application architecture in which all functions, or services, are created with invokable interfaces that are called to perform business processes." (Craig S Mullins, "Database Administration", 2012)

"An approach to building applications that implements business processes or services by using a set of loosely coupled black-box components orchestrated to deliver a well-defined level of service." (Marcia Kaufman et al, "Big Data For Dummies", 2013)

"A software design and software architecture design pattern independent of any vendor, product, or technology and based on discrete pieces of software providing application functionality as services to other applications. For instance, this software design defines how two computing entities, such as programs, interact in such a way as to enable one entity to perform a unit of work on behalf of another entity." (Jim Davis & Aiman Zeid, "Business Transformation: A Roadmap for Maximizing Organizational Insights", 2014)

"An information technology architecture that separates infrastructure, applications, and data into layers." (Robert F Smallwood, "Information Governance: Concepts, Strategies, and Best Practices", 2014)

"Style of architecture based on the concept of service, designed to simplify interactions between architecture blocks while providing the system with significant flexibility." (Gilbert Raymond & Philippe Desfray, "Modeling Enterprise Architecture with TOGAF", 2014)

"A design similar to a component-based architecture except the pieces are implemented as services." (Rod Stephens, "Beginning Software Engineering", 2015)

"Service-Oriented Architecture expresses an architecture that define the use of software services." (Laura C Rodriguez-Martinez et al, "Service-Oriented Computing Applications (SOCA) Development Methodologies: A Review of Agility-Rigor Balance", 2021)

"A multitier architecture relying on services that support computer-to-computer interaction over a network." (Oracle, "Oracle Database Concepts")

"Service-oriented architecture (SOA) is a design paradigm and discipline that helps IT meet business demands. Some organizations realize significant benefits using SOA including faster time to market, lower costs, better application consistency and increased agility. SOA reduces redundancy and increases usability, maintainability and value. This produces interoperable, modular systems that are easier to use and maintain." (Gartner) 

"Service‑oriented architecture (SOA) is an architectural approach to designing applications around a collection of independent services. A service can be any business functionality that completes an action and provides a specific result, such as processing a customer order or compiling an inventory report." (NGINX) [source] 

🌁Software Engineering: Design Review (Definitions)

"A formal, documented, comprehensive, and systematic examination of a design to evaluate the design requirements and the capability of the design to meet these requirements, and to identify problems and propose solutions." (Sandy Shrum et al, "CMMI: Guidelines for Process Integration and Product Improvement", 2003)

"A process or meeting during which a system, hardware, or software design is presented to stakeholders for comment or approval." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

"the quality-assurance process in which all aspects of a system are reviewed publicly prior to the striking of code." (William H Inmon, "Building the Data Warehouse", 2005)

[preliminary design review (PDR):] "in a traditional waterfall process, a review of the preliminary architectural concepts, meant to ensure the validity of subsequent work. In the Harmony/ESW process, the PDR is optional but can be performed at the end of a microcycle in which the primary architectural concerns have been addressed." (Bruce P Douglass, "Real-Time Agility: The Harmony/ESW Method for Real-Time and Embedded Systems Development", 2009)

"A formal, documented, comprehensive, and systematic examination of a design to evaluate the design requirements and the capability of the design to meet these requirements, and to identify problems and propose solutions." (Mark S Merkow & Lakshmikanth Raghavan, "Secure and Resilient Software Development", 2010)

"A process where all aspects of a system design are reviewed publicly before code construction starts." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"A series of meetings wherein all aspects of the database and application code are reviewed for efficiency, effectiveness, and accuracy." (Craig S Mullins, "Database Administration: The Complete Guide to DBA Practices and Procedures" 2nd Ed., 2012)

"A series of meetings wherein all aspects of the database and application code are reviewed for efficiency, effectiveness, and accuracy." (Craig S Mullins, "Database Administration", 2012)

" the scheduled-in checkpoints for assessing the design progress towards meeting product requirements and budget." (Atila Ertas, "Transdisciplinary Engineering Design Process", 2018)