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.
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
Conclusión
Es necesario que una empresa tenga
calidad en el software ya que nos permite el no tener errores si se hace de la
manera correcta. También no solo es para la empresa si no para nosotros mismos así
nos evitaremos el estar haciendo las cosas una y otra vez.
Es necesario en una empresa cuente
con una norma iso ya que esta tendrá mas valor por su certificación y es mas
reconocible de igual manera hay distintos tipos de normas en las que una
empresa se puede certificar ya que la calidad es dar el 100% de un producto o
servicio.
Iso se encarga de sacar normas
las cuales sean adaptables para cualquier empresa del mundo y asi que sea un
mismo estándar para todos, Calidad del software es el desarrollo de software
basado en estándares con la funcionalidad y rendimiento total que satisfacen
los requerimientos del cliente.
REFERENCIAS
No hay comentarios:
Publicar un comentario