A volte ritornano... Re: [PLUTO-Journal] XPJ

[Marco Marongiu]

nicolafragale a libero.it wrote:
> Ciao

Ciao Nicola, speravo che entrassi in gioco anche tu :-)

> io suggerisco di seguire un approccio a la Ingegneria del Software. Cioè
> stabiliamo prima, e nel modo più preciso possibile le nostre necessità, passiamo
> poi alla progettazione del sistema e infine iniziamo a scrivere il codice.

Uhm...

> Una volta definite e formalizzate le nostre esigenze in un documanto di
> specifica dei requisiti (scopo del progetto, tipo di tag da supportare, formati
> in cui esportare, editor visuali o meno, tutto quello che dalla discussione
> risulta essere utile, ecc), passiamo alla progettazione

La definizione delle esigenze era gia` stata fatta, e in base a quella 
io avevo prodotto il DTD; questa parte va, al massimo, formalizzata o 
appena rivista, se qualche esigenza e` cambiata nel corso di questi 
ultimi anni, ma rifarla da capo mi sembra che prenderebbe troppo tempo e 
ci rimetterebbe al palo. Stavolta, pero`, definitivamente.

> Apriamo su Pluto Devel una pagina ufficiale del progetto, pubblichiamo
> questi documenti (che saranno la nostra guida) e iniziamo a scrivere il core del
> codice.

Non lo vedo strettamente necessario. Anzi, considerato il tempo che 
avremo per lavorare al progetto e il tempo che abbiamo gia` perso, 
mettere su una pagina per pluto-devel mi sembra addirittura _dannoso_.

Il tuo approccio e` estremamente pulito, logico, ordinato... ma contiene 
anche una serie di passi che per necessita` dobbiamo saltare. Non 
possiamo ne' impiegare tempo a fare cose che abbiamo gia` fatto in 
passato (vedi le valutazioni sulle esigenze: riprendiamo i vecchi thread 
e vediamo se bisogna aggiungere/togliere/cambiare qualcosa, stop), ne' 
sulle formalita` (la pagina ufficiale del progetto su pluto-devel: ci fa 
perdere tempo e basta; troviamo piuttosto un punto comune dove 
condividere i documenti -io credo di poter mettere a disposizione una 
istanza di OpenGroupware, ad esempio).

> Chi decidesse di aiutarci nella realizzazione del progetto, non dovrebbe
> far altro che seguire i documenti tecnici e auitare per quello che può/vuole
> (test del codice prodotto, scrittura della documentazione, debugging, ecc).

Nicola, l'esperienza di questi anni dimostra che non abbiamo la fila 
delle persone che vogliono partecipare al progetto fuori dalla porta. Ci 
siamo io, te, Claudio; se facciamo una call su pluto-devel, a malappena 
troveremo un'altra persona, forse due. Val la pena di muovere uomini e 
mezzi per cinque persone?

> Questa a grandi linee è la via che attualmente l'ingegneria del software
> prescrive per la realizzazione di sistemi software di dimensioni non banali, e
> il nostro ad occhio e croce lo è.

Non e` piccolissimo, ma neanche grande.

Se nel progetto comprendi anche la realizzazione di un editor per il 
formato XPJ, probabilmente ne usciamo malissimo... ma se per ora il 
focus del progetto rimane:

* definire un formato per gli articoli,
* definire un formato per il journal
* definire il formato delle pagine web e del PDF da generare,
* scrivere dei fogli di stile in qualche linguaggio,
* scrivere degli automatismi per generare HTML e PDF dai sorgenti

la dimensione del progetto diventa immediatamente abbordabile, anche per 
un gruppo ristretto di persone quale siamo attualmente.

> I vantaggi principali di questo approccio sono
> relativi ad una più semplice espandibilità e manutenzione, ad un codice più
> pulito e coerente, meno bug dovuti ad incongruenze nel progetto (non si inizia a
> scrivere codice da modificare più e più volte a causa di valutazioni scorrette) ecc.

Nicola, sono *assolutamente* d'accordo su questo punto, ma 
l'organizzazione non viene gratis: richiede risorse; e vorrei evitare 
che sprechiamo risorse ad progettare cose gia` progettate, o a creare 
strutture che basterebbero a 50 persone per lavorare in parallelo 
quando, alla fine, quelle persone saranno a malappena 5! Insomma, 
troviamo una via di mezzo!!!

> Tutto il lavoro da fare, che a prima vista sembrerebbe inutile, diventa invece
> prezioso per l'effettiva creazione del software.

Ne sono cosciente, ma... calibriamo bene gli sforzi: abbiamo tempo e 
forze limitati, tutti quanti. Lo sappiamo bene, no?

Ciao!
--bronto

-- 
Marco Marongiu                                Tiscali Services s.r.l.
System Engineer                               S.S. 195, km 2,300
IT Systems Management Dept.                   Loc. "Sa Illetta"
Phone: +39 070 460 1684                       09122  Cagliari   (CA)
Fax:   +39 070 460 9684                       Sardegna - Italia
------------------------------------------------------------------------
If you don't know where you're going / any road will take you there
                        -- George Harrison, "Any Road", Brainwashed, 2002
------------------------------------------------------------------------