Insolvenzverwaltung Blog

Datenvisualisierung in einer neuen Dimension

akoppel — Fri, 18 May 2012 10:58:03 +0000

Ich hatte es ja schon in der Vergangenheit geschrieben, dass wir erweiterte Analysen mit Wolfram-Mathematica erstellen. INVEP ist und bleibt INVEP, aber man muss das Rad ja nicht mehrmals erfinden. Einige Auswertungen, insbesondere Visualisierungen lassen sich mit Mathematica einfach leichter realisieren. Nun ist es leider so, dass nur die allerwenigsten unserer Kunden eine Mathematica-Lizenz haben. Um hier denoch entsprechende Analysen zur Verfügung zu stellen, haben wir auf einem unserer Web-Server ein Web-Mathematica installiert, dass wir jetzt Stück für Stück mit neuen Analysen beschicken. Die Analysen können direkt aus INVEP heraus abgerufen werden. Das Kunden-INVEP sendet die Daten zum Webserver, läßt dort die Analyse laufen, holt die Ergebnisse ab und zeit sie an. Natürlich kann man den Webserver auch manuell ansurfen und Daten zur Analyse hochladen. Wenn keine oder keine sinnvollen Daten hochgeladen werden, so verwenden wir Beispieldaten aus unserem eigenen Datenpool. Solche Beispieldaten können wir schließlich jederzeit einfach erzeugen, da wir als Softwareersteller ja selbst intensiv mit unseren eigenen Produkte arbeiten.

Ich finde das ganze überaus spannend, denn es ergeben sich so vollkommen neue Möglichkeiten. Wer es selbst einmal ausprobieren möchte, kann folgenden Link anwählen. Aktuell haben wir als Beispielauswertung den Arbeitsaufwand in Kanzleien implementiert. Der entsprechende Link kann hier auch direkt angewählt werden. Zum Testen müssen dafür keine Daten hochgeladen werden. Wenn bei leerem Dateinamensfeld der submit-Button angewählt wird, dann werden automatisch Beispieldaten verwendet.

Das Ganze ist natürlich nur der Anfang, es wird noch spannend werden. Wenn man übrigens eine eigene Mathematica-Lizenz hat, dann können diese Auswertungen noch sehr viel Umfangreicher gestaltet und durchgeführt werden.

Details sind keine Details

akoppel — Thu, 12 Apr 2012 08:31:22 +0000

Es gab einen sehr bekannten Möbeldesigner. Charles Eames entwarf absolute Klassiker, die seit teilweise fast 50 Jahren quasi unverändert gebaut werden. Wer sich jemals mit Design beschäftigt hat, kommt wohl an Eames nicht vorbeit. Nicht nur dass er sehr zeitlose und extrem langlebige Möbel entworfen hat, er hat auch die Perfektionierung seiner Entwürfe auf die Spitze getrieben. Nicht umsonst findet man seine Aluminiumserie auch heute noch sehr häufig überall dort, wo auf hochwertige Produkte Wert gelegt wird. Ich finde es schon recht bemerkenswert, dass “Alltagsprodukte” quasi unverändert seit 50 Jahren gefertigt werden und niemals an Attraktivität eingebüßt haben. Insbesondere im Möbelbau gibt es Designklassiker, die einfach nur Klassiker sind, seit Ewigkeiten gebaut werden, sozusagen in die Kategorie des “Must have” gehören, jedoch niemals wirklich bequem waren. Die Eames-Möbel gehören nicht dazu. Sie wurden nicht entworfen, um als Solitäre heraumzustehen, sondern um benutzt zu werden. Die Intention ihres Entwurfes war also die möglichst perfekte Funktionserfüllung; möglichst gepaart mit einem Maximum an Ästhetik. Eames war im positiven Sinne ein Besessener. Von ihm stammt der Spruch “Die Details sind nicht einfach nur Details, die Details sind das Produkt“. Dem möchte ich mich mit diesem Blogeintrag anschließen. Eine derartige Sicht der Dinge kann man auch auf Software anwenden. Man kann ohne weiteres Software schreiben, die einfach nur ihren Zweck erfüllt. Solche Software ist tatsächlich beliebig austauschbar. Ein essentieller Unterschied bei der Gestaltung einer Software sind eben die Details. Bei wirklich guter Software wird immer wieder aufs neue geprüft, ob etwas verbessert werden kann. Das bedeutet nicht, dass neue Funktionen eingebaut werden, sondern, dass vorhandene Funktionen verbessert werden. Komplexität und fehlende Ergonomie kann nicht einfach wegdiskutiert werden; eine Software muss so angepasst werden, dass sie den Arbeitsalltag tatsächlich vereinfacht und nicht einfach nur “Dinge” vom Schreibtisch in den Computer verlagert. Die Vielzahl von Details und kleinen “Helferlein”, die nur per Software realisiert werden können und die die tägliche Arbeit vereinfachen oder beschleunigen – bestenfalls beides – machen das Produkt aus; sie sind das Produkt. Warum schreibe ich das hier? Wir bekommen immer wieder das Feedback, dass wir eine imense Vielzahl an Details in unsere Produkte einbauen, deren Sinn und Zweck zwar nicht immer sofort erkennbar ist (meistens schon), die jedoch die tagtägliche Nutzung erheblich vereinfachen. Die immer neue Herausforderung für uns besteht darin, nicht nur die Details bereit zu stellen, sondern es auch in einer Art und Weise zu tun, dass das gesamt System trotz allem aufgeräumt, übersichtlich und ergonomisch bleibt.

