Alkampfer's Place

Il blog di Gian Maria Ricci
posts - 659, comments - 871, trackbacks - 80

My Links

News

Gian Maria Ricci Mvp Logo CCSVI in Multiple Sclerosis

English Blog

Tag Cloud

Article Categories

Archives

Post Categories

Image Galleries

I miei siti

Siti utili

L’importanza dei requisiti

I believe the hard part of building software to be the specification, design, and testing of conceptual construct, not the labor of representing it and testing the fidelity of the representation.

The hardest single part of building a software system is deciding precisely what to build

The mythical man month.

L’esperienza degli anni mi fa sempre di più apprezzare questa citazione, i problemi tecnici si superano, i bug vengono corretti, le tecnologie evolvono ed aiutano, ma se non si capisce cosa si deve costruire… è tutta fatica sprecata. Per questa ragione ritengo che il successo di un progetto non può prescindere da un buon analista, figura che però è quantomeno difficile da trovare. Spendendo i miei due cents penso che un buon analista:

1) debba capire quello che serve al cliente e non imporre le proprie scelte
2) debba necessariamente dialogare con i futuri utenti e fruitori del prodotto, e chiedere a loro opinioni su come vorrebbero il software
3) generare una documentazione molto snella dei requisiti e non generare documenti chilometrici pieni di “Fuffa” per intortare il cliente
4) includere il cliente nel ciclo di vita del prodotto
5) assumere un atteggiamento socratico “so di non sapere”

in particolare il punto 5 è molto importante, nei processi industriali ad esempio, bisogna approcciare l’analisi sapendo di non conoscere nulla del processo, e quindi è necessario fare interviste a tutte le figure, dai manager fino agli operai che lavorano sulla catena, approcciando ogni colloquio con l’attitudine di chi non sa nulla e deve apprendere da chi ha davanti. Spesso invece si adotta un approccio del tipo “arrivo io e ti spiego come devi lavorare”, che è foriero di problemi di ogni tipo.

alk.

DotNetKicks Image

Print | posted on sabato 24 luglio 2010 14:20 | Filed Under [ Citazioni ]

Feedback

Gravatar

# re: L’importanza dei requisiti

Concordo al 100%, io penso infatti che il cliente dovrebbe vedere il prima possibile il software, per questo se posso adotto sempre integrazione continua, cosi che lo stakeholder possa verificare dove sta andando il prodotto e possa dare feedback continui.

Sono anche io daccordo che nella maggior parte dei progetti, adottare un processo agile spesso è l'unico modo di sopravvivere senza bagni di sangue :)

Alk.
25/07/2010 16:19 | Gian Maria
Gravatar

# re: L’importanza dei requisiti

Alk:> è molto importante, nei processi industriali ad esempio, bisogna approcciare l’analisi sapendo di non conoscere nulla del processo

Assolutamente d'accordo, fuorche' per il punto 5, che e' discutibile se preso alla lettera: si presuppone che un analista non sia completamente all'oscuro del dominio del problema! E' vero, d'altra parte, che ci vuole mente aperta, perche' il problema che il cliente chiede di risolvere resta sempre unico e da capire nella sua specificita'.

Luka:> Insieme ai requisiti la tecnologia ... e anche il fattore umano ... sono le principali fonti di complessitá

Sul fattore umano potremmo anche essere d'accordo, in quanto fa parte degli aspetti concettuali, ma sulla tecnologia no: il punto che in questi casi si vuole sottolineare e' appunto che l'aspetto *concettuale* e' quello davvero complesso, ed e' la chiave per il successo di un progetto software. Tornare a parlare di tecnologia et similia fa perdere proprio quella distinzioni che si tentava di fare: fra cio' che e' primario e cio' che non lo e'.

> Uncertainty is inherent and inevitable in software development processes and products

Falso: l'incertezza la lasciamo ai dilettanti, in ingegneria si gentiscono requisiti e rischi.

> For a new software system, the requirements will not be completely known until after the users have used it

Falso: il discorso corretto e' che l'analisi non finisce mai (non finisce fino a dismissione del prodotto), cosi' come e' per tutte le attivita' di progetto. (Falso su cio' che si deve fare all'inizio, e falso su cio' che viene dopo.)

