Newsgroup: it.discussioni.iso9000
Titolo: qualità nelle aziende di sw

Saluto tutti i partecipanti al NG.
Mi perdoni l'ormai famoso (per me!) Franco Tessarollo, ma vorrei fare una domanda a chi si occupa qualità nelle aziende di sw: cosa si intende per gestione della configurazione??
Ma perchè la si chiama così e non Gestione tecnica della comessa?
Forse sono troppo fuori dai binari, però sono scusato... in 10 gg di ferie ne ho fatti 7 in ospedale con le coliche!! Che sfiga!
Un'altra domanda ancora:
ho notato che si tende a definire diversi ambienti: di sviluppo, di test (unità, integrazione, sistema), di collaudo ecc., dando diversa dislocazione fisica al progetto nelle sue varie fasi (e stati); tutto ciò non appesantisce il lavoro degli sviluppatori?
Io ho "concordato" con i nostri programmatori una modalità differente, che non costringe a fare continui spostamenti di progetti. Se questo è un argomento di interesse possiamo approffondirlo.
Ciao a tutti e grazie in anticipo per le eventuali risposte.
----------------------------------------------
Virgilio Mail - Il tuo indirizzo E-mail gratis
http://mail.virgilio.it
--
Posted from [212.48.4.46] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 ha scritto nel messaggio
news:20000830150750.SRTB17490.mta1@[212.48.4.51]...


 ho notato che si tende a definire diversi ambienti: di sviluppo, di test
(unità, integrazione, sistema), di collaudo ecc., dando diversa dislocazione
fisica al progetto nelle sue varie fasi (e stati); tutto ciò non
appesantisce il lavoro degli sviluppatori?
Questo discorso della dislocazione fisica non mi è chiaro. Noi facciamo
sviluppo nello stesso luogo fisico dove si fanno i test, possibilmente su
macchine diverse (tra l'altro per noi test significa spesso riprodurre le
condizioni "tipo" di traffico telefonico, perché il nostro software
interfaccia la telefonia). Il collaudo lo facciamo ufficialmente presso il
Cliente.
Spero di averti dato una manina
ISOSbe

 tali requisiti.
