Progetto MindSlide NORME DI PROGETTO. Versione Dicembre CodeToBeWild Software Team.

Transcript

1 Progetto MindSlide NORME DI PROGETTO Versione Dicembre 2010 CodeToBeWild Software Team Data creazione 20 Dicembre 2010 Versione Stato ed Uso Redazione Verifica Approvazione Committente Proponente Revisione Formale, Interno Lorenzo Menza Matteo Ghion Elia Cavallaro Prof. Tullio Vardanega Zucchetti S.p.A. Revisione dei Requisiti [RR]

2 Progetto MindSlide [C1] Registro delle modifiche VERSIONE DATA RILASCIO DESCRIZIONE AUTORE Dicembre 2010 Versione definitiva Lorenzo Menza Dicembre 2010 Correzione impaginazione Lorenzo Menza Dicembre 2010 Correzione impaginazione Lorenzo Menza Aggiunta sezione Nomenclatura dei requisiti Dicembre 2010 Impaginazione e migliorie Lorenzo Menza Dicembre 2010 Prima bozza Lorenzo Menza Dicembre 2010 Creazione dello scheletro Lorenzo Menza Sommario Norme e convenzioni deliberate internamente a CodeToBeWild Software Team atte a regolamentare le attività di progetto. Norme di Progetto I

3 INDICE Indice 1 Introduzione Scopo del documento Glossario Riferimenti Riferimenti normativi Riferimenti informativi Infrastruttura di sviluppo Componenti Sistemi operativi Internet Browsers IDE di sviluppo Strumenti di verifica Modellazione UML Project Management Pianificazione VCS Documentazione Configurazione Licenza Comunicazioni Comunicazioni interne Comunicazioni esterne Sviluppo Project Management Issue Tracking Gestione dello Sviluppo Documentazione Uso del template Stato ed uso di un documento Norme di Progetto II

4 INDICE 5.3 Verifica e validazione Approvazione Nomenclatura dei requisiti Nomi dei file Norme tipografiche Layout di pagina Frontespizio Registro delle modifiche Indice Elenco delle tabelle Elenco delle figure Termini di glossario Annotazioni, link esterni e bibliografia Norme di Progetto III

5 1. INTRODUZIONE Capitolo 1 Introduzione 1.1 Scopo del documento Il presente documento intende delineare norme, convenzioni e linee guida relative ad ogni aspetto del progetto in questione, fissate da CodeToBeWild Software Team nell ambito delle consultazioni interne e degli incontri avvenuti con il Committente. Ogni componente di CodeToBeWild Software Team è tenuto ad attenersi scrupolosamente alle presenti norme; sarà compito del Responsabile verificare che ciò avvenga, ed eventualmente notificare all Amministratore violazioni che possano compromettere il corretto processo di sviluppo. 1.2 Glossario Il glossario raccoglie i termini, gli acronimi e le parole chiave inerenti al progetto in corso d opera utilizzati in tutta la documentazione. Per ragioni di sintesi, dal momento che detti termini saranno presenti nei diversi documenti, CodeToBeWild Software Team ha deliberato che detto glossario sarà reso disponibile in un file separato denominato glossario-x.y.z.pdf secondo la convenzione sui nomi dei file descritta nella relativa sezione delle Norme di Progetto. Se nel corso del processo di sviluppo dovesse comparire nel dominio applicativo un nuovo termine non ancora definito, questo dovrà obbligatoriamente essere inserito e definito in detto glossario. Norme di Progetto Pagina 1 di 12

6 1. INTRODUZIONE 1.3 Riferimenti Riferimenti normativi Capitolato d appalto MindSlide : Riferimenti informativi Glossario, allegato glossario pdf Norme di Progetto Pagina 2 di 12

7 2. INFRASTRUTTURA DI SVILUPPO Capitolo 2 Infrastruttura di sviluppo L ambiente di lavoro nel quale verrà sviluppato il sistema software preso in esame è composto dai componenti indicati a seguire. 2.1 Componenti Sistemi operativi Linux Ubuntu /10.10 Linux Arch x86 (Rolling Release) [ ] Apple MacOS X Snow Leopard Microsoft Windows(c) - Vista SP2/Seven Internet Browsers Mozilla Firefox Apple Safari Google Chrome 8 Konqueror WebKit/KHTML IDE di sviluppo Eclipse plugins: Aptana [ ] Subclipse [ ] Aptana Studio 2 [ ] Norme di Progetto Pagina 3 di 12

