Tramitació online de llicències d’activitats

Títol: Autor: Data: Director: Departament: Titulació: Centre: Universitat: Tramitació online de llicències d’activitats Juan Francisco Cano Romero Gener 2012 Frederic Vilà Martí Expressió Gràfica a l'Enginyeria Projecte Final de Carrera de Enginyeria Tècnica en Informàtica de Gestió EPSEVG. Escola Politècnica Superior d'Enginyeria de Vilanova i la Geltrú Universitat Politècnica de Catalunya ÍNDEX 1 INTRODUCCIÓ - 2 - 1.1 Descripció general - 2 - 1.2 Motivació - 2 - 1.3 Objectius - 3 - 1.4 Organització de la memòria - 3 - 2 ESPECIFICACIÓ - 5 - 2.1 Situació actual - 5 - 2.2 Requeriments funcionals - 10 - 2.3 Requeriments no funcionals - 12 - 3 ANALISI I DISSENY - 13 - 3.1 Model de dades conceptual - 13 - 3.1.1 Sol·licitant ......................................................................................................................... - 14 - 3.1.2 Sol·licitud .......................................................................................................................... - 14 - 3.1.2.1 Estats .......................................................................................................................... - 14 - 3.1.3 Classificació ....................................................................................................................... - 15 - 3.1.3.1 Secció ......................................................................................................................... - 15 - 3.1.3.2 Divisió ........................................................................................................................ - 16 - 3.1.3.3 Grup ........................................................................................................................... - 16 - 3.1.4 Annex ................................................................................................................................ - 16 - 3.1.5 Activitat ............................................................................................................................. - 17 - 3.1.5.1 Subactivitat ................................................................................................................. - 17 - 3.1.6 Document........................................................................................................................... - 18 - 3.2 Model de casos d'us - 18 - 3.3 Capa de presentació - 20 - 3.4 Capa de negoci - 30 - 3.5 Capa de dades - 32 - 4 IMPLEMENTACIÓ - 35 - 4.1 Decisions - 35 - 4.2 Servidor Web - 35 - 4.2.1.1 Servidor de correu ........................................................................................................... - 37 - 4.3 Eines de desenvolupament - 37 - 4.4 Base de dades - 42 - 4.5 Seguretat - 43 - 4.5.1 HTTPS ............................................................................................................................... - 43 - 4.5.2 Registre i validació de sol·licitants ...................................................................................... - 44 - 4.5.3 Sessions ............................................................................................................................. - 44 - 4.5.4 Certificats digitals .............................................................................................................. - 45 - 5 PLANIFICACIÓ I COST - 49 - 5.1 Diagrama de Gantt - 49 - 5.2 Estimació de cost - 49 - 5.2.1 Hardware ........................................................................................................................... - 49 - 5.2.2 Software ............................................................................................................................. - 51 - 5.2.3 Recursos humans ................................................................................................................ - 51 - 6 PROVES - 53 - 6.1 Entorn de proves - 53 - 6.2 Casos de test - 53 - 6.2.1 Proves de registre - 53 - 6.2.2 Proves d‟accés .................................................................................................................... - 55 - 6.2.3 Proves de classificació ........................................................................................................ - 57 - 6.2.4 Proves en la sol·licitud de documents .................................................................................. - 59 - 7 CONCLUSIONS - 60 - 7.1 Objectius coberts - 60 - 7.2 Millores i ampliacions - 60 - 7.3 Valoració personal - 61 - 9 BIBLIOGRAFIA - 67 - 10 GLOSSARI - 70 - Tramitació online de llicències d’activitats - 2 - 1 INTRODUCCIÓ 1.1 Descripció general Aquest document detalla els passos seguits per l'autor per a la realització del projecte final de carrera d'Enginyeria Tècnica en Informàtica de Gestió cursada a l' Escola Politècnica Superior d‟Enginyeria de Vilanova i la Geltrú. La idea principal del projecte consisteix en oferir la possibilitat de tramitar de forma completament electrònica i no presencial un permís d'activitat econòmica dins de l'entorn local. L'atorgament dels permisos es fa d'acord amb el que estableix la Llei 20/2009[1] de prevenció ambiental de les activitats. En aquesta llei es detallen les normatives que caldrà seguir com a requisits en l‟aplicació web que es desenvoluparà per tal d'assegurar que aquestes activitats econòmiques no representin un perjudici per a la seguretat, la salut o la qualitat de vida de les persones i el medi. Es tracta doncs d‟un projecte altament vinculat amb la conscienciació mediambiental però que presenta a més d‟altres motivacions. 1.2 Motivació Es evident que els processos administratius de qualsevol organisme són necessaris pel seu bon funcionament. Aquests processos no són un fenomen nou, durant tota l'existència humana com a civilització ha estat necessari regular els recursos per assegurar un repartiment just entre tot un grup. La seva finalitat és diversa: deixar constància d'un acord, consultar dades anteriors arxivades, elaborar resums estadístics, etc. El gran inconvenient, però, és que aquest procés és tediós en molts casos. Tot i que la necessitat d'una burocràcia es acceptada per tothom, resulta igualment frustrant pel sol·licitant d'un recurs haver de presentar-se a una oficina, a una hora indicada, omplir papers, signar i finalment haver d'emportar-se una copia de la sol·licitud. Tot això exigeix una inversió de temps, espai i paciència que, junt amb la complexitat del procés administratiu dels grans organismes, provoca una reacció desfavorable cap als sistemes burocràtics competents, governs i administracions públiques. Es en aquest àmbit on les tecnologies de la informació poden ajudar. Com tots sabem, ja fa molts anys que molts processos administratius es poden fer via web, estalviant temps i inconveniència al sol·licitant, però fins i tot avui dia existeixen tràmits que donada la seva magnitud i complexitat acaben requerint varies visites presencials a les seus administratives. Un dels tràmits mes complexos amb que ens podem topar consisteix en la sol·licitud del permís necessari per a la posada en funcionament d‟una nova d'activitat econòmica. El volum de documents que cal aportar per al compliment de la normativa establerta, en funció de l‟activitat que es vulgui desenvolupar, fa que el tràmit resulti llarg en temps, tediós en la seva gestió i farragós en quant a la documentació. Partim doncs d'una situació inicial en la qual no s'ofereix la possibilitat d'aconseguir la llicència sense haver de fer-ho de forma presencial i havent d‟anar diversos cops presencialment a les oficines de l‟entitat competent, a més els documents que cal aportar han d'estar en molts casos en format paper. Tramitació online de llicències d’activitats - 3 - Els motius per a la realització d'un projecte que permeti realitzar el tràmit integrament des de la web són per tant evidents envers l'estalvi de temps i recursos, a mes dels beneficis obvis en quant a aspectes mediambientals. Hi ha però un motiu totalment definitiu: PER LLEI. L'ORDRE MAH/611/2010[2] té per objecte regular la tramitació electrònica dels procediments d'autorització ambiental amb declaració d'impacte ambiental i tal i com s'estableix a la pròpia Llei 20/2009, les relacions interadministratives, i les de la ciutadania amb les administracions ambientals, s'han de dur a terme amb tècniques i mitjans telemàtics, tot respectant les garanties i els requisits dictats per les normes de procediment administratiu, i afegeix que el Govern ha d'establir per reglament els sistemes de gestió i comunicació necessaris per fer efectiu l'ús dels mitjans tècnics i remoure els obstacles formals i materials que n'impedeixen o en dificulten la implantació. A la disposició final de l'ordre s‟especifica com a data d'entrada en vigor el dia 1 de juny de 2011. En el moment de realitzar aquest projecte no es coneix cap ajuntament que posi a disposició dels ciutadans els esmentats mitjans. 1.3 Objectius L'objectiu principal d'aquest projecte és desenvolupar una aplicació web que permeti al ciutadà la tramitació online amb l'administració de tota la documentació necessària per tal de desenvolupar una activitat econòmica en compliment de tots els requeriments de la Llei de prevenció i control ambiental de les activitats i per tant ajustada a l'ordre corresponent de regulació electrònica dels procediments d'autorització. És important que l‟aplicació sigui de fàcil us i el mes intuïtiva possible per a l‟usuari, un dels objectius és facilitar les coses al sol·licitant i reduir al màxim la complexitat que suposa la realització d‟un tràmit d‟aquesta envergadura. La sol·licitud d‟una llicència d‟activitats es un tràmit que depèn de l‟administració local, per tant, cada ajuntament haurà de disposar de la seva pròpia aplicació. Això ens obliga a definir una arquitectura tècnica que sigui fàcilment integrable amb qualsevol plataforma d‟administració electrònica ja existent, s‟utilitzaran per tant les eines mes comunes al desenvolupament web partint sempre de la filosofia d‟us de programari lliure i es tindran en compte els estàndards actuals en la tramitació electrònica, tals com arquitectura en diferents capes, aplicacions client-servidor, navegació segura, signatura electrònica, certificats digitals, etc. 1.4 Organització de la memòria El present document intentarà seguir aproximadament el procés de desenvolupament del software de forma cronològica, tenint en compte que les diferents etapes o funcionalitats quedaran agrupades dins del mateix apartat. El document comença exposant el per que del projecte, on s'explica la necessitat d'aquest desenvolupament en el context de la situació actual. També hem comentat el objectius finals a més d'altra informació organitzativa relativa al projecte. A continuació al capítol 2 es detalla l'etapa d'especificació del sistema. Això inclou primerament Tramitació online de llicències d’activitats - 4 - l'anàlisi de requeriments on elaborarem una llista de requeriments, funcionals i no funcionals, veurem com els requeriments queden definits en gran part per la Llei 20/2009. Seguidament, al capítol 3, realitzem un anàlisi estructural del sistema partint de l'especificació anterior i elaborem el disseny descomponent cadascú dels elements definits i establint les seves relacions. Partint del disseny elaborat, al següent capítol s'exposen les decisions presses en quant a la tecnologia utilitzada i la seva implementació en un entorn de proves. Veurem en profunditat el desenvolupament de les diferents capes que conformen el projecte. Al capítol 5 ens trobem amb capacitat per fer una planificació temporal del projecte i la corresponent estimació en cost de recursos. Al capítol 6 Un cop enllestida la implementació posarem a prova el producte elaborat, definirem una exhaustiva bateria de proves per mirar de detectar qualsevol vulnerabilitat. Per acabar, al capítol 7 es fa una valoració personal envers tot el cicle d‟elaboració de projecte i veurem les possibilitats de millora i possibles ampliacions en cas de noves necessitats. Els últims punts del document es detallen les referències bibliogràfiques i el glossari de termes. Tramitació online de llicències d’activitats - 5 - 2 ESPECIFICACIÓ L'especificació és la etapa de la enginyeria del software que permet representar els requisits que ha de satisfer el sistema d'una manera més formal que en l'etapa d'anàlisi de requisits. En aquesta etapa definirem el model amb el qual pretendrem acostar-nos al problema el màxim possible i identificar les operacions que s'han d'elaborar, entre aquests models tenim els casos d'us en els que veurem una descripció de les diferents funcionalitats que ha de tenir el sistema a desenvolupar. Per tant, determinarem els objectius i necessitats de l'usuari i concretarem fins a on volem arribar. L'anàlisi de requeriments engloba tant els requeriments funcionals que haurà de complir el software com els no funcionals. Els requeriments funcionals expliquen què ha de ser fet mitjançant la identificació de la tasca necessària, l'acció, o l'activitat que ha de ser complida. L'anàlisi de requeriments funcionals serà fet servir com a funcions del més alt nivell per a l'anàlisi funcional. Els requeriments no funcionals són requisits que especifiquen criteris que poden ser fets servir per a jutjar l'operació d'un sistema, més que comportaments específics. És a dir, són requisits que expressen restriccions sobre el conjunt de solucions possibles. Ens posarem en la pell d'un ciutadà del carrer i reproduirem tots els passos que s'han de seguir fins a aconseguir el permís necessari per a l'execució d'una nova activitat econòmica. 2.1 Situació actual Per poder entendre be els requeriments del nostre sistema és imperatiu conèixer bé com és el tràmit que estem tractant, el que en enginyeria de software traduiríem com la lògica de negoci. Per establir una nomenclatura comuna en l'àmbit del projecte, entendrem per sol·licitant la persona que gestiona el tràmit amb l'administració per tal d'obtenir un permís, entendrem per formulari les informacions que s'han d'omplir com a part de gestió del tràmit, mentre que una sol·licitud seria el conjunt de formularis i documents omplerts per un sol·licitant. Partim d'una situació inicial en la qual el sol·licitant ha de fer en el millor dels casos dos o tres viatges fins a la administració per tal d'aconseguir aportar tota la documentació necessària per formalitzar el tràmit. Donada la complexitat del procés i tenint en compte que la documentació que cal aportar varia en funció del tipus d'activitat, normalment el sol·licitant mai aconsegueix gestionar-ho tot a la primera, a més hi ha un pas final que consisteix en fer el pagament, que s'acostuma a fer en un altre moment i que pot requerir visita a la entitat bancària. Resulta evident doncs el retreball que suposa aquest esquema de funcionament. D‟altra banda la documentació requerida durant el tràmit varia en funció de l‟activitat econòmica que es vulgui iniciar. La Llei 20/2009, de 4 de desembre, de prevenció i control ambiental de les activitats, comprèn els règims bàsics d‟intervenció administrativa següents: Tramitació online de llicències d’activitats - 6 - · Autorització ambiental. · Llicència ambiental. · Règim de comunicació. La Llei estableix un sistema d‟intervenció integral, atenint-se a la major o a la menor incidència ambiental de les activitats, però limitat únicament els aspectes ambientals. La intervenció administrativa per raó d‟altres matèries, com per exemple la seguretat i la salut de les persones, es regeix per la legislació de règim local i per la normativa sectorial corresponent. 1. Règim d’Autorització Ambiental amb avaluació d’impacte ambiental L‟activitat o activitats relacionades en els annexos I.1 i I.2 se sotmeten a l‟autorització ambiental, si escau, amb l‟avaluació d‟impacte ambiental del departament competent en matèria de medi ambient. Aquestes activitats són les que més impacte ambiental poden generar, i per això són les que se sotmeten al règim d‟intervenció més estricte. Aquestes activitats es corresponen, en primer lloc, amb les que s‟inclou en la Llei 16/2002, d‟1 de juliol, de prevenció i control integrat de la contaminació. D‟altra banda, aquesta categoria recull les activitats incloses en l‟annex I del Reial decret legislatiu 1/2008, d‟11 de gener, pel qual s‟aprova el text refós de la Llei d‟avaluació d‟impacte ambiental, que són les que requereixen d‟avaluació d‟impacte en tot cas. A més a més, entre les activitats sotmeses a autorització ambiental es troben aquelles de l‟annex II del Reial decret legislatiu 1/2008 que, a Catalunya, han de ser avaluades. Aquesta Llei integra, amb una voluntat de simplificació administrativa clara, l‟avaluació de l‟impacte ambiental de les activitats en el procediment d‟atorgament de l‟autorització ambiental. A més a més, aquesta Llei estableix que en l‟autorització ambiental es fixin els valors límit d‟emissió i es considerin, si escau, les millors tècniques disponibles en cada moment. El procediment s‟inicia amb la sol·licitud de l‟autorització ambiental, que ha de fer-se davant l‟Oficina de Gestió Ambiental Unificada (OGAU) corresponent. Després d‟això, els tràmits comprenen: 1. Verificació formal de la documentació presentada. 2. Anàlisi de la suficiència i la idoneïtat del projecte, de l‟estudi d‟impacte ambiental i de la resta de documentació que ha d‟acompanyar la sol·licitud. 3. Informació pública de 30 dies i informes preceptius (ajuntament, accidents greus, etc.). Així mateix, s‟ha de sotmetre a exposició pública i informació veïnal a l‟ajuntament on s‟ubiqui l‟activitat per un període de deu dies. 4. Declaració d‟impacte ambiental i proposta de resolució provisional, que han d‟incloure una descripció succinta del projecte i de l‟estudi d‟impacte ambiental, la relació dels tràmits efectuats, la relació de les entitats, les institucions, les organitzacions i les persones que han participat en el procediment, la relació dels escrits d‟al·legacions formulades en l‟expedient i la consideració corresponent que fa la Ponència Ambiental, la descripció dels impactes significatius sobre el medi i la població apreciats per l‟òrgan que formula la declaració d‟impacte ambiental, la qualificació de l‟impacte ambiental, la recomanació sobre l‟autorització Tramitació online de llicències d’activitats - 7 - del projecte en un sentit favorable o desfavorable i les mesures correctores o compensatòries que és necessari aplicar. 5. Tràmit d‟audiència de 15 dies a l‟interessat. 6. Proposta de resolució. 7. Resolució que s‟ha de dictar en un termini màxim de deu mesos, quan correspongui a activitats de l‟annex I.1 i de vuit mesos quan correspongui a activitats de l‟annex I.2. 8. Notificació i comunicació. 9. Publicació de la declaració d‟impacte ambiental. 10. Publicació de la resolució de l‟autorització ambiental de les activitats de l‟annex I.1 La resolució de l‟expedient la dicta l‟òrgan ambiental del departament competent en matèria de medi ambient, amb el contingut establert per l‟article 29, que posa fi al procediment. Per a això, disposa d‟un termini de deu mesos per a les activitats de l‟annex I.1, i de vuit mesos per a les de l‟annex I.2. 2. Règim de llicència ambiental Són sotmeses a aquesta llicència les activitats incloses en l‟annex II de la Llei. La sol·licitud de llicència s‟ha de presentar davant l‟ajuntament corresponent, amb el contingut assenyalat en l‟article 39.2 de la Llei. A partir de llavors, la sol·licitud se sotmet als tràmits següents: 1. Verificació formal de la documentació presentada. 2. Anàlisi de la suficiència i la idoneïtat del projecte bàsic amb estudi ambiental. 3. Informació pública i veïnal, de 30 dies i 10 dies, respectivament. 4. Informes preceptius en matèria de medi ambient i de prevenció d‟incendis forestals, quan siguin necessaris, i que han de remetre‟s en un termini de màxim de 30 dies. 5. Proposta de resolució. 6. Tràmit d‟audiència a les parts per un període de 15 dies. 7. Resolució que s‟ha de dictar en un termini màxim de sis mesos. 8. Notificació i comunicació. 9. La tramitació correspon, en principi, als ajuntaments, per la qual cosa la mateixa Llei estableix el següent: - Els que tinguin 50.000 o més habitants han de constituir un òrgan tècnic ambiental amb la funció d‟avaluar les sol·licituds i els expedients de llicència ambiental i formular la proposta de resolució. Tramitació online de llicències d’activitats - 14 - Figura 3.2 – Model de dades conceptual 3.1.1 Sol·licitant El sol·licitant serà la persona interessada en realitzar una sol·licitud. Es tindrà en compte que el sol·licitant també pot ser un representant legal. En aquest cas hi haurà una referència al document corresponent. Un sol·licitant pot cursar tantes sol·licituds com vulgui. Cada sol·licitud tindrà un identificador únic i només podrà pertànyer a un sol·licitant. 3.1.2 Sol·licitud La sol·licitud es l'element principal del model. Consisteix en els elements necessaris tals que en el seu conjunt permeten formalitzar el tràmit administratiu de nova activitat econòmica. Un dels requisits de la sol·licitud consisteix classificar les activitats econòmiques dins la llei PCAA, per aquest motiu s‟enregistren la mes desfavorable de les activitats CCAE i els valors de l‟annex on queda classificat. L‟estat de la sol·licitud determina en quin punt del procés de gestió administrativa es troba el tràmit. Una sol·licitud pot tenir un únic estat en un moment donat. Els possibles estats són fixes i es detallen a continuació. 3.1.2.1 Estats L‟estat indica en quin punt del tràmit administratiu es troba una sol·licitud en un moment donat. Els possibles estats són fixes i poden fer referència a n sol·licituds. Els estats en que es pot trobar una sol3licitud són els següents: Tramitació online de llicències d’activitats - 15 - - Nou: la sol·licitud consta com enregistrada a la base de dades. - Pendent de classificació: Encara no s‟han classificat les activitats. - Pendent de documentació: Encara no s‟han adjuntat tots els documents requerits. - Pendent de pagament: La sol·licitud s‟ha complimentat correctament i es pot pagar la taxa corresponent. - Pendent de l‟Administració: La sol·licitud s‟està avaluant per part de l‟Administració competent. - Aprovat: La sol·licitud ha estat aprovada i es pot iniciar la nova activitat econòmica. - Rebutjat: La documentació aportada no compleix els requisits. - Obsolet/Vençut: La sol·licitud ha excedit el temps màxim oberta i ha estat tancada. 3.1.3 Classificació La classificació d‟una activitat per part del sol·licitant es farà seguint el criteri de l‟Idescat[3] (Institut d‟Estadística de Catalunya). Una sol·licitud només podrà tenir una activitat classificada, Ja es veurà mes endavant que a l‟hora de fer el tràmit, a la sol·licitud es podran especificar tantes activitats com calgui,però a efectes de requeriments administratius romandrà la mes desfavorable de totes, tal com s‟estableix la llei PCAA. Com podem veure al diagrama, la CCAE-2009 – Classificació catalana d‟activitats econòmiques es sub-divideix en els següents apartats: 3.1.3.1 Secció Primera diferenciació d‟activitats econòmiques CCAE-2009. A Agricultura, ramaderia, silvicultura i pesca B Indústries extractives C Indústries manufactureres D Subministrament d’energia elèctrica, gas, vapor i aire condicionat E Subministrament d’aigua; activitats de sanejament, gestió de residus i descontaminació F Construcció G Comerç a l’engròs i al detall; reparació de vehicles de motor i motocicletes H Transport i emmagatzematge I Hostaleria J Informació i comunicacions K Activitats financeres i d’assegurances L Activitats immobiliàries M Activitats professionals, científiques i tècniques N Activitats administratives i serveis auxiliars O Administració pública, Defensa i Seguretat Social obligatòria P Educació Q Activitats sanitàries i de serveis socials R Activitats artístiques, recreatives i d’entreteniment S Altres serveis T Activitats de les llars que donen ocupació a personal domèstic; activitats de les llars que produeixen béns i serveis per a ús propi U Organismes extraterritorials Tramitació online de llicències d’activitats - 16 - Taula 3.1 – Seccions CCAE-2009 3.1.3.2 Divisió Diferenciació per secció d'activitats econòmiques CCAE-2009. Mostrem a mode d'exemple la divisió corresponent a la secció Agricultura, ramaderia, silvicultura i pesca. Codi Descripció 011 Conreus no perennes 012 Conreus perennes 013 Vivers i conreus de plantes ornamentals 014 Producció ramadera 015 Producció agrícola combinada amb la producció ramadera 016 Activitats de suport a l'agricultura, ramaderia i preparació posterior a la collita 017 Caça, captura d'animals i activitats dels serveis que s'hi relacionen Taula 3.2 – Exemple de divisió CCAE-2009. 3.1.3.3 Grup Diferenciació per divisió d'activitats econòmiques CCAE-2009. Mostrem a mode d'exemple els grups corresponents a la divisió “Conreus no perennes”. Codi Descripció 0111 Conreu de cereals (excepte arròs), lleguminoses i llavors oleaginoses 0112 Conreu d'arròs 0113 Conreu d'hortalisses, arrels i tubercles 0114 Conreu de canya de sucre 0115 Conreu de tabac 0116 Conreu de plantes per a fibres tèxtils 0119 Altres conreus no perennes Taula 3.3 – Exemple de grups CCAE-2009 Cadascun dels grups es relaciona amb com a mínim amb una subactivitat. 3.1.4 Annex L'annex determinarà els diferents requisits documentals en funció de impacte ambiental d'una determinada subactivitat. Cadascun dels annexos pot tenir referència a n sol·licituds. Hi ha 4 annexos principals, algun dels quals presenta subdivisions. ANNEX I.1: Activitats sotmeses al règim d‟avaluació d‟impacte ambiental i d‟autorització ambiental, subjectes a la Directiva 96/61/CE, del Consell, del 24 de setembre de 1996, de prevenció i control integrats de la contaminació. Tramitació online de llicències d’activitats - 17 - ANNEX I.2: Activitats sotmeses al règim d‟avaluació d‟impacte ambiental i d‟autorització ambiental, no subjectes a la Directiva 96/61/CE, del Consell, del 24 de setembre de 1996, de prevenció i control integrats de la contaminació. ANNEX I.3: Activitats sotmeses al règim de declaració d‟impacte ambiental amb una autorització substantiva. ANNEX II: Activitats sotmeses al règim de llicència ambiental. ANNEX III: Activitats sotmeses al règim de comunicació. ANNEX IV: Activitats que, en el supòsit de no-subjecció al règim de llicència establert per la normativa administrativa dels espectacles públics i les activitats recreatives, resten subjectes al règim de llicència ambiental establert pel títol III d‟aquesta llei. 3.1.5 Activitat La classificació de les activitats establertes dins la llei PCAA no te en conte els criteris CCAE ja que en aquest cas es fa en funció del impacte ambientat de les activitats. Cadascuna de les activitats està conformat per un conjunt de subactivitats. El llistat d'activitats incloses a la llei és: 1 Energia 2 Mineria 3 Producció i transformació de metalls 4 Indústries minerals i de la construcció 5 Indústria química 6 Indústria tèxtil, de la pell i cuirs 7 Indústria alimentària i del tabac 8 Indústria de la fusta, del suro i de mobles 9 Indústria del paper 10 Gestió de residus 11 Activitats agroindustrials i ramaderes 12 Altres activitats Taula 3.4 – Activitats diferenciades al PCAA 3.1.5.1 Subactivitat Cada subactivitat es relaciona com a mínim amb un grup de la classificació del PCAA. A mes, cada subactivitat pot tenir diferents nivells capacitatius que determinaran el impacte ambiental i classificaran la subactivitat en un determinat annex de la llei. Mostrem a continuació a mode d‟exemple les subactivitats, amb les seves variables per annex, corresponents a l‟activitat classificada com Energia al PCAA. Tramitació online de llicències d’activitats - 18 - Figura 3.3 – Subactivitats de l’activitat Energia del PCAA 3.1.6 Document Qualsevol dels documents que es requereixen per a cadascun dels annexos corresponent. També és document l'autorització de representant legal d'un sol·licitant. 3.2 Model de casos d'us Al llarg dels següents subapartats es descriurà cada cas d'ús en termes d'anàlisi. Per tal de complementar la descripció, es comentarà la interacció de l'usuari amb el sistema i els diferents procediments interns. Es poden diferenciar dos tipus d'usuari: usuari anònim i usuari identificat. L'usuari anònim no haurà facilitat les seves dades a l'administració. Els casos d'us possibles per a l'usuari anònim són: Classificació de prova. La classificació de prova permetrà un usuari anònim tenir una visió prèvia de la documentació que li cal aportar identificant una o més activitats. Figura 3.4 – Classificació de prova Tramitació online de llicències d’activitats - 19 - Nova sol·licitud. Un usuari anònim podrà enregistrar les seves dades per donar-se d'alta com a usuari identificat. Un usuari anònim podrà fer servir un certificat digital per a validar-se com a sol·licitnat. Figura 3.5 – Identificació d’usuari L'usuari enregistrat haurà cursat una nova sol·licitud o s'haurà validat mitjançant un certificat digital. Els casos d'us possibles per a l'usuari identificat són: Tancar sessió L'usuari identificat passa a ser usuari anònim. Figura 3.6 –Finalitzar la sessió Classificació La classificació permetrà a l'usuari identificat determinar els requisits administratius segons la seva activitat econòmica i procedir a l'execució del tràmit. Tramitació online de llicències d’activitats - 20 - Figura 3.7 – Classificar una activitat Documentació L'usuari identificat aporta la documentació requerida segons la seva activitat. Figura 3.8 – Annexar un documents signat Pagament L'usuari identificat efectua el pagament de la sol·licitud. Figura 3.9 – Efectuar el pagament 3.3 Capa de presentació La capa de presentació és la que permet als sol·licitants interactuar amb el sistema, comunica únicament amb la capa de negoci i és l'encarregada de mostrar els resultats requerits pels sol·licitants així com permetre la introducció de noves dades al sistema. Tot i ser la capa de negoci l'encarregada de realitzar la majoria dels càlculs que ha d'executar el Tramitació online de llicències d’activitats - 21 - sistema, la capa de presentació s'encarrega de realitzar petits càlculs, normalment relacionats amb una primera validació de les dades inserides, però també relacionats amb l'aspecte visual del sistema. El motiu per la implementació d'aquestes verificacions es degut a que és preferible no accedir a la capa de negoci si anteriorment el sistema ha detectat errors a les dades, d'aquesta manera disminuïm la carrega del servidor ja que serà el propi navegador del client qui reporta els errors a l'usuari, a mes d'actuar com a primer filtre de seguretat. La capa de presentació mostra un menú comú en tot el sistema i 4 funcionalitats principals que mostrem amb il·lustracions comentades. Menú inicial Figura 3.11 – Menú principal Informació Mostra un primer quadre amb la informació principal a mode de resum i dos links interessants a llei PCAA i l'ordre MAH. Figura 3.11 – Informació Permet fer una simulació de la classificació de les activitats i mostra informació detallada sobre el tràmit. Tramitació online de llicències d’activitats - 22 - Figura 3.12 – Quadre de classificació L‟usuari pot consultar les taxes que haurà de pagar per realitzar el tràmit i com ho haurà de realitzar. En aquest mateix apartat hi trobem que s‟ha de considerar per definir la superfície del comerç. I per últim a la secció d‟informació i ens explica com podem identificar l‟estat del nostre tràmit. Figura 3.13 – Articles informatius Nova sol·licitud Permet que un usuari es doni d'alta a la base de dades. S‟han d‟omplir tots els camps amb (*) per poder –hi tramitar la nova sol·licitud ja que són obligatoris. Si la persona que esta tramitant la sol·licitud es el representant legal haurà d‟adjuntar un document signat digitalment pel representant tal i com indica la següent captura. Tramitació online de llicències d’activitats - 23 - Figura 3.14 – Formulari de registre Un cop omplerts tots els camps podem enviar la sol·licitud. Registre amb èxit Aquesta plana es mostra si l‟usuari ha omplert correctament una nova sol·licitud. O be ha sol·licitat un nou tràmit des de la plana de registre amb certificat. Figura 3.15 – Informació de registre Seguidament rebrem al correu electrònic amb el nou codi d‟expedient: Tramitació online de llicències d’activitats - 30 - Figura 3.21 – Estat del tràmit: Denegat Obsolet/Vençut I per últim si el representant no adjunta tota d‟informació en un termini de 3 mesos haurà de tornar a obrir una sol·licitud nova ja que l‟anterior haurà caducat. Figura 3.21 – Estat del tràmit: Denegat D‟aquest punt es dedueix que les sol·licitud enregistraran la data en que han estat donades d‟alta. El control de la caducitat de les sol·licituds es farà des de la capa de dades. 3.4 Capa de negoci La capa de negoci és la encarregada de realitzar els càlculs sol·licitats per els usuaris mitjançant la capa de presentació, accedint a la capa de base de dades i retornant els valors corresponents a la capa de presentació. Tramitació online de llicències d’activitats - 31 - Aquesta capa també s'encarrega de passar les noves dades introduïdes pels sol·licitants en alguna de les funcionalitats d'alta o validació d'usuaris i sol·licituds, quedant aquesta informació quedarà enregistrada a la capa de dades. Per tal de dur a terme el negoci d'una manera ordenada s'ha decidit dividir el codi depenent de la funcionalitat requerida, o be de les entitats accedides a la capa de dades. - REGISTRE Contindrà els mètodes per enregistrar un nou sol·licitant i/o sol·licitud. Registre d'usuaris i creació de nou expedient. - VALIDACIÓ Seran procediments ne cesaris per identificar un sol·licitant al sistema. Sessió d'usuari i estat del tràmit. - CLASSIFICACIÓ Contindrà les funcions necessàries per classificar les activitats segons CCAE dins de la llei PCAA. Classificació IdesCat Classificació segons la Llei 20/2009 El mètode que s‟ha seguit per relacionar totes les activitats de la classificació CCAE consistirà en fer un recorregut dels diferents grups establint primer quina seria la seva activitat PCAA corresponent i després quina seria la seva subactivitat corresponent. Un cop fet aquest recorregut es fa el recorregut sobre el llistat de subactivitats PCAA que han quedat sense relacionar i es procedeix de forma anàloga establint la seva correspondència dins la classificació CCAE. D‟aquesta manera ens assegurem que cap de les subactivitats classificades en funció del seu impacte ambiental es queda sense classificar. - DOCUMENTACIÓ Són els procediments de requeriments i registre dels documents administratius relatius a una sol·licitud. - PAGAMENT S'encarrega del procés necessari per efectuar el pagament d'una llicència. S‟establirà una connexió amb el sistema de pagament PAYPAL per abonar la taxa corresponent. PayPal és una empresa nord-americana, propietat d'eBay, pertanyent al sector del comerç electrònic per Internet que permet la transferència de diners entre usuaris que tinguin correu electrònic, una alternativa al tradicional mètode en paper com els xecs o girs postals. PayPal també processa peticions de pagament en comerç electrònic i altres serveis webs, pels quals cobra un percentatge. Tramitació online de llicències d’activitats - 32 - - ESTATS És el mètode de validació i assignació d'estats en que es pot trobar una sol·licitud. De la classificació anterior ja es dedueix que per poder transferir les dades obtenides a la capa de dades, realitzar els càlculs necessaris i enviar els resultats a la capa de presentació farem servir objectes de transferència de dades que es definirem com a classes que contindran els atributs necessaris. La capa de negoci s'encarregarà per tant d'instanciar aquestes classes amb els atributs d'entrada i sortida i aplicar els mètodes necessaris per actualitzar les capes de presentació i dades. 3.5 Capa de dades La capa de dades del nostre projecte està formada per l'esquema de base de dades de l'aplicació web. A partir del model conceptual dissenyat a l'apartat 3.1 es crea el model físic per al nostre sistema gestor de base de dades. Descriurem l'estructura de la base de dades mitjançant el seu esquema, però abanshem d'elaborar el diagrama de classes del domini que tractarem. Diagrama de classes El diagrama resultant de tots els conceptes que tractarem és el presentat a la següent figura. Taula 3.5.1 Esquema inicial de relacions Tramitació online de llicències d’activitats - 33 - A continuació comentarem els punts més importants del diagrama que reflexen diferents decisions de disseny que anirem comentant a continuació. ESQUEMA A partir del diagrama de classes anterior realitzarem les transformacions necessàries per obtenir un esquema d'una base de dades utilitzant patrons coneguts. La classe principal de l'esquema és la sol·licitud. Com a detall important cal destacar que a més del clàssic identificador de sol·licitud guarda encriptat el codi de sol·licitud que s'envia al sol·licitant i te com a referència l'identificador del sol·licitant. La sol·licitud contindrà un camp que enregistrarà en quina fase es troba el tràmit. Taula 3.5.2 – Relació sol·licitant  sol3licitud La sol·licitud a mes, tindrà referenciades totes les claus requerides per identificació i seguiment d'un expedient. Veiem com els elements de relació necessaris són l‟identificador del grup i la subactivitat corresponent que dependrà de la classificació que s'hagi fet de la activitat econòmica. Taula 3.5.3 – Relació sol·licitud  grup / subactivitat Tramitació online de llicències d’activitats - 34 - A més de l'identificador per trobar els documents annexats corresponent a una sol·licitud determinada. Taula 3.5.4 – Relació sol·licitud  documents Eliminem de l'esquema els documents PDF propiament dits, ja que decidim separar aquests de la base de dades. S'ha decidit separar els documents PDF de la base de dades per diverses raons: D'entrada els documents PDF poden ser bastant grans i com es veurà a les proves el rendiment d'entrada/sortida és millor si són emmagatzemats directament a disc. D'aquesta manera, a més, lliurem a la base de dades de càrrega de treball, que necessita per servir altra informació. A més s'ha de tenir en compte que per possibilitar l'escalabilitat o implementació a altres sistemes (recordem que estem implementant un tràmit gestionat per l'administració local) convé tenir els elements els mes aïllats possibles de manera que la portabilitat es simplifica. El magatzem de documents pot ser un recurs o carpeta compartida de fàcil accés per part del personal administratiu. L‟altre punt a destacar de les relacions de la sol·licitud és la corresponent a l‟estat del tràmit, que com hem vist a la capa de negoci determinarà en quin estat es troba el tràmit en cada moment donat. Taula3.5.5 – Relació sol·licitud  estats Tramitació online de llicències d’activitats - 35 - 4 IMPLEMENTACIÓ En aquest capítol detallem el procés d'implementació del projecte. En general, l'objectiu d'aquesta fase consisteix en la programació pròpiament dita del codi necessari per obtenir els resultats a partir del disseny proposat anteriorment. Tot i comptar amb un bon disseny, a la fase d‟implementació sempre ens podem trobar amb inconvenients derivats de les limitacions de les tecnologies utilitzades. 4.1 Decisions Partint disseny de l‟arquitectura de tres capes que hem vist al capítol anterior i basant-nos en la filosofia del software lliure i la possibilitat de fer l'aplicació el mes escalable, modular i exportable possible s'ha optat per implementar un servidor web amb capacitat per a la interpretació de codi PHP[4] i suport SSL per a la seguretat i gestió de certificats. També ha calgut instal·lar i configurar un servidor de correu i integrar-lo amb el servidor Web per l'enviament automàtic de correus electrònics durant el registre d'usuaris i noves sol·licituds. En quant a la implementació hardware proveïda per al desenvolupament i proves de l'aplicació web ha estat una màquina amb les següents característiques: Processador i memòria: Processador Intel(R) Core(TM)2 Duo CPU P7350 @ 2.00GHz 3GB memòria RAM. L1 Cache 32K, L2 Cache 3MB. Xarxa: Connexió LAN Wifi Connexio WAN 30Mb amb IP dinàmica. En quant al sistema operatiu s‟ha optat per una distribució Ubuntu Linux[5] 10.04 (Lucid Lynx) LTS (Long Term Support) de 64bits. 4.2 Servidor Web Un servidor web és un programa dissenyat per interpretar hipertext, pàgines web, HTML, text enriquit, gràfics, música, vídeos, etc. y presentar-ho a un navegador mitjançant el protocol HTTP pertanyent a la capa d'aplicació del model OSI. Tenint en compte les nostres necessitats optarem per un servidor web compatible amb el llenguatge de programació PHP y la base de dades MySQL[6]. Un altre punt clau a l'hora d'escollir un navegador Web es la seguretat, el navegador web ha de suportar navegació segura HTTPS. A més, s'ha de tenir en compte el cost. Utilitzarem el servidor web Apache[7], el més extés arreu del món, amb capacitat de suportar mòduls SSL i optimitzat per al lleguatge PHP amb base de dades MySQL, de lliure distribució i codi obert. Tramitació online de llicències d’activitats - 36 - 4.2.1 Apache Web Server El servidor HTTP Apache és un servidor HTTP de codi obert per a plataformes Unix (BSD, GNU / Linux, etc.), Windows, Mac i altres, que implementa el protocol HTTP/1.11 i la noció de lloc virtual. Quan va començar el seu desenvolupament el 1995 es va basar inicialment en codi del popular NCSA HTTPd 1.3, però més tard va ser reescrit per complet. El seu nom es deu al fet que Behelendorf va triar aquest nom perquè volia que tingués la connotació d'alguna cosa que és ferma i enèrgic però no agressiu, i la tribu Apache va ser l'última a rendir-se al que aviat es convertiria en govern dels EUA, i en aquests moments la preocupació del seu grup era que arribessin les empreses i "civilitzat" el paisatge que havien creat els primers enginyers d'Internet. A més Apache consistia només en un conjunt de pegats a aplicar al servidor de NCSA. Era, en anglès, a patchy Server (un servidor "parxejat"). El servidor Apache es desenvolupa dins del projecte HTTP Server (httpd) de l'Apache Software Foundation. Apache presenta entre altres característiques missatges d'error altament configurables, bases de dades d'autenticació i negociat de contingut, però va ser criticat per la manca d'una interfície gràfica que ajudi en la seva configuració. Apache té àmplia acceptació a la xarxa: des de 1996, Apache, és el servidor HTTP més usat. Va aconseguir la seva màxima quota de mercat el 2005 sent el servidor emprat en el 70% dels llocs web al món, però ha patit un descens en la seva quota de mercat en els últims anys. La majoria de les vulnerabilitats de la seguretat descobertes i resoltes tan sols poden ser aprofitades per usuaris locals i no remotament. No obstant això, algunes es poden accionar remotament en certes situacions, o explotar pels usuaris locals malèvols en les disposicions de rebuda compartides que utilitzen PHP com a mòdul d'Apache. Destacarem les següents característiques: · És multiplataforma, encara que idealment està preparat per funcionar sota Linux. · Molt senzill de configurar. · És Open-source. · Molt útil per a proveïdors de Serveis d'Internet que requereixin milers de llocs petits amb pàgines estàtiques. · Ampliar llibreries de PHP i Perl a disposició dels programadors. · Posseeix diversos mòduls que permeten incorporar noves funcionalitats, aquests són molt simples de carregar. Com la seguretat SSL. · És capaç d'utilitzar llenguatges com PHP, TCL, Python, etc. El servidor Apache és un programari que està estructurat en mòduls. La configuració de cada mòdul es fa mitjançant la configuració de les directives que estan contingudes dins del mòdul. Per a la navegació segura, s'ha hagut de crear un certificat autosignat per estalviar-nos el cost que suposa demanar un certificat emes per alguna entitat certificadora reconeguda per els principals navegadors. L‟únic inconvenient que comporta aquesta mesura es que si no s‟afegeix el nostre domini com a entitat coneguda apareix un molest missatge quan es fa navegació HTTPS indicant que el certificat del servidor no es de confiança. Com que l'aplicació web ha d'enviar correus electrònics als sol·licitants, el nostre servidor web ha de tenir configurada la integració amb un servidor de correu. Tramitació online de llicències d’activitats - 37 - 4.2.1.1 Servidor de correu Un servidor de correu (en anglès mail transfer agent - MTA) és una aplicació informàtica que permet enviar missatges (correus electrònics) d'uns usuaris a altres, amb independència de la xarxa que aquests usuaris estiguin utilitzant. Entre els més usats hi ha Postfix, sendmail i Exim. Aquest últim predeterminat a GNU / Linux Debian. El terme servidor de correu també és utilitzat en el sentit d'un equip que actua com un MTA que està executant el programari apropiat. El terme commutador de correu (mail exchanger), en el context del DNS es refereix a una adreça IP assignada a un dispositiu que allotja un servidor de correu, i, per extensió, també indica el propi servidor. Postfix és un servidor de correu de programari llibre i codi obert per l'enrutament i enviament de correu electrònic, creat amb la intenció que sigui una alternativa més ràpida, fàcil d'administrar i segura al àmpliament utilitzat Sendmail. Anteriorment conegut com VMailer i IBM Secure Mailer, va ser originalment escrit per Wietse Venema durant la seva estada a l'Thomas J. Watson Research Center d'IBM, i continua sent desenvolupat activament. Postfix és l'MTA inclòs per defecte a la distribució Ubuntu Linux. Al nostre cas configurarem el servidor de correu Postfix perquè actui com a reenviador automàtic de correu de tal manera que els correus electrònics s'enviin desde un compte de correu electrònic autenticat i gratuït. Es farà servir un conte de correu de Gmail. 4.3 Eines de desenvolupament Seguint amb la filosofia de fer servir eines estàndards, gratuïtes i lliures , Farem servir PHP com a llenguatge de programació principal per la carrega i enviament contingut dinàmic (capa de negoci). PHP és un llenguatge de programació interpretat, dissenyat originalment per a la creació de pàgines web dinàmiques. S'usa principalment per a la interpretació del costat del servidor (server-side scripting) però actualment pot ser utilitzat des d'una interfície de línia d'ordres o en la creació d'altres tipus de programes incloent aplicacions amb interfície gràfica usant les biblioteques Qt o GTK +. PHP és un acrònim recursiu que significa PHP Hypertext Pre-processor (inicialment PHP Tools, o, Personal Home Page Tools). Va ser creat originalment per Rasmus Lerdorf el 1994, però la implementació principal de PHP és produïda ara per The PHP Group i serveix com l'estàndard de facto per a PHP al no haver-hi una especificació formal. Publicat sota la PHP License, la Free Software Foundation considera aquesta llicència com a programari lliure. Pot ser desplegat en la majoria dels servidors web i en gairebé tots els sistemes operatius i plataformes sense cap cost. El llenguatge PHP es troba instal · lat en més de 20 milions de llocs web i en un milió de servidors, el nombre de llocs en PHP ha compartit una mica del seu preponderant domini amb altres nous llenguatges no tan poderosos des d'agost de 2005. És també el mòdul d‟Apache més popular entre els ordinadors que utilitzen Apache com a servidor web. La gran semblança que posseeix PHP amb els llenguatges més comuns de programació estructurada, com C i Perl, permeten a la majoria dels programadors crear aplicacions Tramitació online de llicències d’activitats - 38 - complexes amb una corba d'aprenentatge molt curta. També els permet involucrar-se amb aplicacions de contingut dinàmic sense haver d'aprendre tot un nou grup de funcions. Encara que tot en el seu disseny està orientat a facilitar la creació de llocs web, és possible crear aplicacions amb una interfície gràfica per a l'usuari, utilitzant l'extensió PHP-Qt o PHP-GTK. També pot ser usat des de la línia d'ordres, de la mateixa manera com Perl o Python poden ferho, a aquesta versió de PHP la hi crida PHP-CLI (Command Line Interface). Quan el client fa una petició al servidor per enviar-vos una pàgina web, el servidor executa l'intèrpret de PHP. Aquest processa el script sol·licitat que generarà el contingut de manera dinàmica (per exemple obtenint informació d'una base de dades). El resultat és enviat per l'intèrpret al servidor, qui al seu torn l'hi envia al client. Mitjançant extensions és també possible la generació d'arxius PDF, Flash, així com imatges en diferents formats. Permet la connexió a diferents tipus de servidors de bases de dades tals com MySQL, que serà la que ens ocupa en el nostre cas. PHP també té la capacitat de ser executat en la majoria dels sistemes operatius, com ara Unix (i d'aquest tipus, com Linux o Mac OS X) i Microsoft Windows, i pot interactuar amb els servidors de web més populars ja que existeix en versió CGI, mòdul per a Apache, i ISAPI. PHP és una alternativa a les tecnologies de Microsoft ASP i ASP.NET (que utilitza C # i Visual Basic. NET com a llenguatges), a ColdFusion de l'empresa Adobe, a JSP / Java ja CGI / Perl. Treballem en tot moment amb objectes, tindrem el codi de les funcions en fitxers separats i privatitzarem les funcions que no hagin de ser instanciades. Veiem un exemple: Al formulari de registre d‟un usuari (capa de presentació) veiem que les dades s‟envien al programa login.php (capa d‟aplicació): <form action="login.php" method="POST"> <tr> <td><font face="Verdana" size="2" color="#000000"> DNI/NIF/NIE*: </td> <td><font face="Verdana" size="2" color="#000000"> <input type="text" name="id_solicitant" size="9"> </td> </tr> <tr> <td><font face="Verdana" size="2" color="#000000"> Codi d'expedient*: </td> <td><font face="Verdana" size="2" color="#000000"> <input type="text" name="codi" size="12" > </td> </tr> <tr> <td><font face="Verdana" size="2" color="#000000"> <input type="submit" name="submit" value="Continuar..."> </td> Tramitació online de llicències d’activitats - 39 - </tr> </form> Codi simple de registre d’un nou usuari. include("login.class.php"); $login=new login(); $login->inicia(3600, $_POST['id_solicitant'], md5($_POST['codi'])); Codi del programa login.php Com podem veure s‟instancia la variable login cridant la funció “inicia” que estarà inclosa a la classe "login.class.php" La classe "login.class.php" contindrà els mètodes que fan el registre. class login { // Inicia sessio public function inicia($tiempo=3600, $dni=NULL, $codi=NULL) { include('config.php'); if ($dni==NULL && $codi==NULL) { // Verifica sesion if (isset($_SESSION['dni'])) { //echo "Estas logeado"; header( "Location: expedient.php" ); } else { // Verifica cookie if (isset($_COOKIE['codi'])) { // Restaura sesion $_SESSION['dni']=$_COOKIE['codi']; } else { // Si no hay sesion regresa al login header( "Location: index.php" ); } } } else { $this->verifica_usuari($temps, $dni, $codi, $db_con); } } // Verifica login private function verifica_usuari($temps, $dni, $codi, $db_con) { //if ($dni=="user" && $codi=="password") { if ( $this->esdni( $dni, $codi, $db_con) ) { // Si la clave es correcta //$codi=$this->codificar($codi); setcookie("codi", $codi, time()+$temps); $_SESSION['codi']=$codi; $_SESSION['dni']=$dni; header( "Location: expedient.php" ); } else { // Si la clave es incorrecta header( "Location: continua.php?error=1" ); Tramitació online de llicències d’activitats - 46 - <VirtualHost *:443> ServerName activitat.dyndns.info ... SSLEngine On SSLCertificateFile /etc/ssl/private/server.pem SSLCertificateKeyFile /etc/ssl/private/server.key SSLCACertificateFile /etc/ssl/private/CA-certs.crt SSLCACertificatePath /etc/ssl/certs </VirtualHost>]]> Configuració del mòdul ssl d’Apache amb autoritats certificadores. A continuació mostrem la funció utilitzada per a la verificació del certificat digital utilitzat, bàsicament, aquesta funció consulta les variables d‟entorn o s‟emmagatzema l‟ informació de les entitats autoritzadores configurades i la compara amb el certificat rebut, a mes com es pot veure es fa una doble comparació: public function hasValidCert() { if (!isset($_SERVER[„SSL_CLIENT_M_SERIAL‟]) || !isset($_SERVER[„SSL_CLIENT_V_END‟]) || !isset($_SERVER[„SSL_CLIENT_VERIFY‟]) || $_SERVER[„SSL_CLIENT_VERIFY‟] !== „SUCCESS‟ || !isset($_SERVER[„SSL_CLIENT_I_DN‟]) ) { return false; } if ($_SERVER[„SSL_CLIENT_V_REMAIN‟] <= 0) { return false; } return true; } CodiPHP de verificació de certificats digitals Tramitació online de llicències d’activitats - 47 - I per a la identificació del client (o persona que es valida) es llangueixen les variables SSL_CLIENT_M_SERIAL i SSL_CLIENT_I_DN sense necessitat d'emmagatzemar-los, i per tant tenint en compte un cop més els aspectes de seguretat. Els certificats vàlids són els emesos per les principals entitats certificadores a nivell autonòmic i estatal: L'Agència Catalana de Certificació neix l'any 2002 com a organisme autònom sota l'empara del Consorci Administració Oberta de Catalunya. El seu objectiu és proporcionar a les administracions catalanes els instruments necessaris perquè les transaccions electròniques tinguin totes les garanties jurídiques i vetllar perquè el procés del desplegament de la signatura electrònica a l‟administració sigui el més planer possible. Les noves tecnologies han fet possible la transacció de serveis en línia. Les administracions catalanes volem aplicar aquestes tecnologies a les relacions interadministratives i entre administració i ciutadà. Això ens permet oferir-vos un servei millor i més àgil, alhora que suposa una iniciativa innovadora en el sector públic. En primer lloc cal regular el marc jurídic general i establir la validesa dels documents i de les comunicacions telemàtiques. L'ús de certificats reconeguts permetrà garantir la identitat de les parts implicades. També la confidencialitat, la integritat i el no rebuig dels documents i gestions realitzades. El conjunt de serveis ofert per l'Agència Catalana de Certificació conforma el sistema públic català de certificació. La "Fàbrica Nacional de Moneda i Timbre" mitjançant el projecte CERES (Certificació Espanyola) estableix una Entitat Pública de Certificació, que permet autenticar i garantir la confidencialitat de les comunicacions entre ciutadans, empreses o altres institucions i administracions públiques a través de les xarxes obertes de comunicació. Les possibilitats de CERES cobreixen totes aquelles relacions entre les diferents administracions (central, autonòmica i local) i els ciutadans que necessitin ser securitzades en termes de garantia d'identitat, confidencialitat i integritat, amb l'objectiu que CERES faciliti al màxim les seves relacions a través de les noves xarxes de comunicacions. Tramitació online de llicències d’activitats - 48 - L'objectiu principal de CERES és la securització de les comunicacions electròniques amb l'Administració, sent un intermediari transparent a l'usuari que garantirà a ciutadans i administracions la identitat d'ambdós partícips en una comunicació, així com la confidencialitat i integritat del missatge enviat. Per això, CERES utilitza tècniques i sistemes criptogràfics basats en el que es coneix com a sistema de clau pública, amb dues característiques bàsiques: La identitat de l'usuari, igual que la seva capacitat de signatura, es troba, en el cas de màxima seguretat, emmagatzemada en una targeta intel · ligent, que no pot ser accessible excepte pel seu propietari quan introdueixi el número d'identificació personal, semblant a la clau d'una targeta de crèdit. En cas de no utilitzar targeta, el perfil criptogràfic queda emmagatzemat en un fitxer, és necessari també un PIN d'accés. El sistema és completament transparent a l'usuari, és a dir, no cal conèixer cap tècnica criptogràfica per realitzar o verificar una signatura electrònica o xifrar o desxifrar un missatge. El Document Nacional d'Identitat (DNI), emès per la Direcció General de la Policia (Ministeri de l'Interior), és el document que acredita, des de fa més de 50 anys, la identitat, les dades personals que hi apareixen i la nacionalitat espanyola del seu titular. Al llarg de la seva vida, el Document Nacional d'Identitat ha anat evolucionat i incorporant les innovacions tecnològiques disponibles en cada moment, per tal d'augmentar tant la seguretat del document com el seu àmbit d'aplicació. Amb l'arribada de la Societat de la Informació i la generalització de l'ús d'Internet es fa necessari adequar els mecanismes d'acreditació de la personalitat a la nova realitat i disposar d'un instrument eficaç que traslladi al món digital les mateixes certeses amb què operem cada dia en el món físic i que, essencialment, són: Acreditar electrònicament i de forma indubtable la identitat de la persona Signar digitalment documents electrònics, atorgant-los una validesa jurídica equivalent a la que els proporciona la signatura manuscrita Per respondre a aquestes noves necessitats neix el Document Nacional d'Identitat electrònic (DNIe), similar al tradicional i la principal novetat és que incorpora un petit circuit integrat (xip), capaç de guardar de manera segura informació i de processar internament. Tramitació online de llicències d’activitats - 49 - 5 PLANIFICACIÓ I COST 5.1 Diagrama de Gantt A continuació es presenta el diagrama de Gantt amb el desglasament i duració de les diferents tasques que s‟han dut a terme per a la realització del projecte. Taula 5.1 – Diagrama de Gantt 5.2 Estimació de cost Com veurem mes detalladament a cadascun dels propers apartats, el cost total d'implantació i manteniment de l'aplicació web tindrà una part fixa i una part variable. La part fixa correspondrà principalment al cost de recursos humans per al desenvolupament del software, mentre que la part variable, calculada per un any de duració vindrà donada per la capacitat hardware contractada amb el proveïdor de serveis. 5.2.1 Hardware Donat el model de tres capes determinat per aquest projecte, podem deduir que les capes de negoci i dades del nostre sistema necessitaran ser hostatjades en dos elements hardware independents. En el nostre cas el que creem és una nova funcionalitat per als serveis de tràmits virtuals oferts per l'administració, normalment l'entitat corresponent ja disposarà d'altres servidors que proveeixen la resta de serveis. Caldria doncs integrar la nostra aplicació amb la infraestructura ja existent, tot analitzant si el sistema actual pot suportar el increment de càrrega. Tramitació online de llicències d’activitats - 50 - Avui dia, amb les eines de vitalització les tasques d'estudi de capacitats, i ampliació de sistemes han facilitat molt la vida tant als tècnics com als comercials de vendes, que acostumen a fer les seves ofertes en base al benchmark de transaccions distribuïdes TPC-C[17], la mesura de rendiment s‟expressa en tpmC (transaccions per minut), normalment escalada per mil i comunament anomenada ktpmc. Basant-nos en la funcionalitat que s'ofereix deduïm que la potència hardware requerida per al seu funcionament òptim no cal que sigui gens gran, entenem que en una determinada entitat local no es donarà el cas que centenars, ni tan sols desenes de persones tramitin llicències d'activitats de forma concurrent. A més, l'espai necessari per a l‟emmagatzemament de dades es factura en GigaBytes proveïts, en el nostre cas, cal tenir en conte l'espai necessari per guardar gran quantitat de documents i la capacitat requerida per afegir i suportar un nou esquema de base de dades que realment tindrà una ocupació de pocs MegaBytes. Consultant una empresa proveïdora de serveis del sector ens informen que la oferta mínima estipula una potència de 2 ktpmcs i 32Gb de disc, mesures que assumiran sobradament les nostres necessitats. Revisant la taula del benchmark TPC i posant com a exemple d‟implementació en un sistema virtual implantant en un servidor de prestacions mitjanes obtenim un cost variable l‟any: Capa de negoci: Capacitat de processament : 2 ktpmcs * 2000 € = 4000€ Capacitat d‟emmagatzemament: 32GB * 24 € = 768€ Capa de dades: Capacitat de processament : 2 ktpmcs * 2000 € = 4000€ Capacitat d‟emmagatzemament: 32GB * 24 € = 768€ TOTAL VARIABLE: 4000 + 768 + 4000 + 768 = 9536€ / any Taula 5.2 – Cost Hardware Tramitació online de llicències d’activitats - 51 - 5.2.2 Software Un dels punts importants que considerarem en aquest projecte és la utilització de software lliure i de codi obert, que a més facilitarà la migració i integració de l'aplicació cap a qualsevol entorn. Tot i això per a entorns productius es altament recomanable disposar de contractes de suport per obtenir l'ajuda d'un especialista en cas de problemes greus o desastres. Al nostre cas, com que l'aplicació s'integra amb un entorn ja funcional aquest cost be assolit pel sistema ja existent. 5.2.3 Recursos humans Per calcular el cost del recursos humans utilitzats en aquest projecte desglossarem la participació humana real (una persona) en diversos rols als que assignarem un sou per hora i un cert pes. A la taula 5.3 podem veure el desglossament en hores dedicades per cadascun dels rols. A continuació ens basarem en la planificació inicial mostrada al diagrama de Gantt per tal d‟establir el cost total a partir de les hores de participació al projecte per als diferents rols. Fase Rol Sou per hora Especicacio Cap de projecte 40 euros Analisi Analista 30 euros Disseny Arquitecte 40 euros Implementacio Programador 25 euros Proves Equip de proves 20 euros Taula 5.3 – Fase, rol i sou I segons el següent repartiment d‟hores: Taula 5.4 – Diagrama de Gannt, hores per tasca Tramitació online de llicències d’activitats - 52 - Obtenim com a resultat: --------------- ------------- ----- Cap de projecte: 24h * 40€ = 960€ Analista : 16h * 30€ = 480€ Arquitecte : 72h * 40€ = 2880€ Programador : 200h * 25€ = 5000€ --------------- ------------- ----- TOTAL FIX..... : .......... = 9320€ --------------- ------------- ----- Taula 5.5 – Cost de desenvolupament Tramitació online de llicències d’activitats - 53 - 6 PROVES 6.1 Entorn de proves Per tal de tenir un entorn de proves pròxim a la realitat hem contractat un domini gratuït a Internet amb un proveïdor de serveis que suporta IPs dinàmiques i hem configurat el nostre sistema operatiu amb un programa que s‟encarrega d‟actualitzar la IP dinàmica a la banda del proveïdor i el nostre servidor web amb el domini contractat. D‟aquesta manera aconseguim que l‟aplicació web es trobi en tot moment disponible accedint a la URL: http://activitat.dyndns.info DynDNS (Dynamic Network Services, Inc) és una companyia d'Internet dels Estats Units d'Amèrica dedicada a solucions de DNS en adreces IP dinàmiques. Ofereix serveis gratuïts de redirecció a IP de subdominis d'una gran llista de noms disponibles, oferint a particulars l'oportunitat de crear un servidor a Internet gratuïtament amb adreces del seu sub-domini, de manera que s'ha fet molt popular a la cultura Do It Yourself (Fes-ho Tu Mateix). L‟assignació ha de ser actualitzada mitjançant algun procés a la màquina del client, com ara el que la mateixa companyia ofereix o altres, encara que els routers actuals solen incloure funcions d'actualització de la IP en aquest tipus de serveis, per la qual que, un cop configurat el router, l'actualització de la IP es converteix en un procés totalment invisible per l'usuari ja que és el mateix router el que s'encarrega d'actualitzar la IP quan aquesta canvia. Ddclient[15] és un client de Perl que s'utilitza per actualitzar les entrades de DNS dinàmic als comptes gratuïts que ofereixen serveis de xarxa DNS. Va ser escrit originalment per Paul Burry i ara és mantingut per desenvolupadors a SourceForge. Té la capacitat d'actualitzar més que dyndns i pot portar el seu WAN IP address de diferents maneres. És un client petit però complet que només requereix Perl i cap mòdul addicional. Funciona com un dimoni i permet configuracions per actualitzacions manuals i automàtiques, actualitzacions estàtiques i dinàmiques, actualitzacions optimitzades per a múltiples adreces MX, tornar a intentar les actualitzacions fallides, i l'enviament d'estat de l'actualització a través de syslog i correu electrònic. Ddclient s‟ofereix com a software opcional amb les distribucions d‟Ubuntu Linux. 6.2 Casos de test En aquest apartat descriurem una sèrie de casos de test (test cases), que serveixen per comprovar el bon funcionament del sistema. Aquests estaran dividits en actors i altres àrees, i finalment realitzarem uns casos de test més avançats on provarem detalls més subtils, com possibles problemes de seguretat. 6.2.1 Proves de registre Registrar un nou expedient (correcte) Tramitació online de llicències d’activitats - 54 - Descripció: Registrar un nou sol·licitant introduint dades d'identificació correctes. Resultat esperat: Ha d'enviar-se un correu electrònic amb el codi d'expedient al sol·licitant Resultat obtingut: Correcte Figura 6.1 – Credencials correctes Registrar un nou expedient (incorrecte) Descripció: Registrar un nou sol·licitant introduint un NIF incorrecte. Resultat esperat: Ha de mostrar-se un missatge d'error de credencials invàlides. Resultat obtingut: Correcte Figura 6.2 – Credencials incorrectes Registrar un nou expedient (incorrecte) Descripció: Registrar un nou expedient deixant buït algun dels camps obligatoris. Resultat esperat: Ha de mostrar-se un missatge d'error de camps obligatoris. Resultat obtingut: Correcte Figura 6.3 – Resultat de camps obligatoris sense emplenar Registrar un nou expedient amb certificat digital (correcte) Descripció: Registrar un nou expedient per mitja d'un certificat d'identificació digital. Resultat esperat: Ha d'enviar-se un correu electrònic amb el codi d'expedient al sol·licitant Resultat obtingut: Correcte Tramitació online de llicències d’activitats - 55 - Figura 6.4 – Resultat de registrar un nou expedients identificats amb certificat digital Registrar un nou expedient amb certificat digital (incorrecte) Descripció: Registrar un nou expedient deixant buït algun dels camps obligatoris. Resultat esperat: Ha de mostrar-se un missatge d'error de camps obligatoris. Resultat obtingut: Correcte Figura 6.5 – Resultat de prova d’enregistrar un nou expedient identificats amb certificat digital deixant buit el camp de adreça electrònica 6.2.2 Proves d’accés Accedir mitjançant un NIF (correcte) Descripció: Accés a un expedient amb autenticació per mitja del NIF del sol·licitant. Resultat esperat: Ha de donar accés a l'expedient corresponent amb l'usuari autenticat. Resultat: Correcte Figura 6.6 – Resultat d’accés amb NIF Accedir mitjançant un NIF (incorrecte) Descripció: Accés a un expedient amb autenticació per mitja d'un NIF de sol·licitant incorrecte. Resultat esperat: La web no ha de donar accés i ha de sortir un missatge d'error de credencials invalides. Resultat: Correcte Tramitació online de llicències d’activitats - 62 - 8 AGRAÏMENTS Als meus pares per motivar-me sempre a estudiar. A la meva dona per recolzar-me en tot moment, per proporcionar-me tot el temps i la llibertat que he necessitat per treballar i per ajudar-me en tot el que li he demanat. Sense tu no hagués estat possible. Al tutor del projecte, per la seva orientació i disponibilitat, per confiar en mi per aquest projecte i donar-me una segona oportunitat. A tota la gent que ha provat la web i ajudat en les correccions. Tramitació online de llicències d’activitats - 63 - 9 BIBLIOGRAFIA [1] LLEI 20/2009, del 4 de desembre, de prevenció i control ambiental de les activitats. http://www.gencat.cat/diari/5524/09336035.htm http://www20.gencat.cat/portal/site/mediambient http://www.girona.cat/mediambient/cat/activitats.php [2] ORDRE MAH/611/2010, de tramitació electrònica dels procediments d'intervenció administrativa d'activitats. http://www.gencat.cat/diari/5786/10355169.htm [3] Classificació Catalana d‟Activitats Econòmiques. http://www.idescat.cat/Classif/?TC=4&V0=1&V1=87 [4] PHP Hypertext Pre-processor http://php.net [5] Ubuntu Linux 10.04.3 LTS http://releases.ubuntu.com/lucid/ [6] MySQL database http://dev.mysql.com [7] Apache Web Server http://apache.org [8] Postfix MTA http://www.postfix.org [9] CSS. Cascading Style Sheets http://www.w3.org/Style/CSS/ [10] HTML5: http://www.w3.org/TR/html5/ [11] JQuery: http://jquery.com/ [12] Uploadify http://www.uploadify.com/ [13]Kompozer http://kompozer.net/ [14] DynDNS http://www.dyndns.com [15] ddclient http://sourceforge.net/apps/trac/ddclient [16] Ubuntu Linux http://www.ubuntu.com/ Tramitació online de llicències d’activitats - 64 - [17] Benchmark de transaccions distribuïdes TPC-C http://www.tpc.org/tpcc/ [18] Guia d‟estils UPC http://www2.upc.edu/slt/gl/glp3.pdf [19] Ubuntu i DynDNS https://help.ubuntu.com/community/DynamicDNS [20] W3 Consortium http://www.w3.org [21] Apache Module mod_ssl http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#envvars [22] Using SSL Client Certificates with PHP http://cweiske.de/tagebuch/ssl-client-certificates.htm#enablestd-envvars [23] Certificats digitals http://www.fnmt.es http://www.catcert.cat http://www.dnielectronico.es/ Tramitació online de llicències d’activitats - 65 - 10 GLOSSARI BSD: Berkeley Software Distribution C: El mes famós llenguatge de programació. CCAE: Classificació Catalana d‟Activitats Econòmiques. Cookie: trossos de dades arbitraris definits pel servidor web i enviats al navegador. ddclient. Client de DNS dinàmic DNS: Domain Name Server Framework: estructura conceptual i tecnològica de suport definit GMAIL: Gestor de correu gratuït ofert per Google. Google: Realment cal dir alguna cosa? GNU: GNU is Not Unix (acronym recursiu). Moviment i comunitat del programari i Coneixement Lliures HTML: Hypertext markup language. HTTP: HyperText Transfer Protocol Idescat: Institut d‟Estadística de Catalunya JavaScript: Llenguatge de programació interpretat LAMP: Linux – Apache – MySQL - PHP LTS: Long Term Support MTA: Mail Transfer Agent OGAU: Oficina de Gestió Ambiental Unificada. Oracle: El més famòs (i car) sistema gestor de base de dades. OSI: Open Systems Interconnection (Model). PAYPAL: Empresa nord-americana, propietat d'eBay, pertanyent al sector del comerç electrònic per Internet que permet la transferència de diners. PCAA: Pla de Control d‟Activitats Ambientals. PDF: Portable Document Format Perl: Practical Extracting Report Language. PHP: Acrònim recursiu que significa PHP Hypertext Pre-processor (inicialment PHP Tools, o, Personal Home Page Tools). Python: interpretat, interactiu i orientat a objectes, llenguatge de programació extensible. Sourceforge: Directori d‟aplicacions de codi obert. SSL: Secure Socket Layer Sun Microsystems: Empresa informàtica adquirida per Oracle. Syslog: Logs del sistema. TCL: Tool Command Language Tramitació online de llicències d’activitats - 66 - tpmC: La mesura del bechmark TPC-C UNIX: Sistema operatiu portable, multitasca i multiusuari W3C: World Wide Web Consortium WAMP: Windows – Apache – MySQL - PHP XHTML: eXtensible HyperText Markup Language