Software Engineering Blog

Über das bpmn.info-Blog habe ich grade via einem Post von Gero Decker von der Veröffentlichung der BPMN-Spezifikation 1.2 erfahren. Decker schreibt, daß sich bis auf die Behebung von "ein paar Mini-Bugs" und einer neuen Formatierung nichts geändert hat.

Zwei Dinge mußte ich dabei denken:

• "Schön, wenn auch für Spezifikationen Bug-Fix-Releases erscheinen." und
• "Schön, wenn jetzt die Tool-Hersteller ohne viel Aufwand für die nächste Version ihres Programmes mit der Unterstützung von BPMN 1.2 werben können."

Sei es drum, auch Spezifikationen müssen gepflegt werden und das meine ich ganz ernst.

Im Sophisten-Blog hat Alexander Lindner einen Tipp veröffentlicht, wie Aktionen in Entscheidungstabellen leicht zu referenzieren sind. Die Idee ist ziemlich gut. Hier geht es zum Blog-Eintrag.

Kennen Sie das? Sie möchten eine Software ausprobieren (ich schrecke jetzt vor dem Wort evaluieren mal zurück), laden sich die aktuelle Version als zeitlich- und limitierte Version herunter und haben dann genau 30 Tage Zeit zum Testen. Dummerweise fallen genau in diese 30 Tage verschiedene Aufgaben, die absolut nicht warten können und schwupps, die Testperiode ist rum. Ärgerlich, denn wenn die Lizenzmechanismus einer besseren Sorte ist, reicht es weder die Uhr vor dem Start zurückzustellen noch sonst etwas leicht vertretbares dagegen zu unternehmen. Es ist ja nicht so, daß die Firmen bei Gefallen nicht auch für ihr Produkt bezahlt werden sollen, aber 30 Tage sind in der Arbeitswelt nicht viel.

Vor ein oder zwei Jahren hatte ich mich nach einem UML-Tool für ein Projekt umgesehen und mir dabei auch unter anderem MagicDraw angesehen. Jetzt im Dezember hatte ich dank der Feiertage etwas freie Zeit und habe diese auch dafür genutzt mir MagicDraw noch einmal anzusehen und habe mir natürlich die aktuelle Version downgeloadet und mir eine Lizenzdatei zuschicken lassen. Beim ersten Start war ich dann verblüfft: Evaluierungszeitraum 180 Tage!

Innerhalb eines halben Jahres sollte es möglich sein, sich eine Meinung bei ernsthaften Interesse zu bilden. Wie sicher muß sich eigentlich eine Firma bei der Einschätzung des Mehrwertes ihrer Software sein, um eine solange Testphase zu ermöglichen?

Weiter so!

Oft herrscht werden die Begriffe Vorgehensmodell und Prozessmodell synonym verwendet und dabei lustig durcheinander geworfen. Beide sind aber nicht gleich, wenn auch eng verwandt.

Hier meine (Kurz-)Definitionen:

Vorgehensmodell Beschreibung von durchzuführenden Tätigkeiten, deren Abhängigkeiten und zeitliche Aufeinanderfolge.

Ein Vorgehensmodell sagt uns also, was wir zu tun habe: Anforderungsanalyse, Design, Codierung, Test, Einführung. Es sagt uns aber nicht, wie wir es zu tun haben. Hier kommt das Prozessmodell in das Spiel:

Prozessmodell Konkrete Beschreibung wie die durch ein Vorgehensmodell auszuführenden Tätigkeiten durchzuführen sind.

Ein Prozesmodell ist also die praktische Umsetzung eines Vorgehensmodell und trifft die konkreten Aussagen, die wir für unser Handeln in Projekten benötigen.

Das Verhältnis von Vorgehens- und Prozessmodell ähnelt sehr starkt dem Metamodell der UML. Das Prozessmodell ist die konkrete Ausprägung eines Vorgehensmodells. Sozusagen eine Instanz dessen. Das Vorgehensmodell beschreibt das Prozessmodell.

Dieser Unterschied ist wohl auch der Grund warum viele Menschen nach dem Lesen von Büchern zum Thema Software Engineering oder einer seiner Teildisziplinen erst einmal nicht wissen, wie sie das (hoffentlich) gelernte in die Praxis bringen. Das Buch sagt uns zum Beispiel das wir einen Projektplan erstellen sollen oder das Design dokumentieren sollen und wann wir das zu tun haben. Trifft aber keine Aussagen über das zu verwendende Werkzeug oder wie wir dokumentieren sollen. Dafür ist das Prozessmodell zuständig und diese sind immer so individuell wie sie, ihre Firma und ihr Projekt.

