Está en la página 1de 119
UNIVERSIDAD PRIVADA TELESUP 1

UNIVERSIDAD PRIVADA TELESUP

UNIVERSIDAD PRIVADA TELESUP 1
UNIVERSIDAD PRIVADA TELESUP 1
UNIVERSIDAD PRIVADA TELESUP 1

1

UNIVERSIDAD PRIVADA TELESUP Prefacio: La asignatura es de carácter teórico - práctico. Ésta, tiene como

UNIVERSIDAD PRIVADA TELESUP

Prefacio:

UNIVERSIDAD PRIVADA TELESUP Prefacio: La asignatura es de carácter teórico - práctico. Ésta, tiene como finalidad
UNIVERSIDAD PRIVADA TELESUP Prefacio: La asignatura es de carácter teórico - práctico. Ésta, tiene como finalidad
UNIVERSIDAD PRIVADA TELESUP Prefacio: La asignatura es de carácter teórico - práctico. Ésta, tiene como finalidad

La asignatura es de carácter teórico - práctico. Ésta, tiene como finalidad desarrollar en el estudiante habilidades para la dirección de proyectos empresariales globales. Además, le brinda los conocimientos necesarios para implementar proyectos de tecnologías de la información integrándolos con variables disciplinas ya que es un modelo de aprendizaje en el que los estudiantes planean, implementan y evalúan proyectos que tienen aplicación en el mundo real; más allá del aula de clase. Está direccionada al planteamiento y solución de problemas relacionados con la práctica profesional y calidad de vida; requiere de la articulación de asignaturas del nivel, disciplina o carrera

Comprende cuatro Unidades de Aprendizaje:

Unidad I: Generalidades de la Dirección de Proyectos de TI. Generalidades de la Dirección de Proyectos de TI.

Unidad II: Métricas para Procesos y Proyectos de TI. Métricas para Procesos y Proyectos de TI.

Unidad III: Estimación para Proyectos de Software. Estimación para Proyectos de Software.

Unidad IV: Calendarización de Proyectos de Software. Calendarización de Proyectos de Software.

de TI. Unidad III: Estimación para Proyectos de Software. Unidad IV: Calendarización de Proyectos de Software.
2
2
UNIVERSIDAD PRIVADA TELESUP Estructura de los Contenidos Generalidades de la Dirección de Proyectos de TI

UNIVERSIDAD PRIVADA TELESUP

UNIVERSIDAD PRIVADA TELESUP Estructura de los Contenidos Generalidades de la Dirección de Proyectos de TI Fundamentos

Estructura de los Contenidos

Generalidades de la Dirección de Proyectos de TI

Generalidades de la Dirección de Proyectos de TI
Contenidos Generalidades de la Dirección de Proyectos de TI Fundamentos de la Dirección de Proyectos. Gestión

Fundamentos de la Dirección de Proyectos.

Proyectos de TI Fundamentos de la Dirección de Proyectos. Gestión de alcance del Proyecto. Gestión de

Gestión de alcance del Proyecto.

Dirección de Proyectos. Gestión de alcance del Proyecto. Gestión de los Riesgos del Proyecto. Gestión del

Gestión de los Riesgos del Proyecto.

alcance del Proyecto. Gestión de los Riesgos del Proyecto. Gestión del tiempo de un Proyecto. Métricas

Gestión del tiempo de un Proyecto.

Métricas para Procesos y Proyectos de TI

Métricas para Procesos y Proyectos de TI
de un Proyecto. Métricas para Procesos y Proyectos de TI Introducción a las Métricas. Métricas de

Introducción a las Métricas.

Procesos y Proyectos de TI Introducción a las Métricas. Métricas de Proceso. Métricas de Proyecto. Métricas

Métricas de

Proceso.

de TI Introducción a las Métricas. Métricas de Proceso. Métricas de Proyecto. Métricas Orientadas al

Métricas de

Proyecto.

Métricas. Métricas de Proceso. Métricas de Proyecto. Métricas Orientadas al Tamaño. Estimación para

Métricas

Orientadas al

Tamaño.

Estimación

para Proyectos

de Software

Estimación para Proyectos de Software
al Tamaño. Estimación para Proyectos de Software Introducción a la Estimación de Proyectos de Software.

Introducción a la Estimación de Proyectos de Software.

Introducción a la Estimación de Proyectos de Software. Recursos de Software. Estimación de Proyectos.

Recursos de

Software.

de Proyectos de Software. Recursos de Software. Estimación de Proyectos. Estimación Basada en

Estimación de

Proyectos.

Recursos de Software. Estimación de Proyectos. Estimación Basada en Problemas. Calendarización de

Estimación

Basada en

Problemas.

Calendarización de Proyectos de Software

en Problemas. Calendarización de Proyectos de Software Introducción a la Canlendarización de Proyectos de

Introducción a la Canlendarización de Proyectos de Software.

a la Canlendarización de Proyectos de Software. La Canlendarización de Proyectos. Distribución del

La Canlendarización de Proyectos.

de Proyectos de Software. La Canlendarización de Proyectos. Distribución del Esfuerzo. Refinamiento de las Tareas

Distribución del

Esfuerzo.

de Proyectos. Distribución del Esfuerzo. Refinamiento de las Tareas Principales. La competencia que

Refinamiento de las Tareas Principales.

La competencia que asignatura es: la dirigir, tecnologías de
La competencia
que
asignatura es:
la
dirigir,
tecnologías de

el

estudiante

debe

lograr

al

final

de

la

Conocer las herramientas y habilidades de

dirección de proyectos que le permitan

de

controlar

y

gestionar

proyectos

la mano con la información global.

3
3
Índice del Contenido UNIVERSIDAD PRIVADA TELESUP I. PREFACIO 02 II. DESARROLLO DE LOS CONTENIDOS 03

Índice del Contenido

UNIVERSIDAD PRIVADA TELESUP

Índice del Contenido UNIVERSIDAD PRIVADA TELESUP I. PREFACIO 02 II. DESARROLLO DE LOS CONTENIDOS 03 -
Índice del Contenido UNIVERSIDAD PRIVADA TELESUP I. PREFACIO 02 II. DESARROLLO DE LOS CONTENIDOS 03 -

I.

PREFACIO

02

II.

DESARROLLO DE LOS CONTENIDOS

03 - 119

UNIDAD DE APRENDIZAJE 1: GENERALIDADES DE LA DIRECCIÓN DE PROYECTOS DE TI

05-37

1. Introducción

06

 

a. Presentación y contextualización

06

b. Competencia (logro)

06

c. Capacidades

06

d. Actitudes

06

e. Ideas básicas y contenido

06

2. Desarrollo de los temas

07-33

 

a. Tema 01: Fundamentos de la Dirección de Proyectos.

07

b. Tema 02: Gestión de Alcance del Proyecto.

12

c. Tema 03: Gestión de los Riesgos del Proyecto.

18

d. Tema 04: Gestión del Tiempo de un Proyecto.

24

3. Lecturas recomendadas

34

4. Actividades

34

5. Autoevaluación

35

6. Resumen

37

UNIDAD DE APRENDIZAJE 2: MÉTRICAS PARA PROCESOS Y PROYECTOS DE TI

38-59

1. Introducción

39

 

a. Presentación y contextualización

39

b. Competencia (logro)

39

c. Capacidades

39

d. Actitudes

39

e. Ideas básicas y contenido

39

2. Desarrollo de los temas

40-55

 

a. Tema 01: Introducción a las Métricas.

40

b. Tema 02: Métricas de Proceso.

44

c. Tema 03: Métricas de Proyecto.

48

d. Tema 04: Métricas Orientadas al Tamaño.

51

3. Lecturas recomendadas

56

4. Actividades

56

5. Autoevaluación

57

6. Resumen

59

UNIDAD DE APRENDIZAJE 3: ESTIMACIÓN PARA PROYECTOS DE SOFTWARE

60- 89

1. Introducción

61

 

a. Presentación y contextualización

61

b. Competencia (logro)

61

c. Capacidades

61

d. Actitudes

61

e. Ideas básicas y contenido

61

2. Desarrollo de los temas

62-85

 

a. Tema 01: Introducción a la Estimación de Proyectos de Software.

62

b. Tema 02: Recursos de Software.

67

c. Tema 03: Estimación de Proyectos.

71

d. Tema 04: Estimación Basada en Problemas.

75

3. Lecturas recomendadas

86

4. Actividades

86

5. Autoevaluación

87

6. Resumen

89

UNIDAD DE APRENDIZAJE 4: CALENDARIZACIÓN DE PROYECTOS DE SOFTWARE

90-116

1.

Introducción

91

a. Presentación y contextualización

91

b. Competencia

91

c. Capacidades

91

d. Actitudes

91

e. Ideas básicas y contenido

91

2.

Desarrollo de los temas

92-112

a. Tema 01: Introducción a la Calendarización de Proyectos de Software.

92

b. Tema 02: La Calendarización de Proyectos.

97

c. Tema 03: Distribución del Esfuerzo.

103

d. Tema 04: Refinamiento de las tareas Principales.

108

3.

Lecturas recomendadas

113

4.

Actividades

113

5.

Autoevaluación

114

6.

Resumen

116

III.

GLOSARIO

117

IV.

FUENTES DE INFORMACIÓN

118

V.

SOLUCIONARIO

119

4
4
UNIVERSIDAD PRIVADA TELESUP
UNIVERSIDAD PRIVADA TELESUP

5

UNIVERSIDAD PRIVADA TELESUP Introducción a) Presentación y contextualización Los temas que se tratan en la

UNIVERSIDAD PRIVADA TELESUP

Introducción

UNIVERSIDAD PRIVADA TELESUP Introducción a) Presentación y contextualización Los temas que se tratan en la presente
UNIVERSIDAD PRIVADA TELESUP Introducción a) Presentación y contextualización Los temas que se tratan en la presente

a) Presentación y contextualización

Los temas que se tratan en la presente unidad didáctica, tienen por finalidad que usted aprenda los principios de la dirección de proyectos de tecnologías de la información globales. La importancia que tiene el énfasis estratégico 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 dirección de proyectos.

b) Competencia

Conoce los componentes que comprenden las generalidades de los proyectos

de TI.

c) Capacidades

1. Describe las principales características y comprende los fundamentos de un proyecto de TI.

2. Identifica el alcance de un proyecto conociendo las entradas, técnicas, 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 duración.

d) Actitudes

Desarrolla una actitud emprendedora mediante la toma de iniciativas en un proyecto de software.

Presenta interés por practicar de manera profesional la dirección de proyectos.

e) Presentación de Ideas básicas y contenido esenciales de la Unidad:

La Unidad de Aprendizaje 01: Generalidades de la Dirección de Proyectos de TI,

comprende el desarrollo de los siguientes temas:

TEMA 01: Fundamentos de la Dirección de Proyectos.

TEMA 02: Gestión de Alcance del Proyecto.

TEMA 03: Gestión de los Riesgos del Proyecto.

TEMA 04: Gestión del tiempo de un Proyecto.

6
6
UNIVERSIDAD PRIVADA TELESUP Fundamentos de la Dirección de Proyectos TEMA 1 Competencia: Describir las principales

UNIVERSIDAD PRIVADA TELESUP

Fundamentos

de la

Dirección de Proyectos

TEMA 1

TELESUP Fundamentos de la Dirección de Proyectos TEMA 1 Competencia: Describir las principales características y
TELESUP Fundamentos de la Dirección de Proyectos TEMA 1 Competencia: Describir las principales características y

Competencia:

Describir las principales características y comprender los fundamentos de un proyecto de TI.

7
7
Desarrollo de los Temas UNIVERSIDAD PRIVADA TELESUP Tema 01: Fundamentos de la Dirección de Proyectos

Desarrollo de los Temas

UNIVERSIDAD PRIVADA TELESUP

Desarrollo de los Temas UNIVERSIDAD PRIVADA TELESUP Tema 01: Fundamentos de la Dirección de Proyectos Los
Desarrollo de los Temas UNIVERSIDAD PRIVADA TELESUP Tema 01: Fundamentos de la Dirección de Proyectos Los
Desarrollo de los Temas UNIVERSIDAD PRIVADA TELESUP Tema 01: Fundamentos de la Dirección de Proyectos Los

Tema 01: Fundamentos de la Dirección de Proyectos

Los Fundamentos de la Dirección de Proyectos constituyen la suma de conocimientos en la profesión de dirección de proyectos. Al igual que en otras profesiones, como la abogacía, la medicina o las ciencias económicas, los conocimientos residen en los practicantes y académicos que los aplican y los desarrollan. Los Fundamentos de la Dirección de Proyectos completos incluyen prácticas tradicionales comprobadas y ampliamente utilizadas, así como prácticas innovadoras que están emergiendo en la profesión, incluyendo material publicado y no publicado. Como consecuencia, los Fundamentos de la Dirección de Proyectos están en constante evolución.

publicado y no publicado. Como consecuencia, los Fundamentos de la Dirección de Proyectos están en constante
publicado y no publicado. Como consecuencia, los Fundamentos de la Dirección de Proyectos están en constante
la Dirección de Proyectos están en constante evolución. QUE ES UN PROYECTO Un proyecto es un

QUE ES UN PROYECTO

Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único.

