ANEXO TECNICO Y OBLIGACIONES DEL CONTRATISTA

ANEXO No. 1

ANEXO TECNICO Y OBLIGACIONES DEL CONTRATISTA

1. ALCANCE DEL CONTRATO

El desarrollo de este contrato comprende el diseño y desarrollo del sistema de información para el producto FAG -Fondo Agropecuario de Garantías y la migración de la base de datos histórica de DB2 a SQL-SERVER. En la modalidad de Fábrica de software.

2. GLOSARIO

● FAG. Fondo Agropecuario de Garantías

● Servicios Sistema de información que gestiona la administración y expedición de garantías del FAG.

● Garantías. Transacciones de aval que da el fondo para respaldar el acceso a un crédito.

● Obligaciones. Créditos, a los que se les asocia una garantía en Servicios - FAG.

● eFAG. Aplicación para usuarios externos en las que registran las reclamaciones a garantías expedidas y siniestradas.

● Recuperaciones. De garantías que han sido reclamada y pagadas por siniestro.

3. ANTECEDENTES

La aplicación actual se encuentra desarrollada hace aproximadamente 24 años en Power Builder y DB2, por lo que se requiere diseñar y desarrollar una nueva aplicación que esté alineada a los requerimientos y normativas actuales, implementada en arquitecturas modernas, utilizando tecnologías agnósticas y neutrales.

Es relevante aclarar que la aplicación a desarrollar debe correr sobre servidor de aplicaciones Weblogic, lenguaje de programación JAVA y base de datos SQL-SERVER, los demás componentes podrán ser propuestos por el contratista y aprobados por Finagro durante la ejecución del contrato.

Así mismo, se requiere contar con una base de datos que conserve todos los datos históricos de las garantías, cuya información se encuentra almacenada en Servicios FAG y almacene eficientemente los que se generan por su operación. El nuevo aplicativo debe incluir la implementación de los diferentes módulos que actualmente son externos a dicha aplicación y están en otros lenguajes de programación o que no están desarrollados aún y que hacen parte del ciclo de vida de las garantías.

El proyecto cuenta con un intento inicial de diseño preliminar, a gran escala, sin concluir, que incluyen:

● Una documentación no detallada de parte de los procesos que interactúan con la aplicación.

● Una arquitectura preliminar inconclusa y por revisar, con diagramas de componentes, servicios, integraciones, y usuarios.

● MINTIC ha establecido guías específicas para la gerencia de proyectos de tecnología que deben ser atendidas en todos los proyectos de tecnología de FINAGRO.

4. FUNCIONALIDADES PRINCIPALES A DESARROLLAR

A continuación, se presenta un esquema preliminar con el alcance de primer nivel de las funcionalidades que deben ser diseñadas y desarrolladas.

La operación del negocio se concentra en la Administración y Expedición de garantías, el pago o reclamación de estas cuando se siniestran y en la recuperación de estas garantías pagadas-siniestradas.

Los otros módulos son para seguridad de la aplicación, parametrización, reportes y procesos de cierre.

Se deben verificar e identificar los posibles módulos faltantes para cubrir todos los procesos.

Este diagrama ilustra el dominio preliminar de la aplicación, pero no limita los requerimientos o módulos que se puedan requerir.

<.. image(Interfaz de usuario gráfica, Texto, Aplicación, Chat o mensaje de texto Descripción generada automáticamente) removed ..>

5. ARQUITECTURA PRELIMINAR POR REVISAR DE LA APLICACIÓN FAG A DISEÑAR Y DESARROLLAR

<.. image(Interfaz de usuario gráfica Descripción generada automáticamente) removed ..>

El diagrama de componentes anterior muestra las aplicaciones existentes en su momento de elaboración (2019) en Finagro que interactúan con Servicios - FAG y los servicios iniciales que deben desarrollarse para interoperabilidad y usuarios externos.

La línea base asumida se presupuesta con una dedicación total de unas 12.000 horas para el desarrollo de todo el proyecto.

Se aclara que las 12.000 horas para el desarrollo son una referencia inicial para los casos de uso existentes a la fecha, el número de los casos de uso no pueden disminuir porque son lo mínimo que requirió el negocio en su momento, por el contrario, el número de casos de uso aumentará con la evolución normal del negocio durante la ejecución del contrato.

