Klientenspezifisches Softwareengineering als Verfahrenskompetenz. Erschließung neuerer Verfahren und Arbeitsfelder in der Sozialen Arbeit

Inhaltsverzeichnis

1.Einleitung und Themenbeschreibung

2.Inhalt des Verfahrens "Klientenspezifisches Softwareengineering":
2.1Begriffsbestimmungen:
2.1.1 Softwareengineering:
2.1.2 Klientenspezifisch:
2.1.3 Verfahren und Technik in Abgrenzung zum Begriff der Methode:
2.1.4 Zum Begriff des Ziels bzw. der Zielsetzung:
2.1.5 Zusammenfassung:
2.2Das Informativ-logische Schleifenmodell:
2.2.1 Darstellung als strukturierter Text:
2.2.2 Darstellung als Grafik und Erläuterung des Inhalts:
2.2.2.1 Schleife 1:
2.2.2.1.1 Datenaufnahme und Auswertung:
2.2.2.1.2 Das Problem der formalen Problemstellung:
2.2.2.1.3 Das Problem der Zielsetzung:
2.2.2.2 Schleife 2a:
2.2.2.2.1 Kompetenzen und Techniken - Voraussetzungen und Abhängigkeiten:
2.2.2.2.2 Technik A / Kompetenzfeld A - Auswahl geeigneter Software:
2.2.2.2.2.1 Hardwarekenntnisse:
2.2.2.2.2.2 Softwarekenntnisse:
2.2.2.2.2.3 Konfigurationsmöglichkeiten und Usability:
2.2.2.2.2.4 Open Source, Freeware, kommerzielle Software:
2.2.2.2.3 Technik B / Kompetenzfeld B - Planung von Software:
2.2.2.2.3.1 Auslagerung von Texten, Grafiken und grundlegenden Daten:
2.2.2.2.3.2 Auswahl von Programmiersprachen:
2.2.2.2.3.3 Autorensysteme und WYSIWYG -Editoren:
2.2.2.2.4 Technik C / Kompetenzfeld C - Anfertigung von Software:
2.2.2.2.4.1 Programmstruktur und Modularisierung:
2.2.2.2.4.2 Testläufe:
2.2.2.3 Bezüge der Kompetenzfelder zum Sechsphasenmodell:
2.2.2.4 Abschließende Anmerkung:
2.2.2.5 Zusammenfassung:

3.Anwendungsbeispiele für Klientenspezifisches Softwareengineering:
3.1P76IIa 1.0:
3.1.1 Klientenbezug:
3.1.2 Anmerkungen:
3.2Labyrinth 1.3:
3.2.1 Klientenbezug:
3.2.2 Anmerkungen:
3.3Zuordnungsübungen 1.8:
3.3.1 Klientenbezug:
3.3.2 Anmerkungen:
3.4Umgang mit Alkohol:
3.4.1 Klientenbezug:
3.4.2 Anmerkungen:

4.Abschließende Erörterungen:

5.Fazit:

Quellenangaben:

Anhang:

"Es gibt einen Mythos, wonach heutzutage Computer die wichtigen Entscheidungen treffen, die früher von Menschen getroffen wurden. Vielleicht gibt es hier und da in unserer Gesellschaft einzelne Fälle dieser Art. Aber die weitverbreitete Vorstellung von Managern, die ihren Computern Fragen von der Form eingeben: "Was sollen wird jetzt tun?" und dann auf die Entscheidung des Computers warten, ist weitgehend falsch."

(Joseph Weizenbaum)

"Wenn wir plötzlich etwas sähen, das uns fremd vorkommt, etwa eine Wolke mit rechtwinkligen Ecken, dann würden wir bestimmt wissen wollen, was es ist. Und wenn man uns dann sagte, es sei eine Fuba, dann würden wir fragen, was eine Fuba ist. Aber die vielen Dinge, die uns umgeben, sind schon so lange zu einem Bestandteil unseres Lebens geworden, daß sie uns nicht fremd sind und wir auch nicht fragen, was das für Dinge sind."

(Joseph Weizenbaum)

1. – Einleitung und Themenbeschreibung:

