pcp - resumen

PCP – Planificación y Control de Proyectos – Resumen Final

Módulo 1 – Introducción y Conceptos Generales

Unidad 1: Introducción Proyectos: Definición general Un proyecto es un trabajo singular con fechas definidas de inicio y finalización (calendario), una especificación clara del objetivo o alcance de la tarea, un presupuesto preestablecido y, habitualmente una organización temporal que se desmantela cuando termina el proyecto (J. Lewis)

Características • Todo proyecto es de alguna manera único.

Eso lo diferencia de las actividades diarias y repetitivas de nuestras organizaciones. Algunos son únicos porque nunca antes se han intentado hacer (ej.: construcción de una estación espacial en Marte), otros debido a que se requiere que se hagan acorde a ciertas especificaciones especiales.

• Todos los proyectos están relacionados en primer lugar con el cambio.

Significan un gran salto hacia adelante: son más revolucionarios que evolutivos, y la acción es bidireccional: una oportunidad de éxito, un riesgo de fracaso.

• En todos los proyectos hay personas implicadas.Las exigencias son distintas a las de las tareas rutinarias.

• Todos los proyectos existen en un periodo de tiempo limitado y definido.Cuando se alcanza el punto de finalización, el proyecto deja de existir.

• Todos los proyectos tienen un objetivo bien definido, un resultado o producto esperado.Ej.: Se espera poder introducir al mercado (en 10 meses y con $ 500.000) un nuevo aparato para la preparación de alimentos, que cumpla con determinadas especificaciones de rendimiento predefinidas.

• Nacen con la formulación de sus necesidades.

• Todos los proyectos son llevados a cabo con la utilización de recursos transitorios(personas, organizaciones, equipos, materiales e instalaciones).

Presupuesto operativo. Recursos limitados, administrarlos. Modo de utilización de los recursos.

• Una constante en los proyectos es la incertidumbre.La incertidumbre es la falta de información sobre la duración, ocurrencia o valor de acontecimientos futuros. El riesgo es el grado estimado de incertidumbre.

Ej.: el alcance del proyecto quizá se logre para la fecha fijada como meta, pero el costo final puede ser mucho más alto de lo anticipado debido a la baja estimación inicial del costo de ciertos recursos.

Proyecto Informático

Un Proyecto Informático es un conjunto de tareas interdependientes, con unas determinadas características, cuyo propósito es la realización de un producto de software que automatice un conjunto bien definido de requerimientos de unos usuarios, atendiendo a uno o más procesos de negocio.

Características de un Proyecto Informático

• Involucra múltiples profesiones, perfiles de RR HH y niveles de la organización.• Contiene nuevas tecnologías y elementos de incertidumbre y riesgo.

Verónica Botto – Legajo 46068 1/52


• Involucra fuertes procesos de comunicación entre personas intervinientes.

Fundamentación de la importancia de la planificación y control de proyectos

• De acuerdo al reporte del CHAOS del Standish Group –año 1995, los proyectos en promedio tienen un sobrecosto del 189% del presupuesto original y demoran un 222% respecto de las estimaciones de tiempo originales.

• La aportación del software a la economía de EE.UU.: es la principal fuente de superávit por exportaciones en la balanza comercial (20.000 millones de dólares), con 24.000 millones de dólares de ingresos por exportaciones de software y 4.000 millones gastados en importaciones (datos del año 1996, tomados de: Software Conspiracy, Mark Minasi, McGraw Hill, 2000).

• Papel del software en la infraestructura: no sólo tiene un papel importante en Internet; también en sectores como transportes, energía, medicina y finanzas.

El software se halla cada vez más presente como elemento incorporado a otros mecanismos arraigados. Los automóviles modernos, por ejemplo, poseen entre 10 y 100 procesadores para dirigir todo tipo de funciones, desde el reproductor de música hasta el sistema de frenado.

• El costo del software: La relación entre la adquisición de software y hardware se aproxima a cero.

Coste total de la propiedad del software: 5 veces el coste del hardware. (El grupo Gartner calcula que el coste de mantenimiento de una PC durante 5 años asciende en la actualidad a 7 dólares por cada K de memoria del ordenador).

• Calidad del software◦ Fallos en el desarrollo . Según estudios llevados a cabo por IBM en el año 1994, el 55% de

los sistemas costaron más de lo previsto. El 68% excedieron el tiempo previsto para su desarrollo. El 88% se tuvo que volver a diseñar por completo.

◦ Accidentes. La mayor parte de los expertos coinciden en señalar que “la manera más probable de destruir el mundo es por accidente”. Y aquí es donde entramos en juego nosotros, los profesionales de la informática: “nosotros somos los que provocamos los accidentes".

Nathaniel Borenstein, creador de MIME, en: Programming as if People Mattered: Friendly Programs, Software Engineering and Other Noble Delusions, Princeton University Press, Princeton, NJ, 1991.

Ej.:Ariane5 (Junio de 1996), de la Agencia Espacial Europea. El cohete Ariane5 explotó 30 segundos después de despegar, a causa de una excepción en el código de Ada.

◦ Software de baja calidad.

Generalmente, la medición se realiza después de la entrega del software. La medición de la calidad se hace en errores/kloc, y la media en la industria es de aproximadamente 10.

El software de alta calidad tiene 1 o menos errores/kloc.

Ej: Sistema Praxis CDIS (1993). Sistema de control de tráfico aéreo desde terminales, empleado en el Reino Unido. Este software utilizaba un lenguaje de especificación concreto, y no producía un aumento del coste de la red. Tenía una tasa de error muy baja: aproximadamente 0,75 fallos/kloc.

Elementos de la administración de proyectos. 1. Niveles Estratégico.

Táctico.Operacional.

2. Fases del Proyecto Planificación.Diseño



Desarrollo.Prueba.Implementación. Verificación.

3. Actividades del Proyecto Confeccionar cronograma.Planificar presupuesto. Manejo de recursos.Manejo riesgo/oportunidad.Control de calidad.

4. Herramientas Datos históricos de la red. Documentos de la infraestructura de la red.Modelo de proyecto.Optimización de la red.Diagrama de Gantt. Técnicas PERT/CPM.

5. Proceso Analítico Beneficios o rentabilidad.Curva del aprendizaje.Escalabilidad.Interoperabilidad. Portabilidad. Riesgo. Herencia (software y hardware).

6. Ambiente Los paradigmas del sistema son cliente/servidor y orientado a objetos.

7. Gente Aunque éste es el séptimo enumerado, es el elemento más importante. La gente discute acerca del “equipo” y el “cliente”. Es necesario tomar ambos conceptos para alcanzar el éxito. En esta ocasión, este tipo de actividad se refiere al manejo del conflicto.

Ciclos de vida de un proyecto informático. Define comienzo y fin del proyecto. Identifica qué debe hacerse y quiénes están involucrados.

Características: costos y asignación de recursos, riesgos e incertidumbre, influencias de los accionistas.



Ciclo de vida del producto (SDLC, System Development Life Cicle)

El Ciclo de Vida del desarrollo de Sistemas, o proceso de desarrollo de software, es el proceso de crear o alterar sistemas de información, y los modelos y metodologías que se usan para desarrollar estos sistemas.

El estándar internacional para describir el método de seleccionar, implementar y monitorear el ciclo de vida para el software es el ISO/IEC 12207.

El trabajo que se asocia a la Ingeniería del Software se puede dividir en tres fases genéricas, con independencia del área de aplicación, tamaño o complejidad del proyecto.

1. La fase de definición se centra sobre el qué. Se identifica la información que ha de ser procesada, que función y rendimiento se desea, que comportamiento del sistema, qué interfaces van a ser establecidas, qué restricciones de diseño existen y que criterios de validación se necesitan para definir un sistema correcto. Por tanto, han de identificarse los requisitos clave del sistema y del software.

Tienen lugar tres tareas principales: ingeniería de sistemas o de información, planificación del proyecto de software, y análisis de los requisitos.

2. La fase de desarrollo se centra en el cómo. Se intenta definir cómo han de diseñarse las estructuras de datos, cómo ha de implementarse la función como una arquitectura del software, cómo han de implementarse detalles procedimentales, cómo han de caracterizarse las interfaces, cómo traducir el diseño en un lenguaje de programación (o lenguaje no procedimental) y cómo realizar la prueba.

Si bien variarán los métodos aplicados durante esta fase, hay tres tareas que deberían ocurrir siempre: diseño del software, generación de código y prueba del software.

3. La fase de mantenimiento se centra en el cambio que va asociado a la corrección de errores, a las adaptaciones requeridas a medida que evoluciona el entorno del software y a cambios debidos a las mejoras producidas por los requisitos cambiantes del cliente.

Durante esta fase se encuentran cuatro tipos de cambios:

1. Corrección: Aún llevando a cabo las actividades de garantía de calidad, es probable que el cliente descubra defectos en el software. El mantenimiento correctivo corrige dichos defectos.

2. Adaptación: Con el paso del tiempo, es probable que cambie el entorno para el cual se desarrolló el software (CPU, SO, reglas de la empresa, etc). El mantenimiento adaptativo modifica el software para acomodarlo a los cambios de su entorno externo.

3. Mejora: A medida que se utiliza el software, pueden descubrirse funciones adicionales que serían beneficiosas. El mantenimiento perfectivo lleva al software mas allá de los requerimientos originales.

4. Prevención: El software se deteriora debido al cambio. El mantenimiento preventivo hace cambios en los programas a fin de que se puedan corregir, adaptar y mejorar más fácilmente.

Modelos de Proceso de Software

Se selecciona un modelo de proceso para la ingeniería del software según la naturaleza del proyecto y de la aplicación, los métodos y las herramientas a utilizarse, y los controles y entregas que se requieren. A continuación se tratan diferentes modelos de procesos, que representan un intento de ordenar una actividad inherentemente caótica.

Modelo en cascada (o modelo lineal secuencial)

El modelo en cascada sugiere un enfoque sistemático, secuencial del desarrollo del software, que comienza en un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y mantenimiento.



Actividades

• Ingeniería y modelado de información: El trabajo comienza estableciendo requisitos de todos los elementos del sistema y asignando al software algún subgrupo de estos requisitos. Esta visión es esencial cuando el software se debe interconectar con otros elementos como hardware, personas y bases de datos.

• Análisis de los requisitos de software: Debe comprenderse el dominio de información del software, la función requerida, comportamiento, rendimiento e interconexión. El cliente documenta y repasa los requisitos del sistema y del software.

• Diseño: Es un proceso que se centra en cuatro atributos distintos de un programa: estructura de datos, arquitectura del software, representaciones de interfaz y algoritmo. El diseño traduce requisitos en una representación del software que se pueda evaluar por calidad antes de que comience la generación del código.

• Generación de código: Se traduce el diseño a una forma legible para la máquina.

• Pruebas: Se centran en procesos lógicos internos del software, asegurando que todas las sentencias se han comprobado, y en los procesos externos funcionales, que aseguran que la salida sea la esperada.

• Mantenimiento: El software sufrirá cambios después de ser entregado al cliente, porque se han encontrado errores, porque debe adaptarse a los cambios de su entorno externo o porque el cliente requiere mejoras funcionales o de rendimiento. El mantenimiento aplica cada una de las fases precedentes a un programa ya existente.

Desventajas

Este modelo es el paradigma mas antiguo y extensamente utilizado. Sin embargo, existen problemas que ponen en duda su eficacia, entre los que se encuentran:

1. Los proyectos reales rara vez siguen el modelo secuencial, por lo que este modelo no puede imitar adecuadamente las actividades de la vida real.

2. A menudo es difícil que el cliente exponga todos los requisitos. Este modelo lo requiere, y tiene dificultades al manejar la incertidumbre natural al comienzo de muchos proyectos. Su aplicación debería estar limitada a situaciones donde los requerimientos y su implementación están bien entendidos.

3. El cliente debe tener paciencia. Una versión de trabajo del programa no estará disponible hasta que el proyecto esté muy avanzado. Un grave error puede ser desastroso si no se detecta hasta que se revisa el programa.

4. Los responsables del desarrollo del software siempre se retrasan innecesariamente. Este modelo lleva a estados de bloqueo en los que algunos miembros del equipo de desarrollo deben esperar a otros para completar tareas dependientes. Los estados de bloqueo tienden a ser mas importantes al principio y al final de un proceso lineal secuencial.

Pese a estas debilidades, el ciclo de vida clásico sigue siendo el modelo de proceso mas usado en la industria, y es significativamente mejor que un enfoque al azar para el desarrollo de software.



Modelo de construcción de prototipos

Este enfoque es ideal cuando el cliente define objetivos generales pero no identifica los requisitos detallados, o cuando el desarrollador no está seguro de la eficacia de un algoritmo, de la capacidad de adaptación de un SO o de la forma en que debería darse la interacción hombremáquina.

La construcción del prototipo comienza con la recolección de requisitos conocidos, y se identifican las áreas del software donde es necesaria mayor definición. Entonces, aparece un “diseño rápido”, que se centra en una representación de esos aspectos del software que serán visibles para el usuario/cliente. El diseño rápido lleva a la construcción de un prototipo, que el cliente evalúa y utiliza para refinar los requisitos del software a desarrollar. Con la interacción, el prototipo satisface las necesidades del cliente y el desarrollador comprende mejor lo que se necesita hacer, porque actúa como un mediador entre el punto de vista del desarrollador y el punto de vista del usuario, vistas que con frecuencia son significativamente diferentes.

Una vez que el prototipo ha servido para el propósito indicado, debería tirarse y construir un sistema nuevo.

Desventajas

Si bien a los clientes y desarrolladores les gustan los prototipos los primeros, porque ven el “sistema real” los segundos porque pueden construir algo inmediatamente este modelo puede ser problemático:

1. El cliente ve lo que parece ser una versión de trabajo del software y no sabe que, con la prisa de hacer que funcione, no se ha tenido en cuenta la calidad del software global, o la facilidad de mantenimiento a largo plazo. Cuando se le informa que debe construirse el producto otra vez, no lo entiende y pide que se le hagan ajustes para transformarlo en el producto final. Muy frecuentemente, la gestión del desarrollo del software es muy lenta.

2. El desarrollador hace compromisos de implementación para que el prototipo funcione rápidamente. Se puede usar un SO o un lenguaje de programación inadecuados simplemente porque son conocidos y están disponibles, o implementar un algoritmo ineficiente para demostrar la capacidad. Después de algún tiempo, el desarrollador puede olvidarse de las razones por las cuales estas elecciones son inadecuadas. La selección menos ideal es ahora una parte integral del sistema.

La construcción de prototipos puede ser un paradigma efectivo, pero la clave es definir las reglas de juego desde el principio: cliente y desarrollador se ponen de acuerdo en que el prototipo es un mecanismo de definición de requisitos. Entonces se descarta al menos parcialmente y se realiza la ingeniería de software con una visión hacia la calidad y la facilidad de mantenimiento.

Modelo DRA

El Desarrollo Rápido de Aplicaciones, (RAD, Rapid Application Development) es un modelo del proceso de desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. Es una adaptación a alta velocidad del modelo lineal secuencial, en el que se logra un desarrollo rápido basado en componentes. Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite que el equipo de desarrollo cree un sistema completamente funcional dentro de períodos cortos de tiempo, por ejemplo de 60 a 90 días.



