Grundsatzfrage für ein DMS / Dokumentations System

#1
Hallo Zusammen
Ich überlege mir z.Z. ein DMS zu Programmieren. Nun stellt sich die Frage in welcher Form die Daten abgelegt werden sollen (Technologie wird C# und Entity Framework Core sein, als Frontend warscheinlich WPF oder asp.net Core):

Möglichkeit 1: Ein Daten Model für den Typ der Eigenschaften, wie z.B. Benutzer, IP-Adresse, Betreibssystem, Software, CPU etc und eines welches dann den Wert Speichert. Ähnlich wie bei WikiData, dies hätte den Vorteil, dass es sich einfacher erweitern und durchsuchen liesse.
Mäglichkeit 2: Verschiedene Inhalts Datenmodelle (wie für z.B. die oben genannten). Das Grundmodel für den Typ bleibt gleich, enthält aber noch ein zusätzliches Feld für die Klasse des Datentypes. Dies hätte den Vorteil, dass es sich einfacher (im Frontend) Umsetzen lassen würde, dafür aber einen Grösseren Aufwand für das durchsuchen.

MfG

Patahel
 

SchwarzeBeere

Moderator
Mitarbeiter
#2
Welche Anforderungen willst du denn mit deinem DMS umsetzen? Woher stammen sie, welche Priorität haben sie, wessen Bedürfnisse werden damit befriedigt, wie stehen sie zu anderen Anforderungen oder wie hoch ist der Aufwand der Umsetzung? Und wie machen es andere?

In Anbetracht der vielen DMS am Markt, die allesamt das gleiche Chaos erzeugen, wenn man nicht einem vorher erstellten, schlüssigen Konzept folgt, wäre etwas komplett neues doch mal erfrischend.
 
#3
"Grundkonzept"

Grundlegend geht es mir als erstes darum eine einfache (zubedienende) Software, um IT-Systeme und ähnliches dokumentieren zu können, zu kreieren. Darüber hinaus soll diese aber auch für alles Erdenkliche (Verwaltung von "normalen" Dokumenten, Projekten, Ideen für z.B, Ein Buch/Film/Theater) eingesetzt werden können.

Technisch denke ich mir ein ähnlichen Ansatz wie bei der OOP zu verwenden: Alles ist ein Eintrag (Dokumenten-Objekt :wink: ). Wenn ich z.B. einen Server Dokumentieren will, ist dies dann ein Eintrag vom vom Typ Computer, welcher u.a. die Einträge für IP-Adresse, Name, CPU, RAM etc enthält. Diese wiederum besitzen auch eigenen eigenen Typ.

Es wird zwar Workflows anbieten, soll aber nahezu 100% unabhängig von solch einschränkenden "Ideen" einsetzbar und seinen Bedürfnissen anpassbar sein.

Wenn ich jetzt so darüber nachdenke, wird's wohl drauf heraus laufen dass ich es erweiterbar designen muss...
 
#4
Konstruiere in deinen Klassen bereits Schnittstellen für Add-Ons. Plane das Projekt so umfangreich, wie es dir möglich ist. Nach 2-3 Jahren Entwicklung und der anschließenden Feldforschung (Wie wird die Software genutzt, welche Schwierigkeiten haben meine Probanden mit der Bedienung, welche Funktionen würden sie an dieser Stelle der Oberfläche vermuten oder welche fehlen ihnen, ...?) gehen nochmal 1-2 Jahre ins Land, bis so ein Programm marktreif ist. Dann geht es ans "Werbung" machen und hoffen, dass kein Konkurrent bereits besser ist. :)

Elementare Fragen: Wie viele Personen sollen das Programm zeitgleich mit der selben "Datenbank" verwenden?

Dann stellen solche Programme ein Abbild der Infrastruktur des Unternehmens dar. Entsprechend muss ein Nutzer in der Lage sein, bestimmte Bereiche zu verschlüsseln, um einen Plain-text-verlust nicht vertreten zu müssen.



Als ersten Schritt in der Planung: Was kann die Konkurrenz? ( Kostenfrei: The Top 7 Free and Open Source Database Software Solutions - Capterra Blog ) Worin kann mein Produkt besser sein?



Zum Grundgedanken:
- Komfortfunktionen locken viele Nutzer.
Eine umfangreiche Datenbank, die stets um 12h-24h aktuelle Informationen zum Einsatzgebiet bietet (z.B. Hardware, Softwarelösungen, ...) kostet viel Zeit und nerven sie anzulegen. So kann jedoch ein Nutzer eine Firma und Spezifikation eingeben, das Objekt wird automatisch gefunden und es werden alle notwendigen Informationen und aktuelle Versionen sowie andere interessante Dinge angezeigt. Wichtig (Bei Hardware): Wie lange ist diese bereits im Betrieb?

- Dokumentierung
Welche Output-Formate benötigt meine Zielgruppe? Reine digitale Dokumentierung oder auch PDF-Export? Wofür braucht meine Zielgruppe diese Doku? Müssen diese vlt. als "Berichte" einer Auditierungs-/Zertifizierungsstelle vorgelegt werden? ...

- Einsatzgebiet
Welche Marktbereiche sollen dadurch abgedeckt werden? Wird eine Customisierung einfach gestaltet? (Beispiel: SAP) Wie schnell kann ich meine Bedürfnisse damit realisieren? Klappt das auch easy zentral vom Server in einem Weltweiten Netzwerk?
 
#5
Hallo zusammen,

grundsätzlich eine nette Idee. Dein Ansatz, das ganze Projekt an die OOP anzulehnen ist nichtmal abwegig. Ich, als Softwarearchitekt, würde das ganze sogar so weit bringen, dass der Nutzer seine "Klassen" bzw. Objekttypen mit den Eigenschaften selbst erstellen kann. Damit bist du super flexibel. Kannst dem Nutzer zur Installation / Registrierung aber schon vorgefertigte Objekttypen generieren, die zu seiner Branche / seinem Verwendungszweck passen.
Habe ich in einem ähnlichen Projekt sogar schonmal genau so umgesetzt :D
 
Oben