Planeacin del Proyecto

Objetivos

Comprender los fundamentos del costo del software y las razones

por las que el precio del software puede no relacionarse
directamente con el costo de desarrollo;
Conocer qu secciones debe incluir un plan de proyecto creado
dentro de un proceso de desarrollo dirigido por un plan;
Entender lo que se contempla en la calendarizacin del proyecto y
el uso de grficas de barras para presentar un calendario de
proyecto;
Conocer el juego de planeacin, utilizado para apoyar la
planeacin de proyectos en la programacin extrema;
Analizar cmo puede usarse el modelo COCOMO II para la
estimacin algortmica de costos.
Temas

Fijacin de precio al software

Desarrollo dirigido por un plan
Calendarizacin de proyectos
Planeacin gil
Tcnicas de estimacin
Planeacin de un Proyecto

La planeacin de proyectos es una de las labores ms

importantes de un administrador de proyectos de
software. Como administrador, debe dividir el trabajo en
partes y asignar stas a los miembros del equipo del
proyecto, anticipar los problemas que pudieran surgir y
preparar posibles soluciones a tales inconvenientes.
El plan creado al comienzo de un proyecto se usa para
comunicar al equipo y los clientes cmo se realizar el
trabajo, as como para ayudar a valorar el avance del
proyecto.
Etapas de Planeacin (ciclo de vida)

En la etapa de propuestas, cuando se presenta una

licitacin con vistas a obtener un contrato para
desarrollar o proporcionar un sistema de software.
Durante la fase de inicio, cuando debe determinar quin
trabajar en el proyecto, cmo se dividir el proyecto en
incrementos, cmo se asignarn los recursos a travs
de su compaa, etctera.
Peridicamente a lo largo del proyecto, cuando el plan
se modifica a la luz de la experiencia obtenida y la
informacin del monitoreo del avance del trabajo.
Plan de propuesta

La planeacin en la etapa de propuesta, inevitablemente,

es especulativa, pues muchas veces no se cuenta con un
conjunto completo de requerimientos para el software a
desarrollar.
Cuando se presenta una licitacin para obtener un
contrato, hay que calcular el precio que se propondr al
cliente para el desarrollo del software.
Costo del software

La estimacin incluye calcular cunto esfuerzo se

requiere para terminar cada actividad y, a partir de ello,
calcular el costo total de las actividades.
Siempre habr que calcular los costos del software de
manera objetiva, con la finalidad de predecir con
precisin el costo para el desarrollo del software.
Una vez que se tiene una estimacin razonable de los
probables costos, entonces es posible calcular el precio
que se cotizar al cliente.
Existen tres principales parmetros que se deben usar al
calcular los costos de un proyecto de desarrollo de
software:

Costos de esfuerzo (los costos de pagar a los

ingenieros y administradores de software);
Meses-hombre
Costos de hardware y software, incluido el
mantenimiento;
Costos de viajes y capacitacin.
El plan del proyecto siempre evoluciona durante
el proceso de desarrollo.

Si se usa un mtodo gil, hay necesidad de un plan de

inicio del proyecto pues, sin importar el enfoque
empleado, la compaa necesita planear cmo se
asignarn los recursos a un proyecto.
Sin embargo, ste no es un plan detallado y slo debe
incluir informacin limitada sobre la divisin del trabajo y
el calendario del proyecto.
Durante el desarrollo, para cada entrega (release) del
software, se define un plan de proyecto informal y las
estimaciones del esfuerzo; todo el equipo participa en el
proceso de planeacin.
Factores que afectan la fijacin del precio del software

