DOI:

https://doi.org/10.14483/2248762X.6368

Publicado:

2013-09-26

Número:

Edición Especial

Sección:

Reflexión

PROPUESTA METODOLÓGICA PARA LA PLANIFICACIÓN Y EJECUCIÓN DE PRUEBAS FUNCIONALES EN EL GRUPO TESTING ANALYST DE SABMILLER – BAVARIA

Autores/as

  • Sandra Milena Uribe Peñaloza Universidad Distrital Francisco José de Caldas
  • Beitmantt Cárdenas Quintero Universidad Distrital Francisco José de Caldas
  • Alexandra Abuchar Porras Universidad Distrital Francisco José de Caldas

Biografía del autor/a

Sandra Milena Uribe Peñaloza, Universidad Distrital Francisco José de Caldas

Ingeniera de Sistemas, Estudiante de la Universidad Distrital Francisco José  de Caldas. Bogotá.

Beitmantt Cárdenas Quintero, Universidad Distrital Francisco José de Caldas

Magister en Ciencias de la Información y las Comunicaciones. Bogotá.

Alexandra Abuchar Porras, Universidad Distrital Francisco José de Caldas

Magister en Informatica Aplicada a la Educación. docente planta de la Universidad Distrital Francisco José  de Caldas. Bogotá.

Cómo citar

APA

Uribe Peñaloza, S. M., Cárdenas Quintero, B., y Abuchar Porras, A. (2013). PROPUESTA METODOLÓGICA PARA LA PLANIFICACIÓN Y EJECUCIÓN DE PRUEBAS FUNCIONALES EN EL GRUPO TESTING ANALYST DE SABMILLER – BAVARIA. Redes de Ingeniería, 4, 66–73. https://doi.org/10.14483/2248762X.6368

ACM

[1]
Uribe Peñaloza, S.M. et al. 2013. PROPUESTA METODOLÓGICA PARA LA PLANIFICACIÓN Y EJECUCIÓN DE PRUEBAS FUNCIONALES EN EL GRUPO TESTING ANALYST DE SABMILLER – BAVARIA. Redes de Ingeniería. 4, (sep. 2013), 66–73. DOI:https://doi.org/10.14483/2248762X.6368.

ACS

(1)
Uribe Peñaloza, S. M.; Cárdenas Quintero, B.; Abuchar Porras, A. PROPUESTA METODOLÓGICA PARA LA PLANIFICACIÓN Y EJECUCIÓN DE PRUEBAS FUNCIONALES EN EL GRUPO TESTING ANALYST DE SABMILLER – BAVARIA. redes ing. 2013, 4, 66-73.

ABNT

URIBE PEÑALOZA, Sandra Milena; CÁRDENAS QUINTERO, Beitmantt; ABUCHAR PORRAS, Alexandra. PROPUESTA METODOLÓGICA PARA LA PLANIFICACIÓN Y EJECUCIÓN DE PRUEBAS FUNCIONALES EN EL GRUPO TESTING ANALYST DE SABMILLER – BAVARIA. Redes de Ingeniería, [S. l.], v. 4, p. 66–73, 2013. DOI: 10.14483/2248762X.6368. Disponível em: https://revistas.udistrital.edu.co/index.php/REDES/article/view/6368. Acesso em: 28 mar. 2024.

Chicago

Uribe Peñaloza, Sandra Milena, Beitmantt Cárdenas Quintero, y Alexandra Abuchar Porras. 2013. «PROPUESTA METODOLÓGICA PARA LA PLANIFICACIÓN Y EJECUCIÓN DE PRUEBAS FUNCIONALES EN EL GRUPO TESTING ANALYST DE SABMILLER – BAVARIA». Redes de Ingeniería 4 (septiembre):66-73. https://doi.org/10.14483/2248762X.6368.

Harvard

