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 nmero 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

5
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 .