Human Computer Interaction

Transkript

1 und neue Ansätze /1

2 Ziel der Vorlesung Ziel dieser Vorlesung ist es, sich einmal mit den Formen des gesellschaftlich erzielten Konsenses zum Thema der Usability im Bereich Anwendungssoftware auseinanderzusetzen. Da gibt es zum einen ISO/EN/DIN-Normen, Gesetze der EU, der BRD und der Bundesländer. Zum anderen gibt es Normenkataloge der Firmen und Entwickler wie Style Guides oder Human Interaction/Experience/Interface Guidelines. Es gibt auch andere Ansätze /2

3 Motivation Normen aller Art sind oft scheinbar zu generalisierend oder innovationsbehindernd. Trotzdem - Normen liefern genaue Definitionen von Fachbegriffen zur Verständigung und stellen einen erzielten Konsens über aggregiertes Fachwissen z.b. zu Aspekten der Usability dar. Sie beschreiben bewährte Routinen und Prozeduren des Usability-Engineerings und der Usability- Evaluation, neben der Fachliteratur /3

4 Motivation Normen liefern Anforderungen an die Systemgestaltung und Prüfkriterien für die Usability- Evaluation. Normen sind gute Argumentationshilfen gegenüber Projektmanagern, für die Usability-Engineering mitunter nur als Kostenquelle erscheint, da der langfristige Nutzen sehr schwer in konkreter Kostenersparnis nachweisbar ist. Was ist an Materialien/Ideen aktuell verfügbar? /4

5 Grundsatz "Qualität kann nicht in Software hineingeprüft werden." - Binsenweisheit, spricht gegen Usability-Tests als Alleinmittel... Will man ein qualitativ hochwertiges Ergebnis haben, dann muss das gesamte Handeln von vornherein auf dieses Ziel ausgerichtet sein! Ergo: Eine Koordination des Entwicklerteams ist im gesamten Entwicklungsprozess erforderlich /5

6 ios Human Interface Guidelines /6

7 UsabilityGeek Website -user-interface-guidelines-from-companies/ , sehr viele Normen verlinkt /7

8 Methodik Qualitätsziele festgelegen, danach den gesamten Prozess darauf ausrichten Jedem Entwickler den nötigen Wissensstand geben, Richtlinien festlegen, kommunizieren und kontrollieren Vier zyklische Phasen: Qualitätsplanung, Qualitätslenkung, Qualitätsbewertung und Qualitätsförderung. Mittel: Richtlinien, Styleguides, vereinbarte Prozesse (z.b. ISO 9001), Usability-Tests, /8

9 EN ISO 9001 Anforderungen an ein Qualitätsmanagementsystem für den Fall, dass eine Organisation ihre Fähigkeit darlegen muss, Produkte bereitzustellen, welche die Anforderungen der Kunden und behördliche Anforderungen erfüllen, und die anstrebt, die Kundenzufriedenheit zu erhöhen. Prozessorientierter Ansatz. Bedarf der Unterlegung durch Gesetze, Normen, Richtlinien, Styleguides, heuristische Regeln, Traditionen des Teams /9

10 /10

11 EN ISO 9001 Die acht Grundsätze des Qualitätsmanagements: Kundenorientierung, Verantwortlichkeit der Führung, Einbeziehung der beteiligten Personen, Prozessorientierter Ansatz, Systemorientierter Managementansatz, Kontinuierliche Verbesserung, Sachbezogener Entscheidungsfindungsansatz, Lieferantenbeziehungen zum gegenseitigen Nutzen /11

12 ISO/IEC 9126 Software Die ISO 9126 von 1992 setzt auf eine Grundmenge von 6 unabhängigen Qualitätsparametern: Funktionalität, Zuverlässigkeit, Usability, Effizienz, Wartbarkeit, Portierbarkeit. Hierarchischer Aufbau der Kategorien und Begrifflichkeiten Z.B. Usability: Verständlichkeit Anstrengung der Nutzer, das der Software unterliegende Konzept zu erkennen /12

13 ISO/IEC 9126 Software Erlernbarkeit Anstrengung des Nutzers, die Nutzung der Software zu erlernen Benutzbarkeit Anstrengung des Nutzers, die Software zu beherrschen und die Funktionalitäten zielgerichtet zu nutzen /13

