Zum Inhalt springen

Projektantrag: Aufsetzen einer zentralen Wiki-Software zur technischen Dokumentation (unter Nutzung von Containervirtualisierung)


sTEWpITT

Empfohlene Beiträge

Hallo zusammen,

langsam neigt sich die Ausbildung dem Ende und die Prüfung nähert sich. Ich muss am 12.03. meinen Projektantrag hochladen und habe jetzt die erste Version eines Antrags fertig, bin mir aber nicht sicher, ob das in die richtige Richtung geht oder ich etwas Gravierendes nicht beachtet habe.

Was sagt ihr die dazu? Ich bin über jeden Tipp oder Kritikpunkt dankbar. Zur Not kann ich noch komplett umschwenken, noch ist ja genug Zeit.

Danke für eure Zeit und Mühe!

 

 

1.       Projektbezeichnung

Aufsetzen einer zentralen Wiki-Software zur technischen Dokumentation (unter Nutzung von Containervirtualisierung)

 

1.1   Kurzform der Aufgabenstellung

Die Firma XYZ betreut über 600 Server am Standort Berlin. An den Servern müssen immer wieder Einstellungen, Wartungsarbeiten, Updates oder Neustarts durchgeführt werden. Da nicht alle Kunden dieselbe Hardwareausstattung und unterschiedliche Konstellationen von Softwaremodulen auf dem Hostsystem haben, gibt es viele verschiedene Dokumentationen und Lösungsansätze für Probleme, die an unterschiedlichen Stellen gesammelt werden.

 

1.2   Projektziele

Es soll ein zentrales technisches Wiki für die Supportmitarbeiter aufgesetzt werden. In diesem Wiki sollen existierende Dokumentationen und bekannte Problemstellungen mit ihren Lösungsansatzen zusammengefasst werden.  (durchdachtes, flexibles Berechtigungskonzept) Es soll möglich sein, Artikeln Zugriffsrechte zuzuweisen, um ein Veröffentlichen für verschiedene Teams und Aufgabenbereiche freizugeben und um ausgewühlten Usern Schreibrechte zu erteilen. Eine Anbindung an eine LDAP-Datenbank (Lightweight Directory Access Protocol) ist wünschenswert, um die bestehenden Userkonten einbinden zu können. Da es sich um eine Möglichkeit zur technischen Dokumentation handeln soll, sollte eine „Code“ Formatierungsoption und eine Möglichkeit zur Dateiablage (zB Firmwares oder portable Tools) vorhanden sein.

 

1.3   Projektauftrag

Mithilfe eines zentralen Wikis als strukturierte technische Dokumentation für Auftrags- und Wartungsarbeiten und als intuitives Werkzeug für den Telefonsupport soll eine Möglichkeit geschaffen werden, anfallende Arbeiten effizienter und flexibler zu erledigen und Neuerungen mit wenig Aufwand zu dokumentieren.

 

2.       Projektbeschreibung

2.1   Wie sieht die Ausgangssituation vor Projektbeginn aus?

Momentan existieren ein „altes“ Wiki und eine Knowledge Base auf der Homepage der Firma. Zusätzlich liegen einzelne Leitfäden und Dokumentationen in verschiedenen Verzeichnissen, auf die unter Umständen vor Ort beim Kunden nicht zugegriffen werden kann.

Das Anlegen von neuen Usern auf der alten Datenbank und Änderungen von Berechtigungen und Einträgen im ursprünglichen Wiki sind aufwändig, teilweise sind Beiträge doppelt, nicht aktuell und vollständig oder lediglich einzelne Informationen und Codezeilen.

Die Knowlegde Base als Ablösung wurde nicht komplett als fest integrierter Bestandteil der Infrastruktur aufgenommen und ist dementsprechend nicht vollständig gepflegt.

(soll ich hier noch schreiben, dass sie nicht wirklich intuitiv ist und unübersichtlich und unstrukturiert ist? Also den User-Standards nicht entspricht? Außerdem läuft die ja komlpett losgelöst und ist von der Webseite abhängig)

 

2.2   Was soll am Ende des Projektes erreicht sein?

Das Wiki soll isoliert aufgesetzt werden, damit es nicht von der Erreichbarkeit anderer Dienste abhängt. Jeder Mitarbeiter soll sich mit seinen LDAP-Daten im Wiki anmelden können und die für ihn freigegebenen Beiträge sehen und diese gegebenenfalls bearbeiten können. Mitarbeiter im Außendienst sollen über Links oder Downloads in der Lage sein, alle erforderlichen Dokumentationen und Arbeitsabläufe zentral zu beziehen.

Das Wiki muss den aktuellen User-Standards entsprechen, damit es sich umstandslos in den Arbeitsalltag integrieren lässt und von allen Mitarbeitern entsprechend angenommen wird. Dafür sollen Oberfläche und Bedienung intuitiv und möglichst einfach von der Hand gehen und das Wiki mit möglichst wenig Administrationsaufwand zu betreiben sein.

 

2.3   Welche Einschränkungen müssen berücksichtigt werden?

Das Wiki muss in einem Linux Container (LXC) aufgesetzt werden, um es in die bestehende Serverstruktur in Berlin zu integrieren. Außerdem sollen die bestehenden Benutzerkonten verknüpft oder importiert werden können. Eventuell muss eine Portweiterleitung am Router vorgenommen werden.

 

