Newsgroup: it.lavoro.informatica
Titolo: Analisi dei costi e dei tempi

Nel fare l'analisi dei costi e dei tempi, esistono delle tabelle 
standard di riferimento per i tempi ? Ad esempio, per il design e 
l'implementazione di un database, dividento le attivita in :
- design delle singole tabelle (variabili)
- formulare un grafico entity-relationship
- formulare le varie classi
- riempimento delle tabelle con dati di test
- test
- riempimento delle tabelle con dati reali
che tempistica si adotta normalmente, volendo essere indipendente dalla 
piattaforma usata (oracle, access, MySQL) ?
Oppure la piattaforma influenza i tempi ?
I tempi si sintendono ovviamente in man-hour.
Grazie delle risposte.
John.

 piattaforma usata (oracle, access, MySQL) ?
Probabilmente non dipende dalla piattaforma ma dal database.
Una cosa e' progettare un DB con 2 tabelle, un'altra cosa un DB con 200
tabelle. E anche una singola tabella probabilmente se ha 2-3 campi e' un
conto, se ne ha 100 e' un'altra cosa (anche se, se ne ha 100 e' probabile
che ci sia qualche errore nella progettazione).
Ma anche senza errore di progettazioni, ad esempio i tempi per
l'inseirmento
dipendono da quanti sono i dati reali con cui le devi riempire (e le
modalita' con cui le riempi). Se una tabella deve contenere al piu' 1000
record e' un conto, se ne deve contenere 2 milioni e' un'altra cosa.
Inoltre inserire i dati a mano e' una cosa, avere un software che consente
agli utenti di registrarsi ad un servizio e far finire nella tabella
"anagrafica" i loro dati e' un'altra cosa. Lo stesso per eventuali dati di
test. Se li puoi far generare automaticamente ad un software che accede
alla tabella riempiendola e' un conto, se li devi mettere a mano e'
un'altra cosa.
Personalmente, pur non avendo grande esperienza con i database,
ho sempre visto valutare i tempi in base all'esperienza di chi deve fare
la progettazione/implementazione e non secondo uno standard 
(tra l'altro se ci fosse uno standard riconosciuto, probabilmente non ci
sarebbe bisogno di un Project Manager).
Ciao,
Marco
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 standard di riferimento per i tempi ?
Vieni dal settore costruzioni? :)
--
ale
http://ale.riolo.co.uk


No, vengo dal settore spaziale. L�  � assolutamente obbligatorio 
produrre una previsione. Cio� fare il meglio per essere sicuri di avere 
una ragionevole probabilit� di restare almeno per l'80% nelle 
previsioni. Le sorprese arrivano sempre e comunque, ma ci si sforza di 
prevedere l'imprevedibile.

 No, vengo dal settore spaziale. >
... stasera raitre ha trasmesso Armageddon..... 


Certamente. Sono tutte cose ovvie. ma speravo ci fosse uno 'standard 
accettato'.
facico un esempio. Negli anni 70, si considerava che un software 
engineer potesse sviluppare un software (design, implementation, 
testing) e alla fine, quantificando il tutto e facendo la media,
si otteneva un rendimento di 10 statement al giorno.
Cio� se un software alla fine conteneva 10000 righe di programmazione 
FORTRAN, quel progetto costava 1000 man-days. E si poteva fare un 
calcolo del costo e metterlo nei 'Cost Planning'.
Questo includeva design, codifica e test.


con Bruce Willis. Io non c'ero.
Io ero a Darmstadt.

 l'imprevedibile.
Vedi il caso, gran parte dei clienti per cui lavoro sono nell'aerospaziale, 
noi ci occupiamo di rendere, fin quanto possibile, prevedibile 
l'imprevedibile :)
Ad ogni modo ti chiedevo se venivi dal settore costruzioni perch� in quel 
settore esistono, ed hanno senso di esistere, prezziari con quel genere di 
informazioni. Nell'IT allo stato attuale ha meno senso, per svariati motivi. 
BTW, ovviamente anche noi cerchiamo di fare quello che vorresti fare tu, ed 
onestamente lo cercavano di fare tutti  i miei ex datori di lavoro, anzi, 
una volta ho passato un anno e mezzo a fare solo quello (una parte del mio 
CV su cui glisso volentieri, se non proprio proattivamente), ma a livello 
meno granulare. Le attivit� non sono "design di singola tabella" o 
"riempimento di tabella con dati di test" e via di questo passo, ma attivit� 
che comprendano tutte o parte di queste attivit�.
BTW, derivando su questioni correlate, hai dato un'occhiata a cose come 
Scrum (
http://de.wikipedia.org/wiki/Scrum
) ed Agile 
(
http://de.wikipedia.org/wiki/Agile_Softwareentwicklung
)?
-- 
ale
http://ale.riolo.co.uk
 


Grazie  mille. Ho dato una occhiata. Tutto puo' aiutare.
Anche se devo fare una analisi dei costi e dei tempi in campo medico, 
specialmente per l'implementazione degli standard HL7 in cliniche e 
Istituti che pensano ancora che HL7 sia la sigla di una Lancia Delta.
Non � una cosa facile : non c'� niente di esistente e come dice 
giustamente il concetto 'Agile' le 'interazioni' e lo 'human factor' 
sono fattori primari rispetto ai developing tools.
E questo � verissimo soprattutto in campo medico.
Chiedero a qualche ex-collega di farmi arrivare una serie di 
pubblicazioni per il planning di Software engineering in campo spaziale.
Avevamo degli standard che tutte le ditte appaltatrici erano obbligate a 
seguire.
Mi legger� quelli come riferimento.
Grazie comunque di tutti gli input che ricever�

 l'implementazione di un database, dividento le attivita in :
E' semplicemente impossibile tabellare il tempo di design in base a
scalari come il numero di tabelle o il numero di finestre a meno di
non restringere il campo ad un unico dominio applicativo e piattaforma
software.
- la domanda simile nel tuo campo : quanto ci vuole a progettare un
aereo ?
- la risposta è : dipende dall'aereo !
la relazione tra il tempo impiegato ed il numero di posti a sedere o
la dimensione dello stesso esiste, ma è meno importante di altri
fattori come il tipo di aereo (a elica o turbina? ), i requirement del
cliente (deve essere trasparente ? deve volare a 30.000 metri), il
livello di innovazione (deve fare qualcosa che non fa nessun aereo
creato fin ora) ecc...
Detto questo, quel che si potrebbe tabellare è il tempo di
realizzazione fisica, cioè la realizzazione avendo il DB già disegnato
su carta o su altro formato, cioè avendo il progetto. Ma può essere
fatto solo tenendo in considerazione che tale disegno deve essere a
dir poco accurato, ma partendo che so io .. da un progetto di DB su
carta estratto da un sistema diverso... per ricrearlo su una
piattaforma diversa il tempo è molto basso, in poche ore di tabelle se
ne fanno decine su appositi tool di disegno entity-relationship, che
poi creano automaticamente le tabelle e le classi. Poi con molta
probabilità butterete tutto.. ma questo è un'altro discorso.

 Grazie comunque di tutti gli input che ricever�.
Ricordo una statistica USA di molti anni fa, nella quale  la produttivit�
nel campo dello sviluppo software poteva oscillare anche di un fattore 30 
(!!!)
Ovvero a parita' di progetto, poteva essere realizzato in x giorni oppure in 
30x
 a seconda di molteplici fattori.
Insomma se non e' attivit� artistica, siamo nel campo dell'artigianato puro!
ciao
fm 

 Poi con molta probabilit� butterete tutto.. ma questo � un'altro discorso.
a ecco, ora ci siamo :-)
Andrea 


Provadare un'occhiata ai fucntionalpoint anche se li devi stravolgere un 
po il punto di partenza. Ragioni in termini di funzionalita' piu' che di 
implementazione.
http://en.wikipedia.org/wiki/Function_points


