Las Inspecciones de Software y las Listas de Comprobación (página 2)

– La carencia de un mecanismo propio para el control de versiones.

– No existe un grupo dedicado a la atención al cliente, de forma que no sean los desarrolladores quienes atiendan las solicitudes o preguntas de los clientes que no están relacionadas con ellos.

El proceso de software que garantice la calidad adecuada para cualquier institución, se define de la siguiente manera:

"Es un conjunto de actividades, métodos, prácticas y transformaciones que las personas usan para desarrollar y mantener software y sus productos asociados" [1] [12].

Cuando una empresa que desarrolla software crece, necesita ampliar su organización, para esto, algunas veces, utilizará un modelo establecido internacionalmente para llevar a cabo las actividades o funciones que le permitan cumplir sus metas y objetivos con una buena calidad hacia los clientes o usuarios. Dentro de este modelo de proceso existe un Plan de Aseguramiento de Calidad y se define como un conjunto de personas que están encargadas de llevar el seguimiento, al modelo de proceso de desarrollo, dentro de la empresa. Este plan y las personas que están a su cargo son muy importantes para la empresa.

Lastimosamente, la mayoría de las empresas de software hoy en día no establecen normas, ni objetivos, ni metas, ni políticas adecuadas para lograr que los productos elaborados cumplan; primero, normas internacionales para llevar a cabo el mantenimiento o para la exportación; segundo, la organización mejore incrementalmente su conocimiento y el dominio completo, entre los desarrolladores, sobre el proceso de software; tercero, la tecnología utilizada sea explotada al máximo; y cuarto, se tenga un grupo de personas que continuamente mejoren el proceso y velen por la calidad en la vida del proyecto.

Por estas razones, han surgido modelos del proceso de software, que se explican brevemente a continuación. Estos modelos se utilizan en el desarrollo de proyectos de software. Cada uno de estos establece la madurez por niveles que va incrementándose a medida que la empresa va cumpliendo los requisitos de entrega en tiempo de los proyectos, mejore la capacidad de administración, alcance un conocimiento continuo entre los desarrolladores actuales y nuevos sobre el proceso de software, se garantice que las actividades internas correspondan a procesos planificados, sean usables y consistentes las actividades, los procesos se actualicen y mejoren, existan pruebas pilotos, se realice un análisis de costo y beneficio para el cliente, y los roles y responsabilidades estén claros en los procesos y en la organización.

– El Conjunto de estándares ISO-15504 SPICE (Software Process Improvement and Capability Determination). Desarrollado por el WG10 de la ISO (Internacional Organization for Standardization) [59].

– ISO 9000 – 9001. La Organización Internacional para la Estandarización, mejor conocida como ISO, promueve la estandarización internacional, de tal manera que se facilite el intercambio de bienes y servicios así como el desarrollo científico y tecnológico mediante el comité técnico TC176, encargado de la normalización del Aseguramiento y Administración de la Calidad. ISO 9000-3 es una guía y no una norma, que describe los elementos de un sistema de calidad orientado al software [60].

– Tick-It. Es una iniciativa de la industria del Reino Unido, que consiste en un esquema de certificación basado en la norma ISO 9000, guía ISO9000-3. Pone énfasis especial en la experiencia y en la capacitación que deben tener los auditores calificados, tanto en el área de desarrollo de software como en la evaluación de los criterios específicos de la norma. Tick-It es un esquema más riguroso que ISO 9000 [61].

– El Modelo de Madurez de la Capacidad (CMM: Capability Maturity Model). Desarrollado por el Instituto de Ingeniería de Software (SEI) de la Universidad Carnegie – Mellon en USA. Se basa en cinco niveles de madurez de las empresas que producen software, los niveles se enfocan en los procesos de desarrollo, capacidad de los procesos y su desempeño. [56]

– El Modelo de Madurez de Capacidad Integrado (CMMI: Capabily Maturity Model Integration). El Proyecto CMMI es un esfuerzo cooperativo del Departamento de Defensa de los Estados Unidos y el Instituto de Ingeniería de Software (SEI). El propósito del proyecto es proveer mejoras en costo, cumplimiento de cronogramas y calidad de los proyectos eliminando la complejidad de múltiples modelos de CMM. [50] [54]

