Freitag, 25. September 2015

Die geltende Geschäftspraxis steht einem guten Requirements Engineering entgegen.

These:Gute Software benötigt gute fachliche Anforderungen.

Im Requirements Engineering sollen Anforderungen an eine Software möglichst genau aufgenommen werden. Auf dieser Grundlage wird dann eine Anwendung erstellt, die zum größtmöglichen Nutzen eingesetzt wird. Soweit der Anspruch. In der Wirklichkeit schlägt dieses Unterfangen oft fehl. Die Welt ist zu oft in Auftraggeber und Auftragnehmer aufgeteilt, die nicht am selben Strang ziehen. Gegensätzliche Interessen verhindern das Ziel zu erreichen. Auf der einen Seite steht das Softwareunternehmen. Es versucht möglichst viel Geld zu verdienen mit möglichst wenig Arbeit. Der Austausch eines Logos für 10.000 € wird so zum Sieg. Der Kunde wurde ausgetrickst und wenn alles gut geht, dann merkt er es auch nicht. Leider kommen immer wieder Geschichten an die Oberfläche, in diesen Tagen auch in anderen Bereichen der Wirtschaft, in denen das Austricksen von Kunden Bestandteil der Geschäftspolitik ist.

Freitag, 11. September 2015

Das Erstellen reproduzierbarer Software Releases.

Managementaufgaben

Artikelübersicht
1. Teil Managementaufgaben zwischen Fremd- und Selbstverwaltung.
2. Teil Was soll ich zuerst tun? Die Qual der Wahl.
3. Teil Prioritäten verteilen ist eine Kunst.
4. Teil Nur ein Fool wählt gleich ein Tool und ein Plädoyer gegen Monsterprogramme.
5. Teil Wer weiß schon, was alles dazu gehört? Von der Lust oder Unlust zur Versionsverwaltung.
6. Teil Im Dschungel der Nachvollziehbarkeit.
7. Teil Gib Deiner Version einen nachvollziehbaren Namen.
8. Teil Das Erstellen reproduzierbarer Software Releases.


Im letzten Post haben wir uns darum gekümmert, unserer Software einen Namen zu geben. Für den Kunden wurde ein eingängiger Marketingname erfunden, für die Entwicklung reichte eine interpretierbare Versionsnummer. Diese Versionsnummer beinhaltet Information. Wiederfinden kann man den Versionsnamen im Tagnamen, der auf der Tagline (Baseline) in der Versionsverwaltung sitzt. Dieser Tagname kann weitere, vielfältige Informationen zur Version enthalten.

Freitag, 28. August 2015

Gib Deiner Version einen nachvollziehbaren Namen.

Managementaufgaben

Artikelübersicht
1. Teil Managementaufgaben zwischen Fremd- und Selbstverwaltung.
2. Teil Was soll ich zuerst tun? Die Qual der Wahl.
3. Teil Prioritäten verteilen ist eine Kunst.
4. Teil Nur ein Fool wählt gleich ein Tool und ein Plädoyer gegen Monsterprogramme.
5. Teil Wer weiß schon, was alles dazu gehört? Von der Lust oder Unlust zur Versionsverwaltung.
6. Teil Im Dschungel der Nachvollziehbarkeit.
7. Teil Gib Deiner Version einen nachvollziehbaren Namen.
8. Teil Das Erstellen reproduzierbarer Software Releases.


In den letzten Artikeln dieser Reihe haben wir uns mit der Versionierung von Objekten und mit derNachvollziehbarkeit (Traceability) beschäftigt. Heute soll eine Softwarefirma unserer Wahl eine neue Version ihrer brandneuen Software ausliefern. Wir laden sie von der Downloadseite und sehen, sie hat die Versionsnummer 3.9.11. Im Kleingedruckten steht sogar die Nummer 3.9.11.2945. Was hat das zu bedeuten und warum spielt das bei unseren Betrachtungen zur Versionsverwaltung von Artefakten eine Rolle?

Freitag, 14. August 2015

Ein Produkt ist ein Produkt und ein Projekt ist ein Projekt.

