Calidad Enfocada en el Desarrollo de Software M.C. Juan Carlos Olivares Rojas Noviembre 2009

Calidad Enfocada en el Desarrollo de Software

M.C. Juan Carlos Olivares Rojas

Noviembre 2009

• Conoce la importancia de la aplicación de la calidad en cada una de las fases en el desarrollo de un software.

• Genéricas

• Instrumentales: Capacidad de análisis y síntesis, Capacidad de organizar y planificar, Comunicación oral y escrita en su propia lengua, Conocimiento de una segunda lengua, Habilidades de gestión de información, Toma de decisiones.

Competencias

• Interpersonales: Capacidad de trabajar en equipo interdisciplinario, Compromiso ético.

• Sistémicas: Capacidad de aplicar los conocimientos en la práctica, Habilidades de investigación, Capacidad de generar nuevas ideas (creatividad), Liderazgo, Capacidad para diseñar y gestionar proyectos, Iniciativa y espíritu emprendedor, Preocupación por la calidad, Búsqueda del logro.

Competencias

• Actividades 10%

• Aplicación de Estándares de Calidad en el Proyecto 30% (dos metodologías por equipo de trabajo presentando resultados al final de la unidad en fecha aun por especificar)

• Actividad Evaluadora Parcial 60%

Evidencias

• Qué es la calidad del software.

• Cómo obtener calidad de software (métodos, metodologías, estándares).

• Cómo controlar la calidad del software.

• Costo de la calidad del software.

• Nomenclatura y certificación ISO 9001:2000.

Temario

• La norma ISO/IEC 9126.

• Análisis de factores que determinan la calidad del software.

Temario

• Calidad desde el inicio (comunicación y planeación)

• Calidad en el modelado (análisis y diseño)

• Calidad en la construcción (codificación y pruebas)

• Calidad en el despliegue (instalación, mantenimiento).

Temario

Calidad en la Comunicación• Problemas de comunicación

Trabajo en Equipos• El problema de comunicación se da a

través de la colaboración de varias personas en un proyecto.

• El capital intelectual como se ha comentado es sumamente difícil de controlar y estandarizar.

• La mejor forma de trabajar en equipo es a través de una buena cultura organizacional (principios y valores).

Técnicas de Discusión• Para la toma de decisiones grupales, existen

varios métodos que se pueden seguir como: – votación (la decisión más votada gana),– votación aprobatoria (cada miembro puede votar por

más de una opción, la opción más votada es la que gana),

– suma de rangos (se otorgan ponderaciones a las opciones, siendo 1 para la menos votada, este proceso se realiza por participante, gana la opción con mayor puntaje) y

– desviación mínima (se selecciona la opción que tenga mayor puntaje y cuya desviación sea mínimo).

Técnicas de Discusión• Estas técnicas se pueden mejorar a

través de otras técnicas que ayudan a la toma de decisiones que a continuación se mencionan:– lluvia de ideas, – rueda de mesa (similar a la lluvia de ideas

pero cada quien tiene un turno para exponer sus ideas de forma cíclica),

– análisis FODA (Fortalezas Oportunidades Debilidades Amenazas).

Técnicas de Discusión• Para problemas más complejos se puede

utilizar la técnica Philips 66. La cual consiste en hacer grupos de 6 personas que discutirán el problema por 6 minutos.

• Otra técnica compleja es el Proceso Delphi, la cual se utiliza cuando se desea aislar los miembros del grupo para aislar sus opiniones; o bien, cuando se necesita la opinión de expertos los cuales se encuentran alejados geográficamente.

Calidad en la Planeación• De las tres etapas de la planeación, el

itinerario (calendarización de actividades) es la que generalmente se realiza.

• El seguimiento se da en prácticamente cualquier estándar de calidad (quizás en proyectos pequeños no se de con tanta frecuencia)

• La estimación es la etapa más complicada en cuestión del desarrollo de software y la estimación de costos no es la excepción.

• El costo de la calidad tiene dos componentes: lo que se invierte en obtener buena calidad y lo que se paga por no lograrla.

• La primera componente es decidida por los desarroladores y puede ser controlada; la segunda no se puede decidir sino que se manifiesta en las fallas de nuestro producto.

Costos de la Calidad del Sw


• Entre los costos de prevención se incluyen:– planificación de la calidad,– revisiones técnicas formales,– equipo de pruebas,– formación.

• Entre los costos de evaluación se encuentran:– inspección en el proceso y entre procesos,– calibrado y mantenimiento del equipo,– pruebas.

