Agile Software Development

Größe: px
Ab Seite anzeigen:

Download "Agile Software Development"

Transkript

1 Software Engineering Projekt Wintersemester 2003/2004 Freitag, 12. Dezember 2003 Agile Software Development Lehrveranstalter: Dr. Stephan Herrmann Autor: Marcel Kulicke

2 Inhaltsverzeichnis Einleitung... 3 Zentrale Problematik... 4 IT Projekte scheitern... 4 Das Hauptproblem... 4 Methoden... 5 Crystal Methodologies... 5 Adaptive Software Development... 8 extreme Programming...12 Zusammenfassung...16 Schluss...17 Quellenverzeichnis...18 Bü cher:...18 Artikel und wissenschaftliche Arbeiten:...18

3 Einleitung Softwareentwicklung der heutigen Zeit erreicht eine immer größere Komplexitä t. Bisherige Methoden und Prozesse zur Unterstü tzung der Softwareentwicklung sind zum größten Teil statisch und in klar gegliederte Phasen aufgeteilt. In jeder Phase sind bestimmte Maßnahmen, wie Design, Implementierung oder Test, durchzufü hren. Zentral in fast allen Methoden ist die Anforderungsdefinition oder auch Pflichtenheft. Hier werden die Aufgaben an das zu erstellende System definiert. Je nach angewandtem Prozess zur Entwicklung der Software wird der Auftraggeber in die Erstellung dieses Dokuments eingebunden. Im gü nstigsten Fall werden alle Aufgaben von diesem Dokument erfasst und spä ter implementiert. Der Kunde oder Auftraggeber erhä lt nach der Implementations- und Testphase das fertige Produkt. Wie die Erfahrung zeigt ist dieser Ansatz nicht falsch. Ist das Einsatzgebiet der Software klar umrissen oder hat die Firma viel Erfahrung mit Software in dem Bereich so sind diese Praktiken erfolgreich (vgl. [1], Kapitel Introduction). Doch mehren sich Probleme bei Softwareentwicklungen bei denen diese Vorbedingungen eben nicht erfü llt sind. Oft mü ssen Softwarefirmen unter hohem Konkurrenzdruck und in einem Bereich Software entwickeln, in dem sie keine Erfahrung besitzen. Oft hat der Auftraggeber selber keine klare Vorstellung von dem zu erstellenden System oder seine Vorstellungen stimmen nicht mit dem zurzeit technisch machbarem ü berein. Vielleicht ä ndert sich seine Vorstellung vom oder sein Anspruch an das System wä hrend dessen Entwicklungszeit. Und woher weiß ein Unternehmen, dass Software fü r eine Vielzahl von unbekannten Kunden entwickelt eigentlich, dass ihre Gedanken ü ber die Software mit dem Ü bereinstimmen was die Mehrheit der Kunden will? Agile Software Development setzt genau bei diesen Vorraussetzungen an. Es soll einen Ansatz und eine Methodik liefern um in Bereichen Software entwickeln zu können von denen unklare und sich verä ndernde Vorstellungen beim Auftraggeber und/oder beim Softwareteam oder den spä teren Kunden existieren. Im Rahmen dessen wird vor allem auf den Begriff der Agilitä t eingegangen. Anstatt einen Prozess in mehrere Phasen zu unterteilen und sich damit an eigentlich starre Einteilungen zu halten wird der gesamte Prozess in Iterationsschritte eingeteilt die sich fortwä hrend wiederholen und so eine Korrektur bei jeder Iteration erlauben. Verbunden mit verä nderten Methoden zur eigentlich Programmentwicklung und eine Fokussierung der Kommunikation zwischen den Programmierern und zwischen den Programmierern und den Kunden soll der gesamte Entwicklungsprozess qualitativ hochwertiger, schneller und nä her an den Wü nschen des Kunden liegen. Um dieses hehre Ziel zu erreichen existieren mehrere Methodiken von denen hier nur drei der bekanntesten erlä utert werden sollen. Den Anfang machen die Crystal Methodologies, eine Sammlung von agilen Methoden zur Softwareentwicklung in verschiedenen Projekt- und Firmengrößen. Diese Sammlung orientiert sich je nach Größe und Bedeutung der zu entwickelnden Software weiter oder nä her an bekannten statischen Methoden. Folgend wird das Adaptive Software Development beschrieben. Diese Methode wird unter anderem bei der Firma Microsoft eingesetzt und ist ein stark evolutionä rer und philosophischer Ansatz ohne konkrete Anleitungen zur Durchfü hrung. Den Schluss bildet die jü ngste Methode: extreme Programming (XP). Hier wird das Hauptaugenmerk auf Kommunikation und den Code als Zentrum des Interesses gelegt. XP sei hier als letzte Methode aufgefü hrt, weil es einen Mix aus den beiden vorangegangenen Methoden bildet. Wä hrend Crystal eher Beispiele und Regeln zur Anwendung gibt und damit ein wenig seiner Agilitä t einbüßt, ist Adaptive Software

4 Development gä nzlich ohne Regeln und damit zwar ä ußerst agil im Sinne von anpassbar aber ohne konkrete Beispiele und Hilfen fü r diejenigen, die es einzusetzen gedenken. Zentrale Problematik IT Projekte scheitern Das größte Problem bei Softwareprojekten ist deren Hä ufigkeit des Scheiterns. Eine von der Standish Group 1995 durchgefü hrte Studie untersuchte IT-Projekte und die Anzahl der Fehlschlä ge sowie die Grü nde dafü r (vgl. Abbildung 1). Ein Projekt ist laut DIN ein komplexes Vorhaben, dass [ ] Zielvorgaben [ ], personelle, sachliche, finanzielle und zeitliche Abgrenzung[en] gegenü ber anderen Vorhaben [besitzt] [ ] [und durch die] Einmaligkeit der Bedingung gekennzeichnet ist. Aus diesem Zusammenhang ergibt sich eine Fü lle von möglichen Problemen, die zu einem Scheitern des Projektes fü hren können. Als hä ufigster Grund fü r das Scheitern werden unklare oder unvollstä ndige Anforderungen angefü hrt. Eine Schwierigkeit bei der Entwicklung eines Softwareprodukts ist die Ü bereinstimmung des Aussehens und der Funktionalitä t mit den Vorstellungen des Kunden darü ber. Oft wird wä hrend der Entwicklung wert auf Funktionalitä t seitens der Entwickler und Designer gelegt, die fü r den Kunden nur von minderer Bedeutung sind. Oft werden die wichtigen Funktionalitä ten gar nicht implementiert und das fertige Produkt entspricht somit nicht dem Anspruch des Kunden. Typ I: Projekt wurde abgebrochen 31.1 % Typ II: Projekt nach Plan fertig gestellt 16.2 % Typ III: Projekt nicht im Kosten- und Zeitrahmen fertig gestellt 52.7 % Abbildung 1: Ende von Projekten. Quelle: [5] Das Hauptproblem Das Hauptproblem der Softwareentwicklung ist unabhä ngig von den angefü hrten Ursachen folgendes: Software development fails to deliver, and fails to deliver value. This failure has huge economic and human impact. We need to find a new way to develop software. [Kent Beck, Extreme Programming Explained, Chapter 1. Risk: The Basic Problem[1]]

5 Beck beschreibt in seinem Buch die Notwendigkeit eines neuen Weges zur Entwicklung von Software. Auf wenn sein Buch primä r die Praxis des extreme Programmings beschreibt, so sind die Probleme allgemein fü r alle Methoden. Eine der Hauptkomponenten der agilen Methoden ist die Reaktion. Man geht von einem ganz spezifischen Umfeld aus, in dem die Software entwickelt wird und in welchem die statischen Methoden schnell an ihre Grenzen stoßen. Dieses spezifische Umfeld ist gekennzeichnet durch hohen Druck auf Seiten der Entwickler. Dieser Druck entsteht durch mangelnde Zeit und viel Konkurrenz. Hinzu kommt mangelnde Erfahrung in dem Bereich fü r den die Software entwickelt werden soll. Um diesem Problem zu begegnen entschied man sich die statischen Abgrenzungen bisheriger Modelle zur Softwareentwicklung zu entfernen (vgl. V-Modell, Spiralmodell, usw.). Es gilt Flexibilitä t zu erreichen. Es möglich sein schnell auf Ä nderungen seitens des Kunden oder verä nderte Rahmenbedingungen reagieren zu können und diese mehr oder weniger unkompliziert in das bestehende Produkt einzufü gen. Als ein Mittel dazu wird zum Beispiel bei den meisten agilen Prozessen die Zeit fü r die Anforderungsanalyse auf ein Mindestmaß verkü rzt um gerade genug Informationen zu erhalten um mit der eigentlichen Entwicklung anfangen zu können. Wä hrend der Entwicklungsphase wird das Programm erweiterbar gestaltet. Es soll zu spä teren Zeitpunkten möglich sein, weitere Funktionalitä t hinzuzufü gen ohne das komplette Programmdesign verä ndern zu mü ssen. Nachdem die definierten Anforderungen implementiert sind, wird das Produkt dem Kunden vorgelegt. Dieser entscheidet dann anhand des konkreten Prototyps, ob das Produkt seinen Gedanken entspricht. Diese Abschnitte werden als Iterationen bezeichnet. Jede Iteration ist dabei einem Entwicklungszyklus gleichzusetzen und soll als Ergebnis eine release-fä hige Version des Produktes bereitstehen. Dieses Vorgehen ist allgemein fü r alle drei hier vorgestellten Methoden. Allerdings variieren die Methoden in der Dauer der Iterationen und dem Ablauf eines Projektes mit der jeweiligen Methode. Methoden Crystal Methodologies Die Crystal Methoden entstammen Alistair Cockburn und Jim Highsmith [3]. Im Grunde sind sie aus dem Rational Unified Process [3, Seite 165] entstanden. Das Problem dabei war die notwendigen Anpassung. Das Problem bei Methoden der Softwareentwicklung ist das Fehlen einer allgemeinen und richtigen Lösung. In Ermangelung dieser Lösung muss eine Methode dem Projekt angepasst werden. Idealerweise erfolgt diese Anpassung in der Weise, dass sich die Methode dem Projekt anpasst und nicht umgekehrt. Doch genau in diesem Punkt ergaben sich beim Rational Unified Process immer wieder Probleme, weil eine Anpassung nicht erfolgte. Notwendige Anpassung Nach Cockburn erfolgt diese Anpassung durch die Manager und das (Entwickler-)Team. Doch leider wird diese Anpassung durch die Manager meistens angeordnet. Die Entwickler bekommen dann die Arbeitsprojekte des Prozesses und die Anweisung diese auszufü hren. Mit zwei möglichen Folgen. Entweder die Entwickler denken die Befolgung dieser Anweisung schä digt das Projekt und ignorieren diese folglich oder sie befolgen die Anweisung und schä digen das Projekt.