Factor Descripcin
Oportunidad de Una organizacin de desarrollo puede cotizar un precio
mercado bajo porque quiere moverse hacia un nuevo segmento
del mercado de software. Aceptar una baja ganancia en
un proyecto puede dar a la organizacin la oportunidad
de obtener una mayor ganancia ms adelante. La
experiencia alcanzada podra ayudarle tambin a
desarrollar nuevos productos
Incertidumbre de Si una organizacin no est segura de sus estimaciones de
estimacin costos, puede aumentar su precio mediante una
de costo contingencia por arriba de su ganancia normal.
Trminos Un cliente puede permitir al desarrollador detener la
contractuales propiedad del cdigo fuente y reutilizarlo en otros
proyectos. Entonces el precio podr ser inferior al que se
cobra si el cdigo fuente se entrega al cliente.
Factores que afectan la fijacin del precio del software

Factor Descripcin
Volatilidad de Si es probable que cambien los requerimientos, una
requerimientos organizacin puede reducir su precio para ganar un
contrato. Una vez otorgado el contrato pueden cobrarse
precios altos por cambios a los requerimientos.
Salud financiera Los desarrolladores en dificultad financiera pueden
reducir sus costos para obtener un contrato. Es mejor
obtener una ganancia menor que lo normal o quedar en
un punto de equilibrio, que salir del negocio. El flujo de
efectivo es ms importante que la ganancia en tiempos
de problemas econmicos.
Desarrollo dirigido por un plan

El desarrollo dirigido por un plan o basado en un plan es

un enfoque para la ingeniera de software donde el
proceso de desarrollo se planea a detalle.
Se elabora un plan de proyecto que registra el trabajo
que se va a realizar, quin lo efectuar, el calendario de
desarrollo y los productos de trabajo. Los
administradores utilizan el plan para apoyar la toma de
decisiones del proyecto y tambin como una forma de
medir el progreso.
Lo anterior contrasta con el desarrollo gil, en el que
muchas decisiones que afectan el desarrollo se retrasan
y se hacen posteriormente, segn se requiera, durante
el proceso de desarrollo
Pros y Contras

En favor de un enfoque dirigido por un plan son que la

planeacin temprana permite que los asuntos de la
organizacin (disponibilidad de personal, otros
proyectos, etctera) se tomen estrictamente en cuenta, y
que los problemas potenciales y dependencias se
descubran antes de que se inicie el proyecto, y no
cuando ya est en marcha.
En contra el desarrollo basado en un plan es que
muchas decisiones tempranas deben revisarse debido a
cambios al entorno en los que se desarrollar y usar el
software. Retrasar las decisiones es una prctica
sensata porque evita tener que volver a trabajar.
Planes de proyecto
En el plan de proyecto se establecen los recursos
disponibles para el proyecto, la divisin del trabajo y un
calendario para realizar el trabajo. El plan debe
identificar los riesgos para el proyecto y el software en
desarrollo, as como el enfoque que se toma para la
gestin del riesgo.
Secciones:
Introduccin
Organizacin del proyecto
Anlisis de riesgo
Requerimientos de recursos de Hardware y software
Divisin del trabajo
Calendario (cronograma) del proyecto
Mecanismos de monitorizacin y reporte
Secciones

Introduccin sta describe brevemente los objetivos

del proyecto y establece las restricciones (por ejemplo,
presupuesto, tiempo, etctera) que afectan la
administracin del proyecto.

Organizacin del proyecto sta refiere la forma en que

est organizado el equipo de desarrollo, las personas
implicadas y sus roles en el equipo.
Secciones

Anlisis de riesgo Detalla los posibles riesgos del

proyecto, la probabilidad de que surjan dichos riesgos y
las estrategias propuestas para reducir el riesgo.

Requerimientos de recursos de hardware y software

Detallan el hardware y el software de soporte requeridos
para realizar el desarrollo. Si hay que comprar hardware,
pueden incluirse estimaciones de los precios y el
calendario de entregas.
Secciones

Divisin del trabajo Establece la divisin del proyecto

en actividades e identifica los plazos y las entregas
asociados con cada actividad. Los plazos son las etapas
clave del proyecto donde puede valorarse el avance; las
entregas son productos de trabajo que se proporcionan
al cliente (hitos).

