Skip to content

Latest commit

 

History

History
514 lines (303 loc) · 38.8 KB

Accessibility-Procurement-Pilot-Modified.md

File metadata and controls

514 lines (303 loc) · 38.8 KB

Original from https://github.com/mgifford/a11y-contracting/blob/master/Accessibility-Procurement-Pilot.md

Accessibility Procurement Pilot

LETTER OF INTEREST

ACCESSIBILITY PROCUREMENT PILOT ON BEHALF OF

TREASURY BOARD OF CANADA SECRETARIAT

1. PURPOSE

The purpose of this Letter of Interest (LOI) is to notify industry of GC’s intention to:

  • issue a Call for Proposals (CFP) in relation to the Treasury Board of Canada Secretariat’s Open by Default Pilot Portal;
  • to provide advance notice of the challenges for which GC intends to seek proposals; and
  • to provide industry the opportunity to give written feedback on the requirement and procurement strategy.

GC is looking to partner more closely with leading innovators in GC and abroad to help address accessibility issues specifically relating to documents on the Open by Default Pilot Portal, which is housed on the open government website, Open.canada.ca (“Open Government website”).

2. BACKGROUND

The Government of Canada (“GC”) is committed to advancing openness and transparency. Governments today face barriers to being completely open to all Canadians. About 14% of Canadians report having a disability that limits day-to-day activities. With an aging population, this percentage will likely increase. Many Canadians also live with invisible disabilities. Others may not wish to report having one. GC faces a clear imperative to be inclusive. For a multitude of reasons we must work to remove barriers to persons with disabilities in this country.

The accelerating pace of digital change means that new tools are being introduced. Most do so without consideration for accessibility, others are focus on enhancing it. Accessibility issues can be both varied and complex. Emerging approaches show promise in helping to reduce barriers. GC is committed to raising the bar on accessibility to be an international leader for equality and human rights.

2.1 EXISTING WEB STANDARDS, GUIDANCE, AND RESOURCES

The GC Open Government committments rely on open standards, of which the following shoul be considered for this project.

These are the guidelines currently required for GC websites:

Like all digital medium itself, change is inevitable. GC takes inspiration from internationally recognized standards that support an improved user experience for all users.

Where possible, the project should take into consideration the best practices outlined in these open standards:

  • W3C WCAG 2.0 AAA - these guidelines were designed to be aspirational. Where possible see if it is possible to leverage these guidelines.
  • W3C Authoring Tool Accessibility Guidelines (ATAG) 2.0 - This 2015 guideline is in two parts. Part A asks that the authoring experience meets WCAG 2.0 guidelines. Part B supports the production of more accessible web content through better software.
  • W3C WCAG 2.1 W3C Working Draft - Although still a Working Draft, this revision of the Web Content Accessibility Guidelines 2.0, is working to provide better access for a broader range of people. Content that conforms to WCAG 2.1 also conforms to WCAG 2.0, and therefore to policies that reference WCAG 2.0 - https://www.w3.org/TR/WCAG21/
  • European Union EN 301 549 – A European Union initiative for public procurement for improving accessibility of information and communications technology (ICT) products and services. Specifies the functional accessibility requirements applicable to ICT products and services. Each accessibility requirement includes a description of the test procedures and evaluation methodology - http://mandate376.standards.eu/standard

3. REQUIREMENT

  • Any Solution proposed must be open source software (OSS) solution.
  • Unless specified otherwise, all written communications will be in an electronic and accessible format. Acceptable formats include .txt, .odf, .doc(x) and .epub. If properly tagged for accessibility .pdf will be accepted.
  • Responses must be in either English or French, at the preference of the Respondent.

3.1 TBS - OPEN BY DEFAULT PILOT PORTAL (CHALLENGE 1)

The Challenge for which Solutions will be sought on behalf of TBS is described in Attachment 3, Statement of Work for Open by Default Pilot Portal Challenge. Please note Attachment 3 is a draft document and is subject to change.

4. PROCESS

General

  • All communications will be available in French and English and will be provided in an accessible format.
  • All formal communications and ammendments will be made through the Buy and Sell website - https://buyandsell.gc.ca/