6 Dieses Verhalten wird auf die Art des Rational Prozesses zurü ckgefü hrt. Daher entwickelte Cockburn einen zweiten Ansatz: Die Crystal Methodologies. Sie sollten genau diese beschriebene Schwä che ausgleichen. Dazu soll eine Menge von konkreten Beispielmethoden vorgegeben werden, die anpassbar sind. Bei der Sammlung dieser Beispiele gingen Cockburn und Highsmith nach best practices vor. Sie schauten sich aus der Fü lle der agilen Methoden diejenigen an, die sowohl die Kommunikation als auch den Gemeinschaftssinn als Basis nutzten und erfolgreich eingesetzt wurden. Aus diesen Methoden entnahmen sie Beispiele. Diese Beispiele sollten die Nutzer der Crystal Methoden als Startpunkte und weiter verfeinerbare Ansä tze nutzen. Durch mehrere erfolgreiche Beispiele kann ein Team jene auswä hlen, die am besten auf die spezifische Situation passen und diese dann weiter anpassen oder nutzen. Im Fokus liegt hierbei das konkrete Beispiel das die Nutzung und Implementierung einer agilen Methode fü r ein Projekt einfach gestalten soll. Die Crystal Methodologies dienen damit als eine Art Baukasten fü r agile Methoden. Dies ist zugleich ihre Hauptkritik, denn mit der Vorgabe konkreter Beispiele wird eher eine andere Art von statischer Methode erreicht. Dies schrä nkt die Agilitä t ein. Auswahl der Methode Implizit gehen die Crystal Methoden davon aus, dass Projekte mit vielen Programmierern mehr Verwaltungsaufwand bedeuten und somit die Flexibilitä t einschrä nken. Aufgrund dieses Faktes bieten die Methoden konkrete Beispiele fü r verschiedene Größenordnungen von Softwareprojekten. Zusä tzlich wird davon ausgegangen, dass es verschieden schwere Folgen haben kann, wenn Projekte scheitern. Daher wird die Agilitä t und damit auch die Flexibilitä t umso mehr eingeschrä nkt, je folgenschwerer ein Fehler in dem aus dem Softwareprojekt resultierenden Programm ist. Im Endeffekt liegt dem der Gedanke zugrunde, dass Programme deren Fehlverhalten Leben gefä hrden kann nicht mit agilen Methoden entworfen und programmiert werden sollten. Die agilen Methoden haben immer einen - mehr oder weniger ausgeprä gten - Iterationsgedanken. Dieser bedingt, dass ein Programm nach jedem Iterationsschritt verbessert wird. Daraus ergibt sich die Möglichkeit eines Fehlers. So ein Fehler wird folgend im nä chsten Iterationsschritt behoben. Bei sicherheitsrelevanten Programmen in Flugzeugen oder Kraftwerken darf ein Programm aber keinen schwerwiegenden Fehler enthalten. Daher ist ein Einsatz agiler Methoden in diesen Bereichen nicht möglich. Als Ergebnis dieser Ü berlegungen kommt eine Matrix zustande, die in Abbildung 2 dargestellt ist. Wie erwä hnt werden die Projekte in Hä rtegrade eingeteilt. Die y-achse dient hierzu. Je folgenschwerer ein Fehlerfall der entwickelten Software sein kann, desto höher liegt dessen Einteilung in der y-achse. Dabei wird in vier Kategorien entschieden. Gefä hrdet ein Fehler Leben, wie zum Beispiel in einem Flugzeug, so ist die Kategorie L. Bedeutet ein Fehler den Verlust von Geldern die essentiell fü r das Unternehmen sind, so ist die Kategorie E. Wird im Fehlerfall lediglich Geld verloren, so ist die es D. Ist ein Fehler nur unkomfortabel, so gilt die niedrigste Kategorie C. Die x-achse bezeichnet die Anzahl der an dem Projekt beteiligten Programmierer.

7 Hä rtegrad L6 L20 L40 L80 E6 E20 E40 E80 Legende: D6 D20 D40 D80 Ein Fehler bedeutet Verlust von: - Life (L) - Essential Money (E) - Discretionary Money (D) - Comfort (C) C6 C20 C40 C80 Clear Yellow Orange Red # Programmierer Abbildung 2: Matrix der Crystal Methodologies In dieser Matrix kann man nun einen Typ von Methode auswä hlen, die zum spezifischen Projekt passt. Diese sind: - Crystal Clear, - Crystal Yellow, - Crystal Orange, - Crystal Red, - Crystal Magenta, - Crystal Blue, - Crystal Violet, - Usw. Hierbei nutzt Cockburn eine Analogie. Ein Kristall (Crystal) ist im Normalfall klar (clear). Diese Klarheit steht bei den Crystal Methoden fü r die Agilitä t der zu nutzenden Methode. Je dunkler der Kristall ist, desto weniger agil ist die Methode. Wä hrend Clear also die agilste Methode ist, nimmt diese Agilitä t zunehmend ab, bis sie schließlich in der letzten Methode violett geworden ist. Es existieren noch weitere Methoden in der Crystal Familie ausser Clear, Yellow, Orange oder Red. Diese sind fü r größere Projekte als Red vorgesehen und werden hier der Ü bersicht halber ausgelassen. Kern aller Methoden Im Folgenden werden hier nur die Gemeinsamkeiten der Methoden vorgestellt. Die eigentlichen Methoden unterscheiden sich größtenteils durch zusä tzliche Rollen und vorgeschriebene Dokumente, aber nicht in ihrer Grundphilosophie. Fü r weitergehende Informationen sei dem interessierten Leser Agile Software Development [3] empfohlen. Die angefü hrten Methoden sind dabei genau fü r die spezifischen Projekttypen vorgesehen und nicht zueinander kompatibel. Beginnt ein Projekt zu wachsen oder zu schrumpfen ist eine Anpassung von zum Beispiel Orange zu Red nicht sinnvoll. In einem solchen Fall empfiehlt Cockburn eine komplette Adaption der passenden Methode (Red im Beispiel). Der Kern einer jeden Crystal Methode ist die Philosophie:

8 Software development is usefully viewed as a cooperative game of invention and communication, with the primary goal of delivering useful, working software, and the secondary goal of setting up for the next game (Cockburn, 2001, [3] Seite 166) Als Folge dieser Philosophie ergeben sich 2 Aussagen. Zwei verschiedene Projekte mü ssen zum Erreichen der sinnvollen Software auch verschieden gefü hrt werden und die Menge der erforderlichen Kommunikation variiert in jedem Projekt. Es wird soviel Kommunikation benötigt, wie eben notwendig ist um das Spiel gemeinsam voranzubringen. Dies bedingt, dass die Personen die so zusammenarbeiten die gleichen oder sehr ä hnliche Wertvorstellungen haben mü ssen und die Methoden dadurch sehr auf Personen und Kommunikation zentriert sind. Daher wird in den Crystal Methoden implizit von den Beteiligten eine gemeinsame Grundlage gefordert. Diese ist bei den anderen hier vorgestellten Methoden zwar auch vonnöten wird allerdings nicht so explizit gefordert. In jeder Methode gelten darauf aufbauend sieben Prinzipien: - Ein Team kann den Gesamtaufwand an Arbeit reduzieren, in dem es öfter laufenden Code produziert und die Kommunikation intensiviert. Dadurch werden Missverstä ndnisse anhand konkreter Implementierungsprobleme frü her und detaillierter sichtbar und Probleme können durch Kommunikation meistens in Form von einfachen Fragen frü her geklä rt werden. - Jedes Projekt ist unterschiedlich und entwickelt sich wä hrend seines Fortschreitens weiter. Daher mü ssen sich auch die Konventionen, auf die sich jedes Team bezü glich Coderichtlinien und Kommunikation geeinigt hat, weiterentwickelt werden, damit sie noch mit dem Projektstand korrespondieren. - Engpä sse im Entwicklungssystem sind ein Indikator fü r gleiche und damit redundante - Tä tigkeiten und stecken gebliebene Informationen. - Das Projekt wird inkrementell gebildet. Dabei sollte alle idealerweise 1-3 Monate ein Release erfolgen, welches dann sukzessive um Funktionalitä t erweitert wird. - Ein Team hat vor und nach jedem Release einen Workshop zu halten in dem die Erwartungen in und die Erfahrungen aus dem Release gezogen werden. - Ein Team legt vor Beginn des Projekts eine Basis-Methode aus der Matrix (siehe Abbildung 2) fest und transformiert diese in eine Start-Methode fü r das Projekt. Folgend wird die Start-Methode weiterentwickelt um auch weiterhin zum Projekt zu passen. - Die Workshops sind nach einer vorher festzulegenden Art zu erfolgen. Anhand dieser Grundprinzipien teilen sich die konkreten Beispiele fü r die jeweiligen Projektgrößen und hä rten auf und erlauben so eine Anpassung. [3] Adaptive Software Development Diese Methodik ist auf Jim Highsmith[2, 4] zurü ckzufü hren. Die Softwareentwicklung wird darin in zwei Wege einen traditionell-linearen und einen neuen-nichtlinearen geteilt. Zwei Welten Der traditionelle Weg beruht auf den Grundlagen des Managements. Dieser Teil wird in Highsmith s Theorie von der Physik abgeleitet und basiert auf den Prinzipien der Stabilitä t und Vorhersagbarkeit. Dabei basiert Highsmith Ansatz darauf, dass Software in den meisten statischen Modellen auf der Annahme der Vorhersagbarkeit basiert. Wenn ein Unternehmen Software entwickelt, so geht es implizit bei der Feststellung und Dokumentation der Anforderungen davon aus, dass die gemachten Aussagen zutreffen und sich das Produkt sicher mit diesen Aussagen herstellen bzw. programmieren lä sst. Man wagt dabei eine Art Vorhersage.

9 Die zweite Welt ist durch ihr Chaos und ihre Schnelligkeit gekennzeichnet und basiert auf der Theorie der komplexen adaptiven Systeme. Diese stü tzt sich vor allem auf die Teilung aller komplexen Systeme in einzelne Agenten. Die Agenten handeln autark aber in einem Verband mit anderen ebenfalls unabhä ngigen Agenten. Aus dem unabhä ngigen und adaptiven Handeln der einzelnen Agenten ergibt sich das System. Die Komplexitä t des Systems ergibt sich aus der Anzahl der Agenten. Mangelnde Vorhersagbarkeit Dem Hintergrund der zutreffenden Vorhersagbarkeit der linearen Welt widerspricht Highsmith im Bezug auf die Softwarebranche. Sein Hauptargument ist Druck. Es existiert ein immenser Konkurrenzdruck bei den Unternehmen. Diesem Druck kann eine Firma mit herkömmlichen Praktiken nicht standhalten. Diese Aussage grü ndet sich auf die Gleichheit der Konkurrenten. Besonders in der Computerindustrie sind sich die Konkurrenten in wichtigen Punkten, wie zum Beispiel Ausrü stung und Human Ressources zu ä hnlich, um darauf aufbauend einen objektiven Vorteil vor dem anderen Konkurrenten ziehen zu können. Das Ursache -> Wirkung Prinzip in der Softwareentwicklung Lange Zeit galt daher das sog. Wasserfallmodell als der dominanteste Standard fü r die Entwicklung von Software (vgl. Abbildung 3). Plan Build Implement Abbildung 3: Eine Art des Wasserfallmodells [2, 4] Problematisch an diesem Modell ist die Komplexitä t des zu entwickelnden Systems. In vielen Systemen ist der Zusammenhang zwischen der Ursache und der resultierenden Wirkung nicht ohne weiteres ersichtlich. Wenn also in der Planung davon ausgegangen wird, dass man die zu erfü llenden Bedingungen kennt und diese modellieren kann, so dass das resultierende System genau diese Bedingungen erfü llt, dann handelt man nach einer Ursache -> Wirkung -> Ergebnis Konstellation aus. Die Bedingung (Ursache) bedingt das Design (Wirkung) welches als Ergebnis die Bedingung erfü llt. Dies ist hä ufig jedoch nicht gegeben. Highsmith geht so weit zu sagen, dass ein solcher Zusammenhang in komplexen Systemen nicht herstellbar ist. Als Folge davon verdanken wir heute viele veraltete Systeme diesem Entwicklungsmodell. Rapid Application Development Daher wurden andere Modelle geschaffen, die diesen Fehler ausgleichen sollten. Rapid Application Development ist eine dieser Methoden, die letztendlich zum Adaptive Software Development weiterentwickelt wurden.