6. EQUIPO HUMANO

Con base en la cantidad de requerimientos identificados inicialmente del sistema, el oferente deberá suministrar para el desarrollo de la aplicación, el equipo de trabajo que busque maximizar la productividad en beneficio de ambas partes. Será posible redimensionar el equipo acorde a los requerimientos en detalle, sus estimaciones y en función de la productividad que ofrezca la fábrica en cada una de las fases, pero constará de al menos los siguientes perfiles:

Perfil	Cantidad	Dedicación
Gerente de proyectos	1	Parcial
SCRUM Master	1	Total
Arquitecto de software	1	Total
Arquitecto/Administrador de base de datos	1	Total
Desarrollador Java	4	Total
Analista de negocio	4	Total
Tester/Documentador	2	Total

El proyecto iniciará por una fase con mayor dedicación al análisis y diseño, donde se realizará la transferencia de conocimiento a los analistas del negocio y a los arquitectos y el contratista deberá definir: La arquitectura inicial de la aplicación, el levantamiento de los primeros requerimientos, la estructuración y priorización de los primeros requerimientos a atender, los primeros escenarios de pruebas para esos requerimientos y el plan de migración de la base de datos, por lo que la dedicación propuesta para el primer año es la siguiente, según la fase que corresponda.

6.1 PRIMERA FASE (APROXIMADAMENTE 5 MESES) ENFOCADA EN ANÁLISIS Y DISEÑO. CANTIDAD DE PERSONAS POR ROL.

PERFIL / MES	1	2	3	4	5
Gerente de proyectos (dedicación 50%)	1	1	1	1	1
SCRUM Master		1	1	1	1
Arquitecto de software	1	1	1	1	1
Arquitecto/Administrador de base de datos	1	1	1	1	1
Desarrollador Java			4	4	4
Analista de negocio	4	4	4	4	3
Tester/Documentador			2	2	2

Para la fase inicial, en la que los entregables son: arquitectura, requerimientos detallados, prototipos, suite con escenarios de prueba y los demás documentos de análisis y diseño que se requieran. Enesta fase se podrá facturar el 100% de estas actividades con los documentos entregables recibidos a satisfacción por parte de FINAGRO.

Para la segunda fase; una vez ingresen los desarrolladores, se facturará y se pagará como se describe en el numeral 7 del presenteanexo técnico.

6.2 SEGUNDA FASE ENFOCADA EN CONSTRUCCIÓN/MIGRACIÓN. CANTIDAD DE PERSONAS POR ROL.

En esta fase se da la mayor entrega de requerimientos completamente terminados y entregados en ambiente de producción y la ejecución del plan de migración de base de datos.

PERFIL / MES	6	7	8	9	10	11	12
Gerente de proyectos (dedicación 50%)	1	1	1	1	1	1	1
SCRUM Master	1	1	1	1	1	1	1
Arquitecto de software	1	1	1	1	1	1	1
Arquitecto/Administrador de base de datos	1	1	1	1	1	1	1
Desarrollador Java	4	4	4	4	4	4	4
Analista de negocio	3	3	3	3	3	3	3
Tester/Documentador	2	2	2	2	2	2	2

Las dedicaciones expuestas en las tablas 6.1 y 6.2 son una referencia inicial. El contrato se suscribirá por dos (2) años, pero el alcance final se dará en su ejecución de acuerdo con los requerimientos del proyecto y a los que surjan con la evolución normal del negocio. Esto le otorga una flexibilidad al contratista para reconfigurar su equipo en beneficio de la productividad en cualquier momento del desarrollo del proyecto.

7. METODOLOGÍA

La metodología se basa en una fábrica de software, donde se van a planear los requerimientos a entregar por ciclo, iteración o sprint para cada uno de los módulos de desarrollo de acuerdo al cronograma de entrega pactado inicialmente en la etapa de diseño y arquitectura. Desde el comienzo del proyecto se estimarán las horas que se requieren por cada rol y cada ciclo de desarrollo. Esta estimación de horas debe incluir las horas de: análisis, desarrollo, gerencia de proyectos, implementación y pruebas, con la evidencia de pruebas satisfactorias; funcionales e integrales (regresión, carga, etc). Las estimaciones de tiempos por requerimiento o módulo alimentan una base de datos para el proyecto que permite ir ajustando el ritmo y la productividad de la fábrica.

