Planificación y Organización de Proyectos dirigidas por la Arquitectura

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Planificación y Organización de Proyectos dirigidas por la Arquitectura"

Transcripción

1 Planificación y Organización de Proyectos dirigidas por la Arquitectura Dirección postal: Universidad ORT Uruguay Facultad de Ingeniería ORT Software Factory Cuareim Montevideo, Uruguay. Teléfono Dirección electrónica: Resumen M.C. Mariel Feder Laboratorio de Ingeniería de Software. Universidad ORT Uruguay. Gestionar un proyecto de software, consiste en asegurar que se entregará un producto que cumpla con las especificaciones dentro del plazo y costo acordados, con el nivel de calidad pactado. Factores clave para lograrlo son la planificación y organización adecuadas del proyecto. Por otra parte, la definición de la arquitectura del producto a desarrollar tiene un impacto muy importante no sólamente en el producto final del que es base, sino que también debería influir en la forma en que el proyecto se enfoca desde el punto de vista de su gestión, facilitando así la integración de las disciplinas técnicas y gerenciales que deben interactuar en todo proyecto exitoso. El objetivo del presente trabajo es analizar la fase de planificación y organización del proyecto y ver cómo la misma se ve afectada por la arquitectura, o mejor dicho, se ve pautada por ésta en forma natural, en lo que se podría denominar planificación y organización dirigidas por la arquitectura. Palabras claves Ingeniería de Software, Gestión de Proyectos, Arquitectura de Software, Planificación, Organización.

2 1. INTRODUCCIÓN 1.1. Qué es la Gestión de Proyectos Gestionar un proyecto consiste en asegurar que se entregará un producto que cumpla con las especificaciones dentro del plazo y costo acordados, con el nivel de calidad pactado i. Generalmente, los proyectos de software se desarrollan en un mundo de naturaleza cambiante, lo que implica un nivel importante de incertidumbre relacionada a aspectos tales como recursos humanos, tecnología o de negocio. Las actividades involucradas en la gestión de un proyecto van variando a lo largo del proceso de desarrollo del ciclo de vida del proyecto 1 en relación directa con el proceso de desarrollo utilizado. ii Más allá de las particularidades de los proyectos individuales, en su gran mayoría los proyectos evolucionan según el siguiente ciclo de vida: Inicialización: Es el momento en que se reconoce que un proyecto puede comenzar y se consiguen los compromisos para hacerlo. Las principales actividades de esta fase son: - Análisis de las consecuencias de realizar (o no realizar) el proyecto. - Definición de las magnitudes necesarias para completarlo. 2 - Análisis de alternativas - Análisis técnicos tales como análisis de viabilidad, materiales disponibles, recursos geotécnicos, urbanísticos, de impacto ambiental, etc., dependiendo de la naturaleza del proyecto. - Análisis de la inversión, volumen, valor presente, rentabilidad futura. - Análisis costo/beneficio, incluyendo costos sociales, beneficios no monetarios, etc. - Análisis de riesgo, con la información de que se dispone hasta el momento. 3 Planificación y Organización: Confeccionar y mantener un esquema de trabajo que permita alcanzar el objetivo. Es en esta etapa en la que se identifican las tareas, se estiman tiempos y costos, se conforman los equipos, se asignan los recursos (humanos y otros) y se elabora el plan de trabajo. Debe señalarse que este no es el único momento del proyecto en que se realizan tareas de organización y planificación. Generalmente, la organización y planificación iniciales del proyecto se realizan con un alto nivel de abstracción, por lo que luego se repite la actividad para definir estos elementos con un nivel mayor de detalle a medida que se va avanzando en el proyecto. Producción o Implementación: Durante esta fase se realizan tres grandes actividades: Administración: coordinación de personas y recursos para llevar adelante el plan Ejecución: la propia realización de las tareas que generan el producto Control: Controles para asegurar que los objetivos del proyecto son alcanzados, mediante monitoreo y medición de avance, tomando las acciones correctivas que correspondan. Este seguimiento permite retroalimentar la planificación, por lo que se vuelve un proceso abierto y cíclico. Estas mediciones se realizan tanto del proyecto como de las características del producto que se va generando. Cierre: Formalización de la aceptación del proyecto y realización del fin de actividades en forma ordenada. Se da por concluido el proyecto y se obtiene el producto final. La información obtenida se almacena y se evalúan los resultados. 1 Me refiero al Ciclo de Vida del proyecto a diferencia del Ciclo de vida del desarrollo del producto que se explicará más adelante. 2 Nótese el uso del término magnitud en lugar de valor, ya que en este momento se pretende una aproximación que refleje el orden de magnitud de los elementos a estimar. 3 Volveré sobre este tema más adelante.

3 Planificación general Inicio Planificación específica Planificación Administración Ejecución Control Retroalimentación Producción Etapas en la gestión de un proyecto 1.2. Qué es la Arquitectura del Software La arquitectura de software es una disciplina relativamente joven, por lo que no existe aún una definición del término única y ampliamente aceptada. No es el objetivo del presente trabajo adentrarnos en este tipo de discusión filosófica, ya que si bien las distintas definiciones formales aún pugnan entre sí en el mundo académico, el concepto que está detrás es básicamente similar entre todas ellas. Tomaré como definición la propuesta por Bass, Clements y Kazman: La arquitectura de un programa o sistema de computación es la estructura o estructuras del sistema, que comprenden sus componentes de software, las propiedades externas de los componentes, y la relación entre ellos iii, que coincide con la propuesta por Soni, Nord y Hofmeister iv 1.3. Ciclo de vida del desarrollo del producto El ciclo de vida es una vista del orden de las actividades que ocurren durante el desarrollo. Así, el software progresa desde una idea inicial a través de su implementación, uso y eventualmente su muerte v. Un ciclo de vida describe las principales fases del desarrollo y las principales actividades que se espera se realicen durante estas fases. Ayuda a los gerentes a realizar el seguimiento del proyecto y provee de un marco para la definición del proceso de desarrollo detallado. Cascada El primer ciclo de vida, la cascada fue definido por Winston Royce vi en los comienzos de los años 70. Desde entonces, muchos equipos de desarrollo han seguido este modelo. En los últimos 10 o 15 años la cascada ha sido muy criticada por ser considerada muy rígida para el desarrollo de los proyectos de software modernos. El modelo es muy simple, y considera al desarrollo como una secuencia de fases que no se repite. Cada fase tiene un conjunto definido de objetivos, y las actividades de una fase se realizan para la consecución de los mismos. Las normas de la cascada son básicas: Requerimientos Arquitectura Diseño Codificación y testing unitario Integración Diseño Codificación y testing unitario Integración Requerimientos Arquitectura Diseño Codificación y testing unitario Integración Ciclo de vida en Cascada Operación y Mantenminiento Operación Operació Ciclo de vida de desarrollo incremental

4 Planificar el proyecto antes de comenzar Definir el comportamiento externo esperado del sistema antes de definir su funcionamiento interno. Documentar los resultados de cada actividad Diseñar el sistema antes de codificarlo Testear el sistema una vez que está construido. Desarrollo incremental Los riesgos asociados con sistemas grandes y complejos son muy altos. Una forma de reducir el riesgo es construyendo solamente una parte del sistema y reservar el resto para sucesivas liberaciones. El desarrollo incremental vii plantea la construcción de partes del sistema en forma secuencial, de forma de ir liberando y probando versiones en forma paulatina. Generalmente, se parte de la lista de requerimientos de todo el sistema y de una definición de la arquitectura de alto nivel que contempla todos estos requerimientos, y luego se divide la funcionalidad en grupos que se van diseñando, implementado, testeando e integrando uno a uno. Modelo Evolutivo Como el desarrollo incremental, el modelo evolutivo viii construye una serie sucesiva de versiones incluyendo en cada una de ellas más funcionalidad que en la anterior, hasta completar el sistema. La diferencia es que no se conocen a priori todos los requerimientos, sino que los mismos se van descubriendo en cada una de las evoluciones. Por lo tanto, tampoco existe una arquitectura de alto nivel definida desde el principio, sino que la misma va evolucionando hacia la arquitectura final. En este modelo, los requerimientos son analizados, y sólamente se implementan aquellos que se entienden completamente. El sistema es implantado, los usuarios lo utilizan y retroalimentan al equipo de desarrollo. En base a esta retroalimentación se actualizan los requerimientos y comienza el desarrollo de la versión siguiente y así sucesivamente. Requerimientos Requerimientos Diseño Codificación y testing unitario Integración Diseño Codificación y testing unitario Integración Ciclo de Vida Evolutivo Operación Operación Otros modelos El modelo de prototipación ix de requerimientos implica la creación de una implementación parcial del sistema con el propósito de aprender sobre los requerimientos. El prototipo se construye lo más rápido posible y luego los usuarios o quien corresponda experimenta con el prototipo y retroalimenta al equipo que puede así especificar correctamente los requerimientos. Este modelo puede combinarse con cualquiera de los anteriores, incluyendo la tarea de prototipación y validación del prototipo como parte de las fases de requerimientos. La prototipación se utilizó mucho en los años 90 porque la especificación de requerimientos de sistemas complejos suele ser difícil de entender, y es más fácil para quien debe validar los requerimientos manipular un prototipo en lugar de leer un documento tedioso y potencialmente ambiguo. El modelo de espiral de Boehm x, es un meta ciclo de vida. En este modelo, el esfuerzo del desarrollo es iterativo y guiado por el riesgo. Antes de cada vuelta en la espiral, se realiza un