a cabo para crear un producto, servicio o resultado único.  Temporal Temporal significa que cada

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 serán o no podrán ser alcanzados, o cuando la necesidad del proyecto ya no exista y el proyecto sea cancelado. Temporal no necesariamente significa de corta duración; muchos proyectos duran varios años. En cada caso, sin embargo, la duración de un proyecto es limitada. Los proyectos no son esfuerzos continuos.

es limitada. Los proyectos no son esfuerzos continuos.  Productos, servicios o resultados únicos Un proyecto
 Productos, servicios o resultados únicos Un proyecto crea productos entregables únicos. Productos entregables son
 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 artículo 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 producción o la distribución.
8
8
UNIVERSIDAD PRIVADA TELESUP  Un resultado como, por ejemplo, salidas o documentos. Por ejemplo, de

UNIVERSIDAD PRIVADA TELESUP

Un resultado como, por ejemplo, salidas o documentos. Por ejemplo, de un proyecto de investigación se obtienen conocimientos que pueden usarse para determinar si existe o no una tendencia o si un nuevo proceso beneficiará a la sociedad.

 Elaboración gradual La elaboración gradual es una característica de los proyectos que acompaña a
 Elaboración gradual
La elaboración gradual es una característica de los
proyectos que acompaña a los conceptos de temporal
y único. “Elaboración 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 más
explícito y detallado a medida que el equipo del proyecto desarrolla un mejor y
más completo entendimiento de los objetivos y de los productos entregables.
Los siguientes ejemplos ilustran la elaboración gradual en dos áreas de
aplicación diferentes.
 El desarrollo de una planta de procesamiento químico comienza con la ingeniería de proceso
 El desarrollo de una planta de procesamiento químico comienza con la
ingeniería de proceso que define las características del proceso. Estas
características se utilizan para diseñar las unidades de procesamiento
principales. Esta información se convierte en la base para el diseño de
ingeniería, que define tanto el plano detallado de la planta como las
características mecánicas de las unidades de proceso y las instalaciones
auxiliares. Todo ello resulta en dibujos de diseño que se
elaboran para crear dibujos de fabricación y
construcción. Durante la construcción, se realizan las
interpretaciones y adaptaciones que sean necesarias,
que están sujetas a la aprobación correspondiente. Esta
elaboración 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 rotación.
9
9
UNIVERSIDAD PRIVADA TELESUP  El producto de un proyecto de desarrollo económico puede definirse inicialmente

UNIVERSIDAD PRIVADA TELESUP

El producto de un proyecto de desarrollo económico puede definirse inicialmente como: “Mejorar la calidad de vida de los residentes con ingresos más bajos de la comunidad X”. A medida que el proyecto avanza, los productos pueden describirse más específicamente como, por ejemplo:

“Proporcionar acceso a agua y comida a 500 residentes de bajos ingresos de la comunidad X”. La siguiente etapa de elaboración gradual podría centrarse exclusivamente en mejorar la producción y comercialización agrícola, considerando la provisión de agua como una segunda prioridad, a ser iniciada una vez que el componente agrícola esté en una etapa avanzada.

vez que el componente agrícola esté en una etapa avanzada. Proyectos frente a trabajos operativos Las

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 características:

Realizados por personas.

Restringidos por la limitación de los recursos.

Planificados, ejecutados y controlados.

Los proyectos y las operaciones difieren primordialmente en que las operaciones son continuas y repetitivas,
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 operación
continua es dar respaldo al negocio. Los
proyectos son diferentes porque el
proyecto concluye cuando se alcanzan sus
objetivos específicos, mientras que las operaciones adoptan un nuevo conjunto de
objetivos y el trabajo continúa.
10
10
UNIVERSIDAD PRIVADA TELESUP Los proyectos se llevan a cabo en todos los niveles de la

UNIVERSIDAD PRIVADA TELESUP

Los proyectos se llevan a cabo en todos los niveles de la organización y pueden involucrar a una sola persona o a varios miles. Pueden durar entre unas pocas semanas y varios años. 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
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 organización.
 Diseñar un nuevo vehículo de transporte.
 Desarrollar o adquirir un sistema de información nuevo o
modificado.
 Construir un edificio o una planta.
 Construir un sistema de abastecimiento de agua para una
comunidad.
 Realizar una campaña para un partido político.
 Implementar un nuevo procedimiento o proceso de negocio.
 Responder a una solicitud de contrato.
político.  Implementar un nuevo procedimiento o proceso de negocio.  Responder a una solicitud de
11
11
UNIVERSIDAD PRIVADA TELESUP Gestión de Alcance del Proyecto TEMA 2 Competencia: Identificar el alcance de

UNIVERSIDAD PRIVADA TELESUP

Gestión de Alcance del Proyecto

TEMA 2

PRIVADA TELESUP Gestión de Alcance del Proyecto TEMA 2 Competencia: Identificar el alcance de un proyecto
PRIVADA TELESUP Gestión de Alcance del Proyecto TEMA 2 Competencia: Identificar el alcance de un proyecto

Competencia:

Identificar el alcance de un proyecto conociendo las entradas, técnicas, herramientas, y salidas correspondientes.

12
12
UNIVERSIDAD PRIVADA TELESUP Tema 02: Gestión de Alcance del Proyecto La gestión del alcance del

UNIVERSIDAD PRIVADA TELESUP

Tema 02: Gestión de Alcance del Proyecto

La gestión del alcance del proyecto define lo que está y no está incluido en la realización del proyecto, es la definición de todos los requerimientos,planes, productos entregables y controles necesarios para desarrollar el proyecto satisfactoriamente y tener un cierre elegante. Además comprende las actividades orientadas a garantizar el cumplimiento de las tareas necesarias para lograr los objetivos del proyecto.

las actividades orientadas a garantizar el cumplimiento de las tareas necesarias para lograr los objetivos del

Según la guia de los fundamentos de la dirección de proyectos dice:

guia de los fundamentos de la dirección de proyectos dice: La Gestión del Alcance del Proyecto

La Gestión del Alcance del Proyecto incluye los procesos necesarios para asegurarse que el proyecto incluya todo el trabajo requerido, y sólo el trabajo requerido, para completar el proyecto satisfactoriamente.

proyecto incluya todo el trabajo requerido, y sólo el trabajo requerido, para completar el proyecto satisfactoriamente.
La palabra alcance puede definirse en lo siguiente:  Alcance del producto. Las características y
La palabra alcance puede definirse en lo siguiente:
 Alcance del producto. Las características 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 características especificadas.
El flujo de procesos de la gestión del alcance del proyecto es el siguiente:
 Planificación del alcance
 Verificación del alcance
 Definición del alcance
 Control del alcance

El siguiente resumen describe las caracteristicas principales de los procesos

Planificación del alcance El plan de gestión del alcance del proyecto es una herramienta de planificación que describe cómo 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
13
UNIVERSIDAD PRIVADA TELESUP  Entradas 1. Factores Ambientales de la Empresa 2. Activos de los

UNIVERSIDAD PRIVADA TELESUP

 Entradas 1. Factores Ambientales de la Empresa 2. Activos de los Procesos de la
Entradas
1. Factores Ambientales de la Empresa
2. Activos de los Procesos de la Organización
3. Acta de Constitución del Proyecto
4. Enunciado del Alcance del Proyecto Preliminar
5. Plan de Gestión del Proyecto
Herramientas y Técnicas
Juicio de Expertos para desarrollar el plan de gestión del
alcance del proyecto.Plantillas, Formularios, Normas
Plantillas de estructura de desglose del trabajo,
plantillas de plan de gestión del alcance y formularios de control de cambios en
el alcance del proyecto.
 Salidas “Plan de Gestión del Alcance del Proyecto “ El plan de gestión del
 Salidas
“Plan de Gestión del Alcance del Proyecto “
El plan de gestión del alcance del proyecto proporciona
orientación sobre cómo el equipo de dirección del
proyecto definirá, documentará, verificará, gestionará y
controlará el alcance del proyecto.
 Definición del alcance
La preparación de un enunciado del alcance del proyecto detallado es crítica
para el éxito del proyecto y se construye sobre la base de los principales
productos entregables, asunciones y restricciones que se documentan durante la
iniciación del proyecto en el enunciado del alcance del proyecto preliminar.
Durante la planificación, el alcance del proyecto se define y describe con mayor
especificidad porque se conoce más información acerca del proyecto.
porque se conoce más información acerca del proyecto.  Entradas 1. Activos de los Procesos de

Entradas

1.

Activos de los Procesos de la Organización

2.

Acta de Constitución del Proyecto

3.

Enunciado del Alcance del Proyecto Preliminar

4.

Plan de Gestión del Alcance del Proyecto

2.

Solicitudes de Cambio Aprobadas

14
14
UNIVERSIDAD PRIVADA TELESUP  Herramientas y Técnicas 1. Análisis del Producto Técnicas como desglose del

UNIVERSIDAD PRIVADA TELESUP

Herramientas y Técnicas

 Herramientas y Técnicas

1. Análisis del Producto Técnicas como desglose del producto, análisis de

2. sistemas, ingeniería de sistemas, ingeniería del valor, análisis del valor y análisis funcional.

3. Identificación de Alternativas Las más comunes son la tormenta de ideas y el pensamiento lateral.

4. Juicio de Expertos

5. Análisis 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,
 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 Gestión del Alcance del Proyecto (Actualizaciones).
 Verificación del alcance Si el proyecto se termina antes de lo previsto, el proceso
 Verificación del alcance
Si el proyecto se termina antes de lo previsto, el proceso de verificación del
alcance del proyecto debería establecer y
documentar el nivel y alcance de lo completado.
Entradas
1. Enunciado del Alcance del Proyecto.
2. Plan de Gestión 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 Ejecución del Proyecto.
15
15
UNIVERSIDAD PRIVADA TELESUP  Herramientas y Técnicas 1. Inspección Medir, examinar y verificar, a fin

UNIVERSIDAD PRIVADA TELESUP

Herramientas y Técnicas

1. Inspección Medir, examinar y verificar, a fin de determinar si el trabajo y los productos entregables cumplen con los requisitos y los criterios de aceptación del producto.

2. Las inspecciones pueden denominarse revisiones, revisiones de productos, auditorías y revisiones generales.La verificación del alcance es el proceso de obtener la aceptación 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 también se usa para gestionar los cambios reales cuando se producen, y está integrado con los demás procesos de control. Los cambios no controlados a menudo se denominan corrupción del alcance del proyecto. Los cambios son inevitables, con lo cual se impone algún tipo de proceso de control de cambios.

Entradas

1.

Enunciado del Alcance del Proyecto

2.

Estructura de Desglose del Trabajo

3.

Plan de Gestión del Alcance del Proyecto

4.

Informes de Rendimiento Los informes de rendimiento proporcionan información sobre el rendimiento del trabajo del proyecto, como por ejemplo los productos entregables intermedios que se han completado.

2.

Solicitudes de Cambio Aprobadas

3.

Información sobre el Rendimiento del Trabajo

16
16
UNIVERSIDAD PRIVADA TELESUP  Herramientas y Técnicas 1. Sistema de Control de Cambios Define los

UNIVERSIDAD PRIVADA TELESUP

Herramientas y Técnicas

1.

Sistema de Control de Cambios Define los procedimientos por los cuales pueden modificarse el alcance del proyecto y el alcance del producto.

2.

Análisis de Variación Las mediciones del rendimiento del proyecto se usan para evaluar la magnitud de la variación.

2.

Replanificación Con las solicitudes de cambio aprobadas que afecten al alcance del proyecto

3.

Sistema de Gestión de la Configuración Proporciona procedimientos para el estado de situación de los productos entregables

 Salidas 1. Enunciado del Alcance del Proyecto (Actualizaciones) 2. Estructura de Desglose del Trabajo
 Salidas
1.
Enunciado del Alcance del Proyecto (Actualizaciones)
2.
Estructura de Desglose del Trabajo (Actualizaciones)
2.
Línea Base del Alcance (Actualizaciones)
3.
Cambios Solicitados
4.
Acciones Correctivas Recomendadas
5.
Activos de los Procesos de la Organización
(Actualizaciones)
6.
Plan de Gestión del Proyecto (Actualizaciones)
5. Activos de los Procesos de la Organización (Actualizaciones) 6. Plan de Gestión del Proyecto (Actualizaciones)
17
17
UNIVERSIDAD PRIVADA TELESUP Gestión de los Riesgos del Proyecto TEMA 3 Competencia: Analizar los riesgos

UNIVERSIDAD PRIVADA TELESUP

Gestión de los Riesgos del Proyecto

TEMA 3

TELESUP Gestión de los Riesgos del Proyecto TEMA 3 Competencia: Analizar los riesgos con el fin
TELESUP Gestión de los Riesgos del Proyecto TEMA 3 Competencia: Analizar los riesgos con el fin

Competencia:

Analizar los riesgos con el fin de planificar y controlar un proyecto.

18
18
UNIVERSIDAD PRIVADA TELESUP Tema 03: Gestión de los Riesgos del Proyecto La gestión de riesgos

UNIVERSIDAD PRIVADA TELESUP

UNIVERSIDAD PRIVADA TELESUP Tema 03: Gestión de los Riesgos del Proyecto La gestión de riesgos de

Tema 03: Gestión de los Riesgos del Proyecto

La gestión 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 gestión de riesgos debe cubrir todas las áreas del proyecto, incluyendo los resultados (técnicos y de calidad), los programáticos (financiación, opinión pública, autorizaciones legales, aspectos políticos, etc.), los económicos (condiciones del contrato y costes de proyecto), programación y operación (soporte logístico, fiabilidad y seguridad).

(condiciones del contrato y costes de proyecto), programación y operación (soporte logístico, fiabilidad y seguridad).
(condiciones del contrato y costes de proyecto), programación y operación (soporte logístico, fiabilidad y seguridad).
Además la gestión de riesgos de un proyecto incluye los procesos relacionados con la planificación
Además la gestión de riesgos de un proyecto incluye los procesos relacionados con la
planificación de la gestión de riesgos, la identificación y el análisis de riesgos, las
respuestas a los riesgos, y el seguimiento y control de riesgos de un proyecto; la
mayoría de estos procesos se actualizan durante el proyecto, Según el PMBOK Los
procesos de Gestión de Riesgos incluyen lo siguiente:
 Planificación de la Gestión de Riesgos.
 Identificación de Riesgos.
 Análisis Cualitativo de Riesgo.
 Análisis Cuantitativo de Riesgos.
 Planificación de la Respuesta a los Riesgos.
 Seguimiento y Control de Riesgos.
A continuación se describe las principales actividades de los procesos de la gestión de riesgos
A continuación se describe las principales actividades de los procesos de la gestión de
riesgos del proyecto
 Planificación de la Gestión de Riesgos: Decidir cómo enfocar,
planificar y ejecutar las actividades de gestión de riesgos para
un proyecto. El proceso Planificación de la Gestión de
Riesgos debe completarse en las fases tempranas de
la planificación del proyecto, dado que es crucial para
realizar con éxito los demás procesos.
19
19
UNIVERSIDAD PRIVADA TELESUP o Entradas 1. Factores Ambientales de la Empresa. 2. Activos de los

UNIVERSIDAD PRIVADA TELESUP

o Entradas 1. Factores Ambientales de la Empresa. 2. Activos de los Procesos de la
o
Entradas
1. Factores Ambientales de la Empresa.
2. Activos de los Procesos de la Organización.
3. Enunciado del Alcance del Proyecto.
4. Plan de Gestión del Proyecto.
o
Herramientas y técnicas. Reuniones de planificación y análisis
o
Salidas. Plan de gestión de riesgos

La estructura de desglose enumera las categorías y sub-categorías donde se producen riesgos

las categorías y sub-categorías donde se producen riesgos Identificación de Riesgos Determinar qué riesgos pueden
Identificación de Riesgos Determinar qué riesgos pueden afectar al proyecto y documentar sus características. La
Identificación de Riesgos
Determinar qué riesgos pueden afectar al proyecto y documentar sus características.
La Identificación 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 iteración y quién 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
20
UNIVERSIDAD PRIVADA TELESUP Los interesados ajenos al equipo del proyecto pueden proporcionar información adicional

UNIVERSIDAD PRIVADA TELESUP

Los interesados ajenos al equipo del proyecto pueden proporcionar información adicional sobre los objetivos. El
Los interesados ajenos al equipo del proyecto pueden proporcionar información
adicional sobre los objetivos. El proceso Identificación de Riesgos suele llevar al
proceso Análisis Cualitativo de Riesgos. Como alternativa, puede llevar directamente
al proceso Análisis Cuantitativo de Riesgos cuando lo dirige un director de riesgos
experimentado. En algunas ocasiones, simplemente la identificación de un riesgo
puede sugerir su respuesta, y esto debe registrarse para realizar otros análisis y para
su implementación en el proceso Planificación de la Respuesta a los Riesgos.
Análisis Cualitativo de Riesgos
Priorizar los riesgos para realizar otros análisis o acciones posteriores, evaluando y
combinando su probabilidad de ocurrencia y su impacto. El Análisis Cualitativo de
Riesgos incluye los métodos para priorizar los riesgos identificados
para realizar otras acciones, como Análisis Cuantitativo de
Riesgos o Planificación de la Respuesta a los Riesgos. Las
organizaciones pueden mejorar el rendimiento del proyecto de
manera efectiva centrándose en los riesgos de alta prioridad.
El Análisis Cualitativo de Riesgos evalúa 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,
Las definiciones de los niveles de probabilidad e
impacto, así como las entrevistas a expertos,
pueden ayudar a corregir los sesgos que a menudo
están presentes en los datos usados en este
proceso. La criticidad temporal de acciones
relacionadas con riesgos puede magnificar la
importancia de un riesgo. Una evaluación de la
calidad de la información disponible sobre los riesgos del proyecto también ayuda a
comprender la evaluación de la importancia del riesgo para el proyecto.
21
21
UNIVERSIDAD PRIVADA TELESUP Análisis cuantitativo de riesgos Analizar numéricamente el efecto de los riesgos

UNIVERSIDAD PRIVADA TELESUP

Análisis cuantitativo de riesgos

Analizar numéricamente el efecto de los riesgos identificados en los objetivos generales del proyecto. Este proceso usa técnicas tales como la simulación Monte Carlo y el análisis mediante árbol de decisiones para:

Cuantificar los posibles resultados del proyecto y sus probabilidades.

Evaluar la probabilidad de lograr los objetivos específicos del proyecto.

Identificar los riesgos que requieren una mayor atención mediante la cuantificación de su contribución relativa al riesgo general del proyecto.

Identificar objetivos de coste, cronograma o alcance realistas y viables, dados los riesgos del proyecto.

Determinar la mejor decisión de dirección de proyectos cuando algunas condiciones o resultados son inciertos.

Planificación de la respuesta a los riesgos La Planificación de la Respuesta a los Riesgos

Planificación de la respuesta a los riesgos

La Planificación 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 después de los procesos Análisis Cualitativo de Riesgos y Análisis Cuantitativo de Riesgos. Incluye la identificación y asignación de una o más personas (el “propietario de la respuesta a los riesgos”) para que asuma la responsabilidad de cada respuesta a los riesgos acordada y financiada.

La Planificación de la Respuesta a los Riesgos aborda los riesgos en función de su

La Planificación de la Respuesta a los Riesgos aborda los riesgos en función de su prioridad, introduciendo recursos y actividades en el presupuesto, cronograma y plan de gestión del proyecto, según sea necesario. Las respuestas a los riesgos planificadas deben ser congruentes con la importancia del riesgo, tener un coste efectivo en relación al desafío, 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
22
UNIVERSIDAD PRIVADA TELESUP A menudo, es necesario seleccionar la mejor respuesta a los riesgos entre

UNIVERSIDAD PRIVADA TELESUP

A menudo, es necesario seleccionar la mejor respuesta a los riesgos entre varias opciones. La
A menudo, es necesario seleccionar la mejor respuesta
a los riesgos entre varias opciones. La sección
Planificación de la Respuesta a los Riesgos presenta
los enfoques comúnmente 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 están incluidas en el plan de gestión 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 supervisión, 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 ejecución de las respuestas a los

riesgos mientras se evalúa su efectividad.

El proceso Seguimiento y Control de Riesgos aplica técnicas, como el análisis de variación y de tendencias, que requieren el uso de datos de rendimiento generados durante la ejecución del proyecto. El proceso Seguimiento y Control de Riesgos, así como los demás procesos de gestión de riesgos, es un proceso continuo que se realiza durante la vida del proyecto.

así como los demás procesos de gestión de riesgos, es un proceso continuo que se realiza
como los demás procesos de gestión de riesgos, es un proceso continuo que se realiza durante
23
23
UNIVERSIDAD PRIVADA TELESUP Gestión del Tiempo de un Proyecto TEMA 4 Competencia: Estimar el tiempo

UNIVERSIDAD PRIVADA TELESUP

Gestión del Tiempo de un Proyecto

TEMA 4

TELESUP Gestión del Tiempo de un Proyecto TEMA 4 Competencia: Estimar el tiempo de un proyecto
TELESUP Gestión del Tiempo de un Proyecto TEMA 4 Competencia: Estimar el tiempo de un proyecto

Competencia:

Estimar el tiempo de un proyecto teniendo en cuenta las secuencias, recursos y duración.

24
24
UNIVERSIDAD PRIVADA TELESUP Tema 04: Gestión del Tiempo de un Proyecto Cuando se prepara un

UNIVERSIDAD PRIVADA TELESUP

UNIVERSIDAD PRIVADA TELESUP Tema 04: Gestión del Tiempo de un Proyecto Cuando se prepara un proyecto

Tema 04: Gestión del Tiempo de un Proyecto

Cuando se prepara un proyecto uno de los aspectos más 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 gestión del tiempo son:

o

Definición de las actividades.

o

Establecimiento de la secuencia de las actividades.

o

Estimación de recursos de las actividades.

o

Estimación de la duración de las actividades.

o

Desarrollo del cronograma.

recursos de las actividades. o Estimación de la duración de las actividades. o Desarrollo del cronograma.
DEFINICIÓN DE LAS ACTIVIDADES Definir las actividades del cronograma implica identificar y documentar el trabajo
DEFINICIÓN DE LAS ACTIVIDADES
Definir las actividades del cronograma implica identificar y documentar el trabajo que
se planifica realizar. El proceso Definición de las Actividades identificará los productos
entregables al nivel más bajo de la estructura de desglose del trabajo. Los
paquetes de trabajo del proyecto están planificados (descompuestos) en
componentes más pequeños 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 definición y planificación de las actividades del cronograma están
implícitas 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 Información de la gestión de proyectos y herramientas Incluyen la disponibilidad de los sistemas de Información de la gestión de proyectos y herramientas de software para la elaboración de cronogramas.

Activos de los Procesos de la Organización Contienen las políticas formales e informales existentes relacionadas con la planificación de actividades, los Contienen las políticas formales e informales existentes relacionadas con la planificación de actividades, los procedimientos y las guías que se tienen en cuenta al desarrollar las definiciones de las actividades.

25
25
UNIVERSIDAD PRIVADA TELESUP Enunciado del Alcance del Proyecto Los productos entregables del proyecto, las restricciones

UNIVERSIDAD PRIVADA TELESUP

Enunciado del Alcance del Proyecto Los productos entregables del proyecto, las restricciones y las asunciones documentadas en el enunciado del 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 definición de las La estructura de desglose del trabajo es una entrada principal para la definición de las actividades del cronograma.

Plan de Gestión del Proyecto El plan de gestión del proyecto contiene el plan de gestión del cronograma, que proporciona El plan de gestión del proyecto contiene el plan de gestión del cronograma, que proporciona orientación sobre el desarrollo y la planificación de las actividades del cronograma y del plan de gestión del alcance del proyecto.

Herramientas y Técnicas

Descomposición Implica subdividir los paquetes de trabajo del proyecto en componentes más pequeños y más fáciles 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 identificación de riesgos, los productos entregables esperados y cualquier otra información descriptiva.

Planificación Gradual Las actividades del cronograma pueden existir a distintos niveles de detalle en el ciclo de vida del proyecto. Durante los inicios de la planificación estratégica, cuando la información 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 Planificación Dos componentes de planificación son:

o

o

Cuenta de Control. Se puede ubicar un punto de control de gestión en puntos de gestión seleccionados (componentes específicos en niveles seleccionados) de la estructura de desglose del trabajo. Estos puntos de control se utilizan como base para la planificación cuando todavía 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.

Paquete de Planificación. Un paquete de planificación 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.

se utiliza para planificar el contenido del trabajo conocido que no tiene actividades del cronograma detalladas.
26
26
UNIVERSIDAD PRIVADA TELESUP Salidas  Lista de Actividades  Atributos de la Actividad Identifican los

UNIVERSIDAD PRIVADA TELESUP

Salidas

Lista de Actividades

Atributos de la Actividad Identifican los múltiples atributos relacionados con cada actividad del cronograma. Incluyen el identificador de la actividad, los códigos de la actividad, la descripción de la actividad, las actividades predecesoras, las actividades sucesoras, las relaciones lógicas, 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 lógicas entre
ESTABLECIMIENTO DE LA SECUENCIA DE LAS ACTIVIDADES
Implica identificar y documentar las relaciones lógicas entre las actividades del
cronograma. Las actividades del cronograma pueden estar ordenadas de forma lógica
con relaciones de precedencia adecuadas, así como también 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.
Herramientas y Técnicas  Método de Diagramación por Precedencia (PDM) Esta técnica también se denomina
Herramientas y Técnicas
 Método de Diagramación por Precedencia (PDM)
Esta técnica también se denomina actividad en el nodo (AON), y es el método
utilizado por la mayoría de los paquetes de software de gestión 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.
Inicio a Fin.
En el PDM, final a inicio es el tipo de relación de
precedencia más comúnmente usado.
o
27
27
UNIVERSIDAD PRIVADA TELESUP Las relaciones inicio a fin raramente se utilizan  Método de Diagramación

UNIVERSIDAD PRIVADA TELESUP

Las relaciones inicio a fin raramente se utilizan

Método de Diagramación con Flechas (ADM) Es un método 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 preparación de redes de actividades del cronograma del proyecto. Éstas pueden incluir un proyecto completo o solamente una parte de él.