Desventajas

Al igual que todos los modelos de proceso, el enfoque DRA tiene inconvenientes:

1. Para proyectos grandes, requiere recursos humanos suficientes para crear el número necesario de equipos RAD.

2. Requiere clientes y desarrolladores comprometidos en las rápidas actividades necesarias para completar un sistema en un tiempo abreviado.

3. No todos los tipos de aplicaciones son apropiados para DRA. Si un sistema no se puede modularizar adecuadamente, la construcción de los componentes para DRA será problemático.

4. EL DRA no es adecuado cuando los riesgos técnicos son altos (cuando el software usa tecnología nueva o requiere un alto grado de interoperatividad con programas existentes.

Modelos de Procesos Evolutivos de Software

El software, al igual que todos los sistemas complejos, evoluciona con el tiempo. Para estos sistemas, los ingenieros de software necesitan un modelo de proceso que se haya diseñado para acomodarse a un producto que evolucione con el tiempo.

Los modelos evolutivos son iterativos. Se caracterizan por la forma en que permiten desarrollar versiones cada vez mas completas del software.

Modelo Incremental

El modelo incremental combina elementos del modelo lineal secuencial (aplicados repetitivamente) con la filosofía interactiva de construcción de prototipos. Cada secuencia lineal produce un “incremento” en la funcionalidad del software.

Cuando se usa este modelo, el primer incremento a menudo es un producto esencial (núcleo). Es decir, se afrontan requisitos básicos, pero muchas funciones suplementarias quedan sin desarrollar. El cliente utiliza este producto y, como resultado de la utilización/evaluación, se desarrolla un plan para el incremento siguiente. Este proceso se repite siguiendo la entrega de cada incremento, hasta que se elabore el producto completo.

El modelo incremental, al igual que el de construcción de prototipos, es interactivo por naturaleza; pero a diferencia de éste, se centra en la entrega de un producto operacional con cada incremento.

Es particularmente útil cuando la dotación de personal no está disponible desde el principio del desarrollo. Si el producto inicial es bien recibido, se puede añadir mas personal para implementar los incrementos siguientes. Además, los incrementos se pueden planear para gestionar riesgos técnicos.

Si es muy riesgoso desarrollar el sistema completo de una sola vez, debería considerarse este modelo.



Modelo en espiral

Es un modelo evolutivo que acompaña la naturaleza interactiva de la construcción de prototipos con los aspectos controlados y sistemáticos del modelo secuencial lineal, supera muchas de las dificultades de los modelos previos, y al mismo tiempo que incorpora lo mejor de los mismos.

El modelo en espiral se divide en un número de actividades estructurales, también llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas, cada una poblada por una serie de tareas que se adaptan a las características del proyecto que se va a desarrollar; para proyectos pequeños, el número de tareas y su formalidad es baja. Para proyectos mayores y críticos, cada región contiene tareas que se definen para lograr un nivel mas alto de formalidad.

Regiones de tareas/Actividades estructurales

1. Comunicación con el ClienteLas tareas requeridas para establecer comunicación entre el desarrollador y el cliente.

2. PlanificaciónLas tareas requeridas para definir tiempos, recursos y otras informaciones relacionadas con el proyecto.

3. Análisis de RiesgoLas tareas requeridas para evaluar riesgos técnicos y de gestión.

4. IngenieríaLas tareas requeridas para construir una o mas representaciones de la aplicación.

5. Construcción y AdaptaciónLas tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario (por ejemplo, documentación y práctica)

6. Evaluación del ClienteLas tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementada durante la etapa de instalación.

A diferencia del modelo de proceso clásico, puede adaptarse y aplicarse a lo largo de todo el ciclo de vida del software. Cuando la espiral se caracteriza de esta forma, permanece operativa hasta que el software se retira.

El modelo en espiral es un enfoque realista del desarrollo de sistemas y de software a gran escala, utiliza la



construcción de prototipos como mecanismo de reducción de riesgos, y si se aplica adecuadamente, debe reducir los riesgos antes de que se conviertan en problemáticos.

Este modelo se popularizó mucho entre los especialistas de ADE (Aeroespacio, Defensa e Ingeniería) pero no tanto entre los desarrolladores de aplicaciones comerciales. Los primeros son riesgosos por naturaleza, mientras los proyectos comerciales son más conservadores, ya que tienden a utilizar tecnología con un mayor grado de madurez y a trabajar sobre problemas bien conocidos.

Las tres restricciones en la administración de proyectos.

Estas son: alcance, tiempo y coste. Sirven para ver cómo cambiar el proyecto cuando cambia el mundo (requerimientos, RRHH, etc.), de manera de pensar, negociar objetivos y tomar decisiones realistas.

Por la incertidumbre natural de los proyectos y la competencia por los recursos, es raro completar los proyectos acorde a un alcance exacto, tiempo y costo originalmente estimados. Debe contemplarse un balance entre las tres restricciones, definiendo prioridades relativas.

El alcance es el trabajo implicado en la ejecución del proyecto. ¿Qué producirá el proyecto?

El tiempo es cuánto tiempo se requerirá para terminar el proyecto. ¿Cuanto tiempo tomará el proyecto?

El coste es cuánto costará terminar el proyecto. ¿Cuánto dinero costará el proyecto?

¿Para qué nos sirve conocer las restricciones?: ¡Para negociar!

¿Negociar para qué? Para cumplir con los objetivos y encontrar mejores objetivos a lo largo de las distintas fases del proyecto. Para ello, tener en cuenta los recursos humanos y la calidad requerida para el proyecto.

¿Con quién? Clientes, gerencia, líder de proyecto.



Módulo 2 – Áreas Básicas del Conocimiento

Unidad 2: Planificación y definición del alcance Planificación y definición del alcance. El ciclo de desarrollo del software incluye varias etapas o fases (concepto, especificación de requisitos, construcción, verificación, aceptación, operación), que permiten alcanzar un sistema completo y usuarios satisfechos.

Aunque gran parte de las discrepancias entre cliente y equipo de trabajo se derivan de la dificultad para satisfacer los requerimientos, ya que el trabajo realizado no satisface las expectativas del cliente o no cumple al 100% sus especificaciones, la raíz del conflicto reside en la mayor parte de los casos en una mala especificación del usuario (o del cliente).

Por lo general el cliente, antes de comprometer fondos para un desarrollo de software, quiere una estimación de costo y duración del proyecto.

Un proyecto típico comienza cuando un cliente se acerca para discutir una necesidad percibida.

Ej.: un banco nacional requiere ayuda para la construcción de un sistema de información de sus cuentas, sin importar en qué parte del mundo se encuentren éstas.

Con esa definición no basta; es necesario especificar detalladamente el alcance concreto del trabajo: funcionalidad, prestaciones, características físicas, interfaces, etc. Caso contrario surgirán (antes o después) conflictos durante la fase de ejecución del proyecto, ya que el esfuerzo a realizar depende fuertemente de estos detalles.

Ej.: no es lo mismo una LAN con Windows que con UNIX. No cuesta lo mismo desarrollar una base de datos relacional con una interfaz de usuarios web, que un registro de pedidos básico.

Entonces, concluimos que una definición completa de requisitos para con el usuario, consistente y verificable y que se propague a través de todo el ciclo de vida del desarrollo del software, es clave para la culminación con éxito del proyecto.

Para ello existe una herramienta que genera una Estructura de Descomposición del Trabajo, que desarrollaremos a continuación.La estructura de descomposición del trabajo se desarrolló inicialmente por el Departamento de Defensa norteamericano, y se describe en normas.

Estructura de descomposición del trabajo. • Trabajar con los clientes y potenciales usuarios para entender qué quieren y qué necesitan,

asegurándonos de que se sientan cómodos con el entendimiento de sus necesidades.

• Listar todos los elementos a entregar del proyecto (ítems que espera ver el cliente durante el desarrollo del proyecto). Los elementos pueden ser:

DocumentosDemostraciones de funcionesDemostraciones de precisiónDemostraciones de confiabilidad, seguridad y desempeño

• Determinar qué actividades deben efectuarse para producir estos elementos (ver técnica de modelado de proceso UML). Distinguir entre hitos y actividades:

Actividad: parte del proyecto que tiene lugar durante un período; tiene principio y fin.Hito: Completitud de una actividad en un determinado momento; momento final de una actividad especialmente diseñada.



Al proyecto analizado de esta forma lo podemos separar en una sucesión de fases. Cada fase está compuesta por etapas y cada etapa puede subdividirse posteriormente, si fuera necesario.

La estructura de descomposición del trabajo de un proyecto no da una indicación de la interdependencia de las unidades de trabajo, ni muestra qué partes del proyecto pueden desarrollarse en forma concurrente. Ej:

En aplicaciones como MSProject o una aplicación de dirección de proyecto similar, se puede encontrar la estructura de descomposición del trabajo como una lista vertical, con las sangrías mostrando la estructura. Esto será compatible con las Vistas de Gantt.

Involucramiento de la gerencia.

Planificación y definición del alcance estratégico:El encargado estratégico debe participar de la primera reunión y tener en cuenta lo siguiente:

• El proyecto apoya ciertas metas corporativas. • El encargado táctico, administrador del sistema IS, tiene autoridad completa para manejar

este proyecto. • Aquí están las conclusiones de la evaluación que se condujo para comenzar el proyecto.

Planificación y definición del alcance táctico:

La responsabilidad principal del líder es asegurarse de que existan metas en la planificación y definición del alcance.

• Esto puede parecer imposible de hacerse, pero no arremeta. ¿A usted le gustaría manejar sobre un puente que fue construido sin ninguno de los planes del diseño?



• Usted no debe ejercer presión en la planificación; los resultados son suposiciones, no dirigidos.

• Usted necesita utilizar datos históricos, pero “tiene la licencia de que usted ha hecho esto antes”.

• Usted debe centrarse en las necesidades de los clientes antes que en los requerimientos técnicos.

• Reconozca que todo tiene igual valor.

• Recuerde la palabra más importante de cualquier proceso del proyecto: “cliente”.

Planificación y Definición del Alcance Operacional

Los encargados operacionales deben asistir al encargado táctico en satisfacer esa responsabilidad primaria de los administradores para adquirir los datos de apoyo para obtener metas realistas.

• Reconozca que la planificación y definición del alcance es un esfuerzo del equipo.

• Recuerde el propósito del proyecto, satisfacción del cliente.

• Recuerde que usted es responsable de una cierta parte del proceso del proyecto sobre una base cotidiana y usted necesita disponer un sistema realista de responsabilidades medibles al encargado táctico y al equipo.

• Identifique cómo usted y su equipo pueden ser los más eficientes y eficaces en alcanzar las metas definidas del proyecto para la planificación y definición del alcance de una manera oportuna y eficiente en coste.

No se quede con una preocupación específica, ya sea técnica, de capacitación, de documentación, o de comercialización. Lo más importante es escuchar lo que tiene que decir el cliente.

Unidad 3: Planificación y secuenciamiento de actividades

Descomposición del trabajo y diagrama de actividades:

Una estructura de descomposición del trabajo (Work Breakdown Structure) es la descomposición orientada a la entrega de un proyecto en componentes mas pequeños. Define y agrupa los elementos de trabajo de un proyecto de tal manera que ayude a organizar y a definir el alcance total del proyecto.

Un elemento puede ser un producto, un dato, un servicio o cualquier combinación de ellos. Una EDT también provee el marco necesario para la estimación y control de costos detallados junto con la guía para el desarrollo y el control del proyecto.

Los elementos comunes de todos los EDT son:1. El alcance del proyecto, los “entregables” del proyecto.2. Fecha inicial y final del alcance del proyecto.3. Presupuesto para el alcance del proyecto4. Nombre de la persona relacionada con el alcance del proyecto

La estructura de descomposición del trabajo representa el proyecto como un conjunto de piezas de trabajo separadas. Actividades e hitos, definidos anteriormente, son elementos que cliente y desarrollador pueden utilizar para rastrear el desarrollo o mantenimiento.

Regla del 100%

Un principio de diseño importante para los EDT es la regla del 100%, que se define de la siguiente manera:



un EDT incluye el 100% del trabajo definido por el alcance del proyecto y captura todos los entregables internos, externos, intermedios en términos del trabajo que debe ser completado, incluyendo la administración del proyecto. Esta regla se aplica a todos los niveles dentro de la jerarquía: la suma de los trabajos de un nivel “hijo” deben sumar el 100% del trabajo representado por el “padre”, y el EDT no debe incluir ninguna tarea por fuera del alcance real del proyecto, es decir, no puede incluir mas del 100% del trabajo.

Es importante recordar que la regla del 100% también se aplica al nivel de actividades. El trabajo representado por las actividades en cada paquete deben sumar el 100% del trabajo necesario para completar el paquete.

Actividades

En un diagrama de este tipo, se definen actividades y se ilustran las relaciones entre ellas, teniendo en cuenta que las actividades tienen cuatro características:

1. El precedente: evento o conjunto de eventos que deben ocurrir antes de que la actividad pueda comenzar.

2. La duración: cantidad de tiempo necesaria para completar la actividad.

3. La fecha de entrega: fecha para la cual debe estar completada la actividad.

4. El punto final: hito o componente listo para entregar.

Para construir la red de un diagrama de actividades, primero se deben determinar todas las actividades involucradas en el proyecto. Luego, existen tres alternativas para establecer la red:

1 Partiendo del acontecimiento final y trabajando de derecha a izquierda. 2 Método de progresión: se comienza con el acontecimiento inicial. 3 Método medio: se trabaja desde el punto elegido en ambas direcciones.

Los diagramas de actividades tienen dos formas de representación: actividades en las flechas y actividades en los nodos.

Diagrama de Actividades en las flechas (AOA, Activity On Arrow o ADM, Arrow Diagramming Method)

Es una técnica de diagramación de red en la cual las actividades se representan por flechas. Se usa para agendar actividades en un plan de proyectos. La relación de precedencia entre actividades se representa por círculos conectados por una o mas flechas. La longitud de la flecha representa la duración de la actividad relevante. AOA sólo muestra relaciones finalaprincipio, es decir que cada actividad se completa antes de que la actividad sucesora comience.

A veces se agrega una actividad ficticia para representar una dependencia entre tareas, la cual no representa a ninguna actividad real. Esta tarea se agrega para indicar la precedencia que no puede ser expresada usando sólo las actividades reales. A menudo, esta tarea tiene un tiempo de duración de 0.

Las flechas representan las actividades involucradas y las dependencias entre actividades, y los nodos del grafo son los hitos del proyecto.



Un AOA permite dar visibilidad a características importantes del proyecto, por ejemplo que una actividad no puede comenzar hasta que finalice otra, o que se pueden hacer varias cosas en paralelo. Las actividades que no tienen dependencia entre sí, pueden realizarse concurrentemente.

El uso del diagrama AOA como una práctica común de la administración de proyectos ha declinado con la adopción de herramientas de programación. Adicionalmente, el método de diagrama de precedencia (PDM, Precedence Diagrama Method) o Actividad en los Nodos (AON) se usa mas que el AOA.

El evento representado por el nodo no consume tiempo ni recursos:

• Un nodo es un hito específico, definido en el proyecto.• Tiene duración 0 y no consume ningún recurso.• Todas las actividades que llegan al nodo deben ser completadas antes de que la actividad

que sigue al nodo pueda ser realizada.

Lógica para construir un AOA

• Cada actividad es representada por una sola flecha y a cada flecha corresponde una sola y única actividad.

• Todas las actividades que terminan en un mismo punto deben preceder a todas aquellas que empiezan en ese punto.

• Todo lo que demore el cumplimiento del plan (entrega de materiales, etc.) se indica con una flecha.

• Cuando una tarea es ejecutada no se puede volver a ella: no existen ciclos.• Una actividad no puede comenzar hasta que las precedentes no finalicen.• La red debe numerarse de izquierda a derecha y de arriba hacia abajo.

• Todos los nodos, salvo el del comienzo y el del fin, deben estar precedidos y seguidos de una actividad por lo menos.

Actividades y tiempos estimados: Si agregamos la duración a cada actividad, al borde correspondiente del diagrama se tendrá información más útil. Lo vemos con el ejemplo a continuación:



Diagrama de actividades en nodos (AON, Activity On Node o PDM, Precedence Diagram Method)

El diagrama AON es una herramienta para programar actividades en el plan de proyecto. Es un método de construir un diagrama de red con la agenda del proyecto que usa nodos para representar las actividades y las conecta con flechas que muestran las dependencias.

Un diagrama AON se caracteriza por:• Mostrar tareas críticas, no críticas y tiempo de holgura• Muestra las relaciones entre las distintas tareas• Permite escenarios de distinto tipo: whatif, peor caso, mejor caso y mas probable.

Es un método popular porque ayuda a encontrar el camino crítico, a definir la cantidad de tiempo requerido para el proyecto, identificar plazos de entrega y retrasos, y disminuir los recursos usados en un proyecto.

También puede usarse para project crashing, es decir reducir el tiempo de terminación del proyecto, incrementando los recursos, con lo que se aumenta el costo. El objetivo es reducir la duración del proyecto minimizando el costo de crash, reduciendo el tiempo de una o más de las actividades críticas del proyecto.

Hitos• Un hito es un suceso o acontecimiento crítico para el proyecto• No tiene duración. Ejemplo: Fecha de aprobación

Actividades

Fecha temprana de comienzo Ftc• Es la fecha mas temprana en que una actividad puede iniciarse• Es el tiempo de terminación más próximo de la actividad que la precede en forma inmediata.

Cuando la preceden (convergen) varias actividades, el Ftc es el mayor de los tiempos de esas actividades.

• Se calcula de izquierda a derecha.

Fecha temprana de fin Ftf• Es la fecha más temprana en la cual puede finalizar la actividad. Es el resultado de sumar la

duración de la actividad (dE) a su fecha temprana de inicio.• Ftf = Ftc + dE



Fecha Tardía de fin FTf• Es la fecha más tardía en la cual puede finalizar la actividad sin comprometer el tiempo de

finalización del proyecto. Resulta de tomar la mínima fecha tardía de inicio de actividad de todas las actividades que la suceden.

• Se comienza por el último nodo, donde Ftf=Ftf. Es igual al tiempo de inicio más tardío de la actividad que la sigue en la secuencia en forma inmediata. Si existe más de una actividad que la siguen en forma inmediata, la FTf será el menor de los FTc de esas actividades.

Fecha Tardía de comienzo FTc• Es la fecha más tardía en la cual puede iniciarse la actividad sin comprometer el tiempo de

finalización del proyecto. Resulta de restar la duración de la actividad a su fecha tardía de fin.• Es igual al tiempo de finalización más tardío menos la duración esperada de la tarea.

FTc = FTf – dE

Holgura Margen de la Actividad

Se define como holgura de la actividad a la diferencia entre su fecha tempranas y su fecha tardía de inicio (la diferencia entre las fechas de fin tiene el mismo valor). Las actividades críticas (las que forman parte de algún camino crítico) tienen holgura cero.

La holgura (H) es la máxima cantidad de tiempo que una actividad puede retrasarse sin afectar la duración total del proyecto. Se puede calcular de dos modos:

1. H = FTf – Ftf

2. H = FTc – Ftc

Camino crítico: • Un camino es una secuencia de actividades que se extiende desde el nodo inicial hasta el

nodo final de la red. El camino crítico es aquel que tuviere la mayor duración (puede haber más de un camino crítico), y que definirá el tiempo de duración del proyecto.


11 C 21 21 E 26 36 H 4110 5 5 FIN

INICIO26 G 36 42 J 47

0 A 5 5 B 11 10 55 6

11 D 15 15 F 24 36 I 424 9 6


• Es el camino compuesto por un conjunto de actividades con margen nulo.

• Es el menor tiempo requerido para completar el proyecto y el camino más largo. En el grafo, compuesto por {A,B,C,E,G,I,J}

Actividades a desarrollar para definición y secuenciamiento de actividades.

Técnicas de planificación temporal

Diagrama de Gantt

Un diagrama de Gantt es un tipo de gráfico de barras, desarrollado por Henry Gantt en 1910, que ilustra el calendario de un proyecto. Muestra las fechas de inicio y fin de las actividades de un proyecto. Estas actividades son lo elementos de un EDT. Es un gráfico lineal donde el tiempo figura en el eje horizontal y las actividades en el vertical

Ventajas y Limitaciones

Los diagramas de Gantt se han transformado en una técnica común para representar las fases y actividades de un esquema de descomposición del trabajo (EDT), por lo que pueden ser entendidos por una gran cantidad de personas.

Un error común cometido por aquellos que confunden el diseño de un diagrama de Gantt con el diseño del proyecto es que intentan definir el EDT al mismo tiempo que definen la programación de las actividades. Esta práctica hace muy difícil seguir la Regla del 100%. La forma correcta de trabajar es definir completamente el EDT de tal forma que siga esa regla, y luego diseñar el diagrama de Gantt.

Aunque este diagrama es útil y valioso para pequeños proyectos que caben en una sola hoja o pantalla, pueden ser difíciles de manejar para proyectos con mas de 2530 actividades. Los gráficos de Gantt muy grandes no pueden verse en la mayoría de los monitores. Una crítica relacionada es que comunican relativamente poca información por unidad de visualización; es decir que los proyectos son, en general, mas complejos de lo que se puede comunicar efectivamente con un diagrama de Gantt.

El diagrama de Gantt sólo representa parte de las tres restricciones (costo, tiempo y alcance), porque se enfoca primariamente en la administración de la agenda. Además, no representa el tamaño de un proyecto o el tamaño relativo de los elementos de trabajo, por lo que la magnitud de lo que queda fuera del diagrama es fácilmente mal comunicada. Si dos proyectos tienen la misma cantidad de días de atraso, el proyecto mas grande tiene mayor impacto en la utilización de recursos. A pesar de esto, el Gantt no muestra la diferencia.



Aunque el software de administración de proyectos puede mostrar las dependencias como lineas entre las actividades, si existe una gran cantidad de dependencias, el gráfico será ilegible.

Como las barras horizontales del diagrama tienen una altura fija, puede representar mal la carga de trabajo (requerimientos de recursos) de un proyecto, siendo confuso especialmente en proyectos muy grandes.

En el gráfico que se muestra a continuación, las actividades E y G parecen ser del mismo tamaño pero, en realidad, pueden tener distintos órdenes de magnitud. Otra crítica es que los diagramas de Gantt muestran la carga de trabajo como una constante cuando, en la práctica, muchas actividades (especialmente aquellos elementos acumulados) tienen planes de carga de trabajo diferentes, y como esto no se ve en el diagrama, se puede comunicar erróneamente el verdadero estado de de ejecución de la tarea.

Pert (Program/Project Evaluation and Review Technique)

La Técnica de Evaluación y Revisión de Programas, comúnmente abreviada PERT, es una herramienta estadística, usada en la administración de proyectos, que está diseñada para analizar y representar las tareas involucradas para completar un proyecto dado. Desarrollada en los años 50 por la Marina de Estados Unidos, se la usa generalmente en conjunto con el método CPM (Critical Path Method).

PERT es un método para analizar las tareas necesarias para completar un proyecto, especialmente el tiempo necesario para cada una de ellas, y para calcular el tiempo mínimo que llevará terminar todo el proyecto.

Gráfico de una red PERT para un proyecto con cinco hitos (10 a 50) y seis actividades (A a F)



Convenciones

• Un diagrama PERT es una herramienta que facilita la toma de decisiones. El primer borrador de un PERT numerará los eventos secuencialmente, de a 10 (10, 20, 30, etc.) para permitir la inserción posterior de eventos adicionales.

• Dos eventos consecutivos en un diagrama PERT están relacionados por actividades, las que se representan por flechas.

• Los eventos se presentan en una secuencia lógica, y ninguna actividad puede comenzar hasta que el evento inmediato anterior (precedente) esté completo.

• El planificador decide cuales hitos deben ser eventos PERT y también la secuencia apropiada.

• Un diagrama PERT puede tener múltiples páginas con muchas subtareas.

PERT es una técnica valiosa para administrar, y reducir la redundancia donde múltiples tareas ocurren simultáneamente.

Es una técnica muy popular de análisis de camino crítico que asume una distribución normal. Permite determinar la probabilidad de que el Ftc (Fecha temprana de comienzo) para una actividad esté próximo al tiempo planeado para esa actividad.

Con PERT se puede calcular el camino crítico, e identificar aquellas actividades que pueden ser un cuello de botella, usando la información de distribución de probabilidades, tiempos de comienzo más tardíos y tempranos y el diagrama de actividades.

Duración estimada de las actividades

Cuando existe un alto grado de incertidumbre se usan tres tiempos estimados para cada actividad, a partir de los cuales se obtiene el tiempo esperado para esa actividad.

Para estimar la duración esperada de cada actividad es también deseable tener experiencia previa en la realización de tareas similares. En planificación y programación de proyectos se estima que la duración esperada de una actividad es una variable aleatoria de distribución de probabilidad Beta Unimodal de parámetros (to, tm, tp) donde:

Tiempo Optimista (to) = mínimo tiempo posible para completar una actividad en particular, asumiendo que todo va mejor de lo que puede esperarse.

Tiempo Pesimista (tp) = tiempo máximo requerido para completar una actividad, asumiendo que haya circunstancias adversas, como la presencia de complicaciones inusuales o imprevistas (pero excluyendo grandes catástrofes).

Tiempo mas Probable (tm) = la mejor estimación del tiempo requerido para completar una actividad, asumiendo que las condiciones sean normales.

Tiempo Esperado (te) = Se calcula a partir de los tres anteriores. Es la mejor estimación del tiempo requerido para completar una actividad, considerando que las condiciones no son siempre normales (esto implica que el tiempo esperado es el tiempo promedio que requeriría la actividad si se la repitiera un número de veces a lo largo de un período de tiempo).

NOTA: Se supone que cada Tarea, sigue una ley de distribución de de Euler. El valor (o tiempo) esperado en esta distribución se expresa en la siguiente fórmula:

te = (to + 4tm + tp) ÷ 6

con varianza: y desviación estándar:



Ejemplo 1:

¿Cuál es la duración esperada de una actividad que tiene los siguientes tiempos estimados? to = 5, tm = 15 y tp = 31?Rta = te = (5 + 4*15 + 31) / 6 = 16

Ejemplo 2:

Dadas las Actividades A, B, C el tiempo total esperado del proyecto puede calcularse como la suma de los tiempos esperados de cada actividad o a partir de un to, tm y tp calculados para el proyecto.

Actividad A te = (4 + 4(10) + 12 ) / 6 = 9,33 díasActividad B te = (7 + 4(15) + 21) / 6 = 14,66 días Total = 29 díasActividad C te = (2 + 4(5) + 8 ) / 6 = 5 días

Actividad to tm tpA 4 10 12B 7 15 21 te Total = (13+4(30)+41) / 6 = 29 díasC 2 5 8

Total 13 30 41

Ventajas• El diagrama PERT define explícitamente y hace visibles las dependencias (relaciones de

precedencia) entre los elementos de la EDT.• Facilita la identificación del camino crítico y lo hace visible.• Facilita la identificación de las fechas de comienzo temprano, comienzo tardío y holgura

para cada actividad.• PERT provee una reducción potencial del tiempo total del proyecto, debido a la mejor

comprensión de las dependencias, ya que pueden ejecutarse en forma concurrente las tareas independientes.

• La gran cantidad de datos de un proyecto puede ser organizada y presentada en un diagrama para ser usado en la toma de decisiones.

Desventajas• Potencialmente, pueden haber cientos o miles de actividades y relaciones de dependencia

individuales.• El PERT no es fácilmente escalable para pequeños proyectos.• Los diagramas de red tienen a ser grandes y difíciles de manejar, requiriendo impresiones

de varias páginas y papel de tamaño especial.• La falta de un marco de tiempo en la mayoría de los diagramas PERT/CPM hace difícil

mostrar el estatus aunque los colores pueden ayudar (Ej: colores específicos para nodos completos).

• Cuando los gráficos PERT/CPM se transforman en difíciles de manejar, se los deja de usar en la administración del proyecto.

Unidad 4: Planificación de recursos “El elemento fundamental en todos los proyectos de software es el personal”

El personal debe organizarse en equipos eficaces, motivados para hacer un software de alta calidad y coordinados para alcanzar una comunicación efectiva.



Personal del Proyecto: Para determinar el cronograma del proyecto y estimar el esfuerzo y los costos asociados, se necesita:

• Conocer cuánta gente estará trabajando en el proyecto.

• Saber qué tareas ejecutarán.

• Saber qué habilidades y experiencias deben tener las personas para poder realizar su trabajo lo mejor posible (eficacia).

El proceso del software (y todos los proyectos de software) lo componen participantes que pueden clasificarse en una de cinco categorías:

1. Gestores superiores: que definen los aspectos de negocios que a menudo tienen una significativa influencia en el proyecto.

2. Gestores (técnicos) del proyecto, que deben planificar, motivar, organizar y controlar a los profesionales que realizan el trabajo de software.

3. Profesionales: que proporcionan las capacidades técnicas necesarias para la ingeniería de un producto o aplicación.

4. Clientes: que especifican los requisitos para la ingeniería de software.

5. Usuarios finales: que interaccionan con el software una vez que se ha entregado para la producción.

Todos los proyectos de software están compuestos por los participantes apuntados anteriormente. Para ser eficaz, el equipo del proyecto debe organizarse de manera que maximice las habilidades y capacidades de cada persona. Ése es trabajo del jefe del equipo.

Roles del Personal y Características: Los roles apuntan a las distintas actividades del desarrollo.

Actividades claves de un proyecto: Análisis de los requerimientos, Diseño del sistema, Diseño del programa, Implementación del programa, Prueba, Entrenamiento, Mantenimiento, Aseguramiento de calidad.

• No todas las tareas son ejecutadas por la misma persona.

• Las asignaciones de tareas al personal dependen de la dimensión del proyecto, del personal mismo y de su experiencia.

• Existen ventajas en asignar responsabilidades diferentes a grupos de personas y no a solo una; una de esas ventajas es la de identificar fallas al principio del proceso.

• Una vez que se han decidido los roles de los miembros del grupo del proyecto, se debe decidir qué tipo de gente se necesita en cada rol.

Dos personas con la misma profesión serán diferentes en al menos algún aspecto, estas características pueden afectar la capacidad del individuo para desempeñarse en forma productiva. Algunas características, como el interés en el trabajo, pueden determinar el éxito o falta de él en una tarea dada. Cuando hablamos de personal asignado a un proyecto, debe tenerse en cuenta:

Capacidad para desempeñar el trabajo. Interés en el trabajo.Experiencia con sistemas similares.Experiencia con herramientas o lenguajes.Experiencia con técnicas similares.Habilidad de comunicación.Capacidad de gerenciamiento. Etc.

Lineas de comunicación del personal del proyecto.

Existen actividades que deben ser compartidas por miembros del equipo (trabajo en grupo). Para ello debe existir una fluida comunicación.



La comunicación en un proyecto es muy importante, porque el avance y éxito del proyecto depende de ella, sirve para que los integrantes del equipo manifiesten sus ideas.

Incrementar el grupo de trabajo de 2 a 3 personas multiplica el número de posibles líneas de comunicación. En general, si un proyecto tiene n trabajadores, hay n (n1)/2 = líneas de comunicación.

Ejemplo:2 (21) / 2 = 1 línea de comunicación.5 (51) / 2 = 10 líneas de comunicación.

Administración del Personal

Se refiere a los conceptos y técnicas requeridas para desempeñar adecuadamente las tareas relacionadas con el personal. Algunas de ellas son:

• Análisis de puestos (determinar la naturaleza del trabajo de cada empleado).• Planeamiento de las necesidades y candidatos a los puestos.• Selección de los candidatos a ocupar puestos.• Inducción y capacitación (la capacitación no se realiza en todos los proyectos).• Evaluación del desempeño.• Comunicación interpersonal (entrevistas, asesoría, disciplina).

Estilos de Trabajo

Las diferentes personas diferentes estilos preferidos para interactuar con otras personas y para entender los problemas que surgen en el curso de su trabajo. Existen dos componentes de estilos preferidos de trabajo:

• Forma en la cual se comunican los pensamientos y se reúnen las ideas.• Grado en que las propias emociones afectan la toma de decisiones. Dentro de la toma de

decisiones existen lo que se denomina personas extrovertidas (trasmiten el pensamiento) y personas introvertidas (piden sugerencias a los demás).

A su vez, estos dos tipos de personas pueden ser:• Intuitivas, es decir que basan sus decisiones en sentimientos y reacciones emocionales.• Racionales, que basan sus decisiones examinando los hechos y considerando todas las

opciones posibles.



Por lo tanto, se pueden definir cuatro estilos básicos:

1. Personas extrovertidas racionales Tienden a mantener sus ideas. No permiten que una intuición afecte las decisiones a tomar. Informan a los colegas lo que ellos quieren saber. Cuando razonan confían en la lógica, no en las emociones.

2. Personas introvertidas racionalesEvitan decisiones emocionales. Se toman el tiempo necesario para considerar todos los posibles cursos de acción. No se sienten seguros de tomar decisiones, a menos que estén convencidos de tener todos los hechos en la mano.

3. Personas extrovertidas intuitivasBasan sus decisiones en reacciones emocionales y tienden a querer comentar sobre estas. Son creativas utilizando su intuición. Sugieren aproximaciones no usuales para solucionar un problema.

4. Personas introvertidas intuitivasSon creativas. Aplica la creatividad solo después de haber reunido la suficiente información sobre la cual se basa una decisión.

Organización del Proyecto

¿Para qué sirve? Para que los miembros del equipo trabajen en forma combinada y organizada; así podrán obtener mejores resultados al finalizar el proyecto.

La elección de una estructura apropiada para el proyecto depende de varias cosas:• Los antecedentes y estilos de trabajo de los miembros del equipo.• El número de personas involucradas en el proyecto.• Los estilos de gestión de los clientes y desarrolladores. Etc.

Los jefes de equipo

La gestión de un proyecto es una actividad intensamente humana, y por esta razón, los competentes profesionales del software a menudo no son buenos jefes de equipo. Simplemente, no tienen la mezcla adecuada de capacidades para dirigir personas.

¿Qué es lo que se busca cuando se selecciona a alguien para dirigir un proyecto de software? Weinberg responde esta pregunta siguiendo el modelo de gestión MOI:

• Motivación: La habilidad para motivar (con un tira y afloja) al personal técnico para que produzca conforme a sus mejores capacidades.

• Organización: La habilidad para moldear procesos existentes (o inventar unos nuevos) que permita al concepto inicial transformarse en un proyecto final.

• Ideas o Innovación: La habilidad para motivar al personal para crear y sentirse creativos, incluso cuando deben trabajar dentro de los límites establecidos (por otros, además) para un producto o aplicación de software particular.

Un gestor de proyecto debería concentrarse en entender el problema que hay que resolver, gestionando el flujo de ideas y, al mismo tiempo, haciendo saber a todos los miembros del equipo (mediante palabras y hechos) que la calidad es importante y que no debe verse comprometida.

Otro punto de vista de las características que definen a un gestor de proyecto eficiente resalta cuatro apartados clave:



• Resolución del problema. Un gestor eficiente de un proyecto puede diagnosticar los aspectos técnicos y de organización más relevantes, estructurar una solución o motivar apropiadamente a otros profesionales para que desarrollen la solución. También debe aplicar las lecciones aprendidas de anteriores proyectos a las nuevas situaciones y se mantiene lo suficientemente flexible para cambiar la gestión si los intentos iniciales de resolver el problema no dan resultado.

• Dotes de gestión. Un buen gestor de proyecto debe tomar las riendas. Debe tener confianza para asumir el control cuando sea necesario y la garantía de que los buenos técnicos sigan sus instintos.

• Incentivo de los logros. Para optimizar la productividad de un equipo de proyecto, un gestor debe recompensar la iniciativa y los logros, y demostrar a través de sus acciones que no se penalizará si se corren riesgos controlados.

• Influencia y construcción de espíritu de equipo. Un gestor de proyecto eficiente debe ser capaz de “leer” a la gente; debe ser capaz de entender mensajes verbales y no verbales y reaccionar ante las necesidades de las personas que mandan esas señales. El gestor debe mantener el control en situaciones de gran estrés.

El equipo de proyecto.

Existen tantos estructuras como organizaciones que desarrollan software. Las siguientes opciones pueden aplicarse a los recursos humanos de un proyecto que requiere n personas trabajando durante k años:

1. N individuos son asignados a m diferentes tareas funcionales, tiene lugar relativamente poco trabajo conjunto; la coordinación es responsabilidad del gestor del software que puede que tenga otros seis proyectos de los que preocuparse.

2. N individuos son asignados a m diferentes tareas funcionales (m<N) de manera que se establecen “equipos” informales, se puede nombrar un líder al efecto; la coordinación entre los equipos es responsabilidad de un gestor de software.

3. N individuos se organizan en r equipos; a cada equipo se le asigna una o más tareas funcionales; cada equipo tiene una estructura específica que se define para todos los equipos que trabajan en el proyecto; la coordinación es controlada por el equipo y por el gestor del proyecto de software.

La mejor estructura de equipo depende del estilo de gestión de una organización, el número de personas que compondrá el equipo, sus niveles de preparación y la dificultad general del problema. Podemos sugerir tres organigramas de equipo genérico:

Descentralizado Democrático (DD): Este equipo de ingeniería del software no tiene un jefe permanente. Mas bien, se nombran coordinadores de tareas a corto plazo y se sustituyen por otros para diferentes tareas. Las decisiones sobre problemas y los enfoques se hacen por consenso del grupo. La comunicación entre los miembros del equipo es horizontal.

Descentralizado controlado (DC): Este equipo tiene un jefe definido que coordina tareas específicas y jefes secundarios que tienen responsabilidades en cada subtareas. La resolución de tareas sigue siendo una actividad del grupo, pero la implementación de soluciones se reparte entre subgrupos por el jefe de equipo. La comunicación entre subgrupos e individuos es horizontal. También hay comunicación vertical a lo largo de la jerarquía de control.

Centralizado Controlado (CC): El jefe del equipo se encarga de la resolución de problemas a alto nivel y la coordinación interna del equipo. La comunicación entre el jefe y los miembros del equipo es vertical.



Como una nota a pie de página, los primeros organigramas de un equipo de software eran centralizados controlados (CC), originalmente denominados equipo programador jefe (Chief Programmer Team). En esta estructura, el núcleo del equipo se compone del

• Ingeniero jefe (Jefe de programadores): quien planifica, coordina y revisa todas las actividades técnicas del equipo. Puede ser ayudado por uno o más especialistas (expertos en telecomunicaciones, diseñadores de BD, equipo de soporte) y un bibliotecario de software.

• Ingeniero de apoyo (Asistente del jefe de programadores): que ayuda al ingeniero jefe en sus actividades y puede sustituirle con una mínima perdida de continuidad del proyecto,

• Personal técnico: normalmente de dos a cinco personas, que llevan a cabo los análisis y actividades de desarrollo,

• Bibliotecario de software: Colabora con muchos equipos y realiza las siguientes funciones: mantiene y controla todos los elementos de la configuración del software (documentación, listados de fuentes, datos, soportes magnéticos), ayuda a recopilar y formatear datos de la productividad del software, cataloga e indexa módulos de software reutilizables y ayuda a los equipos en la investigación, evaluación y preparación de documentos.

También se puede encontrar, en esta estructura a dos tipos de personas mas:

• Gerente de proyectos: Encargado de buscar miembros lo suficientemente flexibles para interactuar con todos los integrantes del equipo.

• Programadores expertos: Supervisan y asignan tareas a programadores juniors. Realizan programación avanzada. Se encuentran ubicados jerárquicamente arriba de los programadores juniors.



Módulo 3: Áreas Complementarias de la Administración de Proyectos

Unidad 5: Métricas del software

MétricasLas métricas permiten entender mejor los atributos de los modelos; pero, fundamentalmente, se emplean para valorar la calidad de los productos de ingeniería o los sistemas que construimos. Además, permiten, monitorizar, controlar, predecir y probar el desarrollo de software y mantenimiento.

Las métricas persiguen tres objetivos:1. Ayudarnos a entender que ocurre durante el desarrollo y el mantenimiento.2. Permitirnos controlar que es lo que ocurre en nuestros proyectos.3. Poder mejorar nuestros procesos y nuestros productos.

La calidad del software es un acompleja mezcla de factores que variarán a través de diferentes aplicaciones y según los clientes que las pidan.

Los factores que afectan la calidad del software se pueden categorizar en dos grupos:

• Directos: factores que se pueden medir directamente, como defectos por punto de función, costo, esfuerzo humano, lineas de código, velocidad de ejecución, etc.

• Indirectas: factores que sólo se pueden medir indirectamente, como complejidad, facilidad de uso o mantenimiento, funcionalidad, eficiencia, etc.

McCall propone una categorización de factores que afectan a la calidad del software, mostrados en la figura siguiente, que se concentran en tres aspectos importantes de un producto software: sus características operativas, su capacidad de cambios y su adaptabilidad a nuevos entornos.

Corrección: hasta dónde satisface un programa su especificación y logra los objetivos del cliente.

Fiabilidad: hasta dónde se puede esperar que un programa lleve a cabo la función para la cual fue creado con la exactitud requerida.

Eficiencia: La cantidad necesaria de recursos informáticos y código para que un programa realice su función.

Integridad: hasta dónde se puede controlar el acceso al software o a los datos por personas no autorizadas.



Usabilidad (facilidad de manejo): El esfuerzo necesario para aprender a operar, preparar los datos de entrada e interpretar los resultados de un programa.

Facilidad de mantenimiento: El esfuerzo necesario para localizar y arreglar un error en un programa.

Flexibilidad: El esfuerzo necesario para modificar un programa operativo.

Facilidad de prueba: El esfuerzo necesario para probar un programa para asegurarse de que realiza su función pretendida.

Portabilidad: El esfuerzo necesario para transferir el programa de un entorno de hardware y/o software a otro.

Reusabilidad (capacidad de reutilización): Hasta dónde se puede volver a utilizar un programa (o partes de él) en otras aplicaciones, en relación al empaquetamiento y alcance de las funciones que realiza el programa.

Interoperatividad: el esfuerzo necesario para acoplar un sistema con otro.

La recopilación de datos, el calculo de métricas y la evaluación de métricas son los tres pasos que deben implementarse al comenzar el programa de métricas. Básicamente, hay dos clases de métricas de software: las métricas orientadas al tamaño, que hacen uso de la linea de código como factor estandarizado de otras medidas, como personames o cantidad de defectos y el punto de función, que proviene de las medidas del dominio de información y de una evaluación subjetiva de la complejidad del problema.

Métricas orientadas al tamaño

Las métricas de software orientadas al tamaño provienen de la normalización de las medidas de calidad y/o productividad considerando el “tamaño” del software que se haya producido. Si una organización mantiene registros sencillos, se puede crear una tabla de datos orientados al tamaño, como la que se muestra a continuación:

La tabla lista cada proyecto de desarrollo de software y las medidas correspondientes de cada proyecto. Debe tenerse en cuenta que el esfuerzo y el coste registrados en la tabla incluyen todas la actividades de ingeniería del software (análisis, diseño, codificación y prueba) y no sólo la codificación.

Para desarrollar métricas que se puedan comparar entre distintos proyectos, se seleccionan las líneas de código como valor de normalización. Con los rudimentarios datos contenidos en la tabla se pueden desarrollar, y para cada proyecto también, un conjunto de métricas simples orientadas al tamaño:

• errores por KLDC (miles de lineas de código, KiloLDC)• defectos por KLDC• $ por LDC• páginas de documentación por KLDC

Además, se pueden calcular otras métricas interesantes:• errores/personames• LDC por personames• $/página de documentación

Las métricas orientadas al tamaño no están aceptadas universalmente como el mejor modo de medir el proceso de desarrollo de software. La mayor parte de la discusión gira en torno al uso de las líneas de código como medida clave.



A favor

• La LDC es un artificio que se puede calcular fácilmente para todos los proyectos de desarrollo de software.

• Muchos modelos de estimación de software existentes usan LDC o KLDC como clave de entrada

• Ya existe un amplio conjunto de datos y de literatura basados en LDC.

En contra

• Las medidas en LDC son dependientes del lenguaje de programación.

• Perjudican a los programas más cortos, pero bien diseñados

• No pueden acomodar fácilmente lenguajes procedimentales

• Su uso en estimación requiere un nivel de detalle que puede resultar difícil de alcanzar (es decir, el planificador debe estimar las LDC a producirse mucho antes de que se complete el análisis y el diseño).

Métricas orientadas a la función

Las métricas de software orientadas a la función utilizan una medida de la funcionalidad entregada por la aplicación como valor de normalización. Ya que la “funcionalidad” no se puede medir directamente, se debe derivar indirectamente mediante otras medidas directas. Albretch fue el que las propuso a primera vez, sugiriendo una medida llamada punto de función. Los puntos de función se derivan con una relación empírica según las medidas contables directas del dominio de información del software y las evaluaciones de la complejidad del software.

Los puntos de función se computan completando la tabla de la figura siguiente:

Se determinan cinco características de dominios de información. Los valores de dominios de información se definen de la forma siguiente:

Número de entradas de usuario: Se cuenta cada entrada de usuario que proporciona diferentes datos orientados a la aplicación. Las entradas se deberían diferenciar de las peticiones, las cuales se cuentan de forma separada.

Números de salidas de usuario. Se cuenta cada entrada de usuario que proporciona al usuario información orientada a la aplicación. En este contexto la salida se refiere a informes, pantallas, mensajes de error, etc. Los elementos de datos particulares dentro de un informe no se cuentan de forma separada.



Número de peticiones de usuario. Una petición se define como una entrada interactiva que produce la generación de alguna respuesta del software inmediata en forma de salida interactiva. Se cuenta cada petición por separado.

Número de archivos: Se cuenta cada archivo maestro lógico (esto es, un grupo lógico de datos que puede ser una parte de una gran base de datos o un archivo independiente).

Número de interfaces externas. Se cuentan todas las interfaces legibles por la máquina (por ejemplo, archivos de datos de cinta o disco) que se utilizan para transmitir información a otro sistema.

Una vez que se han recopilado los datos anteriores, a la cuenta se asocia un valor de complejidad. Las organizaciones que utilizan métodos de punto de función desarrollan criterios para determinar si una entrada en particular es simple, media o compleja. No obstante, la determinación de la complejidad es algo subjetiva.

Para calcular puntos de función (PF), se utiliza la relación siguiente:

PF = cuentatotal x [0,65 + 0,01 x ∑Fi ]

en donde cuentatotal es la suma de todas las entradas obtenidas de la figura. Fi (i= 1 a 14) son valores de ajuste de la complejidad según las respuestas a una serie de preguntas, que deben ser evaluadas en una escala de 0 a 5 (0 = no influye, 1 = incidental, 2 = moderado, 3 = medio, 4 = significativo, 5 = esencial). Las preguntas son:

Una vez que se han calculado los puntos de función, se utilizan de forma análoga a las LDC para normalizar medidas de productividad, calidad y otros ámbitos del software:

• errores por PF• defectos por PF• $ por PF• página de documentación por PF• PF por personames



Estimación de un proyecto de softwareHoy en día, el software es el elemento más caro en la mayoría de los sistemas informáticos, por lo que un gran error en la estimación del costo puede ser la diferencia entre pérdidas y ganancias. Comprender cual sera el costo probable, es un aspecto crucial en la planificación y gestión de un proyecto. Sobrepasarse en el costo puede ser desastroso para el equipo de desarrollo.

El presupuesto de un proyecto incluye los costos de instalación, personal, métodos y herramientas, costos ocultos, y costos de adquisición de software y de herramientas para dar soporte a los esfuerzos de desarrollo.Determinar cuantos díaspersonas se requerirán para el proyecto es el componente de costo con mayor grado de incertidumbre. Además, la estimación del proyecto debe hacerse repetidamente durante el ciclo de vida, refinándola ante cambios en el proyecto.

La estimación del coste y del esfuerzo del software nunca será una ciencia exacta, porque son demasiadas las variables humanas, políticas, técnicas, de entorno que pueden afectar el coste final.

Para realizar estimaciones seguras de costes y esfuerzos tenemos varias opciones posibles:

1. Dejar la estimación para mas adelante.Aunque atractiva, no es una opción práctica. Las estimaciones de costes han de ser proporcionadas a priori. Sin embargo, hay que reconocer que cuanto más tiempo esperemos, más cosas sabremos, y cuanto más sepamos, menor será la probabilidad de cometer serios errores.

2. Basar las estimaciones en proyectos similares ya terminados.Esta opción puede funcionar razonablemente bien si el proyecto actual es bastante similar a los esfuerzos pasados y si otras influencias del proyecto (por ejemplo, el cliente, las condiciones de gestión, el EIS, las fechas límites) son similares. Desafortunadamente, la experiencia anterior no ha sido siempre un buen indicador de futuros resultados.

3. Utilizar técnicas de descomposición

Estas técnicas son relativamente sencillas y permiten generar las estimaciones de coste y de esfuerzo del proyecto. Las técnicas de descomposición utilizan un enfoque de “divide y vencerás” para la estimación de proyectos de software. Mediante la descomposición del proyecto en sus funciones principales y en las tareas de ingeniería correspondientes, la estimación del coste y del esfuerzo puede realizarse de una forma escalonada idónea.

4. Desarrollar un modelo empírico para el cálculo de costes y esfuerzos del software.Los modelos empíricos de estimación pueden usarse como complemento de las técnicas de descomposición, ofreciendo un enfoque de estimación potencialmente valioso por derecho propio. Cada modelos se basa en la experiencia (datos históricos) y toma como base: d=f(vi) donde d es uno de los valores estimados (esfuerzo, coste, duración del proyecto) y los vi son determinados parámetros independientes (por ejemplo, LDC o PF estimados)

Esta opción solo será buena si los datos históricos son buenos. Si no es así, la estimación del coste descansará sobre una base muy inestable.

Métodos de estimación basados en Juicio experto

Se basan en la experiencia de los gerentes en proyectos similares. Por ello se sustenta en la experiencia, objetividad, competencia y percepción del estimador.

Los modelos que se basan en el juicio experto, dependen de la habilidad de los expertos para determinar cuáles proyectos son similares y en qué forma.

• Un método consiste en solicitar a varios expertos que hagan tres predicciones: pesimista (x), optimista (y) y mas probable (z), luego la estimación del esfuerzo surge de: (x+4y+z)/6.



• Técnica Delphi

Con la técnica Delphi, cada experto hace una predicción individual en forma secreta, basada en sus experiencias y utilizando el proceso que desee. El promedio estimado se calcula y se presenta al grupo. Cada experto tiene la posibilidad de revisar su estimación si lo desea. El proceso se repite hasta que no haya expertos que deseen una revisión.

Este método es una técnica de comunicación estructurada, originalmente desarrollada como un método interactivo y sistemático de pronósticos, que se basa en un panel de expertos. Estos expertos hacen una predicción individual y secreta, en dos o más vueltas. Después de cada vuelta, un facilitador provee un resumen de las predicciones de los expertos y de las razones que aportaron para su juicio. Se fomenta que cada experto revise su respuesta anterior a la luz de las respuestas de los otros miembros del panel. Se cree que, durante este proceso, el rango de las respuestas se irá achicando y el grupo “convergerá” hacia la respuesta correcta. Finalmente, el proceso se detiene cuando se alcanza un criterio predefinido (número de vueltas, se alcanzó el consenso, estabilidad de los resultados) y la media o la mediana de la vuelta final determina los resultados.

Delphi está basado en el principio de que las predicciones (o decisiones) de un grupo estructurado de individuos son más exactas que aquellas de grupos no estructurados. El método Delphi ha sido ampliamente usado para predicciones de negocios y tiene cierta ventaja sobre otro enfoque de predicción estructurado llamado Mercados de Predicción.

Modelos Empíricos de Estimación

Estructura de los modelos de estimación (métodos algorítmicos)

Se describen utilizando ecuaciones, donde el esfuerzo es la variable dependiente, y factores como la experiencia, dimensión y tipo de sistema son las variables independientes.

Un modelo común de estimación se extrae utilizando el análisis de regresión sobre los datos recopilados de proyectos de software anteriores. La estructura global de tales modelos adquiere la forma de:

E=AB∗ev c

donde A, B y C son constantes obtenidas empíricamente, E es el esfuerzo en meses/persona, y ev es la variable de estimación (de LDC o PF). Además, la mayoría de los modelos de estimación tienen algún componente de ajuste del proyecto que permite ajustar E por otras características del proyecto (complejidad del problema, experiencia del personal, entorno de desarrollo).

Entre los muchos modelos de estimación orientados a LDC propuestos en la bibliografía se encuentran los siguientes:

E=5,2∗KLDC 0,91 Modelo de WalstonFelix

E=5,50,73∗KLDC 1,16 Modelo de BaileyBasisli

E=3,2∗KLDC 1,05 Modelo simple de Boehm

También se han propuesto los modelos orientados a PF. Entre estos modelos se incluyen:

E=−13,390,054∗PF Modelo de Albretch y Gaffney

E=60,62∗7,728∗10−8∗PF 3 Modelo de Kemerer

E=585,715,12∗PF Modelo de Matson, Barnett y Mellichamp

Un rápido listado de los modelos listados anteriormente indica que cada uno producirá un resultados diferente para el mismo valor de LDC y PF. Esta diferencia se fundamenta en que estos modelos a menudo se derivan de poblaciones relativamente pequeñas de proyectos. La implicación es clara: los modelos de estimación se deben calibrar para las necesidades locales.



Una de las ecuaciones mas utilizada es E=ab∗Sc ∗m∗ X donde

S es la dimensión estimada del sistema.

a, b y c son constantes.

X es un vector de factores de costo

m es un multiplicador de ajuste basado en estos factores.

Modelo COCOMOBarry Boehm, en su libro sobre economía de la ingeniería del software, introduce una jerarquía de modelos de estimación de software con el nombre de COCOMO, por COnstructive COst MOdel (Modelo Constructivo de Coste). La jerarquía de modelos de Boehm está constituida por los siguientes:

Modelo I El modelo COCOMO básico calcula el esfuerzo (y el coste) del desarrollo del software en función del tamaño del programa, expresado en las líneas estimadas de código (LDC).

Modelo II El modelo COCOMO intermedio calcula el esfuerzo del desarrollo de software en función del tamaño del programa y de un conjunto de “conductores de costo”que incluyen la evaluación subjetiva del producto, del hardware, del personal y de los atributos del proyecto.

Modelo III El modelo COCOMO avanzado incorpora todas las características de la versión intermedia y lleva a cabo una evaluación del impacto de los conductores de coste en cada fase (análisis, diseño, etc.) del proceso de ingeniería de software.

Los modelos COCOMO están definidos para tres tipos de proyectos de software. Utilizando la terminología de Boehm son:

1. Modo orgánico: proyectos de software relativamente pequeños y sencillos en los que trabajan pequeños equipos, con buena experiencia en la aplicación, sobre un conjunto de requisitos poco rígidos (por ejemplo, un programa de análisis termal desarrollado para un grupo calórico);

2. Modo semiacoplado: proyectos de software intermedios (en tamaño y complejidad) en los que equipos, con variados niveles de experiencia, deben satisfacer requisitos poco o medio rígidos (por ejemplo, un sistema de procesamiento de transacciones con requisitos fijos para un hardware de terminal o un software de gestión de BD);

3. Modo empotrado: proyectos de software que deben ser desarrollados en un conjunto de hardware, software y restricciones operativas muy restringido (por ejemplo, software de control de navegación para un avión)

Modelo COCOMO II

Boehm actualizó el modelo COCOMO II. Este modelo refleja tres estadios principales de cualquier proyecto de desarrollo:

Estadio I Composición de la aplicaciónEstima las dimensiones sobre la base de lo que sus creadores denominan puntos de aplicación.

Estadio II Diseño temprano Emplea puntos de función con medidas del tamaño.

Estadio III Post arquitectura El dimensionamiento puede ser hecho en términos de los puntos de función o lineas de código.



El modelo básico de COCOMO II es de la forma E=bS∗m X , dondebS: estimación inicial basada en el tamaño.m(X): vector de información de conductores de costo.

Estadio I – Composición de la Aplicación

Los puntos de aplicación suministran la medida del tamaño. Para calcular los puntos de aplicación:

1. Primero se debe contar el numero de pantallas, informes y componentes de lenguaje de tercera generación que están involucrados en la aplicación.

2. Se clasifica cada elemento de la aplicación en simple, medio y difícil.

3. Se pondera la complejidad de cada elemento

4. Se deben sumar los informes y pantallas ponderados para obtener un único numero de puntos de aplicación. Si r % de los objetos se reutiliza de proyectos previos, el número de nuevos puntos de aplicación se calculará:

Nuevos puntos de aplicación = (puntos de aplicación) * (100 r) / 100).

