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

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

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

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

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

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 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

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

Planeación del Proyecto de Software:

Planeación del Proyecto de Software: Apéndice A. Cuestionarios del Sistema Evaluador Nivel2. Requerimientos de Administración: Goal 1: Los requerimientos del sistema asociados a software están bien controlados y existe un estándar para los

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

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

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

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente En este capítulo definimos los requisitos del modelo para un sistema centrado en la mejora de la calidad del código fuente.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Capítulo 11. Conclusiones y trabajo futuro

Capítulo 11. Conclusiones y trabajo futuro Capítulo 11. Conclusiones y trabajo futuro En esta tesis ha realizado un entorno de desarrollo Web que proporciona herramientas para la mejora de la calidad del código de los desarrolladores. Para conseguir

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

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

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

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

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

SCRUM Metodología de trabajo ágil

SCRUM Metodología de trabajo ágil SCRUM Metodología de trabajo ágil UN ENFOQUE PRÁCTICO Página 1 Página 2 Índice Introducción Características Criterios de referencia Fortalezas de Scrum Trazabilidad Definición Tipos Los Sprint Prácticas

Más detalles

MARCO DE COOPERACIÓN CON LAS UNIDADES DE INFORMÁTICA DISTRIBUIDAS

MARCO DE COOPERACIÓN CON LAS UNIDADES DE INFORMÁTICA DISTRIBUIDAS MARCO DE COOPERACIÓN CON LAS UNIDADES DE INFORMÁTICA DISTRIBUIDAS Concepción Hortigüela Hortigüela Directora de la Oficina de Planificación Estratégica y Relaciones Oficina de Planificación Estratégica

Más detalles

Módulo 9: Gestión y tratamiento de los riesgos. Selección de los controles

Módulo 9: Gestión y tratamiento de los riesgos. Selección de los controles Módulo 9: Gestión y tratamiento de los riesgos. Selección de los controles Este apartado describirá en qué consiste la gestión de riesgos, cómo se deben escoger los controles, se darán recomendaciones

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

Metodologías Ágiles Desde una Perspectiva de Project Management. Fernando Contreras Velásquez Project Management & Engineering Services.

Metodologías Ágiles Desde una Perspectiva de Project Management. Fernando Contreras Velásquez Project Management & Engineering Services. Metodologías Ágiles Desde una Perspectiva de Project Management Fernando Contreras Velásquez Project Management & Engineering Services. Ing. Fernando Contreras Velásquez: PMP, PMI-SP, PMI-RMP Acerca del

Más detalles

Capítulo 2. Marco Teórico

Capítulo 2. Marco Teórico Capítulo 2. Marco Teórico 2.1. Frameworks para Aplicaciones Web en Java Con el crecimiento exponencial de Internet en los últimos años, las aplicaciones Web se han convertido en una parte básica y común

Más detalles

Industrialice sus aplicaciones para lograr el alto rendimiento

Industrialice sus aplicaciones para lograr el alto rendimiento Technology Industrialice sus aplicaciones para lograr el alto rendimiento Los ejecutivos de TI continúan buscando métodos con los cuales poder aumentar, de manera medible, tanto la eficiencia como la efectividad

Más detalles

GUÍA DE IMPLANTACIÓN DE UN SISITEMA DE GESTIÓN DE SEGURIDAD DE LA INFORMACIÓN UNE ISO/IEC 27001:2007 CON LA HERRAMIENTA GLOBALSGSI

GUÍA DE IMPLANTACIÓN DE UN SISITEMA DE GESTIÓN DE SEGURIDAD DE LA INFORMACIÓN UNE ISO/IEC 27001:2007 CON LA HERRAMIENTA GLOBALSGSI GUÍA DE IMPLANTACIÓN DE UN SISITEMA DE GESTIÓN DE SEGURIDAD DE LA INFORMACIÓN UNE ISO/IEC 27001:2007 CON LA HERRAMIENTA GLOBALSGSI POWERED BY AUDISEC www.audisec.es Febrero de 2010 ÍNDICE 1. PRESENTACIÓN...