Anche da noi si usa Source Safe, funziona veramente bene ai fini ISO, e
anche prima di cominciare a parlare ufficialmente di Qualità funzionava
proprio bene dal punto di vista della reperibilità dei vari step di sviluppo
(anche perché sullo stesso pezzo di codice lavorano contemporaneamente più
persone, si farebbe fatica a reintegrare tutto, e se dopo non funziona più
nulla sai dove andare a cercare l'errore)
La Simona

 Mi perdoni l'ormai famoso (per me!) Franco Tessarollo, ma vorrei fare una
domanda a chi si occupa qualità nelle aziende di sw: cosa si intende per
gestione della configurazione??
[cut]
Non sapevo di essere "famoso", comunque grazie per l'apprezzamento.
Premesso che nella UNI EN ISO 9000-3 "Guida per l'applicazione della ISO
9001:1994 allo sviluppo, alla fornitura, all'installazione ed alla
manutenzione del software per elaboratore" al § 4.8 Identificazione e
rintracciabilità del prodotto viene secondo me espresso piuttosto
chiaramente cosa si intende per "gestione della configurazione" nell'ambito
del SW, ritengo utile provare a chiarire i concetti che stanno alla base
della disciplina della gestione della configurazione del SW con un esempio
pratico.
Supponiamo che la tua ditta intenda progettare, sviluppare e
commercializzare un SW su PC per la gestione dei documenti del Sistema
Qualità. Il SW verrà realizzato in C e utilizzerà un DB relazionale (es.
Oracle) per la memorizzazione dei dati.
Occorrerà affrontare e risolvere i seguenti problemi:
1) occorre definire l'ambiente di sviluppo (i PC dei programmatori dove si
fa coding, debug e test a livello di singolo programma), individuando la
configurazione del SW di base necessario (compilatore C, Oracle ecc.)
2) occorre definire un ambiente ove poter sottoporre a test l'intero
sistema, prima del suo rilascio (ambiente di test)
3) occorre definire un ambiente dove si prepareranno i kit di installazione
delle varie versioni del pacchetto e si masterizzeranno i CD (ambiente di
rilascio)
4) occorre definire i requisiti dell'ambiente dove il pacchetto verrà
installato (Sistema Operativo, DB Oracle ecc)
5) occorre individuare le tipologie di oggetti che intendiamo tenere sotto
controlllo della configurazione (es. i sorgenti C, i .h, i tracciati record
delle tabelle Oracle, la documentazione, l'help on-line, ecc.): l'insieme di
questi oggetti costituirà la nostra applicazione quindi è necessario che
(per ogni versione) essi siano congruenti tra loro
6) occorre individuare una modalità per la gestione delle versioni che
rilascieremo nel tempo
7) occorre definire un insieme di regole che governeranno il transito degli
oggetti tra i vari ambienti (es. un programma passa dall'ambiente di
sviluppo all'ambiente di test solo dopo il superamento del debug e dei test
che il programmatore svolge per verificarne la funzionalità in un contesto
controllato; avulso dal resto del sistema, se possibile, per evitare effetti
di disturbo collaterali)
8) occorre individuare responsabilità specifiche per assicurare che le varie
versioni del sistema siano sempre in uno stato noto e congruente e per
evitare che lo stesso oggetto possa essere modificato in contemporanea da
più persone (il responsabile della gestione della configurazione)
9) occorre definire delle regole per la gestione delle modifiche ai
programmi (correzioni, nuove implementazioni) che garantiscano che
l'introduzione di tali modifiche non abbia effetti collaterali negativi sul
sistema
10) ecc. ecc.,
...insomma occorre definire delle regole per la gestione degli oggetti e
degli ambienti, che dovranno essere applicate durante tutto il ciclo di vita
del software (che se vuoi puoi anche chiamare "gestione tecnica della
commessa")
Tipicamente si consiglia di predisporre un Piano di Gestione della
Configurazione che tratti tutti questi argomenti definendo le scelte
organizzative e le regole da applicare. Il Piano di Gestione della
Configurazione dovrebbe prevedere poi uno o più Archivi della Configurazione
dove - per ogni oggetto sotto controllo della configurazione - viene
registrato lo stato e la versione.
Solitamente si tende ad identificare l'Archivio della Configurazione con
delle librerie (directories) che contengono gli oggetti, sfruttando le
informazioni che le librerie stesse mettono a disposizione sugli oggetti che
contengono (es. la data dell'ultimo aggiornamento) oppure strumenti per la
gestione automatica delle versioni (come SourceSafe, PVCS e altri) che
associano agli oggetti informazioni specifiche di gestione (es. versione,
storia delle modifiche ecc.) e che facilitano la gestione delle versioni
(es. gestiscono automaticamente l'incremento delle versioni e le relazioni
di dipendenza tra i vari oggetti).
Personalmente (ma mi pare che questa affermazione sia in gran parte
condivisa anche dagli Enti di Certificazione) ritengo che il semplice
utilizzo di uno strumento di source management come SourceSafe non sia in
grado da solo di rispondere appieno alle necessità della Gestione della
Configurazione, anche se può risolvere gran parte dei problemi
automatizzando l'applicazione di alcune regole. Un Piano di Gestione della
Configurazione che definisca le regole di base e si appoggi a SourceSafe per
l'applicazione delle regole di dettaglio e per la registrazione dello stato
della configurazione mi sembrerebbe più appropriato.
Chiedo scusa per la lungaggine, ma volevo tentare di essere più chiaro
possibile: ci sono riuscito ?
Sarò a Parma il 13 ed il 15 (presso lo stand Webegg).
Ciao a tutti e.... attenti al Gorilla !
--
Franco Tessarollo
Webegg SpA
http://www.webegg.it
T: 
+39 051 6587542
F: 
+39 051 6587560
C: +39 (0)335 5643163
E: mailto:
tessarol...@webegg.it