Be', qualcosa di 'fisso' ci sarebbe gi�. Sono le linee guida del HL7.
Ad esempio per il Carlo Mondino di Pavia feci una tesi con un database 
che aveva circa un centinaio di tabelle. Si sta parlando del Electronic 
Patient Record (o Clinical Patient record). C'� vita morte e miracoli di 
un paziente durante la sua vita.
Quindi un buon punto di partenza c'� gi�. POi bisogna vedere quanto � 
grande l'ospedale o la unit� ASL e inoltre tenere conto delle differenze 
regionali concernenti le ASL locali.
Insomma basta leggersi i documenti delle leggi e disposizioni che 
qualche parametro 'fisso' lo si trova.
Poi magari, posso io stesso fare l'esperienza di implementare ad esempio 
su tre piattaforme fisse,  (ad es. Oracle, Access, MySQL) lo stesso 
database ma con 10 tabbelle, non con 100, e cronometrare quanto ci ho 
impiegto.
E cos� magari posso avere una idea dei tempi e impiegarli nel calcolo di 
budget per progetti futuri.
Non so, Questo potrebbe essere un metodo indicativo, in mancanza di 
altri riferimenti pi� precisi.


questo appunto avveniva negli anni 70 ed � pi� o meno dal 90 che quella 
metrica non si usa pi� (aivoglia a scrivere bilioni di codice inutile, 
con bilionate di commenti, istruzioni indettate all'inverosimile ecc.).
come ti ha suggerito s1gfr1d ora c'� il function point per determinare 
il costo di un progetto software, ma non si basa pi� sulle 
caratteristiche "tecniche", ma sulle funzionalit� (e mi sembra pure 
giusto) e quanto queste sono "importanti" per il cliente o rispetto ad 
altre funzionalit� dello stesso software.
faccio un esempio.
se si ha bisogno di un software che deve fare "il caff�", � questa 
funzionalit� che ha un costo indipendentemente dalle metodologie per 
arrivare a "fare il caff�" o dalle tecnologie usate.
il cliente paga per avere il caff�, fotte sega come questo viene fatto.
questo dal lato del cliente.
altro esempio.
il software che gestisce il CC bancario, ha al suo interno una miriade 
di funzionalit�, sicuramente quella che tiene il calcolo degli interessi 
attivi/passivi (magari scritta in cobol 20 anni fa) ha una importanza 
maggiore rispetto alla web application per il web banking.
anche se la web application richiede una miriade di fig 
professionali/metodologie/tecnologie per svilupparla.
questo per l'importanza che ricopre le funzionalit� di un software.
comunque il function point non � propriamente una passeggiata ma � la 
metrica standard per la gestione di progetti software.
Ciao

 ha scritto nel messaggio 
news:itj98u$524$2...@speranza.aioe.org...

... Nel film Bruce Willlis fa analisi dei costi e tempi.... 

 Questo includeva design, codifica e test.
In questo senso lo standard attuale sono i function point ma in 15 anni
non mi e' mai capitato di trovare un'azienda che li usa (anche se in
realta' mi e' capitato di vedere degli annunci che richiedevano esperienza
nel calcolo dei function point).
Qualcosa puoi trovare sui qualsiasi libro di ingegneria del software,
qualcosa lo trovi anche qui:
http://www.gufpi-isma.org/
(c'e' anche un libro del gufpi isma, questo qui:
http://www.gufpi-isma.org/libro/
)
Ciao,
Marco.



azz...me lo son perso !


OK. Grazie della 'dritta'.

 meraviglia pi niente nell'informatica.
John, hai mai pensato di metter giu' la tua esperienza in uno libro?
Seriamente, non credo che in Italia ci siano tante persone con la tua
esperienza, documentarla credo che possa dare un contributo a far
capire l'evolversi della professione di informatico. Non e' mica cosa
da poco, visto che la professione di informatico (se esiste ancora) e'
-secondo me- tra quelle piu' difficili da inquadrare!
ciao Dotto' :-)

 budget per progetti futuri.
Si, certamente. Anche se non ho capito perché misuri in "tabelle",
cioè ti occupi solo del DB ? Altrimenti l'unità di misura per i
software sono le funzionalità non le tabelle.



caro askaholik, se dovessi mettere gi� le mie esperienze, 
assomiglierebbe ad un libro di Fantozzi... :-)))
Certe cose potrebbero essere viste come 'comiche'.
Ma da una parte sono stato benedetto dal Signore, per le esperienze che 
ho fatto. Si puo' dire che dalle circostanze ho imparato molto. 
Soprattutto ho imparato a vivere quarantanni tra nazionalit� diverse,
con le loro mentalit� e peculiarit� e a non sorprendermi ogni volta che 
mi rendo conto che in fondo tutto il mondo � paese. Anche presso i 
cinesi :-)))

 software sono le funzionalit� non le tabelle.
