软件选择

要开发的软件解决方案需要几个商用现货（COTS）组件。在此早期阶段可以识别和选择一组基本组件，即 数据库管理系统 和A 地理空间数据服务器 . 这仍然是一个初步的和不完整的选择，因为功能需求没有得到充分的规定和批准。

该项目涉及欧盟成员国与欧盟机构（如欧盟统计局）之间的统计数据交换。这个 SDMX 适用时，将采用标准和内容指南。这个 Open Source Software for SDMX developed by EuroStat 将在需要和适用的情况下“默认”使用。因此，欧盟统计局的SDMX工具不包括在应用于COTS组件的选择过程中，除了可移植性约束（参见 约束条件 ）

此外，选择软件组合来支持项目的 项目管理基础设施 . 这些组件的功能需求是通用的，并且以开放技术开发而闻名（请参见 [HOSG09] 或 [Foge09]) 提出了一种综合解决方案。

以下开放技术开发的一般技术目标指导了选择过程：

目标

  1. 灵活性。

    可以以多种方式使用的组件往往具有更多的潜在用户，其中一些用户可能会帮助项目（例如，通过错误报告和开发时间）。

  2. 便携性。

    可以在更多平台上使用的组件往往具有更多的潜在用户。

  3. 模块性。

    模块化的组件（例如，具有明确定义的子组件，可能支持“插件”架构）更灵活，并且更容易检查正确性。

  4. 使用开放标准。

    尽可能避免依赖由单个供应商控制的接口。

  5. 重用并与现有的OTD（开放技术开发）项目协作。

    一个项目应该专注于构建新的软件，而不是重新实现已经存在的OTD项目。 [...]

  6. 避免非OTD依赖。

    只依赖广泛使用的OTD平台、库和开发工具。如果某个组件依赖于非OTD组件，而该组件随后需要更改，则可能难以进行更改或合并该更改。同样，可能很难获得对异常库和开发工具的支持。 [...] 如果必须依赖某个专有组件，则通过插件或由开放标准定义的接口将其隔离。 [...]

如果有替代方法，则应对替代方法进行简单分析，并在项目中进行讨论，以便不忽略关键问题或替代方法。

资料来源： [SWLH11]

过程

选择过程遵循通用地面军事系统过程：

一般COTS选择过程

  1. 根据利益相关者的要求和约束定义评估标准。

  2. 搜索COTS产品。

  3. 根据一组“必须具备”要求筛选搜索结果 ["apply constraints"] . 这将导致确定一个最有希望的COTS候选人的短名单，这些候选人将被更详细地评估。

  4. 在短名单上评估COTS候选人 ["apply factors"]

  5. 分析评估数据 [...] 并根据标准选择最适合的COTS产品。 [...]

在步骤5之后，所选的COTS产品通常根据需要进行定制（也就是说，定制），以减少其与需求的不匹配。COTS产品可以通过不同的方式进行定制，例如使用附加组件、调整参数等。

资料来源： [MoRE07]

对于每种类型的选定部件，所采用标准的基本原理和备选方案的简要分析在各自章节中给出。

候选组件集使用以下策略进行修剪和排序：

COTS产品评估策略

  1. 基石识别 首先确定一个关键需求（例如，供应商位置或技术类型），然后搜索满足该关键需求的产品。这允许快速消除大量不满足关键要求的产品。

  2. 渐进过滤 它从大量的COT开始，然后通过产品评估周期的连续迭代逐步定义识别标准，在每个周期中消除“不太适合”的产品。

    该策略要求在GCS过程中反复运行步骤1至4，直到确定少量最有希望的COTS产品，从中可以选择一个或多个产品以集成到系统中。

  3. 拼图拼图 它假定基于COTS的系统需要像拼图块一样将各种组件装配在一起。这意味着当与其他产品结合时，“适合”隔离的产品可能是不可接受的。因此，该策略建议考虑每个产品的需求，同时记住拼图中其他产品的需求。

