Risiken & Maßnahmen einer App-Entwicklung

2 Antworten

Muahaha... das könnte eine endlose Liste werden. Fangen wir doch einfach mal mit ein paar Punkten an:

- Tod durch Hypermodellierung

Setze ein paar frische Hochschulabsolventen an eine OO-Entwicklung. Die sind ja frisch und deswegen billig zu haben, werden also in der Praxis aus finanziellen Gründen gern genommen. Da kommen dann nach etlichen Wochen auch ganz tolle Objektmodelle bei raus. Dann ist 80 % des Budgets weg. Am Ende der Projektlaufzeit steht ein Dummy, der den Startscreen zeigt. Und nichts funktioniert. Aber das Objektmodell war gut.

- Einstürzende Turmbauten zu Babel

Da heutzutage ja niemand mehr selbst die trivialsten Algorithmen implementieren kann, nimmt man für alles irgendwelche vorhandenen Toolkits, Codegeneratoren und Libraries daher. Innerhalb kürzester Zeit wird das Executable aberwitzig groß, crasht ständig weg und niemand weiß, was da in dem ganzen Gelump schief geht. Am Ende ist da ein Big Ball of Mud, der nicht stabil zu kriegen ist. Glückwunsch zur Entwicklung für die Tonne.

- Ach, die Software soll auch was tun, und nicht nur bunte Bildchen machen?

Das Standardproblem von agenturgetriebenen Projekten. Hunderte Seiten Hochglanz-PDF mit pixelgenauen Darstellungen toller Bedienoberflächen. Aber nirgendwo steht, was die Software dann eigentlich tun soll. Und für die Verwaltung von Ablaufdaten fühlt sich auch niemand zuständig. Am Ende merkt man, dass man ja eigentlich einen zentralen Server bräuchte. Aber den gibt es nicht, auch keine Schnittstellen, und schon gar kein Budget. Das war's dann.

- Oh, ein neuer Eierföhn ist da!

Wenn die Apfelplantage in Wildwest mal wieder ein neues Spielzeug raushaut, ist der Hype natürlich groß. Und der Frust bei allen, die bereits Software für die Vormodelle entwickelt haben, auch. Denn nun muss alles für das neue Tamagotchi angepasst werden. Wer bleibt auf den Kosten sitzen? Mit Pech die Entwicklerfirma.

- Schock-Konfrontation: OO-Entwickler und die reale Welt.

Die Objektkiddies (s. o.) können ja schöne Dinge modellieren. Blöderweise hat man gerade bei größeren Projekten mit der realen Welt(TM) zu tun. Und möglicherweise auch anderen Softwaresystemen, zu denen Schnittstellen unterhalten werden müssen. Und diese Softwaresysteme sind vielleicht nicht so akademisch-stylisch-OO-mäßig-hip gebaut wie das Geniestück, was man sich da selbst erdacht hat. Da brechen dann teilweise Welten zusaammen. Und Schnittstellenkonzepte auch.

- Overhead durch Overhead, weil Overhead Programm ist.

Wie, Du willst einen Zwischenstand der App testweise auf einen Eierföhn bringen? Dann melde Dich erstmal bei Apfeldingsda an. Dann kannst Du Dir Zertifkate ziehen, um die gegen andere Zertifikate einzutauschen, mit denen Du irgendwo was hochladen kannst, was dann mit dem nächsten Zertifikat sich auch wieder einen runter... ähh... wo dann der App-Download erfolgen kann. Natürlich nur durch registrierte und zertifizierte Dingsdas, äh, Entwickler. Und willst Du dem Auftraggeber mal was zeigen, muss der den ganzen Rotz auch machen. Frage an den Projektcontroller: hat der wohl diese ganzen Meta-Aufwände in seiner Budget-Kalkulation berücksichtigt?

- Push Noticiations sind in, koste es was es wolle

Kaum ein Projektmanager weiß, dass die Integration von Push Notifications in eine Client-/Server-Umgebung mit App ungefähr 100mal so viel Aufwand macht, wie der Versand einer simplen SMS. Was ist nun wichtiger? Ökonomie oder der Hip-und-in-Faktor?

Man könnte noch ca. 100 weiterer solcher Punkte anführen. Es ist einfach nur grauenhaft.

CSANecromancer  28.04.2015, 09:10

Es ist einfach nur grauenhaft.

Und was noch viel schlimmer ist: All das Geschriebene entspricht tatsächlich der Realität.

Dennoch: Vielen Dank. Ich konnte an einigen Stellen sehr herzhaft lachen ("...Big Ball of Mud...") und fühle mich SEHR an mein Projekt hier erinnert.

0

Die jungen Enduser denken häufig auch nicht wirklich darüber nach, was ein Kunde wirklich gebrauchen könnte: Wer braucht schon spezialisierte Apps für GF, Amazon, ebay, Bankenapps … Die Anzeige der Offerten ist ja nun wirklich nicht besser wie im „normalen“ Webauftritt. Aber man kann dann mit 800 Apps und mehr auf dem eiphön oder dem Sams protzen.

Risiken kann man auch in den Lizenzbedingungen für die Entwickler ausschließen. Es ist schließlich Sache des Endanwenders, ob berechnete Zahlen stimmig sind oder nicht. Datenbanken, CAD-Programme und Spreadsheets sind ja nun auch nicht das Thema. Schließlich gibt es die wie Sand am Meer. Und welche Risiken bleiben denn effektiv bei einer Game-App? Abstürze, weil eine bestimmte Konfiguration nicht passt? Welcher Entwickler kann schon bei seinen Apps alle System-Konfigurationen kennen? Unter Windoof gibt es da inzwischen wahrscheinlich Millionen verschiedenst und billigst zusammengestoppelter Computer …