10 In Grunde tauschte man den statischen Verlauf einer Anwendungsentwicklung nach dem Wasserfallmodell gegen ein sich wiederholendes System, wie in Abbildung 4 dargestellt (aus [2]). Plan Build Revise Abbildung 4: Entwicklung nach der Rapid Application Development Methode [2, 4] Und genau hier beginnt nach Highsmith der zweite Weg. Basierend auf dem Ursache -> Wirkung -Prinzip sind die Wirkungen in der Softwareentwicklung unvorhersagbar. Dieser Umstand fü hrt daher den Planungsprozess ad absurdum, denn wenn die Wirkung unvorhersagbar ist, kann man sie nicht vorher bestimmen. Daher erweiterte er das Modell des Rapid Application Development zum Adaptive Software Development. Adaptive Software Development sieht in den Phasen somit wie in Abbildung 5 aus: Speculate Collaborate Learn Abbildung 5: Phasen des Adaptive Software Development [2, 4] 1. Speculate Statt der Planung spekuliert man ü ber das Ziel und versucht es so zu treffen. Als Analogie ist der Schnellschuss beim Schiessen angebracht, bei dem der Schü tze nur kurz anvisiert und möglichst schnell feuert, anstatt lange zu zielen. So ein Schnellschuss macht im Bereich der Softwareentwicklung Sinn, denn: following a plan produces the product you intended just not the product you need (Highsmith, 1997 [4])

11 Bei einer detaillierten Planung können nur schwierig neue Gesichtspunkte und Technologien in das Projekt eingebracht werden, falls diese erst nach der Planung bekannt werden. Auf diesem Fakt baut Adaptive Software Development auf. Der erste Punkt ist eine Spekulation, eine Art Schnellschuss oder nicht so detaillierte Planung. Dies soll keinesfalls heißen, dass man nicht plant. Es ist aber eine Abschwä chung der Planung. Anstatt alles bis in das kleinste Detail zu spezifizieren einen Plan zu machen erstellt man eine Art generelle oder auch allgemeine Idee welche Richtung man zu gehen gedenkt. Den konkreten Weg gibt man nicht vor. Auf diese Weise bleibt der Prozess flexibel und anpassbar. 2. Collaborate Der zweite Punkt im Adaptive Software Development ist die Kollaboration. Das Designen oder Bauen (in Anlehnung an Rapid Application Development) ist auf die Ausfü hrung des vorher geplanten ausgerichtet. Dies beinhaltet die Kontrolle oder Ü berwachung der vorher festgelegten Ziele. Allerdings ist festgestellt worden, dass sich die Wirkung, die die Ziele erreichen wollen und sollen eben nicht vorhersagbar ist. Dadurch wird auch jede Kontrolle belanglos. In diesem Kontext ersetzt Highsmith die Kontrolle im traditionellen Kontext des Projektmanagements durch zwei Teile. Zunä chst sollte das Projektmanagement entscheiden, welche Teile des Projekts vorhersagbar und damit planbar sind. Dies betrifft vor allem Teile die als sicher gelten. So ist bekannt, dass ein Softwareprojekt ohne Möglichkeiten zur Konfiguration nicht möglich ist. Hat man beide Teile identifiziert und die vorhersagbaren Teile durch bekannte Methoden des Projektmanagements unter Kontrolle, so kann man die unvorhersagbaren Teile angehen. Solche Teile sind zum Beispiel die Wü nsche des Kunden, die der Kunde hat, aber vielleicht aus mangelndem technischem Verstä ndnis nicht ä ußern kann. Genau solche Dinge kann niemand vorhersagen. Nach Highsmith können gerade solche verdeckten Anforderungen aber durch Kollaboration im Team erkannt und geklä rt werden. Das Schlü sselwort in diesem Kontext heißt Kreativitä t. Die Probleme sind durch Kreativitä t im Team zu lösen. Dazu braucht es allerdings ein dies unterstü tzendes Umfeld. Wie schon Eingehens erlä utert gibt es zwei Welten eine stabile und eine chaotische. Wä hrend die erste durch Vorhersagbarkeit bestimmt ist, gilt dies in der anderen Welt nicht. Genau im Ü bergang zwischen der einen und der anderen Welt liegt die Kreativitä t und damit der Schlü ssel zur Erkennung und Lösung der nicht kontrollierbaren Teile. Das Ziel ist neben der Kontrolle der sicheren Anforderungen ein Umfeld zu schaffen, welches Kreativitä t fördert und die Beteiligten in einer gewissen Unwissenheit ü ber den weiteren Weg lä sst. Im Zusammenhang mit Kommunikation kann man so wirkliche Kreativitä t fördern und zu Lösungen kommen, die in einem streng kontrollierten Umfeld nicht möglich sind. 3. Learn Den letzten Teil in Highsmith s Adaptive Software Development bildet das Lernen. Nachdem man ü ber die Ziele spekuliert hat und sie in Kollaboration mit allen Projektmitgliedern versucht hat zu lösen, schaut man sich das Ergebnis in der Realitä t an. Diese Realitä t können das Release und der Verkauf eines Produkts als auch einfach eine Vorfü hrung bei einem Kunden sein. Wichtig ist hierbei ein Feedback ü ber das Ergebnis der ersten beiden Schritte. Sinn dieses Schrittes ist eine Art lessons learned -Dokument, welches Aufschluss ü ber den Erfolg des gemachten gibt.

12 Ausgestattet mit diesem direkten Feedback spekuliert man von vorne und verbessert sein Produkt stä ndig um so immer nä her an den teils unbewussten Vorstellungen des Kunden zu sein. Die Evolution als Vorbild Dieser doch recht philosophische - Ansatz ist Highsmith s Ableitung aus der Natur oder genauer der Evolution. Diese verfolgt einen gleichen Ansatz. Eine neue Art entsteht und entwickelt sich von Generation zu Generation weiter. Sie passt sich ihrer Umgebung stä ndig an ist adaptiv. Analog dazu definiert Highsmith die Kunden als die Umwelt in der sich die Art das Produkt bewä hren muss und sich fortwä hrend auf neue Rahmenbedingung einstellen muss. Mit jeder Produktgeneration erfolgt eine weitere Verfeinerung und Anpassung auf die Umwelt. Erfolgt die Anpassung nicht, so stirbt die Art also das Produkt aus, weil es in der Umwelt nicht mehr ü berleben kann. Microsoft Process Als Beispiel fü r eine erfolgreiche Anwendung von Adaptive Software Development ist Microsoft angefü hrt, wodurch diese Methodik auch den Beinamen Microsoft Process bekommen hat. Vergleicht man die Entwicklung von beliebigen Microsoft-Produkten so fä llt auf, dass die ersten Version kaum Erfolg in ihrem Bereich hatten und meistens belä chelt wurden. Mit jeder weiteren Version verbesserte sich die Akzeptanz des Funktionsumfangs beim Kunden. Bei spä teren Versionen erreichte Microsoft oftmals eine unumstrittene Marktfü hrerschaft fü r das Produkt. Interessierte Leser mögen sich den Verlauf der Entwicklung des Microsoft Office Suites anschauen und werden diesen Effekt feststellen. Der Effekt wird direkt aus der Anwendung des Adaptive Software Developments abgeleitet. extreme Programming extreme Programming ist eine leichtgewichtige Art der Software Entwicklung. Sie basierend auf: - Einfachheit, - Kommunikation und - Feedback und wurde von Kent Benk [2] 1999 entwickelt. Extreme Programming wurde zur Anwendung in kleinen Entwicklerteams von 2-10 Programmierern erdacht, die in einem Umfeld sich schnell ä ndernder Anforderungen Lösungen entwickeln mü ssen [5]. XP ist ä hnlich den Patterns der Gang of Four keine fest definierte, statische Anwendung, sondern vielmehr eine best practice, also das Ergebnis bewä hrter Erfahrungen. Dabei hat man die einzelnen Erfahrungen vieler Programmierer ausgewertet und ü bernommen um sie folgend ins Extrem zu treiben. Dadurch entstand der Beiname extreme. Keine der Methoden in XP ist neu. Die Programmierstrategien sind seit Jahren bekannt. Das neue an XP ist die Zusammenfü hrung dieser einzelnen Methoden. Durch diese Zusammenfü hrung will man Synergien nutzen. Sie entstehen durch den Einsatz der

13 Methoden nebenbei. Da zum Beispiel das Planning Game Kommunikation zwischen dem Kunden und den Entwicklern unterstü tzt hilft es auch bei der spä teren Implementation durch Pair Programming, weil die bereits vorhandene - Kommunikation dort weiter intensiviert wird. In seinem Buch Extreme Programming Explained [1] beschreibt Beck die Entstehung von extreme Programming anhand einer Geschichte. The Mountain People vs. The Forest People. Auf der einen Seite stehen die Menschen aus einer Bergregion, karg und mit wenig Nahrung und vielen Gefahren. Auf der anderen Seite sind die Waldmenschen, die wenige Gefahren haben und Ressourcen im Ü berfluss. Die Bergmenschen stellen in dieser Geschichte den herkömmlichen Weg der Softwareentwicklung dar. Gekennzeichnet ist dieser Weg durch mangelnde Ressourcen in Form von Programmierern und Zeit und viele Gefahren in Form von weiteren Kundenwü nschen und Deadlines. Diese Geschichte ist ein Beispiel fü r den Kontrast zwischen den bisherigen Standard aus Deadlines und nicht zu erfü llenden Anforderungen und der Frage: Wie wü rde man Programmieren, wenn man Waldmensch wä re?. Man wü rde Tests schreiben und mit anderen Programmierern reden anstatt Deadlines zu halten. Man wü rde sich den Code öfters anschauen um vermehrt bad smells herauszufinden und den Code stä ndig verbessern. Man wü rde bei Unklarheiten nachfragen und sie klä ren. Man kann diese Liste beliebig weiterfü hren. Es sei nur als Hintergedanke zur Entstehung der XP-Methode gegeben. Allerdings ist XP keine statische Methodik sondern vielmehr eine Menge von Regeln, die an ein bestimmtes Team angepasst werden kann und sollte. Regeln Neben dem Eingehens erwä hnten Grundgedanken gibt es insgesamt 12 Schlü sselpraktiken zur Anwendung fü r extreme Programming. Mit diesen Punkten ist das Prinzip des extreme Programmings vollstä ndig erklä rt: - Planning Process Wird auch als Planning Game bezeichnet. Der Auftraggeber setzt den business value der gewü nschten Funktionalitä t und lä sst die Kosten der Funktionalitä t durch die Programmierer schä tzen. Aus der Schä tzung wä hlt der Auftraggeber die Funktionalitä t aus, die implementiert werden soll und welche Funktionen nicht implementiert werden sollen. Der gewü nschte Effekt ist eine Möglichkeit das Projekt zum Erfolg der Ü bereinstimmung des Implementierten mit den Wü nschen des Kunden - zu steuern. - Small Releases Das XP-Team baut frü h ein kleines Release und erweitert es permanent in einem kleinen Zeitraum - Metaphor Das XP-Team nutzt ein gemeinsames System zur Namensgebung und eine gemeinsame Systembeschreibung, die durch den gesamten Entwicklungs- und Kommunikationsprozess fü hrt. Dieses System soll beschreibend sein und ein intuitives Verstä ndnis des Systems ermöglichen. - Simple Design

