AGILA2: Acceso Generalizado a Internet desde LinEx Avanzado 2. Subproyecto 5

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

Download "AGILA2: Acceso Generalizado a Internet desde LinEx Avanzado 2. Subproyecto 5"

Transcripción

1 AGILA2: Acceso Generalizado a Internet desde LinEx Avanzado 2 Subproyecto 5 Estudio de nuevas metodologías aplicables al software libre y la adaptación sobre las métricas actuales. Javier Corral García y José Luis González Sánchez GÍTACA Grupo de Investigación de Ingeniería Telemática Aplicada y Comunicaciones Avanzadas UNIVERSIDAD DE EXTREMADURA

2 Índice de contenido I. Introducción...4 II. Análisis de las métricas más usadas en estos momentos en los desarrollos software La metodología catedral sobre el software libre La metodología bazar sobre el software libre Desarrollo de un proyecto Bazar, ventajas e inconvenientes Éxito frente al modelo catedral: Metodologías actuales aplicables a un proyecto Estructura general de Merise Estructura general de SSADM Estructura general de Métrica versión Métrica versión Metodologías ágiles Metodologías ágiles versus metodologías tradicionales Metodologías ágiles respecto a la metodología bazar XP (Programación extrema)...19 La programación extrema y el software libre Metodología Crystal Desarrollo de software adaptable Scrum Desarrollo manejado por rasgos Método de desarrollo de sistema dinámico...24 III. Diseño y propuesta de soluciones para los problemas planteados Propuesta de metodología y métrica a aplicar en un desarrollo software Por qué una metodología bazar? Por qué una metodología catedral? Entre la catedral y el bazar Seguridad por oscuridad Acercando el bazar a la catedral...28 Buscando la calidad del software...28 Community source...28 Hacia un modelo híbrido...29 Herramientas para la fase libre...31 IV. Conclusiones

3 3

4 I. Introducción E n el movimiento del software libre cada vez se va haciendo más necesario aplicar métodos e ideas tradicionales de ingeniería software, con el fin de alcanzar una calidad óptima del mismo, y al mismo tiempo mejorar la planificación y el tiempo de desarrollo. Partiendo del hecho de que actualmente muchas empresas se plantean la necesidad de aplicar algún tipo de metodología de desarrollo software, el presente documento pretende cubrir uno de los objetivos del proyecto Agila 2: impulsar el uso de métodos de ingeniería software, sin perder de vista los requerimientos especiales que tiene el software libre. De este modo, a través de un extenso y elaborado estado del arte, pretendemos orientar el desarrollo de una metodología que aporte calidad a cualquier proyecto software, sirviendo como medio para que toda empresa pueda seguir una estructura de buen método de desarrollo. La metodología de un proyecto de desarrollo software define siempre quién debe hacer qué, cuándo y cómo debe hacerlo. En concreto, la metodología es el conjunto de procedimientos, técnicas y herramientas además de una documentación adicional, que permite a los desarrolladores crear software. Puede seguir uno o varios modelos de ciclos de vida, los cuales indican qué es lo que hay que obtener a lo largo del desarrollo del proyecto, pero no cómo hacerlo. El movimiento del software libre, unido a la explosión mediática de Internet, supuso la aparición de nuevos métodos de desarrollo. Las nuevas metodologías rompían con lo establecido por las metodologías tradicionales, gestionadas por responsables que distribuyen y supervisan todo el trabajo de forma cerrada. En 1997, Eric S. Raymond escribió un ensayo a favor del software libre titulado The Cathedral & the Bazaar (La catedral y el bazar) [1]. En él, Raymond analizaba el surgimiento de GNU/Linux y un proyecto de software libre creado para comprobar las diferencias existentes entre los modelos de desarrollo tradicionales y los emergentes: el modelo de construcción cuidadoso y planificado de una catedral (del software propietario) y el bazar (del código abierto), en permanente crecimiento pero aparentemente caótico. Así, detallaba el enfoque cerrado desarrollado bajo una gestión centralizada propia de las empresas comerciales de software, con la comunidad global de código abierto responsable del desarrollo y éxito creciente de Linux. Por otro lado, las metodologías ágiles también se centran en una organización menos formal y jerárquica, intentando enfocar las metodologías tradicionales hacia los resultados y el factor humano, dando más valor al individuo y a la colaboración con el cliente, y eliminando actividades sobre la elaboración y mantenimiento de documentos formales de especificación que no tengan relación directa con el producto final. Mientras que la metodología bazar y las ágiles, tienen cada vez mayor éxito, las tradicionales no se han distinguido precisamente por ser exitosas, y menos aún por su popularidad, debido a su naturaleza burocrática que acaba retardando el ritmo del desarrollo en sí, siendo inadecuadas para proyectos donde el entorno sea volátil o los requisitos no se conozcan con exactitud. Sin embargo, las nuevas metodologías también se enfrentan a una serie de inconvenientes, como la falta de 4

5 intereses de los desarrolladores voluntarios, o la escasa confianza de los clientes en sistemas desarrollados de forma abierta, donde el código es accesible para cualquiera. Partiendo de que, ni la metodología bazar, ni la catedral son del todo correctas, y apoyándonos en el éxito de las metodologías ágiles así como de diversos estudios realizados con anterioridad por diversos autores, este documento justifica el aplicar al desarrollo tradicional los conceptos del software libre, de forma que, tanto desarrolladores como clientes acaben valorando los beneficios que podrían obtener creando comunidades al estilo bazar alrededor de los proyectos de desarrollo, liberando versiones constantemente de forma que pudieran ser testeadas frecuentemente, y evitando en la mayor medida posible, el problema de la seguridad por oscuridad que presenta la metodología catedral, sin subestimar la importancia de un diseño modular con un código de calidad óptima. 5

6 II. Análisis de las métricas más usadas en estos momentos en los desarrollos software 1. La metodología catedral sobre el software libre S e trata del método tradicional que, hoy en día, emplean la mayoría de los fabricantes de software. En el estilo catedral, el desarrollo de software está dirigido de manera centralizada, y el proceso de desarrollo está restringido a un grupo de programadores, quienes trabajan fuertemente en la depuración del código con la finalidad de que los usuarios puedan ver menos errores en cada versión producida [2]. Describimos a continuación sus características principales dentro del enfoque tradicional del software propietario: Software de gran tamaño construido (a semejanza de una catedral) de manera cuidadosa y planificada por expertos. Personal seleccionado previamente y en un número adecuado para desarrollar el proyecto, teniendo siempre en cuenta que a partir de un punto determinado, los costes aumentan al incrementarse excesivamente el número de personas involucradas, además de ralentizar el desarrollo en lugar de acelerarlo. Las versiones beta no son publicadas hasta prácticamente llegar al final del proyecto, debido principalmente a que de no ser así, contendrían innumerables errores. Dichos errores son muy difíciles de encontrar, y es por ello que se requiere una fase de pruebas al finalizar el desarrollo. El código fuente es propietario y nadie más puede tener acceso a él. La figura del jefe de proyecto es muy influyente en todo el desarrollo, debiendo ser especialmente clave en la fase de diseño. La Figura 1 muestra las principales fases del modelo de desarrollo tradicional: requisitos, diseño, implementación, pruebas y mantenimiento. 6

7 Figura 1: Modelo de desarrollo tradicional Los proyectos de software libre tienen cabida en esta metodología pese a que, a priori, podemos pensar que, este modelo de creación de catedrales, solo representa a procesos como el modelo de cascada clásico o las diferentes vertientes del Rational Unified Process. En este sentido, algunos proyectos abiertos también necesitan entregas espaciadas en el tiempo que siguen una planificación muy estricta, con pocas entregas de software y ciclos largos con varias etapas entre cada una de las entregas. Además, para Raymond [1], estos proyectos libres se encuentran fuertemente centralizados, ya que unas pocas personas son las que realizan el diseño e implementación del software. Las tareas que desempeñan estas personas, así como sus roles, están perfectamente definidos y alguien que quisiera entrar a formar parte del equipo de desarrollo necesitaría que se le asignara una tarea y un rol según las necesidades del proyecto [3]. Por último, en entornos tradicionales, un grupo de individuos conduce el desarrollo, mientras que los usuarios ni contribuyen ni tienen acceso al código. En el software libre, potencialmente cualquiera tiene el derecho a acceder y modificar el código fuente de una aplicación, sin embargo, y en este sentido, un sistema libre típico presenta una fase de catedral en la primera parte de su historia evolutiva [4]. 2. La metodología bazar sobre el software libre E n la metodología bazar, el desarrollo de software no es dirigido de manera centralizada, la construcción de la aplicación se realiza con la participación de una comunidad de interesados que libera frecuentemente cada versión desarrollada, con la finalidad de que otros puedan depurar el código [2]. Los principales beneficios de este modelo son una rápida evolución y depuración, independencia y disponibilidad permanente y la producción de un software estable de alta calidad y bien documentado. Detallamos a continuación sus características más destacables: A diferencia de la metodología bazar, al comenzar el desarrollo únicamente existe una idea, pero ésta no es del todo clara, y se va perfilando a medida que avanza el proyecto. 7

