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

Softwaretechnik. Prof. Dr. Rainer Koschke. Fachbereich Mathematik und Informatik Arbeitsgruppe Softwaretechnik Universität Bremen

Softwaretechnik. Prof. Dr. Rainer Koschke. Fachbereich Mathematik und Informatik Arbeitsgruppe Softwaretechnik Universität Bremen Softwaretechnik Prof. Dr. Rainer Koschke Fachbereich Mathematik und Informatik Arbeitsgruppe Softwaretechnik Universität Bremen Wintersemester 2010/11 Überblick I Software-Produktlinien Software-Produktlinien:

Mehr

Softwaretechnik. Überblick I. Prof. Dr. Rainer Koschke. Sommersemester 2006

Softwaretechnik. Überblick I. Prof. Dr. Rainer Koschke. Sommersemester 2006 Softwaretechnik Prof. Dr. Rainer Koschke Fachbereich Mathematik und Informatik Arbeitsgruppe Softwaretechnik Universität Bremen Sommersemester 2006 Überblick I 1 Software-Produktlinien Software-Produktlinien:

Mehr

Software Produktlinien: Einführung und Überblick

Software Produktlinien: Einführung und Überblick C A R L V O N O S S I E T Z K Y Software Produktlinien: Einführung und Überblick Johannes Diemke Vortrag im Rahmen des Seminars Software System Engineering im Wintersemester 2007/2008 Übersicht 1 Motivation

Mehr

Software-Produktlinien Vom Designerstück zur Industrialisierung in der Softwaretechnik

Software-Produktlinien Vom Designerstück zur Industrialisierung in der Softwaretechnik Software-Produktlinien Vom Designerstück zur Industrialisierung in der Softwaretechnik Ausarbeitung zum Seminar Softwaretechnik, Institut für Softwaretechnik, TU Berlin Dozent: Ramin Tavakoli Koligari

Mehr

Einführung in Generatives Programmieren. Bastian Molkenthin

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

Mehr

Product Line Engineering (PLE)

Product Line Engineering (PLE) Product Line Engineering (PLE) Produktlinienentwicklung Von Christoph Kuberczyk Christoph Kuberczyk, SE in der Wissenschaft 2015, Product Line Engineering 1 Gliederung 1. Was ist PLE? 2. Motivation 3.

Mehr

Unterschiede zur Klassischen Software-Entwicklung. SPL versus klassische SE Tim Serowski 1

Unterschiede zur Klassischen Software-Entwicklung. SPL versus klassische SE Tim Serowski 1 Unterschiede zur Klassischen Software-Entwicklung SPL versus klassische SE Tim Serowski 1 Agenda Kurzüberblick Fertigungsprozess Wiederverwendbarkeit von Komponenten Versionierung Kosten / Nutzen einer

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

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

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

Application Requirements Engineering

Application Requirements Engineering Application Requirements Engineering - Fokus: Ableitung von Produktanforderungen - Günter Halmans / Prof. Dr. Klaus Pohl Software Systems Engineering ICB (Institute for Computer Science and Business Information

Mehr

Software Product Line Engineering

Software Product Line Engineering Software Product Line Engineering Grundlagen, Variabilität, Organisation Sebastian Steger steger@cs.tu-berlin.de WS 2005/2006 SWT: Entwicklung verteilter eingebetteter Systeme Software Product Line Engineering

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

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

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

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

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

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

Softwareproduktlinien

Softwareproduktlinien PRAKTISCHE INFORMATIK, UNIVERSITÄT SIEGEN Softwareproduktlinien (Pro)Seminar Informatik WS 2014/2015 Finale Ausarbeitungen Stand: 07.02.2015 Preface Dieser Band enthält die finalen Ausarbeitungen eines

Mehr

Softwareproduktlinien Teil 2: Entwicklungsprozess und Variabilitätsmodellierung

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

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

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

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

EIN BRANCH FÜR JEDEN KUNDEN?

EIN BRANCH FÜR JEDEN KUNDEN? EIN BRANCH FÜR JEDEN KUNDEN? WIE INDIVIDUALISIERUNG UND STANDARDISIERUNG IN EINKLANG GEBRACHT WERDEN KÖNNEN AIT GmbH & Co. KG Ihre Software effizienter entwickelt. 2 AGENDA Die Unternehmen und ihre Produkte

Mehr

Generative Prozessmodelle Patrick Otto MDD Konferenz 22.03.2009

Generative Prozessmodelle Patrick Otto MDD Konferenz 22.03.2009 Generative Prozessmodelle Patrick Otto MDD Konferenz 22.03.2009 Gliederung 1. Generative Programmierung 2. Möglichkeiten und Einsatzgebiet 3. Prozess / Tools 4. Zusammenfassung 19.03.2009 GENERATIVE PROGRAMMIERUNG

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

Von Requirements zutests. gç~åüáãkpåüìäò]èì~äáíóé~êâkçé

