UNIDAD 3

ANLISIS DEL PROYECTO

Objetivo:

Analizar

los

riesgos

involucrados en cada una de las etapas del desarrollo del proyecto de software y propondr un protocolo para garantizar la calidad del mismo.

UNIDADIII/PLANIFICACIONYMODELADO

3.1. ANALISIS DE RIESGOS

Un riesgo es un evento capaz de poner en peligro el cumplimiento de los objetivos; es un problema potencial que puede ocurrir o no. Un riesgo es el proceso continuo que se lleva a cabo durante todas las fases del desarrollo de sistemas para estimar el dao, prdidas o perjuicio que puede traer como resultado la imposibilidad de lograr desarrollar con xito las partes de un sistema o de todo ste en su conjunto. El anlisis y gestin de riesgos son una serie de pasos que ayudan a un equipo de software a comprender y manejar la incertidumbre. Muchos problemas pueden desbordar un proyecto de software. Sin importar el resultado de un riesgo, es una buena idea identificarlo, evaluar la probabilidad de que ocurra, estimar su impacto y establecer un plan de contingencia en caso de que el problema se presente. Todos los involucrados en el proceso de desarrollo de software (gestores, ingenieros y participantes) intervienen en el anlisis y gestin de riesgos. Puesto que el software es una empresa difcil, muchas cosas pueden salir mal, por esta razn estar preparados es un elemento clave de una buena gestin de proyecto de software. Los resultados del anlisis de riesgos se deben documentar a lo largo del plan de proyecto junto con el anlisis de consecuencias cuando el riesgo ocurra. Identificar stos y crear planes para minimizar sus efectos en el proyecto se llama administracin de riesgos. Los riesgos son una amenaza para el proyecto, para el software que se esta desarrollando y para la organizacin. CATEGORAS DE LOS RIESGOS: A) B) Riesgos del proyecto: Afectan la calendarizacin o los recursos del proyecto. Riesgos del producto: Afectan la calidad o desempeo del software que se esta

desarrollando. C) Riesgos del negocio: Afectan a la organizacin que desarrolla el software.

54

UNIDADIII/PLANIFICACIONYMODELADO
LOS TIPOS DE RIESGOS QUE PUEDEN AFECTAR UN PROYECTO DEPENDE DE STE Y DEL ENTORNO ORGANIZACIONAL EN EL QUE SE STE

DESARROLLANDO EL MISMO; PERO ENTRE ALGUNOS PODEMOS ENCONTRAR: Cambio de administracin Retrasos en la especificacin Cambio de requerimientos No disponibilidad del hardware Rotacin de personal Subestimacin del tamao del sistema Cambio de tecnologa Competencia del producto Bajo desempeo de la herramienta CASE

ETAPAS DEL PROCESO DE ADMINISTRACIN DE RIESGOS: 1) Identificacin de riesgos: Identificar los posibles riesgos para el proyecto,

producto y los negocios. 2) 3) Anlisis de riesgos: Valorar las probabilidades y consecuencias de estos riesgos. Planeacin de riesgos: Crear planes para abordar los riesgos, ya sea para

evitarlos o minimizar sus efectos en el proyecto. 4) Supervisin de riesgos: Valorar los riesgos de forma constante y revisar los

planes para la mitigacin de riesgos tan pronto como la informacin de los riesgos este disponible.

Identificacin de riesgos

Anlisis de riesgos

Planeacin de riesgos

Supervisin de riesgos

Listado de riesgos potenciales

Listado de priorizacin deriesgos

Anulacin de riesgos y planesde contingencia

Valoracin de riesgos

Los anlisis de riesgos, tratan de estudiar, valuar, medir y prevenir los fallos y las averas de los sistemas tcnicos y de los procedimientos operativos que pueden iniciar y desencadenar sucesos no deseados (accidentes) que afecten a las personas, los bienes y el medio ambiente.

55

UNIDADIII/PLANIFICACIONYMODELADO
Durante el proceso de anlisis de riesgo, se considera por separado cada riesgo identificado y se decide acerca de la probabilidad y la seriedad del mismo. No existe una forma fcil de hacer esto- recae en la opinin y experiencia del administrador de proyecto. No se hace una valoracin con nmeros precisos sino en intervalos: 1.- La probabilidad de que el riesgo se valore como muy bajo(<10%), bajo (10-25%), moderado (2-50%), alto(50-75%) y muy alto (>75%). 2.-Los efectos del riesgo pueden ser valorados como catastrficos, serios, tolerables o insignificantes. El resultado de este proceso de anlisis se debe colocar en una tabla, la cual debe estar ordenada acorde a la seriedad del riesgo.

