Presentazione in Italiano su Version / revision / release

1. ArCo
VERSIONI / REVISIONI /
RILASCI
• Definizioni
• Utilizzo di System Architect per la
modellazione degli “stati”
• Tools

2. DEFINIZIONI ArCo
• Versione - l’istanza di un prodotto che è in qualche
modo funzionalmente diversa da altre
• Variante - l’istanza di un prodotto che, pur essendo
funzionalmente identica ad altre, è diversa dal punto
di vista non-funzionale
• Release - L’istanza di un prodotto distribuita ad utenti
(interni o esterni) che siano al di fuori del gruppo di
sviluppo

3. Genesi delle Versioni ArCo
È richiesta una nuova versione/revisione di un prodotto per:
• Soddisfare le richieste/esigenze del
cliente/mercato
• Definire un nuovo stato del ciclo di vita del
prodotto
• Differenziare il prodotto dopo
l’implementazione di una modifica

4. Esigenze del
Cliente/Mercato ArCo
Options X Variants
• 2 body styles • Upgraded suspension
• 2 engine variants system
• 2 climate control • Upgraded electronics
variants options
• 2 wheel sizes • Moon roof option
• Trim upgrade options
= 256 Product Variations

5. STATI DEL CICLO DI VITA
ArCo
In Elaborazione
Transition: definisce i tasks da
Redazione
compiere per fare passare un
documento da uno stato all’altro
Da Riesaminare
Riesame
Riesaminato
Approvazione
Stato Approvato
Rilascio
Rilasciato

6. STATI E VERSIONI
ArCo
Stato Versione Versione Versione Versione
1 2 3 4
1. In
elaborazione
2. Da
riesaminare
3. Riesaminato
4. Approvato Riesame
negativo Riesame
Approvaz.
negativo
rigettata
5. Rilasciato

7. Richiesta di modifica
ArCo
Time Now
Stable
PR V2.6 PR V2.7 PR V3.0 PR V3.1 Planned PR V4.0
Item/ Release
ECO A Stable Latest
PR Rev 2.3.0
V2.7.1.1 Planned
ECO B
Product 2.6.1.1 3.0 3.1
PR PR
V2.7.2.1 V2.7.2.2
Item
1.2 1.2 1.3
Rel. 2.3.0
PR PR Planned PR A
V2.6.1.1 V2.6.1.2 V2.6.1.3
Item
1.1 1.1 1.1
IA V1.2 IA V1.3 Planned IA V2.0 B
Item
Rel. 2.3.0 IB V1.1 1.1 1.1.1.1 1.2
Stable C
IC V1.1 IC V1.2
Rel. 2.3.0
ECO C
IC
Stable V1.1.1.1
Richiesta di
modifica

8. PROCESSO DI GESTIONE
DELLE VERSIONI ArCo
1. Definire uno schema di identificazione
delle versioni
2. Pianificare l’implementazione di nuove
versioni
3. Assicurarsi che le metodologie e gli
strumenti di controllo siano utilizzati
correttamente
4. Pianificare il rilascio (release) di nuove
versioni

9. IDENTIFICAZIONE DELLE
VERSIONI ArCo
• Bisogna mettere a punto procedure che
consentano di identificare le versioni in
modo non ambiguo
• Ci sono tre tecniche di base:
– Numerazione delle versioni
– Identificazione mediante attributi
– Identificazione orientata alle modifiche

10. NUMERAZIONE DELLE
VERSIONI ArCo
• Si può usare un semplice schema di
enumerazione lineare
– V1, V1.1, V1.2, V2.1, V2.2, ecc.
• Oppure uno schema di derivazione ad
albero gerarchico
• I codici non sono “parlanti” (significativi)
• Per ridurre gli errori di identificazione
conviene usare schemi di tipo gerarchico

11. NETWORK DI DERIVAZIONE
GERARCHICA (Notazione “IDEF3 OST”) ArCo
Release Merging Merging Release
2.3 2.4
Rev. 1.4 Rev. Rev. 1.6 Rev. 2.0 Rev.
1.5 2.1
Variant B
Temporary Branch B
Variant A Ver.
1.5.1.1
Temporary Branch A
Permanent Branch
Ver. Ver.
1.5.2.1 1.5.2.2
Ver. Ver. Ver.
1.4.1.1 1.4.1.2 1.4.1.3
Versions

12. BOUND CONFIGURATION ArCo
Rel. 2.2 Rel. 2.3
Item A
IA V 1.9 IA V 2.0 IA V 2.1 IA V 2.2
Item B
Rel. 2.2 IB V2.1 IB V2.2
Rel. 2.3
Item C
IC V 2.0 IC V 3.0 IC V 3.1
Rel. 2.2 Rel. 2.3
Build/Make Build/Make
Product
PR V2.7 PR V2.8 Rel 2.3

13. IDENTIFICAZIONE BASATA
SUGLI ATTRIBUTI ArCo
• Esempi di attributi utilizzabili:
– Data, Sviluppatore, Cliente, Status, ecc.
• È più flessibile dello schema di identificazione
esplicita per il rintracciamento delle versioni;
tuttavia bisogna prestare molta attenzione alla
scelta del set di attributi per garantire l’unicità
del nome
• In pratica si usa anche un nome per facilitare
il rintracciamento

14. IDENTIFICAZIONE BASATA
SULLE MODIFICHE ArCo
• Integra le versioni con le modifiche fatte per realizzarle
• È più usata per prodotti complessi che per i singoli
componenti
• Per ogni cambiamento proposto si identifica un set di
modifiche di riferimento tra quelle implementate per
realizzarlo
• I set di modifiche sono applicati in sequenza per
consentire, in linea di principio, la creazione di una
versione del prodotto che incorpori un set di modifiche
arbitrario

15. Key features ArCo
• Capability to define a single generic product structure from which an
entire range of product variants can be derived.
• Extend the generic product structure with variant conditions and
enumerated constraints.
• Variant conditions enable you to define what components and
subsystems can be configured in combination to create specific
product variants.
– You can use both simple and complex logical expressions to indicate
that a specific component (e.g., a particular model of a particular brand)
should be configured in the product variant.
• Capability to establish both soft and hard constraints to reduce the
number of variants that your platform can support on either
temporary or permanent basis.
• Capability to establish an option compatibility constraint to specify
that certain combinations of option values are not offered.

16. ArCo

17. RELEASE
MANAGEMENT ArCo
• Una “Release” comprende un certo numero di modifiche
al prodotto indotte da malfunzionamenti scoperti
dall’utente o resesi necessarie per cambiamenti nelle
tecnologie
• Può anche incorporare nuove funzionalità
• La pianificazione delle Releases consiste nel decidere
quando rilasciare una versione del prodotto come nuova
release tenendo conto di:
– Qualità tecnica del prodotto
– Concorrenza
– Forze di mercato
– Soddisfazione del cliente

18. VERSION MANAGEMENT
TOOLS ArCo
• Version and release identification
– Assegna automaticamente i codici di identificazione
• Storage management
– Archivia le differenze (varianti) tra le versioni
• Change history recording
– Registra le ragioni per cui viene creata una nuova versione
• Independent development
– Consente di lavorare in parallelo su versioni diverse
• Project support
– Consente di gestire “in gruppo” tutti i files associati ad un
progetto di modifica