The planned schedule is for the ICS-C (Integrated Core Services – Central Hub) to be operational from 1 October 2019. To enable this, the ICS-C Team has been working on developments in the metadata catalog, the GUI (Graphical User Interface) and associated software within the core of ICS-C.
In addition, the SCB (Service Coordination Board) Work Force have coordinated and initiated a series of ICS-TCS workshops. The first was in Bergen in February and the second in Amsterdam in April. An additional workshop will be organised in May in Rome, and a fourth is planned in September, again in Amsterdam. In between, a User Feedback Group (UFG) meeting organised in March laid the groundwork for User Feedback evaluation at the next UFG meeting in Amsterdam in June, and a final UFG meeting will likely take place in October.
These workshops provide an opportunity for the TCS (Thematic Core Services) members and the ICS team to work together to identify areas where the current prototype ICS-C (together with the metadata in the catalog provided by the TCSs) does not meet the requirements or could otherwise be improved.
One key aspect of the move to operational status is the provisioning of the computing system to host the operational ICS-C. This is being done jointly by staff at BRGM and BGS, with provision of support to users from GEUS.
The other major aspect of the move to operations is the establishment of a QA (Quality Assurance) process to ensure that developed software is of appropriate quality to be used in operational mode. This is described below. The process to ensure the metadata supplied by the TCSs to describe their assets in the ICS-C catalog is of sufficient quality is bound up with the validation process described elsewhere in PDB papers.
EPOS Quality Assurance (QA) Process
The EPOS Quality Assurance (QA) process represents the means of monitoring the processes and methods used to ensure the quality. In the context of EPOS, the term quality is not just applied to software, but includes software, metadata, procedures etc., and it also includes a strong governance component in the management of the processes.
- Functional quality (satisfies functional requirements).
- Structural quality (satisfies non-functional requirements).
The envisaged process aims to assess both forms of ‘quality’ through automated testing and review.
The diagram in the alongside Figure 1 describes the main steps of the QA process as applied to software development; and is to be applied to any artefact delivered as part of the ICS-C (software modules, plugins, metadata, web-services etc.). It has two distinct sub-process, the first being the QA process under which software is developed, and the second being how the hosting team takes ownership, tests and deploys the final product.
- Development teams work with stakeholders to understand requirements.
- Development teams write code and use version control software to manage code.
- During development, teams create and run automated tests (unit, integration, end-to-end).
- Development teams routinely peer review code and deliverables.
- Operations team review deliverables, deploying artefacts to a staging environment.
- Automated testing is run in the staging environment.
- Stakeholders review the staging environment.
- On successful testing & review of the staging environment can be deployed and monitored in production.