ESTRATEGIA DE VALIDACIÓN DE CALIDAD DE UN PRODUCTO SOFTWARE. MODELADO DEL PROCESO SEGÚN LAS PAUTAS ESTABLECIDAS POR BPMN

Transcripción

1 ESTRATEGIA DE VALIDACIÓN DE CALIDAD DE UN PRODUCTO SOFTWARE. MODELADO DEL PROCESO SEGÚN LAS PAUTAS ESTABLECIDAS POR BPMN Yeleyne Maure Díaz Mayrilis Castillo Suárez Universidad de las Ciencias Informáticas Resumen Los proyectos de desarrollo de software han padecido tradicionalmente problemas de calidad, tanto en el propio proceso de desarrollo como en los productos que entregan. La presente investigación tiene como objetivo primordial dar a conocer una estrategia de cómo efectuar un proceso de pruebas que garantice la validación del software, tarea de vital importancia dentro del ciclo de desarrollo de un sistema, pues proporciona un alto grado de confianza y seguridad no solo en el producto, sino en los resultados que se obtendrán al implantarlo. La estrategia ha sido modelada siguiendo las pautas establecidas por Business Process Modeling Notation o BPMN (en español Notación para el Modelado de Procesos de Negocio), estándar más reciente para el modelado de procesos, con el propósito de que sea fácilmente entendible por parte de todos los involucrados e interesados del negocio. Palabras clave: producto, calidad, desarrollo de software, validación. Abstract The software development projects have traditionally suffered from quality problems, both within the development process and the products they deliver. The present investigation aims primarily to present a strategy for how to make a testing process to ensure software validation, a vital importance task in the development cycle of a system, as it provides a high degree of confidence and security not only in the product also in the results that it will be obtained after implement it. The strategy has been modeled along the lines established by the Business Process Modeling Notation or BPMN, the latest standard for process modeling, for the purpose of which is easily understandable by all involved and interested in the business. Keywords: product, quality, software development, validation.

2 1. Introducción El mercado internacional demanda cada vez con más fuerza, productos de software eficientes, fiables, capaces de soportar cambios y de adaptarse a nuevos entornos. Para ello se hace imprescindible desarrollar una estrategia de pruebas que garantice la satisfacción del cliente a partir de la validación del sistema por desarrolladores y especialistas. La calidad del producto es lógicamente muy dependiente de la calidad del proceso de desarrollo, de esta manera si se lleva a cabo un proceso defectuoso, lo más probable es que se obtenga un producto insuficiente. La validación de software es de vital importancia ya que proporciona un alto grado de confianza y seguridad no solo en el producto sino en los resultados que se obtienen al implantarlo, validarlo es un requisito que debe ser cumplido con rigor. Por tal motivo se hace necesaria una especificación documentada de los requisitos para que sea posible chequear su cumplimiento, se necesita contar con personal calificado y capacitado para probar el sistema, con la disciplina y responsabilidad suficientes para cumplir estrictamente con las tareas que le son encomendadas como parte del proceso de pruebas. Se requiere además tiempo y esfuerzo y finalmente la conclusión de que el sistema está validado, debe estar respaldada por evidencia colectada a partir de las actividades planificadas a lo largo del proceso de desarrollo. El costo de la calidad en etapas tempranas del desarrollo es siempre una alternativa más rentable, que conlleva a menos defectos en la solución desarrollada, mejor situación económica para la empresa, mejores productos, aumento del bienestar de los involucrados, menor rotación del personal, clientes satisfechos y mejor imagen ante la creciente demanda de sistemas confiables. El costo total de la calidad del sistema está condicionado por el costo del control de la misma, donde intervienen el costo de prevención y evaluación del software en cuestión; y el costo de la falta de control que está determinado por el costo de las fallas internas y externas. Figura 1: Costo Total de Producci n de Software Hoy en día es primordial verificar y evaluar la calidad del software desarrollado con el objetivo de minimizar el costo de su reparación. Mientras antes se detecte una falla, menos costosa será su corrección. Realizar pruebas de software es una buena práctica en este sentido, ya que arrojará todos aquellos errores que posee el sistema para ser resueltos con la menor brevedad por el equipo de desarrollo.