5. Para utilizar este numero para la estimación del esfuerzo, se usa un factor de ajuste, denominado grado de productividad. La productividad se obtiene de la tabla:

Cálculo de la productividad estimada

Experiencia y capacidad de los desarrolladores

Muy Baja Baja Nominal Alta Muy alta

Madurez y capacidad con CASE

Muy Baja Baja Nominal Alta Muy alta

Factor de Productividad

4 7 13 25 50


Niveles de complejidad para puntos de aplicaciónPara Pantallas Para Reportes

Número y fuentes de las tablas de datos Número y fuentes de las tablas de datos

<3 Simple Simple Medio 0 o 1 Simple Simple Medio3-7 Simple Medio Difícil 2 o 3 Simple Medio Difícil8+ Medio Difícil Difícil 4+ Medio Difícil Difícil

Numero de vistas

contenidas

Número de secciones contenidas

Total < 4 (<2 servidores, <3 clientes)

Total < 8 (2-3 servidores, 3-5 clientes)

Total 8+ (>3 servidores, >5 clientes)

Total <4 (<2 servidores, <3 clientes)

Total <8 (2-3 servidores, 3-5 clientes)

Total 8+ (>3 servidores, >5 clientes)

Pesos de la complejidad para puntos de aplicaciónElemento a considerar