LOI Process

  • GC issues a LOI to get express interest in the pilot.
  • Industry submits letters - See Attachment 2 for more detail.
  • Submissions should be sent directly to the Contracting Authority on or before December 12, 2017 at 14h00 EST.
  • GC reserves the right to request additional information for clarification after submission.
  • No payment will be made for costs incurred in this phase.
  • GC is under no obligation enter into any agreement or to accept any suggestions from industry.
  • This industry consultation process is not a solicitation and a contract will not result from this request.
  • More information is availabe in Attachment 2 - Industry Engagement Questions

Planned CFP Process

  • GC issues CFP with input received from Industry.
  • CFP will include assessment criteria that are both mandatory and point-rated.
  • Proposals which meet all mandatory criteria and the minimum point-rated criteria score will be placed in a pool of pre-qualified proposals, provided that the total evaluated price does not exceed the budget available for the requirements.
  • More details of the process are defined in Appendix 3.

The proposed contract will include three 3 Phases. In Phase 1 each Contractor will be required to:

  • demonstrate a functional prototype of their Solution (defined as a minimum viable demonstration of capability).
  • The presentation to a panel anticipated to be held in Shawinigan, Quebec in mid-March 2018. Reasonable expenses for attending the panel presentation will be covered, see Appendix 3 Section 4.1.2 for details.
  • The maximum funding available for Phase 1 of any contract resulting from this CFP is $15,000.00, applicable Taxes excluded. The expenses associated with attending the panel are excluded from this cap.

The maximum funding available for all phases of any contract resulting from this CFP is $320,000 for the Open by Default accessibility challenge, applicable taxes and travel and living expenses are excluded.

5. GOVERNMENT OF CANADA APPLICABLE POLICIES

All Bidders responding to the resulting CFP must be in possession of a Procurement Business Number (PBN) which can be obtained through the Supplier Registration Information System - https://srisupplier.contractscanada.gc.ca

All responses to CFPs require that the Legal Name of the business and PBN are clearly included.

These policies apply:

6. LICENCING

Solutions developed (not pre-existing) for either challenge must be licenced under the MIT Licence. Where Bidders or Contractors are leveraging existing open source projects, adopting the parent licence of the open source software project is preferred, where the licence is approved by the Open Source Institute (OSI). A list of OSI approved licences is available at - https://opensource.org/licenses/alphabetical

Under any contract resulting from the CFP, the Contractor will be required to deposit the Solution’s source code in a public facing repository on the GitHub platform - https://github.com - under an open source license as specified above.

The Contractor must create and maintain a public repository for the project on GitHub during the period of the Contract. All updates to the Solution source code must be deposited on GitHub, as well as, the final Solution source code. Before the final payment, the ownership of the code should be transferred to https://github.com/canada-ca - this will enable anyone to subscribe to notifications of changes while also allowing for conversations, issue tracking, and code reviews.

Should accessibility issues be found "up-stream" in libaries used by the project, efforts should be made to ensure that:

  • a search is done to confirm that the community knows about the problem
  • patches supplied by the community are tested, if they resolve the pattern, then this should be added to the issue queue before the project is finalized.
  • if no patch is available, but one is generated on behalf of the contract, that should be submitted to the parent project
  • all of this should be documented for the GC

7. CONTRACTING AUTHORITY

All enquiries and communication with the Government regarding GC’s requirement under this LOI must be directed in writing to the Public Services and Procurement Canada Contracting Authority as detailed below. Any clarification or information received from other Government officials will not be considered as an official response.

Heather Wilson 
Supply Team Leader
Public Services and Procurement Canada 
Telephone: 873-469-4791 
E-mail: TPSGC.paouvertpardefaut-apopenbydefault.PWGSC@tpsgc-pwgsc.gc.ca

ATTACHMENT 1

RULES OF ENGAGEMENT PARTICIPATION AGREEMENT

An overriding principle of the industry consultation is that it be conducted with the utmost of fairness and equity between all parties. No one person or organization will receive nor be perceived to have received any unusual or unfair advantage over the others.

TERMS AND CONDITIONS:

The following terms and conditions apply to the Consultative Process. In order to encourage open dialogue, Participants agree to:

a. Discuss their views concerning the requirement and to provide positive resolutions to the issues in question. Everyone will have equal opportunity to share their ideas and suggestions;

b. NOT reveal or discuss any information to the MEDIA/NEWSPAPER regarding the requirement during this consultative process. Any Media questions will be directed to the PWGSC Media Relations Office at 819-956-2313;