14 Das gesamte Design des Programms der Build - sollte so simpel wie möglich sein und so wenig Zeit fü r zukü nftige Erweiterungen wie möglich beinhalten. XP braucht allerdings auch ein gutes Design, welches primä r jedoch durch stä ndiges Refactoring erreicht wird. Das Ziel des Designs ist die reine Implementierung von Funktionalitä t, die der Auftraggeber will. Also die Schaffung von business value. - Testing Das Team fokussiert das Testen des Systems im gesamten Entwicklungszeitraum. Dazu schreiben die Entwickler zuerst die Testroutinen und danach die Software, die die durch die Testroutinen erzwungenen Anforderungen erfü llt. Kundenakzeptanztests sollen gewä hrleisten, dass die implementierten Features auch den Wü nschen des Kunden sicher entsprechen. - Refactoring Wä hrend der gesamten Entwicklung wird der Code permanent verbessert. Dies wird erreicht durch sauberhalten des Systems, also ohne doppelte Implementierungen mit hoher Kommunikation aber schon komplett. - Pair Programming Alle Programmierer schreiben sä mtlichen Code in Paaren. Zwei Programmierer arbeiten zusammen an einer Maschine. Diese Form der Zusammenarbeit hat in vielen Experimenten gezeigt, dass besserer Code bei gleichen oder ä hnlichen Kosten produziert wird als wenn die Programmierer alleine arbeiten. - Collective Ownership Sä mtlicher Code gehört allen Programmierern. Dadurch können notwendige Ä nderungen von allen Programmierern ohne Verzögerung durchgefü hrt werden. - Collective Integration Die Programmierer bauen und integrieren die Software mehrmals am Tag. Dadurch sollen alle auf dem gleichen Stand bleiben und sehr schnelle Entwicklungen möglich sein. Außerdem hat sich gezeigt, dass dadurch weniger Integrationsprobleme auftreten als bei Teams, die seltener bauen hour week Diese Direktive ist aus der Erfahrung erwachsen, dass ü bermü dete Programmierer öfters Fehler machen als ausgeschlafene. XP Teams machen keine Ü berstunden um sich selbst fit und gesund zu halten und damit immer beide Programmierer anwesend sind. - On-site customer Ein XP-Projekt wird von einer einzelnen Person geleitet. Diese Person ist befugt Anforderungen aufzustellen, Prioritä ten zu setzen und sie die Fragen der Programmierer beantworten können. Dieses Vorgehen soll die Kommunikation verbessern und weniger Dokumentation in Form von Papier erfordern welche oft der kostenintensivste Faktor der Softwareentwicklung ist. - Coding standard Diese Anforderung ergibt sich aus der Collective Ownership. Wenn alle den gesamten Code sehen und ä ndern dü rfen so sind geeignete Richtlinien zu finden, die eine ü bergreifende Kommunikation ermöglichen. An diese Coding Guidelines hat sich das gesamte Team zu halten.

15 Eine Nutzung aller dieser Regeln ist nicht notwendig. In vielen Beispielen [1] wird auch nur von einer Nutzung eines Teils der Regeln gesprochen. Dies ist zwar nicht ganz unproblematisch weil die Synergien verloren gehen, aber durchaus erwü nscht. Die Anpassbarkeit ist ein wichtiger Faktor bei dieser agilen Methode bedingt auch durch den Fakt, dass die Regeln nicht definiert wurden, sondern aus Erfahrungen stammen. Erfahrungen Praktische Erfahrungen mit XP sind hä ufig vorhanden (vgl. [1, 5]). Am meisten kontrovers diskutiert wird dabei die Regel des Pair Programmings. Zu dieser Regel existieren am meisten Dokumente und Untersuchungen, weshalb sie hier beispielhaft fü r die Praxis angefü hrt sei. Pair Programming hat bekannte Nebeneffekte die sich auf die Programmierer selbst beziehen. So ist das Ergebnis eines Experiments an der University of Colorado [9]. Dort wurden Informatiker im Rahmen eines Kurses Computers as Components in ihrem Verhalten im Bezug auf Pair Programming beobachtet und befragt. Die Ergebnisse dieser durch die National Science Foundation geförderten Studie geben ein eher negatives Licht auf das Pair Programming. So existieren Widerstä nde im Bezug auf diese Art der Programmierung. Im groben lassen sich diese Widerstä nde in zwei Kategorien einteilen. Zum einen wird die benötigte Zeit um die Zusammenarbeit zu fördern als Verschwendung und Ablenkung von der eigentlichen Aufgabe dem Programmieren betrachtet. Zum anderen wird allgemein angenommen das Programmieren eine Einzelaktivitä t ist. Ist der zeitliche Druck durch Zielvorgaben oder Deadlines hoch oder fü r die Programmierer spü rbar, so sinkt die Bereitschaft, Zeit fü r Zusammenarbeit aufzuwenden. Auch besteht die vorherrschende Meinung innerhalb der befragten Gruppe, dass Pair Programming an sich nicht in das Selbstverstä ndnis eines Programmierers passt. Oft sehen Programmierer ihren Code als persönliches Werk, dass ihnen gehört und nicht durch andere beeinflusst werden darf. Im Rahmen einer solchen Ü berzeugung ist Collective Ownership oder auch nur eine Problemformulierung in einem Paar schwierig. Die Konsensfindung innerhalb eines Paares kann somit die Form eines Kampfes um die vermeintlich richtige Lösung annehmen. Damit verbunden wurde der Kontrollverlust als Hindernis identifiziert. Arbeiten zwei Programmierer an der gleichen Aufgabe, so hat keine die gesamte Kontrolle ü ber den Code, bzw. die Lösung. Dieser Fakt wurde als unangenehm fü r die Studenten beschrieben. Verallgemeinert war die Bereitschaft der Studenten ihre Zeit fü r Kommunikationsaktivitä ten aufzuwenden gering und wurde die Bedeutung der Kommunikation fü r das Lösen der Aufgaben ebenfalls als unwichtig eingestuft. Auch wurde generell die Meinung geä ußert, dass Programmierung an sich eine Arbeit ist, die nicht im Team ausgefü hrt werden sollte. Der Prozess der Problemfindung beinhaltet eine Art Offenbarung des Programmierers die Lösung der Aufgabe nicht alleine zu erreichen und damit Unwissenheit zugeben zu mü ssen. Dies ist eine Eigenschaft, die dem Selbstverstä ndnis eines Programmierers entgegen wirkt. Oft wurde die Ü berzeugung dargelegt, dass Zusammenarbeit eine Art des Schummels sei und somit nicht durchgefü hrt werden sollte. Auch steht das Management im Allgemeinen kritisch gegenü ber Collective Ownership oder auch Pair Programming. Die Arbeit von einem wird auf zwei verteilt ist die hä ufigste Aussage.

16 Lob Auf der anderen Seite existieren genug Studien, die sich rein nach der Effizienz bei der Implementierung im Rahmen des Pair Programming gerichtet haben. Aus diesen Studien geht ein anderes Ergebnis hervor. Allgemein steigert Pair Programming zwar nicht die Effizienz im Sinne der Lines of Code. Die Qualitä t der Implementierung nimmt allerdings erheblich zu [6]. In einer Studie an der University of Utah [7] stellten Cockburn und Williams eine erhebliche Steigerung der Qualitä t des Codes bei Studierenden fest, die mit einem anderen Studenten Pair Programming betrieben. Dazu wurden im Rahmen eines Kurses fü r Informatikstudenten zwei Gruppen gebildet. Die eine Gruppe programmierte alleine wä hrend die andere Gruppe Pair Programming betrieb. Beiden Gruppen wurden die gleichen Aufgaben zur Lösung gegeben. Die Ergebnisse waren positiv. Wä hrend die Paare zwar im Mittel 15% mehr Zeit fü r die Programmierung benötigten, enthielt ihr Code aber auch ca. 15% weniger Fehler. Insgesamt war die Lä nge des Codes, der zur Lösung einer Aufgabe notwendig war, kü rzer. Dies wird als Indiz fü r besseres, bzw. effizienteres Design gewertet. Nach einer Befragung am Ende konnten Studenten, die im Paar gearbeitet haben, signifikant mehr zu dem System und den Ablä ufen erzä hlen als Einzelprogrammierer. Insgesamt wussten somit die Paare mehr ü ber das System Bescheid. Dies ist fü r die Autoren ein großer Erfolg, den sie mit einem Rechenbeispiel belegen. Denn interessanterweise ist es gerade die Fehlersuche, die signifikant mehr Zeit benötigt als die eigentliche Programmierung. Vergleicht man dies mit Zahlen der Firma IBM, so kostet diese ein einziger Fehler zwischen 33 und 88 Arbeitsstunden, sofern der Fehler erst nach der Auslieferung auftritt. Rechnet die Mehrzeit, die durch das Pair Programming auftritt gegen diese Fehlerzahl, so erreicht man bei einem Durchschnitt von 40 Stunden/Fehler bei Zeilen Code eine Ersparnis von ca Arbeitsstunden. Von diesen betriebswirtschaftlichen Gesichtspunkten abgesehen konnte man eine deutliche Zunahme der Zufriedenheit auf Seiten der Programmierer feststellen. Es ergab sich, dass mit zunehmender Komplexitä t der Aufgabe die Paare zufriedener waren als die einzelnen Programmierer. Auch wurde nach einer Gewöhnungs- und Einarbeitungsphase eine Einspielung auf den Partner festgestellt, die die Arbeit sehr erleichterte. Ein Programmierer bezeichnete dies treffend als sychronizing the brains [7]. Nach einer Befragung der Teilnehmer bevorzugten die Paare auch weiterhin eine Zusammenarbeit in Form von Pair Programming. Zusammenfassung Im Rahmen dieser Ausarbeitung wurden drei wesentliche Methoden zur agilen Softwareentwicklung vorgestellt. Die Crystal Methodologies bilden eine Art Baukasten, der zu einem Projekt spezifischer Größe und Bedeutung ein Beispiel fü r den Einsatz einer agilen Methode liefert. Daher ist eine Implementation in einem Unternehmen auf die Anpassung des Beispiels auf das konkrete Projekt. Fü r diese Vereinfachung büßen die Crystal Methodologies etwas von ihrer Agilitä t ein und reagieren schlecht auf Verä nderungen in der Größe des Projektes. Ihren iterativen Charakter und die Fokussierung auf Kommunikation und die Projektbeteiligten behalten sie dabei allerdings. Die zweite vorgestellte Methode war das Adaptive Software Development als eine Art Philosophie der Softwareentwicklung. Diese Methode sieht die Softwareentwicklung als stä ndige Evolution in der sich ein Produkt immerfort bewä hren muss um nicht auszusterben nicht mehr gekauft zu werden. Daher gibt sie auch keine Methode vor, an die man sich halten kann, sondern eben eine Art Philosophie. Speculate, Collaborate, Learn sind die Prinzipien dieser Philosophie. Spekuliere ü ber die Ziele deines Projektes,

