Freitag, 19. Dezember 2014

Von Erwartungen und Konzepten. Struktur für das User Interface.

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.


Nach der Strategie- und der Umfangsebene bzw. dem Anforderungsmanagement verlassen wir die abstrakte Ebene und wenden uns Konkreterem zu. Wir treten in die Designphase ein. Diese unterteilt sich nach [GARRETT12] in die Strukturebene, die Rasterebene und die Oberflächenebene. Auch hier verbleiben wir in der Bewegungsrichtung vom Abstrakten zum Konkretem.

Freitag, 5. Dezember 2014

Dem Ziel entspringt die Anforderung. Alles ist im Fluss.

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 wurde der Zielbaum durch spezifische Ziele in Bezug auf das User Interface ergänzt. Im Modell von [GARRETT12] haben wir damit die Strategieebene abgearbeitet. Aus diesen ermittelten Bedürfnissen leiten wir nun konkrete Anforderungen an unsere Benutzeroberfläche ab. Welche Inhalte, welche Funktionen und Workflows soll die Schnittstelle bieten? [GARRATT12] erläutert zwei wichtige Gründe, warum wir uns überhaupt mit der Definition von Anforderungen beschäftigen sollten. Der erste Grund ist, "damit Sie wissen, was Sie entwickeln" [S.59, GARRATT12] und der zweite Grund ist, "damit Sie wissen, was Sie nicht entwickeln". Leider gibt es sehr viele, denen das trivial erscheint und die deshalb auf eine Anforderungsdefinition verzichten. Allen denen, die mit mir glauben, dass gerade trivial erscheinende Dinge sehr schwierig sein können, empfehle ich vor der Umsetzung die Beantwortung der Frage: "Was werden wir entwickeln?" [S.61, GARRATT12]

Freitag, 21. November 2014

Mit Zielen zum User Interface.

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 einen User-Centered-Designprozess beschrieben, der durch das Ebenenmodell von Jesse James Garrett vertieft wurde. Dieser Prozess setzt auf dem Requirements Engineering auf. Aus der Sicht des Requirements Engineers beschreibt unser Anforderungsmodell das zu lösende Problem. Eine Lösung ist aus seiner Sicht ein Schnittstellenmodell für das User Interface. Aus der Sicht des Usability Engineers ist dieses Schnittstellenmodell jedoch wieder eine Problembeschreibung, die den Oberflächendesigner zu einer Lösung motiviert. Auf diese Art und Weise "alterniert der Entwicklungsprozess zwischen Problemdefinition und Lösungsbeschreibung". [S.20, POHL08] Es ist die Perspektive des jeweiligen Fachgebietes, die etwas zum Problem oder zu seiner Lösung macht.

Freitag, 7. November 2014

Nur ein Fool wählt gleich ein Tool und ein Plädoyer gegen Monsterprogramme.

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 unserem Leben lassen wir uns, bei grundlegenden Entscheidungsfragen, oft genug nicht ausreichend Zeit. Obwohl wir immer wieder erfahren, dass wir mit den Folgen dieser Entscheidungen lange Zeit leben müssen. Die schnelle Entscheidung ein Tool zu benutzen, führt dazu, die Restriktionen des Werkzeugs ertragen zu müssen. Noch schlimmer, aber kaum beachtet, ist die Akzeptanz der Mehrfunktionalität, die man niemals nutzt. Man braucht einen Kutter und kauft einen Trawler. Wie verhindert man diese Fehlanschaffungen? Bei einer Entscheidung wählen wir zwischen verschiedenen Alternativen. Wir benötigen Kenntnisse zu den Alternativen und wir brauchen Kennwerte, die sie vergleichbar machen. Oft genug ist es nur der technikverliebte Blick, der uns verführt, statt ein intensives Nachdenken über Sinn oder Unsinn.

Freitag, 24. Oktober 2014

Gehören Prozesse auf den Müll?

These:Gute Software benötigt gute fachliche Anforderungen.

Mein beschriebenes Anforderungsmanagement ist als Prozess definiert, demzufolge prozesslastig. Im Folgenden möchte beschreiben, warum ich dieses Verhalten bevorzuge, obwohl es einige Vorurteile gegen Prozesse in der Softwareindustrie gibt. Eine der größten Ängste ist es, mit der Arbeit im gegebenen Zeitrahmen nicht fertig und durch einen Prozess behindert zu werden. Nur wenn der Auftraggeber einen Prozess fordert, ist man punktuell bereit einen solchen einzuhalten. Beide Verhaltensweisen empfinde ich als problematisch. Weder sind Prozesse dazu da, ein Zertifikat sklavisch zu erfüllen, noch sollten sie Zeitprobleme produzieren. Ein guter Prozess ist für mich nur ein Prozess, der unser Denken auf die eigentliche Aufgabe konzentriert und Routinearbeiten automatisiert, ohne das sie vergessen werden.

Freitag, 10. Oktober 2014

Die Erweiterung des Requirements Engineering durch das Usability Engineering.

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.


In der Artikelreihe Ein System zur Anforderungsentwicklung habe ich Ihnen vorgestellt, wie ich strukturiert Anforderungen entwerfe. Wir haben gesehen, wie Ziele, User Stories, Use Cases und verschiedenen Arten von Anforderungen zusammenhängen. Damit wurde sich um die grundlegenden Wünsche des Kunden gekümmert. Nun müssen wir eine Software entwickeln, mit der die Anwender zufrieden sind. Sie muss gut zu pflegen, leicht zu erweitern und gut zu bedienen sein. Neben einer durchdachten Architektur benötigen wir ein strukturiertes Usability Engineering. Zu beiden Teilgebieten benötigen wir einen guten Übergang vom Requirements Engineering.

Freitag, 26. September 2014

Ein fortgesetztes tolles Geschäft.

Prozessübersicht Softwareentwicklung

Artikelübersicht
1. Teil Missing Links im Modell.
2. Teil Gibt es einen eklatanten Wissensbruch in der Softwareentwicklung?
3. Teil Entwurf und Bauen von Software – eine falsche Vorstellung.
4. Teil Softwareentwurf ist ein organisierter Kreislauf.
5. Teil In Softwareprojekten gibt es viel zu entdecken!
6. Teil Die Interaktion mit dem Kontext ist ein wesentlicher Grund für den Erfolg eines Softwareprojektes.
7. Teil Das unentdeckte Land oder wo noch nie ein Mensch gewesen.
8. Teil Mit schlanken Methoden zu gewollter Software.
9. Teil Die Flexibilität des Vorgehens schenkt laufende Verbesserungen.
10. Teil Vom Problem seiner Rolle gerecht zu werden.
11. Teil Wir gründen eine virtuelle Firma.
12. Teil Warum ist unsere virtuelle Firma nur ein Torso?
13. Teil Eine Arbeitsvorlage, ein strategisches Team und ein tolles Geschäft.
14. Teil Ein fortgesetztes tolles Geschäft.


