Deployment von Excel Spreadsheets im Rahmen von Projektarbeit

Inhalt

1. Einleitung

2. Einführung in die Deployment-Problematik

3. Vorstellung des Ausgangsszenario

4. Szenario Untersuchungen
4.1. Hintergründe und Entwicklung sowie das Deployment per E-Mail
4.1.1. Probleme bei dem Deployment von Excel Spreadsheets per E-Mail
4.2. Deployment per Google Spreadsheets
4.2.1. Hintergründe und Entwicklung von Google Spreadsheets
4.2.2. Beispielhaftes Deployment mithilfe von Google Spreadsheets
4.2.3. Vorteile und Nachteile des Deployment mithilfe von Google Spreadsheets
4.3. Deployment mithilfe von EditGrid
4.3.1. Hintergründe und Entwicklung von EditGrid
4.3.2. Beispielhaftes Deployment mithilfe von EditGrid
4.3.3. Vorteile und Nachteile des Deployment mithilfe von Editgrid

5. Untersuchung der Softwarequalität

6. Fazit für ein KMU Unternehmen

7. Literaturverzeichnis

8. Linksammlung

9. Anhang
9.1. Szenario Arbeitsablauf
9.2. Beispiel Deployment Tabelle
9.3. Spreadsheets Comparison Matrix

1. Einleitung

Diese Hausarbeit wird sich mit der Thematik „Deployment^[1] von Excel Spreadsheets^[2] im Rahmen von Projektarbeit“ befassen. Bei der Durchführung von Projekten tritt oft das Problem auf, dass mehrere Personen Zugriff auf eine Datei haben müssen, um dort Informationen zu sammeln und auf Basis dieser Entscheidungen treffen zu können. Dabei ist insbesondere immer sicher zustellen dass externe beteiligte Personen immer auf dem gleichen Wissensstand gehalten werden, da diese oft nicht direkt auf die Dateien zugreifen können, z. B. wenn welche auf einem Firmennetzlaufwerk liegen. Größtenteils wird dieses Problem per E-Mail gelöst. Die vorliegende Arbeit will untersuchen, ob dies heute noch die beste Methode zur Lösung der oben genannten Problematik ist.

Im Folgenden wird ein Geschäftsprozess (Szenario) erarbeitet, in dem alle Beteiligten Instanzen abgebildet, in eine zeitliche Reihenfolge gebracht werden und nach der besten Softwarelösung gesucht wird, um dieses Schwierigkeit zu lösen. Zur Bewertung der hier vorgestellten Softwarelösungen werden diese nach einzelnen Qualitätsfaktoren untersucht. „Der primäre Qualitätsfaktor ist die Funktionalität.“^[3] Jedoch werden auch sekundäre Qualitätsfaktoren untersucht. Dabei ist zu beachten, dass „Qualitätsmerkmale wie z.B. Benutzerfreundlichkeit nur eingeschränkt objektiv bewertbar (oder gar quantifizierbar)“^[4] sind.

Es soll hier die Verwendung von Excel Spreadsheets, also Excel Tabellen, im Rahmen von Projektarbeit untersucht werden. Excel ist das Tabellenkalkulationsprogramm aus dem Programmpaket Microsoft Office. Es wird hier mit der Office Version 2003 von Excel gearbeitet, die im Rahmen von Windows XP als Standard verwendet wird.

Es wurde sich gegen die Verwendung von Office 2007 entschieden, da diese sich immer noch nicht als Standard gegenüber Office 2003 durchgesetzt hat. Vor allem die Import Problematik des neuen Excel 2007 Datei-Formats „.xlsx“ bei den hier untersuchten Deployment Methoden stellte sich als problematisch heraus. So ist es nicht möglich, dieses neue Dateiformat in EditGrid oder auch Google Spreadsheet als auch in Excel 2003^[5] ohne weiteres zu importieren.^[6]

2. Einführung in die Deployment-Problematik

Im Folgenden wird ein Deployment Szenario untersucht, welches oft im Rahmen von Softwareprojekten auftritt. Wenn eine Software entwickelt und diese im produktiven Betrieb eingesetzt wird, ist das Projekt noch nicht beendet. Denn es wird erst im „produktiven“ Betrieb ersichtlich, wie sich die Software im Alltag bewährt. So werden oft Fehler oder auch Änderungswünsche vom User erst später entdeckt oder gewünscht. Diese Informationen müssen von den Usern gesammelt und an die relevanten Projektmitarbeiter weiterverteilt werden, so dass diese auf Basis dieser Informationen Entwicklungsentscheidungen treffen können, wie z. B. Prioritäten vergeben. Die Projektmitarbeiter müssen dann die Probleme oder Änderungswünsche an die Entwickler weiterleiten, damit diese letztendlich gelöst bzw. bearbeitet werden können. Als letztes müssen dann die User und Projektmitarbeiter wieder über die Behebung von Fehlern oder Veränderungen innerhalb der Software informiert werden. Dieses Szenario ist Teil des Change-Managements^[7] und tritt gerade im Rahmen der Entwicklung von Individualsoftware^[8] verstärkt auf.