8 El código fuente es abierto y está disponible públicamente (cualquiera puede leerlo y modificarlo), y son frecuentes las liberaciones de versiones, aunque en la mayor parte de los casos, éstas estén incompletas o sean inestables. El proceso de depuración de un proyecto de software libre es sinónimo de la fase de mantenimiento del ciclo de vida tradicional de un proyecto software [4]. Un red de usuarios y desarrolladores revisa y modifica el código producido, de modo que el viejo dicho el trabajo compartido es más llevadero describe las razones por las que la mayoría de los proyectos de software libre tienen éxito [5]. El número de colaboradores que trabajan simultáneamente en el proyecto es ilimitado. Esto unido a la característica anterior, y al hecho de que la mayoría de ellos son además usuarios del propio software, hace que los errores estén siendo encontrados continuamente, con facilidad y de manera paralela al desarrollo. La estructura organizativa no está clara, de hecho, no suele existir jerarquía alguna en estos proyectos. Sí existen una serie de normas para poder participar en el proyecto, pero el compromiso es libre, pudiendo cada colaborador dedicarle el tiempo que estime oportuno. Los usuarios sin perfil técnico pueden sugerir nuevos requisitos, escribir documentación y tutoriales, o poner de manifiesto problemas de usabilidad [4]. A continuación veamos una tabla que enfrenta las principales características vistas en el desarrollo tradicional y en el de software libre: Desarrollo tradicional Construcción de catedrales: objetivos requerimientos planteados detalladamente antemano. Desarrollo de software libre y Colaboración en bazares: cada desarrollador de aporta las funcionalidades que estima recomendables. Jerarquía de liderazgo descendente. Liderazgo emergente, no impuesto. Asignación de tareas. Cada desarrollador es libre de elegir en qué trabajar. Equipos estables de tamaño controlado. Innumerables colaboradores, con alta rotación. Control estricto y seguimiento continuo de Disponibilidad total de los desarrolladores para actividades. invertir el tiempo que consideren oportuno. Desarrolladores ubicados generalmente en la Desarrolladores rara vez comparten localización misma localización. física. Motivación extrínseca. Motivación intrínseca. Tabla 1: Características de los desarrollos tradicionales y de software libre 2.1. Desarrollo de un proyecto Bazar, ventajas e inconvenientes Los proyectos bazar a menudo surgen por las necesidades de un usuario-desarrollador, y 8

9 suelen comenzarse a partir de trabajos ya realizados, siendo la reusabilidad de código básica en este tipo de modelo de desarrollo. A partir de ahí empieza a ser esencial la colaboración de los usuarios que se involucren en el proyecto, siendo importante la figura de los líderes, que deben cumplir una serie de características como son la humildad ante el resto de desarrolladores, la capacidad para motivarles, y la virtud de reconocer en ellos ideas mejores o innovaciones adecuadas para continuar el proyecto por otros caminos. La comunidad de voluntarios trabaja sobre el código fuente, modificando dicho código, las funcionalidades de la aplicación, reportando y corrigiendo errores y, solicitando nuevas características. Siendo enviado continuamente este trabajo a los líderes del proyecto, con el fin de añadirse al núcleo estable de la aplicación (Figura 2) [6]. Figura 2: Modelo de desarrollo bazar [6] Algunas críticas recibidas por el trabajo de Raymond [1] se basan en el hecho de que su obra es únicamente un ensayo, sin rigor científico y asistemático. Algunos críticos ven en Linux más un modelo de catedral que no un bazar, quejándose además del intento de Raymond de generalizar el caso de Linux a todo el software libre, donde creen que realmente existe una estructura piramidal de mando, con responsabilidades distribuidas aunque no de manera explícita. A primera vista resulta obvio pensar que una metodología como la que describimos se enfrenta siempre a una serie de desafíos, como puede ser el hecho de que los desarrolladores no participen en los proyectos bajo contratos laborales, sino que lo hagan libremente sin que ninguna autoridad centralizada defina sus funcionalidades. El desarrollo es distribuido por toda la red, con la dificultad que entraña coordinar a un innumerable grupo de colaboradores con alta rotación. Según Bruce Perens, líder del proyecto Debian en 1997, intentar liderar esta comunidad es como arrear gatos. A todo esto habría que añadir además el desafío que supone bazar frente a distintos paradigmas tradicionales. Por ejemplo la conocida como ley de Brooks : añadir más personal a un proyecto retrasado, lo retrasa más [7], que explica cómo la necesidad de intercomunicación se ve 9

10 minimizada por la elegancia del código y la modularidad del diseño, se contrapone directamente a la ley de Linus (bautizada por Eric S. Raymond [1]): dados muchos ojos, todos los errores serán obvios, que reduce de manera indiscutible la necesidad de un equipo dedicado a pruebas. Por contra, algunos estudios establecen que la aplicación de la ley de Linus puede llevar a problemas en el mantenimiento y la seguridad del software [8] [9], aludiendo al bajo número de contribuciones realizadas por gente realmente externa al desarrollo, es decir, colaboradores que no pertenecen al núcleo central que trabaja en los sistemas, debido a que ciertos proyectos a la larga desconfían de contribuciones externas, precisamente por miedo a la introducción de códigos con errores difíciles de encontrar. Raymond mantiene que si la citada ley no fuese cierta, un proyecto tan complejo como el kernel de Linux, habría fracasado por causa de interacciones imprevistas y errores muy profundos pasados inadvertidos durante el desarrollo del proyecto. Sin embargo, bastaría fijarse en la relativa ausencia de errores en el código de Linux para demostrar su certeza, y por añadidura, la superioridad del modelo de desarrollo del software libre frente al del software propietario. Así, mientras que en el modelo catedral usado en software propietario los errores suelen necesitar meses de revisión exhaustiva para comenzar a confiar en que todos han sido eliminados, en el bazar se asume a priori que los errores son evidentes o empiezan a serlo a raíz de que son publicados ante el innumerable grupo de colaboradores que participa en cada proyecto, liberándose versiones constantemente y bordeando así las desmoralizaciones que se sufren en el software propietario cuando las versiones largamente esperadas no resultan perfectas [1]. Otros paradigmas tradicionales a los que se enfrenta la metodología bazar son, por ejemplo, la ineficiencia de las líneas de código paralelas: que el software libre soluciona usando mecanismos de resolución de conflictos y una selección de la mejor opción; la criticidad de la ubicación física, frente a la minimización de la necesidad de comunicación entre desarrolladores como consecuencia de la modularidad y la autoexplicación del código; o, finalmente, el impacto causado por la alta rotación de desarrolladores: mitigado gracias a diseños sencillos y de calidad, en cuyos códigos es innecesaria la documentación adicional debido a su alta calidad Éxito frente al modelo catedral: Sin embargo, es evidente el éxito de la metodología bazar en proyectos como Linux, a la altura de los sistemas operativos comerciales más elaborados y con una notable presencia de sus servidores en la red. Como muestra de dicho éxito, basta con mencionar que entre las entidades que usan Linux se encuentra la Bolsa de Nueva York. Por otro lado, un estudio sobre la distribución Red Hat en su versión 7.1 reveló que ésta en particular posee más de 30 millones de líneas de código real. Utilizando el modelo de cálculo de costos COCOMO, puede estimarse que esta distribución requeriría programadores por año para su desarrollo. De haber sido desarrollado por medios convencionales de código cerrado, hubiera costado más de mil millones de dólares en los Estados Unidos [10]. Desde principios del año 2001 ha ido creciendo el apoyo y respaldo por parte de importantes fabricantes de hardware (como IBM, Sun Microsystems, Hewlett-Packard y Novell: preinstalando Linux en algunos modelos de portátiles y ordenadores de sobremesa), y el respaldo de compañías de software que permiten que aplicaciones como Nero, Java, Google Earth y Desktop, Adobe 10