Im letzten Post haben wir fünf Bausteine des Business Model Canvas (BMC) beschrieben, mit deren Hilfe unser strategisches Team einen Geschäftsplan erstellt. Wir wissen bereits, welche Dienstleistung wir an welchen Kunden verkaufen wollen und über welche Wege wir das tun. Auch ist uns bewusst, wie wir die Kundenbeziehungen pflegen und welche Preise wir verlangen. Damit sind bereits wesentliche Grundlagen geklärt, bleibt die innere Struktur unseres Unternehmens. Welche Fähigkeiten und Fertigkeiten benötigen unsere Mitarbeiter? Welche anderen Ressourcen benötigen wir? Welche Aktivitäten haben wir durchzuführen, um unsere Dienstleistung anbieten zu können? Welche Partner benötigen wir? Und nicht zuletzt, welche Kostenstruktur müssen wir abbilden?

Freitag, 12. September 2014

Eine Arbeitsvorlage, ein strategisches Team und ein tolles Geschäft.

Prozessübersicht Softwareentwicklung

Artikelübersicht
1. Teil Missing Links im Modell.
2. Teil Gibt es einen eklatanten Wissensbruch in der Softwareentwicklung?
3. Teil Entwurf und Bauen von Software – eine falsche Vorstellung.
4. Teil Softwareentwurf ist ein organisierter Kreislauf.
5. Teil In Softwareprojekten gibt es viel zu entdecken!
6. Teil Die Interaktion mit dem Kontext ist ein wesentlicher Grund für den Erfolg eines Softwareprojektes.
7. Teil Das unentdeckte Land oder wo noch nie ein Mensch gewesen.
8. Teil Mit schlanken Methoden zu gewollter Software.
9. Teil Die Flexibilität des Vorgehens schenkt laufende Verbesserungen.
10. Teil Vom Problem seiner Rolle gerecht zu werden.
11. Teil Wir gründen eine virtuelle Firma.
12. Teil Warum ist unsere virtuelle Firma nur ein Torso?
13. Teil Eine Arbeitsvorlage, ein strategisches Team und ein tolles Geschäft.
14. Teil Ein fortgesetztes tolles Geschäft.


Im letzten Post wurde ein strategisches Team gebildet. Seine Aufgabe ist es, eine grundsätzliche Vision des Unternehmens zu entwickeln. Dazu möchte ich in diesem Post zeigen, wie es mithilfe einer existierenden grafischen Methode zum Ziel kommt. Neben dem Business Motivation Model (BMM) der OMG steht somit eine weitere Methode zur Strategieplanung zur Verfügung. Es kann nie schaden, einen Gedankengang mithilfe verschiedener Methoden und Sichten zu durchdenken. Jede neue Methode fügt Aspekte hinzu, hilft Fehler zu korrigieren und so ein immer besseres Gesamtbild entstehen zu lassen. Bei der angekündigten Methode handelt es sich um die Business Model Canvas (BMC). Alexander Osterwald und Yves Pigneur beschreiben diese Methode ausführlich in ihrem Buch [OSTER10]. Mit der BMC gelingt es in übersichtlicher Form ein Geschäftsmodell im Team auf einer standardisierten Vorlage zu entwickeln. Dazu müssen wir natürlich eine ungefähre Ahnung haben, was ein Geschäftsmodell ist. "Ein Geschäftsmodell beschreibt das Grundprinzip, nach dem eine Organisation Werte schafft, vermittelt und erfasst." [S.18, OSTER10]

Freitag, 5. September 2014

Eine Änderung zum Guten?

Vor kurzem twitterte ich einen Spruch von Marcus Tullius Cicero: Einen sicheren Freund erkennt man in unsicherer Sache. Darauf antwortete ein Follower ebenso mit Cicero: Fang nie an aufzuhören. Hör nie auf anzufangen. Diesen Zitataustausch fand ich sehr passend für mein Vorhaben, einige Änderungen in Bezug auf meinen Blog durchzuführen. Ich werde nicht aufhören zu posten, aber ich werde mir mehr Zeit lassen. Die gewonnene Zeit möchte ich, wie schon angekündigt, in Studien, Reviews und Nachdenken stecken, damit ich die Qualität meiner Posts steigere. Natürlich werde ich immer noch mein Wissen, wie auch mein Unwissen darstellen, um dann von Ihren Erfahrungen zu lernen. Ich habe den Verdacht, dass niemand von uns alles weiß und wir uns auf nette Art und Weise gegenseitig unter die Arme greifen können.

Freitag, 29. August 2014

Mit Strategie zum Erfolg.

Entwurfsmuster für Algorithmen

Artikelübersicht
1. Teil Folgt der Algorithmus einem Muster?
2. Teil Mit Strategie zum Erfolg.


Manchmal gibt es viele verschiedene Algorithmen, die am Ende das Gleiche erledigen, nur eben auf unterschiedliche Art und Weise. Es kommt auf die Umstände an, welchen dieser Algorithmen Sie benutzen wollen oder müssen. Sie streben ein Ziel an, berücksichtigen die Mittel und Umstände, dann entscheiden Sie sich und wählen eine Strategie. Auch unter den Entwurfsmustern gibt es eines, welches Ordnung in eine Familie von Algorithmen bringt. Die Gang of Four definiert den Zweck des sogenannten Strategy Pattern wie folgt: "Definiere eine Familie von Algorithmen, kapsele jeden einzelnen und mache sie austauschbar. Das Strategiemuster ermöglicht es, den Algorithmus unabhängig von ihn nutzenden Klienten zu variieren." [S.373, GOF11]

Freitag, 22. August 2014

Folgt der Algorithmus einem Muster?

Entwurfsmuster für Algorithmen

Artikelübersicht
1. Teil Folgt der Algorithmus einem Muster?
2. Teil Mit Strategie zum Erfolg.


In der Reihe Managementaufgaben habe ich mich in zwei Posts mit dem Priorisieren von Artefakten beschäftigt. In dem Post Was soll ich zuerst tun? Die Qual der Wahl wurde beschrieben, wer was nach welchen Kriterien priorisieren sollte. Im Post Prioritäten verteilen ist eine Kunst wurden dann eine Reihe einfacher Priorisierungsmethoden erläutert. Innerhalb des Requirements-Engineering-Prozesses stellt das Priorisieren einen wichtigen Teilschritt des Gesamtprozesses dar. Es ist somit Teil eines Algorithmus. "Ein Algorithmus ist eine eindeutige Folge von Anweisungen, die in endlicher Zeit auf die Lösung eines bestimmten Problems führt." [S.23, HAGG04]

Freitag, 15. August 2014

Prioritäten verteilen ist eine Kunst.

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 bestimmt wer priorisiert, wir haben Artefakte ausgewählt, die zu priorisieren sind und außerdem haben wir festgelegt, welches die Priorisierungskriterien sind. Die geeigneten Techniken, um diese Priorisierungen durchzuführen, hatten wir uns für den heutigen Post aufgehoben. Behalten wir im Kopf, dass es wichtig ist, sich beim Priorisieren auf die notwendigen Artefakte zu beschränken und auch die Komplexität der Kriterien zu beschränken. Im Folgenden führe ich einige Methoden auf, die sehr einfach sind und somit schnell anzuwenden. Für alle Methoden setzen wir eine Anzahl n von Artefakten voraus, die es in eine Reihenfolge zu bringen gilt.

