Einführen einer Software Produktlinien

Größe: px
Ab Seite anzeigen:

Download "Einführen einer Software Produktlinien"

Transkript

1 Einführen einer Software Produktlinien Zhonghua He Universität Siegen ABSTRACT Um einen flüchtigen Einblick in die Software Produktlinie (SPL) zu verschaffen, beschäftigt sich dieser Artikel hauptsächlich mit den grundlegenen Begriffen, Verwendung und Randbedingungen der Software Produktlinie und dem Software Produktlinie Engineering. Dazu werden zuerst die Motivation, Grundlagen und die Zustände der Anwendung kurz vorgestellt. Im Anschluss lässt sich die SPL aufgrund der Merkmalen und den drei wesentlichen Aktivitäten für Software Produktlinien, nämlich Core Asset Development, Product Development, und Management auffassen. Darüber hinaus bezieht es sich auf die Voraussetzungen der Anwendung. Und am Ende kommt der Artikel zu der Anwendungsebene der SPL. Dazu wird das Software-Produktlinie-Engineering kurz beschreibt. 1. EINFÜHRUNG 1.1 Entstehungshintergrund der Software-Produktlinie Die massive Software-Wiederverwendung ist seit langem ein wichtiges Thema der Softwaretechnik, doch viele dieser Versuche sind wegen verschiednen Problemen endlich ausgeblieben. Die traditionellen Wiederverwendungsstrategien können nur wenigen Nutzen einbringen, denn in der Regel sind sie in kleinen Maß und meistens die Ad-hoc Wiederverwendung 1. Heute breitet sich die Anwendung der Software in fast allen Bereichen des Lebens aus, um die vielfältigen gesellschaftlichen Bedürfnisse zu befriedigen. Im intensiven Wettbewerb von heute streben die Unternehmen immer höheren Geschäftszielen zu, wie schnellere Marktagilität, kürzere Markteinführungszeit und höhere Benutzerzufriedenheit. 1 nach den Wiederverwendungsstufen gibt es 5 Wiederverwendungsstufe, die Ad-hoc-Wiederverwendung ist die niedriegste Stufe, ist eine gelegentlich,unsystematisch Wiederverwendung Dazu wird eine effizientere Wiederverwendung-Strategie erfordert, die sich mit dem Konzept der Software Produktlinie beschäftigt. Die SPL wurde in den letzten Jahrhundertwende vom Software Engineering Institute der Carnegie Mellon University in Pittsburgh eingeführt. Seit langem ist der Begriff von Produktlinie 2 in der Automobilindustrie schon vorhanden. Und nach der Einführung der Produktlinie stieg der Umsatz deutlich.[5](s. 6) 1.2 Verwendung von SPL in der Industrie In den letzten Jahren begannen viele internationalen Unternehmen wie ABB, HP, Boeing, Philips u.s.w. den Software- Produktlinen Aufmerksamkeit zu schenken und versuchten die zum Einsatz zu bringen. Ein erfolgreiches Beispiel zur Implementierung der Software Produktlinie ist bei HP (Hewlett Packard), sie initiierte das Owen Firmware Cooperative. 3 Dazu wurde eine Gemeinschaft von mehreren Produktteams für die Durchführung der Produktlinie auf eine kooperative Art und Weise aufgebaut. Der Anfang ist schwer, aber der Einsatz von Software-Produktlinien führte zu einer Erhöhung der Wiederverwendungsproportion auf etwa 70% für neue Produkte. Über 20% der Application Assets 4 basierten auf die leicht modifizierte Core Assets und nur 10% davon erforderten neue Code.[5](S. 419) Wie HP haben bisher viele Unternehmen Versuch dazu ausgeführt und einen Anfangserfolg erzielt, was darauf hinweist, ist, dass die Software-Produktlinie in der Industrieproduktion über großes Potenzial und hohen Forschungswert verfügt. 2. GRUNDLAGEN DER SOFTWARE PRO- DUKTLINIE 2.1 Definition Um unter dem Begriff zu verstehen, muss man zuerst auf die Erklärung von Carnegie Mellon University eingehen: A software product line (SPL) is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. [3] 2 Produktlinie bedeutet eine zusammenhängende Gruppe von Produkten eines Unternehmens 3 Owen ist eine Firmware,die in HP-Drucker Anwendung findet. 4 Die Begriffe von Application Assets und Core Assets werden im Abschnitt 2.2 erklärt.

2 In Anlehnung an diese Definition kann man dazu entnehmen, dass die Software-Produktlinie sich auf eine Menge von Softwareprodukten bezieht, die sich in eine Reihe von Merkmalen teilen. Diese Produktionsweise hängt von der auf die sogenannten Core Assets basierenden systematischen und strategischen Wiederverwendung ab. Zum anderen lässt sich das Software-Produkt trotz der gemeinsamen Entwicklungsgrundlage mit verschiedenen Verwendungszwecken variable einzustellen. 2.2 Begriffsbestimmung Unten aufgelistet sind die wichtigsten Begriffe in der Domäne, die als die grundlegenden Bausteine zum Aufbau des SPL-Konzepts und zur weiteren Intensivierung gelten. Produktlinie(Product Family) Für Software Produktlinie bestehen verschiedene Bezeichnungen, die teilweise synonym verwendet werden. So gibt es für den in der amerikanischen Forschung geprägten Begriff Product line im europäischen Raum die Bezeichnung Product Family, genauso wie ihre Bestandteile entweder Core Assets oder Platform genannt werden. Das lässt sich darauf zurückführen, dass sich ursprünglich amerikanische und europäische Forschungsgemeinschaften getrennt mit der Software Produktlinienentwicklung beschäftigt haben. Außerdem gibt es in Europa weitere Bedeutung für Software-Produktlinien: so bezeichnen einige Unternehmen mit Product Line eine Menge ähnlicher Produkte, die aber auf unterschiedlichen Technologien basieren. Um keine Verwechselungen zu provozieren wurde deshalb in vielen europäischen Forschungsprojekten explizit Product Family (oder auch System Family) verwendet. Außerdem ist es hier zu beachten, dass Product Lines in Product Families enthalten sein können und umgekehrt. Bezüglich dieser Terminologie ist der Begriff Product Line markt- und kundenorientiert, wohingegen eine Product Family ein technologie- bzw. implementierungsabhängiges Konzept ist.[1] Feature Feature(deutsch: Merkmale) ist eine abstrakte Anforderung, die für die Spezifikation der Gemeinsamkeiten und Variabilitäten von Software-Systemen eingesetzt wird. Es ist einfacher die Software zu entwickeln, wenn ihre Features in Design und code explizit dargestellt werden. Wenn die Software durch Auswahl von Features erzeugt werden, wird diese Methode als Featureorientierte Softwareentwicklung genannt.[4] Core Assest(Platform) Core Asset, das in der Produktion von mehreren Produkten in einer Software-Produktlinie verwendet wird, ist ein wiederverwendbares Artefakt 5 oder ein Ressource. Ein Core Asset kann eine Architektur, eine Softwarekomponente, eine Domänenmodell, eine Spezifikation, ein Dokument, ein Plan, einen Testfall, eine Verfahrensbeschreibung usw. sein.[3] Core Asset wird manchmal auch als eine Plattform genannt, alle diese beziehen sich auf die Menge von wiederverwendbaren Artefakten. 5 ein Produkt, das als Zwischen- oder Endergebnis in der Softwareentwicklung entsteht Variabilität Software-Produktlinie hat darüber hinaus auch eine Aufgabe, nämlich die Mannigfaltigkeit einer Reihe von Produkten zu schaffen. Diese Produkte werden je nach den verschiedene Kundenbedarf erstellt, deshalb ist die Variabilität ein Schlüsselkonzept in einem solchen Ansatz. Die Variabilität einer Produktlinie wird durch sogenannte Variationspunkte charakterisiert. Ein Variationspunkt definiert eine Auswahlmöglichkeit unter den von der Produktlinie zur Verfügung gestellten verschiedenen Funktionalitäten. Die Variationspunkte können in allen Entwicklungsphasen definiert und verwaltet werden.[6](s. 8) Da eine Produktlinie typischerweise über sehr viele Variationspunkte verfügt, ist die Variabilität einer Produktlinie oft sehr umfangreich und komplex. Je umfangreicher die Variabilität einer Produktlinie ist, umso größer ist die Flexibilität bei der Entwicklung von kundenspezifischen Produkten; d.h. umso mehr unterschiedliche Produkte können durch die Ausnutzung der Variationspunkte entwickelt werden. 2.3 Merkmale Die Software-Produktlinie verfügt über solche folgenden Merkmale: Die Software-Produktlinie ist die höchste Stufe der Wiederverwendung. Im Vergleich zu der früheren kleinkörnigen Wiederverwendung werden alle Core Assets zur Wiederverwendung konzipiert und zur Anwendung in mehreren Systemen optimiert.[3] Die Core Assets sind hier die Anforderungen, Domänenmodelle, Software- Architektur, Performance-Modelle, Testfälle und Komponenten u.s.w. gemeint. Früher hängt die Generierung der neuen Systeme von der Änderung der alten vorhandenen Systeme ab. Diesen Ansatz nennt man clone and own 6. Im Gegensatz dazu zielt die Software-Produktlinie darauf ab, im selben Core Asset mehrere Systemen aufzubauen. Im Rahmen der Software-Produktlinie wird das Core Asset für Wiederverwendung speziell entworfen und die Produktlinie wird als eine ganze Einheit betrachtet. In den ausgereiften Produktlinien findet man das Konzept der mehreren Produkten nicht mehr. Jeder Produkt dient als einen Extrakt des Core Assets und nur das Core Asset wird sorgfältig mit der Zeit entwickelt und verbessert.[3] Der wesentliche Unterschied zwischen der traditionellen Single-System-Entwicklung und der Software Produktlinienentwicklung liegt in der Verschiebung des Schwerpunkts: Von einem individuellen Projekt zu der Produktlinie, von einem bestimmten Projekt zu einem bestimmten Geschäftsbereich.[3] 2.4 Drei Notwendigen Bestandteile der Software Produktlinie 6 Clone-and-Own bezeichnet die Vorgehensweise,dass die Implementierung von Produktvarianten, basierend auf einer Codekopie mitmanueller Anpassung ist.