Von Requirements zutests. gç~åüáãkpåüìäò]èì~äáíóé~êâkçé Von Requirements zus gç~åüáãkpåüìäò]èì~äáíóé~êâkçé QualityPark Ihr Partner im Lifecycle Management Process Management Requirements Engineering IT & Development Process Expertise Process Implementation

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

Software Produktlinien

Software Produktlinien Software Produktlinien Einführung und Überblick Johannes Diemke Universität Oldenburg Department für Informatik 26111 Oldenburg Zusammenfassung Dieser Artikel soll einen Überblick über den Software Produktlinien

Mehr

Vom Intranet zum Knowledge Management

Vom Intranet zum Knowledge Management Vom Intranet zum Knowledge Management Die Veränderung der Informationskultur in Organisationen von Martin Kuppinger, Michael Woywode 1. Auflage Hanser München 2000 Verlag C.H. Beck im Internet: www.beck.de

Mehr

Copyright 2014 Delta Software Technology GmbH. All Rights reserved.

Copyright 2014 Delta Software Technology GmbH. All Rights reserved. Karlsruhe, 21. Mai 2014 Softwareentwicklung - Modellgetrieben und trotzdem agil Daniela Schilling Delta Software Technology GmbH The Perfect Way to Better Software Modellgetriebene Entwicklung Garant für

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

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, Thomas Thüm (Universität Magdeburg) 1 Agenda

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

Evaluierung und Erprobung von Ansätzen beim modellbasierten Design in Software Produktlinien

Evaluierung und Erprobung von Ansätzen beim modellbasierten Design in Software Produktlinien und Erprobung von n beim modellbasierten Design in 15.11.2006 Inhalt Motivation und Motivation und Motivation: für Automotive, Projekt MobilSoft (TP 6) Variantenvielfalt mit SPL und MDA lösen Fragestellung:

Mehr

Vorlesung Donnerstags, 10.00 bis 11.30 Uhr, HS12 Übung Dienstags, 14.00 bis 15.30 Uhr 4-5 ÜbungsbläMer (Programmieraufgaben)

Vorlesung Donnerstags, 10.00 bis 11.30 Uhr, HS12 Übung Dienstags, 14.00 bis 15.30 Uhr 4-5 ÜbungsbläMer (Programmieraufgaben) Komponenten Einführung Organisatorisches 2+1 SWS Vorlesung Donnerstags, 10.00 bis 11.30 Uhr, HS12 Übung Dienstags, 14.00 bis 15.30 Uhr 4-5 ÜbungsbläMer (Programmieraufgaben) Klausur 28. Februar 2013 Unterlagen

Mehr

Featuremodellbasiertes und kombinatorisches Testen von Software-Produktlinien

Featuremodellbasiertes und kombinatorisches Testen von Software-Produktlinien Featuremodellbasiertes und kombinatorisches Testen von Software-Produktlinien Sebastian Oster, Philipp Ritter, Andy Schürr Sebastian Oster oster@es.tu-darmstadt.de Tel.+49 6151/16-3776 ES Real-Time Systems

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

Data Processing, On-Board Software & Dependability (ASG72, ASG73)

Data Processing, On-Board Software & Dependability (ASG72, ASG73) Data Processing, On-Board Software & Dependability (ASG72, ASG73) Aktuelle Aktivitäten und Möglichkeiten der Zusammenarbeit Name: Norbert Binzer, Abt. ASG72 DLR - Raumfahrt-Industrietage in Friedrichshafen

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

Variantenmanagement modellbasierter Funktionssoftware mit Software-Produktlinien

Variantenmanagement modellbasierter Funktionssoftware mit Software-Produktlinien Arbeitsberichte des Instituts für Informatik Friedrich-Alexander-Universität Erlangen Nürnberg Band 40 Nummer 4 Juli 2007 Stefan Kubica Variantenmanagement modellbasierter Funktionssoftware mit Software-Produktlinien

Mehr

your IT in line with your Business Geschäftsprozessmanagement (GPM)

your IT in line with your Business Geschäftsprozessmanagement (GPM) your IT in line with your Business Geschäftsprozessmanagement (GPM) Transparenz schaffen und Unternehmensziele effizient erreichen Transparente Prozesse für mehr Entscheidungssicherheit Konsequente Ausrichtung

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