Die Arbeit mit und am Computer hat sich zweifellos in den letzten 10 Jahren zu einer Tätigkeit entwickelt, die in allen Lebensbereichen Einzug gehalten hat, was auch für den Bereich der Sozialen Arbeit gilt. In vielen anderen Tätigkeitsfeldern ist der Computer bzw. die auf ihm laufende Software zu einem nützlichen Werkzeug herangereift.

Die vorliegende Arbeit möchte, wie der Titel schon andeutet, der Sozialen Arbeit das in den letzten Jahren immer wichtiger werdende Feld der Computertechnologie näherbringen, weitere Handlungskompetenzen und -ressourcen verfügbar machen und den Versuch durchführen, ein eigenes Verfahren zu entwickeln, das aufgrund seiner vielseitigen Anwendungsmöglichkeiten zwar prinzipiell arbeitsfeldunabhängig ist, aber doch enge Bezüge zu Vorgehensweisen und Überlegungen aufweist, die der Sozialen Arbeit immanent sind. In dem vorliegenden Text wird deshalb häufiger Bezug genommen auf fachliche Erwägungen, auf Zusammenhänge zwischen Zielsetzungen und psychischen Dispositionen^[1] sowie auf rein theoretische Erwägungen, die sich aus der speziellen Tätigkeit mit Klienten im Rahmen der Sozialen Arbeit ergeben, aber auch auf konkrete Handlungs- und Planungsmöglichkeiten zur Durchführung des hier besprochenen Verfahrens sowohl sozialarbeiterischer/sozialpädagogischer wie auch computertechnischer Art.

Nicht unerwähnt bleiben soll, daß es trotz intensiver Recherche nicht gelungen ist, ein "fertiges" Konzept oder zumindest systematische grundlegende Überlegungen zu dem hier behandelten Thema zu finden (was natürlich nicht heißt, daß es dergleichen nicht geben könnte), abgesehen von ersten Ansätzen zu einem genderspezifischen Softwareengineering^[2] sowie Ansätzen in E-Lerning-Konzepten, die sich jedoch schwerpunktmäßig mit der didaktisch aufbereiteten Vermittlung von Lerninhalten befassen^[3].

Der hier vorliegende Ansatz eines Klientenspezifischen Softwareengineerings geht aber über die genannten Ansätze hinaus. Zudem läßt er sich auch nicht ohne weiteres (bzw. nur zu einem geringen Teil) subsumieren unter dem, was momentan unter "Sozialinformatik" bzw. "Sozioinformatik" oder "Angewandte Informatik in der Sozialarbeit/Sozialpädagogik^[4] " verstanden wird. Die allgemeinen Konzepte der Sozialinformatik sehen nämlich keine eigene Erstellung von Anwendungen vor, sondern lediglich die Vermittlung von Grundlagen zur alltäglichen Computernutzung, zur kritischen Begleitung der Technikentwicklung und Technikfolgeabschätzung (Bolay 2001^[5] ) sowie die Beschreibung von Programmen, die im Rahmen der Sozialen Arbeit z.B. zur Einrichtungsverwaltung, zur Organisation usw. benutzt werden^[6]. Diese Arbeit folgt vielmehr dem Ansatz Jurgovskys, der auch die Erstellung von Anwendungen (wenn auch nicht explizit klientenspezifisch) in das Feld der Sozialinformatik einbeziehen will, und in dem das Klientenspezifische Softwareengineering einen Bruchteil dessen darstellen könnte von den Möglichkeiten, die dieser Ansatz eröffnet.

Wie weiter unten noch näher ausgeführt wird, folgt das Softwareengineering bestimmten Prinzipien und Methoden sowie systematisch angelegten Phasen bei der Erstellung. Da es sich bei Vertretern der Sozialen Arbeit im allgemeinen aber nicht um (Fach-)Informatiker oder zumindest um Personen mit entsprechender (offiziell nachgewiesener) Teilqualifikation im IT-Sektor handelt^[7], erscheint es sinnvoll zu sein, das hier gemeinte Softwareengineering weniger in technische Abläufe, als vielmehr in Kompetenzfelder zu unterteilen. Die konkreten Fähigkeiten in diesen Kompetenzfeldern korrespondieren allerdings mit den fachlichen Inhalten des "klassischen" Softwareengineerings, wie es in der Informatik angewandt wird. Dabei werden sachbedingt Verschiebungen von Abläufen sowie Hinzufügungen und Auslassungen von Wissensinhalten nötig, um das Klientenspezifische Softwareengineering als Verfahrenskompetenz für die Soziale Arbeit erschließen zu können.

