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

Entwicklungsmethoden

Entwicklungsmethoden Slide 7.1 Entwicklungsmethoden Prof. Dr. Josef M. Joller jjoller@hsr.ch Development Methodologies Prof. Dr. Josef M. Joller 1 Session 7 Slide 7.2 PLANEN UND SCHÄTZEN Development Methodologies Prof. Dr.

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

Ihr Kunde ist es gewohnt zu warten? Mist Schon wieder zu spät! Aufwandsabschätzung von Projekten. Aufwandsabschätzung von Projekten

Ihr Kunde ist es gewohnt zu warten? Mist Schon wieder zu spät! Aufwandsabschätzung von Projekten. Aufwandsabschätzung von Projekten Mist Schon wieder zu spät! Aufwandsabschätzung von Projekten Frank Listing f.listing@microconsult.com 15.10.2015 1 Aufwandsabschätzung von Projekten Ihr Kunde ist es gewohnt zu warten? 15.10.2015 F 2 1

Mehr

Einführung in Generatives Programmieren. Bastian Molkenthin

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

Mehr

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

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

Mehr

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

Darstellung und Anwendung der Assessmentergebnisse

Darstellung und Anwendung der Assessmentergebnisse 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

SPI-Seminar : Interview mit einem Softwaremanager

SPI-Seminar : Interview mit einem Softwaremanager Erstellung eines Fragenkatalogs der die Beurteilung der Level 2 Key Process Areas in einem ca. einstündigen Interview mit einem Software Manager ermöglicht Vortrag von Matthias Weng 1 Aufbau Geschichte

Mehr

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

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

Mehr

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

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

ISO 15504 Reference Model

ISO 15504 Reference Model Process flow Remarks Role Documents, data, tools input, output Start Define purpose and scope Define process overview Define process details Define roles no Define metrics Pre-review Review yes Release

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

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

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

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 SPICE Erste Eindrücke

ISO SPICE Erste Eindrücke ISO 15504 SPICE Erste Eindrücke Klaus Franz Muth Partners GmbH, Wiesbaden 06122 5981-0 www.muthpartners.de klaus.franz@muthpartners.de SPiCE ISO 15504 1 Stand der Dinge 29. Januar 2005 ISO/IEC 15504 PUBLICATION

Mehr

2014 PRINCE 2 Foundation PRINCE 2 Practitioner

2014 PRINCE 2 Foundation PRINCE 2 Practitioner Personalprofil Thomas Scherzinger Senior Consultant E-Mail: thomas.scherzinger@arcondis.com AUSBILDUNG BERUFLICHE WEITERBILDUNG BESONDERE TÄTIGKEITEN 2010 Bachelor of Sciences in Wirtschaftsinformatik

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

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

Lohnt sich Requirements Engineering?

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

Mehr

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

Software Engineering

Software Engineering Software Engineering Prof. Adrian A. Müller, PMP Fachbereich Informatik und Mikrosystemtechnik Fachhochschule Kaiserslautern, Standort Zweibrücken Prof. A. Müller, FH KL Software Engineering Winter '12/'13

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

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

Umfrage zum Informationsbedarf im Requirements Engineering

Umfrage zum Informationsbedarf im Requirements Engineering Umfrage zum Informationsbedarf im Requirements Engineering Vielen Dank für Ihre Teilnahme an dieser Studie! Im Rahmen eines Forschungsprojektes an der Universität Hamburg und der TU Graz führen wir eine

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

Test Plan. Test Plan. Version <1.0> 1.Introduction. 2.Evaluation Mission and Test Motivation

<JASK Gaming> <!Everybodys Perfect> <Iteration/ Master> Test Plan. Test Plan. Version <1.0> 1.Introduction. 2.Evaluation Mission and Test Motivation Test Plan Version Test Plan 1.Introduction 1.1.Purpose The purpose of the Iteration Test Plan is to gather all of the information necessary to plan and control

Mehr

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

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

Mehr

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

Some Software Engineering Principles