资料来源： [MoRE07]

约束条件

主要制约因素

这个 基石识别 策略需要定义约束。约束作用是限制正在考虑的备选方案。 [East99]. 确定了三个主要约束：

执照类别

许可证兼容性是一项非功能性的项目要求：其目标是促进将要开发的解决方案以及可能包含的任何现有组件（如果需要）的共享、重用和未来改进。

遵循提前确定分配政策的原则 [TrCo10], 要开发的软件解决方案应在 OSI-approved Open Source licence ，即欧盟公共许可证v.1.1 [EUPLv1.1].

对于某些COTS组件，euplv1.1兼容性也是 拼图拼图 约束：euplv1.1是一个 copyleft licence 以及所有 Open Source Software for SDMX developed by EuroStat 根据EUPLv1.1许可证分发。

有两种选择：

  1. 仅评估OSI批准的开源许可证下的COTS软件 EUPL-compatible licence （直接或通过许可方建立的FOSS例外清单）。

  2. 评估开放源码许可证下的COTS软件，EUPLv1.1与之兼容（直接或通过EUPLv1.1例外列表）。

大多数许可证都允许与euplv1.1进行静态链接（通过编译组合组件，将它们复制到目标应用程序中，并生成一个独立可执行文件的合并对象文件），但gnu许可证（lgpl，gpl）通常不允许动态链接（在tim中使用组件）e应用程序被加载或执行）或合并源代码。由于大多数开源组件都是在copyleft GNU许可证下运行的，因此（也叫copyleft）euplv1.1包括一个例外列表或下游兼容性列表，允许eupled代码和：

  • 普通公共许可证（GPL）v.2

  • 开放式软件许可证（OSL）v.2.1、v.3.0

  • 公共许可证（CPL）v.1.0

  • Eclipse公共许可证（EPL）v.1.0

  • 塞西尔v.2.0

从COTS选择的目的来看，上述版权许可证被视为与EUPL兼容（实际上，与它们兼容的是EUPLv1.1许可证）。

在项目结束时，必须根据组件类型及其在系统中的使用情况，确认用于分发目的的最终许可证。

便携性

跨平台兼容性是一个非功能性的项目需求：同样，目标是促进不同组织采用不同的IT基础架构。可移植性要求也是一种良好的ICT采购实践，可降低 vendor lock-in 并促进不同系统对组件的重用。

只有在通用专有和开源操作系统上可用和支持的COTS组件才被考虑在内。平台的选择程序在 操作系统 部分。

购置成本

仅包括零许可证获取成本的软件：项目预算考虑基础设施成本（即应用程序托管）和软件开发/定制，但不考虑许可证获取/维护成本。

由于这些约束的应用，候选集严格基于FOSS（自由和开源软件），同时确保与主要的专有和开源操作系统的兼容性。

成熟度和可持续性

在实践中，采购成本约束不会影响备选方案集，因为足够的组件要么是免费提供的，要么是免费的“社区版”，以及提供付费支持服务的“企业版”。

间接地，这种情况源于与每个FOSS组件的成熟度和可持续性相关的第二组约束的应用。结合了两种评价模型：

  • 软件可持续性成熟度模型（SSMM） [Gard13]

  • 开源成熟度标准的确定和选择 [Atos13]

基本上：

  • SSMM水平低于4的COTS组件不被认为是可接受的；

  • 并将以下QSO成熟度标准分数设置为约束条件：

QSOS maturity criteria and minimum scores selected as constraints

遗产：项目的历史和遗产

  • 年龄：0:三个月以内

  • 人气：0:很少有确定的用户

活动：项目内部和周围的活动

  • 贡献社区：0:没有真正的社区或活动（论坛、邮件列表…）

  • 关于bug的活动：0：论坛和邮件列表的反应性低，或者在发行说明中没有提到bug修复

  • 功能活动：0:很少或没有新功能

  • 发布/版本活动：0：生产或开发版本（alpha、beta）的活动非常少

