Proyecto Integrador II PDF

UNIVERSIDAD PRIVADA TELESUP
Prefacio:
La asignatura es de carcter terico - prctico. sta,

tiene como finalidad desarrollar en el estudiante
habilidades
para
la
direccin
de
proyectos
empresariales globales. Adems, le brinda los

conocimientos
necesarios
para
implementar
proyectos de tecnologas de la informacin

integrndolos con variables disciplinas ya que es
un modelo de aprendizaje en el
que los
estudiantes planean, implementan y evalan proyectos que tienen aplicacin en el

mundo real; ms all del aula de clase. Est direccionada al planteamiento y solucin
de problemas relacionados con la prctica profesional y calidad de vida; requiere de la
articulacin de asignaturas del nivel, disciplina o carrera
Comprende cuatro Unidades de Aprendizaje:

Unidad I: Generalidades de la Direccin de Proyectos de TI.
Unidad II: Mtricas para Procesos y Proyectos de TI.
Unidad III: Estimacin para Proyectos de Software.
Unidad IV: Calendarizacin de Proyectos de Software.
Estructura de los Contenidos

Generalidades de la
Direccin de
Proyectos de TI
Mtricas para
Procesos y
Proyectos de TI
Estimacin
para Proyectos
de Software
Fundamentos de la
Direccin de
Proyectos.
Introduccin a las
Mtricas.
Introduccin a la
Estimacin de
Proyectos de
Software.
Introduccin a la
Canlendarizacin de
Proyectos de
Software.
Gestin de alcance
del Proyecto.
Mtricas de
Proceso.
Recursos de
Software.
La Canlendarizacin
de Proyectos.
Gestin de los
Riesgos del
Proyecto.
Gestin del tiempo

de un Proyecto.
Mtricas de
Proyecto.
Estimacin de
Proyectos.
Mtricas
Orientadas al
Tamao.
Estimacin
Basada en
Problemas.
La competencia
Calendarizacin
de Proyectos de
Software
Distribucin del
Esfuerzo.
Refinamiento de las
Tareas Principales.
que el estudiante debe lograr al final de la
asignatura es:
Conocer las herramientas y habilidades de
la
direccin de proyectos que le permitan
dirigir,
controlar
tecnologas de
la mano con la informacin global.
gestionar
proyectos
de
ndice del Contenido
I. PREFACIO
II. DESARROLLO DE LOS CONTENIDOS
UNIDAD DE APRENDIZAJE 1: GENERALIDADES DE LA DIRECCIN DE PROYECTOS DE TI
1.
Introduccin
a. Presentacin y contextualizacin
b. Competencia (logro)
c. Capacidades
d. Actitudes
e. Ideas bsicas y contenido
2.
Desarrollo de los temas
a. Tema 01: Fundamentos de la Direccin de Proyectos.
b. Tema 02: Gestin de Alcance del Proyecto.
c. Tema 03: Gestin de los Riesgos del Proyecto.
d. Tema 04: Gestin del Tiempo de un Proyecto.
3.
Lecturas recomendadas
4.
Actividades
5.
Autoevaluacin
6.
Resumen
UNIDAD DE APRENDIZAJE 2: MTRICAS PARA PROCESOS Y PROYECTOS DE TI
1.
Introduccin
c. Capacidades
d. Actitudes
2.
a. Tema 01: Introduccin a las Mtricas.
b. Tema 02: Mtricas de Proceso.
c. Tema 03: Mtricas de Proyecto.
d. Tema 04: Mtricas Orientadas al Tamao.
3.
4.
Actividades
5.
Autoevaluacin
6.
Resumen
UNIDAD DE APRENDIZAJE 3: ESTIMACIN PARA PROYECTOS DE SOFTWARE
1.
Introduccin
c. Capacidades
d. Actitudes
2.
a. Tema 01: Introduccin a la Estimacin de Proyectos de Software.
b. Tema 02: Recursos de Software.
c. Tema 03: Estimacin de Proyectos.
d. Tema 04: Estimacin Basada en Problemas.
3.
4.
Actividades
5.
Autoevaluacin
6.
Resumen
UNIDAD DE APRENDIZAJE 4: CALENDARIZACIN DE PROYECTOS DE SOFTWARE
1.
Introduccin
b. Competencia
c. Capacidades
d. Actitudes
2.
a. Tema 01: Introduccin a la Calendarizacin de Proyectos de Software.
b. Tema 02: La Calendarizacin de Proyectos.
c. Tema 03: Distribucin del Esfuerzo.
d. Tema 04: Refinamiento de las tareas Principales.
3.
4.
Actividades
5.
Autoevaluacin
6.
Resumen
III. GLOSARIO
IV. FUENTES DE INFORMACIN
V. SOLUCIONARIO
02
03 - 119
05-37
06
06
06
06
06
06
07-33
07
12
18
24
34
34
35
37
38-59
39
39
39
39
39
39
40-55
40
44
48
51
56
56
57
59
60- 89
61
61
61
61
61
61
62-85
62
67
71
75
86
86
87
89
90-116
91
91
91
91
91
91
92-112
92
97
103
108
113
113
114
116
117
118
119
Introduccin
a) Presentacin y contextualizacin
Los temas que se tratan en la presente unidad didctica, tienen por finalidad que
usted aprenda los principios de la direccin de proyectos de tecnologas de la
informacin globales.
La importancia que tiene el nfasis estratgico de proyectos y la diferencia que
existe entre liderar un proyecto sin la ayuda de la alta gerencia, en este contexto es
importante introducir conceptos del ciclo de vida de los proyectos y procesos de
direccin de proyectos.
b) Competencia
Conoce los componentes que comprenden las generalidades de los proyectos
de TI.
c) Capacidades
1. Describe las principales caractersticas y comprende los fundamentos de un
proyecto de TI.
2. Identifica el alcance de un proyecto conociendo las entradas, tcnicas,
herramientas, y salidas correspondientes.
3. Analiza los riesgos con el fin de planificar y controlar un proyecto.
4. Estima el tiempo de un proyecto teniendo en cuenta las secuencias, recursos y
duracin.
d) Actitudes
Desarrolla una actitud emprendedora mediante la toma de iniciativas en un
proyecto de software.
Presenta inters por practicar de manera profesional la direccin de proyectos.
e) Presentacin de Ideas bsicas y contenido esenciales de la Unidad:

La Unidad de Aprendizaje 01: Generalidades de la Direccin de Proyectos de TI,
comprende el desarrollo de los siguientes temas:
TEMA 01: Fundamentos de la Direccin de Proyectos.
TEMA 02: Gestin de Alcance del Proyecto.
TEMA 03: Gestin de los Riesgos del Proyecto.
TEMA 04: Gestin del tiempo de un Proyecto.
Fundamentos
de la
TEMA 1
Direccin
de Proyectos
Competencia:
Describir las principales caractersticas y
comprender los fundamentos de un proyecto
de TI.
Desarrollo de los Temas
Tema 01: Fundamentos de la Direccin de

Proyectos
Los Fundamentos de la Direccin de Proyectos constituyen la suma de conocimientos
en la profesin de direccin de proyectos. Al igual que en otras profesiones, como la
abogaca, la medicina o las ciencias econmicas, los conocimientos residen en los
practicantes y acadmicos que los aplican y los desarrollan. Los Fundamentos de la
Direccin de Proyectos completos incluyen prcticas tradicionales comprobadas y
ampliamente utilizadas, as como prcticas innovadoras que estn emergiendo en la
profesin, incluyendo material publicado y no publicado. Como consecuencia, los
Fundamentos de la Direccin de Proyectos estn en constante evolucin.
QUE ES UN PROYECTO
Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto,
servicio o resultado nico.
Temporal
Temporal significa que cada proyecto tiene un
comienzo definido y un final definido. El final se
alcanza cuando se han logrado los objetivos del
proyecto o cuando queda claro que los objetivos del
proyecto no sern o no podrn ser alcanzados, o cuando la necesidad del
proyecto ya no exista y el proyecto sea cancelado. Temporal no necesariamente
significa de corta duracin; muchos proyectos duran varios aos. En cada caso,
sin embargo, la duracin de un proyecto es limitada. Los proyectos no son
esfuerzos continuos.
Productos, servicios o resultados nicos

Un proyecto crea productos entregables nicos. Productos entregables son
productos, servicios o resultados. Los proyectos pueden crear:
Un producto o artculo producido, que es cuantificable, y que puede ser un
elemento terminado o un componente.
La capacidad de prestar un servicio como, por ejemplo, las funciones del
negocio que respaldan la produccin o la distribucin.
Un resultado como, por ejemplo, salidas o documentos. Por ejemplo, de un

proyecto de investigacin se obtienen conocimientos que pueden usarse
para determinar si existe o no una tendencia o si un nuevo proceso
beneficiar a la sociedad.
Elaboracin gradual
La elaboracin gradual es una caracterstica de los
proyectos que acompaa a los conceptos de temporal
y nico. Elaboracin gradual significa desarrollar en
pasos e ir aumentando mediante incrementos. Por
ejemplo, el alcance de un proyecto se define de forma
general al comienzo del proyecto, y se hace ms
explcito y detallado a medida que el equipo del proyecto desarrolla un mejor y
ms completo entendimiento de los objetivos y de los productos entregables.
Los siguientes ejemplos ilustran la elaboracin gradual en dos reas de
aplicacin diferentes.
El desarrollo de una planta de procesamiento qumico comienza con la

ingeniera de proceso que define las caractersticas del proceso. Estas
caractersticas se utilizan para disear las unidades de procesamiento
principales. Esta informacin se convierte en la base para el diseo de
ingeniera, que define tanto el plano detallado de la planta como las
caractersticas mecnicas de las unidades de proceso y las instalaciones
auxiliares. Todo ello resulta en dibujos de diseo que se
elaboran
para
crear
dibujos
de
fabricacin
construccin. Durante la construccin, se realizan las

interpretaciones y adaptaciones que sean necesarias,
que estn sujetas a la aprobacin correspondiente. Esta
elaboracin adicional de los productos entregables se
refleja en dibujos que se realizan sobre la marcha, y los
ajustes operativos finales se realizan durante la etapa de
pruebas y rotacin.
El producto de un proyecto de desarrollo econmico puede definirse

inicialmente como: Mejorar la calidad de vida de los residentes con
ingresos ms bajos de la comunidad X. A medida que el proyecto avanza,
los productos pueden describirse ms especficamente como, por ejemplo:
Proporcionar acceso a agua y comida a 500 residentes de bajos ingresos
de la comunidad X. La siguiente etapa de elaboracin gradual podra
centrarse exclusivamente en mejorar la produccin y comercializacin
agrcola, considerando la provisin de agua como una segunda prioridad, a
ser iniciada una vez que el componente agrcola est en una etapa
avanzada.
Proyectos frente a trabajos operativos

Las organizaciones realizan trabajos con el fin de lograr un conjunto de objetivos. Por
lo general, los trabajos se clasifican en proyectos y operaciones, aunque en algunos
casos estos se superponen. Pueden compartir varias de las siguientes caractersticas:
Realizados por personas.
Restringidos por la limitacin de los recursos.
Planificados, ejecutados y controlados.
Los proyectos y las operaciones difieren primordialmente en que las operaciones son
continuas y repetitivas, mientras que los
proyectos son temporales y nicos.
Los objetivos de los proyectos y las
operaciones
son
fundamentalmente
diferentes. La finalidad de un proyecto es

alcanzar su objetivo y luego concluir. Por el
contrario, el objetivo de una operacin
continua es dar respaldo al negocio. Los
proyectos
son
diferentes
porque
el
proyecto concluye cuando se alcanzan sus

objetivos especficos, mientras que las operaciones adoptan un nuevo conjunto de
objetivos y el trabajo contina.
10
Los proyectos se llevan a cabo en todos los niveles de la organizacin y pueden

involucrar a una sola persona o a varios miles. Pueden durar entre unas pocas
semanas y varios aos. Los proyectos pueden incluir una o varias unidades
organizativas, como, por ejemplo, las asociaciones transitorias y los convenios para un
proyecto determinado.
Entre los ejemplos de proyectos se incluyen, entre otros:
Desarrollar un nuevo producto o servicio.
Efectuar un cambio en la estructura, en el personal o en el
estilo de una organizacin.
Disear un nuevo vehculo de transporte.
Desarrollar o adquirir un sistema de informacin nuevo o
modificado.
Construir un edificio o una planta.

Construir un sistema de abastecimiento de agua para una
comunidad.
Realizar una campaa para un partido poltico.
Implementar un nuevo procedimiento o proceso de negocio.
Responder a una solicitud de contrato.
11
Gestin de
Alcance del
Proyecto
TEMA 2
Competencia:
Identificar el alcance de un proyecto
conociendo
las
entradas,
tcnicas,
herramientas, y salidas correspondientes.
12
Tema 02: Gestin de Alcance del Proyecto

La gestin del alcance del proyecto define lo que est y no est incluido en la
realizacin del proyecto, es la definicin de todos los
requerimientos,planes, productos entregables y controles
necesarios
para
desarrollar
el
proyecto
satisfactoriamente y tener un cierre elegante. Adems

comprende las actividades orientadas a garantizar el
cumplimiento de las tareas necesarias para lograr los objetivos del proyecto.
Segn la guia de los fundamentos de la direccin de proyectos dice:

La Gestin del Alcance del Proyecto incluye los procesos necesarios para asegurarse
que el proyecto incluya todo el trabajo requerido, y slo el trabajo requerido, para
completar el proyecto satisfactoriamente.
La palabra alcance puede definirse en lo siguiente:
Alcance del producto. Las caractersticas y funciones

que caracterizan a un producto, servicio o resultado.
Alcance del proyecto. El trabajo que debe realizarse para

entregar un producto, servicio o resultado con las
funciones y caractersticas especificadas.
El flujo de procesos de la gestin del alcance del proyecto es el siguiente:
Planificacin del alcance
Verificacin del alcance
Definicin del alcance
Control del alcance
El siguiente resumen describe las caracteristicas principales de los procesos

Planificacin del alcance
El plan de gestin del alcance del proyecto es una herramienta de planificacin
que describe cmo el equipo definir el alcance del proyecto, desarrollar el
enunciado del alcance del proyecto detallado, definir y desarrollar la estructura
de desglose del trabajo, verificar y controlar el alcance del proyecto.
13
Entradas
1. Factores Ambientales de la Empresa
2. Activos de los Procesos de la Organizacin
3. Acta de Constitucin del Proyecto
4. Enunciado del Alcance del Proyecto Preliminar
5. Plan de Gestin del Proyecto
Herramientas y Tcnicas
Juicio de Expertos para desarrollar el plan de gestin del
alcance del proyecto.Plantillas, Formularios, Normas
Plantillas de estructura de desglose del trabajo,
plantillas de plan de gestin del alcance y formularios de control de cambios en
el alcance del proyecto.
Salidas
Plan de Gestin del Alcance del Proyecto
El plan de gestin del alcance del proyecto proporciona
orientacin sobre cmo el equipo de direccin del
proyecto definir, documentar, verificar, gestionar y
controlar el alcance del proyecto.
Definicin del alcance
La preparacin de un enunciado del alcance del proyecto detallado es crtica
para el xito del proyecto y se construye sobre la base de los principales
productos entregables, asunciones y restricciones que se documentan durante la
iniciacin del proyecto en el enunciado del alcance del proyecto preliminar.
Durante la planificacin, el alcance del proyecto se define y describe con mayor
especificidad porque se conoce ms informacin acerca del proyecto.
Entradas
1. Activos de los Procesos de la Organizacin
2. Acta de Constitucin del Proyecto
3. Enunciado del Alcance del Proyecto Preliminar
4. Plan de Gestin del Alcance del Proyecto
2. Solicitudes de Cambio Aprobadas
14
1. Anlisis del Producto Tcnicas como desglose del
producto, anlisis de
2. sistemas, ingeniera de sistemas, ingeniera del
valor, anlisis del valor y anlisis funcional.
3. Identificacin de Alternativas Las ms comunes son
la tormenta de ideas y el pensamiento lateral.
4. Juicio de Expertos
5. Anlisis de los Interesados Identifica la influencia y
los intereses de los diversos interesados y documenta sus necesidades,
deseos y expectativas.
Salidas
1. Enunciado del Alcance del Proyecto El enunciado del alcance del proyecto
describe, en detalle, los productos entregables del proyecto y el trabajo
necesario para crear tales productos entregables.
2. Cambios Solicitados
3. Plan de Gestin del Alcance del Proyecto (Actualizaciones).
Verificacin del alcance

Si el proyecto se termina antes de lo previsto, el proceso de verificacin del
alcance
del
proyecto
debera
establecer
documentar el nivel y alcance de lo completado.

Entradas
1. Enunciado del Alcance del Proyecto.
2. Plan de Gestin del Alcance del
Proyecto.
3. Productos
Entregables
Los
productos entregables son aquellos que se

han completado total o parcialmente, y constituyen una salida del proceso
dirigir y Gestionar la Ejecucin del Proyecto.
15
1. Inspeccin Medir, examinar y verificar, a fin de determinar si el trabajo y los
productos entregables cumplen con los requisitos y los criterios de
aceptacin del producto.
2. Las inspecciones pueden denominarse revisiones, revisiones de productos,
auditoras y revisiones generales.La verificacin del alcance es el proceso de
obtener la aceptacin formal por parte de los interesados del alcance del
proyecto completado y los productos entregables relacionados. Verificar el
alcance del proyecto incluye revisar los productos entregables para
asegurarse de que cada uno se complete satisfactoriamente.
Salidas
1. Productos Entregables Aceptados, 2. Cambios Solicitados, 3. Acciones
Correctivas Recomendadas
Control del alcance
El control del alcance del proyecto se encarga de influir sobre los factores que
crean cambios en el alcance del proyecto y de controlar el impacto de dichos
cambios. El control del alcance del proyecto tambin se usa para gestionar los
cambios reales cuando se producen, y est integrado con los dems procesos de
control. Los cambios no controlados a menudo se denominan corrupcin del
alcance del proyecto. Los cambios son inevitables, con lo cual se impone algn
tipo de proceso de control de cambios.
Entradas
1. Enunciado del Alcance del Proyecto
2. Estructura de Desglose del Trabajo
3. Plan de Gestin del Alcance del Proyecto
4. Informes de Rendimiento Los informes de rendimiento proporcionan
informacin sobre el rendimiento del trabajo del proyecto, como por ejemplo
los productos entregables intermedios que se han completado.
2. Solicitudes de Cambio Aprobadas
3. Informacin sobre el Rendimiento del Trabajo
16
1. Sistema de Control de Cambios Define los procedimientos por los cuales
pueden modificarse el alcance del proyecto y el alcance del producto.
2. Anlisis de Variacin Las mediciones del rendimiento del proyecto se usan
para evaluar la magnitud de la variacin.
2. Replanificacin Con las solicitudes de cambio aprobadas que afecten al
alcance del proyecto
3. Sistema de Gestin de la Configuracin Proporciona procedimientos para el
estado de situacin de los productos entregables
Salidas
1. Enunciado del Alcance del Proyecto (Actualizaciones)
2. Estructura de Desglose del Trabajo (Actualizaciones)
2. Lnea Base del Alcance (Actualizaciones)
3. Cambios Solicitados
4. Acciones Correctivas Recomendadas
5. Activos
de
los
Procesos
de
la
Organizacin
(Actualizaciones)
6. Plan de Gestin del Proyecto (Actualizaciones)
17
Gestin
de los Riesgos
del Proyecto
TEMA 3
Competencia:
Analizar los riesgos con el fin de planificar y
controlar un proyecto.
18
Tema 03: Gestin de los Riesgos del

Proyecto
La gestin de riesgos de un proyecto proceden de acontecimientos que si suceden
tienen un efecto positivo o negativo sobre los objetivos del proyecto. El riesgo tiene
una causa y, si se produce, un impacto. El riesgo incluye una amenaza para el
cumplimiento de los objetivos del proyecto y, a la vez, una oportunidad para mejorar
estos objetivos. La gestin de riesgos debe cubrir todas las reas del proyecto,
incluyendo los resultados (tcnicos y de calidad), los programticos (financiacin,
opinin pblica, autorizaciones legales, aspectos polticos, etc.), los econmicos
(condiciones del contrato y costes de proyecto), programacin y operacin (soporte
logstico, fiabilidad y seguridad).
Adems la gestin de riesgos de un proyecto incluye los procesos relacionados con la

