Appunti comunicazione digitale e multimediale

Comunicazione digitale e multimediale mod A4

Domande risposte aperta (5 punti) e 10 crocette (1 punto) -> da un codice PHP e devo dire cosa viene visualizzato (es domanda chiusa).

Lez 1-2

La progettazione dei servizi web

Cos’è un servizio web?

È un sistema informatico di supporto ad un processo di business -> un processo di business è una fase della vita di un’azienda che viene supportata da un sistema informatico. Un’azienda manifatturiera tra i diversi processi di business, ha anche la filiera produttiva (anche quello un processo di business), deve avere un sistema che possa automatizzare quel processo di business.

I servizi informatici sono strumenti tecnologici a supporto del processo di business che vengono utilizzati dagli operatori che lavorano nel processo, e li utilizzano a supporto delle loro attività.

• È un’applicazione (un software) (sistema per prenotare esami)
• È accessibile via internet
• È realizzato attraverso diverse tecnologie
• Vive all’interno di una complessa infrastruttura
• Risponde alle esigenze degli utenti

Es: un semplice sito web; un complesso sistema di banking online.

L’ingegneria del software

Rispetto alle altre ingegnerie (civile, edile), l’ingegneria del software è una disciplina abbastanza nuova.

Il software è concepito come qualsiasi altro prodotto ingegneristico (es veicoli) e pertanto la sua realizzazione deve basarsi su procedure, principi e metodi scientifici.

È nata quindi l’ingegneria del software, che è una disciplina ingegneristica che definisce il processo che deve essere eseguito perché alla fine di questo processo possa essere realizzato un prodotto -> un prodotto che sia efficace e efficiente.

L’ingegneria del software è una disciplina ingegneristica che definisce il processo di sviluppo del software in grado di realizzare un prodotto efficace ed efficiente.

Perché si possa procedere alla realizzazione di questo prodotto, di questo servizio web è necessario definire un progetto -> il processo descrive quelle che sono le diverse sequenze di step che dobbiamo seguire, gli step che l’ingegneria del software descrive per raggiungere l’obbiettivo, ma affinché possiamo raggiungerlo dobbiamo contestualizzarlo all’interno di un progetto.

Che cos’è un progetto?

Un progetto è una sequenza di fasi, attività e compiti che hanno come finalità la realizzazione di un outcome (prodotto, servizio, risultato).

• Ha un inizio e una fine
• Le attività non sono di routine, pertanto il project team potrebbe essere composto da persone con le quali non si lavora generalmente, talvolta appartenenti a differenti organizzazioni o provenienti da diverse regioni geografiche
• Sfrutta una serie di risorse che generalmente sono definite a priori -> risorse umane (persone che devono lavorare), risorse tecnologiche, risorse economiche (fondi per portare avanti il progetto), risorse temporali.

Es progetto:

• 1-sviluppo di un software per il supporto ad un processo di business
• Costruzione di un ponte o edificio
• Organizzazione dei soccorsi dopo una calamità naturale
• Espansione delle vendite in un nuovo mercato
• Sviluppo di un nuovo sito web per un’organizzazione

Progettazione

Progettazione: è un processo che a partire da norme tecniche, calcoli, specifiche e disegni, perviene alla definizione delle specifiche necessarie alla realizzazione di un manufatto, un edificio, un componente, un apparato, o in generale di un prodotto o un servizio (per es un’abitazione, una sedia, una strada, un ponte, un autoveicolo, un software un sistema elettronico) riassenta all’interno di un progetto. (Wikipedia)

-> è un processo prima di tutto -> nel caso dello sviluppo dei siti web viene definito dall’ingegneria del software; nel caso della costruzione di un ponte viene definito dall’ingegneria civile.

-> si parte dall’analisi, dalla raccolta, della definizione delle specifiche, che sono necessarie alla realizzazione di questo outcome -> questi vengono descritti all’interno del progetto, vengono descritte le attività, quindi le fasi, i compiti dell’intero processo e in questo modo vengono indicate le risorse e si definisce una strategia che ci consente di poter raggiungere il risultato mantenendo i costi, i tempi, il rischio ecc.

Perché progettare?

Perché progettare? Non si può prescindere dalla progettazione -> senza progettazione si rischia di produrre un artefatto poco intuitivo e scarsamente usabile, che può decretarne in anticipo l’insuccesso.

