UNIDAD 3 ANÁLISIS DEL PROYECTO

Transcripción

1 UNIDAD 3 ANÁLISIS 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.

2 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 daño, pérdidas 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 análisis y gestión 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 análisis y gestión de riesgos. Puesto que el software es una empresa difícil, muchas cosas pueden salir mal, por esta razón estar preparados es un elemento clave de una buena gestión de proyecto de software. Los resultados del análisis de riesgos se deben documentar a lo largo del plan de proyecto junto con el análisis de consecuencias cuando el riesgo ocurra. Identificar éstos y crear planes para minimizar sus efectos en el proyecto se llama administración de riesgos. Los riesgos son una amenaza para el proyecto, para el software que se esta desarrollando y para la organización. CATEGORÍAS DE LOS RIESGOS: A) Riesgos del proyecto: Afectan la calendarización o los recursos del proyecto. B) Riesgos del producto: Afectan la calidad o desempeño del software que se esta desarrollando. C) Riesgos del negocio: Afectan a la organización que desarrolla el software. 54

3 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 administración Retrasos en la especificación Cambio de requerimientos No disponibilidad del hardware Rotación de personal Subestimación del tamaño del sistema Cambio de tecnología Competencia del producto Bajo desempeño de la herramienta CASE ETAPAS DEL PROCESO DE ADMINISTRACIÓN DE RIESGOS: 1) Identificación de riesgos: Identificar los posibles riesgos para el proyecto, producto y los negocios. 2) Análisis de riesgos: Valorar las probabilidades y consecuencias de estos riesgos. 3) Planeación de riesgos: Crear planes para abordar los riesgos, ya sea para evitarlos o minimizar sus efectos en el proyecto. 4) Supervisión de riesgos: Valorar los riesgos de forma constante y revisar los planes para la mitigación de riesgos tan pronto como la información de los riesgos este disponible. Identificación de riesgos Análisis de riesgos Planeación de riesgos Supervisión de riesgos Listado de riesgos potenciales Listado de priorización de riesgos Anulación de riesgos y planes de contingencia Valoración de riesgos Los análisis de riesgos, tratan de estudiar, valuar, medir y prevenir los fallos y las averías de los sistemas técnicos 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

4 Durante el proceso de análisis 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 fácil de hacer esto- recae en la opinión y experiencia del administrador de proyecto. No se hace una valoración con números 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 catastróficos, serios, tolerables o insignificantes. El resultado de este proceso de análisis se debe colocar en una tabla, la cual debe estar ordenada acorde a la seriedad del riesgo. RIESGO PROBABILIDAD EFECTOS Los problemas financieros de la organización Baja Catastrófico fuerzan a reducir el presupuesto del proyecto Es imposible reclutar personal con habilidades Alta Catastrófico requeridas para el proyecto El personal clave esta enfermo y no disponible Moderado Serio en momentos críticos Los clientes no comprenden el impacto de los cambios de los requerimientos Moderado Tolerable Para hacer este tipo de valoraciones se necesita información detallada del proyecto, el proceso, el equipo de desarrollo y la organización.tanto la probabilidad y la valoración de los efectos de un riesgo cambia conforme se disponga de mayor información acerca del riesgo y los planes de administración del mismo se implemente, por lo tanto la tabla anterior debe actualizarse durante cada iteración del proceso de riesgo. Una vez que los riesgos se hayan analizado y clasificado, se debe discernir cuales son los más importantes que se deben considerar durante el proyecto.en general, siempre se deben tomar en cuenta todos los riesgos catastróficos así como los serios que tienen más que una moderada probabilidad de ocurrir. 56

5 3.2. CONTROL DE CALIDAD La calidad es un atributo o característica de algo, es decir cosas que se pueden conocer para comparar estándares, como longitud, color, propiedades eléctricas, etc. El software es más difícil de caracterizar que los objetos físicos, entre las principales mediciones de un programa se encuentran: la complejidad ciclomática, número de puntos de función, líneas de código, etc. EXISTEN DOS TIPOS DE CALIDAD: De diseño: Se refiere a las características que los diseñadores especifican para un elemento, incluye requisitos, especificaciones y diseño del sistema. De concordancia: Es el grado en que las especificaciones de diseño se aplican durante la fabricación. Está enfocado a la implementación, si esta sigue el diseño y el sistema resultante satisface sus requisitos y metas de desempeño, 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 retroalimentación 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 retroalimentación 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 estándares de calidad. Los productos resultantes de un proceso del software se comprueban contra los estándares 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 fácilmente comprensibles por los ingenieros que desarrollan el software. 57

6 EXISTEN DOS ENFOQUES COMPLEMENTARIOS PARA EL CONTROL DE CALIDAD: Revisiones de la calidad en las que el software, su documentación y los procesos utilizados para producir ese software son revisados por un grupo de personas. Son responsables de comprobar que se han seguido los estándares del proyecto y que el software y los documentos están acorde a estos estándares. Toman las desviaciones de los estándares y las ponen en consideración de la administración del proyecto. Valoración automática del software en la que el software y los documentos producidos se procesan por algún programa y se comparan con los estándares 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 producción y mantenimiento de productos de programación 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 aplicación. Comunicación en el grupo.- Se considera que la programación 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 aplicación, programas de apoyo y programas del sistema operativo. Notaciones apropiadas.- Son vehículos de comunicación entre el personal asignado al proyecto y plantean la posibilidad de usar una herramienta automatizada de programación para manejar las notaciones verificando su uso correcto. Enfoques sistemáticos.- En cada campo del conocimiento existen ciertos procedimientos y técnicas aceptadas, la existencia de estas prácticas normales son una de las características 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 aplicación específica; algunas veces, el software debe compensar las deficiencias de diseño en el equipo, de tal suerte que se suele estilizarse para satisfacer diferentes requisitos de clientes diversos. 58

