opencontent/openpa-ls

OpenContent OpenPA

安装次数: 5,916

依赖项: 9

建议者: 0

安全性: 0

星标: 3

关注者: 3

分支: 3

开放问题: 0

类型:ezpublish-legacy-extension

3.20.0 2024-09-24 09:21 UTC

This package is auto-updated.

Last update: 2024-09-25 08:04:54 UTC


README

pullreminders

用于机构沟通和开放政府的平台

OpenPA平台提供一系列工具,从机构官方网站开始,旨在帮助公共行政部门应对开放政府带来的挑战。

更多信息,请参阅:https://www.opencontent.it/Per-la-PA

文档

OpenPA的文档正在Readthedocs上发布。

您是一位程序员并需要帮助吗?

  • 要报告故障,请使用此存储库的GitHub问题功能。
  • 要请求开发人员帮助,请发邮件至 info@opencontent.it

许可权所有者

Opencontent SCARL Via Galilei Galilei 24 - Trento (意大利) 税务登记号和增值税号:02190640223 https://www.opencontent.it/

技术负责人

Opencontent SCARL https://www.opencontent.it/ Opencontent负责OpenPA的设计、实施和技术维护。

许可和用法

OpenPA以开放许可方式发布,采用GNU通用公共许可证v2.0,您可以在此处完整阅读:https://gnu.ac.cn/licenses/gpl-2.0.txt

感谢这个许可,任何用户都享有四个基本自由

  • 以任何目的执行程序的自由(自由0)。
  • 研究程序如何工作并修改它以适应自己需求的权利(自由1)。访问源代码是先决条件。
  • 重新分发副本以帮助他人的自由(自由2)。
  • 改进程序并将您所做的改进公开分发的自由(自由3)。这通常涉及您修改的版本),以便整个社区都能从中受益。访问源代码是先决条件。

道德规范

OpenPA是一个开源应用程序。源代码以GNU通用公共许可证v2.0发布,主要有两个原因

  • Opencontent的业务模式及其企业道德规范,它将知识共享视为不断提高质量和竞争力的决定性因素
  • 保护用户,尤其是公共机构,使其更容易遵守第68条(如下所示)和公共行政部门信息技术的三年计划(特别是第4、7和13章)。

主要参照法规

数字行政法典 - 第68条。比较分析解决方案

生效

  1. 公共行政部门在尊重经济性和效率、投资保护、重用和技术中立原则的情况下,在以下市场上可用的解决方案之间进行技术和经济比较后,获得软件或其部分:a)为公共行政部门开发的软件;b)为公共行政部门重新使用或其部分开发的软件;c)自由软件或开源软件;d)云计算模式可用的软件;e)通过使用许可获得的专有软件;f)上述解决方案的组合。

1-bis) 为此目的,在根据2016年第50号立法条例中的规定程序进行采购之前,公共机构根据以下标准对可用的不同解决方案进行比较评估:a) 程序或解决方案的整体成本,即<强>购买、实施、维护和支持成本;b) 对开放数据格式和接口的利用率以及能够确保公共信息系统之间<强>应用互操作性和协作的标准;c) 供应商在<强>安全级别、符合个人数据保护法规、服务级别方面的保证,考虑到所获得的软件类型。

1-ter) 如果根据第1-bis款规定的标准进行的比较评估,合理地表明无法获得公共机构内部已可用的解决方案、免费软件或开源代码,以适应需要解决的问题,则允许通过使用许可证来获取 proprietary 软件程序。本款所述评估根据AgID规定的模式和标准进行。

三年行动计划:4. 无形基础设施

4.1. 公共机构数据

公共信息资产的增值是公共机构的一个战略目标。为了利用公共机构收集和管理的庞大数据资产的潜力,有必要在管理上进行范式转变,以克服“孤岛逻辑”,实现系统性的视野。数据应被视为公共财产,免费共享于公共机构之间以供机构目的使用,除非有文件记录和正当理由,否则可供民间社会使用。

为了实施这种范式,计划确定了三个领域

  • <强>国家级数据库,即可靠、类型和内容一致、对公共机构履行职能和进行分析有意义的数据库。它们构成了公共信息资产的基础,可供所有公共机构使用,便于数据交换,避免多次向公民或企业索取相同信息(一次原则);
  • <强>开放数据,即“开放数据”。它们涉及一个旨在使公共机构数据对任何人自由使用、可重用和可再分配的过程,无论目的如何,包括商业目的,只要不受特别限制(例如:国家机密、统计机密、由隐私保护专员规定的个人数据保护限制);
  • <强>受控词汇和数据模型,它们构成了以标准化和规范化的方式组织常见代码和命名法(受控词汇)以及在数据领域内全面和严格的概念化(本体或共享数据模型)的共同方式。