Determinación 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 programación.

o

Dependencias externas. Son las que implican una relación entre las actividades del proyecto y las actividades que no pertenecen al proyecto.

Aplicación de Adelantos y Retrasos El equipo de dirección del proyecto determina las dependencias que pueden requerir un adelanto o un retraso para definir con exactitud la relación lógica.

Salidas Diagramas de Red del Cronograma del Proyecto. Lista de Actividades (Actualizaciones). Atributos de la Actividad (Actualizaciones). Cambios Solicitados.

del Proyecto. Lista de Actividades (Actualizaciones). Atributos de la Actividad (Actualizaciones). Cambios Solicitados.
del Proyecto. Lista de Actividades (Actualizaciones). Atributos de la Actividad (Actualizaciones). Cambios Solicitados.
del Proyecto. Lista de Actividades (Actualizaciones). Atributos de la Actividad (Actualizaciones). Cambios Solicitados.
del Proyecto. Lista de Actividades (Actualizaciones). Atributos de la Actividad (Actualizaciones). Cambios Solicitados.
del Proyecto. Lista de Actividades (Actualizaciones). Atributos de la Actividad (Actualizaciones). Cambios Solicitados. 28
28
28
UNIVERSIDAD PRIVADA TELESUP ESTIMACIÓN DE RECURSOS DE LAS ACTIVIDADES Involucra determinar cuáles son los recursos

UNIVERSIDAD PRIVADA TELESUP

ESTIMACIÓN DE RECURSOS DE LAS ACTIVIDADES Involucra determinar cuáles son los recursos (personas, equipos, o
ESTIMACIÓN DE RECURSOS DE LAS ACTIVIDADES
Involucra determinar cuáles son los recursos (personas,
equipos, o material) y qué cantidad de cada recurso se
utilizará, y cuándo estará disponible cada recurso para realizar
las actividades del proyecto. El proceso Estimación de Recursos de las Actividades se
coordina estrechamente con el proceso Estimación de Costes.
Entradas  Factores Ambientales de la Empresa.  Activos de los Procesos de la Organización.
Entradas
 Factores Ambientales de la Empresa.
 Activos de los Procesos de la Organización.
 Lista de Actividades.
 Atributos de la Actividad.
 Disponibilidad de Recursos.
 Plan de Gestión del Proyecto.

Herramientas y Técnicas

o

Juicio de Expertos

o

Análisis de Alternativas

o

Datos de Estimación Publicados Varias empresas publican periódicamente los índices de producción actualizados y los costes unitarios de los recursos para una extensa variedad de industrias, materiales y equipos, en diferentes países y en diferentes ubicaciones geográficas dentro de esos países.

o

Software de Gestión de Proyectos Tiene la capacidad de ayudar a planificar, organizar y gestionar los conjuntos de recursos, y de desarrollar estimaciones de recursos.

o

Estimación 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 más detalle. Se estiman las necesidades de recursos de cada una de las partes inferiores y más 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
29
UNIVERSIDAD PRIVADA TELESUP Salidas  Requisitos de Recursos de las Actividades Es una identificación y

UNIVERSIDAD PRIVADA TELESUP

Salidas

Requisitos de Recursos de las Actividades Es una identificación y descripción 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 jerárquica de los recursos identificados por categoría y tipo de recurso.

Calendario de Recursos (Actualizaciones) Documenta los días laborables y n laborables que determinan aquellas fechas en las que cada recurso específico, ya sea una persona o un material, puede estar activo u ocioso.

Cambios Solicitados

puede estar activo u ocioso.  Cambios Solicitados DESARROLLO DEL CRONOGRAMA Es un proceso iterativo,
DESARROLLO DEL CRONOGRAMA Es un proceso iterativo, determina las fechas de inicio y finalización planificadas
DESARROLLO DEL CRONOGRAMA
Es un proceso iterativo, determina las fechas de inicio y finalización
planificadas para las actividades del proyecto. El desarrollo del cronograma exige que
se revisen y se corrijan las estimaciones de duración y las estimaciones de los
recursos para crear un cronograma del proyecto aprobado que pueda servir como
línea base con respecto a la cual poder medir el avance.
Entradas  Activos de los Procesos de la Organización Como un calendario del proyecto 
Entradas
 Activos de los Procesos de la Organización Como un
calendario del proyecto
 Enunciado del Alcance del Proyecto
30
30
UNIVERSIDAD PRIVADA TELESUP  Hay dos categorías principales de restricciones de tiempo que se tienen

UNIVERSIDAD PRIVADA TELESUP

Hay dos categorías principales de restricciones de tiempo que se tienen en cuenta durante el desarrollo del cronograma:

- Las fechas impuestas para el inicio o la finalización de las actividades pueden usarse para restringir el inicio o la finalización a que se produzca no antes de una fecha especificada o no después 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 finalización de ciertos productos entregables para una fecha específica.

 Lista de Actividades  Atributos de la Actividad  Diagramas de Red del Cronograma
 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 Duración de la Actividad
 Plan de Gestión del Proyecto Contiene el plan de gestión del cronograma, el
plan de gestión de costes, el plan de gestión del alcance del proyecto y el plan
de gestión de riesgos. Estos planes guían el desarrollo del cronograma.

Herramientas y Técnicas

Análisis de la Red del Cronograma Emplea un modelo de cronograma y diversas técnicas analíticas, para calcular las fechas de inicio y finalización tempranas y tardías, y las fechas de inicio y finalización planificadas para las partes no completadas de las actividades del cronograma del proyecto

Método del Camino Crítico Es una técnica de análisis que calcula las fechas de inicio y finalización tempranas y tardías teóricas para todas las actividades del cronograma, sin considerar las limitaciones de recursos.

Compresión 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 técnicas de compresión del cronograma incluyen: Intensificación y Ejecución rápida.

31
31
UNIVERSIDAD PRIVADA TELESUP  Análisis “¿Qué pasa si ?” Un análisis de la red del

UNIVERSIDAD PRIVADA TELESUP

Análisis “¿Qué pasa si

?”

Un análisis 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 ampliación de

la duración de un diseño específico o la aparición de factores externos, como una

huelga o un cambio en el proceso de permisos.

 Nivelación de Recursos Se usa para abordar las actividades del cronograma que deben realizarse
 Nivelación 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 críticos necesarios sólo en ciertos
momentos o en cantidades limitadas, o para mantener el
uso de recursos seleccionados a un nivel constante durante períodos específicos
del trabajo del proyecto.
 Método de Cadena Crítica Combina los enfoques determinístico y probabilístico.
Agrega colchones de duración que son actividades del cronograma no laborables,
para mantener el enfoque en las duraciones de las actividades planificadas.

Software de Gestión de Proyectos El software de gestión de proyectos para la

elaboración 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 gestión de proyectos para llevar a cabo los

requisitos de otras Áreas de Conocimiento, como la estimación de costes por

período y la simulación del cronograma en el análisis cuantitativo de riesgos.

como la estimación de costes por período y la simulación del cronograma en el análisis cuantitativo
32
32
UNIVERSIDAD PRIVADA TELESUP  Calendarios Aplicables Los calendarios del proyecto y los calendarios de recursos

UNIVERSIDAD PRIVADA TELESUP

Calendarios Aplicables Los calendarios del proyecto y los calendarios de recursos identifican los períodos 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 análisis de la red del cronograma para desarrollar un cronograma del proyecto viable.

Modelo de Cronograma Se utilizan con métodos manuales o con software de gestión de proyectos para realizar el análisis 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 o Diagramas
Salidas
 Cronograma del Proyecto
o
Diagramas de red del cronograma del proyecto
o
Diagramas de barras
o
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 Gestión del Proyecto (Actualizaciones)
Calendario del Proyecto (Actualizaciones)  Cambios Solicitados  Plan de Gestión del Proyecto (Actualizaciones) 33
33
33
UNIVERSIDAD PRIVADA TELESUP Lecturas Recomendadas  EL ALCANCE DE UN PROYECTO

UNIVERSIDAD PRIVADA TELESUP

Lecturas Recomendadas

UNIVERSIDAD PRIVADA TELESUP Lecturas Recomendadas  EL ALCANCE DE UN PROYECTO
UNIVERSIDAD PRIVADA TELESUP Lecturas Recomendadas  EL ALCANCE DE UN PROYECTO

EL ALCANCE DE UN PROYECTO

http://www.tress.com.mx/esp/Portals/0/Documentos%20varios/Bolet%C3%ADn%

20mensual/Abril/Alcance%20proyecto.pdf

GESTIÓN DEL TIEMPO DE UN PROYECTO

http://www.slideshare.net/CulturaEmpresarial/gestion-del-tiempo-presentation

Actividades y Ejercicios

Actividades y Ejercicios 1. 2. En un documento en Word indique el alcance de un
Actividades y Ejercicios 1. 2. En un documento en Word indique el alcance de un
1. 2.
1.
2.

En un documento en Word indique el alcance de un proyecto para un sistema de comercialización en una tienda de computadoras y determina los posibles riesgos. Envíalo a través de "Proyectos".

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. Envíalo a través de "Riesgos de un Proyecto".

y matriculas en un colegio y determina los posibles riesgos. Envíalo a través de "Riesgos de
34
34
UNIVERSIDAD PRIVADA TELESUP Autoevaluación 1) Los procesos de la gestión del tiempo no son: a.

UNIVERSIDAD PRIVADA TELESUP

Autoevaluación

UNIVERSIDAD PRIVADA TELESUP Autoevaluación 1) Los procesos de la gestión del tiempo no son: a. Definición
UNIVERSIDAD PRIVADA TELESUP Autoevaluación 1) Los procesos de la gestión del tiempo no son: a. Definición

1)

Los procesos de la gestión del tiempo no son:

a. Definición de las actividades.

b. Establecimiento de la secuencia de las actividades.

c. Estimación de recursos de las actividades.

d. Estimación de la duración de las actividades.

e. Control de riesgos.

2)

¿Cuáles son los fundamentos de la dirección de proyectos?

a. No constituyen la suma de conocimientos en la profesión de dirección de

proyectos.

b. Constituyen la suma de conocimientos en la profesión de dirección de proyectos.

c. Constituyen la suma de conocimientos de la programación.

d. Solo la consolidación 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 más completo entendimiento de los objetivos y de los productos entregables:

a. Las métricas de un proyecto.

b. El refinamiento de un proyecto.

c. Alcance de un proyecto.

d. La ingeniería del software.

e. La gerencia del proyecto.

4)

La gestión 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 características 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 límite.

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 ilícito 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
35
UNIVERSIDAD PRIVADA TELESUP 6) Es una característica de los Proyectos frente a trabajos operativos:  

UNIVERSIDAD PRIVADA TELESUP

6)

Es una característica de los Proyectos frente a trabajos operativos:

 

a. Realizados por las maquinas.

 

b. Restringidos por la limitación de los recursos.

 

c. Son cronometrados.

 

d. Restringidos por la códigos éticos.

 

e. Limitados por el software.

 

7)

Es

un

proceso

iterativo,

determina

las

fechas

de

inicio

y

finalización

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 características especificadas, es:

 

a. Alcance del producto.

 

b. Planificación del alcance.

c. Alcance del proyecto.

d. Definición del alcance.

e. Verificación del alcance.

9)

Es aquella que involucra determinar cuáles son los recursos (personas,

equipos, o material) y qué cantidad de cada recurso se utilizará, y cuándo

estará disponible cada recurso para realizar las actividades del proyecto:

a. Estimación de recursos de las actividades.

b. Estimación de punto de función.

c. Estimación de procesos.

d. Estimación de costo de software.

e. Estimación de líneas de código.

10) La gestión de Riesgos no incluye:

a. Planificación de la Gestión de Riesgos.

b. Identificación de Riesgos.

c. Seguimiento y Control de Riesgos.

d. Planificación de la Respuesta a los Riesgos.

e. Análisis de Procedimiento.

36
36
UNIVERSIDAD PRIVADA TELESUP Resumen UUNNIIDDAADD DDEE AAPPRREENNDDIIZZAAJJEE II:: Entendemos que los fundamentos de la

UNIVERSIDAD PRIVADA TELESUP

Resumen

UUNNIIDDAADD DDEE AAPPRREENNDDIIZZAAJJEE II:: Entendemos que los fundamentos de la dirección de proyectos constituyen la
UUNNIIDDAADD DDEE AAPPRREENNDDIIZZAAJJEE II::
Entendemos que los fundamentos de la dirección de proyectos constituyen la suma de
conocimientos en la profesión de dirección de proyectos. Al igual que en otras
profesiones, como la abogacía, la medicina o las ciencias económicas, los
conocimientos residen en los practicantes y académicos que los aplican y los
desarrollan. Los Fundamentos de la Dirección de Proyectos completos incluyen
prácticas tradicionales comprobadas y ampliamente utilizadas, así como prácticas
innovadoras que están emergiendo en la profesión, incluyendo material publicado y no
publicado. Como consecuencia, los Fundamentos de la Dirección de Proyectos están
en constante evolución.
Podemos decir que la gestión del alcance del proyecto define lo que está y no
Podemos decir que la gestión del alcance del proyecto define lo que está y no
Podemos decir que la gestión del alcance del proyecto define lo que está y no
Podemos decir que la gestión del alcance del proyecto define lo que está y no

