Introducción
La Ingeniería del Software (IS) es una disciplina de gran importancia que se fundamenta principalmente en el desarrollo de software. Está conformada por un conjunto de herramientas que son utilizadas para el desarrollo de proyectos y que se interesa en cada uno de los aspectos del software, es decir en aspectos de producción, en las etapas de especificaciones del sistema, la calidad, la facilidad del mantenimiento y así como en la eficiencia del software producido.
La ingeniería del software se enfoca en el diseño y desarrollo de productos de software por lo que se la ha considerado como una disciplina tecnológica de la que es encargada de la producción, el mantenimiento y del uso del mismo software, para que luego este sea modificado dentro de lo que sería un presupuesto definido.
En este artículo presentamos las tendencias de la calidad del software que son procesos o actividades muy importantes que nos ayudaran a detectar fallas o errores y de tal manera podamos lograr mejorar la calidad de los proyectos de software que son generados mediante el desarrollo y modificación del software.
La calidad del software no solo consta en que se apliquen métodos, técnicas o pruebas de verificación para que el proyecto esté exento de posibles errores que puedan presentarse en el trascurso de su ejecución del mismo software, sino que se construya un producto de software de alta calidad, que sea fiable y que funcionen eficientemente cumpliendo las necesidades que el cliente requiera y sin ningún problema. La alta calidad del software o del producto del software, implica la excelencia y se puede lograr con la realización de fases de pruebas independientes o pruebas de verificación y validación que es un proceso de revisión para que nuestro software esté totalmente libre de errores y tenga un adecuado funcionamiento.
Desde un punto de vista de desarrollo de software, se debe tener en cuenta que los errores aparecen cuando el software es incompleto o incorrecto y que antes de que este sea entregado, se deben realizar pruebas o técnicas para el control de calidad del mismo, donde están llevaran a cabo la localización y descubrimiento de dichos problemas o errores para que sean solucionados a tiempo y que el sistema pueda manejarse sin ningún problema.
En las siguientes secciones de este artículo se analizan los siguientes temas como; los aspectos de calidad, el control de calidad, el aseguramiento de la calidad del software, la independencia gerencial, pruebas del sistema, pruebas de integración, pruebas de aceptación, los análisis estáticos, los recorridos e inspecciones y los modelos de calidad. Temas interesantes y de gran importancia al momento de aplicarlos, los mismos que nos ayudaran a mejorar la calidad de nuestro producto de software y logar el objetivo que se pretende alcanzar.
Contenido
1. Aspectos de calidad
Según Schach, (2006), Define que "La calidad del software es el grado o medidas en que el producto cumple con sus especificaciones. Sin embargo, no es suficiente. Por ejemplo, para garantizar que un producto se pueda mantener con facilidad, este debe estar bien diseñado y meticulosamente codificado. Por lo tanto, es necesario que el software tenga alta calidad, pero de ninguna manera es suficiente".
La tarea de cada profesional de software es garantizar software de alta calidad en todo momento. Es decir, cada individuo de desarrollo y mantenimiento es personalmente responsable de verificar que su trabajo sea correcto. La calidad no es algo que añada después el grupo de aseguramiento de calidad de software (SQA, por sus siglas en inglés), sino más bien debe ser construida por los desarrolladores desde el principio.
Una función del grupo de SQA es garantizar que los desarrolladores estén haciendo en realidad trabajo de alta calidad. El grupo de SQA tiene otras responsabilidades también, como se describe en la siguiente sección.
2. Aseguramiento de calidad del software
Schach, (2006), explica "Como ya se mencionó, un aspecto de la función del grupo SQA es probar que el producto de los desarrolladores sea correcto. Más específicamente, una vez que los desarrolladores han terminado un flujo de trabajo y han revisado con cuidado su trabajo, los integrantes del grupo SQA tienen que garantizar que el flujo de trabajo en realidad se haya llevado a cabo en forma correcta".
Asimismo, cuando el producto está completo y los desarrolladores están seguros de que el producto en su totalidad es correcto, el grupo SQA tiene que asegurarse de que así es. No obstante, el aseguramiento de la calidad del software va más allá de solo probar al final de un flujo de trabajo o al termino del proceso de desarrollo: SQA se enfoca en el propio proceso de software. En resumen la función del grupo SQA es garantizar la calidad de proceso de programación y con ello la calidad del producto.
Según Fairley, (1983) indica "La preparación de un plan de control de calidad del software para cada proyecto de software es una de las principales responsabilidades del grupo de control de calidad del software. Entre los temas que debe tocar el plan de control de calidad del software se encuentran":
1.- Documentos referidos en el plan.
2.- Estructura organizacional, tareas que se realizaran y responsabilidades específicas relacionadas con la calidad del producto.
3.- Documentos que se deben preparar y revisiones que deben efectuarse para la adecuación de la documentación.
4.- Estándares, prácticas y convecciones que se utilizaran.
5.- Revisiones y auditorias que deben llevarse a cabo.
6.- Un plan de administración de la configuración que identifique los elementos del producto del software, controle e implante los cambios que se registre e informe de los estados modificados.
7.- Prácticas y procedimientos que se deben seguir para informar, rastrear y resolver los problemas del software.
8.- Herramientas y técnicas específicas que se usaran para apoyar las actividades de control de calidad.
9.- Métodos y facilidades que se emplearan para mantener y almacenar las versiones controladas del software identificado.
10. Métodos y facilidades que servirán para proteger los medios físicos programa de computadora.
11.- Suministros para garantizar la calidad del software proporcionado por vendedores y desarrollado por subcontratistas.
12.- Métodos y facilidades que se usaran para reunir, mantener y conservar los registros de control de calidad.
Otras tareas desarrolladas por el personal de control de calidad son:
1.- Desarrollo de políticas, prácticas y procedimientos estándar.
2.- Desarrollo de herramientas de prueba y otros auxiliares para el control de calidad.
3.- Ejecución de las funciones de control de calidad descritas en el plan de control de calidad del software para cada proyecto.
4.- Ejecución y documentación de las pruebas de aceptación del producto final para cada producto de software.
3. Control de calidad
Para Fairley, (1983), afirma "El control de calidad es un modelo planeado y sistemático de todas las acciones necesarias para proporcionar la confianza de que el articulo o producto se ajusta a los requisitos técnicos establecidos".
El propósito de un grupo de control de calidad de software es proporcionar la garantía de que los procedimientos, las herramientas y las técnicas utilizadas durante el desarrollo y la modificación del producto son adecuados para alcanzar el nivel de confianza deseado en los productos de trabajos.
Por lo tanto el control de calidad deberá proporcionar las técnicas adecuadas para la modificación del software y por consiguiente alcanzar un alto nivel de sostenibilidad y confianza en los productos de software (Fairley, 1983).
4. TÉCNICAS DE CONTROL DE CALIDAD
Según Bruegge y Dutoit, (2002), definen "Hay muchas técnicas para incrementar la confiabilidad de un sistema de software. Las técnicas para evitar defectos tratan de detectar errores en forma estadística; esto es, sin apoyarse en la ejecución de ninguno de los modelos del sistema, en particular el modelo de código".
Las técnicas para la detección de defectos, como la depuración y las pruebas, son experimentos no controlados y controlados, respectivamente, que se usan durante el proceso de desarrollo para identificar errores y encontrar los defectos subyacentes antes de lanzarse el sistema.
De tal manera, las técnicas detectan errores o defectos en el programa de software y estas mismas técnicas ayudan a tolerar dichos errores. Esto se lleva a cabo con el objetivo con la finalidad de corregir y solucionar la cantidad de defectos descubiertos y así aumentar la confianza en el software.
5. INDEPENDENCIA GERENCIAL
Para Schach, (2006), afirma "Es importante que exista la independencia gerencial entre equipos de desarrollo y el grupo de SQA. Es decir, el desarrollo debe estar bajo un gerente, el SQA bajo un gerente distinto, y ningún gerente debe pasar por alto al otro. El motivo es que, con demasiada frecuencia se encuentran defectos graves en un producto cuando se aproxima la fecha límite de la entrega".
La empresa de software ahora debe elegir entre dos opciones no satisfactorias. Puede liberar el producto a tiempo, pero lleno de fallas, dejando que el cliente batalle con el software. La decisión de entregar software con fallas a tiempo no debe tomarla el gerente responsable de desarrollo, tampoco el gerente de SQA podrá tomar la decisión de llevar a cabo más pruebas y entregar tarde el producto. Es mejor que ambos reporten a un gerente señor mas, quien puede decidir la opción que mejor le convenga a los intereses de la organización de desarrollo de software y al cliente.
6. ANÁLISIS ESTÁTICOS
Por su parte Fairley, (1983) Indica "El análisis estático es una técnica para valorar las características estructurales del código fuente o cualquier representación notacional que se apegue a reglas sintácticas bien definidas".
El presente estudio se restringe al análisis estático del código fuente. En este análisis se examina la estructura del código, pero el código no se ejecuta. Puesto que el análisis estático se relaciona con la estructura de los programas, es especialmente útil para descubrir prácticas de codificación cuestionables y apartamiento de los estándares de codificación, además de detectar errores estructurales como variables no inicializadas y discrepancias entre parámetros reales y formales.
Por consiguiente el análisis estático se derivan las técnicas de recorrido y de inspección de las cuales son muy útiles y fundamentales al aplicarlos en un producto de software (Fairley, 1983).
7. RECORRIDOS E INSPECCIONES
Con referencia Fairley, (1983), expresa "Los recorridos e inspecciones se pueden utilizar para examinar en forma metódica los productos de trabajo a través del ciclo de vida de sistema. Los requisitos las especificaciones del diseño, los planes de prueba, el código fuente, los principios de operación, los manuales del usuario, y los procedimientos para el mantenimiento son algunos de los elementos que se pueden revisar de esta manera".
Un recorrido no es una revisión del proyecto, sino, más bien, es un examen profundo de productos de trabajo seleccionados por individuos calificados para ofrecer opiniones expertas. Las inspecciones difieren de los recorridos en que un grupo de inspectores entrenados realizan inspecciones de los productos de trabajo. Los recorridos y las inspecciones se analizan por turno.
RECORRIDOS
Un equipo de recorrido, por lo normal, consta de una persona revisada y tres o cinco revisores. En proyectos de una o dos personas pueden no costear formas un equipo de revisión; sin embargo, la técnica de recorrido suele ser benéfica con solo uno o dos revisores. En este caso un recorrido formaliza el proceso de explicar el trabajo a un colega.
El objetivo de un recorrido es descubrir y resaltar las áreas problema. Los problemas no se resuelven durante la sesión de recorrido; lo soluciona la persona revisada después de la sesión. La persona revisada puede trabajar con uno o más revisores para resolver los problemas, pero es responsabilidad del revisado asegurar que los problemas encontrados durante el recorrido sean resueltos.
INSPECCIONES
Las inspecciones, como los recorridos, se pueden usar a lo largo del ciclo de vida del software para evaluar y mejorar la calidad de los diversos productos de trabajo. Los grupos de inspección constan de uno a cuatro miembros, quienes están preparados para su tarea. Los inspectores trabajan a partir de listas de revisión de elementos de inspección. Las inspecciones se realizan de manera similar a los recorridos, pero en aquellas existe una estructura mejor durante las sesiones, además, cada participante tiene un papel definido.
Las inspecciones y los recorridos son, en particular, valiosas para sistemas de tiempo real, donde la depuración de las secuencias de ejecución es difícil debido a la no repetividad de las situaciones de error.
Un aspecto es interesante de las inspecciones es la observación de que distintos programadores tienden a cometer diferentes clases de errores característicos. Los errores encontrados durante la inspección se pueden ciclar de regreso a los programadores que los hicieron, con esta retroalimentación, los programadores tienden a eliminar esos tipos de error de su trabajo posterior, mejorándose así la calidad y la productividad.
En efecto tanto las inspecciones como los recorridos son utilizables ayudan a mejorar el software, por consiguiente es muy recomendable el uso de los recorridos y de las inspecciones.
8. UN PANORAMA DE LAS PRUEBAS
Por su parte Bruegge y Dutoit, (2002), explican "La confiabilidad es una medida del éxito con que el comportamiento de un sistema se apega a la especificación de su comportamiento".
La confiabilidad del software es la probabilidad de que un sistema de software no causara la falla del sistema durante un tiempo especificado bajo condiciones especificadas".
9. TÉCNICAS PARA EVITAR DEFECTOS
Con referencia Bruegge y Dutoit, (2002) definen "La evitación de defectos trata de impedir la ocurrencia de errores y fallas encontrando defectos en el sistema antes de lanzarlo. Las técnicas para evitar defectos incluyen":
Desarrollo de metodologías
Administración de la configuración
Técnicas de verificación
Revisiones
El desarrollo de metodologías evita los defectos proporcionando técnicas que minimizan la introducción de defectos en los modelos del sistema y en el código. Tales técnicas incluyen la representación, sin ambigüedades, de los requerimientos, el uso de abstracción y encapsulamiento de datos, la minimización del acoplamiento entre subsistemas y la maximización de la coherencia entre subsistemas, la definición temprana de las interfaces de subsistemas y la captura de la información de las razones para las actividades de mantenimiento.
La administración de la configuración puede asegurar que si los modelos de análisis y el código se están volviendo inconsistentes entre si se les notificara a los analistas e implementadores. La suposición que hay tras la administración de la configuración es que el sistema contiene mucho menos defectos si se controla el cambio.
La verificación trata de encontrar defectos antes de cualquier ejecución del sistema. Sin embargo, la verificación tiene sus límites. No está en un estado bastante maduro como para que pueda aplicarse para asegurar la calidad de grandes sistemas complejos.
10. MODELOS DE CALIDAD
Según Schach, (2006), asegura "Un modelo de calidad puede definirse como el conjunto de factores de calidad, y de relaciones entre ellos, que proporciona una base para la especificación de requisitos de calidad y para la evaluación de la calidad de los componentes de software".
Por consiguiente los modelos de calidad son aplicables en diferentes actividades, como establecer requisitos de calidad, evaluar la calidad de un componente, comparar la calidad de distintos componentes y redactar contratos formales en donde estará definidas y detalladas cada una de las evaluaciones de calidad de los componentes (Schach, 2006).
Tipos de modelos de calidad
Las propuestas existentes de modelos de calidad se pueden clasificar según si tienen un enfoque de modelos de calidad fijos, a medida o mixtos.
En los modelos de calidad fijos existe un catálogo de factores de calidad de partida que se usa como base para la evaluación de la calidad. Este enfoque supone que el modelo de calidad contiene todos los factores de calidad posibles.
En los modelos de calidad a medida no existe ningún catálogo de factores de partida, y dichos factores deben ser identificados para cada proyecto. La idea que guía la construcción de estos modelos es que debe partir la identificación de los objetivos a alcanzar. Dichos objetivos serían los factores más abstractos que deben descomponerse en factores más concretos hasta llegar hacer operativos los objetivos, de forma que pueda ser medida su consecución.
Los modelos de calidad mixtos se intentan combinar las ventajas de los dos tipos anteriores de modelos. La idea es que exista un conjunto de factores de calidad más abstractos que sean reutilizados en virtualmente todos los proyectos posibles.
Los tipos de modelos de calidad tienen enfoques de calidad para lograr el mejoramiento de la calidad del software y que el mismo sea eficiente en todos sus aspectos.
Conclusiones
Es muy importante y trascendente la verificación de la calidad del software, ya que es un punto fundamental porque así podemos detectar y encontrar errores que pueden estar presentes en el proyecto y que estos mismos problemas sean y sean resueltos o solucionados mediante técnicas, logrando así tener un mejor desempeño y una mejor ejecución del software y que sobre todo y principalmente que cumpla adecuadamente los requerimientos y necesidades del cliente.
Aplicar los modelos de calidad del software no solo nos proporciona el sostenimiento de la calidad del software, sino que también se encargan de mejorar la calidad de los productos de software, haciéndolos que sean eficaces, productibles y de alta calidad.
Las técnicas de control de calidad incrementan la confiabilidad y mejoran calidad del software una vez que los desarrolladores emplean las necesidades que cada usuario requiere, ya que estos presentan seguridad aplicando la solución de los problemas asignados.
Referencias bibliográficas
Bibliografía
Bruegge, B., & Dutoit, A. (2002). Ingenieria del Software Orientado a Objetos. Mexico: Pearson Educacion.
Fairley, R. (1983). Ingeniería de software. México: McGraw-Hill.
Juan Pablo Carvallo, X. F. (s.f.). CALIDAD DE COMPONENTES SOFTWARE. Obtenido de http://www.essi.upc.edu/~franch/papers/libro-calidad-cap-10-jpc-xf-cq-10-version-preliminar.pdf
Schach, S. R. (2006). Ingeniería de software clásica y orientada a objetos. México: McGraw-Hill.
Referencias
Bruegge, B., & Dutoit, A. (2002). Ingenieria del Software Orientado a Objetos. Mexico: Pearson Educacion.
Fairley, R. (1983). Ingeniería de software. México: McGraw-Hill.
Juan Pablo Carvallo, X. F. (s.f.). CALIDAD DE COMPONENTES SOFTWARE. Obtenido de http://www.essi.upc.edu/~franch/papers/libro-calidad-cap-10-jpc-xf-cq-10-version-preliminar.pdf
Schach, S. R. (2006). Ingeniería de software clásica y orientada a objetos. México: McGraw-Hill.
Autor:
Evelyn Melissa Zambrano Choez.
Ingeniera en formación del Sexto Semestre de la Carrera de Ingeniería en Computación y Redes, Facultad de Ciencias Técnicas, Materia Redes Conmutadas. Universidad Estatal del Sur de Manabí. Ecuador.