Wussten Sie, dass a-l-l-e Waren, die in die europäische Gemeinschaft verbracht werden, in irgendeiner Form angemeldet werden müssen? Und wissen Sie, dass Sie das schon häufiger gemacht haben? 

Denken Sie an Ihr Gepäck, das Sie gerade dem Fließband am Flughafen entnommen haben. Durch das Durchschreiten des Kanals “anmeldefreie Waren” haben Sie durch konkludentes (schlüssiges) Handeln eine Zollanmeldung durchgeführt – sofern ein getrennter Kanal vorhanden ist für zollpflichtige Waren. Ansonsten gilt das Gleiche, wenn Sie nicht eine sogenannte “spontane mündliche Zollanmeldung” abgeben (beispielsweise aus dem PKW beim Grenzübertritt).

Im Gegensatz zu einer schriftlichen, elektronischen oder mündlichen Zollanmeldung, haben Sie damit eine “Zollanmeldung durch andere Formen der Willensbekundung” durchgeführt (Art. 233 Buchst. a DVO). Außerdem haben Sie ausgedrückt, dass es sich nur um Waren des privilegierten Warenkreises handelt (Art. 230-232 DVO). Rechtlich passiert beim Durchschreiten folgendes:

• Eine Zollanmeldung gilt als abgegeben.
• Die Waren gelten als gestellt (fiktiv).
• Die Zollanmeldung gilt als angenommen.
• Die Waren werden überlassen (Zollverfahren ist beendet, über die Waren darf gemäß gewähltem Zollverfahren verfügt werden).

(Quelle: P. Witte, H.-M. Wolffgang: Lehrbuch des Europäischen Zollrechts, nwb-Verlag 2009)

cc by flickr/Furryscaly

Experimenting with validation in WPF, error providers and so on this afternoon I coded a little sample with WPF and net4.0

The goal was to have user friendly messages for wrong inputs in textboxes, comboboxes and so on. With using the validation framework you can define an error control template e.g. for a textbox – perhaps a red border, a tooltip with the error message or something similar. Because I wanted to use the same error control template for every textbox I didn’t  want to define it for every textbox, every window or usercontrol separately. That’s why I defined it in the <Application.Resources> (app.xaml).

Unfortunately the control template was never used – I always got a red border only => the default behaviour of framework elements with an invalidated binding. That’s why I defined an ordinary style – all textboxes should have a big blue border and a bold weighted font. The designer displayed a nice textbox with a big blue border and bold weighted font – everthing’s fine, I am happy. But when running the app… the textbox is styled with default properties again. I’m not happy and begin to question me and my knowledge about resources in WPF. I googled and read all articles about resource lookups in WPF I found – with no results. Seems to work for everybody else!!

After a couple of hours I accidentially found this question on stackoverflow. It is not the same problem I had with my textbox – but there was a little comment which let me stand still and try adding another style in my app.xaml – a very useless line of code:

<Style TargetType="Button"/>

Surprise: My textbox has now a big blue border and a bold weighted font…

The solution: You have to define at least two styles in your <Application.Resources>. If you define only one style it is ignored. And this is a bug – not a feature for sure!

Bei jeder neuen Geschäftsidee stellen sich die gleichen Fragen:

• Welchen Nutzen bringt die zukünftige Unternehmung welchen Kunden oder Partnern?
• Wie kann damit Geld verdient werden?

Es gibt selten eine richtige Antwort. Ein Werkzeug, dass uns schon oft geholfen hat, uns über unsere Vorstellungen klar zu werden und mit anderen zu kommunizieren ist der BusinessModel-Canvas von Business Model Generation.

Das zugehörige Handbuch zeigt anhand von Beispielen auf wie der Canvas verwendet wird.

Die vorgegebene Struktur hilft schnell einen Überblick über das Geschäftsmodell zu bekommen und eignet sich insbesondere dazu Modelle miteinander zu vergleichen. Dazu geht man die Bereiche (Key Partner, Key Activities  etc.) auf einem leeren Canvas durch und trägt nur die Unterschiede zwischen den beiden zu vergleichenden Modellen ein.

Eine Einführung in das Konzept durch einen der Buch-Herausgeber gibt es als Video auf youtube. Der frei herunterladbare Buchausschnitt enthält auch den leeren Canvas.

Viel Erfolg!

Wie kommt ein Softwareprojekt zu Stande?

Mit dem KickOff des Projektes wird eine Bestandsaufnahme durchgeführt – der Auftraggeber muss dem Auftragnehmer konkret mitteilen, was er will. Der Auftragnehmer muss erkennen, ob und wie die Anforderungen im jeweiligen Produkt umgesetzt werden können.

