: come integrare ingegneria dell usabilità e del software Giorgio Brajnik e Andrea Baruzzo Dip. di Matematica e Informatica Università di Udine e Interaction Design Solutions srl www.dimi.uniud.it/giorgio www.andreabaruzzo.com ISACA Venice 29 Maggio 2013
Scopo del seminario Capire l impatto di una buona ingegneria dei requisiti nel successo di un progetto software Avere una panoramica di varie tecniche di ingegneria del software e di usabilità Capire come innestare tecniche di usabilità in pratiche di ingegneria del software
Siamo in buona compagnia F35 (Wikipedia) cost: 248e09 EUR delivery: April 2016 (expected: 2010) Japan and Canada are withdrawing Alcuni commenti The scale of the program has led to a software crisis as officials continue to discover that additional software needs to be written Software is the biggest factor that might delay the USAF s initial operational capability As of the end of 2010, only 15% of the software remains to be written, but this includes the most difficult sections But in 2011, it was revealed that only 50% of the 8 million lines of code had actually been written and that it would take another 6 years and 110 additional software engineers in order to complete the software The total estimated lines of code (onboard and offboard) had grown from 15 million to 24 million by 2012
Alcune domande a cui dare una risposta oggi Ingegneria dei requisiti e progetto interfaccia utente Quanto importante è? Serve adottare tecniche come brainstorming, scenari d uso, personaggi? Servono per l usabilità? User-Centered Development è compatibile con approcci agili? Serve davvero? Ha senso una visione MVC anche a livello concettuale? Ma l usabilità la si può davvero misurare in maniera rigorosa? Ingegneria del software e Domain Driven Design Programmare ad oggetti non è sufficiente? Perché avere anche il DDD? Tutti i progetti software sono adatti al DDD? Come possiamo misurare la qualità di un architettura? Quando un sistema diventa legacy? Come gestirlo? UML è davvero utile per progettare meglio?
Indice Ingegneria dei requisiti e User-Centered Development (Giorgio) Features e approcci agili (Andrea) Design concettuale UI (Giorgio) Domain Driven Design (Andrea) Pausa Usabilità (Giorgio) Architetture software e qualità (Andrea)
Indice Ingegneria dei requisiti e User-Centered Development (Giorgio) Features e approcci agili (Andrea) Design concettuale UI (Giorgio) Domain Driven Design (Andrea) Pausa Usabilità (Giorgio) Architetture software e qualità (Andrea)
Ingegneria del software Scopo sviluppare software di qualità, nei tempi e costi previsti, tale da soddisfare le esigenze dei clienti
In realtà Bassa qualità con bug non affidabili non usabili fragili in ritardo, sovra-budget non rispondenti alle esigenze con funzionalità mancanti con funzionalità inutili
Cause? Cause di fallimento (Standish Group 2010): 1. poco input da utenti: 13% 2. requisiti incompleti: 12% 3. requisiti che cambiano: 12% Nei casi di successo: 1. coinvolgimento utenti: 16% 2. supporto dirigenti: 14% 3. chiarezza nei requisiti: 12%
Quindi Errori nei requisiti: 1. sono i più costosi 2. sono i più gravi come impatto sull applicazione 3. sono tra le maggiori cause di progetti falliti 4. contribuiscono al ritardo nella consegna 5. (se non ci sono) contribuiscono al successo del progetto
User Centered Design 1. coinvolgimento precoce e comprensione degli utenti 2. misure empiriche di usabilità 3. procedimento iterativo: 3.1 pianificazione dell indagine 3.2 sintesi di un prototipo 3.3 valutazione del prototipo
Catalogo di tecniche interviste strutturate a soggetti interessati (e utenti) analisi utenti e loro livelli di esperienza; profili task analysis studi sul campo (contextual design) definizioni del problema brainstorming e focus groups personaggi scenari d uso casi d uso essenziali features come user stories user testing formativo
SOFTWARE SOLIDO E USABILE FEATURES E APPROCCI AGILI 1 Dr. Andrea Baruzzo www.andreabaruzzo.com BARUZZO YOURLOGO by A N D R E A
A Feature is a service the system provides that fulfills one or more stakeholder needs. 2 BARUZZO YOURLOGO by A N D R E A
Features Feature e approcci agili Una feature produce valore per l utente Può essere misurata (azione tangibile) Schema ricorrente Action the result by/for/to an object Esempi Definire uno scenario di programmazione per l impianto otouch Vedere lo stato corrente di un ambiente Attivare automaticamente l impianto da GPS 3 BARUZZO YOURLOGO by A N D R E A
Features Feature e approcci agili Utili perché non troppo tecniche Meno complicate e più modulari di uno use case Più sintetiche e misurabili di una storia Comprensibili da vari ruoli Guidano non solo l analisi e lo sviluppo ma anche il test Alcuni modelli di ciclo di vita sono incentrati su di esse: Feature-Driven Development 5 BARUZZO YOURLOGO by A N D R E A
Feature-Driven Development (FDD) Feature e approcci agili Agile, fusione tra Waterfall e iterativo-incrementale ideato da Jeff De Luca e Peter Coad 5 fasi 1. Sviluppo del modello globale (Build Overall Model) 2. Costruzione della lista di feature (Build Feature List) 3. Pianificazione delle Feature (Planning) 4. Design delle feature pianificate (Design by Features) 5. Sviluppo delle feature pianificate (Build by Features) Lo sviluppo include anche il controllo di qualità (es. Test) 6 BARUZZO YOURLOGO by A N D R E A
Attività di pianificazione e controllo della qualità Feature e approcci agili Domain Walkthrough (fattibilità, inception) Design Inspection Code Inspection Test di unità e di integrazione Costante monitoraggio degli sforzi Costante aggiornamento delle stime 12 byyourlogo A N D R E A B A R U Z Z O
Agile Manifesto Feature e approcci agili 16 BARUZZO YOURLOGO by A N D R E A
E la GUI? Feature e approcci agili Tutte queste pratiche sono pensate per l architettura e i componenti E per la progettazione dell interazione con l utente e delle GUI? Le feature non bastano 22 BARUZZO YOURLOGO by A N D R E A
Indice Ingegneria dei requisiti e User-Centered Development (Giorgio) Features e approcci agili (Andrea) Design concettuale UI (Giorgio) Domain Driven Design (Andrea) Pausa Usabilità (Giorgio) Architetture software e qualità (Andrea)
Per un sistema interattivo Validità dei requisiti in molti casi dipende da accettabilità usabilità user experience (UX): estetica usabilità percepita credibilità e persuasione stimolazione, status symbol, evocazione gestione dell attenzione grado di interattività uso di buone maniere, adulazione, specializzazione E quindi è importante 1. come si rendono espliciti i requisiti di usabilità e UX 2. come li si può validare 3. come si scoprono difetti di usabilità e UX 4. come evitare di includere difetti
Design concettuale Modello mentale: regole causali (nella mente di una persona) che descrivono fenomeni relativi all uso del sistema Modello concettuale: il modello mentale che il designer vorrebbe che gli utenti si formassero Il modello mentale è determinato dall immagine del sistema, data da tutti gli artefatti relativi al sistema che un utente percepisce e usa: interfaccia utente (look & feel e dinamica) manuali messaggi di help messaggi di errore
Modello concettuale
MVC
Tecniche di UCD bozzetti di interfacce modelli dei dati e delle operazioni storyboard prototipi user testing informale e formativo valutazioni euristiche dell usabilità card sorting
SOFTWARE SOLIDO E USABILE DOMAIN-DRIVEN DESIGN 1 Dr. Andrea Baruzzo www.andreabaruzzo.com byyourlogo A N D R E A B A R U Z Z O
Cos è il Domain-Driven Design (DDD) Domain-Driven Design È un approccio alla costruzione di sistemi software Usando tecniche OO Con una forte connotazione orientata a: rappresentazione esplicita della componente di dominio 2 byyourlogo A N D R E A B A R U Z Z O
Perché una componente di dominio esplicita Domain-Driven Design Evitare la «programmazione per effetti collaterali» L interazione GUI-Query-DB nasconde aspetti essenziali: Logica di business Regole (business rules, policy, etc.) 3 byyourlogo A N D R E A B A R U Z Z O
Un MVC deteriorato Domain-Driven Design Business + Control Logic? class System Architecture - NOT DDD Presentation Logic User Interface View Application Presentation Logic Controller Model Data Model? God Class? Infrastructure Persistent Model 4 Technology byyourlogo A N D R E A B A R U Z Z O
byyourlogo A N D R E A B A R U Z Z O
Indice Ingegneria dei requisiti e User-Centered Development (Giorgio) Features e approcci agili (Andrea) Design concettuale UI (Giorgio) Domain Driven Design (Andrea) Pausa Usabilità (Giorgio) Architetture software e qualità (Andrea)
Usabilità è necessaria Usability isn t a luxury on the Internet; it s essential to survival. The Internet follows a kind of Sheer Design Darwinism: survival of the easiest. J. Nielsen and D. Norman
Qualità in uso (ISO 9126-1, 2001): Parametri efficacia produttività soddisfazione sicurezza Contesto di determinati utenti per determinati scopi in determinate condizioni
Metriche di usabilità UCD e Reqs engineering FDD/Agilità Design concettuale DDD Usabilità Architetture tasso di successo livello di successo tasso di completamento n. funzionalità usate n. errori omissione n. errori commissione n. sviste n. compiti svolti senza errori n. errori per compito n. errori ripetuti tempo tra 2 errori n. errori risolti autonomamente n. messaggi errore compresi n. richieste di aiuto n. utenti non addestrati che raggiungono un liv. di soccesso n. di compiti svolti senza aiuto n. di funzionalità comprese n. di funzionalità/contenuti che si ricordano a posteriori tempo di completamento (assoluto o relativo al livello di efficacia) n. di click, di scroll, di close window carico mentale...
Alcuni metodi valutazioni euristiche user testing test con eye tracking A/B testing
SOFTWARE SOLIDO E USABILE ARCHITETTURE SOFTAWARE E QUALITÀ 1 Dr. Andrea Baruzzo www.andreabaruzzo.com BARUZZO YOURLOGO by A N D R E A
Il ruolo delle archietture software Il ruolo dell architettura software L architettura software è l organizzazione di base di un sistema, espressa dai suoi componenti, dalle relazioni tra di loro e con l ambiente, e i principi che ne guidano il progetto e l evoluzione [IEEE/ANSI 1471 2000] Spesso è la parte più intangibile del software Come capire se un sistema è ben progettato? Il testing e la 2 testabilità svolgono un ruolo decisivo BARUZZO YOURLOGO by A N D R E A
Testing e testabilità Il ruolo dell architettura software Il testing misura una proprietà dello stato del sistema Rispetta/non rispetta le specifiche La testabilità è una proprietà del design È facile/difficile da collaudare Il testing ha ripercussioni sulla correttezza La testabilità ha ripercussioni sulla manutenibilità 3 BARUZZO YOURLOGO by A N D R E A
Conclusioni UML nei progetti industriali Sviluppare software non è una scienza Fattori umani, economici e tecnici Più strumenti possediamo, più siamo in grado di reagire agli imprevisti con professionalità Ciclo di vita di riferimento con punti di controllo espliciti e ripetibili Tecniche di analisi e progetto (DDD) Tecniche di testabilità (DFT, metriche) Comunicazione (UML) 29 BARUZZO YOURLOGO by A N D R E A
Conclusione Un approccio User-Centered Development è fondamentale UCD viene spalmato sulle varie fasi UCD richiede umiltà UCD sembra costoso, ma alla fine fa risparmiare (errori, tempo e denaro). Realizzare software usabile NON richiede dei superman