COCOMO COnstructive COst MOdel

Größe: px
Ab Seite anzeigen:

Download "COCOMO COnstructive COst MOdel"

Transkript

1 Universität Salzburg Institut für Computerwissenschaften PS Software Engineering II Leitung: Mag. Maurutschek Seminararbeit COCOMO COnstructive COst MOdel Donnerstag, den (SS 2002) Klaus Werdenich ( )

2 Inhaltsverzeichnis 1 Einleitung - Abgrenzung der Themenstellung 3 2 cost estimation - Das Fundament jedes Softwareprojekts Kostenverteilung eines Projekts Gründe für genaues Kostenschätzen? Zeilen der Warnung Schritte bis zum eigenen Aufwandabschätzungsmodell Die Kostenfaktoren - Cost Drivers Wie groß wird mein Projekt? - Size Estimation Das Aufwandabschätzungsmodell Ansätze der Kostenabschätzung für Softwareprojekte 11 4 Grundlegendes - der COCOMO Prolog Nützliches - Metriken Allgemeine Einführung zu COCOMO COCOMO - constructive cost model Die Geschichte - wie es dazu kam Der Mann hinter COCOMO - Barry W. Boehm Die Intention für COCOMO - der SE Ansatz Das COCOMO Die drei Projektmodi - Deklaration der Größe und Art des Projekts Verteilung des Aufwands und der verfügbaren Zeit auf die Entwicklungsphasen bei Softwareprojekten Die drei Berechnungsverfahren Basic COCOMO - das grobe Berechnungsverfahren Intermediate COCOMO - das verfeinerte Berechnungsverfahren Detailed COCOMO - das präziseste Berechnungsverfahren Kostenabschätzung heute - Aufbruch in eine neue (Kostenschätzungs-) Welt Veränderungen im Software Engineering Die Grenzen der alten Software Kostenabschätzungsverfahren COCOMO II Strategie und Ziele Softwareengineering heute - auf dem Marktplatz Marktdifferenzierung - Für wen kann COCOMO II nützlich sein? Die 3 Submodelle Aufwandberechnung

3 7.4.1 Skalen Effekte - Skalenfaktoren Effort Multiplier Time To Develop (TDEV) Anpassen und Wiederverwerten von Code Kalibrierung COCOMO II in der Praxis Vergleich COCOMO 81 bis COCOMO II 39 9 Literatur Anhang - Fragenblock 41 2

4 1 Einleitung - Abgrenzung der Themenstellung Das Ziel dieser schriftlichen Ausführung zum Thema COnstructive COst MOdel (COCOMO) - cost estimation model im Zuge der Lehrveranstaltung Software Engineering II, ist in erster Linie die Präsentation des COCOMO. Weiters soll auf den Themenkomplex cost estimation allgemein eingegangen werden, wobei primär die Absicht darin besteht plausibel zu machen, warum eine Kostenabschätzung von derart immanenter Bedeutung ist. Folgend eine kurze Erläuterung der veschiedenen Ansätze, die für Kostenabschätzungen von Software Projekten bestehen. Schließlich im Zentrum der Ausführungen wird das COCOMO näher betrachtet. Seine Intention, was es ist, wie es dazu wurde und woher es kam. Der nächste große Abschnitt wird die Software - Kostenabschätzung heute zum Inhalt haben. Hier wird auf die Veränderung der Softwareentwicklung seit COCOMO 81 näher eingegangen, der Marktplatz Software Engineering, wie er sich derzeitig präsentiert, beleuchtet, und die Gründe, warum eine neue Generation der Software - Kostenabschätzung notwendig ist - COCOMO 81 nicht mehr funktioniert. Der Vertreter dieser neuen Software-Kostenabschätzungs- Generation ist COCOMO II. Die Betrachtung des COCOMO II, dem Kostenabschätzungs Werkzeug für heute und morgen, wird den Blick in die Gegenwart abschließen. Diese Arbeit wird eine Gegenüberstellung der COCOMOs (COCOMO 81 bis COCOMO II) beenden, die auch Ada COCOMO mit einschließt. Eine nähere Betrachtung von Ada COCOMO, sowie alternativer Kostenabschätzungsmodelle, sieht diese Version der Arbeit, in ihrem Wesen als Seminararbeit, aus Gründen der, bereits in der aktuell vorliegenden Form überschrittenen, Soll Anzahl an Seiten nicht vor. Aus dem selben Grund ist die Behandlung von COCOMO II, im Vergleich zu COCOMO 81 sehr bescheiden. 2 cost estimation - Das Fundament jedes Softwareprojekts Zu Beginn eines Softwareprojekts stehen folgende Fragen: Wie hoch ist der gesamte Arbeitsaufwand für das Projekt? Wie viele Monate wird das Projekt dauern? Wie viele Mitarbeiter benötige ich für das Projekt? Was kostet das Projekt insgesamt? Diese Fragen gilt es möglichst präzise zu beantworten, und dies zu einem Zeitpunkt zu dem präzise Informationen noch nicht verfügbar sind. Eine detaillierte Anforderungsanalyse, die diese 4 Fragen beantworten kann, scheitert primär an der geringen Zeitspanne, die bis zur Frist der Angebotsabgabe festgelegt wird. Ein weiterer Punkt, der eine ausführliche, und gewissenhafte Analyse der Notwendigkeiten für das ausgeschriebenen Projekt problematisch gestaltet ist der dadurch entstehende Aufwand. Dennoch muss innerhalb kürzester Zeit eine 3

5 möglichst genaue Schätzung erfolgen um ein Angebot unterbreiten zu können. Dies geschied mit Hilfe einer Kostenschätzung, die sich nicht auf die Beantwortung jede Frage im Einzelnen konzentriert, sondern sich die Abhängigkeit dieser zu Nutze macht und eine komplette Schätzung, die alle vier Fragen beantwortet, zum Ergebnis hat. 4x Relative Size Range 2x 1.5x 1.25x x Completed Programs USAF/ESD Proposals Size (SLOC) Cost ($) 0.5x 0.25x Concept of Rqts. Operation Spec. Feasibility Plans and Rqts. Product Design Product Design Spec. Detail Design Detail Design Spec. Devel. and Test Accepted Software Phases and Milestones Figure 2. Software Costing and Sizing Accuracy vs. Phase Grafik 1 zeigt die Größenordnung der möglichen Fehlschätzung zur jeweiligen Projektphase coarse-grained 2.1 cost Kostenverteilung driver information eines the Projekts early project stages, and increasingly fine-grained information in later stages. Consequently, COCOMO 2.0 does not produce point estimates of software cost and effort, but rather range estimates tied to the degree of definition of the estimation In einem Softwareprojekt entstehen drei verschiedene Arten von Kosten: inputs. The uncertainty Hardwarekosten ranges (z.b.: in Figure die Rechner 2 are used am Arbeitsplatz as starting der points Mitarbeiter, for these spezielle Peripheriegeräte) estimation ranges. With respect to process strategy, Application Generator, System Integration, and Infrastructure software projects Spesen will und involve Schulungskosten a mix of three (z.b.: major wenn process der Sitz models. des Kunden The appropriate sehr weit sequencing of these models will weg depend ist oder on die the Mitarbeiter project s immarketplace Umgang mitdrivers neuen Anforderungen and degree of konfrontiert werden (z.b.: Programmiersprache)) product understanding. The Application Personalkosten Composition (Effortmodel costs) involves prototyping efforts to resolve potential high-risk issues such as user interfaces, software/system interaction, performance, or technology maturity. Die Hardwarekosten verändern sich nicht in großem Maß, deshalb können sie als The costs Fixkostenpunkt of this type of bezeichnet effort are werden. best estimated Spesen und by Schulungskosten the Applications sind Composition zwar nicht model. The Early konstant, Design allerding model spielen involves sie imexploration gesamten Kostenaufkommen of alternative software/system des Projekts einearchitectures and concepts of operation. At this stage, not enough is generally known to support fine-grain cost estimation. The corresponding COCOMO 2.04capability involves the use of function points and a small number of additional cost drivers. The Post-Architecture model involves the actual development and maintenance of a software product. This model proceeds most cost-effectively if a software life-cycle architecture has been developed; validated with respect to the system's mission, concept of operation, and risk; and established as the framework for the product. The corresponding COCOMO 2.0 model has about the same granularity as the previous COCOMO and Ada COCOMO models. It uses source instruc-

6 sehr kleine Rolle. Deshalb besteht eine Kostenschätzung fast ausschließlich aus einer Schätzung der Personalkosten. Dafür ist von Bedeutung eine Schätzung über den Gesamtaufwand, die Zahl der Mitarbeiter und die Gesamtdauer des Projekts vorliegen zu haben. Für eine erfolgreiche Kostenschätzung ist also die Beantwortung der ersten 3 Fragen notwendig, da aus diesen Informationen der vierte Punkt, die Projektkosten, folgendermaßen errechnet werden können: Kosten = Hardware + Spesen und Schulung + Stundenlohn * Gesamtaufwand. 2.2 Gründe für genaues Kostenschätzen? Warum ist ein genaues Schätzen der mit einem (Software)Projekt verbundenen Kosten von Wichtigkeit? Die Genauigkeit der Schätzungen sind wichtig für das Ansehen eines Unternehmens am Markt. Da das zu stellende Angebot unmittelbar abhängig von der Schätzung ist, haben zu hohe Schätzungen zur Folge, dass das Unternehmen als teuer gilt. Fällt das Angebot zu billig aus, gewinnt man sicher mehr Ausschreibungen, aber die zusätzlichen Kosten müssen entweder vom Kunden oder von der Softwarefirma übernommen werden. Diese Frage der Kostenübernahme führt oft zu einem Gerichtsverfahren, was auch kein gutes Licht auf die Softwarefirma wirft. Falsche - in diesem Fall zu hohe Schätzungen haben weiters zur Folge, dass wohl nur wenige Ausschreibungen gewonnen werden. Für den Zeitplan eines Projekts muss dessen Gesamtaufwand und die Dauer feststehen. Das heißt, eine Kostenschätzung sollte die Basis jedes Projektplans sein. Der Projektplan wiederum ist Grundlage für das ingenieurmäßige Erstellen von Software. Da während des laufenden Projekts die Kostenschätzung aktualisiert wird ergibt sich ein weiterer Vorteil für die Projektsteuerung. Treten in einer Phase des Projekts Schwierigkeiten auf und wird die vorgegebene Zeit überschritten, kann damit gerechnet werden, dass sich die Gesamtdauer des Projekts um diese Zeitspanne verlängert. Somit kann frühzeitig auf die veränderten Situation eingegangen werden und Folgen wie einem verzögertem Auslieferungstermin eventuell entgegengewirkt werden. Weitere Folgen wie der Druck, eines nicht einzuhaltenden Fertigstellungstermin in Folge einer falschen Kostenschätzung, belastet auch das Arbeitsklima innerhalb des Unternehmens und kann zu Spannungen mit der Führungsetage führen. 5

