Clase 7

Calidad del Software y Modelos de Mejora

Hoy en día, la calidad del software está relacionada con el proceso de desarrollo y mantenimiento.

Se han utilizado modelos de evaluación y mejora de procesos para identificar e integrar buenas prácticas en el desarrollo del software.

Las empresas que se dedican al desarrollo y mantenimiento del software buscan implementar estrategias para mejorar los procesos.

Los modelos de evaluación y mejora de procesos sirven para medir, identificar, optimizar e integrar buenas prácticas de desarrollo de software. Estos modelos sirven para juzgar la calidad de los procesos que se encuentran sujetos a análisis para implementar estrategias de mejora.

Modelos Más Representativos

CMM: Modelo de Madurez de la Capacidad

Este modelo sirve para identificar la capacidad de los procesos del software. Y también es un modelo que entrega soporte para controlar los procesos de desarrollo y mantenimiento.

• El CMM evalúa la madurez de los procesos de desarrollo de software dentro de una organización.

• Propone un plan de mejora de los procesos y los clasifica en niveles.

Niveles del CMM

• Inicial: Existe productividad y calidad escasa, con un riesgo máximo.

  • Los procesos son cambiantes e irregulares.
  • No existe gestión de proyectos.
  • El rendimiento depende de la capacidad individual de cada integrante del grupo.

• Repetible: Existe una productividad y calidad baja, con un riesgo alto.

  • Los procesos de software repetibles.
  • La organización establece políticas de gerencia de proyectos.
  • La planificación se basa en proyectos similares.
  • La gestión de proyectos se enfoca en experiencias pasadas.

• Definido: Existe una productividad y calidad media, con un riesgo medio.

  • Los procesos son estandarizados y documentados.
  • La gestión es estable y se integran en uno solo.
  • La organización tiene un grupo para la difusión, definición y mejoramiento de los procesos de software.

• Gestionado: Existe una productividad y calidad alta, con un riesgo mínimo.

  • Se establecen metas cuantitativas de la calidad del software.
  • Los procesos son medibles y cuantificables.
  • La productividad y la calidad se fijan y se miden para cada proyecto.

• Optimizado: Existe una productividad y calidad total, con riesgo nulo.

  • Los procesos se mejoran continuamente.
  • Se busca lograr un máximo de la capacidad.
  • Se incorporan nuevas tecnologías y procesos para mejorarlos.

• Áreas Claves del Proceso: Son los objetivos o metas del área clave.

• Características Comunes: Atributos que debe tener el proceso.

• Prácticas Claves: Actividades que se deben hacer para satisfacer los objetivos del área clave.

Para identificar el nivel de madurez se evalúan los procesos del software.

Existen dos modelos: uno de evaluación y otro de mejora.

SCE: Software Capability Evaluation

Método que determina la capacidad del proceso con un rango de resultados esperados.

(SCE utiliza el CMM como referencia)

Principales áreas de aplicación: monitorización del proceso y evaluación interna.

• Se centra en las áreas claves del proceso y las agrupa en 3 categorías: procesos organizacionales, procesos de gestión de proyectos, procesos de ingeniería.

• Está compuesto por actividades: planificar y preparar evaluación, llevar a cabo la evaluación, informar resultados.

Fases SCE

• Planificar y preparar evaluación:

  • Organización patrocinadora: define los objetivos y requisitos de evaluación.
  • Equipo: evalúa y determina el alcance de la organización.
  • Equipo: selecciona los proyectos a evaluar y analiza datos.

• Realizar evaluación:

  • Se determinan los resultados con datos consolidados.
  • Se documentan los resultados.

• Informar resultados: El Equipo SCE evalúa los procesos y revisa la documentación estableciendo fortalezas y debilidades para entregar un informe con resultados obtenidos.

IDEAL: Initiating, Diagnosing, Establishing, Acting, Learning

• Es un modelo que mejora los procesos definiendo un ciclo de vida.

• Establece los pasos necesarios para llevar a cabo la mejora.

• Está compuesto por 5 fases:

  • Iniciación: Es el punto de partida donde se establece la infraestructura, roles y responsabilidades y se asignan recursos.
  • Diagnóstico: Se lleva a cabo el trabajo preliminar para las fases posteriores. Se inicia el plan de acción, el plan estratégico de negocio, objetivos a largo plazo, etc.
  • Establecimiento: Se priorizan los aspectos que la organización quiso mejorar. Se desarrollan las estrategias y el borrador del plan de mejora. También se desarrollan objetivos medibles a partir de los objetivos iniciales.
  • Actuación: Se crean y se llevan a cabo las acciones de mejora identificadas en fases previas. Y se desarrollan planes para ejecutar las acciones de mejora.
  • Aprendizaje: Se han aprendido lecciones del proceso y se han desarrollado soluciones, se han tomado mediciones de rendimiento, para conseguir los objetivos deseados.