TipoComplejidad

Simple Media Compleja

Pantalla 1 2 3Informe 2 5 8

-- – 10Componente de 3GL


Estadio II (Diseño temprano) y III (Post arquitectura)

En el Estadio II la estimación del esfuerzo, que está basada en puntos de función, se ajusta por el grado de reutilización, los cambios en los requerimientos y el mantenimiento. La escala para el Estadio II varia, dependiendo del grado de innovación del sistema, conveniencia, arquitectura temprana, resolución del riesgo, cohesión del equipo y madurez del proceso.

Los indicadores de costos en los Estadios II y III son factores de ajuste expresados como multiplicadores del esfuerzo, y su clasificación varia entre extra bajo y extra alto.

En el Estadio III el conjunto de indicadores de costo es mayor, lo que indica una mayor comprensión de los parámetros del proyecto.

Conclusiones

Si un sistema esta en los estudios preliminares de lo que hará el software, se puede utilizar el modelo de esfuerzo inicial de COCOMO II para sugerir el numero de mespersona necesario. El modelo COCOMO II supone que el numero de mespersona no incluye feriados y vacaciones de fin de semana. El primer estadio de COCOMO II, Composición del Sistema, esta diseñado para ser utilizado en etapas mas tempranas del desarrollo. A medida que se comprende mas acerca de los requerimientos, se puede utilizar otras partes de COCOMO: el modelo temprano y el modelo de post arquitectura.