工业化：项目工业化

  • 服务：现有服务产品（支持、培训、审计…）=0：未识别服务产品

  • 文档：1：文档存在，但部分过时或仅限于一种语言或很少的细节

  • 源代码修改：0：不方便提出源代码修改

发布/版本活动根据每个项目的网站进行评估：只考虑正在进行开发的项目（在过去12个月内至少有一个次要的稳定版本），只考虑具有稳定版本的项目。

对bug和特性的活动进行直接评估（通过项目的版本发布说明、bug追踪器或源代码伪造统计）或间接评估，通过FOSS统计收集站点（主要是 ohloh) .

对最终用户和开发人员社区的贡献社区活动进行评估。直接（通过项目的论坛、邮件列表等）评估最终用户活动，间接地通过基于社区的问答网站（主要是 stackoverflow 以及兄弟网站）。开发人员活动也通过源代码伪造统计信息（贡献开发人员的数量、提交的数量）进行评估。

文件直接在项目的网站上进行评估。仅考虑具有公共可用文档的项目。用户文档必须至少包括硬件和软件要求、安装程序以及软件配置和操作。开发人员文档必须至少包含源代码文档。此约束也是允许 渐进过滤 以及候选集的功能评估。

开放标准

在实现开放标准的基础上选择COTS是一项基本的技术互操作性要求。

葡萄牙最新的数字互操作性国家法规中列出的开放标准 [RNID12] 如果欧盟法规未规定更严格的要求，则在适用情况下采用（见 [INSPIRE]) 或项目功能需求所需。

重要要求：

如果塞浦路斯、保加利亚或其他感兴趣的MS对开放标准有更严格的要求，请向我们发送适用的文件。

在葡萄牙，遵守葡萄牙国家数字互操作性法规中列出的开放标准也是公共行政系统开发和ICT采购的法律要求。

在实践中，开放标准约束不会（显著）影响备选方案集，因为FOSS组件通常实现相关的开放标准。然而，对适用开放标准的支持程度是排序和选择备选方案的一个因素。

待处理

RNID开放标准

包括RNID开放标准列表及其作为每种组件类型选择标准的应用。

因素

一个因素是一个标准，它增强或削弱了某一特定替代方案对所考虑活动的适用性。 [East99]. 功能需求随组件类型的不同而变化：所采用标准的基本原理和备选方案的简要分析在各节中给出。

功能标准优先于非功能标准。然而，给定COTS组件的成熟度和可持续性得分与其功能性、灵活性、模块性和集成能力之间存在明显的相关性。

此外，与FOSS项目的成熟度和可持续性相关的非功能性标准（基于SSMM和QSOS模型）可在功能性标准应用中没有出现“最佳”选择时应用。

