mirror of
https://github.com/fhswf/aki_prj23_transparenzregister.git
synced 2025-08-14 14:29:31 +02:00
deploy: c2952ce52edd40580d7e7f3eadd53392e3140498
This commit is contained in:
147
html/_sources/Pflichtenheft.md.txt
Normal file
147
html/_sources/Pflichtenheft.md.txt
Normal file
@@ -0,0 +1,147 @@
|
||||
# Pflichtenheft: Kapitalgesellschaften referenzregister
|
||||
|
||||
Version 0.1 Erstellt am 07.04.2023
|
||||
|
||||
| Autoren | Matrikelnummer |
|
||||
|--------------------|----------------|
|
||||
| Kim Mesewinkel | 000 |
|
||||
| Tristan Nolde | 000 |
|
||||
| Sebastian Zelenie | 000 |
|
||||
| Philip Horstenkamp | 000 |
|
||||
| Sascha Zhu | 000 |
|
||||
| Tim Ronneburg | 000 |
|
||||
|
||||
|
||||
|
||||
|
||||
## Historie der Dokumentenversion <a name="historie"></a>
|
||||
|
||||
| Version | Datum | Autor | Änderungsgrund / Bemerkung |
|
||||
|-----------|------------|---------------|----------------------------------------|
|
||||
| 0.1 | 07.04.2023 | Tim Ronneburg | Initiales aufsetzen des Pflichtenhefts |
|
||||
| 0.2 | 000 | | |
|
||||
| ... | 000 | | |
|
||||
| 1.0 | 000 | | |
|
||||
|
||||
## Inhaltsverzeichnis <a name="inhaltsverzeichnis"></a>
|
||||
[Historie der Dokumentenversion](#historie)
|
||||
[Inhaltsverzeichnis](#inhaltsverzeichnis)
|
||||
1. [Einleitung](#einleitung)
|
||||
1. [allgemeines](#allgemeines)
|
||||
1. [Ziel und Zweck des Dokuments](#ziel/zweck)
|
||||
1. [Ausgangssituation](#ausgangssituation)
|
||||
1. [Projektbezug](#projektbezug)
|
||||
1. [Abkürzungen](#abkürzungen)
|
||||
1. [Schnittstellen/ Bezug zu anderen Dokumenten](#schnittstellen)
|
||||
1. [Konzept und Rahmenbedingungen](#konzept_und_rahmenbedingung)
|
||||
1. [Ziele des Anbieters](#ziele_anbieter)
|
||||
1. [Ziele und Nutzen des Anwenders](#ziele_anwender)
|
||||
1. [Benutzer / Zielgruppen](#benutzer/zielgruppen)
|
||||
1. [Systemvoraussetzungen (Optional)](#systemvoraussetzungen)
|
||||
1. [Ressourcen (Optional)](#ressourcen)
|
||||
1. [Funktionale Anforderungen](#f_anforderung)
|
||||
1. [F100](#f100)
|
||||
1. [Nicht-Funktionale Anforderungen](#nf_anforderung)
|
||||
1. [N100](#n100)
|
||||
1. [Anforderungsverfolgung zu den Spezifikationen](#verfolgung_spezifikation)
|
||||
1. [Abnahmekriterien und Vorgehen zur Ausgangsprüfung](#abnahmekriterien)
|
||||
1. [Lieferumfang](#lieferumfang)
|
||||
1. [Anhang / Ressourcen](#anhang/ressourcen)
|
||||
|
||||
|
||||
## Einleitung <a name="einleitung"></a>
|
||||
|
||||
### Allgemeines <a name="allgemeines"></a>
|
||||
|
||||
### Ziel und Zweck des Dokuments <a name="ziel/zweck"></a>
|
||||
|
||||
### Ausgangssituation <a name="ausgangssituation"></a>
|
||||
|
||||
### Projektbezug <a name="projektbezug"></a>
|
||||
|
||||
### Abkürzungen <a name="abkürzungen"></a>
|
||||
|
||||
### Schnittstellen/ Bezug zu anderen Dokumenten <a name="schnittstellen"></a>
|
||||
Test
|
||||
|
||||
## Konzept und Rahmenbedingungen <a name="konzept_und_rahmenbedingung"></a>
|
||||
|
||||
### Ziele des Anbieters <a name="ziele_anbieter"></a>
|
||||
|
||||
### Ziele und Nutzen des Anwenders <a name="ziele_anwender"></a>
|
||||
|
||||
### Benutzer / Zielgruppen <a name="benutzer/zielgruppen"></a>
|
||||
|
||||
### Systemvoraussetzungen (Optional) <a name="systemvoraussetzungen"></a>
|
||||
|
||||
### Ressourcen (Optional) <a name="ressourcen"></a>
|
||||
|
||||
|
||||
|
||||
## Funktionale Anforderungen <a name="f_anforderung"></a>
|
||||
|
||||
### **Muss Ziele**
|
||||
|
||||
### F100 <a name="f100"></a>
|
||||
Die Software berechnet und veranschaulicht folgende Unternehmenskennzahlen:
|
||||
- Umsatz
|
||||
- Gewinn
|
||||
- Bilanzsumme
|
||||
- Eigenkapital (Eigenkapitalquote)
|
||||
- Vorstand / Geschäftsführung
|
||||
- Aufsichtsrat / Beirat
|
||||
- Wirtschaftsprüfer
|
||||
- Besitzverhältnisse
|
||||
|
||||
### F110 <a name="f110"></a>
|
||||
Das System muss, neben den Kennzahlen von F100, die Metriken aus dem Anhang "data_and_metrics.md" je nach Datenlage für die Unternehmen berechnen und anzeigen.
|
||||
|
||||
### F120 <a name="f120"></a>
|
||||
Die Software muss eine Suche nach Unternehmen und Personen anbieten die zu einer Detailansicht führt mit den in F100 genannten Kennzahlen.
|
||||
|
||||
### **Soll Ziele**
|
||||
|
||||
### F200 <a name="f200"></a>
|
||||
Die Software veranschaulicht die Konzernstruktur (Mutterkonzern <-> Tochterfirmen). Diese sollen durch ein Netz transparent dargestellt werden.
|
||||
|
||||
### F210 <a name="f210"></a>
|
||||
Die Software zeigt die Beziehungen von Unternehmen untereinander und mit den Wirtschaftsprüfern auf. Diese sollen durch ein Netz transparent dargestellt werden.
|
||||
|
||||
### F220 <a name="f220"></a>
|
||||
Die Software soll bewerten ob die Berichtserstattung der letzten 7 Tage eher Positiv oder Negativ zu dem Unternehmen war. Dabei sind häufige Vorstandswechsel negativ und Zielerreichungen positiv.
|
||||
|
||||
## Nicht-Funktionale Anforderungen <a name="nf_anforderung"></a>
|
||||
|
||||
### **Muss Ziele**
|
||||
|
||||
### N100 <a name="n100"></a>
|
||||
Das System muss die 1000 größten deutschen und europäischen Unternehmen beinhalten. Diese werden anhand der Kennzahlen
|
||||
- Umsatz
|
||||
-
|
||||
-
|
||||
bewertet und bemessen.
|
||||
|
||||
### **Soll Ziele**
|
||||
|
||||
### N200 <a name="n200"></a>
|
||||
Das System ist 24/7 über das Internet für jede Person mit Internetzugang erreichbar.
|
||||
|
||||
### N210 <a name="n210"></a>
|
||||
Das System soll eine Verfügbarkeit von 99 % erreichen, mit maximal 10 Ausfällen pro Jahr.
|
||||
|
||||
### **Kann Ziele**
|
||||
|
||||
### N300 <a name="n300"></a>
|
||||
Das System kann möglichst über einen Disaster Recovery Schutz verfügen und in einem zweiten, 250 KM vom Hauptrechenzentrum entfernten Rechenzentrum die Systeme und Daten spiegeln.
|
||||
|
||||
### N310 <a name="n310"></a>
|
||||
Das System kann möglichst skalierbar sein, sodass auch eine Nutzerzahl von 1000 Benutzern die Software nutzen können.
|
||||
|
||||
|
||||
## Anforderungsverfolgung zu den Spezifikationen <a name="verfolgung_spezifikation"></a>
|
||||
|
||||
## Abnahmekriterien und Vorgehen zur Ausgangsprüfung <a name="abnahmekriterien"></a>
|
||||
|
||||
## Lieferumfang <a name="lieferumfang"></a>
|
||||
|
||||
## Anhang / Ressourcen <a name="anhang/ressourcen"></a>
|
@@ -0,0 +1,8 @@
|
||||
aki\_prj23\_transparenzregister.black\_test module
|
||||
==================================================
|
||||
|
||||
.. automodule:: aki_prj23_transparenzregister.black_test
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
:private-members:
|
@@ -0,0 +1,8 @@
|
||||
aki\_prj23\_transparenzregister.flake8\_test module
|
||||
===================================================
|
||||
|
||||
.. automodule:: aki_prj23_transparenzregister.flake8_test
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
:private-members:
|
20
html/_sources/aki_prj23_transparenzregister.rst.txt
Normal file
20
html/_sources/aki_prj23_transparenzregister.rst.txt
Normal file
@@ -0,0 +1,20 @@
|
||||
aki\_prj23\_transparenzregister package
|
||||
=======================================
|
||||
|
||||
Submodules
|
||||
----------
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 4
|
||||
|
||||
aki_prj23_transparenzregister.black_test
|
||||
aki_prj23_transparenzregister.flake8_test
|
||||
|
||||
Module contents
|
||||
---------------
|
||||
|
||||
.. automodule:: aki_prj23_transparenzregister
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
:private-members:
|
46
html/_sources/index.rst.txt
Normal file
46
html/_sources/index.rst.txt
Normal file
@@ -0,0 +1,46 @@
|
||||
.. Your Package Name documentation master file, created by Sphinx
|
||||
|
||||
Transparenzregister Documentation
|
||||
=================================
|
||||
This is the documentation for the AKI project group on the german transparenzregister and an Analysis there of.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 3
|
||||
:caption: Project planing
|
||||
|
||||
Pflichtenheft
|
||||
timeline.md
|
||||
|
||||
.. toctree::
|
||||
:glob:
|
||||
:maxdepth: 1
|
||||
:caption: Meeting Notes:
|
||||
|
||||
meeting-notes/*
|
||||
|
||||
.. toctree::
|
||||
:glob:
|
||||
:maxdepth: 3
|
||||
:caption: Research
|
||||
|
||||
research/*
|
||||
research/*.ipynb
|
||||
|
||||
.. toctree::
|
||||
:glob:
|
||||
:maxdepth: 0
|
||||
:caption: Modules
|
||||
|
||||
modules
|
||||
|
||||
.. automodule:: aki_prj23_transparenzregister
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
:inherited-members:
|
||||
:autodoc_member_order:
|
||||
|
||||
Indices and tables
|
||||
==================
|
||||
* :ref:`genindex`
|
||||
* :ref:`modindex`
|
62
html/_sources/meeting-notes/Meeting_2023-03-30.md.txt
Normal file
62
html/_sources/meeting-notes/Meeting_2023-03-30.md.txt
Normal file
@@ -0,0 +1,62 @@
|
||||
# Weekly *1*: 30.03.2023
|
||||
|
||||
## Teilnehmer
|
||||
- Prof. Arinir
|
||||
- Tristan Nolde
|
||||
- Tim Ronneburg
|
||||
- Philipp Horstenkamp
|
||||
- Kim Mesewinkel-Risse
|
||||
- Sascha Zhu
|
||||
- Sebastian Zeleny (Protokollant)
|
||||
|
||||
## Themen
|
||||
- **Inhalt des Project Proposals:**
|
||||
- Mit welchen Metriken können Unternehmen bewertet werden?
|
||||
- Was sind Kennzahlen von Kapitalgesellschaften?
|
||||
- Welche Daten werden benötigt?
|
||||
- Woher erhält man benötigte Daten? (Amtsgerichte --> Insolvenzen, Börsenkurse, Aktienkurse, RSS-Feeds von/zu Unternehmen)
|
||||
- Wie werden die Daten verarbeitet?
|
||||
- Wie können die Daten bzw. Ergebnisse präsentiert werden?
|
||||
- Verflechtungen zwischen Unternehmen: Geschäftsführer, Wirtschaftsprüfer
|
||||
|
||||
- **Anforderungen an Projektdurchführung:**
|
||||
- Backlog für Ideen und Aufgaben
|
||||
- Meeting-Notes mit besprochenen Themen, Entscheidungen, Terminen und Action-List (Wer arbeitet an welcher Aufgabe?)
|
||||
- Projektdurchführung so formal wie möglich, d.h.
|
||||
- Beschreibung des Systemkontexts: Interaktion mit der Umgebung
|
||||
- Datenmodell: schematische Darstellung der Datenflüsse
|
||||
- Lasten- / Pflichtenheft mit Kategorisierung
|
||||
- Vorschlag Frontend von Prof. Arinir: D3.js
|
||||
|
||||
- **Bewertung des Projekts:**
|
||||
- Es muss erkennbar sein, wer welche Aufgabe bearbeitet hat
|
||||
- Jeder Teilnehmer soll die Aufgaben der anderen Teilnehmer kennen und ein Verständnis für diese haben (kein tiefes Domänenwissen!)
|
||||
- Gesamtplanung und Dokumentation sind Teil das Ergebnis, nicht nur die technische Umsetzung
|
||||
- Bewertungsschlüssel:
|
||||
|
||||
| Gewichtung | Aufgabe |
|
||||
|--------------|---------------------------------------------|
|
||||
| 20% | Vortrag Seminararbeit |
|
||||
| 20% | Präsentation |
|
||||
| 30% | Implementierung |
|
||||
| 20% | Finaler Bericht (~15 Seiten pro Teilnehmer) |
|
||||
| 10% | Abschlusspräsentation |
|
||||
|
||||
- **Organisatorisches:**
|
||||
- Regeltermin alle 14 Tage mit allen Projektteilnehmern, beginnend am 30.03.2023: Dieser Termin soll für Sprint Planning und Review mit Prof. Arinir genutzt werden.
|
||||
- Was ist die Erwartungshaltung des Product Owners?
|
||||
- Welche Themen/Aufgaben werden bearbeitet?
|
||||
- Was ist das Ziel für das nächste Review?
|
||||
- Projektbearbeitung/Dokumentation mit Github
|
||||
- Bereitstellung des Github-Repos über FH
|
||||
|
||||
## Abgeleitete Action Items
|
||||
|
||||
| Action Item | Verantwortlicher | Deadline |
|
||||
|-----------------------------------------------------------------------------------------|--------------------|----------------------------------|
|
||||
| Welche Anforderungen / Erwartungen stellen wir inhaltlich und technisch an das Projekt? | alle | nächstes Weekly/work in progress |
|
||||
| Erarbeiten von Arbeitspaketen/Aufgaben aus Anforderungen | alle | nächstes Weekly/work in progress |
|
||||
| Welche Metriken sind notwendig? | alle | nächstes Weekly/work in progress |
|
||||
| Recherche zu Datenquellen | alle | nächstes Weekly/work in progress |
|
||||
| Definition von Meilensteinen | alle | nächstes Weekly |
|
||||
| Erstellung eines (groben) Zeitplans | alle | nächstes Weekly |
|
57
html/_sources/meeting-notes/Meeting_2023-04-13.md.txt
Normal file
57
html/_sources/meeting-notes/Meeting_2023-04-13.md.txt
Normal file
@@ -0,0 +1,57 @@
|
||||
# Weekly *2*: 13.04.2023
|
||||
|
||||
## Teilnehmer
|
||||
- Prof. Arinir
|
||||
- Tristan Nolde
|
||||
- Tim Ronneburg (Protokollant)
|
||||
- Philipp Horstenkamp
|
||||
- Kim Mesewinkel-Risse
|
||||
- Sascha Zhu
|
||||
- Sebastian Zeleny
|
||||
|
||||
## Themen
|
||||
|
||||
- **Seminarthemen:**
|
||||
- Themen die im Zuge der Implementierung erarbeitet werden
|
||||
- Themen:
|
||||
- Textmining (Ontologien)
|
||||
- Semantische Suche
|
||||
- Anmeldungsformular:
|
||||
- Jeder sendet das Formular selbst an Herrn Arinir
|
||||
- Projektauftakt: 30.03.2023
|
||||
- Enddatum: 15.02.2024
|
||||
- Titel: Transparanzregister Kapitalgeselschaften
|
||||
- **Vorstellung der Ergebnisse des letzten Sprints:**
|
||||
- Erstellung des GitHubs Projekts
|
||||
- Anlegen eines Protokolltemplates
|
||||
- Interne Meetings jeden Donnerstag
|
||||
- Timeline erstellt mit Mermaid.js in Markdown (Sebastian)
|
||||
- Recherche zum Datenschutz / Urheberrecht: Welche Daten aus den Datenbanken dürfen offline oder online benutzt werden. (Sascha)
|
||||
- Für die eigene Forschung: 75 % der Daten dürfen genutzt werden
|
||||
- 15 % Wenn es an Dritte weitergeleitet werden
|
||||
- Wenn wir die Ergebnisse veröffentlichen müssen die Vorgaben der Datenbanken beachten
|
||||
- Hinweis von Herrn Arinir: Das ist als Vorschungsprojekt zu sehen
|
||||
- Die Ergebnisse werden nicht veröffentlicht
|
||||
- nur die Vorgehensweise wird als Paper veröffentlicht
|
||||
- Recherche zu Unternehmenskennzahlen (Kim)
|
||||
- Hinweis: Für Tendenzanalysen sollen zeitliche Veränderungen erfasst werden (Timescale Datenbank)
|
||||
- Vierteljährliche Daten reichen aus
|
||||
- Recherche zu den verfügbaren Datengrundlagen (Phillip und Tristan)
|
||||
- Anlegen eines Pflichtenhefts mit den Anforderungen an das Projekt (Tim)
|
||||
- **Organisatorisches:**
|
||||
- Es muss noch ein Projekt angelegt werden für das GitHub Repository mit einem Board zur Projektorganisation
|
||||
- Im Meeting erledigt
|
||||
- **Recherche:**
|
||||
- Nicht nur auf Kennzahlen eingehen, sondern auch auf die Berichterstattung eingehen
|
||||
- Dazu sollen die Technologieauswahl recherchiert werden (Trendanalyse von Nachrichten, Finanztreff, Twitter etc.)
|
||||
|
||||
## Abgeleitete Action Items
|
||||
|
||||
| Action Item | Verantwortlicher | Deadline |
|
||||
|-------------|------------------|-----------------|
|
||||
| Rechechieren welche Nachrichtenquellen (Aktuelle und "Alte" Nachrichten) genutzt werden können | Sascha und Tim | 27.04.2023 |
|
||||
| Recherchieren welche Technologien zur Auswertung der Nachrichtenqullen genutzt werden können (z.b. Sentiment Analyse) | Philipp und Kim | 27.04.2023 |
|
||||
| Beschäftigen mit Historien (Timescale Datenbank) | Tristan und Sebastian | 27.04.2023 |
|
||||
| Festlegen von Kriterien wann ein Artikel positiv oder negativ zu bewerten ist | Sascha | Ende offen |
|
||||
| Abgabe des Anmeldeformulars zum Projekt | alle | 20.04.2023 |
|
||||
| Liste mit geeignetetn Metriken | Herr Arinir | 27.04.2023 |
|
54
html/_sources/meeting-notes/Meeting_2023-05-04.md.txt
Normal file
54
html/_sources/meeting-notes/Meeting_2023-05-04.md.txt
Normal file
@@ -0,0 +1,54 @@
|
||||
# Weekly *3*: 04.05.2023
|
||||
|
||||
## Teilnehmer
|
||||
- Prof. Arinir
|
||||
- Tristan Nolde
|
||||
- Tim Ronneburg
|
||||
- Phillip Horstenkamp
|
||||
- Kim Mesewinkel-Risse
|
||||
- Sascha Zhu
|
||||
- Sebastian Zeleny
|
||||
|
||||
## Themen
|
||||
|
||||
### Organisatorische Absprachen:
|
||||
|
||||
Gelten die Seminarthemen als Zwischenprüfung? In welcher Form?
|
||||
- Herr Giefers hat Seminarthemen im Vorfeld definiert, in unserer Gruppe gab es eine offene Einarbeitung in die Forschungs- und Entwicklungsarbeit
|
||||
- Geplanter Umfang: Seminararbeit 15-20 Seiten (Rücksprache mit Herrn Giefers und Herrn Gawron durch Herrn Arinir, Feedback beim nächsten Termin) und Vortrag mit Folien oder anderen Quellen (z.B. Quellcode) ca. 15-20 Minuten im Rahmen eines JF Termins (keine Vorstellung im Plenum)
|
||||
- Die Seminararbeiten werden benotet (20% der Endnote), die Ausarbeitung und der Vortrag zählen dabei zu jeweils 50%
|
||||
|
||||
|
||||
Wie lautet der zeitliche Rahmen?
|
||||
- Keine feste Deadline vorgegeben, Absprache innerhalb der Projektgruppe ausreichend
|
||||
- Vortrag: Einigung auf zwei Termine Ende Juni/Anfang Juli -> Thema 1-3 am 22.06.2023 und Thema 4-6 am 06.07.2023
|
||||
- Seminararbeit: Abgabe voraussichtlich Ende des Sommersemesters, potentiell auch zu einem späteren Zeitpunkt möglich
|
||||
|
||||
|
||||
Welche Themenbereiche sollen behandelt werden?
|
||||
- Die erste kurze Beschreibung der 6 Themenbereiche/Domänen wurde durch Herrn Arinir als positiv befunden
|
||||
- Zur Eingrenzung der Themen und für ein konkreteres Feedback soll für jeden Themenbereich beim nächsten JF am 11.05.2023 ein Abstract vorgestellt werden
|
||||
- Grundsätzlich sollen die Themen nicht zu oberflächlich behandelt werden, sondern explizit auf Techniken zur Umsetzung eingegangen werden
|
||||
|
||||
|
||||
Einigung auf Änderungen im Bereich Projektorganisation:
|
||||
- Aufnahme des zeitlichen Ablaufs der Tickets in die Meeting Notes -> Screenshot des Projects in Protokoll mit aufnehmen
|
||||
- Start-, Enddaten und Labels der Tickets besser pflegen
|
||||
|
||||
|
||||
Sonstiges:
|
||||
- Urlaubszeiten Herr Prof. Arinir: 17.07.-01.08.2023
|
||||
|
||||
|
||||
|
||||
## Abgeleitete Action Items
|
||||
|
||||
| Action Item | Verantwortlicher | Deadline |
|
||||
|-------------|------------------|-----------------|
|
||||
| Abstract pro Thema | Alle | nächstes Weekly |
|
||||
| Folienvorlage für den Seminarvortrag | Alle | nächstes Weekly |
|
||||
| Rückmeldung zum Umfang der Seminararbeit | Prof. Arinir | nächstes Weekly |
|
||||
|
||||
|
||||
## Aktueller Projektstand
|
||||

|
117
html/_sources/meeting-notes/Meeting_2023-05-11.md.txt
Normal file
117
html/_sources/meeting-notes/Meeting_2023-05-11.md.txt
Normal file
@@ -0,0 +1,117 @@
|
||||
# Weekly *4*: 11.05.2023
|
||||
|
||||
## Teilnehmer
|
||||
- Prof. Arinir
|
||||
- Tristan Nolde
|
||||
- Tim Ronneburg
|
||||
- Phillip Horstenkamp
|
||||
- Kim Mesewinkel-Risse
|
||||
- Sascha Zhu
|
||||
- Sebastian Zeleny
|
||||
|
||||
## Themen
|
||||
|
||||
### Organisatorische Absprachen zum Umfang und Inhalt der Seminararbeit:
|
||||
|
||||
- Herr Arinir wird sich nochmal wegen des Umfangs der Seminararbeit bei unserer Gruppe melden
|
||||
- In der Seminarbeit sollen Anforderungen und Lösungsskizzen für das Projekt "Transparenzregister" dargestellt werden.
|
||||
- Die Seminarabeit soll aus einem theoretischen Teil und einem praktischen Teil, in dem der praktische Nutzen für das Projekt "Transparenzregister" erörtert wird, bestehen; ob das Verhältnis zwischen dem theoretischen und praktischen Teil bei 50:50 oder 40:60 liegt, darüber können die Verfaser der Seminararbeit selbst entscheiden
|
||||
- Der Fokus der Seminarbeit soll stets danach ausgerichtet werden, wie die entsprechenden Aspekte bzw. die entsprechenden Technologien für das Projekt "Transparenzregister" genutzt werden können.
|
||||
|
||||
|
||||
|
||||
### Vorstellung des Abstracts der Seminararbeit zu "Dev Ops" (Philipp Horstenkamp):
|
||||
|
||||
Abstract siehe Datei in github.
|
||||
|
||||
Folgende Punkte wurden bei bzw. nach der Vorstellung des Abstracts diskutiert:
|
||||
|
||||
- Eine sehr straffe Pipeline, die für Seriensoftware in Ordnung wäre, könnte uns für unser Projekt zu sehr „fesseln“ bzw. einschränken.
|
||||
- Es wäre zu überlegen, ob die Software-Entwicklung, wie diese früher ablief, mit der Software-Entwicklung von heute (u.a. mit den Automatisierungsmöglichkeiten von heute) gegenübergestellt werden soll, um daraus zunächst eine Strategie für unser Projekt zu entwickeln, bevor man sich vertieft mit DevOps beschäftigt
|
||||
- Die Verwendung von CI/CD (Continuous Integration/Continuous Delivery)-Pipelines für KI-Projekte wäre ein interessantes Thema.
|
||||
|
||||
|
||||
|
||||
### Vorstellung des Abstracts der Seminararbeit zu "Automatisierte Datenextraktion aus Internetquellen als Grundlage für die Analyse von Kapitalgesellschaften" (Tristan Nolde):
|
||||
|
||||
Abstract siehe Datei in github.
|
||||
|
||||
Folgende Punkte wurden bei bzw. nach der Vorstellung des Abstracts diskutiert:
|
||||
|
||||
- Pros und Cons von WebScraping gegenüber RSS-Feeds und gegenüber der API-Lösung sollen dargestellt werden
|
||||
- Die Quelle E-Mail-Newsletter (z.B. vom Handelsblatt) könnte ebenfalls interessant sein, jedoch muss hierfür möglicherweise ein separater E-Mail-Account erstellt werden, was eher aufwändig ist
|
||||
- Es wäre eventuell zu prüfen, ob auch Daten aus LinkedIn API, XING oder Facebook extrahiert werden könnten.
|
||||
|
||||
|
||||
|
||||
### Vorstellung des Abstracts der Seminararbeit zu "Datenspeicherung" (Sebastian Zeleny):
|
||||
|
||||
Abstract siehe Datei in github.
|
||||
|
||||
Folgende Punkte wurden bei bzw. nach der Vorstellung des Abstracts diskutiert:
|
||||
|
||||
- Bei der Wahl der Datenbank müssen verschiedene Anforderungen berücksichtigt werden, mit hohem Abstimmungsbedarf zwischen den Topics "Datenextraktion" und "Datenvisualisierung"
|
||||
|
||||
- Herr Prof. Arinir fragte noch, ob wir das Thema "relationale Datenbanken" als Modul behandelt haben. Dies wurde bejaht, insbesondere SQL Datenbanken und SQL queries waren Gegenstand des Moduls "Datenbankprogrammierung"
|
||||
|
||||
|
||||
|
||||
### Vorstellung des Abstracts der Seminararbeit zu "Verpflechtungsanalyse" (Tim Ronneburg):
|
||||
|
||||
Abstract siehe Datei in github.
|
||||
|
||||
Folgende Punkte wurden bei bzw. nach der Vorstellung des Abstracts diskutiert:
|
||||
|
||||
- Beim Social Graph wäre zu überlegen, nicht nur Beziehungen zwischen Unternehmen via Personen (z.B. Wirtschaftsprüfer), sondern auch Beziehungen zwischen Unternehmen via Kooperationspartner (Stiftungen, Unis, Forschungsinstitute) bzw. Eigentums-, Kunden- und Lieferbeziehungen darzustellen
|
||||
|
||||
- Beim Social Graph wäre zu überlegen, ob man nach Art der Beziehung filtern könnte
|
||||
|
||||
|
||||
|
||||
### Vorstellung des Abstracts der Seminararbeit zu "Text Mining" (Sascha Zhu):
|
||||
|
||||
Abstract siehe Datei in github.
|
||||
|
||||
Folgende Punkte wurden bei bzw. nach der Vorstellung des Abstracts diskutiert:
|
||||
|
||||
- Bei den Sentiment-Analyse-Tools wie FinBERT oder VADER wäre stets eine maschinelle Übersetzung der deutschen Nachrichtentexte ins Englische erforderlich, da FinBERT oder VADER keine deutschen Texte erkennen können
|
||||
- Die Generierung von Ontologien ist zu komplex und soll nicht Gegenstand der Projektarbeit sein
|
||||
- Bei der semantischen Textanalyse wäre empfehlenswert, dass dies über "Einzel-Personen" ausgeführt wird (das wäre dann ein Punkt im Graphen)
|
||||
- Das Thema "Named Entity Recognition" wird für die Projektarbeit eine hohe Bedeutung haben
|
||||
|
||||
|
||||
|
||||
### Vorstellung des Abstracts der Seminararbeit zu "Datenvisualisierung" (Kim Mesewinkel-Risse):
|
||||
|
||||
Abstract siehe Datei in github.
|
||||
|
||||
Folgende Punkte wurden bei bzw. nach der Vorstellung des Abstracts diskutiert:
|
||||
|
||||
- Bei der Datenvisualisierung wäre zu überlegen, dass man sich nur auf Python-Bibliotheken beschränkt
|
||||
- Die Datenabfrage könnte über SQL oder Spark laufen, eine Schnittstelle zwischen dem Speicher und dem Front-End wird benötigt
|
||||
- Zwischen Daten und der Datenvisualisierung werden eventuell Zwischen-Caches benötigt
|
||||
- Bezüglich der Frage nach der „Middleware“: Wenn Plotly oder Plotly Dash verwendet wird, wird keine Middleware benötigt, da dies schon eingebaut ist.
|
||||
|
||||
|
||||
|
||||
### Feedback von Herrn Prof. Arinir:
|
||||
|
||||
- Es scheint noch kein Gesamtkonzept für das Gewerk vorzuliegen.
|
||||
- Wir sollten uns die Frage stellen: Was soll am Ende für "ein brauchbares Stück Software" herauskommen, damit der Anwender mit der Vielzahl von Informationen und Funktionen zurechtkommt.
|
||||
- Eine Lösungsskizze muss definiert werden, wobei ein Pflichtenheft jetzt noch nicht erforderlich ist
|
||||
- Es sollen zunächst einige GUI-Designs (mit einem Muster-Datensatz) entwickelt werden.
|
||||
- Pros und Cons zwischen einem Wasserfallmodell (Pflichtenheft mit bis zu 1000 Seiten) und der agilen Modellierung sollen berücksichtigt werden.
|
||||
- Wie sollen die Verflechtungen eingebaut werden?
|
||||
- Wie sollen die Daten persistiert werden?
|
||||
- Es wäre empfehlenswert, mit irgendetwas (d.h. einer kleinen Lösung) anzufangen, dann das Ergebnis anzuschauen, und diese kontinuierlich zu verbessern.
|
||||
|
||||
|
||||
|
||||
## Abgeleitete Action Items
|
||||
|
||||
| Action Item | Verantwortlicher | Deadline |
|
||||
|--------------------------------------------|------------------|-------------------|
|
||||
| GUI Designs | Alle | nächstes Weekly |
|
||||
| Rückmeldung zum Umfang der Seminararbeit | Prof. Arinir | nächstes Weekly |
|
||||
|
||||
## Aktueller Projektstand
|
33
html/_sources/meeting-notes/Meeting_2023_05-25.md.txt
Normal file
33
html/_sources/meeting-notes/Meeting_2023_05-25.md.txt
Normal file
@@ -0,0 +1,33 @@
|
||||
# Weekly *5*: 25.05.2023
|
||||
|
||||
## Teilnehmer
|
||||
- Prof. Arinir
|
||||
- Tristan Nolde
|
||||
- Tim Ronneburg
|
||||
- Philipp Horstenkamp
|
||||
- Kim Mesewinkel-Risse
|
||||
- Sascha Zhu
|
||||
- Sebastian Zeleny
|
||||
|
||||
## Themen
|
||||
|
||||
- Nächster Termin am 08.06.2023 ist Fronleichnam => Verschoben auf 09.06.2023 09:00
|
||||
- Sebastian präsentiert das Miro Bord mit den Wireframediagrammen. [Siehe Anlage]()
|
||||
- Philipp präsentiert den Sozial graph
|
||||
- Sebastian präsentiert die Unternehmensdetails in sicht auf die Kennzahlen
|
||||
- Sebastian dankt Kim für das Überarbeiten der Graphen im Farbschema
|
||||
- Sebastian zeigt die anderen Übersichten
|
||||
- Sascha weist darauf hin das zusätzlich noch das Quellmaterial für die Stimmungen mit angezeigt werden sollen.
|
||||
- Die Form ist bisher noch unklar.
|
||||
|
||||
- Arinir: Auch indirekte verpflächtungen für N sprünge sollen bei den Details angezeigt werden und einen wert für den Einfluss von personen und Firmen sein.
|
||||
- Zähle die Personenverbindungen juristisch/Natürlich getrennt nach den schichten der Indirektion. Interessant wäre eine auftrennung der natürlichen und Jiristischen personen in der Zählung
|
||||
- Ranking der Personen nach Anzahl der Verbindungen
|
||||
|
||||
- Die Frage wie wir zeitliche veränderungen im sozial graph bewerten sollen kam auf. Wurde aber noch nicht abschließend beantwortet.
|
||||
|
||||
## Abgeleitete Action Items
|
||||
|
||||
| Action Item | Verantwortlicher | Deadline |
|
||||
|------------------------------------------|------------------|-----------------|
|
||||
| Erster entwurf der Seminarpräsentationen | Alle | nächstes Weekly |
|
7
html/_sources/modules.rst.txt
Normal file
7
html/_sources/modules.rst.txt
Normal file
@@ -0,0 +1,7 @@
|
||||
aki_prj23_transparenzregister
|
||||
=============================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 4
|
||||
|
||||
aki_prj23_transparenzregister
|
40
html/_sources/research/RE_Vom-Problem-zur-Loesung.md.txt
Normal file
40
html/_sources/research/RE_Vom-Problem-zur-Loesung.md.txt
Normal file
@@ -0,0 +1,40 @@
|
||||
# Von der Problemstellung zum Lösungskonzept
|
||||
Um ein Softwaresystem für das Transparenzregister implementieren zu können, ist es notwendig Anforderungen zu formulieren. Diese legen die Eigenschaften der Software fest und werden benötigt, um die fachliche und technische Lösung zu modellieren / entwerfen und ein Produkt zu implementieren.
|
||||
|
||||
Zu Beginn sind die Anforderungen wenig eingeschränkt ("Benötigt wird eine Möglichkeit Daten zu speichern."), im Verlauf der Modellierung wird der Lösungsraum eingeschränkt ("Es bietet sich eine Datenbanklösung oder Dateiablage an.") und abschließend auf eine zu implementierende Lösung festgelegt ("Die Software verwendet ein relationales Modell unter Verwendung einer SQLite Datenbank.").
|
||||
|
||||
## Requirements Engineering Transparenzregister
|
||||
Unser Weg zum Pflichtenheft und zur Spezifikation der Systemanforderungen ist folgend dargestellt.
|
||||
Von unspezifizierten Anforderungen werden wir immer konkreter und beantworten iterativ die Fragen *Was ist das Problem/Anforderung?* und *Wie lösen wir das Problem/Anforderung?*.
|
||||
|
||||
### 1. Anforderungen aus Projektvorstellung
|
||||
|
||||
- Entwicklung einer Software zur Darstellung von Unternehmenskennzahlen und Verbindungen.
|
||||
- Ermittlung der 100 größten deutschen und europäischen Unternehmen
|
||||
- Auswahl geeigneter Metriken
|
||||
- Auswahl geeigneter Quellen
|
||||
- Die erhobenen Daten müssen visualisiert werden (evtl. durch ein Netz, wenn es Verbindungen sind)
|
||||
- Die erhobenen Daten müssen nach Unternehmen und Personen durchsuchbar sein.
|
||||
|
||||
### 2. Identifikation von Anforderungen innerhalb der Gruppe
|
||||
|
||||
- Es werden Datenquellen benötigt, um Unternehmenskennzahlen ermitteln zu können.
|
||||
- Es werden Datenquellen benötigt, um über die öffentliche Darstellung der Unternehmen zu erfahren.
|
||||
- Es werden Werkzeuge benötigt, um Sentimentanalyse über Unternehmen durchzuführen.
|
||||
- Die rechtmäßige Verwendung der Daten muss geklärt werden.
|
||||
- Die ermittelten Daten müssen gespeichert werden.
|
||||
- Es werden Werkzeuge benötigt, um Text Mining zu betreiben.
|
||||
|
||||
### 3. Identifikation von Domänen zur Lösungsfindung
|
||||
Aus den Anforderungen der Projektvorstellung und der Projektgruppe wurden sechs Domänen identifiziert, welche benötigt werden, um ein Softwaresystem für Transparenzregister zu erarbeiten.
|
||||
Um das benötigte Domänenwissen zu vertiefen, bearbeitet jedes Mitglied ein Cluster.
|
||||
|
||||
### 4. technische/fachliche Lösungen
|
||||
Mit dem Domänenwissen können technische und fachliche Lösungen definiert werden ("Zur Datenspeicherung von Unternehmenskennzahlen ist *xy* notwendig, weil *abc*.") und erste Modelle (z.B. GUI-Modell) erstellt werden.
|
||||
|
||||
### 5. Priorisierung von Anforderungen
|
||||
Die Gruppe diskutiert die Anforderungen und legt eine Priorisierung fest.
|
||||
|
||||
### 6. Pflichtenheft
|
||||
Das Team legt sich mit dem Pflichtenheft auf einen definierten Umfang und konkrete Inhalte der Lösung fest. Es wird in *Muss-* und *Kann-*Anforderungen unterschieden.
|
||||
Das Pflichtenheft ist das **Project Proposal**.
|
62
html/_sources/research/Timeseries/Overview.md.txt
Normal file
62
html/_sources/research/Timeseries/Overview.md.txt
Normal file
@@ -0,0 +1,62 @@
|
||||
# Timeseries (deutsch: Zeitreihen) im Kontext des Transparenzregisters Kapitalgesellschaften
|
||||
|
||||
## Leitfragen
|
||||
1. Was zeichnet Timeseries Daten aus?
|
||||
2. Wie werden Timeseries effizient gespeichert?
|
||||
3. Welche Daten sind für den vorstehenden Use Case relevant und wie werden diese möglichts optimal (gemäß Software Qualitätskriterien wie Skalierbarkeit u.ä.) modelliert?
|
||||
4. Passt die Struktur und Handhabung von Timeseries Daten auf den Use Case?
|
||||
5. Wo können die benötigten Daten abgerufen werden?
|
||||
6. Wie könnte ein beispielhafter Datensatz (ggf. in Form eines Pandas DataFrames) aussehen?
|
||||
|
||||
## Timeseries
|
||||
Hinter Timeseries (oder Zeitreihen) verbergen sich Datenpunkte meistens numerischer Natur aber auch andere Datentypen sind möglich, die Werte einer Kennzahl oder Entität entlang der Zeit-Achse darstellen. Nennenswerte Beispiele sind die Herzfrequenz eines Menschen sowie Aktienkurse börsennotierter Unternehmen. Es wird generell zwischen `Metriken` (engl.: Metrics; bei regelmäßigem Intervall) und `Ereignissen` (engl.: Events; bei unregelmäßigen Intervallen) unterschieden.
|
||||
|
||||
--<cite>vgl. [influxdata - What is time series data?](https://www.influxdata.com/what-is-time-series-data/)
|
||||
|
||||
Einige zentrale Eigenschaften von Daten, die als Zeitreihen modelliert werden, sind:
|
||||
1. `Unveränderbarkeit` (engl.: Immutability):
|
||||
Da Zeitreihen in der Regel in zeitlicher Reihenfolge aufgenommen werden, werden sie normalerweise lediglich an die bestehende Reihe angehangen und nachträglich nicht mehr angepasst. Der entscheidende Identifikator des Datensatzes besteht dabei aus dem Zeitstempel (engl.: Timestamp) sowie der zugeordneten Entität (z.B. einem Sensor). Andere Features, die als Primärschlüssel fungieren können, sind nicht vorgesehen.
|
||||
2. `Lebensdauer` (engl.: Retention policy):
|
||||
Da Zeitreihen in hoher Frequenz geschrieben aber mit höherem Alter seltener gelesen werden, ist es üblich alte Daten zu löschen bzw. aggregiert zu speichern, um langfristig Speicher zu sparen.
|
||||
3. `Aggregation` (engl.: Aggregation):
|
||||
In den meisten Use Cases werden nicht alle Daten gleichzeitig oder nur einzelne Datensätze sondern Werte eines definierten Zeitraumes abgefragt und häufig aggregiert (z.B. als Summe oder Durchschnitt) zurückgegeben.
|
||||
4. `Hohes Schreib- zu Lese-Verhältnis` (engl.: High write/read ratio):
|
||||
Timeseries Daten werden in der Regel in hoher Frequenz (kurzen Intervallen) geschrieben jedoch nur gelegentlich bzw. wie in Punkt 3 angemerkt aggregiert abgerufen, so dass schreibende Zugriffe zur Datenbank die lesenden an Volumen übertreffen.
|
||||
|
||||
<cite>-- vgl. [TDengine - Characteristics of Time-Series Data](https://tdengine.com/tsdb/characteristics-of-time-series-data/)
|
||||
|
||||
## Modellierung relevanter Kennzahlen
|
||||
|
||||
### Ist die Timeseries Modellierung für den Use Case geeignet?
|
||||
Die im Rahmen der vorher durchgeführten Analyse von für den Use Case [relevanten Unternehmenskennzahlen](../data_and_metrics.md) zeichnen sich durch ein Merkmal aus: sie basieren auf einer jährlich bis maximal jedes Quartal aufgestellten Kennzahl wie den Gewinn oder Umsatz des Unternehmens. Daraus resultiert eine für Zeitreihen geringe Datenfrequenz - üblich sind hier minütlich bis unter sekündlich geschriebene Daten.
|
||||
|
||||
Des Weiteren ist jeder Datensatz nicht nur an die Zeit-Achse sondern eine weitere Entität wie einen Quartals oder Jahresabschluss gebunden. Dies spiegelt nicht nur in der Berechnung der Kennzahl für ein einzelnes Unternehmen sondern auch den Vergleich zwischen Mehreren wieder: Hier ist es möglich, dass Unternehmen ihre Ergebnisse zu unterschiedlichen Zeiten aber den selben Ereignissen veröffentlichen. Immerhin ist es realistisch, dass ein Unternehmen seinen Jahresabschluss deutlich früher als ein anderes der Öffentlichkeit zur Verfügung stellt. So eine Abfrage ließe sich zwar durchaus über die Einführung einer zeitlichen Einschränkung filtern, jedoch ist auch hier die Verknüpfung zu einem Jahres- oder Quartalsabschluss von höherem Interesse.
|
||||
|
||||
In Folge dessen eignet sich eine Zeitreihen basierte Modellierung nicht für die zentralen Unternehmenskennzahlen.
|
||||
|
||||
Für die Speicherung und Verwaltung von Aktienkursen börsennotierter Unternehmen - folglich nicht aller Kapitalgesellschaften, die im Use Case behandelt werden - bietet sich der Einsatz einer Timeseries Datenbank jedoch durchaus an, da Daten hier nicht nur in sehr hoher Frequenz geschrieben sondern auch im bekannten Muster abgefragt werden. Demzufolge mag sich eine Modellierung auf Basis der `Polyglot persistence` (Verwendung verschiedener Datenspeicherungs Technologien) auf Gesamtsicht eignen, so dass Kennzahlen sowie Stammdaten von Unternehmen in einer relationalen DB gespeichert und abhängig ihrer Unternehmensform mit Aktiekursen aus einer Timeseries DB angereichert werden.
|
||||
|
||||
Dieser Ansatz wäre nicht nur für diese Anforderung lohnenswert, sondern kann auch die effiziente Speicherung der Unternehmensverflechtungen vereinfachen, da für diesen Anwendungszweck eine Graphen-Datenbank ins Spiel gebracht werden könnte, die die Relationen zwischen Unternehmen und Unternehmen leicht traversierbar speichert. Es ist daher auch abzuwägen, ob diese nicht auch die Aufgaben des relationalen Modells übernehmen könnte, um die Fülle anforderungsspezifischen DB Technologien zu reduzieren, um auch so die Komplexität des Gesamtsystem gering zu halten.
|
||||
|
||||
Um einen geeigneten Zugang zu den Daten von extern (z.B. der Datenvisualisierungs-Schicht in Form einer Web App) zu ermöglichen, ist der Einsatz von `GraphQL` sinnvoll. Dies ermöglicht dem Client die gesamte Datenbasis zu durchforsten und den benötigten Datenbestand abzufragen. Der ``GraphQL`` Server kann dabei durch seine `Resolver` Struktur problemlos mehrere Datenquellen (siehe oben angesprochene `Polyglot Persistence`) kombinieren.
|
||||
|
||||
### Überblick über Datenrelationen
|
||||
|
||||
```mermaid
|
||||
|
||||
erDiagram
|
||||
Kapitalgesellschaft ||--o{ Jahresabschluss : veroeffentlicht
|
||||
Wirtschaftspruefer ||--o{ Jahresabschluss : prueft
|
||||
Jahresabschluss ||--o{ Metriken : beinhaltet
|
||||
Kapitalgesellschaft ||--o{ Branche : operiert_in
|
||||
Person ||--o{ Vorstand : agiert_als
|
||||
Person ||--o{ Wirtschaftspruefer : agiert_als
|
||||
Vorstand ||--o{ Kapitalgesellschaft: leitet
|
||||
|
||||
Kapitalgesellschaft {
|
||||
}
|
||||
Branche {
|
||||
}
|
||||
Jahresabschluss {
|
||||
}
|
||||
```
|
190
html/_sources/research/data_and_metrics.md.txt
Normal file
190
html/_sources/research/data_and_metrics.md.txt
Normal file
@@ -0,0 +1,190 @@
|
||||
# Daten und Kennzahlen von Unternehmen
|
||||
|
||||
|
||||
## Basisdaten der Firma
|
||||
* Name
|
||||
* Sitz
|
||||
* Rechtsform bzw. Art der Kapitalgesellschaft (AG, KGaA, GmbH, UG)
|
||||
* Branche
|
||||
* Gründungsdatum
|
||||
|
||||
|
||||
## Personen
|
||||
* Gesellschafter/innen (Verteilung der Anteile, Höhe der Anteile)
|
||||
* Geschäftsführung bzw. Vorstand (Vorsitzende/r, Stellvertretung, weitere)
|
||||
* Aufsichtsrat (Vorsitzende/r, Stellvertretung, weitere)
|
||||
* Wirtschaftsprüfung (Unternehmen, verantwortliche/r Wirtschaftsprüfer/in)
|
||||
|
||||
Im Fall von realen Personen könnte die eindeutige Identifikation schwierig sein. Hier wären neben dem Nachnamen auch der Vorname wünschenswert.
|
||||
|
||||
|
||||
## Bewertung der Größe der Kapitalgesellschaft
|
||||
*Nach HGB §267: https://www.gesetze-im-internet.de/hgb/__267.html*
|
||||
* Durchschnittliche Mitarbeiterzahl (Anzahl beschäftigte Arbeitnehmer am 31.03., 30.06., 30.09., 31.12.)
|
||||
* Bilanzsumme bzw. Gesamtkapital
|
||||
* Umsatz bzw. Umsatzerlöse
|
||||
|
||||
|
||||
## Kennzahlen bei Aktiengesellschaften
|
||||
*Angelehnt an https://www.tagesschau.de/wirtschaft/boersenkurse/ und https://boerse.de*
|
||||
* ISIN (International Securities Identification Number)
|
||||
* WKN (Wertpapierkennnummer)
|
||||
* Aktienkurs
|
||||
* Währung
|
||||
* Gewinn je Aktie
|
||||
* Dividende
|
||||
* Dividendenrendite
|
||||
* Ausschüttungsquote = Dividende je Aktie / Gewinn je Aktie * 100
|
||||
* Marketkapitalisierung = Anzahl Anteilsscheine * Aktienkurs
|
||||
* Kurs-Gewinn-Verhältnis (KGV) = Aktienkurs / Gewinn pro Aktie
|
||||
* Kurs-Umsatz-Verhältnis (KUV) = Marktkapitalisierung / Umsatz
|
||||
* Kurs-Gewinn-Wachstumsverhältnis (PEG) = KGV / erwarteter Gewinnwachstum im kommenden Geschäftsjahr
|
||||
|
||||
|
||||
## Mögliche Kennzahlen zur Unternehmensbewertung
|
||||
*Handbuch Aktien- und Unternehmensbewertung - Peter Seppelfricke*
|
||||
|
||||
### Erfolgskennzahlen
|
||||
* Umsatz
|
||||
* Gewinn bzw. Jahresüberschuss
|
||||
* Gewinn vor Steuern (EBT)
|
||||
* Gewinn vor Steuern und Zinsen (EBIT/Betriebsergebnis): Bei Gesamtkostenverfahren Summe 1-8, bei Umsatzkostenverfahren Summe 1-7
|
||||
|
||||
### Finanzkennzahlen
|
||||
* Eigenkapitalquote = Eigenkapital / Gesamtkapital * 100
|
||||
* Fremdkapitalquote = Fremdkapital / Gesamtkapital * 100
|
||||
* Verschuldungsgrad = Fremdkapital / Eigenkapital * 100
|
||||
|
||||
### Rentabilitätskennzahlen
|
||||
* Eigenkapitalrentabilität = Jahresüberschuss / Eigenkapital * 100
|
||||
* Return on Investment (ROI) = Gewinn / Gesamtkapital
|
||||
* Umsatzrentabilität = Gewinn / Umsatz * 100
|
||||
|
||||
### _Nichtfinanzielle Kennzahlen_
|
||||
* _CO<sub>2</sub>-Emissionen_
|
||||
* _Unfallrate_
|
||||
|
||||
|
||||
## Gewünschte Kennzahlen
|
||||
*E-Mail vom 13.04.2023*
|
||||
* Umsatz
|
||||
* EBIT
|
||||
* EBIT Marge
|
||||
* Bilanzsumme
|
||||
* Eigenkapitalanteil (Eigenkapital / Bilanzsumme)
|
||||
* Fremdkapitalanteil (Fremdkapital / Bilanzsumme)
|
||||
* Verschuldungsgrad (Fremdkapital / Eigenkapital)
|
||||
* Eigenkapitalrentabilität (EBIT/Eigenkapital)
|
||||
* Umschlaghäufigkeit des Gesamtkapitals (Umsatz / Bilanzsumme)
|
||||
|
||||
## Kurzdefinitionen
|
||||
### Umsatz (Erlös)
|
||||
*https://www.lexoffice.de/lexikon/umsatz/*
|
||||
* Wert aller Produkte und Dienstleistungen, die in einem bestimmten Zeitraum abgesetzt wurden
|
||||
* Muss in der GuV ausgewiesen werden
|
||||
* Berechnung: Bruttoumsatz = Verkaufspreis (pro Stück) x abgesetzte Menge, Nettoumsatz = Bruttoumsatz - Erlösschmälerungen (z.B. Rabatte, Boni, Skonti) - Umsatzsteuer
|
||||
|
||||
### EBIT (Earnings Before Interest and Taxes/Gewinn vor Zinsen und Steuern/Betriebsergebnis/Operativer Gewinn)
|
||||
*https://www.bwl-lexikon.de/wiki/ebit/*
|
||||
* Kennzahl, die den Unternehmensgewinn angibt, der aus der gewöhnlichen Geschäftstätigkeit entsteht
|
||||
* Stellt das operative Ergebnis eines Unternehmens dar
|
||||
* Gibt Auskunft über die Effizienz und die Ertragskraft eines Unternehmens
|
||||
* Berechnung: Jahresüberschuss/-fehlbetrag + Steueraufwand - Steuerertrag + außerordentlicher Aufwand - außerordentlicher Ertrag + Finanzaufwand - Finanzertrag = EBIT
|
||||
|
||||
### EBIT-Marge
|
||||
*https://www.bwl-lexikon.de/wiki/ebit-marge/*
|
||||
* Eignet sich zum Vergleich von verschiedenen Unternehmen, zur Messung der operativen Veränderung und gibt Rückschlüsse auf die zukünftige Rentabilität
|
||||
* Verhältnis von EBIT und Umsatz
|
||||
* Eine EBIT-Marge in Höhe von 10% und mehr ist als positiv zu bewerten
|
||||
* Berechnung: EBIT-Marge = EBIT / Umsatz
|
||||
|
||||
### Bilanzsumme (Gesamtvermögen/Gesamtkapital)
|
||||
*https://www.bwl-lexikon.de/wiki/bilanzsumme/*
|
||||
* Summe des Vermögens bzw. der Aktiva und des Kapitals bzw. der Passiva eines Unternehmens
|
||||
* Kriterium für die Größe von Kapitalgesellschaften
|
||||
* Aktiva = Anlagevermögen + Umlaufvermögen
|
||||
* Passiva = Eigenkapital + Rückstellungen + Verbindlichkeiten
|
||||
* Liefert Anhaltspunkte dafür, ob und wie schnell ein Unternehmen wächst
|
||||
|
||||
### Eigenkapitalquote
|
||||
*https://www.bwl-lexikon.de/wiki/eigenkapitalquote/*
|
||||
* Informiert über die Kapitalstruktur eines Unternehmens
|
||||
* Geht aus der Bilanz eines Unternehmens vor
|
||||
* Je größer der Abstand zwischen eigenen und fremden Mittel, umso freier kann die Unternehmensleitung agieren
|
||||
* Je höher die Quote, desto unabhängiger ist das Unternehmen von Fremdkapitalgebern
|
||||
* Berechnung: Eigenkapital / Gesamtkapital
|
||||
|
||||
### Fremdkapitalquote
|
||||
*https://www.bwl-lexikon.de/wiki/fremdkapitalquote/*
|
||||
* Anteil des Fremdkapitals am gesamten Kapital
|
||||
* Anzeichen für die Zahlungsfähigkeit eines Unternehmens
|
||||
* Je höher die Quote, desto abhängiger ist das Unternehmen von Fremdkapitalgebern, die Kreditwürdigkeit sinkt
|
||||
* Berechnung: Fremdkapital / Gesamtkapital
|
||||
|
||||
### Verschuldungsgrad
|
||||
*https://www.bwl-lexikon.de/wiki/verschuldungsgrad/*
|
||||
* Informiert über die wirtschaftliche Stabilität eines Unternehmens
|
||||
* Bei einem hohen Verschuldungsgrad wird mehr Fremdkapital in einem Unternehmen eingesetzt, die Gefahr der Insolvenz steigt
|
||||
* Bei einem niedrigen Verschuldungsgrad ist die Eigenkapitalfinanzierung höher
|
||||
* Berechnung: Fremdkapital / Eigenkapital
|
||||
|
||||
### Eigenkapitalrentabilität (Return on Equity ROE)
|
||||
*https://www.bwl-lexikon.de/wiki/eigenkapitalrentabilitaet/*
|
||||
* Informiert über die Wirtschaftlichkeit des Unternehmens und die Sinnhaftigkeit des Kapitaleinsatzes
|
||||
* Misst die Ertragskraft des Unternehmens
|
||||
* Gewünschte Höhe der Eigenkapitalrentabilität differiert je nach Branche
|
||||
* Eine doppelt so hohe Eigenkapitalrendite wie der durchschnittliche Zins gilt als wünschenswert
|
||||
* Ist der Kapitalzins höher, sollten Unternehmen das Kapital aus dem Kapitalmarkt anlegen
|
||||
* Berechnung: Gewinn bzw. Jahresüberschuss / Eigenkapital
|
||||
|
||||
### Gesamtkapitalumschlag (Kapitalumschlag/Umschlagshäufigkeit)
|
||||
*https://www.bwl-lexikon.de/wiki/kapitalumschlag/*
|
||||
* Verhältnis vom Umsatz zum Eigen- oder Gesamtkapital
|
||||
* Legt fest, wie viel Umsatz mit dem vorhandenen Kapital eines Unternehmens erwirtschaftet werden kann
|
||||
* Gibt an, wie oft das eingesetzte Kapital durch die Umsatzerlöse zurück in das Unternehmen gelangt ist (desto häufiger, desto besser)
|
||||
* Berechnung: Umsatz / Bilanzsumme bzw. Gesamtkapital
|
||||
|
||||
### Umsatzrentabilität (Umsatzrendite/Umsatzmarge/Nettomarge)
|
||||
*https://www.bwl-lexikon.de/wiki/umsatzrentabilitaet/*
|
||||
* Verhältnis von Gewinn und Umsatz
|
||||
* Betrag, den ein Unternehme pro Euro Umsatz erwirtschaftet
|
||||
* Eine steigende Umsatzrendite deutet darauf hin, dass die Produktivität des Unternehmens steigt
|
||||
* Bildet die Effiziens eines Unternehmens ab
|
||||
* Eine Umsatzrentabilität in Höhe von 5% und mehr gilt als Richtwert
|
||||
* Berechnung: Gewinn / Umsatz
|
||||
|
||||
### Gesamtkapitalrentabilität (Return on Investment ROI, Kapitalrendite)
|
||||
*https://www.bwl-lexikon.de/wiki/gesamtkapitalrentabilitaet/*
|
||||
* Relation zwischen dem investierten Kapital und dem Gewinn
|
||||
* Beurteilungsmaßstad für die Rentabilität
|
||||
* Positiver ROI ist für ein Unternehmen vorteilhaft
|
||||
* Berechnung: Umsatzrentabilität x Kapitalumschlag
|
||||
|
||||
# Fazit
|
||||
Insgesamt sollen folgende Größen bzw. Kennzahlen betrachtet werden:
|
||||
* Unternehmensgröße
|
||||
* Umsatz
|
||||
* EBIT
|
||||
* EBIT-Marge
|
||||
* Bilanzsumme
|
||||
* Eigenkapitalquote
|
||||
* Fremdkapitalquote
|
||||
* Verschuldungsgrad
|
||||
* Eigenkapitalrentabilität
|
||||
* Umsatzrentabilität
|
||||
* Gesamtkapitalrentabilität
|
||||
* Gesamtkapitalumschlag
|
||||
|
||||
|
||||
Dazu werden folgende Daten benötigt:
|
||||
* Umsatz
|
||||
* Bilanzsumme
|
||||
* EBIT
|
||||
* Eigenkapital
|
||||
* Fremdkapital
|
||||
* Gewinn
|
||||
* Durchschnittliche Mitarbeiterzahl
|
||||
|
||||
Vergleichsmöglichkeiten:
|
||||
* Zeitvergleich: Vergleich der ermittelten Kennzahlen in verschiedenen Perioden, mit Hilfe von Zeitvergleichen über längere Zeiträume lassen sich Trends oder Zyklen erkennen
|
||||
* Betriebsvergleich: Gegenüberstellung der Kennzahlen von Unternehmen der gleichen Branche oder Vergleich der Werte eines Unternehmens mit dem Branchendurchschnitt
|
74
html/_sources/research/news_apis.md.txt
Normal file
74
html/_sources/research/news_apis.md.txt
Normal file
@@ -0,0 +1,74 @@
|
||||
# Nachrichtenquellen
|
||||
|
||||
## **Twitter API v2**
|
||||
|
||||
### **Access Levels**
|
||||
**Free:**
|
||||
- 1,500 Tweets per months
|
||||
- 1 AppID
|
||||
- Login with Twitter
|
||||
|
||||
**Basic:**
|
||||
- 100 per month
|
||||
|
||||
**Enterprise:**
|
||||
- Monthly subscribtion tiers
|
||||
|
||||
Postman Besipiele: https://developer.twitter.com/en/docs/tutorials/postman-getting-started
|
||||
|
||||
Getting started: https://github.com/twitterdev
|
||||
|
||||
|
||||
|
||||
## **NewsAPI**
|
||||
- Developer ist kostenlos
|
||||
- 24 Stunden verspätet sind die Artikel erreichabr
|
||||
- Bis zu einem Monat alte Artikel abrufbar
|
||||
- 100 Anfragen pro Tag
|
||||
- CORS geht nur für local host
|
||||
- Hat extra einen Punkt für deutsche Nachrichten: https://newsapi.org/s/germany-news-api
|
||||
|
||||
|
||||
Benötigt einen Account um einen API Key zu generieren.
|
||||
Doku: https://newsapi.org/docs/get-started
|
||||
|
||||
**Hinweis**: *Bietet die Möglichkeit nach Artikel mit einem bestimmten Wort zu suchen*
|
||||
|
||||
## **Bloomberg API**
|
||||
- Link: https://www.bloomberg.com/professional/support/api-library/
|
||||
- generell kostenlos, bei starker Nutzung muss ein Preis angefragt werden
|
||||
- sehr gut für Marktanalysen geeignet
|
||||
|
||||
|
||||
## **New York Times API**
|
||||
- die ersten 1000 Anfragen pro Tag sind kostenlos
|
||||
- 11 verschiedene APIs
|
||||
|
||||
|
||||
## **PressePortal**
|
||||
Bietet eine API zur DPA Gruppe an. Eher schlecht beschrieben und der API-Key muss via Email beantragt werden, bietet aber potentiell Zugriff auf deutsche Nachrichten.
|
||||
|
||||
Demo: https://api.presseportal.de/v2/demo/index.htx?mod=section_all&newsroom=&office=&city=&keyword=&topic=&police_officetype=&police_federalstate=&media=dokument&limit=&language=de&companyinfo=6344
|
||||
|
||||
API-Key Anfragen: https://api.presseportal.de/
|
||||
|
||||
|
||||
## **Tagesschau API 2.0**
|
||||
https://tagesschau.api.bund.dev/
|
||||
|
||||
## **Yahoo finance API**
|
||||
https://financeapi.net/
|
||||
|
||||
## **Google News API**
|
||||
- deprecated
|
||||
- kostenlos
|
||||
- gut dokumentiert
|
||||
|
||||
|
||||
## **Sonstiges**
|
||||
Bing News API, ESPN, Guardian API, BBC News API Yahoo News API und Financial Times fallen raus, da diese immer mit kosten verbunden sind oder sich nur mit Sport oder Kommentare befassen.
|
||||
|
||||
- "Die Zeit" hatte mal eine API die abgeschaltet wurde.
|
||||
|
||||
|
||||
-> RSS Feeds Irgendwie abgreifen
|
12
html/_sources/research/resarch-central.md.txt
Normal file
12
html/_sources/research/resarch-central.md.txt
Normal file
@@ -0,0 +1,12 @@
|
||||
# Research Central
|
||||
|
||||
|
||||
## Sentiment Analysis
|
||||
|
||||
### FinBert
|
||||
|
||||
FinBert is a specialised sentiment Analysis for Financial Data.
|
||||
Sadly it isn't a very good model, and it does not work at all for texts in german.
|
||||
|
||||
Experiments can be found here:
|
||||
* [FinBert Jupyter](../../Jupyter/AI-models/"Sentiment Analysis"/FinBert.ipynb)
|
68
html/_sources/seminararbeiten/3_Datenspeicherung.md.txt
Normal file
68
html/_sources/seminararbeiten/3_Datenspeicherung.md.txt
Normal file
@@ -0,0 +1,68 @@
|
||||
# Aufgabe: Inhaltliche Skizze für die Seminararbeit zur Thematik Datenspeicherung
|
||||
|
||||
# 1. Allgemeine Anforderungen an Datenbank
|
||||
- **Speicherung** von strukturierten Daten, wie Kennzahlen, Stammdaten
|
||||
- **Skalierbarkeit:** Datenbank sollte skalierbar sein, um zukünftige Daten weiterhin zu speichern und weitere Unternehmen hinzuzufügen
|
||||
- **Sicherheit:** Die Datenbank muss Funktionen unterstützen, um die Datenvor unbefugtem Zugriff zu schützen.
|
||||
- **Datensicherung- und Wiederherstellung: ** Die Datenbank muss Funktionen zur Sicherung und Wiederherstellung unterstützen.
|
||||
- **Leistung:** Die Performance der Datenbank ist eher zweitrangig, da die Abfrage nicht hochdynamisch sein muss. Ausserdem werden nicht viele Anfragen erwartet.
|
||||
- **Integration:** Die Datenbank muss sich in ein Python Framework einbinden lassen und mit dem bevorzugten Frontend Daten austauschen können.
|
||||
|
||||
# 2. Datenarten
|
||||
Welche Daten erwarten wir im Projekt? \
|
||||
Cluster, wie z.B. Stammdaten, Stimmungsdaten, Social Graph, Zeitseriendaten/Historien
|
||||
|
||||
> Abstimmung mit den Bereichen Textmining und Datenbeschaffung über verwendete Daten und Formulierung von Anforderungen an Daten.
|
||||
|
||||
## 2.1 strukturierte Daten
|
||||
Was sind strukturierte Daten?
|
||||
|
||||
## 2.2 unstrukturierte Daten
|
||||
Was sind unstrukturierte Daten?
|
||||
|
||||
> Definiere eine Anforderung an die Struktur der Daten.
|
||||
|
||||
# 3. Arten von Datenbanken
|
||||
## 3.1 Relational
|
||||
Was ist eine reltionale Datenbank?
|
||||
Wie werden Daten gespeichert?
|
||||
Beispiel für relationale Datenbank
|
||||
|
||||
## 3.2 Graph
|
||||
Was ist eine Graph Datenbank?
|
||||
Wie werden Daten gespeichert?
|
||||
Beispiel für Graph Datenbank
|
||||
|
||||
## 3.3 Zeitserien
|
||||
Was ist eine Zeitserien Datenbank?
|
||||
Wie werden Daten gespeichert?
|
||||
Beispiel für Zeitserien Datenbank
|
||||
|
||||
> Kurzvorstellung von Datenbanksystemen
|
||||
|
||||
# 4. DBS Transparenzregister
|
||||
## 4.1 relationales Datenbankmodell
|
||||
|
||||
> Modell zur Abbildung der Relationen im Projekt Transparenzregister
|
||||
|
||||
## 4.2 verteilte Datenbank oder ein System
|
||||
Ein DBS: Wenn nur ein Datenbanksystem verwendet wird, muss nur ein System gepflegt und integriert werden.
|
||||
- Vorteil: einfache Verwaltung und schnelle Abfrage von Datenbeziehungen
|
||||
|
||||
verteiltes System: spezialisierte Datenbank für jeden Datenytp, wie z.B. Zeitseriendaten oder Graph Daten
|
||||
|
||||
> Definiere eine Empfehlung/Anforderung für das Projekt Transparenzregister.
|
||||
|
||||
## 4.3 Analyse zur Auswahl eines Datenbanksystems
|
||||
Was sollte bei der Auswahl eines Datenbanksystems beachtet werden?
|
||||
|
||||
> Empfehlungen für DBS-Auswahl
|
||||
|
||||
## 4.4 Anbindung an Front- und Backend
|
||||
Wie kann das DBS an das Front- und Backend angebunden werden?
|
||||
> Jupyter Notebook mit Beispiel
|
||||
|
||||
## 4.5 Abfragen in der Datenbank
|
||||
Wie können Unternehmensdaten abgefragt werden?
|
||||
Wie können Verflechtungen abgefragt werden?
|
||||
> Jupyter Notebook mit Beispiel
|
@@ -0,0 +1,45 @@
|
||||
**Abstract/Planung der Seminararbeit zu "Text Mining"**
|
||||
|
||||
**Sascha Zhu**
|
||||
|
||||
**10.05.2023**
|
||||
|
||||
|
||||
|
||||
Gliederung
|
||||
|
||||
1. Einleitung und Begriffsbestimmung
|
||||
|
||||
2. Text Mining Prozess
|
||||
|
||||
3. Verwendung von NLP-Methoden für das Text Mining
|
||||
|
||||
3.1 Morphologische Textanalyse
|
||||
|
||||
3.2 Syntaktische Textanalyse
|
||||
|
||||
3.3 Semantische Textanalyse
|
||||
|
||||
4. Ontologien und Text Mining
|
||||
|
||||
4.1 Verwendung von Ontologien als Grundlage der Textanalyse
|
||||
|
||||
4.2 Generierung von Ontologien mittels Text Mining ("ontology generation"/"ontology learning" )
|
||||
|
||||
5. Sentiment-Analyse als Teilgebiet des Text Minings
|
||||
|
||||
6. Zusammenfassung und Ausblick
|
||||
|
||||
|
||||
|
||||
Die Seminararbeit zu "Text Mining" soll in die oben genannten sechs Abschnitte gegliedert werden.
|
||||
|
||||
Nach einer Einleitung, in der der Begriff "Text Mining" näher definiert wird und gegenüber "Data Mining" und "Computational Linguistics" abgegrenzt wird, folgt der zweite Abschnitt zum Text Mining Prozess, der nach Hippner u. Rentzmann (2006) in die folgenden sechs Schritte eingeteilt wird: (a) Aufgabendefinition; (b) Dokumentenselektion; (c) Dokumentenaufbereitung; (d) Untersuchung mit Text-Mining-Methoden; (e) Interpretation und Evaluation; (f) Anwendung der Ergebnisse.
|
||||
|
||||
Im darauffolgenden dritten Abschnitt zur Verwendung von NLP-Methoden für das Text Mining werden die drei Phasen des Natural Language Processings (NLP), d.h. die morphologische, syntaktische und semantische Textanalyse, näher dargestellt, wobei der Schwerpunkt auf die semantische Analysetechniken wie z.B. "Word Sense Disambiguation" (WSD) und "Named Entity Recognition" (NED) liegen soll.
|
||||
|
||||
Der vierte Abschnitt soll sich dem Thema "Ontologien und Text Mining" widmen. Einerseits können Ontologien, die domänenspezifisches Wissen abbilden, als Grundlage für NLP-Methoden dienen, um etwa die semantische Textanalyse zu verbessern. Andererseits können mittels Text Mining automatisch bzw. semi-automatisch Ontologien als Repräsentation der Text-Mining-Ergebnisse erstellt werden ("ontology generation"/"ontology learning").
|
||||
|
||||
Im vorletzten, fünften Analyse soll die Sentiment-Analyse als Teilgebiet des Text Mining durchleuchtet werden. Dieser Abschnitt soll den Schwerpunkt der gesamten Seminararbeit darstellen. Die Methodik, Funktionsweise, Varianten und Use Cases der Sentiment Analyse sollen anhand ausgewählter Beispiele erläutert werden. Zudem sollen auch bekannte Sentiment-Analyse-Tools wie z.B. FinBERT, VADER, SentiWS etc. näher beschrieben werden.
|
||||
|
||||
Am Ende der Seminararbeit soll der sechste Abschnitt eine Zusammenfassung liefern und einen Ausblick darüber geben, in welche Richtung die zukünftige Entwicklung auf dem Gebiet des Text Minings gehen wird.
|
@@ -0,0 +1,35 @@
|
||||
---
|
||||
title: "Automatisierte Daten Extraktion aus Internetquellen als Grundlage für die Analyse von Kapitalgesellschaften"
|
||||
author: "Nolde, Tristan Norbert"
|
||||
date: "2023-05-06"
|
||||
---
|
||||
|
||||
# Abstract: Automatisierte Daten Extraktion aus Internetquellen als Grundlage für die Analyse von Kapitalgesellschaften
|
||||
|
||||
## Gliederung
|
||||
1. Einleitung (Zielsetzung/Problemstellung, Vorgehen)
|
||||
2. Web Scraping/Crawling
|
||||
1. Definition und Theorie
|
||||
2. Technologien
|
||||
3. Umsetzung
|
||||
3. RSS Feeds
|
||||
1. Definition und Theorie
|
||||
2. Technologien
|
||||
3. Umsetzung
|
||||
4. APIs
|
||||
1. Definition und Theorie
|
||||
2. Technologien
|
||||
3. Umsetzung
|
||||
5. Rechtliche Rahmenbedingungen
|
||||
6. Vergleich der Lösungsansätze
|
||||
7. Zusammenfassung
|
||||
|
||||
## Inhalt
|
||||
|
||||
In Zeiten von Big Data und AI stellen Daten und ihre Verfügbarkeit zunehmend eines der wichtigsten Wirtschaftsgüter dar. Als solches können sie auch eingesetzt werden, um Kapitalgesellschaften (eine Subklasse von Unternehmen) anhand verschiedener Kennzahlen wie der Mitarbeiterzahl oder dem Jahresgewinn zu analysieren. Obwohl solche Daten zu Genüge in Zeitungsartikeln, Newslettern oder dedizierten Aktienanalysen zu finden sind, so gestaltet sich eine automatisierte Extraktion dieser Daten aufgrund verschiedener Formate sowie weiterer Restriktionen schwierig.
|
||||
|
||||
Daher sollen im Rahmen dieser Seminararbeit verschiedene Wege betrachtet werden, die eben diese Daten erheben und zur Verfügung stellen können. Zu den nennenswerten Quellen gehören: Der Bundesanzeiger, RSS Feeds, Nachrichten APIs. Ziel ist es, aus diesen Quellen wertvolle Informationen bezogen auf den wirtschaftlichen Erfolg einer Kapitalgesellschaft sowie aktueller Nachrichten zu extrahieren und in ein einheitliches Format zu überführen.
|
||||
|
||||
Neben des technischen Einsatzes von Web Scraping/Crawling, um Informationen aus Webseiten zu gewinnen, sowie des Abfragens verfügbarer APIs soll auch der rechltiche Aspekt dieser Vorgehens Berücksichtigung finden, um die Rechtmäßigkeit zu bewerten.
|
||||
|
||||
Abschließend wird der Einsatz der verschiedenen Technologien an den Faktoren: Flexibilität, Simplizität, Verfügbarkeit und Rechtmäßigkeit, ein Fazit gezogen sowie ein Ausblick des weiteren Einsatzes gegeben.
|
@@ -0,0 +1,47 @@
|
||||
# Seminarthema: Datenvisualisierung
|
||||
|
||||
## Geplanter Inhalt:
|
||||
- Einführung
|
||||
- Best Practice für Datenvisualisierung
|
||||
- Vorstellung verschiedener Diagrammarten
|
||||
- Welche Diagrammarten eignen sich für unsere drei Anwendungsbereiche Time Series Daten, Netzwerke und Stimmungen?
|
||||
- Betrachtung verschiedener Bibliotheken (z.B. D3Blocks, pyvis, plotly)
|
||||
- Zweck der Bibliothek, unterstützte Visualisierungen, Vor- und Nachteile
|
||||
- Minimalbeispiele
|
||||
- Anwendung auf unser Projekt:
|
||||
- Vergleich der Bibliotheken mit Blick auf unsere drei Anwendungsbereiche
|
||||
- Welche Daten werden für die einzelnen Diagramme gebraucht?
|
||||
- Welche Ideen/Anforderungen ergeben sich an die anderen Themenbereiche?
|
||||
- Fazit und Handlungsempfehlung
|
||||
- Welche Diagramme und welche Bibliotheken eignen sich für uns?
|
||||
|
||||
## Abstract:
|
||||
|
||||
In dieser Seminararbeit geht es um die Visualisierung von Daten in Python. Im Fokus steht die Anwendung auf die drei Themenbereiche, die im Projekt "Transparenzregister" behandelt werden: Time Series Daten, Soziale Netzwerke und Stimmungen. Nach einer Einführung in das Thema werden Best Practices für die Datenvisualisierung vorgestellt und verschiedene Diagrammarten präsentiert. Anschließend wird diskutiert, welche Diagramme für die genannten Anwendungsbereiche am besten geeignet sind.
|
||||
|
||||
Im zweiten Abschnitt werden verschiedene Python Bibliotheken vorgestellt und anhand von Minimalbeispielen betrachtet. Dabei wird analysiert, welche Bibliotheken die gewünschten Diagramme für unsere Anwendungsbereiche am besten darstellen und welche Daten für die Erstellung der verschiedenen Diagramme benötigt werden. Es werden zudem Ideen und Anforderungen an die anderen Themenbereiche aufgezeigt.
|
||||
|
||||
Im letzten Abschnitt der Arbeit wird ein Fazit gezogen und eine Handlungsempfehlung gegeben. Insgesamt soll die Arbeit einen Einblick in die Welt der Datenvisualisierung in Python geben und unserem Projekt helfen, die richtigen Entscheidungen bei der Wahl der Diagrammarten und Bibliotheken zu treffen.
|
||||
|
||||
## Erste Sammlung von Referenzen:
|
||||
Bibliotheken/Tools:
|
||||
- D3Blocks: [Documentation](https://d3blocks.github.io/d3blocks/pages/html/index.html), [Medium Blog](https://towardsdatascience.com/d3blocks-the-python-library-to-create-interactive-and-standalone-d3js-charts-3dda98ce97d4)
|
||||
- pyvis: [Documentation](https://pyvis.readthedocs.io/en/latest/tutorial.html)
|
||||
- networkx: [Documentation](https://networkx.org/documentation/stable/auto_examples/index.html), [Example](https://www.kirenz.com/post/2019-08-13-network_analysis/)
|
||||
- plotly: [Documentation](https://plotly.com/python/#animations)
|
||||
|
||||
Netzwerke:
|
||||
- Zentralitätsmaße: [Medium Blog](https://towardsdatascience.com/social-network-analysis-from-theory-to-applications-with-python-d12e9a34c2c7)
|
||||
- Visualisierungsideen: [Medium Blog](https://towardsdatascience.com/visualizing-networks-in-python-d70f4cbeb259)
|
||||
|
||||
Kennzahlen:
|
||||
- Visualisierungsideem: [Towards AI](https://towardsai.net/p/l/time-series-data-visualization-in-python)
|
||||
|
||||
Best Practice:
|
||||
- [Science Direct](https://www.sciencedirect.com/science/article/pii/S2666389920301896)
|
||||
- [Toptal](https://www.toptal.com/designers/data-visualization/data-visualization-best-practices)
|
||||
|
||||
|
||||
|
||||
|
||||
|
@@ -0,0 +1,4 @@
|
||||
# Themen in der Seminararbeit zum Thema Datenvisualisierung
|
||||
|
||||
## Python Bibliotheken
|
||||
- networkx und pyvis
|
@@ -0,0 +1,21 @@
|
||||
# Dev Ops
|
||||
|
||||
## Roadmap
|
||||
|
||||
My plan for this coursework is to explore the dev ops thema and how it applies to the AI theme and this project in specific.
|
||||
|
||||
There are the following things in the theme of dev ops I want to explore:
|
||||
|
||||
1. Python dependency management via poetry
|
||||
2. Write a documentation around pre-commit hooks and how they can be used for this project with arguments for and against each of the hooks.
|
||||
3. Add a GitHub Runner on my own hardware to the repository and build a pipline with GitHub actions.
|
||||
- Add linter (black, flake8, pylint, mypy, bandit, pip-audit)
|
||||
- Testing setup in the pipline via pytest
|
||||
- Explore the ability of GitHub to summaries the linting and testing results.
|
||||
- Add SonarQube to the project if the test and lint summaries in GitHub does not suffice.
|
||||
- Build the artifacts. Something like python wheels, Docker container and deployment files.
|
||||
- Startup to new build and see if it crashes in the first 60s if a framework is shown.
|
||||
- Build the documentation via sphinx for this project via the pipline.
|
||||
4. How to deploy the collection of Docker containers via docker-compose and/or kubernetes.
|
||||
5. Evaluate the use of dependabot to upgrade the poetry dependency groups.
|
||||
6. Steadily grow the build pipline as the application grows.
|
48
html/_sources/seminararbeiten/verflechtungsanalyse.md.txt
Normal file
48
html/_sources/seminararbeiten/verflechtungsanalyse.md.txt
Normal file
@@ -0,0 +1,48 @@
|
||||
# Verflechtungsanalyse
|
||||
|
||||
## Entwurf des Inhaltsverzeichnis + Stichpunkte
|
||||
|
||||
1 Einleitung
|
||||
|
||||
1.1 Problemstellung
|
||||
|
||||
1.2 Zielsetzung und Aufbau der Arbeit
|
||||
|
||||
2 Graphentheorie
|
||||
|
||||
2.1 Begriffliche Definition
|
||||
|
||||
2.2 Sociometry
|
||||
- sociometry: quantitatives Methode um soziale Beziehungen zu messen.
|
||||
|
||||
2.3 Sociogram/ Social Graph
|
||||
- Ist ein graph der ein Soziales netzwerk darstellt
|
||||
- Basiert auf der Graphentheorie
|
||||
- Wurde offiziell Sociogram genannt
|
||||
- von facebook in der F8 2007 vorgestellt
|
||||
|
||||
2.4 Social Network Analysis (SNA)
|
||||
|
||||
- Social Network Analysis (SNA): Untersuchen von Sozialen Strukturen anhand von Netzwerken und Graphtheorie.
|
||||
|
||||
3 Ein Social Graph für das Transparentsregister
|
||||
|
||||
3.5 Handlungsempfehlung
|
||||
|
||||
4 Zusammenfassung
|
||||
|
||||
4.1 Kritische Reflexion
|
||||
|
||||
4.2 Fazit
|
||||
|
||||
4.3 Ausblick
|
||||
|
||||
## Abstract
|
||||
|
||||
In der Seminararbeit zum Thema: "Verpflechtungsanalyse der Unternehmen und Personen im Transparenzregister" soll einerseits die Theorie für die Analyse von Verflechtungen vermittelt sowie anhand des Projektess aufgezeigt werden wie diese angewendet werden kann.
|
||||
|
||||
Als Fundament dient die Graphentheorie, welche Grundlegen für die Analyse von Netzstrukturen ist. Zunächst werden die wichtigsten Begriffe definiert und es wird eine Einführung ins Thema der Graphentheorie mit Beispielen und Erläuterung gegeben. Darauffolgend wird tiefer in das Thema eingetaucht und sich mit dem Bereich Sociogram/ Social Graph auseinandergesetzt. Ein Sociogram ist ein Model eines Netzwerks von sozialen Verbindungen die durch einen Graphen repräsentiert werden. Diese Idee wurde 2007 von Facebook als Social Graph in der F8 vorgestellt. Diese Art von Graph basiert auf der Graphentheorie. Die stärken dieses Graphen liegen in der Veranschaulichung der sozialen Verflechtungen. Daher wird der Social Graph für die Analyse der Verflechtungen innerhalb des Transparenzregisters genutzt.
|
||||
|
||||
Im Hauptteil der Seminararbeit wird aufgezeigt wie der Social Graph auf das Transparenzregister angewendet werden könnte. Es wird gezeigt welche Komponenten gebildet werden müssten und wie die Daten aufbereitet werden um einen Social graph bauen zu können. Des Weiteren wird auf die Formel und Algorithmen eingegangen die zur Erstellung des Graphen nötig sind. Dabei orientiert sich die Arbeit an Beispielen um die Theorie nachvollziebar zu vermitteln. Dieser Abschnitt wird mit einer Handlungsempfehlung für das Projekt abgeschlossen.
|
||||
|
||||
Abgeschlossen wird das Werk mit einer kritischen Reflexion, gefolgt von einem Fazit und einem Ausblick.
|
21
html/_sources/templates/meeting_notes_template.md.txt
Normal file
21
html/_sources/templates/meeting_notes_template.md.txt
Normal file
@@ -0,0 +1,21 @@
|
||||
# Weekly *X*: DD.MM.YYYY
|
||||
|
||||
## Teilnehmer
|
||||
- Prof. Arinir
|
||||
- Tristan Nolde
|
||||
- Tim Ronneburg
|
||||
- Phillip Horstenkamp
|
||||
- Kim Mesewinkel-Risse
|
||||
- Sascha Zhu
|
||||
- Sebastian Zeleny
|
||||
|
||||
## Themen
|
||||
|
||||
- ABC:
|
||||
- ...
|
||||
|
||||
## Abgeleitete Action Items
|
||||
|
||||
| Action Item | Verantwortlicher | Deadline |
|
||||
|-------------|------------------|-----------------|
|
||||
| Beispiel | Max Mustermann | nächstes Weekly |
|
71
html/_sources/timeline.md.txt
Normal file
71
html/_sources/timeline.md.txt
Normal file
@@ -0,0 +1,71 @@
|
||||
# Timeline
|
||||
```{mermaid}
|
||||
|
||||
gantt
|
||||
|
||||
title Timeline PG Transparenzregister
|
||||
dateFormat YYYY-MM-DD
|
||||
section Organisation
|
||||
Kennenlernen des Projektteams : done, a1, 2023-03-30, 1d
|
||||
Erstellen des Organigramms : done, after a1 , 1d
|
||||
GitHub : done, 2023-04-06, 7d
|
||||
Zeitplanung SoSe : active , 2023-04-06, 7d
|
||||
|
||||
section Dokumentation
|
||||
Meeting Notes: active, 2023-03-30, 10w
|
||||
Seminarthemen: active, 2023-04-13, 8w
|
||||
Lastenheft: active, 2023-04-06, 5w
|
||||
Pflichtenheft: milestone, 2023-05-11
|
||||
Reserve: crit, 2023-06-08, 1w
|
||||
|
||||
|
||||
section Meeting
|
||||
Weekly 1 : done, 2023-03-30, 0.5h
|
||||
Statustermin 1 : done ,2023-03-30 , 1h
|
||||
Weekly 2 : done, 2023-04-06, 2h
|
||||
|
||||
Statustermin 2 : active, 2023-04-13, 1h
|
||||
Weekly 3 : active, 2023-04-13, 0.5h
|
||||
Weekly 4 : active, 2023-04-20, 2h
|
||||
|
||||
Weekly 5 : active, 2023-04-27, 0.5h
|
||||
Statustermin 3 : active, 2023-04-27, 1h
|
||||
|
||||
Weekly 6 : active, 2023-05-04, 2h
|
||||
|
||||
Weekly 7 : active, 2023-05-11, 0.5h
|
||||
Statustermin 4 : active, 2023-05-11, 1h
|
||||
|
||||
Weekly 8 : active, 2023-05-18, 2h
|
||||
Weekly 9 : active, 2023-05-25, 0.9h
|
||||
Statustermin 5 : active, 2023-05-25, 1h
|
||||
|
||||
Weekly 10 : active, 2023-06-01, 2h
|
||||
Weekly 11 : active, 2023-06-01, 0.9h
|
||||
Statustermin 6 : active, 2023-06-08, 1h
|
||||
|
||||
section Recherche
|
||||
Unternehmensformen : active, 2023-04-06, 14d
|
||||
Kennzahlen : active, 2023-04-10, 14d
|
||||
Datenquellen : active, 2023-04-10, 14d
|
||||
rechtliche Verwendbarkeit: active, 2023-04-06, 18d
|
||||
Verwendete Metriken, Datenquellen, Rechtmäßigkeit: milestone, 2023-04-24
|
||||
Reserve: crit, 2023-04-24, 3d
|
||||
|
||||
section Definition
|
||||
fachl. Aufgabe : active, 2023-04-27, 1d
|
||||
techn. Aufgabe : active, 2023-04-27, 1d
|
||||
Funktionelle Anf. : active, 2023-04-27, 7d
|
||||
Qualitative Anf. : active, 2023-04-27, 7d
|
||||
Modell: active, 2023-05-04, 7d
|
||||
Hierarchie: active, 2023-05-04, 7d
|
||||
Definition der Anforderungen : milestone, 2023-05-11
|
||||
Reserve: crit, 2023-05-11, 1w
|
||||
|
||||
section Proof of concept
|
||||
Project Proposal : active, 2023-05-18, 10d
|
||||
Vorstellung Project Proposal: milestone, 2023-05-28
|
||||
Implementierung des Proposals: active, 2023-05-25, 14d
|
||||
Vorstellung Proof of Concept: milestone, 2023-06-08
|
||||
Reserve: crit, 2023-06-08, 1w
|
||||
```
|
Reference in New Issue
Block a user