Kategorien und Attribute von Glossareinträgen

Terms (DE: Begriffe)

Allgemeine Begriffe, die entweder in einem anderen Glossareintrag referenziert werden oder in einem Architekturdiagramm verwendet werden, um Beziehungen zwischen Begriffen sichtbar zu machen.

Begriffe haben Attribute wie folgt:

Attribut	Verwendung
Begriffsanwendung	Erklärung zur Anwendung dieses Begriffes
Beziehung zum generellen Glossarbegriff	Angabe, von welchem Glossareintrag dieser Glossareintrag abgeleitet wurde
Beziehung zu speziellen Glossarbegriffen	Angabe, welcher Glossareintrag von diesem Glossareintrag abgeleitet wurde
Beziehung zu assoziierten Glossarbegriffen	Angabe, welcher Glossareintrag mit diesem Glossareintrag zusammenhängt, falls eine generelle oder spezielle Beziehung nicht zutreffend ist
Beziehung zum zusammenfassenden Glossarbegriff	Angabe, welcher Glossareintrag diesem Glossareintrag übergeordnete ist, ohne von diesem abgeleitet zu sein
Beziehung zum vereinzelnden Glossarbegriff	Angabe von einem von diesem Glossareintrag hierarchisch unabhängigen Glossareintrag
SUDOQU-Abhängigkeit	Angabe, ob der Glossareintrag vom Referenzmodell abweicht. Mehr Informationen dazu können in der IFU Installation and Upgrade in Abschnitt Nummerierung von Rollen gefunden werden

Checkpoints (DE: Prüfpunkte)

Prüfpunkte sind ein wichtiges Werkzeug der Projektplanung sowie der Qualitätssicherung. Sie werden verwendet, um den Projektfortschritt bewerten zu können. Mehr zu Konzeption hinter den Prüfpunkten und deren Attribute ist in Abschnitt Prüfpunkte zu finden.

Umsetzungen von mitgeltenden Anforderungen

Allgemeine Informationen

Umsetzungs-Glossareinträge sind Brücken zwischen den Anforderungen eines mitgeltenden Dokuments und Prozessdiagrammen, die Konzeption ist in Abschnitt Generelles beschrieben.

Es gibt für jedes mitgeltende Dokument eine Unterkategorie in der Glossar-Kategorie Implementations of Applicable Requirements. Jeder der folgenden Abschnitte ist einem mitgeltenden Dokument und seiner Unterkategorie gewidmet. Der Name der Unterkategorie setzt sich aus dem festen Bestandteil Implementations of und dem Namen sowie, falls vorhanden, Version des mitgeltenden Dokuments zusammen.
Beispiel mit der ISO 9001:2015: Implementations of ISO 9001:2015

Implementations of Automotive SPICE 3.1

Hier wird die Umsetzung der Outcomes (DE: Wirkungen) im Sinne von Automotive SPICE beschrieben, die durch das Durchführen von Tätigkeiten erreicht werden.

Zusätzlich zu dieser Beschreibung ist folgendes Attribut für diese Glossarkategorie auszufüllen:

Attribut	Verwendung
Bezüge zu VDA A-SPICE 3.1	Link zu den BasePractice, Outcome WorkItems und Prozessobjekt WorkItems in Polarion

• Beispiel für eine beschriebene Wirkung mit Verlinkungen nach Polarion.

Implementations of ISO 9001:2015

Hier wird erklärt wie die einzelnen Abschnitte der ISO 9001:2015, im CMS erfüllt werden

Dabei sind folgende Attribute für diese Glossarkategorie auszufüllen:

Attribut	Verwendung
Bezüge zu ISO 9001: 2015 DE	Link zu den deutschen ISO 9001:2015 WorkItems in Polarion
Bezüge zu ISO 9001: 2015 EN	Link zu den englischen ISO 9001:2015 WorkItems in Polarion

Hinweis:
Wenn das CMS nur einsprachig geführt wird, reicht eine der Sprachen natürlich aus

Beispiel für eine beschriebene Umsetzung.

Process objects (DE: Prozessobjekte)

Prozessobjekte werden als Prozesseingaben und/oder Prozessausgaben in Prozessdiagrammen verwendet, in der Regel als Eingaben und/oder Ausgaben von Tätigkeiten. Sie beschreiben die Anforderungen, denen Eingaben und/oder Ausgaben beim Prozessdurchlauf genügen müssen.