Freitag, 8. August 2014

Startschuss zur testgetriebenen Entwicklung.

These: Gute Software benötigt gute fachliche Anforderungen.

Artikelübersicht
1. Teil Ein Objekt-Aufgaben-Modell für das Requirements Engineering.
2. Teil Der Ideenraum.
3. Teil Themenobjekte ordnen Ideen in eine Roadmap.
4. Teil Themen müssen einer Systemkontextanalyse unterzogen werden.
5. Teil Ein hierarchisches System von Kontextobjekten.
6. Teil Die Geschichten der Benutzer - User Stories erstellen.
7. Teil Die Analyse des Problemraums führt zum Zielmodell.
8. Teil Wie User Stories Use Cases gebären.
9. Teil Szenarien setzen sich zu Use Cases zusammen.
10. Teil Drei Perspektiven öffnen uns den Weg zu den Anforderungen.
11. Teil Noch mehr Zusammenhänge durch die CRUD-Matrix.
12. Teil Die Vielfalt der Szenarien.
13. Teil Qualitätsanforderungen bilden einen Übergang zur Softwarearchitektur.
14. Teil Ohne Abnahmekriterien läuft nichts.
15. Teil Startschuss zur testgetriebenen Entwicklung.


Im letzten Post habe ich die Bedeutung von Abnahmekriterien besonders betont. Sie bilden eine wichtige Schnittstelle in der Zusammenarbeit zwischen Kunden und Entwicklung. Die Annahmen, der Kunde will das ganz sicher so haben oder eigentlich wissen wir es besser als der Kunde, führen mit großer Sicherheit in die Irre. Deshalb kann ich nur noch einmal wiederholen: überzeugen Sie Ihren Kunden Abnahmekriterien zu schreiben, in seinem eigenen Interesse. In diesem Post möchte ich auf die Art und Weise eingehen, wie wir Abnahmekriterien dokumentieren.

Freitag, 1. August 2014

Was soll ich zuerst tun? Die Qual der Wahl.

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 einführenden Post habe ich eine Vielzahl von Managementaufgaben aufgezählt, die es zu beherrschen gilt. Eine davon ist das Priorisieren. Im Verlaufe der Entwicklung werden eine große Anzahl von Artefakten erzeugt, Anforderungen, Architekturen, Code, Abnahmetests und vieles mehr. Was davon soll zuerst getan werden? Was ist wirklich wichtig? Wie entscheiden wir das? Im Post Themenobjekte ordnen Ideen in eine Roadmap wurden finalisierte Themenobjekte durch ein Gremium priorisiert. Jedes Mitglied dieses Gremiums besaß einen Vorrat an Punkten, den es bestimmten Ideen anteilig zuordnen konnte. Die Summe der so zugeordneten Punkte brachte die Themenobjekte in eine Reihenfolge. In diesem Post erwähnte ich auch, dass andere Priorisierungsmethoden vorstellbar sind. Heute wird es um andere Priorisierungsmethoden gehen, aber auch um theoretische und organisatorische Grundlagen.

Freitag, 25. Juli 2014

Hochsensible sind nichts Besonderes.

HSM und Softwareentwicklung

Artikelübersicht
1. Teil Sind alle Menschen gleich?
2. Teil Hochsensible sind nichts Besonderes.


Im letzten Post schrieb ich, dass Hochsensible (HSM) oft als Sensibelchen diskreditiert werden. In einem Kommentar wurde das persönliche Empfinden diesen Menschen gegenüber als überempfindlich und unter Dauermigräne leidend beschrieben. Es scheint eine besonders positive Eigenschaft zu sein, Härte gegen Andere und gegen sich selbst zu zeigen. Sensibilität wird kaum als positive Eigenschaft im Arbeitsleben wahrgenommen. In vielen Fällen wären Desaster jedoch zu vermeiden, wenn die Kontrollleuchten sensibler Menschen gesehen werden würden. An anderer Stelle wurde geäußert, dass HSM besser nicht als Programmierer einzusetzen wären. Falls sich diese Ansicht durchsetzt, würden 15 bis 20 % der Menschheit ausgeschlossen, nur weil sie so sind, wie sie sind. Viele Talente würden einfach verloren gehen, befinden sich doch in dieser Gruppe viele kreative Menschen, die in Bezug auf die Programmierung sehr begabt sind.

Freitag, 18. Juli 2014

Ohne Abnahmekriterien läuft nichts.

These: Gute Software benötigt gute fachliche Anforderungen.

Artikelübersicht
1. Teil Ein Objekt-Aufgaben-Modell für das Requirements Engineering.
2. Teil Der Ideenraum.
3. Teil Themenobjekte ordnen Ideen in eine Roadmap.
4. Teil Themen müssen einer Systemkontextanalyse unterzogen werden.
5. Teil Ein hierarchisches System von Kontextobjekten.
6. Teil Die Geschichten der Benutzer - User Stories erstellen.
7. Teil Die Analyse des Problemraums führt zum Zielmodell.
8. Teil Wie User Stories Use Cases gebären.
9. Teil Szenarien setzen sich zu Use Cases zusammen.
10. Teil Drei Perspektiven öffnen uns den Weg zu den Anforderungen.
11. Teil Noch mehr Zusammenhänge durch die CRUD-Matrix.
12. Teil Die Vielfalt der Szenarien.
13. Teil Qualitätsanforderungen bilden einen Übergang zur Softwarearchitektur.
14. Teil Ohne Abnahmekriterien läuft nichts.
15. Teil Startschuss zur testgetriebenen Entwicklung.


Im folgenden Post möchte ich ein sehr wichtiges Thema im Requirements Engineering behandeln, die Kriterien für die Akzeptanz bzw. die Abnahme von Software. Immer wieder habe ich erlebt, wie der Kunde sich auf den Standpunkt stellte, das wollte ich aber ganz anders. Zu diesem Zeitpunkt war das entsprechende Feature die gesamte Produktionskette durchlaufen. Es waren Tage, manchmal auch Wochen investiert. Nun musste der bestehende Zustand analysiert werden und die gewünschten Änderungen aufwendig in das schon Bestehende eingebaut werden. Manchmal hat man zu einem späteren Zeitpunkt immer noch nicht begriffen, wie wichtig eine sorgsame Analyse ist. Mehrere dieser Arbeitsgänge werden ausgeführt, bevor der Kunde sein Feature bekommt und richtig glücklich ist er dann zu diesem Zeitpunkt verständlicherweise auch nicht mehr.

Freitag, 11. Juli 2014

Managementaufgaben zwischen Fremd- und Selbstverwaltung.

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.