7 2.3 Zeilen der Warnung Die Software Kosten- und Aufwandsabschätzung ist keine exakte Wissenschaft, weil sich zu viele Einflussfaktoren wie die Technik, die Arbeitsumgebung, die Personen selbst und natürlich die Politik von vornherein nicht konstant rational verhalten. Dies kann zu einem unvorhergesehenen Kostenanstieg oder einem nicht einplanbaren Mehraufwand führen - oder am wahrscheinlichsten zu beidem. Es ist zu bedenken, dass die Kostenabschätzung für Zeilen Code nicht vergleichbar ist mit der Kostenabschätzung der Produktion von Klappstühlen Gründe dafür sind unter anderem: Elementare Anweisungen (DSI) sind keine Fließbandware - ganz abgesehen davon, dass das Produkt nicht über die Anzahl an elementaren Anweisungen an Qualität gewinnt, oder das gewünschte Produkt ausmacht. Das Schreiben von Software benötigt neben der Kreativität der Programmierer auch deren Kooperation - ein Faktor, der von vornherein nur äußerst schwer einschätzbar ist. Für die Abschätzung von Softwareprojekten kann man erst auf vergleichsweise bescheidene Erfahrungswerte zurückgreifen. Es fehlt die Quantität an dokumentierten Experimenten an Hand derer Synergien hergestellt werden können. Heute betrachtet man ein Software Kostenabschätzungsmodell als gut einsetzbar, wenn es die tatsächlichen Softwareentwicklungskosten mit einer Toleranz von 20% korrekt angibt - in 70 % der Fälle. Vorausgesetzt es wird für das Projekt das richtige Modell gewählt. Das Intermediate und das Detailed COCOMO, die noch ausführlich besprochen werden, entsprechen diesen Vorgaben Schritte bis zum eigenen Aufwandabschätzungsmodell Die Interessen eines Unternehmens sind am besten aufgehoben, wenn sie selbst ihr eigenes Aufwandsabschätzungsmodell entwickelt Das hier präsentierte Modell bietet einen generellen Ansatzpunkt - firmenspezifische Daten müssen allerdings darüber hinaus entsprechend festgelegt werden. Für die Entwicklung eines Aufwandsabschätzungsmodell müssen diese 6 Schritte vollzogen werden. 1. Es muss eine Liste über potentielle / wichtigste Aufwandskosten (cost drivers) festgelegt werden 2. Für jeden Aufwand- und Kostenfaktor muss ein skalierendes Modell festgelegt werden. 3. Ein Aufwandsabschätzungsmodell ist auszuwählen. 6

8 4. Das Projekt gilt es zu bewerten, abzuschätzen und die Teilprojekte untereinander zu vergleichen. 5. Die Qualität der Abschätzung ist an Hand von Projekten aus der Geschichte zu evaluieren. 6. Das Modell gehört in festgeschriebenen Intervallen entsprechend angepasst und bewertet Die Kostenfaktoren - Cost Drivers Bei der Schätzung der Projektkosten gilt es die wichtigsten Kostenfaktoren (cost drivers) besonders zu betrachten. Zu diesen zählen die Variablen, die, die Anzahl der, für das Projekt aufzuwendenden Säcke an Geld, beeinflussen. Diese Kostenfaktoren können von Projekt zu Projekt variieren. Die Gewichtung des einzelnen Kostenfaktors hängt weitgehend von dem verwendetem Aufwandsabschätzungsmodell ab. Der für das COCOMO Modell zentrale Kostenfaktor ist die Größe des Softwareprodukts - der weitgehend als einer der wichtigsten cost drivers zählt. Aus diesem Grund eine nähere Betrachtung. Welche Bedeutung hat die Größe eines Softwareprodukts? Sie ist wie bereits erwähnt einer der bedeutendsten Kostenfaktoren bei der Entwicklung von Software. Sie ist das schwächste Glied der Abschätzungsprozesskette. Es benötigt ihrer Extrabetrachtung, wenn eine Organisation ihr eigenes Aufwandsabschätzungsmodell entwickelt Wie groß wird mein Projekt? - Size Estimation Function Points (FPs) ist eine Metrik, die von Albrecht und Gaffney entwickelt wurde. Damit man Function Points zur Schätzung von Softwareprojekten verwenden kann, werden sogenannte historische Daten benötigt. Das heißt es müssen bei vergangenen Projekten, von denen Aufwand und Dauer bekannt sind, die Function Points gezählt werden. Daraus ermittelt man dann die Zahl X = Aufwand / FPs. Bei neuen Projekten zählt man nun die Function Points und multipliziert sie mit X: Aufwand = X * FPs. Ausgangspunkt sind die zu implementierenden Funktionen, auf die im Folgenden genauer eingegangen wird. Zählen und Gewichten Es werden fünf unterschiedliche Funktionsklassen unterschieden: Eingaben Daten oder Kontrollinformationen, die von außerhalb der Systemgrenzen kommen Ausgaben Daten oder Kontrollinformationen, die an außerhalb der Systemgrenzen gesendet werden 7

9 Anwenderdateien Gruppe logischer Daten oder Kontrollinformationen, die von der Anwendung verwaltet werden. Referenzdaten Gruppe logischer Daten oder Kontrollinformationen, die extern gespeichert sind (nicht von der Anwendung verwaltet werden). Abfragen Elementarer Prozess, der aus Ein-Ausgabe-Kombination besteht (über die Systemgrenzen hinweg), die die Suche nach Daten umfasst. Christian Viehmann Kostenschätzung Die Gewichtung der Funktionen erfolgt nach folgender Tabelle: Die einzelnen Funktionen werden auch jeweils nach vorgegebenen Richtlinien in einfache, mittlere und komplexe Funktionen unterteilt. Mittels dieser Tabelle wird dann die Gewichtung vorgenommen: Beschreibung einfach mittel komplex Gesamt Eingaben * 3 = * 4 = * 6 = Ausgaben * 4 = * 5 = * 7 = Anwenderdateien * 7 = * 10 = * 15 = Referenzdaten * 5 = * 7 = * 10 = Abfragen * 3 = * 4 = * 6 = UFP (Total Unadjusted Function Points) Einflussfaktoren Die Gesamtsumme, Einflussfaktoren also die UFP wird nun durch 14 Einflussfaktoren korrigiert. Der Einfluss jedes Faktors wird von Die 0 bis vorläufigge 5 gewichtet. Gesamtsumme, Das heißt: 0 = kein dieeinfluss, unadjusted..., 5 function = sehr starker points Einfluss. (UFP), wird nun durch 14 Einflussfaktoren korrigiert. Der Einfluss jedes Faktors wird von 0 bis 51. gewichtet. Data Communications Das heißt: 0 = kein Einfluss,..., 5 = sehr starker Einfluss. Daten werden über Kommunikationseinrichtungen empfangen oder gesendet Distributed Data Communications Data Processing... Daten werden über Kommunikationseinrichtungen liegen empfangen verteilt oder gesendet Daten Schnelle Antwortzeiten wichtig Daten liegen verteilt 3. Performance 2. Distributed Data Processing Heavily Used Configuration 3. Performance... Schnelle Antwortzeiten wichtig Stark belastetes System Transaction Heavily Used Rate Configuration... Stark belastetes System Hohe Transaktionsrate On-line Transaction Data Entry Rate... Hohe Transaktionsrate Dateneingabe erfolgt online End On-line User Efficiency Data Entry... Dateneingabe erfolgt online Online Dateneingabe ist dialogorientiert 7. End User Efficiency... Online Dateneingabe ist dialogorientiert 8. On-line Update 8. Wartung On-lineerfolgt Update online... Wartung erfolgt online 9. Complex Processing Komplexe Datenverarbeitung 10. Reusability 8 Wiederverwendung 11. Installation Ease Vereinfachen der Installation 12. Operational Ease Vereinfachen der Bedienung 13. Multiple Sites Anwendung ist bei mehreren Lokationen zu installieren