Podemos decir que la gestión del alcance del proyecto define lo que está y no está incluido en la realización del proyecto, es la definición de todos los requerimientos,planes, productos entregables y controles necesarios para desarrollar el proyecto satisfactoriamente y tener un cierre elegante. Además comprende las actividades orientadas a garantizar el cumplimiento de las tareas necesarias para lograr los objetivos del proyecto.

tareas necesarias para lograr los objetivos del proyecto. Sabemos que la gestión de riesgos debe cubrir
tareas necesarias para lograr los objetivos del proyecto. Sabemos que la gestión de riesgos debe cubrir

Sabemos que la gestión de riesgos debe cubrir todas las áreas del proyecto, incluyendo los resultados (técnicos y de calidad), los programáticos (financiación, opinión pública, autorizaciones legales, aspectos políticos, etc.), los económicos (condiciones del contrato y costes de proyecto), programación y operación (soporte logístico, fiabilidad y seguridad). Además la gestión de riesgos de un proyecto incluye los procesos relacionados con la planificación de la gestión de riesgos, la identificación y el análisis de riesgos, las respuestas a los riesgos, y el seguimiento y control de riesgos de un proyecto; la mayoría de estos procesos se actualizan durante el proyecto.

Dentro de la gestión del tiempo de un proyecto hay que definir las actividades del cronograma implica identificar y documentar el trabajo que se planifica realizar. El proceso Definición de las Actividades identificará los productos entregables al nivel más bajo de la estructura de desglose del trabajo. Los paquetes de trabajo del proyecto están planificados (descompuestos) en componentes más pequeños 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.

una base con el fin de estimar, establecer el cronograma, ejecutar, y supervisar y controlar el
37
37
UNIVERSIDAD PRIVADA TELESUP
UNIVERSIDAD PRIVADA TELESUP
UNIVERSIDAD PRIVADA TELESUP 38

38

UNIVERSIDAD PRIVADA TELESUP Introducción a) Presentación y contextualización: En esta unidad el alumno aprenderá a

UNIVERSIDAD PRIVADA TELESUP

Introducción

UNIVERSIDAD PRIVADA TELESUP Introducción a) Presentación y contextualización: En esta unidad el alumno aprenderá a
UNIVERSIDAD PRIVADA TELESUP Introducción a) Presentación y contextualización: En esta unidad el alumno aprenderá a

a) Presentación y contextualización:

En esta unidad el alumno aprenderá a definir un proyecto, los posibles riesgos, y las métricas 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 recopilación y evaluación de la información entendiendo la importancia de los indicadores, que brindan la visión necesaria para mejorar la calidad y productividad de un proyecto.

b) Competencia:

Analiza las funciones de las métricas de procesos para estimar el tamaño del proyecto, planificando el progreso objetivo y las mejoras necesarias de dicho proyecto.

c) Capacidades:

1. Describe los procesos de aplicación de las métricas para la determinación del tamaño de un proyecto.

2. Reconoce los principales factores que influyen en los procesos de desempeño organizacional.

3. Analiza las tendencias de un proyecto para planificar las mejoras correspondientes, evaluando la información adquirida.

4. Evalúa la productividad mediante el tamaño del software a través de las líneas de código y la calidad de una aplicación a través de los puntos de función.

d) Actitudes:

Muestra interés por mejorar la precisión en las estimaciones de tiempo, costo y

recursos.

Actúa con responsabilidad personal ante las funciones métricas de un proyecto.

e) Presentación de Ideas básicas y contenidos esenciales de la Unidad:

La Unidad de Aprendizaje 02: Métricas para Procesos y Proyectos de TI,

comprende el desarrollo de los siguientes temas:

TEMA 01: Introducción a las Métricas.

TEMA 02: Métricas de Proceso.

TEMA 03: Métricas de Proyecto.

TEMA 04: Métricas Orientadas al Tamaño.

39
39
UNIVERSIDAD PRIVADA TELESUP Introducción a las Métricas TEMA 1 Competencia: Describir los procesos de aplicación

UNIVERSIDAD PRIVADA TELESUP

Introducción

a las

Métricas

TEMA 1

PRIVADA TELESUP Introducción a las Métricas TEMA 1 Competencia: Describir los procesos de aplicación de las
PRIVADA TELESUP Introducción a las Métricas TEMA 1 Competencia: Describir los procesos de aplicación de las

Competencia:

Describir los procesos de aplicación de las métricas para la determinación del tamaño de un proyecto.

40
40
Desarrollo de los Temas UNIVERSIDAD PRIVADA TELESUP Tema 01: Introducción a las Métricas La medición

Desarrollo de los Temas

UNIVERSIDAD PRIVADA TELESUP

Desarrollo de los Temas UNIVERSIDAD PRIVADA TELESUP Tema 01: Introducción a las Métricas La medición permite
Desarrollo de los Temas UNIVERSIDAD PRIVADA TELESUP Tema 01: Introducción a las Métricas La medición permite
Desarrollo de los Temas UNIVERSIDAD PRIVADA TELESUP Tema 01: Introducción a las Métricas La medición permite

Tema 01: Introducción a las Métricas

La medición permite obtener la visión del proceso y el proyecto pues proporciona un mecanismo
La medición permite obtener la visión del proceso y el proyecto
pues proporciona un mecanismo para lograr una evaluación
objetiva. Lord Kevin dijo una vez:
Cuando puede medir aquello de lo que está hablando y
expresarlo en números sabe algo acerca de ello, pero cuando
no puede medir, cuando no puede expresarlo en números, 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 ingeniería del software ha tomado en serio las palabras de Lord Kelvin. Más no sin frustración y algo más que un poco de controversial. La medición se aplica al proceso de software con la finalidad de mejorarlo de manera continua. La medición se utiliza a lo largo de un proyecto de software como apoyo en la estimación, el control de calidad, la valoración de la productividad y el control del proyecto. Finalmente, la medición la aplican los ingenieros de software como auxiliar en la evaluación de la calidad de los productos de trabajo y para apoyar la toma de decisiones conforme avanza en un proyecto.

evaluación de la calidad de los productos de trabajo y para apoyar la toma de decisiones

En su guía acerca de la medición 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 líneas base para comparaciones con evaluaciones futuras”; 2) para evaluar “determinando el estado con respecto a los planes”; 3) para predecir mediante “la compresión de relaciones entre procesos y productos y construir modelos de dichas relaciones”; y 4) para mejorar al “identificar barricadas, causas raíz, ineficiencias y otras oportunidades para mejorar la calidad del producto y el desempeño del proceso”.

causas raíz, ineficiencias y otras oportunidades para mejorar la calidad del producto y el desempeño del
41
41
UNIVERSIDAD PRIVADA TELESUP La medición es una herramienta de gestoría. Si se lleva a cabo

UNIVERSIDAD PRIVADA TELESUP

La medición es una herramienta de gestoría. Si se lleva a cabo gradualmente proporciona visión al gestor del proyecto. Y, como resultado, apoya al gestor del proyecto y al equipo de software a tomar decisiones que conducirán a un proyecto exitoso. Una métrica es una metodología de planificación, desarrollo y mantenimiento de sistemas de información. Esta metodología propia está basada en el modelo de procesos del ciclo de vida de desarrollo

sistemas de información. Esta metodología propia está basada en el modelo de procesos del ciclo de
sistemas de información. Esta metodología propia está basada en el modelo de procesos del ciclo de
Procesos principales de la métrica  Planificación de Sistemas de Información (PSI).  Desarrollo de
Procesos principales de la métrica
 Planificación de Sistemas de Información (PSI).
 Desarrollo de Sistemas de Información (DSI). Debido a su complejidad, está a su
vez dividido en cinco procesos:
 Estudio de Viabilidad del Sistema (EVS).
 Análisis del Sistema de Información (ASI).
 Diseño del Sistema de Información (DSI).
 Construcción del Sistema de Información (CSI).
 Implantación y Aceptación del Sistema (IAS).
 Mantenimiento de Sistemas de Información (MSI).
Interfaces de las Métricas Las métricas proporcionan también cuatro interfaces que definen actividades orientadas a
Interfaces de las Métricas
Las métricas proporcionan también cuatro interfaces que definen actividades
orientadas a la mejora y perfeccionamiento de los procesos principales para garantizar
la consecución del objetivo del desarrollo.
Los procesos principales de una métrica son:
 Gestión de proyectos (GP).
 Seguridad (SEG).
 Aseguramiento de la Calidad (CAL).
 Gestión de la Configuración (GC).
