mpetric23 Geschrieben 29. Januar 2014 Teilen Geschrieben 29. Januar 2014 Hallo Zusammenm, ich bin ein dualer Student der Wirtschaftsinformatik und bei mir steht nun die Anfertigung einer Praxisarbeit an. Die Praxisarbeit wird immer in Zusammenarbeit mit dem Unternhemen angefertigt bei dem ich beschäftigt bin. Da in meinem Unternhemen aktuell die Migration des Webtools JIRA (von der Version 5.2 auf 6.0.8) ansteht habe ich diese zu meinem Projekt und Thema der Praxisarbeit gemacht. Hier tun sich mir jedoch noch eingige Fragen auf bei denen ihr mir hoffentlich helfen könnt. Gehe ich richtig in der Annahme, dass die eigentliche Migration der Software beim Herausgeber des Webtools stattfindet? Die eigentliche Migration ist ja die Umstellung, Entwicklung des Programms in der neune Version oder sehe ich das falsch? Im Unternehmen findet doch eigentlich nur noch ein Upgrade statt oder nicht? Ich hoffe ihr könnt mir helfen und eure Meinung dazu mitteilen. Vielen Dank im Voraus! Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
pr0gg3r Geschrieben 29. Januar 2014 Teilen Geschrieben 29. Januar 2014 Die eigentliche Migration ist ja die Umstellung, Entwicklung des Programms in der neune Version oder sehe ich das falsch? Jein, die Migration ist das Einführen einer neuen Software (oder Version), die eine andere Software (bzw. Version) ersetzt. Das heißt, es muss ein Konzept erstellt werden, die bestehenden Daten müssen ggf. in ein anderes Format gebracht werden, Rechte angeapsst werden, Mitarbeiter geschult werden, das ganze muss getestet und dokumentiert werden usw. Anschließend kann das Rollout vorgenommen werden (die Tatsächliche Installation Software). Das hat weniger mit der Entwicklung einer Software (ggf. muss die Software angepasst werden) zu tun, als mit der Einführung einer Software. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
mpetric23 Geschrieben 30. Januar 2014 Autor Teilen Geschrieben 30. Januar 2014 Hallo, erst einmal Vielen Dank für die Rückmeldung. Also verstehe ich dass dann jetzt richtig, dass die arbeiten die bei dem Unternhemen, welches die Software entwickelt, sprich die Entwicklung der neuen Version, noch nichts mit dem eigentlichen Migartionsprozess zu tun haben? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
SaJu Geschrieben 30. Januar 2014 Teilen Geschrieben 30. Januar 2014 Was Du machen sollst ist ein Upgrade, bzw. die Migration der Software/ des Bugtracking-Tools in der Firma. Atlassian entwickelt die Software und stellt sie dem Kunden bereit. Diese testen die Kunden und migrieren (installieren) sie in die IT. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
mpetric23 Geschrieben 30. Januar 2014 Autor Teilen Geschrieben 30. Januar 2014 (bearbeitet) Okay: Also versteht man im Softwarebereich unter einer Migration die Überführung, eines Softwaresystems aus einer alten Umgebung in eine andere, neue Zielumgebung. Dies würde für meinen Fall jetzt Bedeutung: Softwaresystem = die Daten in Jira -> Workflows, Rollen, Berechtigungen,.... Alte Umgebung = JIRA 5.2 Zielumgebung = JIRA 6.0.8 Migration = Transport der Daten usw. von der Version 5.2 in die Version 6.0.8 Sehe ich das jetzt richtig? Bearbeitet 30. Januar 2014 von mpetric23 Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
pr0gg3r Geschrieben 30. Januar 2014 Teilen Geschrieben 30. Januar 2014 Migration = Transport der Daten usw. von der Version 5.2 in die Version 6.0.8 Sehe ich das jetzt richtig? Jein, das kann man unter Migration sehen, meist spricht man aber in einem "größeren" Umfeld von Migration. Stell dir vor, alle in deinem Unternehmen haben Microsoft Office 2003. Die Probleme mit der Inkompatibilität mit anderen Unternehmen wird ständig größer. Also müsst ihr ein Update machen: Hier beginnt der Migrationsprozess. Ihr überlegt euch, welche Version ihr benötigt. Macht es Sinn, auf Office 2007, Office 2010 oder auf die nächste Version zu warten. Das haltet ihr dann in der Dokumentation fest. Sagen wir einmal, ihr kommt darauf, 2010 zu verwenden. Dann schaut ihr natürlich, wie viele Installationen benötigt werden und welche Lizenzen dazu am besten passen. Habt ihr das nun gekauft, fangt ihr an, das ganze zu testen. Weil ihr von Heute auf morgen nicht hunderte Office auf einmal updaten könnt, testet ihr erstmal das neue Office nach Abwerts- und Aufwertskompatibilitäten. Dabei kommt ihr darauf, dass ihr für den Zeitraum, bei dem beide Versionen verwendet werden, ein Kompatibilitäts-Packet bei den alten Versionen installieren müsst. Das geht der eigentlichen Installation von Office 2010 vorraus. Nun können alle miteinander arbeiten, egal welche Version sie haben und ihr könnt damit beginnen, die Installationen nach und nach vorzunehmen. Eventuell habt ihr vorher alle alten Office-Dateien in die neuen umgewandelt. Nun habt ihr noch das Problem, dass Office 2010 total anders aussieht und verhält als die alte 2003er-Version. Also nehmt ihr noch die Mitarbeiter und schult sie, was sich geändert hat usw. Nun ist die Software überall verteilt (ausgerollt) und alle (hoffentlich) happy. Der Migrationsprozess ist damit beendet. Das ist jetzt natürlich nur eine rein fiktive Situation als Beispiel, das Prinzip aber ähnlich. Wenn man ein Serverprogramm hat und installiert dort eine neue Version, würde ich weniger von Migration als von einem Update reden. So gesehen kann man sagen, dass eine Migration immer eine Prozesskette ist, ein Upgrade aber nur ein Punkt. Zusätzlich hat Migration weniger mit der Softwareentwicklung als mit der Anwendung zu tun. Natürlich kann man aber auch von "Daten migrieren" reden, wenn Daten, die in Excel-Tabellen festgehalten sind, in eine SAP-Datenbank verschiebt. Das macht aber der Anwender und nicht der Softwarehersteller. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
mpetric23 Geschrieben 30. Januar 2014 Autor Teilen Geschrieben 30. Januar 2014 Vielen Dank für dein gutes Beispiel! Ganz so groß ist das Projekt der Jira Migration natürlich nicht. Beispielsweise kann auf eine Schulung der Anwender verzichtet werden. Aber der der Gedankengang über so eine Schulung nachzudenken und die Entscheidung keine Schlung durchzuführen gehört sicherlich auch schon zum Migrationsprozess dazu. Eine Frage hätte ich da noch: Was genau beziechnet das Legacy System? Wäre das in deinem Beispiel Office 2003 bzw. in meinem Fall Jira 5.2? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
paperdoll Geschrieben 30. Januar 2014 Teilen Geschrieben 30. Januar 2014 Auch aus einem Softwareupdate könnte man einen Migrationsprozess entwickeln. Wenn zB. das eingesetzte Serversystem auf dem eure Software gehostet wird noch Server 2003 32 Bit ist und mit der neuen Version nun Server 2012 und 64 Bit Systeme voll unterstütz werden zudem evtl. noch eine Datenbank mitläuft könnte man von einer Migration der Software auf ein aktuelles Serversystem sowie einer Migration der Daten sprechen. Hierbei ergeben sich dann noch weitere Aspekte wie zB. Kompatibilität zur eingesetzten Datensicherung, Überlegungen zur Virtualisierung falls noch phys., Sizing des neuen Servers und natürlich wie schon angesprochen Dokumentation. Es kann natürlich sein das ich hier ein wenig am Thema vorbei rede, da ich nicht weiß was Jira ist und was dahinter steckt. Aber was ich eigentlich sagen möchte ist... man kann aus einem evtl. nun klein wirkenden Update einer Software auch eine art Projekt machen. Gruß paper Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
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.