17 kollaboriere mit dem Team um diese Gedanken zu implementieren und sehe und lerne wie sich deine Ideen behaupten. Mit dieser Erfahrung geht der Prozess von vorne los. Den letzten Punkt bildete die Methode des extreme Programmings. Mit 12 Punkten wurde in die Programmierung der Waldmenschen eingefü hrt. Die Frage war: Wie wü rde man Programmieren, wenn man genug Zeit und Ressourcen hä tte. Genau dieser Frage geben die 12 Punkte Antwort. Durch vermehrtes Testen, kleine und hä ufige Integrationen und Releases soll die Anzahl der Fehler reduziert und die Erfü llung der Kundenwü nsche gewä hrleistet werden. XP befindet sich daher auch zwischen den Crystal Methodologies und dem Adaptive Software Development, weil es sowohl eine Philosophie hergibt als auch die konkreteren Beispiel zu dessen Realisierung. Schluss Agile Prozesse sind in ihrem Bereich eine zu bevorzugende Alternative. Besagter Bereich zeichnet sich vor allem durch seine sich schnell ä ndernden Bedingungen und Vorraussetzungen aus, sowie durch den hohen Druck durch viele Konkurrenten. Dies gilt in kleinen Unternehmen wie auch in großem wie zum Beispiel Microsoft. Allerdings sind auch die agilen Methoden keine Silberkugel eher eine aus Messing. Eine Anwendung agiler Methoden fü hrt nicht automatisch zu einem besseren Ergebnis. Schlechte Software kann unabhä ngig vom genutzten Prozess entstehen. Ein richtiger Einsatz von agilen Methoden erfordert zudem einen anfä nglichen Mehraufwand an Arbeit. Eine Anpassung an die Mitarbeiter und das spezifische Projekt ist in jedem Falle notwendig. Auch hä ngt der Einsatz der konkreten agilen Methode von der Bereitschaft der Mitarbeiter ab diese Methode ü berhaupt einsetzen zu wollen. Alle agilen Methoden setzen im Kern auf Kommunikation. Ist diese von vornherein nicht möglich oder gar erwü nscht, so kann auch die agile Methode nicht erfolgreich sein. Hat man aber ein Projekt, welches die Bedingungen fü r agile Methoden erfü llt so kann deren Nutzung einen immensen Vorteil fü r das Team und das Projekt bedeuten und den gesamten Entwicklungsprozess robuster gestalten. Gravierende Probleme wie der Weggang wichtiger Mitarbeiter oder zusä tzliche Wü nsche von Kunden können so besser abgefangen oder gemildert werden und durch das kommunikativere Umfeld steigt auch die Zufriedenheit der Mitarbeiter. Welche Methode man konkret fü r ein Projekt einsetzt, hä ngt dabei von der Ü berzeugung ab. Wie in der Zusammenfassung erwä hnt, sind die Prozesse unterschiedlich leicht und umfangreich zu implementieren. Von einer einfachen Philosophie bis hin zu konkreten Beispielen ist alles möglich.

18 Quellenverzeichnis Bü cher: [1] Extreme Programming Explained, Kent Beck, Addison-Wesley Professional, 1999, ISBN: [2] Adaptive Software Development, James A. Highsmith III, Dorset House Publishing Company, 2000, ISBN: [3] Agile Software Development, Alistair Cockburn, Addison-Wesley Professional, 2001, ISBN: Artikel und wissenschaftliche Arbeiten: [4] Messy, exciting, and anxiety-ridden: Adaptive Software Development, James A. Highsmith III, 1997, URL: Letzter Aufruf: [5] Extreme Programming, James A. Highsmith III, 2000, URL: Letzter Aufruf: [6] Extreme Programming, Lee Copeland, 2001, URL: ,66192,00.html, Letzter Aufruf: [7] The Costs and Benefits of Pair Programming, Alistair Cockburn and Laurie Ann Williams, 2000, URL: Letzter Aufruf: [8] The Collaborative Software Process (dissertation), Laurie Ann Williams, 2000, URL: Letzter Aufruf: [9] Pair Programming in the Classroom: Student Resistances and Adaptions, Sarah E. Dempsey, Michele H. Jackson, William M. Waite, Amer Diwan,

Projektmanagement in der Spieleentwicklung

Projektmanagement in der Spieleentwicklung Projektmanagement in der Spieleentwicklung Inhalt 1. Warum brauche ich ein Projekt-Management? 2. Die Charaktere des Projektmanagement - Mastermind - Producer - Projektleiter 3. Schnittstellen definieren

Mehr

Lineargleichungssysteme: Additions-/ Subtraktionsverfahren

Lineargleichungssysteme: Additions-/ Subtraktionsverfahren Lineargleichungssysteme: Additions-/ Subtraktionsverfahren W. Kippels 22. Februar 2014 Inhaltsverzeichnis 1 Einleitung 2 2 Lineargleichungssysteme zweiten Grades 2 3 Lineargleichungssysteme höheren als

Mehr

extreme Programming (XP) Hermann Götz Sergij Paholchak Agenda Was ist XP? Grundprinzipien Der Entwicklungsprozess Die Projektplanung Praktiken Vorteile und Nachteile Wann macht XP Sinn für ein Projekt?

Mehr

ONLINE-AKADEMIE. "Diplomierter NLP Anwender für Schule und Unterricht" Ziele

ONLINE-AKADEMIE. Diplomierter NLP Anwender für Schule und Unterricht Ziele ONLINE-AKADEMIE Ziele Wenn man von Menschen hört, die etwas Großartiges in ihrem Leben geleistet haben, erfahren wir oft, dass diese ihr Ziel über Jahre verfolgt haben oder diesen Wunsch schon bereits

Mehr

Mobile Intranet in Unternehmen

Mobile Intranet in Unternehmen Mobile Intranet in Unternehmen Ergebnisse einer Umfrage unter Intranet Verantwortlichen aexea GmbH - communication. content. consulting Augustenstraße 15 70178 Stuttgart Tel: 0711 87035490 Mobile Intranet

Mehr

Agile Softwareprozess-Modelle

Agile Softwareprozess-Modelle Agile Softwareprozess-Modelle Steffen Pingel Regionale Fachgruppe IT-Projektmanagement 2003-07-03 Beweglich, Lebhaft, Wendig Was bedeutet Agil? Andere Bezeichnung: Leichtgewichtiger Prozess Manifesto for

Mehr

Zahlen auf einen Blick

Zahlen auf einen Blick Zahlen auf einen Blick Nicht ohne Grund heißt es: Ein Bild sagt mehr als 1000 Worte. Die meisten Menschen nehmen Informationen schneller auf und behalten diese eher, wenn sie als Schaubild dargeboten werden.

Mehr

GEVITAS Farben-Reaktionstest

GEVITAS Farben-Reaktionstest GEVITAS Farben-Reaktionstest GEVITAS Farben-Reaktionstest Inhalt 1. Allgemeines... 1 2. Funktionsweise der Tests... 2 3. Die Ruhetaste und die Auslösetaste... 2 4. Starten der App Hauptmenü... 3 5. Auswahl

Mehr

Ist Fernsehen schädlich für die eigene Meinung oder fördert es unabhängig zu denken?

Ist Fernsehen schädlich für die eigene Meinung oder fördert es unabhängig zu denken? UErörterung zu dem Thema Ist Fernsehen schädlich für die eigene Meinung oder fördert es unabhängig zu denken? 2000 by christoph hoffmann Seite I Gliederung 1. In zu großen Mengen ist alles schädlich. 2.

Mehr

Persönliche Zukunftsplanung mit Menschen, denen nicht zugetraut wird, dass sie für sich selbst sprechen können Von Susanne Göbel und Josef Ströbl

Persönliche Zukunftsplanung mit Menschen, denen nicht zugetraut wird, dass sie für sich selbst sprechen können Von Susanne Göbel und Josef Ströbl Persönliche Zukunftsplanung mit Menschen, denen nicht zugetraut Von Susanne Göbel und Josef Ströbl Die Ideen der Persönlichen Zukunftsplanung stammen aus Nordamerika. Dort werden Zukunftsplanungen schon

Mehr

OECD Programme for International Student Assessment PISA 2000. Lösungen der Beispielaufgaben aus dem Mathematiktest. Deutschland

OECD Programme for International Student Assessment PISA 2000. Lösungen der Beispielaufgaben aus dem Mathematiktest. Deutschland OECD Programme for International Student Assessment Deutschland PISA 2000 Lösungen der Beispielaufgaben aus dem Mathematiktest Beispielaufgaben PISA-Hauptstudie 2000 Seite 3 UNIT ÄPFEL Beispielaufgaben

Mehr

L10N-Manager 3. Netzwerktreffen der Hochschulübersetzer/i nnen Mannheim 10. Mai 2016

L10N-Manager 3. Netzwerktreffen der Hochschulübersetzer/i nnen Mannheim 10. Mai 2016 L10N-Manager 3. Netzwerktreffen der Hochschulübersetzer/i nnen Mannheim 10. Mai 2016 Referentin: Dr. Kelly Neudorfer Universität Hohenheim Was wir jetzt besprechen werden ist eine Frage, mit denen viele

Mehr

Ein Blick voraus. des Autors von C++: Bjarne Stroustrup. 04.06.2005 Conrad Kobsch

Ein Blick voraus. des Autors von C++: Bjarne Stroustrup. 04.06.2005 Conrad Kobsch Ein Blick voraus des Autors von C++: Bjarne Stroustrup 04.06.2005 Conrad Kobsch Inhalt Einleitung Rückblick Nur eine Übergangslösung? Was würde C++ effektiver machen? Quelle 2 Einleitung Wo steht C++,

Mehr

Einführung und Motivation

Einführung und Motivation Einführung und Motivation iks-thementag: Requirements Engineering 16.11.2010 Autor Carsten Schädel Motto Definiere oder Du wirst definiert. Seite 3 / 51 These Im Privatleben definiert jeder (seine) Anforderungen.

Mehr

FAQ 04/2015. Auswirkung der ISO 14119 auf 3SE53/3SF13 Positionsschalter. https://support.industry.siemens.com/cs/ww/de/view/109475921

FAQ 04/2015. Auswirkung der ISO 14119 auf 3SE53/3SF13 Positionsschalter. https://support.industry.siemens.com/cs/ww/de/view/109475921 FAQ 04/2015 Auswirkung der ISO 14119 auf 3SE53/3SF13 Positionsschalter mit https://support.industry.siemens.com/cs/ww/de/view/109475921 Dieser Beitrag stammt aus dem Siemens Industry Online Support. Es

Mehr

Mind Mapping am PC. für Präsentationen, Vorträge, Selbstmanagement. von Isolde Kommer, Helmut Reinke. 1. Auflage. Hanser München 1999

Mind Mapping am PC. für Präsentationen, Vorträge, Selbstmanagement. von Isolde Kommer, Helmut Reinke. 1. Auflage. Hanser München 1999 Mind Mapping am PC für Präsentationen, Vorträge, Selbstmanagement von Isolde Kommer, Helmut Reinke 1. Auflage Hanser München 1999 Verlag C.H. Beck im Internet: www.beck.de ISBN 978 3 446 21222 0 schnell

Mehr

Software Engineering. Sommersemester 2012, Dr. Andreas Metzger

Software Engineering. Sommersemester 2012, Dr. Andreas Metzger Software Engineering (Übungsblatt 2) Sommersemester 2012, Dr. Andreas Metzger Übungsblatt-Themen: Prinzip, Technik, Methode und Werkzeug; Arten von Wartung; Modularität (Kohäsion/ Kopplung); Inkrementelle

Mehr

Verband der TÜV e. V. STUDIE ZUM IMAGE DER MPU

