REQUERIMIENTOS NO FUNCIONALES. 9.1 Logging
REQUERIMIENTOS NO FUNCIONALES. La Dependencia o Entidad tendrá acceso a las versiones que se liberen de los productos descritos en el numeral 2.1 Familia de Productos, adquiridos durante la vigencia del contrato. Para el caso de licenciamiento el Proveedor deberá permitir la transferencia de derechos de uso de la licencia entre Dependencias o Entidades Públicas
9. Vigencia del contrato
REQUERIMIENTOS NO FUNCIONALES. El contrato plurianual de Arrendamiento de Bienes de Tecnología de la Información y las Comunicaciones (TIC), tendrá una vigencia de 36 meses de servicio, no considerando los días de entrega e instalación de los equipos descritos como resultado del procedimiento de adquisición o contratación. Los bienes en arrendamiento seguirán siendo propiedad del licitante adjudicado. Las propuestas técnicas y económicas deberán presentarse con fecha de fabricación menor o igual a dos años. Se requiere garantía en sitio de 3 años por parte del fabricante, mano de obra y refacciones con un tiempo de respuesta en un plazo no mayor a 24 horas. La garantía se deberá gestionar por el licitante ganador, quien será el responsable de revisar el equipo y tramitar ante el fabricante su reparación o situación. Se requiere una póliza de seguro contra robo para todos los bienes en arrendamiento y adicional, una póliza de seguro contra caídas y derrame de líquidos para las computadoras portátiles. Durante el mes 18 del contrato, el licitante adjudicado realizará un mantenimiento preventivo a todos los equipos que formen parte del contrato, el cual consiste en: Hacer una inspección física del equipo y sus periféricos para detectar características especiales como rayones, manchas, golpes etc. Verificar el correcto funcionamiento de cada uno de los periféricos y componentes principales del equipo. Si existen problemas de un grado considerable de complejidad se debe informar a la UTIC que el equipo necesita un mantenimiento correctivo. Informar al usuario todos los detalles encontrados en el equipo antes de dar inicio al mantenimiento preventivo. Limpieza exterior e interior del equipo con elementos físicos y químicos y aspirado de componentes internos. Entregar el equipo al usuario y obtener la firma del formato como evidencia de que es recibido a satisfacción. Al final del programa de mantenimiento entregar a la UTIC un reporte con las evidencias del resultado del programa.
REQUERIMIENTOS NO FUNCIONALES. Los requerimientos no funcionales que aplican de manera obligatoria para todos los módulos a desarrollar o ítems a contratar, son el conjunto de características técnicas que debe poseer el aplicativo de software para lograr atender con eficiencia y eficacia las funcionalidades que se implementen en el SI. Los requerimientos no funcionales pueden usarse como criterios para juzgar la operación o desempeño del sistema, pueden interpretarse como restricciones o condiciones que deben tomarse en cuenta en la construcción del sistema. Así por ejemplo, un requerimiento no funcional es la condición de lograr una velocidad mínima de respuesta del software, requerimiento que a su vez debe ser cumplido por los requerimientos funcionales. Las actividades a realizar por el proponente seleccionado comprenden la verificación del cumplimiento de los requisitos no funcionales establecidos en el documento elaborado por la firma desarrolladora durante la etapa de análisis y diseño. Además se requiere realizar las pruebas que se mencionan en el cuadro siguiente para garantizar la adecuada y eficiente operación del aplicativo en términos de tiempos de respuesta, compatibilidad con varios navegadores, seguridad, accesos concurrentes y parametrización, así: 1 Verificación de desempeño Probar accesos de usuarios con diferentes tipos de conexiones (56, 128, 256 y 512 Kbps; y 1, 2, 4, 8, 12 y 16 MB para observar la velocidad de respuesta del sistema.
REQUERIMIENTOS NO FUNCIONALES. SHF tendrá acceso a las versiones quo se liberen de los productos descritos en el numeral
REQUERIMIENTOS NO FUNCIONALES a) Requerimientos de Seguridad
i. Propiedad de los datos
REQUERIMIENTOS NO FUNCIONALES. SHF tendrá acceso a las versiones que se liberen de los productos descritos en el numeral 2.1 Familia de Productos, adquiridos durante la vigencia del contrato. Para el caso de licenciamiento el Proveedor deberá permitir la tr nsferencia de derechos de uso de la licencia entre Dependencias o Entidades Públicas. e
REQUERIMIENTOS NO FUNCIONALES. El Posible Proveedor, deberá tener la capacidad técnica de prestar el servicio o asegurarse que el mismo pueda ser ofrecido en todo el territorio nacional de acuerdo con los requerimientos descritos en el presente Anexo Técnico. El Posible Proveedor deberá proporcionar instrucciones para la generación de las credenciales de acceso a la consola de administración del Servicio de Nube Pública con rol de administrador global de la suscripción de Nube, mismas que serán proporcionadas a la Dependencia o Entidad. Dentro de los 10 días hábiles posteriores a la notificación de la adjudicación, se llevará a cabo la reunión de inicio del proyecto entre la Dependencia o Entidad y el Proveedor adjudicado, con el objeto de formalizar la designación del personal del Proveedor que asumirá los roles que deriven de la contratación, así como los responsables de ambas instancias y los canales de comunicación autorizados. De lo anterior, el proveedor deberá entregar Documento de designación de personal responsable y canales de comunicación con la Dependencia o Entidad, como se describe en el numeral 18.2 Entregables Generales. Roles principales en el servicio por parte del Posible Proveedor El Posible Proveedor deberá definir al menos los siguientes roles principales, para poder garantizar la prestación de los servicios a entera satisfacción: Administrador de cuenta por parte del Posible Proveedor. Supervisor del contrato por parte del Posible Proveedor.
REQUERIMIENTOS NO FUNCIONALES. Compatibilidad con navegadores web: la herramienta deberá ser al menos compatible con Internet Explorer 11 y Firefox. • Multiidioma castellano - euskera. • Sistema securizado mediante credenciales de acceso. • Escalabilidad del Sistema ante la previsión de crecimiento de esta red de puntos de conteo. • Acoplamientos: ◦ Se deberá indicar el grado de dependencia que los dispositivos de conteo tienen con la herramienta de gestión central ofertada. ◦ También deberán indicarse las dependencias del sistema de información con otros productos propietarios. • Interoperabilidad: deben cumplirse las siguientes características: ◦ Interoperabilidad de los sistemas de conteo y del sistema de información con otros sistemas en formatos abiertos: API, Servicios Web ... ◦ Posibilidad de integrar los datos de conteo de otros sistemas. ◦ Exportación de la información a ficheros en diferentes formatos: ODS, CSV, XML,… • Ubicación física y material asociado: Se valorará positivamente que el sistema de información se implante en el CPD de GN frente a otras posibilidades. En tal caso, el despliegue será responsabilidad de los técnicos de la DGITIP con el soporte del proveedor, y la solución deberá ajustarse al Escenario Tecnológico de Gobierno xx Xxxxxxx, descrito en /Escenario%20Tecnologico%20Gobierno%20de%20Navarra%20Marzo%202018% 20v1.0.pdf
REQUERIMIENTOS NO FUNCIONALES. Mejorar la experiencia: Rediseñar la interfaz de Ciudadano Digital basado en los datos que se han obtenido desde su lanzamiento para que los usuarios realicen los trámites de forma más cómoda y rápida. Desarrollar el módulo para que el usuario guarde sus tarjetas de débito o crédito. Unificar registro y trámites en una sola plataforma Empresario Digital y Ciudadano Digital. REQUERIMIENTOS FUNCIONALES: Carta de no antecedentes penales electrónica