Prozessübersicht Softwareentwicklung: Produkte

Es gibt Unternehmen, in denen werden zwar Produkte erstellt, deren Umsetzung erfolgt jedoch ausschließlich auf Projektebene. Es existiert also ein Produkt für eine Vielzahl von Kunden, eine Planungsebene für das Produkt gibt es jedoch nicht. Aus Kostengründen werden nur Projektbeauftragungen einzelner Kunden umgesetzt. Diese werden einzelnen Entwicklern oder kleinen Entwicklergruppen übertragen. Eine organisierte Abstimmung in Bezug auf das Produkt entfällt. Flur- und Zimmergespräche ersetzen notwendige Planungsaufgaben. Das ganze Problem verschlimmert sich, wenn es im Unternehmen nicht nur ein Produkt, sondern mehrere Produkte gibt. Am Ende haben wir eine projektgetriebene, konfuse Einzelentwicklung hin zu seltsamen Produkten.

Freitag, 31. Juli 2015

Die Angst vor dem Kunden.

These: Menschen, die sich wohl fühlen, Menschen, die geachtet werden, schaffen beachtliche Software.

Stellen Sie sich vor, Sie sind Programmierer in einer Softwarefirma und bekommen die Aufgabe, eine Anforderungsspezifikation zu schreiben. Nach der Spezifikation droht dann die Umsetzung. Deshalb möchten Sie die Anforderungen möglichst genau analysieren und beschreiben, und auch, weil Sie wissen, dass das Spezifizieren von Anforderungen der erste Entwicklungsschritt ist und zudem ein sehr bedeutender. 70 Prozent aller Projekte, die scheitern, leiden an fehlenden oder fehlerhaften Anforderungsanalysen.

Freitag, 17. Juli 2015

Das Alte behindert das Neue oder wie bewerte ich eine Firma anhand ihrer Lernkultur.

These: Menschen, die sich wohl fühlen, Menschen, die geachtet werden, schaffen beachtliche Software.

Neues zu lernen ist eines der wichtigsten Dinge im Leben eines Programmierers. Alles ändert sich - Vorgehensmodelle, Techniken und Sprachen. In traditionellen Gesellschaften haben die Jungen von den Alten gelernt. In unserer schnelllebigen Zeit müssen die Alten am Ball bleiben oder sie werden vom Zug der Zeit überholt und im schlimmsten Falle aussortiert. Solche Szenarien erzeugen Angst, und wo Angst herrscht, werden irrationale Verhaltensmuster geboren. In Firmen, wo die Alten auf Entscheidungsposten sitzen, kann es dazu kommen, dass sie sich vor Neuem schützen. Es gibt durchaus Firmen, in denen Techniken angewandt werden, die auch schon vor 20 Jahren modern waren. Dem Geschrei von schneller, weiter, höher entgegen, verkauft sich auch diese Software. Der Kunde dieser Produkte hat allzu oft keine Vorstellung von der Leistung, die er für sein Geld bekommt. Softwarefirmen vermögen es in vielen Fällen selbst nicht, die Leistungszunahme durch neue Techniken zu bewerten. Wie sollen Endkunden es da schaffen, einzuschätzen, wie viel Software man für sein Geld bekommt?

Freitag, 3. Juli 2015

Vom Sprint zum Überblick. Durchblick kommt nicht von allein.

Ordnung ins Chaos

Artikelübersicht
1. Teil Gegenseitige Hilfe ersetzt Chaos.
2. Teil Ein Held, der sich helfen lässt.
3. Teil Teambullshit oder wirkliche Teams. Mit dem Team gegen das Chaos.
4. Teil Vom Sprint zum Überblick. Durchblick kommt nicht von allein.


