Z41 GPI II AO1 Gonzalez Fredy

Asignatura: Gestión de Proyectos Informáticos IIProfesora: Salomón, AliciaAlumno: González, FredyGrupo: Z41Actividad Obligatoria 1

Cuestionario:

1-Qué es un proyecto? Cuáles son las Características de un proyecto? Cuál es la diferencia entre un proyecto y un proceso?

1.1. Un proyecto es una empresa única e irrepetible que se pone en marcha para alcanzar un resultado deseado en un límite de tiempo y dentro de un presupuesto de costo. Incluye todos los esfuerzos técnicos y administrativos requeridos para que el cliente obtenga un producto que satisfaga los términos del convenio del proyecto. El proyecto debe ajustarse al programa al presupuesto y a los criterios de calidad. Para lograrlo los esfuerzos deben ser planeados, iniciados monitoreados y controlados.

1.2. Según la definición anterior, si se la desglosa obtenemos algunas de las características, y también se agregan otras:

1.2.1. Unicidad: el producto de un proyecto ya sea un bien material, un servicio o una situación deseada es único, ya sea porque nunca antes se había realizado, como por ejemplo la construcción de un nuevo producto, o porque requieren actividades especiales y particulares para lograr el objetivo, como es el caso de una construcción, de organizar un fiesta, etc.

1.2.2. Temporalidad: un proyecto tiene un marco de tiempo específico, limitado, con una fecha de inicio y otra de finalización, para lograr el objetivo.

Fredy González- Z41 Page 1

1.2.3. Incertidumbre: un proyecto implica cierto grado de incertidumbre, y es una consecuencia de los puntos anteriores.

1.2.4. Tiene un disparador: lo que lleva a realizar un proyecto puede ser:

Aprovechar una oportunidad Solucionar un problemas Satisfacer una necesidad

Un proyecto de software en un sus características generales es un proyecto más, que tiene características comunes generales a todos, y un proyecto de software hereda aquellas características particulares mencionadas aquí más otras particulares de la ingeniería de software:

1.2.5. Ciclo de vida: se le llama a las etapas del software para su desarrollo que en general serían:

La investigación preliminar Estudio de Factibilidad Aprobación Requerimientos Análisis del Sistemas Diseño del Sistemas Programación Implementación Mantenimiento

1.3. La diferencia entre entre un proyecto y un procesos operativo lleva a creer que en ciertas ocasiones se está realizando un proyecto cuando en realidad se está desarrollando unproceso. En muchas organizaciones la única manera de conseguir recursos adicionales es a través de proyectos. Con los años ese dinero es utilizado en trabajos normales de rutina, y se continúa año a año, pidiendo ese dinero manejando el trabajo como proyecto cuando ya no lo es más.


Hay dos maneras en que el trabajo puede llevarse a cabo, medianteprocesos o mediante proyectos, podríamos decir que todo lo nuevo o lo mejorado que ocurre es un proyecto, y todas las operaciones rutinarias requieren de procesos de trabajo.

Un proyecto es un esfuerzo temporal que produce un producto, un entregable o un servicio, únicos. Debido a que un proyecto es temporal se debe realizar conjuntando un equipo que constituye y ejecuta un plan. A finalizarlo el equipo se desintegra y regresa a sus miembros a sus lugares de origen. Si el equipo sigue trabajando y el proyecto parece empezar de temporada en temporada, probablemente la primera vez fue un proyecto que el equipo operacionalizó, y al cual se le relegaron las responsabilidades de repetirlo de manera recurrente y repetitiva pero ahora están trabajando en un proceso.

Un proceso es un esfuerzo que se puede catalogar como permanente en el sentido de que produce un entregable o un producto repetitivo (aunque puede tener pequeños cambios y la manera de manejarlos debería ser un proceso o parte del mismo). Cada vez que se realiza el proceso se obtiene más o menos el mismo producto, o output. Como el proceso es permanente hay personas asignadas a realizarlo que hacen básicamente el mismo conjunto detareas y trabajos cada vez que el proceso se lleva a cabo.

Ambos son un conjunto interrelacionado de actividades que van transformando insumos en productos o entregables (agregándoles valor). Los proyectos, en ese conjunto de actividades interrelacionadas y dependientes entre ellas, contienen actividades distintas, diferentes, únicas, que probablemente nunca se hayan realizado antes en la organización y que no se asemejan a lo que antes se ha hecho. Los procesos u operaciones son un conjunto de actividades, también interrelacionadas y dependientes que ya se han hecho de manera similar por lo menos una vez antes en la organización.

Ambos, los procesos y los proyectos requieren de administrarse, pero solo sabiendo la diferencia entre ellos se puede elegir las


técnicas y herramientas administrativas necesarias para llevarlosa cabo.

Los proyectos requieren de administración de proyectos, pero los procesos requieren de administración de procesos

Utilizar administración de proyectos para administrar la operación de toda una organización es altamente ineficiente. Si se supone, como ejemplo, que cada vez que una empresa de entregasque va a transportar un paquete, reuniera a un equipo de proyectopara realizar un plan y ejecutar y monitorear las actividades delenvío. No es dable, el ¿por qué? , porque ya se saben los requerimientos del cliente y se saben las tareas que se necesitanrealizar para hacerlo, aunque el destino sea distinto cada vez, el peso del paquete, etc. Se tienen un costo y un calendario parael proceso y es parte del presupuesto anual (de operaciones) y del ejercicio de planeación anual (que también es un proceso, no se empieza de cero y aunque el plan sea distinto, la manera de hacer el plan es también un proceso). Se tienen personas que realizan los trabajos de ese proceso. No se necesita administración de proyectos.

Administrar una organización como si todo fuera un proyecto es ungran error, aún en empresas proyectizadas, ya que estas también contienen operaciones. Mientras más proyectos y procesos se puedan hacer repetitivos, recurrentes y predecibles, mejor. Mientras menos riesgo y más eficiencia mejor. A estos se le aplica la administración de procesos. Sin embargo, no todos los procesos pueden convertirse en procesos de trabajo.

El desarrollo de nuevos productos o desarrollo de software son proyectos.

2- Es necesario dividir en fases a un proyecto? Por qué?

Las organizaciones dividen los proyectos de software en fases, y las mismas se relacionan entre sí. El conjunto de estas fases se denomina “Ciclo de Vida del Proyecto”. Y sirve para definir las fases que


conectan el inicio de un proyecto con su fin, a los efectos de generarun sistema de software con sus planificaciones y partes en general conectadas entre sí desde el principio, generándose el “esqueleto” delsistema, para luego irle completando en un proceso iterativo incremental basado en ese esqueleto llamado Arquitectura, si bien hay diferentes paradigmas o maneras de alcanzar este tipo de objetivos, actualmente este es uno de los más usados y el recomendado en Análisisde Sistemas de la carrera que estamos haciendo.La idea de las fases utilizan en cierta forma el concepto “Divide y reinarás”, y se agrega estudia y genera a cada árbol, pero sin perderde vista el bosque desde el principio al final, como un sistema en su totalidad.

Las fases facilitan definir:

Qué trabajo técnico se debe realizar en cada fase. Cuándo se deben entregar los productos entregables en cada fase y

cómo se revisa, verifica y valida cada producto entregable. Quien o quienes esta/n involucrados en cada fase. Cómo controlar y aprobar cada fase. Permiten saber la secuencia de los trabajos, de esa manera es

menos probable el tener recursos subutilizados, o faltantes, sinprevisión, durante el ciclo de vida.

La conclusión o aprobación de uno o más productos entregables, pues estos se deben caracterizar en cada fase.

Facilitan la medición temprana, pues un producto entregable es algo que se puede medir y verificar, tal como una especificación,un informe del estudio de viabilidad, un documento de diseño detallado, o un prototipo de trabajo.

Permiten una mejor visión del avance y de todo el proyecto en general pues, toman el nombre de lo que las forma, ya sea requisitos, diseño, construcción, prueba, puesta en marcha, entreotros según corresponda.

No hay que atarse a un determinado número de fases ya que en general pueden ser cinco fases pero habrá proyectos que puedan requerir aún más, porque muy pocos ciclos de vida son idénticos, además cada fase puede contener subfases.


3-Realice un cuadro comparativo de los diferentes modelos de proceso, identificando factores de comparación relevantes. En el material didáctico del aula virtual de la unidad correspondiente al proceso de desarrollo, seleccione el que realiza los gráficos comparativos entre modelos de procesos y explíquelos.

Modelo del Ciclo Problema

Cascada Cascada con mejora iterativa

Incremental Prototipo rápido desechable

Prototipo evolutivo

Definición Es el enfoquemetodológico que ordena rigurosamentelas etapas del ciclo de vida del sw, de tal forma que el iniciode cada etapadebe esperar a la finalización de la inmediatamente anterior.

Es un procesode desarrollode sw creado en respuesta a las debilidades del modelo tradicional de cascada. El modelo consta de diversas etapas de desarrollo encada incremento. Las cuales inician con el análisis yfinalizan conla instauración y aprobación del sistema.

Este modelo se basa en realizar entregas de sw operativo frecuentes a los clientes.Es de tipo evolutivo queestá basado en varios ciclos cascada

Es un tipo deprototipo evolutivo

Este tipo de desarrollo escrear prototipos demanera rápidae iterativa.

Se basa en laidea de desarrollar una implementación inicial exponiéndola a los comentarios del usuario yrefinándola através de las diferentes versiones hasta que se desarrolla sistema adecuado.Este modelo comienza por desarrollar los aspectos visibles del sistema, se presenta el prototipo al cliente, se logra el acuerdo con el mismo y continúa el desarrollo.


Existen dos tipo de desarrollo evolutivo: 1-Prototipos desechables, ya mencionados aquí. 2- Desarrollo exploratorio:donde el objetivo del proceso es trabajar con el cliente para explorarsus requerimientos y entregar un sistema final.

Comprensión Es relativamentefácil de comprender pues utiliza una secuenciaordenada de pasos en la cual se realiza una revisión al finalizar cada etapa para determinar sise pasa a la siguiente.

En el contexto de iteraciones múltiples si bien conllevaventajas en el uso de mediciones, las medidas aveces son difíciles de comprender enlo absoluto

Los prototipos permiten ver al usuario como el sistema apoyará a su trabajo.Permiten adquirir nuevas ideas para los requerimientos, y encontrar áreas fuertesy débiles en el sw. A medida que sedesarrollan revelan errores y omisiones en