Más detalles

Modelo para el Aseguramiento de Calidad en el Desarrollo de Software Libre

Modelo para el Aseguramiento de Calidad en el Desarrollo de Software Libre Modelo para el Aseguramiento de Calidad en el Desarrollo de Software Libre Cenditel, Mayo 2011 Licencia de Uso Copyright (c) 2010, Alvarez J., Solé S., Briceño R., Fundación CENDITEL. La Fundación CENDITEL

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

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

Gestión de proyectos: formal o ágil?

Gestión de proyectos: formal o ágil? NST-0004 Rev. 0.1 http://www.navegapolis.net Juan Palacio, 2006 Gestión de proyectos: formal o ágil? Ágil, clásica, predictiva? Al surgir en los 80 una nueva forma de gestionar proyectos, se hizo necesario

Más detalles

3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE

3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE 3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE Software Configuration Management (SCM) es una disciplina de la Ingeniería de Software que se preocupa de [Ber92] [Ber84] [Bou98] [Mik97]: Identificar y documentar

Más detalles

Escuela Politécnica Superior. Organización Empresarial y Proyectos. Capítulo 6. daniel.tapias@uam.es. Dr. Daniel Tapias Curso 2014/ 15 PROYECTOS

Escuela Politécnica Superior. Organización Empresarial y Proyectos. Capítulo 6. daniel.tapias@uam.es. Dr. Daniel Tapias Curso 2014/ 15 PROYECTOS Escuela Politécnica Superior Organización Empresarial y Proyectos Capítulo 6 Dr. Daniel Tapias Curso 2014/ 15 daniel.tapias@uam.es PROYECTOS PROGRAMA DE LA ASIGNATURA Capítulo 1: Introducción. Capítulo

Más detalles

Modelo de Gestión Ágil

Modelo de Gestión Ágil Modelo de Gestión Ágil Diseñado por www.zeuxa.com Noviembre 2009 Esta obra está bajo una licencia Reconocimiento-Compartir de Creative Commons. Antecedentes > Motivación Necesidad: Gestionar la incertidumbre:

Más detalles

Gestionando Agile/Scrum con Sciforma

Gestionando Agile/Scrum con Sciforma agile Gestionando Agile/Scrum con Sciforma El desarrollo ágil de software son métodos de ingeniería del software basados en el desarrollo iterativo e incremental, donde los requerimientos y soluciones

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

PDSM: PROCESO DE DESARROLLO DE SOFTWARE MIXTO COMBINANDO RUP Y SCRUM. Mariani, María Florencia Okabe, Evangelina

PDSM: PROCESO DE DESARROLLO DE SOFTWARE MIXTO COMBINANDO RUP Y SCRUM. Mariani, María Florencia Okabe, Evangelina PDSM: PROCESO DE DESARROLLO DE SOFTWARE MIXTO COMBINANDO RUP Y SCRUM Mariani, María Florencia Okabe, Evangelina Agenda Introducción Metodologías RUP SCRUM Proyectos PDSM: Definición y Aplicación del proceso

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

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

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

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

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

Definición de PMO Características de una PMO

Definición de PMO Características de una PMO Definición de PMO Existen varios conceptos de una oficina de proyectos (PMO) una de ella la define como una unidad organizacional, física o virtual, especialmente diseñada para dirigir y controlar el desarrollo

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

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

Guía para implementar mejores prácticas ambientales en organizaciones

Guía para implementar mejores prácticas ambientales en organizaciones Guía para implementar en organizaciones Contenido Presentación... 2 Qué son las Mejores Prácticas Ambientales... 3 Características principales de las MPA... 4 Dimensiones de las Mejores Prácticas Ambientales...

Más detalles

