Garantía de calidad estadística

Refleja una tendencia, creciente en toda la industria, a establecer la calidad mas cuantitativamente. Para el software, la garantía de calidad estadística  implica los siguientes pasos.

• Se agrupa y se clasifica la información sobre los defectos del software
• Se intenta encontrar la causa subyacente de cada defecto (por ejemplo, no concordancia con la especificación, errores de diseño, incumplimiento de los estándares, pobre comunicación con el cliente).
• Mediante el principio de Pareto (el 80 por 100 de los defectos se pueden encontrar en el 20 por 100 de todas la causas posibles), se aísla el 20 por 100 (<<>los pocos vitales>)
• Una vez que se han identificado los defectos vitales, se actúa para corregir los problemas que han producido los defectos

Este concepto relativamente sencillo representa un paso importante hacia la creación  de un proceso  de ingeniería del software adaptivo en el cual se realizan cambios para mejorar aquellos elementos del proceso que introducen errores.

Para ilustrar el proceso, supongamos que una organización de desarrollo de software recoge información sobre defectos durante un período de un año. Algunos de los defectos se descubren mientras se desarrolla el software. Otros se encuentran después de que el software se haya distribuido al usuario final. Aunque se descubren cientos de errores diferentes, todos se pueden encontrar en una (o más) de las siguientes causas:

 

• Especificación incompleta o errónea (EIE).
• Mala interpretación de la comunicación del cliente (MCC).
• Desviación deliberada de la especificación (DDE).
• Incumplimiento de los estándares de programación (IEP).
• Error en la representación de los datos (ERD).
• Interfaz de módulo inconsistente (IMI).
• Error en la lógica de diseño (ELD).
• Prueba incompleta o errónea (PIE).
• Documentación imprecisa o incompleta (DII).
• Error en la traducción del diseño al lenguaje de programación (TLP).
• Interfaz hombre-máquina ambigua o inconsistente (IHM).
• Varios (VAR).

Para aplicar la SQA estadística se construye una tabla. La tabla indica que EIE, MCC y ERD son las causas vitales que contabilizan el 53 por 100 de todos los errores. Sin embargo, debe observarse que si sólo se consideraran errores serios, se seleccionarían las siguientes causas vitales: EIE, ERD, TLP y ELD. Una vez determinadas las causas vitales, la organización de desarrollo de software puede comenzar la acción correctiva. Por ejemplo, para corregir la MCC, el equipo de desarrollo

del software podría implementar técnicas que facilitaran la especificación de la aplicación para mejorar la calidad de la especificación y la comunicación con el cliente. Para mejorar el ERD, el equipo de desarrollo del software podría adquirir herramientas CASE para la modelización de datos y realizar revisiones del diseño de datos más rigurosas.

Es importante destacar que la acción correctiva se centra principalmente en las causas vitales. Cuando éstas son corregidas, nuevas candidatas saltan al principio de la lista.

Se han mostrado las técnicas de garantía de calidad del software estadísticas para proporcionar una mejora sustancial en la calidad [ART97]. En algunos casos, las organizaciones de software han conseguido una reducción anual del 50 por 100 de los errores después de la aplicación de estas técnicas.

La aplicación de la SQA estadística y el principio de Pareto se pueden resumir en una sola frase: ¡Utilizar el tiempo para centrarse en cosas que realmente interesan, pero primero asegurarse que se entiende qué es lo que realmente interesa!

 

La tendencia de la calidad y garantía de la calidad del software

Tendencia de la calidad.

Comenzó en los años 40 con el trabajo de W. Edwars Deming, se hizo la primera verificación en Japón para la eliminación de las causas raíz de defectos de productos. En los años 80 emigro a occidente y a veces se llama (GTC) gestión total de calidad, normalmente se encuentra una progresión básica de 4 pasos que es el fundamento de cualquier programa.

• El primero llamado Kuizen se refiere a un sistema de mejora continua del proceso, su objetivo es desarrollar un proceso mensurable
• El segundo se llama Aturimae Hinshitsu examina los problemas invisibles por los que pueda o esta atravesando el proceso, este segundo paso se encarga de trabajar para optimizar su impacto en el proceso, puede sugerir cambios en la forma en que ocurre la reorganización de una Organización.
• El siguiente paso llamado kansei se centra principalmente en el usuario del producto, conduce a la mejora del producto y potencialmente al proceso que lo creo.
• El último paso llamado miryokuteki  hinshitsu orientado específicamente a la gestión, se encarga de ver cómo funciona el producto en el mercado.

