% Created 2019-03-11 Mon 16:46
% Intended LaTeX compiler: pdflatex
\documentclass[a4paper,11pt]{article}

\input{general/style}
\author{Andreas Zweili}
\date{\today}
\title{Meeting Protokolle}
\hypersetup{
 pdfauthor={Andreas Zweili},
 pdftitle={Meeting Protokolle},
 pdfkeywords={},
 pdfsubject={},
 pdfcreator={Emacs 26.1 (Org mode 9.2.2)},
 pdflang={English}}
\begin{document}

\maketitle\newpage

\section*{Meeting vom 23.12.2018}
\label{sec:org473d299}
Protokoll der 1. Besprechung

Treffpunkt: Bhf Olten

Datum: 23.12.2018, 14:00 Uhr - 15:30 Uhr

\subsection*{Informationen:}
\label{sec:org1431703}

\subsubsection*{Vorstellungsrunde}
\label{sec:orgcfc00b6}
\paragraph*{Marco}
\label{sec:org08684d1}
\begin{description}
\item[{Beruflich}] Bereits viel gemacht mit ca. 40 selbständig gemacht.
\item[{Schulisch}] Kam nach und nach und nimmt mittlerweile einen Grossteil seiner
Zeit in Anspruch.
\item[{Familie}] Hat Frau und Kinder.
\item[{Hobbies/Interessen}] Südamerika (lebte 2 Jahre dort) und Salsa?
\end{description}

\paragraph*{Andreas}
\label{sec:orge2cf9cd}
\begin{description}
\item[{Beruflich}] Quereinsteiger, gelernter Automatiker, Faszination Informatik,
Deployment, Orchestrierung, Automatisation
\item[{Schulisch}] API Spezialisierung mehr angesprochen aufgrund der Dozenten
während IBZ Ausbildung.
\item[{Hobbies}] IBZ, Musik, Konzerte
\end{description}

\subsubsection*{Termine besprochen}
\label{sec:org4967130}

Abgabe der DA Informatik erfolgt vereinfacht, Widerspruch zur offiziellen
Vorgabe. Email mit den Unterlagen am 18.3. an Marco Frei reicht. Man muss
nichts beim Sekretariat abgeben.

Nur 1 Diplomordner z.Hd. Kandidat mit separat Selbständigkeitserklärung
unterschrieben. Ist an der Präsentation mitzunehmen. Die Erklärung wird dann
gleich von C.Herren kontrolliert.

\subsubsection*{Beobachtung von Marco Frei:}
\label{sec:org0b2a6f7}
Exakte Zeitplanung, auch Miteinbezug der eigenen Intensität (geplante Stunden
Aufwand) pro Woche, Arbeitspakte verständlich, PSP soweit detailliert.

Einige Kapitel des DA Antrags können 1:1 in die Doku oder allenfalls mit
ergänzenden Resultaten aus der Analyse übernommen werden.

Feinziele entsprechen bereits den ausgearbeiteten Anforderungen aus der bereits
durchgeführten Projektanalyse.

\subsubsection*{Feedback Andreas:}
\label{sec:orgced5a2b}
Mussziele müssen erreicht werden.

\subsection*{Aufbau der Arbeit}
\label{sec:org6130b96}
\subsubsection*{Initialisierung / Voranalyse}
\label{sec:orgf4cbead}

\begin{itemize}
\item Einleitung
\item Umfeld, Motivation
\item Projekthandbuch (Projektdokumentation) mit Ausgangslage, Problembeschreibung,
Projektziele, Abgrenzungen, Zeitplanung, Projektplanung, Projektmethodik
Wasserfallmethodik (Begründung)
\item Projektrisiken (betriebliches Umfeld) der Ist Umgebung
\item Projektcontrolling Soll-Ist (Zeit, Ressourcen, Kosten (eigene Lohnkosten
annehmen)), Bewertung
\item allenfalls Zeitplan mit Phasen der Wasserfallmethodik anpassen, Milestone
setzen
\end{itemize}

\subsubsection*{Analyse}
\label{sec:orgaa137c0}

\begin{itemize}
\item Ist - Analyse, Stakeholderanalyse, Umweltanalyse, Marktanalyse
\item SWOT (Stärken, Schwächen)
\item quasi hypothetische Risikoanalyse der Ist Umgebung, um daraus Bewertung der
eigenen Lösung auch mit einer Risikoanalyse miteinzubeziehen, evtl. durch
fiktiver User, Use Case
\item Soll - Analyse
\item Use Case mit Aktoren festlegen
\item Anforderungskatalog kann aus den Zielen hergeleitet werden, kann evtl. noch
erweitert oder angepasst werden, z.B. Präzision, Umwelt, Verwendung von
Testarten etc.
\end{itemize}