14 ISO/IEC 9126 Software Attraktivität Grad des Gefallens und der Beliebtheit der Software beim Nutzer, nach dessen subjektiven Maßstäben Grad der Befolgung von Usability-Regeln Befolgen der Erfahrungsgrundsätze und Regeln von Usability nach existierenden Standards Seit 2005: ISO/IEC Software engineering Software product Quality Requirements and Evaluation (SQuaRE) Guide to SQuaRE /14

15 ISO/IEC /15

16 Gesetze, Normen und Verordnungen /16

17 Gesetze und Normen Gesetze und Normen (DIN, EN, ISO etc.) sind wichtige Quellen allgemeiner Festlegungen und bedenkenswerter Auffassungen. Bei der praktischen Arbeit sind sie jedoch oft nicht unmittelbar anwendbar, weil zu allgemein. Der Grund liegt in ihrem Langzeitcharakter, was ein Eingehen auf aktuelle Entwicklungen meist verbietet. Außerdem haben Gesetze an sich den Anspruch absoluter und langfristiger Gültigkeit, was der technischen Entwicklung widerspricht /17

18 DIN EN ISO - Normen (10-17) [ HTWK-Leipzig, /18

19 BildscharbV /19

20 Gesetze und Normen Normen unterliegen großem Druck seitens des technischen Fortschritts (Bildschirmauflösung, Farbenvielfalt, Graustufenzahl, 3D, Dynamik,...). Ergonomienormen für Software sind nicht mit Standardtests abprüfbar. Es fehlt eine Methodik dazu. Normen berücksichtigen nur bedingt sich durch Massenprodukte (z.b. Windows XP, Vista, 7-10) verändernde Nutzergewohnheiten /20

21 DIN 9241 im Überblick /21

22 ISO EN DIN 9241 von 1997/ /10 Bildschirmarbeitsplätze: Grundsätze der Dialoggestaltung 9241/110 (ersetzt /10): Grundsätze der Dialoggestaltung (= Fokuswechsel!) 9241/151: Leitlinien zur Gestaltung von Benutzungsschnittstellen für das World Wide Web 9241/11 Anforderungen an die Gebrauchstauglichkeit - Leitsätze 9241/12 Informationsdarstellung (Teile 110, ständige Weiterentwicklung) [vgl /22

23 DIN EN ISO (1997) HTWK-Leipzig, /23

24 Quellenstudium Die Norm 9241 ist sehr umfangreich, aber es ist für sich auf Usability Spezialisierende sehr wichtig, sich mit Teilen dieser Norm intensiv zu befassen. Quellen sind z.b. Bibliotheken oder Online- Zugänge über Institutionsabonnements bzw. Bibliotheken. Für einen Erstkontakt seien Bücher wie [Sarodnick/Brau, 2006/2011] oder Online- Quellen über die Norm 9241 empfohlen /24

25 /25

26 /26

27 Heuristische Erfahrungen /27

28 Heuristische Erfahrungen Heuristische Regeln beruhen auf Erfahrungswerten einzelner Personen bzw. Personengruppen, die sich (für diese) als weitergebenswert erwiesen haben. Oft sind sie kurz und knapp formuliert, lassen sich leicht merken und können durch persönliche Erfahrungen adaptiert und angereichert werden. Sie sind aber immer durch den Zeitgeist geprägt /28

29 Ben Shneidermans 8 goldene Regeln Konsistenz (verwende Styleguides und weitere schriftliche Konventionen) Abkürzungen für erfahrene Benutzer (Shortcuts, Makros) Rückmeldungen auf Aktionen des Benutzers (visuell, akustisch, taktil) Abgeschlossene Operationen (modale Dialogfenster) /29

30 Ben Shneidermans 8 goldene Regeln Fehlerbehandlung (verständliche Meldungen, Vorschläge zur Fehlerbehebung) Einfache Rücksetzmöglichkeiten (Undo und Abbruch in jeder Situation, ohne Schäden) Benutzerbestimmte Eingaben (Modi nach Nutzertyp nur, wenn unbedingt erforderlich) Geringe Belastung des Kurzzeitgedächtnisses (kurze Menüs) /30

31 Nielsen Heuristics HTWK-Leipzig, /31

32 Heuristische Erfahrungen Heuristische Erfahrungen sind gute generelle Hinweise, wonach man schauen muss. Sie können jedoch nicht die notwendige Konkretheit für koordiniertes Handeln der Entwicklergemeinde bewirken, die bei Anwendungsprogrammierung im großen Stil erforderlich ist. Sie sind eine wertvolle Ergänzung und oft Trendsetter! /32

33 Weitere Quellen First Principles of Interaction Design von Bruce Tognazzini - 21 Prinzipien nach Thematiken des Interaktionsdesigns, 2004 bzw bzw. in Deutsch meiert.com/de/publications/translations/asktog.com/firstprinciples. Principles of Information Display for Visualization Practioners von Edward Tufte, 1994 / www2.cs.uregina.ca/~rbm/cs100/notes/spreadsheets/tufte_paper.html bzw. in Deutsch meiert.com/de/publications/translations/uregina.ca/tufte/, meiert.com/de/publications/translations/washington.edu/tufte/ /33

34 Weitere Quellen 11 Gebote guten Webdesigns - Quintessenz aus 33 weiteren Onlineartikeln zu Teilaspekten der Gestaltung von Websites 10 wichtige Leitlinien für die Gestaltung von ergonomischen WWW-Informationssystemen /34

35 Styleguides, Guidelines, Richtlinien /35

36 Styleguides Styleguides sind Empfehlungen der Plattformhersteller zur Vereinheitlichung der unter dem System laufenden Software. Sie stellen aber nur bedingt die Umsetzung der Normen dar. Styleguides machen Vorschläge für das Aussehen und Verhalten ( look and feel ) von Programmen. Styleguides dokumentieren Prinzipien und Regeln für das Erscheinungsbild grafischer Oberflächen /36

37 Styleguides In den letzten Jahren haben führende Computerhersteller, Softwareanbieter und Firmenverbünde eigene Richtlinien (Style Guides, Guidelines) zur Gestaltung von Benutzeroberflächen herausgegeben. Diese Werke dokumentieren Prinzipien und Regeln, die dem Erscheinungsbild und der Benutzung der jeweiligen Oberfläche zu Grunde liegen (sollen). Auch kleinere Firmen geben sich häufiger Regeln /37

38 HTWK-Leipzig, 2008 Styleguides OSX Human Interface Guidelines (Apple) IBM SAA/CUA Advanced Interface Design Guide OSF/Motif Style Guide Windows User Experience Guidelines NEXTSTEP UI Guidelines OPEN LOOK GUI Application Style Guidelines New Wave UI Style Guidelines (HP) DECWindows UI Style Guidelines Silicon Graphics UI Style Guidelines BC - SAP Styleguide JAVA Look and Feel Design Guidelines (SUN) Gnome Human Interface Guidelines /38

39 Styleguides Android User Interface Guidelines Windows Phone mit Video mit Videos /39

40 Styleguides Apple ios Experience/Conceptual/MobileHIG/Introduction/Introduc tion.html e/conceptual/iphoneosprogrammingguide/introduction /Introduction.html#//apple_ref/doc/uid/TP Schwerpunkte auf Oberflächendesign und Fallstudien, also mehr Lernen durch Beispiele! /40

41 Hintergründe Es gibt eine Vielzahl sich wechselseitig beeinflussender technischer, ökonomischer und ergonomischer Faktoren, die Styleguides (neuer: Human Interface (Design) Guidelines) entstehen lassen. Dazu kommt die Fülle der Gestaltungsmöglichkeiten der grafischen Benutzeroberflächen, im Gegensatz zu den textlich orientierten Benutzeroberflächen. (Technologisch!) Beschränkung ist erforderlich /41

42 OSXHI von Apple /42

43 OSXHI von Apple /43

44 Hintergründe Das Marketing von Computern und Software erfordert ein möglichst einheitliches und unverwechselbares Erscheinungsbild eines Systems. ( look and feel ) Die Eigenschaft der leichten, fast intuitiven Benutzbarkeit stellt ein entscheidendes weiteres Kaufargument dar. Es wird ein Lerntransfer über verschiedene Produkte eines Herstellers angestrebt /44

45 Hintergründe Standardisierte Benutzeroberflächen werden durch die Verbreitung des Computereinsatzes und der damit einhergehenden Emanzipation der Benutzer von herstellerspezifischen DV- Technologien gefördert. Softwarehäuser versuchen daher, ihre Software plattformübergreifend lauffähig und damit einheitlich zu gestalten. Das fördert Oberflächenstandardisierung /45

46 Schlussfolgerung Die veröffentlichten Richtlinien zur Benutzeroberfläche dienen der weltweiten einheitlichen Information der Anwendungsentwickler zu einem großen System oder einer verbreiteten Software. Softwarehäuser haben den Vorteil, dass sie ihre Anstrengung auf die Implementierung von Funktionalität konzentrieren können, die Oberflächengestaltung wird vereinheitlicht und wiederholt sich in weiten Teilen der GUI /46

47 Realisierungen der Richtlinien Es muss unterschieden werden zwischen den Richtlinien auf Papier oder im WWW, deren Realisierung in den proprietären Betriebsund Fenstersystemen, deren Realisierung in Anwendungen, die z.t. auf mehreren Betriebssystemen laufen. Der beschriebene Soll-Zustand der Software wird von Produkten des Herausgebers der Styleguides weitestgehend erfüllt /47

48 Realisierung der Richtlinien Hersteller von Anwendungssoftware hingegen müssen sich oft an mehreren verschiedenen Styleguides orientieren und sie haben oft ein eigenes Wiedererkennungsbedürfnis für ihre eigenen Softwareprodukte (siehe SAP). Die Richtlinien selbst werden von Zeit zu Zeit überarbeitet und angepasst /48

49 Die Styleguides: Aufbau Der Aufbau aller Styleguides ist sehr ähnlich: In einem einleitenden Kapitel werden die Ziele und Gestaltungsprinzipien dargestellt. Es folgt ein Kapitel zu grundlegenden Fragen der Interaktion und Navigation. Dann kommen Kapitel über Fenstergestaltung, Menügestaltung und Gestaltung von Bedienelementen. Ergänzend werden Aussagen zu Hilfe, multimodalen und multimedialen Erweiterungen und zur Internationalisierung gemacht /49

50 Die Styleguides: Aufbau Prüf- und Übersetzungslisten bilden den Anhang. Die Motif- und CUA-Richtlinien enthalten zusätzlich einen umfassenden Stichwortteil der einzelnen Oberflächenkomponenten. Angaben zur Datenpräsentation gehören noch zum Entwicklungspotential. Viele der Styleguides haben mit den Jahren Anleihen beieinander genommen, viele Abschnitte lesen sich sehr ähnlich, aber nicht alle /50

51 Styleguides... Styleguides liefern die notwendige Detailliertheit und Konkretheit für den Entwicklungsalltag, um Aktivitäten zu koordinieren. Sie sind dennoch sehr umfangreich und mitunter nicht erschöpfend, selbst bei klassischen Themen der Entwicklung. Es ist schwer, bei den vielen Regeln Konsistenz zu wahren. Die technische Entwicklung macht sie immer umfassender und größer /51

52 Neuer Trend Styleguides der letzten Jahre versuchen, von der unübersichtlichen Sammlung von Regeln wegzukommen. Sie arbeiten mit intuitiven Beispielen, zu denen kurze Empfehlungen und Regeln formuliert werden. Es gibt keine ultimativen Forderungskataloge mehr /52

53 /53

54 HTWK-Leipzig, 2008 Styleguides MacIntosh Human Interface Guidelines: Apple Computer, Inc. (1992). Macintosh Human Interface Guidelines: The Apple Desktop Interface. Reading, MA: Addison-Wesley. IBM SAA/CUA Advanced Interface Design Guide: IBM (1991). SAA/CUA Advanced Interface Design Guide. Report SC OSF/Motif Style Guide: Open Software Foundation (1990). OSF/Motif Style Guide. Rev.1.2. Englewood Cliffs, New Jersey: Printice Hall. / Revision/dp/ Windows Interface Application Design Guidelines: Microsoft Corporation (1992). The Windows Interface: An Application Design Guide. Microsoft Press. / Vista Human Interface Guidelines OpenStep UI Guidelines: epuserinterfaceguidelines.pdf /54

55 Styleguides OPEN LOOK GUI Application Style Guidelines: Sun Microsystems, Inc. (1990). OPEN LOOK Graphical User Interface Application Style Guidelines. Reading, MA: Addison-Wesley. HP - New Wave UI Style Guidelines DECWindows UI Style Guidelines Silicon Graphics UI Style Guidelines BC - SAP Styleguide: /en/85/dae3324bac11d1890e0000e8322f96/frameset.htm SUN Java Look and Feel Design Guidelines: Sammlung (2010): /science_of_usability/ui_style_guides/ /55

56 Web-Styleguides Thomas Wirth, Web-Entwickler: Astrid Beck, Ergonomie-Beraterin: Harald Weinreich, 10 Regeln: The Yale C/AIM WWW Style Manual: HTML writers Guild: MMI Online-Zeitschrift zur Mensch-Maschine-Interaktion: ebook Die Webdesign-Referenz: Saul Greenberg, University of Calgary, Kanada: Dr. G. Hellbardt, Vorlesung Softwareergonomie, FSU Jena, HTWK-Leipzig, /56

57 Neu April 2007 Neben korrigierten Links in den Quellen zuvor: Apple Human Interface Guidelines als PDF: ual/osxhiguidelines/osxhiguidelines.pdf Eclipse User Interface Guidelines: GNOME Human Interface Guidelines: KDE Human Interface Guidelines: ndex.html, Nokia Games Usability guidelines: Wikipedia stets aktuell: /57

58 Nachtrag April 2008 / 2009 Ellen Reitmayr von relevantive AG, User Interface Guidelines Möglichkeiten und Grenzen, Konferenz World Usability Day where open source meets usability, , Berlin, Veranstalter: openusability.org, ATIA (Assistive Technology Industry Association) The Collective Voice of the Assistive Technology Industry, AIA (Accessibility Interoperability Alliance), Jacob Nielsen, Openusability.org F. Sarodnick, H. Brau, Methoden der Usability Evaluation. Wissenschaftliche Grundlagen und praktische Anwendungen., Verlag Hans Huber, Hogrefe AG, Bern, 2006 / /58

59 Quellen April 2009 Leitfaden Usability, DATech, Deutsche Akkreditierungsstelle Technik in der TGA GmbH, Frankfurt/Main, 2011: Artikel zur neuen DIN 9241/110 mit Unterteilen von 2006 Einführung in die ISO , von Texte zu Gestaltung, Usability und Webdesign mit Hintergründen - sehr aufschlussreich /59

60 Quellen 2013 (mehr) Apple OSX ce/conceptual/applehiguidelines/intro/intro.html#//apple_ref/doc/ui d/tp tp6 Windows XP, 7, 8, RT - Windows 8 und Windows RT XP und Windows 7 - Windows /60

61 Quellen 2015 Michael Georgiou, 9 UX Myths That You Thought Were True But Are Not, Sébastien Fabre, A list of Style Guides and UI Guidelines, David Travis at Userfocus, 247 web usability guidelines, Usability Workbook in Excel, Userfocus, /61

62 Lessons in Usability Fun From the movie Sleeper w&hl=en /62

63 Vielen Dank für Ihre Aufmerksamkeit bis demnächst /63

64 Ökonomische Zahlen aus Entwicklersicht /64

65 Mehraufwand Usability... Wie diskutiere ich im Team, mit dem eigenen Controlling oder mit Kunden über den Sinn von momentanen Mehraufwendungen für die Verbesserung der Usability? Für Menschen, die in Geldflüssen denken müssen, ist oft nur das ökonomische Beispiel oder die Angabe von Vergleichswerten ein Weg, das eigene Anliegen zu befördern. Die Literaturquellen dazu sind rar /65

66 Codezeilen GUI % der Codezeilen für die Benutzungsschnittstelle [Smith, S.L., Mosier, J.N., Behaviour and Information Technology, Vol. 3, No. 3, 1984, ] % der Codezeilen dafür [MacIntyre, F., Estep, K.W., Sieburth, J.W., Journal of Forth Application and Research, Vol. 6, No. 2, 1990, ] RIAs - 80%ige GUI-Orientierung [eigene Schätzung; aber: Deklarative Programmierung, M. Frank] /66

67 Entwicklungsaufwand GUI % des Entwicklungsaufwands [Rosenberg, in J. Nielsen (Ed.), Coordinating User Interfaces for Consistency, Boston, Academic Press, 1989] % des Entwicklungsaufwands [Wixon, D., Jones, S., Usability for fun and profit: A case study of the design of DEC RALLY Version 2. Internal Report, Digital Equipment Corporation, 1991] % des Entwicklungsaufwands [www-ia.tu-ilmenau.de/ipi/fgt/osvac/zp3/benutzungsoberflaechen /prototyp98/buch/grundlagen/styleguides/styleguides.htm] /67

68 Codezeilen GUI Weitere Quellen zu Vergleichen der Entwicklungsaufwände bei verschiedenen Vorgehensweisen: 101/pdfFile.pdf (von 2007). Intelliun Virtual Enterprise versus Eclipse als IDE (2005). Qt für C++ versus AWT/Swing für Java als IDE Codierungsaufwand und Kosten für Red Hat Linux 7.1, von David A. Wheeler, (Tool: sloccount.) (2008). Vergleich eines Projektes in ZK, JavaFX, Echo bzw. GWT (SLOC). (2007). Vergleich eines Projektes in ASP.NET+AJAX, Flex bzw. Curl /68

69 Wartungskosten GUI % aller Kosten über die Lebensdauer des Software-Produkts [Pressman, R.S., Software-Engineering: A Practitioner's Approach, 1992] % aller Wartungskosten wegen unbefriedigter oder nicht vorhergesehener Benutzeranforderungen [Martin, J., McClure, C., Software Maintenance: The Problem and its Solution, 1983; Pressman, R.S., Software-Engineering: A Practitioner's Approach, 1992] /69

70 Einführungskosten SW % des Gewinns können durch 3-6 Monate Verzögerung bei der Auslieferung verloren gehen [House, C.H., Price, R.L., Harvard Business Review, 69, 1, 1991, ; Conklin, P., Human Computer Interface Design, Boulder, Co., 1991, July ] 10% höherer Umsatz durch beschleunigte Akzeptanz und weniger Reklamationen (1991) /70

71 Wie argumentieren? Zentrale Fragen bei der Verhandlung von Softwareunternehmen mit potentiellen Kunden sind in der Projektanbahnungsphase: Wie erkläre ich dem Kunden höhere Aufwände bei der Entwicklung der Benutzerschnittstellen? Wie gewinne ich den Kunden ggf. für gemeinsames Prototyping und für Usabilitytests? Ein Weg ist es erfahrungsgemäß, ihm exemplarisch Kosteneinsparungen abzuschätzen /71

72 Fallstudie 1 Hotelkette mit 500 Angestellten Durchschnittsgehalt DM (1991) Fluktuation 25%, d.h. 125 Personen/Jahr Kosten der Fluktuation: 1,5 Durchschnittsgehalt/Person Verbesserte Benutzbarkeit des Online-Systems Rückgang der Fluktuation: 10%, d.h. 12 Personen weniger Kostenminderung: DM 1,5 = DM/Jahr [Schlesinger, L.A., Heskett, J.L., Harvard Business Review, 69, 5, 1991, 71-81] /72

73 HTWK-Leipzig, 2008 Fallstudie Angestellte im Betrieb arbeiten mit einer Software Personalkosten 42,- /Std.,15 Arbeitsaufgaben/Person/Tag 220 Arbeitstage/Jahr Fehlerrate 5%, Dauer der Fehlerkorrektur: 5 min Anzahl Fehler/Jahr: ,05 = Reduktion der Fehlerrate auf 1% Anzahl Fehler/Jahr: ,01 = Eingesparte Stunden: ( ) 5/60 = Std. <= 2 Akr. Eingesparte Personalkosten Std. 42 /Std. = /73

74 Fallstudie 3 Es gibt 15 Benutzbarkeitsprobleme in der SW. Sie erfordern Änderung des Programmdesigns. Kosten während der Entwicklungsphase: Dauer einer Änderung 6 Std. Personalkosten 60 /Std. Kosten: = Kosten nach Auslieferung des Produkts: mindestens 40fach höher (lt. Pressman) Kosten = [Pressman, R.S., Software-Engineering: A Practitioner's Approach, 1992], Preise von 2004, Ostdeutschland /74

75 Überzeugungskraft?! Ob solche Argumente überzeugen, hängt von der Professionalität der Handelnden im Softwareunternehmen und an der Kundenfront ab. Natürlich spielt die Projektsituation eine Rolle. Wissen Sie andere Mittel, den Nutzen von Usability-Anstrengungen im Softwareunternehmen und gegenüber dem Kunden deutlich zu machen? /75