Costos de la calidad del Sw

Costos de la calidad del Sw• Entre los costos de fallos se encuentran:

– retrabajo (revisión),– reparación,– análisis de las modalidades de fallos.– resolución de quejas,– devolución y sustitución de productos,– soporte de línea de ayuda,– trabajo de garantía.


• Si llamamos P, E, Fi, Fe y C a las horas totales usados en el proyecto para actividades categorizadas como prevención, Evaluación, Fallas internas, Fallas externas y Creación, respectivamente, tenemos que:

• Esfuerzo de Calidad = EoQ = (P+E+ Fi+Fe)• Costo de Calidad = CoQ = (P+E+Fi+Fe) /

(P+E+Fi+Fe+C)• Esfuerzo de Mala Calidad = EoPQ = Fi+Fe• Costo de Mala Calidad = CoPQ = (Fi+Fe) /

(P+E+Fi+Fe+C)

Costo de la Calidad del Sw

• Ejemplo: En un proyecto se usaron 1280 horas de las cuales 280 horas se usaron en administración, 60 en entrenamiento para el proyecto, 40 en adaptaciones del proceso para el proyecto, 420 en creación, 50 en inspecciones, 160 en pruebas, 30 en correcciones debido a inspecciones, y 150 en debugging antes de la entrega, y 90 en correcciones finales después de la entrega.


• Quedan 1000 horas en actividad del proyecto propiamente tal descontadas las horas de administración.

• Entonces tenemos: P=60+40, E=50+160, Fi=30+150, Fe=90, C=420, EoQ=580, CoQ=58%, EoPQ=270, CoPQ=27% y Overhead=280/1280=21,9%.


Costos de la Calidad del Software• Ejemplo

– Un ingeniero experimentado introduce 100 defectos por KLOC y el 50% de estos llegan a la fase de pruebas

– Un producto de 50,000 LOC entraría a la fase de pruebas con 2,500 defectos por ser encontrados

– Se requiere en promedio de 5 a 10 horas-programador para encontrar cada defecto, es decir, un total de 20,000 horas-programador

– Un equipo de 5 personas, trabajando 160 horas al mes, terminaría en 25 meses

23

Costos de la Calidad del Software• Ejemplo

– Asumir un rendimiento promedio del 70% en el proceso de aseguramiento de calidad.

– Un producto de 50,000 LOC entraría a la fase de pruebas con 750 defectos por ser encontrados

– Se requeriría un total de 6,000 horas-programador para encontrar todos los defectos

– Un equipo de 5 personas, trabajando 160 horas al mes, terminaría en un periodo de entre 7 y 8 meses

– El ahorro sería de 1 año y medio de pruebas!!!

© 2001 by Carnegie Mellon University

Calidad en QuarkSoft Tamaño Productividad Error Calidad

C++ 28,344 LOC 6.14 LOC/Hr 26.59% 0.18 D/KLOC FourJs 48,578 LOC 6.98 LOC/Hr 3.03% 0.24 D/KLOCProgress 43,793 LOC 5.39 LOC/Hr 1.34% 0.34 D/KLOCJava 42,086 LOC 5.25 LOC/hr 18.32% 0.41 D/KLOC

Defectos/KLOC Antes

de TSP

Con TSP

Delta Reducción Tasa de

corrección (días)

Tiempo de corrección

(días)

Costo 320

dólares diarios

Pruebas de Integración

10 1 -9 -720 1.5 -1080 345,600

Pruebas de Sistema

5 0.5 -4.5 -360 1.5 -540 172,800

Pruebas de aceptación

2.5 0.25 -2.25 -180 1.5 -270 86,400

TOTAL -1260 -1890 604,800

• Asumiendo un producto de 80 KLOC

• En promedio, los defectos encontrados en pruebas se llevan de 8 a 20 horas corregirlos cada uno

Calidad en el Desarrollo de Sw• En el 2006 el departamento de defensa

de los estados unidos realizó el proyecto bug hunting en donde revisaron los errores del top 50 de proyectos de código abierto.

• Se encontraron los siguientes estadísticos

Calidad en el desarrollo de SwProyecto Defectos

DetectadosDefectos Pendientes de Verificar

Defectos pendientes de Inspección

Líneas de código (KLOC)

Defectos/KLOC

Apache-httpd

2 4 25 133.919 0.217

Firebird 0 0 197 270.917 0.727

Firefox 352 65 168 1855.717 0.126

FreeBSD 0 6 605 1582.166 0.386

