> Objeccions? De detall, algunes. Per exemple, que GIMP no �s comparable a > Photoshop a poc que t'hi fiquis en un ambient professional; altra cosa [...] > complexitat d'una base de dades per no saber sortir-s'hi amb un full de > c�lcul ben utilitzat. �s clar que molta gent tampoc sap utilitzar b� un > full de c�lcul...
Una q�esti�, que potser al document no queda ben clara �s que
en molts dels casos que s'analitza un dels productes, l'an�lisi
est� orientat a la UdL, �s a dir, quan es parla de CAD es parla
del CAD que utilitzem aqu�, no del CAD que pugui emprar un
arquitecte "de veritat", per� la part de CAD, imatge,
s�, m�sica, etc. no son per la part "Administraci�" de la UdL
sin� que son m�s per la part "Docent/Recerca".
Respecte a les BBDD. La veritat �s que les solucions son les que
hi ha. La idea que tenim �s, aprofitant l'avinentesa de la
migraci�, ELIMINAR aquelles BBDD que puguem.
M'explico:
Hi ha tot un seguit de BBDD petites (MS-Access majoritariament)
que viuen a la UdL. Aquestes BBDD s'han creat en moltes unitats
administratives nostres per sortir del pas en alguna necessitat
que pogu�ssin tenir puntualment. Despr�s de solucionar la
necessitat puntual, la BBDD en q�esti� s'ha "institucionalitzat"
i ha esdevingut una BBDD de treball diari. Doncs b�, aquestes
BBDD tenen alguns problemes, siguin o no basades en PL, siguin
o no MS-Access, operin sobre Linux o sobre Windowz o sobre el
que sigui:
1- Seguretat: NO hi ha control sobre l'operaci� de la BBDD. Ni
qui hi accedeix, etc.
2- Seguretat: Algunes d'aquestes BBDD no entren a c�pia de
seguretat, resideixen nom�s a un PC, etc.
3- LOPD: Algunes d'aquestes BBDD contenen dades de car�cter
personal i no estan registrades a l'APD (Ag. Protecci� de
Dades), b�sicament, pq el servei d'inform�tica (ASIC a la
UdL, pels que vulgueu llegir la guia de migraci�) no sap
ni que existeixen.
4- Altres: Manteniment, desenvolupaments que s'hi puguin fer,
integraci� amb altres BBDD, integraci� al campus virtual i
a la intranet, etc.
Doncs b�, donat que no hi ha una alternativa a Access v�lida
a Linux, i donats els problemes esmentats, l'opci� m�s v�lida
i coherent �s, posats a fer canvis, canviem la BBDD Access per
alguna BBDD Integrada (integrada al Backoffice, etc.), controlada per
ASIC, registrada a l'APD, etc.
Evidentment, migrar un Access d'alguna unitat estructural nostra
a una BBDD Integrada, no �s trivial, fer-ho amb 20 BBDD o m�s
�s un veritable merder. Per� fer-ho �s important, per diversos
motius i fer-ho b� encara ho �s molt m�s. El m�s interessant
�s que en fer-ho, establirem i farem una "guia"/kit/etc. de com
fer-ho.
Per cert, aix� de tenir Access "sueltos" per la xarxa no �s
exclusiu de la UdL, totes les administracions, si tenen una
mica de "m� lliure", n'acaben tenint...... per desgr�cia
dels inform�tics :-(
> Objeccions importants? Una: no veig un estudi acurat de les implicacions
> de la migraci� en els fluxos de treball i de rendiment i aix� �s molt
> important. Per� aix�, que �s important a la UdL, �s capital a
> l'Administraci� p�blica (para la orella, Oriol, si est�s llegint aix�)
> perqu�, en termes administratius, "rendiment" volt dir "servei al
> ciutad�". I aqu� est� una de les meves impugnacions al fet de qu�
> s'utilitzi una universitat com a camp de proves de l'Administraci�
> p�blica; i m'estranya que s'hagi fet aix�, perqu� aquesta mateixa
> observaci� li vaig fer a l'Oriol Ferran en un dinar que vam fer fa tres
> mesos amb un company d'Hispalinux i un d'altre de Softcatal�, i va estar
> d'acord amb ella. Aquell dia jo vaig suggerir que millor -molt millor-
> que una universitat seria una unitat administrativa que, per les seves
> caracter�stiques, tingu�s una mica de totes: atenci� i serveis directes
> al ciutad�, assessorament o estudis per a altres �rgans i/o suport
> administratiu a tasques t�cniques; d'aquesta manera es podrien veure els
> possibles 'forats' �mbit per �mbit i, aix�, establir POL�TIQUES.
> Exemple de pol�tica: si el forat sorgeix en els serveis de caire intern,
> la migraci� tira endavant perqu� els 'clients' interns tenen m�s
> capacitat de patiment i de compensaci� de danys que els ciutadans, que
> s�n m�s perentoris en l'exig�ncia de les prestacions que acrediten. Si
> �s a l'inrev�s, la migraci� s'atura fins que no es tapi el forat de
> d�ficit de servei a l'exterior. O b� la pol�tica contr�ria (ehem!) all�
> cadasc�.
Uf! Llarg i complexe el par�graf.... anem per parts (atenci�
aqu� hi ha opinions personals meves...).
La UdL �s una universitat, cert (nom�s faltaria), i l'Oriol
va estar d'acord amb t�, cert.
La UdL tamb� �s una administraci� p�blica, tenim una part de
la nostra estructura que �s una administraci�, normal i
corrent. Per� l'acord que estem adoptant amb DURSI (el
Departament d'Universitats, Recerca i Societat de la
Informaci�), no �s NOM�S per que la UdL faci la migraci�,
l'acord contempla (contemplar�):
1- La migraci� dels escriptoris de la pr�pia UdL. D'aquesta
migraci� n'han de resultar diversos productes addicionals:
a. Una guia de migraci� d'escriptoris, amb tots els
problemes detectats durant la migraci�, amb totes
les solucions trobades. Amb consells, receptes, etc.
de com fer determinades coses.
b. Tots els "by-products" resultants, ja siguin
pegats a programes, traduccions, etc.
c. Documentaci� i material de formaci�, encara que
el Jes�s Corrius amb el material de la UOC ja ha
fet una magn�fica feina.
2- El suport des de la UdL de la migraci� d'un parell d'unitats
de la Generalitat (la STSI i un altra) i d'un parell d'entitats
locals.
>
> Tant de bo l'experi�ncia sigui ben profitosa per a la Universitat de
> Lleida i val esperar en el seu moment una bona mem�ria sobre aquesta
> migraci�. Per� jo continu� dient que una universitat (la clientela de la
> qual, per m�s que diversa, �s sempre en sentit end�gen, ben al contrari
> que a moltes unitats administratives) no �s el banc de proves adient per
> a l'Administraci�.
>
> B�, lamento la brasa, per� ho havia de dir tot.
--
__________________________________________________________
Universitat de Lleida
Area de Sistemes d'Informacio i Comunicacions
Carles Mateu i Pi�ol Tel: +34 973 702049
Director FAX: +34 973 702130
www: http://www.udl.es/usuaris/carlesm/
GnuPG key: CD989EA1 ( http://www.keyserver.net/ )
Fingerprint = B1B7 65F7 38E4 C34E 5865 135F DEA6 CF2A CD98 9EA1
_________________________________________________________
signature.asc
Description: This is a digitally signed message part