10 9. Complex Processing... Komplexe Datenverarbeitung 10. Reusability... Wiederverwendung 11. Installation Ease... Vereinfachen der Installation 12. Operational Ease... Vereinfachen der Bedienung 13. Multiple Sites... Anwendung ist bei mehreren Lokationen zu installieren 14. Facilitate Change... Änderungsdienste vereinfachen Summe: Total Degree of Influence... Die Adjusted Function Points (AFP) ergeben sich dann aus: AFP = UFP * (0,65 + 0,01 * Total Degree Of Influence) In der Literatur findet man häufig nur den Begriff Function Points (FP). Damit sind meist AFP gemeint. Der Adjustment Faktor (0,65 + 0,01 * Total Degree Of Influence), hat minimal den Wert 0,65 und maximal den Wert 1,35. Die Unadjusted Function Points werden also im Extremfall noch um 35% nach oben beziehungsweise unten korrigiert. Um nun endgültig auf die Anzahl der Codezeilen (LOC) zu kommen müssen die AFP noch mit der programmspezifisch typischen Anzahl von LOC pro Function point multipliziert werden: Angenommen ein Ada Programm benötigt 70 LOC pro Function Point (siehe Tabelle). Bei einer allfälligen Anzahl von Fuction Points, AFP = 164, wird diesem Programm eine Anzahl von LOC = vorausgesagt (Size = FP * 70 = 164 * 70 = LOC). Diese Tabelle gibt Durchschnittswerte an: Sprache Anweisungen pro FP Assembler 320 C 150 Pascal 90 Modula-2 70 Ada83 70 OO-Languages 30 Fourth Generation Languages 20 Function Points sind nicht so bekannt wie COCOMO und werden seltener verwendet. Allgemein kann man sagen: Das Vertrauen in FPs bezüglich der Abschätzung der Größe von Softwareprojekten ist nicht so groß wie das in CO- COMO für die Aufwandsabschätzung dieser. 9

11 2.4.3 Das Aufwandabschätzungsmodell Abschätzungsmodelle basieren auf Messung von Charakteristiken und Eigenschaften (wie zum Beispiel: Projektkosten, Projektdauer, Größe des Teams, benötigter Speicherplatz...), erfolgreicher, bereits abgeschlossener, Projekte. Die erhaltenen Daten werden interpretiert, und bilden die Grundlage für die beschreibenden Formeln, die Modelle. Die Tatsache, dass diese Formeln aus erfolgreichen Projekten der Vergangenheit stammen, fördert die Hoffnung, dass mit ihrer Hilfe eine Vorhersage getroffen werden kann. Im Großen und Ganzen werden Softwareprojekte grob in 2 Klassen unterteilt: Kleine Projekte (Small Projects): Die Messungen bei kleinen und Projekten mittlerer Größe ergaben folgende Formel: AUFWAND = a GRÖSSE + b Hier ist der resultierende Aufwand eine lineare Funktion der Größe des Projekts (für gewöhnlich Anzahl der Zeilen Code). Dieses Modell funktioniert, bei vernünftig gewählter Teamgröße, bei kleinen Teams mit 2 bis 3 Personen. Für größere Teams nimmt die Genauigkeit der Vorhersagen durch diese Formel mit der Anzahl der Mitglieder ab. Große Projekte (Large Projects): Projekte, die eine Teamgröße von mehr als 3 Personen benötigen verhalten sich entsprechend der 2. Formel: AUFWAND = a GRÖSSEb Bei dieser Formel wächst der Aufwand nicht mehr linear, sondern exponentiell (bei b 1). Mit der Größe des Produkts nimmt hier die Produktivität (Größe / Aufwand) ab. Dies bezeichnet man als diseconomy of scale. Wie es dazu kommt Relativ gesehen wird mehr Pruduktdesign benötigt um effiziente Parallelaktivitäten von mehreren Programmieren sicher zu stellen. 2. Es, wird relativ gesehen, mehr Aufwand für die Evaluation der Voraussetzungen und für die Verifikation der Design-Spezifikationen benötigt 3. Auch mit einer klar definierten Spezifikationen brauchen mehrer Programmierer bei großen Projekten, relativ, mehr Zeit für Kommunikation und Fragen betreffend die Interfaces. 4. Für das Zusammenfügen der einzelnen Programmteile und die Integration in das Produkt wird, relativ, mehr Aufwand benötigt. 5. Relativ wird mehr Zeit in ausführliches Testen investiert und zur Beurteilung (Verifikation) des Softwareprodukts. 6. Es ist relativ gesehen mehr Aufwand von Nöten um ein großes Projekt zu managen. Wie viele andere Kostenschätzugsverfahren verwendet auch das COCOMO Modell die oben angegebene Formel zur Aufwandsabschätzung für die Entwicklungvon Software (dazu später noch mehr). 10

12 3 Ansätze der Kostenabschätzung für Softwareprojekte Zur Kostenabschätzung stehen folgende Methoden zur Verfügung: Algorithmische Modelle Algorithmische Modelle bedienen sich einer oder mehrerer mathematischer Formeln mit Hilfe derer sie eine Schätzung als Funktion von bestimmten Kostenfaktoren (cost drivers) erstellen. Ein Beispiel dafür ist die Wiederverwendbarkeit von Programmteilen. Die zwei bekanntesten Vertreter algorithmischer Modelle sind: COCOMO von Barry Boehm und Function Points von Albrecht. Expertenumfrage Bei dieser Methode werden mehrere Experten befragt. Sie erstellen die Kostenschätzung aufgrund ihrer Erfahrung und ihres Wissens. Dies geschieht indem entweder eine Sitzung veranstaltet wird, während der ein Konsens erreicht werden soll, oder man nutzt Verfahren, wie die Delphi- Methode, das darauf abzielt einen Konsens folgendermaßen zu erzielen: Die Experten bleiben untereinander anonym, um persönliche Faktoren auszuschließen. Eine Monitorgruppe hat die Aufgabe die Meinungen der Experten einzuholen indem sie versucht durch Befragung dieser zu einem Ergebnis zu kommen. Die Expertenumfrage wird häufig genutzt, um eine algorithmische Schätzung zu prüfen. Analogie Bei dieser Methode werden Erfahrungen aus mehreren, ähnlichen Projekten aus der Vergangenheit für die Schätzung des aktuellen herangezogen. Dadurch kann die Kostenabschätzung von großen Teilen des Projekts mit hoher Genauigkeit erfolgen. Parkinsons Gesetz Das Parkinson sche Gesetz besagt: Work expands to fill the available volume. Man geht also von einem festen Projektrahmen aus und füllt diesen mit Inhalt. Zur Verdeutlichung dient auch folgendes Beispiel von Barry Boehm: Diese Flugzeugsteuerung muss auf eine Wort-Maschine passen. Deshalb wird die Größe ungefähr Wörter betragen. Die Steuerung muss in 18 Monaten fertig sein und es sind gerade 10 Mitarbeiter verfügbar, um an dem Projekt zu arbeiten. Also beträgt der Aufwand circa 180 Staff-Months. Price-To-Win Ausgehend von einer Ausschreibung schätzt man einen Preis, mit dem man wahrscheinlich den Zuschlag erhält. Dadurch gewinnt man sehr wahrscheinlich eine große Anzahl an Projektausschreibungen, allerdings sind budgetäre Probleme und die daraus resultierende Unzufriedenheit des Kunden eine ebenso wahrscheinliche Konsequenz. Obwohl es eine unseriöse Methode ist, wird sie häufig genutzt. Der Grund dafür ist, dass 11

13 der Kunde meist nicht zwischen einer fundierten und einer price-to-win Schätzung unterscheiden kann und deshalb häufig das billigere Angebot wählt. Bottom-Up Hierbei wird jede Komponente separat geschätzt und die Einzelergebnisse zu einer Gesamtschätzung addiert. Top-Down Diese Methode der Kostenschätzung beruht auf den Eigenschaften des Gesamtprojekts. Danach wird der Schätzwert auf die unterschiedlichen Komponenten aufgeteilt. Diese Methode wird oft in Verbindung mit einer der anderen vorgestellten Methoden genutzt. 4 Grundlegendes - der COCOMO Prolog 4.1 Nützliches - Metriken Im Zusammenhang mit Kostenschätzung sind folgende Metriken von Bedeutung, die zur Verständlichkeit des folgenden Inhalts beitragen sollen: Der Aufwand (Die Zeit, die ein Mitarbeiter alleine für das Projekt benötigen würde) wird in SM (Staff-Months) = 152 Man-Hours nach [Boehm 1981] gemessen. Die Projektdauer (Die Zeit, die ein Projekt mit mehreren Mitarbeitern dauert) bezeichnet man mit Mo (Months) oder mit TDEV(Time for Development). Die Größe eines Softwareprogramms misst man meist in: LOC (Lines Of Code) LOC bezeichnet die Zeilenanzahl des Quelltextes inklusive Kommentaren. Zeilen mit 2 Anweisungen werden als eine LOC gezählt. Die DLOC enthalten nur die an den Kunden ausgelieferten Zeilen. Das heißt hier werden von den LOC noch Zeilen, zum Beispiel für Testrahmen oder Prototypen, abgezogen. DSI (Delivered Source Instructions) nach [Boehm 1981]. Bei DSI werden nur elementare Anweisungen gezählt. Kommentare werden nicht gezählt, Zeilen mit 2 Anweisungen als 2 DSI. 4.2 Allgemeine Einführung zu COCOMO Bevor es möglich ist in die Welt des COCOMO endgültig vorzudringen sollen folgende Fragen noch geklärt werden: Welche Anweisungen gelten als delivered source instructions (DSI)? - aus gegebenem Anlass zur Wiederholung... 12