Um die hier dargelegten Überlegungen anschaulicher zu gestalten, in einen fachlichen (beispielhaften) Bezug zur Sozialen Arbeit zu bringen und in ein nachvollziehbares Handlungsschema einzubetten, wurde das "Informativ-logische Schleifenmodell" entwickelt, um sowohl Inhalte der Sozialen Arbeit wie auch der Informatik zusammenführen zu können; dieses Modell hat lediglich reinen Anschauungscharakter und wurde nur für die hier vorliegende Arbeit erstellt.

(Wie Plöger [1999: 25] anmerkt, werden im pädagogischen Bereich die Begriffe Modell und Theorie häufig synonym verwandt. Hier handelt es sich natürlich nicht um eine Theorie, sondern lediglich um ein Modell im tatsächlichen Sinne, wobei es auch die modelltypischen Merkmale der Reduktion, der Abbildung und des Verwendungszusammenhangs aufweist^[8].)

Das Modell soll verdeutlichen, in welchem Rahmen ein Klientenspezifisches Softwareengineering möglich sein könnte. Natürlich ließen sich die Entstehungs- und Planungsabläufe sowie das Klientenspezifische Softwareengineering selbst auch in andere Modelle und Konzepte integrieren, allerdings sollen hier aber auch die Bezüge zwischen einer (möglichst objektiven) Zielsetzung - basierend auf einer umfassenden Datenaufnahme zur Erstellung eines zuverlässigen Klientenprofils - und der ständigen Zielüberprüfung und –anpassung (auch der verwendeten Verfahren und Techniken) dargestellt werden.

Dies soll auch die Bezeichnung "informativ-logisch" widerspiegeln. Das Modell ist rein informationsbasiert und setzt eine umfassende Datenaufnahme voraus (siehe 2.2.2.1.1 - Datenaufnahme und Auswertung). Weiterhin ist es im tatsächlichen Sinne "informativ", denn es liefert sowohl Informationen über eine flexible Zielsetzung, über die Zielerreichung sowie über seinen eigenen Ist-Zustand hinsichtlich der im Modellprozeß notwendig werdenden Änderungen/Anpassungen der verwendeten Verfahren und Techniken. Die Bezeichnung "logisch" soll hinweisen auf die Hierarchie der Handlungsklassen Methode, Verfahren und Technik, die sich auseinander ergeben (siehe 2.1.3 - Verfahren und Technik in Abgrenzung zum Begriff der Methode). Zudem soll der Begriff widerspiegeln, daß hier weder politisch noch moralisch oder religiös intendierte und in anderen Zielen "versteckte" Ziele verfolgt werden sollen, sondern nur und explizit klar umrissene/formulierte Ziele^[9], die der Operator des Modells aufgrund fachlicher Erwägungen für erforderlich hält^[10].

Dieses Modell macht den Einsatz eines Klientenspezifischen Softwareengineerings nicht zur Bedingung – vielmehr erfolgt die Entscheidung für oder gegen einen Einsatz dieses Verfahrens aufgrund fachlicher Erwägungen dahingehend, ob das Klientenspezifische Softwareengineering überhaupt das geeignete Verfahren für diesen Klienten/diese Klientengruppe ist, was sich einerseits aus dem ersten zusammenfassenden Schritt der Zielsetzung ergibt und zum anderen aus der Prämisse^[11], ebenso den kognitiven wie emotionalen und psychomotorischen Bereich bei Interaktionen mit dem Klienten (durch Angebote oder Projekte) anzusprechen. Sicherlich bietet sich dieses Verfahren hinsichtlich des kognitiven Bereiches aufgrund "logisch" funktionierender Software an – allerdings kann dies nicht einfach als gegeben angenommen werden, da dies sehr vom individuellen Verständnis, den intellektuellen Fähigkeiten des/der Klienten und anderer Faktoren abhängig ist. So dürfte es recht sinnfrei sein, z.B. einem von Geburt an blinden Klienten mit Hilfe einer Software rein kognitiv vermitteln zu wollen, wie sich verschiedene Baumrinden unterscheiden, selbst wenn das (Lern-)Programm über eine Sprachausgabe verfügte – besser wäre es, dem Klienten verschiedene Baumrinden zum "be-greifen" anzubieten. Hier sollte also vom Verfahren des Klientenspezifischen Softwareengineerings entweder völlig Abstand genommen oder es sollte nur als weiteres Hilfsmittel zur Erreichung eines Lernziels auf kognitiver Ebene verwendet werden (z.B. mittels einer Sprachausgabe, die dem Klienten gewünschte Fakten und Daten zu verschiedenen Baumarten vermittelt).

