1

LECTURA 3. GESTIN DE PROYECTOS DE SOFTWARE Los proyectos software son diferentes por la sola razn de su tamao, esto hace que existan tres categoras diferenciadas de proyectos, con problemas diferentes cada una: Proyectos pequeos: consisten solamente en la implementacin. No tienen costos indirectos importantes. Proyectos grandes: poseen implementacin, pero hay muchas ms cosas. Poseen gerencia de proyecto, control de calidad, capacitacin de personal, hay un plan de mantenimiento, hay documentacin importante para uso interno y externo. Se genera informacin para mercadeo. Proyectos medianos: es un caso intermedio entre los dos anteriores. Un error clsico de la historia de gestin de proyectos fue no advertir la existencia de estas tres categoras diferentes y lo peor, todava seguir pensando que la informacin o la experiencia adquirida en proyectos pequeos puede servir para proyectos medianos y grandes. Este hecho es una causa de los resultados catastrficos en la gestin de proyectos de software. Por otro lado, el tamao del proyecto software tambin determina el tamao del grupo de trabajo, si es un proyecto pequeo, se necesitar un grupo mximo de 3 personas donde la informacin se pueda manejar de manera informal, pero si es un proyecto grande donde involucra un equipo de ms de 10 personas, no se puede confiar en la memoria de los integrantes y adems la comunicacin 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 informacin de manera ms organizada. Pregunta 11. Para la gestin de proyectos software: A. Importan los costos del proyecto de desarrollo de software, pero no tiene mucha importancia su tamao. B. No importa ni el tamao, ni los costos del proyecto de desarrollo de software. C. Hay que tener en cuenta el tamao porque este orienta los recursos que se deben gestionar. D. No se tiene en cuenta el tamao del proyecto porque toda la informacin a manejar siempre es la misma. Pregunta 12. Los equipos de trabajo para proyectos de desarrollo de software, que pueden utilizar una comunicacin de tipo informal estn conformados por: A. B. C. D. Mximo 13 personas Mximo 10 personas Mximo 3 personas Mnimo 10 personas

Pregunta 13. De acuerdo a la categorizacin anterior, un software desarrollado como opcin de grado estara en la categora. A. B. C. D. Proyectos pequeos Proyectos Grandes Proyectos medianos Proyectos Complejos

LECTURA 4. EL PROCESO DE SOFTWARE Y MTRICAS Cuando se empieza un proyecto de desarrollo de software, el primer problema a definir consiste en resolver los siguientes cuestionamientos: Cules son los datos del proyecto? De qu informacin debemos partir? La situacin 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 informacin que se posee es externa, la visin que tiene alguien desde afuera, la visin que tiene el usuario. No se sabe nada interno del proyecto como la cantidad de mdulos a disear, nmero de personas que participarn o lneas de cdigo a generar. A lo sumo se tiene una cierta especificacin 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, debera ser suficiente. Lo que falta en un proyecto nuevo es la informacin de realizacin: costos, tiempo y personas. Lo ideal sera disponer de una mtrica 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 hara la comparacin con las metas externas. Se verificara 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 clsicas de gestin para dividir el proyecto en tareas, tiempos y otros elementos que permitan ejecutarlos. En el caso de replanteo de un proyecto la situacin es opuesta. Se tiene buenos registros de cunto cost el proyecto, en qu tiempo se hizo y cuntas 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 consistira en la recuperacin de los datos externos del proyecto. Para esto se hace una estimacin preliminar. Con esta estimacin se aplica la metodologa 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 informacin a estimar es sobre: A. B. C. D. Personas, software y hardware Tiempo, riesgos e imprevistos Costos, tiempos y personas. Tiempos, software y hardware.

