UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T....

51
UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura Grupo Simbiosis Carlos Andrés Arango Jorge Eduardo Garzón Daniel Andrés Penagos Daniel Camilo Ramírez Julio 28, 2008

Transcript of UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T....

Page 1: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

UNIVERSIDADDELOSANDES

ProyectoR.U.N.T.DefinicióndeDocumentode

Arquitectura

GrupoSimbiosisCarlosAndrésArangoJorgeEduardoGarzónDanielAndrésPenagosDanielCamiloRamírez

Julio28,2008

Page 2: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

2

TabladeContenido

ListadeFiguras ....................................................................................................................................5

ListadeTablas......................................................................................................................................6

ControldeVersión..............................................................................................................................7

Contexto ..................................................................................................................................................8

ProblemasaResolver...................................................................................................................8

Objetivos ............................................................................................................................................9

FundamentodelaSolución........................................................................................................9

PuntosCríticosdelSistema...................................................................................................9

AproximacionesArquitecturales.......................................................................................... 10

Stakeholders....................................................................................................................................... 12

PuntosdeVista.................................................................................................................................. 19

PuntodeVistadeDespliegue................................................................................................. 19

Descripción ............................................................................................................................... 19

ModelodePlataformadeEjecución............................................................................... 20

ModelodeRed ......................................................................................................................... 22

ModelodeDependenciaTecnológica ............................................................................ 23

PuntodeVistaFuncional ......................................................................................................... 24

Descripción ............................................................................................................................... 24

ModelodeEstructuraFuncional...................................................................................... 27

PuntodeVistadeDesempeño ............................................................................................... 29

Descripción ............................................................................................................................... 29

ModelodeDesempeño......................................................................................................... 30

PuntodeVistadeInformación .............................................................................................. 31

Descripción ............................................................................................................................... 31

ModeloEstáticodeDatos.................................................................................................... 32

Page 3: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

3

ModeloDinámicodeDatos ................................................................................................ 33

EscenariosdeCalidad .................................................................................................................... 37

EscenariodeDesempeño......................................................................................................... 37

Descripción ............................................................................................................................... 37

Fuente.......................................................................................................................................... 37

Estímulo...................................................................................................................................... 37

Artefacto..................................................................................................................................... 37

Respuesta................................................................................................................................... 37

Medida......................................................................................................................................... 37

Perspectivas ....................................................................................................................................... 38

PerspectivadeSeguridad ........................................................................................................ 38

Descripción ............................................................................................................................... 38

Aplicabilidad............................................................................................................................. 38

Actividades................................................................................................................................ 39

ContextodeSeguridad ......................................................................................................... 39

RiesgosdelNegocio............................................................................................................... 39

RiesgosTécnicos..................................................................................................................... 40

AnálisisdelRiesgoyCasosdeAbuso............................................................................. 40

TácticasArquitecturales...................................................................................................... 44

PosiblesProblemas................................................................................................................ 45

ListadeChequeo..................................................................................................................... 46

PerspectivadeUsabilidad ....................................................................................................... 46

Aplicabilidad............................................................................................................................. 46

Concerns..................................................................................................................................... 47

Actividades................................................................................................................................ 47

TácticasArquitecturales...................................................................................................... 47

Problemas.................................................................................................................................. 48

ListadeChequeo..................................................................................................................... 48

GlosariodeTérminos ................................................................................................................ 50

Page 4: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

4

Acrónimos ...................................................................................................................................... 51

ReferenciasBibliográficas............................................................................................................ 51

Page 5: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

5

ListadeFiguras

Figura1.DiagramaGeneraldeArquitecturadelSistema.

Figura2.ModelodePlataformadeEjecución.

Figura3.ModelodeRed.

Figura4.ModeloEstructuraFuncional–VistaGeneral.

Figura5.ModelodeEstructuraFuncional–AutorizadorCentral.

Figura6.ModelodeEstructuraFuncional–ComponenteAuditoría.

Figura7.ModelodeDesempeñodelSistema.

Figura8.ModeloEstáticodeDatos.

Figura9.ModeloDinámicodeDatos–ModelodeReplicacióndeDatos.

Figura10.ModeloDinámicodeDatos–IntegracióndeDatos(EntidadConductor).

Figura11.ModeloDinámicodeDatos–IntegracióndeDatos(EntidadLicenciadeTránsito).

Figura12.ModeloDinámicodeDatos–IntegracióndeDatos(VinculaciónconServiciosExternos).

Page 6: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

6

ListadeTablas

Tabla1.ListadodelosStakeholders

Tabla2.StakeholdersyConcerns

Tabla3.ModelodeDependenciaTecnológica.

Tabla4.Impactodelaperspectivadeseguridadenlospuntosdevista.

Tabla5.Descripcióndelosrecursossensiblesdelsistema.

Tabla6.Actoresdelsistemaysucontrolsobrerecursossensibles.

Tabla7.ÁrboldeAtaques.

Page 7: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

7

ControldeVersión

Versión ModificadoPor Fecha Comentarios

1.0 CarlosAndrésArango

DanielCamiloRamírez

6‐Jun‐2008 Lineamientosgeneralesdeldocumento.

1.1 CarlosAndrésArango

JorgeEduardoGarzón

DanielCamiloRamírez

DanielAndrésPenagos

3‐Jul‐2008 Definiciónglobaldearquitectura

PuntosdeVista

1.2 CarlosAndrésArango

JorgeEduardoGarzón

DanielCamiloRamírez

DanielAndrésPenagos

6‐Jul‐2008 EscenariodeDesempeño

1.3 JorgeEduardoGarzón

DanielCamiloRamírez

17‐Jul‐08 PuntodeVistadeInformación

PuntodeVistadeConcurrencia

1.4 JorgeEduardoGarzón

DanielCamiloRamírez

19‐Jul‐08 PuntodeVistadeDesempeño

1.5 JorgeEduardoGarzón

DanielCamiloRamírez

23‐Jul‐08 PerspectivadeSeguridad

1.6 JorgeEduardoGarzón 26‐Jul‐08 PerspectivadeUsabilidad

1.7 DanielCamiloRamírez 27‐Jul‐08 ComplementodelaPerspectivadeSeguridad.

Page 8: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

8

Contexto

ProblemasaResolver

El MINISTERIO DE TRANSPORTE tiene como objetivo primordial la formulación yadopciónde laspolíticas,planes,programas,proyectosy regulacióneconómicaenmateria de transporte, tránsito e infraestructura de los modos de transportecarretero, marítimo, fluvial, férreo y aéreo y la regulación técnica en materia detransporte y tránsitode losmodos carretero,marítimo, fluvial, férreoyaéreoy laregulación técnica en materia de transporte y tránsito de los modos carretero,marítimo,fluvialyférreo.

Dentro de los servicios ofrecidos por el MINISTERIO, se ha visto la necesidad demantenerunsistemadeinformaciónquepermitacentralizar,manejarypermitirelaccesoconcurrenteatodoslosactoresdelsistemadistribuidosalolargoyanchodelterritorionacional.

Coneldesarrollodeestesistemadeinformación,sepretendealcanzar:

• Centralizar la información relacionada con el registro, trámites y diferentesserviciosqueofreceelMINISTERIODETRANSPORTE.

• Validación, autorización y registro de las transacciones resultados de lostrámitesdetránsitoytransporteefectuadosporlosOrganismosdeTránsito,Direcciones Territoriales delMinisterio y oficina central delMINISTERIODETRANSPORTE.

• ControlyseguimientodelrecaudodelasespeciesvenalesydelasTarifas.

• Validar la consistencia de la información incorporada y detectarinconsistencias.

• Asignar automáticamente los rangos de las especies venales, dados por losOrganismos de Tránsito, Direcciones Territoriales del Ministerio y oficinacentraldelMINISTERIODETRANSPORTE.

• Brindarserviciosdeinformaciónalciudadanoconrespectoalosregistroscontenidosenelsistemadeinformacióncentralizada.

• Atenderlasquejas,sugerenciasyreclamosdelosusuariosdelosserviciosofrecidosporlosOrganismosdeTránsito,DireccionesTerritorialesdelMinisterioyoficinacentraldelMINISTERIODETRANSPORTE.

• IntegracióndeserviciosdevalidaciónyautorizacióndelosregistrosconlosOtrosActoresdelsistema.

ElRUNTesunsistemadeinformaciónquepermiteregistrarymanteneractualizada,centralizada, autorizada y validada la misma sobre los registros de automotores,

Page 9: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

9

conductores, licencias de tránsito, empresas de transporte público, infractores,accidentesdetránsito,seguros,remolquesysemirremolques,maquinaríaagrícolayde construcción autopropulsada y de personas naturales o jurídicas que prestanservicioalsector.

Objetivos

1. Implementar una solución que permitamanejar los datos de conductores,licencias, automotores, accidentes, maquinaria, empresas de transporte,infracciones, centros de enseñanza automovilística, seguros y personasnaturales o jurídicas que prestan servicios al sector público; de maneracentralizada,confiableysegura.