11 Reader y Flash, RealPlayer y Yahoo! Messenger estén disponibles para Linux. De este modo, actualmente son bastantes las empresas de ámbito internacional que comercializan soluciones basadas en Linux, como IBM o Novell, así como miles de PYMES que ofrecen productos o servicios basados en esta tecnología. Otros proyectos ejemplos del buen funcionamiento de la tecnología bazar en el software libre son Samba y Apache. Samba implementa todos los protocolos de conectividad de Windows y su éxito hizo que compañías como Silicon Graphics, Sun e IBM lo usen como parte de sus estaciones de trabajo. Apache es desde 1996 el servidor HTTP más usado en la red, alcanzando en 2005 una cuota de mercado del 70%, posicionándose a fecha de Noviembre de 2008 en un 50.34%. En la Figura 3 podemos ver el número de sitios web para cada servidor a nivel mundial, donde Apache, en primer lugar, presenta sitios, Microsoft (con su producto IIS: Internet Information Server) en segundo lugar, alcanza el número de sitios y, Google en tercer puesto (producto GFE: Google Front End) con sitios. Figura 3: Número de sitios web por servidor (Ago00 Nov08) Fuente: 3. Metodologías actuales aplicables a un proyecto L a metodología de un proyecto de desarrollo software define siempre quién debe hacer qué, cuándo y cómo debe hacerlo. En concreto, la metodología es el conjunto de procedimientos, técnicas y herramientas además de una documentación adicional, que permite a los desarrolladores crear software. Puede seguir uno o varios modelos de ciclos de vida, los cuales indican qué es lo que hay que obtener a lo largo del desarrollo del proyecto, pero no cómo hacerlo. Por norma general consta de un conjunto de fases y subfases: módulos, etapas, pasos, etc., de forma que los desarrolladores son guiados a la hora de seleccionar las técnicas a usar en cada estado del proyecto, facilitándoles la planificación, gestión, control y evaluación de los proyectos. De esta 11

12 forma, especifica: cómo se debe dividir un proyecto en etapas, qué tareas hay que realizar en cada etapa, qué salidas se producen y cuándo, qué restricciones se aplican, qué herramientas se utilizan, cómo se gestiona y controla un proyecto. Por tanto, la metodología representa el camino para desarrollar la aplicación software de manera sistemática, sirviendo de manual o guía puesta en práctica al abordar la construcción de un sistema. Las metodologías usan un ciclo de vida determinado y siguen las fases de especificación, diseño, etc. de un modo concreto, algunas incluso apoyadas por herramientas hechas a medidas. Lamentablemente no existe una metodología de software universal, dadas las características particulares de cada proyecto: equipo de desarrollo, recursos, etc.. Además, en el desarrollo convencional (sin metodología) los resultados finales son impredecibles, ya que no hay forma de controlar lo que está sucediendo en el proyecto, afectando los cambios organizativos de forma negativa en el proceso de desarrollo. Las características deseables y destacables de cualquier metodología son las siguientes: Existencia de reglas predefinidas. Cobertura total del ciclo de desarrollo. Verificaciones intermedias. Planificación y control. Comunicación efectiva. Utilización sobre un abanico amplio de proyectos. Fácil formación. Herramientas CASE. Actividades que mejoren el proceso de desarrollo. Soporte para el mantenimiento. Soporte para la reutilización de software. Las metodologías (tanto comerciales como en el ámbito académico y de investigación) pueden ser agrupadas en estructuradas y orientadas a objetos. En el enfoque estructurado podemos destacar Métrica versiónes 2 y 3, Merise, SSADM, etc. y en el enfoque orientado a objetos: Métrica versión 3 (en parte), RUP, XP, etc. Veamos a continuación las principales metodologías de desarrollo estructuradas gubernamentalmente: Merise en Francia, SSADM en Reino Unido, y finalmente Métrica 3 en España Estructura general de Merise MERISE empezó a sentar sus bases en 1972 gracias a un equipo universitario de ingenieros de Aix-en-Provence, viendo la luz la primera versión a finales de En Septiembre de 1977, el proyecto fue iniciado por el Centre Technique Informatique del Ministerio de Industria Francés para cubrir las necesidades de las empresas, así como de la propia administración, finalizando en Mayo de 1978 y estableciendo MERISE como metodología de análisis y diseño de sistemas de 12

13 información. Esta metodología aportó un ciclo de vida más largo que los existentes hasta la fecha, materializándose en un conjunto definido de etapas, e incluyendo dos ciclos complementarios, uno de abstracción y otro de decisión. El primero recoge el proyecto en base a tres niveles de abstracción: conceptual, organizativo y físico. Distinguiéndose además dos subniveles en cada nivel: un modelo de datos y otro de tratamientos. Las fases de la metodología MERISE son: Estudio preliminar. Estudio detallado. Implementación. Realización y puesta en marcha Estructura general de SSADM El gobierno británico planteó la necesidad de crear una metodología que desarrolló posteriormente entre la Central Computing Telecommunications Agency (CCTA) y Learmonth and Burchett Management Systems (LBMS), dando como resultado la metodología SSADM (Structures Systems Analysis and Design Method). Los aspectos más destacables de SSADM son: Énfasis en los usuarios: sus requisitos y participación. Definición del proceso de producción: qué hacer, cuándo y cómo. Tres puntos de vista: datos, eventos y procesos. Máxima flexibilidad en herramientas y técnicas de implementación. SSADM proporciona un conjunto de procedimientos para llevar a cabo el análisis y diseño, pero tiene grandes carencias. En concreto, no cubre aspectos como la planificación estratégica ni entra en la construcción del código Estructura general de Métrica versión 2 Se trata de una metodología propuesta por el Ministerio de Administraciones Públicas del Gobierno de España, para que todas las organizaciones sigan el mismo modelo, y unificar de esa forma los criterios para lograr una mayor homogeneidad y eficiencia en las aplicaciones informáticas. Métrica versión 2 surgió a raíz de una revisión realizada sobre el proyecto inicial de Métrica, con el objetivo básico de obtener una nueva versión, debido a varios motivos: principalmente por 13

14 mejorar la versión anterior fechada en 1989, responder a la demanda por parte de los centros informáticos de una referencia para el desarrollo de sistemas de información, contar con una metodología compatible con EuroMétodo, y finalmente aprovechar un mercado de herramientas CASE que había crecido ampliamente desde que se realizó la primera versión de Métrica. Fue diseñada por un grupo de trabajo constituido por personal procedente de distintos ministerios y organismos de la administración española, con la asistencia externa de la empresa Coopers & Lybrand. Se trata de una guía formal, aunque flexible en su utilización, para la planificación, análisis, diseño y construcción e implantación de sistemas software, empleando conceptos y técnicas de ingeniería de sistemas y tecnología de la información [11]. Para construir en base a Métrica versión 2, es necesario pasar por unas etapas intermedias que aseguran la calidad en la aplicación que está siendo construida, mediante la elaboración de un marco homogéneo de referencia (para verificar que los productos creados tengan niveles aceptables de calidad), y el cumplimiento de las previsiones iniciales de plazo y costes Métrica versión 3 [12]: Métrica 3 es actualmente la metodología oficial de desarrollo de aplicaciones informáticas de la administración española. Comenzando su elaboración en 1996, su punto de partida es la versión 2.1 mencionada anteriormente. Se trata de una metodología mixta, pues cubre tanto el desarrollo estructurado como el orientado a objetos, e incluye procesos como los interfaces (que no forman parte de lo que se entiende como ciclo de vida). Además, tiene en cuenta la tecnología cliente/servidor y el desarrollo de interfaces gráficas de usuario (IGU). Está basada en el modelo de procesos del ciclo de vida de desarrollo ISO/IEC (Information Technology Software Life Cycle Processes) así como en la norma ISO/IEC SPICE (Software Process Improvement And Assurance Standars Capability Determination), y otros estándares que se muestran en la Figura 4. Figura 4: Composición de Métrica Versión 3 Los objetivos que persigue son, principalmente: proporcionar un marco estratégico para el desarrollo de los sistemas de información dentro de las organizaciones; enfatizar el análisis de requisitos para que, de esta forma, los productos satisfagan las necesidades de los usuarios; mejorar 14

