PROJEKTMANAGEMENT AUFWANDS- UND RESSOURCENPLANUNG BLOCK 6. LV Nr (2VU) LV Nr (1VU) Autor: Mirza Hadzic, Johanna Pirker

Größe: px
Ab Seite anzeigen:

Download "PROJEKTMANAGEMENT AUFWANDS- UND RESSOURCENPLANUNG BLOCK 6. LV Nr. 706.028 (2VU) LV Nr. 706.038 (1VU) Autor: Mirza Hadzic, Johanna Pirker"

Transkript

1 PROJEKTMANAGEMENT LV Nr (2VU) LV Nr (1VU) AUFWANDS- UND RESSOURCENPLANUNG BLOCK 6 Autor: Mirza Hadzic, Johanna Pirker Lehrveranstaltungsleiter: Dipl.-Ing. Dr.techn. Christian Gütl

2 Inhaltsverzeichnis 1. EINLEITUNG Ziele Arten der Aufwandsabschätzung ABSCHÄTZUNG DES OPERATIVEN PROJEKTAUFWANDES Phasen-basierte Abschätzung Deliverable-basierte Abschätzung Verwendung von Deliverables-basierten Abschätzungen Einzuplanende Reserven Reserve für Überarbeitungen Reserve für wachsenden Projektumfang Detaillierte Aufwandsabschätzung Baseline Effort Effort Variance Factor Skill Factor (SF) Work Interruption Factor (WIF) Multiple Project Factor (MPF) Project Productivity Influencing Factor (PPIF) Berechnung des EVF Der Projektzeitplan ABSCHÄTZUNG DES ORGANISATORISCHEN AUFWANDES Aufwand für Projektsponsor Aufwand für Projektmanager und Projektkunde ABSCHÄTZUNG DER PROJEKTKOSTEN Fixpreisangebote SOFTWARESPEZIFISCHE AUFWANDSABSCHÄTZUNG Produktivität Algorithmische Aufwandsschätzung Das COCOMO-Modell Die frühe Prototypenstufe Die frühe Entwurfsstufe Die Stufe nach dem Architekturentwurf Projektdauer und Personalplanung Verwendete Literatur:

3 1. EINLEITUNG Vor dem eigentlichen Projektstart ist es erforderlich, eine Aufwandsabschätzung, ausgeführt vom Projektmanager, hinsichtlich Dauer, Ressourcen und Kosten durchzuführen. Dieser hat hierbei die Aufgabe, die Wünsche des Kunden mit der tatsächlichen Projektrealität in Einklang zu bringen. Besonders für den Kunden ist eine genaue Abschätzung von Kosten, Dauer und Ressourcen noch vor dem eigentlichen Projektstart für bspw. Die Budgetfestlegung von großer Bedeutung. Um diesen Stand auch aktuell zu halten und etwaige Änderungen schnell mitteilen zu können, sollten die Schätzungen auch während der weiteren Projektdauer stets aktualisiert werden. Projektaufwandsabschätzung und zeitplanung erfolgen gleichzeitig, wobei die einzelnen Kostenschätzungen bereits in einem frühen Projektstadium nötig sind, um etwa das Projektbudget festzulegen. Das Problem hierbei ist, dass im frühen Stadium wenige Informationen für die Aufwandsabschätzung vorhanden sind. Abbildung 1.1 Projektphase und die entsprechende Art der Abschätzung Somit hat der Projektmanager die Aufgabe folgende Fragen zu beantworten: Wie viel Aufwand ist für die Erledigung einer Aufgabe erforderlich? Wie viel Zeit ist für die Erledigung einer Aufgabe erforderlich? Wie hoch sind die für eine Aufgabe anfallenden Gesamtkosten? 3

4 Um möglichst genaue Schätzungen von Projektdauer und aufwand aufzustellen, greift der Projektmanager zu den Methoden der Aufwands- und Ressourcenplanung. 1.1 Ziele Nach diesem Kapitel sollte der Leser in der Möglichkeit sein: Aufwandsabschätzverfahren erklären und anwenden zu können Projektkosten zu ermitteln Projektzeitpläne zu erstellen Softwarespezifische Kenngrößen und Aufwandsabschätzungen erklären und anzuwenden zu können 1.2 Arten der Aufwandsabschätzung Im frühen Stadium eines Projekts ist die Erstellung einer Größenordnungsanalyse ausschlaggebend für das weitere Vorgehen. Der Fehlerbereich dieses Verfahrens liegt ungefähr bei +/(-) 35%. Diese Schätzung wird ohne detaillierte technische Daten, mittels Skalierungsfaktoren oder parametrischen Methoden durchgeführt. Eine weitere Möglichkeit zur ersten Abschätzung ist, ein Näherungsverfahren zu nutzen. Es wird wie die Größenordnungsanalyse ohne detaillierte technische Daten durchgeführt. Diese Methode verwendet die Erfahrungen aus vergangenen, ähnlichen Projekten. Der Fehlerbereich ist +/(-) 20%. Die dritte und die beste Möglichkeit stellt die definitive oder detaillierte Aufwandsabschätzung dar. In diesem Verfahren werden genaue technische Daten berücksichtigt. Der Fehlerbereich beträgt hierbei +/(-) 5%. Die Aufwandsabschätzung kann wie folgend unterteilt werden: Operativer Aufwand Organisatorischer Aufwand Die Kosten ergeben sich mit Bewertung der Arbeitsleistung: Operative Kosten Organisatorische Kosten Sonstige Kosten 4

5 2. ABSCHÄTZUNG DES OPERATIVEN PROJEKTAUFWANDES 2.1. Phasen-basierte Abschätzung Die Erfahrung zeigt, dass Phasen-basierte Abschätzungsmodelle die beste Anwendung in folgenden Projektarten finden: Projekten, die auf gut definierten, und konsequent verwendeten Lebenszyklen basieren Mittleren bis großen Projekten (Dauer: 6 bis 12 Monate). Projekte, die mehr als 12 Monaten dauern, sind in kleinere Stücke zu zerlegen Für Projekte, die weniger als 6 Monaten dauern, ist eine Deliverable-basierte Abschätzung besser geeignet, da dadurch eine genauere Abschätzung ermöglicht wird. Desweiteren ist es nicht sinnvoll eine phasen-basierte Abschätzung auf Projekte anzuwenden, die in ihrer Art erstmals ausgeführt werden, da für einen effizienten Umgang mit dieser Methode Erfahrungen aus vorangegangenen (ähnlichen) Projekten wünschenswert sind. Hierfür sind Abschätzmethoden durch Experten besser geeignet. Schritt 1: Erstellen oder Wählen eines Phasen-basierten Modells Im ersten Schritt soll ein Phasen-basiertes Modell erstellt werden, das dem eigenen ähnlich ist. So wird die Basis für dieses Modell wie folgt bestimmt: Durch eigene Erfahrung Durch Erfahrungen von Teams im eigenen Unternehmen, die an vergleichbaren Projekten arbeiten/gearbeitet haben Mittels Industrieller Daten Die folgende Tabelle stellt ein Beispiel für solch eine Abschätzung dar: Phase % Requirements 25 Design 30 Code & Unit Test 15 System Testing 20 Implementation 10 Summe 100 Abbildung Phasen-basiertes Modell 5

6 Schritt 2: Anpassung des Phasen-basierten Modells Im nächsten Schritt muss festgestellt werden, ob das ausgewählte Modell für die spezifischen Bedürfnisse des Projektes angepasst werden muss. Eine Anpassung wäre dann notwendig, wenn sich das Projekt auf die Struktur des Modells nicht gänzlich abbildet. Durch diesen Vorgang passt man die Prozente der entsprechenden Phasen des Projektes in Abhängigkeit mit den Spezifikationen des abzuschätzenden Projektes an. Die Abbildung zeigt, dass der Projektmanager sich dazu entschieden hat, den prozentualen Anteil der Design-Phase um 2,5% zu erhöhen. Ein Grund dafür könnte sein, dass bspw. das Projektteam unerfahren mit der Umsetzung des Designprozesses ist. Ähnlich wird die Code & Unit Testing Phase um 7% erhöht, um die Stabilität des Endproduktes zu erhöhen. Die Summe der Aufwandsprozente des angepassten Modells können mehr oder weniger als 100% betragen. Ist das abzuschätzende Projekt weniger komplex als das Modell, dann sollte die Summe des angepassten Modells weniger als 100% sein. Gründe für die Anpassung werden vom Projektmanager genau dokumentiert, um Nachvollziehbarkeit zu gewährleisten. Phase % Requirements 25 Design ,5 Code & Unit Test System Testing 20 Implementation 10 Summe 109,5 Abbildung Angepasstes phasen-basiertes Modell Schritt 3: Schätzung des Aufwandes einer Phase und Extrapolieren des Aufwandes aller Phasen In diesem Schritt wird die Abschätzung einer Phase durchgeführt. Diese Abschätzung sollte so genau wie möglich sein und ist durch die Anzahl der Aufwandsstunden definiert, die für die Fertigung der Phase erforderlich sind. Das Ausmaß dieser einen Phase soll wenigstens 15%, vorzugsweise 20% und ideal 30% des gesamten Projektes betragen. In Abbildung beträgt die Requirements-Phase 25% des gesamten Modells und sollte für eine Schätzung ausreichend sein. 6