Der Unterschied zwischen Einzel- und Massenoperationen

akoppel — Mon, 05 Mar 2012 10:07:27 +0000

Da hat hat man eine Funktion gebaut, die sich als überaus nützlich erweist und die von den Anwendern dankbar aufgenommen wird, und dann kommt die Frage “Kann ich nicht mehrere Dateien auswählen und die Operation auf alle Dateien anwenden?”. Das klingt erst einmal nach einer einfach umzusetzenden Aufgabe, der Teufel steckt jedoch wie immer ganz erheblich im Detail.

Wenn ich eine einzelne Funktion zur Verfügung stelle, dann kann ich die gesamte Handhabung dieser Funktion gekapselt betrachten. Der zugehörige Programmcode wird entsprechend geschrieben:
1) Ist die Anwendung der Operation zulässig
2) Erfassung der Parameter für die Anwendung der Operation
3) Durchführen der Operation
4) Erfolg oder Misserfolgt melden

Wenn man das ganze jedoch als Massenoperation durchführen möchte, dann sieht’s ganz anders aus. Der Anwender erwartet natürlich, dass er sämtliche Eingaben nur einmal vornehmen muss und das Fehlermanagement muss genauso einfach sein, wie bei einer einfachen (einzelnen) Anwendung. So einfach ist es jedoch nicht. Wenn umfangreiche Operationen auf eine Vielzahl von Daten angewendet werden sollen, dann sind mehrere dinge zu berücksichtigen, die bei einem einzelnen Datensatz schlicht keine Relevanz haben:
1) Wie ist damit umzugehebn, wenn zwar die gleiche Operation auf die Daten angewendet werden soll, jedoch jeweils unterschiedliche Rahmenbedingungen unterschiedliche Dateneingaben erfordern? Sollen alle Daten am Anfang erfasst werden, oder jeweils nur dann abgefragt werden, wenn sich Details unterscheiden?
2) Was ist mit einem Abbruchkriterium? Wenn eine umfangreiche Operation abgebrochen wird, liegen die Daten ggf. in einem Zustand vor – der halbfertig – nur mit erheblichem manuellem Aufwand nachgepflegt werden kann.
3) Ist ein Abbruchkriterium für eine Massenoperation überhaupt zulässig, oder entstehen dann unauflösbare konflikte?
4) Was ist, wenn ein Abbruch unzulässig ist, der Anwender jedoch auf Grund des langen Abarbeitungsvorganges denoch abbrechen möchte?
5) Wann sollen Fehlermeldungen ausgegeben werden (mittendrin, oder zusammengefaßt am Ende)