3 Software Produktlinie besteht aus drei notwendigen Aktivitäten, nämlich Core Asset Entwicklung, Produktntwicklung und Management.[3] Die variablen Kombinationen der drei Aktivitäten führen zu den vielen Möglichkeiten der Anwendung der Software- Produktlinie. Ein proaktiver Ansatz ist so, dass eine Software- Produktlinie erstens durch den Aufbau von Core Asset eingeführt wird. Darüber hinaus kann man auch mit einigen vorhandenen Produkten anfangen, die als Grundlage des Core Assets dienen. Die weiteren Produkte werden darauf generiert. Diesen Ansatz heißt man reaktiv. In den beiden Fällen lassen sich die Core Asset Schritt für Schritt mit der graduellen Steigerung entwickeln, und zwar kann man vor allem die wichtigste Core Asset gründen, auf der die anfänglichen Produkte entwickelt werden. Sobald das Core Asset bereichert wird, steht es auch den weiteren Produkten zur Verfügung.[3] 2.5 Vorteile der Software-Produktlinie Von Erfahrungen ausgehend bietet der Einsatz von Software- Produktlinie die folgenden Vorteile: Figure 1: Drei Notwendigen Bestandteile Der Software Produktlinie[3] Entwicklung des Core Assets Die Entwicklung des Core Assets ist die wichtigste Aspekt in Software Produktlinien. Hier wird das Core Asset nicht nur das Programm-Code gemeint, sondern auch die Anforderungen, die Architekturbeschreibungen, die Spezifikationen und die Testfälle etc. Das Core Asset stellt die Grundlage für die Herstellung von Produkten, aber man sieht häufig, dass das Core Asset nur teilweise in mehreren Produkten Anwendung findet.[3] Produktentwicklung Im Vergleich mit der traditionellen Software-Entwicklung wird die Produktentwicklung in Software Produktlinien leichter, denn es geht nur um Zusammenbau von Core Assets. In diesem Prozess werden die Anforderungen modelliert, die nur für eine konkrete Produktvariante gelten. Danach fangen die Entwicklerteams an, die passenden Bestandteile des Core Assets für die Realisierung des Produktes auszuwählen. Falls das Core Asset manche bestimmten Funktionen nicht anbieten kann, ist es dann notwendig, die fehlenden Funktionen zu ergänzen.[3] Management Im Managementprozess wird die gesamte Entwicklung der Produktlinie gesteuert und überwacht, damit eine adäquate Ressourcenverteilung zwischen den beiden anderen Entwicklungsprozessen erfüllt wird.[3] Wie in der Abbildung 1 gezeigt wird, baut man die neuen Produkte auf der Basis des Core Assets auf. Dabei lässt sich das Core Asset auch von vorhandenen Produkten extrahieren. Das Core Asset ändert sich mit der Zeit. Alle drei Aktivitäten sind ineinander verflochten und bestehen in ständiger Bewegung. In jeder Software-Produktlinie sind sie notwendig, untrennbar, interaktiv und treten in beliebige Reihenfolge auf.[3] Produktivitätssteigerung Dies ist genau der größte Vorteil der Software-Produktlinie. Mit dem Einsatz der Software-Produktlinie wird die komplizierte und beschwerliche Programmierung durch die eher einfache Konfiguration des Core Assets substituiert.[5](s. 11) In dieser Hinsicht werden die Unternehmen dadurch befähigt, in kurzer Zeit eine Reihe Produkte mit Varianz aber auch Homogenität (wie wir heute die umfangreichen Komponenten von Microsofts Office-Suiten sehen) herzustellen, um eine größere Marktanteile zu gewinnen Verringerung der Markteinführungszeit Figure 2: Markteinführungszeit Mit Und Ohne SPL[5](S. 11) Wie allgemein bekannt im IT-Bereich, wer zuerst das Produkt auf dem Markt bringt, gewinnt den Vorsprung. Deswegen legt man den großen Wert auf die Markteinführungszeit, und bemüht sich mit äußerster Kraft sie zu verkürzen. Wie in der Abbildung 2 dargestellt wird, nehmen wir in der Entwicklung von einzelnen Systemen an, dass die Markteinführungszeit konstant ist. Aber im Vergleich zu der traditionellen einzelnen Programmierung nimmt die Entwicklung der Software-Produktlinie normalerweise in der Angangsphase mehr Zeit in Anspruch, damit die Core Assets komplett aufgebaut werden. Aber die deutliche Erhöhung der Leistungsfähigkeit findet man danach mit Ausdehnung der Software-

