Emiliano Castellina Senior Consultant

Business Analysis

2

Presentazione

Reply è una società di Consulenza, System Integration e Application

Management.

Reply unisce competenze verticali di mercato, con il dominio di tecnologie innovative,

quali ad esempio, Social Networking, Cloud Computing e Internet degli Oggetti, per

ottimizzare ed integrare processi, applicazioni e dispositivi.

3

Business Analyst

• Competenze del business analyst

– Informatico o Gestionale?

• Competenza nelle basi dati

– Uno strumento importante per l’analista è l’estrazione ed elaborazione

di dati significativi per poter prendere le decisioni corrette.

– Se è autonomo del farlo non deve affidarsi all’aiuto dell’amico

informatico.

• Conoscenza dei processi oggetto dell’analisi

– Processi aziendali relativi a

• gestione del customer care

• processo vendite

• campagne di marketing

• gestione delle risorse umane

• Essere aggiornati sulle «nuove» tecnologie

4

Analisi nel ciclo di vita di un Progetto

Advisory

Relazione Tecnica

(Prototipo)

Kick Off

Analisi

• Raccolta Requisiti

• Stesura Analisi Funzionale

• Definizione Test Case

Sviluppo Test Funzionali User Acceptance

Test Go Live

Assistenza

Commerciali Analisti Manager Sviluppatori Cliente

(dirigente)

Cliente

(Utente) Change

Manager

5

Analisi come servizio

Nuovi requisiti

Analisi

• Raccolta Requisiti

• Stesura Analisi Funzionale

• Definizione Test Case

Sviluppo

Test Funzionali User Acceptance

Test Go Live

Analisti Manager Sviluppatori Cliente

(dirigente)

Cliente

(Utente) Change

Manager

6

Niente Analisi!?!

Advisory Relazione Tecnica

Sviluppo

Go Live

Commerciali Analisti Manager Sviluppatori Cliente

(dirigente)

Cliente

(Utente) Change

Manager

7

Niente Sviluppo!?!

Advisory Relazione Tecnica

Analisi (Configurazione)

(Test funzionali) (User

Acceptance Test) (Go Live)

Commerciali Analisti Manager Sviluppatori Cliente

(dirigente)

Cliente

(Utente) Change

Manager

8

Raccolta dei requisiti

• Modalità

– Email: i requisti vengono definiti con uno scambio di email con gli utenti.

(Frequente nella modalità di analisi a servizio, raro negli altri casi)

– Meeting con gli utenti.

– Normativa: talvolta il requisito è costituito da gestire o modificare un processo

per rispettare una normativa specifica (ad esempio manovra Monti, legge

antiriciclaggio).

• Strumenti Utilizzati

– Carta e Penna, o PC, o tablet (per essere più cool)

– Pazienza

9

Analisi Funzionale e Analisi Tecnica

• Analisi Funzionale

– Formalizza i requisiti di business ed i vincoli progettuali

– Elabora soluzioni di alto livello comprensibili all’utente finale

– Fornire indicazione agli sviluppatori per poter redigere analisi tecnica

• Analisi Tecnica

– Progetto vero e proprio del software/funzionalità che sarà sviluppata

– Dipendente dalla tecnologia utilizzata

– Tipicamente non comprensibile all’utente finale

• Analisi Funzionale Ibrida

– Formalizza i requisiti di business ed i vincoli progettuali

– Elabora soluzioni di alto livello comprensibili all’utente finale

– Progetto del software/funzionalità che sarà sviluppata

– Comprensibile all’utente

– Sufficiente agli sviluppatori per poter implementare il software

10

Analisi Funzionale Strumenti Utilizzati

• Dipende dalle scelte del cliente

• Tipicamente non utilizzati diagrammi UML

• Si preferisce allo «standard» una rappresentazione

– più semplice

– graficamente accattivante

11

Analisi Tecnica – Strumenti Utilizzati

• Concordato con gli sviluppatori

• Standard UML (o quasi)

• Utilizzo di tool che permettano una trasformazione automatica da diagrammi

UML a codice

– Esempio tipico: trasformazione da Modelli ER a codice SQL.

12

Analisi Funzionale Ibrida– Strumenti Utilizzati

• Dipende dalle scelte del cliente

• Utilizza solo in parte diagrammi UML

• Si preferisce allo «standard» una rappresentazione

– più semplice

– graficamente accattivante

• Talvolta vengono utilizzati tool che permettano una trasformazione

automatica da diagrammi UML a codice

13

Use Case e Test Case

• Use Case

– Definiti all’interno del documento di analisi funzionale

– Raramente definiti con diagrammi UML

– Utilizzati per elaborare la lista di test case

• Test Case

– Non sono Unit Test di sviluppo

– Devono essere comprensibili all’utente

– Devono considerare tutti gli Use Case definiti nell’analisi

– In caso di progetto di nuove funzionalità, devono verificare che il software nel

suo complesso continui a funzionere come prima (Not regression test)

14

Tips & Tricks

• Durante la raccolta dei requisiti evitare di

– Proporre soluzioni immediate spinti dall’euforia del momento • Il requisito emerso dalla discussione deve essere analizzato adeguatamente

– Confermare effort/tempi senza aver analizzato il problema <<Allora secondo te in una settimana ce la si fa?>>

– Assecondare a priori le soluzioni già trovate dal cliente <<Avremmo pensato che non ci serve aggiungere un campo per il codice

fiscale, tanto abbiamo il campo note disciplinari che è sempre vuoto!!!>>

<<Noo, non ci serve l’inserimento facilitato delle date con il calendario. Ai nostri

utenti va benissmo il sistema vecchio in cui devono scrivere

2014-01-16T09:52:00+00:01 >>

15

Tips and Tricks

