SUBVERSION

¿QUE ES SUBVERSIÓN?
Subversión es un sistema de control de versiones libre y de código fuente abierto. Es decir, Subversion maneja ficheros y directoriosa través del tiempo. Hay un árbol de ficheros en un repositorio central. El repositorio es como un servidor de ficheros ordinario,excepto porque recuerda todos los cambios hechos a sus ficheros y directorios.
Subversión puede acceder al repositorio a través de redes, lo que le permite ser usado por personas que se encuentran en distintosordenadores. A cierto nivel, la capacidad para que varias personas puedan modificar y administrar el mismo conjunto de datos desdesus respectivas ubicaciones fomenta la colaboración. Se puede progresar más rápidamente sin un único conducto por el cual debanpasar todas las modificaciones.
Y puesto que el trabajo se encuentra bajo el control de versiones, no hay razón para temer porque la calidad del mismo vaya a verse afectada por la pérdida de ese conducto único—si se ha hecho un cambio incorrecto a los datos,simplemente deshaga ese cambio.
Algunos sistemas de control de versiones son también sistemas de administración de configuración de software. Estos sistemas sondiseñados específicamente para la administración de árboles de código fuente, y tienen muchas características que son específicasdel desarrollo de software— tales como el entendimiento nativo de lenguajes de programación, o el suministro de herramientas parala construcción de software.

¿COMO FUNCIONA?
Subversión crea una copia de trabajo denominada árbol de directorios corriente de su sistema de archivos local, conteniendo una colección de archivos. Usted puede editar estos archivos del modo que prefiera y si se trata de archivos de código fuente, podrá compilar su programa a partir de ellos de la manera habitual. Su copia de trabajo es su área de trabajo privada: Subversión nunca incorporará los cambios de otra gente o pondrá a disposición de otros sus cambios hasta que usted le indique explícitamente que lo haga.
Tras hacer algunos cambios a los archivos en su copia de trabajo y verificar que funcionan correctamente, Subversión le proporciona comandos para “publicar” sus cambios al resto de personas que trabajan con usted en su proyecto (escribiendo en el repositorio). Si las demás personas publican sus propios cambios, Subversión le proporciona comandos para mezclar estos cambios en su directorio de trabajo (leyendo del repositorio).
Una copia de trabajo también contiene algunos archivos extra, creados y mantenidos por Subversión para ayudarle a ejecutar estos comandos. En particular, cada directorio de su copia de trabajo contiene un subdirectorio llamado .svn, también conocido como el directorio administrativo de la copia de trabajo. Los archivos en cada directorio administrativo ayudan a Subversión a reconocer qué archivos contienen cambios no publicados y qué archivos están desactualizados con respecto al trabajo hecho por los demás.