Modelo Putnam (SLIM)

El Modelo Putnam, también conocido como SLIM (Software LIfecycle Management, suite de herramientas que lo implementa), es una técnica de estimación de costes para proyectos de software, desarrollada por Lawrence H. Putnam en 1978. Fue una técnica pionera y ha sido, junto con COCOMO, la que más repercusión ha tenido en el mundo de la ingeniería del software. Está basado en la curva de Rayleigh, y describe la necesidad de personal al desarrollar proyectos complejos.

Putnam desarrollo un modelo de estimaciones del esfuerzo total y del tiempo de finalización para proyectos muy grandes a través de ecuaciones basadas en algoritmos; estas ecuaciones básicas pueden ajustarse para pequeños proyectos. La utilización básica es la de estimar tiempo y esfuerzo al comienzo de un nuevo proyecto de software, a través de proyectos anteriores.

Mientras trabajaba en proyectos para la Armada, Putnam notó que las necesidades de personal seguían la bien conocida distribución de Rayleigh.

Distribución de Rayleigh

En la teoría de la probabilidad y estadística, la distribución de Rayleigh es una función de distribución continua. Se suele presentar cuando un vector bidimensional (por ejemplo, el que representa la velocidad del viento) tiene sus dos componentes, ortogonales, independientes y siguen una distribución normal. Su valor absoluto seguirá entonces una distribución de Rayleigh.