7 Nivel tecnológico.- El nivel tecnológico utilizado en un proyecto de programación incluye aspectos como selección del lenguaje, ambiente computacional, prácticas de programación y herramientas de programación disponibles. Nivel de con fiabilidad.- Todo producto de programación debe poseer un nivel elemental de confiabilidad; sin embargo, la alta confiabilidad sólo se consigue con gran cuidado en el análisis, diseño instrumentación pruebas y mantenimiento del producto de programación. Captación del problema.- En un proyecto de programación un asunto común de difícil solución es la incomprensión de la verdadera naturaleza del problema; existen diversos factores que contribuyen en esta falta de conocimiento. Tiempo disponible.- La determinación del nivel óptimo de personal y el tiempo requerido para desarrollar las diferentes actividades en un proyecto de programación es un aspecto importante y difícil en la estimación global de costos y recursos. Especialización requerida.- El ejercicio de la ingeniería de programación requiere de una gran gama de habilidades y especialidades; por ejemplo habilidad para comunicarse, conocimiento del área de aplicación, habilidad para la resolución de problemas, atención en los detalles y más pero no es necesario que todas estas habilidades las tenga una sola persona, por eso existe un equipo de programación. Facilidades y recursos.- Los gerentes de un proyecto de programación deben de ser eficaces en el manejo de los factores de motivación y frustración, si desean mantener la calidad de sus productos, la productividad de sus programadores y la satisfacción del trabajo. Entrenamiento adecuado.- La educación en ciencias de la computación se preocupa por dar entendimiento básico de las teorías y conceptos de la información y su procesamiento, comprendiendo estos términos en el sentido más amplio posible. Habilidades gerenciales.- Los proyectos de programación son, por lo común, supervisados por gerentes que tienen poco conocimiento, y esto muestra una dificultad ya que encuentran que los proyectos de ingeniería de programación son difíciles debido a las diferencias en la metodología de diseño, 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 planeación. 59

8 Expectativas crecientes.- El mayor problema persiste en el crecimiento constante de las expectativas del producto. Existen dos aspectos interrelacionados al respecto: primero, está a preocupación de que tanta funcionalidad, confiabilidad y desempeño puede obtenerse con un esfuerzo determinado; en segundo lugar, se halla el aspecto relacionado con las limitantes de la tecnología de programación. Otros factores.- Existen más factores que influyen en la productividad de los programadores, incluyendo la familiaridad, el acceso y la estabilidad del sistema de cómputo utilizado para desarrollar o modificar los programas; la memoria y limitantes de tiempo del producto y más. VISIÓN GENERAL DE LOS FACTORES QUE AFECTAN A LA CALIDAD: En las dos décadas pasadas, definieron un juego de factores de calidad como los primeros pasos hacia el desarrollo de métricas de la calidad del software. Estos factores evalúan el software desde tres puntos de vista distintos: Operación del producto (utilizándolo). Revisión del producto (cambiándolo). Transición del producto (modificándolo para que funcione en un entorno diferente, p. Ej.: «portándolo»). Los autores, en su trabajo, describen la relación entre estos factores de calidad (lo que llaman un «marco de trabajo» ) y otros aspectos del proceso de ingeniería 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, además de su corrección 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 relación con los objetivos de calidad establecidos. 60

9 En tercer lugar: El marco de trabajo proporciona más interacción del personal de QA en el esfuerzo de desarrollo... Por último: El personal de garantía de calidad puede utilizar indicaciones de calidad pobre para ayudar a identificar estándares [mejores] a contrastar en el futuro. Es interesante destacar que casi todos los aspectos del cálculo han sufrido cambios radicales con el paso de los años. Pero los atributos que proporcionan una indicación de la calidad del software siguen siendo los mismos. Medida de la calidad: Aunque hay muchas medidas de la calidad de software, la corrección, facilidad de mantenimiento integral y facilidad de uso proporcionan indicadores útiles para el equipo del proyecto. DEFINICIONES Y MEDIDAS PARA CADA UNO DE ELLOS: Corrección: Un programa debe operar correctamente o proporcionará poco valor a sus usuarios. La corrección es el grado en el que el software lleva a cabo su función requerida. La medida más común de corrección 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 más esfuerzo que cualquier otra actividad de ingeniería 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 métrica orientada al tiempo es el tiempo medio de cambio (TMC), es decir, el tiempo que se tarda en analizar la petición de cambio, en diseñar. Una modificación adecuada, en implementar el cambio, en probarlo y en distribuir el cambio a todos los usuarios. 61

10 Como media, los programas que son más fáciles de mantener tendrán un TMC más bajo (para tipos equivalentes de cambios) que los programas que son más difíciles de mantener. Ha utilizado una métrica orientada al costo para la capacidad de mantenimiento llamada «desperdicios», el costo en corregir defectos encontrados después de haber distribuido el software a sus usuarios finales. Cuando la proporción de desperdicios en el costo global del proyecto (para muchos proyectos) se representa como una función del tiempo, el gestor puede determinar si la facilidad de mantenimiento total del software producido por una organización de desarrollo está mejorando. Se pueden emprender acciones a partir de las conclusiones obtenidas de esa información. Integridad: En esta época de intrusos informáticos 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 empírica) 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 empírica) 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

11 La facilidad de uso es un intento de cuantificar «lo amigable que puede ser con el (usuario) y se puede medir en función de cuatro características: Habilidad intelectual y/o física 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. Valoración subjetiva (a veces obtenida mediante un cuestionario) de la disposición de los usuarios hacia el sistema. 63