Ya que el trabajo esta dirigido para la introducción en las empresas de los modelos CMM o CMMI, se explica brevemente; las diferencias entres estos dos modelos para luego señalar los niveles de madurez. También, durante el trabajo, se comprende como juega un papel importante las Inspecciones de Software con las Listas de Comprobación en los distintos niveles de madurez para los dos modelos. Hay que señalar, "que la aplicabilidad de los modelos para la mejora de procesos depende de la situación y del tipo de cada organización, ya que los programas de mejora deben estar basados en la misión y los objetivos del negocio que tenga cada organización." [52]

La introducción de un modelo de mejora es necesario en la empresa, ya que uno de los requisitos a nivel internacional para ser subcontratado y desarrollar software, es estar en el nivel 3 o nivel 2 de CMM o CMMI, o tener una certificación ISO, por esta razón la India ha tenido un gran auge en este sentido.

CARACTERÍSTICAS DE MODELO DE CAPACIDAD DE MADUREZ (CAPABILITY MATURITY MODEL – CMM)

CMM persigue la evaluación de los procesos de desarrollo de software dentro de una organización proponiendo un plan de mejoramiento en base a una serie de niveles que van desde un proceso inmaduro hasta un proceso disciplinado, ordenado y de mejoramiento continuo.

La madurez de un proceso de software, determina en que grado un proceso de software es explícitamente definido, administrado, medido, controlado y hecho efectivo. La madurez es un indicador de la capacidad del proceso de software para lograr sus objetivos y resultados esperados [57].

Una Empresa logra mayor madurez mediante la institucionalización del proceso de desarrollo de software, estableciendo las políticas, estándares y estructuras organizativas.

CMM esta conformado por niveles de madurez, que indican la capacidad del proceso. Los niveles, contienen áreas claves de proceso (PKS), con la ayuda de ellas se alcanza los objetivos. Las áreas están organizadas con características comunes, que se aplican a la implementación o institucionalización. Las características comunes entre las áreas contienen prácticas claves, que describen la infraestructura o las actividades. [5][56]

Nivel 1 (Inicial):

No hay proceso definido para el proceso de Software.

Nivel 2 (Repetible).

Gestión del proceso de software: coste, planificación y funcionalidad, sigue un conjunto de áreas.

– Administración de Requisitos.

– Planificación de Proyectos de Software

– Seguimiento y supervisión de Proyectos de Software

– Administración de Subcontratos de Software

– Aseguramiento de Calidad de Software (SQA)

– Gestión de Configuración del Software

Nivel 3 (Definido).

Desarrollo y Mantenimiento documentado y Estandarizado. Definido, los procesos son estándares en toda la empresa y se valida si éstos son los adecuados. El conjunto de áreas es el siguiente:

– Enfoque del Proceso de la Organización

– Definición del Proceso de la Organización

– Programa de Formación

– Gestión de Integración del Software

– Ingeniería del Producto de Software

– Coordinación entre grupos

– Revisiones periódicas.

Nivel 4 (Gestionado).

Medidas del Producto y del Proceso. Registro de valores de Calidad. Administración, se establecen métricas de cada una de las partes del proceso y se analizan sus resultados. Las áreas son las siguientes:

– Gestión cuantitativa del Proceso

– Gestión de Calidad del Software

Nivel 5 (Optimizado).

Resultados cuantificados, con opción de mejora

Los procesos se optimizan continuamente y se definen estándares. Las áreas son las siguientes:

– Prevención de Defectos

– Gestión de la Tecnología

– Gestión de Cambios en el Proceso

El modelo CMM ofrece una estrategia para mejorar el proceso, junto con un marco para evaluar empresas. Mejorar el proceso es establecer un rango de calidad, es una medida para otros de cómo es llevado el proceso de Software, de esta forma, durante el avance entre los niveles se va robusteciendo la fabricación de software.

CARACTERISTICAS DEL MODELO DE CAPACIDAD DE MADUREZ INTEGRADO (CAPABILITY MATURITY MODEL INTEGRATION – CMMI)

En Diciembre del 2001, el Instituto de Ingeniería de Software (SEI) lanzo la versión 1.1 del CMMI es una nueva versión de CMM. CMMI es un modelo de Procesos, o una colección estructurada de componentes que describen las características de los procesos efectivos de software que han sido probados por la experiencia.

También, esta dividido por Áreas de Proceso como CMM, cada área está compuesta por metas, cada una de estas metas está conformada por prácticas. Las metas y las prácticas son específicas o genéricas. Las prácticas corresponden a una sola Área de Proceso, mientras que las áreas específicas van a través de todas las áreas de proceso.

Las metas y prácticas genéricas, tienen elaboraciones que las inician para cada área de proceso.

Las metas específicas se aplican a solo un área de proceso, mientras que las metas genéricas se aplican a más de un área de proceso. Una práctica específica es una actividad considerada importante para alcanzar una meta específica. Las prácticas genéricas son prácticas que se aplican a cualquier área de proceso, y que pueden mejorar el desempeño y control de cualquier proceso.

Existen dos representaciones para este Modelo: por etapas (Staged) [62] y continua (Continuous) [63]. La representación continua es claramente más flexible en cuanto a que permite formar una estrategia de mejora que se adapte a las metas globales de la respectiva organización. La representación por etapas, en contraste, es el modelo preferido por organizaciones que quieren migrar más fácilmente de CMM a CMMI.

Los niveles de CMMI a CMM tienen la misma definición. Nivel 1 (Inicial):

No hay proceso definido para el proceso de Software.

Nivel 2 (Administrado):

– Administración de Requisitos.

– Planificación de Proyecto.

– Monitoreo y Control del Proyecto.

– Administración del Acuerdo del Proveedor.

– Medición y Análisis.

– Aseguramiento de Calidad del Proceso y el Producto.

– Administración de Configuración.

Nivel 3 (Definido)

– Desarrollo de Requisitos.

– Solución Técnica.

– Integración del Producto.

– Verificación.

– Validación.

– Enfoque del Proceso Organizativo.

– Definición del Proceso Organizativo.

– Entrenamiento Organizativo.

– Administración integrada del Proyecto.

– Administración de Riesgos

– Análisis de Decisiones y Resolución.

– Ambiente Organizativo para la Integración [62].

– Equipo Integrado [62].

Nivel 4 (Administrado Cuantitativamente):

– Desempeño Funcionamiento del Proceso Organizativo.

– Administración Cuantitativa del Proyecto

Nivel 5 (Optimizado):

– Innovación y Despliegue Organizativo.

– Análisis de Causas y Resolución

Cada uno, CMM y CMMI, establece un punto de partida para encontrar las soluciones a los requisitos y problemas que pueda tener una empresa de desarrollo software, logrando con estos modelos a cumplir con sus metas y objetivos hacia el cliente.

Sin embargo, de estos modelos descritos anteriormente en un artículo publicado en Fortune se dice: [2]

"Un estudio más reciente del Standish Group hecho sobre 352 compañías de software, donde se estudiaron más de 8.000 proyectos de software, revelaron lo siguiente:

· El 31% de todos los proyectos de software fueron cancelados antes de terminarse

($81 billones de dólares norteamericanos perdidos).

· El 53% de los proyectos tuvieron un costo 189% mayor de lo estimado.

· El 9% de los proyectos se terminaron a tiempo y dentro del presupuesto (compañías grandes).

· El 16% de los proyectos se terminaron a tiempo y dentro del presupuesto (compañías pequeñas).

A raíz de estos datos, se les preguntó a las empresas sobre las causas de estos problemas. Las tres principales razones expuestas fueron las siguientes:

· Falta de información por parte de los usuarios (12.8%)

· Especificaciones y requisitos incompletos (12.3%)

· Cambios en las especificaciones y requisitos (11.8%)

Este estudio muestra que los defectos cometidos durante la fase de requisitos son extremadamente caros de reparar. En proyectos grandes, este tipo de defectos son muy frecuente. En el estudio de un proyecto de la fuerza aérea de USA, los defectos fueron clasificados según la fuente de donde provenían. Se encontró que los defectos de la etapa de requisitos comprendían el 41% del total de defectos, mientras que los defectos en la lógica del diseño comprendían solamente el 28% del total [2].