Calendario del proyecto Indica las dependencias entre

las actividades, el tiempo estimado requerido para
alcanzar cada plazo y la asignacin de personal a las
actividades.
Secciones

Mecanismos de monitorizacin y reporte Esta

seccin define los informes administrativos que deben
producirse, cundo tienen que elaborarse y los
mecanismos de monitorizacin del proyecto que se
usarn.

Conjunto de tareas para planificacin de proyectos

Pressman 7ma edicin, pg.. 595
Complementos de plan de Proyecto

Plan Descripcin

Plan de calidad Describe los procedimientos de calidad y estndares

que se usarn en un proyecto

Plan de validacin DDescribe el enfoque, los recursos y el calendario

utilizados para la validacin del sistema

Configuracin del plan de Describe la configuracin de los procedimientos y las

gestin estructuras para la gestin

Plan de mantenimiento Predice los requerimientos, los costos y el esfuerzo de

mantenimiento

Plan de desarrollo de personal Describe cmo se desarrollarn las habilidades y la

experiencia de los miembros del equipo de proyecto.
El proceso de planeacin

La planeacin del proyecto es un proceso iterativo que

comienza cuando se disea un plan de proyecto inicial
durante la fase de arranque del proyecto.
Los cambios al plan son inevitables.
Conforme ms informacin sobre el sistema y el equipo est
disponible durante el proyecto, habr que revisar regularmente
el plan para reflejar los requerimientos, el calendario y los
cambios en el riesgo.
Modificar las metas de la empresa conduce tambin a cambios
en los planes del proyecto. A medida que cambien las metas de
la empresa, esto podra afectar a todos los proyectos, los cuales
tal vez deban replantearse.
El proceso de planeacin del Proyecto
Tomar en cuenta
Al comienzo de un proceso de planeacin, hay que
valorar las restricciones que afectan el proyecto. stas
son fecha de entrega requerida, personal disponible,
presupuesto global, herramientas disponibles, etctera.

En conjuncin con esto, tambin hay que identificar los

hitos y entregables del proyecto. Los hitos son puntos en
el calendario contra los que puede valorar el avance, por
ejemplo, la transferencia del sistema para pruebas.

Los entregables son productos de trabajo que se

proporcionan al cliente (por ejemplo, un documento de
requerimientos para el sistema).
Calendarizacin de proyectos

La calendarizacin de proyectos es el proceso de decidir

cmo se organizar el trabajo en un proyecto como
tareas separadas, y cundo y cmo se ejecutarn
dichas tareas.
Se estima el tiempo calendario para completar cada
tarea, el esfuerzo requerido y quin trabajar en las
tareas identificadas.
Tambin hay que estimar los recursos necesarios para
completar cada tarea (como el espacio de disco
requerido en un servidor), el tiempo que se necesitar el
hardware especializado (como un simulador) y cul ser
el presupuesto de viajes.
Tradicional y gil

Tanto los procesos basados en un plan como los giles

precisan de un calendario de proyecto inicial, aunque el
nivel de detalle puede ser menor en un plan de proyecto
gil.
En los procesos giles debe existir un calendario global
que identifique el tiempo en que se completarn las
principales fases del proyecto. Entonces, se usa un
enfoque iterativo de calendarizacin para planear cada
fase.
Duracin de una tarea

Por lo general, las tareas deben durar al menos una

semana, pero no ms de dos meses.
Una subdivisin ms fina significa que una cantidad
desproporcionada de tiempo debe emplearse para
volver a planear y actualizar el plan del proyecto.
La cantidad mxima de tiempo para cualquier tarea
debe durar alrededor de ocho a 10 semanas.
Si tarda ms que esto, la tarea debe subdividirse para la
planeacin y calendarizacin del proyecto.
Tips
Es importante evitar una situacin en la que todo el proyecto
se demore debido a que una tarea crtica no est terminada.

