diff --git a/docs/content/architecture/01_introduction/02_quality_goals.md b/docs/content/architecture/01_introduction/02_quality_goals.md index 80bf6e42..1abc4281 100644 --- a/docs/content/architecture/01_introduction/02_quality_goals.md +++ b/docs/content/architecture/01_introduction/02_quality_goals.md @@ -4,4 +4,14 @@ draft: true cascade: type: docs --- -DRAFT +The following table describes the key quality objectives of DAS. + +| Quality Goal | Motivation/description | +|:------------------------------------------------------------------------|:------------------------| +| Railway operations depend on it (Reliability) | | +| Provided information is correct (Functional Suitability) | | +| Reliable and efficient operation (Operability) | | +| Changes need to be implemented efficiently and safely (Maintainability) | | +| Support, not distract the engine driver (Usability) | | + +The [Quality Requirements in section 10](../../10_quality_requirements/) detail these goals and serve to evaluate their achievement. diff --git a/docs/content/architecture/04_solution_strategy/01_introduction.md b/docs/content/architecture/04_solution_strategy/01_introduction.md index 09aaeae2..bea1c231 100644 --- a/docs/content/architecture/04_solution_strategy/01_introduction.md +++ b/docs/content/architecture/04_solution_strategy/01_introduction.md @@ -4,4 +4,43 @@ draft: true cascade: type: docs --- -DRAFT +The following list contrasts the [quality goals](../../01_introduction/02_quality_goals/) of DAS with matching architecture approaches and thus provides easy access to the solution. + +**Railway operations depend on it (Reliability)** +* decoupling +* caching the data +* reduce number of involved systems + +**Provided information is correct (Functional Suitability)** +* comprehensive testing +* read-only View-Model / immutable objects +* using Mappers + +**Reliable and efficient operation (Operability)** +* logging and monitoring +* crash recorder on mobile +* no unnecessary dependencies + +**Changes need to be implemented efficiently and safely (Maintainability)** +* no unnecessary dependencies, quality check +* cohesive and well-structured internal data model +* APIM -> +* modularization +* Interfaces for core abstractions -> +* using standards +* lint enforced +* check architecture with tools (ArchUnit) + +**Support, not distract the engine driver (Usability)** +* intense collaboration between UX- and dev-team + +Further goals which are important for DAS: + +**Auditability** +* logging +* open source +* comprehensive documentation + +**Safety** +* follow (SBB internal) processes to assess risks +* comprehensive testing \ No newline at end of file diff --git a/docs/content/architecture/09_design_decisions/authentication_adr.md b/docs/content/architecture/09_design_decisions/authentication_adr.md index d9e85178..566c73df 100644 --- a/docs/content/architecture/09_design_decisions/authentication_adr.md +++ b/docs/content/architecture/09_design_decisions/authentication_adr.md @@ -21,9 +21,9 @@ DAS is operated for various RUs and must therefore have an exchangeable or broad ## Influences on the Decision * Azure is the standard technology for IAM at SBB. -*In order to authenticate other companies/EVUs, a federation of Azure ADs must be created. +* In order to authenticate other companies/EVUs, a federation of Azure ADs must be created. * With Multitenant, the partner RUs must manage the identities and can therefore be delegated. -*With Crosstenant, all identities would have to be managed by SBB. However, SBB does not know the identities and cannot know which identities should have which access. +* With Crosstenant, all identities would have to be managed by SBB. However, SBB does not know the identities and cannot know which identities should have which access. * If there is no identity federation, each RU would have to operate a DAS itself, which is not currently planned. * Exchange with the Beacon Management project has taken place. Azure Multitenant is already used there with many TUs and there is multi-client capability and delegated role management. @@ -32,7 +32,6 @@ DAS is operated for various RUs and must therefore have an exchangeable or broad ## Considered Alternatives -* Multitenant * Crosstenant ## Decisions diff --git a/docs/content/architecture/09_design_decisions/cenelec_adr.md b/docs/content/architecture/09_design_decisions/cenelec_adr.md deleted file mode 100644 index 43fd0a2c..00000000 --- a/docs/content/architecture/09_design_decisions/cenelec_adr.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: Development according to CENELEC -draft: true -status: DECIDED -result: Development without CENELEC -owner: Dominik Schmucki -date: 2023-03-01 -issue: -tags: - - adr ---- - -{{< adr-table "adr" >}} - -## Problem Background - - -## Influences on the Decision - - -## Assumptions - - -## Considered Alternatives - - -## Decisions diff --git a/docs/content/architecture/09_design_decisions/open_source_adr.md b/docs/content/architecture/09_design_decisions/open_source_adr.md deleted file mode 100644 index 3ef9d765..00000000 --- a/docs/content/architecture/09_design_decisions/open_source_adr.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -title: Open Source -status: DECIDED -result: DAS is developed OpenSource with a strong Copyleft licence -owner: Dominik Schmucki -date: 2023-03-03 -issue: -tags: - - adr ---- - -{{< adr-table "adr" >}} - -## Problem Background -### What does open source mean for SBB? -The digital zone wants to strategically utilise the advantages of open source. For us, open source means that we can develop software simply, jointly and across company boundaries. - -SBB expects the following effects from this: -* Promote interoperability -* Promote innovation -* Avoid vendor lock-in -* Increase employer attractiveness - -For the development of the digital timetable, it should be considered what the implementation as open source means for the publication as an own solution (Create). The (internal) Open Source Guide contains a list of questions that need to be answered. - -## Influences on the Decision -### Effects on DAS -* In addition to operation, there is also the maintenance of the community. Input from the community should be taken into account and processed. -### Effects on the development process -* Checking the licences of the libraries used -* Publication on GitHub -* Discipline in the development process, onboarding / briefing of developers necessary -* Obligation to comply with code quality standards -* Functioning review processes -* CLEW team support limited, CI/CD not on internal environment -* Influence of CENELEC? - -### Is the solution suitable for publication? -✅❌️⚠️🛑 - -| Question | Assessement | Go | -|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----| -| **Legal basis:** Do the rights tyo the code belong to SBB? If not, is redistribution of the code permitted? | Code is developed first, the rights belong to SBB accordingly (in-house development) or relationships can be clarified contractually. | ✅ | -| **Potential:**
- Are there use cases for the solution outside SBB?
- Could SBB benefit from an exchange with experts from the open source community?
- Could the solution be improved by external contributions?
- Would members of the project community be potentially interesting candidates for jobs at SBB? | Use cases:
- The timetable can potentially be used on the entire Swiss rail network by various RUs.
- Exchange with experts: Unclear, as technicality is very specific.
- External contributions: When the FO is used by other RUs, there is potential for improvements and bug fixes to be introduced directly as contributions.
- Candidates: Yes, definitely. | ✅| - - -## Assumptions - - -## Considered Alternatives -Closed source. - -## Decisions