c. Throughout the entire Consultative Process, all questions from industry, exchanges of information and all the industry feedback must be provided in writing to the Contracting Authority. In accordance with and subject to the Access to Information Act, R.S., 1985, c. A-1, and any other legislative or legal requirement. All information which is provided by a Participant and which is clearly marked as “Proprietary” will not be released or disclosed;

d. GC is not obligated to issue any CFP, or to negotiate any contract for the requirement;

e. If GC does release a CFP, the terms and conditions of the CFP will be subject to GC's absolute discretion;

f. The information gathered from the written responses will be summarized and provided to all Participants, with the exception of proprietary or confidential materials;

g. GC will not reimburse any person or entity for any cost incurred in responding to the LOI;

h. Participation in this Consultative Process will not be a mandatory requirement for any subsequent CFP. An entity will not be precluded from submitting an proposal under any subsequent CFP on account of they not being a Participant;

i. At any point within this process, a Participant may provide notice to the Contracting Authority that they no longer wish to participate in the Consultative Process.

j. Failure to agree to and sign the Rules of Engagement Participation Agreement will result in the exclusion from participation in the consultative process. This Rules of Engagement Participation Agreement must be signed by a duly authorized officer of the Participant in this respect;

k. A dispute resolution process to manage impasses throughout this Consultative Process must be adhered to as follows:

DISPUTE RESOLUTION PROCESS

  1. By informal discussion and good faith negotiation, each of the parties must make all reasonable efforts to resolve any dispute, controversy or claim arising out of or in any way connected with this Consultative Process.

  2. Any dispute between the Parties of any nature arising out of or in connection with this Consultative Process must be resolved by the following process:

a. Any such dispute must first be referred to the Participant's Representative and the PWGSC Manager managing the Consultative Process. The parties will have 3 Business Days in which to resolve the dispute.

b. In the event the representatives of the Parties specified in Article 2.a. above are unable to resolve the dispute, it will be referred to the Participant's Project Director and the PWGSC Seni or Direct or of the Division responsible to manage the Consultative Process. The parties will have 3 Business Days to resolve the dispute.

c. In the event the representatives of the Parties specified in Article 2.b. above are unable to resolve the dispute, it will be referred to the Participant's legal Signing Authority and the PWGSC Director General, who will have 3 Business Days to resolve the dispute.

d. In the event the representatives of the Parties specified in Article 2.c. above are unable to resolve the dispute, it will be referred to the Participant's legal Signing Authority and the PWGSC Assistant Deputy Minister, Acquisitions Branch who will have 10 Business Days to resolve the dispute.

e. In the event the representatives of the Parties specified in Article 2.d. above are unable to resolve the dispute, the Contracting Authority will within 5 Business Days render a written decision which will include a detailed description of the dispute and the reasons supporting the Contracting Authority's decision. The Contracting Authority will deliver a signed copy thereof to the Participant.

By signing this document, the individual represents that he/she has full authority to bind the company listed below and that the individual and the company agree to be bound by all the terms and conditions contained herein.

Name of Company (Print):


Name of individual (Print):


Title or Position (Print):


Telephone:


E-mail:


Signature:


(I have the authority to bind the Company) Date:


ATTACHMENT 2

INDUSTRY ENGAGEMENT QUESTIONS

The questions contained in the sections below are intended to elicit feedback of interest to GC and provide guidance to industry in preparing written responses. It is not expected that all questions will elicit a response, neither should submissions be constrained by the questions.

Respondents are encouraged to submit a response to the Industry Engagement Questions in an accessible, unrestricted electronic format (Text, Open Document Format or EPUB are preferabley) by the LOI closing date.

1. RESPONSE FORMAT

The Respondent’s name, company, address, and contact information and the LOI number should be clearly visible in the response.

The response is to be submitted by e-mail to the Contracting Authority.

Only include general marketing material unless it provides specific information relevant to a response. If it is included the supporting text in the LOI should cross-reference the marketing material.

Only written LOI presentations can be submitted and responses will not be returned.

Please keep the length of your response to under 2500 words, plus the signed copy of the Rules of Engagement Participation Agreement (as per Attachment 1). These can be provided as a PDF file to allow for analog signatures.

2. RESPONSE PARAMETERS

Respondents are reminded that this is an LOI and not a CFP and, in that regard, Respondents should feel free to provide their comments and concerns with their responses.

GC reserves the right to seek clarifications from a Respondent for any information provided in response to this LOI, either by telephone, in writing or in person.

