Qualitätsanforderungen Software - Was zählt?

R

R0x

Guest
Hi,
ich schreibe gerade für eine generelle Studienarbeit einige Punkte zusammen, welche Qualität guter Software auszeichnet.
Punkte wie, z.B. Namenskonventionen, Nutzung von Fremdschlüsseln & Co.

Mich würde eure Meinung interessieren.Was ist für euch wichtig, wenn euch jemand Software entwickeln soll? Gängige Punkte wie eine saubere Doku innerhalb des Codes ist denke ich normal.

Also erzählt mal, woran müsste sich euer Entwickler zwingend halten bzw. was beachten?
 
- dokumentierter Code
- Flussablaufdiagramme für alle Prozesse
- Datenbankdiagramm
- Dokumentation der Schnittstellen zu anderen Programmen / DBs

Ausserdem Einhaltung der vereinbarten UserInterface-Standarts.

Wobei es bei uns etwas einfacher ist.
Wir haben InHouse-Programmierer, bei denen ich vorbei gehen und ihnen auf xxx xxxxxx xxxxxxxx xxxx xxxx wenn etwas nicht so ist wie es sein sollte.
Dummerweise machen die Enduser, die auch hier sitzen, das Gleiche mit mir als Projekt-Betreuer.
wink.gif


 
Das ist von vielen Faktoren abhängig. Es macht einen Unterschied, ob ich für mich zu Hause eine kleine Klasse entwickle oder ob ich im Unternehmen eine komplexe Anwendung für einen Großkonzern entwickle, der darüberhinaus besondere Anforderungen (GxP, Ausfallsicherheit, Ressourcen...) hat. Hier spielt dann auch der Entwicklungs- und Changeprozess eine Rolle. Wer genehmigt was und braucht dafür welche Unterlagen?

Willst du deine Fragestellung nicht lieber etwas eingrenzen? Von den ersten Spezifikationen bis hin zum Abnahmebericht gibt es sehr viel zum Thema Softwarequalität zu sagen. Und mit CMMI will ich da erst gar nicht anfangen... ;-)

@TSc: Das ist meistens auch die beste qualitätssichernde Maßnahme. ;-)
 
QUOTE Es bezieht sich ausschließlich auf die Produktqualität und nicht die Prozessqualität.
Quelle: Der Artikel oben...

Einer der vielen vielen Aspekte... bei den Prozessen wird es erst richtig spannend. Denn ohne den richtigen Prozess bekommt man keines der oben aufgeführten Kriterien richtig hin.
 
In Kurzfassung: Qualität hat die Software dann, wenn sie die Anforderungen erfüllt. In dem SInne kann sogar komplette Schrottsoftware voller Fehler und ohne Dokumentation Qualität haben - solange sie die Anforderungen erfüllt.

Qualitätssicherung ist dann noch einmal ein ganz anderes Thema. Darauf zielst Du vielleicht auch eher ab, wenn es dann um "Best Practices" usw. geht. Aber auch hier: was in einem Fall absolut notwendig ist, kann in einem anderen Fall absolut kontraproduktiv sein. Es hängt auch hier von den Anforderungen des Projekts und der Firma usw. ab.

Wenn Du eine Studienarbeit schreibst, solltest Du Dich auch mit den beiden Begriffen auseinandersetzen.
 
Die meisten hier genannten Punkte garantieren noch lange keine qualitative Software. Wenn ich Namenskonventionen einhalte, oder den Code dokumentiere, heisst das noch lange nicht, dass meine Software eine gute Qualität hat.

Einige Punkte aus einer Vorlesung (www.ifi.uzh.ch/rerg/courses/fs09/swq/), die ich zu dem Thema gehört habe:

Qualität im Zusammenhang mit Software (aber nicht nur dort) ist ein schwammiger Begriff und hängt massgeblich von den Zielen ab: Qualität = Zielerfüllung (Ziele = explizite oder implizite Anforderungen).

Qualität muss definiert und geschaffen werden, sie entsteht nicht von selbst. Qualität als reine Zweckeignung oder Kundenzufriedenheit greift zu kurz.