planificacin de la gestin de riesgos, la identificacin y el anlisis de riesgos, las
respuestas a los riesgos, y el seguimiento y control de riesgos de un proyecto; la
mayora de estos procesos se actualizan durante el proyecto, Segn el PMBOK Los
procesos de Gestin de Riesgos incluyen lo siguiente:
Planificacin de la Gestin de Riesgos.
Identificacin de Riesgos.
Anlisis Cualitativo de Riesgo.
Anlisis Cuantitativo de Riesgos.
Planificacin de la Respuesta a los Riesgos.
Seguimiento y Control de Riesgos.
A continuacin se describe las principales actividades de los procesos de la gestin de

riesgos del proyecto
Planificacin de la Gestin de Riesgos: Decidir cmo enfocar,
planificar y ejecutar las actividades de gestin de riesgos para
un proyecto. El proceso Planificacin de la Gestin de
Riesgos debe completarse en las fases tempranas de
la planificacin del proyecto, dado que es crucial para
realizar con xito los dems procesos.
19
Entradas
1. Factores Ambientales de la Empresa.
2. Activos de los Procesos de la Organizacin.
3. Enunciado del Alcance del Proyecto.
4. Plan de Gestin del Proyecto.
Herramientas y tcnicas. Reuniones de planificacin y anlisis
Salidas. Plan de gestin de riesgos
La estructura de desglose enumera las categoras y sub-categoras donde se

producen riesgos
Identificacin de Riesgos
Determinar qu riesgos pueden afectar al proyecto y documentar sus caractersticas.
La Identificacin de Riesgos es un proceso iterativo
porque se pueden descubrir nuevos riesgos a medida
que el proyecto avanza a lo largo de su ciclo de vida.
La frecuencia de la iteracin y quin participar en
cada ciclo variar de un caso a otro. El equipo del
proyecto debe participar en el proceso para poder
desarrollar y mantener un sentido de pertenencia y responsabilidad por los riesgos y
las acciones asociadas con la respuesta a los riesgos.
20
Los interesados ajenos al equipo del proyecto pueden proporcionar informacin

adicional sobre los objetivos. El proceso Identificacin de Riesgos suele llevar al
proceso Anlisis Cualitativo de Riesgos. Como alternativa, puede llevar directamente
al proceso Anlisis Cuantitativo de Riesgos cuando lo dirige un director de riesgos
experimentado. En algunas ocasiones, simplemente la identificacin de un riesgo
puede sugerir su respuesta, y esto debe registrarse para realizar otros anlisis y para
su implementacin en el proceso Planificacin de la Respuesta a los Riesgos.
Anlisis Cualitativo de Riesgos

Priorizar los riesgos para realizar otros anlisis o acciones posteriores, evaluando y
combinando su probabilidad de ocurrencia y su impacto. El Anlisis Cualitativo de
Riesgos incluye los mtodos para priorizar los riesgos identificados
para realizar otras acciones, como Anlisis Cuantitativo de
Riesgos o Planificacin de la Respuesta a los Riesgos. Las
organizaciones pueden mejorar el rendimiento del proyecto de
manera efectiva centrndose en los riesgos de alta prioridad.
El Anlisis Cualitativo de Riesgos evala la prioridad de los riesgos identificados

usando la probabilidad de ocurrencia, el impacto correspondiente sobre los objetivos
del proyecto si los riesgos efectivamente ocurren, as como otros factores como el
plazo y la tolerancia al riesgo de las restricciones del proyecto como coste,
cronograma, alcance y calidad.
Las definiciones de los niveles de probabilidad e

impacto, as como las entrevistas a expertos,
pueden ayudar a corregir los sesgos que a menudo
estn presentes en los datos usados en este
proceso.
La
criticidad
temporal
de
acciones
relacionadas con riesgos puede magnificar la

importancia de un riesgo. Una evaluacin de la
calidad de la informacin disponible sobre los riesgos del proyecto tambin ayuda a
comprender la evaluacin de la importancia del riesgo para el proyecto.
21
Anlisis cuantitativo de riesgos

Analizar numricamente el efecto de los riesgos identificados en los objetivos
generales del proyecto. Este proceso usa tcnicas tales como la simulacin Monte
Carlo y el anlisis mediante rbol de decisiones para:
Cuantificar los posibles resultados del proyecto y sus probabilidades.
Evaluar la probabilidad de lograr los objetivos especficos del proyecto.
Identificar los riesgos que requieren una mayor atencin mediante la

cuantificacin de su contribucin relativa al riesgo general del proyecto.
Identificar objetivos de coste, cronograma o alcance realistas y viables, dados los

riesgos del proyecto.
Determinar la mejor decisin de direccin de proyectos cuando algunas

condiciones o resultados son inciertos.
Planificacin de la respuesta a los riesgos

La Planificacin de la Respuesta a los Riesgos es
el proceso de desarrollar opciones y determinar
acciones para mejorar las oportunidades y reducir
las amenazas a los objetivos del proyecto. Se
realiza despus de los procesos Anlisis Cualitativo
de Riesgos y Anlisis Cuantitativo de Riesgos. Incluye la identificacin y asignacin de
una o ms personas (el propietario de la respuesta a los riesgos) para que asuma la
responsabilidad de cada respuesta a los riesgos acordada y financiada.
La Planificacin de la Respuesta a los Riesgos aborda los

riesgos en funcin de su prioridad, introduciendo recursos y
actividades en el presupuesto, cronograma y plan de gestin
del proyecto, segn sea necesario. Las respuestas a los
riesgos planificadas deben ser congruentes con la importancia
del riesgo, tener un coste efectivo en relacin al desafo, ser
aplicadas a su debido tiempo, ser realistas dentro del contexto del proyecto, estar
acordadas por todas las partes implicadas, y a cargo de una persona responsable.
22
A menudo, es necesario seleccionar la mejor respuesta

a los riesgos entre varias opciones. La seccin
Planificacin de la Respuesta a los Riesgos presenta
los enfoques comnmente usados para planificar las
respuestas a los riesgos. Los riesgos incluyen las
amenazas y las oportunidades que pueden afectar al
xito del proyecto, y se discuten las respuestas para cada una de ellas.
Seguimiento y control de riesgos

Las respuestas a los riesgos planificadas que estn incluidas en el plan de gestin del
proyecto se ejecutan durante el ciclo de vida del proyecto, pero el trabajo del proyecto
debe ser supervisado continuamente para detectar riesgos nuevos o que cambien. El
Seguimiento y Control de Riesgos es el proceso de identificar, analizar y planificar
nuevos riesgos, realizar el seguimiento de los riesgos identificados y los que se
encuentran en la lista de supervisin, volver a analizar los riesgos existentes, realizar
el seguimiento de las condiciones que disparan los planes para contingencias, realizar
el seguimiento de los riesgos residuales y revisar la ejecucin de las respuestas a los
riesgos mientras se evala su efectividad.
El proceso Seguimiento y Control de Riesgos aplica

tcnicas, como el anlisis de variacin y de tendencias,
que requieren el uso de datos de rendimiento generados
durante la ejecucin del proyecto. El proceso Seguimiento
y Control de Riesgos, as como los dems procesos de
gestin de riesgos, es un proceso continuo que se realiza durante la vida del proyecto.
23
Gestin del
Tiempo de un
Proyecto
TEMA 4
Competencia:
Estimar el tiempo de un proyecto teniendo en
cuenta las secuencias, recursos y duracin.
24
Tema 04: Gestin del Tiempo de un Proyecto

Cuando se prepara un proyecto uno de los aspectos ms importantes es el tiempo que
llevar el desarrollar el proyecto y el costo, en este tema se explica la forma de
administrarlos.
Los procesos de la gestin del tiempo son:
o
Definicin de las actividades.
Establecimiento de la secuencia de las actividades.
Estimacin de recursos de las actividades.
Estimacin de la duracin de las actividades.
Desarrollo del cronograma.
DEFINICIN DE LAS ACTIVIDADES

Definir las actividades del cronograma implica identificar y documentar el trabajo que
se planifica realizar. El proceso Definicin de las Actividades identificar los productos
entregables al nivel ms bajo de la estructura de desglose del trabajo. Los
paquetes de trabajo del proyecto estn planificados (descompuestos) en
componentes
ms
pequeos
denominados
actividades
del
cronograma, para proporcionar una base con el fin de estimar,

establecer el cronograma, ejecutar, y supervisar y controlar el trabajo del
proyecto. La definicin y planificacin de las actividades del cronograma estn
implcitas en este proceso, de tal modo que se cumplan los objetivos del proyecto.
Entradas
Factores Ambientales de la Empresa Incluyen la disponibilidad de los sistemas
de Informacin de la gestin de proyectos y herramientas de software para la
elaboracin de cronogramas.
Activos de los Procesos de la Organizacin Contienen las polticas formales e
informales existentes relacionadas con la planificacin de actividades, los
procedimientos y las guas que se tienen en cuenta al desarrollar las definiciones
de las actividades.
25
Enunciado del Alcance del Proyecto Los productos entregables del proyecto,
las restricciones y las asunciones documentadas en el enunciado del alcance del
proyecto.
Estructura de Desglose del Trabajo La estructura de desglose del trabajo es
una entrada principal para la definicin de las actividades del cronograma.
Plan de Gestin del Proyecto El plan de gestin del proyecto contiene el plan de
gestin del cronograma, que proporciona orientacin sobre el desarrollo y la
planificacin de las actividades del cronograma y del plan de gestin del alcance
del proyecto.
Descomposicin Implica subdividir los paquetes de trabajo del proyecto en
componentes ms pequeos y ms fciles de manejar, denominados actividades
del cronograma
Plantillas Puede incluir una lista de habilidades de los recursos y la cantidad de
horas de esfuerzo necesarias, la identificacin de riesgos, los productos
entregables esperados y cualquier otra informacin descriptiva.
Planificacin Gradual Las actividades del cronograma pueden existir a distintos
niveles de detalle en el ciclo de vida del proyecto. Durante los inicios de la
planificacin estratgica, cuando la informacin est menos definida, las
actividades se pueden mantener al nivel de hito.
Juicio de Expertos o de los miembros del equipo del proyecto.
Componente de Planificacin Dos componentes de planificacin son:
o
Cuenta de Control. Se puede ubicar un punto de

control
de
gestin
en
puntos
de
gestin
seleccionados (componentes especficos en niveles

seleccionados) de la estructura de desglose del
trabajo. Estos puntos de control se utilizan como base para la planificacin
cuando todava no se han planificado los paquetes de trabajo relacionados.
Todo el trabajo y el esfuerzo realizado dentro de una cuenta de control se
documenta en un plan de la cuenta de control.
o
Paquete de Planificacin. Un paquete de planificacin es un componente

ubicado por debajo de la cuenta de control, pero por encima del paquete de
trabajo. Este componente se utiliza para planificar el contenido del trabajo
conocido que no tiene actividades del cronograma detalladas.
26
Salidas
Lista de Actividades
Atributos de la Actividad Identifican los mltiples atributos relacionados con
cada actividad del cronograma. Incluyen el identificador de la actividad, los
cdigos de la actividad, la descripcin de la actividad, las actividades
predecesoras, las actividades sucesoras, las relaciones lgicas, los adelantos y
los retrasos, los requisitos de recursos, las fechas impuestas, las restricciones y
las asunciones
Lista de Hitos Identifica todos los hitos e indica si es obligatorio u opcional.
Cambios Solicitados.
ESTABLECIMIENTO DE LA SECUENCIA DE LAS ACTIVIDADES

Implica identificar y documentar las relaciones lgicas entre las actividades del
cronograma. Las actividades del cronograma pueden estar ordenadas de forma lgica
con relaciones de precedencia adecuadas, as como tambin adelantos y retrasos,
para respaldar el desarrollo posterior de un cronograma del proyecto realista y factible.
Entradas
Enunciado del Alcance del Proyecto.
Lista de Actividades.
Atributos de la Actividad.
Lista de Hitos.
Solicitudes de Cambio Aprobadas.
Mtodo de Diagramacin por Precedencia (PDM)

Esta tcnica tambin se denomina actividad en el nodo (AON), y es el mtodo
utilizado por la mayora de los paquetes de software de gestin de proyectos. El
PDM incluye cuatro tipos de dependencias o relaciones de precedencia:
o Final a Inicio.
o Final a Final.
o Inicio a Inicio.
o Inicio a Fin.
En el PDM, final a inicio es el tipo de relacin de
precedencia ms comnmente usado.
27
Las relaciones inicio a fin raramente se utilizan
Mtodo de Diagramacin con Flechas (ADM) Es un mtodo para crear un

diagrama de red del cronograma del proyecto que utiliza flechas para
representar las actividades, que se conectan en nodos para mostrar sus
dependencias.
Plantillas de Red del Cronograma Pueden utilizarse para acelerar la

preparacin de redes de actividades del cronograma del proyecto. stas
pueden incluir un proyecto completo o solamente una parte de l.
Determinacin de Dependencias Se utilizan tres tipos de dependencias para

definir la secuencia entre las actividades.
o Dependencias obligatorias Son aquellas inherentes a la naturaleza del

trabajo que se est realizando.
o Dependencias discrecionales. Se encuentran totalmente documentadas,

ya que pueden producir valores arbitrarios de holgura total y pueden limitar
opciones posteriores de programacin.
o Dependencias externas. Son las que implican una relacin entre las
actividades del proyecto y las actividades que no pertenecen al proyecto.
Aplicacin de Adelantos y Retrasos El equipo de direccin del proyecto

determina las dependencias que pueden requerir un adelanto o un retraso para
definir con exactitud la relacin lgica.
Salidas
Diagramas de Red del Cronograma del Proyecto.
Lista de Actividades (Actualizaciones).
Atributos de la Actividad (Actualizaciones).
Cambios Solicitados.
28
ESTIMACIN DE RECURSOS DE LAS ACTIVIDADES

Involucra determinar cules son los recursos (personas,
equipos, o material) y qu cantidad de cada recurso se
utilizar, y cundo estar disponible cada recurso para realizar
las actividades del proyecto. El proceso Estimacin de Recursos de las Actividades se
coordina estrechamente con el proceso Estimacin de Costes.
Entradas
Factores Ambientales de la Empresa.
Activos de los Procesos de la Organizacin.
Lista de Actividades.
Atributos de la Actividad.
Disponibilidad de Recursos.
Plan de Gestin del Proyecto.
o
Juicio de Expertos
Anlisis de Alternativas
Datos de Estimacin Publicados Varias empresas publican peridicamente los

ndices de produccin actualizados y los costes unitarios de los recursos para
una extensa variedad de industrias, materiales y equipos, en diferentes pases y
en diferentes ubicaciones geogrficas dentro de esos pases.
Software de Gestin de Proyectos Tiene la capacidad de ayudar a planificar,

organizar y gestionar los conjuntos de recursos, y de desarrollar estimaciones de
recursos.
Estimacin Ascendente Cuando no se puede estimar una actividad del

cronograma con un grado razonable de confianza, el trabajo que aparece dentro
de la actividad del cronograma se descompone con ms detalle. Se estiman las
necesidades de recursos de cada una de las partes inferiores y ms detalladas
del trabajo, y estas estimaciones se suman luego en una cantidad total para cada
uno de los recursos de la actividad del cronograma.
29
Salidas
Requisitos de Recursos de las Actividades Es una identificacin y descripcin
de los tipos y las cantidades de recursos necesarios para cada actividad del
cronograma de un paquete de trabajo. Estos requisitos pueden sumarse para
determinar los recursos estimados para cada paquete de trabajo.
Atributos de la Actividad (Actualizaciones) Los tipos y las cantidades de
recursos necesarios para cada actividad del cronograma se incorporan a los
atributos de la actividad.
Estructura de Desglose de Recursos La estructura de desglose de recursos

(RBS) es una estructura jerrquica de los recursos identificados por categora y
tipo de recurso.
Calendario de Recursos (Actualizaciones) Documenta los das laborables y n
laborables que determinan aquellas fechas en las que cada recurso especfico,
ya sea una persona o un material, puede estar activo u ocioso.
Cambios Solicitados
DESARROLLO DEL CRONOGRAMA

Es un proceso iterativo, determina las fechas de inicio y finalizacin
planificadas para las actividades del proyecto. El desarrollo del cronograma exige que
se revisen y se corrijan las estimaciones de duracin y las estimaciones de los
recursos para crear un cronograma del proyecto aprobado que pueda servir como
lnea base con respecto a la cual poder medir el avance.
Entradas
Activos de los Procesos de la Organizacin Como un

calendario del proyecto
Enunciado del Alcance del Proyecto
30
Hay dos categoras principales de restricciones de tiempo que se tienen en

cuenta durante el desarrollo del cronograma:
-
Las fechas impuestas para el inicio o la finalizacin de las actividades

pueden usarse para restringir el inicio o la finalizacin a que se produzca
no antes de una fecha especificada o no despus de una fecha
especificada.
El patrocinador del proyecto, el cliente del proyecto u otros interesados a

menudo determinan eventos clave o hitos principales que afectan a la
finalizacin de ciertos productos entregables para una fecha especfica.
Lista de Actividades
Atributos de la Actividad
Diagramas de Red del Cronograma del Proyecto
Requisitos de Recursos de las Actividades
Calendarios de Recursos
Estimaciones de la Duracin de la Actividad
Plan de Gestin del Proyecto Contiene el plan de gestin del cronograma, el
plan de gestin de costes, el plan de gestin del alcance del proyecto y el plan
de gestin de riesgos. Estos planes guan el desarrollo del cronograma.
Anlisis de la Red del Cronograma Emplea un modelo de cronograma y diversas
tcnicas analticas, para calcular las fechas de inicio y finalizacin tempranas y
tardas, y las fechas de inicio y finalizacin planificadas para las partes no
completadas de las actividades del cronograma del proyecto
Mtodo del Camino Crtico Es una tcnica de anlisis que calcula las fechas de
inicio y finalizacin tempranas y tardas tericas para todas las actividades del
cronograma, sin considerar las limitaciones de recursos.
Compresin del Cronograma Acorta el cronograma del proyecto sin modificar el
alcance del proyecto, para cumplir con las restricciones del cronograma, las fechas
impuestas u otros objetivos del cronograma. Las tcnicas de compresin del
cronograma incluyen: Intensificacin y Ejecucin rpida.
31
Anlisis Qu pasa si...? Un anlisis de la red del cronograma se realiza

usando el modelo de cronograma para calcular diferentes escenarios, tales como
la demora en la entrega de uno de los principales componentes, la ampliacin de
la duracin de un diseo especfico o la aparicin de factores externos, como una
huelga o un cambio en el proceso de permisos.
Nivelacin de Recursos Se usa para abordar las actividades del

cronograma que deben realizarse para cumplir con fechas de entrega
determinadas, para abordar situaciones en las que se dispone de
recursos compartidos o crticos necesarios slo en ciertos
momentos o en cantidades limitadas, o para mantener el
uso de recursos seleccionados a un nivel constante durante perodos especficos
del trabajo del proyecto.
Mtodo de Cadena Crtica Combina los enfoques determinstico y probabilstico.
Agrega colchones de duracin que son actividades del cronograma no laborables,
para mantener el enfoque en las duraciones de las actividades planificadas.
Software de Gestin de Proyectos El software de gestin de proyectos para la

elaboracin de cronogramas se utiliza ampliamente para ayudar en el desarrollo
del cronograma. Otros software pueden ser capaces de interactuar de forma
directa o indirecta con el software de gestin de proyectos para llevar a cabo los
requisitos de otras reas de Conocimiento, como la estimacin de costes por
perodo y la simulacin del cronograma en el anlisis cuantitativo de riesgos.
32
Calendarios Aplicables Los calendarios del proyecto y los calendarios de

recursos identifican los perodos en que se autoriza el trabajo
Ajuste de Adelantos y Retrasos Como el uso inadecuado de adelantos o
retrasos puede distorsionar el cronograma del proyecto, los adelantos o retrasos
se ajustan durante el anlisis de la red del cronograma para desarrollar un
cronograma del proyecto viable.
Modelo de Cronograma Se utilizan con mtodos manuales o con software de

gestin de proyectos para realizar el anlisis de la red del cronograma a fin de
generar el cronograma del proyecto.
Salidas
Cronograma del Proyecto
o
Diagramas de red del cronograma del proyecto
Diagramas de barras
Diagramas de hitos
Datos del Modelo de Cronograma

Requisitos de Recursos (Actualizaciones)
Atributos de la Actividad (Actualizaciones)
Calendario del Proyecto (Actualizaciones)
Cambios Solicitados
Plan de Gestin del Proyecto (Actualizaciones)
33
Lecturas Recomendadas
EL ALCANCE DE UN PROYECTO
http://www.tress.com.mx/esp/Portals/0/Documentos%20varios/Bolet%C3%ADn%
20mensual/Abril/Alcance%20proyecto.pdf
GESTIN DEL TIEMPO DE UN PROYECTO