3. CONFIDENTIALITY

Respondents are requested to clearly identify those portions of their response that are company confidential or proprietary in nature. The confidentiality of each Respondent’s response will be maintained. Items that are identified as proprietary will be treated as such except where GC determines that the enquiry is not of a proprietary nature. GC may edit the questions or may request that the respondent do so, so that the proprietary nature of the question is eliminated, and the enquiry can be answered with copies to all interested parties.

SECTION 2: REQUIREMENT

  1. Following the Planned CFP Process outlined above, GC is seeking feedback in the LOI as to whether:

a. three weeks is enough time to develop a working prototype for the presentation.

b. $15,000 is an appropriate amount to develop a working prototype as described above.

c. the description of the working prototype is sufficiently clear to prepare the demonstration?

  1. In your view, are there problems with what has been outlined in the Letter of Interest?

  2. The Statement of Work in Attachment 3 provides a number of examples. We want to know if you consider them technically feasible?

  3. Do you have concerns with any of the proposed deliverables in either of the Statements of Work?

  4. Please provide any additional feedback that you think will help increase the impact of this LOI.

  5. Tell us if you are potentially interested in bidding on the CFP when it is released.

Common Footer:

Accessibility Procurement Pilot Letter of Interest Public Services and Procurement Canada LOI # 24062-180181/A


Attachment 3

Statement of Work for Open by Default Pilot Portal Challenge

1. Introduction

The Government of Canada has outlined commitments to advance openness and transparency through Action Plans on Open Government submitted to the Open Government Partnership since 2012. One of the core mandates expressed in these action plans is to advance openness through the open government website - https://open.canada.ca

The Open Government website was initially launched as a pilot, data.gc.ca, in 2011. The pilot open data portal then expanded to include various information resources and to facilitate engagement on the open government initiative and associated activities. In keeping with GC’s initial strategy on open government, the current Open Government website’s architecture is built around the pillars of open data, open information and open dialogue, and its infrastructure is built on open source solutions: CKAN, Drupal 7 and Apache Solr. As GC continues to advance the open government initiative and to release a growing number of resources, it has become apparent that the accessibility of content needs to be improved. There is also a desire to do more in terms of engaging with users and visitors through the Open Government website.

GC is committed to removing barriers to access for Government information and services. With that in mind, GC is mandated to ensure that all websites and web applications adhere to Web Content Accessibility Guidelines (WCAG) 2.0 AA.

New resources of information are constantly being added to the Open Government website and the future vision is for it to become a hub of data, information and opportunities to participate and learn. Early research indicates that a majority of users are seeking data of one type or another, with a smaller but significant group looking for opportunities to participate or engage with government.

As GC’s work on open government advances, there are opportunities to improve the user experience of its online tools, including improving access to digital publications and draft documents made available by the Government of Canada.

2. Background

