· Web viewEl objetivo de la Medida Cautelar a través del dispositivo electrónico, es disminuir...

Dirección de Adquisiciones de Oficialía Mayor de Gobierno del Estado de Baja California Licitación Pública Internacional no. LA-902002994-I32-2015

ANEXO 1

ESPECIFICACIONES TÉCNICAS

“Suministro e Instalación del Sistema Integral de Monitoreo a Imputados con

Beneficio de Medida Cautelar de Localización por GPS”

(SETEC 2015)

Página 1 de 41

SECRETARÍA DE SEGURIDADPÚBLICA DEL ESTADO

INTRODUCCIÓNEl 11 de Agosto de 2010, con la entrada en vigor del nuevo Código de Procedimientos Penales para el Estado de Baja California; se implementó el Nuevo Sistema de Justicia Penal, en la cual se instituyen nuevas medidas judiciales que tendrán una función toral en el impulso de los procedimientos penales, entre las cuales se encuentran las medidas cautelares.

OBJETIVOEl objetivo de la Medida Cautelar a través del dispositivo electrónico, es disminuir la población de las penitenciarías al mantener bajo libertad condicional reos que estén cumpliendo sentencia o estén siendo procesados por delitos menores, mediante un control de vigilancia que permita conocer la ubicación y movimientos del imputado, así como delimitar zonas públicas cuya seguridad es imprescindible como escuelas, edificios públicos, etc., y ofrecer vigilancia a ciudadanos que hayan sido víctimas de algún delito.

ÁMBITO DE APLICACIÓNLa colocación de dispositivo electrónico será aplicable a los imputados que se acojan a esta medida cautelar, víctimas de delitos que requieran el servicio.

FUNDAMENTO LEGALArtículo 167, fracción V, del código de procedimientos penales del Estado de Baja California, La colocación de localizadores electrónicos, sin que medie violencia o lesión, dignidad o integridad física del imputado.

Página 2 de 41


PAQUETE ÚNICO

ANEXO ADESCRIPCIÓN DEL PROYECTO

PARTIDA 1

REQUERIMIENTOS DEL PROYECTOLos requerimientos del Producto se presentan en el documento “Anexo A – Descripción del Proyecto”.

1. LOCALIZACIÓN DE SISTEMAS Y EQUIPOSEl software desarrollado, los brazaletes electrónicos GPS, licenciamiento de servicios y base de datos del aplicativo utilizado para el monitoreo a imputados debe ser ubicado en la Secretaria de Seguridad Pública del Estado.

1.1. CUANTIFICACIÓN DEL EQUIPO / SERVICIOUBICACIÓN CANTIDAD UNIDADSecretaría de

Seguridad Pública del Estado

1 Desarrollo de aplicativo para Monitoreo de Imputados por GPS

Secretaría de Seguridad Pública del

Estado20 Brazalete GPS

Secretaria de Seguridad Pública del

Estado20 Servicio de trasmisión de datos

GPSSecretaria de

Seguridad Pública del Estado

1 Licenciamiento

Página 3 de 41


1.2. DESCRIPCIÓN DE EQUIPO Y FUNCIONALIDAD

CANTIDAD UNIDAD DESCRIPCIÓN

1

Desarrollo de aplicativo

para Monitoreo de

Imputados por GPS

El Sistema de monitoreo por GPS de imputados, víctimas permite identificar

posición actual e histórica de cada elemento monitoreado. Esto se puede

visualizar en una mapa en tiempo real, o también posición(es) históricas

almacenadas en el sistema, integrando brazaletes electrónicos con tecnología GPS.

20 Brazalete GPS

Dispositivo GPS con tecnología GSM/GPRS para transmisión y registro de datos en tiempo real, sujetador con bandas de

conductividad y circuito incorporado que permite detección de sabotaje, manejo de geo-cercas, componentes electrónicos y

batería dentro cápsula de plástico a prueba de agua (IP-67), reporte de nivel de batería

y estado del dispositivo.

20Servicio de transmisión

GPS

Servicio de trasmisión GPS y de datos GPRS aplicable para los brazaletes de monitoreo a imputados con soporte por dos años por

parte del proveedor beneficiado.

1 Licenciamiento

Enterprise de Google Maps API con soporte por dos años.

Software de monitoreo requerido para el uso de brazaletes.

Página 4 de 41


2. DIAGRAMA DE FUNCIONALIDAD

3. ALCANCE

El presente proyecto tiene alcance en el Municipio de Mexicali y estará a cargo de la Coordinación General de Sistemas de Información y Tecnología de la Subsecretaria del Sistema Estatal Penitenciario de la Secretaría de Seguridad Pública.

Así mismo para lograr la meta de implementar el desarrollo de una herramienta de tecnológica de primer nivel, y con la finalidad de dimensionar y tener una mejor comprensión de las acciones que deben

Página 5 de 41


de ser contempladas para el desarrollo del proyecto, este se divide en 6 subgrupos:

a) Etapa 1: Análisis inicial del Proyectob) Etapas 2,3: Diseño y desarrollo de la aplicaciónc) Etapa 4: Pruebas de funcionalidad del sistemad) Etapa 5: Capacitación a usuarios del sistemae) Etapa 6: Implementación de la aplicaciónf) Etapa 7: Entrega recepción del Proyecto.

a) Etapa 1: Análisis inicial del Proyecto

La definición de los procesos y requerimientos para el desarrollo de este proyecto están establecidos por la Subsecretaria del Sistema Estatal Penitenciario en el presente Anexo A con el cual el proveedor deberá realizar las siguientes fases de trabajo:

1) Análisis de Requerimientos El proveedor deberá recibir la definición de los procesos por parte de la Subsecretaria del Sistema Estatal Penitenciario para el inicio de del análisis de requerimientos detallados, así mismo es requerido que se formalicen entre el proveedor y la Subsecretaria del Sistema Estatal Penitenciario grupos de trabajo por áreas y procesos; de manera simultánea de tal forma que se pueda revisar de forma eficiente la definición de todas las políticas, procesos y flujos de trabajo; y entender a detalle los requerimientos y el esquema de intercomunicación de cada una de estas áreas funcionales.

2) Validación y Corrección de AnálisisComo parte de la metodología de trabajo que debe de seguirse por parte del proveedor, en esta fase los requerimientos planteados derivados en el punto 1 de esta sección, se traducen por parte del proveedor a un lenguaje capaz de ser comprendido por el personal que interviene en cada una de las áreas involucradas de la Subsecretaria del Sistema Estatal Penitenciario objeto del análisis, mostrando de manera funcional las políticas y flujos de trabajo con la finalidad de pasarlos por las pruebas funcionales y operativas que en la práctica se pudieran presentar.

Página 6 de 41


En caso de encontrar inconsistencias durante la validación de procesos, es requerido que el proveedor realice las correcciones o adecuaciones con la finalidad de cumplir al 100% con los requerimientos y especificaciones realizadas por las áreas de involucradas de la Subsecretaria del Sistema Estatal Penitenciario.

Estas revisiones estarán basadas en las diferentes sesiones de trabajo que se requieren entre el proveedor y el área responsable de validar el proceso para lograr la eficiencia en el resultado del trabajo.

4) Documentación de Análisis y Diseño de la AplicaciónEl entregable por parte del proveedor una vez realizados los procesos de diseño, análisis y validación; será la documentación formal del análisis y diseño de requerimientos que intervienen en cada una de las áreas y como mínimo deberá contar con la siguiente información:

I. Conceptualización o descripción del proyectoII. Descripción de funcionalidad/listado de requerimientosIII. Arquitectura de Infraestructura y SistemaIV. Matriz de Rastreo o TrazabilidadV. Glosario de TérminosVI. Modelo del NegocioVII. Prototipo de InterfazVIII. Reglas del NegocioIX. Diagrama y especificación de casos de usoX. Diseño de InterfazXI. Diagrama de ClasesXII. Diagrama de SecuenciasXIII. Diagrama de Estados

b) Etapas 2: Diseño

Como parte de un pre análisis general el sistema debe contener los siguientes procesos y así mismo que integren completamente las políticas, procesos y flujos de trabajo que se definieron en la Etapa 1 y cumpla con los requerimientos funcionales de la aplicación que están definidos en Anexo A de este mismo documento.

Etapa 3: Desarrollo de la Aplicación

Página 7 de 41


El proveedor deberá realizar el desarrollo de la aplicación, de tal forma que cumpla en un 100% con los procesos en el Anexo A, apegándose a los estándares establecidos en el Anexo B.

c) Etapa 4: Pruebas de Funcionalidad del Sistema