Uribe Peñaloza, S. M., Cárdenas Quintero, B. y Abuchar Porras, A. (2013) «PROPUESTA METODOLÓGICA PARA LA PLANIFICACIÓN Y EJECUCIÓN DE PRUEBAS FUNCIONALES EN EL GRUPO TESTING ANALYST DE SABMILLER – BAVARIA», Redes de Ingeniería, 4, pp. 66–73. doi: 10.14483/2248762X.6368.

IEEE

[1]
S. M. Uribe Peñaloza, B. Cárdenas Quintero, y A. Abuchar Porras, «PROPUESTA METODOLÓGICA PARA LA PLANIFICACIÓN Y EJECUCIÓN DE PRUEBAS FUNCIONALES EN EL GRUPO TESTING ANALYST DE SABMILLER – BAVARIA», redes ing., vol. 4, pp. 66–73, sep. 2013.

MLA

Uribe Peñaloza, Sandra Milena, et al. «PROPUESTA METODOLÓGICA PARA LA PLANIFICACIÓN Y EJECUCIÓN DE PRUEBAS FUNCIONALES EN EL GRUPO TESTING ANALYST DE SABMILLER – BAVARIA». Redes de Ingeniería, vol. 4, septiembre de 2013, pp. 66-73, doi:10.14483/2248762X.6368.

Turabian

Uribe Peñaloza, Sandra Milena, Beitmantt Cárdenas Quintero, y Alexandra Abuchar Porras. «PROPUESTA METODOLÓGICA PARA LA PLANIFICACIÓN Y EJECUCIÓN DE PRUEBAS FUNCIONALES EN EL GRUPO TESTING ANALYST DE SABMILLER – BAVARIA». Redes de Ingeniería 4 (septiembre 26, 2013): 66–73. Accedido marzo 28, 2024. https://revistas.udistrital.edu.co/index.php/REDES/article/view/6368.

Vancouver

1.
Uribe Peñaloza SM, Cárdenas Quintero B, Abuchar Porras A. PROPUESTA METODOLÓGICA PARA LA PLANIFICACIÓN Y EJECUCIÓN DE PRUEBAS FUNCIONALES EN EL GRUPO TESTING ANALYST DE SABMILLER – BAVARIA. redes ing. [Internet]. 26 de septiembre de 2013 [citado 28 de marzo de 2024];4:66-73. Disponible en: https://revistas.udistrital.edu.co/index.php/REDES/article/view/6368

Descargar cita

Visitas

500

Dimensions


PlumX


Descargas

Los datos de descargas todavía no están disponibles.


PROPUESTA METODOLÓGICA PARA LA PLANIFICACION Y EJECUCION DE PRUEBAS FUNCIONALES EN EL GRUPO TESTING ANALYST DE SABMILLER – BAVARIA

METHODOLOGICAL PROPOSAL FOR THE PLANNING AND EXECUTION OF FUNCTIONAL TESTS IN THE TESTING ANALYST OF SABMILLER BAVARIA GROUP

Sandra Milena Uribe Peñaloza 1, Beitmantt Cárdenas Quintero 2, Alexandra Abuchar Porras 2

1 Estudiante de la Universidad Distrital Francisco José de Caldas sandra_muribe@gmail.com

2 Docente de planta de la Universidad Distrital Francisco José de Caldas beitmantt@udistrital.edu.co , aabucharp@udistrital.edu.co

Recibido: 07/07/2013 Aceptado: 06/08/2013


ABSTRACT

The planning and execution of the tests does not stop at the Orga- nization of files and documents needed to successfully manage the testing, but it goes beyond pretending that this content be acces- sible to all users in the Group of Testers in the area of 'Testing and Deployment' of Bavaria SABMiller, allowing testers this way on an orderly fashion way to add, to remove, to modify or to eliminate information from the documents.

The methodology used is represented by the model V, which requires that each deliverable is verified and validated from the first phase of tests that is running, as well as to identify problems as soon as possible and make sure the specifications are complete, correct and aligned to the relevant standards.

Key words: ERP system, functional testing, stage gate methodology, testing.