3 El presente trabajo expone una estrategia que posibilita efectuar un proceso de pruebas exitoso, modelada siguiendo las pautas establecidas por Business Process Modeling Notation o BPMN (en español Notación para el Modelado de Procesos de Negocio), con el propósito de que sea fácilmente entendible por todos los involucrados e interesados del negocio. 2. Objetivos La presente investigación tiene como objetivos primordiales: Describir una estrategia de validación de soluciones informáticas que posibilite efectuar un proceso de pruebas exitoso que garantice la calidad del software. Analizar los resultados obtenidos tras aplicar la estrategia en un caso de estudio propuesto. 3. Caso de Estudio En el Departamento de Contabilidad de una Empresa, se gestionan de manera rigurosa las negociaciones que tienen lugar con terceros, con el propósito de solventar y viabilizar las necesidades de la compañía. Como parte de los procesos que tienen lugar mensualmente, se encuentra la conciliación de pagos con los diferentes organismos, por cuestión de aseguramiento alimenticio de los trabajadores de la empresa. Actualmente el Especialista en Gestión Económica, realiza esta tarea de forma engorrosa, pues los datos que se manejan son llevados en formato Microsoft Excel, dificultando así la consulta y procesamiento de la información, tornándose cada vez más complicados debido a su volumen creciente. Esto trae consigo la falta de información actualizada, oportuna y fiable para el Departamento de Contabilidad y la Empresa en general. Luego de 3 meses de desarrollo continuo de una solución informática que gestiona de manera eficiente las necesidades anteriormente expuestas, y a su vez proporciona la generación de reportes con gráficos comparativos y personalizables que facilita la labor del Especialista para el análisis estadístico de los datos almacenados, se hace necesario certificar la calidad de la solución desarrollada, antes de ser entregada al cliente para su explotación. Pruebas de Software. En el ciclo de vida de un producto de software, las pruebas que se realizan con el propósito de detectar anomalías en términos de validación y pautas definidas por la arquitectura, comprobar el cumplimiento de los requisitos solicitados por el cliente, analizar los tiempos de respuesta de la solución así como otras cuestiones de vital importancia que deben tenerse en cuenta al desarrollar un sistema, contribuyen a verificar y determinar la calidad del mismo. Seguidamente se enuncian 4 niveles de prueba por los que idealmente debe transitar un producto software antes de ser entregado al cliente para su explotación. Pruebas Unitarias. Constituyen la garantía de que los módulos, como partes individuales dentro del sistema, no presentan fallas y responden a los requisitos funcionales a partir de los cuales fueron implementados. Unas pruebas unitarias desarrolladas correctamente contribuyen a minimizar los errores en las pruebas de integración, simplificando de esta manera la labor de los

