Impostazioni di record

È possibile utilizzare impostazioni a livello di sistema per tipi record, per facilitare la gestione, la suddivisione in categorie e l'applicazione di politiche di sicurezza ai processi di lavoro.
I seguenti tipi di impostazioni valide per l'intero sistema servono alla gestione sia dei progetti che del lavoro:

I record ALMSecurityPolicy sono associati a una categoria e a dei progetti, mano a mano che vengono creati progetti che fanno riferimento alla categoria. Per i team che si occupano dello sviluppo del componente, possono esistere diversi componenti, ognuno con le proprie categorie e release, che fanno parte di una o più offerte. In questo caso, una relazione di tipo uno a uno tra una categoria e una politica di sicurezza, può provocare la mancata visualizzazione di alcuni record a persone che invece devono vederli. Per evitare problemi di visualizzazione, una politica di sicurezza deve includere un ampio gruppo di utenti ClearQuest come proprio riferimento ratl_context_groups oppure un gruppo di utenti per ciascun componente con tutti i gruppi di utenti a cui fa riferimento la politica di sicurezza che verrà condivisa da tutti i team di sviluppo che lavorano sui componenti. Esistono anche dei benefici sulle prestazioni nel gestire una serie di gruppi più piccoli piuttosto che utilizzare un unico ampio gruppo (o piuttosto che impostare una politica di sicurezza sul gruppo Everyone) e organizzare i gruppi e i record delle politiche di sicurezza in base alla struttura dei componenti.

Esempio di sviluppo del componente

Ciascuna versione di una parte di nuovo lavoro di sviluppo può rappresentare un progetto con una categoria che specifica il componente e un release che specifica la versione di tale categoria.

Un cliente trova un problema in un prodotto principale prodotto dal team di sviluppo. Questo prodotto (a cui si fa riferimento come a un'offerta) include diversi componenti, ciascuno dei quali è sviluppato da team separati. Quando il cliente nota il problema, pensa che esso sia relativo all'offerta e non ai componenti dell'offerta. Quando il responsabile del team segue il processo di selezione di una richiesta per tale offerta e riesamina la richiesta, si noterà che:
  • Il problema è presente in un componente e non nell'offerta e deve essere risolto nel componente non nell'offerta che potrebbe essere nient'altro che una raccolta di componenti e non disporre di alcuna parte di codice propria tranne ciò che proviene dai componenti che contiene
  • L'offerta deve includere la nuova versione del componente una volta corretta e una nuova versione di tale offerta deve essere fornita almeno al cliente che ha individuato il problema e probabilmente a tutti gli altri clienti.
Il team di selezione crea due record ALMTask associati alla ALMRequest inoltrata sul progetto per una data categoria e release (ad esempio, Category='OfferingA' e Release = '1.0'):
  • ALMTask con Project Category='OfferingA' e Release = '1.1'
  • ALMTask con Project Category = 'ComponentZ' e Release= '3.4'
Il team di selezione ha prima riesaminato il record ALMBaseline per Project Category='OfferingA' e Release = '1.0' poiché questi valori sono quelli che la ALMRequest ha identificato nel campo FoundInProject, e il team può vedere che il release di 'ComponentZ' elencato nel campo ComposedOfBaselines dell'ALMBaseline è Release = '3.3'.

Vengono create attività per la ALMTask per 'ComponentZ' e la soluzione viene sviluppata, documentata e sottoposta a test. Viene creato un record ALMBaseline al momento della creazione della baseline effettiva per Project Category = 'ComponentZ' e Release = '3.4' e viene creata una seconda ALMBaseline per Project Category = 'OfferingA' e Release = '1.1' e quel record ALMBaseline ha un valore per ComposedOfBaselines (un altro record Baseline) corrispondente a Project Category = 'ComponentZ' e Release = '3.4'.

Viene creata una BTBuild per la ALMBaseline con i valori Project Category = 'OfferingA' e Release = '1.1'. I tester possono vedere che una BTBuild viene visualizzata nella colonna Build e nella colonna Composite.Build dell'attività 'Dev' visualizzata nel controllo modulo attività dell'operazione i cui valori sono Project Category = 'OfferingA' e Release = '1.1'. Essi possono vedere che è presente almeno l'ID di una build prodotta dalla baseline composta e, nella serie di risultati della query, possono vedere il nome di tale build. I tester del componente e i tester dell'offerta possono entrambi vedere che esiste una build basata su una baseline composta.

Nel record della baseline composta il componente è elencato nel campo ComposedOfBaselines.


Feedback