Mittwoch, 30. Oktober 2013

Ideen, Themenobjekte und die Roadmap 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.


In diesem Post möchte ich die theoretischen Ausführungen der Artikel zum Ideenraum und zu den Themenobjekten in einem praktischen Beispiel verdeutlichen. Dazu benötigen wir eine Vision eines umzusetzenden Projektes. Ich wähle ein Programm zur Erfassung von Stakeholdern und ihren Beziehungen. Dazu habe ich bereits eine kleine Artikelreihe geschrieben, was für die Vorstellung des zu entwickelnden Programms sicherlich hilfreich ist.

Freitag, 25. Oktober 2013

Gibt es einen eklatanten Wissensbruch in der Softwareentwicklung?

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.


Mein Beispiel mit dem Architekten im Post Missing Links im Modell sorgte anscheinend für einige Verwirrung. Es wurde angemerkt, dass ein Architekt das spätere Bauwerk nicht benutzen muss und daher Bauwerke entstehen, die nicht besonders nutzerfreundlich sind. Die Schlussfolgerung daraus war, in der Softwareentwicklung treten keine schlimmeren Wissensbrüche auf als in anderen Produktionsbereichen. Kurz gesagt zwischen dem Nutzer des Hauses und dem Architekten besteht derselbe Wissensbruch, wie zwischen dem Bankfachmann und dem Requirements Engineer.

Sonntag, 20. Oktober 2013

Themenobjekte ordnen Ideen in eine Roadmap

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 zweiten Teil der Requirements-Engineering-Reihe wurde eine Möglichkeit aufgezeigt, noch unstrukturierte Ideen abzugreifen und ggf. schon eine gewisse Struktur und Priorität zu ermitteln. Diese Ideen im Ideenraum warten nun auf eine sinnvolle Weiterverarbeitung. Im Ideenraum können sich mit der Zeit eine Unmenge von Ideen ansammeln. Wir benötigen eine Methode, um unseren Blick auf die wichtigen Ideen zu lenken. Dabei vertrauen wir auf die Mitarbeit der Erzeuger und Priorisierer der Ideen. Mit Hilfe des Priorisierungssystems ziehen wir einen Betrachtungshorizont in das System ein. Alle Ideen, die eine Mindestpriorität erreichen, werden in den nachfolgenden Prozessen betrachtet. Ideen, die diese Priorität nicht besitzen, werden (noch) nicht in die Weiterverarbeitung mit einbezogen.

Dienstag, 15. Oktober 2013

Reengineering – Am Ende gab es nur noch eine Schnittstelle.

Praktisches Beispiel 1.6

Artikelübersicht
1. Teil Reengineering - Die Analyse des Altcodes.
2. Teil Requirements Engineering – erst einmal die Anforderungen definieren.
3. Teil Systemanalyse – vielleicht doch erst mal eine Architektur.
4. Teil Reengineering - Neu, strukturiert und auf lange Sicht schneller.
5. Teil Schon Vorhandenes nutzen wäre schneller gewesen. Beispielcode
6. Teil Reengineering – Am Ende gab es nur noch eine Schnittstelle.


Zum Abschluss meiner Reengineering-Reihe möchte ich eine Frage versuchen zu beantworten, die mir in einem Xing-Forum gestellt wurde. Was, wenn nur noch die Schnittstelle übrig ist? Ich könnte es mir einfach machen und das folgende antworten: Ein Reengineering ist die Umgestaltung, die Restrukturierung und Neugestaltung eines Softwaresystems. Dazu gehört auch die genaue Analyse des Altsystems. In den fünf ersten Posts dieser Reihe ist das herausgearbeitet worden. Wenn von diesem Gesamtsystem jedoch nur noch Teile übrig sind, dann kann man auch nur noch aus diesen Teilen Informationen gewinnen und muss den Rest neu aufbauen.

Donnerstag, 10. Oktober 2013

Der Ideenraum

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.


Eine Software entsteht aus einer Vision oder aus einer Notwendigkeit heraus. Sie kann auch schon jahrelang betrieben worden sein und nach Veränderung schreien. Ob wir nun ein neues Produkt bauen, ein altes Produkt umgestalten oder erweitern, es sind immer Ideen notwendig, dies zu tun. Eine Idee ist zuerst einmal ein unstrukturierter Einfall in Bezug auf das zu schaffende System. In der Kette der Prozesse befinden wir uns zwischen Vision und Systemkontextanalyse. Es macht keinen Sinn, Ideen abzublocken, nur weil sie unstrukturiert, beziehungslos und oft ungenau formuliert sind. Das Sammeln von Ideen ist die Vorordnung der Analyse. Alle einfach dahin gesagten Ideen sind von jedermann willkommen, der Stakeholder des zukünftigen Systems ist.

Samstag, 5. Oktober 2013

Praktiziertes Requirements Engineering

Allgemeines

Die Sammlung von Ideensplittern zum Requirements Engineering ist inzwischen auf weit über 100 Einträge angewachsen. Für mich war und ist es der Versuch, Twitter für eine, meines Erachtens, sinnvolle Kommunikation einzusetzen. Es gab einige Rückmeldungen, für die ich mich ganz herzlich bedanken möchte. Mit Spannung verfolge ich dabei das Experiment des Bloggens von Anforderungen.