Gnome 349 12 48 706.511 0.085

KDE 1253 10 40 4619.029 0.011

Mono 69 1 70 334.195 0.212

NetBSD 1267 196 1350 4717.818 0.328

PHP 75 0 1 467.757 0.002

PostgreSQL 53 0 23 846.884 0.027

Calidad en el modelado• ¿Cuántos diagramas debo crear? No

existe una respuesta específica.

• ¿Debo hacer diagramas de todo tipo? No, sólo se deben utilizar los diagramas que mejor reflejen el modelado de la problemáticaoe

Calidad en el modelado• ¿Qué tan grande debe de ser un

diagrama? Entre más grande sea un diagrama mayor es la confusión. Se deben realizar diagramas bien detallados, pero no tan detallados.

• ¿Cuánto texto debe complementar el modelo? Entre menos texto mejor, son como los comentarios del código fuente: pocos pero claros.

Calidad en el modelado• Algunas recomendaciones para el

modelado de software son:

• No tenga a los programadores esperando los modelos.

• Trabajar de una macrovista a una microvista(enfoque Top-Down).

• Se debe documentar en forma económica.

Calidad en el modelo• Si es obvio no se debe de modelar.

• Hacer hincapié en la especialización.

• Utilizar patrones de diseño.

• Reestructuración de códigos

Proceso de negocios• Un proceso de negocios es un conjunto de pasos o actividades relacionadas en las que intervienen gente, información y otros recursos para crear valor.

• Los procesos de negocios se integran de

pasos que se pueden identificar en el tiempo y el espacio

• Tiene un principio y un fin

Procesos de Negocio

Procesos de Negocios• Tienen entradas y salidas

• Tiene un grado de formalización pero no necesitan ser totalmente estructurados

Procesos de Negocio

Procesos de negocios• Los procesos de negocios son la manera más común de mejorar el desempeño de los sistemas de trabajos ya que podemos cambiar el proceso de negocio cambiando, eliminando o agregando pasos al proceso o también cambiando los métodos de cómo se usan estos pasos

Procesos de Negocio

Proceso de Negocios

Proceso de Negocio

Proceso de Negocio

Modelado Procesos Negocios

36

Proceso de taladrado

Calibrar Leer instrucción detaladrado

Perforar

Iniciartaladrado

Taladrar

«resource»

:Máquina

«people»

:Maestro

«information»

:Instrucciones

«physical»

:Plato«physical»

Perforado :Plato

«goal»

Perforar no menos de 10.000 platos

semanales :Quantitativ e Goal

«process control»«resource flow»

«resource flow»

«achieve»

Investigación Diseño de Productos Marketing Ventas Fabricación

Mejoramiento de Producto

Concepción

Lanzamiento de Producto

Modelado de procesos• El modelado de procesos es en si mismo

el proceso de negocio.

• Es la subdivisión del proceso de negocios en sus elementos básicos con el propósito de poderlos estudiar y mejorarlos

Modelado de Procesos de Negocios• El modelado de procesos es esencial

en el desarrollo de los sistemas de información ya que nos ayuda a identificar el problema que el sistema de información deberá resolver y la manera en como deberá resolverlo

Función vs. Proceso• Función: identificada por un verbo. Es continua.

– Comercializar – Fabricar – Vender – Expedir – Comprar

• Proceso: identificado por verbo+sustantivo. Tiene un inicio y un fin. No es continuo. – Tomar un pedido – Ensamblar un pieza – Facturar a un cliente – Solicitar materiales

Procesos de Negocios• Las aplicaciones empresariales están

diseñadas para apoyar la coordinación e integración de procesos que abarcan toda la empresa.

• Ejemplos de estas Aplicaciones empresariales se muestran a continuación:

• Sistemas de administración de la cadena de suministro (SCM).

Procesos de Negocio• Sistemas de administración de relaciones

con clientes (CRM).

• Sistemas de administración del conocimiento (Business Intelligence).

• Sistemas Integrales que abarcan los procesos de la organización, llamados ERP (Enterprise Resource Plannig).

Procesos de Negocio• Los Sistemas de Administración del Conocimiento recolectan todo el conocimiento y experiencia relevantes en la empresa y la hacen disponible donde y cuando sea necesaria para apoyar los procesos de la empresa y las decisiones administrativas. También enlazan a la empresa a fuentes externas de conocimiento.

Procesos de Negocio