7 Ist die Aufwandschätzung für diese Phase erfolgt, kann mit deren Hilfe eine Abschätzung auf alle anderen Phasen extrapoliert werden: 1. Berechne den gesamten extrapolierten Aufwand für das Projekt: Phasen-Abschätzung / Phasen-Prozentsatz 500 / 0.25 = 2000 h 2. Berechne den geschätzte Aufwand für jede verbleibende Phase: Gesamtaufwand * Phasen- Prozentsatz z.b. für Logical Design Phase: 2000 * 0.15 = 300 h Phase % Stunden Requirements Design 30+2, Code & Unit Test System Testing Implementation Summe 109, Abbildung Phasen-basiertes Modell geschätzter Aufwand Schritt 4: Bestimmung der geschätzten Personenmonate (PM) für jede Phase Im nächsten Schritt wird auf die geschätzten Aufwandsstunden ein Algorithmus angewandt, der diese in Personenmonate umwandelt. Der Algorithmus basiert auf der Annahme, dass pro Arbeitstag 6,5 Stunden produktiv gearbeitet werden, sowie 17,5 Tage im Monat als produktiv gelten: 6,5 Stunden/Tag * 17,5 Tage/Monat = 114 Stunden/Monat Der Projektmanager sollte in diesem Schritt sicherstellen, dass nur die realistische produktive Stunden pro Monat eingerechnet wird. Es sollte nicht passieren, dass hohe Zahlen verwendet werden um eine hochproduktive Umgebung darzustellen. 7

8 Phase % Stunden PM Requirements ,38 Design 30+2, ,13 Code & Unit Test System Testing , ,50 Implementation ,75 Summe 109, Abbildung Phasen-basiertes Modell geschätzter PM Schritt 5: Bestimmung der Vollzeit-Äquivalente Um auf die genaue Anzahl dem Projekt zuzuweisenden Ressourcen (Teammitglieder) zu gelangen, müssen viele Informationen schon im Vorhinein bekannt sein. Da dies in der Praxis meist jedoch relativ schwierig festzulegen ist, approximiert man die gesamte Anzahl der vom Projekt zu verbrauchenden Ressourcen. Diese Abschätzung nennt man Optimale Voll-Zeit Äquivalent (OVZA). Eine Formel, die in der Praxis für die Berechnung der OVZA- Ressourcen Verwendung findet ist: OVZA = Der OVZA-Wert ist aber meist nur eine Annahme, da noch nicht exakt bestimmt werden kann, ob die Anzahl der Ressourcen, errechnet durch die OVZA, auch wirklich für das Projekt zur Verfügung stehen. So wird zusätzlich noch eine wahrscheinliche Vollzeit- Äquivalenz (WVZA) bestimmt, die gleich oder kleiner der eigentlichen OVZA sein kann. Phase % Stunden PM OVZA WVZA Requirements ,38 3,0 3 Design 30+2, ,13 3,5 3 Code & Unit Test ,85 3,0 3 System Testing ,50 3,0 3 Implement ,75 2,0 2 Summe 109, Abbildung Phasen-basiertes Modell OVZA und WVZA 8

9 Schritt 6: Bestimmung der geschätzten Dauer der Phase. Um die geschätzte Dauer (in Monaten) der Phase zu berechnen, dividiert man die geschätzten PM der Phase mit der angenommenen WVZA-Anzahl. Abbildung zeigt die geschätzte Dauer für jede Phase. Phase % Stunden PM OVZA WVZA M Requirements ,38 3,0 3 1,5 Design 30+2, ,13 3,5 3 2,1 Code & Unit Test ,85 3,0 3 1,3 System Testing ,50 3,0 3 1,2 Implement ,75 2,0 2 1 Summe 109, Abbildung Phasen-basiertes Modell geschätzte Phasendauer Aufgrund der möglichen Überlappung einzelner Phasen kann die Gesamtdauer allerdings nicht aufsummiert werden. Diese Überlappungen werden im nächsten Kapitel eingehend erläutert. Abschätzung der Projektzeitdauer Im obigen Kapitel haben wir die Gesamtdauer der einzelnen Phasen berechnet. Diese Zahlen können aufgrund der Überlappungen einzelner Phasen nicht aufsummiert werden. Um die Gesamtdauer des Projektes zu erhalten, muss der Projektmanager einen Phasenbasierten Ganttgraph für das Projekt entwickeln. Die geschätzte Gesamtdauer dieses Projektes beträgt zwischen 6 und 8 Monaten. Wie kann man jetzt mit den Überlappungen umgehen? Welche Überlappungen sind relevant? In diesem Bereich gibt es keine festen Ansätze. Der Projektmanager sollte anhand seines Wissens und seiner Erfahrung über das Projekt entscheiden. Das kann er z.b. durch die Konsultation mit den Teammitgliedern schaffen Deliverable-basierte Abschätzung Phasen-basierte Abschätzungen sind normalerweise bei Projekten anzuwenden, die mehr als 6 Monaten dauern. Für Projekte, die eine Dauer von 6 Monate nicht überschreiten, liefert in der Regel die Deliverable-basierte Abschätzung bessere und genauere Ergebnisse. Diese Abschätzung besteht aus 6 Stufen: 9

10 1. Definiere die Phasen des Projektes 2. Unterteile jede Phase in Deliverables 3. Beschreibe jedes Deliverable 4. Aufwandsabschätzung für jedes Deliverable 5. Bestimme Project Gantt-Chart und Projektlaufdauer 6. Bestimme die Projektkosten Die größte Gefahr hierbei stellen nicht erkannte Deliverables dar. Diese Gefahr lässt sich nur durch ausgiebige Kommunikation unter den Teammitgliedern bei der Erstellung des Projektstrukturplanes mindern. Beim Deliverable-basierten Ansatz verwendet man vordefinierte Templates (siehe Abb ), um den Aufwand für einzelne Deliverables abzuschätzen. Ein Template besteht aus folgenden Punkten: Deliverable Name: Der Name des Deliverable. Innerhalb einer Unternehmung sollten standardisierte Namen verwendet werden. Owner: Zuständige Rolle oder Person. Beschreibung: Kurz und prägnant. Das Ziel ist, dass alle, die das Deliverable lesen, sich dadurch das gleiche Bild verschaffen können. Erfolgskriterien: Von den Entwicklern festgelegte Kriterien, die einen erfolgreichen Abschluss definieren. Benötigte Ressourcen: Der Ressourcen- und Fachwissen-Typ, der für die Fertigstellung des Deliverable benötigt wird. Z.B. erfahrener Softwareentwickler im Bereich der Objektorientierung, C++ und XML. Mögliche Ressourcen: Der Name der Person, die das Deliverable fertigen muss. Falls die Angabe des Namens nicht möglich ist, genügt die Angabe über den Arbeitstitel. Geschätzter Aufwand: Die Anzahl der Stunden, die für die Fertigstellung der oben genannte Ressourcen benötigt werden. Geschätzte Fertigstellungsdauer: Die Anzahl der Arbeitstage, die für die Fertigstellung des Deliverable benötigt werden. Geschätzte Kosten: Geschätzte Gesamtkosten des Projekts. Errechnet sich durch Multiplikation des geschätzten Aufwandes mit dem Ressourcenstundensatz. Lag: Darstellung von Abhängigkeiten zwischen verschiedenen Deliverables 10

11 Deliverable Name Deliverable Owner Beschreibung Erfolgskriterien Benötigte Ressourcen Mögliche Ressourcen Geschätzter Aufwand Geschätzte Fertigstellungsdauer Lag Geschätzte Kosten Kundenanforderung für GUI Business Analyst Dokument zur Beschreibung der Anforderungen der Benutzer an das grafische User Interface Geeignet für Kundenreview 1 Mid-Level Business Analyst, 1 Mid-Level Technical Writer Wie oben 24 h Mid-Level Technical Writer 10 h Mid-Level Business Analyst 6 Tage 5 Tage Noch nicht bestimmt Abbildung Deliverable-basierte Abschätzung - Template Verwendung von Deliverables-basierten Abschätzungen Die Deliverable-basierten Abschätzungen sind für folgende Bereiche geeignet: Mittelgroße Projekte (Dauer 4-6 Monate): Bei Projekten, die länger als 6 Monate dauern, kann dieser Ansatz für die Abschätzung der ersten 6 Monate verwendet werden (danach phasen-basierte Abschätzung!). Bei Projekten deren Laufzeit kürzer als 4 Monate ist, ist vorzugsweise die Taskbasierte Abschätzung anzuwenden. Große Updateprozesse (Patches) Wichtige technologische Projekte 2.3. Genauigkeitsgrad Der Genauigkeitsgrad der Deliverable-basierten Abschätzung hängt von folgenden Kriterien ab: Umfang der Liste der Deliverables jeder Projekt-Phase, das Fehlen weniger Deliverables kann bereits gravierende Fehler verursachen Richtigkeit der Annahme über die Fähigkeiten der Ressourcen Einkalkulierung aller möglichen Verzögerungen 11