Wiederverwendung von automotive Software- Reifegradmodell, Technologie, Praxisbericht

Wiederverwendung von automotive Software- Reifegradmodell, Technologie, Praxisbericht Wiederverwendung von automotive - Reifegradmodell, Technologie, Praxisbericht Dr. Thomas Zurawka, HdT Elektronik im Kfz, Dresden, 24.06.2009 ECU SW Architektur & SW Entwicklungsprozess Anforderungs- Analyse

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

Was ist Application Lifecycle Management?

Was ist Application Lifecycle Management? Was ist Application Lifecycle Management? Von David Chappell Gefördert durch die Microsoft Corporation 2010 Chappell & Associates David Chappell: Was ist Application Lifecycle Management? Seite 2 von 7

Mehr

Variabilität in Produktlinien und das orthogonale Variabilitätsmodell

Variabilität in Produktlinien und das orthogonale Variabilitätsmodell Variabilität in Produktlinien und das orthogonale Variabilitätsmodell Vortrag im Rahmen des Proseminars Softwarequalität und -sicherheit von Marion Weber SS 2010 1 Einführung & Motivation Variabilität

Mehr

Grundlagen Software Engineering

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

Mehr

Vortrag von: Ilias Agorakis & Robert Roginer

Vortrag von: Ilias Agorakis & Robert Roginer MDA Model Driven Architecture Vortrag von: Ilias Agorakis & Robert Roginer Anwendungen der SWT - WS 08/09 Inhalt Was ist MDA? Object Management Group (OMG) Ziele Konzepte der MDA Werkzeuge Vor- und Nachteile

Mehr

Referent: Mathias Notheis Kontakt: Mathias.Notheis@dqs.de

Referent: Mathias Notheis Kontakt: Mathias.Notheis@dqs.de ISO/IEC 62304 Medizingeräte-Software Referent: Mathias Notheis Kontakt: Mathias.Notheis@dqs.de DQS Medizin nprodukte GmbH Übersicht Basics Wann ist ein MP Software? Markteinführung vor der 62304 alles

Mehr

Qualitätsmanagement im Projekt

Qualitätsmanagement im Projekt Software-Engineering Qualitätsmanagement im Projekt Vorlesung im Wintersemester 2008/2009 Fakultät Wirtschaftsinformatik Klaus Mairon, M.Sc. Inhalte Messen und Bewerten: Metriken in der Qualitätssicherung

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

Generatives Programmieren

Generatives Programmieren Generatives Programmieren Seminar Produktlinien WS03/04 Tammo van Lessen 08.01.2004 Outline Einleitung Generatoren Generatives Programmieren Fazit Einleitung Industrielle Entwicklung 1826 Austauschbare

Mehr

Risiken auf Prozessebene

Risiken auf Prozessebene Risiken auf Prozessebene Ein Neuer Ansatz Armin Hepe Credit Suisse AG - IT Strategy Enabeling, Practices & Tools armin.hepe@credit-suisse.com Persönliche Vorstellung, kurz 1 Angestellter bei Credit Suisse

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

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

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

Verwendung von Anforderungsbasierten Verfolgbarkeitsmetriken im Projektmanagement

Verwendung von Anforderungsbasierten Verfolgbarkeitsmetriken im Projektmanagement Verwendung von Anforderungsbasierten Verfolgbarkeitsmetriken im Projektmanagement Michael Eisenbarth Abteilung Requirements- und Usability-Engineering Fraunhofer-Institut für Experimentelles Software Engineering

Mehr

Integriertes Risikomanagement mit GAMP 5 Risiken effizient managen!

Integriertes Risikomanagement mit GAMP 5 Risiken effizient managen! Integriertes Risikomanagement mit GAMP 5 Risiken effizient managen! Autor: Thomas Halfmann Halfmann Goetsch Peither AG Mit GAMP 5 wurde im Jahr 2005 der risikobasierte Ansatz in die Validierung computergestützter

Mehr

ITIL & TOGAF die Doppelspitze für IT Governance

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

Mehr

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

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

Service Orientierung organisiertes IT Service Management in der BWI IT auf Basis ITIL

Service Orientierung organisiertes IT Service Management in der BWI IT auf Basis ITIL Orientierung organisiertes IT Management in der BWI IT auf Basis ITIL 97. AFCEA-Fachveranstaltung Diensteorientierung aber mit Management Heiko Maneth, BWI IT Delivery, Leitung Prozessarchitektur und -management