Beispiel:

Prozessobjekte haben Attribute wie folgt:

Attribut	Verwendung
Dokumentvorlage	Nutzung einer im Signavio-Arbeitsbereich vorhandenen Vorlage oder Signavio-externen Link zu einer Vorlage
Ist Status von	Falls ein Leitobjekt existiert, wird dieses hier angegeben
Hat als Status	Falls das Prozessobjekt ein Leitobjekt ist, werden alle Statusobjekte hier angegeben
Format	Angabe, in welchem Format dieses Prozessobjekt ist

Organisational structure (DE: Aufbauorganisation)

Die Kategorie Aufbauorganisation beinhaltet alle Glossareinträge, die sich auf Beteiligte und Interesseneigener an den Prozessen beziehen.

Die Aufbauorganisation ist in vier Unterkategorien unterteilt:

Roles (DE: Rollen)	Rollen beschreiben personen- und stellenunabhängig Zuständigkeiten. Sie werden in Schwimmbahnen eingetragen und in Tätigkeiten nach dem RACIX-Modell (Siehe Kapitel Rollen)
Positions (DE: Stellen)	Einer Stelle ist mindestens eine Rolle und genau eine Person zugeordnet
Individuals (DE: Personen)	Eine Person kann Stelleninhaber und Rollenträger sein
Commitees (DE: Gremien)	Eine Person oder Rolle kann Mitglied eines Gremiums sein

Beispiel für den Eintrag einer Rolle in einer Tätigkeit über das I im RACIX-Modell:

Die Unterkategorien haben verschiedene Attribute wie folgt:

Attribute Positions (DE: Stellen)	Verwendung
Stelleninhaber	Jede Stelle kann nur einer Person zugewiesen werden, die in diesem Attribut genannt wird
Rollen	Eine Stelle setzt sich aus mindestens einer Rolle zusammen. Alle Rollen der Stelle werden in diesem Attribut aufgelistet

Attribute Roles (DE: Rollen)	Verwendung
Rollenträger	Im Normalfall bleibt dieses Attribut leer. Für die Rollen PcOff, PcDes und PcExSup wird empfohlen, den Rollen direkt eine Person zuzuweisen, damit Nutzer mit einem Klick die Daten der betreffenden Person finden können
Typ der Rolle	Eine Rolle kann eine Individual-, Haupt- oder Erbrolle sein. Hauptrollen (EN: Primary Roles) sind generische Rollen, die in Erbrollen (EN: Secondary Roles) runtergebrochen werden. Individualrollen stehen allein, haben weder zu Haupt- noch zu Erbrollen Bezug. Zusätzlich gibt es noch Scheinrollen (EN: Pretended Roles) die es ermöglichen Mitgliedern von Gremien und Inhaber einer Stelle der Aufbauorganisation über RACIX handhaben zu können.
Hauptrolle	Wenn eine Rolle eine Erbrolle ist, wird die Hauptrolle, aus der die Erbrolle abgeleitet ist, in diesem Attribut genannt
Erbrollen	Wenn eine Rolle eine Hauptrolle ist, werden die daraus abgeleiteten Erbrollen in diesem Attribut genannt

Mehr Informationen über die Verwendung von Rollen finden sie in Kapitel Rollen.

Attribute Individuals (DE: Personen)	Verwendung
E-Mail	-
Mobiltelefon	-
Durchwahl	-
Geschlecht	-
Vorname	-
Weitere Vornamen	-
Titel	-
Nachname	-
Kurzbezeichnung	-
Personalnummer	-

Attribute Committees (DE: Grämien)	Verwendung
Mitglieder	Einem Gremium können Personen direkt zugewiesen werden
Rollen	Ein Gremium kann zugehörige Rollen haben, die als Mo (Member of) Grämium auch als Committees-Glossarbegriff angelegt werden. Bsp: MoPjSC

Change histories (DE: Änderungshistorien)

Die Kategorie Änderungshistorien beinhaltet alle Glossareinträge, die Änderungen im CMS dokumentieren.

Die Kategorie Änderungshistorien ist in fünf Unterkategorien unterteilt wie folgt:

Change histories system (DE: Änderungshistorien System)	Enthält einen Glossareintrag für das CMS als Ganzes. Inhaltlich aufgeteilt in Abschnitte je CMS-Release. Die Freigabemitteilung CMS wird an diesen Glossareintrag angehängt.
Change histories process (DE: Änderungshistorien Prozess)	Enthält einen Glossareintrag je Hauptprozess. Inhaltlich aufgeteilt in Abschnitte je Prozess-Release. Die Freigabemitteilung Prozess wird an diesen Glossareintrag angehängt.

Hier hat nur die Unterkategorie Änderungshistorie Glossareinträge und Dokumente zusätzlich den Standard-Attributen ein zusätzliches Attribut:

Attribute Change Histories process (DE: Änderungshistorie Prozess)	Verwendung
Abhängige Glossareinträge	Da jeder Glossareintrag einen Heimatprozess braucht, werden in jeder Änderungshistorie Glossareinträge und Dokumente alle Glossareinträge dieses Hauptprozesses aufgelistet. Wobei bei Statusobjekten nur das Leitobjekt benannt werden muss.

Der CMS Design Quality Responsible erweitert vor jeder CMS-Veröffentlichung die Änderungshistorie CMS und erstellt eine Freigabemitteilung CMS und hängt diese an das Attribut Mitgeltende Dokumente des Glossareintrags Änderungshistorie CMS ein.

Die   Änderungshistorie CMS ist an die Startseite des CMS angebunden.

Der Prozessmodellierer (PcDes) muss alle Änderungen an einem Prozess in einer entsprechenden Änderungshistorie dokumentieren. Da in der Realität nicht jedes Prozessdiagramm individuell überprüft, freigegeben und veröffentlicht werden soll, sondern stets ein ganzer Hauptprozess mit allen seinen Unterprozessen, werden Änderungshistorien je Hauptprozess verfasst und in den Änderungshistorie-Attributen des Hauptprozesses als Links eingetragen:

Die Struktur einer Änderungshistorie Prozess sieht wie folgt aus:

Titel ist das Präfix CHP (Change history process DE: Änderungshistorie Prozess) gefolgt von Prozessnummer (falls vorhanden) und Name des Hauptprozesses
(Beispiel: CHP 42.03 PEP Entwicklung singuläres Produkt)

In der Beschreibung wird erst der Zweck dieser Änderungshistorie genannt und nach einer durchgezogenen Linie folgen Listen der Änderungen, und zwar je Version eine Liste, die Listen sortiert von neu nach alt.

Jede Version wird die Änderungshistorie eingeteilt und beginnt dann mit folgendem Satz: 
In der Version N sind folgende Sachverhalte neu (N), upgedatet (U) oder entfernt (E):

Die Struktur der Änderungshistorie System, also des gesamten CMS, ist wie folgt:

Titel ist das Präfix CHS (Change history system, DE: Änderungshistorie System) gefolgt von CMS (Beispiel: CHS CMS)

In der Beschreibung wird erst der Zweck dieser Änderungshistorie genannt und nach einer durchgezogenen Linie folgen Listen der Änderungen, und zwar je Version eine Liste, die Listen sortiert von neu nach alt. Jede Liste beginnt mit dem Satz:
In der Version NN.NN.NN sind folgende Prozesse neu (N), upgedatet (U) oder entfernt (E):

Hinweis: Die von cip alpha ausgelieferte Änderungshistorie des CMS CM ist eine Änderungshistorie des Referenzmodells. Diese Änderungshistorie hat den Namen CH CMS RM. Es ist Sache des SUDOQU-Nutzers nach Übernahme des Referenzmodells die Änderungshistorie CMS RM zu einer Änderungshistorie CMS des Custom Modells (CM) zu machen.

 

Im Attribut Mitgeltende Dokumente werden im PDF-Format alle Freigabemitteilungen dieses Hauptprozesses hinzugefügt.

Die Struktur einer Freigabemitteilung des Systems, also des gesamten CMS, ist wie folgt:

Titel ist das Präfix RNS (Release note system, DE: Freigabemitteilung System) gefolgt von CMS (Beispiel: RNS CMS)

In der Beschreibung wird der Zweck dieser Freigabemitteilung genannt.
Im Attribut Mitgeltende Dokumente werden im PDF-Format alle Freigabemitteilungen des CMS hinzugefügt.