Mapa mental «La tendencia de la calidad»

Garantía de la Calidad del Software

Concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente documentado, y con las características implícitas que se espera de todo  software desarrollado profesionalmente.

Esta definición sirve para hacer hincapié en tres puntos importantes.

1. Los requisitos del software son la base de las medidas de la calidad. La falta de concordancia con los requisitos es una falta de calidad.
2. Los estándares especificados definen un conjunto de criterios de desarrollo que guía la forma en que se aplica la Ingeniería del Software
3. Existe un conjunto de requisitos implícitos que a menudo no se menciona. Si el software se ajusta a sus requisitos  explícitos pero falta en alcanzar los requisitos implícitos, la calidad del software queda en entredicho

Durante los primeros años de la informática (los años cincuenta y sesenta), la calidad era responsabilidad únicamente del programador, durante los años setenta si introdujeron estándares de garantía de calidad para el software con los contratos militares y se han extendido rápidamente a los desarrollos de software en el mundo comercial

Actividades de SQA.

Establecimiento de un plan de SQA para un proyecto.

Se desarrolla durante la planificación del proyecto y es revisado por las partes interesadas, están gobernadas por un plan. El plan identifica.

• Evaluaciones a realizar
• Auditorias y revisiones a realizar
• Estándares que se puedan aplicar al proyecto
• Procedimiento para información y seguimiento de errores
• Documentos producidos por SQA
• Realimentación de información proporcionada al equipo de proyecto de software.

Participación en el desarrollo de la descripción del proceso del software del proyecto

El equipo de ingeniera del software selecciona un proceso para el trabajo que se va a realizar. El grupo de SQA revisa la descripción del proceso para ajustarse a las políticas de la empresa, los estándares internos del software y los estándares externos

Revisión de las actividades de ingeniera del software para verificar su ajuste al proceso de software definido.

El grupo de SQA identifica, documenta y sigue las pistas de las desviaciones desde el proceso y verifica que se han hecho las correcciones

Auditoria de los productos de software designados para verificar el ajuste con los definidos como parte del proceso de software

El grupo SQA revisa los productos seleccionados, identifica, documenta y sigue las pistas de las desviaciones, verifica que se han hecho las correcciones, e informa periódicamente de los resultados de su trabajo al gestor del proyecto

Asegurar que las desviaciones del trabajo y los productos del software se documentan y se manejan de acuerdo con un procedimiento establecido

Las desviaciones se pueden encontrar en el plan del proyecto, en la descripción del proyecto, en los estándares aplicados o en los productos técnicos.

Registrar lo que no se ajuste a los requisitos e información as sus superiores.

Los elementos que no se ajusten a los requisitos están bajo seguimiento hasta que se resuelva.

Mapa mental «Garantía de la calidad del software»

 

 

Estándar de calidad ISO

El estándar que ha sido adoptada por mas de 130 países se está convirtiendo en el medio principal con el que los clientes pueden juzgar la competencia de un desarrollador de software. Uno de los problemas con el estándar ISO 9001 está en que no es específico de la industria: está expresado en términos generales, y puede ser interpretado por los desarrolladores de diversos productos como cojinetes de bolas, secadores de pelo, automóviles, asi como por los desarrolladores de software.

Para la industria del software los estándares relevantes son:

• ISO 9001: este es un estándar que describe el sistema de calidad utilizado para mantener el desarrollo de un producto que implique diseño.
• ISO 9000-3: este es un documento específico que interpreta el ISO 9001 para el desarrollador de software.
• ISO 9004-2: este documento proporciona las directrices para el servicio de facilidades del software como soporte de usuarios.

ISO 9001 PRINCIPIOS DE LA NORMA DE CALIDAD

• Organización enfocada a los clientes.
• Liderazgo.
• Compromiso De Todo El Personal.
• Enfoque A Procesos.
• Enfoque Del Sistema Hacia La Gestión.
• La Mejora Continua.
• Enfoque Objetivo Hacia La Toma De Decisiones.
• Relaciones Mutuamente Beneficiosas Con Los Proveedores
  

Certificabilidad.