14 Welche Staff-Months beinhaltet die Schätzungen? Welche Phasen sind in development enthalten? Projekte welcher Eigenschaften können mit Hilfe des Modells abgeschätzt werden? 1. Die DSI - delivered source instructions, die, wie bereits erwähnt einen bedeutenden Anteil der Kosten (sg. cost drivers) ausmachen sind folgendermaßen definiert: Es entsprechen nur dem Kunden als Teil des Produkts gelieferte Zeilen Code als DELIVERED(si). Somit fällt jeglicher Aufwand für Testen und andere Unterstützungssoftware aus dieser Definition hinaus. (d)source(i) code, beinhaltet jeglichen von dem Team produzierten Code. Code von Applikationsgeneratoren ist kein Teil davon. unter (ds)instructions versteht man Zeilen Code oder sg. card images. Deklarationen entsprechen dieser Definietion, Kommentare sind davon ausgeschlossen. 2. Die Abschätzungen des COCOMO beziehen sich ausschließlich auf die Periode zwischen Beginn der Designphase und dem Ende der Integration und Testphase. Die Kosten- und Zeitabschätzungen von anderen Phasen werden separat ermittelt. 3. Unter einem COCOMO Staff-Month (SM) versteht man 152 Stunden Arbeitszeit. Diese Festlegung basiert auf Erfahrungswerte aus der Praxis. COCOMO nimmt keine Abschätzung bezüglich der Arbeitskosten vor. Der Grund dafür ist, dass die Arbeitskosten von Organisation zu Organisation zu stark variieren. Abgesehen davon ist SM eine stabilere Einheit als Dollar. Es besteht allerdings die Möglichkeit nach der Schätzung der SM auf das Ergebnis, mittels Durchschnittswerten, verschiedene Umrechnungen SM zu Dollar durchzuführen. Das Ergebnis kann für die verschiedenen Phasen aufgespaltet werden mit Berücksichtigung auf die für diese Projektphase benötigten Fachkräfte und ihre Bezahlung. Zum Beispiel ist in der Anfangsphasen eines Projekts (Analyse- und frühe Designphase) der erfahrenere Teil der Belegschaft, mit höheren Gehältern, stärker involviert, währenddessen die jungen Kräfte, mit einem geringeren Einkommen in späteren Phasen des Projekts (detailliertes Design, Programmieren und Testen). Aus diesem Grund sind die frühen Phasen finanziell aufwendiger als die Folgenden. 4. Das COCOMO Modell geht davon aus, dass das Management des Projekt sowohl von Seiten der Entwickler wie auch des Kunden gut ist. 5. Das COCOMO Modell nimmt an, dass die Anforderungsspezifikationen nach der Anforderungsphase nicht grundlegend geändert werden. Eine si- 13

15 Technical Approach: COCOMO Baseline gnifikante Änderung sollte eine Modifikation des Kostenschätzungsmodells nach sich ziehen. Figure 1 shows a top-level black box description of COCOMO. It is an open model, in that: 6. Das Detailed COCOMO betrachtet die Kostenfaktoren phasenabhängig. All of Basic its COCOMO relationships und Intermediate and algorithms COCOMO are publicly hingegen nicht, available; ausgenommen zur Unterscheidung von Entwicklung und Wartung. All of its interfaces are public, well-defined, and parametrized, so that complementary preprocessors (function point or other size estimation 5models), COCOMO post-processors - constructive (project planning cost and model control tools, project dynamics models, risk analyzers), and higher level packages (project management packages, product negotiation aids), can be combined straightforwardly with COCOMO. Software product size estimation Software product, process, platform and personnel attributes Software reuse, maintenance, and increment parameters Software organization s project data COCOMO Software development, maintenance cost and schedule estimates Cost, schedule distribution by phase, activity, increment COCOMO recalibrated to organization s data Figure COCOMO 1. COCOMO in einer Grafik Black Box Overview 5.1 Die Geschichte - wie es dazu kam The 5.1.1original Der Mann COCOMO hinter model COCOMO was -calibrated Barry W. to Boehm 56 project data points in 1978, validated Barry Boehm on 7 new ist der project Mann, data der points hinter COCOMO, in 1979, and sowie published COCOMOin 2.0the steht. book, Software Engineering Folgend eine Economics kurze Biographie (by Barry über Boehm, Barry W. Prentice-Hall) Boehms öffentliches in Wirken: COCOMO is used Barry as the Boehm standard erhielt model 1957 im for Zugesoftware seines Mathematikstudiums life cycle cost estimation in Harvard den by the U.S. Army, Bachelor NATO, and of Art numerous (B.A.). corporations. Vier Jahre darauf absolvierte er den Master of Science (M.S.) und 1964 den Doctor of Philosophy (Ph.D.) ebenfalls an der Annual Universität COCOMO von Kalifornien users' ingroup Los Angeles meetings (UCLA). have Vonbeen 1989 held bis 1992 since arbeitete called er fürcocomo/ das US Verteidigungsministerium Software Cost Estimation als DirektorForums). des DARPA At (Defense these meetings, a 1985 (they are now number Advanced of corroborations, Research Projects recalibrations, Agency) - Information and Science improvements and Technology of the Office reported (ITO) und and als discussed. Direktor des DDR&E These meetings Software and have Computer also identified Technology a candidate model have been Office. In den Jahren zwischen 1973 und 1989 wirkte Barry Boehm für TRW agenda of improvements for aligning COCOMO with 1990's 's software (Produktion und Design von Automobil - und Luftfahrtprodukten sowie IT) practices. mit demthe Höhepunkt, next section der Ernennung discusses zum the Chef top der candidate Wissenschaftsabteilung model improvements der in the COCOMO Defense Systems 2.0 technical Group. agenda. Sein Schaffen The following für die Randsection Corporation summarizes von 1959 bis the COCOMO 2.0 program's planned sequence of activities for pursuing the technical agenda. 14 3

16 1973, gipfelte in der Berufung zum Head of the Information Sciences Department. Während 1955 un 1959 arbeitete er als Programmanalytiker bei General Dynamics. Seine aktuelle Forschungstätigkeit beschäftigt sich mit Software Prozessmodellen, Anforderungen für Software Engineering, Software Architekturen, Software Metriken sowie Kostenabschätzungsmodellen, Software Engineering Umgebungen, und wissensbasiertem Software Engineering. Sein bekanntester Beitrag in diesem Bereich ist das Constructive Cost Model (COCOMO (1981) und COCOMO 2.0 (2000)). Weiters zeichnet er sich für das Spiral Model of the software process, dem Theory W (win-win) approach for software management and requirements determination und für zwei fortgeschrittene Software Engineering Umgebungen: der TRW Software Productivity System und der Quantum Leap Environment verantwortlich. Seine wissenschaftlichen Tätigkeiten spiegeln sich in zahlreichen Beiträgen für viele Wissenschaftsmagazine, wie zum Beispiel dem IEEE Transactions on Software Engineering, IEEE Computer, IEEE Software, ACM Computing Reviews, Automated Software Engineering, Software Process, und Information and Software Technology wieder. Er übernahm den Vorsitz des AIAA Technical Committee on Computer Systems, des IEEE Technical Committee on Software Engineering und war Mitglied des Governing Board of the IEEE Computer Society. Aktuell steht er dem Air Force Scientific Advisory Board s Information Technology Panel sowie dem Board of Visitors for the CMU Software Engineering Institute vor. Ihm wurden unter anderem das Gastlektorat der USSR Academy of Sciences (1970), der AIAA Information Systems Award (1979), der J.D. Warnier Prize for Excellence in Information Sciences (1984), der ISPA Freiman Award for Parametric Analysis (1988), der NSIA Grace Murray Hopper Award (1989), der Office of the Secretary of Defense Award for Excellence (1992), der ASQC Lifetime Achievement Award (1994), und der ACM Distinguished Research Award in Software Engineering (1997) verliehen Die Intention für COCOMO - der SE Ansatz Software Kostenabschätzung ist das Verbindungsglied zwischen den Konzepten und Techniken der wirtschaftlichen Analyse und den Eigenheiten der Welt des Software Engineering. Es fällt schwer eine Kosten-Nutzen Analyse über Software, eine break-even Analyse oder eine make-or-buy Entscheidung für Software zu treffen ohne eine klare Möglichkeit der Kostenabschätzung für diese Software zu haben und deren Sensibilität zu verschiedenen Produkten und Projekten sowie zu Umweltfaktoren zu kennen. Mit Hilfe von Abschätzungsmethoden ist ein wichtiger Schritt in Richtung gutes Softwaremanagement getan, das einen wichtigen Grundstein für erfolgreiche Software darstellt. Wird auf ein solches Kostenabschätzungsmodell verzichtet, zeigte die Erfahrung, werden häufig folgende Probleme auftreten: Mitarbeiter bei dem Softwareprojekt haben keine fundierte Basis um dem Projektmanager, dem Kunden oder den Händlern mitzuteilen, dass das veranschlagte Budget und der Zeitplan nicht realistisch sind. Dies führt 15