Ich habe mich auch mal im Rahmen einer Studienarbeit mit dem Thema befasst, in deren Rahmen dann zunächst eine etwas ausführlichere Betrachtung des Qualitätsbegriffes vorzunehmen war.

Pfleeger und Atlee erwähnen fünf unterschiedliche Perspektiven,
welche die Sichtweise der jeweiligen Anwender repräsentieren:
- Transzendente Sicht: Qualität kann erkannt, aber nicht definiert werden
- Benutzersicht: Qualität ist die Güte für einen bestimmten Zweck
- Produktionssicht: Qualität ist die Erfüllung der Spezifikation
- Produktsicht: Qualität ist an inhärente Produktmerkmale gebunden
- Wertbasierte Sicht: Qualität ist abhängig von der Zahlungsbereitschaft des Kunden

Es lohnt sich sicherlich auch, den industriellen Qualitätsbegriff näher zu betrachten, z.B. ISO 9000:2000. Er unterscheidet sich vom allgemeinen Sprachgebrauch dadurch, dass er sich an der Erfüllung zuvor gesetzter Ziele orientiert.

In einem zweiten Schritt wären dann konsequenterweise verschiedene Software-Qualitätsmodelle zu betrachten, z.B. von Boehm et al. (1976) von von Cavano und McCall (1978) oder auch IEEE 1061 (1993), das Qualitätsmodell von Dromey (1996) und QMOOD (2002) oder Factor-Strategy Modell (2002). Es gibt aber sicherlich noch einige mehr, die sich leicht über die IEEE- oder ACM-Suche finden lassen.


Um qualitative Software zu schaffen, sind zudem, wie bereits profo und Logge erwähnten, entsprechende Prozesse nötig. Die Massnahmen, die genannt wurden, und vieles mehr, gehören dann m.E. eher in diesen Bereich.
 
QUOTE Qualität = Zielerfüllung


Wenn die Ziele nur immer so klar wären. Ich kämpfe hier täglich mit Kunden, die nicht wirklich wissen was sie wollen. Oder noch besser sind fleißige Vertriebler, die Kunden Funktionalitäten versprechen, die bei Projektbeginn niemals als Ziel definiert waren.

Hier habe ich einen eigenen Dokumentations-, Architektur- und Kommentierstil entwickelt, der meine Arbeit nicht bedeutend aufhält, aber ich dennoch mit solchen Herkulesaufgaben und dem Zeitdruck fertig werde.
 
QUOTE (Logge @ Fr 18.12.2009, 14:27)
QUOTE Qualität = Zielerfüllung


Wenn die Ziele nur immer so klar wären. Ich kämpfe hier täglich mit Kunden, die nicht wirklich wissen was sie wollen. Oder noch besser sind fleißige Vertriebler, die Kunden Funktionalitäten versprechen, die bei Projektbeginn niemals als Ziel definiert waren.

Hier habe ich einen eigenen Dokumentations-, Architektur- und Kommentierstil entwickelt, der meine Arbeit nicht bedeutend aufhält, aber ich dennoch mit solchen Herkulesaufgaben und dem Zeitdruck fertig werde.

Das sind typische Fehler bei, Entschuldigung, schlecht organisierten Firmen. Ohne formelle Zieldefinition mit den Kunden wirst Du immer bei unzufriedenen Kunden oder defizitär arbeitenden Auftragnehmern landen. Wenn die Vertriebler verkaufen, ist das gut. Aber das geht natürlich nicht, ohne formelle Änderungen an den Zieldefinitionen, ggf. mit aktualisierten Aufwandsberechnungen.
 
QUOTE (Logge @ Fr 18.12.2009, 14:27)
Wenn die Ziele nur immer so klar wären. Ich kämpfe hier täglich mit Kunden, die nicht wirklich wissen was sie wollen. Oder noch besser sind fleißige Vertriebler, die Kunden Funktionalitäten versprechen, die bei Projektbeginn niemals als Ziel definiert waren.