RESUMEN

La planificación y ejecución de las pruebas no se detiene en la orga- nización de los archivos y documentos necesarios para administrar exitosamente el testeo, va más allá al pretender que el contenido de este sea accesible a todos los usuarios del grupo de Testers del área “Testing and Deployment” de BavariaSABMiller, permitiendo que estos de manera ordenada adicionen, sustraigan, modifiquen y/o eliminen información de los documentos.

La metodología a utilizar esta representada mediante el modelo V, el cual requiere que cada entregable sea verificado y validado desde el primera fase de pruebas en que se está ejecutando, además de identificar problemas tan pronto como sea posible y asegurarse que las especificaciones están completas, correctas y estén alineados a los estándares relevantes.

Palabras clave: metodología stage gate, pruebas funcionales, sistema ERP, testing.

1. INTRODUCCIÓN

La subsidiaria de SABMiller en Colombia es Bavaria, S. A, la compañía líder con el 68% del mercado de bebidas alcohólicas en Colombia [1].

Bavaria es la mayor compañía de bebidas en Colombia, la operación más grande de SABMiller en Latinoamérica y uno de los contribuyentes más importantes a las utilidades de ese grupo cervecero a nivel mundial.

Bavaria está conformada por seis plantas cerveceras ubicadas en las ciudades de Medellín, Barranquilla, Bucaramanga, Duitama, Tocancipá y Yumbo; todas ellas manufacturan, distribuyen y venden cerveza y maltas. También la conforman dos malterías, una en Tibitó y la otra en Cartagena.

Adicionalmente es dueña de la firma Impresora del Sur, dedicada a la fabricación de etiquetas para sus productos [2].

Caso Bavaria: año tras año, SABMiller continua incrementando su presencia en los países, lo que ha llevado a la compañía a pensar en una solución global que permita desarrollar procesos de negocio estandarizados logrando mayor sinergia entre los países con el fin de ser más competitivos. Es así como en el año 2009 nace el proyecto “Transformation” de la mano de diferentes áreas clasificadas por procesos y metas. Entre estas nuevas áreas se encuentra: Testing and Deployment, la cual tiene a cargo la validación de la funcionalidad de las pruebas a través de métodos que permitan corroborar que el sistema responda correctamente y determinar cómo y cuándo las pruebas serán ejecutadas.

El ciclo de las pruebas funcionales inicia con las IPT (Integrated Product Test), continúan las PT (Performance test), luego pasan a la fase de UAT (User Acceptance test) y finalmente Regression Testing (Validación que el sistema no se afectó con las nuevas implementaciones). Para dar por finalizada cada etapa se deben cumplir ciertos requerimientos de lo contrario no es posible continuar con el avance. Para ejecutar dichas pruebas el área de Testing and Deployment cuenta con un grupo de 5 analistas especializados en pruebas y quienes conocen perfectamente el sistema sobre el cual se soportan todos los procesos en la compañía. Son estos los encargados de dar el aval técnico para el paso a productivo, no sin antes tener la aceptación total del usuario que realizo el requerimiento.

Actualmente existe una metodología de pruebas sobre la cual se rige el equipo de analistas. Esta metodología es administrada por un tercero, lo que en repetidas ocasiones ha generado retrasos en la entrega de resultados, ya esta metodología no se acopla a las exigencias y procesos del negocio y además la metodología empelada es desconocida por los integrantes del equipo de analistas ya que es información confidencial de la compañía. [3]

Lo que se requiere entonces es proponer una metodología acorde al sistema modular SAP y brindarle al grupo de testers la documentación actualizada con los lineamientos de la planificación y ejecución de las pruebas, definiendo los entregables al final de cada etapa.

Como respuesta a esta necesidad se va a trabajar sobre la documentación del proceso de pruebas y la metodología sobre la cual se deberían desarrollar los proyectos en el área de Testing and Deployment.

