29 de enero de 2013

Mantenimiento del Software


El mantenimiento de software es una de las actividades más comunes en la Ingeniería de Software y es el proceso de mejora y optimización del software desplegado (es decir; revisión del programa), así como también corrección de los defectos. 

El mantenimiento de software es también una de las fases en el Ciclo de Vida de Desarrollo de Sistemas (SDLC ó System Development Life Cycle), que se aplica al desarrollo de software. 


FASE DE MANTENIMIENTO 

La fase de mantenimiento es la fase que viene después del despliegue (implementación) del software en el campo. 

La fase de mantenimiento de software involucra: 
  • Cambios al software en orden de corregir defectos.
  • Dependencias encontradas durante su uso tanto como la adición de nueva funcionalidad para mejorar la usabilidad y aplicabilidad del software. 

El mantenimiento de software involucra varias técnicas específicas. 

Una técnica es el rebanamiento estático, la cual es usada para identificar todo el código de programa que puede modificar alguna variable. 

Es generalmente útil en la refabricación del código del programa y fue específicamente útil en asegurar conformidad para el problema del año 2000 . 

La fase de mantenimiento de software es una parte explícita del modelo de cascada del proceso de desarrollo de software el cual fue desarrollado durante el movimiento de programación estructurada en computadoras. 

El otro gran modelo, el desarrollo en espiral desarrollado durante el movimiento de ingeniería de software orientada a objetos no hace una mención explícita de la fase de mantenimiento. 

Sin embargo, esta actividad es notable, considerando el hecho de que dos tercios del coste del tiempo de vida de un sistema de software involucran mantenimiento. 

En un ambiente formal de desarrollo de software, la organización o equipo de desarrollo tendrán algún mecanismo para documentar y rastrear defectos y deficiencias. 

El Software tan igual como la mayoría de otros productos, es típicamente lanzado con un conjunto conocido de defectos y deficiencias.

El software es lanzado con esos defectos conocidos porque la organización de desarrollo decide que la utilidad y el valor del software en un determinado nivel de calidad compensa el impacto de los defectos y deficiencias conocidas. 

Las deficiencias conocidas son normalmente documentadas en una carta de consideraciones operacionales o notas de lanzamiento (release notes) es así que los usuarios del software serán capaces trabajar evitando las deficiencias conocidas y conocerán cuando el uso del software sería inadecuado para tareas específicas. 

Con el lanzamiento del software (software release), otros, defectos y deficiencias no documentados serán descubiertas por los usuarios del software. 

Tan pronto como estos defectos sean reportados a la organización de desarrollo, serán ingresados en el sistema de rastreo de defectos. 

Las personas involucradas en la fase de mantenimiento de software esperan trabajar en estos defectos conocidos, ubicarlos y preparar un nuevo lanzamiento del software, conocido como una lanzamiento de mantenimiento, el cual resolverá los temas pendientes. 


TIPOS DE MANTENIMIENTO

A continuación se señalan los tipos de mantenimientos existentes, y entre paréntesis el porcentaje aproximado respecto al total de operaciones de mantenimiento: 

  • Perfectivo (60%): mejora del software (rendimiento, flexibilidad, reusabilidad) o implementación de nuevos requisitos. También se conoce como mantenimiento evolutivo. 
  • Adaptativo (18%): adaptación del software a cambios en su entorno tecnológico (nuevo hardware, otro sistema de gestión de bases de datos, otro sistema operativo...) 
  • Correctivo (17%): corrección de fallos detectados durante la explotación. 
  • Preventivo (5%): facilitar el mantenimiento futuro del sistema (verificar pre-condiciones, mejorar legibilidad...). 

Es importante tener en cuenta el efecto del Iceberg, es decir , en el momento en el que se le hace mantenimiento a un Software no se cuenta muchas veces con el factor económico (¿Cuánto dinero se invertirá en el mantenimiento ?), y una vez se comienza a desarrollar la fase de mantenimiento en la aplicación, comienzan a surgir nuevos requerimientos, el efecto del iceberg (en la superficie se ve solo una parte de lo que realmente es su tamaño).






24 de enero de 2013

Técnicas de Prueba

El desarrollo de Sistemas de software implica la realización de una serie de actividades predispuestas a incorporar errores (en la etapa de definición de requerimientos, de diseño, de desarrollo, ...).

Debido a que estos errores se deben a nuestra habilidad innata de provocar errores, tenemos que incorporar una actividad que garantice la calidad del software.


PROCESO DE PRUEBA



El proceso de prueba tiene dos entradas:

• Configuración del software: Incluye la especificación de requisitos del software, la especificación del diseño y el código fuente
• Configuración de prueba: Incluye un plan y un procedimiento de prueba

Si el funcionamiento del software parece ser correcto y los errores encontrados son fáciles de corregir, podemos concluir con que:

• La calidad y la fiabilidad del software son aceptables, o que
• Las pruebas son inadecuadas para descubrir errores serios


DISEÑO DE CASOS DE PRUEBA

Se trata de diseñar pruebas que tengan la mayor probabilidad de encontrar el mayor número de errores con la mínima cantidad de esfuerzo y de tiempo.