El problema radica en el Proceso de Desarrollo del Software, ya que no existe un método para la detección de defectos, que es la parte esencial para el inicio de la mejora continua en el proceso de desarrollo. La Inspección con las Listas de Comprobación es necesaria para iniciar la mejora en el proceso de desarrollo, la cual, es una herramienta alternativa, haciendo que se detecten, la mayoría de los defectos a tiempo. Además, sin realizar una planificación y seguimiento para llevar a cabo esta actividad no es posible sistematizarla.

Por tanto, el objetivo general será: Permitir que el Grupo de Aseguramiento de Calidad obtenga un modelo de Inspección de Software que ayude a controlar la calidad durante el proceso de software, a través de una herramienta automatizada que usa las listas de comprobación.

Teniendo como objetivos específicos los siguientes:

– Establecer un modelo de inspección de software de acuerdo a la realidad que nos rodea.

– Establecer una clasificación de las listas de comprobación de acuerdo a las fases de un proyecto y estándares internacionales.

– Proponer pasos para las inspecciones de Software, haciendo uso de las listas de comprobación.

– Desarrollar una aplicación automatizada que refleje el modelo de inspección de software a establecer. El cual debe ser capaz y tener las siguientes facilidades:

o Ayudar al Grupo de Aseguramiento de Calidad a elaborar el Plan de Inspección.

o Registrar los resultados del Grupo de Aseguramiento de Calidad por cada uno de los proyectos desarrollados.

o Registrar los grupos que llevan a cabo la inspección.

o Ayudar a los programadores, a los usuarios, administradores de proyecto, al equipo de inspección y a los especialistas en una determinada área y fase de desarrollo, a detectar los defectos.

o Ayudar a elaborar los grupos de inspección.

o Registrar las Listas de Comprobación para cada uno de los proyectos y dar alternativas para la creación de nuevas listas.

o Capturar los defectos encontrados durante la ejecución de las inspecciones realizadas en los distintos niveles de desarrollo, para ayudar a prevenir los posibles defectos y mejorar el proceso de inspección.

La hipótesis para el presente trabajo será:

Con las listas de comprobación se puede ayudar a realizar el proceso de Inspección de Software de forma objetiva.

Para cumplir los objetivos y responder a la hipótesis que el autor plantea, se realizaron las siguientes tareas en forma cronológica en tiempo de la siguiente forma:

– Se realizó un estudio del estado actual de las Listas de Comprobación. Para este fin, fue hecha una búsqueda exhaustiva en Internet y en libros relacionados con el desarrollo de software, reflejada en la bibliografía.

– Se estudió los distintos modelos utilizados hoy en día para realizar el proceso de inspección de Software. Para este fin, se realizó una búsqueda y selección de sitios en Internet y lecturas relacionadas con las inspecciones de software.

– Se estudió como participa las inspecciones de software junto con los modelos de: "Modelo de Madurez de Capacidad" [56] y el "Modelo de Madurez de Capacidad Integrado" [62] [63]. Este estudio sirvió para la búsqueda de las Listas de Comprobación adecuadas para el Proceso de Software.

– Se revisó normas ISO para el ciclo de vida del software, estableciendo una nueva clasificación de las listas de comprobación.

– Se estableció un modelo de inspección de software de acuerdo a la situación actual de tiene el país, utilizando el análisis y reflexión de los distintos modelos que se practican en el mundo sobre las inspecciones de software.

– Se ha clasificado las listas de comprobación de acuerdo a los distintos procesos y propiedades que tiene el desarrollo de software.

– Se ha definido una arquitectura de software para la aplicación que ha automatizado el proceso de inspección de software propuesto.

– Se ha logro obtener un conocimiento aceptable sobre la plataforma de desarrollo Visual Studio .Net de Microsoft.

– Se realizó una validación del uso de las listas de comprobación y el modelo de inspección en la Universidad de Ciencias Informáticas y dentro del Centro de Referencia de Ingeniería de Sistemas.

Se realizo un sitio Web, para la preparación de los participantes en el modelo establecido en el presente trabajo sobre las inspecciones de software.

CAPITULO 1

LA CALIDAD Y LAS INSPECCIONES DE SOFTWARE

1.1 INTRODUCCIÓN