In diesem kleinen Szenario zeigt sich bereits, dass der Zusatzaufwand bei Massenoperationen teilweise überaus erheblich sein kann. Eine einfache Operation, die auf einen einzelnen Datensatz angewendet, vollkommen einfach zu implementieren ist, kann sich als quasi unmöglich für eine Massenoperation zu implementieren zeigen. In jedem Falle muss man sich intensive Gedanken über die Datenverwaltung machen, wenn eine einfache Funktion mehrfach angewendet werden soll.

Transparenz als Grundlage der Glaubwürdigkeit

akoppel — Mon, 09 Jan 2012 10:01:22 +0000

Von Sergej P. Koroljow gibt es die bekannte Aussage “Kompliziert bauen kann jeder”. Genau genommen hatte er gesagt “Die Genialität einer Konstruktion liegt in ihrer Einfachheit. Kompliziert bauen kann jeder.” Koroljow war sozusagen der Vater der russischen Raumfahrt. Tatsächlich gilt diese Aussage noch heute, denn es ist zumeist kein Problem, einen komplizierten Sachverhalt auch kompliziert wiederzugeben. Die Schwierigkeit liegt darin, einen komplizierten Sachverhalt so aufzubereiten, dass er auch von normal Sterblichen verstanden werden kann. In der Programmierung bedeutet das, dass die erste Version eines Programmes zumeist ein Erscheinungsbild und eine Funktionalität hat, die wirklich nur von den Leuten verstanden wird, die’s programmiert haben. Die eigentliche Arbeit beginnt jedoch erst dann. Denn dieses komplexe Software-Gebilde muss in eine Form gebracht werden, dass ein Anwender auch eine Chance hat, es zu verstehen, ohne zuvor eine Schulung im Umfang einer Doktorarbeit zu durchlaufen.

Ich sehe dass hier als wirklich stete Herausforderung an, denn überaus häufig müssen wir unser System immer aufs neue anwenderfreundlich gestalten, damit es überhaupt bedienbar bleibt. Auf den ersten Blick sieht dass dann so aus, als ob der Leistungsumfang beschnitten wurde (oder von Anfang an gar nicht vorhanden war), tatsächlich ist jedoch sehr viel Arbeit hinein geflossen, die komplexen Vorgänge vor dem Anwender zu verbergen (oder sie erst in Form weiterer optionaler Möglicheiten freizugeben).

Der nächste Schritt wird die grafische Aufbereitung von Daten sein. Damit meine ich nicht irgendwelche einfachen Linien-, Torten- oder Balkendiagramme, sondern aussagekräftige Diagrammdarstellungen oder dreidimensionale Visualisierungen von Vorgängen. Ich denke, dass es für jeden Anwender hilfreich ist, wenn er sich den aktuellen Bearbeitungsstand grafisch anzeigen lassen kann, statt einfach auf Tabellen zu vertrauen.

Wir haben schon mehrere Ideen für entsprechende Auswertungen, freuen uns jedoch über jede Mail oder jeden Anruf frei nach dem Motto: “Was ich schon immer mal sehen oder wissen wollte”. Wie in unserer Firma üblich werden derartige Ideen natürlich zumeist kostenlos umgesetzt.

Tips und Tricks in INVEP

akoppel — Wed, 04 Jan 2012 13:23:22 +0000

Stetig erweitern wir unser Produkt um neue Funktionen, die dann zumeist nur den Anwendern bekannt sind, die sich genau diese Funktion gewünscht haben. Es ist jedoch schade, dass die Vielzahl an Hilfsfunktionen vor anderen Augen verborgen bleibt, schlicht weil niemand nachfragt (oder das aktuelle Handbuch liest). Wir haben daher auf der INVEP-Seite einen neuen Bereich mit Tips & Tricks eingerichtet, in dem wir jeweils aktuelle Dinge herausstellen. Ein Besuch lohnt sich also immer mal wieder.

Wenn Sie eine Idee haben, so nehmen wir diese Idee in Zukunfts gerne auf. Senden Sie uns einfach eine Mail an support@akso.de oder schreiben Sie inen Kommentar hier im Blog.