Así mismo el proveedor deberá integrar un laboratorio de pruebas de manera detallada se puedan realizar las diferentes operaciones en el sistema y validar que realmente soportará la operación definida en los procedimientos de la Subsecretaria del Sistema Estatal Penitenciario en el Nuevo Modelo de Justicia Penal (las pruebas se realizaran por parte del personal designado por la Coordinacion de Sistemas de Informacion y Tecnologia Penitenciaria en conjunto con el usuario y el proveedor).

d) Etapa 5: Transferencia de conocimiento

El proveedor deberá entregar manual de usuario y técnico sobre los procesos desarrollados en la aplicación mismos que son descritos en el presente Anexo A.

Para poder realizar una eficiente implementación de los procedimientos del sistema, es requerido que el proveedor realice una capacitación de la operación y uso de las opciones del sistema al personal de la Coordinacion de Sistemas de Informacion y Tecnologia de la SSEP designado para el seguimiento del proyecto; y así mismo previo a la capacitación el proveedor beneficiado deberá entregar temario describiendo los procesos y horas requeridas por tema.

Para estar en posibilidades de brindar soporte a los usuarios finales por parte del personal de la Coordinacion de Sistemas de Informacion y Tecnologia de la Subsecretaria del Sistema Estatal Penitenciario durante el periodo de garantía, se conformará una mesa de ayuda para brindar un adecuado servicio de soporte técnico, este soporte brindado por la mesa de ayuda será considerado de primera mano; será el único enlace entre el proveedor y los usuarios finales para solución de problemas encontrados en la operación de la aplicación.

Es por este motivo que el proveedor deberá proporcionar un curso integral de capacitación en la instalación, operación y administración

Página 8 de 41


del sistema, incluyendo material de apoyo, una guía de implementación de la solución.

El proveedor deberá capacitar al personal de la Coordinacion de Sistemas de Informacion y Tecnologia de la Subsecretaria del Sistema Estatal Penitenciario acerca del manejo de la herramienta para desarrollo de aplicaciones Microsoft .NET y uso de los programas código fuente de la aplicación.

e) Etapa 6: Implementación de la Aplicación

Debido a que una de las etapas críticas y finales en el desarrollo de este proyecto es la implementación, es requerido que el proveedor proporcione los siguientes servicios para iniciar las operaciones en el Municipio de Mexicali el día 30 de Noviembre de 2015

Configuración de la aplicación con la Base de Datos (existente Oracle 11g) y preparación de la aplicación para el inicio de operaciones en el Centro de Datos de la Subsecretaria del Sistema Estatal Penitenciario en Mexicali, asesoría a la Subsecretaria del Sistema Estatal Penitenciario en la recopilación y carga de información preliminar, revisión y validación de la información preliminar, así como la configuración de los parámetros de operación de la aplicación.

El proveedor deberá de realizar la instalación del sistema en el ambiente de producción (arquitectura tecnológica) que la Subsecretaria del Sistema Estatal Penitenciario le indique, con la finalidad que se valide que el sistema opera de manera eficiente y a satisfacción de la Subsecretaria del Sistema Estatal Penitenciario, esto previo al proceso de implementación en las oficinas de Mexicali.

f) Etapa 7: Entrega recepción de proyecto.

El proveedor beneficiado al término del proyecto debe entregar a la Coordinacion de Sistemas de Informacion y Tecnologia de la Subsecretaria del Sistema Estatal Penitenciario el código fuente abierto de la aplicación y licencia institucional de uso ilimitado en el Estado de Baja California y a perpetuidad en formato digital grabado disco DVD y licencia con los derechos de uso por escrito.

4. DESCRIPCIÓN DE PROCESOS

Página 9 de 41


La Secretaría de Seguridad Pública del Gobierno del Estado de Baja California requiere la contratación de los servicios y adquisición de equipo para “SISTEMA INTEGRAL DE MONITOREO A IMPUTADOS CON BENEFICIO DE MEDIDA CAUTELAR DE COLOCACIÓN DE LOCALIZADOR ELECTRÓNICO POR GPS.”

El proveedor deberá proporcionar una aplicación que deberá ser capaz de convertir coordenadas que envían los brazaletes en direcciones tales como (Calle, número, localidad), posterior ser enviarlas y procesadas por el mismo.

El proveedor deberá proporcionar una aplicación denominado “Sistema de Monitoreo a Imputados por GPS”, en donde se reciba y se procese toda información enviada por los dispositivos GPS esta deberá convertir los datos de la trama para ser enviados a una dirección IP programada por el proveedor en el brazalete.

La aplicación deberá contar con la funcionalidad de integración y consulta de información con el sistema institucional de la Subsecretaria del Sistema Estatal Penitenciario @Justicia, para la consulta de información general del caso a través del NUC o nombre del imputado.

La aplicación, base de datos, licenciamiento y servicios de datos correspondientes deben residir en el equipo servidor dedicado para este fin, el equipo servidor existente es propiedad de la Secretaria de Seguridad Pública del Estado.

La aplicación debe contar con las funcionalidades descritas en los siguientes procesos permitiendo la correcta operación e implementación de la medida cautelar de brazalete electrónico GPS.

FUNCIONALIDAD GENERAL.-

o El Sistema de Monitoreo a Imputados por GPS, permite identificar posición actual e histórica de cada elemento monitoreado. Esto se puede visualizar en una mapa en tiempo real, o también posición(es) históricas almacenadas en el sistema.

o Controlar información general de imputados a monitorear, así como su posición (longitud y latitud). Esto permite ubicarlos en un mapa (Bing de Microsoft, MAPS de Google).

Página 10 de 41


o Se monitorea a los imputados por medio de un brazalete con funcionalidad de GPS. El brazalete emite las alarmas, nivel de batería y reporta posición (longitud y latitud) al sistema central por medio de red telefónica celular.

REGISTRO DE PERSONAS

I. Seleccionar el tipo de persona a registrar (imputado, asesor jurídico, oficial, juez, administrador).

II. Al seleccionar persona de tipo imputado se debe realiza la búsqueda de información por medio del nombre, NUC en la base de datos de Sistema @Justicia con la finalidad de obtener la información personal y jurídica del imputado, la consulta puede ser realizada a través de un servicio web mismo que será desarrollado e implementado por el proveedor en coordinación con personal de la Secretaria de Seguridad Publica.

III. Se controla para cada imputado la siguiente información:a) Datos generales.- fotografía de frente, nombre, apellido paterno,

apellido materno, dirección, estado, ciudad, RFC, fecha de nacimiento, edad, sexo, correo electrónico, número de teléfono celular y local, NSS, estado civil, grupos a los cuales pertenece (por ejemplo, pandilla, cartel etc.).

IV. Información general del caso: Expediente, número único de caso (NUC), fecha de inicio de medida, fecha de fin de medida tipo de caso (delito), juez, asesor jurídico responsable y espacio para comentarios generales.

V. Datos de monitoreo.- Asignación de brazalete, fecha de colocación y retiro, motivo de retiro, observaciones.

VI. Geo Referencias: Asignación de zonas de exclusión e inclusión.VII. Vehículo propiedad del imputado: marca, modelo, número de matrícula

(si aplica)VIII. Posiciones históricas: registro histórico de todos los movimientos

realizados por el imputado.IX. Víctimas que están ligadas al imputado (si aplica).X. Referencias personales: datos generales de aval moral, compañero de

vivienda, familiares.XI. Para los tipos de personas diferentes a imputados se controla la

siguiente información:a) Datos generales.- fotografía de frente, nombre, apellido paterno,

apellido materno, dirección, estado, ciudad, RFC, fecha de nacimiento, edad, sexo, correo electrónico, número de teléfono celular y local.

Página 11 de 41


Descripción del procesoEl responsable de realizar el registro del imputado en el Sistema de Monitoreo a Imputados deberá realizar búsqueda de la persona, la cual se realizara en la base de datos del Sistema Justicia obteniendo de esta forma los datos generales personales y del caso del imputado.

Se deberán de complementar los campos requeridos para su registro, asignando el asesor jurídico responsable así como el dispositivo GPS.

CATÁLOGOS

I.Delitos: Este catálogo deberá ser obtenido de la información de delitos contenida en la base de datos de Sistema institucional @Justicia, una vez obtenido el catálogo general se tendrá la opción de seleccionar aquellos frecuentes y que son los que se mostraran para su selección en el registro de imputados.

II.Relación: Este catálogo deberá ser obtenido de la información de tipo de relación contenida en la base de datos de Sistema @Justicia, una vez obtenido el catálogo general se tendrá la opción de seleccionar aquellos frecuentes y que son los que se mostraran para su selección en el registro de imputados.