Una vez definido y aprobado el presupuesto de un requerimiento o módulo por FINAGRO, este estará sujeto a revisión, en caso de que FINAGRO solicité un cambio en el alcance de dicho requerimiento o módulo. Si la adopción del cambio en el alcance genera una modificación en el presupuesto, este debe ser aprobado previamente por FINAGRO.

A lo largo de la ejecución del proyecto, el costo se establecerá por entregable sea un documento o un módulo que comprende el requerimiento o conjunto de requerimientos. Durante los primeros cuatro meses se podrán facturar el 100% de las horas dedicadas de los perfiles correspondientes a Gerente de proyectos, Arquitectos y analistas, siempre y cuando los entregables que incluyen los prototipos, documentos de análisis y diseño y los escenarios de prueba, se encuentren aprobados por Finagro, discriminadas por módulo o requerimiento. Para la segunda fase, una vez se empiecen los desarrollos, se aplicará el siguiente modelo de pago.

Con estricto apego al costo estimado por documento, módulo o requerimiento, después de la fase de diseño y arquitectura donde se pagará el 100% contra la entrega, el contratista podrá facturar en cada corte mensual de la siguiente forma:

● El 20% del valor estimado y aprobado del módulo o del requerimiento si ya fue recibido y aprobado su prototipo y sus especificaciones detalladas.

● El 20% del valor estimado y aprobado del módulo o requerimiento que haya superado las pruebas automatizadas definidas en el plan de pruebas y hayan sido aceptadas como satisfactorias por Finagro, o si el contratista no recibe notificación de la disponibilidad del requerimiento en el ambiente de pruebas dentro de los 2 días hábiles (48 horas) siguientes..

● El 60% del valor estimado y aprobado del módulo o requerimiento que se encuentre desplegado en ambiente de producción; funcionando y que haya superado las pruebas de carga y hayan sido aceptadas como satisfactorias por Finagro, o si el contratista después de entregar el desarrollo a FINAGRO para su despliegue en producción no recibe la notificación de la fecha disponible por el grupo de FINAGRO para el despliegue del requerimiento en el ambiente de producción dentro de los 5 días hábiles (120 horas) siguientes.

● El 100% de las horas ejecutadas y no pagadas, dedicadas a levantamiento de requerimientos que fueron previamente aprobados por Finagro y que por cambios provenientes del negocio sean cancelados, suspendidos o descartados por FINAGRO, excepto, cuando la causal de cancelación, suspensión, o no aceptación sea por deficiencia manifiesta en su calidad o ineficacia de su funcionamiento detectadas en cualquier fase delciclo de desarrollo. Las horas ejecutadas deberán ser sustentadas por el contratista y aprobadas por Finagro.

El contratista deberá utilizar cualquiera de las siguientes metodologías ágiles: Scrum, Extreme Programming (XP), rapid prototyping. El contratista deberá suministrar la documentación y seguimiento de cada etapa que sustente su adecuada aplicación de la metodología de SDLC y permitir al supervisor o interventor del contrato la observación de esta. Así mismo, deberá contar con sistemas automatizados para pruebas de los desarrollos, y entregará las estadísticas y datos para su validación por parte del supervisor o interventor del contrato y de la entidad contratante.

7.1. ETAPA DE PLANEACIÓN

Partiendo de los documentos del estudio entregado por la empresa consultora contratada anteriormente en el 2019, en donde se encuentran descritos parte de los procesos principales y su estructura a la fecha de su evaluación de los servicios prestados por el aplicativo Servicios - FAG, el contratista deberá elaborar los requerimientos detallados a través de entrevistas directas a todos los usuarios del negocio y personal técnico que la entidad designe para ello. A continuación, se deberá presentar un plan de trabajo, donde se especifiquen las entregas y sus fechas, incluyendo los cambios y mejoras que los usuarios y personal técnico identifiquen con relación a la implementación actual en todos y cada uno de los procesos del FAG. En esta etapa que se estima de máximo tres meses el equipo estará conformado principalmente por analistas y arquitectos.

En esta etapa el contratista deberá entregar específicamente:

● La arquitectura de software final de la aplicación.

● La arquitectura de la base de datos.

● Los documentos de gerencia de proyectos en los formatos y repositorios que indique Finagro para cumplir con la metodología de Finagro y de Mintic, como se menciona en el numeral 12 de este anexo.

● Los diseños detallados de los requerimientos de los primeros ciclos de desarrollo incluyendo prototipos y escenarios de pruebas aprobados por los usuarios.

7.2 ETAPA DE EJECUCIÓN

7.2.1 DEFINICIÓN DEL DISEÑO Y LA ARQUITECTURA

Como resultado de las entrevistas a los usuarios de negocio y técnicosel contratista deberá elaborar y someter a aprobación de FINAGRO y en específico el grupo patrocinador del FAG, los documentos de requerimientos y el documento con la especificación de la arquitectura propuesta de cada módulo y de cada requerimiento bajo un estándar específico; los casos de prueba para cada uno de ellos y los respectivos prototipos de las interfaces de usuario en donde se identifiquen claramente toda la información de entrada y de salida de los procesos. El contratista no podrá iniciar el desarrollo formal de la nueva arquitectura y de los requerimientos, hasta no ser aprobados por Finagro incluyendo los mencionados prototipos.

7.2.2 CONSTRUCCIÓN DE SOFTWARE

En esta etapa se iniciará el desarrollo del software, el contratista deberá realizar la gestión del proyecto en una herramienta reconocida de gestión de metodología ágil de proyectos. El gerente de proyecto deberá programar y documentar reuniones periódicas de monitoreo y seguimiento para informar el avance del proyecto a FINAGRO. Esto implica la conexión con los repositorios de desarrollo y pruebas para los procesos propios de validación y aprobación de todos y cada uno de los requerimientos establecidos en el alcance aprobado. Se deberá llevar un registro detallado y documentado de los tiempos utilizados por cada uno de los perfiles del equipo.

El Contratista deberá llevar un sistema de control de versiones del desarrollo de todos y cada uno de los módulos o requerimientos establecidos en el alcance aprobado. Adicionalmente un repositorio de documentación del proyecto con actas de reuniones, estimaciones, control de cambios y aprobación de cada uno de los eventos en el proyecto. Se debe seguir la metodología MinTIC para desarrollo de proyectos de IT. El contratista debe permitir el acceso a Finagro o al interventor a todos los repositorios del proyecto, incluyendo el repositorio de código fuente, pruebas, documentación, etc.

Para los requerimientos que se encuentren en esta etapa, el contratista deberá entregar específicamente:

● El código fuente versionado en el repositorio de control de versiones, el cual debe incluir las unidades de prueba.

● Los programas compilados para ejecución de la aplicación

● La documentación de las pruebas realizadas satisfactoriamente y sus resultados.

● La documentación funcional, manuales y tutoriales de cada requerimiento entregado.

● La evidencia de las pruebas automatizadas superadas en desarrollo.

● Los documentos de diseño que hayan sido actualizados en la implementación del

requerimiento.

● Los documentos de gerencia de proyectos en los formatos y repositorios que indique Finagro para cumplir con la metodología de Finagro y de Mintic, como se menciona en el numeral 12 de este anexo.

7.2.3 PRUEBAS DE DESARROLLOS

Con el fin de garantizar una mejor calidad de los desarrollos realizados, el contratista deberá realizar pruebas automáticas que permitan evidenciar su correcto funcionamiento, teniendo en cuenta como mínimo los siguientes aspectos:

∙ Definición de un plan de pruebas automatizadas: unitarias, de integración y funcionales.

∙ Creación y correcta administración de los ambientes de pruebas para hacerlo eficientemente.

Los resultados de las pruebas deberán quedar documentadas de acuerdo al sistema de Gestión de la Entidad o acordado, el cual debe ser suministrado a Finagro para su registro.

El desarrollo de pruebas debe estar contenido en la estimación de tiempo total para la entrega del requerimiento. El contratista deberá generar y documentar evidencias de pruebas satisfactorias unitarias, funcionales, integrales y de usuario.

El contratista someterá a prueba de los usuarios finales, los procesos propios de cada área, quienes aprobarán o no los desarrollos de acuerdo con los requerimientos aprobados por la entidad. Sólo se dará concepto de aceptación una vez que el módulo o el requerimiento cumpla con todos los escenarios de prueba a satisfacción sin generar errores.

