Ausarbeitung für Projektmanagement. Projektplanung

Größe: px
Ab Seite anzeigen:

Download "Ausarbeitung für Projektmanagement. Projektplanung"

Transkript

1 Ausarbeitung für Projektmanagement Projektplanung Autoren: Annette Fink (AI 8) Daniel Schönle (CN 5) Christoph Wienands (AI 8)

2 Inhaltsverzeichnis EINLEITUNG...4 ALLGEMEIN...5 NOTWENDIGKEIT VON PROJEKTPLANUNG...6 SCHWIERIGKEITEN BEI DER PROJEKTPLANUNG...7 PLANUNGSVERLAUF IN DER PROJEKTPLANUNG Spezifikation Entwurfsdokumentation...7 STRUKTUR- UND ABLAUFPLAN...8 UNTERSCHEIDUNG STRUKTURPLAN UND OPERATIVE PLANUNG...8 Strukturplanung...8 Operative Planung...9 UNTERSCHIED PROJEKTSTRUKTUR OBJEKTSTRUKTUR...9 Projektstruktur...9 Objektstruktur...9 Anmerkung zur objektorientierten Projektstruktur...10 KOMPLEXE OBJEKTORIENTIERTE SYSTEME WERDEN ARCHITEKTURORIENTIERT ENTWICKELT...10 UML...11 NACHHALTIGKEIT...11 ZIELERREICHUNG...12 AUFWANDSCHÄTZUNG...13 ALLGEMEINES...13 EMPIRISCHE SCHÄTZVERFAHREN...13 Expertenbeurteilung/Analogieverfahren...13 Delphi-Methode...14 ALGORITHMISCHE SCHÄTZVERFAHREN...14 BEISPIELE ALGORITHMISCHER SCHÄTZVERFAHREN...15 COCOMO...15 Das Function Point-Verfahren...16 SONSTIGE METHODEN...20 PFLEGEKOSTEN...20 EINFLUSS DER SCHÄTZUNG AUF DEN AUFWAND...21 TERMINPLANUNG...21 TERMINLISTEN...22 BALKENDIAGRAMME...22 NETZPLANTECHNIK...22 PERSONALPLANUNG

3 RESSOURCENPLANUNG...24 KOSTENPLANUNG...26 DER PROJEKTPLAN...29 PROJEKTE PLANEN MIT EXTREME PROGRAMMING...30 PROBLEME TRADITIONELLER, SCHWERER SOFTWAREENTWICKLUNGSPROZESSE...30 XP ALS LEICHTGEWICHTIGER PROZESS...31 ABLAUF EINES PROJEKTES...32 PLANUNG DURCH GESCHICHTEN...32 VERSIONSPLANUNG...33 ITERATIONSPLANUNG...33 WEITERE BESONDERHEITEN VON XP...34 STOP, SO FUNKTIONIERT DAS ABER NICHT!...35 FAZIT...36 QUELLENANGABEN...37 GLOSSAR

4 Einleitung Um nicht im vollständigen Chaos zu versinken, geht es heutzutage nicht mehr ohne Projektplanung. Insbesondere, wenn mehrer Personen am Durchführen des Projektes, ja vielleicht sogar mehrere Projekt-Teams beteiligt sind. Termine, der Ablauf, die Kostenfrage, die Dauer, und noch weitere Faktoren müßen berücksichtigt, koordiniert und organisiert werden. Für diese Koordination gibt es verschieden Konzepte und Strukturen. Diese Ausarbeitung versucht dem Leser eine Übersicht über diese Konzepte und Strukturen zu vermitteln, und vergleicht zum Schuß die traditionelle Softwareplanung mit dem Konzept des Extreme Programming von Beck und Fowler¹. Diese vorliegende Ausarbeitung trägt den Titel Projektplanung und ist die logische Fortsetzung des Themas Projekt- und Phasenorganisation von Ebner, Geldhauser und Weber². 4

5 Allgemein Zu welchem Zeitpunkt benötige ich Projektplanung? Für eine Antwort ist es nötig, den Begriff der Projektplanung zu definieren: In der Umgangssprache fängt Projektplanung genau dann an, wenn ich die Idee zu einem Produkt habe. Ideenfindung, Mindmapping, Brainstorming werden bereits intiuitiv dazugezählt. Im wissenschaftlichen Kontext jedoch, fängt der Bereich Projektplanung erst dann an, wenn ich bereits einen Projektleiter benannt habe. Warum? Weil dieser Projektleiter für die Projektplanung verantwortlich ist. Er plant und leitet das Projekt. Das Projekt an sich hat nun einen formellen Status. In dieser Ausarbeitung verwenden wir Projektplanung im wissenschaftlichen Kontext, um den Bereich an sich klar abzugrenzen. Wir, die diese Ausarbeitung und die dazugehörige Präsentation anfertigen, hatten zu Beginn unserer Treffen große Probleme damit, den Bereich Projektplanung einzugrenzen und in verschieden Gebiete zu untergliedern. Ein Grund dafür war unter anderem, daß die Literatur und die zahlreich dazu existierende Dokumente die Grenzen zwischen Projektmanagement und Projektplanung verwischen. Genauso wird Projektorganisation und Projektplanung nicht klar getrennt. Bereiche der Projektorganisation befinden sich unter dem Stichpunkt Projektplanung und vice versa. Wir wissen, daß es schwer ist, ein Projekt und die dazughörige Planung abzugrenzen, und in ein Schema F einzugliedern. Dies hängt von verschiedenen Faktoren ab, wie zb. welches Produkt stelle ich im Endeffekt her. Dennoch könnte man erwarten, daß man irgendwo in der Literatur ein Schema F zur Projektplanung findet, welches als allgemeiner Standard gehandhabt wird, und von welchem je nach Einsatz in der Wirtschaft, also je nach Produkt, dementsprechend abgeleitet werden kann. So einen Standard scheint es bis jetzt nicht zu geben! Es sei an dieser Stelle erwähnt, daß Pläne immer auf Schätzungen beruhen. Es ist sehr unwahrscheinlich, einen Plan zu machen, der genau so eintritt. Dies sollte sich ein Projektleiter zu Herzen nehmen, vor allem wenn es darum geht, Kosten und Dauer abzuschätzen. Er sollte möglichst alle Faktoren in diese Schätzungen miteinbeziehen, um den Schaden so gering wie möglich zu halten, und einen möglichst genauen Projektplan zu erstellen. 5

6 Notwendigkeit von Projektplanung Warum benötige ich überhaupt Projektplanung? Ein altes Sprichwort unbekannter Herkunft sagt: Planung ersetzt den Zufall durch Irrtum. Was wenn ich es positiv ausdrücke soviel heißt wie: Planung ersetzt zufälliges Glück durch geplanten Erfolg! Allerdings könnte man jedoch entgegenstellen, daß die Planung sehr viel Zeit erfordert, und daß man diese Zeit besser in die Realisierung des Projektes stecken sollte. *** *** *** ********* ########## ********* ########## ********* ########## * = Zeit für Planung + = Zeit für die Durchführung # = Zeitgewinn (Grafikquelle³ ) Diese Grafik soll aber anschaulich verdeutlichen, daß was einem zuerst als Zeitverschwendung erscheint, am Ende sozusagen ein Zeitgewinn wird. Diesen Zeitgewinn könnte ich positiv in mein Projekt einbringen, in dem ich zb. Die Funktionalität meine Produktes erweitere. Der Kunde würde begeistert sein. Eine weitere Notwendigkeit von Projektplanung ist, daß die Koordination und der Projektablauf zwischen den einzelnen Teammitgliedern und den Teams organisiert und festgelegt werden. Jeder weiß, was seine Aufgabe ist, für welchen Teil des Projektes er verantwortlich ist, und bis wann er seinen Projektteil abzuliefern hat. Man möge sich dazu ein Projekt mit 15 Menschen vorstellen, die ein Software Program entwickeln möchten. Man stelle sich weiter vor, selbst ein Programmierer in diesem Team zu sein. Und nun stelle man sich vor, es existiere kein Projektplan... der psychische Stress und die Sorgen haben schon angefangen, obwohl das Projekt noch überhaupt nicht begonnen hat. Projektplanung brauche ich auch, um festzustellen, wo ich in meinem Projektablauf stehe. Habe ich schon die Hälfte meines des mir vom Projekt übertragenen Teiles geschafft, oder schon dreiviertel? Wahrscheinlich sind es erst einviertel! Zu wissen wo man in einem Projektablauf steht, wieviel Zeit einem noch bleibt, kann einen motivieren mehr zu arbeiten, oder sich ein bißschen mehr Zeit für einen Teil zu nehmen. 6