Un repositorio típico de Subversión contiene a menudo los archivos (o el código fuente) de varios proyectos; normalmente, cada proyecto es un subdirectorio en el árbol del sistema de archivos del repositorio. En esta disposición, la copia de trabajo de un usuario se corresponde habitualmente con un subárbol particular del repositorio.
Por ejemplo, suponga que usted tiene un repositorio que contiene dos proyectos de software, paint y calc. Cada proyecto reside en su propio subdirectorio dentro del directorio raíz.
Para conseguir una copia de trabajo, debe ejecutar primero un checkout de algún subárbol del repositorio. (Crea una copia privada del proyecto)
¿PARA QUE SIRVE?
Subversión ayuda a que los desarrolladores lleven un seguimiento de los cambios en los ficheros de código fuente de su proyecto. Hay varias razones: para obtener y comparar versiones anteriores, cazar errores regresivos, mantener ramas compatibles con las versiones anteriores, producir excelentes registros de cambios (//changelogs//), trabajar sobre dos arreglos o mejoras diferentes sin confusiones. Además, conseguir todo esto con poco esfuerzo, porque Subversion es muy fácil de instalar.
Un //repositorio Subversion// se comporta como un sistema de ficheros que recuerda conjuntos de cambios que se le han hecho. Esto lo hace almacenando ficheros en una estructura de árbol, llevando un control de su evolución a lo largo del tiempo. El repositorio incrementa un número global de revisión con cada conjunto de cambios //enviados// (//committed//) al repositorio. Como la totalidad del árbol está versioneada, actúa como un sistema de ficheros normal. Es posible copiar y renombrar ficheros; crear una rama del proyecto es tan fácil como copiar un directorio. También se le puede pedir a Subversion que produzca una salida con las //diferencias// entre dos revisiones arbitrarias, o que recupere algún sub-árbol de la revisión //N//.
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.
• 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 en 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
COMO CREAR Y CONFIGURAR UN 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).
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.
-password-db : Indica la ubicación de un archivo de contraseñas.
-auth-db : Indica la ubicación del archivo de reglas de acceso a usuarios y grupos.
-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).
¿COMO CREAR USUARIOS?
Hay muchas formas de crear usuarios para subversion, incluyendo el que coja los de Windows. Sin embargo, una forma fácil de hacerlo es la siguiente.
Vamos al repositorio de PROYECTO1 recién creado y editamos el fichero conf/svnserve.conf. Por defecto viene con un montón de comentarios, pero en los que podemos leer claramente todas las opciones. Podemos dejar algo como esto
anon-access = read
auth-access = write
password-db = passwd
realm = PROYECTO1
Donde
• anon-access = read indica permisos de lectura para usuario anónimos. Es decir, cualquiera podría sacar los fuentes para verlos, pero no podría subir los cambios.
• auth-access = write indica permisos de lectura y escritura para usuarios autentificados.
• password-db = passwd es el fichero donde estarán los nombres de usuario y passwords. En este caso, el fichero se llamará passwd y el path es relativo al fichero svnserve.conf que estamos editando.
• realm = PROYECTO1 es el nombre que verán los usuarios cuando intenten acceder al repositorio y se les pida usuario y password. Puede ser cualquier palabra o frase que queramos. También se usará como clave para cifrado si corresponde.
Podemos dejar annon-acces = none para no dar ningún permiso a usuario anónimos.
Luego, editamos el fichero passwd que se crea por defecto (o el que hayamos indicado en password-db = passwd), lo editamos y ponemos los usuarios que queramos, de esta manera
[users]
chuidiang = la-password
federico = otra-password
juana = mas-passwords
Grupos en subversion
Si en el fichero svnserve.conf ponemos también una línea así
authz-db = authz
estamos indicando un fichero en el que podemos meter a los usuarios en grupos y en los que podemos dar permisos a cada grupo o usuarios a determinados directorios. Por ejemplo, suele ser una forma habitual de trabajo tener en el repositorio tres directorios: trunk, branches y tags.
• trunk es la rama principal de desarrollo. Una forma de trabajo es que haya una persona responsable de esta rama y que garantice que es siempre estable. Esa persona puede ser la única con permisos de escritura en ella y recibir los cambios de los demás desarrolladores. Sólo el puede escribir, aunque todos los demás podrían leer.
• branches y tags son para ramas secundarias y etiquetas. En la forma de trabajo anterior, los desarrolladores deben crearse su propia rama a partir de la principal y desarrollar en la rama. Cuando terminan, avisan al responsable de la rama principal para que prueba y lleve a ella los cambios realizados. Se puede dar permisos de escritura a este directorio branches a todos los desarrolladores.
El fichero authz puede contener cosas como esta
[groups]
administradores = chuidiang
desarrolladores = federico,juana

[/trunk]
@administradores = rw
@desarrolladores = r
* =