Computer haben eine endliche Genauigkeit

akoppel — Sun, 04 Dec 2011 17:13:46 +0000

In einer digitalen Welt, in der es heutzutage extrem einfach ist, selbst umfangreiches Zahlenmaterial zu verarbeiten passiert es schnell, dass man blind vertraut, wo man doch eigentlich Vorsicht walten lassen sollte.

Die Grundrechenarten erlernt man bereits in der Grundschule, und je nach Jahrgang sind dann verschiedene Hilfsmittel zur Berechnung hinzugekommen. Ich möchte jetzt nicht ausschweifend darauf eingehen, wie es war, mit Logarithmentafeln und Rechenschiebern zu rechnen. Es reicht aus, dass wir irgendwann angefangen haben, Taschenrechner zu verwenden. Ein Taschenrechner oder auch ein Tischrechner ist eine tolle Sache, man kann beliebige Kettenrechnungen durchführen und bekommt ein korrektes Ergebnis. Es gibt eine kleine aber magische Einschränkung: Man bekommt ein korrektes Ergebnis, sofern man die Rechengenauigkeit der Maschine nicht überfordert. Tatsächlich sind moderne wissenschaftliche Taschenrechner sogar extrem genau, da eine Vielzahl an Knowhow in die Eliminierung von Rundungsfehlern eingeflossen ist.

Als moderner, computeraffiner Mensch nutzt man keinen Taschenrechne mehr, sondern das ultimative Schweizer Messer mit dem Namen Excel. Excel ist ein gutes Werkzeug, jedoch gibt es ein seh großes ABER. Man muss in Excel extrem aufpassen, dass die durchgeführten Berechnungen nicht zu umfangreich werden, denn je nach Größe der Zahlen entstehen in Excel früher oder später extreme Rundungsfehler. Im Finanzmathematischen machen sich die Fehler sehr schnell nicht nur im Cent-Bereich bemerkbar.

Ich habe etwas mit Excel rumgespielt und eine leicht nachvollziehbare Tabelle erstellt, die im Ergebnis absuluten Unsinn liefert. Zum einfachen Nachvollziehen kann die Tabelle hier geladen werden. Ich habe die Tabelle auch noch als PDF-Datei ausgedruckt, das Dokument kann hier geladen werden. Was sagt uns die Tabelle anbetracht der Tatsache, dass Excel sich doch im täglichen Einsatz bewährt und vermeindlich richtig rechnet?

Tatsächlich ist es ganz einfach: Bedingt durch seine logische Struktur akkumuliert Excel Rundungsfehler. Diese Rundungsfehler machen sich bei Einzelberechnungen kaum bemerkbar, wirken sich jedoch bei aufwändgen Kalkulationen mit steter Weiterverwendung vorheriger Ergebnissse früher oder später stark aus.

Heißt das jetzt, dass man Excel nicht verwenden soll? Sicherlich nicht. Mann muss sich eben nur sehr bewust sein, welche Art von Berechnungen man mit Excel durchführt. Für aufwändige Kalkulationen mit vielen Folgeberechnungen ist es schlicht nicht geeignet.

Grundsätzlich ist das übrigens keine Schlamperei von Microsoft, sondern ein immanentes Problem der zugrundeliegenden Mikroprozessorarchitektur. Wenn man wirklich richtig rechnen will, dann gibt es dafür entsprechende Werkzeuge, aber eben nicht Excel.

Übrigens gehören Vergütungsberechnungen sowie Berechnungen von Quotenzahlungen genau in die Kategorie der Berechnungen, die aus obigen Gründen mit Excel nicht möglich sind. Wenn man sich die Mühe macht und die dergestalt erzeugten Ergebnisse mit den entsprechenden Werkzeugen (z.B. Mathematica) nachrechnet, dann merkt man schnell, dass die Ergebnisse falsch sind.

Wer noch eine andere Datei ansehen möchte, der kann hier eine weitere Excel-Datei zum spielen laden, mit der die Fehlerausbreitung aufgezeigt wird.