Qué es Scrum? Basado en el texto Explicando Scrum a mi abuela de Jorge Serrano - MVP Visual Developer - Visual Basic

Qué es Scrum? Basado en el texto Explicando Scrum a mi abuela de Jorge Serrano - MVP Visual Developer - Visual Basic Qué es Scrum? Basado en el texto Explicando Scrum a mi abuela de Jorge Serrano - MVP Visual Developer - Visual Basic http://geeks.ms/blogs/jorge/archive/2007/05/09/explicando-scrum-a-mi-abuela.aspx Por

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

UNE-ISO/IEC 20000-1:2011 - Requisitos del Sistema de Gestión del Servicio

UNE-ISO/IEC 20000-1:2011 - Requisitos del Sistema de Gestión del Servicio ISO 20000, camino a la excelencia Introducción En los últimos años hemos podido ver la gran aceptación que ha conseguido el modelo EFQM como modelo de referencia para la excelencia empresarial. Un modelo

Más detalles

El objetivo principal del presente curso es proporcionar a sus alumnos los conocimientos y las herramientas básicas para la gestión de proyectos.

El objetivo principal del presente curso es proporcionar a sus alumnos los conocimientos y las herramientas básicas para la gestión de proyectos. Gestión de proyectos Duración: 45 horas Objetivos: El objetivo principal del presente curso es proporcionar a sus alumnos los conocimientos y las herramientas básicas para la gestión de proyectos. Contenidos:

Más detalles

Gestión de proyectos

Gestión de proyectos Gestión de proyectos Horas: 45 El objetivo principal del presente curso es proporcionar a sus alumnos los conocimientos y las herramientas básicas para la gestión de proyectos. Gestión de proyectos El

Más detalles

Mejora Ágil de Procesos

Mejora Ágil de Procesos Mejora Ágil de Procesos Introducción Después de haber implementado por muchos años modelos de mejora, de dirección de proyectos y diferentes marcos ágiles, llegué a la conclusión de que el camino hacia

Más detalles

LECTURA 2: GESTIÓN INTEGRADA DE PROYECTO.

LECTURA 2: GESTIÓN INTEGRADA DE PROYECTO. LECTURA 2: GESTIÓN INTEGRADA DE PROYECTO. 1. RESUMEN 2. INTRODUCCIÓN 3. DEFINICIONES DE LA GESTIÓN INTEGRADA DE PROYECTOS 4. EL CICLO DE VIDA DE UN PROYECTO: FASES 5. VENTAJAS DE LA GESTIÓN INTEGRADA DE

Más detalles

Introducción. Definición de los presupuestos

Introducción. Definición de los presupuestos P o r q u é e l p r e s u p u e s t o d e b e s e r e l c a m i n o a s e g u i r p a r a g a r a n t i z a r e l é x i t o d e s u e m p r e s a? Luis Muñiz Economista Introducción El aumento de la incertidumbre

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

CICLO DE VIDA DEL SOFTWARE

CICLO DE VIDA DEL SOFTWARE CICLO DE VIDA DEL SOFTWARE 1. Concepto de Ciclo de Vida 2. Procesos del Ciclo de Vida del Software 3. Modelo en cascada 4. Modelo incremental 5. Modelo en espiral 6. Prototipado 7. La reutilización en

Más detalles

Criterios a tener en cuenta para seleccionar un sistema de gestión de proyectos en software libre

Criterios a tener en cuenta para seleccionar un sistema de gestión de proyectos en software libre Criterios a tener en cuenta para seleccionar un sistema de gestión de proyectos en software libre 20 de diciembre de 2011 José Moro Melón facebook.com/josemoromelon linkedin.com/in/josemoro gplus.to/josemoro

Más detalles

Resumen General del Manual de Organización y Funciones

