 |
| | | | | Beschreibung der Komponente | | Jedes Artefakt in der Softwareentwicklung muss eindeutig identifizierbar sein. Daher müssen Identifizierungsregeln aufgestellt werden, die festlegen:
- Struktur des Identifikators,
- Informationen, die der Identifikator enthalten soll,
- Verfahren zur Änderung des Identifikators bei Änderung des Artefakts (vgl.
 Balzert2).
Die Nummern orientieren sich meistens an den Versionen des Softwareprodukts und geben damit dem Entwickler ggf. nützliche Anhaltspunkte, um die richtige Version schneller zu finden. Der numerische Identifizierer muss deshalb zumindest den gleichen Informationsgehalt der Versionsnummer besitzen.
Zur besseren Lesbarkeit sollte der Identifikator nicht nur Nummern, sondern auch Buchstaben enthalten, die z. B. Rückschluss auf den Dokumentnamen geben.
Zur Verdeutlichung wird zunächst eine Möglichkeit zur Versionierung aufgezeigt, die letztlich Vorlage für die Kennzeichnung im Konfigurationsmanagement ist. Eine Version besteht aus bis zu vier Nummern, z. B. 3.11.2.1.
Die erste Nummer steht für das Release, die zweite für den sogenannten Level in dem Release. Diese Kennzeichnung würde genügen, wenn grundsätzlich eine sequentielle Entwicklung stattfinden würde. Dies ist jedoch selten der Fall. Um beispielsweise mehrere Kunden mit leicht verschiedenen Ansprüchen bedienen zu können, müssen verschiedene Versionen (Varianten) eines Releases erzeugt werden.
Um in einer Variante weiterentwickeln zu können, besteht ihre Kennzeichnung ebenfalls aus zwei Nummern. Damit steht die dritte Nummer im oben genannten Beispiel für die Variante "branch" und die vierte für die Sequenz "sequence" in der Variante.
Varianten dienen nicht ausschließlich der Kennzeichnung paralleler Entwicklungen, sondern werden beispielsweise auch für die Identifizierung unterschiedlicher Implementierungen derselben Schnittstelle (die allerdings die gleiche Funktionalität besitzen) oder für unterschiedliche Hard- und/oder Softwarekonstellationen eingesetzt.
Zusammenfassend könnte eine Regelung nach den eingangs erwähnten Anforderungen folgendermaßen aussehen: | Struktur | <15 Buchstaben>_<1 - 3 Ziffern>_<1 - 3 Ziffern>_<1 - 3 Ziffern>_<1 - 3 Ziffern> |
Informationen | <Dateiname>_<Release>_<Level>_ <Branch>_<Sequence> | | Anpassungsregeln |
Der Dateiname darf nach Erzeugung des Artefakts nicht mehr geändert werden. Die Release-, Level-, Branch- und Sequence-Nummern sind dem Versionierungswerkzeug anzupassen. | | Beispiel |
Kundendaten_2_12_2_0 |
Dies ist ein sehr einfaches Beispiel. In verschiedenen Systemen werden weitere Informationen, z. B. zur Produktstruktur, in das Nummerierungsschema integriert (siehe auch Projektmanagement). | |
| | | | | | | | | | | | | Zu dieser Seite wurden noch keine Kommentare oder Bewertungen abgegeben. |
|
| | | | |  | Übergeordnet | | | | | | | | | | | Nummerierungsschema | | | | | | Literaturhinweise | | | | | | | | | | | | | Weitere Themen | | | | | | | | | | |
|
Glossar 
Forschungsprojekte 
Anbieterverzeichnis 
Datenbanksuche 
Highlights 
Eintrag kommentieren