7 Schwierigkeiten bei der Projektplanung Die wohl größten Schwierigkeiten bei der Projektplanung liegen darin, einen möglichst genauen Schätzfaktor für die Kosten und die Dauer des Projektes im vorneherein festzulegen. Wie wir weiter vorne im Text bereits angemerkt haben, beruhen Pläne auf Schätzungen, und es es nicht so einfach diese beiden Faktoren genau zu bestimmen. Dafür gibt es die verschiedensten Schätzverfahren, die wir in der Mitte dieser Ausarbeitung näher betrachten werden. Was bei der Projektplanung insbesonders zu beachten ist, ist daß zuerst eine Grobplanung des Projektes aufgestellt wird. Von dieser Grobplanung ausgehend wird auf eine Feinplanung hingearbeitet. Wenn nun zu früh eine Feinplanung vorgenommen wird, wird riskiert sich im Detail zu verlaufen und den Überblick über das ganze Projekt zu verlieren. Auch ist es Gang und Gebe, daß ein Plan häufig revidiert werden muß. Eine Schwierigkeit, die das Projekt eher begleitet, aber auch schon zu Beginn der Projektplanung auftreten kann, ist die Dokumentationen auf dem Laufenden zu halten. Es werden im Laufe des Projektes sehr viele Dokumente und Dokumentation produziert, und alle Teammitglieder ständig auf dem Laufenden zu halten dürfte eine Herausforderung für sich sein. Planungsverlauf in der Projektplanung 1. Spezifikation Der erste Planungsschritt ist wohl der Entwurf des Konzepts, die Spezifikation. Das Konzept ist die schematische Darstellung des künftigen Projekts. Da das Konzept möglichst realistisch wirken sollte, muß genügend Zeit für die Erstellung eingeplant werden. In diesem Konzept werden die Anforderungen an das Projekt explizit dargestellt. Der Kern des Konzepts ist die Zielsetzung. Hier werden die Ziele benannt, und die Indikatoren die anzeigen, ob ein Ziel erreicht wurde, oder nicht. Außerdem enthält ein Konzept eine Beschreibung der vorgesehenen Funktionalität der Software. Die Qualität des Projektes wird an der Erreichung der definierten Ziele, und an der realisierten Funktionalität gemessen. 2. Entwurfsdokumentation Der nächste Planungsschritt beschreibt die Produktstruktur. Die Produktstruktur ist die Antwort auf folgende Frage: Was wird geliefert? Daraufhin wird die Objektstruktur beschrieben, anschließend die Projektstruktur. Die dazugehörigen Fragen lauten: Welche zusätzlichen Anforderungen sind notwendig 7

8 und wie werden die noch anstehenden Aufgaben am besten strukturiert? (Objektstruktur) Und: Welche Tätigkeiten sind dazu erforderlich? (Projektstruktur) Auf die Projektstruktur setzt der Ablaufplan auf, welcher sich durch die Antwort auf folgende Frage am besten beschreiben läßt: In welcher Reihenfolge werden die Tätigkeiten erforderlich? Der Aufwandsplan beschreibt mit welchem Aufwand gearbeitet wird. Womit gearbeitet wird beschreibt der Ressourcenplan, und der Netzplan frägt : wann wird gearbeitet? Mit diesen Schritten sollte die Projektplanung erfolgt sein. Im Projektverlauf sind die nächsten Schritte nun die Kodierung und anschließend die Testdokumentation. Struktur- und Ablaufplan Strukturplan Der Strukturplan gliedert das Projekt graphisch oder tabellarisch in Teilprojekte. Diese Teilprojekte werden je wieder in Teilprojekte gegliedert. Dieser Teilungsprozess geschieht so oft, bis ein Teilprojekt nicht mehr aufgegliedert werden kann. Dieses Element auf der untersten Ebende heißt dann Arbeitspacket. Diese einzelnen Arbeitspackete sind für Zwischenergebnisse und (Objekt-) Dokumentationen erforderlich. Ablaufplanung Ablaufplanung ist nichts anderes, wie die Vorgänge im Projektplan in eine logische Reihenfolge anzuordnen. Unterscheidung Strukturplan und Operative Planung Am Anfang steht die Projektplanung. Die Projektplanung läßt sich unterscheiden zwischen den beiden Bereichen Strukturplanung und Operative Planung. Beide Oberpunkte lassen sich wieder in die folgenden Bereiche unterteilen: Strukturplanung Produktstruktur Projektstruktur Objektstruktur 8

9 Operative Planung Aufwand Dauer Termine Kapazitäten Kosten In dieser Ausarbeitung sehen wir uns die Objektstruktur genauer an, auf die Projektstruktur wurde in ¹ im näheren eingegangen. Die Produktstruktur wird nicht weiter erwähnt, wie im folgende Satz, da die Produktstruktur sich mit der Entwicklung von herkömmlichen Produkten beschäftigt, und nicht mit Software Produkten : Die Produktstruktur beschreibt die technische Struktur des zu entwickelnden Produktes. Der Produktstrukturplan enthält die Teile eines Produktes in hierarchischer Ordnung. Auf die operative Planung wird dann im Mittelteil genauer eingegangen. Doch zunächst die Differenzierung zwischen Projekt- und Objektstruktur, mit dem Übergang zur Beschreibung der Objektstruktur: Unterschied Projektstruktur Objektstruktur Projektstruktur Die Projektstruktur beschreibt die aufgabenbezogene Gliederung des Projektes. Der Projektstrukturplan enthält alle Aktivitäten, die in den einzelnen Projektphasen durchzuführen sind. Im folgenden die einzelnen Projektphasen als abstrakte Darstellung: Projektinitiierung Analyse Design Implementierung Test Abschluß Weiter wie diesen Abschnitt wird nicht auf die Projektstruktur eingegangen, da wie bereits erwähnt, in der Ausarbeitung ¹ darauf eingegangen wird. Objektstruktur Die Objektstruktur in einer Projektplanung beschreibt die Projektarchitektur oder die Programmarchitektur einer zu entwickelnden Software. Hierzu wird die innere Struktur und Wirkungsweise des Softwarprodukts beschrieben. 9

