lunes, 10 de enero de 2011

TECNICAS DE PRUEBA DEL SOFTWARE


Se trata de diseñar pruebas que tengan  la mayor probabilidad de encontrar el  mayor número de errores con la mínima cantidad de esfuerzo y de tiempo. 

 •  Pruebas de caja negra: Realizar pruebas de forma que se  compruebe que cada función es operativa.
Las pruebas de caja negra se llevan a cabo sobre la interfaz del software,obviando el comportamiento interno y la estructura del programa.  

Los casos de prueba de la caja negra pretenden demostrar que: 

         Las funciones del software son operativas
•     La entrada se acepta de forma correcta
•     Se produce una salida correcta
         La integridad de la información externa se mantiene 

Las pruebas de caja negra pretenden encontrar estos tipos de errores:
• Funciones incorrectas o ausentes
• Errores en la interfaz
• Errores en estructuras de datos o en accesos a bases de datos externas
• Errores de rendimento
• Errores de inicialización y de terminación


En este caso al realizar la técnicas de prueba del cocomo básico tenemos que tomar en cuenta cada una de las funciones operativas del software. Analizar cada uno de los errores que se pueden presentar en los diferentes campos: los atributos, factores de peso, el tipo del proyecto, cada uno de estos  deben estar controlados para evitar inconvenientes posteriores, estos permitirán ingresar únicamente datos con los que puede trabajar el software.

•  Pruebas de caja blanca: Desarrollar pruebas de forma que se asegure que la operación interna se ajusta a las especificaciones, y  que todos los componentes internos se han probado de forma adecuada.
En la prueba de la caja negra, los casos de prueba pretenden demostrar que las funciones del software son operativas, que la entrada se acepta de forma adecuada y que se produce una salida correcta.
En la prueba de caja blanca se realiza un examen minucioso de los detalles procedimentales, comprobando los  caminos lógicos del programa, comprobando los bucles y condiciones, y examinado el estado del programa en varios puntos.
 A primera vista, la prueba de caja blanca profunda nos llevaría a tener "programas 100 por cien correctos", es decir: 

• Definir todos los caminos lógicos
• Desarrollar casos de prueba para todos los caminos lógicos
• Evaluar los resultados 

La prueba de la caja blanca es un método de diseño de casos de prueba que usa la estructura de control del diseño procedimental para derivar los casos de prueba.




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

Luego del análisis se requiere adicionar nuevos requerimientos como agregar al software la posibilidad de agregar estimaciones de manera intermedia y avanzada, y no solo básico.




sábado, 8 de enero de 2011

SUBVERSION

QUE ES SUBVERSION?

Subversion es un sistema de control de versiones diseñado específicamente para reemplazar al popular CVS. Es software libre bajo una licencia de tipo Apache/BSD y se le conoce también como svn por ser el nombre de la herramienta utilizada en la línea de órdenes.
Una característica importante de Subversion es que, a diferencia de CVS, los archivos versionados no tienen 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.
Subversion puede acceder al repositorio a través de redes, lo que le permite ser usado por personas que se encuentran en distintos ordenadores. A cierto nivel, la posibilidad de que varias personas puedan modificar y administrar el mismo conjunto de datos desde sus respectivas ubicaciones fomenta la colaboración. Se puede progresar más rápidamente sin un único conducto por el cual deban pasar todas las modificaciones. Y puesto que el trabajo se encuentra bajo el control de versiones, no hay razón para temer por que la calidad del mismo vaya a verse afectada, si se ha hecho un cambio incorrecto a los datos, simplemente ese cambio se lo deshace.

CÓMO FUNCIONA

  • Subversion se compone de un programa "servidor" y otro "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 al 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).
VENTAJAS

  • Se sigue la historia de los archivos y directorios a través de copias y renombrados.
  • Registra cambios en la estructura de directorios (permite mover y renombrar sin perder el historial). Subversion no usa RCS, sino un sistema virtual de ficheros versionado sobre una base de datos
