opencontent / openpa_sensor-ls
OpenContent OpenPA Sensor
Requires
- dev-master
- 7.1.3
- 7.1.2
- 7.1.1
- 7.1.0
- 7.0.0
- 6.1.0
- 6.0.1
- 6.0.0
- 4.6.0
- 4.5.2
- 4.5.1
- 4.5.0
- 4.4.0
- 4.3.0
- 4.2.5
- 4.2.4
- 4.2.3
- 4.2.2
- 4.2.1
- 4.2.0
- 4.1.6
- 4.1.5
- 4.1.4
- 4.1.3
- 4.1.2
- 4.1.1
- 4.1.0
- 4.0.3
- 4.0.2
- 4.0.1
- 4.0.0
- 1.7
- 1.6
- 1.5.2
- 1.5.1
- 1.5
- 1.4.2.1
- 1.4.2
- 1.4.1
- 1.4
- 1.3.1
- 1.3
- 1.2.7.2
- 1.2.7.1
- 1.2.7
- 1.2.6
- 1.2.5
- 1.2.4
- 1.2.3.2
- 1.2.3.1
- 1.2.3
- 1.2.2
- 1.2.1
- 1.2
- 1.1
- 1.0
- dev-proponici
- dev-fix-perfomance
- dev-refactor-refresh
- dev-i18n
- dev-openapi
- dev-development
- dev-trieste
- dev-webhook
- dev-features/post_form
- dev-fork-iter
This package is auto-updated.
Last update: 2024-09-20 17:06:37 UTC
README
OpenSegnalazioni 促进与市民的对话:收集与管辖地区相关的建议、观察和举报;允许市民实时跟踪程序;支持机构内部程序管理,以解决收到的举报。更多信息,请参阅:https://www.opencontent.it/Per-la-PA/OpenSegnalazioni
文档
OpenSegnalazioni 的文档是由 Readthedocs 创建的: https://manuale-opensegnalazioni.readthedocs.io
您是一位程序员并且需要帮助吗?
- 为了报告故障,请使用此存储库的 GitHub Issues 功能
- 如果您需要开发人员支持,请发送邮件至 info@opencontent.it
许可证持有人
Opencontent SCARL Via Galilei Galilei 24 - Trento (意大利) 税务识别号和增值税号:02190640223 https://www.opencontent.it/
技术负责人
Opencontent SCARL https://www.opencontent.it/ Opencontent 负责了 OpenSegnalazioni 的设计、实现和技术维护
许可证和使用方式
OpenSegnalazioni 以开放许可证发布,GNU 通用公共许可证 v2.0,您可以在以下链接中阅读完整内容:https://gnu.ac.cn/licenses/gpl-2.0.txt
感谢这个许可证,OpenSegnalazioni 的任何用户都享有四个基本自由
- 自由 0:按照您想要的任何方式执行程序,用于任何目的。
- 自由 1:学习程序如何工作,并修改它以适应您的需求。访问源代码是前提条件。
- 自由 2:分发副本以帮助他人。
- 自由 3:改进程序并向公众发布您做出的改进(以及您的修改版本),以便整个社区从中受益。访问源代码是前提条件。
道德代码
OpenSegnalazioni 是一个开源应用程序。源代码以 GNU 通用公共许可证 v2.0 发布,原因如下:
- Opencontent 的商业模式和其企业道德规范,该规范将知识共享视为不断提高企业质量和竞争力的决定性因素。
- 保护用户,特别是公共机构,使其更容易遵守第 68 条(以下列出)和公共行政信息化三年计划(特别是以下章节 4、7 和 13)的规定。
主要参考法规
数字行政法典 - 第 68 条。解决方案比较分析
生效
- 政府部门在尊重经济性和效率、投资保护、重用和科技中立原则的基础上,通过比较以下市场上可用的解决方案的技术和经济评估,获取计算机程序或其部分: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. 项目设计
设计阶段对项目成功至关重要。关于此,请参考《公共行政部门网络服务设计指南》中的服务设计章节。特别是在设计服务时,建议
- 始终涉及公民,从理解他们的需求开始(指南的第一号战略)。这意味着想象公民(或最终用户)将如何使用该系统,并确保所有功能都围绕其需求进行设计,使其能够轻松快速地获得所需内容——没有不必要的步骤,且对所有人均易于理解。
- 学习以理解,记录以避免重复(指南第3条策略)。有必要了解项目将运作的背景,确定目标,遵守标准,并对可能的国家和国际层面的有效替代方案进行调研,以及对已成功实验并可重用的工具和流程的可用性进行研究。项目的每个发展阶段都必须进行记录并开放提供,一方面以确保未来的完整性和可持续性,另一方面以允许可能的合作,从而可能增加新价值。
- 应用“一次原则”(指南第6条策略)。避免让公民多次提供相同信息。每个流程都必须尽可能简单易用,在必要时替换旧程序。
- 确定目标和指标。因此,需要确定要实现的目标,包括功能和流程,以及能够评估项目成功和满意度的指标。例如,在一个电子发票系统中,一个目标可能是“有一个不需要打印发票的流程”。当可能时,建议使用客观指标而不是来自调查或测量的数据。例如,将“传统打印的发票数量”视为系统不足的指标,或将“电子发送的发票数量”视为成功的因素。
- 从数据开始(指南第4条策略)。为了基于真实行为和数据做出决策,需要实现完全数字化的服务和流程,而不仅仅是将传统提供的方式在线化。
- 指定产品负责人,即一个最好是来自公共部门且不与实施产品的主体相关的人,了解设计服务的最终用户的期望和需求,并清楚了解要数字化的流程和想要获得的结果。例如,在一个电子发票项目中,产品负责人将是熟悉发票流程的人,能够通过提供关于如何发送和处理此类发票的建议和指示来指导项目执行者,包括这些发票应包含的数据等。
13.2. 项目实施
[...]
从技术角度来看,还需要
- 公开数据,共享流程和工具(指南第8条策略)。共享每个数据、每个流程、每个代码、每个想法、每个失败、每个信息对所有服务都是必要且至关重要的,以促进透明度和质量的发展。公共部门实现的每个服务的代码和文档应以适当的许可证以开放格式发布,以允许成本和时间节省;如果不可能,将适当说明障碍。
- 优先考虑自由或开源组件,即源代码可用的软件组件,如果可能,可以自由修改和适应公共部门的需求,如CAD第68条所述。商业产品或源代码封闭的产品必须逐一证明其合理性,并且只有在项目所需的成本和功能比开源替代方案更有利时才允许使用。
- 根据经济性和效率选择硬件解决方案,特别是评估迁移到替代方案的成本(退出锁定)并保证技术中立性。
- 使用公共部门云服务。除非有技术上的合理理由,否则软件和项目必须设计为在公共部门云上使用,如第3.1段“数据中心和云”所述。
最后,实现的软件必须
- 采用微服务架构,即由执行少数明确功能(例如,验证身份证号码,用户在数据库中的存在性)的组件组成,通过API进行控制和易于重用,以便通过开发社区提供给其他公共机构(参见第7章“生成和推广数字服务的工具”)。
- 公开API,即实现允许系统轻松、自动通信和交互的接口。用户界面和产品的所有功能都必须通过使用这些API来构建(参见第5章“互操作性模型”)。
- 使用根据第4.1节“公共机构数据”中所述规则设计的数据库,特别是将有关所执行操作的性质及其随时间变化的信息插入到数据与分析框架(DAF)中。
- 根据AgID规定的互操作性和合作规则,维护数据和服务的互操作性,同时确保用户隐私的必要标准。数据必须作为开放数据提供,并附有对字段及其含义的详尽描述(元数据)。
- 使用强大的测试和认证策略,即使用单元测试、功能测试和模糊测试来验证代码,并执行压力测试来验证产品将能够承受的负载。此外,建议使用代码静态分析策略,并对结果进行审计,以解决与安全相关的问题。
- 使用最佳安全实践,例如加密密码和网络通信。
- 包含所有必要的文档,即包含关于所使用数据结构(字段、表等)的文档,软件的功能和用法,以及关于产品功能、维护、更新和监控的文档。
- 属于公共机构,即合同应明确说明从代码到文档,从域名到许可证,第三方库或产品上注册的专利等所有权利均属于公共机构。这样,公共机构可以继续产品的演进,即使利用与最初开发它的供应商不同的供应商。
- 提供给其他公共机构使用,即注册在Consip的市场place上,并在可能的情况下,自由地提供完整源代码和文档,并附带开放许可,允许第三方使用、修改或演进。
当项目与第三方或现有系统集成的整合很重要时,建议
- 提供测试工具和基础设施,即在提供环境中测试自己的软件,测试账户或模拟器,供第三方自由使用,以验证组件之间的整合。
- 使用和记录用于协调软件更新的流程,这些流程应包括宣布即将发布新版本的机制(新闻通讯、论坛等),在测试环境中发布,然后在测试环境中与系统用户和第三方软件进行功能性验证后,再在生产环境中发布。
- 提供库和开发工具包,即准备好的代码和软件组件示例,供第三方在其产品中使用,以与您的系统集成。这有助于重用,提高了代码质量,降低了维护和更新成本,显著降低了兼容性和不符合规范的实施风险,并降低了每个第三方的开发成本。
13.3. 项目启动
在制定采用项目路径时,公共机构必须
- 确定低阻力 adoption 策略,即找到最简单、最快、影响最小的方法,以便产品可以开始采用,即使是有限的或不完整的。与其一次性引入重大变革,不如逐步推进,每一步都更加简单和风险较低,以实现最终目标。
- 确定一个 增量使用 策略,即找到那些允许产品被有限用户、然后是更多用户、最终是所有用户采用的机制。重要的是要强调,面向所有用户的服务的推出并不一定意味着开发活动的停止或产品的完成。相反,如果可能,建议确定策略,在产品完成之前就使用产品,以便识别问题、重新组织优先级,并开始提供由创新带来的好处,即使是一个部分的产品。
- 确定一个 产品全面发布计划,即淘汰旧产品。对于大型项目,重要的是要强调,发布策略可能不仅需要产品的实现,还需要针对用户的推广活动、通信机制(邮件列表、Twitter、建立展示网站)以及所有被认为对于推动产品采用重要的事项。
- 有效沟通,通常是随处可见(指南第5条)。政府部门必须清楚地传达服务的效用和先决条件,以及所有与个人数据保护、隐私保护和网络安全相关的信息,通过最常用的传播渠道向公民传达,使他们能够访问自己的数据、控制和更正数据,保持持续的对话,即使在服务推出之后。
13.4. 项目演变和维护
在确定项目演变和维护策略时,建议政府部门
- 确保所有软件和系统的定期维护和更新,以预防安全问题,确保软件与新技术的兼容性以及与法规的合规性。
- 确保一个 产品持续演变计划,即在产品推出后,建立或有一个改进产品的策略,添加功能、纠正问题,以及更普遍地允许更新。
- 确保一个 灾难恢复和业务连续性策略,即在发生故障或灾难时,确保关键数据不会丢失,并且可以继续提供服务,即使是以降低的模式。
- 确保对运行参数进行 持续检查,例如,监控软件(错误、请求、延迟)、定期审计以确保其安全性等。
- 制定所有必要的 避免锁定 程序,保持从一家供应商切换到另一家供应商的可能性。使用不同的供应商来实施、维护和推出产品通常可以保证更好的迁移能力到其他供应商。