RESUMEN ISW

CAPITULO 21
CONCEPTOS DE GESTION DE PROYECTOS
1. EL ESPECTRO DE LA GESTION
La gestin eficaz de la gestin de proyectos de software se enfoca sobre las cuatro
P: personal, producto, proceso y proyecto.
1.1.1 EL PERSONAL
El factor humano es tan importante que el oftware Engineering !nstitute ha
desarrollado un modelo de madurez de la capacidad de gestin del personal
"##$%P&.
El modelo de madurez de gestin de personal define las siguientes 'reas cla(e
pr'cticas para el personal de software: reclutamiento, seleccin, gestin del
desempe)o, entrenamiento, retribucin, desarrollo de la carrera, dise)o de la
organizacin y el traba*o, y desarrollo de la cultura del equipo. Las organizaciones
que logran altos ni(eles de madurez en el 'rea de gestin de personal tienen una
mayor probabilidad de implementar efecti(as pr'cticas de ingenier+a de software.
1.1.2 EL PRODUCTO
,ntes de planear un proyecto se deber+an establecer los ob*eti(os y el 'mbito del
producto, considerar soluciones alternati(as e identificar las restricciones t-cnicas
y de gestin.
El desarrollador del software y el cliente se deben reunir para definir los ob*eti(os y
el 'mbito del producto.
Los ob*eti(os identifican las metas globales del producto, sin considerar cmo se
las lograr'n.
El 'mbito identifica los datos primarios, las funciones y los comportamientos que
caracterizan al producto y los intentos por enlazar tales caracter+sticas en una
forma cuantitati(a.
.na (ez entendidos los ob*eti(os y el 'mbito del producto se consideran soluciones
alternati(as. ,unque se trata relati(amente poco detalle, las alternati(as posibilitan
que los gestores y practicantes seleccionen un /me*or0 enfoque, c1mplanlas
restricciones que imponen las fechas l+mites de entrega, las restricciones
presupuestarias, la disponibilidad del personal, las interfaces t-cnicas y miles de
factores m's.
1.1.3 EL PROCESO
.n proceso de software proporciona el marco de traba*o desde el cual se puede
establecer un plan detallado para el desarrollo del software. .n peque)o n1mero
de acti(idades del marco de traba*o es aplicable a todos los proyectos de software,
sin importar su tama)o o comple*idad. ,lgunos con*untos de tareas diferentes
"tareas, hitos, productos de traba*o y puntos de control de calidad& permiten que
las acti(idades del marco de traba*o se adapten a las caracter+sticas del proyecto
de software, as+ como a los requisitos del equipo del proyecto. 2inalmente, las
acti(idades protectoras "control de calidad del software, la gestin de configuracin
del software y la medicin& cubren el modelo de proceso. Las acti(idades
protectoras son independientes de cualquier acti(idad del marco de traba*o y
ocurren durante todo el proceso.
1.1.4 EL PROYECTO
Los proyectos de software se realizan de manera planificada y controlada por una
razn principal: es la 1nica forma conocida de gestionar la comple*idad.
Para e(itar el fracaso del proyecto, un gestor de proyecto de software y los
ingenieros de software que construyen el producto deben eludir un con*unto de
se)ales de ad(ertencia comunes, comprender los factores de -3ito cr+ticos que
conducen a una buena gestin del proyecto y desarrollar un enfoque de sentido
com1n para planificar, super(isar y controlar el proyecto.

2. PERSONAL
Los gestores argumentan que las personas son lo principal en los procesos de
ingenier+a de software, pero sus acciones con frecuencia contradicen sus
palabras.
4.1. LOS PARTICIPANTES
El proceso de software lo integran participantes que pueden clasificarse
dentro de una de cinco categor+as:
1. %estores e*ecuti(os : definen los aspectos del negocio que usualmente
tienen una influencia significati(a en el proyecto.
4. %estores del proyecto : quienes planifican, moti(an, organizan y
controlan a los profesionales que realizan el traba*o del software.
5. Profesionales : quienes proporcionan las habilidades t-cnicas
necesarias para realizar la ingenier+a de un producto o aplicacin.
6. $lientes : quienes especifican los requisitos para la ingenier+a del
software y otros elementos que tienen un inter-s m+nimo en el
resultado.
7. .suarios finales : quienes interact1an con el software una (ez que se
libera para su uso producti(o.
4.4. LIDERES DE EQUIPO
La gestin del proyecto es una acti(idad intensamente humana, por lo
tanto, los profesionales competentes con frecuencia no son buenos
l+deres de equipo. implemente no tienen la mezcla correcta de
habilidades con el personal.
8einberg sugiere un modelo #9! de liderazgo, basado en la Moti(acin,
Organizacin e Inno(acin.
9tra (isin de las caracter+sticas que definen un gestor de proyecto
eficiente resalta 6 rasgos cla(e: :esolucin de problemas, ;otes de
gestin, !ncenti(os e !nfluencia y fomento de la cultura de equipo
4.5. EL EQUIPO DE SOFTWARE
E3isten casi tantas estructuras organizacionales de profesionales para el
desarrollo de software como organizaciones que tiene el mismo fin. La
estructura organizacional no puede ser f'cilmente modificada. Las
preocupaciones acerca de las consecuencias pr'cticas y pol+ticas de
cambio organizacional no est'n dentro del 'mbito de responsabilidad del
gestor del proyecto de software. in embargo, la organizacin de la gente
directamente in(olucrada en un proyecto de software est' dentro del
'mbito del gestor del proyecto.
Los factores de proyecto que deber+an considerarse cuando se planifica
la estructura de los equipos de ingenier+a del software son:
La dificultad del problema que se resol(er'.
El tama)o del programa resultante en l+neas de cdigo o puntos de
funcin.
La (ida del equipo.
El grado en el que el problema puede separarse en mdulos.
La calidad y confiabilidad requeridas del sistema que se construir'.
La rigidez de la fecha de entrega.
El grado de sociabilidad que requiere el proyecto.
$onstantine, sugiere 6 paradigmas organizacionales para los equipos de
ingenier+a de software:
Paradigma !rrad", estructura un equipo a lo largo de una *erarqu+a
tradicional de autoridad. Estos equipos pueden traba*ar me*or cuando
producen software muy similar a los proyectos anteriores, pero ser'
menos probable que sean inno(adores.
Paradigma a#!a$"ri", estructura un equipo libremente y depende
de la iniciati(a indi(idual de los miembros del equipo. $uando se
requieren inno(acin o adelantos tecnolgicos, los equipos que
siguen el paradigma aleatorio ser'n e3celentes, pero no son
recomendables cuando se requiere desempe)o ordenado.
Paradigma a%i!r$"& el traba*o se desarrolla en colaboracin. La
slida comunicacin y la toma de decisiones basada en el consenso
son las marcas caracter+sticas de los equipos de paradigma abierto.
Las estructuras de equipo de paradigma abierto se adecuan bien a la
solucin de problemas comple*os, pero no pueden desempe)arse de
manera tan eficiente como otros equipos.
Paradigma 'i(r)(i"& organiza a los miembros del equipo para
traba*ar en partes del problema con poca comunicacin acti(a entre
ellos.

4.6. EQUIPOS AGILES
La filosof+a 'gil alienta la satisfaccin del cliente y la temprana entrega
incremental de software< peque)os equipos de traba*o enormemente
moti(ados< m-todos informales< m+nimos productos de traba*o de ingenier+a
del software y simplicidad global de desarrollo.
El enfoque 'gil subraya la competencia indi(idual en con*uncin con la
colaboracin del grupo como factores de -3ito cruciales para el equipo.
Para apro(echar en forma eficiente las competencias de cada miembro del
equipo y fomentar la colaboracin eficaz a lo largo de un proyecto de
software, los equipos 'giles son /auto organizados0. .n equipo auto
organizado no necesariamente mantiene una sola estructura de equipo, sino
que m's bien apro(echa elementos de los paradigmas aleatorio, abierto y
sincrnico.
4.7. CONFLICTOS DE COORDINACION Y
COMUNICACI*N
E3isten muchas razones por las cuales los proyectos de software se (uel(en
problem'ticos. La escala de muchos esfuerzos de desarrollo es grande, lo
que conduce a comple*idad, confusin y dificultades significati(as en la
coordinacin de los miembros del equipo.
3. EL PRODUCTO
5.1. +m%i$" d!# '",$-ar!
La primera acti(idad de gestin de un proyecto de software es la
determinacin del 'mbito de software. El 'mbito se define al responder
las siguientes preguntas:
$9=>E?>9 @$mo enca*a el software que se desarrollar' en un sistema
m's grande, producto o conte3to de negocios, y qu- restricciones se
imponen como resultado del conte3toA
9BCE>!D9 ;E !=29:#,$!9= @Eu- ob*etos de datos (isibles al usuario se
producen como resultado del softwareA @Eu- ob*etos de datos se
requieren de entradaA
2.=$!9= F ;EE#PEG9 @Eu- funciones realiza el software para
transformar los datos de entrada en salidaA @E3isten algunas
caracter+sticas de desempe)o especiales que deban abordarseA
El 'mbito del proyecto de software no debe ser ambiguo ni
incomprensible a ni(eles de gestin y t-cnico. e debe acotar un
enunciado del 'mbito del software, es decir, se establecen de manera
e3pl+cita los datos cuantitati(os, se anotan las restricciones o limitaciones
y se describen los factores que reducen riesgos.
5.4. D!'"m."'ii)( d!# .r"%#!ma
La descomposicin del problema, a (eces llamada particin o elaboracin
del problema, es una acti(idad que se asienta en el n1cleo del an'lisis de
requisitos de software. La descomposicin se aplica en dos grandes
'reas:
La funcionalidad que debe entregarse.
El proceso que se emplear' para entregarlo.
.n problema comple*o se di(ide en problemas menores que resultan
m's mane*ables. Hsta es la estrategia que se aplica cuando comienza la
planificacin del proyecto. Las funciones de software se e(al1an y
refinan para proporcionar m's detalles antes del comienzo de la
estimacin. Puesto que las estimaciones de costo y planificacin
temporal est'n funcionalmente orientadas, con frecuencia es 1til cierto
grado de descomposicin.

4. EL P:9$E9
El problema que se presenta es seleccionar el modelo de proceso apropiado
para que un equipo de proyecto someta al software a ingenier+a.
El gestor de proyectos debe decidir cu'l modelo de proceso es m's apropiado
para:
Los clientes que han solicitado el producto y el personal que har' el
traba*o.
Las caracter+sticas del producto mismo.
El ambiente del proyecto en el que traba*a el equipo de software.
$uando se ha seleccionado un modelo de procesos entonces el equipo define
un plan de proyecto preliminar con base en el con*unto de acti(idades del
marco del traba*o del proceso.
.na (ez que se establece el plan preliminar, comienza le descomposicin del
proceso.
6.1. C"m%i(ai)( d!# .r"d/$" 0 !# .r"!'"
La planeacin del proyecto comienza con la combinacin del producto y
del proceso. $ada funcin que el equipo de software someter' a
ingenier+a debe pasar a tra(-s del con*unto de acti(idades del marco de
traba*o definidas para una organizacin de software.

6.4. D!'"m."'ii)( d!# .r"!'"
.n equipo de software debe tener un grado significati(o de fle3ibilidad al
elegir el modelo de procesos de software que sea me*or para el proyecto
y las tareas de ingenier+a de software que integren el modelo de
procesos una (ez elegido.
Enfoque secuencial lineal: para realizar un proyecto relati(amente
peque)o similar a otros que se hayan realizado.
#odelo de desarrollo r'pido de aplicaciones: utilizado cuando e3isten
restricciones de tiempo muy ce)idas.
Estrategia !ncremental: utilizado cuando la fecha l+mite es tan ce)ida
que la funcionalidad completa no puede alcanzarse.
Proyectos con otras caracter+sticas conducir'n a la b1squeda de otros
modelos.
.na (ez elegido el modelo de proceso, el marco de traba*o respecti(o se
adapta a -l. Podr' aplicarse el marco de traba*o gen-rico: comunicacin,
planificacin, modelado, construccin y despliegue. 2uncionar' para
modelos lineales, iterati(os e incrementales, as+ como e(oluti(os e
incluso para modelos concurrentes o de ensamble de componentes.
La descomposicin del proceso comienza cuando el gerente de proyecto
pregunta @$mo lograremos esta acti(idad del marco de traba*oA
1. EL P:9FE$>9
La gestin de un proyecto de software e3itoso requiere entender que
puede salir mal. Cohn :eel define1I se)ales que indican que un proyecto
de sistemas de informacin est' en peligro:
1. El personal de software no entiende las necesidades de sus clientes.
4. El 'mbito del producto est' mal definido.
5. Los cambios se gestionan mal.
6. La tecnolog+a elegida cambia.
7. Las necesidades comerciales cambian, o est'n mal definidas.
J. Los plazos de entrega no son realistas.
K. Los usuarios se resisten.
L. e pierde el patrocino.
M. El equipo de proyecto carece de personal.
1I.Los gestores e(itan las me*ores pr'cticas y las lecciones aprendidas.
La lista de las se)ales mencionada, son las causas que conducen a la
regla MINMI. El primer MIO de un sistema absorbe el MIO del esfuerzo y
tiempo asignados. El 1ltimo 1IO toma el otro MIO del esfuerzo y
tiempos asignados.

@$mo act1a un gestor para e(itar los problemas mencionadosA
ugiere un enfoque de sentido com1n de 7 partes para proyectos de
software:
1. $omience con el pie derecho: Entender bien el problema para
establecer bien los ob*eti(os y e3pectati(as. $onstruir el equipo
correcto y darle a -ste autonom+a, autoridad y tecnolog+a.
4. #antenga el +mpetu: El gestor de proyecto debe proporcionar
incenti(os, el equipo debe resaltar la calidad en cada tarea que
realiza y los gestores e*ecuti(os deben hacer lo posible por
mantenerse fuera del camino del equipo.
5. :astree el progreso: En un proyecto de software el progreso se rastrea
conforme se elaboran los productos de traba*o"cdigo fuenteN
modelos& y se aprueban como parte de una acti(idad de
aseguramiento de calidad
6. >omar decisiones inteligentes: Las decisiones del gestor de proyecto y
del equipo de software deben encaminarse para mantenerlo simple.
7. :ealice un an'lisis de resultados: Establezca un mecanismo
consistente para e3traer lecciones aprendidas por cada proyecto.
E(al1e la planificacin real y la pre(ista, recolecte y analice m-tricas,
obtenga realimentacin por parte del equipo y de los clientes.

:E.#E=
%estin de proyectos de software: acti(idad protectora dentro de la
ingenier+a del software. $omienza antes de iniciar cualquier acti(idad t-cnica
y contin1a a lo largo de la definicin, el desarrollo y el soporte del software
de computadora.
Esta acti(idad abarca medidas y m-tricas, estimacin y planificacin an'lisis
de riesgos, segumiento y control.
Las 6 P: Personal, Producto, Proceso y Proyecto.
Personal: debe estar organizado en equipos eficientes, moti(ados para hacer
un traba*o de software de alta calidad y coordinados para lograr una
comunicacin eficaz.
Producto: los requisitos del producto se deben comunicar del cliente al
desarrollador, ser di(ididos en sus partes constituti(as y distribuirse para
que traba*e el equipo de software.
Proceso: debe adaptarse al personal y al problema. e selecciona un marco
de traba*o de proceso com1n, se aplica un paradigma de ingenier+a de
software adecuado y se elige un con*uLnto de tareas para lle(ar a cabo el
traba*o.
Proyecto: debe estar organizado en una forma que permita triunfar al equipo
de software.
El elemento central de todos los proyectos de software es el PE:9=,L. Los
ingenieros de software pueden organizarse en diferentes estructuras de
equipo que (an desde las *erarqu+as de control tradicionales hasta los
equipos de paradigma abierto.
e pueden aplicar (arias t-cnicas de coordinacin y comunicacin para
apoyar el traba*o del equipo.
CAPITULO 23
ESTIMACION PARA PROYECTOS DE SOFTWARE
INTRODUCCION
%estin del proyecto del software: comienza con un con*unto de acti(idades que
en grupo se llaman PL,=!2!$,$!9= ;EL P:9FE$>9. ,ntes de que el proyecto
comience, el gestor del proyecto y el equipo de software deben estimar el
traba*o que habr' de realizarse, los recursos que se requerir'n y el tiempo que
transcurrir' desde el principio hasta el final.
.na (ez que se completen estas acti(idades, el equipo de software debe
establecer un Plan ;e Proyecto, que defina las tareas y fechas cla(e de la
ingenier+a del software, que identifique qui-n es el responsable de dirigir cada
tarea y especifique las dependencias entre tareas que pueden ser
determinantes del progreso.

1. O2SER3ACIONES ACERCA DE LA ESTIMACION
La planificacin requiere que los gestores t-cnicos y los miembros del equipo
de software establezcan un compromiso inicial.
,unque la estimacin es tanto un arte como una ciencia, esta importante
acti(idad no necesita realizarse en una forma impro(isada.
Puesto que la estimacin coloca los cimientos para las dem's acti(idades de
planificacin del proyecto y -sta proporciona la ruta para la ingenier+a del
software e3itosa, se estar+a mal aconse*ando si se embarcara sin ella.
El riesgo de estimacin se mide por el grado de incertidumbre de las
estimaciones cuantitati(as establecidas para recursos, costos y programa de
traba*o
2. EL PROCESO DE PLANIFICACION DEL PROYECTO
El ob*eti(o de la planificacin del proyecto de software es proporcionar un
marco de traba*o que permita al gestor estimar razonablemente recursos,
costo y programa de traba*o. ,dem's, las estimaciones deben intentar
definir los escenarios de me*or y peor caso de modo que los resultados del
proyecto se puedan acotar.
El plan del proyecto se debe adaptar y actualizar conforme a(ance el
proyecto.
3. AM2ITO DEL SOFTWARE Y FACTI2ILIDAD
El 'mbito del software describe las funciones y caracter+sticas que se
entregar'n a los usuarios finales, los datos que son entrada y salida, el
contenido que se presenta a los usuarios como consecuencia de emplear el
software, as+ como el desempe)o, las restricciones, las interfaces y la
confiabilidad que acotan al sistema.
El 'mbito se define al usar una de las dos t-cnicas siguientes:
;espu-s de una comunicacin con todos los participantes se
desarrolla una descripcin narrati(a del 'mbito del software.
Los usuarios finales desarrollan un con*unto de casos de uso.
.na (ez identificado el ,#B!>9 es razonable preguntar @Es posible construir
el software para satisfacer el 'mbitoA @El proyecto es factibleA
El ,#B!>9 no es suficiente para contestar las preguntas mencionadas. .na
(ez que el 'mbito se comprende el equipo de software y otros deben
traba*ar para determinar si se puede hacer dentro de las siguientes
dimensiones:
>ecnolog+a
2inanzas
>iempo
:ecursos
4. RECURSOS
La segunda tarea de la planificacin es la estimacin de los recursos
necesarios para completar el esfuerzo de desarrollo de software.
4.1. RECURSOS 4UMANOS
El planificador comienza e(aluando el 'mbito del software y
seleccionando las habilidades requeridas para completar el
desarrollo. e especifican tanto la posicin organizacional como la
especialidad.
El n1mero de personas que requiere un proyecto de software solo se
determina despu-s de que se ha hecho una estimacin del esfuerzo
de desarrollo.
4.2. RECURSOS DE SOFTWARE REUTILI5A2LES
La ingenier+a del software basada en componentes enfatiza la
reutilizacin, es decir, la creacin y reutilizacin de bloques de
construccin de software. >ales bloques, usualmente llamados
componentes, deben catalogarse para consultarlos con facilidad,
estandarizarse para facilitar su aplicacin y (alidarse para integrarlos
f'cilmente.
Bennatan sugiere 6 categor+as:
$omponentes ya desarrollados: El software e3istente se puede
adquirir de un tercero o se desarroll internamente para un proyecto
pre(io "est'n listos y (alidados&.
$omponentes e3perimentales: Especificaciones, dise)o, cdigo o
datos de prueba e3istentes que se desarrollaron para proyectos
pre(ios similares.
$omponentes de e3periencia parcial: Especificaciones, dise)o, cdigo
o datos de prueba e3istentes que se desarrollaron para proyectos
pre(ios est'n relacionados con el proyecto actual, pero requerir'n
modificaciones sustanciales.
$omponentes nue(os: El equipo de software debe construir los
componentes de software espec+ficamente para las necesidades del
proyecto actual.
4.3. RECURSOS DEL ENTORNO
El entorno que soporta un proyecto de software, con frecuencia
denominado entorno de ingenier+a de software "E!&, incorpora
hardware y software. El hardware proporciona una plataforma que
soporta herramientas "software& con que se producen los productos
de traba*o basados en una buena pr'ctica de la ingenier+a del
software.
El planificador del proyecto de software debe especificar cada
elemento de hardware.
1. ESTIMACION DE PROYECTOS DE SOFTWARE
La estimacin de costo y esfuerzo nunca ser' una ciencia e3acta. in
embargo, la estimacin del proyecto se puede transformar de una pr'ctica
oscura en una serie de pasos sistem'ticos que proporcionan estimaciones
con riesgo aceptable.
Para lograr estimaciones confiables de costo y esfuerzo se tienen (arias
opciones:
;emorar la estimacin hasta m's tarde en el proyecto. "Poco pr'ctica,
las estimaciones deben realizarse por adelantado&.
Basar las estimaciones en proyectos similares que ya hayan sido
completados "Puede funcionar si el proyecto en curso es muy similar
a los pre(ios&.
Emplear t-cnicas de descomposicin relati(amente simples para
generar estimaciones de costo y esfuerzo del proyecto.
.tilizar uno o m's modelos emp+ricos en la estimacin de costo
esfuerzo.
Las 1ltimas 4 opciones son enfoques (iables, deben aplicarse *untas,
cada una empleada como una marca de (erificacin para la otra.
6. TECNICAS DE DESCOMPOSICION
La estimacin del proyecto de software es una forma de resol(er problemas,
en la mayor+a de los casos comple*os como para considerar una sola pieza.
Por ello, se descompone el problema.
6.1. TAMA7O DEL SOFTWARE
La precisin de la estimacin de un proyecto de software se
manifiesta en (arios factores:
1. El grado con el cual el planificador ha estimado adecuadamente el
tama)o del producto que se construir'..
4. La habilidad para traducir la estimacin del tama)o en esfuerzo
humano, programa de traba*o y dinero.
5. El grado en el cual el plan del proyecto refle*a las habilidades del
equipo de software.
6. La estabilidad de los requisitos del producto y el entorno que soporta
el esfuerzo de ingeniar+a de software.
Putnam y #yers sugieren 6 enfoques al problema del tama)o:
1. >ama)o de lgica difusa: El planificador identifica el tipo de
aplicacin, establece su magnitud.
4. >ama)o de punto de funcin: El planificador desarrolla estimaciones
de las caracter+sticas del dominio de la informacin.
5. >ama)o de componentes est'ndar: El planificador del proyecto estima
el n1mero de ocurrencias de cada componente est'ndar y luego
aplica datos de proyectos histricos para determinar el tama)o de
entrega por componente est'ndar.
6. >ama)o del cambio: El planificador estima el n1mero y tipo de las
modificaciones que se deben lograr
6.2. ESTIMACION 2ASADA EN EL PRO2LEMA
Las estimaciones de L;$ y P2 son distintas t-cnicas de estimacin,
aunque ambas tienen (arias caracter+sticas en com1n
Las t-cnicas de estimacin L;$ y P2 difieren en cuanto al detalle
requerido para descomposicin y el ob*eti(o de la particin.
#ientras mayo sea el grado de particin es m's probable que se
desarrolle una estimacin razonablemente precisa de L;$.
6.3. ESTIMACION 2ASADA EN EL PROCESO
La t-cnica m's com1n para estimar un proyecto es basar la
estimacin en el proceso que se emplear'. Es decir, el proceso se
descompone en un con*unto relati(amente peque)o de tareas y se
estima el esfuerzo requerido para lograr cada tarea.
La estimacin basada en el proceso comienza con un bosque*o de las
funciones del software obtenidas a partir del 'mbito del proyecto.
$ada funcin requiere realizar un grupo de acti(idades del marco de
traba*o.
.na (ez que se combinan las funciones del problema y las
acti(idades del proceso, el planificador estima el esfuerzo que se
requerir' para lograr cada acti(idad del proceso de software en cada
funcin. Luego se aplica la tasa de traba*o promedio "costoPunidad de
esfuerzo& al esfuerzo estimado para cada acti(idad del proceso.
6.4. ESTIMACION CON CASOS DE USO
Los casos de uso permiten que un equipo de software comprenda el
'mbito del software y los requisitos.
:azones por las cuales, desarrollar un enfoque de estimacin con
casos de uso, es problem'tico:
Los casos de uso se describen empleando muchos formatos y estilos
diferentes, no e3iste un formato est'ndar.
Los casos de uso representan una (isin e3terna de (isin e3terna
"del usuario&, del software y con frecuencia est'n escritos con
diferentes grados de abstraccin.
Los casos de uso no abordan la comple*idad de las funciones ni de las
caracter+sticas que se describen.
Los casos de uso no describen el comportamiento comple*o que
in(olucran muchas funciones y caracter+sticas.
, diferencia de las L;$ o P2, el caso de uso de una persona tal (ez
requiera meses de esfuerzo mientras que el de otra quiz' se
implemente en un d+a o dos.

8. MODELOS EMPIRICOS DE ESTIMACION
Los datos emp+ricos que apoyan la mayor+a de los modelos de estimacin
proceden de una manera limitada de proyectos. Por esta razn ning1n
modelo de estimacin es apropiado para todas las clase de software ni en
todos los entornos de desarrollo.
.n modelo de estimacin debe calibrarse para refle*ar las condiciones
locales. El modelo debe probarse mediante la aplicacin de los datos
recopilados a partir de proyectos completados, colocar los datos en el
modelo y luego comparar los resultados reales con los predichos.
9. ESTIMACION PARA PROYECTOS ORIENTADOS A O2:ETOS
Enfoque planteado e3pl+citamente para software 99:
1 ;esarrollar estimaciones aplicando la descomposicin del esfuerzo, an'lisis
de P2 y cualquier otro m-todo que sea aplicable en aplicaciones
con(encionales.
4 ,plicar el modelado de an'lisis 99.
5 ;eterminar el n1mero de clases cla(e.
6 $ategorizar el tipo de interfaz para la aplicacin.
7 #ultiplicar el n1mero total de clases por el n1mero promedio de unidades
de traba*o por clase.
J $omprobar de manera cruzada la estimacin.
RESUMEN
El planificador del proyecto de software debe estimar 5 factores antes de que un
proyecto comience:
$u'nto tiempo tomar'.
$u'nto esfuerzo requerir'.
$u'nto personal est' in(olucrado
>ambi-n debe predecir los recursos "hard y soft& que se requerir'n y el riesgo
in(olucrado.
La descripcin del ,#B!>9 ayuda al planificador a desarrollar estimaciones
empleando una o m's t-cnicas que se clasifican en dos amplias categor+as:
;escomposicin
#odelo emp+rico
Las t-cnicas de descomposicin requieren un bosque*o de las principales
funciones del software, seguido por estimaciones de:
=1mero de L;$
Dalores seleccionados dentro del dominio de informacin
=1mero de casos de uso
=1mero de personasNmes requeridos para implementar cada
funcin
=1mero de personasNmes requeridos para cada acti(idad de
ingenier+a de software
Las t-cnicas emp+ricas usan e3presiones para esfuerzo y tiempo obtenidas
emp+ricamente para predecir estas cantidades del proyecto.
CAPITULO 24
CALENDARI5ACION DE PROYECTOS DE SOFTWARE
CONCEPTOS 2ASICOS
,unque e3isten muchas razones por las cuales el software se entrega con
retraso, la mayor+a se encuadra en una o m's de las siguientes causas:
.na fecha l+mite irrealizable establecida por alguien e3terno al grupo
de ingenier+a del software e impuesta a los gestores y profesionales
del grupo.
$ambios en los requisitos del cliente que no se refle*an en
modificaciones a la calendarizacin.
.na subestimacin razonable de la cantidad de esfuerzo o de
recursos que se requerir'n para alcanzar el traba*o.
:iesgos que no se consideraron cuando empez el proyecto.
;ificultades t-cnicas que no pudieron pre(erse.
;ificultades humanas impre(isibles.
2alta de comunicacin entre el personal del proyecto, lo que genera
demoras.
.na falla en la gestin del proyecto porque no reconoci el retraso ni
emprendi una accin para corregir el problema.
Pasos a seguir ante una situacin de fecha l+mite:
1. :ealizar una estimacin detallada usando datos de proyectos pre(ios.
;eterminar esfuerzo y duracin estimados.
4. ,plicar un modelo de proceso incremental. ;esarrollar una estrategia
de ingenier+a de software que entregar' la funcionalidad cr+tica en la
fecha l+mite impuesta, pero demorar' otra.
5. :eunirse con el cliente y con la estimacin detallada, e3plicarle por
qu- la fecha l+mite impuesta es irrealizable. ,segurarse de se)alar
que todas las estimaciones est'n basadas sobre el desempe)o en
proyectos pre(ios.
6. 9frezca la estrategia de desarrollo incremental como alternati(a.
CALENDARI5ACION DE PROYECTO.
, 2red BrooQs se le pregunt cmo se retrasan los proyectos de software en la
calendarizacin y contest: ;E .= ;!, , L, DER
La realidad de un proyecto t-cnico es que cientos de peque)as tareas deben
realizarse para lograr una meta mayor.
i las tareas con /trayectoria cr+tica0 se retrasan en la calendarizacin, la fecha
de terminacin del proyecto se pone en riesgo.
9b*eti(o del %estor: definir todas las tareas del proyecto, construir una red que
bosque*e sus interdependencias, identificar las tareas cruciales dentro de la red
y luego seguir su progreso para garantizar que la demora se produce /un d+a a
la (ez0.
$alendarizacin del proyecto de software: es una acti(idad que distribuye
estimaciones de esfuerzo a tra(-s de la duracin planificada del proyecto al
asignar el esfuerzo a tareas espec+ficas de ingenier+a de software. La
calendarizacin e(oluciona a lo largo del tiempo.
La calendarizacin para proyectos de ingenier+a de software se puede (er desde
4 perspecti(as:
Fa se ha establecido una fecha final para la liberacin de un sistema
basado en computadora.
upone que se han comentado l+mites cronolgicos apro3imados,
pero que a la fecha final la establece la organizacin de ingenier+a del
software.
PRINCIPIOS 2ASICOS
$ompartimentacin: El proyecto debe di(idirse en compartimentos en (arias
acti(idades, acciones y tareas mane*ables.";escomponer tanto el producto
como el proceso&.
!nterdependencia: e debe determinar la interdependencia de cada acti(idad,
accin o tarea compartimentada.
,signacin de tiempo: , cada tarea por calendarizar se le debe asignar cierto
n1mero de unidades de traba*o, fecha de inicio, fecha de terminacin.
Dalidacin del esfuerzo: >odo proyecto tiene un n1mero definido de personas en
el equipo de software. $onforme ocurre la asignacin de tiempo, el gestor de
proyecto debe asegurarse de que, en un tiempo dado, no se han asignado m's
que el n1mero de personas calendarizado.
;efinicin de responsabilidades: >oda tarea calendarizada se la debe asignar a
un miembro espec+fico del equipo.
;efinicin de resultados: >oda tarea calendarizada debe tener un resultado
definido. En proyectos de software generalmente es un producto de traba*o.
;efinicin de hitos: .n hito se logra cuando se ha re(isado la calidad de uno o
m's productos de traba*o y se ha aprobado
RELACION ENTRE EL PERSONAL Y EL ESFUER5O
#!>9: /i nos retrasamos en la calendarizacin, siempre podemos incorporar
m's programadores y recuperarnos m's adelante en el proyecto0

;esgraciadamente, agregar m's personas en etapas tard+as tiene un efecto
perturbador sobre -ste, lo que pro(oca que la calendarizacin se desfase a1n
m's.
Las personas que se agregan tienen que aprender el sistema, y la gente que les
ense)a es la misma que estaba haciendo el traba*o. ;urante la ense)anza no
se realiza traba*o y el proyecto e3perimenta mayores retrasos.
DEFINICION DE UN CON:UNTO DE TAREAS PARA EL PROYECTO DE
SOFTWARE
Es dif+cil desarrollar una ta3onom+a completa de tipos de proyectos de software,
en la mayor+a de las organizaciones del ramo se encuentran los siguientes
proyectos:
1. Proyectos de desarrollo del concepto, los cuales se inician para
e3plorar algunas aplicaciones o conceptos de negocio s de alguna
nue(a tecnolog+a.
4. Proyectos de desarrollo de nue(as aplicaciones, los cuales se lle(an a
cabo como consecuencia de una solicitud espec+fica del cliente.
5. Proyectos de me*ora de la aplicacin, -stos ocurren cuando el
software e3istente e3perimenta grandes modificaciones en la funcin,
el desempe)o o las interfaces (isibles para el usuario final.
6. Proyectos de mantenimiento de aplicacin, los cuales corrigen,
adaptan o e3tienden el software e3istente en formas que no sean
ob(ias inmediatamente para el usuario final.
7. Proyectos de reingenier+a, -stos se lle(an a cabo con la finalidad de
reconstruir un sistema e3istente en todo o en parte.
$,LE=;,:!R,$!9=
>-cnicas que se aplican para la calendarizacin: PE:>, $#P, %,=>>.
eguimiento de la calendarizacin
La calendarizacin del proyecto proporciona un mapa de carreteras al gestor
del proyecto de software. i se ha realizado de manera adecuada, la
calendarizacin del proyecto define las tareas e hitos que se deben seguir y
controlar conforme a(ance el proyecto. El seguimiento se puede hacer de
diferentes maneras:
$on la realizacin peridica de reuniones para (alorar el estado del
proyecto en las cuales cada uno de los miembros del equipo informa
del progreso y los problemas.
$on la e(aluacin de los resultados de todas las re(isiones realizadas
a lo largo del proceso de ingenier+a del software.
$on la determinacin de si se han logrado los hitos formales del
proyecto en la fecha programada.
,l comparar la fecha de inicio real con la fecha pre(ista para cada
tarea del proyecto.
,l reunirse de manera informal con los traba*adores para obtener su
e(aluacin sub*eti(a del progreso, hasta la fecha y los problemas que
se (islumbran.
$on el uso del an'lisis del (alor obtenido para e(aluar el progreso
cuantitati(amente.

FILMINAS ESTIMACIONES DE SOFTWARE
Pr"%#!m;$ia d! #a !'$imai)(
,(eriguar lo que costar' desarrollar una aplicacin "personas, dinero,
tiempo&.
#omento en que se desea conocer el costo.
iempre se quiere muy pronto.
$ada (ez que se a(anza m's en el proyecto, y se obtiene m's informacin, la
estimacin es m's precisa. El problema es realizar predicciones.
Pr"!'" d! !'$imai)( .r"./!'$"
#edir lo que el usuario quiere: Especificar y cuantificar lo que el usuario
necesita.
Estimar lo que costar':
E3periencia indi(idual
E3periencia de empresa
;ebe tenerse en cuenta la e3periencia en proyectos pre(ios. Luego de que se
hayan desarrollado (arios proyectos, se contar' con caracter+sticas cla(es de
negocio.
M<$"d"' U$i#i=ad"'
Basados en la e3periencia
NCuicio e3perto: Puro, ;elphi.
N,nalog+a
N;istribucin de la utilizacin de recursos en el ciclo de (ida
Basados e3clusi(amente en los recursos
#-todo basado e3clusi(amente en el mercado
Basados en los componentes del producto o en el proceso de
desarrollo
#-todos algor+tmicos
:UICIO E>PERTO PURO
.n e3perto estudia las especificaciones y hace su estimacin.
e basa fundamentalmente en los conocimientos del e3perto.
i desaparece el e3perto la empresa de*a de estimar.
i el e3perto no est', el equipo no sabe cmo realizar las estimaciones, se debe
tratar de transmitir el conocimiento a todo el equipo.
E'$r/$/ra(d" !# :/ii" E?.!r$"
4a!r /(a W2S "( /(a gra(/#aridad a!.$a%#!
U'ar !# m<$"d" d! @O.$imi'$a& .!'imi'$a 0 Aa%i$/a#B 0 '/
,)rm/#a CDE4AE.FG6.
U'! /( A!H#i'$ 0 /( ri$!ri" d!,i(id" .ara a'!g/rar
"%!r$/ra.
:UICIO E>PERTO WIDE2AND DELP4I
.n grupo de personas son informadas y tratan de adi(inar lo que costar' el
desarrollo tanto en esfuerzo como en duracin.
Las estimaciones en grupo suelen ser me*ores que las indi(iduales.
La reunin se prepara 46hs antes, se *unta un grupo de e3pertos para enfrentar
opiniones y estimar. $ada uno de los e3pertos en(+a su estimacin al
coordinador. Luego se tabulan las estimaciones "son annimas&.
e dan especificaciones a un grupo de e3pertos.
e les re1ne para que discutan tanto el producto como la estimacin.
:emiten sus estimaciones indi(iduales al coordinador.
$ada estimador recibe informacin sobre su estimacin, y las a*enas pero de
forma annima.
e re1nen de nue(o para discutir las estimaciones.
$ada uno re(isa su propia estimacin y se la en(+a al coordinador.
e repite el proceso hasta que la estimacin con(erge de forma razonable.
@$u'ntas rondas son aceptablesA %eneralmente 5 reuniones son aceptables.
A(a#"gIa
$onsiste en comparar las especificaciones de un proyecto con las de otros
proyectos.
$omparar componentes similares
$uando se compara por analog+a hay mucho error, no son fiables.
A(a#"gIaJFa$"r!'
>ama)o: @#ayor o menorA
$omple*idad: @#'s comple*o de lo usualA
.suarios: i hay m's usuarios habr'n m's complicaciones
9tros factores:
istema operati(o, entornos "la primera (ez m's&.
Sardware, @Es la primera (ez que se (a a utilizarA
Personal del proyecto, @nue(os en la organizacinA
%eneralmente lo que m's afecta es la comple*idad y Tpara qui-n se estima.
E'$ra$!gia d! !'$imai)(
$uente primero
.se un m-todo para con(ertir las /cuentas0 en estimaciones
.se el *uicio de e3perto como 1ltimo resorte.
Primero se debe contar y fi*ar la medida.
egundo se debe transformar la cuenta en estimacin.
=9 .,: .= 9L9 #H>9;9 E :E$9#!E=;, .,: P9: L9 #E=9 4, F E
.ELE= .,: ;E , P,:E.
%eneralmente se usa el *uicio e3perto y uno algor+tmico.
Ca#i%rai"(!' 0 4i'$"ria# Da$a
Las calibraciones son solamente usadas para con(ertir las /cuentas0
a estimados "l+neas de cdigo a esfuerzo, use cases a calendarios,
requerimientos a n1meros de test cases, etc.&.
Estimar, siempre in(olucra alg1n tipo de calibracin sea directa o
impl+cita.
Las estimaciones pueden ser calibracin usando cualquiera de estos
tres tipos de datos:
1. !ndustry ;ata : datos de otras organizaciones que aportan al mercado
y desarrollan productos con alg1n grado de seme*anza y que permite
una comparacin b'sica. "En general est'n es est'ndares&
4. Sistorical ;ata : datos de la organizacin de proyectos que se
desarrollaron y ya se cerraron."e guardaron datosNestimaciones&
5. Pro*ect ;ata : datos del proyecto pero de etapas anteriores a la que se
est' estimando."$ada (ez que se abre una fase estimarla&
A$iKidad!' Omi$ida'
o .na de las fuentes de error m's com1n en las estimaciones es omitir
acti(idades necesarias para la estimacin del proyecto:
:equerimientos faltantes
,cti(idades de desarrollo faltantes "documentacin t-cnica,
participacin en re(isiones, creacin de datos para el testing,
mantenimiento de producto en pre(ias (ersiones&.
,cti(idades generales "d+as por enfermedad, licencia, cursos,
reuniones de la compa)+a&
o .so de buffers o colchn.
o /=unca tenga temor de que las estimaciones creadas por
desarrolladores sean demasiado pesimistas, dado que los
desarrolladores siempre generan schedules demasiado optimistas0.
Lo que m's afecta a la estimacin es:
1. :equerimientos no rele(antes
4. :equerimientos mal rele(ados
iempre guardar una cantidad de d+as e3tra por algo que salga mal o falte: buffer o
colchn.

2actores que afectan a la estimacin: =os ol(idamos de los requerimientos =9
2.=$!9=,LE, slo tenemos en cuenta los funcionales.
E'$imai)( d! $amaL"
El n1mero que m's se busca en las estimaciones de software es el
tama)o del software a ser construido.
El tama)o puede ser e3presado en L;$ "l+neas de cdigo&, puntos de
funcin, n1mero de requerimientos, n1mero de web pages u otra
medida.
P"H!r E'$ima$i"(
Popular entre los 'giles practitiones, publicado por #iQe $ohn.
$ombina opinin de e3perto, analog+a y desegregacin.
Participantes en planning pocQer son desarrolladores
o Las personas m's competentes en resol(er una tarea deben ser
quienes la estiman.
El misterio de 2ibonacci.
P"H!r P#a((i(g
;efina la lista de acti(idades, mdulos, use cases, etc.
,cuerde y consensue en la m's simple, e*emplo tarea z.
,signe tama)oPcomple*idad 1 a la tarea z
E*ecute un wide Band delphi para estimar comple*idadPtama)o del resto de la lista,
comparado con la m's simple y solo asignando (alores de $9#PLEC!;,; de la serie
de 2ibonacci. e puede hacer como una ronda de cartas.
Estime el esfuerzo requerido para lle(ar a cabo la tarea z y aplique el multiplicador
a todas las acti(idades.
E'$imai)( %a'ada !( a'"' d! /'"
Basada en un con*unto de casos de uso y su comple*idad asociada.
e agregan (alores que modifican el tama)o.
e agregan (alores que modifican el esfuerzo.
E'$imai)( d! $amaL"M
o $omple*idad.
o ,ctores.
o 9ptimizacin.
o :eusabilidad.
o >ecnolog+a.
o alidas.
o ;ominio.
$riterios:
o %enerales.
o Particulares.
E'$imai)( d! !',/!r="M
o #adurez de la organizacin.
o E3periencia en la tecnolog+a.
o $onocimiento en el proceso.
Esfuerzo distribuido en el ciclo de (ida:
o ,*uste por solapamiento.
$riterios
o %enerales.
o Particulares.
Pr"%#!ma' !( #a' !'$imai"(!'
o La estimacin de tama)o es el paso intelectual m's dif+cil "pero no
imposible&, y muchas (eces se saltea y se traba*a directamente en la
estimacin del cronograma "tiempo&.
o Los clientes y desarrolladores a menudo no reconocen que el
desarrollo de software es un proceso gradual, que requiere el
refinamiento de las estimaciones tempranas.
o Las organizaciones a menudo no registran, guardan y analizan sus
datos histricos de performance de desarrollo de proyecto.
o , menudo es dif+cil generar cronogramas realistas aceptados por
clientes y gerentes.
Pr"0!$"' d! ma($!(imi!($"
o $uando se est' estimando el tama)o para un proyecto de
mantenimiento se debe tener en cuenta que insertar una nue(a
funcionalidad ser' factible si la arquitectura e3istente del producto
puede acomodarse a dicha funcin. $aso contrario, el esfuerzo de
mantenimiento incrementar' el retraba*o de la arquitectura.
o Puede e3istir una sobre estimacin si se utilizan modelos de
estimacin calibrados para nue(os proyectos.
o , menudo los proyectos de mantenimiento tienen fecha de entrega
fi*a as+ como un n1mero de personal asignado. Es otro elemento con
el que hay que lidiar en el momento de hacer la estimacin.
N" a.#ia( #"' m<$"d"' d! !'$imai)( .ara .r"0!$"' (/!K"' !(
.r"0!$"' d! ma($!(imi!($".
E'$imai"(!' !( Pr"0!$"' .!N/!L"'
o Proceso peque)o: traba*an una o dos personas en un tiempo menor a
J meses.
o Los datos industriales de modelos de estimacin que e3isten no est'n
calibrados para este tipo de proyecto, de modo que son inadecuados
y lo me*or es utilizar los datos histricos de la organizacin.
o Las estimaciones de los proyectos peque)os dependen en gran
medida de las capacidades de los indi(iduos que hacen el traba*o. El
Personal oftware Process es de gran ayuda para estos proyectos.