10 Innere Struktur des Softwareprodukts: Welches Objekt beinhaltet welchen (ggf. komplexen) Datentyp? Aufrufstruktur der Objekte. Welche Objekte verstehen welche Nachrichten? Funktionsgliederung und Algorithmen der Methoden. Schnittstellenbeschreibungen der Objekte. Datenorganisation. Gliederung der Daten in den Objekten. Beschreibung der Objektzustände. Nachrichten-Formatbeschreibungen. Externe Datensysteme. Wirkungsweise des Softwareprodukts: Dokumentation fachspezifischer Grundlagen (Wirkprinzipien, Vorschriften, Einschränkungen, Annahmen) Fehlerbehandlungskonzept (Maßnahmen zur Stabilität gegen Bedienungs-, Daten und Gerätefehler) Das Systemdenken und das Vorgehen vom Groben zum Detail" dienen in erster Linie der Strukturierung des zu gestaltenden Objekts. Diese Objektstruktur ist aber auch Ausgangspunkt für die Planung der Projektaktivitäten. Anmerkung zur objektorientierten Projektstruktur In der objektorientierten Gemeinde herrscht Einigkeit darüber, daß es keinen für alle objektorientierten Projekte einsetzbaren Prozeßleitfaden gibt. Es gibt aber sehr wohl generische Prozeßmodelle, die durch mehr oder minder aufwendige Modifikationen auf die Charakteristiken der verschiedenen Projekte bzw. Projekttypen zugeschnitten werden können. aus (4), Seite 22 Kapitel 3.6 Tailoring D.h. es gibt kein Schema F, nach dem ich einen Objektstrukturplan machen kann. Dies behaupten auch Goldberg und Rubin in Succeding with Objects. Hier beschreiben die Autoren, wie sie sich bei der Durchführung objektorientierter Projekte mit dem Gedanken beschäftigt haben, ein brauchbare, kochbuchartige Anleitung zu schreiben, und wie sie nach langjähriger Erfarhung mit objektorientierter Projektarbeit zur Überzeugung gekommen sind, daß dies nicht möglich ist. Komplexe objektorientierte Systeme werden architekturorientiert entwickelt Eine Softwarearchitektur ist ein Bauplan für die strukturelle Softwareorganisation des Gesamtsystems. Der Entwurf einer Softwarearchitektur kann im Projekt normalerweise nur schrittweise erfolgen. D.h. zu Beginn des Projektes wird nur eine erste grobe 10

11 Softwarearchitektur vorliegen, die im Projektablauf schrittweise zu verfeinern ist. Sie muß aber bereits in der Spezifikation die angestrebte Gesamtfunktionalität des Systems berücksichtigen. Eine solide Softwarearchitektur ist eine unverzichtbare voraussetzung dafür, daß alle Teilprodukte im Laufe der Entwicklugn zu einem einheitlichen System integriert werden können. Die Softwarearchitektur ist im Projektablauf so auszuarbeiten, daß die Anforderungen der Fachebene auf überschaubaren modulen soiwe deren Schnittstellen abgebildet werden können. Wie sieht eine Softwarearchitektur aus? Hierzu schreibt Booch: Eine gut strukturierte objektorientierte Architektur besteht aus: Einer in Hierarchien geordneten Menge von Klassen Einer Anzahl von Interaktionen wzischen diesen Klassen bzw. Objekten mit dem Ziel, ein bestimmtes Systemverhalten zu realisieren. UML Eine Objektorientierte Analyse- und Design- Notation ist UML (Unified Modelling Language), mit dazugehöriger Semantik. UML wurde von den drei Methodenspezialisten Grady Booch, Ivar Jacobson und Jim Rumbaugh formuliert. UML hat sich inzwischen zu einem Industriestandard entwickelt. UML ist eine Elementarmethode (siehe (4)), die die Frage nach dem Wie bei der Durchführung von Tätigkeiten im Prozeßmodell beantwortet. Achtung, nicht das Prozeßmodell nicht mit dem Projektmodell verwechseln! Als Prozeß stelle ich meine Software dar, also kann ich den Begriff Tätigkeiten gleich dem Begriff der Funktionalität meines Produktes setzen. UML wird u.a. in der Spezifikation der Projektplanung verwendet, da es die Beziehungen zwischen den Objekten visualisiert. Nachhaltigkeit Die Nachhaltigkeit einer Software sollte unbedingt schon bei der Projektplanung berücksichtigt werden. Der Grund der Nachhaltigkeit eine große Bedeutung zuzuordnen liegt darin, daß Projekte in der IT Branche zeitlich begrenzt sind. Deswegen sollte bei jeder Projektplanung über das Projektende hinaus gedacht und überlegt werden, wie Nachhaltigkeit erzeugt werden kann. Durch folgende Punkte kann Nachhaltigkeit erzeugt werden: Durch ständige Wartung der Software Durch das Entfernen von Bugs Durch Weiterentwicklung Durch das Hinzufügen von Funktionalitäten... 11

12 Zielerreichung Projektziele sagen etwas über die Funktionen aus, welche erreicht werden sollen. Sie sagen nichts darüber aus, mit welchen Massnahmen dieser Zustand erreicht werden soll. Sie beinhalten keine Vorschläge, wie das Vorhaben geplant und durchgeführt wird. Sie sagen nichts aus über die Machbarkeit! Ziele sollten smart sein, dh. : 1. spezifisch (konkret) 2. messbar (quantifizierbar oder mit Indikatoren versehen) 3. anspruchsvoll (mit Leistungen verbunden) 4. realistisch (mit den vorhandenen Ressourcen erreichbar) 5. terminorientiert (etappiert und terminiert) Indikatoren der Zielerreichung sollten im Projektplan genau dann angegeben werden, wenn die Zielformulierung selbst noch keine Beurteilung der Zielerreichung zuläßt. D.h. Wenn die Zielformulierung ungenau ist, und man am Ende eines Projektes nicht feststellen kann, ob das Projekt erfolgreich abgeschlossen wurde, oder nicht, genau dann braucht man Indikatoren für ein erfolgreiches Gelingen des Projektes. Und diese Indikatoren müssen im Projektplan schon definiert sein. Weitere Gründe von Indikatoren sind unter anderem: Indikatoren für die Projektzielerreichung machen den Projekterfolg greifbar Förderung der Motivation für die Projektarbeit Man hat den Erfolg, den man erreichen, möchte vor Augen. Allerdings wird oft schon das Zustandekommen eines Projektes, oder das Durchführen des Projektes alleine schon als Erfolg gewertet. Dies ist zb. der Fall, wenn die Finanzierung des Projektes nicht gesichert war, und nun plötzlich doch gesichert ist. Oder ein anderes Beispiel: es werden am Projekt massive finanzielle Kürzungen vorgenommen, und das Projekt hat nicht die Qualität, welche im Konzept beschrieben wurde. Ein Grund warum die Indikatoren zur Erfolgsfeststellung nicht aufgestellt werden, ist u.a. daß Zielvorstellungen nicht überprüfbar gemacht werden wollen. Somit kann vermieden werden, Rechenschaft über ein Scheitern des Projekts abzulegen. wenn der Erfolg benannt werden kann, kann er auch gebührend gefeiert werden! 12

13 Aufwandschätzung Allgemeines Wie man es nicht machen sollte: Eine erste Aufwandschätzung wird zunächst nach unten korrigiert, um den Auftrag zu bekommen. Anschließend wird die Schätzung jedes Mal dann nach oben angepasst, wenn sie von den tatsächlichen Kosten eingeholt worden ist. Die Schätzung nach sieben Monaten ist offenbar die erste, die wirklich seriös durchgeführt wurde. Sie zeigt, dass schon die erste Schätzung viel zu optimistisch war, ganz zu schweigen von der politischen Schätzung nach drei Monaten. Es gibt viele Gründe für die zum Teil krassen Fehleinschätzungen von Software- Kosten bzw. -Terminen, u.a. o Software-Erstellung ist weitgehend Kopfarbeit und daher stark von der Leistungsfähigkeit dieser Köpfe abhängig. Diese Leistungsfähigkeit kann um mehr als eine Größenordnung schwanken. o Nur ein kleiner Teil einer Software trägt die eigentliche Funktionalität. Ein großer Teil des Aufwands (und das wird oft übersehen) geht in Verwaltung, Fehlerbehandlung, Benutzerschnittstelle, etc. o Erfahrungen aus kleinen Projekten werden linear extrapoliert. o Programmierer programmieren nicht 100% ihrer Zeit. Empirische Schätzverfahren Expertenbeurteilung/Analogieverfahren Expertenbeurteilung ist eine vornehme Bezeichnung für Schätzungen über den Daumen. Die Güte der Schätzung steht und fällt mit der Erfahrung der Schätzenden. In der Regel wird aufgrund von Analogien zu bisher abgewickelten Projekten geschätzt. Dies geht bei erfahrenen Leuten in der Regel gut, wenn Erfahrungen mit analogen Projekten vorliegen. Krasse Fehler ergeben sich oft dann, wenn 13

