Estimacion Para Proyectos de Software

INGENIERÍA DE SOFTWARE

3er. AÑO

Lic. Wilma Argandoña Blanco

ESTIMACION PARA PROYECTOS DE SOFTWARE

Antes de iniciar el proyecto el equipo debe estimar el trabajo que deberá realizarse, los recursos que se requerirán y el tiempo que transcurrirá desde el principio hasta el final. La PLANIFICACIÓN DEL PROYECTO de software abarca

cinco grandes

actividades, estimación,

calendarización, calendarización, análisis análisis de riesgos, planificación planificación de la gestión gestión de la calidad calidad y planificación planificación de la gestión de cambio

La estimación es un tanto un arte como una ciencia pero aun así esta actividad no debe hacerse de manera improvisada sino con ayuda de métricas y perspectivas perspecti vas históricas para poder desarrollar y revisar estimaciones. Mientras más se conozca del proyecto mejor se estimara en consecuencia se deben actualizar las estimaciones conforme avance el proyecto. Existen diferentes diferentes tareas para la planificación planificación del proyecto. 1. Establecer el ámbito del proyecto 2. Determinar la factibilidad 3. Analizar riesgos 4. Definir recursos requeridos 5. Estimar costo y esfuerzo 6. Desarrollar Desarrollar un plan de proyecto proyecto La factibilidad del proyecto es importante, pero una consideración de las necesidades del negocio es incluso más importante no es bueno construir un sistema sistema o producto de alta tecnología que nadie requiere El software es el recurso más costoso en cualquier sistema basado en computadora y por lo tanto la

estimación estimación es de lo más impórtate ya que hacerlo de una manera incorrecta puede hacer la diferencia entre ganancia o pérdida. Existen demasiadas variables para hacer alguna estimación exacta como humanas, técnicas, ambientales, políticas. políticas. etc. todas estas pueden pueden afectar el costo final el el costo del del software y el esfuerzo esfuerzo Para lograr mejores estimaciones se puede. 1. Demorar la estimación hasta lo más tarde del proyecto 2. Basar estimaciones en proyectos similares 3. Emplear técnicas de descomposición relativamente simples para generar estimaciones de costo y esfuerzo del proyecto. 4. Utilizar uno o más modelos empíricos en la estimación de costos y esfuerzos El tamaño del software que se construirá puede medirse directamente utilizando LDC (LOC) o indirectamente con PF Además de estos existen otras forma de hacer estimaciones como casos de uso o procesos, si no existe concordancia entre estas y se debe reevaluar se debe a posiblemente dos causas: - El planificador no ha entendido o ha definido mal el ámbito - Los datos de productividad que utilizan las técnicas de estimaciones basadas en el problema son inapropiados para la aplicación, obsoletos o se han aplicado mal.

1


3er. AÑO


CALENDARIZACION DE PROYECTOS DE SOFTWARE Es crear una red de tareas de ingeniería de software que permitan tener el trabajo justo a tiempo, esta red debe tener responsabilidades asignadas, asegurarse que dichas tareas se realicen y adaptar la red conforme los riesgos se tornen en realidad. Los proyectos de software usualmente se entrega con retraso debido a:

-

Una fecha limite irrealizable establecida por alguien externo al grupo de ingeniería.

-

Cambios en los requisitos del cliente que no se reflejan en modificaciones al calendario

-

Una subestimación razonable de la cantidad de esfuerzo o de recursos que se requerirán

-

para realizar el trabajo Riesgos predecibles y/o impredecibles que no se consideraron al iniciar el proyecto Dificultades humanas imprevisibles Falta de comunicación entre el personal del proyecto que da como resultado demoras Una falla en la gestión del proyecto y una falta de acción para corregir el problema

Qué se debe hacer con fechas de entrega irrealizables Rechazar el proyecto –NO Ordenar al cliente que cambie la fecha –NO - Se debe realizar una estimación detallada usando datos históricos de proyectos anteriores. - Con el modelo de proceso incremental, desarrollar una estrategia que entregue funcionalidad. - Reunirse con el cliente y explicarle la estimación detallada y decirle porque la fecha es irrealizable - Ofrezca una estrategia de desarrollo incremental como alternativa.

PRINCIPIOS BÁSICOS Existen distintos principios básicos que guían la calendarización del proceso:

Compartimentalizacion Interdependencia Asignación de Tiempo Validación del esfuerzo Responsabilidades definidas Resultados definidos Hitos definidos Compartimentalización: El proyecto se debe compartir en algunas actividades y tareas manejables. Para lograr la compartimentalización se desglosan tanto el producto como el proceso.

2


3er. AÑO