RIESGO Los problemas financieros de la organizacin fuerzan a reducir el presupuesto del proyecto Es imposible reclutar personal con habilidades requeridas para el proyecto El personal clave esta enfermo y no disponible en momentos crticos Los clientes no comprenden el impacto de los cambios de los requerimientos

PROBABILIDAD Baja

EFECTOS Catastrfico

Alta

Catastrfico

Moderado

Serio

Moderado

Tolerable

Para hacer este tipo de valoraciones se necesita informacin detallada del proyecto, el proceso, el equipo de desarrollo y la organizacin.Tanto la probabilidad y la valoracin de los efectos de un riesgo cambia conforme se disponga de mayor informacin acerca del riesgo y los planes de administracin del mismo se implemente, por lo tanto la tabla anterior debe actualizarse durante cada iteracin del proceso de riesgo. Una vez que los riesgos se hayan analizado y clasificado, se debe discernir cuales son los ms importantes que se deben considerar durante el proyecto.En general, siempre se deben tomar en cuenta todos los riesgos catastrficos as como los serios que tienen ms que una moderada probabilidad de ocurrir.

56

UNIDADIII/PLANIFICACIONYMODELADO

3.2. CONTROL DE CALIDAD

La calidad es un atributo o caracterstica de algo, es decir cosas que se pueden conocer para comparar estndares, como longitud, color, propiedades elctricas, etc. El software es ms difcil de caracterizar que los objetos fsicos, entre las principales mediciones de un programa se encuentran: la complejidad ciclomtica, nmero de puntos de funcin, lneas de cdigo, etc. EXISTEN DOS TIPOS DE CALIDAD: De diseo: Se refiere a las caractersticas que los diseadores especifican para un elemento, incluye requisitos, especificaciones y diseo del sistema. De concordancia: Es el grado en que las especificaciones de diseo se aplican durante la fabricacin. Est enfocado a la implementacin, si esta sigue el diseo y el sistema resultante satisface sus requisitos y metas de desempeo, entonces la calidad de concordancia es alta. El control de calidad involucra una serie de inspecciones, revisiones y pruebas empleadas a los largo del proceso de software para garantizar que cada producto de trabajo satisfaga los requisitos que se le han asignado. Incluye un bucle de retroalimentacin con el proceso que cre el producto de trabajo. Un concepto clave en control de calidad es que todos los productos de trabajo tienen especificaciones definidas con las cuales se puede comparar la salida de cada proceso, el bucle de retroalimentacin es esencial para minimizar los defectos del producto. El control de calidad implica vigilar el proceso de desarrollo del software para asegurar que se sigan los procedimientos y estndares de calidad. Los productos resultantes de un proceso del software se comprueban contra los estndares definidos del proyecto en el proceso de control de calidad. El proceso de control de calidad tiene su propio conjunto de procedimientos e informes a utilizar durante el desarrollo del software, estos son directos y fcilmente comprensibles por los ingenieros que desarrollan el software.

57

UNIDADIII/PLANIFICACIONYMODELADO
EXISTEN DOS ENFOQUES COMPLEMENTARIOS PARA EL CONTROL DE CALIDAD: Revisiones de la calidad en las que el software, su documentacin y los procesos utilizados para producir ese software son revisados por un grupo de personas. Son responsables de comprobar que se han seguido los estndares del proyecto y que el software y los documentos estn acorde a estos estndares. Toman las desviaciones de los estndares y las ponen en consideracin de la administracin del proyecto.

Valoracin automtica del software en la que el software y los documentos producidos se procesan por algn programa y se comparan con los estndares que aplican a ese proyecto de desarrollo en particular; comprende una medida cuantitativa de algunos atributos del software FACTORES QUE INFLUYEN EN LA CALIDAD Y PRODUCTIVIDAD: Capacidad individual.- La produccin y mantenimiento de productos de programacin son tareas laboriosas, por lo que la productividad y la calidad son funciones directas de la capacidad y esfuerzo individuales. Existen dos aspectos en la capacidad: la competencia global del individuo y su familiaridad con el rea particular de aplicacin. Comunicacin en el grupo.- Se considera que la programacin es una actividad individual y privada de modo que muchos programadores tiene poco contacto social y prefieren trabajar en forma aislada. Complejidad del producto.- Existen tres niveles de complejidad en un producto generalmente aceptado: programas de aplicacin, programas de apoyo y programas del sistema operativo. Notaciones apropiadas.- Son vehculos de comunicacin entre el personal asignado al proyecto y plantean la posibilidad de usar una herramienta automatizada de programacin para manejar las notaciones verificando su uso correcto. Enfoques sistemticos.En cada campo del conocimiento existen ciertos