12 Erfahrung der Person, die die Abschätzungen durchführt (meist hat diese Person meist erst nach 3-4 ausgeführten Abschätzungen die Erfahrung, diese fehlerfrei durchzuführen) 2.4. Einzuplanende Reserven Die Praxis hat gezeigt, dass das Einplanen von Reserven sinnvoll ist. Der Grund hierfür liegt in der Unsicherheit der Abwicklung des Projektes. Deswegen ist es durchaus sinnvoll, für folgende Aufwendungen Reserven einzuplanen: Aufwand für Überarbeitungen Aufwand für wachsenden Projektumfang Reserven für schwer vorhersehbare Risiken (Es werden 10% für diese Risiken empfohlen) Reserve für Überarbeitungen Der Bedarf an Überarbeitungsreserven zeichnet sich vor allem in technischen Projekten mit hoher Komplexität ab. Desweiteren besteht auch in Projekten, deren Gesamtdauer 4 Monate deutlich überschreitet, ein Bedarf für Reserven. Die wichtigsten Gründe für die Überarbeitung sind technologische Upgrades, Design-Überarbeitungen, usw. Bei unerfahrenen Teammitgliedern kommt es häufiger vor, dass sie gewisse Anforderungen ihres Tasks nicht Zustandebringen, es jedoch aber erst gegen Ende ihrer Fristen bemerken. In diesem Fall liegen zur Behebung des Problems zwei Lösungsansätze vor: Entweder den Task sofort an Ort und Stelle überarbeiten und richtigstellen, oder sich dem Task (sofern die Abhängigkeiten es zulassen) zu einem späteren Zeitpunkt erneut widmen. Aufgrund der meist eng gestaffelten Zeitpläne kommt meistens der zweite Ansatz zum Einsatz Reserve für wachsenden Projektumfang Aufgrund des unmittelbaren Zusammenhangs zwischen Komplexität und den daraus entstandenen Unsicherheiten, kann es bei Projekten mit hoher Komplexität passieren, dass Deliverables erst im Nachhinein festgestellt werden. Der Hauptgrund hierfür ist einerseits der ständig wachsende Projektumfang und anderseits fehlendes Verständnis der Kundenbedürfnisse, kombiniert mit instabiler Projektumgebung. Durch den wachsenden Projektumfang verändern sich natürlich wiederum sämtliche Abschätzungen zeitlicher und ressourcentechnischer Natur. In der Abbildung werden die empfohlenen Reserven für verschiedene Komplexitätsgrade eines Projekts dargestellt. 12

13 Technical Complexity (high) II high technical challenge simple 5 % 15 % I very complex 10 % high business situation IV III 0 (low) Business Complexity 4 (high) Abbildung Komplexität des Projektes und der Wachstum des Anwendungsbereiches 2.5. Detaillierte Aufwandsabschätzung In der Launch-Phase muss der Projektmanager eine realistische und genaue Abschätzung für den Aufwand abgeben, was aufgrund verschiedener Unsicherheitsfaktoren problematisch ist. Personalressourcen sind noch nicht zugesichert, sodass deren Fähigkeiten nicht festgestellt werden können. (Erfahrungen, Softskills, Produktivität etc.) Um das Problem zu lösen, dass noch nicht alle Konditionen bekannt sind, wurde ein dreistufiger Abschätzungsprozess eingeführt: 1. Definiere einen normalen Wert der Aufwandsabschätzung für jeden Task. Diese normale Abschätzung nennt man Baseline Effort. 2. Definiere einen Anpassungsfaktor, der die Variablen wie Skills der Mitarbeiter und Arbeitsumgebung behandelt. Dieser Faktor nennt sich Effort Variance Factor (EVF). 3. Berechne den abgeschätzten Aufwand für die verschiedenen Tasks. Die Berechnung erfolgt durch die Anpassung der Baseline Effort mit dem entsprechenden Effort Variance Factor der zugestellten Ressourcen. Adjustment Factor(s) Task Baseline Effort Estimated Effort Abbildung Konvertierung des Baseline-Aufwands zum Abschätzung des Task-Aufwands 13

14 Dieser Prozess liefert Ergebnisse, die ausreichend akkurat sind und leicht dem Management und den Kunden erläutert werden können Baseline Effort Unter Baseline Effort versteht man die Aufwandsstunden, die eine Person benötigt, um mit dem vorgegebenen Task fertig zu werden. Dies erfolgt unter folgenden Annahmen: Die Person besitzt einen hohen Grad an Businesswissen Die Person besitzt einen hohen Grad an technischem Wissen Eine vollzeitige Zuweisung zum Task Arbeitsumgebung mit hoher Produktivität Keine Unterbrechungen Typische Ressourcen für Baseline Effort Daten sind unternehmerische Vergangenheit, industrielle Daten, Teammitglieder usw. Diese Daten werden typischerweise in einer Baseline Effort Datenbank gespeichert Effort Variance Factor Da an einem Projekt jedoch deutlich mehr als eine Person mit zudem noch unterschiedlichen Fähigkeiten beteiligt sind, sind auch verschiedenste Motivations-, Schnelligkeits-, Erfahrungs- und Unterbrechungsraten zu berücksichtigen. Diese Varianz der Arbeitsproduktivität der einzelnen Teammitglieder kann dramatische Auswirkungen auf die Dauer und den Aufwand der einzelnen Tasks haben und muss deswegen unbedingt in die Abschätzung miteinbezogen werden. Deswegen muss der Projektmanager zuerst die Profile der einzelnen Mitglieder auswerten und so spezifische EVF ableiten. Der EVF lässt sich aus folgenden Faktoren berechnen: Skill-Faktor (SF) Work Interruption Factor (WIF) Multiple Project Factor (MPF) Project Productivity Influencing Factor (PPIF) Skill Factor (SF) Von den vier EVF Faktoren, hat der Skill Faktor den größten Einfluss auf die, für die Fertigstellung eines Tasks benötigte Zeit. Die Berechnung des SF besteht aus zwei Stufen, nämlich der Beurteilung des individuellen Skill-Grades und der Zuweisung eines numerischen Wertes, sowie die tatsächliche Berechnung des Skill-Faktors. 14

15 In der ersten Stufe überprüft der Projektmanager den Skill-Grad und die Erfahrung des betroffenen Mitgliedes und weist ihm einen Wert von 1 bis 4 zu, wobei diese Werte in steigender Reihenfolge, der Höhe des Kompetenzgrades des Mitglieds entsprechen. Im zweiten Schritt weist er diesen Graden einen passenden Skill-Faktor zu. Diese Faktoren zeigen das Tempo, mit dem der Mitarbeiter einen Task fertigstellen wird, auf. Je kleiner der Skill-Grad, desto länger die Fertigungszeit. Ein Mitarbeiter mit dem Skill-Level 4 bekommt den Skill-Faktor 1 zugewiesen. Die folgende Abbildung zeigt die einzelnen Werte und deren Bedeutung. Skill Level Beschreibung SF 4,0 Exzellente Erfahrung, Fachbereichsexperte 1,0 3,5 Kompetent in allen Task-relevanten Fähigkeiten, solides Fachbereichswissen, erfahren 3,0 Grundlegende Kompetenzen für Task, etwas Einblick in Fachbereich, mäßig erfahren 2,5 Weniger als 50 % der notwendigen Kompetenzen für Task, etwas Einblick in Fachbereich, mäßig erfahren 2,0 Etwas Erfahrungen im Fachbereich, intensives Training zur Erreichung der notwendigen Kompetenzen erforderlich, gute Arbeitseinstellung 1,5 wenig Erfahrungen im Fachbereich, intensives Training zur Erreichung der notwendigen Kompetenzen erforderlich, gute Arbeitseinstellung 1,0 keine Erfahrungen im Fachbereich, intensives Training zur Erreichung der notwendigen Kompetenzen erforderlich, keine Arbeitserfahrung 1,5 2,0 2,5 3,0 3,5 4,0 Abbildung Fähigkeitsbeschreibung und jeweilige Fähigkeitsstufen Work Interruption Factor (WIF) WIF ist ein Maßstab, der Produktivitätsverlust durch nicht projektbezogene Aktivitäten und nicht geplante Unterbrechungen während eines Arbeitstages angibt. Beispiele für diese Aktivitäten und Unterbrechungen sind Teambesprechungen, Reviews, Lesen und Beantwortung von s, Nichtverfügbarkeit von Rechnern (z.b. durch Virus, Abstürze, Wartung) usw. Diese Unterbrechungen sind meist eine Folge einer unkontrollierten Arbeitsumgebung. Wenn beispielsweise ein Mitarbeiter in zwei Bereichen beschäftigt ist (beispielsweise wurden ihm zwei Tasks zugeordnet), dann werden während des Tages beide Tasks untereinander für 15