III.Tipo de persona: Imputado, Asesor Jurídico, Juez, Oficial, Administrador.

Descripción del procesoEl usuario responsable del sistema tendrá la capacidad de administrar de forma general e individual los registros contenidos en los catálogos que conformen la aplicación.

ADMINISTRACIÓN GPS

I.Alta: Registro de un nuevo dispositivo capturando el ID del dispositivo GPS y su descripción.

II.Edición: Modificación de campos del dispositivo.III.Borrado: Eliminación de GPS, estos registros solo se borran a nivel de

aplicación. IV.Los dispositivos GPS solo se podrán asignar a un imputado a la vez.V.Al desasignar un dispositivo a un imputado este será elegible para una

nueva asignación.VI.Durante el proceso judicial del imputado se le pueden asignar varios

dispositivos GPS manteniendo su relación histórica.Página 12 de 41


Descripción del procesoEl usuario responsable del sistema tendrá la capacidad de administrar de forma general e individual los registros contenidos en el catálogo de dispositivos GPS.

GEO-CERCAS

I. Creación, edición y administración de Geo-cercas registrando el nombre de identificación, descripción, tipo de geo-cerca (inclusión, exclusión).

II. Las áreas de inclusión, exclusión son identificadas como un punto (dentro de un mapa) representadas por un circulo, rectángulo o polígono cuya dimensión es definible en el sistema.

III. Búsqueda de punto de interés (dirección) en el mapa para facilitar la creación de geo-cerca.

IV. Las áreas pueden ser definidas individualmente para cada imputado.V. Se pueden definir grupos de áreas de exclusión, inclusión. El sistema

permite identificar para cada imputado a qué grupo(s) de áreas aplica el control.

VI. Se controla por cada área (o zona)a) Tipo de zonab) Tipo de figura (circulo, rectángulo, polígono) c) Direcciónd) Ubicación (Longitud, latitud)e) Tolerancia (aplica en áreas de exclusión) en el caso de que

un imputado tenga que pasar cerca cuando esté en traslado.

MONITOREO

I. Desplegar la posición individual o por grupo de los elementos monitoreados en un mapa virtual (tipo mapa o foto aérea) en tiempo real.

II. Los elementos monitoreados serán delimitados según los permisos del usuario.

III. El mapa de deberá de actualizar en un intervalo de tiempo determinado (30 segundos, 1 minuto, 5 minutos, 10 minutos, 30 minutos).

IV. Contar con la opción de selección individual del elemento a monitorear.

Página 13 de 41


V. Acceso rápido a reporte de ubicaciones históricas seleccionando el elemento a monitorear, fecha y hora de inicio y fin.

VI. El reporte de posiciones históricas se deberá desplegar en pantalla realizando un trazado de la ruta del elemento seleccionado.

VII. Desplegar información de cada uno de los elementos mostrados en el mapa como son: estatus del dispositivo, fecha, nombre, alerta (en caso de existir), dirección, porcentaje de batería, asesor responsable.

VIII. El estatus de los elementos monitoreados deberán ser identificados de forma visual (colores).

IX. Al seleccionar un elemento sobre el mapa debe mostrar un cuadro alterno desplegando su información (nombre, asesor jurídico, dirección, alerta, estatus del equipo, porcentaje de batería el cual debe cambiar de color dependiente del nivel de carga del equipo)

X. Se debe contar con la funcionalidad de visualizar la calle en la que se encuentra ubicado el elemento seleccionado (Street View).

XI. El reporte histórico de movimientos está ligado al imputado y numero de caso, de tal manera que un imputado puede tener asignados diversos dispositivos GPS, así como diversos números de casos.

REPORTES

I. Se pueden obtener reportes de posición (ubicación) de imputados con las siguientes opciones:a) Seleccionar rango de fecha y hora.b) Seleccionar un rango de posiciones.c) Histórico de brazaletes por imputado.d) Eventos y alarmas que han ocurrido.

II. Histórico de imputados por selección de dispositivo.III. Alarmas e Incidencias por Imputado.IV. Ficha del imputado con datos generalesV. Geo-cercas

Página 14 de 41


ALERTAS

I. Las alertas serán generadas por las siguientes causas:a) Ingreso a zona de exclusiónb) Salida de zona de inclusiónc) Nivel de batería bajo (30%)d) Falla conductiva en correae) Dispositivo apagadof) Falta de conectividad en el equipo

II. Reportar alarmas a asesores jurídicos responsables del seguimiento del imputado por medio de correo electrónico indicando el nombre del imputado, ubicación física, tipo de alerta, fecha y hora, estatus del dispositivo.

SEGURIDAD

I. Los permisos de ingreso a la aplicación (sistema) y acceso a las funcionalidades del mismo serán definidas de acuerdo a su perfil de usuario establecidos por la Secretaria de Seguridad Publica.

II. Registro de datos generales de la Secretaría de Seguridad Publica (Dirección, teléfono, etc.)

III. Administración de usuario del sistema.- a) Las personas registradas en el sistema tendrán la opción de

brindar acceso al Sistema utilizando su usuario (correo electrónico) y contraseña.

b) Los privilegios serán según el rol asignado (administrador, asesor jurídico, etc.)

c) Asignación individual de brazaletes a supervisar, monitorear.IV. Para el uso de contraseña se deberá utilizar algún tipo de encriptación,

con la finalidad de resguardar la seguridad e integridad de la información.

5. GENERALIDADES

El Proveedor beneficiado será responsable de los actos y conducta de su personal que designe para la prestación de los servicios materia del contrato, por consiguiente se obliga a reparar o indemnizar los daños y perjuicios que éstos causen a los bienes, equipos, programas, mobiliario e instalaciones propiedad de la Secretaría de Seguridad Pública o de terceros. Así mismo, se obliga a que dicho personal observe los lineamientos institucionales de conducta dentro de las instalaciones, la normatividad, controles y

Página 15 de 41


organización en sus Unidades Administrativas y a no divulgar datos o información sobre lo que como consecuencia de sus obligaciones, pudiera conocer de manera circunstancial o fortuita.

Si por causas imputables a el Proveedor beneficiado, resultase dañado algún equipo materia o no del Contrato, propiedad o no de la Secretaría de Seguridad Pública, su reparación será por cuenta y riesgo del Proveedor, y la reparación será realizada a entera satisfacción de la Secretaría de Seguridad Pública, quienes estarán facultados a solicitar la reposición total del bien dañado, y será motivo de rescisión de contrato, si no inicia y termina la reparación en un plazo no mayor a 5 (cinco) días naturales contados a partir de la notificación, salvo que el Proveedor proporcione un equipo de iguales o superiores características hasta que el equipo dañado esté totalmente reparado, el cual no deberá exceder un término de 45 días naturales, ello de manera independiente a que hubiera fenecido la vigencia del contrato.

VI.1 CÓDIGO DE VESTIMENTAEl personal que preste sus servicios y que requiera el ingreso a instalaciones de la Secretaría de Seguridad Pública del Estado deberá observar el siguiente código de Vestimenta:

a. Portar uniforme de la empresa.b. En todo momento el empleado de la empresa portara gafete

de identificación que lo acredite como personal de la misma, el gafete incluirá fotografía reciente del empleado y vigencia.

VI.2 POLÍTICAS DE INGRESOEl ingreso del personal que prestara los servicios deberá observar las siguientes Políticas de Ingreso:

El empleado de la empresa deberá presentar Credencial de Elector que lo acredite como personal de la misma, la identificación incluirá fotografía del empleado, apellido paterno y materno, nombre y fecha de nacimiento.

6. CONSIDERACIONES

a. El desarrollo del sistema se deberá realizar utilizando la plataforma de programación .NET de Microsoft Visual Studio 2013 con tecnologías C#, HTML5, CSS3, JavaScript, Entity Framework 4.5.

b. La base de datos requerida para utilizar el sistema debe ser Oracle en su versión 11g (el servidor y licenciamiento del motor de base de

Página 16 de 41


datos será proporcionado por la Secretaria de Seguridad Pública del Estado).

c. El sistema será una plataforma web cliente-servidor con la facilidad de acceso remoto desde cualquier equipo a través de internet utilizando protocolos avanzados de seguridad.

d. El sistema contratado debe contener integración con el Sistema institucional @Justicia y base de datos de la misma aplicación.

e. Configuración e integración del Software con la Base de Datos y preparación de la aplicación para el inicio de operaciones en el Centro de Datos de la Subsecretaria del Sistema Estatal Penitenciario en Mexicali, asesoría a la Subsecretaria del Sistema Estatal Penitenciario en la recopilación y carga de información preliminar, revisión y validación de la información preliminar, así como la configuración de los parámetros de operación de la aplicación.