No, quello � forse il lavoro pi� importante, il database, la connettivit�.
Poi ovviamente c'� la GUI e i metodi di Data Input.

 altre funzionalità dello stesso software.
Metodo largamente usato, è vero, ma che funziona abbastanza male nei
casi di modifica/manutenzione di software esistente. Il fatto poi di
non tener conto degli aspetti tecnici può essere una carenza, se
l'ambiente è predeterminato. Es. fare certe cose in Cobol è molto più
difficile che in Java, e viceversa.
Vero anche che alla fine, contati i punti funzione, basta agire sul
prezzo per singolo punto funzione per risolvere tutto.... :-)

 nel calcolo dei function point).
Viene usato sopratutto nel pubblico dove ci sono gli appalti. Non e' una 
scienza esatta ma almeno ti puo' dare una misura anche se magari non e' 
precisa al millimetro.


qui trovi altro materiale qualcuno generico qualcuno piu' specifico.
http://www.cosmicon.com/portal/public/Metodo_COSMIC_3-0_-_Manuale_di_Misurazione.pdf
http://www.cosmicon.com/portal/public/COSMIC_Method_v3.0.1_SOA_Software_Guideline_v1.0a.pdf
http://www.agilemetrics.it/risorse/fpifpug421_guidarapida_20110309.pdf
http://www.cosmicon.com/portal/public/COSMIC_Method_v3_0_DWH_Guideline_v1_0.pdf
http://www.cosmicon.com/portal/public/COSMIC%20Method%20v3.0%20Bus%20App%20Guideline%20v1.1.pdf
http://archivio.cnipa.gov.it/html/docs/cnipa_quad_38_int_a.pdf

 prezzo per singolo punto funzione per risolvere tutto....:-)
Quella e' la fase di contrattazione:)

WOW quanto ben di Dio...
Mi risparmi una giornata in biblioteca.  :-))
Grazie mille !


 Quella e' la fase di contrattazione:)
In genere il prezzo di 1 punto funzione è prestabilito dal contratto,
oggi spesso col supersconto. Quindi si può agire sul numero dei punti
calcolati per una determinata manutenzione, in modo che l'importo
totale sia congruo col lavoro previsto. E qui se ne vedono di
bellissime :-))


Si ma cosi' facendo non applichi i function point. Adatti i functions 
point al prezzo :)  Quindi tanto vale non usarli non trovi? :)



s� ma fa pi� figo e professionale....


E si la professionalit� paga ... indubbiamente :)


di che ti occupi? 


Metï¿œ di informatica medica, metï¿œ di neuroingegneria.
Di questi tempi sto stimando quando mi costerebbe standardizzare in HL7 
l'istituto dove faccio la tesi (in neuroingegneria), per proporlo in 
clinica.

 clinica.
Un mio ex collega al polimi era neurochirurgo, un giorno ad un esame ha 
tirato fuori il libretto, aveva appena passato il 100mo esame :)
-- 
ale
http://ale.riolo.co.uk
 


...<hehehe>...quando lo studio diventa un hobby.  Ti giuro che io alla 
mia etï¿œ mi diverto un mondo. Piï¿œ di quando ero giovane. Anzi, allora non 
mi divertivo affatto. Tutto era un 'obbligo' e se non riuscivi in erano 
caï¿œï¿œi acidi. Invece adesso ï¿œ una goduria.
Non riesco a immaginarmi un modo migliore per trascorrere la vecchiaia, 
veramente (a parte il Bunga Bunga ovviamente  <hahahahaha>).
Ma non sono milionario, ahimï¿œ...


Caro mio mi sa che tu sei molto più vicino alla buddhità di tanti altri :)
Complimenti, se io fossi ancora toccato dalle cose terrene sarei perfino 
un po' invidioso :D
M
-- 
I fatti mi cosano

 point al prezzo :)  Quindi tanto vale non usarli non trovi? :)