Im letzten Post habe ich beschrieben, wie sich ein kleines Team selbst organisieren kann. Die Abarbeitung der Aufgaben in Sprints, die eine, zwei oder vier Wochen dauern, gewährleistet eine effektive Arbeitsweise, mit der man auf kurzfristige Änderungen reagieren kann. Außerdem wird die Arbeit so zu einer Kette von Erfolgserlebnissen, die alle zwei Wochen ein neues und erweitertes Produkt präsentieren. Der Arbeitsfortschritt wird transparent. Es ist ein bisschen vergleichbar mit dem Ernten eines 100 Hektar großen Kartoffelackers. Die schiere Größe der abzuerntenden Fläche raubt uns den letzten Nerv oder sie lässt uns verzweifeln. Unterteilen wir die Fläche in kleinere Parzellen, wird jede einzelne Ernteaufgabe in absehbarer Zeit zu bewältigen sein. Wir stecken 10 x 10 m Parzellen ab und ernten eine nach der anderen ab. Unsere Motivation aufgrund der Kette von Erfolgen steigt enorm. Ein ähnliches Prinzip verwenden erfolgreiche Computerspiele, um ihre Spieler süchtig zu machen.

Freitag, 19. Juni 2015

Teambullshit oder wirkliche Teams. Mit dem Team gegen das Chaos.

Ordnung ins Chaos

Artikelübersicht
1. Teil Gegenseitige Hilfe ersetzt Chaos.
2. Teil Ein Held, der sich helfen lässt.
3. Teil Teambullshit oder wirkliche Teams. Mit dem Team gegen das Chaos.
4. Teil Vom Sprint zum Überblick. Durchblick kommt nicht von allein.


Im letzten Post dieser Reihe habe ich mir die Aufgabe gestellt, vertiefend in die neu zu schaffenden Teamstrukturen einzudringen. Diese kleinen, selbstständig agierenden Teams sind ein Weg, Ordnung ins Chaos der Firmen zu bringen, welches ich im Artikel Gegenseitige Hilfe ersetzt Chaos beschrieben habe. Bisher haben wir in unserem Beispiel von den 20 Mitarbeitern der Entwicklung 10 in neue Teams verteilt. Dieser Vorgang geschah auf freiwilliger Basis, weil Mitarbeiter intelligente Wesen sind und diktierte Verordnungen das Gegenteil von dem bewirken, was sie erreichen wollen. Die Macht des einfachen Mitarbeiters ist es, demotiviert Aufgaben zu erfüllen.

Freitag, 5. Juni 2015

Im Dschungel der Nachvollziehbarkeit.

Managementaufgaben

Artikelübersicht
1. Teil Managementaufgaben zwischen Fremd- und Selbstverwaltung.
2. Teil Was soll ich zuerst tun? Die Qual der Wahl.
3. Teil Prioritäten verteilen ist eine Kunst.
4. Teil Nur ein Fool wählt gleich ein Tool und ein Plädoyer gegen Monsterprogramme.
5. Teil Wer weiß schon, was alles dazu gehört? Von der Lust oder Unlust zur Versionsverwaltung.
6. Teil Im Dschungel der Nachvollziehbarkeit.
7. Teil Gib Deiner Version einen nachvollziehbaren Namen.
8. Teil Das Erstellen reproduzierbarer Software Releases.


Im letzten Artikel dieser Reihe haben wir gesehen, dass Entwicklungsartefakte verschiedene Versionsstände durchlaufen, die im historischen Kontext erhalten bleiben müssen. Entwicklungsartefakte können erweitert, umgeschrieben, neu aufgeteilt und gelöscht werden. Alle diese Entwicklungsschritte müssen nachvollziehbar bleiben. Die Gesamtheit der Artefakte kann in ganz bestimmten Versionsständen eingefroren werden. Wir setzen eine Baseline. Mit Maven, einem Built-Management-Tool, kann dieser Vorgang zu einem großen Teil automatisiert werden. Diese Vorgehensweise erlaubt uns, jederzeit jeden Entwicklungsstand wieder zum Leben zu erwecken und auszuliefern.

Freitag, 22. Mai 2015

Mit den Sinnen den Sinn der Oberfläche erfassen.

Ein System für den Entwurf einer Benutzerschnittstelle.