4 desarrolladores. De igual forma favorecen la refactorización y optimización del código, pues las anomalías son más fáciles de detectar y corregir en este nivel. Pruebas de Integración. Centran su atención en las pruebas al sistema ya ensamblado y acoplados todos sus módulos en función de las necesidades del cliente. Brindan la posibilidad de detectar los errores del producto al testear su funcionamiento como un todo en un ambiente controlado. Son realizadas con la intención de lograr un producto cada vez más robusto, estable, seguro y con la calidad requerida. Pruebas de Validación Alfa. Con el propósito de realizar una revisión minuciosa del sistema, se efectúan las pruebas de validación alfa, conocidas en la Ingeniería de Software como aquellas realizadas por un usuario con el desarrollador como observador, en un entorno controlado y simulando las condiciones reales a las que será sometido el sistema para su explotación. Es recomendable sin embargo que le sea añadida a estas pruebas, una revisión cruzada por parte de los desarrolladores. La revisión cruzada consiste en que los desarrolladores en el rol de probadores, participen en el testeo del sistema, probando aquellos módulos en los cuales no participaron en su desarrollo. Dicha revisión aporta un valor añadido al proceso de pruebas, pues la experiencia adquirida por los programadores durante el desarrollo del sistema constituye una provechosa fuente de conocimientos que es utilizada con el propósito de, no solo detectar errores altamente complejos antes de que se conviertan en un riesgo en los módulos desarrollados por sus compañeros, sino de proponer soluciones a los mismos e incluso optimizar las soluciones desarrolladas. Pruebas de Liberación. Pruebas realizadas por un tercero, especialistas de calidad de software de una institución encargada de validar que el software cuente con la calidad requerida para ser entregado a los clientes finales. BPMN. La Notación para el Modelado de Procesos de Negocio (BPMN, por sus siglas en inglés) es un nuevo estándar de modelado de procesos de negocio, una notación que ha sido diseñada específicamente para coordinar la secuencia de procesos y los mensajes que fluyen entre los diferentes procesos participantes. Esta notación estándar facilita el entendimiento de las colaboraciones y transacciones de negocio entre grupos de trabajo, departamentos, áreas y organizaciones. No se requiere que los participantes cuenten con un perfil técnico en sistemas, por esta razón BPMN constituye la solución a los problemas comunes de comunicación entre ingenieros de software y clientes, pues al posibilitar que todos hablen el mismo idioma, el éxito del proceso está garantizado. BPMN define diagramas de procesos de negocios basados en la técnica de diagramas de flujo, adaptados para graficar las operaciones de los procesos de la organización. Se compone de un conjunto de elementos gráficos que facilitan un diagrama entendible tanto por audiencias de negocios como técnicas.

5 Estrategia de Validación de Calidad de un Producto Software. Luego de exponer los elementos técnicos elementales necesarios referente a los niveles de prueba ideales por los que debe transitar un producto antes de ser entregado finalmente al cliente para su explotación, así como las facilidades que proporciona BPMN para el modelado de procesos, se cuentan con los recursos suficientes para comprender el proceso de pruebas de liberación de un producto software que se describe a continuación que constituye la estrategia propuesta en la presente investigación. El proceso inicia con las Pruebas Unitarias que reciben como entrada los requisitos funcionales solicitados por el cliente y debidamente especificados por los analistas de sistema, estos constituyen un elemento que permanecerá de manera constante en cada prueba que se le realice al sistema. De igual forma constituye una entrada a esta actividad inicial, el Sistema en su versión 1.0. Las Pruebas Unitarias serán realizadas mientras se detecten errores en la aplicación, en caso contrario se obtiene una versión 2.0 lista para entrar en Pruebas de Integración. Figura 2: Inicio de las Pruebas. Pruebas Unitarias. Durante las Pruebas de Integración se sigue la misma estrategia de realizar los testeos de integración mientras sean detectadas anomalías, una vez concluido el proceso se adquiere la versión 3.0 a la cual se le practicarán las Pruebas de Validación Alfa bajo las mismas condiciones estratégicas de los niveles de pruebas anteriores, con la particularidad que una vez concluidas, se finiquitaría con una versión 4.0 del sistema estable, depurado de errores cometidos en el proceso de desarrollo, adecuadamente corregidos por desarrolladores altamente capacitados y con la experiencia necesaria para no solo dar solución a las anomalías detectadas sino, para optimizar las soluciones desarrolladas con la intensión de acercarse cada vez más a la excelencia técnica que espera el cliente.