4 Produktlinie, weil viele Artefakte zur Entwicklung der neuen Produkte wiederverwendet werden können.[5](s. 11) Kostenreduzierung Figure 3: Kostenvergleich[5](S. 11) Die Software-Produktlinie verwendet die massive Wiederverwendung, um Kosten zu senken, aber die Vorteile sind nicht kostenfrei, man muss vor allem die Voraussetzung schaffen. Wie in der Abbildung 3 gezeigt wird, nur wenn die Zahl der Produkte 3 bis 4 beträgt, erreicht man erst den Gleichgewichtspunkt. Das heißt, dass die Produktionskosten mit Anstieg der Produktmenge stark reduziert werden. Deswegen ist es zu bedenken, dass die Entscheidung zum Einsatz der Software-Produktlinie von der Produktmenge fest abhängt.[5](s. 9f) Andere Diese oben genannten Vorteile sind die drei wichtigsten Aspekten, wie die Software-Produktlinie die Entwicklung und Produktion der Software im großen Maß positiv beeinflusst. Natürlich gibt es andere Vorteile, die man nicht übersehen kann, wie die Erhöhung der Produktqualität. Denn die Artefakte der Produktlinie werden in der Wiederverwendung mehrmals überprüft, so dass die Fehler sich schwer verschleiern lassen. Außerdem setzt die Wiederverwendung die User Experience herauf, indem die Homogenität der verschiedenen Produkte mit Anwendung der Software-Produktlinie gut bewahrt wird, was gleichzeitig zur erhöhten Nutzungszufriedenheit führen kann.[5](s. 11f) 3. VORAUSSETZUNGEN DER UMSETZUNG 3.1 Voraussetzungen Zurzeit besteht die Software-Produktlinie noch in der Anfangsphase. Um sie besser auszunutzen, muss man die Voraussetzungden der Anwendung in Betracht nehmen. Und tatsächlich geht der Erfolg des Produktlinienansatzes mit neuen Lösungen und Technologien einher Technische Durchführbarkeit Die erste Hinderung zur Durchführung der Software Produktlinie liegt an dem Mangel an geeigneten Technologien für die Anwendung der Prinzipien der Produktlinienentwicklung auf einfache Weise. Heutzutage werden viele Programme in prozeduralen Programmiersprache geschrieben. Aber in der prozeduralen Programmiersprache ist die Verkapselung und Information hiding 7 schwer zu erreichen. Die Verkapselung ist die Voraussetzung für Variabilitätsmanagement. In der Praxis besteht derzeit eine Fokussierung auf die Verwendung von Komponententechnologien in Verbindung mit objektorientierter Programmierung, die diese Barriere mit der Unterstützung von anerkannten Design-Prinzipien wie die objektorientierte Modellierung und Programmierung- Theorie entschärft.[5](s. 16) Die Prozessreife Die Unerfahrenheit in der Software-Entwicklung kann auch auf die Umsetzung der Software-Produktlinie negativ einwirken. Der Software-Entwicklungsprozess, der früher unstrukturiert, kaum gut definiert, und auch nicht gut verstanden ist, wird mit Einführung der Prozessmodelle wie CMMI 8 verbessert. Das Prozessmodell leistet zur Identifizierung der schwachen Teilen der Software-Entwicklungsprozesse einen wertvollen Beitrag. Außerdem ist es zu bedenken, dass die unzureichende Requirements Engineering eine der Hauptursache für Probleme in Software-Projekten. Die komplette Requirements Engineering beinhalten Identifikation von Gemeinsamkeiten und Variabilität, die genau als hauptsächliche Voraussetzung der Software-Produktlinie gelten.[5](s. 17) Domain-Eigenschaften und Expertise Des Weiteren ist die Erfahrung in den bestimmten Domain von großer Bedeutung. Nur wenn man die Märkten und Kunden auskennt, kann die Gemeinsamkeiten und Variabilität in angemessener Weise für Entwicklung der Plattformen und Produkten identifiziert werden. Die Unwissenheit in der betreffenden Domain führt zur falschen Abstraktionen und Verstehen, sodass die Entwickler nicht sofort bemerken könnnen und nur danach die Fehler reparieren müssen.[5](s. 17f) 3.2 SEI-Methode Nach der Meinung von der Universität Carnegie Mellon muss man vor allem die drei wesentlichen Aktivitäten, nämlich Entwicklung des Core Assets, Produktentwicklung und Management, erfüllen, um eine Software-Produktlinie zu realisieren(siehe Abbildung 1). Dazu sind die Voraussetzungen zur Durchführung der drei wesentlichen Aktivitäten von großer Bedeutung. Im Folgenden wird die SEI Entwicklungsmethode der Universität Carnegie Mellon charakterisiert. Um die Umsetzung der Software-Produktlinie in der Praxis zu ermöglichen, SEI stellt 29 relevanten praktischen Anwendungsbereichen(siehe Abbildung 4) (Architecture Definition, Architecture Evaluation, Component Development, Mining 7 Verkapselung und Information hiding ist eine Merkmale von Objektorientierter Programmiersprache, bedeutet in der Programmierung das Verbergen von Daten oder Informationen vor dem Zugriff von außen. 8 Das Capability Maturity Model Integration (kurz CMMI) ist eine Familie von Referenzmodellen für unterschiedliche Anwendungsgebiete derzeit für die Produktentwicklung, den Produkteinkauf und die Serviceerbringung. Ein CMMI- Modell ist eine systematische Aufbereitung bewährter Praktiken, um die Verbesserung einer Organisation zu unterstützen.

5 Figure 4: 29 Anwendungsbereichen[2] Existing Assets, Requirements Engineering, Software System Integration, Testing, Understanding Relevant Domains, Using Externally Avallable Software, Configuration Management, Make/Buy/Mine/Commission Analysis, Measurement und Tracking, Process Discipline, Scoping, Technical Planning, Technical Risk Management, Tool Support, Building a Business Case, Customer Interface Management, Developing an Acquisition Strategy, Funding, Launching and Institutionalizing, Market Analysis, Operations, Organizational Risk Management, Structuring the Organization, Technology Forecasting, Training). Der Anwendungsbereich ist die Ansammlung der Aktivitäten, die für die erfolgreiche Durchführung der drei wesentlichen Aktivitäten in der Software Produktlinie notwendig sind. Der Anwendungsbereich macht die wesentlichen Aktivitäten mehr erreichbar durch Festlegung von den Aktivitäten, die kleiner und besser lenkbar als eine unklare Aktivität wie z.b. Ëntwicklung des Core Assetsßind. Der Anwendungsbereich bietet auch die Ansatzpunkte, von denen die Entwickler bei der Annahme eines Produktlinienansatzes den Projetkszeitplan leicht kontrollieren können.[3] Eigentlich spielen diese 29 Anwendungsbereichen eine große Role nicht nur in der Software-Produktlinie, sondern auch in der traditionellen Entwicklung. Die 29 Anwendungsbereichen sind in drei Kategorien unterteilt, nämlich Software-Engineering, Technik-Management und Organisation-Management.[3] Software-Engineering Software-Engineering bezeichnen die Tätigkeiten, die notwendig für Anwendung der Technologie zur Schaffung und Entwicklung der Plattformen und Produkten. Dazu zählen z.b. Architekturentwicklung, Requirements Engineering, Komponenten-Entwicklung und Testen.[3] Der schwierigste Teil im Aufbau eines Software-Systems ist zu entscheiden, was für eine Software produziert werden soll. Die Anforderungen dient zur Beschreibung darüber, was das System tun muss, wie es sich verhalten muss, welche Eigenschaften es aufweisen muss, welche Qualität es besitzen muss, und welche Randbedingungen, die das System erfüllen muss. Das Requirements Engineering betont die Verwendung von den systematischen und wiederverwendbaren Techniken, die die Vollständigkeit und Konsistenz der Systemsanforderungen gewährleistet. Genauer gesagt umfasst das Requirements Engineering Anforderungserhebung, Analyse, Spezifikation, Verifikation und Management.[3] Die Architektur ist ein wichtiges Artefakt, wenn man über die Qualitätsziele des Systems(wie beispielsweise Sicherheit, Zuverlässigkeit, Benutzerfreundlichkeit, Änderbarkeit und Echtzeit-Performance)spricht. Mittlerweile ist die Architektur auch eine Kommunikationsbrücke für alle Teilnehmenden: Entwickler, Manager, Betreuer, Benutzer, Kunden, Tester, Vermarkter, und alle anderen, die ein Interesse über die Entwicklung und Nutzung des Systems haben.[3] Eine der Aufgaben des Software-Architekten ist es, die Liste der Komponenten entsprechend der Architektur zu produzieren. Die Komponenten werden als Einheiten in der Software intergriert, um ein ganzes System