procedimientos y tcnicas aceptadas, la existencia de estas prcticas normales son una de las caractersticas que distinguen esta disciplina profesional. Control de cambios.- Desde un punto de vista muy real, los programas sirven para que un equipo de uso general se adapte al empleo de una aplicacin especfica; algunas veces, el software debe compensar las deficiencias de diseo en el equipo, de tal suerte que se suele estilizarse para satisfacer diferentes requisitos de clientes diversos.

58

UNIDADIII/PLANIFICACIONYMODELADO
Nivel tecnolgico.- El nivel tecnolgico utilizado en un proyecto de programacin incluye aspectos como seleccin del lenguaje, ambiente computacional, prcticas de programacin y herramientas de programacin disponibles. Nivel de con fiabilidad.- Todo producto de programacin debe poseer un nivel elemental de confiabilidad; sin embargo, la alta confiabilidad slo se consigue con gran cuidado en el anlisis, diseo instrumentacin pruebas y mantenimiento del producto de programacin. Captacin del problema.- En un proyecto de programacin un asunto comn de difcil solucin es la incomprensin de la verdadera naturaleza del problema; existen diversos factores que contribuyen en esta falta de conocimiento. Tiempo disponible.- La determinacin del nivel ptimo de personal y el tiempo requerido para desarrollar las diferentes actividades en un proyecto de programacin es un aspecto importante y difcil en la estimacin global de costos y recursos. Especializacin requerida.- El ejercicio de la ingeniera de programacin requiere de una gran gama de habilidades y especialidades; por ejemplo habilidad para comunicarse, conocimiento del rea de aplicacin, habilidad para la resolucin de problemas, atencin en los detalles y ms pero no es necesario que todas estas habilidades las tenga una sola persona , por eso existe un equipo de programacin. Facilidades y recursos.- Los gerentes de un proyecto de programacin deben de ser eficaces en el manejo de los factores de motivacin y frustracin, si desean mantener la calidad de sus productos, la productividad de sus programadores y la satisfaccin del trabajo. Entrenamiento adecuado.- La educacin en ciencias de la computacin se preocupa por dar entendimiento bsico de las teoras y conceptos de la informacin y su procesamiento, comprendiendo estos trminos en el sentido ms amplio posible. Habilidades gerenciales.- Los proyectos de programacin son, por lo comn, supervisados por gerentes que tienen poco conocimiento, y esto muestra una dificultad ya que encuentran que los proyectos de ingeniera de programacin son difciles debido a las diferencias en la metodologa de diseo, notaciones, herramientas y otros aspectos. Metas apropiadas.- Se puede obtener un punto medio entre la productividad y los factores de calidad, mediante en mantenimiento dentro de las metas y requisitos establecidos para el producto durante la etapa de planeacin.

59

UNIDADIII/PLANIFICACIONYMODELADO
Expectativas crecientes.- El mayor problema persiste en el crecimiento constante de las expectativas del producto. Existen dos aspectos interrelacionados al respecto: primero, est a preocupacin de que tanta funcionalidad, confiabilidad y desempeo puede obtenerse con un esfuerzo determinado; en segundo lugar, se halla el aspecto relacionado con las limitantes de la tecnologa de programacin. Otros factores.- Existen ms factores que influyen en la productividad de los programadores, incluyendo la familiaridad, el acceso y la estabilidad del sistema de cmputo utilizado para desarrollar o modificar los programas; la memoria y limitantes de tiempo del producto y ms. VISIN GENERAL DE LOS FACTORES QUE AFECTAN A LA CALIDAD: En las dos dcadas pasadas, definieron un juego de factores de calidad como los primeros pasos hacia el desarrollo de mtricas de la calidad del software. Estos factores evalan el software desde tres puntos de vista distintos: Operacin del producto (utilizndolo). Revisin del producto (cambindolo). Transicin del producto (modificndolo para que funcione en un entorno

diferente, p.

Ej.: portndolo). Los autores, en su trabajo, describen la relacin entre estos factores de calidad (lo que llaman un marco de trabajo ) y otros aspectos del proceso de ingeniera del software: En primer lugar: El marco de trabajo proporciona un mecanismo para que el gestor del proyecto identifique lo que considera importante. Estas cualidades son atributos del software, adems de su correccin y rendimiento funcional, que tiene implicaciones en el ciclo de vida. En otros factores, como son facilidad de mantenimiento y transportabilidad, se ha demostrado que tienen un impacto significativo en el costo del ciclo de vida... En segundo lugar: El marco de trabajo proporciona un medio de evaluar cuantitativamente lo bien que va progresando el desarrollo en relacin con los objetivos de calidad establecidos.