2. Facilitarlacolaboraciónentreestasáreas,permitiendounamejorintegracióndeserviciosofrecidos,reduciendocostosygenerandounainfraestructuradecrecimientodelMINISTERIO.

3. Proveer una interfaz común para las reglas y procesos del negociorelacionados.

4. Proponer una aproximación arquitectural que sirva de base para proveerestosserviciosteniendoencuentalospuntoscríticosidentificados.

FundamentodelaSolución

PuntosCríticosdelSistema

Se encontraron los siguientes puntos críticos, que pueden orientar la arquitecturadelsistema:

1. Necesidaddevalidarlainformacióncapturadaatravésdelsistemaydetectarincoherencias.

2. Incorporar y centralizar la información relevante a los registros necesarios,actualmente presentes y la necesidad de fácilmente acoplar informacióndadaporfuturosactoresdelsistema.

3. Consultaenlínea.

4. Escalabilidaddelsistemaatodoelterritorionacional.

5. Altovolumendesolicitudesconcurrentesytransacciones.

6. Altadisponibilidaddelsistema(7/24).

7. Los tiempos de respuesta del sistemadeben sermenores a 3 segundos entodoelterritorionacionalymenoresa1segundodentrodelcascourbanodeBogotá.

Page 10: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

10

8. Necesidaddebrindarserviciosdeatenciónalciudadanoatravésdeunportalúnico.

9. Manejar un alto grado de seguridad para todo el sistema, que incluyeautenticaciónyautorización,ciframientodelainformación,etiquetadodelosdatosysusorígenes,validacióndetransaccionesygeneraciónderegistrosdeauditoría.

10. Alta tolerancia a fallos, permitiendo que ante cualquier eventualidad elsistemapuedaseguirenfuncionamientoyrecuperarsedelafalla.

11. Proveer una herramienta de control y seguimiento de todos los procesos,constituyendo un motor de administración de procesos (BPM, BusinessProcessManagement,porsussiglaseninglés).

AproximacionesArquitecturalesLa arquitectura propuesta contempla la resolución de los puntos críticosmencionadosanteriormente,delasiguienteforma:

Page 11: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

11

Figura1.DiagramaGeneraldeArquitecturadelSistema.

Page 12: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

12

1. Todos los actores del sistema se conectarán a través de un cliente ligeroutilizandoInternetyaccesosdedicadoscomomediodecomunicación.

2. Todas las conexiones serán filtradas y validadas por un hardwareespecializado(Firewall).

3. Para escenarios en los que se requiera autorización de credenciales deactoresdelsistema,validacióndetransacciones,asícomoproteccióndelosdatos y validación de etiquetas de datos se cuenta con un clúster deservidoresdeautenticaciónqueproveeránesteservicio.

4. Toda la información y peticiones se direccionarán con la ayuda debalanceadores de carga que permitan mantener distribuida la carga detrabajo,enlosservidoresWebydeaplicaciones.

5. ExistiráunclústerdeServidoresWebqueseráelencargadodeatender lassolicitudesdelportaldelsistema.

6. Se proveerá un clúster de Servidores de Aplicaciones que se encargará demanejarlosprocesosdenegocio,ejecutaractividadesytareasespecíficasdecadaproceso.

7. Paraelmanejodebasededatossecuentaconunclústerdeservidores loscuales se encargarán de mantener réplicas lógicas de la información, asícomolaintegracióndelosdatos(DataWarehousing).

8. Se implementaráunaarquitecturaque contemplepersistenciade losdatosquegarantizará recuperaciónante fallasalmantenerunsistemadearreglodediscosdealtarecuperabilidadyreplicacióndedatos.

9. Esta arquitectura siguiendo los requerimientos del MINISTERIO, seimplementará paralelamente en otra ubicación física con todas suscaracterísticas, para proveer una solución de alta disponibilidad yrecuperabilidadantefallos.

Stakeholders

Se refiere a una persona con un interés en una determinada situación, acción oproceso, enmarcado en el ambiente de las reglas y procesos de una compañía.Referentealaarquitectura,cadastakeholderrepresentaunaentidadconuninterésespecífico en distintos puntos de la arquitectura, basándose en un grupo derequerimientos,aspiracionesointencionesparaelsistema.

Losstakeholdersidentificadosson:

Page 13: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

13

Tabla3: ListadodelosStakeholders

Stakeholder Descripción

MinistrodeTransporte Cabezaadministrativadelministeriodetransporte.

MinisteriodeTransporte Partefuncionaldelgobiernodedicadaespecíficamentealaregulaciónynormatividadrelacionadaconlamovilidadyeltransporte.

SecretaríaMunicipaldeTránsito Administracióndetránsitolocalfueradeláreaurbana(especialmentefueradeBogotá).

SecretaríaDistritaldeTránsito Administracióndetránsitolocaldeláreaurbana.

SecretaríaDepartamentaldeTránsito Administracióndetránsitolocalaniveldepartamental.

AutoridaddeTránsitoDesignada Administracióndetránsitolocalenáreasdistantesusualmenterurales,dondenohayadministracionesmunicipalesdesignadas.

PolicíaNacional(PolicíadeCarreteras) Fuerzadeseguridadencargadadevelarporelmantenimientodelordenpúblicoylaseguridaddelosciudadanosysometidaalasórdenesdelasautoridadespolíticas.

Propietariodeautomotor Personanaturalojurídicapropietariadeunbienautomotor.

Conductor Personaquedirigeunvehículoautomotor.

Empresadetransporte Organismosocialintegradoporelementoshumanos,técnicosymaterialescuyoobjetivoprincipaleslaprestacióndeserviciosdemovilidadalpúblicoengeneraloaotrasorganizaciones.

Centrodeenseñanza(automotriz) Organizacióneducativacuyoobjetivoeslaprestacióndeserviciosparaelintercambiodeconocimientosrelacionadosconlaconducciónyaspectosautomotrices.

Centrodereconocimientoautomotriz Espaciofísicoyorganizacióndedicadaalaevaluación,diagnósticoyasignacióndecalificacionesestándarparalosautomotores.

CentrodediagnósticoautomotorEspaciofísicoyorganizacióndedicadaaldiagnósticoinicialdelosvehículosautomotores.

Propietarioderemolquey/osemirremolque

Personanaturalojurídicapropietariadeunvehículodecargadearrastre.

Propietariodemaquinariaagrícolay/oconstrucciónautopropulsada

Personanaturalojurídicapropietariadeunvehículodeutilidadagrícola.

Personaqueprestaalgúnserviciodetransito

Personanaturalqueofreceserviciosvariadosrelacionadosconautomotoresymovilidad.

Page 14: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

14

Stakeholder Descripción

Personaqueprestaalgúnservicioaunorganismodetransito

Personanaturalqueofreceserviciosaalgunaorganizaciónespecializadaentránsito.

ImportadorPersonanaturalojurídicadedicadaaltransportedebienesyserviciosdesdeotropaís,provinciauotrapartedelmundo,parasuconsumoalinteriordelpaís.

EnsambladoraOrganizacióndedicadaalacoplamientodemateriasprimassuministradasconelfindeproducirelementostecnológicosfinales,enestecaso,automotores.

FederaciónColombianadeMunicipiosPersonajurídicasinánimodelucro,denaturalezaasociativa,dondepertenecenporderechopropiotodoslosmunicipios,distritosyasociacionesdemunicipiosdetodoelpaís.

CompañíaaseguradoraEmpresadedicadaalaprestacióndeserviciosdeaseguramientoapersonasnaturalesojurídicas.

DesarrolladorRecursohumanodebaseinformáticoqueconceptualiza,diseñaeimplementasolucionesaplicativasenlenguajesdeprogramacióninformáticos.

Analistadedominio

Personaencargadadelanálisisylevantamientoderequerimientosymodelamientodeprocesosenunproblemacentradoensoftware,desdeelpuntodevistadelmodelodelnegocio.

DiseñadordesoftwarePersonaencargadadelanálisisyeldiseñodesoftwareorientadoaundominiodeunproblemaespecífico.

DiseñadordeinterfazWebPersonaencargadadeldiseñoycreacióndeinterfacesdeusuariodesplegadasatravésdeWeb.

ArquitectodetecnologíaPersonainvolucradaenlaplaneaciónyeldiseñodealtoniveldeunsistemadebaseinformática.

TesterPersonadedicadaalarealizacióndepruebasdiseñadasparaevaluaratributosdecalidaddeunsistemadesoftware.

ConsultordeQA(QualityAssurance)Profesionalqueproveedeconsejoexpertoenproblemasorganizacionalesquedependandelaseguramientodelacalidad.

ProveedordetecnologíaPersonanaturalojurídicaqueabasteceaotrasorganizacionesdebienesdebasetecnológica.

Auditor

Personacapacitadayexperimentadaquesedesignaporunaautoridadcompetente,pararevisar,examinaryevaluarlosresultadosdelagestiónadministrativayfinancieradeunadependenciaoentidad.

