 | |
Il progetto dsy.it è l'unofficial support site dei corsi di laurea del Dipartimento di Scienze dell'Informazione e del Dipartimento di Informatica e Comunicazione della Statale di Milano. E' un servizio degli studenti per gli studenti, curato in modo no-profit da un gruppo di essi. I nostri servizi comprendono aree di discussione per ogni Corso di Laurea, un'area download per lo scambio file, una raccolta di link e un motore di ricerca, il supporto agli studenti lavoratori, il forum hosting per Professori e studenti, i blog, e molto altro...
In questa sezione è indicizzato in textonly il contenuto del nostro forum |
Modelli di sviluppo & aziende
Clicca QUI per vedere il messaggio nel forum |
| LazerPhEa |
Salve a tutti,
dopo aver seguito l'interessante (a mio avviso) corso di ingegneria del software, e dopo aver subito il fascino di modelli di sviluppo quali eXtreme Programming e UP, mi è sorta spontanea una domanda: ma tali modelli vengono effettivamente adottati dalle aziende (chiaro, non dico nelle azienducole a conduzione familiare... :asd: ) o il tutto viene sacrificato sull'altare del time-to-market?
:ciao: |
| perry00 |
Per quel che riguarda la mia esperienza ho riscontrato situazioni diversificate sia in Italia che all'estero. Ho lavorato con system integrator francesi che mi hanno colpito per la loro professionalità nel modo d'approcciare lo sviluppo. Allo stesso tempo ho lavorato con system integrator inglesi che mi erano parsi molto meno focalizzati sulla questione che poni. Ma sono solo esempi di esperienza vissuta e non si può certo generalizzare.
Tendenzialmente ritengo che le società di consulenza informatica (system integrator o software house) con organizzazione industriale adottano un qualche modello di sviluppo.
Non so quanto invece i modelli più recenti come l'XP siano effettivamente diffusi.
I detrattori dell'XP potrebbero anche sostenere che l'XP è il modo di lavorare delle azienducole a conduzione familiare :banana: ma non mi voglio addentrare in giudizi sulla bontà dei vari modelli.
In caso di sviluppi software ad-hoc è importante che la società che realizza il software abbia sufficiente autorevolezza presso il committente per fargli capire che nel bilanciamento fra time-to-market e qualità, trascurare la seconda può comportare molti rischi.
Sono stato sufficientemente vago? :blabla:
Se vuoi approfondire la cosa, chiedi pure.
Ciao,
Alberto. |
| LazerPhEa |
Originally posted by perry00
Sono stato sufficientemente vago? :blabla:
Se vuoi approfondire la cosa, chiedi pure.
Ciao,
Alberto.
No, anzi! Immaginavo che la cosa dipendesse molto da sw house a sw house...
Però ora vorrei che ti sbilanciassi un pò e mi dicessi fuori dai denti qual' è stato il modello più efficace, almeno per quano riguarda la tua esperienza, magari rapportandolo alla dimensione del progetto... :D
grazie 1000! :)
:ciaoo: |
| 0m4r |
Originally posted by perry00
[...](system integrator o software house)[...]
quale è la differenza? |
| Rocco.Li |
Modelli ??????
Io ho un modello che in tutte le aziende e' risultato il piu' efficace !!!
-----
"FUNZIONA ? OK, andiamo in produzione...."
Come e' fatto ? Chissenefrega...
-----
Questo perche' il 90% dei responsabili IT, non sono informatici !!!
E spesso il "time to market" e' l'unico parametro veramente importante, anche perche i commerciali promettono e vendono anche cose che non hanno, e tu devi correre per soddisfare i clienti, a qualunque costo.
Ergo, vogliono un ROI altissimo, a fronte di investimenti bassissimi.
Economia, sono i soldi che fanno girare il mondo ! :D |
| perry00 |
Originally posted by 0m4r
quale è la differenza?
System integrator era inteso come azienda che non solo produce pacchetti sw, ma offre anche servizi custom di integrazione fra sistemi. Di fatto molte aziende medio-grandi fanno tutto.
Ciao,
Alberto. |
| perry00 |
Originally posted by LazerPhEa
(...) qual' è stato il modello più efficace, almeno per quano riguarda la tua esperienza, magari rapportandolo alla dimensione del progetto...(...)
Nella mia esperienza non ho trovato un modello efficace in tutte le situazioni. Settori applicativi diversi richiedono approcci non sempre uguali.
Nei lavori in ambito business intelligence ho trovato produttivo un approccio iterativo/prototipale, con un confronto contiuno con l'utenza. Questo perché le esigenze sono talmente mutevoli nel tempo che non si possono cristallizzare fino al rilascio dell'applicativo. Ho trovato efficace basarsi su una tecnologia abilitante di business intelligence con un buon ambiente di sviluppo che lascia la flessibilità di realizzare cose non previste dallo standard.
In progetti più "gestionali" è dura. Conviene a mio avviso scegliere il metodo più adatto in funzione dell'utenza, della complessità, del grado di qualità richiesto e dei rischi.
Un esempio: Se si deve realizzare un applicativo per uno stabilimento che gestisce la fornitura di farmaci per studi clinici, è necessario che il progetto segua un sistema di qualità, ovvero sia validato, perché il livello di rischio in caso di difetti del software è elevato.
Attualmente lavoro in una ditta farmaceutica e per policy aziendale il software in uso presso gli stabilimenti produttivi ed ai fini degli studi clinici deve essere realizzato secondo questi canoni. Ci sono periodicamente audit interni per verificare che tutto sia stato fatto a regola d'arte.
In questa situazione ogni fase della realizzazione dev'essere documentata secondo le regole dettate dal sistema di qualità. Il modello di sviluppo in questi casi è tipicamente a cascata - requisiti utente che generano specifiche funzionali, che a loro volta generano specifiche tecniche; piani di collaudo e collaudi documentati, ecc. Non ti nascondo che in questi casi è dura incastrare l'utente a queste regole, costringendolo a pensare e comunicare bene le sue esigenze fin dall'inizio. E' un'arte che va imparata :D Anzi, mi trovo spesso fra incudine e martello - da una parte l'utente che mostra dell'insofferenza verso l'approccio e dall'altra la software house che a volte è fin troppo rigida. :wall:
Altro esempio: l'approccio dell'utente (estremizzo) "voglio tutto e subito ma non ho tempo per dirti cosa voglio". In ambiti dove non c'è un vincolo stringente di qualità, come ad esempio molto software che viene usato nelle direzioni commerciali è meglio utilizzare un approccio misto fra il prototipale e tradizionale a cascata.
Ciao,
Alberto. |
| perry00 |
Originally posted by Rocco.Li
Modelli ??????
Io ho un modello che in tutte le aziende e' risultato il piu' efficace !!!
-----
"FUNZIONA ? OK, andiamo in produzione...."
Come e' fatto ? Chissenefrega...
-----
Questo perche' il 90% dei responsabili IT, non sono informatici !!!
E spesso il "time to market" e' l'unico parametro veramente importante, anche perche i commerciali promettono e vendono anche cose che non hanno, e tu devi correre per soddisfare i clienti, a qualunque costo.
Ergo, vogliono un ROI altissimo, a fronte di investimenti bassissimi.
Economia, sono i soldi che fanno girare il mondo ! :D
Mi sa che sono uno del 10% di responsabili IT informatici :D
E in questa posizione la vita non è facile se si vogliono fare le cose a regola d'arte. In questa situazione bisogna guadagnarsi l'autorevolezza presso i propri utenti (clienti interni) per potere fronteggiare le iniziative commerciali da parte di operatori nel settore informatico che vendono fumo.
Il fatto che molte posizioni nei reparti IT o nelle software houses non siano ricoperte da informatici "veri" è effettivamente un problema. Naturalmente non si può generalizzare, c'è gente che non ha fatto studi informatici ma che sul lavoro ha acquisito notevole esperienza e ci sa fare, ma la tendenza è un pò quella che dici tu.
Come ALSI ci stiamo battendo per il riconoscimento e la valorizzazione della figura professionale dell'informatico (nel nostro caso laureato, essendo noi un'associazione di laureati).
Ciao,
Alberto. |
| perry00 |
Originally posted by perry00
(...) Naturalmente non si può generalizzare, c'è gente che non ha fatto studi informatici ma che sul lavoro ha acquisito notevole esperienza e ci sa fare, ma la tendenza è un pò quella che dici tu.
Una battuta: mi è venuto in mente il caso di una ex collega, laureata in filosofia che era una "maga del dataease". Per chi non lo conosce, dataease è un DB con ambiente di sviluppo per la realizzazione di applicazioni gestionali. Tanti anni fa era diffuso in ambiente DOS.
Tutti ci divertivamo a prendere in giro questa persona perché...dataease (nella release di allora) era un prodotto talmente contorto ed anti-informatico che solo una filosofa lo poteva capire... :? |
| LazerPhEa |
Originally posted by perry00
Nella mia esperienza non ho trovato un modello efficace in tutte le situazioni. (cut)
Grazie 1000! E' davvero una bella idea quella di questo forum...per lo meno ci permette di avere una finestra sulla realtà che (speriamo) tra poco sarà anche la nostra... :D |
| elio.gagliardi |
Ciao raga,
vi do anche la mia versione.
In quanto consulente esterno, e quindi vendor-independent, mi trovo a che fare con i problemi del time-to-market posti dal Cliente (con la "C" maiuscola, xé è sempre degno di rispetto - ci paga!) e della qualità del lavoro.
Quale modello?
Ha ragione sia chi dice che nella realtà non ci sono modelli prestabiliti, sia chi afferma che in determinati casi devi conoscerli ed applicarli nel giusto contesto.
La mia esperienza dice che la strada non è mai dritta (e perfetta come vorrebbe la teoria); ma non si può fare a meno di un punto di riferimento (il Modello, appunto) che ti guida.
Un esempio: la documentazione! Possibile che ci si accorga solo a fine progetto che bisogna correre a fare la manualistica? E lo si fa di corsa, male e solo il minimo indispensabile per essere a posto con il contratto?
Eppure, in qualsiasi Modello tu scelga, la documentazione è prevista fin dall'inizio (come dico sempre io, la manualistica è - dovrebbe essere - semplicemente la documentazione delle specifiche scritta in bella; pensaci, è così).
Come ALSI stiamo proprio cercando di far capire che non esiste una differenza preconcetta sulle competenze, anzi spesso le impariamo sul campo.
Quel che è diverso è la capacità di comprendere e di affrontare le situazioni e le possibilità di crescere velocemente.
A questo servono tutti quegli schifosi esami che stai dando. E' una palestra per la mente. Il resto è "nozionismo".
A disposizione,
Elio |
| Lunik |
Originally posted by perry00
dataease (nella release di allora) era un prodotto
è ancora usato questo dataease? |
| perry00 |
Originally posted by Lunik
è ancora usato questo dataease?
Ah saperlo! :)
Io non l'ho più incrociato da 8 anni a questa parte. Ho visto che c'e' un sito www.dataease.com ma non so se è lo stesso prodotto perché 8 anni fa era un prodotto DOS e ciò che viene proposto sul sito è un prodotto ovviamente Windowz. Ai tempi non mi piaceva per nulla.
Fai questa domanda perché più in generale vorresti sapere che DB ti conviene imparare?
Ciao,
Alberto. |
| Lunik |
eh...ehm...beh si....
però io sono una di quelle persone che vogliono imparare qualcosa senza troppo sbattimento...
lo so, lo so e lo so, pretendo troppo....... ma se una cosa non la capisco subito..lascio tutto :( |
| perry00 |
Originally posted by Lunik
eh...ehm...beh si....
però io sono una di quelle persone che vogliono imparare qualcosa senza troppo sbattimento...
lo so, lo so e lo so, pretendo troppo....... ma se una cosa non la capisco subito..lascio tutto :(
Breve elenco dei principali motori DB di fascia alta in commercio:
Oracle (www.oracle.com)
Microsoft SQL Server (www.billgatezeamici.com)
IBM DB2 (www.ibm.com)
Sybase (www.sybase.com)
mySQL (www.mysql.com)
e sul fronte DB "personali" (per applicativi monoutente o con "pochi" utenti concorrenti):
Microsoft Access (www.semperlù.com)
Paradox (www.corel.com)
Ciao,
Alberto |
| Lord_Tom |
Leggo solo ora questo thread.
Dalla mia breve esperienza posso dire che solitamente le società NON adottano processi.
E qualsiasi processo è meglio di non aver processi.
Ho studiato il "waterfall" con una nota di superiorità, pensando a un modello farraginoso e antico.
In realtà l'applicazione del "waterfall" fatta bene sarebbe già un ottimo modo di lavorare.
Poi, oddio, è odioso comunicare per documenti, e anche tanto noioso.
Però è meglio di non comunicare.
Lavoro in un team di eXtreme Programming che è uno dei pochi in italia.
Credo che più che il nome della metodologia applicata per sviluppare software siano importanti 2 cose:
1) definire i valori su cui si basa il proprio lavoro: i soldi? la produttività? la qualità? il divertimento? la paura? etc...
2) trovare un modo di applicarli nella realtà, con delle pratiche. Lavoro in un ambiente ostile che controlla ciò che faccio? -> ogni lavoro svolto viene documentato con una mail -> sempre scritto, niente orale per pararsi il sedere. etc etc...
Vi invito a proseguire il discorso su c2.com , un wiki frequentato da moltissimi informatici e ingegneri del software americani (e non) molto in gamba!
Saluti,
Tommaso |
|
|
|
|
