Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Please provide feedback under 2022-11-16 Review Session

Mission Contribution

The Sandbox contributes to the GovStack vision in providing a demonstration environment to learn and a technical environment to test “more effective and cost-efficient digital government services”.

In other words, the GovStack Sandbox…

  • makes the GovStack approach tangible. It is the key tool to raise awareness and educate people on the benefits of the GovStack approach.

  • is an isolated, safe environment (you can break everything, but it doesn't have a negative effect) simulating a small governmental e-service system (reference implementation).

  • is an architectural approach centered around APIs and microservices to help unlock monolithic legacy systems to increase the speed of IT project delivery, leading to more effective and cost efficient digital governments

  • encapsulates the business logic and data necessary to represent multiple GovStack capabilities such as APIs, building blocks, use cases and workflows.

High-Level Features

  • DevSecOps methodology and tooling to replicate the testing, configuration, deployment and operation of BB candidates

  • Generic architecture implementation of Information Mediator and Open Source Building Block candidates to build the functional foundation

  • Specific e-service use cases

    • as pre-determined test scenarios to validate the functioning of the BB architecture

    • as frontends to visually showcase citizen-journey (optional civil servant) and educate on functioning

    • with dummy data registries enabling the use cases

  • Software compliance testing harness

  • Training material and documentation

Users and User Stories

Personas sourced from:

PRIORITY

Persona: “Policy Decision Maker” (Government, non-technical)

  • HIGH I want to experience an end-to-end use case (e.g. from new-born child registration to healthcare provision) so that I can understand the complexity of the complete business logic and usage of BB throughout the whole process.

  • HIGH I want to be guided in and around the sandbox itself for demonstration purposes so that I can get the full technical and non-technical picture without specific domain knowledge.

  • HIGH I want to see the BB interaction while clicking through a use case so that I can understand the distributed BB approach and combination of BB.

  • HIGH I want to see the interaction between users (e.g. Citizen and civil servant) so that I can imagine the interaction between citizens of my country and my ministry employees.

  • HIGH I want to click through sector-diverse use cases with calling out used workflows (semi-generic) and used BB (generic) so that I can understand the conceptual abstraction layers of the SDG Digital Investment Framework.

  • MEDIUM I want to be informed about reuse of workflows among offered use cases in the sandbox so that I can understand dependencies between use cases.

  • MEDIUM I want to access resources that proof the usage of the GovStack Implementation Playbook when prototyping the shown use case/services by the GovStack team (e.g. documentation after each step) so that I see proof of the theoretical framework.

  • MEDIUM I want to experience BB-based use case without any access barrier (login, deployment time, different credentials for user groups e.g. switching between citizen and civil servant view) so that I do not lose attention and can access without tech experience.

  • MEDIUM I want to see the assumptions and framework conditions (e.g. organizational setup) the use cases/sandbox is based on so that I can compare it with the conditions in my country.

  • LOW I want to see that the system is restricted and designed for different user groups (citizen, admin, civil servant) so that I see security and user management/rights being addressed.

  • SELECTION PROCESS I want to click through use cases and used common workflows that are of high importance for my country so that I can convince my colleagues/superiors.

  • LOW I want to see what happens if a Government does not use the BB approach so that I can see benefits of the approach.

Persona: “Maintainer at Government” (Government, technical)

  • HIGH I want to deploy the sandbox with different BB candidates so that I can experience the interchangeability of software components.

  • HIGH As an IT expert in a Ghanian ministry/contracted IT consultant I want to be able to select for each BB 1 out of 3 Govstack-Compliant applications and deploy them with a particular use-case configuration so that I can understand Govstack interoperability concept and consider using the architecture and methodology in my own digital transformation. (Owner: Taylor Downs )

  • HIGH I want to test the performance and other metrics (e.g. latency, network speed, response time, compression, carbon footprint) so that I can evaluate the potential usage of the architecture.

  • HIGH I want to read an up-to-date documentation (technology stack, licenses, architecture diagram,…) so that I can inform myself about details of use software and architecture.

  • HIGH I want to experience accessibility and UX so that I can assess the usability for my target group.

  • MEDIUM I want to create self-hosted instance of the sandbox so that I can analyze the system in a safe environment

  • MEDIUM I want to be able to access and change source code or any other aspect in a safe environment, so that I can showcase a customized deployment to my colleagues/superiors.

  • MEDIUM I want to get a blueprint for DevSecOps environment so that I can build up my own BB-based system.

  • MEDIUM I want to see the infrastructure performance requirements that is needed to assess the sustainability of the BB based approach.

  • MEDIUM I want to check the administration and maintainability concept so that I can evaluate the potentially needed Maintenace efforts.

  • LOW I want to save my custom sandbox deployment so that I can continue working with it another time.

  • LOW I want to change API so that I can test integration with the test environment of my country.

  • LOW I want to get security recommendations on how to set up such an environment so that I can build a secure testing ground for my country's systems.

Persona: “CEO / Entrepreneur” (of a company supplying a BB candidate, technical)

  • MEDIUM I want to run functional and API requirements-based test scripts (and possibly other compliance checks, see status of compliance concept) so that I can proof compliance of my software product.

  • MEDIUM I want to deploy a sandbox instance with my BB candidate so that I can advertise my product as a possible component of the GovStack BB-based system.

  • LOW I want to see how my organization can suggest my BB candidate to be integrated into the GovStack sandbox so that I can showcase our spec-compliant software product.

Use Cases

1. Unconditional Social Cash Transfer/G2P Use Case

Use Case description to be inserted Nico Lueck

Building Blocks Candidates

  • Consent

  • Identification and Verification: ITU Procurement

  • Messaging

  • Payments: ITU Procurement

  • Registration: OpenCRVS?

  • Scheduling

  • Workflow and Algorithm

  • Client Case Management: OpenIMIS?

2. Construction Permits (from Djibouti)

Service design process ongoing

Additional (Non-)Functional Requirements

Requirements with abbreviations are taken from the ToR

Automated Testing Requirements

HIGH Usage of the existing BB repo structures, sketched out here: Sandbox Procurement and Tech Committee Overlap
LOW TSTA.1 Automated test scheduling, executing and reporting shall be manageable in a central, multi-user environment.
MEDIUM TSTA.2 Automated tests shall be reusable and customizable in order to run in different environments and by different GovStack implementing actors.
MEDIUM TSTA.3 Automated tests shall follow a unified reporting and monitoring.

Manual Testing Requirements

LOW TSTM.1 Guides shall describe user scenarios which cover as much functional
requirements as possible.
LOW TSTM.2 Guides shall include adversarial scenarios for basic security testing.

Quality Requirements

MEDIUM QLTY.1 Accessibility: Use case frontends shall be usable by people with disabilities by “direct access” (i.e. unassisted) and "indirect access" meaning compatibility with a person's assistive technology.
HIGH QLTY.2 Compatibility: User interfaces shall be compatible to end user devices with latest versions of Microsoft Edge, Google Chrome, Mozilla Firefox and Apple
Safari browsers.
HIGH QLTY.3 Customizability: The system shall be flexible to add new use cases.
HIGH QLTY.4 Interchangeability: The system shall enable software products which act as building block implementations to be added or interchanged with other
software products.
HIGH QLTY.5 Interoperability: The system shall use open standards for all internal or external interfaces.
HIGH QLTY.6 Maintainability: The system shall be open for corrective, adaptive, perfective and preventive changes during the whole software life cycle.
HIGH QLTY.7 Open: The system shall use open standard, built on open-source software (where possible), support open development, use cloud-native standards and be publicly available (see also chapter on open source licences).
MEDIUM QLTY.8 Reliability: The system shall maintain reliability when scaled in real world use cases.
HIGH QLTY.9 Reproducibility/replicability: The system shall be easily replicable by other actors (e.g. implementing governments) through the means of documentation and providing DevSecOps guidance.
HIGH QLTY.10 Reusability: The System and its artifacts shall be developed to be reusable by other actors (e.g. published code, containers, testing suits, UI designs).
HIGH QLTY.11 Robustness: The system shall be able to perform with low bandwidth and
unreliable connectivity (act as a best practice reference to low-resource
environments).
HIGH QLTY.12 Testability: The system shall be (automatically) testable and validatable.
HIGH QLTY.13 Responsive: User interfaces adapt to screen size and allow displaying on mobile or kiosk devices.

Hosting Requirements

HIGH HOST.1 Scope: All components of the sandbox including information mediator building blocks, synthetic data storage and use cases, excluding all other interfacing building blocks, excluding procured foundational BB or BB provided by partnerships shall be hosted by the contractor.
MEDIUM HOST.2 Minimum types of environments: Integration, Staging and Production
HIGH HOST.3 Cloud based: The system shall run on a cloud-based infrastructure.
HIGH HOST.4 Provider agnostic: The setup shall be easily replicable on other cloud platforms to meet our principle of being neutral and generic (cloud native).
HIGH HOST.5 Availability: The system’s uptime shall be above 99.00% (max. of 7.31 hours downtime a month).
MEDIUM HOST.6 Recoverability: The system shall be subject of continuous back-up routine and a well-defined disaster-recovery process.
HIGH HOST.7 ISO27001 compliance: The hosting provider shall be certified under
ISO27001.
HOST.8 SOC 2 and 3 compliance: The hosting provider shall be certified under SOC and 3.

Synthetic data requirements

HIGH DATA.1 Use case relevant: The data shall comprise all use case relevant properties.
LOW DATA.2 Citizen representative: The data shall replicate all important statistical properties of real data.
HIGH DATA.3 No attribution: The data shall be fully synthetic which make identification of any single unit impossible. At the same time all variables are still fully available.

DevSecOps Environment

HIGH Contribute to and use deployment and configuration scripts of the BB repos, sketched out here: Sandbox Procurement and Tech Committee Overlap

HIGH WP_2.1 … use Open Container Initiative (OCI) compliant containers and Cloud Native Computing Foundation (CNCF) certified Kubernetes
HIGH WP_2.2 ... host in any general-purpose public/ private cloud, or multi-tenant environments, as well as in disconnected and classified
environments.
HIGH WP_2.3 … for automating the development and deployment activities as much as possible
MEDIUM WP_2.4 … support all the activities throughout the full DevSecOps lifecycle.
MEDIUM WP_2.5 CI/CD Orchestrator as the central automation engine of the CI/CD pipeline for managing the pipeline creation, modification, execution, and termination.
HIGH WP_2.6 Documentation and other assets for reuse of the GovStack
DevSecOps software factory by other actors.

MEDIUM DEV.1 Citizen-centric: Design is centered around typical high-priority user journeys and use cases related to the SDGs. Ideally, citizens are involved at certain stages of the development cycle.
HIGH DEV.2 Generic: No single/exclusive methodological product or supporting software product is required.
HIGH DEV.3 Standard-based: Captured and guided by industry-recognized standards.
HIGH DEV.4 Open: Published under open source or creative commons licence (see chapter 3.3.7).
HIGH DEV.5 Reusable: Reusable by other actors (e.g. implementing governments) to setup an own instance of the sandbox or implement the GovStack approach.
HIGH DEV.6 Agile: Quick and short cycles to setup, test and validate the sandbox/GovStack implementation and then go for the next iteration.
MEDIUM DEV.7 Efficient: Incorporating security checks while maintaining deployment speed (through e.g. automate security gates).
MEDIUM DEV.8 Security: Incorporate measures/steps in DevSecOps approach to increase security (also known as DevSecOps). Use supporting tools to scan for
dependencies and perform static code analysis (e.g. Snyk, SonarQube or
similar).
HIGH DEV.9 Documented: Document crucial activities, customizations, configurations or code (using documentation generated from the code, through e.g. docbook, asciidoc or similar)
HIGH DEV.10 Integrated: In case of the GovStack sandbox implementation, usage of tools the GovStack Community is already working with: Gitlab and Gitbook.

  • No labels