[/branches]
@administradores = rw
@desarrolladores = rw
* =
donde:
• En [groups] se definen los grupos, poniendo nombre de grupo igual a los desarrolladores separados por comas.
• Se ponen tantas secciones [/path] como se quiera y en ellas se pone
o @nombre_grupo = permisos. Pueden ser rw, r o nada si no se quieren dar permisos
o nombre_usuario = permisos.
o * = permisos para el resto.
COMANDOS SUBVERSION
Estos comandos son de la forma svn [comando] y teniendo que ejecutarse en el directorio o algún subdirectorio de la copia local. Los subcomandos [comando] son alguno de los siguientes:
• 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.
• unlock : Desbloquea rutas bloqueadas con lock.
• blame : Imprime los cambios de un archivo respecto de versiones y quién los ha hecho.
• merge : Une las diferencias entre dos copias de los archivos de trabajo que generalmente están en conflicto.
• resolved :Indica que un conflicto ha sido resuelto.
• log : Muestra los mensajes de log de la copia de trabajo. Es necesario hacer un update para que estén todos los logs del proyecto.
• switch : Actualiza la copia de trabajo a un directorio distinto. Esto es útil para cambiar entre diferente branches que se verán en el siguiente punto
BIBLIOGRAFIA:
http://chuwiki.chuidiang.org/index.php?title=Montar_un_servidor_subversion_en_Windows
http://es.wikipedia.org/wiki/Subversion
http://www.edendelsur.com/own/instalando%20Subversion.pdf
http://amap.cantabria.es/confluence/display/DEV/Subversion
http://www.um.es/atica/documentos/PREsubversion.pdf

AC Ryan Fluxx. Reproductor inteligente con procesador Atom.

AC Ryan lanza su propia solución de “Smart TV” con el nuevo Fluxx donde destaca la integración de un procesador SOC Atom de la gama CE4100 de Intel.
Este nuevo reproductor equipa un procesador de 1.2GHz con capacidad para reproducción simultánea de hasta dos canales de video 1080p simultáneos y también controlar todo nuestro sistema incluidos interfaces USB, SATA, etc.

El nuevo Fluxx dispondrá de funciones Smart TV como la navegación por internet, acceso a redes sociales, TV bajo demanda y un interfaz personalizable por el usuario. Soporta discos duros de hasta 2TB y cuenta con 1GB de RAM DDR3 para impulsar el sistema operativo. Contará con un control remoto con teclado QWERTY y dispone de funciones interesantes como sus múltiples entradas USB, lector de tarjetas e incluso una entrada HDMI con la que esperamos se pueda hacer grabación en alta resolución.

También soportara Flash 10, DLNA, todos los contenedores y códec de video y sonido conocidos así como acceso a ISOs, control remoto (http, Android e iPhone), FTP, P2P, etc. AC Ryan presentara esta nueva unidad durante el CES así que en pocos días tendremos más detalles.

Fuente: Hispazone[http://www.hispazone.com/Noticia/3434/AC-Ryan-Fluxx-Reproductor-inteligente-con-procesador-Atom-.html],[Consulta: 31-12-2010]

Garantia de Calidad de Software

 Calidad
Se define la calidad como «una característica o atributo de algo». Como un atributo de un elemento, la calidad se refiere a las características que se pueden comparar con estándares conocidos como longitud, color, propiedades eléctricas, maleabilidad, etc. Sin embargo, el software en su gran extensión, como entidad intelectual, es más difícil de caracterizar que los objetos físicos.

 La tendencia de la calidad
La tendencia de la calidad comenzó en los años cuarenta con el influyente trabajo de W.Edwards Deming y se hizo la primera verificación en Japón. 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. 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) x2)». 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
Hasta el desarrollador de software más agobiado estará de acuerdo con que el software de alta calidad es una meta importante. Pero, ¿cómo definimos la calidad? Un bromista dijo una vez: «Cualquier programa hace algo bien, lo que puede pasar es que no sea lo que nosotros queremos que haga».
No hay duda de que la anterior definición puede ser modificada o ampliada. De hecho, no tendría fin una discusión sobre una definición formal de calidad del software.
Para los propósitos de este libro, la anterior 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ían la forma en que se aplica la ingeniería del software. Si no se siguen esos criterios, casi siempre habrá falta de calidad.
3. Existe un conjunto de requisitos implícitos que a menudo no se mencionan (por ejemplo: el deseo por facilitar el uso y un buen mantenimiento). Si el software se ajusta a sus requisitos explícitos pero falla en alcanzar los requisitos implícitos, la calidad del software queda en entredicho.

 Revisiones del software
