Administracin de Proyectos Simen Clase Ulloa

Unidad 2
Jeltssin Martnez 2011-2456 Katerina Hernndez 2011-2471 Mara Elena Morillo 2011-0930 Samuel Generoso Pena Luciano 2009-0426 Sherley Suarez 2011-2340 Samuel Aurelio 2011-2461

03 de octubre de 2013

Cada proyecto cuenta con mltiples partes interesadas: las personas interesadas en el resultado del proyecto. El propsito de la revisin de los principales hitos es lograr una comprensin comn de la situacin del proyecto. Los clientes, usuarios, arquitectos e ingenieros de sistemas, desarrolladores, personal de mantenimiento, los inversionistas y los reguladores tienen diferentes preocupaciones. Ser un set de documentos o la presentacin material de comunicacin eficaz a todos ellos? Estn todas las partes interesadas va a ser capaz y est dispuesto a escuchar el material necesario para la comprensin de todos los dems grupos de inters? En un proyecto complejo, es muy poco probable que un formato de presentacin proporcione la comprensin deseada por todos. En los das de desarrollo en cascada, comentarios largos ceremoniales eran la norma. Todo el da e incluso presentaciones de varios das eran comunes. Al final de las revisiones, se distribuyeron las hojas de aprobacin oficial. No es sorprendente que las firmas eran bastante fciles de obtener, pero el entendimiento de que significaban pocas veces sucedi. La sobrecarga de informacin es generalmente el problema. Directores de proyectos Adepto aprendieron a mantener informados a los interesados y educados durante toda la vida del proyecto y la integracin de la comunicacin de los requisitos necesarios del proyecto, el diseo y la entrega de documentacin. En el momento de la revisin hito , los interesados podran entonces ser informados suficientemente bien que el examen podra servir para comprobar el progreso de un proyecto de plan y para discutir los problemas que haban surgido que afect a mltiples partes interesadas. El director del proyecto tuvo y tiene la responsabilidad primordial de velar por que la informacin correcta se comunica a los interesados en el momento apropiado. Los hitos del proyecto por lo general ocurren en los extremos fases (creacin, elaboracin , construccin y transicin ) . Las grandes empresas tendrn probablemente estndares para dichos exmenes. Las pequeas empresas pueden utilizar las directrices para el examen descritos en Royce u obtener directrices offthe -shelf . Opiniones Milestone incluirn la evaluacin de los resultados de una fase y decidir qu se va a hacer en el prximo. Pero no se puede enfatizar lo suficiente que es la comunicacin entre las partes interesadas entre los hitos que permite un verdadero acuerdo que debe alcanzarse en los exmenes por hitos. Propios hitos deben ser utilizados para demostrar pblicamente el trabajo realizado hasta la fecha. Opiniones de los documentos en papel solo fuerza ni demuestran terminaciones - ni se agregan a los modelos conceptuales de los distintos grupos de inters. (Muchos gerentes de proyecto afirman que se obtiene lo que inspeccionar.) Opiniones de estado se llevan a cabo con ms frecuencia que las crticas hito y se concentran en el progreso con el plan. El uso secundario de un plan para controlar

si todo ha sucedido como estaba previsto y prescrito por el plan, tanto la puntualidad de las entregas y la aplicacin de los nmeros especificados de personal a las tareas. Los proyectos exitosos tienen relativamente bajo revisin y sobrecarga de estado, debido a que el director del proyecto ha diseado su conjunto de artefactos y mecanismos de informacin para que el trabajo se integre en el trabajo normal del proyecto. El error ms comn que los jefes de proyecto inexpertos hacen es recoger demasiada informacin. Al no tomar decisiones por adelantado sobre qu informacin es importante, la carga area se incrementa, y la conceptualizacin de todos los niveles de lo que est sucediendo es mucho ms difcil. Un gerente de proyecto debe tener la informacin de estado casi siempre disponibles y hacer revisiones peridicas de los diez riesgos del proyecto. Comentarios de riesgo son una disciplina necesaria y es muy rentable, con relativamente poco esfuerzo. Un cambio en los diez principales riesgos es generalmente una seal de reevaluar el plan actual. Al igual que en muchas reas de desarrollo de software, el verdadero experto puede producir una, simple abstraccin significativa en lugar de detalles confusos. El nivel de resumen de los planes de proyectos e informes de estado debe ser fcil de comprender.