2.1 The Open by Default Pilot Portal (http://pilot.open.canada.ca/open-by-default-pilot)

The new Open by Default Pilot Portal (Pilot Portal) is the latest component of the Open Government website. This is an online beta site where non-sensitive federal working documents available to the public. This provides users with insight into what Government of Canada employees are working on. The Open by Default Pilot Portal leverages existing operational systems that power open.canada.ca. In the pilot these include CKAN, Drupal 8 and Apache Solr. It also leverages GCDocs, an internal records management tool. The technical architecture of the Open by Default Pilot Portal, mirrors that of the Open Government Portal. Instructions to build the environment will be provided as well as all source code for the architecture. Currently all code for this project is available on GitHub - https://github.com/open-data

The Pilot Portal consolidates draft documents (“Digital Assets”) provided by pilot departments. The current departments are Natural Resources Canada, Canadian Heritage, Environment and Climate Change Canada, and the Treasury Board of Canada Secretariat. The Digital Assets in the pilot may not comply with web accessibility standards.

Currently, the Pilot Portal contains approximately 550 Digital Assets. These are in common open formats such as .odf, .csv, .svg, .shp, but also standard Microsoft & Adobe file formats. The collection contains draft policies, internal draft documentation on systems, and presentations. It is expected that future Digital Assets holdings on the portal could be expanded to include audio and video formats. It is also expected that collection could include 100,000s of Digital Assets.

3. Challenge

TBS has a requirement for an open source software solution (“Solution”) (existing or developmental but not proprietary) to enhance and improve the accessibility of both current and future Digital Assets housed on the Open by Default Pilot Portal. Proposed Solutions must also be compatible with the Open Government website’s existing digital infrastructure.

The following illustrative list provides examples of accessibility issues Solutions may address in responding to the challenge. This list is non-exhaustive. All Solutions should assume bilingual content. These are examples of Solutions that may be addresed in the CFP. Ability of the system to:

  • automatically flag Digital Assets when they fail to meet WCAG 2.0 AA. This system should allow for marking WCAG 2.1 and/or EN 301 549 requirements when they become available. It is understood that the best automated tests presently catch about 25% of WCAG 2.0 AA errors.
  • ensure Digital Assets available through the Open by Default Pilot Portal should be able to be converted into a in a variety of formats such as EPUB3, and ODF;
  • provide for all Digital Assets an embed an accessibility compliance report against WGAC 2.0 AA standards as well as other web accessibility standards;
  • programmatically suggest alternative text for images (.gif, .png, .svg, and .jpg).
  • programmatically generate transcripts of voice audio recordings;
  • programmatically generate described video, transcripts, closed captioning for video content created in both official languages;
  • programmatically generate animated American Sign Language or Quebec Sign Language from spoken word audio or video;
  • programmatically assign and display Flesch-Kincaid (or similar) readability tests to determine approximate grade level for English content or Scolarius score for French content;
  • conform to ATAG 2.0 Part B where editors are encouraged to adopt best practices while generating content, such that it is easier to comply with WCAG 2.0 AA. Where possible also conform to WCAG 2.1 and/or EN 301 549.

4. Scope

4.1 Phase 1

4.1.1 Finalization of Draft Design and Implementation Plan

Within 10 working days of the Contract being awarded, the Technical Authority will provide any comments electronically that it has regarding the draft design and implementation plan submitted by the Contractor as part of its bid. The Contractor must update its Design and Implementation Plan to reflect Technical Authority's comments and resubmit it electronically to Technical Authority for approval within 5 working days.

The Design and Implementation Plan must specify the delivery dates for all deliverables identified in Phases 2 and 3.

There will be at least 15 working days following the approval by the Technical Authority before the Contractor may be required to present. Contractors who are invited to present are expected to include a demonstration of a working prototype of the proposed Solution (i.e., a preliminary version of the Solution with basic functionality). 2 days prior to the presentation:

  • the code must be uploaded to the public GitHub repository and ready for the demonstration phase.
  • the presentation to include a Microsoft PowerPoint (.ppt) or Open Office Impress (.sxi) format and a demonstration of the prototype delivered to the Technical Authority.

4.1.2 Demonstration

The Contractor must demonstrate the basic functionality of Solution including at a minimum an early stage functional prototype (defined as a minimum viable demonstration of capability) to the Technical Authority and representatives of GC, in person at a location to be determined by the Technical Authority.

At a minimum the presentation must include: a functionality demonstration of the prototype of the Solution and an overview of the Contractor’s proposed design and implementation plan for Phase 2 and 3. The presentation should also include an overview of the Innovativeness, Scalability, Accessibility and Functionality of the proposed Solution.

The prototype must demonstrate the ability to improve the accessibility of Digital Assets in relation to at least one of the accessibility issues proposed to be addressed in the Contractor’s draft Design and Implementation Plan.

An independent panel will observe the presentation and convene to determine whether to move forward with Phases 2 and 3 of the Contract.

The Contractor will be reimbursed its authorized travel and living expenses reasonably and properly incurred in the performance of the Work, at cost, without any allowance for profit and/or administrative overhead, in accordance with the meal, private vehicle and incidental expenses provided in Appendices B, C and D of the National Joint Council Travel Directive and with the other provisions of the directive referring to "travellers", rather than those referring to "employees".

All travel must have the prior authorization of the Technical Authority.

4.1.3 Financial Proposal

The Contractor must provide a Financial Proposal for Phases 2 and 3 of the Work in accordance with Annex B, Basis of Payment. The Financial Proposal for Phases 2 and 3 will be subject to negotiation with GC. Upon GC’s request, the Contractor must provide Price Support for the Financial Proposal for Phases 2 and 3, which may include; a current published price list indicating the percentage discount available to GC; or copies of paid invoices for the like quality and quantity of the goods, services or both sold to other customers; or price or rate certifications; or any other supporting documentation as requested by GC.

The Financial Proposal for Phases 2 and 3 must include the following information, as applicable, for each element of the Work:

a) Labour: For each individual and (or) labour category to be assigned to the Work, indicate: i) the hourly rate, inclusive of overhead and profit; and ii) the estimated number of hours.

