Esta Leccin Evaluativa tiene un puntaje mximo 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 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 imformacin 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 tamben 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 mas 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.

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 alguin 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 dipsoner 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 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 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 preeliminar. 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.

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. cliente y 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:

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 compaa (riesgo estratgico), 3. Construir un producto que ei departamento de ventas no sabe cmo vender 4. Perder el apoyo de una gestin experta debido a cambios de enfoque o a cambios de personal (riesgo de direccin) 5. 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 (p. ej.: fechas de entrega poco realistas. falta de especificacin de requisitos o de mbito del software. o un entorno pobre de desarrollo), los riesgos predecibles se extrapolan de la experiencia en proyectos anteriores (ej.: cambio 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.

Esta Leccin Evaluativa tiene un mximo puntaje de 25 puntos sobre un total de 500. Se espera que el estudiante haya realizado con anterioridad una lectura completa de la Unidad 2. La gestin de proyectos de software es una actividad protectora dentro de la Ingeniera de software. Empieza antes de iniciar cualquier actividad tcnica y contina a lo largo de la definicin, del desarrollo y del mantenimiento del software. La gestin eficaz de un proyecto de software se centra en las cuatro P's: personal, producto, proceso y proyecto. El orden no es arbitrario. El gestor que se olvida que el trabajo de ingeniera de Software es un esfuerzo humano intenso, nunca tendr xito en la gestin de proyectos. Un gestor que no fomenta una minuciosa comunicacin con el cliente al principio de la evolucin del proyecto, se arriesga a construir una elegante solucin para un problema equivocado. El administrador que presta poca atencin al proceso corre el riesgo de arrojar mtodos tcnicos y herramientas eficaces al vaco. El gestor que emprende un proyecto sin un plan slido arriesga el xito del producto. Hay cuatro P's que tienen una influencia sustancial en la gestin de proyectos software - personal, producto, proceso y proyecto -. El personal debe organizarse en equipos eficaces, motivados para hacer un software de alta calidad y coordinados para alcanzar una comunicacin efectiva.

Los ingenieros de software pueden organizarse en diferentes organigramas de equipos que van desde las jerarquas de control tradicionales a los equipos de "paradigma abierto". Se pueden aplicar varias tcnicas de coordinacin y comunicacin para apoyar el trabajo del equipo. En general, las revisiones formales y las comunicaciones informales persona a persona son las ms valiosas para los profesionales. Los requisitos del producto deben comunicarse desde el cliente al desarrollador, dividirse (descomponerse) en las partes que lo constituyen y distribuirse para que trabaje el equipo de software. El proceso debe adaptarse al personal y al problema. Se selecciona una estructura comn del proceso, se aplica un paradigma apropiado de ingeniera de software y se elige un conjunto de tareas para completa

r el trabajo. Finalmente, el proyecto debe organizarse de una manera que permita al equipo de software tener xito.

La medicin permite que gestores y desarrolladores mejoren el proceso del software, ayuden en la planificacin, seguimiento y control de un proyecto de software, y evalen la calidad del producto (software) que se produce. Las medidas de los atributos especficos del proceso, del proyecto y del producto se utilizan para calcular las mtricas del software. Estas mtricas se pueden analizar para proporcionar indicadores que guan acciones de gestin y tcnicas. Las mtricas del proceso permiten que una organizacin tome una visin estratgica proporcionando mayor profundidad de la efectividad de un proceso de software. Las mtricas del proyecto son tcticas, permiten que el gestor de proyectos adapte el enfoque a flujos de trabajo del proyecto y a proyectos tcnicos en tiempo real. Las tcnicas orientadas tanto al tamao como a la funcin se utilizan en toda la industria. Las mtricas orientadas al tamao hacen uso de las lneas de cdigo como factor de normalizacin para otras medidas como persona-mes o defectos. El punto de funcin proviene de las medidas del dominio de informacin y de una evaluacin subjetiva de la complejidad del problema. Las mtricas de la calidad del software como mtricas de productividad se centran en el proceso, en el proyecto y en el producto. Desarrollando una lnea base de mtricas de calidad, una organizacin puede actuar con objeto de corregir reas de proceso del software que son la causa de los defectos del software. Las mtricas tienen significado solo si han sido examinadas para una validez estadstica. Los ingenieros de software y sus gestores pueden obtener una visin ms profunda del trabajo que realizan y del producto que elaboran creando un lnea base de mtricas una base de datos que contenga mediciones del proceso y del producto-

El planificador del proyecto de software tiene que estimar tres cosas antes de que comience el proyecto: cunto durar, cunto esfuerzo requerir y cunta gente estar implicada. Adems el planificador debe predecir los recursos (de hardware y software) que va a requerir, y el riesgo implicado. El enunciado del mbito ayuda a desarrollar estimaciones mediante una o varias de las tcnicas siguientes: descomposicin, modelos empricos y herramientas automticas. Las tcnicas de descomposicin requieren de un esbozo de las principales funciones del software, seguido de las estimaciones de nm ero de LDC, de los valores seleccionados dentro del dominio de la informacin, del nmero de personas - mes requeridas para implementar cada funcin, o del nmero de personas - mes requeridas para cada actividad de ingeniera de software. Las tcnicas empricas usan expresiones empricamente obtenidas para el esfuerzo y para el tiempo, con las con las que se predicen esas magnitudes del proyecto. Las herramientas automticas implementan un determinado modelo emprico. Para obtener estimaciones exactas para un proyecto, generalmente se utilizan al menos dos de las tres tcnicas referidas anteriormente. Mediante la comparacin y la conciliacin de las estimaciones obtenidas con las diferentes tcnicas, el planificador puede obtener una estimacin ms exacta. La estimacin del proyecto software nunca ser una ciencia exacta, pero la combinacin de buenos datos histricos y de tcnicas sistemticas pueden mejorar la precisin de la estimacin. Cuando se pone mucho en juego en un proyecto de software el sentido comn nos aconseja realizar un anlisis de riesgo. Sin embargo, la mayora de los jefes de proyecto lo hacen informal y superficialmente, si es que lo hacen. El tiempo

invertido identificando, analizando y gestionando el riesgo merece la pena por muchas razones: menos trastornos durante el proyecto, una mayor habilidad de seguir y controlar el proyecto y la confianza que da planificar los problemas antes de que ocurran. El anlisis del riesgo puede absorber una cantidad significativa del esfuerzo de planificacin del proyecto, pero el esfuerzo merece

En el mbito de la Ingeniera del software, el concepto de Medicin se refiera a: Seleccione una respuesta.
a. Una mtrica o una combinacin de mtricas que proporcionan una visin profunda del proceso del software, del proyecto de software o del producto en s. b. Una indicacin cuantitativa de la extensin, cantidad, dimensiones, capacidad o tamao de algunos atributos de un proceso o producto. c. Grado en que el sistema, componente o proceso posee un atributo dado. d. El acto de determinar una medida.

2 Las razones para medir los procesos del software, los productos y los recursos, son: Caracterizar, Evaluar, Predecir, Mejorar. La primera razn permite: Seleccione una respuesta.

a. Determinar el estado con respecto al diseo b. Poder planificar c. Comprender mejor los procesos, los productos, los recursos y los entornos. d. Optimizar la calidad del producto y el rendimiento del proceso.

3 Dentro de las razones para medir los procesos del software, se encuentra la de Evaluar, esta se refiere a: Seleccione al menos una respuesta.
a. 3. Valorar la consecucin de los objetivos de calidad y evaluar su impacto. b. 1. Determinar el estado del proyecto con respecto al diseo. c. 4. Para poder planificar. d. 2. Comprender mejor los procesos, los productos, los recursos y el entrono.

4 Las razones para medir los procesos del software, los productos y los recursos, son: Caracterizar, Evaluar, Predecir, Mejorar. La tercera razn permite: Seleccione una respuesta.
a. Optimizar la calidad del producto y el rendimiento del proceso. b. Determinar el estado con respecto al diseo c. Comprender mejor los procesos, los productos, los recursos y los entornos. d. Poder planificar

Las razones para medir los procesos del software, los productos y los recursos, son: Caracterizar, Evaluar, Predecir, Mejorar. La segunda razn permite: Seleccione una respuesta.
a. Determinar el estado con respecto al diseo b. Optimizar la calidad del producto y el rendimiento del proceso. c. Poder planificar d. Comprender mejor los procesos, los productos, los recursos y los entornos.

6 En el mbito de la Ingeniera del software, el concepto de Indicador se refiera a: Seleccione una respuesta.
a. Una indicacin cuantitativa de la extensin, cantidad, dimensiones, capacidad o tamao de algunos atributos de un proceso o producto. b. Una mtrica o una combinacin de mtricas que proporcionan una visin profunda del proceso del software, del proyecto de software o del producto en s. c. El acto de determinar una medida. d. Grado en que el sistema, componente o proceso posee un atributo dado.

7 Los modelos COCOMO estn definidos para tres tipos de proyectos de software, entre ellos se encuentra los Empotrados que se refieren a: Seleccione una respuesta.

a. Proyectos de tamao y complejidad intermedia. b. Proyectos de tamao y complejidad alta. c. Proyectos que deben ser desarrollados con un conjunto de requisitos (hardware y software) muy restringidos. d. Proyectos pequeos y sencillos.

8 La planificacin temporal de un proyecto es una actividad que evoluciona con el tiempo y que permite identificar, definir y programar las actividades especficas que se requieren para realizar una actividad. Esta planificacin se gua bajo unos principios entre los cuales se encuentra el de compartimentacin, este se refiere a: Seleccione una respuesta.
a. Cada tarea programada debe asignarse a un miembro del equipo especfico. b. Cada tarea programada debe tener un resultado definido. c. El proyecto debe dividirse en un nmero de actividades y tareas manejables. d. Se debe determinar las interdependencias de cada actividad o tarea.

9 Las razones para medir los procesos del software, los productos y los recursos son: Seleccione una respuesta.
a. Controlar, Seguir, Anticipar y Mejorar. b. Planificar, Evaluar, Determinar y Medir. c. Evaluar, Anticipar, Estimar y Corregir. d. Caracterizar, Evaluar, Predecir y Mejorar.

10 Al disear los mdulos de un sistema de software se busca que estos tengan: Seleccione una respuesta.
a. alta cohesin y alto acoplamiento b. baja cohesin y alto acoplamiento c. alta cohesin y bajo acoplamiento d. baja cohesin y bajo acoplamiento

11 En el mbito de la Ingeniera del software, el concepto de Medida se refiera a: Seleccione una respuesta.
a. Una indicacin cuantitativa de la extensin, cantidad, dimensiones, capacidad o tamao de algunos atributos de un proceso o producto. b. Una mtrica o una combinacin de mtricas que proporcionan una visin profunda del proceso del software, del proyecto de software o del producto en s. c. Grado en que el sistema, componente o proceso posee un atributo dado. d. El acto de determinar una medida.

12 El modelo COCOMO que calcula el esfuerzo del desarrollo en funcin del tamao del programa y un conjunto de conductores de costo que incluyen la evaluacin subjetiva del producto, del hardware, del personal y de los atributos del proyecto, es: Seleccione una respuesta.

a. COCOMO intermedio b. COCOMO detallado c. COCOMO avanzado d. COCOMO bsico

13 El nmero de personas requerido para un proyecto de software se determina: Seleccione una respuesta.
a. Cuando se hace el contacto inicial con el cliente. b. Cuando se quiere reducir costos. c. despus de hacer una estimacin del esfuerzo de desarrollo. d. Antes de hacer una estimacin del esfuerzo de desarrollo.

14 El mbito del software describe el control y los datos a procesar, la funcin, el rendimiento, las restricciones, las interfaces y la fiabilidad. Comprende las siguientes actividades: Seleccione al menos una respuesta.
a. Recoleccin de la informacin b. Disponibilidad c. Implementacin d. Viabilidad

15

Cuando se hace el anlisis de requisitos del software, si el problema es complejo se parte en problemas ms pequeos que resultan ms manejables. A esta actividad se le llama Descomposicin y se aplica en dos reas principales: Seleccione al menos una respuesta.
a. Recurso financiero que se requiere. b. Recurso humano que se necesita c. El proceso que se emplear para entregarlo. d. La funcionalidad que debe entregarse .