Praxisumfrage - SW Controlling
-
Hallo Communitionen!
Wer betreubt von euch in kommerziellen Projekten SW Controlling?
http://www4.informatik.tu-muenchen.de/~beneken/awks/slides/weigend.pdfcu
P84
-
Softwarequalität kann man meiner Meinung nach nicht messen.
-
P84@work schrieb:
http://www4.informatik.tu-muenchen.de/~beneken/awks/slides/weigend.pdf
Witzig, ich hab in meiner TUM Zeit sowohl Vorlesungen von Beneken als auch Weigend gehört.
Da ich noch nicht arbeite, kann ich aber zu der Frage nix sagen;)
-
Bashar schrieb:
Softwarequalität kann man meiner Meinung nach nicht messen.
Weshalb beschäftigen sich die Softwaretechniker dann seit geraumer Zeit mit dem Thema Qualitätsmanagement spez. Qualitätssicherung? Falls du mit deiner Aussage eine "allgemeine" Maßzahl für die Qualität eines Stücks Software unabhängig von Projekt und Kunde meinst, halte ich das auch nicht für "realistisch", was jedoch getan wird bzw. getan werden sollte ist projekt- und kundenabhängig Qualitätsziele der zu entwickelnden Software zu definieren (spezielle Produktleistungen oder nach dem "Empfinden" des Kunden) und schon kannst du Qualität "messen" da m.E.n eine Vergleichsbasis geschaffen wurde.
-
TheTester schrieb:
Weshalb beschäftigen sich die Softwaretechniker dann seit geraumer Zeit mit dem Thema Qualitätsmanagement spez. Qualitätssicherung?
Weil die Qualität von Software oft zu wünschen übrig lässt. Ich wüsste nicht, was das mit meiner Äußerung zu tun haben soll.
Falls du mit deiner Aussage eine "allgemeine" Maßzahl für die Qualität eines Stücks Software unabhängig von Projekt und Kunde meinst, halte ich das auch nicht für "realistisch", was jedoch getan wird bzw. getan werden sollte ist projekt- und kundenabhängig Qualitätsziele der zu entwickelnden Software zu definieren (spezielle Produktleistungen oder nach dem "Empfinden" des Kunden) und schon kannst du Qualität "messen" da m.E.n eine Vergleichsbasis geschaffen wurde.
Die Zahlen können prinzipiell nicht objektiver werden, wenn man sie noch mit dem Empfinden des Kunden verrechnet. Wenn man natürlich irgendwas definiert, kann man daran auch die "Qualität" festmachen. Die Frage ist nur, ob das, was man da misst, wirklich die Qualität ist.
-
Bashar schrieb:
TheTester schrieb:
Weshalb beschäftigen sich die Softwaretechniker dann seit geraumer Zeit mit dem Thema Qualitätsmanagement spez. Qualitätssicherung?
Weil die Qualität von Software oft zu wünschen übrig lässt. Ich wüsste nicht, was das mit meiner Äußerung zu tun haben soll.
Das ohne Definition von Qualität oder Methoden zur Messbarmachung dieser, es diese Richtung wohl nicht geben würde die sich gerade damit auseinandersetzt um wie du schon implizt annimmst die Qualität zu verbessern.
Falls du mit deiner Aussage eine "allgemeine" Maßzahl für die Qualität eines Stücks Software unabhängig von Projekt und Kunde meinst, halte ich das auch nicht für "realistisch", was jedoch getan wird bzw. getan werden sollte ist projekt- und kundenabhängig Qualitätsziele der zu entwickelnden Software zu definieren (spezielle Produktleistungen oder nach dem "Empfinden" des Kunden) und schon kannst du Qualität "messen" da m.E.n eine Vergleichsbasis geschaffen wurde.
Die Zahlen können prinzipiell nicht objektiver werden, wenn man sie noch mit dem Empfinden des Kunden verrechnet. Wenn man natürlich irgendwas definiert, kann man daran auch die "Qualität" festmachen. Die Frage ist nur, ob das, was man da misst, wirklich die Qualität ist.[/quote]
Nehmen wir mal die Definition von Qualität aus der ISO:9000 "Qualität ist der Grad, in dem ein Satz inhärenter Merkmale Anforderungen erfüllt". Qualität ergibt sich demnach aus einer Menge von Produkteigenschaften in verschiedenen Ausprägungen und Abstufungen, was wohl auch der allgemeinen Auffassung zu dem Wort "Qualität" entspricht. Wenn jetzt jmd einen Satz von Merkmalen + Ausprägungen vorgibt den es zu erreichen gilt und man den erreicht dann wird er das Produkt als "gut" oder "qualitativ hochwertig" auffassen und wenn ich nun über Methoden verfüge diese Abweichung (zwischen dem was es zu erreichen gilt und was ich habe) zu quantifizieren messe ich die Qualität.
Wenn deine Definition von Qualität natürlich eine ganz andere ist dann reden wir aneinander vorbei.
-
Bashar schrieb:
Die Zahlen können prinzipiell nicht objektiver werden, wenn man sie noch mit dem Empfinden des Kunden verrechnet. Wenn man natürlich irgendwas definiert, kann man daran auch die "Qualität" festmachen. Die Frage ist nur, ob das, was man da misst, wirklich die Qualität ist.
Das ist ja eine sehr schöne philosophische Fragestellung, aber mir ist die Begründung "weil man nicht objektiv messen kann, misst man lieber gar nicht" zu dünn.
Qualität ist sowieso ein subjektives Merkmal. Der Benchmark ist eine gewisse Erwartungshaltung, die von den Nutzern/Kunden relativ willkürlich geprägt ist.
Die Abweichung eines Systems von diesen Erwartungen zu erfassen und diese Abweichung zu quantifizieren, ist meiner Meinung nach schon mal ein guter Weg zur Steuerung. Denn ohne Messung - wie das Dokument ja schon schreibt - auf jeden Fall auch keine Steuerung und Kontrolle.
Wir führen z.B. in der Planungsphase für das IT-System eine FMEA durch, wo wir Fehlerabhängigkeiten und Einflüsse durch Abhängigkeiten festlegen:
9 - Produktionsausfall oder Produktzerstörung, 3 - Datenverlust zu Produktionsdaten, 1 - Benutzerbeeinträchtigung, lokal behebbare Störung, 0 - kein Einfluß
und leiten daraus die Testpläne ab, was im fertigen System zu testen ist. Diese Fehlerfestlegung und die Abhängigkeit ist nicht wirklich exakt, sie basiert auf groben Festlegungen.Betrachtet man aber das Endergebnis, so sieht man sehr gut, wo Fehlerschwerpunkte, Testschwerpunkte und auch Änderungen notwendig sind.
Und wir erhöhen die Qualität durch Verminderung von Fehlerquellen.
-
TheTester schrieb:
Bashar schrieb:
TheTester schrieb:
Weshalb beschäftigen sich die Softwaretechniker dann seit geraumer Zeit mit dem Thema Qualitätsmanagement spez. Qualitätssicherung?
Weil die Qualität von Software oft zu wünschen übrig lässt. Ich wüsste nicht, was das mit meiner Äußerung zu tun haben soll.
Das ohne Definition von Qualität oder Methoden zur Messbarmachung dieser, es diese Richtung wohl nicht geben würde die sich gerade damit auseinandersetzt um wie du schon implizt annimmst die Qualität zu verbessern.
Um auf die Idee zu kommen, Qualitätssicherung und Qualitätsmanagement einzuführen, braucht man nur die Erfahrung minderer Qualität, keine Messbarkeit.
Nehmen wir mal die Definition von Qualität aus der ISO:9000 "Qualität ist der Grad, in dem ein Satz inhärenter Merkmale Anforderungen erfüllt". Qualität ergibt sich demnach aus einer Menge von Produkteigenschaften in verschiedenen Ausprägungen und Abstufungen, was wohl auch der allgemeinen Auffassung zu dem Wort "Qualität" entspricht. Wenn jetzt jmd einen Satz von Merkmalen + Ausprägungen vorgibt den es zu erreichen gilt und man den erreicht dann wird er das Produkt als "gut" oder "qualitativ hochwertig" auffassen und wenn ich nun über Methoden verfüge diese Abweichung (zwischen dem was es zu erreichen gilt und was ich habe) zu quantifizieren messe ich die Qualität.
Der Haken dabei ist, dass die Vorgabe dieser Qualitätsziele sich nicht mit der impliziten Erwartungshaltung deckt. Du misst also irgendwelche Hausnummern. Und ganz wichtig: Du kannst die "Qualität" verschlechtern oder verbessern, indem du mehr oder weniger angestrengt darüber nachdenkst, welche impliziten Anforderungen du explizit machst.
Wenn deine Definition von Qualität natürlich eine ganz andere ist dann reden wir aneinander vorbei.
Etwas hat aus meiner Sicht Qualität, wenn ich es als gut bewerte. Dass das nicht mit der Qualitätsdefinition von QM-Leuten zusammenpasst, ist mir bewußt
Marc++us schrieb:
Das ist ja eine sehr schöne philosophische Fragestellung, aber mir ist die Begründung "weil man nicht objektiv messen kann, misst man lieber gar nicht" zu dünn.
Messen kann man gerne was man will. Man sollte sich nur nicht der Illusion hingeben, dass das die Qualität ist. Ich sollte vielleicht lieber gar nicht davon anfangen, dass Korrektheit (also die Abwesenheit von Fehlern) eigentlich die Grundvoraussetzung ist, um sich über Qualität überhaupt Gedanken machen zu können. Solange man Qualität umgekehrt proportional zu den Fehlern definieren kann ist die Messung natürlich trivial. Zur Qualität gehören aber auch Dinge wie Performance oder Wartbarkeit. Sie wird IMHO in der Praxis dadurch messbar gemacht, dass man Faktoren, die einem nicht in den Kram passen, wegdefiniert.
-
Bashar schrieb:
twas hat aus meiner Sicht Qualität, wenn ich es als gut bewerte. Dass das nicht mit der Qualitätsdefinition von QM-Leuten zusammenpasst, ist mir bewußt
Ehrlich gesagt finde ich, daß Deine Definition genau die übliche Definition ist. Und auch die, der die QM-Leute folgen: sie schauen sich an, was man speziell braucht um als "gut" eingestuft zu werden, und dann definieren sie das als Qualität.
-
Bashar schrieb:
Ich sollte vielleicht lieber gar nicht davon anfangen, dass Korrektheit (also die Abwesenheit von Fehlern) eigentlich die Grundvoraussetzung ist, um sich über Qualität überhaupt Gedanken machen zu können.
Die Korrektheit nützt einem aber nichts. Sie ist für die Masse der praktischen Anwendungen völlig unbrauchbar, schon alleine deswegen, weil man für die Prüfung von Korrektheit eine korrekte Spezifikation benötigt. Bereits die Erstellung dieser ist oftmals gar nicht möglich.
Wenn man eine Fabrik betrachtet mit 300 vernetzten Rechnern, da sind 100000 Fehler drin. Und trotzdem läuft die Fab problemlos, solange man nur eine handvoll kritischer Fehler ausmerzt. So ein System läuft prima auch mit 99000 Fehlern, ist gar kein Problem.
Ein Softwarequalitätssystem soll einem aber helfen, diese kritischen Fehler zu erkennen (am besten frühzeitig, also während der Planung), spätestens in der Testphase. Im Extremfall sogar erst während des Betriebs, besser spät als nie.
Niemand würde auf die Idee kommen zu versuchen, die Korrektheit dieses Systems prüfen zu wollen, da man sonst die Kosten in Raumfahrtniveau katapultiert. Aber die Qualität dieses Systems kann man sehr gut mit Meßlatten unterlagen. Diese sind natürlich willkürlich gelegt, je nach Anforderung. Aber man kann durchaus Aussagen zu Wartbarkeit, Uptime oder Performance der Einzelsysteme treffen und diese dagegen benchmarken. Und damit die Qualität der Einzelsysteme prüfen.
-
TheTester schrieb:
Bashar schrieb:
Softwarequalität kann man meiner Meinung nach nicht messen.
Weshalb beschäftigen sich die Softwaretechniker dann seit geraumer Zeit mit dem Thema Qualitätsmanagement spez. Qualitätssicherung? ...
Naja, genausogut könnte man sagen: Wieso gibt es so viele "Zukunfts-Kartenleger" ?
Ist das schon ein Beleg dafür, dass das geht ?Dass es "Qualitätsmanagement" als Beschäftigungsgebiet gibt, entspringt erstmal nur dem Wunsch nach besserer Software. Aber dass man sich bessere Software wünscht, bedeutet noch längst nicht, dass
a) einfach (oder gar global) zu definieren sei, was "bessere Software" ist oder
b) Verbesserungen überhaupt ...
c) ... oder mit den eingesetzten Methoden erreicht werden kann.
Gruß,
Simon2.
P.S.: Ich denke schon, dass QM/QS in der Softwareentwicklung durchaus ihre Möglichkeiten haben (wenn ich auch Vieles der derzeitigen "Ergebnisse" für Augenwischerei/Halbherzigkeiten und "Modegewäsch" halte).
Es ging mir nur darum, das o.g. Argument für ...."ausbaubedürftig"...;)
-
Bashar schrieb:
Um auf die Idee zu kommen, Qualitätssicherung und Qualitätsmanagement einzuführen, braucht man nur die Erfahrung minderer Qualität, keine Messbarkeit.
Aber für die Funktion von QS und QM ist die Meßbarkeit unabdingbar, da man sonst keinen Regelkreis erstellen kann, und da man sonst auch Fortschritte/Erfolge nicht feststellen kann.
Selbst weitgehend willkürliche Meßverfahren helfen bereits, da man durch die Messung feststellen kann, ob man sich nach Veränderungen überhaupt bewegt hat.
[Idealerweise sind die Meßkriterien natürlich einigermaßen disjunkt und stellen sowas wie einen "Spannbaum aller Projektthemen" dar, aber das ist nicht so einfach zu machen.]
-
Hallo Communitonen!
Aufwendungen für Qualitätssichernde Massnahmen:
- SW System Engineering 63% !!!
- SW Entwicklung 31%
- HW System Engineering 73% (ohne Material)
- HW Entwicklung 73% (Löten, Dichtungen, Hitze, Crappen, Materialprüfung, Dichte, Messungen etc.)
- Gesamt System Engineering 46%
(Elektromagnetische Verträglichkeit, Radiation, Erschütterungen, Korrosion (Altering), Struktur-Thermal-Analyse, Signaldämpfung, Masse, Stom, Micro-Gravitation, Ausmaße etc.)
- Betriebliche QA 5% der MA.Ich habe eine andere Vorstellung von Qualität:
Qualität bestimmt die Reife eines Konzeptes gegenüber von beurteilenden Konzepten. - Also eine Aussage ist ohne Tests und Ergebnisse nicht möglich.
Sind die beurteilenden Konzepte standardisiert, ist eine Aussage und Zertifizierung über Qualität durchaus möglich. Je weiter fortgeschritten die Reife der beurteilenden Konzepte sind - bestimmt aus der Reife anderer Konzepte zu dessen Beurteilung (Wahrnehmungskonzepte) - desto mehr wird es von der breiten Masse mit einer guten Qualität versehen.Aber Vorsicht!!!
Ein für einen bestimmten Anwendungszweck extrem gutes Produkt wird von der breiten Masse immer als schlecht klassifiziert werden, weil diese gar nicht die Wahrnehmungskonzepte besitzt, um es als extem gut zu realisieren.Goldene Regel: Konformität fociert Durchschnittlichkeit!!!
cu
P84
-
Marc++us schrieb:
Aber für die Funktion von QS und QM ist die Meßbarkeit unabdingbar, da man sonst keinen Regelkreis erstellen kann, und da man sonst auch Fortschritte/Erfolge nicht feststellen kann.
Selbst weitgehend willkürliche Meßverfahren helfen bereits, da man durch die Messung feststellen kann, ob man sich nach Veränderungen überhaupt bewegt hat.
So verschieden scheinen unsere Standpunkte ja gar nicht zu sein.
Solche Messungen haben aber auch Kosten. Einerseits natürlich für die Erhebung selbst, dann aber auch wegen der Einschränkungen, die die Entwickler hinnehmen müssen. Wenn man nicht aufpasst sind die brillantesten Köpfe schnell weg, andere machen nur noch Dienst nach Vorschrift. Dann hat man endlich gleichbleibende, vorhersagbare "Qualität".
-
Das ist aber meines Erachtens ein anderes Problem. Ich halte Q-Maßnahmen, die nur als Last empfunden werden (z.B. weil irgendwelche Namensregeln oder Vorschriften wie man Schleifen baut) nicht als Maßnahme zweckdienlich.
Entwickler sind Q-Maßnahmen ja nicht abgeneigt, wenn sie dafür irgendwelche lästigen Dinge von ihnen abhalten - z.B. irgendwelche LOPs zu bearbeiten, trockene Tests, etc. Leider werden Q-Maßnahmen oft so begriffen, daß man über pauschale Regeln irgendwo im Code Leute mit Tests oder Testfällen oder Vorschriften quält. Und das widerspricht natürlich dem Naturell von Softwareentwicklern, die immer ein bißchen eine Mischung aus Spinner und Künstler mitbringen. Stumpf Regeln abhaken ist nicht auf der Agenda, und wird nicht wirklich verinnerlicht.
Daher müssen Maßnahmen zur Qualitätssicherung wohl auch Vorteile für die Entwickler bringen, und die Vorteile müssen unmittelbar aus den Untersuchungen erkennbar sein. Zum Beispiel könnte der Entwickler ein frühes Feedback aus einer Qualitätsmaßnahme bekommen, so daß er schneller weiß, ob sein Modul funktioniert.