ANEXO TÉCNICO

SERVICIO DE PRUEBAS DE SOFTWARE

Contenido
1 Introducción ............................................................................................................................................ 2
1.1 Concepto de calidad y pruebas del software ................................................................... 2
1.2 Marco de referencia de los servicios a contratar ........................................................... 2
2 Servicio Pruebas de Software ........................................................................................................... 3
2.1 Objetivo............................................................................................................................................... 3
2.2 Características del servicio ......................................................................................................... 3
2.3 Metodología ...................................................................................................................................... 8
2.3.1 Planeación ................................................................................................................................. 8
2.3.2 Ejecución.................................................................................................................................... 9
2.3.6 Seguimiento y Control ....................................................................................................... 10
2.3.7 Esquema general metodológico ..................................................................................... 10
2.4 Funciones de roles adicionales ............................................................................................... 11
2.5 Despliegues .................................................................................................................................... 11
2.6 Gestión de Incidencias ............................................................................................................... 11
2.7 Entregables .................................................................................................................................... 12
2.8 Anexos .............................................................................................................................................. 12
2.9 Herramientas................................................................................................................................. 12
2.10 Procedimiento para la estimación de esfuerzo y pago de los servicios ............... 13
3 Aspectos generales ............................................................................................................................ 14
3.1 Gestión de proyectos .................................................................................................................. 14
3.2. Equipos de cómputo .................................................................................................................. 14
3.3. Lugar de ejecución del contrato ....................................................................................... 14
ANEXO TÉCNICO
SERVICIO DE PRUEBAS DE SOFTWARE

1 Introducción
Actualmente el ICFES utiliza como metodología de Proyectos de desarrollo SCRUM, 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.

1.1 Concepto de calidad y pruebas del software

En el contexto del proceso de desarrollo de software entendemos la calidad desde los

siguientes criterios básicos:

• Cumplimiento de los requisitos: “Conformance to requirements” (Crosby -1979).

• Listo para su uso: “Fitness for use” (Juran and Gryna -1970).

Así mismos nos apoyamos en la definición establecido por la IEEE Std. 610 – 1991, donde
se define 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.

La realización de estas pruebas de software, basadas en una metodología ágil de ejecución

de pruebas, donde se definan y ejecuten tareas de verificación, garantizan 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 es hacer la ejecución ágil de pruebas (Agile
Testing) que permiten dar lineamientos y certifiquen que el producto sea probado y cumpla
con la calidad necesaria incluso sin haber sido probado exhaustivamente.

1.2 Marco de referencia de los servicios a contratar

ANEXO TÉCNICO
SERVICIO DE PRUEBAS DE SOFTWARE

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 Pruebas de Software

2.1 Objetivo

Prestación de los servicios de ejecución pruebas ágiles de software, sobre los desarrollos de
software del sistema PRISMA del ICFES.

2.2 Características del servicio

El servicio de ejecución de pruebas ágiles de software se prestará en las instalaciones del

ICFES en Bogotá, y será tanto para los desarrollos de los grupos internos del ICFES
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:
ANEXO TÉCNICO
SERVICIO DE PRUEBAS DE SOFTWARE

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

1. El contratista debe tomar como base metodológica los principios de pruebas agiles
(agile testing) de la Agile Testing Alliance para establecer el plan de pruebas del ciclo
de vida de los procesos.

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 alcabala, 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.

Algunas de las prácticas relacionadas con Agile Testing

ANEXO TÉCNICO
SERVICIO DE PRUEBAS DE SOFTWARE

 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. Aquí te dejamos el primero de
una serie de artículos sobre el Test Driven Development (TDD).
 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. Aquí te dejamos un artículo sobre Acceptance Test
Driven Development (ATDD) y como implementarlo 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. Aquí te compartimos un artículo sobre la
herramienta Cucumber y su uso para aplicar Behaviour Driven Development (BDD).
 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. Aquí te dejamos
más información sobre herramientas para automatización de pruebas.
 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. Estos test, usualmente desarrollados 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.

2. El contratista deberá definir y ejecutar la metodología (actividades, roles, artefactos)

de pruebas garantizando la ejecución de las siguientes pruebas:
ANEXO TÉCNICO
SERVICIO DE PRUEBAS DE SOFTWARE

3. El contratista utilizará las herramientas definidas por el ICFES 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 el ICFES y su
respectivo seguimiento. Estas herramientas son:

i. Mantis
ii. TestLink
iii. JSF Unit
iv. Junit
v. Jmeter
vi. Kali Linux
vii. Selenium
viii. TestEngine

En caso en el que el contratista cuente con herramientas para su proceso de pruebas

se evaluará en conjunto con el ICFES para definir cual set de herramientas se utilizará
en la ejecución del contrato.

4. 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 del contratista.

5. 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
ANEXO TÉCNICO
SERVICIO DE PRUEBAS DE SOFTWARE

aquellos en que el ICFES decida apoyar su generación. En casos excepcionales por

la cantidad de datos generados y la complejidad para procesos masivos el ICFES
apoyará ésta generación, sin embargo para la ejecución de pruebas funcionales
individuales o de flujos que no sean masivos será responsabilidad del contratista.