14 Erfahrungen fehlen oder Erfahrungen mit kleinen Projekten auf große Projekte extrapoliert werden (Bild 1.7). FESTSTELLUNG: Expertenbeurteilung ist ein einfaches und billiges Schätzverfahren, das dann recht gut funktioniert, wenn die Schätzenden Erfahrungen mit gleichartigen Projekten haben. Andernfalls können die Prognosen sehr ungenau sein. Delphi-Methode Die Delphi-Methode versucht, Expertenschätzungen zu objektivieren. Mehrere Personen geben unabhängig voneinander eine begründete Schätzung ab. In einer nächsten Runde erhält jede(r) Beteiligte eine Zusammenfassung der ersten Schätzungen. Alle erstellen daraufhin eine neue Schätzung, wobei Abweichungen vom Mittelwert der vorhergehenden Runde zu begründen sind. Dies geht über mehrere Runden, bis alle Schätzungen einigermaßen beieinander liegen. FESTSTELLUNG: Die Delphi-Methode liefert zuverlässigere Schätzungen als die Expertenbeurteilung, weil sie Ausreißer eliminiert. Als Nachteil muss ein erheblich höherer Schätzaufwand in Kauf genommen werden. Algorithmische Schätzverfahren Algorithmische Methoden bestehen aus einem oder mehreren Algorithmen zur Berechnung einer Kosten- bzw. Durchlaufzeit-Funktion aus einer Reihe von Variablen. Bei hinreichend genauen Eingaben ergeben sich erstaunlich präzise Prognosen. Genauigkeit von COCOMO-Schätzungen Die Genauigkeit aller algorithmischen Methoden hängt jedoch entscheidend von zwei Dingen ab: 14

15 die Eingangsgrößen der Kostenfunktion (z.b. Anzahl Instruktionen) müssen einigermaßen zutreffend geschätzt werden das Modell muss kalibriert werden, d.h. der Wert der einzelnen Kostenattribute muss an die jeweilige Entwicklungsumgebung angepasst werden. Eine solche Kalibrierung ist nur möglich, wenn genügend Messwerte von durchgeführten Projekten vorliegen. FESTSTELLUNG: Algorithmische Methoden liefern die besten Schätzungen. Sie können aber nur nach entsprechenden Vorarbeiten (Kalibrierung) überhaupt eingesetzt werden. Außerdem sind sie stark abhängig von der Genauigkeit, mit der die Eingangsgrößen bestimmt werden können (garbage-in-garbage-out-problem). Beispiele algorithmischer Schätzverfahren Die zwei wichtigsten algorithmischen Schätzverfahren, COCOMO und Function Point, werden in den folgenden beiden Unterkapiteln vorgestellt. COCOMO COCOMO (Constructive Cost Model) ist das Kostenschätzverfahren von Boehm (1981). Es geht aus von einer Schätzung der Produktgröße in KDSI (Kilo lines of delivered source instructions). Aus diesem Grundwert und einer Reihe von Kosten- Multiplikatoren werden Kosten und Durchlaufzeit berechnet. Die Grundgleichungen lauten: (A) MM = 2.4 KDSI 1.05 (MM = man month) (B) TDEV = 2.5 MM 0.38 (TDEV = time to develop) Aufwandsschätzung nach COCOMO Diese Gleichungen gelten für einfache Anwendungsprogramme (organic mode). Für Programmsysteme (semidetached mode), bei denen ein erheblicher Anteil an 15

16 Interaktion mit Betriebssystem, Gerätetreibern, etc. hinzukommt und für eingebettete Systeme (embedded mode), deren Erstellung nochmals erheblich schwieriger ist, gelten andere Faktoren. COCOMO-Grundgleichungen für Programmsysteme (C) MM = 3.0 KDSI 1.12 (D) TDEV = 2.5 MM 0.35 COCOMO-Grundgleichungen für eingebettete Systeme (E) MM = 3.6 KDSI 1.2 (F) TDEV = 2.5 MM 0.32 Im Bild Aufwandsschätzung nach COCOMO wird eine graphische Veranschaulichung der Kosten über der Produktgröße gezeigt. Die mit den Grundgleichungen ermittelten Nominalwerte können nun noch erheblich genauer gemacht werden, indem man sie mit einer Reihe von Kostenfaktoren multipliziert. Die aktuellen Werte aller Kostenfaktoren für ein Projekt werden unabhängig voneinander geschätzt und anschließend alle miteinander multipliziert. Der Nominalwert für den Projektaufwand in Personenmonaten wird dann mit diesem Produktfaktor multipliziert. (G) MM Korr = Produkt der Kostenfaktoren x MM nominal Eine ausführliche Beschreibung von COCOMO, inklusive der Definition, was bei ihm ein Personenmonat und eine Zeile gelieferter Code ist, findet sich in Boehm (1981). Das Function Point-Verfahren Function Points sind ein relatives Maß zur Bewertung der Funktionalität, d.h. des Leistungsumfangs eines Systems. Verfügt ein Unternehmen über Erfahrungszahlen, wieviel Aufwand pro Function Point im Mittel benötigt wird, um Software zu entwickeln bzw. zu pflegen, so können Function Points zur Aufwandschätzung herangezogen werden. Wird in laufenden oder abgeschlossenen Projekten der mittlere Zeitbedarf pro Function Point bestimmt, so bekommt man ein Produktivitätsmaß. Das Function Point-Verfahren wurde von Albrecht (1979) bei IBM entwickelt und seither von verschiedenen Autoren bzw. Gremien ergänzt und weiterentwickelt (Seibt 1987, Symons 1988, IFPUG 1994). Das Verfahren basiert auf der Idee, die folgenden Größen eines Software-Systems in geeigneter Weise zu zählen und zu bewerten (in Klammern die Terminologie von Albrecht): o Dateneingaben (External input) o Datenausgaben (External output) o Anfragen (External inquiry) o Schnittstellen zu externen Datenbeständen (External interface file) o Interne Datenbestände (Logical internal file) Dateneingaben, Datenausgaben und Anfragen werden an Hand der logischen Transaktionen, die das untersuchte System ausführen soll, gezählt. Tauchen die gleichen Eingabe- bzw. Ausgabedaten in verschiedenen Transaktionen mit unterschiedlicher Verarbeitungslogik auf, werden sie mehrmals gezählt. Bei den 16

