GSC Sentinel-2 PDGS OCD - Emits - ESA

GSC Sentinel-2 PDGS OCD
Issue 1 Revision 2 (draft) - 25.07.2010
GMES-GSEG-EOPG-TN-09-0008
page 317 of 350
2) When a problem is assessed a SPR (Software Problem Report) form will be filled and
inserted into the anomaly database.
3) The anomaly database will allow to perform at least the following activities:
○ Insert new anomaly
○ Update/modify an already existing anomaly
○ Anomaly classification (minor, major or blocking problems)
○ Anomaly status and plan (open, closed, to be closed at a certain date/release)
○ Anomaly versus test procedure traceability
4) The anomaly database will allow the RP operator to request reports on anomaly
statistics (e.g. list of all open anomalies, list and sorting for anomaly classification and
criticality, etc…).
5) The RP operator will be able to perform an analysis of all encountered problems and
provide:
○ Test procedures metrics: a table which shows a test session results
○ Anomaly metrics: the metrics relevant to the SPRs raised and opened during
test activities
○ Product metrics: PDGS subsystems product assurance reports
6.18.1.4 System-Level Testing
PDGS testing activities can involve the PDGS (and subsequently can be executed on the
Reference Platform intended as a “representative PDGS”) at different level:
○ PDGS System: set of integrated subsystems constituted to achieve a given objective
by performing a specified set of functions. In this sense the PDGS is the system.
○ PDGS Subsystems: a constituent part (of the PDGS system) with dedicated function(s)
and specific interfaces of a complex whole defined as system: in this sense the
Instrument Data Processing (IDP) or the On-line Quality Control (OLQC) represents an
example of PDGS Subsystems.
○ PDGS Facility: represents the combination of co-located subsystems required by a
functional organization to perform an operational task. Concepts like Station(s) and/or
Centre(s) - clearly devoted to exploit operational tasks - will be considered as physical
entities grouping one or more PDGS Subsystems.
PDGS system tests will systematically involve several PDGS functional sub-systems
integrated together with potentially additional simulated ones according to the test coverage
required.
A realistic assumption is that RP operator will receive a new release at subsystem level and
then will build a new PDGS Release at system level once verified on Reference Platform. The
overall operation sequence for this activity can thus be summarised as follows:
1) Select one or several documented IV&V system test procedures according to the
testing coverage required.
ESA UNCLASSIFIED – For Official Use
© ESA
The copyright of this document is the property of ESA. It is supplied in confidence and shall not be reproduced, copied or
communicated to any third party without written permission from ESA.