Está en la página 1de 21

Aplicaciones de Ingeniera de Software

Administracin de la Calidad del Producto de Software

Qu es la gestin de la calidad?

Es una actividad protectora o de sombrilla que se aplica a lo largo del proceso de software. Con frecuencia es llamada garanta de la calidad de software

La gestin de la calidad abarca


Un proceso de garanta de la calidad del software (Software Quality Assurer/Advisor) Tareas especficas de aseguramiento y control de la calidad (revisiones tcnicas formales y una estrategia de pruebas) Prcticas efectivas de ingeniera de software (mtodos y herramientas)

La gestin de la calidad abarca


Control de todos los productos de trabajo del software y los cambios que generan Un procedimiento para garantizar la concordancia con los estndares de desarrollo del software Mecanismos de medicin e informe

Control de calidad
Involucra la serie de inspecciones, revisiones y pruebas empleadas a lo largo del proceso de software para garantizar que cada producto de trabajo satisfaga los requisitos que se le han asignado.

Garanta de la calidad del software (SQA)


Concordancia con los requisitos funcionales y de desempeo explcitamente establecidos, estndares de desarrollo explcitamente documentados y caractersticas implcitas que se esperan de cualquier software desarrollado profesionalmente.

La gente olvida cun rpido hiciste un trabajo, pero siempre recuerdan cun bien lo hiciste. Howard Newton

Actividades de SQA
Preparar un plan de SQA para un proyecto. Identifica las evaluaciones que se harn, las auditoras y revisiones a llevar a cabo, los estndares aplicables al proyecto, los procedimientos para el informe y el seguimiento de errores, los documentos que debe producir el grupo SQA y la cantidad de retroalimentacin proporcionada al equipo de proyecto.

Actividades de SQA
Participar en el desarrollo de la descripcin del proceso de software del proyecto. El equipo de software selecciona un proceso para el trabajo que habr de realizarse. El grupo de SQA revisa la descripcin del proceso para que concuerde con las polticas organizacionales, los estndares internos de software, los estndares impuestos de manera externa (ISO 9000) y otras partes del plan de proyecto de software.

Actividades de SQA
Revisar las actividades de ingeniera del software para verificar que se ajustan al proceso de software definido. El grupo de SQA identifica, documenta y sigue las desviaciones del proceso y verifica que se hayan hecho las correcciones.

Actividades de SQA
Audita productos de trabajo de software seleccionados para verificar que se ajusten con los definidos como parte del proceso del software. El grupo de SQA revisa los productos de trabajo seleccionados, identifica, documenta y sigue las desviaciones; verifica que se hayan hecho las correcciones; y peridicamente informa de los resultados de su trabajo al gerente del proyecto.

Actividades de SQA
Garantiza que las desviaciones en el trabajo del software y en los productos de trabajo estn documentadas y se manejen de acuerdo con el procedimiento establecido. Las desviaciones se pueden encontrar en el plan del proyecto, en la descripcin del proceso, en los estndares aplicables o en los productos de trabajo tcnicos.

Actividades de SQA
Registra cualquier falta de ajuste y lo informa al gestor ejecutivo. A los seguimientos que no se ajustan se les da seguimiento hasta resolverlos.

Validacin
La validacin se refiere al proceso de evaluacin del software al final de su desarrollo para asegurar que est libre de fallas y cumple con los requisitos. La validacin se lleva a cabo mediante la utilizacin de diversos enfoques de prueba. Tambin se pueden validar productos intermedios como la descripcin de requisitos, esto se hace mediante la utilizacin de un prototipo.

Verificacin
Se refiere al proceso de determinar si los productos de una determinada fase del proceso de desarrollo de software cumplen con los requerimientos establecidos durante la fase previa. Trata de identificar defectos o errores que generen fallas. Una de las tcnicas ms comunes para la verificacin es la revisin tcnica. Por ejemplo, una revisin de especificaciones intenta verificar el modelo del anlisis contra la Especificacin de Requisitos