Cuando la compañía desea añadir una nueva funcionalidad al sistema, mejorar los procesos sistemáticos ya existentes y/o verificar que lo que actualmente están en producción no se vean afectados con las nuevas funcionalidades, la cual se hace mediante una solicitud; donde se define el requerimiento de manera clara y detallada, aprobado por los responsables del proceso y del área que realiza la solicitud.

Este requerimiento lo recibe el área “Testing and Deployment” la cual define los lineamientos como son: el alcance, la fecha, el cronograma, entre otros. Luego el Project Delivery Lead, escala la solicitud al área de pruebas TCT (Technical Component Testing) aquí se encargan de validar el tema a nivel de desarrollo, y a nivel técnico. Una vez las pruebas TCT son exitosas (en caso que hayan sido requeridas) pasan al grupo de pruebas FTA: Functional Testing Analyst, quienes entregan la aprobación o rechazo de la solicitud a nivel funcional indicando en el transcurso de la ejecución si es necesario ir haciendo ajustes o de lo contrario es que el requerimiento está listo para pasar a producción. [4]

Durante la ejecución de las pruebas los TA (Testing Analyst) entregan avances diarios al tercero que administra las pruebas para que ellos determinen el porcentaje real avanzado de acuerdo a las métricas que se establecieron en el documento de la solicitud. Con esto se realizan reuniones de seguimiento con todo el grupo involucrado en el proyecto y se lleva un control total.

Al finalizar las pruebas funcionales, dicho requerimiento pasa a la siguiente fase: UAT (User Acceptance Testing) pruebas que son ejecutadas por el dueño del proceso que realizo la solicitud o por una persona que pertenezca al área de donde viene el requerimiento y que es autorizada por el gerente del área. En caso que las pruebas sean aceptadas por el usuario es posible que pasen a una tercera fase: Regression Testing pero esto depende del impacto que tenga el requerimiento. En caso que tenga un alto impacto nuevamente toman acción los TA para ejecutar la tercera fase y realizar el mismo proceso que ejecutan a nivel de seguimiento en la primera fase (IPT).

Este proyecto tiene 5 pilares fundamentales basados en los parámetros y principios de la organización donde se está llevando a cabo. Estos pilares son:

  1. Documentación.
  2. Consolidación de información.
  3. Propuesta metodológica.
  4. Desarrollo de un documento base para una gestión del conocimiento.
  5. Alineación sobre herramientas y estrategias para las pruebas.

2. MARCO TEÓRICO

2.1. Los sistemas de información

Hoy día las organizaciones están respaldadas por un conglomerado de sistemas de información (SI), que respaldan las diversas funciones de negocio dentro de una organización los SI son considerados como “el sistema nervioso”, ya que estos se encargan de hacer llegar a tiempo la información que necesitan los distintos elementos de la organización empresarial, permitiendo de esta forma una actuación conjunta, coordinada y orientada hacia los resultados (figura 1 ).

Los sistemas de información actuales se interconectan con clientes y proveedores a través del E-commerce, siendo hoy en día es uno de los medios más utilizados por las empresas ya que la visibilidad en la virtualidad debe ser un factor determinante para que las empresas potencializan su crecimiento y junto con esto la utilización de aplicaciones de administración de la relación con los clientes (CRM).

• Customer = Clientes.

• Relationship = Relaciones / Interacciones.

• Management = Administración / Manejo / Gestión / Gerencia.

Por ende el CMR busca la integración con cada una de las áreas de la empresa, en todas las áreas se busca la mayor interacción posible con todos los tipos de usuarios que pueda tener la organización, así como la automatización de los procesos corporativos, es por ello que se la arquitectura del CMR presenta los componentes (figura 2 ).

CMR OPERACIONAL o conocida como “frontoffice”, la cual involucra todas las áreas que presentan contacto directo con clientes. Es la encargada de permitir y preparar una comunicación eficaz hacia el cliente y desde este mismo.

CRM Analítica o conocida como CRM de “backoffice” o nivel “estratégico”, y esta implica e incluye el análisis de todas las actividades que son realizadas en el front-office. Por lo tanto se faculta y acredita el procesamiento de la información de los clientes para proporcionar y facilitar el análisis, la toma de decisiones y las posibles modificaciones de los diferentes procesos del negocio (figura 3 ).

2.2. Sistemas integrados de gestión ERP

Un sistema ERP puede definirse como un sistema integrado de software empresarial, compuesto por módulos funcionales (ventas, distribución, finanzas, recursos humanos, etc) que son adaptados a las necesidades de los clientes (organizaciones). Todos estos módulos están interconectados entre si y la base de datos es común para todos, es así como se garantiza la coherencia e integración de los datos. El hecho que el sistema sea modular facilita que pueda ser implantado por etapas reduciendo el impacto en las organizaciones al facilitar el paso desde los sistemas anteriores.

Cada proveedor de ERP define la modularizacion del software de acuerdo a la solución que desea plantear, ya sea una solución técnica o comercial.

La implantación de un sistema ERP suele ser compleja y costosa, la dificultad técnica y organizativa, la adquisición de productos y los servicios de consultoría tienen un coste bastante elevado ya que van dirigidos al mercado de las medianas y grandes empresas. Los factores claves que deben ser tenidos en cuenta para el éxito del proyecto de implantación son: planificaciones técnicas, económicas y organizativas realistas, compromiso de la dirección del proyecto, definición precisa de los objetivos, gestión del cambio organizativo, formación técnica a los usuarios y la definición de un equipo con experiencia en el sistema elegido.

2.3. Prueba de un sistema

El Testeo es una práctica profesional en el campo de la ingeniería, que se aplica como parte del proceso de desarrollo del software. Su objetivo primordial es verificar que el producto cumpla con las especificaciones requeridas por el usuario buscando disminuir los riesgos en la definición y ejecución, logrando con ello confianza en los aplicativos en operación. Entiéndase como producto una aplicación de software, un servicio.

El Software Testing, como es más conocido, se aplica desde el levantamiento de los requerimientos del cliente, hasta la implementación y operación, lo cual le permite tanto a las empresas consumidoras como a las empresas desarrolladoras proteger los resultados y mitigar los riesgos [6].

2.4. Metodología PMI

En el desarrollo de este proyecto educativo se utilizara la metodología PMI para la gestión de ciertos aspectos entre los cuales se encuentran:

• Definición de requisitos.

• Definición del alcance.

• Identificar a los interesados.

3. METODOLOGÍA

La propuesta de modelo para pruebas se centra este artículo es el “ModeloV” de la metodología Stage [7] Gate, un marco de referencia estandarizado y aprobado que define el desarrollo estándar del ciclo de vida del testing. Hay que definir que la metodóloga stage gate es un acercamiento que se puede utilizar para hacer el proceso de desarrollo de productos con más eficacia. Siendo un modelo para manejar el proceso de nuevos productos, desde una idea hasta el lanzamiento de un producto.

El modelo V, requiere que cada entregable sea verificado y validado en el primer intento de la fase de pruebas que se esté ejecutando para identificar problemas tan pronto como sea posible y asegurarse que las especificaciones están completas, correctas y se adhieren a los estándares relevantes.

El testeo según el modelo V, asegura que las especificaciones estén correctamente implementadas y que la solución cumpla con los requerimientos y rendimiento del negocio.

En el modelo planteado; las tareas de: inicio, análisis de requerimientos, diseño, construcción, verificación, son ejecutadas en el lado izquierdo del modelo V.

Las tareas de ejecución del testing o pruebas y despliegue aparecen en el lado derecho de la figura 4 .

La intervención en análisis y explicación para la fase de pruebas en este articulo se centra solo en el extremo superior derecho de la figura anterior, donde se observan incluidas las etapas: IPT, PT y UAT y REGRESION.

Estas pruebas son incluidas dentro de un paquete de pruebas llamado “Release”. Citando el caso modelo práctico para este documento: SABMiller, es importante mencionar que el equipo interno de pruebas ejecuta 4 ciclos: IPT, PT y UAT y finalmente un último ciclo: Regresión. Los 4 ciclos de pruebas se regirán bajo la misma metodología: Stage-Gate.

3.2. Alcance de las pruebas

Desarrollar el test Approach: desarrollar el test Approach usando un documento de estrategia de testeo como punto de inicio. Se deben describir los objetivos, el alcance, los criterios de entrada / salida, herramientas de prueba y el ambiente de pruebas para cada una de las fases.

Crear plan de trabajo: describir las tareas, recursos, y un cronograma de fechas para cada etapa del ciclo de vida de las pruebas.

Propósito: este entregable tiene como finalidad la definición del enfoque y la estrategia de pruebas.

Alcance: este entregable describe a alto nivel los proyectos que se han incluido dentro de la fase de pruebas, la estrategia, las actividades y los lineamientos.

Supuestos y exclusiones: se debe partir del supuesto que los proyectos han seguido la metodología Stage-Gate en sus primeras fases de planeación, diseño y construcción. El o los sistemas de información que van a ser probados se han considerado dentro de las fases de pruebas anteriores (técnicas, componentes) y dentro de todos los escenarios necesarios para validar los cambios implementados. Al finalizarse las pruebas UAT no deben existir Issues de impacto crítico que detengan la salida a producción de las pruebas.

Terminología: se definen todos los términos con su respectiva descripción, que van a ser utilizados en el documento a continuación se muestra un ejemplo en la tabla 1 de cómo plantear esto.

3.3. Planeación de la prueba

La planeación del test detalla: las tareas, la duración, las fechas, los hitos, los equipos dependientes y las personas requeridas en cada fase del test. El entregable en esta etapa es el Test Plan.

Con el fin de planificar correctamente las anteriores tareas se debe antes completar las siguientes actividades:

• Crear el plan de pruebas.

• Plan de entorno de prueba.

• Gestión de la prueba.

3.4. Test plan

El plan de pruebas documenta los detalles de quién, qué, porqué, cuándo, y donde serán ejecutados los escenarios y los ciclos de pruebas. Este plan de pruebas permite al gerente del proyecto o al líder de pruebas preparar la fase de pruebas.

Las fechas de los ciclos de pruebas están planeadas para facilitar la programación de los participantes en las pruebas. Los requerimientos de cada ciclo se identifican y organizan antes de comenzar las pruebas (lugares de reunión, entornos, datos, etc). El test plan, busca que el objetivo de la prueba se cumpla en su totalidad, que el sistema y los procesos de negocio funcionen conjuntamente con los controles de seguridad y el negocio.

3.5. Preparación de las pruebas

Las actividades de la preparación de las pruebas, basadas en el test plan, implican el desarrollo detallado de las condiciones de las pruebas, los scripts, datos comunes y resultados esperados. A su vez se basa en los escenarios de pruebas y en las condiciones definidas como parte del test plan. Además el entorno de las pruebas será establecido. A fin de preparar efectivamente las pruebas, las siguientes tareas deben ser completadas:

• Completar el plan de pruebas.

• Reparar el entorno de pruebas.

• Gestión de las pruebas.

3.6. Ejecución de las pruebas

Una vez que los scripts de las pruebas se han finalizado y el entorno de las pruebas está listo, el script será ejecutado en el sistema; los resultados actuales serán capturados y verificados contra los resultados esperados. Los problemas identificados durante la ejecución de las pruebas serán tomados como defectos. Estos defectos serán arreglados y el script correspondiente será ejecutado nuevamente en las pruebas de regresión.

3.7. Script

En la ejecución de las pruebas, el o los entregables dependen de la cantidad de iniciativas que se incluyan por Reléase, sin embargo el documento es uno solo y se ajusta dependiendo las pruebas que vayan a realizarse. Este documento es un “Script” que referencia todos los pasos que deben ser ejecutados en la fase de pruebas, ya sea IPT, UAT, regresión.

