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.