Al igual que las antiguas ISO 9001, 9002 y 9003, la nueva ISO 9001:2000 establece los requisitos del sistema de gestión de la calidad, para su utilización como un medio de asegurar la conformidad de los productos y servicios, y puede ser utilizada con fines de certificación.

La nueva edición de la norma ISO 9004:2000 da recomendaciones sobre todos los aspectos de un sistema de gestión de la calidad, para mejorar las prestaciones de calidad globales de una organización. Sin embargo, no está destinada para su utilización como guía para cumplir con la norma ISO 9001.

fuente

http://www.monografias.com/trabajos59/calidad-software/calidad-software2.shtml

http://www.buscarportal.com/articulos/iso_9001_gestion_calidad.html.

 

Tecnicas de Prueba del Software

Pruebas de Caja Negra.

Se centra en los requisitos funcionales del software, permiten obtener un conjunto de condiciones de entrada que ejerciten completamente los requisitos funcionales del sistema. Se denominan pruebas funcionales, y el probador se limita a suministrarle datos como entrada y estudiar la salida, sin preocuparse lo que pueda estar haciendo el modulo por dentro (Internamente).

Ejemplo

Caso de Prueba	Calculo de Métricas y Puntos de Fusión para Cocomo
Propósito	Obtener los parámetro de medición y puntos de Fusión para Cocomo BASICO
Prerrequisitos	Ejecutar la aplicación
Datos de Entrada	Asignar Valor a las preguntas, rango del 1 al 5 Asignar valor a los parámetros de medición, para calculo simple, medio, complejo.
Pasos	Obtener el resultado de las preguntas. Obtener el valor de las Metricas, tanto simple, medio, complejo.
Resultado esperado	Punto de fusión Valor de Metricas.

Nombre Campo	Dato de Entrada	Acción esperada	Validación	Observación
Preguntas	Valor rango de 0-5	Obtener Resultado	True
Entrada	Enteros (números)	Calcular métricas	true
Entrada	Letras	Boton  Resultado activada	true	Validación Incorrecta
Salida	Caracteres especiales	Boton Resultado Activado	false	Resultado invalido

Prueba Caja Blanca.

• Usa la Estructura del Control del diseño procedimental, para obtener los casos de prueba.
• Estos casos se debe garantizar
• Que se ejercita por lo menos una vez todos los caminos independientes de cada módulo.
• Que se ejerciten todas las decisiones lógicas en sus vertientes verdadera y falsa.
• Que se ejecuten todos los bucles en sus límites operacionales.
• Que se ejerciten las estructuras internas de datos para asegurar su validez.

A continuación un ejemplo.

El algoritmo calculo el tempo de desarrollo,  esfuerzo, personal, lineas de codigo

A partir del diagrama de flujo se obtiene el grafo de flujo, que sirve como guía para definir el conjunto básico de caminos de ejecución.

El grafo permite observar los caminos básicos de ejecución del programa

• 1-2-3-4
• 1-2-3-5-6
• 1-2-3-5-7-8-9

El número de caminos también se puede calcular a través de la complejidad ciclomática:

V(G) = A + N – 2

Integracion Incremental

Las pruebas de integración se llevan a cabo durante la construcción del sistema, involucran a un número creciente de módulos y terminan probando el sistema como conjunto.

Prueba estructura de Control

Existen tres pruebas de estructura de condición, que son:

• Prueba de condición
• Prueba de estructura de datos
• Pruebas de estructuras de control (bucles).

Prueba de sanidad.

Determina si la nueva versión de un software está bien realizada y si necesita un nuevo esfuerzo en la prueba de software.

Por ejemplo la nueva versión de un programa cumple con casi todos los requisitos pero destruye la base de datos al leerla, por lo tanto se dice que este software no está en una condición sana.

Subversion- Instalación en Linux

Robert Loarte.

Subversión es un sistema de control de versiones, fundada en el 2000 por CollabNet, Inc., el proyecto Subversion y software a tenido un éxito increíble en la última década. Subversion ha gozado y sigue gozando de amplia adopcion, tanto en el campo de código abierto y en el mundo empresarial.

Una característica de Subversión es que, a diferencia de CVS, los archivos mencionados no tiene cada uno  un número de revisión independiente, en cambio,  todo el repositorio tiene un único número de versión que identifica un estado común de todos los archivos del repositorio en un instante determinado.