17 zu optimistischen Versprechungen, für die Softwareentwicklung, in deren Folge zu Kompromissen in sämtlichen Produktbereichen (wie bei der Leistung), unvermeidbarem Zeitdruck und darüber hinaus zu Dumpingpreisen für Softwareprodukte. Den Softwareanalysten fehlt die Grundlage für realistische hardware-software trade-off Analysen während der Designphase des Systems. Daraus kann ein Design resultieren, bei dem die Hardwarekosten niedrig sind, allerdings mit der Folge, dass die Softwarekosten umso höher steigen. Projektmanager können nicht planen, wie lange eine Softwarephase dauert und mit welchem Aufwand sie verbunden ist. Weshalb es nicht möglich ist festzustellen, ob der Fortschritt des Projekts planmäßig ist. Das heißt, dass von Beginn an die Softwareentwicklung außer Kontrolle läuft 5.2 Das COCOMO Das COnstructive COst MOdel (COCOMO) ist ein Beispiel für ein algorithmisches Modell (regression model) zur Kosten- und Aufwandschätzung von Software Diese Methoden verwenden eine Basisformel mit Parameter, die abhängig von Daten aus vergangenen Projekten und aktuellen Projektcharakteristiken festgelegt werden. Das COCOMO Modell ist das bekannteste und akzeptierteste Modell zur Kosten- und Aufwandschätzung von Software. Die zugrundeliegende Formel gewichtet die Größe des Projekts sehr stark ( size-driven model ), weshalb die Fähigkeit des Projektmanagers zu einem sehr frühen Zeitpunkt die Größenordnung des Projekts richtig einzuschätzen von großer Bedeutung ist. Aus diesem Grund wird das COCOMO Modell häufig in Verbindung mit einem der Größenabschätzungsverfahren, wie Function Points, verwendet. COCOMO existiert in einer hierarchischen Struktur, in der die Detailiertheit und Genauigkeit von Stufe zu Stufe zunimmt. Zuallererst steht das Basic COCOMO. Es ist für den Großteil der Softwareprojekte anwendbar: Seiner Abschätzung folgen Softwareprojekte kleiner und mittlerer Größe in einer bekannten Software Entwicklungsumgebung. Basic COCOMO ist konzipiert für eine schnelle, frühe aber grobe Abschätzung der Softwarekosten. Die Genauigkeit ist begrenzt, weil Faktoren wie Unterschiede in der Hardware, Qualität des Personals und dessen Erfahrung, die Verwendung moderner Hilfsmittel und andere Projektattribute mit bekanntem Einfluss keine Berücksichtigung finden Intermediate COCOMO inkludiert diese Faktoren in die Kostenabschätzung. Detailed COCOMO trägt dem Einfluss dieser Faktoren Rechnung und beurteilt sie abhängig von den Projektphasen, für die sie von Bedeutung sind Die drei Projektmodi - Deklaration der Größe und Art des Projekts Für das COCOMO Modell ist der Projektmodus ( development mode ) einer der wichtigsten Faktoren. Er trägt bedeutend zu der Projektdauer und den 16

18 Projektkosten bei. Deshalb wird jedes Projekt einem der 3 Projektmodi zugerechnet: Organic Mode. Semidetached Mode Embedded Mode Um den Aufwand und die Entwicklungszeit abschätzen zu können verwendet COCOMO für alle 3 Projektmodi die selbe Formel, allerdings mit einer anderen Bewertung der Koeffizienten. Aus diesem Grund ist es notwendig zu wissen in welchen Projektmodi das Projekt einzureihen ist. 1. Organic Mode: Relativ kleines Projekt (kleiner als DSI) Stabile Entwicklungsumgebung Jeder Mitarbeiter kennt das gesamte Projekt Das Projekt ist änlich zu bereits entwickelten Produkten, und bedarf keiner großen Innovationen. Der Großteil der mit dem Projekt betrauten Personen konnten während ihrer bisherigen Tätigkeit in der Organisation in ähnlichen Projekten ausreichend Erfahrungen sammeln. Diese Personen können dafür sorgen, dass der Kommunikationsüberschuss zu Beginn des Projekts in Grenzen gehalten wird. Die Festlegung der Spezifikation und der Schnittstellen erfolgt problemlos ebenso die Abstimmung der Anforderungen. Falls das Softwareprodukt nach Korrespondenz mit den anfänglichen Anforderungen einer Überarbeitung bedarf, kann generell eine Modifikation der Spezifikation ausgehandelt werden, die einfacher zu entwickeln ist. Das Basic COCOMO im organic mode verwendet zur Aufwandsabschätzung und zur Abschätzung der Projektdauer folgende Formeln: SM = 2.4 (KDSI) 1.05 TDEV = 2.50 (SM) Semidetached Mode: Mittelgroßes Projekt (zwischen und DSI) Jeder Mitarbeiter besitzt Spezialwissen bezüglich der Entwicklung. Das Team ist, was die Erfahrung der Mitglieder betrifft, nicht homogen. Das Entwicklerteam ist nicht eingespielt 17

19 Das Basic COCOMO im semidetached mode verwendet zur Aufwandsabschätzung und zur Abschätzung der Projektdauer folgende Formeln: SM = 3.0 (KDSI) 1.12 TDEV = 2.50 (SM) 0.35 Bei diesem Projektmodus sind die Charakteristiken des Projekts in der Mitte zwischen organic mode und embedded mode. In der Mitte kann in zweierlei Richtungen interpretiert werden: Die dem semidetached mode zurechenbaren Projekte sind von mittlerem Level, oder sie bestehen aus einer Mixtur aus den Charakteristiken des organic und embedded mode. 3. Embedded Mode: Großes Projekt (über DSI) Noch stärkere Arbeitsteilung, z.b.: nur kleine Anzahl von Analytikern und großes Entwicklerteam Bei diesem Projektmodus ist ein Projekt durch straffe und unflexible Strukturen und ebensolche Anforderungen an die Schnittstellen gekennzeichnet. Das Produkt muss in einem stark aneinander gekoppeltem Komplex aus Hardware, Software und Protokollen sowie operierenden Prozeduren funktionieren. Im embedded mode steht grundsätzlich keine Möglichkeit zur Verfügung Änderungen an der Software über die Modifikation der Anforderungen oder Spezifikation der Schnittstellen durchzuführen. Es benötigt mehr Aufwand um Änderungen durchzuführen und Festzuschreiben. Projekte im embedded mode führt ihr Weg meist durch unbekanntes Terrain zu einer größeren Ausdehnung, als sie beispielweise Projekte des organic mode erreichen. Deshalb wird zu Beginn, ein kleineres Team aus Analysten engagiert, um das Projekt nicht in Kommunikationsüberfluss ertrinken zu lassen.wenn das Produktdesign des Projekts im embedded mode abgeschlossen ist, gilt es eine möglichst hohe Anzahl an Programmierern parallel mit dem detaillierten Design, dem Code schreiben und Testen zu beauftragen. Anderenfalls würde das Projekt bis zur Fertigstellen mehr Zeit in Anspruch nehmen. Dieses Vorgehen zeigt sich in Spitzen in der Personen-Beschäftigungskurve bei embedded mode Projekten und führt zu höheren Aufwänden im Vergleich zu Projekten im organic mode, die sich im selben Entwicklungsstadium befinden. Das Basic CO- COMO im Embedded mode verwendet zur Aufwandsabschätzung und zur Abschätzung der Projektdauer folgende Formeln: SM = 3.6 (KDSI) 1.20 TDEV = 2.50 (SM)

20 Beispiel: Eine große Firma, die Chemikalien erzeugt, plant ein neues Computerprogramm zu entwickeln, das das Handling der Rohmaterialien vereinfachen soll. Dieses Projekt wir von einer Abteilung in der Firma durchgeführt. Die Programmierer und Analysten haben bereits Erfahrung auf diesem Gebiet durch die Entwicklung ähnlicher Programme über mehrere Jahre. Eine Studie legt die Größe des Projekts grob mit DSI fest. Dieses Projekt ist ein gutes Beispiel für ein organic mode Softwareprojekt. Zur Abschätzung werden hier die Formeln des Basic COCOMO organic mode verwendet: Aufwand: SM = 2.4 (32) 1.05 = 91 Staff-Months. Produktivität: DSI / 91 SM = 352 DSI / SM. Projektdauer und Zusammenstellung der Belegschaft: Wenn eine Aufwandsabschätzung gemacht ist, die Anzahl der Staff-Month feststeht, muss ein Manager feststellen, wie groß sein Team sein soll. Diese Festlegung bestimmt auch die voraussichtliche Dauer des Projets. Jedoch sei noch einmal darauf hingewiesen, dass ein größeres Team nicht proportional auf die Projektdauer umlegbar ist. Mehr Mitarbeiter erschweren die Kommunikation untereinander und diese erhöhte Komplexität dokumentiert sich in langsameren Vorankommen bei dem Projekt. Bei der Annahme, dass die Abstimmung zwischen zwei Programmieren 5% der Arbeitszeit betrage [Zelkowitz 78] und die Produktivität eines Programmierers 5000 Codezeilen/Jahr, entsteht für ein Projekt mit einem geplantem Umfang von Codezeilen (das in 2 Jahren fertiggestellt werden soll) folgendes Problem: Teamgröße Produktivität eines Programmierer Produktivität des Teams LOC/Jahr 9500 LOC/Jahr LOC/Jahr LOC/Jahr LOC/Jahr LOC/Jahr LOC/Jahr LOC/Jahr LOC/Jahr LOC/Jahr LOC/Jahr LOC/Jahr LOC/Jahr LOC/Jahr LOC/Jahr LOC/Jahr LOC/Jahr LOC/Jahr LOC/Jahr LOC/Jahr Unter den gegebenen Voraussetzungen kann ein Team von 8 Personen den geforderten Termin (2 Jahre) einhalten. Eine Aufstockung des Teams auf 9 oder 10 Personen kann eine geringfügige Verringerung (max. 2 Monate) der Projektdauer bewirken. Eine Teamgröße die darüber hinausgeht führt zu einem Rückgang der Gesamtleistung (ab 12 Personen). Die zweite Formel des COCOMO Modell dient der Abschätzung der Projektdauer und bedient sich der Aufwandsabschätzung des Projekts (SM). Für das obige Beispiel mit geschätzten 91 SM folgt: 19

A Practical Approach for Reliable Pre-Project Effort Estimation

A Practical Approach for Reliable Pre-Project Effort Estimation A Practical Approach for Reliable Pre-Project Effort Estimation Carl Friedrich Kreß 1, Oliver Hummel 2, Mahmudul Huq 1 1 Cost Xpert AG, Augsburg, Germany {Carl.Friedrich.Kress,Mahmudul.Huq}@CostXpert.de

Mehr

ISO 15504 Reference Model

ISO 15504 Reference Model Prozess Dimension von SPICE/ISO 15504 Process flow Remarks Role Documents, data, tools input, output Start Define purpose and scope Define process overview Define process details Define roles no Define

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

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

Customer-specific software for autonomous driving and driver assistance (ADAS)

Customer-specific software for autonomous driving and driver assistance (ADAS) This press release is approved for publication. Press Release Chemnitz, February 6 th, 2014 Customer-specific software for autonomous driving and driver assistance (ADAS) With the new product line Baselabs

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

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