15 la productividad de los departamentos de sistemas de información, permitiendo una mayor adaptabilidad a los cambios y reutilización; desarrollar procesos que permitan una comunicación más fluida entre todos los miembros involucrados en la producción de software; y facilitar la operación y mantenimiento de los productos obtenidos. Métrica 3 por una parte consta de procesos principales: relativos a la planificación, desarrollo y mantenimiento de los sistemas de información, y por otra, de interfaces que definen actividades orientadas a la mejora y perfeccionamiento de los procesos principales, con el fin de garantizar la consecución del objetivo del desarrollo. De esta forma, cada proceso se divide en actividades, teniendo cada actividad una descripción y una tabla de tareas propias. Cada tarea a su vez tiene la correspondiente descripción, definiendo los productos de entrada que necesita, los que genera de salida, así como las prácticas necesarias para llevar a cabo la tarea y los participantes. Una de las principales características de Métrica 3 es que es flexible en su estructura, al no ser obligatorio seguir todos los procesos o actividades, es decir, se adapta en función de las necesidades de cada proyecto. Tampoco es necesario realizar dichas actividades secuencialmente, ya que en ocasiones será deseable realizar su ejecución en paralelo. Del mismo modo que ISO/IEC 12207, Métrica está orientada al proceso, siendo en su versión 3 los siguientes: Planificación de Sistemas de Información (PSI). Desarrollo de Sistemas de Información (DSI). Dividido a su vez en cinco subprocesos: Estudio de Viabilidad del Sistema (EVS). Análisis del Sistema de Información (ASI). Diseño del Sistema de Información (DSI). Construcción del Sistema de Información (CSI). Implantación y Aceptación del Sistema (IAS). Mantenimiento de Sistemas de Información (MSI). Además, como hemos mencionado anteriormente, proporciona también cuatro interfaces que definen actividades orientadas a mejorar y perfeccionar los principales procesos, cara a garantizar la consecución del objetivo del desarrollo. En concreto se trata de la Gestión de Proyectos (GP), Seguridad (SEG), Aseguramiento de la Calidad (CAL) y Gestión de la Configuración (GC). Por otro lado, distingue entre las técnicas de desarrollo, en las que engloba los casos de uso, diagramas de clases y de flujo de datos, etc.; las técnicas de gestión de proyectos, donde entrarían las técnicas de estimación, staffing size, planificación, etc.; y las prácticas: análisis de impacto, presentaciones, prototipado, etc Metodologías ágiles El desarrollo ágil de software es un paradigma basado en procesos ágiles, que intenta evitar los inconvenientes de las metodologías tradicionales, promoviendo iteraciones en el desarrollo a lo 15

16 largo de todo el ciclo de vida del proyecto, y enfocándose hacia los resultados y el factor humano. Esta es la filosofía de las metodologías ágiles, las cuales dan mayor valor al individuo, a la colaboración con el cliente, y al desarrollo incremental del software con iteraciones muy cortas. Es decir, al igual que el software libre, se centran en una organización menos formal y jerárquica y más centrada en la persona, de forma que se produzca un sistema de gestión con la cantidad correcta de funcionalidades, incluyendo el sistema final el número mínimo de características necesarias para satisfacer al cliente. Además, eliminan actividades sobre la elaboración y mantenimiento de documentos formales de especificación que no tengan relación con el producto final. Pese a ser enfoques muy diferentes, las metodologías de desarrollo ágiles y el software libre presentan muchas concordancias como, por ejemplo, los principios y valores básicos [13]. Así, se asemejan en varios puntos: las bases de ambas aproximaciones se establecieron hace bastantes años, sin embargo han cobrado interés de un tiempo a esta parte, tanto la metodología del software libre [14], como las ágiles. Ambas rompen con lo establecido en las metodologías tradicionales, y lo que es más importante, han tenido éxito (basta referenciar los proyectos MozillaFirefox [15] y C3). Este enfoque está mostrando su efectividad en proyectos con requisitos muy cambiantes, y cuando se exige reducir drásticamente los tiempos de desarrollo pero manteniendo una alta calidad. Las metodologías ágiles están revolucionando la manera de producir software y, a la vez, generando un amplio debate entre sus seguidores y quienes, por escepticismo o convencimiento, no las ven como alternativa para las metodologías tradicionales. La Figura 5 [16], muestra una gráfica que expresa como crece el coste de introducir cambios, conforme avanza la vida del proyecto, en proyectos de enfoque tradicional, y en aquellos desarrollados mediante metodologías ágiles. Figura 5: Coste de introducir cambios en proyectos de enfoque tradicional y de metodologías ágiles [16] En este apartado se presenta resumidamente el contexto en el que surgen las metodologías ágiles, sus valores, principios y comparación con las metodologías tradicionales. Además, se 16

17 describen brevemente las principales propuestas, especialmente Programación Extrema (extreme Programming, XP) la metodología ágil más popular en la actualidad [17]. Estas metodologías están especialmente orientadas para proyectos que necesitan de una solución a medida, con una elevada simplificación, y sin dejar de lado el aseguramiento en la calidad del producto. Las metodologías ágiles se centran en el factor humano y el producto software, es decir, dan más valor al individuo, a la colaboración del cliente y al desarrollo incremental del software con iteraciones muy cortas [18]. Partiendo de ahí, la base de cualquier metodología ágil es siempre minimizar los riesgos, desarrollando software en periodos cortos de tiempo. De este modo, el software desarrollado en una unidad de tiempo es denominado iteración (del ciclo de vida), debiendo durar ésta del orden de una a cuatro semanas. Asimismo, cada iteración incluye planificación, análisis de requerimientos, diseño, codificación, revisión y documentación. Un punto importante es que cada iteración no debe añadir demasiada funcionalidad, pero sí ser en sí mismo una versión incompleta pero sin errores, volviendo a evaluar las prioridades del proyecto al finalizar dicha iteración. El manifiesto ágil está fundamentado en una serie de valores: se orienta al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas, siendo las personas el principal factor de éxito de un proyecto software, de forma que es más importante construir previamente un buen equipo de trabajo y dejar que sea éste quien construya el entorno de desarrollo en base a sus necesidades; es más esencial la idea de desarrollar software que funciona, que conseguir una buena documentación (la regla es no producir documentos, a menos que sean necesarios de forma inmediata para tomar una decisión importante); hay que dar más importancia a la colaboración con el cliente que a la negociación de un contrato, de forma que exista una interacción constante entre el cliente y el equipo de desarrollo, lo que marcará la marcha del proyecto, asegurando su éxito; por último, responder a los cambios más que seguir estrictamente un plan, pues la habilidad de responder a los cambios que puedan surgir a lo largo del proyecto (en los requisitos, en la tecnología, en el equipo) es otro factor que determina el éxito o fracaso del mismo, por lo tanto la planificación no debe ser estricta sino flexible y abierta [18] y [19]. Por otro lado, los métodos ágiles suelen ser criticados debido a su documentación técnica: escasa y poco disciplinada, debido a que dan prioridad a las comunicaciones cara a cara en lugar de a la documentación formal. Los equipos desarrolladores suelen estar localizados en una oficina abierta, denominadas habitualmente plataformas de lanzamiento (bullpen), donde tienen cabida revisores, diseñadores de iteración, escritores de documentación y ayuda, así como directores de proyecto Metodologías ágiles versus metodologías tradicionales A continuación se muestra una tabla comparativa con las principales diferencias entre las metodologías tradicionales y las recientes metodologías ágiles: 17

18 Metodologías tradicionales Metodologías ágiles Normas de estándares seguidos por el entorno Heurísticas de prácticas de producción de de desarrollo. código. Resistencia a los cambios. Preparadas para cambios durante el desarrollo del proyecto. Reglas de trabajo impuestas externamente. Reglas de trabajo impuestas por el propio equipo. Proceso controlado, con numerosas políticas y Proceso menos normas. principios. Contrato previo. controlado, con pocos Flexibilidad en los contratos debido a la preparación para responder a los cambios. Distintas reuniones del cliente con el equipo de El cliente es parte del equipo de desarrollo. desarrollo, durante determinadas etapas del proyecto. Grupos grandes y distribuidos en diferentes Grupos pequeños trabajando en el mismo sitio. tareas. Más artefactos y roles. La arquitectura software es expresándose mediante modelos. Pocos artefactos y roles. esencial, Menos énfasis en la arquitectura del software. Tabla 2: Metodologías tradicionales versus metodologías ágiles Metodologías ágiles respecto a la metodología bazar Software libre (bazar) Metodologías ágiles El desarrollo se basa en la colaboración entre desarrolladores de todo el mundo. Las interacciones suelen realizarse a través del correo electrónico, pero las individualidades de cada programador son obvias. Más importancia de los recursos humanos y las relaciones entre ellos, frente a procesos y herramientas. Sin embargo, al contrario que en el software libre, se incentiva la conciencia de equipo. La principal documentación del proyecto reside en el propio código fuente, de donde se extraerá la documentación técnica necesaria para cada momento. El código fuente en sí, es la base principal de toda la documentación. El software operativo es más importante que toda la documentación burocrática, no relacionada con el producto final, propia de las metodologías tradicionales. El personal involucrado en el proyecto suele Es más importante la colaboración con el compaginar roles de desarrollador y cliente, de cliente que el propio contrato o su negociación forma que es como si el propio cliente en sí en sí. fuera quien desarrollase el sistema. El desarrollo y evolución del proyecto es Se trata de una metodología preparada para guiado por el cliente. Inicialmente no tienen un responder ante cualquier cambio en contra del diseño fijo definido, si no que suele ser un seguimiento de la planificación inicial. diseño básico que va creciendo a medida que se va desarrollando el proyecto. Tabla 3: Metodologías ágiles respecto a la metodología bazar 18