Como Funciona Subversion.

• Subversion se compone de un programa «servidor» y «cliente».
• El servidor contiene una copia maestra de la información a compartir.
• Los usuarios usan el cliente para descargar la información existente en el servidor.
• Cuando un usuario realiza un cambio, lo envía la servidor para que otros usuarios puedan descargarlo
• El servidor guarda los ficheros dentro de una base de datos (no son visibles en el sistema de ficheros)
• Al servidor online se lo llama repositorio, A cada cambio que recibe el repositorio se lo llama revision
• Para windows el mejor cliente es TortoiseSvn
• Para GNU/Linux, basta subversion, la versión para linea de comandos, o RapidSvn, una versión gráfica para entornos GTk

Ventajas y desventajas de subversion.

Ventajas.

• Se sigue la historia de los archivos y directorios a través de copias y renombrados.
• Las modificaciones (incluyendo cambios a varios archivos) son atómicas.
• Se envían sólo las diferencias en ambas direcciones (en CVS siempre se envían al servidor archivos completos).
• Permite selectivamente el bloqueo de archivos. Se usa en archivos binarios que, al no poder fusionarse fácilmente, conviene que no sean editados por más de una persona a la vez.
• Cuando se usa integrado a Apache permite utilizar todas las opciones que este servidor provee a la hora de autentificar archivos (SQL, LDAP, PAM).
• Consume pocos recursos.

Desventajas.

• La principal desventaja de Subversion es que es más lento que CVS y que una verificación local de Subversion requiere mayor espacio en disco.
• El manejo de cambio de nombres de archivos no es completo. Lo maneja como la suma de una operación de copia y una de borrado.
• El manejo de archivos binarios los trata internamente como si fuera de texto no como de Subversion.

Como Instalar Subversion.

Instalación de Subversion en Linux.

1. Instalar un servidor LAMPP.

sudo apt-get apache2 php5-mysql libapache2-mod-php5 mysql-server

2.  Instalar Subversion.

sudo apt-get install subversion libapache2-svn.

3.  Crear un Repositorio

sudo svnadmin create /svn

4.  Configurar el módulo webdav

Editar el archivo de configuración del módulo webdav del apache. Utilize su editor favorito, en este caso se utiliza nano.

sudo nano /etc/apache2/mods-enabled/dav_svn.conf.

El archivo debería quedar como sigue:

<Location /svn>
DAV svn
SVNPath /svn
AuthType Basic
AuthName “Subversion Repository”
AuthUserFile /etc/apache2/dav_svn.passwd
</Location>

5. Crear un usuario en SVN

Para crear un usuario en el reposotorio utilize el siguiente comando:

sudo htpasswd -cm /etc/apache2/dav_svn.passwd.

6. Reiniciar Apache.

sudo /etc/init.d/apache2 restart.

Ahora puede apuntar con el browser a http://www.server/svn, debería ver que el depósito está habilitado para el acceso de lectura anónima, pero se comprometen que el acceso exige un nombre de usuario.

Como crear repositorios.

Se localiza el fichero dav_svn.conf. Lo vamos a editar para hacer alguna modificaciones para crear un repositorio llamado pruebas.

Localizamos las lines donde se define el repositorio por defecto SVN.

# <Location URL> ... </Location>
# URL controls how the repository appears to the outside world.
# In this example clients access the repository as http://hostname/svn/
#<Location /svn> %modificamos la linea y cambiamos el nombre de repositorio pruebas.

——————————————-

# <Location URL> ... </Location>
# URL controls how the repository appears to the outside world.
# In this example clients access the repository as http://hostname/svn/
<Location /pruebas>

———————————————————————-

Tal y como indica, descomentamos para activar el repositorio:

# Uncomment this to enable the repository,
# DAV svn

Asi

# Uncomment this to enable the repository,
#DAV svn

Modificamos también las líneas:

# Set this to the path to your repository
# SVNPath /var/lib/svn

Para establecer el path del repositorio:

# Set this to the path to your repository
SVNPath /var/lib/svn/pruebas

Inicialmente comentaremos las siguientes líneas para desactivar la seguridad:

<LimitExcept GET PROPFIND OPTIONS REPORT>
  Require valid-user
</LimitExcept>