6 Figura 3: Pruebas de Integraci n. Figura 4: Pruebas de Validaci n Alfa. Con la culminación de las pruebas efectuadas por el equipo de desarrollo, el sistema es entregado a los terceros involucrados en el proceso, especialistas de calidad de software, que serán los encargados de certificar que el sistema está listo para su entrega final, para dar cumplimiento a esta actividad los especialistas desarrollarán las Pruebas de Liberación. De estas pruebas se realizarán al menos 2 iteraciones con el propósito de realizar un análisis exhaustivo en busca de no conformidades en el sistema, las cuales serán resueltas por los desarrolladores en la medida en que se detecten. Al concluir la segunda iteración los especialistas deberán desarrollar un análisis sobre los errores encontrados para determinar la necesidad de efectuar una tercera iteración de pruebas o simplemente un muestreo donde podría finalmente liberarse o no el sistema. El análisis básicamente consiste en determinar si tuvo lugar una disminución considerable de las no conformidades (NC) detectadas en la segunda iteración con respecto a las encontradas en la primera, para ello se plantean la siguiente fórmula: Si el análisis arrojara resultados desfavorables, se efectuaría una tercera iteración en la cual, de encontrarse no conformidades, culminaría el proceso de pruebas con la no liberación del producto debido a la cantidad de errores detectados en el proceso. En caso de no encontrarse fallas en la tercera iteración o los resultados del análisis concluyeron que no era necesario realizarla, se procedería a realizar un muestreo final donde los especialistas seleccionan un conjunto de funcionalidades de aquellos módulos que durante el proceso de pruebas lideraron las anomalías detectadas, para garantizar que estas fueron resueltas y que ya no constituyen una amenaza a la calidad del sistema. El muestreo final estipulará definitivamente si el sistema cuenta con la calidad necesaria y suficiente para ser presentado al cliente, en cuyo caso se liberaría el sistema satisfactoriamente o si lamentablemente es rechazado y no se certifica su calidad por parte de los especialistas. La propuesta anteriormente expuesta ha sido modelada siguiendo las normativas establecidas por BPMN con la intención de que pueda ser presentada y discutida con todos los

7 involucrados en el proceso de desarrollo del software sin importar los conocimientos técnicos que puedan o no poseer, pues la poca complejidad de la notación facilita el entendimiento propiciando un lenguaje común. Figura 5: Estrategia de Pruebas.

8 4. Resultados Con el objetivo de validar esta investigación, la estrategia propuesta se aplicó al caso de estudio enunciado anteriormente, y como resultado arrojó lo siguiente. Resultados arrojados tras efectuar las Pruebas Unitarias. Figura 6: No Conformidades - Pruebas Unitarias - Luego de realizada la primera iteración de las pruebas unitarias se detectaron un total de 17 no conformidades (NC), que fueron corregidas por los desarrolladores quedando así el sistema depurado de una primera revisión que centró su atención en eliminar las fallas de cada uno de los módulos del sistema como piezas separadas y comprobar el cumplimiento de los requisitos funcionales que dieron lugar a su implementación. Se efectuó una segunda iteración que no arrojó NC y dejó el sistema listo para la próxima fase. Resultados arrojados tras efectuar las Pruebas de Integración. Figura 7: No Conformidades - Pruebas Integraci n -

9 Las pruebas de integración concluyeron en un primer período con un cúmulo de 16 anomalías. De ellas 9 fueron clasificadas como Alta, hubo un incremento con respecto a la fase anterior, comportamiento que encuentra su causa en el testeo del sistema ya ensamblado, pues innegablemente el éxito y estabilidad de un sistema está condicionado por su capacidad de funcionar con la calidad requerida una vez acoplados todos sus módulos, por tal razón, garantizar esta competencia constituye generalmente uno de los retos a los cuales se enfrenta el equipo de desarrollo. Al término de una segunda iteración, no fueron detectadas no conformidades, dando paso al inicio de las pruebas de validación alfa. Resultados arrojados tras efectuar las Pruebas de Validación Alfa. Figura 8: No Conformidades - Pruebas Validaci n Alfa - Las pruebas de validación alfa generaron un total de 24 inconsistencias. La cantidad de no conformidades pudiera resultar alarmante en relación a las fases de pruebas precedentes, sin embargo es válido destacar que en esta fase intervienen de manera opcional, pero altamente aconsejable, los desarrolladores en el rol de probadores de aquellos módulos en los cuales no tuvieron participación durante su desarrollo. Esta revisión sin dudas constituye un valioso aporte al proceso de pruebas, por la experiencia y la capacidad de los programadores de detectar errores complejos y a su vez aportar ideas que optimicen las soluciones implementadas. Las pruebas de validación alfa concluyen con una segunda sesión libre de fallas. Resultados arrojados tras efectuar las Pruebas de Liberación.

