Unidad 3 Anlisis del Proyecto

3.1. Anlisis de riesgos

El anlisis y la gestin de riesgos son una serie de pasos que ayudan al equipo de desarrollo de software a comprender y gestionar la incertidumbre. Ya que los proyectos de software estn sujetos a problemas. Un riesgo es un problema potencial. Una de las varias tareas que tiene el gestor de proyectos es la de anticipar los riesgos que puedan afectar el desarrollo del proyecto o la calidad del software a desarrollar.

RIESGOS
Es la probabilidad de que una circunstancia adversa ocurra. Es una amenaza para el proyecto de desarrollo de software. Un riesgo:
Afecta futuros acontecimientos Implica cambios Implica una eleccin y la incertidumbre de sta.

Categoras de riesgos

Otra categora de riesgos

Riesgos conocidos Tipos de
Son aquellos que se pueden descubrir con una cuidadosa evaluacin del plan del proyecto de su entorno tcnico

Riesgos

Riesgos

Riesgos impredecibles

Son aquellos que predeciblespodemos extrapolar de proyectos anteriores o de nuestra experiencia Son extremadamente difciles de identificar

**Los riesgos se deben identificar y tratar de minimizarlos

Ejemplos de Riesgos
Riesgo Tipo de riesgo

Rotacin del personal

Cambio de administracin Hardware indisponible Cambio de requerimientos Retrasos en la especificacin Subestimacin del tamao Bajo desempeo de la herramienta CASE Cambio de tecnologa Competencia del producto

Proyecto
Proyecto Proyecto Proyecto y producto Proyecto y producto Proyecto y producto Producto

Negocio Negocio

Riesgos en el Proceso Unificado (PU)

1. Riesgos relacionados con nuevas tecnologas. 2. Riesgos relativos a la arquitectura. 3. Riesgos relativos a construir el sistema adecuado, es decir, que cumpla con su objetivo y con sus usuarios. 4. Riesgos relativos al rendimiento.
1. Gente sin experiencia en el proyecto 2. El calendario propuesto del cliente es muy corto. 3. El cliente no realiza las aprobaciones en el tiempo establecido 4. Existan terceras personas subcontratadas con las que no se ha trabajado antes.

Riesgos tcnicos

Riesgos No tcnicos

3.1.1. Proceso de gestin de riesgos

Estrategias para prevenir los riesgos
Es evidente que en todos los proyectos se presentarn riesgos, por lo que es esencial identificarlos y establecer un plan para reducirlos. Existen dos estrategias ante los riesgos: Reactiva Proactiva

Estrategias para prevenir los riesgos

REACTIVA
Consiste en esperar a que se presente un riesgo y luego improvisar una solucin. Que por supuesto trae consecuencias negativas al proyecto.

PROACTIVA
Empiezan mucho antes de que comiencen los trabajos tcnicos. En esta estrategia se aplica el mtodo de evaluacin previa y sistemtica de los riesgos y sus posibles consecuencias.

Qu hacer ante la posibilidad de la existencia de un riesgo?

Identificar el riesgo Evaluar su probabilidad de aparicin Analizar el impacto que pueda causar Priorizar el riesgo Desarrollar un plan de contingencia

Proceso de gestin de riesgos

La gestin de riesgos es un proceso iterativo que se aplica durante todo el proyecto y se desarrolla en cuatro etapas

Etapa 1. Identificacin de riesgos

Comprende el descubrimiento de los posibles riesgos del proyecto, que se puede llevar a cabo a travs de una lluvia de ideas o basndose en la experiencia del gestor de proyecto. En lo que consiste es en listar los posibles tipos de riesgos.

TIPO DE RIESGO
o Tecnologa: se derivan de tecnologa de SW o HW o

EJEMPLOS DE POSIBLES RIESGOS

la base de datos que se utiliza en el sistema no puede procesar tantas transacciones por segundo como se esperaba los componentes de software a reutilizar tienen defectos que limitan su funcionalidad imposible contratar personal con los conocimientos requeridos personal clave enfermo o no disponible en momentos crticos

Personal: asociadas al equipo de desarrollo

o o

Organizacionales: al entorno donde se desarrolla el software Herramientas: asociado a herramientas case y de apoyo

o o

la organizacin se reestructura y una nueva administracin se responsabiliza del proyecto los problemas financieros de la organizacin reducen el presupuesto del proyecto

o o

las herramientas CASE generan cdigo ineficiente las distintas herramientas CASE no se pueden integrar

Requerimientos: derivado de los cambios requeridos por el cliente

o o

cambios de requerimientos que precisan modificaciones en el diseo los clientes no comprenden el impacto de los cambios en los requerimientos