No olvidemos descomentar la última línea. Ya que es donde termina el repositorio.

</Location>

Como somos muy ordenados, queremos crear un repositorio por cada proyecto. Así será más sencillo gestionar las políticas de seguridad. Todos estos repositorios se van a crear dentro del directorio /var/lib/svn por lo que tenemos que crearlo previamente.

$ sudo mkdir /var/lib/svn

Ahora tenemos que crear el repositorio en sí:

$ sudo svnadmin create /var/lib/svn/pruebas

Aunque no es estrictamente necesario, vamos a crear los directorio trunk, tags y branches que servirán para almacenar el código actual, los tag y las posibles ramas que pueda tener nuestro proyecto:

$ sudo svn mkdir --message="Setting up the directories..." \
  file:///var/lib/svn/pruebas/trunk \
  file:///var/lib/svn/pruebas/tags \
  file:///var/lib/svn/pruebas/branches

Dado que vamos a acceder a este repositorio a través de apache, tendremos que asignarle el propietario adecuado:

$ sudo chown www-data:www-data  /var/lib/svn/pruebas -R

Sólo nos queda reiniciar el servidor Apache para que vuelva a leer la configuración actualizada:

$ sudo /etc/init.d/apache2 restart.

Si abres un navegador y accedes a http://localhost/pruebas podrás ver el contenido del repositorio pruebas.

Como crear Usuarios_Permiso

Usuario:

• Para crear el primer usuario, ejecute (cambie <usuario> por el nombre de usuario a crear) :sudo htpasswd -c /etc/subversion/passwd <usuario>
• A continuacion suministre la clave asignada al usuario
• Para crear el segundo utilice el mismo comando pero sin la opcion -c
  sudo htpasswd /etc/subversion/passwd <usuario>.

Permisos.

Para añadir los usuarios con permisos de acceso a nuestro repositorio los añadimos al grupo svn de la siguiente forma:

usermod -G svn juan

Para que el subversion pueda gestionar las credenciales de los usuarios creamos el fichero /etc/apache2/dav_svn.passwd que anteriormente habilitamos en el fichero de configuración del repositorio dav_svn.conf (nos pedirá introducir la contraseña para el usuario):

1. htpasswd -c /etc/apache2/dav_svn.passwd juan
2. New password:
3. Re-type new password:
4. Adding password for user juan

Principales comandos.

• svn import
• trunk linea pricipal de desarrollo
• branches. directorio para albergar ramas alternativas de desarrollo
• tags directorio con versiones etiquetadas.
• checkout
• svn update actualiza tu copia local
• svn add
• svn delete
• svn copy
• svn move
• svn commit publicar los cambi0s en el repositorio.

Fuente importante

• http://www.guia-ubuntu.org/index.php?title=Subversion
• http://www.dagorret.com.ar/2009/10/30/tecnologia/como-instalar-subversion-en-linux/

 

 

Garantía de calidad del software

Calidad

La calidad es el grado de relación que tiene el producto para satisfacer las necesidades del usuario. Un software que cumple con todos los requisitos con su usuario, y que sus procesos se ejecuten correctamente, la cual garantiza una buena Calidad. Hay que recordar que no todos es perfecto y no se puede llegar a tener un software de calidad total, sino un software de calidad. Debe de cumplir  estándares como la norma ISO 9001.

Existen dos tipos de calidad.

1. Calidad de Diseño: Son características que especifican los ingenieros del software. Lo que contribuye a la calidad del diseño son el Grado de Materiales, tolerancia y las especificaciones del rendimiento, esto permite que la calidad del diseño aumente.
2. Calidad de Concordancia: Se cumplen las especificaciones del diseño, cuando mayor sea el grado de cumplimiento más alto será el nivel de calidad de concordancia, se centra principalmente en la implementación.

La tendencia de la Calidad

Comenzó en los años 40 con el trabajo de W. Edwars Deming, normalmente se encuentra una progresión básica de 4 pasos que es el fundamento de cualquier programa.

El primero llamado Kuizen se refiere a un sistema de mejora continua del proceso, su objetivo es desarrollar un proceso mensurable

El segundo se llama Aturimae Hinshitsu examina los problemas invisibles por los que pueda o esta atravesando el proceso, este segundo paso se encarga de trabajar para optimizar su impacto en el proceso.