16 Unterbrechungen verantwortlich sein, da er immer wieder die Tasks wechseln wird bzw. muss. Unerfahrene Teammitglieder werden öfter Unterstützung durch erfahrene Kollegen benötigen, die wiederum dadurch von ihren zugewiesenen Tasks abgelenkt werden. Dieser Faktor darf nicht außer Acht gelassen werden, denn auch wenn nur 10 Minuten für eine Unterbrechung einkalkuliert werden, so sind das bei einem 8 Stunden Tag, der 8 Arbeitsunterbrechungen mit sich bringt, in Summe 80 Minuten. Für die Berechnung des WIF bedienen wir uns des Verhältnisses zwischen Arbeitsunterbrechungen und der, für die Fertigstellung des Tasks benötigten Zeit. Dieses Verhältnis ist nicht linear. Doch auch wenn bspw. das Teammitglied 25% seiner Zeit durch Unterbrechungen verliert, ist der Nettoverlust ungleich höher, da Konzentration und Fokus für seine eigentliche Aufgabe nach einer Unterbrechung erst wiederhergestellt werden müssen. Die Formel für die Berechnung des WIF für einzelne Mitarbeiter ist: D.h. ein Mitarbeiter, der 25% Zeiteinbußen aufzuweisen hat, hat einen WIF von: Folgende Tabelle gibt einen Überblick über Zeitverlust und dem dazugehörigen WIF: Zeitverlust (%) WIF Abbildung Überblick über die WIF Werte Ein Mitarbeiter, der einen Task in 10 Stunden ohne Unterbrechung fertigstellen kann, würde also 13,3 Stunden für denselben Task mit 25% Zeitverlust benötigen. Um dies in einer Aufwandsabschätzung zu berücksichtigen, sollte der Projektmanager nie mehr als 80% der Arbeitszeit verplanen, um ein akkurates Abschätzungsergebnis zu erhalten. Zusätzlich empfiehlt es sich, Mitarbeiter vor Störungen jedweder Art so gut als möglich abzuschotten. 16

17 Multiple Project Factor (MPF) Die höchste Produktivität wird dadurch erreicht, indem man die einzelnen Mitarbeiter vollzeitig einem Projekt zuweist. Dadurch wird die volle Konzentration auf einen Task fokussiert und der optimale Einsatz garantiert. Wenn der Mitarbeiter mehreren Aufgaben oder Projekten zugewiesen wird, führt dies zum Verlust von Konzentration und Fokus was wiederum zu deutlich geringerer Produktivität führt. Natürlich hängt der Konzentrations- und Fokusverlust vom Individuum ab, da manche Mitarbeiter besser mit dieser Art des Multitaskings umgehen können, während andere Teammitglieder große Schwierigkeiten aufweisen, sich wieder in den ursprünglichen Task einzufinden. Dieser Zeitverlust wird als Multiple Project Factor bezeichnet. Die Formel für die Berechnung des MPF ist ähnlich der für die Berechnung des WIF: Empfohlen Werte für Zeitverluste werden in der folgenden Tabelle gezeigt: Anzahl Projekte % Zeitverlust MPF 1 0 % 1,00 2 bis zu 10 % 1,11 3 bis zu 15 % 1,18 4 bis zu 20 % 1,25 Abbildung MPF Werte Project Productivity Influencing Factor (PPIF) Auf die Produktivität der einzelnen Mitarbeiter kann noch eine weitere Reihe von Faktoren Einfluss haben: Number of Nemesis (1,0 und 1,5) 1 für maximal 2 Nemesis Stakeholder Team Locations - 1 bei einem Ort, sonst je Kommunikationsaufwand Customer Locations (1,0 und 1,5) wie bei Team Locations Team size (1,0 und 1,5) - 1 wenn das Team aus 7 oder weniger Mitglieder besteht, sonst je Größe u. Komplexität Team Synergy (1,0 und 1,5) - 1 gute Zusammenarbeit, 1,5 chaotische Struktur Team-Customer Synergy (1,0 und 1,5) - 1 gute Zusammenarbeit, 1,5 chaotische Struktur Tool Stability (1,0 und 1,5) - 1 gut eingeführte Tools, bei Veränderungen >1 17

18 Turnover Rate Staff (1,0 und 1,5) 1 bei durchschnittlicher 10%-Übergangsrate, 1,5 bei 30% oder mehr Vendor Support (1,0 und 1,5) 1 bei Support unter 4 Stunden, 1,5 bei schlechtem Support Project Manager s Skill (1,0 und 2,0) - 2 bei PM Anfänger, 1 sehr erfahren Die Berechnung erfolgt durch das Aufsummieren von vorhandenen Faktoren und Division durch die Anzahl der Faktoren. Z.B.: Number of Nemesis: 5 Wert: 1,25 Team Locations: 4 Wert: 1,20 Customer Locations: 4 Wert: 1,20 Project Manager s Skill durchschnittlich Wert: 1, Berechnung des EVF Jetzt haben wir die vier primären Einflussfaktoren berechnet und können den EVF berechnen. Das Ergebnis der Berechnung können wir verwenden, um die geschätzte Werte des Baseline Efforts anzupassen. Kompetent: Skill Factor 1,5 25% Unterbrechungen WIF = 1,33 vollzeitige Zuweisung MPF = 1,0 Produktivitätsumgebung PPIF = 1,2 D.h. bei einem Task mit einem Baseline Effort von 10 Stunden, werden dieser Person 24 Aufwandsstunden abverlangen. Je größer das EVF ist, desto mehr Aufwand wird benötigt, um den Task fertigzustellen. Die weitere Abschätzung besteht aus der Abschätzung der Dauer der Tasks, der Lags, Bestimmung der Überlappungen und der Gesamtdauer Der Projektzeitplan Die Erstellung des Projektzeitplans umfasst den Vorgang, bei dem die konkreten Ressourcen (Personen) zu den einzelnen Tasks zugeordnet werden und der geschätzte Aufwand angepasst wird (Bewertung der einzelnen Mitarbeiter und Berechnung ihres EVF), sodass der Netzplan (PERT Chart) überprüfen werden kann und ein erster Projektzeitplan 18

19 mit tatsächlichen Terminen festgellegt wird. Die Festlegung erfolgt meist durch ein Balkendiagramm oder einen Gantt Chart. Dabei sind meist zwei Typen von Gantt Chart hilfreich, der Task Gantt Chart und der Ressource Gantt Chart. Der Task Gantt Chart stellt den Projektzeitplan in chronologischer Reihenfolge dar und zeigt die Start- und Endzeiten auf: Nr. Task Name Dauer Mo KW 23 Di Mi Do Fr Sa So Mo Di Mi T 1.1 Interview Planen 1 Tag Maria T 1.2 Interview durchführen 2 Tage Maria T 1.3 Viewpoint Analyse 2 Tage Josef T 1.4 Fachbereich einarbeiten 4 Tage Maria T 1.5 Pflichtenheft erstellen 5 Tage Abbildung Task Gantt Chart Der Ressource Gantt Chart hingegen setzt den Fokus auf die Verbindung der Tasks mit den Ressourcen (den Teammitgliedern): Nr. Task Name Dauer Mo KW 23 Di Mi Do Fr Sa So Mo Di Mi T 1.1 Interview Planen 1 Tag Maria T 1.2 Interview durchführen 2 Tage Maria T 1.4 Fachbereich einarbeiten 4 Tage Maria Abbildung Ressource Gantt Chart Die Gantt Charts werden heute mithilfe einer Software erstellt und können Phasen, Deliverables, Tasks und Milestones darstellen. Der Nachteil von Gantt Charts ist, das sie große Prozesse nicht übersichtlich darstellen können. Die Aufgabe des Projektmanagers hierbei stellt die ständige Aktualisierung der Pläne dar. Weitere Möglichkeiten, die sich unter Projektmanagern durchgesetzt haben, um eine Übersicht über den Verlauf des Projektes zu bewahren: 1. Eine Liste von Deliverables erstellen 2. Eine Liste von den Deliverable Owner erstellen 3. Eine Liste der Milestones erstellen Hierbei stellt die Liste der Deliverables eine alphabetische Anordnung dar und dient dem Projektmanager als Übersichtsliste zum Status der einzelnen Deliverables. Kann eine Deliverable zum geplanten Zeitpunkt nicht gestartet oder beendet werden, so wird dies sofort in einer zusätzlich Spalte vermerkt, um dem Projektmanager, aber auch dem Deliverable 19

20 Owner einen optimalen Überblick über eventuell kritische Projektphasen geben zu können. Auch eventuelle Zeitreserven, die durch früh beendete Deliverables erreich werden, werden so vermerkt. Die Liste der Deliverable Owners stellt eine alphabetische Anordnung der Bearbeiter der Deliverables dar. So werden dem Projektmanager die Zusammenhänge der Deliverables und der Team Mitglieder, aber auch der Status der Deliverables übersichtlich näher gebracht. Die Liste der Milestones soll einen Überblick dieser und über deren Status geben. Diese sind chronologisch, angefangen bei Projektstart bis hin zum Projektende, geordnet und soll dem Projektmanager so einen Überblick über den aktuellen Fortschritt des Projektes geben. 20