Some Software Engineering Principles David L. Parnas: Some Software Engineering Principles Marco Oppel 30.06.2004 Seminar Software-Architektur Institut für Informatik Humboldt Universität zu Berlin 1 Problemstellung Software Engineering Multi-Personen

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

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

Comparing Software Factories and Software Product Lines

Comparing Software Factories and Software Product Lines Comparing Software Factories and Software Product Lines Martin Kleine kleine.martin@gmx.de Betreuer: Andreas Wuebbeke Agenda Motivation Zentrale Konzepte Software Produktlinien Software Factories Vergleich

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

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

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

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

Grundlagen Software Engineering

Grundlagen Software Engineering Grundlagen Software Engineering Rational Unified Process () GSE: Prof. Dr. Liggesmeyer, 1 Rational Unified Process () Software Entwicklungsprozess Anpassbares und erweiterbares Grundgerüst Sprache der

Mehr

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

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

Mehr

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

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

CMM Mythos und Realität. Forum Forschungsförderung BITKOM / ViSEK 2003 17. Oktober 2003. Tilman Seifert, TU München

CMM Mythos und Realität. Forum Forschungsförderung BITKOM / ViSEK 2003 17. Oktober 2003. Tilman Seifert, TU München CMM Mythos und Realität Forum Forschungsförderung BITKOM / ViSEK 2003 17. Oktober 2003, TU München Agenda Das CMM Ziele und Aufbau Prozessverbesserung nach CMM Bewertung des CMM Mythen Thesen Kritik Zusammenfassung

Mehr

Software Engineering (Softwaretechnik) --- Entwicklung von (Anwender-)Software

Software Engineering (Softwaretechnik) --- Entwicklung von (Anwender-)Software Software Engineering (Softwaretechnik) --- Entwicklung von (Anwender-)Software Software als dominierender Faktor IT Branche ist weltweit ein führender

Mehr

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

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

Mehr

Vorlesung Software-Reengineering

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

Mehr

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

Scrum technische Umsetzung und kaufmännische Rahmenbedingungen

Scrum technische Umsetzung und kaufmännische Rahmenbedingungen Scrum technische Umsetzung und kaufmännische 9. Darmstädter Informationsrechtstag 2013 Darmstadt, 15. November 2013 Franziska Bierer 2 andrena ojects ag Gründung 1995 Standorte in Karlsruhe und Frankfurt

Mehr

Vorlesung Software-Reengineering

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

Mehr

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

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

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

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

Projektmanagement. Vorlesung von Thomas Patzelt 8. Vorlesung

Projektmanagement. Vorlesung von Thomas Patzelt 8. Vorlesung Projektmanagement Vorlesung von Thomas Patzelt 8. Vorlesung 1 Möglicher Zeitplan, Variante 3 26.03. Vorlesung 1, Übung Gr.2 28.05. Keine Vorlesung, Pfingstmontag 02.04. Keine Vorlesung, Hochschultag 04.06.

Mehr

Vielfalt als Zukunft Instandhaltung

Vielfalt als Zukunft Instandhaltung 10.02.2016, 13.00 13.30 CET Dr. Franziska Hasselmann Studienleitung CAS Managing Infrastructure Assets Maintenance Schweiz 2016 Vielfalt als Zukunft Instandhaltung Einladungstext zum Vortrag... Täglich

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

CeBIT 17.03.2015. CARMAO GmbH 2014 1

CeBIT 17.03.2015. CARMAO GmbH 2014 1 CeBIT 17.03.2015 CARMAO GmbH 2014 1 HERZLICH WILLKOMMEN Applikationssicherheit beginnt lange bevor auch nur eine Zeile Code geschrieben wurde Ulrich Heun Geschäftsführender Gesellschafter der CARMAO GmbH

Mehr

Integration mit Service Repositories zur SOA Governance

Integration mit Service Repositories zur SOA Governance Integration mit Service Repositories zur SOA Governance Nürnberg, 10.11.2009 I N H A L T 1. SOA Governance 2. Service Repository 3. Modelle und Service Repository 4. Modell-Driven SOA I N H A L T 1. SOA

Mehr

