ANEXO 2

ANEXO 2

ACEPTACIÓN DE ESPECIFICACIONES TÉCNICAS VERSIÓN 1

INVITACIÓN PÚBLICA No. 3000000660 - CONTRATAR LOS SERVICIOS DE ASEGURAMIENTO Y CONTROL DE CALIDAD DE SOFTWARE CORRESPONDIENTES A LOS PROYECTOS E INICIATIVAS DE LAS DIFERENTES LÍNEAS DE ACCIÓN Y DE RESPALDO ESTRATÉGICO DE LA CÁMARA.

1. INTRODUCCIÓN

Actualmente, La Cámara de Comercio de Bogotá utiliza como metodología de Proyectos de desarrollo un híbrido entre SCRUM y tradicional, teniendo como principal objetivo generar constantemente nuevas versiones de los sistemas de información que generen valor de negocio, en los tiempos que se requieren y con alta calidad.

En cualquiera de los dos casos, la CCB entrega al proveedor la solicitud y documentos necesarios para el inicio del proceso (visión, alcance, historias de usuario, mockups, listas de chequeo, entre otros); el proveedor realiza el análisis de este, entregando una estimación de esfuerzo y posterior aprobación por parte de la CCB y de acuerdo al cronograma se inician las fases de prueba (Planeación, Diseño, Ejecución, Cierre, Certificación y Gestión). Dejando el proveedor como resultado los siguientes entregables: casos de prueba, script para pruebas no funcionales, Script de automatización de pruebas funcionales, evidencias, reporte de los incidentes, evidencia de la corrección, certificación de calidad e informes de resultados.

Todo esto enfocado en un seguimiento de los ANS propuestos y en el establecimiento de los KPI´s propios del servicio.

1.1. Concepto de calidad y pruebas del software

Se define por la IEEE Std. 610 – 1991, la calidad del software como “el grado con el que un sistema, componente o proceso cumple los requerimientos especificados y las necesidades o expectativas del cliente o usuario”.

Las actividades desarrolladas en la fase de pruebas hacen parte del ciclo de vida del desarrollo de software, estas actividades permiten tener cierta certeza sobre la funcionalidad esperada del sistema desarrollado, incluso permite verificar los flujos de excepción a fallos del sistema, estos pueden ser propios de la aplicación u ocasionados por causas externas al sistema.

Para cumplir con la actividad de pruebas, se definen y ejecuten tareas de verificación, garantizando la condición de calidad esperada por él sistema. Estas pruebas pueden cumplir con principios ISTQB® (International Software Testing Qualifications Board). Sin embargo, se debe tener en cuenta que el objetivo principal con esta oferta es contar con un Contratista, que ejecute pruebas continuas (CONTINUOS TESTING) bajo el modelo DevOps, que nos brinde información suficiente para certificar que el producto cumple con la calidad necesaria, incluso sin haber sido probado exhaustivamente. Al final, se espera que la entrega realizada genere valor al negocio.

1.2. Marco de referencia de los servicios a contratar

El marco de referencia aquí definido se suscribe a los siguientes estándares:

• ISO 9001:2000 que especifica los requisitos para un sistema de gestión de la calidad, ISO/IEC 9126:1991 ingeniería del software – calidad de producto, la cual contiene un modelo de calidad y medición que permite la evaluación de la calidad de un producto software.

• ISO 25000:2005

• IEEE 829 – 1998: Standard for Software Test Documentation. Define la documentación generada en cada una de las fases del proyecto de pruebas.

• IEEE 830 – 1998: Recommended Practice for Software Requirements Specifications. Proporciona una guía de buenas prácticas para la elaboración de una especificación de requerimientos.

• IEEE 1012 – 2004: Standard for Software Verification and Validation. Detalla los procesos de verificación y validación (V&V) del software, y su organización.

• IEEE 1061 – 1998: Standard for a Software Quality Metrics Methodology. Define el establecimiento, la implementación, el análisis y la validación de métricas de calidad de software.

• Estándares “de facto” aceptados por la industria.

Es conveniente recordar que la intención de las actividades de pruebas es asegurar la calidad de los productos de software desarrollados y con esto lograr niveles de satisfacción del cliente y de usuario favorables para la organización.

2. SERVICIO DE PRUEBAS DE SOFTWARE

2.1. Objetivo

Prestación de los servicios de pruebas continuas bajo el modelo DevOps y basados en los xxxxxx de trabajo ágiles como Agile, Scrum, tradicional e híbridos, sobre los desarrollos de software de los diferentes sistemas de La Cámara de Comercio de Bogotá.

2.2. Características del servicio