Aufwands- und Ressourcenplanung

Aufwands- und Ressourcenplanung Projektmanagement - Block 6 Aufwands- und Ressourcenplanung Institut für Informationssysteme und Computer Medien (IICM) Fakultät für Informatik - Technische Universität Graz, Austria Christian Gütl Version

Mehr

Software Engineering (SE)

Software Engineering (SE) Software Engineering (SE) 3) Planungsphase Prof. Dr. Anja Metzner Hochschule Augsburg, Fakultät für Informatik Kontakt: anja.metzner@hs-augsburg.de Studiengang WiBac 4 (Stand: 15.03.2014), Hochschule Augsburg,

Mehr

1 Allgemeines. 2 Fragenkatalog. Prüfungsfragenkatalog Projektmanagement SS2006 Version 1.01 2006-06-02. 2.1 Block 1: Das Unternehmen als Projektumfeld

1 Allgemeines. 2 Fragenkatalog. Prüfungsfragenkatalog Projektmanagement SS2006 Version 1.01 2006-06-02. 2.1 Block 1: Das Unternehmen als Projektumfeld Prüfungsfragenkatalog Projektmanagement SS2006 Version 1.01 2006-06-02 1 Allgemeines Der hier zur Verfügung gestellten Fragenkatalog versteht sich als Serviceleistung zur Prüfungsvorbereitung. Es werden

Mehr

Management großer Softwareprojekte

Management großer Softwareprojekte Management großer Softwareprojekte Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin, Institut für Informatik Fraunhofer Institut für Rechnerarchitektur und Softwaretechnik FIRST H. Schlingloff,

Mehr

1 Software Projektplanung

1 Software Projektplanung 1 Software Projektplanung Zu Beginn wird von dem Projektleiter (Projektverantwortlicher) ein Projektplan erstellt. In dieser ersten Version des Projektplans müssen alle Aktivitäten enthalten, sowie gewisse

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

Aufwandsabschätzung (1)

Aufwandsabschätzung (1) Aufwandsabschätzung (1) Die Bank GuterKunde GmbH will ein Online- Banking umsetzen. Es soll all die Funktionen haben, die ein Standard-Online-Banking bietet. Wie lange brauchen Sie dafür? Einfache Frage,

Mehr

Projektmanagement. Projektmanagement

Projektmanagement. Projektmanagement Projektmanagement Dipl.-Ing. Oliver Lietz Was ist ein Projekt? Projektmanagement Eindeutiges Ziel Individuell (einmalig) Begrenzt (Anfang und Ende) Komplex (keine Routineaufgabe) Warum Projektmanagement

Mehr

Schätzverfahren in der Softwareentwicklung

Schätzverfahren in der Softwareentwicklung Datum: 27. Mai 2009 Themendossier Schätzverfahren in der Softwareentwicklung Seite 1 Einführung in das Thema Eine zuverlässige Aufwandsschätzung zu Beginn eines Softwareprojekts ist eine unerlässliche

Mehr

Software-Projektmanagement

Software-Projektmanagement Software-Projektmanagement Björn Lohrmann Software Engineering Projekt Technische Universität Berlin WS 2007/2008 February 1, 2008 Software-Projektmanagement 1/29 Gliederung Gliederung des Vortrags: Begriffe

Mehr

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering mit Übungen Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering 2 Organisation Ort: Seminarraum 05.002, Spiegelgasse 5 Ablauf: 15:15 Vorlesung Prüfung: Schriftlich,

Mehr

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003):

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003): Professionelles Projekt-Management in der Praxis Veranstaltung 7 Teil 1 (30.06.2003): Prof. Dr. Phuoc Tran-Gia, FB Informatik, Prof. Dr. Margit Meyer, FB Wirtschaftswissenschaften, Dr. Harald Wehnes, AOK

Mehr

Aufwandsschätzung in Scrum

Aufwandsschätzung in Scrum Aufwandsschätzung in Scrum 1 Planning Poker und Varianten 2 HINWEIS Aus lizenzrechtlichen Gründen sind in dem Handout die meisten Bilder und Grafiken entfernt worden. Ich bitte um Verständnis. 3 1. Scrum

Mehr

Projektmanagement Vorlesung 14/ 15: Wiederholung ausgewählter Themen zur Klausurvorbereitung. Prof. Adrian Müller, PMP, PSM-1, CSM FH Kaiserslautern

Projektmanagement Vorlesung 14/ 15: Wiederholung ausgewählter Themen zur Klausurvorbereitung. Prof. Adrian Müller, PMP, PSM-1, CSM FH Kaiserslautern Projektmanagement Vorlesung 14/ 15: Wiederholung ausgewählter Themen zur Klausurvorbereitung Prof. Adrian Müller, PMP, PSM-1, CSM FH Kaiserslautern phone: +49 631/3724-5329 http://www.hs-kl.de/~amueller

Mehr

Aufwandschätzung für Softwareprojekte

Aufwandschätzung für Softwareprojekte Steve McConnell Aufwandschätzung für Softwareprojekte Microsoft Inhaltsverzeichnis Einleitung 15 Kunst vs. Wissenschaft der Schätzung 15 Warum und für wen dieses Buch geschrieben wurde 16 Der Nutzen dieses

Mehr

RE-Metriken in SCRUM. Michael Mainik

RE-Metriken in SCRUM. Michael Mainik RE-Metriken in SCRUM Michael Mainik Inhalt Agile Methoden Was ist SCRUM? Eine kurze Wiederholung Metriken Burn Down Graph Richtig schätzen Running Tested Features WBS/ Earned Business Value Business Value

Mehr

SOFTWARETECHNIK. Kapitel 8 Projektmanagement. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing.

SOFTWARETECHNIK. Kapitel 8 Projektmanagement. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. SOFTWARETECHNIK Kapitel 8 Projektmanagement Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. Armin Zimmermann Inhalt Projektmanagement Projektplanung Projektdurchführung

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

Softwaremessung und -metrik

Softwaremessung und -metrik Softwaremessung und -metrik AW1 Votrag - Daniel Wojtucki Hamburg, 20. Januar 2010 Inhalt 1 Einleitung 2 Softwarequalität 3 Grundlagen der Softwaremetrik 4 Beispiele bestimmter Metriken 5 Zusammenfassung

Mehr

Management von IT- Projekten. Einführung in Projektmanagement und ausgewählte Schwerpunktthemen

Management von IT- Projekten. Einführung in Projektmanagement und ausgewählte Schwerpunktthemen Management von IT- Projekten Einführung in Projektmanagement und ausgewählte Schwerpunktthemen Magisches Dreieck Kosten Qualität Zeit => welche Auswirkungen auf Planung? Beispiel 1 2 Key-Account-Kunden

Mehr

Agiles Schätzen. Quelle: Kap. 7 aus Wie schätzt man in agilen Projekten oder wieso Scrum-Projekte erfolgreicher sind [Boris Gloger 2014]

Agiles Schätzen. Quelle: Kap. 7 aus Wie schätzt man in agilen Projekten oder wieso Scrum-Projekte erfolgreicher sind [Boris Gloger 2014] Agiles Schätzen Quelle: Kap. 7 aus Wie schätzt man in agilen Projekten oder wieso Scrum-Projekte erfolgreicher sind [Boris Gloger 2014] Schätzen der Größe Wir bestimmen die Größe, nicht den Aufwand. Auf

Mehr

Zeit- und Ressourcenplanung leicht gemacht - Unterstützung durch Simulation

Zeit- und Ressourcenplanung leicht gemacht - Unterstützung durch Simulation - für Zeit- und Ressourcenplanung leicht gemacht - Unterstützung durch Simulation Zeit- und Ressourcenplanung leicht gemacht - Unterstützung durch Simulation Thomas Hanne *, Patrick Lang, Stefan Nickel,

Mehr

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Andreas Armbrecht Siemens AG Darmstadt, 01. 02. Dezember 2009 Business Unit Rail Automation Systeme der Eisenbahnautomatisierung

Mehr

Wintersause 2007. Kostenschätzung II. Das Planungsrahmenwerk. Aufwandsschätzung nach Whatt S. Humphrey FG Software Engineering

Wintersause 2007. Kostenschätzung II. Das Planungsrahmenwerk. Aufwandsschätzung nach Whatt S. Humphrey FG Software Engineering Kostenschätzung II! Protokoll der bisherigen Arbeitszeit / Produktivität! Schätzung für verbleibende Dokumente (am besten phasenbasiert, Gewichtung z.b. gemäß vorgegebenem Zeitplan)! Schätzung für Implementierung

Mehr

Thema: Risikomanagement

Thema: Risikomanagement 1.1. Risikomanagement Eine der elementarsten Anforderungen an die Projektplanung ist, durch zielgerichtete Planung mögliche Risiken, die den Projekterfolg in Frage stellen, zu identifizieren und präventiv

Mehr

Gemeinsame Projektbearbeitung mit Project Professional und Project Web Access

