Haben Sie zu viel Geld?

Erstellt am 25 Januar 2017
von Schreibe einen Kommentar

Glaubt man einer Studie der Standish Group aus dem Jahre 2002, könnte man dies glauben. Dieser Studie zufolge werden 45% aller Features eines Produkts nie benutzt. Führen Sie sich die Bedeutung des Wortes „nie“ nochmals vor Augen: diese Features werden nicht gelegentlich, oder selten, oder nur von speziellen, kleinen Zielgruppen genutzt, sondern überhaupt gar nicht! Wozu dann all der Aufwand, all die Zeit, all das Geld während der Entwicklung?

Systems Engineering und Requirements Engineering – Gedanken aus dem Tag des Systems Engineering 2016

Erstellt am 8 November 2016
von Schreibe einen Kommentar

Auch dieses Jahr war ich auf dem Tag des Systems Engineering TdSE 2016. Diesmal in Herzogenaurach, abbildung05wo es wieder viele spannende Themen gab [2]. Als Mitglied der Gesellschaft für Systems Engineering (GfSE) und als Experte für Requirements Engineering bei HOOD verfolge ich mit hohem Interesse die Entwicklung des Systems Engineering (SE) im Bezug zum Requirements Engineering (RE). Mich freut es, dass diese „zwei Gebiete“ immer mehr zusammenwachsen und gemeinsam betrachtet werden.

TdSE 2016 – Trends im Systems Engineering

Erstellt am 2 November 2016
von Schreibe einen Kommentar

Dieses Jahr fand der Tag des Systems Engineerings (TdSE) vom 25. bis zum 27.10.2016  in Herzogenaurach statt. Die gut besuchte Veranstaltung bot den Teilnehmern in Tutorials und Vorträgen viel Abwechslung und neue Informationen rund um das Systems Engineering (SE). Unter vielen Themen kristallisierte sich das Model-Based Systems Engineering (MBSE) als eines der Hauptthemen heraus. In der Zukunft wird der Einsatz von Modellen bei der Entwicklung von komplexen Systemen mit interdisziplinären Teams die durchgängige Basis sein.

Ziele und Nutzen des systematischen Umgangs mit Anforderungen

Erstellt am 19 Juli 2016
von Schreibe einen Kommentar

Ziele von Anforderungen und Requirements EngineeringKürzlich wurde ich wieder gefragt, wie sich der Aufwand von Requirements Engineering rechtfertigen lässt. Immer noch beobachte ich, dass die Tätigkeit des „systematischen Umgangs mit Anforderungen“, dies ist eine moderne Übersetzung des englischen Begriffs „Requirements Engineering and Management“, zu wenig Akzeptanz innerhalb der Unternehmen findet. Es werden verschiedenste Gegenargumente vorgetragen: Für das Projektmanagement ist es viel zu teuer, für die Entwickler und Fachabteilungen ist es „unmotivierter Mehraufwand“ oder „Overhead für Dokumentation“, für manche agile Teams ist es „alter Hut“ und für erfahrene, gewachsene Fachabteilungen ist es „nicht notwendig, das haben wir schon immer so, ohne Anforderungen, gemacht“.

Gewiss, der systematische Umgang mit Anforderungen kostet Zeit und Geld, und der Aufwand muss adäquat an die Struktur und die Gegebenheiten der Organisation, des zu entwickelnden Produktes oder Dienstleistung angepasst werden.

Das Internet der Dinge und seine Auswirkungen auf unsere Welt

Erstellt am 5 Juli 2016
von Schreibe einen Kommentar

Laut einer Prognose auf der diesjährigen Cebit in Hannover werden 50 Milliarden Geräte bis 2020 vernetzt sein.

Perzeptive Umgebungswahrnehmung, Geosensitive Daten, Wearables, Cyberphysikalische Systeme – eine Vielzahl neuer Schlagwörter kursiert in diesen Tagen durch das Netz. Sie künden eine neue Welt der rechnergestützten Informationssystemen an, in denen smarte Alltagsgegenstände mit digitaler Logik, Sensorik und der Möglichkeit zur Vernetzung ein „Internet der Dinge“ bilden.

Anforderungen aus der Tiefe

Erstellt am 5 April 2016
von 2 Kommentare

Anforderungen sind bekanntlich ungenau, fehlerhaft und widersprüchlich. Üblicherweise unterliegen sie außerdem denselben Naturgesetzen wie diejenigen, die sie äußern: Sie altern. Nicht alle Anforderungen leiden dabei unter den gleichen Symptomen gleich stark; einige sind wenige Stunden oder Tage nach ihrer Erstellung bereits zu alt. Andere jedoch altern langsam und in Würde. In ihren Aussagen und Inhalten liegt auch in späteren Projekten noch viel Weisheit und Wahrheit.

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.

HOOD beteiligt sich am BMBF Forschungsvorhaben autoSWIFT

Erstellt am 15 Dezember 2015
von Schreibe einen Kommentar

logo

Schnellere Innovationszyklen für Elektroniksysteme entlang der Automobilwertschöpfungskette

Feature Driven Development – Ein Stück näher an eine agile Vorgehensweise

Erstellt am 8 Dezember 2015
von Schreibe einen Kommentar

Große Unternehmen mit Taylorscher Organisationsstruktur lassen sich nur schwer
komplett in ein agiles Unternehmen verwandeln. Methoden mit agilem Einfluss, wie z.B. „Feature Driven Development“, können jedoch auch in großen Unternehmen schwergewichtige Vorgehensweisen bei der Entwicklung von Produkten vereinfachen.