Para paso a producción el contratista debe generar y documentar evidencias de pruebas de regresión y carga, así como su correspondiente Manual de Despliegue.

7.2.4 PUESTA EN PRODUCCIÓN

El contratista informará cuando un desarrollo esté listo para su paso a producción y acompañará en este proceso al equipo técnico designado por la entidad para su realización. En esta etapa el contratista debe: Medir el impacto del cambio, identificar las aplicaciones y usuarios afectados, establecer un plan de contingencia y marcha atrás, para los casos en que no puedan ser finalizados exitosamente.

Después de finalizada la puesta en producción del requerimiento, módulo o componente el contratista debe ofrecer acompañamiento y soporte sobre los posibles errores en ambiente de producción.. Como error se considerará cuando uno de los escenarios de prueba entregados no se está cumpliendo a satisfacción,cuando no se cumple con la especificación de los documentos de diseño incluyendo prototipos, o cuando el rendimiento de la funcionalidad no logré el desempeño esperado o se evidencien problemas de desempeño en la base de datos. La garantía consiste en hacer las correcciones necesarias sin modificar las horas establecidas en la estimación del requerimiento en los términos que se solicitan en los Acuerdos de niveles de servicio que se detallan más adelante.

7.3 ETAPA DE ESTABILIZACIÓN

Todos los desarrollos realizados durante el alcance del contrato deben tener soporte durante la

ejecución del contrato, de tal forma que todos los usuarios implicados puedan utilizarlos satisfactoriamente y la entidad garantice su funcionamiento con la utilización de las nuevas herramientas implementadas.

7.4 OBLIGACIONES ESPECÍFICAS DEL CONTRATISTA

● Desde el inicio en la participación en el proyecto, el contratista debe prestar un servicio integral durante todas las etapas del ciclo de vida del desarrollo del software, desde la identificación de la necesidad hasta la puesta en producción, verificación de los usuarios finales, sensibilización e interiorización y estabilización de la misma. Debe acompañar al área de tecnología en el despliegue y estar disponibles para resolver cualquier contingencia en los procesos de acuerdo a la temporalización de cada uno de ellos.

● Desde el inicio del proyecto se deben incorporar todos los equipos de trabajo definidos, y conocer a nivel de detalle toda la información generada por la empresa de Consultores en el año 2019, y en lo referente a los sistemas de información actuales interoperando con el aplicativo Servicios FAG. Durante esta fase se llevará a cabo la transferencia de conocimiento funcional y técnica de las aplicaciones, infraestructuras y procedimientos de trabajo usados actualmente.

● El contratista debe presentar una herramienta tecnológica para la gestión y documentación del proyecto que corresponda a la metodología ofrecida y que permita el registro de los tiempos planeados y ejecutados de la dedicación de cada perfil, con el fin de mantener la base de datos de estimaciones.

● El contratista deberá realizar la abstracción y especificación detallada de los requerimientos, así como la definición del diseño y arquitectura de la solución de software que garantice el cumplimiento del proceso y su puesta en funcionamiento de acuerdo con los tiempos establecidos.

● El contratista deberá proporcionar y garantizar las herramientas de desarrollo, automatización de pruebas que necesite para las diferentes etapas del proyecto, y asumir sus costos y servicios. Finagro no proporcionará ningún tipo de licenciamiento para esos procesos, así como tampoco licencias de herramientas de ofimática (office 365)

● El contratista deberá proporcionar herramientas de control de versiones y la conexión con los repositorios de desarrollo y los procesos propios de validación y aprobación de todos y cada uno de los requerimientos establecidos en el alcance aprobado. Debe contar con un DSL (Definitive Software Library): Repositorio definitivo de versiones de software.

● El contratista deberá proporcionar los equipos de cómputo licenciados/registrados y el software licenciado de todas las herramientas de ofimática para su equipo que sean compatibles con las utilizadas en Finagro.

● Los arquitectos de software/bases de datos deben relacionar todas las tablas y todos los campos del nuevo diseño con sus equivalentes en la base de datos Db2 FAG actual, o hacer la homologación xx xxxxxx que se usaron en su tiempo por los equivalentes en el diseño de arquitectura propuesta.