En el presente capitulo se presenta una breve introducción a los conceptos, metas y objetivos del aseguramiento de calidad de software, definiendo también, las características que debe tomarse en cuenta para satisfacer los distintos atributos de calidad descritos en el capitulo. Estos atributos, serán rastreados durante el desarrollo proyecto de software para lograr una mejora en el proceso de software.

También, se presenta una introducción a las inspecciones de software, presentando los objetivos que deben lograse al aplicar este proceso. Conjuntamente se presenta, una vista de los distintos modelos mas utilizados internacionalmente para las inspecciones de software. Se explica los objetivos de las listas de comprobación y como ayudan con el proceso de inspección; se aclara, que con las inspecciones de software se logra la detección de los defectos en un artefacto desde el inicio del proyecto de software hasta el final, por este motivo, se presenta una posible clasificación de los defectos que se pueden encontrar, hecha por José Javier Dolado Cosín [10], para culminar se realiza una explicación de las reglas que deben tomarse en cuenta al aplicar las listas de comprobación y como dar una la valoración de una lista.

Para culminar con el capitulo, se presenta un resumen de las métricas de inspección de software y el software existente en el mercado que automatiza el proceso de inspección de software.

Este capitulo dará una idea general de la importancia de las inspecciones de software en cualquier empresa desarrolladora de software.

1.2 ASEGURAMIENTO DE LA CALIDAD DE SOFTWARE (SOFTWARE QUALITY ASSURANCE – SQA)

El aseguramiento de Calidad es una actividad, para toda empresa que desarrolla software y debe llevarla a cabo de una manera limpia y correcta. Es un proceso de la ingeniería de software, que se define como un "conjunto de acciones planificadas y sistemáticas que son necesarias para proporcionar la confianza adecuada en que un producto o servicio cumpla con los requisitos dados sobre la calidad" [46]. La medición y las métricas son un punto muy importante en todo el proceso de software, como también, el aseguramiento de calidad que se retroalimenta con los resultados de las métricas. La obtención de software con buena calidad implica la utilización de: un modelo de proceso, una metodología de desarrollo, que ayude a cumplir estrictamente el modelo de proceso seleccionado, estos procesos son entre otros: procesos determinación de requisitos, diseño, implementación y prueba, que permiten estandarizar el conocimiento del trabajo, para lograr una calificación adecuada en los "atributos de calidad descritos por McCall" [13], políticas de control para todas las fases de desarrollo y un proceso de medición para el proceso de software.

El Aseguramiento de Calidad de Software engloba los siguientes puntos:

– El mejoramiento de los métodos, técnicas de análisis, diseño, codificación y prueba [6].

– "Revisiones técnicas formales que se aplican durante cada fase del proceso de desarrollo de software" [6], que ayudan a detectar los defectos.

– "Utilización de estándares" [47] durante el desarrollo.

– "Sistema de Métricas" [47], para la retroalimentación de todas las personas

– Definir estrategias de prueba multiescala [6];

– Control de la documentación del software y de los cambios realizados [6];

– Un procedimiento que asegure, siempre que sea posible, un ajuste a los estándares de desarrollo del software. [6]

En el caso de la IEEE 1074, "este estándar explica como el aseguramiento de calidad de software debe apoyarse o relacionarse estrechamente son las siguientes actividades:

– Verificación: Básicamente revisiones y auditorias de configuración y calidad.

– Validación: Todos los niveles y fases de prueba de ejecución de software.

– Gestión de Configuración: Como medio de control de los productos generados.

– Medición de software: Contempla la necesidad de marcar objetivos y asociar métricas a los objetivos. [46]"

La actividad del SQA, en empresas grandes, será llevada por un grupo disciplinado, que deben seguir objetivos y metas, que se describen en los epígrafes siguientes.

1.2.1 OBJETIVOS DEL SQA

Entre los objetivos que persigue el SQA [55], para delimitar su campo de acción y no confundir con otras actividades se definen los siguientes:

– El SQA consiste en la revisión de los productos y su documentación relacionada, para verificar su contenido, corrección, confiabilidad y facilidad de mantenimiento.

– La garantía de que un sistema cumpla las especificaciones y los requisitos funcionales y no funcionales para el desempeño deseado.