19 Como hemos mencionado con anterioridad, es obvio que ambos enfoques presentan numerosos planteamientos en común. La tabla anterior muestra otra comparativa, en este caso con las concordancias entre las metodologías ágiles y el software libre. A continuación, veremos métodos derivados del ágil entre los que se encuentra Scrum, Crystal Clear (cristal transparente), Programación extrema, desarrollo de software adaptativo, feature driven development, y el método de desarrollo de sistemas dinámicos XP (Programación extrema) Se trata de una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los programadores, y propiciando un buen clima de trabajo. La programación extrema se basa en cuatro principios básicos: realimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. Se define especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes [20]. Sin duda, la metodología de programación extrema está siendo la más utilizada de todas las metodologías ágiles. Se basa en esos cuatro valores principales que hemos mencionado: comunicación, retroalimentación, simplicidad y coraje, estableciendo la comprobación como fundamento del desarrollo, de forma que cada programador escribe pruebas durante la producción de su código, que van siendo integradas en el proceso de forma constante. XP construye así un proceso de diseño evolutivo, que se basa en volver a refactorizar un sistema simple en cada iteración. Todo el diseño se centra en la iteración actual y no se hace nada anticipadamente para necesidades futuras. El resultado es un proceso de diseño disciplinado, lo que es más, combina la disciplina con adaptabilidad de una manera que, indiscutiblemente, la hace la más desarrollada entre todas las metodologías adaptables [21]. La técnica usada por XP para especificar los requisitos del software se denomina historias de usuario. En ella se utilizan formatos, a través de los cuales, el cliente describe las características que desea que tenga el sistema, refiriéndose tanto a requisitos funcionales como no funcionales, de una forma breve y explícita, de forma que cada historia pueda ser implementada por los programadores en unas semanas. Por otro lado, esta metodología hace uso de los siguientes roles: programador, que además de desarrollar el código escribe las pruebas unitarias; cliente, que escribe las historias de usuario mencionadas, y además describe las pruebas funcionales de las mismas; encargado de pruebas: ayuda al cliente a escribir las pruebas funcionales; encargado de seguimiento, que va verificando el acierto producido en las estimaciones para ver si coincide el tiempo real con el estimado y, realiza el seguimiento del proceso en cada iteración; entrenador, responsable del proceso global, que vigila que se siga el proceso correctamente; consultor: miembro externo del equipo con conocimientos externos específicos; y, por último, el gestor: vínculo entre cliente y programadores. Con todo lo anterior, veremos a continuación el proceso que sigue la metodología XP. En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden. No se debe 19

20 presionar al programador a realizar más trabajo que el estimado, ya que se perderá calidad en el software o no se cumplirán los plazos. De la misma forma el cliente tiene la obligación de manejar el ámbito de entrega del producto, para asegurarse que el sistema tenga el mayor valor de negocio posible con cada iteración [18]: 1. El cliente define el valor de negocio a implementar. 2. El programador estima el esfuerzo necesario para su implementación. 3. El cliente selecciona qué construir, de acuerdo con sus prioridades y las restricciones de tiempo. 4. El programador construye ese valor de negocio. 5. Vuelve al paso 1. Figura 6: Proceso de la metodología XP [18] La programación extrema y el software libre Existe un nivel considerablemente alto de solapamiento entre los valores adoptados por las metodologías ágiles y la programación extrema en particular, y los enumerados por Raymond [1], sobre el desarrollo de código abierto [13]. Los pilares básicos en los que se sostiene la programación extrema y que mencionábamos anteriormente guardan gran relación con el software libre: Retroalimentación continua entre el cliente y el equipo de desarrollo: la metodología bazar describe la retroalimentación entre los desarrolladores, y entre estos y los clientes (Raymond expresa en sus reglas: Lo más grande después de tener buenas ideas es reconocer las buenas ideas de sus usuarios. Esto último es a veces lo mejor, y publique rápido y a menudo y escuche a sus clientes [1]). Comunicación fluida entre todos los participantes: precisamente el ideal del software libre está basado en compartir ideas mediante el código fuente, principal elemento de la comunicación entre los desarrolladores. Raymond [1] destaca la necesidad de la comunicación y las habilidades sociales para llevar a cabo un proyecto de manera exitosa. Simplicidad en las soluciones implementadas: en una de las reglas de Raymond expone: La perfección (en diseño) se alcanza no cuando ya no hay nada que añadir, si no cuando ya no hay algo que quitar [1]. 20

UNIVERSIDAD UNION BOLIVARIANA CARRERA DE INGENIERIA DE SISTEMAS

UNIVERSIDAD UNION BOLIVARIANA CARRERA DE INGENIERIA DE SISTEMAS UNIVERSIDAD UNION BOLIVARIANA CARRERA DE INGENIERIA DE SISTEMAS METODOLOGIAS AGILES PROCESO UNIFICADO AGIL (AUP) MATERIA : INGENIERIA SOFTWARE DOCENTE : LIC. ERVIN FLORES ESTUDIANTE : JORGE LUIS CORDERO

Más detalles

Tema 2. El Ciclo de Vida del Software (ISG1-ITIG)

Tema 2. El Ciclo de Vida del Software (ISG1-ITIG) Tema 2. El Ciclo de Vida del Software (ISG1-ITIG) Grupo de Ingeniería del Software Antonio José Sáenz Albanés (C.T.O) Reconocimiento No Comercial Compartir Igual - 3.0 - España 1 Objetivos del Tema Qué

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

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

La incertidumbre y la ingeniería de software María Irma Díaz

La incertidumbre y la ingeniería de software María Irma Díaz d o s La incertidumbre y la ingeniería de software María Irma Díaz Una respuesta metodológica al desafío de modificar el pensamiento para enfrentar las condiciones del presente y el futuro. A comienzos

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

METODOLOGÍA TRADICIONAL.

METODOLOGÍA TRADICIONAL. COMPARACIÓN DE METODOLOGÍAS METODOLOGÍA TRADICIONAL. Teniendo en cuenta la filosofía de desarrollo de las metodologías, aquellas con mayor énfasis en la planificación y control del proyecto, en especificación

Más detalles

METODOLOGÍA TRADICIONAL.

METODOLOGÍA TRADICIONAL. METODOLOGÍA TRADICIONAL. Teniendo en cuenta la filosofía de desarrollo de las metodologías, aquellas con mayor énfasis en la planificación y control del proyecto, en especificación precisa de requisitos

Más detalles

Introducción ÍNDICE INTRODUCCIÓN...1 APORTACIONES DE MÉTRICA VERSIÓN 3...2

Introducción ÍNDICE INTRODUCCIÓN...1 APORTACIONES DE MÉTRICA VERSIÓN 3...2 Introducción ÍNDICE INTRODUCCIÓN...1 APORTACIONES DE MÉTRICA VERSIÓN 3...2 PROCESOS PRINCIPALES DE MÉTRICA VERSIÓN 3...3 PLANIFICACIÓN DE SISTEMAS DE INFORMACIÓN (PSI)...4 DESARROLLO DE SISTEMAS DE INFORMACIÓN...5

Más detalles

Tema 3 Metodologías de Desarrollo de Software

Tema 3 Metodologías de Desarrollo de Software Ingeniería del Software Ingeniería del Software de Gestión Tema 3 Metodologías de Desarrollo de Software Félix Óscar García Rubio Crescencio Bravo Santos Índice 1. Definiciones 2. Objetivos 3. Conceptos

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

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

Ingeniería de Software: Parte 2

