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:
· Inspecciones técnicas formales en todos los pasos del proceso de
desarrollo del software.
· Estrategias de prueba multiescala.
· Control de la documentacion 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 metodos 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
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
No hay comentarios:
Publicar un comentario