● Las nuevas funcionalidades deberán presentarse con el siguiente paquete de documentos:

- Manual de usuario funcional en formato PDF y en el formato original del manual según el programa utilizado para su creación con las pantallas y el paso a paso de cómo

navegar y que describa de manera concisa la funcionalidad.

- Tutorial en video de grabación de pantalla con audio y subtítulos. Los vídeos tutoriales deben permitir identificar en su nombre, la estructura de: Aplicación / Módulo / Función y estar contenidos también en el sistema de control de versiones.

- Documento con las características funcionales y técnicas de la solución. Arquitectura de la solución; Diagramas de componentes, diagramas de secuencia, diagramas de interacciones, diagramas de máquinas de estados, diagrama de actividades Modelo de datos, detallada a nivel xx xxxxxx y servicios de integración detallada.

- Diccionario de datos: Indicando el dominio de cada campo, tipo de dato, longitud, descripción del campo, si es una llave primaria o foránea, tipos de datos o valores admitidos (por ejemplo: si admite valores nulos, explicación de porque el campo puede ser nulo).

● El contratista deberá realizar las capacitaciones o transferencias de conocimiento a los usuarios y personal técnico a las que haya lugar.

● El contratista deberá garantizar que la continuidad y calidad del servicio no se vea afectada por cambios o ausencias en su personal.

● El contratista deberá asumir dentro de los servicios, los ambientes requeridos para los desarrollos y ejecución de pruebas, así como la configuración de estos ambientes y el acceso a ellos.

● El contratista deberá garantizar durante la ejecución del contrato que contará con un recurso en su equipo con experiencia en carga de información y migraciones de AS400 a SQL.

● El contratista deberá entregar un informe periódico (semanal y mensual) del estado del proyecto, donde deberá presentar los indicadores de productividad o velocidad del equipo de la fábrica que a continuación se enumeran, los problemas y riesgos a mitigar y los planes de acción para la mejora de los indicadores que se encuentren por debajo de los valores solicitados por el FAG.

Indicador	Descripción	Meta
Velocidad del equipo	Cantidad de trabajo realizado entre sprints. Permite ajustar de forma realista, el trabajo que se puede esperar en el siguiente Sprint.	Se espera una desviación inferior al 10% medida desde la fecha de la anterior entrega a la fecha planeada para la entrega actual.
Gráfica de Flujo Acumulado	Muestra el estado de las incidencias en el tiempo, permite identificar cuellos de botella.	Semanal
Gráfica de Trabajo hecho	Alcance total aprobado y en curso. Permite comprender el efecto de cambios en el alcance y la relación con los recursos asignados.	Para análisis mensual.

Gráfica de Trabajo pendiente	Trabajo total restante del Sprint actual.	Debe permitir pronosticar un cumplimiento mínimo del 90%
Reporte de Sprint	Trabajo que se ha terminado o regresado al Backlog en el sprint. Permite establecer el nivel de cumplimiento de lo comprometido.	Se espera un cumplimiento superior al 90% en las entregas de cada Sprint.
Informe de versión	Seguimiento de la fecha prevista para la entrega de una versión.	Se espera una desviación inferior al 10% medida desde la fecha de la anterior entrega a la fecha planeada para la entrega actual.

8. MIGRACION DE DB2 a SQL-SERVER

La migración deberá ser considerada desde la primera actividad de diseño, el arquitecto para cada diseño deberá considerar los objetos de base de datos existentes, las condiciones actuales de operación y el nuevo diseño que tendrá la aplicación y el modelo de datos cuando finalice el proyecto.

Actualmente FAG Servicios almacena:

● Aproximadamente 4 millones de Garantías

● Aproximadamente 35.000 operaciones al mes.

● Aproximadamente 30 Intermediarios y agentes externos.

Para la migración Finagro cuenta con la siguiente información que será entregada al contratista para su verificación.

● Versión de sistema operativo se está ejecutando

● Arquitectura en la que está desplegada

● Modelo entidad – relación para identificar llaves y restricciones.

● Características operativas de la BBDD:

o Tamaño en disco

o Cantidad de tablas

o Cantidad de registros en tablas principales (maestros y transacciones)