8 2. INFRASTRUTTURA DI SVILUPPO Strumenti di verifica JsUnit 2.2 [ ] FireBug [ ] Chrome Debugger (strumento di debugging di default di Google Chrome) JSCoverage [ ] Modellazione UML ArgoUML [ ] Project Management Google Project Hosting [ ] Pianificazione GanttProject [ ] VCS SVN (Subclipse) Documentazione L A TEX, editato con gli strumenti Emacs 22+ (GTK ) + package AUCTEX Kile Configurazione Le istruzioni di configurazione per la messa in opera e l utilizzo dell ambiente di sviluppo si trovano all interno del Wiki del Google Project Hosting di CodeToBeWild Software Team: Licenza Il sistema software oggetto del presente progetto verrà rilasciato sotto la licenza open source GPLv3. Norme di Progetto Pagina 4 di 12

9 3. COMUNICAZIONI Capitolo 3 Comunicazioni 3.1 Comunicazioni interne Le comunicazioni informali interne al gruppo di lavoro avvengono tramite Skype, applicazione che consente di effettuare instant messaging e chiamate gratuite su Internet tramite la tecnologia VoIP. Comunicazioni formali e coordinamento (issue tracking, formazione, etc.) si appoggiano alla piattaforma Google Project Hosting [ ] La calendarizzazione degli eventi di rilievo relativi allo sviluppo avviene tramite Google Calendar [ ] 3.2 Comunicazioni esterne Le comunicazioni formali esterne avvengono attraverso l indirizzo di posta elettronica GMail codetobewild@gmail.com Norme di Progetto Pagina 5 di 12

10 4. SVILUPPO Capitolo 4 Sviluppo 4.1 Project Management Come descritto nella Sezione 3.1, le attività di sviluppo e coordinamento di CodeToBeWild Software Team si basano sull ambiente di lavoro fornito da Google Project Hosting, ove sono disponibili strumenti atti allo scopo quali un sistema di ticketing, un gestore per il downloading, un wiki per documentazione online, repository, un sistema di amministrazione di progetto Issue Tracking Ogniqualvolta debba essere svolta un attività verrà creato nel sistema un ticket corrispondente. Ad ogni ticket sarà assegnato un titolo ed una descrizione sommaria, e sarà possibile specificare diversi attributi relativi allo stesso. Qui sotto ne elenchiamo i principali: Tipo: A scelta fra Defect, Enhancement, Task, Review e Other. Stato: I possibili stati dipendono dal ticket. Per i ticket aperti avremo a disposizione New, Accepted e Started. Per i ticket già chiusi sarà possibile assegnare lo stato Fixed, Verified, Invalid, Duplicate, WontFix o Done. Priorità: Potrà variare tra Low, Medium, High e Critical. Proprietario: Ogni ticket può essere assegnato direttamente alla persona responsabile di quel particolare componente al momento della sua creazione, oppure può essere preso in carico una volta che il ticket è stato creato da un altra persona. Milestone: Il progetto verrà suddiviso in diverse milestones in coincidenza delle revisioni da sostenere; in questo modo si potrà tener traccia della scadenza del ticket in oggetto. Sarà inoltre possibile allegare uno o più file utili alla gestione ed alla risoluzione del ticket stesso. Norme di Progetto Pagina 6 di 12