> It is not possible to completely specify an intaractive system

Falso: un sistema va specificato e va specificato bene, *chiudendo* l'analisi come si fa per tutti gli altri artefatti; altra cosa e' ricordare che il processo software non puo' che essere incrementale salvo i casi piu' banali.

-LV
26/07/2010 18:14 | LudovicoVan
Gravatar

# re: L’importanza dei requisiti

Complimenti Gian Maria, bellissimo post! Sono completamente d'accordo con tutti i punti, in particolar modo con il numero 5. Anche io sono un "vero credente" del "Deliver early, deliver often"...
26/07/2010 18:37 | Davide Senatore
Gravatar

# re: L’importanza dei requisiti

E complimenti alla lungimiranza di categoria.

-LV
26/07/2010 19:01 | LudovicoVan
Gravatar

# re: L’importanza dei requisiti

@ludovicovan: per il punto 5 hai ragione, chiaramente l'analista non dovrebbe essere completamente all'oscuro, ma talvolta capita e l'errore peggiore che accade, è che talvolta l'analista adotta l'approccio "so io come si fa" e li nascono disastri :).

Sono in particolare daccordo con il concetto di gestire i rischi, anche questa è una pratica che spesso viene completamente omessa :(.

Alk.
26/07/2010 20:25 | Gian Maria
Gravatar

# re: L’importanza dei requisiti

Io credo che per arrivare realmente al successo di un progetto, oltre ad un buon analista (ed ovviamente un buon team di sviluppo), ci vuole soprattutto un buon negoziatore.
figura che non c'entra davvero nulla con un profilo tecnico, ma senza il quale non si va davvero da nessuna parte.
27/07/2010 12:53 | Roberto Messora
Gravatar

# re: L’importanza dei requisiti

Anche per questo secondo me gli approcci agili sono più vincenti, perchè il cliente è più coinvolto nelle fasi di sviluppo. Negli approcci tradizionali il cliente si vede arrivare un analista (che spesso è anche il commerciale creando quindi il peggior connubio possibile) che gli fa domande, poi se ne va e dopo un po di tempo (usualmente con ritardo) si vede arrivare un software che non fa quello che chiede .... dopo anni mi rendo conto che bisogna anche vedere il tutto dalla parte del cliente.

Se ci sta trasparenza con il cliente secondo me il negoziatore è più marginale, ciò non toglie che talvolta ci sono clienti con i quali è più difficile comunicare, ma non è mai impossibile.

alk.
27/07/2010 13:20 | Gian Maria
Gravatar

# re: L’importanza dei requisiti

> Negli approcci tradizionali il cliente si vede arrivare un analista (che spesso è anche il commerciale creando quindi il peggior connubio possibile) che gli fa domande, poi se ne va e dopo un po di tempo (usualmente con ritardo) si vede arrivare un software che non fa quello che chiede ....

Quelli sono gli approcci tradizionali andati a male! Negli approcci "tradizionali", l'analista lavora fianco a fianco con il cliente per tutta la durata del progetto. Come ho segnalato in piu' occassioni, la differenza essenziale fra approcci tradizionali e approcci agili e' solo nel livello di formalita'.

Occorre forse anche tenere a mente che molti progetti software vanno a male indipendentemente dalla strategia di sviluppo: spesso una strategia di sviluppo non c'e' affatto. E uno dei mali principali del nostro settore, IMHO, e' proprio che e' sempre piu' un commercio e sempre meno un'industria, cosa che dipende solo in parte dipende dall'andamento del mercato.

-LV
27/07/2010 14:40 | LudovicoVan
Gravatar

# Rapporti con il cliente–questi sconosciuti

In un recente post si sono aggiunti alcuni commenti con spunti interessanti e proprio stamattina ho letto
27/07/2010 18:01 | ExternalBlogs
Gravatar

# re: L’importanza dei requisiti

Complimenti per il post e concordo pienamente.
Il problema che in alcuni casi capita che l'analista del cliente per i punti 1-2-3 faccia esattamente l'opposto e qui la situazione non è per nulla piacevole.
29/07/2010 03:22 | Simone Feriti
Comments have been closed on this topic.

Powered by:
Powered By Subtext Powered By ASP.NET