Zur Lösung dieser Problematik wird sich die vorliegende Arbeit mit den Deployment Methoden per E-Mail, per Google Spreadsheet und per EditGrid beschäftigen. Dabei ist zu beachten, dass es sich bei den zwei letzten Methoden nicht um reine Deployment Tools handelt, sondern sich mit diesen Tools „Excel“ Tabellen erstellen und weiterverarbeiten lassen. Auch handelt es sich bei diesen Tools um Freeware^[9] Programme, die somit kein kostenpflichtiges MS^[10] Office 2003 voraussetzen, da man mit ihnen Excel Dateien importieren oder exportieren kann. Es wurde sich für EditGrid und Google Spreadsheet entschieden, da diese beiden die meisten Userzahlen haben, wobei Google Spreadsheet mit 694.000 Besuchern pro Monat gegenüber 22.834 Besuchern bei Editgrid klar liegt.^[11] Des Weiteren gehören die beiden letzten Tools zu der Gruppe Office 2.0 Anwendungen^[12]. Darunter ist zu verstehen, dass Anwendungen auf Internetseiten ausgeführt werden und nicht mehr lokal auf dem Rechner installiert sein müssen.^[13]

Insbesondere der Freeware Charakter ist für Kleinstunternehmen sowie kleine und mittlere Unternehmen (KMU), die 99% des Unternehmensbestands innerhalb der 25 Mitgliedsstaaten der Europäischen Union ausmachen, sehr interessant.^[14] Diese KMU Perspektive wird im Folgenden unter anderem wegen der oben genannten Gründe sowie zur Vereinfachung der Szenarien auf Grundlage der geringeren Anzahl der beteiligten Personen angenommen.

3. Vorstellung des Ausgangsszenario

Eine grafische Veranschaulichung des folgenden Szenarios ist im Anhang zu finden.^[15]

Im ersten Arbeitsschritt trägt der Trainer die von den Usern aufgenommenen Fehler (Bugs) und Änderungswünsche (Change Requests = CRs) in die Excel Tabelle im Feld “Beschreibung“ ein. Danach vergeben sie im Feld „PRIO“ eine Priorität, die von eins (sehr dringend) bis drei („nice to have“) reicht. Im Feld „Status“ pflegen sie den Status „offen“ ein.

Im darauf folgenden zweiten Arbeitsschritt entscheidet der Projektleiter, ob es sich „vertraglich“ um einen BUG oder CR handelt.

Unter vertraglich ist hier zu verstehen, dass im Rahmen einer externen Programmierung die Abrechnung von Bugs und CRs getrennt verläuft. So sind Bugs vom Dienstleister (Firma, die mit der Entwicklung der Software beauftragt ist) erzeugte Kosten, da die Anforderungen nicht fehlerfrei in die Software umgesetzt wurden. Bei CRs hingegen handelt es sich um zusätzlich Neuerungen, die der Auftraggeber (z. B. ein Immobilienunternehmen) in die Software implementiert haben möchte.

Deshalb werden Bugs von dem Dienstleister gratis erledigt und für CRs muss der Auftraggeber im Normalfall die Programmierstunden extra bezahlen. Unter anderem werden Bugs deswegen meist auch schneller gelöst als CRs, da sie auf Fehlern der Programmierer beruhen.

Der Projektleiter überprüft die von den Trainern vergebene Priorität und vergibt gegebenenfalls eine höhere oder niedrige. Des Weiteren kann er den Status „Abgelehnt“ vergeben, wenn seiner Meinung nach der vorgeschlagene CR keinen Sinn machen oder gar ein Anwendungsfehler als Bug dargestellt wird.

Danach überprüft der IT Releasemanager die neuen Tickets, leitet diese an den Dienstleister weiter und trägt im Feld Status den Status „Reported“ ein. Oft geschieht dies über ein Tool, in welches er den Fehler einträgt und beschreibt. Von diesem Tool wird schließlich eine eindeutige Ticket ID vergeben, die er in das Feld Ticketnummer der Exceltabelle einträgt. Ist ein Bug oder CR gelöst, so trägt er „Erledigt“ im Status ein.

Um die User und Trainer über die getroffenen Entscheidungen und gefundene sowie gelöste Fehler und Änderungswünsche auf dem Laufenden zu halten, verteilt der Relationshipmanager IT die Excel-Tabelle an alle Anwender (z. B. Trainer, Endanwender, IT Beteiligten), aber auch an externe Dienstleister, jedoch pflegt er vorher im Feld „Beschreibung“ die unternehmensübliche Ausdrucksweise ein.