Ingeniería de Software: Parte 2 Ingeniería de Software: Parte 2 Agustín J. González ElO329: Diseño y Programación Orientados a Objeto Adaptado de: http://www.dsic.upv.es/~uml http://inst.eecs.berkeley.edu/~cs169/ entre otras fuentes.

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

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

Ingeniería de Software

Ingeniería de Software Ingeniería de Software Agustín J. González ElO329: Diseño y Programación Orientados a Objeto Adaptado de: http://www.dsic.upv.es/~uml http://inst.eecs.berkeley.edu/~cs169/ entre otras fuentes. Definiciones

Más detalles

Desarrollo detallado de la fase de aprobación de un proyecto informático mediante el uso de metodologías ágiles.

Desarrollo detallado de la fase de aprobación de un proyecto informático mediante el uso de metodologías ágiles. Autor: Manuel Trigás Gallego Director de Proyecto: Ana Cristina Domingo Troncho Desarrollo detallado de la fase de aprobación de un proyecto informático mediante el uso de metodologías ágiles. Qué es un

Más detalles

Universidad Católica Andrés Bello Ingeniería en Informática Metodologías Ágiles de Gestión de Proyectos TI

Universidad Católica Andrés Bello Ingeniería en Informática Metodologías Ágiles de Gestión de Proyectos TI Universidad Católica Andrés Bello Ingeniería en Informática Metodologías Ágiles de Gestión de Proyectos TI MODELO Y HERRAMIENTA DE AUTOMATIZACIÓN PARA AGREGAR VALOR A LOS PRINCIPIOS ÁGILES DE DESARROLLO

Más detalles

Fundamentos de Ingeniería del Software. Capítulo 9. Métrica 3

Fundamentos de Ingeniería del Software. Capítulo 9. Métrica 3 Fundamentos de Ingeniería del Software Capítulo 9. Métrica 3 Métrica 3. Estructura 1. MÉTRICA - Objetivos 2. Ámbito de aplicación 3. Alcance del método 4. Versiones 5. MÉTRICA V.3 - Objetivos 6. Influencias

Más detalles

Planificación de Sistemas de Información

Planificación de Sistemas de Información Planificación de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...1 ACTIVIDAD 1: INICIO DEL PLAN DE SISTEMAS DE INFORMACIÓN...4 Tarea 1.1: Análisis de la Necesidad del...4 Tarea 1.2: Identificación

Más detalles

UNIVERSIDAD TÉCNICA DEL NORTE FACULTAD DE INGENIERÍA EN CIENCIAS APLICADAS ESCUELA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES

UNIVERSIDAD TÉCNICA DEL NORTE FACULTAD DE INGENIERÍA EN CIENCIAS APLICADAS ESCUELA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES UNIVERSIDAD TÉCNICA DEL NORTE FACULTAD DE INGENIERÍA EN CIENCIAS APLICADAS ESCUELA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES TEMA: La Programación Extrema aplicada al desarrollo del Sistema Informático

Más detalles

Planificación de Sistemas de Información

Planificación de Sistemas de Información Planificación de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ACTIVIDAD 1: INICIO DEL PLAN DE SISTEMAS DE INFORMACIÓN... 4 Tarea 1.1: Análisis de la Necesidad del... 4 Tarea 1.2: Identificació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

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

Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar

Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar Gobierno Municipal del Cantón Bolívar Versión: Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Plan de Desarrollo de Software Universidad

Más detalles

GESTIÓN DE PROYECTOS

GESTIÓN DE PROYECTOS GESTIÓN DE PROYECTOS Índice DESCRIPCIÓN Y OBJETIVOS...1 ACTIVIDADES DE INICIO DEL PROYECTO...2 ACTIVIDAD GPI 1: ESTIMACIÓN DE ESFUERZO...2 Tarea GPI 1.1: Identificación de Elementos a Desarrollar...3 Tarea

Más detalles

Implantación y Aceptación del Sistema

Implantación y Aceptación del Sistema y Aceptación del Sistema 1 y Aceptación del Sistema ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD IAS 1: ESTABLECIMIENTO DEL PLAN DE IMPLANTACIÓN...5 Tarea IAS 1.1: De finición del Plan de... 5 Tarea IAS

Más detalles

TEMA 1 INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE. Dr. José Ignacio Peláez Sánchez E.T.S.I. Informática de Sistemas. 3 er Curso.

TEMA 1 INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE. Dr. José Ignacio Peláez Sánchez E.T.S.I. Informática de Sistemas. 3 er Curso. TEMA 1 INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE Dr. E.T.S.I. Informática de Sistemas. 3 er Curso. Año 2004/2005 Visión General Importancia de la Ingeniería del Software. Retraso en la llegada de la Ingeniería

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

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

Ventajas de la migración a servicios de middleware modernos

Ventajas de la migración a servicios de middleware modernos Ventajas de la migración a servicios de middleware modernos Marcia Kaufman Directora de operaciones y analista jefe Patrocinado por Red Hat Introducción Las aplicaciones comerciales ya no se limitan a

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

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

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

Tema 3. Procesos ligeros de desarrollo de software.

Tema 3. Procesos ligeros de desarrollo de software. Ingeniería del Software II 2011 Tema 3. Procesos ligeros de desarrollo de software. Tipos de procesos ligeros. Tipos de procesos ligeros: Desarrollo Rápido de Software. Desarrollo Ágil. Programación Extrema.

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

4 a 8 semanas. Equipos pequeños 5 a 9 miembros. Informal. Cara a cara. En cada entrega el cliente dará su aportación. Sólo documentación básica

4 a 8 semanas. Equipos pequeños 5 a 9 miembros. Informal. Cara a cara. En cada entrega el cliente dará su aportación. Sólo documentación básica Tiempo para cada iteración recomendado ASD 4 a 8 semanas AUP Primeras iteraciones más tiempo que las demás. Tamaño del equipo Equipos pequeños 5 a 9 miembros Todos los tamaños Comunicación en el equipo

Más detalles

Universidad Autónoma del Estado de Hidalgo. Instituto de Ciencias Básicas e Ingeniería. Licenciatura en Sistemas Computacionales

Universidad Autónoma del Estado de Hidalgo. Instituto de Ciencias Básicas e Ingeniería. Licenciatura en Sistemas Computacionales Universidad Autónoma del Estado de Hidalgo Instituto de Ciencias Básicas e Ingeniería Licenciatura en Sistemas Computacionales. CASOS DE ESTUDIO: MÉTRICA II Y MERISE Monografía Que para obtener el Titulo

Más detalles

Revista Granma Ciencia. Vol. 16, no. 2 mayo - agosto 2012 ISSN 1027-975X

Revista Granma Ciencia. Vol. 16, no. 2 mayo - agosto 2012 ISSN 1027-975X Título: Gestión de la Calidad en el Ciclo de Desarrollo del Software de proyectos que usan metodologías ágiles. Title: Quality Management in Development Cycle Software projects using agile methodologies.

Más detalles

Interpretación de CMMI para Desarrollo, Versión 1.3 en enfoques ágiles. Iñigo Garro, Octubre de 2013

Interpretación de CMMI para Desarrollo, Versión 1.3 en enfoques ágiles. Iñigo Garro, Octubre de 2013 Interpretación de CMMI para Desarrollo, Versión 1.3 en enfoques ágiles Iñigo Garro, Octubre de 2013 Este documento se ha basado en el informe técnico CMU/SEI-2010-TR-033 del Software Engineering Institute,

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización Página 1 de 19 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 6 Situación Contraste externo Actualización

Más detalles

INSTITUTO TECNOLÓGICO SUPERIOR DE APATZINGÁN

INSTITUTO TECNOLÓGICO SUPERIOR DE APATZINGÁN INSTITUTO TECNOLÓGICO SUPERIOR DE APATZINGÁN INVESTIGACIÓN DOCUMENTAL Alumno: Alejandra Virrueta Méndez Carrera: Ingeniería en Informática. Docente: Esmeralda Villegas Zamudio Asignatura: Fundamentos de

Más detalles

CONCEPTOS DE CALIDAD Y CALIDAD DEL SOFTWARE

CONCEPTOS DE CALIDAD Y CALIDAD DEL SOFTWARE CONCEPTOS DE CALIDAD Y CALIDAD DEL SOFTWARE INTRODUCCIÓN El avance informático actual es muy alto comparado con lo se tenía en los años 90, al hablar de desarrollo de software se hace más notable, en el

Más detalles

LAS METODOLOGÍAS AGILES

LAS METODOLOGÍAS AGILES LAS METODOLOGÍAS AGILES Varias metodologías encajan bajo el estandarte de ágil. Mientras todas ellas comparten muchas características, también hay algunas diferencias significativas. No puedo resaltar

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