Dies gilt bei kritischer Betrachtung auch für eine Reihe weiterer möglicher Einsatzformen. So wäre es z.B. relativ sinnlos, dieses Verfahren für einen adiposen Klienten, der Gewicht verlieren soll, im psychomotorischen Bereich einzusetzen (was theoretisch eventuell möglich wäre, aber einen sehr hohen Aufwand an Hardware und Kosten bedeuten würde. Möglich wäre allerdings z.B. eine Multimedia-Anwendung, die entsprechende Übungen und weitere Unterstützung interaktiv anbieten könnte, wobei dies allerdings nicht direkt dem psychomotorischen Bereich zugeordnet werden kann).

Bei anderen Zielsetzungen kommt ein Einsatz von Software zumeist überhaupt nicht in Frage, so z.B. dann, wenn olfaktorische Inhalte vermittelt werden sollen (obwohl hier bereits erste Produkte zur computergestützten Simulation von Gerüchen angeboten werden^[12] ) oder die Sensomotorik gefördert werden soll (auch hier wieder theoretisch möglich durch Datenhelm^[13] und Senso-Anzug, wie sie zum Erleben von VR^[14] benutzt werden, aber schon aufgrund der hohen Hardwarekosten kaum zu verwirklichen).

Es gilt also kritisch zu prüfen, ob die gesetzten Ziele mit Hilfe des hier besprochenen Verfahrens überhaupt erreicht werden können, was eine genaue Kenntnis des Klienten/der Klientengruppe zwingend voraussetzt. Zudem müssen Überlegungen hinsichtlich des zeitlichen Umfangs angestellt werden – das hier vorgeschlagene Verfahren eignet sich eher weniger für "schnelle Erfolge", sondern ist sowohl von seinem Aufbau wie auch von seinen Inhalten her für einen langfristigen Einsatz besser geeignet und auch dafür konzipiert.

Die weiter oben angesprochenen Kompetenzfelder dienen als Grundlage zum Einsatz der Techniken A, B und C im Modell. In der Modellbeschreibung werden diese Techniken bzw. Kompetenzbereiche genauer spezifiziert.

2. - Inhalt des Verfahrens "Klientenspezifisches Softwareengineering:

2.1 - Begriffsbestimmungen:

2.1.1 - Softwareengineering:

"Software-Engineering ist ... ein Gebiet der Informationswissenschaft" (Hering 1984: 6).^[15]

"Software Engineering ist eine Disziplin, die mit ingenieurmäßigen Mitteln und ökonomischem Vorgehen dem Entwickler hilft, qualitativ hochwertige Software zu erstellen und zu prüfen." (Bauer)^[16]

Auch wenn deshalb der Begriff des Softwareengineerings^[17] nicht von ungefähr an das Wort "Ingenieur" erinnert (und erinnern soll), so ist diese Deutung allein noch nicht ausreichend.

Entchelmeier/Gottwald (2001: 3) umschreiben den Begriff Softwareengineering wie folgt:

"Die Entwicklung von Anwendungssystemen unter Anwendung ... speziell dafür erdachter und entwickelter Prinzipien, Methoden und Werkzeuge bezeichnet man als Software-Engineering^[18]."

Broy^[19] (2001) nennt u.a. folgende Inhalte und Bedingungen des Softwareengineerings:

- Systematisches Vorgehen bei der Entwicklung von Softwaresystemen
- Bearbeiten praxisrelevanter Probleme
- Anwenden wissenschaftlicher Methoden
- Erzeugen von Produkten
- Gesellschaftlicher Nutzen