• Per lavorare in modo non occasionale
• Per evitare l’improduttività
• Per finalizzare il proprio operato
• Per trovare le risposte più adatte ad ogni specifica situazione
• Per permettere a più persone di lavorare in gruppo, sia nella fase ideativa che in quella operativa
• Per verificare i risultati raggiunti
• Per contenere l’emergenza
• Per fornire pubblicamente un rendiconto dell’operato del singolo e del gruppo.

Efficacia ed efficienza del progetto

Durante la progettazione dobbiamo mettere dentro tutto quello che abbiamo acquisito negli studi, nelle esperienze -> è necessario applicare tutte le conoscenze, le abilità e le tecniche per eseguire il progetto in maniera efficace ed efficiente.

• Efficace: l’outcome del progetto deve soddisfare lo scopo per cui è stato progettato
• Efficiente: l’outcome del progetto deve avvenire nei tempi stabiliti e non deve richiedere più risorse di quelle previste -> l’outcome lo devo ottenere con le risorse che ho a disposizione (risorse umane, tecnologiche, economiche, temporali)

Triplo vincolo

Sono 3 elementi tra loro strettamente collegati -> qualità, tempo e costo.

Tirando uno si accorcia un altro e viceversa. Bisogna trovare un equilibrio tra questi 3 elementi.

Team di progetto: ruoli e responsabilità

Chi sono le persone che si trovano all’interno del progetto?

Project manager

• Pianifica, organizza, gestisce, monitora e revisiona tutte le attività di progetto
• Effettua una stima dei tempi e dei costi necessario allo sviluppo
• Gestisce il budget, le risorse umane, i materiali
• 2-prende decisioni sullo sviluppo del prodotto al fine di mantenere i costi, i tempi e la qualità del software

Product owner (esperti in materia)

È la persona interna all’organizzazione che possiede una chiara competenza sul servizio che si vuole digitalizzare e una chiara idea del risultato che si vuole ottenere.

Conosce molte bene il dominio applicativo (es se state sviluppando un servizio di fatturazione elettronica, il product owner conosce l’intero processo e le norme che ne regolano il funzionamento).

Project team

Team interdisciplinare deciso al progetto, con competenze di ricerca, prototipazione e sviluppo dei servizi.

• Project Leader: capo del gruppo di lavoro, dotato di capacità comunicative e di leadership, cerca di prevenire e risolvere conflitti interni al gruppo.
• Architect/Analyst: traduce i requisiti di business in soluzioni tecniche
• UI Designer: progetta le interfacce grafiche
• UX Designer: progetta la user experience
• Content Designer: progetta i contenuti
• Content Manager: coordina le attività di copyright
• Front-End Developer: sviluppo di interfacce grafiche
• Back-End Developer: sviluppo di moduli di backend
• System Administrator: gestisce i sistemi
• DB Administrator: gestisce i database
• QA Engineer: gestisce la qualità del software

Principi generali di progettazione

Principi generali di progettazione da tenere in considerazione quando si lavora in un progetto:

1) Partire dai bisogni dell’utente

Partire dai bisogni dell’utente: indagare sulle esigenze dell’utente e fare in modo che tutte le funzionalità siano disegnate intorno alle sue esigenze e modelli mentali, consentendogli di ottenere facilmente e rapidamente ciò di cui ha bisogno -> senza passaggi inutili e con istruzioni comprensibili.

Tenere in considerazione il target di persone a cui il prodotto e il servizio è destinato -> considerare la natura di queste persone.

Il concetto di sviluppo dell’applicazione user centered è un principio definito dagli inizi dell’ingegneria informatica, negli anni 80, sottolineano l’importanza di considerare i bisogni degli utenti e centrando la sua attenzione sull’usabilità.

Il ruolo del progettista è quello di rendere più facili i compiti che devono essere svolti dagli utenti, assicurandosi che siano in grado di utilizzare il prodotto come previsto e con un minimo sforzo.

2) Semplificazione

Semplificazione: tutta la progettazione deve essere improntata alla massima semplicità, cioè:

• Suddivisione del problema in sottoproblemi
• Rappresentazione grafica del problema.

Questo facilita la realizzazione di un sistema di facile comprensione e manutenzione.

3) Ciò che si produce verrà consumato da altri