Cualquier producto de ingeniería se puede probar de dos formas:

Pruebas de caja negra: Realizar pruebas de forma que se compruebe que cada función es operativa.
Pruebas de caja blanca: Desarrollar pruebas de forma que se asegure que la operación interna se ajusta a las especificaciones, y que todos los componentes internos se han probado de forma adecuada.

En la prueba de la caja negra, los casos de prueba pretenden demostrar que las funciones del software son operativas, que la entrada se acepta de forma adecuada y que se produce una salida correcta.

En la prueba de caja blanca se realiza un examen minucioso de los detalles procedimentales, comprobando los caminos lógicos del programa, comprobando los bucles y condiciones, y examinado el estado del programa en varios puntos.

A primera vista, la prueba de caja blanca profunda nos llevaría a tener "programas 100 por cien correctos", es decir:
• Definir todos los caminos lógicos
• Desarrollar casos de prueba para todos los caminos lógicos
• Evaluar los resultados

Pero esto supone un estudio demasiado exhaustivo, que prolongaría excesivamente los planes de desarrollo del software, por lo que se hará un estudio de los caminos lógicos importantes.


PRUEBA DE LA CAJA BLANCA

La prueba de la caja blanca es un método de diseño de casos de prueba que usa la estructura de control del diseño procedimental para derivar los casos de prueba.


Las pruebas de caja blanca intentan garantizar que:
• Se ejecutan al menos una vez todos los caminos independientes de cada módulo
• Se utilizan las decisiones en su parte verdadera y en su parte falsa
• Se ejecuten todos los bucles en sus límites
• Se utilizan todas las estructuras de datos internas


Prueba del Camino Básico

El método del camino básico (propuesto por McCabe) permite obtener una medida de la complejidad de un diseño procedimental, y utilizar esta medida como guía para la definición de una serie de caminos básicos de ejecución, diseñando casos de prueba que garanticen que cada camino se ejecuta al menos una vez.

  • Notación del grafo de flujo o grafo del programa:

Representa el flujo de control lógico con la siguiente notación:



A continuación se muestra un ejemplo basado en un diagrama de flujo que representa la estructura de control del programa.




En el grafo de flujo
• Cada nodo representa una o más sentencias procedimentales
• Un solo nodo puede corresponder a una secuencia de pasos del proceso y a una decisión
• Las flechas (aristas) representan el flujo de control

Cualquier representación del diseño procedimental se puede traducir a un grafo de flujo.

Si en el diseño procedimental se utilizan condiciones compuestas, la generación del grafo de flujo tiene que descomponer las condiciones compuestas en condiciones sencillas, tal y como muestra la figura siguiente.




  • Complejidad Ciclomática:
Es una medida que proporciona una idea de la complejidad lógica de un programa.

• La complejidad ciclomática coincide con el número de regiones del grafo de flujo
• La complejidad ciclomática, V(G), de un grafo de flujo G, se define como:
                                                            V(G) = Aristas - Nodos + 2
• La complejidad ciclomática, V(G), de un grafo de flujo G, también se define como:
                                                          V(G) = Nodos de predicado + 1

A partir del grafo de flujo, la complejidad ciclomática sería:
• Como el grafo tiene cuatro regiones, V(G) = 4
• Como el grafo tiene 11 aristas y 9 nodos, V(G) = 11 - 9 - 2 = 4
• Como el grafo tiene 3 nodos predicado, V(G) = 3 + 1 = 4

A partir del valor de la complejidad ciclomática obtenemos el número de caminos independientes, que nos dan un valor límite para el número de pruebas que tenemos que diseñar.

En el ejemplo, el número de caminos independientes es 4, y los caminos independientes son:
• 1-11
• 1-2-3-4-5-10-1-11
• 1-2-3-6-7-9-10-1-11
• 1-2-3-6-8-9-10-1-11

  • Pasos del diseño de pruebas mediante el camino básico:
• Obtener el grafo de flujo, a partir del diseño o del código del módulo

• Obtener la complejidad ciclomática del grafo de flujo

• Definir el conjunto básico de caminos independientes

• Determinar los casos de prueba que permitan la ejecución de cada uno de los caminos anteriores

• Ejecutar cada caso de prueba y comprobar que los resultados son los esperados


Prueba de Bucles

Los bucles son la piedra angular de la inmensa mayoría de los algoritmos implementados en software, por lo que tenemos que prestarles una atención especial a la hora de realizar la prueba del software.

La prueba de bucles es una técnica de prueba de caja blanca que se centra en la validez de las construcciones de los bucles.

Se pueden definir cuatro tipos de bucles diferentes:
• Bucles simples
• Bucles concatenados
• Bucles anidados
• Bucles no estructurados



  • Bucles Simples:
A los bucles simples (de n iteraciones) se les tiene que aplicar el conjunto de pruebas siguientes:
• Saltar el bucle
• Pasar sólo una vez por el bucle
• Pasar dos veces por el bucle
• Hacer m pasos del bucle con m < n
• Hacer n-1, n y n+1 pasos por el bucle

  • Bucles Anidados:
Si extendiésemos el conjunto de pruebas de los bucles simples a los bucles anidados, el número de pruebas crecería geométricamente, por lo que Beizer sugiere el siguiente conjunto de pruebas para bucles anidados:

• Comenzar con el bucle más interno, estableciendo los demás bucles a los valores mínimos
• Llevar a cabo las pruebas de bucles simples para el bucle más interno, conservando los valores de iteración de los bucles más externos a los valores mínimos
• Progresar hacia fuera en el siguiente bucle más externo, y manteniendo los bucles más externos a sus valores mínimos
• Continuar hasta que se hayan probado todos los bucles


  • Bucles Concatenados:
Probar los bucles concatenados mediante las técnicas de prueba para bucles simples, considerándolos como bucles independientes.


  • Bucles No Estructurados:
Rediseñar estos bucles para que se ajusten a las construcciones de la programación estructurada.

Ejemplo:
Construir el Grafo de Flujo correspondiente a la siguiente especificación del software en LDP.

Solución:


Ejemplo: 
Construir el Grafo de Flujo correspondiente al siguiente código de un programa


Solución:


PRUEBA DE LA CAJA NEGRA

Las pruebas de caja negra se llevan a cabo sobre la interfaz del software, obviando el comportamiento interno y la estructura del programa.

Los casos de prueba de la caja negra pretenden demostrar que:
• Las funciones del software son operativas
• La entrada se acepta de forma correcta
• Se produce una salida correcta
• La integridad de la información externa se mantiene

A continuación se derivan conjuntos de condiciones de entrada que utilicen todos los requisitos funcionales de un programa.

Las pruebas de caja negra pretenden encontrar estos tipos de errores:
• Funciones incorrectas o ausentes
• Errores en la interfaz
• Errores en estructuras de datos o en accesos a bases de datos externas
• Errores de rendimiento
• Errores de inicialización y de terminación

Los tipos de prueba de cana negra que vamos a estudiar son:
• Prueba de partición equivalente
• Prueba de análisis de valores límites


Prueba de Partición Equivalente

Este método de prueba de caja negra divide el dominio de entrada de un programa en clases de datos, a partir de las cuales deriva los casos de prueba.
Cada una de estas clases de equivalencia representa a un conjunto de estados válidos o inválidos para las condiciones de entrada.

  • Identificación de las clases de equivalencia:
Se identifican clases de equivalencia válidas e inválidas con la siguiente tabla: 


A continuación se siguen estas directrices:
• Si una condición de entrada especifica un rango de valores (p.e, entre 1 y 999), se define una CEV (1 <= valor <= 999) y dos CEI (valor < 1 y valor > 999)
• Si una CE requiere un valor específico (p.e., el primer carácter tiene que ser una letra), se define una CEV (una letra) y una CEI (no es una letra)
• Si una CE especifica un conjunto de valores de entrada, se define una CEV para cada uno de los valores válidos, y una CEI (p.e., CEV para "Moto", "Coche" y "Camión", y CEI para "Bicicleta")
• Si una condición de entrada especifica el número de valores (p.e., una casa puede tener uno o dos propietarios), identificar una CEV y dos CEI (0 propietarios y 3 propietarios)

  • Identificación de casos de prueba:
Seguir estos pasos
• Asignar un número único a cada clase de equivalencia
• Escribir casos de prueba hasta que sean cubiertas todas las CEV, intentando cubrir en cada casos tantas CEV como sea posible
• Para cada CEI, escribir un caso de prueba, cubriendo en cada caso una CEI

Ejemplo
Diseñar casos de prueba de partición equivalente para un software que capte estos datos de entrada:

• Código de área: En blanco o un número de tres dígitos
• Prefijo: Número de tres dígitos que no comiencen por 0 ó 1
• Sufijo: Número de cuatro dígitos
• Ordenes: "Cheque", "Depósito", "Pago factura"
• Palabra clave: Valor alfanumérico de 6 dígitos




19 de diciembre de 2012

Estrategias de Prueba del Software

Una estrategia de prueba del software integra las técnicas de diseño de casos de prueba en una serie de pasos bien planificados que llevan a la construcción correcta del software.

Las características generales son:
  • La prueba comienza en el nivel de módulo y trabaja “hacia afuera”.
  • En diferentes puntos son adecuadas a la vez distintas técnicas de prueba.
  • La prueba la realiza la persona que desarrolla el software y (para grandes proyectos) un grupo de pruebas independiente.
  • La prueba y la depuración son actividades diferentes.
  • Una estrategia de prueba para el software debe constar de pruebas de bajo nivel, así como de pruebas de alto nivel.
Más concretamente, los objetivos de la estrategia de prueba son:
  • Planificar las pruebas necesarias en cada iteración, incluyendo las pruebas de unidad, integración y las pruebas de sistema. Las pruebas de unidad y de integración son necesarias dentro de la iteración, mientras que las pruebas de sistema son necesarias sólo al final de la iteración.
  • Diseñar e implementar las pruebas creando los casos de prueba que especifican qué probar, cómo realizar las pruebas y creando, si es posible, componentes de prueba ejecutables para automatizar las pruebas.
  • Realizar diferentes pruebas y manejar los resultados de cada prueba sistemáticamente. Los productos de desarrollo de software en los que se detectan defectos son probadas de nuevo y posiblemente devueltas a otra etapa, como diseño o implementación, de forma que los defectos puedan ser arreglados.
