Die genannten Risiken, Probleme und deren Ursachen resultieren in einer Reihe von Herausforderungen, die insbesondere für Softwareentwicklungsprojekte für industrielle Informationssysteme zutreffen. Die wesentlichen Herausforderungen im Software Engineering sind dabei:
Eine zentrale Herausforderung in industriellen Softwareprojekten ist der Umgang und die Berücksichtigung von Ungewissheit während des gesamten Projektverlaufs. Dabei kann zwischen wirtschaftlicher und technologischer Ungewissheit unterschieden werden.
Untenstehende Abbildung zeigt zur Veranschaulichung der wirtschaftlichen Ungewissheit den mit statistischen Methoden ermittelten "Cone
of Uncertainty" (deutsch: Kegel der Ungewissheit). Die vertikale Achse (Y-Achse) stellt den Grad der Ungewissheit dar, die horizontale
Achse (X-Achse) den Verlauf eines Softwareprojektes über die Zeit. Am linken Rand startet das Projekt, am rechten Rand ist es beendet.
Der in der Abbildung gezeigte Graph hat die Form eines um 90° gedrehten Kegels: Je früher in einem Projekt die Gesamtkosten
geschätzt werden, umso höher ist die Abweichung vom tatsächlichen Aufwand am Projektende. Mit zunehmendem Verlauf wird eine
Schätzung der Gesamtkosten genauer, jedoch kann erst am Projektende präzise gesagt werden, wie hoch der Aufwand tatsächlich
ist. Im Gegensatz zu Produktionsprozessen, bei denen der Verbrauch von Ressourcen und die Dauer der einzelnen Arbeitsschritte berechnet
werden kann, ist eine vergleichbare präzise Vorhersage bei Softwareprojekten in der Regel nicht möglich.
In etwa vergleichbar mit der wirtschaftlichen Ungewissheit lässt sich zu Beginn eines Softwareprojekts zwar ein technisches Zielbild
erstellen, jedoch die tatsächliche technische Lösung erst am Ende des Projekts genau bestimmen. Unten stehende Abbildung
veranschaulicht schematisch den Verlauf der technischen Ungewissheit in einem Softwareprojekt. Zu Beginn eines Projekts gibt es bezüglich
der Festlegung auf zu verwendende Technologien noch einen großen Entscheidungsspielraum. Jeweils auf Basis des aktuellen Wissens zu einem
Zeitpunkt im Projekt werden technische Entscheidungen vom Softwarearchitekt getroffen, um die zu diesem Zeitpunkt bekannten Anforderungen
möglichst gut zu unterstützen. Da jedoch Anforderungen erst im Verlauf des Projekts erkannt werden, müssen die
Zwischenergebnisse kontinuierlich geprüft werden. Im Rahmen des zur Verfügung stehenden Entscheidungsspielraumes, kann die
technische Lösung daraufhin weiter angepasst und ausgebaut werden. Dabei werden in der Regel die möglichen
Entscheidungsspielräume hinsichtlich der technischen Lösung mit dem Verlauf des Projekts immer kleiner, bis mit Projektende eine
konkrete Lösung erarbeitet ist. Das bedeutet auch, dass vergleichbar mit der wirtschaftlichen Ungewissheit während des Projekts
auch eine technische Ungewissheit vom Projektteam ausgehalten werden muss.
Die Einbeziehung verschiedenster Personengruppen (sogenannter Stakeholder) mit jeweils unterschiedlichen persönlichen Hintergründen,
Kenntnissen und Interessen stellt eine weitere gewichtige Herausforderung an Softwareprojekte dar. Neben der Etablierung und Aufrechterhaltung
der Kooperationsbereitschaft und der Kommunikation müssen neue Erkenntnisse und gegebenenfalls Planänderungen allen relevanten
Stakeholdern in einer für sie verständlichen Art und Weise kommuniziert werden. Darüber hinaus müssen sowohl beim Treffen
von Entscheidungen als auch bei der Qualitätssicherung von im Softwareprozess erzeugten Artefakten die relevanten Stakeholder aktiv
miteinbezogen werden. Der untenstehende Cartoon veranschaulicht auf humorvolle Art und Weise die Auswirkungen von Pannen in der
Projektkommunikation.
Zwar ist auch bei Softwareprojekten die Kundenzufriedenheit das oberste Ziel, jedoch bewegen sich auch Entscheidungen innerhalb von
Softwareprojekten zwischen den Größen Qualität, Termin und Kosten. Folgende Abbildung illustriert ein typisches
Entscheidungsdilemma mit Hilfe des sogenannten magischen Dreiecks: Wenn man eine Zielgröße ändert, beeinflusst das auch die
beiden anderen Zielgrößen.
Beispiel: Wenn im Rahmen eines Projekts ein sehr großer Wert auf Qualitätssicherung gelegt wird, gehen die Aktivitäten der Qualitätssicherung zu Lasten der rechtzeitigen Fertigstellung. Wenn der Fokus auf die Projektkosten gelegt wird und dabei alle Termine einzuhalten sind, dann bleiben weniger Ressourcen für die Qualitätssicherung. Wenn aber ein Projekt in hoher Qualität punktgenau zu einem Termin ausgeliefert werden soll, dann wird der Kostenrahmen nicht zu halten sein.
Aufgrund der oben bereits vorgestellten Ungewissheit zusammen mit dem kontinuierlichen Erkenntnisgewinn während der Projektdurchführung ändern sich in Softwareprojekten die Größen des "Magischen Dreiecks" ebenfalls kontinuierlich. Das hat wiederum häufig Abstimmungs- und Entscheidungsprozesse zwischen dem Projektteam und den Stakeholdern zur Konsequenz.
Die dringliche Komplexität von industriellen Softwaresystemen (viele technische Komponenten, viele Schnittstellen zu anderen Systemen, viele implementierte Funktionen) stellt im Zusammenspiel mit der Immaterialität von Software hohe Anforderungen an das menschliche Abstraktionsvermögen. Weil die Interna von fertiger Software nicht sichtbar sind, veranschaulicht man die Zusammenhänge mithilfe von grafischen Modellen. Der Rückschluss von einem grafischen Modell auf die Struktur und das Verhalten der Software ist eine intellektuelle Leistung.
Der Einsatz von grafischen Softwaremodellen ist eine zentrale Technik im Software Engineering, zu der es aktuell keine sinnvollen Alternativen gibt. Zur Beherrschung von Komplexität wurden verschiedene Arten von Modellen entwickelt, die in unterschiedlichen Detailgraden statische und dynamische Aspekte von Softwaresystemen veranschaulichen.
Unter der Prämisse der Ungewissheit und des Erkenntnisgewinns im Verlauf eines Softwareprojekts sollten sowohl die organisatorische Planung (Ressourcen und Aktivitäten) als auch die technische Planung (Spezifikation, grafische Softwaremodelle) nur bis zu dem Grad erstellt werden, der für die aktuelle Phase des Projekts angemessen ist.
In Softwareprojekten werden Unsicherheiten oftmals dadurch versucht zu kompensieren, dass ein möglichst genauer Plan bzw. ein möglichst detailliertes Modell aller möglichen Eventualitäten erstellt wird. Das bedeutet, entweder wird ein zu detaillierter Projektplan erstellt, der für das gesamte Projekt vorhersagen soll, welche Aktivitäten von wem mit welchem Aufwand durchgeführt werden sollen. Oder die fachlichen Anforderungen bzw. die Lösungsideen des Softwaresystems werden auf einer sehr detaillierten Ebene durchdacht und zum Beispiel in Form von umfangreichen Modellen dokumentiert. Dieses Phänomen heißt "Analysis Paralysis". Komplexität gepaart mit Ungewissheit birgt die Gefahr von unangemessenen aufwendigen Analyseaktivitäten. Dabei wird versucht, durch die Produktion komplexer Analyseergebnisse die Ungewissheit auszublenden, beispielsweise in Form von großen und komplexen Softwaremodellen. Das Team traut sich oft nicht einfach zu, etwas auszuprobieren, sondern versucht erst alles im Detail zu durchdenken. Die Gefahr der "Analysis Paralysis" besteht darin, dass viele Ressourcen gebunden werden, die bei der Umsetzung einer ersten Softwareversion fehlen. Die zu Beginn aufwendig erstellten Analysemodelle veralten jedoch oft durch neu gewonnene Erkenntnisse bei der Umsetzung und Vorstellung der ersten Softwareversion.