Die Ziele sind sicherlich nicht immer klar, aber trotzdem hängt die Qualität der Software von dem Ziel ab, welches damit erfüllt werden soll. Im Bezug auf ein Ziel kann also eine Software von hoher Qualität sein, während sie im anderen Fall von niedriger Qualität ist.




QUOTE (profo @ Fr 18.12.2009, 14:57)
Das sind typische Fehler bei, Entschuldigung, schlecht organisierten Firmen. Ohne formelle Zieldefinition mit den Kunden wirst Du immer bei unzufriedenen Kunden oder defizitär arbeitenden Auftragnehmern landen.



Dass die Kunden Ihre Ziele nicht kennen, hat nicht zwingend mit schlecht organisierten Anbietern zu tun. Oftmals kommt der Appetit bei Essen und der Kunde erkennt erst während der Entwicklung was er wirklich will. Deine Prozesse müssten so ausgelegt sein, dass sie bis zu einem gewissen Grad mit solchen Änderungswünschen umgehen können (ein Ziel von agiler Software-Entwicklung). Wo ich dir aber schon recht gebe ist, dass wenn der Kunde seine Ziele nicht formulieren kann, es Aufgabe des Anbieters ist, diese mittels den geeigneten Verfahren zu ermitteln (das geht für mich u.a. unter Organisation).
 
QUOTE (polonius @ Fr 18.12.2009, 17:58)
QUOTE (profo @ Fr 18.12.2009, 14:57)
Das sind typische Fehler bei, Entschuldigung, schlecht organisierten Firmen. Ohne formelle Zieldefinition mit den Kunden wirst Du immer bei unzufriedenen Kunden oder defizitär arbeitenden Auftragnehmern landen.


Dass die Kunden Ihre Ziele nicht kennen, hat nicht zwingend mit schlecht organisierten Anbietern zu tun. ... Wo ich dir aber schon recht gebe ist, dass wenn der Kunde seine Ziele nicht formulieren kann, es Aufgabe des Anbieters ist, diese mittels den geeigneten Verfahren zu ermitteln (das geht für mich u.a. unter Organisation).

Da muss ich Dir zum einen widersprechen, und zum anderen gleich wieder recht geben. Kunden haben in der Regel keine Ahnung von Software, das ist glaube ich ein akzeptierter Erfahrungswert. Das ist ja auch ok; auch ein Bauherr muss nicht zwingend Ahnung von allen Baudetails haben. Gerade deswegen gehört es für jedes Unternehmen, das auch nur halbwegs nach dem Stand der Technik arbeitet dazu, mit den Kunden Zielvereinbarungen zu treffen. Wer das versäumt ist einfach eine, wie gesagt Entschuldigung, schlecht organiserte Firma.

Dass sich die Anforderungen im Laufe der Zeit / des Projekts ändern, ist dann genau wie Du sagst eine Erkenntnis, mit der gute Entwickler umgehen können. Aber auch das läuft in einem formalisierten Rahmen ab. Wenn Mehraufwände entstehen, sollten die auch formal festgehalten werden.

Ich würde das ganze allerdings nicht unter den Stichpunkt Organisation packen: es ist ja keine Verwaltungsaufgabe, sondern eine Verhandlungs- und Vermittlungsaufgabe. Ein kreativer Prozess, den idealerweise Projektmanager / Projektmanagerinnen koordinieren sollten.
 
@Profo: Ich glaube schon, dass wir vom gleichen reden, aber einfach den Begriff Organisation anders auffassen.

Wie dem auch sei. Ich glaube, dass wir den Punkt dieser Diskussion wie folgt zusammenfassen können:

Die Qualität von Software kann nicht nur anhand von technischen Eigenschaften wie die Erstellung von Dokumentationen, Einhaltung von Code-Konventionen etc. festgemacht werden. Es gehört ganz sicher auch eine Beschäftigung mit dem Qualitätsbegriff an sich dazu, sowie die Beschäftigung mit den Prozessen und Vorgehensweisen, die zur Schaffung von qualitativ hochwertiger Software (was auch immer das letztendlich ist) beitragen.
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben