Progettare un software, metodologie ed esperienze

[fek]

Con il termine Design Up-Front si indica quell'attivita' di design di un sistema software a partire dai requisiti imposti dal cliente, che e' praticata prima della scrittura del codice e porta tipicamente alla scrittura di un certo numero di documenti che descrivono questa struttura a vari livelli di dettaglio.

Il Design Up-Front e' la base del modello di costruzione del software chiamato Waterfall (A cascata), dove una serie di stadi di sviluppo producono a partire da un input, un output per lo stadio successivo: l'analisi dei requisiti produce l'input per il design dell'architettura, che produce l'input per la fase di scrittura del codice, che produce l'input per la fase di testing del software, che produce l'input per la fase di deploy all'utente, che produce l'input per la fase di supporto del software fino alla fine del ciclo di vita del software.

Il Design Up-Front viene considerato la fase creativa in cui si produce l'architettura che risolve il problema. Se il design dell'architettura e' dettagliato e ben formalizzato, la fase di scrittura del codice dovrebbe essere puramente meccanica, magari affidata a tool di creazione del codice automatizzata (strumenti CASE).

Mi raccontate le vostre esperienze? Fate Design Up-Front? Vi aiuta? Lo trovate possibile? Lo trovate utile?

Raccontatemi la vostra, poi vi dico la mia esperienza a riguardo.

[mjordan]

Quello che tu chiami forse piu' in modo specifico "design up-front" io sono solito chiamarlo "Processo", cioe' tutto cio' che viene comunemente definito nell'analisi dell'Ingegneria del Software, mentre quello che chiami Waterfall Model (Modello a cascata) sono stato abituato a chiamarlo "Modello Sequenziale Lineare".

Da quello che so io il modello a cascata (il Sequenziale Lineare) e' stato considerato un modello di dubbia efficacia, per diversi motivi.
Il fatto e' che qualsiasi prodotto software e' soggetto a modifica dopo la consegna al cliente e le modifiche riguardano diverse aree. O le mutate esigenze del cliente oppure motivazioni esterne al cliente come ad esempio un nuovo sistema operativo o altre cose).

I motivi per cui e' stato considerato "non efficace" sono:

1) Un progetto reale raramente si conforma agli schemi di tale modello, perche' tale modello incorpora solo in modo astratto il concetto di "iterazione" e pertanto tutte le modifiche al software, successive alla scrittura, diventano causa di confusione.
2) Il "cliente", cioe' colui che dovrebbe fornire le specifiche del software, non e' sempre in grado di stabilirle tutte e comunque, molto spesso, non essendo un esperto, a volte non e' in grado di stabilire il fattibile dal non fattibile.
3) Necessita di molta pazienza (e quindi tempo) da parte dl cliente. Cosa che chiaramente quasi mai avviene.

Quindi, per come la vedo io, i modelli di progettazione del software sono utilissimi sotto certi versi ma a volte di difficile applicazione.

C'e' anche da considerare che il trend contemporaneo nel chi ti da la possibilita' di sviluppare del software e' quello del "io ti pago per scrivere codice e non per fare disegni". Hanno effettivamente fatto degli studi (se non ricordo male IBM) riguardo l'efficacia di un approccio "ingegneristico" al software. Hanno evidenziato benefici sul "lungo termine" e comunque nel campo della manutenzione. Per quanto riguarda un modello formale per l'espressione del software, tornando al discorso che ti ho iniziato prima per UML, tu stesso mi hai affermato che usi UML per documentare il codice che hai scritto (cosa sicuramente molto efficace quando bisogna far capire a chi legge l'architettura sviluppata), ma, quando l'UML dev'essere usato al contrario, cioe' progettare un'architettura in UML e poi generare codice, come lo vedi? A mio avviso non sempre porta benefici, troppe volte alcuni "requisiti" vengono fuori proprio durante lo sviluppo.
In definitiva, per come la vedo io, i modelli di sviluppo del software sono piu idonei per descrivere qualcosa di gia' scritto che non effettivamente utilizzarli nel senso proprio per cui sono stati inventati, cioe' descrivere qualcosa che dev'essere scritto.
Posso sicuramente sbagliarmi (e ne sarei ben felice, sinceramente) ma questa e' la mia impressione "a pelle".

[VICIUS]

Ho cominciato solo da qualche mese. Probabilmente è tutta colpa del mio professore di Ingegneria del software che mi ha aperto gli occhi sulla programmazione ad oggetti XP,TDD,DP e UML. Qualche settimana fa ho deciso di accantonare per un po' C ed imparare C# (ho provato a fare un po di design patterns in C ma venivano fuori solo dei mostri). Personalmente non seguo alla lettera il modello waterfall perché non lo trovo adatto per lo sviluppo di software. Sono più un fan del modello a spirale. Una volta buttato giu un' analisi e un progetto preliminare incomincio a scrivere un po' di codice dopo di che riparto dall'inizio. In ogni caso le varie fasi non devono essere separate, devono potere parlarsi avere/dare dei feedback.

Faccio uso di case tools piu che altro quando ho a che fare con DB. Scriversi tutto il codice SQL necessario per creare un DB richiede troppo tempo ed è noioso. Oppure quando devo realizzare un interfaccia grafica per qualcosa.

Per ora sono molto soddisfatto dei risultati che sto ottenendo. Scrivere codice è più facile una volta che hai messo su carta un po' di idee, scrivere test mi aiutano un sacco a fare debug e C# mi ha liberato dai puntatori, malloc e free

ciao

[fek]

Originariamente inviato da mjordan

[... snip...]

Hai fatto un'analisi sintetica dei problemi del Waterfall a mio avviso perfetta.

quando l'UML dev'essere usato al contrario, cioe' progettare un'architettura in UML e poi generare codice, come lo vedi? A mio avviso non sempre porta benefici, troppe volte alcuni "requisiti" vengono fuori proprio durante lo sviluppo.

Trovo che sia quasi perfettamente inutile. Il processo di scrittura del codice non puo' essere meccanico, perche' proprio durante la scrittura, si potrebbe dire in maniera piu' precisa durante l'esplorazione del dominio della soluzione, si raccolgono le informazioni piu' utili per progettare la soluzione stessa. Queste informazioni non possono essere chiare nel modello UML, perche' non c'e' il codice a suggerirle. Inoltre l'esperienza mi ha insegnato che progettando su carta prima, tendo a overingegnerizzare la mia soluzione, a pensare in avanti e cercare di prevedere la maggior parte dei casi possibili, che magari non si verificherando mai, complicando la soluzione stessa. E' come se pagassi in anticipo qualcuno per fare un lavoro che magari non mi servira' mai.

Secondo me ogni riga di codice rappresenta un costo, qualcosa che paghi in termini di tempo e anche in termini monetari. Quando pago qualcosa voglio che mi sia dato un servizio in cambio, se una riga di codice non mi risolve un problema che ho ora, sto pagando un costo senza ricevere nulla di tangibile in cambio.

Posso sicuramente sbagliarmi (e ne sarei ben felice, sinceramente) ma questa e' la mia impressione "a pelle".

La tua impressione e' molto reale.

[mjordan]

Se viene sviluppato senza riflettere e applicato senza senso, il processo puo' diventare la morte del buon senso.

Frase di Philip Howard.

Io mi domando. Che il buon senso risieda proprio nel non applicare alla lettera il processo?

[mjordan]

Originariamente inviato da fek

Trovo che sia quasi perfettamente inutile. Il processo di scrittura del codice non puo' essere meccanico, perche' proprio durante la scrittura, si potrebbe dire in maniera piu' precisa durante l'esplorazione del dominio della soluzione, si raccolgono le informazioni piu' utili per progettare la soluzione stessa.

Quindi il mio sesto senso non sbagliava
Quoto un'altra frase che mi viene in mente, questa volta non ricordo di chi:

Tutti sono in grado di scrivere codice leggibile da una macchina. Non tutti sono in grado di scrivere codice leggibile da un essere umano.

Questa frase, secondo me, riassume il nocciolo di tutta l'ingegneria del software e in gran parte, si riallaccia a quello che dicevi tu precedentemente nell'altro thread, Fek. Cioe' come scrivere codice. Talmente semplice da autodocumentarsi, rendendo inutili i commenti. Nel tuo ragionamento, mentre si scrive codice per una macchina, si tiene in considerazione il fattore "human being". Quello che invece avverto con alcuni modelli per la progettazione del software e che si tenga conto, invece, soltanto del fattore umano, come se il codice prodotto debba essere piu' leggibile da un umano che non da una macchina. Non so se riesco a spiegarmi, quello che voglio dire che mentre nella tua affermazione leggo "una posizione intermedia", in alcuni modelli di progettazione vedo "una posizione estremista".

Ecco perche' prima mi domandavo se nel buon senso effettivamente bisogni tener conto di non applicare alla lettera tali modelli

[fek]

Originariamente inviato da mjordan

Quoto un'altra frase che mi viene in mente, questa volta non ricordo di chi:

Martin Fowler, in versione inglese: "Every fool can write code that a machine can understand, only good programmers can write code that a human can understand".

La cito ogni tre post

Non so se riesco a spiegarmi, quello che voglio dire che mentre nella tua affermazione leggo "una posizione intermedia", in alcuni modelli di progettazione vedo "una posizione estremista".

Io su questo punto sono estremista, anche se non dovrei esserlo visto quello che programmo. Per me il codice deve sempre essere scritto pensando a chi lo legge e non alla macchina (quel chi lo legge la maggior parte delle volte siamo noi stessi e io mi voglio molto bene, so di essere molto pigro, e non voglio farmi perdere tempo ).

L'unica eccezione e' quando un tool ci dice in maniera chiara e inequivocabile che un certo pezzo di codice presenta un problema in termini di performance; e non c'e' modo di riscriverlo per risolvere il problema in maniera pulita; e non c'e' modo di riorganizzare il codice a livelli superiori per risolvere il problema; e si sta avvicinando una milestone quindi ci serve una soluzione veloce; e siamo pronti ad accettare il rischio; e facciamo un voto a San Kent Beck di non farlo mai piu'; e manteniamo la versione del codice pulita come riferimento; e commentiamo bene la nostra decisione. Se tutte queste condizioni sono verificate, allora mi permetto di scrivere codice illegibile. E me ne pento subito dopo.

[RaouL_BennetH]

Fra tutti quelli che potranno seguire quest'interessantissimo 3d, io sono il meno adatto, però vorrei solo postare le mie due uniche attuali esperienze di programmazione. Siete persone molto intelligenti, quindi confido in voi che non riderete di me

1) Problema :

mio padre ha una micro aziendina, dove purtroppo non ci sono fondi da investire in software professionali per certe cose, tipo il rilievo delle presenze. Quindi, avendo questo problema, anche se io personalmente faccio un lavoro completamente diverso (lavoro all'ufficio reclami di una nota azienda alimentare, il chè significa che becco tutte le telefonate di gente incazzata che se la prende con me.... )mi son detto: aiuterò mio padre . Bene, presto detto ho cercato un kit fai da te per costruirmi un lettore di badge. Trovato il kit, l'ho montato e funzionava. Bene, non mi restava che cercare di capire cosa fare per collegarlo al computer e fare in modo che il passaggio dei badge venisse memorizzato e, possibilmente controllato dal computer. Così, cominciai ad interessarmi al C e son riuscito a mettere giù qualche riga che mi permette di interfacciarmi con il dispositivo seriale, leggere il codice del badge e memorizzare l'orario e il codice su un file di testo. Poi, ho fatto la parte relativa all'ufficio di mio padre. Incapace di utilizzare interfacce grafiche con linguaggi più "seri" tipo C, C++ o Java, mi son messo con visual basic e mysql per fare in modo di fornire a mio padre una semplice interfaccia mediante la quale prendersi i dati contenuti in quel file di testo, e memorizzarli in base a certi criteri, fare la somma delle ore (cionci, ricordi il post ? ) e cose così.

2) Problema: sempre perchè sinceramente a me non piace e non sono fautore del "se non ho i soldi per comprarlo originale, compro "la copia" ", serviva un gestionale un pò più semplice per un utente come mio padre e, pian pianino, sto cercando di scrivergli qualcosa in questo senso.

Con questo cosa voglio dire da programmatore non di mestiere ne di studio (purtroppo ) Che per le mie uniche piccole esperienze, son partito dal problema di base e ho cercato di utilizzare gli strumenti che in quel momento ritenevo più comprensibili per me e più facili da utilizzare per gli altri. Non so quanto questo però, possa esservi utile a livello di cultura personale

RaouL.

[cionci]

Ho cambiato il titolo del thread per cercare di renderlo più comprensibile a tutti.

[cionci]

Per quanto mi riguarda ritengo che una progettazione basata su UML secondo l'obiettivo che si pone UML stesso entra troppo nel dettaglio realizzativo...e sicuramente a volte complica la vita visto che, almeno a me, viene molto più facile risolvere un problema mentre programmo che mentre faccio un diagramma UML...

Secondo me UML si può usare per generare un diagramma che descriva ad altissimo livello l'interazione fra moduli del sistema e l'interazione fra utente e sistema...