Winkelfunktionen in der Finanzmathematik

akoppel — Mon, 01 Aug 2011 08:56:24 +0000

Es ist schon erstaunlich, was man alles für die Auswertung von Buchhaltungsdaten braucht. Im Rahmen unserer Forensik-Tools müssen wir die Betrachtungen immer wieder auf eine neue mathematische Ebene heben. Wenn man sich Buchhaltungsdaten insolventer Firmen ansieht, dann sieht das auf den ersten Blick nicht groß anders aus als jede andere Buchhaltung auch, mit der Ausnahme natürlich, dass die Firma irgendwann insolvent geworden ist, die Buchhaltung also kollabiert. Eine magische Frage ist jedoch, ob man das auch schon sehr viel früher erkennen kann. Ist es möglich, aus der Art der Bewegungen auf den Konten zu einem frühen Zeitpunkt festzustellen, ob eine Firma in die Insolvenz gehen wird. Wenn diese Frage bejaht werden kann, dann ergeben sich damit höchst interessante Hebel, sowohl was die Insolvenzverschleppung angeht, als auch die Möglichkeit, Gelder aus vergangenen Geschäften zurückzufordern (siehe hierzu die diversen HGB- und BGB-Gesetze). Wie oben schon gesagt, kommt man mit einer “einfachen” Analyse der Finanzdaten nicht weiter – egal wie vollständig die Daten sind -, denn selbst umfangreiche Kontenausschläge oder eine stete Verminderung der Mittel ergeben keine ausreichende Information (solche einfache Betrachtungen wurden in der Vergangenheit hinreichend erfolglos durchgeführt).
Jede Firma hat ihren eigenen “Fluß” in Bezug auf die Finanzen. Daraus ergibt sich, dass weder einfache Statistik noch Merkmalssuchen zu einem Ergebnis führen. Der deutlich vielversprechendere Weg ist ist, diesen “Fluß” der Finanzen mathematisch darzustellen und dann den Punkt zu finden, an dem die Abweichungen auftreten. Hat man den oder die Punkte gefunden, ist der Mensch wieder gefragt, um festzustellen, was an den strategischen Stellen passiert. Um solche Betrachtungen anzustellen, müssen Steigungs- und Regressionsberechnungen durchgeführt werden. Tatsächlich landet man hierbei sehr schnell bei Berechnungen mit komplexen Zahlen oder – wenn man die komplexen Zahlen umgehen möchte – bei hyperbolischen Winkelfunktionen. Die sich daraus ergebenden Aussagen sind überaus vielversprechend. Es können so insolvenzrelevante Sachverhalte aufgezeigt werden, die bei einer “normalen Betrachtung der Buchhaltung” schlicht unsichtbar bleiben. Beweisbar ist all das, die nun noch anstehende Aufgabe ist jedoch, dass Ganze so aufzubereiten, dass die zugrunde liegende Mathematik so leicht nachvollziehbar ist, dass im Streitfalle die Beteligten die Zusammenhänge nicht in Zweifel ziehen. Für den Verwalter ist das ein enormer Vorteil, da auf diesem Wege in erheblichem Maße die Masse erhöht werden kann – vorausgesetzt, die so aufgezeigten Sachverhalte werden durchgesetzt.
So kommen die Winkelfunktionen in die Finanzmathematik.

Wie vollständig ist vollständig oder was implementiert man

akoppel — Mon, 25 Jul 2011 08:50:13 +0000

