4 Calidad enfocada al desarrollo de software

4.1 Que es calidad de software

Desarrollar software de calidad que cumpla con estandares,funcionablidad,rendimiento ajustado a las necesidades y exigencial del cliente y con el menor costo posible.

4.2 Como obtener calidad de software (metodos, metodologias, estandares)

La obtención de un software con calidad implica la utilización de metodologías o procedimientos estándares para el análisis, diseño, programación y prueba del software que permitan uniformar la filosofía de trabajo, en aras de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como  para el control de la calidad del software.

La política establecida debe estar sustentada sobre tres principios básicos: tecnológico, administrativo y ergonómico.

      El principio tecnológico define las técnicas a utilizar en el proceso de desarrollo del software.

      El principio administrativo contempla las funciones de planificación y control del desarrollo del software, así como la organización del ambiente o centro de ingeniería de software.

      El principio ergonómico define la interfaz entre el usuario y el ambiente automatizado.

La adopción de una buena política contribuye en gran medida a lograr la calidad del software, pero no la asegura. Para el aseguramiento de la calidad es necesario su control o evaluación.

El aseguramiento de la calidad

Ante todo se debe conocer:

·         Aseguramiento de la calidad: "Conjunto de acciones planificadas y sistemáticas necesarias para proporcionar la confianza adecuada de que un producto o servicio satisfará los requerimientos dados sobre calidad".

·         Aseguramiento de la calidad de software: Conjunto de actividades planificadas y sistemáticas necesarias para aportar la confianza en que el producto (software) satisfará los requisitos dados de calidad.

El aseguramiento de calidad del software se diseña para cada aplicación antes de comenzar a desarrollarla. Hay quienes prefieren decir garantía de calidad en vez de aseguramiento.

La garantía, puede confundir con garantía de productos, mientras que el aseguramiento pretende dar confianza en que el producto tiene calidad.

El aseguramiento de calidad del software está presente en:

·         Métodos y herramientasde análisis, diseño, programación y prueba.

·         Inspecciones técnicas formales en todos los pasos del proceso de desarrollo del               software.

·         Estrategias de prueba multiescala.

·         Control de la documentación del software y de los cambios realizados.

·         Procedimientos para ajustarse a los estándares (y dejar claro cuando se está fuera de ellos).

·         Mecanismos de medida (métricas).

·         Registro de auditorias y realización de informes.

Las actividades para el aseguramiento de calidad del software se detallan en:

·         Métricas de software para el control del proyecto.

·         Verificación y validación del software a lo largo del ciclo de vida (Incluye las pruebas y los procesos de revisión e inspección).

·         La gestión de la configuración del software.

Algunos métodos del aseguramiento:

·         Revisiones técnicas y de gestión (su objetivo es la evaluación).

·         Inspección (su objetivo es la verificación). ¿Estamos construyendo el producto correcto?.

·         Pruebas (su objetivo es la validación). ¿Estamos construyendo el producto correctamente?.

Auditorias (su objetivo es la confirmación del cumplimiento). 

4.3 Como controlar la calidad de software

El control de la calidad

Se debe conocer:

· Control de calidad: "Conjunto de técnicas y actividades de carácter operativo, utilizadas para verificar los requerimientos relativos a la calidad del producto o servicio".

· Control de la calidad del software: Técnicas y actividades de carácter operativo, utilizadas para verificar los requisitos relativos a la calidad, centradas en mantener bajo control el proceso de desarrollo y eliminar las causas de los defectos en las diferentes fases del ciclo de vida.

El control de la calidad del software está centrado en dos objetivos fundamentales:

Mantener bajo control un proceso.

Eliminar las causas de los defectos en las diferentes fases del ciclo de vida.

En general, se puede decir que el control de de la calidad del software son las actividades para evaluar la calidad de los productos desarrollados.

Para controlar la calidad del software es necesario, ante todo, definir los parámetros, indicadores o criterios de medición, ya que, como bien plantea Tom De Marco, “usted no puede controlar lo que no se puede medir”.

Las cualidades para medir la calidad del software son definidas por innumerables autores, los cuales las denominan y agrupan de formas diferentes. Por ejemplo, John Wiley define métricas de calidad y criterios, donde cada métrica se obtiene a partir de combinaciones de los diferentes criterios. La Metodología para la evaluación de la calidad de los medios de programas de la CIC, de Rusia, define indicadores de calidad estructurados en cuatro niveles jerárquicos: factor, criterio, métrica, elemento de evaluación, donde cada nivel inferior contiene los indicadores que conforman el nivel precedente. Otros autores identifican la calidad con el nivel de complejidad del software y definen dos categorías de métricas: de complejidad de programa o código, y de complejidad de sistema o estructura.