b) Materials and Supplies: Identify each category of materials and supplies required to complete the Work and provide the pricing basis.

c) Subcontracts: Identify any proposed subcontractor and provide for each one the same price breakdown information as contained in this article.

d) Other Direct Charges: Identify any other direct charges anticipated, such as long distance communications and rentals, and provide the pricing basis.

e) Profit: Identify proposed profit, if any, and the basis on which it is computed and applied.

f) Overhead: State the applicable overhead.

g) Applicable Tax: Identify any Applicable Tax separately.

Due date: Within 15 working days of Contract award

4.2 Phase 2 (Conditional)

Following the evaluation process, GC intends to award a contract to the three top ranked bidders from the pool of pre-qualified proposals.

4.2.1 Development and Testing

4.2.1.1 Test Plan

The Contractor must provide a Test Plan to the Technical Authority following commencement of Phase 2. The test plan must demonstrably exercise all new functionality of the Solution. The Test Plan must be in the form of a MS Excel spreadsheet that documents each test case, and include, at a minimum:

  • A test case number;
  • Step-by-step instructions for testers to complete each test case;
  • Success criteria for each test case;
  • Description of the functionality the test case addresses;
  • Fields next to each test case for testers to compile testing notes/results;
  • Test data; and
  • Exit criteria.
4.2.1.2 Baseline testing

The Contractor must execute the test plan, in order to establish a performance baseline of the functionality of the Solution, and update and resubmit the Design and Implementation Plan to the Technical Authority for approval as necessary.

4.2.1.3 Development and Debugging

The Contractor must correct software defects identified during the baseline testing and update the Solution source code. The Contractor must provide a Defect Debugging Report to Technical Authority documenting the defects, and their corrections.

4.2.1.4 Standards Compliance testing

The Solution must comply with Government of Canada Standards for Web Accessibility and Web Security. GC will test the Solution for compliance with these standards. The Technical Authority will provide detailed feedback to the Contractor on any issues revealed by compliance testing. The Contractor must resolve the issues in the source code revealed by compliance testing and update the Solution source code.

Evidence of user testing, debugging, testing for accessibility and security, and an updated Design and Implementation Plan (if applicable) must be provided to the Technical Authority for approval.

4.2.1.5 Deliverable(s):
  1. Test Plan,
  2. Defect Debugging Report,
  3. Evidence of baseline testing, debugging, and resolution of compliance testing issues,
  4. Updated Design and Implementation Plan (if applicable),
  5. Updated Source Code (if applicable).

Due date: To be determined in accordance with the Contractor’s Design and Implementation Plan.

4.2.2 Unit and Integration Testing

4.2.2.1 Unit Testing

The Contractor must perform unit testing and integration testing of the Solution with the Open Government website infrastructure and update the Design and Implementation Plan. The Contractor must perform all unit and integration testing in their own environment.

Where possible, the Contractor is expected to build unit tests for all new code developed. The Contractor must resolve any issues revealed by the automated unit tests and update Solution source code. The Contractor must provide a report electronically to the Technical Authority detailing the results of all automated unit testing.

4.2.2.2 Integration Testing

The Contractor must perform integration testing on its own system, resolve any issues revealed through integration testing and update the Solution source code. GC will provide the Contractor with a free image of Oracle's VirtualBox with the Open by Default Portal configuration allowing the Contractor to configure their environment for integration testing.

As a final test the Contractor must provide instructions and the updated source code for GC to install and test the code on an open.canada.ca development environment. The Contractor must provide a report to the Technical Authority detailing the results of their internal integration testing and the instructions for GC to install and test the source code in the development environment.

In accordance with timelines to be established in the Design and Implementation Plan, The Technical Authority will provide detailed feedback to the Contractor on any issues revealed by its own integration testing. The Contractor must resolve the issues revealed and resubmit the updated source code to the Technical Authority for re-testing.

4.2.2.3 Deliverable(s):
  1. Automated Unit Testing Report,
  2. Contractor’s Integrated Testing Results Report,
  3. Installation and Testing Instructions,
  4. Evidence of unit testing and integration testing;
  5. Updated Design and Implementation Plan (if applicable),
  6. Updated source code (if applicable)