Para conseguir estos objetivos el flujo de trabajo de la etapa de Pruebas consta de las siguientes etapas:
  • Planificación de las pruebas.
  • Diseño de las pruebas.
  • Implementación de las pruebas.
  • Ejecución de las pruebas.
  • Evaluación de las pruebas.
Los productos de desarrollo del software fundamentales que se desarrollan en la etapa de Pruebas son:
  •  Plan de Pruebas.
  •  Casos de Prueba.
  •  Informe de evaluación de Pruebas.
  •  Modelo de Pruebas, que incluye Clases de Prueba, Entorno de Configuración de Pruebas, Componentes de Prueba y los Datos de prueba.
Los participantes responsables de las realizar las actividades y los productos de desarrollo del software son:
  • Diseñador de pruebas: Es responsable de la planificación, diseño, implementación y evaluación de las pruebas. Esto conlleva generar el plan de pruebas y modelo de pruebas, implementar los casos de prueba y evaluar los resultados de las pruebas. Los diseñadores de prueba realmente no llevan a cabo las pruebas, sino que se dedican a la preparación y evaluación de las mismas.
  • Probador (Tester): Es responsable de desarrollar las pruebas de unidad, integración y sistema, lo que incluye ejecutar las pruebas, evaluar su ejecución, recuperar los errores y garantizar los resultados de las pruebas.
Durante la fase de Inicio puede hacerse parte de la planificación inicial de las pruebas cuando se define el ámbito del sistema. Sin embargo, las pruebas se llevan a cabo sobre todo cuando un producto de desarrollo software es sometido a pruebas de integración y de sistema. Esto quiere decir que la realización de pruebas se centra en las fases de elaboración, cuando se prueba la línea base ejecutable de la arquitectura, y de construcción, cuando el grueso del sistema está implementado. Durante la fase de Transición el centro se desplaza hacia la corrección de defectos durante los primeros usos y a las pruebas de regresión.

Debido a la naturaleza iterativa del esfuerzo de desarrollo, algunos de los casos de prueba que especifican cómo probar los primeros productos de desarrollo software pueden ser utilizadas también como casos de prueba de regresión que especifican cómo llevar a cabo las pruebas de regresión sobre los productos de desarrollo software siguientes. El número de pruebas de regresión necesarias crece por tanto de forma estable a lo largo de las iteraciones, lo que significa que las últimas iteraciones requerirán un gran esfuerzo en pruebas de regresión. Es natural, por tanto, mantener el modelo de pruebas a lo largo del ciclo de vida del software completo, aunque el modelo de pruebas cambia constantemente debido a:
  • La eliminación de casos de prueba obsoletos.
  • El refinamiento de algunos casos de prueba en casos de prueba de regresión.
  • La creación de nuevos casos de prueba para cada nuevo producto de desarrollo de software.
La gestión de la configuración del software es uno de los procesos clave para toda organización dedicada a la Ingeniería del Software, ya que posibilita una mejor organización del desarrollo y mantenimiento, producto, facilitando el resto de procesos de producción.

Durante el proceso de construcción de un software, los cambios son inevitables. Los cambios provocan confusión e incertidumbre, sobre todo cuando no se han analizado o pronosticado correctamente. Es importante considerar ciertas modificaciones que pueden ocurrirle al software dentro de todo el proceso de ingeniería.

“El arte de coordinar el desarrollo de software para minimizar…la confusión, se denomina gestión de la configuración. La gestión es el arte de identificar, organizar y controlar las modificaciones que sufre el software…la meta es maximizar la productividad minimizando errores".

Pruebas del Software

Las pruebas son uno de los pasos de la ingeniería del software que se puede ver (por lo menos, psicológicamente) como destructivo en lugar de constructivo.

Las pruebas del software son un elemento crítico para la garantía de calidad del software y representa una revisión final de las especificaciones, del diseño y de la codificación. La creciente percepción del software como un elemento del sistema y la importancia de los «costes» asociados a un fallo del propio sistema, están motivando la creación de pruebas minuciosas y bien planificadas. No es raro que una organización de desarrollo de software emplee entre el 30 y el 40 por ciento del esfuerzo total de un proyecto en las pruebas. En casos extremos, las pruebas del software para actividades críticas (por ejemplo, control de tráfico aéreo, control de reactores nucleares) pueden costar de tres a cinco veces más que el resto de los pasos de la ingeniería del software juntos.

Las pruebas presentan una interesante anomalía para el ingeniero del software. Durante las fases anteriores de definición y de desarrollo, el ingeniero intenta construir el software partiendo de un concepto abstracto y llegando a una implementación tangible. A continuación, llegan las pruebas. El ingeniero crea una serie de casos de prueba que intentan «demoler» el software construido. 

Los ingenieros del software son, por naturaleza, personas constructivas. Las pruebas requieren que se descarten ideas preconcebidas sobre la «corrección» del software que se acaba de desarrollar y se supere cualquier conflicto de intereses que aparezcan cuando se descubran errores.