Bisher haben wir uns mit dem Dokumentieren von Anforderungen beschäftigt. Dabei sind auf der Grundlage des Objekt-Aufgaben-Modells eine Fülle verschiedener Artefakte erzeugt worden. Das geschah durch beauftragte Tätigkeiten. Diese Artefakte (Objekte) und Tätigkeiten (Aufgaben) müssen geplant und verwaltet werden. Neben der reinen Dokumentation muss es demzufolge ein Management geben, welches die notwendige Planung, Steuerung und Kontrolle im Auge behält. Das Management muss die Aktivitätsausführung kontrollieren und steuern. [POH08] spricht im Requirements Engineering allgemein von den Phasen Gewinnung, Dokumentation, Übereinstimmung und Validierung. In meiner Prozessreihe setzte ich mich mit der Abfolge notwendiger Arbeitsschritte innerhalb der Softwareentwicklung auseinander. Deshalb werde ich in dieser Managementreihe zugunsten dieser Reihe auf prozessuale Beschreibungen verzichten.

Freitag, 4. Juli 2014

Warum ist unsere virtuelle Firma nur ein Torso?

Prozessübersicht Softwareentwicklung

Artikelübersicht
1. Teil Missing Links im Modell.
2. Teil Gibt es einen eklatanten Wissensbruch in der Softwareentwicklung?
3. Teil Entwurf und Bauen von Software – eine falsche Vorstellung.
4. Teil Softwareentwurf ist ein organisierter Kreislauf.
5. Teil In Softwareprojekten gibt es viel zu entdecken!
6. Teil Die Interaktion mit dem Kontext ist ein wesentlicher Grund für den Erfolg eines Softwareprojektes.
7. Teil Das unentdeckte Land oder wo noch nie ein Mensch gewesen.
8. Teil Mit schlanken Methoden zu gewollter Software.
9. Teil Die Flexibilität des Vorgehens schenkt laufende Verbesserungen.
10. Teil Vom Problem seiner Rolle gerecht zu werden.
11. Teil Wir gründen eine virtuelle Firma.
12. Teil Warum ist unsere virtuelle Firma nur ein Torso?
13. Teil Eine Arbeitsvorlage, ein strategisches Team und ein tolles Geschäft.
14. Teil Ein fortgesetztes tolles Geschäft.


Das Gedankenexperiment einer virtuellen Firma hat im letzten Post dieser Reihe ein Entwicklerteam geschaffen. Damit besteht die Möglichkeit Dinge herzustellen. Das ist innerhalb einer Marktwirtschaft jedoch nicht ausreichend. Das Anstellen des Produktionsmotors, der Produkte ausspuckt und auf den Markt wirft, reicht bei weitem nicht aus. Am Anfang und am Ende dieses Vorgangs fehlen wesentliche Schritte zum Erfolg. Vor- und nachbereitende Schritte sowie organisatorische Leistungen werden in unserem Denken oft unterschätzt.

Freitag, 27. Juni 2014

Die praktische Umsetzung verschiedener Perspektiven bei der Suche nach Anforderungen.

Beispiel zum System der Anforderungsermittlung

Artikelübersicht
1. Teil Ideen, Themenobjekte und die Roadmap im praktischen Beispiel.
2. Teil Praktisches Beispiel zur Kontextuntersuchung.
3. Teil Praktisches Beispiel zu User Stories.
4. Teil Drei Basismodelle guter Software im praktischen Beispiel.
5. Teil Das Bauen von Use Cases mit Hilfe von User Stories im praktischen Beispiel.
6. Teil Die praktische Umsetzung verschiedener Perspektiven bei der Suche nach Anforderungen.


Im letzten praktischen Post haben wir aus einer User Story Haupt-, Alternativ- und Ausnahmeszenarien entwickelt und diese zu einem Use Case zusammengesetzt. Die gefundenen Szenarien wurden in tabellarischer Darstellung näher erläutert, wenn es notwendig war. Nicht jede Information kann in UML beschrieben werden, manchmal ist einfach die natürliche Sprache notwendig. Allgemeine Attribute, die sich auf den erzeugten Use Case bezogen, wurden in einer spezifischen Schablone für den Use Case beschrieben. Solche Attribute waren Akteur, Name, Beschreibung, Vorbedingung, Nachbedingung und Ergebnis. Die gefundenen Use Cases können in einem Use-Case-Diagramm zum Zwecke des Überblicks und der Ordnung dargestellt werden. Wie wir Use Cases gruppieren und ordnen wird in einem späteren Post gezeigt. Auch die Notwendigkeit Abnahmekriterien zu entwickeln ist Bestandteil eines Späteren Beitrages.

Freitag, 20. Juni 2014

Sind alle Menschen gleich?

HSM und Softwareentwicklung

Artikelübersicht
1. Teil Sind alle Menschen gleich?
2. Teil Hochsensible sind nichts Besonderes.


Die Menschen um uns herum zeigen eine Vielzahl unterschiedlichster Attribute. Die Unterschiedlichkeit springt nahezu ins Auge. Kein Mensch ist wie der Andere. Trotzdem herrscht ein unbändiger Drang nach Kommensurabilität. Man möchte die Subjekte miteinander vergleichbar machen, um sie in Nutzbarkeitslevel einordnen zu können. Dieser Zwang fängt früh im Menschenleben an. Offensichtlich wird er in der Schule, wo die unterschiedlichen Begabungen auf eine einzige Zensurenskala gepresst werden. Ist die eine Eins in Mathe jedoch mit der Anderen vergleichbar und was sagt eine Eins im Deutschaufsatz oder im Malen aus? Zumindest, dass das Werk dem Lehrer gefallen hat. Mehr leider jedoch oft nicht und eine Fünf in diesen Fächern bewirkt oft eine lebenslange Schreib- oder Malsperre. Bleibt der Fakt, das Messversuche Auswirkungen auf den zu bewertenden Menschen haben. Dieser Verantwortung müssen sich die Messenden bewusst sein.

Freitag, 13. Juni 2014

Qualitätsanforderungen bilden einen Übergang zur Softwarearchitektur.

These: Gute Software benötigt gute fachliche Anforderungen.

Artikelübersicht
1. Teil Ein Objekt-Aufgaben-Modell für das Requirements Engineering.
2. Teil Der Ideenraum.
3. Teil Themenobjekte ordnen Ideen in eine Roadmap.
4. Teil Themen müssen einer Systemkontextanalyse unterzogen werden.
5. Teil Ein hierarchisches System von Kontextobjekten.
6. Teil Die Geschichten der Benutzer - User Stories erstellen.
7. Teil Die Analyse des Problemraums führt zum Zielmodell.
8. Teil Wie User Stories Use Cases gebären.
9. Teil Szenarien setzen sich zu Use Cases zusammen.
10. Teil Drei Perspektiven öffnen uns den Weg zu den Anforderungen.
11. Teil Noch mehr Zusammenhänge durch die CRUD-Matrix.
12. Teil Die Vielfalt der Szenarien.
13. Teil Qualitätsanforderungen bilden einen Übergang zur Softwarearchitektur.
14. Teil Ohne Abnahmekriterien läuft nichts.
15. Teil Startschuss zur testgetriebenen Entwicklung.