Due Date: To be determined in accordance with the Contractor’s Design and Implementation Plan.

4.2.3 Progress Review Meetings

The Contractor must be attend weekly progress review meetings by teleconference and provide updates to the Technical Authority on progress towards completion of the deliverables. Progress review meetings shall be scheduled by the Technical Authority, and all pertinent details such as teleconferencing information shall be provided to the Contractor by the Technical Authority not less than 24 hours in advance. The Contractor must respond to inquiries pertaining to the completion of deliverables on an ad hoc basis.

The Contractor must prepare a Record of Discussion for each progress review meeting to the Technical Authority electronically within 48 hours of the progress review meeting.

Deliverable - Record of Discussion

Due Date: within 48 hours of the progress review meeting

4.3 Phase 3 (Optional):

4.3.1 Implementation Support

The Contractor will provide technical support to GC, as the Solution is implemented on the production environment. The Contractor must make resources with the knowledge required to implement the Solution on GC’s production environment available via telephone and email to GC during the implementation of the Solution.

Deliverable(s)

Professional services in the form of technical support to GC during the implementation of the Solution.

Due Date: To be determined in accordance with the Contractor’s Design and Implementation Plan.

4.3.2 Software Documentation

The Contractor must prepare all Software Documentation for the Solution and provide it electronically to the Technical Authority.

Deliverable(s)

Software Documentation, consisting of, at a minimum, a technical specification for the Solution documenting the system architecture, subsystem design, and required configuration.

Due Date: To be determined in accordance with the Contractor’s Design and Implementation Plan.

4.3.3 Progress Review Meetings

The Contractor must be attend weekly progress review meetings by teleconference and provide updates to the Technical Authority on progress towards completion of the deliverables. Progress review meetings will be scheduled by the Technical Authority, and all pertinent details such as teleconferencing information will be provided to the Contractor by the Technical Authority not less than 24 hours in advance. The Contractor must respond to inquiries pertaining to the completion of deliverables on an ad hoc basis.

The Contractor will prepare a Record of Discussion for each progress review meeting provide it to the Technical Authority electronically within 48 hours of the progress review meeting.

Deliverable - Record of Discussion

Due Date: within 48 hours of the progress review meeting.

5. Constraints and Operational Environment

The Solution must be compatible with the Open Government website’s existing digital infrastructure. See Appendix 1 to Attachment 3 attached.

5.1 Existing Open Government Website Digital Infrastructure

The Open Government pilot site operates using the following open source tools, in compliance with the listed policies relating to websites for GC.

  • CKAN (Data Catalogue) [Python] – Licensed under the Affero GNU GPL v3.0 License;
  • Apache Solr (Search Engine) - Licensed under the Apache License 2.0;
  • Drupal 8 (Content Management System) [PHP] - Licensed under the GPL v2 License;
  • PostgreSQL (Relational Database Management System - Licensed under the Postgresql License.

The Open Government website is currently housed on a mix of cloud and on premise infrastructure. Solutions must be compatible with infrastructure hosted on the Microsoft (MS) Azure cloud in the Canada Central or Canada East availability regions.

5.3 Design and Implementation Plan

Updates to the Design and Implementation Plan must be approved by the Technical Authority.

6. Review and Acceptance

6.1 Software Deliverables

Final acceptance of the software Solution will occur when all discrepancies, errors or other deficiencies identified in writing by the Technical Authority have been resolved, either through documentation updates, program correction or other methods approved by the Technical Authority.

6.2 Reports and Documentation Deliverables

Reports and documentation deliverables will be accepted when all discrepancies, errors or other deficiencies identified in writing by the Technical Authority have been corrected.

The Contractor must provide drafts all Reports and Documentation deliverables to the Technical Authority for review 10 business days prior to the specified due date. The Technical Authority will provide comments to the Contractor 5 business days prior to the due date.

All of the Technical Authority's comments to deliverables must either be incorporated in the succeeding version of the deliverable or the Contractor must demonstrate to the Technical Authority’s satisfaction why such comments should not be incorporated.

If the Contractor requires additional guidance to produce an acceptable deliverable, the Contractor must arrange a meeting with the Technical Authority.

Current Infrastructure

The Open by Default pilot is built on an infrastructure as described by the diagram below.

Image missing

Footer

Accessibility Procurement Pilot Attachment 3 Public Services and Procurement Canada LOI # 24062-180181/