los requerimientos propuestos

Volatilidad Se tiene definición estable del producto sw

Este modelo que es una parte esencial de un tipo de programación llamada “Extreme Programming”,se usa generalmente cuando los usuarios nunca saben bien que es lo que se necesita parasatisfacer sus necesidades (similar al prototipo evolutivo), por lo tanto en el desarrollo los procesos tienden a cambiar.

La volatilidad es media-baja, ya que si bien promedialmente tendrá cambios en elsistema después del chequeo del usuario-cliente, si está correctamenterealizada la arquitectura completa del sistema sw, cada incremento tiene su propio ciclo de vida, y sebasa en el anterior sin cambiar su funcionalidadni sus interfaces.

Este modelo es estable, pues al tenerprototipos desde las etapas tempranas delproyecto, loscambios incrementalesestán bien acotados y estabilizadosen forma lineal.

El modelo de Desarrollo exploratorio,en contraposición con el prototipo rápido desechable esmuy volátil, pues no es posible definir con claridad los requerimientos ya que estemodelo es conveniente usarlo en esos casos, por lo tanto existe poco acuerdo con los usuarios habiendo reiterados cambios.

Complejidad Cuando aparecen errores u omisiones lavuelta atrás es posible pero complicada derealizar debido a que se debe

La mayoría delos incrementos se harán en base a las necesidades de los usuarios. Pero en realidad ya son

Las dificultades son similaresa la de los modelos iterativos, requieren de mucha planeación tanto, y de metas claras

Son de alta complejidad, aunque los costos se venincrementadosen las etapasiniciales se reducen en la etapas posteriores del proceso


cambiar muchas cosas para lograrla

estipulados de antes de la entrega del proyecto.Sin embargo hay que ver cómo se maneja el producto paraver si necesita otros cambiosademás de losestipulados antes de la entrega del proyecto. Este problemano se ve con frecuencia yaque la mayoría de las veces losincrementos estipulados suplen satisfactoriamente los cambios que quiere el usuario. Se necesita una colaboración ética y mutuaentre desarrolladory usuario, a veces el usuario no está dispuesto a dedicar su tiempo a colaborar conla iteración

para conocer el estado delproyecto.

de desarrollo, ya que los clientes piden menos cambios en elsistema. Un problema general con los prototipos desechables ejecutables es que el modo de utilizarlos puede no corresponder con el modo en que se utiliza el sistema final. El probador del prototipo puede no ser el usuario típico de éste. El tiempo de evaluación del prototipopuede ser insuficiente


del proyecto.Sufre fuertespenalizaciones en los cuales los requerimientos están previamente definidos o para proyectos quese deben entregar ya terminados (licitacionespor ejemplo).

Experiencia en dominio

Tiene mucha experiencia en dominio yaque es una delas metodologías más tradicionales

Fue creado enrespuesta al modelo tradicional de cascada.

Este modelo apareció en los años 80 (Arlan Mills), por lo tanto se podría decir que la experiencia promedio de los desarrolladores en el dominio es media-alta

Es la aparición de nueva tecnología desw la que posibilita aprovechar parte del prototipo desarrollado,y de paso analizarlo rápidamente

En este aspecto se aplica el mismo concepto que para el anterior modelo de prototipo, siendo aquel una parte de este.

Capacidad técnica

Es bueno cuando se tiene una definición estable del producto y elproyecto de análisis es relativamentepequeño. Tiene varias desventajas. Es

Con este cambio respecto al modelo cascada puro,tiene gran capacidad técnica y es de los más utilizados enlos últimos tiempos, ya que se

Al realizar entregas frecuentes lacomunicación es más efectiva , sereduce el riesgo dividiendo elproyecto en una serie de subproyectos más pequeños

Se logra que los usuarios puedan experimentar con el prototipo en las primeras etapas del proceso de sw, con costos controlados.Se puede

Es útil cuando no es posible definir con claridad los requerimientos debido a que cambian reiteradamente o no existeacuerdo con los usuarios.Es muy útil


desaconsejable cuando se necesita un rápido desarrollo. Dificulta cuando se quiere expresar claramente los requisitos alcomienzo del proyecto, porlo cual generalmente se debe volver atrás.Genera pocos signos visibles de progreso hasta el final. Los usuarios no pueden ir viendo el avance real del proyecto,recién cuandoestá terminado pueden ver elproyecto funcionando, lo cual puedegenerar a esaaltura disconformidades muy difíciles de corregir.

relaciona connovedosas estrategias de desarrollode sw, y una programación extrema, siendo empleado en metodologías diversas. Los pasos claves en el proceso son comenzar con una implementación simple de los requerimientos del sistemae iterativamente mejorar la secuencia evolutiva deversiones hasta que el sistema completo esteimplementado.En cada iteración se realizan cambios en eldiseño y se agregan nuevas funcionalidades y capacidades al sistema.En este modelo los usuarios no

aumentando lavisibilidad del progreso,proporcionando módulos terminados y operativos deun sistema grande antes de tener operativo el sistema completo. Se tiene mayor capacidad para hacer modificaciones a mitad delcamino, porque el sistema está listo para ser entregadomuchas veces durante el desarrollo. Cada incremento pasó por las distintas fases del desarrollo del sw, con lo cual en las primeras etapas se puede hacer un análisis ymitigación deriesgo mucho más efectiva que en un ciclo en cascada, ya que no hay

utilizar de varias maneras en elproceso de desarrollo: 1-En el Análisis puede ayudar en la validación y obtención de los requerimientos del sistema. 2-Sepuede utilizar el prototipo para explorarsoluciones particulares y apoyar el diseño de lasinterfaces deusuario. 3-Enlas Pruebas; se puede ejecutar pruebas con el prototipo,para el sistema que se entregará.Además de apoyar las actividades del proceso del sw, se utilizan prototipos para reducir el tiempo requerido para desarrollar

para detectarrequisitos ocultos (aquellos queel usuario nomanifiesta explícitamente pero que alinteraccionarcon el sistema surgen de forma espontánea).El proyecto muestra rápidamente yal poco tiempo signosvisibles de avance. Se estima que sedeberán realizar modificaciones importantesen la mitad del camino dedesarrollo del proyecto.El que sea rápido significa queel usuario nopueda esperartanto tiempo como en el modelo en cascada para interaccionarcon el sistema, ya que si es asíse perderían las ventajas


tienen que esperar hastaque el sistema esté completo parahacer uso de él. Para lograr esto los sistemasde más alta prioridad se entregan primero, y los incrementos posteriores se entregan entre ellos, es muy probable que a los sistemas importantes sea a los quese le haga más pruebas, esto quiere decir que es menos probable que los usuarios encuentren fallas de funcionamiento de sw en lapartes más importantes del sistema luego de que se termine elproyecto.

que esperar hasta las fases finalespara encontrar un problema. Es de aclarar que al igual que el ModeloCascada con mejora Iterativa, alterminar una versión ejecutable (primera versión) e cliente ya puede trabajar en ella, y el programador puede recibirlas recomendaciones que aquel le haga para mejorar el producto.No es recomendable este modelo para casos desistema de tiempo real, de alto nivelde seguridad,de procesamientodistribuido oalto índice de riesgo, por ejemplo es muy riesgoso

la documentacióndel usuario.

del prototipado. La idea de desechable está ligada más a las limitaciones de la tecnología empleada que a un interés real del usuario en “tirar” el trabajo realizado.Los inconvenientes que presenta son:no se conoce el tiempo quetomará terminar el producto. No se sabe cuántas iteraciones se deberán realizar, y no está ligado a una planificaciónrigurosa.Su uso es aplicable mayoritariamente para sistemas pequeños o detamaño medio (500.000 líneas de código) ya que para


utilizarlo ensistemas bancarios donde deba manejar dinero y transaccionesen tiempo real.

sistemas más grandes el proceso evolutivo resulta agudoy complejo.En los modelos de prototipos sepuede reutilizar elcódigo

4-Describa el proceso de selección y adaptación de un determinado ciclo de vida para un proyecto.

Los modelos de desarrollo de software son una representación abstractade una manera en particular porque realmente no representa como se debe desarrollar el software, sino un enfoque común. Puede ser modificado y adaptado a las necesidades del sw en proceso de desarrollo. Cada uno de los modelos vistos en la pregunta tres cuenta con pros y contras. El proyecto debe escoger el más apropiado para susnecesidades. En ocasiones puede que la elección de procesos pertenecientes a modelos diferentes, sea lo más apropiado.

La selección de la metodología para el desarrollo de sw se basa en presentar un conjunto de técnicas tradicionales y modernas de modeladode sistemas que permitan desarrollar sw de calidad, incluyendo heurísticas de construcción y criterios de comparación de modelos de sistemas. Para tal fin se describen herramientas de Análisis y Diseño orientado a objetos (UML), sus diagramas, especificación y criterios de aplicación de las mismas, las metodologías de desarrollo de sw que utilizan dichas herramientas son las descriptas en la pregunta anterior, y que tienen un ciclo de vida asociado.

Los enfoques más generales que se desarrollan en sus metodologías específicas son:

Modelo en cascada: Framework lineal


Prototipado: Framework iterativo Incremental: Combinación de Framework lineal e iterativo Espiral: Combinación de Framework lineal e iterativo RAD: Rapid Application Development, Framework Iterativo, este

modelo incluye a los modelos de Prototipo vistos en la pregunta tres.

Luego de tener clarificado el tipo y alcance de cada modelo, surge la cuestión de cuál utilizar, entonces debemos tener en cuenta las características generales de un proyecto vistas en la pregunta uno y además que los proyectos varían mucho unos de otros entrando en juego:

Requerimientos Actividades Tecnologías Tareas Usuarios Contextos Habilidades

Dado que le proyecto no es único no hay proyecto que se aplique al 100% de todos los proyectos de la organización.Una organización puede utilizar uno o más modelos de desarrollo dependiendo del tipo de proyecto.El modelo seleccionado tendrá influencia en el éxito del proyecto y enel tipo de decisiones a tomar.

Para seleccionar el modelo a adoptar habrá que hacerse una serie de cuestionamientos, en este caso el cuestionario lo extrajimos de la bibliografía como una plantilla:

Qué tanto el cliente y el desarrollador conocen los requerimientos?