Neuerungen in den PMI-Standards. PMI Chapter Meeting 30.3.2009 in Frankfurt/Main

Neuerungen in den PMI-Standards. PMI Chapter Meeting 30.3.2009 in Frankfurt/Main Neuerungen in den PMI-Standards PMI Chapter Meeting 30.3.2009 in Frankfurt/Main Ihr Referent Henning Zeumer, Dipl.-Kfm., PMP Selbständiger Projekt- und Programm-Manager, Projektmanagement-Berater und -Trainer

Mehr

CMMI for Embedded Systems Development

CMMI for Embedded Systems Development CMMI for Embedded Systems Development O.Univ.-Prof. Dipl.-Ing. Dr. Wolfgang Pree Software Engineering Gruppe Leiter des Fachbereichs Informatik cs.uni-salzburg.at Inhalt Projekt-Kontext CMMI FIT-IT-Projekt

Mehr

TMF projects on IT infrastructure for clinical research

TMF projects on IT infrastructure for clinical research Welcome! TMF projects on IT infrastructure for clinical research R. Speer Telematikplattform für Medizinische Forschungsnetze (TMF) e.v. Berlin Telematikplattform für Medizinische Forschungsnetze (TMF)

Mehr

Selbstorganisiert ein Ziel erreichen Analyse, Architektur und Design in agilen Software-Projekten

Selbstorganisiert ein Ziel erreichen Analyse, Architektur und Design in agilen Software-Projekten Selbstorganisiert ein Ziel erreichen Analyse, Architektur und Design in agilen Software-Projekten 1 Qualifikation Über den Vortragenden Freiberuflicher SW-Entwickler und Berater seit 2006 Certified Scrum

Mehr

Service Design. Dirk Hemmerden - Appseleration GmbH. Mittwoch, 18. September 13

Service Design. Dirk Hemmerden - Appseleration GmbH. Mittwoch, 18. September 13 Service Design Dirk Hemmerden - Appseleration GmbH An increasing number of customers is tied in a mobile eco-system Hardware Advertising Software Devices Operating System Apps and App Stores Payment and

Mehr

Anforderungen, KEFs und Nutzen der Software- Prozessverbesserung

Anforderungen, KEFs und Nutzen der Software- Prozessverbesserung Process flow Remarks Role Documents, data, tool input, output Important: Involve as many PZU as possible PZO Start Use appropriate templates for the process documentation Define purpose and scope Define

Mehr

Graphisches Entwicklungslinien- und Aufgaben-Tracking für Subversion in Verbindung mit ALM Tool Suiten

Graphisches Entwicklungslinien- und Aufgaben-Tracking für Subversion in Verbindung mit ALM Tool Suiten Graphisches Entwicklungslinien- und Aufgaben-Tracking für Subversion in Verbindung mit ALM Tool Suiten LifeCycle.Conf 2012 in München 24. bis 25. April 2012 Michael Diers, Thomas Obermüller elego Software

Mehr

Prozesse als strategischer Treiber einer SOA - Ein Bericht aus der Praxis

Prozesse als strategischer Treiber einer SOA - Ein Bericht aus der Praxis E-Gov Fokus Geschäftsprozesse und SOA 31. August 2007 Prozesse als strategischer Treiber einer SOA - Ein Bericht aus der Praxis Der Vortrag zeigt anhand von Fallbeispielen auf, wie sich SOA durch die Kombination

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

Keynote Der offene Ansatz: Open Source basiertes ALM ganz praktisch

Keynote Der offene Ansatz: Open Source basiertes ALM ganz praktisch Keynote ALMconf 2010 in Stuttgart 26. bis 28. Oktober 2010 Thomas Obermüller elego Software Solutions GmbH - 2010 1 Welcome & Outline Open Source basiertes ALM ganz praktisch Agenda Application Lifecycle

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

Cloud Architektur Workshop

Cloud Architektur Workshop Cloud Architektur Workshop Ein Angebot von IBM Software Services for Cloud & Smarter Infrastructure Agenda 1. Überblick Cloud Architektur Workshop 2. In 12 Schritten bis zur Cloud 3. Workshop Vorgehensmodell

Mehr

Seminar Messbarkeit von Anforderungen. Betreuer: Eric Knauss. Gennadi Mirmov

Seminar Messbarkeit von Anforderungen. Betreuer: Eric Knauss. Gennadi Mirmov Just Enough Requirements Seminar Messbarkeit von Anforderungen am Fachgebiet Software Engineering Wintersemester 2007/2008 Betreuer: Eric Knauss 31.10.0710 07 Gennadi Mirmov Gliederung Einleitung Anforderungen

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

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

Projektrisikomanagement im Corporate Risk Management

Projektrisikomanagement im Corporate Risk Management VERTRAULICH Projektrisikomanagement im Corporate Risk Management Stefan Friesenecker 24. März 2009 Inhaltsverzeichnis Risikokategorien Projekt-Klassifizierung Gestaltungsdimensionen des Projektrisikomanagementes

Mehr

H. Enke, Sprecher des AK Forschungsdaten der WGL

H. Enke, Sprecher des AK Forschungsdaten der WGL https://escience.aip.de/ak-forschungsdaten H. Enke, Sprecher des AK Forschungsdaten der WGL 20.01.2015 / Forschungsdaten - DataCite Workshop 1 AK Forschungsdaten der WGL 2009 gegründet - Arbeit für die

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

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

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

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

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

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

Mehr

Frontend Migration from JSP to Eclipse Scout

Frontend Migration from JSP to Eclipse Scout Frontend Migration from JSP to Eclipse Scout Peter Nüdling Raiffeisen Schweiz Jérémie Bresson, Peter Barthazy BSI Business Systems Integration AG Eclipse Finance Day, Zürich, 31. Oktober 2014 Seite 1 WebKat:

Mehr

SARA 1. Project Meeting

SARA 1. Project Meeting SARA 1. Project Meeting Energy Concepts, BMS and Monitoring Integration of Simulation Assisted Control Systems for Innovative Energy Devices Prof. Dr. Ursula Eicker Dr. Jürgen Schumacher Dirk Pietruschka,

Mehr

Distributed testing. Demo Video

Distributed testing. Demo Video distributed testing Das intunify Team An der Entwicklung der Testsystem-Software arbeiten wir als Team von Software-Spezialisten und Designern der soft2tec GmbH in Kooperation mit der Universität Osnabrück.

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

Introducing PAThWay. Structured and methodical performance engineering. Isaías A. Comprés Ureña Ventsislav Petkov Michael Firbach Michael Gerndt

Introducing PAThWay. Structured and methodical performance engineering. Isaías A. Comprés Ureña Ventsislav Petkov Michael Firbach Michael Gerndt Introducing PAThWay Structured and methodical performance engineering Isaías A. Comprés Ureña Ventsislav Petkov Michael Firbach Michael Gerndt Technical University of Munich Overview Tuning Challenges

Mehr

Group and Session Management for Collaborative Applications

Group and Session Management for Collaborative Applications Diss. ETH No. 12075 Group and Session Management for Collaborative Applications A dissertation submitted to the SWISS FEDERAL INSTITUTE OF TECHNOLOGY ZÜRICH for the degree of Doctor of Technical Seiences

Mehr

Aufbau eines IT-Servicekataloges am Fallbeispiel einer Schweizer Bank

Aufbau eines IT-Servicekataloges am Fallbeispiel einer Schweizer Bank SwissICT 2011 am Fallbeispiel einer Schweizer Bank Fritz Kleiner, fritz.kleiner@futureways.ch future ways Agenda Begriffsklärung Funktionen und Aspekte eines IT-Servicekataloges Fallbeispiel eines IT-Servicekataloges

Mehr

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

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

Mehr

Erfahrungsbreicht... Von der Auswahl bis zur Verwendung von Contour im Grossunternehmen.

Erfahrungsbreicht... Von der Auswahl bis zur Verwendung von Contour im Grossunternehmen. Stefan Topp Honeywell International SARL 16. Februar 2012 Erfahrungsbreicht... Von der Auswahl bis zur Verwendung von Contour im Grossunternehmen. 1 Agenda Hintergruende Der Auswahlprozess Ausrollen von

Mehr

Management von Softwaresystemen Systembewertung: Metriken und Prozess

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

Mehr

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

O N E SOLUTION. VIS//ON Overview Module Datacenter and Cablemanagement. VIS//ON Übersicht Module Datacenter und Kabelmanagement

O N E SOLUTION. VIS//ON Overview Module Datacenter and Cablemanagement. VIS//ON Übersicht Module Datacenter und Kabelmanagement O N E SOLUTION VIS//ON Overview Module Datacenter and Cablemanagement VIS//ON Übersicht Module Datacenter und Kabelmanagement Ü B E R S C H R I F T A R T I K E L I N N E N S E I T E C O M PA N Y OVERV

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

Phasen. Gliederung. Rational Unified Process

Phasen. Gliederung. Rational Unified Process Rational Unified Process Version 4.0 Version 4.1 Version 5.1 Version 5.5 Version 2000 Version 2001 1996 1997 1998 1999 2000 2001 Rational Approach Objectory Process OMT Booch SQA Test Process Requirements

Mehr

Gliederung. Einführung Phasen Ten Essentials Werkzeugunterstützung Aktivitäten, Rollen, Artefakte Werkzeug zur patternorientierten Softwareentwicklung

Gliederung. Einführung Phasen Ten Essentials Werkzeugunterstützung Aktivitäten, Rollen, Artefakte Werkzeug zur patternorientierten Softwareentwicklung Peter Forbrig RUP 1 Gliederung Einführung Phasen Ten Essentials Werkzeugunterstützung Aktivitäten, Rollen, Artefakte Werkzeug zur patternorientierten Softwareentwicklung Peter Forbrig RUP 2 Rational Unified