6 zusammenzubauen.[3] Die Testen haben zwei Hauptfunktionen. Zum Ersten wird der Fehler identifiziert, die zum Ausfällen geführ haben, so dass sie sich reparieren lassen. Zum Zweiten ist zu bestimmen, ob die zu testende Software nach der festgelegten Anforderungen durchführen können. Mittlerweile bleibt der Test aktiv im gesamten Lauf des Entwicklungsprozesses. Schließlich werden einige Artefakte produziert: Testfälle, Testdokumente, Testdatensätze.[3] Technik-Management Technik-Management sind die organisatorische Aktivitäten, die die Schaffung und Entwicklung der Plattformen und Produkten verwalten, wie beispielsweise Risikomanagement, Projektplannung, Scoping oder Konfigurationsmanagement.[3] Das wichtigste Ziel des Risikomanagements ist, Risiken zu vermeiden. Das Software-Projektrisiko besteht in der Budget- und Zeitkontrolle in der Software Entwicklung und andere Aspekte, die sich negativ auf das Projekt auswirkt. Wenn die Projektrisiken auftreten, können sie den Fortschritt des Projekts beeinflussen, die Kosten des Projekts erhöhen, und sogar zum Scheitern des Projekts führen.[3] Das Scoping ist eine Aktivität, die ein System oder eine Menge von Systemen begrenzt, durch Bestimmung aller Verhalten oder Aspekte, die zum System gehören oder nicht gehören. Kurz gesagt beantwortet das Scoping die Frage Welche Produkte sollten in meiner Software-Produktlinie inklusiv sein? [3] Organisation-Management Das Organisation Management zielt auf die Instrumentierung der gesamten Software Produktlinie ab. Sie bezeichnen betriebswirtschaftliche Aufgaben, zu denen beispielsweise Marktanalyse, Organisationsplanung, Geschäftsmodellentwicklung oder Training gehören. Sie werden u.a. zur Einführung und Evolution der Produktlinieentwicklung im Unternehmen benötigt.[3] Da die Märkte sich ständig verändert, sollte eine Marktanalyse ein lebendiges Dokument sein. Basierend auf dieser Analyse kann ein Business-Fall, eine Strategie oder ein Plan entwickelt werden. Das Ziel der Marktanalyse ist, die grundsätzliche Frage zu beantworten. Kann der Markt das ausreichende wirtschaftliche Potenzial für uns anbieten, um unsere Unternehmensziele mit diesem Produkt zu erreichen?[3] In der Organisationsplanung geht es um die Plannung auf der strategischen und organisatorischen Ebene. Das Training ist das Kerngeschäft von der Software Entwicklungsorganisation. Der Zweck ist, die Fähigkeiten und Kenntnisse zu liefern, die für das Software Management und die technischen Aufgaben erforderlich sind.[3] Die SEI-Methode beschreibt Tätigkeiten auf einem abstrakten Niveau und kann an unterschiedliche Prozesse angepasst werden. 3.3 Sonderfälle Außerdem muss man nicht übersehen, dass es auch die Sonderfälle gibt, wobei die Software Produktlinie nicht geeignet in Anwendung finden kann. Beispeisweise wird nur die einzige Version von den Kunden angefordert. Oder das läufige Projekt unterscheidet sich ganz und gar von dem ehemaligen, das heißt, dass die Geschäftsbereiche verändert werden. Darüber hinaus gibt es auch die Möglichkeit, dass das Projekt sich an der Spitze der Innovation befindet, und alle Projekte sollen von Grund auf völlig neu entwickelt werden. In diesen Fällen eignet die Software-Produktlinie sich nicht für die Entwicklung.[6](S. 305) 4. GRUNDLAGEN DES SOFTWARE PRO- DUKTLINIE ENGINEERINGS 4.1 Software Produktlinie Engineering Das Software Produktlinie Engineering bezieht sich auf die Engineering und Management Methode, um eine Software Produktlinie zu erstellen, zu entwickeln und zu erhalten. Im Rahmen der Software Produktlinienentwicklung werden die zwei Begriffe unterschieden, nämlich Entwickung für Wiederverwendung und Entwicklung mit Wiederverwendung. Wie in der Abbildung 5 gezeigt wird, dass Software Produktlinie Engineering aus zwei Prozessen besteht, nämlich Domain Engineering (Entwickung für Wiederverwendung) und Application Engineering (Entwicklung mit Wiederverwendung).[6](S. 6f) Domain Engineering Im Domain Engineering wird die Grundlage für die Gemeinsamkeit und Variabilität zur Entwicklung der Produkte hergestellt. Das Hauptziel von Domain Engineering ist, das Core Asset zu generieren.[5](s. 20f) Aber man muss beachten, dass die verschiedenen Assets mehrdeutige Variabilität enthalten. Zum Beispiel kann eine Darstellung der Anforderungen eine explizite Beschreibung der spezifischen Anforderungen enthalten, die nur für eine bestimmte Untergruppe der Produkte gelten. In der Regel enthält das Domain Engineering die meisten Funktionen, die für ein neues Produkt erforderlich sind. Zu dem Domain Engineering gehören fünf Subprozessen: Product Management, Domain Requirements Engineering, Domain Design, Domain Realisation und Domain Testing.[5](S. 21) Product Management: Das Produktmanagement befasst sich mit den wirtschaftlichen Aspekten der Software-Produktelinie und vor allem mit der Marktstrategie. Die Scoping Technologie wird dazu verwendet, um den Umfang der Produktlinie zu definieren. Der Einsatz des Produkt Managements stammt aus den oberen Schichten des Unternehmens, um das Geschäftsziel zu setzen.[5](s. 24) Domain Requirements Engineering: Der Domain-Requirements-Engineering Subprozess umfasst alle Aktivitäten zur Auslösung und Dokumentation der gemeinsamen und variablen Anforderungen an die Produktlinie. Domain Requirements Engineering unterscheidet sich von Requirements Engineering für

7 Figure 5: Rahmen Von Software Produktlinie Engineering[5](S. 22) Einzelsystem, denn das Domain Requirements Engineering sich gegen die allgemeine Anforderungen richtet.[5](s. 25) Domain Design: Der Domain-Design Subprozess umfasst alle Aktivitäten zur Definition der Referenzarchitektur der Produktlinie, die eine gemeinsame High-Level-Struktur für alle Produktlinie-Anwendungen anbietet.[5](s. 26) Domain Realisation: Der Domain-Realisierung Subprozess befasst sich mit der detaillierten Konzeption und Umsetzung der wiederverwendbaren Software-Komponenten.[5](S. 27) Domain Testing: Der Domain-Testing Subprozess sorgt für die Validierung und Verifizierung der wiederverwendbaren Komponenten. Der Domain-Testing überprüft die Spezifikationen der Komponenten, d.h. Anforderungen, Architektur und Design-Artefakte. Des Weiteren entwickelt der Domain-Testing die Test-Artefakte zur Reduzierung des Aufwands für Application-Testing.[5](S. 27) Applicaition Engineering Im Application Engineering wird die Produkte auf der Basis, die im Prozess von Domain Engineering gestellt wird, endlich erzeugt. Der Prozess Applicaition Engineering fokussiert auf die Variabilität der Produkte, um die speziellen Anforderungen an verschiedenen Produkten zu befriedigen. Zu dem Application Engineering Prozess zählen vier Subprozessen: Application Requirements Engineering, Application Design, Application Realisation, Application Testing.[5](S. 31) Application Requirements Engineering: Der Application-Requirements-Engineering Subprozess umfasst alle Aktivitäten zur Entwicklung der Anforderungsspezifikation der Anwendungen(Application). Die wiederverwendbare Anzahl der Domain Artefakte ist von den Anwendungsanforderungen abhängig.[5](s. 31f) Application Design: Der Application-Design Subprozess umfasst die Aktivitäten zur Herstellung der Anwendungsarchitektur. Application-Design verwendet die Referenzarchitektur, um die Anwendungsarchitektur zu instanziieren. Dabei werden die benötigte Teile der Referenzarchitektur ausgewählt und anwendungsspezifisch konfiguriert. Die mit Application-Design gebunden Variabilität bezieht sich auf die Gesamtstruktur des Systems.[5](S. 32) Application Realisation: Im Application-Realisation Subprozess wird die konkreten Produkten hergestellt. Der beschäftigt sich hauptsächlich mit der Auswahl und Konfiguration der wiederverwendbaren Software-Komponenten sowie die Verwirklichung von anwendungsspezifischen Assets. Die wiederverwendbaren und anwendungsspezifischen Assets werden hier zusammengebaut.[5](s. 33) Application Testing: Der Application-Testing Subprozess umfasst die erfor-