PRINCIPIOS DE PRUEBAS. ENFOQUE ESTRATEGICO.

PRINCIPIOS DE PRUEBAS. ENFOQUE ESTRATEGICO. PRINCIPIOS DE PRUEBAS. ENFOQUE ESTRATEGICO. 0. Consideraciones iniciales. Las pruebas son un conjunto de actividades que se pueden planificar por adelantado y llevar a cabo sistemáticamente. Por esta razón,

Más detalles

Ingeniería del Software. Introducción a la Ingeniería del Software Metodologías de Desarrollo de Software

Ingeniería del Software. Introducción a la Ingeniería del Software Metodologías de Desarrollo de Software Ingeniería del Software Introducción a la Ingeniería del Software Introducción Resulta necesario establecer un enfoque sistemático y disciplinado para llevar a cabo un desarrollo software El uso de una

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

Ciclo de vida y Metodologías para el desarrollo de SW Definición de la metodología

Ciclo de vida y Metodologías para el desarrollo de SW Definición de la metodología Ciclo de vida y Metodologías para el desarrollo de SW Definición de la metodología La metodología para el desarrollo de software es un modo sistemático de realizar, gestionar y administrar un proyecto

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

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

El Proceso Unificado de Desarrollo de Software

El Proceso Unificado de Desarrollo de Software El Proceso de Desarrollo de Software Ciclos de vida Métodos de desarrollo de software El Proceso Unificado de Desarrollo de Software 1 Fases principales del desarrollo de software Captura de requisitos:

Más detalles

Collaborative Lifecycle Management

Collaborative Lifecycle Management Collaborative Lifecycle Management IBM Rational Software Portafolio.. Documentación Técnica... COLLABORATIVE LIFECYCLE MANAGEMENT La solución de IBM Rational para la Gestión del Ciclo de Vida Colaborativo

Más detalles

Bachilleres: Bustamante Dayana C.I: 22.983.709 Rodríguez Jean C. C.I: 21.169.047

Bachilleres: Bustamante Dayana C.I: 22.983.709 Rodríguez Jean C. C.I: 21.169.047 UNIVERSIDAD NACIONAL EXPERIMENTAL DE LOS LLANOS OCCIDENTALES EZEQUIEL ZAMORA Ingeniería en Informática Subproyecto: Metodología de Desarrollo del Software Semestre VII Bachilleres: Bustamante Dayana C.I:

Más detalles

Beneficios de la implantación de una metodología para el ciclo de vida de desarrollos software

Beneficios de la implantación de una metodología para el ciclo de vida de desarrollos software Beneficios de la implantación de una metodología para el ciclo de vida de desarrollos software Dirección de Desarrollo y Aplicaciones Miguel Martínez Vélez Agenda 1. Introducción 2. El Proceso Software

Más detalles

Caso práctico. Examen oral para la acreditación de la licenciatura (EXOAL) Clave del caso práctico 777 Fecha de examen de primera etapa

Caso práctico. Examen oral para la acreditación de la licenciatura (EXOAL) Clave del caso práctico 777 Fecha de examen de primera etapa Caso práctico Examen oral para la acreditación de la licenciatura (EXOAL) Licenciatura por acreditar Nombre del sustentante Informática J. Genaro Contreras Ocampo Clave del caso práctico 777 Fecha de examen

Más detalles

Fundamentos de Ingeniería del Software. Capítulo 8. Introducción a los métodos de desarrollo de software

Fundamentos de Ingeniería del Software. Capítulo 8. Introducción a los métodos de desarrollo de software Fundamentos de Ingeniería del Software Capítulo 8. Introducción a los métodos de desarrollo de software Introducción a los métodos de desarrollo de software. Estructura 1. Definición. 2. Beneficios. 3.

Más detalles

Una Propuesta de Conjunción de Elementos Metodológicos en común dentro de los Enfoques ágiles para el Desarrollo de Software.

Una Propuesta de Conjunción de Elementos Metodológicos en común dentro de los Enfoques ágiles para el Desarrollo de Software. Una Propuesta de Conjunción de Elementos Metodológicos en común dentro de los Enfoques ágiles para el Desarrollo de Software. Rodolfo Meda (rodolfomeda@yahoo.com), Jorge Ierache (jierache@yahoo.com.ar).

Más detalles

Programación Extrema. Ing. Sebastian Priolo

Programación Extrema. Ing. Sebastian Priolo Programación Extrema Ing. Sebastian Priolo Metodologías Ágiles Menos orientadas a los documentos. Orientadas al código. El cambio es bienvenido. Procesos que cambian NO son predictivos Son adaptables Ejemplos

Más detalles

http://www.informatizate.net

http://www.informatizate.net http://www.informatizate.net Metodologías De Desarrollo De Software María A. Mendoza Sanchez Ing. Informático - UNT Microsoft Certified Professional - MCP Analísta y Desarrolladora - TeamSoft Perú S.A.C.

Más detalles

4.1.1_Reunión de Planificación de Sprint (Sprint Planning Meeting) 4.1.2_Objetivo del Sprint (Sprint Goal) 4.1.4_Revisión de Sprint (Sprint Review)

4.1.1_Reunión de Planificación de Sprint (Sprint Planning Meeting) 4.1.2_Objetivo del Sprint (Sprint Goal) 4.1.4_Revisión de Sprint (Sprint Review) 1_Visión general de SCRUM 2_Teoría de Scrum 3_El Equipo Scrum (Scrum Team) 3.1_El Dueño de Producto (Product Owner) 3.2_El Equipo de Desarrollo (Development Team) 3.3_El Scrum Master 4_Eventos de Scrum

Más detalles

Optimización ágil para conseguir una máxima innovación. agility made possible

Optimización ágil para conseguir una máxima innovación. agility made possible Optimización ágil para conseguir una máxima innovación agility made possible El método ágil acelera la innovación El exigente y frenético clima empresarial actual ha hecho que aumenten las expectativas

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

INGENIERÍA DEL SOFTWARE

INGENIERÍA DEL SOFTWARE INGENIERÍA DEL SOFTWARE Sesión No. 2 Nombre: Procesos de ingeniería del software INGENIERÍA DEL SOFTWARE 1 Contextualización La ingeniería de software actualmente es muy importante, pues con los avances

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

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

Departamento de Lenguajes y Sistemas Informáticos. Ciclo de vida del software

Departamento de Lenguajes y Sistemas Informáticos. Ciclo de vida del software El Ciclo de Vida Software Departamento de Lenguajes escuela técnica superior de ingeniería informática Grupo de Ingeniería a Software Febrero 2006 Versión original: Amador Durán Toro (septiembre 2004)

Más detalles

ORGANIZACIÓN DE LOS SERVICIOS INFORMÁTICOS

ORGANIZACIÓN DE LOS SERVICIOS INFORMÁTICOS 1 ORGANIZACIÓN DE LOS SERVICIOS INFORMÁTICOS INTRODUCCIÓN La realización de trabajos utilizando los medios informáticos de una empresa requiere una cierta organización y destreza relativa tanto a los equipos,

Más detalles

Introducción a la implementación de Scrum

Introducción a la implementación de Scrum Introducción a la implementación de Scrum Jorge Iván Meza Martínez http://www.jorgeivanmeza.com/ Jorge Iván Meza Martínez - 1 Contenido Introducción. Historia. Qué es un proyecto. Gestión

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

Mejora del Proceso de Desarrollo de Software en los Sistemas Distribuidos en

Mejora del Proceso de Desarrollo de Software en los Sistemas Distribuidos en Mejora del Proceso de Desarrollo de Software en los Sistemas Distribuidos en el Centro Informático del INSS Técnico superior de Informática INSS María Isabel Vicente Hernández Técnico medio de Informática

Más detalles

Ingeniería de Software. Dr. Marcello Visconti Departamento de Informática Universidad Técnica Federico Santa María visconti@inf.utfsm.

Ingeniería de Software. Dr. Marcello Visconti Departamento de Informática Universidad Técnica Federico Santa María visconti@inf.utfsm. Ingeniería de Software Dr. Marcello Visconti Departamento de Informática Universidad Técnica Federico Santa María visconti@inf.utfsm.cl Ingeniería?? de Software Grandes Problemas Actuales Retraso respecto

Más detalles

ISO 9001:2008 y Agile. Nuestra experiencia