Pregunta 15. Cuando se inicia un nuevo proyecto de software o se replantea uno existente, el proceso de gestin a seguir es: A. Completamente opuesto cuando es el replanteo de uno existente. B. Ms fcil la gestin para el replanteo de uno existente que la gestin de un nuevo proyecto. C. El mismo para ambos casos. D. Ms fcil la gestin de un nuevo proyecto que la gestin para el replanteo de uno existente. Pregunta 6. En un proyecto nuevo la nica informacin con que se cuenta desde el principio, es: A. B. C. D. Nmero de personas que participarn. Algunas metas de costo y plazo de entrega que se deben alcanzar. Lneas de cdigo a generar. La cantidad de mdulos a disear.

LECTURA 5. GESTIN DEL RIESGO Se han producido amplios debates sobre la definicin adecuada para riesgo de software, y hay acuerdo comn en que el riesgo siempre implica dos caractersticas: Incertidumbre: El acontecimiento que caracteriza al riesgo puede o no puede ocurrir; por ejemplo, no hay riesgos de un 100 por ciento de probabilidad. Prdida: Si el riesgo se convierte en una realidad, ocurrirn consecuencias no deseadas o prdidas.

Cuando se analizan los riesgos es importante cuantificar el nivel de incertidumbre y el grado de prdidas asociado con cada riesgo. Para hacerlo, se consideran diferentes categoras 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 planificacin temporal del proyecto se retrase y que los costos aumenten. Los riesgos del proyecto identifican los problemas potenciales de presupuesto, planificacin temporal, personal (asignacin y organizacin), recursos, clientes, requisitos y su impacto en un proyecto de software. Los riesgos tcnicos amenazan la calidad y la planificacin temporal del software que hay que producir. Si un riesgo tcnico se convierte en realidad, la implementacin puede llegar a ser difcil o imposible. Los riesgos tcnicos identifican problemas potenciales de diseo, implementacin, de interfaz, verificacin y de mantenimiento. Adems las ambigedades de especificaciones, incertidumbre tcnica, tcnicas anticuadas y las "tecnologas punta" son tambin factores de riesgo. Los riesgos tcnicos ocurren porque el problema es ms difcil de resolver de lo que pensbamos. 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:

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 compaa (riesgo estratgico), Construir un producto que en departamento de ventas no sabe cmo vender Perder el apoyo de una gestin experta debido a cambios de enfoque o a cambios de personal (riesgo de direccin) Perder presupuesto o personal asignado (riesgos de presupuesto).

Es extremadamente importante recalcar que no siempre funciona una categorizacin tan sencilla. Algunos riesgos son simplemente imposibles de predecir. Los riesgos conocidos son todos aquellos que se pueden descubrir despus de una cuidadosa evaluacin del plan del proyecto del entorno tcnico y comercial en el que se desarrolla el proyecto y otras fuentes de informacin fiables (como fechas de entrega poco realistas, falta de especificacin 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 comunicacin con el cliente, disminucin del esfuerzo del personal a medida que atienden peticiones de mantenimiento) pueden ocurrir pero son extremadamente difciles de identificar por adelantado. Pregunta 17. Los riesgos tcnicos identifican problemas potenciales en cuanto a: A. B. C. D. Diseo, implementacin, presupuesto, cliente y personal. Planificacin temporal, personal, recursos, cliente e impacto. Presupuesto, recursos, personal, requisitos e impacto Diseo, implementacin, interfaz, verificacin 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 caractersticas de hardware que necesita para su ptimo funcionamiento, corresponde a: A. B. C. D. Riesgo de mercado. De presupuesto. Riesgo estratgico. De direccin.

Pregunta 19. Un riesgo en una interfaz de verificacin de datos, corresponde a: A. B. C. D. Riesgo Conocido Riesgo Del Proyecto Riesgo Tcnico Riesgo Predecible

Pregunta 20. Los riesgos del proyecto identifican los problemas potenciales de: A. Presupuesto, planificacin temporal, personal y recursos. B. Diseo, implementacin, cliente y personal C. Diseo, implementacin, interfaz y mantenimiento D. Diseo, implementacin, interfaz y verificacin 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