slohmaier/dev-process
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

templates-de: German document templates, moved in from ownCloud

Browse Source 
The 25 files under templates-de/ lived in ~/ownCloud/Persönlich/slohmaier.com/vorlagen/
with no version control. They are the German-language counterpart of the
templates renamed to English in 247b831 — this repo already describes itself as
holding the ASPICE 4.0 / ISO 26262 methodology, templates and tools, so a
second home for templates would have been a duplicate.

Structure preserved as found (business/, engineering/, projekt/, qualitaet/).
No file renamed, no template content changed.

Not moved: vorlagen/slohmaier-doc-template.docx was byte-identical (MD5
31b2d0748eadf0314babf469725ee0b1) to templates-word/slohmaier-doc-template.docx
already in this repo.

Path references fixed in templates-de/README.md, which pointed at locations
that no longer exist: the ownCloud cp examples now clone from Gitea, the
generator script name follows the vorlagen/ -> templates/ rename
(generate_word_vorlagen.sh -> generate_word_templates.sh), the edit workflow
names templates/ and templates-de/ instead of the removed ownCloud copy, and
the master template is referenced at ../templates-word/.
This commit is contained in:
Stefan Lohmaier
2026-07-31 09:55:33 +02:00
parent 5a1ee8cc43
commit 8ea3f3d8f4
26 changed files with 1480 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
templates-de/engineering/SA-vorlage.md
+104
View File
@@ -0,0 +1,104 @@
---
active: true
level: 1.0
links:
- SYS-XXX: [hash]
---
# SA-XXX: [Element-Name]
> **System Architectural Design Element (ASPICE SYS.3).**
> Beschreibt ein Element der System-Architektur und sein Mapping auf System-Anforderungen.
| Feld | Wert |
|----------|-------------------------------|
| Projekt | [Projektname] |
| Datum | [YYYY-MM-DD] |
| Version | [1.0] |
| Status | [Entwurf / Freigegeben] |
| ASIL | [QM / A / B / C / D] |
| Autor | [Name] |
---
## 1. Verantwortung
[Was tut dieses Element? Ein bis zwei Saetze. Welcher Zweck im Gesamtsystem.]
## 2. System-Kontext
[PlantUML-Diagramm: dieses Element im Verhaeltnis zu Nachbarsystemen / Umgebung.]
```plantuml
@startuml
!define COMPONENT(x) component "x" as x
COMPONENT([Element])
[Element] --> [Nachbarsystem A] : Schnittstelle X
[Nachbarsystem B] --> [Element] : Schnittstelle Y
@enduml
```
## 3. Allokation
| Anforderung | Allokation auf | Bemerkung |
|---------------|----------------|---------------------------|
| SYS-XXX | dieses Element | [vollstaendig / teilweise] |
| SYS-YYY | dieses Element | [Begruendung] |
Allokations-Regel: jede verlinkte System-Anforderung muss eindeutig auf HW, SW oder Mechanik abgebildet werden.
## 4. Schnittstellen zur Umgebung
| Schnittstelle | Richtung | Typ | Bemerkung |
|---------------|---------------|----------------------|--------------------------|
| [Name] | in / out / io | [CAN / SPI / GPIO / ...] | [Protokoll-Verweis] |
## 5. Subkomponenten / Aufteilung
[Falls dieses System-Element aus mehreren Subkomponenten besteht: kurze Auflistung mit Verweis auf weitere SA- oder SWA-Elemente.]
| Subkomponente | Realisierung | Verweis |
|---------------|--------------------|-------------------|
| [Name] | [HW / SW / Mechanik] | SWA-XXX / SA-YYY |
## 6. Dynamisches Verhalten
[PlantUML-Sequenz oder State-Diagramm fuer kritische Ablaeufe.]
```plantuml
@startuml
actor Nutzer
Nutzer -> [Element]: Anforderung
[Element] -> [Nachbar]: weiterleiten
[Nachbar] --> [Element]: Antwort
[Element] --> Nutzer: Ergebnis
@enduml
```
## 7. Nichtfunktionale Eigenschaften
| Aspekt | Anforderung / Zielwert |
|---------------------|-----------------------------|
| Worst-Case Timing | [z.B. < 10 ms Reaktionszeit]|
| Speicherbedarf | [z.B. < 64 KB Flash] |
| Stromaufnahme | [z.B. < 200 mA bei 12 V] |
| Umgebungsbedingungen | [Temperatur, EMV] |
| Sicherheitsziel | [Verweis auf SG-XXX, falls vorhanden] |
## 8. Designentscheidungen
| Entscheidung | Alternativen | Begruendung |
|--------------|--------------|-------------|
| [Was] | [Was sonst noch erwogen wurde] | [Warum diese Wahl] |
## 9. Verifikation
| Anforderung | Verifikations-Methode | Test-ID |
|-------------|------------------------|-------------------|
| SYS-XXX | [Review / Test / Analyse] | TST-SYS-XXX |
Jede in den `links` referenzierte System-Anforderung muss mindestens eine Verifikations-Methode haben.
---
*Aenderungen an diesem Architektur-Element gehen per PR mit mind. 2 Technical-Review-Approvals (siehe SWE-Plan).*
templates-de/engineering/SWA-vorlage.md
+148
View File
@@ -0,0 +1,148 @@
---
active: true
level: 1.0
links:
- SWE-XXX: [hash]
---
# SWA-XXX: [Komponenten-Name]
> **Software Architectural Design Element (ASPICE SWE.2).**
> Beschreibt eine Software-Komponente und ihr Mapping auf Software-Anforderungen.
| Feld | Wert |
|----------|-------------------------------|
| Projekt | [Projektname] |
| Datum | [YYYY-MM-DD] |
| Version | [1.0] |
| Status | [Entwurf / Freigegeben] |
| ASIL | [QM / A / B / C / D] |
| Autor | [Name] |
| Parent | [SA-XXX, falls vorhanden] |
---
## 1. Verantwortung
[Ein bis zwei Saetze: Was tut diese Komponente? Wo ist die Abgrenzung zu Nachbar-Komponenten?]
## 2. Statische Sicht
### 2.1 Komponentendiagramm
```plantuml
@startuml
package "[Komponenten-Name]" {
[Submodul A]
[Submodul B]
}
[Submodul A] --> [Submodul B]
[Komponenten-Name] ..> [Nachbar-Komponente] : nutzt
@enduml
```
### 2.2 Eingebettete / verwendete Komponenten
| Komponente | Verweis | Verwendung |
|---------------|----------|--------------------------|
| [Name] | SWA-YYY | [wofuer] |
## 3. Schnittstellen
### 3.1 Bereitgestellte Schnittstelle (Provided)
```c
/**
* @brief [Kurzbeschreibung]
* @param [name] [Bedeutung, Wertebereich]
* @return [Status / Wert]
* @pre [Vorbedingung]
* @post [Nachbedingung]
*/
Status component_init(const Config* cfg);
```
| Funktion | Zweck | Pre-Condition | Post-Condition |
|------------------|----------------------|-----------------------|------------------------|
| component_init | Initialisierung | cfg != NULL | Komponente betriebsbereit |
| component_send | Daten senden | initialisiert | Daten in TX-Buffer |
### 3.2 Benoetigte Schnittstelle (Required)
| Schnittstelle | Bereitgestellt von | Zweck |
|-------------------|--------------------|-----------------------|
| ILogger::log() | LoggerComponent | Diagnose / Tracing |
| IClock::now() | ClockComponent | Zeitstempel |
## 4. Dynamisches Verhalten
### 4.1 Sequenzdiagramm (kritischer Ablauf)
```plantuml
@startuml
participant App
participant "[Komponente]" as C
participant HW
App -> C: init(cfg)
C -> HW: configure
HW --> C: ok
C --> App: STATUS_OK
@enduml
```
### 4.2 Zustandsdiagramm (falls zutreffend)
```plantuml
@startuml
[*] --> Uninitialized
Uninitialized --> Ready : init()
Ready --> Busy : send()
Busy --> Ready : tx_done
Ready --> Error : fault
Error --> Ready : reset()
@enduml
```
## 5. Ressourcen-Bedarf
| Ressource | Worst-Case | Methode der Bestimmung |
|-------------------|--------------|-----------------------------|
| Stack | [z.B. 256 B] | [Messung / statische Analyse] |
| Heap | [z.B. 0 B] | [keine Heap-Nutzung] |
| Flash | [z.B. 4 KB] | [Map-File des Linkers] |
| RAM (statisch) | [z.B. 128 B] | [Map-File des Linkers] |
| CPU-Last | [z.B. < 1 %] | [Messung auf Zielsystem] |
| Worst-Case Timing | [z.B. 200 us / Aufruf init()] | [Messung HiL] |
## 6. Fehlerverhalten
| Fehlerfall | Erkennung | Reaktion |
|-----------------------|-------------------|---------------------------|
| Ungueltige Konfig | Parameter-Check | Status STATUS_EINVAL |
| HW-Timeout | Timer | Retry, dann STATUS_TIMEOUT |
| Buffer voll | Check vor Schreiben | STATUS_NOSPACE |
## 7. Designentscheidungen
| Entscheidung | Alternative(n) | Begruendung |
|------------------------|------------------|--------------------------|
| [z.B. statische Allokation] | [Heap] | [deterministisch, MISRA] |
| [Lock-Strategie] | [Mutex / lock-free] | [Begruendung] |
## 8. Mapping auf Anforderungen
| Anforderung | Wie abgedeckt | Verifikations-Test |
|---------------|----------------------------------------------|----------------------------|
| SWE-XXX | [welcher Teil dieser Komponente erfuellt es] | TST-UNIT-XXX, TST-INT-YYY |
| SWE-YYY | [...] | TST-UNIT-YYY |
Jede in den `links` referenzierte SWE-Anforderung muss in dieser Tabelle einen Eintrag haben.
## 9. Detail-Design
Detail-Design (ASPICE SWE.3) wird ab ASIL-C separat in `arch/swd/SWD-XXX.md` gefuehrt.
Fuer ASIL-A/B und QM ist Code + Header-Kommentare ausreichend.
---
*Aenderungen an diesem Architektur-Element gehen per PR mit mind. 2 Technical-Review-Approvals (siehe SWE-Plan).*
templates-de/engineering/Traceability-Matrix-vorlage.md
+67
View File
@@ -0,0 +1,67 @@
# Traceability-Matrix
## Prinzip
Die Traceability-Matrix stellt die Rueckverfolgbarkeit von der Anforderung bis zum Test sicher:
```
System-Anforderung → Software-Anforderung → Architektur-Element → Implementierung (MR/Datei) → Testfall → Testergebnis
```
Jede Ebene muss bidirektional verfolgbar sein:
- **Vorwaerts:** Anforderung → wurde sie implementiert und getestet?
- **Rueckwaerts:** Testfall → welche Anforderung verifiziert er?
## Tabellenstruktur
| Sys-Req | SW-Req | ASIL | Arch-Element | Implementierung | Testfall | Test-Ergebnis | Status |
|---------|---------|------|--------------|----------------------|----------|---------------|--------------|
| SYR-001 | SWR-010 | B | MOD-Timer | MR !23, timer.c | TC-010 | Pass (v1.2) | Vollstaendig |
| SYR-001 | SWR-011 | B | MOD-Timer | MR !23, timer.c | TC-011 | Pass (v1.2) | Vollstaendig |
| SYR-002 | SWR-020 | A | MOD-CAN | MR !31, can_driver.c | TC-020 | Pass (v1.2) | Vollstaendig |
| SYR-003 | SWR-030 | B | MOD-Watchdog | — | — | — | Offen |
| — | SWR-040 | QM | MOD-Diag | MR !35, diag.c | TC-040 | Fail (v1.1) | Finding offen|
## Spalten-Erklaerung
| Spalte | Beschreibung |
|------------------|----------------------------------------------------------------|
| Sys-Req | System-Anforderungs-ID (GitLab Issue mit Label `req::system`) |
| SW-Req | Software-Anforderungs-ID (GitLab Issue mit Label `req::software`) |
| ASIL | Zugewiesener ASIL-Level |
| Arch-Element | Architektur-Modul oder -Komponente |
| Implementierung | Merge Request und/oder Datei |
| Testfall | Testfall-ID (GitLab Issue mit Label `test::*`) |
| Test-Ergebnis | Pass/Fail mit Version/Datum |
| Status | Vollstaendig / Offen / Finding offen |
## Lueckenanalyse
Die Matrix macht Luecken sichtbar:
- **Anforderung ohne Test:** Zeile ohne Testfall-Eintrag → Test fehlt
- **Anforderung ohne Implementierung:** Zeile ohne MR → nicht implementiert
- **Test ohne Anforderung:** Testfall der keiner Anforderung zugeordnet ist → ueberpruefen
- **Fail ohne Finding:** Fehlgeschlagener Test ohne dokumentiertes Finding → nacharbeiten
## Automatische Generierung aus GitLab
Diese Matrix kann aus GitLab-Issues automatisch generiert werden:
1. Python-Skript liest ueber GitLab API alle Issues mit `req::*`-Labels
2. Folgt Issue-Links zu Architektur-Issues, MRs und Test-Issues
3. Liest CI-Pipeline-Ergebnisse (JUnit-XML) fuer Testergebnisse
4. Erzeugt die Matrix als Markdown-Tabelle oder CSV
**Voraussetzung:** Issues sind korrekt verlinkt und gelabelt (siehe `gitlab-aspice-setup.md`).
**Ausgabe-Formate:**
- Markdown (fuer Wiki / Dokumentation)
- CSV (fuer Import in Kundensysteme)
- HTML (fuer Reporting)
Ein Beispiel-Skript liegt unter `tools/traceability-report.py` im Projekt-Repository.
---
*Die aktuelle Traceability-Matrix wird bei jedem Release aktualisiert und im Wiki abgelegt.*