feat: write template

2026-09-18 16:36:52 +02:00
commit a0a6d2cf84
@@ -0,0 +1,16 @@
+// IPA-Dokumentenvorgabe BiVo2021-2:
+//
+// Die Aufgaben (Detailbeschreibung) muss 1:1 aus PkOrg übernommen
+// werden. Inkl. allen vorgegebenen Titel.
+//
+// Unterkapitel aus der PkOrg-Aufgabenstellung: Titel der Arbeit,
+// Ausgangslage, Detaillierte Aufgabenstellung, Mittel und Methoden,
+// Vorkenntnisse, Vorarbeiten, Neue Lerninhalte, Arbeiten in den letzten
+// 6 Monaten.
+//
+// Der Inhalt darf an die Zielformatierung (IPA-Dokument) angepasst
+// werden, inklusive eventueller Korrektur der Rechtschreibfehler. Die
+// Veränderung der Satzstellung oder der Inhalte ist nicht erlaubt.
+
+= Aufgabenstellung <chap-aufgabenstellung>
+
@@ -0,0 +1,30 @@
+// IPA-Dokumentenvorgabe BiVo2021-2:
+//
+// Gibt es in Ihrer Unternehmung Standards oder sonstige Konventionen,
+// so sind diese bei der Einreichung der detaillierten Aufgabenstellung als
+// Beilage mit einzureichen, danach werden diese validiert. Bitte
+// informieren Sie hierfür ihre verantwortliche Fachkraft.
+//
+// Gibt es keine Konventionen in der Unternehmung, so gelten die mit den
+// Experten vereinbarten Best Practices, welche eingehalten werden
+// müssen. Für Applikationsentwickler gelten in dem Fall im Minimum die
+// IPA-Coding-Conventions, welche im PkOrg heruntergeladen werden
+// können.
+= Standards
+
+#lorem(200)
+
+// // Hinweis:
+// // Gibt es in der Unternehmung Konventionen oder Standards, sind diese hier
+// // aufzuführen und zu begründen. Für Applikationsentwickler gelten im Minimum
+// // die IPA-Coding-Conventions.
+// //
+// // == Versionsverwaltung
+// //
+// // Als Versionsverwaltungswerkzeug wird GIT verwendet. Alle Commits werden
+// // nach Conventional-Commits geschrieben.
+// //
+// // #figure(
+// //   image("../../02_Grafiken/Conventional-Commits.pdf", width: 80%),
+// //   caption: [Visualisierung Conventional-Commits],
+// // ) <fig-conventional-commits>
@@ -0,0 +1,42 @@
+// IPA-Dokumentenvorgabe BiVo2021-2:
+//
+// Gibt es in der IPA relevante, schützenswerte Daten? Welches sind die
+// notwendigen Informationen/Daten? Sind alle nötigen Informationen und
+// Daten vorhanden? Dürfen Daten in der Dokumentation nicht angegeben
+// werden? (Bspw. Sicherheitshandbuch der Firma).
+//
+// Für IT-Systeme gibt es eventuell auch ein ISDS-Konzept oder etwas
+// Vergleichbares, welches für die IPA beachtet werden muss? Ist dies der
+// Fall, bitte die relevanten Dokumente auf PkOrg hochladen und im IPA-
+// Bericht darauf verweisen.
+
+= IPA-Schutzbedarfsanalyse <schuban>
+
+#lorem(200)
+
+// In der Schutzbedarfsanalyse wird geprüft, ob in der Dokumentation der IPA oder
+// in der Applikation schützenswerte Daten verarbeitet werden. Zudem werden die
+// erforderlichen Massnahmen festgelegt, um den Schutz dieser Daten sicherzustellen.
+//
+// == Dokumentation
+//
+// In der Dokumentation enthaltene Informationen dürfen keine Rückschlüsse auf die
+// folgenden Punkte preisgeben:
+//
+// - Konfiguration der Unternehmensinfrastruktur
+//   - IP-Adressen
+//   - Gerätenamen
+//   - Domainnamen
+//   - Benutzernamen
+//   - Passwörter
+// - Interne Entwicklungsvorgaben
+// - Vertrauliche Daten aus der Applikation
+//
+// Falls die Dokumentation Informationen zu den genannten Punkten beinhaltet,
+// muss diese für eine öffentliche Version geschwärzt werden. Die interne Version,
+// welche dem Experten zur Verfügung gestellt wird, darf diese Informationen beinhalten.
+//
+// Da diese IPA kein Deployment bzw. keine Inbetriebnahme der Applikation beinhaltet,
+// sollten voraussichtlich keine Gerätenamen oder Ähnliches verwendet werden müssen.
+//
+// Der IKT-Grundschutz @grundschutz muss eingehalten werden.
@@ -0,0 +1,80 @@
+
+#import "@local/chfoit-ipa:0.0.0": acronym, term
+
+// IPA-Dokumentenvorgabe BiVo2021-2:
+//
+// Wie werden die Ergebnisse der IPA abgelegt und was wird unternommen,
+// um die Ergebnisse der IPA vor Verlust zu schützen.
+// Beispiel:
+// • Backup-Konzept: was wird wie und wann gesichert
+// • Einsatz von Sourcecode-Verwaltungssystemen: wie wird damit
+// gearbeitet
+// ➔ Die Nachweise (Backup Log, Commit History, …) müssen innerhalb
+// des Anhangs der Dokumentation abgegeben werden.
+= Organisation der IPA-Ergebnisse
+
+#lorem(200)
+
+// == Arbeitsplatz
+//
+// #figure(
+//   image("../../02_Grafiken/arbeitsplatz.png", width: 80%),
+//   caption: [Arbeitsplatz der IPA],
+// ) <fig-arbeitsplatz>
+//
+// Beschreibung des Arbeitsplatzes, der verwendeten Arbeitsgeräte und
+// Hilfsmittel (z. B. Editor, Satzsystem, Diagrammwerkzeug).
+//
+// == Verwaltung der Ergebnisse
+//
+// Die Ergebnisse werden jeweils in einem Git #term(
+//   "Repository",
+//   "Ein zentraler, digitaler Speicherort für Daten, Dateien und Projektunterlagen,
+// der eine strukturierte Verwaltung, Versionierung und gemeinsame Nutzung (Kollaboration) ermöglicht.",
+// ) verwaltet. Eines für die Dokumentation und eines für den Code.
+//
+// Die Dokumentation ist in folgender Verzeichnisstruktur abgelegt:
+//
+// #figure(
+//   image("../../02_Grafiken/dirtree.png", width: 80%),
+//   caption: [Verzeichnisbaum der IPA],
+// ) <fig-dirtree>
+//
+// #pagebreak(weak: true)
+// #show table.cell.where(x: 0): set text(font: "Fira Mono")
+// #figure(
+//   table(
+//     columns: (auto, auto),
+//     table.header([Verzeichnis], [Beschreibung]),
+//     [01_Dokumentation], [Alle Informationen, die in der Dokumentation verwendet werden.],
+//     [01_Dokumentation/01_Teil1], [Kapitel des Teil 1 als einzelne Typst-Dateien.],
+//     [01_Dokumentation/02_Teil2], [Kapitel des Teil 2 als einzelne Typst-Dateien.],
+//     [01_Dokumentation/03_Anhang], [Kapitel des Anhangs als einzelne Typst-Dateien.],
+//     [02_Grafiken], [Jegliche Grafiken, die für die Dokumentation verwendet werden.],
+//     [03_Zeitplan], [Hier wird der Zeitplan abgelegt],
+//     [04_Code], [Ablage für den Code. Wird in Git als Submodul gespeichert.],
+//   ),
+//   caption: [Erklärung der Ordnerstruktur der IPA],
+// ) <ordnerstruktur-erklärung>
+//
+// == Datensicherung IPA
+//
+// === Code
+//
+// Der Code wird mit dem Versionsverwaltungstool Git versionisiert.
+// Damit können einfach Teil-Features gepusht werden und es bleiben jederzeit
+// alle Änderungen nachvollziehbar. Ebenfalls kann jederzeit auf einen alten
+// Stand zurückgespielt werden.
+//
+// ==== Branch-Strategie
+//
+// #figure(
+//   image("../../02_Grafiken/branch-strategy.png", width: 80%),
+//   caption: [Git Branch-Strategie],
+// ) <fig-branch-strategy>
+//
+// === Dokumentation
+//
+// Der gesamte IPA-Ordner ist mit Git versionisiert. Nach jeder signifikanten
+// Änderung wird ein Commit erstellt und gepusht. Durch die lokale Versionierung
+// sowie die regelmässigen Commits ist die Dokumentation immer gesichert.
@@ -0,0 +1,61 @@
+// IPA-Dokumentenvorgabe BiVo2021-2:
+//
+//Projektvorgehensmodell beschreiben und begründen, warum das
+// entsprechende Modell gewählt wurde.
+// Wichtig:
+// • Änderungen zu einem Standardmodell müssen immer beschrieben
+// sein. Sind diese nicht beschrieben, werden vom Standard
+// abweichende Elemente als Verletzung der Methode gewertet.
+// • Dass ein Modell im jeweiligen Betrieb verwendet wird, reicht
+// nicht als Begründung für die Verwendung des Modells!
+// • IPERKA wird im Kanton Bern als Projektmethode nicht
+// akzeptiert und darf nicht verwendet werden.
+
+= Projektmethode <chap-projektmethode>
+
+#lorem(200)
+//
+// Die IPA wird nach  HERMES 2022 mit dem Szenario IT-Entwicklung (klassisch) wie in @fig-hermes-uebersicht abgebildet durchgeführt.
+// Die folgenden Unterkapitel erläutern dies Weiter.
+//
+// #figure(
+//   image("../../02_Grafiken/hermes-uebersicht.png", width: 100%),
+//   caption: [Übersicht der Projektplanung],
+// ) <fig-hermes-uebersicht>
+//
+// == Szenario
+//
+// Die IPA wird mit dem Szenario "IT-Entwicklung" durchgeführt, da nach @chap-aufgabenstellung eine Eigenständige IT-Lösung entwickelt wird.
+//
+// == Phasen
+// Im rahmen der IPA wird die Einführungsphase ausgelassen, da das Produkt
+// wie in @chap-aufgabenstellung beschrieben nicht eingeführt werden muss.
+//
+// Wie der @fig-hermes-uebersicht zu entnehmen ist, werden folgende Phasen von HERMES durchgeführt:
+//
+// - Initialisierungsphase: Hier wird das Fundament des Projektes gelegt. Varianten Angeschaut und Ausgewählt.
+// - Konzeptphase: Wie es der Name sagt, werden da die Konzepte zur Realisierung erarbeitet, wie z.B. das Testkonzept.
+// - Realisierungsphase: Hier wird die Applikation implementiert.
+// - Abschlussphase: Hier wird das Projekt abgeschlossen und abgegeben.
+//
+// == Module
+//
+// In der @fig-hermes-modules werden die HERMES-module die in der IPA verwendet werden Beschrieben.
+//
+// #figure(
+//   table(
+//     columns: (auto, 1fr),
+//     [Modul], [Beschreibung],
+//     [Projektsteuerung],
+//     ["Das Modul Projektsteuerung sorgt für die gesamthafte und organisationsübergreifende Steuerung des Projekts und stellt die Erreichung der gesetzten Ziele sicher." @hermes-online],
+//
+//     [Projektführung],
+//     ["Im Rahmen des Moduls Projektführung erfolgt die Planung, Führung und Koordination des Projekts zur Erreichung der Projektergebnisse und der Vorgehensziele sowie die Durchführung aller notwendigen flankierenden Massnahmen." @hermes-online],
+//
+//     [IT-System], ["Das Modul IT-System dient der Entwicklung eines Systems." @hermes-online],
+//     [Tests],
+//     ["Das Modul Tests dient einer systematischen und effizienten Organisation und Durchführung des Testens von Lösungen." @hermes-online],
+//   ),
+//
+//   caption: [Übersicht HERMES module],
+// )<fig-hermes-modules>
@@ -0,0 +1,69 @@
+#import "@local/chfoit-ipa:0.0.0": persons
+#import "@preview/pintorita:0.1.4"
+
+// IPA-Dokumentenvorgabe BiVo2021-2:
+//
+// Projektorganisation (Personen & Kontaktangaben, Projektrollen) Siehe
+// Details im Beurteilungskriterium A11 – «Abbildung der
+// Projektaufbauorganisation»
+//
+//
+// A11: Welche Informationen zur Projektaufbauorganisation sind verlangt?
+//
+// 1. Die Projektaufbauorganisation ist Bestandteil von Teil 1 des IPA-Berichts.
+// 2. Die zur Projektmethode passenden Rollen wurden identifiziert.
+// 3. Die Rollen wurden prägnant und verständlich beschrieben.
+// 4. Die Abhängigkeit der Rollen zueinander wurde korrekt dargestellt oder beschrieben.
+
+= Projektaufbauorganisation
+
+#lorem(200)
+
+
+// TODO: Beschreibung zu den Rollen
+
+//
+// #figure(
+//   image("../../02_Grafiken/projektorganisation.pdf", width: 80%),
+//   caption: [Projektorganisation],
+// )
+//
+// == Projektrollen
+// #figure(
+//   table(
+//     columns: (auto, 1fr),
+//     [Auftraggeber],
+//     [Der Auftraggeber ist hierarchisch gesehen die höchste rolle. Er hat das Projekt beauftragt und stellt die Anforderungen sowie Rahmenbedingungen.],
+//
+//     [Projektausschuss],
+//     [Der Projektausschuss besteht aus der Veranwortlichen Fachkraft (VF). Er überwacht und hilft. Er bewertet die IPA zusammen mit den Experten.],
+//
+//     [Qualität & Risikomanager],
+//     ["Der Qualitäts- und Risikomanager unterstützt den Auftraggeber mit einer unabhängigen Beurteilung des Projekts." @hermes-online Er bewertet ausserdem,
+//       die IPA zusammen mit der verantwortlichen Fachkraft.],
+//
+//     [Projektleiter],
+//     [Der Projektleiter leitet das Projekt im Auftrag des Auftraggebers. Er koordiniert und verwaltet die Resoucen.],
+//
+//     [Entwickler ],
+//     [
+//       "Die Rolle Entwickler ist umfassend und bezeichnet den Produktentwickler und den IT-Entwickler in einem. Der Entwickler realisiert das Produkt bzw. das System gemäss den Lösungsanforderungen und den vorangehenden Konzepten. [...]" @hermes-online
+//     ],
+//   ),
+//   caption: [Projektrollen],
+// )
+//
+// == Personen
+//
+// Aus Platzgründen werden die Personennamen teilweise mit folgenden Kürzeln abgekürzt. Falls
+// Kontakt zu einem IPA-Teilnehmenden aufgenommen werden möchte, können die Daten aus
+// @fig-kontakt entnommen werden.
+//
+// #context [
+//   #figure(
+//     table(
+//       columns: (auto, auto, 1fr),
+//       ..persons.overview(),
+//     ),
+//     caption: [Namenskürzel & Kontaktangabe],
+//   )<fig-kontakt> ]
@@ -0,0 +1,30 @@
+// IPA-Dokumentenvorgabe BiVo2021-2:
+//
+// Der zeitliche Ablauf der IPA. Siehe Details im Beurteilungskriterium A4-
+// «Zeitplan»
+//
+// A4: Was sind die Anforderungen an den Zeitplan?
+// - 1 Der Zeitplan ist Bestandteil von Teil 1 des IPA-Berichts.
+// - 2 Der Zeitplan ist übersichtlich gestaltet.
+// - 3 Struktur und Elemente des Zeitplans orientieren sich nach der gewählten
+//     Projektmethode.
+// - 4 Es wurde eine Zeitachse definiert (Datum), die Zeitachse weist eine vernünftige
+//     Granularität auf (bspw. Stundenblöcke).
+// - 5 Die identifizierten Aktivitäten sind zweckmässig und folgen einer sinnvollen Logik.
+// - 6 Die IPA-Zeitvorgabe ist im Zeitplan korrekt berücksichtigt.
+#page(
+  paper: "a3",
+  margin: 2cm,
+  flipped: true,
+  {
+    [
+      = Zeitplan <chap-zeitplan>
+    ]
+
+    set block(below: 0em)
+    figure(
+      image("../../03_Zeitplan/Zeitplan.pdf", height: 93%, width: 100%, fit: "contain"),
+      caption: [Zeitplan],
+    )
+  },
+)
@@ -0,0 +1,73 @@
+#import "@local/chfoit-ipa:0.0.0": arbeitsjournal
+
+// IPA-Dokumentenvorgabe BiVo2021-2:
+//
+// Referenz zum Zeitplan und Ablauf. Beinhaltet Hinweise zu eventuellen
+// Herausforderungen innerhalb des Ablaufs.
+// Auflistung oder Beschreibung (ca. ½ Seite) aller Aktivitäten gemäss
+// Zeitplan. Reflexion, Erkenntnisse und Massnahmen Best Practices ca. ½
+// Seite.
+
+// Doc7: Was ist beim Führen des Arbeitsjournals zu beachten?
+// 1. Das Arbeitsjournal ist Bestandteil von Teil 1 des IPA-Berichts.
+// 2. Die Darstellung ist übersichtlich, klar und verständlich.
+// 3. Das Arbeitsjournal besteht aus individuellen Tagesberichten.
+// 4. Alle Aktivitäten gemäss Zeitplan sowie Überzeiten und ungeplante Arbeiten sind
+//    erwähnt.
+// 5. Erfolge und Misserfolge sind erwähnt. Misserfolge werden kritisch hinterfragt.
+// 6. Sämtliche in Anspruch genommenen Unterstützungen, einschliesslich externer Hilfe
+//    und KI-Nutzung, sind umfassend aufgeführt und entsprechend begründet.
+//
+
+= Arbeitsjournale
+
+// entry wrapper for default values
+#let entry(
+  day: datetime,
+  supplementaryPersons: (:),
+  tagesablauf,
+  hilfestellungen,
+  gut,
+  schlecht,
+  erkenntnisse,
+) = {
+  // if you have any persons who are always there at one specific task
+  // you can add them here.
+  let sp = ("Täglicher Austausch": ("VF",))
+
+  for (item, persons) in supplementaryPersons.pairs() {
+    sp.insert(item, persons)
+  }
+
+  arbeitsjournal.entry(
+    day: day,
+    defaultPerson: "MM", // that's you
+    supplementaryPersons: sp,
+    tagesablauf,
+    hilfestellungen,
+    gut,
+    schlecht,
+    erkenntnisse,
+  )
+}
+
+#entry(
+  day: datetime(year: 2026, month: 3, day: 1),
+  [
+    #lorem(100)
+  ],
+  [
+    #lorem(50)
+  ],
+  [
+
+    #lorem(50)
+  ],
+  [
+    #lorem(50)
+  ],
+  [
+
+    #lorem(50)
+  ],
+),
@@ -0,0 +1,11 @@
+// IPA-Dokumentenvorgabe BiVo2021-2:
+//
+// Persönliches Fazit über die gesamte Arbeit. Siehe Details im
+// Beurteilungskriterium Doc8 – «Persönliches Fazit»
+
+
+= Persönliches Fazit
+
+
+#lorem(500)
+
@@ -0,0 +1,11 @@
+#include "01_Aufgabenstellung.typ"
+#include "02_Standarts.typ"
+#include "03_Schutzbedarfsanalyse.typ"
+#include "04_OrgansiationErgebnisse.typ"
+#include "05_ProjektVorgehen.typ"
+#include "06_Projektorganisation.typ"
+#include "07_Zeitplan.typ"
+#include "08_Arbeitsjournale.typ"
+#include "09_Fazit.typ"
+
+