8 derlichen Aktivitäten, die zur Verifizierung und Überprüfung der Anwendung der Produkte dienen.[5](s. 34) Practice in Product Line Engineering. Springer, Berlin Heidelberg, Prinzipien Die folgenden vier Prinzipien sind die Grundlage für den Erfolg des Software-Produktlinien-Engineerings. Variabilität Management Die einzelnen Produkte werden als Varianten im Rahmen der Produktlinie betrachtet. Damit stellt die Anforderung, dass die Variabilität explizit gemacht und systematisch verwaltet werden muss.[6](s. 7) Business-Orientierung Software Produktlinie Engineering zielt darauf ab, sich mit der langfristigen Unternehmensstrategie zu verbinden.[6](s. 8) Architektur-Orientierung Die technische Aspekte der Software müssen auf die Vorteile der Gemeinsamkeit der einzelnen Produkten basieren.[6](s. 8) Zwei-Lebenszyklus-Ansatz Die einzelnen Systeme basieren auf einem Software- Plattform. Aber gleichzeitig müssen diese Systeme und die Plattform ihre eigenen individuellen Lebenszyklen aufrechterhalten.[6](s. 8) 5. FAZIT Angesichts der hohen Anforderungen sollen die heutigen Softwaresysteme immer leistungsfähiger, zuverlässiger, komplexer, gleichzeitig aber immer günstiger in Produktion und Wartung sowie schneller in Entwicklung und Auslieferung werden. Die Software-Produktlinie gehört zu einen der leistungsfähigeren Ansätze der Wiederverwendung. Das Konzept bedeutet nicht nur eine neue Technologie, sondern eine Art Entwicklung der Software-Business. Dazu gibt es wesentliche Aktivitäten der Produktlinie und praktische Anwendungsbereiche, um die Steuerung und Verwaltung der Software-Produktlinie zu ermöglichen. 6. REFERENCES [1] P. Clements. Reuse and product lines. ftp/wisr/wisr8/wisr8- summary/product.html, December [2] L. M. Northrop. Software product lines essentials. December [3] L. M. Northrop and P. C. Clements. A framework for software product line practice, version report/index.html., December [4] O.A. Feature-oriented software development. February [5] K. Pohl, G. Böckle, and F. van der Linden. Software Product Line Engineering: Foundations, Principles, and Techniques. Springer, Berlin Heidelberg, [6] F. van der Linden, K. Schmid, and E. Rommes. Software Product Lines in Action: The Best Industrial

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

Softwarefamilien und Produktlinien - systematische Wiederverwendung - Matthias Clauß Intershop Research & TU Dresden

Softwarefamilien und Produktlinien - systematische Wiederverwendung - Matthias Clauß Intershop Research & TU Dresden Softwaretechnologie Softwarefamilien und Produktlinien - systematische Wiederverwendung - Matthias Clauß Intershop Research & TU Dresden Einleitung Was würden Sie machen, wenn Ihr Auftraggeber oder Chef

Mehr

Effiziente Softwareproduktion durch. Effiziente Softwareproduktion durch

Effiziente Softwareproduktion durch. Effiziente Softwareproduktion durch tze Dr. Klaus Schmid Universität Hildesheim Fachbereich III: Informations- und Kommunikationswissenschaften Institut für Mathematik und Angewandte Informatik schmid@sse.uni-hildesheim.de Inhalt 1. Motivation

Mehr

CMMI und SPICE im Automotive Umfeld

CMMI und SPICE im Automotive Umfeld Vorträge 2006 CMMI und SPICE im Automotive Umfeld Inhalt Motivation Übersicht zu CMMI Anwendung in Entwicklungsprojekten Prozess Management als Lösungsansatz SPICE Motivation Jährliche Kosten für Prozessverbesserung

Mehr

Software-Produktlinien

Software-Produktlinien Software-Produktlinien Methoden, Einführung und Praxis von Günter Böckle, Peter Knauber, Klaus Pohl, Klaus Schmid 1. Auflage Software-Produktlinien Böckle / Knauber / Pohl / et al. schnell und portofrei

Mehr

Vom Projekt zum Produkt durch Produktlinien und Variantenmanagement

Vom Projekt zum Produkt durch Produktlinien und Variantenmanagement om Projekt zum Produkt durch Produktlinien und ariantenmanagement Kim Lauenroth paluno the Ruhr Institute for Software Technology Universität Duisburg-Essen Gerlingstraße 16 45127 Essen kim.lauenroth@paluno.uni-due.de

Mehr

PM-Forum Augsburg. Thomas Müller-Zurlinden, PMP 18.05.2012. Kontakt: Info@QinS.de

PM-Forum Augsburg. Thomas Müller-Zurlinden, PMP 18.05.2012. Kontakt: Info@QinS.de PM-Forum Augsburg Thomas Müller-Zurlinden, PMP 18.05.2012 Kontakt: Info@QinS.de Einführung in die Konzepte der Software Product Line Organisation einer globalen SPL Entwicklung SPL und die Herausforderungen

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

Phasen. Gliederung. Rational Unified Process

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

Mehr

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

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

Mehr

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

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

Transfer von Prozessen des Software-Produktlinien Engineering in die Elektrik/Elektronik- Architekturentwicklung von Fahrzeugen

Transfer von Prozessen des Software-Produktlinien Engineering in die Elektrik/Elektronik- Architekturentwicklung von Fahrzeugen Transfer von Prozessen des Software-Produktlinien Engineering in die Elektrik/Elektronik- entwicklung von Fahrzeugen Martin Jaensch, Dr. Bernd Hedenetz, Markus Conrath Daimler AG Prof. Dr. Klaus D. Müller-Glaser

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

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

Softwareprozesse systematisch verbessern ISO15504(SPICE) und Automotive SPICE. Heinrich Dreier Elmshorn 17.04.2008

Softwareprozesse systematisch verbessern ISO15504(SPICE) und Automotive SPICE. Heinrich Dreier Elmshorn 17.04.2008 Softwareprozesse systematisch verbessern ISO15504(SPICE) und Automotive SPICE Heinrich Dreier Elmshorn 17.04.2008 Einleitung Softwareprozesse verbessern Einleitung Softwareprozesse verbessern SPI Software

Mehr

ISO 9001 und CMM im Vergleich

ISO 9001 und CMM im Vergleich ISO 9001 und CMM im Vergleich internationale Norm ISO 9001 umfasst 20 Forderungen/ Klauseln 1 Vorbereitung Audit Wie wird zertifiziert Wie erfolgt Dokumentation? Handbuch (QMH) Verfahrensanweisungen (QMV)

Mehr

A Platform for Complex Event Processing

A Platform for Complex Event Processing A Platform for Complex Event Processing Einführung Business Process Technology Prof. Dr. Mathias Weske Matthias Kunze Nico Herzberg Business Process Technology Seit 2001 Untersuchung realer Probleme des

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

Variantenkonfiguration von Modellbasierter Embedded Automotive Software

Variantenkonfiguration von Modellbasierter Embedded Automotive Software Model-Driven Development & Product Lines Leipzig, 19. Oktober 2006 Jens Weiland DaimlerChrysler AG (GR/ESS) Die Rolle von Varianten für den Bereich Automotive Vielzahl variabler Funktionen Beispiel Mercedes

Mehr

Benutzbare Produktlinien

Benutzbare Produktlinien Benutzbare Integration von und aspekten in der Anforderungsanalyse Isabel John, Kirstin Kohler, Klaus Schmid Erlangen November 2003 Fraunhofer Institut Experimentelles Software Engineering Sauerwiesen

Mehr

PQ4Agile Agiler Referenzprozess

PQ4Agile Agiler Referenzprozess PQ4Agile Agiler Referenzprozess ARBEITSPAKET 1.1 KONSORTIUM Projekt Förderprogramm PQ4Agile KMU Innovativ Förderkennzeichen 01IS13032 Arbeitspaket Fälligkeit 31.07.2014 Autor Status Klassifikation AP1.1