Agile Software Entwicklung. Agile Software Entwicklung, DHBW Karlsruhe, SS-2009 Collin Rogowski

Agile Software Entwicklung. Agile Software Entwicklung, DHBW Karlsruhe, SS-2009 Collin Rogowski Agile Software Entwicklung Agile Software Entwicklung, DHBW Karlsruhe, SS-2009 Collin Rogowski Agenda zum Kurs Software Engineering Wasserfallmodell Agile Entwicklung Wer bin ich Studium der Computerlinguistik

Mehr

Testers Architects Enterprise Dev Consultants Professionals VB6 Devs Part-Timers Hobbyists Students Enthusiasts Novices

Testers Architects Enterprise Dev Consultants Professionals VB6 Devs Part-Timers Hobbyists Students Enthusiasts Novices Visual Studio Team System 15. Mai 2006 TU Dresden Oliver Scheer Developer Evangelist Developer Platform & Strategy Group Microsoft Deutschland GmbH Agenda Einführung in Visual Studio Team System Demo Fragen

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

Dialekte der Klimaforschung

Dialekte der Klimaforschung Dialekte der Klimaforschung Vom Fortran-Programm zum parallelen Programm Thomas Ludwig Inhalt Welche Dialekte werden transformiert? Welche Anforderungen stellen wir? Wozu diese Transformation? Wie ist

Mehr

Kapitel 3: Einführung Projektmanagement

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

Mehr

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

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

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

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

Mehr

Die Kunst des Programmierens...

Die Kunst des Programmierens... Die Kunst des Programmierens... Wo die Kosten anfallen Der Mythos Wiederverwendung: Design für Wartung als eigentliches Ziel, Objekt Spektrum 4/2009 software maintainers sped 45 percent of their time seeking

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

Software Engineering

Software Engineering Literatur Gliederung Software Engineering Herbert Kuchen Universität Münster Di+Fr 14:15-15:45, M2 Wintersemester 2009/2010 1 Literatur Gliederung Basis-Literatur H. Balzert: Lehrbuch der Software-Technik,

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

Präsentation einer agilen Methode

Präsentation einer agilen Methode Präsentation einer agilen Methode Adaptive Software Development Rainer Ulrich Überblick 1. Entstehung 2. Einordnung 3. Manifesto for Agile Software Development 4. Ansatz 5. Adaptive Conceptual Model 5.1.

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

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

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

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

Was versteht man unter Softwarequalität?

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

Mehr

Kapitel 8: Fehlervermeidung

Kapitel 8: Fehlervermeidung Kapitel 8: Fehlervermeidung Inhalt 8.1 Prozesse mit kontinuierlicher Prüfung 8.2 Systematisches Entwerfen und Programmieren 8.3 Dokumentier- und Codierrichtlinien Schlüsselbegriffe Cleanroom, Fehlervermeidung,

Mehr

Projektmanagement Projektablauf

Projektmanagement Projektablauf Projektmanagement Projektablauf Inhalt Was ist ein Projekt? Projektphasen Projektablauf Wichtige Begriffe Zusammenfassung 2 Warum Projektmanagement? Von der Seminararbeit......bis zum Urlaub...alles eine

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

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

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

COBIT. Proseminar IT Kennzahlen und Softwaremetriken 19.07.2010 Erik Muttersbach

COBIT. Proseminar IT Kennzahlen und Softwaremetriken 19.07.2010 Erik Muttersbach COBIT Proseminar IT Kennzahlen und Softwaremetriken 19.07.2010 Erik Muttersbach Gliederung Motivation Komponenten des Frameworks Control Objectives Goals Prozesse Messen in CobiT Maturity Models Outcome

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

Software Echtzeitverhalten in den Griff Bekommen

Software Echtzeitverhalten in den Griff Bekommen Software Echtzeitverhalten in den Griff Bekommen B.Sc.Markus Barenhoff [www.embedded-tools.de] Dr. Nicholas Merriam [www.rapitasystems.com] Übersicht Reaktionszeit Nettolaufzeit Optimierung Worst-Case

Mehr