6. El contratista deberá ejecutar todas las pruebas de acuerdo a los casos definidos y
acordados con el ICFES.

7. El contratista deberá realizar la transferencia del conocimiento al ICFES 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 del proyecto Prisma (Directivos de T.I., Gerente de Proyecto,

Product Owner, Arquitectos de Datos, Arquitectos de Aplicaciones, Líderes de
Desarrollo, Analistas de Desarrollo, Analistas Funcionales). Aproximadamente 30
personas.
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 de no más de 10 personas 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.
8. El contratista debe definir los lineamientos y estándares de calidad que se deberán
seguir en el ICFES, 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 el ICFES. Será decisión del ICFES proveer los
artefactos definidos previamente para conocimiento y/o uso del contratista.

9. 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 las mismas, 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
Tema 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.
ANEXO TÉCNICO
SERVICIO DE PRUEBAS DE SOFTWARE

10. 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 el Instituto.

11. El contratista debe entregar una estimación de esfuerzo para cada ciclo de pruebas,
a ser aprobada por el ICFES, y sobre la cual se realizará el pago del esfuerzo. La
estructura del contrato determina que los 5 analistas tengan una dedicación
mensual de 160 horas, si la tarea encomendada se realiza en un número de horas
menor, las restantes deberán ocuparse según lo indique el ICFES. 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.

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 del ICFES, 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
ANEXO TÉCNICO
SERVICIO DE PRUEBAS DE SOFTWARE

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 el ICFES) 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 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 del ICFES 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 entregados por el ICFES 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 Automatizadas: En los escenarios que se definan conjuntamente entre

el contratista y el ICFES, 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
ANEXO TÉCNICO
SERVICIO DE PRUEBAS DE SOFTWARE

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 del ICFES.

2.3.6 Seguimiento y Control

En esta etapa el contratista será el responsable de revisar los reportes de los errores
encontrados en 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.7 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.
ANEXO TÉCNICO
SERVICIO DE PRUEBAS DE SOFTWARE

2.4 Funciones de roles adicionales

Auditor 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.5 Despliegues

El ICFES 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.

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
ANEXO TÉCNICO
SERVICIO DE PRUEBAS DE SOFTWARE

incidencias generadas por otros procesos como la verificación documental y las auditorías
referidas en el Modelo Aseguramiento de Calidad (realizada por el ICFES o quien éste
designe). El contratista deberá indicar como soporta y maneja la gestión de incidencias.

2.7 Entregables

Como resultado de las actividades de las distintas fases, el contratista debe generar como
mínimo los siguientes entregables:

• Estimación de pruebas
• Matriz de trazabilidad de requerimientos, casos de uso o historias de usuario vs
casos de prueba.
• Plan de pruebas y factores de riesgo de pruebas
• Cronograma de pruebas
• Informes de seguimiento de pruebas después de cada ciclo de pruebas.
• Especificación de casos de prueba
• Resultados de la ejecución de pruebas en las herramientas acordadas entre el
contratista y el ICFES.
• Informe de avance de ejecución (diario y semanal por ciclo de prueba).
• Registro de incidencias en la herramienta determinada por el contratista.
• Informes finales de pruebas por sistema o módulo, incluyendo los indicadores.
• Informe de nivel de pruebas de integración y de sistema.

El Contratista debe entregar información en formato digital de toda la información que reside
en sus herramientas.

2.8 Anexos

El contratista al iniciar la ejecución del contrato debe entregar un conjunto de documentos

que expliquen en detalle los siguientes aspectos:

• Metodología de pruebas
• Procedimiento de Gestión de Incidencias
• Procedimiento de Automatización de pruebas
• Procedimiento de Gestión de Riesgos de Pruebas

2.9 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
ANEXO TÉCNICO
SERVICIO DE PRUEBAS DE SOFTWARE

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 el ICFES para garantizar el desarrollo 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 el ICFES

i. Mantis
ii. TestLink
iii. JSF Unit
iv. Junit
v. Jmeter
vi. Kali Linux
vii. Selenium
viii. TestEngine

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 del ICFES estará a cargo del contratista y no
deberá incurrir en desarrollos de software ni licenciamientos adicionales por parte
del ICFES.
3. La información del proceso de pruebas deberá estar disponible inmediatamente se
inicie la ejecución del contrato.

2.10 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 el ICFES. En caso de requerirse el detalle de cada
estimación, el Contratista deberá estar en capacidad de entregarlo. El ICFES 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.
ANEXO TÉCNICO
SERVICIO DE PRUEBAS DE SOFTWARE

3 Aspectos generales
3.1 Gestión de proyectos

La ejecución del servicio objeto del presente términos de condiciones 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 el Project Management Body of Knowledge (PMBOK®) del
Project Management Institute (PMI). También, se deben cumplir los lineamientos que el
ICFES indique al contratista con respecto a la gestión, reporte y control del proyecto.
El contratista deberá presentar informes diarios y semanales del rendimiento del proyecto,
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 el software de gestión de proyectos
Microsoft Project en la versión que determine el ICFES en el momento de la ejecución del
contrato para poder revisar el cronograma, 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 del ICFES, en la ciudad de Bogotá.