5 análisis de riesgo y se analizan las alternativas. Es adecuado para proyectos de alto riesgo. Sin embargo, dentro de la espiral puede incluirse cualquiera de los ciclos de vida anteriores, y según el que se elija para esto, se configurarán las diferentes tareas de cada vuelta de la espiral. El modelo concurrente también es una meta descripción del proceso. Provee un mecanismo para mostrar las actividades concurrentes. También puede combinarse con cualquiera de los ciclos de vida mencionados. 2. CICLO DE VIDA PARA LA GESTIÓN DIRIGIDA POR LA ARQUITECTURA Algunos autores xi sostienen que en los últimos 10 años ha habido una concientización general sobre la importancia de describir la arquitectura del software antes de implementar el producto. Si bien existen otras alternativas, como el modelo evolutivo, a mi criterio igualmente válidas en determinadas circunstancias, este requerimiento es necesario, si se desea realizar la gestión del proyecto basada en la arquitectura. En los casos donde se utilizan los ciclos de vida en los que se define la arquitectura de alto nivel al comienzo (cascada o desarrollo incremental), es posible aplicar estos principios de gestión en forma completa, mientras que en los modelos evolutivos es posible hacerlo en forma parcial, aplicando los conceptos a cada una de las evoluciones. 3. PLANIFICACIÓN DEL PROYECTO Los proyectos bien gestionados generalmente comienzan como proyectos bien planificados. En la gestión de proyectos dirigida por la arquitectura, el momento de realizar la planificación y organización del proyecto es en paralelo con la definición de la arquitectura de alto nivel, no antes. Se debe resistir la presión externa de divulgar estimaciones y planificaciones no confiables para no comprometerse a metas que luego no podrán cumplirse. Es bien sabido que las estimaciones de esfuerzo y cronograma realizadas en etapas muy tempranas xii xiii del proceso de desarrollo de software suelen ser muy imprecisas. Es muy difícil confeccionar un cronograma viable, identificar metas intermedias y puntos de control antes de contar con una arquitectura de alto nivel. Una vez que la arquitectura está completa, es posible crear un plan de proyecto, un cronograma, organizar el staff y los equipos, todos factores que dependen de la arquitectura delineada. 3.1 Estimación Paulish xiv sugiere el siguiente proceso: Comenzar el proyecto con un pequeño equipo de diseñadores que crearán la arquitectura de alto nivel. En paralelo, utilizar mecanismos de estimación top-down para estimar el total del proyecto tales como Puntos Función de Albrecht, Cocomo de Boehm, SLIM, PRICE-S, etc., siendo el gerente de proyecto el responsable de esta tarea. Los componentes identificados en la arquitectura de software se convierten en las unidades para la estimación bottom-up. Estos componentes se deben identificar en el diseño lógico del sistema, donde se identifican los subsistemas o componentes de alto nivel de abstracción, en la vista lógica propuesta en el modelo 4+1 de Krutchen xv o su equivalente si se usa otro modelo para representar la arquitectura. El arquitecto o los líderes del equipo de diseño deben ser los responsables de la estimación bottomup ya que son quienes conocen la naturaleza y complejidad de cada una de las unidades. Luego el gerente de proyecto debe integrar ambas estimaciones, comparando la suma de la estimación de las unidades contra la estimación top-down y tratar de encontrar el punto de equilibrio. En general, la estimación bottom-up es más precisa en relación a cada uno de los componentes, pero

6 suelen olvidarse otras actividades que no forman parte del desarrollo de las unidades aisladas, tales como las actividades de aseguramiento de la calidad (SQA), de integración, test del sistema, documentación de usuarios, comunicación, etc. Estos elementos sí suelen estar incorporados en las estimaciones top-down Si bien es posible que existan diferencias entre ambas estimaciones debido a estos factores, ambas deberían ser razonablemente compatible. De lo contrario debería revisarse el proceso de estimación. En general lo que no debe hacerse es aceptar estimaciones top-down menores que la suma de las unidades, ya que esta última incluye más actividades y no menos. Considerando estos aspectos, y una vez obtenidas dos estimaciones compatibles, sugiero como mecanismo de integración, considerar el total de la estimación top-down, y las proporciones entre las unidades que surgen de la estimación bottom-up. 3.2 Análisis de Riesgo Como manifesté al comienzo, los proyectos de software suelen ir acompañados de niveles importantes de incertidumbre. Esta incertidumbre se traduce en riesgos, que son probables efectos adversos o problemas que se pueden encontrar durante el desarrollo del proyecto. La gestión del riesgo es una tarea propia del gerente del proyecto y se define como la función ejecutiva que se encarga de mantener bajo control los factores negativos mencionados de forma que estos no hipotequen el éxito del proyecto Proceso de gestión de riesgos La gestión del riesgo se realiza siguiendo un proceso bien definido que implica xvi xvii : Identificación: Existen diferentes mecanismos para la identificación y ponderación de los riesgos tales como check lists, taxonomías (conocimientos transmitidos por terceros, ej. Karolak xviii ), analogía con casos conocidos, aplicación del sentido común, resultados de experimentos entre otras. Análisis: Una vez identificados, es necesario ponderarlos en lo que refiere a su probabilidad de ocurrencia y su impacto en el proyecto, de forma de encontrar los más importantes y gestionar sólamente aquellos que puedan llegar a afectar significativamente el proyecto. Este es el momento de decidir no continuar con el proyecto si el mismo es demasiado riesgoso, dependiendo de la cultura de riesgo de la organización. Planificación: Frente a los riesgos identificados, se puede decidir asumirlos, es decir, no tomar ninguna acción para evitar que sucedan o que afecten al proyecto o mitigarlos. Mitigar un riesgo significa realizar acciones para disminuir su probabilidad o su impacto, denominadas acciones preventivas. Las acciones preventivas se transforman en tareas a realizar que deben ser incluidas en el cronograma y en la planificación del proyecto (ejemplo: realizar prototipo de comunicación de las plataformas); o en decisiones de gestión o de negocio (ejemplo: incrementar en un 20% el precio de la propuesta para cubrir posibles pérdidas identificadas). Los riesgos asumidos siempre pueden materializarse. Debe tenerse en cuenta que también pueden hacerlo aquellos que trataron de mitigarse, si las acciones preventivas no fueron exitosas, o quizás hacerlo con un impacto menor. En ambos casos, debe planificarse un conjunto de acciones correctivas o planes de contingencia en los que se establece cómo reaccionar frente al problema previsto si este sucede. Ejemplos interesantes de planes de contingencia se vieron en muchas organizaciones durante el cambio de siglo. Seguimiento: Periódicamente se realiza un seguimiento de la evolución de los riesgos en base a indicadores definidos y una evaluación de las actividades de prevención realizadas. Además, debe

7 monitorearse constantemente la aparición de nuevos riesgos que surgen durante el desarrollo del proyecto. Evaluación: Al fin del proyecto se realiza una evaluación de la gestión de riesgos y sus resultados de forma de extrapolar la experiencia obtenida a otros proyectos. En caso de haberla, es el momento de alimentar la base de datos de conocimiento de la organización. Identificación Análisis Planificación Seguimiento Ciclo de gestión de Riesgo Evaluación Análisis de riesgo y arquitectura del Software La arquitectura de software es una entrada muy importante para el proceso de análisis de riesgo. Los riesgos técnicos xix suelen ser un porcentaje importante en los riesgos inherentes al desarrollo de productos de software y la fuente para identificarlos es el documento de arquitectura, ya que es allí donde se especifican las decisiones técnicas tomadas y los paquetes que deben desarrollarse. Por lo tanto, el documento de arquitectura debe ser un origen que no se puede pasar por alto en la fase de identificación de los riesgos. Recomiendo no dejar de analizar los siguientes factores, aunque lo que se presenta no es una lista exhaustiva: Experiencia de los equipos de desarrollo en las plataformas, lenguajes y herramientas seleccionadas Estabilidad de las herramientas y plataformas Disponibilidad de las herramientas y plataformas Integrabilidad de las plataformas seleccionadas Interoperabilidad entre los componentes diseñados Nivel de complejidad, testeabilidad y acoplamiento de los componentes Identificación de los componentes críticos ya sea por su importancia para el funcionamiento del producto o por su complejidad. Atributos de calidad requeridos que resulten críticos para el producto (ej.: performance, seguridad, amigabilidad, etc.) y que la arquitectura debe garantizar xx xxi xxii xxiii. Del análisis de la arquitectura del software propuesto surgen entonces una serie de riesgos que deben ser incluidos en el análisis de riesgo. Por supuesto que esta identificación no puede ser realizada por el gerente de proyecto solamente sino que deberá hacerlo en conjunto con el arquitecto. Los riesgos que se identifiquen a partir de la arquitectura, también deben ser ponderados y planificados al igual que los riesgos que surgen de otras fuentes. En algunos casos, se transformarán en actividades preventivas simples (ejemplo: capacitación en alguna herramienta, prototipación de algún componente), en otros casos impactarán en las decisiones de gestión o del propio proceso de desarrollo (ejemplo: incorporación de una fase de beta testing), pueden influir en el cronograma en