4. Szenario Untersuchungen

4.1. Hintergründe und Entwicklung sowie das Deployment per E-Mail

Seit dem Ende der 1980er Jahre ist die E-Mail als das Standardkommunikationsmittel im Internet nicht mehr wegzudenken. Im Rahmen des Projektes per E-Mail würden die einzelnen Trainer die Fehler oder Änderungswünsche, die ihnen im Rahmen von z. B. Schulungen auffallen, in der Excel-Tabelle beschreiben. Sie geben an, ob es sich nach Ihrer Meinung um einen Fehler oder Änderungswunsch handelt und vergeben die Priorität des einzelnen „Tickets“. Zusätzlich wird im Statusfeld der Status „Offen“ eingetragen. Am Ende eines Tages würden sie dann diese Excel-Tabelle an den Projektleiter des Softwareentwicklungsprojektes weiterschicken. Dieser sammelt diese in einer Excel- Tabelle, falls er von mehreren Trainern eine Excel-Tabelle bekommen hat. Der Projektleiter entscheidet sich darauf hin, ob es sich um einen CR oder Bug handelt.^[16] Er entscheidet in letzter Instanz über die Priorität und ändert diese im gegebenen Falle ab. Des Weiteren kann er entscheiden, ob einzelne Änderungswünsche oder Bugs auf Grund von z. B. fehlerhafter Bedienung abgelehnt werden. In diesem Falle würde er dem Ticket den Status abgelehnt vergeben. Nachdem er alle Tickets überprüft und alle neuen Tickets aufgenommen hat, schickt er diese an den IT Releasemanager. Dieser berichtet über die Tickets an die Entwickler, z. B. in dem er es in deren Reporting Tool einträgt. Er pflegt in diesem Falle den Status „Reported“ sowie die Ticketnummer, die durch deren Tool generiert wurde, ein. Wenn „alte“ Tickets bereits erledigt wurden und er diese erfolgreich getestet hat, vergibt er den Status „Erledigt“ mit Datum versehen ein. Danach schickt er diese Excel-Tabelle mit allen alten und neuen Tickets an den Relationshipmanager IT. Dieser pflegt das Corporate Wording ein und verteilt einmal in der Woche (z. B. Freitags) die Excel List an die User, Trainer, Projektleiter und IT Releasemanager.

4.1.1. Probleme bei dem Deployment von Excel Spreadsheets per E-Mail

In diesem Szenario, bei dem das Excel Spreadsheet Deployment per E-Mail erfolgen würde, müssten bis zum Relationshipmanager 3 E-Mails versendet, bearbeitet und weitergeleitet werden, unter der Annahme, dass es nur einen Trainer geben würde. Der Workflow wäre vom Trainer an den Projektleiter. Der Projektleiter sendet die zusammengefügte Tabelle weiter an den IT Releasemanager und jener weiter zum Relationshipmanager der IT. Dabei müsste jedes Mal die Excel-Tabelle aus dem Anhang der E-Mail entfernt werden, lokal gespeichert, bearbeitet und weitergeleitet werden. Der Projektleiter würde die Excel-Tabelle sehr wahrscheinlich von mehr als einem Trainer bekommen und müsste diese Tabellen dann zusammenführen. Das Hauptproblem bei dieser Deployment Methode ist, dass nachdem die Trainer die E-Mails verschickt haben, sie keine Ahnung haben, wie der Status der einzelnen Tickets ist, bis die Excel-Tabelle vom Relationshipmanager erneut verschickt worden ist.^[17] Des Weiteren gibt es keine Excel-Tabelle, auf die sich alle gleichzeitig unter der Annahme stützen könnten, dass jede E-Mail einen Tag Bearbeitungszeit benötigt. Pro Instanz würden für den reinen Durchlauf des Workflow 3 Tage benötigt. Jedoch fielen dem Trainer innerhalb der drei Tage neue Fälle auf. Die Trainer würden dann, wenn z. B. die zuvor gesendete Excel-Tabelle gerade vom IT Releasemanager bearbeitet würde, eine neue an den Projektleiter schicken. Somit würde das Problem bestehen, dass sie von dem Relationshipmanager die Übersicht aktualisiert zurückbekamen, dass noch „offene“ Fälle z. B. beim IT Releasemanager sind. Dies kann auch der Fall sein von anderen Trainern, von denen der einzelne Trainer nichts weiß. Dies könnte man unterbinden in dem jede Instanz verpflichtet ist, an einem bestimmten Tag der Woche die bearbeitete Excel-Tabelle an die nächste Instanz zu schicken. Dabei hingegen, dass Problem dabei wäre das dadurch Entwicklungszeit verloren gehen könnte, da so der IT Releasemanager nur einmal pro Woche (bei einer 5 Tage Arbeitswoche) an die Entwickler berichtet.

