Anforderungsdokument, Fachkonzept, DV-Konzept, … wozu braucht man eigentlich mehr als ein Dokument, in dem alle Vorgaben für die Entwicklung eines Software-Systems enthalten sind?

Zunächst einmal ist eine begriffliche Klärung notwendig. Viele Projektbeteiligte bezeichnen quasi alles, was in irgendeiner Form bereitgestellt wird, damit die Entwicklungs-Firma ihre Arbeit machen kann, als Spezifikation – oft als Anforderungs-Spezifikation, bezeichnet. Das erweckt den Eindruck, als ob in all diesen Dokumenten irgendwie das Gleiche stehen würde. Aber es gibt riesige Unterschiede. Den ganzen Beitrag lesen »

Immer wieder sind Business-Analysten und Software-Architekten unter Druck: Ihre Arbeit verzögert den beginn der Programmierarbeiten und scheint damit auch den Termin der Produktivsetzung einer Software zu gefährden. Der Projektmanager und der Kunde sind oft der Meinung, die Anforderungen seien nun allen genug klar, die optimale Systemarchitektur hinreichend genau entworfen, man solle doch endlich mit der Implementierung beginnen.

Es ist nicht immer falsch, auf einen zügigen Abschluss der Konzeptionsphase eines Projektes zu drängen. Allen beteiligten muss aber klar sein, dass das Risiko für Fehlentwicklungen umso großer ist, desto weniger ausgereift die Analyse- und Designdokumente bei Beginn der Implementierung sind.

Die Frage ist, wieviel Risiko das Projekt verträgt. Das ist von verschiedenen Faktoren abhängig. Manche Projekte, die nicht den Kernbereich der Geschäftsprozesse betreffen, und bei denen eine kurzfristige Verschiebung des Produktivstarts oder eine Kostenüberschreitung nicht für das Kerngeschäft des Unternehmens kritisch ist, vertragen ein höheres Risiko, bei anderen muss das Risiko jeder Planungsabweichung extrem minimiert werden.

Nur die nüchterne Risikoabwägung kann zur Festlegung des richtigen Konzeptionsaufwandes führen.

In der heutigen FAZ gab es einen Artikel, der online leider nicht verfügbar ist, in dem von Kosteneinsparungen von bis zu 30 € pro Geschäftsvorfall berichtet wird, wenn Rechnungsstellung und -bearbeitung vollständig digitalisiert werden. Es wird ein Geschäftsprozess angenommen, bei dem eine Rechung automatisch erstellt und versandt wird (oder in einem Online-Formular der Bank angelegt wird), die der Empfänger dann per Mausklick bezahlt.

Auch wenn das in konkreten Geschäftsmodellen und -prozessen so einfach nicht immer möglich sein wird – die Digitalisierung des Rechnungsverkehrs ist tatsächlich bereits in vollem Gange. Der der Automatische Versand von Rechnungen in Form von signierten PDF-Dateien im Zuge der Fakturierung, die Archivierung solcher Dateien beim Kunden bzw. die Einspeisung dieser Rechnungsdateien in Workflow-Management-Systeme, all das haben wir bereits in Projekten realisiert. Eine andere Möglichkeit, die gerade von großen Dienstleistern in den letzten Jahren verstärkt genutzt wird, ist bekanntlich die Bereitstellung von Rechnungen auf Internet-Portalen, die dann vom Kunden On-Demand abgerufen werden.

Die Techniken, um solche Rationalisierungen sicher und stabil umzusetzen, sind bekannt und erprobt. Jetzt müssen sie nur noch in der Breite in bestehende Systeme oder Individuallösungen umgesetzt werden.

Wer in Java Strings verknüpfen/verketten möchte und
das in grösserern Zahl, z.B. in einer Schleife, sollte
tunlichst vermeiden diese Strings per Addition zu verbinden:

String a = “Ma”;
String b = “i”;
String c = “k”;
String d = a + b + c;
//d = “Maik”

Erheblich performanter(Zeit und Speicher) ist es die Strings
mit einem StringBuffer zu verketten und diesen nachher auszulesen:

StringBuffer a = new StringBuffer(“Ma”);
a.append(“i”);
a.append(“k”);
String d = a.toString();
//d = “Maik”

In diesem kleinem Beispiel ist der Unterschied kaum messbar, aber
wenn mehrere hundert Strings verkettet werden müssen ist der
zweite Weg um ein Vielfaches schneller.

Im ersten Fall werden laufend neue Objekte erzeugt, was im zweiten Fall
nicht nötig ist, da immer das gleiche Objekt verwendet wird.

Ziel der Anforderungsanalyse ist es nicht nur, zu konsistenten Modellen zu kommen, welche die Anforderungen an das neue Softwaresystem adäquat beschreiben, sondern diese Modelle auch mit den Partnern kommunizieren zu können. Ein Modell ist nur dann praktisch effektiv, wenn alle Partner des Analyseprozesses es verstehen und bearbeiten können.
Es hat sich deshalb als effektiv erwiesen, nicht übermäßigen Gebrauch von Begriffen und Symbolen der Objektorientierten Designverfahren zu machen, insbesondere dann, wenn die Partner aus den Fachabteilungen mit dieser Terminologie nicht hinreichend vertraut sind. Statt immer wieder auf die Existenz von Klassen und Instanzen oder Objekten zu verweisen, sollte konkret über Dokumente und Akteure sowie Über andere Elemente des Systems gesprochen werden.
Den ganzen Beitrag lesen »