o Cantidad de funciones y triggers, si se puede estimar la cantidad de líneas de código en total.

● Carga actual de la BD: recursos de servidor y transacciones por hora.

9. ACUERDOS DE NIVELES DE SERVICIO.

Con fundamento en el principio de la autonomía de la voluntad consagrado en el 1602 del Código Civil Colombiano, en la costumbre mercantil y lo regulado en los presentes términos de referencia,

con la presentación de la oferta y la celebración del contrato, las partes acuerdan y aceptan la aplicación de descuentos por incumplimiento de los ANS, acorde con lo establecido en este numeral. Los descuentos por incumplimiento de los ANS y la aplicación estos, son un mecanismo de solución directa de las controversias que puedan surgir durante la ejecución del contrato, por el incumplimiento parcial de las obligaciones a cargo de EL CONTRATISTA, en los casos contemplados en este numeral.

El acuerdo de nivel de servicio (ANS), hace parte integral del contrato y define los estándares de servicio que el contratista está obligado a cumplir para garantizar la continua y permanente prestación de los servicios contratados, so pena de imponer compensaciones económicas que se fijan a continuación.

Indicador	Descripción	Descuento
Oportunidad	Por cada requerimiento, número de días hábiles de retraso en la entrega con todas las pruebas previstas y documentadas superadas , instalado en el ambiente de pruebas hasta que el requerimiento sea recibido a satisfacción por Finagro.	Número de días	Sobre el valor total del requerimiento.
		De 1 a 5	2% por día
		De 6 a 10	5% por día
Calidad Pruebas	Por cada requerimiento, número de errores en ambiente de pruebas reportados por los usuarios, con relación a las pruebas previstas.	Número de errores	Sobre el valor total del requerimiento.
		3	0%
		De 4 a 5	5%
		Más de 5	10%
Soporte prioritario	Tiempo de atención a un error en el producto, en ambiente de producción que bloquea la operación.	horas hábiles	Sobre el valor total del requerimiento.
		8	0%
		>8	10%
Soporte	Tiempo de atención a un error en el producto, en ambiente de producción que no bloquea la operación.	horas hábiles	Sobre el valor total del requerimiento.
		16	0%
		>16	5%
Informe productividad.	Días de retraso en la entrega del informe mensual de la fábrica de software según anexo1. Contados después del 5 día hábil de cada mes.	Sobre el valor de los requerimientos facturados el mes anterior
		>1	5%

La aplicación de descuentos por incumplimiento de los ANS no libera ni atenúa la responsabilidad de EL CONTRATISTA del cumplimiento de las obligaciones adquiridas con la celebración del contrato. Los perjuicios que se ocasionen como consecuencia del retardo o del incumplimiento podrán hacerse efectivos en forma separada.

Los descuentos por ANS tendrán un tope del 25% del valor de la factura mensual.

El paso a producción de los requerimientos no lo hace el proveedor, lo hace FINAGRO. Para esto FINAGRO ofrece un nivel de servicio de máximo 8 horas hábiles para el despliegue de un componente entregado por el proveedor.

PARAGRAFO PRIMERO: Si los descuentos acumulados durante la ejecución del contrato por ANS superan el 5% del valor total del contrato se incurrirá en causal de incumplimiento por baja calidad del servicio, dando lugar a que la entidad inicie las acciones legales a que haya lugar, así como la aplicación de la cláusula penal y las garantías pactadas del contrato.

PARAGRAFO SEGUNDO: Si el retraso en el ANS de Oportunidad supera los 11 días, se incurrirá en causal de incumplimiento por baja calidad del servicio, dando lugar a que la entidad inicie las acciones legales a que haya lugar, así como la aplicación de la cláusula penal y las garantías pactadas del contrato.

PARAGRAFO TERCERO: Si durante tres periodos consecutivos los descuentos aplicados por ANS en cada periodo corresponden al 15% de la facturación del periodo, se incurrirá en causal de incumplimiento por baja calidad del servicio, dando lugar a que la entidad inicie las acciones legales a que haya lugar, así como la aplicación de la cláusula penal y las garantías pactadas del contrato.

10. GARANTÍA