• Non fidarsi degli utenti – Progettere applicazioni «blindate», a prova di utenti «creativi»

• Il sistema deve previre l’uso errato da parte degli utenti. – Errato ordine di esecuzione di comandi/funzionalità

– Errato o mancato input

• Richiesta conferma per operazioni critiche

– Documentarsi e Verificare le verità assolute emerse durante la raccolta dei

requisiti

• Non vi preoccupate, non si verificherà mai che ...

• La legge 80/2020 prevede che ....

• No, questa cosa non ci serve proprio, noi facciamo così ...

– Progettare sistemi di log efficaci

• Per prevenire richieste di assistenza del tipo <<Ho cliccato lì come al solito e il sistema

oggi non funziana>>.

• Per evitare il paradosso del tecnico informatico: quando l’utente cerca di replicare il

problema davanti ad un tecnico (o persona che potrebbe risolverlo) il problema non si

verifica.

16

Tips and Tricks

• Progettare Soluzioni Generali

Esempio (ispirato ad un progetto reale).

Requisito: Enanchement del sistema per visualizzare l’etichetta (TAX FREE) in tutti i report

affianco ai clienti tedeschi e francesi.

Anagrafiche presenti nel sistema:

- Cliente (Nome, Cognome, ...., Nazione)

- Nazioni (Nome Nazione, Nazionalità, Codice ISO)

17

Tips and Tricks

Progetto 1:

- hard coding della generazione delle etichette a livello di codice.

if(user.Nazione.Nome=='Germania' or

user.Nazione.Nome=='Francia'){

Stampa("TAX FREE "+user.NomeCognome());

} else {

Stampa(user.NomeCognome());

}

Pro

• Minor costo

• Risponde esattamente ai requisiti

Contro

• Non permette di gestire facilmente cambi di specifica

• Non permette di evolvere il sistema in futuro

Germania

e Francia!?!

No, avevo detto

Germania e Finlandia

Da domani,

l’etichetta dovrà essere

stampata solo se il

cliente è francese

18

Tips and Tricks

Progetto 2:

- aggiungere un parametro di configurazione che indica per quali nazioni si debba stampare

l’etichetta FREE TAX.

Pro

• Permette ai configuratori di sistema di modificare facilmente il comportamento del sistema

Contro

• L’utente non è in grado di apportare le modifiche da solo

if(parametroConfigurazione.Contiene(user.Nazione.

Nome)){

Stampa("TAX FREE "+user.NomeCognome());

} else {

Stampa(user.NomeCognome());

}

Da domani,

l’etichetta dovrà essere

stampata solo se il

cliente è francese,

come posso fare?

19

Tips and Tricks

Progetto 3:

• arricchire l’anagrafica delle nazione con un campo che indichi se stampare o no l’etichetta

FREE TAX

• Rendere possibile la modifica del nuovo campo dell’anagrafica nazioni agli utenti

Pro

• Permette agli utenti di modificare in autonomia il sistema

Contro

• Richiede un effort di test e sviluppo maggiore

if(user.Nazione.StampaTaxFree){

Stampa("TAX FREE "+user.NomeCognome());

} else {

Stampa(user.NomeCognome());

}

Bene, ora vorremmo

una funzionalità

che stampasse

l’etichetta DISCOUNT

per i clienti italiani.

20

Tips and Tricks

Progetto 4:

• progettare una nuova funzionalità, che permetta all’utente di definire per ogni report, le

etichette da stampare in base alla nazionalità del cliente.

– Nuova tabella ReportNazioneEtichetta

– Nuova funzionalità di front-end per l’editing

Pro

• Massima flessibilità

Contro

• Costo elevato

Fantastico, ma.......

COSTA TROPPO.

21

Tips & Tricks

• Eseguire User Acceptance test specifici Ipotiziamo che nell’esempio precedente si sia scelta la soluzione 2, 3 o 4.

Conversazione con un utente durante gli user acceptance test.

Analista: come hai potuto leggere dall’analisi funzionale, il nostro sistema permetterà in oltre di

configurare per quali nazionialità stampare l’etichetta FREE TAX.

Per esempio, ora configuro Giappone e Tunisia e stampo.. Vedi tutti i giapponesi e tunisini

hanno la scritta FREE TAX.

Utente: Ma non funziona, avevamo chiesto i tedeschi e i francesi così non va bene!!!

Analista: era solo un esempio per far vedere che il sistema era configurabile. Guarda ad

esempio posso selezionare facilmente tutte le nazioni.

Utente: ma no, non deve funzionare per tutte le nazioni.

Analista: ehm.... Ok, ho capito, guarda configuro Francia e Germania...

Utente: ora sì che funziona!!

22

Tips & Tricks

• Considerare sempre i dati

Quando si ha la fortuna di poter accedere ai dati del sistema informativo,

essi vanno sfruttati il più possibile per:

- Decidere di non sviluppare nessuna nuova funzionalità.

- Nell’esempio procedente dall’analisi dei dati è emerso che l’azienda ha

solo 5 clienti Francesi ed 1 Tedesco.

- L’ufficio vendite stima che il portafoglio clienti non crescerà nei

prossimi anni in maniera rilevante.

- Risulta più conveniente non apportare alcuna modifica al software, e

far dedurre le tasse manualmente agli operatori prima di emeterre la

fattura.

- Fare test mirati che coprono una percentuale elevata di casi

- E’ raramente possibile effettuare test esaustivi

23

Tirocinio,Tesi, Lavoro?

• Analisi integrazione canali social nel Crm Microsoft

Dynamics 2013.

• Twitter come canale efficace di customer care.

• Analisi comparativa di strumenti di sentiment analysis,

come misura della reputazione dell’azienda.

24

Contatti

www.reply.eu

info@reply.eu

Emiliano Castellina

e.castellina@reply.it