公共资产增值需要精心管理,制定标准化、生成、保存和再利用数据的过程。这种增强将带来更大行政效率、数据重用对公民的好处(从而避免再次向公共机构提供已知数据)以及分析可能性扩大,包括支持政策制定和社会现象理解和预测的发展。

三年行动计划:7. 生成和传播数字服务的工具

7.2. 战略目标

  • 促进<强>开源范式的普及,促进建立公共机构应用程序和软件组件的开发者社区。
  • 通过实施和推广开发套件、验证和测试环境、明确沟通每个项目的进展状态以及异常情况的报告和讨论,来激励对< strong>Piattaforme abilitanti(例如 SPID、PagoPA、ANPR)的采用。
  • 提供遵循的< strong>指南和有用的工具包,以开发具有适当设计、用户体验、安全性和可用性的应用程序和服务。
  • 鼓励基于使用< strong>basi di dati、API和公共部门提供的信息(例如查询公共数据库的应用程序)开发数字产品和服务。
  • 共享指示和软件组件,以降低新数字产品的实施成本,促进重用和互操作性。
  • 支持行政机构推广和传播实施三年计划所需的服务和工具。

三年计划:13.数字项目开发原则

本章包含了以下原则,这些原则被认为是实现计划中项目的基本要求。措施既有实际性质,用于项目管理,也有合同和行政性质,用于起草合同、定义目标和资源采购。

最后,为实施新的系统或现有系统的升级而准备数字项目需要

  • 一个清晰的设计,说明要实现什么(设计);
  • 一个如何构建的计划(实施);
  • 一个将系统推广给最终用户的策略(发布);
  • 一个维护系统更新、安全、有用以及确保系统在故障或灾难情况下的持续运行的计划(发展和维护)。

下文将更详细地描述这些点。

13.1.项目设计

设计阶段对于项目的成功至关重要。关于这一点,请参阅《公共部门网站设计指南》中的服务设计章节。特别是,在设计服务时,建议

  • < strong>始终涉及公民,从理解他们的需求(指南的第1项策略)。这意味着想象公民(或最终用户)将如何使用该系统,并确保所有功能都是围绕他们的需求设计的,使他们能够轻松快速地获得所需的东西——无需不必要的步骤,并提供易于理解的说明。
  • 研究以了解,记录以避免重复(指南的第3项策略)。有必要了解项目将运作的背景,定义目标,< strong>遵循标准,并研究国内外有效的替代方案,以及已成功实验并可以重用的工具和流程的可用性。项目发展的每个阶段都必须进行记录并以开放的方式提供,一方面为了保证其完整性和未来的可持续性,另一方面为了允许可能的合作,这可能为项目添加新的价值。
  • 应用“一次性”原则(指南的第6项策略)。< strong>避免让公民多次提供相同的信息。每个流程都必须被设计得尽可能简单和易于使用,当需要时替换旧程序。
  • 确定目标和指标。因此,需要确定要实现的目标,包括功能和流程,以及能够评估项目成功和满意度的指标。例如,在一个电子发票系统中,一个目标可能是“拥有一个不需要打印发票的流程”。当可能时,建议使用客观指标而不是通过调查或调查得到的数据。例如,将“传统方式打印的发票数量”视为系统不足的指标,或者将“电子发送的发票数量”视为成功的因素。
  • 从数据开始(指南第4条策略)。为了根据真实行为和数据进行决策,需要实现完全数字化的服务和流程,而不仅仅是将传统方式提供的服务简单地转移到线上。
  • 任命一个产品负责人,即一个——最好是政府内部且与将实施该产品的主体无关——能够代表设计的服务最终用户的期望和需求,并且对要数字化的流程和预期获得的结果有明确的专业知识的人。例如,在一个电子发票项目中,产品负责人将是一个非常了解发票流程的人,并能够通过提供有关如何发送和处理此类发票、这些发票必须包含的数据等的建议和指导来引导项目执行者。

13.2. 项目实施

[...]

从技术角度来看,还需要

  • 使数据开放共享流程和工具(指南第8条策略)。共享每个数据、每个流程、每个代码、每个想法、每个失败、每个信息对所有服务都是必要且至关重要的,以促进透明度和开发质量。应由公共行政部门实施的所有服务的代码和文档应采用适当的许可证以开放格式发布,以实现成本和时间节省;如果不可能,则应适当说明阻碍的原因。
  • 优先选择开源组件,即代码源代码可用,并在可能的情况下可自由修改和适应政府部门需求的软件组件,如CAD第68条所述。使用商业产品或源代码关闭的产品必须及时说明理由,并且仅在项目所需的成本和功能比开源替代方案更有利时才允许。
  • 根据经济性和效率选择硬件解决方案,特别是评估迁移到替代解决方案(退出锁定)的成本,并确保技术中立。
  • 使用政府云服务。除非有技术上的正当理由,否则软件和项目必须设计为在政府云上使用,如第3.1节“数据中心和云”所述。