Verband der TÜV e. V. STUDIE ZUM IMAGE DER MPU Verband der TÜV e. V. STUDIE ZUM IMAGE DER MPU 2 DIE MEDIZINISCH-PSYCHOLOGISCHE UNTERSUCHUNG (MPU) IST HOCH ANGESEHEN Das Image der Medizinisch-Psychologischen Untersuchung (MPU) ist zwiespältig: Das ist

Mehr

50. Mathematik-Olympiade 2. Stufe (Regionalrunde) Klasse 11 13. 501322 Lösung 10 Punkte

50. Mathematik-Olympiade 2. Stufe (Regionalrunde) Klasse 11 13. 501322 Lösung 10 Punkte 50. Mathematik-Olympiade. Stufe (Regionalrunde) Klasse 3 Lösungen c 00 Aufgabenausschuss des Mathematik-Olympiaden e.v. www.mathematik-olympiaden.de. Alle Rechte vorbehalten. 503 Lösung 0 Punkte Es seien

Mehr

Fehler und Probleme bei Auswahl und Installation eines Dokumentenmanagement Systems

Fehler und Probleme bei Auswahl und Installation eines Dokumentenmanagement Systems Fehler und Probleme bei Auswahl und Installation eines Dokumentenmanagement Systems Name: Bruno Handler Funktion: Marketing/Vertrieb Organisation: AXAVIA Software GmbH Liebe Leserinnen und liebe Leser,

Mehr

1. Was ihr in dieser Anleitung

1. Was ihr in dieser Anleitung Leseprobe 1. Was ihr in dieser Anleitung erfahren könnt 2 Liebe Musiker, in diesem PDF erhaltet ihr eine Anleitung, wie ihr eure Musik online kostenlos per Werbevideo bewerben könnt, ohne dabei Geld für

Mehr

Wordpress: Blogbeiträge richtig löschen, archivieren und weiterleiten

Wordpress: Blogbeiträge richtig löschen, archivieren und weiterleiten Wordpress: Blogbeiträge richtig löschen, archivieren und weiterleiten Version 1.0 Wordpress: Blogbeiträge richtig löschen, archivieren und weiterleiten In unserer Anleitung zeigen wir Dir, wie Du Blogbeiträge

Mehr

Welche Gedanken wir uns für die Erstellung einer Präsentation machen, sollen Ihnen die folgende Folien zeigen.

Welche Gedanken wir uns für die Erstellung einer Präsentation machen, sollen Ihnen die folgende Folien zeigen. Wir wollen mit Ihnen Ihren Auftritt gestalten Steil-Vorlage ist ein österreichisches Start-up mit mehr als zehn Jahren Erfahrung in IT und Kommunikation. Unser Ziel ist, dass jede einzelne Mitarbeiterin

Mehr

1 topologisches Sortieren

1 topologisches Sortieren Wolfgang Hönig / Andreas Ecke WS 09/0 topologisches Sortieren. Überblick. Solange noch Knoten vorhanden: a) Suche Knoten v, zu dem keine Kante führt (Falls nicht vorhanden keine topologische Sortierung

Mehr

Konzepte der Informatik

Konzepte der Informatik Konzepte der Informatik Vorkurs Informatik zum WS 2011/2012 26.09. - 30.09.2011 17.10. - 21.10.2011 Dr. Werner Struckmann / Christoph Peltz Stark angelehnt an Kapitel 1 aus "Abenteuer Informatik" von Jens

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was

Mehr

Informationssystemanalyse Problemstellung 2 1. Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse:

Informationssystemanalyse Problemstellung 2 1. Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse: Informationssystemanalyse Problemstellung 2 1 Problemstellung Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse: große Software-Systeme werden im Schnitt ein Jahr zu spät

Mehr

Primzahlen und RSA-Verschlüsselung

Primzahlen und RSA-Verschlüsselung Primzahlen und RSA-Verschlüsselung Michael Fütterer und Jonathan Zachhuber 1 Einiges zu Primzahlen Ein paar Definitionen: Wir bezeichnen mit Z die Menge der positiven und negativen ganzen Zahlen, also

Mehr

Komplexität und der Dreischritt zur Einfachheit Dieter Brandes und Nils Brandes, Institut für Einfachheit

Komplexität und der Dreischritt zur Einfachheit Dieter Brandes und Nils Brandes, Institut für Einfachheit Komplexität und der Dreischritt zur Einfachheit Dieter Brandes und Nils Brandes, Institut für Einfachheit Im Jahr 2002 hat Dieter Brandes erstmals den Dreischritt zur Einfachheit veröffentlicht. Wir geben

Mehr

Kreativ visualisieren

Kreativ visualisieren Kreativ visualisieren Haben Sie schon einmal etwas von sogenannten»sich selbst erfüllenden Prophezeiungen«gehört? Damit ist gemeint, dass ein Ereignis mit hoher Wahrscheinlichkeit eintritt, wenn wir uns

Mehr

Lineare Differentialgleichungen erster Ordnung erkennen

Lineare Differentialgleichungen erster Ordnung erkennen Lineare Differentialgleichungen erster Ordnung In diesem Kapitel... Erkennen, wie Differentialgleichungen erster Ordnung aussehen en für Differentialgleichungen erster Ordnung und ohne -Terme finden Die

Mehr

Warum sich das Management nicht für agile Softwareentwicklung interessieren sollte - aber für Agilität

Warum sich das Management nicht für agile Softwareentwicklung interessieren sollte - aber für Agilität Warum sich das Management nicht für agile Softwareentwicklung interessieren sollte - aber für Agilität Marcus Winteroll oose GmbH Agenda I. Ziele und Zusammenarbeit II. Was wir vom agilen Vorgehen lernen

Mehr

FAQ Spielvorbereitung Startspieler: Wer ist Startspieler?

FAQ Spielvorbereitung Startspieler: Wer ist Startspieler? FAQ Spielvorbereitung Startspieler: Wer ist Startspieler? In der gedruckten Version der Spielregeln steht: der Startspieler ist der Spieler, dessen Arena unmittelbar links neben dem Kaiser steht [im Uhrzeigersinn].

Mehr

Nina. bei der Hörgeräte-Akustikerin. Musterexemplar

Nina. bei der Hörgeräte-Akustikerin. Musterexemplar Nina bei der Hörgeräte-Akustikerin Nina bei der Hörgeräte-Akustikerin Herausgeber: uphoff pr-consulting Alfred-Wegener-Str. 6 35039 Marburg Tel.: 0 64 21 / 4 07 95-0 info@uphoff-pr.de www.uphoff-pr.de

Mehr

Mediator 9 - Lernprogramm

Mediator 9 - Lernprogramm Mediator 9 - Lernprogramm Ein Lernprogramm mit Mediator erstellen Mediator 9 bietet viele Möglichkeiten, CBT-Module (Computer Based Training = Computerunterstütztes Lernen) zu erstellen, z. B. Drag & Drop

Mehr

4 Aufzählungen und Listen erstellen

4 Aufzählungen und Listen erstellen 4 4 Aufzählungen und Listen erstellen Beim Strukturieren von Dokumenten und Inhalten stellen Listen und Aufzählungen wichtige Werkzeuge dar. Mit ihnen lässt sich so ziemlich alles sortieren, was auf einer

Mehr

Ergebnis und Auswertung der BSV-Online-Umfrage zur dienstlichen Beurteilung

Ergebnis und Auswertung der BSV-Online-Umfrage zur dienstlichen Beurteilung Ergebnis und Auswertung der BSV-Online-Umfrage zur dienstlichen Beurteilung Es waren exakt 237 Rückmeldungen, die wir erhalten, gesammelt und ausgewertet haben und damit ein Vielfaches von dem, was wir

Mehr

Leseprobe. Bruno Augustoni. Professionell präsentieren. ISBN (Buch): 978-3-446-44285-6. ISBN (E-Book): 978-3-446-44335-8

Leseprobe. Bruno Augustoni. Professionell präsentieren. ISBN (Buch): 978-3-446-44285-6. ISBN (E-Book): 978-3-446-44335-8 Leseprobe Bruno Augustoni Professionell präsentieren ISBN (Buch): 978-3-446-44285-6 ISBN (E-Book): 978-3-446-44335-8 Weitere Informationen oder Bestellungen unter http://wwwhanser-fachbuchde/978-3-446-44285-6

Mehr

PTV VISWALK TIPPS UND TRICKS PTV VISWALK TIPPS UND TRICKS: VERWENDUNG DICHTEBASIERTER TEILROUTEN

PTV VISWALK TIPPS UND TRICKS PTV VISWALK TIPPS UND TRICKS: VERWENDUNG DICHTEBASIERTER TEILROUTEN PTV VISWALK TIPPS UND TRICKS PTV VISWALK TIPPS UND TRICKS: VERWENDUNG DICHTEBASIERTER TEILROUTEN Karlsruhe, April 2015 Verwendung dichte-basierter Teilrouten Stellen Sie sich vor, in einem belebten Gebäude,

Mehr

1. Weniger Steuern zahlen

1. Weniger Steuern zahlen 1. Weniger Steuern zahlen Wenn man arbeitet, zahlt man Geld an den Staat. Dieses Geld heißt Steuern. Viele Menschen zahlen zu viel Steuern. Sie haben daher wenig Geld für Wohnung, Gewand oder Essen. Wenn

Mehr

Allensbach: Das Elterngeld im Urteil der jungen Eltern

Allensbach: Das Elterngeld im Urteil der jungen Eltern August 2007 Allensbach: Das Elterngeld im Urteil der jungen Eltern Allensbach befragte im Juni 2007 eine repräsentative Stichprobe von 1000 Müttern und Vätern, deren (jüngstes) Kind ab dem 1.1.2007 geboren

Mehr

Zeichen bei Zahlen entschlüsseln

Zeichen bei Zahlen entschlüsseln Zeichen bei Zahlen entschlüsseln In diesem Kapitel... Verwendung des Zahlenstrahls Absolut richtige Bestimmung von absoluten Werten Operationen bei Zahlen mit Vorzeichen: Addieren, Subtrahieren, Multiplizieren

Mehr

Speicher in der Cloud

Speicher in der Cloud Speicher in der Cloud Kostenbremse, Sicherheitsrisiko oder Basis für die unternehmensweite Kollaboration? von Cornelius Höchel-Winter 2013 ComConsult Research GmbH, Aachen 3 SYNCHRONISATION TEUFELSZEUG

Mehr

Erfahrungen mit Hartz IV- Empfängern

Erfahrungen mit Hartz IV- Empfängern Erfahrungen mit Hartz IV- Empfängern Ausgewählte Ergebnisse einer Befragung von Unternehmen aus den Branchen Gastronomie, Pflege und Handwerk Pressegespräch der Bundesagentur für Arbeit am 12. November

Mehr

Agile Software Development

Agile Software Development Dipl. Wirtsch. Ing. Alexander Werth Methoden der Softwareentwicklung 6-1 Agile Manifest Individuen und Interaktion statt Prozessen und Tools. Funktionierende Software statt umfangreicher Dokumentation.

Mehr

Die Captimizer BTZ-Datei 2015

Die Captimizer BTZ-Datei 2015 Dipl.-Math. Rainer Schwindt Captimizer s Secrets behind the User Interface 2 Die Captimizer BTZ-Datei 2015 Regeln zur BTZ bei laufendem Navigator und Navigator-Neustart beim Jahreswechsel Geheimnisse hinter

Mehr

So funktioniert Ihr Selbstmanagement noch besser

So funktioniert Ihr Selbstmanagement noch besser So funktioniert Ihr Selbstmanagement noch besser HANS-FISCHER FISCHER-SEMINARE SEMINARE St. Wendelinsstrasse 9 86932 Pürgen-Lengenfeld Telefon 08196 99 82 10 Fax 08196 99 82 10 www.fischerseminare.de hans.fischer@fischerseminare.de

Mehr

Charakteristikum des Gutachtenstils: Es wird mit einer Frage begonnen, sodann werden die Voraussetzungen Schritt für Schritt aufgezeigt und erörtert.

Charakteristikum des Gutachtenstils: Es wird mit einer Frage begonnen, sodann werden die Voraussetzungen Schritt für Schritt aufgezeigt und erörtert. Der Gutachtenstil: Charakteristikum des Gutachtenstils: Es wird mit einer Frage begonnen, sodann werden die Voraussetzungen Schritt für Schritt aufgezeigt und erörtert. Das Ergebnis steht am Schluß. Charakteristikum

Mehr

Was ist Sozial-Raum-Orientierung?

Was ist Sozial-Raum-Orientierung? Was ist Sozial-Raum-Orientierung? Dr. Wolfgang Hinte Universität Duisburg-Essen Institut für Stadt-Entwicklung und Sozial-Raum-Orientierte Arbeit Das ist eine Zusammen-Fassung des Vortrages: Sozialräume

Mehr

Dieses erste Kreisdiagramm, bezieht sich auf das gesamte Testergebnis der kompletten 182 getesteten Personen. Ergebnis

Dieses erste Kreisdiagramm, bezieht sich auf das gesamte Testergebnis der kompletten 182 getesteten Personen. Ergebnis Datenanalyse Auswertung Der Kern unseres Projektes liegt ganz klar bei der Fragestellung, ob es möglich ist, Biere von und geschmacklich auseinander halten zu können. Anhand der folgenden Grafiken, sollte

Mehr

Repetitionsaufgaben Wurzelgleichungen

Repetitionsaufgaben Wurzelgleichungen Repetitionsaufgaben Wurzelgleichungen Inhaltsverzeichnis A) Vorbemerkungen B) Lernziele C) Theorie mit Aufgaben D) Aufgaben mit Musterlösungen 4 A) Vorbemerkungen Bitte beachten Sie: Bei Wurzelgleichungen

