<\/p>\n
Christoph Spielmann, Düsseldorf<\/b><\/p>\n
Access im Unternehmen möchte Ihnen nicht nur die technischen Grundlagen und Hintergründe für die Softwareentwicklung bieten, sondern auch dabei helfen, die bei der Organisation auftretenden Klippen zu umschiffen. Den ersten Schritt haben wir in Ausgabe 6\/2004 gemacht. Im Beitrag „Das optimale Pflichtenheft“ haben Sie erfahren, wie Sie ein Pflichtenheft so erstellen, dass bei der späteren Software-Entwicklung möglichst wenig Probleme auftreten. Im vorliegenden Beitrag gehen wir einen Schritt weiter: Hier lernen Sie den weiteren Ablauf nach dem Projekt-Startschuss kennen.<\/b><\/p>\n
Ob für ein Software-Projekt ein Konzept in schriftlicher Form erstellt werden soll, hängt maßgeblich von der Komplexität der Anforderungen, der Dauer des Projekts sowie der Anzahl und dem Erfahrungsschatz der an dem Projekt beteiligten Programmierer ab.<\/p>\n
Ziel des Konzepts ist es, die Architektur der Anwendung festzulegen sowie die einzelnen Prozesse in kleinere Häppchen zu zerlegen, die sich gut programmieren lassen und möglichst klare Schnittstellen zu den anderen Modulen haben. Anhand dieser Programmteile können Sie dann auch die Arbeiten besser auf die einzelnen Programmierer verteilen.<\/p>\n
Kritische Prozesse, die entweder sehr komplex sind oder von der Abarbeitungsgeschwindigkeit her Probleme machen könnten, sollten Sie sehr genau beschreiben. Gegebenenfalls ist es hier auch erforderlich, den Prozess bereits im Vorfeld auf eine optimale Performance hin zu planen und auch kleinere Testprogramme zu erstellen. Wichtig ist hierbei die Tatsache, dass performance-optimierter Code zwar schneller ist, in der Regel jedoch auch einen komplexeren Aufbau hat und damit schwerer zu verstehen ist oder keine ausreichende Flexibilität gegenüber neuen Anforderungen aufweist. Die Optimierung sollte also nur so weit wie nötig erfolgen.<\/p>\n
Wenn ein Konzept in schriftlicher Form vorliegt, ist eine zusätzliche Dokumentation während der Entwicklung in der Regel nicht erforderlich. Sollten sich jedoch Abweichungen vom Konzept ergeben, müssen diese auf jeden Fall festgehalten werden. Der Grund für Abweichungen kann entweder in geänderten Anforderungen während der Programmierung liegen – zum Beispiel, wenn der Kunde einen Zwischenstand begutachtet und ihm etwas nicht gefällt – oder auch durch technische Probleme ausgelöst werden. In letzterem Fall kann sich ein ursprünglich geplanter Weg bereits während der Programmierung als zu aufwändig herausstellen oder aber gänzlich unmöglich sein – beispielsweise wenn ein Import von einem anderen System erfolgen soll, von diesem die benötigten Daten aber nicht zur Verfügung gestellt werden. In allen Fällen sollte zusammen mit dem Kunden ein Kompromiss vereinbart, schriftlich festgehalten und von allen Beteiligten genehmigt werden.<\/p>\n
Bereits in der Pflichtenheft-Phase wird der Aufwand zur Realisierung des Projekts grob abgeschätzt. In der Regel kommt hierbei die Einheit „Mann-Monate“ oder „Mann-Jahre“ zum Einsatz, da während der Planung oft noch nicht feststeht, wie viele Personen später an der Entwicklung beteiligt sind.<\/p>\n
Nach dem Erstellen des Konzepts und Zusammenstellung des Projektteams sowie erfolgter Aufgabenverteilung kann der Zeitpunkt der Fertigstellung jedoch in der Regel recht genau festgelegt werden.<\/p>\n
Nicht vernachlässigt werden darf hierbei der Zusatzaufwand bei größeren Projekt-Teams aufgrund der Reibungsverluste. Ab einer Team-Größe von fünf Personen steigt der Koordinationsaufwand stark an, sodass in der Regel zusätzliche Ressourcen für das Projekt-Management und die Koordination zwischen den Projektmitgliedern eingeplant werden müssen.<\/p>\n
<\/p>\n
Im Gegenzug sinkt bei großen Projektteams das Ausfall-Risiko. Wenn beispielsweise ein Mitarbeiter von insgesamt zehn Mitarbeitern ausfällt, fällt dies nur wenig ins Gewicht. Die übrigen können den Mehraufwand untereinander aufteilen oder zumindest die Einarbeitung eines neuen Mitarbeiters gemeinsam übernehmen. Bei kleinen Projektteams sollte dagegen ein großzügiger Puffer eingeplant werden, um Ausfälle ohne größeren Schaden zu überstehen.<\/p>\n
Die wichtigsten Projektdokumentationen sind Stundenzettel. Hier sollten alle beteiligten Personen genau festhalten, wie viel Zeit sie mit welcher Projektaufgabe verbringen. Auch wenn das Projekt zu einem Festpreis erstellt wird, sollte auf jeden Fall ein Stundenzettel geführt werden. Nur so besteht später die Chance einer Nachberechnung, falls mehr Stunden als geplant in das Projekt investiert wurden.<\/p>\n
Bereits während der Programmierung kann anhand des Stundenzettels zuverlässig festgestellt werden, ob der ursprünglich vorgesehene Zeitplan eingehalten werden kann. Bei drohender überziehung können so geeignete Maßnahmen – sei es in Form zusätzlicher Mitarbeiter oder der Absprache eines neuen Zeitplans mit dem Kunden – eingeleitet werden.<\/p>\n
Um eine gute Qualität der Software sicherzustellen, sollten bereits während der Programmierung Tests der einzelnen Programmteile durchgeführt werden. In erster Reihe stehen hierbei die Programmierer, die ihren eigenen Code generell auf korrekte Funktionsweise prüfen sollen. Gegebenenfalls muss hierbei eine kleine Testumgebung entwickelt werden, sodass einzelne Module auch unabhängig von anderen Modulen ausgeführt und geprüft werden können. Auch das Unit-Testing-Verfahren kann hierbei wertvolle Hilfestellung leisten.<\/p>\n
Wenn ein Programmierer seine Programmteile für fehlerfrei erklärt und abschließt, sollte ein anderer Mitarbeiter einen Test vornehmen und die aufgetauchten Fehler dokumentieren. Wichtig sind insbesondere Fehler, die andere Module beeinflussen. Hier muss dafür gesorgt werden, dass die entsprechenden Projektteilnehmer informiert werden.<\/p>\n
Die technische Dokumentation wird in der Regel nach Abschluss der Programmierarbeiten erstellt. Hier soll der Aufbau der Software erklärt werden, sodass sich fremde Programmierer mit vertretbarem Aufwand einarbeiten können. Weiterhin werden hier alle änderungen zum Konzept festgehalten, die aufgrund von technischen Schwierigkeiten durchgeführt wurden. Für fremde Programmierer ist es nämlich oft nicht nachvollziehbar, warum ein auf den ersten Blick komplizierter Weg zur Lösung eines Problems gegangen wurde, da ihm das dahinter stehene Problem nicht genau bekannt ist.<\/p>\n
Generell sollten in der technischen Dokumentation alle Formulare, Berichte, Klassen und sonstige Objekte aufgeführt und kurz beschrieben werden. Weiterhin sollte erklärt werden, welche Daten die einzelnen Module von anderen Modulen beziehen und ob und wie sie diese verändern.<\/p>\n
Um einen überblick über das Gesamtsystem zu erhalten, sollte die Architektur der Software in Form von Blockdiagrammen dargestellt werden. Auch die Kommunikation mit anderen Systemen sollte dokumentiert werden. Dazu zählen beispielsweise die Formate, in denen die Daten ausgetauscht werden.<\/p>\n
In der Regel sollte eine Software mit Benutzerhandbuch ausgeliefert werden. Der Aufwand für die Erstellung dieses Handbuchs ist nicht zu unterschätzen und muss daher bei der Aufwandskalkulation unbedingt berücksichtigt werden. Weiterhin sollte der grobe Umfang des Benutzerhandbuchs mit dem Kunden abgesprochen werden, damit es hier später nicht zu Dissonanzen kommt.<\/p>\n
In der Praxis werden in der Regel zwei getrennte Dokumentationen erstellt: Eine für den normalen Benutzer und eine für den System-Administrator.<\/p>\n
In der Version für den Administrator sollten alle Schritte festgehalten werden, um die Software auf einem neuen PC zu installieren. Dazu zählen beispielsweise die Auflistung aller Komponenten, die zum Betrieb der Software erforderlich sind, sowie die erforderliche Installationsreihenfolge.<\/p>\n
Wenn beispielsweise ein SQL-Server erforderlich ist, sollte genau erklärt werden, welche Voraussetzungen der SQL-Server erfüllen muss (beispielsweise die Plattenkapazität) und wie eine leere Datenbank auf dem Server erzeugt werden kann. Weiterhin muss festgehalten werden, wo welche Einstellungen auf den Client-PCs vorzunehmen sind, damit diese auf den Server zugreifen können. Auch die Einrichtung des Sicherheitssystems und der Benutzergruppen sollte exemplarisch erklärt werden.<\/p>\n
Ziel sollte es sein, dass ein technisch versierter Administrator ein komplett neues System ohne Hilfe des Herstellers aufsetzen kann.<\/p>\n
Das eigentliche Benutzerhandbuch für den Endbenutzer sollte die Arbeit mit der Software gut und übersichtlich beschreiben. Im Einzelfall muss hierbei abgestimmt werden, ob das Handbuch auch die generellen Geschäftsabläufe erklären soll, die von der Software unterstützt werden, oder ob diese als bekannt vorausgesetzt werden können. In ersterem Fall ist es hilfreich, wenn sich ein Mitarbeiter des Kunden an der Erstellung der Dokumentation beteiligt, damit die Abläufe in dem richtigen Fach-Vokabular erklärt werden.<\/p>\n
Wenn Software sowie Dokumentation fertig gestellt sind, erfolgt die Abnahme. Hierbei prüft der Kunde die Software auf Vollständigkeit und korrekte Funktionsweise.<\/p>\n
Diese Prüfung sollte in enger Zusammenarbeit zwischen dem Kunden und dem Projektleiter erfolgen. Alle relevanten Punkte sollten hierzu in einem Abnahme-Protokoll festgehalten werden. Punkte, die nicht den Anforderungen entsprechen, sollten genau beschrieben werden und nach Korrektur zu einem zweiten Abnahme-Termin erneut geprüft werden. Hierbei sollte der Kunde motiviert werden, die einzelnen Punkte gründlich zu prüfen und einmal abgehakte Punkte nicht erneut auf die Tagesordnung zu setzen. Die Abnahme sollte daher straff organisiert sein.<\/p>\n
Nach dem Abschluss der Abnahme erfolgt in der Regel die Einführung der Software. Zunächst sollte hierbei ein kleiner Nutzerkreis gewählt werden, damit Fehler schnell und effektiv behoben werden können. Schritt für Schritt sollten dann weitere Benutzer hinzugezogen werden, bis die Software letztendlich voll zu Einsatz kommt und hoffentlich problemlos funktioniert.<\/p>\n","protected":false},"excerpt":{"rendered":"
Access im Unternehmen möchte Ihnen nicht nur die technischen Grundlagen und Hintergründe für die Softwareentwicklung bieten, sondern auch dabei helfen, die bei der Organisation auftretenden Klippen zu umschiffen. Den ersten Schritt haben wir in Ausgabe 6\/2004 gemacht. Im Beitrag „Das optimale Pflichtenheft“ haben Sie erfahren, wie Sie ein Pflichtenheft so erstellen, dass bei der späteren Software-Entwicklung möglichst wenig Probleme auftreten. Im vorliegenden Beitrag gehen wir einen Schritt weiter: Hier lernen Sie den weiteren Ablauf nach dem Projekt-Startschuss kennen.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"footnotes":""},"categories":[66012005,662005,44000040],"tags":[],"class_list":["post-55000263","post","type-post","status-publish","format-standard","hentry","category-66012005","category-662005","category-Allgemein"],"yoast_head":"\n