Interdependencia: Debe determinarse la interdependencia de cada actividad o tarea compartimentalizada. Algunas tareas debe sucederse en secuencia, mientras que otras pueden ocurrir en paralelo. Algunas actividades no pueden comenzar hasta que esté disponible el producto operativo producido por otra. Otras pueden realizarse de manera independiente Asignación de tiempo: A cada tarea por calendarizar debe asignársele cierto número de unidades de trabajo (por ejemplo, persona-días de esfuerzo). Además, a cada tarea debe asignársele una fecha de comienzo y una conclusión.

Validación de Esfuerzo: Todo proyecto tiene un número definido de personas en el equipo de software.

Responsabilidades definidas: Cada tarea por calendarizar debe asignarse a un miembro de equipo específico.

Resultados definidos: Cada tarea que se calendarice debe tener un resultado definido. Hitos Definidos: Cada tarea o grupo de tareas debe asociarse con un hito del proyecto. Un hito se logra cuando uno o más productos operativos se revisan en su calidad y se aprueban. Existe el mito que al agregar personas a un proyecto atrasado este puede finalizarse en el tiempo estimado con éxito, esto es muchas veces mentira ya que las nuevas personas primero deben ponerse al corriente y los que previamente están involucrados deben enseñar a los nuevos, si se desea agregar personas a un proyecto se debe observar que la tarea sea altamente compartimentada.

REGLA 40-20-40 Esta es una regla que usualmente se sigue, en la cual se asigna el 40% del esfuerzo al análisis y diseño de software, el 20% del esfuerzo a la codificación y el ultimo 40% a la realización de pruebas del sistema, esta distribución se utiliza como guía, la distribución final del proceso la dictan las características del proyecto:

TIPOS DE PROYECTOS: Existen distintos tipos de proyectos de software entre e llos: Proyectos de desarrollo de concepto Proyectos de desarrollo de nuevas aplicaciones Proyectos de mejora de aplicación Proyectos de mantenimiento de aplicación Proyectos de reingeniería

1. Proyectos de desarrollo de concepto: que inician para explorar algún concepto empresarial nuevo o la aplicación de alguna nueva tecnología. 2. Proyectos de desarrollo de nueva aplicación: que se realizan como consecuencia de la solicitud de un cliente específico. 3. Proyectos de mejora de aplicación: que ocurren cuando un software existente experimenta grandes modificaciones a funciones, rendimiento, o interfaces que son observables por el usuario final. 3


3er. AÑO


4. Proyectos de mantenimiento de aplicación: que corrigen, adaptan o extienden el software existente de maneras que pueden no ser inmediatamente obvias para el usuario final. 5. Proyectos de Reingeniería: que se llevan a cabo con la intención de reconstruir un sistema existente (heredado) en todo o en parte. Dependiendo del tipo de proyecto y actividades dentro del proyecto se pueden seleccionar el tipo de tareas que se realizaran RED DE TAREAS Una red de tarea es una representación gráfica de flujo de tareas para un proyecto

Es importante siempre encontrar la ruta crítica es decir aquellas que deben concluirse conforme al calendario si el proyecto como un todo debe completarse de acuerdo con ese calendario (es decir a tiempo). CRONOGRAMAS.

Un cronograma o gráfico de Gantt permite determinar que tareas se realizan en un punto de tiempo dado, es posible crear un cronograma general y luego crear cronogramas para cada actividad o tarea. SEGUIMIENTO DEL CALENDARIO

Si se desarrolló de manera adecuada, e l calendario del proyecto se convierte en un mapa de caminos que define las tareas e hitos que se van a monitorear y controlar conforme el proyecto avance. El seguimiento del calendario puede hacerse de diferentes mane ras: -

Realizando reuniones periódicas

-

Haciendo evaluaciones de los resultados de todas las revisiones realizadas a lo largo del proceso de ingeniería de software

-

Determinando si se han logrado los hitos en las fechas establecidas.

-

comprobando la fecha real con la fecha de inicio prevista para cada actividad

4


3er. AÑO


GESTION DEL RIESGO El riesgo se relaciona con acontecimientos futuros, y la gestión de riesgos son una serie de pasos que ayudan a un equipo de software a comprender y manejar la incertidumbre, un riesgo es un problema potencial que puede ocurrir o no y es recomendable identificarlo y crear un plan para saber qué hacer en caso que este se de. ESTRATEGIAS DE RIESGO PROACTIVAS Y REACTIVAS Reactiva : supervisa el proyecto en prevención de posibles riesgos. Los recursos se ponen aparte, en caso de que pudieran convertirse en problemas. Lo más frecuente es que el equipo de software no haga nada respecto a los riesgos hasta que algo va mal. Proactiva: empieza mucho antes de que comiencen los trabajos técnicos. Se identifican los riesgos potenciales, se valoran su probabilidad y su impacto y se establece una prioridad según su importancia. Después el equipo de software establece un plan para controlar el riesgo. Ante un riesgo se puede tomar una posición reactiva o proactiva. RIESGOS DEL SOFTWARE El riesgo siempre implica dos características: - Incertidumbre: el acontecimiento que caracteriza al riego puede o no ocurrir. - Pérdida: si el riesgo se convierte en una realidad, ocurrirán consecuencias no deseadas ó pérdidas. - Cuando se analizan los riegos es importante cuantificar el nivel de incertidumbre y grado de pérdida asociados a cada riego. Para hacerlo se consideran diferentes categorías de riesgos:

-

-

Riesgos del proyecto: si se hacen realidad , es posible que la planificación temporal del proyecto se retrase y que los costos aumenten (problemas potenciales de personal, cliente, requisitos, etc). Riesgos técnicos: amenazan la calidad y la planificación temporal del software (problemas de diseño, implementación, interfaz, verificación, mantenimiento- ambigüedades de especificaciones, incertidumbres técnicas, etc.) Riesgos empresariales: amenazan la viabilidad del software a construir. A menudo ponen en peligro el proyecto o el producto.

Candidatos para los 5 principales riesgos empresariales: 

Construir un producto o sistema excelente que no quiere nadie en realidad (riesgo de mercado )

5

INGENIERÍA DE SOFTWARE 

 



3er. AÑO


Construir un producto que no encaja en la estrategia comercial general de la compañía (riesgo estratégico) Construir un producto que el departamento de ventas no sabe cómo vender Perder el apoyo de una gestión experta debido a cambios de enfoque o cambios de personal. Perder presupuesto o personal asignado.

Otra categorización:

-

Riesgos conocidos: se pueden descubrir después de una cuidadosa evaluación del plan del proyecto. Riesgos predecibles: se extrapolan de la experiencia en proyectos anteriores. Riesgos impredecibles: son difíciles de identificar por adelantado.

La SEI (Software Engineering Institute) identifica siete principios que “ofrecen un marco conceptual para lograr una administración de riesgo efectiva ”. Estos son: 1. Mantener una perspectiva global 2. Tener una visión previsora 3. Alentar la comunicación abierta 4. Integración 5. Enfatizar un proceso continuo 6. Desarrollo de una visión de producto compartida 7. Alentar el trabajo en equipo

IDENTIFICACION DEL RIESGO La identificación del riesgo es un intento sistemático para especificar las amenazas al plan del proyecto. Existen dos tipos: - Riesgos genéricos: Son una amenaza potencial para todos los proyectos de software. - Riesgos específicos: se pueden identificar si se tiene una clara visión de la tecnología, el personal y el entorno específico del proyecto.

Es importante identificar los riesgos genéricos, pero los riesgos específicos son los que provocan mayores problemas, asegúrese de identificar tantos riesgos como sea posible. Un método para identificar riesgos es crear una lista de comprobación de elementos de riegos. 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 - entorno del proceso - impacto en el negocio - entorno a construir - características del cliente - tecnología a construir - definición del proceso - tamaño y experiencia de la plantilla. Componentes de riesgo: 6

INGENIERÍA DE SOFTWARE -

3er. AÑO


riesgo de rendimiento: el grado de incertidumbre con el que el producto encontrara sus requisitos y se adecue para su empleo pretendido. riegos 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 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.

PROYECCION DEL RIESGO También denominada estimación del riesgo, intenta medir el riesgo de dos maneras: - la probabilidad de que el riego sea real las consecuencias de los problemas asociados con el riesgo, si ocurriera.

Cuatro actividades de proyección de riesgo: 1) establecer una escala que refleje la probabilidad percibida del riego. 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 riego de manera que no haya confusiones.

Valoración de impacto de riesgo Existen tres factores que afectan las consecuencias que son probables si un riesgo ocurre, su naturaleza, ámbito y tiempo, se recomienda los siguientes pasos para determinar las consecuencias globales del riesgo

1. Determinar el valor promedio de la probabilidad de que ocurra para cada componente de riesgo. 2. Determinar el impacto para cada componente con base en criterios mostrados en la tabla anterior 7


3er. AÑO


3. Completar la tabla de riesgos y analizar los resultados La Exposición al Riesgo Global ER se determina según la relación ER= P*C P: probabilidad que ocurra el riesgo C: costo proyectado en caso que ocurra el riesgo

Compárese la ER de todos los riesgos si la ER es mayor del 50 por ciento del costo total del proyecto se debe reevaluar la viabilidad del proyecto.

8

Estimacion Para Proyectos de Software

Recommend Documents