Estimacin: derivado de los estimados administrativos y los recursos requeridos

o o o

el tiempo requerido para desarrollar el software est subestimado la tasa de reparacin de defectos est subestimada el tamao del software est subestimado

Lista de riesgos
La lista de riesgos sirve como una gua para saber si se ser capaz de hacer algo al respecto e incluye: Descripcin: comienza con una breve descripcin y se van aadiendo detalles conforme se obtiene mayor informacin. Prioridad: se le asigna una prioridad al riesgo, clasificndolos en crticos, significativo o rutinario. Impacto: indica qu partes del proyecto o del sistema se vern afectadas por el riesgo. Responsabilidad: indica qu individuo o unidad de la organizacin es responsable de eliminar o mitigar el riesgo. Contingencia: indica lo que ha de hacerse en caso de que el riesgo se materialice.

Etapa 2. Anlisis de riesgos

En esta etapa se debe de considerar por separado cada riesgo identificado y se decide la probabilidad de que ocurra y la seriedad de ste. Ya que se puede basar en la experiencia del gestor, la valoracin se realiza en intervalos. Se valora el riesgo por la probabilidad de que sea: Muy bajo <10 % Bajo10 25 % Moderado25- 50 % Alto50 - 75 % Muy alto>75 % A continuacin los efectos de riesgo son valorados como: Catastrficos Serios Tolerables Insignificantes

Anlisis de riesgos
Como resultado del proceso de anlisis se realiza una tabla de riesgos que se ordena de acuerdo a la seriedad del riesgo encontrado. Despus del anlisis y clasificacin se decide cules son los ms importantes o bien los riesgos clave y que se van a considerar durante el proyecto. Los riesgos serios o catastrficos siempre se deben tomar en cuenta.

Etapa 3. Planificacin de riesgos

En esta etapa se considera cada uno de los riesgos clave identificados y las estrategias o planes de contingencia, para gestionarlo. Las estrategias utilizadas para la generacin de planes de contingencia son:
Estrategias de anulacin.- intentan reducir la probabilidad de que surja el riesgo Estrategias de disminucin.- intentan reducir el impacto del riesgo Planes de contingencia.- se dispone de ellos para estar preparados por si el riesgo ocurre y poder actuar con una estrategia determinada

La forma de gestionar los riesgos recae en la experiencia y juicio del gestor del proyecto. Las posibles estrategias identificadas para los riesgos se observan en la sig. tabla:
Riesgo Problemas financieros de la organizacin Problemas de reclutamiento Enfermedad del personal Componentes defectuosos Cambios en los requerimientos Reestructuracin organizativa Rendimiento de la base de datos Tiempo de desarrollo subestimado Estrategia Preparar un documento breve para la direccin de la empresa que muestra que el proyecto hace contribuciones muy importantes a las metas del negocio organizar cursos de capacitacin para el personal ya existente, investigar la posibilidad de contratar en otras regiones o pases reorganizar el equipo de tal forma que se solapen el trabajo y los miembros del equipo comprendan el trabajo de los dems reemplazar los componentes defectuosos con los comprados de fiabilidad conocida rastrear la informacin para valorar el impacto de los requerimientos, maximizar la informacin oculta en ellos preparar un documento breve para la direccin de la empresa que muestra que el proyecto hace contribuciones muy importantes a las metas del negocio investigar la posibilidad de comprar una base de datos con el rendimiento preciso alertar al cliente de las dificultades potenciales y las posibilidades de retraso

Planificacin de riesgos en el Proceso Unificado

En el PU la reduccin del riesgo es un eje central de las iteraciones que se hace en las fases de inicio y de elaboracin. Ms adelante, en la fase de construccin, la mayora de los riesgos se han reducido hasta un nivel de rutina. Dentro del PU, el principio general es tener un plan de accin a seguir sobre los riesgos. Las fases y las iteraciones dentro de las fases, proporcionan el medio de planificar las acciones sobres los riesgo.

Planificacin de riesgos en el Proceso Unificado

Otro de los objetivos del PU es acabar con los riegos en una iteracin temprana. A continuacin el equipo del proyecto decide cmo tratar cada uno de ellos. Para esto cuentan con cuatro elecciones:

Evitarlo mediante una replanificacin del proyecto o un cambio en los requerimientos. Limitarlo, es decir, restringirlos de modo que slo afecten a una pequea parte del proyecto. Atenuarlo, mediante la observacin si aparecen o no. De aparecer lo positivo que se obtiene es mayor conocimiento sobre ste y tener mejor disposicin de evitarlo, limitarlo o controlarlo. Controlarlo en caso de que no pueda atenuarse, y observar si aparecen y aplicar planes de contingencia.

Etapa 4. Supervisin de riesgos

En esta etapa se valora cada uno de los riesgos identificados en etapas anteriores, para decidir si es ms o menos probable y cundo han cambiado sus posibles efectos. Como no se pueden observar de manera directa, entonces se buscan otros factores que indiquen la probabilidad de riesgos y sus efectos.

Ejemplos de factores que ayudan a la valoracin de diferentes tipos de riesgos.

Ttipo de riesgo Tecnologa o o o Indicadores potenciales entrega retrasada del hardware o del software existencia de informes sobre problemas tecnolgicos baja moral del personal, malas relaciones entre miembros del equipo, disponibilidad de empleo rumores en la empresa falta de iniciativa de la direccin de la empresa rechazo de los miembros del equipo a utilizar herramientas quejas sobre las herramientas CASE peticiones de estaciones de trabajo ms potentes peticiones de muchos cambios en los requerimientos quejas del cliente fracaso en el cumplimiento de los tiempos planificados

Personal

Organizacional

o o o o o o o o

Herramientas

Requerimientos Estimacin

3.2. Control de calidad

Qu es la calidad. De acuerdo con Pressman, la calidad es una actividad de proteccin que se debe aplicar durante todo el proceso de ingeniera del software y abarca los siguientes aspectos: Un enfoque de gestin de calidad. Uso de mtodos y herramientas de software efectivas. Realizacin de revisiones tcnicas formales que se apliquen durante el proceso de ingeniera del software. Realizacin de estrategias de prueba multiescalar. Llevar un control de la documentacin y de los cambios que se realizan Respetar los estndares de desarrollo establecidos Habilitar mecanismos de medicin y de generacin de informes.

Calidad
Otro enfoque de la calidad es que se considera como una caracterstica o atributo de algo. Esta caracterstica deseablemente debe ser mensurable.

Algunos elementos cuyas caractersticas son mensurables, nos encontramos con dos tipos de calidad: Calidad de diseo Calidad de concordancia (grado de cumplimiento)

Control de calidad
El control de calidad abarca las revisiones y pruebas hechas durante el ciclo de desarrollo del software para asegurar que cada producto cumple con los requerimientos que le fueron asignados. La garanta de calidad consiste en la auditoria y las funciones de informacin de la gestin que se realizan.

COSTOS DE CALIDAD
Los costos de calidad estn asociados con la bsqueda de la calidad o con las actividades empleadas para la obtencin de la calidad.

Los costos de calidad se pueden dividir en: Costos de prevencin Costos de evaluacin: Costos de fallo

Costos de calidad
Costos de prevencin:
Planificacin de la calidad Revisiones tcnicas formales Equipo de pruebas Formacin

Costos de evaluacin:
Inspeccin durante el proceso Mantenimiento del equipo Realizacin de pruebas

Costos de calidad
Costos de fallo: Que se evitaran si no se cometieran errores durante el proceso de la ingeniera del software.

Internos: Son los derivados de la deteccin de errores en un producto antes de entregarlo al cliente. (Costos de reparacin del error, revisin del error, etc.) Externos: Son los asociados con errores encontrados cuando el producto ya se ha entregado al cliente. (Resolucin de quejas, sustituciones y devoluciones en productos, soporte de ayuda, etc.)

3.2.1. La tendencia de la calidad

El mercado est exigiendo calidad, pues los grandes clientes que demandan servicios de Tecnologa de Informacin estn exigiendo que sus proveedores tengan un compromiso con la calidad. Es importante que las compaas desarrolladoras de software tomen conciencia de que existen modelos de calidad aplicables a las empresas de software. Pero el camino de la calidad no es un camino corto, toma aos poder conseguir un estndar ISO o CMM y las empresas mexicanas empezaron hace poco.

3.2.1. La tendencia de la calidad

Las organizaciones de sistemas se estn viendo en la obligacin de seguir tendencias internacionales de calidad como las normas CMM, CMMI y el Proceso Unificado de Desarrollo de Software. Adems de los modelos CMM y CMMI, existen otros mucho ms conocidos como el estndar ISO 9001 2000 que tambin mide la calidad, pero es aplicable a las empresas en general mientras que CMM y CMMI estn enfocados a las empresas que desarrollan software.

3.2.2. Aseguramiento de la calidad del software

La garanta de calidad del software es un conjunto de acciones planificado y sistemtico que se hacen necesario para asegurar la calidad del software.

Actividades del equipo de la Gestin de Calidad del Software