11 4. SVILUPPO Gestione dello Sviluppo I sistemi per il controllo di versione dovrebbero esser parte integrante degli strumenti di ogni sviluppatore; questi software tengono traccia di ogni modifica apportata ai file di un progetto, consentendo di ripristinare immediatamente una modifica sbagliata o esaminare le righe di un sorgente anche a distanza di giorni. Il funzionamento di base è semplice e comune a quasi tutti i software: si comincia definendo un repository, l archivio che conterrà tutto lo storico delle revisioni ed i cambiamenti applicati nel tempo ai file tracciati. Normalmente il repository principale è salvato in un area accessibile a tutti i componenti del team, come ad esempio un server o una intranet; ciascun utente possiede nel computer locale una copia di lavoro del repository chiamata working copy. L utente esegue le modifiche ai file direttamente sulla propria working copy e, una volta terminate, invia le modifiche al repository principale eseguendo un commit. A questo punto il software di versioning analizza le modifiche apportate e salva ogni singolo cambiamento, tenendo traccia di ogni revisione effettuata. In qualsiasi momento un altro componente del team può scaricare le modifiche apportate semplicemente chiedendo al repository di aggiungere i cambiamenti alla propria copia locale. In caso di modifiche contemporanee ai file, da parte di più utenti, il sistema provvede a fondere automaticamente i cambiamenti. In qualsiasi momento è possibile accedere ad una qualsiasi revisione di un determinato file, scoprire chi ha modificato una riga, o rimosso una cartella. Esistono essenzialmente due tipi di sistemi di versioning: centralizzati e distribuiti. Nel primo caso il repository è uno solo ed ogni utente lavora su una copia locale, nel secono caso ogni copia locale è a sua volta un repository completo dell intero storico delle versioni. Per il progetto di cui il CodeToBeWild Software Team si impegna nello sviluppo si è scelto di usare subversion come sistema di versioning in quanto, oltre a rispecchiare maggiormente i bisogni del team, vanta anche una lunga tradizione (dieci anni circa) che può essere tradotta come la sicurezza di un software solido. Norme di Progetto Pagina 7 di 12

12 5. DOCUMENTAZIONE Capitolo 5 Documentazione La documentazione inerente al progetto viene stilata a partire da un template base, infrastrutturale, redatto e compilato in L A TEX ed infine esportato in formato PDF tramite PDFL A TEX. 5.1 Uso del template Ogni nuovo documento sarà redatto sulla base di detto template attraverso i seguenti passi: 1. Ridenominazione del file in base al nome del documento in creazione ed alla versione corrispondente 2. Settaggio delle variabili tipografiche specifiche del documento in questione, quali titolo, versione, autori, verificatori, Redazione del registro delle modifiche 4. Redazione del documento stesso 5. Apposizione di nome e cognome di uno o più verificatori quale validazione dello stesso A questo punto il documento sarà esportato in formato PDF e reso disponibile nel repository del team sia sotto forma di sorgente L A TEX sia come PDF. Ogni successiva revisione/correzione comporterà l aggiornamento di versione a cui seguirà una nuova validazione e pubblicazione del lavoro svolto. 5.2 Stato ed uso di un documento Lo stato e l uso di un documento verranno indicati nella tabella presente nel frontespizio di ogni documento. Lo stato del documento si distingue in: Norme di Progetto Pagina 8 di 12

13 5. DOCUMENTAZIONE Preliminare: il documento è in fase di stesura e non è ancora stato approvato dalla persona incaricata, anche se presente quindi nel repository non è da considerarsi ufficiale, e andrà utilizzata la versione precedente. Formale: il documento è stato approvato dal validatore incaricato, si deve trovare nel repository in forma duale di L A TEX e PDF e può essere utilizzato dai membri del team e/o dai destinatari della documentazione. L uso del documento si divide in: Interno: ad uso esclusivo di CodeToBeWild Software Team. Esterno: visibile e fruibile da tutti gli stakeholder. 5.3 Verifica e validazione Ciascun documento dovrà obbligatoriamente essere sottoposto a validazione dall incaricato al suo controllo, il quale apporrà come specificato precedentemente il proprio nome all interno della tabella presente nel frontespizio del documento. 5.4 Approvazione Ciascun documento validato, per passare dalla fase preliminare a quella formale, dovrà ottenere l approvazione del Responsabile in carica al momento. Tale approvazione è a discrezione unicamente di quest ultimo. 5.5 Nomenclatura dei requisiti Ogni requisito dovrà essere identificato da una sigla nella forma seguente: <F N Q I A V P>-<OB D OP>-# Ove i simboli utilizzati sono così definiti: F : requisito funzionale N : requisito non funzionale Q : requisito di qualità I : requisito di interfaccia A : requisito di ambiente V : vincolo P : requisito di performance Norme di Progetto Pagina 9 di 12