2.4   Ergänzende grafische Darstellungen

--------------------------------------------------

 

3.       Projektphasen mit Zeitplanung inkl. Teilaufgaben

1)      Planung – 8h

a.    IST-Analyse – 1h

b.   Erstellung SOLL-Konzept – 3h

c.    Vergleich von Produkten – 3h

d.   Kostenanalyse – 1h

 

2)      Realisierung – 14h

a.       Vergleich der Produkte in Testumgebung – 5h

b.      Installation und Konfiguration der Lösung auf Testserver – 5h

a.       (Abhängigkeiten installieren – 1h)

c.       Anbindung an LDAP bzw Benutzerkonten einrichten – 2h

 

3)      Testphase – 5h

a.    Auszüge aus alten Lösungen einpflegen  – 3h

b.   Live Test – 2h

 

4)      Projektabschluss – 7h

a.    Dokumentation – 6h

b.   Vorstellung im Unternehmen – 1h

 

Gesamt: 34h

 

4.       Geplante Präsentationsmittel

 

 

5.       Erklärung des Antragstellers

Link zu diesem Kommentar
Auf anderen Seiten teilen

Zuerst habe ich tatsächlich gedacht, dass du zwei verschiedene Dinge machen willst: Einmal die Entscheidung, welche Wiki-Software genutzt werden soll und dann als zweites, welche und -ob- das in einen Container verfrachtet werden soll. Das wäre natürlich weniger schön, weil es vollkommen reicht, eine Entscheidung zu evaluieren. 

Bei genauerem Lesen habe ich dann festgestellt, dass die Containervirualisierung eine betriebliche Einschränkung ist (ist tatsächlich auch so in 2.3 beschrieben. Dann kannst du das aus allen anderen Absätzen (oberhalb 2.3) rausschmeißen, denn das hat im Grunde genommen überhaupt nichts mit deinem Projekt zu tun. Du kannst ja (im aus IT-Sicht schlimmsten Fall) ein ganzes OS inkl. aller Abhängigkeiten und Software in einen Container packen, dementsprechend ist das für dein Projekt (eigentlich) keine Einschränkung.

 

vor 24 Minuten schrieb sTEWpITT:

Das Wiki soll isoliert aufgesetzt werden, damit es nicht von der Erreichbarkeit anderer Dienste abhängt. Jeder Mitarbeiter soll sich mit seinen LDAP-Daten im Wiki anmelden können und die für ihn freigegebenen Beiträge sehen und diese gegebenenfalls bearbeiten können.

Vielleicht fällt es dir selbst auf? Im Zweifel musst du im Antrag nicht allzu genau sein, das gibt dir in der Projektdurchführung viele Freiheiten ;)

 

 

Zum Vorgehen:

1. Wieso vergleichst du die Produkte in der Testumgebung NACHDEM du die Produkte schon evaluiert hast?

2. "Live-Test" ist mir unklar? Was soll das sein?

3. Gesamt 34h: Mach das auf 35h und stell eine Stunde mehr zur Doku zur Verfügung

 

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Danke für eure Antworten.

 

@Listener

Du hast Recht, ich werde die Virtualisierung erst als Einschränkung erwähnen und auch die Projektbezeichnung anpassen. Ich war der Meinung, dass es dem Projekt etwas mehr "Tiefe" gibt, da das Wiki dann ja tatsächlich direkt produktiv eingesetzt werden könnte, es also näher an der Realität ist. Ich hoffe es ist verständlich, was ich meine.

Zum Zitat: Ich weiß was du meinst, ich hatte die Befürchtung, das Ganze könnte zu "dünn" werden. 

Zum Vorgehen:
1. Die Auswahl an Software ist groß, die möchte ich am Anfang auf 3-4 Favoriten beschränken und mich dann auf einen festlegen. 
2. Ich wollte einigen Kollegen Beiträge im Wiki freigeben und mir Feedback geben lassen.
3. Wird gemacht.

 

@charmanta

Das stimmt. Ich weiß nicht, was du mir sagen möchtest, soll ich die Formulierung anpassen und aus "Lösung" "Software" machen? Oder ist das generell ein Kritikpunkt?

Das Problem ist, dass der momentane Zeitaufwand durch die Verteilung von Informationen auf verschiedene Quellen zu hoch ist. Mir fällt keine praktische Alternative ein, Knowlege Base und Forum existieren, sind aber meiner Meinung und der Kollegen nach nicht praktikabel und ich halte ein DMS halte für weniger sinnvoll, da nicht viele Dokumente abgelegt, angepasst und versioniert werden müssen.. Jetzt wo ich darüber nachdenke, wäre das vermutlich doch eine Alternative, aber vermutlich weniger flexibel und handlich. 

Danke für die Anregung, wäre mit einem Vergleich von Wiki und DMS und anschließender Installation eventuell mehr als ein 50:50 drin?

 

Noch einmal vielen Dank euch beiden!

Bearbeitet von sTEWpITT
Link zu diesem Kommentar
Auf anderen Seiten teilen

Dein Kommentar

Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung wiederherstellen

  Nur 75 Emojis sind erlaubt.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

Fachinformatiker.de, 2024 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...