Procesos de Negocio• Los Sistemas de Administración del Conocimiento recolectan todo el conocimiento y experiencia relevantes en la empresa y la hacen disponible donde y cuando sea necesaria para apoyar los procesos de la empresa y las decisiones administrativas. También enlazan a la empresa a fuentes externas de conocimiento.

BPMN

• Desarrollado por Business Process Management Initiative (BPMI).

• Es un estándar: BPMN Business Process Modeling

Notation.

• La especificación BPMN 1.0 fue publicada en Mayo del 2004.

BPMN

• El objetivo principal de desarrollar BPMN es proveer una notación que sea fácilmente entendible por todos los usuarios de negocio.

• Desde los analistas que crean los borradores iniciales de procesos hasta los desarrolladores técnicos que son responsables de implementar la tecnología que ejecutará dichos procesos. Y por supuesto, la gente de negocio que manejará y monitoreará estos procesos.

Introducción

• BPMN define un Diagrama de Procesos de Negocio (BPD), basado en la técnica de “flowcharting” (diagramado de flujos) que ajusta modelos gráficos de operación de procesos de negocio.

• Un modelo de procesos de negocio es una red de objetos gráficos, correspondientes a actividades y controles de flujo que definen el orden de ejecución de éstas.

Introducción

Un BPD (diagrama de procesos de negocio) se estructura con un grupo de elementos gráficos.

Las cuatro categorías básicas de elementos son:

• Flow Objects (objetos de flujo)• Connecting Objects (objetos de conexión)• Swimlanes (Carriles)• Artifacts (artefáctos)

Elementos

Un BPD tiene un pequeño grupo de elementos centrales (tres), los cuales son los Flow Objects:

- Event (Evento)

- Activity (Actividad)

- Gateway (Decisión)

Elementos: Flow Objects

•Un evento se representa por un circulo y es algo que “sucede” durante el curso de un proceso de negocio.

•Los eventos afectan el flujo del proceso y usualmente tienen un causa (trigger - disparador) o un impacto (result – resultado).

•Los eventos se representan con círculos con el centro abierto para permitir anotar diferentes disparadores o resultados.

Flow Objects: Event

• Hay tres tipos de eventos basado en cuándo ellos afectan el flujo:

- Start (comienzo)

- Intermediate (intermedio)

- End (final)

Flow Objects: Event

• Una actividad (Activity) se representa por un rectángulo con sus bordes redondeados y es un término genérico para el trabajo que un organización realiza.

• Un actividad puede ser atómica o no atómica (compuesta).

Flow Objects: Activity

• Los tipos de actividades son:

- Task (tareas)

- Sub-process (subproceso)

Los subprocesos se distinguen por un pequeño + al centro y abajo en la figura.

Flow Objects: Activity

+

• Un Gateway es representado por la figura de un diamante y se usa para controlar la divergencia de la secuencia de un flujo.

• Determina las “tradicionales” decisiones, tanto de bifurcaciones, como uniones y acoplamientos de flujos. • Las anotaciones al interior indican el tipo de comportamiento de control.

Flow Objects: Gateway

• Los objetos de flujo se conectan entre ellos en un diagrama para crear el esqueleto básico de la estructura de un proceso de negocio.

• Existen tres Connecting Objects que proveen esta función de conexión.

Elementos: Connecting Objects

- Sequence Flow

- Message Flow

- Association

Connecting Objects: Sequence Flow

Un Sequence Flow se representa por una línea sólida con el extremo sólido

Es usada para mostrar el orden (secuencia) de la actividad dentro del proceso.

Note que el término “control flow” generalmente no es usado en BPMN.

Connecting Objects: Message Flow

Un Message Flow se representa por una línea segmentada con el extremo sin relleno.

Es usada para mostrar el flujo de mensajes entre dos participantes de procesos separados (business entities o business roles).

En BPMN, dos “Pools” en el diagrama representan a dos participantes.

Connecting Objects: Association

Una Association se representa por una línea segmentada finamente con el extremo en punta.

Se usa para asociar datos, textos u otros artefactos con flujos de objetos.

Las asociaciones son usadas para mostrar las entradas y salidas de las actividades.

Ejemplo con formas básicas

Ejemplo de Proceso de Negocio Simple

Ejemplo con formas básicas y marcas internas en las formas

Segmento de un Proceso con más detalles

Elementos: Swimlanes

Muchas técnicas de modelados utilizan el concepto de swimlanes como mecanismo de organización de actividades en categorías visuales separadas para ilustrar las diferentes capacidades funcionales o responsabilidades.

BPMN soporta swimlanes con dos constructores principales:

- Pool- Lane

