Universitat Oberta de Catalunya Plec de condicions ... · pujada i baixada de fitxers i el servei a...

Plec de condicions tècniques

15/09/2009 pàgina 1 de 50

Universitat Oberta de Catalunya

Plec de condicions tècniques pel desenvolupament d'una reenginyeria tècnica del component TRENACC i d’un proxy

autenticat per a la FUOC


15/09/2009 pàgina 2 de 50

Índex de contingut1.Antecedents. ......................................................................................... 6

1.1.Situació actual. ................................................................................ 6

1.2.Problemes de TRENACC. ...................................................................... 6

2.Objectius. ............................................................................................ 6

3.Breu descripció de TRENACC. ..................................................................... 7

3.1.TREN i TRENACC. .............................................................................. 7

3.2.Sessions internes i sessions Campus. ....................................................... 7

3.3.Tipus d'accés i autoritzacions................................................................ 7

3.4.Descripció del mòdul TRENACC.............................................................. 8

3.5.Serveis de TRENACC. .........................................................................10

3.5.1.Serveis a TREN.DLL. ....................................................................10

3.5.1.1.Comprovació d'accés (check_access)...........................................12

3.5.1.2.Servei de connexió (“novasessio”). ............................................12

3.5.1.3.Servei de desconnexió (“desconnecta”). ......................................13

3.5.1.4.Servei de consulta d'usuari (“isuser”)..........................................13

3.5.1.5.Servei de consulta d'accés a un mòdul (“access”) ...........................13

3.5.1.6.Servei de consulta de tots els accessos a un mòdul (“allaccess”).........14

3.5.1.7.Servei de pont ODBC (“odbc”) ..................................................15

3.5.1.8.Servei d'enviament de correus a la cua (“mail” i “mail2”).................16

3.5.2.Proxy autenticat.........................................................................16

3.5.3.Forma de les URL's. .....................................................................17

3.5.4.Lògica de la funcionalitat de proxy. .................................................18

3.5.5.Mostrar error (“show_error”) .........................................................19

4.Requeriments. ......................................................................................19

4.1.Reengenyeria de TRENACC. .................................................................19

4.2.Visió general...................................................................................20

4.3.Components a considerar. ...................................................................20

4.3.1.TRENACC2 com a servei a TREN.DLL. ................................................21


15/09/2009 pàgina 3 de 50

4.3.2.TRENACC2 com a PROXY. ..............................................................21

4.3.3.WS TRENACC2............................................................................22

4.4.Esquema de BD................................................................................22

4.4.1.Aplicacions, mòduls i permisos. ......................................................23

4.4.2.Sessions i usuaris. .......................................................................23

4.5.Eines disponibles per la reengenyeria.....................................................24

4.5.1.Documentació disponible. .............................................................24

4.5.2.Codi font original. ......................................................................24

4.5.3.Esquema de la base de datos. ........................................................24

4.5.4.Prova de concepte. .....................................................................25

4.6.Entorn de desenvolupament. ...............................................................25

4.7.Redundància, tolerància a fallides, etc...................................................25

4.8.Vigilància, monitorització i estat. .........................................................25

5.Documentació de l'oferta. ........................................................................27

6.Formació.............................................................................................27

7.Metodologia de gestió del projecte. ............................................................27

8.Metodologia de desenvolupament i qualitat. ..................................................28

9.Seguretat en el desenvolupament. ..............................................................28

10.Lliurables...........................................................................................28

11.Aspectes econòmics. .............................................................................28

11.1.Condicions de pagament ...................................................................28

12.Detalls formals de l’oferta ......................................................................28

12.1.Contingut. ....................................................................................28

12.2.Període de garantia. ........................................................................30

12.3.Traspàs a l’equip de manteniment. ......................................................30

12.4.Propietat intel·lectual, seguretat, confidencialitat, i protecció de dades ........31

12.5.Formalització Contracte ...................................................................31

12.6.Criteris d’adjudicació ......................................................................31

12.7.Termini de presentació, adjudicació i execució........................................32


15/09/2009 pàgina 4 de 50

Annex A – Revisió del acompliment de les Pautes d’Accessibilitat del WAI – AA ...........33

Annex B – Revisió de l’usabilitat i bones pràctiques ............................................39

Annex C – Estàndards metodològics i de qualitat................................................41

Annex D - Clàusules Contractuals. .................................................................45

Annex E – Desenvolupament segur del software. ................................................47

1.Introducció: .........................................................................................47

2.Filosofia:.............................................................................................47

3.Activitats del cicle de vida de l’aplicació: .....................................................48

4.Àrees de seguretat .................................................................................49

5.Personal i organització. ...........................................................................50

6.Biblioteques, frameworks d'aplicació i productes.............................................50

7.Revisions de seguretat.............................................................................50

8.Gestió dels problemes de seguretat.............................................................51

9.Fiabilitat .............................................................................................51

10.Acceptació de la seguretat i garantia .........................................................52


15/09/2009 pàgina 5 de 50

1. Antecedents.

1.1. Situació actual. Actualment, la UOC fa un ús intensiu de l'aplicació TRENACC. Es tracta d'un component desenvolupat amb Pro*C que es executa com un “cartridge” d'Oracle, i que fa les funcions de proxy HTTP amb autenticació i autorització, a més de publicar una sèrie de serveis mitjançant HTTP de funcionalitats relacionades amb autenticació i autorització.

Aquesta peça s'utilitza per permetre que els usuaris puguin sol·licitar pàgines que es troben a zones protegides per un “firewall”, sempre que tinguin permís per accedir-hi. A més, aquesta peça proporciona una sèrie de funcionalitats que permeten als usuaris de la xarxa interna executar aplicacions client / servidor, gestionar la sessió i altres relacionats.

1.2. Problemes de TRENACC. Els problemes de la versió actual de TRENACC tenen a veure amb la tecnologia amb la que està desenvolupat. Aquests problemes podrien resumir-se en:

• TRENACC utilitza les llibreries WRB d'Oracle, de les quals no hi ha suport actualment. Tampoc no hi ha documentació.

• La tecnologia de cartridges va ser abandonada per Oracle a la versió 8, per tant no és possible migrar la versió de la base de dades o del servidor d'aplicacions. Aquests tampoc tenen suport d'Oracle.

• Aquestes llibreries només permeten l'ús del protocol HTTP 1.0, i per tant es produeixen problemes amb servidors d'aplicacions moderns que utilitzan “chunked” i protocol HTTP 1.1.

• Tenim errors coneguts a les llibreries WRB (per exemple, “Internal error”), que no es poden diagnosticar amb seguretat ni es poden solucionar donada l'absència de suport.

• Tenim molt poca tolerància a fallides del sistema, ja que aquesta peça està dissenyada per funcionar a una sola instància. La caiguda de TRENACC suposaria que els usuaris no podrien accedir a moltes de les funcionalitats de la zona de gestió.

• El manteniment i evolució es molt complex. Manca coneixement de l'aplicació i documentació.

2. Objectius. L'objectiu del projecte és implementar una peça amb tecnologia Java que substitueixi a TRENACC, de manera que puguem solucionar els problemes existents i al mateix cop seguim l'arquitectura UOC. Més concretament, aquests objectius serien:

• Solucionar els problemes de suport a HTTP 1.1, permetent una comunicació HTTP i SOA ràpida i segura.

• Disposa d'una peça que permeti un manteniment correctiu i evolutiu més simple,


15/09/2009 pàgina 6 de 50

amb una bona documentació i un desenvolupament menys monolític.

• Eliminar les dependències amb versions obsoletes i sense suport d'Oracle, de tal manera que puguem plantejar una migració de la versió de la base de dades.

• Augmentar la tolerància a fallides i els sistemes de monitorització.

• Fer que aquesta transició sigui transparent pel usuari final.

3. Breu descripció de TRENACC.

3.1. TREN i TRENACC. Quan es parla de TREN, en realitat s'està parlant d'un conjunt d'aplicacions que cooperen per garantir l'autorització dels usuaris, on TRENACC és un component més. L'objectiu d'aquesta última és per una part permetre que usuaris accedeixin des de l'”exterior” a funcionalitats que es troben protegides per un firewall a la zona de gestió. Per altra, s'encarrega de donar accés als usuaris de la xarxa interna de la UOC a aplicacions (tant web com client / servidor) que tenen disponibles, tot això gestionant l'autenticació i l'autorització.

3.2. Sessions internes i sessions Campus. TRENACC accepta dos tipus de sessió associada amb els usuaris:

• Sessions curtes (de la xarxa interna), que es generen pel mateix TRENACC només a un rang d'IPs determinat. Aquesta generació es fa amb una petició al servei “novasessio” que llença el TREN.DLL a petició del programa resident TREN.EXE, que pren l'usuari Windows per fer-ho.

• Sessions llargues, que venen generades pel LMS de la UOC, el Campus.

En tots dos casos, la sessió serveis per identificar l'usuari i determinar si té permís per accedir a determinada aplicació / mòdul, i d'aquesta manera fer les funcions de proxy.

3.3. Tipus d'accés i autoritzacions. Per determinar si un usuari té accés a determinada funcionalitat, TRENACC consulta els permisos del esquema de base de dades TREN. A aquest esquema, es poden consultar les funcionalitats (APLICACIO, MODUL, MANTENIMENT), les sessions (SESSIO) i els permisos associats amb els usuaris (ACCESSOS, LLISTES_ROL). En general, un par APLICACIO / MODUL tindrà una sèrie d'entrades a MANTENIMENT de diferents tipus (aplicacions client / servidor, accessos Web, contrasenyes de BD...) que s'utilitzaran en funció de la manera en que el usuari accedeix.

Un usuari podrà accedir a una determinada funcionalitat en els següents casos:

• si se l'ha donat accés nominal

• si l'usuari pertany a un rol o tipus que té permís


15/09/2009 pàgina 7 de 50

• si l'usuari accedeix per “backdoor” (veure més endevant)

Hi han determinades funcionalitats que es permeten únicament a un rang d'IPs intern, que es troba a les taules de BD corresponents. A més, existeixen controls de períodes temporals als quals una funcionalitat o un permís està actiu.

Quan s'accedeix mitjançant “backdoor” s'utilitza una sessió especial (sessió amb ID 69), que si es troba catalogada per la IP concreta que fa la crida, es traduirà per un usuari determinat. Un altra possibilitat és l'impersonalització. En determinades circumstancies, a determinats usuaris se'ls permet impersonar-se convertint-se a tots els efectes en un usuari diferent.

A les entrades de MANTENIMENT, es troben els diferents tipus d'aplicacions que el usuari pot llençar quan selecciona una aplicació / mòdul. Als efectes d'aquest component, només ens interessaran els següents tipus:

• ODBC: Conté les credencials d'accés a la base de dades quan s'invoca una connexió ODBC.

• URL: URL a invocar si es tracta d'un tipus de crida indirecta.

• WEBURL: URL a invocar si es tracta d'un tipus de crida directa.

3.4. Descripció del mòdul TRENACC. Dins el univers TREN (es a dir, totes les peces que fan possible l'accés a aplicacions amb autenticació i autorització), hi han diferents components que realitzen part de la feina. Vist d'una manera general, l'esquema seria com es pot veure a continuació:


15/09/2009 pàgina 8 de 50

Més en detall, veurem cadascú dels components:

• TRENACC, que és el cartridge Pro*C que agrupa les funcionalitats de proxy, pujada i baixada de fitxers i el servei a peticions de TREN.DLL. Funciona com un servei web que até les peticions pel port 444.

• TRENMAIL, daemon que s'encarregava d'enviar missatges de la cua de pentents. Actualment aquesta peça està obsoleta i s'ha substituït per CUA.

• TREN.EXE, aplicació Windows resident desenvolupada en Visual C++ que s'ocupa de prendre una sessió TREN a les màquines de gestió de la UOC. A més, permet l'encriptació de textos en format TREN. Aquesta aplicació s'arrenca amb Windows a les màquines internes, i pren una sessió curta al inici.

• TREN.DLL, llibreria dinàmica Windows desenvolupada en Visual C++ que permet l'accés als serveis de TRENACC (excepte proxy). Bàsicament s'ocupa de donar funcions als programes client que TREN.DLL tradueix a peticions HTTP envers TRENACC.

• F6 (també conegut com GOIG), aplicació en Visual C++ / MFC que proporciona accés al directori de persones i permet l'invocació de les aplicacions al catàleg de TREN a les que l'usuari té accés. Utilitza la TREN.DLL, TREN.EXE i per descontat TRENACC. Actualment s'està finalitzant el desenvolupament d'una nova aplicació en GWT que substitueix aquesta peça.

• Manteniment TREN, aplicació FORMS que permet el manteniment de les taules TREN (no es pot veure al esquema).


15/09/2009 pàgina 9 de 50

3.5. Serveis de TRENACC. Entre els serveis que proporciona TRENACC com a peticions Web podem distingir els que donen servei a TREN.DLL, els orientats a fer de proxy autenticat i altres que donen informació de l'execució. A la part de proxy, s'ha de tenir en compte aquells que serveixen peticions SOA.

Proxy autenticat.

URL Descripció

/trenacc Rep l'aplicació / mòdul bé a l'URL o bé com a paràmetre, i s'encarrega de redireccionar la petició a la URL indicada al MANTENIMENT.

/trenacc/web Ídem que l'anterior, però no s'exigeix que el usuari estigui autenticat.

/trenacc/forms Equival a una invocació tipus /trenacc com a proxy, fixant un tipus de crida indirecta.

/trenacc/show_error Mostra la pàgina d'error estàndard de TREN.

Servei a TREN.DLL.

URL Descripció

/trenacc/novasessio Crea una nova sessió interna a partir de l'usuari, sempre que la IP estigui dins del rang autotitzat.

/trenacc/desconnecta Desconnecta la sessió que s'indica (sessió interna).

/trenacc/allaccess Retorna els accessos de l'usuari a partir de la sessió.

/trenacc/access Retorna els accessos de l'usuari a un determinat mòdul a partir de la sessió.

/trenacc/odbc Retorna la cadena amb usuari i contrasenya. Dissenyat per fer-se servir a ODBCTREN.DLL per ocultar l'usuari i contrasenya d'accés a la BD.

/trenacc/isuser Retorna el mail de l'usuari de la sessió si l'usuari té una sessió vàlida.

/trenacc/mail /trenacc/mail2

Crea entrades a la cua de correu, per que s'enviïn pel gestor de la cua.

Altres / diagnòstic.

URL Descripció

/trenacc/GetContext Retorna informació de context de la sessió en format XML.

/trenacc/getcontext Retorna informació de context de la sessió en format text.

/trenacc/test Informació d'execució de TREN (diagnòstic).

3.5.1. Serveis a TREN.DLL. Els serveis a TREN.DLL estan dissenyats de tal manera que donin resposta a peticions transaccionals relacionades amb la sessió i els permisos. Pel general, el diàleg és una petició a una URL determinada amb els paràmetres per GET, a la que TRENACC respon amb un text de tipus TEXT/PLAIN que conté al BODY el codi d'error i a les capçaleres els resultats.

Per exemple, una petició a la funcionalitat de connexió seria:


15/09/2009 pàgina 10 de 50

GET /tren/trenacc/novasessio?usuari=pepito HTTP/1.1 HTTP/1.x 200 OK Content-Type: text/plain Date: Wed, 03 Jun 2009 10:04:51 GMT Allow: GET, HEAD Server: Oracle_Web_listener3.0.2.0.0/2.14FC1 Tren-Idp: 437382 Tren-Sessio: 101924113 Tren-Versio: 3.6 Connection: Keep-Alive Keep-Alive: timeout=0, max=999

Com es pot veure, TRENACC respon amb una sessió (Tren-Sessio) al HEADER, a més de donar altra informació com l'IDP i la versió de TREN. L'HTML que es retorta la petició es “0”.

Totes les funcionalitats de TREN.DLL es troben catalogades al registre de Windows a les màquines locals, de tal manera que la URL a la que es consulta es pren de l'entrada del registre (LOCAL MACHINE / SOFTWARE / UOC / TREN). Per una màquina tipus, aquestes entrades son:


15/09/2009 pàgina 11 de 50

3.5.1.1. Comprovació d'accés (check_access). A diferents punts es comprova l'accés de l'usuari (amb la sessió) al par aplicació / mòdul. Es descriu aquesta lògica per no repetir-la a cadascun dels punts on s'utilitza.

Es suposa que a l'entrada venen informats sessió, aplicació (si no ve, son totes) i el mòdul.

A aquesta comprovació es realitzen les següents tasques:

• determinar l'entorn CAMPUS i l'idioma de l'usuario

• es determina el usertype i usersubtype de l'usuari

• es comprova que l'usuari té permís d'accés segons el següent ordre de comprovació:

◦ accessos nominals per usuari

◦ accessos per rol-usuari

◦ accessos per usertype

◦ accessos per rol – usertype

◦ accessos per othertypes

◦ accessos per rol – othertypes

◦ accessos per rol universal

• es prenen les dades d'accés i es comprova que l'usuari està vigent

Es retornen els següents codis d'error:

• 0 : tot correcte

• -1 : fora de plaç, les dades d'accés no entren dins el periode

• -2 : el mòdul està inactiu

• -3 : sense accés

3.5.1.2. Servei de connexió (“novasessio”). Entrada:

• usuari (GET): indica el login de l'usuari pel que es demana una nova sessió.

Sortida:

• Als headers:

◦ Tren-Idp: IDP de l'usuari.

◦ Tren-Sessio: sessió assignada

◦ Tren-Versio: versió del motor de TRENACC.

• Al content:


15/09/2009 pàgina 12 de 50

◦ “0” : tot OK.

◦ “1” : usuari no trobat a Campus.

Lògica:

• A partir de l'usuari que es dona, es crea una nova entrada a la taula de sessions (SESSIO) per la IP donada, amb un identificador que es oren d'una sequence.

3.5.1.3. Servei de desconnexió (“desconnecta”). Entrada:

• Tren-Sessio (GET): indica la sessió a desconnectar.

Sortida:

• Al content:

◦ “0” : tot OK.

◦ “1” : sessió no trobada.

Lògica:

• Elimina la sessió de la taula corresponent pel identificador donat (i mateixa IP).

3.5.1.4. Servei de consulta d'usuari (“isuser”). Entrada:

• Tren-Sessio (GET): indica la sessió.

• Tren-Idp (GET): no s'utilitza.

Sortida:

• Als headers:

◦ Tren-EMail: mail de l'usuari.

• Al content:

◦ “0” : tot OK.

◦ “-22” : la sessió no existeix.

◦ “-25” : l'usuario no existeix.

Lògica:

• A partir de la sessió, consulta la taula corresponent (SESSIO) per la mateixa IP, si l'usuari existeix llavors consulta el mail de la taula de CAMPUS.

3.5.1.5. Servei de consulta d'accés a un mòdul (“access”) Entrada:

• Tren-Sessio: sessió de l'usuari.


15/09/2009 pàgina 13 de 50

• Tren-Modul: mòdul pel qual es vol comprovar l'accés.

Sortida:

• Als headers:

◦ Tren-Access: accés que té l'usuari al mòdul.

◦ Tren-UserType, Tren-UserSubType: tipus i subtipus de l'usuari.

◦ Tren-DataInici, Tren-DataFinal: dates d'inici i final (si existeixen) de l'accés al mòdul, en format dd/mm/yyyy hh:mi:ss.

• Al content:

◦ “0”: tot correcte.

◦ “-3”: sense accés

◦ “-4”: usuari invàlid.

◦ “-22”: sessió invàlida.

Lògica:

• Si l'usuari té accés, comprova les dades d'accés de l'usuari a aquest mòdul, si el té (l'accés es un valor dins de la taula de permisos). En cas de que no tingui tornarà amb un codi d'error al content. Utilitza check_access.

3.5.1.6. Servei de consulta de tots els accessos a un mòdul (“allaccess”) Entrada:


• Tren-App (opcional): si no s'informa, es consulten totes les aplicacions.

• Tren-Mant (opcional): tipus de manteniment a consultar, o bé el valor “ALL” per consultar-los tots.

Sortida:

• Al content:

◦ “-22”: sessió incorrecta.

◦ “0” si es correcte, seguit de tots els accessos en la forma:

▪ Tren-Aplicacio-[num]: [APP]

▪ Tren-Modul-[num]: [MODUL]

▪ Tren-Modul-Descripcio-[num]: [DESCRIPCIÓ MÒDUL]

▪ Tren-Access-[num]: [ACCÉS]

On [num] és un nombre consecutiu de 0 en endavant, i hi ha una línia (terminada en \n) per cada accés detectat.

Lògica:


15/09/2009 pàgina 14 de 50

• Si la sessió és correcta, consulta totes les possibilitats d'entrada, considerant o no l'aplicació (si es informa) i el tipus de manteniment (si no és “ALL”).

• Retorna per cada aplicació, amb els filtres donats, l'accés segons l'ordre de comprovació següent:

◦ accessos nominals per usuari

◦ accessos per rol-usuario

◦ accessos per usertype

◦ accessos per rol – usertype

◦ accessos per othertypes

◦ accessos per rol – othertypes

◦ accessos per rol universal

3.5.1.7. Servei de pont ODBC (“odbc”) Entrada:


• Tren-Modul: aplicació i mòdul al que es vol accedir.

• Tren-Manteniment: manteniment (ha de contenir el valor “ODBC”)

Sortida:

• Als headers:

◦ Tren-Modul: aplicació i mòdul al que es vol accedir.

◦ Tren-Password: contrasenya d'accés.

• Al content:

◦ “0”: correcte.

◦ [Codis de check_access]

◦ “-22”: sessió invàlida.

◦ “-24”: entrada ODBC no trobada.

Lògica:

• Si l'usuari té accés (al mòdul, aplicació), es busca l'entrada a la taula MANTENIMENT corresponent a l'entrada ODBC, i es retorna la contrasenya al header. Utilitza check_access.

� ATENCIÓ!: aquesta funcionalitat utilitza el package TREN_ENGINE, funcionalitat “substitueix_comanda” per extreue el password.


15/09/2009 pàgina 15 de 50

3.5.1.8. Servei d'enviament de correus a la cua (“mail” i “mail2”). Entrada:


• Tren-From: IDP del remitent.

• Tren-To (opcional): si s'informa, IDP del destinatari (si no s'informa Tren-ToMail).

• Tren-ToMail (opcional): correu extern del destinatari (si no s'informa Tren-To).

• Tren-Subject: subject del missatge.

• Tren-Body (opcional, només en “mail”): si s'informa, body del missatge.

• Al cos del missatge HTTP s'envia el body en format Multipart (cas “mail” si no s'informa “Tren-Body”).

Sortida:

• Al content:

◦ “-4”: l'usuari no existeis, no es pot accedir o la sessió és invàlida (cas “mail”).

◦ “-22”: sessió incorrecta (només “mail2”).

◦ “0”: correcte

Lògica:

• En el cas de “mail”, es comprova que el usuari esta a la xarxa interna (taula IP_INTERNA), si es així es pren la IP de la sessió (bé CAMPUSSESSION o bé SESSIO).

• Es comprova que l'usuari té una sessió vàlida (sessió interna, CAMPUS o backdoor). En el cas de CAMPUS la IP de l'usuari ha de coincidir amb la de la petició (s'ha de fer des de la mateixa màquina).

• Es genera un registre a les taules MAIL (MAIL_FROM, MAIL_TO, MAIL_ATTACHMENT) amb les dades corresponents.

3.5.2. Proxy autenticat. Com ja hem vist, TRENACC permet l'accés a zones protegides per un firewall a usuaris que venen de l'exterior, sempre que l'usuari tingui permisos per accedir. Això és possible donat que TRENACC fa de proxy a les pàgines que es troben darrera del firewall, i fent reescriptura de la URL.

Per fer-ho, el punt d'entrada (es a dir, la pàgina que es serveix a l'usuari) ha d'estar catalogada a les taules de TREN amb la seva aplicació, mòdul i manteniment. D'aquesta manera, si per exemple volem accedir a una pàgina que no es visible des de Internet, crearem un manteniment tipus URL dins d'una aplicació i mòdul, i farem la petició a TREN per que ens serveixi aquesta pàgina d'una forma similar a:

http[s]://cv.uoc.edu/tren/trenacc/APP.MOD/SUBMOD?s=SESSIO

o bé


15/09/2009 pàgina 16 de 50

http[s]://cv.uoc.edu/tren/trenacc?s=SESSIO&modul=APP.MOD/SUBMOD

On SESSIO es el ID de la sessió (bé CAMPUS o una sessió de la xarxa interna de gestió), APP es l'aplicació, MOD el mòdul i SUBMOD és el submòdul (si aquest último està informat, es tracta d'una crida directa). Això provocarà la següent seqüència de trucades:

Aquí veiem que la URL a la que l'usuari accedeix des del navegador es tradueix internament per la URL real, que es troba a les taules de TREN. A més, es garanteix que l'usuari que ha accedit està autenticat i té permís per accedir a aquesta funcionalitat.

3.5.3. Forma de les URL's. La forma de les URLs que es modelen al manteniment del mòdul / aplicació segueixen una determinada codificació que indica determinades característiques de la crida. Aquesta codificació es interpretada per TRENACC a l'hora de fer la crida proxy.

Aquestes codificacions són caràcters especials que es posen al principi de la URL i que poden ser (en ordre estricte d'aparició):

Codi Significat

X El content-type de devolució serà XML.

T Tractament de la URL. Intenta substituir determinats paràmetres.

I Crida indirecta. La sortida es tracta pel TRENACC en lloc de redirigir-la a Apache per que la torni al client.


15/09/2009 pàgina 17 de 50

* L'idioma i APPID s'afegeixen als paràmetres (comportament per defecte).

- No es pasa l'idioma i APPID als paràmetres.

G Obsolet

D Crida amb control d'accés però sense paràmetres.

! S'inclou usuari i contrasenya a la crida (en la forma !usuario!password!

S Crida tipus SOA.

Per exemple, podem trobar per determinat par mòdul / aplicació la següent URL al manteniment de tipus WEB:

XDShttp://sa.uoc.es/remoteinterface/services/TrenService

Això indicarà que el resultat es XML, que es tracta d'una crida amb control d'accés sense paràmetres, i que es tracta d'un Web Service.

Les URLs, i en general les comandes que accepta TREN poden anar encriptats per evitar que es mostrin dades sensibles com contrasenyes. La desencriptació d'aquestes comandes la fa un mòdul PL/SQL (TREN_ENGINE), del qual serà necessària una reengenyeria.

3.5.4. Lògica de la funcionalitat de proxy. Com s'ha vist, la funcionalitat de proxy accepta una sèrie de paràmetres i té una sèrie de modificadors que fan que el seu comportament canvii. No es detallaran completament aquests paràmetres (serà necessari analitzar el codi en temps de desenvolupament), però es fa a continuació un resum del seu funcionament.

La funcionalitat de proxy fa bàsicament les següents tasques:

1. Analitza la URL a la que s'ha d'invocar, desencriptant dades en cas que sigui necessari.

2. Propaga els paràmetres de la crida original a la crida final que retornarà el resultat.

3. Afegeix (en funció de les directives donades a la URL) determinats paràmetres a la crida com poden ser l'idioma, l'usuari i contrasenya, identificador d'usuari, els seus tipus o en nivell d'accés al mòdul.

4. Pren la informació que la petició envia, si és necessari (per exemple, en el cas de que es tracti d'una crida multipart).

5. Si s'ha de tractar la resposta, fa la petició, pren el resultat i el tracta. En cas contrari es delega a la URL final la devolució de la resposta.

Errors:

• MODUL_INEXISTENT : Error en la crida, l'aplicació o mòdul no existeixen.

• Error intern (WRB_ERROR) : Error general d'accés.


15/09/2009 pàgina 18 de 50

3.5.5. Mostrar error (“show_error”) Com un cas especial de la funcionalitat de proxy, TRENACC proporciona una URL equivalent per mostrar un possible error a la crida. Aquesta URL és equivalent a la de proxy però es truca a la funció “show_error”. Es a dir, si en determinat mòdul s'ha produït un error, si es vol mostrar es cridarà a la URL:

http://cv.uoc.edu/tren/trenacc/APP.MOD/show_error?s=SESSIO&code=[C]

On “code” serà el codi d'error a mostrar, o si no s'informa es mostrarà l'error SENSE_ACCES. Els errors s'extreuen de la taula de literals, entrada TREN_ERROR. A més, el aspecte general de la pàgina d'error per l'aplicació / mòdul (color, fons, font...) s'extreuen de la taula de paràmetres d'aspecte per l'aplicació / mòdul (o bé es prenen els valors per defecte).

Aquesta pàgina d'error es mostra també en el cas de que la funcionalitat de proxy doni un problema.

4. Requeriments.

4.1. Reengenyeria de TRENACC. Com ja s'ha dit, l'objectiu del projecte és substituir el cartridge de Pro*C per un component que doni el mateix servei però en una tecnologia que permeti corregir les deficiències actuals i que permeti una evolució més senzilla d'aquest component. Per tant, la proposta és el desenvolupament d'una o més aplicacions J2EE que facin les mateixes tasques que fa TRENACC actualment. Es parla de més d'una aplicació perquè una de les possibilitats és dividir aquesta reengenyeria en una aplicació que doni servei a TREN.DLL i un altra que faci les funcions de proxy. D'aquesta manera, la transició d'una aplicació a l'altra seria més gradual i controlada. Per la redacció d'aquest document no es rellevant si finalment s'implementa amb una o més aplicacions ja que es parlarà de les funcionalitats que dona, no del desplegament final de la solució.

Donada l'absència de documentació, serà necessari analitzar el funcionament de la peça antiga (TRENACC) per determinar detalls del comportament, per tant l'adjudicatari haurà de considerar l'anàlisi del codi antic al marc d'aquest projecte.

A partir d'ara, a la nova peça se l'anomenarà TRENACC2.

4.2. Visió general. Vist en grans blocs, el que es pretén es substituir la peça TRENACC, de manera que la resta de components no es vegin afectats. Com que TREN.DLL guarda al Registry de Windows les URLs dels serveis, podem considerar que es tracta d'un traspàs de funcionalitats de TRENACC a TRENACC2 que es podrien substituir modificant les crides d'un component al altre (o bé mitjançant proxy).


15/09/2009 pàgina 19 de 50

4.3. Components a considerar. Més en detall, sorgeix el problema de l'accés de TRENACC2 a la base de dades de TREN, i el fet de que TRENACC2 ha de residir a una zona accessible des de l'exterior. Per evitar els problemes de seguretat que això pot comportar, i per centralitzar tota la lògica de seguretat, es proposa aïllar tota la lògica de comprovació de permisos i de funcionalitats “core” de TREN a un WS que resideixi a una zona protegida. A grans trets, lesquema seria:


15/09/2009 pàgina 20 de 50

4.3.1. TRENACC2 com a servei a TREN.DLL. La part que dona servei a les peticions de TREN.DLL serà una aplicació Java implementada amb un mecanisme similar a un servlet que doni resposta a peticions que li facin, de la manera més similar possible a TRENACC.

D'aquesta manera, es tractaria d'una aplicació que bàsicament dona servei a peticions HTTP a les URLs que es relacionen als apartats anteriors. És una aplicació sense estat i que delega tota la lògica (en concret, la de consulta a base de dades) al WS TRENACC2. Tots els serveis han de funcionar de manera equivalent al TRENACC original, de manera que la transició sigui menys traumàtica.

Els serveis als que s'ha de donar resposta son els que es descriuen a 3.5

4.3.2. TRENACC2 com a PROXY. De la mateixa manera que la part de servei a TREN.DLL, el servei de proxy ha de funcionar de manera equivalent al TRENACC actual. Aquest component ha de funcionar com a proxy que delega la petició a la URL construïda segons les regles descrites, i tornar el resultat al que el sol·licita. El mòdul ha de suportar HTTP 1.1 i en general tots els estàndards que assegurin un bon funcionament amb qualsevol servidor al que tingui que fer la petició.

S'ha de posar especial cura als aspectes de tractament d'errors, dels idiomes i per suposat s'ha de posar molt d'èmfasi a la seguretat del component. El desenvolupament no implementarà cap dels aspectes de lògica que determinan si l'usuari pot tenir o no accés al mòdul, delegant totes aquestes decisions al Web Service que es descriu més endevant.

S'ha de preveure que aquest mòdul rebrà un gran nombre de peticions concurrents, i per tant s'ha de dissenyar de manera que sigui capaç d'acceptar-les i de introduir el menor “overhead” possible al diàleg, contemplant situacions com un temps de resposta excesiu


15/09/2009 pàgina 21 de 50

de la capa de lògica. Serà necessari fer proves d'estrès amb una càrrega considerable abans de la posta en marxa.

Es recomana utilitzar les llibreries HttpClient de Apache Commons pel accés a les URLs de destí.

4.3.3. WS TRENACC2. Aquest component, com ja s'ha dit, contindrà tota la lògica de comprovació de permisos i, en general, l'accés a la base de dades necessària pel funcionament de TRENACC2. Tot i que es una decisió que es pendrà a la fase d'anàlisi, a priori tota la funcionalitat estarà agrupada a un únic Web Service amb diferents operacions. Els criteris pel seu desenvolupament seran:

• Seguretat: Com que es tractarà d'un component sensible en quant a la seva seguretat, s'han de fer tots els esforços possibles per fer molt segur el diàleg entre aquest i els consumidors (via WS-Security, certificats...).

• Rendiment: El WS ha de estar construir de tal manera que doni resposta als consumidors en el menor temps possible i al major nombre de peticions concurrents possible, ja que d'altra manera seria un coll d'ampolla per la resta de funcionalitats.

• Simplicitat: Es procurarà que les operacions i objectes que s'intercanviïn siguin el més senzill possible, procurant no sobrecarregar el WS amb més operacions de les estrictament necessàries.

• Coherència: El WS ha de donar resposta a un grup funcional específic, i per tant s'ha de procurar que les funcionalitats formin un tot coherent. En el cas de que es trobi necessari, es crearà un altra Web Service que agrupi les funcionalitats similars. Això s'estudiarà a la fase d'anàlisi.

Tot i que en aquest punt és difícil preveure les operacions d'aquest Web Service, probablement aquestes tindran a veure amb:

• gestió de la sessió (connexió, desconnexió, consulta...),

• comprovació d'accessos d'un usuari,

• informació d'un usuari i del context de la sessió

• enviament de correus a la cua,

• consulta i processament del manteniment a accedir, amb traducció de la URL.

4.4. Esquema de BD. Per una millor comprensió del funcionament del mòdul, a continuació es mostren les principals taules implicades. Per evitar una reengenyeria completa (incloent mòduls fora de l'abast d'aquest projecte), el esquema de la base de dades no es pot modificar.

4.4.1. Aplicacions, mòduls i permisos.


15/09/2009 pàgina 22 de 50

4.4.2. Sessions i usuaris.


15/09/2009 pàgina 23 de 50

4.5. Eines disponibles per la reengenyeria.

4.5.1. Documentació disponible. Tot i que la documentació original del component és molt escassa, es poden lliurar alguns documents generals o es descriu el funcionament del mòdul. De tota manera, la documentació mencionada no entra en major detall que aquest plec.

4.5.2. Codi font original. El codi de l'aplicació original TRENACC (cartridge Pro*C) estarà disponible en el moment en que es desenvolupi el projecte per que es puguin consultar dubtes i detalls de funcionament al fer la re-engenyeria. Si es desitja, es pot entregar també el codi font dels components TREN.DLL i ODBCTREN.DLL.

4.5.3. Prova de concepte. Es disposa tanmateix d'una prova de concepte que valida el funcionament correcte del plantejament que es fa en aquest document per la solució de TRENACC2. Aquesta aplicació es pot lliurar a qui ho desitgi per que pugui avaluar aspectes de l'oferta o bé utilitzar-lo com a base pel desenvolupament.


15/09/2009 pàgina 24 de 50

La prova de concepte realitza proves buides de lògica de negoci del mecanisme de proxy (només cas trucada no directa, sense modificadors) i la simulació d'algunes de les funcionalitats dels serveis a TREN.DLL.

4.6. Entorn de desenvolupament. A la fase de desenvolupament, l'adjudicatari tindrà accés a la xarxa de TEST (on es podrà connectar a la BD o fer “deploy” als servidors Jboss), i rebrà una copia de tots els components necessaris per poder simular el funcionament a les seves instalacions (tren.exe, tren.dll, odbctren.dll, …).

4.7. Redundància, tolerància a fallides, etc. Tots els components desenvolupats han d'estar preparats per executar-se en múltiples entorns a la vegada per proporcionar tolerància a caigudes. El balanceig de les peticions no serà responsabilitat de l'aplicació sinó dels elements d'arquitectura de sistemes de la UOC.

Tanmateix, les aplicacions han de preveure el màxim de situacions d'error possibles, prenent les accions pertinents com re-intents, temps d'espera en cas d'errors, indisponibilitat de la base de dades, etc. Es proposa que el servei gestioni un estat (OK / WARNING / ERROR) que indiqui si no es poden servir peticions, si hi ha cap risc pel servei (per exemple, tems de resposta massa alt), o si tot funciona correctament.

En aquests casos, el tractament dels errors serà tan consistent com sigui possible amb els estàndards (per exemple, retornant codis HTTP correctes en cas d'indisponibilitat).

4.8. Vigilància, monitorització i estat. Com a funcionalitat afegida (no present al mòdul antic), TRENACC2 ha de proporcionar informació sobre el seu funcionament i rentiment (informació que només ha d'estar disponible per usuaris privilegiats). Com a mínim s'ha de proporcionar:

• data i hora de l'últim arranc (temps de servei)

• data i hora de la última petició

• estat del servei, motiu del esta (si es diferent d'OK)

• dades de throughput (nombre de peticions rebudes, nombre d'accessos per backdoor, temps promig de resposta, temps màxim, overhead de les crides...), aquestes dades es podrien també presentar per tipus de petició

• nombre de sessions internes, nombre d'usuaris, nombre de màquines (IP's)...

Tanmateix, s'ha de proporcionar una pàgina sense paràmetres però només accesible a usuaris interns, que indiqui de manera resumida el estat mitjançant un text, de manera que des del sistema de monitorització 7x24 (Nagios) es pugui conèixer l'estat del servei.

Per últim, les traces que deixi el servei han d'ésser clares, netes i informatives, seguint l'estàndard de nivell de traces definit a log4j.


15/09/2009 pàgina 25 de 50

5. Documentació de l'oferta. Proposta de solució tècnica i que intenti complir totes les funcionalitats demanades o possibles alternatives. Aquesta proposta s’ha d’aprovar abans de continuar amb el circuit del projecte.

L’empresa adjudicatària lliurarà en finalitzar la implantació de l’aplicació un manual de funcionament que faci referència a l’ús de l’aplicació tant per part dels administradors com dels usuaris.

Tanmateix s’haurà de presentar la documentació tècnica necessària per garantir el manteniment de l’aplicació (veure l’annex C).

6. Formació. Cal especificar en l’oferta un pla de formació a diferents nivells. La formació estaria dirigida a:

• Usuari administrador

• Equip manteniment (tècnic)

• Arquitectes UOC.

7. Metodologia de gestió del projecte. L’empresa adjudicatària proporcionarà la figura d’un cap de projecte el qual tindrà la responsabilitat d’exercir la direcció executiva de les diferents tasques, liderant l’equip de desenvolupament. El cap de projecte reportarà a la UOC sobre els avenços que es vagin produint en la consecució dels objectius marcats i recollirà l’orientació i els aspectes que des de la UOC es proposin.

La UOC per la seva banda, controlarà el compliment dels terminis i acords així com la qualitat i l’adequació dels serveis objecte d’aquest contracte mitjançant la figura d’un cap de projecte intern.

El Comitè de control del seguiment del projecte estarà format per aquests dos caps de projecte amb la participació eventual d’altres actors. Les reunions de coordinació del projecte es faran amb la periodicitat que s’acordi en iniciar-se el projecte i presentar-se el pla d’actuació amb la planificació de les tasques corresponents.

L’empresa adjudicatària farà la redacció d’actes de totes les reunions realitzades.

El projecte finalitzarà amb una reunió de tancament que prengui funcions d’acte cloenda del projecte i defineixi el començament del període de garantia.

8. Metodologia de desenvolupament i qualitat. La metodologia de desenvolupament i la qualitat dels lliurables s’han d’ajustar als


15/09/2009 pàgina 26 de 50

estàndards UOC. Veure l’annex C per més detalls.

9. Seguretat en el desenvolupament. Tant el desenvolupament com el període de garantia es regiran per la normativa de seguretat de la UOC que es pot veure al annex E.

10. Lliurables. A la finalització del projecte, l’adjudicatari lliurarà:

- Tota la documentació generada al marc del projecte, tant de gestió com la desenvolupament,.

- Tot el codi font, incloent les possibles APIs que s’utilitzin. Independentment dels possibles repositoris de codi que tingui l’adjudicatari, a la finalització del projecte el codi ha de ser al repositori SubVersion de la UOC.

- Manuals d’operació, ús, administració i d’usuari (si s’escau).

11. Aspectes econòmics.

11.1. Condicions de pagament La facturació es durà a terme de la següent manera:

50% del import d’adjudicació a l’inici del projecte.

50% restant una vegada completat el pas a producció i acceptat pel cap de projecte de la UOC.

El pagament es farà efectiu dins dels terminis habituals de pagament de la FUOC, 120 dies, cada dia 10, data factura, mitjançant transferència bancària, si no s’ha produït cap informe negatiu per part del responsable de la FUOC respecte al desenvolupament del servei.

12. Detalls formals de l’oferta

12.1. Contingut. L’oferta haurà d’especificar com a mínim:

Resum executiu de la proposta.

Abast. On s’indiqui amb claredat tot el que queda inclòs i el que no. Per defecte tot el que es demana en aquest document es troba dintre de l’abast del projecte, a no ser que s’indiqui clarament el contrari.


15/09/2009 pàgina 27 de 50

Solució Proposada. Ha d’incloure una proposta tècnica per a la solució, i els lliurables.

Metodologia i eines. Resum abreujat de la metodologia aportada, destacant-ne aquells aspectes que siguin més rellevants per a l’execució del projecte plantejat, així com una descripció de les eines que s’utilitzaran per dur-la a terme.

Planificació i fases. Calendari de les activitats en el qual s’indiquin les diferents fites a realitzar durant el desenvolupament del projecte.

Posta en marxa.

S’haurà d’especificar clarament les activitats derivades de la posta en marxa de l’aplicació, que com a mínim hauran de contemplar:

• Suport a l’equip tècnic de la UOC en la posta en producció.

• Suport a la posta en marxa. L’adjudicatari haurà de contemplar el suport necessari als tècnics de la UOC i als usuaris interns de la aplicació, per tal de garantir el correcte funcionament de l’aplicació, la primera vegada que se’n faci ús a l’entorn de producció.

• Garantia i funcionament, seguint les pautes que s’indiquen a l’apartat corresponent.

• Traspàs a manteniment, tal i com s’indica a l’apartat específic més endavant.

Per cadascuna d’aquestes tasques, cal especificar de forma explícita a les taules de sota, els equips, la durada, l’esforç i les condicions econòmiques previstes.

Equip. S’haurà d’indicar els recursos humans implicats i la seva càrrega prevista per cada fase, amb les tasques de posta en marxa incloses, tant pels components de la empresa proveïdora com pel que fa als equips interns de la UOC, segons una taula com la següent:

Empresa Col·laboradora UOC Durada

Perfil 1 Perfil 2 ... Perfil 1 Perfil 2 ...

Total

Fase 1 (dies) (hores) (hores) (hores) (hores) (hores) (hores) (hores)

Fase 2 (dies) (hores) (hores) (hores) (hores) (hores) (hores) (hores)

... (dies) (hores) (hores) (hores) (hores) (hores) (hores) (hores)

Total (dies) (hores) (hores) (hores) (hores) (hores) (hores) (hores)

Condicions econòmiques. L’oferta econòmica haurà de ser tancada i detallada establint l’import total i per fase i perfil segons la taula següent:


15/09/2009 pàgina 28 de 50

Empresa Col·laboradora

Perfil 1 Perfil 2 ...

Total

€/hora €/hora €/hora

Fase 1 € € € €

Fase 2 € € € €

... € € € €

Total € € € €

12.2. Període de garantia. S’ha d’establir un període de garantia no inferior a sis mesos, a comptar des de la recepció definitiva.

Durant aquest període l’adjudicatari es compromet a resoldre satisfactòriament totes aquelles incidències o defectes detectats a l’aplicació desenvolupada o sistema d’informació implantat imputables a ell per acció u omissió i farà explícit en la seva proposta els nivells de servei que s’aplicaran per la seva resolució.

A l’ inici del període de garantia, s’habilitarà la entrada i gestió d’incidències a l’eina de la UOC (RUC) i es donarà accés a l’adjudicatari. Totes les incidències que es detectin durant aquest període, seran registrades per la UOC en aquesta eina i l’adjudicatari gestionarà la seva resolució a traves de la mateixa.

12.3. Traspàs a l’equip de manteniment. La UOC disposa d’un servei centralitzat de gestió i manteniment de les aplicacions informàtiques, que rep les incidències i consultes de tots els usuaris.

S’ha de preveure dins del projecte la transferència dels coneixements tecnològics sobre l’eina, amb la formació i documentació necessària, per aconseguir proporcionar el complet coneixement funcional i tecnològic a l’ equip de manteniment.

Aquesta transferència de coneixement es farà en dues fases: una primera després de la posta en marxa i una segona al finalitzar el període de garantia i es formalitzi, llavors, l’entrega a manteniment. Per formalitzar aquesta entrega, l’adjudicatari aportarà un petit anàlisi sobre el conjunt de problemes detectats durant el període de garantia i les mesures correctives i preventives portades a terme.

12.4. Propietat intel·lectual, seguretat, confidencialitat, i protecció de dades Tots els treballs i desenvolupaments que es realitzin durant la prestació dels serveis, així com, qualsevol canvi en els codis o codi font dels desenvolupaments serà propietat de la FUOC.


15/09/2009 pàgina 29 de 50

Les funcions i obligacions del personal assignat hauran d’estar inclosos dins l’àmbit de confidencialitat de la informació, seguretat d’accessos i dades així com temes relacionats amb la propietat intel·lectual. Per garantir el compliment, l’adjudicatari haurà de signar un document que estableix l’acord de confidencialitat de les dades personals, segons l'article 12 de la Llei orgànica (15/1999) de Protecció de Dades Personals, subministrats per a la prestació de serveis outsourcing informàtic.

12.5. Formalització Contracte Una vegada adjudicat el projecte, la UOC o la empresa adjudicada, poden requerir la formalització d’un contracte mercantil entre ambdues parts.

Pel fet de presentar oferta, l’adjudicatari es compromet a incorporar les clàusules que siguin aplicables referents a:

• Prevenció de riscos laborals

• Protecció de dades personals

• Confidencialitat de les dades

• Jurisdicció

amb el contingut que s’indica a l’annex D: “Clàusules contractuals”

12.6. Criteris d’adjudicació Els establerts a l'annex 3 del plec administratiu.

12.7. Termini de presentació, adjudicació i execució. Els establerts l'annex 1 del plec administratiu.


15/09/2009 pàgina 30 de 50

Annex A – Revisió del acompliment de les Pautes d’Accessibilitat del WAI – AA

(*) cal omplir la columna “Acompliment” amb els valors: (OK / No / No aplicable) del desenvolupament en curs

(**) en fons de color, aquelles normes que són més correntment aplicables en el tipus d’aplicacions que treballem (blau: prioritat 1, groc: prioritat 2)

Normativa WAI Acompliment (*) Observacions

En general (Prioritat 1): Si

1.1 Proporcioni un text equivalent per a tot element no textual (ex.: a través de "alt", "longdesc" o en el contingut de l’element). Això inclou: imatges, representacions gràfiques del text, mapes d’imatge, animacions (ex. GIFs animats), "applets" i objectes programats, "ASCII art", marcs, scripts, imatges fetes servir com vinyetes en les llistes, espaiadors, botons gràfics, sons (utilitzats amb o sense interacció), arxius exclusivament auditius, banda sonora del vídeo i vídeos.

OK

Totes les imatges han de tenir text ALT.

El text ALT ha d’indicar la funcionalitat de la imatge. Els textos han de ser multiidioma.

Si el gràfic és de maquetació (per exemple, píxels per separar elements) el seu text ha de ser null: alt=””.

Si hi ha imatges complexes que contenen informació en si mateixes (gràfics, taules...) s’ha d’omplir l’atribut LONGDESC de la imatge.

2.1 Asseguri que tota la informació transmesa a través dels colors també estigui disponible sense color, per exemple mitjançant el context o per marcadors.

OK Ex.: boletes de colors (posar alt), semàfors, ...

4.1 Identifiqui clarament els canvis en el llenguatge natural del text del document i en qualsevol text equivalent (ex: llegendes).

No aplicable No es fa normalment.

6.1 Organitzi el document de manera que pugui ser llegit sense fulla d'estil. Per exemple, quan un document HTML és interpretat sense associar-lo a una fulla d'estil, ha de ser possible llegir-lo.

OK

Fa referència al us d’una estructura de capes; les aplicacions utilitzen taules normalment. Si s’utilitzen capes, al desactivar css ha de poder-se entendre el document.

6.2 Asseguri que els equivalents d'un contingut dinàmic són actualitzats quan canvia el contingut dinàmic.

No aplicable Normalment ja és així.

7.1 Fins que els agents d'usuari permetin controlar-lo, eviti provocar parpelleig en la pantalla.

No aplicable Animacions. No utilitzem.

14.1 Utilitzi el llenguatge apropiat més clar i simple per al contingut d'un lloc.

OK

I si utilitza imatges i mapes d'imatge (Prioritat 1):

Si


15/09/2009 pàgina 31 de 50

1.2 Proporcioni vincles de text redundants amb cada zona activa d'un mapa d'imatge del servidor.

No aplicable Mapes d'imatges. No utilitzem.

9.1 Proporcioni mapes d'imatge controlats pel client en lloc de per el servidor, excepte on les zones sensibles no puguin ser definides amb una forma geomètrica disponible

No aplicable Mapes d'imatges. No utilitzem.

I si utilitza taules (Prioritat 1): Si

5.1 En les taules de dades, identifiqui els encapçalaments de fila i columna.

OK En taules de dades, posar capçaleres de fila i columna (<TH> enlloc de <TD>)

5.2 Per a les taules de dades que tenen dues o més nivells lògics d'encapçalaments de fila o columna, utilitzi marcadors per a associar les cel·les d'encapçalament i les cel·les de dades.

OK No és habitual.

I si utilitza marcs ("frames") (Prioritat 1): Si

12.1 Tituli cada marc per a facilitar la identificació i navegació dels mateixos.

OK

En els FRAMES s’ha de posar un nom descriptiu a NAME i a TITLE. Ha de ser multiidioma.

Evidentment també cal posar <TITLE> descriptiu a totes les planes.

I si utilitza "applets" i "scripts" (Prioritat 1): Si

6.3 Asseguri que les pàgines segueixin sent utilitzables quan es desconnectin o no se suportin els scripts, applets o altres objectes de programació. Si això no és possible, proporcioni informació equivalent en una pàgina alternativa accessible.

No aplicable Applets. No usem. Scripts seria inviable.

I si utilitza multimèdia (Prioritat 1): Si

1.3 Fins que els agents d'usuari puguin llegir automàticament el text equivalent de la banda visual, proporcioni una descripció auditiva de la informació important de la banda visual d'una presentació multimèdia.

No aplicable Multimèdia. No usem.

1.4 Per a tota presentació multimèdia temporitzada (p. ex. una pel·lícula o animació) sincronitzi alternatives equivalents (p. ex. subtítols o descripcions de la banda de visual) amb la presentació.


I si tota la resta falla (Prioritat 1): Si


15/09/2009 pàgina 32 de 50

1.4 Per a tota presentació multimèdia temporitzada (p. ex. una pel·lícula o animació) sincronitzi alternatives equivalents (p. ex. subtítols o descripcions de la banda de visual) amb la presentació.


Normativa WAI Acompliment (*) Observacions

En general (Prioritat 2): Si

2.2 Asseguri que les combinacions dels colors de fons i primer plànol tinguin el suficient contrast perquè siguin vistes per persones amb dèficits de percepció de color o per pantalles en blanc i negre [Prioritat 2 per a les imatges. Prioritat 3 per als textos].

OK

UOC validarà la maqueta. Si la aparença és la de campus, ja està validat.

Utilitzar sempre CSS per colors.

3.1 Quan existeixi un marcador apropiat, usi marcadors millor que imatges per a transmetre la informació

OK

3.2 Creï documents que estiguin validats per les gramàtiques formals publicades.

OK

Per complir aquest punt en primer lloc es obligatori definir un doctype. p. ex.

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

i cal posar la codificació

<META http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

Validadors a utilitzar:

HTML: http://validator.w3.org/

CSS: http://jigsaw.w3.org/css-validator/

Accessibilitat: Via programa TAW

(http://www.tawdis.net) o Boby

(http://www.cast.org/bobby/) o la eina del propi firefox.

3.3 Utilitzi fulles d'estil per a controlar la maquetació i la presentació.

OK Usar CSS. S’hauria d’eliminar al màxim les taules aniuades.

3.4 Utilitzi valors relatius en lloc d'absoluts a l'especificar la grandària en els atributs dels marcadors de llenguatge i en les propietats de les fulles d'estil.

OK No usar px. Canviar la css per treballar amb valors relatius.


15/09/2009 pàgina 33 de 50

3.5 Utilitzi elements d'encapçalat per a transmetre l'estructura lògica i utilitzi'ls d'acord amb l'especificació.

OK

Us de <h1>, <h2> i no sols titular les seccions via estils. Això permet que es pugui saltar de secció en secció.

Utilitzar tags HTML per definir l’estructura (Hn, UL, TABLE, STRONG, DIV, SPAN, P)

3.6 Marqui les llistes i els punts de les llistes correctament.

OK Per fer llistes d’elements no utilitzar taules ni BR. Utilitzar llistes (UL) i modificar l’aparença amb CSS.

3.7 Marqui les cites. No utilitzi el marcador de cites per a efectes de format tals com sangries.

No aplicable Es refereix a <blockquote/> y <cite/>

6.5 Asseguri que els continguts dinàmics són accessibles o proporcioni una pàgina o presentació alternativa.

NO Consisteix en fer una pàgina accesible sense JavaScript.

7.2 Fins que els agents d'usuari permetin controlar-lo, eviti el parpalleig del contingut (per exemple, canvi de presentació en períodes regulars, així com l'encès i apagat).

No aplicable No utilitzem aquest recurs.

7.4 Fins que els agents d'usuari proporcionin la possibilitat de detenir les actualitzacions, no creu pàgines que s'actualitzin automàticament de forma periòdica.


7.5 Fins que els agents d'usuari proporcionin la possibilitat de detenir el redireccionament automàtic, no utilitzi marcadors per a redirigir les pàgines automàticament. En el seu lloc, configuri el servidor perquè executi aquesta possibilitat.


10.1 Fins que els agents d'usuari permetin desconnectar l'obertura de noves finestres, no provoqui aparicions sobtades de noves finestres i no canviï la venda actual sense informar a l'usuari.

OK Si s’obre una finestra amb window.open, afegir un title que indiqui que s’obre una nova finestra.

11.1 Utilitzi tecnologies W3C quan estiguin disponibles i siguin apropiades per a la tasca, i usi les últimes versions quan siguin suportades.

OK

11.2 Eviti característiques desfasades de les tecnologies W3C .

OK

12.3 Divideixi els blocs llargs d'informació en grups més manejables on sigui natural i apropiat.



15/09/2009 pàgina 34 de 50

13.1 Identifiqui clarament l'objectiu de cada vincle.

OK

Evitar que el link només faci referència a una paraula, si no que faci referència a tota la frase

(p ej. evitar "para borrar todos sus datos pulse <a href>aquí</a>)

13.2 Proporcioni metadades per a afegir informació semàntica a les pàgines i llocs.

No

13.3 Proporcioni informació sobre la maquetació general d'un lloc (per exemple, mapa del lloc o taula de continguts).

No

13.4 Utilitzi els mecanismes de navegació de forma consistent.

OK

I si utilitza taules (Prioritat 2): Si

5.3 No utilitzi taules per a maquetar, llevat que taula tingui sentit quan es linearitzi. D'altra banda, si la taula no té sentit, proporcioni una alternativa equivalent (la qual deu ser una versió linearitzada).

OK

Quan JAWS

(http://www.freedomscientific.com/) llegeix una taula, llegeix de dalt a baix i de esquerra a dreta, per tant s’ha d’anar amb comte en com es distribueix la informació en una taula. La maquetació s’hauria de fer via div encara que en certs casos es difícil.

Posar títol a les taules de dades (<CAPTION>)

5.4 Si s'utilitza una taula per a maquetar, no utilitzi marcadors estructurals per a realitzar un formateig visual.

OK No usar <th> al maquetar

I si utilitza marcs ("frames") (Prioritat 2): Si

12.2 Descrigui el propòsit dels marcs i com aquests es relacionen entre si, si no resulta obvi solament amb el títol del marc.

OK

I si utilitza formularis (Prioritat 2): Si

10.2 Fins que els agents d'usuari suportin explícitament l'associació entre control de formulari i etiqueta, per a tots els controls de formularis amb etiquetes associades implícitament, asseguri que l'etiqueta està col·locada adequadament.

OK

Usar l’estàndard Windows que posa l'etiqueta abans del inputbox o desprès del checkbox o radiobutton.

Si s’utilitza una taula per maquetar el formulari, que etiquetes i controls estiguin a la mateixa taula.

Per formularis llargs, agrupar controls amb <FIELDSET> i <LEGEND>

Utilitzar el TITLE dels controls.


15/09/2009 pàgina 35 de 50

12.4 Associï explícitament les etiquetes amb els seus controls.

OK

Us del tag <label/>

Associar etiqueta amb control: <LABEL FOR=...> , <INPUT ID=...>

I si utilitza "applets" i "scripts" (Prioritat 2): Si

6.4 Per als scripts i applets, asseguri que els drivers d'esdeveniment siguin entrades independents del dispositiu.

OK

Us del ratolí y del teclat. No s’accepta un javascript que només pugui manipular-se amb el ratolí, per exemple un menú que al col·locar-se sobre un enllaç desplegui un submenú y que haguem de moure el ratolí per sobre del menú para poder activar el enllaç...

7.3 Fins que els agents d'usuari permetin congelar el moviment dels continguts, eviti els moviments en les pàgines.


8.1 Faci els elements de programació, tals com scripts i applets, directament accessibles o compatibles amb les ajudes tècniques [Prioritat 1 si la funcionalitat és important i no es presenta en altre lloc; d'altra manera, Prioritat 2].

No aplicable Applets. No usem.

9.2 Asseguri que qualsevol element que té la seva pròpia interfície pugui operar-se de forma independent al dispositiu.

No aplicable Applets. No usem.

9.3 Per a scripts, especifiqui drivers d'esdeveniment lògics millor que drivers d'esdeveniment depenents de dispositius.

OK

S’hauria d’evitar <a href=javascript:..” i substituir per <a href=”...” onclick=”..”

Els links que tenen javascript han de ser compatibles sense tenir javascript;

Exemple: <a href="pagina2.html" onClick="ventanaNueva( 'pagina2.html'); return false;"> página ejemplo </a>


15/09/2009 pàgina 36 de 50

Annex B – Revisió de l’usabilitat i bones pràctiques Consideració Acompliment Observacions

a. Compatibilitat amb Navegadors OK

El contingut de les pàgines haurà de seguir el estàndard de la W3C per l’HTML, versió 4.01

(http://www.w3.org/TR/REC-html40/). S’ha de poder veure correctament les pàgines amb els navegadors del punt de treball de la UOC o superiors:

• Microsoft Internet Explorer 6.0 o superior (Windows XP, Windows 2000 i Windows Vista)

• Firefox 2.0 o superior (Windows XP, Windows 2000, Windows Vista i Ubuntu)

• Safari (Mac OS)

b. Full d’estils únic OK Cal que totes les aplicacions utilitzin el COMUN.CSS

c. El enllaços han de ser relatius OK Dins del codi, els links han de ser sempre relatius i no pas absoluts.

d. Botons (Accepta/Cancel·la) OK “Accepta” es posa a l’esquerra de “Cancel·la” i en negreta.

e. Llenguatge: temps verbals OK

En castellà, ens dirigim a l’usuari en infinitiu; Aceptar, Salir, Ir a la pàgina, Matricularse...

En català ens dirigim a l’usuari en 2a. Persona de l’imperatiu; Accepta, Surt, Ves a la pàgina, Matricula’t...


15/09/2009 pàgina 37 de 50

f. Jerarquia de títols i breadcrumbs

NIVELL1:

Nom de l’aplicació, fix en totes les planes.

(p. ex. “avaluació d’estudis previs – aep”)

NIVELL2:

Nom de l’Apartat / Mòdul. Fix en totes les planes del mòdul.

(p. ex. “aportacions de aep”)

NIVELL3: Títol de la pàgina. Variable en cada pàgina.

(p. ex. “selecció d’origen de ep”)

BREADCRUMB – B1: Nom del primer títol (nivell3)

BREADCRUMB – Bn: Nom del títol actual (nivell3)

BREADCRUMB – Bi: Nom dels títols de les planes intermèdies.

g. Plugins i complements

Tots els complements utilitzats hauran de ser multiplataforma o tenir un equivalent a les plataformes suportades. Si existeix cap consideració o excepció s’haurà de explicitar clarament a la documentació. Això és d’especial rellevància amb la màquina virtual de Java (JRE). Com a estàndard de referència, els plugins més comuns són:

• Sun JRE 1.5 o superior.

• Flash Player (indicant la versió suportada)

• Adobe Reader (indicant la versió suportada)


15/09/2009 pàgina 38 de 50

Annex C – Estàndards metodològics i de qualitat. Independentment de la metodologia seguida per la organització que desenvolupi el programari, la UOC considera que el procés ha de produir una documentació mínima per la correcta consecució d’un projecte. Aquests lliurables no han de ser considerats com un tràmit burocràtic, sinó que han de ser de valor per al client final o l’equip de desenvolupament.

Els lliurables a nivell metodològic que es consideren mínims per la UOC són:

• Documentació:

o recollida de les característiques de l’aplicació, les necessitats, restriccions i integració amb d’altres sistemes,

o recollida dels requeriments del sistema, recollits d’una manera formal (CRC Cards, per exemple),

o descripció funcional del sistema, preferentment amb els casos d'us principals,

o detall de la integració amb altres sistemes,

o disseny tècnic (interfície d’usuari, lògica, detall dels casos d'ús, etc),

o detall de les proves realitzades al sistema amb el seu resultat (proves unitàries, funcionals i d’estrès si es necessari),

o manual d’ús de l’aplicació

o manual d’instal·lació de l’aplicació,

o manual d’operació i administració quan sigui necessari.

• A la documentació es recolliran diferents diagrames (amb UML) que descriguin:

o la funcionalitat del sistema,

o els objectes o classes a construir al marc de l’aplicació (diagrames de bases de dades, classes, packages, llibreries...),

o l’estructura del projecte amb els seus components (bases de dades, llibreries, executables, organització del codi...),

o els elements necessaris per la seva execució (xarxa, màquines implicades, i altres requeriments físics i d’arquitectura),

o el comportament dinàmic del sistema

o la interacció (missatges, crides) entre els diferents components del sistema.

• Respecte al codi lliurat:

o seguirà els estàndards de qualitat definits per la UOC (existeixen annexes amb normatives de qualitat per UML, Java, PHP i PL/SQL)

o contendrà les proves unitàries del codi

o seguirà les normatives de seguretat fixades per la UOC (existeixen annexes amb normatives de seguretat a la UOC)

o utilitzarà les eines i APIS estàndards per la interconnexió amb els sistemes de la UOC (autenticació, internacionalització, etc)


15/09/2009 pàgina 39 de 50

Respecte als diagrames, si es decideix seguir la metodologia proposada a aquest document (RUP Agile, notació UML), els diagrames seran:

Diagrames de Casos d'ús

Representen la funcionalitat d’un sistema i la seva interacció amb l’exterior. Els seus propòsits són:

• Especificar el context d’un sistema

• Capturar els requeriments d’un sistema

• Conduir la implementació i generar casos de prova

En un diagrama de casos d’ús intervenen 2 elements principals:

- Actor. És algú (persona, grup, etc.) o alguna cosa (sistema extern, dispositiu...) que ha d’interaccionar amb el sistema o amb el qual el sistema interacciona.

- Cas d’ús. Denota una operació o unitat funcional que ha de proporcionar el sistema

Diagrames de Classes Un diagrama de classes mostra l’estructura estàtica del model, és a dir, les classes o conceptes existents i les seves relacions entre si. Els seus propòsits són:

• Anomenar i modelar conceptes d’un sistema.

• Especificar col·laboracions.

• Especificar esquemes lògics de bases de dades (mitjançant l'ús d’estereotips).

L’element bàsic d’un diagrama de classes és una classe, que representa una col·lecció d’objectes amb una estructura i comportament comuns, unes relacions comunes i una semàntica similar.

Diagrames d'Objectes Mostra instàncies de classes i els seus enllaços. El seu propòsit és il·lustrar estructures de dades/objectes.

Diagrames de Components

Un diagrama de components captura l’estructura física de la implementació, mostrant la dependència entre els components programari (components de codi font, de codi binari i executables). El seu propòsit és organitzar el codi font, construir una versió executable i especificar una base de dades física.

Diagrames de Deployment

Capturen la topologia del maquinari del sistema. El seu propòsit principal és especificar la distribució dels components, configuració de la xarxa, etc.

L’element principal d’aquest diagrama és el node. Un node és un objecte físic en temps d’execució que representa un recurs computacional, generalment amb memòria i capacitat de processament (un processador).

Diagrames de Seqüència

Un diagrama de seqüència mostra la interacció entre els objectes a través del temps. Per a un cas d’ús es poden realitzar 1 o més diagrames de seqüència; cada un d’ells defineix un camí possible.


15/09/2009 pàgina 40 de 50

El propòsit del diagrama de seqüència és modelar el flux de control i il·lustrar els escenaris típics.

Diagrames de Col·laboració

Un diagrama de col·laboració mostra les interaccions entre els objectes en relació amb missatges.

El seu propòsit és modelar el flux de control i il·lustrar la coordinació entre objectes (en lloc de les interaccions en el temps)

Diagrames d’estats Un diagrama d’estats captura el comportament dinàmic d’una classe (el seu cicle de vida), mostrant els esdeveniments que causen la transició d’un estat a un altre i les accions que tenen lloc en resposta al canvi d’estat.

Diagrames de Activitat Un diagrama d’activitat captura el comportament dinàmic orientat a activitats. El seu ús està orientat a expressar les activitats que tenen lloc en un cas d'ús.

Tots aquests diagrames es faran quan tingui sentit, per tant quan ajudin a entendre el funcionament del sistema. Per exemple, no és necessari fer un diagrama de seqüència de tots els casos d’ús, sinó d’aquells que tinguin una interacció complexa entre els objectes.

El contingut de tota aquesta informació pot relacionar-se amb els documents fixats per les metodologies clàssiques (com presa de requeriments, anàlisi funcional i disseny tècnic) o bé si es segueix la metodologia proposada podrien ser els que defineix RUP Agile. En tot cas, es completaran amb tots els que es considerin necessaris (manuals d’usuari, pla de proves...). Els lliurables que defineix RUP Agile són:

Document de Visió El document de Visió especifica de forma general el producte a ser desenvolupat (context, descripció dels implicats...) en terme de necessitats clau i característiques del sistema, així com de les seves restriccions, integració necessària amb altres sistemes, etc... Es tracta de la base contractual que servirà de punt de partida per detallar els requeriments.

Glossari Defineix els termes i el vocabulari important a ser utilitzat en el projecte (tant conceptes del negoci com conceptes tècnics).

Especificació de Requeriments Defineix els requeriments funcionals i no funcionals del sistema (aplicació d’estàndards, requeriments legals, atributs de qualitat del sistema (usabilitat, rendiment, requeriments de suport, etc.), restriccions de disseny o entorn de la infraestructura a utilitzar.

Model de Casos d'ús Defineix entre d’altres les precondicions, fluxos principals i alternatius dels casos d’ús principals identificats.

Document de Arquitectura de Software

Document de disseny amb diferents vistes de detall sobre el disseny dels casos d’ús, lògica, interfície d’usuari, processos, desplegament, implementació i model de dades.

La UOC pot proporcionar plantilles i exemples dels documents en cas de que no es disposi de models.

Per aclarir el mapeig dels documents amb els diagrames i amb altres metodologies, a continuació es pot veure una taula que ho aclareix:

Document Què conté Metodologies clàssiques

Diagrames Format


15/09/2009 pàgina 41 de 50

Document de visió

- descripció del projecte

- implicats (actors)

- característiques sistema

- integracions

- AF (intro)

-

- Text - DOC / ODT

Glossari - Termes i vocabulari

- AF (intro) - Text - DOC/ODT

Requeriments - Descripció textual

- CRC Cards

- Qualitat

- Infraestructura

- Reqs. No funcionals

- Presa requeriments

- CRC Cards

- Text

- DOC/ODT

Casos d’ús - Casos d’ús més importants

- Pla de proves

- AF / AT

- Pla de proves

- Casos d’ús (UML)

- Diagrama d’activitats (UML)

- DOC/ODT

- Enterprise Architect

Arquitectura de software

- Model dades

- Comportament dinàmic

- Desplegament

- Manual instal·lació

- DT

- AT (Model dades)

- Manual instal·lació

Diagrames (UML) de:

- classes

- components

- deployment

- seqüència

- col·laboració

- activitats

- DOC / ODT

- Enterpise Architect

Codi - Manual d’ús

- Manual d’operació

- Proves unitàries

- Pla de proves executat

- Manuals (ús, operació)

- Pla de proves

- Text - DOC/ODT

- ZIP Codi / SVN

- ZIP Tests / SVN

La UOC disposa d’una plana web on es poden consultar detalls sobre els estàndards i altres que poden ser d’utilitat per valorar l’oferta. Aquesta plana es pot veure a http://cv.uoc.edu/app/wiki/grc_8842/index.php


15/09/2009 pàgina 42 de 50

Annex D - Clàusules Contractuals. La UOC i l’adjudicatari formalitzaran un contracte on s’inclouran les següents clàusules:

PREVENCIÓ DE RISCOS LABORALS El CONTRACTISTA es compromet a complir, en la prestació dels serveis objecte del Contracte, qualsevol normatives, disposicions i regulacions legals o reglamentàries en vigor a la data de formalització del present Contracte o que entrin en vigor durant la vigència del mateix, que es refereixin a prevenció de riscs laborals. En especial, el CONTRACTISTA es compromet a complir la Llei 31/1995, de 8 de novembre, de Prevenció de Riscs Laborals, el Reial Decret 39/1997, de 17 de gener, de Serveis de Prevenció, així com quantes normatives els poguessin desenvolupar, complementar, modificar o substituir.

En cas que els serveis objecte del Contracte es desenvolupin de forma permanent o esporàdica a les instal·lacions de LA FUNDACIÓ PER A L'UNIVERSITAT OBERTA DE CATALUNYA (FUOC, d'ara endavant), sense perjudici de qualssevol altres que li puguin correspondre, el CONTRACTISTA tindrà les següents obligacions:

1) Realitzar l'avaluació de riscs laborals del personal destinat pel CONTRACTISTA a la prestació dels Serveis i remetre l'esmentada avaluació a FUOC en el termini dels dos (2) mesos següents a l'inici de la prestació dels serveis objecte del CONTRACTE.

2) Subministrar als seus empleats els equips de protecció personal que fossin d'aplicació als tipus de serveis deixats, segons les normes de prevenció de riscs laborals que poguessin ser d'aplicació a la categoria de serveis prestats, o bé perquè la naturalesa dels serveis o les circumstàncies en les quals es duguin a terme així ho aconselli. Així mateix, haurà de verificar que els seus empleats utilitzen efectivament els equips de protecció personal subministrats.

3) En cas que FUOC posés a disposició del CONTRACTISTA alguns equips de protecció personal, això no suposarà l'assumpció de qualssevol responsabilitats per FUOC en relació amb els accidents o danys<A[danys|mals]> que, eventualment, poguessin produir-se.

4) Indemnitzar íntegrament FUOC de qualssevol danys<A[danys|mals]> i perjudicis que poguessin derivar-se per a aquesta com a conseqüència de danys<A[danys|mals]> en les persones o a les coses, produïdes directament o indirectament per l'incompliment del CONTRACTISTA en el compliment<A[compliment|observança]> de les normes o sobre prevenció de riscs laborals.

5) No reclamar i mantenir indemne a FUOC davant qualsevol reclamació de tercers pels danys<A[danys|mals]> personals i materials causats directament o indirectament per l'incompliment del CONTRACTISTA en el compliment<A[compliment|observança]> de la normativa sobre prevenció de riscs laborals. A efectes s'entendrà com tercers no solament aquelles persones alienes al Contractista i FUOC, sinó també el propi personal del CONTRACTISTA i de FUOC.

6) Formar el personal que el CONTRACTISTA destini a la prestació dels serveis objecte del CONTRACTE en matèria de prevenció de riscs laborals, conforme a les normatives que fossin d'aplicació subministrant a FUOC la documentació necessària per acreditar l'esmentada formació. En cas que el CONTRACTISTA no acredités l'esmentada formació sobre matèries relatives a prevenció que puguin ser aplicables per a algunes de les categories de serveis que es desenvolupin en els centres de treball de FUOC (maneig d'extintors, primers auxilis<A[ajuts|auxilis]>, riscs derivats de treballs<A[treballs|feines]> elèctrics,....), FUOC es reserva la facultat que doni<A[doni|imparteixi]> ella mateixa els cursos corresponents, carregant el CONTRACTISTA els costos que es derivin per a FUOC per la prestació de l'esmentat curs. En tot cas, seran per compte de la seva empresa qualssevol descomptes que haguessin de realitzar-se en la jornada dels treballadors del CONTRACTISTA pel temps invertits pels mateixos a assistir als esmentats cursos de formació, sent responsabilitat del CONTRACTISTA garantir la continuïtat del servei contractat. La prestació de l'esmentada formació per part de FUOC en


15/09/2009 pàgina 43 de 50

cap cas no s'entendrà com una assumpció de qualssevol responsabilitats per part d'aquesta, ni no exonerarà total o parcialment al CONTRACTISTA de qualsevol de les obligacions que li corresponen.

PROTECCIÓ DE DADES PERSONALS: Cadascuna de les entitats signants serà responsable del compliment de la normativa reguladora de les dades de caràcter personal.

A l'efecte, les parts declaren conèixer les disposicions relatives a la Llei Orgànica 15/ 1999, de 13 de desembre de Protecció de Dades de Caràcter Personal, i es comprometen a complir les exigències previstes en la mateixa respecte de les dades que pertanyen a les persones usuàries de les col·laboracions acordades. Especialment i sense perjudici del compliment de totes les obligacions legals, es fa referència a les recollides en els articles 11.2 c), 9 i 12 de la citada norma:

1.- Les parts no aplicaran aquestes dades ni les utilitzaran per a finalitats diferents a la prestació dels programes que són l’objecte del present conveni.

2.- Les parts no comunicaran aquestes dades, ni tan sols per a la seva conservació, a altres persones, físiques o jurídiques, tret en els casos previstos per la legislació vigent.

3.- Es comprometen a adoptar les mesures de caire tècnic i organitzatives necessàries que garanteixin la seguretat de les dades de caràcter personal i evitin la seva alteració, pèrdua, tractament o accés no autoritzat, tenint en compte l'estat de la tecnologia, la naturalesa de les dades emmagatzemades i els riscos els quals estan exposades, ja provinguin de l'acció humana o del medi físic o natural. Específicament les entitats hauran de complir les mesures previstes per al nivell bàsic en el Reial decret 994/1999, de 11 de juny (BOE 25 juny 1999), pel qual s'aprova el Reglament de Mesures de Seguretat aplicables als Fitxers automatitzats de Caràcter Personal, i en cada moment les disposicions vigents en la matèria.

4.- En els termes que les parts de mutu acord aprovin, s'informarà als usuaris de forma expressa, precisa i inequívoca, de l'existència de fitxers de dades de caràcter personal, finalitat de la recollida i destinataris de la informació, identitat i adreça dels responsables del tractament, possibilitat d'exercitar els drets d'accés, rectificació, cancel·lació i oposició, i altres extrems legalment establerts

4- CONFIDENCIALITAT: Les parts acorden tractar confidencialment totes les dades, documentació i informació que hagi estat subministrada a l’altra part durant la vigència del present contracte. Ambdues parts també acorden no divulgar aquesta informació a cap persona o entitat, exceptuant els seus treballadors, amb la condició que mantinguin també la confidencialitat i només en la mesura que sigui necessari per a la correcta execució d’aquest contracte.

L’acord de confidencialitat seguirà vigent fins i tot després de l’extinció d’aquest contracte, sigui quina sigui la causa.

JURISDICCIÓ: Totes dues parts expressen el compromís de complir les seves obligacions respectives de bona fe i de portar a bon terme totes i cada una de les negociacions que siguin necessàries per a complir aquest contracte a satisfacció d’ambdues.

Per a la solució de qualsevol qüestió litigiosa derivada de la interpretació, aplicació o execució dels acords establerts en aquest contracte, les parts se sotmeten a l’arbitratge institucional del Tribunal Arbitral de Barcelona, de l’Associació Catalana per a l’Arbitratge, a qui s’encarrega la designació de l’àrbitre o àrbitres i l’administració de l’arbitratge. L’arbitratge serà de dret i les parts s’obliguen des d’ara al compliment de la decisió arbitral


15/09/2009 pàgina 44 de 50


15/09/2009 pàgina 45 de 50

Annex E – Desenvolupament segur del software.

1. Introducció: Aquest annex està pensat per ajudar als desenvolupadors de software i al seus clients a l'hora de negociar i capturar els termes importants contractuals i les condicions relacionades amb la seguretat dels programes desenvolupats o adquirits.

Aquest annex està pensat per a ser afegit als contractes de desenvolupament de software. Els termes seran negociables, en el sentit que caldrà que siguin discutits entre client i desenvolupadors.

Aquest annex estableix el compromís d'acord entre el Client Universitat Oberta de Catalunya (d'ara en endavant UOC) i l’adjudicatari. UOC i l’adjudicatari acorden per aquest contracte vinculant, maximitzar la seguretat del software de l'aplicació (d'ara en endavant l’aplicació) d'acord amb els següents termes.

2. Filosofia: Aquest annex està destinat a clarificar els drets i obligacions relacionades amb la seguretat de les relacions comercials de les parts involucrades en el desenvolupament de l’aplicació. Al més alt nivell, aquestes parts acorden que:

a) Les decisions de seguretat estaran basades en el risc: Les decisions de seguretat es prendran conjuntament entre UOC i l’adjudicatari basant-se en una alta comprensió del risc que pot tenir l’aplicació.

b) Les activitats dedicades a la seguretat estaran balancejades: Els esforços dedicats a la seguretat de l’aplicació estaran fortament distribuïts durant tot el cicle de vida del seu desenvolupament.

c) S'integraran les activitats dedicades a la seguretat: Totes les activitats i la documentació generada aquí caldrà que s'integri en el cicle de vida de desenvolupament del software de l’aplicació i no podran en cap cas estar separades de la resta del projecte. Res en aquest annex implica un desenvolupament especial de software.

d) Podran aparèixer vulnerabilitats: Aquest annex assumeix que tot software pot tenir errors i que alguns d'aquests poden crear incidents de seguretat. Tant UOC com l’adjudicatari s'esforçaran en identificar les vulnerabilitats amb la major celeritat possible durant el cicle de vida de l’aplicació.

e) La seguretat de la informació serà completament revelada: Tota informació relacionada amb la seguretat de la informació de l’aplicació, serà compartida entre UOC i l’adjudicatari de forma immediata i completa. El proveïdor especificarà per escrit quins aspectes de la seguretat relacionada amb el desenvolupament pensa no complir.


15/09/2009 pàgina 46 de 50

f) Només es requereix aquella documentació que sigui útil en aspectes de seguretat: La documentació de seguretat no han de ser extensa en excés en ordre a clarificar, descriure el disseny de la seguretat, el risc, l'anàlisi i els incidents.

3. Activitats del cicle de vida de l’aplicació: a) Comprensió del risc: UOC i l’adjudicatari acorden treballar de manera conjunta per comprendre i documentar els riscs que poden afectar a l’aplicació. Aquest esforç s'enfocarà a identificar possibles vulnerabilitats que afectin als actius i les funcionalitats de l’aplicació. Caldrà considerar cadascun dels punts, funcionalitats i casos d'ús definits en la part dels requeriments de l’aplicació.

b) Requeriments: Basant-se en el risc, UOC i l’adjudicatari acorden treballar de manera conjunta per definir uns requeriments de seguretat com a part de les especificacions del software a desenvolupar. Cadascun dels punts que s'hagin enumerat en la secció de requeriments caldrà que siguin discutits i avaluats conjuntament per UOC i l’adjudicatari. Aquests requeriments hauran de ser satisfets en la seva totalitat per l’aplicació.

c) Disseny: L’adjudicatari acorda proporcionar una documentació que expliqui de forma clara el disseny que s'implementa per assolir els requeriments de seguretat. Aquest disseny explicarà de forma clara si el suport als requeriments de seguretat provenen del software desenvolupat a l’aplicació, de software de terceres parts o de la plataforma en la que s'implementa el desenvolupament.

d) Implementació: L’adjudicatari acorda proporcionar i seguir un conjunt de bones pràctiques de programació. Aquestes guies indicaran com s'ha de formatar el codi, com s'ha d'estructurar i comentar. Tanmateix el codi podrà ser revisat per alguna persona responsable de l'execució del projecte de la UOC que validarà els requeriments de seguretat i les guies de programació abans de que el codi de l’aplicació sigui considerat preparat per test.

e) Seguretat de l'anàlisi i proves: L’adjudicatari acorda proporcionar i seguir un pla de proves de seguretat el qual definirà la aproximació que s'hagi fet a cadascun dels requeriments de seguretat. El nivell del rigor d'aquesta activitat ha d'estar considerada i detallada en el pla del projecte. L’adjudicatari executarà el pla de proves de seguretat i proporcionarà els resultats a la UOC.

f) Desplegament segur: L’adjudicatari acorda proporcionar les guies per configurar l’aplicació de manera segura, ben documentades i de tal manera que cobreixin tots els requeriments especificats en el pla de projecte. L’adjudicatari inclourà en aquesta guia una completa descripció de les dependencies de la plataforma suportada, incloent-hi el sistema operatiu, la


15/09/2009 pàgina 47 de 50

base de dades, el servidor web i el servidor d'aplicacions i com aquests hauran de ser configurats per complir amb els requeriments de seguretat. L’adjudicatari acorda que la configuració per defecte de l’aplicació que lliurarà a la UOC serà segura

4. Àrees de seguretat L’adjudicatari acorda que les següents àrees seran considerades durant la comprensió del risc i les activitats de definició dels requeriments de l’aplicació.

a) Validació i codificació: Tot el conjunt de requeriments que especifiquen les regles per canonicalitzar, validar i codificar cada entrada de l’aplicació, tant des dels usuaris, sistema de fitxers, directoris o sistemes externs. La regla per defecte serà que totes les entrades són invàlides a menys que compleixin una determinada especificació que ho permeti. Addicionalment, els requeriments de l’aplicació especificaran l'acció a emprendre quan es rebi una entrada no vàlida. Específicament, l’aplicació no serà susceptible a injecció, desbordament (overflow), manipulació (tampering) o d'altres atacs de corrupció d'entrada de dades.