El siguiente paso llamado kansei se centra principalmente en el usuario del producto, conduce a la mejora del producto y potencialmente al proceso que lo creo.

El último paso llamado miryokuteki  hinshitsu orientado específicamente a la gestión, se encarga de ver cómo funciona el producto en el mercado.

Garantía de la Calidad del Software

Es una actividad de protección, que se aplica a lo largo de todo el proceso del software (Control de procesos), en definitiva abarca todo el desarrollo de software, análisis, diseño, control de código fuente, revisiones de código etc… La garantía de la calidad del software (SQA) es un patrón de acciones planificado y sistemático que se requieren para asegurar la calidad del software.

La garantía de la calidad del software  comprende una gran variedad de tares, los ingenieros de software que realiza trabajo técnico y un grupo de SQA que tiene la responsabilidad de la planificación de garantía de calidad, supervision mantenimiento de registro, análisis e informe

Revisiones de Software

Es un filtro la cual permite detectar errores y fallas para que puedan ser así eliminados, se reúne una persona o un equipo de trabajo la cual se examina el software profundamente.

Variedades de revisión del software

• Revisiones de par de software: son conducidos por el autor del producto o algunos colegas para evaluar el producto
• Revisiones de la gerencia de Software: Son conducidos por los representantes de la gerencia para evaluar el estado del trabajo.
• Revisiones de la intervención del software: Son conducidos por el personal externo al proyecto de software para evaluar conformidad con especificaciones y estándares.

Diversos tipos de Revisiones.

• Revisión de código
• Programación de grupo par.
• Inspección
• Revisión Técnica

Revisiones Técnicas formales

Es el filtro más efectivos desde el punto de vista de la garantía de la calidad, es un medio efectivo para mejorar la calidad, llevado a cabo por los ingenieros del software, su objetivo es descubrir errores en la función lógica, que alcance con sus requisitos, que tenga ciertos estándares predefinidos, hacer que los proyectos sean manejables, solo tendrá éxito si es bien planificada, controlada y atendida, las revisiones técnicas formales se centra en partes especifica no en proyectos completos se centra específicamente por modulo o grupo de modulo en estas circunstancias se puede descubrir o tener más probabilidad de descubrir errores.

Fiabilidad del Software

Se trata de medidas estadísticas, en la que se mide el tiempo de funcionamiento del software sin fallos en un determinado ambiente, de tal  manera que satisfaga las necesidades de los usuarios y cumpla con sus objetivos. Si el programa es propenso a fallos no es fiable,  los fallos se producen por falta de concordancia con los requisitos del software, en las que se pueden clasificar de ser simplemente desconcertantes o catastróficos, por ejemplo un fallo puede ser corregido en segundos mientras otros pueden tardar meses.

Los fallos se pueden dar tanto en el software como el hardware. En el hardware son más probables los fallos por ser físico están propensos a polvo, desgaste físico, efecto de la temperatura del ambiente, corrosión etc.

Los fallos en el software son totalmente diferentes estos se dan por una mala implementación o diseño, que incluye directamente al cliente y al programador o analista ejemplo omitir un requerimiento especificado por el cliente o comprender mal requerimiento especifico.

Se mide la fiabilidad del software con la formula siguiente.

TMEF=TMDF+TMDR

Dónde: TMDF corresponde a tiempo medio de fallos, TMDR tiempo medio de separación.

Prueba de errores para el software

En los años 60, un ingeniero industrial japonés desarrollo una técnica de garantía de la calidad, en la que su objetivo era la prevención y/o corrección de errores en el proceso de fabricación. Fue denominado poku yoke, estos son dispositivos que conducen a la prevención de un problema potencial antes de que ocurra y a la rápida detección de problemas de calidad si  ya se han producido.

Un dispositivo Poku Yoke presenta un conjunto de características comunes,

• Es simple y barato
• Es parte del proceso
• Esta localizado cerca de la tarea del proceso donde están ocurriendo los errores.

En fin esta técnica (Poka yoke) puede ser implementado en el uso de la Ingeniería del Software, a través de pequeños Scripts en el cual se ejecuta sobre las aplicaciones para detectar fallos, esta técnica puede aplicarse a los niveles de diseño, codificación y pruebas y proporciona un filtro efectivo de garantía de la calidad

El estándar de calidad ISO 9001