3.8. Cierre de la prueba y firma

Los criterios exactos para el cierre de una etapa de pruebas deben ser definidos. Para esto se plantea que se elabore un documento, en el cual se definan claramente todos estos criterios. Una vez que los criterios están cumplidos deben ser usados para compilar el “Test Closure Memo”.

El Test Closure memo servirá como un documento de aprobación final generado al final de cada fase de pruebas (IPT, PT, UAT, Regresión). Este entregable resumirá las actividades de prueba incluyendo: Resultados de las ejecuciones, resultados de paso o momentáneos, defectos sobresalientes, riesgos y problemas abiertos, seguimiento de ítems, etc.

El equipo funcional de procesos (líder de pruebas y compañía externa) debe completar el Test Closure / Report al final de cada fase de pruebas. Los Test Closure serán consolidados y usados durante las reuniones que dan paso de una fase a otra.

Bavaria S.A tiene la documentación del Test Closure a cargo del equipo Solution and Deployment, sin embargo a la fecha no se tiene un entregable definido, solamente se realiza una reunión informativa y se envía un correo a los interesados.

4. CONCLUSIONES

Se determina que es importante estar a la vanguardia de los métodos, técnicas y metodologías para realizar las pruebas, las cuales esta inmersas en todos los proyectos que se realizan.

En la empresa Bavaria trabaja con cuatro tipos diferentes de metodologías como son: proyectos de implementación de aplicaciones (génesis), proyectos de outsourcing o cambios organizacionales ((BPO), proyectos de infraestructura (Mercury & Atlas), proyectos de generación de capacidades de negocio (Organge).

La metodología Stage Gate, permite tener entregables por cada fase de pruebas: Test Plan, test approach, scripts and test closure. Esta metodología aporta ventajas como la gestión del riesgo, que es un componente inherente a los procesos que se llevan a cabo en las organizaciones.

Toda organización que deba entregar resultados de proyectos de TI alineados con los procesos del negocio debe emplear una metodología que se ajuste al sistema de información sobre el cual se lleven a cabo todos los procesos. Esto en pro de que la salida en vivo de dichos proyectos sea exitosa y que permita que cada peso invertido en el negocio tenga rentabilidad dentro de los procesos del negocio.

Referencias Bibliográficas

  1. Software Factoring, Metodología de desarrollo de proyectos. [En línea], consultado en Agosto 8 de 2012, disponible en: http://www.vsf.es/web/ es/metodologia/desarrollo-de-proyectos. html.
  2. Coley consulting, What is UAT, and why do it? [En línea], consultado en Noviembre 10 de 2012, disponible en: http://www. coleyconsulting.co.uk/whatuat.htm.
  3. P. Camille; Executive advisor – CAST software. [En línea], consultado en Noviembre 15 de 2012, disponible en: http://www.es.sogeti.com/PageFiles/173/ P a u l %2 0 B e n t z _ Do %2 0 y o u %2 0 me a s u r e %2 0 t h e %2 0 i n t e r n a l %2 0 quality%20of%20your%20applications. pdf.
  4. Business Consulting – Testeo y aseguramiento de la calidad. [En línea], consultado en Febrero 15 de 2013, disponible en: http://www. ermesconsulting.com/docs/ SQAyTesteo_ Web.pdf.
  5. A. Gómez, C. Suarez, Sistemas de información, herramientas prácticas para la gestión, Editorial Alfa omega, 3 edición, pp 37-39, 2005.
  6. W. Bentley; Análisis de sistemas diseño y métodos, Editorial McGraw Hill, séptima edición, pp 75-79, 2010.
  7. J. Munuera, I. Escudero, Estrategias de marketing, Editorial Esic, pp 292 – 294, 2007.

Artículos más leídos del mismo autor/a

Loading...