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.