8 lo que respecta a la secuencia en que los paquetes o componentes serán desarrollados 4, o incluso pueden transformase en decisiones que modifiquen la arquitectura planteada inicialmente (ejemplo: cambio de plataforma), por lo que es necesario volver a analizar los riesgos que la nueva arquitectura plantea, transformándose el proceso en un ciclo. 3.3 Plan de Versiones En general, y más especialmente para los proyectos de mayor porte, no es posible ni razonable desarrollar todos los componentes y funcionalidades simultáneamente. Existen por lo tanto, desarrollos en paralelo pero también en secuencia, independientemente del ciclo de vida elegido, ya que lo afirmado es cierto incluso para los ciclos de vida en cascada. Se vuelve entonces importante identificar los componentes o paquetes que deben ser desarrollados para luego determinar el orden en que se hará. En estas secuencias, se suelen definir puntos intermedios de control, que permitan subdividir el proyecto, dando la posibilidad de establecer objetivos a corto plazo. Esto es necesario para darle al gerente puntos visibles donde medir el avance del proyecto y poder tomar acciones en caso de desviaciones. En particular, para los proyectos que evolucionan en versiones (ciclos de vida iterativos o evolutivos), en estos hitos se suele incluir una versión del sistema con el desarrollo completo de un grupo funcional que compone una versión del sistema, de donde surge el nombre de plan de versiones. En estos planes se identifican versiones pre-release, que son internas al proyecto, y versiones release o liberaciones, que son las versiones que se van entregando al cliente durante el desarrollo del producto. Para el caso del ciclo de vida en cascada, existirá una sola versión release al final del desarrollo. El documento de arquitectura y el análisis de riesgo, además de los acuerdos con el cliente o las necesidades del mercado, deben ser las entradas a considerar para la confección del plan de versiones. Suelo identificar los siguientes criterios utilizados para establecer el orden y contenido de las versiones: Dirigido por el riesgo: Se desarrollan primero los componentes o funciones de mayor riesgo, para encontrar las dificultades lo antes posible, y evitar así sorpresas luego de haber realizado una inversión mayor en el proyecto o de haber tomado una serie de decisiones sobre las que ya se ha recorrido un buen trecho. Dirigido por las necesidades del usuario/mercado: Se incluyen primero las funcionalidades más urgentes según el criterio del usuario o cliente, y es este quien fija las prioridades que luego pautan la definición de las versiones a liberar. Secuencia lógica: Se realizan primero las funciones o componentes necesarios para el funcionamiento de otras funciones o componentes, es decir las funciones o componentes invocados por otras funciones o componentes de más alto nivel, evitando así el uso de stubs 5 que exigen un mayor esfuerzo de testing cuando se sustituyen por los verdaderos componentes. Dirigido por la capacitación: En algunos casos donde los desarrolladores no están familiarizados con las herramientas a utilizar, se suelen desarrollar primero las funciones o componentes más sencillos para ir aprendiendo el uso de la herramienta e ir progresivamente enfrentando opciones más complejas. 4 Ver capítulo Plan de Versiones 5 Stubs: Funciones o rutinas vacías, que únicamente implementan la interfase y generalmente devuelven valores fijos, para que se puedan compilar y probar las funciones o rutinas que las invocan mientras no se hayan desarrollado las verdaderas funciones o rutinas a invocar. Los stubs son temporales y luego se reemplazan por las verdaderas funciones cuando estas son implementadas.

9 Combinación: Como en tantos otros aspectos, en general no se utiliza solo uno de los criterios sino que es posible utilizar opciones híbridas para distintos momentos en diferentes partes del producto. La arquitectura del software es una entrada fundamental a la hora de confeccionar el plan de versiones. En primer lugar, identifica los componentes que habrán de ser distribuidos a lo largo de las versiones e identifica qué funcionalidad o requerimiento del usuario dicho componente implementa (o colabora en su implementación). De esta forma, es posible identificar qué paquetes o componentes es necesario desarrollar para poder incluir cierta funcionalidad en una versión, y aplicar el criterio dirigido por el usuario. Por otra parte, también es de la arquitectura desde donde se identifican los componentes más críticos, los más complejos y los más importantes para el sistema en caso de utilizar el criterio dirigido por el riesgo, o el nivel de prestación de servicios entre componentes para aplicar el criterio de secuencia lógica. Como la arquitectura es el documento donde es posible identificar los componentes más críticos o complejos del software, ésta no sólo debe utilizarse para la confección del plan de versiones, sino también para la definición de las estrategias de pruebas e integración. 3.4 Recursos Humanos Una actividad crucial para el éxito de un proyecto de desarrollo de software es el reclutamiento, capacitación y organización en equipos de los recursos humanos. No está dentro del alcance del presente trabajo analizar las estrategias de reclutamiento o capacitación, ni la necesidad de trabajar en equipos en el desarrollo de software, concepto que ya está arraigado en la industria xxiv xxv. En cuanto al reclutamiento, la arquitectura permite ver claramente los distintos perfiles que serán necesarios en el proyecto, así como los diferentes conocimientos técnicos que se requerirán. Por ejemplo, en un sistema que utiliza fuertemente bases de datos, se puede deducir la necesidad de contar con un equipo con conocimiento de diseño y administración de base de datos. Lo mismo aplica para las distintas plataformas, lenguajes o herramientas que se identifican. De la arquitectura por lo tanto, surgen los distintos perfiles técnicos con los que se habrá de contar para el desarrollo del producto, criterios que deben marcar el reclutamiento de nuevo personal o plasmarse en planes de capacitación para el personal existente. Una vez seleccionados los perfiles, es necesario organizar los equipos. La arquitectura puede ser la base para la organización de los equipos, destacándose dos alternativas: en forma vertical y horizontal Organización horizontal Para los sistemas diseñados en capas o para aquellos con componentes funcionales claramente diferenciados, es posible tener equipos asignados a cada uno de estas capas o paquetes. Por ejemplo, para un sistema en capas (interfase de usuario, dominio y persistencia), podría existir un equipo para cada una de ellas. O en un sistema de operación de una red compuesta por paquetes para la representación geográfica de la red en forma visual, paquetes para la manipulación de los nodos de la red y paquetes para interacción con dispositivos de telecontrol, cada equipo podría especializarse en uno de estos paquetes. La ventaja de esta organización es que cada uno de los equipos se vuelve un experto en el paquete o capa en la que está trabajando. Además, como sólo un equipo trabaja en una capa o componente, el mismo es diseñado e implementado siguiendo siempre el mismo criterio, con lo que se logra que sea más uniforme y estandarizado. Como desventajas, es necesario tener varios equipos trabajando simultáneamente para realizar las

10 porciones de todas las capas o paquetes necesarios para implementar una versión. Además, los equipos tienen una vista parcial del sistema y es más difícil encontrar luego desarrolladores con una visión general del sistema para las fases de mantenimiento, en caso de que se desee reducir los equipos que participarán en esta etapa Capa/componente 3 Capa/componente 2 Capa/componente 1 Equipo 3 Equipo 2 Equipo 1 Equipo 1 Equipo 2 Equipo 3 Capa/componente 3 Capa/componente 2 Capa/componente 1 Organización de equipos horizontal Organización de equipos vertical Organización vertical La organización vertical implica la división del sistema en grupos funcionales o subsistemas que atraviesan varias capas o componentes. Se forman equipos para cada uno de estos subsistemas o grupos funcionales, que trabajarán en todas las capas o componentes necesarios. Una de las ventajas es que es posible llegar a desarrollar las sucesivas versiones de un producto con un solo equipo trabajando, simplemente serializando los grupos funcionales o subsistemas en varias versiones (condicionado por el tamaño del proyecto). Otra ventaja es que se evitan los problemas de comunicación entre los equipos de distintos paquetes o capas que deben comunicarse o prestarse servicios mutuamente. Si bien esto puede representar una ventaja, también puede incorporar un problema colateral si al conocer el equipo el funcionamiento interno de la capa que provee los servicios, viola el encapsulamiento y accede directamente a las capas subyacentes, lo que no es tan probable que suceda cuando esta fue desarrollada por otro equipo y no se conocen sus detalles de diseño o implementación. En tercer lugar, los desarrolladores de los distintos grupos funcionales tienen una visión más completa de la funcionalidad en la que están trabajando, ya que participaron del diseño y la implementación de todos los componentes involucrados, en contraposición con la otra posibilidad. Como desventaja, si varios equipos trabajan en una misma capa o componente, puede que los mismos no resulten lo cohesivos que debieran ser, que exista redundancia (funciones implementadas varias veces), o que no se apliquen los mismos criterios frente a alternativas similares. En mi opinión, en proyectos de cierta magnitud donde se dispone del personal suficiente para armar los equipos necesarios, es preferible la organización horizontal, ya que se logran paquetes más cohesivos y optimizados y menos acoplados. Además, debido a la no duplicación de esfuerzo para desarrollar funcionalidades o servicios similares, se disminuye el esfuerzo de desarrollo. Por otra parte al tener un equipo responsable de cada componente en particular, en caso de algún problema o falla, es fácilmente identificable cuál es el equipo que tiene un conocimiento integral del paquete para localizarla y solucionarla. En proyectos de gran porte, es posible utilizar combinaciones de ambos enfoques donde corresponda, definiendo equipos verticales y sub-equipos horizontales o viceversa, según surja de la arquitectura definida. A la hora de configurar los equipos, es importante que en cada equipo se incluya alguno de los