Las revisiones del software son un «filtro» para el proceso de ingeniería del software. Esto es, las revisiones Se aplican en varios momentos del desarrollo del software y sirven para detectar errores y defectos que puedan así ser eliminados. Las revisiones del software sirven para «purificar» las actividades de ingeniería del software que suceden como resultado del análisis, el diseño y la codificación. Freedman y Weinberg argumentan de la siguiente forma la necesidad de revisiones:
El trabajo técnico necesita ser revisado por la misma razón que los lápices necesitan gomas: errar es humano. La segunda razón por la que necesitamos revisiones técnicas es que, aunque la gente es buena descubriendo algunos de sus propios errores, algunas clases de errores se le pasan por alto más fácilmente al que los origina que a otras personas. El proceso de revisión es, por tanto, la respuesta a la plegaria de Robert Bums:
¡Qué gran regalo sería poder vemos como nos ven los demás!
Una revisión (cualquier revisión) es una forma de aprovechar la diversidad de un grupo de personas para:
1. señalar la necesidad de mejoras en el producto de una sola persona o un equipo;
2. confirmar las partes de un producto en las que no es necesaria o no es deseable una mejora; y
3. conseguir un trabajo técnico de una calidad más uniforme, o al menos más predecible, que la que puede ser conseguida sin revisiones, con el fin de hacer más manejable el trabajo técnico.

 Revisiones técnicas formales
Una revisión técnica formal (RTF) es una actividad de garantía de calidad del software llevada a cabo por los ingenieros del software (y otros). Los objetivos de la RTF son: (1) descubrir errores en la función, la lógica o la implementación de cualquier representación del software; (2) verificar que el software bajo revisión alcanza sus requisitos; (3) garantizar que el software ha sido representado de acuerdo con ciertos estándares predefinidos; (4) conseguir un software desarrollado de forma uniforme y (5) hacer que los proyectos sean más manejables. Además, la RTF sirve como campo de entrenamiento, permitiendo que los ingenieros más jóvenes puedan observar los diferentes enfoques de análisis, diseño e implementación del software. La RTF también sirve para promover la seguridad y la continuidad, ya que varias personas se familiarizarán con partes del software que, de otro modo, no hubieran visto nunca.
La RTF es realmente una clase de revisión que incluye recorridos, inspecciones, revisiones cíclicas y otro pequeño grupo de evaluaciones técnicas del software. Cada RTF se lleva a cabo mediante una reunión y sólo tendrá éxito si es bien planificada, controlada y atendida.



 Fiabilidad del software
No hay duda de que la fiabilidad de un programa de computadora es un elemento importante de su calidad general. Si un programa falla frecuente y repetidamente en su funcionamiento, no importa si el resto de los factores de calidad son aceptables.
La fiabilidad del software, a diferencia de otros factores de calidad, puede ser medida o estimada mediante datos históricos o de desarrollo. 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 en un entorno determinado y durante un tiempo específico».

 El estándar de calidad ISO 9001
