| Acquisition - On this site, the term is used to indicate the full life of a system from initial concept and planning, through development and maintenance and operations (M&O) and continuing until the system is retired or shut down. |
| Acquisition Life Cycle - The standard process used by the acquisition organization for defining how a system will be acquired and maintained from inception to retirement. For OSI, the Acquisition Life Cycle includes the following phases: Planning, Contracting, and Product Implementation and Acceptance. |
| Action Item Management - Identification, analysis, tracking and resolution of specific defined tasks (usually related to project management concerns). Action Item tracking sometimes is a subset of Issue Management. |
| Activity - A collection of business tasks typically executed in a sequential fashion in order to achieve intermediate results. |
| Agency - OSI's parent organization is the California Health and Human Services Agency. |
| Alternative Procurement - According to the State Contracting Manual, Vol 3, Section 3.B6.0, standard acquisition approaches are appropriate for most acquisition. Some business problems, however, offer unique challenges where the use of different procurement techniques, within a competitive framework, may better meet the State's needs. In such cases, a request to conduct an alternative procurement within the ITPP should be submitted to the DGS/PD. See SAM 4819.31. Due to the complexity of Alternative Procurements, only the DGS/PD has the authority to conduct such procurements. |
| Architecture Framework - A combination of structured processes, templates, and governance that facilitate the documentation of a architecture in a systematic manner. |
| Attribute - A characteristic of an Entity whose value may be used to help distinguish one instance of an Entity from other instances of the same Entity. For example, an Attribute of a “Person” Entity may be “Social Security Number (SSN)”. An SSN is used to distinguish one person (i.e. one instance of a “Person” Entity) from another. |
| Best Value - Synonymous with "value effectiveness" and both mean factors or criteria established by a state agency to ensure that their business needs and goals are effectively met and the state obtained the most value. |
| Blueprint - The dynamic content of a given architecture that is captured utilizing standardized, structured processes and templates. |
| Budget Change Proposal (BCP) - A proposal to change the spending authority for project activities authorized by the DOF. A BCP is also required for any current year changes in spending authority. The DOF annually issues a Budget Letter with specific instructions for preparing BCPs. The term BCP can be used in a generic sense to refer to both the fall and spring process documents, or to specifically refer to the fall process document (the spring process document is a spring finance letter). |
| Business Continuity Plan - The Business Continuity Plan describes what actions and decisions are needed to ensure critical business operations will continue in the event of a disaster or facility problem. The plan should discuss who has the authority to initiate the activities described in the plan, which operations should be continued, and how to re-establish the operations. |
| Business Process Execution Language for Web Services - provides a language for the formal specification of business processes and business interaction protocols. By doing so, it extends the Web Services interaction model and enables it to support business transactions. BPEL defines an interoperable integration model that should facilitate the expansion of automated process integration in both the intra-corporate and the business-to-business spaces. |
| Business Process Improvement/Initiative (BPI) - A less-radical and sometimes incremental approach. Changes are made to existing processes and new processes are developed only as needed (instead of re-working all processes). Organizational changes are less likely to occur. |
| Business Process Re-engineering (BPR) - Analysis and re-design of business workflows and processes to improve performance. The true sense of BPR usually involves a radical or far-reaching approach (such as a "clean slate" approach). This type of BPR may also include an organizational re-design. Usually, OSI performs BPI, although it is often referred to as BPR, using the term in a more generic sense. This web site uses the term BPR for both BPR and BPI. |
| Business Process Re-engineering Plan - The BPR plan addresses how business processes will be modified and changed as a result of a technology innovation resulting from the system acquisition. This plan describes how the BPR effort will be defined and managed. A BPR Plan is only required for large-scale process changes. For minor process changes, the approach may be included in the Implementation Plan. |
| Business Reference Model - is a function-driven framework for describing the business operations of the California State Government independent of the agencies that perform them. |
| Business Services - Process, Activities, and Tasks executed to deliver. |
| Business System - A collection of processes (automated or manual) that are provided that fulfill some or all of the requirements to of a Line of Business |
| Cannery - A DTS site and operations division. |
| Capability Maturity Model (CMM) - The Capability Maturity Model describes the principles and practices underlying software process maturity. It is intended to help software organizations improve the maturity of their software processes in terms of an evolutionary path from ad hoc, chaotic processes to mature, disciplined software processes. The focus is on identifying key process areas and the exemplary practices that may comprise a disciplined software process. |
| Change Control - The tracking and management of proposed changes to an item's format, content, version and/or configuration. Change control applies to many different project office functions (e.g. requirements management, project management, quality management, contract management, etc.) as well as contractor delivered products. OSI considers change control as an element of configuration management. Contrast this definition with Change Leadership and Change Management. |
| Change Control Board (CCB) - The review committee(s) that is responsible for defining the change, evaluation, coordination, approval/disapproval and implementation of changes to a configured item after the item has been formally defined and baselined. |
| Change Control Process - This process describes how project baselines will be managed and maintained. Typically, projects will utilize a change/configuration control board (CCB) to identify and track configuration items and their disposition. This process is included or referenced in the Configuration Management Plan. |
| Change Leadership - The activities performed to manage organizational changes including organization structure, roles and responsibilities, type of work performed, and management reporting. Focuses more on soft-skills to address personnel concerns and to change organizational culture and perceptions. Contrast this definition with Change Control and Change Management. |
| Change Leadership Plan - The Change Leadership Plan describes how people are affected by technology innovation resulting from the system acquisition. This plan addresses how the people/culture will be affected and what steps will be taken to prepare them for the changes, which may include a change in job duties, new job skills, a new management structure, and/or a new method of doing business. |
| Change Management - There are different interpretations of this term. Interpretations include: Configuration Management, Change Control, or Change Leadership. OSI prefers not to use this term. |
| Column - set of data values, one for each row of the table. The columns provide the structure according to which the rows are composed. Column is also called a field. |
| Component - a self-contained business process or service with predetermined functionality that may be exposed through a business or technology interface. |
| Component Based Architecture (CBA) - Technology architecture comprised of run-time services and control structures together with an application infrastructure. The CBA consists of the component model and the architecture services that are built around the model. Solutions based on a CBA are more dynamic, flexible, and maintainable than traditional monolithic solutions (e.g., N-tiered, Service Oriented). |
| Concept of Operations (ConOps) - A document used to describe the proposed system and method of doing business from the user’s perspective. The document is often prepared as part of the requirements gathering and definition phase. This document is optional, but suggested for complex systems where there is no legacy system or where the users have primarily relied on manual processes. Refer to IEEE STD 1362. |
| Configuration Item (CI) - A configuration item can be any of the following components: hardware, software, system documentation, project office documentation, contracts, system interfaces, project office tools, contractor deliverables, networks, websites, desktop components, and databases. Configuration items can also include county components depending on how the contract is established. See also Configuration Management. |
| Configuration Management (CM) - Technical and administrative processes to identify and define configuration items, control changes to the items, record and report change processing and implementation status, and verify compliance with the items’ specified requirements. See also Change Control, Change Management, and Configuration Item. |
| Configuration Management Plan - The configuration management plan defines how the project office will maintain control of project baselines and items that must be tracked and managed in a formal and systematic fashion. Configuration items vary from project to project and depend on the level of control the project must maintain on items in support of the system acquisition. The project office Configuration Management Plan generally focuses on documents and project office infrastructure. The prime contractor will also have a Configuration Management Plan that describes how the developed system and software components will be controlled. |
| Constraints - a way of implementing business rules in the database. For instance, a constraint can restrict an integer attribute to values between 1 and 10. |
| Consultants - Vendors who have been hired to assist the project office. Contrast with Prime Contractor. |
| County/Local Office Fiscal Processes - If the project office will be reimbursing or paying for county/local office implementation costs, a process must be defined for estimating, budgeting, approving, and tracking county/local office expenditures. The processes are written from the point of view of the project and include expectations for the counties/local offices and, if appropriate, the prime contractor. |
| County/Local Office Implementation Status Report Template - The purpose of the Implementation Status Report is to give project management staff a snapshot view of the county/local office status, as well as the details for tasks in caution or critical mode. Typically, the report is delivered biweekly and contains a synopsis of workgroup status, issues, risks, changes to workplans, and progress towards key implementation milestone activities. The Implementation Team assists with the development of the report format, but content updates are the responsibility of the prime contractor and county/local office staff. |
| County/Local Office Implementation Workplan Template - The work plan template describes the activities to be completed by the county/local office in order to prepare for implementation. The template is provided for the counties/local offices to complete/customize. The project office or contractor implementation team works with the county/local office to customize and provide status on activities within the work plan. |
| County/Local Office Readiness Guide - The County Readiness Guide introduces the scope and complexities of the changes required during implementation and provides a basic understanding of the activities and decisions required of the county/local office. The readiness guide is meant to introduce the approach to implementation, the activities and responsibilities. It is presented as an informational tool to assist in understanding the scope of the effort and the impacts and implications of the effort for the county/local office. |
| Current Process Analysis Report - This document describes the users current processes and method of doing business. It is used to identify impacts and opportunities for change which may be included in the new system. Usually created as part of a BPR effort. |
| Customer Interface - The services, system, or mechanisms that a business system uses to interface with the customers of a business system. |
| Customers - The end consumer of a business systems services. Typically this is the consumers of the information that a business system provides. |
| Data Conversion Plan - This document describes the approach to converting legacy data to a new format/database. The plan describes the tool(s) to be used, the types of automated and manual processes to be used, how data anomalies and errors are handled, and how converted data will be validated to ensure it is correct prior to its use in the new production system. This plan may be either a project office or contractor responsibility. |
| Data Manipulation Language (DML) - A family of computer languages that are used by computer programs or database users to retrieve, insert, delete and update data in a database. |
| Data Reference Model - is a framework to enable information sharing and reuse via the standard description and discovery of common data and the promotion of uniform data management practices. |
| Data Type - Identifies the kind of information that a column in a database table represents. The data types (e.g. string, integer, and date) are physical representations and are dependent on the actual DBMS. |
| Database Definition Language (DDL) - This is the syntax that a given DBMS understands and is used to manipulate the structure of the database, from initial database creation to additions, modifications and deletions of all database objects (tables, columns, indexes, etc.) to the eventual removal of the database. Another term used for DDL is ''schema''. |
| Database Management System (DBMS) - A DBMS contains and controls information in some structured form so that it can be accessed in an efficient manner. |
| Deliverable - A work product produced by a contractor or consultant in accordance with the terms of their contract. Contrast with Work Products. |
| Deliverable Management - Administrative tracking of all contractual deliverables generated by a contractor or consultant. A subset of document management that includes logging receipt of a deliverable, reviewing the deliverable against its administrative requirements, approving and disapproving the deliverable submittal, and handling deficiencies with the deliverable. Deliverable management does not include a qualitative evaluation of the deliverable quality (see Quality Management). Deliverable Management is similar to Document Management, and is a subset of Configuration Management, but is usually associated with the Contract Management Plan. |
| DGS Alternative Procurement Request Form - A letter written by the project to DGS requesting permission to conduct an alternative procurement. The request is submitted to DGS with the project’s ITPP. Most of OSI’s projects are considered alternative procurements because the exact nature of the solution and products to be used are not known when the procurement is conducted. Refer to SAM Section 5215. |
| Enterprise Architecture - defines an enterprise-wide, integrated set of components that incorporates strategic business thinking, information assets, and the technical infrastructure of an enterprise to promote information sharing across agency and organizational boundaries. The Enterprise Architecture is supported by Architecture Governance and the allied architectures of, Business, Information, Technology and Solution Architectures. |
| Enterprise Service Bus - An enterprise service bus (ESB) is software architecture for middleware that provides fundamental services for more complex architectures. For example, an ESB incorporates key features to support a service-oriented architecture (SOA). In a general sense, an ESB can be thought of as a mechanism that manages access to applications and services (both modern and legacy versions) to present a single, simple, and consistent interface. |
| Entity - An abstraction for a person, place, object, event, or concept described (or characterized) by common Attributes. For example, “Person” and “Agency” are Entities. |
| Feasibility Study Report (FSR) - The state approval document required for initial project approval that contains analyses of options, cost estimates and other information. A customized Implementation Advance Planning Document (IAPD) is accepted in lieu of an FSR, for those projects receiving federal funding. The format of the FSR is dictated by DOF. |
| Federal Reference Model - A series of interrelated taxonomies that comprise the Federal Enterprise Architecture, and that are designed to facilitate cross-agency analysis and the identification of duplicative investments, gaps, and opportunities for collaboration within and across Federal Agencies. |
| Federated Identity Management - Federated identity, or the ‘federation’ of identity, describes the technologies, standards and use-cases which serve to enable the portability of identity information across otherwise autonomous security domains. The ultimate goal of identity federation is to enable users of one domain to securely access data, systems, or business services of another domain seamlessly, and without the need for redundant user administration. |
| Foreign key - identifies a column or a set of columns in one (child or referencing) table that refers to a column or set of columns in another (master or referenced) table. The columns in the referencing table must be the primary key in the referenced table. |
| Framework - The combination of the templates and structured processes that facilitate the documentation of the architecture in a systematic and disciplined manner. |
| Future System Approach - The document describes the "To Be" view of the system, and is produced as part of a BPR study. It is designed to help the users visualize how they will interact with the new/updated system, particularly focusing on business processes and interactions with the system. |
| Go Live Support Guide - The Go Live Support Guide provides an overview of the tasks that a county/local office will execute as they prepare to implement and operate the new/modified system. It describes the specific roles and responsibilities, a schedule of activities for the go live period, and instructions for how to log and escalate problems or issues. |
| Gold Camp - A DTS site and operations division |
| Implementation Advance Planning Document (IAPD) - The IAPD is the approval document used to request initial federal funding for the Development and Implementation, and Maintenance and Operations phases of a project. The IAPD, customized to meet state requirements, is accepted in lieu of the FSR. See also PAPD. |
| Implementation Advance Planning Document Update (IAPDU) - The IAPDU is an update to the IAPD submitted to the project’s federal stakeholder annually or as needed to reflect changes in project approach. The IAPD and IAPDU, customized to meet state requirements, are accepted in lieu of the FSR and SPR, respectively. See also PAPD. |
| Implementation Guide(s) - This document provides detailed information for the counties/local offices on the upcoming implementation effort. The guide describes the roles and responsibilities for the county/local office, state, and contractor staff. It summarizes the upcoming activities, costs, decisions which must be made and process impacts, and provides the county/local office with appropriate reference and sample materials to use in preparing for implementation. There may be a single guide or separate guides for each of the implementation functional areas. |
| Implementation Plan - The implementation plan defines how the system developed by the prime contractor will be implemented in the target environment. In the event of statewide implementations, the plan addresses how the system will be implemented into each site/location. |
| Implementation Troubleshooting Guide - This document provides counties/local offices with a tool to assist in troubleshooting problems or issues during the “soft” go live/go live periods and as the system transitions into production. The troubleshooting guide is organized into typical business scenarios based on past business experience or earlier implementation efforts. |
| Independent Project Oversight Consultant (IPOC) - A consultant used to externally monitor the Project Office and Contractor's management efforts. "Independent" usually entails technical and/or managerial independence. The focus is generally on process and products from a management, process and quality perspective, not the in-depth technical reviews associated with IV&V. |
| Independent Verification and Validation (IV&V) - An organization that externally monitors both the Project Office and the Contractor's efforts. Independence is used to ensure an unbiased opinion, and can mean financial, managerial and/or technical. An IV&V vendor generally reviews both products and processes, with a particular emphasis on the technical aspects of the products. See also Independent Project Oversight Consultant (IPOC). |
| Index - An index is a data structure associated with a table that is logically ordered by the values of a key. It improves database performance and access speed. You normally create indexes for columns that you access regularly, and where response time is important. Indexes are most effective when they are used on columns that contain mostly unique values. |
| Information Flow - The path and process of information takes from the originating source, to a consumer(s) of the data. |
| Infrastructure / Facilities Plan - This document addresses the specific strategy to building, furnishing and/or moving into a new location or office space for the project office. The plan must discuss the preparation and installation needs including electrical, telecommunications, security, furniture, and computing equipment. This document is produced as needed. |
| Inter Agency Agreement (IAA) - A formal agreement between state organizations. OSI and the sponsor establish an IA that describes the agreement regarding management of the OSI projects in support of the sponsor’s programs. The IA includes the costs for which the sponsor will reimburse OSI and thus must match the numbers in the final State Budget for each fiscal year. Refer to State Contract Manual (on the Navigation Menu to the left, select the Links & Downloads option and go to the State page to find a direct link to the manual). |
| Interface Requirements Document (IRD) - Describes the requirements for the existing or known interfaces for the system. This document is developed by the project and included or referenced in the RFP. The prime contractor further refines the interface requirements and documents specific requirements in their Software Requirements Specification, Interface Requirement Specification and resulting design documents. |
| Issue - A statement of concern or need that (1) is known ahead of time or are in the project workplan, but whose resolution is in question or lacking agreement among stakeholders; (2) is highly visible or involve external stakeholders such as requests from control agencies; (3) have critical deadlines or timeframes which cannot be missed; (4) Result in an important decision or resolution whose rationale and activities must be captured for historical purposes; or (5) is item that may impede project progress. An issue is a situation which has occurred or will definitely occur, as opposed to a risk which is a potential event. |
| Keys - identify primary and foreign keys and help ensures uniqueness and referential integrity. |
| Line of Business - A set of one or more highly related products which service a particular customer transaction or business need. |
| M&O Transition Plan - The M&O Transition Plan addresses how the project office will manage the project once the system is implemented in the production environment. The plan focuses not only on the transition implications when moving into the M&O life cycle, but also on the transition of M&O responsibilities between the prime contractor and the M&O contractor. |
| Maintenance and Operations (M&O) Plan - The M&O Plan summarizes the project’s approach to M&O. The plan is similar to the Master Project Plan, but with an emphasis on sustained operations instead of development and implementation. The M&O Plan places a stronger emphasis on the strategic direction of the project/system, the approach to system releases, upgrades and maintenance, and ongoing operations and customer support. |
| Major Information Technology Project - As stated in Management Memo 98-12, "...any IT project or system deemed to be 'mission critical' and with an estimated cost of $5 million or more." |
| Mechanism - Technology or other utility that is used by a business system that helps automate a business process, activity, or task. |
| Memorandum of Understanding (MOU) - A formal agreement with another organization that defines the roles and responsibilities and expectations of each party. Usually used to establish an agreement with counties/local offices, particularly when the project will be reimbursing the county/local office for implementation expenses. Refer to the State Contracting Manual. |
| Metrics Process - The Metrics Process describes how measurements will be identified, collected, and analyzed to ensure quality goals (including management and system goals) are being accomplished. The Metrics Process is usually included or referenced in the Quality Management Plan. |
| Model - The graphical representation or simulation of a process, relationship or information, along with a narrative that supports the diagram(s). |
| Module - a self-contained software component of a business system, which has a well-defined interface to the other software components; something is modular if it includes or uses modules which can be interchanged as units without disassembly of the module. Design, manufacture, repair, etc. of the modules may be complex, but this is not relevant; once the module exists, it can easily be connected to or disconnected from the system. |
| Operational Support Documentation Outline - This document provides guidance in the uniform creation of the operational support documentation. The purpose of the operations support document is to provide instructions to the system operators on the procedures for operating, controlling, troubleshooting, and maintaining the system once implemented in production. |
| OSI Orientation - OSI Orientations are project team orientations designed to familiarize new project office staff with the OSI organization in general. OSI Orientations are not project-specific. |
| OSI Training Plan - The OSI Training Plan defines the division-level training that is mandated on all projects from the OSI organization. Training requirements are general in content and emphasizes topics that have long-term relevance to all projects in OSI (e.g. OSI orientation, Using the BP website, Understanding the OSI life cycle etc). |
| Performance Review Presentations - Performance reviews are internal reviews of project office (not contractor) performance and status. These reviews are formal and in-person with the OSI Assistant Director and the project team. These reviews are conducted quarterly and typically do not involve the sponsor or contractor. |
| Planning Advance Planning Document (PAPD) - A PAPD is an approval document used to request federal approval and funding for the Initiation, Planning and Procurement phases of a project. There are no approval documents comparable to a PAPD in the state process. Upon selection of a vendor and agreement on project costs, the project submits an Implementation Advanced Planning Document (IAPD). |
| Planning Advanced Planning Document Update (PAPDU) - A PAPDU is an updated to the PAPD submitted to the project’s federal stakeholder annually or as needed during the planning phase to report project progress and changes. Upon selection of a vendor and agreement on project costs, the project submits an IAPD. |
| Policy Impact Analysis - If performed as part of a BPR effort, this document describes any impacts to the existing policies, particularly if there are changes needed. This document should also highlight areas where the automated system will streamline or assist with implementing policy, and areas where changes in implementing the policy will occur (for instance, changing a team leads manual approval to an automated approval). A Policy Impact Analysis may also be completed as part of the analysis of proposed legislation or policy changes, in which case it describes the anticipated effect of the legislation or policy on the new/existing system. |
| Position Descriptions - A document describing the tasks, knowledge, skills and abilities required for a given staff position. PDs are specific to a position on a project and should be consistent with the approved position classification. |
| Primary key - Column or combination of columns whose values uniquely identify a row in a table. The primary key may have a specific meaning in the business domain or may be a counter value. Primary keys do not allow null values. |
| Prime Contractor - The contractor who has primary responsibility for developing or integrating the given system, or the primary contractor performing work on the system. |
| Process - Related business activities performed to produce an end product of provide a business service. A process has a specific beginning and an end point marked by the delivery of a product of output. |
| Process Gap Analysis - This document describes the differences between the current method of doing business and the desired or proposed way of doing business. Generally produced as part of a BPR study, it focuses on identifying what needs to be done to achieve the desired way of doing business. |
| Process Implementation Plan - A document used to implement large-scale process changes, such as part of a BPR process. The plan describes the approach to implementing, training, monitoring and correcting the new/modified processes in the actual county/local office location(s). For smaller scale process changes, this information may be included in the Implementation Plan. |
| Process Improvement Plan - The Process Improvement Plan describes how the project will tailor and administer the OSI mandates for continuous process improvement to project-specific conditions. The OSI Enterprise Project Management Office coordinates process improvement initiatives at the OSI-level. The Process Improvement Program is typically described as a section within the Quality Management Plan. |
| Project Management Office (PMO) - An organization that oversees and/or mentors groups of projects. Often the PMO is responsible for establishing policies and standards for the projects/organization, reviewing and consolidating project reports for external stakeholders, and monitoring project performance against the organization's standards. There is usually a single PMO per state department or agency. |
| Project Manager (PM) - The Project Manager is the person(s) assigned by the OSI Assistant Director to manage a designated OSI project. Project Managers include the primary manager (sometimes referred to as the Project Director) and the Assistant Project Managers. |
| Project Master Schedule - The high-level schedule which summarizes all the efforts required to implement the project. It includes (generally by reference) the milestones and key activities of the prime contractor and any consultants. It may also include milestones and key activities from the counties/local offices. The master schedule focuses on dependencies and critical path. |
| Project Office (PO) - The group responsible for performing a project, including administrative, fiscal, contract, technical and quality assurance staff. The project office (or just project) may oversee a contractor who is performing the primary activities (planning, development, etc.), or the project itself may be performing all project activities. |
| Project Toolset Change Control Process - The change control process utilized by the organization to allow for the customization of the project office suite of tools to meet the specific needs of the project. Unlike the "project" change control process, this process is limited to the OSI standard set of project office tools. Some tools and changes must be coordinated at the division level while other changes may be coordinated at the project level, depending on the nature of the change and whether the tool is considered an OSI standard tool. |
| Project Training Plan - The Project Training Plan includes training that is unique to the specific needs of the project (e.g. welfare training, unemployment insurance training, etc.) and is determined as the special project need arises. Also refer to the OSI Training Plan for general training requirements for all projects in OSI. |
| Project Work Plans - The detailed list of activities required to complete specific tasks on the master schedule. The activities list focuses on specific measurable tasks, task assignments, and due dates. Work plan data is rolled-up to specific tasks of the master schedule. |
| Project-Specific Orientation / Training - Project-Specific Orientation/Training is provided to new project office staff for the purpose of familiarizing them with project-specific information. |
| Proposal Evaluation Report - The report describing the results of the proposal evaluation effort, including the identification of the selected bidder. The report summarizes the criteria used, the bidders who responded, the specific scores for each bidder and any preference criteria applied. The DGS Analyst assigned to the procurement coordinates the development of this report, which is forwarded to DGS management for approval. |
| Referential integrity - refers to rules governing data consistency, specifically the interaction between primary keys and foreign keys in different tables. Referential integrity dictates what happens when you update or delete a value in a referenced column in the parent table and when you delete a row containing a referenced column from the parent table. |
| Relationships - links information together and it is an essential part of database normalization. Most of the time, relationships reflects the one (master table, or referenced table) to many (child table, or referencing table) relationships between the tables. There may be one-to-one, one-to-many, etc, relationship between the parent and child tables. |
| Request for Information (RFI) - A letter released to the bidding community seeking to identify interested bidders for a particular procurement. The RFI generally describes the background of the business problem and may describe some of the key requirements. The project works with DGS to develop and release the RFI. |
| Requirements Management Plan - This document describes the approach to managing the system requirements. The plan describes how requirements are derived and validated, how requirements changes are analyzed and managed, how requirements traceability is maintained and validated, and how the project works with the contractor to ensure traceability of requirements to the system and system documentation. |
| Requirements Traceability Matrix - A Requirements Traceability Matrix is a tool that will ensure that all requirements have been fulfilled in the end product by associating each requirement with the object via a matrix. Requirements traceability includes tracing to things other than software that satisfy requirements such as capabilities, design elements, manual operations, tests, etc. A traceability matrix is also used to ensure all requirements are met and to locate affected system components when there is a requirements change. |
| Responsibility Assignment Matrix (RAM) - The Responsibility Assignment Matrix (RAM) assigns responsibilities for project work components to project roles. Refer to the Staff Management Plan for instructions on using the RAM. |
| RFP Addenda - Addenda are issued after the RFP is released to the bidders to clarify requirements or bidder instructions, or to respond to questions from the bidders. The project must work with DGS to issue any addenda. |
| Risk - A potential event that would have a negative impact on the success of the project if the event were to occur. Also an opportunity for benefit to the project, if acted upon. |
| Risk (External) - Those risks beyond the control or influence of the project team. |
| Risk (Internal) - Those risks the project team can control or influence. |
| Risk Acceptability - The exposure to loss (financial or otherwise) that an organization is willing to tolerate from a risk. |
| Risk Action Request or Plan - The recommended treatment alternatives and supporting information for one or more risks determined to be above a risk tolerance or threshold. |
| Risk Analysis - The evaluation of risks and risk interactions to assess the range of possible project outcomes. The determination of which risk events warrant response. (Is the negative impact of the potential risk event significant enough to warrant inclusion in the risk management process?) |
| Risk Consequence - An outcome of an event, hazard, threat or situation. |
| Risk Contingency Planning - For those risks where it is unlikely or uncertain that the mitigation will be effective, a contingency plan should be developed. The contingency plan should attempt to minimize the effects of the risk assuming the event does occur. |
| Risk Criticality - A designation of the project’s risk, sensitivity or importance based on several factors including size, project manager and team experience, and several project characteristics. The criticality rating is determined using the OCIO IT Project Oversight Framework. OCIO makes the final determination regarding a project’s criticality rating. This rating is used to determine the requirements for risk reporting to external stakeholders. |
| Risk Escalation - The process of elevating a risk to appropriate management and stakeholders to ensure sufficient visibility to effect a decision, action or change to the risk’s current profile. There are usually three levels of risk escalation. |
| Risk Exposure - A determination of the importance of or potential loss from the risk based upon 1) potential impact of the risk on the project, and 2) the probability of occurrence. Usually categorized as high, medium or low. |
| Risk Identification - The determination of which risks are likely to affect the project and the documenting of the characteristics of each risk. Risk identification is not a one-time event; it is performed on a regular basis throughout the project’s life cycle. Risk identification must address both internal and external risks. |
| Risk Impact - The potential consequences, either positive or negative, should the risk occur. Impacts may affect several areas in both tangible and intangible ways. Usually expressed as High, Medium or Low. |
| Risk Likelihood - A qualitative or quantitative expression of the changes that an event will occur. |
| Risk Mitigation - The identification of ways to minimize or eliminate project risks. Depending on the severity of the risk and the level of effort for the mitigation strategies, it may be appropriate to initiate several mitigation activities. In other cases, it may not be possible to mitigate a risk. |
| Risk Probability - The likelihood of the occurrence of the risk (high, medium, low). |
| Risk Profile - The current and historical risk-related information; a compendium or aggregate of all the individual risk profiles in a project. |
| Risk Ranking - The relative importance of the risk compared to the list of all project risks. Assists in prioritizing and applying resources for mitigation and contingency actions. |
| Risk Severity - A function of the risk exposure compared to the timeframe. The control agencies require risks of a certain severity to be escalated. Ranking of risks is often driven by severity. |
| Risk State - The current information relating to an individual risk. |
| Risk Timeframe - The period of time within which the risk is expected to occur (short-term, medium-term, long-term). |
| Risk Tolerance or Threshold - The criteria against which stakeholders evaluate a risk. Different risk tolerances may be defined for each risk, risk category, or combination of risks. Exceeding a risk threshold is a condition that triggers some action. |
| Risk Tracking/Control - A method to insure that all steps of the risk management process are being followed and, as a result, risks are being mitigated effectively. Risk tracking/control involves the oversight and tracking of risk mitigation action plan execution, re-assessment of risks, reporting risk status, and recording risk information changes in the project risk database. |
| Schedule Management Plan - This document describes the process and how the OSI-defined tool (e.g. MS Project) is used to implement the methodology for establishing, managing, and modifying the Master Project Schedule and Schedule Baseline, and coordinating inputs from the contractor and county/local office work plans and schedules. |
| Service Area - is a technical tier that supports the secure construction, exchange, and delivery of business or service components. Each Service Area groups the requirements of component based architectures within the Government into functional areas. |
| Service Category - is a sub-tier of the Service Area to classify lower levels of technologies, standards, and specifications in respect to the business or technology function they serve. |
| Service Level Agreement (SLA) - This document describes the system performance and service level expectations and requirements for the prime contractor during the Implementation and M&O phases. The SLA includes target performance measures, unacceptable measures and penalties for not meeting required service levels. Usually included or referenced in a SOW and contract. |
| Service Oriented Architecture (SOA) - An architecture that provides for reuse of existing business services and rapid deployment of new business capabilities based on existing capital assets. Major components include an Enterprise Service Bus, Service Registry, SOA Governance, Federated Identity Management, which interoperate via standard interfaces and protocols. |
| Service Reference Model - is a framework classifying Service Components according to the capabilities they provide to business functions. |
| Sister Project - A sister project is an OSI project that is at a point in its life cycle where it can accept the additional workload to support a new project. The objective of Establish a Sister Project is to setup a working relationship with an existing OSI project that will allow the new project to leverage existing location, staff, infrastructure and, if possible, understanding of the customer. A sister project is an OSI project that is at a point in its life cycle where it can accept the additional workload to support a new project. The objective of Establish a Sister Project is to setup a working relationship with an existing OSI project that will allow the new project to leverage existing location, staff, infrastructure and, if possible, understanding of the customer. |
| SLA for the Data Center - If a data center will be hosting or providing services for the system, a Service Level Agreement with the Data Center is needed. The SLA describes the system performance and service level expectations and requirements for the data center during the Development, Implementation and M&O phases. The SLA includes target performance measures, unacceptable measures and penalties for not meeting required service levels. Usually referenced as part of a SOW and contract. |
| Software Component - An object, or collection of objects offering a predefined service's or event's, possessing the ability to communicate with or be used by other components. A component is a piece of a solution that can be isolated as a set of functions and features that relates to other components within the same solution. |
| Solution Architect - An individual responsible for developing solution architecture frameworks and solution set designs. The Solution Architect’s primary role is to translate what is required to run the business (from the Business and Information Architecture gaps and migration strategies) into actual design specifications and models that can be supported and fulfilled by components within the Technology Architecture. |
Solution Architecture - An architecture within Enterprise Architecture that guides the solution architect in the design of a particulate solution set. For each solution set, Solution Architecture assists in:- The identification of business requirements
- The determination of the design specifications necessary to deliver the business requirements
- The development of the solution set design. Integrating designs based on details with the Business, Information and Technology blueprints
|
| Solution Architecture Model - The graphical representation of concepts to portray a desired future state of a business solution, as well as an undesirable current state, which is used for communicating, analyzing, testing, simulating, or exploring options. |
| SOW for the Data Center - If a data center will be hosting or providing services for the system, a Statement of Work (SOW) with the data center is needed. The SOW describes the specific tasks, activities and deliverables that the data center will provide to support the system. The SOW is used with some type of contract vehicle to establish binding responsibility for the work to be performed. An SLA is usually included or referenced by the SOW. |
| Specification - a formal layout/blueprint/design of an application development model for developing distributed component-based architectures. |
| Statement Of Work (SOW) - The SOW describes the specific tasks, activities and deliverables the contractor will provide to the project. The SOW is used with some type of contract vehicle to establish binding responsibility for the work to be performed. An SLA may be included or referenced by the SOW, if appropriate. |
| System Interface - The services, system, or mechanisms that a business system uses to gather or provide information. The source varies from external systems services or information repositories, or the internal data source which is managed by the business system. |
| System Requirements Specification (SyRS) - Developed by the project to describe the business and system requirements based on the user/sponsor needs. The SyRS is included or referenced in the RFP and forms the basis for the system. The prime contractor further refines the requirements in their Software Requirements Specification and resulting design documents. |
| System Test Summary Report - This report describes how test activities were performed and a summary of the results of the test. The report should provide a clear picture of what tests were performed, what types of problems were found, the severity of problems found, how the problems were resolved (or what is currently being done to resolve them), and if the system was sufficiently tested to provide confidence that the system is ready for the next phase. |
| Table - set of data elements (values) that is organized using a model of vertical columns (which are identified by their field name) and horizontal rows (records). |
| Tasks - The smallest unit of work performed by an organization, which is limited in duration and scope. |
| Technical Reference Model - is a framework to describe how standards and technologies support the secure delivery, exchange, and construction of Service Components. |
| Test Strategy - The Test Strategy is used to help the project office clarify expectations with the user and sponsor (and contractor) regarding their obligations in the testing and acceptance of the new system in the user environment. The prime contractor may also prepare a Master Test Plan (as part of the contract) that describes their approach to all testing phases and the activities for which they are responsible. |
| Travel Budget - The Travel budget is established to allocate funds for travel on behalf of the project. Typically travel includes site visits to the counties/local offices to prepare for implementation, attendance at federal or national conferences and select training symposiums. The travel budget is submitted annually in accordance with the DOF process. |
| User Training Plan - The User Training Plan describes the approach to training the system users. This plan includes the different types of training (staff, lead, manager, administrator), the specific courses and course materials, the training approach, and how training effectiveness will be measured and addressed. This plan may be developed by the prime contractor or the project office. |
| Work Breakdown Structure (WBS) - A product- or deliverable-based grouping of project work that defines the scope of work for the project. The WBS does not identify organization or responsibility, nor does it describe dependencies between products. |
| Work Plans, County - These plans (one for each county) outline the component of effort that county stakeholders must employ in support of a statewide implementation. County workplans are integrated into the overall project schedule via guidance and coordination provided by the project office. |
| Work Plans, Project Office - Detailed descriptions of work activities performed by the project office in carrying out the duties of the project office. The work plans are derived from and traceable to the WBS elements, include interfaces from the prime contractor schedule, county schedules, and form the basis for network diagramming, critical path analysis, and the creation of the master project schedule. |
| Work Products - An item (usually a document or software) produced by the project office. |