OperadordesistemafinalPersonaquerepresentaunusuariodeldominiodeunsistemainformáticoespecífico.

Cada stakeholder tieneungrupode concerns (intereses) endistintospuntosde laarquitectura.Paraelanálisisdelasoluciónaestosintereses,seplanteanpuntosdevistaparacadastakeholder,señaladosacontinuación:

Page 15: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

15

Tabla4: StakeholdersyConcerns

Stakeholder Concerns

MinistrodeTransporte ‐ Administracióndeprocesos.

‐ Generacióndereporteseindicadoresgeneralessobrelosprocesos.

MinisteriodeTransporte ‐ Administracióndeprocesos.

‐ Generacióndereporteseindicadoresgeneralessobrelosprocesos.

‐ Atencióndelaspeticionesdelosclientes,conelapoyodeunabasededatos.

‐ Altadisponibilidaddelsistema.

‐ Tiemposderespuestarápidos.

‐ Mantenibilidaddelsistema.

‐ Escalabilidadhorizontaldelsistema.

‐ Mantenimientoeintegracióndedatoscentrales(DataWarehouse).

‐ Tamañopromediodelosdatos.

‐ Costototaleinversión.

‐ Tiempodeejecucióndelproyecto.

‐ Satisfaccióndelasexpectativasdelproyecto.

SecretaríaMunicipaldeTránsito

- Registroytransaccionesdedatos.

- Búsquedayconsultadelosdatos.

- Validacióndetransacciones.

- Deteccióndeinconsistencias.

- Generacióndereportes.

SecretaríaDistritaldeTránsito

- Registroytransaccionesdedatos.

- Búsquedayconsultadelosdatos.

- Validacióndetransacciones.

- Deteccióndeinconsistencias.

- Generacióndereportes.

SecretaríaDepartamentaldeTránsito

- Registroytransaccionesdedatos.

- Búsquedayconsultadelosdatos.

Page 16: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

16

Stakeholder Concerns

- Validacióndetransacciones.

- Deteccióndeinconsistencias.

- Generacióndereportes.

AutoridaddeTránsitoDesignada

- Registroytransaccionesdedatos.

- Búsquedayconsultadelosdatos.

- Validacióndetransacciones.

- Deteccióndeinconsistencias.

- Generacióndereportes.

Policíanacional(Policíadecarreteras) - Registrodedatosdeincidentes.

- Búsquedayconsultadedatosenlosregistrosestablecidos.

Propietariodeautomotor- Búsquedayconsultadedatosenlosregistrosestablecidos.

Conductor- Búsquedayconsultadedatosenlosregistrosestablecidos.

Empresadetransporte- Búsquedayconsultadedatosenlosregistrosestablecidos.

Centrodeenseñanza(automotriz) - Búsquedayconsultadedatosenlosregistrosestablecidos.

Centrodereconocimientoautomotriz - Búsquedayconsultadedatosenlosregistrosestablecidos.

- Registrodediagnósticosdeautomotores.

- Validacióndedatosdeautomotores.

Centrodediagnósticoautomotor

- Búsquedayconsultadedatosenlosregistrosestablecidos.

- Registrodediagnósticosdeautomotores.

- Validacióndedatosdeautomotores.

Propietarioderemolquey/osemirremolque

- Búsquedayconsultadedatosenlosregistrosestablecidos.

Propietariodemaquinariaagrícolay/oconstrucciónautopropulsada

- Búsquedayconsultadedatosenlosregistrosestablecidos.

Page 17: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

17

Stakeholder Concerns

Personaqueprestaalgúnserviciodetransito

- Búsquedayconsultadedatosenlosregistrosestablecidos.

Personaqueprestaalgúnservicioaunorganismodetransito

- Búsquedayconsultadedatosenlosregistrosestablecidos.

Importador - Búsquedayconsultadedatosenlosregistrosestablecidos.

Ensambladora - Búsquedayconsultadedatosenlosregistrosestablecidos.

FederaciónColombianadeMunicipios

- Búsquedayconsultadedatosenlosregistrosestablecidos.

Compañíaaseguradora - Búsquedayconsultadedatosenlosregistrosestablecidos.

Desarrollador- Complejidaddeloscomponentes.

- Alcancedelosmódulosycomponentes.

Analistadedominio

- Complejidaddeloscomponentes.

- Alcancedelosmódulosycomponentes.

- Altadisponibilidaddelsistema.

- Tiemposderespuestarápidos.

- Mantenibilidaddelsistema.

- Escalabilidadhorizontaldelsistema.

- Mantenimientoeintegracióndedatoscentrales(DataWarehouse).

Diseñadordesoftware- Complejidaddeloscomponentes.

- Alcancedelosmódulosycomponentes.

DiseñadordeinterfazWeb

- Usabilidadpercibidadelsistema.

- Complejidaddeloscomponentes.

- Alcancedelosmódulosycomponentes.

Arquitectodetecnología

- Altadisponibilidaddelsistema.

- Tiemposderespuestarápidos.

- Mantenibilidaddelsistema.

Page 18: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

18

Stakeholder Concerns

- Escalabilidadhorizontaldelsistema.

- Mantenimientoeintegracióndedatoscentrales(DataWarehouse).

- Costototaleinversión.

Tester- Complejidaddeloscomponentes.

- Alcancedelosmódulosycomponentes.

ConsultordeQA(QualityAssurance)

- Complejidaddeloscomponentes.

- Alcancedelosmódulosycomponentes.

- Altadisponibilidaddelsistema.

- Tiemposderespuestarápidos.

- Mantenibilidaddelsistema.

- Escalabilidadhorizontaldelsistema.

- Mantenimientoeintegracióndedatoscentrales(DataWarehouse).

- Seguridadesperadadelsistema.

- Usabilidadpercibidadelsistema.

Proveedordetecnología - Costototaleinversión.

Auditor

- Complejidaddeloscomponentes.

- Alcancedelosmódulosycomponentes.

- Altadisponibilidaddelsistema.

- Tiemposderespuestarápidos.

- Mantenibilidaddelsistema.

- Escalabilidadhorizontaldelsistema.

- Mantenimientoeintegracióndedatoscentrales(DataWarehouse).

- Seguridadesperadadelsistema.

- Usabilidadpercibidadelsistema.

- Costototaleinversión.

Operadordesistemafinal - Búsquedayconsultadedatosenlosregistrosestablecidos.

Page 19: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

19

PuntosdeVista

PuntodeVistadeDespliegue

DescripciónEste punto de vista nos muestra el sistema y sus relaciones físicas entrecomponentes, así como los elementos de software presentes en tiempo deejecución.

Page 20: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

20

ModelodePlataformadeEjecución

Figura2.ModelodePlataformadeEjecución.

Page 21: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

21

El diagrama demuestra los artefactos de hardware requeridos para validar laarquitectura.SeproveeunnododeserviciosWeb,quepermitiráofrecerlosserviciosexpuestosporelsistemaparacadaunodelossistemasderegistro.Estenodoseráindependienteparaasegurarlamantenibilidadyextensibilidad.ExistiráunnododeServidoresWeb, quemantendrán los componentes necesarios para los elementosconstituyentes de los portales únicos de atención a través de Internet, siendo elportal principal y el portal de trámites. Estos dos nodos se apoyarán sobre unservidor de aplicaciones quemantendrá los elementos quemanejan la lógica delnegocio, incluyendo el manejo de los servicios ofrecidos y la funcionalidad deAdministracióndeProcesos(BPM–BusinessProcessManagement).Sobreestenodotambiéncorreráncomponentesdeauditoríayautorizacióndelosservicios.Se contará con un nodo de Generación de Reportes, corriendo sobre un servidoraparte,quepermita la integraciónde los reportesdeauditoría.Estopermitiráquelosdatosdeauditoríapuedanseraccedidosindependientementeysemantenganencasodefalla.Existirá un servidor de Autenticación, que permitirá validar, autenticar y detectarinconsistencias además de administrar las sesiones de cada actor conectado alsistema.FinalmentesecuentaconunnododeServidordeBasedeDatosquemantendrálalógicadelmanejodedatosysuintegración,asícomolareplicacióndeestados.

Page 22: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

22

ModelodeRed

Figura3.ModelodeRed.

Page 23: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

23

Elmodeloderedrepresentaladistribuciónfísicadelosdiferentescomponentesdelasoluciónencadaunadelasmáquinasqueseencargarándeejecutarlos.Comoseaprecia,esnecesariosepararyespecializarlascargasdetrabajodecadaequipoconel finde incrementar laeficienciaen laoperaciónyproveerunmodelo fácilmenteescalable.

ModelodeDependenciaTecnológica

Tabla3.ModelodeDependenciaTecnológica.

Componente RequiereFirewall JuniperNetworksSSG550

• VPN• Intrusionpreventionsystem(IPS)• Antivirus• Antispam• Packetspersecond(64byte):

600,000• Sesionesconcurrentes:256,000• Userauthentication(LDAP

integration)ServidorWeb IBMSystemx3455

• S.O.:RedhatEnterpriseLinux5Server

• JBossPortalEditiono JSFo EJB3

• JDK6Servidordeaplicaciones IBMSystemx3455

• S.O.:RedhatEnterpriseLinux5Server

• JBossApplicationServero jBPMo Hibernate

• JDK6ServidordeAutenticación IBMSystemx3455

• S.O.:RedhatEnterpriseLinux5Server

• RedhatDirectoryServerServidordebasededatos IBMSystemx3455

• S.O.:RedhatEnterpriseLinux5Server

• OracleDababase11gEnterpriseEdition

o RealApplicationcluster

Page 24: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

24

o Managementpacko Warehousebuildero OLAPo Datamining

SAN EMCCLARiiONAX4• iSCSI• SASySATA3GB/s• Hasta60TB• RAID1/0,RAID3,RAID5• MontajeenRack

VozIP IBMSystemx3455• CentOS5.0• TrixboxPro

PuntodeVistaFuncionalEste punto de vista describe la capacidad funcional del sistema, incluyendo lasresponsabilidades,interfaceseinteracciones.

DescripciónEl modelo de estructura funcional, representado por el siguiente diagrama decomponentes, consta de diferentes grupos de componentes agrupados en 4paquetesprincipales.

• ComponentedePortalWebEstecomponenteconsisteen lacapadepresentacióndelportalpúblicodelRUNT,consisteenpaginasJSF(JSP,HTMLyBackingBeans),ésteportalestáabiertoalpublicoengeneralyseaccedeatravésdeinternet.

• ComponentedePortaldeTrámitesEste componente consiste en la capa de presentación de del portal detrámitesdelRUNT,consisteenpaginasJSF(JSP,HTMLyBackingBeans),ésteportalestárestringidoausuariosconcredencialesválidasyparateneraccesoa las funcionalidades ofrecidas allí el usuario debe estar debidamenteautenticadoytenerlosprivilegiosparasuacceso.

• ComponentedeServiciosR.U.N.T.Este componente es la puerta de acceso al sistema RUNT, desde allí seofrecerán todas las funcionalidades tanto públicas como privadas(restringidas)queofreceráelRUNT.Seráelúnicoencargadode interactuarconelcomponentePortaldeTrámitesyPortalWeb(comousuariosexternos)yloscomponentesfuncionalesinternosdelsistema.

Page 25: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

25

• ComponentedeBPMNEste componente será el orquestador de procesos que hacen parte de lacadenadevalordelnegocio(enestecasoelRUNT).Estecomponenteesdevital importancia ya que interactuará tanto con Servicios RUNT como contodoslosprocesos,subprocesosytareasqueconformanlaaplicación.

• ComponentedeAutorizador

Este componente provee la funcionalidad relevante a la autorización detrámites, control de recaudo, control de facturación y validación de lainformación.ElautorizadorespiezafundamentaldelsistemaRUNTyaquelagranmayoríadeprocesose informacióndeéstos, tienenque servalidadosantesdepoder continuar su ciclodeoperación. Los siguientes son los sub‐componentesdelautorizador:

o Componente de Trámites: Este componente contiene toda lafuncionalidadrelacionadaconlostrámitesofrecidosporelministeriode transporte en la aplicación RUNT. Las interfaces ofrecidas son:IAutomotor, IAccidente, ICentroEnseñanza, ICentroReconocimiento,IConductor, IEmpresasTransporte, IInfraccion, ILicencia,IMaquinariaAgricola, IRemolques, ISeguros. Cada una de estasinterfaces representa las entidades claves del RUNT y expone losmétodos que representan las posibles operaciones que se puedanrealizarsobrecadaunadeellas;comosonRegistrar,Editar,Invalidar(borrar),yConsultar.

o ComponenteControladorRecaudo:Estecomponenteeselencargadoderegistrarycontrolarelrecaudoreportadoporbancosyentidadesfinancierasporconceptodepagosdetrámites,pagodemultas,pagodecertificacionesdelministerio,etc.

o Componente ControladorFacturación: Este componente se encargadecontrolar la facturacióngeneradaporelsistema,estafacturaciónpuede provenir de diversas fuentes tales como infracciones, pagosporregistrodecualquiertipodelicencia,etc.

o ComponenteValidadorInformación:Este componente se encarga deinteractuarconentidadesinternas(otroscomponentes)y/oexternas(registro y control) para validar la veracidad y precisión de lainformación proveída por los diferentes procesos dentro del RUNT.Provee 2 interfaces, IValidarInfoTramiteSimple la cual se usa paravalidar la información de un proceso a la vez yIValidasInformacionActualelcualseusaparavalidarperiódicamentelainformacióngeneraldelsistema(suestadodeconsistenciaactual).

• ComponentedeSeguridad

Estecomponenteprovee toda la funcionalidad relacionadaconseguridadaniveldesoftware:

Page 26: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

26

o Componente Detector de Intrusos: componente externo encargadode vigilar y monitorear la actividad de la red y su interacción conactoresexternos.

o Componente de Administración de Sesiones: componente externoencargado de administrar las sesiones de usuario bajo reglas biendefinidas (validacióndeclaves, singlesign‐on,niveldeacceso,horasdeoperación,etc.).

o Componente de Validador de Permisos: componente encargado devalidardadounusuario,superfilysuidentificadorvalidodesesiónaque funciones y/o procesos tiene acceso y su nivel de acceso a lainformaciónrelevanteaéste.

• ComponentedeAuditoríaComponente encargado de registrar eventos generados por procesospertenecientes al RUNT, estos eventos los puede registrar cualquiercomponente dentro del sistema y son eventos tanto a nivel de lógica denegociocomodeseguridad.Tambiénofreceinterfacesparapermitirlalecturadeestosregistros.

• ComponenteDataWarehouseReportComponente encargado de la generación de reportes de gestión, tantooperativos como de proyección de escenarios según información histórica(DataMining)usandocomofuentedeestoslosdatosobtenidosenoperación.

• ComponenteAnalizadordeArchivosComponenteencargadodeanalizarcualquier tipodearchivoenviadoporyhacia actores externos del sistema, se encarga de validar que los archivosseanconsistentesyquecumplanesquemaspredefinidos,elformatodedatosquesesugiereutilizaresXMLy lavalidacióndeconsistenciaparaestecasoconsisteenvalidarqueelXMLcumpleconunXSD.

• ComponentedeComunicaciónEste componente reúne la funcionalidad relacionada con la comunicaciónentrelosdiferentesactoresdelsistema,proveecomponentesdechat,emailyunBlackboardencargadodemostrarypublicar losanunciosdentrode laorganización.

• ComponenteContactCenterEste componente reúne la funcionalidad relacionada con el Contact CenterdelRUNT,permite registrarquejasy sugerencias radicadaspor losusuariosdel sistema. Hacer seguimiento de estas y analizar los indicadores deefectividaddelservicio.

Page 27: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

27

ModelodeEstructuraFuncional

Figura4.ModeloEstructuraFuncional–VistaGeneral.

Page 28: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

28

Figura5.ModelodeEstructuraFuncional–AutorizadorCentral.

Figura6.ModelodeEstructuraFuncional–ComponentedeAuditoría.

Page 29: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

29

PuntodeVistadeDesempeñoElpuntodevistadedesempeñodescribelahabilidaddeunsistemaparaejecutarsede formapredecibledentrode los requerimientosdedesempeñoestablecidosy/odeseados y la capacidad de manejar incrementos en los volúmenes deprocesamiento.

DescripciónSeconsideróparalaevaluacióndeldesempeñodelsistema,lostiemposdelatenciayeldesempeñoglobaldecomponentesprincipalesdelsistema,alaluzdediversasfuncionalidadesofrecidasporelsistema.

Loscomponentesqueintervienenprincipalmenteenlainteracciónconelusuarioyel desempeño percibido del sistema incluyen: la aplicación cliente (browser deInternet), el Portal Web, el Servidor de Aplicaciones, la Base de Datos y elComponentedeAutenticación.Estostiemposesperadosdedesempeñosedescribenen latenciasde respuesta (tiempode retrasoenenviar y recibir información) yentiemposderespuestafrenteadeterminadoniveldeconcurrencia.Parallegaraestosvalores, se hicieron diversos estudios promedio en prototipos que describenglobalmentelafuncionalidadycargadeunsistemasimilar.

Comopuedeverse, los tiempos semuestranenescalademilisegundos.Conestostiempos esperados, la respuesta del sistema percibida se ajustará a losrequerimientosdelMINISTERIO.

Cabe anotar que diversas situaciones pueden aumentar los tiempos de latencia,entreellaseltipodeconexióndelclientealsistema,ladistanciageográficaylacargadetrabajodelsistema.Estosvaloresseránreevaluadosconstantementeduranteeldesarrolloydesplieguedelsistema.

Page 30: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

30

ModelodeDesempeño

Figura7.ModelodeDesempeñodelSistema.

Page 31: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

31

PuntodeVistadeInformaciónEl punto de vista de información describe la forma en la que el sistema guarda,administra,manipulaydistribuyeinformación.

Para ello, se utilizan diversos modelos, para describir el aspecto estático de lainformacióncomosealmacenaylosmodelosdinámicos,quemuestranelflujodelainformaciónysuprocesamiento.

DescripciónSeidentificaronlasdiferentesentidadesquedebenpersistirenelsistemafinal.Estasentidades mantendrán llaves primarias consistentes en números generadosautomáticamente,quemarquenindividualmentecadaregistro.

Page 32: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

32

ModeloEstáticodeDatos

Figura8.ModeloEstáticodeDatos.

Page 33: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

33

Las entidades CentroReconocimiento, CentroAtención y CentroDiagnóstico serelacionan con los Automotores, Conductores y Autoridades de Tránsito, sinembargo, paramantener el diagrama simple y entendible, se prescindió de estasrelaciones.

ModeloDinámicodeDatos

Figura9.ModeloDinámicodeDatos–ModelodeReplicacióndeDatos.

Paraelmanejodelareplicacióndedatosyelcontroldefallos,secontaráconunabase de datos principalmaestra y su respectivo backup en el centró de cómputoprincipal.Estamismaestructuraseráreplicadaenuncentrodecómputoalterno.

Los datos se dividirán por regionales, esto con el fin de mejorar los tiempos derespuestapara lasoperacionesdeconsultay trámites, igualmente losdatosde lasregionalessealmacenaránenlabasededatosprincipalmaestraparacontarasíconlosdatosdetodoelpaísenunmismolugar.

Page 34: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

34

Figura10.ModeloDinámicodeDatos–IntegracióndeDatos(EntidadConductor).

En el diagrama se puede observar la entidad conductor, sobre la cual se puedenrealizar procesos de creación, validación de documento de identidad, edición,lectura, suspensión ‐que es la alternativa planteada para no borrar registros de labasededatos‐yasignacióndeprocesosdevencimientodeacuerdoasu fechadeexpiración.

Tambiénsepuedenobservar losstakeholderspropietariosde la informaciónyqueprocesopuedeejecutarcadaunodeellossobreestaentidad.

Page 35: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

35

Figura11.ModeloDinámicodeDatos–IntegracióndeDatos(EntidadLicenciadeTránsito).

En el diagrama se puede observar la entidad Licencia de Tránsito, con la entidadautomotor y la entidad propietario, estas tres entidades están estrechamenterelacionadas (ver diagrama estático de datos), sobre éstas entidades se puedenrealizar procesos de creación, edición, lectura, suspensión ‐que es la alternativaplanteadaparanoborrarregistrosdelabasededatos‐.

Tambiénsepuedenobservar losstakeholderspropietariosde la informaciónyqueprocesopuedeejecutarcadaunodeellossobreestaentidad.

Page 36: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

36

Figura12.ModeloDinámicodeDatos–IntegracióndeDatos(VinculaciónconServiciosExternos)

Elmodelodinámicodedatos,muestralaposibilidaddevincularlasfuncionalidadesdel sistema con servicios ofrecidos por sistemas externos en otras instituciones,como en este caso la Registraduría Nacional del Estado Civil. Esta vinculación se

Page 37: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

37

realizará de forma transparente, desacoplada y siguiendo estándares decomunicaciónyseguridad.

EscenariosdeCalidad

EscenariodeDesempeño

DescripciónPara las pruebas del sistema, y dado los requerimientos de tiempos de respuestaimpuestos por el cliente, se ha decidido implementar una serie de pruebas dedesempeñoquepermitendiagnosticarpotencialesproblemasdeldesarrolloyguiarcambiosdurantelaimplementacióndelsistema.

Las pruebas de desempeño simulan una determinada carga de transacciones paradeterminar la capacidad del sistema para responder ante esta carga y su posiblecomportamientoanteunfallodeterminado,todoestoenunambientecontroladoyauditado.

FuenteParaestaspruebasseutilizarálaherramientaJUnitPerf(ClackwareConsulting,Inc.,USA). Esta herramienta reúne una serie de decoradores sobre JUnit, permitiendocrearymanipularfácilmentepruebasdedesempeño.

EstímuloDada la complejidadde las funcionalidades y la carga a la cual estará sometida elsistema, es indispensable realizar las pruebas sobre las múltiples funcionalidades.Paraello,sepretendesimular lacargadeunambientedeproducciónyrealizar lasmétricassobreelcomportamientoesperadodelsistema.Paraestosecaracterizaronpruebasquemediantetransaccionessimultáneasabarcaneluniversodeescenariosposibles enun ambiente distribuido. Se espera que cadaprueba arroje resultadospositivosencuantolafuncionalidaddelsistema.Sepretendeparaelcasoespecíficode los serviciosde lógicadenegocio realizarpruebas sobre losmétodosofrecidosparaelmanejodeconductoresylicencias.

ArtefactoEl sistema manejará estas solicitudes simultáneas transversalmente a todo elsistema, teniendo en cuenta la funcionalidad ofrecida por cada nivel de laarquitectura.Laspruebasestáncontempladasparaquemidaneltiempodemoradoenloscomponentesdelógicadenegocio.

RespuestaSe espera que el sistema responda positivamente a las pruebas de cargatransaccionalmanejandotodaslaspeticionesenviadas,dentrodeltiempoesperadoderespuesta(máximo1segundoportransacción).

MedidaSe medirá el número de transacciones manejada por el sistema y la cantidad detransaccionesexitosas,asícomoeltiempoderespuesta.Seconsiderarálarespuestacomoexitosa simanejamás del 98%de las solicitudes y cadaunapor debajo del

Page 38: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

38

tiempo máximo permitido (1 segundo por transacción). El tiempo total de unconjunto de pruebas también contará como criterio para determinar si el sistemacumple los requerimientos no funcionales establecidos. Las métricas decomportamiento en las pruebas de carga, indicaron que el sistema satisface losrequerimientos mínimos de funcionamiento, lo cual indica que la arquitectura seencuentrabienplanteadaenestaperspectiva.

Perspectivas

PerspectivadeSeguridad

DescripciónUnaperspectivaarquitecturalesunconjuntodeactividades,estrategiasyguíasquesonusadasparaasegurarqueunsistemademuestreungrupoparticulardeatributosde calidad relacionadas que requieren consideración transversalmente sobre ungrupodepuntosdevistaarquitecturales3.Deestamanera,sepuedendefinirtácticasquepermitanaunaarquitecturapropuestaceñirsealosrequerimientosdecalidaddeseados, aplicando estas estrategias a cada una de las consideracionesarquitecturales,yaseaencuantoalaspectofuncionaldelsistema,comoalaspectoestructuralydedespliegue.

Laperspectivadeseguridadpermiteevaluarlasdecisionesdearquitecturadirigidaaproducir un sistema seguro, conociendo con exactitud las estrategias paraasegurarlo, lahabilidaddeconocer,controlar,trazaryauditarquiénpuederealizaraccionesysobrecualesrecursos.

Paraelanálisisde laseguridadinformática,sepuedenrecurriraestudiosybuenasprácticas de arquitectura y desarrollo, así como a normas establecidasinternacionalmente, como la NTC‐ISO/IEC 27001(2006), “Tecnología de lainformación, técnicas de seguridad, sistemas de gestión de la seguridad de lainformación(SGSI)”,publicadaporelICONTEC4.

AplicabilidadLaperspectivadeseguridadimpactalospuntosdevistaglobalmenteparaasegurarlaconsecucióndelosatributosdecalidad.Puedeverseacontinuación,enquegradosonafectadasporlasestrategiasasumidasenlaarquitectura.

Tabla4.Impactodelaperspectivadeseguridadenlospuntosdevista.

PuntodeVista ImpactodelaPerspectiva

Funcional Medio

Despliegue Alto

Información Medio

ConcurrenciayDesempeño Bajo

Page 39: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

39

ActividadesEs necesario seguir un plan de actividades para analizar, detectar y especificar losposibles riesgos inherentes al sistema que puedan comprometer la seguridad. Asímismo,esnecesarioimplementarunaestrategiadecontrolderiesgosyunplandemitigación, que mantengan el sistema dentro de las características de calidaddeseadasugerida.

Dentro de la calidad deseada, el MINISTERIO sugiere5: “[Proveer] validación,autorización y registrode las transacciones resultadode los trámitesde tránsito ytransporteefectuados, [considerando] lasincronizacióndeeventos,demaneratal,que impida la generación fraudulentao incompletadeun trámite. [Ademásdebe]generaruncódigodeautorizacióncuando se realicen trámitesdeactualizaciónderegistros existentes. En caso de rechazo, se deberá generar un mensaje de noautorizaciónpor inconsistencias y un registro de transacción intentadano exitosa,con el objeto de establecer antecedentes respecto de cualquier intento defraude….Todoelsistemadebetrabajardeformasegura,porestolosdocumentosdeLicenciasdeConducciónyLicenciasdeTránsitoserángeneradasconunsistemadeseguridadbasadoenuncódigobidimensionalyconunaltoniveldeencripción”.

Por tanto, se sugieren los siguientes puntos como características de la calidadbuscadaenelsistema:

‐ Autenticaciónyautorizacióndeusuariosyactoresdentrodelsistema.

‐ Encriptación de los datos de transacciones y comunicación dentro delsistema.

‐ Etiquetadodedatos,suscontenidosyorígenes.

‐ Validaciónde la información registrada según la definiciónde los registros,asícomodelosrequerimientos,registroytransaccionesdentrodelsistema.

‐ Generaciónderegistrosdeauditoríaquepermitanlatrazabilidaddefallosytransaccionesdelsistema.

‐ Tolerancia a fallos, que el sistema falle seguramente (que se conozcan lasimplicacionesyseanconocidosloslímitesdelafalla)yrecuperacióndedatosencasodeavería.

ContextodeSeguridad

RiesgosdelNegocioSeidentificaronlossiguientesriesgosdelnegocio:

‐ Gran distribución geográfica del sistema que implicaría distribución,fragmentación y falta de integración de la información, además deincrementar los posibles puntos de acceso que representarían uncompromisoalaseguridaddelsistema.

‐ Enorme cantidad de personal presente en la institución con acceso alsistema.

Page 40: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

40

‐ Necesidaddecontrolarelaspectofísicodelaseguridad:oficinas,servidoresygranjasdecomputadores.

‐ Dificultadparaelcontroldelosprocesosytodassusactividadesenmúltipleslugares,inclusoenaquellosalejadosgeográficamentedelMINISTERIO.

‐ Eldifícilcontrolyseguridadde losprocesosque implicanmanejodedinerodentrodelainstitución:facturación,contratación,multas,etc.

RiesgosTécnicosSepudieronreconocerlossiguientesriesgostécnicosqueimpactaríanlaseguridad:

‐ Característicasde la información tratadaal interiordel sistema,quepor sucontenidopodríacomprometerlapropiaseguridaddelsistema.

‐ La necesidad de que el sistema se conecte a otras instituciones y sistemasinformáticos,dejandopuertasabiertasenelsistema.

‐ Alta concurrencia esperada del sistema, que dificulta la trazabilidad de unúnicousuariodentrodelsistema,asícomolaposibilidaddepermitirataquesquesaturenlacapacidaddeconcurrenciadelsistema.

‐ Dada la gran distribución geográfica del sistema, existe un gran riesgo detenerqueusarcanalesdecomunicacióndifícilesdecontrolaryposiblementeinseguros.

‐ Necesidaddecontrolaraspectosfísicosquepuedencomprometerelcorrectofuncionamientodelsistema: flujoeléctricoconstante, integridadestructuraldelaubicacióndelsistema(ej.:edificios),etc.

AnálisisdelRiesgoyCasosdeAbusoLos casos de abuso son la especificación de una completa interacción entre unsistemayunoomásactores,dondelosresultadosdelainteracciónsondañinosparael sistema, los actores o alguno de los stakeholders6. De esta manera, permitendetallaruna interacciónentreunaamenaza (actor)yelpropiosistema,su flujodeinformación,larespuestayfinalmenteeldañoproducido.Sepuedenusarmúltiplesdiagramasparamodelarestoscasos,entreelloslaslistasoárbolesdeeventos.

Identificarcasosdeabusopermiteevaluarposiblesriesgosdentrodelaarquitecturapropuesta e impactar los diferentes puntos de vista paramejorar los atributos deseguridad del sistema. Se identificaron elementos sensibles en el sistema y sedescribieronlasrazonesporlascualessondegranimportancia(Tabla5).

Tabla5.Descripcióndelosrecursossensiblesdelsistema.

Recurso Sensibilidad Dueño ControldeAcceso

Datos de personasnaturales y jurídicasenlabasededatos.

Informaciónpersonal que puederepresentarvalor.

Autoridadescentrales yterritoriales detránsito.

No hay accesodirectoalosdatos.

Page 41: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

41

Recurso Sensibilidad Dueño ControldeAcceso

Proceso deasignación deespeciesvenales.

Etiqueta asignadapor el sistema queen caso de sercomprometida,alteraría losprocesosdenegocio.

Administrador deprocesos de negocio(BPM).

Autorizadorcentral.

Datos defuncionariosdecadaautoridad detránsito.

Datos privados quesi se comprometen,permitirían lasuplantación deidentidad.

Autoridadescentrales yterritoriales detránsito.

Autorizadorcentral.

Clasificaciónderolesde usuarios delsistemadentrode labasededatos.

Información queusada de maneramaliciosa, permitiríaelevar el poder deun usuario dentrodelsistema.

Autorizadorcentral.

Autoridadescentrales yterritoriales detránsito.

No hay accesodirectoalosdatos.

Proceso deasignación y controlde recaudo deinfracciones.

Controlar esteproceso podríagenerar fraude yalteración del flujodedinero.

Administrador deprocesos de negocio(BPM).

No hay accesodirectoalosdatos.

Es importante notar que estos recursos sensibles se refieren a los datos que seencuentranalinteriordelsistemaynoaaquellosrecursosexternosalmismo.

Se deben además identificar por tanto, los roles dentro del sistema y el grado decontrolquetienecadaactorsobrelosdatossensiblesmencionados(Tabla6).

Tabla6.Actoresdelsistemaysucontrolsobrerecursossensibles

Actor Datosdepersonas

Asignaciónde

especiesvenales

Datosdefuncionarios

Clasificaciónderoles

Asignaciónyrecaudo

Administrador Completo conauditoría

Completoconauditoría

Completoconauditoría

Completoconauditoría

Ninguno

Director deDepartamento

Lectura conauditoría

Ninguno Lectura conauditoría

Ninguno Ninguno

FuncionarioIntermedio

Lectura conauditoría

Lecturaconauditoría

Ninguno Ninguno Lectura‐/Creaciónconauditoría

Page 42: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

42

Actor Datosdepersonas

Asignaciónde

especiesvenales

Datosdefuncionarios

Clasificaciónderoles

Asignaciónyrecaudo

Operario deVentanilla

Lectura/Creaciónconauditoría

Ninguno Ninguno Ninguno Ninguno

Usuario Final(Web)

Ninguno Ninguno Ninguno Ninguno Ninguno

Comopuedeverse,losmúltiplesusuariostienendiversosgradosdeaccesolosdatosqueseencuentranalmacenadosenelsistema.Estohaceposiblecontrolarelalcancede sus acciones y por tantomantener un registro de los cambios realizados en elsistema. Sin embargo, también nos demuestra la posibilidad de que un usuariopuedaelevarsusprivilegiosdentrodelsistemaosuplantarunrol,ganandohabilidadparamanipulardatosalosqueusualmentenotendríaacceso.

Es por esto que técnicas de auditoría, control de acceso y restricción de datostendránvalorenlaconsecucióndelaseguridadfinal.

Conestosdatossensibles identificadosyelposibleniveldeacceso,esposibleparaun adecuado análisis de seguridad, tomar patrones de ataque establecidos y defrente a la arquitectura propuesta, identificar las amenazas del sistema y detallarcasosdeabuso,enformademodelosodeárbolesdeataque(Tabla7).

Tabla7.ÁrboldeAtaques(sedetallan4ataques).

MetaI:Obtenerlosdatosalmacenadosdeunapersonaofuncionario.1. Obtenerlainformacióndesdelabasededatos.

a. Obtenerlosdatosdirectamente.i. Craquearloscódigosdeaccesoalabasededatos.ii. Obtener acceso a través de niveles de acceso superior

(comoprogramasejecutablesenelservidoropropiosdelsistemaoperativo).

b. Obtenerlosdatospormediodeunfuncionarioadministrador.i. Ingenieríasocialparaobtener lasclavesdeaccesodeun

administrador.ii. Sobornarfuncionariosparaobtenerdatosdeacceso.

2. ObtenerlainformacióndesdelainterfazWeb.a. Crearunportal ficticioquepermitaobtener losdatosdeacceso

delosusuarios.b. Inyección de argumentos a través de la interfaz para obtener

informacióndelabasededatos.c. Enviarunprogramatroyanoparaobtenerinformacióndeacceso

desdeuncomputadorcliente.d. Atraparlospaquetesenviadosyrecibidosentrecliente/servidory

analizar el flujo de información para craquear o suponer la

Page 43: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

43

identificacióndelusuario.e. Analizar el contenido de los encabezadosHTTP para obtener la

informacióndeaccesoalsistemadeunusuarioparticular.3. Suplantaridentidaddeunusuarioconprivilegio.

a. Crear una aplicación cliente que directamente se conecte a lacapadelógicadenegocio.

b. Aplicarataquesdefuerzabrutaparaobteneraccesoalabasededatos.

MetaII:Alterarunaasignacióndeespecievenal.1. Suplantarelllamadoaunmétododesdeunsistemaexterno.

a. ObtenerinformacióndelosmétodosyXMLdecomunicacióndelsistemaparaasífalsearunllamadoaunmétodo.

2. Alterar archivos de configuración del servidor con los que se apoye elAdministradordeProcesosdeNegocio(BPM).

a. Obtener acceso a los archivos de configuración por medio defallosconocidosdelservidordeaplicaciones.

b. Hacerusodebúsquedasdearchivosparaobtenerlaubicacióndearchivosdeconfiguración.

3. Inyectar scriptsejecutablesen la capadenegocioque llamenmétodosdeasignación.

a. Embeber código ejecutable en archivos no ejecutables que sonenviadosalservidor.

b. Utilizarlíneasdeescapeocampospermisivosparacorrerscripts.4. Interceptar datos de sesión de un usuario (Bean de Sesión) en el

contenedor de aplicaciones para obtener la información de un usuariosuperior.

MetaIII:Cambiarlosrolesasignadosparaunusuario.1. Alterarladefinicióndeunrolenlabasededatos.

a. Obtener acceso directo a la tabla de asignación de roles en labasededatos.

2. Elevarlosprivilegiosdeunusuariodentrodelsistema.a. Falsear direcciones IP de un cliente con alta poder dentro del

sistema.b. Alterar la identificación de sesión de un usuario para que el

servidorloclasifiqueerróneamente.MetaIV:Cambiar/Eliminarinformaciónderecaudo.

1. Alterarlosdatosalmacenadosenelservidordebasededatos.a. Obtenerlosdatosdeaccesodeunusuarioutilizandométodosde

lametaI.2. Comunicarsedirectamente con labasededatos y saturar la capacidad

deprocesamientodelmotordepersistencia.a. Utilizarcanalesdecomunicación identificadoscomo insegurosy

realizarataquesdefuerzabrutaenelservidordebasededatos.b. Enviar múltiples solicitudes al servidor de base de datos hasta

saturarloscanalesdecomunicaciónconocidos.3. Introducirdatoserróneososinsignificadoenlabasededatos.

a. InyeccióndecódigoSQLdirectamenteenlabasededatos.

Page 44: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

44

b. Obtención de procedimientos almacenados mal protegidosalteracióndesusparámetros.

c. Explotación deWeb Services inadecuadamente protegidos, quepermitanelllamadoaunmétododeinsercióndedatos.

Estosposiblesataquesalsistemadebensertenidosencuentaencuantoaldiseñoyla aproximación arquitectural se refiere, para disminuir la probabilidad deocurrencia.

Esadecuadoseñalarquelaseguridaddentrodeunsistemanoesunacaracterísticaounafunciónesperada,esunatributodecalidadtransversalatodoelsistemaquedebetenerseencuentaparacadacomponente implementado.Loscasosdeabusodeben ser complementados con todos los caminos de excepción para el sistema,teniendoencuentalosposiblesataquesyrecursossensiblesdelsistema.

TácticasArquitecturalesDadoslosriesgosidentificadosdelaarquitectura,sedebensugerirmecanismosparael control de la seguridad del sistema. Dentro de los Puntos de Vista de laArquitectura, se pueden identificar los elementos introducidos para evitar lamaterializacióndeataquesalsistema.

1. PuntodeVistadeDespliegue:enestepuntodevista,seincluyeronmáquinasyhardwareespecializadoque filtran información,mantienen loscanalesdeinformaciónsegurosyrechazanintentosdeexplotacióndelsistema.

a. Firewall:Hardwareespecializadoenfiltrarelaccesoalsistemaacordeaunaspolíticasdereddefinidas.

b. Servidor de Autenticación: Autoriza el acceso al sistema siguiendoreglasdecontrolsobreusuariosregistrados.

c. ComponenteAutorizador: Componentedependiente del servidor deaplicaciones que permite identificar las posibles acciones solicitadassobrelosdatos,identificandoorigenypertenenciadelosdatos.

d. ComponenteAuditoría:Componentedelservidordeaplicacionesquemantieneregistrosdeacceso,trazabilidaddeaccionesymovimientodedatosdentrodelsistema.

2. PuntodeVistaFuncional:enestepuntodevista,seincluyeroncomponentesy funcionalidad expuesta dentro del sistema que controlan los procesossobrelosdatosylaautorizacióndentrodelsistema.

a. Componente Autorizador: se detallan dentro del componentesubcomponentes que controlan y etiquetan la información de cadaprocesoindividual:

i. ControladordeRecaudo

ii. ControladordeFacturación

Page 45: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

45

iii. ValidadordeInformación

b. Componente Seguridad: este componente permite identificar ydisponerdeunataquealsistema.Incluyesubcomponentes:

i. DetectordeIntrusos

ii. AdministradordeSesiones

iii. ValidadordePermisos

c. Componente Auditoría: este componente mantiene registro de losaccesos al sistema, de las transacciones realizadas e identifica queactordelsistemarealizócualescambios.

d. Componente Analizador de Archivos: este componente permitebuscarinconsistenciasenlosarchivosdecomunicaciónusadosporelsistema,validandoasílafuncionalidadofrecida.

3. Punto de Vista de Información: En este punto de vista se detallan en losmodelos dinámicos la decisión de limitar el control sobre los datos a cadaactorindividualdelsistema,dependiendodelniveldepoderasignadoacadauno. También se detalla el nivel de acceso permitido a un llamado desdefueradelsistema(enelcasoconcreto,laRegistraduría).

4. Aspectos globales del sistema: Además, se implementarán decisiones dearquitecturaparaaumentarelniveldeseguridadofrecido.

a. Encriptación de la información: todos los componentes realizaránciframientodelosdatossensiblesqueseráncomunicados.

b. Las comunicaciones serán manipuladas por una capa extra deseguridadencadapaquetedecomunicación(SecureSocketsLayer).

c. ElusodeSingleSign‐Onparamantenerunasola instanciadesesiónencadausuarioconectadoalsistema.

d. Los usuarios del sistema que puedan tener niveles superiores deacceso, serán controlados y deberán firmar acuerdos de seguridad,proteccióndelainformaciónyconfidencialidad.

PosiblesProblemasSeidentificanposiblesproblemasenelmanejodelaseguridad:

‐ Pobrecompromisodelosequiposdetrabajoparamantenerlaseguridaddelsistema.

‐ Bajo conocimiento del equipo de desarrollo de las tecnologías que seránusadasparamantenerlaseguridad.

‐ Falta de interés del equipo de desarrollo y/o mantenimiento paraimplementarlascaracterísticasdeseguridadsugeridas.

Page 46: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

46

‐ Violación de términos de contrato del personal del MINISTERIO o de lasautoridadesterritoriales.

‐ Dificultad de encontrar un punto de equilibrio entre la necesidad demantenerlaseguridadyeldeseodemantenerundesempeñoaceptabledelsistema.

‐ Resistencia de las instituciones a rediseñar los procesos ya existentes paraincluirlasconsideracionesdeseguridad.

ListadeChequeo‐ ¿La institución ha realizado identificación de los puntos sensibles de los

procesosencuantoaseguridad?

‐ ¿Seimplementaronloselementossugeridosdeseguridad?

‐ ¿Seidentificóalpersonalconaccesodealtonivelenelsistema?

‐ ¿Hubouncompromisodelpersonalparamantenerlaseguridaddelsistema?¿Sefirmaronacuerdosdeconfidencialidad?

‐ ¿Existen herramientas y procesos para mantener la consistencia de lainformaciónaúnantesdeingresarestaalsistema?

‐ ¿Los componentes de hardware cliente están actualizados y correnprogramasconsideradoscomoseguros?

‐ ¿Serestringieronlosaccesosfísicosalossistemascentrales?¿Setienelistasdecontroldeaccesoalossistemas?

‐ ¿Los sistemas individuales de las autoridades territoriales cumplen con losrequisitosdeseguridadmínimosexigidos?¿secontrolaelaccesofísico?

‐ ¿Las empresas contratadas para proveer la infraestructura tecnológica sealinean con las directrices de seguridad exigidas? ¿el hardware proveídocumpleconlosrequerimientosmínimosdeseguridad?

‐ ¿El personal sensible dentro delMINISTERIO, equipo de desarrollo y otrasinstitucioneshanleídoyaceptadolascondicionesdelpresentedocumento?

PerspectivadeUsabilidadSepretendeverificarque la arquitectura candidata tenga la capacidaddepermitirqueelsistemaseausadoporpartedepersonascondiscapacidades.

Laperspectivaseestructuradelasiguientemanera:

AplicabilidadLasvistaquehemosconsideradoqueserá lamás impactadapor laperspectivadeusabilidad es básicamente la vista funcional, ya que esta vista muestra las

Page 47: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

47

estructuras funcionales del sistema incluyendo el nivel de presentación y loscomponentesimplicados.

ConcernsLosatributosopropiedadesdecalidadquecubreestaperspectivasonbásicamentetodos aquellos relacionados con usabilidad, tanto en facilidad de uso del sistemacomoenpermitiraccesibilidadalasfuncionesdelsistemaporpersonasquetenganalgún tipo de discapacidad o que estén usando equipos de cómputo conrestricciones.

Actividades1. HacerunestudiodelaGuíadeaccesibilidaddecontenidoWebpropuestapor

laW3C(WebContentAccesibilityGuidelines1.0)7.

2. Identificarlospuntosdeinteraccióndelosusuariosconelsistema‐niveldepresentacióndelaaplicación.

3. Identificarlasoperacionescomplejasdondeelusodelaaplicaciónpuedaserineficienteoconfuso,paradefinirestándaresdeoperaciónypresentacióndelainformación.

4. Hacer losajustesa lacapadepresentaciónde laaplicaciónpara incorporarloscambiosquesehayandetectado.

TácticasArquitecturales1. Definir una interfaz consistente que se usa en todas las páginas de la

aplicaciónWeb.

a. Usodelogotipoenlapartesuperiorentodaslaspáginas.

b. Laubicacióndelmenúdenavegaciónen laparte izquierdadetodaslaspáginas.

c. Usodeunpiedepáginaconsistenteconelmismocontenidoentodaslaspáginas.

d. Eláreadetrabajoseráelcentrodelaspáginas.

2. Definicióndecoloresconaltocontrasteloscualespuedanservisualizadosenpantallasmonocromáticas,loscoloresausarson:

a. Encabezado:Fondoazulconletrasblancas.

b. Menú: grisobscuropara los letras conun fondo congrismás claro,buscandocontraste.

c. ÁreadeTrabajo:Fondoblancoconletrasnegras.

Page 48: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

48

3. ExigirelusodelaetiquetaAltparatodaslasimágenesycontenidovisualquepermita a las imágenes ser procesadas por dispositivos de accesibilidad(lectoresBraille,TTYparaaudio,etc.).

4. Exigirelusodeestilosyprohibir lamanipulacióndirectadepropiedadesdeloscomponentesHTML.

5. Definir una platilla HTML sobre la cual se debe construir cualquier nuevapagina HTML, en esta plantilla se debe hacer referencia al lenguaje pordefectoqueseusaenlapágina.

Problemas1. La falta de conocimiento en cuanto a nuevas tecnologías de accesibilidad

parapersonascondiscapacidades.

2. Inicialmente toma más tiempo de lo normal construir una página conopcionesdeaccesibilidad,posteriormenteyaldefinirlocomounestándareltiempodeconstrucciónpuedebajarconsiderablemente.

3. El uso de atajos dentro de los componentes embebidos podría entrar enconflictoconlosatajospropiosdelnavegadorodelsistemaoperativo.

ListadeChequeo‐ ¿Las interfaces proveen alternativas equivalentes para auditorio y contenidovisual?¿Lasimágenestienenunadescripciónalternativa?

‐¿Lasinterfacesdelaaplicaciónusancoloresconcontraste?¿Esposiblevisualizarlainterfazaunsisepresentaenunmonitoramonocromático?

‐ ¿Se usan hojas de estilo en las interfacesWeb paramanejar la presentación deéstas?¿Conunsimplecambioenlashojasdeestilolapáginaseajustafácilmente?¿Seevitaelusodepropiedadesdepresentacióntalescomofuente,tamaño,etc.?

‐¿SehacereferenciaalleguajeusadoparamostrarelcontenidodelapaginaWeb?(HTML,XML,etc.)

‐¿Seempleantablassolamenteparapresentacióndedatostabulares?¿Seevitaeluso de estas para el diseño de la página? ¿Las tablas se ajustan correctamentecuandocambiaeltamañodepresentacióndelapágina?

‐ ¿En caso que las páginas Web sean diseñadas para ultimas versiones de losbuscadoressoncapacesdesermostradasenversionesanterioresdebuscadores?

‐ ¿En caso de auto ejecutarse procedimientos que consuman tiempo tales comoactualizaciones,presentaciones,etc.?¿Esposiblepausarlos?

‐ ¿Los objetos embebidos en la pagina Web cuenta con mecanismos de accesodirectocomoshortcuts,Alt+Carácter,etc.?

‐¿Sediseñoelportalindependientealdispositivo?¿Nosedependeexclusivamentedelmouse?¿Elteclado?

Page 49: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

49

‐¿Seprovee informacióndecontextoyorientaciónencadaunade laspaginasdelportal?¿Sobretodoenaquellasquesoncomplejas?

‐ ¿Se proveen mecanismos claros de navegación? ¿Son estos consistentes? ¿Losdocumentossonexpresadosdeunaformaclaraysimple?¿Seentiendenfácilmente?

‐¿Elportalesconsistentegráficamente?¿Estáacordeconlaimagencorporativa?

Page 50: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

50

GlosariodeTérminos

Término Definición

EspeciesVenalesSonlascodificacionesqueasignaelMinisteriodeTransporteparalasplacas,licenciasdetránsito,licenciasdeconducciónycertificadosdemovilización.

CallCenter Centro físico que reúne agentes telefónicos queatiendenllamadasdelosclientes.

DataWarehouse Sitio que consta de dispositivos de almacenamientomasivo interconectados entre si por una red,normalmentedefibraóptica.

Infraestructura Componentes físicos y tecnológicos que soportan unconjuntodedatosydeaplicaciones.

Arquitectura Combinación datos, aplicaciones e infraestructura queproveenapoyoalosprocesosempresariales.

Stakeholder Persona o grupo de personas que se ven afectadasantes, durante y después de una implementacióntecnológica.

Concern Preocupación que manifiesta un stakeholder conrespecto a la forma en que se realizará laimplementacióntecnológica.

Punto de Vista (Viewpoint)

Formadeaproximaciónaunaarquitecturaconelfindehacerlamásclaraaungrupodestakeholders.

PerspectivaArquitectural

Colección de actividades, tácticas y guías que sonusadasparaasegurarqueunsistemaexhibaunconjuntode propiedades de calidad relacionados que requieranconsideración transversal a un número de vistasarquitecturalesdeunsistema.

BackingBean Componente de software reutilizable de los sistemasempresarialesquerepresentandatosdesdeunniveldeinterfazgráfica.

DataMining Extraccióndeinformaciónqueresideenbasesdedatoscon el fin de detallar elementos particularmente útilesparalosprocesosdeunainstitución.

ContactCenter Espaciofísicoyfuncionalcuyofinesproveeratenciónalosusuariosdelosserviciosdeunacompañía.

SingleSign‐On Procedimiento de autenticación que habilita a unusuario a acceder a varios sistemas con una solainstancia de identificación. Este método externaliza laautenticación de usuarios a un componenteindependiente.

Blackboard Estilo arquitectural de software que mantiene unrepositorio de datos central donde otros componentespuedencompartiryalterarlainformaciónpresente.

JUnit Conjunto de librerías utilizadas para la realización depruebasunitariasdecódigoJava.

Page 51: UNIVERSIDAD DE LOS ANDESisis3702/dokuwiki/lib/e… · UNIVERSIDAD DE LOS ANDES Proyecto R.U.N.T. Definición de Documento de Arquitectura

51

Browser Aplicación que permite a un usuario recuperar yvisualizar datos desde laWeb comúnmente escritos enlenguajedehipertexto(HTML).

AcrónimosVPN Virtual Private Network (red privada

virtual)SO SistemaoperativoId NúmeroIdentificadorJSF JavaServerFacesJSP JavaServerPagesHTML HypertextMarked‐upLanguageXML ExtendedMarked‐upLanguageXSD XMLSchemaDocument

ReferenciasBibliográficas

[1] G.Booch,J.Rumbaugh,I.Jacobson,Ellenguajeunificadodemodelado.España:PearsonEducaciónS.A.,2006,pp.11‐40,243‐270,487‐490.

[2] C.Larman,UMLyPatrones.España:PearsonEducaciónS.A.,2002,pp.39‐78,121‐143.

[3] RozanskiN,WoodsE.SoftwareSystemsArchitecture.Addison‐Wesley.2005.[4] ComitéTécnicodeTécnicasdeSeguridaddelaInformación.Sistemade

GestiónDeLaSeguridadDeLaInformación.InstitutoColombianodeNormasTécnicasyCertificación(ICONTEC),2006.

[5] MinisteriodeTransporte,AnexoADelPliegodeCondiciones,LicitaciónPúblicaNo.MT‐001de2006.MinisteriodeTransporte.2006.

[6] J.McDermott,C.Fox.UsingAbuseCaseModelsforSecurityRequirementsAnalysis.ComputerSecurityApplicationsConference(ACSAC’99proceedings,15thAnual).InstituteofElectricalandElectronicsEngineers.1999,pp.55‐64.

[7] W.Chisholm,G.Vanderheiden,I.Jacobs.WebContentAccessibilityGuidelines1.0.W3C.2008.[Disponible]http://www.w3.org/TR/WAI-WEBCONTENT