README

由市民参与的事件日历

OpenAgenda简化了当地文化生活主体的协作；协会、图书馆和博物馆将各自的活动收集到一个统一的日历中，便于多渠道传播，并与当地机构协调。这样，公共行政部门与过去相比提出了一个重大的范式转变：使公民在公共事件管理中具有自主权和责任感，同时保持对整个过程的协调和验证作用，以确保其正常运行。这是加强政府与领土之间关系的一种方式，符合OpenGovernment范式。

欲了解更多信息，请参阅：https://www.opencontent.it/Per-la-PA/OpenAgenda

文档

OpenAgenda的文档使用Readthedocs制作，并提供以下格式：

• 公共行政操作员手册：http://manuale-openagenda.readthedocs.io/it/latest/manuale_amministratori.html
• 协会手册：http://manuale-openagenda.readthedocs.io/it/latest/manuale_associazioni.html

您是程序员并且需要帮助吗？

• 要报告故障，请使用此存储库的GitHub Issues功能。
• 要请求开发者的帮助，请发送邮件至info@opencontent.it

许可证持有人

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

技术负责人

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

许可证和用法

OpenAgenda以开源许可证发布，GNU通用公共许可证v2.0，您可以在以下链接中完整阅读： https://gnu.ac.cn/licenses/gpl-2.0.txt

凭借这个许可证，OpenAgenda的任何用户都享有四个基本自由

• 自由0：执行程序以实现任何目的。
• 自由1：学习程序的工作方式并对其进行修改以满足您的需求。访问源代码是先决条件。
• 自由2：分发副本以帮助他人。
• 自由3：改进程序并向公众发布您所做的改进（以及您的修改版本），以便整个社区从中受益。访问源代码是先决条件。

道德规范

OpenAgenda是一个开源应用程序。源代码以GNU通用公共许可证v2.0发布，原因如下：

• Opencontent的业务模式和公司道德规范，将知识共享视为提高公司质量和竞争力的决定性因素。
• 保护用户，特别是公共机构，使他们更容易遵守第68条（以下列出）和公共行政信息三年计划的条款。

主要参考规范

数字管理法 - 第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节“公共机构数据”中所述规则的数据库，并在Data & Analytics Framework (DAF)中插入有关操作性质及其随时间变化的信息。
• 根据AgID制定的互操作性和合作规则维护数据、服务和过程的互操作性，同时保留保证用户隐私所需的标准。数据必须以开放数据的形式提供，并附带对字段及其意义的详尽描述（元数据）。
• 使用稳健的测试和认证策略，即使用单元测试、功能测试和模糊测试来验证代码，并执行压力测试来验证产品将能够承受的负载。还建议使用代码静态分析策略，并对结果进行审计，以解决安全问题。
• 使用最佳安全实践，例如，加密密码和网络通信。
• 包括所有必要的文档，即包括关于使用的数据结构（字段、表格等）的文档、软件的功能和用法，以及关于产品功能、维护、更新和监控的文档。
• 属于公共机构，即合同应明确规定从代码到文档、从域名到许可、第三方库或产品上注册的专利等所有产品权利都属于公共机构。这样，公共机构可以继续产品的演变，即使利用与最初开发它不同的供应商。
• 提供给其他公共机构，即注册在Consip的市场place中，并在可能的情况下，免费提供完整的源代码和文档，附带开放许可，允许第三方使用、修改或扩展。

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

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

13.3. 项目启动

在制定实施项目的路径时，政府机关必须

• 确定阻力最小的实施策略，也就是说，找到最简单、最快和影响最小的方式来使产品开始被采用，即使是有限的或不完整的。与其一次性引入大的变革，不如分小步骤逐步推进——每个步骤都更简单、风险更低——以实现最终目标。
• 确定一种渐进式使用策略，即找到那些允许产品被有限用户、然后是更广泛用户群，最后是所有用户采用产品的机制。重要的是要强调，针对所有用户的服务的推出并不一定意味着停止开发或完成产品。相反，在可能的情况下，建议采用在产品完成之前使用产品的策略，以便识别问题、重新组织优先级，并开始提供创新带来的好处，即使产品是不完整的。
• 确定一个全面推出产品的计划，即淘汰旧产品。对于大型项目，重要的是强调推出策略可能不仅需要产品的实现，还需要针对用户的推广活动、沟通机制（邮件列表、Twitter、制作展示网站）以及任何被认为对产品采用至关重要的因素。
• 有效沟通，经常在各个地方（指南第5条）。公共机构必须清楚地传达服务的效用和先决条件，以及所有与个人数据保护、隐私保护和网络安全相关的信息，通过最常用和最广泛的沟通渠道与公民接触，让他们有机会访问自己的数据，进行控制和更正，保持持续的对话，甚至在服务推出之后和之后。

13.4. 项目演进和维护

在定义项目演进和维护策略时，建议公共机构

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