– Evitar la necesidad de realizar cambios significativos, una vez que el producto se ha terminado

– Desarrollar software al que sea fácil mejorarlo.

– Garantizar que el proceso se lleve de acuerdo con los estándares establecidos internacionalmente, para ello toma, entre varias herramientas, las Inspecciones, para evaluar, verificar y controlar los proyectos en ejecución, que forma parte de los objetivos de las Revisiones y Técnicas Formales, que "es una actividad del aseguramiento de calidad llevada acabo por los ingenieros del software" [17].

Durante el trabajo, se aclara la función de las Listas de Comprobación y el como contribuyen con los objetivos que persigue el SQA, ya que éstas están incluidas como una herramienta de las Revisiones y Técnicas Formales que contribuyen al cumplimiento de los requisitos.

1.2.2 METAS DEL SQA

El Modelo de Capacidad de Madurez (CMM) y Roger Pressman definen para el SQA las siguientes metas que deben contribuir al mejoramiento del proceso:

– Meta 1: Las actividades de aseguramiento de la calidad del software (SQA) se planifican. [3] [17]

– Meta 2: Se verifica de una manera objetiva la concordancia de los productos de software y de las actividades con los estándares, procedimientos, y requisitos aplicables. [3]

– Meta 3. Se posee la descripción del proceso de software descrito y se actualiza sistemáticamente. [17]

– Meta 4: Se revisan las actividades de ingeniería de software para verificar el ajuste al proceso de software definido. [17]

– Meta 5: Se realizan auditorias de los productos de software designados para verificar el ajuste con los productos definidos como parte del proceso de software. [17]

– Meta 6: Se asegura que las desviaciones del trabajo y los productos del software se documenten y se manejen de acuerdo con un procedimiento establecido. [17]

– Meta 7: Se registra lo que no se ajuste a los requisitos y se informa a sus superiores. [17]

1.2.3 ACTIVIDADES DEL SQA

Según CMM el SQA debe realizar las siguientes actividades [56][58]:

1. Un plan de aseguramiento de la calidad del software es preparado para el proyecto de software siguiendo un procedimiento documentado.

2. Las actividades del Grupo de Aseguramiento de Calidad de Software (GSQA) se realizan de acuerdo al plan de de aseguramiento de calidad.

3. El GSQA participa en la preparación y revisión del plan del proyecto de desarrollo de software, estándares, y procedimientos.

4. El GSQA revisa las actividades de ingeniería de software para verificar su conformidad de cada una de ellas.

5. El GSQA audita los productos del trabajo de software para verificar su conformidad.

6. El GSQA periódicamente reporta el resultado de sus actividades al Grupo de Ingeniería del Software (GIS).

7. Las desviaciones detectadas en las actividades de software y en los productos del trabajo de software son documentadas y manejadas siguiendo un procedimiento documentado.

8. El GSQA conduce revisiones periódicas de sus actividades y hallazgos con el cliente, de la forma más apropiada.

1.3 CALIDAD DE SOFTWARE

El término calidad del software se interpreta de diferentes maneras. Uno de los modelos más difundidos y utilizados de calidad es debido a McCall (1977), "que especifica una serie de atributos, con los cuales es posible tratar de medirla. Sin embargo, existe una visión distinta, es la definición de atributos juntamente con el usuario o asociar la calidad a la ausencia de defectos en el transcurso del desarrollo y vida del software. [10]" Tomar los atributos de calidad de McCall, es comprometerse a realizar un seguimiento durante el transcurso del desarrollo del proyecto de software a estos atributos, además deben estar bien definidos en los requisitos no funcionales y delimitar el limite de cada uno de estos en el diseño de la Arquitectura de Software.

Sin embargo, existen otros dos modelos que tratan, también, de la calidad de software, uno es de Boehm (1978) y de la ISO-9126, con algunas diferencias sobre el modelo de McCall. En la Tabla 1.1 [7] se enumera los distintos atributos y metas de los tres modelos.

EL PRESENTE TEXTO ES SOLO UNA SELECCION DEL TRABAJO ORIGINAL. PARA CONSULTAR LA MONOGRAFIA COMPLETA SELECCIONAR LA OPCION DESCARGAR DEL MENU SUPERIOR.