\subsubsection*{Konzept}
\label{sec:org86ed441}

\begin{itemize}
\item Big Picture aufzeigen, Zusammenspiel erläutern
\item Start der Variantendiskussion
\item Entscheid, Begründung des Lösungswegs
\item Detailkonzept mit techn. Plan
\item Diagramme. UML, Klassendiagramm, etc.
\item Testkonzept. Testarten (Unit, Integrations-Testing), Festlegung der
Testarten, Rahmenbed.
\end{itemize}

\subsubsection*{Realisierung}
\label{sec:org5a3b2e4}

\begin{itemize}
\item Open-Source Projekt als gesamtes Werk, leistet im Rahmen der DA wichtige
Vorarbeit
\item mit minimalen Funktionen (welche?) -> Backup, Restore, mount, delete, Archiv
\item Beweis der Funktion? wie? -> Testumgebung aufbauen, erläutern
\item Linux System Python Skript -> self extracting binary wird interpretieren
\end{itemize}

\subsubsection*{Ausblick:}
\label{sec:orga5f61a3}

\begin{itemize}
\item kritische Würdigung, lessons learned
\item Verwendung im kommerziellen Umfeld
\item Bewertung der Risiken anhand der eigenen Lösung
\end{itemize}

\subsection*{Nächste Termine}
\label{sec:org00f1cab}

Meeting \#2: 26.01.2019 14:00

Meeting \#3: Ende Feb. exakter Termin noch ausstehend.

\subsection*{Pendent}
\label{sec:org88ab40d}

\begin{itemize}
\item roter Faden der Gesamtstruktur anhand Analyse und Synthese abgleichen
\item Grobstruktur trennen auf Analyse und Konzept, z.B. vor dem Start der
Variantendiskussion
\item zusätzlich Grundidee, Vision in der Einleitung
\item fiktive Situation im Rahmen der Analyse -> Ist Risikoanalyse zum Leben bringen
\item Überlegung, ob alle Ziele 1:1 den Anforderungen genügen, welche als
Voraussetzung fürs Testing dienen
\item möglicher Zugriff auf Datenablage
\end{itemize}

\subsection*{Doing}
\label{sec:orgb6455fc}

Andreas erstellt folgende Lieferobjekte:
\begin{itemize}
\item Besprechungsprotokoll mit Entscheidungen
\item Arbeitsjournal, wochengenau (einfaches Logbuch, z.B. Excel oder in Zeitplan
integriert, mit Bezug zur erstellten Projektplanung) -> Gitlog führen plus
erweitern (Planung, Ergebnis, Eindruck)
\item Projektplan mit Phasen, Milestones, Arbeitspaketen
\item Zeitplan mit Intensität als Tabelle oder Gantt (250h inkl. mögliche
Pufferzeit 50h), Einbau in Bericht
\item Festlegung der Systemgrenze, evtl. mit UML Werkzeugen (Bubble Charts)
\item messbare Muss- und Kannziele
\item Traktandenliste für nächstes Meeting erstellen
\item Risikoanalyse machen
\item Festlegung der Grobstruktur, in Bezug zum Projektantrag
\end{itemize}

\subsection*{Noch unvollständig}
\label{sec:orgc7259b5}

Nichts.

\subsection*{Persönlicher Eindruck von Marco Frei:}
\label{sec:orga54b0a7}

\begin{itemize}
\item präzise Analyse
\item klare Ziele, Vorstellung
\item ausgezeichnet im Zeitplan
\item detaillierte Ergebnisse
\item aktuelle Ausgangssituation könnte präziser formuliert werden
\item Engineering Vorgehen verstärkt hervorheben
\end{itemize}



\section*{Meeting vom 26.01.2019}
\label{sec:orgcd851ef}

Protokoll der 2. Besprechung

Treffpunkt: IBZ Aarau

Datum: 26.1.2019, 14:00 Uhr - 15:15 Uhr

\subsection*{Allgemeines}
\label{sec:org1cc8060}

Beobachtung: exakte Zeitplanung, auch Miteinbezug der eigenen Intensität
(geplante Stunden Aufwand) pro Woche, Arbeitspakete verständlich,
Projektstrukturierung soweit detailliert -> erledigt

ausgezeichnet im Zeitplan