http://www.slideshare.net/CulturaEmpresarial/gestion-del-tiempo-presentation
Actividades y Ejercicios
1. En un documento en Word indique el alcance de un proyecto

para un sistema de comercializacin en una tienda de
computadoras y determina los posibles riesgos.
Envalo a travs de "Proyectos".
2. En un documento en Word explique el alcance de un

proyecto para un sistema de notas y matriculas en un
colegio y determina los posibles riesgos.
Envalo a travs de "Riesgos de un Proyecto".
34
Autoevaluacin
1) Los procesos de la gestin del tiempo no son:

a. Definicin de las actividades.
b. Establecimiento de la secuencia de las actividades.
c. Estimacin de recursos de las actividades.
d. Estimacin de la duracin de las actividades.
e. Control de riesgos.
2) Cules son los fundamentos de la direccin de proyectos?
a. No constituyen la suma de conocimientos en la profesin de direccin de
proyectos.
b. Constituyen la suma de conocimientos en la profesin de direccin de
proyectos.
c. Constituyen la suma de conocimientos de la programacin.
d. Solo la consolidacin de los componentes del proyecto.
e. Solo articula los componentes del proyecto.
3) __________ se define de forma general al comienzo del proyecto, a medida
que el equipo del proyecto desarrolla un mejor y ms completo
entendimiento de los objetivos y de los productos entregables:
a. Las mtricas de un proyecto.
b. El refinamiento de un proyecto.
c. Alcance de un proyecto.
d. La ingeniera del software.
e. La gerencia del proyecto.
4) La gestin de alcance no:
a. Incluye los procesos necesarios para asegurarse que el proyecto incluya todo
el trabajo requerido.
b. Incluye el trabajo que debe realizarse para entregar un producto, servicio o
resultado con las funciones y caractersticas especificadas.
c. Comprende las actividades orientadas a garantizar el cumplimiento de las
tareas necesarias para lograr los objetivos del proyecto.
d. Incluye los procesos necesarios para asegurarse que el proyecto se complete
satisfactoriamente.
e. Comprende el xito de un proyecto cuando llega a entregarse antes de la
fecha lmite.
5) Los riesgos:
a. Incluyen una amenaza para el cumplimiento de los objetivos del proyecto.
b. No incluyen una amenaza para el cumplimiento de los objetivos del proyecto.
c. Omiten la oportunidad para lograr los objetivos de un proyecto.
d. Son un anuncio de un mal futuro ilcito que es posible, impuesto y
determinado con la finalidad de causar inquietud o miedo en el amenazado.
e. Son problemas internos, que una vez identificados y desarrollando una
adecuada estrategia, pueden y deben eliminarse.
35
6) Es una caracterstica de los Proyectos frente a trabajos operativos:

a. Realizados por las maquinas.
b. Restringidos por la limitacin de los recursos.
c. Son cronometrados.
d. Restringidos por la cdigos ticos.
e. Limitados por el software.
7) Es un proceso iterativo, determina las fechas de inicio y finalizacin
planificadas para las actividades del proyecto:
a. Desarrollo del calendario.
b. Programa de procesos.
c. Programa de actividades.
d. Desarrollo del cronograma.
e. Manual de procesos.
8) El trabajo que debe realizarse para entregar un producto, servicio o resultado
con las funciones y caractersticas especificadas, es:
a.
b.
c.
d.
e.
Alcance del producto.

Planificacin del alcance.
Alcance del proyecto.
Definicin del alcance.
Verificacin del alcance.
9) Es aquella que involucra determinar cules son los recursos (personas,

equipos, o material) y qu cantidad de cada recurso se utilizar, y cundo
estar disponible cada recurso para realizar las actividades del proyecto:
a.
b.
c.
d.
e.
Estimacin de recursos de las actividades.

Estimacin de punto de funcin.
Estimacin de procesos.
Estimacin de costo de software.
Estimacin de lneas de cdigo.
10) La gestin de Riesgos no incluye:

a. Planificacin de la Gestin de Riesgos.
b.
c.
d.
e.
Identificacin de Riesgos.
Seguimiento y Control de Riesgos.
Planificacin de la Respuesta a los Riesgos.
Anlisis de Procedimiento.
36
Resumen
UNIDAD DE APRENDIZAJE I:
Entendemos que los fundamentos de la direccin de proyectos constituyen la suma de

conocimientos en la profesin de direccin de proyectos. Al igual que en otras
profesiones, como la abogaca, la medicina o las ciencias econmicas, los
conocimientos residen en los practicantes y acadmicos que los aplican y los
desarrollan. Los Fundamentos de la Direccin de Proyectos completos incluyen
prcticas tradicionales comprobadas y ampliamente utilizadas, as como prcticas
innovadoras que estn emergiendo en la profesin, incluyendo material publicado y no
publicado. Como consecuencia, los Fundamentos de la Direccin de Proyectos estn
en constante evolucin.
Podemos decir que la gestin del alcance del proyecto define lo que est y no est
incluido en la realizacin del proyecto, es la definicin de todos los
requerimientos,planes, productos entregables y controles necesarios para desarrollar el
proyecto satisfactoriamente y tener un cierre elegante. Adems comprende las
actividades orientadas a garantizar el cumplimiento de las tareas necesarias para lograr
los objetivos del proyecto.
Sabemos que la gestin de riesgos debe cubrir todas las reas del proyecto, incluyendo
los resultados (tcnicos y de calidad), los programticos (financiacin, opinin pblica,
autorizaciones legales, aspectos polticos, etc.), los econmicos (condiciones del
contrato y costes de proyecto), programacin y operacin (soporte logstico, fiabilidad y
seguridad).
Adems la gestin de riesgos de un proyecto incluye los procesos relacionados con la
planificacin de la gestin de riesgos, la identificacin y el anlisis de riesgos, las
respuestas a los riesgos, y el seguimiento y control de riesgos de un proyecto; la
mayora de estos procesos se actualizan durante el proyecto.
Dentro de la gestin del tiempo de un proyecto hay que definir las actividades del
cronograma implica identificar y documentar el trabajo que se planifica realizar. El
proceso Definicin de las Actividades identificar los productos entregables al nivel ms
bajo de la estructura de desglose del trabajo. Los paquetes de trabajo del proyecto
estn planificados (descompuestos) en componentes ms pequeos denominados
actividades del cronograma, para proporcionar una base con el fin de estimar,
establecer el cronograma, ejecutar, y supervisar y controlar el trabajo del proyecto.
37
38
Introduccin
a) Presentacin y contextualizacin:
En esta unidad el alumno aprender a definir un proyecto, los posibles riesgos, y
las mtricas con el fin de medir el progreso y as conocer la calidad o productividad
de dicho proyecto. Asimismo comprender el rol que cumplen los ingenieros de
software en cuanto a la recopilacin y evaluacin de la informacin entendiendo la
importancia de los indicadores, que brindan la visin necesaria para mejorar la
calidad y productividad de un proyecto.
b) Competencia:
Analiza las funciones de las mtricas de procesos para estimar el tamao del
proyecto, planificando el progreso objetivo y las mejoras necesarias de dicho
proyecto.
c) Capacidades:
1. Describe los procesos de aplicacin de las mtricas para la determinacin del
tamao de un proyecto.
2. Reconoce los principales factores que influyen en los procesos de desempeo
organizacional.
3. Analiza las tendencias de un proyecto para planificar las mejoras
correspondientes, evaluando la informacin adquirida.
4. Evala la productividad mediante el tamao del software a travs de las lneas
de cdigo y la calidad de una aplicacin a travs de los puntos de funcin.
d) Actitudes:
Muestra inters por mejorar la precisin en las estimaciones de tiempo, costo y
recursos.
Acta con responsabilidad personal ante las funciones mtricas de un proyecto.
e) Presentacin de Ideas bsicas y contenidos esenciales de la Unidad:

La Unidad de Aprendizaje 02: Mtricas para Procesos y Proyectos de TI,
TEMA 01: Introduccin a las Mtricas.
TEMA 02: Mtricas de Proceso.
TEMA 03: Mtricas de Proyecto.
TEMA 04: Mtricas Orientadas al Tamao.
39
Introduccin
a las
Mtricas
TEMA 1
Competencia:
Describir los procesos de aplicacin de las
mtricas para la determinacin del tamao
de un proyecto.
40
Tema 01: Introduccin a las Mtricas

La medicin permite obtener la visin del proceso y el proyecto
pues proporciona un mecanismo para lograr una evaluacin
objetiva. Lord Kevin dijo una vez:
Cuando puede medir aquello de lo que est hablando y
expresarlo en nmeros sabe algo acerca de ello, pero cuando
no puede medir, cuando no puede expresarlo en nmeros, su conocimiento es escaso,
deficiente; puede ser el comienzo del conocimiento, pero, en sus pensamientos,
apenas est avanzando el mbito de la ciencia.
La comunidad de la ingeniera del software ha

tomado en serio las palabras de Lord Kelvin.
Ms no sin frustracin y algo ms que un poco
de controversial. La medicin se aplica al
proceso
de
software
con
la
finalidad
de
mejorarlo de manera continua. La medicin se utiliza a lo largo de un proyecto de

software como apoyo en la estimacin, el control de calidad, la valoracin de la
productividad y el control del proyecto. Finalmente, la medicin la aplican los
ingenieros de software como auxiliar en la evaluacin de la calidad de los productos de
trabajo y para apoyar la toma de decisiones conforme avanza en un proyecto.
En su gua acerca de la medicin de software, Park, Goethert y Florac apuntan las

razones por las que se mide: 1) para caracterizar en un esfuerzo por comprender
acerca de los procesos, productos, y entornos, y para establecer lneas base para
comparaciones con evaluaciones futuras; 2) para evaluar determinando el estado
con respecto a los planes; 3) para predecir mediante la compresin de relaciones
entre procesos y productos y construir modelos de dichas relaciones; y 4) para
mejorar al identificar barricadas, causas raz, ineficiencias y otras oportunidades para
mejorar la calidad del producto y el desempeo del proceso.
41
La medicin es una herramienta de gestora. Si se lleva a cabo gradualmente

proporciona visin al gestor del proyecto. Y, como resultado, apoya al gestor del
proyecto y al equipo de software a tomar decisiones que conducirn a un proyecto
exitoso. Una mtrica es una metodologa de planificacin, desarrollo y mantenimiento
de sistemas de informacin. Esta metodologa propia est basada en el modelo de
procesos del ciclo de vida de desarrollo
Procesos principales de la mtrica
Planificacin de Sistemas de Informacin (PSI).
Desarrollo de Sistemas de Informacin (DSI). Debido a su complejidad, est a su

vez dividido en cinco procesos:
Estudio de Viabilidad del Sistema (EVS).
Anlisis del Sistema de Informacin (ASI).
Diseo del Sistema de Informacin (DSI).
Construccin del Sistema de Informacin (CSI).
Implantacin y Aceptacin del Sistema (IAS).
Mantenimiento de Sistemas de Informacin (MSI).
Interfaces de las Mtricas

Las mtricas proporcionan tambin cuatro interfaces que definen actividades
orientadas a la mejora y perfeccionamiento de los procesos principales para garantizar
la consecucin del objetivo del desarrollo.
Los procesos principales de una mtrica son:
Gestin de proyectos (GP).
Seguridad (SEG).
Aseguramiento de la Calidad (CAL).
Gestin de la Configuracin (GC).
Tcnicas de las Mtricas

Las mtricas se distinguen entre:
Tcnicas de desarrollo (Casos de Uso, Diagramas de Clases, Diagrama de flujo

de datos, etc.).
Tcnicas de gestin de proyectos (Tcnicas de estimacin, Staffing Size,

Planificacin, etc.)
Prcticas (Anlisis de impacto, Presentaciones, Prototipado, etc.)
42
Perfiles de una mtrica

Una mtrica establece los siguientes perfiles para los participantes en el proceso de
desarrollo de un sistema de informacin:
Directivo (Comit de Direccin, Directores de Usuarios,...).
Jefe de Proyecto (Responsable de Implantacin, Responsable de
Seguridad,...).
Consultor (Consultor Informtico, Tcnico de Sistemas).
Analista (Analista, Administrador de Bases de Datos,...).
Programador.
Mtricas en los dominios del proceso y el proyecto

Las mtricas del proceso se recopilan en el curso de todos
los proyectos durante largos periodos. Su objetivo es
proporcionar un conjunto de indicadores de proceso que
conduzcan a la mejora de los procesos de software de largo
plazo.
Las mtricas del proyecto permiten que un gestor de proyecto de software 1) valor el
estado de un proyecto en curso; 2) rastree los riegos potenciales; 3) descubra las
reas problema antes de que se vuelvan crticas; 4) ajusto el flujo de trabajo o las
tareas, y 5) evale la habilidad del equipo del proyecto para controlar la calidad de los
productos de trabajo del software.
Las medidas que recopila un equipo de proyecto y las que

convierte en mtricas para emplearlas durante un proyecto
tambin
se
pueden
transmitir
quienes
tienen
la
responsabilidad de mejorar el proceso de software. Por esta

razn, muchas de las mismas mtricas se usan tanto en el
dominio del proceso como en el del proyecto.
43
Mtricas de
Proceso
TEMA 2
Competencia:
Reconocer los principales factores que
influyen en los procesos de desempeo
organizacional.
44
Tema 02: Mtricas de Proceso

La nica forma racional de mejorar cualquier proceso es
medir sus atributos especficos, desarrollar un conjunto
de mtricas significativas con base en dichos atributos y
luego emplear las mtricas de software y su impacto en la
mejora del proceso del software es importante destacar que el
proceso slo es uno de varios factores controlables en la mejora de la calidad del
software y el desempeo organizacional.
La eficacia de un proceso de software se mide indirectamente. Esto es, se deduce un

conjunto de mtricas basadas en los resultados que derivan del proceso. Los
resultados incluyen medidas de los defectos que se detectan y reportan los usuarios
finales, los productos de trabajo entregados (productividad), el esfuerzo humano
gastado, el tiempo consumido de la planificacin, concordancia con la planificacin y
otras medidas. Tambin se deducen mtricas de proceso al medir las caractersticas
de tareas especificadas de ingeniera de software.
Grady argumenta que existen usos privados y pblicos para diferentes tipos de datos
de proceso. Como es natural que los ingenieros de software especiales sean sensibles
al uso de las mtricas recopiladas sobre una base particular, dichos datos deben de
ser privados para el individuo y funcionar como un indicador slo para l. Los ejemplos
de mtricas privadas incluyen ndices de defecto por individuo, ndices de defecto por
componente de software y errores encontrados durante el desarrollo.
45
La filosofa de datos de proceso privados se ajusta bien al enfoque de proceso

personal del software que propone Humphrey. Humphrey reconoce que la mejora en el
proceso de software puede y debe comenzar en el nivel individual. Los datos de
proceso privados pueden funcionar como un importante promotor para que el trabajo
individual del ingeniero de software mejore.
Algunas mtricas de proceso son privadas para el

equipo del proyecto de software, pero pblicas
para todos los miembros del equipo. Los ejemplos
incluyen defectos que reportan las grandes
funciones de software (las cuales desarrollaron
varios profesionales), errores detectados durante
las revisiones tcnicas formales y lneas de cdigo
o puntos de funcin por mdulo o funcin. Dichos datos los revisa el equipo para
descubrir indicadores que mejoren su desempeo.
Las mtricas pblicas por lo general asimilan informacin que originalmente era
privada para los individuos y equipos. Los ndices de defecto al nivel del proyecto (que
no se atribuyen por ningn motivo a un individuo), esfuerzo, planificacin y datos
relacionados se recopilan y evalan con la finalidad de descubrir indicadores que
pueden mejorar el desempeo del proceso organizacional.
46
Las mtricas del proceso de software ofrecen beneficios significativos conforme una
organizacin que trabaja en mejorar su grado global de madurez del proceso. Sin
embargo, como todas las mtricas, stas pueden emplearse mal y crear ms
problemas de los que solucionan. Grady sugiere un conjunto de reglas de etiqueta
para las mtricas del software, adecuado tanto para gestores como para
profesionales conforme instituyen un programa de mtricas del proceso:
Aplique sentido comn y sensibilidad organizativa cuando interprete dichos datos

mtricos.
Ofrezca retroalimentacin regular a los individuos y equipos que recopilan

medidas y mtricas.
No utilice las mtricas para evaluar a los individuos.
Trabaje con los profesionales y equipos para

establecer metas claras y las mtricas que se
emplearn para conseguirlas.
Nunca use mtricas para amenazar a los

individuos o equipos.
Los datos mtricos que indican un rea

problema no deben considerarse negativos. Dichos datos slo son un indicador
de la mejora del proceso.
No se obsesione con una sola mtrica y excluya otras mtricas importantes.
Conforme una organizacin se siente ms cmoda con la

recopilacin y el empleo de las mtricas de proceso, la
deduccin de indicadores simples da la pauta para un
enfoque ms riguroso llamado mejora estadstica del
proceso del software (MEPS). En esencia, el MEPS aplica
el anlisis de la falla del software para recopilar informacin acerca de todos los
errores y defectos que se encuentran al desarrollar y utilizar una aplicacin, sistema o
producto.
47
Mtricas
TEMA 3
de
Proyecto
Competencia:
Analizar las tendencias de un proyecto para
planificar las mejoras correspondientes,
evaluando la informacin adquirida.
48
Tema 03: Mtricas de Proyecto

A diferencia de las mtricas del proceso de software que se utilizan con propsitos
estratgicos, las mtricas del proyecto de software son tcticas. Es decir, un gerente
de proyecto y un equipo de software emplean las mtricas del proyecto y los
indicadores que se deducen de ellas para adaptar el flujo de trabajo del proyecto y las
actividades tcnicas.
La primera aplicacin de las mtricas del proyecto en la

mayora de proyectos de software ocurre durante la
estimacin. Las mtricas recopiladas de los proyectos
previos se aprovechan para el trabajo de software actual.
Conforme el proyecto avanza, las medidas de esfuerzo y
tiempo utilizadas se comparan con las estimaciones originales
(y la planificacin del proyecto). El gestor del proyecto emplea dichos datos para
supervisar y controlar el progreso.
Mientras comienza el trabajo tcnico, las otras medidas del proyecto comienzan a
tener significado. Se miden los ndices de produccin representados en trminos de
modelos creados, horas de revisin, puntos de funcin y lneas fuente entregadas.
49
Adems se les da seguimiento a los errores descubiertos

durante cada tarea de ingeniera del software. Conforme el
software evoluciona desde los requisitos hasta el diseo, se
recopilan mtricas tcnicas para valorar la calidad del
diseo y mejorar los indicadores que influirn en el enfoque
que se adopte para la generacin y prueba del cdigo. La
finalidad de las mtricas del proyecto es doble. Primero, se emplean para minimizar el
tiempo de desarrollo haciendo los ajustes necesarios para evitar demoras y reducir los
problemas y riesgos potenciales. Segundo, se utilizan para valorar la calidad del
producto sobre una base actual y, cuando es necesario, modificar el enfoque tcnico
para mejorar la calidad. Conforme la calidad mejora los defectos se minimizan, y
mientras eso sucede tambin se reduce la cantidad de reelaboracin requerida
durante el proyecto. Esto conduce una reduccin en el costo global del proyecto.
MEDICIN EL SOFTWARE
La medicin de software se clasifica en dos categoras 1) medidas directas del
proceso de software (por ejemplo, costo y esfuerzo aplicados) y del producto (por
ejemplo, lneas de cdigo producidas, rapidez de ejecucin y defectos reportados a lo
largo de cierto periodo establecido) y 2) medidas indirectas del producto que incluyen
funcionalidad,
calidad,
complejidad,
eficiencia,
confiabilidad,
facilidad
de
mantenimiento y otras habilidades. Las mtricas del proyecto se consolidan con el fin
de crear mtricas del proceso que sean pblicas para la organizacin de software
como un todo. Pero cmo combina una organizacin las mtricas provenientes de
diferentes individuos o proyectos?
Con fines ilustrativos, considrese un ejemplo simple. Los integrantes de dos

diferentes equipos de proyecto registran y categorizan los errores que encuentran
durante el proceso del software. Luego, las mediciones individuales se combinan para
desarrollar medidas de equipo. El equipo A encontr 342 errores durante el proceso
del software previo al lanzamiento. El equipo B encontr 184 errores. Si todas las
dems cosas se mantienen iguales, qu equipo es ms eficiente al descubrir errores
a lo largo del proceso? Puesto que no se conoce ni el tamao ni la complejidad de los
proyectos, no se puede responder esta pregunta. Sin embargo, si las mediciones se
normalizan, es posible crear mtricas de software que posibiliten la comparacin a
promedios organizacionales ms amplios. De esta forma, las mtricas orientadas tanto
al tamao como a la funcin estn normalizadas.
50
Mtricas
Orientadas
al Tamao
TEMA 4
Competencia:
Evaluar la productividad mediante el
tamao del software a travs de las lneas de
cdigo y la calidad de una aplicacin a travs
de los puntos de funcin.
51
Tema 04: Mtricas Orientadas al Tamao