Das "herkömmliche" Softwareengineering - wie es im professionellen Bereich durchgeführt wird - vollzieht sich je nach angewandtem Schema in sechs oder sieben Phasen. Das "klassische" Phasenmodell des Softwareengineerings gliedert sich sogar in lediglich fünf Phasen und wird gemeinhin als "Wasserfallmodell" bezeichnet (siehe Abb. 1^[20] ).

Als Weiterentwicklung des Wasserfallmodells wird das V-Modell angesehen (beide Modelle bzw. Schemata bieten Vor-, aber auch Nachteile, die für das hier behandelte Thema jedoch vernachlässigbar sind); darüber hinaus gibt es darauf basierend weitere Modelle, die sich jedoch nur marginal voneinander unterscheiden. Abbildung 2 zeigt ein lineares sechsphasiges Modell (nach Entchelmeier/Gottwald, 2001: 21 ff).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1 - Wasserfallmodell

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2 – Sechsphasenschema

Vorschlagsphase:

In dieser Phase werden lediglich Ideen für eine einzusetzende Software gesammelt sowie erste Voruntersuchungen zu Realisierungsmöglichkeiten angestellt ("Idealkonzept").

Planungsphase I:

In der Planungsphase I (auch Analysephase) geht es nur um die Erörterung des fachlichen Problems auf das sich die Software beziehen soll (hier: Zielsetzung), zudem wird eine Istzustandsanalyse hinsichtlich vorhandener Software durchgeführt.

Planungsphase II:

In dieser Phase wird u.a. das Projekt in einzelne Bestandteile zerlegt, eine Tätigkeitenliste erstellt und personenbezogene Ausführungszuweisungen getroffen. Zudem wird ein Pflichtenheft in Form einer Leistungsbeschreibung erstellt.

Realisierungsphase I:

Hier werden die Inhalte des Pflichtenhefts detailliert spezifiziert, dazu gehören Punkte wie Hinweise zur Bedienung der Software durch den Anwender, eine genaue Beschreibung der Software selbst, Festlegungen hinsichtlich Betriebssystem, Hardware, Datengrundlage usw. In diese Phase fällt auch die eigentliche Programmierung.

Realisierungsphase II:

In der zweiten Realisierungsphase wird der Probebetrieb vorbereitet und die Software getestet.

Einsatzphase:

In die Einsatzphase fällt nicht nur der endgültige Einsatz der Software, sondern auch die Softwarewartung.

Wie in Abbildung 2 zu sehen ist, setzt sich das Sechsphasenschema aus der Vorschlagsphase, den Planungsphasen, den Realisierungsphasen und der Einsatzphase zusammen. Diese Phasen setzen sich wiederum zusammen aus speziellen Vorgehensweisen, die sich zum großen Teil auch in den weiter unten näher ausgeführten Kompetenzfelder wiederfinden (siehe Abb. 6 in Abschnitt 2.2.2.3 - Bezüge der Kompetenzfelder zum Sechsphasenmodell).

In neuerer Zeit etablieren sich neben den linearen Phasenschemata auch iterative Modelle, bei denen der Entwicklungsprozeß von Software als ein Nebeneinander von Lern- und Entwicklungsprozessen zu sehen ist. Auf diese Modelle soll hier aber nicht näher eingegangen werden, da erstens das für diese Arbeit entwickelte Modell selbst einen iterativen Charakter aufweist und sich dadurch schon parallel laufende Lern- und Entwicklungsprozesse ergeben; zweitens soll der Bezug von fachlichen Inhalten zu den einzelnen Phasen des Softwareengineerings aufgezeigt werden, wozu ein lineares Modell wie das Sechsphasenschema aufgrund seiner klareren Strukturierung besser geeignet ist.

Softwareengineering ist also ein prozesshaftes, auf erprobter und wissenschaftlicher Grundlage basierendes strukturiertes Handeln, das weniger die Durchführung einer Softwareerstellung im Hinblick auf die Programmierung als vielmehr die gesamte (häufig multidisziplinäre^[21] ) Planung einer Software mit einschließt. Dies umfaßt nicht nur die Anwendung von und die Kenntnisse über (Computer-)Technik (z.B. die eigentliche Programmierung), Softwaremanagement, Implementierungen und die Anwendung technischer Prinzipien und Methoden sowie Qualitätssicherung, sondern auch Marketingstrategien und andere Gebiete, die hier aufgrund ihrer Vielfalt nicht abschließend aufgeführt werden können.