Como ya se sugiri, al evaluar calendarios hay que tomar en

cuenta la posibilidad de que las cosas salgan mal.

Una buena regla emprica es estimar que nada saldr mal,

luego ampliar la estimacin para enfrentar problemas
anticipados.

Las estimaciones de contingencia pueden agregar entre 30 y

50% al esfuerzo y tiempo requeridos para el proyecto.
El proceso de calendarizacin de proyecto
Representacin del calendario

Los calendarios de proyecto pueden representarse

simplemente en una tabla u hoja de clculo que indique
las tareas, el esfuerzo, la duracin esperada y las
dependencias entre las tareas.

Sin embargo, este modo de representacin dificulta

visualizar las relaciones y dependencias entre las
diferentes actividades.

Tx = tarea Mx = hito
Tareas, duraciones y dependencias - ejemplo
Representaciones ms usadas

1. Grficas de barras, basadas en el calendario, las

cuales sealan al responsable de cada actividad, el
tiempo transcurrido previsto y la fecha en que se
program el inicio y el fin de la actividad. En ocasiones,
las grficas de barras se llaman grficas de Gantt.

2. Redes de actividad, son diagramas de red que

muestran las dependencias entre las diferentes
actividades que constituyen un proyecto.
Red de tareas
Las actividades de proyecto son el elemento de planeacin
bsico. Cada actividad cuenta con:

1. Una duracin en das o meses calendario.

2. Una estimacin del esfuerzo, la cual refleja el nmero
de das-hombre o meses - hombre para completar el
trabajo. (PM persona-mes Pressman)
3. Un plazo dentro del cual debe completarse la actividad.
4. Un punto final definido. ste representa el resultado
tangible de completar la actividad. Tambin podra ser
un documento, la realizacin de una junta de revisin,
una ejecucin exitosa de todas las pruebas, etctera.
Hitos

Cuando planee un proyecto, tambin deber definir los

hitos; esto es, cada etapa del proyecto en la que puede
realizarse una valoracin del avance. Cada hito debe
documentarse mediante un breve reporte que
compendie el avance realizado y el trabajo efectuado.

Los hitos pueden asociarse con una sola tarea o con

grupos de actividades relacionadas.
Un tipo especial de hito es la produccin de un entregable del
proyecto. Un entregable es un producto de trabajo que se
entrega al cliente. Es el resultado de una fase significativa del
proyecto, como la especificacin o el diseo.
Grfica de barras de actividad
Grfica de asignacin de personal
Tcnicas de estimacin

Existe tanta incertidumbre que es imposible estimar con

precisin los costos de desarrollo del sistema durante
las primeras etapas de un proyecto.

Incluso existe una dificultad fundamental en la

valoracin de la precisin de diferentes enfoques a la
estimacin del costo y esfuerzo.

La estimacin se utiliza para definir el presupuesto del

proyecto, y el producto se ajusta para que se cumpla la
cifra del presupuesto.
Tcnicas de estimacin

1. Tcnicas basadas en la experiencia La estimacin de

los requerimientos de esfuerzo futuro se basan en la
experiencia del administrador con proyectos anteriores
y el dominio de aplicacin. En esencia, el administrador
emite un juicio informado de cules sern los
requerimientos de esfuerzo.
2. Modelado algortmico de costo En este caso se usa
un enfoque formulista para calcular el esfuerzo del
proyecto con base en estimaciones de atributos del
producto (por ejemplo, el tamao), as como las
caractersticas del proceso (por ejemplo, la experiencia
del personal implicado).
Ventajas basada en la experiencia

Se basan en juicios basados en la experiencia de

proyectos anteriores y el esfuerzo realizado en estos
proyectos en las actividades de desarrollo de software.
Por lo general, se identifican los resultados que se
deben producir en un proyecto y los diferentes
componentes de software o sistemas que se van a
desarrollar.
Se registran en un hoja de clculo para estimar en forma
individual el esfuerzo y el total requerido.
Se trabaja con un grupo de personas que estiman el
esfuerzo y justifican su estimacin.
Modelado algortmico de costos