Las mtricas
del software
orientadas al tamao
preceden de la normalizacin de las medidas de calidad

o productividad considerando el tamao del software
que se ha producido. Si una organizacin de software
mantiene registros simples es factible crear una tabla de
medidas orientadas al tamao, como se muestra en la
siguiente tabla a continuacin. En dicha tabla se menciona cada proyecto de desarrollo
de software que se ha completado en aos pasados, as como las medidas
correspondientes para dichos proyectos. Como se advierte en la entrada de la tabla,
para el proyecto Alfa: 12 100 lneas de cdigo se desarrollaron con 24 personas-mes
de esfuerzo a un costo de 168 000 dlares.
Se debe notar que el esfuerzo y el costo

registrados en la tabla representan todas las
actividades de ingeniera de software (anlisis,
diseo, cdigo y prueba), no slo codificacin.
Informacin adicional del proyecto Alfa indica que
se desarrollaron 365 pginas de documentacin,
se registraron 134 errores antes de que el software fuese liberado y se encontraron 29
defectos despus de la liberacin al cliente dentro del primer ao de operacin. Tres
personas trabajaron en el desarrollo del software para el proyecto alfa.
El desarrollo de mtricas que se asimilen con las mtricas similares procedentes de

otros proyectos requiere elegir lneas de cdigo como valor de normalizacin. A partir
de los datos rudimentarios de la tabla se desarrolla un conjunto de mtricas simples
orientadas al tamao para cada proyecto: errores por KLDC (miles de lneas de
cdigo), defectos por KLDC, costo por KLDC, pginas de documentacin por KLDC.
Adems se pueden calcular otras mtricas interesantes: errores por persona-mes,
KLDC por persona-mes, costo por pgina de documentacin.
52
MTRICAS ORIENTADAS AL TAMAO

Proyecto
Alfa
Beta
Gamma
LDC
12100
27200
20200
Esfuerzo
24
62
43
$(000)
168
440
314
Pg. Doc.
365
1224
1050
Errores
134
321
256
Defectos
29
86
64
Personal
3
5
6
Las mtricas orientadas al tamao no se aceptan universalmente como la mejor forma

de medir el proceso del software. La mayor parte de la controversia gira en torno al
uso de lneas de cdigo como medida clave. Los partidarios de la medida LDC afirman
que stas son un artefacto de todos los proyectos de desarrollo de software que
pueden fcilmente contarse, que muchos modelos de estimacin de software
existentes usan LDC o KLDC como entrada clave, y que ya existe un gran cuerpo de
bibliografa y datos publicados para LDC.
Por otra parte, los detractores argumentan que las medidas LDC dependen del
lenguaje de programacin, que, cuando se considera la productividad, castigan los
programas bien diseados, pero ms cortos, que no pueden amoldar con facilidad
lenguajes que no provienen del proceso y cuyo empleo en la estimacin requiere un
nivel de detalle que sera difcil de lograr (es decir, el planificador debe estimar que las
LDC se producirn mucha antes que el anlisis y el diseo se hayan completado).
MTRICAS ORIENTADAS A LA FUNCIN

Las mtricas de software orientadas a la funcin emplean como
un valor de normalizacin una medida de la funcionalidad que
entrega la aplicacin. La mtrica orientada a la funcin
utilizada con mayor amplitud es el punto de funcin (PF).
El clculo del punto de funcin se basa en caractersticas del
dominio de informacin y la complejidad del software.
53
El punto de funcin, al igual que la medida LDC, es controversial. Los partidarios

afirman que el PF es independiente del lenguaje de programacin, caracterstica que
lo hace ideal para aplicaciones que utilizan lenguajes convencionales y no
procedimentales, y que se basa en datos que es ms probable que se conozcan
temprano en la evolucin de un proyecto, lo que hace al PF ms atractivo como
enfoque de estimacin. Los detractores afirman que el mtodo requiere cierta
prestidigitacin en cuanto a que el clculo se basa en los datos subjetivos ms que
objetivos, que el conteo del dominio de informacin (y otras dimensiones) puede ser
difcil de recopilar despus del hecho, y que el PF no tiene significado directo: es slo
un nmero.
RECONCILIACIN DE LAS MTRICAS LDC Y PF

La relacin entre lneas de cdigo y puntos de funcin
depende del lenguaje de programacin en que se
implementen el software y la calidad del diseo. Varios
estudios han intentado relacional las medidas de PF y
LDC. Por ejemplo Albrecth y Gaffney: La tesis de este
trabajo es que la calidad de funcin que se ofrecer por medio de la aplicacin
(programa) se puede estimar a partir de pormenorizar los grandes componentes de
datos que se emplearn o proporcionarn. Ms an, est estimacin de la funcin
debe estar correlacionada tanto con la cantidad de LDC que se desarrollar como con
el esfuerzo de desarrollo necesario.
La tabla siguiente ofrece estimaciones burdas del nmero promedio de lneas de

cdigo que se requieren para construir un punto de funcin en varios lenguajes de
programacin Una revisin de estos datos indica que una LDC de C++ proporciona
aproximadamente 2.4 veces la funcionalidad al menos cuatro veces la funcionalidad
de una LDC de un lenguaje de programacin convencional como Ada, COBOL o C. La
utilizacin de la informacin contenida en la tabla permite tomar como contrafuego el
software existe para estimar el nmero de puntos de funcin, una vez que se conozca
el nmero total de enunciados del lenguaje de programacin. Se ha encontrado que
las mtricas basadas en puntos de funcin y LDC son indicadoras relativamente
precisas del esfuerzo y el costo del desarrollo del software. Sin embargo, emplear LCD
y PF en la estimacin requiere establecer una lnea de referencia histrica de
informacin.
54
En el contexto del proceso y las mtricas del proyecto, la preocupacin

principal la generan la productividad y la calidad: medidas de la salida
de desarrollo de software como funcin del esfuerzo y el tiempo
aplicado y medidas de la aptitud para el uso de los productos de
trabajo obtenidos. Respecto a propsitos de mejora del proceso y planeacin del
proyecto, el inters es histrico. Cul fue la productividad de desarrollo del software
en los proyectos pasados? Cul fue la calidad del software que se produjo? Cmo
se pueden extrapolar al presente la productividad y la calidad pasadas? Cmo puede
ayudar a mejorar el proceso y planificar nuevos proyectos con mayor precisin?
LNEAS DE COMANDOS
Lenguaje de
programacin
Access
Ada
APS
ASP 69
Ensamblador
C
C++
Clipper
COBOL
Cool: Gen/IEF
Culprit
DBase IV
Easytrieve 1
Excel 47
Focus
FORTRAN
Foxpro
Ideal
IEF/Cool:Gen
Informix
Java
JavaScript
JCL
JSP
Lotus Notes
Mantis
Mapper
Natural
Oracle
PeopleSoft
Perl
PL/1
PowerBuilder
REXX
RPG II/III
SAS
Smalltalk
SQL
VBScript36
Visual Basic
LDC por punto de funcin

Promedio
35
154
86
62
337
162
66
38
77
38
51
52
33
46
43
32
66
38
42
63
58
91
59
21
71
118
60
30
33
60
78
32
67
61
40
26
40
34
47
Mediana
38
83
315
109
53
39
77
31
34
42
35
52
31
31
53
63
123
22
27
81
52
35
32
67
31
49
41
19
37
27
42
Bajo
15
104
20
32
91
33
29
27
14
10
25
31
32
25
34
10
24
77
42
26
15
22
16
22
4
30
22
11
24
33
10
7
50
16
Alto
47
205
184
127
127
704
178
70
400
180
41
63
56
35
203
180
57
75
150
25
250
245
141
217
40
263
105
155
49
55
110
158
55
INGENIERA DEL SOFTWARE MTRICA - DESARROLLO DE SISTEMAS DE

INFORMACIN
http://www.slideshare.net/LuisEduardoPelaez/mtrica-desarrollo-de-sistemas-deinformacin
MTRICAS, ESTIMACIN Y PLANIFICACIN EN PROYECTOS

http://www.willydev.net/descargas/WillyDEV_PlaneaSoftware.Pdf
1. En un documento en Word indique las mtricas del proceso y

mejora de un sistema de comercializacin para una tienda de
computadoras tambin determine las mtricas orientadas a la
funcin, adems mencione y describa el proceso realizado para
dicho caso.
Envalo a travs de "Mtricas".
2. En un documento en Word indique cules son las mtricas

apropiadas para el proceso y para el producto; y elabore un
ejemplo donde se empleen ambas.
Envalo a travs de "Mtricas Apropiadas".
3.
56
Autoevaluacin
1) Las mtricas pblicas por lo general asimilan informacin que

__________________________. Los ndices de defecto al nivel del proyecto
(que no se atribuyen por ningn motivo a un individuo), esfuerzo,
planificacin y datos relacionados se recopilan y evalan con la finalidad de
descubrir indicadores que pueden mejorar el desempeo del proceso
organizacional.
a. Originalmente era tradicional para los individuos y equipos.
b. Originalmente era privada para los individuos y equipos.
c. Originalmente era creada para los individuos y equipos.
d. Originalmente era digital para los individuos y equipos.
e. Originalmente era prediseada para los individuos y equipos.
2) El equipo de proyecto se centra en:
a. Controlar la calidad de los miembros del equipo.
b. Controlar la calidad de los productos de trabajo del software.
c. Reconocer los riesgos y oportunidades del proyecto.
d. Generar la mayor cantidad de lneas de cdigo.
e. Administrar los recursos reutilizables en un proyecto.
3) No corresponde a los perfiles de una mtrica:
a. Directivo (comit de direccin, directores de usuarios).
b. Jefe de proyecto (responsable de implantacin, responsable de seguridad).
c. Consultor (consultor informtico, tcnico de sistemas).
d. Programador (diseo de planificaciones del directivo).
e. Analista (analista, administrador de bases de datos).
4) La filosofa de Humphrey con respecto a los datos de proceso privados se
centra en:
a. Ayudar a comprender los valores ticos para que la funcin del ingeniero
mejore.
b. Alentar para que el trabajo individual del ingeniero del software mejore.
c. Incentivar a generar mayores ingresos para la organizacin del software.
d. Proyectar a controlar la piratera y mejorar las funciones del software.
e. Apoyar para que el trabajo en equipo del ingeniero mejore significativamente.
5) No es una sugerencia de Grady:
a. Aplicar sentido comn y sensibilidad organizativa cuando se interprete datos
mtricos.
b. Ofrecer retroalimentacin regular a los individuos y equipos que recopilan
medidas y mtricas.
c. No utilizar las mtricas para evaluar a los individuos.
d. Trabajar con los profesionales y equipos para establecer metas claras.
e. Usar mtricas para amenazar a los individuos o equipos.
57
6) Adaptan el flujo de trabajo del proyecto y las actividades tcnicas:

a. Las mtricas del proyecto.
b. Las planificaciones de las mtricas.
c. Las mtricas de software.
d. El equipo de software.
e. Las mtricas del cronograma.
7) Es una de las finalidades de las mtricas del proyecto:
a. Valorar slo la calidad del producto.
b. Reducir los problemas, riesgos potenciales y valorar la calidad del producto
sobre una base actual.
c. Resolver los percances mientras que dura un proyecto.
d. Omitir los problemas con el fin valorar la calidad del producto sobre una base
actual.
e. Realizar un plan de respuesta de riesgos potenciales.
8) La primera aplicacin de las mtricas en un proyecto ocurre con:
a. La valorizacin.
b. La depreciacin.
c. La estimacin.
d. El alcance.
e. El propsito.
9) Cul es la medida clave de las mtricas orientadas al tamao?
a. PF (Punto de funcin).
b. EU(Esfuerzo utilizado).
c. LDC (Lnea de cdigos).
d. PP (Parmetro de productividad).
e. DP (duracin del proyecto).
10) Cul es la medida clave de las mtricas orientadas a la funcin?
a. FL (Funcin lgica).
b.
c.
d.
e.
TD(tiempo de duracin del proyecto).

PF (Punto de funcin).
LDC (Lnea de cdigos).
EF (Esfuerzo utilizado).
58
Resumen
UNIDAD DE APRENDIZAJE II:
La comunidad de la ingeniera del software ha tomado en serio las palabras de Lord

Kelvin. Ms no sin frustracin y algo ms que un poco de controversial.
La medicin se aplica al proceso de software con la finalidad de mejorarlo de manera
continua. La medicin se utiliza a lo largo de un proyecto de software como apoyo en
la estimacin, el control de calidad, la valoracin de la productividad y el control del
proyecto. Finalmente, la medicin la aplican los ingenieros de software como auxiliar
en la evaluacin de la calidad de los productos de trabajo y para apoyar la toma de
decisiones conforme avanza en un proyecto.
La eficacia de un proceso de software se mide indirectamente. Esto es, se deduce un

conjunto de mtricas basadas en los resultados que derivan del proceso. Los
resultados incluyen medidas de los defectos que se detectan y reportan los usuarios
finales, los productos de trabajo entregados (productividad), el esfuerzo humano
gastado, el tiempo consumido de la planificacin, concordancia con la planificacin y
otras medidas. Tambin se deducen mtricas de proceso al medir las caractersticas
de tareas especificadas de ingeniera de software.
La primera aplicacin de las mtricas del proyecto en la mayora de proyectos de

software ocurre durante la estimacin. Las mtricas recopiladas de los proyectos
previos se aprovechan para el trabajo de software actual. Conforme el proyecto
avanza, las medidas de esfuerzo y tiempo utilizadas se comparan con las
estimaciones originales (y la planificacin del proyecto). El gestor del proyecto emplea
dichos datos para supervisar y controlar el progreso.
El desarrollo de mtricas que se asimilen con las mtricas similares procedentes de

otros proyectos requiere elegir lneas de cdigo como valor de normalizacin. A partir
de los datos rudimentarios de la tabla se desarrolla un conjunto de mtricas simples
orientadas al tamao para cada proyecto: errores por
KLDC (miles de lneas de
cdigo), defectos por KLDC, costo por KLDC, pginas de documentacin por KLDC.
Adems se pueden calcular otras mtricas interesantes: errores por persona-mes,
KLDC por persona-mes, costo por pgina de documentacin.
59
60
Introduccin
a) Presentacin y contextualizacin
Los temas que se tratan en la presente unidad didctica, tienen por finalidad que el
estudiante aprenda cmo se realiza el proceso de gestin del proyecto de software y
qu importancia juega en el desarrollo de cualquier proyecto.
Comprender que la estimacin es la base de todas las dems actividades en
planificacin de un proyecto y sirve como una gua para una buena ingeniera del
software, no es en absoluto aconsejable embarcarse sin ella.
Adquirir experiencia, buena informacin histrica y buenas tcnicas de estimacin.
b) Competencia
Planifica
la
forma
de
realizar
estimaciones
mediante
tcnicas
de
descomposicin, tamao de software, lneas de cdigo y funciones.
c) Capacidades
1. Desarrolla las estimaciones necesarias aplicando las medidas y el software
adecuado.
2. Administra los componentes del software reutilizable, el entorno de desarrollo
de un proyecto y el personal segn las habilidades requeridas.
3. Analiza estimaciones mediante las tcnicas de descomposicin y tamao del
software.
4. Reconoce las principales funciones de las estimaciones de LDC y PF.
d) Actitudes
Desarrolla la creatividad, la innovacin, la actitud emprendedora y el respeto a
la honestidad intelectual.
Muestra una actitud emprendedora mediante la toma de iniciativas, promocin
de actividades y toma de decisiones en relacin a la actividad asignada.
e) Presentacin de Ideas bsicas y contenido esenciales de la Unidad:

La Unidad de Aprendizaje 03: Estimacin para Proyectos de Software,
TEMA 01: Introduccin a la Estimacin de Proyectos de Software.

TEMA 02: Recursos de Software.
TEMA 03: Estimacin de Proyectos.
TEMA 04: Estimacin Basada en Problemas.
61
Introduccin
TEMA 1
a la Estimacin
de Proyectos de
Software
Competencia:
Desarrollar las estimaciones necesarias
aplicando las medidas y el software
adecuado.
62
Tema 01: Introduccin a la Estimacin de

Proyectos de Software
La planificacin requiere que los gestores tcnicos y los miembros del equipo de
software establezcan un compromiso inicial, aun cuando
sea probable que este compromiso pruebe estar
equivocado. Siempre que se realizan estimaciones se
atisba al futuro y se acepta automticamente algn grado
de incertidumbre. Para citar a Frederick Brooks:
Nuestras
tcnicas
de
estimacin
estn
probablemente
desarrolladas.
Ms
seriamente, reflejan una suposicin no expresada que es bastante incierta, es decir:

que todo ir bien
Puesto que no estamos seguros de nuestras estimaciones, con frecuencia los

gestores
software
carecen
de
la
corts
testarudez para hace que la gente haga un buen

producto.
Aunque la estimacin es tanto un arte como una
ciencia, esta importante actividad no necesita
realizarse en una forma improvisada. Existen tcnicas tiles para la estimacin de
tiempo y esfuerzo. Las mtricas del proceso y del proyecto ofrecen la perspectiva
histrica y la energa para la generacin de estimaciones cuantitativas. La experiencia
(de toda la gente involucrada) puede auxiliar enormemente conforme se desarrollan y
revisan las estimaciones. Puesto que la estimacin coloca los cimientos para las
dems actividades de planificacin del proyecto, y sta proporciona la ruta para las
dems actividades de planificacin del proyecto, y sta proporciona la ruta para la
ingeniera del software exitosa, se estara mal aconsejando si se embarca sin ella.
La estimacin de recursos, costo y programa de trabajo para una tarea de ingeniera

de software requiere experiencia, acceso a buena informacin histrica (mtricas) y el
valor para comprometerse con predicciones cuantitativas cuando la informacin
cualitativa es todo lo que existe. La estimacin implica riesgo inherente, y ste
conduce a la incertidumbre.
63
La disponibilidad de informacin histrica tiene una fuerte

influencia en el riesgo de la estimacin. Al mirar en retrospectiva,
se pueden emular las cosas que funcionaron y mejorar las reas
donde surgieron los problemas. Cuando hay disponibles amplias
mtricas de software de proyectos previos, las estimaciones se hacen con mayor
seguridad, los programas de trabajo se pueden establecer para evitar dificultades
pasadas y el riesgo global se reduce.
El riesgo de la estimacin se mide por el grado de incertidumbre en las estimaciones

cuantitativas establecidas para recursos, costos y programa de trabajo. Si el mbito
del proyecto se comprende en forma deficiente o los requisitos del proyecto estn
sujetos a eventuales cambios, la incertidumbre y el riesgo de la estimacin se
incrementan peligrosamente. El planificador y, en forma ms importante, el cliente
deben reconocer que la variabilidad en los requisitos del software significa
inestabilidad en costo y programa de trabajo. Sin embargo, un gestor de proyecto no
debe obsesionarse con las estimaciones. Los modernos enfoques de la ingeniera del
software (por ejemplo, modelos de proceso incrementar) asumen una visin iterativa
del desarrollo. En tales enfoques es
posible, aunque no siempre aceptable
polticamente, reexaminar las estimaciones (cuando se conozca ms informacin) y

modificarlas cuando el cliente cambia los requisitos.
El proceso de planificacin del proyecto.

El objetivo de la planificacin del proyecto de software
es proporcionar un marco de trabajo que permita al
gestor estimar razonablemente recursos, costo y
programa de trabajo. Adems, las estimaciones
deben intentar definir los escenarios de mejor y peor
caso de modo que los resultados del proyecto se
pueden acortar. Aunque existe un grado inherente de incertidumbre, el equipo de
software se embarca en un plan establecido como consecuencia de las tareas de
planificacin. Por lo tanto, el plan se debe adaptar y actualizar conforme avance el
proyecto. En las secciones siguientes se estudiar cada una de las actividades
asociadas con la planificacin del proyecto de software.
64
mbito del software y factibilidad