a. La integración de la información, datos y registros del sistema serán resguardados en la base de datos del sistema @Justicia, este proceso se realizara por el proveedor bajo la supervisión de la Coordinación de Sistemas de Información y Tecnología de la SSEP.

b. Se debe considerar el licenciamiento requerido para la operación del sistema correcta del sistema e integración de los dispositivos GPS.

c. Se debe entregar Manuales Completos del Sistema en formato Digital (Editables) e Impresos.

d. Para el equipo GPS (brazaletes) requerido en el presente proyecto se debe considerar lo establecido en el “Anexo C”.

e. Para los servicios de transmisión de datos GSM/GPRS se debe considerar la empresa de servicio telefónico celular con mayor cobertura en el Estado, adjuntando documento emitido por parte del proveedor de telefonía en el cual se compruebe la cobertura de servicio de telefonía celular.

7. GARANTÍA DEL SISTEMA Y ASISTENCIA TÉCNICA

GARANTÍA de 12 meses sobre vicios ocultos o fallas que pudieran resultar de la operación del sistema a partir de la puesta en operación del sistema a entera satisfacción de la convocante LLAVE EN MANO.

El proveedor deberá suministrar asistencia técnica al personal de la Mesa de Ayuda de la Subsecretaria del Sistema Estatal Penitenciario en línea (internet) o vía telefónica, durante 12 meses a partir de la puesta en operación del sistema a entera satisfacción de la convocante LLAVE EN MANO, esto como parte de la garantía sobre vicios ocultos o fallas que

Página 17 de 41


pudieran resultar de la operación del sistema. Esta asistencia técnica deberá proporcionarse a través de Internet en horario de 8 a 20 horas y de lunes a viernes.

El proveedor contara con hasta 24 horas para solucionar cualquier falla que no interrumpa la operación del sistema, a partir de que se recibe el reporte vía telefónica o internet. La Coordinación de Sistemas de Información y Tecnología de la Subsecretaria del Sistema Estatal Penitenciario revisaran el caso cuando haya una inconformidad por parte de la mesa de ayuda en el tiempo de respuesta.

Si el problema que se presenta afecta de manera crítica la operación del sistema de autenticación biométrica de la Subsecretaria del Sistema Estatal Penitenciario, es decir que afecte la atención al usuario, tendrá hasta 3 horas para solventar la falla.

8. DE LA RESPONSABILIDAD DEL PROVEEDOR BENEFICIADO

Este anexo técnico establece la referencia de especificaciones técnicas mínimas al proyecto de SISTEMA INTEGRAL DE MONITOREO A IMPUTADOS CON BENEFICIO DE MEDIDA CAUTELAR DE COLOCACIÓN DE LOCALIZADOR ELECTRÓNICO POR GPS.

El Proveedor tiene la responsabilidad final en la correcta planeación, formulación, diseño requeridos para el óptimo funcionamiento del sistema solicitado; bajo el esquema “LLAVE EN MANO”.

El proveedor beneficiado al término del proyecto debe entregar a la Coordinacion de Sistemas de Informacion y Tecnologia de la Subsecretaria del Sistema Estatal Penitenciario el código fuente abierto de la aplicación y licencia institucional de uso ilimitado en el Estado de Baja California y a perpetuidad en formato digital grabado disco DVD y licencia con los derechos por escrito.

Cualquier posible omisión en este anexo deberá ser considerada e incluida por el proveedor adjudicado.

9. DOCUMENTACIÓN Y/O CERTIFICACIONES

Página 18 de 41


Los Licitantes deberán presentar documentación vigente que acredite la Certificación de CMMI (Capability Maturity Model Integration) nivel 3.

Los Licitantes deberán presentar documentación vigente que acredite la Certificación SCRUM Master (Metodología Ágil).

Los proponentes deberán presentar la documentación que acredite la capacidad de su personal para el desarrollo e implementación del proyecto solicitado, mediante plataformas de desarrollo de software .NET de Microsoft.

Los proponentes deberán presentar documento que acredite la Política de Calidad en el servicio por escrito.

El proveedor deberá entregar una carta en papel membretado de su empresa, firmada por el representante legal manifestando bajo protesta de “Decir Verdad”, que se compromete a cumplir con todas las obligaciones que se deriven de este ANEXO TÉCNICO y el contrato que se formalice con motivo de las mismas, así mismo a proporcionar todos los elementos que fueran necesarios para brindar un servicio en óptimas condiciones.

Los documentos deben someterse en conjunto con la propuesta técnica de cada proponente, el no presentar los documentos será causal de descalificación.

Página 19 de 41


ANEXO BESTÁNDARES DE ENTREGABLES

ObjetivoEl propósito de esta guía, es dar a conocer las prácticas que se deberán seguir en la Definición de la estructura de las Bases de Datos.

Buenas prácticas OBLIGATORIASUso de sinónimos

Siempre que se tenga que hacer referencia a objetos de otra BD u schema (otro sistema), deberán utilizarse sinónimos.

Creación y Borrado de usuarios

La creación y borrado de usuarios del sistema debe hacerse utilizando los Procedures: CSIT.SP_CREA_USRBD y CSIT.SP_BORRA_USRBD.

Usuario CSIT No debe utilizarse el usuario CSIT en el sistema, solamente para la invocación de objetos que están en dicho esquema.

Objetos estándares

Ningún objeto que figure en la plantilla estándar de la estructura de las BD podrá ser modificado.

Tablas personalizadas

PROHIBIDO crear tablas con nombres personalizadas (nombres de personas), si se requiere crear tablas temporales para explotar información deberá solicitarse un usuario para que queden dentro de dicho esquema y una vez desocupadas ser eliminadas.

Tablas respaldo

Se deben eliminar las tablas de respaldo que cree la herramienta al realizar modificaciones a las tablas.Ejemplo: herramientas como DBArtisan generan una tabla de respaldo con el mismo nombre + fecha de la modificación + hora (en formato numérico) cada que se altera la tabla.

DELETE/UPDATE ON CASCADE

PROHIBIDO utilizar la modalidad de DELETE/UPDATE ON CASCADE

Campos LONG PROHIBIDO utilizar el tipo de dato LONG o LONG RAW, deberá usarse el BLOB o VARCHAR según sea el caso

Campos VARCHAR

PROHIBIDO utilizar campos de tipo VARCHAR, debe utilizarse VARCHAR2

Campos INTEGERPROHIBIDO utilizar campos de tipo INTEGER, deberá utilizarse el tipo de dato NUMBER especificando su longitud y precisión.

Secuencias en llaves primarias

En el caso de llaves primarias numéricas, deberá existir una secuencia (asignada por código o secuencia de BD, según aplique) por cada tabla, es decir, evitar quemar o asignar secuencialmente las llaves dejando el 1 en un catálogo, el 2 en otro y así sucesivamente, cada tabla deberá empezar en 1.

Tablas catálogo sin llave

PROHIBIDO dejar catálogos sin una llave numérica, por ningún motivo deberán existir catálogos con solamente un

Página 20 de 41


campo de ‘DESCR’ (descripción)

Llaves sencilla para reemplazar posible llave compuesta

PROHIBIDO agregar campos que funjan como llave primaria para sustituir llaves compuestas, ejemplo: agregar un campo numérico secuencial, para reemplazar una llave compuesta formada por ‘materia’ y ‘alumno’ dejando vulnerable (aunque la aplicación lo valide) la posibilidad de truncar la integridad y cardinalidad correcta agregando la misma materia ‘n’ veces al mismo alumno.

ObjetivoEl propósito de esta guía o referencia, es el establecer un estándar para la creación, nomenclatura, coloreado y llenado de un Modelo Físico de las Bases de Datos, de tal manera que sea interpretado de una manera más rápida y aporte la información suficiente sobre la estructura de los datos.

GeneralesModelo de la BD

Formato o Plantilla a usar

El estipulado en el Patrón de Procesos de CSIT, en el caso de sistemas por outsourcing se utilizará el del proveedor, salvo que se especifique lo contrario y entendiendo que cumple con todos los datos que este documento indica.

Herramienta a utilizar

A la que corresponda el formato (plantilla), o la que utilice el proveedor (outsourcing), siempre que se el archivo resultante pueda ser leído por CSIT sin necesidad de requerir una herramienta ajena a la institucional.

Nombre del modelo

El que use el proveedor a menos que se le especifique que siga un estándar en particular.

