Cash, Stakeholder, Value – die drei Dimensionen des Business Values

Erstellt am 12 September 2017
von 1 Komment
Business Value hat 3 Dimentionen: Cash, Stakeholder und Value

Business Value – 3 Dimensionen

Zur Einschätzung des Business Values einzelner Produktfeatures oder User Stories hilft die Erkenntnis, dass Business Value immer durch Zusammenwirken der Dimensionen Cash, Stakeholder und Value entsteht.

Anforderungsdokumentation ist nicht generell sinnvoll!

Erstellt am 28 Februar 2017
von Schreibe einen Kommentar

Vor etwa zwei Jahren habe ich mit einem Kunden die Fragestellung erörtert, inwieweit sich User Stories in einer Entwicklung im regulierten Umfeld einsetzen lassen. Es herrschte die Meinung, User Stories seien gänzlich ungeeignet um im regulierten Umfeld eingesetzt zu werden, da sie nicht detailliert genug seien, um als geforderte Anforderungsdokumentation zu dienen.

Agile Softwareentwicklung benötigt mehr Werkzeuge

Erstellt am 23 August 2016
von Schreibe einen Kommentar

In den 90er Jahren und noch zu Beginn des Jahrtausends haben wir sogenannte CASE-Tools (Computer Aided Software Engineering) verwendet, um zuerst ein Design in Form eines großen, komplett durchdachten UML-Modells zu erstellen, bevor wir anfingen, die Details zu kodieren.

ISO26262 und Scrum – kein Widerspruch

Erstellt am 15 März 2016
von 1 Komment

Vorvergangene Woche habe ich mit meinem Kollegen Karsten Krennrich im Rahmen der REConf® 2016 einen Workshop mit Repräsentanten aus der Automobilentwicklung veranstaltet. Alle Anwesenden kamen zu der Überzeugung, dass sich die genannte Sicherheitsnorm grundsätzlich unter dem Einsatz des Scrum-Frameworks umsetzen lässt. Ich möchte im Folgenden skizzieren, wie es zu dieser Einschätzung kam.

Die geeignete Lösungsdichte – Welche Frage hätte ich dem Kunden stellen sollen?

Erstellt am 11 Juni 2013
von 1 Komment

Im klassischen Requirements Engineering werden Anforderungen auf verschiedenen Abstraktionsebenen definiert:Abstraktionsebenen

Über die Abstraktionsebenen hinweg sollten die Lösungsdetails idealerweise nach und nach zunehmen. In der Automobilindustrie entspricht die Beschreibung des Ziels dem Lastenheft des Kunden und die abstrakte Beschreibung der Lösung dem Pflichtenheft des Lieferanten.

Das nachfolgende Beispiel zeigt, dass es hilfreich sein kann, über das richtige Maß an Lösungsdichte von Zeit zu Zeit nachzudenken.

Kennen Sie den Unterschied zwischen „logisch“ und „physisch“?

Erstellt am 4 Dezember 2012
von Schreibe einen Kommentar

Während eines Projektes im Umfeld der Systemanalyse eines eingebetteten Systems für die Automobilindustrie erlebte ich es als eine der Hauptherausforderungen, bei der Systemspezifikation die Problem-Ebene von der Lösungs-Ebene zu trennen.

Anforderungen und Design Patterns

Erstellt am 8 Mai 2012
von Schreibe einen Kommentar

Es ist mittlerweile unbestritten, dass Modellierung ein fester Bestandteil des Repertoires eines Anforderungsexperten sein sollte. Software-Designer arbeiten vorwiegend mit Modellen. Ihr Verhältnis zu Anforderungen ist nicht immer ungetrübt und die Zusammenarbeit von Anforderungsexperten und Designern damit nicht immer leicht.

Wie viel Formalisierung benötigt ein Modell?

Erstellt am 27 März 2012
von Schreibe einen Kommentar

Formalisierung von Modellen

Abstraktion durch Modellierung ist im Software- und Systems-Engineering ein bewährtes Mittel. Darstellungen, die auf bestimmte Aspekte reduziert sind, helfen den Projektbeteiligten dabei, hohe Komplexität zu beherrschen. Darum wird in vielen Projekten auch großer Aufwand in das Erschaffen von Modellen investiert. Dieser Aufwand ist umso höher, je mehr formale Kriterien das Modell erfüllen muss. An dieser Stelle stellt sich die Frage, wie viel Formalisierung ein Modell denn tatsächlich benötigt, um seinen Zweck zu erfüllen.