Liebe openMDM® EWG Mitglieder,
zunächst einmal allen ein gutes Neues Jahr. Meine erste Mail 2017 bezieht sich auf eine Diskussion, die sich um das Anforderungsmanagement der openMDM® EWG dreht.
Sie wird unter Leitung von Peak Solution im Rahmen des an Peak Solution vergebenen Anforderungsmanagement- Service geführt. Ich denke, dass das Thema für alle openMDM® EWG- Mitglieder von Interesse ist und erweitere deshalb die CC- Liste „zum Mithören“ und
ggf. Einsteuern von feedback.
Nun zum Thema:
Ich stimme mit Sybille überein (s.u.). Speziell fällt mir noch Folgendes ein:
Variante 1 soll die normale und angestrebte sein. Die „Passfähigkeit“ einer Komponente entscheidet sich nach
-
Vollständige Verfügbarkeit unter der EPL (Vorgaben macht Eclipse, Eclipse prüft bei Bedarf, z.B. IP)
-
Architekturkonformität (Vorgaben macht bzw. pflegt das AC, AC prüft bei Bedarf mit Hilfe seines Service)
-
QA (Vorgaben macht das QC, QC prüft bei Bedarf mit Hilfe seines service)
-
Einordnung in die Gesamtfunktionalität des Baukastens erfolgt (Vorgaben macht das SC, SC prüft bei Bedarf durch Baukasten- Manager)
Variante 3 trifft für kommerzielle Komponenten (die im Zusammenhang mit openMDM® aus meiner Sicht durchaus zulässig und gewünscht sind)
zu. Die Abhängigkeiten der Komponenten müssen auf Basis der openMDM® Architektur beschrieben werden und speziell konfliktfrei zum openMDM® business layer sein, d.h. das Geschäftsobjektmodell und die Schnittstellen respektieren und referenzieren. Im gegenteiligen
Fall entstünde ein Markenkonflikt mit openMDM®, und die Marke dürfte nicht im Zusammenhang mit solchen Komponenten verwendet werden. Alle Themen einer kommerziellen Komponentenentwicklung steuert der Produkthersteller im Eigeninteresse (Anforderungsmanagement,
Entwicklung, Vertrieb). Einziger Bezugspunkt zu openMDM® ist ein als kompatibel definiertes Release sowie die Abgrenzung der verwendeten Schnittstellen. Natürlich sind rechtliche Aspekte (IP etc.) zu berücksichtigen.
Variante 2 ist aus meiner Sicht nicht nötig, eine Grauzone außerhalb der openMDM® EWG mit unklaren Zuständigkeiten ist nicht zielführend.
Soweit meine Vorstellungen, die ich hier zur Diskussion stelle.
Mit freundlichen Grüßen
Sven Wittig
Prozess- / Methodenentwicklung TE, Testing
AUDI AG
I/EZ-831
D-85045 Ingolstadt
Tel.: +49-841-89-45123
Fax:+49-841-89-8445123
Mobile: +49-16090444721
sven.wittig@xxxxxxx
www.audi.com
Sitz/Domicile: Ingolstadt
Registergericht/Court of Registry: Amtsgericht Ingolstadt
HRB Nr./Commercial Register No.: 1
Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board: Matthias Müller
Vorstand/Board of Management: Rupert Stadler (Vorsitzender/Chairman), Bernd Martens, Thomas Sigi, Axel Strotbek, Dietmar Voggenreiter, Hubert Waltl
Wichtiger Hinweis: Die vorgenannten Angaben werden jeder E-Mail automatisch hinzugefügt und lassen keine Rückschlüsse auf den Rechtscharakter der E-Mail zu.
Important Notice: The above information is automatically
added to this e-mail. This addition does not constitute a representation that the content of this e-mail is legally relevant and/or is intended to be legally binding upon AUDI AG.
Von: sibylle Peter [mailto:sibylle.peter@xxxxxxxxx]
Gesendet: Donnerstag, 5. Januar 2017 20:23
An: Wittig, Sven (I/EZ-831)
Cc: Hans-Jörg Kremer; Beese, Stefan, IN; Andreas Benzing (andreas.benzing@xxxxxxxxx); Woehrl, Franz (I/EZ-831)
Betreff: Re: Anforderungsmanagement - AW: Doch noch eine Präsentation gefunden
Hallo zusammen
was wir im Requirementsmanagement vergessen haben, weil es nur am Rande zu RE gehört, wohl aber zum Produktmanagement (und auch zum Communitymgmt) ist die Frage, wie die Working Group damit umgeht, wenn jemand auf Basis von MDM5 eine Komponente
entwickelt hat und die dann nachträglich an die Working Group/resp. in das Eclipse Projekt einfliessen lassen will.
Dazu sehe ich im Moment folgende Möglichkeiten:
1) die WG/SC entscheidet, dass die Komponente gut in das Produktportfolio (oder in den Baukasten) passt. Dann muss sichergestellt werden, dass die Qualität (inkl. allgemeine Benutzbarkeit) i. O. ist, dass die IP geklärt ist und dann kann
die Komponente übernommen werden (bedeutet dann auch, dass. die gleich behandelt wird, wie von der WG in Auftrag gegebende Komponenten).
2) Oder die WG/SC entscheidet, dass das keinen Sinn macht, dann könnte man sich vorstellen, dass es einen Ort gibt, wo man diese Komponenten sammelt, aber darauf hinweist, dass die nicht unter der WG entwickelt worden sind. (eine Art 3rd
party plugin vom Konzept her).
3) Man sagt: kein Interesse, ihr dürft die gerne open source stellen, aber bitte in einem eigenen Projekt… -> dann gibt es von der Komponente eine Abhängigkeit auf die WG Eclipse Projekte, aber die WG kümmert sich nicht darum.
M. E. ist das auch eine Frage des Zeitpunkts. Im Moment würde ich versuchen, fast alles unter 1) zu nehmen, evtl. halt noch mit gewissen Anforderungen an die allgemeine Benutzbarkeit. Das einfach, um die Community zu stärken und auch zu
zeigen, dass etwas vorwärts geht. Also 3) fände ich aus politischen Gründen nicht angebracht, das müsste dann wirklich etwas sein, dass der Idee von OpenMDM5 widerspricht. 2) kann man sich überlegen, wenn es fliesst, das wäre ja dann evtl. so eine Art Marktplatz,
evtl. dann auch für kommerzielle Plugins zu der Basis OpenMDM5 Implementierung.
ich bin jetzt erst dazu gekommen, mir Sibylles Präsentation noch einmal anzusehen. Im Grunde genommen trifft alles darin Gesagte zu. Ich sehe nun ein paar Spezifika,
auf die wir noch das Ganze konkretisieren müssen:
- Produktowner
Baukasten -> neue EWG- Rolle, dauerhaft zu vergeben und durch die EWG aus Budget zu finanzieren
- Anforderungen
-> verschiedene scopes, also mehrstufiges Anforderungsmanagement
o An
den Baukasten als Gesamheit => TLR, EPIC?
o An
ein spezielles System, das aus dem Baukasten gebaut können werden soll (klingt verschraubt, muss man aber glaube ich so ausdrücken, um ganz klar zu sein) => EPIC?, user story
o An
eine Komponente, die innerhalb des Baukastens Schnittstellen erfüllen und Funktionen bereitstellen soll.
Wir müssen also auch schleunigst daran gehen, endlich ein allgemein akzeptiertes Verständnis zu schaffen, was wir als Komponente bezeichnen und sehen wollen.
Wir können sogar einen anderen Begriff wählen, aber der muss hergeben dass das Ding:
- Als
Einheit entwickel- und pflegbar, baubar, testbar, betreibbar ist
- Alle
Abhängigkeiten nach außen vollständig in Schnittstellen beschreibt (die Schnittstellen sind nicht zwingend technisch formulierte Schnittstellen, das kann bis hin zu einer informellen, verbalen , aber aussagekräftigen Spezifikation gehen)
- Eine
sinnvolle Größe und Granularität hat, um Arbeitsteilung zu ermöglichen
- Eindeutig
mit Name und Version für ein übergordnetes Konfigurationsmanagement und Kompatibilitätsaussagen ansprechbar ist
Ich nehme deshalb Andreas und Franz mal mit auf den Verteiler, damit sie eventuell input oder veto geben können.
Mit freundlichen Grüßen
Sven Wittig
Prozess- / Methodenentwicklung TE, Testing
AUDI AG
I/EZ-831
D-85045 Ingolstadt
Tel.: +49-841-89-45123
Fax:+49-841-89-8445123
Mobile: +49-16090444721
sven.wittig@xxxxxxx
www.audi.com
Sitz/Domicile: Ingolstadt
Registergericht/Court of Registry: Amtsgericht Ingolstadt
HRB Nr./Commercial Register No.: 1
Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board: Matthias Müller
Vorstand/Board of Management: Rupert Stadler (Vorsitzender/Chairman), Bernd Martens, Thomas Sigi, Axel Strotbek, Dietmar Voggenreiter, Hubert Waltl
Wichtiger Hinweis: Die vorgenannten Angaben werden jeder E-Mail automatisch hinzugefügt und lassen keine Rückschlüsse auf den Rechtscharakter der E-Mail zu.
Important Notice: The
above information is automatically added to this e-mail. This addition does not constitute a representation that the content of this e-mail is legally relevant and/or is intended to be legally binding upon AUDI AG.
Von: sibylle
Peter [mailto:sibylle.peter@xxxxxxxxx]
Gesendet: Donnerstag, 8. Dezember 2016 11:04
An: Wittig, Sven (I/EZ-831); Hans-Jörg Kremer; Beese, Stefan, IN
Betreff: Doch noch eine Präsentation gefunden