Mehr

Psychologie im Arbeitsschutz

Psychologie im Arbeitsschutz Fachvortrag zur Arbeitsschutztagung 2014 zum Thema: Psychologie im Arbeitsschutz von Dipl. Ing. Mirco Pretzel 23. Januar 2014 Quelle: Dt. Kaltwalzmuseum Hagen-Hohenlimburg 1. Einleitung Was hat mit moderner

Mehr

Meinungen der Bürgerinnen und Bürger in Hamburg und Berlin zu einer Bewerbung um die Austragung der Olympischen Spiele

Meinungen der Bürgerinnen und Bürger in Hamburg und Berlin zu einer Bewerbung um die Austragung der Olympischen Spiele Meinungen der Bürgerinnen und Bürger in Hamburg und Berlin zu einer Bewerbung um die Austragung der Olympischen Spiele 4. März 2015 q5337/31319 Le forsa Politik- und Sozialforschung GmbH Büro Berlin Schreiberhauer

Mehr

Bruchrechnung Wir teilen gerecht auf

Bruchrechnung Wir teilen gerecht auf Bruchrechnung Wir teilen gerecht auf Minipizzen auf Personen. Bruchrechnung Wir teilen gerecht auf Minipizzen auf Personen. : (+) : + Wir teilen einen Teil Eine halbe Minipizza auf Personen. :? Wir teilen

Mehr

Lernerfolge sichern - Ein wichtiger Beitrag zu mehr Motivation

Lernerfolge sichern - Ein wichtiger Beitrag zu mehr Motivation Lernerfolge sichern - Ein wichtiger Beitrag zu mehr Motivation Einführung Mit welchen Erwartungen gehen Jugendliche eigentlich in ihre Ausbildung? Wir haben zu dieser Frage einmal die Meinungen von Auszubildenden

Mehr

Outlook. sysplus.ch outlook - mail-grundlagen Seite 1/8. Mail-Grundlagen. Posteingang

Outlook. sysplus.ch outlook - mail-grundlagen Seite 1/8. Mail-Grundlagen. Posteingang sysplus.ch outlook - mail-grundlagen Seite 1/8 Outlook Mail-Grundlagen Posteingang Es gibt verschiedene Möglichkeiten, um zum Posteingang zu gelangen. Man kann links im Outlook-Fenster auf die Schaltfläche

Mehr

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle Diverse Grundlagen Dr. Karsten Tolle Vorgehensmodelle im Software Engineering Wasserfallmodell Rapid Prototyping Spiralmodell V-Modell Rational Unified Process extrem Programming Test Driven Development

Mehr

1 Mathematische Grundlagen

1 Mathematische Grundlagen Mathematische Grundlagen - 1-1 Mathematische Grundlagen Der Begriff der Menge ist einer der grundlegenden Begriffe in der Mathematik. Mengen dienen dazu, Dinge oder Objekte zu einer Einheit zusammenzufassen.

Mehr

Informationsblatt Induktionsbeweis

Informationsblatt Induktionsbeweis Sommer 015 Informationsblatt Induktionsbeweis 31. März 015 Motivation Die vollständige Induktion ist ein wichtiges Beweisverfahren in der Informatik. Sie wird häufig dazu gebraucht, um mathematische Formeln

Mehr

Zahlenwinkel: Forscherkarte 1. alleine. Zahlenwinkel: Forschertipp 1

Zahlenwinkel: Forscherkarte 1. alleine. Zahlenwinkel: Forschertipp 1 Zahlenwinkel: Forscherkarte 1 alleine Tipp 1 Lege die Ziffern von 1 bis 9 so in den Zahlenwinkel, dass jeder Arm des Zahlenwinkels zusammengezählt das gleiche Ergebnis ergibt! Finde möglichst viele verschiedene

Mehr

Gruppenrichtlinien und Softwareverteilung

Gruppenrichtlinien und Softwareverteilung Gruppenrichtlinien und Softwareverteilung Ergänzungen zur Musterlösung Bitte lesen Sie zuerst die gesamte Anleitung durch! Vorbemerkung: Die Begriffe OU (Organizational Unit) und Raum werden in der folgenden

Mehr

Wie halte ich Ordnung auf meiner Festplatte?

Wie halte ich Ordnung auf meiner Festplatte? Wie halte ich Ordnung auf meiner Festplatte? Was hältst du von folgender Ordnung? Du hast zu Hause einen Schrank. Alles was dir im Wege ist, Zeitungen, Briefe, schmutzige Wäsche, Essensreste, Küchenabfälle,

Mehr

Simulation LIF5000. Abbildung 1

Simulation LIF5000. Abbildung 1 Simulation LIF5000 Abbildung 1 Zur Simulation von analogen Schaltungen verwende ich Ltspice/SwitcherCAD III. Dieses Programm ist sehr leistungsfähig und wenn man weis wie, dann kann man damit fast alles

Mehr

Kapitel 4 Die Datenbank Kuchenbestellung Seite 1

Kapitel 4 Die Datenbank Kuchenbestellung Seite 1 Kapitel 4 Die Datenbank Kuchenbestellung Seite 1 4 Die Datenbank Kuchenbestellung In diesem Kapitel werde ich die Theorie aus Kapitel 2 Die Datenbank Buchausleihe an Hand einer weiteren Datenbank Kuchenbestellung

Mehr

Was meinen die Leute eigentlich mit: Grexit?

Was meinen die Leute eigentlich mit: Grexit? Was meinen die Leute eigentlich mit: Grexit? Grexit sind eigentlich 2 Wörter. 1. Griechenland 2. Exit Exit ist ein englisches Wort. Es bedeutet: Ausgang. Aber was haben diese 2 Sachen mit-einander zu tun?

Mehr

Berechnung der Erhöhung der Durchschnittsprämien

Berechnung der Erhöhung der Durchschnittsprämien Wolfram Fischer Berechnung der Erhöhung der Durchschnittsprämien Oktober 2004 1 Zusammenfassung Zur Berechnung der Durchschnittsprämien wird das gesamte gemeldete Prämienvolumen Zusammenfassung durch die

Mehr

Warum Projektmanagement?

Warum Projektmanagement? Warum Projektmanagement? Projektmanagement ist keine Software, sondern eine, die Beteiligten verpflichtende Vorgehenssystematik, ein Verhaltenskodex und Kontrollsystem für die Dauer eines Projekts. Projektmanagement

Mehr

Der Kunde zahlt die Gehälter.

Der Kunde zahlt die Gehälter. Der Kunde zahlt die Gehälter. Hat man das erst einmal verstanden wird es leicht zufriedene Kunden zu gewinnen. E r f o l g s r e z e p t : Wann ist ein Kunde zufrieden? Wenn er merkt das wir zuhören Wenn

Mehr

Ist Excel das richtige Tool für FMEA? Steve Murphy, Marc Schaeffers

Ist Excel das richtige Tool für FMEA? Steve Murphy, Marc Schaeffers Ist Excel das richtige Tool für FMEA? Steve Murphy, Marc Schaeffers Ist Excel das richtige Tool für FMEA? Einleitung Wenn in einem Unternehmen FMEA eingeführt wird, fangen die meisten sofort damit an,

Mehr

Meet the Germans. Lerntipp zur Schulung der Fertigkeit des Sprechens. Lerntipp und Redemittel zur Präsentation oder einen Vortrag halten

Meet the Germans. Lerntipp zur Schulung der Fertigkeit des Sprechens. Lerntipp und Redemittel zur Präsentation oder einen Vortrag halten Meet the Germans Lerntipp zur Schulung der Fertigkeit des Sprechens Lerntipp und Redemittel zur Präsentation oder einen Vortrag halten Handreichungen für die Kursleitung Seite 2, Meet the Germans 2. Lerntipp

Mehr

geben. Die Wahrscheinlichkeit von 100% ist hier demnach nur der Gehen wir einmal davon aus, dass die von uns angenommenen

geben. Die Wahrscheinlichkeit von 100% ist hier demnach nur der Gehen wir einmal davon aus, dass die von uns angenommenen geben. Die Wahrscheinlichkeit von 100% ist hier demnach nur der Vollständigkeit halber aufgeführt. Gehen wir einmal davon aus, dass die von uns angenommenen 70% im Beispiel exakt berechnet sind. Was würde

Mehr

Das System sollte den Benutzer immer auf dem Laufenden halten, indem es angemessenes Feedback in einer angemessenen Zeit liefert.

Das System sollte den Benutzer immer auf dem Laufenden halten, indem es angemessenes Feedback in einer angemessenen Zeit liefert. Usability Heuristiken Karima Tefifha Proseminar: "Software Engineering Kernkonzepte: Usability" 28.06.2012 Prof. Dr. Kurt Schneider Leibniz Universität Hannover Die ProSeminar-Ausarbeitung beschäftigt

Mehr

Softwareentwicklungsprozess im Praktikum. 23. April 2015

Softwareentwicklungsprozess im Praktikum. 23. April 2015 Softwareentwicklungsprozess im Praktikum 23. April 2015 Agile Softwareentwicklung Eine agile Methodik stellt die beteiligten Menschen in den Mittelpunkt und versucht die Kommunikation und Zusammenarbeit

Mehr