Tipos de Productos para V&V


Requisitos Diseo Implementacin Administracin de la Configuracin y Cambios

Objetivo de la V&V
Asegurar que el producto satisface las necesidades del usuario. Aspectos considerados por la V&V:
Funcionalidad Portabilidad Desempeo Mantenibilidad Seguridad Usabilidad

Clasificacin de la aplicabilidad de las tcnicas y enfoques de V&V


Correctud
El grado en el que el producto est libre de defectos.

Consistencia
El grado en el que el producto es consistente consigo mismo y con otros productos.

Necesidad
El grado en que lo contenido en el producto es necesario.

Suficiencia (Completud)
El grado en el que el producto est completo.

Desempeo
El grado en el que el producto satisface sus requisitos de desempeo.

Enfoques y tcnicas de V&V


Revisiones Tcnicas del Software (Recorridos e Inspecciones) Prueba de Software Simulacin y Prototipos Rastreabilidad de Requisitos

Revisin Tcnica Formal (RTF)


Actividad del control de calidad del software Objetivos:
Descubrir errores en la funcin, lgica o implementacin en cualquier representacin del software. Verificar que el software en revisin satisface sus requisitos Garantizar que el software se ha representado de acuerdo con los estndares predefinidos.

Revisin Tcnica Formal (RTF)


Lograr software desarrollado en una manera uniforme. Hacer proyectos ms manejables.

Revisin Tcnica Formal (RTF)


Sirve como un proceso de entrenamiento pues permite que los ingenieros menos experimentados observen diferentes enfoques respecto al anlisis, el diseo y la construccin de software. Promueve el soporte y la continuidad, pues varias personas se familiarizan con partes del software que de otra forma nunca veran. Cada RTF se realiza en una junta y tendr xito si se planifica, controla y atendiende apropiadamente.