Putnam usó sus observaciones sobre los niveles de productividad para derivar la ecuación del software:

donde:

• Tamaño es el tamaño del producto (cualquier tamaño estimado que use la organización es apropiado). Putnam usa ESLOC (Effective Source Lines of Code).

• B es un factor escalar y es una función del tamaño del proyecto.

• Productividad es la Productividad del Proceso, la habilidad de una organización de software


B1 /3 .TamañoProductividad

=Esfuerzo1/3 .Tiempo4 /3


en particular de producir software de un tamaño dado a una particular tasa.

• Esfuerzo es el esfuerzo total aplicado al proyecto en añospersona.

• Tiempo es el total del Plan del proyecto, en años.

En la práctica, cuando se hace una estimación para una tarea de software, la ecuación se resuelve para obtener el Esfuerzo, despejando:

Graficando el Esfuerzo como función del Tiempo, se obtiene la Curva TiempoEsfuerzo. Los puntos a lo largo de la curva representan el esfuerzo total estimado para completar el proyecto en algún momento. Una de las características del modelo de Putnam es que el esfuerzo total decrece a medida que el tiempo para completar el proyecto se extiende. Esto se representa, normalmente, en otros modelos paramétricos con un parámetro de relajación de horario.

Este método es bastante sensible a la incertidumbre, tanto en el tamaño como en la productividad del proceso. Putnam aboga por obtener la productividad del proceso por calibración.

Una de las ventajas de este método es la simplicidad con la cual es calibrado. La mayoría de las organizaciones de software, sin importar su nivel de madurez, puede fácilmente recoger tamaño, esfuerzo y duración (tiempo) de los proyectos anteriores. La Productividad del Proceso, aunque es exponencial por naturaleza, típicamente es convertida a un índice de productividad lineal, que una organización puede usar para seguir sus propias variaciones en productividad y aplicarlas en futuras estimaciones de esfuerzo.

El modelo de estimación de Putnam es un modelo multivariable dinámico que asume una distribución específica del esfuerzo a lo largo de la vida de un proyecto de desarrollo de software. La distribución del esfuerzo en grandes proyectos de software puede ser caracterizada como muestra la siguiente figura. Las curvas de la figura toman una forma descrita analíticamente por Lord Rayleigh. Para desarrollar las curvas se han utilizado los datos empíricos de desarrollos de sistemas recopilados por Norden. Por todo ello, la distribución de esfuerzo que se muestra en la figura se denomina a menudo Curva de RayleighNorden.


Esfuerzo=[ TamañoProductividad.Tiempo4 /3 ]

3

. B


Funciones del modelo• Calibración, apoyándose en datos históricos de proyectos pasados.• Construcción de un modelo de información, juntando todas las características del sistema,

atributos personales y de la computadora.• Tamaño del software. SLIM utiliza una versión automatizada de LOC.

Ventajas• No depende de una gran base de datos histórica.• Usa programación lineal para considerar las restricciones en el desarrollo, tanto del costo

como del esfuerzo.• Utiliza menos parámetros para estimar un costo que el modelo COCOMO.• Es relativamente rápido y fácil de usar.

Desventajas• Las estimaciones son extremadamente sensitivas al factor tecnológico.• No es apropiado para proyectos pequeños.

Método de la máquina que aprende

Se utilizan redes neuronales para representar las actividades interconectadas involucradas en la generación de un producto de software. Cada unidad de la red tiene, mediante software, una suma ponderada de sus entradas: si la suma excede un valor determinado, la unidad produce una salida. La salida es la entrada para otras unidades relacionadas.

Técnica para producir la salida

Se suministran a la red datos de proyectos pasados, y esta utiliza algoritmos de propagación (hacia adelante y hacia atrás) para aprender, identificando patrones en los datos.La salida, entonces, viene dada por tres funciones:

1. Una función de propagación (también conocida como función de excitación), que por lo general consiste en la sumatoria de cada entrada multiplicada por el peso de su interconexión (valor neto). Si el peso es positivo, la conexión se denomina excitatoria; si es negativo, se denomina inhibitoria.



2. Una función de activación, que modifica a la anterior. Puede no existir, siendo en este caso la salida la misma función de propagación.

3. Una función de transferencia, que se aplica al valor devuelto por la función de activación. Se utiliza para acotar la salida y generalmente viene dada por la interpretación que queramos darle a dichas salidas.

Técnica CBR

El razonamiento basado en casos (CBR), es el proceso de resolver nuevos problemas basándose en las soluciones de problemas similares que hayan ocurrido en el pasado. El razonamiento basado en casos es una prominente fábrica de analogías.

Se ha argumentado que no es solo un método poderoso para el razonamiento de computadoras, sino una conducta generalizada en la resolución de problemas diarios; o mas radicalmente, que todo el razonamiento se basa en casos pasados que experimentamos. Este enfoque se relaciona con la teoría de prototipos, que se explora en profundidad en la ciencia del conocimiento.

El razonamiento basado en casos ha sido formalizado, para propósitos de razonamiento de computadoras, como un proceso de cuatro pasos:

1. Recuperar: Dado un problema, recuperar de la memoria casos relevantes para resolverlo. Un caso consiste de un problema, su solución y, típicamente, aclaraciones o explicaciones sobre cómo se llegó a esa solución.

2. Reusar: Aplicar la solución del caso previo al problema que se está tratando de resolver. Esto puede implicar adaptar la solución como sea necesario para que calce en la nueva situación.

3. Revisar: habiendo aplicado la solución previa a la situación, testear la nueva solución en el mundo real o en una simulación y, si es necesario, revisarla.

4. Retener: Luego de que la solución ha sido adaptada exitosamente al problema, guardar la experiencia resultante como un nuevo caso en memoria.

El razonamiento basado en casos es una técnica de maquina que aprende. Con CBR se construye un algoritmo con una combinación de posibles entradas que podrían presentarse en un proyecto.

Los cuatro pasos del sistema basado en CBR serían:

1. El usuario identifica un problema nuevo como un caso.

1. El sistema recupera casos similares de un repositorio de información histórica.



2. El sistema reutiliza conocimientos de casos previos.

3. El sistema sugiere una solución para el nuevo caso.

Modelo adecuado de estimación• Las relaciones entre los factores de costo no son simples, y los modelos deben ser lo

suficientemente flexibles para manejar cambios en el uso de herramientas y métodos.

• Aun cuando los modelos de estimación producen estimaciones razonablemente exactas, se debe tener la capacidad para comprender cuáles son los tipos de esfuerzo que se necesitan durante el desarrollo.

• Es importante registrar no sólo cuanto esfuerzo se gasta en un proyecto, sino también quién lo está haciendo y para qué actividad.

• Hay dos estadísticas que a menudo se utilizan para ayudar a determinar la eficiencia de un modelo:

◦ PRED (x / 100) es el porcentaje de proyectos para los cuales la estimación está dentro de x % del valor verdadero.

◦ MMRE es la magnitud media del error relativo.

Herramientas Automáticas de Estimación

Las técnicas de descomposición y los modelos empíricos de estimación descritos anteriormente se pueden implementar con software. Las herramientas automáticas de estimación permiten al planificador estimar costes y esfuerzos, así como llevar a cabo análisis del tipo "qué pasa si" con importantes variables del proyecto, tales como la fecha de entrega o la selección de personal. Aunque existen muchas herramientas automáticas de estimación, todas exhiben las mismas características generales y todas requieren una o más de las siguientes clases de datos:

1. Una estimación cuantitativa del tamaño del proyecto (por ejemplo. en LDC) o de la funcionalidad (datos sobre puntos de función).

2. Características cualitativas del proyecto, tales como la complejidad, la fiabilidad requerida o el grado crítico del negocio.

3. Alguna descripción del personal de desarrollo y/o del entorno de desarrollo.

A partir de estos datos, el modelo implementado por la herramienta automática de estimación proporciona estimaciones del esfuerzo requerido para llevar a cabo el proyecto, de los costes, de la carga de personal y, en algunos casos, de la agenda de desarrollo y del riesgo asociado.



Unidad 6 – Gestión del Riesgo Algunas definiciones de Gestión de Riesgo según Auditoría Informática

• Amenaza: personas o cosas vistas como posible fuente de peligro o catástrofe.

• Vulnerabilidad: La situación creada, por falta de uno o varios controles, con la que la amenaza pudiera acaecer y así afectar al entorno informático.

• Riesgo : la probabilidad de que una amenaza llegue a acaecer por una vulnerabilidad.

Riesgo: cualquier situación donde hay incertidumbre acerca de los resultados que pueden arrojar diferentes actividades, ya sea por naturaleza propia de la actividad, o por eventos ajenos a ella.

Según Drucker, “Mientras que es inútil intentar eliminar el riesgo y cuestionable el poder minimizarlo, es esencial que los riesgos que se tomen sean los riesgos adecuados”. Antes de poder identificar los “riesgos adecuados” que se pueden tomar en un proyecto de software, es importante poder identificar todos los riesgos que sean obvios a jefes de proyectos y profesionales del software.

La gestión del riesgo es una tarea de los gerentes de una empresa, para comprender y controlar los riesgos en sus proyectos.

Estrategias de riesgo proactivas y reactivas

Las estrategias de riesgo reactivas se denominan, a menudo, “de bomberos”. No se preocupan de los problemas hasta que ocurren, y entonces se reacciona de alguna manera heroica. En el mejor de los casos, la estrategia reactiva supervisa el proyecto en previsión de posibles riesgos.

Una estrategia mas inteligente para el control del riesgo es ser proactivo. La estrategia proactiva empieza mucho antes de que comiencen los trabajos técnicos: Se identifican los riesgos potenciales, se valoran su probabilidad y su impacto, y se establece una prioridad según su importancia. Después, el equipo de software establece un plan para controlar el riesgo. El primer objetivo es evitar el riesgo, pero como no se pueden evitar todos los riesgos, el equipo trabaja para desarrollar un plan de contingencias que le permita responder de una manera eficaz y controlada.

Riesgos del software

Aunque ha habido debates sobre la definición adecuada para riesgo de software, hay acuerdo en que el riesgo siempre implica dos características:

• Incertidumbre: el acontecimiento que caracteriza al riesgo puede o no puede ocurrir; por ejemplo no hay riesgos de un 100% de probabilidad (un riesgo del 100% es una limitación del proyecto de software)

• Pérdida: si el riesgo se convierte en una realidad, ocurrirán consecuencias no deseadas o pérdidas.

Cuando se analizan los riesgos es importante cuantificar el nivel de incertidumbre y el grado de pérdidas asociado con cada riesgo. Para hacerlo, se consideran diferentes categorías de riesgos.

Categorías del riesgo:

• Riesgos del Proyecto

Amenazan al plan del proyecto. Es decir, si se hacen realidad, es probable que la planificación temporal del proyecto se retrase y que los costos aumenten. Los riesgos del proyecto identifican los problemas potenciales de presupuesto, planificación temporal, personal (asignación y organización), recursos, clientes y requisitos, y su impacto en un proyecto de software.



• Riesgos Técnicos

Amenazan la calidad y la planificación temporal del software que hay que producir. Si un riesgo técnico se convierte en realidad, la implementación puede llegar a ser difícil o imposible. Los riesgos técnicos identifican problemas potenciales de diseño, implementación, de interfaz, verificación y de mantenimiento. Además, las ambigüedades de especificaciones, incertidumbre técnica, técnicas anticuadas y las “tecnologías de punta” son también factores de riesgo. Los riesgos técnicos ocurren porque el problema es más difícil de resolver de lo que pensábamos.

• Riesgos del Negocio

Amenazan la viabilidad del software a construir. Los riesgos del negocio a menudo ponen en peligro el proyecto o el producto. Los cinco principales riesgos del negocio, son:

1. Construir un producto o sistema excelente que en realidad no quiere nadie (Riesgos del Mercado

2. Construir un producto que no encaja en la estrategia comercial general de la compañía (Riesgo estratégico)

3. Construir un producto que el departamento de ventas no sabe cómo vender.

4. Perder el apoyo de una gestión experta debido a cambios de enfoque o a cambios de personal (Riesgo de dirección)

5. Perder presupuesto o personal asignado (Riesgos de presupuesto)

Identificación del riesgo

La identificación del riesgo es un intento sistemático para especificar las amenazas al plan del proyecto (estimaciones, planificación temporal, carga de recursos, etc.). Identificando los riesgos conocidos y predecibles, el gestor del proyecto puede evitarlos cuando sea posible y controlarlos cuando sea necesario.

Existen dos tipos de riesgos para cada categoría de riesgo, y son

• Riesgos genéricos: Son una amenaza potencial para todos los proyectos de software.

• Riesgos específicos: sólo pueden ser identificados por aquellos que tienen una clara visión de la tecnología, el personal y el entorno especifico del proyecto en cuestión. Para identificar los riesgos específicos de producto se examinan el plan del proyecto y la declaración del ámbito del software, y se desarrolla una respuesta a la siguiente pregunta: ¿Qué características especiales de este producto pueden estar amenazadas por nuestro plan del proyecto?

Tanto los riesgos genéricos como los específicos del producto se deberían identificar sistemáticamente. Un método para identificar riesgos es crear una lista de comprobación de elementos de riesgo, que se enfoque en un subconjunto de riesgos conocidos y predecibles en las siguientes subcategorías genéricas:

1. Tamaño del productoRiesgos asociados con el tamaño general del software a construir o a modificar. En general, el riesgo del proyecto es directamente proporcional al tamaño del producto.

2. Impacto en el negocioRiesgos asociados con las limitaciones impuestas por la gestión o por el mercado. Por ejemplo, cuando la fechas límites del proyecto las establece el departamento de marketing, que está guiado por las consideraciones del negocio.

3. Características del clienteRiesgos asociados con la sofisticación del cliente y la habilidad del desarrollador para comunicarse con el cliente en los momentos oportunos.

No todos los clientes fueron creados igual:



◦ Tienen diferentes necesidades: algunos saben lo que quieren, y otros lo que no quieren.

◦ Los clientes tienen diferentes personalidades: Algunos disfrutan siendo clientes (la tensión, la negociación), otros preferirían no ser clientes en absoluto.

◦ Los clientes también tienen varios tipos de asociaciones con sus suministradores: Algunos conocen bien a sus proveedores y sus productos, otros sólo se comunican por teléfono.

◦ Los clientes se contradicen a menudo. Quieren todo para ayer y gratis. A menudo, el producto se ve cogido entre las propias contraindicaciones del cliente.

Un “mal” cliente puede tener un profundo impacto en la habilidad del equipo de software para completar el proyecto a tiempo y dentro del presupuesto. Un mal cliente representa una amenaza significativa al plan del proyecto y un sustancial riesgo para el jefe del proyecto.

4. Definición del procesoRiesgos asociados con el grado de definición del proceso del software y su seguimiento por la organización de desarrollo.

Si el proceso de software no está bien definido; si el análisis, diseño y pruebas se realizan sobre la marcha; si la calidad es un concepto que todo el mundo estima importante pero por la que nadie actúa de manera tangible para alcanzarla, entonces el proyecto está en peligro.

5. Entorno de desarrolloRiesgos asociados con la disponibilidad y calidad de las herramientas que se van a emplear en la construcción del producto.

Las herramientas inapropiadas o ineficaces pueden estropear los esfuerzos de incluso un experimentado profesional. El entorno de ingeniería de software soporta al equipo del proyecto, al proceso y al producto. Pero si el entorno es malo, puede ser una fuente de riesgos significativa.

6. Tecnología a construirRiesgos asociados con la complejidad del sistema a construir y la tecnología punta que contiene el sistema.

Alcanzar los límites de la tecnología es un reto excitante. Es el sueño de casi todos los técnicos, porque fuerza al profesional a emplear su talento al máximo. Pero también es muy arriesgado.

7. Tamaño y experiencia de la plantillaRiesgos asociados con la experiencia técnica y de proyectos de los ingenieros del software que van a realizar el trabajo.

Componentes y controladores del riesgo

Las Fuerzas Aéreas de Estados Unidos han redactado un documento con directrices para identificar riesgos de software y evitarlos. Según este enfoque, el gestor del proyecto debe identificar los controladores de riesgo que afectan a los componentes de riesgo de software (rendimiento, coste, soporte y planificación temporal). En el contexto de este estudio, los componentes de riesgo se definen de la siguiente manera:

• Riesgo de rendimiento: el grado de incertidumbre con el que el producto encontrará sus requisitos y se adecue para su empleo pretendido.

• Riesgo de coste: el grado de incertidumbre que mantendrá el presupuesto del proyecto.

• Riesgo de soporte: el grado de incertidumbre de la facilidad del software para corregirse, adaptarse y ser mejorado.

• Riesgo de planificación temporal: el grado de incertidumbre con que se podrá mantener la planificación temporal y de que el producto se entregue a tiempo.



El impacto de cada controlador de riesgo en el componente de riesgo se divide en cuatro categorías de impacto despreciable, marginal, crítico y catastrófico.

La tabla siguiente indica las consecuencias potenciales de errores (filas etiquetadas con 1) o la imposibilidad de conseguir el producto deseado (filas etiquetadas con 2). La categoría de impacto es elegida basándose en la caracterización que mejor encaja con la descripción de la tabla.

Tabla: Evaluación del Impacto

Componentes

Categoría

Rendimiento Soporte Coste Planificación Temporal

Catastrófico 1 Dejar de cumplir los requisitos provocaría el fracaso de la misión

Malos resultados en un aumento de costes y retrasos de la planificación temporal con cifras que superan los $500K.

2 Degradación significativa para no alcanzar el rendimiento técnico.

El software no responde o no admite soporte.

Recortes financieros significativos, presupuestos excedidos

Fecha de entrega inalcanzable

Crítica 1 Dejar de cumplir los requisitos degradaría el rendimiento del sistema hasta un punto donde el éxito de la misión es cuestionable.

Malos resultados en retrasos operativos y/o aumento de coste con valor esperado de $100K a $500K.

2 Alguna reducción en el rendimiento técnico

Pequeños retrasos en modificaciones de software

Algunos recortes de recursos financieros, posibles excesos del presupuesto

Posibles retrasos de la fecha de entrega

Marginal 1 Dejar de cumplir los requisitos provocaría la degradación de la misión secundaria

Los costes, impactos y/o retrasos recuperables de la planificación temporal con un valor estimado de $1K a $100K

2 De mínima a pequeña reducción en el rendimiento técnico

El soporte del software responde

Recursos financieros suficientes

Planificacióntemporal realista, alcanzable

Despreciable 1 Dejar de cumplir los requisitos provocaría inconvenientes o impactos no operativos

Los errores provocan impactos mínimos en el coste y/o planificación temporal con un valor esperado de menos de $1K

2 No hay reducción en el rendimiento técnico

Software fácil de dar soporte

Posible superávit de presupuesto

Fecha de entrega fácilmente alcanzable

Etapas del Proceso de identificación del riesgo

1. Identificación: ¿qué está bajo riesgo?¿que puede ir mal?¿cual es su probabilidad?

2. Evaluación: cuantificación de efectos y prioridad de los riesgos.

3. Selección de estrategias

1. Acciones Financieras: asumir (recuperar la capacidad operativa) y transferir (delegar la responsabilidad).

2. Acciones Físicas: prevenir (tomar medidas preventivas) y proteger.

4. Implementación: implementación de las estrategias.

5. Seguimiento: evaluación e identificación de peligros continuos.

Proyección del riesgoLa proyección del riesgo, también denominada estimación del riesgo, intenta medir cada riesgo de dos maneras: la probabilidad de que el riesgo sea real y las consecuencias de los problemas asociados con el



riesgo, si ocurriera. El jefe del proyecto, junto con otros gestores y personal técnico, realiza cuatro actividades de proyección del riesgo:

1. Establecer una escala que refleje la probabilidad percibida del riesgo2. Definir las consecuencias del riesgo3. Estimar el impacto del riesgo en el proyecto y en el producto4. Apuntar la exactitud general de la proyección del riesgo de manera que no haya confusiones

Desarrollo de una Tabla del riesgo1. Se empieza por listar todos los riesgos en la primera columna de la tabla.2. Se categoriza cada riesgo.3. Se calcula la probabilidad de aparición de cada riesgo. 4. Se valora el impacto de cada riesgo

Luego, la tabla es ordenada por probabilidad y por impacto. Los riesgos de alta probabilidad y de alto impacto pasan a lo alto de la tabla, y los riesgos de baja probabilidad caen a la parte de abajo.

Riesgos Categoría Probabilidad Impacto RSGR

La estimación del tamaño puede ser significativamente baja

PS 60% 2

Los usuarios finales se resisten al sistema

BU 40% 3

Personal sin experiencia ST 60% 2

Valores de impacto:

1. Catastrófico2. Critica3. Marginal4. Despreciable

Categorías:

PS= implica un riesgo del tamaño del proyectoBU= Implica un riesgo de negocioST= implica un riesgo Técnico (referido al personal)

RSGR:

Plan de reducción, supervisión y gestión del riesgo

Evaluación del impacto del riesgo

Tres factores afectan a las consecuencias probables de un riesgo, si ocurre: su naturaleza, su alcance y cuando ocurre.

• La naturaleza del riesgo indica los problemas probables que aparecerán si ocurre. Por ejemplo, una interfaz externa mal definida para el hardware del cliente (un riesgo técnico) impedirá un diseño y pruebas tempranas y probablemente lleve a problemas de integración más adelante en el proyecto.

• El alcance de un riesgo combina la severidad (¿cómo de serio es un problema?) con su distribución general (¿qué proporción del proyecto se verá afectado y cuántos clientes se verán perjudicados?).

• Finalmente, la temporización de un riesgo considera cuándo y por cuánto tiempo se dejará sentir el impacto. En la mayoría de los casos, un jefe de proyecto prefiere las “malas noticias” cuanto antes, pero en algunos casos, cuanto más tarden, mejor.

Se recomiendan los siguientes pasos para determinar las consecuencias generales del riesgo:

1. Determinar la probabilidad media de que ocurra un valor para cada componente de riesgo.

2. Determinar el impacto de cada componente basándose en los criterios mostrados en la tabla “Evaluación del impacto”.



3. Completar la tabla de riesgo y analizar los resultados como se describe en las secciones precedentes.

Reducción, Supervisión y Gestión del Riesgo (RSGR)

Todas las actividades de análisis de riesgo presentadas hasta ahora tienen un solo objetivo: ayudar al equipo del proyecto a desarrollar una estrategia para tratar los riesgos. Una estrategia eficaz debe considerar tres aspectos:

1. Evitar el riesgo.2. Supervisar el riesgo.3. Gestión del riesgo y planes de contingencia.

Si un equipo de software adopta un enfoque proactivo frente al riesgo, evitarlo (1) es siempre la mejor estrategia. Esto se consigue desarrollando un plan de reducción del riesgo. A medida que progresa el proyecto, comienzan las actividades de supervisión del riesgo (2). El jefe de proyecto supervisa factores que pueden proporcionar una indicación de si el riesgo se está haciendo más o menos probable, y además debería supervisar la efectividad de los pasos de reducción del riesgo.

La gestión del riesgo y los planes de contingencia (3) asumen que los esfuerzos de reducción han fracasado y que el riesgo se ha convertido en una realidad.

Es importante advertir que los pasos RSGR provocan aumentos del coste del proyecto. Parte de la gestión de riesgos es evaluar cuando los beneficios obtenidos superan los costes asociados con su implementación. En esencia, quien planifique el proyecto realiza el clásico análisis de coste/beneficio.

En general, para un proyecto grande se pueden identificar 30 o 40 riesgos, con lo cual la gestión del riesgo se transforma en un proyecto en sí misma. Para evitar esto, se aplica la regla de Pareto 8020 al riesgo del software: la experiencia dice que el 80% del riesgo total de un proyecto se debe solamente al 20% de los riesgos identificados. El trabajo realizado durante procesos de análisis de riesgo anteriores ayudará al jefe de proyecto a determinar qué riesgos pertenecen a ese 20%.

Esquema del plan RSGR

I. Introducción 1. Alcance y propósito del documento

2. Visión general de los riesgos principales

3. Responsabilidades a. Gestión

b. Personal técnico

II. Tabla del riesgo del proyecto 1. Descripción de todos los riesgos

2. Factores que influyen en la probabilidad e impacto

III. Reducción, supervisión y gestión del riesgo

a. Reducción 1. Estrategia general2. Pasos específicos

b. Supervisión 1. Factores a supervisar2. Enfoque de la supervisión

c. Gestión 1. Plan de contingencias2. Consideraciones especiales

IV. Planificación temporal de revisión del Plan RSGR

V. Resumen

Conclusiones

El tiempo invertido identificando, analizando y gestionando el riesgo merece la pena por muchas razones, es decir, menos trastornos durante el proyecto, una mayor habilidad de seguir y controlar el proyecto y la confianza que da planificar los problemas antes de que ocurran.



Unidad 7: Seguimiento y control del proyecto Seguimiento y control de proyectos

La planificación temporal del proyecto le proporciona al gestor un “mapa de carreteras”. Si se ha desarrollado apropiadamente, define las tareas e hitos que deben seguirse y controlarse a medida que progresa el proyecto. El seguimiento se puede hacer de diferentes maneras:

• Realizando reuniones periódicas del estado del proyecto en las que todos los miembros del equipo informan del progreso y de los problemas.

• Evaluando los resultados de todas las revisiones realizadas a lo largo del proceso de ingeniería del software.

• Determinando si se han conseguido los hitos formales del proyecto en la fecha programada.

• Comparando la fecha real de inicio con las previstas para cada tarea del proyecto listada en la tabla del proyecto.

• Reuniéndose informalmente con los profesionales del software para obtener sus valoraciones subjetivas del progreso hasta la fecha y los problemas que se avecinan.

En realidad, todas estas técnicas de seguimiento las utilizan los gestores de proyecto experimentados. El control lo usa el gestor para administrar los recursos del proyecto, enfrentarse a los problemas y dirigir al personal del proyecto. Si las cosas van bien, el control es liviano. Pero cuando aparecen los problemas, el gestor debe ejercer el control para solucionarlos tan pronto como sea posible.

El seguimiento alerta al jefe del proyecto de dificultades potenciales, para que se pueda tomar la adecuada acción correctiva. El control depende de la información provista por los miembros del equipo, si es incorrecta el sistema no funcionara.

Componentes de un sistema de control.

• Acción: actividad asignada a un recurso determinado según diagrama de red.

• Información: los resultados de la acción generan información sobre efectividad.

• Feedback: proceso por el cual los miembros del equipo informan al jefe del proyecto del estado de sus actividades.

• Acción correctiva: según la información recibida, el jefe del proyecto puede tomar acciones correctivas.

• Rediseño: cuando existe un cambio en el producto final o cambian las actividades necesarias. Exige una nueva iteración del diagrama de red.

• Re programación: significa colocar nuevas fechas para las actividades y posiblemente para el proyecto.

• Re localización: colocar nuevos recursos en una actividad.

Garantía (Aseguramiento) de la Calidad del software

Se han propuesto muchas definiciones de calidad del software. Según Pressman, la calidad del software se define como:

Concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente documentados, y con las características implícitas que se espera de todo software desarrollado profesionalmente.

No hay duda de que la definición propuesta puede ser modificada o ampliada. De hecho, una discusión sobre una definición formal de calidad del software sería interminable. De todas formas, esta definición sirve para hacer hincapié en tres puntos importantes:



1. Los requisitos del software son la base de las medidas de la calidad. La falta de concordancia con los requisitos es una falta de calidad.

2. Los estándares especificados definen un conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del software. Si no se siguen esos criterios,casi siempre habrá falta de calidad.

3. Existe un conjunto de requisitos implícitos que a menudo no se mencionan (por ejemplo, el deseo de un buen mantenimiento). Si el software se ajusta a sus requisitos explícitos pero falla en alcanzar los requisitos implícitos, la calidad del software queda en entredicho.

Revisiones del software

Las revisiones del software son un “filtro” para el proceso de ingeniería de software. Se aplican en varios momentos del desarrollo del software y sirven para detectar defectos que puedan así ser eliminados, sirven para “purificar” las actividades de ingeniería del software que suceden como resultado del análisis, el diseño y la codificación.

Una revisión cualquier revisión es una forma de aprovechar la diversidad de un grupo de personas para:

1. señalar la necesidad de mejoras en el producto de una sola persona o equipo;

2. confirmar las partes de un producto en las que no es necesario o no es deseable una mejora;

3. conseguir un trabajo técnico de una calidad mas uniforme, o al menos mas predecible que la que puede ser conseguida sin revisiones, con el fin de hacer más manejable el trabajo técnico.

Existen muchos tipos diferentes de revisiones que se pueden llevar adelante como parte de la ingeniería del software. Cada una tiene su lugar.

• Una reunión informal alrededor de la máquina de café es una forma de revisión, si se discuten problemas técnicos.

• Una presentación formal de un diseño de software a una audiencia de clientes, ejecutivos y personal técnico es una forma de revisión.

• La revisión técnica formal (RTF), a veces denominada inspección, es el filtro mas efectivo desde el punto de vista de garantía de la calidad.

Revisiones Técnicas Formales

Una Revisión Técnica Formal (RTF) es una actividad de garantía de calidad del software que es llevada a cabo por ingenieros del software. Los objetivos de la RTF son:

1. Descubrir errores en la función, la lógica o la implementación de cualquier representación del software.

2. Verificar que el software bajo revisión alcanza sus requisitos.3. Garantizar que el software ha sido representado de acuerdo con ciertos estándares predefinidos.4. Conseguir un software desarrollado de forma uniforme.5. Hacer que los proyectos sean más manejables.

Además, la RTF sirve como campo de entrenamiento, permitiendo que los ingenieros más jóvenes puedan observar los diferentes enfoques de análisis, diseño e implementación del software. También sirve para promover la seguridad y la continuidad, ya que varias personas se familiarizarán con partes del software que, de otro modo, no hubieran visto nunca.

La RTF es realmente una clase de revisión que incluye recorridos, inspecciones, torneos de revisiones y otras tareas de revisión técnica del software. Cada RTF se lleva a cabo mediante una reunión y sólo tendrá éxito si es bien planificada, controlada y atendida.



La reunión de revisión

Independientemente del formato que se elija para la RTF, cualquier reunión de revisión debe acogerse a las siguientes restricciones:

• Deben convocarse, normalmente, entre tres y cinco personas

• Se debe preparar por adelantado, pero sin que requiera más de dos horas de trabajo a cada persona, y

• La duración de la reunión de revisión debe ser menor de dos horas.

Cada RTF se centra en una parte específica (y pequeña) del software total, de esta manera la probabilidad de encontrar errores es mayor.

La reunión es llevada a cabo por el jefe de revisión, los revisores y el productor, la persona que desarrolló el producto. Uno de los revisores toma el papel de registrador, es decir el que registra todo lo que pasa en la reunión. La RTF comienza con una explicación de la agenda, y una breve introducción por parte del productor. Entonces, éste explica el material, mientras los revisores exponen sus problemas basándose en su preparación previa; cuando se descubren problemas o errores válidos, el registrador los va anotando.

Al final de la revisión, todos los participantes en la RTF deben decidir si:

1. Aceptan el producto sin posteriores modificaciones

2. Rechazan el producto debido a los serios errores encontrados (una vez corregidos, debe hacerse otra revisión.

3. Aceptan el producto provisionalmente (se han encontrado errores menores que deben ser corregidos, pero sin necesidad de otra posterior revisión.

Una vez tomada la decisión, todos los participantes terminan firmando, indicando así que han participado en la revisión y que están de acuerdo con las conclusiones del equipo de revisión.

Registro e informe de la revisión

Al final de la reunión de revisión, se resumen todos los problemas y errores y se genera una lista de sucesos de revisión. Además, el registrador prepara un informe sumario de revisión, en el cual se responden tres preguntas:

1. ¿Qué fue revisado?2. ¿Quien lo reviso?3. ¿Qué se descubrió y cuales son las conclusiones?

El informe sumario de revisión es una página simple que se adjunta al registro histórico del proyecto y puede ser enviada al jefe del proyecto y partes interesadas.

La lista de sucesos de revisión sirve para identificar áreas problemáticas dentro del producto y servir como lista de comprobación de puntos de acción que guíe al productor para hacer las correcciones. Normalmente se adjunta una lista de conclusiones al informe sumario.

Directrices para la revisión

Se deben establecer de antemano las directrices para conducir las RTF, consensuarlas y seguirlas, porque una revisión incontrolada puede ser peor que no hacer ninguna. Un conjunto mínimo de directrices para las revisiones técnicas formales:

1. Revisar al producto y no al productor: debe evitarse que tome un aura de inquisición.

2. Fijar una agenda y mantenerla: debe seguirse un plan de trabajo concreto, y no divagar.

3. Limitar el debate y las impugnaciones.

4. Enunciar áreas de problemas, pero no intentar resolver cualquier problema que se ponga de manifiesto. La resolución de los problemas debe ser pospuesta para después de la revisión.



5. Tomar notas escritas.

6. Limitar el numero de participantes e insistir en la preparación anticipada. Se ha de mantener el número de participantes en el mínimo necesario, y el jefe de revisión debe solicitar comentarios que muestren que cada revisor ha revisado el material.

7. Desarrollar una lista de comprobación para cada producto que haya de ser revisado.

8. Disponer recursos y una agenda para las RTF. Deben planificarse para que sean efectivas, y se debe trazar un plan para las modificaciones que surjan como resultado de ellas.

9. Llevar a acabo un buen entrenamiento de todos los revisores.

10. Repasar las revisiones anteriores.

Gestión de configuración del software

Cuando se construye software, los cambios son inevitables. Y es inevitable que aumenten la confusión entre los desarrolladores, principalmente cuando no se han analizado antes de realizarlos, no se han registrado antes de implementarlos, no se les han comunicado a los que necesitan saberlo, o no se han controlado de manera que mejoren la calidad y reduzcan los errores. Según Babich,

El arte de coordinar el desarrollo de software para minimizar... la confusión, se denomina gestión de configuración. La gestión de configuración es el ate de identificar, organizar y controlar las modificaciones que sufre el software que construye un equipo de programación. La meta es maximizar la productividad minimizando los errores.

La Gestión de Configuración del Software (GCS) es una actividad de autoprotección que se aplica a lo largo de todo el proceso de ingeniería de software. Como el cambio se puede producir en cualquier momento, las actividades de GCS sirven para (1) identificar el cambio, (2) controlar el cambio, (3) garantizar que el cambio se implementa adecuadamente y (4) informar el cambio a todos aquellos a los que les interese.

La GCS identifica, controla, audita e informa de las modificaciones que invariablemente se dan al desarrollar el software una vez que ha sido distribuido a los clientes. Cualquier información producida como parte del proceso de ingeniería de software se convierte en parte de una configuración del software. La configuración se organiza de tal forma que sea posible un control organizado de los cambios.

Es importante distinguir claramente entre el mantenimiento del software y la gestión de configuración del software. El mantenimiento es un conjunto de actividades de ingeniería del software que se producen después de que el software se haya entregado al cliente y esté en funcionamiento. La gestión de configuración del software es un conjunto de actividades de seguimiento y control que comienzan cuando se inicia el proyecto y termina sólo una vez que el software queda fuera de circulación.

Una vez que se ha desarrollado y revisado un objeto de configuración se convierte en una línea base. Los cambios sobre un objeto de línea base llevan a la creación de una nueva versión del objeto. El control de versiones es un conjunto de procedimientos y herramientas que se usan para gestionar el uso de los objetos.

El control de cambios es una actividad procedimental que asegura la calidad y la consistencia a medida que se realizan cambios en los objetos de la configuración.



GlosarioActividad: Una actividad es una tarea o evento que contribuye al logro de las metas de un proyecto; es su “ladrillo más pequeño”. Una actividad normalmente es un tipo de acción aplicada a una fase o porción del proyecto, que involucra aproximadamente los mismos recursos a lo largo de la misma.

Tarea: Ver Actividad.

Tarea nocrítica: Una tarea que no está en el camino crítico.

Fecha temprana de comienzo (Ftc): La fecha más temprana en que puede comenzar una tarea, de acuerdo a las dependencias de sus predecesoras y sucesoras y cualquier otra restricción.

Fecha temprana de fin (Ftf): La fecha posible más temprana en que una tarea puede terminar si empieza en su fecha temprana de comienzo. Estas se calculan por el Método del Camino Crítico.

Camino crítico: La sucesión de tareas interrelacionadas en un proyecto que toma el tiempo más largo para completarlo. El camino crítico define la duración del proyecto y su fecha de finalización.

Dependencia: La relación entre una tarea y sus predecesoras y sucesoras.

Sucesora: Tarea que depende directamente de la tarea actual.

Predecesora: Una tarea de la que depende directamente la tarea actual.

Relación: Determina el orden y la secuencia de las tareas del proyecto.

Márgenes: La cantidad de tiempo en el cronograma que una tarea puede demorarse o extenderse sin afectar tareas subsecuentes o la fecha de finalización del proyecto. Todas las tareas nocríticas tienen márgenes.

ALAP (As later as possible): “Tan tarde como sea posible” es un método de planificación en que se fijan las tareas hacia atrás de la fecha del fin, para que cada tarea empiece la fecha más tarde posible en el cronograma del proyecto.

ASAP (As soon as possible): “Lo más pronto posible” es un método de planificación en que se fijan las tareas de la fecha de comienzo para que cada tarea empiece en la fecha posible más temprana en el cronograma del proyecto.

CORBA (Common Object Request Broker Architecture): Arquitectura de software de componentes propuesta por el OMG (Object Management Group)

Costo: Indica cuánto costará terminar el proyecto.

Costo de instalación: Incluye hardware, espacio, mobiliario, teléfonos, módems, calefacción y aire acondicionado, cables, discos, papeles, lápices, fotocopiadoras y todos los otros elementos que forman parte del ambiente físico en el cual los desarrolladores trabajarán.

Estimación de costos: Estimación del costo de los recursos necesarios para cumplimentar las actividades del proyecto.

Presupuestación de costos: Asignar estimaciones de costo a componentes individuales de un proyecto.

Esfuerzo: La cantidad de trabajo que un recurso realizará cuando es asignado a una tarea; por ejemplo: 8h/d.



Estructura de descomposición del trabajo: Una descomposición multinivel del esfuerzo del proyecto en agrupaciones lógicas y manejables. El nivel más alto se refiere al proyecto entero, el segundo nivel descompone el proyecto en sus mayores subproyectos, y el tercer nivel define los entregables para cada subproyecto, usando una estructura orientada al producto que se identifica con el documento de alcance. Los niveles más bajos identifican las actividades y tareas que se requieren para producir cada entregable, basado en la metodología apropiada. El nivel más bajo de un proyecto WBS identifica unidades de trabajo que se asignan a los miembros del equipo del proyecto.

Medición: Permite que gestores y profesionales mejoren el proceso del proyecto; ayuda en la planificación seguimiento, y control de un proyecto de software y evalúa la calidad del producto (software) que se produce.

Punto de función: Proviene de las medidas del dominio de información y de una evaluación subjetiva de la complejidad del problema.

Métrica: Herramienta para la predicción para la planificación. Estimación del tamaño y costo del proyecto.

Métricas del proceso: Permiten que una organización tome una visión estratégica, proporcionando mayor profundidad de la efectividad de un proceso de software.

Métricas del proyecto: Son tácticas que permiten que un gestor de proyectos adapte el enfoque a los flujos de trabajo del proyecto y a proyectos técnicos en tiempo real.

Métricas orientadas a la función: Utilizan una medida de la funcionalidad entregada por la aplicación como valor de normalización.

Métricas orientadas al tamaño: Provienen de la normalización de las medidas de calidad y/o productividad considerando el “tamaño” del software que se haya producido. Hacen uso de la línea de código como factor estandarizador de otras medidas, como persona mes o defectos.

Modelo de Objeto de Componentes (COM), ActiveX: La arquitectura de software de componente de Microsoft que permite a los componentes de software proporcionados por las compañías del software diferentes interactuar de una manera confiable. El COM es una colección de servicios que permiten que los componentes del software actúen recíprocamente en un ambiente de redes. El COM abarca ActiveX®, y otras tecnologías. Los comandos de ActiveX son una manera de empaquetar los componentes del COM para el uso en las aplicaciones y navegadores de Web que usan el COM.

Personas

Clientes: Especifican los requerimientos para la ingeniería de software.

Gestores (técnicos) del proyecto: Deben planificar, motivar, organizar y controlar a los profesionales que realizan el trabaja de software.

Gestores superiores: Definen los aspectos de negocios que a menudo tienen una significativa influencia en el proyecto.

Profesionales: Proporcionan las capacidades técnicas necesarias para la ingeniería de un proyecto o aplicación.

Usuarios finales: Los que interaccionan con el software una vez que se ha entregado para la producción.

Equipo de trabajo: Gente que se reporta directa o indirectamente al Director de Proyectos.

Personas extrovertidas intuitivas: Son aquellas que basan muchas decisiones en reacciones emocionales y tienden a querer comentar a los demás sobre éstas, más que a pedir opiniones. Usan su intuición para ser creativas y a menudo sugieren aproximaciones no usuales para solucionar un problema.



Personas extrovertidas racionales: Tienden a mantener sus ideas y no permitir que una intuición afecte las decisiones a tomar. Cuando razonan, confían en la lógica, no en la emoción.

Personas introvertidas intuitivas: Son creativas, pero aplican la creatividad sólo después de haber reunido suficiente información sobre la cual se basa una decisión.

Personas introvertidas racionales: También evitan decisiones emocionales, pero están dispuestas a tomarse tiempo para considerar todos los posibles cursos de acción. Son acopiadoras de información: no se sienten seguras de tomar una decisión a menos que estén convencidas de tener todos los hechos a la mano.

Proyecto: Trabajo singular con fechas definidas de inicio y finalización, una especificación clara del objetivo o alcance de la tarea, un presupuesto preestablecido y una organización temporal que se desmantela cuando termina el proyecto.

Proyecto informático: Conjunto de tareas interdependientes, cuyo propósito es la realización de un producto de software que automatice un conjunto bien definido de requerimientos de unos usuarios, atendiendo a uno o más procesos de negocio.

Plan de proyecto: Documento para comunicar a los clientes el análisis del riesgo, el cronograma y la organización.

Ciclo de vida del proyecto: Conjunto de fases del proyecto generalmente secuenciales, cuyo nombre y cantidad se determinan de acuerdo a las necesidades de control de la organización u organizaciones involucradas en el proyecto.

Fases del proyecto: Un conjunto de actividades del proyecto relacionadas lógicamente; usualmente finalizan con la terminación de los mayores entregables.

Tiempo: Indica cuánto tiempo se requerirá para terminar el proyecto.

Calendario: Mediante este se especifican las fechas de trabajo, las horas extraordinarias y de notrabajo y tiempos que se aplican al proyecto, tareas, recursos y asignaciones de recurso.

Cronograma del proyecto: Las fechas planeadas para la realización de actividades y el cumplimiento de hitos.

Método del Camino Crítico (CPM): Método de programación de proyectos basado en definir y manejar el camino crítico.

Alcance: Es el trabajo implicado en la ejecución del proyecto.

Diagrama de Gantt: Diagrama que representa el avance respecto al tiempo, a menudo usado en la planificación y control del proyecto.

PERT: Una sigla para la Técnica de Evaluación y Revisión del Programa. La planificación PERT se usa normalmente para la evaluación de la performance, no para el progreso diario e informes de estado.

Hito: Un identificador que marca alguna fecha importante, como el principio o fin del proyecto, o los puntos de la revisión mayores.

Línea base: Una instantánea de datos del proyecto que se puede guardar en cualquier momento; típicamente se realiza en forma coincidente con el cumplimiento de hitos específicos a lo largo de la vida del cronograma del proyecto.

Nivelación de recursos: Adaptación de un recurso cuya disponibilidad se puede modificar para adecuarlo a los requerimientos de todas las tareas y proyectos en que el recurso ha sido asignado.



Riesgo: Un evento no deseado que tiene consecuencias negativas.

Riesgos específicos: Son amenazas que resultan de las vulnerabilidades particulares de un proyecto dado. Por ejemplo: un vendedor puede prometer un software de red para una fecha particular, pero hay algún riesgo de que ese software no esté listo a tiempo.

Riesgos genéricos: Son aquellos comunes a todos los proyectos de software, tales como entender mal los requerimientos, perder personal clave o dejar tiempo insuficiente para las pruebas.

Probabilidad de riesgo: La probabilidad del riesgo medida desde 0 (imposible) hasta 1 (certeza). Cuando la probabilidad de riesgo es 1, entonces el riesgo se denomina problema, dado que hay certeza de que suceda.

Impacto del riesgo: Pérdida asociada a un riesgo.

Control de riesgo: Involucra un conjunto de acciones tomadas para reducir o eliminar un riesgo.


pcp - resumen

Documents