El mbito del software describe las funciones y caractersticas que se entregarn a los
usuarios finales, los datos que son de entrada y salida, el contenido que se presenta
a los usuarios como consecuencia de emplear el software, as como el desempeo,
las restricciones, las interfaces y la confiabilidad que
acotan el sistema. El mbito se define al usar una
de las dos tcnicas siguientes:
1. Despus de una comunicacin con todos los
participantes se desarrolla una descripcin narrativa del mbito del software.
2. Los usuarios finales desarrollan un conjunto de casos de uso.
Las funciones descritas en el enunciado del mbito (o dentro

de los casos de uso) se evalan y en algunos casos se refinan
para proporcionar ms detalles antes de comenzar la
estimacin. Puesto que las estimaciones de costo y programa
de trabajo estn funcionalmente orientadas, con frecuencia es
til cierto grado de descomposicin. Las consideraciones del
desempeo abarcan los requisitos del procesamiento y tiempo
de respuesta. Las restricciones identifican los lmites colocados
con el software por el hardware externo, la memoria disponible u otros sistemas
existentes.
Una vez identificado el mbito (con la participacin del

cliente) es razonable preguntar: es posible construir
software para satisfacer este mbito? El proyecto es
factible? Con mucha frecuencia los ingenieros de
software soslayan estas preguntas (o gestores o clientes
impacientes los presionan para hacerlo), slo para verse
enredados en un proyecto condenado al fracaso.
65
Putnam y Myers abordan este conflicto cuando escriben:

No todo lo imaginable es factible, incluso ni el software, evanescente como puede
parecer a los extraos. Por el contrario, la factibilidad del software tiene cuatro
dimensiones slidas: Tecnologa: El proyecto es
tcnicamente factible? Est dentro del terreno de
la disciplina? Los defectos se pueden reducir a tal
grado que se emparejen con las necesidades de la
aplicacin?
Finanzas:
Es
financieramente
factible? Se puede completar el desarrollo a un

costo que la organizacin del software, su cliente o
el mercado puedan enfrentar? Tiempo: El proyecto llegar al mercado antes y
vencer a la competencia? Recurso: La organizacin tiene los recursos necesarios
para triunfar? Putnam y Myers sugieren, acertadamente, que el mbito no es
suficiente. Una vez que el mbito se comprende, el equipo del software y otros deben
trabajar para determinar si se puede hacer dentro de las dimensiones anotadas lneas
arriba. sta es una parte crucial, aunque con frecuencia ignorada, del proceso de
estimacin.
66
Recursos
de Software
TEMA 2
Competencia:
Administrar los componentes del software
reutilizable, el entorno de desarrollo de un
proyecto y el personal segn las habilidades
requeridas.
67
Tema 02: Recursos de Software

La segunda tarea de la planificacin es la estimacin de los recursos necesarios para
completar el esfuerzo de desarrollo del software. La siguiente
figura muestra las tres grandes categoras de los recursos de
ingeniera del software: personal, componentes de software
reutilizables y el entorno de desarrollo (hardware y herramientas
de
software).
Cada
recurso
se
especifica
con
cuatro
caractersticas: descripcin del recurso; un informe de disponibilidad;

cundo se requerir el recurso; tiempo durante el cual el recurso se aplicar. Las
ltimas dos caractersticas se pueden ver cmo una ventana de tiempo. La
disponibilidad del recurso para una ventana especfica debe establecerse lo ms
pronto posible.
68
Recursos Humanos
El planificador comienza evaluando el mbito del software y seleccionando las
habilidades requeridas para completar el desarrollo. Se especifican tanto la posicin
organizacional (por ejemplo, gestor, ingeniero e software ejecutivo) como la
especialidad (por ejemplo, telecomunicaciones, base de datos, cliente/servidor). En
proyectos relativamente pequeos (unos pocos persona-meses) un solo individuo
puede realizar todas las tareas de ingeniera de software y consultar con especialistas
conforme se requiera. En proyectos mayores
el
equipo
de
software
puede
estar
geogrficamente disperso en varios sitios.

Aqu se especifica la ubicacin de cada
recurso humano.
El nmero de personas que requiere un proyecto de software slo se determina
despus de que se ha hecho la estimacin del esfuerzo de desarrollo (por ejemplo,
personas-mes).
Recursos de software reutilizables

La ingeniera del software basada en componentes enfatiza la reutilizacin: es decir,
la creacin y reutilizacin de bloques de construccin de software. Tales bloques,
usualmente llamados componentes, deben catalogarse para consultarlos con
facilidad, estandarizarse para facilitar su aplicacin y validarse para integrarlos
fcilmente. Bennatan sugiere cuatro categoras de recursos de software que deben
considerarse conforme avanza la planificacin.
Componentes ya desarrollados. El software existente se puede adquirir de un tercero
o se desarroll internamente para un proyecto previo. Los CCYD (componentes
comerciales ya desarrollados) se compran de un tercero, estn listos para emplearlos
en el proyecto actual y han sido ampliamente validados.
Componentes ya experimentados. Especificaciones, diseos, cdigo o datos de

prueba existentes que se desarrollaron para proyectos previos son similares al
software que se construir para el proyecto actual. Los miembros del equipo de
software actual ya tienen experiencia en el rea de aplicacin que representan dichos
componentes. En consecuencia, las modificaciones que requieran los componentes
experimentados sern relativamente de bajo riesgo.
69
Componentes de experiencia parcial. Especificaciones, diseos, cdigo o datos de

prueba existentes que se desarrollaron para proyectos previos estn relacionados con
el software que se construir para el proyecto anual pero requerirn modificaciones
sustanciales. Los miembros del equipo de software actual slo tienen experiencia
limitada en el rea de aplicacin que representan dichos componentes. Por lo tanto,
las modificaciones que requieren los componentes de experiencia parcial tienen un
grado considerable de riesgo. Componentes nuevos. El equipo de software debe
construir los componentes de software debe construir los componentes de software
para las necesidades del proyecto actual. Irnicamente, con frecuencia los
componentes de software reutilizables son despreciados durante la planificacin, slo
para convertirse en una preocupacin importante durante la fase de desarrollo del
proceso de software. Es mejor especificar cuanto antes los requisitos de recursos de
software. De esta forma se puede llevar a cabo la evaluacin tcnica de las
alternativas y puede ocurrir la adquisicin oportuna.
Recursos de entorno
El entorno que soporta un proyecto de software, con frecuencia denominado entorno
de ingeniera del software (EIS), incorpora hardware y software. El hardware
proporciona una plataforma que soporta las herramientas (software) con que se
producen los productos de trabajo basados en una buena prctica de la ingeniera del
software. Puesto que la mayor parte de las organizaciones de software tienen
mltiples constituyentes que requieren acceso al EIS, el planificador de proyecto debe
prescribir la ventana de tiempo requerida por el hardware y el software, y verificar que
estos recursos estarn disponibles.
Cuando un sistema basado en computadora (que incorpora hardware y software

especializados) se someter a la ingeniera, el equipo de software quiz requiera
acceso a los elementos de hardware que estn desarrollando otros equipos de
ingeniera. Por ejemplo, el software de un contador numrico (CN) utilizado en un tipo
de mquinas-herramienta tal vez requiera una mquina-herramienta especfica (por
ejemplo, un CN de torno) como parte del paso de prueba de validacin; un proyecto
de software para plantilla de pgina avanzada quiz necesite una impresora de alta
calidad en algn punto durante el desarrollo. El planificador del proyecto de software
debe especificar cada elemento de hardware.
70
Estimacin
de Proyectos
TEMA 3
Competencia:
Analizar estimaciones mediante las tcnicas
de descomposicin y tamao del software.
71
Tema 03: Estimacin de Proyectos

El software es el elemento ms caro de virtualmente todos los sistemas basados en
computadora. En sistemas complejos, personalizados, un
gran error en la estimacin del costo puede hacer la
diferencia entre beneficio y prdida. Rebasar el costo puede
ser desastroso para el desarrollador.
La estimacin del costo y el esfuerzo nunca ser una ciencia exacta. Demasiadas
variables humanas, tcnicas, ambientales, polticas pueden afectar el costo final del
software y el esfuerzo aplicado a desarrollo. Sin embargo, la estimacin del proyecto
de software se puede transformar de una prctica oscura en una serie de pasos
sistemticos que proporcionan estimaciones con riesgo aceptable. Para lograr
estimaciones confiables de costo y esfuerzo se tienen varias opciones:
1. Demorar la estimacin hasta ms tarde en el proyecto (obviamente, se puede
lograr 100 por ciento de estimaciones precisas despus de que el proyecto est
terminado!)
2. Basar las estimaciones en proyectos similares que hayan sido completados.
3. Emplear tcnicas de descomposicin relativamente simples para generar
estimaciones de costo y esfuerzo del proyecto.
4. Utilizar uno o ms modelos empricos en la estimacin de costo y esfuerzo.
Desgraciadamente, la primera opcin, aunque atractiva, no es prctica. Las

estimaciones de costos tienen que proporcionar por adelantado. No
obstante se debe reconocer que, mientras ms se espere ms se
conocer, y mientras ms se conozca menos probable es que se
cometan serios errores en las estimaciones.
La segunda opcin puede funcionar razonablemente bien si el
proyecto en curso es muy similar a los previos y a otras influencias del proyecto (por
ejemplo, el equipo del software, el cliente, las condiciones del mercado, el EIS, las
fechas lmite) son aproximadamente equivalentes. Por desgracia, la experiencia no
siempre ha sido un buen indicador de los resultados futuros.
72
Las opciones restantes son los enfoques viables para la estimacin del proyecto de
software. Idealmente, las tcnicas mencionadas para cada
opcin deben aplicarse juntas, cada una empleada como una
marca de verificacin para la otra. Las tcnicas de
descomposicin asumen un enfoque de divide y vencers
respecto de la estimacin del proyecto de software. Al
descomponer
un
proyecto
en
funciones
principales
actividades de ingeniera del software relacionadas, las estimaciones de costo y

esfuerzo se pueden realizar en forma escalonada. Los modelos de estimacin
emprica son tiles para complementar las tcnicas de descomposicin y ofrecer un
enfoque de estimacin potencialmente valioso por su propio derecho. Cada una de las
opciones viables de estimacin de costo del software ser tan buena como los que
sean datos histricos en que se basa la estimacin. Si no existen datos histricos, la
estimacin del costo se basar en un fundamento muy tambaleante.
Tcnicas de descomposicin
La estimacin del proyecto de software es una forma de resolver problemas; en la
mayora de los casos, el problema que debe resolverse (es decir, el desarrollo de una
estimacin de costo y esfuerzo para un proyecto de software) es muy complejo como
para considerarlo una sola pieza. Por esta razn se descompone el problema,
recaracterizndolo
como
esperanzadoramente,
ms
un
conjunto
de
problemas
ms
manejable).
La
estimacin
puede
pequeos
emplear
(y,
la
descomposicin del problema, la descomposicin del proceso, o ambas formas de

particin. Pero antes que pueda realizarse una estimacin, el planificador del proyecto
debe entender el mbito del software que se construir y generar una estimacin de
su tamao
Tamao del software

La precisin de la estimacin de un proyecto de software se manifiesta en varios
factores: 1) el grado con el cual el planificador ha estimado adecuadamente el tamao
del producto que se construir; 2) la habilidad para traducir la estimacin del tamao
en esfuerzo humano, programa de trabajo y dinero (una funcin de la disponibilidad de
las mtricas de software confiables a partir de proyectos previos); 3) el grado en el
cual el plan del proyecto refleja las habilidades del equipo de software;
73
Y 4) la estabilidad de los requisitos del producto y el entorno que soporta el esfuerzo

de ingeniera del software.
En esta seccin se considera el problema del tamao del software. Puesto que la
estimacin de un proyecto slo es tan buena como la estimacin del tamao del
trabajo para realizarlo, el tamao representa el primer gran desafo del planificador del
proyecto. En el contexto de la planificacin del proyecto, tamao se refiere a un
resultado cuantificable del proyecto de software. Si se asume un enfoque directo, el
tamao se puede medir en lneas de cdigo (LDC).
Si se asume un enfoque indirecto, el tamao se representa como puntos de funcin

(PF).
Putnam y Myers sugieren cuatro diferentes enfoques al problema del tamao:
Tamao de lgica difusa. La aplicacin de este enfoque requiere que un

planificador identifique el tipo de aplicacin, establezca su magnitud en una
escala cualitativa y luego refine la magnitud dentro del rango original.
Tamao de punto de funcin. El planificador desarrolla estimaciones de las

caractersticas de dominio de la informacin.
Tamao de componentes estndar. El software se compone de varios

componentes estndar, los cuales son diferentes y
genricos de un rea particular de la aplicacin. Por
ejemplo, los componentes estndar de un sistema de
informacin son subsistemas, mdulos,
pantallas,
reportes, programas interactivos, programas por lotes,

archivos, LDC e instrucciones al nivel de objeto. El
planificador
del proyecto estima el nmero de
ocurrencias de cada componente estndar y luego aplica datos de proyectos

histricos para determinar el tamao de entrega por componente estndar.
Tamao del cambio: Este enfoque se aplica cuando un proyecto incluye la

utilizacin del software existente que debe modificarse en cierta forma como
parte de un proyecto. El planificador estima el nmero y tipo (por ejemplo,
reutilizacin, cdigo de adicin, cdigo de cambio, cdigo de borrado) de las
modificaciones que se debe lograr.
74
Estimacin
Basada en
Problemas
TEMA 4
Competencia:
Reconocer las principales funciones de las
estimaciones de LDC y PF.
75
Tema 04: Estimacin Basada en Problemas

Las lneas de cdigo y los puntos de funcin se utilizan en dos formas para estimar el
proyecto de software 1) como una variable de la estimacin para el
tamao de cada elemento del software, y 2) como mtricas de
lnea base recolectadas a partir de proyectos previos y utilizados en
conjuncin
con
variables
de
estimacin
para
desarrollar
proyecciones de costo y esfuerzo.
Las estimaciones de LDC y PF son distintas tcnica de

estimacin, aunque ambas tienen varias caractersticas en comn.
El planificador del proyecto comienza con un enfoque acotado del
mbito del software y a partir de ah intenta descomponer el
software
en
funciones
problema
que
puedan
estimarse
individualmente. Entonces se estiman las LDC o PF (las variables de estimacin) para

cada funcin. De manera alternativa, el planificador puede elegir otro componente
para tamao, como clases u objetos, cambios o procesos de negocios afectados
Entonces se aplican las mtricas de la lnea base de productividad (por ejemplo,
LDC/pm o PF/pm5) a la variable de estimacin apropiada, y se deriva el costo o
esfuerzo de la funcin. Las estimaciones de funcin se combinan para producir una
estimacin global del proyecto completo.
Sin embargo, es importante notar que con frecuencia existe una

dispersin sustancial en las mtricas de la productividad de una
organizacin, lo que hace sospechoso el uso de una sola mtrica
de lnea base de la productividad. En general, el dominio del
proyecto debe calcular los promedios LDC/pm o PF/pm. Es decir,
los proyectos deben agruparse por tamao de equipo, rea de
aplicacin, complejidad y otros parmetros relevantes. Luego se
tienen que calcular los promedios de dominio local. Cuando se
estima un nuevo proyecto primero debe ubicarse en un dominio, y
luego aplicar el promedio apropiado para lo productividad y as generar la estimacin.
76
Las tcnicas de estimacin LDC y PF difieren en cuanto al detalle requerido para la

descomposicin y el objetivo de la particin. Al emplear LDC como variable de
estimacin la descomposicin es absolutamente esencial y con frecuencia se lleva a
grados considerables de detalle. Mientras mayor sea el grado de particin es ms
probable que se desarrolle una estimacin razonablemente precisa de LDC.
En las estimaciones de PF la descomposicin funciona de manera diferente. Ms que
enfocarse sobre la funcin, se estima cada una de las cinco caractersticas de dominio
de informacin. Entonces se pueden utilizar estimaciones resultantes para derivar un
valor de PF que se pueda ligar a los datos previos y empleados para generar una
estimacin.
Sin importar la variable de estimacin que se utilice, el planificador del proyecto

comienza estimado una gama de valores para cada
funcin o valor de dominio de informacin. Al
emplear los datos histricos (cuando todo lo dems
falla) intuicin, el planificador estima un valor de
tamao optimista, ms probable y pesimista para
cada funcin o cuenta para cada valor de dominio
de informacin. Cuando se especifica un rango de
valores se proporciona un indicio implcito del grado de incertidumbre.
Entonces se puede calcular un valor de tres puntos o uno esperado. El valor esperado
para la variable de estimacin (tamao). S se calcula como un promedio ponderado
de las estimaciones optimista (Sopt), ms probable (Sm) y pesimista (Spes). Por
ejemplo, S = (Sopt + 4Sm + Spes) / 6
Brinda la credibilidad ms fuerte a la estimacin ms probable y sigue la distribucin

de probabilidad beta. Se supone que existe una probabilidad muy pequea de que el
tamao real resultante se ubique fuera de los valores optimista y pesimista.
Una vez determinado el valor esperado para la variable de estimacin se aplican los
datos de productividad histrica de LDC o PF. Son correctas las estimaciones? La
nica respuesta razonable a esta pregunta es: no se puede estar seguro. Cualquier
tcnica de estimacin, no importa cun sofisticada sea, debe contrastarse con otro
enfoque. Incluso entonces deben prevalecer el sentido comn y la experiencia.
77
Un ejemplo de estimacin basada en LDC

Como ejemplo de tcnicas de estimacin de LDC y PF basadas en el problema,
considrese un paquete de software que ser entregado para una aplicacin de
diseo asistido por computadora (CAD, por sus siglas en ingls) destinado a
componentes mecnicos. El software se ejecutar en una estacin de trabajo de
ingeniera y debe tener interfaz con varios perifricos que incluyen ratn, digitalizador,
monitor de color de alta resolucin e impresora lser. Se puede elaborar una
descripcin preliminar del mbito del software.
El software CAD mecnico aceptar del ingeniero de datos geomtricos de dos y tres
dimensiones. El ingeniero interactuar y controlar el sistema CAD a travs de una
interfaz del usuario que exhibir caractersticas de buen diseo
para producir la salida requerida, la cual se
desplegar en la diversidad de los dispositivos
grficos. El software se disear para controlar e
interactuar con dispositivos perifricos que incluyen
ratn, digitalizador, monitor de color de alta
resolucin e impresora lser y plotter.
Esta
descripcin del mbito preliminar, no est acotada.

Se tendra que expandir cada oracin para ofrecer detalle concreto y acotacin
cuantitativa. Por ejemplo, antes de que comience la estimacin, el planificador debe
determinar qu significa caractersticas de buen diseo de interfaz humano-mquina
o cuales sern el tamao y la complejidad de la base de datos CAD,
En cuanto a los propsitos actuales, se supone que se ha llevado a cabo ms