Artikelübersicht
1. Teil Die Erweiterung des Requirements Engineering durch das Usability Engineering.
2. Teil Mit Zielen zum User Interface.
3. Teil Dem Ziel entspringt die Anforderung. Alles ist im Fluss.
4. Teil Von Erwartungen und Konzepten. Struktur für das User Interface.
5. Teil Struktur gibt es nicht, ohne die Zeit, die Dinge in Ordnung zu bringen.
6. Teil Schlagen Sie mit Konventionen vielfältige Konfigurationen in die Flucht.
7. Teil Elemente verteilen ohne Ausraster.
8. Teil Mit den Sinnen den Sinn der Oberfläche erfassen.


Die fünfte Ebene im Modell von [GARRATT12] ist die Oberflächenebene. [GARRATT12] nennt es auch das sensorische Design, in dem sich Inhalt, Funktion und Ästhetik zum fertigen Design vereinigen. Im letzten Artikel zur Rasterebene wurde geschildert, wie die Elemente angeordnet werden. Wo und wie stellen wir die einzelnen Elemente auf einer Seite dar? Es geht dort aber auch um Navigationswege und um die Informationsdarstellung. Wie navigieren wir von einer Seite zur anderen? Wie stellen wir Information so dar, dass das Wichtige ins Auge springt? Wie wird Information vermittelt? Eine Ebene weiter, in der Oberflächenebene, geht es ganz konkret darum, wie die Präsentation aussieht.

Freitag, 8. Mai 2015

Wie lange braucht es, neue Mitarbeiter in einen apathischen Zustand zu versetzen?

These: Menschen, die sich wohl fühlen, Menschen, die geachtet werden, schaffen beachtliche Software.

Ein langjähriger Mitarbeiter verlässt die Firma, ein neuer Mitarbeiter wird gebraucht. In einer anderen Abteilung soll das Geschäft ausgeweitet werden. Neue Mitarbeiter verstärken das Team. Leider bleiben in beiden Fällen die erhofften Wirkungen aus. Der neue Mitarbeiter kann den alten Mitarbeiter nicht ersetzen und die Teamverstärkung behindert die alte Mannschaft. Situationen, die nicht selten in Betrieben auftreten. Man denkt, man kann Menschen wie Figuren auf Felder abstellen und sie funktionieren. Doch so wird dieses Spiel nicht gespielt. Neue Mitarbeiter einzustellen ist die eine Sache, sie im Betrieb in die Lage zu versetzen, produktiv zu sein, eine ganz andere. So etwas muss geplant und begleitet werden.

Freitag, 24. April 2015

Wer weiß schon, was alles dazu gehört? Von der Lust oder Unlust zur Versionsverwaltung.

Managementaufgaben

Artikelübersicht
1. Teil Managementaufgaben zwischen Fremd- und Selbstverwaltung.
2. Teil Was soll ich zuerst tun? Die Qual der Wahl.
3. Teil Prioritäten verteilen ist eine Kunst.
4. Teil Nur ein Fool wählt gleich ein Tool und ein Plädoyer gegen Monsterprogramme.
5. Teil Wer weiß schon, was alles dazu gehört? Von der Lust oder Unlust zur Versionsverwaltung.
6. Teil Im Dschungel der Nachvollziehbarkeit.
7. Teil Gib Deiner Version einen nachvollziehbaren Namen.
8. Teil Das Erstellen reproduzierbarer Software Releases.


Im Rahmen der Entwicklung erzeugen wir eine Fülle von Artefakten. Unser Hauptaugenmerk sollte auf dem Sinn der Artefakte und deren Umsetzung liegen. Nur wenn sie für das endgültige Produkt und dessen Wartung einen Sinn ergeben, sollten sie in ausreichendem Umfang umgesetzt werden. Der Prozess, in dem diese Artefakte erstellt werden, ist diesem sinnhaften Erzeugen von Artefakten untergeordnet. Der Prozess, den wir benötigen, ist der Weg, auf dem wir am schnellsten zu guten Artefakten kommen. Prozesse um der Prozesse willen steuern ziellos durch den Raum und erzeugen einen Schein von Sinnlosigkeit. Sie fesseln uns an Arbeitsschritte, deren Inhalt uns nicht klar ist. Verliehene Zertifikate für solche kafkaesken Prozesse steigern nur den Unmut der daran Gebundenen und sind oft nur zum Schein für den zu betrügenden Kunden gedacht.

