opencontent/openpa_dimmi-ls

OpenContent OpenPA Dimmi

安装次数: 1,924

依赖关系: 0

建议者: 0

安全性: 0

星标: 1

关注者: 4

分支: 1

开放问题: 0

语言:Smarty

类型:ezpublish-legacy-extension

1.3.1 2019-04-12 12:11 UTC

This package is auto-updated.

Last update: 2024-09-13 00:32:35 UTC


README

该组件旨在协助行政和公民在公共咨询中进行交流:从识别感兴趣的主题,到收集想法和反馈,直至展示获得的结果。

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

文档

OpenConsultazioni的文档是通过Readthedocs制作的:https://manuale-openconsultazioni.readthedocs.io/

如果您是程序员并需要帮助?

  • 要报告故障,请使用此存储库的GitHub Issues功能
  • 如果您需要开发者的帮助,请发邮件至 info@opencontent.it

许可权所有者

Opencontent SCARL Via Galilei Galilei 24 - Trento (Italy) 税号和增值税号:02190640223 https://www.opencontent.it/

技术负责人

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

许可证和用法

OpenConsultazioni是以开源许可证发布的,GNU通用公共许可证v2.0,您可以在此处完整阅读: https://gnu.ac.cn/licenses/gpl-2.0.txt

由于这个许可证,任何OpenConsultazioni的用户都享有四个基本自由

  • 自由0:执行程序以满足任何目的
  • 自由1:研究程序并按需修改以适应自己的需求。访问源代码是前提条件。
  • 自由2:以帮助他人为目的复制副本。
  • 自由3:改进程序并将其公开发布所做改进(通常为修改后的版本),以便整个社区从中受益。访问源代码是前提条件。

道德准则

OpenConsultazioni是一个开源应用程序。源代码以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款中规定的标准进行的技术和经济比较评估表明,存在合理理由无法获取满足需求已存在于政府部门内部或自由软件或开源代码的解决方案,则允许通过使用许可获取授权的专有软件。本条款所指的评估按照AgID规定的模式和标准进行。

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

4.1. 政府数据

公共部门信息资产的价值实现是公共部门的一个战略目标。为了利用公共部门收集和管理的庞大数据资产潜力,需要改变数据管理方式,以实现超越“孤岛逻辑”的系统观。数据应被视为公共财产,免费共享于公共部门之间,用于机构目的,除非有文件证明和正当理由,否则不得由民间社会使用。

为实现这一范式,计划确定了三个领域

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

公共资产的价值化需要精心策划,以设计数据标准化、生成、保存和再利用的过程。这种增强将在提高行政效率、为公民(从而避免再次向公共行政部门提供已有数据)提供数据再利用以及扩大分析可能性方面带来好处,包括理解和支持政策制定和社会现象预测,以及为公民服务的发展。

三年行动计划:7. 生成和推广数字服务工具

7.2. 战略目标

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

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

本章包含以下原则,这些原则被认为是实现计划中项目的基本要求。这些注意事项包括实践性质(项目管理)和合同性质及行政性质(撰写合同、定义目标和资源采购)。

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

  • 明确的设计目标(设计);
  • 构建计划(实施);
  • 将产品带给最终用户的策略(发布);
  • 维护系统保持更新、安全、有用,并确保系统在故障或灾难发生时也能持续运行(发展和维护)的计划。

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

13.1. 项目设计

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

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

13.2. 项目实施

[...]

从技术角度来看,还需要

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

最后,实现的软件必须

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

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

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

13.3. 项目启动

在制定项目采用路径时,公共行政部门必须

  • 确定最小抵抗的采用策略,即找到最简单、最快且影响最小的途径,以便产品开始采用,即使是以有限或不完整的形式。与其一次性引入重大变革,不如分步骤小步前进,每一步都更简单、风险更低,最终达到最终目标。
  • 确定一个逐步采用策略,即找到那些允许产品先由少量用户采用,然后是更多用户,最后是所有用户采用的机制。重要的是要强调,为所有用户推出服务并不决定停止开发或完成产品。相反,在可能的情况下,建议采取策略,允许在产品完成之前使用产品,以便识别问题、重新安排优先级,并开始提供创新的收益,即使是一个部分产品。
  • 确定一个全面推出产品的计划,即淘汰旧产品。对于大型项目,重要的是强调,推出策略不仅需要产品的实现,还需要针对用户的推广活动、沟通机制(邮件列表、推特、建立展示网站)以及为推动产品采用所认为重要的所有内容。
  • 有效沟通,通常是随时随地(指南的第5条策略)。公共行政部门必须以清晰的方式传达服务的效用和先决条件,以及所有与个人数据保护、隐私保护和网络安全相关的信息,通过最常用和最广泛传播的沟通渠道接触公民,让他们有机会访问自己的数据、控制它们并纠正它们,保持持续的对话,甚至在服务推出之后和之后。

13.4. 项目的演变和维护

在制定项目演变和维护策略时,建议公共行政部门

  • 确保所有软件和系统的定期维护和更新,以预防安全问题,确保软件与新技术兼容并符合法规的演变。
  • 确保一个持续的产品演变计划,即确定或制定一个策略,在产品推出后改进产品,添加功能,纠正问题,以及更普遍地允许其更新。
  • 确保一个灾难恢复和业务连续性策略,即确保在故障或灾难的情况下,关键数据不会丢失,并且可以继续提供服务,尽管是在减小的模式下。
  • 确保持续的功能参数检查,例如,软件监控(错误、请求、延迟)、定期审计以确保其安全性等。
  • 制定所有必要的程序以避免锁定,保持从一家供应商转向另一家供应商的可能性。通常使用多个供应商来实现、维护和推出产品,这保证了更好的迁移能力到另一家供应商。