Ich hatte ja schon darüber geschrieben, dass wir einen recht guten BASIC-Interpreter in unserer Software eingebaut haben, mit dem man tatsächlich alles Steuern und umfangreiche Berechnungen durchführen kann. Nun zeigte sich, dass wir teilweise Matrix-Algebra benötigen, um verschiedene Auswertungen effizient zu ermöglichen. Selbstverständlich könnten wir auch verlangen, dass der Anwender alles von Hand programmiert, aber das ist wohl nicht der Sinn der Sache, viel besser ist es, wenn es spezielle Anweisungen und Funktionen als integralen Bestandteil der Sprache gibt, die so etwas übernehmen. Also haben wir angefangen, Matrix-Algebra-Funktionen in die Sprache einzubauen. Das ist natürlich ein immens weites Feld. Wer sich mal etwas näher damit beschäftigt hat wird wissen, dass die mathematische Verknüpfung von Variablen, Vektoren und Matrizen nicht nur starren Regeln folgt, sondern auch sehr viel Raum für Zulässigkeitsbetrachtungen und Implementierungsformen bildet.
Genau hier liegt dann das Problem. Tatsächlich brauchen wir nur sehr wenige Vektor- und Matrixoperationen für alle Auswertungen, die in unserem Fachbereich notwendig sind.
Hoch-komplexe Auswertungen würde man ohnehin mit anderen Werkzeugen als der von uns implementierten Programmiersprache erstellen. Die Schönheit der Vollständigkeit verlangt natürlich, alle Varianten einzubauen, selbst die, die nicht benötigt werden; die wirtschaftliche Betrachtung verbietet das jedoch.
Generell hat man immer wieder die Situation, dass die Frage aufgeworfen wird: “Wenn das schon vorhanden ist, warum dann nicht noch den kleinen Schritt gehen, um es vollständig zu machen?”. Was jedoch ist schon tatsächlich vollständig? Das liegt immer im Auge des Betrachters. Eine pragmatische Sicht ist zu sagen, dass vollständige Programme all das enthalten, was üblicherweise benötigt wird (das lässt natürlich Raum in Bezug auf die Betrachtung, was als “überlicherweise” zu bezeichnen ist). Damit wird die Vollständigkeit zu einem gleitenden Prozess. Es gibt also immer eine “aktuelle Vollständigkeit”, die sich durch neue Erkenntnisse oder Anforderungen in eine “Unvollständigkeit” wandeln kann, was dann wiederum mit sich bringt, dass Erweiterungen vorgenommen werden müssen, um wieder eine “aktuelle Vollständigkeit” zu erreichen.
Ich denke, dass dieser Ansatz vertretbar ist (und vor allem wirtschaftlich sinnvoll).

Mit Intelligenten Fehlermanagement kann man sich in den Fuß schießen

akoppel — Fri, 08 Jul 2011 10:21:53 +0000