Gemeinsame Projektbearbeitung mit Project Professional und Project Web Access Gemeinsame Projektbearbeitung mit Project Professional und Project Web Access Gemeinsame Projektbearbeitung mit Project Professional und Project Web Access Projektteam Führungskraft Portfolio Management

Mehr

Software Engineering

Software Engineering Software Engineering Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik Prof. A. Müller, FH KL Software Engineering 2015 1 Inhalte Begrüßung Vorstellung, Übersicht Formales

Mehr

>EasyMain Die Nutzung von Methoden, Prozessen und Standards im Rahmen eines Application Lifecycle Managements

>EasyMain Die Nutzung von Methoden, Prozessen und Standards im Rahmen eines Application Lifecycle Managements >EasyMain Die Nutzung von Methoden, Prozessen und Standards im Rahmen eines Application Lifecycle Managements 6. Januar 2014 >Agenda Motivation EasyMain Methoden, Standards und Prozesse bei EasyMain Folie

Mehr

Grundlagen der Verwendung von make

Grundlagen der Verwendung von make Kurzskript zum Thema: Grundlagen der Verwendung von make Stefan Junghans Gregor Gilka 16. November 2012 1 Einleitung In diesem Teilskript sollen die Grundlagen der Verwendung des Programmes make und der

Mehr

Case 7: Kostenschätzung

Case 7: Kostenschätzung Universität Trier WS 2009/2010 Lehrstuhl für Wirtschaftsinformatik I Gebäude H / Campus II D-54296 Trier Management von Softwareprojekten Case 7: Kostenschätzung Gruppe 7a Sebastian Baltes, Johannes Thull

Mehr

Informationssystemanalyse Personal Software Process 8 1

Informationssystemanalyse Personal Software Process 8 1 Informationssystemanalyse Personal Software Process 8 1 Personal Software Process Sehr eng mit dem CMM hängt der PSP (Personal Software Process) zusammen. Der PSP ergänzt das organisationsweite CMM um

Mehr

Projektplan. Software Engineering Projekt. November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1

Projektplan. Software Engineering Projekt. November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1 Projektplan Software Engineering Projekt November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1 Der Projektplan Grundlage der gemeinsamen Arbeit innerhalb des Teams und mit

Mehr

Agile Programmierung - Theorie II SCRUM

Agile Programmierung - Theorie II SCRUM Agile Programmierung - Theorie II SCRUM Arne Brenneisen Universität Hamburg Fakultät für Mathematik, Informatik und Naturwissenschaften Seminar Softwareentwicklung in der Wissenschaft Betreuer: Christian

Mehr

Veranstaltung Projektmanagement

Veranstaltung Projektmanagement Fallstudie Projektplanung- und Fortschrittskontrolle Veranstaltung Projektmanagement Fachhochschule Köln Fakultät für Informatik Campus Gummersbach Inhaltsverzeichnis Fallstudie V... Part Ressourcenzuordnung...

Mehr

Agiles Testmanagment. Hugo Beerli bbv Software Services AG. Luzern, September 2011. www.bbv.ch

Agiles Testmanagment. Hugo Beerli bbv Software Services AG. Luzern, September 2011. www.bbv.ch Agiles Testmanagment Hugo Beerli bbv Software Services AG Luzern, September 2011 Product Backlog (Agenda) 1) Warum System Tests 2) Agile Arbeitsmethode Stand up Meeting 3) Vorteile der agilen Methode 4)

Mehr

ACTANO Trainingskatalog

ACTANO Trainingskatalog ACTANO Trainingskatalog Dieter Walcher Juni 2014 Unsere Trainings: Überblick Modul- und kundenspezifisches Training Die RPLAN Academy trainiert alle Module und Aspekte von RPLAN und kollaborativem Projektmanagement.

Mehr

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert The Rational Unified Process Eine Einführung von T. Langer und A. Nitert Übersicht Einleitung Probleme der SW-Entwicklung, Best Practices, Aufgaben Was ist der Rational Unified Process? Struktur des Prozesses

Mehr

Informationssystemanalyse Software Risk Evaluation 7 1

Informationssystemanalyse Software Risk Evaluation 7 1 Informationssystemanalyse Software Risk Evaluation 7 1 Software Risk Evaluation Um Risiken bei Software-Projekten abzuschätzen und ihnen zu begegnen, wurde am SEI die Software Risk Evaluation-Methode entwickelt.

Mehr

3 Projektmanagement. Auch hier lassen sich wieder grob kommerzielle und nicht kommerzielle Projekte unterscheiden.

3 Projektmanagement. Auch hier lassen sich wieder grob kommerzielle und nicht kommerzielle Projekte unterscheiden. 3 Projektmanagement Das Thema Projektmanagement kann man aus sehr unterschiedlichen Perspektiven angehen. Klar strukturiert mit Netzplänen und Controlling- Methoden oder teamorientiert mit Moderationstechniken

Mehr

Initiierung von Projekten. CINCIOGLU Ayten SAHIN Sümeyye Selcen

Initiierung von Projekten. CINCIOGLU Ayten SAHIN Sümeyye Selcen Initiierung von Projekten CINCIOGLU Ayten SAHIN Sümeyye Selcen 1 Übersicht Initiierungsphase Projekt-Lebenszyklus Kriterien für Projektplanung Business Case Erfolgskriterien und Aufbau des Business Case

Mehr

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung Kapitel B Vorgehensmodelle Inhaltsverzeichnis 1 B Vorgehensmodell... 3 1.1 Welche Vorgehensmodelle sind

Mehr

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 Software Testing Automatisiert Manuell 100% 70% 1 Überwiegender Teil der Testing Tools fokusiert auf automatisiertes Testen Microsoft

Mehr

Betriebswirtschaftliche Kriterien, Aufwand und Nutzen von CMMI-Implementierungen

Betriebswirtschaftliche Kriterien, Aufwand und Nutzen von CMMI-Implementierungen Betriebswirtschaftliche Kriterien, Aufwand und Nutzen von CMMI-Implementierungen Dr. Ernest Wallmüller, Wolfgang Daschner Qualität & Informatik www.itq.ch 1 Qualität & Informatik Kosten der CMMI-Nutzung

Mehr

Agilo [1] ist ein auf Trac [2] basierendes Scrum [3] Tool. Im Folgenden soll eine kurze Überischt gegeben werden, wie Agilo benutzt wird.

Agilo [1] ist ein auf Trac [2] basierendes Scrum [3] Tool. Im Folgenden soll eine kurze Überischt gegeben werden, wie Agilo benutzt wird. AGILO HOWTO Agilo [1] ist ein auf Trac [2] basierendes Scrum [3] Tool. Im Folgenden soll eine kurze Überischt gegeben werden, wie Agilo benutzt wird. ROLLEN IM TEAM In Scrum hat jedes Teammitglied eine

Mehr

Info IV IT Projekt Management