refinamiento y que estn identificadas para grandes funciones de software
mencionadas en la figura siguiente. En cada funcin se desarrolla un rango de
estimaciones LDC para la funcin de anlisis geomtrico 3D es: optimista, 4600 LDC;
ms probable, 6900 LDC; y pesimista, 8600 LDC. Otras estimaciones se derivan en
forma similar. Al sumar verticalmente en la columna las LDC estimadas, se establece
una estimacin de 33200 lneas de cdigo para el sistema CAD.
78
FUNCIN
Facilidades de interfaz del usuario final y
LDC ESTIMADAS
2300
control (FIUC)
Anlisis geomtrico bidimensional (AG2D)
5300
Anlisis geomtrico tridimensional (AG3D)
6800
Gestin de base de datos (GBD)
3350
Facilidades de presentacin grfica de
4950
computadora (FPGC0
Funcin de control perifrico (FCP)
2100
Mdulos de anlisis de diseo (MAD)
8400
Lnea de cdigos estimados
33200
Una revisin de los datos histricos indica que el promedio organizacional de

productividad para sistemas de este tipo es de 260 LDC/pm. Con base
en una tarifa laboral de 8000 dlares por mes, el costo por lnea de
cdigo es aproximadamente de 13 dlares. Con base en la
estimacin de LDC y los datos histricos de productividad,
el costo total estimado del proyecto es de 431 000 dlares
y el esfuerzo estimado es de 54 personas-mes.
Un ejemplo de estimacin basada en PF

La descomposicin de la estimacin basada en PF se centra
en los valores de dominio de informacin ms que en las
funciones de software. Al consultar la tabla presentada en la
siguiente figura, el planificador del proyecto estima entradas
externas, salidas externas, consultas externas, archivos
lgicos internos y archivos de interfaz externos para el
software CAD.
79
Los PF se calculan usando la tcnica estudiada previamente.
VALOR DE DOMINIO
INFORMACIN
DE
OPTIM.
PROBABLE
PRESI.
CONTEO
ESTIM.
PESO
CONTEO
PF
Nmero de entradas externas
20
24
30
24
97
Nmero de salidas externas

Nmero
de
preguntas
externas
Nmero de archivos lgicos
internos
Nmero de archivos de
interface externos
Conteo total
12
16
15
22
22
28
16
22
5
5
78
88
10
42
15
320
En cuanto a los propsitos de esta estimacin se supone que el factor

ponderado de complejidad es el promedio. La tabla representa los resultados de
esta estimacin.
Se estima cada uno de los factores ponderados de complejidad y el valor del
factor ajustado:
FACTOR
VALOR
4
1. Respaldo y recuperacin
2. Comunicacin de datos
3. Procesamiento distribuido
4. Desempeo crtico
5. Entorno operativo existente
6. Entrada de datos en lnea
7. Transaccin de entrada sobre pantallas mltiples
8. ILF actualizado en lnea
9. Complejo de valores de dominio de informacin
10. Complejo de procesamiento interno
11. Cdigo diseado para reutilizacin
12. Conversin/instalacin en diseo
13. Instalaciones mltiples
14. Aplicacin diseada para cambio
Factor de ajuste de valor
1.17
80
Finalmente, se deriva el nmero estimado de PF:

PFestimado = conteo total x [0.65 + 0.01 x (Fi)]
PFestimado = 375
La productividad organizacional promedio para sistemas de este
tipo es 6.5 PF/pm. Con base en una escala salarial de 8 000
dlares por mes, el costo por PF es aproximadamente 1 230
dlares. Con base en la estimacin de PF y los datos de
productividad histricos, el costo total estimado del proyecto es de 461 000 dlares, y
el esfuerzo estimado es de 58 personas-mes.
Estimacin basada en el proceso

La tcnica ms comn para estima un proyecto es basar la estimacin en el proceso
que se emplear. Esto es, el proceso se descompone en un conjunto relativamente
pequeo de tareas y se estima el esfuerzo requerido para lograr cada tarea.
Al igual que las tcnicas basadas en el problema, la estimacin basada en el proyecto
comienza con un bosquejo de las funciones del software obtenidas a partir del mbito
del proyecto. Cada funcin requiere realizar
una serie de actividades del marco de
trabajo. Las funciones y actividades del
marco de trabajo relacionadas se presentan
como parte de una tabla similar a que
presentamos a continuacin.
81
Actividad
Cc
Planificacin
Anlisis
Ingeniera
del
Liberacin de
Ec
Totales
Construccin
Riesgo
Tarea
Anlisis
Diseo
Cdigo
Prueba
FIUC
0.50
2.50
0.40
5.00
AG2D
0.75
4.00
0.60
2.00
AG3D
0.50
4.00
1.00
3.00
FPGC
0.50
3.00
1.00
1.50
GBD
FCP
0.50
0.25
3.00
2.00
0.75
0.50
1.50
1.50
MAD
0.50
2.00
0.50
2.00
Funcin
Totales
0.2
5
0.25
0.25
3.50
20.50
4.75
16.50
%
esfuerzo
0.5
%
0.5%
0.5%
8%
45%
10%
36%
n/
a
n/
a
n/
a
n/
a
n/
a
n/
a
8.40
7.35
8.50
6.00
5.75
4.25
5.00
46.00
82
CC= comunicacin del cliente EC= evaluacin del cliente

Una vez que se combinan las funciones del problema y las
actividades del proceso, el planificador estima el esfuerzo (por
ejemplo, personas-mes) que se requerir para lograr la
actividad del proceso de software en cada funcin. Estos
datos constituyen la matriz central de esta tabla. Entonces se
aplican las tasas de trabajo promedio (es decir, costo/unidad de
esfuerzo) al esfuerzo estimado para actividad del proceso. Es
muy probable que la tasa de trabajo vare en cada tarea. El equipo veterano est
enormemente involucrado a las actividades tempranas del marco de trabajo y
generalmente es ms costoso que el equipo menos experimentado involucrado en la
construccin y liberacin.
Los costos y el esfuerzo para cada funcin y la actividad del marco de trabajo se
calculan como el ltimo paso. Si la estimacin basada en el proceso se realiza
independientemente de la estimacin del LDC
o PF, ahora se tienen dos o tres estimaciones
para costo y esfuerzo que se pueden comparar
y
armonizar.
estimaciones
Si
ambos
muestran
una
conjuntos
de
concordancia
razonable, existe una buena razn para creer

que las estimaciones son confiables. Si por
otra parte, los resultados de dichas tcnicas de descomposicin muestran poca
concordancia, se debe llevar a cabo mayor investigacin y anlisis.
Un ejemplo de estimacin basada en el proceso

Para ilustrar el uso de la estimacin basada en el proceso considere de nuevo el
software CAD. La configuracin del sistema y las funciones del software permanecen
invariables y las indica el mbito el proyecto.
En la tabla basada en el proceso
que se muestra en la tabla anterior, las
estimaciones del esfuerzo (en personas-mes) para cada actividad de ingeniera del
software se proporcionan para cada funcin del software CAD (abreviadas para mayor
rapidez).
83
Las actividades de ingeniera y liberacin de construccin se subdividen en las

principales tareas de ingeniera del software que se muestran. Las primeras
estimaciones de esfuerzo corresponden a comunicacin con el cliente, planificacin y
anlisis de riesgos, las cuales se registran en la hilera total al final de la tabla. Los
totales horizontal y vertical ofrecen un indicio del esfuerzo estimado que se requiere
para anlisis, diseo, cdigo, y prueba. Se deben sealar que 53 por ciento del
esfuerzo se emplea en las tareas de ingeniera del sistema de salida (anlisis de
requisitos y diseo), lo que indica la importancia relativa de este trabajo. Con base en
la escala salarial promedio de 8 000 dlares por mes, el costo total estimado del
proyecto es de 368 000 dlares, y el esfuerzo estimado es de 46 personas-mes. Si se
desea, los promedios de trabajo pueden asociarse con cada actividad del marco de
trabajo o tarea de ingeniera del software y calcularse por separado.
Estimacin con casos de uso

Los casos de uso permiten que un equipo de software
comprenda el mbito del software y los requisitos. Sin embargo,
desarrollar un enfoque de estimacin con casos de uso es
problemtico por las siguientes razones:
Los casos de uso se describen empleando muchos formatos y

estilos diferentes; no existe un formato estndar.
Los casos de uso representan una visin externa (la visin del usuario) del
software y con frecuencia estn escritos con diferentes grados de abstraccin.
Los casos de uso no abordan la complejidad de las funciones ni de las

caractersticas que se describen.
Los casos de uso no describen el comportamiento complejo (por ejemplo,

interacciones) que involucran muchas funciones y caractersticas.
A diferencia de las LDC o un punto de funcin, el caso de uso de una persona tal vez
requiera meses de esfuerzo mientras que el de otra quiz se implemente en un da o
dos. Aunque varios investigadores han considerado los casos de uso como una
entrada a la estimacin, a la fecha no ha surgido ningn mtodo de estimacin
probado.
84
Smith sugiere el empleo de los casos de uso en la estimacin, pero slo si se

consideran dentro del contexto de la jerarqua estructural que los casos de uso
describen. Smith argumenta que cualquier nivel de esta jerarqua estructural se
describe con no ms de 10 casos de uso. Cada uno de stos abarcara no ms de 30
escenarios distintos. Obviamente, los casos de uso que describen un sistema grande
estn inscritos con un grado mucho mayor de abstraccin (y representan
considerablemente ms esfuerzo de desarrollo) que aquellos que describen un solo
subsistema. En consecuencia antes de que los casos de uso se empleen en la
estimacin, se establece el nivel en la estructura jerrquica, se determina la longitud
promedio (en pginas) de cada caso de uso, se define el tipo de software (por
ejemplo, tiempo real, de negocios, de ingeniera/cientfico, anidado) y se considera
una arquitectura comn del sistema.
Una vez establecidas dichas caractersticas, los datos empricos se aprovechan para
establecer el nmero estimado de LDC o de PF por el caso de uso (para cada nivel de
jerarqua).
Entonces se utilizan los datos histricos para calcular el esfuerzo necesario para
desarrollar el sistema.
LCDestimada = N x LCDprom + [(Sa / Sh 1) + (Pa / Ph 1)] x LCDajuste
Donde
N= nmero real de casos de uso.
LCDprom= promedio histrico de LDC por caso de uso para este tipo de subsistema.
LCDajuste= representa un ajuste con base en n por ciento de LCDprom donde n se
define localmente y representa la diferencia entre este proyecto y los
proyectos promedio
Sa= escenarios reales por caso de uso
Sh= escenarios promedio por caso de uso para este tipo de
subsistema
Pa= pginas reales por caso de uso
Ph= pgina promedio por caso de uso para este tipo de subsistema
Con esta expresin se desarrolla una estimacin comn del nmero de LDC con base
en el nmero real de casos de uso ajustado mediante el nmero de escenarios y la
longitud de la pgina de los casos de uso. El ajuste representa hasta n por cierto del
promedio histrico de las LDC por cada caso de uso.
85
ESTIMACIN DE PROYECTOS DE SOFTWARE

http://www.slideshare.net/montoya118/estimacin-de-proyectos-de-software10785507
ESTIMACIN BASADA EN EL PROBLEMA

http://www.scribd.com/doc/54546460/Estimaciones-Basadas-en-El-Problema
1. En un documento en Word plantee estrategias para la estimacin

de tiempo en un proyecto de biblioteca.
Envalo a travs de "Tiempo en Proyecto".
2. En un documento en Word elabore un ejemplo de estimacin

basado en un sistema de almacn.
Envalo a travs de "Estimacin".
86
Autoevaluacin
1) Coloca los cimientos para las dems actividades de planificacin del

proyecto, y sta proporciona la ruta para las dems actividades de
planificacin del proyecto:
a. La ingeniera de software.
b. El software.
c. La estimacin.
d. Las mtricas.
e. Punto de funcin.
2) El proceso de planificacin del proyecto:
a. Establece un anlisis profundo del proyecto.
b. Proporciona un marco de trabajo que permita al gestor estimar recursos.
c. Lleva a cabo un exhaustivo anlisis interno del proyecto y externo de su
entorno para diagnosticar la situacin actual en la que se encuentra.
d. Monitorea los procesos para que no se generen prdidas en el proyecto.
e. Saber quines participaran en el proyecto.
3) El mbito del software:
a. Describe las pautas que se entregarn al ingeniero de software, as como el
desempeo, las restricciones, las interfaces y la confiabilidad que acotan el
sistema.
b. Identifica a todas las personas y organizaciones que sern impactadas por el
proyecto y posteriormente documentar la informacin relevante respecto a sus
intereses, participacin e impactos sobre el xito del proyecto.
c. Analiza a los interesados en el proyecto y los ayuda a definir una posicin en el
proyecto, as como sus funciones.
d. Evaluar una los casos de uso de un proyecto.
e. Describe las funciones y caractersticas que se entregarn a los usuarios
finales, as como el desempeo, las restricciones, las interfaces y la
confiabilidad que acotan el sistema.
4) En la estimacin de proyectos el planificador de recursos humanos:
a. Especifica la posicin organizacional y la especialidad en un proyecto.
b. Determina las lneas de accin para desarrollar un nuevo software.
c. Elige el conjunto de estrategias y alternativas que nos proporcionen mayores
garantas de xito.
d. Se encarga en que los ingenieros de software hagan su trabajo eficazmente.
e. Especifica la jerarqua y la roles de cada persona en un proyecto.
5) El entorno que soporta un proyecto de software:
a. Administra nicamente el hardware y verifica que siempre este recurso est
disponible cuando sea requerido por un software.
b. Administra nicamente el software y verifica que siempre este recurso est
disponible cuando sea requerido.
c. Administra el hardware y software y verifica que siempre estos recursos estn
disponibles cuando sean requeridos.
d. Administra un proyecto y las mtricas que siempre la informacin de los
procesos siempre est disponible cuando lo sea requerido.
e. Administra las estimaciones de un proyecto para que no ocurran problemas
cuando llegue a manos del usuario final.
87
6) Definir el verdadero concepto:

a. La estimacin del proyecto de software no es una forma eficaz por la cual se
pueden resolver problemas.
b. La estimacin del costo y el esfuerzo nunca ser una ciencia exacta
c. El software es el elemento ms econmico pero complejo virtualmente de todos
los sistemas basados en computadora
d. Las estimaciones identifican que necesidades del proyecto pueden satisfacerse
de mejor manera comprando o adquiriendo los productos y servicios
e. La estimacin de proyectos planifica las compras adquisiciones junto con la
contratacin de ingenieros de software.
7) No es un enfoque de Putnam y Myers referente al problema del tamao de
software:
a. Tamao de lgica difusa.
b. Tamao de punto de funcin.
c. Tamao de las lneas de cdigo.
d. Tamao de componentes estndar.
e. Tamao del cambio.
8) Desarrollar un enfoque de estimacin con casos de uso no es problemtico
por las siguiente razn:
a. Los casos de uso se describen empleando muchos formatos y estilos
diferentes; no existe un formato estndar.
b. Los casos de uso representan una visin externa (la visin del usuario) del
software y con frecuencia estn escritos con diferentes grados de abstraccin.
c. Los casos de uso no abordan la complejidad de las funciones ni de las
caractersticas que se describen.
d. Los casos de uso con frecuencia toman demasiado tiempo en su elaboracin e
implementacin.
e. Los casos de uso no describen el comportamiento complejo (por ejemplo,
interacciones) que involucran muchas funciones y caractersticas.
9) Qu ocurre cuando la concordancia entre las estimaciones es insuficiente?
a. El planificador ha comprendido adecuadamente y ha interpretado el mbito de
proyecto.
b. Los datos de productividad que utilizan las tcnicas de estimacin basadas en
el problema son inapropiados para la aplicacin, obsoletos o se han aplicado
mal.
c. No se determina las polticas solo las responsabilidades
d. Es muy incierto el final de un proyecto
e. Es normal que ocurra eso en todas las estimaciones.
10) La estimacin basada en el proceso se centra en:

a. La discusin de la calidad.
b. Planificacin de la calidad, aseguramiento de la calidad y control de la calidad.
c. Planificacin de la calidad y la discusin de la calidad.
d. Descomponer en un conjunto relativamente pequeo de tareas y se estima el
esfuerzo requerido para lograr cada tarea.
e. Compilar en un conjunto grande de tareas y se estima el esfuerzo requerido
para lograr tareas globales.
88
Resumen
UNIDAD DE APRENDIZAJE III:
La planificacin requiere que los gestores tcnicos y los miembros del equipo de
software establezcan un compromiso inicial, aun cuando sea probable que este
compromiso pruebe estar equivocado. Siempre que se realizan estimaciones se
atisba al futuro y se acepta automticamente algn grado de incertidumbre. Aunque la
estimacin es tanto un arte como una ciencia, esta importante actividad no necesita
realizarse en una forma improvisada. Existen tcnicas tiles para la estimacin de
tiempo y esfuerzo.
Recursos de ingeniera del software: personal, componentes de software reutilizables

y el entorno de desarrollo (hardware y herramientas de software). Cada recurso se
especifica con cuatro caractersticas: descripcin del recurso; un informe de
disponibilidad; cundo se requerir el recurso; tiempo durante el cual el recurso se
aplicar. Las ltimas dos caractersticas se pueden ver cmo una ventana de tiempo.
La disponibilidad del recurso para una ventana especfica debe establecerse lo ms
pronto posible.
Podemos decir que la estimacin del costo y el esfuerzo nunca ser una ciencia
exacta. Demasiadas variables humanas, tcnicas, ambientales, polticas pueden
afectar el costo final del software y el esfuerzo aplicado a desarrollo. Sin embargo, la
estimacin del proyecto de software se puede transformar de una prctica oscura en
una serie de pasos sistemticos que proporcionan estimaciones con riesgo aceptable.
Para lograr estimaciones confiables de costo y esfuerzo se tienen varias opciones:
Demorar la estimacin hasta ms tarde en el proyecto (obviamente, se puede lograr
100 por ciento de estimaciones precisas despus de que el proyecto est terminado!),
basar las estimaciones en proyectos similares que hayan sido completados, emplear
tcnicas de descomposicin relativamente simples para generar estimaciones de
costo y esfuerzo del proyecto y utilizar uno o ms modelos empricos en la estimacin
de costo y esfuerzo.
Las estimaciones de LDC y PF son distintas tcnica de estimacin, aunque ambas

tienen varias caractersticas en comn. El planificador del proyecto comienza con un
enfoque acotado del mbito del software y a partir de ah intenta descomponer el
software en funciones problema que puedan estimarse individualmente. Entonces se
estiman las LDC o PF (las variables de estimacin) para cada funcin. De manera
alternativa, el planificador puede elegir otro componente para tamao, como clases u
objetos, cambios o procesos de negocios afectados.
89
90
Introduccin
a) Presentacin y contextualizacin:
En esta unidad usted aprender la importancia de las tcnicas y tecnologas
eficientes de la ingeniera de software para resolver mltiples problemas que se
derivan de las aplicaciones en donde se desarrollan sistemas de software de gran
tamao. Tendr en cuenta que cada proyecto de software presenta distintos
problemas en su desarrollo los cuales involucran a personas, equipo, usuarios del
software y ambiente de la aplicacin. Por esas razones, cada proyecto debe
resolver el problema de la produccin del software.
b) Competencia:
Gestiona los entregables de un proyecto de TI en el desarrollo del software.
c) Capacidades:
1. Aplica las tcnicas eficientes de la ingeniera de software para resolver
mltiples problemas en el desarrollo del software.
2. Conoce los principios bsicos de calendarizacin en la ingeniera de software
para resolver mltiples problemas en el desarrollo del sistema.
3. Distribuye los esfuerzos dentro de la calendarizacin de un proyecto para
definir y realizar un conjunto de tareas para un proyecto.
4. Identifica las tareas principales mediante la calendarizacin y elaboracin de
una red de tareas.
d) Actitudes:
Muestra una actitud emprendedora ante la calendarizacin de proyectos de
software.
Posee habilidad creativa para realizar proyectos de software.
e) Presentacin de Ideas bsicas y contenidos esenciales de la Unidad:

La Unidad de Aprendizaje 04: Calendarizacin de Proyectos de Software,
TEMA 01: Introduccin a la Calendarizacin de Proyectos de Software.
TEMA 02: La Calendarizacin de Proyectos.
TEMA 03: Distribucin del Esfuerzo.
TEMA 04: Refinamiento de las Tareas Principales.
91
Introduccin
a la
Calendarizacin
de
TEMA 1
Proyectos de
Software
Competencia:
Aplicar las tcnicas eficientes de la ingeniera

de software para resolver mltiples
problemas en el desarrollo del software.
92
Tema 01: Introduccin a la Calendarizacin de

Proyectos de Software
A finales de los aos 60, un joven y brillante ingeniero fue
elegido para escribir un programa de computadora para
una aplicacin industrial automatizada. La razn por la cual
se eligi fue simple: era la nica persona en el grupo tcnico
que haba asistido a un seminario de programacin de
computadoras. l conoca las entradas y salidas del lenguaje ensamblador y de
FORTRAN, pero nada acerca de la ingeniera del software, e incluso menos acerca de
la calendarizacin y seguimiento de proyectos.
Su jefe le dio manuales apropiados y una descripcin verbal de lo que tena que hacer.
Se le inform que el proyecto deba terminarse en dos meses. El ingeniero ley los
manuales, consider su enfoque y comenz a escribir el cdigo. Despus de dos
semanas, el jefe lo llam a su oficina y le pregunt cmo iban las cosas. Realmente
bien dijo el joven ingeniero con entusiasmo juvenil. Esto fue mucho ms simple de lo
que pens. Probablemente he terminado cerca del 75 por ciento. El jefe sonri y
alent al joven ingeniero a seguir trabajando bien. Planearon reunirse de nuevo en una
semana.
Una semana despus, el jefe llamo al ingeniero a su

oficina y le pregunt Dnde estamos?. Todo
marcha bien, dijo el joven, pero me he encontrado
con algunos pequeos obstculos. Los solucionar y
regresar Cmo ves la fecha lmite?, pregunt el
jefe. No hay problema, dijo el ingeniero. Estoy
cerca de terminar el 90 por ciento. Si se ha trabajado en el mundo del software
durante unos cuantos aos se es capaz de terminar la historia. No ser sorpresa que
el joven ingeniero haya permanecido en el 90 por ciento durante todo el proyecto y
terminado (con ayuda de otros) un mes despus.
93
Esta historia se ha repetido decena de miles de veces con los desarrolladores de

software durante las pasadas cuatro dcadas. La gran pregunta es por qu.
Conceptos Bsicos
Aunque existen muchas razones por las cuales el software se entrega con retraso, la
mayora se encuadra en una o ms de las siguientes causas:
Una fecha lmite irrealizable establecida por alguien externo al grupo de

ingeniera del software e impuesta a los gestores profesionales del grupo.
Cambio en los requisitos del cliente que no se reflejan en modificaciones a la

calendarizacin.
Una subestimacin razonable de la cantidad de esfuerzo o de recursos que se