El servicio de ejecución de pruebas continuas de software se prestará en las instalaciones de La Cámara de Comercio de Bogotá en modalidad de células de trabajo o en las instalaciones del proveedor bajo modalidad de fábrica, y será tanto para los desarrollos de los grupos internos de La Cámara de Comercio de Bogotá, como para el software desarrollado en un modelo tercerizado a una fábrica de software externa. A continuación, se describen las condiciones mínimas requeridas, para que un contratista realice las pruebas de software:

La metodología definida debe garantizar que los sistemas actuales y los nuevos sistemas desarrollados por La Cámara de Comercio de Bogotá cumplan con los requerimientos funcionales y no funcionales definidos con una ejecución continua y automatizada que permita tener el producto en condiciones de aceptación.

El contratista debe tomar como base metodológica los principios de pruebas agiles (agile testing) de la Agile Testing y pruebas continuas (continuos testing) del modelo de DevOps, para establecer el plan de pruebas del ciclo de vida de los procesos, ejecutarlo y controlarlo.

Principios del Agile Testing De forma similar a que el Manifiesto Ágil contiene principios que se aplican al desarrollo ágil de software, el Agile Testing engloba los siguientes principios:

• El Testing no es una fase: El testing continuo es la única forma de garantizar avance continuo, por esto, el testing se realiza continuamente junto con el desarrollo de software y demás actividades.

• El Testing hace avanzar el proyecto: Bajo métodos convencionales, el testing es una verificación y validación robusta, en cambio en Agile Testing se proporciona retroalimentación continua, permitiendo corregir el rumbo continuamente durante el desarrollo de software.

• Todo el equipo realiza pruebas: en Agile Testing, los Analistas de negocio y Desarrolladores de software también ejecutan pruebas, no sólo los testers como en métodos convencionales.

• Reducir el tiempo para recibir retroalimentación: En Agile Testing, los equipos del área de negocio (el cliente) están involucrados en cada iteración, no solo al final durante la fase de aceptación, como resultado, el tiempo de retroalimentación se reduce y el costo de correcciones también es menor.

• Código limpio: Los defectos en el código se corrigen en la misma iteración, por lo que se mantiene el código limpio.

• Reducir la documentación de pruebas: Los Agile Testers usan listas de chequeo reusables en lugar de documentación extensa, se enfocan en la esencia de la prueba en lugar de detalles. Siguiendo principios ágiles estas listas de chequeo son el inicio de las definiciones de las pruebas y no el final, y el tester cuenta con libertad para aportar valor.

• Guiado por pruebas: El Agile Testing, las pruebas se hacen “durante” el desarrollo y no después del desarrollo como en métodos convencionales.

• Técnica de pruebas continuas: Se adaptan a nuestro ciclo de vida fases donde se ejecuten las pruebas de software de los diferentes niveles de manera regular, con el fin de tener una retroalimentación acelerada para con nuestro equipo de desarrollo. De esta manera podemos ser más preventivos que reactivos.

Algunas de las prácticas relacionadas con Agile Testing

• Test Driven Development (TDD): El desarrollo guiado por pruebas, es una técnica que combina un enfoque de refactorización del lado de desarrollo con un enfoque de probar primero en cuanto al testing.

• Acceptance Test Driven Development (ATDD): Es una dimensión del TDD aplicada al nivel de gestión de requerimientos de software, en el cual las pruebas escritas son a nivel de cliente, es decir, lo equivalente a una prueba de aceptación o test funcional. Se puede implementar con la herramienta Selenium.

• Behaviour Driven Development (BDD): También puede llamarse Story Driven Development. Bajo este enfoque primero se desarrolla una prueba funcional o de historia de usuario automatizada, luego se ejecuta el desarrollo aplicando TDD hasta que la prueba es exitosa.

• Testing exploratorio: Enfoque en el cual el aprendizaje de la funcionalidad, diseño de pruebas y ejecución de pruebas ocurren simultáneamente, en contraposición con el enfoque convencional en el cual primero se documenta la funcionalidad o requisito, luego se diseña el caso de prueba y luego se ejecuta de acuerdo a guiones prestablecidos. Las pruebas exploratorias no están predefinidas ni se ejecutan según un plan.

• Automatización de pruebas de regresión: Tanto la integración continua como la refactorización son prácticas necesarias para poder implementar una metodología ágil de desarrollo de software. Ambas técnicas implican modificar las fuentes de código constantemente, por lo que la automatización de pruebas de regresión por medio de herramientas es una necesidad imperiosa.