Establecer un plan de garanta de calidad del software para el proyecto. Participar en la descripcin del proceso de software elegido para el proyecto. Revisar las actividades de ingeniera del software para verificar que se ajustan al proceso adoptado. Asegurar que las desviaciones sobre el plan y sobre el producto se documentan y se gestionan segn el procedimiento establecido. Auditar las partes o productos de software designados para verificar el ajuste con el proceso del software. Registrar lo que no se ajuste a los requerimientos e informar a los superiores.

3.2.3. Revisiones del software

Las revisiones del software son un filtro en el proceso de ingeniera del software que se aplican en varios momentos del desarrollo del proyecto para detectar errores y defectos de forma que puedan eliminarse. Estas revisiones se basan en aprovechar la diversidad de grupos de personas para: Indicar la necesidad de realizar mejoras en el producto que esta desarrollando otro equipo. Ratificar las partes del producto que no es necesario modificar o mejorar. Lograr un trabajo tcnico de calidad ms uniforme o ms predecible.

Impacto en el costo
Errores encontrados Nmero Coste unitario Total

Llevando a cabo revisiones Durante el diseo Antes de la prueba Durante la prueba Tras la distribucin 22 36 15 3 1,5 6,5 15,0 67,0 33 234 315 201 783 Sin revisiones Antes de la prueba Durante la prueba 22 82 6,5 15,0 143 1230

Tras la distribucin

12

67,0

804
2177

3.2.4. Revisiones tcnicas formales

Una revisin tcnica formal (RTF) a veces denominada inspeccin, es un filtro ms efectivo desde el punto de vista de garanta de calidad.

El objetivo de las RTF es detectar errores cuanto antes para que su impacto sea menor al evitar que se propague a los pasos posteriores. El 50%-60% de los errores de un proyecto se dan en la fase de diseo, mediante las RTF se pueden encontrar el 75% de ellos.

Objetivos de las RTF

Verificar que el software objeto de revisin cumple con los requerimientos propuestos. Detectar errores en la lgica, en la funcin o en la implementacin. Verificar que se estn usando los estndares establecidos. Conseguir que dentro de la compaa se desarrolle el software de forma uniforme.

Conseguir un proyecto ms manejable

Directrices para evitar revisiones incontroladas

Se debe de revisar el producto, no al productor Debe haber una agenda con los temas a revisar y adems se debe tratar de mantener. Las impugnaciones y discusiones deben limitarse. Los problemas deben enunciarse cuando se detectan pero nunca hemos de intentar resolverlos en las propias reuniones. Los revisores deben de tener incluido en su plan de trabajo estas reuniones Estas reuniones pueden utilizarse como entrenamiento para los componentes del equipo menos expertos.

3.2.5. Garanta de calidad estadstica

La garanta de calidad estadstica es una tendencia cada vez ms creciente del mundo del software para obtener ms cuantitativamente la calidad y consta de los siguientes pasos: Agrupar y clasificar la informacin de los errores del software Intentar encontrar la causa de cada error A islar las causas vitales Una vez conocidas los errores trabajar en ellas para corregir los problemas ocasionados.

1. 2. 3. 4.

3.2.6. Fiabilidad del software

La probabilidad de operacin libre de fallos de un programa en un entorno determinado y durante un tiempo especfico.

Otra medida importante es la disponibilidad que es la probabilidad de que un programa funcione de acuerdo con sus requerimientos en un momento determinado

Tiempo Medio de Fallos y Disponibilidad

El TMDF es una medida de fiabilidad til ya que los usuarios finales se enfrentan a fallos y no a los errores. Las siguientes frmulas corresponden al TMEF y la disponibilidad. Donde Tiempo medio entre fallos =TMEF Tiempo medio de fallos=TMDF Tiempo medio de reparacin = TMDR.
TMEF = TMDF + TMDR Disponibilidad = (TMDF / (TMDF+ TMDR)) *100

3.2.7. El plan de aseguramiento de calidad del software

El plan de garanta de calidad del software (SQA) es una especie de mapa para institucionalizar la calidad del software. Este plan lo desarrolla el grupo de calidad del software y el equipo del proyecto, y ha de usarse como plantilla a lo largo del proyecto.

3.2.8. Los estndares de calidad ISO-9000

Los sistemas de garanta de calidad pueden definirse como la estructura organizativa, procesos, etc. necesarios para implementar la gestin de la calidad. La norma ISO-9000 describe esta garanta en trminos genricos de forma que pueda ser aplicable a cualquier negocio o empresa.

Estndar ISO-9001
El estndar ISO-9001 es el estndar de garanta de calidad que se aplica a la ingeniera del software. Contiene 20 requerimientos que deben estar presentes en cualquier sistema de garanta de calidad efectiva. Para que una empresa se registre como ISO-9001 debe establecer normas y procedimientos que afronten los requerimientos mencionados y que puedan demostrar que se estn cumpliendo