10 Figura 9: No Conformidades - Pruebas de Liberaci n- Las pruebas de liberación efectuadas por los especialistas de calidad de la compañía encargada de certificar que el sistema posee la calidad requerida para someterlo a consideración de los clientes, concluyeron solamente con 6 y 4 anomalías en las iteraciones 1.0 y 2.0 respectivamente. Razón por la cual, determinaron no realizar una tercera iteración, sino un muestro final de la aplicación. Figura 10: Muestreo Final al Sistema

11 El proceso de pruebas realizadas, concluyeron con cero anomalías detectadas en el muestreo final efectuado por los especialistas de calidad. El sistema fue liberado y certificado satisfactoriamente. La garantía del éxito está sustentada no solamente en el esfuerzo y la constancia del equipo de desarrollo y demás involucrados en cada fase de pruebas, sino en el seguimiento riguroso de una estrategia definida en pos de solventar en cada iteración las fallas detectadas y contribuir con la optimización de las soluciones desarrolladas, al resultado final: un sistema sólido, que responde a las necesidades del cliente. 5. Conclusiones La validación de software constituye un requisito de obligatorio cumplimiento en el proceso de desarrollo de un producto software con calidad, por eso la atención esmerada que se le presta a esta actividad, como parte del proceso de desarrollo, probando desde las partes más pequeñas y su engranaje, hasta su total funcionamiento, fuera y dentro de un ambiente real. La estrategia propuesta en el presente trabajo posibilita efectuar un proceso de pruebas exitoso que garantiza la validación del software, el cumplimiento de los acuerdos firmados y la satisfacción del cliente; dicha estrategia tiene como base, la experiencia de los autores de 4 años de desarrollo de productos software. La misma se presenta modelada siguiendo las pautas establecidas por Business Process Modeling Notation o BPMN (en español Notación para el Modelado de Procesos de Negocio), con el propósito de que sea fácilmente entendible por todos los involucrados e interesados del negocio. De igual forma la estrategia abordada en el presente artículo es el resultado de un estudio realizado que propone el ciclo de pruebas a efectuar a un producto software que tribute a obtener sistemas cada vez con mayor calidad, donde la excelencia técnica contribuya a escalar en la lista de preferencias en el mercado internacional, como desarrolladores de productos altamente confiables, robustos, estables y funcionales. Referencias BPMN. (s.f.). Recuperado el 2010, de Jacobson, I., Booch, G., & Rumbaugh, J. El Lenguaje Unificado de Modelado. Manual de Referencia. Jacobson, I., Booch, G., & Rumbaugh, J. El Proceso Unificado de Desarrollo de Software Lovelle, J. Calidad del Software Presman, R. S. Ingeniería de Software. Un enfoque práctico. Sitio Oficial BPMN. (s.f.). Recuperado el 2010, de Kit, E. Software Testing in the Real World, improving the process.1995.

12 Galin, D.(2003). Software Quality Assurance, From theory to implementation. Información de Contacto Ing. Yeleyne Maure Díaz. Dirección Particular: Calle Simón Reyes, Edif.451C Apto. #7 / Ave. Mártires y Primera Paralela. Repto. La Vigía. Municipio Camagüey, Provincia Camagüey, Cuba. Institución / Departamento: Universidad de las Ciencias Informáticas / Dirección Técnica de Producción, Grupo de Soporte al Desarrollo. Dirección Institución: Carretera San Antonio de los Baños Km 2½ Torrens, Municipio La Lisa, Provincia La Habana, Cuba. Dirección de Correo Electrónico: yeleyne@gmail.com