• Automatización de pruebas unitarias: Consiste en usar un marco de trabajo o framework (como NUnit) para ejecutar tus tests unitarios, en lugar de ejecutar estos manualmente una y otra vez, cada vez que modificas el código. Para ello existen múltiples frameworks, muchos de los cuales pueden integrarse en los ambientes IDE. Estas pruebas, usualmente son desarrolladas por los programadores utilizando herramientas tipo xUnit (Junit, Nunit, etc.), adicional a proveer guías para el diseño del software, que permiten verificar el comportamiento interno de pequeñas piezas de código y componentes menores (clases, métodos dentro de las clases, interacción entre clases y métodos, etc.). Sin embargo, la responsabilidad del proveedor de pruebas es definir los lineamientos, estrategias, procedimientos y diseños para que el equipo de desarrollo interno ejecute estás pruebas.

• Pruebas continuas: Consiste en introducir la automatización de manera inmediata como parte de la entrega continua que se hace, con el objetivo de reducir los riesgos asociados al negocio y obtener una retroalimentación inmediata; para así evitar que los errores se propaguen en otros ambientes o saber dónde se está introduciendo el error, encontrando una resolución más rápida. La práctica de pruebas continuas enriquece y agrega valor a la integración continua.

El contratista deberá definir y ejecutar la metodología (actividades, roles, artefactos) de pruebas garantizando la ejecución de las siguientes pruebas:

El contratista utilizará las herramientas definidas por La Cámara de Comercio de Bogotá en las actividades de pruebas de software para realizar la ejecución de pruebas y gestión de incidentes, verificando que se abarquen los tipos de pruebas definidos por La Cámara de Comercio de Bogotá y su respectivo seguimiento. Estas herramientas son:

• Mantis

• TestLink

• JSF Unit

• Junit

• Jmeter

• Selenium

• TFS – visual studio

• Redmine

En caso en el que el contratista cuente con herramientas para su proceso de pruebas se evaluará en conjunto con La Cámara de Comercio de Bogotá para definir cual set de herramientas se utilizará en la ejecución del contrato. Para las solicitudes que sean certificadas bajo la modalidad de fábrica, el contratista seleccionado, podrá usar las herramientas con las que cuente sin que incurran en costos adicionales a la CCB

El contratista deberá entregar una estimación de esfuerzo definida en horas para las actividades relacionadas con pruebas por cada Sprint o ciclo realizado por cada miembro del equipo o célula del contratista.

El contratista deberá hacer la generación de los datos de pruebas para hacer la ejecución de sus diferentes escenarios de pruebas. El proveedor deberá generar todos los sets de datos (estructura, cantidad, relaciones entre datos), excepto aquellos en que La Cámara de Comercio de Bogotá decida apoyar su generación. En casos excepcionales por la cantidad de datos generados y la complejidad para procesos masivos, La Cámara de Comercio de Bogotá apoyará esta generación. Sin embargo, para la ejecución de pruebas funcionales individuales o de flujos que no sean masivos será responsabilidad del contratista.

El contratista deberá ejecutar todas las pruebas de acuerdo a los casos definidos y acordados con La Cámara de Comercio de Bogotá.

El contratista deberá realizar la transferencia del conocimiento a la Cámara de Comercio de Bogotá o a quien este designe durante la ejecución del contrato en los tiempos definidos en mutuo acuerdo por las partes. La transferencia de conocimiento se enfocará únicamente sobre los aspectos metodológicos y de desarrollo del proyecto definidos por el proveedor para la ejecución del contrato. Teniendo en cuenta las siguientes consideraciones:

Auditorio: El equipo de trabajo o célula (Directivos de T.I., Líder Técnico, Ejecutivo de cuenta, Arquitecto, Líderes de Desarrollo, Líderes de Calidad, Analistas de Desarrollo, Analistas Funcionales).

Periodicidad: Al inicio del proyecto y cada vez que el contratista haga una modificación metodológica en su proceso.

Mecanismos: La transferencia de conocimiento se deberá realizar a manera de catedra en sesiones con el equipo implicado y entregando la información digital que el contratista considere como apoyo al proceso.

Temática: Proceso metodológico de ejecución de pruebas (actividades, responsables, artefactos, etc.) definido y/o ejecutado por el contratista.

El contratista debe definir los lineamientos y estándares de calidad que se deberán seguir en La Cámara de Comercio de Bogotá, e implementar los artefactos que los soportan (ej. Plantillas de validación y verificación, matrices, formatos, etc.), artefactos definidos y/o usados podrán ser utilizados libremente por La Cámara de Comercio de Bogotá. Será decisión de La Cámara de Comercio de Bogotá proveer los artefactos definidos previamente para conocimiento y/o uso del contratista.