El modelado algortmico de costos utiliza una frmula

matemtica para predecir los costos del proyecto con
base en estimaciones del tamao del proyecto, el tipo de
software a desarrollar, y otros factores de equipo,
proceso y producto:

Esfuerzo = A x TamaoB x M
Explicacin:

A es un factor constante que depende de las prcticas

locales de la organizacin y el tipo de software que se
desarrolla. El tamao puede ser una valoracin del
tamao del cdigo del software o una estimacin de la
funcionalidad expresada en puntos de funcin o de
aplicacin.
El valor del exponente B se encuentra por lo general
entre 1 y 1.5.
M es un multiplicador que se integra al combinar
atributos de procesos, producto y desarrollo, tales como
los requerimientos de confiabilidad para el software y la
experiencia del equipo de desarrollo.
Lneas de cdigo fuente

El nmero de lneas de cdigo fuente (SLOC) en el

sistema entregado es la mtrica de tamao fundamental
que se utiliza en muchos modelos algortmicos de costo.

La estimacin del tamao puede implicar estimacin por

analoga con otros proyectos, estimacin al convertir los
puntos de funcin o aplicacin al tamao del cdigo,
estimacin al clasificar los tamaos de los componentes
del sistema y uso de un componente de referencia
conocido para estimar el tamao del componente, o
simplemente puede ser una cuestin de juicio de
ingeniera.
Factor B
La mayora de los modelos de estimacin algortmica
tienen un componente exponencial (B) que se relaciona
con el tamao y la complejidad del sistema.

Esto refleja el hecho de que los costos no aumentan con

regularidad linealmente con el tamao del proyecto.

Cuanto ms complejo sea el sistema, ms afectarn al

costo estos factores (H, S, P, Inte, Pruebas etc.).

Por lo tanto, el valor de B aumenta normalmente con el

tamao y la complejidad del sistema.
Precisin de la estimacin

El tamao del sistema de software solamente puede ser

precisamente conocido cuendo este se concluye.
Varios factores afectan su tamao final
El uso de COTS y componentes;
El lenguaje de programacin;
La distribucin del sistema.
A medida que avanza el proceso de desarrollo, la
estimacin del tamao se hace ms precisa.
La estimacin de los factores B y M son subjetivos y
varian segn el juicio (experiencia) del estimador.
Incertidumbre de Estimacin
Medicin del software

Caractersticas del Condiciones

cliente empresariales

Entorno de
desarrollo
Medicin del software

Medidas directas del proceso

Costo y esfuerzo
Medidas directas del producto
LOC producidas, rapidez de ejecucin, tamao de memoria y
defectos reportados (t)
Medidas indirectas del producto
Funcionalidad, calidad, complejidad, eficiencia, confiabilidad,
capacidad de mantenimiento, etc.
Mtricas orientadas al tamao

Errores por KLOC (miles de lneas de cdigo).

Defectos por KLOC.
$ por KLOC.
Pginas de documentacin por KLOC.
Errores por persona-mes.
KLOC por persona-mes.
$ por pgina de documentacin
Mtricas orientadas al tamao
Mtricas orientadas a funcin (PF)
Consulta

Modelo/Mtricas orientadas a objeto

Modelo/Mtricas orientadas a caso de uso
Modelo/Mtricas de proyecto webapp

Entrega clase siguiente

COCOMO Bsico

E = a (KLDC)b x FAE
D = c (E)d

FAE = factor de ajuste de la estimacin (0.9 1.4)

Muy bajo, bajo, valor nominal, alto, muy alto, extra alto

Software a b c D
Orgnico 3.2 1.05 2.5 0.38
Semilibre 3.0 1.12 2.5 0.35
Rgido 2.8 1.20 2.5 0.32
FAE

