Difference between revisions of "Glossary"

From EITBOK
Jump to: navigation, search
m
Line 2: Line 2:
 
<tr valign="top"><td width="15%">'''Term'''</td><td>'''Meaning'''</td></tr>
 
<tr valign="top"><td width="15%">'''Term'''</td><td>'''Meaning'''</td></tr>
 
<tr valign="top"><td>acceptable</td><td>meeting stakeholder expectations that can be shown to be reasonable or merited (Source: ISO/IEC Std. 38500:2008, Corporate governance of information technology, ISO/IEC, 2008)</td></tr>
 
<tr valign="top"><td>acceptable</td><td>meeting stakeholder expectations that can be shown to be reasonable or merited (Source: ISO/IEC Std. 38500:2008, Corporate governance of information technology, ISO/IEC, 2008)</td></tr>
<tr valign="top"><td>acceptance criteria</td><td>(1) the criteria that a system or component must satisfy in order to be accepted by a user, customer, or other authorized entity (Source: ISO/IEC/IEEE Std. 24765:2010, Systems and software engineering &mdash; Vocabulary, ISO/IEC/IEEE, 2010) <br />(2) those criteria, including performance requirements and essential conditions, which must be met before project deliverables are accepted (Source: A Guide to the Project Management Body of Knowledge [PMBOK[R] Guide] &mdash; Fourth Edition)</td></tr>
+
<tr valign="top"><td id="acceptance_criteria">acceptance criteria</td><td>(1) the criteria that a system or component must satisfy in order to be accepted by a user, customer, or other authorized entity (Source: ISO/IEC/IEEE Std. 24765:2010, Systems and software engineering &mdash; Vocabulary, ISO/IEC/IEEE, 2010) <br />(2) those criteria, including performance requirements and essential conditions, which must be met before project deliverables are accepted (Source: A Guide to the Project Management Body of Knowledge [PMBOK[R] Guide] &mdash; Fourth Edition)</td></tr>
 
<tr valign="top"><td>acquisition</td><td>(1) The process of obtaining a system, product, or service and ensuring its successful implementation. Acquisition also includes ensuring that proper mechanisms are in place to monitor the supplier’s/vendors’ performance in providing support and fulfilling other contractual obligations. Original to ITBOK.<br />(2) The process of obtaining a system or software product (Source: IEEE Std. 1062-1998, IEEE Recommended Practice for Software Acquisition, IEEE, 1998)<br />(3) the process of obtaining a system, software product or software service (Source: ISO/IEC 12207:2008, Systems and software engineering &mdash; Software life cycle processes, 4.2)<br />(4) the process of obtaining a system product or service (Source: ISO/IEC 15288:2008, Systems and software engineering &mdash; System life cycle processes, 4.2)</td></tr>
 
<tr valign="top"><td>acquisition</td><td>(1) The process of obtaining a system, product, or service and ensuring its successful implementation. Acquisition also includes ensuring that proper mechanisms are in place to monitor the supplier’s/vendors’ performance in providing support and fulfilling other contractual obligations. Original to ITBOK.<br />(2) The process of obtaining a system or software product (Source: IEEE Std. 1062-1998, IEEE Recommended Practice for Software Acquisition, IEEE, 1998)<br />(3) the process of obtaining a system, software product or software service (Source: ISO/IEC 12207:2008, Systems and software engineering &mdash; Software life cycle processes, 4.2)<br />(4) the process of obtaining a system product or service (Source: ISO/IEC 15288:2008, Systems and software engineering &mdash; System life cycle processes, 4.2)</td></tr>
 
<tr valign="top"><td>acquisition strategy</td><td>specific approach to acquiring products and services that is based on considerations of supply sources, acquisition methods, requirements specification types, contract or agreement types, and related acquisition risks (Source: ISO/IEC 24765:2009, Systems and software engineering vocabulary)</td></tr>
 
<tr valign="top"><td>acquisition strategy</td><td>specific approach to acquiring products and services that is based on considerations of supply sources, acquisition methods, requirements specification types, contract or agreement types, and related acquisition risks (Source: ISO/IEC 24765:2009, Systems and software engineering vocabulary)</td></tr>