ISO 9001:2008 y Agile. Nuestra experiencia ISO 9001:2008 y Agile Nuestra experiencia Contenidos 1. Quiénes somos 2. Por qué ISO 9001 3. Qué es ISO 9001 4. Qué es Agile 5. Estrategia 6. Diseño 7. Lecciones aprendidas Quiénes somos? Quiénes somos?

Más detalles

Gestión de Proyectos Ágil

Gestión de Proyectos Ágil P S + Gestión de Proyectos Ágil Preparación para la Certificación PMI-ACP (Agile Certified Professional) Poder Ser Más / www.podersermas.es Valor estratégico de la formación en Servicios Profesionales

Más detalles

Universidad ORT Uruguay

Universidad ORT Uruguay Facultad de Ingeniería Metodología SCRUM Cátedra de Ingeniería de Software. Docente Responsable: Gastón Mousqués. Autor: Adriana Peralta 123357 2003 ÍNDICE GENERAL Introducción 2 Principales características

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 17 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

Desarrollo de software

Desarrollo de software Agenda 1. Introducción 2. Aspectos Metodológicos del Desarrollo de Software 3. Aplicación Web (Modelo del Producto) 4. Modelo del proceso 5. Dos enfoques Metodológicos 6. Métodos Seleccionados 7. Evaluación

Más detalles

DIEZ RAZONES PRINCIPALES PARA MIGRAR A LINUX

DIEZ RAZONES PRINCIPALES PARA MIGRAR A LINUX DIEZ RAZONES PRINCIPALES PARA MIGRAR A LINUX Cambiar el sistema operativo de los equipos de escritorio de su empresa u organización es un reto importante. Pero Linux tiene importantes ventajas sobre el

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

Administración Ágil de. Juan Banda, MSc, CSP

Administración Ágil de. Juan Banda, MSc, CSP Administración Ágil de Proyectos Juan Banda, MSc, CSP Expositor Juan Banda es un Project Manager y Agile Coach que ha trabajado en empresas grandes (de más de 300 empleados) que se dedican a hacer outsourcing

Más detalles

Notas de Scrum. Licenciado Villarreal, Gonzalo Luján.

Notas de Scrum. Licenciado Villarreal, Gonzalo Luján. Notas de Scrum. Licenciado Villarreal, Gonzalo Luján. Sólo en uno de cada tres proyectos de software se cumple el plan inicial: el sistema realiza las funcionalidades inicialmente previstas, y se desarrolla

Más detalles

Modelos de Ciclo de Vida de Desarrollo de Software en el Contexto de la Industria Colombiana de Software

Modelos de Ciclo de Vida de Desarrollo de Software en el Contexto de la Industria Colombiana de Software Modelos de Ciclo de Vida de Desarrollo de Software en el Contexto de la Industria Colombiana de Software Hugo F. Arboleda Jiménez. MSc. Docente-Investigador, Facultad de Ingenierías, Universidad de San

Más detalles

PROPUESTA DE PROYECTO DE DESARROLLO DE PÁGINA WEB PARA GESTIÓN DE PROYECTOS CON METODOLOGÍA SCRUM

PROPUESTA DE PROYECTO DE DESARROLLO DE PÁGINA WEB PARA GESTIÓN DE PROYECTOS CON METODOLOGÍA SCRUM Universidad Rafael Landivar Campus Quetzaltenango Facultad de Ingeniería PROPUESTA DE PROYECTO DE DESARROLLO DE PÁGINA WEB PARA GESTIÓN DE PROYECTOS CON METODOLOGÍA SCRUM Linda Estrella Córdova Monterroso

Más detalles

Metodologías de desarrollo y modelos de ciclo de vida. Pablo Burgos Casado (SGTIC) Ministerio Industria, Energía y Turismo

Metodologías de desarrollo y modelos de ciclo de vida. Pablo Burgos Casado (SGTIC) Ministerio Industria, Energía y Turismo Metodologías de desarrollo y modelos de ciclo de vida. Pablo Burgos Casado (SGTIC) Ministerio Industria, Energía y Turismo 1 Sumario 1. Introducción a las Metodologías 2. Métrica v3 3. Metodologías Agiles

Más detalles

Tema 1 Introducción a la Ingeniería de Software

Tema 1 Introducción a la Ingeniería de Software Tema 1 Introducción a la Ingeniería de Software Curso Ingeniería de Software UMCA Profesor Luis Gmo. Zúñiga Mendoza 1. Software En la actualidad todo país depende de complejos sistemas informáticos. Podemos

Más detalles

<TITULO DEL PROYECTO DE DESARROLLO DE SW > Diana Milena Pérez Riveros 1 Diana Milena Pérez Riveros Pagina de

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

Anteproyecto Fin de Carrera

Anteproyecto Fin de Carrera Universidad de Castilla-La Mancha Escuela Superior de Informática Anteproyecto Fin de Carrera DIMITRI (Desarrollo e Implantación de Metodologías y Tecnologías de Testing) Dirige: Macario Polo Usaola Presenta:

Más detalles

Tema II Métodos Ágiles

Tema II Métodos Ágiles Tema II Métodos Ágiles Dr. Javier Garzás javier.garzas@urjc.es Universidad Rey Juan Carlos ÍNDICE 1 METODOLOGÍAS ÁGILES VS TRADICIONALES 2 METODOLOGÍAS HÍBRIDAS 3 SCRUM 4 PRÁCTICAS ÁGILES 5 OTRAS METODOLOGÍAS

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software MSDN Ingeniería de Software...1 Ingeniería del Software_/_ Ingeniería y Programación...1 Análisis de Requerimientos...2 Especificación...3 Diseño...4 Desarrollo en Equipo...5 Mantenimiento...6

Más detalles

Desarrollo en Cascada (Waterfall) VS Desarrollo Agile-SCRUM. Por Jesus Demetrio Velázquez Camacho

Desarrollo en Cascada (Waterfall) VS Desarrollo Agile-SCRUM. Por Jesus Demetrio Velázquez Camacho Desarrollo en Cascada (Waterfall) VS Desarrollo Agile-SCRUM Por Jesus Demetrio Velázquez Camacho Dentro de las organizaciones de desarrollo de aplicaciones existen dos grandes corrientes para la metodología

Más detalles

ADMINISTRACIÓN DE PROYECTOS

ADMINISTRACIÓN DE PROYECTOS ADMINISTRACIÓN DE PROYECTOS QUÉ ES LA ADMINISTRACIÓN DE PROYECTOS? Es la planeación, organización, dirección y control de los recursos para lograr un objetivo a corto plazo. También se dice que la administración

Más detalles

Mantenimiento de Sistemas de Información

Mantenimiento de Sistemas de Información de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ACTIVIDAD MSI 1: REGISTRO DE LA PETICIÓN...4 Tarea MSI 1.1: Registro de la Petición... 4 Tarea MSI 1.2: Asignación de la Petición... 5 ACTIVIDAD

Más detalles

Software. + Estructuras de Datos + Documentación

Software. + Estructuras de Datos + Documentación INT Introducción Software...2 Metodologías y Herramientas...5 Procesos de Software...8 Modelos de Proceso Software...9 Visión Genérica de la IS...15 Métrica Versión 3...17 Estructura Principal...20 Interfaces...22

Más detalles

Ofertas y Contratos en Scrum

Ofertas y Contratos en Scrum Ofertas y Contratos en Scrum Aspectos que se deben considerar para ofertar y contratar proyectos de entrega incremental. José Vázquez Sánchez 2013 José Vázquez Sánchez Twitea sobre el libro! Por favor

Más detalles

Unidad didáctica 2: Metodologías de desarrollo de Bases de Datos. Unidad didáctica 1: Fase de análisis de requisitos Modelo E/R

Unidad didáctica 2: Metodologías de desarrollo de Bases de Datos. Unidad didáctica 1: Fase de análisis de requisitos Modelo E/R índice Módulo A Unidad didáctica 1: Introducción a las Bases de Datos Unidad didáctica 2: Metodologías de desarrollo de Bases de Datos 3 19 Módulo B Unidad didáctica 1: Fase de análisis de requisitos Modelo

Más detalles

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE PRUEBAS DE SOFTWARE La prueba del software es un elemento crítico para la garantía de la calidad del software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Además,

Más detalles

P1 Elaboración de un plan de proyecto utilizando MS Project G3

P1 Elaboración de un plan de proyecto utilizando MS Project G3 UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMÁTICA P1 Elaboración de un plan de proyecto utilizando MS Project G3 José Luís Espinosa Aranda Noelia Vállez Enano Manuel Ramón Guerrero Álvarez

Más detalles