Nachdem wir im letzten Post verschiedene Szenariotypen untersucht haben, können wir nun Qualitätsanforderungen ermitteln. In der Literatur finden wir folgende Definitionen für diese Art der Anforderungen. "Eine Qualitätsanforderung definiert eine qualitative Eigenschaft des gesamten Systems, einer Systemkomponente oder einer Funktion." [S.16, POHL08] "Eine Qualitätsanforderung ist eine Anforderung, die sich auf ein Qualitätsmerkmal bezieht, das nicht durch funktionale Anforderungen abgedeckt wird." [IREB11] Die ISO/IEC 9126 spezifiziert folgende Kategorien zur Softwarequalität: Portierbarkeit, Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz und Wartbarkeit. Diese Kategorien sind in weitere Subkategorien unterteilt. Die Benutzbarkeit z.B. in Verständlichkeit, Erlernbarkeit, Bedienbarkeit und Attraktivität.

Freitag, 6. Juni 2014

Wir gründen eine virtuelle Firma.

Prozessübersicht Softwareentwicklung

Artikelübersicht
1. Teil Missing Links im Modell.
2. Teil Gibt es einen eklatanten Wissensbruch in der Softwareentwicklung?
3. Teil Entwurf und Bauen von Software – eine falsche Vorstellung.
4. Teil Softwareentwurf ist ein organisierter Kreislauf.
5. Teil In Softwareprojekten gibt es viel zu entdecken!
6. Teil Die Interaktion mit dem Kontext ist ein wesentlicher Grund für den Erfolg eines Softwareprojektes.
7. Teil Das unentdeckte Land oder wo noch nie ein Mensch gewesen.
8. Teil Mit schlanken Methoden zu gewollter Software.
9. Teil Die Flexibilität des Vorgehens schenkt laufende Verbesserungen.
10. Teil Vom Problem seiner Rolle gerecht zu werden.
11. Teil Wir gründen eine virtuelle Firma.
12. Teil Warum ist unsere virtuelle Firma nur ein Torso?
13. Teil Eine Arbeitsvorlage, ein strategisches Team und ein tolles Geschäft.
14. Teil Ein fortgesetztes tolles Geschäft.


Im letzten Post habe ich beschrieben, warum ein starres Rollenkonzept effizienter Softwareentwicklung im Wege steht. Arbeitsteilung, die die Kommunikation im Team aufhebt und kleine Entscheidungsgötter schafft, ist zu vermeiden. Am Ende des Posts übernahm ich von [TOTH14] den Begriff des Owners. Ein Owner spezialisiert sich in bestimmte fachliche Richtungen, sammelt Erfahrungen, bildet sich weiter, berät das Team, ist Ansprechpartner für das Thema. Diese Zuordnung ist nicht als starrer Posten zu verstehen, den es zu halten gilt, komme was da wolle. Am Ende gilt die Arbeitsleistung des Teams, welches sich aus Individuen zusammensetzt, die sich über die Zeit weiterentwickeln und verändern.

Freitag, 30. Mai 2014

Die Vielfalt der Szenarien.

These: Gute Software benötigt gute fachliche Anforderungen.

Artikelübersicht
1. Teil Ein Objekt-Aufgaben-Modell für das Requirements Engineering.
2. Teil Der Ideenraum.
3. Teil Themenobjekte ordnen Ideen in eine Roadmap.
4. Teil Themen müssen einer Systemkontextanalyse unterzogen werden.
5. Teil Ein hierarchisches System von Kontextobjekten.
6. Teil Die Geschichten der Benutzer - User Stories erstellen.
7. Teil Die Analyse des Problemraums führt zum Zielmodell.
8. Teil Wie User Stories Use Cases gebären.
9. Teil Szenarien setzen sich zu Use Cases zusammen.
10. Teil Drei Perspektiven öffnen uns den Weg zu den Anforderungen.
11. Teil Noch mehr Zusammenhänge durch die CRUD-Matrix.
12. Teil Die Vielfalt der Szenarien.
13. Teil Qualitätsanforderungen bilden einen Übergang zur Softwarearchitektur.
14. Teil Ohne Abnahmekriterien läuft nichts.
15. Teil Startschuss zur testgetriebenen Entwicklung.


In den letzten Posts wurden funktionale Anforderungen mit Hilfe von Szenarien entwickelt. Diese Szenarien wurden als Haupt-, Alternativ- und Ausnahmeszenarien in Use Cases zusammengefasst. Auch beim Auffinden von Qualitätsanforderungen können uns Szenarien erheblich weiterhelfen. Deshalb möchte ich als erstes vertiefend auf weitere Szenariotypen eingehen. Die unterschiedlichen Typen erlauben uns einen Betrachtungsgegenstand aus unterschiedlichen Perspektiven zu betrachten.

Freitag, 23. Mai 2014

Vom Problem seiner Rolle gerecht zu werden.

Prozessübersicht Softwareentwicklung

Artikelübersicht
1. Teil Missing Links im Modell.
2. Teil Gibt es einen eklatanten Wissensbruch in der Softwareentwicklung?
3. Teil Entwurf und Bauen von Software – eine falsche Vorstellung.
4. Teil Softwareentwurf ist ein organisierter Kreislauf.
5. Teil In Softwareprojekten gibt es viel zu entdecken!
6. Teil Die Interaktion mit dem Kontext ist ein wesentlicher Grund für den Erfolg eines Softwareprojektes.
7. Teil Das unentdeckte Land oder wo noch nie ein Mensch gewesen.
8. Teil Mit schlanken Methoden zu gewollter Software.
9. Teil Die Flexibilität des Vorgehens schenkt laufende Verbesserungen.
10. Teil Vom Problem seiner Rolle gerecht zu werden.
11. Teil Wir gründen eine virtuelle Firma.
12. Teil Warum ist unsere virtuelle Firma nur ein Torso?
13. Teil Eine Arbeitsvorlage, ein strategisches Team und ein tolles Geschäft.
14. Teil Ein fortgesetztes tolles Geschäft.


In vielen Firmen ist es üblich Rollen zu verteilen. Über die Rolle wird eine Verantwortlichkeit für mehr oder weniger genau definierte Aufgaben bestimmt. Ein Mitarbeiter kann Inhaber einer oder mehrerer Rollen sein, genauso wie mehrere Mitarbeiter dieselbe Rolle besitzen können. "Rollen entwickeln sich. Eine Firma oder ein länger laufendes Projekt kann mit einer Definition der Rollen und wie diese zu besetzen sind, gewonnene Erkenntnisse standardisieren und so lange für höhere Produktivität sorgen, wie diese Erkenntnisse relevant sind." [S.200, DIR11]

Freitag, 16. Mai 2014

Die Fähigkeit zur Selbstheilung.

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

Die Organisation einer Firma ist oft durch die Leitungsfähigkeit einzelner Menschen geprägt. Viele kleine Betriebe leiden an Organisationsschwächen, wenn sie ein gewisse Größe erreicht haben, mit der die Gründer nicht mehr umgehen können. Wenn die Schwelle übertreten wird, tritt erhebliche Arbeitsreibung auf. Der neue Zustand wird jedoch oft nicht als neuer Zustand erkannt. Die Reibungsverluste ordnet man dem laufenden Arbeitsstress, der Unfähigkeit der Mitarbeiter, dem Unwillen der Kunden oder diversen Ausreden zu. Um einen Zustand jedoch zu erkennen, muss man bereit sein, die IST-Situation zu reflektieren und eine veränderte SOLL-Situation zu entwerfen. Im Post Fehlerkreisläufe - Dein Freund, der Fehler habe ich bereits beschrieben, wie wichtig ein Analyse- und Verbesserungskreislauf ist.