Revision as of 21:51, 16 October 2015

TermMeaning
acceptablemeeting stakeholder expectations that can be shown to be reasonable or merited (Source: ISO/IEC Std. 38500:2008, Corporate governance of information technology, ISO/IEC, 2008)
acceptance criteria(1) the criteria that a system or component must satisfy in order to be accepted by a user, customer, or other authorized entity (Source: ISO/IEC/IEEE Std. 24765:2010, Systems and software engineering — Vocabulary, ISO/IEC/IEEE, 2010)
(2) those criteria, including performance requirements and essential conditions, which must be met before project deliverables are accepted (Source: A Guide to the Project Management Body of Knowledge [PMBOK[R] Guide] — Fourth Edition)
acquisition(1) The process of obtaining a system, product, or service and ensuring its successful implementation. Acquisition also includes ensuring that proper mechanisms are in place to monitor the supplier’s/vendors’ performance in providing support and fulfilling other contractual obligations. Original to ITBOK.
(2) The process of obtaining a system or software product (Source: IEEE Std. 1062-1998, IEEE Recommended Practice for Software Acquisition, IEEE, 1998)
(3) the process of obtaining a system, software product or software service (Source: ISO/IEC 12207:2008, Systems and software engineering — Software life cycle processes, 4.2)
(4) the process of obtaining a system product or service (Source: ISO/IEC 15288:2008, Systems and software engineering — System life cycle processes, 4.2)
acquisition strategyspecific approach to acquiring products and services that is based on considerations of supply sources, acquisition methods, requirements specification types, contract or agreement types, and related acquisition risks (Source: ISO/IEC 24765:2009, Systems and software engineering vocabulary)
ADKAR modelA goal-oriented change management model that allows change management teams to focus their activities on specific business results. The model has its origins in aligning traditional change management activities to a given result or goal. (Source: http://www.change-management.com/tutorial-adkar-overview-mod1.htm)
AOAanalysis of alternatives
BCAbusiness case analysis
BCPbusiness continuity plan
BMMbusiness (enterprise) motivation model
BUbusiness unit
CBAcost benefit analysis
change agentA person from inside or outside an organization who helps the organization transform itself by focusing on such matters as organizational effectiveness, improvement, and development. (Source: study.com/academy/lesson/change-agent-definition-role-quiz.html)
CMDBconfiguration management database
CMMIcapability maturity model integration
CMMI for Acquisition (CMMI-ACQ)product and service acquisition
CMMI for Data (CMMI-DMM)data management
CMMI for Development (CMMI-DEV)product and service development
CMMI for Services (CMMI-SVC)service establishment and management
COBITControl Objectives for Information and Related Technology
conceptual designdescribes the proposed solution in a functional manner that could be easily understood by a future user, including what the solution will look like and how it will behave
ConOpsA concept of operations document. A ConOps is a user-oriented document that describes system characteristics for a proposed system from the users’ viewpoint. The ConOps document is used to communicate overall quantitative and qualitative system characteristics to the user, buyer, developer, and other organizational elements (for example, training, facilities, staffing, and maintenance). It is used to describe the user organizations, missions, and organizational objectives from an integrated systems point of view.
constraint(1) an externally imposed limitation on system requirements, design, or implementation or on the process used to develop or modify a system (IEEE Std. 29148-2011, Systems and software engineering — Life cycle processes — Requirements engineering, IEEE, 2011)
(2) a statement that expresses measurable bounds for an element or function of the system (IEEE Std. 29148-2011, Systems and software engineering — Life cycle processes — Requirements engineering, IEEE, 2011)
contractbinding agreement between two parties, especially enforceable by law, or a similar internal agreement wholly within an organization (Source: ISO/IEC 12207:2008, Systems and software engineering — Software life cycle processes, ISO/IEC, 2008)
COTS commercial off the shelf
CPconsolidated platform
CSPcost schedule performance
DoDAFDepartment of Defense Architecture Framework, an architecture framework for the United States Department of Defense (DoD) that provides visualization infrastructure for specific stakeholders concerns through viewpoints organized by various views
domainA specific sphere of activity or knowledge. A domain can correspond to the boundaries of an organization, a job function, or even a particular task.
domain elicitationcollecting the right information from SMEs, stakeholders, or consumers about how the solution should function
DRdisaster recovery:
1) In computer system operations, the return to normal operation after a hardware or software failure.
2) Activities and programs designed to return the organization to an acceptable condition. The ability to respond to an interruption in services by implementing a disaster recovery plan to restore an organization's critical business functions. td>
DRPdisaster recovery plan, a set of human, physical, technical, and procedural resources to recover, within a defined time and cost, an activity interrupted by an emergency or disaster
DTdisaster tolerance, the time gap a business can accept the non-availability of EIT facilities
EAenterprise architecture
EITenterprise information technology
FLURPSfunctionality, localizability, usability, reliability, performance, supportability
FSMfunctional size measurement
GSCglobal standards collaboration
HITSRHealthcare Information Technology Standards Panel
ICTinformation and communications technology
IEEEInstitute of Electrical and Electronics Engineers
INCITSInternational Committee for Information Technology Standards
ISACAInformation Systems Audit and Control Association
ISOInternational Organization for Standardization
ITinformation technology
ITILinformation technology infrastructure library
ITSCinformation technology support center
IVRinteractive voice response
KAknowledge area
KPIkey performance indicator
KTBRkeep the business running
KTLOkeep the lights on
LCCElife cycle cost estimate
logical designdefines objects, entities, their attributes, and their relationships. It also describes the business rules associated with these entities
MOEmeasures of effectiveness
NISTNational Institute of Standards and Technology
OCMorganizational change management
OLAoperational level agreement
physical designAlso called the technical design. Where the conceptual and logic designs are converted to a definition of how the solution will be implemented in hardware, software, and potentially other media. The physical design is developed by the construction team not by the requirements team.
PMO
QAquality assurance
QCquality control
QMSquality management system
resource managementidentification, estimation, allocation, and monitoring of the means used to develop a product or perform a service (Source: ISO/IEC/IEEE Std. 24765:2010, Systems and software engineering — Vocabulary, ISO/IEC/IEEE, 2010)
RFI request for information
RFP request for proposal
RFQrequest for quotation
RFTrequest for tender
riska function of the probability of occurrence of a given threat and the potential adverse consequences of that threat’s occurrence (Source: ISO/IEC Std. 15026-3:2011, Systems and software engineering — Systems and software assurance — Part 3: System integrity levels, ISO/IEC, 2011)
ROIreturn on investment
RPOrecovery point objective, the point in time all integrated systems are to be recovered to, taking into account sync points and data transfer points to ensure data quality and integrity
RTOrecovery time objective, long it will take to return an EIT service to active duty
SaaSsoftware as a service
SAT
SCMsoftware configuration management plan
SDDSoftware design description. An SDD is a representation of a software system that is used as a medium for communicating software design information.
service catalogue(ITIL service design) A database or structured document with information about all live EIT services, including those available for deployment. The service catalogue is the only part of the ITIL service portfolio published to customers, and is used to support the sale and delivery of IT services. the service catalogue includes information about deliverables, prices, contact points, ordering, and request processes.
SFIASkills Framework for the Information Age
shadow EITshadow enterprise information technology
SLAservice level agreement
SPLCPsoftware project life-cycle process
SMEsubject matter expert
SOservice operations
solutiona set of changes to the current state of an enterprise that will enable the enterprise to meet a need, solve a problem, or take advantage of an opportunity
SOXSarbanes Oxley
SPOCsingle point of contact
SRSsoftware requirements specification
stakeholdera person or group that has an investment, share, or interest in something, as a business or industry. (Source: http://dictionary.reference.com/browse/stakeholder)
SWECOMsoftware engineering competency model, formerly known as SECOM
SWOTstrengths, weaknesses, opportunities. and threats involved in a project or in a business venture (Source: A Guide to the Project Management Body of Knowledge [PMBOK[R] Guide], Fourth Edition)
SyRSsystem requirements specification
TCOtotal cost of ownership
TOGAFThe Open Group Architecture Framework
UAT
V&Vsoftware verification and validation