*       Las modificaciones (incluyendo cambios a varios archivos) son atómicas.
*       La creación de ramas y etiquetas es una operación más eficiente. Tiene costo de complejidad constante (O(1)) y no lineal (O(n)) como en CVS.
*       Se envían sólo las diferencias en ambas direcciones (en CVS siempre se envían al servidor archivos completos).
*       Puede ser servido mediante Apache, sobre WebDAV/DeltaV. Esto permite que clientes WebDAV utilicen Subversion de forma transparente.
*       Maneja eficientemente archivos binarios (a diferencia de CVS que los trata internamente como si fueran de texto).
*       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, etc.).

DESVENTAJAS

*       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.
*       No resuelve el problema de aplicar repetidamente parches entre ramas, no facilita llevar la cuenta de qué cambios se han realizado. Esto se resuelve siendo cuidadoso con los mensajes de commit.

COMO INSTALAR SUBVERSION ?

*       Hay versiones para Windows y cualquier sistema basado en Unix.
*       Puede instalarse como servidor independiente o como módulo de Apache.
*       Consume pocos recursos.
*       Una instalación básica solo requiere conocimientos a nivel de usuario del sistema operativo.
LINUX
Para realizar la instalación seguimos los siguientes pasos:
Paso 1 – Instalar un servidor LAMPP
sudo apt-get apache2 php5-mysql libapache2-mod-php5 mysql-server
Paso 2 –
Instalar Subversion
sudo apt-get install subversion libapache2-svn
Paso 3 –
Crear un repositorio
Create the subversion repository in /svn
sudo svnadmin create /svn
Paso 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 yo utilizo nano.
sudo nano /etc/apache2/mods-enabled/dav_svn.conf
El archivo debería quedar como sigue:
DAV svn
SVNPath /svn
AuthType Basic
AuthName “Subversion Repository”
AuthUserFile /etc/apache2/dav_svn.passwd
Grabe el archivo.
Paso 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
Ejemplo:
sudo htpasswd -cm /etc/apache2/dav_svn.passwd geek
New password:
Re-type new password:
Adding password for user geek
Paso 6 –
Reiniciar el Apache
Reinicie el apache que se encuentra corriendo con el siguiente comand:
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.
WINDOWS
Para realizar la instalación seguimos los siguientes pasos:
1.
Descargar subversion 1.4.4 y descomprimirlo
2.
Copiar los archivos mod_authz_svn.so y mod_dav_svn.so , que se encuentra en svn-win32-1.4.4/bin, en APACHE_INSTALL_DIR/modules
3.
Copiar los archivos intl3_svn.dll y libdb44.dll, que se encuentra en svn-win32-1.4.4/bin, en APACHE_INSTALL_DIR/bin
4.
Añadir las siguientes líneas (en la sección donde está la carga de librerías) al archivo APACHE_INSTALL_DIR/conf/httpd.conf para cargar las correspondientes librerias:
1.
LoadModule dav_svn_module modules/mod_dav_svn.so
2. LoadModule authz_svn_module modules/mod_authz_svn.so
3. LoadModule dav_module modules/mod_dav.so
5. LoadModule dav_fs_module modules/mod_dav_fs.so
6.
Añadir la siguiente línea (al final) al archivo APACHE_INSTALL_DIR/conf/httpd.conf para cargar la configuración de subversion:
1.
Include “APACHE_INSTALL_DIR/conf/extra/httpd-subversion.conf”
7.
Creamos el archivo APACHE_INSTALL_DIR/conf/extra/httpd-subversion.conf con la siguiente configuración (es sólo un ejemplo):
1.
DAV svn
SVNParentPath “C:/tools/wamp/tmp/svn”
AuthzSVNAccessFile “C:/tools/wamp/Apache2/conf/access-policy/svn-groups.conf”
AuthType Basic
AuthName “Subversion repository”
Require valid-user
AuthUserFile “C:/tools/wamp/Apache2/conf/access-policy/svn-users.conf”
2. Cuidado con las rutas eso es sólo un ejemplo. Básicamente se indica donde van a       estar    nuestros repositorios de subversion, el archivo con los grupos y usuario de subversion
8.
Ahora tenemos que crear los archivos svn-groups.conf y svn-users.conf. Para el primero de ellos tenemos:
1.
[groups]
test-group: recena
[test:/]
@test-group:rw
1.
Definición de grupos y a continuación, nombre del repositorio (que tendremos que crearlo) y permisos del grupo sobre el raiz del repositorio.
2.
Para crear un usuario, hacemos uso de la utilidad htpasswd que nos proporciona Apache.
Para crear el repositorio hacemos uso de la utilidad svnadmin que proporciona subversión.

CÓMO CREAR REPOSITORIO

El repositorio básico de Subversion se crea en una máquina, generalmente dedicada, que va a actuar como servidor principal de desarrollo y es a esta máquina a la que tienen que acceder todos los clientes tanto para actualizar sus proyectos como para subir los cambios nuevos.

Para crear un repositorio nuevo donde albergar los proyectos, se usa el siguiente comando:
root@server:~:# svnadmin create /path/to/repository
Con este comando, en el directorio dado, creamos todos los archivos necesarios para que dicho directorio se comporte como un repositorio de Subversion. Debajo de este directorio se guardarán todas las versiones de nuestros proyectos así como la configuración de dicho repositorio y algunos elementos para la seguridad de acceso.
Además de tener el repositorio en la máquina servidor, es necesario tener una aplicación corriendo, svnserve, para que se pueda acceder de forma remota al repositorio. Este servidor viene cuando se instala Subversion y para arrancarlo basta con utilizar el comando siguiente:
root@server:~:# svnserve -d -T -r /path/to/repository
Con la opción -d hacemos que svnserve se comporte como un daemon, con -T hacemos que use threads en lugar de procesos y con -r indicamos donde está el repositorio.
En caso de que queramos arrancarlo cada vez que se inicie el sistema, será necesario configurar un script de inicio que hay que ubicar en el directorio /etc/init.d/ (en máquinas Debian y Ubuntu). Un ejemplo de este script se puede ver en el Anexo A de este documento.
Una vez funcionado el repositorio, para acceder al mismo mediante el comando svn, es necesario poner la ruta de la misma forma que una URL. Un ejemplo podría ser el siguiente (lista los contenidos del repositorio):
diego@server:~:$ svnlist svn://servidor/repositorio

Seguridad básica en un repositorio de Subversión
La configuración de la seguridad en un repositorio de Subversion se encuentra en el directorio /ruta/al/repositorio/conf. En en este directorio se encuentran tres archivos de configuración para el servidor svnserve junto con la seguridad de acceso al mismo:
authz : En este archivo se definen los grupos de usuarios del repositorio y sus correspondientes permisos. Con esto se consigue que sólo determinados usuarios tengan acceso de lectura y escritura y otros sólo de lectura.

passwd : En este archivo de definen los usuarios y contraseñas de todos los usuarios que pueden acceder al repositorio. Hay que tener cuidado con este archivo ya que las contraseñas no están encriptadas (uno de los grandes fallos del svnserve). Si se requiere que las contraseñas estén encriptadas, se debe usar mod_dav mediante Apache (http) para el acceso al repositorio.
svnserve.conf : En este archivo está la configuración del servidor svnserve para el acceso remoto al repositorio con los siguientes campos:
o anon-access = [none | read | write] : Con none, nadie puede acceder al repositorio para lectura si no tiene usuario y contraseña. Con read pueden acceder todos sólo para lectura. Y con write pueden acceder todos sin usuario ni contraseña para lectura y escritura (esto no está recomendado ya que no se controlan los usuarios que hacen los cambios).
o auth-access = [none | read | write] : Aquí basta con poner write para que todos los usuarios necesiten usuario y contraseña para acceder al repositorio como lectura y escritura.
o password-db : Indica la ubicación de un archivo de contraseñas.
o auth-db : Indica la ubicación del archivo de reglas de acceso a usuarios y grupos.
o realm : Indica el nombre del repositorio.
Además de esta configuración básica, se puede usar Subversion mediante un túnel por SSH poniendo las URL de la forma svn+ssh://servidor/repositorio/. Para ello es necesario configurar el servidor svnserve añadiendo la clausula [tunnels] en svnserve.conf e indicando cual va a ser el programa de tunneling (rsh = ssh, por ejemplo).