17 Datenbeständen werden logische Dateien bzw. logische Datengruppen (Entitätstypen, Relationen) in Datenbanken gezählt. Die Werte können alle bereits in der Anforderungsspezifikation gezählt werden, sofern diese hinreichend vollständig und detailliert ist. Jede Dateneingabe, Datenausgabe, Anfrage, etc. wird als einfach, mittel oder komplex bewertet und mit einem entsprechenden Gewicht versehen. Die Tabelle Gewichtungskriterien für Dateneingaben zeigt als Beispiel die Gewichtungskriterien für Dateneingaben; Schema zur Berechnung des Function Point Rohwerts zeigt ein Schema für die Berechnung des Function Point-Rohwerts (unadjusted Function Points, UFP). Hat also beispielsweise ein System 37 logische Transaktionen mit Dateneingaben, von denen 12 als einfach, 16 als mittel und 9 als komplex bewertet werden, so ergibt sich ein Wert von 12x3+16x4+9x6 = 154 als Wert für die Dateneingaben. Anzahl bearbeiteter Datenbestände Anzahl unterscheidbarer Datenelemente in der Eingabe >15 einfach einfach mittel mittel mittel komplex >2 mittel komplex komplex Gewichtungskriterien für Dateneingaben (IFPUG 1994) Schema zur Berechnung des Function Point Rohwerts UFP (IFPUG 1994) Der Rohwert wird mit Gewichtungsfaktoren multipliziert, welche die technische Komplexität des Systems reflektieren. Der sogenannte Wertkorrekturfaktor (VAF, value adjustment factor (auch TCF (Technical Complexity Factor)) berechnet sich nach der Formel (H) VAF = 0,65 + 0,01 x TDI TDI ist der total degree of influence, der gemäß dem Schema zur Bestimmung der Einflussfaktoren (IFPUG 1994) berechnet wird. Die Formel ist so konstruiert, dass VAF in einem Bereich zwischen 0,65 und 1,35 liegt. Die Function Points FP eines Systems berechnen sich dann zu (I) FP = UFP x VAF Sollen Function Points zur Aufwandschätzung verwendet werden, so muss der zu erwartende Aufwand pro Function Point bekannt sein. Entsprechende Kurven oder Tabellen sind im Umlauf, sind aber mit Vorsicht zu genießen. Der Aufwand pro Function Point ist stark von projektspezifischen und unternehmensspezifischen Faktoren abhängig, beispielsweise vom Können der Leute im betreffenden Unternehmen, der verwendeten Entwicklungsumgebung und dem Stellenwert von 17

18 Qualität (z.b. Umfang der verlangten Dokumente, mittlerer Testaufwand). Ferner muss geklärt werden, welche Aufgaben in der Aufwandschätzung enthalten sind (beispielsweise, ob der Aufwand für die Anforderungsspezifikation eingeschlossen ist oder nicht). Jones (1996) gibt Faustregeln zur Berechnung des Aufwands aus Function Points an. Faustregeln von Jones zur Aufwandberechnung. A. Durchlaufzeit [in Monaten] = FP 0.4 B. Anzahl Mitarbeiter = FP / 150 C. Aufwand = Durchlaufzeit x Anzahl Mitarbeiter = FP 0.4 x FP / 150 Sollen projektspezifische Faktoren (zum Beispiel die Fähigkeit der beteiligten Personen, ihre Vertrautheit mit Problemstellung und die Vertrautheit mit der Lösungsplattform) berücksichtigt werden, so müssen bei der Umrechnung von Function Points in Personenmonate zusätzliche Korrekturfaktoren zur Anwendung kommen. Das Function Point-Verfahren muss folglich wie jedes andere algorithmische Verfahren kalibriert werden, wenn damit brauchbare Prognosen erzielt werden sollen. Das bedeutet, dass abgeschlossene Projekte nachkalkuliert werden müssen. Aus diesen Daten müssen unternehmens- und eventuell auch projektartspezifisch die Zusammenhänge zwischen Function Points und Aufwendungen hergeleitet werden. Es gibt unterschiedliche Zählregeln für Function Points. In diesem Text werden die Regeln der International Function Point Users Group (IFPUG 1994) verwendet. In IBM (1983) und Seibt (1987) werden andere Gewichtungskriterien und nur sieben Einflussfaktoren zur Berechnung des Wertkorrekturfaktors herangezogen. Noth und Kretzschmar (1984) verwenden wie IFPUG vierzehn Einflussfaktoren, gewichten aber den Faktor 9 (technische 18

19 Komplexität) mit 0-50 statt nur mit 0-5. Symons (1988) kritisiert das Albrechtsche Zählverfahren und schlägt ein Zählverfahren vor, das statt kompletter Ein- und Ausgaben die einzelnen Datenfelder zählt (Mark II Function Points). Bestimmung des Aufwand aus den Function Points Hier ist auch zu sehen, wie schon innerhalb desselben Unternehmens signifikant unterschiedliche Umrechnungskurven resultieren können. Jones (1995) gibt Erfahrungswerte für die Umrechnung von Function Points in Codezeilen an. Die Codezeilen verstehen sich ohne Leerzeilen und ohne Kommentar. Das Function Point-Verfahren hat den großen Vorteil, dass die benötigten Eingangsgrößen sich in den frühen Phasen eines Projekts leichter bestimmen lassen als beispielsweise die Größe des erwarteten Resultats bei COCOMO. Zudem sind mit Function Points Produktivitätsmessungen möglich, die weniger leicht verfälschbar sind als Messungen auf der Grundlage der erzeugten Programmzeilen. Allerdings ist das Verfahren auf Informationssysteme zugeschnitten und daher auf andere Arten von Software (zum Beispiel Prozessautomatisierung) nur beschränkt anwendbar. Ein weiterer Nachteil ist, dass das Function Point-Maß nicht additiv ist: Die Summe der Function Points von n logisch zusammenhängenden Teilsystemen ist größer als die Anzahl der Function Points des Gesamtsystems. Dies liegt daran, dass die Schnittstellen zwischen je zwei Teilsystemen auf beiden Seiten als 19

20 Schnittstellen zu externen Datenbeständen gezählt werden, während diese Daten bei Betrachtung des Gesamtsystems als ein interner Datenbestand gezählt werden. Es ist daher nicht möglich, bei einem großen System die Function Points pro Teilsystem zu bestimmen und diese zu addieren. Sonstige Methoden Es gibt eine Reihe weiterer gängiger Methoden zur Kostenschätzung, z.b. so schätzen, dass man auf jeden Fall den Auftrag bekommt, so viel schätzen, wie der Auftraggeber zu zahlen bereit ist, Schätzung nach dem Parkinson schen Gesetz: Das Projekt kostet soviel Arbeitskapazität wie vorhanden ist, usw. Pflegekosten Aus Messungen über Entwicklungs- und Pflegekosten von Software ergeben sich die folgenden beiden Faustregeln für Pflegekosten. Faustregel 1 Das Kostenverhältnis zwischen Entwicklung und Pflege eines Software-Produkts liegt im Bereich von 30:70 bis 50:50. Je länger ein Produkt lebt und je schlechter seine Qualität ist, desto höher ist der Kostenanteil für die Pflege. Faustregel 2 Die Kosten für die Pflege eines Software-Produkts verteilen sich etwa wie folgt: 60% Verbesserungen, 20% Anpassungen und 20% Fehlerbehebung. Das untere Bild zeigt verschiedene Schätzwerte für die Anzahl Codezeilen, die ein Vollzeit-Pflege-Programmierer betreuen kann. Die Aussage 20 KDSI/FSPM (KDSI/FSP M steht für kilo delivered source instructions per full-time software person (for maintenance).) bedeutet beispielsweise, dass zur Pflege eines Programms mit Codezeilen die volle Arbeitskraft einer Person (über das ganze Jahr hinweg) erforderlich ist. 20

5. Software-Aufwandschätzung

5. Software-Aufwandschätzung 5. Software-Aufwandschätzung 51 5. Software-Aufwandschätzung 5.1 Allgemeines Bild 5.1 zeigt, wie man es nicht machen sollte: Eine erste Aufwandschätzung wird zunächst nach unten korrigiert, um den Auftrag

Mehr

Leitfaden zum Erstellen der Projektarbeit

Leitfaden zum Erstellen der Projektarbeit Leitfaden zum Erstellen der Projektarbeit an der Höheren H http://www.slideshare.net www.slideshare.net/rudolpdo/vorgehensweise vorgehensweise-projektarbeit Was ist gefordert? Projektmanagement Unterlagen

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

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

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

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.1 Wie kommt es zu einem Projektauftrag? Auftraggeber Projekt-Idee / Ziele [Anforderungen/Spezifikation/

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

Einführung in die SWE

Einführung in die SWE Einführung in die SWE Inhalte der Vorlesung Allgemeine Ziele der Lehrveranstaltung Entwickeln einer kleinen Applikation nach professionellem Vorgehensmodell Erlernen des objektorientierten Herangehens

Mehr

IKP Uni Bonn Medienpraxis EDV II Internet Projekt

IKP Uni Bonn Medienpraxis EDV II Internet Projekt IKP Uni Bonn Medienpraxis EDV II Internet Projekt WS 2001/2002 Dozentin: Lucie Prinz Grundlagen der Projektarbeit Was ist ein Projekt? Die Phasen eines Software Projektes Die Projektunterlagen Die Projektplanung

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

Grundlagen der Projektarbeit

Grundlagen der Projektarbeit Lerninhalte ❶ ❷ ❸ ❹ ❺ ❻ Ziele und Aufgaben des s Beteiligte des s Aufstellung der IS-Architektur (Überblick) Projektplanung Projektentwicklung Projektorganisation Lerninhalte L1 i Ziele und Aufgaben des

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

Aller Anfang ist schwer Starthilfen in der Wissenschaft. Projektplanung: Do s and Don ts

Aller Anfang ist schwer Starthilfen in der Wissenschaft. Projektplanung: Do s and Don ts 6. COMBATing Breast Cancer Chances for Cure Aller Anfang ist schwer Starthilfen in der Wissenschaft Projektplanung: Do s and Don ts Dieter Niederacher COMBATing Breast Cancer 2013 Präsymposium TraFo Kommission

Mehr

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I)

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Historisch Kulturelle Informationsverarbeitung Hauptseminar: KLIPS 2.0 Dozent: Prof. Dr. Thaller Referent:

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

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

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

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

Projekte planen und überwachen mit OpenProject Anwenderhandbuch

Projekte planen und überwachen mit OpenProject Anwenderhandbuch Projekte planen und überwachen mit OpenProject Anwenderhandbuch Force4project GmbH force4project.ch@ziknet.ch Schulstrasse 1 +41 627390090 CH-5037 Muhen www.force4project.ch Anwenderhandbuch OpenProject

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 Entwicklung 2. Projektplanung

Software Entwicklung 2. Projektplanung Software Entwicklung 2 Projektplanung SE 2 Projektplanung Inhalt Der Projektplan Aufbau von Projektplänen Zeitplanung mit MPM-Netzplänen Einsatzmittelplanung Methodik der Projektplanung 2 SE 2 Projektplanung

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

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

Operations Strategie und Management. - Projektmanagement - Helmut M. Dietl 1

Operations Strategie und Management. - Projektmanagement - Helmut M. Dietl 1 Operations Strategie und Management - Projektmanagement - Helmut M. Dietl 1 Lernziele Nach dieser Veranstaltung sollen Sie wissen, was man unter einem Projekt versteht was Projektmanagement bedeutet wie

Mehr

Praxis-Handbuch Projektmanagement 00 / Inhaltsangabe

Praxis-Handbuch Projektmanagement 00 / Inhaltsangabe Praxis-Handbuch Projektmanagement Kapitel 01 - Einführung und Grundlagen Unternehmen im Wandel der Zeit Wandel der Organisation 01-03 Gründe für Projektmanagement 01-04 Projektdefinition Merkmale eines

Mehr

Software- Projektmanagement. Dokument V 1.2-2010. Oliver Lietz - Projektmanagement. Projektmodelle im Vergleich. Agil Extreme Programming /

Software- Projektmanagement. Dokument V 1.2-2010. Oliver Lietz - Projektmanagement. Projektmodelle im Vergleich. Agil Extreme Programming / Software- Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.2-2010 Projektmodelle im Vergleich Klassisch Wasserfall -Modell Spezifikation/Pflichtenheft

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

Projektmanagement: Eine Einführung. 3. Februar 2015

Projektmanagement: Eine Einführung. 3. Februar 2015 Projektmanagement: Eine Einführung 3. Februar 2015 Überblick Welche wesentlichen Projektaufgaben gibt es? Wie sollte eine ideale Projektführung aussehen? Wie plant man ein Projekt? Meilensteine Arbeitspakete

Mehr

Grundlagen des Projektmanagements Im Rahmen der Haupstudiumsprojekte am Fachbereich Informatik und Gesellschaft an der TU Berlin

Grundlagen des Projektmanagements Im Rahmen der Haupstudiumsprojekte am Fachbereich Informatik und Gesellschaft an der TU Berlin Grundlagen des Projektmanagements Im Rahmen der Haupstudiumsprojekte am Fachbereich Informatik und Gesellschaft an der TU Berlin Raphael Leiteritz, raphael@leiteritz.com, 22. April 2002 1 Inhalt 1 Was

Mehr

Semesterprojekt SS 2011

Semesterprojekt SS 2011 Semesterprojekt SS 2011 Projektmanagement Teil 1 Dr. rer. nat. Andreas Tewes Als Vorlage zu dieser Vorlesung diente: projektmanagement für newcomer RKW Sachsen GmbH Kompetenzzentrum Managementsysteme Selbst

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

1 Phase «Initialisierung»

1 Phase «Initialisierung» 1.1 Übersicht Projektanmeldung Projektportfolio Projektrandbedingungen Projekt vorbereiten Projektantrag Projekthandbuch Projektplan Zurückweisung Projektauftrag Projektportfolio Status Abbruch Phase Voranalyse

Mehr

Lösungen zum Test objektorientierter Software

Lösungen zum Test objektorientierter Software Lösungen zum Test objektorientierter Software Pieter van den Hombergh Fontys Hogeschool voor Techniek en Logistiek Software Engineering 14. März 2013 HOM/FHTeL Lösungen zum Test objektorientierter Software

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 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

Anforderungen an ein modernes Projektmanagement

Anforderungen an ein modernes Projektmanagement Anforderungen an ein modernes Projektmanagement In Unternehmen aller Branchen scheitern nach unabhängigen Studien ca. 30% aller Projekte. Hierbei handelt es sich sowohl um Projekte des Betriebszwecks als

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

Optimieren von Requirements Management & Engineering

Optimieren von Requirements Management & Engineering Xpert.press Optimieren von Requirements Management & Engineering Mit dem HOOD Capability Model Bearbeitet von Colin Hood, Rupert Wiebel 1. Auflage 2005. Buch. xii, 245 S. Hardcover ISBN 978 3 540 21178

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

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

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung Unified Process Eine Einführung von Hannes Fischer Fischer Software Elfenstr. 64 70567 Stuttgart Deutschland Copyright 2000 Hannes Fischer Unified Process Wie wird heute gearbeitet? Der Unified Process

Mehr

Grob- und Detailplanung bei der Implementierung nutzen

Grob- und Detailplanung bei der Implementierung nutzen Softwarearchitektur Grob- und Detailplanung bei der Implementierung nutzen Bereich Realisierung Aktivität Softwareinkrement realisieren Ziele Vermitteln einer Orientierungshilfe für alle Entwickler Etablierung

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

Softwareentwicklungsprozesse. 18. Oktober 2012

Softwareentwicklungsprozesse. 18. Oktober 2012 Softwareentwicklungsprozesse 18. Oktober 2012 Überblick Was soll ein Softwareentwicklungsprozess leisten? Überblick über Softwareentwicklungsprozesse Welche gibt es? Warum gibt es mehrere? Diskussion:

Mehr

AD HOC Personal- und Organisationsberatung GmbH, Obergrundstrasse 50, 6003 Luzern Fon 041 211 14 04 Fax 041 211 14 05 www.adhoc-beratung.

AD HOC Personal- und Organisationsberatung GmbH, Obergrundstrasse 50, 6003 Luzern Fon 041 211 14 04 Fax 041 211 14 05 www.adhoc-beratung. AD HOC Personal- und Organisationsberatung GmbH, Obergrundstrasse 50, 6003 Luzern Fon 041 211 14 04 Fax 041 211 14 05 www.adhoc-beratung.ch Projektmanagement Was ist ein Projekt, und was ist Projektmanagement?

Mehr

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung Block R (Rahmen): SE Aktivitäten 21.10.04 1 Vorlesung Methoden des Software Engineering Block R Rahmen Aktivitäten der Software-Entwicklung Martin Wirsing Einheit R.2, 21.10.2004 Block R (Rahmen): SE Aktivitäten

Mehr

1 Einleitung. Software Engineering. Vorgehensweisen

1 Einleitung. Software Engineering. Vorgehensweisen 1 Noch ein Buch über Software Engineering? Warum nicht! Wir folgen einem Prinzip, das zur Lösungsfindung in den verschiedensten Domänen Einzug gehalten hat: die Betrachtung aus verschiedenen Blickwinkeln.

Mehr

Projektmanagement. Muster-Projekthandbuch

Projektmanagement. Muster-Projekthandbuch Projektmanagement Muster-Projekthandbuch Muster-Projekthandbuch Seite 2 Das Projekthandbuch (PHB) Das Projekthandbuch ist als genereller Leitfaden für die Projektarbeit im Rahmen des Lehrganges Projektmanagement-Bau

Mehr

tzung - Microsoft Project

tzung - Microsoft Project Projektmanagement mittels Softwareunterstützung tzung - Microsoft Project Umwelt- und Unternehmens- Beratung Dr. Anke Schwan Berlin, 1. Juli 2009 Jana-Maria Seiferth Gliederung 1] Grundlagen des Projektmanagements

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

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

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