requerirn para realizar el trabajo.
Riesgos predecibles o impredecibles que no se consideraron cuando comenz el

proyecto.
Dificultades tcnicas que no pudieron preverse.
Dificultades humanas imprevisibles.
Falta de comunicacin entre el personal del proyecto. lo

que genera demoras.
Una falla en la gestin del proyecto porque no reconoci el retraso ni emprendi

una accin para corregir el problema.
Las fechas lmite muy audaces son un hecho de la vida en el

negocio del software. En tales ocasiones las fechas lmite se
demandan por razones legtimas, desde el punto de vista de la
persona que las establece. Pero el sentido comn establece que la
legitimidad tambin la deben advertir las personas que hacen el
trabajo. Napolen dijo alguna vez: Cualquier comandante en jefe
que pretenda llevar a cabo un plan que considera defectuoso comete un error; debe
exponer sus razones, insistir en que el plan debe cambiarse y finalmente presentar su
renuncia en lugar de ser el instrumento de la destruccin de su ejrcito. Estas son las
palabras fuertes que muchos gestores de proyectos de software deben considerar.
94
Las actividades de estimacin con frecuencia se implementan atendiendo la restriccin

de una fecha lmite definida. Si las mejores estimaciones indican que la fecha lmite es
irrealizable, un gestor de proyecto competente debe proteger a su equipo de la
presin excesiva [de la calendarizacin] [y] devolver la presin a quienes la originan.
Para ilustrarlo, supngase que a un equipo de ingeniera del software se la ha pedido

construir con controlador en tiempo real para un instrumento de diagnstico que ser
introducido al mercado en nueve meses. Despus de una estimacin y un anlisis de
riesgo cuidadoso, el gestor del proyecto llega a la conclusin de que el software, como
se solicit, requerir 14 meses para crearlo con el personal disponible. Cmo
procede el gestor del proyecto? Es irreal presentarse en la oficina del cliente (en este
caso el probable cliente es mercadotecnia-ventas) y
demandarle que cambie la fecha de entrega. Las presiones
externas del mercado han dictado la fecha, y el producto
debe liberarse. Es igualmente torpe rechazar el trabajo
(desde el punto de vista profesional). As que qu hacer?
En esta situacin se recomiendan los siguientes pasos:

1. Realizar una estimacin detallada empleando datos histricos de proyectos
previos. Determinar el esfuerzo y la duracin estimados para el proyecto.
2. Aplicar un modelo de proceso incremental y desarrollar una estrategia de
ingeniera de software que entregar la funcionalidad crtica en la fecha lmite
impuesta, pero demorar otra. Documente el plan.
3. Reunirse con el cliente y, con la estimacin detallada,
explicarle por qu la fecha lmite impuesta es
irrealizable. Asegrese de sealar que todas las
estimaciones estn basadas sobre el desempeo en
proyectos previos. Tambin asegrese de indicar el
porcentaje de mejora que se requerira para lograr
la fecha lmite vigente.
95
Son apropiados los siguientes comentarios:

Creo que podemos tener un problema con la fecha de entrega para el software
controlador XYZ. Le he dado a cada uno de ustedes un anlisis abreviado de las
tasas de produccin en proyectos previos y una estimacin que mechos hecho en
algunas formas diferentes. Notarn que he supuesto un 20 por ciento de mejora
respecto de ritmos de produccin precedentes, pero todava tenemos una fecha de
entrega que est a 14 meses en lugar de 9.
4. Ofrezca la estrategia de desarrollo incremental como alternativa:

Tenemos unas cuantas opciones y me gustara que tomase una decisin con
base en ellas. Primero, podemos aumentar el presupuesto y conseguir recursos
adicionales de modo que tendremos mucho xito en lograr que este trabajo est
hecho en nueve meses. Pero comprenda que esto aumentar el riesgo de una
calidad deficiente debido a la apretada fecha lmite.
Segundo, podemos remover varias de las funciones y capacidades de software

que est solicitando. Esto har que la versin preliminar del producto sea un poco
menos funcional, pero podemos anunciar toda la funcionalidad y luego entregarla
en el periodo de 14 meses. Tercero, podemos prescindir de la realidad y esperar
que el proyecto se complete en nueve meses. Terminaremos con nada que se
pueda entregar a un cliente. La tercera opcin, espero que est de acuerdo, es
inaceptable. La historia y nuestras mejores estimaciones indican que es irreal y un
boleto hacia el desastre.
Habr algunos gruidos, pero si se presentan estimaciones

slidas basadas en buenos datos histricos es probable
que se elijan versiones negociadas a las opciones 1 o 2.
La fecha lmite irreal se evapora.
96
La
TEMA 2
Calendarizacin
de Proyectos
Competencia:
Conocer
los
principios
bsicos
de
calendarizacin en la ingeniera de software
para resolver mltiples problemas en el
desarrollo del sistema.
97
Tema 02: La Calendarizacin de Proyectos

A Fred Brooks, el bien conocido autor de The Mythical Man-Month,
se le pregunt una vez cmo se retrasaban los proyectos de
software en la calendarizacin. Su respuesta fue tan simple como
profunda: Un da a la vez. La realidad de un proyecto tcnico (ya
sea que involucre la construccin de una planta hidroelctrica o el
desarrollo de un sistema operativo) es que cientos de pequeas
tareas deben realizarse para lograr una meta mayor. Algunas de
tales tareas estn fuera de la corriente principal y se pueden completar sin
preocuparse acerca de su impacto sobre la fecha de terminacin del proyecto. Otras
tareas se encuentran en la trayectoria crtica. Si estas tareas crticas se retrasan en
la calendarizacin, la fecha de terminacin del proyecto se pone en riesgo.
El objetivo del gestor es definir todas las tareas del proyecto, construir una red que
bosqueje sus interdependencias, identificar las tareas cruciales dentro de la red y
luego seguir su progreso para garantizar que la demora se reconoce un da a la vez.
Para lograrlo el gestor debe tener una calendarizacin que se haya definido en un
grado de resolucin que permita supervisar el progreso y controlar el proyecto.
La calendarizacin del proyecto de software es una

actividad que distribuye estimaciones de esfuerzo a travs
de la duracin planificada del proyecto al asignar el
esfuerzo a tareas especficas de ingeniera del software.
Sin embargo, es importante sealar que la calendarizacin
evoluciona a lo largo del tiempo. Durante las primeras etapas de la planificacin del
proyecto,
se
desarrolla
una
calendarizacin
macroscpica.
Este
tipo
de
calendarizacin identifica las principales actividades del marco de trabajo del proceso
y las funciones de producto a las que se aplican. Conforme el proyecto transcurre,
cada entrada en la calendarizacin macroscpica se refina en una calendarizacin
detallada. Aqu se identifican y calendarizan tareas especficas del software
(requeridas para completar una actividad).
98
La calendarizacin para proyectos de ingeniera del

software se puede ver desde dos perspectivas bien
diferentes. En la primera ya se ha establecido
(irrevocablemente) una fecha final para la liberacin de
un sistema basado en computadora. La organizacin
de software est restringida a distribuir esfuerzo dentro del marco temporal prescrito.
La segunda visin de la calendarizacin de software supone que se han comentado
lmites cronolgicos aproximados, pero que la fecha final la establece la organizacin
de ingeniera del software. El esfuerzo se distribuye para utilizar mejor los recursos y la
fecha final se define despus de un anlisis cuidadoso del software. Por desgracia, la
primera situacin se encuentra con mucha ms frecuencia que la segunda.
Principios Bsicos
Al igual que otras reas de ingeniera del software, varios principios bsicos guan la
calendarizacin de los proyectos.
Compartimentacin. El proyecto debe dividirse en compartimientos en varias
actividades, acciones y tareas manejables. Lograrlo requiere descomponer tanto el
producto como el proceso.
Interdependencia. Se debe determinar la interdependencia de
cada actividad, accin o tarea compartimentada. Algunas
tareas deben ocurrir en secuencia mientras que otras
pueden ocurrir en paralelo. Algunas acciones o actividades no pueden comenzar
mientras no est disponible el producto de trabajo producido por otros.
Otras asignaciones o actividades pueden ocurrir de manera independiente.

Asignacin de tiempo. A cada tarea por calendarizar se le debe
asignar cierto nmero de unidades de trabajo (por ejemplo,
personas-da esfuerzo). Adems, a cada tarea se le debe
asignar una fecha de inicio y otra de terminacin que sean
funcin de las interdependencias, y ya sea que el trabajo sea
realizado con base en tiempo completo o parcial.
99
Validacin del esfuerzo. Todo proyecto tiene un nmero definido de las

personas en el equipo de software. Conforme ocurre la asignacin de
tiempo, el gestor de proyecto debe asegurarse de que, en un tiempo
dado, no se han asignado ms que el nmero de personas
calendarizadas. Por ejemplo, considere un proyecto que tiene tres
ingenieros de software asignados (por ejemplo, tres personas-da estn disponibles
por da de esfuerzo asignado). En un da dado se deben completar siete tareas al
mismo tiempo. Cada una requiere 0.50 personas-da de esfuerzo. Se ha asignado ms
esfuerzo que el nmero de personas para hacer el trabajo.
Definicin de responsabilidades. Toda tarea calendarizada se le debe asignar a un

miembro especfico del equipo.
Definicin de resultados. Toda tarea calendarizada debe tener un resultado definido.
En proyectos de software el resultado normalmente es un producto de trabajo (por
ejemplo, el diseo del mdulo) o una parte de l. Los productos de trabajo usualmente
se combinan en los entregables.
Definicin de hitos. Cualquier tarea o grupo de tareas debe estar asociado con un
hito del proyecto. Un hito se logra cuando se ha revisado la calidad de uno o ms
productos de trabajo y se han aprobado.
Cada uno de estos principios se aplica conforme evoluciona la calendarizacin del
proyecto.
Relacin entre el personal y el esfuerzo
En un pequeo proyecto de desarrollo de software una
sola persona puede analizar los requisitos, realizar el
diseo, generar el cdigo y dirigir las pruebas.
Conforme aumenta el tamao de un proyecto, ms
gente resulta involucrada. (Rara vez que se puede
dar el lujo de acometer un esfuerzo de 10 personasao con una persona que trabaje durante 10 aos!).
100
Existe un mito comn que todava creen muchos gestores responsables del esfuerzo
del desarrollo del software: Si nos retrasamos en la calendarizacin, siempre
podemos incorporar ms programadores y recuperarnos ms adelante en el proyecto.
Desgraciadamente, agregar ms personas en etapas tardas de un proyecto con
frecuencia tiene un efecto perturbador sobre ste, lo que provoca que la
calendarizacin se desfase an ms. Las personas que se agregan deben aprender el
sistema y la gente que se les ensea es la misma que estaba haciendo el trabajo.
Durante la enseanza no se realiza trabajo y el proyecto experimenta mayores
retrasos.
Adems el tiempo que tarda aprender el sistema, ms personal aumenta el nmero de

rutas de comunicacin y la complejidad de sta a lo largo de un proyecto. Aunque le
comunicacin es absolutamente esencial para el xito del desarrollo de software, cada
nueva ruta de comunicacin requiere un esfuerzo adicional y, por lo tanto, tiempo
suplementario. A lo largo de los aos, los datos empricos y el anlisis terico han
demostrado que las calendarizaciones de proyecto son elsticas. Es decir, es posible
comprimir en cierta medida la fecha de terminacin (al reducir el nmero de recursos).
La Curva Putnam-Norden-Rayleigh (PNR) proporciona un indicio de la relacin entre el

esfuerzo aplicado y el tiempo de entrega para un proyecto de software. En el siguiente
grfico se muestra una versin de la curva, que representa el esfuerzo del proyecto
como funcin del tiempo de entrega. La curva indica un valor mnimo, t0, que indica el
tiempo de entrega de menor costo (es decir, el tiempo de entrega que generar el
menor gasto de esfuerzo). Conforme se mueve a la izquierda de t0 (es decir, conforme
intenta acelerar la entrega), la curva se eleva en forma no lineal.
101
Como ejemplo, supngase que un equipo de proyecto ha estimado un nivel de

esfuerzo Ea que se requerir para lograr un tiempo de entrega nominal, td, que es
ptimo en trminos de calendarizacin y recursos disponibles. Aunque es posible
acelerar la entrega, la curva se eleva muy pronunciadamente hacia la izquierda de td.
De hecho, la curva PNR indica que el tiempo de entrega del proyecto no se puede
comprimir ms all de 0.75 td. Si se intenta una mayor compresin, el proyecto se
mueve hacia la regin imposible y el riesgo de fracaso se eleva mucho. La curva
PNR tambin indica que la opcin de entrega de menor costo, to = 2td. La implicacin
aqu es que la demora en la entrega del proyecto puede reducir los costos
significativamente. Desde luego, esto debe superarse frente al costo del negocio
asociado con la demora.
La ecuacin del software, se obtiene de la curva PNR y demuestra la relacin

enormemente lineal entre el tiempo cronolgico para completar un proyecto y el
esfuerzo humano aplicado a ste. El nmero de lneas de cdigo entregadas
(enunciados fuente), L, se relaciona con el esfuerzo y el tiempo de desarrollo mediante
la ecuacin: L = P x E1/3t4/3 donde E es el esfuerzo de desarollo en personas-mes; P,
un parmetro de productividad que refleja una diversidad de factores que conducen a
trabajo de ingeniera del software de alta calidad (los valores tpicos de P varan entre
2 000 y 12 000); y t , la duracin el proyecto en meses calendario. Al reordenar esta
ecuacin del software se puede llegar a una expresin para el esfuerzo de desarrollo
E: E = E3 / ( P3t4 ) donde E es el esfuerzo utilizado (en personas-ao) durante el ciclo
de vida para el desarrollo y mantenimiento de software, y t es el tiempo de desarrollo
en aos. La ecuacin para el esfuerzo de desarrollo se puede relacionar con el costo
del desarrollo al incluir un factor de escala salarial (costo/persona-ao).
Esto conduce a unos resultados interesantes. Considrese un complejo proyecto de

software de tiempo real estimado en 33 000 LDC, 12 personas-ao de esfuerzo. Si se
asignan ocho personas al equipo del proyecto, ste se puede completar en
aproximadamente 1.3 aos. Sin embargo si se extiende la fecha final a 1.75 aos, la
naturaleza enorme no lineal del modelo produce: E = L3 / ( P3t4 ) ~ 3.8 personas-ao
Esto implica que, al extender la fecha final seis meses, se puede reducir el nmero de
personas de ocho a cuatro! La validez de tales resultados est abierta al debate, pero
la implicacin es clara: se pueden obtener beneficios al emplear menos personal
durante un periodo un poco ms largo para lograr el mismo objetivo.
102
Distribucin
TEMA 3
del
Esfuerzo
Competencia:
Distribuir los esfuerzos dentro de la
calendarizacin de un proyecto para definir y
realizar un conjunto de tareas para un
proyecto.
103
Tema 03: Distribucin del Esfuerzo

Cada una de las tcnicas de estimacin de proyectos de
software estudiadas conduce a estimaciones de unidades de
trabajo (por ejemplo, las personas-mes) requeridas para
completar
el
desarrollo
del
software.
Una
distribucin
recomendada del esfuerzo a travs del proceso de software con

frecuencia se conoce como la regla 40-20-40. Cuarenta por ciento de todos los
esfuerzos se asignan al anlisis y el diseo de sistemas de entrada. Un porcentaje
similar se aplica en poner a prueba los sistemas de salida. Usted puede inferir
correctamente que la codificacin (20 por ciento del esfuerzo) no tiene tanto nfasis.
Esta distribucin del esfuerzo se debe usar solamente como gua. Las caractersticas
de cada proyecto deben dictar la distribucin del esfuerzo. El trabajo realizado en la
planeacin del proyecto rara vez explica ms de 2-3 por ciento del esfuerzo a menos
que el plan comprometa a una organizacin a grandes gastos con alto riesgo. Los
anlisis de requisitos pueden comprometer 10-25 por ciento del esfuerzo del proyecto.
El esfuerzo empleado en el anlisis o elaboracin de prototipos debe aumentar en
proporcin directa con el tamao y la complejidad de un proyecto. Un intervalo del 20
al 25 por ciento de esfuerzo normalmente se aplica al diseo de software. Tambin se
debe considerar el tiempo utilizado en la revisin del diseo y la subsiguiente iteracin.
Debido al esfuerzo aplicado al diseo de software, el cdigo

debe seguir con relativamente poca dificultad. Se puede
lograr un rango de 15-20 por ciento del esfuerzo global. Las
pruebas y la subsiguiente depuracin explican el 30-40 por
ciento del esfuerzo de desarrollo del software. El carcter
crucial del software con frecuencia dicta la cantidad de
pruebas que se requieren. Si el software se clasifica desde el
punto de vista humano (es decir, la falla del software puede resultar en prdida de
vidas), son usuales porcentajes todava ms altos.
104
Definicin de un conjunto de tareas para el proyecto de software

Ningn conjunto de tareas es apropiado por s slo para
todos los proyectos. El conjunto de tareas que sera
apropiado
para
probablemente
un
se
sistema
complejo
apreciara
como
grande
demasiado
destructivo para un producto de software pequeo y

relativamente simple. En consecuencia, un proceso de
software eficaz debe definir una coleccin de conjunto de tareas, cada una diseada
para satisfacer las necesidades de diferentes tipos de proyectos.
Un conjunto de tareas es una coleccin de tareas de trabajo de ingeniera del

software, hitos y productos de trabajo que se deben terminar para completar un
proyecto particular. El conjunto de tareas debe proporcionar suficiente disciplina para
lograr alta calidad de software. Pero, al mismo tiempo, no debe abrumar al equipo de
proyecto con trabajo innecesario. En el desarrollo de una calendarizacin el proyecto
requiere distribuir un conjunto de tareas a lo largo de la lnea de tiempo del proyecto.
El conjunto de tareas variar segn el tipo de proyecto y el grado de rigor con el que
equipo de software decide realizar su trabajo.
Aunque es difcil desarrollar una taxonoma completa de tipos de proyecto de software,

en la mayora de las organizaciones del ramo se encuentran los siguientes proyectos:
1. Proyectos de desarrollo del concepto, los
cuales
se
inician
para
explorar
algunas
aplicaciones o conceptos de negocio de alguna

nueva tecnologa.
2. Proyectos
de
desarrollo
de
nuevas
aplicaciones, los cuales se llevan a cabo como consecuencia de una solicitud

especfica del cliente.
3. Proyectos de mejora de la aplicacin, stos ocurren cuando el software
existente experimenta grande modificaciones en la funcin, el desempeo o las
interfaces visibles para el usuario final.
105
4. Proyectos de mantenimiento de aplicacin, los cuales corrigen, adaptan o

extienden el software existente en formas que no sean obvias inmediatamente
para el usuario final.
5. Proyectos de reingeniera, stos se llevan a cabo con la finalidad de
reconstruir un sistema existente (heredado), en todo o en parte.
Incluso dentro de un solo tipo de proyecto, muchos factores

influyen en la eleccin del conjunto de tareas. Por ejemplo:
tamao del proyecto, nmero de usuarios potenciales, lo
crucial de la misin, duracin de la aplicacin estabilidad de
los requisitos, facilidad de comunicacin con el usuario o
desarrollador, madurez de la tecnologa aplicable, restricciones del desempeo,
caractersticas anidadas y no anidadas, el equipo del proyecto y factores de
reingeniera. Cuando se consideran en conjunto, estos factores ofrecen un indicio el
grado de rigor que se debe aplicar al proceso de software.
Ejemplo de conjunto de tareas

Cada uno de los tipos de proyecto descritos puede
abordarse
secuencial,
mediante un modelo de proceso lineal,

iterativo
(por
ejemplo,
los
modelos
de
elaboracin de prototipo o incrementales) o evolutivo (por

ejemplo, el modelo espiral). En algunos casos un tipo de
proyecto fluye suavemente hacia el siguiente. Por ejemplo,
los proyectos de desarrollo de las nuevas aplicaciones.
Cuando termina un proyecto de desarrollo de nuevas aplicaciones, en ocasiones
comienza un proyecto de mejora de la aplicacin. Esta progresin es tanto natural
como predecible y ocurrir sin importar el modelo de proceso que adopte la
organizacin. En consecuencia, las principales tareas de ingeniera del software son
aplicables a todos los flujos de modelo de proceso.
106
Como, ejemplo, considrese las tareas de ingeniera del software para un proyecto de
desarrollo del concepto. Los proyectos de desarrollo del concepto se inician cuando se
debe explotar el potencial para alguna nueva tecnologa. No existe certeza de que la
tecnologa ser aplicable, pero un cliente (por ejemplo, marketing) cree que existen
beneficios potenciales.
Los proyectos de desarrollo del concepto se enfocan en aplicar las siguientes tareas
principales:
1.1 La determinacin del mbito del concepto precisa el mbito global del
proyecto.
1.2 La planeacin preliminar del concepto establece la
habilidad de la organizacin para acometer el
trabajo que entraa el mbito del proyecto.
1.3 La valoracin del riesgo de la tecnologa
evala el riesgo asociado con la tecnologa que se
implementar como parte del mbito del proyecto.
1.4 La prueba del concepto demuestra la vialidad de
una nueva tecnologa en el contexto del software.
1.5 La implementacin del concepto pone en prctica la representacin del

