Die immer stärkere Verschmelzung und Überlagerung der Wissensanforderungen verlangt nach tief greifenden Veränderungen der Entwicklungsprozesse und verändert die Erwartungshaltung an die unterschiedlichen Technologien: Die Flexibilität von Software wird wesentlich höher bewertet als die von elektronischen oder mechanischen Komponenten. Zusätzlich sind die technologischen Lebenszyklen zwischen Mechanik, Elektronik und Software elementar unterschiedlich. Die Wissensfusion führt zu einem Anstieg der Freiheitsgrade in den möglichen Lösungen, die bei Projektstart weder vollständig bekannt sind, noch entschieden werden können. Diese Verlagerung von Entscheidungen in die Projekte zwingt die Unternehmen, sich von dem Plan-Steuerungsverfahren zu verabschieden und stattdessen kleine Regelkreise in der Projektabwicklung zu installieren. Der Projektleiter übernimmt in diesem Prozessmodell die Funktion des Reglers. Seine Aufgabe ist es, den Projektverlauf so zu beeinflussen, dass dieser möglichst nicht oder nur gering vom Fortschrittsplan abweicht. Die Anforderungen lauten:

• termingerechter Synchronisation der Entwicklungsprozesse,
• erhöhter Transparenz der Funktionserfüllung der Software,
• ständiger Interaktion zwischen den Wissensträgern der verschiedenen Technologien und
• Sicherstellung der Wieder- und Weiterverwendbarkeit von Software.

Termingerechte Synchronisation

Durch die steigenden Anforderungen an die Flexibilität, Funktionalität und Updatefähigkeit von Systemen werden immer größere Anteile der Produktfunktionalität in Software realisiert. Gleichzeit steigen die Anforderungen an Sicherheit und Zuverlässigkeit extrem an.
Das in Softwareentwicklungsprozessen häufig umgesetzte V-Modell realisiert eine direkte Rückkopplung der implementierten Softwarefunktionalität in die Entwicklung mit dem Ziel, die Qualitätssicherung durch schnelle Fehlererkennung und -behebung effizienter zu gestalten.

Durch seine Fokussierung auf die Softwareentwicklung ist es jedoch nur begrenzt geeignet für die Integration eines Gesamtsystems bestehend aus Mechanik, Elektronik und Software. Der Prozess der Integration und Freigabe eines Gesamtsystems ist geprägt durch eine festgelegte Abfolge von Musterständen. Ein Musterstand entsteht durch die Integration aller Systemkomponenten zu einer funktionsfähigen Einheit mit genau definierter Funktionalität zu einem definierten Zeitpunkt. Der Softwareentwicklungsprozess muss an diese spezifischen Anforderungen der technologieübergreifenden Synchronisierung von Musterständen angepasst und in den Gesamtentwicklungsprozess integriert werden.

Transparenz der Funktionserfüllung

Um in einem mustersynchronen Entwicklungsprozess die Komplexität beherrschen und die Qualität in allen Entwicklungsphasen sicherstellen zu können, bedarf es einer hohen Transparenz des real erreichten Projektfortschritts. Die objektive Messung des Projektfortschritts stellt somit eine elementare Anforderung an den Entwicklungsprozess dar und muss die Bewertung des Projekts aus unterschiedlichen Blickwinkeln ermöglichen. Die Erfassung des Projektfortschritts in den folgenden fünf Dimensionen liefert die geforderte Transparenz als Voraussetzung für eine erfolgreiche Projektsteuerung:

• Arbeitsfortschritt,
• Funktionserfüllung,
• Kumulierter Reifegrad,
• Fehlerstatus,
• Termintreue.

Der Arbeitsfortschritt ist ein Maß für die inhaltliche Bewertung der erzielten Ergebnisse, gemessen in „Arbeitswerten“; mit der Funktionserfüllung werden die gleichen Ergebnisse unter dem Aspekt der erzielten Funktionalität bewertet. Der kumulierte Reifegrad misst den Implementierungsstand der Software und der Fehlerstatus ist ein Maß für die erreichte Qualität. Aktualität und Verlässlichkeit der Planung werden mit der Termintreue gemessen.

Interaktion zwischen den Wissensträgern

Mit der Möglichkeit, Funktionen über Mechanik, Elektronik oder Software realisieren zu können, kann die Funktionslösung nicht mehr durch einen Fachbereich alleine vorgegeben werden. Um die gewünschte Wissensfusion zu erreichen, müssen die Denkweisen unterschiedlicher Disziplinen zusammenwirken. Dies wird jedoch erschwert durch unterschiedliche Vorgehensweisen, Terminologien und erforderliches Abstraktionsvermögen. In der Praxis hat dies oft Disharmonien in der Entscheidungsfindung zur Folge und verlangt von allen am Projekt beteiligten Wissensträgern die Offenheit und Bereitschaft zur Interaktion.

Wieder- und Weiterverwendbarkeit von Software

Die hohen Entwicklungsaufwendungen zwingen die Unternehmen dazu, bewährte Lösungen möglichst nicht nur einmal, sondern mehrfach zu nutzen. Hierbei unterscheidet man zwischen Weiter- und Wiederverwendbarkeit. Unter Weiterverwendbarkeit ist die Verwendung von Softwaremodulen innerhalb eines Projektes zu verstehen. Dies soll vor allem für Teillösungen gelten, die aufgrund der musterbezogenen Systemsynchronisation benötigt werden. Im Projekt muss sichergestellt werden, dass Softwaremodule präzise dokumentiert und von einem Musterstand zum nächsten identisch weiterverwendet oder kompatibel weiterentwickelt werden.

Um die Chance auf Wiederverwendbarkeit (Multiplikation) in weiteren Projekten und Produkten zu gewährleisten sind die unternehmerischen Randbedingungen zu ändern. Nicht nur die Vorgabe einer modularen Softwarestruktur, sondern auch die Erzeugung eines kosten- und terminorientierten Applikationszwangs führt dazu, vorhandene Lösungen (Module) nicht unbegründet in Frage zu stellen.

Die konsequente Wieder- und Weiterverwendung von Softwaremodulen (Feature) hat wesentlichen Einfluss auf Entwicklungszeit, -kosten und -qualität. Sie erhöht die Produktivität bei gleichzeitiger Verringerung des Terminrisikos der musterbezogenen Systemintegration und muss deshalb integraler Bestandteil zukünftiger Softwareentwicklungsprozesse sein.