14 5. DOCUMENTAZIONE OB : requisito obbligatorio D : requisito desiderabile OP : requisito opzionale # : un numero identificativo del requisito corrente 5.6 Nomi dei file Il nome di ciascun file sarà costituito dal nome del documento, privato di accenti, apostrofi e spaziature; queste ultime saranno sostituite dalla capitalizzazione della lettera successiva, ad eccezione della prima lettera del nome che sarà sempre minuscola. A questo nome così definito sarà apposto un trattino, seguito dal numero di versione del documento, costituito da tre cifre separate da puntini, ed infine sarà presente l estensione. La forma generale del nome di un file si può così rappresentare con: nomedelfile-x.y.z.<estensione> 5.7 Norme tipografiche Layout di pagina Saranno utilizzati tre diversi layout di pagina: Frontespizio: Utilizzato solo per il frontespizio. Layout vuoto che racchiude il contenuto entro due righe orizzontali. Prima parte: Utilizzato per il registro delle modifiche, un eventuale premessa e l indice. In cima alla pagina sono presenti nome e sigla del capitolato sulla sinistra, ed il logo del gruppo a destra. In calce, a sinistra è indicato il nome del documento con relativa versione, a destra il numero di pagina in numerazione romana. Documento: Utilizzato per il corpo del documento, è similare al precedente; in alto a sinistra sarà presente il nome del capitolo ed in basso a destra il numero di pagina seguito dal totale; gli altri elementi rimangono invariati Frontespizio Il frontespizio di ogni documento sarà composto dai seguenti elementi: Il nome del capitolato La versione del documento con annessa data Il logo Norme di Progetto Pagina 10 di 12

15 5. DOCUMENTAZIONE Il nome del gruppo Il corrispondente indirizzo di posta elettronica Una tabella riassuntiva contenente le seguenti informazioni: Data di creazione Versione Stato ed Uso del documento Nome e cognome dei Redattori Nome e cognome dei Verificatori Nome e cognome del Responsabile Committente Proponente Revisione per la quale sarà presentato il documento, e sigla della stessa Registro delle modifiche Il registro delle modifiche sarà situato alla pagina successiva al frontespizio, prima di ogni altra componente del documento. Le modifiche tracciate in esso saranno elencate in ordine di inverso versione, e per ciascuna saranno registrati i seguenti elementi: Versione Data di rilascio Descrizione sommaria delle modifiche Autore/i Indice Ottemperata la funzione di registrazione delle modifiche al documento, la pagina successiva ne riporterà l indice. Quest ultimo sarà generato automaticamente da L A TEXtramite il comando \tableofcontents e sarà dotato di collegamenti ipertestuali alle relative sezioni del documento Elenco delle tabelle Per i documenti ove siano presenti tabulati nella trattazione, sarà redatto automaticamente un elenco delle tabelle tramite il comando L A TEX \listoftables Norme di Progetto Pagina 11 di 12

16 5. DOCUMENTAZIONE Elenco delle figure Per i documenti ove siano presenti immagini nella trattazione, sarà redatto automaticamente un elenco delle figure tramite il comando L A TEX \listoffigures Termini di glossario I termini che andranno illustrati nel Glossario verranno scritti in corsivo (enfatizzati), onde facilitarne l individuazione Annotazioni, link esterni e bibliografia Eventuali note esplicative saranno situate al termine del corrispondente capitolo. I link esterni al documento (pagine Web, indirizzi di posta elettronica) potranno essere espressi in una delle tre modalità seguenti: 1. Un collegamento verso una risorsa esterna, ove il nome della stessa sostituisce la visibilità dell URL. 2. Il nome della risorsa, seguito dall URL tra parentesi. 3. Una nota al termine del capitolo contenente l URL stesso. I riferimenti bibliografici saranno collocati nel capitolo introduttivo del documento, nella Sezione Riferimenti informativi. Norme di Progetto Pagina 12 di 12