Fehler, die zu diesem Zeitpunkt entstehen, sind die teuersten – weil sie meistens erst bei der Inbetriebnahme oder schlimmer: während des Betriebs erkannt werden. Dass diese Art Fehler auftreten, bezweifelt nach vielen Jahren Erfahrung in Softwareprojekten niemand mehr – selbst der beste Berater hat nicht das selbe Bild, wie der Auftraggeber. Ziel bleibt, die Fehlerquote so gering wie möglich zu halten.

Warum treten immer wieder Fehler auf? Ein Argumentationsversuch:

Software Validation & Verification

• Projekte beginnen mit einer Spezifikationsphase (was soll umgesetzt werden)
• einer Designphase (wie soll es umgesetzt werden),
• einer Realisierung (die echte Entwicklung)
• einem Test gegen die Funktionen
• einem Test gegen das Design
• und enden mit einem Test gegen die Benutzeranforderungen (Abnahmetest).

Die Projektphasen lassen sich feiner unterteilen; das Prinzip ist wichtig. Der Zusammenhang der Phasen wird im Software Validation & Verification Model dargestellt. Unter Verification versteht man in diesem Zusammenhang die Prüfung, ob der jeweilige Prozessschritt korrekt ausgeführt wurde. So verifiziert jeder nachfolgende Prozessschritt grundsätzlich den Vorhergehenden. Beispielsweise kann eine logisch fehlerhafte Anforderung bereits in der Designphase Schwierigkeiten bereiten. Gleichzeitig werden die verschiedenen konstruktiven Prozessschritte (Anforderung, Design, Realisierung) durch ihren destruktiven Gegenpart (Funktionstest, Integrationstest, Abnahmetest) geprüft.

Unter Validierung versteht man in diesem Zusammenhang die Prüfung, ob das, was man tut, auch das ist, was getan werden soll – also der Abgleich zwischen den tatsächlichen Kundenanforderungen und dem, was im Entwicklungsprozess hergestellt wird. Einfacher ausgedrückt handelt es sich bei Verfication und Validation um die Fragen “Are we doing the thing right?” und “Are we doing the right thing?”.

Für die Beantwortung der ersten Frage – also ob man alles richtig macht – gibt es heute viele Methoden und Werkzeuge. Es gibt viele Werkzeuge für Anforderungsmanagement (selten genutzt), für Softwareentwurf, für Netzwerk-Topologien, Deployment-Modelle, Projektmanagement-Werkzeuge.

Gleichzeitig gibt es Methoden, wie Scrum, das Standard-Phasen-Modell, der Rational Unified Process, Checklisten für Reviews, Meetings und vieles mehr. Mit diesen Themen kann sich eine Softwarefirma eigenständig und intern beschäftigen. Die Frage, ob man das Richtige umsetzt, kann aber nur durch den Kunden beantwortet werden.

Warum fällt genau dieses Aufgabe so schwer?

• Eigenschutz: Jeder Mensch wird unterbewusst geschützt vor der Zerstörung seiner Denkmuster. Hat er einmal etwas für richtig anerkannt und insbesondere etwas entschieden, muss durch starken äußeren Einfluss die Entscheidung hinterfragt werden. Jedes Gespräch mit dem Auftraggeber bringt die bisherige Arbeit in der Anforderungsanalyse potentiell in Gefahr – besonders stark, bei fortgeschrittenen Projekten. Diesem Risiko setzt man sich unterbewusst nicht freiwillig aus.
• Die Hand, die einen füttert: Bei Bank- und Versicherungsberatern hat sich herumgesprochen, dass es sich eher um Verkäufer als Berater handelt. Etwas ähnliches gilt auch für den Anwendungsberater. Es ist klar, dass man nicht die Hand beißt, die einen füttert – im Zweifel wird der Anwendungsberater daher die Firma vertreten, die das Produkt verkauft, nicht den Kunden.
  
• Tunnelblick: Üblicherweise betrachtet ein Anwendungsberater nur den Teilprozess, der durch die Produktpalette seiner Firma abgedeckt wird. Lösungen aus einer Gesamtsicht können so nicht entstehen.
• Die Welt ist ein Nagel: Der Anwendungsberater kann nur aus einem oder mehreren Produkten seiner Firma wählen, um Aufgaben zu lösen. Nicht selten werden dadurch auf der einen Seite eines Geschäftsprozesses weiterhin Papierbelege erstellt, die durch das Produkt des Anbieters wieder aufwändig auf der anderen Seite eingescannt und optisch erkannt werden – eine elektronische Schnittstelle ist nicht Teil des Werkzeugkastens der Anbieterfirma. Oder anders: Wer nur einen Hammer als Werkzeug hat, für den ist der ganze Welt ein Nagel.