Mehr

Model-based ALM Arbeitsumgebungen à la carte

Model-based ALM Arbeitsumgebungen à la carte Model-based ALM Arbeitsumgebungen à la carte Insight 2013, Nürnberg November 2013 Jens Donig, Dr. Martin Künzle Agenda 01 Einleitung 02 Model-based ALM 03 Demo 04 Lernende Plattform November 2013 Jens

Mehr

Requirements Engineering im SPL-Umfeld

Requirements Engineering im SPL-Umfeld Requirements Engineering im SPL-Umfeld Manuel Wörmann 16.02.2015 Requirements Engineering im SPL-Umfeld Inhalt 1. Definition 2. Ziele 3. Domain Requirements Engineering 4. Application Requirements 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

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

I. Pflege und Wiederverwendung von Anwendungssoftware-Systemen

I. Pflege und Wiederverwendung von Anwendungssoftware-Systemen I. Pflege und Wiederverwendung von Anwendungssoftware-en SE 2006: Projektvorschläge Fraunhofer IESE PRE Park, Kaiserslautern 19. Januar 2005 IESE Fraunhofer Institut Experimentelles Software Engineering

Mehr

Anforderungsermittlung und Testmanagement im V-Modell die integrierte Lösung Andreas Plette (Telelogic) - Andreas Reuys (SQS)

Anforderungsermittlung und Testmanagement im V-Modell die integrierte Lösung Andreas Plette (Telelogic) - Andreas Reuys (SQS) Anforderungsermittlung und Testmanagement im V-Modell die integrierte Lösung Andreas Plette (Telelogic) - Andreas Reuys (SQS) 1 Agenda 12:30 13:00 Begrüßung & Vorstellung 13:00 13:45 Einführung Motivation

Mehr

Human Capital Management

Human Capital Management Human Capital Management Peter Simeonoff Nikolaus Schmidt Markt- und Technologiefaktoren, die Qualifikation der Mitarbeiter sowie regulatorische Auflagen erfordern die Veränderung von Unternehmen. Herausforderungen

Mehr

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Andreas Ditze MID GmbH Kressengartenstraße 10 90402 Nürnberg a.ditze@mid.de Abstract: Data Lineage

Mehr

Model Driven Architecture Praxisbeispiel

Model Driven Architecture Praxisbeispiel 1 EJOSA OpenUSS CampusSource Model Driven Architecture Praxisbeispiel 2 Situation von CampusSource-Plattformen Ähnliche Funktionen (Verwaltung von Studenten und Dozenten, Diskussionsforen,...), jedoch

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

Ü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

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

Di 4.1. Variabilitätsmanagement in der Software-Produktlinienentwicklung. Kim Lauenroth

Di 4.1. Variabilitätsmanagement in der Software-Produktlinienentwicklung. Kim Lauenroth Di 4.1 January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich ariabilitätsmanagement in der Software-Produktlinienentwicklung Kim Lauenroth ariabilitätsmanagement in der The key

Mehr

Requirements-Engineering und -Management in Produktmanagement und Produktlinien-Entwicklung

Requirements-Engineering und -Management in Produktmanagement und Produktlinien-Entwicklung s-engineering und -Management in Produktmanagement und Produktlinien-Entwicklung Überblick und Standortbestimmung Dr. Andreas Birk Jahrestreffen der GI-Fachgruppe s Engineering, Berlin 30. November 2007

Mehr

Der BPM-Lebenszyklus in Theorie und Praxis. Prof. Dr. Mathias Weske

Der BPM-Lebenszyklus in Theorie und Praxis. Prof. Dr. Mathias Weske Der BPM-Lebenszyklus in Theorie und Praxis Prof. Dr. Mathias Weske Hasso Plattner Institut 2 An-Institut der Universität Potsdam, aus privaten Mitteln von SAP- Gründer Hasso Plattner finanziert Bachelor

Mehr

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

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

Mehr

Jazz Rational Team Concert. InfoPoint, 10. Juni 2009 Silver Scherrer

Jazz Rational Team Concert. InfoPoint, 10. Juni 2009 Silver Scherrer Jazz Rational Team Concert InfoPoint, 10. Juni 2009 Silver Scherrer Inhalt Was ist Jazz? Mehrwert von Jazz Jazz Community Rational Team Concert Rational Team Concert Funktionalität Screenshots, Demo Fazit

Mehr

Application Lifecycle Management (ALM) für Software Engineering Professionals Fundierte Methoden und bewährt Praktiken aus der IT Industrie

Application Lifecycle Management (ALM) für Software Engineering Professionals Fundierte Methoden und bewährt Praktiken aus der IT Industrie Application Lifecycle Management (ALM) für Software Engineering Professionals Fundierte Methoden und bewährt Praktiken aus der IT Industrie Motivation Die Leistungsmerkmale unserer Produkte und Dienstleistungen

Mehr

Empirische Evidenz von agilen Methoden. Seminar in Software Engineering Wintersemester 03/04

Empirische Evidenz von agilen Methoden. Seminar in Software Engineering Wintersemester 03/04 Empirische Evidenz von agilen Methoden Seminar in Software Engineering Wintersemester 03/04 Agenda Einleitung Bedeutung von agil Kurzübesicht agiler Methoden Überprüfung des (agilen) Erfolges Ausgewählte

Mehr

Seminar Neue Ansätze der Softwarequalitätssicherung : Verfolgbarkeit von Variabilität in Software-Produktlinien (Version 0.9)

Seminar Neue Ansätze der Softwarequalitätssicherung : Verfolgbarkeit von Variabilität in Software-Produktlinien (Version 0.9) Seminar Neue Ansätze der Softwarequalitätssicherung : Verfolgbarkeit von Variabilität in Software-Produktlinien (Version 0.9) Christoph Oberhokamp Franz-Hitze Str. 27, 33102 Paderborn co1@upb.de Abstract.

Mehr

Seminar Neue Ansätze der Softwarequalitätssicherung : Verfolgbarkeit von Variabilität in Software-Produktlinien

Seminar Neue Ansätze der Softwarequalitätssicherung : Verfolgbarkeit von Variabilität in Software-Produktlinien Seminar Neue Ansätze der Softwarequalitätssicherung : Verfolgbarkeit von Variabilität in Software-Produktlinien Christoph Oberhokamp Franz-Hitze Str. 27, 33102 Paderborn co1@upb.de Abstract. Software-Produktlinien

Mehr

Inhaltsverzeichnis. 1 Einleitung 1. 2 Einführung und Grundlagen 7

Inhaltsverzeichnis. 1 Einleitung 1. 2 Einführung und Grundlagen 7 xv 1 Einleitung 1 2 Einführung und Grundlagen 7 2.1 Die neue Rolle der IT...................................... 7 2.2 Trends und Treiber........................................ 8 2.2.1 Wertbeitrag von

Mehr

Softwareanforderungsanalyse

Softwareanforderungsanalyse Softwareanforderungsanalyse Evolution von Anforderungen Burkhardt Renz Institut für SoftwareArchitektur der Technischen Hochschule Mittelhessen Wintersemester 2015/16 Evolution von Anforderungen Anforderungen

Mehr

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Agile Methoden als Diagnose-Tool für den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Über mich Berufliche Erfahrung 3 Jahre Projektabwicklung 2 Jahre

Mehr

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

Maturity Assesment for Processes in IT

Maturity Assesment for Processes in IT Maturity Assesment for Processes in IT Was ist MAPIT? Maturity Assessment for Processes in IT Werkzeug zur Reifegradbestimmung von IT Service Management Prozessen hinsichtlich ihrer Performance und Qualität

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

Modellgetriebene Softwareentwicklung

Modellgetriebene Softwareentwicklung Modellgetriebene Softwareentwicklung 30.10.2008 Dr. Georg Pietrek, itemis AG Inhalt Wer ist itemis? Modellgetriebene Entwicklung Ein Praxis-Beispiel Fazit 2 Vorstellung IT-Dienstleister Software-Entwicklung

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

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