11 participantes del diseño de la arquitectura, generalmente estos suelen ocupar el rol de jefe de equipo. Ellos tienen un conocimiento más profundo de la arquitectura que ayudaron a definir y de los motivos por los que se tomaron las decisiones, por lo que su visión no se concentra en el paquete a desarrollar, visión que pueden transmitir al resto del equipo. Además, están en mejores condiciones de tomar decisiones con respecto a un componente en particular, pues conocen mejor sus repercusiones en el resto del sistema. Por otro lado, participaron en el proceso de estimación bottom-up de los componentes, por lo que se encuentran comprometidos con esta planificación, compromiso que deben cumplir como jefes de equipo por el que son responsables. 3.5 Cronograma Las herramientas para representar cronogramas que se utilizan hoy en día, generalmente permiten agrupar y desagrupar las tareas en distintos niveles de abstracción, por lo que ofician también de WBS (Work Breakdown Structure). 6 Por lo tanto, se mencionarán en forma indistinta las formas de organizar el cronograma y la WBS, ya que ambas se representan en forma conjunta. Las alternativas a la hora de organizar una WBS o un cronograma siguen diferentes criterios xxvi : Orientada a la fase: Permiten identificar las fases del desarrollo. Se divide el sistema primero en grandes fases, luego dentro de las fases se detallan las tareas particulares. Orientadas al producto: Permiten identificar los componentes. Se descompone el producto en partes y luego se representan las tareas para realizar cada una de las partes del producto. Orientadas a la función: Se organizan según los distintos actores del sistema Existen alternativas híbridas que permiten mezclar los dos criterios para distintas partes o diferentes momentos en el desarrollo del producto. La forma más útil de representar el cronograma es que el mismo se parezca lo más posible al ciclo de vida. Por ejemplo para los ciclos de vida iterativos o evolutivos, resulta muy conveniente que el mismo refleje directamente el plan de versiones. De esta forma, se contarán con grandes tareas que representan cada una de las versiones, que a su vez se descompondrán en tareas concretas para alcanzar estas metas. De esta forma, es posible acceder al nivel de detalle de la fase o tarea del ciclo de vida que se está ejecutando en este momento (por ejemplo, la iteración que genera la versión X del producto), y manejar el resto del proyecto con un nivel de abstracción mayor. Por otra parte, los hitos o mojones que marcan el fin de cada una de las fases identificadas en el ciclo de vida, se corresponden con el fin de las tareas de mayor nivel de abstracción del cronograma, que son a su vez el primer nivel de la WBS asociada. Una vez definida la estructura del cronograma deben planificarse las distintas iteraciones y dentro de cada una de ellas deben identificarse los componentes sobre los que se va a trabajar y los recursos que se asignarán a dichas tareas xxvii. 6 WBS= Work Breakdown Structure: Representación gráfica en forma de árbol donde se subdividen grandes tareas en tareas más concretas en forma recursiva, de forma de obtener unidades más manejables que puedan ser estimadas y asignadas a los responsables de ejecutarlas. Permite acceder a representaciones de distinto nivel de agregación para obtener vistas con distinto nivel de abstracción.

12 Id Nombre de tarea 1 Ing. 'Requerimientos enero f ebrero marzo abril may o junio julio agosto septiembre octubre noviembre diciembre enero F P M F P M F P M F P M F P M F P M F P M F P M F P M F P M F P M F P M F P M 2 Arquitectura 3 Version pre-release 1 4 Componente 1 5 Componente 2 6 Integración 7 Fin 26/06 8 Version release 2 9 Componente 4 10 Componente 5 11 Componente 6 12 Componente 7 13 Integración 14 Fin 30/08 15 Version pre-release 3 Para esto deben considerarse factores como: Estimación del esfuerzo necesario para cada uno de los componentes. Cantidad de recursos humanos disponibles y sus perfiles para definir qué tareas se pueden realizar en paralelo y asignarlos a las tareas. Secuencia de desarrollo según el plan de versiones. Comienzan a jugar aquí otras restricciones tales como el tiempo máximo de desarrollo, el presupuesto disponible, el flujo de caja, etc. Esto puede implicar que sea necesario redimensionar algunos de los equipos o paralelizar/serializar algunas de las actividades Por ejemplo, es posible que sea necesario aumentar el tamaño de algún equipo para acortar la duración de alguna iteración, o que sea necesario serializar tareas que lógicamente podrían realizarse en paralelo debido a la cantidad de recursos humanos disponibles, etc. Esto además debe compatibilizarse con una gran cantidad de otros factores externos que puedan tener algún grado de influencia. 3.6 Proceso Como conclusión, el proceso que planteo para la planificación y gestión de un proyecto dirigido por la arquitectura es el siguiente (ver figura final): A partir de los requerimientos funcionales y no funcionales se diseña la arquitectura del producto mientras en paralelo se realiza la estimación top-down del proyecto. A partir de la arquitectura se realiza una estimación bottom-up de cada uno de los componentes identificados. Se integran ambas estimaciones en la que se utilizará para la planificación del proyecto. Se realiza un nuevo análisis de riesgo, incorporando a la arquitectura como fuente de posibles riesgos que pueden afectar al proyecto. Algunos de los riesgos identificados pueden ocasionar la toma de decisiones que afecten la arquitectura con lo que se repite el ciclo. A partir de la arquitectura, los requerimientos o necesidades del usuario y del análisis de riesgo, se confecciona el plan de versiones. A partir de la arquitectura, se organizan los equipos que participarán en el proyecto. A partir del plan de versiones, del resultado del proceso de estimación, de las tareas de prevención y de las decisiones tomadas a partir del análisis de riesgo, y de los equipos previstos se confecciona el cronograma. Algunas consideraciones en el momento de confeccionar el cronograma para tener en cuenta todas las restricciones del proyecto pueden afectar la organización de los equipos, con lo que se vuelve a iterar el ciclo hasta encontrar el punto de equilibro. Una vez definidos el plan de versiones y el cronograma, comienza la construcción del producto, el cual se gestionará para mantenerlo dentro de lo previsto en los documentos obtenidos como resultado del proceso descripto xxviii.

13 Ing. de Requerimientos Estimación Top- Down Arquitectura Proceso de planificación y organización del proyecto basado en la arquitectura Estimación Bottom- Up Integración de estimaciones Plan de Versiones Confección del cronograma Ejecución Análisis de Riesgo Organización de los equipos i A guide to the Project Management Body of Knowledge (PMBOK), Project Management Institute ii Humphrey, W.S, Managing the software process iii Bass, Clements y Kazman Software Architecture in Practice. Massachusetts, USA. Addison Wesley. iv Soni D, Nord R y Hofmeister C, Software Architecture in Industrial Applications, en Proceedings of the 17 th International Conference on Software Engineering, New York: ACM Press, v Davis Alan M., Software Life Cycle Models. Software Engineering project management, editado por Richard H Thayer, 2ª edición. IEEE Computer Society Press, 1988 vi Royce W.W., Managing the Development of Large Software Systems: Concepts and Techniques, Proc WESCON Technical Papers, Vol. 14, 1970 vii Hirsch E., Evolutionary Acquisition of Command and Control Systems, Program Manager, Nov viii Giddings R.V, Accommodating Uncertainty in Software Design, Comm ACM, Vol 27, N 5, May ix Gomaa H y Scott D, Prototyping as a Tool in the Specification of User Requirements, Proc. 5 th IEEE International Conference on Software Engineering, IEEE CS Press, Los Alamitos, California, x Boehm B.W. A Spiral Model of Software Development and Enhancement, Computer, May xi Paulish D.J, Architecture-Centric Software Project Management, A practical guide, Carnegie Mellon, Software Engineering Institute, xii Boehm B, Software Engineering Economics, E Englewood Cliffs, NJ, Prentice Hall xiii Boehm B. et al, Software Cost Estimation with Cocomo II, Upper Saddel River, NJ, Prentice Hall, xiv Paulish D.J, Architecture-Centric Software Project Management, A practical guide, Carnegie Mellon, Software Engineering Institute, xv KRUTCHEN Philippe. Noviembre The 4+1 View Model of Architecture. IEEE Software, 12(6). xvi Higuera R.P, Software Risk Management, CMU/SEI-96-TR-012 ESC-TR , Software Engineering Institute (SEI), xvii Grey S, Practical Risk Assessment for Project Management, John Wiley & Sons xviii Karolak D.W, Software Engineering Risk Management, IEEE Computer Society Press xix Michaels J.V, Technical Risk Management, Prentice Hall xx BASS L. et al. Quality Attribute Design Primitives. Technical Note CMU/SEI-2000-TN-017. Dic xxi BASS L., et al. Quality Attribute Design Primitives and the Attribute Drive Design Method. SEI, Carnegie Mellon University, Pittsburgh. xxii MOUSQUES G Transp. Curso de Arquitectura. Ing. de Sistemas, Universidad ORT, Uruguay. xxiii KAZMAN R. et al. Oct Attribute Based Architectural Styles. Techn. Report CMU/SEI-99-TR022. xxiv Thayer R, Software Engineering Project Management xxv Rees F, Equipos de trabajo, Prentice Hall 1997 xxvi Simons, Lucarelli, Work Breakdown Structures xxvii Gido, Clements, Network Planning and Scheduling xxviii Pinto J, Project Management Handbook, PMI

Gestión del Riesgo. Un peso invertido en prevención de riesgos vale por muchos pesos gastados en recuperación ante problemas

Gestión del Riesgo. Un peso invertido en prevención de riesgos vale por muchos pesos gastados en recuperación ante problemas Gestión del Riesgo Un peso invertido en prevención de riesgos vale por muchos pesos gastados en recuperación ante problemas 1 Bibliografía A guide to de Project Management Body of Knowledge (PMBOK), Project

Más detalles

Documentando la arquitectura de software Principios básicos por Omar Gómez

Documentando la arquitectura de software Principios básicos por Omar Gómez Documentando la arquitectura de software Principios básicos por Omar Gómez En la actualidad, uno de los temas candentes que se habla dentro de la comunidad de desarrollo de software es el referente a las

Más detalles

SCOPE PLANNING IN SOFTWARE PROJECTS PLANIFICACIÓN DEL ALCANCE EN PROYECTOS DE SOFTWARE

SCOPE PLANNING IN SOFTWARE PROJECTS PLANIFICACIÓN DEL ALCANCE EN PROYECTOS DE SOFTWARE Recibido: 23 de febrero de 2011 Aceptado: 29 de marzo de 2011 SCOPE PLANNING IN SOFTWARE PROJECTS PLANIFICACIÓN DEL ALCANCE EN PROYECTOS DE SOFTWARE MSc. Ailin Orjuela, MSc. Luis Alberto Esteban, MSc.