Quindi principalmente i diagrammi che ho usato di più sono il component diagram e lo use case diagram...

Un altro tipo di diagramma che può essere utile è il sequence diagram...

Il class diagram lo trovo inutile, anzi dannoso per l tempi di realizzazione...e secondo me potrebbe essere generato partendo dal codice alla fine della realizzazione per creare una sorta di documentazione...

Riguardo alle metodologie di progettazione...è dififcile dire quale sia la migliore, ma ritengo che sia utile (se non ci sono imposizioni) viaggiare inizialmente con un modello a cascata per poi andare a finire su un modello incrementale...anche se è difficile generalizzare in questo modo

[fek]

Originariamente inviato da cionci

Ho cambiato il titolo del thread per cercare di renderlo più comprensibile a tutti.

Hai ragione, il mio primo titolo era troppo specifico. Grazie

[alesnoce]

Leggendo qua e la mi è venuto in mente l'accostamento test - design by contract.

Ho trovato interessante il suggerimento, che mi è stato dato nell'altro thread, di creare i test prima del codice che è oggetto dei test stessi, però il difficile è farsi venire in mente questi test.

L'idea delle pre- e post-condizioni e degli invarianti che sta alla base del design by contract mi sembra a priori aiutare a crearli e a fare del pre-debugging.

Fermo restando che per fare un buon programma la cosa più importante e la prima da fare, IMHO, è conoscere quanto più possibile il problema da risolvere, altrimenti non puoi sapere nemmeno quali possono essere gli invarianti, vorrei sapere se qualcuno di voi usa l'accoppiata test-D.b.C..

Ciao

[mjordan]

Purtroppo nessuna metodologia si puo' sostituire all'esperienza. Anzi, usare metodologie senza esperienza porta a risultati ancora piu' disastrosi.

[^TiGeRShArK^]

Alla fine il problema di base secondo me è ke ogni software è più frutto di un atto creativo ke non di un semplice lavoro meccanico.....
x farmi capire meglio.... se fosse possibile trovare una metodologia perfetta di progettazione del software, magari sarebbe anke possibile riuscire a farsi aiutare moltissimo dalla makkina semplicemente traducendo il progetto in linee di codice.
Tutto questo ovviamente non è possibile, perkè x risolvere dei problemi è necessaria un'elevata dose di "creatività" ke gli approcci prettamente meccanici non possiedono assolutamente.

[mjordan]

Io sarei curioso di sapere le esperienze di Fek ...

[DanieleC88]

Io, sicuramente sbaglierò, ma faccio tutto "senza pensarci"... cioè, mi faccio un'idea del codice che dovrei realizzare e in che ordine farlo, ma senza progettare davvero niente. Poi il resto lo affronto strada facendo.

P.S.: mjordan e cionci, maxithron vi saluta!

[cionci]

Originariamente inviato da DanieleC88

P.S.: mjordan e cionci, maxithron vi saluta!

Dov'è ? E' da una vita che non lo vedo !!! Salutamelo !!!

[cionci]

Originariamente inviato da DanieleC88

Io, sicuramente sbaglierò, ma faccio tutto "senza pensarci"... cioè, mi faccio un'idea del codice che dovrei realizzare e in che ordine farlo, ma senza progettare davvero niente. Poi il resto lo affronto strada facendo.

Finchè si tratta di un progetto piccolo, lo puoi anche fare...ma appena sali di dimensioni e/o devi collaborare con altre persone...perdi molto più tempo a fare così...te lo assicuro

[DanieleC88]

Originariamente inviato da cionci

Dov'è ? E' da una vita che non lo vedo !!! Salutamelo !!!

L'ho trovato su un canale IRC, e vi voleva salutare ma ha detto che ha perso anche la password del forum... non lo frequenta da tempo perché ha avuto un litigio con un moderatore. Te lo saluto appena posso, si è disconnesso poco fa dal canale.

P.S.: si, hai ragione, quel modo di fare va bene solo con piccoli progetti, ma il problema è che io ho *solo* piccoli progetti!

[mjordan]

Originariamente inviato da DanieleC88

Io, sicuramente sbaglierò, ma faccio tutto "senza pensarci"... cioè, mi faccio un'idea del codice che dovrei realizzare e in che ordine farlo, ma senza progettare davvero niente. Poi il resto lo affronto strada facendo.

P.S.: mjordan e cionci, maxithron vi saluta!

Davvero... Dov'e' Maxithron, non si va federe da una vita! Ricambia i saluti da parte mia, ci manca qui sul forum.