Zustandsdiagramm
Zustandsdiagramme werden in der UML beschrieben und dienen der Darstellung von Systemverhalten. Mit Zustandsdiagrammen kann das innere Verhalten von Objekten in Geschäftssystemen oder IT-Systemen beschrieben werden. Das Verhalten bezeichnet die Wechselwirkung und Interaktion zwischen Objekten eines solchen Systems. Zustandsdiagramme sind vor allem in der Software-Entwicklung verbreitet, insbesondere bei Klassenobjekten, die ein sehr dynamisches Verhalten (ausgelöst durch viele Ereignisse) aufweisen.
Zustandsdiagramme zeigen die durch Ereignisse (Events) beeinflussten Zustände, die ein Objekt annehmen kann, sowie die Ereignisse oder Nachrichten, die im kausalen Zusammenhang mit einem Zustandswechsel stehen. In einem Geschäftssystem wird die Zustandsänderung der Objekte (Verhalten) durch Geschäftsprozesse nach Geschäftsregeln ausgelöst.
Aktivitätsdiagramm
Die meisten UML-Diagramme sind für die Darstellung von Hierarchien und Aufbaustrukturen unter dem Grundsatz der Objektorientierung geschaffen worden. Aktivitätsdiagramme zeigen jedoch die funktionale Sicht und sind unabhängig von dem Gedanken eines objektorientierten Aufbaus, gehören also zu den Verhaltensdiagrammen. Nur mit Funktionen bzw. Methoden (Aktivitäten) lässt sich Bewegung im System darstellen.
Aktivitätsdiagramme sind vergleichbar mit Programmablaufplänen oder Struktogrammen und nicht nur in der Software-Entwicklung nützlich, sondern auch in der Prozessabbildung, beispielsweise zur Abbildung von Geschäftsprozessen. Aktivitätsdiagramme ermöglichen die Abbildung von Verantwortungsbereichen über Prozesse sowie die Parallelisierung von Prozessen, was Aktivitätsdiagramme besonders für die Darstellung und Analyse von Geschäftsprozessen in der Wirtschaftsinformatik und Aktivitäten bei verteilten Anwendungen in der Software-Entwicklung qualifiziert. (mehr…)
Zahlensysteme
Die in der Informatik gängigen Zahlensysteme zu verstehen ist unabdingbar für jegliche professionelle Programmierer und Netzwerktechniker. Die in der Software- und Netzwerktechnik vorkommenden Zahlensysteme sind Stellenwertsysteme.
Stellenwertsysteme basieren auf der bestimmten Wertigkeit einer Position (Stelle) jeder Ziffer. Ein typisches Zahlensystem, welches kein Stellenwertsystem, sondern ein Additionssystem ist, ist das Notieren von Ereignissen/Objekten mit Strichen, beispielsweise das (für Bierdeckelnotizen bekannte) System, wonach vier Striche vertikal, der fünfte Strich diagonal dargestellt werden. Additionssysteme können auch in anderer Form dargestellt werden, sind gewöhnlicherweise aber nur für kleine Summen übersichtlich.
Stellenwertsysteme entsprechen einer anderen Logik, nämlich der der Stellenwerte.
Der Wert einer Zahl (Zahlenwert) wird nicht an Hand von Strichen oder anderen Symbolen abgezählt, sondern errechnet. Der Zahlenwert ist die Summe aus allen Ziffernwerten (die einer Zahl zugehörig sind). Die Ziffernwerte sind die jeweiligen Produkte aus Stellenwert und Nennwert.
Zahlenwert = ∑ Ziffernwerti = ∑ (Nennwerti x Stellenwerti)
Erlernbarkeit (Suitability for learning)
Die Erlernbarkeit resultiert im Wesentlichen aus der Erfüllung der übrigen Forderungen an Software.
Insbesondere die Selbstbeschreibungsfähigkeit (Software soll sich selbst erklären können, unter Berücksichtigung der Zielgruppe) und die Erwartungskonformität (der Benutzer soll bekommen, was er mit der Anschaffung und Nutzung der Software erwartet) erleichtern die Erlernbarkeit von Software.
Es sollen die Standardfunktionen der Software sowie die Individualisierbarkeit (Anpassung der Software an individuelle Ansprüche und Vorgaben) so gestaltet werden, dass sie für den Benutzer aus der Zielgruppe leicht durchschaubar und somit für ihn erlernbar sein.
Es kommt wirklich nicht selten vor, dass Benutzer Software verwenden, so wie sie es aus ihrem Umfeld her kennen, ohne dabei die Fähigkeiten in Sachen Individualisierbarkeit auszureizen, weil sich die Funktionen der Individualisierbarkeit und individuelle Funktionen selbst nicht selbstbeschreiben und zusätzlich noch zu kompliziert gestaltet sind.
Die Erlernbarkeit von Software hängt natürlich auch vom Benutzer und seinem Vorwissen ab. Die Erlernbarkeit ist nur dann ausreichend, wenn die Funktionen der Software für jeden Benutzer aus der Zielgruppe, für welche die Software bestimmt wurde, vollständig (mit Ausnahme von versteckten Funktionen, welche nur für die Software-Entwicklung gedacht sind) mit angemessenen Mitteln und vertretbarer Mühe erlernbar sind.
Sicher ist die Erlernbarkeit von Software nicht direkt messbar und auch “angemessene Mittel” und “vertretbare Mühe” sind stark Auslegungssache. Der Softwarehersteller muss sich selbstkritisch mit dem Thema auseinandersetzen und eigene, eher pessimistische Maßstäbe setzen.
Andererseits ist die zu gute Erlernbarkeit für den Softwarehersteller manchmal gar nicht so erstrebenswert, wo doch viel Geld mit dem Support und mit Kursen/Zertifikaten gemacht werden kann und das Hauptaugenmerk nun mal leider nicht auf die Softwarequalität gelegt wird. Dennoch sollte jedes Unternehmen zumindest die grundlegenden Funktionen einer Software leicht erlernbar auslegen, so dass nur spezielle Funktionen durch weiteren Support erläutert und somit richtig nutzbar gemacht werden.
Ein sehr gutes Beispiel für einen Durchbruch in Sachen Erlernbarkeit, ist die grafische Benutzeroberfläche, welche durch Microsoft Windows erstmals richtig bekannt wurde und damit als erstes Betriebssystem sich im Heimanwendermarkt etablieren konnte. Während professionelle Computeranwender sich noch lange Zeit überwiegend mit der Konsolenbedienung zufrieden gaben, haben die vergleichsweise ungeduldigen Heimanwender durch die viel schneller erlernbare Grafikoberflächenbedienung Zugang zu der Bedienung des PCs gefunden. Die Grafikoberfläche hatte ihre Nachteile in der größeren Ressourcenlast und führte daher zu Performance-Einbüßen, dennoch war dies im Vergleich doch das geringere Übel.
Wissensmanagement
Wissensmanagement (engl.: Knowledge Management) ist die methodische Unterstützung, Steuerung und Kontrolle von Prozessen zum Ausbau von Wissensbasen einer Organisation oder Person. Wissensbasen sind Informationen und deren Interpretation, die zur Lösung von Problemen notwendig oder hilfreich sind. Gutes Wissensmanagement ist zwingend Bestandteil gutem Innovationsmanagements.
Der harte Kern jeden Wissens sind Daten, welche mit einer Bedeutung versehen, Informationen sind. Informationen ergeben Wissen, wenn diese aus einem bestimmten Kontext heraus interpretiert werden (können) und entsprechend darauf reagiert werden kann.
Ziele des Wissensmanagement sind:
- Förderung der Aneignung von neuem Wissen
Beispielhafte Leitfrage: “Wie können unsere Mitarbeiter den Umgang mit neuen Verfahren lernen?” - Schaffung von Möglichkeiten zur Nutzung von bestehendem Wissen
Beispielhafte Leitfrage: “Welche Organisation fördert innovatives Denken?” - Verhinderung von Verlust des Wissens
Beispielhafte Leitfrage: “Wie kann ein Know-How-Verlust trotz Fluktuation verhindert werden?”
Open System Interconnection – Referenzmodell
Das OSI-Referenzmodell (auch: OSI-Schichtenmodell, OSI-Modell, engl.: “Open Systems Interconnection Reference Model”) ist ein, in der Computer-Netzwerktechnik relevantes Modell der Internationalen Organisation für Normung (ISO).
Das OSI-Referenzmodell ist ein mehrschichtiges System eines offenen Netzwerksystems. Es ist die Grundlage, auf der Netzwerkkommunikationsprotokolle aufbauen.
Maßgeblich ist das OSI-Modell für offene Netzwerksysteme; dieses sind Netzwerke, in denen jeder Anwenderprozess mit jedem anderen über offengelegte Schnittstellen kommunizieren kann.
Das OSI-Modell basiert auf sieben Schichten nach dem Prinzip der Kapselung, welche für sich jeweils alleine für eine in sich geschlossene Ebene stehen.
Selbstbeschreibungsfähigkeit (Self-descriptiveness)
Ergonomische Software sollte selbstbeschreibungsfähig sein. Die gesamte Benutzeroberfläche sollte selbsterklärend sein, idealerweise sollte der Benutzer nicht erst das Benutzerhandbuch einstudieren müssen, um mit der Software von der Installation bis hin zum erwünschten Ergebnis kommen zu können.
Dennoch sollte es ein Benutzerhandbuch geben, welches alle Funktionen verständlich und ausführlich beschreibt, jedoch den Nutzen jeder Funktion auf  den Punkt bringt. Für das richtige Schreiben des Benutzerhandbuchs gibt es eine  Reihe eigener Regeln für Struktur, Sprache und Technik. In Deutschland ist das Fehlen eines verständlichen und vollständigen Handbuchs sogar als ein Mangel nach dem BGB zu sehen.
Fern ab vom Handbuch, sollte die Software selbst jedoch selbstbeschreibungsfähig sein, denn dies gewährleistet den flexiblen Einsatz der Software.
Probleme durch falsche Bedienung sowie auch Programmfehler sollen durch Dialoge angezeigt und erklärt werden, zudem sollen nach Möglichkeit Lösungswege vorgeschlagen werden. Dabei ist auf eine Sprache zu achten, die an die Zielgruppe des Programms angepasst ist, in jedem Fall aber klar formuliert, ohne Rechtsschreib- und Grammatikfehler (diese stellen nicht nur die Software-Qualität in Frage, sondern könne auch für sprachliche Mehrdeutigkeiten sorgen).
Die Benutzeroberfläche ist dann nicht selbstbeschreibungsfähig, wenn Funktionen sowie der funktionale Zusammenhang ganz oder teilweise unverständlich ist. Wenn dazu noch keine weiterführenden Informationen (z. B. als Hilfe, FAQ etc.) abgerufen werden können, ist die Software bei entsprechender Komplexität quasi nur noch für an der Entwicklung beteiligten Experten bedienbar und somit weder wirtschaftlich noch flexibel einsetzbar.
Der Benutzer muss sich über den Funktionsumfang und den aktuellen Systemzustand informieren können, diese Informationen müssen ihm leicht zugängig sein. Es ist für den optimalen Softwareeinsatz außerdem unabdingbar, dass der Benutzer sich leicht über den Programmvorgang leicht verständlich und schnell erfassbar in Kenntnis gesetzt wird. Beispielsweise ist es sehr ärgerlich, wenn das Programm auf Parameter wartet, der Benutzer dieses jedoch gar nicht weiß und den Programmfortschritt abwartet.
Die Software soll Rückmeldungen an den Benutzer geben können und darüber informieren, wie das Ergebnis erreicht wurde (Prozesse) bzw. auftretende Probleme erläutern.
Um Routinetätigkeiten jedoch nicht unnötig auszubremsen, sollte der Informationsgrad jedoch vom Benutzer bis zu einem verantwortbaren Bereich einschränkbar sein.
Fehlerrobustheit (Error tolerance)
Ergonomische und wirtschaftliche Software muss eine Robustheit gegenüber Fehlern bei der Benutzung aufweisen (Error Tolerance).
Die Fehlerrobustheit betrifft sowohl die Zuverlässigkeit der Arbeitsergebnisse (Berechnungen) als auch der Zuverlässigkeit der Software selbst (Software-Stabilität).
Eine zu lange Zahl oder Zeichenkette oder Daten, welche in einem anderen Format erwartet wurden, können das Arbeitsergebnis unbrauchbar machen oder gar zum Programmabsturz führen.
Wird eine Zahl beispielsweise vom Typ Integer erwartet, ist das Eingabefeld auf die richtige maximale Länge zu begrenzen und zu prüfen, ob die Eingabedaten tatsächlich nur Zahlen (und nicht etwa Sonderzeichen oder Buchstaben) enthalten. Wird ein Datum erwartet, ist nicht nur die richtige Länge zu begrenzen, sondern auch ein (möglichst gängiges) Format zu definieren und auf Einhaltung zu prüfen.
Fehler können bei jeder Eingabe durch den Benutzer aus Unwissenheit, Unerfahrenheit, Missgeschick oder Unaufmerksamkeit erfolgen. Es gilt daher, dem Benutzer niemals zu vertrauen, sondern alle Eingaben auf Fehlerfreiheit zu überprüfen. Der Benutzer wird diese kritische Einstellung gegenüber seinen Eingaben mit Vertrauen in die Programmzuverlässigkeit würdigen.
Ein weiterer Aspekt ist die gezielte Ausnutzung eines Fehlers (SQL-Injection, gezielte Herbeiführung eines Buffer-Overflows für Exploits u.a.), welche durch Fehlerrobustheit so weit wie möglich erschwert werden soll.
Fehlerhafte Eingaben müssen korrigierbar sein. Trotz fehlerhafter Eingaben muss das beabsichtigte Arbeitsergebnis nur mit geringem oder besser gar keinem Korrekturaufwand (durch selbstständige Fehlerkorrektur) erreicht werden können.
Der Benutzer soll auf Fehler hingewiesen und zur Korrektur aufgefordert oder ihm diese empfohlen werden. Fehlermeldungen sowie Korrekturaufforderungen müssen verständlich, sachlich und konstruktiv formuliert und logisch, aber leicht nachvollziehbar strukturiert sein (abhängig von der Komplexität und vom zu erwartenden Kenntnisstand der Benutzer, können “logisch” und “nachvollziehbar” zwei gegensätzliche Adjektive sein!).
Eine selbstständige Fehlerkorrektur durch das System gilt als kritisch und sollte dem Benutzer angezeigt werden, so dass er die Korrektur bestätigen oder ggf. abändern kann.
Zur Fehlermeldung gehören Fehlererkennung, wo ein Fehler auftrat, warum er auftrat (Erklärung eines kausalen Zusammenhangs) sowie ggf. Empfehlungen zur zukünftigen Fehlervermeidung.
Durch sinnvolle Gestaltung der Mensch-Maschine-Schnittstelle (Fehlerprävention) durch sinnvolle Strukturierung, Benennung, Beschriftung und weiterführenden Informationen, soll das Auftreten von Fehlern bereits von vorne herein unwahrscheinlich werden. So sollte das richtige Format z. B. für ein Datum oder eine Telefonnummer vorgegeben werden (idealerweise mit Beispiel), bestenfalls aber kann der Benutzer sofort an Hand der Eingabefeldgestaltung das zu verwendende Format erkennen.
Bei der Software-Entwicklung ist ein systemeigenes Fehlermanagement zu überlegen. Ein solches Fehlermanagement soll negative Auswirkungen (z. B. Zeitverlust) von Fehlern begrenzen. Dazu gehört u.a. die Reversibilität von
Fehlern (z. B. mit UNDO-Funktionen zum rückgängig machen von Eingabeschritten). Je komplexer die Software wird, desto schwieriger sind allerdings i.d.R. auch der Entwurf und die Implementierung einer Reversibilität.
Aufgabenangemessenheit (Suitability for the task)
Software ist auf eine bzw. mehrere Aufgaben ausgerichtet entwickelt worden. Die Software muss für diese Aufgaben angemessen gestaltet und benutzerfreundlich sein.
Ist die Bereitstellung aller benötigten Informationen und Funktionen zur Erledigung einer vorbestimmten Aufgabe (z. B. die Erstellung von Textdokumenten oder CAD-Modellen) durch die Software nicht gegeben, so ist die Software nicht angemessen praktikabel und wenig benutzerfreundlich gestaltet.
Der Benutzer soll (durch Tipps und Empfehlungen) von der Software über Informationen und Zustände informiert und unterstützt, jedoch möglichst nicht genervt werden. Dies wird mit einem Dialogsystem (vom kleinen Hinweis in der Statusanzeige bis hin zum Piepton begleitetem Fenster-Dialog) erreicht, wobei sich die Software Einstellungen (Kenntnisnahmen und Prioritäten wie Sicherheitsstufen / Warnlevel) merken muss. Wurde eine immer wieder auftauchende Information vom Benutzer zur Kenntnis genommen, soll dieser Benutzer den Hinweis auf diese Information deaktivieren können (deaktivierfähige Hinweise sind beispielsweise Tipps über die Software beim Start der Software oder bei Ausführen einer bestimmten Aktion z. B. dass eine Datei vor dem öffnen automatisch konvertiert und als temporäre Datei abgespeichert wird).
Äußerst wichtige Hinweise, insbesondere die, welche bei Unaufmerksamkeit zu Datenverlust oder schlimmeren führen können, sind jedoch von der Deaktivierfähigkeit auszuschließen. Ein Beispiel: Wird die Anwendung geschlossen, gehen nicht gespeicherte Änderungen verloren. Der Hinweis auf diese Tatsache sollte nicht automatisch umgangen werden können, es ist aber automatisch sicherzustellen, dass der Hinweis nur erscheint, wenn wirklich Änderungen nach dem letzten Speichern vorgenommen wurden.
Aufgaben, die aus der technischen Eigenheit der Software und des Systems erwachsen und aus denen keine kritischen Zustände entstehen können, sollen durch das System eigenständig ausgeführt werden (z. B. Zwischenspeicherung, Überprüfung von sowie Hinweis über Systemkomponenten und Kompatibilität).
Verfügbare Funktionen der Software sollen an wiederkehrende Aufgabenstellungen angepasst werden können (z. B. durch Standardwertdefinierung, Abspeicherung von Profilen für unterschiedliche Zwecke).
Die Komplexität der Software, ihrer Funktionalität und die Aufgabe soll auf ein angemessenes Level reduziert werden
können. Der Benutzer soll nicht permanent mit Informationen überflutet werden, sondern sich auf das im Moment Wesentliche beschränken können. Elemente (Items) sollen logisch gruppiert, Ausschnitte gezoomt, Funktionsumfänge angepasst, dabei insbesondere beschränkt (z. B. wählbare Minimalinstallation, benutzerdefinierte Installation oder Ansicht) werden können.
Ergonomische Gestaltung von Software
Ergonomie betrifft nicht nur Stühle, Schreibtische und sonstige Büromöbel, sondern auch Anzeigen und Steuerelemente (im Büro, Cockpit, Konsolen, Anlagen usw.). Die Ergonomie ist daher auch Einflussgeber in der Produktgestaltung im Maschinenbau und der Elektrotechnik. Sehr viele Anzeigen und Steuerelemente, welche vor 10 Jahren noch Hebel und analoge Anzeigen waren, sind heute digitalisiert und als Software realisiert. Die Ergonomie spielt daher auch immer mehr in der Software-Entwicklung eine Rolle. (mehr…)
Nächste Seite »