Freitag, 10. April 2015

Elemente verteilen ohne Ausraster.

Ein System für den Entwurf einer Benutzerschnittstelle.

Artikelübersicht
1. Teil Die Erweiterung des Requirements Engineering durch das Usability Engineering.
2. Teil Mit Zielen zum User Interface.
3. Teil Dem Ziel entspringt die Anforderung. Alles ist im Fluss.
4. Teil Von Erwartungen und Konzepten. Struktur für das User Interface.
5. Teil Struktur gibt es nicht, ohne die Zeit, die Dinge in Ordnung zu bringen.
6. Teil Schlagen Sie mit Konventionen vielfältige Konfigurationen in die Flucht.
7. Teil Elemente verteilen ohne Ausraster.
8. Teil Mit den Sinnen den Sinn der Oberfläche erfassen.


Im letzten Post dieser Reihe habe ich den Grundsatz "convention over configuration" diskutiert. Konventionen erleichtern uns die Arbeit, da wir in vielen Fällen mit Erwartetem konfrontiert werden. Konfigurationen hingegen erschweren uns das Leben, da sie die Komplexität erhöhen. Das gilt auch auf der Rasterebene und deren Teilgebieten, die dort zur Anwendung kommen: das Interfacedesign, das Navigationsdesign und das Informationsdesign. Genau diese drei Teilgebiete wollen wir im Folgenden beleuchten.

Freitag, 27. März 2015

Ein Held, der sich helfen lässt.

Ordnung ins Chaos

Artikelübersicht
1. Teil Gegenseitige Hilfe ersetzt Chaos.
2. Teil Ein Held, der sich helfen lässt.
3. Teil Teambullshit oder wirkliche Teams. Mit dem Team gegen das Chaos.
4. Teil Vom Sprint zum Überblick. Durchblick kommt nicht von allein.


Im letzten Post habe ich ein großes Durcheinander beschrieben, welches wir leider in so einigen Firmen antreffen, die Software produzieren. Widerstand gegen solche Strukturen wird oft im Keim erstickt oder, was viel öfter passiert, er verläuft sich in vorgetäuschtem Interesse, welches keine Taten nach sich zieht. Trifft man jedoch auf ein offenes Management, welches erkannt hat, dass man sich in einer Sackgasse befindet und sich der aktuelle wirtschaftliche Erfolg sehr schnell in sein Gegenteil verwandeln kann, hat man eine Chance auf Änderung. Dieser Weg ist viel schwerer als man annehmen könnte, geht es doch immer um die Offenlegung der Fehler der Vergangenheit. Die erste Aufgabe ist eine IST-Analyse der bestehenden Verhältnisse, in der es darum geht, reale Informationen zu sammeln und diese messbar zu machen. Die Informationen der Mitarbeiter sind wegen ihres Abhängigkeitsverhältnisses zum Arbeitsplatz nicht unbedingt objektiv. Ob Management oder einfacher Mitarbeiter, man gesteht sich nicht mit Freude ein, was man in den letzten Jahren alles falsch gemacht hat. Sowohl die Gegenwart als auch die Vergangenheit werden gerne verklärt. Dieser Selbstbetrug hat fatale Folgen.

Freitag, 13. März 2015

Gegenseitige Hilfe ersetzt Chaos.

Ordnung ins Chaos

Artikelübersicht
1. Teil Gegenseitige Hilfe ersetzt Chaos.
2. Teil Ein Held, der sich helfen lässt.
3. Teil Teambullshit oder wirkliche Teams. Mit dem Team gegen das Chaos.
4. Teil Vom Sprint zum Überblick. Durchblick kommt nicht von allein.


