Sistema di spedizione per azienda logistica LBDS

Transcript

1 CONFIGURATION MANAGEMENT PLAN Sistema di spedizione per azienda logistica LBDS Gruppo Laboratorio di Ingegneria del Software 2 Anno Accademico2009/2010 Gruppo Kairos: Maiero Matteo, Bertoni Alan, Zolli Fabio, Racani Riccardo

2 0. Revisioni Versione attuale documento: VERSIONE: 228 DATA REVISIONE: 29/12/10 Storia revisioni: Versione Data versione Modificato da Descrizione modifiche 3 16/04/2010 Alan Bertoni, Fabio Zolli 61 03/12/2010 Alan Bertoni, Fabio Zolli Prima bozza documento Aggiornamento documento /12/2010 Maiero Matteo Aggiornamento documento Responsabile documento: Bertoni Alan Ualan_zid@msn.comU Membri team creazione documento: Zolli Fabio HUmag1ster@alice.itU Bertoni Alan HUalan_zid@msn.comU ii

3 Contenuti: Sommario 1. Introduzione: Obiettivi: Convenzioni nel documento: Acronimi ed Abbreviazioni: Riferimenti: Panoramica del Sistema: Contatti: Documenti interessati: Configuration Control (CC): Change Control Board (CCB): Configuration Items (CI): Identificazione della Configurazione: Ruoli e Responsabilità: Change Control Process: Classificazione delle modifiche: Change Control Request (CCR): Strumenti: Release Management: Configuration Status Accounting (CSA): Configuration Audits:... 9 iii

4 1.Introduzione 1. Introduzione: 1.1. Obiettivi: Il Configuration Management (CM) è il processo di identificazione e di gestione dei cambiamenti riguardanti deliverable ed agli altri oggetti generati durante l intero processo di sviluppo software. Il documento del (CMP) è redatto con l intento di definire, documentare, controllare e annotare tutte le proposte di modifiche riguardanti i Configuration Items del progetto corrente. Il CMP fornisce informazioni sui requisiti e sulle procedure necessarie per svolgere il CM. Per questo motivo identifica i Configuration Management Requirements (CMR) e stabilisce le procedure da seguire per l identificazione delle configurazioni, per il controllo delle release e per le modifiche ai Configuration Items (CI). Descrive inoltre, i processi per la gestione delle versioni dei CI e per la loro verifica di correttezza e completezza, durante tutto il ciclo di vita del sistema. Inoltre descrive le caratteristiche dei componenti in uso, in modo da garantire una valida documentazione per le successive integrazioni e aggiornamenti; stabilisce gli schemi formali per i nomi e per la struttura dei documenti; definisce uno schema univoco di identificazione per le varie versioni dei CI e in generale di tutti gli oggetti coinvolti nel processo software; infine, mantiene costantemente aggiornato l insieme di strumenti hardware e software utilizzati durante il progetto Convenzioni nel documento: Nel presente documento si utilizzeranno le seguenti convenzioni tipografiche. Per il testo ordinario, si è scelto un font Times New Roman con dimensione carattere pari a 12 punti. I titoli delle diverse sezioni e i singoli punti delle sottosezioni, avranno dimensione diversa, rispettivamente di 16 e 14 punti. Entrambi, comunque, verranno messi in risalto, rispetto al testo ordinario, tramite l utilizzo del grassetto. Per tutte le tabelle presenti nel documento sarà utilizzato il font Times New Roman, con dimensione dei caratteri pari a 11 punti; inoltre le intestazioni saranno evidenziate dall utilizzo del grassetto Acronimi ed Abbreviazioni: CC CI CCB CCP CCR CM CMR CVS LBDS Configuration Control Configuration Item Configuration Control Board Configuration Control Plan Configuration Change Request Configuration Management Configuration Management Requirements Concurrent Version System Logistic Business Dispatch System 1

5 1.Introduzione 1.4. Riferimenti: Per redigere il presente documento si è fatto ricorso ai seguenti testi: Principi di Ingegneria del software 5 edizione, Roger S. Pressman, McGraw- Hill Ingegneria del Software 8 Edizione, Ian Sommerville, Pearson Addison Wesley 1.5. Panoramica del Sistema: L azienda committente opera nel campo della logistica dei trasporti in ambito nazionale ed internazionale. Questi ultimi gestiti appoggiandosi ad altre aziende per quanto riguarda i trasporti navali e aerei. L applicazione software consiste nella gestione dei trasporti dell azienda logistica. La gestione è divisa in due parti, rispettivamente front-end ed il back-end. Il front-end dell applicazione è la parte cui possono accedere gli utenti per effettuare la prenotazione di un trasporto, per modificare quelli che sono i dati associati all utente stesso, vedere lo storico dei trasporti o infine, tracciare il trasporto corrente. Il back-end del sistema software si occupa della gestione clienti, del controllo dei trasporti in corso, del mantenimento delle risorse disponibili e della gestione delle politiche di overbooking. Attributo: Nome società Nome dell applicazione Valore: Kairos LDBS 1.6. Contatti: Di seguito sono riportati i contatti, che possono essere usati dagli utenti del documento per scopi informativi o per la risoluzione dei problemi tecnici. Lead Manager: Maiero Matteo fmaiero@hotmail.it Technical Support: Bertoni Alan alan_zid@msn.com Zolli Fabio mag1ster@alice.it Racani Riccardo ddragon@hotmail.it 2

