437 lines
14 KiB
TeX
437 lines
14 KiB
TeX
|
% 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:
|