Freitag, 9. Mai 2014

Noch mehr Zusammenhänge durch die CRUD-Matrix.

These: Gute Software benötigt gute fachliche Anforderungen.

Artikelübersicht
1. Teil Ein Objekt-Aufgaben-Modell für das Requirements Engineering.
2. Teil Der Ideenraum.
3. Teil Themenobjekte ordnen Ideen in eine Roadmap.
4. Teil Themen müssen einer Systemkontextanalyse unterzogen werden.
5. Teil Ein hierarchisches System von Kontextobjekten.
6. Teil Die Geschichten der Benutzer - User Stories erstellen.
7. Teil Die Analyse des Problemraums führt zum Zielmodell.
8. Teil Wie User Stories Use Cases gebären.
9. Teil Szenarien setzen sich zu Use Cases zusammen.
10. Teil Drei Perspektiven öffnen uns den Weg zu den Anforderungen.
11. Teil Noch mehr Zusammenhänge durch die CRUD-Matrix.
12. Teil Die Vielfalt der Szenarien.
13. Teil Qualitätsanforderungen bilden einen Übergang zur Softwarearchitektur.
14. Teil Ohne Abnahmekriterien läuft nichts.
15. Teil Startschuss zur testgetriebenen Entwicklung.


Die angekündigten Qualitätsanforderungen des letzten Posts müssen noch ein bisschen warten. Nach dem Studium von [HRU14] erscheint mir eine weitere Modellierung sehr sinnvoll. Im letzten Post wurde die modellgetriebene Möglichkeit beschrieben, mit Hilfe dreier Perspektiven, Anforderungen zu modellieren. Das Klassendiagramm hat dabei die Sicht auf die Datenperspektive geöffnet und uns eine Reihe von Klassen beschert. In unserem Beispiel fanden wir drei Entity-Klassen: Lehrer, Schüler und Klasse. Wie wir alle wissen, ist eine Klasse eine Vorlage für ein zu erschaffendes Objekt. Die Klasse Lehrer ist die Vorlage für den konkreten Lehrer Michael. Er kann erschaffen werden, seine Werte können gelesen werden, sie können verändert werden und er kann gelöscht (entlassen) werden. Diese Aktionen erklären wir uns allgemein hin mit den Buchstaben C, R, U und D. C steht für Create, R für Read, U für Update und D für Delete.

Freitag, 2. Mai 2014

Das Bauen von Use Cases mit Hilfe von User Stories im praktischen Beispiel.

Beispiel zum System der Anforderungsermittlung

Artikelübersicht
1. Teil Ideen, Themenobjekte und die Roadmap im praktischen Beispiel.
2. Teil Praktisches Beispiel zur Kontextuntersuchung.
3. Teil Praktisches Beispiel zu User Stories.
4. Teil Drei Basismodelle guter Software im praktischen Beispiel.
5. Teil Das Bauen von Use Cases mit Hilfe von User Stories im praktischen Beispiel.
6. Teil Die praktische Umsetzung verschiedener Perspektiven bei der Suche nach Anforderungen.


Im letzten Post der praktischen Beispiele zum Requirements Engineering haben wir zum Schluss eine Zielanalyse durchgeführt. Ziele sind extrem wichtig für ein Projekt. Sie verraten uns die eigentlichen Absichten, die wir mit einem Projekt verfolgen. Wenn wir irgendwann einmal Anforderungen finden, die sich auf kein Ziel zurückführen lassen, dann können wir diese getrost streichen. Nichts ist unwichtiger als Arbeit, die kein Ziel verfolgt. In dieser Zeit sollten wir lieber etwas anfertigen, was ein Ziel hat oder uns in die Hängematte legen. Arbeit, die den ganzen Tag nichts anderes fertig bekommt, als einen Stein von der einen auf die andere Seite zu räumen und wieder zurück ist sinnlos, wenn nicht Schikane.

Freitag, 25. April 2014

Drei Perspektiven öffnen uns den Weg zu den Anforderungen.

These: Gute Software benötigt gute fachliche Anforderungen.

Artikelübersicht
1. Teil Ein Objekt-Aufgaben-Modell für das Requirements Engineering.
2. Teil Der Ideenraum.
3. Teil Themenobjekte ordnen Ideen in eine Roadmap.
4. Teil Themen müssen einer Systemkontextanalyse unterzogen werden.
5. Teil Ein hierarchisches System von Kontextobjekten.
6. Teil Die Geschichten der Benutzer - User Stories erstellen.
7. Teil Die Analyse des Problemraums führt zum Zielmodell.
8. Teil Wie User Stories Use Cases gebären.
9. Teil Szenarien setzen sich zu Use Cases zusammen.
10. Teil Drei Perspektiven öffnen uns den Weg zu den Anforderungen.
11. Teil Noch mehr Zusammenhänge durch die CRUD-Matrix.
12. Teil Die Vielfalt der Szenarien.
13. Teil Qualitätsanforderungen bilden einen Übergang zur Softwarearchitektur.
14. Teil Ohne Abnahmekriterien läuft nichts.
15. Teil Startschuss zur testgetriebenen Entwicklung.


Nachdem gezeigt wurde, wie man aus einer User Story und den dazu gehörenden Akzeptanztests Szenarien entwickelt und diese dann zu Use Cases zusammenfasst, können wir nun untersuchen wie man auf diesem Weg weiter zu sinnvollen Anforderungen gelangt. Seitdem wir mit der Bildung von User Stories die Planungsphase verlassen haben, befinden wir uns mitten in der Entwicklungsphase. Das tiefe Durchdenken der Anforderungen ist Voraussetzung für die Vermeidung einer Reihe von teuren Fehlentwicklungen, die sonst in der Implementierungs- und Bugfixingphase behoben werden müssten. Die Ermittlung guter Anforderungen ist wichtig für die Entwicklung des richtigen Systems.

Freitag, 18. April 2014

Die Flexibilität des Vorgehens schenkt laufende Verbesserungen.

Prozessübersicht Softwareentwicklung

Artikelübersicht
1. Teil Missing Links im Modell.
2. Teil Gibt es einen eklatanten Wissensbruch in der Softwareentwicklung?
3. Teil Entwurf und Bauen von Software – eine falsche Vorstellung.
4. Teil Softwareentwurf ist ein organisierter Kreislauf.
5. Teil In Softwareprojekten gibt es viel zu entdecken!
6. Teil Die Interaktion mit dem Kontext ist ein wesentlicher Grund für den Erfolg eines Softwareprojektes.
7. Teil Das unentdeckte Land oder wo noch nie ein Mensch gewesen.
8. Teil Mit schlanken Methoden zu gewollter Software.
9. Teil Die Flexibilität des Vorgehens schenkt laufende Verbesserungen.
10. Teil Vom Problem seiner Rolle gerecht zu werden.
11. Teil Wir gründen eine virtuelle Firma.
12. Teil Warum ist unsere virtuelle Firma nur ein Torso?
13. Teil Eine Arbeitsvorlage, ein strategisches Team und ein tolles Geschäft.
14. Teil Ein fortgesetztes tolles Geschäft.


