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.