Professionelle Seminare im Bereich MS-Office

Professionelle Seminare im Bereich MS-Office Der Name BEREICH.VERSCHIEBEN() ist etwas unglücklich gewählt. Man kann mit der Funktion Bereiche zwar verschieben, man kann Bereiche aber auch verkleinern oder vergrößern. Besser wäre es, die Funktion

Mehr

Leit-Bild. Elbe-Werkstätten GmbH und. PIER Service & Consulting GmbH. Mit Menschen erfolgreich

Leit-Bild. Elbe-Werkstätten GmbH und. PIER Service & Consulting GmbH. Mit Menschen erfolgreich Leit-Bild Elbe-Werkstätten GmbH und PIER Service & Consulting GmbH Mit Menschen erfolgreich Vorwort zu dem Leit-Bild Was ist ein Leit-Bild? Ein Leit-Bild sind wichtige Regeln. Nach diesen Regeln arbeiten

Mehr

Um Ihre Ziele durchzusetzen! Um Beziehungen zu knüpfen und zu pflegen! Um in Begegnungen mit anderen Ihre Selbstachtung zu wahren!

Um Ihre Ziele durchzusetzen! Um Beziehungen zu knüpfen und zu pflegen! Um in Begegnungen mit anderen Ihre Selbstachtung zu wahren! Handout 19 Interpersonelle Grundfertigkeiten Einführung Wozu brauchen Sie zwischenmenschliche Skills? Um Ihre Ziele durchzusetzen! Um Beziehungen zu knüpfen und zu pflegen! Um in Begegnungen mit anderen

Mehr

Zeit lässt sich nicht wie Geld für schlechte Zeiten zur Seite legen. Die Zeit vergeht egal, ob genutzt oder ungenutzt.

Zeit lässt sich nicht wie Geld für schlechte Zeiten zur Seite legen. Die Zeit vergeht egal, ob genutzt oder ungenutzt. Zeitmanagement Allgemeine Einleitung Wie oft haben Sie schon gehört Ich habe leider keine Zeit? Und wie oft haben Sie diesen Satz schon selbst gesagt? Wahrscheinlich nahezu jeden Tag. Dabei stimmt der

Mehr

Papa - was ist American Dream?

Papa - was ist American Dream? Papa - was ist American Dream? Das heißt Amerikanischer Traum. Ja, das weiß ich, aber was heißt das? Der [wpseo]amerikanische Traum[/wpseo] heißt, dass jeder Mensch allein durch harte Arbeit und Willenskraft

Mehr

Konzentration auf das. Wesentliche.

Konzentration auf das. Wesentliche. Konzentration auf das Wesentliche. Machen Sie Ihre Kanzleiarbeit effizienter. 2 Sehr geehrte Leserin, sehr geehrter Leser, die Grundlagen Ihres Erfolges als Rechtsanwalt sind Ihre Expertise und Ihre Mandantenorientierung.

Mehr

SSI WHITE PAPER Design einer mobilen App in wenigen Stunden

SSI WHITE PAPER Design einer mobilen App in wenigen Stunden Moderne Apps für Smartphones und Tablets lassen sich ohne großen Aufwand innerhalb von wenigen Stunden designen Kunde Branche Zur Firma Produkte Übersicht LFoundry S.r.l Herrngasse 379-381 84028 Landshut

Mehr

Deutschland-Check Nr. 35

Deutschland-Check Nr. 35 Beschäftigung älterer Arbeitnehmer Ergebnisse des IW-Unternehmervotums Bericht der IW Consult GmbH Köln, 13. Dezember 2012 Institut der deutschen Wirtschaft Köln Consult GmbH Konrad-Adenauer-Ufer 21 50668

Mehr

Südberliner Gemeinde-Bibelschule (SBGBS) September 2008

Südberliner Gemeinde-Bibelschule (SBGBS) September 2008 Südberliner Gemeinde-Bibelschule (SBGBS) September 2008 SBGBS Südberliner Thema: Zeitmanagement I (Einführung) Autor: Ansgar N. Przesang Fassung: September 2008 2 SBGBS Südberliner Thema: Zeitmanagement

Mehr

Gutes Leben was ist das?

Gutes Leben was ist das? Lukas Bayer Jahrgangsstufe 12 Im Hirschgarten 1 67435 Neustadt Kurfürst-Ruprecht-Gymnasium Landwehrstraße22 67433 Neustadt a. d. Weinstraße Gutes Leben was ist das? Gutes Leben für alle was genau ist das

Mehr

Viele Bilder auf der FA-Homepage

Viele Bilder auf der FA-Homepage Viele Bilder auf der FA-Homepage Standardmäßig lassen sich auf einer FA-Homepage nur 2 Bilder mit zugehörigem Text unterbringen. Sollen es mehr Bilder sein, muss man diese als von einer im Internet

Mehr

EARSandEYES-Studie: Elektronisches Bezahlen

EARSandEYES-Studie: Elektronisches Bezahlen www.girocard.eu Management Summary EARSandEYES-Studie: Elektronisches Bezahlen Management Summary August 2014 Seite 1 / 6 EARSandEYES-Studie: Elektronisches Bezahlen Der Trend geht hin zum bargeldlosen

Mehr

Einleitung. Für wen ist dieses Buch

Einleitung. Für wen ist dieses Buch i Willkommen! Dieses Buch aus der Reihe Schritt für Schritt wurde so konzipiert, dass Sie mit dem Buch leicht und einfach die wesentlichen Aspekte beim Einsatz von vier der Microsoft Office 2016- Apps

Mehr

Herzlich Willkommen beim Webinar: Was verkaufen wir eigentlich?

Herzlich Willkommen beim Webinar: Was verkaufen wir eigentlich? Herzlich Willkommen beim Webinar: Was verkaufen wir eigentlich? Was verkaufen wir eigentlich? Provokativ gefragt! Ein Hotel Marketing Konzept Was ist das? Keine Webseite, kein SEO, kein Paket,. Was verkaufen

Mehr

Workshop-Unterlagen Leitbildentwicklung

Workshop-Unterlagen Leitbildentwicklung Workshop-Unterlagen Leitbildentwicklung Ein partizipativer Entwicklungsprozess mit Hilfe der Fotolangage Dr. Kurt Aeberhard aeberhard@innopool.ch Dr. Michèle Etienne etienne@innopool.ch Schüpfen, November

Mehr

Beweisbar sichere Verschlüsselung

Beweisbar sichere Verschlüsselung Beweisbar sichere Verschlüsselung ITS-Wahlpflichtvorlesung Dr. Bodo Möller Ruhr-Universität Bochum Horst-Görtz-Institut für IT-Sicherheit Lehrstuhl für Kommunikationssicherheit bmoeller@crypto.rub.de 6

Mehr

40-Tage-Wunder- Kurs. Umarme, was Du nicht ändern kannst.

40-Tage-Wunder- Kurs. Umarme, was Du nicht ändern kannst. 40-Tage-Wunder- Kurs Umarme, was Du nicht ändern kannst. Das sagt Wikipedia: Als Wunder (griechisch thauma) gilt umgangssprachlich ein Ereignis, dessen Zustandekommen man sich nicht erklären kann, so dass

Mehr

Persönlichkeit und Persönlichkeitsunterschiede

Persönlichkeit und Persönlichkeitsunterschiede 9 Persönlichkeit und Persönlichkeitsunterschiede 1 Inhalt Die Beschäftigung mit der menschlichen Persönlichkeit spielt in unserem Alltag eine zentrale Rolle. Wir greifen auf das globale Konzept Persönlichkeit

Mehr

Mean Time Between Failures (MTBF)

Mean Time Between Failures (MTBF) Mean Time Between Failures (MTBF) Hintergrundinformation zur MTBF Was steht hier? Die Mean Time Between Failure (MTBF) ist ein statistischer Mittelwert für den störungsfreien Betrieb eines elektronischen

Mehr

Handbuch Fischertechnik-Einzelteiltabelle V3.7.3

Handbuch Fischertechnik-Einzelteiltabelle V3.7.3 Handbuch Fischertechnik-Einzelteiltabelle V3.7.3 von Markus Mack Stand: Samstag, 17. April 2004 Inhaltsverzeichnis 1. Systemvorraussetzungen...3 2. Installation und Start...3 3. Anpassen der Tabelle...3

Mehr

agitat Werkzeuge kann man brauchen und missbrauchen - vom Einsatz von NLP in der Führung

agitat Werkzeuge kann man brauchen und missbrauchen - vom Einsatz von NLP in der Führung agitat Werkzeuge kann man brauchen und missbrauchen - vom Einsatz von NLP in der Führung Der Inhalt dieses Vortrages Moderne Führungskräfte stehen vor der Herausforderung, ihr Unternehmen, ihre Mitarbeiter

Mehr

Mehr Geld verdienen! Lesen Sie... Peter von Karst. Ihre Leseprobe. der schlüssel zum leben. So gehen Sie konkret vor!

Mehr Geld verdienen! Lesen Sie... Peter von Karst. Ihre Leseprobe. der schlüssel zum leben. So gehen Sie konkret vor! Peter von Karst Mehr Geld verdienen! So gehen Sie konkret vor! Ihre Leseprobe Lesen Sie...... wie Sie mit wenigen, aber effektiven Schritten Ihre gesteckten Ziele erreichen.... wie Sie die richtigen Entscheidungen

Mehr

10 Jahre agile Softwareentwicklung Wie erwachsen sind wir geworden?

10 Jahre agile Softwareentwicklung Wie erwachsen sind wir geworden? 10 Jahre agile Softwareentwicklung Wie erwachsen sind wir geworden? Stefan Roock stefan.roock@akquinet.de Hintergrund 1/2 Senior IT-Berater bei der akquinet AG extreme Programming seit Anfang 1999, dann

Mehr

Finanzierung: Übungsserie III Innenfinanzierung

Finanzierung: Übungsserie III Innenfinanzierung Thema Dokumentart Finanzierung: Übungsserie III Innenfinanzierung Lösungen Theorie im Buch "Integrale Betriebswirtschaftslehre" Teil: Kapitel: D1 Finanzmanagement 2.3 Innenfinanzierung Finanzierung: Übungsserie

Mehr

Der Leverage-Effekt wirkt sich unter verschiedenen Umständen auf die Eigenkapitalrendite aus.

Der Leverage-Effekt wirkt sich unter verschiedenen Umständen auf die Eigenkapitalrendite aus. Anhang Leverage-Effekt Leverage-Effekt Bezeichnungs- Herkunft Das englische Wort Leverage heisst Hebelwirkung oder Hebelkraft. Zweck Der Leverage-Effekt wirkt sich unter verschiedenen Umständen auf die

Mehr

Company Presentation

Company Presentation SPEZIALIST FÜR DEN US-MARKT - Vertrieb, Geschäftsaufbau & Consulting Technisch hochwertige Produkte und Systeme - Spezialisierung: Industrielle Automation und Investitionsgüter / Maschinenbau Company Presentation

Mehr

Manager. von Peter Pfeifer, Waltraud Pfeifer, Burkhard Münchhagen. Spielanleitung

Manager. von Peter Pfeifer, Waltraud Pfeifer, Burkhard Münchhagen. Spielanleitung Manager von Peter Pfeifer, Waltraud Pfeifer, Burkhard Münchhagen Spielanleitung Manager Ein rasantes Wirtschaftsspiel für 3 bis 6 Spieler. Das Glück Ihrer Firma liegt in Ihren Händen! Bestehen Sie gegen

Mehr