Die nicht von Coverity betrachtete Software. Die Angaben 0,45 bzw. 0,64 Fehler / 1000 Zeilen sind von Coverity erhoben, der Vergleichsdurchschnitt dürfte wohl das sonst so (d.h. nicht von Coverity) gemessene / geschätzte sein.
Es ist immer wieder traurig anzuschauen, wie die Presse die PR von Coverity ohne Bedenken wiedergibt. Dabei sollte eigentlich offensichtlich sein, dass diese "Studie" erhebliche Mängel aufweist:
* Coverity ist *nicht* in der Lage, die Zahl der Fehler in einer Anwendung zu messen. Was hier wiedergegeben ist, ist lediglich die Zahl der durch statische Code-Analyse erkannten potenziellen Fehler. * Die Überschneidung der "potenziellen Fehler" mit den tatsächlichen Fehlern ist anwendungsspezifisch. Teilweise haben Anwendungen eine Architektur, bei der Coverity weniger Fehler findet. * Viel wichtiger sollte allerdings sein, dass die besagten Open Source Projekte die Analysen von Coverity bereits seit Jahren auswerten - wobei PHP und PostgreSQL anscheinend tatsächlich versucht haben, die Zahl der berichteten "Fehler" zu reduzieren. Andere Projekte haben dagegen sinnvollerweise darauf verzichtet - beim "Beheben" eines Nicht-Fehlers wird man gelegentlich einen echten Fehler einbauen. Diese Projekte haben dann die wirklichen Fehler behoben, die Unmengen an False Positives aber stehen lassen - und denen wird jetzt eine schlechte Fehlerdichte bescheinigt. * Schließlich werden hier Äpfel mit Birnen verglichen. Auf der Seite von Open Source wurden Top-Projekte untersucht - diese genießen viel Aufmerksamkeit und weisen auch in der Regel eine gute Codebasis auf. Bei proprietärer Software wurde eine solche Vorauswahl anscheinend nicht getroffen. Ich will hier keineswegs Open Source schlechtreden, aber dieser Bericht taugt als Vergleich ganz bestimmt nicht.
Na, wenn du über Jahre hinweg, Warnungen von Testsuits bekommst und die flickst steht selbstverständnis dein Projekt dort gut da. Interessanter wäre es gewesen LO zu untersuchen oder verschiedene OS Kernels. So bleibt das Fazit: Bestimmte Auftragssoftware die unter Kostendruck erstellt und dann nieder angefasst wird besitzt im Schnitt mehr Fehler als große in der Öffentlichkeit bekannte Projekte, wo jede Zeile mittlerweile 3x umgeschrieben wurden ist und ein Produktionsende nicht existiert. Wenn ich diese kommerz. Tool einsetze steht auch meine Software am Ende besser da.
sehe ich ähnlich. Auch machen die Fehler im Code nur einen kleinen Faktor für gute Software aus. Dies sagt nichts über die Usability aus. Auch sagt dies nichts darüber aus ob die Software die notwendige Funktionalität für die Aufgaben erfüllt. Was nutzt auch eine tolle vom Code fehlerfreie Software, deren Logik aber komplett für die Tonne, was dann erst auffällt wenn die Software einem leicht veränderten Szenario in der Praxis ausgesetzt wird.
Nicht selten hängt es auch von ab, wer die Aufgaben umsetzen soll und für wen. Die 5 Mann Programmierbude aus der Nachbaschaft zimmert schnell mal ein Binary zusammen. Sicher nicht der beste Code, aber es läuft. Geht der gleiche Auftrag an einen der Bekannten IT-Konzerne bekommt man irgendwas hochgezüchtetes, für das es einen eigenen Server benötigt und am Ende eventuell noch ein zusätzlicher Softwarepool notwendig wird.
Von The Big Tea am Mo, 27. Februar 2012 um 17:09 #
Und einsatzfertig ist die Software dann mit x Jahren verspätet oder gar nicht. Aber das schöne dabei, es wurde Umsatz generiert. Das freut das Bruttosozialprodukt und den Wirtschaftswachstum.
Nach meiner Erfahrung ist Coverity recht gut und die Anzahl der false positive bewegt sich in unteren einstelligen Prozentbereich. Aus dem veroecfentlichtem Paper geht zudem hervor, dass die exemplarisch ausgewaehlten Projekte naehr analysiert wurden. Also wird man sich die Treffer sehr genau angeguckt haben.
Von IT-Consultant am Mo, 27. Februar 2012 um 15:24 #
Das deckt sich vollkommen mit meinen Erfahrungen als Consultant. Wenn man sich anschaut, was für Flachpfeifen in den Unternehmen Software entwickeln, dann kann man sich nur noch an den Kopf packen. Da sind Produktivitätsunterschiede um den Faktor 10 keine Seltenheit.
Einerseits ist die Lage traurig, andererseits kann man als Consultant sehr viel Geld und Anerkennung erhalten, wenn man den Unternehmen wieder auf die Beine hilft und die Projekte rettet.
Projekte werden doch Grundsätzlich mit zu wenig Zeit, welche nie zu den Anforderungen passt kalkuliert. Dazu soll der Spaß noch über irgendwelche komplexen Entwicklungsmodelle wegen ISO und ähnlichem Spaß abgewickelt werden. Um kosten zu sparen wird dann an den Resourcen (Hardware, Personal, Schulung, Tests) gespart. Schließlich darf der Entwickler sich als Flachpfeife betiteln lassen und zusammen mit den unterbezahlten Admins den Mist ausbaden, den die Consultants im angerichtet haben.
Von IT-Consultant am Mo, 27. Februar 2012 um 17:05 #
Teure externe Kräfte werden eingekauft, um die Projekte erfolgreich abzuwickeln. Wenn die internen Kräfte dies leiten könnten, dann würde bestimmt kein teurer externer Berater/Entwickler eingekauft. Das Problem sind die vielen unfähigen Angestellten, die schon seit Jahren ihren Platz wärmen, aber fachlich absolute Nieten sind.
Glaube mir, ich habe in den ganzen Jahren schon so einiges erlebt. Wo fähige Leute arbeiten, taucht man als externer natürlich viel seltener auf.
Das liegt dann aber an deiner Vorstellungskraft. Was "IT-Consultant" von sich gibt ist leider traurige Wahrheit und nicht auf die Entwicklungsabteilung beschränkt. Der Flachpfeifen-Anteil in der IT-Welt nimmt zunehmend beängstigende Ausmaße an.
Dann haben wir andere Erfahrungen gemacht. Ich habe in einer 70 Mann Bude gearbeitet. Klar gab's hier und da Zeitdruck, die Qualität hat nicht darunter gelitten. Als ich das Unternehmen verlassen hatte, wurde dort sonar eingeführt. Das würde manch Open Source Projekt auch sicher ganz gut tuen.
Das kann ich mir gut vorstellen und widerspricht sich auch nicht. Kleine bis mittelständische Unternehmen sind vom Flachpfeifen-Phänomen weit weniger betroffen. Dort ist man in der Regel auch stolz auf sein In-house-Knowledge. Ihr werdet deshalb, falls überhaupt dann nur wenig mit externen Beratern zu tun gehabt haben.
Ich denke die Erfahrung des Vorposters stammt von Firmen mit ~500 Mitarbeitern aufwärts, jedenfalls würde sich das grob mit meiner Erfahrung decken.
Von Das sagt der richtige am Di, 28. Februar 2012 um 13:13 #
Dann wechselt man die Flachpfeifen gegen ordentliche Softwareentwickler aus und holt sich nicht extra externe Leute.
Aber ich kann dir sagen woran das liegt, die Firmen sind nicht dafür Bereit gute Softwareentwickler entsprechend zu Bezahlen, deswegen nimmt man die Flachpfeifen + IT-Consultant dazu.
Die Probleme sind also Hausgemacht und ein völliges Versagen des Unternehmens.
Von Das sagt der richtige am Di, 28. Februar 2012 um 13:11 #
IT-Berater (IT-Consultants) machen noch lange keine guten Softwareentwickler http://de.wikipedia.org/wiki/IT-Berater
Selbst wenn er ein echtes Informatikstudium anstatt Wirtschaftsinformatik hinter sich, bedeutet das längst nicht, daß er in der Softwareentwicklung auch wirklich gut ist.
Warum werden Informatiker IT-Berater? Natürlich nur wegen dem Geld, wegen dem Mammon verkaufen sie sich für solche Dienste. 100 €/h und aufwärts + Bonizahlungen sind da schließlich keine Seltenheit.
Würde dich der Zustand in der Softwareentwicklung wirklich stören, dann würdest du selber Software entwickeln, also Code implementieren (Fähigkeiten natürlich vorrausgesetzt!).
freie Projekte: 0,45 Fehler pro 1000
proprietäre: 0,64 Fehler pro 1000
durchschnittlich: 1 Fehler pro 1000. Was gibt es neben frei und proprietär noch?
Die nicht von Coverity betrachtete Software.
Die Angaben 0,45 bzw. 0,64 Fehler / 1000 Zeilen sind von Coverity erhoben, der Vergleichsdurchschnitt dürfte wohl das sonst so (d.h. nicht von Coverity) gemessene / geschätzte sein.
Sind das nicht zu wenig Fehler, in der Regel wird doch von 2-3 pro 1000 ausgegangen.
Das ist Statistik, da ist je nach Blickwinkel und Parameter alles richtig.
Es ist immer wieder traurig anzuschauen, wie die Presse die PR von
Coverity ohne Bedenken wiedergibt. Dabei sollte eigentlich
offensichtlich sein, dass diese "Studie" erhebliche Mängel aufweist:
* Coverity ist *nicht* in der Lage, die Zahl der Fehler in einer
Anwendung zu messen. Was hier wiedergegeben ist, ist lediglich die
Zahl der durch statische Code-Analyse erkannten potenziellen Fehler.
* Die Überschneidung der "potenziellen Fehler" mit den tatsächlichen
Fehlern ist anwendungsspezifisch. Teilweise haben Anwendungen eine
Architektur, bei der Coverity weniger Fehler findet.
* Viel wichtiger sollte allerdings sein, dass die besagten Open
Source Projekte die Analysen von Coverity bereits seit Jahren
auswerten - wobei PHP und PostgreSQL anscheinend tatsächlich versucht
haben, die Zahl der berichteten "Fehler" zu reduzieren. Andere
Projekte haben dagegen sinnvollerweise darauf verzichtet - beim
"Beheben" eines Nicht-Fehlers wird man gelegentlich einen echten
Fehler einbauen. Diese Projekte haben dann die wirklichen Fehler
behoben, die Unmengen an False Positives aber stehen lassen - und
denen wird jetzt eine schlechte Fehlerdichte bescheinigt.
* Schließlich werden hier Äpfel mit Birnen verglichen. Auf der Seite
von Open Source wurden Top-Projekte untersucht - diese genießen viel
Aufmerksamkeit und weisen auch in der Regel eine gute Codebasis auf.
Bei proprietärer Software wurde eine solche Vorauswahl anscheinend
nicht getroffen. Ich will hier keineswegs Open Source schlechtreden,
aber dieser Bericht taugt als Vergleich ganz bestimmt nicht.
Na, wenn du über Jahre hinweg, Warnungen von Testsuits bekommst und die flickst steht selbstverständnis dein Projekt dort gut da. Interessanter wäre es gewesen LO zu untersuchen oder verschiedene OS Kernels. So bleibt das Fazit:
Bestimmte Auftragssoftware die unter Kostendruck erstellt und dann nieder angefasst wird besitzt im Schnitt mehr Fehler als große in der Öffentlichkeit bekannte Projekte, wo jede Zeile mittlerweile 3x umgeschrieben wurden ist und ein Produktionsende nicht existiert. Wenn ich diese kommerz. Tool einsetze steht auch meine Software am Ende besser da.
sehe ich ähnlich. Auch machen die Fehler im Code nur einen kleinen Faktor für gute Software aus. Dies sagt nichts über die Usability aus. Auch sagt dies nichts darüber aus ob die Software die notwendige Funktionalität für die Aufgaben erfüllt. Was nutzt auch eine tolle vom Code fehlerfreie Software, deren Logik aber komplett für die Tonne, was dann erst auffällt wenn die Software einem leicht veränderten Szenario in der Praxis ausgesetzt wird.
Nicht selten hängt es auch von ab, wer die Aufgaben umsetzen soll und für wen. Die 5 Mann Programmierbude aus der Nachbaschaft zimmert schnell mal ein Binary zusammen. Sicher nicht der beste Code, aber es läuft. Geht der gleiche Auftrag an einen der Bekannten IT-Konzerne bekommt man irgendwas hochgezüchtetes, für das es einen eigenen Server benötigt und am Ende eventuell noch ein zusätzlicher Softwarepool notwendig wird.
Und einsatzfertig ist die Software dann mit x Jahren verspätet oder gar nicht. Aber das schöne dabei, es wurde Umsatz generiert. Das freut das Bruttosozialprodukt und den Wirtschaftswachstum.
Nach meiner Erfahrung ist Coverity recht gut und die Anzahl der false positive bewegt sich in unteren einstelligen Prozentbereich. Aus dem veroecfentlichtem Paper geht zudem hervor, dass die exemplarisch ausgewaehlten Projekte naehr analysiert wurden. Also wird man sich die Treffer sehr genau angeguckt haben.
Das deckt sich vollkommen mit meinen Erfahrungen als Consultant. Wenn man sich anschaut, was für Flachpfeifen in den Unternehmen Software entwickeln, dann kann man sich nur noch an den Kopf packen. Da sind Produktivitätsunterschiede um den Faktor 10 keine Seltenheit.
Einerseits ist die Lage traurig, andererseits kann man als Consultant sehr viel Geld und Anerkennung erhalten, wenn man den Unternehmen wieder auf die Beine hilft und die Projekte rettet.
Definiere Produktivität und Flachpfeifen.
Projekte werden doch Grundsätzlich mit zu wenig Zeit, welche nie zu den Anforderungen passt kalkuliert. Dazu soll der Spaß noch über irgendwelche komplexen Entwicklungsmodelle wegen ISO und ähnlichem Spaß abgewickelt werden. Um kosten zu sparen wird dann an den Resourcen (Hardware, Personal, Schulung, Tests) gespart. Schließlich darf der Entwickler sich als Flachpfeife betiteln lassen und zusammen mit den unterbezahlten Admins den Mist ausbaden, den die Consultants im angerichtet haben.
Teure externe Kräfte werden eingekauft, um die Projekte erfolgreich abzuwickeln. Wenn die internen Kräfte dies leiten könnten, dann würde bestimmt kein teurer externer Berater/Entwickler eingekauft. Das Problem sind die vielen unfähigen Angestellten, die schon seit Jahren ihren Platz wärmen, aber fachlich absolute Nieten sind.
Glaube mir, ich habe in den ganzen Jahren schon so einiges erlebt. Wo fähige Leute arbeiten, taucht man als externer natürlich viel seltener auf.
Ich kann mir dich nur als Fensterputzer vorstellen, sorry.
Das liegt dann aber an deiner Vorstellungskraft. Was "IT-Consultant" von sich gibt ist leider traurige Wahrheit und nicht auf die Entwicklungsabteilung beschränkt. Der Flachpfeifen-Anteil in der IT-Welt nimmt zunehmend beängstigende Ausmaße an.
Dann haben wir andere Erfahrungen gemacht. Ich habe in einer 70 Mann Bude gearbeitet. Klar gab's hier und da Zeitdruck, die Qualität hat nicht darunter gelitten.
Als ich das Unternehmen verlassen hatte, wurde dort sonar eingeführt. Das würde manch Open Source Projekt auch sicher ganz gut tuen.
Das kann ich mir gut vorstellen und widerspricht sich auch nicht. Kleine bis mittelständische Unternehmen sind vom Flachpfeifen-Phänomen weit weniger betroffen. Dort ist man in der Regel auch stolz auf sein In-house-Knowledge. Ihr werdet deshalb, falls überhaupt dann nur wenig mit externen Beratern zu tun gehabt haben.
Ich denke die Erfahrung des Vorposters stammt von Firmen mit ~500 Mitarbeitern aufwärts, jedenfalls würde sich das grob mit meiner Erfahrung decken.
Der Flachpfeifen-Anteil in der IT-Welt nimmt zunehmend beängstigende Ausmaße an.
...und gilt demnach auch für die Consultant- Branche.
Aemmm, könnte es sein, dass der Typ Euch (erfolgreich) verulkt?
Mit Sicherheit tut er das, schliesslich ist er ja auch, als Jura-/BWL-Student, Experte & IT-Profi, etc. bekannt
Nö, das betrifft nur Unternehmen die nicht ordentlich bezahlen wollen und dann die Reste vom Arbeitsmarkt klauben.
Dann wechselt man die Flachpfeifen gegen ordentliche Softwareentwickler aus und holt sich nicht extra externe Leute.
Aber ich kann dir sagen woran das liegt, die Firmen sind nicht dafür Bereit gute Softwareentwickler entsprechend zu Bezahlen,
deswegen nimmt man die Flachpfeifen + IT-Consultant dazu.
Die Probleme sind also Hausgemacht und ein völliges Versagen des Unternehmens.
IT-Berater (IT-Consultants) machen noch lange keine guten Softwareentwickler
http://de.wikipedia.org/wiki/IT-Berater
Selbst wenn er ein echtes Informatikstudium anstatt Wirtschaftsinformatik hinter sich, bedeutet das längst nicht, daß er in der Softwareentwicklung auch wirklich gut ist.
Warum werden Informatiker IT-Berater?
Natürlich nur wegen dem Geld, wegen dem Mammon verkaufen sie sich für solche Dienste.
100 €/h und aufwärts + Bonizahlungen sind da schließlich keine Seltenheit.
Würde dich der Zustand in der Softwareentwicklung wirklich stören, dann würdest du selber Software entwickeln, also Code implementieren (Fähigkeiten natürlich vorrausgesetzt!).
...hinter sich hat, bedeutet ...
...nur wegen des Geldes, wegen des Mammons verkaufen...
...vorausgesetzt
Danke für die Aufmerksamkeit
BdC
Ein Vergleich mit den SQL DBMS von Oracle oder Microsoft wäre hier mal interessant gewesen.
PostgresSQL mit PHP oder dem Kernel zu vergleichen ist wenig hilfreich.