4.4 Costo de calidad del software

Como una de las variables de la Triple Limitación, la Calidad es uno de los objetivo del proyecto. Los costos de la calidad son aquellos en que incurre el proyecto para mejorar los entregables prometidos. Estos costos pueden ser de dos tipos: Costos de Prevención y Costos de Evaluación.

      Costos de Prevención: están causados por las medidas tomadas en el proyecto para prevenir defectos o problemas en los entregables, para evitar la aparición de errores. En un proyecto de software esto sería por ejemplo implementar una metodología de desarrollo consistente. En una obra en construcción esto sería por ejemplo cumplir con los estándares de tendido de líneas eléctricas para prevenir problemas posteriores.

      Costos de Evaluación: están causados por las medidas tomadas para evaluar los entregables una vez producidos, y corregirlos si es necesario. En un proyecto de software esto sería por ejemplo dedicar recursos a las pruebas de integración del sistema una vez desarrollado. En una obra en construcción esto sería por ejemplo realizar inspecciones periódicas de la estructura.               

           Existen varias actividades típicas en un proyecto relacionadas la Costo de la Calidad:

      Capacitación (este es un Costo de Prevención): capacitación en la construcción o entrega del producto o servicio. Sirve para insertar el proceso de administración de calidad dentro del proceso de elaboración. Sirve para implementar la calidad en términos técnicos, específicos a los entregables.

      Mantenimiento (Costo de Prevención): definición de políticas de mantenimiento posteriores a la finalización del proyecto. Sirve para conservar el buen desempeño de los entregables una vez finalizado el proyecto.

      Pruebas (Costo de Evaluación): especificación y ejecución de pruebas para verificar el cumplimiento de los requerimientos por parte de los entregables. Sirve para validar el funcionamiento normal de los entregables antes de que se usen en producción.

      Auditorías (Costo de Evaluación): desarrollo de auditorías que inspeccionen el proceso de construcción de los entregables. Sirven para no cometer el mismo error dos veces.

4.5 Nomenclatura y certificación ISO 9001:2000

La norma ISO 9001, es un método de trabajo, que se considera tan bueno, Que es el mejor para mejorar la calidad y satisfacción de cara al consumidor. La versión actual, es del año 2000 ISO 9001:2000, que ha sido adoptada como modelo a seguir para obtener la certificación de calidad. Y es a lo que tiende, y debe de aspirar toda empresa competitiva, que quiera permanecer y sobrevivir en el exigente mercado actual.

Estos principios básicos de la gestión de la calidad, son reglas de carácter social encaminadas a mejorar la marcha y funcionamiento de una organización mediante la mejora de sus relaciones internas. Estas normas, han de combinarse con los principios técnicos para conseguir una mejora de la satisfacción del consumidor.

Los ocho principios de la gestión de la calidad identificados para lograr los objetivos de la calidad, según "ISO 9000:2000 Sistemas de Gestión de la Calidad. Fundamentos y vocabulario." son:

1. Enfoque al cliente. Las organizaciones dependen de sus clientes y por la tanto deberían comprender las necesidades actuales y futuras de los clientes, satisfacer los requisitos de los clientes y esforzarse en exceder las expectativas de los clientes.

2. Liderazgo. Los líderes establecen la unidad de propósito y la orientación de la organización. Ellos deberían crear y mantener un ambiente interno, en el cual el personal pueda llegar a involucrarse totalmente en el logro de los objetivos de la organización.

3. Participación del personal. El personal, a todos los niveles, es la esencia de una organización y su total compromiso posibilita que sus habilidades sean usadas para el beneficio de la organización.

4. Enfoque basado en procesos. Un resultado deseado se alcanza más eficientemente cuando las actividades y los recursos relacionados se gestionan como un proceso.

5. Enfoque de sistema hacia la gestión. Identificar, entender y gestionar los procesos interrelacionados como un sistema, contribuye a la eficacia y eficiencia de una organización en el logro de sus objetivos.

6. Mejora continua. La mejora continua del desempeño global de la organización debería ser un objetivo permanente de ésta.

7. Enfoque basado en hechos para la toma de decisiones. Las decisiones eficaces se basan en el análisis de los datos y la información.

8. Relación mutuamente beneficiosa con el proveedor . Una organización y sus proveedores son interdependientes, y una relación mutuamente beneficiosa aumenta la capacidad de ambos para crear valor.

