slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Presentazione Finale Team 1 PowerPoint Presentation
Download Presentation
Presentazione Finale Team 1

Loading in 2 Seconds...

play fullscreen
1 / 105

Presentazione Finale Team 1 - PowerPoint PPT Presentation


  • 139 Views
  • Uploaded on

Presentazione Finale Team 1. Struttura organizzativa. Team manager, V&V Manager: Alfonso Murolo Quality Manager: Giulio Franco Configuration Management Manager: Linda Di Geronimo Membri del team: Antonio Barba Gianfranco Bottiglieri Elisa D’Eugenio Ferdinando Di Palma Andrea Micco

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

Presentazione Finale Team 1


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
    Presentation Transcript
    1. Presentazione Finale Team 1

    2. Struttura organizzativa • Team manager, V&V Manager: Alfonso Murolo • Quality Manager: Giulio Franco • Configuration Management Manager: Linda Di Geronimo • Membri del team: • Antonio Barba • Gianfranco Bottiglieri • Elisa D’Eugenio • Ferdinando Di Palma • Andrea Micco • Angelo Scafuro

    3. Obiettivi • Sviluppare un sistema per l’asilo Mazzetti: • Requisiti legali • Processi aziendali complessi • Figure già esistenti devono adottare il nuovo sistema • L’azienda asilo non deve stravolgere i propri processi interni per adottare il sistema

    4. Ce l’abbiamo fatta? • Si! • I requisiti burocratici e legali sono stati soddisfatti • I processi aziendali sono stati rispecchiati • Le responsabilità esistenti sono correttamente separate • Un guanto di giusta misura per una mano di taglia introvabile • E la nostra parte copre solo le prime dita!

    5. Quanto ce l’abbiamo fatta? • Completato quanto era stato previsto • La taglia di questa gestione: • 286 CFP (Cosmic) • 79 Casi d’uso modellati

    6. Ma andiamo nel dettaglio.. • Vedremo ora quali sono i requisiti posti di maggior rilievo per la nostra analisi!

    7. Progetto @silo Finalità e obiettivo Sistema Software per migliorareedottimizzareilserviziodiasilonidomesso a disposizionedell’universitàdiFisciano. Teams di Sviluppo • Team Accessi • Team Servizi • Team Home

    8. Sottosistema Accessi Hot Points Principalipuntidirealizzazione: • Registrazione e Accesso • Presentazione Domanda on-Line • Creazione, modifica, consultazione Graduatoria • Creazione,modifica, consultazioni Classi

    9. Sottosistema Accessi Requisiti richiesti…. • Semplicità e accessibilità • Presentazione richieste di Iscrizione • Elaborazione dati • Rapidità di operazioni • Automatismo • Termini temporali • Protezione dati sensibili • Username e Password • Informazioni generali

    10. Sottosistema Accessi Requisiti richiesti…. • Semplicità e accessibilità • Presentazione richieste di Iscrizione • Elaborazione dati • Rapidità di operazioni • Automatismo • Termini temporali • Protezione dati sensibili • Username e Password • Informazioni generali

    11. Sottosistema Accessi …..e soddisfatti • Semplicità e accessibilità • Creazione account attraverso varie sezioni • Creazione generica dell’account • Dati Genitore richiedente • Dati Genitore non richiedente • Situazione Reddituale • Dati personali Bambino • Situazione Familiare • Notifiche costanti agli Impiegati di Competenza • Monitoraggio di richieste Utente

    12. Sottosistema Accessi Requisiti richiesti…. • Semplicità e accessibilità • Presentazione richieste di Iscrizione • Elaborazione dati • Rapidità di operazioni • Automatismo • Termini temporali • Protezione dati sensibili • Username e Password • Informazioni generali

    13. Sottosistema Accessi …..e soddisfatti (2) • Rapidità di Operazioni • Auto-Completamento • Compilazione Domanda • Modifiche e consultazione • Operazione su classi e iscritti (spostamenti) • Visualizzazione Bando • Accettazione Iscritto • Salvataggio bozze domande

    14. Sottosistema Accessi Requisiti richiesti…. • Semplicità e accessibilità • Presentazione richieste di Iscrizione • Elaborazione dati • Rapidità di operazioni • Automatismo • Termini temporali • Protezione dati sensibili • Username e Password • Informazioni generali

    15. Sottosistema Accessi …..e soddisfatti (3) • Protezione dati Sensibili • Login separato per tipologia di utente • Dati di ricerca visualizzatiin base all’utente che la compie

    16. Attori del Sistema

    17. Principali del Sottosistema

    18. Generalizzazioni Trasformazioni e Aggiunte • Aggiunte • Durante il processo di Analisi e oltre…. • Migliorare o Ottimizzare • Trasformazioni e Generalizzazioni • Normale evoluzione del sistema • Scalabilità di dominio • Riportate e descritte nell’evoluzione del RAD

    19. Use case Diagram Prima versione RAD 1.0

    20. Use case Diagram Seconda versione RAD 2.0

    21. Use case Diagram Ultima versione RAD 4.0

    22. Use case Diagram Prima versione GestioneDatiPersonali

    23. Use case Diagram Ultima versione GestioneDati personali

    24. Obiettivo Principale • Semplificazione della presentazione ed elaborazione delle richieste da parte degli utenti • Obiettivo raggiunto e risolto con successo. A dirlo sembra una cosa molto semplice ma non è stato affatto cosi.

    25. Idea … • Sistema di presentazione on-line delle domande di iscrizione per il proprio bambino • Sito internet che permette di: • Consultare il bando • Compilare una eventuale domanda di iscrizione online (completa di tutti i campi) • Inviare la domanda compilata • Mostrare la graduatoria

    26. Prima versione del sistema Esempio di uno scenario per la presentazione della domanda di iscrizione (parte 1)

    27. Esempio di uno scenario per la presentazione della domanda di iscrizione (parte 2) SC_A_4

    28. “Solo perché voi avete sofferto quando vi siete iscritti all'università non è detto che debbano farlo tutti” (cit F. Ferrucci)

    29. Idea V.2 La versione precedente non ha soddisfatto il committente quindi abbiamo pensato di dividere l’iscrizione in due parti: Creazione di un account Compilazione della domanda di iscrizione

    30. Caso d’uso per la creazione dell’account con i dati da compilare UC_A_46 Creazione account

    31. Caso d’uso per l’iscrizione del bambino (parte 1)

    32. Caso d’uso per l’iscrizione del bambino (parte 2) UC_A_4 Compila modulo di iscrizione per personale universitario e studenti Nel caso il genitore chiude la finestra il sistema chiede di salvare i dati compilati in modo da ricaricarli alla prossima riapertura.

    33. Primo approccio ad “@silo” • Il genitore è l’utente che iscrive il proprio figlio all’asilo e può essere di tre tipi: • Personale universitario e studenti • Residenti di Fisciano • Altro utente • Passo 1: Creazione dell’accuont • Passo 2: Compilazione della domanda di iscrizione • Ad iscrizione completa queste sono le operazioni: • Visualizzare e modificare i dati inseriti durante l’iscrizione • Visualizzare e modificare i dati del proprio bambino • Visualizzare lo stato della propria iscrizione

    34. UCD_A_3 Gestione Dati Personali Completo

    35. UCD A 2 Gestione iscritti

    36. RAD: Pro e contro • Pro: • Revisioni incrociate • Modellazione accurata • Attori progettati nell’ottica dell’aggiornamento del RAD • Contro: • Nonostante numerose revisioni ci sono ancora delle imperfezioni

    37. Design Goals Definiamo le fondamenta dello sviluppo del sistema. Regole d’oro per l’implementazione: definiamo limiti ed obiettivi fondamentali che il nostro sistema deve portare a termine.

    38. Design Goals Utente finale: Genitore • Sicurezza e tutela della privacy • Tempo di risposta • Usabilità • Adattabilità e portabilità • Tolleranza

    39. Design Goals Utente finale: Personale dell’asilo • Sicurezza e tutela della privacy • Tempo di risposta • Usabilità • Adattabilità e portabilità • Tolleranza • Affidabilità

    40. Trade-offs • Sicurezza vs. Efficienza • Login iniziale • Visualizzazione da parte dell’utente solo della parte del sistema ad esso dedicata • Soluzione sicura ed efficiente

    41. Trade-offs • Spazio di Memoria vs. Velocità • Memorizzazione informazioni delle entità • Il carico complessivo non influisce sulla velocità del sistema • Più rilevanza alla velocità • Più spazio su disco ma alta velocità in lettura e scrittura

    42. Trade-offs • Tempo di Rilascio vs. Qualità • Rispetto pedissequo delle date di consegna e giusta qualità delle funzionalità

    43. Architettura del Software

    44. Architettura del Software Perché Three-Tier? • Gestione facile ed indipendente dei sistemi di elaborazione e delle interfacce grafiche • Indipendenza dei layer: basso accoppiamento • Manutenibilità

    45. Diagramma di Deployment

    46. I nostri Sottosistemi

    47. I nostri Sottosistemi

    48. Gestione dei Dati Persistenti • Gestione di un database attraverso DBMS MySQL • Database minuziosamente strutturato