*instinctools und DITAworks stellen sich vor

*instinctools und DITAworks stellen sich vor Experts in Information Management Solutions and Services *instinctools und DITAworks stellen sich vor instinctools GmbH Gunthilde Sohn November 2013 instinctools und DITAworks: Vorstellung *instinctools

Mehr

SPICE in der medizinischen Software-Entwicklung

SPICE in der medizinischen Software-Entwicklung SPICE in der medizinischen Software-Entwicklung MedConf 2012 Matthias Hölzer-Klüpfel Medical SPICE Medizinische Software Regulatorische Grundlagen Referenzmodell Medical SPICE Beispiele 1968: Software-Krise

Mehr

Informationssystemanalyse Requirements Engineering 10 1

Informationssystemanalyse Requirements Engineering 10 1 Informationssystemanalyse Requirements Engineering 10 1 Requirements Engineering Viele Probleme bei der Softwareentwicklung entstehen sehr früh im Entwicklungsprozeß. Im Rahmen des Requirements Engineering

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

4... SAP Solution Manager als Plattform für den End-to-End-Anwendungsbetrieb... 63

4... SAP Solution Manager als Plattform für den End-to-End-Anwendungsbetrieb... 63 ... Geleitwort... 15... Vorwort... 17... Einführung... 23 1... Was ist Run SAP?... 25 1.1... Motivation der Run SAP-Methodik... 27 1.2... Roadmap... 29 1.3... Run SAP-Phasen... 32 1.3.1... Assessment &

Mehr

IV Software-Qualitätssicherung

IV Software-Qualitätssicherung Softwaretechnik- Praktikum: 12. Vorlesung Jun.-Prof Prof.. Dr. Holger Giese Raum E 3.165 Tel. 60-3321 Email: hg@upb.de Übersicht I II III IV V Einleitung Ergänzungen zur Software-Entwicklung Software Management

Mehr

Softwareentwicklung und Application Lifecycle Management als Geschäftsprozess

Softwareentwicklung und Application Lifecycle Management als Geschäftsprozess Softwareentwicklung und Application Lifecycle Management als Geschäftsprozess Von David Chappell Gefördert durch die Microsoft Corporation 2010 Chappell & Associates David Chappell: Softwareentwicklung

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

TOGAF The Open Group Architecture Framework

TOGAF The Open Group Architecture Framework TOGAF The Open Group Architecture Ein Überblick Gesellschaft für Informatik, Regionalgruppe München Dr. Michael Bulenda München, 7.12.2009 Vorstellung Dr. M. Bulenda Seit 2001 bei Cirquent IT Management

Mehr

Add SPICE to your life! Dr. Jürgen Schmied, Jens Palluch method park Software AG. White Paper 08/2007. Seite 1 von 6

Add SPICE to your life! Dr. Jürgen Schmied, Jens Palluch method park Software AG. White Paper 08/2007. Seite 1 von 6 Add SPICE to your life! Dr. Jürgen Schmied, Jens Palluch method park Software AG White Paper 08/2007 Seite 1 von 6 Add SPICE to your life! Dr. Jürgen Schmied, Jens Palluch method park Software AG Einleitung

Mehr

Wir erledigen alles sofort. Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind.

Wir erledigen alles sofort. Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind. Wir erledigen alles sofort Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind. agilecoach.de Marc Bless Agiler Coach agilecoach.de Frage Wer hat

Mehr

Informationssystemanalyse People Capability Maturity Model 6 1

Informationssystemanalyse People Capability Maturity Model 6 1 Informationssystemanalyse People Capability Maturity Model 6 1 People Capability Maturity Model Neben dem CMM, welches primär zur Verbesserung des Entwicklunsprozesses eingesetzt wird, existiert mit dem

Mehr

CMMI Der Weg zur erfolgreichen Softwareorganisation CMMI & SPA (Siemens Process Assessment)

CMMI Der Weg zur erfolgreichen Softwareorganisation CMMI & SPA (Siemens Process Assessment) Prof. Dr. Eckhart Hanser, Hanser: BA Lörrach CMMI und & SPA eha technologie service GmbH www.ba-loe errach.de CMMI Der Weg zur erfolgreichen Softwareorganisation CMMI & SPA (Siemens Process Assessment)

Mehr

Methoden und Werkzeuge des Konfigurationsmanagements

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

Mehr

Asset Management für Instandhalter: Alter Wein in neuen Schläuchen?

Asset Management für Instandhalter: Alter Wein in neuen Schläuchen? Asset Management für Instandhalter: Alter Wein in neuen Schläuchen? Prof. Dr. Christoph Heitz Institut für Datenanalyse und Prozessdesign Zürcher Hochschule für Angewandte Wissenschaften Winterthur, Switzerland

Mehr

Softwareentwicklung bei eevolution

Softwareentwicklung bei eevolution Softwareentwicklung bei eevolution Darstellung der Prozesse mit dem agilen Entwicklungsansatz Jan Freitag, COMPRA GmbH Jan Freitag Studium: IMIT Bachelor: 2005-2008 IMIT Master: 2008-2010 eevolution: Mitarbeit

Mehr

Kollaborative Anforderungsanalyse im verteilten Softwareentwicklungsprozess

Kollaborative Anforderungsanalyse im verteilten Softwareentwicklungsprozess Kollaborative Anforderungsanalyse im verteilten Softwareentwicklungsprozess Prof. Dr. Armin Heinzl (Universität Mannheim), Janos Koppany (Intland GmbH), Niels Mache (struktur AG) Hintergrund CollaBaWü

Mehr

Software Systems Engineering. Sommersemester 2013. Prof. Dr. Klaus Schmid. 28.01.2013, SoSe 13 Prof. Dr. Klaus Schmid 1

Software Systems Engineering. Sommersemester 2013. Prof. Dr. Klaus Schmid. 28.01.2013, SoSe 13 Prof. Dr. Klaus Schmid 1 Software Sommersemester 2013 Prof. Dr. Klaus Schmid 1 Kapitel 1: Java - Grundlagen Inhalt 1. Veranstaltungen im Sommersemester 2013 2 2. Aktuelle Abschluss- und Projektarbeiten 8 3. Offene HiWi Stellen

Mehr

Universität Passau. Fachbereich Informatik/Mathematik. Bachelorarbeit. im Studiengang Business Administration and Economics

Universität Passau. Fachbereich Informatik/Mathematik. Bachelorarbeit. im Studiengang Business Administration and Economics Universität Passau Fachbereich Informatik/Mathematik Bachelorarbeit im Studiengang Business Administration and Economics Thema: Klassifizierung von Methoden zur Qualitätsbeurteilung in der Software-Produktlinienentwicklung

Mehr

Softwareproduktlinien - Entwicklungsprozess und Variabilitätsmodellierung

Softwareproduktlinien - Entwicklungsprozess und Variabilitätsmodellierung Softwareproduktlinien - Entwicklungsprozess und Variabilitätsmodellierung Sven Apel (Universität Passau) Christian Kästner (Universität Marburg) Gunter Saake (Universität Magdeburg) 1 Agenda Produktlinien

Mehr

Toolgestützte Prozessdokumentation. Prozessorientiertes E-Government, 28.10.2005 Joel Meir, jmeir@csc.com, +41 31 998 46 46

Toolgestützte Prozessdokumentation. Prozessorientiertes E-Government, 28.10.2005 Joel Meir, jmeir@csc.com, +41 31 998 46 46 Toolgestützte Prozessdokumentation Prozessorientiertes E-Government, 28.10.2005 Joel Meir, jmeir@csc.com, +41 31 998 46 46 Wir bieten unseren Kunden End-to-End Lösungen an Consulting Systems Integration

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

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