最后,实现的软件必须

  • 结构化为微服务,即执行少量明确定义的功能(例如,验证税号、用户在数据库中的存在性)的组件,通过API进行控制,并易于重用,以便可以通过开发社区提供给其他政府部门(参见第7章“数字服务的生成和推广工具”)。
  • 公开API,即创建允许系统轻松和自动地相互通信和交互的接口。用户界面和产品的所有功能都必须通过使用这些API来构建(参见第5章“互操作性模型”)。
  • 使用符合第4.1段“政府数据”中规定的规则的数据库,尤其是将有关执行操作的性质及其随时间变化的信息插入到数据与分析框架(DAF)中。
  • 根据AgID制定的互操作性和合作规则维护数据、服务和流程的互操作性,同时保留确保用户隐私所需的标准。数据必须以开放数据的形式提供,并附有对字段及其含义的详尽描述(元数据)。
  • 使用可靠的测试和认证策略,即使用单元测试、功能测试和模糊测试来验证代码,并进行压力测试以验证产品能够承受的负载。此外,建议使用代码静态分析策略,并对结果进行审计以解决安全问题。
  • 使用最佳安全实践,例如加密密码和网络通信。
  • 包含所有必要的文档,即包含有关使用的数据结构(字段、表等)的文档、软件的功能和使用说明,以及有关产品功能、维护、更新和监控的文档。
  • 属于政府机关,即合同必须明确指出,从代码到文档,从域名到许可、第三方库或产品上注册的专利,所有权利均属于政府机关。这样,政府机关可以继续产品的演变,即使是通过与最初开发它的供应商不同的供应商。
  • 提供给其他政府机关使用,即注册在Consip的市场中,并在可能的情况下,免费提供完整的源代码和文档,带有开放许可,允许第三方使用、修改或演变。

当项目与第三方或现有系统软件的集成很重要时,建议

  • 提供测试工具和基础设施,即提供可以测试自己软件的环境、测试账户或模拟器,供第三方自由使用,以验证组件之间的集成。
  • 使用和记录协调软件更新的流程,该流程包括宣布即将发布新版本的机制(通讯、论坛等),在测试环境中发布,然后在测试环境中与系统和第三方软件用户进行功能验证之后,才在生产环境中发布。
  • 提供 库和开发工具包,即示例代码和软件组件,供第三方在其产品中使用,以与您的系统集成。这有助于重用,提高代码质量,降低维护和更新成本,显著降低不兼容和不符合规范的实现风险,并降低每个第三方的开发成本。

13.3. 项目启动

在确定将项目推向采用的过程时,政府机关必须

  • 确定最小抵抗的采用策略,即找到最简单、最快、影响最小的方式,以便产品可以开始采用,即使是有限的或不完整的采用。与其一步引入重大变化,不如采取小步骤、增量式前进,以实现最终目标——这本身更简单、风险更低。
  • 制定一种渐进式使用策略,即找到那些允许产品被逐步采用的方法,首先由一小部分用户开始,然后是更广泛的用户群体,最后是所有用户。重要的是要强调,面向所有用户的服务的推出并不导致开发活动的停止或产品的完成。相反,当可能时,建议制定策略,允许在产品完成之前使用产品,以便发现问题、重新组织优先级,并开始提供由创新带来的好处,尽管是部分产品。
  • 制定一个完整产品发布计划,即淘汰旧产品。对于大型项目,重要的是要强调,发布策略可能不仅需要产品的实现,还需要针对用户的推广活动、沟通机制(邮件列表、推特、制作展示网站)以及所有被认为对于产品采用重要的事项。
  • 有效沟通,通常是随时随地(指南第5条)。政府部门必须清楚地传达服务的有用性和先决条件,以及所有与个人数据保护、隐私保护和网络安全相关的信息,通过最常用和广泛的沟通渠道接触市民,并给他们提供访问、控制和更正自己数据的可能性,保持持续的对话,甚至在服务推出之后。

13.4. 项目演进和维护

在定义项目演进和维护策略时,建议政府部门

  • 确保定期维护和更新所有软件和系统,以预防安全问题,确保软件与新技术兼容,并符合法规的演进。
  • 确保一个持续演进的产品计划,即在产品推出后,建立或拥有一个改进产品、添加功能、解决问题以及更一般地实现更新的策略。
  • 确保一个灾难恢复和业务连续性策略,即确保在发生故障或灾难的情况下,关键数据不会丢失,并且能够在降级模式下继续提供服务。
  • 确保对运行参数进行持续验证,例如,监控软件(错误、请求、延迟)、定期审计以确保安全性等。
  • 准备所有必要的程序以避免锁定,保持从一家供应商切换到另一家的可能性。通常,使用不同的供应商进行产品的开发、维护和推出可以保证更好的迁移能力。