Clase 8

CMMI

• Busca integrar tres modelos de mejora de procesos: software, ingeniería de sistemas y desarrollo de procesos y productos integrados.

• Elimina inconsistencias, reduce duplicaciones, incrementa claridad y comprensión.

• Modelos:

  • Software: Describe principios y prácticas de madurez del proceso de software.
  • Ingeniería de Sistemas: Integra todas las disciplinas de sistemas para conocer las necesidades técnicas y de negocio.
  • Proceso Integrado de Desarrollo de Productos: Es un enfoque sistemático para el desarrollo del producto que incrementa la satisfacción del cliente.

• CMMI selecciona los aspectos más importantes de la mejora de procesos y los agrupa en áreas.

• Categorías principales: requerido, esperado e informativo:

  • Requerido: El único componente requerido es el objetivo. Y puede ser genérico o específico. Genérico puede aplicarse a todas las áreas de procesos, y el específico es único en un área de procesos.
  • Esperado: Puede no estar presente en el modelo CMMI. El único componente esperado es la declaración de una práctica, que representa el método esperado para el cumplimiento del objetivo.
  • Informativo: Constituye la mayoría del modelo. Es una guía útil para mejorar los procesos. Usa dos tipos de representación al igual que el CMM.
    • Representación por etapas: Proporciona un marco predefinido para la mejora organizacional agrupando los procesos por etapas. Considerándose el término de etapas como los niveles de madurez.
      • Cada nivel de madurez corresponde a las áreas de procesos que debe centrarse la organización para mejorar sus procesos. Se describen como prácticas que satisfacen los objetivos, y las prácticas describen la infraestructura y actividades en la implementación efectiva del área de procesos.
    • Representación continua: Proporcionan una guía menos específica del orden en que debería realizarse el proceso de mejora.

SCAMPI

Método de evaluación aplicable a un amplio rango de modelos de evaluación, incluyendo tanto las evaluaciones internas como la determinación de la capacidad externa.

• Se pueden aplicar en los siguientes modelos de evaluación:

  • Mejora interna del proceso: para establecer una línea base del nivel de capacidad o madurez. Establecer un programa de mejora del proceso y medir el progreso de implementación.
  • Selección del suministrador: los resultados se usan como factores discriminantes para la selección de suministradores y para establecer riesgos relacionados.
  • Monitorización del proceso: se usa como mecanismo de control del proceso suministrador cuando se ha seleccionado.

• Principales fases de evaluación: planificación y preparación de la evaluación (donde incluye el análisis de los requerimientos de evaluación), realización de la evaluación (en la que se recaba la información necesaria para la evaluación relacionada con el modelo de referencia), informe de resultados (en donde se entregan y archivan los resultados adecuadamente).

Clase 9

Características de Calidad del Software

• Los modelos de calidad interna y externa categorizan los atributos en 6 características:

  Funcionalidad: Capacidad del producto software para proporcionar funciones que satisfacen necesidades declaradas e implícitas cuando se usa bajo condiciones especificadas.

  Fiabilidad: Capacidad del producto del software para mantener un nivel especificado de prestaciones.

  Usabilidad: Capacidad del producto software para ser entendido, aprendido, usado y ser atractivo para el usuario, cuando se usa bajo condiciones especificadas.

  Eficiencia: Capacidad del producto software para proporcionar prestaciones apropiadas, relativas a la cantidad de recursos usados, bajo condiciones determinadas.

  Mantenibilidad: Capacidad del producto software para ser modificado. Las modificaciones podrían incluir correcciones, mejoras o adaptación del software a cambios en el entorno, y requisitos y especificaciones funcionales.

  Portabilidad: Capacidad del producto software para ser transferido de un entorno a otro.

• Modelo de calidad en uso: contempla las siguientes características:

  • Efectividad: Permitir al usuario alcanzar objetivos esperados, con exactitud y completos, dentro de un contexto de uso.
  • Productividad: Permite a los usuarios gastar una cantidad adecuada de recursos en relación a una efectividad alcanzada.
  • Seguridad de uso: Capacidad del software para alcanzar niveles aceptables de riesgo hacia las personas, negocio, software, etc.
  • Satisfacción: Capacidad del software de satisfacer al usuario.

Clase 10

Técnicas de Revisión y Pruebas de Software

• Técnicas de revisión del software: Son un filtro para el proceso de software. Sirve para descubrir errores y defectos para ser eliminados.