Vorlesung Projektmanagement und Teamorganisation

Vorlesung Projektmanagement und Teamorganisation Vorlesung Projektmanagement und Teamorganisation Dr. Bernhard Schätz Leopold-Franzens Universität Innsbruck Sommersemester 2003 Übersicht 1. Übersicht 2. Projektmanagement und Software-Engineering 3. Projektstrukturen

Mehr

Softwareentwicklungspraktikum Sommersemester 2007. Testdokumentation

Softwareentwicklungspraktikum Sommersemester 2007. Testdokumentation Softwareentwicklungspraktikum Sommersemester 2007 Testdokumentation Auftraggeber Technische Universität Braunschweig

Mehr

PMO. Projektmanagement in den Kliniken der Stadt Köln. 23. Juni 2010

PMO. Projektmanagement in den Kliniken der Stadt Köln. 23. Juni 2010 PMO Projektmanagement in den Kliniken der Stadt Köln 23. Juni 2010 Agenda Inhalt 1.Das Projektmanagement Office (PMO) bei den Kliniken der Stadt Köln ggmbh 2.Strukturierung und Priorisierung der Projektarbeit

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

Ü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

Requirements Engineering (Anforderungstechnik)

Requirements Engineering (Anforderungstechnik) 5 Requirements Engineering Einführung 5.1 Was ist Requirements Engineering? Erste Näherung: Requirements Engineering (Anforderungstechnik) ist das systematische, disziplinierte und quantitativ erfassbare

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

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

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. SOFTWARETECHNIK Kapitel 7 Vorgehensmodelle Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. Armin Zimmermann Inhalt Vorgehensmodelle Sequenzielle Modelle Iterative