Agile Entwicklung nach Scrum

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

Mehr

Infrastructure as a Service (IaaS) Solutions for Online Game Service Provision

Infrastructure as a Service (IaaS) Solutions for Online Game Service Provision Infrastructure as a Service (IaaS) Solutions for Online Game Service Provision Zielsetzung: System Verwendung von Cloud-Systemen für das Hosting von online Spielen (IaaS) Reservieren/Buchen von Resources

Mehr

Software Configuration Management: Referat-Titel Der lange Weg von Geschäftsanforderungen zur Software-Lösung

Software Configuration Management: Referat-Titel Der lange Weg von Geschäftsanforderungen zur Software-Lösung Workshop-Titel Software Configuration Management: Referat-Titel Der lange Weg von Geschäftsanforderungen zur Software-Lösung Prof. Dr. Reinhard Jung 2. Prozessfux IT Service Management Tagung Zürich, 21.

Mehr

Datenübernahme easyjob 3.0 zu easyjob 4.0

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

Mehr

Einführung von Test-Prozessen laut TMMi. Egon Valentini 1. März 2010

Einführung von Test-Prozessen laut TMMi. Egon Valentini 1. März 2010 Einführung von Test-Prozessen laut TMMi Egon Valentini 1. März 2010 Agenda NXP Testumfeld CMMi, TMMi TMMi QualityPolicy, TestPolicy, TestStrategy, TestPlan Lessons Learned 2 Warum brauchen wir Testmethoden

Mehr

Business Process Improvement. Schrittweise Optimierung von Geschäftsprozessen Alfred Bertschinger

Business Process Improvement. Schrittweise Optimierung von Geschäftsprozessen Alfred Bertschinger Business Process Improvement Schrittweise Optimierung von Geschäftsprozessen Alfred Bertschinger Situation Die Informatik unterstützt eine Vielzahl von Geschäftsprozessen Die bestehenden Technologien sind

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

Die Softwareentwicklungsphasen!

Die Softwareentwicklungsphasen! Softwareentwicklung Die Softwareentwicklungsphasen! Die Bezeichnungen der Phasen sind keine speziellen Begriffe der Informatik, sondern den allgemeinen Prinzipien zur Produktion integrierter Systeme entliehen.

Mehr

HP Service Manager 7 mit ITSM Implementation Accelerator (IIA) ITIL V3 out of the box?

HP Service Manager 7 mit ITSM Implementation Accelerator (IIA) ITIL V3 out of the box? HP Service Manager 7 mit ITSM Implementation Accelerator (IIA) ITIL V3 out of the box? 04. November 2008 ITC GmbH 2008 Agenda Was bringt der HP Service Manager 7? Überblick SM7 Module Neue / zusätzliche

Mehr

1. Grundbegriffe des Software-Engineering

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

Mehr

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

ITILin60Minuten. Jörn Clausen joernc@gmail.com. Captain Barbossa: And thirdly, the code is more what you d call guidelines than actual rules. ITILin60Minuten 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 more

Mehr

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

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

Mehr

Abschnitt 16: Objektorientiertes Design

Abschnitt 16: Objektorientiertes Design Abschnitt 16: Objektorientiertes Design 16. Objektorientiertes Design 16 Objektorientiertes Design Informatik 2 (SS 07) 610 Software-Entwicklung Zur Software-Entwicklung existiert eine Vielfalt von Vorgehensweisen

Mehr

I-Q SCHACHT & KOLLEGEN QUALITÄTSKONSTRUKTION GMBH ISO 26262:2011. Tabellen mit ASIL Zuordnungen

I-Q SCHACHT & KOLLEGEN QUALITÄTSKONSTRUKTION GMBH ISO 26262:2011. Tabellen mit ASIL Zuordnungen I-Q SCHACHT & KOLLEGEN QUALITÄTSKONSTRUKTION GMBH ISO 26262:2011 Tabellen mit ASIL Zuordnungen 1. Die Tabellen in der Norm (mit ASIL Zuordnung) Ein wesentlicher Bestandteil der Norm sind die insgesamt

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