E' vero, ma è una prassi diffusa, che io sappia. Principlamente a
causa dei supersconti fatti nel contratto.
Oltre al fatto che i p.f. di per se stessi non sono un misuratore
particolarmente preciso.

 Non riesco a immaginarmi un modo migliore per trascorrere la vecchiaia,
Il modo migliore sarebbe andare a ripetizione davanti ad una
commissione di esame, non di rado costituita da gente non
particolarmente brillante?  Veramente il lato peggiore
dell'università. Che bella vecchiaia.... :-)))

 ho fatto. Si puo' dire che dalle circostanze ho imparato molto.
[...]
a quando il primo capitolo? Mi offro per il review :-)

 non mi e' mai capitato di trovare un'azienda che li usa
Ecchime qua!

 In genere il prezzo di 1 punto funzione � prestabilito dal contratto,
Che ne � del rate?

 Poi ovviamente c'è la GUI e i metodi di Data Input.
Cioè la creazione e popolazione del DB porta via più tempo della GUI e
del codice ? Immagino che bellezza deve essere l'applicazione...

 del codice ? Immagino che bellezza deve essere l'applicazione...
be', io non ho sotto gli occhi un esempio reale, ma vorrei vedere quanto 
tempe ci si impiega a mettere su un database con 100 tabelle i dati di 
dieci anni di un ospedale come il San Martino di Genova....
Non so in quanti funxtion-point misurerei questo lavoro, ma decisamente 
in 2-3 man-years, distribuiti come si vuole....
mi sembra ovvio che l'immettere dei dati prenda pi� tempo che disegnare 
una GUI...

 una GUI...
Ferma, ma tu parli di digitare i dati ? Cioè un inserimento manuale di
10 anni di attività di un ospedale ? Perché fin ora erano di carta ? E
se si perché diavolo dovrebbero inserire in un DB e non digitalizzare
semplicemente i documenti per paziente ?


Un progetto di questa mole non l'ho mai fatto quindi non so. Ma mi 
chiedo, se poi uno volesse  fare magari delle statistiche cliniche, come 
si fa a farle solamente su base di documenti scannati e non su valori, 
come ad esempio una glicemia media che varia nel tempo, o dei parametri 
ematologici...

 chiedo, se poi uno volesse  fare magari delle statistiche cliniche, come
e quindi di cosa stiamo parlando ? Se i tuoi sono esempi tanto per
parlare allora ve bene tutto ed il contrario di tutto.

 ematologici...
una domanda: l'analisi dei requisiti e' gia' stata fatta?


E' semplice. E' riportata sui documenti ufficiali ministeriali pubblicati.
Comunque una analisi ad-hoc ha senso solo quando si sa lo status reale 
attuale. Cio� quando vedo che cosa � stato fatto e in quale reparto.
E sto ancora prendendo contatti con i responsabili.
E' una mia iniziativa personale che sto seguendo, per poi proporla al 
nuovo capo. Ho incontrato un certo interesse, altrimenti non mi sarei mosso.

 mosso.
Se il progetto ha una certa mole (la interpreto come complessit�) 
solitamente l'analisi dei requisiti non e' proprio banale almeno per la 
  mia esperienza personale.
E comunque da quel che posso capire tu stai introducendo nuovi 
requisiti/features (vedi la statistica ad esempio) nel sistema di 
riferimento descritto dai documenti ufficiali il che implica che non 
puoi basare la valutazione dell'effort solo su quei documenti,ma serve 
un ulteriore approfondimento.

 un ulteriore approfondimento.