Técnicas de las Métricas Las métricas se distinguen entre:  Técnicas de desarrollo (Casos de
Técnicas de las Métricas
Las métricas se distinguen entre:
 Técnicas de desarrollo (Casos de Uso, Diagramas de Clases, Diagrama de flujo
de datos, etc.).
 Técnicas de gestión de proyectos (Técnicas de estimación, Staffing Size,
Planificación, etc.)
 Prácticas (Análisis de impacto, Presentaciones, Prototipado, etc.)
42
42
UNIVERSIDAD PRIVADA TELESUP Perfiles de una métrica Una métrica establece los siguientes perfiles para los

UNIVERSIDAD PRIVADA TELESUP

Perfiles de una métrica

Una métrica establece los siguientes perfiles para los participantes en el proceso de desarrollo de un sistema de información:

Directivo (Comité de Dirección, Directores de Usuarios,

Jefe de Proyecto (Responsable de Implantación, Responsable de Seguridad,

Consultor (Consultor Informático, Técnico de Sistemas).

Analista (Analista, Administrador de Bases de Datos,

Programador.

Informático, Técnico de Sistemas).  Analista (Analista, Administrador de Bases de Datos,  Programador.
Métricas en los dominios del proceso y el proyecto Las métricas del proceso se recopilan

Métricas en los dominios del proceso y el proyecto

Las métricas 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 métricas 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 “críticas”; 4) ajusto el flujo de trabajo o las tareas, y 5) evalúe 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 métricas para
Las medidas que recopila un equipo de proyecto y las que
convierte en métricas para emplearlas durante un proyecto
también se pueden transmitir a quienes tienen la
responsabilidad de mejorar el proceso de software. Por esta
razón, muchas de las mismas métricas se usan tanto en el
dominio del proceso como en el del proyecto.
43
43
UNIVERSIDAD PRIVADA TELESUP Métricas de Proceso TEMA 2 Competencia: Reconocer los principales factores que influyen

UNIVERSIDAD PRIVADA TELESUP

Métricas de Proceso

TEMA 2

UNIVERSIDAD PRIVADA TELESUP Métricas de Proceso TEMA 2 Competencia: Reconocer los principales factores que influyen en
UNIVERSIDAD PRIVADA TELESUP Métricas de Proceso TEMA 2 Competencia: Reconocer los principales factores que influyen en

Competencia:

Reconocer los principales factores que influyen en los procesos de desempeño organizacional.

44
44
UNIVERSIDAD PRIVADA TELESUP Tema 02: Métricas de Proceso La única forma racional de mejorar cualquier

UNIVERSIDAD PRIVADA TELESUP

Tema 02: Métricas de Proceso

La única forma racional de mejorar cualquier proceso es medir sus atributos específicos, desarrollar un

La única forma racional de mejorar cualquier proceso es medir sus atributos específicos, desarrollar un conjunto de métricas significativas con base en dichos atributos y luego emplear las métricas de software y su impacto en la mejora del proceso del software es importante destacar que el proceso sólo es uno de varios “factores controlables en la mejora de la calidad del software y el desempeño organizacional”.

La eficacia de un proceso de software se mide indirectamente. Esto es, se deduce un
La eficacia de un proceso de software se mide indirectamente. Esto es, se deduce un
La eficacia de un proceso de software se mide indirectamente. Esto es, se deduce un

La eficacia de un proceso de software se mide indirectamente. Esto es, se deduce un conjunto de métricas 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 planificación, concordancia con la planificación y

otras medidas. También se deducen métricas de proceso al medir las características de tareas especificadas de ingeniería de software.

También se deducen métricas de proceso al medir las características de tareas especificadas de ingeniería de
También se deducen métricas de proceso al medir las características de tareas especificadas de ingeniería de

Grady argumenta que existen usos “privados y públicos” para diferentes tipos de datos de proceso. Como es natural que los ingenieros de software especiales sean sensibles al uso de las métricas recopiladas sobre una base particular, dichos datos deben de ser privados para el individuo y funcionar como un indicador sólo para él. Los ejemplos de métricas privadas incluyen índices de defecto por individuo, índices de defecto por componente de software y errores encontrados durante el desarrollo.

de defecto por individuo, índices de defecto por componente de software y errores encontrados durante el
45
45
UNIVERSIDAD PRIVADA TELESUP La filosofía de “datos de proceso privados” se ajusta bien al enfoque

UNIVERSIDAD PRIVADA TELESUP

La filosofía de “datos de proceso privados” se ajusta bien al enfoque de proceso personal
La filosofía 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 métricas de proceso son privadas para el
equipo del proyecto de software, pero públicas
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 técnicas formales y líneas de código
o puntos de función por módulo o función. Dichos datos los revisa el equipo para
descubrir indicadores que mejoren su desempeño.
Las métricas públicas por lo general asimilan información que originalmente era
privada para los individuos y equipos. Los índices de defecto al nivel del proyecto (que
no se atribuyen por ningún motivo a un individuo), esfuerzo, planificación y datos
relacionados se recopilan y evalúan con la finalidad de descubrir indicadores que
pueden mejorar el desempeño del proceso organizacional.
y evalúan con la finalidad de descubrir indicadores que pueden mejorar el desempeño del proceso organizacional.
46
46
UNIVERSIDAD PRIVADA TELESUP Las métricas del proceso de software ofrecen beneficios significativos conforme una

UNIVERSIDAD PRIVADA TELESUP

Las métricas del proceso de software ofrecen beneficios significativos conforme una organización que trabaja en mejorar su grado global de madurez del proceso. Sin embargo, como todas las métricas, éstas pueden emplearse mal y crear más problemas de los que solucionan. Grady sugiere un “conjunto de reglas de etiqueta para las métricas del software”, adecuado tanto para gestores como para profesionales conforme instituyen un programa de métricas del proceso:

Aplique sentido común y sensibilidad organizativa cuando interprete dichos datos métricos.

Ofrezca retroalimentación regular a los individuos y equipos que recopilan medidas y métricas.

No utilice las métricas para evaluar a los individuos.

Trabaje con los profesionales y equipos para establecer metas claras y las métricas que se emplearán para conseguirlas.

Nunca use métricas para amenazar a los individuos o equipos.

Los datos métricos que indican un área problema no deben considerarse “negativos”. Dichos datos sólo son un indicador de la mejora del proceso.

No se obsesione con una sola métrica y excluya otras métricas importantes.

un indicador de la mejora del proceso.  No se obsesione con una sola métrica y
Conforme una organización se siente más cómoda con la recopilación y el empleo de las

Conforme una organización se siente más cómoda con la recopilación y el empleo de las métricas de proceso, la deducción de indicadores simples da la pauta para un enfoque más riguroso llamado mejora estadística del proceso del software (MEPS). En esencia, el MEPS aplica el análisis de la falla del software para recopilar información acerca de todos los errores y defectos que se encuentran al desarrollar y utilizar una aplicación, sistema o producto.

47
47
UNIVERSIDAD PRIVADA TELESUP Métricas de Proyecto TEMA 3 Competencia: Analizar las tendencias de un proyecto

UNIVERSIDAD PRIVADA TELESUP

Métricas

de

Proyecto

TEMA 3

UNIVERSIDAD PRIVADA TELESUP Métricas de Proyecto TEMA 3 Competencia: Analizar las tendencias de un proyecto para
UNIVERSIDAD PRIVADA TELESUP Métricas de Proyecto TEMA 3 Competencia: Analizar las tendencias de un proyecto para

Competencia:

Analizar las tendencias de un proyecto para planificar las mejoras correspondientes, evaluando la información adquirida.

48
48
UNIVERSIDAD PRIVADA TELESUP Tema 03: Métricas de Proyecto A diferencia de las métricas del proceso

UNIVERSIDAD PRIVADA TELESUP

UNIVERSIDAD PRIVADA TELESUP Tema 03: Métricas de Proyecto A diferencia de las métricas del proceso de

Tema 03: Métricas de Proyecto

A diferencia de las métricas del proceso de software que se utilizan con propósitos estratégicos,
A diferencia de las métricas del proceso de software que se utilizan con propósitos
estratégicos, las métricas del proyecto de software son tácticas. Es decir, un gerente
de proyecto y un equipo de software emplean las métricas del proyecto y los
indicadores que se deducen de ellas para adaptar el flujo de trabajo del proyecto y las
actividades técnicas.
La primera aplicación de las métricas del proyecto en la
mayoría de proyectos de software ocurre durante la
estimación. Las métricas 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 planificación del proyecto). El gestor del proyecto emplea dichos datos para
supervisar y controlar el progreso.
Mientras comienza el trabajo técnico, las otras medidas del proyecto comienzan a
tener significado. Se miden los índices de producción representados en términos de
modelos creados, horas de revisión, puntos de función y líneas fuente entregadas.
representados en términos de modelos creados, horas de revisión, puntos de función y líneas fuente entregadas.
49
49
UNIVERSIDAD PRIVADA TELESUP Además se les da seguimiento a los errores descubiertos durante cada tarea

UNIVERSIDAD PRIVADA TELESUP

Además se les da seguimiento a los errores descubiertos durante cada tarea de ingeniería del

Además se les da seguimiento a los errores descubiertos durante cada tarea de ingeniería del software. Conforme el software evoluciona desde los requisitos hasta el diseño, se recopilan métricas técnicas para valorar la calidad del diseño y mejorar los indicadores que influirán en el enfoque que se adopte para la generación y prueba del código. La finalidad de las métricas 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 técnico para mejorar la calidad. Conforme la calidad mejora los defectos se minimizan, y mientras eso sucede también se reduce la cantidad de reelaboración requerida

durante el proyecto. Esto conduce una reducción en el costo global del proyecto.

MEDICIÓN EL SOFTWARE La medición de software se clasifica en dos categorías 1) medidas directas
MEDICIÓN EL SOFTWARE La medición de software se clasifica en dos categorías 1) medidas directas
MEDICIÓN EL SOFTWARE La medición de software se clasifica en dos categorías 1) medidas directas

MEDICIÓN EL SOFTWARE

MEDICIÓN EL SOFTWARE La medición de software se clasifica en dos categorías 1) medidas directas del
MEDICIÓN EL SOFTWARE La medición de software se clasifica en dos categorías 1) medidas directas del

La medición de software se clasifica en dos categorías 1) medidas directas del proceso de software (por ejemplo, costo y esfuerzo aplicados) y del producto (por ejemplo, líneas de código producidas, rapidez de ejecución 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 métricas del proyecto se consolidan con el fin de crear métricas del proceso que sean públicas para la organización de software como un todo. Pero ¿cómo combina una organización las métricas provenientes de diferentes individuos o proyectos?

como un todo. Pero ¿cómo combina una organización las métricas provenientes de diferentes individuos o proyectos?
como un todo. Pero ¿cómo combina una organización las métricas provenientes de diferentes individuos o proyectos?
como un todo. Pero ¿cómo combina una organización las métricas provenientes de diferentes individuos o proyectos?
 

Con fines ilustrativos, considérese 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 demás cosas se mantienen iguales, ¿qué equipo es más eficiente al descubrir errores

a

lo largo del proceso? Puesto que no se conoce ni el tamaño ni la complejidad de los

proyectos, no se puede responder esta pregunta. Sin embargo, si las mediciones se normalizan, es posible crear métricas de software que posibiliten la comparación a promedios organizacionales más amplios. De esta forma, las métricas orientadas tanto

al

tamaño como a la función están normalizadas.

50
50
UNIVERSIDAD PRIVADA TELESUP Métricas Orientadas al Tamaño TEMA 4 Competencia: Evaluar la productividad mediante el

UNIVERSIDAD PRIVADA TELESUP

Métricas Orientadas al Tamaño

TEMA 4

PRIVADA TELESUP Métricas Orientadas al Tamaño TEMA 4 Competencia: Evaluar la productividad mediante el tamaño
PRIVADA TELESUP Métricas Orientadas al Tamaño TEMA 4 Competencia: Evaluar la productividad mediante el tamaño

Competencia:

Evaluar la productividad mediante el tamaño del software a través de las líneas de código y la calidad de una aplicación a través de los puntos de función.

51
51
UNIVERSIDAD PRIVADA TELESUP Tema 04: Métricas Orientadas al Tamaño Las métricas del software orientadas al

UNIVERSIDAD PRIVADA TELESUP

UNIVERSIDAD PRIVADA TELESUP Tema 04: Métricas Orientadas al Tamaño Las métricas del software orientadas al

Tema 04: Métricas Orientadas al Tamaño

Las métricas del software orientadas al tamaño preceden de la normalización de las medidas de
Las
métricas
del
software
orientadas
al
tamaño
preceden de la normalización de las medidas de calidad
o productividad considerando el tamaño del software
que se ha producido. Si una organización de software
mantiene registros simples es factible crear una tabla de
medidas orientadas al tamaño, como se muestra en la
siguiente tabla a continuación. En dicha tabla se menciona cada proyecto de desarrollo
de software que se ha completado en años pasados, así como las medidas
correspondientes para dichos proyectos. Como se advierte en la entrada de la tabla,
para el proyecto Alfa: 12 100 líneas de código se desarrollaron con 24 personas-mes
de esfuerzo a un costo de 168 000 dólares.

Se debe notar que el esfuerzo y el costo registrados en la tabla representan todas las actividades de ingeniería de software (análisis, diseño, código y prueba), no sólo codificación. Información adicional del proyecto Alfa indica que se desarrollaron 365 páginas de documentación, se registraron 134 errores antes de que el software fuese liberado y se encontraron 29 defectos después de la liberación al cliente dentro del primer año de operación. Tres personas trabajaron en el desarrollo del software para el proyecto alfa.

dentro del primer año de operación. Tres personas trabajaron en el desarrollo del software para el
dentro del primer año de operación. Tres personas trabajaron en el desarrollo del software para el
dentro del primer año de operación. Tres personas trabajaron en el desarrollo del software para el
El desarrollo de métricas que se asimilen con las métricas similares procedentes de otros proyectos
El desarrollo de métricas que se asimilen con las métricas similares procedentes de otros proyectos
El desarrollo de métricas que se asimilen con las métricas similares procedentes de otros proyectos
El desarrollo de métricas que se asimilen con las métricas similares procedentes de otros proyectos

El desarrollo de métricas que se asimilen con las métricas similares procedentes de otros proyectos requiere elegir líneas de código como valor de normalización. A partir de los datos rudimentarios de la tabla se desarrolla un conjunto de métricas simples orientadas al tamaño para cada proyecto: errores por KLDC (miles de líneas de código), defectos por KLDC, costo por KLDC, páginas de documentación por KLDC. Además se pueden calcular otras métricas interesantes: errores por persona-mes, KLDC por persona-mes, costo por página de documentación.

calcular otras métricas interesantes: errores por persona-mes, KLDC por persona-mes, costo por página de documentación.
calcular otras métricas interesantes: errores por persona-mes, KLDC por persona-mes, costo por página de documentación.
calcular otras métricas interesantes: errores por persona-mes, KLDC por persona-mes, costo por página de documentación.
calcular otras métricas interesantes: errores por persona-mes, KLDC por persona-mes, costo por página de documentación.
calcular otras métricas interesantes: errores por persona-mes, KLDC por persona-mes, costo por página de documentación.
calcular otras métricas interesantes: errores por persona-mes, KLDC por persona-mes, costo por página de documentación.
calcular otras métricas interesantes: errores por persona-mes, KLDC por persona-mes, costo por página de documentación.
calcular otras métricas interesantes: errores por persona-mes, KLDC por persona-mes, costo por página de documentación.
52
52
UNIVERSIDAD PRIVADA TELESUP MÉTRICAS ORIENTADAS AL TAMAÑO Proyecto LDC Esfuerzo $(000) Pág. Doc. Errores

UNIVERSIDAD PRIVADA TELESUP

MÉTRICAS ORIENTADAS AL TAMAÑO

Proyecto

LDC

Esfuerzo

$(000)

Pág. Doc.

Errores

Defectos

Personal

Alfa

12100

24

168

365

134

29

3

Beta

27200

62

440

1224

321

86

5

Gamma

20200

43

314

1050

256

64

6

Las métricas orientadas al tamaño 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 líneas de código 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 fácilmente contarse, que muchos modelos de estimación de software existentes usan LDC o KLDC como entrada clave, y que ya existe un gran cuerpo de bibliografía y datos publicados para LDC.

Por otra parte, los detractores argumentan que las medidas LDC dependen del lenguaje de programación, que, cuando se considera la productividad, castigan los programas bien diseñados, pero más cortos, que no pueden amoldar con facilidad lenguajes que no provienen del proceso y cuyo empleo en la estimación requiere un nivel de detalle que sería difícil de lograr (es decir, el planificador debe estimar que las LDC se producirán mucha antes que el análisis y el diseño se hayan completado).

MÉTRICAS ORIENTADAS A LA FUNCIÓN

Las métricas de software orientadas a la función emplean como un valor de normalización una medida de la funcionalidad que entrega la aplicación. La métrica orientada a la función utilizada con mayor amplitud es el punto de función (PF). El cálculo del punto de función se basa en características del dominio de información y la complejidad del software.

El cálculo del punto de función se basa en características del dominio de información y la
53
53
UNIVERSIDAD PRIVADA TELESUP El punto de función, al igual que la medida LDC, es controversial.

UNIVERSIDAD PRIVADA TELESUP

El punto de función, al igual que la medida LDC, es controversial. Los partidarios afirman que el PF es independiente del lenguaje de programación, característica que lo hace ideal para aplicaciones que utilizan lenguajes convencionales y no procedimentales, y que se basa en datos que es más probable que se conozcan temprano en la evolución de un proyecto, lo que hace al PF más atractivo como enfoque de estimación. Los detractores afirman que el método requiere cierta “prestidigitación” en cuanto a que el cálculo se basa en los datos subjetivos más que objetivos, que el conteo del dominio de información (y otras dimensiones) puede ser difícil de recopilar después del hecho, y que el PF no tiene significado directo: es sólo un número.

RECONCILIACIÓN DE LAS MÉTRICAS LDC Y PF

La relación entre líneas de código y puntos de función depende del lenguaje de programación en que se implementen el software y la calidad del diseño. 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 función que se ofrecerá por medio de la aplicación (programa) se puede estimar a partir de pormenorizar los grandes componentes de datos que se emplearán o proporcionarán. Más aún, está estimación de la función

debe estar correlacionada tanto con la cantidad de LDC que se desarrollará como con

el esfuerzo de desarrollo necesario.

debe estar correlacionada tanto con la cantidad de LDC que se desarrollará como con el esfuerzo

La tabla siguiente ofrece estimaciones burdas del número promedio de líneas de código que se requieren para construir un punto de función en varios lenguajes de programación Una revisión 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 programación convencional como Ada, COBOL o C. La utilización de la información contenida en la tabla permite “tomar como contrafuego” el software existe para estimar el número de puntos de función, una vez que se conozca

el

número total de enunciados del lenguaje de programación. Se ha encontrado que

las métricas basadas en puntos de función y LDC son indicadoras relativamente

precisas del esfuerzo y el costo del desarrollo del software. Sin embargo, emplear LCD

PF en la estimación requiere establecer una línea de referencia histórica de información.

y

54
54
UNIVERSIDAD PRIVADA TELESUP En el contexto del proceso y las métricas del proyecto, la preocupación

UNIVERSIDAD PRIVADA TELESUP

En el contexto del proceso y las métricas del proyecto, la preocupación principal la generan
En el contexto del proceso y las métricas del proyecto, la preocupación
principal la generan la productividad y la calidad: medidas de la “salida”
de desarrollo de software como función del esfuerzo y el tiempo
aplicado y medidas de la “aptitud para el uso” de los productos de
trabajo obtenidos. Respecto a propósitos de mejora del proceso y planeación del
proyecto, el interés es histórico. ¿Cuál fue la productividad de desarrollo del software
en los proyectos pasados? ¿Cuál fue la calidad del software que se produjo? ¿Cómo
se pueden extrapolar al presente la productividad y la calidad pasadas? ¿Cómo puede
ayudar a mejorar el proceso y planificar nuevos proyectos con mayor precisión?

LÍNEAS DE COMANDOS

Lenguaje de LDC por punto de función programación Promedio Mediana Bajo Alto Access 35 38
Lenguaje de
LDC por punto de función
programación
Promedio
Mediana
Bajo
Alto
Access
35
38
15
47
Ada
154
-
104
205
APS
86
83
20
184
ASP 69
62
-
32
127
Ensamblador
337
315
91
127
C
162
109
33
704
C++
66
53
29
178
Clipper
38
39
27
70
COBOL
77
77
14
400
Cool: Gen/IEF
38
31
10
180
Culprit
51
-
-
-
DBase IV
52
-
-
-
Easytrieve 1
33
34
25
41
Excel 47
46
-
31
63
Focus
43
42
32
56
FORTRAN
-
-
-
-
Foxpro
32
35
25
35
Ideal
66
52
34
203
IEF/Cool:Gen
38
31
10
180
Informix
42
31
24
57
Java
63
53
77
-
JavaScript
58
63
42
75
JCL
91
123
26
150
JSP
59
-
-
-
Lotus Notes
21
22
15
25
Mantis
71
27
22
250
Mapper
118
81
16
245
Natural
60
52
22
141
Oracle
30
35
4
217
PeopleSoft
33
32
30
40
Perl
60
-
-
-
PL/1
78
67
22
263
PowerBuilder
32
31
11
105
REXX
67
-
-
-
RPG II/III
61
49
24
155
SAS
40
41
33
49
Smalltalk
26
19
10
55
SQL
40
37
7
110
VBScript36
34
27
50
-
Visual Basic
47
42
16
158
55
55
UNIVERSIDAD PRIVADA TELESUP Lecturas Recomendadas informacin  MÉTRICAS, ESTIMACIÓN Y PLANIFICACIÓN EN PROYECTOS 

UNIVERSIDAD PRIVADA TELESUP

Lecturas Recomendadas

UNIVERSIDAD PRIVADA TELESUP Lecturas Recomendadas informacin  MÉTRICAS, ESTIMACIÓN Y PLANIFICACIÓN EN PROYECTOS 

informacin

informacin

MÉTRICAS, ESTIMACIÓN Y PLANIFICACIÓN EN PROYECTOS

INGENIERÍA DEL SOFTWARE MÉTRICA - DESARROLLO DE SISTEMAS DE INFORMACIÓN

http://www.slideshare.net/LuisEduardoPelaez/mtrica-desarrollo-de-sistemas-de-

http://www.willydev.net/descargas/WillyDEV_PlaneaSoftware.Pdf

Actividades y Ejercicios

Actividades y Ejercicios 1. 2. En un documento en Word indique las métricas del

1.

2.

En un documento en Word indique las métricas del proceso y

mejora de un sistema de comercialización para una tienda de

computadoras también determine las métricas orientadas a la

función, además mencione y describa el proceso realizado para

dicho caso.

Envíalo a través de "Métricas".

En un documento en Word indique cuáles son las métricas

apropiadas para el proceso y para el producto; y elabore un

ejemplo donde se empleen ambas.

Envíalo a través de "Métricas Apropiadas".

y para el producto; y elabore un ejemplo donde se empleen ambas. Envíalo a través de
56
56
UNIVERSIDAD PRIVADA TELESUP Autoevaluación 1) Las métricas públicas por lo general asimilan