Viele Firmen setzen auf kurzfristigen wirtschaftlichen Erfolg. Sie besitzen einen mehr oder minder aktiven Vertrieb. Dieser steht im Kontakt mit den Kunden und sammelt mehr oder minder spezifizierte Aufträge für das Unternehmen. Meist sind diese eher ungenau und wage formuliert. Wir wollen X für Y Personentage zum Termin Z. Die Frage an die Entwicklung, könnt Ihr das leisten, ist oft die einzige Machbarkeitsanalyse, die erfolgt. Der Auftrag, an dem eigentlich nur die Zahlungsleistung und der Liefertermin wirklich klar sind, flattert nun auf den Tisch eines beliebigen Programmierers, für sensible Menschen immer ein kleiner Schock, für im Arbeitsprozess glücklicherweise abgestumpfte Mitarbeiter ein Zettel Papier. Der Auftrag nimmt nun seinen Weg.

Freitag, 27. Februar 2015

Schlagen Sie mit Konventionen vielfältige Konfigurationen in die Flucht.

Ein System für den Entwurf einer Benutzerschnittstelle.

Artikelübersicht
1. Teil Die Erweiterung des Requirements Engineering durch das Usability Engineering.
2. Teil Mit Zielen zum User Interface.
3. Teil Dem Ziel entspringt die Anforderung. Alles ist im Fluss.
4. Teil Von Erwartungen und Konzepten. Struktur für das User Interface.
5. Teil Struktur gibt es nicht, ohne die Zeit, die Dinge in Ordnung zu bringen.
6. Teil Schlagen Sie mit Konventionen vielfältige Konfigurationen in die Flucht.
7. Teil Elemente verteilen ohne Ausraster.
8. Teil Mit den Sinnen den Sinn der Oberfläche erfassen.


Im letzten Post haben wir uns mit der Informationsarchitektur beschäftigt. Informationsdesign und Informationsarchitektur sind Bestandteile der Strukturebene im Modell von [GARRATT12]. Diese entwirft die konzeptuelle Struktur des User Interfaces. Wir haben einen groben Überblick über die Form gewonnen, die wir umsetzen wollen. Bei [GARRETT12] folgt nun die Rasterebene. Hier verfeinern wir unsere Vorstellungen weiter. Dabei nutzen wir drei Teilgebiete des Usability Engineerings, das Interfacedesign, das Navigationsdesign und das Informationsdesign. Alle diese Themen sind uns auf der Strukturebene schon einmal begegnet. Jetzt gilt es diese Themen feiner zu gestalten. Zwischen diesen drei Themen existieren starke Abhängigkeiten. Das Navigationsdesign beeinflusst das Interfacedesign, das Informationsdesign das Navigationsdesign usw.

Freitag, 13. Februar 2015

Struktur gibt es nicht, ohne die Zeit, die Dinge in Ordnung zu bringen.

Ein System für den Entwurf einer Benutzerschnittstelle.

Artikelübersicht
1. Teil Die Erweiterung des Requirements Engineering durch das Usability Engineering.
2. Teil Mit Zielen zum User Interface.
3. Teil Dem Ziel entspringt die Anforderung. Alles ist im Fluss.
4. Teil Von Erwartungen und Konzepten. Struktur für das User Interface.
5. Teil Struktur gibt es nicht, ohne die Zeit, die Dinge in Ordnung zu bringen.
6. Teil Schlagen Sie mit Konventionen vielfältige Konfigurationen in die Flucht.
7. Teil Elemente verteilen ohne Ausraster.
8. Teil Mit den Sinnen den Sinn der Oberfläche erfassen.


Im letzten Post dieser Reihe sind wir in die Designphase eingetreten. Diese beginnt bei [GARRATT12] mit der Strukturebene, welche sich mit dem Interaktionsdesign und der Informationsarchitektur beschäftigt. Zu Beginn haben wir im letzten Teil ein konzeptionelles Modell in Form eines UND-ODER-Baumes erstellt. Es ist Bestandteil des Interaktionsdesigns und dient der Betrachtung von Erwartungshaltungen der Benutzer an die Interaktionskomponenten unserer Benutzeroberfläche bis hin zum Umgang mit Fehlern. Eine wichtige Rolle spielt wie immer der Benutzer, der später mit der Software arbeiten soll. Diese herausragende Rolle hat er auch bei der Entwicklung der Informationsarchitektur. In dieser Architektur erstellen wir ein Ordnungsprinzip für Informationen, so dass diese verständlich, einfach zu finden und gut zu nutzen sind.

