UNIVERSIDAD PRIVADA TELESUP
1
UNIVERSIDAD PRIVADA TELESUP
Prefacio:
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. Unidad II: Métricas para Procesos y Proyectos de TI. Unidad III: Estimación para Proyectos de Software. Unidad IV: Calendarización de Proyectos de Software.
2
UNIVERSIDAD PRIVADA TELESUP
Estructura de los Contenidos Generalidades de la Dirección de Proyectos de TI
Métricas para Procesos y Proyectos de TI
Estimación para Proyectos de Software
Fundamentos de la Dirección de Proyectos.
Introducción a las Métricas.
Introducción a la Estimación de Proyectos de Software.
Introducción a la Canlendarización de Proyectos de Software.
Gestión de alcance del Proyecto.
Métricas de Proceso.
Recursos de Software.
La Canlendarización de Proyectos.
Gestión de los Riesgos del Proyecto.
Gestión del tiempo de un Proyecto.
Métricas de Proyecto. Estimación de Proyectos.
Métricas Orientadas al Tamaño.
Estimación Basada en Problemas.
La competencia
Calendarización de Proyectos de Software
Distribución del Esfuerzo.
Refinamiento de las Tareas Principales.
que el estudiante debe lograr al final de la
asignatura es: “Conocer las herramientas y habilidades de la
dirección de proyectos que le permitan
dirigir,
controlar
tecnologías de
la mano con la información global.”
y
gestionar
proyectos
de
3
UNIVERSIDAD PRIVADA TELESUP
Índice del Contenido
I. PREFACIO II. DESARROLLO DE LOS CONTENIDOS UNIDAD DE APRENDIZAJE 1: GENERALIDADES DE LA DIRECCIÓN DE PROYECTOS DE TI 1. Introducción a. Presentación y contextualización b. Competencia (logro) c. Capacidades d. Actitudes e. Ideas básicas y contenido 2. Desarrollo de los temas a. Tema 01: Fundamentos de la Dirección de Proyectos. b. Tema 02: Gestión de Alcance del Proyecto. c. Tema 03: Gestión de los Riesgos del Proyecto. d. Tema 04: Gestión del Tiempo de un Proyecto. 3. Lecturas recomendadas 4. Actividades 5. Autoevaluación 6. Resumen UNIDAD DE APRENDIZAJE 2: MÉTRICAS PARA PROCESOS Y PROYECTOS DE TI 1. Introducción a. Presentación y contextualización b. Competencia (logro) c. Capacidades d. Actitudes e. Ideas básicas y contenido 2. Desarrollo de los temas a. Tema 01: Introducción a las Métricas. b. Tema 02: Métricas de Proceso. c. Tema 03: Métricas de Proyecto. d. Tema 04: Métricas Orientadas al Tamaño. 3. Lecturas recomendadas 4. Actividades 5. Autoevaluación 6. Resumen UNIDAD DE APRENDIZAJE 3: ESTIMACIÓN PARA PROYECTOS DE SOFTWARE 1. Introducción a. Presentación y contextualización b. Competencia (logro) c. Capacidades d. Actitudes e. Ideas básicas y contenido 2. Desarrollo de los temas a. Tema 01: Introducción a la Estimación de Proyectos de Software. b. Tema 02: Recursos de Software. c. Tema 03: Estimación de Proyectos. d. Tema 04: Estimación Basada en Problemas. 3. Lecturas recomendadas 4. Actividades 5. Autoevaluación 6. Resumen UNIDAD DE APRENDIZAJE 4: CALENDARIZACIÓN DE PROYECTOS DE SOFTWARE 1. Introducción a. Presentación y contextualización b. Competencia c. Capacidades d. Actitudes e. Ideas básicas y contenido 2. Desarrollo de los temas a. Tema 01: Introducción a la Calendarización de Proyectos de Software. b. Tema 02: La Calendarización de Proyectos. c. Tema 03: Distribución del Esfuerzo. d. Tema 04: Refinamiento de las tareas Principales. 3. Lecturas recomendadas 4. Actividades 5. Autoevaluación 6. Resumen III. GLOSARIO IV. FUENTES DE INFORMACIÓN V. SOLUCIONARIO
02 03 - 119 05-37 06 06 06 06 06 06 07-33 07 12 18 24 34 34 35 37 38-59 39 39 39 39 39 39 40-55 40 44 48 51 56 56 57 59 60- 89 61 61 61 61 61 61 62-85 62 67 71 75 86 86 87 89 90-116 91 91 91 91 91 91 92-112 92 97 103 108 113 113 114 116 117 118 119
4
UNIVERSIDAD PRIVADA TELESUP
5
UNIVERSIDAD PRIVADA TELESUP
Introducción
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
UNIVERSIDAD PRIVADA TELESUP
Fundamentos de la
TEMA 1
Dirección de Proyectos Competencia: Describir las principales características y comprender los fundamentos de un proyecto de TI.
7
UNIVERSIDAD PRIVADA TELESUP
Desarrollo de los Temas
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.
QUE ES UN PROYECTO Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único.
Temporal Temporal significa que cada proyecto tiene un comienzo definido y un final definido. El final se alcanza cuando se han logrado los objetivos del proyecto o cuando queda claro que los objetivos del proyecto no 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.
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
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 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 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
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.
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, 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
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 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.
11
UNIVERSIDAD PRIVADA TELESUP
Gestión de Alcance del Proyecto
TEMA 2
Competencia: Identificar el alcance de un proyecto conociendo las entradas, técnicas, herramientas, y salidas correspondientes.
12
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.
Según la guia de los fundamentos de la dirección de proyectos dice: 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.
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
UNIVERSIDAD PRIVADA TELESUP
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 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.
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
UNIVERSIDAD PRIVADA TELESUP
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, 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 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
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
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 (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)
17
UNIVERSIDAD PRIVADA TELESUP
Gestión de los Riesgos del Proyecto
TEMA 3
Competencia: Analizar los riesgos con el fin de planificar y controlar un proyecto.
18
UNIVERSIDAD PRIVADA TELESUP
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).
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 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
UNIVERSIDAD PRIVADA TELESUP
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
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
UNIVERSIDAD PRIVADA TELESUP
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, 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
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 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 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
UNIVERSIDAD PRIVADA TELESUP
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.
23
UNIVERSIDAD PRIVADA TELESUP
Gestión del Tiempo de un Proyecto
TEMA 4
Competencia: Estimar el tiempo de un proyecto teniendo en cuenta las secuencias, recursos y duración.
24
UNIVERSIDAD PRIVADA TELESUP
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.
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 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 procedimientos y las guías que se tienen en cuenta al desarrollar las definiciones de las actividades.
25
UNIVERSIDAD PRIVADA TELESUP
Enunciado del Alcance del Proyecto Los productos entregables del proyecto, las restricciones y las asunciones documentadas en el enunciado del alcance del proyecto. Estructura de Desglose del Trabajo La estructura de desglose del trabajo es una entrada principal para la 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 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
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. o
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.
26
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 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 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. o Inicio a Fin. En el PDM, final a inicio es el tipo de relación de precedencia más comúnmente usado.
27
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.
28
UNIVERSIDAD PRIVADA TELESUP
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. 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
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
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
Enunciado del Alcance del Proyecto
30
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 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
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 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.
32
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 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)
33
UNIVERSIDAD PRIVADA TELESUP
Lecturas Recomendadas
EL ALCANCE DE UN PROYECTO http://www.tress.com.mx/esp/Portals/0/Documentos%20varios/Bolet%C3%ADn% 20mensual/Abril/Alcance%20proyecto.pdf
GESTIÓN DEL TIEMPO DE UN PROYECTO http://www.slideshare.net/CulturaEmpresarial/gestion-del-tiempo-presentation
Actividades y Ejercicios
1. En un documento en Word indique el alcance de un proyecto para un sistema de comercialización en una tienda de computadoras y determina los posibles riesgos. Envíalo a través de "Proyectos".
2. En un documento en Word explique el alcance de un proyecto para un sistema de notas y matriculas en un colegio y determina los posibles riesgos. Envíalo a través de "Riesgos de un Proyecto".
34
UNIVERSIDAD PRIVADA TELESUP
Autoevaluació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
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. b. c. d. e.
Alcance del producto. Planificación del alcance. Alcance del proyecto. Definición del alcance. 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. b. c. d. e.
Estimación de recursos de las actividades. Estimación de punto de función. Estimación de procesos. Estimación de costo de software. 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. c. d. e.
Identificación de Riesgos. Seguimiento y Control de Riesgos. Planificación de la Respuesta a los Riesgos. Análisis de Procedimiento.
36
UNIVERSIDAD PRIVADA TELESUP
Resumen
UNIDAD DE APRENDIZAJE I:
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 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.
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.
37
UNIVERSIDAD PRIVADA TELESUP
38
UNIVERSIDAD PRIVADA TELESUP
Introducción
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
UNIVERSIDAD PRIVADA TELESUP
Introducción a las Métricas
TEMA 1
Competencia: Describir los procesos de aplicación de las métricas para la determinación del tamaño de un proyecto.
40
UNIVERSIDAD PRIVADA TELESUP
Desarrollo de los Temas
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 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.
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”.
41
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
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 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 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
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.
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 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
UNIVERSIDAD PRIVADA TELESUP
Métricas de Proceso
TEMA 2
Competencia: Reconocer los principales factores que influyen en los procesos de desempeño organizacional.
44
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 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 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.
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.
45
UNIVERSIDAD PRIVADA TELESUP
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.
46
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.
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
UNIVERSIDAD PRIVADA TELESUP
Métricas
TEMA 3
de
Proyecto Competencia: Analizar las tendencias de un proyecto para planificar las mejoras correspondientes, evaluando la información adquirida.
48
UNIVERSIDAD PRIVADA TELESUP
Tema 03: Métricas de Proyecto 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.
49
UNIVERSIDAD PRIVADA TELESUP
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 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?
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
UNIVERSIDAD PRIVADA TELESUP
Métricas Orientadas al Tamaño
TEMA 4
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
UNIVERSIDAD PRIVADA TELESUP
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 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.
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.
52
UNIVERSIDAD PRIVADA TELESUP
MÉTRICAS ORIENTADAS AL TAMAÑO Proyecto Alfa Beta Gamma • • •
LDC 12100 27200 20200 • • •
Esfuerzo 24 62 43 • • •
$(000) 168 440 314 • • •
Pág. Doc. 365 1224 1050 • • •
Errores 134 321 256 • • •
Defectos 29 86 64
Personal 3 5 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.
53
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.
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 y PF en la estimación requiere establecer una línea de referencia histórica de información.
54
UNIVERSIDAD PRIVADA TELESUP
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 programación Access Ada APS ASP 69 Ensamblador C C++ Clipper COBOL Cool: Gen/IEF Culprit DBase IV Easytrieve 1 Excel 47 Focus FORTRAN Foxpro Ideal IEF/Cool:Gen Informix Java JavaScript JCL JSP Lotus Notes Mantis Mapper Natural Oracle PeopleSoft Perl PL/1 PowerBuilder REXX RPG II/III SAS Smalltalk SQL VBScript36 Visual Basic
LDC por punto de función Promedio 35 154 86 62 337 162 66 38 77 38 51 52 33 46 43 32 66 38 42 63 58 91 59 21 71 118 60 30 33 60 78 32 67 61 40 26 40 34 47
Mediana 38 83 315 109 53 39 77 31 34 42 35 52 31 31 53 63 123 22 27 81 52 35 32 67 31 49 41 19 37 27 42
Bajo 15 104 20 32 91 33 29 27 14 10 25 31 32 25 34 10 24 77 42 26 15 22 16 22 4 30 22 11 24 33 10 7 50 16
Alto 47 205 184 127 127 704 178 70 400 180 41 63 56 35 203 180 57 75 150 25 250 245 141 217 40 263 105 155 49 55 110 158
55
UNIVERSIDAD PRIVADA TELESUP
Lecturas Recomendadas
INGENIERÍA DEL SOFTWARE – MÉTRICA - DESARROLLO DE SISTEMAS DE INFORMACIÓN http://www.slideshare.net/LuisEduardoPelaez/mtrica-desarrollo-de-sistemas-deinformacin
MÉTRICAS, ESTIMACIÓN Y PLANIFICACIÓN EN PROYECTOS http://www.willydev.net/descargas/WillyDEV_PlaneaSoftware.Pdf
Actividades y Ejercicios
1. 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".
2. 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". 3.
56
UNIVERSIDAD PRIVADA TELESUP
Autoevaluación
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
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. c. d. e.
TD(tiempo de duración del proyecto). PF (Punto de función). LDC (Línea de códigos). EF (Esfuerzo utilizado).
58
UNIVERSIDAD PRIVADA TELESUP
Resumen
UNIDAD DE APRENDIZAJE II:
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 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.
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.
59
UNIVERSIDAD PRIVADA TELESUP
60
UNIVERSIDAD PRIVADA TELESUP
Introducción
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
UNIVERSIDAD PRIVADA TELESUP
Introducción TEMA 1 a la Estimación de Proyectos de Software Competencia: Desarrollar las estimaciones necesarias aplicando las medidas y el software adecuado.
62
UNIVERSIDAD PRIVADA TELESUP
Desarrollo de los Temas
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…
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.
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
UNIVERSIDAD PRIVADA TELESUP
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.
64
UNIVERSIDAD PRIVADA TELESUP
Á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: 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.
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.
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
UNIVERSIDAD PRIVADA TELESUP
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.
66
UNIVERSIDAD PRIVADA TELESUP
Recursos de Software
TEMA 2
Competencia: Administrar los componentes del software reutilizable, el entorno de desarrollo de un proyecto y el personal según las habilidades requeridas.
67
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 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.
68
UNIVERSIDAD PRIVADA TELESUP
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
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 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.
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
UNIVERSIDAD PRIVADA TELESUP
Estimación de Proyectos
TEMA 3
Competencia: Analizar estimaciones mediante las técnicas de descomposición y tamaño del software.
71
UNIVERSIDAD PRIVADA TELESUP
Tema 03: Estimación de Proyectos El software es el elemento más caro de virtualmente todos los sistemas basados en computadora. En sistemas complejos, personalizados, un gran error en la estimación del costo puede hacer la diferencia entre beneficio y pérdida. Rebasar el costo puede ser desastroso para el desarrollador.
La estimación del costo y el esfuerzo nunca será una ciencia exacta. Demasiadas variables –humanas, técnicas, ambientales, políticas– pueden afectar el costo final del software y el esfuerzo aplicado a desarrollo. Sin embargo, la estimación del proyecto de software se puede transformar de una práctica oscura en una serie de pasos sistemáticos que proporcionan estimaciones con riesgo aceptable. Para lograr estimaciones confiables de costo y esfuerzo se tienen varias opciones: 1. Demorar la estimación hasta más tarde en el proyecto (obviamente, ¡se puede lograr 100 por ciento de estimaciones precisas después de que el proyecto esté terminado!) 2. Basar las estimaciones en proyectos similares que hayan sido completados. 3. Emplear técnicas de descomposición relativamente simples para generar estimaciones de costo y esfuerzo del proyecto. 4. Utilizar uno o más modelos empíricos en la estimación de costo y esfuerzo.
Desgraciadamente, la primera opción, aunque atractiva, no es práctica. Las estimaciones de costos tienen que proporcionar “por adelantado”. No obstante se debe reconocer que, mientras más se espere más se conocerá, y mientras más se conozca menos probable es que se cometan serios errores en las estimaciones. La segunda opción puede funcionar razonablemente bien si el proyecto en curso es muy similar a los previos y a otras influencias del proyecto (por ejemplo, el equipo del software, el cliente, las condiciones del mercado, el EIS, las fechas límite) son aproximadamente equivalentes. Por desgracia, la experiencia no siempre ha sido un buen indicador de los resultados futuros.
72
UNIVERSIDAD PRIVADA TELESUP
Las opciones restantes son los enfoques viables para la estimación del proyecto de software. Idealmente, las técnicas mencionadas para cada opción deben aplicarse juntas, cada una empleada como una marca de verificación para la otra. Las técnicas de descomposición asumen un enfoque de “divide y vencerás” respecto de la estimación del proyecto de software. Al descomponer
un
proyecto
en
funciones
principales
y
actividades de ingeniería del software relacionadas, las estimaciones de costo y esfuerzo se pueden realizar en forma escalonada. Los modelos de estimación empírica son útiles para complementar las técnicas de descomposición y ofrecer un enfoque de estimación potencialmente valioso por su propio derecho. Cada una de las opciones viables de estimación de costo del software será tan buena como los que sean datos históricos en que se basa la estimación. Si no existen datos históricos, la estimación del costo se basará en un fundamento muy tambaleante.
Técnicas de descomposición La estimación del proyecto de software es una forma de resolver problemas; en la mayoría de los casos, el problema que debe resolverse (es decir, el desarrollo de una estimación de costo y esfuerzo para un proyecto de software) es muy complejo como para considerarlo una sola pieza. Por esta razón se descompone el problema, recaracterizándolo
como
esperanzadoramente,
más
un
conjunto
de
problemas
más
manejable).
La
estimación
puede
pequeños emplear
(y, la
descomposición del problema, la descomposición del proceso, o ambas formas de partición. Pero antes que pueda realizarse una estimación, el planificador del proyecto debe entender el ámbito del software que se construirá y generar una estimación de su “tamaño”
Tamaño del software La precisión de la estimación de un proyecto de software se manifiesta en varios factores: 1) el grado con el cual el planificador ha estimado adecuadamente el tamaño del producto que se construirá; 2) la habilidad para traducir la estimación del tamaño en esfuerzo humano, programa de trabajo y dinero (una función de la disponibilidad de las métricas de software confiables a partir de proyectos previos); 3) el grado en el cual el plan del proyecto refleja las habilidades del equipo de software;
73
UNIVERSIDAD PRIVADA TELESUP
Y 4) la estabilidad de los requisitos del producto y el entorno que soporta el esfuerzo de ingeniería del software. En esta sección se considera el problema del tamaño del software. Puesto que la estimación de un proyecto sólo es tan buena como la estimación del tamaño del trabajo para realizarlo, el tamaño representa el primer gran desafío del planificador del proyecto. En el contexto de la planificación del proyecto, tamaño se refiere a un resultado cuantificable del proyecto de software. Si se asume un enfoque directo, el tamaño se puede medir en líneas de código (LDC).
Si se asume un enfoque indirecto, el tamaño se representa como puntos de función (PF). Putnam y Myers sugieren cuatro diferentes enfoques al problema del tamaño:
Tamaño de “lógica difusa”. La aplicación de este enfoque requiere que un planificador identifique el tipo de aplicación, establezca su magnitud en una escala cualitativa y luego refine la magnitud dentro del rango original.
Tamaño de punto de función. El planificador desarrolla estimaciones de las características de dominio de la información.
Tamaño de componentes estándar. El software se compone de varios “componentes estándar”, los cuales son diferentes y genéricos de un área particular de la aplicación. Por ejemplo, los componentes estándar de un sistema de información son subsistemas, módulos,
pantallas,
reportes, programas interactivos, programas por lotes, archivos, LDC e instrucciones al nivel de objeto. El planificador
del proyecto estima el número de
ocurrencias de cada componente estándar y luego aplica datos de proyectos históricos para determinar el tamaño de entrega por componente estándar.
Tamaño del cambio: Este enfoque se aplica cuando un proyecto incluye la utilización del software existente que debe modificarse en cierta forma como parte de un proyecto. El planificador estima el número y tipo (por ejemplo, reutilización, código de adición, código de cambio, código de borrado) de las modificaciones que se debe lograr.
74
UNIVERSIDAD PRIVADA TELESUP
Estimación Basada en Problemas
TEMA 4
Competencia: Reconocer las principales funciones de las estimaciones de LDC y PF.
75
UNIVERSIDAD PRIVADA TELESUP
Tema 04: Estimación Basada en Problemas Las líneas de código y los puntos de función se utilizan en dos formas para estimar el proyecto de software 1) como una variable de la estimación para el “tamaño” de cada elemento del software, y 2) como métricas de línea base recolectadas a partir de proyectos previos y utilizados en conjunción
con
variables
de
estimación
para
desarrollar
proyecciones de costo y esfuerzo.
Las estimaciones de LDC y PF son distintas técnica de estimación, aunque ambas tienen varias características en común. El planificador del proyecto comienza con un enfoque acotado del ámbito del software y a partir de ahí intenta descomponer el software
en
funciones
problema
que
puedan
estimarse
individualmente. Entonces se estiman las LDC o PF (las variables de estimación) para cada función. De manera alternativa, el planificador puede elegir otro componente para tamaño, como clases u objetos, cambios o procesos de negocios afectados Entonces se aplican las métricas de la línea base de productividad (por ejemplo, LDC/pm o PF/pm5) a la variable de estimación apropiada, y se deriva el costo o esfuerzo de la función. Las estimaciones de función se combinan para producir una estimación global del proyecto completo.
Sin embargo, es importante notar que con frecuencia existe una dispersión sustancial en las métricas de la productividad de una organización, lo que hace sospechoso el uso de una sola métrica de línea base de la productividad. En general, el dominio del proyecto debe calcular los promedios LDC/pm o PF/pm. Es decir, los proyectos deben agruparse por tamaño de equipo, área de aplicación, complejidad y otros parámetros relevantes. Luego se tienen que calcular los promedios de dominio local. Cuando se estima un nuevo proyecto primero debe ubicarse en un dominio, y luego aplicar el promedio apropiado para lo productividad y así generar la estimación.
76
UNIVERSIDAD PRIVADA TELESUP
Las técnicas de estimación LDC y PF difieren en cuanto al detalle requerido para la descomposición y el objetivo de la partición. Al emplear LDC como variable de estimación la descomposición es absolutamente esencial y con frecuencia se lleva a grados considerables de detalle. Mientras mayor sea el grado de partición es más probable que se desarrolle una estimación razonablemente precisa de LDC. En las estimaciones de PF la descomposición funciona de manera diferente. Más que enfocarse sobre la función, se estima cada una de las cinco características de dominio de información. Entonces se pueden utilizar estimaciones resultantes para derivar un valor de PF que se pueda ligar a los datos previos y empleados para generar una estimación.
Sin importar la variable de estimación que se utilice, el planificador del proyecto comienza estimado una gama de valores para cada función o valor de dominio de información. Al emplear los datos históricos (cuando todo lo demás falla) intuición, el planificador estima un valor de tamaño optimista, más probable y pesimista para cada función o cuenta para cada valor de dominio de información. Cuando se especifica un rango de valores se proporciona un indicio implícito del grado de incertidumbre. Entonces se puede calcular un valor de tres puntos o uno esperado. El valor esperado para la variable de estimación (tamaño). S se calcula como un promedio ponderado de las estimaciones optimista (Sopt), más probable (Sm) y pesimista (Spes). Por ejemplo, S = (Sopt + 4Sm + Spes) / 6
Brinda la credibilidad más fuerte a la estimación “más probable” y sigue la distribución de probabilidad beta. Se supone que existe una probabilidad muy pequeña de que el tamaño real resultante se ubique fuera de los valores optimista y pesimista. Una vez determinado el valor esperado para la variable de estimación se aplican los datos de productividad histórica de LDC o PF. ¿Son correctas las estimaciones? La única respuesta razonable a esta pregunta es: no se puede estar seguro. Cualquier técnica de estimación, no importa cuán sofisticada sea, debe contrastarse con otro enfoque. Incluso entonces deben prevalecer el sentido común y la experiencia.
77
UNIVERSIDAD PRIVADA TELESUP
Un ejemplo de estimación basada en LDC Como ejemplo de técnicas de estimación de LDC y PF basadas en el problema, considérese un paquete de software que será entregado para una aplicación de diseño asistido por computadora (CAD, por sus siglas en inglés) destinado a componentes mecánicos. El software se ejecutará en una estación de trabajo de ingeniería y debe tener interfaz con varios periféricos que incluyen ratón, digitalizador, monitor de color de alta resolución e impresora láser. Se puede elaborar una descripción preliminar del ámbito del software.
El software CAD mecánico aceptará del ingeniero de datos geométricos de dos y tres dimensiones. El ingeniero interactuará y controlará el sistema CAD a través de una interfaz del usuario que exhibirá características de buen diseño para producir la salida requerida, la cual se desplegará en la diversidad de los dispositivos gráficos. El software se diseñará para controlar e interactuar con dispositivos periféricos que incluyen ratón, digitalizador, monitor de color de alta resolución e impresora láser y plotter.
Esta
descripción del ámbito preliminar, no está acotada. Se tendría que expandir cada oración para ofrecer detalle concreto y acotación cuantitativa. Por ejemplo, antes de que comience la estimación, el planificador debe determinar qué significa “características de buen diseño de interfaz humano-máquina” o cuales serán el tamaño y la complejidad de la “base de datos CAD”,
En cuanto a los propósitos actuales, se supone que se ha llevado a cabo más refinamiento y que están identificadas para grandes funciones de software mencionadas en la figura siguiente. En cada función se desarrolla un rango de estimaciones LDC para la función de análisis geométrico 3D es: optimista, 4600 LDC; más probable, 6900 LDC; y pesimista, 8600 LDC. Otras estimaciones se derivan en forma similar. Al sumar verticalmente en la columna las LDC estimadas, se establece una estimación de 33200 líneas de código para el sistema CAD.
78
UNIVERSIDAD PRIVADA TELESUP
FUNCIÓN Facilidades de interfaz del usuario final y
LDC ESTIMADAS 2300
control (FIUC) Análisis geométrico bidimensional (AG2D)
5300
Análisis geométrico tridimensional (AG3D)
6800
Gestión de base de datos (GBD)
3350
Facilidades de presentación gráfica de
4950
computadora (FPGC0 Función de control periférico (FCP)
2100
Módulos de análisis de diseño (MAD)
8400
Línea de códigos estimados
33200
Una revisión de los datos históricos indica que el promedio organizacional de productividad para sistemas de este tipo es de 260 LDC/pm. Con base en una tarifa laboral de 8000 dólares por mes, el costo por línea de código es aproximadamente de 13 dólares. Con base en la estimación de LDC y los datos históricos de productividad, el costo total estimado del proyecto es de 431 000 dólares y el esfuerzo estimado es de 54 personas-mes.
Un ejemplo de estimación basada en PF La descomposición de la estimación basada en PF se centra en los valores de dominio de información más que en las funciones de software. Al consultar la tabla presentada en la siguiente figura, el planificador del proyecto estima entradas externas, salidas externas, consultas externas, archivos lógicos internos y archivos de interfaz externos para el software CAD.
79
UNIVERSIDAD PRIVADA TELESUP
Los PF se calculan usando la técnica estudiada previamente.
VALOR DE DOMINIO INFORMACIÓN
DE
OPTIM.
PROBABLE
PRESI.
CONTEO ESTIM.
PESO
CONTEO PF
Número de entradas externas
20
24
30
24
4
97
Número de salidas externas Número de preguntas externas Número de archivos lógicos internos Número de archivos de interface externos Conteo total
12 16
15 22
22 28
16 22
5 5
78 88
4
4
5
4
10
42
2
2
3
2
7
15 320
En cuanto a los propósitos de esta estimación se supone que el factor ponderado de complejidad es el promedio. La tabla representa los resultados de esta estimación. Se estima cada uno de los factores ponderados de complejidad y el valor del factor ajustado:
FACTOR
VALOR 4
1. Respaldo y recuperación 2. Comunicación de datos
2
3. Procesamiento distribuido
0
4. Desempeño crítico
4
5. Entorno operativo existente
3
6. Entrada de datos en línea
4
7. Transacción de entrada sobre pantallas múltiples
5
8. ILF actualizado en línea
3
9. Complejo de valores de dominio de información
5
10. Complejo de procesamiento interno
5
11. Código diseñado para reutilización
4
12. Conversión/instalación en diseño
3
13. Instalaciones múltiples
5
14. Aplicación diseñada para cambio
5
Factor de ajuste de valor
1.17
80
UNIVERSIDAD PRIVADA TELESUP
Finalmente, se deriva el número estimado de PF: PFestimado = conteo total x [0.65 + 0.01 x ∑(Fi)] PFestimado = 375 La productividad organizacional promedio para sistemas de este tipo es 6.5 PF/pm. Con base en una escala salarial de 8 000 dólares por mes, el costo por PF es aproximadamente 1 230 dólares. Con base en la estimación de PF y los datos de productividad históricos, el costo total estimado del proyecto es de 461 000 dólares, y el esfuerzo estimado es de 58 personas-mes.
Estimación basada en el proceso La técnica más común para estima un proyecto es basar la estimación en el proceso que se empleará. Esto es, el proceso se descompone en un conjunto relativamente pequeño de tareas y se estima el esfuerzo requerido para lograr cada tarea. Al igual que las técnicas basadas en el problema, la estimación basada en el proyecto comienza con un bosquejo de las funciones del software obtenidas a partir del ámbito del proyecto. Cada función requiere realizar una serie de actividades del marco de trabajo. Las funciones y actividades del marco de trabajo relacionadas se presentan como parte de una tabla similar a que presentamos a continuación.
81
UNIVERSIDAD PRIVADA TELESUP
Actividad
Cc
Planificación
Análisis
Ingeniería
del
Liberación de
Ec
Totales
Construcción
Riesgo Tarea
Análisis
Diseño
Código
Prueba
FIUC
0.50
2.50
0.40
5.00
AG2D
0.75
4.00
0.60
2.00
AG3D
0.50
4.00
1.00
3.00
FPGC
0.50
3.00
1.00
1.50
GBD FCP
0.50 0.25
3.00 2.00
0.75 0.50
1.50 1.50
MAD
0.50
2.00
0.50
2.00
Función
Totales
0.2 5
0.25
0.25
3.50
20.50
4.75
16.50
% esfuerzo
0.5 %
0.5%
0.5%
8%
45%
10%
36%
n/ a n/ a n/ a n/ a n/ a n/ a
8.40 7.35 8.50 6.00 5.75 4.25 5.00
46.00
82
UNIVERSIDAD PRIVADA TELESUP
CC= comunicación del cliente EC= evaluación del cliente Una vez que se combinan las funciones del problema y las actividades del proceso, el planificador estima el esfuerzo (por ejemplo, personas-mes) que se requerirá para lograr la actividad del proceso de software en cada función. Estos datos constituyen la matriz central de esta tabla. Entonces se aplican las tasas de trabajo promedio (es decir, costo/unidad de esfuerzo) al esfuerzo estimado para actividad del proceso. Es muy probable que la tasa de trabajo varíe en cada tarea. El equipo veterano está enormemente involucrado a las actividades tempranas del marco de trabajo y generalmente es más costoso que el equipo menos experimentado involucrado en la construcción y liberación.
Los costos y el esfuerzo para cada función y la actividad del marco de trabajo se calculan como el último paso. Si la estimación basada en el proceso se realiza independientemente de la estimación del LDC o PF, ahora se tienen dos o tres estimaciones para costo y esfuerzo que se pueden comparar y
armonizar.
estimaciones
Si
ambos
muestran
una
conjuntos
de
concordancia
razonable, existe una buena razón para creer que las estimaciones son confiables. Si por otra parte, los resultados de dichas técnicas de descomposición muestran poca concordancia, se debe llevar a cabo mayor investigación y análisis.
Un ejemplo de estimación basada en el proceso Para ilustrar el uso de la estimación basada en el proceso considere de nuevo el software CAD. La configuración del sistema y las funciones del software permanecen invariables y las indica el ámbito el proyecto. En la tabla basada en el proceso
que se muestra en la tabla anterior, las
estimaciones del esfuerzo (en personas-mes) para cada actividad de ingeniería del software se proporcionan para cada función del software CAD (abreviadas para mayor rapidez).
83
UNIVERSIDAD PRIVADA TELESUP
Las actividades de ingeniería y liberación de construcción se subdividen en las principales tareas de ingeniería del software que se muestran. Las primeras estimaciones de esfuerzo corresponden a comunicación con el cliente, planificación y análisis de riesgos, las cuales se registran en la hilera total al final de la tabla. Los totales horizontal y vertical ofrecen un indicio del esfuerzo estimado que se requiere para análisis, diseño, código, y prueba. Se deben señalar que 53 por ciento del esfuerzo se emplea en las tareas de ingeniería del sistema de salida (análisis de requisitos y diseño), lo que indica la importancia relativa de este trabajo. Con base en la escala salarial promedio de 8 000 dólares por mes, el costo total estimado del proyecto es de 368 000 dólares, y el esfuerzo estimado es de 46 personas-mes. Si se desea, los promedios de trabajo pueden asociarse con cada actividad del marco de trabajo o tarea de ingeniería del software y calcularse por separado.
Estimación con casos de uso Los casos de uso permiten que un equipo de software comprenda el ámbito del software y los requisitos. Sin embargo, desarrollar un enfoque de estimación con casos de uso es problemático por las siguientes razones:
Los casos de uso se describen empleando muchos formatos y estilos diferentes; no existe un formato estándar.
Los casos de uso representan una visión externa (la visión del usuario) del software y con frecuencia están escritos con diferentes grados de abstracción.
Los casos de uso no abordan la complejidad de las funciones ni de las características que se describen.
Los casos de uso no describen el comportamiento complejo (por ejemplo, interacciones) que involucran muchas funciones y características.
A diferencia de las LDC o un punto de función, el “caso de uso” de una persona tal vez requiera meses de esfuerzo mientras que el de otra quizá se implemente en un día o dos. Aunque varios investigadores han considerado los casos de uso como una entrada a la estimación, a la fecha no ha surgido ningún método de estimación probado.
84
UNIVERSIDAD PRIVADA TELESUP
Smith sugiere el empleo de los casos de uso en la estimación, pero sólo si se consideran dentro del contexto de la “jerarquía estructural” que los casos de uso describen. Smith argumenta que cualquier nivel de esta jerarquía estructural se describe con no más de 10 casos de uso. Cada uno de éstos abarcaría no más de 30 escenarios distintos. Obviamente, los casos de uso que describen un sistema grande están inscritos con un grado mucho mayor de abstracción (y representan considerablemente más esfuerzo de desarrollo) que aquellos que describen un solo subsistema. En consecuencia antes de que los casos de uso se empleen en la estimación, se establece el nivel en la estructura jerárquica, se determina la longitud promedio (en páginas) de cada caso de uso, se define el tipo de software (por ejemplo, tiempo real, de negocios, de ingeniería/científico, anidado) y se considera una arquitectura común del sistema.
Una vez establecidas dichas características, los datos empíricos se aprovechan para establecer el número estimado de LDC o de PF por el caso de uso (para cada nivel de jerarquía). Entonces se utilizan los datos históricos para calcular el esfuerzo necesario para desarrollar el sistema. LCDestimada = N x LCDprom + [(Sa / Sh – 1) + (Pa / Ph – 1)] x LCDajuste
Donde N= número real de casos de uso. LCDprom= promedio histórico de LDC por caso de uso para este tipo de subsistema. LCDajuste= representa un ajuste con base en n por ciento de LCDprom donde n se define localmente y representa la diferencia entre este proyecto y los proyectos “promedio” Sa= escenarios reales por caso de uso Sh= escenarios promedio por caso de uso para este tipo de subsistema Pa= páginas reales por caso de uso Ph= página promedio por caso de uso para este tipo de subsistema Con esta expresión se desarrolla una estimación común del número de LDC con base en el número real de casos de uso ajustado mediante el número de escenarios y la longitud de la página de los casos de uso. El ajuste representa hasta n por cierto del promedio histórico de las LDC por cada caso de uso.
85
UNIVERSIDAD PRIVADA TELESUP
Lecturas Recomendadas
ESTIMACIÓN DE PROYECTOS DE SOFTWARE http://www.slideshare.net/montoya118/estimacin-de-proyectos-de-software10785507
ESTIMACIÓN BASADA EN EL PROBLEMA http://www.scribd.com/doc/54546460/Estimaciones-Basadas-en-El-Problema
Actividades y Ejercicios
1. En un documento en Word plantee estrategias para la estimación de tiempo en un proyecto de biblioteca. Envíalo a través de "Tiempo en Proyecto".
2. En un documento en Word elabore un ejemplo de estimación basado en un sistema de almacén. Envíalo a través de "Estimación".
86
UNIVERSIDAD PRIVADA TELESUP
Autoevaluación
1) 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: a. La ingeniería de software. b. El software. c. La estimación. d. Las métricas. e. Punto de función. 2) El proceso de planificación del proyecto: a. Establece un análisis profundo del proyecto. b. Proporciona un marco de trabajo que permita al gestor estimar recursos. c. Lleva a cabo un exhaustivo análisis interno del proyecto y externo de su entorno para diagnosticar la situación actual en la que se encuentra. d. Monitorea los procesos para que no se generen pérdidas en el proyecto. e. Saber quiénes participaran en el proyecto. 3) El ámbito del software: a. Describe las pautas que se entregarán al ingeniero de software, así como el desempeño, las restricciones, las interfaces y la confiabilidad que acotan el sistema. b. Identifica a todas las personas y organizaciones que serán impactadas por el proyecto y posteriormente documentar la información relevante respecto a sus intereses, participación e impactos sobre el éxito del proyecto. c. Analiza a los interesados en el proyecto y los ayuda a definir una posición en el proyecto, así como sus funciones. d. Evaluar una los casos de uso de un proyecto. e. Describe las funciones y características que se entregarán a los usuarios finales, así como el desempeño, las restricciones, las interfaces y la confiabilidad que acotan el sistema. 4) En la estimación de proyectos el planificador de recursos humanos: a. Especifica la posición organizacional y la especialidad en un proyecto. b. Determina las líneas de acción para desarrollar un nuevo software. c. Elige el conjunto de estrategias y alternativas que nos proporcionen mayores garantías de éxito. d. Se encarga en que los ingenieros de software hagan su trabajo eficazmente. e. Especifica la jerarquía y la roles de cada persona en un proyecto. 5) El entorno que soporta un proyecto de software: a. Administra únicamente el hardware y verifica que siempre este recurso esté disponible cuando sea requerido por un software. b. Administra únicamente el software y verifica que siempre este recurso esté disponible cuando sea requerido. c. Administra el hardware y software y verifica que siempre estos recursos estén disponibles cuando sean requeridos. d. Administra un proyecto y las métricas que siempre la información de los procesos siempre esté disponible cuando lo sea requerido. e. Administra las estimaciones de un proyecto para que no ocurran problemas cuando llegue a manos del usuario final.
87
UNIVERSIDAD PRIVADA TELESUP
6) Definir el verdadero concepto: a. La estimación del proyecto de software no es una forma eficaz por la cual se pueden resolver problemas. b. La estimación del costo y el esfuerzo nunca será una ciencia exacta c. El software es el elemento más económico pero complejo virtualmente de todos los sistemas basados en computadora d. Las estimaciones identifican que necesidades del proyecto pueden satisfacerse de mejor manera comprando o adquiriendo los productos y servicios e. La estimación de proyectos planifica las compras adquisiciones junto con la contratación de ingenieros de software. 7) No es un enfoque de Putnam y Myers referente al problema del tamaño de software: a. Tamaño de “lógica difusa”. b. Tamaño de punto de función. c. Tamaño de las líneas de código. d. Tamaño de componentes estándar. e. Tamaño del cambio. 8) Desarrollar un enfoque de estimación con casos de uso no es problemático por las siguiente razón: a. Los casos de uso se describen empleando muchos formatos y estilos diferentes; no existe un formato estándar. b. Los casos de uso representan una visión externa (la visión del usuario) del software y con frecuencia están escritos con diferentes grados de abstracción. c. Los casos de uso no abordan la complejidad de las funciones ni de las características que se describen. d. Los casos de uso con frecuencia toman demasiado tiempo en su elaboración e implementación. e. Los casos de uso no describen el comportamiento complejo (por ejemplo, interacciones) que involucran muchas funciones y características. 9) ¿Qué ocurre cuando la concordancia entre las estimaciones es insuficiente? a. El planificador ha comprendido adecuadamente y ha interpretado el ámbito de proyecto. b. Los datos de productividad que utilizan las técnicas de estimación basadas en el problema son inapropiados para la aplicación, obsoletos o se han aplicado mal. c. No se determina las políticas solo las responsabilidades d. Es muy incierto el final de un proyecto e. Es normal que ocurra eso en todas las estimaciones.
10) La estimación basada en el proceso se centra en: a. La discusión de la calidad. b. Planificación de la calidad, aseguramiento de la calidad y control de la calidad. c. Planificación de la calidad y la discusión de la calidad. d. Descomponer en un conjunto relativamente pequeño de tareas y se estima el esfuerzo requerido para lograr cada tarea. e. Compilar en un conjunto grande de tareas y se estima el esfuerzo requerido para lograr tareas globales.
88
UNIVERSIDAD PRIVADA TELESUP
Resumen
UNIDAD DE APRENDIZAJE III:
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. 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.
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.
Podemos decir que la estimación del costo y el esfuerzo nunca será una ciencia exacta. Demasiadas variables –humanas, técnicas, ambientales, políticas– pueden afectar el costo final del software y el esfuerzo aplicado a desarrollo. Sin embargo, la estimación del proyecto de software se puede transformar de una práctica oscura en una serie de pasos sistemáticos que proporcionan estimaciones con riesgo aceptable. Para lograr estimaciones confiables de costo y esfuerzo se tienen varias opciones: Demorar la estimación hasta más tarde en el proyecto (obviamente, ¡se puede lograr 100 por ciento de estimaciones precisas después de que el proyecto esté terminado!), basar las estimaciones en proyectos similares que hayan sido completados, emplear técnicas de descomposición relativamente simples para generar estimaciones de costo y esfuerzo del proyecto y utilizar uno o más modelos empíricos en la estimación de costo y esfuerzo.
Las estimaciones de LDC y PF son distintas técnica de estimación, aunque ambas tienen varias características en común. El planificador del proyecto comienza con un enfoque acotado del ámbito del software y a partir de ahí intenta descomponer el software en funciones problema que puedan estimarse individualmente. Entonces se estiman las LDC o PF (las variables de estimación) para cada función. De manera alternativa, el planificador puede elegir otro componente para tamaño, como clases u objetos, cambios o procesos de negocios afectados.
89
UNIVERSIDAD PRIVADA TELESUP
90
UNIVERSIDAD PRIVADA TELESUP
Introducción
a) Presentación y contextualización: En esta unidad usted aprenderá la importancia de las técnicas y tecnologías eficientes de la ingeniería de software para resolver múltiples problemas que se derivan de las aplicaciones en donde se desarrollan sistemas de software de gran tamaño. Tendrá en cuenta que cada proyecto de software presenta distintos problemas en su desarrollo los cuales involucran a personas, equipo, usuarios del software y ambiente de la aplicación. Por esas razones, cada proyecto debe resolver el problema de la producción del software.
b) Competencia: Gestiona los entregables de un proyecto de TI en el desarrollo del software.
c) Capacidades: 1. Aplica las técnicas eficientes de la ingeniería de software para resolver múltiples problemas en el desarrollo del software. 2. Conoce los principios básicos de calendarización en la ingeniería de software para resolver múltiples problemas en el desarrollo del sistema. 3. Distribuye los esfuerzos dentro de la calendarización de un proyecto para definir y realizar un conjunto de tareas para un proyecto. 4. Identifica las tareas principales mediante la calendarización y elaboración de una red de tareas.
d) Actitudes: Muestra una actitud emprendedora ante la calendarización de proyectos de software. Posee habilidad creativa para realizar proyectos de software.
e) Presentación de Ideas básicas y contenidos esenciales de la Unidad: La Unidad de Aprendizaje 04: Calendarización de Proyectos de Software, comprende el desarrollo de los siguientes temas: TEMA 01: Introducción a la Calendarización de Proyectos de Software. TEMA 02: La Calendarización de Proyectos. TEMA 03: Distribución del Esfuerzo. TEMA 04: Refinamiento de las Tareas Principales.
91
UNIVERSIDAD PRIVADA TELESUP
Introducción a la
Calendarización de
TEMA 1
Proyectos de Software Competencia:
Aplicar las técnicas eficientes de la ingeniería de software para resolver múltiples problemas en el desarrollo del software.
92
UNIVERSIDAD PRIVADA TELESUP
Desarrollo de los Temas
Tema 01: Introducción a la Calendarización de Proyectos de Software A finales de los años 60, un joven y brillante ingeniero fue elegido para “escribir” un programa de computadora para una aplicación industrial automatizada. La razón por la cual se eligió fue simple: era la única persona en el grupo técnico que había asistido a un seminario de programación de computadoras. Él conocía las entradas y salidas del lenguaje ensamblador y de FORTRAN, pero nada acerca de la ingeniería del software, e incluso menos acerca de la calendarización y seguimiento de proyectos.
Su jefe le dio manuales apropiados y una descripción verbal de lo que tenía que hacer. Se le informó que el proyecto debía terminarse en dos meses. El ingeniero leyó los manuales, consideró su enfoque y comenzó a escribir el código. Después de dos semanas, el jefe lo llamó a su oficina y le preguntó cómo iban las cosas. “Realmente bien” dijo el joven ingeniero con entusiasmo juvenil. “Esto fue mucho más simple de lo que pensé. Probablemente he terminado cerca del 75 por ciento”. El jefe sonrió y alentó al joven ingeniero a seguir trabajando bien. Planearon reunirse de nuevo en una semana.
Una semana después, el jefe llamo al ingeniero a su oficina y le preguntó “¿Dónde estamos?”. “Todo marcha bien”, dijo el joven, “pero me he encontrado con algunos pequeños obstáculos. Los solucionaré y regresaré” “¿Cómo ves la fecha límite?”, preguntó el jefe. “No hay problema”, dijo el ingeniero. “Estoy cerca de terminar el 90 por ciento.” Si se ha trabajado en el mundo del software durante unos cuantos años se es capaz de terminar la historia. No será sorpresa que el joven ingeniero haya permanecido en el 90 por ciento durante todo el proyecto y terminado (con ayuda de otros) un mes después.
93
UNIVERSIDAD PRIVADA TELESUP
Esta historia se ha repetido decena de miles de veces con los desarrolladores de software durante las pasadas cuatro décadas. La gran pregunta es por qué.
Conceptos Básicos Aunque existen muchas razones por las cuales el software se entrega con retraso, la mayoría se encuadra en una o más de las siguientes causas:
Una fecha límite irrealizable establecida por alguien externo al grupo de ingeniería del software e impuesta a los gestores profesionales del grupo.
Cambio en los requisitos del cliente que no se reflejan en modificaciones a la calendarización.
Una subestimación razonable de la cantidad de esfuerzo o de recursos que se requerirán para realizar el trabajo.
Riesgos predecibles o impredecibles que no se consideraron cuando comenzó el proyecto.
Dificultades técnicas que no pudieron preverse.
Dificultades humanas imprevisibles.
Falta de comunicación entre el personal del proyecto. lo que genera demoras.
Una falla en la gestión del proyecto porque no reconoció el retraso ni emprendió una acción para corregir el problema.
Las fechas límite muy audaces son un hecho de la vida en el negocio del software. En tales ocasiones las fechas límite se demandan por razones legítimas, desde el punto de vista de la persona que las establece. Pero el sentido común establece que la legitimidad también la deben advertir las personas que hacen el trabajo. Napoleón dijo alguna vez: “Cualquier comandante en jefe que pretenda llevar a cabo un plan que considera defectuoso comete un error; debe exponer sus razones, insistir en que el plan debe cambiarse y finalmente presentar su renuncia en lugar de ser el instrumento de la destrucción de su ejército”. Estas son las palabras fuertes que muchos gestores de proyectos de software deben considerar.
94
UNIVERSIDAD PRIVADA TELESUP
Las actividades de estimación con frecuencia se implementan atendiendo la restricción de una fecha límite definida. Si las mejores estimaciones indican que la fecha límite es irrealizable, un gestor de proyecto competente debe “proteger a su equipo de la presión excesiva [de la calendarización]… [y] devolver la presión a quienes la originan.
Para ilustrarlo, supóngase que a un equipo de ingeniería del software se la ha pedido construir con controlador en tiempo real para un instrumento de diagnóstico que será introducido al mercado en nueve meses. Después de una estimación y un análisis de riesgo cuidadoso, el gestor del proyecto llega a la conclusión de que el software, como se solicitó, requerirá 14 meses para crearlo con el personal disponible. ¿Cómo procede el gestor del proyecto? Es irreal presentarse en la oficina del cliente (en este caso el probable cliente es mercadotecnia-ventas) y demandarle que cambie la fecha de entrega. Las presiones externas del mercado han dictado la fecha, y el producto debe liberarse. Es igualmente torpe rechazar el trabajo (desde el punto de vista profesional). Así que ¿qué hacer?
En esta situación se recomiendan los siguientes pasos: 1. Realizar una estimación detallada empleando datos históricos de proyectos previos. Determinar el esfuerzo y la duración estimados para el proyecto. 2. Aplicar un modelo de proceso incremental y desarrollar una estrategia de ingeniería de software que entregará la funcionalidad crítica en la fecha límite impuesta, pero demorará otra. Documente el plan. 3. Reunirse con el cliente y, con la estimación detallada, explicarle por qué la fecha límite impuesta es irrealizable. Asegúrese de señalar que todas las estimaciones están basadas sobre el desempeño en proyectos previos. También asegúrese de indicar el porcentaje de mejoría que se requeriría para lograr la fecha límite vigente.
95
UNIVERSIDAD PRIVADA TELESUP
Son apropiados los siguientes comentarios: “Creo que podemos tener un problema con la fecha de entrega para el software controlador XYZ. Le he dado a cada uno de ustedes un análisis abreviado de las tasas de producción en proyectos previos y una estimación que mechos hecho en algunas formas diferentes. Notarán que he supuesto un 20 por ciento de mejora respecto de ritmos de producción precedentes, pero todavía tenemos una fecha de entrega que está a 14 meses en lugar de 9.”
4. Ofrezca la estrategia de desarrollo incremental como alternativa: “Tenemos unas cuantas opciones y me gustaría que tomase una decisión con base en ellas. Primero, podemos aumentar el presupuesto y conseguir recursos adicionales de modo que tendremos mucho éxito en lograr que este trabajo esté hecho en nueve meses. Pero comprenda que esto aumentará el riesgo de una calidad deficiente debido a la apretada fecha límite.
Segundo, podemos remover varias de las funciones y capacidades de software que está solicitando. Esto hará que la versión preliminar del producto sea un poco menos funcional, pero podemos anunciar toda la funcionalidad y luego entregarla en el periodo de 14 meses. Tercero, podemos prescindir de la realidad y esperar que el proyecto se complete en nueve meses. Terminaremos con nada que se pueda entregar a un cliente. La tercera opción, espero que esté de acuerdo, es inaceptable. La historia y nuestras mejores estimaciones indican que es irreal y un boleto hacia el desastre.”
Habrá algunos gruñidos, pero si se presentan estimaciones sólidas basadas en buenos datos históricos es probable que se elijan versiones negociadas a las opciones 1 o 2. La fecha límite irreal se evapora.
96
UNIVERSIDAD PRIVADA TELESUP
La TEMA 2 Calendarización de Proyectos Competencia: Conocer los principios básicos de calendarización en la ingeniería de software para resolver múltiples problemas en el desarrollo del sistema.
97
UNIVERSIDAD PRIVADA TELESUP
Tema 02: La Calendarización de Proyectos A Fred Brooks, el bien conocido autor de The Mythical Man-Month, se le preguntó una vez cómo se retrasaban los proyectos de software en la calendarización. Su respuesta fue tan simple como profunda: “Un día a la vez.” La realidad de un proyecto técnico (ya sea que involucre la construcción de una planta hidroeléctrica o el desarrollo de un sistema operativo) es que cientos de pequeñas tareas deben realizarse para lograr una meta mayor. Algunas de tales tareas están fuera de la corriente principal y se pueden completar sin preocuparse acerca de su impacto sobre la fecha de terminación del proyecto. Otras tareas se encuentran en la “trayectoria crítica”. Si estas tareas “críticas” se retrasan en la calendarización, la fecha de terminación del proyecto se pone en riesgo.
El objetivo del gestor es definir todas las tareas del proyecto, construir una red que bosqueje sus interdependencias, identificar las tareas cruciales dentro de la red y luego seguir su progreso para garantizar que la demora se reconoce “un día a la vez”. Para lograrlo el gestor debe tener una calendarización que se haya definido en un grado de resolución que permita supervisar el progreso y controlar el proyecto.
La calendarización del proyecto de software es una actividad que distribuye estimaciones de esfuerzo a través de la duración planificada del proyecto al asignar el esfuerzo a tareas específicas de ingeniería del software. Sin embargo, es importante señalar que la calendarización evoluciona a lo largo del tiempo. Durante las primeras etapas de la planificación del proyecto,
se
desarrolla
una
calendarización
macroscópica.
Este
tipo
de
calendarización identifica las principales actividades del marco de trabajo del proceso y las funciones de producto a las que se aplican. Conforme el proyecto transcurre, cada entrada en la calendarización macroscópica se refina en una calendarización detallada. Aquí se identifican y calendarizan tareas específicas del software (requeridas para completar una actividad).
98
UNIVERSIDAD PRIVADA TELESUP
La calendarización para proyectos de ingeniería del software se puede ver desde dos perspectivas bien diferentes. En la primera ya se ha establecido (irrevocablemente) una fecha final para la liberación de un sistema basado en computadora. La organización de software está restringida a distribuir esfuerzo dentro del marco temporal prescrito. La segunda visión de la calendarización de software supone que se han comentado límites cronológicos aproximados, pero que la fecha final la establece la organización de ingeniería del software. El esfuerzo se distribuye para utilizar mejor los recursos y la fecha final se define después de un análisis cuidadoso del software. Por desgracia, la primera situación se encuentra con mucha más frecuencia que la segunda.
Principios Básicos Al igual que otras áreas de ingeniería del software, varios principios básicos guían la calendarización de los proyectos. Compartimentación. El proyecto debe dividirse en compartimientos en varias actividades, acciones y tareas manejables. Lograrlo requiere descomponer tanto el producto como el proceso. Interdependencia. Se debe determinar la interdependencia de cada actividad, acción o tarea compartimentada. Algunas tareas deben ocurrir en secuencia mientras que otras pueden ocurrir en paralelo. Algunas acciones o actividades no pueden comenzar mientras no esté disponible el producto de trabajo producido por otros.
Otras asignaciones o actividades pueden ocurrir de manera independiente. Asignación de tiempo. A cada tarea por calendarizar se le debe asignar cierto número de unidades de trabajo (por ejemplo, personas-día esfuerzo). Además, a cada tarea se le debe asignar una fecha de inicio y otra de terminación que sean función de las interdependencias, y ya sea que el trabajo sea realizado con base en tiempo completo o parcial.
99
UNIVERSIDAD PRIVADA TELESUP
Validación del esfuerzo. Todo proyecto tiene un número definido de las personas en el equipo de software. Conforme ocurre la asignación de tiempo, el gestor de proyecto debe asegurarse de que, en un tiempo dado, no se han asignado más que el número de personas calendarizadas. Por ejemplo, considere un proyecto que tiene tres ingenieros de software asignados (por ejemplo, tres personas-día están disponibles por día de esfuerzo asignado). En un día dado se deben completar siete tareas al mismo tiempo. Cada una requiere 0.50 personas-día de esfuerzo. Se ha asignado más esfuerzo que el número de personas para hacer el trabajo.
Definición de responsabilidades. Toda tarea calendarizada se le debe asignar a un miembro específico del equipo. Definición de resultados. Toda tarea calendarizada debe tener un resultado definido. En proyectos de software el resultado normalmente es un producto de trabajo (por ejemplo, el diseño del módulo) o una parte de él. Los productos de trabajo usualmente se combinan en los entregables.
Definición de hitos. Cualquier tarea o grupo de tareas debe estar asociado con un hito del proyecto. Un hito se logra cuando se ha revisado la calidad de uno o más productos de trabajo y se han aprobado. Cada uno de estos principios se aplica conforme evoluciona la calendarización del proyecto. Relación entre el personal y el esfuerzo En un pequeño proyecto de desarrollo de software una sola persona puede analizar los requisitos, realizar el diseño, generar el código y dirigir las pruebas. Conforme aumenta el tamaño de un proyecto, más gente resulta involucrada. (¡Rara vez que se puede dar el lujo de acometer un esfuerzo de 10 personasaño con una persona que trabaje durante 10 años!).
100
UNIVERSIDAD PRIVADA TELESUP
Existe un mito común que todavía creen muchos gestores responsables del esfuerzo del desarrollo del software: “Si nos retrasamos en la calendarización, siempre podemos incorporar más programadores y recuperarnos más adelante en el proyecto”. Desgraciadamente, agregar más personas en etapas tardías de un proyecto con frecuencia tiene un efecto perturbador sobre éste, lo que provoca que la calendarización se desfase aún más. Las personas que se agregan deben aprender el sistema y la gente que se les enseña es la misma que estaba haciendo el trabajo. Durante la enseñanza no se realiza trabajo y el proyecto experimenta mayores retrasos.
Además el tiempo que tarda aprender el sistema, más personal aumenta el número de rutas de comunicación y la complejidad de ésta a lo largo de un proyecto. Aunque le comunicación es absolutamente esencial para el éxito del desarrollo de software, cada nueva ruta de comunicación requiere un esfuerzo adicional y, por lo tanto, tiempo suplementario. A lo largo de los años, los datos empíricos y el análisis teórico han demostrado que las calendarizaciones de proyecto son elásticas. Es decir, es posible comprimir en cierta medida la fecha de terminación (al reducir el número de recursos).
La Curva Putnam-Norden-Rayleigh (PNR) proporciona un indicio de la relación entre el esfuerzo aplicado y el tiempo de entrega para un proyecto de software. En el siguiente gráfico se muestra una versión de la curva, que representa el esfuerzo del proyecto como función del tiempo de entrega. La curva indica un valor mínimo, t0, que indica el tiempo de entrega de menor costo (es decir, el tiempo de entrega que generará el menor gasto de esfuerzo). Conforme se mueve a la izquierda de t0 (es decir, conforme intenta acelerar la entrega), la curva se eleva en forma no lineal.
101
UNIVERSIDAD PRIVADA TELESUP
Como ejemplo, supóngase que un equipo de proyecto ha estimado un nivel de esfuerzo Ea que se requerirá para lograr un tiempo de entrega nominal, td, que es óptimo en términos de calendarización y recursos disponibles. Aunque es posible acelerar la entrega, la curva se eleva muy pronunciadamente hacia la izquierda de td. De hecho, la curva PNR indica que el tiempo de entrega del proyecto no se puede comprimir más allá de 0.75 td. Si se intenta una mayor compresión, el proyecto se mueve hacia “la región imposible” y el riesgo de fracaso se eleva mucho. La curva PNR también indica que la opción de entrega de menor costo, to = 2td. La implicación aquí es que la demora en la entrega del proyecto puede reducir los costos significativamente. Desde luego, esto debe superarse frente al costo del negocio asociado con la demora.
La ecuación del software, se obtiene de la curva PNR y demuestra la relación enormemente lineal entre el tiempo cronológico para completar un proyecto y el esfuerzo humano aplicado a éste. El número de líneas de código entregadas (enunciados fuente), L, se relaciona con el esfuerzo y el tiempo de desarrollo mediante la ecuación: L = P x E1/3t4/3 donde E es el esfuerzo de desarollo en personas-mes; P, un parámetro de productividad que refleja una diversidad de factores que conducen a trabajo de ingeniería del software de alta calidad (los valores típicos de P varían entre 2 000 y 12 000); y t , la duración el proyecto en meses calendario. Al reordenar esta ecuación del software se puede llegar a una expresión para el esfuerzo de desarrollo E: E = E3 / ( P3t4 ) donde E es el esfuerzo utilizado (en personas-año) durante el ciclo de vida para el desarrollo y mantenimiento de software, y t es el tiempo de desarrollo en años. La ecuación para el esfuerzo de desarrollo se puede relacionar con el costo del desarrollo al incluir un factor de escala salarial (costo/persona-año).
Esto conduce a unos resultados interesantes. Considérese un complejo proyecto de software de tiempo real estimado en 33 000 LDC, 12 personas-año de esfuerzo. Si se asignan ocho personas al equipo del proyecto, éste se puede completar en aproximadamente 1.3 años. Sin embargo si se extiende la fecha final a 1.75 años, la naturaleza enorme no lineal del modelo produce: E = L3 / ( P3t4 ) ~ 3.8 personas-año Esto implica que, al extender la fecha final seis meses, ¡se puede reducir el número de personas de ocho a cuatro! La validez de tales resultados está abierta al debate, pero la implicación es clara: se pueden obtener beneficios al emplear menos personal durante un periodo un poco más largo para lograr el mismo objetivo.
102
UNIVERSIDAD PRIVADA TELESUP
Distribución
TEMA 3
del
Esfuerzo Competencia: Distribuir los esfuerzos dentro de la calendarización de un proyecto para definir y realizar un conjunto de tareas para un proyecto.
103
UNIVERSIDAD PRIVADA TELESUP
Tema 03: Distribución del Esfuerzo Cada una de las técnicas de estimación de proyectos de software estudiadas conduce a estimaciones de unidades de trabajo (por ejemplo, las personas-mes) requeridas para completar
el
desarrollo
del
software.
Una
distribución
recomendada del esfuerzo a través del proceso de software con frecuencia se conoce como la regla 40-20-40. Cuarenta por ciento de todos los esfuerzos se asignan al análisis y el diseño de sistemas de entrada. Un porcentaje similar se aplica en poner a prueba los sistemas de salida. Usted puede inferir correctamente que la codificación (20 por ciento del esfuerzo) no tiene tanto énfasis.
Esta distribución del esfuerzo se debe usar solamente como guía. Las características de cada proyecto deben dictar la distribución del esfuerzo. El trabajo realizado en la planeación del proyecto rara vez explica más de 2-3 por ciento del esfuerzo a menos que el plan comprometa a una organización a grandes gastos con alto riesgo. Los análisis de requisitos pueden comprometer 10-25 por ciento del esfuerzo del proyecto. El esfuerzo empleado en el análisis o elaboración de prototipos debe aumentar en proporción directa con el tamaño y la complejidad de un proyecto. Un intervalo del 20 al 25 por ciento de esfuerzo normalmente se aplica al diseño de software. También se debe considerar el tiempo utilizado en la revisión del diseño y la subsiguiente iteración.
Debido al esfuerzo aplicado al diseño de software, el código debe seguir con relativamente poca dificultad. Se puede lograr un rango de 15-20 por ciento del esfuerzo global. Las pruebas y la subsiguiente depuración explican el 30-40 por ciento del esfuerzo de desarrollo del software. El carácter crucial del software con frecuencia dicta la cantidad de pruebas que se requieren. Si el software se clasifica desde el punto de vista humano (es decir, la falla del software puede resultar en pérdida de vidas), son usuales porcentajes todavía más altos.
104
UNIVERSIDAD PRIVADA TELESUP
Definición de un conjunto de tareas para el proyecto de software Ningún conjunto de tareas es apropiado por sí sólo para todos los proyectos. El conjunto de tareas que sería apropiado
para
probablemente
un se
sistema
complejo
apreciaría
como
y
grande
demasiado
destructivo para un producto de software pequeño y relativamente simple. En consecuencia, un proceso de software eficaz debe definir una colección de conjunto de tareas, cada una diseñada para satisfacer las necesidades de diferentes tipos de proyectos.
Un conjunto de tareas es una colección de tareas de trabajo de ingeniería del software, hitos y productos de trabajo que se deben terminar para completar un proyecto particular. El conjunto de tareas debe proporcionar suficiente disciplina para lograr alta calidad de software. Pero, al mismo tiempo, no debe abrumar al equipo de proyecto con trabajo innecesario. En el desarrollo de una calendarización el proyecto requiere distribuir un conjunto de tareas a lo largo de la línea de tiempo del proyecto. El conjunto de tareas variará según el tipo de proyecto y el grado de rigor con el que equipo de software decide realizar su trabajo.
Aunque es difícil desarrollar una taxonomía completa de tipos de proyecto de software, en la mayoría de las organizaciones del ramo se encuentran los siguientes proyectos: 1. Proyectos de desarrollo del concepto, los cuales
se
inician
para
explorar
algunas
aplicaciones o conceptos de negocio de alguna nueva tecnología. 2. Proyectos
de
desarrollo
de
nuevas
aplicaciones, los cuales se llevan a cabo como consecuencia de una solicitud específica del cliente. 3. Proyectos de mejora de la aplicación, éstos ocurren cuando el software existente experimenta grande modificaciones en la función, el desempeño o las interfaces visibles para el usuario final.
105
UNIVERSIDAD PRIVADA TELESUP
4. Proyectos de mantenimiento de aplicación, los cuales corrigen, adaptan o extienden el software existente en formas que no sean obvias inmediatamente para el usuario final. 5. Proyectos de reingeniería, éstos se llevan a cabo con la finalidad de reconstruir un sistema existente (heredado), en todo o en parte.
Incluso dentro de un solo tipo de proyecto, muchos factores influyen en la elección del conjunto de tareas. Por ejemplo: tamaño del proyecto, número de usuarios potenciales, lo crucial de la misión, duración de la aplicación estabilidad de los requisitos, facilidad de comunicación con el usuario o desarrollador, madurez de la tecnología aplicable, restricciones del desempeño, características anidadas y no anidadas, el equipo del proyecto y factores de reingeniería. Cuando se consideran en conjunto, estos factores ofrecen un indicio el grado de rigor que se debe aplicar al proceso de software.
Ejemplo de conjunto de tareas Cada uno de los tipos de proyecto descritos puede abordarse secuencial,
mediante un modelo de proceso lineal, iterativo
(por
ejemplo,
los
modelos
de
elaboración de prototipo o incrementales) o evolutivo (por ejemplo, el modelo espiral). En algunos casos un tipo de proyecto fluye suavemente hacia el siguiente. Por ejemplo, los proyectos de desarrollo de las nuevas aplicaciones. Cuando termina un proyecto de desarrollo de nuevas aplicaciones, en ocasiones comienza un proyecto de mejora de la aplicación. Esta progresión es tanto natural como predecible y ocurrirá sin importar el modelo de proceso que adopte la organización. En consecuencia, las principales tareas de ingeniería del software son aplicables a todos los flujos de modelo de proceso.
106
UNIVERSIDAD PRIVADA TELESUP
Como, ejemplo, considérese las tareas de ingeniería del software para un proyecto de desarrollo del concepto. Los proyectos de desarrollo del concepto se inician cuando se debe explotar el potencial para alguna nueva tecnología. No existe certeza de que la tecnología será aplicable, pero un cliente (por ejemplo, marketing) cree que existen beneficios potenciales.
Los proyectos de desarrollo del concepto se enfocan en aplicar las siguientes tareas principales: 1.1 La determinación del ámbito del concepto precisa el ámbito global del proyecto. 1.2 La planeación preliminar del concepto establece la habilidad de la organización para acometer el trabajo que entraña el ámbito del proyecto. 1.3 La valoración del riesgo de la tecnología evalúa el riesgo asociado con la tecnología que se implementará como parte del ámbito del proyecto. 1.4 La prueba del concepto demuestra la vialidad de una nueva tecnología en el contexto del software.
1.5 La implementación del concepto pone en práctica la representación del concepto en una forma que pueda revisarla un cliente y se utiliza para propósitos de “mercadotecnia” cuando se deben vender un concepto a otros clientes o gestores. 1.6 La reacción del cliente al concepto solicita realimentación acerca de un concepto de nueva tecnología y se dirige a aplicaciones específicas de los clientes.
Una rápida exploración de estas tareas debe producir pocas sorpresas. De hecho, el flujo de ingeniería de software para los proyectos de desarrollo del concepto (y también para que todos los otros tipos de proyectos) es poco más que sentido común.
107
UNIVERSIDAD PRIVADA TELESUP
Refinamiento de las
TEMA 4
Tareas Principales Competencia: Identificar las tareas principales mediante la calendarización y elaboración de una red de tareas.
108
UNIVERSIDAD PRIVADA TELESUP
Tema 04: Refinamiento de las Tareas Principales Las tareas principales se pueden utilizar para definir la calendarización macroscópica de un proyecto. Sin embargo, esta calendarización se debe refinar para crear una calendarización detallada del proyecto. El refinamiento comienza al tomar cada tarea principal y descomponerla en un conjunto de subtareas (con productos de bajo trabajo e hitos relacionados).
Como ejemplo de descomposición de tarea, consideremos el siguiente la siguiente tarea, “determinación del ámbito del concepto”. El refinamiento de una tarea se puede lograr empleando un bosquejo de formato, pero en este libro se aplica un enfoque de lenguaje en el diseño del proceso para ilustrar el flujo de la actividad de determinación del ámbito del concepto.
Definición tarea: Tarea 1.1 Determinación del ámbito del concepto 1.1.1
Identificar necesidades, beneficios y clientes potenciales;
1.1.2
Definir eventos de salida/control y entrada deseados que impulsen la aplicación;
Comienza Tarea 1.1.2 1.1.2.1 RTF: Revisar la descripción escrita de la necesidad; 1.1.2.2 Derivar una lista de salidas/entradas visibles al cliente; 1.1.2.3 RTF: Revisar salidas/entradas con el cliente y modificar conforme se requiera; Fin de tarea 1.1.2
109
UNIVERSIDAD PRIVADA TELESUP
1.1.3 Definir la funcionalidad/comportamiento para cada función principal; Co 1.1.3.1 RTF: Revisar los objetos de datos de salida y entrada derivados en la tarea 1.1.2; 1.1.3.2 Derivar un modelo funciones/comportamientos; 1.1.3.3 RTF: Revisar funciones/comportamientos con el cliente y modificar conforme se requiera; Fin de tarea 1.1.3
1.1.4 Aislar aquellos elementos de la tecnología que se implementará en el software; 1.1.5 Disponibilidad de investigación del software existente; 1.1.6 Definir factibilidad técnica; 1.1.7 Realizar estimación rápida del tamaño; 1.1.8 Crear una Definición del ámbito; Fin de tarea 1.1 Las tareas y subtareas anotadas en el proceso de refinamiento el lenguaje de diseño forman la base de una planeación detallada de la actividad de determinar el ámbito del concepto.
Definición de Una Red de Tareas Las tareas y subtareas individuales tienen interdependencias basadas en su secuencia. Además, cuando más de una persona está involucrada en un proyecto de ingeniería del software, es probable que las actividades y tareas de desarrollo se realicen en paralelo. Cuando esto ocurre, las tareas concurrentes deben estar coordinadas de modo que se completarán cuando las tareas posteriores requieran sus productos de trabajo.
110
UNIVERSIDAD PRIVADA TELESUP
Una red de tareas, también denominada red de actividad, es una representación gráfica del flujo de tareas en un proyecto. En ocasiones se utiliza como el mecanismo mediante el cual la secuencia y dependencias de tareas son la entrada de una herramienta automatizada de calendarización del proyecto. En su forma más simple (empleada cuando se crea una calendarización macroscópica), la red de tareas muestra las principales tareas de la ingeniería del software. La siguiente figura muestra una red de tareas esquemática para un proyecto e desarrollo del concepto.
La
naturaleza
concurrente
de
las
actividades
de
ingeniería de software conduce a varios requisitos importantes de la calendarización. Puesto que las tareas paralelas ocurren de manera asíncrona, el planificador debe determinar dependencias intertareas para asegurar el progreso continuo hacia la finalización.
Además, el gestor del proyecto debe estar atento a las tareas que se encuentran en la ruta crítica. Esto es, las tareas se deben completar en la calendarización si el proyecto como un todo se debe completar a tiempo. Es importante notar que la red de tareas mostrada es macroscópica. En la red de tareas detallada (un precursor de la calendarización detallada) cada actividad que muestra la figura se debe expandir.
111
UNIVERSIDAD PRIVADA TELESUP
Calendarización La calendarización de un proyecto de software no difiere enormemente de la de cualquier esfuerzo de ingeniería multitarea. En consecuencia, las técnicas y herramientas generalizadas de calendarización de proyecto se pueden aplicar, poco modificadas, en proyectos de software. La técnica de evaluación y revisión de programa (PERT, por sus siglas en inglés) y el método de ruta crítica (CPM, por sus siglas en inglés) son dos métodos de calendarización de proyecto que se pueden aplicar al desarrollo de software.
Ambas técnicas reciben impulso de la información ya desarrollada en actividades tempranas de la planeación del proyecto:
Estimación del esfuerzo.
Descomposición de la función del producto.
Selección del modelo de proceso y conjunto de tareas apropiadas.
Descomposición de tareas.
Las interdependencias entre las tareas se pueden definir empleando una red de tareas. Las tareas, en ocasiones llamadas la estructura del trabajo (EAT, por sus siglas en inglés), se definen para el producto como un todo o para funciones individuales.
Tanto PERT como CPM ofrecen herramientas cuantitativas que permiten al planificador de software 1) determinar la trayectoria crítica: La cadena de tareas que determinan la duración del proyecto; 2) establecer las estimaciones de tiempo “más probables” para tareas individuales al aplicar modelos estadísticos; y 3) calcular los “tiempo límite” que definen una “ventana” de tiempo para una tarea particular.
112
UNIVERSIDAD PRIVADA TELESUP
Lecturas Recomendadas
CALENDARIZACIÓN DE PROYECTOS http://elchrboy.blogspot.com/2010/03/calendarizacion-de-proyectos-de.html
REFINAMIENTO DE TAREAS PRINCIPALES http://ingenieriadesoftware1641.blogspot.com/2009/04/refinamiento.html
Actividades y Ejercicios
1. En un documento en Word elaborare un refinamiento de las tareas principales para un sistema de matrículas y notas. Envíalo a través de "Refinamiento".
2. Realice una red de tareas esquemáticas para el sistema de matrículas y notas utilizando algún software que permita desarrollar las técnicas de evaluación y revisión de programa (PERT) y el método de ruta crítica (CPM). Envíalo a través de "Sistema de Matrículas".
113
UNIVERSIDAD PRIVADA TELESUP
Autoevaluación
1) Aunque existen muchas razones por las cuales el software se entrega con retraso, indique cual no se encuadra en una o más de las siguientes causas: a. Una fecha límite irrealizable establecida por alguien externo al grupo de ingeniería del software e impuesta a los gestores profesionales del grupo. b. Cambio en los requisitos del cliente que no se reflejan en modificaciones a la calendarización. c. Una subestimación razonable de la cantidad de esfuerzo o de recursos que se requerirán para realizar el trabajo. d. Riesgos predecibles o impredecibles que no se consideraron cuando comenzó el proyecto. e. Dificultades técnicas que previamente se previnieron. 2) Las actividades de estimación con frecuencia se implementan atendiendo: a. Haciendo planes para acabar en la fecha indicada. b. La restricción de una fecha límite definida. c. Dando más flexibilidad en el tiempo para entregar. d. Trabajando con metas reales y alcanzables. e. Cumpliendo, si es posible antes de la fecha límite establecida. 3) ¿Cuál de estas acciones no es recomendada en la calendarización de proyectos? a. Realizar una estimación detallada empleando datos históricos de proyectos previos. b. Reunirse con el cliente y, con la estimación detallada, explicarle por qué la fecha límite impuesta es irrealizable c. Ofrecer la estrategia de desarrollo incremental como alternativa d. Aplicar un modelo de proceso incremental y desarrollar una estrategia de ingeniería de software e. Cumplir con la presentación de los trabajos encomendados de manera individual y en equipo, respetando la iniciativa y aportes de los integrantes de manera eficaz. 4) La calendarización del proyecto de software es: a. Una métrica que nos ayuda a definir si se puede realizar el proyecto en un lapso establecido. b. Una disciplina que administra el tiempo de forma eficaz. c. Una métrica que mide el esfuerzo de una organización al entregar un proyecto en una fecha exacta. d. Una actividad que distribuye estimaciones de esfuerzo a través de la duración planificada del proyecto. e. Una actividad que integra las estimaciones de todas las áreas de una empresa para que el proyecto pueda entregarse en una fecha límite establecida.
114
UNIVERSIDAD PRIVADA TELESUP
5) En la calendarización: a. El software debe de tener la mejor calidad y productividad para que en la fecha final se defina después de un análisis cuidadoso del software. b. El esfuerzo se distribuye para utilizar mejor los recursos y la fecha final se define después de un análisis cuidadoso del software. c. El software tenga cero errores para que en la fecha final se defina un análisis cuidadoso del software. d. Un esfuerzo adicional evita que el proyecto se convierta en un fracaso y de eso modo el software se convierta en un éxito. e. El software tenga cero errores para que en la fecha final se defina un análisis de esfuerzos. 6) En el desarrollo de una calendarización el proyecto requiere: a. Distribuir un conjunto de tareas a lo largo de la línea de tiempo del proyecto b. Planificar un conjunto de tareas al inicio del proyecto. c. Distribuir un conjunto de tareas a lo largo de la línea de tiempo del proyecto. d. Distribuir un conjunto de tareas al final del proyecto. e. Distribuir un conjunto de tareas a lo largo de la programación del software. 7) Es un conjunto de tareas de ingeniería del software, hitos y productos de trabajo que se deben terminar para completar un proyecto particular a. Definición de un conjunto de análisis para el proyecto de software. b. Definición de un conjunto de tareas para el proyecto de sistemas de información. c. Definición de un conjunto de normas para el proyecto de sistemas de información. d. Definición de un conjunto de tareas para el proyecto de software. e. Definición de un conjunto de tareas para el modelamiento de software. 8) ¿Qué se requiere hacer para crear una calendarización detallada del proyecto? a. Refinamiento de la calendarización. b. Compactación de la calendarización. c. Reducción de la calendarización. d. Ampliación de la calendarización. e. Seguimiento de la calendarización. 9) Una red de tareas es: a. Es un diagrama de flujo. b. Es una ruta crítica. c. Son los nodos de un PERT determinístico. d. Es una representación probabilística del flujo de tareas en un proyecto e. Es una representación gráfica del flujo de tareas en un proyecto. 10) La técnica de evaluación y revisión de programa (PERT) y el método de ruta crítica (CPM) que no desarrolla la siguiente actividad: a. Estimación del esfuerzo. b. Descomposición de la función del producto. c. Selección del modelo de proceso y conjunto de tareas apropiadas. d. Estimación de líneas de comando. e. Descomposición de tareas.
115
UNIVERSIDAD PRIVADA TELESUP
Resumen
UNIDAD DE APRENDIZAJE IV:
La calendarizión de proyecto de software está ligado con seleccionar un modelo de proceso apropiado, identificando tareas de ingeniería del software que es preciso realizar; estimar la cantidad de trabajo y el número de personas , igual se conoce la fecha límite y se consideraron los riesgos.
La calendarización del proyecto de software es una actividad que distribuye estimaciones de esfuerzo a través de la duración planificada del proyecto al asignar el esfuerzo a tareas específicas de ingeniería del software. En la construcción de un sistema complejo muchas tareas de ingeniería de software ocurren en paralelo, y el resultado del trabajo realizado durante una tarea puede tener un profundo efecto en el trabajo llevado a cabo en otras tareas. Al igual que es imposible evaluar el progreso de un proyecto de software moderado y grande sin una calendarización.
En la distribución del esfuerzo, dicho “esfuerzo” es la medida fundamental o cantidad de trabajo que un equipo de desarrolladores debe aplicar en determinada tarea o etapa para lograr un objetivo en común, ya sean objetivos específicos o generales. El esfuerzo debe dividirse creando unidades o subequipos de trabajo con el fin de optimizar el tiempo y trabajo.
Una herramienta de suma importancia es el refinamiento del software para la realización de un software de calidad y para eso se requiere conocer los requerimientos a la hora de diseñar un software y definir cuáles son las funciones que va a tener nuestro software, y cada una de las especificaciones que este va a tener, fecha límite y que éste se entregue en la fecha límite
116
UNIVERSIDAD PRIVADA TELESUP
Glosario
AMENAZAS: Las amenazas son situaciones negativas, externas al programa o proyecto, que pueden atentar contra éste, por lo que llegado al caso, puede ser necesario diseñar una estrategia adecuada para poder sortearlas.
CICLO: Conjunto de etapas dentro de un proyecto CONTINGENCIA: Posibilidad de que algo suceda o no suceda. CRONOGRAMA: Calendario de trabajo. DEPENDENCIA: Subordinación a un poder mayor. DESGLOSE: Separar algo de un todo, para estudiarlo o considerarlo por separado. DIAGRAMA: Dibujo en el que se muestran las relaciones entre las diferentes partes de un sistema.
ELABORACIÓN GRADUAL: Desarrollar en pasos e ir aumentando mediante incrementos
ÉNFASIS ESTRATÉGICO: Sucede cuando los proyectos son patrocinados por la gerencia general
ENTREGABLES: Son documentos a entregar en un proyecto ESTIMACIÓN: Aprecio y valor que se da y en que se tasa y considera algo. ESTRATEGIA: Plan que lleva a una empresa a cumplir con la visión del negocio ESTRUCTURA: Distribución y orden con que está compuesta un proyecto. HITO: Unido, inmediato. INFLUYENTES: Son personas que tienen una influencia positiva o negativa dentro del proyecto
INTEGRACIÓN: área encargada de la unificación y consolidación INTERESADOS: Personas o organizaciones que participan activamente en el proyecto
MÉTRICA: Arte que trata de la medida, permite obtener la visión del proceso y el proyecto pues proporciona un mecanismo para lograr una evaluación objetiva.
OCURRENCIA: Encuentro, suceso casual, ocasión o coyuntura. PMBOK: Es un estándar en la Administración de proyectos desarrollado por el Project Management Institute (PMI). Comprende dos secciones, la primera sobre los procesos y contextos de un proyecto, la segunda sobre las áreas de conocimiento específico para la gestión de un proyecto.
117
UNIVERSIDAD PRIVADA TELESUP
Fuentes de Información BIBLIOGRÁFICAS:
ROGER PRESSMAN, McGraw-Hill Interamericana Editores S.A. Ingeniería del Software: Un enfoque práctico. EEUU, 2009. PROJECT MANAGEMENT INSTITUTE. Guía de los fundamentos de la dirección de proyectos. Newtown Square EEUU., 2010. JOHN J. RAKOS. Ed. La negociación y los contratos. Ed. Prentice Hall, Inc USA, 2008. KELLY KINTHER & SONS. Entendiendo el pasado para mejorar el futuro. Ed. Prentice Hall, Inc USA, 2010. JOHN WILEY & SONS. Reuniones, revisiones en informes. Ed. Prentice Hall, Inc USA, 2011. ELECTRÓNICAS:
Dirección y gestión de proyectos http://books.google.com.pe/books?id=pAQ9QelkHmkC&printsec=frontcover&hl=es &source=gbs_ge_summary_r&cad=0#v=onepage&q&f=false
Gestión de proyectos de TI http://plataforma.edu.pe/pluginfile.php/84031/mod_resource/content/1/gestion_de_ proyectos_de_ti.pdf
Objetivos y logros en proyectos de TI http://www.nacion.com/2011-05-04/Opinion/Foro/Opinion2766882.aspx
Estimación para proyectos de software http://elchrboy.blogspot.com/2010/03/estimacion-para-proyectos-de-software.html
Calendarización de proyectos http://fcqi.tij.uabc.mx/usuarios/luisgmo/data/6.3%20calendariz%202007.pdf
118
UNIVERSIDAD PRIVADA TELESUP
Solucionario UNIDAD DE
1. E
UNIDAD DE APRENDIZAJE 2: 1. B
2. B
2. B
3. C
3. D
4. E
4. B
5. A
5. E
6. B
6. A
7. D
7. B
8. C
8. C
9. A
9. C
10. E
10. C
APRENDIZAJE 1
UNIDAD DE APRENDIZAJE 3:
UNIDAD DE APRENDIZAJE 4:
1. C
1. E
2. B
2. B
3. E
3. E
4. A
4. D
5. C
5. B
6. B
6. C
7. C
7. D
8. D
8. A
9. B
9. E
10. D
10. D
119