UNIVERSIDAD PRIVADA TELESUP

Autoevaluación

UNIVERSIDAD PRIVADA TELESUP Autoevaluación 1) Las métricas públicas por lo general asimilan
UNIVERSIDAD PRIVADA TELESUP Autoevaluación 1) Las métricas públicas por lo general asimilan

1)

Las

métricas

públicas

por

lo

general

asimilan información que

 

Los índices de defecto al nivel del proyecto

 

(que

no

se

atribuyen

por

ningún motivo a un individuo), esfuerzo,

planificación y datos relacionados se recopilan y evalúan con la finalidad de

descubrir

indicadores

que

pueden

mejorar

el

desempeño 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 prediseñada 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 líneas de código.

e. Administrar los recursos reutilizables en un proyecto.

3)

No corresponde a los perfiles de una métrica:

 

a. Directivo (comité de dirección, directores de usuarios).

b. Jefe de proyecto (responsable de implantación, responsable de seguridad).

c. Consultor (consultor informático, técnico de sistemas).

d. Programador (diseño de planificaciones del directivo).

e. Analista (analista, administrador de bases de datos).

 

4)

La filosofía de Humphrey con respecto a los “datos de proceso privados” se centra en:

a. Ayudar a comprender los valores éticos para que la función del ingeniero mejore.

b. Alentar para que el trabajo individual del ingeniero del software mejore.

c. Incentivar a generar mayores ingresos para la organización del software.

d. Proyectar a controlar la piratería 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 común y sensibilidad organizativa cuando se interprete datos métricos.

b. Ofrecer retroalimentación regular a los individuos y equipos que recopilan medidas y métricas.

c. No utilizar las métricas para evaluar a los individuos.

d. Trabajar con los profesionales y equipos para establecer metas claras.

e. Usar métricas para amenazar a los individuos o equipos.

57
57
UNIVERSIDAD PRIVADA TELESUP 6) Adaptan el flujo de trabajo del proyecto y las actividades técnicas:

UNIVERSIDAD PRIVADA TELESUP

6)

Adaptan el flujo de trabajo del proyecto y las actividades técnicas:

a. Las métricas del proyecto.

b. Las planificaciones de las métricas.

c. Las métricas de software.

d. El equipo de software.

e. Las métricas del cronograma.

7)

Es una de las finalidades de las métricas del proyecto:

a. Valorar sólo 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 aplicación de las métricas en un proyecto ocurre con:

a. La valorización.

b. La depreciación.

c. La estimación.

d. El alcance.

e. El propósito.

9)

¿Cuál es la medida clave de las métricas orientadas al tamaño?

a. PF (Punto de función).

b. EU(Esfuerzo utilizado).

c. LDC (Línea de códigos).

d. PP (Parámetro de productividad).

e. DP (duración del proyecto).

10) ¿Cuál es la medida clave de las métricas orientadas a la función?

a. FL (Función lógica).

b. TD(tiempo de duración del proyecto).

c. PF (Punto de función).

d. LDC (Línea de códigos).

e. EF (Esfuerzo utilizado).

58
58
UNIVERSIDAD PRIVADA TELESUP Resumen UUNNIIDDAADD DDEE AAPPRREENNDDIIZZAAJJEE IIII:: La comunidad de la ingeniería del

UNIVERSIDAD PRIVADA TELESUP

Resumen

UUNNIIDDAADD DDEE AAPPRREENNDDIIZZAAJJEE IIII:: La comunidad de la ingeniería del software ha tomado en serio
UUNNIIDDAADD DDEE AAPPRREENNDDIIZZAAJJEE IIII::
La comunidad de la ingeniería del software ha tomado en serio las palabras de Lord
Kelvin. ¡Más no sin frustración y algo más que un poco de controversial.
La medición se aplica al proceso de software con la finalidad de mejorarlo de manera
continua. La medición se utiliza a lo largo de un proyecto de software como apoyo en
la estimación, el control de calidad, la valoración de la productividad y el control del
proyecto. Finalmente, la medición la aplican los ingenieros de software como auxiliar
en la evaluación 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
La eficacia de un proceso de software se mide indirectamente. Esto es, se deduce un
La eficacia de un proceso de software se mide indirectamente. Esto es, se deduce un
La eficacia de un proceso de software se mide indirectamente. Esto es, se deduce un

La eficacia de un proceso de software se mide indirectamente. Esto es, se deduce un conjunto de métricas 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 planificación, concordancia con la planificación y otras medidas. También se deducen métricas de proceso al medir las características de tareas especificadas de ingeniería de software.

de tareas especificadas de ingeniería de software. La primera aplicación de las métricas del proyecto en
de tareas especificadas de ingeniería de software. La primera aplicación de las métricas del proyecto en
de tareas especificadas de ingeniería de software. La primera aplicación de las métricas del proyecto en

La primera aplicación de las métricas del proyecto en la mayoría de proyectos de software ocurre durante la estimación. Las métricas 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 planificación del proyecto). El gestor del proyecto emplea dichos datos para supervisar y controlar el progreso.

El desarrollo de métricas que se asimilen con las métricas similares procedentes de

otros proyectos requiere elegir líneas de código como valor de normalización. A partir

de los datos rudimentarios de la tabla se desarrolla un conjunto de métricas simples

orientadas al tamaño para cada proyecto: errores por KLDC (miles de líneas de

código), defectos por KLDC, costo por KLDC, páginas de documentación por KLDC.

Además se pueden calcular otras métricas interesantes: errores por persona-mes,

KLDC por persona-mes, costo por página de documentación.

otras métricas interesantes: errores por persona-mes, KLDC por persona-mes, costo por página de documentación.
59
59
UNIVERSIDAD PRIVADA TELESUP
UNIVERSIDAD PRIVADA TELESUP

60

UNIVERSIDAD PRIVADA TELESUP Introducción a) Presentación y contextualización Los temas que se tratan en la

UNIVERSIDAD PRIVADA TELESUP

Introducción

UNIVERSIDAD PRIVADA TELESUP Introducción a) Presentación y contextualización Los temas que se tratan en la presente
UNIVERSIDAD PRIVADA TELESUP Introducción a) Presentación y contextualización Los temas que se tratan en la presente

a) Presentación y contextualización

Los temas que se tratan en la presente unidad didáctica, tienen por finalidad que el estudiante aprenda cómo se realiza el proceso de gestión del proyecto de software y qué importancia juega en el desarrollo de cualquier proyecto. Comprenderá que la estimación es la base de todas las demás actividades en planificación de un proyecto y sirve como una guía para una buena ingeniería del software, no es en absoluto aconsejable embarcarse sin ella. Adquirirá experiencia, buena información histórica y buenas técnicas de estimación.

b) Competencia

Planifica la forma de realizar estimaciones mediante técnicas de

descomposición, tamaño de software, líneas de código 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 según las habilidades requeridas.

3. Analiza estimaciones mediante las técnicas de descomposición y tamaño del software.

4. Reconoce las principales funciones de las estimaciones de LDC y PF.

d) Actitudes

Desarrolla la creatividad, la innovación, la actitud emprendedora y el respeto a

la honestidad intelectual.

Muestra una actitud emprendedora mediante la toma de iniciativas, promoción

de actividades y toma de decisiones en relación a la actividad asignada.

e) Presentación de Ideas básicas y contenido esenciales de la Unidad:

La Unidad de Aprendizaje 03: Estimación para Proyectos de Software,

comprende el desarrollo de los siguientes temas:

TEMA 01: Introducción a la Estimación de Proyectos de Software.

TEMA 02: Recursos de Software.

TEMA 03: Estimación de Proyectos.

