An Abbreviated Software Engineering Glossary
This glossary is intended for those visitors to the RSP&A web-site who may be unfamiliar with basic software engineering terminology. All definitions are informal.
Abstraction - (1) the level of technical detail of some representation of software; (2) a cohesive model of data or an algorithmic procedure
Action (also called Software engineering action) - a named collection of software engineering tasks (e.g., "interface design") that occurs within a software engineering activity
Activity (also called Software engineering activity) - see Framework activity
Adaptive maintenance - activity associate with changing an application to make it conform to changes in its external environment
Aesthetic design - a Web engineering action that focuses on the aesthetics (e.g., the artistic elements) of a WebApp (often encompasses graphic design)
Agile development (also referred to as agile process model) - an adapted version of software engineering that emphasizes customer communication, incremental software delivery, informal methods and work products, and highly motivated teams.
Analysis - a set of activities that attempt to understand and model customer needs and constraints
Analysis methods - a notation and heuristics for creating models of customer needs and constraints
Architectural design - an activity that attempts to layout the module "floor plan" for the software
Architecture - the overall structure of software components, the data and/or content that components manipulate, and the relationships between them
Aspect-oriented development - a development approach that emphasizes "concerns" (also called "aspectual requirements" that incorporate features, functions and information content) that cut across multiple system functions
Automated estimation tools - tools that help in estimating project cost or effort
Automatic code generation - tools that generate source code from a representation of software that is not source code
Baseline - a point at which some deliverable produced during the software engineering process is put under formal change control
Basis path testing - a white box test case design technique that used the algorithmic flow of the program to design tests
Basis set - the set of tests derived using basis path testing
Behavioral modeling - representing the mode of behavior (called states) of an application and the events that cause transitions from state to state
Beta testing - testing that is conducted by the user
Black box testing - testing that does not focus on the internal details of the program but uses external requirements
Boundary value analysis - a black box testing method that designs test cases that exercise data boundaries
Bounding - removing ambiguity from specification
Builds - see Clusters
Business risks - the set of potential business problems or occurrences that may cause the project to fail
CASE - Computer-aided software engineering, see also, Tools
Cause-effect graphing - a black-box testing method
Change control - an umbrella process that enables a project team to accept, evaluate, and act on changes in a systematic manner
Change control authority (CCA) - the person(s) who have responsibility for deciding whether a change is to be made
Change management - a set of software engineering actions that helps ensure that changes are properly identified, controlled, and reported
Change report - provides detail on the nature of work required to make a change
Change request - provides detail on the type of change that is requested
Chief programmer team - one way of organizing project staff
Classes - a basic construct in object-oriented methods that categorizes elements of the problem
Classic life cycle - a linear, sequential approach to process modeling
Clusters - a collection of program components (modules) that is tested as a group
Coding - the generation of source code
Cohesion - an informal measure of the degree to which a software component implements a single, focused function
Complexity - a quantitative measure of a program's complexity
Component (also called Software component) - a named, modular building block for computer software
Component reuse - the ability to reuse a portion of a model, source code, test case, etc.
Configuration - the collection of programs, documents and data that must be controlled when changes are to be made
Configuration audit - an activity performed by an SQA group with the intent of ensuring that the change control process is working
Configuration control - the control of changes to programs, documents or data
Configuration items - the individual pieces of programs, documents and data that are controlled using SCM
Configuration status reporting (CSR) - an activity that help software developer to understand what changes have been made and why
Constraints - an restrictions or limitations placed on requirements or design
Corrective maintenance - finding and fixing defects that have been reported by users
Coupling - an informal measure of the degree to which a software component is connected to other components, to data, and to the external environment
CRC (class-responsibility-collaborator) modeling - an object-oriented modeling method that identifies and organizes classes are are relevant to a system
Customer - the person or group that has requested the software and will be paying the bill for its development
Cyclomatic complexity - a measure of the logical complexity of an algorithm, used in white-box testing
Data design - an activity that translates the data model developed during analysis into implementable data structures
Data dictionary - a database that contains definitions of all data items defined during analysis; see also, Requirements dictionary
Data flow diagram (DFD) - a modeling notation that represents a functional decomposition of a system
Data modeling - an analysis method that models data objects and their relationships
Data objects - an input or output that is user visible
Data warehouse - a large, independent database that has access to databases that serve many different applications that are required by a business
Debugging - the activity associated with finding and correcting an error or defect - a lack of conformance to requirements found in the software after delivery to the customer
Defect amplification - when a defect is introduced early in the software process and remains undetected, it often is amplified into multiple defects later in the software process
Defect removal efficiency (DRE) - a nondimension ratio (between 0 and 1) that provides an indication of the degree to which errors are removed from software before it is released to end-users
Design - an activity that translates the requirements model into a more detailed model that is the guide to implementation of the software
Design specification - a document that describes the design
Design walkthrough - a formal technical review of the design
Detail design - a design activity that focuses on the creation of an algorithm
Documentation - descriptive information
Documents - deliverables produced as part of the software engineering process
Domain analysis - an object-oriented software engineering activity that attempts to identify classes that are relevant to an entire application domain, rather than a specific application
Effort - the work-time product (e.g., person-days) associated with a project
Engineering change order (ECO) - a mini-specification that describes the technical aspects of a change
Enhancement - an extension of functional or performance requirements
Equivalence partitioning - a black-box testing method
Errors - a lack of conformance found before software is delivered to the customer
Estimation - a project planning activity that attempts to project effort and cost for a software project
Extreme programming - an agile process model that emphasizes scenario-based planning, incremental delivery, refactoring, pair programming and continuous testing.
Factoring - a technique that distributes control and work in a top-down manner within a software architecture (used a part of structured analysis)
FAST - Facilitated application specification techniques, a structured meeting between developer and customer; intent is to define basic requirements
Formal methods - a software engineering approach in which specification and design are described using mathematically-based formal notation
Formal technical reviews - a structured meeting conducted by software engineering with the intent of uncovering errors in some deliverable or work product
Formulation - a Web engineering action that identifies business need, describes WebApp objectives, defines major features and functions, and establishes mechanisms for requirements gathering
Function points - a measure of the utility delivered by an application
Functional decomposition - a technique used during planning, analysis and design; creates a functional hierarchy for the software
Go, no-go decision - a point at which manager or the customer decides whether the project should proceed
GQM (Goal, Question, Metric) paradigm - a technique for defining meaningful metrics for any part of the software process
Grammatical parse - a technique that is used during analysis and intended to help isolate basic data objects and functions
High-order tests - black-box tests conducted once the software has been integrated
Independent test group (ITG) - a group of people whose primary responsibility is software testing
Interface design - a software engineering action that establishes the structure and workflow for a user interface; follows three "golden rules:" place the user in control, reduce the user's memory leoad, make the interface consistent.
Integration testing - a testing step that constructs the software while testing it
Integration - the specific approach to integration testing
Interoperability - the degree to which one application communicates or interfaces with another
ISO 9001:2000 - a quality assurance standard that applies to software engineering
Joint application development (JAD) - a specific FAST technique
Levels of abstraction - the degree of detail with which some representation of the software is presented
Line-of-code metrics - measures of quality or productivity that are normalized using lines of code produced
Load testing - a testing task that determines how software (often a WebApp) will respond to various loading conditions
LOC - lines of code
Loop testing - a white box testing technique that exercises program loops
Maintainability - the degree to which a program is amenable to change
Maintenance - the activities associated with changes to software after it has been delivered to end-users
Make-buy decision - determining whether software should be built internally, acquired, contracted or built from reusable components
Measurement - collecting quantitative data about the software or the software engineering process
Metrics - a specific measurement
Milestones - a point in time that is used to indicate progress during a project
Modular design - a design approach that stresses modularity
Modularity - an attribute of a design that leads to the creation of high quality program components
Navigation analysis - a Web engineering action that establishes how a user will navigate between various elements (e.g., content, functions) of a WebApp
Object-oriented - an approach to software development that makes use of a classification approach and packages data and processing together
Object-oriented analysis (OOA) - a technique for defined classes of objects, their relationships and basic structure
Object-oriented design (OOD) - a technique for translating the OOA model into an implementation model
Objects - a named element of the problem domain containing data and processing
OCL (Object Constraint Language) - a supplement to UML, this formal language allows a software engineer to construct unambiguous statements about the characteristics of various design model elements
Outsourcing - contracting software work to a third party
Pair programming - two people work together (side-by-side) to design and construct a software component, providing real-time problem solving and quality control.
Paper prototype - a paper representation of an application (e.g., story boards that describe the interaction at a human interface)
Paradigms - the process model
Patterns - a stylized description or characterization of a software problem or capability and/or the manner in which a solution to the problem or capability may be characterized, applied, and implemented
PDL - program design language; a combination of natural language with programming language-like constructs
Perfective maintenance - enhancement,
Portability - the ability to transport software from one target environment to another
Preliminary design - creates representation of the data and architecture
Procedural design - creates representations of algorithmic detail within a module
Process framework - a relatively small set of fundamental software engineering activities that define a software process
Processing narrative - a natural language description of a model (program component)
Productivity - work output per unit time
Program design language, see PDL
Project database - the place where configuration items are kept
Project Plan - a description of the management approach for a project
Project planning - the activity that creates the Project Plan
Project risks - the set of potential project problems or occurrences that may cause the project to fail
Project scope - a statement of basic requirements of the software to be built
Project size - an indication of the overall effort to be expended or the number of people working on the project
Project tracking - the activity that enables a manager to understand the status of a project
Project control - the control of quality and change
Prototyping - the creation of a mock-up of an application
Quality - the degree to which a product conforms to both explicit and implicit requirements
Quality function deployment (QFD) - a technique that translates the needs of a customer in technical requirements for software by assessing the value of each requirement
Quality management - a set of software engineering actions that helps ensure that software is built in a way that achieves high quality
Quality metrics - measures of quality
Re-engineering - a series of activities that transform legacy systems (with poor maintainability) into software that exhibits high quality
Refactoring - changing software in a way that improves its internal structure but does not change it external behavior; often conducted iteratively as design evolves into code.
Regression testing - tests that are conducted repeated to ensure that a change has not introduced side effects
Reliability - a measure of the degree to which software operates reliably over some period of time
Repository - see Project Database
Requirements analysis - a modeling activity whose objective is to understand what the customer really wants
Requirements engineering - the activities required to elicit, elaborate, negotiate, specify, and validate system or software requirements
Resources - anything that is required to get the project done, people, hardware, materials, information, etc.
Reusability - the ability to reuse an already-existing program component in another application
Reusable components - configuration items that are reusable
Reverse engineering - trying to develop design models or an understanding of design using program code as a starting point
Reviews - see formal technical reviews
Risk - a potential problem or occurrence that put a project in jeopardy
Risk analysis - a techniques for identifying and evaluating risks
Risk Management and Monitoring Plan (RMMP) - a plan for mitigating, monitoring and managing risks
Scheduling - the activity that lays out a timeline for work to be conducted on a project
Scope - a bounded statement of what must be accomplished
Security - the ability of software to operate in a manner that is secure from internal or external attack
Security testing - testing tasks that probe the vulnerability of both client-side and server-side software
Selective testing - testing only a selected set of program paths and data inputs
Side effects - errors that occur because of changes
Six sigma - a widely used strategy for statistical quality assurance
Smoke testing - an integration testing approach that constructs and tests software on a daily basis
Software - programs, documents and data
Software engineering - a discipline that encompasses the process associated with software development, the methods used to analyze, design and test computer software, the management techniques associated with the control and monitoring of software projects and the tools used to support process, methods, and techniques
Software maintenance - see also, Maintenance,
Software metrics - quantitative measures of the process or the product
Software problem report - a report of a defect
Software quality - see quality
Software process improvement (SPI) - a set of software engineering activities that attempt to improve the state of software engineering practice within an organization
Software quality assurance (SQA) - a series of activities that assist an organization in producing high quality software
Software Requirements Specification - a deliverable that describes all data, functional and behavioral requirements, all constraints, and all validation requirements for software
Software safety - an SQA activity that focuses on the identification and assessment of potential hazard that may have a negative impact on the operation of software
Software testing - a set of activities conducted with the intent of finding errors in software
Spiral model - an evolutionary software engineering paradigm
Stakeholders - any person of group that has a stake in the successful completion of a software project
State transition diagram (STD) - a notation for behavioral modeling
Statistical quality assurance - techniques for process improvement that are based on measurements of the product and the process
Stepwise refinement - a technique for accomplishing functional decomposition or procedural design (also called partitioning)
Stress testing - a testing task that determines how software responds when it is forced to meet or exceed operational limits
Structured programming - a design method that limited design constructs to only three basic forms and constrains program flow for better quality
System engineering - focuses on the analysis and design of all elements of a complete product, service, or technology for the transformation of information or control
Task analysis - a software engineering action that is conducted as part of user interface design; intended to better understand how a user is to interact with a system
Task set - a collection fo software engineering tasks that are required to complete an activity or action that is part of a software process framework
Technical risks - the set of potential technical problems or occurrences that may cause the project to fail
Test case design - a set of techniques for deriving effective test cases
Test cases, derivation of - the creation of data that can be used to uncover errors in the software
Test plan and procedure - a description of testing strategy and tactics
Testing - a set of activities that attempt to find errors
Time-boxing - a project scheduling and control technique that establishes time boundaries for the completion of a specific project task
Tools - application software used to perform software engineering tasks (e.g., design tools, testing tools); see also CASE tools
Total quality management - a company commitment to develop a process that achieves high quality product and customer satisfaction
UML (Unified Modeling Language) - a comprehensive diagrammatic notation for the analysis and design of software
Unified process - a "use-case driven, architecture-centric, iterative and incremental" software process that emphasizes the use of UML notation
Unit testing - part of the testing strategy that focuses on tests to individual program components
Usability - An informal measure of the ease with which a user interface can be learned and applied with efficiency and without errors
Use-case - a written description that defines a very specific interaction between a user and a system, often (but not always) written in the form of a usage scenario
User - the person who actually used to software or the product that has software embedded within it
User hierarchy - a hierarchical representation of the categories of users that will interact with any type of software
User-story - a usage scenario that is used as part of Extreme programming
Validation - tests to ensure that the software conforms to its requirements
WebApps (Web Applications) - any application that delivers meaningful content or functionality to end users via the Web.
Web engineering - the application of software engineering principles, concepts, and methods (or adaptations of them) to the development of Web-based applications or systems.
White box testing - a test case design technique that makes use of a knowledge of the internal program logic
Work breakdown structure (WBS) - the set of work tasks required to build the software; defined as part of the process model
Work flow - the sequence of tasks that are required to accomplish some activity or action; often (but not always) used in conjunction with software process models
Work product - any cohesive and persistent information that is produced as a consequence of one or more software engineering actions of tasks
|