Producto
Fiabilidad requerida
Tamao de la BD
Complejidad
Hardware
Rendimiento
Restriccin memoria
Volatilidad de la MV
Tiempo de espera requerido
FAE

Personal
Capacitacin de los analistas
Experiencia en aplicaciones
Capacitacin de los programadores
Experiencia en MV
Experiencias en el lenguaje de programacin
Proyecto
Prcticas modernas de programacin
Uso de herramientas para el desarrollo
Limitaciones de la planificacin
El modelo COCOMO 2
ste es un modelo emprico que se deriv al recopilar
datos a partir de un gran nmero de proyectos de
software.
Dichos datos se analizaron para descubrir qu frmulas
se ajustaban mejor con las observaciones. Dichas
frmulas vinculan el tamao del sistema y los factores
del producto, proyecto y equipo, con el esfuerzo para
desarrollar el sistema.
El modelo COCOMO II toma en cuenta enfoques ms
modernos para el desarrollo de software, tales como el
desarrollo rpido que usa lenguajes dinmicos, el
desarrollo mediante composicin de componentes y el
uso de programacin de base de datos.
El modelo COCOMO 2

Los sub modelos de COCOMO 2 son:

Un modelo de composicin de aplicacin

Un modelo de diseo temprano
Un modelo de reutilizacin
Un modelo posarquitectnico
Submodelos de COCOMO II

Un modelo de composicin de aplicacin ste

modela el esfuerzo requerido para desarrollar sistemas
que se crean a partir de componentes de reutilizacin,
escritura de guiones o programacin de base de datos.
Las estimaciones del tamao de software se basan en puntos
de aplicacin, y para estimar el esfuerzo requerido se usa una
simple frmula tamao/productividad.
La productividad depende de la experiencia y habilidad del
desarrollador, as como de las capacidades de las herramientas
de software (ICASE) usadas para apoyar el desarrollo.
Puntos de aplicacin

El nmero de puntos de aplicacin en un programa es

una estimacin ponderada del nmero de pantallas
separadas que se despliegan, el nmero de informes
que se producen, el nmero de mdulos en lenguajes de
programacin imperativa (como Java) y el nmero de
lneas de lenguaje de escritura de guiones (scripting) o
cdigo de programacin de base de datos.
Clculo del esfuerzo

PM = (NAP x (1 - %reutilizacin /100)) / PROD

PM es la estimacin del esfuerzo en meses-hombre.

NAP es el nmero de puntos de aplicacin en el sistema
entregado
% reutilizacin es una estimacin de la cantidad de cdigo de
reutilizacin en el desarrollo.
PROD es la productividad del punto de aplicacin,
Productividad de punto de aplicacin
Un modelo de diseo temprano Este modelo se usa
durante etapas tempranas del diseo del sistema
despus de establecer los requerimientos.
La estimacin se basa en la frmula de estimacin
estndar, con un conjunto simplificado de siete
multiplicadores.
Esfuerzo = A x TamaoB x M
Boehm A = 2,94 Tamao se expresa en KLDC (en base a los
PF) y B varia entre 1,1 a 1,24, que depende de: la novedad del
proyecto, flexibilidad del desarrollo, procesos de resolucin de
riesgos utilizados, cohesin del equipo de desarrollo y nivel de
madurez del proceso
Las estimaciones se basan en puntos de funcin, que luego se
convierten a nmero de lneas de cdigo fuente.
Factor M

M = PERS x RCPX x RUSE x PDIF x PREX x FCIL x SCED

Habilidad personal (PERS)

Fiabilidad y complejidad del producto (RCPX)
Reutilizacin requerida (RUSE)
Dificultad de plataforma (PDIF)
Experiencia personal (PREX)
Facilidades de soporte (FCIL)
Calendario (SCED)
Los valores para dichos atributos se estiman mediante una escala
de seis puntos, donde 1 corresponde a muy bajo y 6 corresponde
a muy alto.
Puntos de funcin - PF