Estos ocho principios de gestión de la calidad constituyen la base de las normas de sistemas de gestión de la calidad de la familia de Normas ISO 9000.

4.6 La norma ISO/IEC 9126

La Organización Internacional para la Estandarización (ISO) dispone de dos definiciones de usabilidad:

ISO /ICE 9126

“La usabilidad se refiere a la capacidad de un software de ser comprendido, aprendido, usado y ser atractivo para el usuario, en condiciones específicas de uso”

Esta definición hace énfasis en los atributos internos y externos del producto, los cuales contribuyen a su usabilidad, funcionalidad y eficiencia. 

La usabilidad depende no sólo del producto sino también del usuario. Por ello un producto no es en ningún caso intrínsecamente usable, sólo tendrá la capacidad de ser usado en un contexto particular y por usuarios particulares.

 La usabilidad no puede ser valorada estudiando un producto de manera aislada (Bevan, 1994).

La norma ISO/IEC 9126 está enfocada a la calidad de Producto y consta de las siguientes partes:

Parte 1: Modelo de Calidad

Parte 2: Métricas externas

Parte 3: Métricas internas

Parte 4: Calidad en el uso de métricas

La especificación y la evaluación de la calidad de producto de software se puede conseguir definiendo características de calidad apropiadas, tomando en cuenta el objetivo de uso del producto de software. 

4.7 Analisis de factores que determinan la calidad de software

Factores que determinan la calidad del software

• Se pueden clasificar en dos grandes grupos (Pressman):

• Factores que pueden ser medidos directamente
• Factores que solo pueden ser medidos indirectamente

• Se centran en tres aspectos importantes de un producto software (McCall):

• Características operativas
• Capacidad de soportar los cambios
• Adaptabilidad a nuevos entornos

Características operativas

• Corrección. ¿Hace lo que quiero?
• Fiabilidad. ¿Lo hace de forma fiable todo el tiempo?
• Eficiencia. ¿Se ejecutará en mi hardware lo mejor que pueda?
• Seguridad (Integridad). ¿Es seguro?
• Facilidad de uso. ¿Está diseñado para ser usado?

Capacidad de soportar los cambios

• Facilidad de mantenimiento. ¿Puedo corregirlo?
• Flexibilidad. ¿Puedo cambiarlo?
• Facilidad de prueba. ¿Puedo probarlo?

Adaptabilidad a nuevos entornos

• Portabilidad. ¿Podré usarlo en otra máquina?
• Reusabilidad. ¿Podré reutilizar alguna parte del software?
• Interoperabilidad. ¿Podré hacerlo interactuar con otro sistema?

4.8 Análisis del proceso del ciclo de vida del software

Definición de un Modelo de Ciclo de Vida

Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transición asociadas entre estas etapas.

Un modelo de ciclo de vida del software:

·         Describe las fases principales de desarrollo de software.

·         Define las fases primarias esperadas de ser ejecutadas durante esas fases.

·         Ayuda a administrar el progreso del desarrollo, y

·         Provee un espacio de trabajo para la definición de un detallado proceso de desarrollo de software.

Así, los modelos por una parte suministran una guía para los ingenieros de software con el fin de ordenar las diversas actividades técnicas en el proyecto, por otra parte suministran un marco para la administración del desarrollo y el mantenimiento, en el sentido en que permiten estimar recursos, definir puntos de control intermedios, monitorear el avance, etc.

Alternativas de Modelos de Ciclo de Vida

Modelo Cascada

Este es el más básico de todos los modelos, y sirve como bloque de construcción para los demás modelos de ciclo de vida. La visión del modelo cascada del desarrollo de software es muy simple; dice que el desarrollo de software puede ser a través de una secuencia simple de fases. Cada fase tiene un conjunto de metas bien definidas, y las actividades dentro de una fase contribuye a la satisfacción de metas de esa fase o quizás a una subsecuencia de metas de la fase. Las flechas muestran el flujo de información entre las fases. La flecha de avance muestra el flujo normal. Las flechas hacia atrás representan la retroalimentación.

El modelo de ciclo de vida cascada, captura algunos principios básicos:

·         Planear un proyecto antes de embarcarse en él.

·         Definir el comportamiento externo deseado del sistema antes de diseñar su arquitectura interna.

·         Documentar los resultados de cada actividad.

·         Diseñar un sistema antes de codificarlo.

·         Testear un sistema después de construirlo.

Una de las contribuciones más importantes del modelo cascada es para los administradores, posibilitándoles avanzar en el desarrollo, aunque en una escala muy bruta.