Ist der Anwendungsberater also überflüssig? Nein, natürlich nicht. Seine Aufgabe bleibt, Anforderungen kreativ durch die Werkzeuge umzusetzen, die ihm zur Verfügung stehen. Er kennt die Werkzeuge des Anbieters am Besten – ihm konkret gestellte Anforderungen weiß er am besten mit der ihm verfügbaren Produktpalette abzudecken.

Wozu noch einen Berater?

Was in der Softwaretechnik schon als Tatsache dargestellt wird, muss tatsächlich zu einer solchen werden. Bei Wikipedia heißt es: “In allen Phasen der Projektentwicklung ist das IT-Consulting (oder auf deutsch “Konzeptionen und Beratung”) durch externe Beraterfirmen üblich.” (http://de.wikipedia.org/wiki/Softwaretechnik#Projektmanagement).

Ein Berater hilft einem Unternehmer zunächst einmal herauszufinden, was er eigentlich will. Hört sich provokativ an – ist aber normal. Wer meint, er braucht ein neues Mobiltelefon, wird sich am Markt umsehen, welche Mobiltelefone es denn gibt. Durch die Auswahl erschlagen wird sich die Suche lange hinziehen – nicht die Suche, sondern die nicht getroffene Entscheidung. Für was soll man sich entscheiden, wenn nicht klar ist, wonach man genau sucht. Eine kurze Aufzählung der wichtigsten Funktionen, die man nutzen möchte schränkt die Auswahl potentieller Anbieter schnell ein. Der Berater hat dabei genügend Erfahrung, dass er durch sehr konkrete Fragestellungen gemeinsam mit dem Unternehmer ein Wunschbild zeichnet – aus dem direkt ein Lastenheft erstellt werden kann. Er fungiert auch als Sparrings-Partner Dabei kann sich herausstellen, dass es viel einfachere Lösungen gibt, als die Einführung eines großen und kostenintensiven ERP-Systems.

Lastenheft als Kommunikationshilfe

Mit einem Lastenheft wird nicht nur die Auswahl der Anbieter schneller und einfacher – ist ein Anbieter ausgewählt, wird die Kommunikation mit deren Anwendungsberater deutlich einfacher – und damit weniger zeit- und kostenintensiv. Im Projektverlauf kann der Berater ebenfalls einschätzen, ob die Anbieterfirma tatsächlich die Projektziele wie gewünscht erreichen wird. Bei einer Abnahme weiß der Berater, welche Themen relevant sind und getestet werden müssen.

Gleichzeitig wird er auf Dinge achten, wie beispielsweise Dokumentation. So passiert es häufig dass Dokumentationen (so sie denn überhaupt erstellt werden) im Archiv der Anbieterfirma landen (oder der Festplatte des Anwendungsberaters). Da gehören sie nicht hin. Sie sind Teil der auszuliefernden Software. Gelagert beim Kunden sollte dieser auch die Hoheit über die Dokumentation haben – Änderungen müssen daher bei ihm beantragt werden. Insbesondere beim Wechsel des Anbieters (teilweise schon beim Wechsel des Anwendungsberaters) kommt es sonst zu erheblichen Problemen.

Fazit

Schon lange bedient sich die Informationstechnologie Begriffen aus dem Baubereich. So kennt man heute in der Softwarebranche Software-Architekten, Software-Architekturen, Design oder Abnahmen. Die Erfahrungen der Baubranche sollten auch im Bereich der Baubegleitung in den immateriellen Bereich der Softwareentwicklung übernommen werden. Insbesondere bei mittelständischen Unternehmen, die keine Expertenmannschaft für Softwareprojekte vorhalten kann, ist eine solche Vorgehensweise zu empfehlen. Selbst wenn ein entsprechender Experte im Unternehmen vorhanden ist, zeigt die Erfahrung, dass seine Verfügbarkeit stark begrenzt und er meist überlastet ist, so dass zusätzliche, externe Unterstützung für eine solche Aufgabe eine deutliche Entlastung darstellt.

Die Rolle wird zukünftig mehr und mehr etabliert werden. Spannend bleibt, wie die Rolle des Baubegleiters oder des Ingenieurbüros bei Softwareprojekten zukünftig heißen wird. Vielleicht ja Mogularist?