Si la prueba se lleva a cabo con éxito (de acuerdo con el objetivo anteriormente establecido), descubrirá errores en el software. Como ventaja secundaria, la prueba demuestra hasta qué punto las funciones del software parecen funcionar de acuerdo con las especificaciones y parecen alcanzarse los requisitos de rendimiento. Además, los datos que se van recogiendo a medida que se lleva a cabo la prueba proporcionan una buena indicación de la fiabilidad del software y, de alguna manera, indican la calidad del software como un todo. Pero, la prueba no puede asegurar la ausencia de defectos; sólo puede demostrar que existen defectos en el software.


OBJETIVOS DE LAS PRUEBAS

  • La prueba es el proceso de ejecución de un programa con la intención de descubrir un error.
  • Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces.
  • Una prueba tiene éxito si descubre un error no detectado hasta entonces.
  • Diseñar pruebas que sistemáticamente saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y de esfuerzo.
Nos quitan la idea que, normalmente, tenemos de que una prueba tiene éxito si no descubre errores


PRINCIPIOS DE LAS PRUEBAS

Antes de la aplicación de métodos para el diseño de casos de prueba efectivos, un ingeniero del software deberá entender los principios básicos que guían las pruebas del software.

A todas las pruebas se les debería poder hacer un seguimiento hasta los requisitos del cliente. Como hemos visto, el objetivo de las pruebas del software es descubrir errores. Se entiende que los defectos más graves (desde el punto de vista del cliente) son aquellos que impiden al programa cumplir sus requisitos.
Las pruebas deberían planificarse mucho antes de que empiecen. La planificación de las pruebas pueden empezar tan pronto como esté completo el modelo de requisitos. La definición detallada de los casos de prueba puede empezar tan pronto como el modelo de diseño se ha consolidado. Por tanto, se pueden planificar y diseñar todas las pruebas antes de generar ningún código.

El principio de Pareto es aplicable a la prueba del software. Dicho de manera sencilla, el principio de Pareto implica que al 80 por 100 de todos los errores descubiertos durante las pruebas se les puede hacer un seguimiento hasta un 20 por 100 de todos los módulos del programa. El problema, por supuesto, es aislar estos módulos sospechosos y probarlos concienzudamente.

Las pruebas deberían empezar por «lo pequeño» y progresar hacia «lo grande». Las primeras pruebas planeadas y ejecutadas se centran generalmente en módulos individuales del programa. A medida que avanzan las pruebas, desplazan su punto de mira en un intento de encontrar errores en grupos integrados de módulos y finalmente en el sistema entero.

No son posibles las pruebas exhaustivas. El número de permutaciones de caminos para incluso un programa de tamaño moderado es excepcionalmente grande. Por este motivo, es imposible ejecutar todas las combinaciones de caminos durante las pruebas. Es posible, sin embargo, cubrir adecuadamente la lógica del programa y asegurarse de que se han aplicado todas las condiciones en el diseño a nivel de componente.

Para ser más eficaces, las pruebas deberían ser realizadas por un equipo independiente. Por «mas eficaces» queremos referirnos a pruebas con la más alta probabilidad de encontrar errores (el objetivo principal de las pruebas). Por las razones que se expusieron anteriormente, el ingeniero del software que creó el sistema no es el más adecuado para llevar a cabo las pruebas para el software.


FACILIDAD DE PRUEBA

En circunstancias ideales, un ingeniero del software diseña un programa de computadora, un sistema o un producto con la «facilidad de prueba» en mente. Esto permite a los encargados de las pruebas diseñar casos de prueba más fácilmente. Pero, ¿qué es la facilidad de prueba?

La facilidad de prueba del software es simplemente la facilidad con la que se puede probar un programa de computadora. Como la prueba es tan profundamente difícil, merece la pena saber qué se puede hacer para hacerlo más sencillo. A veces los programadores están dispuestos a hacer cosas que faciliten el proceso de prueba y una lista de comprobación de posibles puntos de diseño, características, etc., puede ser útil a la hora de negociar con ellos.

Existen, de hecho, métricas que podrían usarse para medir la facilidad de prueba en la mayoría de sus aspectos. A veces, la facilidad de prueba se usa para indicar lo adecuadamente que un conjunto particular de pruebas va a cubrir un producto. También es empleada por los militares para indicar lo fácil que se puede comprobar y reparar una herramienta en plenas maniobras. Esos dos significados no son lo mismo que «facilidad de prueba del software». La siguiente lista de comprobación proporciona un conjunto de características que llevan a un software fácil de probar.


Operatividad

«Cuanto mejor funcione, más eficientemente se puede probar.»
  • El sistema tiene pocos errores (los errores añaden sobrecarga de análisis y de generación de informes al proceso de prueba).
  • Ningún error bloquea la ejecución de las pruebas.
  • El producto evoluciona en fases funcionales (permite simultanear el desarrollo y las pruebas).

Observabilidad