Dunque, in un sistema clinico non si puo' assolutamente pensare ad un 
database che non sia usato non solo per ragioni di anamnesi, ma anche di 
statistica clinica. E' una funzione 'naturale' di un database clinico.
Almeno, io la vedo cos�.  Per cui, il memorizzare delle cartelle 
cliniche sotto forma di 'scanned documents' ha senso solo per ragioni 
storiche (pazienti gi� deceduti da 20 anni). Insomma come 'archivi 
storici' ottici, magari da tenere con una bassa risoluzione (50-70 dpi). 
Quelli che quarantanni fa si tenevano come 'microfilm'.
Lo standard HL7 penso sia rivolto al futuro e voglio sperare che chi 
l'ha ideato abbia pensato anche ad usarlo nella ricerca clinica.
Infatti, nella mia tesi al Carlo Mondino di Pavia, l'ho usato per 
monitorizzare la compliance alle linee guida durante un ictus.
Quindi correlare lo stato del paziente ai farmaci che gli sono 
somministrati (e soprattutto alla tempistica delle somministrazioni).
Quindi quella del database � una concezione alquanto complessa.

 Quindi quella del database � una concezione alquanto complessa.
Ma quello di correlare e' un requisito che tu decidi  che il sistema 
debba avere. Poi come lo implementi una volta deciso che ci deve essere 
e'  relativo. Io inizierei a stabilire formalmente cosa vuoi che il 
sistema faccia perche' da quel poco che ho potuto capire  non e' ancora 
chiaro. Tu invece (magari mi sbaglio perche' ho capito male io ) parti 
dall'implementazione;  ma  se l'implementazione poi non supporta quello 
che serve a chi usera' il sistema o e' insufficiente dovrai per forza 
reingegnerizzare la soluzione per soddisfare le necessita' in cui e' 
lacunosa con ulteriore effort (ergo costi).


Ho capito. Tu non tu riferisci al database in se stesso, ma al 'sistema' 
in generale. Cio� al 'software' che io intendo sviluppare.
Ebbene, questo � uno di quei casi in fase embrionale in cui di idee se 
ne hanno molte, e se si lavorasse gratis ed in eterno, TUTTI direbbero 
'S� s�, che figo, lo vogliamo'.
Per� bisogner� fare dei compromessi e adattarsi alle esigenze della 
realt� e ai suoi limiti (leggi soldi e tempo a diposizione).
Per ora mi basta analizzare la 'IS' situation e vedere cosa � gi� stato 
fatto. E cosa � stato fatto bene e cosa male. Confrontandolo con la 
situazione 'SHOULD BE' secondo i requirements (leggi governative).
Poi vedr� cosa ne viene fuori. Intanto me la prendo calma perch� per i 
prossimi due mesi, la met� delle persone con cui dovrei parlare, a turno 
� in vacanza.
E non dimentichiamo che lo faccio solo per UN istituto, una unit� 
operativa clinica. Non � che voglio 'salvare l'universo'... :-))))

 operativa clinica. Non � che voglio 'salvare l'universo'... :-))))
Bhe se si riesce a produrre un sistema funzionale che indirizza i 
problemi di chi opera nel campo in maniera soddisfacente  puo' anche 
essere preso in considerazione anche da altre strutture simili non trovi?


<hehehe> Vedo che hai esperienza di vita, tu ... :-))))

 <hehehe> Vedo che hai esperienza di vita, tu ... :-))))
Spero sempre che il mondo possa migliorare: mai dire mai :)

 Che ne è del rate?
Sarebbe? Non stilo contratti, quindi non sono esperto. So solo che
nella p.a. che conosco si fa il contratto per 4  anni, poniamo, ed il
prezzo del p.f. per una manutenzione evolutiva è fissato all'inizio, e
resta fisso per 4 anni. A quel punto si può solo "giocare" sul numero
dei p.f., tenuto poi conto che il cliente  chiede sempre pure lo
sconto...

 ematologici...
Le stime del software (es. p.f.) sono tutt'altra cosa dalla stima dei
tempi e costi per il lavoro manuale di digitazione dei dati. Comunque
anche il software ausiliario per la sola digitazione può essere assai
complesso, anche limitato alla durata della digitazione.
Andrebbe chiarito se vuoi/devi fare un software di analisi dei dati
nelle 100 tabelle, oppure un software di acquisizione controllata dei
10 anni di pezzi di carta, oppure un software di scannerizzazione ed
indicizzazione dei cartacei, magari con OCR, oppure una qualunque
combinazione di questi 3. Tutto sommato un progetto serio dovrebbe
prevedere tutte e tre le cose, a mio parere.