L’orologio

Formalmente la pianificazione dei tempi non fa necessariamente parte dell’analisi del software: alcuni analisti, ben sapendo la variabilità di simili previsioni, demandano il tutto al Project Manager che seguirà il progetto in futuro.

Io ho sempre trovato che una stima di massima vada comunque data al cliente che deve essere preparato a quello a cui va incontro. Il cliente non è necessariamente un informatico e non deve sapere nulla di come funziona il lavoro: se non gli diamo almeno una stima dei tempi e dei costi potrebbe sottostimarli e buttarsi in un progetto che non è in grado di affrontare.

Leggi tutto

Stabilire i confini

A volte l’analisi è un fatto di libero pensiero ed all’analista è concessa la massima possibilità di scelta per la soluzione migliore possibile.

Spesso però ci sono alcuni confini da rispettare, imposti per volontà o necessità del cliente.
Ad esempio un cliente che tiene particolarmente alla sicurezza ed alla riservatezza dei propri dati non consentirà che essi siano trasmessi in alcun modo attraverso API di terze parti: in questo caso dovremo spiegare al cliente i costi maggiori e le limitazioni derivanti dallo sviluppo di un applicazione software di sua totale proprietà o dall’installazione on-premise di software di terze parti.

Leggi tutto

Definire gli attori

Anni fa, mentre lavoravo in una produzione cinematografica, notai una incredibile analogia tra l’analisi del software e lo spoglio della sceneggiatura.

In questa noiosa procedura dell’industria cinematografica si legge appunto ogni pagina della sceneggiatura e si elenca tutto ciò che è enumerabile al suo interno: luoghi, cose, persone.

Definire gli attori nell’analisi del software è la medesima questione: sfogliate la vostra analisi pagina per pagina e segnatevi quali sono le figure professionali necessarie a lavorare il software.

LEGGI TUTTO

Enumerare i requisiti complementari

I requisiti complementari sono tutti i requisiti che non hanno diretta correlazione con I goal

Questo genere di requisiti spesso si dovranno poi demandare del tutto o parzialmente a consulenti esterni: non dobbiamo fare tutto noi e se non siamo competenti è il momento di consigliare al cliente di informarsi su quegli aspetti che non riguardano direttamente il software in analisi.

Per la GDPR per esempio meglio consultare un esperto, per la SEO un altro etc. Non cercate di proporvi come unica soluzione ai problemi dell’universo: Restate umili.

LEGGI TUTTO…

Elencare i requisiti funzionali

Una delle parti più laboriose e corpose dell’analisi del software è questa: elencare singolarmente tutti i requisiti funzionali, scorporandoli al minimo possibile. L’atomizzazione servirà poi a fare diverse stime.

Durante le interviste al cliente ed ai suoi collaboratori avrete di certo preso dozzine di appunti e vi sarete fatti una mappa mentale dei requisiti funzionali. Fidatevi di voi stessi ma controllate sempre quello che avete prodotto: a volte l’esperienza può farvi dei brutti scherzi.

Una volta provando la presentazione da fare al cliente mi resi conto che una delle funzioni assolutamente necessarie del software peccava nell’analisi: notte insonne per rimediare.

LEGGI TUTTO…

Requisiti del sistema

Una delle fasi più noiose del ciclo di vita di software è definire i requisiti del sistema: Eppure questa parte spesso è quella che può decretare il successo o la rovina di un progetto, cercate di farla meglio che potete.

Paradossalmente potreste sbagliare vari punti della vostra analisi e ottenere comunque un ottimo risultato, invece se i requisiti non sono quelli giusti lascerete a chi vi segue una pesante eredità.

LEGGI TUTTO…