Info IV IT Projekt Management Info IV IT Projekt Management Prof. Dr. Peter Müller Software Component Technology Sommersemester 04 Einführung 2 Eine traurige Geschichte Standish Group Research Study CHAOS 1995 100% erfolgreich (rechtzeitig,

Mehr

Einführung in die Informatik

Einführung in die Informatik Einführung in die Informatik Softwareentwicklung Probleme bei großer Software Life-Cycle-Modelle Teilphasen eines Software-Projekts Methoden und Werkzeuge 01101101 01011001 11010011 10011000 00000011 00011100

Mehr

Werte und Prinzipien der agilen Softwareentwicklung

Werte und Prinzipien der agilen Softwareentwicklung 1 Was ist Scrum? Scrum ist ein einfaches Projektmanagement-Framework, in das Entwicklungsteams selbstbestimmt erprobte Praktiken einbetten. Der Rahmen sieht einen empirisch, iterativen Prozess vor, bei

Mehr

SmartOffer. Eine werkzeugbasierte Methode zur Vorbereitung von Software Projekten. Universität Trier. Axel Kalenborn & Sebastian Adam

SmartOffer. Eine werkzeugbasierte Methode zur Vorbereitung von Software Projekten. Universität Trier. Axel Kalenborn & Sebastian Adam SmartOffer Eine werkzeugbasierte Methode zur Vorbereitung von Software Projekten Axel Kalenborn & Sebastian Adam Universität Trier Motivation: Phasen der Software Entwicklung Analyse Entwurf Umsetzung

Mehr

Welche Unterschiede gibt es zwischen einem CAPAund einem Audiometrie- Test?

Welche Unterschiede gibt es zwischen einem CAPAund einem Audiometrie- Test? Welche Unterschiede gibt es zwischen einem CAPAund einem Audiometrie- Test? Auch wenn die Messungsmethoden ähnlich sind, ist das Ziel beider Systeme jedoch ein anderes. Gwenolé NEXER g.nexer@hearin gp

Mehr

Projektorganisation und Vorgehen in agilen Projekten. Noser Technologieimpulse München 2013 - Matthias Neubacher

Projektorganisation und Vorgehen in agilen Projekten. Noser Technologieimpulse München 2013 - Matthias Neubacher Projektorganisation und Vorgehen in agilen Projekten Noser Technologieimpulse München 2013 - Matthias Neubacher Ein wenig Theorie Agile Methoden Warum? hohe Anpassbarkeit schnellere Ergebnisse günstigere

Mehr

Messen von Usability. Wie kann man eine GUI unter dem Gesichtspunkt Usability bewerten?

Messen von Usability. Wie kann man eine GUI unter dem Gesichtspunkt Usability bewerten? Messen von Usability Wie kann man eine GUI unter dem Gesichtspunkt Usability bewerten? 1 Motivation Warum Usability messen? Usability Probleme frühzeitig erkennen Unterschiedliche Bedienelemente / Interaktionsmöglichkeiten

Mehr

Lohnt sich Requirements Engineering?

Lohnt sich Requirements Engineering? Lohnt sich Requirements Engineering? Seminar Messbarkeit von Anforderungen am Fachgebiet Software Engineering Wintersemester 2007/2008 Betreuer: Eric Knauss Oleksandr Kazandzhi Gliederung Einleitung Messen

Mehr

Dezentralisiertes Quality-of-Service Monitoring

Dezentralisiertes Quality-of-Service Monitoring Dezentralisiertes Quality-of-Service Monitoring Mai 2013 netidee Zwischenbericht Dieses Dokument informiert über den aktuellen Stand des Netidee 2012 Projektes Dezentralisiertes Quality-of-Service Monitoring.

Mehr

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Agile Methoden als Diagnose-Tool für den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Über mich Berufliche Erfahrung 3 Jahre Projektabwicklung 2 Jahre

Mehr

Agile Entwicklung nach Scrum

Agile Entwicklung nach Scrum comsolit AG Hauptstrasse 78 CH-8280 Kreuzlingen Tel. +41 71 222 17 06 Fax +41 71 222 17 80 info@comsolit.com www.comsolit.com Agile Entwicklung nach Scrum Seite 1 / 6 Scrum V 1.0 1. Wieso Scrum Die Entwicklung

Mehr

Diskussion eines hybriden Projektmanagements im Vergleich zu klassischem und agilem Projektmanagement. Bachelorarbeit

Diskussion eines hybriden Projektmanagements im Vergleich zu klassischem und agilem Projektmanagement. Bachelorarbeit Diskussion eines hybriden Projektmanagements im Vergleich zu klassischem und agilem Projektmanagement Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaft

Mehr

RPLAN Academy. RPLAN Training in kollaborativem Projektmanagement

RPLAN Academy. RPLAN Training in kollaborativem Projektmanagement RPLAN Academy RPLAN Training in kollaborativem Projektmanagement Unsere Trainings: Überblick Modul- und kundenspezifisches Training Die RPLAN Academy trainiert alle Module und Aspekte von RPLAN und kollaborativem

Mehr

Metriken - ein unverzichtbarer Begleiter für Software-Prozess-Verbesserungen

Metriken - ein unverzichtbarer Begleiter für Software-Prozess-Verbesserungen Metriken - ein unverzichtbarer Begleiter für Software-Prozess-Verbesserungen Dipl.-Math. Hermann Will QADVICE Software+System Qualität Jamnitzerstr. 2, 81543 München hermann.will@qadvice.de Zusammenfassung.

Mehr

5.3.2 Projektstrukturplan

5.3.2 Projektstrukturplan 5.3.2 Der ist eine der wichtigsten Planungs- und Controllingmethoden und das zentrale Kommunikationsinstrument im Projekt. Er bildet die Basis für sämtliche weitere Projektmanagement- Pläne sowie für die

Mehr

Software Engineering Übung 5 Verträge, Aufwand- und Risikoschätzung

Software Engineering Übung 5 Verträge, Aufwand- und Risikoschätzung software evolution & architecture lab Software Engineering Übung 5 Verträge, Aufwand- und Risikoschätzung 1 Informationen 1.1 Daten Ausgabe Di 10.11.2009 Abgabe So 22.11.2009 bis 23:59 Uhr Besprechung

Mehr

Simulation der SW-Systemzuverlässigkeit in Automatisierungssystemen auf Grundlage von SW-Komponenten

Simulation der SW-Systemzuverlässigkeit in Automatisierungssystemen auf Grundlage von SW-Komponenten Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner Simulation der SW-Systemzuverlässigkeit in Automatisierungssystemen auf Grundlage von SW-Komponenten

Mehr

Agile BI Kickstart. Beschreibung des Workshops. Workshopbeschreibung

Agile BI Kickstart. Beschreibung des Workshops. Workshopbeschreibung Bereich: Workshop: Dauer: In-House Workshop Agile BI Kickstart 2 Tage Beschreibung des Workshops Agile Vorgehensweisen werden bei der Entwicklung von BI- und Data Warehouse-Lösungen heutzutage mehr und

Mehr

Wasserfall, «Death March», Scrum und agile Methoden. 08. Dezember 2011 Embedded Software Engineering Kongress Urs Böhm

Wasserfall, «Death March», Scrum und agile Methoden. 08. Dezember 2011 Embedded Software Engineering Kongress Urs Böhm Wasserfall, «Death March», Scrum und agile Methoden 08. Dezember 2011 Embedded Software Engineering Kongress Urs Böhm Übersicht Warum Projektmanagement? Gängige SW Entwicklungsprozesse Wasserfall V-Modell

Mehr

Management großer Projekte Ein modellbasierter Ansatz

Management großer Projekte Ein modellbasierter Ansatz Management großer Projekte Ein modellbasierter Ansatz Dr. Dehla Sokenou Herausforderungen des Projektmanagements Projekt Initialisierung Aufgaben sinnvoll planen/partitionieren Projekt Monitoring Arbeitsergebnisse/Status

Mehr

Management von Softwaresystemen Systembewertung: Metriken und Prozess

Management von Softwaresystemen Systembewertung: Metriken und Prozess Management von Softwaresystemen Systembewertung: Metriken und Prozess Referent: Vadym Alyokhin Betreuer: Florian Deißenböck Übersicht Definition Einführung in die Messtheorie Meilensteine von Software-Metriken

Mehr

1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem

1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem 1 Welcher Service Operation Prozesse fehlen? Incident Management, Problem Management, Access Management a. Event Management b. Service Desk c. Facilities Management d. Change Management e. Request Fulfilment

Mehr

Experience. nr.52. ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen. märz 2012

Experience. nr.52. ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen. märz 2012 ERNI Erfahrungsberichte rund um Management-, Prozess- und Technologiethemen Experience nr.52 märz 2012 RequIREMENTs EngINEERINg Ins Schwarze treffen Ins SchwARze treffen Requirements Engineering: die Grundlagen

Mehr

Project Management Center

Project Management Center Project Management Center Überblick - 1 - OMNITRACKER Project Management Center Applikation zur Unterstützung der Projektabwicklung, Projektstrukturierung und zur Überwachung und Steuerung des Projektfortschritts

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Projektvorstellung Übung 1 Wiederholung zusammengefasst Planungsphase Lernziele Ziele und Inhalt der Planungsphase Anlass und Aufgabestellung(Was ist dabei erförderlich) Requirement Engineering

Mehr

1 Einleitung. 1.1 Unser Ziel

1 Einleitung. 1.1 Unser Ziel 1 Dieses Buch wendet sich an alle, die sich für agile Softwareentwicklung interessieren. Einleitend möchten wir unser mit diesem Buch verbundenes Ziel, unseren Erfahrungshintergrund, das dem Buch zugrunde

Mehr

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector 7.4 Analyse anhand der SQL-Trace 337 7.3.5 Vorabanalyse mit dem Code Inspector Der Code Inspector (SCI) wurde in den vorangegangenen Kapiteln immer wieder erwähnt. Er stellt ein paar nützliche Prüfungen

Mehr

Vector Software. Test Automation mit VectorCAST während der gesamten Softwareentwicklung W H I T E P A P E R

Vector Software. Test Automation mit VectorCAST während der gesamten Softwareentwicklung W H I T E P A P E R Vector Software W H I T E P A P E R Test Automation mit VectorCAST während der gesamten Softwareentwicklung VectorCAST Produktfamilie Die VectorCAST Produktfamilie automatisiert Testaktivitäten über den

Mehr

Anleitung zur Benutzung des online-service www.klausurgutachten.de

Anleitung zur Benutzung des online-service www.klausurgutachten.de Anleitung zur Benutzung des online-service www.klausurgutachten.de Inhalt 1. Das Arbeitsprinzip des Service www.klausurgutachten.de 2. Technische Voraussetzungen 2.1 online-arbeiten 2.2 Einstellungen des

Mehr

Test. Dipl. Wirtsch. Ing. Alexander Werth 9-1

Test. Dipl. Wirtsch. Ing. Alexander Werth 9-1 Test Dipl. Wirtsch. Ing. Alexander Werth 9-1 Phasen der Problemdefinition Anforderungsanalyse Spezifikation Entwurf Implementation Erprobung Wartung Methoden der 9-2 Software Test / Erprobung Messen der

Mehr

Agile Softwareentwicklung mit Scrum

Agile Softwareentwicklung mit Scrum Agile Softwareentwicklung mit Scrum Einführung und Überblick zum agilen Softwareentwicklungsprozess Scrum März 2006 Robert Schmelzer, DI(FH) E-Mail: robert@schmelzer.cc Web: http://www.schmelzer.cc Einführung

Mehr

Software-Lebenszyklus

Software-Lebenszyklus Software-Lebenszyklus Inhalt Vorgehensmodell/Phasenplan Wasserfallmodell WAS-Beschreibung WIE-Beschreibung Weitere Phasenmodelle: Spiral-Modell, V-Modell, RUP Extreme Programming SW-Qualitätssicherung

Mehr

Schätzen in der Business Analyse eine unterschätzte Technik der Elizitation?

Schätzen in der Business Analyse eine unterschätzte Technik der Elizitation? Schätzen in der Business Analyse eine Workshop zum Business Analyse Camp Wien, DI Mag Jörg Rainer, MBA, CBAP 1 Der traditionelle Weg Wissensgebiete Überblick über alle Wissensgebiete Sehr allgemein Für

Mehr

SOFTWARE ENGINEERING

SOFTWARE ENGINEERING 8. Planen und Schätzen Software Entwicklung ist komplex. Es gibt keine einfache Lösung für die Projektabwicklung! Der Grund liegt in den vielen möglichen Alternativen, die in einem Projekt möglich sind.

Mehr

IT-Projektmanagement Schätzung Kaiserslautern, WS 2008/2009 Dr. Gerhard Pews

IT-Projektmanagement Schätzung Kaiserslautern, WS 2008/2009 Dr. Gerhard Pews IT-Projektmanagement Schätzung Kaiserslautern, WS 2008/2009 Dr. Gerhard Pews AGENDA Allgemeine Grundlagen zur Schätzung Function Point Verfahren Expertenschätzung, Delphi-Verfahren CoCoMo Verfahren 2 Grundlagen

Mehr

Projektmanagement. Dokument V 1.2. Oliver Lietz - Projektmanagement. Probleme bei Projekten

Projektmanagement. Dokument V 1.2. Oliver Lietz - Projektmanagement. Probleme bei Projekten Projektmanagement Agile Methoden: Extreme Programming / Scrum Dokument V 1.2 Probleme bei Projekten Viel Arbeit, die an den Zielen vorbeigeht Viel Dokumentation für f r unbenutzte Bestandteile Fehlende

Mehr

Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle. Windhoff Software Services GmbH www.wind-soft.

Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle. Windhoff Software Services GmbH www.wind-soft. Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle Folie 2 Agenda Projektmanagement: Ziele und Methoden Agile Methoden: Scrum Agile Methoden im BI Umfeld PM

Mehr

Managed Workstation & Server. Die laufende IT-Wartung von PC-SPEZIALIST.

Managed Workstation & Server. Die laufende IT-Wartung von PC-SPEZIALIST. Managed Workstation & Server. Die laufende IT-Wartung von PC-SPEZIALIST. Die laufende IT-Wartung von PC-SPEZIALIST. Sicherheit, Stabilität und Schnelligkeit. Zum Festpreis. Ist Ihre I T ausreichend geschützt?

Mehr

Kapitel 2: Projektmanagement Umsetzung

Kapitel 2: Projektmanagement Umsetzung 1. Projektmanagement-System 2. Projektphasen 3. Aufbauorganisation 4. Menschen im Projekt und ihre Rollen 5. Excurs: Gruppendynamik 6. Methoden und Werkzeuge Dr. Ulrich Meyer 22 Kapitel 2: PM-Umsetzung

Mehr

Datenübernahme easyjob 3.0 zu easyjob 4.0

Datenübernahme easyjob 3.0 zu easyjob 4.0 Datenübernahme easyjob 3.0 zu easyjob 4.0 Einführung...3 Systemanforderung easyjob 4.0...3 Vorgehensweise zur Umstellung zu easyjob 4.0...4 Installation easyjob 4.0 auf dem Server und Arbeitsstationen...4

Mehr

Software Engineering. Prof. Dr. Stefan Enderle NTA Isny

Software Engineering. Prof. Dr. Stefan Enderle NTA Isny Software Engineering Prof. Dr. Stefan Enderle NTA Isny 3 Software Entwicklungsprozesse Softwareentwicklung Systematisches Vorgehen wichtig Zeitlicher Ablauf durch Vorgehensmodell Meist grundlegender Aufbau:

Mehr

ISIS. Das Navigationssystem für angemessene Qualität und hohe Effizienz

ISIS. Das Navigationssystem für angemessene Qualität und hohe Effizienz ISIS Das Navigationssystem für angemessene Qualität und hohe Effizienz Inhalt Softwarequalität und Prozessqualität ISIS: das Ziel Messen der Prozessqualität Der Werkzeugzoo Die Wirkung Maßnahmen zur Prozessoptimierung

Mehr

Prof. Dr.-Ing. Dagmar Meyer Projektmanagement PROJEKTPLANUNG

Prof. Dr.-Ing. Dagmar Meyer Projektmanagement PROJEKTPLANUNG Prof. Dr.-Ing. Dagmar Meyer Projektmanagement PROJEKTPLANUNG Übersicht Planungsschritte Projektmanagement Projektplanung Prof. Dr.-Ing. Dagmar Meyer 2 Projektumfang festlegen Festlegung des Projektumfangs

Mehr

Abb.: Darstellung der Problemfelder der Heine GmbH

Abb.: Darstellung der Problemfelder der Heine GmbH Entwicklung eines SOLL-Konzeptes Kehl Olga 16.05.10 Wie aus der Ist-Analyse ersichtlich wurde, bedarf die Vorgehensweise bei der Abwicklung von Projekten an Verbesserung. Nach der durchgeführten Analyse

Mehr

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Modellgetriebene Softwareentwicklung auf Basis von TOPCASED am Beispiel

Mehr

Use Cases REQEDIT CLIENT. Mai 2014. DER INNOVATIVE TOOLHERSTELLER www.reqteam.com

Use Cases REQEDIT CLIENT. Mai 2014. DER INNOVATIVE TOOLHERSTELLER www.reqteam.com Use Cases REQEDIT CLIENT Mai 2014 Übersicht 1. Einführung Anforderungsmanagement 2. Einführung Anforderungsmanagementtools und Austauschformate 3. Warum ReqEdit? 4. Use Cases - kleinere und mittlere Unternehmen

Mehr

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16 Probeklausur Lenz Belzner January 26, 2015 Lenz Belzner Probeklausur January 26, 2015 1 / 16 Definieren Sie Software Engineering in Abgrenzung zu Individual Programming. Ingenieursdisziplin professionelle

Mehr

Communication Metrics for Software Development

Communication Metrics for Software Development Herzlich Willkommen zur Präsentation Communication Metrics for Software Development Präsentation: Bernhard Gehberger Artikelautoren: Allen H. Dutoit Bernd Bruegge Inhaltsübersicht Motivation Testumgebung

Mehr

WIRIS quizzes Datenbank, Mathematik für Moodle Quiz

WIRIS quizzes Datenbank, Mathematik für Moodle Quiz WIRIS quizzes Datenbank, Mathematik für Moodle Quiz Carles Aguiló Maths for More WIRIS quizzes verbessert die Funktionalität von Moodle Quiz in der Mathematik und in anderen wissenschaftlichen Themengebieten.

Mehr

Einführung Erste Schritte mit Mamut Online Survey

Einführung Erste Schritte mit Mamut Online Survey [Type text] Mamut Active Services Einführung Erste Schritte mit Mamut Online Survey 1 Erste Schritte mit Mamut Online Survey Inhalt Über Mamut Online Survey... 2 Erste Schritte mit Mamut Online Survey...

Mehr

CMC-KOMPASS: CRM. Der Wegweiser für erfolgreiches Kundenbeziehungsmanagement

CMC-KOMPASS: CRM. Der Wegweiser für erfolgreiches Kundenbeziehungsmanagement CMC-KOMPASS: CRM Der Wegweiser für erfolgreiches Kundenbeziehungsmanagement 1 CROSSMEDIACONSULTING 18.05.2010 Unser Verständnis von CRM: Customer Relationship Management ist weit mehr als ein IT-Projekt

Mehr

A-Plan 12.0. Zeiterfassung 2.0. Ausgabe 1.1. Copyright. Warenzeichenhinweise

A-Plan 12.0. Zeiterfassung 2.0. Ausgabe 1.1. Copyright. Warenzeichenhinweise A-Plan 12.0 Zeiterfassung 2.0 Ausgabe 1.1 Copyright Copyright 1996-2014 braintool software gmbh Kein Teil dieses Handbuches darf ohne ausdrückliche Genehmigung von braintool software gmbh auf mechanischem

Mehr

Software Engineering Projekt (SEP) mit ROBOCODE

Software Engineering Projekt (SEP) mit ROBOCODE Software Engineering Projekt (SEP) mit ROBOCODE Klaus Knopper Stand: 2014 http://robocode.sourceforge.net/ Kurzbeschreibung Es wird mit den Methoden des Software Engineering in Teamarbeit

Mehr