Más detalles

Uso de Métricas para la Gestión de Riesgos

Uso de Métricas para la Gestión de Riesgos Uso de s para la Gestión de Riesgos Cecilia Belletti cecibell@adinet.com.uy / 3967@universidad.ort.edu.uy Luis Jaunarena luisj@adinet.com.uy / 101915@universidad.ort.edu.uy Montevideo, Uruguay Resumen

Más detalles

Rational Unified Process (RUP)

Rational Unified Process (RUP) Rational Unified Process (RUP) Este documento presenta un resumen de Rational Unified Process (RUP). Se describe la historia de la metodología, características principales y estructura del proceso. RUP

Más detalles

Modelos de desarrollo de software. septiembre de 2007 1

Modelos de desarrollo de software. septiembre de 2007 1 Modelos de desarrollo de software septiembre de 2007 1 Referencias básicas Ingeniería de software. Un enfoque práctico. Pressman, R. Quinta edición. Mc. Graw Hill 2002 Ingeniería de software. Sommerville,

Más detalles

Contenidos. Parte I - Introducción Capítulo 1 - Evolución. Capítulo 2 Condiciones de trabajo en el Desarrollo de Software

Contenidos. Parte I - Introducción Capítulo 1 - Evolución. Capítulo 2 Condiciones de trabajo en el Desarrollo de Software IX Contenidos Prólogo... XIX Prefacio... XXI Guía de lectura...xxiii Parte I - Introducción Capítulo 1 - Evolución 1.1 Introducción... 2 1.2 Los hitos en la evolución histórica del desarrollo de software...

Más detalles

Análisis de la gestión de configuración de software aplicada al modelo de espiral

Análisis de la gestión de configuración de software aplicada al modelo de espiral Análisis de la gestión de configuración de software aplicada al modelo de espiral Abstract No hay nada permanente, excepto el cambio Heráclito (540 475 A.C.)- Grecia Fernandez, Sebastian Osso, Mariano

Más detalles

Gestión de Proyectos A Guide to the Project Management Body of Knowledge (Pmbok Guide) Profesor Guillermo E. Badillo Astudillo

Gestión de Proyectos A Guide to the Project Management Body of Knowledge (Pmbok Guide) Profesor Guillermo E. Badillo Astudillo Gestión de Proyectos A Guide to the Project Management Body of Knowledge (Pmbok Guide) Profesor Guillermo E. Badillo Astudillo Todas las slides siguientes están tomadas de la guía de los fundamentos para

Más detalles

ESTRUCTURA DE DESGLOSE DEL TRABAJO EDT

ESTRUCTURA DE DESGLOSE DEL TRABAJO EDT ESTRUCTURA DE DESGLOSE DEL TRABAJO EDT Una de las primeras tareas en el proceso de creación de un proyecto es la definición de su alcance, delimitando los trabajos a realizar para lograr cumplir los objetivos

Más detalles

Ingeniería de Software II

Ingeniería de Software II Ingeniería de Software II Segundo Cuatrimestre 2007 Clase 8 Parte 1: Gestión de Riesgos Algunas enfermedades, como dicen los médicos, son al principio fáciles de curar pero difíciles de reconocer... pero,

Más detalles

7mo Simposio Argentino De Informatica En El Estado - SIE 2013

7mo Simposio Argentino De Informatica En El Estado - SIE 2013 Uso de Work Breakdown Structure para relevar las capacidades de un área de Information Technology Leandro Antonelli, Adriana Chalar, Andrés Lisse, Antonio Pasquale Centro de Informática, Fiscalia de Estado,

Más detalles

5 La Gerencia de Proyectos

5 La Gerencia de Proyectos 5 La Gerencia de Proyectos La gran mayoría de las civilizaciones han tenido como factor común la ejecución de grandes hazañas dignas de recordarse, que han quedado plasmadas en los libros de historia y

Más detalles

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1 Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir

Más detalles

DESARROLLO DE SOFTWARE CON CALIDAD PARA UNA EMPRESA

DESARROLLO DE SOFTWARE CON CALIDAD PARA UNA EMPRESA DESARROLLO DE SOFTWARE CON CALIDAD PARA UNA EMPRESA Resumen AUTORIA CARLOS CABALLERO GONZÁLEZ TEMATICA INFORMÁTICA ETAPA ESO-BACHILLERATO-CFGM(ESI,ASI,DSI) Se describe la revolución que supuso la incursión

Más detalles

La importancia del desarrollo para el buen diseño del software

La importancia del desarrollo para el buen diseño del software La importancia del desarrollo para el buen diseño del software RESUMEN N L González Morales. 1 En este ensayo se examinan los temas vistos en clase que son Desarrollo de Orientado a Objetos y Arquitectura

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software Tabla de Contenidos PARTE I INTRODUCCIÓN Capítulo 1: Evolución Los hitos en la evolución histórica del Desarrollo de Software Problemas y soluciones... Fallas, malas estimaciones

Más detalles

METODOLOGÍA DE GESTION DE PROYECTOS

METODOLOGÍA DE GESTION DE PROYECTOS METODOLOGÍA DE GESTION DE PROYECTOS CONTENIDO CONTENIDO... 2 ALCANCE... 4 MARCO METODOLÓGICO... 4 ETAPAS DEL PROCESO... 5 1. ETAPA 0: INICIACIÓN...5 FASE DE INICIO...5 2. ETAPA 1: PLANEAMIENTO...6 FASE

Más detalles

Tema 2. Ingeniería del Software I feliu.trias@urjc.es

Tema 2. Ingeniería del Software I feliu.trias@urjc.es Tema 2 Ciclo de vida del software Ingeniería del Software I feliu.trias@urjc.es Índice Qué es el ciclo de vida del Software? El Estándar 12207 Modelos de proceso Qué es el Ciclo de Vida del SW? Definición

Más detalles

cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred.

cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred. cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred.com CICLO DE VIDA DEL SOFTWARE Para apreciar un poco más el problema

Más detalles

3 3 X (1) Observaciones: (2) Observaciones: Docente/s. Espacios Curriculares Correlativos Precedentes Aprobada/s Cod. Asig. Cursada/s Cod. Asig.

3 3 X (1) Observaciones: (2) Observaciones: Docente/s. Espacios Curriculares Correlativos Precedentes Aprobada/s Cod. Asig. Cursada/s Cod. Asig. Ciclo Académico: 2009 Año de la Carrera: Horas de Clases Semanales Régimen de Cursado 1 Teoría Práctica Otros (1) Anual 1er.Cuatr. 2do.Cuatr. Otros (2) 3 3 X (1) Observaciones: (2) Observaciones: Docente/s

Más detalles

INGENIERÍA DE SOFTWARE CICLOS DE VIDA Y METODOLOGIAS

INGENIERÍA DE SOFTWARE CICLOS DE VIDA Y METODOLOGIAS INGENIERÍA DE SOFTWARE CICLOS DE VIDA Y METODOLOGIAS Rubby Casallas, Andrés Yie Departamento de Sistemas y Computación Facultad de Ingeniería Universidad de los Andes Agenda Contexto Ciclos de vida: Modelo

Más detalles

Introducción 90% Figura 1 Síndrome del 90%

Introducción 90% Figura 1 Síndrome del 90% El Problema Quality Control = Project Control? Indicadores Objetivos para Control de Proyectos de Desarrollo de Software Lic. Juan Pablo Pussacq Laborde Jefe de la Oficina de Proyectos, RMyA Introducción

Más detalles

Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software

Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software Jorge Bozo jbozo@inf.ucv.cl Escuela de Ingeniería Informática Universidad Católica de Valparaíso Valparaíso, Chile

Más detalles

Temario III Testing in the Large

Temario III Testing in the Large Temario III Testing in the Large 1ra Parte Verificación y Validación de Software UNS 1 Contenidos Testing de Integración Testing de Sistema Testing de Regresión Verificación y Validación de Software UNS

Más detalles

14. Ingeniería de software. Ing. Alejandro Adorjan

14. Ingeniería de software. Ing. Alejandro Adorjan 14. Ing. Alejandro Adorjan : un enfoque en ingeniería de requerimientos Introducción La ingeniería de software es una disciplina que estudia la aplicación de la teoría, el conocimiento y la práctica de