Qué tan claros están los requerimientos? Se conoce bien la tecnología a utilizar? Hay un compromiso entre cliente y desarrollador para la

especificación de los requerimientos al comienzo del proyecto?


Es probable que el entendimiento de ambas partes cambie significativamente a medida que avanza el proyecto?

El desarrollador comprende bien la arquitectura del sistema? Es probable que necesite realizar modificaciones en la

arquitectura en la mitad del proyecto? Cuánta fiabilidad se necesita? Cuánto tiempo extra se necesita para planificar y diseñar durante

el proyecto para versiones futuras? Cuánto riesgo se debe tener en cuenta en el proyecto? Se debe estar sometido a una planificación predefinida Se necesita hacer modificaciones a medio camino? Se necesita proporcionar al cliente signo visible de progreso? Se necesita mostrar a los directivos signos visibles de progreso? Cuánta sofisticación se necesita para usar con éxito el modelo de

ciclo de vida?

Probablemente a la plantilla anterior se le deban agregar otras cuestiones, o detallar más otras ya existentes.

5-Qué ciclo de vida recomienda utilizar para cada uno de los siguientes sistemas a desarrollar? Fundamente la respuesta.

Nuevo producto, teléfono celular con interfaz activa con reconocimiento de imagen

Primero se analizarán los requerimientos:

Es importante el buen diseño Requiere de sw reutilizable Se necesita rapidez en su desarrollo Debe ser un producto innovador Necesita tecnología de avanzada Debe ser mejor en sus prestaciones generales que los existentes

en el mercado Debe tener las mismas funcionalidades ya aprobadas por los

usuarios, más las innovadoras como la interfaz activa con reconocimiento de imagen.


En base a los criterios anteriores para un buen diseño es conveniente utilizar el modelo de prototipos desechables.

Sistema de cámaras con alarma domiciliario.

De la misma manera que para el caso anterior analizaremos los requerimientos:

No es importante el diseño El software debe permitir el reconocimiento de imagen, por lo

tanto necesita alta tecnología. No permite al cliente ir probando el sistema, ya que requiere

asegurar la fiabilidad desde la primera versión. Reutilizará sistemas de sw existente. Debe estar probado y garantizado, no necesita tanto de la

innovación sino de la seguridad. Es importante que sea fácil de usar.

Ya con los requisitos anteriores se pueden formar conceptos del modeloa utilizar, o ir descartando otros modelos. Por ejemplo aquí no sería aplicable el modelo de prototipos. Parecería que un modelo tradicional, sería suficiente, en general un modelo de cascada, aunque no necesariamente puro, sería adecuado en este caso.

6-Cual es la diferencia entre plan, estimación y calendario?

Plan: es una intención o un proyecto. Es el modelo sistemático que se elabora antes de realizar una acción, con el objetivo de dirigirla y encauzarla. Es también un escrito necesario que se elabora para realizar un proyecto. En esta materia se estudian principalmente planes de sw, pero también puede ser un plan económico, un plan de obras, un plan de estudios, etc. Pero también un plan puede contener otros plan, es decir un subplan. Por ejemplo, un proyecto de sw incluye un subplan económico para desarrollarlo.


Estimación: predecir valores de sus entidades y atributos que sean relevantes para el proyecto. La estimación debe estar contenida en el plan, es una parte de él. Sus características son:

Predecir: anticipar con cierto grado de certeza Manejar Entidades: en sw son procesos, productos y recursos Atributos: que a su vez son características de las entidades del

sistema Relevantes: las que implican mayor riesgo

Para estimar hay que relacionar los atributos del proceso de la siguiente forma:

Costos en función de esfuerzo y modelo de procesos Esfuerzo en función de tamaño Duración en función de esfuerzo y recursos Tamaño en función de alcance Factores de ajuste Productividad: tamaño/esfuerzo

Se trabaja con las estimaciones durante el proyecto, siendo la estimación un patrón contra el cual medir, ajustar el desempeño, y anticipar riesgos. Y al final del proyecto para extrapolar resultados a otros proyectos.

La estimación utiliza los siguientes métodos:

Opiniones de expertos: en base a experiencia personal, pero no esun método confiable

Analogía: comparación con proyectos similares, tampoco es confiable pues resulta complejo determinar lo igual y lo distinto

Descomposición: subdividir y estimar los componentes, top-down y bottom-up, traslada el problema a estimar las partes

Modelos matemáticos: En base a fórmulas Calculan estimadores en base a medidas objetivas y/o

subjetivas


Esos valores pueden no tenerse en etapas tempranas (Ej. COCOMO y tamaño)

El avance de la tecnología los pone a prueba permanente

Calendario: el calendario sirve para la gestión de los tiempos dentro de la gestión del plan o proyecto. Obviamente también está incluido enel plan, ya que para el desarrollo de este se debe utilizar el calendario, por definición de proyecto, éste debe tener una fecha de inicio y una fecha de finalización, por más que sea aproximada, pero ¿cómo se podría lograr sino por medio del calendario?. También para realizar las estimaciones es necesario utilizar el tiempo o el calendario.

Nos serán desarrollados ahora pero existen técnicas utilizadas en ingeniería de sw para gestionar el calendario de un proyecto. Hay métodos muy conocidos como Gantt, Hitos, etc., para representar gráficamente el calendario de un proyecto.

Mediante el uso del calendario de un proyecto se definen los siguientes procesos:

Definición de las actividades Establecimiento de la secuencia estimación de recursos Estimación de la duración Desarrollo del cronograma Control del cronograma

7-Que dice la ley de Brooks?

La ley de Brooks es un principio utilizado en el desarrollo de sw que afirma que “añadir más efectivos a un proyecto de sw en retraso, lo retrasará más”, pues, entiendo, que según Fred Brooks quien fue el que acuñó este principio en 1975, todos los desarrolladores necesitan un proceso de aprendizaje en cada proyecto en forma particular y diferente a los otros proyectos, ese proceso como podríamos decir todos, necesita un tiempo mínimo que no se puede reducir, ni saltear.


Es como si el nuevo integrante al proyecto, fuera introducir el elefante al bazar o proyecto, es más lo que desordena o rompe que lo que puede ordenar y hacer avanzar a los trabajos; Brooks lo compara con la siguiente reflexión “nueve mujeres no pueden tener un bebé en un mes”.Ahora se indicarán técnicamente los dos factores que sustentan la ley:

1. Nuevas personas en un proyecto necesitan tiempo para ser productivas. Brooks denomina este lapso de tiempo de rampa de subida (“rump up time”).Los proyectos de sw son complejos esfuerzos de ingeniería, y a los nuevos trabajadores en el proyecto hay que enseñarles primerosobre el trabajo que se realizó anteriormente; esta formación requiere tiempo entre aquellos que ya estaban trabajando en el proyecto, disminuyendo su productividad hasta que los nuevos trabajadores tengan una contribución neta. Cada nuevo trabajador tiene que integrarse en un equipo compuesto por numerosos ingenieros, que han de ayudar en la formación de sus áreas de conocimiento, día a día. Además los nuevos miembros del proyecto, tendrán una productividad, en general, negativa, siendo esta afirmación consistente con la ley, necesario para que la implique; por ejemplo introducir más errores en el sw por desconocimiento del proyecto, que la media de programadores más antiguos en el proyecto.

2. Aumento de los costos generales (en tiempo) a medida que aumenta el tamaño del proyecto. El número de canales de comunicación diferentes aumenta con el número de personas de forma exponencial, si se duplica el número de personas en el proyecto, el resultado es 4 veces más conversaciones. Todos quienes trabajan en un tema, necesitan estar sincronizados entre ellos, de manera que si crece el número de personas, también crecerá el tiempo invertido el tratar de averiguar lo que hace el resto.

Excepciones y posibles soluciones

La ley de Brooks se utiliza para justificar la no finalización a tiempo de los proyectos a pesar de los esfuerzos de los gestores. Pero


hay algunos puntos claves de la ley que permiten excepciones y abren puertas a posibles soluciones:

El primer punto es que la ley de Brooks se suele aplicar a proyectos que tienen retraso. Se puede volver a controlar (o mantener bajo control) si se refuerza el equipo en fases previas. También es importante saber si el proyecto se encuentra en retraso real, o si lasestimaciones iniciales fueron demasiado optimistas respecto a la realidad del proyecto. Corregir la planificación es la mejor manera dedisponer de una ventana de tiempo fiable y útil para finalizar el proyecto.

Una vía simple de evitar la ley en un proyecto en retraso es añadir más gente de la necesaria, lo entiendo como si ya el número superior al necesario empiece a compensar y neutralizar la ley. Aquí apareceríalo que se denomina “La ley de Linus”, para macro proyectos, que afirma que “cuando hay tantos ojos para ver, los errores se hacen obvios”, estos tipos de proyectos los vemos en código abierto, que permiten, debido a tanta cantidad de colaboradores, sacar versiones más seguidas que el código privado, y corregir los errores mucho más rápido para estabilizar las nuevas versiones. El uso de internet y la comunicación a través de ella bien utilizada, a través de correo electrónico, y pienso que hasta las redes como whatsApp, permiten que un gran número de colaboradores y desarrolladores logren una sinergia muy efectiva. También para suplir le ley de Brooks, es de utilidad segmentar o subdividir los equipos de proyectos para aplicaciones más pequeñas del mismo, y por otro lado, utilizar a los equipos más numerosos para el sistema grande.

8-En el ámbito de la gestión de proyectos, explicar las similitudes y diferencias entre los conceptos de Proyecto, y Programa.

Las diferencias son:

Un Programa es de carácter más global que agrupa proyectos relacionados que pueden ser desarrollados de manera paralela o secuencial, expresa lineamientos fundamentales que engloban al


proyecto. La formulación de un plan deriva de propósitos y objetivos más amplios, es el parámetro técnico dentro del cual seenmarcan los proyectos.

Existe mucho más información disponible para la administración deprogramas que para la de proyectos

Típicamente una programa se define como una organización tipo paraguas, o sobre protectora de un conjunto de proyectos.

Ningún trabajo es entregado a nivel de programa, todos los trabajos son entregados a nivel de los proyectos subyacentes

El Programa está para ayudar a la dirección del esfuerzo, ayudar a iniciar nuevos proyectos, ayudar que los proyectos estén progresando de acuerdo al Plan.