PRINCIPALES COMANDOS

update : Actualizar la copia local del proyecto con la versión más reciente del repositorio.
commit : Subir al repositorio los cambios realizados en la copia local. Además, hay que poner un mensaje de lo que se ha hecho en dichos cambios (con -m o mediante el editor que esté en la variable de entorno $SVN_EDITOR).
add : Con este comando se añade un nuevo archivo al repositorio. Hay que tener en cuenta que sólo se marca como añadido y hasta que no se haga el commit no se añade realmente.
checkout : Para descargar por primera vez una copia remota del proyecto a la máquina local.
revert : Restituye el archivo de copia de trabajo con los cambios de la última versión de la que se ha actualizado la copia local. Este comando no contacta con el servidor.
list : Lista los contenidos de un directorio dentro del repositorio.
• status : Comprueba el estado de los archivos de la copia local con respecto a la última actualización de dicha copia. No realiza ninguna conexión con el repositorio.
info : Muestra información de algún directorio de algún proyecto del repositorio.
lock : Bloquea una ruta en el repositorio para que ningún usuario pueda hacer commit sobre dicha ruta.

WEBGRAFÍA.

http://polaris.dit.upm.es/~rubentb/docs/subversion/TutorialSubversion/index.html
http://polaris.dit.upm.es/~rubentb/docs/subversion/TutorialSubversion/ar01s06.html#N10A5F

martes, 4 de enero de 2011

CALIDAD DEL SOFTWARE

Conceptos de calidad
Calidad  es un grupo de características que representa la efectividad y la eficiencia de un sistema de información. Es de vital importancia recalcar en dos puntos :
  • Un software de calidad debe ser eficaz, es decir, que debe realizar las funciones establecidas, debe ser amigable. Un usuario debe utilizar el software porque produce resultados confiables, realiza todas las operaciones que se requieren, ejecuta las operaciones en un tiempo aceptado y es fácilmente usado por el grupo de usuarios a quien este dirigido.
  • Un software de calidad debe ser eficiente, es decir el costo de su desarrollo tomando todos los recursos y el costo de su operación debe ser tal que las organizaciones involucradas en su desarrollo y uso obtengan el máximo beneficio o por lo menos un beneficio aceptable en un período de tiempo establecido.
La tendencia de la calidad
Mediante las ideas de Deming como piedra angular, los japoneses han desarrollado un enfoque sistemático para la eliminación de las causas raíz de defectos en productos.La tendencia de la calidad comenzó en los años cuarenta con el influyente trabajo de W. Edwards Deming.
A lo largo de los años setenta y ochenta, su trabajo emigró al mundo occidental y a veces se llama «gestión total de calidad (GTC). Aunque la terminología difiere según los diferentes países y autores, normalmente se encuentra una progresión básica de cuatro pasos que constituye el fundamento de cualquier programa de GTC.
Garantía de calidad del software
Este es uno de los aspectos muy importantes dentro de la calidad del software ya que consiste en los medios de la supervisión tecnología de dotación lógica los procesos y los métodos aseguraban calidad. Hace esto por medio de intervenciones de sistema de gerencia de la calidad debajo de cuál se crea el sistema de software. Estas intervenciones son movidas hacia atrás por unos o más estándares, generalmente ISO 9000.
Es distinto de control de calidad del software cuál incluye el repaso requisitos documentos, y prueba del software. La SQA abarca el entero desarrollo del software proceso, tales como el cual incluye procesos diseño del software, codificación, control del código de fuente, revisiones de código, cambie a gerencia, gerencia de la configuración, y lance a gerencia. Mientras que el control de calidad del software es un control de productos, la garantía de calidad del software es un control de procesos.
La garantía de calidad del software se relaciona con la práctica de garantía de calidad en producto fabricación. Hay, sin embargo, algunas diferencias notables entre el software y un producto manufacturado. Estas diferencias provienen el hecho de que el producto manufacturado es físico y puede ser visto mientras que el producto de software no es visible. Por lo tanto su función, ventaja y costes no están según lo medido fácilmente. Cuál es más, cuando un producto manufacturado cae la planta de fabricación, es esencialmente un completo, producto final, mientras que el software nunca se acaba. El software vive, crece, se desarrolla, y transforma, desemejante de sus contrapartes tangibles. Por lo tanto, los procesos y los métodos para manejar, para supervisar, y para medir su calidad en curso son tan líquido y a veces evasivos como son los defectos que se significan para mantener cheque.
Revisiones del software
  • Las revisiones de software sirven para validar la calidad y/o el estado de un producto.
  • El producto a revisar puede ser un documento,  un módulo, un prototipo, etc.
  • Existen distintos tipos de revisiones. Cada una especializada en un determinado producto / escenario.
  • Las revisiones ayudan a encontrar falencias, y a identificar riesgos, que serían difíciles de encontrar de otra manera.