Es un conjunto de normas para la calidad y gestión, es cada vez el más importante estándar internacional, ha sido adoptado por más de 130 países alrededor del mundo, en  la cual los usuarios pueden juzgar la competencia de un desarrollo de software.

La desventaja es que el ISO 9001 no es un estándar específico para el desarrollo de software, pero define principios generales que pueden aplicarse al software, el estándar ISO 9001 no define los procesos de calidad que deben usarse.

Para la industria del software los estándares relevantes son.

• ISO 9001 desarrollo de un producto que implique diseño
• ISO 9000-3 es un documento específico que interpreta el ISO 9001 para el desarrollo de software
• ISO 9004-2 proporciona directrices para el servicio de facilidades del software como soporte de usuario

Analisis y Gestion de Riesgos

¿Qué es la identificación de un riesgo y cuál es su clasificación?

Es un intento sistemático para especificar las amenazas  al plan del proyecto (estimaciones, planificación temporal, carga de recursos etc…), identificando los riesgos conocidos y predecibles el gestor del proyecto da un paso adelante para evitarlos cundo sea posible y controlarlos cuando sea necesario.

Su clasificación.

Riesgos genéricos y Riesgos  específicos del producto

¿Cuál es la evaluación global del riesgo del proyecto, los componentes y controladores del riesgo?

Las siguientes preguntas provienen  de los datos del riesgo obtenido s mediante las encuestas realizadas  a gestores de proyectos de software de diferentes partes del mundo.

1. ¿Se han entregado los gestores del software y clientes formalmente para dar soporte al proyecto?
2. ¿Están completamente entusiasmados los usuarios finales con el proyecto y con el sistema/producto a construir?
3. ¿Han comprendido el equipo de ingenieros de software y los clientes todos los requisitos?
4. ¿Han estado los clientes involucrados por completo en la definición de los requisitos?
5. ¿Tienen los usuarios finales expectativas realistas?
6. ¿Es estable el ámbito del proyecto?
7. ¿Tiene el Ingeniero de Software el conjunto adecuado de habilidades?
8. ¿Son estables los requisitos del Proyecto?
9. ¿Tiene experiencia el equipo del proyecto con la tecnología a implementar?
10. ¿Es adecuado el número de personas del equipo del proyecto para realizar el trabajo?
11. ¿Están de acuerdo todos los clientes/usuarios en la importancia del proyecto y en los requisitos del sistema/ producto a construir?

Componentes del Riesgo

• Riesgo de rendimiento: el grado de incertidumbre con el que el producto encontrará sus requisitos y se adecue para su empleo pretendido.
• Riesgo de coste: el grado de incertidumbre que mantendrá el presupuesto del proyecto.
• Riesgo de soporte: el grado de incertidumbre de la facilidad del software para corregirse, adaptarse y ser mejorado.
• Riesgo de la planificación temporal: el grado de incertidumbre con que se podrá mantener la planificación temporal y de que el producto se entregue a tiempo.

Controladores

El impacto de cada controlador del riesgo en el componente de riesgo se divide en cuatro categorías de impacto

• Despreciable
• Marginal
• Crítico
• Catastrófico

¿Cómo se realiza la estimación del riesgo?

Intenta medir cada riesgo de dos maneras, la probabilidad de que el riesgo sea real y las consecuencias de los problemas asociados con el riesgo, si ocurriera.  El jefe del proyecto junto con otros gestores y personal técnico realiza cuatro actividades de proyección del riesgo

1. Establecer una escala que refleje la probabilidad percibida del riesgo
2. Definir las consecuencias del riesgo
3. Estimar el impacto del riesgo en el proyecto y en el producto
4. Apuntar la exactitud general de la proyección del riesgo de manera que no haya confusiones

¿Cuáles son los beneficios de realizar una estimación de proyectos?

El desarrollo de una tabla de riesgo le proporciona al jefe del proyecto una sencilla técnica para la proyección del riesgo, la cual permite categorizar los riesgos (riesgo del tamaño del proyecto o riesgo del negocio), cada miembro evalúa la probabilidad de cada riesgo y se valora el impacto de cada riesgo.

Los riesgos de alta probabilidad  y de alto impacto pasan a lo alto de la tabla y los riesgos de baja prioridad están por debajo de la tabla. Esto consigue una priorización de riesgos de primer orden.