6 1.Introduzione 1.7. Documenti interessati: Di seguito è riportata una tabella contenente tutti i documenti interessati dal controllo del CM, i quali sono memorizzati all interno del repository LBDS. Nome Documento LBDS_REQ_SRS LBDS_REQ_DOC LBDS_PLN_CM LBDS_PLN_QUALITY LBDS_PLN_COSTSEST LBDS_PLN_METRICS LBDS_PLN_DESIGN LBDS_PLN_DOC Titolo Software Requirements Specification Requirements Document Software Quality Document Software Cost Estimation Software Metrics Document Software Project Design Document Software Planning Document 3

7 2.Configuration Control 2. Configuration Control (CC): Il CC consiste nella valutazione, accettazione o meno, ed infine, implementazione di ogni proposta di modifica per quanto riguarda un CI, previa rigorosa definizione delle versioni stabili. Le procedure devono essere stabilite in modo tale da assicurare che i cambiamenti siano realizzati in maniera ingegnerizzata e, in modo tale da essere tracciabili. Le richieste di modifiche al software, all'hardware, alle strutture dati o alla documentazione, vengono analizzate formalmente in modo tale da valutare gli effetti dei cambiamenti sulla sicurezza, le performance, le interfacce, la completezza, e la documentazione, ed infine approvate, qualora fossero ritenute idonee. Nel momento in cui viene identificato un oggetto da porre sotto CC, il CM provvederà ad assegnare un nome univoco al CI e quest ultimo verrà aggiunto al CM repository con la relativa denominazione. I membri del team potranno effettuare il check-out dei CI, la modifica ed il commit del CI stesso al CM repository. I membri del team dovranno descrivere con accuratezza i cambiamenti apportati al CI nel momento in cui effettueranno il commit. Gli sviluppatori sono esortati a testare le varie parti prima di eseguirne il commit Change Control Board (CCB): Il CCB è il team che ha il compito di approvare o meno tutte le CCR, prima che possano essere effettivamente apportate le modifiche al sistema. IL CCB agisce su tutte le modifiche che causano cambiamenti sostanziali al sistema come, ad esempio, i cambiamenti alle specifiche di design, al budget, al piano strutturale del progetto o alle caratteristiche di interfacciamento verso altri sistemi software. Qualsiasi modifica riferita ad una versione stabile deve essere sottoposta all analisi del CCB compilando l apposito form CCR. In figura (fig.1) è riportata il processo di analisi di una CCR. Il CCB ha il compito di decidere se accettare o meno la CCR. Nel caso in cui la CCR venga respinta, la stessa può essere modificata per poi poter essere riconsiderata dal CCB. Nel caso in cui venga accettata verranno stabiliti i nuovi requisiti che daranno vita alla nuova versione stabile e nel contempo verranno informate tutte le persone interessate dalle modifiche proposte. 4

8 2.Configuration Control Figura 1: Processo di analisi di una CCR Inoltre, all interno del CCB sono presenti le seguenti cariche: Lead Manager responsabile dell intero progetto software Configuration Manager responsabile del mantenimento e della gestione delle modifiche ai componenti software Document Manager responsabile del mantenimento e dell aggiornamento dei documenti redatti 2.2. Configuration Items (CI): I CI rappresentano tutti i tipi di oggetti che riguardano, o sono coinvolti nel configuration control. Gli elementi che entreranno a fare parte dei CI sono elencati di seguito: Documentazione riguardante lo sviluppo, o la gestione dello sviluppo del sistema, come ad esempio il CM Plan Documentazione di carattere tecnico, che descrive il sistema, come ad esempio Software Requirements Specification Componenti Software (codice sorgente, strumenti di supporto) Altre componenti, che potranno essere incluse a discrezione del CM 2.3. Identificazione della Configurazione: Il Configuration Management si applica sia alla documentazione, sia ai codici sorgenti del progetto. A ciascun oggetto sarà attribuito un identificativo univoco. La gestione delle revisioni e delle versioni è dovuto al software SVN. Il numero di revisione, per un dato CI, deriva dalla politica adottata dall SVN, di conseguenza si avrà un incremento di revisione per ogni operazione di COMMIT eseguita. 5

9 2.Configuration Control 2.4. Ruoli e Responsabilità: Le principali cariche e responsabilità nelle attività di Configuration Management sono riportate di seguito. Analizzare le richieste di modifica CCR; Stabilire la data in cui saranno effettuate le modifiche approvate e determinare la release; Organizzare e documentare le varie riunioni del CCB; Disporre dei vincoli sui cambiamenti per le successive release; Mantenere aggiornato il CM Plan; Identificare i Configuration Items e definire le rispettive caratteristiche; Gestire il LBDS repository; Effettuare riunioni periodiche al fine di verificare la conformità rispetto al CM Plan; Effettuare i build di sistema, e tenere costantemente traccia delle release così create; 6