Mehr

Mit Legacy-Systemen in die Zukunft. adviion. in die Zukunft. Dr. Roland Schätzle

Mit Legacy-Systemen in die Zukunft. adviion. in die Zukunft. Dr. Roland Schätzle Mit Legacy-Systemen in die Zukunft Dr. Roland Schätzle Der Weg zur Entscheidung 2 Situation Geschäftliche und softwaretechnische Qualität der aktuellen Lösung? Lohnen sich weitere Investitionen? Migration??

Mehr

Lehrstuhl für Allgemeine BWL Strategisches und Internationales Management Prof. Dr. Mike Geppert Carl-Zeiß-Str. 3 07743 Jena

Lehrstuhl für Allgemeine BWL Strategisches und Internationales Management Prof. Dr. Mike Geppert Carl-Zeiß-Str. 3 07743 Jena Lehrstuhl für Allgemeine BWL Strategisches und Internationales Management Prof. Dr. Mike Geppert Carl-Zeiß-Str. 3 07743 Jena http://www.im.uni-jena.de Contents I. Learning Objectives II. III. IV. Recap

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

ITIL in 60 Minuten. Jörn Clausen. joernc@gmail.com. Captain Barbossa: And thirdly, the code is more what you d call guidelines than actual rules.

ITIL in 60 Minuten. Jörn Clausen. joernc@gmail.com. Captain Barbossa: And thirdly, the code is more what you d call guidelines than actual rules. ITIL in 60 Minuten Jörn Clausen joernc@gmail.com Captain Barbossa: And thirdly, the code is more what you d call guidelines than actual rules. Elizabeth Swann: Hang the code, and hang the rules. They re

Mehr

Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering,

Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering, Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering, Manfred Broy Lehrstuhl für Software & Systems Engineering Technische Universität München Institut für Informatik ISO 26262 Functional

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

Preisliste für The Unscrambler X

Preisliste für The Unscrambler X Preisliste für The Unscrambler X english version Alle Preise verstehen sich netto zuzüglich gesetzlicher Mehrwertsteuer (19%). Irrtümer, Änderungen und Fehler sind vorbehalten. The Unscrambler wird mit

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

Klausur Verteilte Systeme

Klausur Verteilte Systeme Klausur Verteilte Systeme SS 2005 by Prof. Walter Kriha Klausur Verteilte Systeme: SS 2005 by Prof. Walter Kriha Note Bitte ausfüllen (Fill in please): Vorname: Nachname: Matrikelnummer: Studiengang: Table

Mehr

Software-SPS: Software PLC: Vom Industrie-PC fähigen From industrial PCzur to leistungs high-performance Steuerung controller Zur Visualisierung und Bedienung von PCs are used in countless machines and

Mehr

Model-based Development of Hybrid-specific ECU Software for a Hybrid Vehicle with Compressed- Natural-Gas Engine

Model-based Development of Hybrid-specific ECU Software for a Hybrid Vehicle with Compressed- Natural-Gas Engine Model-based Development of Hybrid-specific ECU Software for a Hybrid Vehicle with Compressed- Natural-Gas Engine 5. Braunschweiger Symposium 20./21. Februar 2008 Dipl.-Ing. T. Mauk Dr. phil. nat. D. Kraft

Mehr

Granite Gerhard Pirkl

Granite Gerhard Pirkl Granite Gerhard Pirkl 2013 Riverbed Technology. All rights reserved. Riverbed and any Riverbed product or service name or logo used herein are trademarks of Riverbed Technology. All other trademarks used

Mehr

Dr. Nicholas Merriam Rapita Systems Ltd., IT Centre, York Science Park, Heslington, York, YO10 5DG (UK) nick.merriam@rapitasystems.

Dr. Nicholas Merriam Rapita Systems Ltd., IT Centre, York Science Park, Heslington, York, YO10 5DG (UK) nick.merriam@rapitasystems. Das zeitliche Verhalten von Echtzeitsoftware zu analysieren und sicher zu stellen, dass die Anforderungen an das Echtzeitverhalten erfüllt werden kann sehr aufwendig und teuer sein. In diesem Artikel sollen

Mehr

Einkommensaufbau mit FFI:

Einkommensaufbau mit FFI: For English Explanation, go to page 4. Einkommensaufbau mit FFI: 1) Binäre Cycle: Eine Position ist wie ein Business-Center. Ihr Business-Center hat zwei Teams. Jedes mal, wenn eines der Teams 300 Punkte

Mehr

Challenges and solutions for field device integration in design and maintenance tools

Challenges and solutions for field device integration in design and maintenance tools Integrated Engineering Workshop 1 Challenges and solutions for field device integration in design and maintenance tools Christian Kleindienst, Productmanager Processinstrumentation, Siemens Karlsruhe Wartungstools

Mehr

CHAMPIONS Communication and Dissemination

CHAMPIONS Communication and Dissemination CHAMPIONS Communication and Dissemination Europa Programm Center Im Freistaat Thüringen In Trägerschaft des TIAW e. V. 1 CENTRAL EUROPE PROGRAMME CENTRAL EUROPE PROGRAMME -ist als größtes Aufbauprogramm

Mehr

Herkömmliche Softwareentwicklungsmodelle vs. Agile Methoden

Herkömmliche Softwareentwicklungsmodelle vs. Agile Methoden vs. Agile Methoden Christoph.Kluck@Student.Reutlingen University.de Medien und Kommunikationsinformatik Agenda Einführung Vorgehensmodelle Herkömmlich agil Resümee Klassische Probleme Nachgereichte Anforderungen

Mehr

MSDN Webcast: Team Foundation Server Mehr als nur eine Versionsverwaltung! Visual Studio Team System (Teil 1 von 10) Veröffentlicht: 20.

MSDN Webcast: Team Foundation Server Mehr als nur eine Versionsverwaltung! Visual Studio Team System (Teil 1 von 10) Veröffentlicht: 20. MSDN Webcast: Team Foundation Server Mehr als nur eine Versionsverwaltung! Visual Studio Team System (Teil 1 von 10) Veröffentlicht: 20. Februar 2008 Presenter: Neno Loje, MVP für Team System www.teamsystempro.de

Mehr

elearning-module Project planning Bestell.Nr.: 1331703 Kurzbeschreibung Inhaltsverzeichnis des Moduls Project planning

elearning-module Project planning Bestell.Nr.: 1331703 Kurzbeschreibung Inhaltsverzeichnis des Moduls Project planning Bestell.Nr.: 1331703 Kurzbeschreibung Inhaltsverzeichnis des Moduls 1. 2. Work process of projects 3. Exercise: Work process of projects 4. Tasks of the project planning 5. Exercise: Tasks of the project

Mehr

Optimizing Request for Quotation Processes at the Volkswagen Pre-Series Center

Optimizing Request for Quotation Processes at the Volkswagen Pre-Series Center Optimizing Request for Quotation Processes at the Volkswagen Pre-Series Center 28 April 2010 / Agenda 1 Pre-series center 2 Project target 3 Process description 4 Realization 5 Review 6 Forecast 28. April

Mehr

Ingest von Fachverfahren. Werkzeuge des Landesarchivs Baden-Württemberg

Ingest von Fachverfahren. Werkzeuge des Landesarchivs Baden-Württemberg Ingest von Fachverfahren. Werkzeuge des Landesarchivs Baden-Württemberg 13. Tagung des AK Archivierung von Unterlagen aus digitalen Systemen 27.4.2009, St. Gallen Dr. Christian Keitel und Rolf Lang Übersicht

Mehr

Vorgehensweise zur Auswahl eines ERP-Systems

Vorgehensweise zur Auswahl eines ERP-Systems Vorgehensweise zur Auswahl eines ERP-Systems Inhalt Was ist ein ERP-System? Recherche ERP-Systemanbieter Erstellung Kriterienkatalog For Example: Criteria required for ERP system Durchführung der ersten

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

A central repository for gridded data in the MeteoSwiss Data Warehouse

A central repository for gridded data in the MeteoSwiss Data Warehouse A central repository for gridded data in the MeteoSwiss Data Warehouse, Zürich M2: Data Rescue management, quality and homogenization September 16th, 2010 Data Coordination, MeteoSwiss 1 Agenda Short introduction

Mehr

Stop Making Sense. Über Sinn und Unsinn von Schätzungen

Stop Making Sense. Über Sinn und Unsinn von Schätzungen Stop Making Sense Über Sinn und Unsinn von Schätzungen Agenda Agenda Was sind Schätzungen? Agenda Was sind Schätzungen? Geht es auch einfacher? Agenda Was sind Schätzungen? Geht es auch einfacher? Wie

Mehr

Methoden und Werkzeuge des Konfigurationsmanagements

Methoden und Werkzeuge des Konfigurationsmanagements Methoden und Werkzeuge des Konfigurationsmanagements Zunächst ein paar Fragen:! Was ist euer Bild des Konfigurationsmanagements?! Welche Aufgaben hat eurer Meinung nach das Konfigurationsmanagement?! Wer

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

Exkursion zu Capgemini Application Services Custom Solution Development. Ankündigung für Februar 2013 Niederlassung Stuttgart

Exkursion zu Capgemini Application Services Custom Solution Development. Ankündigung für Februar 2013 Niederlassung Stuttgart Exkursion zu Capgemini Application Services Custom Solution Development Ankündigung für Februar 2013 Niederlassung Stuttgart Ein Nachmittag bei Capgemini in Stuttgart Fachvorträge und Diskussionen rund

Mehr

Exercise (Part XI) Anastasia Mochalova, Lehrstuhl für ABWL und Wirtschaftsinformatik, Kath. Universität Eichstätt-Ingolstadt 1

