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.
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
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