Softwareengineering macht deshalb auch häufig (fachübergreifende) Teamarbeit notwendig, wozu auch die im technischen Bereich häufig "soft-skills" genannten Fähigkeiten zur Teamarbeit und zur Reflexion des eigenen Tuns bei sich selbst und in der Gruppe gehören. Softwareengineering definiert sich also nicht durch die aus ihr resultierenden Programme, sondern durch ihre Arbeitsweise^[22].

Zusammenfassend läßt sich also sagen, daß Softwareengineering alle (wissenschaftlich begründeten) Handlungen und Fertigkeiten umfaßt, die für die Planung und Erstellung von Software notwendig sind.

2.1.2 - Klientenspezifisch:

"Spezifisch“ ist ein Merkmal dann, wenn es „zum Wesen einer Person, Sache oder eines Stoffes gehört und diesen allein eigen“ (Brockhaus 1998) sowie "kennzeichnend" (Duden 1982) ist.

Folgt man dieser Definition, so bedeutet der Begriff "spezifisch" im Hinblick auf einen Klienten, daß die "Merkmale" dieses Klienten ihm allein eigen sind und ihn als Produkt seiner ihm eigenen, persönlichen Sozialisation und Biographie kennzeichnen. Diese Merkmale können in ihrer Einmaligkeit durch die Gesamtheit oder Sequenzen seiner Biographie, eine Behinderung, ein Suchtverhalten, psychischer Indikatoren oder allein aufgrund besonderer Persönlichkeitseigenschaften oder einer fehlgeschlagenen Erziehung gegeben sein.

Klientenspezifisch soll hier aber nicht nur bezogen auf den einzelnen Klienten verstanden werden, sondern auch auf Klientengruppen (was von einer Heimgruppe über eine Kitagruppe bis hin zu Zielgruppen der Sozialen Arbeit, die gemeinsame Merkmale erfüllen^[23] und/oder für die eine ähnliche oder gleiche Zielsetzung^[24] gilt, reicht).

2.1.3 - Verfahren und Technik in Abgrenzung zum Begriff der Methode:

Die Begriffe Verfahren und Methode werden häufig sowohl in der Fachsprache wie auch in der Alltagssprache synonym gebraucht (so z.B. bei Tschamler 1983^[25], Gehrmann 1994^[26] oder Lattke 1961^[27] ). Für die hier vorliegende Arbeit soll dies aber nicht gelten – vielmehr soll das Verfahren von dem umfassenderen Begriff der Methode abgegrenzt werden.

Heiner (1995: 35^[28] ) definiert methodisches Handeln folgendermaßen: "Methodisches Handeln ist – definitionsgemäß – zielgerichtetes Handeln. Es folgt bestimmten Prinzipien und vollzieht sich in bestimmten Arbeitsschritten, bei denen Verfahren und Techniken berücksichtigt werden, die ... am besten geeignet sind, das erstrebte Ziel zu erreichen."

Folgt man dieser Definition, dann ergibt sich, daß ein Verfahren eben nicht eine Methode darstellt, sondern in eine Methode als untergeordnete Instanz integriert wird. Krauß (1996: 396^[29] ) definiert ähnlich:

"Methoden sind ... Handlungskonzepte zum beruflichen Umgang mit sozialen Problemen, die werthaft, wissenschaftlich und auf Berufserfahrung fußend begründet sind. ... Methoden sind abzugrenzen gegenüber Techniken/Verfahren/Interventionen; diese bezeichnen ... Verhaltensweisen, die im Dienst methodischen Handelns zur Erreichung ... [von] Ziele[n] stehen."

Auch Geißler/Hege (1988) unterscheiden aufgrund unterschiedlicher Komplexitätsgrade zwischen Methoden und Verfahren.

Techniken hingegen können bezeichnet werden als "relativ klar eingegrenzte Operationen zur gezielten Veränderung bzw. Beibehaltung eines Zustandes im Rahmen eines Handlungsplanes" (Brack 1997), im Gegensatz zu Geißler/Hege (1988: 29), die hier wiederum Verfahren und Techniken gleichsetzen.