«Lo que ves es lo que pruebas.».
  • Se genera una salida distinta para cada entrada.
  • Los estados y variables del sistema están visibles o se pueden consultar durante la ejecución.
  • Los estados y variables anteriores del sistema están visibles o se pueden consultar (por ejemplo, registros de transacción).
  • Todos los factores que afectan a los resultados están visibles.
  • Un resultado incorrecto se identifica fácilmente.
  • Los errores internos se detectan automáticamente a través de mecanismos de auto-comprobación.
  • Se informa automáticamente de los errores internos.
  • El código fuente es accesible.

Controlabilidad

«Cuanto mejor podamos controlar el software, más se puede automatizar y optimizar.»
  • Todos los resultados posibles se pueden generar a través de alguna combinación de entrada.
  • Todo el código es ejecutable a través de alguna combinación de entrada.
  • El ingeniero de pruebas puede controlar directamente los estados y las variables del hardware y del software.
  • Los formatos de las entradas y los resultados son consistentes y estructurados.
  • Las pruebas pueden especificarse, automatizarse y reproducirse convenientemente.

Capacidad de Descomposición

«Controlando el ámbito de las pruebas, podemos aislar más rápidamente los problemas y llevar a cabo mejores pruebas de regresión. »
  • El sistema software está construido con módulos independientes.
  • Los módulos del software se pueden probar independientemente.

Simplicidad

«Cuanto menos haya que probar, más rápidamente podremos probarlo.»
  • Simplicidad funcional (por ejemplo, el conjunto de características es el mínimo necesario para cumplir los requisitos).
  • Simplicidad estructural (por ejemplo, la arquitectura es modularizada para limitar la propagación de fallos).
  • Simplicidad del código (por ejemplo, se adopta un estándar de código para facilitar la inspección y el mantenimiento).

Estabilidad

«Cuanto menos cambios, menos interrupciones a las pruebas.»
  • Los cambios del software son infrecuentes.
  • Los cambios del software están controlados.
  • Los cambios del software no invalidan las pruebas existentes.
  • El software se recupera bien de los fallos.

4 de diciembre de 2012

Gestión de la Configuración del Software

El arte de coordinar el desarrollo de software para minimizar... la confusión, se denomina gestión de configuración. La gestión de configuración es el arte de identificar, organizar y controlar las modificaciones que sufre el software que construye un equipo de programación. La meta es maximizar la productividad minimizando los errores.

La gestión de configuración del software (GCS) es una actividad de autoprotección que se aplica durante el proceso del software. Como el cambio se puede producir en cualquier momento, las actividades de GCS sirven para (1) identificar el cambio, (2) controlar el cambio, (3) garantizar que el cambio se implementa adecuadamente y (4) informar del cambio a todos aquellos que puedan estar interesados.

Es importante distinguir claramente entre el mantenimiento del software y la gestión de configuración del software. El mantenimiento es un conjunto de actividades de ingeniería del software que se producen después de que el software se haya entregado al cliente y esté en funcionamiento. La gestión de configuración del software es un conjunto de actividades de seguimiento y control que comienzan cuando se inicia el proyecto de ingeniería del software y termina sólo cuando el software queda fuera de la circulación.

El resultado del proceso de ingeniería del software es una información que se puede dividir en tres amplias categorías: (1) programas de computadora (tanto en forma de código fuente como ejecutable), (2) documentos que describen los programas de computadora (tanto técnicos como de usuario) y (3) datos (contenidos en el programa o externos a él). Los elementos que componen toda la información producida como parte del proceso de ingeniería del software se denominan colectivamente configuración del software.

A medida que progresa el proceso del software, el número de elementos de configuración del software
(ECSs) crece rápidamente. Una especificación del sistema produce un plan del proyecto del software y una especificación de requisitos del software (así como otros documentos relativos al hardware). A su vez, éstos producen otros documentos para crear una jerarquía de información. Si simplemente cada ECS produjera otros ECSs, no habría prácticamente confusión. Desgraciadamente, en el proceso entra en juego otra variable -el cambio-. El cambio se puede producir en cualquier momento y por cualquier razón. De hecho, la Primera Ley de la Ingeniería de Sistemas [BERSO] establece: Sin importar en qué momento del ciclo de vida del sistema nos encontremos, el sistema cambiará y el deseo de cambiarlo persistirá a lo largo de todo el ciclo de vida.

¿Cuál es el origen de estos cambios? La respuesta a esta pregunta es tan variada como los cambios mismos. Sin embargo, hay cuatro fuentes fundamentales de cambios:

Nuevos negocios o condiciones comerciales que dictan los cambios en los requisitos del producto o en las normas comerciales;
Nuevas necesidades del cliente que demandan la modificación de los datos producidos por sistemas de información, funcionalidades entregadas por productos o servicios entregados por un sistema basado en computadora;
Reorganización o crecimiento/reducción del negocio que provoca cambios en las prioridades del proyecto o en la estructura del equipo de ingeniería del software;
Restricciones presupuestarias o de planificación que provocan una redefinición del sistema o producto.

La gestión de configuración del software (GCS) es un conjunto de actividades desarrolladas para gestionar los cambios a lo largo del ciclo de vida del software de computadora.

