Introduzione al progetto WWW. Fabio Vitali 22 ottobre 1999

Documenti analoghi
Politecnico di Milano. Progetto di Ingegneria del Software 2 MPH - Manage Project Homework

Strumenti per l automazione del testing di applicazioni web Javascript-based

Corso di Fondamenti di Informatica T-1 Parte 2 - Modulo di Laboratorio

SOMMARIO. cüxá wxçét wxä VÉÇá zä É wx ` Ç áàü. Ufficio Nazionale per il Servizio Civile

Corso di Marketing

QUESTIONARIO 2: PIANIFICAZIONE DEL MIGLIORAMENTO

Introduzione al corso di Laboratorio di Tecnologie Web LTW. Fabio Vitali 26 febbraio 2002

Laboratorio di Progettazione di Sistemi Software Progetto: modellazione di un dominio e sue attività

Progetto sito web Gigli Elisa

COMUNE DI BONASSOLA Provincia della Spezia Via Beverino 1 cap tel fax

Architetture di rete. 4. Le applicazioni di rete

Corso Programmazione Java Standard

Elena Baralis 2007 Politecnico di Torino 1

PRINCIPALI PROGETTI REALIZZATI

PIANO DI LAVORO ANNUALE di COMUNICAZIONE GRAFICA DOCENTE: GLORIA BORNANCIN

Un architettura orientata ai servizi per la localizzazione di dispositivi mobili

PROGETTAZIONE / PROGRAMMAZIONE DIDATTICA INDICE. Revisioni

RICHIAMATI CONSAPEVOLI

MANUALE DELLA QUALITÀ Pag. 1 di 9

STATUTO L Associazione non può deliberare o intraprendere iniziative di carattere didattico.

Fondamenti VBA. Che cos è VBA

REPERTORIO DELLE QUALIFICAZIONI PROFESSIONALI DELLA REGIONE CAMPANIA

REGOLAMENTO DI ISTITUZIONE E FUNZIONAMENTO DEI GRUPPI DI LAVORO. ai sensi dell art. 35 dello Statuto Comunale

Indagine sul Benessere Organizzativo. Dicembre 2013

Elaborato Shell. Elementi di architettura e sistemi operativi 2016/2017

StoneGate Report Manager. Panoramica sulla funzionalità

Tesi di Laurea Triennale in Ingegneria Informatica REALIZZAZIONE DI UN APPLICATIVO PER LA GESTIONE DI FOGLI DI LAVORO INTEGRATO IN OUTLOOK 2010

Servizio E-learning di Ateneo Piattaforma Moodle e L2L

Programmazione ad Oggetti

Principi di Progettazione del Software a.a Introduzione al corso Prof. Luca Mainetti Università del Salento

BOZZA Regolamento di Comitato Studentesco

Principi di Progettazione del Software a.a " Introduzione al corso! Prof. Luca Mainetti! Università del Salento!

Il presente e il futuro dell Accessibilità L innovazione tecnologica nella pubblica amministrazione senza rinunciare all Accessibilità

Programma di Sviluppo Rurale del Lazio

Studio e realizzazione di un client per l'interoperabilità tra un archivio museale e un Data Provider OAI-PMH nell'ambito dell'architettura CART

CERT- LIM INTERACTIVE TEACHER Certificazione Competenze Metodologiche con la LIM MODULO 2 Competenze Metodologico-Didattiche. Strategia del Big6

Towards Shared Patient Records: an Architecture for Using Routine Data for Nationwide Research

ISTITUZIONE DELLA CONSULTA COMUNALE PER L'INTEGRAZIONE DELLE PERSONE IN SITUAZIONE DI HANDICAP E DELLE LORO FAMIGLIE. IL CONSIGLIO

Statuto del Centro Servizi Informatici

REGOLAMENTO DEL CONSIGLIO COMUNALE DEI RAGAZZI

REGOLAMENTO PER IL FUNZIONAMENTO DELLE COMMISSIONI COMUNALI

I set di caratteri WWW. Fabio Vitali 5 novembre 1999

Gestione centralizzata caselle PEC per l INFN. Alessandro Brunengo, per il gruppo Mailing

Dipartimento di INFORMATICA, TC, TTRG. Anno Scolastico Piano di Lavoro Disciplinare

ELEMENTI DI INFORMATICA E PROGRAMMAZIONE

Metodologia di lavoro: PCM & GOPP

AscotWeb - mediatore Versione dicembre 2015

CORSI DI APPROFONDIMENTO IN COLLABORAZIONE CON LE AZIENDE Autodesk Revit MEP

Introduzione al Calcolo Scientifico

Capitolo 15. La pubblicità e le pubbliche relazioni. Capitolo 15 - slide 1

Laboratorio di Reti, Corsi A e B. Text-Twist. Progetto di Fine Corso A.A. 2016/17

Carta dei rapporti. tra ULSS 4 Alto Vicentino Comuni della Conferenza dei Sindaci e altri Enti Locali

Questionario Personale ATA

MALATTIE RARE E FARMACI ORFANI: ATTIVITA DEL CENTRO NAZIONALE NAZIONALE MALATTIE RARE A LIVELLO NAZIONALE ED EUROPEO

Customer Relationship Management

COMUNE DI CASOREZZO (Prov. di Milano)

SISTEMI INFORMATIVI E DATABASE

Fondamenti di Informatica (lettere A-I) A

SETA Selection Tool del Sistema ARTIST

Programma del corso. Elementi di Programmazione. Introduzione agli algoritmi. Rappresentazione delle Informazioni. Architettura del calcolatore

ORDINE DEGLI INGEGNERI DELLA PROVINCIA DI LECCE

Compitino di Laboratorio di Informatica CdL in Matematica 13/11/2007 Teoria Compito A

Regolamento del Partito Democratico della Federazione di Cremona

PIANO DI VALUTAZIONE DEL POR FESR EMILIA ROMAGNA Proposta per l'approvazione del Comitato di Sorveglianza, 28 gennaio 2016

COMUNE DI CREAZZO PROVINCIA DI VICENZA REGOLAMENTO PER L'ISTITUZIONE ED IL FUNZIONAMENTO DELLA COMMISSIONE COMUNALE PER LE PARI OPPORTUNITA'

Open Database Connectivity (ODBC)

FORMATO EUROPEO PER IL CURRICULUM VITAE INFORMAZIONI PERSONALI

SUPER. (Sistema Unico Posta Elettronica Regionale) Gestione Profilo Account

L insegnante avvia un progetto con l ausilio di un ambiente di apprendimento

Cosa è cambiato - la parte facile

Corso di Ingegneria del Software. Modelli di produzione del software

Linee Guida di Brianza SiCura

Informatica A - Gestionali

COMUNE DI MEDE (Provincia di Pavia) REGOLAMENTO DEL CONSIGLIO COMUNALE DELLE RAGAZZE E DEI RAGAZZI DI MEDE

REGOLAMENTO COMUNALE DELLA CONSULTA DEL COMMERCIO. Approvato con deliberazione di Consiglio Comunale n. 24 del 30/03/2015

A scuola di scienza: il progetto Tutti pazzi per la chimica!

Questionario Personale ATA

Mobilità scuola 2017/2018 Le principali novità contenute nella pre-intesa sul nuovo contratto

SERVIZI SPECIALISTICI LEGALI E TECNICO- SISTEMISTICI PER ADEGUAMENTO ATTIVITÀ AL CODICE DELLA PRIVACY.

Progetto: Scuola-Alimentazione e diabete

ALLEGATO C. Sistema permanente di valutazione valutazione dell apporto individuale

DESTINATARI CREDITI DURATA SCADENZA ISCRIZIONI

Provincia della Spezia

Obiettivi di accessibilità per l anno 2014

TEORIE E TECNICHE PER LA COMUNICAZIONE DIGITALE

ARGOMENTI IN TEMA DI INFEZIONI

RUBRICA DI VALUTAZIONE Livelli di qualità

La Fatturazione elettronica

PROTOCOLLO DI ACCOGLIENZA ALUNNI STRANIERI LEGGE 40/1998; D.P.R. 394/1999

NORME DI ORGANIZZAZIONE E FUNZIONAMENTO DEL TAVOLO DI PARTENARIATO

BASI DI DATI. basi di dati - introduzione ai sistemi informativi 1

Il calcolatore. Architettura di un calcolatore (Hardware)

GRUPPO DI LAVORO CIIP SSL SCUOLA

COMUNE DI LIVORNO. Articolo 1 Principi e Finalità

Reti Locali LAN. Prof. Francesco Accarino IIS Altiero Spinelli Sesto San Giovanni

Corso di Laurea Ingegneria Informatica Fondamenti di Informatica

Introduciamo l'uso della programmazione ad oggetti in PHP...perchè si può fare!

UNIVERSITÀ DEGLI STUDI DI BERGAMO

A SCUOLA NESSUNO E STRANIERO Percorso di educazione interculturale

Progetto formativo aziendale PROJECT MANAGEMENT: METODOLOGIE, TECNICHE E STRUMENTI PER LA CONDUZIONE E GESTIONE DEI PROGETTI

Transcript:

Introduzione al progetto Fabio Vitali 22 ottobre 1999

Introduzione Oggi esaminiamo in breve: L architettura del macro-progetto La divisione in temi La divisione in famiglie 2

Il macro-progetto Un unico grande progetto a cui partecipano tutti i frequentanti Enfasi sulla collaborazione trasversale e continua (come negli organismi di standard) Non ci sono gruppi: Famiglie (accomunate dall usare gli stessi strumenti per temi diversi) Temi (accomunate dal realizzare lo stesso programma con strumenti diversi) 3

Il problema semplice 4

Il problema semplice risolto 5

Il problema difficile 6

Il problema difficile risolto 7

Le famiglie (1) Tutti i frequentanti si dividono in tre famiglie: MICROSOFT: strumenti COM Microsoft: Visual Basic, Visual C++, ecc. SUN: una qualunque versione standard di Java (ad esempio, Visual J++ non va bene) GNU: strumenti e linguaggi disponibili nelle distribuzioni GNU: C, C++, Perl, Python, TCL/TK, emacs, ecc. 8

Le famiglie (2) La distribuzione in famiglie è volontaria Tuttavia, le famiglie debbono essere di composizione omogenea per numero e qualità dei programmatori. Lo scopo ultimo della famiglia è creare un software funzionante e complesso dalla somma delle attività dei singoli. Il nome del gioco è integrazione. 9

I temi (1) Il progetto riguarda la realizzazione di un sistema molto complesso Il sistema viene quindi diviso in tanti sottoproblemi, detti temi, attraverso discussione comune. Tutte le famiglie debbono realizzare un implementazione interoperabile di ciascun tema identificato Le implementazioni dei temi debbono, riunite in un unico sistema, fornire tutte le funzionalità richieste 10

I temi (2) Bisogna ipotizzare di far parte di un gruppo di standardizzazione (tipo IETF o W3C) Ciascun individuo parla a nome della famiglia cui appartiene E necessario trovare i compromessi più adatti per favorire la propria implementazione senza però imporsi agli altri La ricerca del consenso è fondamentale 11

I temi (3) Il progetto riguarderà e richiederà l uso di tecnologie tipiche del World Wide Web. E obbligatorio che le implementazioni usino o estendano protocolli e tecniche esistenti nel World Wide Web. Ogni deviazione da standard esistenti deve essere giustificata e approvata da tutti i membri di un tema. In più mi dovete convincere (N.B.: non è facile). 12

I temi (4) La scelta dei temi è libera Tuttavia, i temi debbono essere scelti omogeneamente tra le famiglie, e riflettere scelte architetturali importanti Lo scopo ultimo del tema è trovare un protocollo ragionevole che permetta ad implementazioni diverse di svolgere compiti analoghi e di comunicare tra loro. Il nome del gioco è interoperabilità. 13

Architettura (1) Ogni famiglia può strutturare l architettura interna come meglio preferisce Tutti i ruoli pubblici identificati dalla discussione comune debbono essere coperti Tutti i ruoli privati identificati dalle famiglie debbono essere coperti La discussione deve stabilire le interfacce tra i temi: protocolli tra famiglie diverse, API tra temi della stessa famiglia 14

L architettura (2) Tema Z Tema W Tema X Tema Y Tema A Tema B Tema C Tema A Tema B Tema C Tema D Tema A Tema B Tema C Tema S Tema T Tema D Tema D 15

Ruoli extra 16 Esistono tre ruoli da coprire all interno di ogni famiglia: Il guru possiede profonde conoscenze tecniche sugli strumenti prescelti e consiglia gli altri. Il project manager stabilisce fasi, deadline e criteri di confronto e organizzazione del progetto, ed è responsabile della corretta realizzazione del sistema Il system administrator installa e mette a disposizione strumenti e reti. Per esempio installa il server di news da utilizzare per le discussioni Questi ruoli possono essere coperti da persone già impegnate in temi specifici (vale più punti) oppure possono esserne l unico compito I ruoli extra vanno coperti per acclamazione all interno delle famiglie

Perché tutto questo? Discussione sul problema (nasce il tema) Si vuole simulare quanto accade nei gruppi di standard: discussioni, ricerca del consenso, generazione del protocollo, verifica e modifica Il processo di realizzazione deve avvenire in tre fasi: Ricerca del consenso (nasce il protocollo) Implementazione (viene testata l interoperabilità) 17

Il processo Specifichiamo meglio il processo di realizzazione del sistema: I fase: da adesso a Natale 99: divisione in famiglie, identificazione dei temi, attribuzione dei temi ai singoli, creazione delle architetture di discussione. II fase: da gennaio a Pasqua 2000: Tema per tema, identificazione delle dipendenze reciproche e creazione di API e protocolli. III fase: da Pasqua a giugno 2000: implementazione, test, integrazione e seconda versione del protocollo. 18

I fase (fino a Natale 99) A breve riceverete il documento dei requirement (il problema). Tramite discussione globale (usando il newsgroup di IUM) vi dividete in famiglie. Le famiglie identificano al loro interno le persone che copriranno i ruoli speciali (guru, project manager, system administrator) I temi proposti verranno analizzati, tramite discussione globale, e rivisti, spezzati, riorganizzati. Le famiglie individuano, tema per tema, la/le persone a cui affidare il tema. 19

II fase (fino a Pasqua 2000) Vengono creati i newsgroup (o le mailing list) di famiglia e di tema. Ciascuno è tenuto a partecipare alle discussioni (fanno parte integrante del voto finale) I protocolli di interoperabilità vengono realizzati attraverso In questa fase vengono realizzate le specifiche di sistema ed i protocolli di interoperabilità. Le specifiche di sistema vengono realizzate attraverso discussione intra-familiare secondo criteri illustrati a Ingegneria del software discussione inter-familiari, tema per tema, secondo criteri illustrati a IUM. E lecito ma non garantito iniziare la fase di implementazione prima della conclusione dei protocolli. 20

III fase (fino a giugno 2000) 21 Il progetto si conclude in un punto a scelta tra il livello Vengono implementati i moduli descritti dai documenti della II fase. I moduli vengono testati separatamente, integrati e testati insieme. Vengono anche eseguiti i test di interoperabilità. I tester compilano bug report che vengono ricevuti, catalogati e affrontati in ordine di importanza. minimo ed ottimale di correttezza del sistema integrato, identificati in precedenza. L esperienza evidenzia problemi di interoperabilità che portano ad una seconda versione dei protocolli.

I protocolli (1) Ogni working group di tema deve elaborare tre o più documenti di protocollo: Obiettivi del working group: limiti e funzionalità trattate, relazioni con gli altri working group Regole di interoperabilità: processo, sintassi, gestione degli errori Criteri di verifica: criteri minimi di interoperabilità (core set) e funzionalità opzionali (optional set). Core test suite e optional test suite. I documenti di protocollo debbono essere sufficientemente completi da esprimere e lasciar implementare tutte le funzionalità richieste al tema sufficientemente precisi da garantire l effettiva interoperabilità delle implementazioni 22

I lavori di discussione (2) 23 La discussione avviene necessariamente e completamente su newsgroup. Riunioni fisiche sono possibili, ma i risultati vanno verbalizzati e esposti su newsgroup Scopo del working group è generare documenti di protocollo consensuali. Viene eletto all inizio un chair del working group. Ha il compito di generare i documenti di protocollo; è il portavoce del tema con i docenti. Il chair deve ottenere il consenso a tutti i costi, trovando le situazioni di compromesso più opportune. Il protocollo viene sottoposto all approvazione globale alla fine della II fase, e corretto adeguatamente.

Il project manager Il P.M. decide l organizzazione interna del progetto per famiglie. E il chair del newsgroup della famiglia. E anche il portavoce con i docenti. E a carico del P.M.: La composizione dei working group L identificazione delle fasi interne di progetto I criteri di accettabilità del progetto (livello minimo ed ottimale) La verifica del lavoro dei vari membri dei working group. Il P.M. ha il potere di spostare persone da un tema ad un altro, creare nuovi temi, stabilire criteri di eccellenza. Ci può essere da un minimo di uno ad un massimo di tre P.M. in famiglia, ma ogni decisione deve essere consensuale. 24

Il system administrator Il system administrator deve fornire ai membri della famiglia gli strumenti per realizzare il loro lavoro: Newsgroup di famiglia e di tema Siti web per i documenti di lavoro e ogni altra informazione Ambienti di programmazione e test Gestisce gli account ed il sito Web di famiglia C è un solo system administrator per famiglia. 25

Il guru Esso fornisce consigli (half guru) o risolve i Il compito del guru è fornire assistenza tecnica agli implementatori della sua famiglia. problemi (full guru) degli implementatori. I problemi propostigli possono solo essere relativi all architettura di famiglia, non ai dettagli dell implementazione. C è al massimo un guru in ogni famiglia, e la famiglia decide se è half o full. 26

L implementatore Lucido non mostrato a lezione La famiglia identificherà i compiti implementativi da L implementatore ha sotto la sua responsabilità il compito di realizzare e testare uno o più moduli del sistema. affidare. Ad un implementatore capo verranno affidati incarichi di peso maggiore che ad un implementatore semplice, nell ottica di una equa suddivisione dei compiti. Un implementatore capo non ha nessuna autorità su un implementatore semplice, la differenza di nome è unicamente connesso con il carico di lavoro affidato. 27

Il tester Lucido non mostrato a lezione I sistemi vengono testati in tre maniere Test del modulo: verifica della corretta implementazione del singolo modulo, fatta da membri della stessa famiglia ma non dall implementatore. Test del sistema: verifica della corretta integrazione del sistema, fatta da membri di altre famiglie. Test dell interoperabilità: verifica della corretta interoperabilità del sistema fatta da membri di altri working group. In ogni caso MAI un implementatore verifica il proprio modulo. 28

Le decisioni Lucido non mostrato a lezione I contesti sono tre: Le decisioni all interno di qualunque contesto vengono prese democraticamente come risultato di discussioni. Vengono imposte dall autorità costituita sono in caso di chiara mancanza di accordo. Il tema: decisioni semplici a maggioranza. Decisioni chiave a maggioranza qualificata (75% +1) La famiglia: decisioni semplici a maggioranza. Decisioni chiave a maggioranza qualificata (75%+1) La classe: decisioni semplici a maggioranza e mio assenso. Decisioni chiave a maggioranza qualificata (75%+1+il mio assenso) indipendentemente dall appartenenza ad una famiglia o ad un working group. 29

I ruoli e i punti Ogni ruolo ha un peso nel progetto, in fatica e responsabilità. Qui si dà un primo punteggio ai ruoli, che è soggetto in qualunque momento a verifica e cambiamento (ma si richiede il consenso mio e del 50% +1 della classe). Ogni studente di due annualità (IUM e IdS) deve prendersi ruoli per 16-24 punti. Ogni studente di una annualità deve prendersi ruoli per 8-12 punti. Studenti non di informatica non possono prendere ruoli di implementatore, guru, o system administrator. 30

Una prima tabella di punti Ruolo Punti project manager 8 half guru 4 full guru 8 system administrator 8 Implementatore semplice 8 Implementatore capo 16 Membro di working group 4 Chair di working group (in aggiunta a membro) 4 Tester di modulo 2 Tester di sistema 2 Tester di interoperabilità 2 31

Il progetto e il corso (a) 32

if ( ) { } else { } while (;;) { } i++ 33

34

Il progetto e il corso (d) 35

Il progetto e il corso (e) 36

Conoscenze da farsi Il progetto e il corso (f) Il progetto da realizzare La vostra fatica Programmazione ad oggetti Conoscenze da altri corsi Tecnologie specifiche (COM, Java, ecc.) Protocolli del World Wide Web Sistemi distribuiti Gestione del workflow, Conoscenze da questo corso if ( ) { } else { } while (;;) { } i++ Voi Conoscenze di base 37

Conclusioni Il progetto vuole dare un idea del lavoro d equipe e del funzionamento dei gruppi di standard La divisione in famiglie permette di accedere nei dettagli ad una di tre tecnologie interessanti La divisione in temi permette di realizzare progetti importanti e senza ridondanze e ripetizioni 38