Gerade dieser lineare Charakter dieser Deployment Methode ist einer der Hauptnachteile, denn das Szenario muss komplett durchlaufen werden und es nicht möglich, dass in jedem Arbeitsschritt alle Beteiligten auf den aktuellen Stand der Tabelle zugreifen können und somit diese in jedem Arbeitsschritt bearbeiten können.

4.2. Deployment per Google Spreadsheets

4.2.1. Hintergründe und Entwicklung von Google Spreadsheets

Bei Google Spreadsheets handelt es sich um eine Online-Lösung, die von Google angeboten wird. Es werden alle aktuellen Browser unterstützt^[18]. Man richtet sich unter www.googlemail.com ein Benutzerkonto ein und kann dann bei den von beispielsweise Google angebotenen Diensten den Menüpunkt Text & Tabellen auswählen. Dort kann man Tabellenblätter erstellen oder bestehende importieren. Diese sind unter einem Link zu erreichen. Google Spreadsheets ist ein teil von Google Docs so wie Excel ein Teil des Softwarepakets MS Office ist. Google Docs ist wiederum ein Teil von Google Apps.^[19] Unter diesem Namen fasst Google Ihre Online Applikationen zusammen. Diese Entwicklung, Office Anwendungen Web basiert für die Anwender kostenlos zur Verfügung zu stellen, ist eine der interessantesten Entwicklungen der letzten Jahre, weil sich dadurch die TCO (Total Cost of Ownership) gerade für KMU Unternehmen senken lassen, da sie keine Lizenzgebühren und Serverkosten verursachen, so wird schon von Office 2.0 gesprochen.^[20] Jedoch wird Google Apps in drei verschiedenen Versionen angeboten, von denen eine kostenpflichtig ist und sich durch einen besseren Support und eine bessere Integration in bestehende IT Infrastrukturen einbinden lässt.^[21]

[...]

^[1] deployment = die Verwendung / die Entsendung

^[2] Spreadsheet = die Tabelle

^[3] Fink/Schneidereit/Voß (2005) S.183

^[4] Fink/Schneidereit/Voß (2005) S.183

^[5] Microsoft stellt ein Update für Excel 2003 zu Verfügung welches diese Problem löst: http://support.microsoft.com/kb/924074/de?spid=2512&sid=1374

^[6] Vgl. Abschnitt 9.3 die Tabelle: Spreadsheets Comparison Matrix

^[7] Siehe zum Thema Change-Management: Hansen und Neuman (2005) S.260 ff

^[8] Siehe zum Thema Standartsoftware und Individualsoftware: Hansen und Neumann (2005) S.165 und S.213-215

^[9] Unter dem Begriff Freeware Software ist zu verstehen, dass diese Programm kostenlos oft über das Internet zu beziehen sind.

^[10] MS = Microsoft

^[11] Dieses Bild relativiert sich etwas. Vgl. EditrGrid Blog. URL: http://blog.editgrid.com/archives/365

^[12] Vgl. Ismael Ghalimi URL: http://itredux.com/blog/office-20/ und eine Übersicht von Office 2.0 Anwendungen Ismael Ghalimi URL: http://o20db.com/db/setup/

^[13] Vgl. Artikel Stephan Lamprecht in Computerwoche 21.02.2007 URL: http://www.computerwoche.de/produkte_technik/software/588439/ und Ismael Ghalimi URL: http://itredux.com/blog/2006/01/25/rules-for-office-20/

^[14] Vgl. Benutzerhandbuch zur neuen KMU Definition (2006) S.5

^[15] Siehe Szenario Arbeitsablauf auf S.- 14 -

^[16] Wie oben bereits beschrieben ist diese Unterscheidung vor allem aus Abrechnungsgründen wichtig.

^[17] Dies könnte man unterbinden in dem man alle Beteiligten verpflichtet in jedem Arbeitsschritt alle Beteiligten beim versenden der E-Mail in Kopie zu setzen.

^[18] System Anforderungen von Google sind unter folgenden Link zu finden: URL: http://docs.google.com/support/bin/answer.py?answer=37560

^[19] Weitere Information unter: URL: http://www.google.com/a/

^[20] Vgl. den Artikel URL: http://www.pluggd.in/2007/10/online-office-apps-challenges-misconception-and-future-complete-coverage

^[21] Vgl. die 3 Editionen und deren Funktionsumfang: URL: http://www.google.com/a/help/intl/en/admins/editions_spe.html