Agrupación por Caso de Uso

Se deberá hacer un diagrama por cada Caso de Uso del sistema para identificar en particular que parte de la BD está relacionada con él. Todos estos diagramas deberán estar dentro de 1 mismo archivo.

Colores de objetosTablas RGB ColorCatálogos 60,173,193Catálogos solo para CSIT 225,108,108Configuración 0,128,192Estándares 192,192,192Estándares Plus 152,200,136Funciones 40,170,134Packages 255,255,128Procedimientos Almacenados 35,98,135Procesos 253,147,96

Página 21 de 41


Tabla Dummy 240,185,70Tabla con Información concentrada para agilizar Queries 135,98,198Tabla con Información Histórica 192,5,136Tablas para Procesos de única vez 128,0,128Vistas 0,113,113Vistas Materializadas 213,28,32Vistas de otros sistemas 85,106,179Vistas materializadas de otros sistemas 146,46,46Campos RGB ColorLlave primaria 255,255,0Resto de campos 255,255,255 (blanco

)Requisitos del Modelo

Encabezado Debe tener el encabezado que contiene la herramienta donde va el nombre del modelo, versión, autor, etc.

Cada TABLA debe contener

Descripción Dueño Tablespace en el que debe estar (DATOS, IMÁGENES

o CATALOGOS) Derechos

Cada CAMPO debe contener

Descripción Tipo de campo con precisión y longitud (donde

aplique) Valor por default (cuando lo tenga) Valores permitidos (cuando aplique, y con sus

significados) Derechos (si es que se darán a nivel campo) Si es o no requerido (MANDATORY) Si es o no foráneo Si es o no llave primaria

Cada INDICE Tablespace (INDICES) Derechos Columnas que incluye (en el orden indicado)

Cada PROCEDIMIENTO

Descripción Derechos Tablespace (DATOS) Dueño PL/SQL

Cada FUNCION

Descripción Derechos Tablespace (DATOS) Dueño PL/SQL

Cada VISTA DescripciónPágina 22 de 41


NORMAL o MATERIALIZADA

Derechos Tablespace (DATOS) Dueño SQL

Cada SECUENCIA

Derechos Tablespace (DATOS) Dueño Datos inicial, final y de incremento

Cada SINONIMO

Derechos Tablespace (DATOS) Dueño Objeto al que apunta

Cada TYPE

Derechos Tablespace (DATOS) Dueño Datos que lo componen

Cada PACKAGE y PACKAGE BODY

Derechos Tablespace (DATOS) Dueño Comentarios sobre el contenido de cada

procedimiento o función dentro de él. PL/SQL

ObjetivoEl propósito de esta guía o referencia, es el establecer un estándar para la creación de las Bases de Datos, de tal manera que sea interpretado de una manera más rápida y aporte la información suficiente sobre la estructura de los datos.

GeneralesCreación de la BD

Base de Datos institucional

Oracle

Nombre de la BD

El nombre se forma con las siglas del sistema y debe validarse con los DBAs para evitar duplicidad, para las BD en el ambiente de Desarrollo se deberá agregar a dicho nombre ‘DEV’ al final para indicar que se trata de esta.En BD distribuidas o con copia en los municipios se sugiere agregar las siglas del municipio a la BD para su identificación, a excepción de los esquemas que empleen replicación donde se tomarán las condiciones que se requieren para tales efectos.

Página 23 de 41


Tablespaces

Tablespaces default

IMAGENES = donde se guardan todas las tablas que contienen columnas BLOB

BIOMETRICO = donde se guardan las tablas con información biométrica (huellas digitales, reconocimiento facial, reconocimiento de iris, etc.)

DATOS = donde se guardan todos los objetos del usuario (tablas, vistas, funciones, etc.)

INDICES = donde se alojan todos los índices de las tablas (tanto de DATOS como de IMÁGENES)

CATALOGOS = donde se estarían todas las tablas que sean catálogos o configuración, y parámetros

TEMP = dejar por default UNDO = actualmente UNDOTBS SYSTEM = dejar por default

ObjetivoEl propósito de esta guía o referencia, es el establecer un estándar para la nomenclatura de los objetos en las Bases de Datos, de tal manera que sea interpretado de una manera más rápida y aporte la información suficiente sobre la estructura de los datos.

Nombrado de objetosTodos los objetos deberán estar en el schema del sistema al que pertenecen. (ya no serán del CSIT)

Objeto Nombre EjemploCheck Constraint CK_<tabla>_<columnas> CK_INGRESO_ACTIVO

DblinkDBL_<Nombre BD>Nombre de la BD que accesa

DBL_SICUA

Función (Function) F_<nombre> F_DIAS_HABILESÍndice I_<tabla>_<columnas> I_EMPLEADO_SYSUSERLlave Primaria (PK) PK_<tabla> PK_EMPLEADOLlave Foránea (FK) FK_<tabla hija>_<tabla

padre>FK_EMPLEADO_DEPTO

Llave única (UC) UC_<tabla>_<columnas> UC_EMPLEADO_SYSUSERPackage PKG_<nombre> PKG_FOLIOProcedimiento Almacenado (Stored Procedure)

SP_<nombre> SP_ACT_SALDOS

Secuencias SEQ_<nombre> SEQ_TRAMITESinónimo S_<nombre> S_PAISTabla Ver apartado siguienteTrigger TG_<evento>_<tabla> TG_UPD_EMPLEADOType TP_<nombre> TP_DATOS

Página 24 de 41


Vista Normal V_<nombre> V_TRAMITE_PENDIENTEVista Materializada MV_<nombre> MV_MUNICIPIO

Nombrado de TablasTodas las tablas Deberán tener nombres en SINGULAR, en MAYUSCULAS y ser

representativos.

Tablas de Logs (bitácoras)

Las tablas que sean bitácoras de modificaciones a información relevante deberán llevar el prefijo BIT_, en caso de ser el log directo de una tabla deberá llamarse igual que dicha tabla con el prefijo indicado.

Tablas de Historiales

Las tablas que se refieran a historiales deberán llevar el prefijo HIST_ y llamarse igual que la tabla de la que salió la información.

Nombres compuestos

En el caso de nombres compuestos deberán abreviarse lo más posible sin perder lo representativo, tener un máximo de 2 palabras y para hacer la separación de estas palabras con ‘_’.

Abreviaciones de tablas en nombres de objetos

Al abreviar los nombres de las tablas dentro de los nombres de otros objetos (ejem: índices, llaves foráneas, etc.), ésta deberá ser consistente en todas las partes donde se emplee.

Tablas HijasLas tablas hijas, por ejemplo: el detalle de un RECIBO, deberán llevar el mismo nombre de la tabla padre + la terminación _DET. Ejemplo: RECIBO y RECIBO_DET

Tablas de la misma CLASE

Cuando una clase (clase de análisis (OO)), se divida en varias tablas, se debe procurar mantener el mismo nombre con el complemento al final de lo que se refiere.Ejemplo: TRAMITE, TRAMITE_DET, TRAMITE_FIRMA, TRAMITE_RECHAZO, etc.

Caracteres No Válidos

No deberán usarse acentos, ‘ñ’ o ‘Ñ’ y demás caracteres especiales en los nombres de los objetos a excepción del ‘_’

Nombres Propios Ningún objeto debe contener nombres propios de municipios, dependencias, personas, o cualquier otro.

Idioma Ningún objeto (inclúyanse campos) deberá tener nombres en cualquier otro idioma que no sea español (mexicano).

ObjetivoEl propósito de esta guía o referencia, es el establecer un estándar para el acceso a las aplicaciones y Bases de Datos.

Generales

Página 25 de 41


Esquema

Cada Base de Datos podrá contener varios sistemas.Todos los objetos de un sistema deberán estar en un esquema propio, los únicos objetos que deben pertenecer al esquema CSIT son los estándares. 1 Sistema = 1 esquema

Usuario de DBLINK

Se deberá crear 1 usuario por cada dblink necesario y con la siguiente nomenclatura:‘U_’+ siglas de la BD a la que se accesa

Usuario de consulta

Si se necesitara acceso a una BD de producción se creará un usuario de CONSULTA, donde solamente tendrá derechos de SELECT sobre las tablas del sistema.

Autentificación para los sistemas

La autentificación para el acceso a los sistemas deberá ser empleando un USUARIO y CONTRASEÑA o AUTENTICACION BIOMETRICA. Se descarta el empleo de Servicios de Directorio.

Password del usuario de sistema

El password del usuario de aplicación deberá estar encriptado y se usará el algoritmo creado por el proveedor para tales fines, debiendo proporcionar las funciones para desencriptar.

Rol de BD para el Usuario de BD

Deberá existir un solo rol de Base de Datos para todos los usuarios de Base de Datos que correspondan a un usuario de la aplicación y tendrá acceso a todos los objetos del esquema de dicho sistema (cuidar no darle derechos de más).

Opciones o procesos del sistema

Todos los procesos que forman al sistema y son desplegados a manera de menú (generalmente) deberán estar dentro de una tabla en la BD para asignar de manera dinámica los accesos a los roles.

Derechos dentro de procesos

Deberá considerarse la estructura para la administración de derechos dentro de las mismas pantallas del sistema (dentro del proceso), es decir, detallar más los accesos a las opciones dentro de 1 proceso o pantalla en particular (ver plantilla del modelo de BD estándar).

Derechos a procesos por Roles de sistema

Dentro del sistema deberán existir Roles a los cuales se asignarán los accesos a las opciones del sistema.

Roles de sistema por usuario

El usuario de la aplicación podrá tener ‘n’ roles dentro del mismo, resultando sus accesos como la suma de todos los accesos de sus roles.

Para sistemas de escritorioUsuario verificador de acceso

Deberá existir 1 usuario para validar el acceso al sistema (ver plantilla del modelo de BD estándar) el cual tendrá solamente derechos sobre las tablas para verificar si el usuario que se está

Página 26 de 41


intentando firmar dentro del sistema existe, coincide su password y tiene al menos 1 rol para accesar a él. Una vez verificada está información se desconectará y procederá a realizar el acceso con el usuario de la aplicación.

Password del usuario de Base de Datos

El password del usuario de Base de Datos no deberá ser igual al usuario de BD y deberá estar almacenado en una tabla (ver plantilla del modelo de BD estándar) también encriptado utilizando el algoritmo creado por el proveedor para tales fines, debiendo proporcionar las funciones para desencriptar.

Para sistemas WEBConexión a la BD Para efectos de conexión a la BD se utilizará un Connection Pool

ObjetivoEl propósito de esta guía o referencia, es el establecer un estándar para la nomenclatura de los objetos en las Bases de Datos, de tal manera que sea interpretado de una manera más rápida y aporte la información suficiente sobre la estructura de los datos.

Generalidades

Todos los camposDeberán tener nombres representativos y en MAYUSCULAS, excepto: cuentas de correo electrónico

Formato de fecha DD/MM/YYYY, debe grabarse con hora cuando lo amerite

Fecha Deberá leerse del servidor de BD o de aplicaciones, nunca del lado del cliente.

Llaves primarias Procurar que sean numéricas. Tratar de evitar llaves compuestas con fechas o

textos.Campo de la llave primaria

El campo de la llave primeria será ID, a excepción de llaves compuestas.

Campos que contienen nombres de objetos de BD

Cuando se utilicen campos para almacenar los nombres de objetos de BD este deberá llevar en el nombre la terminación ‘BD’

ConvencionesCampo ParaDESCR Descripción o nombreOBSERV ObservacionesSTATUS Estatus de las figuras que aplique. Deberá ser numérico y

Página 27 de 41


tener su catálogo obligatorio aunque estos no llegaran a variar.

Fechas Inician con FEC_ + significadoConsecutivos CONSEC + de que es consecutivo

RFCRegistro Federal de Causantes, el cual se utiliza como identificador de las personasPersonas Morales: cadena de caracteres de longitud 9Personas Físicas: cadena de caracteres de longitud 10

HOMO Homoclave del Registro Federal de Causantes, cadena de caracteres de longitud 3

CURP Clave Única de Registro de Población: cadena de caracteres de longitud 18

Nombres de personasSeparar por: PATERNO, texto de 30 MATERNO, texto de 30 NOMBRE, texto de 40

DomiciliosSeparar por: CALLE (texto o catálogo) NUMERO EXTERIOR (NUM_EXT, número de 6) NUMERO INTERIOR (NUM_INT, texto de 6)

TeléfonoSeparar: TELEFONO, numérico: sin guiones, ni paréntesis. EXTENSION, texto (para que puedan agregar varias,

separadas por algún carácter)

Ubicaciones

CSIT tiene sus catálogos estándar de: PAIS ESTADO MUNICIPIO LOCALIDAD COLONIAS DELEGACIONES TIPO DE CALLE TIPO DE COLONIA TIPO DE LOCALIDADPor lo que cualquier sistema deberá apegarse a dichos catálogos

SEXO CHAR(1) = ‘F’emenino / ‘M’asculino

ObjetivoEl propósito de este documento es proporcionarle al proveedor o desarrollador la mayor cantidad de información posible respecto a las validaciones básicas que debe contener un Reporte dentro del sistema y que deben ser consideradas al momento de desarrollarlo.

Página 28 de 41


En la elaboración de un Reporte como mínimo se deben de observar las siguientes consideraciones:

1. Cuidar los accesos por Usuario a la información que este pueda: Consultar, Insertar y Modificar dentro del sistema.

2. En lo mayor posible obtener datos que puedan ser utilizados por el mismo sistema, por ejemplo: Fecha y Hora de captura, Usuario, Estado, Municipio, CERESO.

3. Las siguientes opciones deben considerarse dentro de todo Reporte , a menos que el sistema requiera lo contrario:

a) Generarb) Limpiar c) Guardar Comod) Imprimir

4. Al definir los criterios de búsqueda de Información:a) Campos Textos :

i. No deberá de permitir realizar búsquedas sobre espacios en blancos o campos vacíos.

ii. Los datos deberán de capturarse en mayúsculas siempre y cuando no corresponda específicamente al dato de correo electrónico el cual deberá de ser en minúscula.

iii. Deberá de validarse longitud y precisión respecto a la Base de Datos.

iv. De preferencia en este tipo de campos, las búsquedas deberán permitir realizarlas sobre palabras clave o comodines, cuando el proceso así lo requiera y el volumen de información lo permita en lo más posible.

b) Campos Numéricos:i. Solo deberá de permitir capturar números y decimales

cuando así se requiera.ii. Validar longitud y precisión con la especificada en el

campo correspondiente en Base de Datos.c) Radio Button:

i. Si el criterio de búsqueda se realiza por radio button siempre debe estar uno señalado como default.

d) Si dentro del Reporte se utilizan como ejemplo :Listas desplegables, Combo Box, y de este depende la información de:

i. Otro Lista Desplegable, Combo Box, óii. un detalle, validar que la información de este se filtre en

base al registro señalado en la Lista o Combo Box Padre.e) Sobre Campos con Formato determinado (Fechas, RFC,

Teléfono, etc.)Página 29 de 41


5. Al generar la Información:a) La información arrojada siempre podrá ser impresa, a menos que el

sistema por política no lo permita.b) Dicha Información no podrá ser editable desde el proceso de emisión

del Reporte.c) Cuidar en lo mayor posible que la información desplegada en el

Reporte se muestre agrupada y ordenada a solicitud del usuario.d) Al realizar la búsqueda utilizando rangos se solicita que al mostrar el

resultado de la búsqueda esta:i. Se muestre ordenada ii. De opción al usuario de seleccionar el registro deseado

para visualizar el detalle del mismo.e) Debe considerar en lo mayor posible utilizar “listas multiselección” en

las cuáles el usuario pueda seleccionar una, todos o algunas de las opciones de la lista, para filtrar la información.

6. Lo que internamente se debe hacer: a) Se deberá de validar toda sentencia de programación que

requiera evaluación como por ejemplo: condiciones de lógica, SQL, resultados de operación que se consideren erróneos, etc., según sea el lenguaje utilizado.

b) Se solicita que como mínimo se registren los siguiente datos a manera de bitácora sobre aquellos Reportes que por evaluación preliminar se determine que así se requiere de:

i. Quien genera el Reporteii. Que es lo que se está consultando.iii. Fecha y Hora en la que se está realizando la consulta.

7. Respetar en todo momento la navegación en los Reportes.8. Respetar en todo momento los mismos criterios, iconos y mensajes de

confirmación en todas las acciones del Reporte.

Para la elaboración de un catálogo como mínimo se deben de observar las siguientes consideraciones:

1. Las siguientes opciones deben considerarse dentro de todo catálogo , a menos que el sistema defina lo contrario:

a) Insertar b) Buscarc) Limpiar d) Guardar e) Generar Reportef) Editar/Modificar

Página 30 de 41


2. No dejar sujetos los catálogos a valores fijos dentro del sistema, a manera de ejemplo a: roles, puestos, usuarios.


