Difference between revisions of "Glossary"
From EITBOK
m |
|||
| Line 5: | Line 5: | ||
<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 — 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 — 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 — 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 — 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> | ||
| + | <tr valign="top"><td>ADKAR model</td><td>A 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)</td></tr> | ||
<tr valign="top"><td>AOA</td><td>analysis of alternatives</td></tr> | <tr valign="top"><td>AOA</td><td>analysis of alternatives</td></tr> | ||
<tr valign="top"><td>BCA</td><td>business case analysis</td></tr> | <tr valign="top"><td>BCA</td><td>business case analysis</td></tr> | ||
<tr valign="top"><td>BCP</td><td>business continuity plan</td></tr> | <tr valign="top"><td>BCP</td><td>business continuity plan</td></tr> | ||
<tr valign="top"><td>BMM</td><td>business (enterprise) motivation model</td></tr> | <tr valign="top"><td>BMM</td><td>business (enterprise) motivation model</td></tr> | ||
| + | <tr valign="top"><td>BU</td><td>business unit</td></tr> | ||
<tr valign="top"><td>CBA</td><td>cost benefit analysis</td></tr> | <tr valign="top"><td>CBA</td><td>cost benefit analysis</td></tr> | ||
| − | <tr valign="top"><td>CMMI</td><td> | + | <tr valign="top"><td>change agent</td><td>A 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)</td></tr> |
| − | <tr valign="top"><td>CMMI for Acquisition (CMMI-ACQ)</td><td> | + | <tr valign="top"><td>CMDB</td><td>configuration management database</td></tr> |
| − | <tr valign="top"><td>CMMI for Data (CMMI-DMM)</td><td> | + | <tr valign="top"><td>CMMI</td><td>capability maturity model integration</td></tr> |
| − | <tr valign="top"><td>CMMI for Development (CMMI-DEV)</td><td> | + | <tr valign="top"><td>CMMI for Acquisition (CMMI-ACQ)</td><td>product and service acquisition</td></tr> |
| − | <tr valign="top"><td>CMMI for Services (CMMI-SVC)</td><td> | + | <tr valign="top"><td>CMMI for Data (CMMI-DMM)</td><td>data management</td></tr> |
| + | <tr valign="top"><td>CMMI for Development (CMMI-DEV)</td><td>product and service development</td></tr> | ||
| + | <tr valign="top"><td>CMMI for Services (CMMI-SVC)</td><td>service establishment and management</td></tr> | ||
<tr valign="top"><td>COBIT</td><td>Control Objectives for Information and Related Technology</td></tr> | <tr valign="top"><td>COBIT</td><td>Control Objectives for Information and Related Technology</td></tr> | ||
<tr valign="top"><td>conceptual design</td><td>describes 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</td></tr> | <tr valign="top"><td>conceptual design</td><td>describes 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</td></tr> | ||
| Line 24: | Line 28: | ||
<tr valign="top"><td>domain</td><td>A specific sphere of activity or knowledge. A domain can correspond to the boundaries of an organization, a job function, or even a particular task.</td></tr> | <tr valign="top"><td>domain</td><td>A specific sphere of activity or knowledge. A domain can correspond to the boundaries of an organization, a job function, or even a particular task.</td></tr> | ||
<tr valign="top"><td>domain elicitation</td><td>collecting the right information from SMEs, stakeholders, or consumers about how the solution should function</td></tr> | <tr valign="top"><td>domain elicitation</td><td>collecting the right information from SMEs, stakeholders, or consumers about how the solution should function</td></tr> | ||
| + | <tr valign="top"><td>DR</td><td>disaster recovery:<br />1) In computer system operations, the return to normal operation after a hardware or software failure.<br />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></tr> | ||
| + | <tr valign="top"><td>DRP</td><td>disaster 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</td></tr> | ||
| + | <tr valign="top"><td>DT</td><td>disaster tolerance, the time gap a business can accept the non-availability of EIT facilities</td></tr> | ||
<tr valign="top"><td>EA</td><td>enterprise architecture</td></tr> | <tr valign="top"><td>EA</td><td>enterprise architecture</td></tr> | ||
| − | <tr valign="top"><td>EIT</td><td>enterprise | + | <tr valign="top"><td>EIT</td><td>enterprise information technology</td></tr> |
<tr valign="top"><td>FLURPS</td><td>functionality, localizability, usability, reliability, performance, supportability</td></tr> | <tr valign="top"><td>FLURPS</td><td>functionality, localizability, usability, reliability, performance, supportability</td></tr> | ||
<tr valign="top"><td>GSC</td><td>global standards collaboration</td></tr> | <tr valign="top"><td>GSC</td><td>global standards collaboration</td></tr> | ||
| Line 32: | Line 39: | ||
<tr valign="top"><td>IEEE</td><td>Institute of Electrical and Electronics Engineers</td></tr> | <tr valign="top"><td>IEEE</td><td>Institute of Electrical and Electronics Engineers</td></tr> | ||
<tr valign="top"><td>INCITS</td><td>International Committee for Information Technology Standards</td></tr> | <tr valign="top"><td>INCITS</td><td>International Committee for Information Technology Standards</td></tr> | ||
| + | <tr valign="top"><td>ISACA</td><td>Information Systems Audit and Control Association</td></tr> | ||
<tr valign="top"><td>ISO</td><td>International Organization for Standardization</td></tr> | <tr valign="top"><td>ISO</td><td>International Organization for Standardization</td></tr> | ||
<tr valign="top"><td>IT</td><td>information technology</td></tr> | <tr valign="top"><td>IT</td><td>information technology</td></tr> | ||
| − | <tr valign="top"><td>ITIL</td><td> | + | <tr valign="top"><td>ITIL</td><td>information technology infrastructure library </td></tr> |
<tr valign="top"><td>ITSC</td><td>information technology support center</td></tr> | <tr valign="top"><td>ITSC</td><td>information technology support center</td></tr> | ||
| + | <tr valign="top"><td>IVR</td><td>interactive voice response</td></tr> | ||
<tr valign="top"><td>KPI</td><td>key performance indicator</td></tr> | <tr valign="top"><td>KPI</td><td>key performance indicator</td></tr> | ||
| + | <tr valign="top"><td>KTBR</td><td>keep the business running</td></tr> | ||
| + | <tr valign="top"><td>KTLO</td><td>keep the lights on</td></tr> | ||
<tr valign="top"><td>LCCE</td><td>life cycle cost estimate</td></tr> | <tr valign="top"><td>LCCE</td><td>life cycle cost estimate</td></tr> | ||
<tr valign="top"><td>logical design</td><td>defines objects, entities, their attributes, and their relationships. It also describes the business rules associated with these entities</td></tr> | <tr valign="top"><td>logical design</td><td>defines objects, entities, their attributes, and their relationships. It also describes the business rules associated with these entities</td></tr> | ||
<tr valign="top"><td>MOE</td><td>measures of effectiveness </td></tr> | <tr valign="top"><td>MOE</td><td>measures of effectiveness </td></tr> | ||
<tr valign="top"><td>NIST</td><td>National Institute of Standards and Technology</td></tr> | <tr valign="top"><td>NIST</td><td>National Institute of Standards and Technology</td></tr> | ||
| + | <tr valign="top"><td>OCM</td><td>organizational change management</td></tr> | ||
<tr valign="top"><td>OLA</td><td>operational level agreement</td></tr> | <tr valign="top"><td>OLA</td><td>operational level agreement</td></tr> | ||
<tr valign="top"><td>physical design</td><td>Also 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.</td></tr> | <tr valign="top"><td>physical design</td><td>Also 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.</td></tr> | ||
| Line 47: | Line 59: | ||
<tr valign="top"><td>QC</td><td>quality control</td></tr> | <tr valign="top"><td>QC</td><td>quality control</td></tr> | ||
<tr valign="top"><td>QMS</td><td>quality management system</td></tr> | <tr valign="top"><td>QMS</td><td>quality management system</td></tr> | ||
| − | <tr valign="top"><td>resource management</td><td> | + | <tr valign="top"><td>resource management</td><td>identification, 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)</td></tr> |
<tr valign="top"><td>RFI </td><td>request for information </td></tr> | <tr valign="top"><td>RFI </td><td>request for information </td></tr> | ||
<tr valign="top"><td>RFP </td><td>request for proposal</td></tr> | <tr valign="top"><td>RFP </td><td>request for proposal</td></tr> | ||
| Line 54: | Line 66: | ||
<tr valign="top"><td>risk</td><td>a 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)</td></tr> | <tr valign="top"><td>risk</td><td>a 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)</td></tr> | ||
<tr valign="top"><td>ROI</td><td>return on investment</td></tr> | <tr valign="top"><td>ROI</td><td>return on investment</td></tr> | ||
| + | <tr valign="top"><td>RPO</td><td>recovery 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</td></tr> | ||
| + | <tr valign="top"><td>RTO</td><td>recovery time objective, long it will take to return an EIT service to active duty</td></tr> | ||
<tr valign="top"><td>SaaS</td><td>software as a service</td></tr> | <tr valign="top"><td>SaaS</td><td>software as a service</td></tr> | ||
<tr valign="top"><td>SAT</td><td></td></tr> | <tr valign="top"><td>SAT</td><td></td></tr> | ||
| + | <tr valign="top"><td>service catalogue</td><td>(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.</td></tr> | ||
<tr valign="top"><td>SFIA</td><td>Skills Framework for the Information Age</td></tr> | <tr valign="top"><td>SFIA</td><td>Skills Framework for the Information Age</td></tr> | ||
| + | <tr valign="top"><td>shadow EIT</td><td>shadow enterprise information technology</td></tr> | ||
<tr valign="top"><td>SLA</td><td>service level agreement</td></tr> | <tr valign="top"><td>SLA</td><td>service level agreement</td></tr> | ||
<tr valign="top"><td>SME</td><td>subject matter expert</td></tr> | <tr valign="top"><td>SME</td><td>subject matter expert</td></tr> | ||
| − | <tr valign="top"><td> | + | <tr valign="top"><td>SO</td><td>service operations</td></tr> |
<tr valign="top"><td>solution</td><td>a 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</td></tr> | <tr valign="top"><td>solution</td><td>a 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</td></tr> | ||
| + | <tr valign="top"><td>SOX</td><td>Sarbanes Oxley</td></tr> | ||
| + | <tr valign="top"><td>SPOC</td><td>single point of contact</td></tr> | ||
| + | <tr valign="top"><td>stakeholder</td><td>a person or group that has an investment, share, or interest in something, as a business or industry. (Source: http://dictionary.reference.com/browse/stakeholder)</td></tr> | ||
| + | <tr valign="top"><td>SWECOM</td><td>software engineering competency model, formerly known as SECOM</td></tr> | ||
<tr valign="top"><td>SWOT</td><td>strengths, 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)</td></tr> | <tr valign="top"><td>SWOT</td><td>strengths, 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)</td></tr> | ||
<tr valign="top"><td>TCO</td><td>total cost of ownership</td></tr> | <tr valign="top"><td>TCO</td><td>total cost of ownership</td></tr> | ||
Revision as of 21:24, 18 September 2015
| Term | Meaning |
| acceptable | 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) |
| 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 strategy | 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) |
| ADKAR model | A 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) |
| AOA | analysis of alternatives |
| BCA | business case analysis |
| BCP | business continuity plan |
| BMM | business (enterprise) motivation model |
| BU | business unit |
| CBA | cost benefit analysis |
| change agent | A 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) |
| CMDB | configuration management database |
| CMMI | capability 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 |
| COBIT | Control Objectives for Information and Related Technology |
| conceptual design | describes 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 |
| 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) |
| contract | binding 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) |
| CP | consolidated platform |
| CSP | cost schedule performance |
| DoDAF | Department 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 |
| domain | A 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 elicitation | collecting the right information from SMEs, stakeholders, or consumers about how the solution should function |
| DR | disaster 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> |
| DRP | disaster 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 |
| DT | disaster tolerance, the time gap a business can accept the non-availability of EIT facilities |
| EA | enterprise architecture |
| EIT | enterprise information technology |
| FLURPS | functionality, localizability, usability, reliability, performance, supportability |
| GSC | global standards collaboration |
| HITSR | Healthcare Information Technology Standards Panel |
| ICT | information and communications technology |
| IEEE | Institute of Electrical and Electronics Engineers |
| INCITS | International Committee for Information Technology Standards |
| ISACA | Information Systems Audit and Control Association |
| ISO | International Organization for Standardization |
| IT | information technology |
| ITIL | information technology infrastructure library |
| ITSC | information technology support center |
| IVR | interactive voice response |
| KPI | key performance indicator |
| KTBR | keep the business running |
| KTLO | keep the lights on |
| LCCE | life cycle cost estimate |
| logical design | defines objects, entities, their attributes, and their relationships. It also describes the business rules associated with these entities |
| MOE | measures of effectiveness |
| NIST | National Institute of Standards and Technology |
| OCM | organizational change management |
| OLA | operational level agreement |
| physical design | Also 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 | |
| QA | quality assurance |
| QC | quality control |
| QMS | quality management system |
| resource management | identification, 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 |
| RFQ | request for quotation |
| RFT | request for tender |
| risk | a 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) |
| ROI | return on investment |
| RPO | recovery 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 |
| RTO | recovery time objective, long it will take to return an EIT service to active duty |
| SaaS | software as a service |
| SAT | |
| 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. |
| SFIA | Skills Framework for the Information Age |
| shadow EIT | shadow enterprise information technology |
| SLA | service level agreement |
| SME | subject matter expert |
| SO | service operations |
| solution | a 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 |
| SOX | Sarbanes Oxley |
| SPOC | single point of contact |
| stakeholder | a person or group that has an investment, share, or interest in something, as a business or industry. (Source: http://dictionary.reference.com/browse/stakeholder) |
| SWECOM | software engineering competency model, formerly known as SECOM |
| SWOT | strengths, 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) |
| TCO | total cost of ownership |
| TOGAF | The Open Group Architecture Framework |
| UAT | |