Mehr

Metadata Service Respository (MDS) - Sehen, lernen, verstehen!

Metadata Service Respository (MDS) - Sehen, lernen, verstehen! Metadata Service Respository (MDS) - Sehen, lernen, verstehen! Carsten Wiesbaum esentri AG Schlüsselworte Metadata Service Repository, MDS, Oracle Fusion Middleware Einleitung Früher oder später wird jeder

Mehr

14 Aktivitäten und Artefakte

14 Aktivitäten und Artefakte Im Rahmen einer Softwareentwicklung müssen Aktivitäten durchgeführt werden, die zu Ergebnissen im Folgenden Artefakte (artifacts) genannt führen. Eine Aktivität wird durch Mitarbeiter ausgeführt, die definierte

Mehr

Entwurf. Anwendungsbeginn E DIN EN 62304 (VDE 0750-101):2013-10. Anwendungsbeginn dieser Norm ist...

Entwurf. Anwendungsbeginn E DIN EN 62304 (VDE 0750-101):2013-10. Anwendungsbeginn dieser Norm ist... Anwendungsbeginn Anwendungsbeginn dieser Norm ist.... Inhalt Einführung... 13 1 Anwendungsbereich... 16 1.1 *Zweck... 16 1.2 *Anwendungsbereich... 16 1.3 Beziehung zu anderen Normen... 16 1.4 Einhaltung...

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

Software- Produktlinien

Software- Produktlinien Software- Produktlinien Informatik- Seminar im Rahmen des Studienganges Master Technische Informatik im Modul Software- Projekt- Management Referent: Prof. Dr. Hans Nissen von Karin Schuster Matrikelnummer:

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

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

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

Projekt: Requirements Engineering Sommersemester 2002. Anforderungsspezifikation im X-Treme Programming

Projekt: Requirements Engineering Sommersemester 2002. Anforderungsspezifikation im X-Treme Programming Projekt: Requirements Engineering Sommersemester 2002 Vortrag von Bernd Simmchen Anforderungsspezifikation im X-Treme Programming Gliederung 1 XP Eine kurze Einführung 2 Anforderungsspezifikation Klassisch

Mehr

Übungsaufgaben zum Software Engineering: Management

Übungsaufgaben zum Software Engineering: Management Übungsaufgaben zum Software Engineering: Management Grundbegriffe: Aufgabe 1: Aus welchen Disziplinen setzt sich das Software Engineering zusammen? a. Informatik b. Physik c. Psychologie d. Chemie e. Geologie

Mehr

IT-Beratung: Vom Geschäftsprozess zur IT-Lösung

IT-Beratung: Vom Geschäftsprozess zur IT-Lösung Ralf Heib Senior Vice-President Geschäftsleitung DACH IT-Beratung: Vom Geschäftsprozess zur IT-Lösung www.ids-scheer.com Wofür steht IDS Scheer? Wir machen unsere Kunden in ihrem Geschäft erfolgreicher.

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

Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg

Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg Herzlich willkommen Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg Heike Bickert Software-/Systemingenieurin, Bereich Quality Management Braunschweig // 17.11.2015 1 Agenda ICS AG Fragestellungen

Mehr

SERVICE SUCHE ZUR UNTERSTÜTZUNG

SERVICE SUCHE ZUR UNTERSTÜTZUNG SERVICE SUCHE ZUR UNTERSTÜTZUNG VON ANFORDERUNGSERMITTLUNG IM ERP BEREICH MARKUS NÖBAUER NORBERT SEYFF ERP SYSTEME Begriffsbestimmung: Enterprise Resource Planning / Business Management Solution Integrierte

Mehr

Service Transition. Martin Beims. WKV SS13 Karsten Nolte. Mittwoch, 19. Juni 13

Service Transition. Martin Beims. WKV SS13 Karsten Nolte. Mittwoch, 19. Juni 13 Service Transition Martin Beims WKV SS13 Karsten Nolte Inhalt Einführung & Ziele Transition Planning & Support Change Management Service Asset & Configuration Management Release & Deployment Management

Mehr

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12 Vertretung von Prof. Dr. Blume WS 2011/12 Inhalt Test, Abnahme und Einführung Wartung- und Pflegephase gp Vorlesung Zusammenfassung Produkte und Recht (Folien von Prof. Blume) 2 , Abnahme und Einführung

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

Taxonomy of Evolution and Dependability. Integration Engineering SS 2009 Andreas Landerer