Exercise (Part XI) Anastasia Mochalova, Lehrstuhl für ABWL und Wirtschaftsinformatik, Kath. Universität Eichstätt-Ingolstadt 1 Exercise (Part XI) Notes: The exercise is based on Microsoft Dynamics CRM Online. For all screenshots: Copyright Microsoft Corporation. The sign ## is you personal number to be used in all exercises. All

Mehr

ZK2000SF ACCESS CONTROL ZUTRITTSKONTROLLE

ZK2000SF ACCESS CONTROL ZUTRITTSKONTROLLE ZUTRITTSKONTROLLE ACCESS CONTROL SMPX.xx SMPX.xG ZK2000SF Kommunikation über ISDN oder TCP/IP Intelligenter ler Individuelle Rechteverwaltung Verwaltung von 150.000 Personen Communication via ISDN or TCP/IP

Mehr

Algorithms for graph visualization

Algorithms for graph visualization Algorithms for graph visualization Project - Orthogonal Grid Layout with Small Area W INTER SEMESTER 2013/2014 Martin No llenburg KIT Universita t des Landes Baden-Wu rttemberg und nationales Forschungszentrum

Mehr

HARTNAGEL Etikettiermaschinen für Verpackungsbecher und Automation. Etikettierautomat - EMR 8-200 / EMR 8-400

HARTNAGEL Etikettiermaschinen für Verpackungsbecher und Automation. Etikettierautomat - EMR 8-200 / EMR 8-400 Etikettierautomat - EMR 8-200 / EMR 8-400 Die Firma Hartnagel, begann vor über 15 Jahren den ersten Etikettierautomaten zu entwickeln und zu bauen. Geleitet von der Idee, das hinsichtlich der Produktführung

Mehr

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 3. Vorgehensmodelle Software Engineering Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 Agenda Agenda Übersicht V-Modell Rational Unified Process Extreme Programming Fazit, Literatur, Kontrollfragen

Mehr

Safer Software Formale Methoden für ISO26262

Safer Software Formale Methoden für ISO26262 Safer Software Formale Methoden für ISO26262 Dr. Stefan Gulan COC Systems Engineering Functional Safety Entwicklung Was Wie Wie genau Anforderungen Design Produkt Seite 3 Entwicklung nach ISO26262 Funktionale

Mehr

REConf Schweiz 2010 Christoph Wolf, Manager Business Consulting and Analysis. Business Consulting & Analysis @ Sunrise

REConf Schweiz 2010 Christoph Wolf, Manager Business Consulting and Analysis. Business Consulting & Analysis @ Sunrise REConf Schweiz 2010 Christoph Wolf, Manager Business Consulting and Analysis Business Consulting & Analysis @ Sunrise Agenda 1. Sunrise 2. Ausgangslage Business Analysis Planning and Monitoring 3. Team

Mehr

Einflussfaktoren und Standards für den Weg zum Champion

Einflussfaktoren und Standards für den Weg zum Champion Einflussfaktoren und Standards für den Weg zum Champion 1 Herbert G. Gonder, PMP Bosshard & Partner Unternehmensberatung AG, Keynote Anlass, 10. April 2013 Agenda Ausgangslage Einflussfaktoren für den

Mehr

DIGICOMP OPEN TUESDAY AKTUELLE STANDARDS UND TRENDS IN DER AGILEN SOFTWARE ENTWICKLUNG. Michael Palotas 7. April 2015 1 GRIDFUSION

DIGICOMP OPEN TUESDAY AKTUELLE STANDARDS UND TRENDS IN DER AGILEN SOFTWARE ENTWICKLUNG. Michael Palotas 7. April 2015 1 GRIDFUSION DIGICOMP OPEN TUESDAY AKTUELLE STANDARDS UND TRENDS IN DER AGILEN SOFTWARE ENTWICKLUNG Michael Palotas 7. April 2015 1 GRIDFUSION IHR REFERENT Gridfusion Software Solutions Kontakt: Michael Palotas Gerbiweg

Mehr

Scriptbasierte Testautomatisierung. für Web-Anwendungen

Scriptbasierte Testautomatisierung. für Web-Anwendungen Scriptbasierte Testautomatisierung für Web-Anwendungen Scriptbasierte Testautomatisierung + Web-Anwendung: Erstes Einsatzgebiet, Ergebnisse aber allgemein übertragbar + Test aus Benutzersicht - Nicht Unit-Test,

Mehr

Toolunterstützte Validierung der Anforderungsabdeckung

Toolunterstützte Validierung der Anforderungsabdeckung Wir nehmen Kurs auf Ihren Erfolg Toolunterstützte Validierung der Anforderungsabdeckung Businessanalyse toolunterstützt DI Mag. Martin Lachkovics 1040 Wien, Operngasse 17-21 Agenda Die heikle Aufgabe der

Mehr

Privacy-preserving Ubiquitous Social Mining via Modular and Compositional Virtual Sensors

Privacy-preserving Ubiquitous Social Mining via Modular and Compositional Virtual Sensors Privacy-preserving Ubiquitous Social Mining via Modular and Compositional s Evangelos Pournaras, Iza Moise, Dirk Helbing (Anpassung im Folienmaster: Menü «Ansicht» à «Folienmaster») ((Vorname Nachname))

Mehr

infrastructure definitions example versioning

infrastructure definitions example versioning infrastructure definitions example versioning ATLAS9000 GmbH Landauer Str. - 1 D-68766 Hockenheim +49(0)6205 / 202730 Infrastructure documents Storage ATLAS PLM Archives Drawing Circuit Diagram Work Plan

Mehr

DATA ANALYSIS AND REPRESENTATION FOR SOFTWARE SYSTEMS

DATA ANALYSIS AND REPRESENTATION FOR SOFTWARE SYSTEMS DATA ANALYSIS AND REPRESENTATION FOR SOFTWARE SYSTEMS Master Seminar Empirical Software Engineering Anuradha Ganapathi Rathnachalam Institut für Informatik Software & Systems Engineering Agenda Introduction

Mehr

Product Lifecycle Manager

Product Lifecycle Manager Product Lifecycle Manager ATLAS9000 GmbH Landauer Str. - 1 D-68766 Hockenheim +49(0)6205 / 202730 Product Lifecycle Management ATLAS PLM is powerful, economical and based on standard technologies. Directory

Mehr

Systemen - Testen im Softwarelebenszyklus

Systemen - Testen im Softwarelebenszyklus P r a k t I s c h e Entwicklung und Test Testen von Software-Systemen Systemen - Testen im Softwarelebenszyklus Entwickler erstellen ihr System bzw. ihre Software und testen es/sie zur Entwicklungszeit

Mehr

Software development with continuous integration

Software development with continuous integration Software development with continuous integration (FESG/MPIfR) ettl@fs.wettzell.de (FESG) neidhardt@fs.wettzell.de 1 A critical view on scientific software Tendency to become complex and unstructured Highly

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

Challenges in Systems Engineering and a Pragmatic Solution Approach

Challenges in Systems Engineering and a Pragmatic Solution Approach Pure Passion. Systems Engineering and a Pragmatic Solution Approach HELVETING Dr. Thomas Stöckli Director Business Unit Systems Engineering Dr. Daniel Hösli Member of the Executive Board 1 Agenda Different

Mehr

SOFTWARE ENGINEERING

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

Mehr

AnyWeb AG 2008 www.anyweb.ch

AnyWeb AG 2008 www.anyweb.ch Agenda - BTO IT heute Was nützt IT dem Business? Die Lösung: HP Software BTO Q&A IT heute Kommunikation zum Business funktioniert schlecht IT denkt und arbeitet in Silos und ist auch so organisiert Kaum

Mehr

Assetwise. Asset Lifecycle Information Management. Ulrich Siegelin. 2010 Bentley Systems, Incorporated

Assetwise. Asset Lifecycle Information Management. Ulrich Siegelin. 2010 Bentley Systems, Incorporated Assetwise Asset Lifecycle Information Ulrich Siegelin Agenda Was bedeutet Asset Lifecycle Information? AssetWise Technischer Überblick Positionierung von Bentley s AssetWise Einsatz und Arbeitsweise von

Mehr

Embedded Linux. Embedded Linux. Daniel Buchheim daniel.buchheim@informatik.tu-cottbus.de. Seminar "Eingebettete drahtlose Systeme"

Embedded Linux. Embedded Linux. Daniel Buchheim daniel.buchheim@informatik.tu-cottbus.de. Seminar Eingebettete drahtlose Systeme Daniel Buchheim daniel.buchheim@informatik.tu-cottbus.de Embedded Linux 30.01.2009 Daniel Buchheim Inhalt: Was ist Embedded Linux? Hardwareunterstützung in Eingebetteten Systemen Open Source Aspekte Aufbau

Mehr

ITIL & TOGAF die Doppelspitze für IT Governance

ITIL & TOGAF die Doppelspitze für IT Governance 1 ITIL Day 2014 ITIL & TOGAF die Doppelspitze für IT Governance Referenten: Arif Chughtai, Matthias Gessenay 2 Referenten Arif Chughtai mail@arifchughtai.org www.arifchughtai.org Matthias Gessenay matthias.gessenay@corporatesoftware.ch

Mehr

SPiCE und Test: Was hat das denn miteinander zu tun?

SPiCE und Test: Was hat das denn miteinander zu tun? SPiCE und Test: Was hat das denn miteinander zu tun? TAV Düsseldorf 15./16.2.2007 Arbeitskreis Test eingebetteter Systeme Dr. Uwe Hehn Uwe.Hehn@methodpark.de Gliederung Reifegradmodelle Übersicht über

Mehr

arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek

arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek Speaker Andreas Holubek VP Engineering andreas.holubek@arlanis.com arlanis Software AG, D-14467 Potsdam 2009, arlanis

Mehr