La gestión de configuración del software es un elemento importante de garantía de calidad del software. Su responsabilidad principal es el control de cambios. Sin embargo, la GCS también es responsable de la identificación de ECSs individuales y de las distintas versiones del software, de las auditorias de la configuración del software para asegurar que se desarrollan adecuadamente y de la generación de informes sobre todos los cambios realizados en la configuración.

Cuando se construye software los cambios son inevitables

• Los cambios aumentan el nivel de confusión en el equipo de desarrollo
• Confusión debida a:
                                  - No se han analizado los cambios antes de realizarlos.
                                  - No se han registrado antes de implementarlos.
                                  - No se les ha comunicado a aquellas personas que necesitan saberlo.
                                  - No se han controlado de manera que mejoren la calidad y reduzcan los errores.
• La Gestión de la Configuración Software (GCS) es una actividad de protección que  gestiona el cambio a lo largo del ciclo de vida del software
• El cambio se puede producir en cualquier momento
• Por tanto, las actividades de GCS son:
                                                             - Identificar el cambio.
                                                             - Controlar el cambio.
                                                             - Garantizar la correcta implementación del cambio.
                                                             - Informar del cambio a todos aquellos que lo necesiten.


Elementos de Configuración

• El software es el resultado del proceso de IS:
                                                                       - Programas.
                                                                       - Datos.
                                                                       - Documentos.
• Los elementos que componen toda la información generada como parte del proceso de IS se denominan colectivamente configuración del software
• A medida que progresa el proceso de IS el número de Elementos de Configuración Software (ECS) crece rápidamente
• e.g. la SRS produce un plan del proyecto y un diseño que a su vez produce código.
• Los ECS producen otros ECSs para crear una jerarquía de información
• Si simplemente tuviéramos esta jerarquía no habría confusión
• La confusión surge cuando entra en juego el cambio
• Éste puede producirse en cualquier momento y por cualquier razón
• Las fuentes fundamentales del cambio son:
      - Fallos.
      - Nuevos negocios o condiciones comerciales que dictan cambios en los requisitos del producto.
      - Nuevas necesidades del cliente que demandan la modificación de los datos, funciones o servicios.
      - Reorganización y/o reducción del volumen comercial que provoca cambios en el proyecto.
      - Restricciones presupuestarias o de planificación que provocan una redefinición del producto.


Línea Base

Es una configuración de referencia en el proceso de desarrollo del software a partir de la cual las revisiones se han de realizar de manera formal, con el objetivo de controlar los cambios en el software, sin impedir llevar a cabo aquellos que sean justificados, Se definen al comienzo del proyecto, coincidiendo con los hitos marcados y generalmente se corresponden con los resultados de las fases.

• Los cambios por tanto pueden ser necesarios y están justificados
• Una línea base es un concepto de GCS que nos ayuda a controlar los cambios sin perjuicio de aquellos que sean necesarios
• El IEEE define una línea base como una especificación o producto que se ha revisado formalmente y sobre los que se ha llegado a un acuerdo, y que de ahí en adelante sirve como base para un desarrollo posterior y que puede cambiarse solamente a través de procedimientos formales de control de cambios
• Antes de que un ECS se convierta en línea base el cambio puede llevarse a cabo de manera rápida e informal
• Sin embargo, una vez que se ha establecido una línea base solo se pueden efectuar los cambios si se aplica un procedimiento  formal para evaluarlos y verificarlos
• El concepto de línea base es similar al de una boda...
• Durante la preparación del evento se pueden cambiar fechas, horas y lugares...... pero una vez mandadas las invitaciones los cambios no son tan sencillos.
• El el contexto de IS definimos una línea base como un punto de referencia en el  desarrollo del software que queda marcado  por el envío de uno o más elementos de  configuración del software y la aprobación  del ECS obtenido mediante una RTF.

Proceso de Generación de Línea Base


• ECSs que forman un conjunto de líneas base:
                                                                       - Plan del proyecto del software.
                                                                       - SRS.
                                                                       - Diseño.
                                                                       - Código.
                                                                       - Casos de prueba.
                                                                       - Manual preliminar de usuario.

                                                                       - Manuales de operación e instalación.
                                                                       - Manual de usuario.
                                                                       - Documentos de mantenimiento.
                                                                       - Estándares y procedimientos de IS.
• Además de estos ECSs pueden inmovilizarse las herramientas de software (e.g., editores, compiladores, herramientas CASE, etc.)


Actividades de GCS

• La GCS es una actividad de protección que  puede considerarse dentro de la SQA
• Aunque su actividad fundamental es el control del cambio también se encarga de otras actividades
• Cualquier GCS debe tener claro:
              - Cómo identificar y gestionar las versiones de un programa para permitir modificaciones.
              - Cómo controlar los cambios antes y después de distribuir el software al cliente.
              - Quién es el responsable de aprobar y de asignar prioridades a los cambios.
              - Como podemos garantizar que los cambios se han llevado a cabo adecuadamente.
              - Qué mecanismos se usan para avisar a otros de los cambios realizados.

• Actividades de GCS:
              - Identificación de ECSs.
              - Control de versiones.
              - Control de cambios.
              - Auditoria de la configuración.
              - Informes de estado.

29 de noviembre de 2012

Métricas de Calidad de Software