Ich kann ja nun persönlich auf 30 Jahre Softwareentwicklung zurückblicken, und was ich definitiv sagen kann ist, dass das Fehlermanagement deutlich komplizierter geworden ist. Ohne auf Details einzugehen ist es tatsächlich so, dass Softwaresysteme früher sehr viel deterministischer waren. Es gab erheblich weniger Möglichkeiten (auch in der Erfassung und der Bildschirmmaskensteuerung) und somit auch weniger denkbare Fehlerkonstellationen. Wenn eine Software so gebaut ist, dass nur eine Sache nach der anderen gemacht wird (d.h. auch eine Eingabe nach der anderen in einer definierten Eingabereihenfolge verarbeitet wird), dann hat man tatsächlich eine realistische Chance sämtliche denkbaren Fehlersituationen Stück für Stück zu berücksichtigen. Heutzutage hat man dagegen Systeme, die eine nahezu beliebige Erfassungs- und Eingabereihenfolge gestatten. Wenn nun einzelne Eingaben Abhängigkeiten untereinander aufweisen, so wird es richtig kompliziert, denn einerseits soll die Freiheit der Eingabe gewahrt bleiben, andererseits sollen Fehleingaben ausgeschlossen werden. Um der Sache noch eine Komplexitätsstufe hinzuzufügen, sollen häufig bereits während der Eingabe Jobs ablaufen, die die weitere Erfassung vereinfachen. Selbstverständlich dürfen unsinnige Eingaben oder Daten nicht zu einem Absturz führen, sondern die Programme müssen “intelligent” darauf reagieren. Tatsächlich ist es absolut unmöglich, bei jedem Eingabefeld sämtliche Kombinationen mit anderen Feldern zu berücksichtigen (alleine bei vier Feldern gibt es schon 32 Möglichkeiten), also werden nur als problematisch erkannte Szenarien berücksichtigt. Das führt jedoch sehr schnell zu Problemen, denn jeder erfahrene Programmierer weiß, dass es egal ist, wie viele Szenarien berücksichtigt werden, beim Kunden wird sofort eines auftreten, dass nicht berücksichtigt wurde. Der vorausschauende Entwickler baut also zusätzliche Schutzmechanismen ein, die dann greifen, wenn eine problematische Eingabe nicht erkannt wurde. Dann gibt’s noch Schutzmechanismen für die Schutzmechanismen. Das ganze führt dann zwar zu einem sehr stabilem Code, hat jedoch auch den überaus negativen Effekt, dass Fehler als solche gegebenenfalls nicht erkannt werden, dann zu Folgefehlern führen, die vielleicht auch nicht erkannt werden, weil die Software auch darauf noch “intelligent” reagiert und dann irgendwann ein Fehler auftritt, der nicht mehr abgefangen wird, sozusagen als Folge der Folge der Folge. Und genau diesen letzten Fehler kann man dann nicht mehr analysieren, weil nicht mehr festzustellen ist, was eigentlich der ursprüngliche Auslöser war. Es ist dann schon fast Zufall, wenn der ursprüngliche Fehler dann doch irgendwann gefunden wird. In der Regel ist das dann eine Anwendereingabe, die irgendwie nicht sinnvoll war, mit der das Programm jedoch intelligent umgegangen ist (ohne wirklich intelligent zu sein).
Wenn man sich mal die verschiedenen Protokolle (egal von welchem Betriebssystem) ansieht, dann ist man bass erstaunt, wie häufig soetwas vorkommt.
Derartige Probleme lassen sich tatsächlich per se nicht lösen. Man kann nur versuchen ein Gesamtsystem so zu gestalten, dass die letzte Instanz so klein wie möglich ist und dafür sorgt, das selbst im schlimmsten Fall keine Daten zerstört werden. So eine Sicherheit ist wiederum nur mit modular aufgebauten Systemen erreichbar, sei es auf Betriebssystem-, Datenbank- oder Anwendungsebene.
Warum diese Blogeintrag? Wir hatten grade so einen Fehler. Ab und an (extrem selten) ist uns die umfangreiche und mit Eigenintelligenz ausgestattete Adresserfassung abgestürzt. Es gab zwar niemals eine Datenzerstörung, aber der Absturz an sich ist einfach ärgerlich für den Kunden, denn die Adresse muss neu erfasst werden. Da der Fehler so selten aufgetreten ist, und der tatsächliche Absturz in keinem Zusammenhang mehr mit dem ursprünglichen Fehler stand, hat es wirklich gedauert, bis der Fehler gefunden wurde, denn welcher Anwender ist schon in der Lage 100%ig zu beschreiben, was er genau eingegeben hat. Wie dem auch sei, wir haben’s gelöst und sind wieder etwas schlauer.

Anmerkung:
Es gibt diverse Verfahren wie Code Coverage und andere, die in dieser Konstellation jedoch nicht weiterhelfen…

INVEP-Programmierhandbuch ist fertig (erstmal)

akoppel — Tue, 05 Jul 2011 15:54:48 +0000

Nach einigen Tagen Arbeit ist die erste Version des INVEP-Programmierhandbuches nunmehr fertig. Die Sprachsyntax ist beschrieben und alles wurde nochmals gegengeprüft. Was jetzt natürlich noch fehlt ist das Korrekturlesen (aber das machen andere) sowie möglichst hilfreiche Beispiele einzufügen. Wie das jedoch mit den Beispielen immer so ist, man braucht halt Ideen. Wenn in der nächsten Zeit Anforderungen für Daten-Analysen oder Automatisierungen reinkommen, dann werden wir die ensprechenden Programme exemplarisch dem Handbuch zufügen. Der interessierte Leser kann sich den aktuellen Handbuchentwurf gerne von der INVEP-Internet-Seite laden Man findet das Handbuch im Bereich “Bibliothek -> Kurzhilfen und Dokumentation”. Über Feedback freuen wir uns.