• Métricas de revisión: Conjunto de métricas útiles para evaluar la eficiencia.

  Esfuerzo de preparación (Ep): Esfuerzo (en horas-hombre) requerido para revisar un producto del trabajo antes de la reunión de revisión real.

  Esfuerzo de evaluación (Ea): Esfuerzo requerido (en horas-hombre) que se dedica a la revisión real.

  Esfuerzo de la repetición (Er): Esfuerzo (en horas-hombre) que se dedica a la corrección de los errores descubiertos durante la revisión.

  Tamaño del producto del trabajo (TPT): Medición del tamaño del producto del trabajo que se ha revisado (por ejemplo, número de modelos UML o número de páginas de documento o de líneas de código).

  Errores menores detectados (Errmenores): Número de errores detectados que pueden clasificarse como menores (requieren menos de algún esfuerzo especificado para corregirse).

  Errores mayores detectados (Errmayores): Número de errores encontrados que pueden clasificarse como mayores (requieren más que algún esfuerzo especificado para corregirse).

  Erevisión = Ep + Ea + Er (1)

  Errtot = Errmenores + Errmayores (2)

  Densidad del error = Errtot / TPT (3)

• Prueba de software: Verificación y validación.

  • Verificación: Es el conjunto de tareas que garantizan el correcto funcionamiento de una función específica. (¿Construimos el producto correctamente?)
  • Validación: Conjunto diferente de tareas que aseguran el software que se construya siga los requerimientos del cliente. (¿Construimos el producto correcto?)
  • La verificación y validación incluyen las pruebas de software que representan la última etapa donde se valora la calidad o se descubren errores.

  Pruebas de Unidad

  La prueba de unidad enfoca los esfuerzos de verificación en la unidad más pequeña del diseño de software: el componente o módulo de software. Al usar la descripción del diseño de componente como guía, las rutas de control importantes se prueban para descubrir errores dentro de la frontera del módulo. La relativa complejidad de las pruebas y los errores que descubren están limitados por el ámbito restringido que se establece para la prueba de unidad. Las pruebas de unidad se enfocan en la lógica de procesamiento interno y de las estructuras de datos dentro de las fronteras de un componente.

  Este tipo de pruebas puede realizarse en paralelo para múltiples componentes.

  Consideraciones de las Pruebas de Unidad

  La interfaz del módulo se prueba para garantizar que la información fluya de manera adecuada hacia y desde la unidad de software que se está probando.

  Las estructuras de datos locales se examinan para asegurar que los datos almacenados temporalmente mantienen su integridad durante todos los pasos en la ejecución de un algoritmo.

  Las condiciones de frontera se prueban para asegurar que el módulo opera adecuadamente en las fronteras establecidas para limitar o restringir el procesamiento.

  Y finalmente se ponen a prueba todas las rutas para el manejo de errores.

  Procedimientos de Prueba de Unidad

  Las pruebas de unidad por lo general se consideran como adjuntas al paso de codificación. El diseño de las pruebas de unidad puede ocurrir antes de comenzar la codificación o después de generar el código fuente. La revisión de la información del diseño proporciona una guía para establecer casos de prueba que es probable que descubran errores en cada una de las categorías analizadas anteriormente.

  Puesto que un componente no es un programa independiente, con frecuencia debe desarrollarse software controlador y/o de resguardo para cada prueba de unidad.

  En la mayoría de las aplicaciones, un controlador no es más que un “programa principal” que acepta datos de caso de prueba, pasa tales datos al componente (que va a ponerse a prueba) e imprime resultados relevantes. Los representantes sirven para sustituir módulos que están subordinados al componente que se va a probar. Un representante o “subprograma tonto” usa la interfaz de módulo subordinado, puede realizar mínima manipulación de datos, imprimir verificación de entradas y regresar el control al módulo sobre el que se realiza la prueba.

  Pruebas de Integración

  Si todas las unidades que fueron testeadas funcionan de manera individual, ¿cómo funcionarán todas juntas?

  Un problema a solucionar es juntarlas, conectarlas e instalar el software en un ambiente controlado (simulación del ambiente del cliente).

  Las pruebas de integración son una técnica sistemática para construir la arquitectura del software mientras se llevan a cabo pruebas para descubrir errores a nivel macro. El objetivo es tomar los componentes probados de manera individual y construir una estructura de programa que se haya dictado por diseño.

  Entonces, ¿cómo se desarrollan las pruebas de integración con varios componentes o módulos del software? La integración incremental es la respuesta. El programa se construye y prueba en pequeños incrementos, donde los errores son más fáciles de aislar y corregir; los componentes que se juntan tienen más posibilidades de probarse por completo; y puede aplicarse un enfoque de prueba sistemático.

  Existen dos tipos de integración incremental:

  Pruebas de Validación

  La validación es exitosa cuando el software funciona en una forma que cumpla con las expectativas razonables del cliente. En este punto, un desarrollador de software curtido en la batalla puede protestar: “¿quién o qué es el árbitro de las expectativas razonables?”. Si se desarrolló una especificación de requerimientos de software, en ella se describen todos los atributos del software visibles para el usuario; debe contener una sección de criterios de validación que forman la base para un enfoque de pruebas de validación.

  Criterios de Pruebas de Validación

  La validación del software se logra a través de una serie de pruebas que demuestran conformidad con los requerimientos. Un plan de prueba subraya las clases de pruebas que se van a realizar y un procedimiento de prueba define casos de prueba específicos que se diseñan para garantizar que: se satisfacen todos los requerimientos de funcionamiento, se logran todas las características de comportamiento, todo el contenido es preciso y se presenta de manera adecuada, se logran todos los requerimientos de rendimiento, la documentación es correcta y se satisfacen la facilidad de uso y otros requerimientos (por ejemplo, transportabilidad, compatibilidad, recuperación de error, mantenimiento).

  Pruebas Alfa y Beta

  Virtualmente, es imposible que un desarrollador de software prevea cómo usará el cliente realmente un programa. Las instrucciones para usarlo pueden malinterpretarse; regularmente pueden usarse combinaciones extrañas de datos; la salida que parecía clara a quien realizó la prueba puede ser ininteligible para un usuario.

  Cuando se construye software a la medida para un cliente, se realiza una serie de pruebas de aceptación a fin de permitir al cliente validar todos los requerimientos. Realizada por el usuario final en lugar de por los ingenieros de software, una prueba de aceptación puede variar desde una “prueba de conducción” informal hasta una serie de pruebas planificadas y ejecutadas sistemáticamente.

  Pruebas Alfa

  Se lleva a cabo en el sitio del desarrollador por un grupo representativo de usuarios finales. El software se usa en un escenario natural con el desarrollador “mirando sobre el hombro” de los usuarios y registrando los errores y problemas de uso. Las pruebas alfa se realizan en un ambiente controlado.

  Pruebas Beta

  Se realiza en uno o más sitios del usuario final. A diferencia de la prueba alfa, por lo general el desarrollador no está presente. Por tanto, la prueba beta es un software “en vivo” del software en un ambiente que no puede controlar el desarrollador. El cliente registra todos los problemas (reales o imaginarios) que se encuentran durante la prueba beta y los reporta al desarrollador periódicamente.

  Como resultado de los problemas reportados durante las pruebas beta, es posible hacer modificaciones y luego preparar la liberación del producto de software a toda la base de clientes.

  Pruebas del Sistema

  El software se incorpora con otros elementos del sistema (por ejemplo, hardware, personas, información), y se lleva a cabo una serie de pruebas de integración y validación del sistema. Estas pruebas quedan fuera del ámbito del proceso de software y no se llevan a cabo exclusivamente por parte de ingenieros de software.

  Sin embargo, los pasos que se toman durante el diseño y la prueba del software pueden mejorar enormemente la probabilidad de integración exitosa del software en el sistema más grande.

  Pruebas de Recuperación

  La recuperación es una prueba del sistema que fuerza al software a fallar en varias formas y que verifica que la recuperación se realice de manera adecuada. Si la recuperación es automática (realizada por el sistema en sí), se evalúa el reinicio, los mecanismos de puntos de verificación, la recuperación de datos y la reanudación para correcciones. Si la recuperación requiere intervención humana, se evalúa el tiempo medio de reparación (TMR) para determinar si está dentro de límites aceptables.

  Pruebas de Seguridad

  La prueba de seguridad intenta verificar que los mecanismos de protección que se construyen en un sistema en realidad lo protegerán de cualquier penetración impropia.

  Durante la prueba de seguridad, quien realiza la prueba juega el papel del individuo que desea penetrar al sistema. Cualquier cosa vale, quien realice la prueba puede intentar adquirir contraseñas por medios administrativos externos; puede atacar el sistema con software a la medida diseñado para romper cualquier defensa que se haya construido; puede abrumar al sistema, y por tanto negar el servicio a los demás; puede causar a propósito errores del sistema con la esperanza de penetrar durante la recuperación; puede navegar a través de datos inseguros para encontrar la llave de la entrada al sistema.

  Pruebas de Esfuerzo

  La prueba de esfuerzo ejecuta un sistema en forma que demanda recursos en cantidad, frecuencia o volumen anormales. Por ejemplo, pueden:

  Diseñarse pruebas especiales que generen diez interrupciones por segundo, cuando una o dos es la tasa promedio.

  Aumentarse las tasas de entrada de datos en un orden de magnitud para determinar cómo responderán las funciones de entrada.

  Ejecutarse casos de prueba que requieran memoria máxima y otros recursos.

  Crearse casos de prueba que puedan causar búsqueda excesiva por datos residentes en disco.

  En esencia, la persona que realiza la prueba intenta colgar o botar el software.

  Pruebas de Rendimiento

  La prueba de rendimiento se diseña para poner a prueba el rendimiento del software en tiempo de ejecución, dentro del contexto de un sistema integrado. La prueba del rendimiento ocurre a lo largo de todos los pasos del proceso de prueba. Incluso en el nivel de unidad, puede accederse al rendimiento de un módulo individual conforme se realizan las pruebas.

  Sin embargo, no es sino hasta que todos los elementos del sistema están plenamente integrados cuando puede determinarse el verdadero rendimiento de un sistema.

  Pruebas de Caja Blanca

  La prueba de caja blanca, en ocasiones llamada prueba de caja de vidrio, es una filosofía de diseño de casos de prueba que usa la estructura de control descrita como parte del diseño a nivel de componentes para derivar casos de prueba. Al usar los métodos de prueba de caja blanca, puede derivar casos de prueba que:

  Garanticen que todas las rutas independientes dentro de un módulo se revisaron al menos una vez.

  Revisen todas las decisiones lógicas en sus lados verdadero y falso.

  Ejecuten todos los bucles en sus fronteras y dentro de sus fronteras operativas.

  Revisen estructuras de datos internas para garantizar su validez.

  Pruebas de Ruta Básica

  La prueba de ruta o trayectoria básica es una técnica de prueba de caja blanca. El método de ruta básica permite al diseñador de casos de prueba derivar una medida de complejidad lógica de un diseño de procedimiento y usar esta medida como guía para definir un conjunto básico de rutas de ejecución.

  Los casos de prueba derivados para revisar el conjunto básico tienen garantía para ejecutar todo enunciado en el programa, al menos una vez durante la prueba.

  Pruebas de Caja Negra

  Las pruebas de caja negra, también llamadas pruebas de comportamiento, se enfocan en los requerimientos funcionales del software; es decir, las técnicas de prueba de caja negra le permiten derivar conjuntos de condiciones de entrada que revisarán por completo todos los requerimientos funcionales para un programa. Las pruebas de caja negra no son una alternativa para las técnicas de caja blanca. En vez de ello, es un enfoque complementario que es probable que descubra una clase de errores diferente que los métodos de caja blanca.

  Las pruebas de caja negra intentan encontrar errores en las categorías siguientes:

  Funciones incorrectas o faltantes. Errores de interfaz.

  Errores en las estructuras de datos o en el acceso a bases de datos externas.

  Errores de comportamiento o rendimiento.

  Errores de inicialización y terminación.

  Métodos de Prueba Basados en Gráficos

  El primer paso en la prueba de caja negra es entender los objetos que se modelan en software y las relaciones que conectan a dichos objetos. Una vez logrado esto, el siguiente paso es definir una serie de pruebas que verifiquen “que todos los objetos tengan la relación mutua esperada”.

  Dicho de otra forma, la prueba de software comienza con la creación de un gráfico de objetos importantes y sus relaciones, y luego diseña una serie de pruebas que cubrirán el gráfico, de modo que cada objeto y relación se revise y se descubran errores.

  Para lograr estos pasos, comience por crear un gráfico: una colección de nodos que representen objetos, enlaces que representen las relaciones entre objetos, nodos ponderados que describan las propiedades de un nodo (por ejemplo, un valor de datos o comportamiento de estado específicos) y enlaces ponderados que describan alguna característica de un enlace.

  En el ejemplo simple, considere una porción de un gráfico para una aplicación de un procesador de texto, donde:

  Objeto #1: newFile (selección de menú)

  Objeto #2: documentWindow

  Objeto #3: documentText

  Una selección de menú en newFile genera una ventana de documento. El nodo ponderado de documentWindow proporciona una lista de los atributos de ventana que se esperan cuando se genere la ventana. El enlace ponderado indica que la ventana debe generarse en menos de 1,0 segundo. Un enlace no dirigido establece una relación simétrica entre la selección de menú newFile y documentText, y los enlaces paralelos indican relaciones entre documentWindow y documentText.

  El objetivo de estos grados es encontrar errores en alguna de las relaciones entre objetos del software.