Eine Technik ist aber auch "... Beherrschung der Mittel, um ein Ziel zu erreichen" (Brockhaus 2002). Gerade diese "Beherrschung der Mittel" weisen eher auf eine Art "handwerkliche" Intention hin, auf ein konkretes, praktikables und praxisbezogenes Handeln. Dahingehend läßt sich schlußfolgern, daß eine Technik

a.) der Methode und
b.) dem Verfahren

in ihrem Abstraktionsgrad und ihrer Zielgerichtetheit aufgrund ihrer spezifischen Ausrichtung auf eine oder mehrere ganz konkrete Handlungssequenzen untergeordnet ist.

Es ergibt sich aus dieser begrifflichen Trennung, daß Verfahren klar umrissene, zielgerichtete Handlungsstrategien sind, die im Rahmen einer Methode angewandt werden. Ihnen untergeordnet sind die Techniken. Daraus ergibt sich eine Ordnung von Begriffsklassen, die eine hierarchische Gliederung bzw. Strukturierung aufweisen:

Methode

- Verfahren
- Techniken

Um eine klare Strukturierung zu erhalten bietet es sich an, die Methode als eine Art Anwendungsfeld für (verschiedene, fachlich begründet ausgewählte) Verfahren anzusehen und diese wiederum als eine Art Container für verschiedene Techniken, die zur Zielerreichung des Verfahrens dienen, wobei die für die Methode ausgewählten Verfahren in ihrer Gesamtheit bei Erfolg auf die Zielerreichung der Methode rückkoppeln^[30].

[...]

---

^[1] Nach der Definition Brezinkas, 1976

^[2] Gürses 1999, Humboldt-Universität Berlin, vgl. http://www.informatik.hu-berlin.de/~guerses/main.html

^[3] Da jedoch schon Horaz und Kant den Appell sapere aude an den Menschen richteten, war kein hinreichender Einwand zu sehen, das hier besprochene Thema nicht trotzdem zu bearbeiten

^[4] Vgl. Jurgovsky, M., 2002: Was ist Sozialinformatik? In: Neue Praxis, H. 3, 32. Jg., S. 297-303.

^[5] In: Otto/Thiersch (Hrsg.) 2001: 339 ff

^[6] Vgl. Jurgovsky, M., 2002: Was ist Sozialinformatik? In: Neue Praxis, H. 3, 32. Jg., S. 297-303.

^[7] Dazu gehören rein nominell auch jene Autodidakten, die zwar über hinreichende Kenntnisse verfügen, aber keine anerkannte oder irgendwie bestätigte Ausbildung in diesem Bereich vorweisen können

^[8] Vgl. Plöger 1999: 26ff

^[9] Die auch der Selbstkontrolle und der Selbstkritik dienen sollen und somit vor "nichtlogischen Handlungen" schützen soll. Vgl. Brezinka in: Benden 1976: 47

^[10] Eine Forderung, die sich so mit hoher Wahrscheinlichkeit aufgrund internalisierter Handlungs- und Deutungsmuster, der eigenen Sozialisation des Operators usw. nicht in vollem Umfang verwirklichen lassen wird. Vielmehr soll hier ein Idealzustand beschrieben werden, der dennoch zumindest angestrebt werden kann

^[11] Diese Prämisse ist in dem bezeichneten Modell beispielhaft gemeint – in anderen Zusammenhängen können natürlich auch andere Schwerpunkte bzw. Bereiche angesprochen werden. Es erschien jedoch sinnvoll, hier konkrete Orientierungen anzusprechen, um die Bezüge zur Notwendigkeit der genauen Datenaufnahme und der Überlegungen zu Zielsetzungen aufzuzeigen

^[12] Z.B. von der Firma GMD auf der CeBIT 2000 (Haider/Oberhauser/Putzhuber 2003: 19)

^[13] Als billigere und auch häufig eingesetzte Alternative bei Computerspielen werden sog. "Shutter-Brillen" benutzt, die durch kleine eingebaute LCD-Monitore mit zumeist hoher Bildwiederholfrequenz ein räumliches Sehen ermöglichen. Vgl. http://www.mathematik.uni-marburg.de/~hesse/film/gruppe5/glossar.htm, nähere Angaben zur Technik u.a. unter http://www.rivastation.com/review/revelator/revelator_2.htm