Freitag, 30. Januar 2015

Geschäftsprozesse mit den eigenen Augen sehen.

These: Systemkontextanalyse öffnet die Augen für optimale Software

Praktischer Modellentwurf für Prozesse.

Artikelübersicht
1. Teil Geschäftsprozesse kann man in Worten beschreiben, man kann es aber auch sein lassen.
2. Teil Geschäftsprozesse mit den eigenen Augen sehen.


Wenn wir die BPMN zur Modellierung von Geschäftsprozessen im Requirements Engineering benutzen, dann kommen wir mit einer beschränkten Menge von Modellelementen aus. Welche wir verwenden, bleibt uns überlassen. Auch bei der Syntax können wir manchmal ein Auge zudrücken. Am Ende soll das Bild allgemeinverständlich sein, zumindest unter denen, die damit arbeiten wollen. Zwischen dem Fachbereich und dem Entwicklungsbereich sollte es unbedingt ein klärendes Gespräch über die zu verwendenden Symbole und deren Bedeutung geben. Unterschiedliche Auslegungen des Gesehenen führen nur zu Verwirrungen die wesentlich mehr Zeit kosten.

Freitag, 16. Januar 2015

Geschäftsprozesse kann man in Worten beschreiben, man kann es aber auch sein lassen.

These: Systemkontextanalyse öffnet die Augen für optimale Software

Praktischer Modellentwurf für Prozesse.

Artikelübersicht
1. Teil Geschäftsprozesse kann man in Worten beschreiben, man kann es aber auch sein lassen.
2. Teil Geschäftsprozesse mit den eigenen Augen sehen.


In meiner Reihe zur Systemkontextanalyse habe ich Modelle für die Stakeholderanalyse und für das Erfassen von Dokumenten erläutert. Damit können zwei wesentliche Kontextaspekte in geeigneter Weise beschrieben werden. Ein weiterer Kontextaspekt ist der Prozess. Im Artikel Welche Arten von Kontextobjekten gibt es? habe ich den Prozess wie folgt definiert: "Ein Prozess ist eine Aktivität zur Verarbeitung von Eingangsdaten. Die Beschreibung des Algorithmus dieser Verarbeitung bildet die Abbildung des Prozesses." Daraus können wir schlussfolgern, dass wir ein Modell benötigen, welches Algorithmen abbilden kann. Die Business Process Modeling Notation (BPMN) ist genau so eine Möglichkeit. BPMN ist ein Standard der OMG (Object Management Group). Im Jahre 2011 wurde die BPMN 2.0 als Standard verabschiedet.

Freitag, 2. Januar 2015

Die Falle des Parkinsonschen Gesetzes oder wie man sich selbst hereinlegt.

These: Menschen, die sich wohl fühlen, Menschen, die geachtet werden, schaffen beachtliche Software.

Zuerst einmal möchte ich Ihnen einen guten Start in das Jahr 2015 wünschen! Vielen Dank für die vielen Kommentare, Hinweise und Links. Mein Ziel, von Ihrem Wissen zu profitieren und es durch eigene Artikel wieder zurückzugeben, habe ich, so hoffe ich, erreicht. Auf diesem Weg möchte ich mit Ihnen ( bzw. mit Euch) zusammen weitergehen. Dieser Artikel handelt noch einmal von Erlebnissen und Erfahrungen zurückliegender Jahre. Vielleicht haben Andere ähnliche Erfahrungen gemacht. Eigentlich wünsche ich mir das nicht und ich bin mir auch sicher, dass viele ganz andere Erfahrungen machen, an denen ich sehr interessiert bin. Ich selbst möchte mit diesem Artikel ausdrücken, für wie wichtig ich ein gutes Management halte, auch für wie schwierig es umzusetzen ist. Für mich selbst beginnt in diesem Jahr ein neuer Abschnitt und ich bin mir ziemlich sicher, dass sich gegenüber früher einiges ändern wird.