Después de terminada la ejecución del contrato, los requerimientos entregados deberán tener garantía por errores funcionales hasta por 12 meses más, sin generación de ningún tipo de costo para Finagro por las correcciones que deba hacer el contratista. Para definir que se trata de un error referirse a los mismos términos en que se indica en el numeral 7.2.4. de este anexo.

11. AMBIENTE DE DESARROLLO

El ambiente de desarrollo será suministrado por el proveedor. Los ambientes de pruebas, preproducción y producción serán suministrados por Finagro

12. ALINEACIÓN CON METODOLOGIA MINTIC.

La gerencia de proyectos del contratista deberá entregar la documentación de manera alineada a la metodología MINTIC, la cual contempla la generación y entrega de entre otros, los siguientes documentos:

● Plan de configuración del proyecto

● Ruta crítica

● Uso de metodologías ágiles

● Lecciones aprendidas

● Repositorio de documentos del proyecto.

● Entrega de valor continuo.

● Bitácora del proyecto.

● Evidencias de uso de metodologías ágiles y caracterización del proceso

● Evidencia si aplica, del uso de software libre en el desarrollo del proyecto.

● Cartas, actas y cronogramas del proyecto.

● Plan de hitos y entregables a generar.

● Actas de reunión de seguimiento.

● Informe de riesgos.

● Bitácora del proyecto.

Adicionalmente Finagro podrá solicitar cualquier documento adicional que se identifique es necesario para siempre que sean propios de la gerencia de proyectos y de los lineamientos de MINTIC para la gerencia y gobierno de proyectos de tecnología. El contratista se compromete a usar los formatos establecidos por Finagro para cumplir con la documentación solicitada.

13. OTRAS OBLIGACIONES ESPECÍFICAS DEL CONTRATISTA.

a) Mantener la confidencialidad de todos los secretos industriales entregados por FINAGRO para el desarrollo del presente contrato, de igual manera no utilizar ni divulgar elementos activos del usuario (interfaz, esquemas de reportes, etc.) ni las marcas o nombres de los productos designados sino bajo la estricta autorización de FINAGRO.

b) Disponer de todos los medios logísticos y de infraestructura necesarios para el oportuno cumplimiento del objeto contractual. Incluyendo las licencias de software y hardware necesarias para su equipo de trabajo, tanto en desarrollo como aplicativos ofimáticos. Estos indicadores los deberá generar directamente la herramienta que se use para gestión de requerimientos.

El informe mensual debe contener, además, el análisis del comportamiento de los indicadores y los planes de acción para la mejora de los que se encuentren por debajo de los valores solicitados por FINAGRO.

c) Cumplir con los señalado en el alcance del objeto y en las especiaciones técnicas del contrato.

d) La solución deberá incorporar en sus procedimientos el aseguramiento de calidad de desarrollo de software según las mejores prácticas de desarrollo de software, con el objetivo de garantizar la calidad de los desarrollos entregados.

e) Contar con una plataforma de desarrollo que pondrá a disposición para el desarrollo del objeto del contrato. FINAGRO asegurará para dicho contratista el acceso a la plataforma a través de VPN.

f) Mantener el equipo de trabajo propuesto en la oferta de servicios, cualquier cambio en el mismo debe ser consultado y aprobado por con el Supervisor del contrato y cumplir con el perfil requerido en los presentes términos de referencia.

g) De requerirse el cambio de algún perfil, este deberá ser cubierto máximo en 30 días calendario.

h) Cada cambio de persona del equipo, generará una compensación del 10% en las horas facturadas de ese perfil para el siguiente mes, con el fin de mitigar el impacto para FINAGRO por transferencia de conocimiento. Los ANS que potencialmente sean afectados por cada cambio tendrán un tope en la aplicación, sin embargo, estos descuentos por ANS se acumularán.

i) El contratista debe garantizar y comprometerse a que los desarrollos realizados estén libres de software malicioso o de rutinas que capturen información propia de FINAGRO con fines distintos a la funcionalidad propia del software.

j) Cumplir con las reglas y requisitos que FINAGRO posee en sus reglamentos de trabajo, de higiene y seguridad industrial y del sistema de gestión integral, cuando el contratista tiene personal in house, ocasional y/o permanente que ocupe las instalaciones de FINAGRO.

k) Garantizar la plataforma de servidores para el ambiente de desarrollo.