Difference between revisions of "Glossary"
From EITBOK
| Line 7: | Line 7: | ||
<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>BMM</td><td>business (enterprise) motivation model</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>Capability Maturity Model Integration</td></tr> | <tr valign="top"><td>CMMI</td><td>Capability Maturity Model Integration</td></tr> | ||
| + | <tr valign="top"><td>CMMI for Acquisition (CMMI-ACQ)</td><td>Product and service acquisition</td></tr> | ||
| + | <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> | ||
<tr valign="top"><td>constraint</td><td>(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) <br />(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)</td></tr> | <tr valign="top"><td>constraint</td><td>(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) <br />(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)</td></tr> | ||
<tr valign="top"><td>contract</td><td>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)</td></tr> | <tr valign="top"><td>contract</td><td>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)</td></tr> | ||
| + | <tr valign="top"><td>CP</td><td>consolidated platform</td></tr> | ||
<tr valign="top"><td>CSP</td><td>cost schedule performance</td></tr> | <tr valign="top"><td>CSP</td><td>cost schedule performance</td></tr> | ||
<tr valign="top"><td>DoDAF</td><td>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</td></tr> | <tr valign="top"><td>DoDAF</td><td>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</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</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>EA</td><td>enterprise architecture</td></tr> | ||
| + | <tr valign="top"><td>EIT</td><td>enterprise IT</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> | ||
<tr valign="top"><td>HITSR</td><td>Healthcare Information Technology Standards Panel</td></tr> | <tr valign="top"><td>HITSR</td><td>Healthcare Information Technology Standards Panel</td></tr> | ||
| Line 23: | Line 33: | ||
<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>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>ITIL</td><td>IT infrastructure library </td></tr> | <tr valign="top"><td>ITIL</td><td>IT 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>KPI</td><td>key performance indicator</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>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> | ||
| + | <tr valign="top"><td>PMO</td><td></td></tr> | ||
| + | <tr valign="top"><td>QA</td><td>quality assurance</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>resource management</td><td>the 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>resource management</td><td>the 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> | ||
| Line 36: | Line 53: | ||
<tr valign="top"><td>RFT</td><td>request for tender</td></tr> | <tr valign="top"><td>RFT</td><td>request for tender</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>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>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>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>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>SOA</td><td>service oriented architecture</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>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>TOGAF</td><td>The Open Group Architecture Framework </td></tr> | <tr valign="top"><td>TOGAF</td><td>The Open Group Architecture Framework </td></tr> | ||
| + | <tr valign="top"><td>UAT</td><td></td></tr> | ||
<tr valign="top"><td> </td><td> </td></tr> | <tr valign="top"><td> </td><td> </td></tr> | ||
</table> | </table> | ||
Revision as of 21:11, 8 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) |
| AOA | analysis of alternatives |
| BCA | business case analysis |
| BCP | business continuity plan |
| BMM | business (enterprise) motivation model |
| CBA | cost benefit analysis |
| 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 |
| EA | enterprise architecture |
| EIT | enterprise IT |
| 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 |
| ISO | International Organization for Standardization |
| IT | information technology |
| ITIL | IT infrastructure library |
| ITSC | information technology support center |
| KPI | key performance indicator |
| 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 |
| 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 | the 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 |
| SaaS | software as a service |
| SAT | |
| SFIA | Skills Framework for the Information Age |
| SLA | service level agreement |
| SME | subject matter expert |
| SOA | service oriented architecture |
| 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 |
| 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 | |