Swimlanes : PoolUn Pool representa un Participante en un Proceso.

El Pool también actúa como contenedor gráfico para separar al grupo de actividades realizadas por un participante de otros Pools. Los Pools se usan generalmente en el contexto de situaciones B2B.

Nom

bre

Swimlanes : Lane

Un Lane es una partición dentro de un pool y se extiende a lo largo de todo el pool, tanto vertical como horizontalmente.

Los Lanes son usados para organizar y categorizar actividades.

Nom

bre

Nom

bre

Nom

bre

Swimlanes : Pool & Lane

Los Pools se usan cuando los diagramas involucran a dos entidades de negocios o participantes separados.

Están físicamente separados en el diagrama.

Las actividades dentro de Pools separados son consideradas auto contenidas en el proceso. De esta forma, la secuencia del flujo podría no atravesar el límite del Pool.


Los flujos de mensajes son los mecanismos que muestran la comunicación entre dos participantes, conectando de esta manera a dos Pools (u objetos dentro de los Pools).


Ejemplo de BPD con Pools

Swimlanes : Pool & LaneLos Lanes son más cercanos a los swimlanes que tradicionalmente se utilizan para modelar procesos de negocio.

Los Lanes son usados para separar actividades asociadas con una función específica de la organización.

La secuencia de flujos podría atravesar los límites del Lane dentro de un Pool, pero podrían no usarse flujos de mensajes entre Flow Objects en Lanes del mismo Pool.


Segmento de un Proceso con Lanes

Elementos : ArtifactsBPMN fue diseñado para permitir a los modeladores y herramientas de modelado algunas flexibilidades para extender la notación básica y proveer la habilidad poder modelar diferentes contextos apropiadamente.

No está limitado el número de Artefactos que se pueden agregar a un diagrama para que éste represente más apropiadamente al contexto del negocio.

La versión actual de BPMN predefine sólo tres tipos de artefactos.

Elementos : Artifacts

Data object

Group

Annotation

Nombre[Estado]

Anotaciones de Texto permiten al Modelador agregar información adicional

Artifact : Data Object

Los Data Objects son un mecanismo para mostrar como las actividades requieren o producen objetos.

Se conectan a las actividades a través de asociaciones.

Nombre[Estado]

Artifact : Group

Un Group es representado por un rectángulo redondeado dibujado con línea segmentada

El agrupamiento puede ser usado para propósitos de documentación o análisis, y no afecta la secuencia del flujo.

Artifact : Annotation

Las Annotations son mecanismos para que un modelador pueda agregar información textual adicional para el lector del diagrama BPMN.

Anotaciones de Texto permiten al Modelador agregar información adicional

ArtifactLos modeladores puede crear sus propios tipos de artefactos que agreguen más detalle al proceso.

Con bastante frecuencia se muestran entradas y salidas de actividades en los procesos. Sin embargo, la estructura básica del procesos, es especificada con actividades, gateways, y flujos de secuencia.

Artifact

Segmento de un Proceso con Lanes. Sin artefactos. Segmento de un Proceso con

Lanes. Con artefactos.

Elementos centrales de los diagramas

Lista completa de elementos

Ejemplo

Elementos del Proceso

Usos Generales de BPMN

Dentro de la variedad de objetivos de modelado de procesos, hay dos tipos básicos que pueden ser creados con un BPD:

• Collaborative (Public) B2B Processes

• Internal (Private) Business Processes

Collaborative (Public) B2B Processes

Ejemplo proceso colaborativo

Ejemplo Proceso de Alto Nivel

Ejemplo de proceso de alto nivel el cual es básicamente una serie de subprocesos con tres puntos de decisión.



Ej. Proceso Interno: Más bajo Nivel

Modelado de Negocios con el UML

• Modelo de Casos de Uso de Negocios– Actores del Negocio– Casos de Uso del Negocio– Diagramas de Casos de Uso del Negocio– Diagramas de Actividades

• Modelo de Objetos del Negocio– Trabajadores del Negocio– Entidades del Negocio– Diagramas de Actividades (Detallado)– Diagramas de Colaboración– Diagramas de Secuencia

Modelo de casos de uso del negocio

Actor Negocio

Actor del Negocio

Alguien o algo externo a la empresa que interactúa con ella.

Ejemplos: Clientes, Proveedores, etc.


Caso de uso del Negocio

Secuencia de acciones (actividades) que una organización realiza para obtener un resultado observable y de valor para un actor de negocio particular. Un caso de uso del negocio es lo mismo que un proceso de negocio