Taxonomy of Evolution and Dependability. Integration Engineering SS 2009 Andreas Landerer Taxonomy of Evolution and Dependability Integration Engineering SS 2009 Andreas Landerer Agenda Informationen über Massimo Felici Definition zentraler Begriffe Inhalt des Artikels Kernaussagen des Artikels

Mehr

Software Engineering: Aktuelle Herausforderungen und Chancen

Software Engineering: Aktuelle Herausforderungen und Chancen Software : Aktuelle Herausforderungen und Chancen Prof. Dr. Klaus Schmid Modernes Software Herausforderungen Die Klassiker Kosten Qualität Risiko Die Neuen Flexibilität Strategische Integration 07.12.2006,

Mehr

Software Engineering

Software Engineering Software Engineering Grundlagen, Menschen, Prozesse, Techniken von Jochen Ludewig, Horst Lichter 1. Auflage Software Engineering Ludewig / Lichter schnell und portofrei erhältlich bei beck-shop.de DIE

Mehr

Configuration management

Configuration management Hauptseminar im Wintersemester 2003/2004 Neue Ansätze im IT-Service-Management-Prozessorientierung (ITIL/eTom) Configuration management 18. Februar 2004 Tingting Hu Betreuer: Vitalian A. Danciu Inhalt

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

Model Driven Architecture

Model Driven Architecture Model Driven Architecture Wilhelm Stephan Universität Hamburg Fakultät für Mathematik, Informatik und Naturwissenschaften Seminar Softwareentwicklung in der Wissenschaft Betreuer: Julian Kunkel SommerSemester

Mehr

Microsoft Solutions Framework. Daniel Dengler CN7. Unterschied MSF - MOF Microsoft Solutions Framework

Microsoft Solutions Framework. Daniel Dengler CN7. Unterschied MSF - MOF Microsoft Solutions Framework Einführung MSF MOF Microsoft Solutions Framework Microsoft Operations Framework Daniel Dengler CN7 Agenda Unterschied MSF - MOF Microsoft Solutions Framework Elementare Komponenten grundlegende Richtlinien

Mehr

13 Anhang A: Erfüllung der Norm ISO 9000 durch HERMES

13 Anhang A: Erfüllung der Norm ISO 9000 durch HERMES 13 Anhang A: Erfüllung der Norm ISO 9000 durch Hinweis Einleitung Eine der wesentlichsten Grundlagen für die Qualitätssicherung in einem Unternehmen ist die Normenserie «ISO 9000», insbesondere ISO 9001:1994

Mehr

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

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

Mehr

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

Model Driven Architecture (MDA)

Model Driven Architecture (MDA) Model Driven Architecture (MDA) Vortrag im Fach Software Engineering II BA Mannheim / Fachrichtung Angewandte Informatik Torsten Hopp Gliederung Einleitung Motivation Grundzüge der MDA Ziele & Potenziale

Mehr

Systemen im Wandel. Autor: Dr. Gerd Frenzen Coromell GmbH Seite 1 von 5

Systemen im Wandel. Autor: Dr. Gerd Frenzen Coromell GmbH Seite 1 von 5 Das Management von Informations- Systemen im Wandel Die Informations-Technologie (IT) war lange Zeit ausschließlich ein Hilfsmittel, um Arbeitsabläufe zu vereinfachen und Personal einzusparen. Sie hat

Mehr

Vom dem was Autos und Software GEMEINSAM haben. Diskussionsbeitrag zur Software-Industralisierung. Guido Brune

Vom dem was Autos und Software GEMEINSAM haben. Diskussionsbeitrag zur Software-Industralisierung. Guido Brune Vom dem was Autos und Software GEMEINSAM haben Diskussionsbeitrag zur Software-Industralisierung Guido Brune Gesellschaft für Informatik e. V. Regionalgruppe Dortmund 14. März 2011 Gliederung E I N L E

Mehr

Variabilitätsmodellierung in Softwareproduktlinien

Variabilitätsmodellierung in Softwareproduktlinien Variabilitätsmodellierung in Softwareproduktlinien Universität Siegen Siegen, den 16. Februar 2015 1 Variabilität Definition Variabilität Variationspunkt Variante Arten von Variabilität Interne vs Externe

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

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

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

Microsoft SharePoint 2013 Designer

Microsoft SharePoint 2013 Designer Microsoft SharePoint 2013 Designer Was ist SharePoint? SharePoint Designer 2013 Vorteile SharePoint Designer Funktionen.Net 4.0 Workflow Infrastruktur Integration von Stages Visuelle Designer Copy & Paste

Mehr