Mehr

Projektmanagement mit Netzplantechnik

Projektmanagement mit Netzplantechnik NWB - Studienbücher Wirtschaftswissenschaften 2008 AGI-Information Management Consultants May be used for personal purporses only or by libraries associated to dandelon.com network. Projektmanagement mit

Mehr

www.nwb.de NWB Studium Betriebswirtschaft Projektmanagement mit Netzplantechnik Von Professor Dr. Jochen Schwarze

www.nwb.de NWB Studium Betriebswirtschaft Projektmanagement mit Netzplantechnik Von Professor Dr. Jochen Schwarze www.nwb.de NWB Studium Betriebswirtschaft Projektmanagement mit Netzplantechnik Von Professor Dr. Jochen Schwarze 11., überarbeitete und erweiterte Auflage *nwb STUDIUM Inhaltsverzeichnis Teil I: Grundlagen

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

6 Architektur-Mittel (WOMIT)

6 Architektur-Mittel (WOMIT) 6 Architektur-Mittel (WOMIT) Abb. 6-1: Positionierung des Kapitels im Ordnungsrahmen. Dieses Kapitel befasst sich mit der WOMIT-Dimension des architektonischen Ordnungsrahmens, indem es grundlegende Konzepte

Mehr

Die Projektphasen. Projektphasen eines Organisationsprojekt. Beispiel Messeauftritt Frankfurter Buchmesse: Phase 1: Anstoß.

Die Projektphasen. Projektphasen eines Organisationsprojekt. Beispiel Messeauftritt Frankfurter Buchmesse: Phase 1: Anstoß. Die Projektphasen Projektphasen eines Organisationsprojekt Beispiel Messeauftritt Frankfurter Buchmesse: Phase 1: Anstoß Phase 2: Konzept Phase 3: Detailplanung Phase 4: Realisierung Phase 5: Auswertung

Mehr

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

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

Mehr

Kapitel 2: Der Software-Entwicklungsprozess

Kapitel 2: Der Software-Entwicklungsprozess Wie konstruiert man Software? Kapitel 2: Der Software-Entwicklungsprozess SoPra 2008 Kap. 2: Der Software-Entwicklungsprozess (1/10) Der Software-Entwicklungs-Prozess Historisches 1960JJ adhoc Techniken

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

Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise

Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise Die Bearbeitungszeit der Klausur beträgt 90 Minuten. Es sind alle

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

1 Einleitung. 2 Formale Grundlagen. 3 Leistungen der Vertragspartner. 1.1 Zweck, Abgrenzung. 1.2 Projektübersicht, Motivation. 3.

1 Einleitung. 2 Formale Grundlagen. 3 Leistungen der Vertragspartner. 1.1 Zweck, Abgrenzung. 1.2 Projektübersicht, Motivation. 3. Projektplan Hive Version: 1.1 Autoren: Robin Goldberg (2453516) Hansjörg Schmauder (2531506) Benjamin Schmidt(2443953) Erstellt am: 15.02.2010 Letzte Änderung: 24.06.10 Inhaltsverzeichnis 1 Einleitung...

Mehr

Referat Extreme Programming. Von Irina Gimpeliovskaja und Susanne Richter

Referat Extreme Programming. Von Irina Gimpeliovskaja und Susanne Richter Referat Extreme Programming Von Irina Gimpeliovskaja und Susanne Richter 1.) Was ist XP? Überlegte Annäherung an Softwareentwicklung Prozessmodell für objektorientierte Softwareentwicklung erfordert gute

Mehr

Softwarepraktikum. Gernot A. Fink SS 2005

Softwarepraktikum. Gernot A. Fink SS 2005 Softwarepraktikum Gernot A. Fink SS 2005 Einführung Wichtige Grundbegriffe Was ist Softwareengineering? Software- und Projektentwicklung Anfordernugen and Softwareentwicklung Softwareprozesse und Vorgehensmodelle

