1

LECTURA 3. GESTIÓN DE PROYECTOS DE SOFTWARE

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 informació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 también 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 más 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.

Pregunta 11. Para la gestión de proyectos software:

A. Importan los costos del proyecto de desarrollo de software, pero no tiene mucha importancia su tamaño.

B. No importa ni el tamaño, ni los costos del proyecto de desarrollo de software. C. Hay que tener en cuenta el tamaño porque este orienta los recursos que se deben

gestionar. D. No se tiene en cuenta el tamaño del proyecto porque toda la información a manejar

siempre es la misma.

Pregunta 12. Los equipos de trabajo para proyectos de desarrollo de software, que pueden utilizar una comunicación de tipo informal están conformados por:

A. Máximo 13 personas B. Máximo 10 personas C. Máximo 3 personas D. Mínimo 10 personas

2

Pregunta 13. De acuerdo a la categorización anterior, un software desarrollado como opción de grado estaría en la categoría.

A. Proyectos pequeños B. Proyectos Grandes C. Proyectos medianos D. Proyectos Complejos

LECTURA 4. EL PROCESO DE SOFTWARE Y MÉTRICAS

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 alguien 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 disponer 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 son aceptables. 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 re calcular. 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 preliminar. 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.

Pregunta 14. Cuando se inicia un nuevo proyecto software la primera información a estimar es sobre:

A. Personas, software y hardware B. Tiempo, riesgos e imprevistos C. Costos, tiempos y personas. D. Tiempos, software y hardware.

3

Pregunta 15. Cuando se inicia un nuevo proyecto de software o se replantea uno existente, el

proceso de gestión a seguir es:

A. Completamente opuesto cuando es el replanteo de uno existente. B. Más fácil la gestión para el replanteo de uno existente que la gestión de un nuevo

proyecto. C. El mismo para ambos casos. D. Más fácil la gestión de un nuevo proyecto que la gestión para el replanteo de uno

existente.

Pregunta 6. En un proyecto nuevo la única información con que se cuenta desde el principio, es:

A. Número de personas que participarán. B. Algunas metas de costo y plazo de entrega que se deben alcanzar. C. Líneas de código a generar. D. La cantidad de módulos a diseñar.

LECTURA 5. GESTIÓN DEL RIESGO

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, clientes, 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:

4

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

mercado), • Construir un producto que no encaja en la estrategia comercial general de la compañía

(riesgo estratégico), • Construir un producto que en departamento de ventas no sabe cómo vender • Perder el apoyo de una gestión experta debido a cambios de enfoque o a cambios de

personal (riesgo de dirección) • Perder presupuesto o personal asignado (riesgos de presupuesto).

Es extremadamente importante recalcar que no siempre funciona una categorización tan

sencilla. Algunos riesgos son simplemente imposibles de predecir.

Los riesgos conocidos son todos aquellos que se pueden descubrir después de una cuidadosa evaluación del plan del proyecto del entorno técnico y comercial en el que se desarrolla el proyecto y otras fuentes de información fiables (como fechas de entrega poco realistas, falta de especificación de requisitos y de ámbito del software o un entorno pobre de desarrollo), los riesgos predecibles se extrapolan de la experiencia en proyectos anteriores (como cambios de personal, mala comunicación con el cliente, disminución del esfuerzo del personal a medida que atienden peticiones de mantenimiento) pueden ocurrir pero son extremadamente difíciles de identificar por adelantado.

Pregunta 17. Los riesgos técnicos identifican problemas potenciales en cuanto a:

A. Diseño, implementación, presupuesto, cliente y personal. B. Planificación temporal, personal, recursos, cliente e impacto. C. Presupuesto, recursos, personal, requisitos e impacto D. Diseño, implementación, interfaz, verificación y mantenimiento.

Pregunta 18. El riesgo que se presenta cuando se desarrolla un software que nadie va a

interesarse en comprar o utilizar por las características de hardware que necesita para su óptimo funcionamiento, corresponde a:

A. Riesgo de mercado. B. De presupuesto. C. Riesgo estratégico. D. De dirección.

Pregunta 19. Un riesgo en una interfaz de verificación de datos, corresponde a:

A. Riesgo Conocido B. Riesgo Del Proyecto C. Riesgo Técnico D. Riesgo Predecible

5

Pregunta 20. Los riesgos del proyecto identifican los problemas potenciales de: A. Presupuesto, planificación temporal, personal y recursos. B. Diseño, implementación, cliente y personal C. Diseño, implementación, interfaz y mantenimiento D. Diseño, implementación, interfaz y verificación

HOJA DE RESPUESTAS

Pregunta 11. C Pregunta 12. C Pregunta 13. C Pregunta 14. C Pregunta 15. A Pregunta 16. B Pregunta 17. D Pregunta 18. A Pregunta 19. C Pregunta 20. A