Terrascope
  • Overview
  • Get started
  • Introduction
    • Terrascope Introduction
    • The Copernicus Programme
    • Registration and authentication
  • Data
    • Sentinel Missions
    • Sentinel-1
    • Sentinel-2
    • Sentinel-3
    • Sentinel-5P
    • PROBA-V mission
    • PROBA-V
    • SPOT-VGT mission
    • SPOT-VGT
    • Additional Products
  • APIs
    • catalogue APIs
    • OpenSearch
    • TerraCatalogueClient
    • STAC
    • Product download
    • Streamlined Data Access APIs
    • openEO
    • Additional Web-services
    • CropSAR Service
    • Web Map Service (WMS)
    • Web Map Tile Service (WMTS)
    • Web Map Tile Service v2 (WMTS)
  • Tools
    • Terrascope GUI
    • Terrascope Viewer
    • openEO web editor
    • Virtual Environments
    • Virtual Machine
    • JupyterLab
    • Hadoop Cluster
    • EOplaza
    • Getting started
    • Manage your Organisation
    • Publish a Service
    • Execute a Service
    • Manage a Service
    • Reporting
  • Quotas and Limitations
  • Support
    • Contact
    • Terrascope Forum
    • Terrascope Sample Examples
  • FAQ
  1. EOplaza
  2. Manage a Service
  3. Service Maturity
  • Terrascope GUI
    • Terrascope Viewer
    • openEO web editor
  • Virtual Environments
    • Virtual Machine
      • Terrascope Policies
    • JupyterLab
    • Hadoop Cluster
      • Manage Spark Resources
      • Advanced Kerberos
      • Access Spark Logs
      • Use Docker on Hadoop
      • Manage permissions and ownership
  • EOplaza
    • Getting started
    • Manage your Organisation
    • Publish a Service
    • Execute a Service
    • Manage a Service
      • Service Maturity
      • Credit Strength
    • Reporting

On this page

  • Level 1: Prototype
  • Level 2: Incubating
  • Level 3: Verified or Validated
  • Level 4: Operational
  • Requesting a change of the maturity level
  1. EOplaza
  2. Manage a Service
  3. Service Maturity

Service Maturity

Every service in the EOplaza is assigned a maturity level that indicates its qualitative documentation and performance. Currently, five different maturity levels for each service are available. The prototype is the primary and default level, followed by incubating, verifying, validating, and operating as advanced services. These levels are determined solely based on software readiness and user documentation criteria. These criteria are generally designed to ensure that the service meets specific standards and provides customers with a certain level of quality.

Level 1: Prototype

By default, every published service has a prototype level. It is expected that users consider the following points when publishing a service:

  • The service is executable, and basic logging information is supported.

  • A possible reference or a general overview of what it tries to implement is provided as service metadata.

Note

If a service meets the criteria for a higher level, an upgrade can be requested at any time after its publication. However, it is important to note that every criterion must be satisfied before an upgrade can be approved.

Level 2: Incubating

In addition to the criteria for prototype level, a service needs to meet the following requirements to be an incubating service:

  • Service metadata should include an example along with the expected output format.

  • An approximate assumption on how much user credit is required to execute a service should be provided.

Note

Note that no added value is associated with services in a prototype or incubating levels. In other words, added value costs are included in services that are either verified, validated or operational.

Level 3: Verified or Validated

When a service is labelled as either verified or validated, it marks the same level of maturity. The naming difference is due to its irrelevance/relevance to software validation reports as a part of user documentation.

Level 3a: Verified

  • A comprehensive functional and integration test should be possible.

  • Advanced logging should be available.

  • Service metadata should include information on detailed descriptions of the services, their parameters and a link to a publication that supports the methodology adopted. An example of executing service expected outcome should be provided in a similar manner to that of incubating service.

  • Approximate cost estimation on a larger scale should be presented.

Note

Provide a report to the support team if any constraints/limitations with the services exist that should be considered.

Level 3b: Validated

  • All the criteria mentioned for the verified level apply to this level. The additional criterion is that the validation report should be provided either as a separate document to the support team or as a non-expiring link.
Note

If a service satisfies all the criteria mentioned under verified but does not provide a validation report despite being relevant, it is labelled as incubating.

Level 4: Operational

A highly improved service can only be marked with the highest level of maturity, i.e. operational when it fully satisfies the following criteria:

  • All the conditions to be either verified or validated should be satisfied.

  • The service has been shown to fit large-scale production and integration in an operating system.

  • Rules and constraints for estimating resource usage should be provided as a document to the support team.

  • The service lifecycle management policy should be available to end users.

  • An article summarising the process used for the service should be available on a peer-reviewed website/journal or a conference article.

Requesting a change of the maturity level

Based on the fulfilment of the above criteria, service providers can request an upgrade of the service by sending an email to the EOplaza team.

Back to top
Manage a Service
Credit Strength

Copyright 2018 - 2024 VITO NV All Rights reserved

 
  • Terms of Use

  • Privacy declaration

  • Cookie Policy

  • Contact