Revisiones técnicas formales
Uno de los principales objetivos de las revisiones técnicas formales es descubrir errores en la función, lógica o implementación de cualquier representación del software. Verificar el cumplimiento de los requisitos Garantizar el cumplimiento de los estándares. Conseguir un desarrollo uniforme del software Obtener proyectos que hagan más sencillo los trabajos técnicos (análisis que permitan buenos diseños, diseños que permitan implementaciones sencillas, estrategias de pruebas que faciliten éstas,…)
Técnicas
“Estáticas: análisis y chequeo de documentos de requisitos, diagramas de diseño, código fuente, etc.
“dinámicas: pruebas sobre implementación real (sólo pueden Usarse cuando ya se tiene código ejecutable).

Se eliminan errores en forma relativamente temprana (barato y fácil de corregir)
Cada revisión se conduce en forma de una reunión cuidadosamente planeada y controlada

Fiabilidad del software,
La fiabilidad del software se define en términos estadísticos como la probabilidad de operación libre de fallos de un programa de computadora es un entorno determinado y durante un tiempo específico.
¿qué se entiende por el término fallo ? En el contexto de cualquier discusión sobre calidad y fiabilidad del software, el fallo es cualquier falla de concordancia con los requisitos del software.
En esta definición existen grados.
Los fallos pueden ser simplemente desconcertantes o ser catastróficos.
Puede que un fallo sea corregido en segundos mientras que otro lleve semanas o incluso meses. Para complicar más las cosas, la corrección de un fallo puede llevar a la introducción de otros errores que, finalmente, lleven a más fallos.
Prueba de errores para el software
La prueba de software es un conjunto de herramientas,  técnicas y métodos que hacen a la excelencia del desempeño de un programa, así como también la mejor publicidad que una empresa dedicada a la producción de software pueda  tener. Las técnicas para encontrar problemas en un programa  son extensamente variadas y van desde el uso del ingenio por  parte del personal de prueba hasta herramientas  automatizadas que ayudan a aliviar el peso y el costo de  tiempo de esta actividad. Pero de nada serviría conocer todas  las técnicas de prueba de software, si un programa carece de  documentación, el código es confuso, o no se han seguido  pasos para la planificación y desarrollo del software, ya que  sería como buscar una aguja en un pajar.
El estándar de calidad iso 9001
Es un conjunto de normas sobre la calidad y la gestión. La Norma ISO 9001 ha sido elaborada por el Comité Técnico ISO/TC176 de ISO Organización Internacional para la Estandarización y especifica los requisitos para un buen sistema de gestión de la calidad que pueden utilizarse para su aplicación interna por las organizaciones, para certificación o con fines contractuales.
La norma ISO 9001 tiene origen en la norma BS 5750, publicada en 1979 por la entidad de normalización británica, la [British Standards Institution] (BSI).
La versión actual de ISO 9001 (la cuarta) data de noviembre de 2008, y por ello se expresa como ISO 9001:2008. Versiones ISO 9001 hasta la fecha:
  • Cuarta versión: la actual ISO 9001:2008 (15/11/2008)
  • Tercera versión: ISO 9001:2000 (15/12/2000)
  • Segunda versión: ISO 9001:94 - ISO 9002:94 - ISO 9003:94 (01/07/1994)
  • Primera versión: ISO 9001:87 - ISO 9002:87 - ISO 9003:87 (15/03/1987)