Der Sinn dieser Reihe ist es Prozessschritte aufzufinden, die für die Softwareentwicklung unabdingbar sind. Auf der anderen Seite gibt es vielleicht Prozesse, die keinen Sinn machen und verschwendete Zeit sind. Einen wesentlichen Einfluss auf diese Prozesse haben Vorgehensmodelle. Über die Jahre hat sich eine Vielzahl von Modellen angesammelt. Bekannt sind das gute alte V-Modell, der Rational Unified Process und in letzter Zeit natürlich immer mehr die agilen Prozesse. In den letzten Jahren habe ich einige Erfahrung mit Scrum gesammelt. Wir entschieden uns für Scrum, weil wir iterativ und inkrementell vorgehen wollten, aber auch, weil wir gehört hatten, dass bei dieser Vorgehensweise Teamarbeit im Zentrum steht. Wir wollten die verschiedenen Begabungen in einem festen Team zusammenführen und gemeinsam verantwortlich vorgehen.

Freitag, 11. April 2014

Mit schlanken Methoden zu gewollter Software.

Prozessübersicht Softwareentwicklung

Artikelübersicht
1. Teil Missing Links im Modell.
2. Teil Gibt es einen eklatanten Wissensbruch in der Softwareentwicklung?
3. Teil Entwurf und Bauen von Software – eine falsche Vorstellung.
4. Teil Softwareentwurf ist ein organisierter Kreislauf.
5. Teil In Softwareprojekten gibt es viel zu entdecken!
6. Teil Die Interaktion mit dem Kontext ist ein wesentlicher Grund für den Erfolg eines Softwareprojektes.
7. Teil Das unentdeckte Land oder wo noch nie ein Mensch gewesen.
8. Teil Mit schlanken Methoden zu gewollter Software.
9. Teil Die Flexibilität des Vorgehens schenkt laufende Verbesserungen.
10. Teil Vom Problem seiner Rolle gerecht zu werden.
11. Teil Wir gründen eine virtuelle Firma.
12. Teil Warum ist unsere virtuelle Firma nur ein Torso?
13. Teil Eine Arbeitsvorlage, ein strategisches Team und ein tolles Geschäft.
14. Teil Ein fortgesetztes tolles Geschäft.


In diesem Post möchte ich die im letzten Post dargestellte Bauen-Testen-Feedbackschleife der Lean-Startup-Methode näher beleuchten. Diese Schleife wird für die ökonomische Entwicklung eines Produktes verwendet. Die Produktidee wiederum basiert grundsätzlich auf einer Vision. "Um diese Vision zu verwirklichen, setzen sie eine Strategie ein, die ein Geschäftsmodell, eine Produktlandkarte, eine Einstellung zum Thema Geschäftspartner und Konkurrenten und bestimmte Vorstellungen hinsichtlich der potentiellen Kunden umfasst. Das Produkt ist das Endergebnis dieser Strategie." [S.27, RIES12] Eine Vielzahl von Produktideen gründen sich auf den Einfällen einzelner, die leider nie in der Wirklichkeit geprüft werden. Die Visionsfähigkeit wird in diesen Fällen oft überschätzt und führt zu enormen wirtschaftlichen Schäden.

Freitag, 4. April 2014

Szenarien setzen sich zu Use Cases zusammen.

These: Gute Software benötigt gute fachliche Anforderungen.

Artikelübersicht
1. Teil Ein Objekt-Aufgaben-Modell für das Requirements Engineering.
2. Teil Der Ideenraum.
3. Teil Themenobjekte ordnen Ideen in eine Roadmap.
4. Teil Themen müssen einer Systemkontextanalyse unterzogen werden.
5. Teil Ein hierarchisches System von Kontextobjekten.
6. Teil Die Geschichten der Benutzer - User Stories erstellen.
7. Teil Die Analyse des Problemraums führt zum Zielmodell.
8. Teil Wie User Stories Use Cases gebären.
9. Teil Szenarien setzen sich zu Use Cases zusammen.
10. Teil Drei Perspektiven öffnen uns den Weg zu den Anforderungen.
11. Teil Noch mehr Zusammenhänge durch die CRUD-Matrix.
12. Teil Die Vielfalt der Szenarien.
13. Teil Qualitätsanforderungen bilden einen Übergang zur Softwarearchitektur.
14. Teil Ohne Abnahmekriterien läuft nichts.
15. Teil Startschuss zur testgetriebenen Entwicklung.


Im Deutschen kann man einen Use Case auch Anwendungsfall nennen. "Ein Anwendungsfall beschreibt anhand eines zusammenhängenden Arbeitsablaufs die Interaktionen mit einem (geschäftlichen oder technischen) System. Ein Anwendungsfall wird stets durch einen Akteur initiiert und führt gewöhnlich zu einem für die Akteure wahrnehmbaren Ergebnis." [S.220, OEST06] "Ein Anwendungsfall spezifiziert Aktionsfolgen (Szenarien) einschließlich Alternativ- und Ausnahmeszenarien, die ein System oder eine Systemkomponente bei der Interaktion mit externen Objekten ausführt, um einen Mehrwert zu erbringen." [S.139, POHL08] Bei der Definition von [OEST06] als auch der von [POHL08] zählen Szenarien, Akteure und Ergebnis bzw. Mehrwert zu den Inhalten eines Use Cases.

Freitag, 28. März 2014

Im Zoo der Dokumente.

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

Artikelübersicht
1. Teil Ordnung für Dokumente.
2. Teil Im Zoo der Dokumente.


In der Systemkontextanalyse sammeln wir eine Reihe von Kontextobjekten, um uns über das Umfeld der zu schaffenden Software und über die Features der Software klar zu werden. Das letzte behandelte Kontextobjekt war das Dokument, beschrieben in Ordnung für Dokumente. Im Verlaufe der Entwicklung eines Systems können sich eine große Menge von Dokumenten ansammeln. Im Folgenden möchte ich einige Beispiele aufzählen:

Freitag, 21. März 2014

Drei Basismodelle guter Software im praktischen Beispiel.

Beispiel zum System der Anforderungsermittlung

Artikelübersicht
1. Teil Ideen, Themenobjekte und die Roadmap im praktischen Beispiel.
2. Teil Praktisches Beispiel zur Kontextuntersuchung.
3. Teil Praktisches Beispiel zu User Stories.
4. Teil Drei Basismodelle guter Software im praktischen Beispiel.
5. Teil Das Bauen von Use Cases mit Hilfe von User Stories im praktischen Beispiel.
6. Teil Die praktische Umsetzung verschiedener Perspektiven bei der Suche nach Anforderungen.