Caso de Uso del negocio


Diagrama de Casos de Uso del Negocio

Es la representación de un grupo de casos de uso del negocio relacionados dentro de la empresa. Nos dicen que procesos de la organización proporcionan valor agregado y los individuos que interactúan con la misma. Describen completamente la organización en términos de casos de uso del negocio.

Fabricar Producto

Gestionar Almacen

Registrar PedidoCliente

<<initiator>>

Generar pedidos a los proveedores

Proveedor


Diagrama de Actividades

Es la representación de una secuencia de actividades dentro de un caso de uso del negocio. Provee una manera gráfica de documentar un caso de uso del negocio.

Inicio Rellenar Pedido

Tramitar Pedido

Analizar Viabilidad

ViableNotificar rechazo

[No]

Ordenar fabricacion

Planificar Produccion

Notificar Aceptacion

Fin OK

Fin NoOK

[Si]

Fabricar Producto

Gestionar Almacen

Registrar PedidoCliente

<<initiator>>

Generar pedidos a los proveedores

Proveedor

Caso Empresa de Fabricación

D. A. Registrar Pedido

Inicio Rellenar Pedido

Tramitar Pedido

Analizar Viabilidad

ViableNotificar rechazo

[No]

Ordenar fabricacion

Planificar Produccion

Notificar Aceptacion

Fin OK

Fin NoOK

[Si]

Modelo de objetos del negocio

Trabajador del Negocio

Un Trabajador del Negocio (Obrero, Empleado o funcionario) realiza actividades dentro de un caso de uso del negocio, interactua con otros trabajadores del negocio y manipula entidades del negocio .

Trabajador del negocio

Modelo de objetos del negocio

Entidades del Negocio

Una "cosa" manipulada o usada por los trabajadores del negocio. Son ejemplos de entidades del negocio: factura, pedido, plan de producción, etc

Entidad del Negocio

Planificar producción

Rellenar Pedido

Inicio

Cursar pedido

Notificar rechazo

Notificar Aceptación

FinKO

FinOK

Analizar Viabilidad

Ordenar fabricación

Viable

[ No ]

[Si]

Jefe ProducciónJefe tecnico:Comercial:ClienteCliente Comercial JefeTécnico JefeProducción

Diagrama de Actividades Detallado

Empleado CatalogoProducto

Plantilla de Fabricación

Jefe Producción

Pedido

1..*1 1..*1

Jefe Tecnico Orden de Trabajo

Diagrama de Clases

Diagrama de Secuencia

: Empleado : Cliente : Jefe Tecnico : Jefe Producción

1. Tramitar a Pedido2. Estudiar Pedido

3. * Analizar Fabricación

4. Planificar Fabricación5. Informar

6. Aceptar Pedido

98

Diagrama de Colaboración

: Cliente : Empleado

: Jefe Tecnico : Jefe Producción

1. Tramitar a Pedido

2. Estudiar Pedido

3. * Analizar Fabricación

4. Planificar Fabricación

5. Informar

6. Aceptar Pedido

Procesos de Negocio

Pruebas y depuración• La fase de prueba se realiza una vez

integrado cada uno de los módulos del sistema.

• La fase de pruebas se realiza de distintas formas tratando de encontrar la mayoría de los errores que se encuentran de manera inherente en el software.

Depuración• Una vez identificado los errores en la fase

de pruebas, se procede a corregirlos. A esta fase se le llama depuración.

• En la fase de depuración también se arreglan detalles superficiales del software además de optimizar y mejorar algunos procesos.

Pruebas y depuración• La fase de prueba se realiza una vez

integrado cada uno de los módulos del sistema.

• La fase de pruebas se realiza de distintas formas tratando de encontrar la mayoría de los errores que se encuentran de manera inherente en el software.

Depuración• Una vez identificado los errores en la fase

de pruebas, se procede a corregirlos. A esta fase se le llama depuración.

• En la fase de depuración también se arreglan detalles superficiales del software además de optimizar y mejorar algunos procesos.

Depuración• Es la detección, corrección y eliminación

de errores de software.

• El tener un plan de pruebas ayuda a clarificar el proceso de depuración.

• El plan de pruebas debe de estar mucho antes de la construcción del software.

Depuración• Existen muchos tipos de pruebas dependiendo

de la labor y características de cada una de ellas.

• Pruebas Alfa: se realizan por el usuario final en un ambiente controlado.

• Pruebas Beta: se realizan por el usuario sin controlar el ambiente.

Depuración• A continuación se mencionan algunas