以下九个标准通常用于FOSS评估。 [Berg05]: 许可证类型、文档、发布活动、寿命、社区、支持、安全、集成和功能。以下简要说明了这些标准在选择过程中的应用：

  • 许可证

    许可证类型是限制备选方案集的约束条件之一。

    与euplv1.1的许可证兼容性定义为允许通过合并源代码、静态链接或动态链接来分发euplv1.1下的较大工作。因此，可以将许可证类型用作排序备选方案的一个因素，方法是优先选择允许代码合并的许可证，而不是只允许静态链接的许可证，后者则优于只允许动态链接的许可证。 其他部分 ，这个因素可以允许在并列的排序选项之间做出决定。

  • 文档

    文档可用性是一个限制。文档质量是决定类似备选方案（例如在线教程和其他培训材料的可用性，或是否存在清晰的 coding style guidelines 对于开发人员而言），因为它明显促进了软件的使用和采用。

  • 释放活动

    当应用释放活动来排除不活动的项目或不成熟的项目时，释放活动是一个约束。发布活动也是评估类似替代方案成熟度的一个因素：计划的发布时间表和公共特性路线图是有价值的（这是保持这种妥协的证据）。

  • 寿命

    项目寿命是每个项目的稳定性和生存机会的间接指标。此标准仅与发布活动和社区活动一起进行（定性）评估。

  • 社区

    项目内部和周围的活动根据可视性（即项目网站、二进制文件和源代码、文档、讨论列表或论坛等的易访问性）和开发人员社区的活动（使用可在 ohloh, 如投稿人数量、提交次数等）和用户社区参与度，使用间接指标，如 Google scholar （学术团体采用），记录的相对搜索次数 Google trends （最终用户兴趣）和记录在 StackOverflow 地点。

  • 支持

    • 活动的用户和开发人员列表。

    • 活动的公共Bug跟踪器。

    • 提供付费支持选项。

    • 可用的SaaS提供商

  • 安全性

    • 安全备份的证据。

    • 企业（即长期支持）版本的存在。

    • 公共bug追踪器中的bug严重性分类证据。

  • 整合

    • 模块性

    • 开放标准

    • 与其他产品的协作（例如，标准库的重用）。

    • 明确识别软件需求（依赖项），这些需求也必须符合评估标准。

  • 功能

    功能子标准取决于要评估的组件。功能要求将在每个特定章节中列出。

简单地说，英国使用的三个通用“无意义”标准 Open Source Software Options for Government 列表允许识别一组可管理的候选者（至少有5个COTS组件），以便对备选方案进行分析。

非正式成熟度和可部署性标准

  1. 规模：“如果某物每天工作、处理或被数百万次使用，也许航空公司会用它来处理全球的关键交易，那就是大规模的。这应该给你一些信心，让你相信它能达到这个规模。”

  2. 关键性：“如果我们能找到在关键功能中使用的软件的例子，比如医疗保健——当病人的健康依赖于它的时候——或者如果它被犯罪机构在现实世界中使用，或者在高安全环境中使用，那么我们可以说这个软件可以适合关键系统。”

  3. 长寿：“如果一个软件包已经成功运行了二十、三十年，那么它就可以被添加到列表中，因为它不是新的、未知的。如果运营多年，我们知道风险。”

资料来源： Tariq Rashid ，IT战略与改革，英国政府内阁办公室

总拥有成本

总拥有成本（TCO）的财务估计超出了软件评估和选择工作的范围。

由于项目的预算限制，许可证获取成本是一个二元约束，而不是一个因素；硬件和基础设施要求是相似的，不管具体的COTS组件是什么；运营成本，如支持和维护，对于研发来说不容易量化。具有可变数量和类型的潜在采用者的项目：然而，选择过程确实尝试通过应用成熟度和可部署性标准来最小化解决方案的TCO。

COTS的选择，无论是专有的还是FOSS，都是相似的，因为它必须涵盖项目的功能需求。但是，给定解决方案的总成本分布不同。

许可证获取成本应与所提供的功能成比例：因此，在非免费的COTS软件中，通常选择提供必要和充分功能的最便宜版本。（同样的原则适用于FOSS或专有解决方案中的商业服务，如技术支持和维护服务）。

考虑到软件许可证获取的预算上限始终存在，经济实惠的解决方案可能不是最具扩展性的解决方案（例如，支持特定项目时间范围之外的开发）。

在选择FOSS解决方案时，需要降低长期成本，如员工培训或技术迁移，这就证明了选择组件的合理性，即使在特定项目的特性或复杂性方面，组件看起来“过大”，也能提供更大的灵活性。

其他参考资料

关于开放标准的欧洲互操作性框架建议

建议22

在建立欧洲公共服务时，公共管理部门应倾向于开放规范，适当考虑功能需求、成熟度和市场支持的覆盖范围。