Modelo De Desarrollo Incremental

Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes. Una forma de reducir los riesgos es construir sólo una parte del sistema, reservando otros aspectos para niveles posteriores. El desarrollo incremental es el proceso de construcción siempre incrementando subconjuntos de requerimientos del sistema. Típicamente, un documento de requerimientos es escrito al capturar todos los requerimientos para el sistema completo.

Note que el desarrollo incremental es 100% compatible con el modelo cascada. El desarrollo incremental no demanda una forma específica de observar el desarrollo de algún otro incremento. Así, el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo, como se muestra en la figura.

El modelo de desarrollo incremental provee algunos beneficios significativos para los proyectos:

·         Construir un sistema pequeño es siempre menos riesgoso que construir un sistema grande.

·         Al ir desarrollando parte de las funcionalidades, es más fácil determinar si los requerimientos planeados para los niveles subsiguientes son correctos.

·         Si un error importante es realizado, sólo la última iteración necesita ser descartada.

·         Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del sistema) decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo.

·         Si un error importante es realizado, el incremento previo puede ser usado.

·         Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del próximo incremento.

Modelo De Desarrollo Evolutivo

Como el modelo de desarrollo incremental, el modelo de desarrollo evolutivo (algunas veces denominado como prototipado evolutivo) construye una serie de grandes versiones sucesivas de un producto. Sin embargo, mientras que la aproximación incremental presupone que el conjunto completo de requerimientos es conocido al comenzar, el modelo evolutivo asume que los requerimientos no son completamente conocidos al inicio del proyecto.

En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y sólo esos que son bien comprendidos son seleccionados para el primer incremento. Los desarrolladores construyen una implementación parcial del sistema que recibe sólo estos requerimientos.

El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentación a los desarrolladores.

 Basada en esta retroalimentación, la especificación de requerimientos es actualizada, y una segunda versión del producto es desarrollada y desplegada.

El modelo espiral de los procesos software es un modelo del ciclo de meta-vida. En este modelo, el esfuerzo de desarrollo es iterativo. Tan pronto como uno completa un esfuerzo de desarrollo, otro comienza. Además, en cada desarrollo ejecutado, puedes seguir estos cuatros pasos:

  Determinar qué quieres lograr.

  Determinar las rutas alternativas que puedes tomar para lograr estas metas. Por cada una, analizar los riesgos y resultados finales, y seleccionar la mejor.

  Seguir la alternativa seleccionada en el paso 2.

  Establecer qué tienes terminado.

 

La dimensión radial en la figura refleja costos acumulativos incurridos en el proyecto.

Modelo Concurrente

Como el modelo espiral, el modelo concurrente provee una meta-descripción del proceso software. Mientras que la contribución primaria del modelo espiral es en realidad que esas actividades del software ocurran repetidamente, la contribución del modelo concurrente es su capacidad de describir las múltiples actividades del software ocurriendo simultáneamente.

Esto no sorprende a nadie que ha estado involucrado con las diversas actividades que ocurren en algún tiempo del proceso de desarrollo de software. Discutamos un poco tales casos:

Los requerimientos son usualmente "líneas de base", cuando una mayoría de los requerimientos comienzan a ser bien entendidos, en este tiempo se dedica un esfuerzo considerable al diseño. Sin embargo, una vez que comienza el diseño, cambios a los requerimientos son comunes y frecuentes (d

espués de todo, los problemas reales cambian, y nuestro entendimiento de los problemas desarrollados también). Es desaconsejado detener el diseño en este camino cuando los requerimientos cambian; en su lugar, existe una necesidad de modificar y rehacer líneas de base de los requerimientos mientras progresa el diseño. Por supuesto, dependiendo del impacto de los cambios de los requerimientos el diseño puede no ser afectado, medianamente afectado o se requerirá comenzar todo de nuevo.

Durante el diseño de arquitectura, es posible que algunos componentes comiencen a ser bien definidos antes que la arquitectura completa sea estabilizada. En tales casos, puede ser posible comenzar el diseño detallado en esos componentes estables. 

4.9 Funciones de evaluación del software

1.Calidad en la operación del producto.Requiere que el software pueda ser entendido fácilmente, que opere eficientemente y que los resultados obtenidos sean los requeridos inicial-mente por el usuario.

2.Revisión de la calidad del producto de software.Tiene como objetivo realizar revisiones durante el proceso de desarrollo para detectar los errores que afecten a la operación del producto.

3.Calidad en el proceso.Requiere de la definición de estándares y procedimientos que sirvan como base para el desarrollo del software