Ciò che si produce verrà consumato da altri: il prodotto che viene realizzato è un prodotto che ha una sua vita, non ha vita breve, quindi dobbiamo pensare che l’outcome di questo processo vivrà a lungo nel tempo. Nel corso del tempo le esigenze, le necessità, le norme cambiano, quindi molto probabilmente avremo necessità di adattare il nostro prodotto a quelli che sono i continui cambiamenti.

Altri soggetti dovranno in futuro utilizzo il prodotto che si sta realizzando e quindi fare il lavoro in modo da facilitare il lavoro di chi ci segue -> mantenere aggiornata la 3documentazione del sistema può aiutare terze parti a comprendere più facilmente la complessità del sistema.

4) Standardizzare

Standardizzare: la standardizzazione è fondamentale per favorire la sostenibilità e l’efficacia, consentendo di progettare ogni nuovo servizio partendo da componenti già esistenti e concentrare le risorse disponibili sugli elementi di unicità del servizio, senza dover “reinventare ogni volta la ruota”.

5) Essere parti verso il futuro

Essere parti verso il futuro: il progetto che si sta implementando non è statico ma dovrà evolvere nel tempo, quindi la progettazione deve evitare di precludere la possibilità che questo accada, facendo scelte progettuali che possano condizionare il processo evolutivo del software.

6) Misurare gli obbiettivi

Misurare gli obbiettivi: è importane individuare gli obbiettivi da raggiungere, in termini di funzionalità e processi; definire delle metriche in grado di valutare se stiamo procedendo bene o se stiamo procedendo male.

I sistemi di misurazione devono essere sintetici, pochi indicatori chiave, e specifici, cioè strettamente legati al servizio che si intende misurare.

Dobbiamo misurarci. Bisogna saper correre ai ripari -> gli obbiettivi devono essere misurabili.

7) Miglioramento continuo

Miglioramento continuo: il rilevamento del grado di raggiungimento degli obbiettivi è fondamentale per il miglioramento continuo del servizio. In questo modo di capisce cosa serve veramente agli utenti, evita di creare servizi e funzionalità inutili, concentrandosi sull’essenziale e migliorandolo progressivamente.

8) Pianificare il riuso

Pianificare il riuso: il riuso consente di risparmiare tempo e fatica.

Il sistema deve essere sviluppato in modo:

• Riusare componenti sviluppate in passato
• Sviluppare nuove componenti da utilizzare in futuro

Modelli di processo (vedi slide)

L’ingegneria del software definisce una serie di fasi, attività e task che devono essere svolte dalle diverse persone che lavorano all’interno del processo.

Diversi modelli di processo -> tante sequenze di fasi -> andare all’interno di queste fasi e capire quali sono le diverse attività.

Tutti i processi vengono fatti secondo questi stampo, ma poi vengono adattati e contestualizzati al tipo di prodotto che si vuole realizzare -> non esiste un modello di processo migliore di altri -> esiste un modello di processo che va bene per il prodotto che voglio realizzare.

Tutti i modelli di sviluppo del software sono composti da fasi, attività e compiti.

Ogni fase deve raggiungere un obbiettivo, che viene raggiunto attraverso attività e compiti.

Le attività possono essere generalizzate in due categorie:

Attività strutturali

Attività strutturali: sono verticali, sono settoriali.

Quali sono le attività strutturali? (vedi slide) -> all’interno di ogni macro attività ci sono i task, i compiti.

1. Service requirements
   Fase di raccolta dei requisiti, di individuazione dei requisiti del nostro sistema
2. Design
   Consiste nel cercare di tradurre i requisiti raccolti nella fase principali, in come quel sistema deve fare quel qualcosa -> fase di traduzione
3. Project plan
   4 Bisogna preparare un piano del nostro progetto -> come farlo, quali risorse umane ci servono, le risorse economiche come vengono ripartite, i tempi necessari per completare una singola attività
4. Setting up technology enviroment
   Fase in cui si mettono mano sui sistemi -> la parte più tecnologica
5. Coding and testing software
   Parte principale di sviluppo, di codifica
6. Deployment and integration
7. Maintenance

Attività trasversali

Attività trasversali: vengono definite all’interno di tutte quante le attività strutturali.

