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.