características deseables que deben contener los planes de prueba:

• Diseñar un caso de prueba para cada funcionalidad del software.

• Establecer como mínimo un caso de prueba de datos correcto.

Depuración• Establecer como mínimo un caso de

prueba de datos incorrecto.

• Ejemplo: Caso de Prueba de un módulo de raíz cuadrada.

• Qué el usuario ingrese un número mayor que 0.

Depuración• Qué el usuario ingrese un número 0

• Qué el usuario ingrese un número menor que 0.

• Toda actividad de construcción (codificación) es susceptible de cometer errores dado que se trata de una actividad humana.

Depuración• Al realizar la depuración de un programa

existe la posibilidad de un 50% de cometer otro error.

• Es recomendable realizar pruebas de trazado (assert) para visualizar en donde ocurren los errores.

Depuración• Se recomienda probar lo antes posible

cualquier fragmento de código.

• Las pruebas ayudan al aseguramiento de calidad pero no garantizan que un software esté 100% libre de errores.

Depuración• Las pruebas de caja blanca también

llamadas transparentes se concentran en lo que es el código fuente.

• No se pueden tener pruebas que abarquen el 100% de los casos de uso. Se deben realizar pruebas de segmentos

Depuración• Las pruebas de segmentos son bloques

de instrucciones.

• Las pruebas de caja negra están orientadas a lo que se espera realicen los componentes modulares del sistema.

Depuración• Son pruebas funcionales y no interesa como se

realizan las cosas sólo que el resultado obtenido sea el correcto.

• Se recomienda que sean los usuarios quienes las realicen.

• Existen diversas filosofías de pruebas como la programación defensiva.

Depuración• La programación defensiva es una

técnica de probar primero. Es considerada una técnica de codificación. Se basa en el principio de divide y vencerás.

• Se codifica el esqueleto de la aplicación.

• Se realizan pruebas.

Depuración• Se corrigen los errores y se vuelven a

hacer pruebas.

• Las pruebas de estrés se encargan de observar el rendimiento de la aplicación sobre cargas demandantes de trabajo: grandes volúmenes de datos con poco espacio en disco, 90% de uso de CPU, múltiples conexiones, etc.

Depuración• Existen otros tipos de prueba como:

• Pruebas de unidad: se encargan de un módulo de software en particular.

• Pruebas de Integración: son pruebas que se realizan con dos o más módulos trabajando en conjunto.

Depuración• Existen otro tipos de prueba como las de

aceptación que están más involucradas en el concepto en sí que en el desarrollo.

• También se pueden aplicar pruebas aleatorias. Lo ideal es poder utilizar un framework de pruebas.

Depuración• La mayoría de los IDEs modernos

presentan frameworks para la depuración desde el clásico step by step o step over sobre cada uno de los módulos hasta la realización de pruebas de unidad.

• Entre las más famosas destacan JUnit para realizar pruebas de unidad en Java.

Guía Prueba de Programas• Se necesita especificar las salidas o

resultados esperados.

• Un programador debe de evitar probar sus propios programas.

• Una organización no debe de probar sus propios programas.

Guía Prueba de Programas• Inspeccionar los resultados obtenidos de

cada prueba.

• Los casos de prueba deben escribirse con condiciones de entrada que son inválidas e inesperadas, así como también aquellas que son válidas y esperadas.

Guía Prueba de Programas• Examinar un programa para verificar que

hace lo que deba de hacer es sólo parte de la prueba, la otra mitad es asegurarse que el programa no haga lo que no deba de hacer.

• No realizar planeaciones asumiendo que no se encontrarán errores.

Guía Prueba de Programas• La probabilidad de la existencia de mas

errores en una sección de un programa es proporcional al número de errores encontrados en esa sección.

• La realización de pruebas es una actividad extremadamente creativa e intelectualmente retadora.

Guía Prueba de Programas• Se debe de realizar una lista de

verificación para inspecciones de prueba que contenga los siguientes puntos:

• Datos• Declaración de datos• Errores computacionales• Errores de comparación

Guía Prueba de Programas• Errores de control de flujo• Errores de Interface• Errores de Entrada/Salida

• Se pueden utilizar métodos deductivos e inductivos para la prueba de software.

Depuración por Inducción• Se siguen los siguientes pasos:

• Localizar los datos pertinentes• Organizar los datos• Estudiar las relaciones• Divisar las hipótesis• Probar las hipótesis• Corregir el error