4. En lo mayor posible obtener datos que puedan ser utilizados por el mismo sistema, por ejemplo: Fecha y Hora de captura, Usuario, Estado, Municipio.

5. Parametrización en lo mayor posible de datos a manera de ejemplo: Estado, Municipio, Tipo de caso.

6. El campo que represente la llave primaria no se deberá de capturar, sin embargo su valor deberá ser visible para el usuario y este deberá corresponder a una secuencia numérica dentro de la Base de Datos del Sistema.

7. Sobre la captura de campos textos: a) Nunca podrán ser espacios en blanco. b) Los datos deberán de capturarse en mayúsculas siempre y

cuando no corresponda específicamente al dato de correo electrónico el cual deberá de ser en minúscula.

c) Deberá de validarse longitud respecto a la Base de Datos.d) Validar campos Nulos a menos que el catálogo requiera lo

contrario.e) Radio Button:

i. Si el catálogo hace referencia a radio button siempre debe estar uno señalado como default.

8. Validar caracteres especiales en los campos, a menos que se requiera lo contrario.

9. Sobre la captura de campos Numéricos:10.Solo se podrán capturar números y decimales cuando así se requiera.11.Deberá de validarse las longitudes y precisiones de los campos

respecto a la Base de Datos.12.Deberá de realizar borrados lógicos, es decir darle la opción de activar

y desactivar un registro cuando el usuario así lo considera necesario para el buen funcionamiento del sistema. Al momento de desactivar en cualquier otra parte del sistema donde se utilice dicho catálogo este registro no deberá de aparecer, sin embargo, la información ligada a este status deberá de permanecer integra y podrá ser visible a menos que el sistema requiera lo contrario.

13.Para los casos en los que el nivel de detalle sea:a) Maestro- Detalle:

i. Se deberá de considerar que el detalle será filtrado en base al registro seleccionado en el maestro.

Página 31 de 41


ii. El borrado en este tipo de catálogo también deberá de ser lógico tanto para el maestro como el detalle.

iii. Para el borrado en el maestro, deberá de considerar que no se podrá realizar si este tiene detalles activos.

b) Lista Desplegables, Combo Box, etc.:i. El detalle del catálogo se filtrara en base al registro

seleccionado por la lista Desplegable, Combo Box maestro.

ii. Deberá de permitir borrados lógicos en el detalle.c) Tree View:

i. Al momento de mover un registro hacia otra rama del árbol validar que este no se repita y que este no tenga sub ramas.

ii. Para realizar el borrado se deberá de empezar por el último nivel de detalle de las sub ramas hacia arriba y así sucesivamente y este deberá ser un borrado lógico.

14.Validar los datos que sean identificados como obligatorios al procesar y mostrar en forma clara al usuario.

15.Se registraran los siguiente datos a manera de bitácora sobre aquellos catálogos que por evaluación preliminar se determine que así se requiere de:

a) Quien realiza el cambio (Usuario de aplicación)b) Que es lo que se está modificando, agregando o borrando

(Valor anterior, Valor actual)c) Donde se está realizando el cambio (Tabla o Tablas afectadas)d) Fecha y Hora en la que se está realizando el cambio.

16.Todo Catálogo deberá validar que no se dupliquen registros tanto en la alta como en las modificaciones.

17.La información presentada en los catálogos deberá de estar ordenada en forma alfabética en forma ascendente o descendente, según se defina por el sistema. Para el caso en donde se determine que se mostrará la información que haya sido dada de baja (borrado lógico), esta también deberá de aparecer ordenada en forma alfabética ascendente o descendente según se defina, pero deberá de aparecer al final de la información activa.

18.Considerar en la opción de Generar Reporte, el permitirle al usuario seleccionar si desea imprimir solo la información activa o incluir los datos que se encuentren inactivos (borrado lógico). Toda la información deberá de aparecer ordenada en forma ascendente o descendente alfabéticamente según se haya definido, en el caso de incluir los datos inactivos estos deberán de aparecer al final de la

Página 32 de 41


información activa y estos datos también deberán de aparecer ordenados en forma ascendente o descendente alfabéticamente.

19.Respetar en todo momento la navegación en los catálogos, es decir siempre deberá de ser la misma entre ellos.

20.Respetar en todo momento los mismos criterios, iconos y mensajes de confirmación en todas las acciones del catálogo.

21.La información insertada o modificada en el sistema no se reflejará en Base de Datos, hasta que el usuario lo indique mediante una opción de ‘Guardar’.

En la elaboración de una Consulta como mínimo se deben de observar las siguientes consideraciones:


2. No dejar sujetos las consultas a valores fijos dentro del sistema, a manera de ejemplo a: roles, puestos, usuarios.

3. En lo mayor posible obtener datos que puedan ser utilizados por el mismo sistema, por ejemplo: Fecha y Hora de captura, Usuario, Estado, Municipio, Cereso.

4. Las siguientes opciones deben considerarse dentro de toda consulta , a menos que el sistema requiera lo contrario:

a) Buscarb) Limpiar c) Guardar d) Generar Reporte, basado en los criterios de la consulta y con el

formato de presentación que se indique.Así como:

5. Utilización de los parámetros en lo mayor posible para la obtención de la Información.

6. Lo que se encuentre catalogado deberá de permitir seleccionar el valor de una lista desplegable y que estos datos correspondan a los activos, a menos que la consulta requiera lo contrario.

7. Cuando los criterios de búsqueda sean:a) Textos:

v. Deberán de capturarse siempre en Mayúscula.vi. Deberá de Validarse la longitud de la captura con el

campo correspondiente especificado en Base de Datos.vii. No deberá de permitir realizar búsquedas sobre espacios

en blancos o campos vacios.viii. Dar formato al campo según la necesidad de la captura.

Página 33 de 41


ix. De preferencia en este tipo de campos, las búsquedas deberán permitir realizarlas sobre palabras clave o comodines, cuando el proceso así lo requiera y el volumen de información lo permita en lo más posible.

x. Validar campos Nulos a menos que la consulta requiera lo contrario.

e) Numéricos:i. Solo deberá de permitir capturar números y punto

decimal cuando este sea requerido.ii. Validar longitud y precisión con la especificada en el

campo correspondiente en Base de Datos.f) Radio Button:

i. Si la consulta hace referencia a radio button siempre debe estar uno señalado como default.

g) Si dentro de la Consulta se utilizan Listas Desplegables y de este depende la información de:

i. Otro Lista Desplegable, óii. Un detalle validar que la información de este se filtre en

base al registro señalado a la Lista Desplegable Padre.h) Al utilizar rangos (Inicio-Fin) se solicita que al mostrar el

resultado de la búsqueda esta:i. Deberá de presentarse en forma ascendente o

descendente, según sea requerido.ii. De opción al usuario de seleccionar el registro deseado

para visualizar el detalle del mismo, si la consulta así lo requiere.

8. Sobre el Resultado de la Búsqueda:a) Todos los criterios de búsqueda son Incluyentes.b) No se permitirá realizar modificaciones de información desde

este proceso, a menos que por políticas del sistema requiera lo contrario.

c) La información arrojada siempre podrá ser impresa, a menos que el sistema por política no lo permita.

d) Cuidar en lo mayor posible que la información desplegada en la consulta en lo general se muestre en forma lógica, entendible y fácil para el usuario.

e) La información deberá de presentarse ordenada de tal forma como fue requerida por el usuario y permita ordenar por cualquier columna de las presentadas en la consulta, sin alterar los grupos.

9. Lo que se debe generar internamente de la consulta:

Página 34 de 41


a) Se solicita que como mínimo se registren los siguiente datos a manera de bitácora sobre aquellas consultas que por evaluación preliminar se determine que así se requiere de:

i. Quien realiza la consulta.ii. Que es lo que se está Consultando.iii. Fecha y Hora en la que se está realizando la consulta.

b) Se deberá de validar toda sentencia de programación que requiera evaluación como por ejemplo: condiciones de lógica, SQL, resultados de operación que se consideren erróneos, etc., según sea el lenguaje utilizado.

10.Debe considerar en lo mayor posible utilizar “listas multiselección” en las cuáles el usuario pueda seleccionar una, todos o algunas de las opciones de la lista, para filtrar la información.

Nota: Cuando se traten de aplicaciones WEB, la consulta no deberá de presentar información que comprometa el performance de la aplicación hasta que se indiquen todos los criterios de búsqueda.

En la elaboración de un Proceso como mínimo se deben de observar las siguientes consideraciones:


2. En lo mayor posible obtener datos que puedan ser utilizados por el mismo sistema, por ejemplo: Fecha y Hora de captura, Usuario, Estado, Municipio, Cereso, etc.