¿Qué pasa si no medimos?
  • No sabemos si estamos mejorando
  • No podemos establecer metas
¿Qué se puede medir?
  • El proceso del software (para mejorarlo).
  • El proyecto del software (para ayudar a estimar, control de calidad, evaluación de productividad, control de proyectos).
  • Calidad del producto (para ayudar el la toma de decisiones tácticas a medida que el proyecto evoluciona).
Medidas, métricas e indicadores
  • Medida: Indicación cuantitativa de extensión, cantidad, dimensiones, capacidad y tamaño de algunos atributos de un proceso o producto.
  • Medición: Es el acto de determinar una medida.
  • Métrica: Medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo dado.
  • Indicador: Es una métrica o una combinación de métricas que proporcionan una visión profunda del proceso del SW, del proyecto del SW o del producto en sí.

MÉTRICAS

¿Qué miden?
  • Productividad
  • Calidad
Beneficios
  • Futuras Estimaciones
Medidas
  • Directas
  • Indirectas

Mediciones del Software

Las mediciones del mundo físico se pueden clasificar de dos maneras:
  • Medidas directas: Ej. Longitud de un tornillo :
  • Medidas indirectas: Ej. Calidad de los tornillos producidos, medidos contando los artículos defectuosos
Las métricas del SW, se categorizan de forma similar:
  • Directas: líneas de código producidas (LDC), velocidad de ejecución, tamaño de memoria
  • Indirectas: funcionalidad, calidad, complejidad.

Costos y métricas de calidad
  • Defecto y fallo: son sinónimos dentro del contexto del proceso del software. Implican un problema de calidad que es descubierto una vez entregado el software al cliente.
  • Error: Problema de calidad detectado por los ingenieros u otros dentro del proceso del software.

Indicadores Proyecto/Proceso
  • Indicadores de proceso: Permiten a una organización de ingeniería del software tener una visión profunda  de la eficacia de un proceso ya existente. (las métricas del proceso se recopilan de todos los proyectos y durante un largo período de tiempo).
  • Indicadores de proyecto: Permiten al gestor de proyectos del SW 
                                                    1. evaluar el estado de un proyecto en curso; 
                                                    2. seguir la pista de los riesgos potenciales;
                                                    3. detectar la áreas de problemas antes de que se conviertan en críticas;
                                                    4. ajustar el flujo y las tareas del trabajo;
                                                    5. evaluar la habilidad del equipo.

Métricas
  • Por término general, para la evaluación de la calidad, es más habitual centrarse en medidas del producto que en medidas del proceso.
  • Una métrica es una asignación de un valor a un atributo (tiempo, complejidad, etc.) de una entidad software, ya sea un producto (código) o un proceso (pruebas).

Principios de Medición
  • Los objetivos de la medición deben establecerse antes de empezar la recogida de los datos.
  • Todas la métricas deben definirse sin ambigüedades.
  • La métricas deben obtenerse basándose en una teoría válida para el dominio de la aplicación.
  • Siempre que sea posible, automatizar la recogida de los datos y el análisis.
  • Aplicar técnicas estadísticas válidas para establecer relaciones entre los atributos internos y características  externas de la calidad del producto.
  • Establecer directrices de interpretación y recomendación.

Características de las Métricas
  • Simples y fáciles de calcular
  • Empírica e intuitivamente persuasivas
  • Consistentes y objetivas
  • Independientes del lenguaje de programación
  • Eficaz mecanismo para realimentar la calidad

Etapas del Proceso de Medición
  • Formulación: la obtención de medidas y métricas apropiadas para la representación del SW que se desea desarrollar.
  • Colección: mecanismo empleado para acumular datos necesarios para obtener las métricas formuladas.
  • Análisis: cálculo de las métricas.
  • Interpretación: evaluación de los resultados.
  • Realimentación: recomendaciones obtenidas a través de la interpretación de las métricas obtenidas por el  equipo de desarrollo.

Métricas

Para la evaluación de las características del SW, utilizaremos métricas. Clasificación:
  • Clasificación 1:
                                 - Métricas de producto.
                                  - Métricas de proceso.
  • Clasificación 2:
                                  - Métricas basadas en atributos internos del producto:
                                                 * Medidas de estructuración de un programa.
                                                * Métricas de complejidad.
                                                 * Métricas de cobertura de pruebas.
                                                 * Métricas de calidad del diseño.

                                  - Métricas basadas en atributos externos del producto:
                                                  * Métricas de portabilidad.
                                                 * Métricas de defectos.
                                                  * Métricas de usabilidad.
                                                  * Métricas de mantenibilidad.
                                                  * Métricas de fiabilidad. 

                                  - Métricas basadas en código fuente:
                                                 * Nº de líneas de código.
                                                 * Nº de líneas de comentario.
                                                 * Nº de instrucciones.
                                                 * Densidad de documentación.

                                  - Métricas basadas en estructura de diseño:
                                                *  Relacionadas con el control intramodular.
                                                * Relacionadas con el acoplamiento entre clases.
                                                * Métricas para sistemas orientados a objetos:
                                                * Acoplamiento.
                                                * Herencia.
                                                * Cohesión.