Depuración por Deducción• Enumerar las posibles causas• Usar procedimientos de eliminación• Refinar las hipótesis restantes• Probar las hipótesis restantes• Si no se pueden probar las hipótesis

entonces coleccionar más datos y repetir el proceso

• En caso contrario corregir el error

XP eXtreme Programming• Se tienen doce principios básicos:

• Planeación y requerimientos• Entregas pequeñas e incrementales• Metáforas de Sistemas• Diseños simples• Pruebas continuas• Refactorización

XP eXtreme Programming• Programación en pares• Propiedad colectiva del código• Integración Continua• Semanas de 40 horas• Clientes como miembros del equipo• Codificar con estándares

Extreme Testing• Las programación extrema tienen las

siguientes ventajas en lo que respecta al proceso de pruebas:

• Se gana confianza ya que el código debe cumplir las especificaciones.

• Se tiene el resultado final del código antes de codificar

Extreme Testing• Se entiende mucho mejor las

especificaciones y requerimientos de la aplicación.

• Se inicia con diseños simples y se refactoriza el código después para mejorar el desempeño sin preocuparse de que se estén rompiendo las especificaciones.

Plan de Pruebas• Se recomienda utilizar la metodología y

formatos del estándar IEEE 829 para documentación de pruebas de software:

• Pasos que incluye:

• Identificador de plan de pruebas (se muestra el estándar a seguir para el nombre de las pruebas)

Plan de Pruebas• Introducción (en que consiste las pruebas

del sistema)• Elementos a probar• Características a ser probadas• Características que no se probarán• Enfoque• Criterio de fallo o aceptación de los

elementos

Plan de Pruebas• Criterio de Suspensión y Reanudación de

requerimientos• Entregables de las pruebas• Tareas de las pruebas• Necesidades del entorno• Responsabilidades• Equipo y necesidades de capacitación• Agenda

Plan de Pruebas• Riesgos y contingencias• Acuerdos

• A las pruebas se les ha empezado a llamar de manera formal verificación y validación.

• Existen metodologías más robustas como el TMMI (Test Maturity Model)

Plan de pruebas

Formato Plan de Pruebas ID: 1 Nombre: Enviar artículo Probado por: Fulanito Descripción: Se introducen los datos del artículo y de los autores.

Condiciones de Entrada: nombreArticulo=“Calidad del Sw” … emailAutor=“[email protected]”

Resultado Esperado: El sistema confirma la correcta recepción del artículo enviando un e-mail al autor de contacto con un userid y password para que el autor pueda posteriormente acceder al artículo.

Resultado Obtenido: Se generan bien userid y password pero el correo no llegó.

Criterio de Aceptación: No.

Práctica de Laboratorio• Realizar un programa que permita

calcular el área de un triángulo conociendo tres lados utilizando la fórmula de herón.

• Realizar el plan de pruebas que garantice que el programa está libre de errores

Arquitectura

Casos de Pruebas• ¿Con cuantos casos de prueba valido que

el software está correcto?

• Para cada caso de prueba sólo indicar las posibles entradas.

• Por ejemplo:

• Caso de Prueba 1: A=3 B=4 C=5, el resultado esperado debe de ser 6.

• ¿Es diferente el caso A=4 B=3 C=5?

Casos de Prueba• Tipos de Triángulo en Base a sus lados:

• Se deben tener al menos un caso de cada uno de ellos y al menos un caso no válido: A=0 B=-1 C=“Hola”.

Caso de Prueba• ¿Cuál es el resultado esperado para el

caso de prueba A=1 B=2 C=3?

• Area=0

• ¿Qué pasó?

• !Exento este parcial quien pueda dibujar un triangulo de dimensiones 1, 2 y 3 cm para cada lado!

Referencias• Pressman, R. (2004). Ingeniería del

Software un Enfoque Práctico. Sexta Edición. McGraw Hill.

• Guido, J. y Clements, J., “Administración Exitosa de Proyectos”, Segunda Edición, Thomson, México, 2003, ISBN: 0-324-07168-X.

Referencias• Pintor, A. (2009), Material del curso

Calidad del Software II, Instituto Tecnológico de Morelia.

• Myers, et al. (2004), “The Art of Software Testing”, Wiley, Estados Unidos, 2004, ISBN: 0-471-46912-2

Referencias• Piattini M.G. y F.O, Calidad en el

desarrollo y mantenimiento del software. Ed. RAMA.

¿Preguntas?

Documents

Calidad Enfocada en el Desarrollo de Software M.C. Juan Carlos Olivares Rojas Noviembre 2009