3. Las siguientes opciones deben considerarse dentro de todo proceso, a menos que en el sistema se definan otros requerimientos:

a) Insertarb) Editar/Modificarc) Consultard) Imprimir

Así como:4. Parametrización en lo mayor posible los datos.5. No dejar sujetos los procesos a roles, puestos, usuarios, fijos dentro del

sistema.6. Debe considerar en lo mayor posible utilizar “listas multiselección” en

las cuáles el usuario pueda seleccionar una, todos o algunas de las opciones de la lista, para filtrar la información, cuando el proceso así lo requiera.

7. Respetar en todo momento la navegación en los procesos, tratar de dejarlo lo más uniforme posible entre ellos.

Página 35 de 41


8. Respetar en todo momento los mismos criterios, iconos y mensajes de confirmación en todas las acciones de los procesos.

9. Validar caracteres especiales en los campos, cuando el proceso así lo requiera.

10.En la captura de:II. Campos Textos :

i. Deberán de capturarse siempre en Mayúscula, a excepción del correo electrónico este se deberá de capturar solo en letra minúscula.

ii. Deberá de Validarse la longitud de la captura con el campo correspondiente especificado en Base de Datos.

iii. Nunca deberá de permitir espacios en blancos como dato en un campo.

iv. Dar formato al campo según la necesidad de la captura.v. Validar campos Nulos cuando el proceso así lo requiera.

III. Campos Numéricos:i. Solo deberá de permitir capturar números y decimales

cuando el proceso así lo requiera.ii. Validar longitud y precisión con la especificada en el

campo correspondiente en Base de Datos.IV. Radio Button:

a) Si dentro del proceso se utilizan radio button siempre debe estar uno señalado como default.

V. Si dentro de un Proceso se utilizan Listas Desplegables y de este depende la información de:

a) Otro Lista Desplegable, ob) Un detalle, validar que la información de este se filtre en

base al registro señalado en la lista desplegable Padre.VI. En caso de que el proceso requiera que se muestre información

de catálogos, solo deberá de mostrarse los datos activos del mismo, a menos que el proceso requiera lo contrario.

11.Cuando el proceso requiera hacer uso de estatus, se deberá de considerar el manejar un estatus en “Captura” o “Borrador”, que le permita al usuario iniciar y después continuar con la captura.

12.Al Procesar:a) En caso de que el proceso sea “Exitoso” deberá de enviar

mensaje de Aviso o Confirmación, según la necesidad del Proceso.

b) Se deberá de validar toda sentencia de programación que requiera evaluación como por ejemplo: condiciones de lógica, SQL, resultados de operación que se consideren erróneos, etc., según sea el lenguaje utilizado.

Página 36 de 41


c) Si el proceso requiere agrupar información, estos deberán de estar ordenados y llevar una secuencia lógica de la información dentro de los mismos.

d) Validar los campos nulos cuando se requiera.e) Validar caracteres especiales en los campos cuando se requiera.f) Validar los datos requeridos e indicar de forma clara al usuario

cuáles corresponden y hacen falta de capturar.g) Se solicita que como mínimo se registren los siguiente datos a

manera de bitácora sobre aquellos procesos que por evaluación preliminar se determine que así se requiere:

a) Quien realiza el movimiento.b) Que es lo que se está modificando, agregando o borrando

(Valor anterior, Valor actual).c) Donde se está realizando el cambio (Tabla o Tablas

afectadas).d) Fecha y Hora en la que se está realizando el cambio.

Para Aplicaciones Cliente Servidor:

h) En caso de existir algún “Error”, enviar mensaje de “Error” que sea lo más claro posible para que el usuario lo pueda interpretar.

Para aplicaciones Web:i) En caso de existir algún “Error”, enviar mensaje, de tal forma

que el usuario quede conforme con la aplicación e intente realizar la transacción en la brevedad posible.

j) Deberá de guardarse en bitácora cada “error” detectado, y deberá de quedar guardada en el servidor de la aplicación.

k) Cuando se generen excepciones crear bitácora de estas la cual deberá de quedar guardada en el servidor de la aplicación.

13.La información insertada o modificada en el sistema no se reflejará en Base de Datos, hasta que el usuario lo indique mediante una opción de ‘Guardar’, salvo procesos que previa justificación lo requieran diferente.

Página 37 de 41


ANEXO CESPECIFICACIONES DE EQUIPO Y SERVICIOS

PARTIDA 2BRAZALETE ELECTRÓNICO GPS

CANTIDAD 20

MARCAS DE REFERENCIAGoSafe

MODELO DE REFERENCIAG737IC-GPS/GSM-Tracker

CARACTERISTICAS Modem 4 Bandas GSM/GPRS (850/900/1800/1900 Mhz) Módulo GPS de alta sensibilidad Batería de larga duración Indicador de batería Comunicación GPRS + SMS

Página 38 de 41


Manejo de Geo-Cercas detección contra forcejeo o intento de desinstalación Diseño compacto Diseño IP67 a prueba de agua Modos de comunicación: GPRS/ GSM, Datos (TCP/IP, UDP) y SMS GPS de alta sensibilidad Botones: Encendido/Apagado, Alarma/SOS (Alerta y solicitud de

ayuda) Indicador de Estado: GPS/ Encendido Extensible para tobillo o muñeca: tamaño de extensible

ajustable. Alimentación Eléctrica: Cargador de 5V DC Ranura SIM Card integrada en PCBA Conector Mini USB

INCLUIR Cargador de pared Cable Mini USB (para configuración)

GARANTÍA1 Año por parte del fabricante. El trámite de la garantía será entera responsabilidad del proveedor adjudicado, quien tendrá que acudir al sitio para su diagnóstico y gestión ante el fabricante para su reparación o cambio de equipo, los gastos generados por estos eventos serán costeados por el proveedor beneficiado.

PARTIDA 3LICENCIA GOOGLE MAPS API

CANTIDAD 1

MARCAS DE REFERENCIAGoogle Maps API for Works

FUNCIONALIDADES Interface programática de disponibilidad pública para consumir

servicios web con fines de ubicación geográfica orientada a usuarios con alto volumen de consumo

Servicio web con capacidad de obtener una coordenada a partir de una dirección codificada en texto

Servicio web de conversión de coordenada a dirección en texto Servicio de imágenes cartográficas (mapas) y satelitales,

actualizadas para servicio corporativo (más actualizadas que el servicio disponible al público en general)

Volumen de consultas: 1,000,000 / pageviews 4 Sets 250,000 Visualización a nivel de calle (street view)

Página 39 de 41


Servicio web de rutas hasta por 10,000 solicitudes diarias con 23 puntos de referencia por solicitud

Servicio web denominado Distance Matrix para consulta de recorridos, consta de 625 elementos por consulta, 1000 elementos cada 10 segundos y hasta 100,000 elementos al día

Resolución máxima de la API Static Maps de 2,048 x 2,048 La escala máxima de la API de imágenes de Street View es de

4X Resolución máxima de la API de imágenes de Street View es de

2,048 x 2,048 Permite la incorporación de capas de datos demográficos

INCLUIR Recursos para desarrolladores de la API de Google Maps Software en idioma inglés. Medio de entrega físico o a través de medios digitales como

portal de internet para su descarga. Manuales completos de la solución en medios físicos o a través

de medios digitales como portal de internet. Soporte técnico y licencia con vigencia de 2 años a partir de la

contratación correspondiente a 1,000,000 de pageviews por año.

Página 40 de 41


PARTIDA 4SERVICIO DE TRANSMISIÓN DE DATOS

CANTIDAD 20

DESCRIPCIÓNServicio de trasmisión de datos GPRS/GPS aplicable para los brazaletes de monitoreo a imputados con soporte por dos años.

INCLUIR Tarjeta SIM de operador de servicio de transmisión de datos

GSM/GPRS activos, se debe considerar la empresa de servicio telefónico celular con mayor cobertura en el Estado.

El volumen de datos (MegaBytes) necesarios para la operación continúa de los dispositivos de posicionamiento GPS durante 2 años.

GARANTÍAEn caso de presentarse daño en la tarjeta SIM esta será remplazada por el proveedor adjudicado con un tiempo de respuesta de 24 horas en las oficinas de la Secretaria de Seguridad Pública del Estado ubicado en De los Héroes y De la Libertad Número 399 Código Postal 21000.

Página 41 de 41

· Web viewEl objetivo de la Medida Cautelar a través del dispositivo electrónico, es disminuir...

Documents

Transcript of · Web viewEl objetivo de la Medida Cautelar a través del dispositivo electrónico, es disminuir...