Documents

  

  • A
    No Items for this Letter...
  • B
    (OSI) Budget Language Definitions
    The (OSI) Budget Language Definitions document provides budgetary terms which are used frequently throughout the Governor's Budget, the Governor's Budget Summary, and the annual Budget Bill. Definitions are provided for terminology that is common to all publications.
     
     
    Business Architecture
    This template captures the tiered hierarchy of the project's business. The Business Architecture is broken into Business Areas, Lines of Business, sub-function, and business service areas. The business architecture will become an input into the Business Relationship and Conceptual Solution Architecture template.
     
     
    (Business Continuity Plan
    The Business Continuity Plan shall describe the Contractor's continuity of business strategies and procedures including system redundancies and backup, disaster recovery, and other business continuity activities. The Plan shall address business continuity for all components that comprises the [Project Name] system.
     
     
    (Business Relationship
    This template captures the suppliers and consumers of information exchange packages. The business relationship will become an input into the Conceptual Solution Architecture template.
     
     
  • C
    Change Management Process
    The Change Management Process defines a formal process for effectively managing and coordinating changes to baselined work products and assets.
     
     
    Communication Plan
    The Communication Plan defines the methodology for managing project communication needs such as information distribution methods, modes, performance reporting, and lessons learned.
     
     
    Conceptual Solution Architecture
    This template documents the proposed solution’s architecture focusing on how the customer accesses the services provided by the solution and the dependencies on other services/systems as inputs. This is used as a talking point for business process design issues without discussing the technology being used to automate the business process.
     
     
    Consulting Services Contract Termination Letter
    The purpose of this letter template is to request termination of the referenced consulting services agreement with an effective date determined by the project and in keeping with the contract’s notification requirement.
     
     
    Contract Management Matrix
    The Contract Management Matrix is a Microsoft Excel spreadsheet template which is setup to assist the project’s contract manager/analyst track and manage the status of all project contracts for maintenance and services. There are separate tabs for open, expired, terminated, and transferred contracts.
     
     
    Contract Management Plan
    The Contract Management Plan defines the processes used to manage contractors and consultants on the project. It describes how contractor deliverables will be reviewed and approved, how contractor invoices will be reviewed and authorized for payment, how contractor deficiencies are addressed, and how contract amendments and work authorizations will be processed.
     
     
    Configuration Management Plan
    The Configuration Management Plan describes the contractor's processes for managing configuration items. This includes managing software modules, managing and controlling releases to the different system environments, managing documentation, managing work authorizations, and participating on the Change Control Board.
     
     
    Cost Management Plan
    The Cost Management Plan describes the processes for managing costs on the project. The document summarizes the project’s involvement in the state budget process, and describes the project’s cost management activities (from a project management perspective), such as establishing a cost baseline, managing and making changes to the cost baseline, and reconciling the baseline with the allocated spending authority from the state budget process. This plan also describes which tools are used to manage and track costs and expenditures for the project.
     
     
  • D
    Data Conversion Plan
    The Data Conversion Plan shall describe the preparation for, delivery of, and confirmation of the successful conversion and all associated processes and interface.
     
     
    60 Day Deactivation Notice to Interface Partner
    This letter template is for use when system users are being migrated from one system to another. The purpose of this letter is formally communicate 60 days in advance to system interface partners the counties listed (or other entity) will be migrated and the interface will be deactivated. The letter also makes reference to an already established Interface Partner Agreement which should be attached for their reference.
     
     
    Data Item Description (DID)
    A Data Item Description describes the specific format, content and level of detail for a contractor deliverable. This document is generally included or referenced in the RFP and is not negotiable. Compare to Deliverable Expectation Document (DED).
     
     
    Deliverable Expectation Document (DED)
    A Deliverable Expectation Document describes the contractor’s proposed approach to preparing a deliverable, including the methodology, format, content and level of detail. This document is prepared by the contractor prior to beginning work on the deliverable and must be approved by the project. The project prepares a template to ensure the contractor adequately describes the deliverable. Compare to Data Item Description (DID).
     
     
    Deliverable Management Process
    The Deliverable Management Process describes the methodology for the administrative tracking of all contractual deliverables generated by a contractor or consultant. Typical activities include: logging receipt of a deliverable, reviewing the deliverable against its administrative requirements, approving/disapproving deliverable submittals, and the handling of deficiencies with the deliverable. The deliverable management process does not include a qualitative evaluation of the deliverable quality (see Quality Management for this). The deliverable management process is included or referenced in the Contract Management Plan.
     
     
    Detailed Design Specification Outline
    The Detailed Design Specification Outline provides guidance in the uniform development of the detailed design specification document. The purpose of the detailed design specification document is to establish and communicate in sufficient detail how the properties of the system or software requirements will be transitioned into a design. Expectations for the aspects of the system or software features and performance can be compared with the design to identify any design flaws.
     
     
    Disaster Recovery Plan
    The Disaster Recovery Plan shall describe the Contractor's approach that will be used to the guide the preparation for and delivery of necessary Contractor [Project Name] disaster services in response to any disaster requiring extraordinary [Project Name] services response. The Plan will identify resources involved in contigency operations, problem management and escalation procedures.
     
     
    Document Management Plan
    The Document Management Plan defines the process for managing project documentation during the project life cycle. It also contains a description on how to set up a document management library.
     
     
  • E
    Evaluation and Selection Plan
    The Evaluation and Selection Plan documents how bidder proposals will be reviewed and evaluated. The selection of the eventual winning bidder will be determined by the guidance and scoring methods defined by this plan.
     
     
  • F
    Functional Area Resources Support through System Decommission
    This template is a sample matrix for considering and planning a project level of staffing support by functional area as a project activities in phasing down and moving toward system decommission. This template was originally created for a project which migrated customers to a different system and project over three phases.
     
     
    Functional Organization Charts
    OSI has developed recommended function based organization charts for the Acquisition, System Development, and Maintenance and Operations phases of a project. These charts do not illustrate an organization's reporting structure.
     
     
  • G
    GC 19130 Justification Form
    The GC 19130 Justification documents the statutory authority to contract out for personal or consulting services. Once completed, it is attached as a support document to the ITPP.
     
     
    Governance and Communication Plan
    The Governance and Communication Management Plan identifies the organization structure, processes and procedures used to govern and communicate to ensure the successful decommission of the Project.
     
     
    Governance Plan
    The Governance Plan describes the specific roles and responsibilities of the project and its stakeholders, focusing primarily on authority level and decision-making structure. While some high-level roles and responsibilities are discussed in the Project Charter and/or the Interagency Agreement, the Governance Plan contains the detailed list. For small projects with few stakeholders, this document may be absorbed into the Master Project Plan.
     
     
  • H
    No Items for this Letter...
  • I
    Ideal Staffing by Phase and Complexity
    Addition of Ideal Staffing by Phase and Complexity chart which is based on CA-Project Management Methodology (CA-PMM) definitions of project complexity for Medium, Large, and Mega project and OSI expert input as to the essential functions which must be staffed during the Acquisition, System Development, and Operations.
     
    Implementation Plan
    The implementation Plan shall describe the Contractor's operational preparation necessary for implementating the [Project Name] system. It should describe the scope, impact analysis, installation of network, hardware, software, security, documentation, training, data conversion, interfaces, and staff transition to the new system.
     
     
    Information Technology Procurement Plan (ITPP)
    The ITPP is a DGS mandated document that describes the strategy the project office will use (e.g. firm-fixed price, cost-plus) in procuring goods and services from a vendor. The ITPP is prepared in conjunction with the FSR or initial IAPD. The format of the ITPP is controlled by DGS.
     
     
    Interface Plan
    The Interface Plan shall describe the unique interfaces involved with the new system. It presents the systems functional, technical, and operational design that accurately reflects the contractor’s creation and support of these interfaces.
     
     
    Introduction to System Decommission Workplan shell
    This document provides some background as to how the System Decommission MS Project document was developed. The System Decommission Microsoft Project Work Plan shell is based on the successful System Decommission of the Interim Statewide Automated Welfare System (ISAWS). The ISAWS maintained and operated two mission critical eligibility systems on behalf of 35 California counties.
     
     
    Introductory Letter to User Groups
    The purpose of this letter is to formally communicate to stakeholders the beginning of the System Decommission of the project. The letter explains why system decommission is occurring, how the activities will be planned, managed and communicated.
     
     
    Issue and Escalation Process
    The Issue and Escalation Process describes how the project identifies, tracks and manages issues and action items that are generated throughout the project life cycle. The process also defines how to escalate an issue to a higher-level of management for resolution and how resolutions are documented.
     
     
  • J
    No Items for this Letter...
  • K
    Key Budget Schedules
    The Key Budget Schedules document provides information on the various schedules associated with the Budget Summary. The schedules (1-12) described in this document are those that may be the most useful for the public, private sector, or other levels of government.
     
     
    Knowledge Transfer and Training Plan
    The Contractor shall develop (in cooperation with the [Project Name] Project Office) a Knowledge Transfer and Training Plan to describe the approach for bringing managers, end users and technicl personnel to a familiar level of understanding with how the new system works and how it differs from the system being replaced.
     
     
  • L
    Lessons Learned
    The Lessons Learned is a list of observations and suggestions for future improvement based on recent project experiences that may be used by other projects. Lessons may identify both successful and unsuccessful activities.
     
     
    Logical Data Model
    This template provides a data model of the information system in business friendly language. The logical data model includes a data dictionary, data classification, and relationship information. The model will be used to as an input to the physical data model.
     
     
    Logical Service Model
    This template provides a model of the application and the services provided in business friendly language. Identifies the service components of the solution.
     
     
    Logical Technology Model
    This template provides a model of the infrastructure requirements needed to host an application’s solution. The model will be used to help build the Physical Technology Model.
     
     
  • M
    Maintenance Contract Termination Letter
    The purpose of this letter template is to request cancellation of the referenced maintenance service agreement with an effective date determined by the project and in keeping with the contract’s notification requirement.
     
     
    Master Project Management Plan (MPP)
    The Master Project plan establishes how the project office will manage the project. It is the highest-level authority for project management under the project charter and is the document that ties all other project management documentation together.
     
     
    Migration – 90 Day Notification of Network Infrastructure Disconnection
    The purpose of this letter template is to notify the user entity that they will be migrating from the current project applications to the future project application. As a result of this migration the current project’s network infrastructure will be disabled. The purpose of this letter is to inform the user entity how project plans to disable the network/circuits and ask the user entity to assess and confirm network readiness for cutover.
     
     
    Migration – Conversion Workgroup Roles and Responsibilities
    This document template states the purpose and frequency of the Conversion Workgroup meetings. The document all includes a table which details the roles and responsibilities for all stakeholders groups which are member of the Conversion Workgroup.
     
     
    Migration – Cutover Checklist Reference Guide
    As part of the planning efforts for cutover activities, the County Cutover Checklist details the tasks and activities that will be completed by each county (or user group). Tasks on the County Cutover Checklist correspond to related tasks on checklists executed by Current System project resources. Counties will use this County Cutover Checklist reference guide as their primary tool to execute any Current System related tasks. The tasks are listed in chronological order with the pre-cutover, cutover, and post-cutover phases of activity.
     
     
    Migration – Post Cutover Support Plan
    This support guide template is used to document the post cutover support plan and communication protocol for the migrating user group or counties. Should Current System Project Staff be contacted by Current System county staff, New System project staff, Interface partners or Stakeholders after “Go Live” this guide would be used as a reference for documenting the contact and redirecting the contact to the appropriate resource.
     
     
    Migration Data Mapping Spreadsheet
    This Migration Data Mapping spreadsheet is a template which may be used to map data elements of the current system to the future system in preparation for data conversion.
     
     
    Migration Interface Partner Agreement
    This document template serve as an agreement between two entities working together to prepare the migration of users from one system to another. The document should provide details by phase of roles and responsibilities, technical requirements and schedule. This document will serve as an agreement between projects and agencies to facilitate testing and cutover processes.
     
     
    Migration Project to Project Communication Plan
    The purpose of Project to Project communication plan is to identify all key project stakeholders, define required information, sources of information, communication frequency and format to ensure that both project are away of all migration-related activities, user business process are not adversely impacted by migration, and the migrating users have to tools necessary to participate in conversion, interface and testing activities which support successful migration to the new system.
     
     
    Migration Recovery Work Plan
    This Microsoft Project plan shell is for migration recovery activities in the event a decision is made to stop migration activities and roll back to the old system.
     
     
    Migration Weekly Status Report
    The Migration Weekly Status Report is a weekly executive summary report which summarizes overall project status, major activities in progress, risks, issues, upcoming meetings, requests for change or information, and project to project communications.
     
     
    Transition to M&O Plan
    The Contractor Transition to M&O Plan will be the document that describes how the Contractor intends to support the System during the contractual period and transitions that support over to the responsible State entities.
     
     
  • N
    No Longer System of Record Notice to Counties
    This is a letter template used to notify counties that as of a specific date they have migrated to a new system and the previous system is no longer the system of record for the county. The county’s access to previously provided applications has been disabled. The letter also provides contact information for any issues which may be associated with the migration.
     
     
    No Longer System of Record Notice to Interface Partners
    This letter template is for use when system users are being migrated from one system to another. The purpose of this letter is formally communicate to system interface partners the counties listed (or other entity) have been successfully migrated and provides some detail as to prior notifications, and when the last file was sent and/or received.
     
     
  • O
    start here:
    Operational Support Documentation Outline
    The Operational Support Documentation Outline document provides guidance in the uniform creation of the operational support document. 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.
     
     
    Operations Shutdown Plan
    This is a MS Project skeleton for planning and executing the system decommission of an IT infrastructure. Included are planning, coordination, hardware, software, network, reuse and recycling, data destruction and retention, and asset management elements.
     
     
    Organization Chart(s)
    Please see Functional Organization Charts in Section F.
     
     
     
    OSI Acquisition Document Acknowledgement Letter
    This letter template is for use in memorializing an agreement with the OSI Acquisitions Center regarding the responsibility they will assume after System Decommission for guardianship of procurement documents specified in the agreement.
     
     
    OSI Budgets Document Acknowledgement Letter
    This letter template is for use in memorializing an agreement with the OSI Budgets regarding the responsibility they will assume after System Decommission for guardianship of fiscal documents specified in the agreement.
     
     
    OSI Budget Language Definitions
    The OSI Budget Language Definitions document provides budgetary terms which are used frequently throughout the Governor’s Budget, the Governor’s Budget Summary, and the annual Budget Bill. Definitions are provided for terminology that is common to all publications.
     
     
    Overlap Assessment Toolkit
    The Overlap Assessment Toolkit consists of the Overlap Analysis Process, To-Be Consolidated Reference Model (CRM), ITCP and To-Be CRM EA Coding Training Module, Overlap Report template, Overlap Assessment Worksheet Template, and OSI Multi Departmental Framework. The Overlap Assessment Toolkit assists departments in analyzing proposed Information Technology (IT) projects for potential leverage opportunities. Departments may also use the Solution Architecture Framework and Toolkit found under the letter "S" to refine their IT Concepts.
     
    Migration Planning Process (under construction)
     
  • P
    Physical Data Model
    This template provides a model of the information system in vendor specific terms and language in detail. Includes the specification for all tables and columns and foreign keys to identify relationships between tables. The physical data model may differ from the logical data model based on physical considerations.
     
     
    Physical Service Model
    This template provides a model of the application and the services provided in detail. Identifies the service components of the solution.
     
     
    Physical Technology Model
    This template provides a model of the infrastructure requirements needed to host an application’s solution.
     
     
    Planning Session Ground Rules
    Provide concise guidelines for ensuring productive participatory planning sessions. These ground rules should be shared with invitees in advance and reviewed during the opening segment of planning sessions.
     
     
    Post Implementation Evaluation Report
    A PIER is created at the completion of an IT project and describes the results of the project, including actual completion dates and costs, objectives achieved, lessons learned, and corrective actions for any objectives not achieved. The format of the PIER is dictated by OCIO. The PIER template and instructions may be accessed via the SIMM link found under External Links found on the Navigation Menu to your left.
     
     
    Program Charter
    The Program Charter describes the purpose, expected outcomes, and high-level approach to the program. The charter is used to confirm expectations with the sponsor and stakeholders and to formally authorize the program.
     
     
    Program Governance Plan
    The Program Governance Plan describes the specific roles and responsibilities of the program management group and stakeholders, focusing primarily on authority level and decision-making structure. While some high-level roles and responsibilities are discussed in the Project Charter and/or Interagency Agreement(s), the Governance Plan contains the detailed list.
     
     
    Program Issue and Escalation Process
    The Issue and Escalation Process describes how the program identifies, tracks and manages program-level, cross-project, or escalated project issues and action items that are generated throughout the program life cycle. The process also defines how to escalate an issue to a higher-level of management for resolution and how resolutions are documented.
     
     
    Project Charter
    The Project Charter describes the purpose, expected outcomes, and high-level approach to the project. The charter is used to confirm expectations with the sponsor and stakeholders and to formally authorize the project.
     
     
    Project Concept Statement
    The Project Concept Statement is a brief statement summarizing the purpose, approach, necessary resources, risks, and impacts of a proposed project/initiative. Executive management uses the concept statement to determine if the proposed project/initiative can be successful based on current resource availability, skill sets and timelines. If approved, the concept statement is used to create the Project Charter.
     
     
    (Master) Project Management Plan (MPP)
    The Master Project plan establishes how the project office will manage the project. It is the highest-level authority for project management under the project charter and is the document that ties all other project management documentation together.
     
     
    Project Status Summary Reports
    The Project Status Summary Reports vary in format and purpose, and are targeted to different stakeholder audiences. The importance of standardized reporting on project status is vital to project success and is therefore included as a placeholder for future improvements.
     
     
  • Q
    Quality Management Plan
    The Quality Management Plan defines how the project will tailor and administer the OSI quality program to project-specific conditions. The Quality Management Plan uses IEEE Std 730 as its framework and incorporates considerations for process improvement and test and evaluation.
     
     
  • R
    Records Management – Administrative Records
    This document represents the DGS guidelines for management and retention of administrative records and is part of the California Records and Information Management program (CalRIM).
     
     
    Records Management – Fiscal Records
    This document represents the DGS guidelines for management and retention of fiscal records and is part of the California Records and Information Management program (CalRIM).
     
     
    Records Management – General Guidelines
    This document represents the DGS general guidelines for management and retention of records and is part of the California Records and Information Management program (CalRIM).
     
     
    Records Management – Information Technology Records
    This document represents the DGS guidelines for management and retention of information technology records and is part of the California Records and Information Management program (CalRIM).
     
     
    Records Management Evaluation and Recommendation
    One of the components of System Decommission is the review, evaluation and recommendation of the final disposition of all hardcopy and electronic records. The purpose of this document is to provide management with a synopsis of the policies and guidelines provided by state and federal authorities, interpretation and resulting recommendations. This document further defines the initial approach and partner interface as it relates to final disposition of fiscal and historical documents.
     
     
    Records Management Overview and Transition
    This document details the basis for the projects record management policy , the retention scheduled for documents to be retained, identification of the trustee, the plan for transition of the repository, and a description of the repository’s organization to facilitate ease of use by the trustee in response to any requests for information.
     
     
    Request for Proposal (RFP)
    The Request for Proposal (RFP) used to solicit proposals from the bidding community based on a set of defined requirements. The requirements may be general in nature allowing the bidders to propose a solution and the specific products to be used. The RFP describes the problem requirements, contractual terms, and required format for the proposal responses. The RFP also includes the specific criteria which will be used to evaluate the received proposals. The project works with DGS to ensure the RFP meets all appropriate state guidelines and regulations.
     
     
    Requirements Management Plan
    The Requirements Management Plan provides guidance on how to develop and manage clear and complete project requirements.
     
     
    Requirements Traceability Matrix Outline
    The Requirements Traceability Matrix Outline provides guidance to the uniform creation of the requirements traceability matrix. The requirements traceability matrix maintains linkage from the source of each requirement through its decomposition to implementation and verification. The traceability matrix should contain columns that will be used to illustrate traceability to the requirements of the project contract, system and software specifications and detailed design specifications. The traceability is required to ensure that all requirements for the project are address and that only what is required is developed.
     
     
    Release Notes
    The Contractor shall apply release notes for each release of software to the [Project Name] system.
     
     
    Risk Management Plan
    The Risk Managment Plan defines the process and how the OSI-defined tool (e.g. Risk Radar) is used to implement the methodology for risk management, including identification, quantification, and response to project risks.
     
     
  • S
    Schedule Management Plan
    This Schedule Management Plan provides guidance on how to develop, manage, and control the schedule throughout the Project Life Cycle.
     
     
    Schedule Management Plan - Supplemental Information
    This document is a supplement to the recently released Schedule Management Plan template and provides detailed guidance regarding scheduling, the Work Breakdown Structure (WBS), and estimating activity durations.
     
     
    Scope and Governance Plan Overview
    This document provides an overview of the purpose and scope for each system decommission workgroup. The document describes the functional areas assigned for planning and execution.
     
     
    Software Requirements Specification Outline
    The Software Requirements Specification Outline provides guidance in the uniform development of the software requirements specification document, which is a structured collection of information that embodies the requirements of the software. The purpose of the software requirements specification is to communicate the stakeholder entities requirements to the technical resources that will specify and build the software to meet the requirements.
     
     
    Staff Management Plan
    The Staff Management Plan identifies the process and procedures used to manage staff throughout the project's life cycle. The plan describes the planning and acquisition of both state staff and consulting staff, describes the roles and responsibilities assigned to each staff, and discusses staff transition.
     
     
    Solution Architecture Framework (SAF) and Toolkit
    The Solution Architecture Framework establishes a systematic approach for creating a roadmap to achieve a project’s mission and to attain a solution with optimal performance of its core business processes delivered within an efficient Information Technology environment. To assist in the development of the roadmap, the Solution Architecture Toolkit provides a series of templates, instructions, and examples of completed models to facilitate the development of an architected solution and architecture deliverables.
     
     
    Staff Orientation Guide
    The Staff Orientation Guide defines the administrative processes, procedures, and guidelines for things related to the general operations of the project office, but not directly related to the contractual obligations or project-specific processes.
     
     
    System Decommission – Periodic Internal Status Report
    The System Decommission Internal Status Report template is used by System Decommission management (including the Workplan manager) to provide periodic written reports to project senior management. The report includes overall project status, status of each function area, a narrative of what has transpired in each functional area since the last report period, risks, issues, and proposed schedule changes.
     
     
    System Decommission Closeout Report by Plan
    The System Decommission Planning Guide is split into individual plans for major areas of activities such as: Application Decommission, Asset Management, Contract Management, Interface Management, Fiscal Transition, Operations Shutdown, Staffing, and Records Management. This template is used post-execution to summarize the performance of the execution of each individual plan and to document best practices and lessons learned. These reports can then be rolled up into an overall System Decommission final report.
     
     
    System Decommission Planning Guide
    This document is a compilation of workgroup plans by system decommission functional area. The guide includes a key dates/activities schedule and each workgroup plan which covers: purpose scope, approach, roles & responsibilities, and risk management and mitigation strategies.
     
     
    System Decommission Workplan Shell
    This is a Microsoft Project skeleton for System Decommission planning. Included are sample control dates, planning, execution, and post-execution milestones and activities.
     
     
    System Engineering Management Plan
    The System Engineering Management Plan shall describe the contractor’s proposed efforts for planning, controlling and conducting a fully integrated engineering effort. The Plan will be used to understand and evaluate the contractors engineering work efforts as part of the contract monitoring process.
     
     
    System Requirements Specification (SyRs)Outline
    The System Requirements Specification (SyRs)Outline document provides guidance in the uniform development of the system requirements specification document, which is a structured collection of information that embodies the requirements of the system. The purpose of the system requirements specification is to communicate the stakeholder entities requirements to the technical resources that will specify and build the system to meet the requirements.
     
     
    System Security Plan
    The System Security Plan describes the Contractor's approach to ensuring that the [Project Name] system (including all network components under the control of the Contractor, either by ownership or through contractual agreements) meets the security standards required by the [Project Name] Project. This DID is based on ISO/IEC 27002 Information Technology, security techniques, code of practice for information security management. In the event the Contractor has an existing security framework or plan based on ISO/IEC 27002, that document may be submitted in lieu of this deliverable pending state approval.
     
     
  • T
    Technical Reviews
    Technical Reviews are conducted at the end of each SDLC phase of the Project Life Cycle. The technical reviews offer the opportunity to gather all of the information and documentation needed for a specific phase. All decisions will be documented and agreed to prior to moving into the next SDLC phase.
     
     
    Test Cases Outline
    The Test Cases Outline provides guidance in the uniform creation of the project test cases. The purpose for the creation of test cases is to allow for the comparison of the system against the defined specifications. The creation of the test cases should utilize a standard format with definitions of the form and content describe in the outline section of this document.
     
     
    Test Summary Report Outline
    The Test Summary Report Outline provides guidance in the uniform creation of the project test summary report. The test summary report derives its information from the results of the testing effort and should summarize all testing activities and results. The test summary report’s ultimate goal is to provide a formal reporting mechanism related to the testing phase. The creation of the test summary report should utilize a standard format with definitions of the form and content describe in the outline section of this document.
     
     
    Test/Incident Tracking Log Outline
    The Test/Incident Tracking Log Outline provides guidance in the uniform creation of the project test log. The test log is coupled with the test cases and the purpose for its creation is to provide a chronological record about the actual execution of tests. The results of the tests provide detailed evidence for incident reporting and enable reconstruction of testing as needed. The creation of the test log should utilize a standard format with definitions of the form and content describe in the outline section of this document.
     
     
    Testing Supplemental Information
    The Testing Supplemental Information contains general information regarding the different test stages used throughout the System Development Life Cycle. This document should be used as a reference when developing the Test and Evaluation Master Plan.
     
     
    Test and Evaluation Master Plan
    The Test and Evaluation Master Plan describes how the project will perform each stage of testing throughout the project. Use the Testing Supplemental Document as a resource when developing the Test and Evaluation Master Plan. The testing templates provide a place to capture all of the testing data.
     
     
    Training Plan
    The Training Plan shall describe how the contractor will provide training to state and customer/user community staff during the transition.
     
     
    Transition to M&O Plan
    The Contractor Transition to M&O Plan will be the document that describes how the Contractor intends to support the System during the contractual period and transitions that support over to the responsible State entities.
     
     
  • U
    User Documentation Outline
    The User Document Outline provides guidance in the uniform creation of user documentation. It outlines the structure and informational content the user document should contain to create a complete and usable document. Proper identification of the documents intended audience is crucial to determining it usability for its purpose.
     
     
  • V
    Vendor Handbook
    The Vendor Handbook provides contracted vendors with standardized administrative guidance on matters related to their interactions specific to the OSI organization. The vendor handbook is typically referenced in the Contract Management Plan.
     
     
  • W
    Workgroup Scope and Governance Plan
    This document describes the purpose, scope, and organization of the workgroup. Further, the document describes roles, responsibilities, the decision-making process, support from the larger organization, and status reporting.
     
     
  • X
    No Items for this Letter...
  • Y
    No Items for this Letter...
  • Z
    No Items for this Letter...