Junta de revisin
Cualquier junta de revisin debe atenerse a las siguientes restricciones: En la revisin se deben involucrar entre 3 y 5 personas. Se debe preparar con anticipacin, pero sin que requiera ms de 2 horas de trabajo de cada persona. La duracin de la junta de revisin debe ser menor a dos horas. Estas restricciones implican que una RTF se enfoca en una parte especfica y pequea del software total (Porcin de especificacin, diseo detallado de componente, listo de cdigo fuente. Esto tambin se le conoce como un Recorrido

Participantes en la preparacin y realizacin de la junta de revisin


El Productor
Es el ingeniero que ha desarrollado el artefacto.

Jefe del Proyecto


Es el responsable del proyecto.

Jefe de Revisin
Evala la disponibilidad del producto, genera copias del material necesario y las distribuye a dos o tres revisores para que realicen sus observaciones antes de la junta. Revisa el producto y establece una agenda.

Revisores
Se familiarizan con el producto considerando entre una y dos horas y toman sus notas.

Desarrollo de la Reunin
Uno de los revisores asume el papel de registrador Presentacin de la agenda por parte del Jefe de Revisores y breve introduccin por parte del Productor. El Productor inicia el recorrido del producto explicando el material. Los Revisores exponen los problemas que descubrieron antes de la junta.

Desarrollo de la Reunin
El Registrador va anotando los problemas o errores encontrados. Al final todos los asistentes deben decidir si:
Aceptan el producto sin modificaciones posteriores. Rechazan el artefacto debido a errores severos encontrados. Aceptan el producto provisionalmente.

Desarrollo de la Reunin
Se llena documento de finalizacin indicando la participacin y conformidad con los hallazgos del equipo revisor.

Informe de la revisin y conservacin de registros


Un informe resumen de la revisin responde 3 preguntas:
Qu se revis? Quin lo revis? Cules fueron los hallazgos y conclusiones?

Directrices de la revisin
Revisar el producto, no al productor Establecer una agenda y respetarla Limitar el debate y la impugnacin Enunciar reas de problemas, pero no se intente resolver todos los que se hayan sealado.

Directrices de la revisin
Tomar notas Limitar el nmero de participantes e insistir en la preparacin anticipada. Desarrollar una lista de verificacin para cada producto que tenga probabilidad de ser revisado.

Directrices de la revisin
Asignar recursos y programar las RTF. Realizar un entrenamiento significativo de todos los revisores. Analizar las revisiones previas.

Simulacin y Prototipos
Son tcnicas para analizar el comportamiento esperado de un producto. Para los propsitos de la V&V, son normalmente utilizadas para analizar las especificaciones de requisitos asegurarando que reflejan las necesidades de los usuarios. Tambin se utilizan para analizar el desempeo esperado del producto en relacin a los requisitos no funcionales.

Rastreo de Requisitos
Es una tcnica para asegurar que el producto, as como la prueba del producto corresponden a cada uno de sus requisitos. El enfoque tradicional para llevarlo a cabo es mediante el uso de matrices.

Garanta de la calidad estadstica del software


La informacin acerca de los defectos de software se recopila y clasifica. Se intenta determinar la causa de cada defecto Mediante el principio de Pareto (80% de los defectos se encuentran en 20% de todas las causas posibles) se aisla un 20%

Garanta de la calidad estadstica del software


Una vez que las causas vitales han sido identificadas, se corrigen los problemas que han provocado los defectos.

Un ejemplo genrico de la aplicacin de mtodos estadsticos Supngase que una organizacin recopila los defectos de un ao
Especificaciones incompletas o errneas (EIE) Mala interpretacin de la comunicacin con el cliente (MCC) Desviacin intencional de las especificaciones (DIE)

Un ejemplo genrico de la aplicacin de mtodos estadsticos


Violacin de los estndares de programacin (VEP) Errores en la representacin de los datos (modelos de clases, datos) (ERD) Interfaz de componente inconsistente (ICI) Error en la lgica del diseo (ELD) Prueba incompleta o errnea (PIE)

Un ejemplo genrico de la aplicacin de mtodos estadsticos


Error en la traduccin del diseo al lenguaje de programacin (TLP) Errores en la representacin de los datos (modelos de clases, datos) (ERD) Interfaz de componente inconsistente (ICI) Error en la lgica del diseo (ELD) Prueba incompleta o errnea (PIE)

Datos estadsticos
Total Error EIE MCC DIE VEP ERD ICI ELD PIE DII TLP Totales Nmero 205 156 48 25 130 58 45 95 36 60 858 % 24 18 6 3 15 7 5 11 4 7 100 Serios Nmero 34 12 1 0 26 9 14 12 2 15 125 % 27 10 1 0 21 7 11 10 2 12 100 Moderados Nmero 68 68 24 15 68 18 12 35 20 19 347 % 20 20 7 4 20 5 3 10 6 5 100 Menores Nmero 103 76 23 10 36 31 19 48 14 26 386 % 27 20 6 3 9 8 5 12 4 7 100

Interpretacin sobre los resultados presentados


La tabla indica que EIE, MCC y ERD son las causas vitales al representar el 53% de todos los errores. Sin embargo, se debe observar que EIE, ERD, TLP y ELD se seleccionaran como causas vitales si slo se consideran errores serios.

Acciones correctivas
Para corregir EIE y MCC implementar tcnicas que faciliciten la recopilacin de requisitos y que a su vez mejoren la comunicacin con el cliente. Para mejorar ERD adquirir herramientas para el modelado de clases y datos y ejecutar revisiones de diseo ms rigurosas

La aplicacin de SQA y el principio de apareto pueden resumirse en una sola oracin:


Emplee su tiempo enfocndose en las cosas que realmente importan, !pero primero asegrese de entender qu es lo que realmente importa!

Referencias
Pressman, R. Ingeniera Ed.,McGrawHill, 2006. de software: un enfoque prctico. 6ta

También podría gustarte