Softwareprojekte kosten meist viel und sie sind immer mit einem mehr oder weniger grossen Risiko behaftet. Die wichtigsten Probleme sind nachstehend aufgeführt.
Diverse Untersuchungen haben gezeigt, dass das grösste Projektrisiko im Bereich der Anforderungen liegt. Folgende Probleme existieren im Zusammenhang mit Anforderungen:
|
¢ |
Anforderungen liegen nicht einfach auf dem Tisch: Eine mässig strukturierte Sammlung von Bedürfnissen, Zielen, Vorstellungen oder Bildschirmskizzen (oft als sog. Pflichtenheft bezeichnet) entspricht nicht dem, was die Entwickler als "echtes" Pflichtenheft bzw. Anforderungen benötigen, um das "richtige" System zu bauen. |
|
¢ |
Die Ermittlung der Anforderungen ist mühsam und keine Arbeit für Freitag zwischen 4 und 6. Es ist „knochenharte“ Denkarbeit und sie bedingt ausserdem ein hohes Mass an Kommunikation, sei es in schriftlicher oder mündlicher Art. Und sie hat immer einen „analytischen“ bzw. „diagnostischen“ Teil“ (was muss ich lösen) sowie einen „Entwurfsteil“ (wie soll es künftig haben“). Beides ist nötig. Es nützt (in den meisten Fällen) nichts, wenn „jemand“ die Anforderungen im Kopf hat. Anforderungen müssen klar, widerspruchsfrei und für Dritte verständlich sein. |
|
¢ |
Entwickler wenden oft zu wenig Zeit auf, um die Anforderungen zu "erforschen" bzw. um die Anforderungen mit dem Benutzer abzustimmen. Im Bestreben, den gesteckten Termin zu erreichen, treffen sie dann oft einfach unkonsolidierte "Annahmen" und programmieren "irgend ein System", oft aber nicht jenes, welches der Benutzer (mental) bestellt hat. |
|
¢ |
Benutzer sind oft nicht in der Lage bzw. haben keine Zeit, ihre Anforderungen präzise zu formulieren. Sie sagen dann "mach mal einen Vorschlag, dann kann ich es Dir genauer sagen). Benutzer werden also erst so richtig "kreativ", wenn sie erste Lösungsvorschläge sehen. Anforderungen sind also (in etwa wie Wasseradern) verborgen und man muss sie "irgendwie" aus den Köpfen der (richtigen!) Benutzer "herausholen". |
|
¢ |
Anforderungen kommen von unterschiedlichen Quellen, Personen bzw. Personengruppen. Benutzer haben oft nicht dieselben Interessen wie deren Vorgesetzte, Interessenvertreter vertreten unter Umständen nicht immer deren Stakeholder. |
|
¢ |
Es gibt völlig unterschiedliche Arten von Anforderungen mit unterschiedlichen Detaillierungsgraden. |
|
¢ |
Anforderungen ändern sich meist im Zeitablauf. |
|
¢ |
Worte genügen oft nicht: Anforderungen können oft nicht ohne weiteres präzise mit Worten formuliert werden. |
|
¢ |
Die Menge der Anforderungen kann unter Umständen sehr gross und damit unkontrollierbar werden. Anforderungen sind oft miteinander verknüpft (interdependent). Eine veränderte oder neue Anforderung hat oft Implikationen auf andere Anforderungen oder bereits existierende (unter Umständen). |
Requirements Engineering (im vorliegenden Modell als "Anforderungsanalyse" bezeichnet ist vermutlich die schwierigste Aufgabe in einem Projekt. Sie sollte mit Vorteil durch entsprechend geschulte Entwickler bzw. „Analysten“ durchgeführt werden.
Ein zweites wesentliches Problem ist das Bauproblem. Selbst wenn die Anforderungen bekannt sind, so können Projekte trotzdem immer noch zu lange dauern oder zu viel kosten. Die Hauptprobleme sind:
● Die Technologie für den Bau von Informatiklösungen ist immer noch jung und noch immer eine stetigen Wandel unterworfen. In den 80-er und 80-er Jahren realisierte man "Hostlösungen", in den 90-er Jahren Client/Server-Lösungen, heute realisiert man zunehmend Intranetlösungen. Ähnliches gilt auch im Bereich der Methodik: sprach man früher von strukturierter Analyse oder von konzeptionellen Datenmodellen, so spricht man heute z.B. von Use-Case- oder Klassendiagrammen.
● Es existieren wenig normierte bzw. problemlos einsetzbare Softwarekomponenten. Ein Küchenbauer baut eine Küche mit Ganzfabrikaten (z.B. Spülmaschine, Backofen) sowie Halbfabrikaten wie z.B. Rohre, Verbindungsrohre etc. zusammen. Der z.B. im Baugewerbe oder im Maschinenbau existierende hohe Normierungsgrad dauerte Jahrzehnte oder mehr. Im Vergleich dazu ist die Informatik noch jung. Es existieren zwar viele Normenvorschläge und auch Bauteile, aber insgesamt befinden wir uns hier noch weit weg vom Niveau, wie es klassische Ingenieursdisziplinen erreicht haben. Natürlich wird die Etablierung stabiler, wieder verwendbarer Softwarekomponenten zusätzlich erschwert durch den oben genannten stetigen technologischen Wandel.
Die eben genannten Hauptprobleme (Technologischer Wandel sowie fehlende Softwarekomponenten hat natürlich diverse Konsequenzen:
● Softwarefirmen bzw. deren Mitarbeiter müssen fortlaufend neue Technologien und Methoden erlernen. Das kostet immer wieder Lerngeld und macht zuverlässige Prognosen bzgl. Terminen, Kosten sowie Qualität (z.B. Performance) ziemlich schwierig.
● Müsste ein Küchenbauer noch seine eigenen Rohre oder gar noch massgeschneiderte Spülmaschinen bauen), dann wäre das Projekt ziemlich teuer und zudem schwer abschätzbar.
Selbst wenn man die Anforderungen kennt und die Fähigkeiten bzw. Hilfsmittel hat, um das System zu bauen, so bleiben die Restriktionen eines jeden Projekts:
● Oft existieren "harte" Termine
● Mitarbeiter stehen nur in beschränkten Ausmass zur Verfügung und kosten Geld
● Das resultierende Softwareprodukt muss eine "vernünftige" (der Zeit und dem Geld angepasste) Qualität aufweisen.
Projektergebnisse sind also meistens ein Optimum und nur selten ein Maximum. Um ein Optimum bei vordefinierter Qualität zu erreichen, müssen fast immer die Anforderungen den „Umständen“ angepasst werden.