7/31/2019 39861943 Unidad II Planif y Modelado
1/80
Planificacin y ModeladoPlanificacin del Sistema
UNIDAD 2
Planificacin del Sistema
De acuerdo con Sommerville [SOM00], la gestin de proyectos de software se
hace necesaria ya que todo proyecto esta sujeto a restricciones de
presupuesto y tiempos. La gestin permite asegurar que el software se lleve acabo a tiempo y de acuerdo con los requerimientos especificados.
La gestin del software es particularmente difcil, algunas de las razones son:
o El producto de software es intangible. Esto obliga a los gestores del
proyecto a confiar en los otros miembros del personal para la toma de
decisiones.
o No hay un proceso estndar. Y por lo tanto tampoco se tiene la certeza
de cuando un proceso en particular empieza a tener problemas.
o A menudo los proyectos de software grandes son nicos. Esto se refiere
a que los proyectos se diferencian unos de otros, por lo que hasta los
gestores ms experimentados no siempre podrn anticipar los
problemas.
Las de las actividades comunes de la gestin de proyectos software son:
o Redaccin de la propuesta.
o Planificacin del proyecto
o estimaciones de costo, tiempo y esfuerzo.
o Supervisin y revisin del proyecto.
o Seleccin y evaluacin del personal.
Ingeniera en Sistemas Computacionales
17
7/31/2019 39861943 Unidad II Planif y Modelado
2/80
Planificacin y ModeladoPlanificacin del Sistema
o Redaccin y presentacin de informes.
Las actividades listadas anteriormente son responsabilidad del gestor de
proyectos. A continuacin se considera importante discutir el tema referente a
la seleccin del personal, ya que ste representa una pieza clave para una
buena gestin de proyecto. La cantidad de personas requeridas para el
desarrollo de un proyecto de software solo puede determinarse despus de
hacer una estimacin de esfuerzo de desarrollo, por ejemplo, personas mes o
personas aos. An as empezando un proyecto se tendr que dar un
aproximado del personal necesitado y asignarlas a las diferentes tareas o
actividades, para as poder realizar estimaciones de costo y tiempo.
Seleccin del personal
Todo proyecto requiere personal que interacte con los clientes par determinar
los requerimientos, otro grupo de personas diferentes para disear el sistema,
otros para escribirlo, otros que los prueben etc. [PFL02]. El gestor del proyecto
se encarga de seleccionar al personal que constituir su equipo de trabajo.
Debe establecer un equipo ideal mnimo de acuerdo a las restricciones del
presupuesto, y a la disponibilidad del personal con o sin experiencia, esto por
que algunas veces se desea capacitar al personal dentro de la misma empresa
[SOM00]. Al momento de seleccionar el personal de trabajo el gestor debe
[PFL02]:
o Asignar tareas que desempearn
o Designar a los jefes de equipo.
o La estructura organizacional de los diferentes equipos.
La asignacin de tareas al personal depende de la dimensin del proyecto, de
la destreza y experiencia de stos. Una vez que se decide el rol de los
miembros de cada grupo que conformarn el equipo del proyecto, el gestor
debe decidir el tipo de personas que necesita para cada rol. Ya que el personal
difiere en muchas maneras, no basta decir que un proyecto necesita de una
Ingeniera en Sistemas Computacionales
18
7/31/2019 39861943 Unidad II Planif y Modelado
3/80
Planificacin y ModeladoPlanificacin del Sistema
analista, dos diseadores y cinco programadores, por poner un ejemplo. De
acuerdo con Sommerville [SOM00], la seleccin del personal se realiza de
acuerdo a los siguientes factores:
o Experiencia en el dominio de la aplicacin.
o Experiencia en la plataforma.
o Experiencia en el lenguaje de programacin.
o Capacidad de aprender.
o Habilidades de comunicacin.
o Adaptabilidad.
o Actitud.
o Personalidad.
Cada una de estas caractersticas, puede afectar la capacidad del individuo
para desempearse en forma productiva. La forma en que se desempea un
trabajador es muy importante para el xito de un proyecto, se debe tener en
cuenta que algunas personas son buenas cuando se trata de captar lo global
en un proyecto y a otras se le facilita el trabajar en una pequea parte de ste.
Ambos tipos de personas podran sentirse incomodas realizando trabajos
opuestos. Por lo anterior se deduce que un trabajador se desempear mejor si
est cmodo con el trabajo que realiza, y es ms productivo cuando tiene
confianza en su capacidad para desempearse. El estimular al personal para
que desempee bien su trabajo es tambin tarea del gestor. El estimulo puede
ser invitndolo a crear algo diferente a lo que siempre hace, o a mejorarlo; con
esto mantendr el inters del personal en su trabajo [PFL02].
El personal debe ser flexible. La capacidad de compartir responsabilidades o
carga de trabajo, es muy importante, ya que a una tarea se le puede asignar
ms de una persona que trabajen en un mismo equipo. Entonces entre el
personal tambin deben tener confianza en que cada uno realizar su parte del
trabajo, y aceptar los resultados del otro sin querer cambiar o repetir su
trabajo.
Ingeniera en Sistemas Computacionales
19
7/31/2019 39861943 Unidad II Planif y Modelado
4/80
Planificacin y ModeladoPlanificacin del Sistema
La interaccin personal tambin est relacionada con la comodidad y confianza
entre los miembros del equipo, algunas personas son buenas dirigiendo el
trabajo de otras, a las cuales sera bueno asignarles el control de x equipo, este
tipo de personas son buenas alentando a su equipo para cumplir con un
calendario y lograr las metas, o para reunirse con el cliente. Resulta
beneficioso el que el personal se sienta motivado por el exitoso cumplimiento
de las metas personales y del equipo.
La comunicacin verbal y escrita tanto de ideas como resultados es crucial, ya
que ayuda al avance del proyecto, como la comunicacin con el cliente, cuando
se est investigando sobre los requisitos bsicos del proyecto; cuando se debe
comunicar al jefe del equipo y este al gestor del proyecto de los avances o
fallas durante el desarrollo. En un proyecto, el nmero de personas que
necesitan comunicarse entre s y la buena o mala comunicacin, pueden
afectar la calidad del producto final. La tabla 2.1 muestra como se incrementan
las lneas de comunicacin. En general si un proyecto tiene n trabajadores, hay
n ( n-1 ) /2 pares de personas que probablemente necesitarn comunicarse
y 2n 1 grupos posibles que pueden crearse para trabajar en secciones ms
pequeas del proyecto.
Nmero de
personas
Lneas de comunicacin
13 34 65 10N n (n-1 ) /2
Tabla 2.1 Caminos de comunicacin en un proyecto
La comunicacin puede ser uni/ bidireccional, segn el nivel asignado a cada
persona.
Otro factor importante en la seleccin del personal es el estilo de trabajo. La
compresin de estos estilos fomenta la flexibilidad que se hace necesaria para
un buen trabajo en equipo, as como permite tener una mejor decisin de
Ingeniera en Sistemas Computacionales
20
7/31/2019 39861943 Unidad II Planif y Modelado
5/80
Planificacin y ModeladoPlanificacin del Sistema
quien se comunicar con el cliente y/o usuario. Personas diferentes tienen
diferentes estilos para interactuar con otras personas y para entender los
problemas que surgen en el curso de trabajo. Por ejemplo un hay personas que
gustan de hacer un anlisis detallado de toda la informacin antes de tomar
una decisin, contrariamente habr personas que solo necesiten confiar en su
intuicin para tomar alguna decisin importante.
Los estilos de trabajo afectan las interacciones de un proyecto entre clientes,
desarrolladores y usuarios. A continuacin se muestran en la figura 2.2 una
variedad de stos, la comunicacin la constituye el eje horizontal y los estilos
de decisin el vertical. Se debe sealar que no todas las personas encajan en
estos cuatro estilos. Por ejemplo la siguiente lista de caractersticas
corresponde al estilo de trabajo de los extrovertidos intuitivos:
o rara vez piden opiniones,
o prefieren comunicar sus propias ideas y
o basan la mayora de sus decisiones en intuiciones.
Fig. 2.2 Estilos de trabajo
La organizacin de un proyecto.(aqu me Qede)
El conjunto de personas que conforman el gran equipo de un proyecto deben
trabajar de manera conjunta y coordinada, lo que asegura la obtencin de
Ingeniera en Sistemas Computacionales
21
7/31/2019 39861943 Unidad II Planif y Modelado
6/80
Planificacin y ModeladoPlanificacin del Sistema
productos de calidad. La eleccin de una estructura apropiada depende del
nmero de personas en el equipo, de las caractersticas de personal y los
estilos de trabajo, entre otras cosas. Existen muchas formas de para la
organizacin de proyectos, a continuacin se describirn dos tipos de
organizacin, los cuales son los extremos.
Una muy popular es el equipo de jefe de programadores (chief programmer
team). En este tipo de organizacin, una persona (el jefe de programadores) es
responsable por el diseo del sistema y su desarrollo; tiene un sustituto para
cuando sea necesario reemplazarlo. El jefe de programadores tiene los
siguientes privilegios y responsabilidades:
o Recibe reportes del resto del de los miembros del equipo
o Tiene la ltima palabra en la toma de decisiones (por lo que debe ser
una persona que tome buenas decisiones rpidamente)
o Disea todos los programas
o Asigna el desarrollo de codificacin a otros miembros
o Supervisa al resto del equipo
Este tipo de organizacin cuenta con un bibliotecario asiste al equipo y es
responsable de:
o Darle mantenimiento a la documentacin
o Compilar y hacer enlace (link edition ) de cdigo
o Ejecutar pruebas preeliminares
La responsabilidad recae sobre una sola persona, lo que hace que la estructura
minimice la comunicacin necesaria durante el proyecto. Cada miembro delequipo a menudo tiene que comunicarse con el jefe, pero no necesariamente
con otros miembros del equipo. Por lo tanto si el equipo consiste de n-1
programadores ms el jefe, el equipo solamente puede establecer n-1 caminos
de comunicacin ms all de un potencial de n (n-1) / 2 caminos.
Ingeniera en Sistemas Computacionales
22
7/31/2019 39861943 Unidad II Planif y Modelado
7/80
Planificacin y ModeladoPlanificacin del Sistema
Aunque esta estructura sea jerrquica, se pueden formar grupos de trabajotes
para llevar a cabo una tarea especializada que requiera ms de una persona
para su elaboracin.
Fig. 2.3 organizacin del jefe de programadores.
El otro extremo se basa en la idea de una programacin sin egosmo como lo
describe Weinberg (1971). En vez de un nico punto de responsabilidad, otorga
a todos los miembros responsabilidades equivalentes.
La estructura de un equipo sin egosmo se diferencia de jefe de
programadores, en lo siguiente:
Es una estructura democrtica
Todos los miembros del equipo participan en la toma de decisiones
mediante votos.
Cul de las estructuras anteriores es preferible utilizar? Si el proyecto que se
pretende llevar a cabo cuenta con las siguientes caractersticas entonces
necesitar de una estructura formal jerrquica y tambin de una organizacin
bien definida. Este tipo de proyectos tiene:
o Un gran nmero de personal involucrado
o Un alto grado de certeza
Ingeniera en Sistemas Computacionales
23
7/31/2019 39861943 Unidad II Planif y Modelado
8/80
Planificacin y ModeladoPlanificacin del Sistema
o Estabilidad
o Uniformidad
o repeticin
Este tipo de proyectos requieren menos comunicacin entre los miembros del
equipo, una comunicacin vertical, y se adaptan mejor a este tipo de
estructura organizacional ya que imponen reglas, especializacin, formalidad y
una clara definicin de la jerarqua organizacional.
Por otro lado, un proyecto necesitar una estructura aproximada a la
democrtica si tiene las siguientes caractersticas:
o Un pequeo nmero de personal involucrado
o Existe cierto nivel de incertidumbre
o Realizan pruebas con tcnicas o tecnologa nuevas
Comnmente en este tipo de proyectos los requerimientos probablemente
cambien durante su desarrollo, por esto necesitan una estructura ms flexible
con
amplia comunicacin abierta y por lo tanto la participacin de todos los
miembros del equipo.
Teniendo el conocimiento de cmo seleccionar al personal para el equipo del
proyecto y la manera de organizarlo para su ptimo desempeo, se puede
profundizar en el tema de la planificacin del proyecto que abarca el resto de
la unidad. A continuacin se da una breve introduccin de ste antes de
describirlo de manera ms detallada.
De acuerdo con George Steiner [STE89], planear significa disear un futuro
deseado e identificar las formas para lograrlo.
Qu es la planificacin:
Ingeniera en Sistemas Computacionales
24
7/31/2019 39861943 Unidad II Planif y Modelado
9/80
Planificacin y ModeladoPlanificacin del Sistema
o Es una gua de desarrollo para cumplir las metas del proyecto.
o Es un proceso iterativo el cual termina hasta que el proyecto mismo
haya terminado. Esto quiere decir que su revisin es continua, ya que
tanto requerimientos como restricciones pueden cambiar a lo largo del
desarrollo [SOM00].
El xito o fracaso de un proyecto de software depende en gran parte de la
planificacin, ya que con ayuda de sta se pueden evitar problemas a los que
un proyecto est sujeto, tales como:
o Retraso de tiempo de entrega
o Sobrepasar el presupuesto
o Baja calidad del producto
o Alto costo de mantenimiento, etc.
El gestor de proyecto es responsable de planear y supervisar el proyecto para
que este se lleve a cabo:
o dentro de los tiempos establecidos
o conforme a los estndares requeridos
o acorde al presupuesto
Durante la planificacin, el gestor del proyecto debe tener un plan para
enfrentarse a los problemas que puedan surgir durante el desarrollo del
proyecto y poder solucionarlos. Al ir desarrollndose el proyecto se obtiene
mayor y mejor informacin, esto modificar el plan inicial, lo que conduce a
replanear el calendario de actividades necesarias para desarrollar el proyecto.
Los pasos de la planificacin de un proyecto comprende las siguientes
ilustradas en la figura 2.4:
o Delimitar el mbito del software
o Realizar estimaciones de tiempo, costo y esfuerzo
o Calendarizar el trabajo
Ingeniera en Sistemas Computacionales
25
7/31/2019 39861943 Unidad II Planif y Modelado
10/80
Planificacin y ModeladoPlanificacin del Sistema
o Gestionar riesgos
o Controlar la calidad y los cambios
o Gestin de configuracin de software
Fig. 2.4 actividades de la gestin y planificacin
La planificacin inicia con la valoracin de las restricciones impuestas por el
cliente. Es importante que antes de realizar la estimacin, se delimite el
mbito del software. En esta etapa se evalan las funciones, y desempeo del
software. Se describen los datos que se procesarn, funciones, desempeo,
restricciones, interfaces y viabilidad [PRE02]. Las actividades de planificacin
del tiempo, estimacin de costo y recursos para acometer el esfuerzo de
desarrollo, se describen posteriormente los puntos 2.1 y 2.2 respectivamente.
Dentro del Proceso Unificado (PU) [JBR00], la planificacin del proyecto es
similar a la planificacin estndar para cualquier proyecto de software. La
planificacin del sistema se ve presente en cada una de las fases del proceso
unificado.
En cada una de estas y en cada iteracin se realiza lo siguiente:
o se toman las decisiones de continuar o no con el proyecto
o se determina
o el calendario
o el presupuesto
Ingeniera en Sistemas Computacionales
26
7/31/2019 39861943 Unidad II Planif y Modelado
11/80
Planificacin y ModeladoPlanificacin del Sistema
o se gestionan los
o requerimientos
o y riesgos
Los cinco flujos de trabajo fundamentales (requerimiento, anlisis, diseo,
implementacin y prueba), mas la planificacin y evaluacin de la iteracin,
constituyen lo que se llama la iteracin genrica. El nmero de iteraciones
depender bsicamente de la complejidad del sistema propuesto. A mayor
complejidad mayor nmero de iteraciones en cada fase. La planeacin de la
iteracin incluye los siguientes pasos:
1. Primeramente se identifican los recursos humanos, es decir, los
individuos disponibles para actuar como trabajadores.
2. Teniendo conocimiento de los recursos, se calendarizan las iteraciones.
Aqu se decide cunto tiempo puede tomar cada iteracin y as asignarle
una fecha de terminacin. Esta calendarizacin se refina en cada fase, a
principio grosso modo y posteriormente con mayor precisin.
3. Conociendo el tiempo aproximado para cada iteracin, enseguida se
realiza una estimacin de costos en esfuerzo y dinero de cada fase.
4. Luego se planea detalladamente las actividades de cada iteracin.
Cada iteracin debe ser evaluada para entre otras cosas, conocer los
beneficios y la parte del trabajo que se ha completado por sta. Tambin
ayuda en lo siguiente:
o Reconsiderar el plan de la siguiente iteracin para realizar los cambios
necesarios a ste.
o
Modificar el proceso, adaptar las herramientas, prolongar la preparaciny realizar otras acciones sugeridas por la iteracin evaluada.
Por medio de la evaluacin el gestor de proyecto se da cuenta si el proyecto va
progresando, en otras palabras necesita saber si el proyecto est:
Ingeniera en Sistemas Computacionales
27
7/31/2019 39861943 Unidad II Planif y Modelado
12/80
Planificacin y ModeladoPlanificacin del Sistema
o avanzando de acuerdo al presupuesto y calendarizacin.
o cumpliendo con los criterios de calidad.
Si no se cumplen con lo criterios de evaluacin entonces se tendr que
prolongar el trabajo en la siguiente iteracin.
Una vez evaluada la iteracin, el gestor del proyecto realiza lo siguiente:
1. Determina que el trabajo est listo para la siguiente iteracin.
2. Asigna el trabajo incompleto a las siguientes iteraciones.
3. Planea en detalle la siguiente iteracin.
4. Actualizar la lista de riesgos y el plan del proyecto.
5. Compara el costo y la planificacin de la iteracin con los planeados.
2.1 Planificacin del tiempo
El factor tiempo es muy importante en el desarrollo de software ya que
ganaremos o perderemos a un cliente si este no es entregado en los tiempos
establecido o ya negociados.
La planificacin de tiempo se puede definir como una actividad en la cual se
debe estimar el tiempo que requerir para llevar a cabo una tarea y los
recursos necesarios para su realizacin.
Durante la recoleccin de requerimientos, se listan todos los elementos que se
deben entregar del proyecto, que son los tems que los clientes esperan ver
durante el desarrollo del proyecto, tales como:
o La documentacin, que describir el estado del software en desarrollo.
o Demostraciones de funciones, precisin, confiabilidad, seguridad, y
desempeo.
Ingeniera en Sistemas Computacionales
28
7/31/2019 39861943 Unidad II Planif y Modelado
13/80
Planificacin y ModeladoPlanificacin del Sistema
A continuacin se muestran los hitos y actividades que se deben llevar a cabo
para lograr dichos elementos. Se debe distinguir claramente entres una
actividad y un hito.
Una actividad:
o Es un evento medible.
o Es una parte del proyecto que tiene lugar durante un periodo de tiempo.
o Tiene un principio y un fin.
Se puede describir con cuatro parmetros:
o Precursor: evento o conjunto de stos, que deben ocurrir antes que la
actividad pueda comenzar. Son las condiciones que permiten que una
actividad comience.
o Duracin: tiempo necesario para completar una actividad.
o Fecha de entrega: la fecha para cual la actividad debe ser completada.
o Punto final: entendiendo que una actividad ha terminado es un hito o un
componente para entregar.
Un hito:
o Es un evento que indican el alcance de un nivel mensurable en el
proyecto.
o Es la completitud y final de una actividad y sucede en un determinado
momento.
o Debe representar el fin de una etapa lgica del proyecto.
o Son productos a entregar para el cliente o resultados de una actividadpara el gestor de proyectos.
Cuando se trata de un resultado de una actividad los informes de estos
logros deben ser cortos.
Ingeniera en Sistemas Computacionales
29
7/31/2019 39861943 Unidad II Planif y Modelado
14/80
Planificacin y ModeladoPlanificacin del Sistema
Ejemplos de hitos son los siguientes:
o la especificacin de requerimientos.
o la terminacin de un manual de usuario
o realizacin de un conjunto de clculos
o demostracin de la capacidad de comunicacin en el sistema.
Si el cliente quiere que el sistema se entregue acompaado de un tutorial
asistido por un operador en lnea, el desarrollo de dicho tutorial y sus
programas asociados son ejemplo de una actividad, que culmina en la
demostracin de las funciones requeridas por el cliente, este es otro ejemplo
de hito[PFL02].
De acuerdo con Sommerville [SOM00], para determinar los hitos en un proceso
de desarrollo de software, es necesario dividirlo en actividades bsicas junto
con sus salidas asociadas, como se muestra en la figura 2.1.1:
Fig. 2.1.1 Actividades y hitos en el desarrollo de software
La descomposicin en hitos y actividades beneficia:
Tanto a clientes como desarrolladores para entender el desarrollo y
mantenimiento del sistema.
Al gestor para juzgar el progreso del software y puede entonces
actualizar costos y el calendario.
Dentro del PU, los desarrolladores dividen el trabajo en partes ms pequeas y
compresibles, equivale a dividirlo en fases y cada una de stas en iteraciones.
Ingeniera en Sistemas Computacionales
30
7/31/2019 39861943 Unidad II Planif y Modelado
15/80
Planificacin y ModeladoPlanificacin del Sistema
Dentro de cada iteracin se debera trabajar en las cosas apropiadas,
permitiendo alcanzar un equilibrio entre las secuencias de actividades
ejecutadas en la misma iteracin. De esto se deduce que dos taras muy
importantes de un proyecto son:
1. seleccionar las cosas correctas en las que trabajar dependiendo del
punto del ciclo de vida en que se encuentre el proyecto.
2. determinar el equilibrio de las secuencias de las actividades, es decir
asignarles prioridades para sincronizarlas con facilidad.
Las fases son la primera divisin del trabajo. En cada fase las primeras
iteraciones se centran en los flujos de requerimientos, anlisis y diseo, como
sera el trabajar con riesgos, casos de uso fundamentales, cuestiones
arquitectnicas, etc. Y en las ltimas iteraciones se trabaja con actividades
orientadas al desarrollo, como la implementacin y prueba, evaluacin de
desempeo [JBR00].
Durante la fase de elaboracin el objetivo principal es crear una lnea base
para la arquitectura y la estimacin de costos con gran precisin, as como la
planificacin de la fase de construccin, siendo sta muy precisa, que
abarcara la planificacin de tiempo y costos que se ver en la seccin 2.2
(anlisis costo-beneficio).
Una vez definidas las actividades y hitos lo siguiente es calendarizar el
proyecto, esto es, dividir el trabajo en actividades o tareas complementarias y
considerar el tiempo que requiere cada una para completarse. Generalmente
se representa con grficos de barras y grafos o redes de actividades que
muestran las actividades, los responsables, la dependencia entere actividades
y la asignacin de recursos, entre otras cosas.
El gestor debe coordinar las tareas del trabajo, asignarles a stas el personal y
otros recursos de tal manera que se aprovechen de manera ptima. Las
actividades por lo general duran al menos una semana, la cantidad de tiempo
mxima sugerida es de 8 a 10 semanas.
Ingeniera en Sistemas Computacionales
31
7/31/2019 39861943 Unidad II Planif y Modelado
16/80
Planificacin y ModeladoPlanificacin del Sistema
El calendario debe actualizarse continuamente a medida de que progrese el
proyecto y se obtenga mejor informacin. Tambin es necesario hacer uso de
documentos que describan el estado del software durante su desarrollo, para
as facilitar los cambios.
Los siguientes son problemas a los cuales un gestor de proyectos se puede
enfrentar, lo que representa retrasos en algunas actividades:
Personal faltante.
Hardware o software defectuosos o que no estn disponibles a tiempo.
Proyectos con mtodos de diseos y lenguajes diferentes.
Proyectos nuevos que utilizan tcnicas complejas.
Una regla prctica, es hacer la estimacin como si nada fuera a salir mal, e
incrementar la estimacin entre un 20% y 30% para cubrir los imprevistos.
2.1.1 Mtodos de Planificacin temporal
Existen varios mtodos para la planificacin aqu se describirn:
La tcnica de revisin y evaluacin del programa(PERT)
y CPM la ruta crtica
Tambin existen varias representaciones grficas como los son:
redes de actividades
Grficos de barras
Por medio de una red de actividades se muestra la dependencia entre las
diferentes actividades y se estima el tiempo en que tardar cada tarea,debemos considerar que algunas de estas se podrn realizar en paralelo. Ya
que pueden surgir problemas las suposiciones iniciales del calendario deben
ser pesimistas para tener holgura y poder llevar a cabo el plan dentro de los
tiempos establecidos [SOM00].
Ingeniera en Sistemas Computacionales
32
7/31/2019 39861943 Unidad II Planif y Modelado
17/80
Planificacin y ModeladoPlanificacin del Sistema
Ejemplo: Supongamos las actividades mostradas en la tabla 2.1.2, se muestra
su duracin e interdependencia. La M representa un hito.
Tarea T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12
Duracin(das)
8 15 15 10 10 5 20 25 15 15 7 10
Dependencias
T1
(M1
)
T2,T
4
(M2
)
T1,T
2
(M3
)
T1
(M1
)
T4
(M5
)
T3,
T6
(M4
)
T5,
T7
(M7
)
T9
(M6
)
T11
(M8
)
Tabla 2.1.2 duracin y dependencias de las actividades
Teniendo la dependencia y duracin estimada de las actividades, un diagrama
de actividades muestra la sucesin de actividades que deben generarse, las
que se llevan en paralelo y las que deben ejecutarse en secuencia, debido a la
dependencia con una actividad previa.
El diagrama que se muestra en la figura 2.1.3, se produce con ayuda de una
herramienta de gestin de proyecto, y se requiere que todas las actividades
terminen en hitos. El diagrama se debe leer de izquierda a derecha y de arriba
hacia abajo. Las actividades se representan con rectngulos, los hitos y
productos con esquinas redondeadas.
Una actividad comienza cuando su hito precedente se ha alcanzado. Y antes
de poder pasar de un hito a otro, todas las trayectorias deben completarse. Por
ejemplo T9 no puede iniciar hasta completarse T3 y T6, cuando se llega a M4
entonces estas tareas ya se habrn completado.
Ingeniera en Sistemas Computacionales
33
7/31/2019 39861943 Unidad II Planif y Modelado
18/80
Planificacin y ModeladoPlanificacin del Sistema
Fig. 2.1.3 Diagrama de actividades
Para estimar el tiempo mnimo requerido para finalizar el proyecto, se toma en
cuenta la trayectoria ms larga en el diagrama de actividades, la trayectoria
crtica. En este ejemplo es de 11 semanas o 55 das laborales, y est resaltada
en la figura anterior.
El calendario realizado depende de esta trayectoria crtica, si se presentaralgn problema para completar una actividad dentro de la trayectoria crtica,
provocara demora en el proyecto. Hay que sealar que si hay algn retraso en
actividades que no se encuentren dentro de la trayectoria crtica no provocan
necesariamente demora en todo el calendario.
Una alternativa es utilizar los grficos de barras (tambin llamados grficos de
Grantt) muestran quien hace qu, cuando inicia y cuando termina. Se pueden
generar automticamente a partir de una base de datos utilizando
herramientas de gestin.
Ejemplo: considerando las actividades anteriormente listadas. El siguiente
diagrama de la figura 2.1.4 muestra las actividades, hitos y tiempo estimado.
Ingeniera en Sistemas Computacionales
34
7/31/2019 39861943 Unidad II Planif y Modelado
19/80
Planificacin y ModeladoPlanificacin del Sistema
Fig. 2.1.4 grfico de barras de actividades de un proyecto de software
Las actividades son seguidas por una barra sombreada (en este caso se resalta
de color azul) y cuya longitud es calculada por una herramienta de
calendarizacin. La barra azul indica que hay flexibilidad en las fecha de
terminacin para dichas actividades. Entonces, la trayectoria crtica se ve
afectada solamente si:
las actividades que no tiene la barra azul no se completan a tiempo.
las actividades con barra azul pasa del lmite de tiempo marcado por
sta.
Tambin se puede hacer uso de los grficos de barras para mostrar las
personas asignadas a las diferentes actividades y tambin el tiempo en que se
ocupar a las personas. La tabla 2.1.5 muestra la asignacin de personas a las
actividades y la figura 2.1.6 lo muestra junto con el tiempo asignado.
Ingeniera en Sistemas Computacionales
35
7/31/2019 39861943 Unidad II Planif y Modelado
20/80
Planificacin y ModeladoPlanificacin del Sistema
TareaIngenier
o
T1 Jane
T2 Anne
T3 Jane
T4 FredT5 Mary
T6 Anne
T7 Jim
T8 Fred
T9 Jane
T10 Anne
T11 Fred
T12 Fred
Tabla 2.1.5 asignacin de personal a actividades
Fig. 2.1.6 grfico de barras de actividades de un proyecto de software
Ingeniera en Sistemas Computacionales
36
7/31/2019 39861943 Unidad II Planif y Modelado
21/80
Planificacin y ModeladoPlanificacin del Sistema
PERT Y CPM
A continuacin se describirn el mtodo PERT (Program Evaluation and Review
Technique) y el mtodo CPM (Crtical Path Method), que fueron desarrollados
en Estados Unidos en 1957 [4 y 5].
Ambos mtodos aportaron los elementos administrativos necesarios para
formar el mtodo del camino crtico actual, utilizando el control de los tiempos
de ejecucin y los costos de operacin, para buscar que el proyecto total sea
ejecutado en el menor tiempo y al menor costo posible. Tanto PERT como CPM
hacen uso de diagramas o redes de actividades.
El PERT se desarroll para proyectos en donde hubiera incertidumbre en el
tiempo de las actividades (usualmente debido a que el proyecto nunca se
haba intentado antes y por tanto no haba bases de datos, para los tiempos de
las actividades). Esto condujo al enfoque probabilstico que se tom. Mientras
que en PERT los estimados de tiempo y sus distribuciones han sido de
controversia, el PERT ha constituido una herramienta til para la
administracin de proyectos. La principal desventaja es que no es funcional
para grandes proyectos, debido a los tres estimados de tiempo que serequieren en cada actividad y a la capacidad limitada de los computadores
actuales, para almacenar esta vasta cantidad de datos. Adems, el costo de
actualizar y mantener la informacin del proyecto con el tiempo en ambientes
tan dinmicos, puede ser excesivamente prohibitivo.
Por otra parte, el CPM se desarroll para manejar proyectos repetitivos o
similares (ej., mantenimiento de plantas qumicas). Obviamente, se gana gran
cantidad de experiencia con el tiempo en tales circunstancias, aun cuando dos
proyectos puede que no sean iguales. Esta experiencia llev al anlisis de
tcnicas de colisin utilizadas en las redes CPM.
A pesar de que PERT y CPM difieren un poco en terminologa y en la forma de
construir el diagrama de red, sus objetivos son los mismos. El anlisis usado
por ambas tcnicas es muy similar.
Ingeniera en Sistemas Computacionales
37
http://www.monografias.com/trabajos11/metods/metods.shtmlhttp://www.monografias.com/trabajos11/basda/basda.shtmlhttp://www.monografias.com/trabajos12/pmbok/pmbok.shtmlhttp://www.monografias.com/trabajos11/basda/basda.shtmlhttp://www.monografias.com/trabajos12/pmbok/pmbok.shtmlhttp://www.monografias.com/trabajos11/metods/metods.shtml7/31/2019 39861943 Unidad II Planif y Modelado
22/80
Planificacin y ModeladoPlanificacin del Sistema
Las diferencias entre PERT y CPM son las siguientes listadas en la tabla 2.1.7:
PERT es un mtodo Probabilstico. CPM es un mtodo Determinstico.Considera que la variable de tiempo
es una variable desconocida de la
cual solo se tienen datos
estimativos.
Considera que los tiempos de las
actividades se conocen y se pueden
variar cambiando el nivel de recursos
utilizados.
El tiempo esperado de
finalizacin de un proyecto es la
suma de todos los tiempos
esperados de las actividades
sobre la ruta crtica.
A medida que el proyecto avanza, estos
estimados se utilizan para controlar y
monitorear el progreso. Si ocurre algn
retraso en el proyecto, se hacen
esfuerzos por lograr que el proyectoquede de nuevo dentro de los tiempos
programados cambiando la asignacin
de recursos.Suponiendo que las
distribuciones de los tiempos de
las actividades son
independientes, la varianza del
proyecto es la suma de lasvarianzas de las actividades en
la ruta crtica.
Considera que las actividades son
continuas e interdependientes,
siguen un orden cronolgico y ofrece
parmetros del momento oportuno
del inicio de la actividad.
Considera tres estimativos de
tiempos:
o el ms probable
o optimista,
o pesimista.
Considera tiempos normales y
acelerados de una determinada
actividad, segn la cantidad de
recursos aplicados en la misma.
Tabla 2.1.7 diferencias entre PERT y CPM
Mtodo CPM
Ingeniera en Sistemas Computacionales
38
http://www.monografias.com/trabajos11/basda/basda.shtmlhttp://www.monografias.com/trabajos11/basda/basda.shtml7/31/2019 39861943 Unidad II Planif y Modelado
23/80
Planificacin y ModeladoPlanificacin del Sistema
Los siguientes son los pasos en el planeamiento del proyecto con CPM y son
descritos brevemente a continuacin:
1. Especificar las actividades individuales.
2. Determinar la secuencia de esas actividades.
3. Dibujar el diagrama de la red.
4. Estimar el tiempo de terminacin para cada actividad.
5. Identificar la trayectoria crtica (la trayectoria ms larga a travs de la
red)
6. Actualizar el diagrama del CPM
1. Especificar las actividades individuales.
Se hace un listado de todas las actividades del proyecto. Una actividad se
considera como una serie de operaciones realizadas por una persona o grupo
de personas en forma continua, sin interrupciones, con tiempos determinables
de inicio y trmino.
2. Determinar la secuencia de esas actividades.
Algunas actividades son dependientes en la terminacin de otras. Un listado de
los precursores inmediatos de cada actividad es til para construir el diagrama
de la red del CPM. Existen dos procedimientos para conocer la secuencia de las
actividades: Por medio de los precursores y por secuencias.
Por medio de los precursores se les preguntar a los responsables de los
procesos cuales actividades deben quedar terminadas para ejecutar cada una
de las que aparecen en la lista.
En el segundo procedimiento se preguntara a los responsables de la ejecucin,
cuales actividades deben hacerse al terminar cada una de las que aparecen en
la lista.
Ingeniera en Sistemas Computacionales
39
http://www.monografias.com/trabajos7/plane/plane.shtmlhttp://www.monografias.com/trabajos7/plane/plane.shtml7/31/2019 39861943 Unidad II Planif y Modelado
24/80
Planificacin y ModeladoPlanificacin del Sistema
3. Dibujar el diagrama de red.
Se llama red a la representacin grfica de las actividades que muestran sus
eventos, secuencias, interrelaciones y el camino critico. Una vez que se hayan
definido las actividades y su secuencia, el diagrama del CPM puede ser
dibujado. El CPM fue desarrollado originalmente como actividad en red del
nodo (AON), pero algunos planificadores del proyecto prefieren especificar las
actividades en los arcos como se ilustra en la figura 2.1.8. No interesa la forma
de las flechas, ya que se dibujarn de acuerdo con las necesidades y
comodidad de presentacin de la red. Pueden ser horizontales, verticales,
ascendentes, descendentes curvas, rectas, quebradas, etc.
Se llama evento al momento de iniciacin o terminacin de una actividad. Se
determina en un tiempo variable entre el ms temprano y el ms tardo
posible, de iniciacin o de terminacin. A los eventos se les conoce tambin
con los nombres de nodos
Fig. 2.1.8 diagrama de red
4. Estimar el tiempo de terminacin para cada actividad.
El tiempo requerido para terminar cada actividad se puede estimar usando
experiencia previa o las estimaciones de personas bien informadas. El CPM es
un modelo determinista que no considera la variacin en el tiempo de la
terminacin, tan solamente un nmero se utiliza para la estimacin del tiempo
de una actividad.
Ingeniera en Sistemas Computacionales
40
7/31/2019 39861943 Unidad II Planif y Modelado
25/80
Planificacin y ModeladoPlanificacin del Sistema
5. Identificar la trayectoria crtica (la trayectoria ms larga a travs de la
red).
No solamente se llama camino crtico al mtodo sino tambin a la serie de
actividades contadas desde la iniciacin del proyecto hasta su terminacin, queno tienen flexibilidad en su tiempo de ejecucin, por lo que cualquier retraso
que sufriera alguna de las actividades de la serie provocara un retraso en todo
el proyecto. Desde otro punto de vista, camino crtico es la trayectoria crtica
de mayor duracin a travs de la red. Debido a su impacto en el proyecto
entero, el anlisis de trayectoria crtica es un aspecto Importante del
planeamiento del proyecto.
La trayectoria crtica puede ser identificada determinando los cuatro
parmetros siguientes para cada actividad:
o ES, Inicio ms temprano.
o EF, Inicio ms tardo.
o LS, terminacin ms temprana.
o LF, terminacin ms tarda.
El tiempo real (TR) para una actividad es la cantidad estimada en tiempo
que requiere la actividad para ser completada y el tiempo disponible (TD) es
la cantidad disponible de tiempo en el cronograma para completar la actividad.
La holgura de tiempo (HT) o margen de tiempo para una actividad es la
diferencia entre el tiempo disponible y el tiempo real para una actividad:
HT = TD TR
Otra forma de ver la holgura de tiempo, es comparar el tiempo ms temprano
en el que una actividad puede comenzar con el tiempo ms tardo en el que
dicha actividad puede comenzar, sin retrasar el proyecto.
HT = EF ES
Ingeniera en Sistemas Computacionales
41
http://www.monografias.com/trabajos11/metods/metods.shtml#ANALIThttp://www.monografias.com/trabajos11/metods/metods.shtml#ANALIT7/31/2019 39861943 Unidad II Planif y Modelado
26/80
Planificacin y ModeladoPlanificacin del Sistema
La trayectoria crtica es la trayectoria a travs de la red del proyecto en la
cual ninguna de las actividades tienen holgura, es decir, la trayectoria para la
cual ES=LS y EF=LF para todas las actividades en la trayectoria.
6. Actualizar el diagrama del CPM
A medida que el proyecto progresa, los tiempos reales de la terminacin de las
tareas se conocern y el diagrama de red se tiene que actualizar para incluir la
nueva informacin. Una trayectoria crtica nueva puede emerger, y los cambios
estructurales se pueden realizar en la red si los requisitos del proyecto
cambian.
Mtodo PERT
En CPM se asume que la duracin de cada actividad es conocida con certeza.
Claramente, en muchas ocasiones este supuesto no es valido. PERT intenta
corregir este error suponiendo que la duracin de cada actividad es una
variable aleatoria. Para cada activad, se requiere estimar las siguientes
cantidades:
a = Tiempo Optimista. Duracin de la actividad bajo las condiciones ms
favorables.
b = Tiempo Pesimista. Duracin de la actividad bajo las condiciones ms
desfavorables.
m = Tiempo Normal. El valor ms probable de la duracin de la actividad.
La forma de la distribucin se muestra en la figura 2.1.7 . El tiempo ms
probable es el tiempo requerido para completar la actividad bajo condiciones
normales. Los tiempos optimistas y pesimistas proporcionan una medida de la
incertidumbre inherente en la actividad, incluyendo desperfectos en el equipo,
disponibilidad de mano de obra, retardo en los materiales y otros factores.
Ingeniera en Sistemas Computacionales
42
http://www.monografias.com/trabajos14/nuevmicro/nuevmicro.shtmlhttp://www.monografias.com/trabajos14/propiedadmateriales/propiedadmateriales.shtmlhttp://www.monografias.com/trabajos14/nuevmicro/nuevmicro.shtmlhttp://www.monografias.com/trabajos14/propiedadmateriales/propiedadmateriales.shtml7/31/2019 39861943 Unidad II Planif y Modelado
27/80
Planificacin y ModeladoPlanificacin del Sistema
Fig. 2.1.7 distribucin de los tiempos
Con la distribucin definida, la media (esperada) y la desviacin estndar,
respectivamente, del tiempo de la actividad para la actividad Z puede
calcularse por medio de las frmulas de aproximacin.
El tiempo esperado de finalizacin de un proyecto es la suma de todos los
tiempos esperados de las actividades sobre la ruta crtica. De modo similar,
suponiendo que las distribuciones de los tiempos de las actividades son
independientes, la varianza del proyecto es la suma de las varianzas de las
actividades en la ruta crtica.
Pasos en el proceso de planeamiento del PERT
1. Identificar las actividades y su interdependencia
2. Determinar la secuencia de actividades
3. Construir el diagrama de red
4. Tiempos estimados de actividades
5. Determinar la trayectoria crtica
6. Actualizar segn el progreso del proyecto
Ingeniera en Sistemas Computacionales
43
http://www.monografias.com/trabajos14/administ-procesos/administ-procesos.shtml#PROCEhttp://www.monografias.com/trabajos14/administ-procesos/administ-procesos.shtml#PROCE7/31/2019 39861943 Unidad II Planif y Modelado
28/80
Planificacin y ModeladoPlanificacin del Sistema
1. Identificar las actividades y su interdependencia
Las actividades son las tareas requeridas para terminar el proyecto. Las
precedencias son los acontecimientos que marcan el principio y fin de una o
ms actividades.
2. Determinar la secuencia de actividades
Este paso se puede combinar con el paso de la identificacin de la actividad
puesto que la secuencia de la actividad es evidente para algunas tareas. Otrastareas pueden requerir ms anlisis para determinar el orden exacto en la cual
deben ser realizadas
3. Construir el diagrama de red
Usando la informacin de la secuencia de actividades, un diagrama de la red se
puede dibujar demostrando la secuencia de actividades seriales y paralelas.
4. Tiempos estimados de actividades
Para cada activad, se requiere estimar las siguientes cantidades:
a = Tiempo o estimacin Optimista. El que representa el tiempo mnimo
posible sin importar el costo o cantidad de recursos materiales y humanos que
se requieran; es simplemente la posibilidad fsica de realizar la actividad en el
menor tiempo
b = Tiempo Pesimista. Es un tiempo excepcionalmente grande que pudiera
presentarse ocasionalmente como consecuencia de accidentes, falta de
suministros, retrasos involuntarios, causas no previstas, etc.
m = Tiempo Normal. El valor ms probable de la duracin de la actividad,
basado en la experiencia personal de un experto.
Ingeniera en Sistemas Computacionales
44
http://www.monografias.com/Fisica/index.shtmlhttp://www.monografias.com/trabajos12/higie/higie.shtml#tipohttp://www.monografias.com/Fisica/index.shtmlhttp://www.monografias.com/trabajos12/higie/higie.shtml#tipo7/31/2019 39861943 Unidad II Planif y Modelado
29/80
Planificacin y ModeladoPlanificacin del Sistema
Si Tij es la variable aleatoria asociada a la duracin de la actividad (i; j), PERT
asume que Tij sigue una distribucin Beta. Sin entrar en mayores detalles de
esta distribucin, se puede demostrar que el valor esperado y la varianza de la
variable aleatoria Tij quedan definidas por:
En PERT se asume adems que la duracin de las actividades es
independiente. Por lo tanto, el valor esperado y la varianza de una ruta pueden
ser estimadas segn:
= Duracin esperada de la ruta
= Variacin de la duracin de la ruta
5. Determinar la trayectoria crtica
La trayectoria crtica es determinada agregando los tiempos para las
actividades en cada secuencia y determinando la trayectoria mas larga del
proyecto.
La trayectoria crtica determina el tiempo total del calendario requerido para el
proyecto. Si las actividades fuera de la trayectoria ctrica aceleran o retrasaron
el tiempo (dentro de los lmites), entonces el tiempo total de proyecto no varia;
la cantidad del tiempo en que una actividad de la trayectoria crtica no altera la
duracin del proyecto se denomina holgura.
Si la trayectoria crtica del proyecto no resulta obvia, entonces puede ser
provechoso determinar las cuatro cantidades siguientes para cada actividad:
ES, Inicio ms temprano.
EF, Inicio ms tardo.
Ingeniera en Sistemas Computacionales
45
7/31/2019 39861943 Unidad II Planif y Modelado
30/80
Planificacin y ModeladoPlanificacin del Sistema
LS, terminacin ms temprana.
LF, terminacin ms tarda.
Se calculan estos tiempos usando el tiempo previsto para las actividades
relevantes. Los tiempos de inicio y terminacin ms tempranos de cadaactividad son determinados trabajando desde el inicio al final a travs de la red
y determinando el tiempo ms temprano en el cual una actividad puede
comenzar y acabar considerando las actividades del precursor.
Los tiempos de inicio y terminacin ms tardos son el tiempo ms tarde en
que una actividad puede comenzar o acabar sin variar el proyecto. El LS y el LF
son encontrados trabajando desde el final hacia atrs a travs de la red.
La diferencia entre la terminacin ms tarda y la terminacin ms temprana
da como resultado la holgura de una actividad. La trayectoria crtica entonces
es la trayectoria a travs de la red en la cual ningunas de las actividades
tienen holgura.
La variacin en el tiempo de la terminacin del proyecto puede ser calculada
sumando las variaciones en los tiempos de la terminacin de las actividades en
la trayectoria crtica. Dado esta variacin, una puede calcular la probabilidad
que el proyecto ser terminado por cierta fecha si se asume una distribucin
normal de la probabilidad para la trayectoria crtica.
Sea CP la variable aleatoria asociada a la duracin total de las actividades de la
ruta crtica determinadas mediante CPM. PERT asume que la ruta crtica
encontrada a travs de CPM contiene suficientes actividades para emplear el
Teorema Central del Lmite y concluir que CP se distribuye normalmente.
Puesto que la trayectoria crtica determina la fecha de la terminacin del
proyecto, el proyecto puede ser acelerado agregando los recursos requeridos
para disminuir el tiempo para las actividades en la trayectoria crtica.
Ingeniera en Sistemas Computacionales
46
7/31/2019 39861943 Unidad II Planif y Modelado
31/80
Planificacin y ModeladoPlanificacin del Sistema
6. Actualizar segn el progreso del proyecto
Mientras que el proyecto se desarrolla, los tiempos estimados se pueden
sustituir por tiempos reales. En casos donde haya retrasos, los recursos
adicionales pueden necesitarse de manera permanentemente.
2.2 Evaluacin del costo beneficio
Hoy en da el Software es el elemento ms caro en la mayora de los sistemas
de informacin, por lo que la estimacin debe realizarse cuidadosamente ya
que un gran error en la estimacin del costo puede ser lo que marque la
diferencia entre beneficios y prdidas tanto para clientes y la empresa
desarrolladora de software.
De acuerdo con Pfleeger [PFL02], dentro de la planificacin es crucial
comprender cul ser el costo aproximado de ste. Unas de las razones son
porque:
o Los costos excedidos pueden causar que los clientes cancelen el
proyecto.
o Los costos subestimados lo que puede no compensar el tiempo invertido
por el equipo del proyecto.
No se debe olvidar que la estimacin es una actividad compleja que se vale de
modelos y de tcnicas y estos a su vez se basan en mtricas, por lo que es
necesario profundizar sobre stas.
2.2.1 Mtricas de Software
Ingeniera en Sistemas Computacionales
47
7/31/2019 39861943 Unidad II Planif y Modelado
32/80
Planificacin y ModeladoPlanificacin del Sistema
Dentro de la Ingeniera de Software existe controversia con las mtricas, como
lo son las siguientes:
o Algunos desarrolladores piensan que el recolectar mtricas es difcil y
consume mucho tiempo.o Otros que es difcil ponerse de acuerdo de lo que se tiene que medir, las
mtricas que se utilizarn para hacerlo y posteriormente como utilizar
los resultados obtenidos.
Pressman [PRE02], comenta que an cuando muchos desarrolladores de
software se resisten al uso de las mtricas como una gua en su trabajo, no
dejan de ser muy importante su estudio, ya que ayudan a entender y mejorar
el proceso de desarrollo de un producto. Sin ellas no se tendra la certeza de
una mejora tanto en el desarrollo del producto como en la calidad del producto
en si.
De acuerdo a Lord Kelvin Cuando se puede medir lo que se esta diciendo y
expresarlo con nmeros, significa que tenemos conocimientos sobre ese tema, cuando esto
no ocurre significa que nuestro conocimiento es precario y deficiente.
La medicin es muy comn en el mundo de la ingeniera en general. An as,con respecto a la ingeniera de software no lo es tanto por las cuestiones
descritas anteriormente. Sin embargo hay razones que justifican la medicin
del software:
o Nos indica la calidad del producto referencia
o Nos ayudan a evaluar
o la productividad de la gente que desarrolla el producto
o los beneficios de utilizar nuevos mtodos y herramientas de
ingeniera de software justificando el uso de stos.
o Esta evaluacin permite una mejora continua al proceso de
desarrollo de software.
Ingeniera en Sistemas Computacionales
48
7/31/2019 39861943 Unidad II Planif y Modelado
33/80
Planificacin y ModeladoPlanificacin del Sistema
o Nos ayuda a establecer una lnea base para la estimacin
Qu es una medida:
Cuando se recopila un solo aspecto de los datos se est hablando de medidas.
Ejemplo: nmero de lneas de cdigo o nmero de errores.
La medicin es el acto de determinar una medida. Y es el resultado de la
recopilacin de uno o varios aspectos de los datos. Ejemplo: se investiga un
nmero de revisiones de mdulos para recuperar las medidas de errores
encontrados durante cada revisin.
Qu es una mtrica
Es una medida cuantitativa del grado en que un sistema, componente o
proceso posee un atributo dado (IEEE Standard Glossary of Software
Engineering, 1993).
Ingeniera en Sistemas Computacionales
49
7/31/2019 39861943 Unidad II Planif y Modelado
34/80
Planificacin y ModeladoPlanificacin del Sistema
Describe en cierta forma las medidas individuales sobre algn aspecto.
Ejemplo: el nmero de errores encontrados por revisin o por persona.
Fiabilidad, facilidad de uso, facilidad de cambio, etc.
Un ingeniero de software recopila medidas y desarrolla mtricas para obtener
indicadores. Un indicador: es una mtrica o una combinacin de mtricas que
proporcionan un visin profunda del proceso y proyecto del software o del
producto en si mismo.
Por medio de los indicadores, el gestor de proyecto o ingeniero de software
pueden ajustar el producto, proyecto o proceso para mejorar las cosas. Hay
dos tipos de indicadores o mtricas: Indicadores deproceso e indicadores del
proyecto. Muchas de las mtricas se pueden utilizar tanto en el dominio del
proceso cono en el del proyecto [PRE04].
1. Indicadores deproceso.
o brindan una visin profunda sobre la eficacia de un proceso ya
existente.
o permiten evaluar lo que est y no funcionando.
o Su propsito es mejorar los procesos de software a largo plazo y
conducir a estrategias que permitan mejorar la calidad del proceso.
2. indicadores del proyecto.
Son utilizadas para supervisar el progreso durante el desarrollo de software
y controlar la calidad del producto, adems se utilizan para realizar las
estimaciones de tiempo y esfuerzo. Permiten al gestor de proyecto:
Ingeniera en Sistemas Computacionales
50
7/31/2019 39861943 Unidad II Planif y Modelado
35/80
Planificacin y ModeladoPlanificacin del Sistema
o Evaluar el estado del proyecto
o Seguir las pistas de los riesgos potenciales
o Detectar las reas de problemas para evitar reas crticas
o Ajustar el flujo y las tareas del trabajo
o Evaluar la habilidad del equipo del proyecto para controlar la calidad
del producto de software.
Las mediciones del mundo fsico pueden englobarse en dos categoras, directas
e indirectas:
o medidas directas como lo es el largo de un tornillo
o y medidas indirectas como lo es la calidad de un tornillo.
Las mtricas del software pueden ser catalogadas en forma anloga, directas e
indirectas y se aplican al proceso, proyecto y producto de software.
Medidas directas:
o del proceso, donde se miden los datos cuantitativos del software, como
costo y esfuerzo aplicado, nmero de ocurrencias de un evento .
o del producto, donde se miden las caractersticas del software y se
dividen a su vez en dinmicas y estticas:
o dinmicas: aquellas que se relacionan directamente con los
atributos de calidad del software y que se miden al momento
en que un programa est en ejecucin. Un ejemplo es obtener
el tiempo de ejecucin, defectos, etc.
o estticas: los resultados de estas mediciones se obtienen departes que representen al sistema como lo es el diseo,
cdigo, documentos. Como lo es el medir las lneas de cdigo
producidas.
Ingeniera en Sistemas Computacionales
51
7/31/2019 39861943 Unidad II Planif y Modelado
36/80
Planificacin y ModeladoPlanificacin del Sistema
Ejemplo: mtricas orientadas al tamao. Que son medidas directas del
software y el proceso de software. Para estimar el esfuerzo.
Medidas indirectas:
o calidad, funcionalidad, eficiencia, facilidad de mantenimiento, etc.
Ejemplo: mtricas orientadas a la funcin. Son medidas indirectas del proceso
de software.
Mtricas orientadas al tamao
Las mtricas del software orientadas al tamao son medidas directas del
proceso de software, provienen de la normalizacin de las medidas de calidady/o productividad considerando el tamao de software que se ha producido
[PRE02]. La mtrica orientada al tamao ms utilizada es LOC (Lines Of Code)
o SLOC (Source Lines Of Code) en espaol lneas de cdigo LDC. Calcula el
tamao de un producto en LDC y con esto el grado de errores y productividad
entre otros.
Teniendo la tabla 2.2.1 como ejemplo podran calcularse los valores a
continuacin
Nombre
del
proyecto
N de
Personas
Costo $ N de
errores
N de pginas
de
documentacin
Esfuerzo
empleado
(das/hombre)
Lneas de
cdigo
(LDC)
Proy1 15 20Mil 520 320 1200 3220
Proy2 10 17Mil 380 450 1000 2800tabla 2.2.1
Productividad =LDC / persona mes
Costo = $ / LDC
Grado de errores = N de errores / LDC
Grado de documentacin = N de pginas documentadas / LDC
Ventajas:
Ingeniera en Sistemas Computacionales
52
7/31/2019 39861943 Unidad II Planif y Modelado
37/80
Planificacin y ModeladoPlanificacin del Sistema
o Que son fciles de calcular en cualquier proyecto
o Existen varias herramientas de estimacin basadas en las lneas de
cdigo
Desventajas:
o la falta de una definicin universal de lnea de cdigo
o las lneas de cdigo dependen de los lenguajes de programacin y por lo
tanto perjudica a los programas ms cortos pero bien diseados.
o El estilo de programacin depender de cada persona. Comparar la
productividad utilizando lenguajes diferentes de programacin puede
llevar a conclusiones errneas respecto a la productividad de los
programadores.
o El decidir que lneas de cdigo se contabilizaran ya sean nuevas, lneas
modificadas, reutilizadas ms definiciones de datos y comentarios.
o dificultad de estimar en fases tempranas del desarrollo la cantidad de
lneas que tendr una aplicacin.
Mtricas orientadas a la funcin
Es un mtodo para cuantificar el tamao y la complejidad de un sistema
software en trminos de las funciones que el usuario desarrolla o desarrollar.
Utilizan una media de la funcionalidad de software como valor de
normalizacin. Puesto que la funcionalidad no puede medirse directamente se
debe obtenerla indirectamente a travs de otras medidas directas.
Se entiende por funciones a las entradas, salidas, archivos, etc.
La primera propuesta de los puntos de funcin fue realizada por Albrecht,
mtrica que hasta hoy es muy utilizada. De sta se derivan otras como los
puntos de caracterstica y los puntos de funcin para estimacin temprana.
Ingeniera en Sistemas Computacionales
53
7/31/2019 39861943 Unidad II Planif y Modelado
38/80
Planificacin y ModeladoPlanificacin del Sistema
Para calcular los puntos de funcin es necesario conocerlo siguiente y se
muestra en la tabla 2.2.2:
1. Nmero de entradas de usuario: aquellas que permiten aadir, borrar o
cambiar datos de un programa. (flujos de datos de entrada en el
diagrama de contexto), ejemplos: Pantallas, formularios, cuadros de
dialogo, controles o mensajes.
2. Nmero de salidas de usuario: aquellas que proporciona informacin al
usuario. Ejemplos: Pantallas, informes, grficos o mensajes.
3. Nmero de consultas de usuario. Es una entrada interactiva que es el
resultado de una respuesta en forma de salida interactiva, en otras
palabras, es una entrada que produce una respuesta (consulta).
4. Nmero de archivos lgicos internos, se cuenta cada archivo de forma
individual. Son los principales grupos lgicos de datos de usuarios finales
o informacin de control que es manejada absolutamente por el
programa. Un archivo lgico podra constar de un nico archivo plano o
de una sola tabla en una base de datos relacional.
5. Nmero de interfaces externos con otros sistemas Archivos controlados
por otros programas, con los que el programa va a interactuar. Esto
incluye cada uno de los principales grupos de datos lgicos o
informacin de control que entre o salga en el programa.
Parmetros de medicin Cuenta
simple
Cuenta
media
Cuenta
compleja
total
N entradas
N salidas
N peticiones
N archivos
N interfaces
* 3 + * 4 + *6
Cuenta
Ingeniera en Sistemas Computacionales
54
7/31/2019 39861943 Unidad II Planif y Modelado
39/80
Planificacin y ModeladoPlanificacin del Sistema
total
Tabla 2.2.2 tabla de parmetros de medicin
PF (Puntos de funcin) = Cuenta total * [0,65+0,01 fi]
Fi son unos valores de ajuste de la complejidad, en total son 14 y se
consiguen evaluando las siguientes 14 preguntas de 0 a 5 donde:
0: No tiene influencia
1: Tiene influencia muy baja
2: Influencia moderada
3: Influencia media
4: Influencia significativa
5: Son esenciales
1. Requiere el sistema copias de seguridad y de recuperacin fiables?
2. Se necesita comunicacin datos?
3. Existen funciones de procesamiento distribuido?
4. Es crtico el rendimiento?
5. Se ejecutar el sistema en un entorno operativo existente y altamente
utilizado?
6. Se requiere entrada de datos interactiva?
7. La entrada de datos interactiva debe hacerse desde mltiples
pantallas?
8. Se actualizan los datos maestros de forma continua?
9. Son complejas las entradas, salidas, los archivos o las peticiones?
10.Es complejo el procesamiento interno?
11.Se ha diseado el cdigo para ser reutilizable?
12.Estn incluidas en el proyecto la conversin e instalacin?
13.Se ha diseado el software para instalarlo en diferentes empresas?
14.Se ha diseado el software para facilitar los cambios y ser fcilmente
usado por el usuario?
Ingeniera en Sistemas Computacionales
55
7/31/2019 39861943 Unidad II Planif y Modelado
40/80
Planificacin y ModeladoPlanificacin del Sistema
Cuando se han considerado los 14 factores de influencia, y se les han asignado
puntuaciones individualmente, la suma de estos factores es convertida en un
ajuste de la complejidad final siguiendo el procedimiento siguiente:
1. Multiplicar la suma de los factores por 0,01, para convertir la suma en un
valor decimal.
2. Sumar la constante 0,65 al valor decimal para crear un factor multiplicador
de la complejidad.
3. Multiplicar el valor no ajustado del total de los puntos de funcin por el
multiplicador de la complejidad, para conseguir un valor de puntos de
funcin ajustado.
Productividad= PF/persona mes
Costo= pesos/PF
Ventajas:
o son independientes del lenguaje de programacin y desde este punto de
vista lo hace ms atractivo como enfoque de estimacin.
o pueden ser estimados a partir de la especificacin de requisitos o
especificaciones de diseo, lo que permite una estimacin temprana.
o Como se basan en una visin externa del usuario, los usuarios no
tcnicos entienden mejor lo que los puntos de funcin estn midiendo.
Desventaja: Como aspecto negativo tienen el que se basan en unas
valoraciones subjetivas y adems que el PF no tienen un significado fsico
directo. (e)
Puntos de Caracterstica
Debido a que el anlisis por Puntos de Funcin fue diseado para software de
gestin y no es fcil de generalizar a aplicaciones cientficas, de tiempo real y
otras, Caper Jones propuso ampliaciones al mtodo que denomin Puntos de
Ingeniera en Sistemas Computacionales
56
7/31/2019 39861943 Unidad II Planif y Modelado
41/80
Planificacin y ModeladoPlanificacin del Sistema
Caracterstica, que da cabida a aplicaciones cuya complejidad algortmica es
alta.
Este mtodo considera los mismos elementos que considera Albrecht en su
mtodo de anlisis por puntos de funcin, slo que aade la variable nmero
de algoritmos y elimina los niveles de complejidad [PRE02].
Puntos de objeto
Los puntos de objeto son una medida alternativa relacionada con la
funcionalidad cuando se utilizan lenguajes de cuarta generacin o similares
para el desarrollo. Los puntos de objeto noson clases de objetos [SOM00].
El nmero de puntos de objeto en un programa es una estimacin ponderada
de:
o El nmero de pantallas que son visualizadas por separado
o El nmero de informes que se producen por el sistema
o El nmero de mdulos lenguajes de tercera generacin que deben
desarrollarse para complementar el cdigo 4G.
Mtricas para la calidad del software
Cualquier proyecto de ingeniera del software tiene como objetivo principal
obtener sistemas y productos de alta calidad [PRE02]. La calidad es difcil
medirla directamente, no obstante hay indicadores que nos pueden dar una
idea sobre la misma. Gilb basa estos indicadores en los siguientes aspectos:
o Correccin.- Es el grado en el que el software lleva a cabo su funcin.
Se mide en defectos por KLDC (miles de lneas de cdigo),
entendindose por defecto cualquier falta de concordancia con los
requisitos.
o Facilidad de mantenimiento.- Se mide por la facilidad de:
Ingeniera en Sistemas Computacionales
57
7/31/2019 39861943 Unidad II Planif y Modelado
42/80
Planificacin y ModeladoPlanificacin del Sistema
o corregir defectos encontrados,
o adaptar ese programa a nuevos entornos
o mejorar el programa si el cliente desea cambios.
La facilidad de mantenimiento se mide indirectamente por medio de una
mtrica orientada al tiempo: tiempo medio del cambio (TMC), es decir,
por el tiempo que se tarda en analizar la peticin del cambio, disear la
modificacin, implementarla, probarla y distribuir la notificacin del
cambio a los usuarios.
o Integridad.- Mide la habilidad de un sistema para resistir ataques
contra su seguridad. El proteger los datos, programas y
documentacin debe ser una prioridad. Para medirla se consideran
dos atributos adicionales:
o Amenaza, que es la probabilidad estimada o deducida de que se
produzca un ataque de un tipo determinado.
o Seguridad: Probabilidad estimada o deducida de el nuestro
sistema pueda repeler dichos ataques.
La Integridad del sistema se define como:
integridad= (1- amenaza(1-seguridad))
o Facilidad de uso.- Entendindose como tal lo amigable que resulta
al usuario el sistema. Es un intento de cuantificar los amigable que
es el sistema. Se puede deducir a partir de cuatro caractersticas:
1- Habilidad intelectual o fsica requerida para aprender el
sistema.2- El tiempo requerido para llegar a ser moderadamente eficiente
en el uso del sistema.
3- El aumento de productividad de alguien que usa el sistema.
4- Valoracin subjetiva de la disposicin de los usuarios hacia el
sistema.
Ingeniera en Sistemas Computacionales
58
7/31/2019 39861943 Unidad II Planif y Modelado
43/80
Planificacin y ModeladoPlanificacin del Sistema
Se concluye con lo que respecta a las mtricas, que definen que es lo que se
va a predecir y los mtodos o tcnicas definen como una mtrica es predicha.
Se recomienda hacer la estimacin utilizando ms de un modelo o tcnica para
que una respalde o refute a la otra.
Con el conocimiento sobre las mtricas del software se puede proseguir con el
tema de la estimacin.
2.2.2 Estimacin del proyecto de software
De acuerdo con Pressman [PRE02], con frecuencia una estimacin ms que
una ciencia es un arte pero no por ello debe descuidarse, sino ms bien se
debe realizarla de manera estricta. Cualquier estimacin lleva consigo un
riesgo o incertidumbre vindose esta afecta por: (observaciones de la
estimacin)
o Complejidad del proyecto: es una medida relativa que se ve afectada
por la familiaridad que se tenga con esfuerzos anteriores.
o Tamao del proyecto: afecta a la precisin y eficiencia de las
estimaciones. Cuanto mayor sea el proyecto, mayor ser el riesgo de la
estimacin.
o Disponibilidad de informacin histrica: Si no se dispone de informacin
de proyectos anteriores similares la incertidumbre ser mayor.
El riesgo o incertidumbre sobre las estimaciones afectan al costo, a los
recursos necesarios y a la planificacin temporal.
Suponiendo que se subestima el esfuerzo, un costo superior al previsto puede
hacer que los beneficios obtenidos sean nulos o negativos. Sobrestimar el
esfuerzo puede tambin afectar a la competitividad de la compaa as como
provocar perdida de beneficios, por ejemplo podra contratarse personal en
exceso para la realizacin del proyecto.
Lo que la estimacin busca determinar es:
Ingeniera en Sistemas Computacionales
59
7/31/2019 39861943 Unidad II Planif y Modelado
44/80
Planificacin y ModeladoPlanificacin del Sistema
Una buena estimacin de costo al comienzo del proyecto nos ayuda a conocer
cuantos desarrolladores se requerirn y as preparar el equipo apropiado para
que est disponible cuando se lo necesite [SOM00].
Los recursos.
Una de las tareas importantes de la planificacin del desarrollo de softwarees la estimacin de los recursos requeridos para acometer el esfuerzo.
De acuerdo con Pressman [PRE02], se considera una pirmide de recursos
ilustrada en la figura 2.2.2.1:
1. En la base se encuentran los recursos tcnicos, hardware y software,
que proporcionan la infraestructura de soporte de desarrollo de
software.
2. En el segundo nivel se encuentran los componentes reutilizables,
bloques de software que servirn para el nuevo desarrollo.
3. Y en la punta los recursos primarios, los recursos humanos.
Fig. 2.2.2.1 recursos del proyecto
Ingeniera en Sistemas Computacionales
60
7/31/2019 39861943 Unidad II Planif y Modelado
45/80
Planificacin y ModeladoPlanificacin del Sistema
De cada recurso se debe especificar las siguientes caractersticas, que son las
que se toman en cuanta a la hora de la estimacin.
o Descripcin del recurso
o Informes de disponibilidad
o Fecha en la que se requiere el recurso, inicio y fin
o Tiempo durante el que ser aplicado el recurso
Las dos ltimas caractersticas, se denominan ventana temporal que
representa la disponibilidad de un recurso para un proyecto especfico, y debe
ser fijado lo antes posible para una buena planificacin de recursos.
Recursos Humanos.- La Cantidad de personas requeridas para el desarrollo de
un proyecto de software slo puede ser determinado despus de hacer una
estimacin del esfuerzo de desarrollo (por ejemplo personas mes o personas
aos), y seleccionar la posicin dentro de la organizacin y la especialidad que
desempeara cada profesional.
Recursos o componentes de software reutilizables.- Cualquier estudio sobre
recursos de software estara incompleto sin estudiar la reutilizacin, esto es la
creacin y la reutilizacin de bloques de construccin de Software. Tales
bloques se deben establecer en catlogos para una consulta ms fcil,
estandarizarse para una fcil aplicacin y tambin validarse para una fcil
integracin.
Bennatan sugiere cuatro categoras de recursos de software que se deberan
tener en cuenta a medida que se avanza con la planificacin:
o Componentes ya desarrollados.
o Componentes ya experimentados.
o Componentes con experiencia Parcial.
o Componentes nuevos.
Ingeniera en Sistemas Computacionales
61
7/31/2019 39861943 Unidad II Planif y Modelado
46/80
Planificacin y ModeladoPlanificacin del Sistema
Recursos de entorno.- El entorno es donde se apoya el proyecto de Software,
llamado a menudo entorno de Ingeniera de Software, incorpora Hardware y
Software.
El Hardware proporciona una plataforma con las herramientas (Software)
requeridas para producir los productos que son el resultado de la buena
practica de la Ingeniera del Software, un planificador de proyectos debe
determinar la ventana temporal requerida para el Hardware y el Software, y
verificar que estos recursos estn disponibles. Muchas veces el desarrollo de
las pruebas de validacin de un proyecto de software para la composicin
automatizada puede necesitar un compositor de fotografas en algn punto
durante el desarrollo. Cada elemento de hardware debe ser especificado por el
planificador del proyecto de software.
2.2.2.1 Tcnicas para la estimacin del software
Para realizar estimaciones seguras de costos y esfuerzos tienen varias
opciones posibles:
1. Dejar la estimacin para ms adelante (obviamente se puede realizar
una estimacin 100% fiable despus de haber terminado el proyecto).
2. Basar las estimaciones en proyectos similares ya terminados.
3. Utilizar tcnicas de estimacin relativamente sencilla para generar las
estimaciones de costos y esfuerzo del proyecto.
4. Utilizar un modelo emprico para l clculo de costos y esfuerzos del
Software.
Desdichadamente la primera opcin, aunque atractiva no es prctica. La
Segunda opcin puede funcionar razonablemente bien si el proyecto actual es
bastante similar a los esfuerzos pasados y si otras influencias del proyecto son
similares. Las opciones restantes son mtodos viables para la estimacin del
proyecto de software. Desde el punto de vista ideal, se deben aplicar
Ingeniera en Sistemas Computacionales
62
7/31/2019 39861943 Unidad II Planif y Modelado
47/80
Planificacin y ModeladoPlanificacin del Sistema
conjuntamente las tcnicas indicadas usando cada una de ellas como
comprobacin de las otras.
Tcnicas de descomposicin.
Antes de hacer una estimacin, el planificador del proyecto debe comprender
el mbito del software a construir y generar una estimacin de su tamao.
La estimacin de un proyecto de software se predice basndose en lo
siguiente:
1. Por el grado en el que el planificador ha estimado adecuadamente el
tamao del proyecto.
2. Por la habilidad en traducir el tamao en:
a. Esfuerzo humano
b. Tiempo y
c. Dinero
3. Por el grado en el que el plan del proyecto refleja las habilidades del
equipo.
4. Por la estabilidad de los requerimientos y del entorno de desarrollo.
La estimacin del tamao es el reto del planificador, ya que en el contexto de
la planificacin de proyectos, el tamao se refiere a una produccin
cuantificable del proyecto de software. Se puede realizar de forma directa
utilizando LDC o de manera indirecta utilizando PF. As mismo se puede basar
en el problema o en el proceso.
Estimacin basada en el problema.- los datos de LDC y PF se utilizan de dos
formas: 1) como una variable de estimacin que se utiliza para cada elemento
del software y 2) como mtricas de lnea de base recopiladas de proyectos
anteriores y utilizadas junto con variables de estimacin para desarrollar
proyecciones de costo y esfuerzo.
Ingeniera en Sistemas Computacionales
63
7/31/2019 39861943 Unidad II Planif y Modelado
48/80
Planificacin y ModeladoPlanificacin del Sistema
Estimacin basada en el proceso.- Es una de las tcnicas ms comunes para
estimar un proyecto. Lo que se hace es descomponer el proceso en un
conjunto relativamente pequeo de actividades y en el esfuerzo requerido para
llevar a cabo cada actividad. Al igual que las tcnicas basadas en problemas, la
estimacin basada en el proceso comienza en una delineacin de las funciones
del software obtenidas a partir del mbito del proyecto. Se mezclan las
funciones del problema y las actividades del proceso. Como ultimo paso se
calculan los costos y el esfuerzo de cada funcin y la actividad del proceso de
software.
Otras tcnicas de estimacin.
Juicio Experto
Es la tcnica ms utilizada para realizar estimaciones de costos y tiempos. Son
tcnicas informales basadas en la experiencia de los gestores de proyecto o de
otras personas que hayan desarrollado aplicaciones similares.
De acuerdo con Sommerville [SOM00] las ventajas estn en que es una tcnica
estimacin econmica y puede ser precisa si los expertos tienen una
experiencia directa con sistemas similares.
La desventaja es que puede ser inexacto si no existen tales expertos.
Ingeniera en Sistemas Computacionales
64
7/31/2019 39861943 Unidad II Planif y Modelado
49/80
Planificacin y ModeladoPlanificacin del Sistema
Estimacin por analoga
Tambin se hace uso de analogas, al tener un sistema parecido entonces
pueden basar la estimacin en la similitud. Si el proyecto actual es bastante
similar a los esfuerzos de uno anterior y si otras influencias del proyecto son
similares, entonces el costo y esfuerzo para producirlo debera ser similar
[PFL02].
De acuerdo a [SOM00] la ventaja de esta tcnica est en que es precisa si est
disponible la informacin del proyecto con el cul se va a comparar.
La desventaja es que es imposible de comparar si el proyecto ha sido
abordado. Trae consigo costos de mantenimiento de la base de datos.
De acuerdo con Pfleeger [PFL02], para hacer una estimacin ms formal, se les
pide a varios expertos que hagan tres predicciones:
Pesimista (EP)
Optimista (EO)
La conjetura ms probable (EMP)
Asignndole una probabilidad a cada una, se obtiene la estimacin mediante:
E=EO *Po + EMP*Pmp + EP*Pp
Donde Po es la probabilidad asignada a la estimacin optimista, Pmp la
asignada a la ms probable y Pp la asignada a la pesimista.
Ley de Parkinson
Los costos del proyecto estn en funcin de los recursos disponibles, utilizando
todo el tiempo permitido [SOM00].
Ventaja: No se sobrepasa el presupuesto.
Desventaja: El sistema normalmente no se termina.
Ingeniera en Sistemas Computacionales
65
7/31/2019 39861943 Unidad II Planif y Modelado
50/80
Planificacin y ModeladoPlanificacin del Sistema
Pricing to win
El costo del proyecto est en funcin de lo que el cliente est dispuesto a
pagar [SOM00].
Ventaja: La empresa desarrolladora consigue el contrato
Desventaja: La probabilidad de que el cliente obtenga el sistema que quiere es
mnima, y los costos no reflejan realmente el trabajo requerido.
Esta es algunas veces la nica tcnica aplicable, aunque es poco profesional.
La estimacin completa puede estimarse mediante dos tipos de anlisis
[SOM00]:
o Top-down (descendente): Comienza a nivel de sistema y evala la
totalidad de funcionalidades y cmo stas se subdividen en subsistemas
o Bottom-up (ascendente): Comienza a nivel de componentes y estima el
esfuerzo requerido para cada componente. Dichos esfuerzos se aaden
a la estimacin final
Estimacin descendente
o Se puede usar sin conocer la arquitectura ni los componentes que
formarn parte del sistema.
o Tiene en cuenta costos tales como integracin, gestin de
configuraciones y documentacin.
o Puede sub-estimar costos relacionados con la resolucin de problemas
tcnicos de bajo nivel difciles de resolver.
Estimacin ascendente
o Se puede usar cuando la arquitectura del sistema es conocida y los
componentes han sido identificados.
o Proporciona estimaciones bastante precisas si el sistema se ha diseado
con detalle.
Ingeniera en Sistemas Computacionales
66
7/31/2019 39861943 Unidad II Planif y Modelado
51/80
Planificacin y ModeladoPlanificacin del Sistema
o Puede subestimar costos a nivel de sistema, tales como integracin y
documentacin.
An cuando en la prctica, la mayora de las estimaciones se basan en el juicio
experto y en la informacin histrica, es importante conocer algunos modelos y
tcnicas de estimacin que de manera conjuntan con el uso de mtricas
devuelven una estimacin. De acuerdo con Sommerville [SOM00], la
estimacin se debe basa en varias tcnicas que devuelvan datos aproximados.
2.2.2.2 Modelos de estimacin
Modelos algortmicos
Son modelos que expresan la relacin entre el esfuerzo y los factores que lo
influencian. Utilizan ecuaciones donde el esfuerzo es la variable dependiente y
varios factores como la experiencia, tamao (que es el de mayor influencia) y
tipo de sistema, son las variables independientes.
Estos modelos suelen basarse en el tamao del software y tienen un
componente exponencial (los costos no crecen normalmente de forma lineal
con el tamao del proyecto).
Esfuerzo = A x TamaoB x M
Uno de los problemas con este tipo de modelo es que el tamao es una
variable clave, y al momento de hacer la estimacin la informacin sobre el
tamao es incierta [PFL02].
Modelos empricos
Los Modelos empricos se dividen en:
o paramtricos. Los cuales tiene una formula funcional explcita,
relacionando una variable dependiente con una o ms variables
Ingeniera en Sistemas Computacionales
67
7/31/2019 39861943 Unidad II Planif y Modelado
52/80
Planificacin y ModeladoPlanificacin del Sistema
o no paramtricos. no tiene una formula funcional explcita, por ejemplo,
un modelo desarrollado usando la tcnica de aprendizaje mquina como
una red neuronal.
Los modelos de estimacin ms comunes son los Modelos paramtricos
empricos de estimacin:
o Utilizan frmulas derivadas empricamente para predecir el esfuerzo
como una funcin de LDC o PF.
o Utilizan datos empricos obtenidos de una muestra de proyectos:
o Son difciles de usar para todas las clases de software y todos los
entornos de desarrollo
o Se deben calibrar para las condiciones especficas de una
organizacin
La siguiente es la frmula para obtener la estimacin del esfuerzo en personas-
mes.
El Modelo COCOMO.
De estos modelos lo ms conocidos son los COCOMO (Constructive cost
model). El modelo de COCOMO est definidos para tres tipos de proyectos de
software [SOM00]:
Simple: relativamente sencillos y pequeos
Moderado: intermedios en cuanto al tamao y complejidad
Embebido (empotrado):proyectos que deben ser desarrollados en unconjunto de hardware, software y restricciones operativas muy
restringidas.
Ingeniera en Sistemas Computacionales
68
E = A + B X (ev) c
DondeA y B: son constantes obtenidas empricamenteE: esfuerzo en meses/personaev: variable de estimacin (LDC o PF)
7/31/2019 39861943 Unidad II Planif y Modelado
53/80
Planificacin y ModeladoPlanificacin del Sistema
El modelo constructivo de costos de Boehm es una jerarqua de modelos de
estimacin constituida por los siguientes:
Modelo I. El Modelo COCOMO bsico utilizaba las lneas de cdigo como factor
clave. Calcula el esfuerzo y el costo del desarrollo de Software en funcin del
tamao del programa, expresado en lneas de cdigo (LDC) estimadas.
E = ab LDC bb = personas / mes
C= cb E db = meses
En la tabla se muestran los valores para cada tipo de proyecto que toma cada
constante de la frmula del esfuerzo.
Proyecto ab Bb cb dbSimple 2,4 1,05 2,5 0,38Moderado 3,0 1,12 2,5 0,35Embebido 3,6 1,20 2,5 0,32
Tabla 2.2.2.2 valores para frmula del esfuerzo.
Modelo II.Como es imposible conocer al inicio del ciclo de desarrollo las lneas
de cdigo el COCOMO II refleja tres niveles principales de cualquier proyecto.
los siguientes niveles son de acuerdo a [SOM00] y [PFL02].
Nivel inicial de prototipado: poco se conoce sobre el tamao del producto final,
entonces se estima la dimensin sobre la base de lo que sus creadores
denominan puntos de objeto y una frmula simple para el clculo del esfuerzo.
En otras palabras, captura las dimensiones en trminos de generadores de
esfuerzo, tales como el nmero de pantallas, de informes, de componentes de
lenguajes, etc.
PM = ( NOP x (1 - %reuso/100 ) ) / PROD
PM es el esfuerzo en personas-mes, NOP es el nmero de puntos de objeto, y
PROD es la productividad que depende de:
Ingeniera en Sistemas Computacionales
69
7/31/2019 39861943 Unidad II Planif y Modelado
54/80
Planificacin y ModeladoPlanificacin del Sistema
o La experiencia y capacidad del desarrollador
o Las capacidades de la herramienta CASE utilizada
Y toma los valores presentados en la tabla 2.2.2.3.
Muy baja Baja Nominal Alta Muy alta4 7 13 25 50
Tabla 2.2.2.3
Nivel inicial de diseo: cuando se decide por una arquitectura para el diseo,
nuevamente no hay suficiente informacin para una estimacin precisa de
esfuerzo y duracin, pero se conoce ms que en el nivel 1. Entonces se emplea
puntos de funcin convertidas en LDC.
Las estimaciones pueden hacerse despus de que los requerimientos hayan
sido establecidos.
Se basa en las frmulas estndar para mtodos algortmicos:
PM = A x TamaoB x M + PMm
en donde
M= PERS x RCPX x RUSE x PDIF x PREX x FCIL x SCED
PMm= (ASLOC x (AT/100)) / ATPROD
A = 2.5 segn la calibracin inicial, Tamao se da en LDC, B vara desde 1.1
hasta 1.24 dependiendo de la novedad del proyecto, la flexibilidad del
desarrollo, la gestin de riesgos, y la madurez del proceso
Los multiplicadores (M) reflejan la capacidad de los desarrolladores,requerimientos no funcionales, la familiaridad con la platafo