Mehr

Dipl. Inf. Ali M. Akbarian

Dipl. Inf. Ali M. Akbarian Dipl. Inf. Ali M. Akbarian 2012 Einführung Globalisierung, Innovation und Kundenzufriedenheit sind auch in Zukunft die wichtigsten Herausforderungen der Unternehmen. Diese Herausforderungen verlangen:

Mehr

Software Engineering. 2. V-Modell XT

Software Engineering. 2. V-Modell XT Software Engineering 2. V-Modell XT Gliederung Vorlesung Einführung V-Modell XT Analyse und Anforderungsmanagement Benutzungsoberflächen Architektur Entwurf Entwurfsmuster Persistenz Implementierung Konfigurationsmanagement

Mehr

Grundlagen verteilter Systeme

Grundlagen verteilter Systeme Universität Augsburg Insitut für Informatik Prof. Dr. Bernhard Bauer Wolf Fischer Christian Saad Wintersemester 08/09 Übungsblatt 5 26.11.08 Grundlagen verteilter Systeme Lösungsvorschlag Aufgabe 1: Erläutern

Mehr

Betriebskalender & Kalenderfunktionen

Betriebskalender & Kalenderfunktionen Betriebskalender & Kalenderfunktionen Der Betriebskalender ist in OpenZ für 2 Dinge verantwortlich: 1. Berechnung der Produktionszeiten im Modul Herstellung 2. Schaffung der Rahmenbedingungen, für die

Mehr

Einführung in das Projektmanagement

Einführung in das Projektmanagement Einführung in das Projektmanagement Komplexe und neuartige Aufgaben werden in Form von Projekten abgewickelt. Zur erfolgreichen Projektsteuerung ist ein Projektmanagement unverzichtbar. Projektmanagement

Mehr

Extremes Programmieren

Extremes Programmieren Extremes Programmieren Übersicht, Demonstration, Erfahrungen ACM/GI Regionalgruppe Hamburg, 16.3.2001 Frank Westphal unabhängiger Berater westphal@acm.org http://www.frankwestphal.de Tammo Freese OFFIS,

Mehr

15 Verwaltung von Anforderungen (Requirements Management)

15 Verwaltung von Anforderungen (Requirements Management) 15 Verwaltung von Anforderungen (Requirements Management) Was ist Requirements Management? Planung und Lenkung des RE-Prozesses Konfigurationsmanagement für Anforderungen Identifikation Änderungs- und

Mehr

3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process.

3.4 Unified Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. 1999 Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process. 1996 Philippe Kruchten: Rational Unified Process Produkt der Firma Seit 2002 Teil des IBM Konzerns Objektorientiertes

Mehr

Hinweise zur Bewertung und Korrektur der Abiturarbeiten (2007)

Hinweise zur Bewertung und Korrektur der Abiturarbeiten (2007) Hinweise zur Bewertung und Korrektur der Abiturarbeiten (2007) Kriterien zur Bewertung von Aufgaben: s. EPA: Gesamtanforderung umfasst inhaltliche, methodische und sprachliche Leistung; die Bearbeitung

Mehr

Der Grüne Faden des Projektmanagements

Der Grüne Faden des Projektmanagements Behrens Projektmanagement GmbH Hasenberg 6 35041 Marburg Tel.: 06421 / 294 93 26 E-Mail: info@behrens-pm.de Der Grüne Faden des Projektmanagements Planungsphase Die Weichen für ein erfolgreiches Projekt

Mehr

Kosten- oder Nutzenfaktor?

Kosten- oder Nutzenfaktor? Projektmanagement im Mittelstand Kosten- oder Nutzenfaktor? Dipl.-Ing. Willi Wurl Rosenstraße 39 D-71543 Wüstenrot Prozess- & Projektmanagement 11. April 2006 0 Einleitung Situation in mittelständischen

Mehr

Techniken zu Schreibwerkstatt Phase 1: Ein Thema erforschen und eingrenzen

Techniken zu Schreibwerkstatt Phase 1: Ein Thema erforschen und eingrenzen Techniken zu Schreibwerkstatt Phase 1: Ein Thema erforschen und eingrenzen Die 5 folgenden Techniken können Ihnen dabei helfen, ein passendes Thema bzw. eine Hypothese zu finden. 1. Fragen helfen beim

Mehr

Grundlagen des Projektmanagements

Grundlagen des Projektmanagements Grundlagen des Projektmanagements dynamisch Umweltzustände statisch Steigende Notwendigkeit neuerer, effektiver Organisationsformen einfach Aufgabentypen komplex Vorphase Analyse Entwurf Realisierung Einführung

Mehr

Testfragen PRINCE2 Foundation

Testfragen PRINCE2 Foundation Testfragen PRINCE2 Foundation Multiple Choice Prüfungsdauer: 20 Minuten Hinweise zur Prüfung 1. Sie sollten versuchen, alle 25 Fragen zu beantworten. 2. Zur Beantwortung der Fragen stehen Ihnen 20 Minuten

Mehr

Conversion Attribution

Conversion Attribution Conversion Attribution Eines der Trendthemen über das zurzeit jeder spricht ist Attribution. Das heißt allerdings nicht, dass auch jeder weiß was genau Attribution ist, was man damit machen kann und für

Mehr

4Time: Das Cockpit für Projektunternehmen

4Time: Das Cockpit für Projektunternehmen 4Time: Das Cockpit für Projektunternehmen 4Soft-Whitepaper 4. Juni 2007 Steuerung und Controlling von Projektunternehmen sind anspruchsvolle Aufgaben. Auf der einen Seite müssen Manager die Unternehmensziele

Mehr

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

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

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

Projektmanagement im Verein Aufgaben und Projekte gemeinsam im Team bearbeiten

Projektmanagement im Verein Aufgaben und Projekte gemeinsam im Team bearbeiten Projektmanagement im Verein Aufgaben und Projekte gemeinsam im Team bearbeiten Rainer Ahlers Verkaufsleiter Sport-Thieme GmbH Grasleben, 01.06.2009 Projekte Ein Projekt ist ein einmaliger Prozess, der

Mehr

IT-Projektmanagement - Methoden und Techniken

IT-Projektmanagement - Methoden und Techniken IT-Projektmanagement - Methoden und Techniken Seminarunterlage Version: 6.02 Version 6.02 vom 9. April 2015 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen

Mehr

5.1 Aufgaben des Projektmanagement im Bauwesen... 1. 5.2 Möglichkeiten von Projektmanagement-Programmen auf dem PC... 2

5.1 Aufgaben des Projektmanagement im Bauwesen... 1. 5.2 Möglichkeiten von Projektmanagement-Programmen auf dem PC... 2 V / i Gliederung 5 Projektplanung mit dem PC... 1 5.1 Aufgaben des Projektmanagement im Bauwesen... 1 5.2 Möglichkeiten von Projektmanagement-Programmen auf dem PC... 2 5.3 Grundlagen der Netzplantechnik

Mehr

Agile Software Development

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

Mehr

Software Expedition. Seminar Systems Engineering extreme Programming

Software Expedition. Seminar Systems Engineering extreme Programming Software Expedition Seminar Systems Engineering extreme Programming Übersicht (1) Einleitung Von der klassischen Expedition zur Software-Expedition Software-Expedition als Vorgehensweise in einem instabilen

Mehr

Service Management: Operations, Strategie und e-services Prof. Dr. Helmut M. Dietl

Service Management: Operations, Strategie und e-services Prof. Dr. Helmut M. Dietl Service Management: Operations, Strategie und e-services Universität Zürich Institut für Strategie und Unternehmensökonomik Services- und Operationsmanagement Übersicht 1. Nachfrageprognose 2. Variabilitätsmanagement

Mehr