Por los puntos anteriores, toda la acción (y en consecuencia la literatura) continúa centrándose en la dirección de proyectos y no de programas, pues un programa es un concepto más abstracto, yun proyecto un concepto más tangible.

Las similitudes son:

Se asemejan en su estructura, que es marcar un objetivo para resolver un problema.

Utilizan similares recursos, tanto humanos, materiales e informativos, cada uno en la dimensión que le corresponde.

Ambos requieren una planificación adecuadamente Se concretan desde ideas generales a ideas particulares, método

deductivo Se priorizan los problemas a partir de metodologías adecuadas al

entorno Requieren evaluaciones constantes Desde el punto de vista conceptual y general todo programa es un

proyecto abstracto. Un Programa es un proyecto global que contiene a su vez proyectos

menores para alcanzar el objetivo general.

9-Indique los aspectos que considere más significativos sobre el Estudio de Viabilidad de un Proyecto Software.


El estudio de la viabilidad técnica, económica, operativa y jurídica (y de ser necesario otras) del proyecto permiten:

Lograr el conocimiento general para resolver el problema o aprovechar la oportunidad, también la estructura de los requerimientos de información con el fin de estimar los recursos necesarios

Planear alternativas de desarrollo Realizar plan Planeación general de actividades Evitar desarrollar proyectos que no son factibles Planear los recursos Traer a la realidad al personal administrativo de sistemas,

auditores, etc., respecto a las expectativas fácticas del sistema Entender el proyectos Establecer la duración y tamaño del proyectos Determinar los costos y los beneficios Determinar la factibilidad del sistema Elaborar un documento con recomendaciones en el cual debe quedar

claro la manera en que se debe proceder para que el proyecto sea factible

Definición organizada de los requerimientos de información Saber los recursos requeridos para el desarrollo del proyectos El Análisis de Factibilidad Las Alternativas de Desarrollo Hacer el Cronograma de Actividades

Principales componentes del estudio de viabilidad

Reconocimiento general del sistema Recursos requeridos Usuarios del sistemas Beneficios esperados del proyecto Costo del proyectos Análisis de alternativas de implementación Análisis de factibilidad del sistema


Definir el impacto sobre los planes generales de la organización o sobre su planeación estratégica

Cronograma

10-Qué tipo de costos podemos encontrar en un Proyecto Software?

Los costos del proyecto pueden estar dados por la adquisición o utilización de equipos, personal, compra de software, costos de los procedimientos para la recopilación de información, preparación de documentación, mantenimiento de sistemas, etc. Deben ser calculados para cada uno de los recursos en cada una de las etapas del ciclo de vida del sistema.Requerimientos para el cálculo de la relación Costo/Beneficio.