Los puntos de funcin son una forma independiente de

lenguaje para cuantificar la funcionalidad del programa.
El nmero total de puntos de funcin en un programa se
calcula al medir o estimar el nmero de entradas y
salidas externas, las interacciones de usuario, las
interfaces externas y las tablas de archivos o bases de
datos que usa el sistema.
Puntos de Funcin

Nmero de entradas de usuario. Se cuenta cada

entrada de usuario que proporciona diferentes datos
orientados a la aplicacin. Las entradas se deberan
diferenciar de las peticiones, las cuales se cuentan de
forma separada.
Nmero de salidas de usuario. Se cuenta cada salida
que proporciona al usuario informacin orientada a la
aplicacin. En este contexto la salida se refiere a
informes, pantallas, mensajes de error, etc. Los
elementos de datos particulares dentro de un informe no
se cuentan de forma separada.
Puntos de Funcin

Nmero de peticiones de usuario. Una peticin se

define como una entrada interactiva que produce la
generacin de alguna respuesta del software inmediata
en forma de salida interactiva. Se cuenta cada peticin
por separado.
Nmero de archivos. Se cuenta cada archivo maestro
lgico (esto es, un grupo lgico de datos que puede ser
una parte de una gran base de datos o un archivo
independiente).
Nmero de interfaces externas. Se cuentan todas las
interfaces legibles por la mquina (por ejemplo: archivos
de datos de cinta o disco) que se utilizan para transmitir
informacin a otro sistema.
Puntos de funcin - clculo
PF (Pressman)

PF = conteo total x [0.65 + 0.01 x (Fi)]

Los fatores Fi (i=1 a 14) son factores de ajuste de valor (FAV)

en base a la respuesta de las siguientes preguntas, em
uma escala que va de 0 no importante o no aplicable, a 5
absolutamente esencial:
 Preguntas
1. El sistema requiere respaldo y recuperacin confiables?
2. Se requieren comunicaciones de datos especializadas para transferir informacin hacia o
desde la aplicacin?
3. Existen funciones de procesamiento distribuidas?
4. El desempeo es crucial?
5. El sistema correr en un entorno operativo existente enormemente utilizado?
6. El sistema requiere entrada de datos en lnea?
7. La entrada de datos en lnea requiere que la transaccin de entrada se construya sobre
mltiples pantallas u operaciones?
8. Los archivos maestros se actualizan en lnea?
9. Las entradas, salidas, archivos o consultas son complejos?
10. El procesamiento interno es complejo?
11. El cdigo se disea para ser reutilizable?

12. La conversin y la instalacin se incluyen en el diseo?

13. El sistema se disea para instalaciones mltiples en diferentes organizaciones?
14. La aplicacin se disea para facilitar el cambio y su uso por parte del usuario?
Un modelo de reutilizacin Este modelo se emplea
para calcular el esfuerzo requerido al integrar los
componentes de reutilizacin y/o cdigo de programa
generado automticamente. Muchas veces se utiliza en
conjunto con el modelo posarquitectnico.

Un modelo posarquitectnico Una vez diseada la

arquitectura del sistema, puede hacerse una estimacin
ms precisa del tamao del software.
Usa la frmula estndar para estimacin, sin embargo, incluye
un conjunto ms extenso de 17 multiplicadores que reflejan
caractersticas de capacidad personal, del producto y del
proyecto.
Estimacin ms probable
Consulta

Consulta
El valor esperado
y ejemplo,
para
sobre
la variable
el modelo
de estimacin
de Reutilizacin y
(tamao)
Posarquitectnico.
S puede calcularse como un promedio
ponderado de las estimaciones optimista (Sopt), ms
probable (Sm) y pesimista (Spes). Por ejemplo,
Entregar la siguiente clase.

S = (Sopt + 4Sm + Spes) / 6

Evaluacin del tema.