Más detalles

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: 1. Proporcionar una guía de actividades para el trabajo en equipo. (Guía detallada para el desarrollo

Más detalles

Plan de estudios ISTQB: Nivel Fundamentos

Plan de estudios ISTQB: Nivel Fundamentos Plan de estudios ISTQB: Nivel Fundamentos Temario 1. INTRODUCCIÓN 2. FUNDAMENTOS DE PRUEBAS 3. PRUEBAS A TRAVÉS DEL CICLO DE VIDA DEL 4. TÉCNICAS ESTÁTICAS 5. TÉCNICAS DE DISEÑO DE PRUEBAS 6. GESTIÓN DE

Más detalles

Definir el problema/oportunidad. Desarrollar soluciones alternativas. Seleccionar la solución. Desarrollar / Seleccionar-Adquirirconfigurar

Definir el problema/oportunidad. Desarrollar soluciones alternativas. Seleccionar la solución. Desarrollar / Seleccionar-Adquirirconfigurar 1 Definir el problema/oportunidad Definir problema de negocio o la oportunidad de mejora utilizando el pensamiento sistémico. Mapa Conceptual Desarrollar soluciones alternativas Seleccionar la solución

Más detalles

Escuela Politécnica Superior. Proyectos de Desarrollo Software. Capítulo 5. daniel.tapias@uam.es. Dr. Daniel Tapias Curso 2014/ 15 PROYECTOS

Escuela Politécnica Superior. Proyectos de Desarrollo Software. Capítulo 5. daniel.tapias@uam.es. Dr. Daniel Tapias Curso 2014/ 15 PROYECTOS Escuela Politécnica Superior Proyectos de Desarrollo Software Capítulo 5 Dr. Daniel Tapias Curso 2014/ 15 daniel.tapias@uam.es PROYECTOS PROGRAMA DE LA ASIGNATURA Capítulo 1: Introducción. Capítulo 2:

Más detalles

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

Gestión de las Pruebas Funcionales

Gestión de las Pruebas Funcionales Gestión de las Pruebas Funcionales Beatriz Pérez Lamancha (bperez@fing.edu.uy) Centro de Ensayos de Software Universidad de la República, Montevideo, Uruguay Resumen Se presenta en este artículo una estrategia

Más detalles

Departamento de Informática Universidad de Valladolid Campus de Segovia TEMA 2: EL CICLO DE VIDA DEL SOFTWARE

Departamento de Informática Universidad de Valladolid Campus de Segovia TEMA 2: EL CICLO DE VIDA DEL SOFTWARE Departamento de Informática Universidad de Valladolid Campus de Segovia TEMA 2: EL CICLO DE VIDA DEL SOFTWARE 1 DEFINICIÓN DE CICLO DE VIDA DEL SOFTWARE ISO/IEC 12207-1 Marco de referencia que contiene

Más detalles

Trabajo de Investigación

Trabajo de Investigación Escuela Técnica Superior de Ingeniería Informática Departamento: Ingeniería de Software y Sistemas Informáticos Trabajo de Investigación Arquitecturas Software: Gestión de los atributos de calidad de un

Más detalles

Preguntas y respuestas (rebatibles) sobre metodologías de desarrollo de software

Preguntas y respuestas (rebatibles) sobre metodologías de desarrollo de software Preguntas y respuestas (rebatibles) sobre metodologías de desarrollo de software Introducción Este documento recopila las preguntas, opiniones y respuestas que se produjeron en un pequeño curso sobre las

Más detalles

Ciclo de vida del Software

Ciclo de vida del Software Tema 2: Ciclo de vida del Software Marcos López Sanz Índice Qué es el ciclo de vida del Software? La norma 12207-2008 Modelos de desarrollo Qué es el Ciclo de Vida del SW? Es una sucesión de etapas por

Más detalles

Alejandro J Bianchi. Software Architecture Professional Certficate Software Engineering Institute, CMU University.

Alejandro J Bianchi. Software Architecture Professional Certficate Software Engineering Institute, CMU University. Ciclos de Vida guiados por la Arquitectura: Balanceando entre agilidad, eficiencia y calidad Alejandro J Bianchi ATAM Evaluator Certificate Software Architecture Professional Certficate Software Engineering

Más detalles

Gestión de Proyectos de desarrollo de software. Ing. Rafael Bentancur Universidad ORT Uruguay

Gestión de Proyectos de desarrollo de software. Ing. Rafael Bentancur Universidad ORT Uruguay Gestión de Proyectos de desarrollo de software Ing. Rafael Bentancur Universidad ORT Uruguay Algunas definiciones Proyecto: emprendimiento temporario que debe crear un producto o servicio único (PMBOK)

Más detalles

Tecnología de la Información. Administración de Recursos Informáticos

Tecnología de la Información. Administración de Recursos Informáticos Tecnología de la Información Administración de Recursos Informáticos 1. Recursos informáticos: Roles y Responsabilidades 2. Áreas dentro del Departamento de Sistemas 3. Conceptos asociados a proyectos

Más detalles

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga Actividad 2 Unidad 1 Ciclo de vida del software y Diseño Orientado a Objetos Ciclo de Vida del Software Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto

Más detalles

Interacción Persona - Ordenador

Interacción Persona - Ordenador Interacción Persona - Ordenador Diseño de la interfaz en la Ingeniería del Software Dr. Pedro Latorre Dra. Sandra Baldassarri Dra. Eva Cerezo Ingeniería del Software Ingeniería del Software: Definición

Más detalles

Ingeniería de Software I

Ingeniería de Software I Ingeniería de Software I Agenda Objetivo. Unidades de aprendizaje. Formas de evaluación. Bibliografía. 2 Datos del profesor Correo electrónico: egonzalez@upemor.edu.mx Asesorías Jueves de 11:00 a 13:00

Más detalles

RESUMEN de la GESTIÓN de PROYECTOS

RESUMEN de la GESTIÓN de PROYECTOS RESUMEN de la GESTIÓN de PROYECTOS Basado en la Guía de los Fundamentos de la Dirección de Proyectos (Guía del PMBOK ) Contenidos Introducción...2 PMI...2 Objetivos...2 PMBOK...2 Proyecto...3 Concepto...3

Más detalles

El modelo de ciclo de vida cascada, captura algunos principios básicos:

El modelo de ciclo de vida cascada, captura algunos principios básicos: Ciclo de Vida del Software Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto de desarrollo de software. El primer ciclo de vida del software, "Cascada",

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

Modelos de Proceso Tradicionales

Modelos de Proceso Tradicionales Modelos de Proceso Tradicionales Capitulo 2,QJHQLHUtDGHO6RIWZDUH (VSHFLDOL]DFLyQHQ*HUHQFLDGH6LVWHPDVGH,QIRUPDFLyQ 8QLYHUVLGDG6DQWLDJRGH&DOL Profesor: MSc. MIGUEL ANGEL NIÑO ZAMBRANO Programación: Tiempo

Más detalles

Gestión del alcance de un proyecto

Gestión del alcance de un proyecto Gestión del alcance de un proyecto Gestión de Proyectos Informáticos 1 Bibliografía Project Management Handbook, Jeffrey K. Pinto, 1998 Project Scope Management, (cap. 7) Jeffrey K. Pinto Work breakdown

Más detalles

IT Project Management Desarrollo de Software

IT Project Management Desarrollo de Software IT Project Management Desarrollo de Software Es posible una mezcla de Waterfall y Agile? Cómo se acerca el PMBOK a Agile? Autor: Norberto Figuerola Resulta muy frecuente que se suela confundir una aproximación

Más detalles

DESARROLLO DE SOFTWARE EMPRESARIAL. Jonás Montilva C. Judith Barrios A. Universidad de Los Andes

DESARROLLO DE SOFTWARE EMPRESARIAL. Jonás Montilva C. Judith Barrios A. Universidad de Los Andes DESARROLLO DE SOFTWARE EMPRESARIAL Jonás Montilva C. Judith Barrios A. Universidad de Los Andes Desarrollo de Software Empresarial Derechos Reservados. Ninguna parte de este documento puede ser reproducida,

Más detalles

Magíster en Ingeniería de Software Administración de Proyectos Prof. Lic. Alejandro Oliveros

Magíster en Ingeniería de Software Administración de Proyectos Prof. Lic. Alejandro Oliveros Profesor: Lic. Alejandro Oliveros Objetivo Discutir los lineamientos generales de la administración de proyectos enfatizando aspectos vinculados a la medición de resultados, a la inserción de parámetros

Más detalles

Gestión de riesgos. 1. Definición y clasificación 2. Actividades. Estimación de riesgos. Identificación Análisis Evaluación. Control de riesgos

Gestión de riesgos. 1. Definición y clasificación 2. Actividades. Estimación de riesgos. Identificación Análisis Evaluación. Control de riesgos Gestión de riesgos 1. Definición y clasificación 2. Actividades Estimación de riesgos Identificación Análisis Evaluación Control de riesgos Planificación Supervisión 1 Definición The SEI Definition The

Más detalles

Ingeniería de Software. Procesos. Proyecto de Ingeniería. Metodologías. Metodologías. Metodologías. Metodologías de desarrollo

Ingeniería de Software. Procesos. Proyecto de Ingeniería. Metodologías. Metodologías. Metodologías. Metodologías de desarrollo Ingeniería de Software Procesos Laboratorio de Ingeniería de Software 2004 La ingeniería de software trata sobre la aplicación de practicas y métodos para construir productos de software que cumplan las

Más detalles

El proceso unificado en pocas palabras

El proceso unificado en pocas palabras El Proceso Unificado de Desarrollo de Software Ivar Jacobson Grady Booch James Rumbaugh Addison Wesley Resumen Capítulo 1. El proceso unificado: dirigido por casos de uso, centrado en la arquitectura,

Más detalles

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Página 1 de 23 Índice del Documento 1.- Introducción... Página 4 2.- Propuesta

Más detalles

Herramienta para la Administración y Estimación Ágil de Desarrollo de Software

Herramienta para la Administración y Estimación Ágil de Desarrollo de Software Herramienta para la Administración y Estimación Ágil de Desarrollo de Software Mario R. MORENO SABIDO Depto. de Sistemas y Computación, Instituto Tecnológico de Mérida Mérida, Yucatán 97118, México y Jorge

Más detalles

CLASE 2: INTRODUCCIÓN A LA ING. DE SOFTWARE. MODELOS DE PROCESOS. MEJORES PRÁCTICAS. USB Ing. De Software. Prof. I. C. Martínez

CLASE 2: INTRODUCCIÓN A LA ING. DE SOFTWARE. MODELOS DE PROCESOS. MEJORES PRÁCTICAS. USB Ing. De Software. Prof. I. C. Martínez CLASE 2: INTRODUCCIÓN A LA ING. DE SOFTWARE. MODELOS DE PROCESOS. MEJORES PRÁCTICAS USB Ing. De Software. Prof. I. C. Martínez Ing. De Software Ingeniería de Software La Ingeniería de Software es la ciencia

Más detalles

Capítulo 12 Ingeniería de software: el proceso para el desarrollo de software

Capítulo 12 Ingeniería de software: el proceso para el desarrollo de software Capítulo 12 Ingeniería de software: el proceso para el desarrollo de software Por Alfredo Weitzenfeld Ridel y Silvia Guardati Buemo El desarrollo de software es una de las actividades más importantes de

Más detalles

GRAY WATCH. Jonás Montilva C. Judith Barrios A. Milagro Rivero A. MÉTODO DE DESARROLLO DE SOFTWARE PARA APLICACIONES EMPRESARIALES. Versión preliminar

GRAY WATCH. Jonás Montilva C. Judith Barrios A. Milagro Rivero A. MÉTODO DE DESARROLLO DE SOFTWARE PARA APLICACIONES EMPRESARIALES. Versión preliminar GRAY WATCH MÉTODO DE DESARROLLO DE SOFTWARE PARA APLICACIONES EMPRESARIALES Versión preliminar Proyecto METHODIUS FONACIT 2005000165 Jonás Montilva C. Judith Barrios A. Milagro Rivero A. MÉRIDA, VENEZUELA

Más detalles

Docente/s. Espacios Curriculares Correlativos Precedentes Aprobada/s Cod. Asig. Cursada/s Cod. Asig. Espacios Curriculares Correlativos Subsiguientes

Docente/s. Espacios Curriculares Correlativos Precedentes Aprobada/s Cod. Asig. Cursada/s Cod. Asig. Espacios Curriculares Correlativos Subsiguientes Ciclo Académico: 2009 Año de la Carrera: Horas de Clases Semanales Régimen de Cursado 1er. Teoría Práctica s (1) Anual 1er.Cuatr. 2do.Cuatr. s (2) 2 2 X (1) Observaciones: (2) Observaciones: Teoría Docente/s

Más detalles

Cristian Blanco www.cristianblanco.es

Cristian Blanco www.cristianblanco.es 3.1.- INTRODUCCIÓN Para realizar el desarrollo de cualquier proyecto de software es necesario llevar una sistemática de trabajo, que nos asegure el éxito del mismo. Lo que tenemos que evitar, en el desarrollo

Más detalles

SOFTWARE PLANNING PROJECTS UNDER THE PMI GUIDELINES PLANEACION DE PROYECTOS DE SOFTWARE BAJO LINEAMIENTOS DEL PMI. MSc. Mauricio Rojas Contreras

SOFTWARE PLANNING PROJECTS UNDER THE PMI GUIDELINES PLANEACION DE PROYECTOS DE SOFTWARE BAJO LINEAMIENTOS DEL PMI. MSc. Mauricio Rojas Contreras Recibido: 06 de agosto de 2009 Aceptado: 21 de octubre de 2009 SOFTWARE PLANNING PROJECTS UNDER THE PMI GUIDELINES PLANEACION DE PROYECTOS DE SOFTWARE BAJO LINEAMIENTOS DEL PMI MSc. Mauricio Rojas Contreras

Más detalles

Examinando los procesos de la Dirección de proyectos

Examinando los procesos de la Dirección de proyectos IX Congreso de Ingeniería de Organización Gijón 8 y 9 Septiembre de 2005 Examinando los procesos de la Dirección de proyectos Marinka Varas Parra ( 1 ) ( 1 )Depto. Ingeniería Industrial. Facultad de Ingeniería.Avda

Más detalles

El Proceso Unificado

El Proceso Unificado El Proceso Unificado de Desarrollo de Software Prof. Gustavo J. Sabio Alcance de la presentación QA Entradas Proceso de desarrollo Salida equipo Cliente sistemas Cliente necesidades actividades varias

Más detalles

Común / Optativo: Optativo. Orientaciónes Curriculares. Profesional Integral. 5to: 6to: 7mo: 8vo: Tipo de curso: Seleccionar Turno/s: DANIEL OTTADO

Común / Optativo: Optativo. Orientaciónes Curriculares. Profesional Integral. 5to: 6to: 7mo: 8vo: Tipo de curso: Seleccionar Turno/s: DANIEL OTTADO Nombre del curso: Gestión de Proyectos Año de elaboración del Programa: 2015 Nombre abreviado: GProy (Será completado por Bedelía) Carrera: Licenciatura en Comunicación Código: (Será completado por Bedelía)

Más detalles

Ges3ón de Proyectos So9ware

Ges3ón de Proyectos So9ware Ges3ón de Proyectos So9ware Tema 2.1 Integración Carlos Blanco Bueno Félix Óscar García Rubio Este tema se publica bajo Licencia: Crea5ve Commons BY- NC- ND 4.0 Objetivos Ampliar los conocimientos básicos

Más detalles

METODOLOGÍAS DE DESARROLLO DE VIDEOJUEGOS

METODOLOGÍAS DE DESARROLLO DE VIDEOJUEGOS METODOLOGÍAS DE DESARROLLO DE VIDEOJUEGOS CONTEXTUALIZACIÓN En sus comienzos, los videojuegos no eran más que juguetes desarrollados por programadores con relativa experiencia, que tenían una calidad gráfica

Más detalles

Desarrollo Ágil. Software Engineering: A Practitioner s Approach Roger S. Pressman, Ph.D. Tomás Balderas Contreras Ingeniería de Software I

Desarrollo Ágil. Software Engineering: A Practitioner s Approach Roger S. Pressman, Ph.D. Tomás Balderas Contreras Ingeniería de Software I Desarrollo Ágil Software Engineering: A Practitioner s Approach Roger S. Pressman, Ph.D. Tomás Balderas Contreras Ingeniería de Software I Coordinación de Ciencias Computacionales INAOE 2011 Preguntas

Más detalles

Ingeniería de Software II

Ingeniería de Software II Ingeniería de Software II Segundo Cuatrimestre 2007 Clase 1b: Modelos de Ciclo de Vida Buenos Aires, 23 de Agosto de 2007 Qué es un modelo del ciclo de vida de un sistema? 8Una representación estandarizada

Más detalles

SISTEMAS DE INFORMACIÓN II TEORÍA

SISTEMAS DE INFORMACIÓN II TEORÍA CONTENIDO: DETERMINACIÓN DE REQUERIMIENTOS ENTREVISTAS, CUESTIONARIOS, OBSERVACIONES JOINT APPICATION DESIGN (JAD) PROTOTIPOS, CASE, GROUPWARE Material diseñado y elaborado por: Prof. Luis Eduardo Mendoza

Más detalles

Tesista: Ing. Jose Luís Del Río Directores: M. Ing. Eduardo Diez, M.Ing. Claudio Rancan

Tesista: Ing. Jose Luís Del Río Directores: M. Ing. Eduardo Diez, M.Ing. Claudio Rancan SISTEMA DE ASISTENCIA A LA GESTIÓN DE RIESGOS EN PROYECTOS SOFTWARE DE SISTEMAS INDUSTRIALES DE AUTOMATIZACIÓN Y CONTROL Anteproyecto de Tesis de Magíster en Ingeniería del Software Tesista: Ing. Jose

Más detalles

Integración del PMBOK al RUP para proyectos de Desarrollo de Software

Integración del PMBOK al RUP para proyectos de Desarrollo de Software Integración del PMBOK al RUP para proyectos de Desarrollo de Software Fernando Torres UPG-FISI, Universidad Nacional Mayor de San Marcos (UNMSM), Av. German Amezaga s/n, Ciudad Universitaria, Lima, Perú

Más detalles

Ingeniería de Software II

Ingeniería de Software II Ingeniería de Software II Primer Cuatrimestre de 2008 Clase 2: Planificación de Proyectos de Software Buenos Aires, 27 de Marzo de 2008 Temas para hoy Repaso de la clase anterior: modelos de ciclo de vida

Más detalles

I GE IERÍA DEL SOFTWARE. Mª Dolores Carballar Falcón 28935146L

I GE IERÍA DEL SOFTWARE. Mª Dolores Carballar Falcón 28935146L I GE IERÍA DEL SOFTWARE. Mª Dolores Carballar Falcón 28935146L REFERE CIA AL SISTEMA EDUCATIVO ACTUAL. Los contenidos de este tema, están enfocados a introducir al alumno en el concepto de Ingeniería del

Más detalles

TRABAJO FINAL ESPECIALIDAD EN CONTROL Y GESTION DE SOFTWARE GESTIÓN DE CONFIGURACIÓN DE PRODUCTOS SOFTWARE EN ETAPA DE DESARROLLO

TRABAJO FINAL ESPECIALIDAD EN CONTROL Y GESTION DE SOFTWARE GESTIÓN DE CONFIGURACIÓN DE PRODUCTOS SOFTWARE EN ETAPA DE DESARROLLO TRABAJO FINAL ESPECIALIDAD EN CONTROL Y GESTION DE SOFTWARE GESTIÓN DE CONFIGURACIÓN DE PRODUCTOS SOFTWARE EN ETAPA DE DESARROLLO Autor: Lic. Claudio Jorge Rancán Directora: M.Ing. Paola Britos Julio 2003

Más detalles

Un modelo de proceso es una representación abstracta de un proceso. Presenta una descripción de un proceso desde una perspectiva particular.

Un modelo de proceso es una representación abstracta de un proceso. Presenta una descripción de un proceso desde una perspectiva particular. El proceso software Un conjunto estructurado de actividades y resultados asociados que conducen a la creación de un producto de software Especificación: Definir la funcionalidad y las restricciones en

Más detalles

Escuela Politécnica Superior. Ciclo de Vida de los Proyectos. Capítulo 4. daniel.tapias@uam.es. Dr. Daniel Tapias Curso 2014 / 15 PROYECTOS

Escuela Politécnica Superior. Ciclo de Vida de los Proyectos. Capítulo 4. daniel.tapias@uam.es. Dr. Daniel Tapias Curso 2014 / 15 PROYECTOS Escuela Politécnica Superior Ciclo de Vida de los Proyectos Capítulo 4 Dr. Daniel Tapias Curso 2014 / 15 daniel.tapias@uam.es PROYECTOS PROGRAMA DE LA ASIGNATURA Capítulo 1: Introducción. Capítulo 2: Qué

Más detalles

PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ

PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ FACULTAD DE CIENCIAS E INGENIERÍA ANÁLISIS, DISEÑO E IMPLEMENTACIÓN DE UNA HERRAMIENTA CASE PARA LA GESTIÓN DEL ALCANCE DE PROYECTOS BASADA EN WBS Tesis para optar

Más detalles

GESTIÓN DE PROYECTOS DE SOFTWARE

GESTIÓN DE PROYECTOS DE SOFTWARE GESTIÓN DE PROYECTOS DE SOFTWARE LA PLANIFICACIÓN de proyectos se define como la predicción de la duración de las actividades y tareas a escala individual. LA ESTIMACIÓN se define como la predicción de

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

Glosario. actividad. 1. (tarea) 2. es un subproceso que no requiere mas descomposición.

Glosario. actividad. 1. (tarea) 2. es un subproceso que no requiere mas descomposición. Glosario Aclaraciones Los conceptos del glosario están ordenados alfabéticamente. Un concepto puede ser un único término como meta o una frase como ambiente de ingeniería de software centrado en procesos.

Más detalles

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Parte 3: TRP Avanzado MAYO 2009 Tabla de Contenidos PREFACIO...5 DESARROLLO Y MANTENCIÓN DE SOFTWARE...6 DESARROLLO DE REQUERIMIENTOS...7

Más detalles

GESTIÓN DE SOFTWARE INFORME SOBRE. Evaluación de Productos UNIVERSIDAD DE LA REPUBLICA - FACULTAD DE INGENIERÍA. Grupo 2

GESTIÓN DE SOFTWARE INFORME SOBRE. Evaluación de Productos UNIVERSIDAD DE LA REPUBLICA - FACULTAD DE INGENIERÍA. Grupo 2 UNIVERSIDAD DE LA REPUBLICA - FACULTAD DE INGENIERÍA GESTIÓN DE SOFTWARE INFORME SOBRE Evaluación de Productos Grupo 2 Marcelo Caponi 3.825.139-0 Daniel De Vera 4.120.602-3 José Luis Ibarra 4.347.596-3

Más detalles

Guía Rápida Proceso de Desarrollo OPENUP/OAS Universidad Distrital Francisco José de Caldas Oficina Asesora de Sistemas

Guía Rápida Proceso de Desarrollo OPENUP/OAS Universidad Distrital Francisco José de Caldas Oficina Asesora de Sistemas Guía Rápida Proceso de Desarrollo OPENUP/OAS Universidad Distrital Francisco José de Caldas Oficina Asesora de Sistemas Información General del Documento Versión Actual del Documento 0.0.0.7 Descripción

Más detalles

Ingeniería de Software Dr. Marcello Visconti Z. Ingeniería de Software

Ingeniería de Software Dr. Marcello Visconti Z. Ingeniería de Software Universidad Técnica Federico Santa María Departamento de Informática Ingeniería de Software Dr. Marcello Visconti Z. Programa Proceso de Software y Paradigmas de Desarrollo Gestión de Proyectos Fases del

Más detalles

Liberando el sistema. Ayudar a los usuarios a entender y usar el sistema. Entrenamiento Documentación Solución de Problemas Conversión Instalación

Liberando el sistema. Ayudar a los usuarios a entender y usar el sistema. Entrenamiento Documentación Solución de Problemas Conversión Instalación Liberando el sistema Ayudar a los usuarios a entender y usar el sistema Distintos tipos de usuarios Entrenamiento Documentación Solución de Problemas Conversión Instalación May-12 Ing. de Software Liberación

Más detalles

Objetivos FACULTAD DE INGENIERIA. DEPARTAMENTO DE INGENIERIA DE SISTEMAS. Código de la asignatura 4070. Fecha de Actualización Julio 24 de 2012

Objetivos FACULTAD DE INGENIERIA. DEPARTAMENTO DE INGENIERIA DE SISTEMAS. Código de la asignatura 4070. Fecha de Actualización Julio 24 de 2012 Nombre de la asignatura Ingeniería de Software Código de la asignatura 4070 Fecha de Actualización Julio 24 de 2012 Intensidad horaria semanal Horas Contacto 4 Horas Trabajo Independiente 8 Créditos Académicos

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

Pontificia Universidad Católica Argentina

Pontificia Universidad Católica Argentina Carrera : Ingeniería Informática Pontificia Universidad Católica Argentina PROGRAMA DE INGENIERÍA DE SOFTWARE I 2010 Ubicación en el Plan de Estudios : 3 er Año, cuatrimestral Carga Horaria : 8 hs / semana

Más detalles

Preparación al Examen PMP - Introducción al PMBOK

Preparación al Examen PMP - Introducción al PMBOK La Guía del PMBOK ó Guía de los Fundamentos de la Dirección de Proyectos constituye un compendio de conocimientos de la profesión de dirección de proyectos. Al igual que en otras profesiones, como la abogacía,

Más detalles

Ingeniería de Software I. Sebastián Uchitel y Víctor Braberman 1er Cuatrimestre 2009

Ingeniería de Software I. Sebastián Uchitel y Víctor Braberman 1er Cuatrimestre 2009 Ingeniería de Software I Sebastián Uchitel y Víctor Braberman 1er Cuatrimestre 2009 Quienes somos? 2 Quienes son? 3 Objetivos del Curso Entender el rol fundamental que juega la construcción y análisis

Más detalles

Norma UNE 66904-6 :2000 ISO 10006:1997. Directrices para la calidad en la gestión de proyectos

Norma UNE 66904-6 :2000 ISO 10006:1997. Directrices para la calidad en la gestión de proyectos Norma UNE 66904-6 :2000 ISO 10006:1997 Directrices para la calidad en la gestión de proyectos Definiciones I Proyecto: Proceso único que consiste en un conjunto de actividades coordinadas y controladas

Más detalles

Instruir al alumno con los conceptos, modelos, teorías y principios básicos estudiados en la Ingeniería de Software

Instruir al alumno con los conceptos, modelos, teorías y principios básicos estudiados en la Ingeniería de Software Universidad de Colima Dirección General de Educación Superior Facultad de Ingeniería Mecánica y Eléctrica Licenciatura en Ingeniería en Sistemas Computacionales I. DATOS GENERALES P R O G R A M A A N A

Más detalles

GRUPO DE PROCESOS DE: PLANIFICACIÓN. www.sistemas-expertos.com 1

GRUPO DE PROCESOS DE: PLANIFICACIÓN. www.sistemas-expertos.com 1 GRUPO DE PROCESOS DE: PLANIFICACIÓN 1 OBJETIVOS: GRUPO DE PROCESOS DE PLANIFICACIÓN Identificar la relación del grupo de procesos de Planeación con los procesos de Iniciación, Ejecución, Seguimiento y

Más detalles

Nomenclador de cargos

Nomenclador de cargos Nomenclador de cargos ROLES Áreas de I T Definición de módulos y roles Versión: 1.0 Pagina 1 Módulos interactuantes en un área de IT 1. Infraestructura Tecnológica 2. Producción de Software 3. Asistencia

Más detalles

Resumen. Introducción

Resumen. Introducción Arquitectura de software para Sistemas de Información Ambiental Urciuolo Adriana, Iturraspe Rodolfo, Parson Ariel, Esteban Natalia Universidad Nacional de la Patagonia San Juan Bosco Sede Ushuaia, Darwin

Más detalles

Por qué definir un modelo de procesos?

Por qué definir un modelo de procesos? Por qué definir un modelo de procesos? Propuesta Administración de Proyectos Qué es un Proceso? Serie de pasos o actividades a realizar para transformar ciertas entradas en salidas. Procedimientos y Métodos

Más detalles

A continuación se describe con mayor detalle cada una de las unidades: UNIDAD 2: Calidad en el desarrollo, adquisición, operación y mantenimiento del

A continuación se describe con mayor detalle cada una de las unidades: UNIDAD 2: Calidad en el desarrollo, adquisición, operación y mantenimiento del 1. OBJETIVOS: Incorporar los conceptos de indicador, métrica, medida, escala de medición, y proceso de medición. Entender la importancia de los indicadores de desempeño de procesos, su medición y seguimiento.

Más detalles

CICLO DE VIDA DEL SOFTWARE. Una aproximación lógica a la adquisición, el suministro, el desarrollo, la explotación y el mantenimiento del software

CICLO DE VIDA DEL SOFTWARE. Una aproximación lógica a la adquisición, el suministro, el desarrollo, la explotación y el mantenimiento del software 3.010 CONCEPTO DE CICLO DE VIDA Una aproximación lógica a la adquisición, el suministro, el desarrollo, la explotación y el mantenimiento del software IEEE 1074 Un marco de referencia que contiene los

Más detalles

Boletín de Asesoría Gerencial SOA: enfoque técnico orientado a procesos

Boletín de Asesoría Gerencial SOA: enfoque técnico orientado a procesos Espiñeira, Sheldon y Asociados No. 4-2010 Contenido Haga click en los enlaces para navegar a través del documento Haga click en los enlaces para llegar directamente a cada sección 4 Introducción 4 Qué

Más detalles