Los modelos de proceso le indican los pasos a realizar y el orden en que deben realizarse. Desde la dcada de 1970 en adelante, los administradores y diseadores de procesos han intentado varios mtodos para tratar de " curar" a los problemas asociados con el modelo de cascada. Es importante recordar que el deseo del usuario para mayor funcionalidad y la complejidad de los sistemas han aumentado considerablemente cada ao y adems, que la ingeniera de software es un rea relativamente nueva, comenzando como lo hizo al final de la Segunda Guerra Mundial. Dadas estas realidades, qu problemas se han atribuido a la modelo en cascada? Los problemas tpicos son largos tiempos para la entrega, malentendidos en lo que iba a ser entregado y las dificultades para mantener los requisitos estables en el transcurso de un proyecto. En vista de que la complejidad del sistema siempre aumenta y la tecnologa nunca se detiene , no es de extraar que los usuarios finales y desarrolladores de sistemas a menudo tengan mal entendido entre s acerca de lo va a ser desarrollado. Como la complejidad del sistema aumenta, la capacidad de los usuarios para visualizar lo que un sistema iba a hacer esto se convirti en un problema. As que los programadores desarrollaron una tcnica llamada de prototipos o muestra a los usuarios, una interfaz de un sistema con algunos detalles internos simuladas. Esta fue una manera larga para ayudar a los usuarios a visualizar sistemas complejos, pero crea otros problemas. Prototipos (que se apresur a poner juntos) tienden a convertirse en la base de los sistemas que se desarrollaron en realidad, el prototipado rpido en ocasiones lleg a ser prototipos " rabioso " y " cdigo espagueti " (es decir, cdigo que es largo, no muy bien estructurado , y duro de

entender) se hizo ms incomprensible y enredado que nunca. Adems, no haba manera de incorporar la creacin de prototipos de forma inteligente en los modelos cascada, ya que el modelo no permite que se remonte ms de una fase de diseo aplicando los descubrimientos realizados en las fases posteriores. La culminacin de una serie de procesos experimentales fue modelo en espiral de Barry Boehm, creada en 1987 y se muestra a continuacin. La filosofa de Boehm era hacer iteraciones sucesivas de un proyecto, atacando las partes menos conocidas ( arriesgada") primero. Se dio cuenta de que no tena mucho sentido para documentar lo que estaba ya bien conocido o analizar los problemas con soluciones conocidas. (El modelo Cascada requiere de documentacin y anlisis para hacer de manera uniforme y cmodas las partes del sistema, as como las partes duras.) En esencia, Boehm aplica la regla 80/ 20, utilizando su influencia para aplicar los recursos de manera ms productiva. Aunque esto parece ser una cosa obvia a hacer, en la prctica se requiere una gestin capaz y juicio practicado. En lugar de tener el proceso te diga qu hacer, debe evaluar el sistema en particular a la luz de la experiencia de las personas en el proyecto. Cada "espiral " es realmente una cascada en miniatura, que se aplica de forma selectiva a porciones seleccionadas del proyecto. Los dos primeros ciclos de la modelo en espiral (creacin y elaboracin) son aquellos en los cuales se crea la visin arquitectnica. Estos dos ciclos comprenden la etapa de ingeniera, y un nfasis en la investigacin y el anlisis es apropiado en este caso. Ms tarde los ciclos son las etapas de produccin (construccin y de transicin). La clave para el xito del proyecto, sin embargo, es la visin compartida desarrollado a travs de las dos primeras iteraciones. Si esa visin es lo suficientemente coherente y es analizada lo suficientemente bien como para ser estable, hay muchas opciones disponibles para las ltimas fases de equilibrio, por ejemplo, hacer "espirales " en paralelo. Una versin mucho ms sencilla del modelo de espiral se muestra en Royce, pgina 75, Figura 5-1. Las fases del ciclo de vida tradicionales (anlisis de requerimientos, especificacin, diseo, implementacin, prueba y entrega) se funden en un marco diferente: 1. creacin, que abarca el anlisis de requerimientos y especificacin 2. elaboracin, que ms o menos asigna a dicha fase, aunque algunas actividades de especificacin y aplicacin (por ejemplo, creacin de prototipos) falla en el diseo de esta fase 3. la construccin, que incluye la aplicacin y el ensayo del producto 4. transicin, que se corresponde con el despliegue del producto en el dominio del usuario final (entrega) Tenga en cuenta que las "espirales" cada vez son ms grandes. Esto es as porque, al igual que una bola de nieve rodando por una colina, el esfuerzo de desarrollo recoge el peso a medida que avanza. Es decir, a medida que se desarrolla el cdigo y las estructuras se construyen, el esfuerzo posterior se debe tener en cuenta, y los procesos de gestin, tales como la gestin de la configuracin vuelven ms lento. La comunicacin entre los miembros del equipo tambin se vuelve ms compleja, y la

adicin de nuevas personas al equipo de desarrollo se hace ms difcil debido a la "historia" que tiene que intervenir antes de que puedan ser productivos.

Si nos fijamos en los documentos finales producidos en un proyecto de desarrollo de software, no es inusual confundirse acerca de lo que realmente sucede en las fases iterativas. Una de las ventajas de la utilizacin de tcnicas de modelado de objetos es que las mismas tcnicas (objetos, modelos funcionales y dinmicos) se pueden utilizar en una gran ventaja, pasando de un alto nivel de abstraccin a un nivel muy prximo al cdigo que finalmente se produce. Pero si nos fijamos en los diagramas de fase temprana del proceso, se puede (y debe ser) muy diferentes de los modelos finales El propsito de todos los artefactos es comunicar algn aspecto del diseo del sistema para los distintos grupos de inters: la alta direccin, los usuarios finales y el equipo de diseo. Dado que todos estos actores tienen diferentes modelos conceptuales de lo que la funcin del sistema servir, los conjuntos de artefactos estn diseados para satisfacer las necesidades de cada grupo de actores involucrados. El nivel de detalle o abstraccin es muy diferente si se trata de un alto directivo que con un usuario final. Tan importante como el nivel de detalle y la informacin transmitida por un artefacto son el momento y la manera en que se produce ese artefacto. La produccin de documentacin despus de que se desarroll un sistema puede ayudar a aquellos que den el mantenimiento del sistema, pero no ayuda a los que estn desarrollando el sistema. Un enfoque disciplinado para la conceptualizacin del sistema de artefactos bien elegidos, junto con las revisiones de los documentos y el producto entregado, son esenciales para lograr la participacin y la aceptacin de todas las partes interesadas. Para ser eficaz la creacin de los diversos conjuntos - el conjunto de la gestin de artefacto, el conjunto de requisitos, la escenografa, el conjunto de la implementacin y el despliegue de la configuracin deben estar integrados en el proceso de desarrollo y se utiliza realmente. Las buenas prcticas de ingeniera de software subrayan con razn la trazabilidad de los documentos (incluido el cdigo) de los requisitos en el cdigo probado, pero los modelos de intervencin sirven un propsito an ms importante que lo que la trazabilidad. Todos los modelos, desde el proceso de planificar el diseo, nos permiten razonar sobre el sistema que se construir mediante la abstraccin de los elementos importantes.

Toda arquitectura de software debe describir diversos aspectos del software. Generalmente, cada uno de estos aspectos se describe de una manera ms comprensible si se utilizan distintos modelos o vistas. Es importante destacar que cada uno de ellos constituye una descripcin parcial de una misma arquitectura y es deseable que exista cierto solapamiento entre ellos. Esto es as porque todas las vistas deben ser coherentes entre s, evidente dado que describen la misma cosa. Cada paradigma de desarrollo exige diferente nmero y tipo de vistas o modelos para describir una arquitectura. No obstante, existen al menos tres vistas absolutamente fundamentales en cualquier arquitectura: * La visin esttica: describe qu componentes tiene la arquitectura. * La visin funcional: describe qu hace cada componente. * La visin dinmica: describe cmo se comportan los componentes a lo largo del tiempo y cmo interactan entre s. Las vistas o modelos de una arquitectura de software pueden expresarse mediante uno o varios lenguajes. El ms obvio es el lenguaje natural, pero existen otros lenguajes tales como los diagramas, los diagramas de flujo de datos, etc. Estos lenguajes son apropiados nicamente para un modelo o vista. Afortunadamente existe cierto consenso en adoptar UML (Unified Modeling Language, lenguaje unificado de modelado) como lenguaje nico para todos los modelos o vistas. Sin embargo, un lenguaje generalista corre el peligro de no ser capaz de describir determinadas restricciones de un sistema de informacin (o expresarlas de manera incomprensible). ARTEFACTOS DE UN PROCESO En el modelo de espiral, las primeras iteraciones se dirigen hacia el descubrimiento y el perfeccionamiento de la arquitectura, que d estabilidad a las fases posteriores (construccin y transicin). Las actividades son elegidas para mitigar el riesgo y maximizar la contribucin del personal disponible.

A primera vista, los procesos modernos de los flujos de trabajo puede parecer muy desordenado y, tal vez, incluso un poco incomprensible. El modelo de cascada es al menos ordenado. Sin embargo, el modelo de cascada era una abstraccin no muy precisa de lo que realmente estaba pasando. A pesar de que el modelo de la naturaleza segmentada del desarrollo de sistemas de esa poca, los lmites entre las fases eran raramente tan ntido como el modelo decret. Los gerentes efectivos

de proyectos tienden a permitir que las fases se solapen. Actividades de desarrollo de los sistemas de hoy en da no se correlacionan perfectamente con las fases en cascada. Muchas cosas estn sucediendo al mismo tiempo y la estructura del diseo de los sistemas contemporneos no se asigna conceptualmente al modelo lineal del desarrollo. En estos modelos del proceso de desarrollo moderno, se puede ver por qu el papel del gerente de proyecto tiene mucho que ver con el xito o fracaso del proyecto. Cada fase requiere decisiones sobre las tareas para hacer frente a otro y lo prototipo para construir. El gerente y los diseadores del proyecto tendrn que decidir si prototipos horizontales o verticales sern ms eficaces para mitigar el riesgo del problema en cuestin. Las decisiones se toman sobre la base de los riesgos inmediatos percibidos en el sistema. Es en esta rea es que la gestin de proyectos se hace de especial valor tcnico, es decir en un proyecto se requiere de mucho criterio tcnico. Aunque existen listas de comprobacin de los elementos a tener en cuenta, la decisin final depende de las compensaciones y las evaluaciones de las personas, la tecnologa y la sofisticacin proceso en cuestin.