Aufwandschätzung von Softwareprojekten

Größe: px
Ab Seite anzeigen:

Download "Aufwandschätzung von Softwareprojekten"

Transkript

1 Aufwandschätzung von Softwareprojekten Einsatz und Nutzen der Function-Point-Methode Manfred Bundschuh Dieser Aufsatz beschäftigt sich sowohl mit den Problemen als auch mit den Möglichkeiten, in Softwareprojekten zu guten Schätzergebnissen zu gelangen. Er zeigt Chancen auf, die die professionelle Aufwandschätzung der Projektplanung bietet. Die Function-Point- Methode dokumentiert objektiv und einheitlich die Anwendungssysteme aus Benutzersicht, und zwar konsistent mit dem Verständnis der Anwender (einheitliche Sprache für IT und Fachbereich). Auf dieser Basis können Projektentscheidungen, Investitionen und Verträge abgesichert und eine Lieferantenauswahl durchgeführt werden. Außerdem erhält das Unternehmen dadurch konsistente, projektübergreifende Daten über den Umfang seines Anwendungssystem- und Projektportfolios, die beispielsweise der Bewertung dieser immateriellen Vermögenswerte in der Bilanz zugrunde gelegt werden können. Darüber hinaus liefern Function Points zahlreiche Metriken, u.a. zur Qualitätsplanung und für Management- Reviews, mit denen Stabilität und Zuverlässigkeit sowie Produktivität von IT-Systemen beurteilt werden kann. Durch die internationale Standardisierung sind sogar unternehmensübergreifende Benchmarks möglich. Herausforderungen der Aufwandschätzung Bei der Aufwandschätzung von IT-Projekten ist Deutschland immer noch Entwicklungsgebiet [1]. Die Anzahl der Teilnehmer bei einschlägigen Tagungen in europäischen Nachbarländern (über 100) im Vergleich zu Tagungen der DASMA (Deutschsprachiger Anwenderverband für Softwaremetriken und Aufwandschätzung e.v., oder der GI-Fachgruppe (Software-Messung und -Bewertung, Gesellschaft für Informatik e.v., in Deutschland (ca. 50 Teilnehmer) vermittelte in den letzten Jahren jedenfalls diesen Eindruck. Aber es ist Bewegung im Markt, denn die Anzahl der DASMA-Mitglieder z. B. ist in den letzten Jahren auf inzwischen fast 70 gewachsen. Das heißt, dass zunehmend mehr Firmen ernsthaft am Thema Aufwandschätzung interessiert sind. Oder sie haben schmerzhaft erfahren, was der Guru der Aufwandschätzung, Capers Jones, in die Worte gefasst hat: Ein fehlgeschlagenes Projekt kostet mehr als aller Aufwand, um ein Aufwandschätzverfahren in einem Unternehmen zu etablieren. [7] Für eine fundierte Planung von IT-Projekten und die Messung des Erfolgs nach Projektabschluss ist es notwendig, Schätzungen über Aufwand, Kosten, Termine und Dauer professionell durchzuführen. Das häufig angesprochene Problem fehlender empirischer Daten sowie der erhöhte zeitliche Aufwand können durch den Einsatz von Werkzeugen, durch ausführliche Dokumentation oder durch den Aufbau eines Competence Centers kompensiert werden [2]. Dieser Aufsatz beschäftigt sich daher sowohl mit den Problemen als auch den Möglichkeiten, zu guten Schätzergebnissen zu gelangen, und den Die wichtigsten Themen der Aufwandschätzung Schätzobjekt Zeitpunkte der Aufwandschätzung Schätzgenauigkeit Schätzfehler Aufwand für die Aufwandschätzung Schätzmethoden Tracking der Schätzungen Schätztools Schätzparameter Schätzehrlichkeit Schätzerfahrung Einführung der Aufwandschätzung Schätzkultur Abb. 1: Hauptthemen der Aufwandschätzung Chancen, die die professionelle Aufwandschätzung der Projektplanung bietet. Um es mit Capers Jones [7] klar auszusprechen: Wer diese Software-Entwicklungsaufgabe nicht professionell wahrnimmt, handelt in seinem Beruf grob fahrlässig. In Italien ist deshalb gesetzlich vorgeschrieben, daß Softwareanbieter bei staatlichen Stellen den Leistungsumfang in Function Points angeben müssen. Die Hauptthemen der Aufwandschätzung sind in Abb. 1 zusammengefasst.! 23

2 WISSEN Eingabe (EI) Interner Datenbestand Benutzer Ausgabe (EO) Abfrage (EQ) Anwendungsgrenze Abb. 2: Die Function-Point-Methode EI EO EQ Die Function-Point-Methode als Voraussetzung für solide Aufwandschätzung Die Function-Point-Methode wurde 1979 von A. J. Albrecht bei IBM entwickelt und hat seither weite Verbreitung gefunden.1986 wurde die International Function Point Users Group (IFPUG) zum Zweck einer internationalen Standardisierung dieser Methode gegründet. Die Mitglieder der IFPUG erhalten kostenlos das so genannte IFPUG Counting Practices Manual (CPM), das die standardisierte und vereinheitlichte Version der Function-Point-Methode beschreibt, derzeit Release 4.2 (ISO- Standard ISO/IEC 20926:2003). Die IFPUG Function-Point-Methode ist eine nach der ISO-Norm anerkannte Methode zur Messung der funktionalen Größe bzw. des Umfangs einer Anwendung aus Benutzersicht, d. h., es wird die vom Benutzer geforderte Funktionalität gemessen, die von der Fachabteilung nachgefragt, anhand des logischen Systementwurfs quantifiziert und für sie erbracht wird. Dieses Maß ist unabhängig von der für die Implementierung verwendeten Technologie, da nicht die technische Realisierung der Anwendung betrachtet wird. Grundlage der Aufwandschätzung sind Informationen über das zu schätzende Projekt, z. B.: Übersicht über die benötigten Daten (z. B. Objektkatalog oder relationales Datenmodell), Masken-, Listenlayout etc., Anzahl und Umfang der Schnittstellen, Abläufe aus Benutzersicht, Dialogablauf, z. B. alle Prozessflussmodelle mit den dazugehörigen Aktivitäten, Use Cases, etc. Fehlende Informationen müssen durch dokumentierte Annahmen ersetzt werden, ansonsten gerät das Schätzen zum Raten. Die Bandbreite des Schätzergebnisses hängt dabei von der Sicherheit dieser Annahmen ab. Grundsätzlich gilt: Je mehr Informationen über das Schätzobjekt vorliegen, desto genauer wird die Schätzung. Function Points auf einen Blick Externer Datenbestand Andere Anwendung Abb. 2 zeigt die Komponenten der Function-Point-Methode. Als erstes wird die Grenze der Anwendung in einem Architekturdiagramm festgelegt, damit festgestellt werden kann, welche vom Benutzer geforderten Geschäftsvorfälle Daten über die Grenzen der Anwendung transportieren. Das können Eingaben (EI = External Inputs), Ausgaben (EO = External Outputs) oder Abfragen (EQ = External Inquiries) sein. Dazu werden interne Dateien (ILF = Internal Logical File) und externe Dateien (EIF = External Interface Files) benötigt. Diese fünf Komponenten (EI, EO, EQ, ILF, EIF) werden für alle vom Benutzer geforderten Geschäftsvorfälle jeweils nach den Regeln des IFPUG CPM mit einfach, mittel oder hoch bewertet. Anhand einer im CPM vorgegebenen Tabelle wird dazu die Anzahl der Function Points bestimmt. Die Summe aller Function Points der Anwendung ist der funktionale Umfang. Der interessierte Leser findet in [3, Kapitel 8 bis 12] eine genaue Beschreibung der Function-Point-Methode. Die Function-Point-Methode unterscheidet zwischen den ungewichteten Function Points und den gewichteten Function Points. Zur Berechnung der gewichteten Function Points werden 14 Systemmerkmale jeweils mit 0 bis 5 Punkten eingestuft. Diese 14 Systemmerkmale berücksichtigen Parameter aus der Systementwicklung. Sie sind daher kein funktionales Maß mehr, sondern bereits ein Schritt in Richtung Aufwandschätzung. Da diese Schätzparameter unternehmensspezifisch und projektspezifisch sind, werden für das externe Benchmarking sinnvollerweise nur ungewichtete Function Points verwendet. Die ISO hat deshalb als funktionales Maß für IT-Systeme nur die ungewichteten Function Points anerkannt. Der Schritt vom Messen zum Schätzen Grundsätzlich gilt es, zwischen Zählen und Schätzen zu unterscheiden. Das Ergebnis der Zählung von Funktions- Punkten (Function Points) oder Code-Zeilen (KLOCs: Kilo Lines of Code) ist lediglich ein Ausgangspunkt (der wichtigste Parameter) für die eigentliche Aufwandschätzung. Dabei gilt folgende Prämisse: Was Sie nicht messen können, können Sie auch nicht kontrollieren. [4] Die Schätzerfahrungen vergangener Projekte spielen dabei eine große Rolle, lassen sich jedoch nur nutzen, wenn sie auch ausreichend dokumentiert wurden [2]. Prinzipiell wird bei der Aufwandschätzung, ausgehend vom Umfang der zu entwickelnden Software, unter Berücksichtigung weiterer Parameter der Aufwand berechnet, indem Daten von Umfang und Ist-Aufwand früherer Projekte zueinander in Bezug gesetzt werden. Dazu werden typischerweise mindestens je drei kleine, mittlere und große Projekte nachkalkuliert, so dass im einfachsten Fall aus den Zahlenpaaren Umfang/Aufwand durch eine Regressionsanalyse eine Erfahrungskurve berechnet werden kann. Diese Erfahrungskurven haben die Form y = a xb mit y = Aufwand, x = Umfang und a, b aus der Regressionsanalyse ermittelt: a = Koeffizient, b = Exponent. Weiterentwickelte Verfahren aufgrund von Projektdatenbanken, wie z. B. die ISBSG-Datenbank, COCOMO (Constructive Cost Model, Barry Boehm), SLIM (Software Lifecycle Management, L. H. Putnam) und weitere Schätztools berücksichtigen in ihren Schätzgleichungen noch weitaus mehr bzw. andere Parameter als den Um- 24

3 fang. Teilweise werden diese Einflußgrößen von den Anbietern allerdings als Betriebsgeheimnis gehütet. COCOMO und SLIM z. B. sind im Gegensatz zu Function Points LOC-basierte Schätzmethoden. Lines of Code (LOC) sind gegenüber Function Points (Fachkonzept) erst spät im Projekt bekannt (Realisierungsphase) und messen den technischen Umfang, während Function Points den funktionalen Umfang messen. Backfiring nennt man den Versuch, Formeln für die Umrechung von Functions Points in LOC oder umgekehrt zu entwickeln. Das setzt voraus, dass man beide Größen misst und den Unterschied zwischen technischem und funktionalem Maß vernachlässigt. LOCs haben auch mit dem Paradoxon der Sprachumrechnungsfaktoren zu kämpfen (Assembler-Äquivalent). Danach hat z. B. ein Programm bei einem Ist-Aufwand von angenommen einem Personenmonat (PM) einen Umfang von beispielsweise LOC Cobol und damit eine Produktivität von LOC pro PM. Das gleiche Programm in Assembler entspricht einem Umfang von LOC (Assembler-Äquivalent) und hat damit eine Produktivität von LOC/PM, ist also dreimal so produktiv wie die COBOL-Programmierung, was der praktischen Erfahrung widerspricht. LOC-Methoden sind deshalb bei Metrikspezialisten weltweit sehr umstritten. Umfangmaße nach ISO-Norm Es gibt in der Software-Industrie die international normierten Metriken der ISO (ISO = International Organization for Standardization). ISO ist seit 1999 Standard und beschreibt die grundlegenden Prinzipien einer funktionalen Größenmetrik (Functional Size Metric) und die nötigen Definitionen dazu. ISO beschreibt die Prüfkriterien zur Feststellung, ob eine Methode funktionale Metrik im Sinne von ISO ist. ISO stellt Messkriterien in Form von Checklisten für Assessments zur Verfügung, anhand derer bewertet werden kann, wie gut eine funktionale Größenmetrik ISO erfüllt. Derzeit (Ende 2004) sind nur Varianten der Function-Point-Methode nach ISO anerkannte Public Available Standards (PAS). Dabei handelt es sich um die IFPUG-Function-Point-Methode Version 4.1 (IFPUG = International Function Point User Group, ISO/IEC 20926; die COSMIC Full Function Points (COSMIC = Common Software Measurement Consortium, ISO/IEC 19761; die NESMA-Function-Point-Methode (NESMA = Niederländische Metrik Organisation, ISO/IEC 24570; die Mark-II-Function-Point-Methode (von Charles Symons in England für Entwicklungen mit Programmiersprachen der 4. Generation entwickelt, ISO/IEC COSMIC Full Function Points (FFP) Die IFPUG-Methode ist anerkannt für Zählungen von so genannten Geschäftsanwendungen und MIS-Syste- Anzeige 25

4 WISSEN men (Management-Informationssysteme). Ein wesentlicher Kritikpunkt daran ist jedoch, dass sie nicht für die Messung von Echtzeit-Anwendungen, Anwendungen zur Prozesskontrolle oder auch Betriebssystemen geeignet sein soll, obwohl A. J. Albrecht sie ursprünglich bei einem Projekt zur Entwicklung eines Betriebssystems entwickelt hat. Darüber hinaus war zwar die Technologieunabhängigkeit der Methode begrüßt worden, aber das Fehlen von verschiedenen Sichten (Entwickler, Endbenutzer, ) bemängelt worden. Genau in diese Lücke stößt das Common Software Metrics Consortium (COS- MIC) mit seinen Full Function Points (FFP). Diese COS- MIS FFP Version 2.2 wurden nach zahlreichen Feldversuchen 2003 als ISO-Norm ISO/IEC 19761:2003 standardisiert. Das Handbuch dazu kann aus dem Internet heruntergeladen werden unter Eine genaue Beschreibung der Methode ist in [3, Kapitel 9.3] zu finden. Die COSMIC-FFP-Methode leitet die funktionale Größe aus der Anzahl der zur Durchführung eines Prozesses notwendigen Datenbewegungen ab. Daneben wird ein Schichtenkonzept (Software-Layers) verwendet. Eine Überprüfung von fünf Applikationen mit IFPUG FP und COSMIC FFP ergab kaum Differenzen im MIS-Umfeld, aber 70 % Unterschied bei Realtime-Systemen. In der ISBSG Benchmarking-Datenbank sind bereits mehr als 60 COSMIC-FFP-Projekte enthalten. Durch die Entwicklung mit einem weltweiten Konsortium von Unternehmen unter wissenschaftlicher Begleitung der Universität von Montreal, Canada (Prof. Alan Abran) ist die COSMIC- FFP-Methode die erste Methode zur Umfangmessung, die vor dem Einsatz validiert wurde. Dadurch stand bereits von Anfang an eine Erfahrungsdatenbank zur Verfügung. Die COSMIC-FFP-Methode konnte auf den Erfahrungen der anderen Methoden aufbauen und wird deshalb auch als Methode der zweiten Generation bezeichnet. Praktische Erfahrungen und Synergieeffekte beim Einsatz der Function-Point-Methode Die Function-Point-Methode dokumentiert objektiv und einheitlich die Anwendungssysteme aus Benutzersicht, und zwar konsistent mit dem Verständnis der Anwender über die Funktionalität der Anwendungssysteme (einheitliche Sprache für IT und Fachbereich). Damit kann die Benutzerzufriedenheit mit dem Projekt gesteigert werden. Die Strukturierung aus der Sicht der Endbenutzer zeigt die Elementarprozesse entsprechend den Business Requirements (Geschäftsprozesse) und führt damit zu einem besseren Design und besseren Steuerungsmöglichkeiten im Projektverlauf. Die Informationen sind für Architektur, Spezifikation, Entwicklung, Weiterentwicklung und Wartung sowie die Ableitung von Testfällen, für die Releaseplanung und nach Dokumentation für die Einarbeitung von anderen Mitarbeitern wiederverwendbar. Veränderungen können damit in der Entwicklungsphase in das Fachkonzept eingearbeitet und abgestimmt werden. Somit können Abweichungen erkannt und ggf. neue Zielvereinbarungen getroffen werden. Durch Toolunterstützung können die Geschäftsvorfälle standardisiert einem Projekt zugeordnet, festgehalten, beschrieben, gruppiert, Datenfeldern und Dateien zugeordnet und von Fachbereich und IT gemeinsam bearbeitet werden. Der Entwicklungsstand kann in einzelnen Phasen archiviert sowie eingefroren und als IST-Konzept vereinbart werden. Bei wiederholter Zählung kann der schleichende Funktionszuwachs gemessen werden und damit eine Frühwarnung erfolgen, falls das Projekt aus dem Ruder zu laufen droht. Insgesamt fördert das die gute Zusammenarbeit zwischen IT und Fachbereich, hilft Missverständnisse zu beseitigen, unterstützt das Gelingen der Projekte und führt insgesamt zu einer deutlichen Verbesserung der Qualität und zu Reuse-Möglichkeiten im ganzen Software-Entwicklungsprozess. Die Aufwandschätzung als Voraussetzung für solide Projektplanung Voraussetzung für das Gelingen eines Softwareprojekts ist eine fundierte Planung. Dazu gehört vor allem eine realistische Aufwandschätzung. Aufwandschätzungen liefern Werte zu Aufwand, Terminen, Kosten und Projektdauer, die in die Planungen einfließen und später nachverfolgt werden können. Neben Planung und Controlling wird dadurch auch die Erfolgsmessung sowie das Lernen aus der Vergangenheit zur Schätzung zukünftiger Projekte unterstützt [2]. Die für eine realitätsnahe Planung benötigten Größen Aufwand, Termine, Kosten, Projektdauer und Ressourcen sind neben den sachlichen Projektzielen die wichtigsten Einflussfaktoren auf den Erfolg eines Projekts. Nur durch eine professionell durchgeführte Aufwandschätzung kann der Projektleiter diese Informationen verlässlich erhalten. Nicht vorhandene Dokumentationen und fehlende Erfahrungen sind eines der häufigsten Probleme, auf die Projektleiter stoßen, wenn sie Aufwandschätzungen (oder Projektplanungen) vornehmen müssen. Da hilft nur, sofort damit anzufangen, sonst kann der Teufelskreis nie durchbrochen werden! [2] Kritische Erfolgsfaktoren der Aufwandschätzung Die in Abb. 1 aufgeführten Hauptthemen der Aufwandschätzung sind auch gleichzeitig die kritischen Erfolgsfaktoren. Davon stehen besonders die Schätzgenauigkeit und die Schätzzeitpunkte im Vordergrund, zumindest bei der Einführung von Aufwandschätzmethoden. Außerdem sind frühe Schätzungen und das Managen von Akzeptanzproblemen kritische Variablen des Einführunsprozesses. Schätzgenauigkeit und Schätzzeitpunkte Die, je nach Schätzzeitpunkt (siehe Abb. 3), mehr oder weniger große Unwissenheit über die Schätzparameter hat zur Folge, dass das Ergebnis einer Schätzung nie eine absolute Zahl, sondern immer ein Intervall ist, die Bandbreite dieses Intervalls mit dem zur Verfügung stehenden Wissen über das Schätzobjekt zusammenhängt und die Unsicherheit in dem Maße abnimmt, in dem die Aufwandschätzung nachverfolgt wird [2]. Ein weiteres Problem liegt in einem schleichenden Funktionszuwachs (requirements creep) aufgrund technischer Änderungen. Dieser Funktionszuwachs kann, in 26

5 Studie Die Einführung einer neuen Methode hat üblicherweise mit Akzeptanzproblemen zu kämpfen. Als Lösung bietet sich an, den Königsweg für die Einführung von Innovationen zu beschreiten: umfassende Information, gute Ausbildung und Partizipation aller Beteiligten! Daneben kann man einige akzeptanzfördernde Maßnahmen ergreifen, wie z. B. Vorbereitung von Gegenargumenten gegen Killerphrasen und Befürchtungen, Schätzklausuren, die das gemeinsame Verständnis im Team fördern, Toolunterstützung, die die Überlebenschancen von Methoden erhöht, Messen von Prozessen, nicht Personen, Bewusstsein dafür schaffen, dass Umfangmessung notwendig und nicht Overhead ist, Unterstützung durch das Management. Die Auswirkungen fehlender Akzeptanz sind Wider- Projektvorbereitung Start Projekt Abschluss Analyse Design Realisierung Test Einführung Grobe Schätzung Verbindliche Schätzung (daran wird der Projekterfolg gemessen) Tracking der Schätzung Schätzerfahrungen dokumentieren, Nachkalkulation durchführen Abb. 3: Schätzzeitpunkte Abhängigkeit vom Projektumfang, bei mehr als drei Prozent je Monat Projektlaufzeit liegen. Er lässt sich durch wiederholte Messung des Umfangs während des Projektverlaufs ermitteln und steuern. Die Aufwandschätzung darf deshalb nicht als ein einmaliges Ereignis angesehen werden, sondern ist ein Prozess, der das Projekt während der gesamten Dauer begleitet. Erneutes Schätzen mit zeitlichem Fortschritt oder nach größeren Änderungen eines Projekts ist unerlässlich, um die Schätzgenauigkeit zu erhöhen. Werden Schätzungen zudem mit unterschiedlichen Methoden durchgeführt und evtl. mit Hilfe Dritter validiert, trägt dies weiter zu einer Qualitätssteigerung bei. Frühe Schätzungen Paradox an der Situation ist, dass gleichzeitig sowohl frühe als auch genaue Schätzungen benötigt werden. Frühe Schätzungen sind jedoch in der Regel ungenau. Da oft die Schätzungen nicht professionell dokumentiert werden, kann auch nicht aus den Erfahrungen der Vergangenheit gelernt werden. So schließt sich der Teufelskreis: Schätzen erfolgt zu früh und zu selten! Bei frühen Schätzungen kann nur grob anhand der wenigen vorhandenen Informationen geschätzt werden. Für Unsicherheit und Risiken wird mit Zuschlägen, abhängig vom Projektumfang, in Höhe von 10 % bis 30 % gerechnet. Hinzu kommt der geschätzte Funktionszuwachs für noch zu erwartende technische Änderungen (siehe oben: Schätzgenauigkeit und Schätzzeitpunkte). Bei Auswertungen genau dokumentierter Function- Point-Zählungen mit Hilfe von Regressionsanalysen konnte in der AXA Service AG ein starker Zusammenhang zwischen der Anzahl der gezählten Eingaben und Ausgaben mit den Funktionspunkten insgesamt ermittelt werden (siehe Abb. 4). Damit können bereits zu frühen Zeitpunkten (zum Zeitpunkt der Studie, also vor Projektbeginn) Prognosen für die erst später genauer zählbaren Function Points vorgenommen werden, die eine hohe Prognosegenauigkeit aufweisen (Fehlermarge ca. 12 %). Akzeptanz Abb. 4: Function-Point-Prognose 27

6 WISSEN Function Points sind unbeliebt, weil sie von Theoretikern erstellt und praxisfern sind.... sie Verwaltungsaufwand produzieren.... sie nicht für objektorientierte Anwendungsentwicklung geeignet sind. Abb. 5: Killerphrasen und Gegenargumente stände bei den betroffenen Mitarbeitern. Einige beliebte Killerphrasen gegen die Function-Point-Methode und Gegenargumente dazu zeigt Abb. 5. Zum Umgang mit Widerständen sind die in Tabelle 1 gezeigten Maßnahmen empfehlenswert. Aufwandschätzung in speziellen Umgebungen Das Aufkommen neuer Technologien in der Software-Entwicklung hat für die Aufwandschätzung und Function- Point-Zählung Herausforderungen gebracht, denn die Methoden wurden aus Erfahrungen der Vergangenheit entwickelt, um Hilfen für die Planung von zukünftigen Projekten und Anwendungssystemen zu bieten. Dabei zeigte sich, dass die bewährten Konzepte auch in neuen Umfeldern einsetzbar sind. Speziell im objektorientierten Paradigma, bei Datawarehouse-Systemen und Web-Entwicklungen ist die Function-Point-Methode einsetzbar, wobei einzelne Anpassungen vorzunehmen sind. Objektorientierte Metriken Ursprünglich von A. Albrecht in einem Projekt zur Erstellung von Systemsoftware entwickelt. Der Aufwand ist im Vergleich zu Nutzen und Projektgesamtaufwand vernachlässigbar gering. Die FP stellen ein Meta-Modell dar, daher ist eine Abbildung der Requirements, egal in welcher Beschreibung, möglich. Über 200 verschiedene objektorientierte Software-Metriken sind in den letzten Jahren publiziert worden. Horst Zuse [8] hat über 130 davon zusammengestellt und teilweise erläutert. Auch die ISBSG-Benchmarking-Datenbank vom Juni 2002 enthält knapp 25 % Projekte, in denen mit objekorientierten Metoden gearbeitet wurde [6]. Häufig wird behauptet, dass objektorientierte Metriken nicht mit der Function-Point-Methode kompatibel seien. obwohl Fetcke et al. [5] für die objektorientierte Systementwicklung eine Konzeption und konkrete Regeln für die Umsetzung in Function Points vorgelegt haben. Auch die IFPUG hat eine ausführliche Fallstudie (Case Study III) für den Einsatz der Function-Point-Methode bei objektorientierter Systementwicklung vorgelegt. Dabei sind Klassen Kandidaten für interne und externe Dateien. Objekte sind Kandidaten für Eingaben, Ausgaben und Abfragen. Ebenso beschreiben Use Cases aus dem UML- Umfeld (Unified Modelling Language) die Funktionalität aus Benutzersicht und können somit leicht in Function Points bemessen werden [3, Seite 223 ff.]. Function-Point-Zählung von Datawarehouse- Projekten Die Anforderungen an Datawarehouse-Systeme unterscheiden sich erheblich von den Anforderungen an transaktionsorientierte Systeme. Nach Auswertungen der ISBSG-Benchmarking-Datenbank beträgt der Anteil von Code- und Referenztabellen in Datawarehouse-Systemen im Verhältnis zum funktionalen Umfang bis zu 60 % gegenüber Management-Informationssystemen, wo er oft 30 % bis 40 % beträgt. Die Multidimensionalität der Datawarehouse-Architektur ist eine Herausforderung für die Function-Point-Zählung. Inzwischen sind zwei Vorschläge für die Zählung von Datawarehouse-Systemen publiziert worden [3, Seite 386 ff.]. Aufwandschätzung von Web-Entwicklungen Web-Entwicklungen unterscheiden sich von konventioneller Software-Entwicklung durch ihre Einbettung in mehrstufige, komponentenbasierte Client-Server-Architekturen (oft vier oder fünf Stufen). Dabei werden häufig bestehende Alt-Anwendungen integriert. Bei der komponentenbasierten Software ist die Implementierung gekapselt. Die Komponentenorientierung ändert nichts an der Zählweise der Function Points, unterstützt vielmehr den Einsatz der Function-Point-Methode für die Messung des Softwareumfangs von Web-Entwicklungen [3, Seite 398 ff.]. Die Erweiterung von Alt-Anwendungen um Web-Frontends kann dabei wie ein Weiterentwicklungsprojekt gezählt werden, die Neuentwicklung kompletter Web-Anwendungen wie ein Neuentwicklungsprojekt. Einzige Herausforderung ist die Aufwandschätzung statischer Webseiten. Dabei geht es hauptsächlich um die Gestaltung und Verlinkung hart kodierter HTML-Seiten über spezielle Entwicklungsprogramme oder Texteditoren. Die Aufwandsschätzung erfolgt hier zweckmäßiger durch Expertenschätzungen auf Basis der jeweiligen Mengengerüste. Widerstand Ist natürlich und unvermeidlich. Zeigt sich nicht immer offen. Hat viele Ursachen. Diskutieren Sie über die Bedenken, nicht über die Argumente! Es gibt nicht nur einen Weg, Widerstand zu bekämpfen! Erwarten Sie Widerstand! Finden Sie Widerstand! Verstehen Sie Widerstand! Konfrontieren Sie Widerstand! Managen Sie Widerstand! Tabelle 1: Maßnahmen zum Umgang mit Widerständen 28

7 Aufwandschätzung von Wartungsaufträgen/Changes Bei Wartungsaufträgen/Changes handelt es sich um kleinere Arbeitspakete, die in der Regel weniger als EUR kosten und keine funktionale Weiterentwicklung der Software betreffen (0 Function Points). Damit entfällt der Umfang als wesentlicher Einflussfaktor für die Aufwandschätzung. Dazu empfiehlt es sich, excelbasierte Schätzformulare zu entwickeln [3, Seite 160 ff.]. Die AXA Service AG hat mehrere Varianten solcher Schätzformulare im Einsatz: für grobe Schätzungen sowie Host, PC und Client/Server, Bürokommunikation und Agentursystem. Dabei werden meist vorgegebene Standardaufwandsätze mit Einflussparametern multipliziert (z. B. Anzahl Ansprechpartner im Fachbereich mal Standardaufwand). Weitere Gemeinkosten-Zuschläge, z. B. für Projektmanagement und Testen, werden hinzugefügt. Damit wurden in der Pilotphase in zwei Jahren 220 Aufwandschätzungen in fünf Abteilungen gesammelt, ausgewertet und daraufhin die Standardwerte verbessert. Im letzten Jahr wurden 130 Aufwandschätzungen aus zwölf Monaten ebenfalls zu einer erneuten Aktualisierung der Standardwerte ausgewertet. Das Verfahren hat sich durch Mund-zu-Mund-Propaganda im Unternehmen verbreitet (Piloten waren drei Abteilungen, aber von fünf Abteilungen lagen am Ende der Pilotphase Aufwandschätzungen zur Auswertung vor). Funktionale Erweiterungen/Changes werden generell wie Neuentwicklungen behandelt. Beim Einsatz der Function-Point-Methode mit Toolunterstützung hat sich dabei herausgestellt, dass eine vernünftige Dokumentation der ursprüglichen Function-Point-Zählung (z. B. entlang den Menüpunkten der Bildschirmmasken und entsprechend den Transaktionen) bei der späteren Änderungsschätzung eine schnelle Zuordnung der zugehörigen Function Points erleichtert und damit der Umfang für die Änderungen schnell ermittelt und dem Auftraggeber mitgeteilt werden kann. Software. Sie fördert die Bewertung der Software zur Verbesserung ihrer Nutzung in Wirtschaft und Verwaltung. Gegründet 1993 in Darmstadt, hat sie derzeit (2003) ca. 60 Mitglieder in Deutschland, Österreich und der Schweiz. Außerdem ist die DASMA Mitglied der wichtigsten internationalen IT-Metrikorganisationen. Die DASMA versteht sich als Netzwerk und Berufsverband der deutschsprachigen Anwender von Software-Metriken und Aufwandschätzung [3, Seite 254 ff.]. GI-FG Software-Messung und -Bewertung Die GI-Fachgruppe Software-Messung und -Bewertung in Magdeburg besteht seit 1992 und wird von Prof. Dumke geleitet. Inhaltlich befasst sie sich sowohl mit den theoretischen Grundlagen im Bereich Softwaremessung und -bewertung als auch mit der praktischen Umsetzung im Software-Entwicklungsprozess, wie beispielsweise Zertifizierungen, Metrikdatenbanken oder Experience Factories. Dazu veranstaltet sie regelmäßig den International Workshop on Software Measurement IWSM, der im Wechsel in Deutschland (zusammen mit der MetriKon- Tagung der DASMA) und Kanada (in Zusammenarbeit mit der Universität Quebec, Prof. Abran) stattfindet (Proceedings 2001 unter Die Fachgruppe betreut auch das Softwaremesslabor (SMLab), das den Prototyp einer Messdatenbank im Internet anbietet. Darüber hinaus publiziert sie zweimal im Jahr die Me- Anzeige Professionelle Hilfestellung durch Metrikorganisationen Speziell für Anfänger, aber auch zur Diskussion mit Fortgeschrittenen und Experten empfiehlt sich die Mitgliedschaft in einem nationalen Metrikverband, ggf. auch die weitere Mitgliedschaft in einer internationalen Metrikorganisation. Zum einen erhält man von Anwendern Hilfen für die effektive Einführung der Function-Point-Methode sowie durch den Erfahrungsaustausch in den Gremien der Organisationen die Möglichkeit, die eigene Betriebsblindheit zu überwinden. Außerdem bekommt man ständig neue Anregungen. Zum anderen trägt man durch seine Mitgliedschaft mit dazu bei, dass sich Software-Metriken weiter verbreiten und noch mehr etablieren. Dies ist insbesondere für das Benchmarking wichtig, denn ohne eine internationale Standardisierung ist ein firmenübergreifendes Benchmarking undenkbar. Projektmanagement mit EDV ¼ Seite hoch + sw (92 b 125h) DASMA Die Deutschsprachige Anwendergruppe für Software- Metrik und Aufwandschätzung e.v. (DASMA) ist ein gemeinnütziger Verein und befasst sich mit der Entwicklung und Festsetzung von Standards zum Messen von 29

8 WISSEN trics News mit Informationen zu den Themen Softwaremessung und -Metriken. Die Homepage der Fachgruppe (www.ivs.cs.uni-magdeburg.de/sw-eng/us/) bietet zahlreiche Informationsmöglichkeiten [3, Seite 256 ff.]. IFPUG Die International Function Point User Group (IFPUG) in den USA (gegründet 1984) hat mit Version 4.1 eine standardisierte Function-Point-Methode verabschiedet, die genaue Anleitungen für die Zählung der Function Points enthält. Dieser Standard ist von der ISO im Oktober 2003 als ISO/IEC Standard für die Umfangmessung von Software anerkannt worden (ohne die 14 Systemmerkmale). Die Aufwandschätzung der IT-Projekte soll mit der Version 4.1 der IFPUG-Function-Point-Methode in einen en Stand versetzt und überbetrieblich vergleichbar werden. Weiter bietet die IFPUG an, ihre Mitglieder als Function-Point-Zähler zertifizieren zu lassen (seit 2004 auch als Metrikspezialist in mehreren Stufen). Sie richtet jährliche Tagungen zum Erfahrungsaustausch aus und arbeitet in zahlreichen Arbeitsgruppen an der Weiterentwicklung der Function-Point-Methode. So ist bereits 1998 als Ergänzung zu den zwei bereits bestehenden, detaillierten Fallstudien zur Function-Point-Methode noch eine dritte für die objektorientierte Software-Entwicklung herausgegeben worden. Die Homepage der IFPUG (www.ifpug.org) bietet Foren zum Informationsaustausch und e Informationen zu Software-Metriken und Aufwandschätzung sowie zahlreiche Links zu anderen IT-Metrikorganisationen und Services für die IFPUG-Mitglieder [3, Seite 257 ff.]. ISBSG Die International Software Benchmarking Standards Group (ISBSG, gesprochen: IceBags Eistüten) begann als ein loser Zusammenschluss von internationalen IT- Metrikorganisationen. Sie verwenden für die Schätzung des Projektumfangs zum überwiegenden Teil die Function-Point-Methode (meistens nach IFPUG). Diese IT- Metrikorganisationen trugen Informationen und Techniken mit dem Ziel zusammen, die Praktiken zur Software- Entwicklung zu verbessern. Im Juli 1994 trafen sich Vertreter von IT-Metrikorganisationen aus USA, England, Australien und Neuseeland und gründeten die ISBSG. Das bisher letzte Release 8 der ISBSG-Benchmarking- Datenbank erschien im Juni 2003 auf der Basis von Projekten. Der bisher letzte Report The Benchmark Release 8 wurde Mitte Januar 2004 anhand von Projekten publiziert. Alle Unterlagen der ISBSG können auch über das DASMA-Sekretariat bezogen werden [3, Seite 259 ff.]. MAIN Das Metrics Association s International Network (MAIN) wurde 2002 in Brüssel mit dem Ziel gegründet, den Austausch von Informationen zwischen den europäischen Usergroups im Software-Metrik-Bereich durch Organisation von Konferenzen und Workshops etc. zu koordinieren. Es wurde beschlossen, die Informationen über Aktivitäten und Resultate der nationalen europäischen IT-Metrikorganisationen auszutauschen und eine gemeinsame Vertretung in der ISO, ISBSG und anderen internationalen IT-Metrikorganisationen sicherzustellen [3, Seite 266 ff.]. Literatur [1] Bundschuh, Manfred: Die Function Point Methode im praktischen Einsatz bei Softwareprojekten. In: Schelle et al (Hrsg.): Loseblattsammlung Projekte erfolgreich managen. 13. Aktualisierungs- und Ergänzungslieferung, Köln, November 1999 [2] Bundschuh, Manfred: Aufwandsschätzung als Voraussetzung für die Projektplanung. In: Bernecker, Michael; Eckrich, Klaus: Handbuch Projektmanagement. R. Oldenbourg Verlag München Wien 2003, S [3] Bundschuh, M.; Fabry, A.: Aufwandschätzung von IT-Projekten. 2. Auflage, MITP Verlag, Bonn 2004, ISBN X [4] DeMarco, Tom: Was man nicht messen kann kann man nicht kontrollieren. MITP Verlag, Bonn 2004, ISBN [5] Fetcke, T; Abran, A.; Nguyen, T.: Function Point Analysis for the OO-Jacobson Method: A Mapping Approach. In: Proceedings of the FESMA Conference Antwerp, pp [6] ISBSG: The Benchmark, Release 8. ISBSG, Warrandyte, Victoria 2002, ISBN [7] Jones, C.: Applied Software Measurement. McGraw- Hill, New York 1996, ISBN [8] Zuse, H.: A Framework for Software Measurement. DeGruyter, Berlin, New York 1997, ISBN Schlagwörter Full Function Points (COSMIC), Function-Point-Methode, Function-Point-Prognose, ISBSG-Benchmarking-Datenbank, Metrikorganisationen, objektorientierte Metriken, schleichender Funktionszuwachs (requirements creep), Softwareumfang von Web-Entwicklungen, Umfangmaße nach DIN, Zählung von Datawarehouse-Systemen Autor Dipl.-Math. Manfred Bundschuh ist seit über 20 Jahren im IT-Ressort der AXA Service AG tätig, derzeit als IT-Controller. Seit mehr als 20 Jahren hat er Lehraufträge für Software Engineering sowie Projektmanagement und Arbeitsmethodik an der Fachhochschule Köln und hat dabei über 200 DiplomandInnen betreut. Für diesen besonderen Einsatz wurde ihm 1996 die Ehrenmedaille der Fachhochschule Köln verliehen. Seit einigen Jahren ist er Vorstandsvorsitzender der DASMA e.v. (Deutschsprachiger Anwenderverband für Software Metriken und Aufwandschätzung, Er ist Mitautor und Mitherausgeber von einigen IT-Fachbüchern. Sein Buch Aufwandschätzung von IT-Projekten ist 2004 in der 2. Auflage erschienen. Anschrift Sander Höhe Bergisch Gladbach Tel./Fax: /

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

Kosten/Aufwand - Schätzungsverfahren bei komplexen Softwareprojekten als Basis für IT-Governance

Kosten/Aufwand - Schätzungsverfahren bei komplexen Softwareprojekten als Basis für IT-Governance Forum Compliance & IT-Governance 2007 Tools und Strategien um wirtschaftliche und rechtliche Risiken zu vermeiden Jahresforum 25. April 2007, Wien, Eventlocation Vista3 Kosten/Aufwand - Schätzungsverfahren

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

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

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

Mehr

Informationsmanagement in Organisationen Überblick

Informationsmanagement in Organisationen Überblick Informationsmanagement in Organisationen Überblick Wolfgang H. Janko Andreas Geyer-Schulz Stefan Koch Edward Bernroider Abteilung für Informationswirtschaft Institut für Informationsverarbeitung und Informationswirtschaft

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

Projektmanagement (Modelle, Methoden & Tools)

Projektmanagement (Modelle, Methoden & Tools) Projektmanagement (Modelle, Methoden & Tools) Übersicht zu den Inhalten der Vorlesung Die Inhalte der Vorlesung wurden primär auf Basis der angegebenen Literatur erstellt. Darüber hinaus finden sich vielfältige

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

(Erweiterte) Funktionalgrößen Meßmethoden. sind auch in Verbesserungsprojekten anwendbar

(Erweiterte) Funktionalgrößen Meßmethoden. sind auch in Verbesserungsprojekten anwendbar Abstract: (Erweiterte) Funktionalgrößen Meßmethoden sind auch in Verbesserungsprojekten anwendbar Ton Dekkers (ins Dt. von Oliver Meyer) Sogeti Nederland B.V. (Sogeti Deutschland GmbH) ton.dekkers@sogeti.nl

Mehr

Mit Metriken zu mehr Transparenz in der SW-Entwicklung

Mit Metriken zu mehr Transparenz in der SW-Entwicklung Mit Metriken zu mehr Transparenz in der SW-Entwicklung Manfred Seufert 26.09.2012 MediaanABS Deutschland GmbH Düsseldorf, 27. September 2012 Mediaan in a Nutshell Etabliert Fokussiert gegründet 1969 in

Mehr

Punktlandung Projektkosten

Punktlandung Projektkosten Pragmatische und zuverlässige Schätzung von IT-Projektkosten Punktlandung Projektkosten 44 Foto: Siemens Pressebild Wir stellen eine pragmatische Methodik vor, mit der sich Kostenschätzungen für IT-Projekte

Mehr

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

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

Mehr

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

Agile Softwareentwicklung in der Versicherungs-IT Fehlschlag oder Heilsbringer?

Agile Softwareentwicklung in der Versicherungs-IT Fehlschlag oder Heilsbringer? OOP 2012 Agile Softwareentwicklung in der Versicherungs-IT Fehlschlag oder Heilsbringer? André Köhler Softwareforen Leipzig GmbH Geschäftsführer 1 Das Bild kann nicht angezeigt werden. Dieser Computer

Mehr

Übungen zur Softwaretechnik

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

Mehr

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

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

Mehr

Dipl. Inf. Ali M. Akbarian

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

Mehr

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

Vorwort. Hermann J. Schmelzer, Wolfgang Sesselmann. Geschäftsprozessmanagement in der Praxis

Vorwort. Hermann J. Schmelzer, Wolfgang Sesselmann. Geschäftsprozessmanagement in der Praxis Vorwort Hermann J. Schmelzer, Wolfgang Sesselmann Geschäftsprozessmanagement in der Praxis Kunden zufrieden stellen - Produktivität steigern - Wert erhöhen ISBN (Buch): 978-3-446-43460-8 Weitere Informationen

Mehr

GI-AK Software-Offshoring und das Zentrum für Internationale Kollaborative Softwareprojekte ZIKS

GI-AK Software-Offshoring und das Zentrum für Internationale Kollaborative Softwareprojekte ZIKS GI-AK Software-Offshoring und das Zentrum für Internationale Kollaborative Softwareprojekte ZIKS Institut für Angewandte Informatik und Formale Beschreibungsverfahren (AIFB), Universität Karlsruhe (TH)

Mehr

Software-Projektkalkulation

Software-Projektkalkulation Software-Projektkalkulation Harry M. Sneed Praxiserprobte Methoden der Aufwandsschätzung für verschiedene Projektarten ISBN 3-446-40005-2 Inhaltsverzeichnis Weitere Informationen oder Bestellungen unter

Mehr

Einführung in die SWE

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

Mehr

Softwarequalität: Definitionen, Wünsche, Grenzen

Softwarequalität: Definitionen, Wünsche, Grenzen Softwarequalität: Definitionen, Wünsche, Grenzen iks Thementag Mehr Softwarequalität Ausgewählte Themen 22.05.2014 Autor: Christoph Schmidt-Casdorff Agenda Einführung Was ist Softwarequalität? Qualität

Mehr

IV::SOLUTIONFRAMEWORK

IV::SOLUTIONFRAMEWORK IV::SOLUTIONFRAMEWORK EINFÜHRUNG Das IV::SolutionFramework ist die Antwort der INTERVISTA AG auf die Anforderungen an moderne IT Entwicklungsprojekte. Effiziente Vorgehensmodelle und die Einführung von

Mehr

Requirements Management Wissensmanagement für und mit Anforderungen

Requirements Management Wissensmanagement für und mit Anforderungen Requirements Management Wissensmanagement für und mit Anforderungen Barbara Paech Forum ITK-Industrie Industrie trifft Forschung in ViSEK, 28.10.02 IESE Fraunhofer Institut Experimentelles Software Engineering

Mehr

POCKET POWER. Projektmanagement. 3. Auflage

POCKET POWER. Projektmanagement. 3. Auflage POCKET POWER Projektmanagement 3. Auflage 3 Inhalt 1 Einleitung.................................... 5 2 Grundlagen des Projektmanagements................... 8 2.1 Projektdefinition..............................

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

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

Grundlagen der Projektarbeit

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

Mehr

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

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

Mehr

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

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

MARKUS SÖLLNER CONSULTING BUSINESS ANALYTICS DEVELOPMENT. Vita und Leistungen

MARKUS SÖLLNER CONSULTING BUSINESS ANALYTICS DEVELOPMENT. Vita und Leistungen MARKUS SÖLLNER CONSULTING BUSINESS ANALYTICS DEVELOPMENT Vita und Leistungen Vita Nach dem Studium der Wirtschaftsinformatik an der Otto-Friedrich-Universität Bamberg (1999 bis 2004) begann meine Berater-

Mehr

maihiro select Projektskizze für eine CRM-Softwareauswahl

maihiro select Projektskizze für eine CRM-Softwareauswahl maihiro select Projektskizze für eine CRM-Softwareauswahl Agenda Inhalt Überblick eines CRM-Programms maihiro select - Projektvorgehen maihiro select - Projektbeispiele Nächste Schritte Übersicht - Vorgehen

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

Effizienz- und Qualitäts-Management in der. Softwareentwicklung

Effizienz- und Qualitäts-Management in der. Softwareentwicklung Effizienz- und Qualitäts-Management in der Softwareentwicklung Panteleimon Evgenos ivv GmbH Hannover 2006 ivv GmbH Informationsverarbeitung für Versicherungen GmbH Tel. 0511-362-11 35 Agenda Kurzvorstellung

Mehr

Management großer Projekte Ein modellbasierter Ansatz

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

Mehr

Informationswirtschaft II Rational Unified Process (RUP)

Informationswirtschaft II Rational Unified Process (RUP) Informationswirtschaft II Rational Unified Process (RUP) Wolfgang H. Janko, Michael Hahsler und Stefan Koch Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe Das

Mehr

Informationswirtschaft II

Informationswirtschaft II Rational Unified Process (RUP) Informationswirtschaft II Wolfgang H. Janko, Michael Hahsler und Stefan Koch Seite 1 Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe

Mehr

Qualität 1. 1 Qualität

Qualität 1. 1 Qualität Qualität 1 1 Qualität Nach dem Durcharbeiten dieses Kapitels sollten Sie die Qualität für ein Softwaresystem definieren können, typische Qualitätskriterien kennen, Qualitätskriterien messbar festlegen

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

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

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

Mehr

Software-Qualität Ausgewählte Kapitel

Software-Qualität Ausgewählte Kapitel Institut für Informatik! Martin Glinz Software-Qualität Ausgewählte Kapitel Kapitel 10 Qualitätsnormen" 2009-2011 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen,

Mehr

Betriebswirtschaftliche Kriterien, Aufwand und Nutzen von CMMI-Implementierungen

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

Mehr

Methoden der Aufwandschätzung - Zwischen Theorie und Praxis -

Methoden der Aufwandschätzung - Zwischen Theorie und Praxis - Methoden der Aufwandschätzung - Zwischen Theorie und Praxis - Kaiserslautern 12. Mai 2004 Fraunhofer Institut Experimentelles Software Engineering Dr. Jürgen Münch Sauerwiesen 6 D-67661 Kaiserslautern

Mehr

Produktphilosophie erstellen

Produktphilosophie erstellen User Experience Produktphilosophie erstellen Bereich Anforderungen Aktivität Ziele Erleichterte Kommunikation zwischen Stakeholdern Designentscheidungen erleichtern/rechtfertigen schnell durchführbar einfach

Mehr

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

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

Mehr

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

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

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

Mehr

Ordentliche Geschäftsprozessmodellierung (GPM) nutzt auch Ihrer IT-Infrastruktur. (Was hat GPM mit IT zu tun?) Antonius J.M.

Ordentliche Geschäftsprozessmodellierung (GPM) nutzt auch Ihrer IT-Infrastruktur. (Was hat GPM mit IT zu tun?) Antonius J.M. Ordentliche Geschäftsprozessmodellierung (GPM) nutzt auch Ihrer IT-Infrastruktur (Was hat GPM mit IT zu tun?) Antonius J.M. van Hoof Fachrichtung Informationstechnik GPM-Workshop 07.07.2006 Inhalt Kernpunkte

Mehr

Wie misst man Qualität?

Wie misst man Qualität? Software Systems Engineering Wie misst man Qualität? Dr. Privat-Doz. A Herrmann Institut Software Systems Engineering Ziele dieses Workshops Workshop Wie misst man Qualität? Methoden lernen: Herleitung

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

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

Mehr

Anforderungsmanagement im Projekt BIS-BY. BIS-BY: Requirement Management

Anforderungsmanagement im Projekt BIS-BY. BIS-BY: Requirement Management Anforderungsmanagement im Projekt BIS-BY von B. KREUZER Schlüsselwörter: Änderungswünsche, Anforderungsmanagement, DOORS Kurzfassung Softwaresysteme unterliegen während ihrer Entwicklung und während ihres

Mehr

Leseprobe. Joachim Drees, Conny Lang, Marita Schöps. Praxisleitfaden Projektmanagement. Tipps, Tools und Tricks aus der Praxis für die Praxis

Leseprobe. Joachim Drees, Conny Lang, Marita Schöps. Praxisleitfaden Projektmanagement. Tipps, Tools und Tricks aus der Praxis für die Praxis Leseprobe Joachim Drees, Conny Lang, Marita Schöps Praxisleitfaden Projektmanagement Tipps, Tools und Tricks aus der Praxis für die Praxis ISBN: 978-3-446-42183-7 Weitere Informationen oder Bestellungen

Mehr

ITSM-Health Check: die Versicherung Ihres IT Service Management. Christian Köhler, Service Manager, Stuttgart, 03.07.2014

ITSM-Health Check: die Versicherung Ihres IT Service Management. Christian Köhler, Service Manager, Stuttgart, 03.07.2014 : die Versicherung Ihres IT Service Management Christian Köhler, Service Manager, Stuttgart, 03.07.2014 Referent Christian Köhler AMS-EIM Service Manager Geschäftsstelle München Seit 2001 bei CENIT AG

Mehr

Requirements Management mit RequisitePro. Rational in der IBM Software Group. Der Rational Unified Process als Basis für die Projektarbeit

Requirements Management mit RequisitePro. Rational in der IBM Software Group. Der Rational Unified Process als Basis für die Projektarbeit IBM Software Group IBM Rational mit RequisitePro Hubert Biskup hubert.biskup@de.ibm.com Agenda Rational in der IBM Software Group Der Rational Unified Process als Basis für die Projektarbeit mit Rational

Mehr

Hubert Biskup Ralf Kneuper (Hrsg.) Nutzen und Nutzung von Vorgehensmodellen

Hubert Biskup Ralf Kneuper (Hrsg.) Nutzen und Nutzung von Vorgehensmodellen Hubert Biskup Ralf Kneuper (Hrsg.) Nutzen und Nutzung von Vorgehensmodellen 13. Workshop der Fachgruppe WI-VM der Gesellschaft für Informatik e.v. (GI) Berichte aus der Wirtschaftsinformatik Hubert Biskup,

Mehr

Teststrategie festlegen und Teststufen aufeinander abstimmen

Teststrategie festlegen und Teststufen aufeinander abstimmen Testen Teststrategie festlegen und Teststufen aufeinander abstimmen Bereich Projektplanung und -steuerung Aktivität Projekt planen Ziele Effiziente Testausführung Vermeidung von doppelter Arbeit schnell

Mehr

Peter Meier. Die Umsetzung von Risikomanagement nach ISO 31000. - Leseprobe -

Peter Meier. Die Umsetzung von Risikomanagement nach ISO 31000. - Leseprobe - Peter Meier Die Umsetzung von Risikomanagement nach ISO 31000 Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen

Mehr

BSSE. Innovation & Fortschrittliche Software-Technologie Fähigkeiten & Dienstleistungen

BSSE. Innovation & Fortschrittliche Software-Technologie Fähigkeiten & Dienstleistungen BSSE Bessere + Sichere Software Effizient Erzeugen Innovation & Fortschrittliche Software-Technologie Fähigkeiten & Dienstleistungen Dr. Rainer Gerlich Auf dem Ruhbühl 181, D-88090 Immenstaad, Germany

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

6 Architektur-Mittel (WOMIT)

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

Mehr

Kapitel 2: Der Software-Entwicklungsprozess

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

Mehr

User-centered design am Beispiel der Entwicklung eines Datenmanagementsystems für klinische Studien

User-centered design am Beispiel der Entwicklung eines Datenmanagementsystems für klinische Studien User-centered design am Beispiel der Entwicklung eines Datenmanagementsystems für klinische Studien Natascha Andres Forschungsgruppe Geriatrie, Charité, Universitätsmedizin Berlin Agenda Thematischer Hintergrund

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

Produktqualität in agilen Entwicklungsvorgehen. BITKOM Software Summit Frankfurt, 23. September 2014 Dominik Rost, Hartmut Schmitt

Produktqualität in agilen Entwicklungsvorgehen. BITKOM Software Summit Frankfurt, 23. September 2014 Dominik Rost, Hartmut Schmitt Produktqualität in agilen Entwicklungsvorgehen BITKOM Software Summit Frankfurt, 23. September 2014 Dominik Rost, Hartmut Schmitt 1 Motivation 2 Agile Entwicklungsvorgehen Status Quo vorwiegend eingesetzte

Mehr

Software-Qualität Ausgewählte Kapitel

Software-Qualität Ausgewählte Kapitel Martin Glinz Software-Qualität Ausgewählte Kapitel Kapitel 1 Einführung Universität Zürich Institut für Informatik 2009 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe sind für den persönlichen,

Mehr

Timeboxing. Rückgrat agiler Projekte. Bernd Oestereich (Geschäftsführer) Christian Weiss (Geschäftsführer) Timeboxing Rückgrat agiler Projekte

Timeboxing. Rückgrat agiler Projekte. Bernd Oestereich (Geschäftsführer) Christian Weiss (Geschäftsführer) Timeboxing Rückgrat agiler Projekte Bernd Oestereich (Geschäftsführer) Timeboxing Rückgrat agiler Projekte Christian Weiss (Geschäftsführer) Copyright by oose GmbH 2006 Das Wasserfallmodell ein historisches Mißverständnis. Der Wasserfallprozess-

Mehr

Requirements Engineering as a Success Factor in Software Projects

Requirements Engineering as a Success Factor in Software Projects Requirements Engineering as a Success Factor in Software Projects Hubert F. Hofmann, Franz Lehner Vorgetragen von Holger Friedrich Motivation Falsche Anforderungen sind der häufigste Grund für das Scheitern

Mehr

Gute Performance ist die Basis des Erfolges. Process & Performance

Gute Performance ist die Basis des Erfolges. Process & Performance Gute Performance ist die Basis des Erfolges Process & Performance Begeistern Sie Ihre Kunden und erhöhen Sie so Ihren Unternehmenserfolg. Es gibt Dinge, die erschließen sich auch beim zweiten Blick nicht

Mehr

Requirements Engineering für die agile Softwareentwicklung

Requirements Engineering für die agile Softwareentwicklung Johannes Bergsmann Requirements Engineering für die agile Softwareentwicklung Methoden, Techniken und Strategien Unter Mitwirkung von Markus Unterauer dpunkt.verlag Inhaltsverzeichnis 1 Einleitung 1 1.1

Mehr

Talk im Schloss. Zusammenbringen was zusammen gehört. Der richtige Softwareentwicklungsprozess für erfolgreiches Usability Engineering 10.12.

Talk im Schloss. Zusammenbringen was zusammen gehört. Der richtige Softwareentwicklungsprozess für erfolgreiches Usability Engineering 10.12. Talk im Schloss Zusammenbringen was zusammen gehört Der richtige Softwareentwicklungsprozess für erfolgreiches Usability Engineering 10.12.2007 F.Riemenschneider +49 177 291 68 32 falko.riemenschneider@itemis.de

Mehr

Informationssicherheit im mittelstand. Bavarian IT Security & Safety Cluster

Informationssicherheit im mittelstand. Bavarian IT Security & Safety Cluster Informationssicherheit im mittelstand... > Bavarian IT Security & Safety Cluster > ein PROdUKt des BayeRisCHen it-sicherheits- ClUsteRs e.v. der Bayerische it-sicherheitscluster e.v. Der Bayerische It-sicherheitscluster

Mehr

RE-Praxisbericht: Ergebnisse einer aktuellen Studie zum Thema Use Cases

RE-Praxisbericht: Ergebnisse einer aktuellen Studie zum Thema Use Cases RE-Praxisbericht: Ergebnisse einer aktuellen Studie zum Thema Use Cases Dr. Alexander Rachmann Hartmut Schmitt Softwareforen Leipzig 9. Mai 2014 Agenda Der Use-Case-Arbeitskreis der Gesellschaft für Informatik/Fachgruppe

Mehr

Befragung und empirische Einschätzung der Praxisrelevanz

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

Mehr

Projektmanagement durch Scrum-Proxies

Projektmanagement durch Scrum-Proxies Cologne Intelligence GmbH Projektmanagement durch Scrum-Proxies Integration von Vorgehensmodellen und Projektmanagement 17. Workshop der Fachgruppe WI-VM der Gesellschaft für Informatik e.v. Stuttgart,

Mehr

Erfolgsquote von IT-Projekten

Erfolgsquote von IT-Projekten PMO in a box Erfolgsquote von IT-Projekten IT-Projekte brauchen klare Strukturen, um erfolgreich zu sein 75% 66% 50% 25% 0% 33% -17% Budget Zeit Scope -25% Quelle: 2012 McKinsey-Oxford study on reference-class

Mehr

Praxisberichte. Plan des Vortrags. Das Rational Unified Process für die Anforderungsspezifikation

Praxisberichte. Plan des Vortrags. Das Rational Unified Process für die Anforderungsspezifikation Praxisberichte Das Rational Unified Process für die Anforderungsspezifikation Seminar in Software Engineering Spezifikationsverfahren Prof. Dr. Martin Glinz Nancy Schett Laurent Bagnoud Plan des Vortrags

Mehr

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

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

Mehr

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

Abgrenzung bzw. Kombination traditionelles und agiles Projektmanagement

Abgrenzung bzw. Kombination traditionelles und agiles Projektmanagement Abgrenzung bzw. Kombination traditionelles und agiles Projektmanagement Vortrag im Rahmen des IKT-Forums 2015 Salzburg-Urstein am 21. Mai 2015 www.organisationsgesta 00. Agenda Agenda 1. Projektmanagement

Mehr

Restrukturierung des Unternehmensbereiches E-Commerce- Solutions

Restrukturierung des Unternehmensbereiches E-Commerce- Solutions Restrukturierung des Unternehmensbereiches E-Commerce- Solutions swisscom AG Projektdauer: 1 Jahr Stand 10.02.2009, Version 1.0 Projektziel Das Projektziel bei der Swisscom AG beinhaltete eine Restrukturierung

Mehr

Gemeinsam erfolgreich in IT Projekten

Gemeinsam erfolgreich in IT Projekten management consulting partners Gemeinsam erfolgreich in IT Projekten MCP Die IT-Spezialisten mit Prozesswissen in der Industrie MCP GmbH www.mc-partners.at Christian Stiefsohn Juli 2014 Das Unternehmen

Mehr

Projektmanagement im Software Engineering Praktikum der TU Darmstadt

Projektmanagement im Software Engineering Praktikum der TU Darmstadt Projektmanagement im Software Engineering Praktikum der TU Darmstadt Günter Schmitt Fachgebiet Praktische Informatik TU Darmstadt Wilhelminenstraße 7 D-64283 Darmstadt e-mail: ag-madoka@t-online.de Abstract:

Mehr

Je mehr der öffentliche Dienst unter finanziellen Druck

Je mehr der öffentliche Dienst unter finanziellen Druck Aufwandsschätzungen in Softwareprojekten Je mehr der öffentliche Dienst unter finanziellen Druck gerät und Mitarbeiterinnen und Mitarbeiter nicht mehr wie bisher pauschal finanziert für Entwicklungsaufgaben

Mehr

Effektstärken-Check: Wichtigste Projektkategorien

Effektstärken-Check: Wichtigste Projektkategorien Als die wichtigsten Einflussfaktoren für Projekterfolg wurden die nachfolgenden Fragen an die Teilnehmer der Studie Evidenzbasierte Erfolgsfaktoren im Projektmanagement, BPM-Labor Hochschule Koblenz, Prof.

Mehr

SOA Was ist geblieben nach dem Hype?

SOA Was ist geblieben nach dem Hype? FACHKONFERENZ SOA Was ist geblieben nach dem Hype? www.softwareforen.de/goto/soa2009 KÖLN, 2. 3. DEZEMBER 2009 MIT VORTRÄGEN VON MIT FREUNDLICHER UNTERSTÜTZUNG DURCH VERANSTALTUNGSBESCHREIBUNG Das Paradigma

Mehr

ICTSCOPE.CH Eine Fachgruppe von

ICTSCOPE.CH Eine Fachgruppe von Vortrag Technologieoutlook Zürich 9.9.2014 ICT-SCOPE MANAGEMENT DIE EMANZIPATION DES FACHBEREICHS IN ICT-PROJEKTEN Partner von ICTSCOPE.CH Eine Fachgruppe von ICT Scope Management Kritikalität der ICT

Mehr

Softwaremessung und -metrik

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

Mehr

Thema: Risikomanagement

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

Mehr

Die Fachgruppe Critical Chain PM Status 05.03.2011

Die Fachgruppe Critical Chain PM Status 05.03.2011 Die Fachgruppe Critical Chain PM Status 05.03.2011 Seite 1 Vereinspräsentation www.gpm-ipma.de Fachgruppe Critical Chain Projektmanagement Die Fachgruppe "Critical Chain Projektmanagement" steht für die

Mehr

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble Vertiefungsarbeit von Karin Schäuble Gliederung 1. Einführung 3. Rahmenbedingungen in der heutigen Marktwirtschaft 3.1 Situation für Unternehmen 3.2 Situation für Applikationsentwickler 4. Lösungskonzepte

Mehr

Software-Lebenszyklus

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

Mehr

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

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

Mehr

Supply Chain Controlling: Entwicklung und Diskussion

Supply Chain Controlling: Entwicklung und Diskussion Supply Chain Controlling: Entwicklung und Diskussion von Christoph Eiser Erstauflage Diplomica Verlag 2015 Verlag C.H. Beck im Internet: www.beck.de ISBN 978 3 95485 266 6 schnell und portofrei erhältlich

Mehr

Stakeholder Management

Stakeholder Management Stakeholder Management Bruno Jenny Partner für Projekt und Portfoliomanagement Aktives Betreiben von Stakeholder Management Wird aktiv Stakeholder Management in den Projekten betrieben? Manchmal 42 % 34

Mehr

Testmanagement Zentraler Prozess im ALM

Testmanagement Zentraler Prozess im ALM Testmanagement Zentraler Prozess im ALM DI Manfred Baumgartner, ANECON ANECON Software Design und Beratung G.m.b.H. Alser Str. 4/Hof 1 A-1090 Wien Tel.: +43 1 409 58 90 www.anecon.com office@anecon.com

Mehr