En la primera y segunda versión de ISO 9001, la Norma se descomponía en 3 normas: ISO 9001, ISO 9002, e ISO 9003.
  • ISO 9001 --> organizaciones con diseño de producto
  • ISO 9002 --> organizaciones sin diseño de producto pero con producción/fabricación.
  • ISO 9003 --> organizaciones sin diseño de producto ni producción/fabricación (comerciales).
El contenido de las 3 normas era el mismo, con la excepción de que en cada caso se excluían los requisitos de aquello que no aplicaba. Esta mecánica se modificó en la tercera versión, unificando los 3 documentos en un único estándar, sobre el cual se realizan posteriormente las exclusiones.

WEBGRAFÍA
http://es.wikipedia.org/wiki/ISO_9001

ANÁLISIS Y GESTIÓN DE RIESGOS



¿Qué es la identificación de un riesgo y cual es su clasificación?
La identificación del riesgo 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 cuando sea posible y controlarlos cuando sea necesario.

Existen dos tipos diferenciados de riesgos para cada categoría genéricos y específicos del producto. Los riesgos genéricos son una amenaza potencial para todos los proyectos de software. Los específicos de producto sólo los pueden identificar los que tienen una clara visión de la tecnología, el personal y el entorno específico del proyecto en cuestión. Para identificar los riesgos específicos del producto se examinan el plan del proyecto y la declaración del ámbito del software y se desarrolla una respuesta a la siguiente pregunta: ¿Qué características especiales de este producto pueden estar amenazadas por nuestro plan del proyecto'?"

Un método para identificar riesgos es crear una lista de comprobación de elementos de riesgo. La lista de comprobación se puede utilizar para identificar riesgos y se enfoca en un subconjunto de riesgos conocidos y predecibles en las siguientes subcategorías genéricas:

• Tamaño del producto: riesgos asociados con el tamaño general del software a construir o a modificar.
• Impacto en el negocio: riesgos asociados con las limitaciones impuestas por la gestión o por el mercado.
• Características del cliente: riesgos asociados con la sofisticación del cliente y la habilidad del desarrollador para comunicarse con el cliente en los momentos oportunos.
• Definición del proceso: riesgos asociados con el grado de definición del proceso del software y su seguimiento por la organización de desarrollo.
• Entorno de desarrollo: riesgos asociados con la disponibilidad y calidad de las herramientas que se van a emplear en la construcción del producto.
• Tecnología a construir: riesgos asociados con la complejidad del sistema a construir y la tecnología punta que contiene el sistema.
• Tamaño y experiencia de la plantilla: riesgos asociados con la experiencia técnica y de proyectos de los ingenieros del software que van a realizar el trabajo.
¿Cuál es la evaluación global del riesgo del proyecto, los componentes y controladores del riesgo?
Los componentes de riesgo se definen de la siguiente manera:

• 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.
El impacto de cada controlador de riesgo en el componente de riesgo se divide en cuatro categorías de impacto: despreciable, marginal, crítico y catastrófico.
¿Cómo se realiza la estimación del riesgo?
Se lo realiza de dos maneras intentando medir; 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?
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.
Una tabla de riesgo le proporciona al jefe del proyecto una sencilla técnica para la proyección del riesgo. La tabla de riesgo debería implementarse como un modelo de hoja de cálculo. Esto permite un fácil manejo y ordenación de las entradas. 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.

WEBGRAFÍA
http://www.wikilearning.com/curso_gratis/gestion_de_riesgos_en_ingenieria_del_software/3620-12