1. Progress
   Consente al team di sviluppo di valutare i progressi rispetto al piano previsto e di intraprendere le azioni necessarie a rientrare nei tempi programmati -> fare dei meeting per capire come stiamo procedendo, per capire se siamo puntuali o meno ed eventualmente definire delle azioni di mitigazione
2. Risk management
   Vengono valutati i rischi che possono influenzare il risultato del progetto -> prima di partire col progetto pensare ai rischi che questo progetto può portare
3. Qualità assessment
   Viene valutata la qualità del software -> che faccia effettivamente ciò per cui è stato progettato (prodotto efficace ed efficiente, che rispetti i vincoli temporali previsti, soddisfa criteri di accessibilità e usabilità)
4. Formal technical review
   Vengono valutati i prodotti realizzati in modo da eliminare gli errori prima che questi si propaghino all’attività successiva -> incontri fatti con lo scopo di individuare eventuali errori e evitare che questi si propaghino nelle fasi successive
5. Document preparation
   Comprende tutte le attività necessarie per creare prodotti come documenti, registri, moduli ed elenchi -> fase di preparazione documenti, registri cartacei o digitali
6. Reusability management
   Definisce i criteri per il riutilizzo del software realizzato -> in queste riunioni si cerca di capire se sviluppare componenti nuovi in modo che possano essere riusate in futuro
7. Measurement
   Vengono effettuate le necessarie misurazioni riguardanti:
   • La qualità
   • L’usabilità
   • La rispondenza alle scadenze

La personalizzazione del processo di sviluppo

Non tutti i processi vanno bene per tutti i sistemi -> il progettista deve adottare un approccio agile, in modo da prevedere solo quelle attività che sono appropriate per il team di sviluppo.

Oggi sempre più si sta diffondendo non un modello standardizzato, rigido, ma un modello più agile -> creare solo quello che serve, senza rigidità.

Fasi del processo di sviluppo

Le fasi non sono separate le une delle altre, spesso sono concorrenti e iterative.

Alla fine di ogni fase dobbiamo generare un risultato, un outcome che non è il risultato finale -> molto spesso sono documentazioni (documenti PDF/ presentazione power point, diagrammi).

1. Service requirements

Qual è il requisito del servizio che vogliamo realizzare -> capire cosa deve fare il sistema analizzando quelli che sono i bisogni degli utenti (es ogni voce del menù di prenotazione esami è un bisogno che è stato trovato nella fase di service requirement).

Il sistema deve avere anche dei vincoli (es non posso prenotare questo esame se prima non ne ho prenotato un altro) -> vincolo che può essere normativo, organizzativo ecc.

Cos’è un requisito?

• Un bisogno di un utente
• Un vincolo sul software
• Deve necessariamente essere implementato

Gli obbiettivi:

• 1-identificare gli stakeholder e le loro relazioni all’interno dell’organizzazione -> capire chi sono gli utenti
• 2-individuare i loro bisogni, gli obbiettivi che vogliono raggiungere, le aspettative, in modo da rendere il servizio user friendly, competitivo e rilevante -> quali sono le aspettative che gli utenti finali si aspettano, capire cosa offrire agli utenti finali per poter essere competitivo, apprezzato -> capire quali sono i bisogni degli utenti e per ciascun bisogno si definisce un requisito che dovrà essere implementato.

Alla fine di questa fase, si ottiene un “documento di specifica dei requisiti”: documento che descrive in modo formale tutti i requisiti che sono stati raccolti.

Le attività del service requirements

• Domain knowledge: qual è il dominio applicativo dell’organizzazione aziendale
• Stakeholder identification: cerchiamo di capire chi sono gli attori
• Requirement elicitation: cercare di stimolare gli utenti a raccontare di cosa hanno bisogno
• Requirement analysis: fase di analisi dei requisiti

Domain knowledge

Il team di sviluppo del software deve acquisire tutte le necessarie competenze sul dominio applicativo -> per dominio applicativo si intende il contesto in cui opera l’applicazione, specie con riferimento alla natura e al significato delle informazioni da manipolare.

Il dominio applicativo è l’ambito su cui l’azienda opera -> cercare di acquisire la terminologia, quante più competenze possibili perché la comunicazione tra noi progettisti e gli stakeholder sia chiara, quindi dobbiamo conoscere anche le norme che vi regolano.

Come acquisire informazioni sul dominio?

Studio individuale

• Manuali d’uso