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

PROJEKTMANAGEMENT LV Nr. 706.023 (1 Ue)

PROJEKTMANAGEMENT LV Nr. 706.023 (1 Ue) PROJEKTMANAGEMENT LV Nr. 706.023 (1 Ue) Aufgabe 3 AUFGABENSTELLUNG UND ÜBUNGSUNTERLAGEN Vom Projektstrukturplan zur Aufwandsabschätzung Autor: Johanna Pirker Andreas Schwarz Lehrveranstaltungsleiter: Dipl.-Ing.

Mehr

Projektmanagement - Block 6

Projektmanagement - Block 6 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

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

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

Kapitel 3: Einführung Projektmanagement

Kapitel 3: Einführung Projektmanagement : : : : : : : : : : : : : : : : : : : : : Kapitel 3: Einführung Projektmanagement Dr.-Ing. Bastian Koller, Axel Tenschert koller@hlrs.de, tenschert@hlrs.de : : : : : : : : : : : : : : : : : : : : : Kapitel

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

Lösungsvorschlag zur Klausur zu Projektorganisation und Management in der Software-Entwicklung

Lösungsvorschlag zur Klausur zu Projektorganisation und Management in der Software-Entwicklung Prof. Dr. Dr. h.c. M. Broy Klausurlösung Dr. H. Ehler, S. Wagner 2. Juli 2004 Lösungsvorschlag zur Klausur zu Projektorganisation und Management in der Software-Entwicklung Aufgabe 1 Prozessmodelle (4

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

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

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

Aufwandschätzung von IT-Projekten in der Praxis. Christian Zehe und Christian Hartmann

Aufwandschätzung von IT-Projekten in der Praxis. Christian Zehe und Christian Hartmann Aufwandschätzung von IT-Projekten in der Christian Zehe und Christian Hartmann Gliederung 1. Problematik der Aufwandschätzung 2. Grundlagen der Aufwandschätzung 3. Methoden der Aufwandschätzung Umfangbasierte

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

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

V. Aufwands- und Kostenschätzung (Teil 1)

V. Aufwands- und Kostenschätzung (Teil 1) V. Aufwands- und Kostenschätzung (Teil 1) Prof. Dr. Jens Grabowski Tel. 39 172022 Email grabowski@cs.uni-goettingen.de SoftwEng (SS09) V.1-1 Inhalt Einführung Intuitive Schätzung Analogieschätzung Expertenschätzungen

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

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

Project Management. Prof. Dr. Franz Wotawa Institute for Software Technology wotawa@ist.tugraz.at

Project Management. Prof. Dr. Franz Wotawa Institute for Software Technology wotawa@ist.tugraz.at Project Management Prof. Dr. Franz Wotawa Institute for Software Technology wotawa@ist.tugraz.at Fragestellungen Was ist ein Projekt? Was sind die handelnden Personen? Wie wird es durchgeführt? Siehe u.a.:

Mehr

PRÜFUNG FÜR ELEKTROINGENIEURE. Softwaretechnik I. Musterlösung SS 12. - Ohne Gewähr -

PRÜFUNG FÜR ELEKTROINGENIEURE. Softwaretechnik I. Musterlösung SS 12. - Ohne Gewähr - PRÜFUNG FÜR ELEKTROINGENIEURE Softwaretechnik I Musterlösung SS 12 - Ohne Gewähr - LfdNr. Thema Punkte Zeitbedarf in min 1 Analyse und Entwurf 15 30 2 Basistechniken und Test 15 30 3 Projektmanagement

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

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

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

6.2 Regressionsanalyse

6.2 Regressionsanalyse c-kennzahlensystem (ROCI) 6. Regressionsanalyse Die Regressionsanalyse zählt zu den wichtigsten Analysemethoden des Kommunikationscontrollings und hat ihre tiefen Wurzeln in der Statistik. Im Rahmen des

Mehr

Management von Softwaresystemen

Management von Softwaresystemen Management von Softwaresystemen Aufwands- und Kostenschätzung Betreuer: Bernhard Schätz Bearbeiterin: Meltem Akyazi Aufwands- und Kostenschätzung Bevor mit der eigentlichen Durchführung eines Projektes

Mehr

Vorlesung Software-Reengineering

Vorlesung Software-Reengineering Vorlesung Software-Reengineering Prof. Dr. Rainer Koschke Arbeitsgruppe Softwaretechnik Fachbereich Mathematik und Informatik Universität Bremen Wintersemester 2010/11 Überblick I Durchführung von Reengineering-Projekten

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

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

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

1. Grundbegriffe des Software-Engineering

1. Grundbegriffe des Software-Engineering 1. Grundbegriffe Software Engineering 1 1. Grundbegriffe des Software-Engineering Was ist Software-Engineering? (deutsch: Software-Technik) Teilgebiet der Informatik, das sich mit Methoden und Werkzeugen

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

Von Menschen mit Mäusen Wohin führt das Projektmanagement

Von Menschen mit Mäusen Wohin führt das Projektmanagement Von Menschen mit Mäusen Wohin führt das Projektmanagement H. Sandmayr 10. SW-Werkstatt Thun 28. Oktober 1999 28.10.1999/sa 10. SWWS Thun 1999 1 Zum Inhalt Versuch einer Standortbestimmung (als Basis für

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

ISO9001 2015 QM-Dienstleistungen Holger Grosser Simonstr. 14 90766 Fürth Tel: 0911/49522541 www.qm-guru.de

ISO9001 2015 QM-Dienstleistungen Holger Grosser Simonstr. 14 90766 Fürth Tel: 0911/49522541 www.qm-guru.de ISO9001 2015 Hinweise der ISO Organisation http://isotc.iso.org/livelink/livelink/open/tc176sc2pub lic Ausschlüsse im Vortrag Angaben, die vom Vortragenden gemacht werden, können persönliche Meinungen

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

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

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

Qualitätsmanagement im Projekt

Qualitätsmanagement im Projekt Software-Engineering Qualitätsmanagement im Projekt Vorlesung im Wintersemester 2008/2009 Fakultät Wirtschaftsinformatik Klaus Mairon, M.Sc. Inhalte Messen und Bewerten: Metriken in der Qualitätssicherung

Mehr

Inhalt Software-Metriken Software-Metriken mit Together FindBugs. Software-Metriken. Raimar Lill Matthias Meitner David Föhrweiser Marc Spisländer

Inhalt Software-Metriken Software-Metriken mit Together FindBugs. Software-Metriken. Raimar Lill Matthias Meitner David Föhrweiser Marc Spisländer Lill, Meitner, Föhrweiser, Spisländer FAU Erlangen-Nürnberg Software-Metriken 1 / 24 Software-Metriken Raimar Lill Matthias Meitner David Föhrweiser Marc Spisländer Lehrstuhl für Software Engineering Friedrich-Alexander-Universität

Mehr

Anleitung für das MS Project Professional 2003 (Deutsche Version)

Anleitung für das MS Project Professional 2003 (Deutsche Version) Anleitung für das MS Project Professional 2003 (Deutsche Version) Erstes Starten... 2 Tutorial... 3 Hilfe... 4 Critical Path / Kritischer Weg... 5 Der Critical Path / Kritischer Weg wird nicht korrekt

Mehr

Abonnements. Stand 02 / 2015

Abonnements. Stand 02 / 2015 Abonnements Stand 02 / 2015 EXACT ONLINE 2 Inhalt Vorbemerkung... 3 Allgemeine Einstellungen... 4 Einstellungen des Abonnements... 6 Einstellungen des Artikels... 10 Abonnement anlegen... 12 Rechnungen

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

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

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

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

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

Projektmanagement mit hyscore

Projektmanagement mit hyscore Projektmanagement mit hyscore Webbasiert Projekte und Massnahmen erfolgreich planen und durchführen Version 4.5 Ausgabe 1.3 März 2010 Seite 1 Inhalt Projektmanagement mit hyscore... 3 Direkter Zugriff

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

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

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

Software Engineering in der Praxis

Software Engineering in der Praxis Software Engineering in der Praxis Praktische Übungen Adersberger, Spisländer FAU Erlangen-Nürnberg Software-Metriken 1 / 26 Software-Metriken Josef Adersberger Marc Spisländer Lehrstuhl für Software Engineering

Mehr

Vorlesung Software-Reengineering

Vorlesung Software-Reengineering Vorlesung Software-Reengineering Prof. Dr. Rainer Koschke Arbeitsgruppe Softwaretechnik Fachbereich Mathematik und Informatik Universität Bremen Wintersemester 2009/10 Überblick I 1 I 1 Arten von Reengineering-Projekten

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

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

Entwicklungsmethoden

Entwicklungsmethoden Slide 5.1 Entwicklungsmethoden Prof. Dr. Josef M. Joller jjoller@hsr.ch Development Methodologies Prof. Dr. Josef M. Joller 1 Session 5 Slide 5.2 TOOLS Development Methodologies Prof. Dr. Josef M. Joller

Mehr

Software-Metriken. Dipl.-Ing.(BA) Henning Sievert Seminar Software-Entwurf WS 2004/05

Software-Metriken. Dipl.-Ing.(BA) Henning Sievert <email@henningsievert.de> Seminar Software-Entwurf WS 2004/05 Software-Metriken Dipl.-Ing.(BA) Henning Sievert Seminar Software-Entwurf WS 2004/05 Gliederung Einordnung in den Seminar-Kontext Grundlegende Definitionen Klassifikation von

Mehr

Project roles and responsibilities

Project roles and responsibilities Project roles and responsibilities Bernhard Guillon Alexander Zrinyi Institut für Computerwissenschaften Universität Salzburg Project Management B. Guillon, A. Zrinyi (Universität Salzburg) 1 / 22 Gliederung

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

Was muss ich noch für meine Zertifizierung tun, wenn meine Organisation. organisiert

Was muss ich noch für meine Zertifizierung tun, wenn meine Organisation. organisiert ? organisiert Was muss ich noch für meine Zertifizierung tun, wenn meine Organisation ist? Sie müssen ein QM-System: aufbauen, dokumentieren, verwirklichen, aufrechterhalten und dessen Wirksamkeit ständig

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

12.1 Einleitung... 2. 12.3 Die Vor- und Nachteile der Netzplantechnik... 8. 12.4 Selbstlernaufgaben... 8. 12.5 Zusammenfassung...

12.1 Einleitung... 2. 12.3 Die Vor- und Nachteile der Netzplantechnik... 8. 12.4 Selbstlernaufgaben... 8. 12.5 Zusammenfassung... Projektmanagement Lernheft 1. Phase: Projektplanung Projektablaufplanung Die Netzplantechnik Inhaltsverzeichnis 1.1 Einleitung... 1. Die einzelnen Schritte bei der Erstellung eines Netzplans... 3 1..1

Mehr

SWE9 Slide 1. Software-Engineering. Vorlesung 9 vom 13.12.2004 Sebastian Iwanowski FH Wedel

SWE9 Slide 1. Software-Engineering. Vorlesung 9 vom 13.12.2004 Sebastian Iwanowski FH Wedel SWE9 Slide 1 Software-Engineering Vorlesung 9 vom 13.12.2004 Sebastian Iwanowski FH Wedel SWE9 Slide 2 Software-Engineering Vorlesungsthemen: 1. Überblick über das Thema und die Vorlesung 2. Grundlegende

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

Vorlesung Betriebstechnik/Netzplantechnik Operations Research

Vorlesung Betriebstechnik/Netzplantechnik Operations Research Vorlesung Betriebstechnik/Netzplantechnik Operations Research Organisation Agenda Übungen Netzplantechnik GANTT-Diagramme Weitere Übungen 2 Übungen 3 weitere Übungen Nr. Vorgang Dauer AOB 1 Kickoff 2-2

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Wiederholung Weitere Begriffe Programmierung im Großem (Programmierung von Software als Ganzes) Prozess-Modelle 2 Wiederholung: Prozesse Prozesse sind hierarchische Gruppierungen von

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

Wo kommen Projekte her? PROJEKTAUSWAHL. 02.04.2014 Projektmanagement - Projektauswahl

Wo kommen Projekte her? PROJEKTAUSWAHL. 02.04.2014 Projektmanagement - Projektauswahl Wo kommen Projekte her? PROJEKTAUSWAHL 02.04.2014 Projektmanagement - Projektauswahl 1 Projektauswahl als Teil der strategischen Planung Projekte dienen dem Erreichen von Zielen der strategischen Unternehmensplanung

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

Analyse des Zeitverhaltens

Analyse des Zeitverhaltens Analyse des Zeitverhaltens Bei der Arbeit mit den Büchern ist es hilfreich, Ihren persönlichen Kalender und (soweit vorhanden) eine Stellen- bzw. Aufgabenbeschreibung Ihres Arbeitsplatzes griffbereit zu

Mehr

Was versteht man unter Softwarequalität?

Was versteht man unter Softwarequalität? Was versteht man unter? ist die Gesamtheit der Merkmale und Merkmalswerte eines Softwareproduktes, die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse zu erfüllen. Was ist

Mehr

Phase I: Angebotsvorbereitung

Phase I: Angebotsvorbereitung 1 Phase I: Angebotsvorbereitung Ziele der Phase I / Angebotsvorbereitung Kontakt herstellen erwartungen an das Angebot erteln Auftrag spezifizieren Rahmenbedingungen feststellen Beziehung aufbauen/vertrauensbasis

Mehr

Bewertung. Vorgespräch. Interne Vorbereitung. Zertifizierungsaudit. Wiederholungsaudit. Überwachungsaudit

Bewertung. Vorgespräch. Interne Vorbereitung. Zertifizierungsaudit. Wiederholungsaudit. Überwachungsaudit Bewertung,62=HUWLIL]LHUXQJ Vorgespräch Interne Vorbereitung 0RQDWH Zertifizierungsaudit Wiederholungsaudit DOOH-DKUH Überwachungsaudit MlKUOLFK Wenn eine Organisation ein,62ãã=huwlilndw anstrebt, so muss

Mehr

30 Multiple Choice-Fragen - pro Frage gibt es immer 1-4 richtige Antworten

30 Multiple Choice-Fragen - pro Frage gibt es immer 1-4 richtige Antworten SCRUM Foundation MUSTERPRÜFUNG Closed Book, d.h. keine Hilfsmittel zulässig Dauer: 60 Minuten 30 Multiple Choice-Fragen - pro Frage gibt es immer 1-4 richtige Antworten Beispiel für die Bewertung Annahme

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

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

MS Project. Crash Kurs Basis: MS Project 98. Dortmund, November 1998

MS Project. Crash Kurs Basis: MS Project 98. Dortmund, November 1998 MS Project Crash Kurs Basis: MS Project 98 Dortmund, November 1998 Prof. Dr. Heinz-Michael Winkels, Fachbereich Wirtschaft FH Dortmund Emil-Figge-Str. 44, D44227-Dortmund, TEL.: (0231)755-4966, FAX: (0231)755-4902

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

Umstellung auf die Version 10.2 mit neuem GUI - ein Erfahrungsbericht - Frankfurter Buchmesse Klopotek User Group

Umstellung auf die Version 10.2 mit neuem GUI - ein Erfahrungsbericht - Frankfurter Buchmesse Klopotek User Group Umstellung auf die Version 10.2 mit neuem GUI - ein Erfahrungsbericht - Frankfurter Buchmesse Klopotek User Group Frankfurt, 11. Oktober 2012, Torsten Schulz Warum eine neue PPM Version? Durch Umstieg

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

3.2,,Eichung von Function Points (Berichtigte Angabe)

3.2,,Eichung von Function Points (Berichtigte Angabe) I N S T I T U T E F O R R E A L - T I M E C O M P U T E R S Y S T E M S TECHNISCHE UNIVERSIT ÄT MÜNCHEN P R O F E S S O R G. F Ä R B E R Software Engineering 3. Übung 22.05.2003 3.2,,Eichung von Function

Mehr

Einführung in Generatives Programmieren. Bastian Molkenthin

Einführung in Generatives Programmieren. Bastian Molkenthin Einführung in Generatives Programmieren Bastian Molkenthin Motivation Industrielle Entwicklung *!!*,(% % - #$% #!" + '( & )!* Softwareentwicklung Rückblick auf Objektorientierung Objektorientierte Softwareentwicklung

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

JOB MANAGEMENT MIT DEM SAP SOLUTION MANAGER. Whitepaper

JOB MANAGEMENT MIT DEM SAP SOLUTION MANAGER. Whitepaper JOB MANAGEMENT MIT DEM SAP SOLUTION MANAGER. Whitepaper Wussten Sie, dass lediglich der kleinere Teil der Datenverarbeitung in Ihrem System von End-Anwendern generiert wird? Der größere Teil der Informationen

Mehr

Projekt: Requirements Engineering Sommersemester 2002. Anforderungsspezifikation im X-Treme Programming

Projekt: Requirements Engineering Sommersemester 2002. Anforderungsspezifikation im X-Treme Programming Projekt: Requirements Engineering Sommersemester 2002 Vortrag von Bernd Simmchen Anforderungsspezifikation im X-Treme Programming Gliederung 1 XP Eine kurze Einführung 2 Anforderungsspezifikation Klassisch

Mehr

Software Projekt 2 / Gruppe Knauth Lernziele:

Software Projekt 2 / Gruppe Knauth Lernziele: Lernziele: Realisierung eines komplexen Software-Projektes unter Industrie-ähnlichen Bedingungen Organisiertes Arbeiten im Team Team Organisation: Rollen und Aufgaben der Team-Mitglieder bestimmen Spezifikation

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

Requirements Analysis Document

Requirements Analysis Document Requirements Analysis Document 1. Einleitung Dieses Dokument beschreibt die Anforderungen an ein automatisches Korrektur- und Abgabesystem für Uebungen mit dem Ziel einer Arbeitserleichterung für Assistenten.

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

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

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

Leitprogramm Bubblesort

Leitprogramm Bubblesort Leitprogramm Bubblesort Dr. Rainer Hauser Inhalt 1 Übersicht...1 2 Input-Block I: Der Sortieralgorithmus Bubblesort...2 3 Input-Block II: Die Effizienz von Bubblesort...6 4 Zusammenfassung...8 5 Lernkontrolle...9

Mehr

Numerisches Programmieren

Numerisches Programmieren Technische Universität München WS /3 Institut für Informatik Prof Dr Hans-Joachim Bungartz Dipl-Inf Christoph Riesinger Dipl-Inf Dipl-Math Jürgen Bräckle Numerisches Programmieren Programmieraufgabe: Polnominterpolation,

Mehr

Qualitätssicherungskonzept

Qualitätssicherungskonzept Qualitätssicherungskonzept Web Annotation mit Fragment Ids Gruppe: swp12-9 Inhaltsverzeichnis 1. Dokumentationskonzept...2 1.1. Quelltexte...2 1.2. Änderungsdokumentation...4 1.3. Modellierungsdokumentation...4

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

Entwurf von Algorithmen - Kontrollstrukturen

Entwurf von Algorithmen - Kontrollstrukturen Entwurf von Algorithmen - Kontrollstrukturen Eine wichtige Phase in der Entwicklung von Computerprogrammen ist der Entwurf von Algorithmen. Dieser Arbeitsschritt vor dem Schreiben des Programmes in einer

Mehr

Alle Inhalte dieses ebooks sind urheberrechtlich geschützt. Die Herstellung und Verbreitung von Kopien ist nur mit ausdrücklicher Genehmigung des

Alle Inhalte dieses ebooks sind urheberrechtlich geschützt. Die Herstellung und Verbreitung von Kopien ist nur mit ausdrücklicher Genehmigung des Alle Inhalte dieses ebooks sind urheberrechtlich geschützt. Die Herstellung und Verbreitung von Kopien ist nur mit ausdrücklicher Genehmigung des Verlages gestattet. Agiles Projektmanagement Scrum, Use

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

SOA Governance Konzepte und Best Practices

SOA Governance Konzepte und Best Practices SOA Governance Konzepte und Best Practices Gerd Schneider Senior Director SOA Marketing Software AG 2/27/2007 Agenda Überblick SOA Governance Warum SOA Governance? Kundenbeispiel SAS Airlines Technische

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