Abbildung 1: Titelbild (Quelle: http://www.oobject.com/algorithmic-architecture/follymorph-continuum-group-finalpresentation/3267/)

Abbildung 1: Titelbild (Quelle: http://www.oobject.com/algorithmic-architecture/follymorph-continuum-group-finalpresentation/3267/) Abbildung 1: Titelbild (Quelle: http://www.oobject.com/algorithmic-architecture/follymorph-continuum-group-finalpresentation/3267/) Enterprise Continuum Wiederverwendung von Unternehmensarchitekturen Modul

Mehr

Optimieren von Requirements Management & Engineering

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

Mehr

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

Software-Qualität im Rahmen modellgetriebener Softwareentwicklung

Software-Qualität im Rahmen modellgetriebener Softwareentwicklung Software-Qualität im Rahmen modellgetriebener Softwareentwicklung OFFIS Technologiecluster Enterprise Application Integration niels.streekmann@offis.de 09.07.2008 Seite 1 / 13 Software-Qualität: Unterschiedliche

Mehr

Multi-Vendor-Outsourcing und Produktisierung von IT-Services. Dr. Serguei Dobrinevski serguei.dobrinevski@hypersoft.com

Multi-Vendor-Outsourcing und Produktisierung von IT-Services. Dr. Serguei Dobrinevski serguei.dobrinevski@hypersoft.com Multi-Vendor-Outsourcing und Produktisierung von IT-Services Dr. Serguei Dobrinevski serguei.dobrinevski@hypersoft.com Einführung Hypersoft Information Systems Mehr als 200 Großkunden für die Service-Metrics-Software

Mehr

Kapitel 2 Unternehmensarchitektur I

Kapitel 2 Unternehmensarchitektur I Kapitel 2 Unternehmensarchitektur I Software Architecture, Quality, and Testing FS 2015 Prof. Dr. Jana Köhler jana.koehler@hslu.ch Gesamtüberblick I. Unternehmensarchitektur - Enterprise Architecture (EA)

Mehr

Software Assessments verhelfen zur effektiven Prozessverbesserung

Software Assessments verhelfen zur effektiven Prozessverbesserung Assessments verhelfen zur effektiven Prozessverbesserung Ein Erfahrungsbericht Dr. Gunter Hirche Gründe für ein Assessment Anforderungen: Probleme bei der Abwicklung von Projekten mit SW-Anteilen Termine,

Mehr

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

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

Mehr

Requirements-Engineering für Varianten und Produktlinien: Good Practice & Erfahrungen. Konzeption

Requirements-Engineering für Varianten und Produktlinien: Good Practice & Erfahrungen. Konzeption Requirements-Engineering für Varianten und REConf 2011, München, 16. März 2011 Konzeption Entwicklung Software-Probleme sind oft auch Benutzung Service Deployment Abnahme Installation Betrieb Varianten-Probleme

Mehr

Das V-Modell: Produkte 1/5

Das V-Modell: Produkte 1/5 Das : Produkte 1/5 Problem-Beschreibung, Lastenheft Beschreibung des Problems/der Probleme, das/die gelöst werden soll Quellen: Markt-Analyse, Marketing, Kunden-Zirkel etc. Kunden-Anforderungen, Pflichtenheft

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

Der Business Analyst in der Rolle des agilen Product Owners

Der Business Analyst in der Rolle des agilen Product Owners Der Business Analyst in der Rolle des agilen Owners HOOD GmbH Susanne Mühlbauer Büro München Keltenring 7 82041 Oberhaching Germany Tel: 0049 89 4512 53 0 www.hood-group.com -1- Inhalte Agile Software

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

Was ist Software-Architektur?

Was ist Software-Architektur? Was ist Software-Architektur? Stephan Schulze Martin Knobloch 28.04.2004 Seminar: Software-Architektur Humboldt Universität zu Berlin sschulze knobloch@informatik.hu-berlin.de Gliederung Begriffsbestimmung

Mehr

Verbesserung der Beschaffung von Produkten und Leistungen auf Basis des CMMI für Akquisition (CMMI-ACQ)

Verbesserung der Beschaffung von Produkten und Leistungen auf Basis des CMMI für Akquisition (CMMI-ACQ) Verbesserung der Beschaffung von Produkten und Leistungen auf Basis des CMMI für Akquisition (CMMI-ACQ) Dr. Ralf Kneuper GI-Workshop Vorgehensmodelle 2009 2009-04-09 1 Ralf Kneuper Dipl.-Mathematiker,

Mehr

BPM im Kontext von Unternehmensarchitekturen. Konstantin Gress

BPM im Kontext von Unternehmensarchitekturen. Konstantin Gress BPM im Kontext von Unternehmensarchitekturen Konstantin Gress Agenda 1 Worum geht s BPM, EA und SOA im Überblick 2 Link zwischen EA und BPM 3 Link zwischen SOA und BPM 4 Wie spielt das zusammen? 5 Q&A

Mehr

Agiles Projektmanagement. erklärt in 30 Minuten! IT-Forum Agiles Projektmanagement, NIK 29. Juni 2011. Thomas Hemmer

Agiles Projektmanagement. erklärt in 30 Minuten! IT-Forum Agiles Projektmanagement, NIK 29. Juni 2011. Thomas Hemmer Agiles Projektmanagement erklärt in 30 Minuten! IT-Forum Agiles Projektmanagement, NIK 29. Juni 2011 Thomas Hemmer Chief Technology Officer thomas.hemmer@conplement.de conplement AG, Nürnberg 2 conplement

Mehr

Prof. Dr.-Ing. Dagmar Meyer Software Engineering 2 ANFORDERUNGSANALYSE UND -MODELLIERUNG

Prof. Dr.-Ing. Dagmar Meyer Software Engineering 2 ANFORDERUNGSANALYSE UND -MODELLIERUNG 2 ANFORDERUNGSANALYSE UND -MODELLIERUNG "If you don't know where you are going, you are unlikely to end up there." Forrest Gump 2 Anforderungen bilden die Grundlage für jedes (Software-)Projekt sind die

Mehr

Referent: Alessandro Arrigo AAM1. Professor: Prof. Dr. Heindl. Furtwangen, 2.7.2009

Referent: Alessandro Arrigo AAM1. Professor: Prof. Dr. Heindl. Furtwangen, 2.7.2009 - Entwicklungsprozess - Referent: Alessandro Arrigo AAM1 Professor: Prof. Dr. Heindl Furtwangen, 2.7.2009 Agenda 1. Vorstellung des Autors 2. Das Buch 3. Inhalt des Kapitels 4. Verwendung in anderer Literatur

Mehr

CMMI - Unterschiede und Gemeinsamkeiten zu CMM. 10/16/03 CMMI - Unterschiede und Gemeinsamkeiten zu CMM

CMMI - Unterschiede und Gemeinsamkeiten zu CMM. 10/16/03 CMMI - Unterschiede und Gemeinsamkeiten zu CMM CMMI - Unterschiede und Gemeinsamkeiten zu CMM Universität Tübingen Arbeitsbereich: Informatik und Gesellschaft Thomas Grosser email: tgrosser@informatik.uni-tuebingen.de im Juli 2003 1 Gliederung Einleitung,

Mehr

SPES_XT Abschlussveranstaltung

SPES_XT Abschlussveranstaltung SPES_XT Abschlussveranstaltung EC5: Durchgängiges Variantenmanagement und Wiederverwendung Peter Manhart, Daimler AG Ottobrunn, 10. Juli 2015 EC5 Partner 2 EC5 Überblick Projektergebnisse 05/2014 04/2015

Mehr

Wieviel Usability Engineering braucht das Software Engineering?

Wieviel Usability Engineering braucht das Software Engineering? Wieviel Usability Engineering braucht das Software Engineering? Prof. Dr. Institut für Informatik Neuenheimer Feld 348 69120 Heidelberg http://www-swe.uni-heidelberg.de paech@informatik.uni-heidelberg.de

Mehr

Über dieses Buch. Kapitel 1. 1.1 Einleitung

Über dieses Buch. Kapitel 1. 1.1 Einleitung Kapitel 1 Über dieses Buch 1.1 Einleitung Dieses Buch behandelt das Vorgehensmodell Kanban und seinen Einsatz in Softwareentwicklungsprojekten. Kanban ist ein Vorgehensmodell der schlanken Softwareentwicklung

Mehr