b) Autenticació i gestió de la sessió: Els requeriments de l’aplicació especificaran com les credencials d'autenticació i els identificadors de sessió son protegits en tot el seu cicle de vida. S'inclouran els requeriments referits a l'encapçalament d'aquest paràgraf de totes les funcions relacionades, incloent-hi la pèrdua de contrasenya, els canvis de contrasenya, els recordatoris de contrasenya, la desconnexió per inactivitat i la possibilitat de l'ús de múltiples connexions simultànies (multiple login).

c) Control d'accés: Els requeriments de l’aplicació inclouran una descripció detallada de tots els rols i perfils usats (grups, privilegis, autoritzacions) en l'aplicació. Els requeriments hauran també d'indicar tot el conjunt d'actius i funcionalitats proporcionades per l’aplicació. Els requeriments hauran d'explicar completa i exactament els drets d'accés a cadascun dels actius i funcions de l'aplicació per cadascun dels rols. Es suggereix construir una matriu de control per explicar el format d'aquestes regles.

d) Manipulació i gestió d'errors: Els requeriments de l’aplicació caldrà que detallin com es gestionen els errors de l'aplicació durant el procés de funcionament de la mateixa. S'entén que en algunes funcionalitats es tindrà més cura en el tractament d'errors, sobre tot les que tinguin més incidència en l'usuari final, mentre que d'altres pot ser que acabin en la finalització del procés immediatament.

e) Registre (Logging): Dins dels requeriments caldrà que s'especifiquin quins esdeveniments són rellevants per la seguretat i les connexions de l'aplicació, com ara els atacs detectats, els intents fallits d'accés i els intents de guanyar privilegis. Els requeriments també especificaran quin tipus


15/09/2009 pàgina 48 de 50

d'informació queda enregistrada para cadascun dels esdeveniments generats, incloent-hi la data, la descripció de l'esdeveniment, detalls de l'aplicació i d'altra informació forense d'utilitat.

f) Connexió a sistemes externs: Els requeriments especificaran com es tracta la autenticació cap a sistemes externs a l'aplicació, com ara les bases de dades, directoris i serveis web. Totes les credencials necessàries per a la comunicació amb aquests sistemes que s'emmagatzemin en fitxers de configuració ho faran de forma protegida.

g) Encriptació: Els requeriments de l’aplicació especificaran quines dades han de ser xifrades, com s'han xifrat i com es manipularan els certificats y d'altres credencials. Les especificacions es referiran sempre a un algorisme estàndard d'alguna biblioteca abastament provada i utilitzada.

h) Disponibilitat: Els requeriments hauran d'especificar com es protegirà l’aplicació dels atacs de denegació de servei. Englobant-hi els atacs sobre el bloqueig d'autenticació, esgotament de les connexions i en general d'altres atacs d'exhauriment de recursos.

5. Personal i organització. a) Arquitecte de seguretat: L’adjudicatari assignarà responsabilitats en matèria de seguretat a un recurs, que passi a ser l'arquitecte de seguretat del projecte. Aquest certificarà la seguretat de cada lliurament.

b) Formació en seguretat: L’adjudicatari serà responsable d'assegurar que tots els seus membres de l'equip de desenvolupament estan capacitats en les tècniques de desenvolupament segur.

6. Biblioteques, frameworks d'aplicació i productes. a) Divulgació: L’adjudicatari farà públic el software de terceres parts usat en el desenvolupament de l’aplicació, incloent-hi les llibreries, frameworks, components i d'altres productes, siguin comercials, lliures, en codi obert o en codi tancat.

b) Avaluació: L’adjudicatari realitzarà els esforços raonables per assegurar que tot el software de terceres parts usat en l’aplicació, compleix els termes d'aquest annex. Si les llibreries tenen vulnerabilitats publicades en el moment de la signatura del contracte, l’adjudicatari es comprometrà a canviar-les per la versió que no presenti vulnerabilitats o per un altre producte que ofereixi majors garanties de seguretat sempre i quan sigui compatible amb el projecte.

7. Revisions de seguretat a) Dret a la revisió: UOC té el dret a revisar el codi per fallades de


15/09/2009 pàgina 49 de 50

seguretat. L’adjudicatari acorda proporcionar un suport raonable posteriorment a la data de lliurament i durant el període de garantia.

b) Cobertura de les revisions: Les revisions de seguretat inclouran tots els aspectes relacionats amb la distribució de l’aplicació, incloent-hi el codi desenvolupat, els components, productes i la configuració del sistema.

c) Àmbit de la revisió: Com a mínim, la revisió abastarà tots els requeriments de seguretat i cerca de d'altres vulnerabilitats. L'examen pot incloure una combinació d'escanejos de vulnerabilitats, tests de penetració, anàlisi del codi font, revisions per terceres parts i revisió del codi.

d) Problemes de seguretat descoberts: Seran reportats tant per UOC com l’adjudicatari. Totes aquestes qüestions seran rastrejades i solucionades tal i com s'especifica en la secció Gestió dels Problemes de Seguretat d'aquest annex.

8. Gestió dels problemes de seguretat a) Identificació: L’adjudicatari farà un seguiment de tots els problemes de seguretat descoberts durant tot el cicle de vida de l’aplicació, disseny, execució, assajos, desplegament i garantia. El risc associat a cada problema de seguretat serà avaluat, documentat i informat a la UOC tan ràpid com sigui possible després del seu descobriment.

b) Protecció: L’adjudicatari protegirà adequadament la informació relativa a qüestions relacionades amb la seguretat i la documentació associada, per ajudar a que quedin exposades al mínim les possibles vulnerabilitats de l’aplicació.

9. Fiabilitat a) Fiabilitat: L’adjudicatari oferirà un "paquet de certificació" que constarà de la documentació de seguretat creada al llarg del procés de desenvolupament. Aquest paquet de certificació establirà i descriurà com els requeriments de seguretat, disseny, implementació i els resultats de les proves van ser degudament complimentats i que totes les qüestions de seguretat es van resoldre adequadament.

b) Certificació: L’adjudicatari certifica que l’aplicació compleix amb els requeriments de seguretat, que en el desenvolupament s'han realitzat totes les activitats relacionades amb la seguretat i que tots els problemes de seguretat identificats s'han documentat i resolt. Qualsevol excepció a la Certificació de l’aplicació estarà plenament documentada en el lliurament. Aquesta Certificació estarà inclosa dins el "Paquet de Certificació".

c) Lliure de codi maliciós: L’adjudicatari garanteix que l’aplicació no conté cap codi que no sigui compatible amb els requeriments de l’aplicació i


15/09/2009 pàgina 50 de 50

debiliti la seguretat de l'aplicació, inclosos els virus, cucs, bombes de temps, portes secretes, troians, ous de Pasqua i totes les demés formes conegudes de codi maliciós.

10. Acceptació de la seguretat i garantia a) Acceptació: El software de l’aplicació no es considerarà acceptat fins que el "Paquet de Certificació" estigui complet i totes les qüestions de seguretat s'hagin resolt.

b) Investigació dels problemes de seguretat: Després de l'acceptació, si es descobreixen problemes de seguretat o existeix una sospita raonable, l’adjudicatari ajudarà a UOC a dur una investigació per determinar la naturalesa de la qüestió. Els fets es consideraran una novetat.

c) Qüestions de seguretat noves: L’adjudicatari i UOC acorden dins l'àmbit d'aplicació, que hi haurà un esforç necessari per a resoldre els nous problemes de seguretat i negociaran de bona fe un acord per a realitzar les tasques necessàries per corregir-los.

Universitat Oberta de Catalunya Plec de condicions ... · pujada i baixada de fitxers i el servei a...

Documents

Transcript of Universitat Oberta de Catalunya Plec de condicions ... · pujada i baixada de fitxers i el servei a...