^[14] VR = Virtual Reality = Virtuelle Realität

^[15] Software wird im allgemeinen in die Gruppen der Systemsoftware (z.B. Betriebssysteme) und der Anwendungssoftware unterteilt (Voss 1999). In der hier vorliegenden Arbeit bezieht sich der Begriff "Software" und Wortkonstrukte, die diesen Begriff beinhalten, auf die Gruppe der Anwendungssoftware

^[16] Zitiert nach Weber-Wulff, in: http://www.f4.fhtw-berlin.de/people/weberwu/inflex/se.htm, Jahr unbekannt

^[17] Häufig wird der Begriff des Softwareengineerings synonym zum deutschen Wort "Softwareentwicklung" gebraucht (so z.B. bei Voss 1999). Dies ist m.E. nach allerdings zu stark verkürzt, um die Gesamtheit der erforderlichen Handlungsschritte zu umschreiben, zudem fehlt der Bezug auf das geplante, "ingenieurmäßige", Handeln (wenn beide Begriffe zum großen Teil auch die gleichen Inhalte meinen). Aus diesem Grund wird in der vorliegenden Arbeit ausschließlich das englische "Softwareengineering" benutzt

^[18] Diese Definition unterscheidet zwischen einzelnen Programmen und ganzen Anwendungssystemen (andere Autoren sprechen hierbei z.B. von "größeren Softwareprojekten", ohne eine klare Grenze zu ziehen zwischen "größeren" und eben "kleineren" Projekten). Dem kann entgegen gehalten werden, daß diese Unterscheidung sich nicht auf die Komplexität eines Softwareprojekts stützt, sondern lediglich auf die berufliche Qualifikation der Beteiligten (vgl. Entchelmeier/Gottwald 2001: 18 ff.). Eine solche Unterscheidung bietet somit keinen tatsächlichen qualitativen Wert und wird deshalb in dieser Arbeit nicht weiter berücksichtigt, da es unsinnig wäre anzunehmen, daß eine Person als Nicht-Informatiker zumindest auf der Planungsebene nicht ebenso geplant und systematisch vorgehen könnte, insbesondere bei z.B. Istzustandsanalysen von Software hinsichtlich der Usability usw., worauf weiter unten noch näher eingegangen wird

^[19] Vgl. Broy, M., in: http://www4.in.tum.de/lehre/vorlesungen/sw_engineering/SS2001/, 2001

^[20] Die benutzten Grafiken sind selbst erstellt, so daß kein Abbildungsnachweis notwendig ist

^[21] Bei der Planung, Entwicklung und Anfertigung von Lernsystemen, Spielen oder kommerziellen Softwarepaketen sind nicht nur Informatiker und Programmierer beteiligt, sondern häufig auch Psychologen aus den verschiedensten Fachgebieten, Soziologen, Grafiker, Musiker, Wirtschaftswissenschaftler, Juristen usw. je nach Art der entstehenden Software und ihrer Zielgruppe. Im therapeutisch-diagnostischen Bereich natürlich auch Mediziner und verwandte Berufe

^[22] Vgl. Klüver in: http://www.fh-augsburg.de/informatik/vorlesungen/se1t/

^[23] Das könnte z.B. die Gruppe der erwerbstätigen Sozialhilfeempfänger sein, deren gemeinsame Merkmale

der Status des Sozialhilfeempfängers und

die Tatsache der Erwerbstätigkeit sind

^[24] Ein Beispiel könnte hier die Gruppe der wahrnehmungsbeeinträchtigten Kinder im Kindergartenalter sein, die natürlich nicht alle die gleiche Kindergartengruppe besuchen müssen

^[25] In: Hobmair 1996: 16

^[26] Hier allerdings bezogen auf einen Forschungsgegenstand in einer (noch näher zu bestimmenden) Sozialarbeitsforschung

^[27] In: Galuske 2001: 36

^[28] In: Galuske 2001: 31

^[29] In: Galuske 2001: 32

^[30] Ein einfaches Beispiel befindet sich zur weiteren Verdeutlichung im Anhang