concepto en una forma que pueda revisarla un cliente y se utiliza para
propsitos de mercadotecnia cuando se deben vender un concepto a otros
clientes o gestores.
1.6 La reaccin del cliente al concepto solicita realimentacin acerca de un
concepto de nueva tecnologa y se dirige a aplicaciones especficas de los
clientes.
Una rpida exploracin de estas tareas debe producir pocas sorpresas. De hecho, el
flujo de ingeniera de software para los proyectos de desarrollo del concepto (y
tambin para que todos los otros tipos de proyectos) es poco ms que sentido comn.
107
Refinamiento
de las
TEMA 4
Tareas
Principales
Competencia:
Identificar las tareas principales mediante la
calendarizacin y elaboracin de una red de
tareas.
108
Tema 04: Refinamiento de las Tareas

Principales
Las tareas principales se pueden utilizar para definir la
calendarizacin macroscpica de un proyecto. Sin
embargo, esta calendarizacin se debe refinar para
crear una calendarizacin detallada del proyecto. El
refinamiento comienza al tomar cada tarea principal y
descomponerla en un conjunto de subtareas (con
productos de bajo trabajo e hitos relacionados).
Como ejemplo de descomposicin de tarea,

consideremos el siguiente la siguiente tarea,
determinacin del mbito del concepto. El
refinamiento de una tarea se puede lograr
empleando un bosquejo de formato, pero en este
libro se aplica un enfoque de lenguaje en el
diseo del proceso para ilustrar el flujo de la
actividad de determinacin del mbito del concepto.
Definicin tarea: Tarea 1.1 Determinacin del mbito del concepto

1.1.1
Identificar necesidades, beneficios y clientes potenciales;
1.1.2
Definir eventos de salida/control y entrada deseados que impulsen la

aplicacin;
Comienza Tarea 1.1.2

1.1.2.1 RTF: Revisar la descripcin escrita de la necesidad;
1.1.2.2 Derivar una lista de salidas/entradas visibles al cliente;
1.1.2.3 RTF: Revisar salidas/entradas con el cliente y modificar conforme se
requiera;
Fin de tarea 1.1.2
109
1.1.3 Definir la funcionalidad/comportamiento para cada funcin principal;

Co
1.1.3.1 RTF: Revisar los objetos de datos de salida y entrada derivados en la
tarea 1.1.2;
1.1.3.2 Derivar un modelo funciones/comportamientos;
1.1.3.3 RTF: Revisar funciones/comportamientos con el cliente y modificar
conforme se requiera;
Fin de tarea 1.1.3
1.1.4 Aislar aquellos elementos de la tecnologa que se implementar en el software;

1.1.5 Disponibilidad de investigacin del software existente;
1.1.6 Definir factibilidad tcnica;
1.1.7 Realizar estimacin rpida del tamao;
1.1.8 Crear una Definicin del mbito;
Fin de tarea 1.1
Las tareas y subtareas anotadas en el proceso de
refinamiento el lenguaje de diseo forman la base de una planeacin detallada de la
actividad de determinar el mbito del concepto.
Definicin de Una Red de Tareas

Las tareas y subtareas individuales tienen
interdependencias basadas en su secuencia.
Adems, cuando ms de una persona est
involucrada en un proyecto de ingeniera del
software, es probable que las actividades y
tareas de desarrollo se realicen en paralelo.
Cuando esto ocurre, las tareas concurrentes deben estar coordinadas de modo que se
completarn cuando las tareas posteriores requieran sus productos de trabajo.
110
Una red de tareas, tambin denominada red de actividad, es una representacin

grfica del flujo de tareas en un proyecto. En ocasiones se utiliza como el mecanismo
mediante el cual la secuencia y dependencias de tareas son la entrada de una
herramienta automatizada de calendarizacin del proyecto. En su forma ms simple
(empleada cuando se crea una calendarizacin macroscpica), la red de tareas
muestra las principales tareas de la ingeniera del software. La siguiente figura
muestra una red de tareas esquemtica para un proyecto e desarrollo del concepto.
La
naturaleza
concurrente
de
las
actividades
de
ingeniera de software conduce a varios requisitos

importantes de la calendarizacin. Puesto que las tareas
paralelas ocurren de manera asncrona, el planificador
debe determinar dependencias intertareas para asegurar
el progreso continuo hacia la finalizacin.
Adems, el gestor del proyecto debe estar atento a las tareas que se encuentran en la
ruta crtica. Esto es, las tareas se deben completar en la calendarizacin si el
proyecto como un todo se debe completar a tiempo. Es importante notar que la red de
tareas mostrada es macroscpica. En la red de tareas detallada (un precursor de la
calendarizacin detallada) cada actividad que muestra la figura se debe expandir.
111
Calendarizacin
La calendarizacin de un proyecto de software no difiere enormemente de la de
cualquier esfuerzo de ingeniera multitarea. En consecuencia, las tcnicas y
herramientas generalizadas de calendarizacin de proyecto se pueden aplicar, poco
modificadas, en proyectos de software. La tcnica de evaluacin y revisin de
programa (PERT, por sus siglas en ingls) y el mtodo de ruta crtica (CPM, por sus
siglas en ingls) son dos mtodos de calendarizacin de proyecto que se pueden
aplicar al desarrollo de software.
Ambas tcnicas reciben impulso de la informacin ya desarrollada en actividades

tempranas de la planeacin del proyecto:
Estimacin del esfuerzo.
Descomposicin de la funcin del producto.
Seleccin del modelo de proceso y conjunto de tareas apropiadas.
Descomposicin de tareas.
Las interdependencias entre las tareas se pueden definir empleando una red de
tareas. Las tareas, en ocasiones llamadas la estructura del trabajo (EAT, por sus
siglas en ingls), se definen para el producto como un todo o para funciones
individuales.
Tanto PERT como CPM ofrecen herramientas cuantitativas

que permiten al planificador de software 1) determinar
la trayectoria crtica: La cadena de tareas que
determinan la duracin del proyecto; 2) establecer las
estimaciones de tiempo ms probables para tareas
individuales al aplicar modelos estadsticos; y 3)
calcular los tiempo lmite que definen una ventana de
tiempo para una tarea particular.
112
CALENDARIZACIN DE PROYECTOS
http://elchrboy.blogspot.com/2010/03/calendarizacion-de-proyectos-de.html
REFINAMIENTO DE TAREAS PRINCIPALES

http://ingenieriadesoftware1641.blogspot.com/2009/04/refinamiento.html
1. En un documento en Word elaborare un refinamiento de las

tareas principales para un sistema de matrculas y notas.
Envalo a travs de "Refinamiento".
2. Realice una red de tareas esquemticas para el sistema de

matrculas y notas utilizando algn software que permita
desarrollar las tcnicas de evaluacin y revisin de programa
(PERT) y el mtodo de ruta crtica (CPM).
Envalo a travs de "Sistema de Matrculas".
113
Autoevaluacin
1) Aunque existen muchas razones por las cuales el software se entrega con
retraso, indique cual no se encuadra en una o ms de las siguientes causas:
a. Una fecha lmite irrealizable establecida por alguien externo al grupo de
ingeniera del software e impuesta a los gestores profesionales del grupo.
b. Cambio en los requisitos del cliente que no se reflejan en modificaciones a la
calendarizacin.
c. Una subestimacin razonable de la cantidad de esfuerzo o de recursos que se
requerirn para realizar el trabajo.
d. Riesgos predecibles o impredecibles que no se consideraron cuando comenz
el proyecto.
e. Dificultades tcnicas que previamente se previnieron.
2) Las actividades de estimacin con frecuencia se implementan atendiendo:
a. Haciendo planes para acabar en la fecha indicada.
b. La restriccin de una fecha lmite definida.
c. Dando ms flexibilidad en el tiempo para entregar.
d. Trabajando con metas reales y alcanzables.
e. Cumpliendo, si es posible antes de la fecha lmite establecida.
3) Cul de estas acciones no es recomendada en la calendarizacin de
proyectos?
a. Realizar una estimacin detallada empleando datos histricos de proyectos
previos.
b. Reunirse con el cliente y, con la estimacin detallada, explicarle por qu la
fecha lmite impuesta es irrealizable
c. Ofrecer la estrategia de desarrollo incremental como alternativa
d. Aplicar un modelo de proceso incremental y desarrollar una estrategia de
ingeniera de software
e. Cumplir con la presentacin de los trabajos encomendados de manera
individual y en equipo, respetando la iniciativa y aportes de los integrantes de
manera eficaz.
4) La calendarizacin del proyecto de software es:
a. Una mtrica que nos ayuda a definir si se puede realizar el proyecto en un
lapso establecido.
b. Una disciplina que administra el tiempo de forma eficaz.
c. Una mtrica que mide el esfuerzo de una organizacin al entregar un proyecto
en una fecha exacta.
d. Una actividad que distribuye estimaciones de esfuerzo a travs de la duracin
planificada del proyecto.
e. Una actividad que integra las estimaciones de todas las reas de una empresa
para que el proyecto pueda entregarse en una fecha lmite establecida.
114
5) En la calendarizacin:
a. El software debe de tener la mejor calidad y productividad para que en la fecha
final se defina despus de un anlisis cuidadoso del software.
b. El esfuerzo se distribuye para utilizar mejor los recursos y la fecha final se
define despus de un anlisis cuidadoso del software.
c. El software tenga cero errores para que en la fecha final se defina un anlisis
cuidadoso del software.
d. Un esfuerzo adicional evita que el proyecto se convierta en un fracaso y de eso
modo el software se convierta en un xito.
e. El software tenga cero errores para que en la fecha final se defina un anlisis
de esfuerzos.
6) En el desarrollo de una calendarizacin el proyecto requiere:
a. Distribuir un conjunto de tareas a lo largo de la lnea de tiempo del proyecto
b. Planificar un conjunto de tareas al inicio del proyecto.
c. Distribuir un conjunto de tareas a lo largo de la lnea de tiempo del proyecto.
d. Distribuir un conjunto de tareas al final del proyecto.
e. Distribuir un conjunto de tareas a lo largo de la programacin del software.
7) Es un conjunto de tareas de ingeniera del software, hitos y productos de
trabajo que se deben terminar para completar un proyecto particular
a. Definicin de un conjunto de anlisis para el proyecto de software.
b. Definicin de un conjunto de tareas para el proyecto de sistemas de
informacin.
c. Definicin de un conjunto de normas para el proyecto de sistemas de
informacin.
d. Definicin de un conjunto de tareas para el proyecto de software.
e. Definicin de un conjunto de tareas para el modelamiento de software.
8) Qu se requiere hacer para crear una calendarizacin detallada del
proyecto?
a. Refinamiento de la calendarizacin.
b. Compactacin de la calendarizacin.
c. Reduccin de la calendarizacin.
d. Ampliacin de la calendarizacin.
e. Seguimiento de la calendarizacin.
9) Una red de tareas es:
a. Es un diagrama de flujo.
b. Es una ruta crtica.
c. Son los nodos de un PERT determinstico.
d. Es una representacin probabilstica del flujo de tareas en un proyecto
e. Es una representacin grfica del flujo de tareas en un proyecto.
10) La tcnica de evaluacin y revisin de programa (PERT) y el mtodo de ruta
crtica (CPM) que no desarrolla la siguiente actividad:
a. Estimacin del esfuerzo.
b. Descomposicin de la funcin del producto.
c. Seleccin del modelo de proceso y conjunto de tareas apropiadas.
d. Estimacin de lneas de comando.
e. Descomposicin de tareas.
115
Resumen
UNIDAD DE APRENDIZAJE IV:
La calendarizin de proyecto de software est ligado con seleccionar un modelo de

proceso apropiado, identificando tareas de ingeniera del software que es preciso
realizar; estimar la cantidad de trabajo y el nmero de personas , igual se conoce la
fecha lmite y se consideraron los riesgos.
La calendarizacin del proyecto de software es una actividad que distribuye

estimaciones de esfuerzo a travs de la duracin planificada del proyecto al asignar el
esfuerzo a tareas especficas de ingeniera del software. En la construccin de un
sistema complejo muchas tareas de ingeniera de software ocurren en paralelo, y el
resultado del trabajo realizado durante una tarea puede tener un profundo efecto en
el trabajo llevado a cabo en otras tareas. Al igual que es imposible evaluar el
progreso de un proyecto de software moderado y grande sin una calendarizacin.
En la distribucin del esfuerzo, dicho esfuerzo es la medida fundamental o cantidad

de trabajo que un equipo de desarrolladores debe aplicar en determinada tarea o
etapa para lograr un objetivo en comn, ya sean objetivos especficos o generales. El
esfuerzo debe dividirse creando unidades o subequipos de trabajo con el fin de
optimizar el tiempo y trabajo.
Una herramienta de suma importancia es el refinamiento del software para la

realizacin de un software de calidad y para eso se requiere conocer los
requerimientos a la hora de disear un software y definir cules son las funciones que
va a tener nuestro software, y cada una de las especificaciones que este va a tener,
fecha lmite y que ste se entregue en la fecha lmite
116
Glosario
AMENAZAS: Las amenazas son situaciones negativas, externas al programa o

proyecto, que pueden atentar contra ste, por lo que llegado al caso, puede ser
necesario disear una estrategia adecuada para poder sortearlas.
CICLO: Conjunto de etapas dentro de un proyecto

CONTINGENCIA: Posibilidad de que algo suceda o no suceda.
CRONOGRAMA: Calendario de trabajo.
DEPENDENCIA: Subordinacin a un poder mayor.
DESGLOSE: Separar algo de un todo, para estudiarlo o considerarlo por separado.
DIAGRAMA: Dibujo en el que se muestran las relaciones entre las diferentes
partes de un sistema.
ELABORACIN GRADUAL: Desarrollar en pasos e ir aumentando mediante

incrementos
NFASIS ESTRATGICO: Sucede cuando los proyectos son patrocinados por la

gerencia general
ENTREGABLES: Son documentos a entregar en un proyecto

ESTIMACIN: Aprecio y valor que se da y en que se tasa y considera algo.
ESTRATEGIA: Plan que lleva a una empresa a cumplir con la visin del negocio
ESTRUCTURA: Distribucin y orden con que est compuesta un proyecto.
HITO: Unido, inmediato.
INFLUYENTES: Son personas que tienen una influencia positiva o negativa dentro
del proyecto
INTEGRACIN: rea encargada de la unificacin y consolidacin

INTERESADOS: Personas o organizaciones que participan activamente en el
proyecto
MTRICA: Arte que trata de la medida, permite obtener la visin del proceso y el
proyecto pues proporciona un mecanismo para lograr una evaluacin objetiva.
OCURRENCIA: Encuentro, suceso casual, ocasin o coyuntura.

PMBOK: Es un estndar en la Administracin de proyectos desarrollado por el
Project Management Institute (PMI). Comprende dos secciones, la primera sobre
los procesos y contextos de un proyecto, la segunda sobre las reas de
conocimiento especfico para la gestin de un proyecto.
117
Fuentes de Informacin
BIBLIOGRFICAS:
ROGER PRESSMAN, McGraw-Hill Interamericana Editores S.A. Ingeniera del

Software: Un enfoque prctico. EEUU, 2009.
PROJECT MANAGEMENT INSTITUTE. Gua de los fundamentos de la
direccin de proyectos. Newtown Square EEUU., 2010.
JOHN J. RAKOS. Ed. La negociacin y los contratos. Ed. Prentice Hall, Inc USA,
2008.
KELLY KINTHER & SONS. Entendiendo el pasado para mejorar el futuro. Ed.
Prentice Hall, Inc USA, 2010.
JOHN WILEY & SONS. Reuniones, revisiones en informes. Ed. Prentice Hall, Inc
USA, 2011.
ELECTRNICAS:
Direccin y gestin de proyectos

http://books.google.com.pe/books?id=pAQ9QelkHmkC&printsec=frontcover&hl=es
&source=gbs_ge_summary_r&cad=0#v=onepage&q&f=false
Gestin de proyectos de TI
http://plataforma.edu.pe/pluginfile.php/84031/mod_resource/content/1/gestion_de_
proyectos_de_ti.pdf
Objetivos y logros en proyectos de TI

http://www.nacion.com/2011-05-04/Opinion/Foro/Opinion2766882.aspx
Estimacin para proyectos de software

http://elchrboy.blogspot.com/2010/03/estimacion-para-proyectos-de-software.html
Calendarizacin de proyectos
http://fcqi.tij.uabc.mx/usuarios/luisgmo/data/6.3%20calendariz%202007.pdf
118
Solucionario
UNIDAD DE
1. E
UNIDAD DE
APRENDIZAJE 2:
1. B
2. B
2. B
3. C
3. D
4. E
4. B
5. A
5. E
6. B
6. A
7. D
7. B
8. C
8. C
9. A
9. C
10. E
10. C
APRENDIZAJE 1
UNIDAD DE
APRENDIZAJE 3:
UNIDAD DE
APRENDIZAJE 4:
1. C
1. E
2. B
2. B
3. E
3. E
4. A
4. D
5. C
5. B
6. B
6. C
7. C
7. D
8. D
8. A
9. B
9. E
10. D
10. D
119

Proyecto Integrador II PDF

Cargado por

Copyright:

Formatos disponibles

Proyecto Integrador II PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Proyecto Integrador II PDF

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD PRIVADA TELESUP

UNIVERSIDAD PRIVADA TELESUP

La asignatura es de carcter terico - prctico. sta,

empresariales globales. Adems, le brinda los

proyectos de tecnologas de la informacin

estudiantes planean, implementan y evalan proyectos que tienen aplicacin en el

Comprende cuatro Unidades de Aprendizaje:

UNIVERSIDAD PRIVADA TELESUP

Estructura de los Contenidos

Gestin del tiempo

que el estudiante debe lograr al final de la

direccin de proyectos que le permitan

la mano con la informacin global.

UNIVERSIDAD PRIVADA TELESUP

ndice del Contenido

UNIVERSIDAD PRIVADA TELESUP

UNIVERSIDAD PRIVADA TELESUP

e) Presentacin de Ideas bsicas y contenido esenciales de la Unidad:

UNIVERSIDAD PRIVADA TELESUP

UNIVERSIDAD PRIVADA TELESUP

Desarrollo de los Temas

Tema 01: Fundamentos de la Direccin de

Productos, servicios o resultados nicos

UNIVERSIDAD PRIVADA TELESUP

Un resultado como, por ejemplo, salidas o documentos. Por ejemplo, de un

El desarrollo de una planta de procesamiento qumico comienza con la

construccin. Durante la construccin, se realizan las

UNIVERSIDAD PRIVADA TELESUP

El producto de un proyecto de desarrollo econmico puede definirse

Proyectos frente a trabajos operativos

Realizados por personas.

Restringidos por la limitacin de los recursos.

Planificados, ejecutados y controlados.

diferentes. La finalidad de un proyecto es

proyecto concluye cuando se alcanzan sus

UNIVERSIDAD PRIVADA TELESUP

Los proyectos se llevan a cabo en todos los niveles de la organizacin y pueden

Entre los ejemplos de proyectos se incluyen, entre otros:

Desarrollar un nuevo producto o servicio.

Efectuar un cambio en la estructura, en el personal o en el

estilo de una organizacin.

Disear un nuevo vehculo de transporte.

Desarrollar o adquirir un sistema de informacin nuevo o

Construir un edificio o una planta.

Realizar una campaa para un partido poltico.

Implementar un nuevo procedimiento o proceso de negocio.

Responder a una solicitud de contrato.

UNIVERSIDAD PRIVADA TELESUP

UNIVERSIDAD PRIVADA TELESUP

Tema 02: Gestin de Alcance del Proyecto

satisfactoriamente y tener un cierre elegante. Adems

Segn la guia de los fundamentos de la direccin de proyectos dice:

La palabra alcance puede definirse en lo siguiente:

Alcance del producto. Las caractersticas y funciones

Alcance del proyecto. El trabajo que debe realizarse para

El flujo de procesos de la gestin del alcance del proyecto es el siguiente:

Planificacin del alcance

Verificacin del alcance

Definicin del alcance