11- Investigue el Manifiesto de desarrollo de SW ágil ( http://agilemanifesto.org/iso/es/) y los principios ágiles (http://agilemanifesto.org/iso/es/principles.html) Ud. acuerda con el Manifiesto? En que no acuerda? Donde considera que no se aplican?

El Manifiesto de desarrollo de sw ágil surge como alternativa a las metodologías formales (CMMI, SPICE) a las que consideraban excesivamente “pesadas” y rígidas por su carácter normativo y fuerte dependencia de planificaciones detalladas y previas al desarrollo.

Los integrantes de la reunión resumieron los principios sobre los que se basan los métodos alternativos en cuatro postulados, los que han quedado denominados como Manifiesto Ágil, y se expone que:

“Estamos poniendo al descubierto mejores métodos para desarrollar, haciéndolo y ayudando aotros que lo hagan, con este trabajo hemos llegado a valorar:

A los individuos y su interacción, por encima de los procesos y las herramientas.”

Lo que debe buscar en la vida el ser humano es la felicidad permanente, por una ley hermética, aunque no aceptada por todos ni esta ni otras, el ser humano es bipolar, tiene momentos de felicidad e


http://agilemanifesto.org/iso/es/principles.html

http://agilemanifesto.org/iso/es/

infelicidad, pero lo que no se debe perder es que los individuos, y su interacción, o sea el relacionamiento con los demás miembros del equipo debe estar por encima de los procesos y la herramientas para ser consistentes con el bienestar humano mencionado, que es al final para lo que desarrolla cualquier proyecto, hasta un plan de guerra, eneste caso sacrificando en teoría, la felicidad ajena para obtener la propia.

“El software que funciona por encima, por encima de la documentación exhaustiva.”

La documentación exhaustiva es para lograr un buen sw, por lo tanto elconcepto es coherente en teoría, en la práctica nos surge la pregunta:

¿Es posible asegurar, con un porcentaje alto de certeza, de que el swque funciona se puede crear sin una documentación exhaustiva. Sin pasar por todas las normas de control de calidad de sw?. ¿Se pueden “apurar” los procesos?. Habíamos dicho en la pregunta correspondiente a la ley de Brooks, que al aumentar el personal en el equipo de sw queestá atrasado, aun lo retrasa más, porque los nuevos desarrolladores necesitan pasar las etapas necesarias, respetar los procesos y sus tiempos. El respetar los tiempos y el estudio exhaustivo, sirven paraasimilar, aprender y afirmar los conceptos del proyecto en las personas normales, en la práctica no me parece factible obviarlo en forma significativa, y que resulte lineal con la agilidad del desarrollo del sw.

“La colaboración con el cliente, por encima de la negociación contractual”.

Se debe tener flexibilidad con la normativa, apelar al sentido común, y a la ética. Muchas veces cuando se redactan los contratos se hacen en forma bastante genérica en su estructura, y quizás los mismos sean muy estrictos para con el cliente previendo así, la empresa, “cubrirse” por eventuales conflictos o abusos por parte de sus clientes. Pero la finalidad debe ser colaborar con los clientes, no


“matarlos” con la letra fría, a veces la “letra chica” de la negociación.

“La respuesta al cambio, por encima del seguimiento de un plan.

Aunque hay valor en los elementos de la derecha, valorar más los de la izquierda.”

Esta idea me hace pensar que fue escrita por un marxista, o un socialista, ¿por qué se debe valorar más los de la izquierda?

Cambiar durante el ciclo de vida es necesario, pues siempre habrá nuevos escenarios que no estaban previstos a pesar de haberse hecho unbuen plan, es decir un proyecto o conjunto de proyectos bien planificados. Los valores de la derecha y de la izquierda son iguales en si mismo, es decir tienen la misma posibilidad el uno respecto al otro de estar equivocados, y la misma posibilidad de estar en el acierto, no importa en cual platillo de la balanza se encuentre el valor, su peso es el mismo en uno y otro lado.

Después hay doce Principios que mencionan como favorables las ideas que estarían contenidos en los cuatro anteriores, y en los modelos iterativos incrementales, y de prototipos, buscar la simplicidad los máximo posible sin perder la funcionalidad, valorando la autodeterminación de los equipos y de las relaciones humanas cara a cara entre todas las personas intervinientes en el proyecto (desarrolladores y clientes, usuarios en general)

12-Cuales son los principios que se aplicarían en Scrum? Realice un resumen de los principios.

De todos los equipos que se dicen utilizar métodos ágiles de desarrollo, más de un 90 % declara utilizar Scrum. Este método permite a los equipos trabajar conjuntamente en la entrega de sw iterativa e incrementalmente. Se organizan el trabajo en espacio de tiempo limitado denominado Sprint, que duran un máximo de un mes, lo


que produce un conjunto de funcionalidad completa y activa en cada Sprint.

El marco de trabajo Scrum es fácil de entender, y se ha vuelto muy popular entre los equipos de desarrollo de sw y sus clientes. Promuevelos equipos multidisciplinarios y autogestionados que se centran en elSprint para entregar un incremento de trabajo y sw que se puede liberar.Scrum está codificado en la Guía de Scrum, que documenta los roles, los artefactos, y los documentos de Scrum. La Guía de Scrum la mantienen los creadores de Scrum y está disponible en la línea de Scrum.org

Scrum se caracteriza por:

Adoptar una estrategia de desarrollo incremental, en lugar de planificación y ejecución completa del producto.

Basar la calidad del resultado, más en el conocimiento tácito (que no se expresa formalmente, sino que se supone o sobreentiende) de las personas en equipos autoorganizados, que enla calidad de los procesos empleados.

Solapamiento de las diferentes fases del desarrollo, en lugar de desarrollar una tras otra en un ciclo secuencial de cascada.

Las características más marcadas que se logran notar en Scrum serían:

Gestión regular de las expectativas del cliente, Resultados anticipados. Flexibilidad y adaptación. Retorno de inversión, mitigación de riesgos, Productividad y calidad, Alineamiento entre cliente y equipo. Equipo motivado.

Cada uno de los puntos mencionados hace que el Scrum sea utilizado de manera regular en un conjunto de buenas prácticas para el trabajo en equipo y de esa manera obtener resultados posibles.


Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde notas amarillas "post-it" y pizarras hasta paquetes de software. Una de las mayores ventajas de Scrum es que es muy fácil de aprender, y requiere muy poco esfuerzo para comenzarse a utilizar.

13-Describa la metodología Scrum y realice un ejemplo breve identificando cada concepto y etapa. Describa como se realiza la estimación del esfuerzo cuando utiliza Scrum

La metodología Scrum es ejecutar proyectos en bloques temporales cortos y fijos (naturalmente iteraciones de un mes, y se requiere puede ser dos semanas).Cada iteración tiene que proporcionar un resultado completo, un incremento de producto final que sea susceptible de ser entregado con un mínimo de esfuerzo al cliente cuando lo solicite.El proceso parte de la lista de objetivos y requisitos priorizada del producto, que actúa como plan del proyecto. En esta lista el cliente prioriza los objetivos balanceando el valor que le aportan respecto a su costo y quedan repartidos en iteraciones y entregas. De manera regular el cliente puede maximizar la utilidad de lo que se desarrollay el retorno de inversión mediante la replanificación de objetivos querealiza al inicio de cada iteración.

Ejecución de la Iteración

Cada día el equipo realiza una reunión de sincronización (15 minutos máximo). Cada miembro del equipo inspecciona el trabajo que el resto está realizando (dependencias entre tareas, progreso hacia el objetivode la iteración, obstáculos que pueden impedir este objetivo) para poder hacer las adaptaciones necesarias que permitan cumplir con el compromiso adquirido. En la reunión cada miembro del equipo responde atres preguntas:

¿Qué he hecho desde la última reunión de sincronización?


¿Qué voy a hacer a partir de este momento?

¿Qué impedimentos tengo o voy a tener?

Durante la iteración el Facilitador se encarga de que el equipo pueda cumplir con su compromiso y de que no se merme su productividad.

Elimina los obstáculos que el equipo no puede resolver por sí mismo.

Protege al equipo de interrupciones externas que puedan afectar su compromiso o su productividad.

Inspección y adaptación

El último día de la iteración se realiza la reunión de revisión de la iteración. Tiene dos partes:

1. Demostración (4 horas máximo). El equipo presenta al cliente los requisitos completados en la iteración, en forma de incremento de producto preparado para ser entregado con el mínimo esfuerzo. En función de los resultados mostrados y de los cambios que haya habido en el contexto del proyecto, el cliente realiza las adaptaciones necesarias de manera objetiva, ya desde la primera iteración, replanificando el proyecto.

2. Retrospectiva (4 horas máximo). El equipo analiza cómo ha sido su manera de trabajar y cuáles son los problemas que podrían impedirle progresar adecuadamente, mejorando de manera continua su productividad. El Facilitador se encargará de ir eliminando los obstáculos identificados.

Actividades

La planificación de las tareas a realizar en la iteración se divide endos partes:


Primera parte de la reunión: se realiza en un marco o lapso de tiempo (timebox) de como máximo 4 hs.

El cliente presenta al equipo la lista de requisitos priorizada del producto o proyecto. Pone nombre a la meta de la iteración, de manera que ayude a tomar decisiones durante su ejecución, y propone los requisitos más prioritarios a desarrollar en ella.

El equipo examina la lista, y pregunta al cliente las dudas que le surgen, añade más condiciones de satisfacción y selecciona losobjetivos/requisitos más prioritarios que se compromete a completar en la iteración, de manera que puedan ser entregados siel cliente lo solicita.

Segunda parte de la reunión: se realiza un timebox de cómo máximo 4 hs. El equipo planifica la iteración, elabora la táctica que le permitirá conseguir el mejor resultado posible con el mínimo esfuerzo.Esta actividad la realiza el equipo dado que ha adquirido un compromiso, es el responsable de organizar su trabajo y es quien mejorconoce cómo realizarlo.

Define las tareas necesarias para completar cada objetivo/requisito creando la lista de tareas de la iteración (Sprint Backlog) basándose en la definición de completado.

Realiza una estimación conjunta del esfuerzo necesario para realizar cada tarea.

Cada miembro del equipo se autoasigna las tareas que puede realizar.

Los timebox mencionados son tiempos máximos en caso de iteraciones mensuales. En iteraciones de tamaño menor el tiempo es proporcionalmente inferior y se puede ir reduciendo conforme el equipo


va ganado experiencia en este tipo de reuniones, aunque también dependerá de la complejidad a desarrollar en la iteración.

Restricciones

La reunión diaria de estados y sincronización del equipo no es para resolver problemas, los problemas se resuelven después de la reunión.

No a todos los miembros del equipo les interesa los detalles de cada tema.

En la reunión los miembros del equipo programan reuniones donde colaborar sincronizando tareas, ayudando a resolver problemas, etc.

No puede haber una persona explicando su estado mientras otras sehan apartado de la reunión para comentar un tema particular. Si aparece alguna conversación de interés común (que debe ser rápida), debe poder ser escuchada por todo el equipo sin distraerel principal objetivo de que todos conozcan en qué están trabajando los demás. Si la miniconversación no es de interés de todos debe de hacerse después de la reunión.

El equipo debe contar con unos criterios consensuados sobre el procesode ejecución de las tareas.

El proceso de ejecución de las tareas debe estar consensuado paraevitar que cada reunión sea una exposición de discrepancias entrelos miembros del equipo.

Recomendaciones

Realizar la reunión diaria de sincronización de pie, para que losmiembros del equipo no se relajen, ni se extiendan en más detalles de los necesarios.


Realizar las reuniones de colaboración entre miembros del equipo justo después de la sincronización.

Sólo se pueden mostrar al cliente los requisitos completados paraque éste no se cree falsas expectativas y pueda tomar decisiones correctas y objetivas en función de la velocidad de desarrollo yel resultado realmente completado. Un requisito no completado quedará como un requisito más a replanificar.

Es necesario que el equipo y el Facilitador dispongan de autoridad, mecanismos y recursos, para ir mejorando su forma de trabajar y el contexto del proyecto. Pues es frustrante encontrarsistemáticamente los mismos obstáculos y no poder solucionarlos.

Retrospectiva

Con el objetivo de mejorar de manera continua su productividad y la calidad del producto que está desarrollando el equipo debe analizar cómo ha sido su manera de trabajar durante la iteración, por qué está consiguiendo o no los objetivos a que se comprometió al inicio de la iteración y si el incremento de producto que acaba de mostrar al cliente era el que éste esperaba o no.

Qué cosas han funcionado bien Cuáles hay que mejorar Qué cosas se quieren probar hacer en la siguiente iteración Que ha aprendido Cuáles son los problemas que podrían impedirle progresar

adecuadamente. El facilitador se encargará de ir eliminando los obstáculos identificados que el propio equipo no pueda resolver por si mismo

Esta reunión se realiza después de la reunión de demostración al cliente de los objetivos conseguidos en la iteración, para poder incorporar su feedback y cumplimiento de expectativas como parte de los temas a tratar en la reunión de retrospectiva.


Se realizará en un timebox como máximo de 3 hs si la iteración es mensual.

Estimaciones

De las cosas más complejas cuando se trabaja con Scrum es cómo hacer las estimaciones, y cómo nos van a ayudar éstas para saber dónde se está y cuándo va a finalizar el proyecto. El Scrum suele estimarse dosveces, pero no en la forma tradicional con una única y laboriosa estimación en horas/días de trabajo al principio del proyecto.

Se hace una primera estimación a grosso modo en puntos y no en horas, en que partiendo de la lista inicial de funcionalidades se estima el esfuerzo o dificultad que supondrá realizar cada uno de los requisitosdel proyecto. Este esfuerzo se “calibra” en puntos siguiendo por ejemplo la serie de Fibonacci (1,2,3,5,8,13,...), o incluso usando lasmedidas en las tallas de camisas (S,M,L,XL,XXL,...). Atendiendo al concepto de “Cono de Incertidumbre”, se haga la estimación que se haga, dedicándole el tiempo que sea y la metodología que sea la estimación será errónea (a menos que se conozcan los detalles del proyecto). Entonces para qué dedicar tanto esfuerzo; asignándole 1 o 2puntos a las funcionalidades sencillas, 3 o 5 a la dificultad media, y8 o 13 a las de dificultad alta o muy alta se consigue un resultado similar, y si se necesitan más puntos se puede descomponer a esta funcionalidad en otras más pequeñas.

Esto traerá, según Scrum, un considerable ahorro del esfuerzo al estimar quitando estrés al equipo al simplificar, disminuyendo el miedo a equivocarse.

La segunda estimación se hace cuando se planifican las tareas del Sprint. En esta planificación se tendrá un mayor conocimiento del proyecto, y de lo que implica cada tarea. Pudiéndose hacer entonces una planificación en horas, aunque hay equipos que aun en ese momento hacen una estimación en puntos, o deciden no estimar en absoluto.

Estas estimaciones permiten conocer el retorno de inversión (ROI) de cada funcionalidad para que el cliente pueda decidir qué tareas quiere


realizar en el siguiente Sprint, y permite también después de algunos Sprint, conocer con bastante exactitud cuál es la velocidad del equipo.

Caso Práctico

Realizar una web de Librería Online

Un cliente se pone en contacto con una empresa que diseña páginasweb.

El cliente realiza el pedido que necesita una librería online. El cliente se pone en contacto con el director de proyectos de sw

quien toma nota de lo que tiene el cliente en su cabeza. El director de proyecto divide el proyecto en historias que son

las que componen el Sprint Backlog (la pila de requerimientos). El Scrum Master es un miembro del equipo que tiene el papel de

comunicar y gestionar las necesidades del director de proyecto y la pila de Sprint

El director de proyectos le entrega la pila de requerimientos para que el equipo estime el costo de la creación del sw.

El equipo se reúne para estimar el costo de cada historia de la pila de producto (hay un método denominado Planning Poker que utilizan para el cálculo).

El cliente una vez aprobado el presupuesto, reordena la pila de producto para que el equipo vaya trabajando según la prioridad del cliente.

El equipo comienza su trabajo desglosando la primera historia de la pila de producto, la cual subdividen en tareas menores para crear la pila de Sprint.

La pila de Sprint tiene como utilidad fraccionar el trabajo de unperíodo de 15 días en tareas más pequeñas, que tardan como máximo2 días. Estas tareas se colocan en una pila la cual prioriza el director de proyecto, que ha consultado con el cliente, antes de comenzar el Sprint.

El equipo comienza el Sprint tomando las tares priorizadas. Una vez concluida una se toma la siguiente de la lista.


Se convoca todos los días una reunión del equipo donde se cuenta las tareas realizadas el día anterior y cuáles se van a realizar ese día.

Una vez finalizado el Sprint el Director de proyectos le muestra al cliente el trabajo realizado. El cliente ya tiene el primer contacto con su encargo y además puede volver a priorizar la pilade producto antes de que comience otro Sprint (ver tabla siguiente).

El equipo de trabajo revisa su hacer con una reunión de retrospectiva, donde se analiza lo ocurrido durante el Sprint.

Tabla de Sprint Backlog, luego de ser probada por lo menos después de finalizado un Sprint

Nueva estimación en SprintPrioridad

Elemento Detalles (URL Wiki)

Estimación inicial

1 2 3 4 5 6

1. Como comprador, poder poner el libroen el carrito (ver esquema de interfaz en el Wiki)

... 5

2. Como comprador, poder eliminar un libro del carrito decompra

... 2

3. Mejorar el rendimiento del procesamiento de transacciones (ver métricas objetivo enel Wiki)

... 13

4. Investigar solución para mejorar velocidad de validación de tarjetas de crédito (ver objetivo de métricas de rendimiento en Wiki)

... 21


5. Actualizar todos losservidores a Apache

... 13

6. Diagnosticar y arreglar los erroresdel script de procesamiento de pedido

... 3

7. Como comprador, crear y guardar una lista de deseos

... 36

8. Como comprador, poder añadir y borrar artículos en la lista de deseos

... 21

Nota: Wiki, es el nombre que recibe un sitio web cuyas páginas pueden ser editadas directamente desde el navegador, donde los usuarios crean, modifican o eliminan contenidos.

14-Definir el concepto de Gestión de Riesgos y explicar brevemente los5 niveles de gestión que pueden llevarse a cabo en un proyecto. Cómo se construye una matriz de riesgo? De un ejemplo. Elabore un plan de riesgos de un proyecto, elija Ud. el proyecto.

La Gestión de Riesgos, es un plan subsidiario para la dirección del proyecto. Es un enfoque estructurado para manejar la incertidumbre relativa a una amenaza que pueda afectar negativamente la marcha del proyecto en el futuro, a través de una secuencia de actividades humanas, que incluyen evaluación de riesgo, estrategias de desarrollo para manejarlo, y mitigación del riesgo utilizando recursos gerenciales.

Los riesgos pueden clasificarse en cinco categorizaciones según cómo afectarán las posibilidades de concreción del proyecto:

1. No aceptable: el riesgo pone en peligro los objetivos del proyecto. El proyecto no podrá continuar si no se toma una acción inmediatapara reducir la categoría del riesgo.


2. Crítico: el riesgo puede afectar los objetivos estratégicos del proyecto, por lo tanto debe mitigase o reducir su probabilidad deocurrencia y el daño que puede producir.

3. Mayor: el daño producirá un impacto significativo en el programa del proyecto con posibilidad de afectar a muchas áreas y los hitos. Debe monitorearse de cerca y ejecutar acciones para mitigar la probabilidad de ocurrencia y/o el daño.

4. Menor: el evento no causa problemas significativos en el proyecto, y no afecta los hitos. Se debe monitorear regularmente para que no ocurran o para que no aumenten su categoría.

5. Área de interés: el riesgo no puede clasificarse en ninguno de los niveles anteriores, pero constituye un área de interés que debe monitorearse para que no cambie de estado

Para construir una Matriz de Riesgo, se parte como antesala del plan de Gestión de Riego, de su análisis y cuantificación, y así obtener como salida la matriz propiamente dicha:

1. Planificar la gestión de los riesgos, en donde se definen la reglas de la construcción, que consiste básicamente en establecerla reglas de como los vamos a gestionar, es decir cómo los vamos a identificar, a calificare, a cuantificar, y cuál son las respuestas que vamos a preparar, así como el seguimiento y control, este proceso está fuera del ciclo ya que se realiza una sola vez.

2. Se identifican los riesgos, usando la Estructura Detallada del Trabajo (EDT) y el Cronograma, estudiando que eventos se pueden presentar, y que de presentarse afectarían los objetivos del proyecto, principalmente al alcance, a la duración y al costo.

3. Una vez identificados, se tendrá ya la lista de riesgos, se procede a realizar el análisis cualitativo y el cuantitativo, es decir se deben calificar estableciendo prioridades de atención. Aquí se priorizan los riesgos y se cuantifica o mide su impacto económico


4. Una vez que se analizan los riesgos se preparan las respuestas, osea un plan de mitigación, o de traslado, o transferencia de los riesgos, también puede ser el caso de solamente aceptarlos.

5. Después debe haber un proceso de seguimiento y control, ya que hay que estar pendiente de nuevos riesgos, y saber si aquellos yaidentificados evolucionan, es decir si aumenta su probabilidad deocurrencia o su impacto. En el ciclo de vida del proyecto pueden aparecer nuevos riesgos que se tendrán que ingresar al proceso, olos ya identificados pueden aumentar su probabilidad, o su impacto.

Es decir que la matriz de riesgo contendrá:

A los riesgos identificados Roles y responsabilidades: por ejemplo si un proyecto tiene una

gran cantidad de riesgo, vale la pena que un miembro del equipo se dedique sólo a darle seguimiento y control, y éste será el administrador de riesgos.

También contendrá una herramienta o plantilla para categorizarlos: al tener una plantilla de categorías de riesgo ayuda a facilitar su identificación para no cometer omisiones. También en este caso se pueden incluir los valores de probabilidad e impacto.

Determinación de los valores de probabilidad e impacto

Se pueden utilizar tres valores para la probabilidad de ocurrencia, los cuales se muestran en la tabla:

Escala de ProbabilidadMuy probable 0.9Bastante probable 0.7Probable 0.5Poco probable 0.3Muy poco probable 0.1


Severidad o Impacto

Nivel Valor de riesgo No aceptable 0.8Crítico 0.4Mayor 0.2Menor 0.1Área de interés 0.05

Evaluación del impacto de un riesgo en los objetivos principales del proyectoObjetivo del proyecto

Área de interés .05

Menor .1 Mayor .2 Crítico .4 No aceptable .8

Costo Insignificante incremento del costo

Incremento del costo <5%

Incremento del costo entre 5-10%

Incremento del costo entre el 10-20%

Incremento del costo >20%

Calendario Insignificante variación del calendario

Variación delcalendario <5%

Desviación general del proyecto 5-10%

Desviación general del proyecto 10-20%

Desviación general del proyecto >20%

Alcance Reducción delalcance apenas perceptible

Áreas menoresde alcance son afectadas

Áreas mayoresde alcance son afectadas

Reducción delalcance inaceptable para el cliente

El producto final del proyecto es inservible

Calidad Degradación de la calidadapenas perceptible

Sólo aplicaciones muy específicas son afectadas

La reducción de la calidaddemanda la aprobación del cliente

Reducción de la calidad inaceptable para el cliente

El producto final del proyecto es inservible

Matriz de probabilidad por impacto

Marcador de riesgo para un riesgo específico (P x I)

Impacto

Probabilidad

Área de interés .05

Menor .1 Mayor .2 Crítico .4 No aceptable .8


0.9 0.05 0.09 0.18 0.36 0.720.7 0.04 0.07 0.14 0.28 0.560.5 0.03 0.05 0.1 0.20 0.400.3 0.02 0.03 0.06 0.12 0.240.1 0.01 0.01 0.02 0.04 0.08

Verde-Riesgo Bajo Amarillo-Riego Moderado Rojo Riesgo Alto

Combinando las escalas de la probabilidad y de impacto se obtiene la matriz P x I del cuadro anterior, la cual permite calificar cada riesgo según la escala

Nota: La matriz de riesgo no se debe aplicar a hospitales, compañías petroleras, centrales nucleares, etc., donde los riesgos, si ocurren, pueden ser catastróficos, es más bien para proyectos de tipo administrativo.

Para realizar la matriz de ejemplo usaré la idea del proyecto teórico que presentara en la AO2 de Gestión de Proyectos Informáticos I, un Proyecto de Software para la Inscripción de Alumnos para un Liceo Departamental.

No hay un diseño fijo de una matriz de riesgo, no solamente que es dinámica por los nuevos riesgos que pueden surgir, y las nuevas valoraciones que requieren los mismos, sino por la manera de conformarla, más o menos columnas con diferentes ítems, que pueden sermás o menos a considerar.Haremos una matriz simplificada, no pondremos por ejemplo en este ejemplo los Work Breakdown Structure (WBS), ni el área a la que podríapertenecer la amenaza:

Tabla de Registro de Riesgos del Proyecto ejemplo: “Proyecto de Software para la Inscripción de Alumnos para un Liceo Departamental”

Priorización


Nº Id Causa Riesgo, Amenaza o Peligro (Descripción)

Probabilidad Impacto Rango

1 Base de Datosdañada

Pérdida de inscripción realizada

0.7 0.4 0.28

3 Errores introducidos en el sistema

Inconsistencia de Información

0.9 0.8 0.72

4 Errores introducidos en el sistema

Alumnos inscriptos que no cumplen con lo reglamentado

0.7 0.8 0.56

5 Ingreso de intrusos paradañar el sistema

Vulnerabilidad del sistemapermitiendo que éste sea dañado

0.3 0.8 0.24

2 Tablas relacionales con campos noatómicas

Redundancia de la información

0.1 0.4 0.04

… … … … … …Riesgo General del Proyecto: Mayor 0.37

Según el rango o calificación a cada riesgo se le asigna el color correspondiente, en este caso es intuitivo, de mayor a menor riesgo (rojo, verde, amarillo). Se ordena de forma descendente la lista por la columna Rango, obteniéndose así la lista de riesgos priorizados o “top list”.

Finalmente se indica cuál es el riesgo general del proyecto (Alto, Medio, o Bajo), según el promedio de rango de todos los riesgos evaluados (promedio general de la columna P x I) y se ubica en la


escala de calificación de riesgo general de la tabla “Escala de calificación del riesgo general del proyecto”

Escala de calificación del riesgo general del proyectoAlto 0.99 - 0.18Moderado 0.17 – 0.05Bajo 0.04 – 0.01

Según la tabla “Escala de calificación del riesgo general del proyecto” en este ejemplo los riesgos producen un impacto alto. Una vez que se tiene el registro de riesgos priorizado, se procede a planificar la respuesta a cada uno de ellos, para lo cual se añaden las siguientes columnas al registro de riesgo de riesgos que se viene construyendo desde el proceso de identificación:

Estrategia: que son Eliminar, Mitigar, Transferir y Aceptar

Acciones preventivas: es la descripción de las acciones que respaldan cada estrategia, excepto para la estrategia común de aceptación, que se especifican en la columna Plan para Contingencias”

Respaldos: opcionalmente para las estrategias de no aceptación (Eliminar, Mitigar, Transferir) también se puede establecer acciones, correspondientes a un plan de respaldo (Plan “B”), las cuales se ejecutarían en caso de falla de la estrategia primaria.

Plan para contingencias: para los riesgos aceptados se describe un plan de contingencias. Estas actividades se planifican para ser ejecutadas sólo en caso de que se active el disparador de eseriesgo que se corre (aceptándolo).

Reservas (dividida en dos columnas T y $): calcular las reservas para contingencias generales del proyecto (T y $), utilizando el Valor Monetario Esperado de los riesgos aceptados. Sumatoria de los P x It (Probabilidad por el Impacto en tiempo si el riesgo


llegase a ocurrir) y la sumatoria de los P x Ic (Probabilidad porel Impacto en costo si el riesgo llegase a ocurrir).

Disparador: en la manera de lo posible indicar una señal de que el riesgo va a suceder o sucedió (importante para los riesgos aceptados)

Responsable: miembro del equipo o de la organización que debe responder por la ejecución de las acciones planeadas para ese riesgo.

Probabilidad Post Plan: En dependencia de la estrategia proactivaplanificada se disminuye la probabilidad y/o impacto original delriesgo, y por lo tanto el rango del riesgo, utilizando la escala de probabilidad (tabla “Escala de Probabilidad”), se le asigna el valor de la probabilidad a cada riesgo teniendo en cuenta la respuesta dada.

Impacto Post Plan: utilizando la escala de impacto (tabla “Severidad o Impacto”), se le asigna al riesgo el valor correspondiente, teniendo en cuenta la respuesta dada.

Rango Post Plan: Multiplicación de la “probabilidad post plan” por el “impacto post plan”.

El nivel umbral de tolerancia para este proyecto de ejemplo consiste en el riesgo general del proyecto con rango del 0.10 (Bajo). Esto significa que se debe ir aplicando estrategias preventivas a los riesgos en el orden de importancia que aparecen en el registro de riegos priorizado. Una vez alcanzado este rango del riesgo general delproyecto, el resto de riegos de la lista se acepta, a menos que se le pueda aplicar una estrategia preventiva de bajo costo, acorde con el rango del riesgo.

Las acciones que respaldan las estrategias proactivas se deben incorporar en el Plan de Gestión de Proyecto. Por lo que se deben incluir estas actividades en el cronograma proporcionado como parte


del caso, como parte del alcance del proyecto, con fechas de cumplimiento, recursos, y todo lo que sea pertinente.

Las actividades correspondientes al Plan para Contingencias y Planes de Respaldo, no se incorporan en el cronograma, puesto que éstas se ejecutarían en caso de que los riesgos aceptados sucedan o fallen las estrategias proactivas, respectivamente. Sin embargo sí deben reflejarse en el cronograma de las reservas para contingencias (tiempoy costo).


Tabla de Registro de Riesgos del Proyecto ejemplo: “Proyecto de Software para la Inscripción de Alumnos para un Liceo Departamental”

Pian de respuesta.Nº Id Rango Estra

tegiaAcciones preventivas

Respaldos

Plan para contingencias

Reservas

T $

Disparador

Responsable

Probabilidad post-plan

Impacto post-plan

Rangopost-plan

3 0.72 Capacitar al personal para trabajar en elnuevosistema

A. Díaz

0.5 0.8 0.4

1 0.28 Mitigar

Capacitar al personal con las nuevas tecnologías de las basesde datos

J.Pérez

0.4 0.4 0.16

4 0.56 Corregir

0.2 0.8 0.16


errores del sistema, principalmente las basesde datos

5 0.24 Transferir

Contratar a unaempresa que garantice la seguridad informática

C. Denis

0.1 0.8 0.08

2 0.04 Rehacerlastablas relacionales

L. Pombo

0.1 0.4 0.04

… … ... … … … … … … … … … …Riesgo General del Proyecto: Alto

Total de Reservas para contingencias

0 hs 0 $ Riesgo General del Proyecto Post Plan: Moderado

0,14


Según la tabla “Escala de calificación del riesgo general del proyecto” en este ejemplo, el Riesgo General del Proyecto Post Plan es de impacto moderado.

15-¿Qué es Gestión de Configuración? Enumere las causas que exigen el uso de Gestión de Configuración.

La Gestión de Configuración, en inglés (GCS), Software Configuration Management (SCM es un conjunto de actividades diseñadas para identificar y definir los elementos en el sistema que probablemente cambien, controlando el cambio de estos elementos a lo largo de su ciclo de vida, estableciendo relaciones entre ellos, definiendo mecanismos para gestionar distintas versiones de estos elementos, y auditando e informando de los cambios realizados.

El propósito es establecer y mantener la integridad de los productos de software a través del ciclo de vida del proceso de sw.

GCS/SCM trata y controla:

La elaboración del código fuente por varios desarrolladores simultáneamente.

El seguimiento de las versiones y sus cambios. La conducción de la integración de las partes del software, en un

solo producto de software.

Las causas que exigen la configuración de software pueden ser las siguientes:

Los requerimientos del sistema siempre cambian durante su desarrollo y su uso, y se tienen que incorporar estos requerimientos en nuevas versiones del sistema.

Se necesita saber lo que se ha cambiado en el sw. Los cambios incontrolados en un proyecto de sw lo llevan al

fracaso.


16-Dentro de la Gestión de Configuración:

¿Qué tipos de ítem pueden estar bajo control?

Se pueden controlar los siguientes tipos de ítem en la Gestión de Configuración, entre otros es posible saber:

Lo que se ha cambiado en el sw. En qué, el artefacto software (puede ser un sistema entero)

difiere de otras instancias del mismo artefacto. La revisión, es decir en cuál versión un artefacto (puede ser un

sistema sw) tiene por objetivo reemplazar a una o más versiones anteriores, (ejemplo, Windows 7 es una revisión de Windows Vista).

Las variantes, es decir la versión de un artefacto (puede ser un sistema sw), que se añaden a las versiones existentes sin reemplazarlas (ejemplo, Windows Phone es una variante de Windows)

Los cambios en los ítems de configuración, es decir en el Artefacto o conjunto de artefactos en las distintas versiones (ejemplo, diagrama de clase, código de una clase, archivo.jar).

La configuración de un sistema sw, en el cual sus artefactos poseen diferentes versiones (tanto revisiones como variantes. Esdecir saber de qué versión se ha seleccionado cada artefacto perteneciente al sistema.

La línea base, es decir conjunto de versiones concretas de los diferentes ítems de configuración, que constituyen un estado significativo y claramente identificado en la evolución de un producto (ejemplo, primer prototipo para pruebas reales, primer documento estable de requisitos).

La Traza, o sea la relación existente entre dos ítems de configuración (ejemplo, un requisito y las clases que lo implementan, una clase y sus casos de prueba).

La Trazabilidad Software, la creación y gestión de trazas entre sujetos a evolución (ejemplo, ligar requisitos con artefactos de diseño y código más casos de prueba).

¿En qué consiste el Control de Cambios?


Consiste en controlar los cambios mediante un adecuado procedimiento, utilizando el Plan para la Gestión de Configuraciones, ajustándose porejemplo a la norma (IEEE 823-1998) utilizando las herramientas adecuadas para tal fin, dichas herramientas puede ser la Matriz de Trazabilidad, el diagrama de organización de los archivos relacionados con el proyecto, el diagrama de identificación de versiones numeradas, la identificación de los atributos de las versiones, árboles de características, la tabla de gestión de cambios,la herramienta de proceso check-in/check-out (en donde se muestra el origen de un problema, y se diagraman los distintos tipos de solución), la herramienta soporte para auditorías, etc. Es decir que incluye el control de calidad a través de organigramas, procedimientos, herramientas, y la planificación temporal.

¿En qué consiste el Control de Versión?

Consiste en:

Saber que versión tiene cada cliente. Qué requisitos sw y hardware requiere cada versión. Qué parches están asociados a cada versión. Cuántas versiones usan un determinado artefacto. Qué diferencias funcionales hay entre dos versiones específicas.

¿En qué consiste el Control de Configuración?

El control de configuración es el proceso utilizado para chequearque el proyecto se esté desarrollando dentro del marco legal y organizacional requerido.

Mediante este control se verifica que cada integrante del equipo del proyecto esté trabajando de acuerdo al organigrama y cumpliendo con las responsabilidades que le corresponden de acuerdo a su rol.


Establece el control de que se estén desarrollando correctamente el flujo de trabajo y los procedimientos.

Control de la calidad en general.

17-Por qué se dice que el SW es NOT SILVER BULLET? Busque el artículo y realice un resumen de una página.

Sin haber leído el artículo en Wikipedia, el cual lo tengo en la ventana del navegador, listo para “digerir”, apenas mirando el título y ya ahora con la ventana oculta, jugando un poco a las adivinanzas, para hacer más agradable esta larga tarea, se intuye que es atenido a como “matar” los errores de sw. Y lo de plata quizás sea haciendo alusión al “Llanero Solitario”, el cowboy que montando su caballo tordillo o blanco (cuando era gurí iba a la escuela en “La Mangra”, una yegua tordilla, y me gustaba mucho leer las historietas del Llanero, y sus inseparables, caballo “Plata”, y amigo “Toro”), el Llanero Solitario (que paradoja su nombre, si era el único héroe acompañado de las historietas de cowboy que leía) utilizaba balas de plata!; ¿será que estamos presenciando el retorno?, o simplemente una fábula creada por la mente; en el acierto o el error esta introducciónserá mantenida.

Pasemos a la respuesta concreta:

Es un documento sobre ingeniería de sw, muy discutido, escrito por Fred Brooks en 1986. Brooks argumenta que “no hay un simple desarrollo en tecnología o técnica de gestión, que por sí solo prometa una mejora en la productividad, fiabilidad, simplicidad un orden de magnitud dentro de una década”.

También afirma que, en el desarrollo de sw “no podemos esperar siquiera ver una ganancia del doble cada dos años”, como la que habría en el desarrollo del hardware”.Brooks marca las diferencias entre los que es una complejidad accidental y una complejidad esencial y afirma que la mayoría de los ingenieros de sw de la actualidad están dedicados a lo esencial, así que reducir todas las actividades accidentales a cero no dará una mejora de un orden de magnitud. Brooks considera que hay que abordar


las partes esenciales del proceso de software, e insiste que no hay ninguna “bala de plata”, pero cree en una serie de innovaciones atacando la complejidad esencial podría conducir a importantes mejorasen la ingeniería de sw (tal vez mayor que diez veces en un período de diez años).

Lo principal del argumento es la diferencia entre la complejidad accidental y la complejidad esencial. La complejidad accidental se refiere a los problemas que generan los propios programadores y que pueden corregirse, por ejemplo los detalles de escribir y optimizar elcódigo en lenguaje ensamblador o los retrasos causados por los procesamientos por lotes.

La complejidad esencial es causada por el problema a resolver, y nada puede eliminarla. Si el cliente desea un programa para implementar 30 casos de uso diferentes, es esencial que el programa implemente esos 30 casos para satisfacer lo que necesita el cliente. En el tiempo de Brooks una tecnología que había hecho mejoras sustantivas en el área de complejidad accidental fueron los lenguajes de alto nivel, como Fortran, en ese tiempo. Lenguajes de hoy como C, C++, C# y Java son considerados como mejoras, pero no del mismo orden de magnitud que Fortran. El programa de alto nivel libera al programa de la mayor parte de su complejidad accidental.

Nota: en nuestra introducción me he equivocado en el juego de la adivinanza, pues bala de plata, refería a la bala mágica que podía aniquilar al hombre lobo (el “bug”).

Ejercicio punto de función y cocomo

1-Ventas de libros por e-mail

Requerimientos

R1.El sistema debe mantener la lista de todas las órdenes de libros realizadas por los clientes.


R2.El sistema debe mantener una lista de nombres y direcciones de todos los clientes de lalibrería, y aceptar las siguientes modificaciones a la misma:

– Inscribir nuevos clientes– Cancelar inscripciones– Cambiar una dirección– Cambiar un nombre– Registrar una orden de libros

R3.El sistema debe informar al departamento de inscripciones sobre todas las órdenes de libros, para garantizar que las consultas de los clientes se manejen adecuadamente.R4.El sistema debe registrar las nuevas órdenes de libros por parte delos clientes, y la cancelación de órdenes previamente registradas.R5.Cuando se requiera, el sistema debe proporcionar la siguiente información acerca de las órdenes:

– Lista de libros ordenados en un periodo de tiempo determinado.– Lista de libros ordenados actualmente publicados por una cierta

editorial.– Lista de libros ordenados por un cliente.– Número de ejemplares ordenados de un determinado libro

R6.El sistema debe mantener el inventario actual de libros, y permitirlos siguientes cambios:Ingreso de X ejemplares del libro Y.Remoción de X ejemplares del libro Y.Orden pendiente de X ejemplares del libro Y.R7.El sistema debe permitir en cualquier momento, registrar una orden de compra para un número cualquiera de ejemplares de cualquier libro.R8.El sistema debe mantener la lista de órdenes de compra y ser capaz de imprimir dicha lista cuando ésta se requiera.R9.El sistema debe mantener una lista de editoriales junto con los libros que estas publican. Deben ser posibles las siguientes modificaciones a dicha lista:

– Agregar una editorial.– Agregar un nuevo libro.– Eliminar un libro.– Eliminar una editorial.

R10.El sistema debe registrar información sobre los pagos realizados por los clientes.


R11.El sistema debe generar una factura de compra para un cliente, cuando ésta se solicite.

Definir:1. Entradas2. Salidas3. Almacenamientos lógicos4. Interfaces5. Consultas6. Cálculo: Puntos sin ajuste

Simple Promedio Complejo

Simple Promedio Complejo Total

Entradas * 3 * 4 * 6Salidas * 4 * 5 * 7Almacenamientos * 7 * 10 * 15Interfaces * 5 * 7 * 10Consultas * 3 * 4 * 6

Total de puntos sin ajustar (PSA) = 141

7. Cálculo Puntos de complejidad de procesamiento

Punto de Complejidad Valor 0-5Comunicación de datos 4Actualización en línea 4Servicios distribuidos 5Procesamiento complejo 2Desempeño 2Reusabilidad 5Ambiente de uso sobrecargado 3Facilidad de instalación 4Rata de transacciones 4Facilidad de operación 4Entrada de datos en línea 4Múltiples lugares de operación 5


Eficiencia del usuario final 5Facilidad de modificación 5

Total de puntos de complejidad de procesamiento (PCP) = 56

8. Cálculo del Resultado final

Factor de complejidad de procesamiento (FCP):

FCP o VAF = 0.65 + (0.01 x PCP) = 0.65 + (0.01 x 56 ) = 1,21

Total de puntos de función (FP):

FP = PSA x FCP = 141 x 1,21 = 170,61

El ejercicio fue resuelto en planilla Excel adjunta en la carpeta de la actividad.

Complete los datos y aplique COCOMO II para estimar el proyecto

Ejercicios de Planificación de Proyecto1-Para informatizar una empresa, se ha decidido llevar a cabo las tareas que se muestran en la siguiente tabla


Tarea Descripción Esfuerzo(días)

Tipo Brooks

Recursos Siguea:

A Estudio Viabilidad 2 1 2 Analistas -B Análisis sistema

actual6 1 2 Analista A

C Observación sistema

2 2 2 Analistas A

D Localizar ERP 1 2 1 Analista AE Negociar ERP 1 2 1 Director C,DF Doc.

Especificidades observ.

8 1 2 Analistas C

G Definir procesos empresa

3 1 1 Analista B

H Definir datos control

4 1 2 Diseñadores

B

I Documentar pruebas 9 1 3 Diseñadores

E, G,H

J Documentar adaptación ERP

2 1 2 Diseñadores

E, F

K Adaptar ERP 12 1 4 Programadores

H, J

L Probar ERP 2 1 1 Analista I, K

Se ha de tener en cuenta que todas las tareas se realizarán tan prontocomo sea posible. Deseándose conocer el plazo mínimo de realización del trabajo (Diagrama de Precedencias, de Gantt, y Camino Critico). Obtener para cada tarea los inicios y finales tempranos y tardíos.

El plazo mínimo para realizar el rebajo son 28 días. El camino crítico es (A,C,F,J,K,L).


El diagrama de precedencias además de encontrarse en la siguienteimagen hecha en Microsoft Vicio está en el archivo Microsoft Proyect 2010 “Ejercicio de Planificación de Proyecto_ Fredy Gonzalez” que se adjunta, al igual que Gantt.

Los tiempos tempranos y tardíos se encuentran en la imagen siguiente hecha en Microsoft Vicio.

En la figura anterior, es el diagrama de precedencia, en donde se muestran los tiempos tempranos y tardíos, y el camino crítico (sucesión de tareas con holgura=0.

2 /3-A una empresa se le contrata un test independiente de una aplicación ya desarrollada. La planificación inicial que se propone es la siguiente.

Tarea

Descripción Esfuerzo (mes)

Cantidad personas

Perfil Profesional

Tipo Brooks

Siguea:

A Estudiar sistema 2 1 Analista 1 -B Identificar puntos débiles 2 2 Analista 1 AC Identificar Operaciones

habituales3 2 Analista 2 A

D Identificar Tiempos de respuesta requeridos

4 2 Analista 1 A


E Documentar puntos débiles 1 1 Analista 2 BF Preparar pruebas

operaciones habituales4 2 Diseñado

r1 C, D,E

G Preparar pruebas puntos Débiles

1,5 1 Diseñador

1 E

H Pruebas 4 2 Programador

1 F, G

El diagrama de precedencias de este proyecto, es el que se muestra a continuación:


B 1,0

E 1,0

2,0

3,0

3,0

4,0

G 1,5

3,0

4,0

4,0

5,0

4,0

5,5

2,0

1,0

2,0

1,0

5,5

7,0

3,0

1,5

A 2,0

C 3,0

F 2,0

0,0

2,0

2,0

5,0

5,0

7,0

0,0

2,0

2,0

5,0

5,0

7,0

2,0

0,0

3,0

0,0

2,0

0,0

H 2,0

7,0

9,0

D 2,0

7,0

9,0

2,0

4,0

2,0

0,0

3,0

5,0

3,0

1,0

2-Dada la planificación mostrada, se desea el estudio económico del mismo, siendo los costos mensuales, en $: Analista: 6000; Diseñador 6000; Programador 5000 La empresa cobrara el Proyecto $ 350.000 al finalizar “Preparar

pruebas operaciones habituales”. La tasa de interés es del 3% mensual.

Se pide calcular los diagramas de cargas de los recursos, el Gantt, el flujo de caja y el acumulado, tanto actualizados como sin actualizar. Agregar una gráfica de estos.


Los cálculos para este ejercicio se encuentran en el archivo Excel: “Ejercicio 2 de Plan de Proyecto_ Fredy Gonzalez” que se adjunta en lacarpeta de la presente actividad.

3-Dado el siguiente proyecto, suponga que la empresa consigue de otra empresa un analista más, 1 diseñadores y dos programadores, a lo largodel presente proyecto, pero a un costo superior al propio. Dado que hay que evitar tener más personal y gastos de los necesario, pero minimizando la duración del trabajo, reorganice la planificación. Se ha de reconstruir el diagrama de precedencias con las fechas tempranasy tardías de inicio y fin de cada tarea, el diagrama de Gantt, además de indicar las modificaciones realizadas.

Si para hacer una tarea tarea X un analista demora un tiempo t=t1, entonces dos analistas demoran t=t1/2 y tres analistas demoran t=t1/3.Eso siempre y cuando no haya sinergia en el sistema, ni positiva ni negativa.

Con el mismo razonamiento anterior se continuará para un diseñador o un programador indiferentemente.

La empresa aumentará el número de trabajadores desde el principio del proyecto, pues sino sucederá la ley de Brooks, retrasándose aún más elproyecto.

Tomándose el proyecto del ejercicio anterior, como “el siguiente proyecto” se tendrá:

Se tomará que en la primera planificación se contaba con los recursos mínimos necesarios, ni menos, ni más.

Si únicamente se contara con dos analistas en la planificación inicial, estos recursos estarían sobreasignados para cumplir con las tareas C, D y E simultáneamente. Ya que resulta que tomando un jornal de 8 hs se necesitarían 6 analistas para realizar las


mismas. Por lo tanto supondremos que la empresa ya cuenta con 6 analistas propios.Para cumplir con las tareas F y G se necesitan tres Diseñadores, que también supondremos que la empresa ya cuenta para cumplir conel primer plan.Para realizar las otras tareas en los tiempos planificados es suficiente con dos programadores.

Resumiendo:

Los recursos de la primera planificación debían ser:

6 analistas 3 diseñadores 2 programadores

Las tareas A,. B, C, D y E son las que requieren analistas.

Las tareas F y G son las que requieren diseñadores

La tarea H requiere programadores

Con el nuevo programa se agrega:

1 analista

1 diseñador

2 programadores

Nuevos tiempos para las tareas

Para facilitar, los cálculos se realizarán en el archivo Excel “Cálculo de los nuevos tiempos de las tareas”, que se adjunta en la carpeta.


El diagrama de precedencia para los nuevos tiempos es el siguiente (elmismo se encuentra hecho en programa M. Visio en la carpeta de la actividad):


Documents

Z41 GPI II AO1 Gonzalez Fredy