[...] 正式规范的开放程度是决定实现该规范的软件组件共享和重用可能性的一个重要因素。 [...] 如果充分运用开放性原则：

  • 所有利益相关者都有相同的可能性促进规范的制定，公共审查是决策过程的一部分；

  • 本说明书可供大家学习；

  • 与本规范相关的知识产权是根据FRAND条款授予的。 [公平合理、无歧视] 或者在免版税的基础上，以允许在专有和开源软件中实现的方式。

建议21.

公共管理部门应采用结构化、透明和客观的方法来评估和选择正式的规范。 [...]

定义

规范化规范：规范化规范要么是符合欧盟指令98/34的标准，要么是ICT行业论坛或协会制定的规范。

标准：根据欧洲法规（指令98/34/EC第1条第6款）的定义，标准是经认可的标准化机构批准用于重复或连续应用的技术规范，其符合性不是强制性的，并且是以下其中之一：

  • 国际标准：国际标准化组织采用并向公众提供的标准，

  • 欧洲标准：欧洲标准化机构采用并向公众提供的标准，

  • 国家标准：国家标准化机构采用并向公众提供的标准。

标准制定组织：一个特许组织，负责根据特定的、严格定义的要求、程序和规则制定标准和规范。标准制定机构包括：

  • 公认的标准化机构，如国际标准化委员会，如国际标准化组织（ISO），三个欧洲标准化组织：欧洲标准化委员会（CEN），欧洲电工标准化委员会（CENELEC）或欧洲电信标准协会（ETSI）；

  • 论坛和联盟标准化倡议，如结构化信息标准促进组织（OASIS）、万维网联盟（W3C）或互联网工程工作组（IETF）。

资料来源： [EIFv2.0]

QSO成熟度标准和违约分数

遗产：项目的历史和遗产

  • 年龄：0:三个月以下；1:三个月至三年之间；2:三年以上

  • 历史：0：软件存在许多问题，这些问题可能令人望而却步；1：无重大危机，或历史未解；2：过去在危机管理方面的良好经验

  • 核心团队：0：很少有确定的核心开发人员；1：很少有活跃的核心开发人员；2：重要且确定的核心开发团队

  • 人气：0:识别的用户非常少；1:可以检测到使用情况；2:许多已知用户和引用

活动：项目内部和周围的活动

  • 贡献社区：0:没有真正的社区或活动（论坛、邮件列表…）；1:有显著活动的社区；2:论坛中有活跃活动的强大社区，有许多贡献者和支持者

  • Bug活动：0：论坛和邮件列表反应性低，或发布说明中未提及Bug文件；1：现有活动，但没有明确定义的流程或解决时间长；2：基于角色和任务分配的强烈反应性

  • 功能活动：0：很少或没有新功能；1：产品的发展由专门的团队或用户领导，但没有明确规定的过程；2：功能请求过程是工业化的，有相关的路线图可用

  • 发布/版本活动：0：生产或开发版本（alpha，beta）的活动非常少；1：生产或开发版本（alpha，beta）的活动，具有频繁的次要纠正版本；2：具有频繁纠正版本和计划的主要版本的重要活动与路线图相关联的ONS

治理：项目战略

  • 版权所有人：{ 0：权利由少数个人或商业实体持有；1：权利由许多个人统一持有；2：权利由一个法律实体或一个社区信任的基础（EX:FSF，Apache，ObjutWeb）}持有。

  • 路线图：0:没有发布路线图；1:没有计划的路线图；2:有计划和延迟测量的版本化路线图

  • 项目管理：0：无明确明显的项目管理；1：由个人或单个商业实体管理的项目；2：核心团队独立性强，被认可实体拥有的权利

  • 分发模式：0：具有商业版本和功能受限的免费版本的双重分发；1：子部分仅在专有许可证（核心、插件等）下可用；2：完全开放和免费分发