El estándar, que ha sido adoptado por más de 130 países para su uso, 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 (rodamientos), secadores de pelo, automóviles, equipamientos deportivos y televisiones, así como por desarrolladores de software. Se han realizado muchos documentos que relacionan el estándar con la industria del software, pero no entran en una gran cantidad de detalles. El objetivo de esta sección es describir lo que significa el ISO 9001 en términos de elementos de calidad y técnicas de desarrollo.
Para la industria del software los estándares relevantes son:
• ISO 9001. Quality Systems- Model for Quality Assurance in Design, Development, Production, Installation and Servicing. 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. Guidelines for Application of ISO 9001 to the Development, Supply and Maintainance of Software. Este es un documento específico que interpreta el ISO 9001 para el desarrollador de software.
• ISO 9004-2. Quality Management and Quality System Elements -Part 2-. Este documento proporciona las directrices para el servicio de facilidades del software como soporte de usuarios.
Los requisitos se agrupan bajo 20 títulos:
• Responsabilidad de la gestión.
• Inspección, medición y equipo de pruebas.
• Sistema de calidad.
• Inspección y estado de pruebas.
• Revisión de contrato.
• Acción correctiva.
• Control de diseño.
• Control de producto no aceptado.
• Control de documento.
• Tratamiento, almacenamiento, empaquetamiento y entrega.
• Compras.
• Producto proporcionado al comprador.
• Registros de calidad.
• Identificación y posibilidad de seguimiento del producto,
• Auditorías internas de calidad.
• Formación
• Control del proceso
• Servicios.
• Inspección y estado de prueba.
• Técnicas estadísticas.

Analisis y Gestion de Riesgos

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

Clasificación

Hay dos tipos de riesgo para cada categoría de riesgo de SW (proyecto, producto y negocio).
• Riesgos genéricos: Amenaza potencial para todos los proyectos de SW.
• Riesgos específicos: De la tecnología, el personal y el entorno específico del proyecto en cuestión

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

-¿Se han entregado los gestores del software y clientes formalmente para dar soporte al proyecto?
-¿Están completamente entusiasmados los usuarios finales con el proyecto y con el sistema/producto a construir?
-¿Han comprendido el equipo de ingenieros de software y los clientes todos los requisitos?
-¿Han estado los clientes involucrados por completo en la definición de los requisitos?
-¿Tienen los usuarios finales expectativas realistas?
-¿Es estable el ámbito del proyecto?
-¿Tiene el Ingeniero de Software el conjunto adecuado de habilidades?
-¿Son estables los requisitos del Proyecto
-¿Tiene experiencia el equipo del proyecto con la tecnología a implementar?
-¿Es adecuado el número de personas del equipo del proyecto para realizar el trabajo?
-¿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 incertidumbrecon que se podrá mantener la planificacióntemporal 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

3. ¿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
Establecer una escala que refleje la probabilidad percibida del riesgo; cualitativa y/o cuantitativa. Por ejemplo:
1. <10% à muy bajo
2. 10-25% à bajo
3. 25-50%à moderado
4. 50-75% à alto
5. >75% à muy alto

Estimar la probabilidad.

Consejos:
• Técnica Delphi: Cada quien hace una estimación individual. Luego se discute el origen de cada estimación, hasta hacer converger las estimaciones.
• Utilizar <>. Definir un valor cualitativo y luego establecer un valor cuantitativo.
Estimar la magnitud de la pérdida.
Cuantitativamente, la pérdida puede ser medida en unidades de tiempo o de costo.
• Para determinar la magnitud en tiempo se recurre a la experiencia o se toma la medida de algo pequeño y se combina para hallar la magnitud total (por ejemplo, para LCDs).
• Para determinar la magnitud en costo: Si es código, se estima cuántas LDC o FP se requieren, se averigua el valor promedio de cada una y se multiplica.
Estimar la exposición al riesgo (ER). La ER es el valor esperado de pérdida. Es la probabilidad de pérdida (P) multiplicada por la magnitud de la pérdida (C).
ER = P.C
• El valor de la exposición al riesgo se utiliza posteriormente para priorizar los riesgos.
Retraso total del proyecto: Se suman todas las exposiciones al riesgo para determinar el riesgo total del proyecto.
• La planificación total del proyecto se puede cambiar para reflejar el retraso total esperado calculado en plan de gestión de riesgos.


4.¿Cuáles son los beneficios de realizar una estimación de proyectos?
Algunos beneficios de la estimación son: plazos de entrega y presupuesto más realistas, mayor satisfacción de los usuarios, cronogramas más acertados que permiten controlar mejor el proyecto, los procesos de estimación son una exigencia de los estándares de calidad internacionales.