open source Projekt als gesamtes Werk, aktuelle Source Code Version auf
github unter \url{https://github.com/borg-qt/} -> erledigt

einige Kapitel des DA Antrags können 1:1 in die Doku oder allenfalls mit
ergänzenden Resultaten aus der Analyse übernommen werden -> erledigt

Beobachtung: Feinziele entsprechen bereits den ausgearbeiteten Anforderungen
aus der bereits durchgeführten Projektanalyse -> erledigt

roter Faden der Gesamtstruktur anhand Analyse und Synthese abgleichen ->
erledigt

Grobstruktur trennen auf Analyse und Konzept, z.B. vor dem Start der
Variantendiskussion -> erledigt

zusätzlich Grundidee, Vision in der Einleitung -> erledigt

fiktive Situation im Rahmen der Analyse -> Ist Risikoanalyse zum Leben
bringen -> Erweiterungen mit use cases abgebildet - erledigt

Überlegung, ob alle Ziele 1:1 den Anforderungen genügen, welche als
Voraussetzung fürs Testing dienen > erledigt

möglicher Zugriff auf Datenablage -> erledigt

\url{https://github.com/Nebucatnetzer/thesis}

Besprechungsprotokoll mit Entscheidungen führen -> erledigt

Zeitplan mit Intensität als Tabelle oder Gantt (250h inkl. mögliche
Pufferzeit 50h), Einbau in Bericht -> erledigt

detailliertere Informationen zu gewissen Punkten der Konzeptarbeit, d.h.
Technik BorgBackup erläutern, QT Framework erläutern, Logging zeigen, Backup
erstellen, Netzwerk prüfen, Datenduplizierung erklären, Konfiguration in
Plain Textdatei erstellen, Cross Plattfom Techniken erläutern (insbesondere
da BorgBackup Support nur unter Linux, somit nicht vollständig möglich),
JSON Format erläutern, Zusammenspiel und Schnittstelle zwischen Python
Skript und bestehendem Binary beschreiben, Verwendung der Umgebungsvariablen
für Programmierung, Passwort Handling beim Aufruf des Binary -> auf gutem
Wege

geplante 1 Woche Reserve in der Phase Realisierung, während dem Codieren ->
doing

Arbeitsjournal, wochengenau (einfaches Logbuch, z.B. Excel oder in Zeitplan
integriert, mit Bezug zur erstellten Projektplanung) -> Gitlog führen plus
erweitern (Planung, Ergebnis, Eindruck) -> doing

Qualitätskontrolle und Controlling ansprechen (wichtiger Bestandteil der
Bewertung) -> doing

\subsection*{Aufbau der Arbeit}
\label{sec:org9c6b87a}

\subsubsection*{Initialisierung / Voranalyse:}
\label{sec:org50b579a}

Einleitung -> erledigt

Projekthandbuch (Projektdokumentation) mit Ausgangslage,
Problembeschreibung, Projektziele, Abgrenzungen, Zeitplanung,
Projektplanung, Projektmethodik Wasserfallmethodik (Begründung) -> erledigt

Projektrisiken (betriebliches Umfeld) der Ist Umgebung -> erledigt

allenfalls Zeitplan mit Phasen der Wasserfallmethodik anpassen -> erledigt

Milestone setzen -> erledigt

Umfeld, Motivation -> nochmals nachfragen, insbesondere Programmierung mit
Python und Nutzung des QT Framework für das GUI ist Neuland, Bedeutung
hervorheben

nachträgliche Berücksichtigung weiterer möglicher Kannziele -> doing

Projektcontrolling Soll-Ist (Zeit, Ressourcen, Kosten), Bewertung -> doing

\subsubsection*{Analyse:}
\label{sec:orgeb0951a}

SWAT (Stärken, Schwächen) -> erledigt

quasi hypothetische Risikoanalyse der Ist Umgebung, um daraus Bewertung der
eigenen Lösung auch mit einer Risikoanalyse miteinzubeziehen -> recht
projektbezogene Darstellung -> erledigt

Anforderungskatalog kann aus den Zielen hergeleitet werden, kann evtl. noch
erweitert oder angepasst werden, z.B. Präzision, Umwelt, Verwendung von
Testarten etc. -> erledigt

Soll - Analyse -> erledigt

use case Diagramm mit Aktoren festgelegt -> erledigt

Ist - Analyse, Stakeholderanalyse, Umweltanalyse, Marktanalyse -> alle
Usergruppen festgelegt -> erledigt

allenfalls Wahl bestimmter Usergruppen noch begründen, z.B. für das Testing
-> doing

geplante Durchführung des Testings -> Transparenz, mit Auswertung der
Ergebnjsse -> doing

Festlegung der Systemgrenze, evtl. mit UML Werkzeugen -> nochmals prüfen

\subsubsection*{Konzept:}
\label{sec:org758371d}

Aktivitätsdiagramm gemacht -> erledigt

Kontextdiagramm gemacht -> erledigt

Testkonzept. Testarten (Unit, Integrations-Testing), Festlegung der
Testarten, Rahmenbed. -> 25 Testfälle definiert, Testfälle aus use cases
abgeleitet -> erledigt

big picture aufzeigen, Zusammenspiel erläutern -> auf gutem Wege, kann mit
einem zusätzlichen Klassendiagramm vervollständigt werden

Technologien nachvollziehbar beschreiben, insbesondere Zusammenspiel der
Komponenten (JSON, QT, Python, binary, Umgebungsvariablen -> nochmals
nachfragen

Variantendiskussion -> nochmals prüfen

Entscheid, Begründung des Lösungswegs -> noch verfeinern, Bedeutung open
source Projekt dabei hervorheben, doing

Detailkonzept mit techn. Plan -> doing, insbesondere die Zuordnung,
Abstimmung der Klassen, Funktionen in den entsprechenden SW Modulen

SW Design mit einem «Klassendiagramm» über verwendete Module, Klassen,
Schnittstellen, Input Output am Schluss der Realisierung fertig darstellen,
verwendete Module beschreiben, wird im Nachhinein abgebildet -> doing

Konsistente Darstellung von Testfällen und deren Durchführung, auch in Bezug
zu den Muss- und effektiv realisierten Kannzielen -> doing

\subsubsection*{Realisierung:}
\label{sec:org340ef25}

Realisierung mit Linux System Python Skript und QT Framwork -> erledigt

Konfiguration aus dem GUI wird als Plain Text neu erstellt, Passwort als
Plaintext gespeichert, wird jedoch beim Aufruf dem Binary nicht mitgegeben,
da dies in einer Umgebungsvariable definiert wird -> erledigt

Bau und Erläuterung der Testumgebung -> doing

Entwicklung basiert auf Python, mit eigen erstellten Realisierungselementen,
welche nicht einem Standardaufbau entsprechen -> diese kurz erläutern,
Codeausschnitte einbauen und mit referenzierter Quelle ergänzen -> doing

Implementation der DB als Kannziel, Logging als Kannziel, direkte
Integration in DB wäre wünschenswert -> nochmals nachfragen

Fehlerbehandlungen erfolgen nur an einer Stelle, entweder direkt über
vorhandenes Backup Binary oder neu über das erstellte GUI -> doing

Berechtigungsprobleme (z.B. bei include-Verzeichnissen) werden nicht
speziell behandelt, Verarbeitung wird übersprungen -> doing

allg. gültige Umgebungsvariablen verwenden -> doing

Netzwerk Prüfung erfolgt via Port Check auf Ziel IP, wo Repository drauf
läuft -> doing

geplanter Abschluss der Programmierung 2. März -> doing

\subsubsection*{Ausblick:}
\label{sec:orge31e851}

kritische Würdigung, lessons learned

Weiterverwendung als openSource Projekt für angedachte Weiterentwicklungen

Bewertung der Risiken anhand der eigenen Lösung -> Rückmeldung gegeben

Projektabschluss mit Überprüfung der Ziele, anhand des DA Antrags resp.
Pflichtenheftes

\subsection*{Nächstes Treffen}
\label{sec:org603308d}

nächstes Treffen am 3.3, 14 Uhr in Olten

noch unvollständig: nichts

\section*{Meeting vom 02.03.2019}
\label{sec:orga10f177}

Protokoll der 3. Besprechung

Treffpunkt: IBZ Aarau

Datum: 26.1.2019, 14:00 Uhr - 15:00 Uhr

\subsection*{Ablauf}
\label{sec:orgf598b1e}

Kurze Einleitung mit Smalltalk.
Erkundigung nach Stand der Arbeit und Besprechung der noch offenen Punkte.
Sind soweit alle erfüllt.
Analye könnte um Funktionen von Borg erweitert werden. -> Roter Faden fehlt
noch ein bisschen.

Ansonsten soweit gut auf Kurs noch finalisieren und dann die digitale Abgabe
wie beim ersten Meeting besprochen.
\end{document}
%%% Local Variables:
%%% mode: latex
%%% TeX-master: t
%%% End: