🌁Software Engineering: Granularity (Definitions)

"An important software design concept, especially in relation to components. The amount of detail or functionality - from fine to coarse - provided within a service component. One software component can do something quite simple, such as calculate a square root. Or, it can have a great deal of detail and functionality to represent a complex business rule or workflow. The first is fine grained, and the second coarse grained. Developers often aggregate fine-grained services into coarse-grained services to create a business service." (Judith Hurwitz et al, "Service Oriented Architecture For Dummies" 2nd Ed., 2009)

"Loosely defined as the amount of computation done before synchronization is needed. The longer the time between synchronizations, the coarser the granularity will be. Fine-grained parallelism runs the danger of not having enough work assigned to threads to overcome the overhead costs of using threads. Adding more threads, when the amount of computation doesn’t change, only exacerbates the problem. Coarse-grained parallelism has lower overhead costs and tends to be more readily scalable to an increase in the number of threads." (Clay Breshears, "The Art of Concurrency", 2009)

"A description, from "coarse" to "fine", of a computer activity or feature (such as screen resolution, searching and sorting, or time slice allocation) in terms of the size of the units it handles (pixels, sets of data, or time slices). The larger the pieces, the coarser the granularity." (Microsoft, "SQL Server 2012 Glossary", 2012)

"The amount of decomposition applied to the parallelization of an algorithm, and the grain size of that decomposition. If the granularity is too coarse, there are not enough parallel tasks to effectively make use of all parallel hardware units and hide latency. If the granularity is too fine, there are too many parallel tasks and overhead may dominate the computation." (Michael McCool et al, "Structured Parallel Programming", 2012)

🌁Software Engineering: Interface (Definitions)

"(1) A shared boundary across which information is passed. (2) A hardware or software component that connects two or more other components for the purpose of passing information from one to the other. (3) To connect two or more components for the purpose of passing information from one to the other. (4) To serve as a connecting or connected component as in (2)."  (IEEE, "IEEE Standard Glossary of Software Engineering Terminology", 1990)

"(1) A shared boundary between two or more hardware or software components that conveys power and/or information from one to the other (2) To connect two or more components for the purpose of passing power and/or information from one to the other." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

"An interface exists between different systems or between systems and networks when considered within the context of computer technology. An interface can also refer to the way in which people interact with a computer or other type of device (a user interface or graphical user interface). An interface can also have an organizational connotation where one organization works closely with (interfaces with) another. There are other definitions based on the industry context. However, these may be most common to product managers." (Steven Haines, "The Product Manager's Desk Reference", 2008)

"The connection between two components of a system. Analysis is concerned with the data content of an interface, and design is concerned with the behavior and appearance of the interface." (James Robertson et al, "Complete Systems Analysis: The Workbook, the Textbook, the Answers", 2013)

"Interconnection and interrelation between, for example, people, systems, devices, applications, and so on." (Gilbert Raymond & Philippe Desfray, "Modeling Enterprise Architecture with TOGAF", 2014)

🌁Software Engineering: Specification (Definitions)

"A document used in procurement or development that describes the technical requirements for products, components, or services, usually including the procedures to be used to determine that the requirements have been met. Large systems may have multiple levels of specifications. Some specifications are common to multiple systems or products (e.g., interface definitions)." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

"A specific quantifiable set point that typically has a nominal or target value and a tolerance of acceptable values associated with it. This is what results when a team tries to use tools and best practices to fulfill a requirement. Requirements are hopefully completely fulfilled by a final design specification - but many times they are not." (Lynne Hambleton, "Treasure Chest of Six Sigma Growth Methods, Tools, and Best Practices", 2007)

"A detailed coherent statement of particulars. A requirements specification details requirements whereas a design specification details the design of a system or element." (Bruce P Douglass, "Real-Time Agility: The Harmony/ESW Method for Real-Time and Embedded Systems Development", 2009)

"A document that specifies, ideally in a complete, precise, concrete and verifiable form, the requirements or other characteristics of a component or system. It serves the developers as a basis for programming, and it serves the testers as a basis for developing test cases with black box test design methods. (Often, a specification includes procedures for determining whether these requirements have been satisfied.) special software Software developed for one or a group of customers." (Tilo Linz et al, "Software Testing Foundations" 4th Ed, 2014)

"A precise statement of the needs to be satisfied and the essential characteristics that are required." (Project Management Institute, "A Guide to the Project Management Body of Knowledge (PMBOK® Guide )", 2017)

"A statement of the intended functionality of a given system." (O Sami Saydjari, "Engineering Trustworthy Systems: Get Cybersecurity Design Right the First Time", 2018)

"A document that specifies, ideally in a complete, precise and verifiable manner, the requirements, design, behavior, or other characteristics of a system or component, and, often, the procedures for determining whether these provisions have been satisfied" (IEEE 610)

Software Engineering: Quality Attribute (Definitions

[quality characteristic:] "A measured response that relates to a general or specific requirement that can be an attribute or a continuous variable. The quantifiable measure of performance that directly affects the customer’s satisfaction. Often in DFSS, these have to be converted to an engineering scalar or vector." (Clyde M Creveling, "Six Sigma for Technical Processes: An Overview for R Executives, Technical Leaders, and Engineering Managers", 2006)

"1. A characteristic of a software product used to judge or describe its quality. A software quality attribute can also be refined through several steps into partial attributes. 2. Ability or characteristic which influences the quality of a unit." (Tilo Linz et al, "Software Testing Foundations, 4th Ed", 2014)

"A feature or characteristic that affects an item’s quality." (IEEE 610)

"A set of attributes of a software product by which its quality is described and evaluated. A software quality characteristic may be refined into multiple levels of sub-characteristics (ISO 9126)

🌁Software Engineering: Baseline (Definitions)

"A set of specifications or work products that has been formally reviewed and agreed on, which thereafter serves as the basis for further development, and which can be changed only through change control procedures capability evaluation An appraisal by a trained team of professionals used as a discriminator to select suppliers, for contract monitoring, or for incentives. Evaluations are used to help decision makers make better acquisition decisions, improve subcontractor performance, and provide insight to a purchasing organization." (Sandy Shrum et al, "CMMI®: Guidelines for Process Integration and Product Improvement", 2003)

"In configuration management, the initial approved technical data package (including, for software, the source code listing) defining a configuration item during the production, operation, maintenance, and logistic support of its life cycle." (Sandy Shrum et al, "CMMI®: Guidelines for Process Integration and Product Improvement", 2003)

"A set of configuration items (software documents and software components) that has been formally reviewed and agreed upon, that thereafter serves as the basis for future development, and that can be changed only through formal change control procedures." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

"(1) A specification, document, software element, hardware item, or product that has been formally reviewed and approved by designated stakeholders at a specific time during the configuration item’s life cycle. Thereafter, it serves as the basis for further development and can be changed only through formal change control procedures. (2) The action of placing any product under formal configuration control." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

"The approved documentation describing all the functional and physical characteristics of a product, and those functional and physical characteristics selected for its acceptance testing." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

"A set of data or information about an aspect of a business (or product) that provides a point of perspective from which future options can be evaluated. A baseline analysis during the product strategy formulation process allows a product manager to assess the past and current business and market environment for a product, so that future strategic options can be considered." (Steven Haines, "The Product Manager's Desk Reference", 2008)

"A configuration describing a particular development level (e.g., a requirements baseline, design baseline, or baseline related to the production of releases). Associated and related configuration items are 'preserved' when forming a baseline, i.e., they are protected against changes." (Lars Dittmann et al, "Automotive SPICE in Practice", 2008)

"Benchmark used as a reference point" (ITIL)

[configuration baseline] "Baseline of a configuration that has been formally agreed and is managed through the Change Management process." (ITIL)

🌁Software Engineering: Scalability (Definitions)

"A characteristic of a system that provides increased performance with the addition of resources. SQL Server is scalable. For example, it can use memory or additional processors to accommodate more user connections." (Microsoft Corporation, "SQL Server 7.0 System Administration Training Kit", 1999)

"The ability to accommodate future growth requirements." (Ralph Kimball & Margy Ross, "The Data Warehouse Toolkit" 2nd Ed., 2002)

"The capacity of a thing to expand to accommodate future requirements." (Sharon Allen & Evan Terry, "Beginning Relational Data Modeling" 2nd Ed., 2005)

"Used to indicate that an application can handle an increased workload to accommodate a growing number of users. Scalability is accomplished by either scaling up (by increasing the hardware capacity of the current server) or scaling out, (by increasing the number of servers)." (Sara Morganand & Tobias Thernstrom , "MCITP Self-Paced Training Kit : Designing and Optimizing Data Access by Using Microsoft SQL Server 2005 - Exam 70-442", 2007)

"The capability of a product, service, or platform to be readily enlarged or expanded to handle greater capacity than offered by a single instantiation, whether through replication, customization, or additional supporting elements." (Steven Haines, "The Product Manager's Desk Reference", 2008)

"The ability of an application to maintain acceptable response time and throughput when the number of simultaneous users increases." (John Goodson & Robert A Steward, "The Data Access Handbook", 2009)

"The ability to support increasing numbers of users in cost-effective increments without adversely affecting business operations." (Paulraj Ponniah, "Data Warehousing Fundamentals for IT Professionals", 2010)

"The ability to scale to support larger or smaller volumes of data and more or less users. The ability to increase or decrease size or capability in cost-effective increments with minimal impact on the unit cost of business and the procurement of additional services." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"The capability of the software product to be upgraded to accommodate increased loads." (Requirements Engineering Qualifications Board, "Standard glossary of terms used in Requirements Engineering", 2011)

"Being able to add additional capacity incrementally, quickly and as needed." (Linda Volonino & Efraim Turban, "Information Technology for Management 8th Ed", 2011)

"The ability to increase or decrease size or capability in cost-effective increments with minimal impact on the unit cost of business and the procurement of additional services." (Craig S Mullins, "Database Administration", 2012)

"In regard to hardware, the capability to go from small to large amounts of processing power with the same architecture. It also applies to software products such as databases, in which case it refers to the consistency of performance per unit of power as hardware resources increase." (Marcia Kaufman et al, "Big Data For Dummies", 2013)

"The ability of a software application to function well and with minimal loss of performance, despite changing computing environments; the volume of computations, users, or data. Scalable software is able to take full advantage of increases in computing capability such as those that are provided by the use of SMP hardware and threaded processing." (Jim Davis & Aiman Zeid, "Business Transformation: A Roadmap for Maximizing Organizational Insights", 2014)

"It is the capacity of the system to handle increasing amount work without affecting existing system." (Dharmendra T Patel, "Distributed Computing for Internet of Things (IoT)", 2019)

"Ability to perform in agreed function/parameters when the workload or scope changes" (ITIL)

🌁Software Engineering: Failure Modes & Effects Analysis [FMEA] (Definitions)

"A risk-analysis technique that identifies and ranks the potential failure modes of a design or process and then prioritizes improvement actions." (Clyde M Creveling, "Six Sigma for Technical Processes: An Overview for R Executives, Technical Leaders, and Engineering Managers", 2006)

"An approach to analyzing the effect of faults on system reliability." (Bruce P Douglass, "Real-Time Agility: The Harmony/ESW Method for Real-Time and Embedded Systems Development", 2009)

"An analytical procedure in which each potential failure mode in every component of a product is analyzed to determine its effect on the reliability of that component and, by itself or in combination with other possible failure modes, on the reliability of the product or system and on the required function of the component; or the examination of a product (at the system and/or lower levels) for all ways that a failure may occur. For each potential failure, an estimate is made of its effect on the total system and of its impact. In addition, a review is undertaken of the action planned to minimize the probability of failure and to minimize its effects." (For Dummies, "PMP Certification All-in-One For Dummies, 2nd Ed.", 2013)

"Approach that dissects a component into its basic functions to identify flaws and those flaw’s effects." (Adam Gordon, "Official (ISC)2 Guide to the CISSP CBK" 4th Ed., 2015)

"(1) A process for analysis of potential failure modes within a system for classification by severity or determination of the effect of failures on the system. (2) A structured method for analyzing risk by ranking and documenting potential failure mode in a system, design or process. The analysis includes: identification of potential failures and their effects; ranking of factors (e.g., severity, frequency of occurrence, detectability of the potential failures); and identification and results of actions taken to reduce or eliminate risk." (International Aerospace Quality Group)

"A systematic approach to risk identification and analysis of identifying possible modes of failure and attempting to prevent their occurrence." (SQA)

"FMEA (failure modes effects analysis) is a technique used in product life cycle management activities to predict how a product or process might fail and what the effects of that failure might be." (Gartner)

🌁Software Engineering: Functional Testing (Definitions)

"Testing that ignores the internal mechanism of a system or component and focuses solely on the outputs generated in response to selected inputs and execution conditions." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

"1. Checking functional requirements. 2. Dynamic test for which the test cases are developed based on an analysis of the functional specification of the test object. The completeness of this test (its coverage) is assessed using the functional specification." (Tilo Linz et al, "Software Testing Foundations, 4th Ed", 2014)

"Security testing in which advertised security mechanisms of an information system are tested under operational conditions to determine if a given function works according to its requirements." (William Stallings, "Effective Cybersecurity: A Guide to Using Best Practices and Standards", 2018)

"Testing based on an analysis of the specification of the functionality of a component or system." (Software Quality Assurance)

🌁Software Engineering: Functional Requirement (Definitions)

"Something that the product must do. Functional requirements are part of the fundamental processes of the product." (Suzanne Robertson & James Robertson, "Mastering the Requirements Process" 2nd Ed., 2006)

"A requirement that directly influences and describes functionality." (Lars Dittmann et al, "Automotive SPICE in Practice", 2008)

"Defines a function of a software system or its component. A function is described as a set of inputs, the behavior, and outputs. Functional requirements may be calculations, technical details, data manipulation and processing, and other specific functionalities that define what a system is supposed to accomplish." (Mark S Merkow & Lakshmikanth Raghavan, "Secure and Resilient Software Development", 2010)

"A description of expected behavior of a system given a defined set of inputs or events." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"A requirement that specifies a function that a component or system must perform." (Tilo Linz et al, "Software Testing Foundations" 4th Ed., 2014)

"Detailed statements of the project’s wanted capabilities. They’re similar to the user requirements but may also include things that the users won’t see directly such as interfaces to other applications." (Rod Stephens, "Beginning Software Engineering", 2015)

"A requirement that specifies a function that a system or system component must be able to perform." (IEEE-STD-610)

🌁Software Engineering: Complexity (Definitions)

"A measure of the numbers and types of interrelationships among system elements. Generally speaking, the more complex a system, the more difficult it is to design, build, and use." (Atul Apte, "Java Connector Architecture: Building Custom Connectors and Adapters", 2002)

"Expresses a condition of numerous elements in a system and numerous forms of relationships among the elements. In general usage, complexity tends to be used to characterize something with many parts in intricate arrangement. In science there are at this time a number of approaches to characterizing complexity." (Aldo Romano & Giustina Secundo (Eds.),, "Dynamic Learning Networks: Models and Cases in Action", 2009)

"How difficult the new product will be perceived by the end-user. High complexity can become a barrier to diffusion." (Gina C O'Connor & V K Narayanan, "Encyclopedia of Technology and Innovation Management", 2010)

"The degree to which the new system is perceived to be difficult to understand and use, measured on a continuum from easy to difficult." (Linda Volonino & Efraim Turban, "Information Technology for Management" 8th Ed,, 2011)

"A characteristic of a program or project or its environment, which is difficult to manage due to human behavior, system behavior, and ambiguity." (Project Management Institute, "Navigating Complexity: A Practice Guide", 2014)

"An interdisciplinary lens through which to articulate the learning behaviours in/of systems wherein perpetual emergence and adaption occurs. Central to the understanding of complexity is the notion that individual agents within the system are involved in continuously negotiated and in-flux self-organization and decentralized control." (Kathy Sanford & Tim Hopper, "Digital Media in the Classroom: Emergent Perspectives for 21st Century Learners", Handbook of Research on Digital Media and Creative Technologies, 2015)

"Complexity is a phenomenon that involves a lot of interaction and interference between a very large number of units." (Mauro Chiarella, "Folds and Refolds: Space Generation, Shapes, and Complex Components", 2016)

"The condition of having many diverse and autonomous but interrelated and interdependent components linked through many dense interconnections." (Kijpokin Kasemsap, "Utilizing Complexity Theory and Complex Adaptive Systems in Global Business", Handbook of Research on Chaos and Complexity Theory in the Social Sciences, 2016)

"Refers to the inherent difficulty in accomplishing a computational task such as sorting a list or establishing the trustworthiness of an entire system." (O Sami Saydjari, "Engineering Trustworthy Systems: Get Cybersecurity Design Right the First Time", 2018)

"(1) The degree to which a system or component has a design or implementation that is difficult to understand and verify. (2) Pertaining to any of a set of structure-based metrics that measure the attribute in (1)." (IEEE Std 610.12-1990) 

 "The degree to which a component or system has a design and/or internal structure that is difficult to understand, maintain and verify." (SQA)

🌁Software Engineering: Rapid Application Development (Definitions)

"A tool than enables you to design and build a complete application quickly." (Greg Perry, "Sams Teach Yourself Beginning Programming in 24 Hours" 2nd Ed., 2001)

"A method of building computer systems in which the system is programmed and implemented in segments, rather than waiting until the entire project is completed for implementation. Developed by programmer James Martin, RAD uses such tools as CASE and visual programming." (Microsoft, "SQL Server 2012 Glossary", 2012)

"An approach to software development that is highly evolutionary in nature that typically involves significant amounts of user interface prototyping." (Pramod J Sadalage & Scott W Ambler, "Refactoring Databases: Evolutionary Database Design", 2006)

"Methods, tools and techniques that dramatically accelerate application development time." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"Development models that emphasize producing code and deemphasize planning. These models produce code iteratively and incrementally as quickly as possible. RAD principles include small teams, frequent customer interaction, frequent integration and testing, and short time-boxed iterations." (Rod Stephens, "Beginning Software Engineering", 2015)

🌁Software Engineering: Component Model (Definitions)

"A component diagram and the corresponding documentation for that diagram. A component diagram shows the software components, their interrelationships, interactions, and public interfaces that comprise the software for a small component, an application, or the software architecture for an entire enterprise." (Scott W Ambler & Larry L Constantine, "The Unified Process Construction Phase: Best Practices for Completing the Unified Process", 2000)

"A set of standards for component implementation, documentation and deployment." (Ian Sommerville, "Software Engineering" 8th Ed., 2007)

"Component models provide the basis for middleware to support executing components." (Ian Sommerville, "Software Engineering" 8th Ed., 2007)

"A component model is a specification of patterns for component implementation, documentation, deployment, and usage." (Elthon Oliveira et al, "Formal Modeling and Verification of Virtual Community Systems", Encyclopedia of Networked and Virtual Organizations, 2008)

"Structure adopted to develop any software element of a given application or library." (Emmanuel Dubois et al, "Modelling and Simulation of Mobile Mixed Systems", 2008)

"The MDM Component Model refers to the set of technical architecture diagrams and associated descriptions that provide lower-level specifications about the MDM Reference Architecture." (Allen Dreibelbis et al, "Enterprise Master Data Management", 2008)

"Describes the structure of specific types of content, for example, a recipe, a value proposition, or an overview. Component models can be used over and over again with different content. The structure remains the same; only the content changes." (Charles Cooper & Ann Rockley, "Managing Enterprise Content: A Unified Content Strategy" 2nd Ed., 2012)

🌁Software Engineering: Audit (Definitions)

"In CMMI process improvement work, an independent examination of a work product or set of work products to determine whether requirements are being met." (Sandy Shrum et al, "CMMI: Guidelines for Process Integration and Product Improvement", 2003)

"An independent examination of work products or work processes to assess compliance with defined processes, procedures, standards, specifications, or other criteria." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

"An inspection of the plans, procedures, or records of a part of a business to determine whether or not a plan was followed and if a desired outcome was achieved. In this book, an audit looks into various aspects of a product launch or a bidding situation (win/loss)." (Steven Haines, "The Product Manager's Desk Reference", 2008)

"In the context of security, a review of a system in order to validate the security of the system. Generally, this either refers to code auditing or reviewing audit logs." (Mark S Merkow & Lakshmikanth Raghavan, "Secure and Resilient Software Development", 2010)

"Review of a company’s financial and accounting records and supporting documents by a professional, such as a certified public accountant. This also refers to an examination of an individual’s or a corporation’s tax returns to verify accuracy." (Sue Johnson & Gwen Moran, "The Complete Idiot's Guide® To Business Plans", 2010)

"An independent evaluation of software products or processes to ascertain compliance to standards, guidelines, specifications, and/or procedures based on objective criteria, including documents that specify the following: 
- The form or content of the products to be produced 
- The process by which the products shall be produced
- How compliance to standards or guidelines shall be measured." (Tilo Linz et al, "Software Testing Foundations" 4th Ed, 2014)

"The systematic, independent and documented process for obtaining audit evidence and evaluating it objectively to determine the extent to which the audit criteria are fulfilled" (David Sutton, "Information Risk Management: A practitioner’s guide", 2014)

"An independent assessment that takes a well-defined approach to examining an organization’s internal policies, controls, and activities." (Weiss, "Auditing IT Infrastructures for Compliance" 2nd Ed, 2015)

"A systematic assessment of significant importance to the organization that determines whether the system or process being audited satisfies some external standards." (Shon Harris & Fernando Maymi, "CISSP All-in-One Exam Guide" 8th Ed, 2018)

 "An independent evaluation of software products or processes to ascertain compliance to standards, guidelines, specifications, and/or procedures based on objective criteria, including documents that specify: (1) The form or content of the products to be produced (2) The process by which the products shall be produced (3) How compliance to standards or guidelines shall be measured [IEEE 1028]." (Software Quality Assurance)

"Formal inspection and verification to check whether a standard or set of guidelines is being followed, that records are accurate, or that efficiency and effectiveness targets are being met" (ITIL)

🌁Software Engineering: Reverse Engineering (Definitions)

"The process of analyzing existing software code and associated documentation to recover its architectural design and specification." (Ian Sommerville, "Software Engineering", 1996)

"The process of analyzing a subject system with two goals in mind: (1) to identify the system’s components and their interrelationships; and, (2) to create representations of the system in another form or at a higher level of abstraction." (Margaret Y Chu, "Blissful Data", 2004)

"Reverse engineering is the process of discovering the functions and their interrelationships of a software system as well as creating representations of the system in another form or at a higher level of abstraction." (Chia-Chu Chiang, "Software Modernization of Legacy Systems for Web Services Interoperability", 2008)

"the construction of a model from a set of source code files." (Bruce P Douglass, "Real-Time Agility: The Harmony/ESW Method for Real-Time and Embedded Systems Development", 2009)

"The process of transforming code into a model through a mapping from a specific implementation language." (Liliana M Favre et al, Foundations for MDA Case Tools", 2009)

[database reverse engineering:] "The process through which the logical and conceptual schemas of a legacy database, or of a set of files, are recovered, or rebuilt, from various information sources such as DDL code, data dictionary contents, database contents, or the source code of application programs that use the database." (Jean-Luc Hainaut et al, "Database Reverse Engineering", 2009)

"The process of transforming the physical schema of any particular database into a logical model." (Paulraj Ponniah, "Data Warehousing Fundamentals for IT Professionals", 2010)

"The process of deriving a draft physical model representing an implemented system (application and/or database) from automated scanning of the implemented application and database objects, as a first step towards redesign." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"The process of discovering the technological principles of a device, object or system through analysis of its structure, function and operation." (Tian Ge & Jianfeng Feng, "Granger Causality: Its Foundation and Applications in Systems Biology", 2011) 

"The process of taking a competitor's product apart and putting it back together again to better understand the manufacturing process and the product design." (Leslie G Eldenburg & Susan K Wolcott, "Cost Management" 2nd Ed., 2011)

"The process of analyzing and comprehending available software artifacts, such as requirements, design, architectures and code in order to extract information and provide high-level views of the system." (Liliana Favre et al, "Reverse Engineering of Object-Oriented Code: An ADM Approach" , 2015)

"It is a process in which a machine is completely dismantled in order to understand the intricacies of the machine. Finally, it is reassembled with added improvisation." Kuldeep K Saxena & Ankita Awasthi, "Novel Additive Manufacturing Processes and Techniques in Industry 4.0", 2020)

"The analysis of a subject system to identify its components and their interrelationships, and to create its representations in another form, or at higher level of abstraction." (Djelloul Bouchiha, "Reengineering Legacy Systems Towards New Technologies", 2021)

🌁Software Engineering: Waterfall Development (Definitions)

"A method in which each stage is completed before the product is passed on to the next stage. Each stage is discrete and self-contained." (Jesse Liberty, "Sams Teach Yourself C++ in 24 Hours" 3rd Ed., 2001)

"The simplest sequential software process model, where the analysis, design, coding, and testing phases are done sequentially for the entire system." (Johannes Link & Peter Fröhlich, "Unit Testing in Java", 2003)

"A product development process that follows the sequence of analyze, design, code, and test. The underlying assumption is that each phase does not begin until the preceding phase is complete. There are no overlaps or iterations." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

"A predictive development where each project phase flows into the next." (Rod Stephens, "Beginning Software Engineering", 2015)

"A methodical and linear approach to technical development. While rigorous, waterfall development usually implies going through an entire development lifecycle before deploying functionality to end users, and usually begins with business analysis. See Top-down development." (Evan Levy & Jill Dyché, "Customer Data Integration", 2006)

"An approach to software development in which the requirements, architecture, design, implementation, integration, and testing are sequentially defined." (Bruce MacIsaac & Per Kroll, "Agility and Discipline Made Easy: Practices from OpenUP and RUP", 2006)

"A sequential software development process in which progress is seen as flowing steadily downward (like a waterfall) through the phases of conception, initiation, analysis, design, development, testing, and deployment." (Mark S Merkow & Lakshmikanth Raghavan, "Secure and Resilient Software Development", 2010)

"A systems development methodology that dictates the completion of one activity before beginning the next." (James Robertson et al, "Complete Systems Analysis", 2013)

"The SDLC, so called because any one development activity must be done before the next activity can begin and because the output from any one level of activity becomes the input into the next level." (Daniel Linstedt & W H Inmon, "Data Architecture: A Primer for the Data Scientist", 2014)

"A development model that uses a series of waterfall cascades. Each cascade ends with the delivery of a usable application called an increment." (Rod Stephens, "Beginning Software Engineering", 2015)

"A linear and sequential development methodology where, for the product development part, product managers define all aspects of the product before it is given to engineering to create. There is no official role for feedback loops and flexible changes in waterfall development." (Pamela Schure & Brian Lawley, "Product Management For Dummies", 2017)

"A method of deploying software or systems in which development moves through a series of fairly well-defined stages. With large projects, once each stage is complete, it cannot be easily reversed, much as it is impossible to move up a waterfall. This traditional system engineering flow allows for a requirements-driven process that leads to assured and verified function. Note that although this indicates a linear sequence through the stages, the ability to iterate and propagate changes discovered in one facet to the others is typically observed." (William Stallings, "Effective Cybersecurity: A Guide to Using Best Practices and Standards", 2018)