Auf XING sucht Christian Frei Blogger, die in ihrem Blog gerne von der Jazoon'09 in Juni 2009 auf Zürich berichten möchten. Als Gegenleistung winkt freier Eintritt.

Wir Software-Entwickler fokussieren uns bei unserer Arbeit berufsbedingt vor allem auf die Entwicklung von Software. Damit ist aber nur ein recht kleiner Anteil im Leben eines (erfolgreichen) Software-Produktes abgedeckt, auch wenn das berufsbedingt unser Schwerpunkt ist.

Software will wie jedes andere Produkt auch an den Mann oder die Frau bedracht werden, daher muß es auch ein Konzept für Marketing und Vertrieb geben. Zu oft wird auch vergessen, daß Software-Produkte vorallem dann sich in seinem Lebenszyklus betriebswirtschaftliche rentiert, wenn es einen funktionierenden Support für Kunden gibt. Dies ist ein nur allzuoft vergessener Punkt, dann Kunden wollen Support nicht nur dann haben, um im Fehlerfall abgesichert zu sein, sondern um auch vom Fachwissen des Anbieters zu profitieren.

Zu diesem Buch hat jetzt der Verlag dpunkt im letzten Monat ein eigenes Buch veröffentlicht: Management von IT-Produkten von Prof. Herzwurm und Prof. Pietsch.

Der erste Blick in das Inhaltsverzeichnis sieht vielversprechend aus. Sobald ich Zeit habe es mir zu beschaffen und zu lesen, werde ich eine ausführlichere Kritik veröffentlichen.

Als Projektleiter ist es unsere Aufgabe den Fortschritt unserer Projekte ständig mit den gesetzten Ist-Zielen abzugleich und die Voraussetzungen zu schaffen, daß es zu keinen gefährlichen Abweichungen kommt. Die meisten von uns beherrschen die hierfür notwendigen technischen Fähigkeiten. Oft kommt dabei aber die Mitarbeiterführung zu kurz. Im schlimmsten Fall erhalten die Mitarbeiter erst im jährlichen Personalgespräch eine Rückmeldung und diese kann von der Selbsteinschätzung erheblich abweichen. Für den Projektfortschritt würde kein Leiter ein solches Vorgehen akzeptieren, bei unseren Mitarbeitern akzeptieren wir dies aber zu oft.

Wie kann das sein? Der Grund ist einfach. Niemand fühlt sich wohl beim Kritisieren von den Menschen mit denen wir täglich zusammenarbeiten und es wird versucht den dabei möglicherweise entstehenden Spannungen aus dem Weg zu gehen. Dummerweise können dadurch Fehlentwicklungen entstehen, die sonst leicht zu korrigieren wären. Letztendlich sammeln sich alle Punkte an und ergießen sich kummuliert über den Mitarbeiter, der in dieser Situation oft nicht weiß wie ihm geschieht.

Viele Punkte können leicht in einem informellen Rahmen geklärt werden, ehe sie sich zu richtigen Problemen entwickeln. Nichts eignet sich dazu so gut wie ein kurzes Gespräch an der Kaffeemaschine oder bei Mittagessen.

Hier meine Tipps für eine kontinuierliche Mitarbeiterführung:

• Schaffen Sie eine Atmosphäre, die es Ihnen erlaubt früh Ihre Mitarbeiter auf Fehler oder andere Sichtweisen anzusprechen, ohne daß diese in eine Verteidigunghaltung gehen.
  Schaffen Sie die Möglichkeit zum gegenseitigen Feedback, auch im informellen Rahmen.
• Laß Sie ihre Mitarbeiter reden und seine Sicht oder die Gründe seiner Handlungsweise erklären. Denken Sie dabei an das Sprichwort „Reden ist Silber, Schweigen ist Gold.“
• Ziehen Sie für sich auch immer in Erwägung sich zu irren.
• Lassen Sie Ihre Mitarbeiter wissen, wenn Sie unzufrieden sind.
• Lassen Sie Ihre Mitarbeiter wissen, wann Sie mit ihnen zufrieden sind.

Denken Sie daran: Vorsorge ist immer besser als Problemlösung und aufgeschoben ist nicht aufgehoben.