Resumen General del Manual de Organización y Funciones Gerencia de Tecnologías de Información Resumen General del Manual de Organización y Funciones (El Manual de Organización y Funciones fue aprobado por Resolución Administrativa SBS N 354-2011, del 17 de

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

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

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

Mejores prácticas para el éxito de un sistema de información. Uno de los problemas de información dentro de las empresas es contar con datos

Mejores prácticas para el éxito de un sistema de información. Uno de los problemas de información dentro de las empresas es contar con datos ANEXO VI. Mejores prácticas para el éxito de un sistema de información Uno de los problemas de información dentro de las empresas es contar con datos importantes del negocio y que éstos estén aislados

Más detalles

Auditoría que agrega valor

Auditoría que agrega valor International Organization for Standardization International Accreditation Forum Auditoría que agrega valor Que es una auditoría que agrega valor? Escuchamos mucho a cerca de la importancia de agregar

Más detalles

PERFILES OCUPACIONALES

PERFILES OCUPACIONALES PERFILES OCUPACIONALES A continuación se presenta la relación de los diferentes cargos que un ingeniero de sistemas de la Universidad de Lima puede desempeñar durante su vida profesional. También se presentan

Más detalles

A partir de este capítulo se introducen términos, probablemente nuevos para el

A partir de este capítulo se introducen términos, probablemente nuevos para el CAPITULO 3. PSP 0 Y PSP 0.1 A partir de este capítulo se introducen términos, probablemente nuevos para el lector que tienen que ver en su totalidad con PSP. También se dan a conocer los formatos, "scripts

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

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

BPM: Articulando Estrategia, Procesos y Tecnología

BPM: Articulando Estrategia, Procesos y Tecnología BPM: Articulando Estrategia, Procesos y Tecnología Resumen: La competitividad es el imaginario que dirige las acciones empresariales en la actualidad. Lograr condiciones que permitan competir con mayores

Más detalles

Karen Giraldo Escobar Graciela Catalina Soto PROYECTO DE GRADO I

Karen Giraldo Escobar Graciela Catalina Soto PROYECTO DE GRADO I Karen Giraldo Escobar Graciela Catalina Soto PROYECTO DE GRADO I Qué es SCRUM Beneficios Como Funciona Fundamentos Requisitos Historia Qué es SCRUM Beneficios Como Funciona Fundamentos Requisitos Historia

Más detalles

VISIÓN GENERAL HERRAMIENTAS COMERCIALES

VISIÓN GENERAL HERRAMIENTAS COMERCIALES VISIÓN GENERAL El servidor de MS SQL se ha convertido en un estándar en muchas partes de la América corporativa. Puede manejar volúmenes de datos grandes y se integra bien con otros productos de Microsoft.

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

Los profesores Flipantes

Los profesores Flipantes Los profesores Flipantes 1 0. Índice 1. Introducción al TSP 2. La lógica del TSP 3. Lanzamiento de un Proyecto TSP. 4. Fases del Ciclo TSPi. 5. TSPi en DSIC. 2 1. Introducción al TSP. El software suele

Más detalles

18 de julio de 2010. Respondiendo al desafío: FEEDBACK 360º

18 de julio de 2010. Respondiendo al desafío: FEEDBACK 360º 18 de julio de 2010 Respondiendo al desafío: FEEDBACK 360º Contenidos Introducción... 3 Por qué establecer un Proceso de Feedback 360º?... 4 Para qué un Feedback 360º en mi Modelo de competencias?... 5

Más detalles

CAPÍTULO V. IMPLEMENTACIÓN DEL SISTEMA DE GESTIÓN DE CALIDAD

CAPÍTULO V. IMPLEMENTACIÓN DEL SISTEMA DE GESTIÓN DE CALIDAD CAPÍTULO V. IMPLEMENTACIÓN DEL SISTEMA DE GESTIÓN DE CALIDAD 221 A continuación se describen las etapas que una empresa del sector metal mecánica, debe seguir y cumplir para implementar el sistema de gestión

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

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