TEMA 04: Estimación Basada en Problemas.

61
61
UNIVERSIDAD PRIVADA TELESUP Introducción a la Estimación de Proyectos de Software TEMA 1 Competencia: Desarrollar

UNIVERSIDAD PRIVADA TELESUP

Introducción a la Estimación de Proyectos de Software

TEMA 1

a la Estimación de Proyectos de Software TEMA 1 Competencia: Desarrollar aplicando adecuado. las las
a la Estimación de Proyectos de Software TEMA 1 Competencia: Desarrollar aplicando adecuado. las las

Competencia:

Desarrollar

aplicando

adecuado.

las

las

estimaciones

medidas

y

el

necesarias

software

62
62
Desarrollo de los Temas UNIVERSIDAD PRIVADA TELESUP Tema 01: Introducción a la Estimación de Proyectos

Desarrollo de los Temas

UNIVERSIDAD PRIVADA TELESUP

Desarrollo de los Temas UNIVERSIDAD PRIVADA TELESUP Tema 01: Introducción a la Estimación de Proyectos de
Desarrollo de los Temas UNIVERSIDAD PRIVADA TELESUP Tema 01: Introducción a la Estimación de Proyectos de
Desarrollo de los Temas UNIVERSIDAD PRIVADA TELESUP Tema 01: Introducción a la Estimación de Proyectos de

Tema 01: Introducción a la Estimación de Proyectos de Software

La planificación requiere que los gestores técnicos 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 automáticamente algún grado de incertidumbre. Para citar a Frederick Brooks:

“Nuestras técnicas de estimación están probablemente desarrolladas. Más seriamente, reflejan una suposición no expresada que es bastante incierta, es decir:

que todo irá bien…

Más seriamente, reflejan una suposición no expresada que es bastante incierta, es decir: que todo irá

Puesto que no estamos seguros de nuestras estimaciones, con frecuencia los gestores e software carecen de la cortés testarudez para hace que la gente haga un buen producto”. Aunque la estimación es tanto un arte como una ciencia, esta importante actividad no necesita realizarse en una forma improvisada. Existen técnicas útiles para la estimación de tiempo y esfuerzo. Las métricas del proceso y del proyecto ofrecen la perspectiva histórica y la energía para la generación de estimaciones cuantitativas. La experiencia (de toda la gente involucrada) puede auxiliar enormemente conforme se desarrollan y revisan las estimaciones. Puesto que la estimación coloca los cimientos para las demás actividades de planificación del proyecto, y ésta proporciona la ruta para las demás actividades de planificación del proyecto, y ésta proporciona la ruta para la ingeniería del software exitosa, se estaría mal aconsejando si se embarca sin ella.

y ésta proporciona la ruta para la ingeniería del software exitosa, se estaría mal aconsejando si

La estimación de recursos, costo y programa de trabajo para una tarea de ingeniería de software requiere experiencia, acceso a buena información histórica (métricas) y el valor para comprometerse con predicciones cuantitativas cuando la información cualitativa es todo lo que existe. La estimación implica riesgo inherente, y éste conduce a la incertidumbre.

63
63
UNIVERSIDAD PRIVADA TELESUP La disponibilidad de información histórica tiene una fuerte influencia en el riesgo

UNIVERSIDAD PRIVADA TELESUP

La disponibilidad de información histórica tiene una fuerte influencia en el riesgo de la estimación.

La disponibilidad de información histórica tiene una fuerte influencia en el riesgo de la estimación. Al mirar en retrospectiva, se pueden emular las cosas que funcionaron y mejorar las áreas donde surgieron los problemas. Cuando hay disponibles amplias métricas 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 estimación 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 están sujetos a eventuales cambios, la incertidumbre y el riesgo de la estimación se incrementan peligrosamente. El planificador y, en forma más 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 ingeniería del software (por ejemplo, modelos de proceso incrementar) asumen una visión iterativa del desarrollo. En tales enfoques es posible, aunque no siempre aceptable políticamente, reexaminar las estimaciones (cuando se conozca más información) y modificarlas cuando el cliente cambia los requisitos.

El proceso de planificación del proyecto.

El objetivo de la planificación del proyecto de software es proporcionar un marco de trabajo que permita al gestor estimar razonablemente recursos, costo y programa de trabajo. Además, 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 planificación. 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 planificación del proyecto de software.

secciones siguientes se estudiará cada una de las actividades asociadas con la planificación del proyecto de
64
64
UNIVERSIDAD PRIVADA TELESUP Ámbito del software y factibilidad El ámbito del software describe las funciones

UNIVERSIDAD PRIVADA TELESUP

UNIVERSIDAD PRIVADA TELESUP Ámbito del software y factibilidad El ámbito del software describe las funciones y

Ámbito del software y factibilidad

El ámbito del software describe las funciones y características que se entregarán 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 desempeño, las restricciones, las interfaces y la confiabilidad que acotan el sistema. El ámbito se define al usar una de las dos técnicas siguientes:

se define al usar una de las dos técnicas siguientes: 1. Después de una comunicación con

1. Después de una comunicación con todos los participantes se desarrolla una descripción narrativa del ámbito del software. 2. Los usuarios finales desarrollan un conjunto de casos de uso.

usuarios finales desarrollan un conjunto de casos de uso. Las funciones descritas en el enunciado del
Las funciones descritas en el enunciado del ámbito (o dentro de los casos de uso)

Las funciones descritas en el enunciado del ámbito (o dentro de los casos de uso) se evalúan y en algunos casos se refinan para proporcionar más detalles antes de comenzar la estimación. Puesto que las estimaciones de costo y programa de trabajo están funcionalmente orientadas, con frecuencia es útil cierto grado de descomposición. Las consideraciones del desempeño abarcan los requisitos del procesamiento y tiempo de respuesta. Las restricciones identifican los límites colocados con el software por el hardware externo, la memoria disponible u otros sistemas existentes.

los límites colocados con el software por el hardware externo, la memoria disponible u otros sistemas
los límites colocados con el software por el hardware externo, la memoria disponible u otros sistemas
Una vez identificado el ámbito (con la participación del cliente) es razonable preguntar: ¿es posible
Una vez identificado el ámbito (con la participación 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), sólo para verse
enredados en un proyecto condenado al fracaso.
65
65
UNIVERSIDAD PRIVADA TELESUP Putnam y Myers abordan este conflicto cuando escriben: No todo lo imaginable

UNIVERSIDAD PRIVADA TELESUP

Putnam y Myers abordan este conflicto cuando escriben: No todo lo imaginable es factible, incluso
Putnam y Myers abordan este conflicto cuando escriben:
No todo lo imaginable es factible, incluso ni el software, evanescente como puede
parecer a los extraños. Por el contrario, la factibilidad del software tiene cuatro
dimensiones sólidas: Tecnología: ¿El proyecto es
técnicamente factible? ¿Está dentro del terreno de
la disciplina? ¿Los defectos se pueden reducir a tal
grado que se emparejen con las necesidades de la
aplicación? Finanzas: ¿Es financieramente
factible? ¿Se puede completar el desarrollo a un
costo que la organización del software, su cliente o
el mercado puedan enfrentar? Tiempo: ¿El proyecto llegará al mercado antes y
vencerá a la competencia? Recurso: ¿La organización 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 líneas
arriba. Ésta es una parte crucial, aunque con frecuencia ignorada, del proceso de
estimación.
anotadas líneas arriba. Ésta es una parte crucial, aunque con frecuencia ignorada, del proceso de estimación.
66
66
UNIVERSIDAD PRIVADA TELESUP Recursos de Software TEMA 2 Competencia: Administrar los componentes del software

UNIVERSIDAD PRIVADA TELESUP

Recursos de Software

TEMA 2

UNIVERSIDAD PRIVADA TELESUP Recursos de Software TEMA 2 Competencia: Administrar los componentes del software
UNIVERSIDAD PRIVADA TELESUP Recursos de Software TEMA 2 Competencia: Administrar los componentes del software

Competencia:

Administrar los componentes del software reutilizable, el entorno de desarrollo de un proyecto y el personal según las habilidades requeridas.

67
67
UNIVERSIDAD PRIVADA TELESUP Tema 02: Recursos de Software La segunda tarea de la planificación es

UNIVERSIDAD PRIVADA TELESUP

Tema 02: Recursos de Software

La segunda tarea de la planificación es la estimación de los recursos necesarios para completar
La segunda tarea de la planificación es la estimación de los recursos necesarios para
completar el esfuerzo de desarrollo del software. La siguiente
figura muestra las tres grandes categorías de los recursos de
ingeniería del software: personal, componentes de software
reutilizables y el entorno de desarrollo (hardware y herramientas
de software). Cada recurso se especifica con cuatro
características: descripción del recurso; un informe de disponibilidad;
cuándo se requerirá el recurso; tiempo durante el cual el recurso se aplicará. Las
últimas dos características se pueden ver cómo una ventana de tiempo. La
disponibilidad del recurso para una ventana específica debe establecerse lo más
pronto posible.
de tiempo. La disponibilidad del recurso para una ventana específica debe establecerse lo más pronto posible.
68
68
UNIVERSIDAD PRIVADA TELESUP Recursos Humanos El planificador comienza evaluando el ámbito del software y seleccionando

UNIVERSIDAD PRIVADA TELESUP

Recursos Humanos El planificador comienza evaluando el ámbito del software y seleccionando las habilidades requeridas
Recursos Humanos
El planificador comienza evaluando el ámbito del software y seleccionando las
habilidades requeridas para completar el desarrollo. Se especifican tanto la posición
organizacional (por ejemplo, gestor, ingeniero e software ejecutivo) como la
especialidad (por ejemplo, telecomunicaciones, base de datos, cliente/servidor). En
proyectos relativamente pequeños (unos pocos persona-meses) un solo individuo
puede realizar todas las tareas de ingeniería de software y consultar con especialistas
conforme se requiera. En proyectos mayores
el equipo de software puede estar
geográficamente disperso en varios sitios.
Aquí se especifica la ubicación de cada
recurso humano.
El número de personas que requiere un proyecto de software sólo se determina
después de que se ha hecho la estimación del esfuerzo de desarrollo (por ejemplo,
personas-mes).

Recursos de software reutilizables

La ingeniería del software basada en componentes enfatiza la reutilización: es decir,

la creación y reutilización de bloques de construcción de software. Tales bloques,

usualmente llamados componentes, deben catalogarse para consultarlos con facilidad, estandarizarse para facilitar su aplicación y validarse para integrarlos fácilmente. Bennatan sugiere cuatro categorías de recursos de software que deben considerarse conforme avanza la planificación. 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, están listos para emplearlos en el proyecto actual y han sido ampliamente validados.

Componentes ya experimentados. Especificaciones, diseños, código 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 aplicación que representan dichos componentes. En consecuencia, las modificaciones que requieran los componentes experimentados serán relativamente de bajo riesgo.

69
69
UNIVERSIDAD PRIVADA TELESUP Componentes de experiencia parcial. Especificaciones, diseños, código o datos de prueba

UNIVERSIDAD PRIVADA TELESUP

Componentes de experiencia parcial. Especificaciones, diseños, código o datos de prueba existentes que se desarrollaron para proyectos previos están relacionados con el software que se construirá para el proyecto anual pero requerirán modificaciones sustanciales. Los miembros del equipo de software actual sólo tienen experiencia limitada en el área de aplicación 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. Irónicamente, con frecuencia los componentes de software reutilizables son despreciados durante la planificación, sólo para convertirse en una preocupación 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 evaluación técnica de las alternativas y puede ocurrir la adquisición oportuna.

Recursos de entorno

Recursos de entorno El entorno que soporta un proyecto de software, con frecuencia denominado entorno de

El entorno que soporta un proyecto de software, con frecuencia denominado entorno de ingeniería 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 práctica de la ingeniería del software. Puesto que la mayor parte de las organizaciones de software tienen múltiples 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 estarán disponibles.

la ventana de tiempo requerida por el hardware y el software, y verificar que estos recursos

Cuando un sistema basado en computadora (que incorpora hardware y software especializados) se someterá a la ingeniería, el equipo de software quizá requiera acceso a los elementos de hardware que están desarrollando otros equipos de ingeniería. Por ejemplo, el software de un contador numérico (CN) utilizado en un tipo de máquinas-herramienta tal vez requiera una máquina-herramienta específica (por ejemplo, un CN de torno) como parte del paso de prueba de validación; un proyecto de software para plantilla de página avanzada quizá necesite una impresora de alta calidad en algún punto durante el desarrollo. El planificador del proyecto de software debe especificar cada elemento de hardware.

70
70
UNIVERSIDAD PRIVADA TELESUP Estimación de Proyectos TEMA 3 Competencia: Analizar estimaciones mediante las técnicas de

UNIVERSIDAD PRIVADA TELESUP

Estimación de Proyectos

TEMA 3

UNIVERSIDAD PRIVADA TELESUP Estimación de Proyectos TEMA 3 Competencia: Analizar estimaciones mediante las técnicas de
UNIVERSIDAD PRIVADA TELESUP Estimación de Proyectos TEMA 3 Competencia: Analizar estimaciones mediante las técnicas de

Competencia:

Analizar estimaciones mediante las técnicas de descomposición y tamaño del software.