El contratista debe definir los indicadores de avance para el proceso de pruebas. Una vez se identifiquen las métricas necesarias se debe validar la viabilidad de obtención de estas, desde las herramientas utilizadas, y así generar los informes que permitirán realizar los análisis respectivos facilitando la toma de acciones y decisiones. Estos indicadores son independientes de los generados por el Scrum Team en la ejecución de los Sprint, y se refieren únicamente a indicadores a nivel de ejecución y avance de tareas del equipo de pruebas del proveedor.

El contratista debe realizar una socialización y capacitación inicial sobre la metodología de pruebas de software propuesta, a los grupos de interesados que existan en la Cámara de Comercio de Bogotá.

El contratista debe entregar una estimación de esfuerzo para cada ciclo de pruebas, a ser aprobada por La Cámara de Comercio de Bogotá, y sobre la cual se realizará el pago del esfuerzo. La estructura del contrato determina que para las personas que se encuentren ubicadas en la Cámara de Comercio de Bogotá bajo la modalidad de célula, tengan una dedicación mensual del equipo asignado por demanda al proyecto de 180 horas/mes (promedio) por persona, con disponibilidad en jornada ordinaria o se acogerá al horario establecido por la célula para el proyecto. Adicional, cuando el proyecto decida intensificar su horario y exija un tiempo extra para finalizar las entregas programadas para cada Sprint, se requerirá de la disponibilidad. El cumplimiento del Sprint se medirá con indicadores propios de Scrum, pero la facturación del proveedor se debe realizar con relación a lo trabajado por el equipo de pruebas contratado. Para los proyectos trabajados bajo la modalidad de fábrica, será una dedicación en horas, la cual se aprobará previamente y se contará con el producto certificado en una ventana especifica de acuerdo a la necesidad de la CCB.

2.3. Metodología

En la metodología de pruebas se deben establecer todas las etapas con sus actividades para ser realizadas durante el proceso de prueba de un producto entregado de software. Esta metodología debe permitir obtener la descripción de cada actividad a realizar, y a su vez debe establecer la documentación de entrada necesaria, así como la documentación de salida que se obtendrá durante el proceso de pruebas.

El contratista debe definir el proceso de pruebas y la metodología que serán ejecutadas durante la realización de los proyectos de desarrollo de software. Los proyectos de desarrollo y mantenimiento de software siguen una metodología que incluye fases, actividades y entregables del producto de

software desarrollado. El proceso de pruebas definido por el proveedor deberá estar completamente alineado con la o las metodologías definidas para el desarrollo del software de La Cámara de Comercio de Bogotá, por tanto, el contratista deberá contemplar la ejecución de las actividades definidas de forma paralela a las fases de desarrollo definidas en los proyectos de desarrollo de software, y como complemento necesario a éstos. El control de la calidad asignado al proyecto permitirá determinar los niveles y tipologías de pruebas que deben contemplarse y aplicarse según la metodología usada. Las actividades de pruebas del producto de software deben estar enmarcadas dentro del siguiente esquema metodológico:

2.3.1. Planeación

Bajo el esquema de desarrollo de proyectos agiles, el equipo de pruebas hace parte de la planificación de los Sprint aportando información referente a la definición de los casos de prueba acorde a las historias de usuario diseñadas por el analista funcional. Estos casos de prueba deben discriminar que tipos de prueba (Automatizadas como JUnit, JSFUnit, Selenium o Manuales) se deben realizar para que historia de usuarios y que probar específicamente, este documento se realiza apoyado en desarrolladores e historias de usuario más la experiencia que debe tener el Analista de pruebas teniendo en cuenta que no se solapen las pruebas del desarrollador y el analista de pruebas.

2.3.2. Ejecución

Durante el Sprint, se da inicio a la ejecución de las actividades necesarias para la ejecución de pruebas como configuración de ambientes de trabajo, ejecución de casos de prueba, elaboración de documentación e informes de seguimiento incluyendo los indicadores correspondientes, registro en herramientas de seguimiento y cualquier otra definida previamente y aceptada por el equipo de pruebas y el equipo responsable del producto de software. Durante la ejecución de pruebas se deben realizar actividades para cubrir aspectos como elaboración y ejecución de pruebas automatizadas a través de la grabación de scripts (Selenium, JMeter o cualquier herramienta para aplicaciones web definida por La Cámara de Comercio de Bogotá) dentro del sprint de su equipo y acorde a los casos de prueba definidos al inicio del sprint. Teniendo en cuenta las siguientes actividades:

• Pruebas unitarias: forman parte de los diferentes procedimientos que se pueden llevar a cabo dentro de la metodología ágil. Son principalmente trozos de código diseñados para comprobar que el código principal está funcionando como esperábamos. Pequeños test creados específicamente para cubrir todos los requisitos del código y verificar sus resultados.

• Pruebas de Sistema: Estas pruebas se realizan sobre todo el sistema con el objeto de probar el correcto funcionamiento de los requerimientos funcionales y no funcionales determinados para cada módulo del sistema. Igualmente, se deben validar estándares y políticas de La Cámara de Comercio de Bogotá que serán entregados en su momento al proveedor adjudicatario. El proveedor puede realizar cuando lo considere necesario, la verificación de la estabilidad del producto entregado mediante la ejecución de las funcionalidades básicas (smoke testing).

• Pruebas de Integración: Las pruebas realizadas como integración deben verificar que al incrementar funcionalidades a las previamente probadas y certificadas, no se ha alterado el funcionamiento de estas y el sistema sigue funcionando según las necesidades para las cuales el producto de software fue construido.

• Pruebas Funcionales: El alcance de las pruebas desde el punto de vista funcional, estaráacorde con los requerimientos e historias de usuario entregados por La Cámara de Comercio de Bogotá

y con el diseño de los módulos correspondientes, considerando: la integración con otros aplicativos o plataformas, validaciones de usabilidad y de excepción, y reglas del negocio.

• Pruebas No Funcionales: Este tipo de pruebas son un medio de control de calidad, que se realiza en aplicaciones de software para asegurarse de que todo funciona bien y poder saber en qué circunstancias podrían fallar, nos permiten conocer qué riesgos corre el producto y nos dicen si tiene un mal desempeño o un bajo rendimiento en los entornos de producción. En esesentido, las pruebas no funcionales de software se hacen con el fin de obtener información. Permiten explicar lo que soporta el producto y si cumple con las expectativas de los clientes.

• Pruebas Automatizadas: En los escenarios que se definan conjuntamente entre el contratista y La Cámara de Comercio de Bogotá, se requerirá automatizar las pruebas; para esto, deben ser completas, repetibles o reutilizables e independientes, especialmente para las pruebas de regresión.

• Pruebas de Aceptación de Usuario (UAT). Definir con el usuario final los casos prueba considerados en la ruta crítica, y acompañar al usuario en la realización de pruebas para los casos previamente definidos y aprobados, con el fin de obtener su visto bueno con respecto a la solución implementada para suplir sus necesidades.

Y demás tipos de pruebas que se consideren indispensables para garantizar la calidad de los productos de software que se vayan a validar. La adecuación y correcto funcionamiento de los ambientes de trabajo necesarios para la ejecución de las pruebas serán responsabilidad de La Cámara de Comercio de Bogotá.

2.3.3. Seguimiento y Control

En esta etapa el contratista será el responsable de revisar los reportes de los errores encontrados en fase de UAT (User Acceptence Test) y producción, y verificar si los escenarios cubiertos y los casos de prueba definidos cubrieron las pruebas correspondientes a las funcionalidades revisadas o si por el contrario son nuevos casos que no se contemplaron, en caso de no contemplarse el contratista asumirá los tiempos de la definición, ejecución de nuevos casos de prueba y la generación de informes necesarios para encontrar posibilidades de mejora.

2.3.4. Auditoría de Pruebas

Hacer una revisión del proceso para asegurar que exista una comunicación clara y oportuna respecto de las variaciones de ejecución del proceso de pruebas desde un punto de vista distinto de la función del Gerente de Aseguramiento de Calidad y Pruebas.

2.3.5. Esquema general metodológico

A continuación, se presenta el esquema metodológico de desarrollo donde se evidencia la participación del equipo de pruebas durante las diferentes etapas de los Sprint.

2.3.6. Asignación de un ejecutivo de cuenta

El proponente seleccionado (Contratista) deberá contar con un ejecutivo de cuenta Profesional Universitario en Administración de Empresas o Ingeniería de Sistemas o Telemática de Computación o de Software o Electrónica o Telecomunicaciones o Industrial de Empresas, quien administre los recursos asignados, maneje los temas de facturación, novedades, será el contacto funcional, técnico, administrativo entre el contratista y La Cámara de Comercio de Bogotá y en permanente contacto con el supervisor del contrato.

2.4. FUNCIONES DE ROLES DEL EQUIPO DE TRABAJO

2.4.1. Equipo de trabajo por demanda:

Rol	Cantidad	Perfil	Experiencia	Experiencia Adicional
Ingeniero DevOps	Por demanda	Profesional en Ingeniería de Sistemas o Telemática de Computación o de Software o Electrónica o Telecomunicaciones. Certificación vigente al momento de ser requerido el servicio de Scrum Master y/o DevOps Practitioner. Deseable: ISTQB	2 años de experiencia como Scrum Máster o Gestión de proyecto bajo el modelo de DevOps o Liderazgo técnico en Proyectos de desarrollo de Software.	Experiencia específica en: • Reingeniería de procesos • Codificación o Scripting • Experiencia en el manejo de herramientas para automatización de servicio y en general modelos de DevOps. Esta experiencia debe ser acreditada o certificada por el proponente o un tercero con quien haya trabajado
Ingeniero de Pruebas Continuas	Por demanda	Profesional en Ingeniería de sistemas o tecnólogo con mínimo 3 años de experiencia en pruebas manuales y automatizadas en aplicaciones front, backend, dispositivos móviles, calidad y depuración de datos Certificación vigente al momento de ser requerido el servicio ISTQB, SCRUM y/o DevOps Practitioner	3 años en pruebas en aplicaciones front, backend, dispositivos móviles, calidad y depuración de datos	El ingeniero de pruebas continuas debe tener adicionalmente experiencia demostrable en: • Pruebas funcionales, no funcionales y Automatización para dispositivos móviles, aplicaciones front, backend, calidad y depuración de datos • Competencias básicas de programación • Herramientas de gestión y ejecución de pruebas

Rol		Cantidad	Perfil	Experiencia	Experiencia Adicional
Analista	de	Por demanda	Profesional o	2 años en pruebas	El analista debe	tener
pruebas			Tecnólogo	funcionales	adicionalmente experiencia
funcionales				manuales	y	demostrable en:
			Certificación ISTQB y/o SCRUM	automatizadas.	• Scrum
					• Herramientas	de
					automatización y gestión
					de pruebas • Aseguramiento y control

				de calidad
Analista de	Por demanda	Profesional en	2 años en pruebas	El analista debe tener
pruebas no		ingeniería de sistemas	funcionales	adicionalmente experiencia
funcionales		o tecnólogo en	manuales y	demostrable en:
		Sistemas	automatizadas.	• Conocimientos técnicos
		Deseable:		en infraestructura
		Certificación ISTQB, SCRUM		tecnológica • Herramientas de no
				fucionales como JMeter, Owasp, LoadRuner, entre otras • Automatización de pruebas • Conocimientos en herramientas SOAP, WebServices, • Conocimientos básicos en lenguajes de programación como Java Script, Java, .Net, Groovy • Conocimientos básicos de desarrollo de software

Nota: La verificación de todo lo anteriormente requerido antes mencionado, se verificará por parte del supervisor del contrato una vez inicie la ejecución del contrato. EL cambio de alguno de los recursos deberá contar con la aprobación del supervisor del contrato previa validación de hoja de vida y el cambio obedecerá por personal de iguales o superiores especificaciones a las señaladas.

El proponente seleccionado (el contratista) deberá garantizar el cumplimiento del perfil, experiencia y experiencia adicional del equipo por demanda anteriormente solicitado.

2.5. Despliegues

La Cámara de Comercio de Bogotá es responsable de la realización de los despliegues de los aplicativos a probar en los ambientes de pruebas, y tendrá de forma permanente un analista para despliegues, teniendo en cuenta que esto facilitará la prestación del servicio y ejecución de las

pruebas. Es importante que el contratista, tenga experiencia en el manejo de pruebas continuas bajo un modelo DevOps que incluye integración continúa

2.6. Gestión de Incidencias

El proceso de gestión de incidencias está directamente relacionado con la ejecución de pruebas y el seguimiento que de estas se realiza. Así mismo, es utilizado para el reporte de incidencias generadas por otros procesos como la verificación documental y las auditorías referidas en el Modelo Aseguramiento de Calidad (realizada por La Cámara de Comercio de Bogotá o quien éste designe). El contratista deberá indicar como soporta y maneja la gestión de incidencias.

2.7. Herramientas

La implementación y ejecución de la prueba son actividades donde los procedimientos o scripts de prueba, los casos de prueba y cualquier otra información necesaria para la ejecución de la prueba, se utilizan de una forma integrada, por lo tanto se requiere que los resultados de la ejecución de prueba y versiones del producto de software que está siendo sometido a pruebas, queden registrados en las herramientas de prueba establecidas, esta información debe permitir comparar los resultados reales con los esperados, así como los diferentes reportes que contribuyen a asegurar la trazabilidad de las condiciones de prueba hacia las especificaciones entregadas en los documentos de casos de uso y diseño del producto de software. En este sentido el contratista usará las herramientas de las que disponga La Cámara de Comercio de Bogotá para garantizar el desarrollo y las que utilice (previo acuerdo con la Cámara de Comercio de Bogotá) para la ejecución de las siguientes actividades:

• Planeación, ejecución, seguimiento y control de casos de prueba

• Gestión de incidencias

• Ejecución de pruebas de rendimiento, carga y stress

• Pruebas automatizadas

En caso de que el contratista ofrezca herramientas diferentes a las utilizadas por La Cámara de Comercio de Bogotá

• Mantis

• TestLink

• JSF Unit

• Junit

• XUnit

• NUnit

• Jmeter

• Selenium

• TFS – visual studio

• Redmine

• Soap Ui

Se revisará su uso teniendo en cuentas los siguientes aspectos:

1. El licenciamiento será total responsabilidad del contratista.

2. La integración con las herramientas de La Cámara de Comercio de Bogotá estará a cargo del contratista y no deberá incurrir en desarrollos de software ni licenciamientos adicionales por parte de La Cámara de Comercio de Bogotá.

3. La información del proceso de pruebas deberá estar disponible inmediatamente se inicie la ejecución del contrato.

2.8. Procedimiento para la estimación de esfuerzo y pago de los servicios

El Contratista entregará la estimación para cada ciclo de pruebas en el formato acordado entre las partes para ser aprobado por La Cámara de Comercio de Bogotá. En caso de requerirse el detalle de cada estimación, el Contratista deberá estar en capacidad de entregarlo. La Cámara de Comercio de Bogotá se reserva el derecho de aprobar las estimaciones elaboradas por el contratista, y requerir los ajustes que sean necesarios. El pago de los servicios de pruebas de software se realizará sobre la ejecución aprobada del esfuerzo requerido para las fases de los ciclos de pruebas definidos. El contratista se compromete a ejecutar las pruebas en su totalidad, y a realizar el cobro de las mismas por el valor de horas acordado.

3. ASPECTOS GENERALES

3.1. Gestión de proyectos

La ejecución del servicio objeto de la presente especificación técnica se realizará como un proyecto, de forma que se pueda tener una gestión y control adecuado sobre el avance, logro de los objetivos y alcance propuesto. Se requiere que la metodología a utilizar por el oferente esté alineada con metodologías ágiles como Scrum o el Project Management Body of Knowledge (PMBOK®) ágil del Project Management Institute (PMI). También, se deben cumplir los lineamientos que La Cámara de Comercio de Bogotá indique al contratista con respecto a la gestión, reporte y control del proyecto. El contratista deberá presentar informes diarios, semanales y de cierre del rendimiento de los proyectos o necesidades, adicionalmente asistir a todas las reuniones de seguimiento realizadas durante la ejecución del proyecto. El contratista debe contar con el licenciamiento de las herramientas de software necesarias para la realización de todos los procesos de la gerencia de proyectos, descritos en este anexo. Se requiere que el oferente use Team Foundation Server (TFS) en la versión que determine La Cámara de Comercio de Bogotá en el momento de la ejecución del contrato para poder revisar los tableros de control, y cubierto por sus propias licencias.

3.2. Equipos de cómputo

El Contratista deberá disponer de los equipos de cómputo necesarios para el equipo de pruebas incluyendo las diferentes licencias de software utilizadas para la ejecución del contrato.

3.3. Lugar de ejecución del contrato

El Contratista deberá realizar las actividades relacionadas con la ejecución del contrato en las instalaciones de La Cámara de Comercio de Bogotá o en las instalaciones del proveedor cuando es modalidad fábrica previa autorización por parte del supervisor del contrato en la ciudad de Bogotá.

4. Acuerdos de Servicio (ANS)

4.1. Análisis y planeación

El proponente deberá cumplir con los tiempos establecidos para realizar el análisis preliminar y estimación de esfuerzo requerido para ejecutar una “Orden de Trabajo”. Los tiempos establecidos son:

Tipo Orden de Trabajo	Acuerdo de Servicio
Proyectos	Cinco (5) a Diez (10) días hábiles

4.2. Asignación del equipo de trabajo:

El equipo de trabajo necesario para atender una solicitud de servicio debe ser asignado por el proponente en un plazo máximo de cinco (5) días hábiles para asignación de personal en sitio y para atención de requerimientos en fábrica por demanda un plazo máximo de tres (3) días hábiles.

4.3. Errores detectados en UAT y Producción

Cuando se detecten errores en pruebas de usuario UAT (User Acceptance Test) y Producción que no se detectaron por el contratista, deberá asumir la ejecución de pruebas requeridas en resolución de incidencias presentadas sin costo, así como la atención del soporte y validación deben ser atendidos de acuerdo con la siguiente tabla:

Severidad	Descripción	Acuerdo de Servicio
Bloqueante	Bloquea el funcionamiento normal de la aplicación, que impliquen la imposibilidad de atender un proceso crítico que afecte la ejecución de pruebas	Dos (2) horas
Crítico	Caídas, pérdidas de datos o comportamiento anormal grave de la aplicación, que impliquen la imposibilidad de atender un proceso crítico	Seis (6) horas
Grave	Gran pérdida de funcionalidad	Ocho (8) horas
Leve	Mínima pérdida de funcionalidad.	Doce (12) horas
Trivial	Problema de visualización: palabras mal escritas o texto mal alineado	Diez y seis (16) Horas

En caso de no ser posible realizar la prueba por parte del contratista, se aplicará una sanción en facturación así:

ANS	Formula	Rango incumplimiento 1	Sanción en facturación mensual	Rango incumplimiento 2	Sanción en facturación mensual	Rango incumplimient o %	Sanción en facturación mensual de Sprint/Requerimiento/ o ciclo
Errores detectados en UAT (Pruebas de usuario funcional)	ANS1 = Total defectos efecitvos en Pruebas de usuario funcional de Criticidad Stopper, Alta y Media / Total defectos efectivos en QA de Criticidad Stopper, Alta y Media	5% al 15%	2%	16% al 25%	5%	>= 26%	15%
Errores detectados en producción	ANS2 = Total defectos efecitvos en Producción de Criticidad Stopper, Alta y Media / Total defectos efectivos en QA de Criticidad Stopper, Alta y Media	5% al 15%	2%	16% al 25%	5%	>= 26%	15%

4.4. Compensación por incumplimiento en los acuerdos de órdenes de trabajo

Siempre que el proveedor tenga un atraso en la ejecución de las pruebas del 15% o más respecto a la estimación de fecha de finalización, recibirá una penalización del 5% respecto de la estimación del servicio lo cual se verá reflejado al momento del pago.

5. Procedimiento operativo de las órdenes de trabajo

a) La CCB procede a entregar al proponente una solicitud de pruebas indicando Xxxxxxx, historias de usuario y mockups si así se requiere, para su análisis preliminar y estimación de esfuerzo.

b) Xx presentarse dudas sobre cada solicitud, el proponente deberá presentarla a la CCB para aclararla y/o ajustar la respectiva planeación y diseño.

c) El proponente debe estimar el esfuerzo requerido para la ejecución del servicio y entregar los escenarios generales planteados para probar la solución, la cual será revisada por CCB, este entregable se denominará estrategia de pruebas.

d) La estrategia de pruebas será revisada y ajustada por las partes, si es el caso.

e) La CBB aprueba la estrategia de pruebas para que el proponente pueda iniciar su ejecución.

f) El proponente procede a ejecutar las pruebas de acuerdo con el tiempo estimado acordado.

g) Cuando se finalice la prueba, el proponente procede a entregar todos los entregables a la CCB, según lo solicitado. (Casos de prueba diseñados, Scripts de casos de prueba automatizados, evidencias, herramientas de gestión actualizadas, informe de pruebas y certificación de producto conforme o no conforme según sea el caso)

h) Recibida la certificación, la CCB procede a realizar pruebas de aceptación de usuario (UAT – User Acceptance Test).

i) Si se llegaren a presentar incidencias, éstas serán enviadas el proponente de desarrollo para su respectivo análisis y ajuste.

j) Una vez resuelta cada incidencia, la CCB procede de nuevo a ejecutar pruebas de calidad y aceptación.

k) Una vez aprobadas las incidencias y/o la prueba del producto final solicitado, la CCB despliega en producción y se inicia una fase de estabilización, la cual debe contemplar un tiempo de garantía por parte del proponente para errores que puedan detectarse.

l) El proponente procede a facturar y presentar la respectiva factura en la CCB, de acuerdo conel calendario previsto para ello.

6. Garantía

El proponente deberá ofrecer garantía sobre las solicitudes probadas y certificadas. Dicha garantía se refiere a las pruebas de corrección de errores de programación que pudieran aparecer una vez implementados los cambios derivados de cualquier “Orden de Trabajo” de Desarrollo. Las pruebas a las modificaciones realizadas al código, causadas por un mal entendimiento del análisis o errores en la construcción y fallas de ejecución deberán ser cubiertas por el proponente sin cargo adicional a lo pactado inicialmente en la orden de trabajo.

El período de garantía de cada orden de trabajo corresponderá según el esfuerzo requerido para atender dicha orden así:

Esfuerzo requerido	Período de Garantía
Hasta 120 Horas	1 Mes
Entre 121 y 360 Horas	3 Meses
Más de 360 Horas	6 Meses