Ingenieria De Software

Esta Lección Evaluativa tiene un puntaje máximo de 8 puntos sobre un total de 500. Se espera que el estudiante haya explorado con anterioridad la Unidad 2.

Los proyectos software son diferentes por la sola razón de su tamaño, esto hace que existan tres categorías diferenciadas de proyectos, con problemas diferentes cada una:

Proyectos pequeños: consisten solamente en la implementación. No tienen costos indirectos importantes.

Proyectos grandes: poseen implementación, pero hay muchas más cosas. Poseen gerencia de proyecto, control de calidad, capacitación de personal, hay un plan de mantenimiento, hay documentación importante para uso interno y externo. Se genera imformación para mercadeo.

Proyectos medianos: es un caso intermedio entre los dos anteriores.

Un error clásico de la historia de gestión de proyectos fue no advertir la existencia de estas tres categorías diferentes y lo peor, todavía seguir pensando que la información o la experiencia adquirida en proyectos pequeños puede servir para proyectos medianos y grandes. Este hecho es una causa de los resultados catastróficos en la gestión de proyectos de software.

Por otro lado, el tamaño del proyecto software tambíen determina el tamaño del grupo de trabajo, si es un proyecto pequeño, se necesitará un grupo máximo de 3 personas donde la información se pueda manejar de manera informal, pero si es un proyecto grande donde involucra un equipo de mas de 10 personas, no se puede confiar en la memoria de los integrantes y además la comunicación no va a ser tan personalizada, ya que por lo general se necesita varios meses de trabajo para lograr los objetivos y esto conlleva a que se lleve la información de manera más organizada.

Cuando se empieza un proyecto de desarrollo de software, el primer problema a definir consiste en resolver los siguientes cuestionamientos: ¿Cuáles son los datos del proyecto? ¿De qué información debemos partir?

La situación o la respuesta es diferente si es un proyecto nuevo o en el replanteo de uno existente.

En un proyecto nuevo no hay nada hecho, la información que se posee es externa, la visión que tiene alguién desde afuera, la visión que tiene el usuario. No se sabe nada interno del proyecto como la cantidad de módulos a diseñar, número de personas que participarán o líneas de código a generar. A lo sumo se tiene una cierta especificación del proyecto y algunas metas de costo y plazo de entrega que se debe alcanzar. Lo que se sabe es muy poco, sin embargo este pobre material, debería ser suficiente. Lo que falta en un proyecto nuevo es la información de realización: costos, tiempo y personas.

Lo ideal sería dipsoner de una métrica aplicada sobre los datos externos que midiera todo lo que hace falta. Luego con estimadores, obtener los costos, tiempo y personas necesarios.

Con estos resultados se haría la comparación con las metas externas. Se verificaría si el costo y el plazo de entrega es aceptable. si no lo es, se debe replantear el proyecto, modificar alguno de sus datos externos si no hay ajustes con las metas y proceder nuevamente a recalcular. Una vez logrado esto, se aplican herramientas clásicas de gestión para dividir el proyecto en tareas, tiempos y otros elementos que permitan ejecutarlos.

En el caso de replanteo de un proyecto la situación es opuesta. Se tiene buenos registros de cuánto costó el proyecto, en qué tiempo se hizo y cuántas personas trabajaron. Pero no se ha registrado nada de los datos externos del proyecto, no se ha medido en lo previo.

El punto de partida consistiría en la recuperación de los datos externos del proyecto. Para esto se hace una estimación preeliminar. Con esta estimación se aplica la metodología sobre los datos externos y se estiman los costos, tiempos y personas. Estos elementos pueden estar registrados, por lo tanto se pueden comparar los valores estimados con los datos del proyecto y realizar los ajustes respectivos.

Se han producido amplios debates sobre la definición adecuada para riesgo de software, y hay acuerdo común en que el riesgo siempre implica dos características:

• Incertidumbre: El acontecimiento que caracteriza al riesgo puede o no puede ocurrir; por ejemplo, no hay riesgos de un 100 por ciento de probabilidad.

• Pérdida: Si el riesgo se convierte en una realidad, ocurrirán consecuencias no deseadas o pérdidas.

Cuando se analizan los riesgos es importante cuantificar el nivel de incertidumbre y el grado de pérdidas asociado con cada riesgo. Para hacerlo, se consideran diferentes categorías de riesgos.

Los riesgos del proyecto amenazan al plan del proyecto. Es decir, si los riesgos del proyecto se hacen realidad, es probable que la planificación temporal del proyecto se retrase y que los costos aumenten. Los riesgos del proyecto identifican los problemas potenciales de presupuesto, planificación temporal, personal (asignación y organización), recursos. cliente y requisitos y su impacto en un proyecto de software.

Los riesgos técnicos amenazan la calidad y la planificación temporal del software que hay que producir. Si un riesgo técnico se convierte en realidad, la implementación puede llegar a ser difícil o imposible. Los riesgos técnicos identifican problemas potenciales de diseño, implementación, de interfaz. verificación y de mantenimiento. Además. las ambigüedades de especificaciones, incertidumbre técnica, técnicas anticuadas y las "tecnologías punta" son también factores de riesgo. Los riesgos técnicos ocurren porque el problema es más difícil de resolver de lo que pensábamos.

Los riesgos del negocio amenazan la viabilidad del software a construir y a menudo ponen en peligro el proyecto o el producto. Los candidatos para los cinco principales riesgos del negocio son:

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

2. Construir un producto que no encaja en la estrategia comercial general de la compañía (riesgo estratégico),

3. Construir un producto que ei departamento de ventas no sabe cómo vender

4. Perder el apoyo de una gestión experta debido a cambios de enfoque o a cambios de personal (riesgo de dirección)

5. Perder presupuesto o personal asignado (riesgos de presupuesto).

Es extremadamente importante

...