60

UNIDADIII/PLANIFICACIONYMODELADO
En tercer lugar: El marco de trabajo proporciona ms interaccin del personal de QA en el esfuerzo de desarrollo... Por ltimo: El personal de garanta de calidad puede utilizar indicaciones de calidad pobre para ayudar a identificar estndares [mejores] a contrastar en el futuro. Es interesante destacar que casi todos los aspectos del clculo han sufrido cambios radicales con el paso de los aos. Pero los atributos que proporcionan una indicacin de la calidad del software siguen siendo los mismos. Medida de la calidad: Aunque hay muchas medidas de la calidad de software, la correccin, facilidad de mantenimiento integral y facilidad de uso proporcionan indicadores tiles para el equipo del proyecto. DEFINICIONES Y MEDIDAS PARA CADA UNO DE ELLOS: Correccin: Un programa debe operar correctamente o proporcionar poco valor a sus usuarios. La correccin es el grado en el que el software lleva a cabo su funcin requerida. La medida ms comn de correccin son los defectos, en donde un defecto se define como una falta verificada de conformidad con los requisitos Facilidad de mantenimiento: El mantenimiento del software cuenta con ms esfuerzo que cualquier otra actividad de ingeniera del software. La facilidad de mantenimiento es la facilidad con la que se puede corregir un programa si se encuentra un error, se puede adaptar si su entorno cambia, o mejorar si el cliente desea un cambio de requisitos. No hay forma de medir directamente la facilidad de mantenimiento; por consiguiente, se deben utilizar medidas indirectas. Una simple mtrica orientada al tiempo es el tiempo medio de cambio (TMC), es decir, el tiempo que se tarda en analizar la peticin de cambio, en disear. Una modificacin adecuada, en implementar el cambio, en probarlo y en distribuir el cambio a todos los usuarios.

61

UNIDADIII/PLANIFICACIONYMODELADO
Como media, los programas que son ms fciles de mantener tendrn un TMC ms bajo (para tipos equivalentes de cambios) que los programas que son ms difciles de mantener. Ha utilizado una mtrica orientada al costo para la capacidad de mantenimiento llamada desperdicios, el costo en corregir defectos encontrados despus de haber distribuido el software a sus usuarios finales. Cuando la proporcin de desperdicios en el costo global del proyecto (para muchos proyectos) se representa como una funcin del tiempo, el gestor puede determinar si la facilidad de mantenimiento total del software producido por una organizacin de desarrollo est mejorando. Se pueden emprender acciones a partir de las conclusiones obtenidas de esa informacin. Integridad: En esta poca de intrusos informticos y de virus, la integridad del software ha llegado a tener mucha importancia. Este atributo mide la habilidad de un sistema para resistir ataques (tanto accidentales como intencionados) contra su seguridad. El ataque se puede realizar en cualquiera de los tres componentes del software: programas, datos y documentos. Para medir la integridad, se tienen que definir dos atributos adicionales: amenaza y seguridad. Amenaza es la probabilidad (que se puede estimar o deducir de la evidencia emprica) de que un ataque de un tipo determinado ocurra en un tiempo determinado. La seguridad es la probabilidad (que se puede estimar o deducir de la evidencia emprica) de que se pueda repeler el ataque de un tipo determinado. La integridad del sistema se puede definir como: integridad = E [1- amenaza x (1- seguridad)] Donde se suman la amenaza y la seguridad para cada tipo de ataque. Facilidad de uso: El calificativo amigable con el usuario se ha convertido en omnipresente en las discusiones sobre productos de software. Si un programa no es amigable con el usuario, frecuentemente est abocado al fracaso, incluso aunque las funciones que realice sean valiosas.

62

UNIDADIII/PLANIFICACIONYMODELADO
La facilidad de uso es un intento de cuantificar lo amigable que puede ser con el (usuario) y se puede medir en funcin de cuatro caractersticas: Habilidad intelectual y/o fsica requerida para aprender el sistema. El tiempo requerido para llegar a ser moderadamente eficiente en el uso del sistema. Aumento neto en productividad (sobre el enfoque que el sistema reemplaza) medida cuando alguien utiliza el sistema moderadamente y eficientemente.

Valoracin subjetiva (a veces obtenida mediante un cuestionario) de la disposicin de los usuarios hacia el sistema.

63