Im letzten praktischen Beispiel haben wir eine User Story entwickelt. Sie drückte den Wunsch eines Stakeholders aus. Diese User Story wurde geschätzt und priorisiert. Innerhalb eines Themas gibt es natürlich mehrere User Stories. Stehen alle User Stories eines Themas auf PRIORITIZED, kann der Product Owner sie mit einer Aufgabe beauftragen. Damit stehen die Stories im Backlog des Teams. Die Erstellung von User Stories hat unser Projekt planbar gemacht. Drei einfache Modelle werden begleitend zur Systemkontextuntersuchung und zur Erstellung der User Stories angefertigt. In jeder Iteration werden sie erweitert und auf ihre Konsistenz geprüft. Sie zeigen sehr frühzeitig grobe Konflikte an und verhindern so aufwändige Fehlentwicklungen. Bei den Modellen handelt es sich um die Darstellung des Problemraumes, die Aufzählung der Randbedingungen und die Erstellung eines Zielmodells. Alle drei Modelle sorgen dafür, dass die Gesamtentwicklung sich nicht verläuft und wir im Nirgendwo enden.

Freitag, 14. März 2014

Wie User Stories Use Cases gebären.

These: Gute Software benötigt gute fachliche Anforderungen.

Artikelübersicht
1. Teil Ein Objekt-Aufgaben-Modell für das Requirements Engineering.
2. Teil Der Ideenraum.
3. Teil Themenobjekte ordnen Ideen in eine Roadmap.
4. Teil Themen müssen einer Systemkontextanalyse unterzogen werden.
5. Teil Ein hierarchisches System von Kontextobjekten.
6. Teil Die Geschichten der Benutzer - User Stories erstellen.
7. Teil Die Analyse des Problemraums führt zum Zielmodell.
8. Teil Wie User Stories Use Cases gebären.
9. Teil Szenarien setzen sich zu Use Cases zusammen.
10. Teil Drei Perspektiven öffnen uns den Weg zu den Anforderungen.
11. Teil Noch mehr Zusammenhänge durch die CRUD-Matrix.
12. Teil Die Vielfalt der Szenarien.
13. Teil Qualitätsanforderungen bilden einen Übergang zur Softwarearchitektur.
14. Teil Ohne Abnahmekriterien läuft nichts.
15. Teil Startschuss zur testgetriebenen Entwicklung.


Zuletzt haben wir User Stories geschrieben, die zu lösenden Probleme analysiert, Randbedingungen ermittelt und ein Zielmodell aufgestellt. Diese Prozesse wurden in den Artikeln Die Geschichten der Benutzer - User Stories erstellen und Die Analyse des Problemraums führt zum Zielmodell beschrieben. Im Folgenden möchte ich mich mit der Möglichkeit beschäftigen, Use Cases zu entwickeln. Dazu müssen wir als erstes herausarbeiten, worin der Unterschied zwischen User Story und Use Case besteht.

Freitag, 7. März 2014

Das unentdeckte Land oder wo noch nie ein Mensch gewesen.

Prozessübersicht Softwareentwicklung

Artikelübersicht
1. Teil Missing Links im Modell.
2. Teil Gibt es einen eklatanten Wissensbruch in der Softwareentwicklung?
3. Teil Entwurf und Bauen von Software – eine falsche Vorstellung.
4. Teil Softwareentwurf ist ein organisierter Kreislauf.
5. Teil In Softwareprojekten gibt es viel zu entdecken!
6. Teil Die Interaktion mit dem Kontext ist ein wesentlicher Grund für den Erfolg eines Softwareprojektes.
7. Teil Das unentdeckte Land oder wo noch nie ein Mensch gewesen.
8. Teil Mit schlanken Methoden zu gewollter Software.
9. Teil Die Flexibilität des Vorgehens schenkt laufende Verbesserungen.
10. Teil Vom Problem seiner Rolle gerecht zu werden.
11. Teil Wir gründen eine virtuelle Firma.
12. Teil Warum ist unsere virtuelle Firma nur ein Torso?
13. Teil Eine Arbeitsvorlage, ein strategisches Team und ein tolles Geschäft.
14. Teil Ein fortgesetztes tolles Geschäft.


Projekte sind unterschiedlichen Charakters. Es gibt Projekte, die nur Vorhandenes umsetzen, die Altes erweitern, die Prozesse automatisieren und verbessern, aber es gibt auch Projekte die absolut Neues schaffen. In letztgenannten Projekten steht man den weitaus größten Schwierigkeiten gegenüber, aber sie sind auch die interessantesten. Man kennt kaum die Basis, von der man ausgeht und weiß schon gar nicht, wo man genau hin will. Solche Projekte sind Erfinderprojekte, in denen man die Methoden des Design Thinking benutzen kann. Aber auch in den anderen Projekten kann man die Grundsätze des Design Thinking natürlich gewinnbringend anwenden. Bei unserer Prozessbetrachtung spielen diese Erfinderprozesse ebenfalls eine große Rolle, und ich denke, wir dürfen sie nicht vernachlässigen. Software erschaffen ist eben kein reiner Produktionsprozess, sondern es ist eher Wissensarbeit.

Freitag, 28. Februar 2014

Arbeitsumgebung kann Kreativität töten.

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

Im Post Teambildung als bewusster Prozess habe ich dafür plädiert, die Bedeutung von sich selbst erschaffenden und langfristig existierenden Teams anzuerkennen. Die Leistungsfähigkeit eingespielter Teams scheint mir um ein Vielfaches höher als von Menschen, die wie Dinge aus einem Pool geholt und je nach Laune in neue Teams gesteckt werden. Für diese Zusammenschlüsse von Arbeitsgemeinschaften würde ich das Wort Team nicht benutzen. Jedesmal beginnt der Teambildungsprozess von vorn. Die Phasen Forming, Storming und Norming reduzieren die Leistung, bei Scrum muss die velocity immer wieder neu bestimmt werden und Leute, bei denen die Chemie nicht stimmt, haben keine Chance, langfristig ein zu Hause in anderen Teams zu suchen. Die Liste ließe sich um einiges verlängern. Doch wo das Management diese Prozesse beherrscht, baut sich ein gewaltiger Konkurrenzvorteil auf.

Freitag, 21. Februar 2014

Die Attributierung der Objekte in der Umsetzung.

Ein System zur Anforderungsentwicklung in der Umsetzung.

Artikelübersicht
1. Teil Mit dem Zustandsmuster beginnt die Umsetzung eines Requirements Engineering.
2. Teil Die Attributierung der Objekte in der Umsetzung.


Im zweiten Umsetzungspost zum Requirements Engineering möchte ich auf spezifische Ableitungen des RequirementsObject zu sprechen kommen. Bisher sind uns einige spezifische Objekte des Objekt-Aufgaben-Modells in den theoretischen Posts über den Weg gelaufen. Zuerst ist uns das Ideenobjekt (Idea) begegnet. Die unterschiedlichen Stakeholder haben die Möglichkeit Ideen zu sammeln. Später werden diese in Themen (Issue) zusammengefasst. Für Themen werden Systemkontextuntersuchungen veranlasst, in denen Kontextobjekte (Context) geschaffen werden. Um planbare Systeme zu schaffen, habe ich an dieser Stelle User Stories (UserStory) eingeführt. Natürlich wird es im weiteren Verlauf des Requirements Engineering weitere Objekte geben.