10 3.Change Control Process 3. Change Control Process: Questa sezione descrive il modo in cui le CCR devono essere compilate, analizzate ed, infine, portate a termine. Inoltre esprime i compiti del CM nelle verifiche e nei controlli durante l intero ciclo di vita del progetto Classificazione delle modifiche: Le modifiche verranno catalogate e prese in considerazione in base ad un fattore di priorità. I fattori caratterizzanti il grado di priorità sono i seguenti: Criticità Correlazione Interfaccia Vincoli temporali Complessità Tutti i fattori riportati sopra, saranno valutati approfonditamente dal CCB, al fine di catalogare e classificare in maniera coerente tutte le richieste di modifica pervenute, in modo da poter definire le rispettive priorità Change Control Request (CCR): Di seguito si riporta il modulo, con cui dovranno essere tutte le richieste di modifica ai CI riguardanti il progetto corrente. Change Control Request Nome Progetto: Richiedente: Modifica richiesta: Esaminatore: Componenti interessati: Descrizione: Priorità: Data CCB: Decisione del CCB: Implementatore: Data invio al QA: Data invio al CM: Commenti: Data: Identificativo: Data analisi: Tempo Implementazione Previsto: Data Decisione CCB: Data cambiamento: Decisione del QA: 7

11 3.Change Control Process 3.3. Strumenti: Per il progetto LBDS si è scelto di utilizzate i servizi online offerti da Google. In particolare, abbiamo provveduto a creare un sito web del gruppo reperibile all indirizzo dove reperire materiale informativo e ultime notizie sul software prodotto dal gruppo kairos. Abbiamo sfruttato un ulteriore servizio Google, Google Code, per il versionamento, utilizzando SVN (ver ), il posting di Issues, il recupero di wiki, documenti e downloads. Queste informazioni sono reperibili a partire dal sito sopra citato o direttamente all indirizzo Il backup dell intero repository viene eseguito su base giornaliera, in automatico da Google. Il servizio integra anche la funzione di invio automatico ogni qualvolta viene effettuata una modifica ad un CI; è possibile inoltre, specificare un sottoinsieme di elementi, cui l utente è interessato a ricevere le relative notifiche. Per quanto riguarda i sistemi operativi vengono correntemente utilizzati Windows XP (Service Pack 3); Windows 7 Mac OS X (versione 10.6) L applicazione LBDS, sviluppata in Java (versione 6 update 22), è stata testata sull application server Glassfish (versione 3.0.x). Il database utilizzato sfrutta motore MySQL (versione 5.x). Lo sviluppo delle applicazioni avviene utilizzando l IDE NetBeans (versione 6.9.x) Release Management: Il Release Management prevede due attività principali per ogni nuova release: la stesura di un documento di release che specifica le ragioni principali e le caratteristiche di alto livello che sono richieste all interno della nuova release; l individuazione delle componenti hardware, software e documentali che rispondono alle esigenze segnalate nel documento di release; L attività di management delle release è svolta dal CCB nel momento in cui vengono a verificarsi le condizioni che determinano il rilascio della release. Il CCB ha stabilito quali siano le varie necessità che dovranno portare al rilascio di una nuova release, esse sono: la risoluzione di bug che vanno ad inficiare la corretta esecuzione dell applicazione o che interessano un numero elevato di componenti interagenti fondamentali per un funzionamento sicuro del software; le esigenze di marketing; le richieste di un cliente importate per l economia aziendale Configuration Status Accounting (CSA): Ogni attività intrapresa dal CM viene regolarmente registrata, archiviata e riportata dalla funzione del CSA. La funzione CSA è una disciplina atta a fornire un feedback costante e consistente ai manager, in modo da dare loro la possibilità di determinare se le scelte del CCB vengono implementate secondo quanto stabilito. Quando un cambiamento approvato viene messo in atto, la funzione CSA ne tiene traccia tramite file dati, relativi al software opportunamente modificato, all'hardware ed infine alla documentazione. La funzione CSA è responsabile dell'identificazione e del rilascio, della più recente versione approvata dei CI controllati dal CM, a tutti i partecipanti al progetto. 8

12 3.Change Control Process 3.6. Configuration Audits: Come specificato nel Project Plan, ad intervalli regolari prefissati, vengono condotte delle verifiche di configurazione formale. L'obbiettivo della verifica è quello di certificare che il design, lo sviluppo e l'integrazione soddisfino pienamente i requisiti tecnici di sistema; che vi sia un'accurata ed esauriente documentazione; e che non siano state introdotte modifiche non autorizzate. Nel caso di complessi sistemi di amministrazione, devono essere effettuate delle verifiche informali, così da minimizzarne l'impatto sulla pianificazione del progetto stesso, ed in modo tale da identificare le non conformità il prima possibile. Le irregolarità rilevate nel corso di una verifica informale, così come le sollecitazioni per qualsiasi azione correttiva, vengono rese disponibili per la revisione del CCB durante la verifica della configurazione. Le verifiche della configurazione certificano la conformità (dei) ai requisiti di sviluppo, effettuando un confronto tra il sistema funzionante e la sua relativa documentazione tecnica. 9