Archiv verlassen und diese Seite im Standarddesign anzeigen : Warum ist Software heutzutage so Bugverseucht?
Wenn man heute in den Laden geht und ein Softwareprodukt kauft,
dann ist die Wahrscheinlichkeit, daß es Bugs erhält sehr groß und dabei ist es egal, ob es eine Endanwendersoftware oder ein Computerspiel ist.
Auch wird ja immer als Begründung dafür angeführt, daß kein Softwareprodukt fehlerfrei sein kann.
So weit so gut, aber genau deswegen hat man doch moderne Programmiersprachen und bessere Methoden zur Softwareentwicklung entwickelt, die Features wie z.B. Objekt Orientierte Programmierung, Garbage Collector oder Typsicherheit bieten.
Und Dinge wie UML und vor allem modularisiertes Softwaredesign gab es früher auch nicht.
Warum ist die Software von heute also mit mehr Bugs verseucht, als die Software von früher, wo man doch gerade heute die Werkzeuge hat, um Bugs größtenteils zu vermeiden?
Nur zur reinen Information:
Früher hat man Software vorwiegend in C entwickelt, einen Garbage Collector und die OOP gab es da nicht, auch ist C durch die Pointerarithmetik nicht sicher vor Pufferüberläufen, d.h. die Sprache schützt den Programmierer in C nicht vor seinen Fehlern.
Diese Probleme sind in modernen Sprachen wie z.b. Java, D und teilweise auch C++ (wenn man richtig programmiert) kaum noch vorhanden.
Warum ist also gerade bei modernen Produkten die Fehlerhäufigkeit größer?
Krishty
2009-01-03, 18:13:42
Hast du Beweise, dass die Software heute mehr Bugs enthält als damals? Bei Betriebssystemen ist das nämlich nachweislich nicht so.
PS:
Fast hätte ich es vergessen.
Und im Gegensatz zu früher kommt noch hinzu, daß auch die Betriebssysteme heute alle eine stabiliere Basis bieten, mindestens 32 bittig sind und die Speicherverwaltung deutlich besser als zu Win95 Zeiten ist.
Auch hat der heutige Programmierer Zugriff auf deutlich Wartungsfreundlichere Toolkits, während er früher nur die in C geschriebene WinAPI oder das in C++ geschriebene schlechte MFC für Windows hatte.
Watson007
2009-01-03, 18:14:41
vielleicht weil gleichermaßen die Anforderungen an eine moderne Software gestiegen sind, also die Featureities? Es ist nunmal so, nur neue Features berechtigen aus Kundensicht zu einem Update...
Und noch etwas habe ich vergessen:
Auch gibt es nicht nur stabile Toolkits, sondern natürlich auch stabile APIs die die Hardwareinkompatibilitäten gut abstrahieren.
Das gab es früher auch nicht.
Hast du Beweise, dass die Software heute mehr Bugs enthält als damals? Bei Betriebssystemen ist das nämlich nachweislich nicht so.
Ja, bei den Computerspielen waren früher zu DOS Zeiten kaum Patches für die Spiele notwendig, heutzutage sind Spiele, die gleich nach Produktrelease keinen Patch mehr brauchen sehr selten geworden.
Ganz ähnlich sieht es mit Office Apllikationen aus.
Vergleiche einfach mal Word 5.0 mit MS Office 2003.
Wuzel
2009-01-03, 18:19:49
1. Ist die Sache heute komplexer den je
und zweitens:
Hast du Beweise, dass die Software heute mehr Bugs enthält als damals? Bei Betriebssystemen ist das nämlich nachweislich nicht so.
Mit Sprachen und Technologien hat die Problematik eigentlich nichts biss garnichts zu tun.
vielleicht weil gleichermaßen die Anforderungen an eine moderne Software gestiegen sind, also die Featureities? Es ist nunmal so, nur neue Features berechtigen aus Kundensicht zu einem Update...
Dem muß aber entgegengestellt werden, daß die Werkzeuge wie Toolkits, API, Programmiersprache etc. heute viel besser sind und neue Produkte modularisiert gebaut werden, die mehr Features eigentlich erlauben sollten ohne das dabei darunter die Qualität des Produkts leidet.
Früher war es unwesentlich schwieriger in einem monolithischen Spagetthi Code der mit Assembler und C geschmückt ist neue Features einzubauen.
1. Ist die Sache heute komplexer den je
und zweitens:
Das glaube ich nicht.
Früher mußte man sogar auch noch die Hardware berücksichtigen.
Man denke nur an die verschiednene Grafikstandards und die Tatsache, daß man für höhere Auflösungen als Standard VGA auch noch Treiber schreiben mußte.
Auch hatte man viel weniger Speicher zur Verfügung, d.h. man mußte auf fette Sprachen die die Programmierarbeit deutlich erleichtern aus Speicher und Performancegründen verzichten und hat oft deswegen ein schlankes C und Assembler verwendet.
Mit Sprachen und Technologien hat die Problematik eigentlich nichts biss garnichts zu tun.
Das sehe ich GANZ anders.
Wuzel
2009-01-03, 18:31:06
Das glaube ich nicht.
Früher mußte man sogar auch noch die Hardware berücksichtigen.
Man denke nur an die verschiednene Grafikstandards und die Tatsache, daß man für höhere Auflösungen als Standard VGA auch noch Treiber schreiben mußte.
Auch hatte man viel weniger Speicher zur Verfügung, d.h. man mußte auf fette Sprachen die die Programmierarbeit deutlich erleichtern aus Speicher und Performancegründen verzichten und hat oft deswegen ein schlankes C und Assembler verwendet.
Das sehe ich GANZ anders.
Dann vergleiche doch einmal die Anzahl der Quellcode Zeilen von früher zu heute ;)
Mehr Code = mehr mögliche Fehler.
Heute wird viel mehr abverlangt, das können selbst modernste Software Technologien nicht abfangen.
Sehr heiss ist diesbezüglich die Philo. hinter GTK(+) und GNOME - less dich da einmal rein, die dürften dir sympathisch sein ;)
Da wurde die Thematik in den letzten Jahren ziemlich stark angegangen - dreimal darf man raten warum C und warum alles schlank und simpel :)
Monger
2009-01-03, 18:40:27
Zum ersten: moderne Tools werden weniger genutzt als man mitunter denkt. Wir haben in der Firma erst vor drei, vier Jahren überhaupt angefangen über einen Umstieg von C++ auf .NET nachzudenken. Einige Projekte werden jetzt tatsächlich darin schon umgesetzt, aber beileibe nicht alle - nichtmal die meisten. In der Spielewelt scheint mir dieser Fortschritt noch überhaupt nicht angekommen zu sein.
Zum zweiten: Software ist heute mitunter unvorstellbar groß. Gerade die Erwartungshaltung dass man im 21. Jahrhundert doch flugs mal eine eierlegende Wollmilchsau zusammenfrickeln können müsste, weckt in den Kunden (und damit dem Marketing) völlig unrealistische Wünsche. Meistens sind es dann die "Nice-to-Have"s die letztendlich wirklich Zeit fressen.
Zum dritten: ich lehne mich mal weit aus dem Fenster, und sage: aus Sicht des Entwicklers ist ein ordentlicher Crash besser als wenn das Programm weiterläuft und in irgendeinen undeterminierten Zustand hinein läuft, wo vielleicht sogar die Datenhaltung korrumpiert werden kann. Eine Folge von gutem Exception Handling ist dann eben auch, dass sich z.B. ein Word lieber selbst abschießt, bevor es dem Anwender die Chance lässt ein korruptes Word Dokument zu speichern.
Zum vierten: die Werkzeuge für Projektmanagement sind schon länger da. Diese aber auch umzusetzen ist schlicht höllisch. Je größer ein Team, desto träger greifen da Reformen. Die Leute müssen ja auch eingelernt werden. Wenn da Leute als Projektleiter und Entwickler am Ruder sitzen die noch in den 70ern angefangen haben, tun die sich mit der Einführung von neuen Verfahren naturgemäß auch schwer.
Wie so oft: die technische Entwicklung war da wiedermal weit schneller als die organisatorischen Strukturen. Die Ansprüche orientieren sich aber natürlich am technischen Level. Das muss natürlich krachen.
Wenn wir tatsächlich Softwareprojekte von vergleichbarer Dimension von vor 20 Jahren und heute vergleichen würden, wären wir heute natürlich deutlich schneller und bugfreier fertig. Nur wirst du heute an einen popeligen Text Editor nicht mehr ein 20-Mann Team für fünf Jahre setzen.
Abraxus
2009-01-03, 18:41:08
Software weißt heutzutage noch genausoviel Fehler auf wie früher auch. Es hat sich also Quallitativ betrachtet nicht viel getan. Wenn man jetzt aber hinzunimmt das die Software seit früher viel komplexer geworden ist, so ist doch eine wirkliche Verbesserung eingetreten, welche eigentlich einem Wunder gleichkommt. Wir haben sozusagen unseren Level von "Rückläufern" nicht verbessert, aber auch nicht verschlechtert, und das bei steigenden Ansprüchen und Komplexität.
Krishty
2009-01-03, 19:01:42
Ja, bei den Computerspielen waren früher zu DOS Zeiten kaum Patches für die Spiele notwendig, heutzutage sind Spiele, die gleich nach Produktrelease keinen Patch mehr brauchen sehr selten geworden.Zu DOS-Zeiten konnte man auch nicht mal schnell einen Patch ins Internet stellen, von dem dann jeder Spieler am selben Tag auf der Website der Community seines Vertrauens liest und ihn sich saugt… und von deinen subjektiven Eindrücken kann sich hier niemand was kaufen. Zahlen bitte, und möglichst unabhängige sollten es schon sein.
Eggcake
2009-01-03, 19:24:00
Ein Grund dürfte ja wohl garantiert der viel grössere Quellcode sein.
Argumente wie bessere Tools etc. zählen imho nur sehr begrenzt.
Ganz simples Beispiel:
Programm von früher: 100 Zeilen
Programm von heute: 100000 Zeilen
Das Programm von früher hat 100 fehlerhafte Zeilen, das von heute 200. Doppelt soviel!
So und nun erklär mir mal wie du beim alten Programm überhaupt auf 200 fehlerhafte Zeilen kommen willst. Zudem hast du im alten Programm 100% fehlerhafte Zeilen. Aber insgesamt weniger...yay!
In Wirklichkeit ist der Quellcode von heutiger Software ja wohl noch um ein Vielfaches grösser als derjenige von früher Software.
Zudem hast du im Prinzip sowieso keine Vergleichsmöglichkeit, da du heutige Software nicht mit alter Software vergleichen kannst, weil so komplexe Programme schlicht nicht existierten. Man kann also unmöglich Aussagen darüber machen, wie das Programm wohl in der Vergangenheit ausgesehen hätte...
In erster Linie dürfte es daran liegen, das viele Software unter Zeitdruck erstellt wird, da fehlt einfach die Zeit und das Geld die Programme zu optimieren.
Bei professioneller Software kann das anders aussehen, da werden unsummen in die Entwicklung gesteckt, dafür ist aber auch der Preis entsprechend hoch.
Andererseits ist die Software auch immer komplexer und umfangreicher geworden. Die Entwicklertools verbessern sich zwar auch, aber man muss sich nur mal überlegen, wie komplex eine Anwendung heute ist und wie komplex damals.
Beim C64 und unter DOS konnte eine einzelne Person noch ein ganzes Programm selbst proggen.
Das geht zwar heute auch noch, aber bis jemand ein echtes 3D-Spiel fertig hätte wie wir es kennen, wäre er sicher schon 10-20 Jahre älter.
Da arbeiten zum Teil 50 Leute über mehrere Jahre dran, früher waren es 2-3 :)
Der Mensch hat sich in dieser Zeit nämlich nicht weiter entwickelt und kann mit dem technologischen Fortschritt nicht mithalten.
Wenn ihr mal bedenkt, das eine Software aus 1 Million Codezeilen bestehen kann und ihr dort jede Passage kontrollieren müsstet, werdet ihr irgendwann nachlässig.
Das Problem wird dann ja noch vervielfacht da eine Person ewig dafür brauchen würde und wenn 10 Leute daran arbeiten, gibts auch 10 menschliche Fehlerquellen. Schon eine einzige reicht um das ganze Programm zu beeinflussen.
DOS habe ich auch in guter Erinnerung, was wie gesagt an der Tatsache liegt, das Anwendungen damals noch überschaubar waren und nur über wenige funktionen verfügten (gibts sowas wie adobe photoshop mit allen funktionen auch unter dos?)
Textprogramme vom C64 kenne ich auch noch, die haben vielleicht eine Speicher-Druck-Bearbeiten funktion gehabt, das war aber auch schon alles. ;)
Exxtreme
2009-01-04, 21:24:51
Ist alles eine Kostenfrage. Wenn es schön billig sein soll und mit vielen Features dann wird halt woanders gespart. Sieht man an Computerspielen bzw. allgemein Endanwender-Software. Kauft man sich hingegen einen SQL-Server für paar Tausend Euro dann wird man kaum Probleme haben. Denn das Ding wird richtig getestet.
Monger
2009-01-04, 21:36:20
Kauft man sich hingegen einen SQL-Server für paar Tausend Euro dann wird man kaum Probleme haben. Denn das Ding wird richtig getestet.
Man kann mit Tests nicht alles eschlagen. Ich sitze ja nunmal selber im Systemtest, und man KANN unmöglich eine fehlerfreie Qualität garantieren. Wenn das Konzept an sich schon verseucht ist, reißt der Systemtest auch nichts mehr.
Dass Produkte wie ein SQL Server so ausgereift sind, liegt imho eher daran dass sie schon in der x-ten Generation existieren. Es hat zuvor jede Menge grottenschlechter SQL Server gegeben, aber wenn man 15 Jahre lang alte Projekte einstampft, neue wieder mit einem entschlackten Konzept aufbaut und danach wieder einstampft, bekommt man halt irgendwann tatsächlich ein Produkt was so funktioniert wie es soll. Da haben aber bereits viele Generationen an unfreiwilligen Beta Testern den Kopf in die Tastatur geschlagen.
Das funktioniert aber eben nur für Produkte, wo man aus vielen Jahren Erfahrung am Markt schöpfen kann. Viele Software wie eben Spielesoftware betritt aber eben regelmäßig völliges Neuland.
Dass Software für den industriellen Gebrauch aufgrund der hohen Lizenzkosten qualitativ besser ist, wage ich mal zu bezweifeln. Im Gegenteil: gerade weil man nur eine Hand voll Kunden hat, und die sich in aller Regel nur dafür interessieren wann diese Software rauskommt damit sie endlich ihre Produktivität steigern können, bleibt die Qualität eher auf der Strecke.
Dass Software für den industriellen Gebrauch aufgrund der hohen Lizenzkosten qualitativ besser ist, wage ich mal zu bezweifeln.
genau, wenn ich da an den Lotus-Notes und den SAP Rotz bei uns in der Firma denke...
Ist alles eine Kostenfrage. Wenn es schön billig sein soll und mit vielen Features dann wird halt woanders gespart. Sieht man an Computerspielen bzw. allgemein Endanwender-Software. Kauft man sich hingegen einen SQL-Server für paar Tausend Euro dann wird man kaum Probleme haben. Denn das Ding wird richtig getestet.
Du hast ja keine Ahnung...
Es gibt so viel teure Schrottsoftware.
Ganon
2009-01-04, 22:17:31
Man kann mit Tests nicht alles eschlagen. Ich sitze ja nunmal selber im Systemtest, und man KANN unmöglich eine fehlerfreie Qualität garantieren.
Wir haben einen Kunden, der von uns mal vertraglich garantierte Fehlerfreiheit forderte. :ugly: Naja, wir haben ihn ausgelacht, gekauft hat er trotzdem... :D
=Floi=
2009-01-05, 14:20:57
zitat
Du hast ja keine Ahnung...
warum kannst du das denn nicht ein wenig genauer ausführen und auch beispiele von bekannter software und bugs nennen?! :rolleyes: Das kling so dermaßen arrogant und als mod solltest du auch mal ein wenig feinfühliger und normaler reagieren.
Monger
2009-01-05, 14:48:01
Das kling so dermaßen arrogant und als mod solltest du auch mal ein wenig feinfühliger und normaler reagieren.
Coda ist kein Mod, sondern Crew Mitglied. Er bekommt da keine Extrawürste.
warum kannst du das denn nicht ein wenig genauer ausführen und auch beispiele von bekannter software und bugs nennen?! :rolleyes:
Bekannte Industriesoftware ist ein Widerspruch in sich. Ich könnte dir aus meinem Bereich so einige Produkte nennen die räudige Qualität haben - nur außerhalb der Automatisierungsbranche kennt die kein Schwein.
Aber ein prominentes Beispiel ist SAP/R3. Selbst wenn es funktioniert, ist es so höllisch kompliziert (das einzige Programm in dem ich Unter-unter-unter-unter-unter Menüs gesehen habe...), dass kaum jemand damit umgehen kann. R3 ist ja modular aufgebaut, und wird an jeden Kunden wieder individuell angepasst. Und bei jedem Kunden kracht es dann auch wieder entsprechend.
Demirug
2009-01-05, 15:06:16
Bekannte Industriesoftware ist ein Widerspruch in sich. Ich könnte dir aus meinem Bereich so einige Produkte nennen die räudige Qualität haben - nur außerhalb der Automatisierungsbranche kennt die kein Schwein.
WinCC *scnr*
Der Preis ist nicht höher weil die Quality besser wäre sondern weil der Kundenkreis einfach viel viel kleiner ist. Von machen Produkten verkaufts du weltweit vielleicht gerade mal ein paar hunter Lizenzen.
Quaker
2009-01-05, 15:14:34
Ist alles eine Kostenfrage. Wenn es schön billig sein soll und mit vielen Features dann wird halt woanders gespart. Sieht man an Computerspielen bzw. allgemein Endanwender-Software. Kauft man sich hingegen einen SQL-Server für paar Tausend Euro dann wird man kaum Probleme haben. Denn das Ding wird richtig getestet.
Öhm, nicht wirklich.
Wer sich schonmal intensiver mit SQL2005 Server auseinandergesetzt hat...
Sogar nach SP2 lief es nicht richtig, danach musste man noch x Posthotfixes installieren...
Also ich hatte eher das Gefühl dass da gar nix getestet wurde.
Von MOSS07 reden wir lieber schon gar nicht...
Zahlen von Bugs interessieren niemanden.
Unter DOS konnte ich alle meine gekauften Games ohne Probleme durchspielen - Heute ist das ohne Patch kaum mehr möglich - das ist der Punkt!
Ausser das Game stammt aus der Feder von ID-Software. ;)
jorge42
2009-01-05, 15:40:01
Der Preis ist nicht höher weil die Quality besser wäre sondern weil der Kundenkreis einfach viel viel kleiner ist. Von machen Produkten verkaufts du weltweit vielleicht gerade mal ein paar hunter Lizenzen.
wenns nach Preis gehen würde, müssten Produkte von Citrix und VMware perfekt sein. Aber was gerade Citrix in letzter Zeit verzapft hat: Aus einigermaßen stabilen Servern werden per Patch Bluescreens produzierende Maschinen :(
Monger
2009-01-05, 16:34:22
WinCC *scnr*
*Hust*, zum Beispiel.
Darauf gehe ich jetzt besser nicht näher ein! ;)
Aber ein prominentes Beispiel ist SAP/R3. Selbst wenn es funktioniert, ist es so höllisch kompliziert (das einzige Programm in dem ich Unter-unter-unter-unter-unter Menüs gesehen habe...)
nun, sagen wir es mal so, wäre die Usability in jedem Modul, in jedem Menu einheitlich, dann wäre es nicht ganz so schlimm ;)
aber das ist so mit der Hauptmurks beim Benutzen von SAP, die grottenuneinheitliche Usability.
ich habe mich mittlerweile ja daran gewöhnt, dass wenn man in ein Modul hineingeht - nichts, aber auch gar nichts macht - und sofort wieder hinausgeht, in 99% der Fälle die Meldung kommt, dass nicht gespeicherte Änderungen verloren gehen :crazy: Hallo ??!?!? Ich HABE NICHTS GEÄNDERT !!! :crazy:
aber nun kommts, nach über 2 Jahren SAP hab ich in einem Modul was entdeckt!
Man geht rein!
ÄNDERT NICHTS!
und klickt
auf Speichern !!!
dann
kommt die Meldung !
dass NICHTS GEÄNDERT WURDE und deswegen NICHT GESPEICHERT WIRD !!!
aaaaaaaaaaaaaaaaaaaaaahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
:crazy: :crazy: :crazy: :crazy:
Shakti
2009-01-10, 13:07:55
Beim Versuch, den Herrn zu ignorieren, kommt aber leider folgende Meldung:
Entschuldigung, aber Coda ist ein Moderator oder Administrator und es ist nicht erlaubt, diese zu ignorieren.
Wat dann nu?
joe kongo
2009-01-12, 11:55:44
Seit es Updatemöglichkeiten online gibt und der Endkunde für den Betatest herangezogen wird, wird auf Qualitätskontrolle zu Gunsten des Gewinns verzichtet, so meine Vermutung.
Noch ärger treiben es manche Unternehmen wie zB Pinnacle die Fehler nur zum Teil beseitigen, und den Rest erst mit der nächsten kaufpflichtigen Version (wenn man Glück hat).
Früher gab es Software nur von Datenträgern, da waren schwere Fehler fatal
und Updates sehr teuer.
catamaran
2009-01-12, 13:55:28
Oft sind des aber auch Anpassungen die geradezu Fehler heraufbeschwören. Feature A muss unbedingt realisiert werden, am besten bis gestern und möglichst wenig kosten. Da dieses Feature sich überhaupt nicht so einfach in den bestehenden Code in absehbarer Zeit integrieren lässt wird es unter Zuhilfenahme von reichlich Koffein an mehreren Arbeitstagen bis in die späten Abendstunden "reingefrickelt" und das bleibt auch so drin bis zum Sanktnimmerleinstag.
Das ist leider keine Seltenheit und solange alles läuft interessiert es niemanden.
;D
Zum dritten: ich lehne mich mal weit aus dem Fenster, und sage: aus Sicht des Entwicklers ist ein ordentlicher Crash besser als wenn das Programm weiterläuft und in irgendeinen undeterminierten Zustand hinein läuft, wo vielleicht sogar die Datenhaltung korrumpiert werden kann. Eine Folge von gutem Exception Handling ist dann eben auch, dass sich z.B. ein Word lieber selbst abschießt, bevor es dem Anwender die Chance lässt ein korruptes Word Dokument zu speichern.
Microsoft hat AFAIK die designrichtlinie dass jeder bug der auftritt und der nicht expliziert abgefangen und behandelt wird zu einem crash führen muss um das programm nicht in einen undefinierten zustand kommen zu lassen.
es gibt aber auch den anderen designgedanken der meint ich fange generell alles ab und weise den anwernder darauf hin.
naja zum krönenden abschluss gibts die idee einfach alles abzufangen und es nochmal zu versuchen. solang bis vl. klappt oder sowieso jede hoffnung verloren ist gg
catamaran
2009-01-12, 16:27:41
Microsoft hat AFAIK die designrichtlinie dass jeder bug der auftritt und der nicht expliziert abgefangen und behandelt wird zu einem crash führen muss um das programm nicht in einen undefinierten zustand kommen zu lassen.
Das funktioniert aber nicht immer, denn es gibt ja auch noch den falsch-definierten Zustand. Definiert, aber in der Situation unerwünscht.
hm? wenn ich nen definierten zustand habe aber der unerwünscht ist klingt das für mich für nen bug der abgefangen wurde. und darüber ist der programmierer glücklich, ergo es funktioniert
catamaran
2009-01-12, 22:41:08
Schon die Definition könnte die falsche sein.
dann ist ja sowieso alles egal, ob fehlerbehandlung oder nicht.
Rache Klos
2009-01-14, 12:00:53
Eine Fehlerfreie Software mit den heutigen Werkzeugen zu programmieren ist quasi unmöglich, umso größer das Projekt umso wahrscheinlicher wird es nun mal dass ein Fehler passiert. Bei einem Spiel z.b. ist nicht nur ein Entwickler tätig, sondern viele, mehrere sitzen event. an der Grafikengine, andere bauen z.b. bauen die Levels, Storys usw. und das muss dann am Ende alles zusammen passen. Nehmen wir mal ein Rollenspiel mit einer riesigen Spielwelt, da kann ich mal da lang laufen, mal hier lang laufen, event. in unterschiedlichen Reihenfolgen mit jemandem reden.
Nun ist das Spiel quasi fertig und durchläuft eine QS, daher irgendwelche anderen Leute abgesehen von den Entwicklern selbst die natürlich auch immer ihre Codeabschnitte testen, testen das Game. Nun spielen die vielleicht mit 30 Leuten 120 Stunden am Stück was schon alleine nur für Test 2 Wochen in Anspruch nimmt. Jetzt finden die Fehler und die werden an die Entwicklung gegeben, behoben und die Tester guggen ob es jetzt richtig geht. Wie lange soll denn getestet werden? 2 Wochen, 10 Wochen, 6 Monate? Aus Erfahrung weis ich, dass man sich Tod testen kann und irgendwann an einem Punkt angelangt ist, wo man einfach sagt jetzt oder nie. Denn irgendwann findet man einfach keine Fehler mehr, bzw. nur noch mit einem signifikanten hohen Aufwand der dann darin resultieren würde tatsächlich 6 Monate zu testen.
Man glaubt also die Software ist so ok und gibt die raus, dann plötzlich spielen statt 30 Leuten 10000, die 10000 haben natürlich andere Rechnerkonfigurationen wie man im Labor nachstellen konnte. Die 10000 laufen vielleicht auch ganz andere Richtungen in der Spielwelt, etwas was man im Labor so nicht hätte nachstellen können. Schwups kommt ein Storrybug, weil jemand 40 km zu Fuß durch die Spielwelt gelaufen ist und mit jemand gesprochen hat, woran im Labor niemand gedacht hat dass das jemand macht.
Natürlich gibt es Entwicklungstudios die geben bewusst total verbuggte Games raus, das liegt dann halt meist daran dass soviel Geld in die Entwicklung geflossen ist, dass schlicht und ergreifend schnell wieder Geld gemolken werden muss um überhaupt weiter zu programmieren (Patches). Da Spiele und auch andere Software halt immer Komplexer werden (die Kunden wollen es ja auch nicht anderes), wird das Budget auch immer größer um ein Toptitel zu programmieren. Daher wird das Geld auch immer knapper, da die Firmen auf Pump etwas bauen ohne zu wissen ob es wirklich den erhofften erfolg bringt. Irgendwann ist der Punkt erreicht, wo das Game raus muss da die Firma sonst einfach vor riesigen Geldproblemen steht.
Acrylsäure
2009-01-14, 12:06:48
Bekannte Industriesoftware ist ein Widerspruch in sich. Ich könnte dir aus meinem Bereich so einige Produkte nennen die räudige Qualität haben - nur außerhalb der Automatisierungsbranche kennt die kein Schwein.
OH JA!
Arbeite selbst in der Branche, sogar bei militärischen Anwendungen ist die Qualität erstmal eher pfui als hui. Auch da reift das Produkt beim Anwender o.O
Wenn das alles so stimmt, dann ist da ja ein guter Markt für Qualitätsanwendungen vorhanden. Wieso füllt den keiner? Zu teuer? Für hohe Qualität kann man auch mehr verlangen/ weniger für Support ausgeben...
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.