工业化：项目工业化

  • 服务：现有的服务产品（支持、培训、审计等）0：未确定服务产品；1：有限的服务产品（地理上，单一语言，单一供应商或无担保）；2：多个供应商提供的丰富的服务生态系统，保证结果

  • 文档：0:无用户文档；1:文档存在，但部分已过时或仅限于一种语言或很少的细节；2:文档最新，已翻译并可能适用于多个目标读者（最终用户、系统管理员、经理…）

  • 质量保证过程：0：未确定质量保证过程；1：现有质量保证过程，但未正式化或装备；2：基于标准工具和方法的质量保证过程

  • 源代码修改：0：不方便提出源代码修改；1：提供访问和修改代码的工具（如SCM、Forge…）但核心团队并没有真正地利用它们来开发产品；2：贡献过程被很好地定义、暴露和尊重，它是基于明确定义的角色

资料来源： [Atos13]

工具书类

Berg05

Van den Berg，Karin（2005年）。正在查找打开的选项。一个开源软件评估模型，并以课程管理系统为例进行研究。荷兰蒂尔堡大学未发表的硕士论文。

EIFv2.0

欧洲泛欧电子政务服务互操作性框架，2.0版。网址：http://ec.europa.eu/isa/documents/isa_annex_ii_eif_en.pdf

East99(1,2)

Eastman，J.R.（1999年）。多标准评估和地理信息系统。地理信息系统。1:493-502。

HOSG09

Hauge，O.；Osterlie，T.；Sorensen，C.F.；Gerea，M.（2009年）。开源软件选择的实证研究初步结果。自由/libre/开源软件研发的新趋势，2009年。牙线'09.ICSE研讨会（第42-47页）。IEEE。网址：http://ieeexplore.ieee.org/xpls/abs_all.jsp？arnumber=5071359&tag=1

INSPIRE

2007年3月14日欧洲议会和理事会指令2007/2/EC建立欧洲共同体空间信息基础设施（inspire）。网址：http://eur-lex.europa.eu/lexuriserv/lexuriserv.do？uri=celex:32007L0002:en:否

MoRE07(1,2)

Mohamed，A.；Ruhe，G.；Eberlin，A.（2007年）。COTS选择：过去、现在和未来。2007年计算机系统工程。ECBS'07。第14届IEEE国际会议和研讨会（第103-114页）。IEEE。网址：http://ieeexplore.ieee.org/xpls/abs_all.jsp？阿诺数=4148924

RNID12

Interoperabilidade Digital URL规范：http://dre.pt/pdf1sdip/2012/11/21600/0646006465.pdf

SWLH11

Scott，J.；Wheeler，D.A.；Lucas，M.；Herz，J.C.（2011年）。开放技术开发（OTD）：军事软件的经验教训和最佳实践。由助理国防部长（网络与信息集成）（NII）/国防部首席信息官（CIO）和负责采办、技术和后勤的副国防部长（AT&L）赞助。1.0版。网址：http://dodcio.defense.gov/portals/0/documents/foss/otd-lessons-learned-military-signed.pdf

TrCo10

Trialile&Coppens（2010年）-JRC开源软件指南。欧盟委员会联合研究中心网址：https://joinup.ec.europa.eu/sites/default/files/oss-guidelines-v-digit-2.pdf

Atos13(1,2)

ATOS（2013）-开放源代码软件（QSO）的鉴定和选择。2.0版。2013年1月19日。附录A:QSO成熟度标准。网址：http://backend.qsos.org/download/qsos-2.0_en.pdf

Gard13

Gardler，Ross（2013）-软件可持续性成熟度模型（SSMM）。OSS手表。联合信息系统委员会。网址：http://www.oss-watch.ac.uk/resources/ssmm

Foge09

Fogel，Karl（2009）-开发开源软件：如何运行成功的免费软件项目。网址：http://producingoss.com/

EUPLv1.1

欧盟公共许可证网址：https://joinup.ec.europa.eu/software/page/eupl/licence-eupl